Book Review: Show Stopper!

My first book of 2009 was a crusty old out-of-print classic I'd given up on finding a copy of years ago, but I found it under the X-mas tree last month courtesy of my awesome girlfriend. The book was, of course, Show Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft.

I'm no fan of Microsoft, but I'm a sucker for software development stories, no matter how embellished. From the definitive The Soul of a New Machine to the almost farcical Microserfs and everything in between like The Autodesk File and Dreaming in Code and I could list another dozen from my reading list of the last decade but I'll save that for another time and another post. Essentially, I love reading about how other people suffered through pushing a product to market, because I've lived it myself a few times now, and I suspect I'll do a few more tours of duty before my retirement.

Show Stopper! makes a for a good leisurely read, but unfortunately it's far more focused on the people and their relationships rather than the technological and political hurdles they had to overcome. In other words, it's more fluff, less stuff. The book slowly and methodically introduces core people on the Windows NT team, giving their back story, explaining their motivations, touching on their personal lives outside of the office, etc. Technology and politics are covered, but not in great detail, and in some cases so abstractly as to insult a reader that hungers for the nitty gritty specifics.

Without spoiling the plot too much, a complex new operating system is conceived, an all-star team is assembled to produce it, deadlines are missed by years, tempers flare, nerves are shot, power plays are made, and in the end if ships. Of course, you knew how it ends. It saddens me think some of you readers are young enough to not have even used Windows NT. Sometimes working with the old clunky stuff gives you a much better appreciation for what you have today. Perhaps I'd not be such a fanatical OS X pundit today if I'd not had to launch a product or two on top of Windows NT.

So in summary, Show Stopper! is worth a read. It's not in my top five of historical dramatizations of big software development launches, but maybe it's in the top ten. Find yourself a copy while you still can.

Tracking AJAX calls with Google Analytics (and Rails)

With my recent pet project I used AJAX to provide a majority of the site functionality on the main page with it never having to reload itself or load another page. This resulted in a drastic drop of "page" views in my Google Analytics reports, because the only "page" being loaded on each visit was the sole main page; every click after that was an AJAX call to update only a portion of the already loaded page, hence not triggering any calls back to the Google Analytics tracking server. So I set out to see if I could remedy that, and I did.

I started out with a Google search for assistance. Surprisingly, the results were grim. The highest ranked result required a "donation" to read the answer, and I opted not to. Other results were vague or dated or focused on the same issue with Flash. I had to crack open the code and get my hands dirty.

When you set up a profile to track with Google Analytics, they give you a little snipped of JavaScript code to paste into your website pages. It looks something like this:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-1377203-6");
pageTracker._trackPageview();
} catch(err) {}</script>

Seems cryptic enough, right? If you look closely you'll see it's actually two scripts, not one. The first script imports the Google Analytics tracking library:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>

And the second script calls the library to track the page.

<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-1377203-6");
pageTracker._trackPageview();
} catch(err) {}</script>

In order to track a page load, including an AJAX call, you merely need to call the tracking library, but you need to import the library only once. That's where things get a little tricky.

For starters, I separated the two scripts into their own respective partials. I render both partials on the main page, so the library is loaded and then called to track the page load. However, from the AJAX calls, I only render the second script, the one that calls the library, since it will have already been loaded by the main page.

Here's the first curve ball. The first time I render and serve the main page, the AJAX-y portions of the page are rendered in-line. Since each of them in turn renders the call to the tracking library, the loading of the main page could erroneously track several hits. In order to prevent this, I wrapped the script with a global flag check and set, so no matter how many times it's rendered for a single page, it only injects the script once:

<% unless @already_tracked %>
<% @already_tracked = true %>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-1377203-6");
pageTracker._trackPageview();
} catch(err) {}</script>
<% end %>

The second curve ball is that you need to render the first partial - the one that loads the Google Analytics library - at the top of your page, rather than the bottom as Google recommends in its documentation. I put mine immediately inside the body tag. Why? Because the first partial, with an embedded tracker call, to render on the page is going to try to call the tracking library when the browser processes it, and if the tracking library isn't yet loaded, the call will silently fail (thanks to the try/catch block).

Now that the main page loads the tracking library, and the HTML snippets returned from the AJAX calls in turn call the already-loaded tracking library, each AJAX call is tracked as a page view on your Google Analytics report. Note that this solution is specific to AJAX calls that inject pre-rendered HTML into the page. If you need to track AJAX calls that deal with behind-the-scenes processing you should be able to simply make the same JavaScript calls you see in the second script; wrap them up in a helper function for convenience.

How to Launch 2 Sites in 20 Hours

Since I "became independent" exactly two months ago to the day, I've launched two pet project web sites: Pocket Rails and Rate Marina's Outfits. I tracked my time on each, just like I would for a billable client, and oddly enough they each took about twenty hours from inception to launch. Turns out it's pretty damn easy, and cheap too. Here's how I did it.

Get organized

I'm a "to do" list guy. Everything I do on a daily basis centers around "to do" lists. Whenever I think to myself, "I need to..." it goes straight on to the list. For these two projects I used Ta-da Lists. I created a new list for each project, and started adding "to do" items as I thought of them, and checked them off as I completed them. It's a great way to ensure you don't forget anything, nothing falls through the cracks, and it gives you a decent visual representation of your progress and how much you have left to do.

Get a domain

The first thing you need is a domain name for your site so people have a way to surf to it. You don't necessarily need a separate domain for every site; you can can host several sites on a single domain via sub-domains. For example, I registered anachromystic.com for my company then hosted one of my projects at marina.anachromystic.com.

I get all my domain names through GoDaddy. It's usually the cheapest, and it's convenient to manage them all through a single central service. If you plan on sending/receiving e-mail through the domain, I strongly recommend Google Apps for Business. It's dirt simple to set up, their tutorials cover every major registrar, and requires no maintenance.

Get a host

As the name "pet" project implies, these sites are hobbies. They are not generating any money, and it's not critical that they be up all the time and fast to respond. So I went with the cheapest host I could find, DreamHost. Pull up Google and search for DreamHost promo codes and try all the ones you find. I ended up getting an entire year of hosting for about $20 (that's for the entire year, not a monthly rate).

Choose a platform (Hint: Use Rails, dummy)

Not only is Ruby on Rails the best platform for getting a site up and running quickly, you can get a head start with a "base" application like Bort which comes with a plethora of pre-shaved yaks including registration, e-mail activation, log-in, password reset, pre-configured routes, deployment scripts, etc. It's not perfect - I had to tweak it a bit - but it saved me hours of laying the groundwork and let me get to the meat of the project quicker.

Use hosted source control

Why hosted? First of all, it's essentially a cheap back-up of your work. Secondly, it makes it a lot easier to collaborate if you're working with other developers. There's a billion to choose from, and if you're willing to let other people see your code, they're free. I decided to make the source for Pocket Rails open but keep the source for Marina private (for now). I'm a huge git fanboy so GitHub was the natural choice for me. My open-sourced projects are hosted for free and I pay a measly $7 per month for the privilege of keeping some of them private.

Test all the fscking time

If you aren't test infected yet, it's time to wake up. Testing demonstrates that what you've written works, and testing ensures that when you modify or enhance it you don't break any of the old stuff. Don't let yourself fall into the quagmire of, "I'll add testing later after I get everything working." You'll waste endless hours of debugging issues that could have been prevented with preemptive testing. But don't take my word for it, take the word of Bryan Liles.

Also, on a somewhat related note to testing, use one of the plug-ins and accompanying services like Hoptoad or Exceptional to track and alert you when something breaks on your site.

If you want to get hard core, and why not, install the New Relic plug-in which will track and report on the performance of your application, so you can find out where the bottlenecks are.

Automate deployment

Get automated deployment working from the get go. Don't save it for the end. You should be able to deploy your site from your hosted source control to your hosting provider with a single command. Capistrano is the tool for the job if you're using Rails. Open up a terminal window and type "cap deploy" and watch it all unfold. If that one command doesn't do everything you need it to, make it! For example, I deploy a lot, and Capistrano doesn't clean up after itself automatically, so I hacked it to run the "clean" command after every "deploy". It also doesn't run database migrations by default, so I added the "migrate" task to "deploy" as well. When you can update your live site with one command, you'll sleep better at night.

If you build it, they will come

Well, they wont actually come until you promote it, but that's a later section. Once I had all the aforementioned steps in place, I buckled down and coded. My Ruby and Rails skills were a little rusty, so I'd occasionally have to visit a documentation site like APIdock or search for an issue on Google or as a last resort post my problem on gist then tweet the link on Twitter (thankfully I have quite a few smart and helpful Rails guys following me).

Package your dependencies

Don't expect your hosting provider, or the next developer to work on your project, to have all the necessary third-party dependencies for your project. Package them up with your application if possible. In Rails this is pretty simple, just declare the gem dependencies in your environment.rb file then rake gems:unpack to extract them locally. Do it for Rails itself too, and don't forget to add them all to source control.

Track it

If you want to know how many people are visiting your site, how many pages your site is serving, which page is the most popular, etc., you need to track it all. The quickest, easiest, and cheapest way I know of accomplishing that is Google Analytics. Create a profile for your site and they will generate a little snippet of JavaScript code to paste into your pages. Assuming you have a template that's common to ever page on the site (like a header or footer), that's the logical place to put it. Google will track everything for you and give you some super slick reports.

Tell people about it

Once you've got your new site coded, tested, and deployed, it's time to draw people to it. People aren't likely to find it on their own, so you need to announce it. With Pocket Rails I first started tweeting about it on Twitter. This attracted a few visitors and provided some initial feedback. Once I'd ironed out a few kinks I shot an e-mail over to the guys as the Rails Envy Podcast explaining what I'd built. They seemed to like it and mentioned it on their show. That drove a sizable burst of traffic which quickly died off. A week later I posted the link to reddit for ruby hackers and holy macaroni the site was deluged with visitors, and I began to see other people talking about it and linking to it thanks to tools like Google Alerts and Twitter Search. I added their RSS feeds to my news reader so I can keep on top of the chatter.

Finally, blog about it

Hey, my blog post about launching your site is recommending you blog about launching your site. How meta is that? It makes my brain hurt a little. But seriously, share your story so others may learn from it, as I hope you've learned something from my story. I'd love to hear your comments and criticisms, perhaps you'd have done something differently.

Rate Marina's Outfits

Yesterday I soft-launched my latest pet project, which I wrote on New Year's Eve of all nights, with graphic design graciously contributed by Allan Branch of Less Everything.

What is it? Well, for those of you too lazy to click the link, it's essentially a mash-up of YouTube and the Ajaxful Rating plug-in for Ruby on Rails that lets you rate the outfits worn by Marina Orlova on her popular webisode sensation HotForWords.

Why did I write it? To get rich and famous, of course, right? Ha, no. I wrote it because I've been interviewing for new gigs the last couple months and I keep getting asked for sample code that I've written. All the projects I've worked on for the last decade have been private and proprietary code bases, so I can't share them. Now I have something to share. For now I'm only sharing the code with potential employers, but I do plan to release it to the public in the very near future.

If you like what you see and you're looking for a solid developer (remote only, sorry, no relocation) please give my resume a peek. Thanks.