Posts tagged: RAILS

This is nifty – Locomotive, from Ryan Raaum, a complete Ruby on Rails environment in a self-contained 30MB bundle. And when I say complete, I mean complete: Locomotive contains not only Rails itself, but the Ruby interpreter, RubyGems, the LightTPD webserver with FastCGI, the SQLite database engine, bindings for MySQL and PostgreSQL (though not the server binaries, wisely), and all the other bits and pieces needed for turnkey Rails. There’s also an expanded version of the package with even more goodies. If you have an existing Rails installation, Locomotive will run politely alongside it without messing anything up.

The recent posting by Ben Bangert entitled “Best of breed Controllers for MVC web frameworks” is interesting reading. (Also see his followup with corrections.) Rather than trying to stage a showdown, he’s noting significant similarities between the controller styles in CherryPy, Myghty, Bricks, Aquarium, Ruby on Rails, and Django. The implication I take is that this (mostly independent) convergence might be telling us something about smart web application development.

The post is worth reading for the comment thread alone, with posts from core Zope, CherryPy, Django, and TurboGears developers (among others) and a great little discussion of the history of object publishing on the web.

Big Nerd Ranch, which became well known on the strengths of Aaron Hillegass’s Cocoa training and writing, has a new offering in their “bootcamp” series: Ruby on Rails Bootcamp. It’s taught by Marcel Molina Jr., a longtime Rails contributor. Most of the stuff Big Nerd Ranch teaches has been around in one form or another for ten years or more; it says something that they are tackling something so relatively new. Another jump in mindshare for Rails.

Even if all the recent interest in Django hasn’t stopped other people from trying to create Python web frameworks, I think it has raised the bar for what people decide to unleash on the world.

Enter TurboGears.

Though it’s billed as a “megaframework,” its structure is almost identical to plain ol’ frameworks Subway and Fanery: a stack combining SQLObject, CherryPy, and a templating system (in this case, Kid). TurboGears also adds Ajax support via MochiKit.

It’s installable via setuptools; even if this means you need to install setuptools first, the net effort required is still less than manually installing TurboGears and its four separate framework components. Dependency management is no small thing when you’re combining several pieces that are all evolving rapidly.

As of yesterday, Django has changed its model syntax. So code that formerly looked like this:

class Comment(meta.Model): 
    fields = (
        meta.TextField('comment', 'comment', maxlength=3000), 
        meta.CharField('headline', 'headline', maxlength=255, blank=True)
    )

will now look like this:

class Comment(meta.Model): 
    comment = meta.TextField(maxlength=3000) 
    headline = meta.CharField(maxlength=255, blank=True) 

Sweet. This brings Django more in line with the Rails philosophy that syntax matters. Making things easier for the developer to type, remember, and read can only bring good things.

A List Apart, the website for people who design websites, relaunched this past Tuesday (they like Tuesdays) with a lovely new design and, at least as interesting to me, a completely new back-end powered by Ruby on Rails. Check out that stupendous live comment preview! Designer Jason Santa Maria, CSS ninja Eric Meyer and CMS maker Dan Benjamin have all done great work.

Zeldman also includes a capsule history and colophon.

Sam Newman has posted a useful high-level comparison of Django and Rails on his site. In it, I think he hits on one little-discussed reason why these two projects are grabbing so much mindshare right now:

[Rails and Django] … historically would have ended up being written in Perl or PHP - but ended up being written in Ruby and Python respectively.

When I heard DHH speak at OSCON, he mentioned switching to Ruby after giving up on trying to make PHP do the kind of stuff he wanted to do. Back in July I asked Simon Willison (of the Django team) about PHP; he said that both he and Adrian Holovaty had worked in PHP for years, but it was Python that “gave us the flexibility we needed to pull everything off.”