If you’re in Adelaide (South Australia) and have experience in Rails, Katalyst are currently looking for developers. We’re a small team, specializing in custom web development and interactive media. You can get a bit of an idea of what we do from the Katalyst website.
If you’re interested, send a CV to jobs@katalyst.com.au.
I’ve recently bought myself a wonderful book called Dansk Design, by Thomas Dickson. It covers a lot of the history of Danish design, and not only the immediately recognizable furniture, lighting and other overtly bauhaus-inspired domestic artefacts. It also explores how Viking-era art also informs the Danish aesthetic, building on principles of simplicity, utility and a deep-seated sense of playfulness. The book draws in examples from all over the place, including the Danish landscape, early boat-building, office equipment – even the cover art for late-nineties group Aqua) – to explore Denmark’s place at the forefront of innovative design.
I got suckered in by the references to Lego of course, which made me consider what it is about the design of Lego that appeals. As I’ve said before, I’m not a big fan of much of the “modular” Lego – it seems more to do with movie tie-ins and a constructed approach to play. The kind of play that appeals to me comes from taking a bucket full of bricks and letting your own imagination take hold. I’m quite proud of my kids who – when presented with a new box of Lego (a common occurrence in our house) – will prefer to just muck about with all the new shapes and colours available to them first before getting into what the boxed instructions have to say. Taken to Toy Corner and given the choice of anything from India Jones to Star Wars sets, my youngest opted for a Creator set in order to build “monster robots”. Yay! Kids know how to play – it’s in their nature. I’m not sure why we feel compelled to give them pre-packaged imaginary worlds to play in.
The parallels with Ruby on Rails are readily apparent. RoR gives you a set of patterns, conventions and classes – building bricks if you like – to create web applications with. Using Rails you are constrained in certain ways, but those constraints free you up to focus your energies in other areas. According to the book Fifty Years of the Lego Brick, six 6 by 2 stud Lego bricks can be combined in 915,103,765 ways. Similarly the various component parts of Rails can be put together and extended in a wide range of creative ways that are – to all practical concerns – limitless. Paradoxically, the imposition of certain overarching constraints only restricts you to the bounds of your imagination.
You can see some of this in the simple but effective designs of web sites built using Rails. Basecamp, Lighthouse, and Shopify all carry forward this aesthetic, as do many of the sites listed in software.com’s ‘Best Ruby on Rails’. There is joy in their simplicity. They each take a problem and respond to it in an imaginative way that isn’t bogged down with artifice or preconceived complexity. It’s not that you couldn’t do something similar in Java, .NET or PHP. It’s more that you wouldn’t because the culture of surrounding each of these languages is very different to that of Ruby on Rails.
I didn’t realise this before, but David Heinemeier Hansson – the originator of Ruby on Rails – is Danish, thereby bringing my musings full circle. What a weird world. I can’t find a reference to Ruby on Rails in “Dansk Design”. Maybe a revised edition will see it included – at least on a par with Aqua.
A bit of a rant entry here – written in a rush – but stuff that keeps going around my head:
With the all the current buzz going on about Twitter and RoR I may as well throw my own opinion in so you dear readers (all three of you) can.. well.. make up your own mind I hope.
Is it just me, or is there some weird deja vu thing going on? We’ve heard this before with the story of CD Baby switching back to PHP after 2 years of Rails development. Derek Sivers made it clear that he was trying to get Rails to do things it wasn’t meant to do and went back to PHP wiser for having been exposed to Rails. Similarly the Twitter guys seem happy with using Rails for web-facing user interfaces, though you have to infer from their interview at the Artima Developer site that they ran into trouble trying to get Rails to do things it wasn’t intended to do. I’m going by Alex Payne fessing up to calling kind_of? all over the place – hint: if it looks like a strongly-typed application, and it smells like a strongly-typed application… what the heck are you using Ruby for?
Whether the Scala experiment will work for Twitter remains to be seen. I suspect – and hope – that everything will work out well for them, as a JVM-based language just seems a better fit for the high volume of transactions they have to deal with. “Twitter chooses appropriate technology for its architecture” is probably the real story behind the story.. but no-one’s going to get frothing at the mouth and spout off ill-informed blog commentary if that was the generally accepted view. Indeed, where’s the fun if you can’t have the odd holy war.
Having worked with Rails for a few years now though I’m still constantly baffled by people’s insistence on trying to get Rails to do things it’s not meant to do. It’s not the first time I’ve encountered this sort of attitude – back in my Delphi days I remember a co-worker extolling Delphi’s capacity for building web applications. This was at the point that PHP was pretty well the dominant language for quickly developing web apps, so I was a bit surprised at how miffy the guy got over my “when you have a hammer, everything looks like a nail” response. Delphi was a great language for building Win32 clients – much better in my opinion what Microsoft was offering at the time. But using it to write web applications just seemed to be perverting its core purpose. I stand by this of course – how many web apps ever ran on Delphi? – and funnily enough the guy is now a convert to Rails. But anyway… there’s a definite pattern here.
It’s not just inappropriate use of Rails in general that bugs me. It’s all the minor deviations developers take because they want to do things differently. Rails is, as they say, opinionated software. If you don’t like way Rails does things you’re better off not using Rails at all as it’s going to get you in the end. I got burnt – and inadvertently burnt other developers – trying to get Rails to do oddball things in the early days of using it. It was mostly stuff that I brought over from other languages, plus my own personal preferences – along with trying to fix stuff I believed Rails just got wrong. Using idiosyncratic style or “optimising” the way Rails works by creating libraries to automate stuff that Rails already does in a long-hand fashion: (i) it assumes your way is right (hint: just like me, you probably aren’t) and (ii) it drives a wedge between you and other developers. At worst, you make a whole heap of work for yourself doing things one way only to backtrack and do them the “Rails way” later – or alternatively keep writing code around your deviations and constantly complain about how hard it is to get Rails to do what you want it to do.
I’m not suggesting drinking the Ruby on Rails cool-aid. There’s plenty of room for improvement and many things that have come to be included in the Rails core because someone got shitty with the original implementation (old v. new migrations being an example). But it’s one thing to offer improvements to the way Rails does things and another to slyly (or inadvertently) subvert the core conventions of Rails because you either don’t agree with or don’t understand what Rails is trying to do.
The things I love about Rails – and even more so about Ruby – is the clarity of the language. Getting back to my idea about Rails-as-CMS, the RoR framework seems – to me at least – to be well suited to tackle the current problems around web-development. It allows rapid prototyping. It supports communication within teams by laying out a set of common concepts and conventions – a “language” if you like that make sense and everyone involved can use in describing an application’s architecture. DSLs can be used to make business-readable fragments of logic that even non-techy managers should be able to grok. Designers can use Rails to weave functionality into their designs. OK, it’s not the most high-performing framework out there, but if issues of scalability are your problem then RoR isn’t for you. If getting everyone on the same page and getting a working application built with few arguments then Rails may be the solution.
Fighting Rails is a fruitless exercise. If you are up for a fight then go pick a bigger framework like Java or .NET where you have plenty of variety in which “true way” (or “ways”) you want to chose. If you want to enjoy building web applications using Rails then learn the framework, understand the conventions (and the rationale behind them), and allow yourself to question why you did things differently before. Even if it’s not for you, worst case is you’ll go back to your favourite language better for the experience.
