I’ve moved to Disqus for comments. I like their interface and the way comments and commentators can be tracked across blogs, articles and discussions. I created my first Rails plugin in the process too, but I’ll save that for another post.

I came across this article this morning via Hacker News. In a nutshell, the authors are using a custom framework for their new site consisting of empty, static HTML templates which are then populated with data on the client side using JavaScript to fetch JSON from the server.

This is a really cool idea, not without caveats and problems that still need to be solved, but I like the core idea. Now that we’re all Web 2.0 with dynamic page updates via AJAX/JavaScript, managing the initial page render of template plus data on the server side PLUS handling the JavaScript/JSON requests requires careful planning and architecture to keep everything DRY and maintainable. Even with some of the best constructs out there (I favor “respond_to” from Rails, but I’m sure there are others), it still just feels dirty to me.

Of course the biggest question is what if the client doesn’t have JavaScript enabled, which most notably includes search engine crawlers. And I don’t have an answer for that, but as we continue to move forward and see JavaScript performance improve and become such an integral part of the modern browser I wouldn’t be surprised if this problem doesn’t solve itself. It seems to be one of the fundamental questions facing the future of the web, how do move forward on a platform that was initially designed to be document centric but which has given growth to dynamic applications? We have a lot of incremental solutions, and I think we’ll continue to see these, but at some point will we get an evolutionary step forward?

I can feel this post quickly tumbling down the rabbit hole, so I’ll stop there…

While working on GoRunNow this weekend I ran headlong into the issue of foreign key constraints in Rails. In short, the creation of foreign key constraints is not supported by Rails out of the box. (There are plugins to add support, but I’m trying to keep my plugin usage to a minimum.)

Of course, you can execute raw SQL in your migrations via the execute method, which is what I initially did. The surprise came when I started writing specs and discovered the associated model could be saved without the foreign key. I was expecting the database constraint to prevent this.

After an hour of head scratching and digging I discovered the catch is your test database gets created from schema.rb, which is generated via inflection on the database schema after migrations are applied. It’s not based on the migrations themselves, so those foreign key constraints created via execute are sneakily left out of schema.rb.

From what I’ve read the reason for doing this is speeding up tests, which makes sense, but it was rather surprising behavior for someone new to BDD in Rails.

Since starting my new pet project, I’ve been experimenting with a more BDD style method of development. In particular, I’ve been following the typical BDD development loop:

1. Write the spec for a small piece of code
2. See spec fail (since the code doesn’t exist yet)
3. Write the code to pass the spec
4. See spec pass
5. Repeat…

I won’t go into details on the “why” for doing development like this. There’s a lot of information, arguments, rebuttals, etc. out there. I’m just going to highlight some of the key benefits I’ve seen thus far.

Ruby on Rails
This is probably obvious to anyone who’s taken even a cursory glance at Rails, but it’s worth mentioning. Ruby on Rails as a framework and as a developer community has excellent support and attention to both test and behavior driven development. Test driven development is supported right out of the box, and behavior driven development is easily integrated via Rspec and Rspec for Rails. It’s worth mentioning because once you go back to a framework (or language for that matter) that doesn’t help you practice TDD or BDD (I’m looking at you Java/J2EE), it’s a big deal. Yeah, I know you can (and should) practice TDD/BDD in Java/J2EE, but it doesn’t have that momentum.

RSpec and RSpec for Rails
RSpec was the first framework for BDD in Ruby, so there’s a wealth of information out there for using it. There are other frameworks and some amount of noise in the community about what’s “best”, but I’ve been happy using RSpec and RSpec for Rails thus far.

ZenTest / autotest
The autotest gem (part of the larger ZenTest suite) watches your source tree and runs the relevant tests/specs for you automatically as you update individual files. If a test/spec fails, the command line output goes red. If it passes, it goes green. Simple, but very effective.

For me, autotest has been the key to making this style of development work. Next to my emacs window, I have a terminal running autotest in a tiny font (so it doesn’t take up a lot of screen real estate). When I write a new spec and save the file, I see the failure in a few seconds. When I write the code to pass the spec, I see it pass in just a few seconds as well. Thus it makes this whole development cycle much faster since steps 2 & 4 above are completely automated and I see the results of 1 & 3 almost instantly.

After doing development like this for a few weeks now, it pains me to go back to the old lengthy write/compile/test(manually) loop. Using this BDD method of development, I find I’m much more focused on all the details of my code… structure, brevity, quality, organization… rather than just getting something that works. Some of it is related to the benefits of behavior driven design and development, but a lot of it is that I can stay engaged (yeah, I’m talking about flow). No waiting for compile loops or opening browsers or bouncing around checking logs, etc. I’m able to write and test/spec a large amount of code w/out ever taking my hands off the keyboard.

It has taken a little while to learn the ropes and all the tricks for spec’ing code. It was frustrating at first because I was spending a lot of time writing specs and very little time writing my application, but now that I’m becoming more familiar with how to spec my code that has dropped considerably. Like a lot of expert power tools with a high learning curve (like vim and emacs), the payoff is really high once you get the hang of it.