“What is exactly the sweet spot Ruby on Rails has managed to hit? What in Rails makes a developer tick? The Railways is an open discussion where Rails hackers share the love and tell newcomers what in the Rails paradigm concretely made their views about web development turn somersaults.”
Some very interesting people turned up to share their experiences. The Rails users were people at small startups, people who’ve been running Rails apps for well over a year and people who work for large consultancies. The interested folks included .Net and J2EE developers, designers who wanted to know more about what their developers are excited about, and people who’ve been tracking Rails for a while without diving in and using it.
I’ll try to summarize here, and provide some information and tips that came out of the discussion. Apologies if I’ve missed anything.
People who are already using Rails are using it because they:
Enjoy it.
Get products and solutions out the door faster.
Appreciate how the tools that come along with Rails make development and deployment easier.
Appreciate how beautiful Ruby code can be made.
People who are interested in Rails but aren’t using it yet are either:
Locked into other frameworks because of their clients.
Unable to find documentation they can use either about the framework or about setting up production servers.
Worried about whether time spent learning a new language and framework will be a good investment.
So what exactly did we talk about?
Speed of development
Try things out, fail or succeed faster, use less people to get the same things done so you don’t need as much or even any funding. This was illustrated earlier in the day by Jesper Rønn-Jensen’s talk about using Rails for prototyping in CapGemini. They’ve put some of their prototypes into production, and turned others into Java/.Net code after using Rails to work out the use cases with their clients.
Good abstractions
Lars Pinds talked about how the abstraction in Rails are at the right level. Rails abstracts the things that are fixed, e.g. the HTTP protocol, AJAX, SQL and leaves the rest up to the developer. He talked about the problems other frameworks had trying to abstract non-generic things like groups and users into a generic framework and why that didn’t work.
Ease of deployment
People who’d come from J2EE specifically mentioned Capistrano being a joy. Ben Griffith shared his secret for finding Java developers who want to become Rails developers. He took out adwords for terms like “J2EE deployment problems” that said “Stuck in J2EE hell?” and got a very good response!
Migrations
Several people mentioned this as something that other frameworks just don’t have. Anyone who has used migrations knows it would be hard to do it any other way.
script/console
Having a console on your production database means you don’t have to write lots of scripts to do DB stuff. Knowing you’re going to be working this way means you tend to have a richer domain model.
Testing is easy
As Rails comes with a testing framework built in it’s easy to be test infected.
Ruby
Ruby allows you to write beautiful code that is closer to the language of the domain. Ben actually gets his non techies to read the code!
Fun / Passion
Reno Marconi, one of the original developers of Java in Sun talked about how he hasn’t seen this much buzz since Java first came out.
Future directions
People wondered whether Rails would turn into the committee based mess of J2EE and were reassured that DHH’s benevolent delegator style of leadership would ensure this wouldn’t happen.
A few people talked about running Ruby inside the CLR or JVM. Jon Lam is working on making the CLR and Ruby talk together. Other people made the point that the JVM is a really nice piece of engineering, it’s J2EE that’s the mess on top of it.
Documentation
A couple of people mentioned this as an area they found lacking, both for Rails itself and getting your app running in production. rails.outertrack.com is a fairly new site aiming to be something like php.net for Rails. Several upcoming books were mentioned that will help improve documentation in other areas. Someone also made the point that when Tomcat first came out, sometimes the only way to figure out what was going on was to read the code.
Keeping up with what’s happening
We talked about how to keep up with what’s happening in the Rails world. A good set of RSS feeds to keep in your reader are:
Previous Topic
