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?

This complete, I pushed the Mac OS X Snow Leopard Family Pack upgrade disc into the drive, and after a quick read, I’d signed away my life to Apple, pressed the install button, and found something else to do for the next hour.

I’d checked that all my key applications were compliant with Snow Leopard before I started, so the mainstream upgrade process was pretty painless: very promising for my chances of surviving my next upgrade.

I also remembered to install Xcode and the developer tools, vital for the next step.

The Pain of the Developer.

The problems started with the developer environment I’ve become accustom to using: PHP and Ruby. I started to wonder whether a clean install might have been a better idea.

I’m happy using the bundled Apache and PHP at the moment; these have been upgraded to versions 2.2.11 and 5.3 respectively, so there’s no major drama until they need to connect to MySQL.

Conversely, I prefer to build the majority of my tools from source in the /usr/local directory: MySQL, Ruby, RubyGems and Git.

Dan Benjamin has a great set of posts to help you do this, but he starts with a clean install, and if you’re upgrading it might not go so smoothly. Here are a few pointers gleaned from the Web and personal experience.

A new MySQL build.

I’ve been using version 5.0.51a for a while and decided to upgrade to 5.1.39 as part of the whole process. The first step was to create a dumpfile of the old database to upload into the new version:

mysqldump --opt -uroot -p --all-databases > currentdatabasedump.sql

In my experience, following Dan’s instructions gives great results, but I install each version into its own directory and symbolic link the one I want to use:

lrwxr-xr-x 1 root wheel 12 28 Oct 16:05 mysql -> mysql-5.1.39 drwxr-xr-x 12 root wheel 408 28 Oct 13:24 mysql-5.0.51a drwxr-xr-x 10 root wheel 340 28 Oct 16:07 mysql-5.1.39

Now to load the old databases into the new management system, so I logged in as root:

mysql -uroot

notice there’s no password yet, and from the mysql command line I loaded the contents of the dumpfile:

source path/to/dumpfile/currentdatabasedump.sql;

Finally, the databases need to be checked for incompatibilities and upgraded:

mysql_upgrade

and the database was acting like the old one, with the expected users and passwords assigned.

Why PHP still can’t use MySQL.

Snow Leopard doesn’t come with a php.ini file, so I copied /etc/php.ini.default to /etc/php.ini, but this file still needed a little modification to work with MySQL.

I changed all the occurrences of /var/mysql/mysql.sock to /tmp/mysql.sock, restarted Apache and my local WordPress installations were back in action, but MediaWiki wasn’t.

At this point the irony of having my troubleshooting notes in the form of a local wiki struck home, fortunately an upgrade to MediaWiki version 1.15.1 solved the problem.

Building Ruby, Rails and Gems.

I based my attempt on Dan’s instructions, and this time I was greeted by a series of make errors from readline.

Rob Seaman sums them up nicely and making the suggested adjustments to config.h allowed me to complete the installation.

I also tried to uninstall readline, but this only resulted in more errors, so pragmatically I upgraded to readline 6.0, and stuck to with the file modifications; must solve this problem one day…

Back to Dan for RubyGems, and installing the MySQL gem, and the first leg of the job was complete.

Rebuilding all the other gems.

Time to upgrade every gem, and gem update won’t do the job, they all need to be reinstalled. I picked up this handy line of Ruby code that can be run in irb from Victor Costan’s blog:

gem list.each_line {|line| system "sudo gem install #{line.split.first}"}

It executes the gem install command for every gem on your existing local list, and it was at this point that I noticed that the arrow keys were behaving strangely in irb.

It turns out that the readline extension isn’t installed along with the rest of Ruby:

cd /usr/local/src/ruby-1.8.7-p174/ext/readline ruby extconf.rb make sudo make install

should fix the problem.

The fly in the ointment.

Everything was going great, but whilst building the Nokogiri gem I ran into more errors. As Roger Neel worked out, I also tracked the problem to MacPorts, and the thing is that I can’t remember why it’s installed in the first place! So I took a risk, cloned first of course, and removed all traces of MacPorts:

sudo port -f uninstall installed

No good, MacPorts was too broken to uninstall itself, so next I took the direct approach:

sudo rm -rf /opt/local \ /Applications/MacPorts \ /Applications/DarwinPorts \ /Library/Tcl/macports1.0 \ /Library/Tcl/darwinports1.0 \ /Library/LaunchDaemons/org.macports.* \ /Library/StartupItems/DarwinPortsStartup \ /Library/Receipts/MacPorts.pkg \ /Library/Receipts/DarwinPorts.pkg \ ~/.macports

Gone, and with it the Nokogiri compilation errors, I can’t help wondering whether I’ll regret this step later… when I figure out why I installed it in the first place.

Building and installing Passenger.

Like all the gems, Passenger needs to be rebuilt using the new gcc compiler bundled with Xcode. My original Passenger configuration file disappeared from the /etc/apache2/other directory during the upgrade, so I made a new one:

-r--r--r-- 1 root wheel 73 18 May 20:44 bonjour.conf -rw-r--r-- 1 root wheel 287 28 Oct 20:06 passenger.conf -r--r--r-- 1 root wheel 194 18 May 20:44 php5.conf

This file contains the configuration instructions given at the end of the Passenger installation invoked by:

passenger-install-apache2-module

And Git.

Followed Dan’s recommendations and there were no problems.

I’ve used Ruby for scripting, and deploying PHP applications with custom Capistrano recipes for years now, but I’ve never tried any of the available web frameworks.

This week I switched to Ruby on Rails, and I’ve accomplished more in a couple of days than in a couple of months with CodeIgniter.

I’m not trying to claim that there’s anything fundamentally wrong with PHP, so don’t beat me up over it, but I find working with Ruby and Java much more intuitive, enjoyable and productive: it’s a personal choice, I feel more inspired.

I’m particularly loving the default support for unit, functional and integration testing; I now feel in control of my code and I’ve yet to explore the full range of testing frameworks and approaches available for Rails.

I know that CakePHP mirrors Rails functionality very closely, but I’m afraid it’s the PHP language that I find too ugly to love – personal choice again, don’t shoot – consequently this is one developer who may have written his last line of PHP code…… maybe.

I’m now hoping to have the first release of the nature and wildlife recording application I’ve been promising Clare for…… much too long, up and running in the next couple of weeks.