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:
- Write the spec for a small piece of code
- See spec fail (since the code doesn’t exist yet)
- Write the code to pass the spec
- See spec pass
- 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.
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.
I’ve been tossing around a web app idea in my head for a while now, but I’m finally getting serious about it. It’s called GoRunNow. The basic idea is it will track running data for, well, runners. I took up running about 6 months ago, so that was the impetus for the idea. In a fit of insanity I purchased the domain name for it already, so that much is for certain. I’ve got some (hopefully) interesting features and twists that I’ll save for some future posts.
Rather than throwing it together though I’m taking a slower approach. I’m wanting to flex my UI and design muscles a bit, which don’t get exercised as much as I would like on the day job, so this app will sort of be like my gym for that… slowly building up to the heavy lifting.
I’ll post updates on the entire process. We’ll see where it goes.
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…
Gary Vaynerchuk has this great video about “having both jobs”. In a nutshell, having both jobs means you can work the day job AND still pursue your passion or dream job in the evening. Of course, it takes hard work and sacrifice, which is what nobody wants to hear but is the simple, indisputable truth of building anything.
In the blogosphere, I rarely find posts that deal with “struggle”. I think that’s a shame, too. People deal with their struggles in private and post from a position of authority in public after the fact. But, you know, I’d really like to read about the struggle part, because I sure have a lot of them. I want to read about how some guy totally sucked at something or got his ass kicked and then read about the steps he took to not suck so much…and not get his ass kicked. To me, that is not only real, but valuable.
This comes from a post up on Hacker News today. It’s addressing programming blogs, but it sparked a more general thought, mainly that “blogging” has changed since it first hit the Internet scene.
It’s probably not a big revelation to anyone who spends a lot of time online, but that quote helped define something that’s been lurking in the back of my mind, especially now that I’m writing my own blog.
Early blogs were more personal diary. People shared thoughts and feelings, bad writing and uncomfortable revelations included. Although they revolved around certain topics, some as “emotionless” as programming, they still had a very personal tone. Now it seems as though most blogs I read already have all the answers worked out before they even write the post. It’s more about building up your readership or appearing as an authority on some topic. Admittedly all this is very much my personal perception and dependent on the particular blogs that I’ve frequented over the years.
Maybe what I’m really getting at is the general commercialization of blogging. Obviously a lot of “blogs” aren’t really personal web logs anymore, but media machines for generating readership and ad dollars. Even a lot of “personal” blogging advice seems to be more geared towards creating a nice neat package for your readers. And there’s certainly nothing wrong with that. We certainly need well thought out writing and everyone I think should strive to communicate their ideas well, regardless if it’s programming or cooking or talking about your kids.
I guess what’s missing to me is the “story”. We have more bloggers writing posts that read like cold tutorials or instruction manuals. This seems especially true in the programming circles. Everybody has their pet language or framework or technique or opinion that they’re pushing for Google juice.
Maybe I’m just bitter. Maybe what I’m feeling is actually more personal. Admittedly I’ve had a hard time figuring out what I want this blog to be about. I oscialate between some kind of programming blog and some kind of personal “I ate pizza for dinner” blog. Of course, all of this really seems kinda pointless when I consider I have 0 readership :)
The title of this post comes from a Sufjan Stevens song I was listening to on the train this morning. The line has always stuck in my head, but I’ve never been quite sure what it means. I guess there’s the obvious interpretation… and maybe that’s really what I’ve been missing and what I’m getting at… the obvious. Blogging is interesting because it’s people and it’s stories and it’s struggle and revelation. It’s the combination of all these things, and to take away the struggle is to take away the tension. It’s like giving away the ending at the beginning of the story.
My sister and her fiancé (Congratulations!) gave me Radiohead’s In Rainbows on vinyl for Christmas. I love the music itself (possibly one of my favorite Radiohead albums now), but I’m equally impressed by the way it sounds. The pop n’ crackle goes great with the music itself, plus there’s an extra depth and quality of sound. Maybe it’s the thicker, 180 gram vinyl. Whatever it is, I love it. It’s got me looking at some of the Radiohead re-issues on 180g vinyl now.
I’ve also been listening to all my old LPs, 10 and 7 inches. I never really considered myself a vinyl enthusiast, but there’s definitely something special about the sound and experience of listening to music on vinyl.
There’s a blog post from Errol Morris up at the New York Times where he asks the head photo editors from 3 of the big news wire services to choose their favorite photographs of President Bush. The pictures and commentary are both equally good, and many of the pics I hadn’t seen before.
One of the most striking to me was near the end, a single closeup of his face, crying at the Medal of Honor ceremony for a Marine killed in Iraq.
“It wasn’t often that you saw George Bush become emotional and cry in the course of his presidency and as far as I remember, this was the first time that anyone saw him shed tears specifically related to casualties and the events in Iraq.”
I have mixed feelings about the war and Bush and his presidency overall. All of that aside though, this picture to me captures the immense weight and gravity of what it means to be Commander in Chief and still (just) human. And with Bush, whose humanity might be both his greatest asset and flaw, it comes through all the more clearly what a terribly difficult job it must be.
