SwirrlSpeak

Swirrl is built on Ruby on Rails. For the ininitiated, Ruby on Rails is an open source web development framework originally created by David Heinemeier Hansson (commonly referred to in the Rails community as DHH) from 37signals, and then extended by open source contributors.

Initially we chose Rails mainly as it was free and open source, something that makes a big difference to a cash-strapped young company, and because of its reputation for ease and speed of development. But it was also a great chance to start afresh with something a bit different (I had been a Microsoft .NET developer in my former life), and to see what all the hype was about. Additionally, due to the kind of problems we are trying to solve (i.e. the ability to work with virtually any kind of data), we thought that Ruby’s combination of power, conciseness and freedom might come in handy.

When we started out with Rails, we had to get used to coding to Ruby’s strengths i.e. mixing in functionality to classes with modules, rather than using strongly typed inheritance (although ‘classic’ inheritance is supported in Ruby, and does still come in useful sometimes). It also took a while to get used to, and take advantage of, certain ruby coding idioms. This was especially true when trying to read and understand Ruby code from third parties (which I’ll come back to shortly).

Since starting out on Swirrl, it has changed direction several times but Ruby and Rails have made these U-turns less painful than they could have been. Rails actively encourages thorough testing by making it easy to write tests for your code and as such Swirrl has a lot of test-code. This makes it easy to tell what parts of the application any changes have affected. The flexibility of a weakly typed, run-time interpreted language does has it’s disadvantages in some respects, though, as theres no compilation step to catch coding or refactoring errors. This means that tests are heavily relied upon, so it’s great that Rails makes testing so easy (and, dare I say, enjoyable).

Rails is ‘opinionated software’ (which is no surprise, given that it came out of DHH’s brain). This means that many coding decisions have already been made for you, the developer. Now, it is possible to override these defaults if you wish, or if your particular problem requires it. But on the whole it means that your mind is freed up to concentrate on more important matters (i.e. your application), rather than wasting time deciding what to name something, where to put it in the project structure or writing boilerplate code. With Rails, you trade flexibility at the infrastructure level to gain freedoms at the application level. Some programmers don’t like curtailing their personal expression, but I agree with DHH when he says that a more uniform code-base and seeing your application work in a short time is a very concrete, rewarding goal (Surely that’s the whole point of this coding-lark, anyway!?). As Jamis Buck (a member of the core Rails team) recently said, if you find yourself thinking too much about something, you should stop yourself: just get something real in place and you’ll find that a lot of your imagined problems evaporate anyway. Rails helps in this regard by removing one more obstacle to getting things done.

The Rails community, and the open source community in general are, in my opinion, among the main factors that have helped Rails enjoy continued growth and success. Reinventing the wheel happens less often than in closed environments and everyone benefits from people sharing their solutions to common problems, in the form of plugins, gems and blog posts. This is also a great way to get yourself or your company noticed, and to give something back to the community. For example, I wouldn’t have heard of Rick Olson, Josh Goebel, Thoughtbot, Err, Robby Russell’s Planet Argon, or even 37signals (to name but a few) if it wasn’t for their contribution to Rails and open source. Participation from parties like these mean that Rails and its related technologies seldom become stale: everything is constantly evolving and steadily moving forward. Even deployment and production-runnning have their open source solutions, in the form of Capistrano, more recently Phusion Passenger, and of course Ubuntu (and other linux flavours).

Becoming involved with Rails has also introduced me to the world of Apple Macs. Being a former Microsoft .NET developer, I had previously only known Windows environments. I know that Apple may seem about as far from open-source as you can get, but many of the tools that the Rails community use are Mac-based, and being a unix-derived environment many of the settings, configuration and commands are directly transferable to linux, Rails’ production platform du choix. Besides all that, Macs have an unquantifiable feel-good factor (for me, at least) that actually makes turning on the computer in the morning something to relish, rather than dread.