There’s no better way to learn a new language than to actually use it in real life. My Nature Notes started as a project for my partner in PHP, CodeIgniter actually, but progress was slow due to an enjoyment deficit.

Testing is the main reason that I grew unhappy with PHP, most of the tools were there, but the integration was patchy: the basics are all there in Ruby and it’s associated development frameworks and integrating new packages via ruby gems or plugins is simple.

I started using the built-in Rails testing tools, but for no particular reason I’ve moved on to RSpec for unit and functional Rails model and standalone Ruby code testing coupled with Cucumber based integration testing. I’ve found that I need both.

Cucumber tests try to exercise the whole software stack – views, controllers, models and even the database. The use of natural language makes it easier to translate user stories into the appropriate tests, though it still needs some discipline to ensure that the edge cases are covered: I don’t think clients could write these as acceptance tests.

Involving the whole stack makes tests a little brittle, how specific is too specific? I’ve managed to break tests by removing fullstops (periods) from the rendered HTML!

I think that this is where unit and functional testing with RSpec at the model level is indispensable. I test model associations, validations and custom business logic in that order, I draw the limit at all the ActiveRecord CRUD functionality.

I’ve found that the development environment hasn’t really changed in the move, the same basic toolkit does PHP and Ruby.

I regularly use several code version control systems including Subversion, Git and Mercurial. Recently though I’ve increasingly turned to Git and GitHub. Like most good tools the more you use it the more attached you become, so I’ll have to force myself to use the equally fine Mercurial again soon. I love these distributed tools.

TextMate is my editor of choice for Rails development. I’ve tried to use Netbeans IDE, I use this for Java, but it seems like overkill. TextMate is quicker, simpler and provides the tools I need via the a range of bundles.

I have to admit that the code syntax highlighting is the most useful feature because I like using the command line too much, but I’m increasingly using code completion and I’m going to try the Zen coding bundles for HTML and CSS, I don’t like the default tools much.

That’s a round up of my current practice, more about the resulting software once I’ve decided to move on to a public beta.

It feels like I’m starting from the top of the software stack and working down from broad specifications, creating code as I go, rather than up from fine grained models based on specific unit tests. Is this a reductionist approach?

When writing my features and scenarios I’ve noticed a tendency to follow the CRUD acronym common in data access layers: Create Read Update and Delete. The order of these processes is significant and my reasoning goes something like this……

I can’t really expect to read the contents of an entity before I’ve generated the code to create it. Now I’ve created it, I’m not going to try to edit this same entity unless I can actually read it. I can read what I’ve got, but I might want to edit those contents, and delete comes last…… because it just does, I guess the order of “UD” is negotiable, but this way it’s easier to pronounce.

You get the general picture, but this is just the approach I’ve adopted through trial and lots of error. It’s far from perfect, so how do you use behaviour to lead the code?