It’s very clear from posts on the rails email list that there’s space for books that take the novice developer beyond what they learn in beginners’ books like Agile Web Development With Ruby on Rails. Those books will help you build your first app and get a sense of the structure of Rails but before long you’ll want to write code that needs to be reusable between models, or across projects, or to interface with services other than databases. The beginners’ books, by definition, don’t deal with intermediate topics. That’s the niche Ruby on Rails Enterprise Application Development sets out to fill, but sadly it doesn’t offer much beyond those beginners’ guides.

Based on the title, I had expected going in that the book would be mostly focussed on cross-systems integration such as the use of LDAP, web services (particularly SOAP), connecting to multiple and/or legacy databases and other topics often lumped together as “enterprisey” which push at the rails conventions or require them to be abandoned. In fact the book would be better titled along the lines of “Up and running on Ruby on Rails in a small business” as the application developed through the course of its chapters is very simple and doesn’t demonstrate much about Rails itself that couldn’t be gleaned from AWDwRoR or one of its competitors.

Where some may find this book most useful is in the attention paid to windows-based development and to deployment (where it focusses on unix-based systems). Most of the books currently on the market do touch on using windows, but the authors of this one clearly use it themselves and actually advocate the use of an IDE for windows development. If your tastes run to Eclipse on Windows, that may draw you to this.

Though the book references Rails 1.2.3, the application built inside could just as easily have been built on Rails 1.1. The app is CRUD-based, but there is no mention of REST or map.resources, despite the fact that they could have simplified it. Authors don’t have to buy into the prevailing wisdom in the rails community, but it’s a shame when strategies that can simplify apps aren’t covered.

Perhaps more worrying given that Rails 2.0 is now out the door and will be the default for anyone starting out with this book now is the use of deprecated techniques such as dynamic scaffolds (the scaffold keyword was removed 10 months ago in changeset 6306) and old-style pagination (which left in changeset 6992 back in June)

There certainly aren’t as many books out there for newcomers to Rails as there are for some other languages/frameworks, so its inevitable that more are to come. It’s a shame that already at least two such books have been pitched at intermediate developers rather than their more correct audience, and hopefully that trend won’t continue. It would also be very helpful if packt would publish an addendum to this volume detailing the aspects that no longer work in Rails 2.0. Missing some great new feature in Edge Rails is one thing, but it’s quite another to rely on features that were scheduled for removal over six months before a book goes to press.

Disclaimer: I was sent a copy of this book for review by the publisher. You can find it at packt, amazon US, amazon UK and all sorts of other places.

Recommend this post:

All reports, and the evidence of the subversion commit log, says Ruby on Rails 2.0 will be with us very shortly. Apparently the announcement has been delayed until the gems have properly circulated. For those who’ve not been following, Rails 2.0 isn’t going to seem like a huge step forward as it’s mainly focussed on cleaning up existing features, and moving quite a few out of the core and into plugins.

I’ve converted quite a few projects over to be 2.0-compatible over the past few weeks and I’ve always come away feeling like my projects are cleaner as a result. It’ll be interesting to see what the benchmarks say about the performance impact of the new release.

Some of my favourite features of the new release are:

New view filenames and improved mime type support

Rather than filling up your views folders with .rhtml, .rxml, and .rjs files you’ll now be looking at filenames of the form myaction.html.erb, myaction.atom.builder, etc. If you ever found yourself working with the likes of myaction_atom.rxml, myaction_rss2.rxml, and so on, you’ll understand that the new naming system makes life simpler and your code simpler. In general, it really feels like the support for different formats that has been creeping into rails for a while now is finally coming of age with 2.0.

Pseudo-mime types

Closely related to the previous point, it’s nice to see an officially supported way to present different content to different devices just as you’d supply different formats for different requests. That’s written up well in this piece on building an iPhone UI for your Rails 2.0 application, and would have come in very handy when I was doing my work on intercepting microformats in rails input. Put simply you can define extra aliases for a given mime type, eg:

Mime::Type.register_alias "text/html", :my_extra_format

then use a before filter to identify a request as your pseudo-mime type:

  before_filter :detect_input_format
 
  def detect_input_format
    if request_matches_my_criteria?
      params[:format] = "my_extra_format"
    end
  end

and then the resulting action will render the view myaction.my_extra_format.erb (or myaction.my_extra_format.builder, etc.).

If the long-predicted explosion of the mobile web does indeed come in 2008, or more people adopt the facebook application approach, I can see this feature getting a lot of attention.

ActiveRecord Query Caching and Serializations

Lots of databases support native query caching, but it’s good to see it going in at the ActiveRecord level as it’ll sit a little closer to your app and be something you can rely on. I’ve seen a good speed up on some apps that I’ve been running on Edge.

ActiveRecord objects can now be created from XML and serialized to json much more easily, making inter-operability still easier.

And a lot more

The new initialization process is great, being able to specify :moved_permanently in redirects has cut out code I never liked, fixtures make a lot more sense, the view cleanups are great, and there’s a lot of stuff I never used which is no longer taking up memory in my processes. My experiences with Edge Rails lately mean I’m very pleased with Rails 2.0, am glad that this release is so focussed on clean-up, but I’m also looking forward to seeing what radical changes and refactoring come along once this version is out the door.

You can learn more about Rails 2.0 by checking out this post on the Riding Rails blog, the videos at railscasts.com and Ryan Daigle’s posts on Edge Rails. I’m sure a lot more will emerge over the next few weeks.

UPDATE (later that day): DHH has announced it and it’s official: Rails 2.0 is now out.

Recommend this post:

When Ruby on Rails first hit the scene, what attracted many of us to it was ActiveRecord. By providing a declarative syntax for describing relationships, validations, and callbacks it provided an elegance to model code that makes programming a lot more fun. Over the past couple of years ActiveRecord has received a lot of love, with has_many :through and improved caching options being the key additions I’ve enjoyed. But despite all that it’s given, ActiveRecord is clearly not the last word in Object Relational Mappers and it’s been good to see increased attention for some alternative Ruby ORMs such as DataMapper.

DataMapper shares a lot of syntax with ActiveRecord but promises a few new features, such as a more succinct find syntax, eg.

  # Find first entry in my_objects table
  MyObject.find(:first) # ActiveRecord
  MyObject.first        # DataMapper
 
  # Find all entries in my_objects table
  MyObject.find(:all)   # ActiveRecord
  MyObject.all          # DataMapper

and perhaps more usefully, improved finder options. Edited from the DataMapper site:

# 'gt' means greater-than. We also do 'lt'.
Person.all(:age.gt => 30)
 
# 'gte' means greather-than-or-equal-to. We also do 'lte'.
Person.all(:age.gte => 30)
Person.all(:name.not => 'bob')
 
# If the value of a pair is an Array, we do an IN-clause for you.
Person.all(:name.like => 'S%', :id => [1, 2, 3, 4, 5])
 
# Does a NOT IN () clause for you.
Person.all(:name.not => ['bob','rick','steve'])

You can approximate that functionality with some Rails plugins, and of course you can use the :conditions parameter to an ActiveRecord finder to do the same queries, but there’s something nice about being able to do it all in Ruby. (You can also fall back to ActiveRecord like syntax)

Most uses of DataMapper I’ve seen so far have been standalone, or in conjunction with merb, but I decided to give it a try by converting an existing rails app. Given how much similarity there is in syntax it seemed like it would be fairly easy to convert a few models and see how it compared. Unfortunately, it’s not that easy.

It’s pretty rare to build a rails app without plugins, and most plugins that affect models do so by extending ActiveRecord::Base. Since by using DataMapper you’re breaking away from ActiveRecord::Base, those plugins won’t work without invasive surgery. Similarly, DataMapper doesn’t support AR’s validation syntax and while it will soon have validations of its own, it looks unlikely that they’ll be compatible. It might well be possible to write a plugin that makes many other plugins work by examining ActiveRecord::Base.extended_by, and that could provide a translation layer to allow ActiveRecord validations to work with DataMapper, but that begins to be a lot of work for very little return.

Where DataMapper may really help Rails developers is in introducing more competition into the Ruby ORM world. By taking some radically different design decisions, particularly with regards to migrations and column specifications DataMapper allows us to see a different, but similarly elegant way of doing things, and hopefully ideas will percolate back into ActiveRecord just as AR has clearly inspired DataMapper. Personally I am looking forward to using DataMapper in my next non-rails ruby project, but found the exploration a useful reminder of how much of rails’ success is in its coherency as a stack.

Recommend this post:

Practical Rails Projects is a weighty tome, coming in just shy of 600 pages, which led to this review taking a little longer than it otherwise might: not just because the book took a while to get through, but also because it wasn’t quite so practical to lug it on the bus as some of the others I’ve recently covered. A result of that heft is a fairly comprehensive volume, but one that doesn’t feel quite so consistent as it perhaps should.

Eldon Alameda has written the book for people who have some previous Rails experience or may have cracked open one of the introductory books on offer, but who want to learn the framework by observing a number of working projects. In some ways that leads to overlap with a book like Practical Rails Social Networking Sites, but whereas that built up one example this book covers seven ranging from a system to track progress through an exercise programme, to an appointment scheduler that interfaces with 37signals’ Highrise using ActiveResource.

The first few projects proceed at an even pace and are likely to be helpful to a newcomer to Rails, there’s a fair bit of overlap with examples available in other volumes, but they work well together. While the author discusses the decision to skip over the writing of tests and/or specs, it did seem that in a volume of this size that topic should have been given a little space, even if that involved sacrificing one of the sample projects.

Unfortunately the book loses pace a little later on, particularly with the introduction of the Ext JS library which is used to build user interfaces but ends up occupying far more space than the actual Rails code in the later chapters. Obviously Javascript frameworks are an important part of building many modern web applications and Ext JS is a worthy entrant, but the way it was used seemed quite inappropriate. The admin interfaces built with it would not gracefully degrade for users without javascript; there was no discussion of progressive enhancement or even of why the decision had been taken to build such an inaccessible system. When careful use of respond_to blocks can make progressive enhancement so straightforward in Rails, this seems a missed opportunity. At the very least the decision making process should have been documented, and ideally a better solution would have been offered.

I was similarly surprised to find a number of occasions where design decisions were made that conflicted with the RESTful approach that is now Rails convention. Early on that might have been one thing, but coming after a chapter extolling the virtues of resource-centric design that was quite a surprise and seemed an indication that the book had begun to sprawl a bit. In many ways it’s a shame that this book wasn’t broken up into a couple of volumes. Packaging the first few projects together as an introduction, then offering the last few as smaller supplements more tightly focussed on specific areas such as Ext JS usage, ActiveResource, etc. That way the material could have been tightened up and some of the repetition would have made more sense, and perhaps there would have been space to cover a few obvious missing pieces such as atom/rss feeds.

With a number of volumes now available that use specific projects to illustrate Rails techniques, this book isn’t so distinctive as it might have been a few months ago, and many developers will probably want to go for a more focussed, more succinct option. If your learning style benefits from taking things slowly and you don’t mind some repetition then this may be a good option, but don’t forget to read up on accessible web development while exploring later chapters.

Disclaimer: I was sent a copy of this book for review by the publisher. You can find it at apress, amazon US, amazon UK and all sorts of other places.

Recommend this post:

As I’ve indicated here a few times, when announcing site launches and offering a few hints and tips, I fairly frequently find myself working with Drupal but have long had reservations about doing so. What I’ve so far avoided doing is going into much detail about why that would be, what those reservations are, and so on. But now I’m working on a review of a Drupal book and so it seems appropriate to lay those cards on the table and look at the details on them. It seems easiest to do that by comparing with the framework I do most of my development in: Ruby on Rails.

As ever with technology comparisons, just like any other sort of comparison, a lot of my preference for rails boils down to a combination of taste and experience. I’m also well aware that I’m comparing unlike things. Rails and Drupal set out to solve different problems, and so obviously take quite different approaches. That doesn’t mean, however, that developers aren’t often left choosing between them as the boundaries are blurred and there is significant overlap between their respective domains.

I’ve seen plenty of bad ruby code, but proportionately I’ve seen a lot more bad PHP, and as a PHP-based solution Drupal inherits some of that baggage. Drupal has pretty good support for a wide range of cutting-edge ideas and tools, but by and large the Rails community has seemed much more clued-in to what’s happening at the forefront of web development. That may of course change as the Rails community continues to transition from being chiefly early adopters to a much more mainstream crowd, but it marked my early impressions of the framework.

A case in point is the integration of automated testing in Rails. There is some community support for automated testing in Drupal (primarily through the simpletest module) and there are plenty of Rails projects that lack tests, but there is a strong focus on Test-Driven and Behaviour-Driven development in the Rails community, and the combination of Rails’ object orientation, simple rake tasks and fixtures/mocks makes it very simple to write a solid test kit.

Testing is complicated by the hooks system in Drupal. Hooks are a powerful feature, allowing any module to broadcast and listen for a variety of events and respond appropriately, but it can be difficult to know what order modules will receive those events and so you end up performing a variety of contortions to make sure your responses are given the appropriate weight. Arguably Rails’ layers of filters and plugins can introduce similar complications and I’ve certainly spent quite a bit of time tracking down performance hits coming from rogue filters in plugins and engines, but so long as inheritance is properly handled it’s not all that difficult to do a little introspection to make sure everything’s in its right place.

The fact that Drupal relies heavily on web-based configuration makes it easy to put a lot of power in the hands of admin users, reducing the reliance on a developer, but it also makes upgrades and deployments a more complex business. When I add a new module to an existing Drupal project I usually find myself noting down the steps I take to configure it in my development and/or staging environments so that I can repeat that process in production. In a Rails project I’d write a migration and set up capistrano to run that migration when I push my new version live, significantly reducing duplication. The Drupal approach may be simpler for non-developers, but as a developer I frequently get frustrated at the repetition of tasks that could be so much easier.

That issue is one of the key things pushing me away from the nice-in-concept CCK. Adding new content types to a site through a web interface is an appealing idea, but it’s a pain to have to work out how that changed things in my database to produce a script, or to have to repeat a manual process. Since I know how, I’m much more likely to produce a module for my new content type, simply because I know that deploying that is a much quicker process.

One reason it’s been fascinating reading the Drupal book I’m currently reviewing is that books on Drupal are so thin on the ground. That’s a real shame as while there’s a lot of content on Drupal online, it’s not really been well organised for experienced developers wanting to build serious solutions who aren’t already intimately involved with Drupal. By contrast, while the Rails books are mixed in quality the best ones not only get you up and running fairly quickly, but provide a good entrance to exploring the internals and writing effective extensions. That’s not necessarily a reflection on the core projects themselves, but both online documentation (where, admittedly, Rails is still lacking) and books make a significant difference to the developer eco-system and quality of the solutions that are likely to be built.

I don’t mean to sound too negative, and I’d love to receive comments showing me how to address the shortcomings I perceive. I’ve built sites I’m proud of on top of Drupal, and where their focus is a good fit for Drupal’s core features or mainstream modules it’s been a very good solution, providing a suite of content management tools at very little cost. But as soon as there’s serious custom development to do, those advantages tend to dissipate pretty quickly when set alongside the advantages of Rails for agile, regularly upgraded and well tested solutions.

Recommend this post: