No One Thing

No, it’s not an application feature - it’s new content. I’ve posted my first guitar gear review! And I’ve already got a second item lined up.

Of course, in my rare spare minute, I’m still working on added features for GuitarCardio.com - I think mode-based drills will be next.

I love that Mac OS X is really BSD under the hood, but sometimes it causes unexpected pain. More than once I’ve tripped over the differences in date between Linux and Mac OS X, and over this weekend I’ve had trauma with sed.

Specifically, if I have a single character I want to replace in a file - like replacing an out-of-band delimiter in a flat file with a TAB character - I’d normally say sed ’s/\d197/\d009/g’ < foo > bar. Sadly, this doesn’t work with Mac OS X’s sed.

Ruby to the rescue, in the form of my own sadsed.rb:

#!/usr/bin/env ruby

f = File.open $*[0]

until f.eof?
  puts f.readline.strip.gsub(/\xc7/, "\t")
end

And then just ./sadsed.rb foo > bar and away you go.

And for the record: I’m dealing with some big files, and Ruby’s Regexp is pretty snappy.

Yesterday, I spent more time dealing with the getting floated page elements to look right than I care to admit. I am not kidding when I say that I found quantum mechanics more intuitive than I find CSS floats now.

Of course, I put more effort into studying quantum mechanics. And maybe there’s some similarity here - once you learn a few hairy rules and what they really mean, the weird results make sense.

That was more gripe-y than educational. I’ll post something meatier next time.

I’ve deployed a shiny new user profile feature at GuitarCardio.com, visible details of which are described in the relevant blog entry.

As for the under-the-hood stuff, the Restful Authentication Plugin made it embarrassingly easy.

Late, late. Must sleep now.

As I mentioned previously in this space, I’ve written a web app called GuitarCardio.com. Of course, posting about it here informs nobody but a few family and friends, and then only a few days later when they get around to checking the site. Likewise with my Twitter feed (which as an even more circumscribed set of people who care), Facebook, etc.

I also post to a few guitar-related blogs and fora, and I got a few hits from that. It’s not lots of traffic, but the people who came were at least interested in the topic.

The other night night, on a lark, I put GuitarCardio on StumbleUpon, which is a neat little tool for finding new stuff on the web. Within hours, I had over 5,000 new visitors. In the past 48 hours, it became over 12,000 new visitors, many of whom were staying at the site. GC peaked at #2 on the del.icio.us popular links, and made the front page of popurls. People actually gave pleasant, useful comments on the blog, and I got linked on Twitter and on multiple blogs.

I’m not so much bragging about any of this, but more expressing how agog I am at the whole notion. It had not occurred to me that any of that stuff might happen.

The even better news is that the site stayed hyper-responsive (within the limits of a good shared host) through the whole traffic wave. A few 500 errors or “sorry, my database is bogged” messages, and you’ve dug a pit of negative goodwill from which your site might never emerge.

So, lessons learned:

• The site stayed responsive in part because currently there is no database component to the site (though this will change soon). Response codes for every one of the tens of thousands of requests over the past 48 hours have been either 200 or 302 - no 500’s, which is the bane of Rails apps on shared hosts.
• I host no graphics on the page, which I think also helped performance. It is possible to make an eye-catching design with just HTML and CSS.
• If you’re going to use a service like StumbleUpon, be ready. If my site weren’t able to handle the traffic, I wouldn’t have been able to do anything about it from work yesterday morning. I kind of lucked out there, due to my minimalist design decisions.
• Services like StumbleUpon can work for you, if you’ve made something people actually want.

All the activity was really a surprise to me, as this is the first time I’ve put something (of my own, anyway) on the web that anyone I don’t know was actually interested in. (This is no great surprise - my interests and priorities intersect with those of the general population only rarely.) So thanks to all those who did care enough to say something nice about GuitarCardio - who voted it up on StumbleUpon, and who tweeted, blogged, and bookmarked it.

Now, I need to digest some of the great feedback I’ve gotten on the GuitarCardio blog, pore over the Google Analytics data, see how my ads performed, &c.

And then, I’ll be making the site even better. The GC blog will cover the features I add and when I’ll be unveiling them, and I’ll be posting about technical lessons learned here.

w00t!

Let’s say you have a class Foo:

class Foo
  THE_CONST = 'parent_const'

  def get_val
    'parent_val'
  end

  def show_const
    puts THE_CONST
  end

  def show_val
    puts get_val
  end
end

Further, let’s say you have a class Bar, derived from Foo, that redefines a couple of things:

class Bar < Foo
  THE_CONST = 'child_const'

  def get_val
    'child_val'
  end
end

It seems kind of obvious that:

f = Foo.new
f.show_const  # => parent_const
f.show_val    # => parent_val

But would you have guessed that:

b = Bar.new
b.show_const  # => parent_const WTF!?!?!
b.show_val    # => child_val

This caused me no end of headaches during a weekend bout of refactoring. Pushing default constants up to the parent class completely hosed me up in those child classes that tried to override them. Overriding dumb getter methods that just return constants, though, works fine.

I’m sure there’s some computer-sciencey reason for this that Matz could explain to me, but I had really expected the every-call-is-a-message nature of Ruby to handle those two cases more consistently.

One of the coolest things about Rails is Migrations - the database-agnostic framework for building and versioning your database. A conversation at work today spawned a bit of googling which led me to a nice-looking Java equivalent: Migrate4j.

Share and enjoy.

This gets a little into the psychology of programming, at least as it applies to me.

Here’s why I’m a fan of Test Driven Development: When I’m adding a new feature - especially a new decision branch - and I’m not doing TDD, I will often only test the “happy path”. That is to say, I check what happens with the expected/normal inputs, and rationalize to myself that the change is small, and the likely error conditions are already handled. (Yes, I know. But if you’re reading this, chances are that you do it to.)

In contrast, when I’m doing TDD, I tend to triangulate compulsively, check boundary conditions, and generally dream up piles of test cases that would never come up if I were doing code-then-test rather than test-then-code. I suspect it has to do with the fact that writing an automated test at the beginning is far cheaper than spending my time clicking through every possible bad input in my UI, to say nothing of manually mocking up all the possible defects in a GET or POST request. I even find it kind of fun to spend a few minutes thinking up new edge cases for my code to handle gracefully.

And when I’m done, that code never gets deployed in a broken state again - at least for the paths I’ve tested.

As an example, consider putting your site through an invitation-only beta period. Perhaps you’re using something like Restful Authentication or some other prepackaged user signup & login code, and you have to add on the invitation validation process as a bag on the side. (In fact, you want to implement invitations as a separate model and code path so that you can easily cut it out later when the site opens to the public.) So you throw some extra code into the signup process to check a submitted invitation code, boot the user out if the code is invalid or used, and mark it as used if the signup is successful.

What if the signup is not successful, because the user put in a mismatched password and password confirmation? Does the invitation code get marked as used anyway, thus booting the user out and confusing him when he submits the form a second time with corrected input? That’s the kind of path that I often wouldn’t (and I’ll admit here: didn’t) think to test manually if I’m just coding away, but would take me 30 seconds to code a test case for when I’m working test-driven.

And that’s why I’m going to try to stay more disciplined about test-driving my development.

I had recommended Sitealizer (a Rails plugin) to a friend for monitoring stats on his website. Normally, I consider Sitealizer to be a pretty slick package - it has everything a smaller site needs (uniques, referrers, search terms, breakout by browser, etc.) and not a lot of cruft.

The downside: It appears that under certain conditions - like if you’ve used the standard deprec deploy (at least using the instructions at Slicehost), where Mongrel serves the app and Apache talks to the outside world - Sitealizer records all incoming IP addresses as 127.0.0.1. Not good.

And when the choice comes down to debugging the interaction of someone else’s code with arcane configuration issues or just going with Google Analytics? Sorry, Sitealizer..