Boredom-Driven Development
I mentioned in a previous post that the Ajax Experience conference crowd showed a great interest in automated testing. During one of the testing sessions, I posted a thought that got retweeted several times:
After the conference, I spent some time looking at what the various frameworks had as for testing hooks built in. While I don’t have working experience with Rails, I was familiar with it’s console and some of the clever ways it lets you peek into your application to see how things are working (or not working) together. I was curious if Django had something similar, although I got sidetracked watching Django in the Real World from Django-Con 2009 before I got too far. There’s actually quite a few good quotes throughout the presentation, but this one from Kent Beck’s Test Driven Development: By Example stood out:
Tests are the Programmer’s stone, transmuting fear into boredom.
Too often, those of us in the maintenance section of the software life cycle are paralyzed by fear when we come across a problem. Can I fix this without breaking other things? Does anything in my application depend on this broken implementation? We shouldn’t have to ask these questions, and automated tests give us the confidence to make those necessary changes without the element of fear. You want that level of boredom.
Having to agonize over what should have been a simple bug fix is not a fun process. Test-driven development has caught a bad wrap from some who argue that TDD imposes unrealistic principles in real-world development. I disagree with that stance on the basis that most of Beck’s work that I’ve read has argued for practical rather than fanatical testing. If you can get to 100% code coverage, great, but do you really need to test your getter/setter methods? Probably not.
The Ajax Experience 2009
This week I was fortunate enough to attend The Ajax Experience (put on by the Ajaxian folks) out in Boston. The conference was spread over 3 days, covering a range of topics from ECMAScript5 and the future of JavaScript to running continuous integration suites against a web application.
It was a pretty hard coming back to Fargo Thursday afternoon and trying to jump back in to work the next morning with a head full of ideas that need to be pulled down, polished and persisted somewhere, but I managed to get through a few issues that I left unfinished the previous Friday.
The Future of Ajax
Monday morning, Ben Galbraith (co-founder of ajaxian.com) gave an excellent talk titled The Future of Ajax. His talk focused appropriately on the way new technologies like Canvas are changing the web. He demoed Bespin, a Mozilla Labs project that aims to create a full-featured web code editor in the browser using HTML 5 technologies.
There was also some focus on old things turned new. Ben had this to say about the JavaScript speed war:
When you increase the speed of something by an order of magnitude, you haven’t improved something, you’ve created something new.
That quote rightly focuses how critical the browser wars, specifically the JavaScript speed aspect, has been to modern web applications. Other innovations, such as the generational garbage collection built in to Chrome’s V8 engine is revolutionary, and I have a feeling that it will be copied by others in the future.
The Tools
Steve Souders is a pretty cool guy. He introduced two new tools at the conference: Browserscope and SpriteMe.
Browserscope is a crowdsourcing tool being used to profile various browsers. If you head over to the site, you can run a broad set of tests against your browser to test it’s capabilities. As you might expect, most of the tests are based on Souders’ rules for high performance web sites (get the book), but since the results are all captured, the hope is that Browserscope will be a resource for web developers needing information on the capabilities of different browsers.
SpriteMe is a JavaScript bookmarklet that searches a page for all of the CSS background images and then suggests how you might put them into a sprite to improve page performance. If you page has 20 background images, your browser has to make 20 requests to see if the images were modified (depending on how your web server is set up), so it can be a huge performance bottleneck on older browsers. SpriteMe even contains a link to generate the sprite for you (using CoolRunnings), and you can add or remove images to the sprite as you see fit.
The Crowd
Perhaps one of the best aspects of the conference was the group of attendees. I’m guessing there were around 300 people there, so it was a smaller conference, but it’s so valuable to be able to chat with other people who’ve faced problems you’re experiencing and be able to chat about how they solved them.
The Twitter crowd was pretty active. Common topics included, “Holy shit it’s cold in here”, “this Wakanda presentation is terrible”, and “The Hilton’s wireless would be great for testing our app against a spotty connection”.
The End.
All in all, the conference was great, and I’m so happy that I was able to attend. Having an oppurtunity to see Douglas Crockford and Steve Souders speak was well worth the trip alone.
I was also excited to see that there is a huge desire for automated testing in the Web world, but it’s still a tough problem to solve in an elegant manner.
The server-side JavaScript buzz will be an interesting thing to watch over the next year, but it seems to not have any real traction yet (perhaps the finalization of ES5 will change that).
Slides for many of the presentations can be found here.
Google App Engine, Bobby Tables, And #bugsthatuwontfind
Google App Engine went into extended downtime last Thursday. The Tweetosphere was up in arms, and there were a lot of pissed off people roaming the interwebs. Understandable. Downtime sucks for everyone, whether it’s your app, or you’re the user and you just need that damn duck jambalaya that you saved on that spiffy new app you discovered last week. The cause of the downtime? A single malformed file pointer passed from a single application unintentionally exploited a bug in the GFS Master Node that runs the Data Store. More from the official Google post:
The root cause of the outage was a bug in the GFS Master server caused by another client in the data center sending it an improperly formed file handle which had not been safely sanitized on the server side, and thus caused a stack overflow on the Master when processed.
I’m oversimplifying. That single fault actually caused a cascade of unforeseen circumstances that took a not-insignificant amount of time for Google’s engineers to patch up. The details are in the extended downtime information that Google provided and I won’t go into them here.
What I find both comforting and disturbing about this castrophany is that it uncovered a who-knows-how-old bug in GFS. The problem had been experienced a week earlier, but given the nature of the App Engine DataStore, I have to think if the engineers knew what caused the problem that it would have been patched sooner rather than later:
8:00 AM — The cause of the GFS Master failures has not yet been identified. However, a similar-looking issue that had been seen in a different data center the week prior had been resolved by an upgrade to a newer version of the GFS software.
It sounds to me like this bug was accidentally fixed, rather that discovered, recreated, and intentionally patched. It’s difficult, however, to do much more than guess at Google’s internal software upgrade schedule, so this is all just a bunch of guesswork. It just goes to show that you can never be too paranoid about what your users are doing on your platform. I’m reminded of the XKCD comic: Exploits of a Mom
![Exploits of a Mom [via XKCD]](http://imgs.xkcd.com/comics/exploits_of_a_mom.png)
Meebo misses me
When I was a student at MSUM, we had one small computer lab that was the unofficial geek hangout: the Linux Lab.
The computers were nothing extravagent, and until the last year of my undergrad degree they still had CRT monitors, but it was our lab. The one downside was that the lab was so locked down network-wise, we couldn’t use the already-installed IM clients (probably for good reason). Fortunately, Meebo was coming in to it’s own during the same time period.
Meebo is pretty cool in it’s own right, but I pretty much had no use for it after I finished college, and so I forgot about it until the other day when I received this email:
I don’t know exactly why, but somehow this obviously automated email seemed strangely personal. Someone at Meebo went out of their way to solicit some feedback about why I stopped using their service, which is enough to make me think, “This company is worth my time.” Tiny glimpses at the personality driving services like Meebo make software seem not so impersonal, and that can really make a difference in how your userbase views you as a company.
Opera’s Standards Compliance a Detriment?
There’s an interesting compatibility debate going in the comments thread of a blog post on my.opera.com.
The issue the article poses is that Opera has gone to great lengths to follow the standards that the W3 put forth. In doing so, the author has run into to a number of major sites that do not work properly due to their abuse^H^H^H^H^H use of JavaScript’s setTimeout method.
When I first got in to web development, I was one of the purists who thought that page validation and standards were really important.
Scratch that.
I still think that standards and validation are important. I’ve seen some bizarre behavior in all of the major browsers (Firefox, Opera, IE, Safari) due to even more bizarre markup. To some end, however, Joel had a point when he argued that standards don’t matter. Standards are great, until you end up with a non-standards compliant implementation that, for a long time, becomes the standard upon which others are judged (there are several issues I have with Joel’s position, but those are best left for another article). Back when IE6 was the browser and Firefox was sitting on a puny 2% market share, if a page displayed and functioned properly in IE but not in Firefox, well dammit, it was Firefox’s fault. Eventually, however, we learned that Firefox did a much better job of following the W3 standards, and it was a little easier to develop for, and people started using it. Several years later, the tables have flipped, and it’s the Internet Explorer team that’s taking the bad rap for not having committed to standards early on.
Opera is in the same boat today as Firefox was back then. Firefox has become the standard by which everything else is judged (though Webkit is rapidly gaining support), and as a consequence of Firefox having to implement some of IE’s quirks for sanity’s sake, Opera adheres just a little bit better to the W3 standards than Firefox does. Parsing markup is one thing, but JavaScript performance has become a huge interest lately. Don’t believe me? Ask Google.
Given what John Resig discovered about timer implementations across various browsers, it’s no surprise that the sites mentioned in the Opera article have wildly different results depending which browser you’re using. But c’mon people, it’s 2009 already. Haven’t we found some sane way to work around issues like this?
Actually yes.
This is exactly why the more popular JavaScript frameworks were developed and have become widely popular. They take care of these browser differences so you don’t have to. It’s a little surprising to see large organizations such as AOL and the New York Times haven’t picked up one of the popular libraries, though I suppose it’s just as reasonable to assume that they’ve developed their own code in-house, and it’s just not quite as robust as it should be.
Should Opera get slammed for something that is apparently an oversight on the part of the web developers?