"Libraries should be mostly unit tested. Applications should be mostly (and lightly) integration tested. Naturally, some parts of a complex app will behave like a library..."

Agree or disagree?

My second reaction: what happens when the magic ends? When I was new to Rails, I really loved how easy it was to get started with scaffolding, a nice DSL for specifying relations, nifty form helpers. However, the first time I veered a little off the golden path and wanted to do something a little more complicated (that was not supported by the form helpers at that time), I ran into a huge wall. I found out that I actually had no idea how Rails worked. The magic had hidden all complexity from me before, and now the magic failed me and I didn't know where to start doing it on my own. Rails has matured a lot since then (it also dropped some of the magic in favor of more explicit behavior) and my understanding of the framework has grown with it.

Meteor looks even more magic to me. There is so much stuff happening. What if I plan to do a lot of dynamic updates and I want to defer live-updating because I am doing mass-updates? What if I need a hard division between client/server code? What if I want to share the backend with an iOS app or something? Can I use this to build an API? The documentation does not yet fully answer these questions for me.

Actually, that pixel density is typically too high because they sit so far back. From http://www.economist.com/blogs/babbage/2011/08/high-definiti...

"A survey made some years ago by Bernard Lechner, a television engineer at the former RCA Laboratories, near Princeton, New Jersey, showed that the median eye-to-screen distance in American homes was nine feet. At that distance, a 1080p HDTV set (with a screen 1,920 pixels wide and 1,080 pixels high) needs to be at least 69-inch across a diagonal if viewers are to see all the detail it offers."

When I play games on my XBox, I need to pull up a chair so I can sit about 5-6 feet from my TV. My couch is about 10' from the TV, and I simply can't make out the detail as well from that distance.

Unfortunately for real memory (caches, DIMMs, swap etc) that's not true. It's O(log n) for any non-trivial size of memory, and can have bad (constant?) factors for mutating memory that is shared between processors.

Of course functional languages have hidden and not-so-hidden costs too, starting with the garbage collector, but including the time taken to get the larger working set into cache.

I'm interested in any studies that look at these total costs in real systems.

I quickly realized that my job was futile - many of the "good" tests had already been written, while in other places, "bad" tests were entrenched and the "test dev" had the job of manning the scanner to check for nail clippers, or upgrading the scanner to find as many nail clippers as possible.

Here's a useful rule on the subject that I picked up from an Artificial Intelligence course back in the day: The value of a piece of information is proportional to the chance that you will act on it times the benefit of acting on it. We all realize there is no benefit in testing if you ignore failures rather than acting to fix the bugs, but in much the same way that doing nothing when tests fail has no benefit, doing nothing when tests pass also has no benefit - so tests which always pass are just as useless as failing tests you ignore, as are tests which only turn up corner-case bugs that you would have been comfortable with shipping.

If you're doing the right amount of testing, there should be a good chance, whenever you kick off a test run, that your actions for the next hour will change depending on the results of the run. If you typically don't change your actions based on the information from the tests, then the effort spent to write tests gathering that information was wasted.

IMO this is pretty shitty - I put this information into the app to send to other people, not so Bump can email me. And now I feel iffy putting other data into the app - Bump is not strictly the data exchange platform I thought it was.

This is a violation of user trust - if you want to store/act on any information users put into the app you need to let them know first.

This really, really rubbed me the wrong way - this is the first time any app of mine has ever intercepted a form field, sent it to the mothership without my consent, and used the data in a way that was never stated nor implied. App deleted.

[edit] Oh hey look, the email addressed me by the name I put into the vCard. I guess now you have my phone number too.

I'd like to add a few things: 1. The german system of government is very much different from the US. In the US you have by-and-large a "winner takes it all" voting system. In germany, by contrast, we have a system of proportional representation. That means, winning 10% of the popular vote nets you 10% of the seats that are on the line in your voting district. That's why we currently have 6 parties in our federal parliament ("Bundestag") - where you have only 2 parties in congress.

2. Although this is "just" a poll it isn't meaningless. The pirate party has been steadily building up momentum in the last 2 years. They now are the 5th largest party by member count in germany. They have also scored surprisingly high wins in two recent regional elections, and are set to repeat those gains in the two upcoming elections.

3. The pirate party runs on a platform of systemic reform. They want copyright reformed to be more compatible with the 21st century. They want a reformed educational sector with more use of modern technology in the classroom, as well as improved structures (i.e. more freedom to pursue different educational models). They also want to reform the political system at large, by having more citizen participation in political decisions. They want more public votes on specific issues, as well as more transparency (For example: ACTA was negotiated in secret and only announced to the german public once the details were finished. They pirates strongly oppose such intransparency.)

This helped them to capture the votes of young, highly educated people. Many, but by no means all, from the "informatics" sector. They have also mobilized many first time voters, and re-energized many people who had formerly abandoned voting.

4. What's currently also helping them is the bad state of our government (the governing coalition is in disarray), their inability to answer to the challenges shaping our future, their corruption (our head of state recently had to resign in shame), their detachedness from concerns of everyday people. This greatly helps them to get the vote of people who are disaffected with the "established" parties and who are ready to give those "political youngsters" a chance.

It's by no means guaranteed, but they seem to be on the way of becoming a serious political force in germany.

The basic thing about tests is that once you have them passing, they represent statements about constraints on the program. In other words, they express your opinion of things that should not change. Unit tests are a bet that certain aspects of the implementation will not change. Integration tests are a bet that certain aspects of the externally visible behaviour will not change.

Libraries tend to be smaller and with well-defined responsibility. Applications tend to be bigger and have many responsibilities. In general, I think it’s true that the requirements for libraries change less often than the requirements for applications. I think this leads us to expect that applications may need to be rewired “under the hood” and have their implementations changed as responsibilities are added, removed, or changed.

This, I believe, leads us to want to unit test applications less, because a unit test expresses implementation semantics, and we expect application implementations to change. No what about integration tests? Well, if we’re unit testing less in the application, we need to make up for it by integration testing more, otherwise where do we get our confidence?

Now if we throw the words “library” and “application” away, this suggests to me that those parts of the code that are small and tight and with a single, clear responsibility should be unit tested, while those parts that involve a lot of what the AOP people call ‘scattering and tangling,’ should be integration tested.

Thoughts?

Ebooks have essentially zero printing and distribution costs and, from the publisher's point of view, can't be resold like paper books can. For both of these reasons they should be cheaper. On this point, Jeff Atwood actually makes sense [1].

I know the spiel about pricing having nothing to do with the cost of production, blah blah blah. I don't care. The present situation is stupid and ultimately shortsighted. Only Amazon seems to be interested in creating an ebook market rather than just gouging consumers.

[1]: http://www.codinghorror.com/blog/2012/04/books-bits-vs-atoms...

As a slightly more on-topic aside- an app I made was recently featured in the NY Daily News. The results were great- I got some useful feedback from real users, rather than hypothetical users more interested in gossip.