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)
Simple, Repeatable, Powerful
In software, simple is better.
As developers, we spend much more time trying to understand code than we do writing it. It’s going to be a lot easier for your collegues to understand what you meant by a method nameddoesUserExist() than everybodyWangChungTonight().
Tracking down obscure bugs is insanely frustrating. It’s even more frustrating when you have to struggle to grasp a shred of meaning from the code that is supposedly buggy. Imagine what your college professors must have gone through.
Dr. Brekke: I’m sorry I picked random animal names for variable names on that assignment. It was late and OperationHerdCats() seemed hilarious at the time.
There. That feels better.
Similarly, if you have to jump through an arbitrary number of hoops to perform some action at work, be it kick off an integration build, generate a report, or make a new pot of coffee, it’s going to be hard to talk anyone in to taking over or sharing in those duties.
I’ve been gradually working my way though The Pragmatic Programmer over the last few weeks. Some things are old hat (thanks Dr. Walker), while others are less obvious, but insanely practical. One of the ideas was that everything you do should be easily reproducible with simple steps. This falls right in line with #2 of The Joel Test.
The Power of Simple.
In building the template that this blog used to use, I ran into a few minor hiccups. I’m currently hosting the site on GoDaddy shared hosting, so I’m limited to using FTP for transferring files. That, by itself, is not a huge deal. I’d prefer rsync, but I can make do.
While chatting with a friend one night, I mentioned that I’d just updated a bunch of stylesheet rules. He replied that it looked the same as it did the previous week, which was odd since I had made several minor updates since then. It turned out to be a simple CSS caching error, caused by me forgetting to update the version number following the script HREF in the HTML. Previously, the link looked like this in the template:
<link rel="stylesheet" type="text/css" href="<?php bloginfo('stylesheet_url'); ?>?4815162342 />
In this example, 4815162342 is just an arbitrary number that gets incremented to trick the browser into thinking the file might have changed by using a simple GET request. It’s a simple way to let the browser cache the stylesheet, but still force it to get a new one whenever necessary by simply changing the number. Rails does something similar, but it appends the last-modified timestamp of the external CSS or JavaScript file in place of the arbitrary numbers I’ve used.
I thought for a little while, but then I realized that what I really wanted needed was a 1-click (err, command) Build Process that did the following:
- Create a dist directory to allow for an uncontaminated base point for a release
- Copy all of the image files to the dist directory (I really need to get ambitious and make some sprites)
- Copy all of the relevant PHP files to the dist directory
- Minify the external CSS and JavaScript files and put them in the new directory
- Update my arbitrary number in the header.php file so I don’t have to ever think about it again.
Using Ant, this ended up being a simple, yet valuable introduction to the Java Build world. The only thing I really needed to sub out was to a really trivial shell script on my desktop that took care of the minification using the YUI Compressor. My build process went from actually more steps than what I laid out before to the following:
- ant deploy
Even my SO could handle that. Simple. Repeatable. Powerful.