Ruby on Rails
Ta-da List


April 12, 12:56

The blend of mind, talent, and passion

The rise of Rails has one story that's more important than any other. The story of blending. Blending mind, talent, and passion from widely different cultures across the entire complexity scale of software development.

It's a story about building a community consisting of seasoned J2EE developers responsible for making banks and the rest of the corporate world run on time. And at the same time inhabited by graphical designers pushing the envelope in look'n'feel who are just starting out in programming. And every single step in between.

That's remarkable. The J2EE guys would probably never have felt passion for doing Cold Fusion or PHP or any of the other technologies that normally appeals to designers turning into programming. And likewise, the designers would run screaming away if dumped in the backyard of J2EE. But Ruby on Rails is turning out to be that place in the middle capable of igniting excitement from both ends of the spectrum.

Why is that? I think part of the reason is that a lot of interesting properties around technology are universal in their appeal. Getting started quickly and feeling success early appeals to everyone (perhaps more critically to newcomers than veterans). Seeing the rise of beautiful coding structures arising from elegant syntax and the adherence to DRY (something that should be more appealing to the veterans as they've seen the consequences of the opposite). So what we're basically trying to achieve is the meeting of quick'n'dirty with slow-but-clean into quick'n'clean.

Now that the place in the middle exists, we're seeing the results of combining vast experience in enterprise systems with dedicated attention to look, feel, and eye candy. This is infecting both sides with the opposite concerns. The designers learn to appreciate abstraction through encapsulation and coherence much earlier than otherwise. The back-end programmers learn to appreciate and build consistent, accessible interfaces.

And Rails benefits enormously from the ideas and implementations steeming from both camps. From optimic locking strategies on the one side to Ajax visual effects on the other. The vision to address the full stack of web development makes ample room to include everyone.

See also ThoughtWorker and J2EE developer Obie's take on many of the same perspectives.

Challenge by Tim Bates on April 12, 13:20

Despite the advances that Rails has made, some of us still don't have the graphical or web design skills to make the best use of it.

I've been toying with Rails since ancient history and have made contributions to its code base, but my own Rails project is continually stalling on design or cross-browser compatibility issues, which I find increasingly frustrating. Some of these are things Rails will never be able to fix, although the Prototype library hopefully does a lot to address cross-browser JS compatibility.

I'd imagine that people in the opposite position might find different issues to be stumbling blocks, but I have no experience in this regard.

Incidentally, I'm looking for someone in the opposite position, who has the design foo but not the programmer zen, to team up with. Drop me a line if you're interested.

Challenge by Simen Brekken on April 12, 13:22

For me, one of two technical people working alongside 10 graphic designers, Rails has been a fantastic departure from (my own) badly structured PHP code and the horrifying alternative of partnering with a company offering J2EE CMS solutions for a ton of money and zero flexibility. Now I can stop re-inventing the wheel with PHP and develop the same powerful CMS and community apps in a framework that has made programming fun again.


Challenge by Morten on April 13, 14:50

I think you're making excellent points. Rails has hit a sweet spot where it has something to the various camps.

J2EE developers who either are more into web than backend or who don't want to fire up the big ole stack for all projects [1] will easily be able to use Rails due to the best practices approach and undeniably elegant manner of specifying and controlling the domain model (and ofc. the OO goodness of Ruby).

PHP developers can relate to the scripting-language methodology and have in Rails finally gotten a well-defined approach for dividing their problems into digestible bits in a language with a clean OO syntax and library.

It would be interesting to see from which camps the railers come from, take the poll:

I suspect that most railers are PHP buffs - possibly because Rails is the hammer they can use to hit J2EE developers upside the head with after years of futile and frustrating discussions :-)

[1]: I leave it as an exercise for the architect to determine when to use what tool..