I’m a Ruby noobie, I admit it. Coming from a .NET background, Ruby has been a learning experience for sure, but I certainly feel lke I’ve learned something along the way. One aspect of the Rails framework I really like is the relaxed attitude to working with the database – I really rarely have to worry about it.

That said, I’ve been puzzling over the use of inheritance with Active Record. In .NET land and with NHibernate, I’d quite happily have this:

class AbstractUser
class AdminUser : AbstractUser
class StandardUser : AbstractUser

All the *User subtypes have their own extra properties, and the AbstractUser provides some common ones like email, password, username.

Ruby doesn’t actually provide for abstract classes, so that’s one issue. But another issue is the way in which ActiveRecord deals with inheritance. Only single table inheritance is supported via the user of a discriminator column. My issue with this is that there’s no good way to support extra properties on a subclass – the properties would have to be added to the Users table and therefore without some trickery would be available to all User subtypes.

One possible solution for this is as follows:

class AbstractUser < ActiveRecord::Base
end

class AdminUser < AbstractUser
	has_one :admin_details
end

In this case, we have another model - and therefore another table - which provides the AdminUser's extra properties. This can then be used as follows:

admin = AdminUser.new
admin.admin_details.direct_line = '+44 567 7890'

This works fine, the values are off in a separate table and everything's separated out as I'd like. But the syntax is clunky. I don't really want to have to do admin.admin_details.direct_line, I want to do admin.direct_line. So I wrote a little extra method to do this:

class AdminUser < AbstractUser
	incorporates :admin_details
end

All this does is set up a has_one as normal, but then provide extra methods for getting and setting all of the attributes of admin_details, meaning that admin.direct_line will work as expected. The code for incorporates has_one is up on github now - it's the minimum that was required to get this to work, so please feel free to fork it. I do wonder if I'm missing something that's already built into Rails, but if I am, it's damn hard to find.

This approach makes me pretty happy overall - in the scenario I've got right now, I never actually need a base User, which is why I'm referring to it as AbstractUser, and it would really be better if that could never be instantiated. But it's a minor niggle, and the whole setup plays well with Rails' polymorphic routing and suchlike, and works with Authlogic too. I can already see some improvements, so I hope someone forks the gist and I can learn something from Rubyists!

I came across this when we were setting up Rails for IIS. To fix it, place the following in request.rb in your rails stuff:

def request_uri
if uri = env['REQUEST_URI']
(%r{^\w+\://[^/]+(/.*|$)$} =~ uri) ? $1 : uri # Remove domain, which webrick puts into the request_uri.
else # REQUEST_URI is blank under IIS – get this from PATH_INFO and SCRIPT_NAME
script_filename = env['SCRIPT_NAME'].to_s#.match(%r{[^/]+$})
uri = env['PATH_INFO']

uri = uri.sub(“#{script_filename}”, “”) unless script_filename.nil?

#we must have our rewrite rule look like
#RewriteRule ^(/[^.]*)\?([^.]*)$ /dispatch.fcgi?$1*$2
#It replaces the first ‘?’ with ‘*’
parts = env['QUERY_STRING'].split(“*”)

if parts.length > 1
env['QUERY_STRING'] = parts[1]
uri = parts[0]
env['REQUEST_URI'] = uri + ‘?’ + env['QUERY_STRING']
else
#if we didn’t have a *real* query string,
#then set the uri to the query string IIS gives us
uri << env['QUERY_STRING'] unless env['QUERY_STRING'].nil?
env['QUERY_STRING'] = ""
env['REQUEST_URI'] = uri
end
uri
end
end

And this in your site httpd.ini:

# Ruby on Rails
IterationLimit 0
RewriteRule ^(/[^.]*)\?([^.]*)$ /dispatch.fcgi?$1*$2RewriteRule ^(/[^.]+)$ /dispatch.fcgi?$1

Thanks to Chris Lang for this.

This is one of my favourite blog posts of all time: Choose a single layer of cleverness by David Heinemeier Hansson. It might not even be the right point of view, but the clarity of thought and ability to see it through makes this attitude refreshing.

In a world where we are plagued by design-by-commitee pain, the success of Ruby on Rails and Firefox (who also employed this sort of “benevolent dictator” attitude) should be drawing a lot of worried glances from bad project managers.

Ruby on Rails, a lesscode framework for the web, has reach version 1.0.

It’s great. Cutting edge AJAX functionality, smart database access through Active Record, great MVC implementation with it’s controllers and views, native URL rewriting with Routes. Lovely.

Congratulations to David and the rest of the Rails contributers.

The Railsday 2005 results are now in, and highlight just how rapidly you can get something convincing up and running using Rails. The winners range from practical, to clever, to downright inspired.

Boom boom!

The upcoming script.aculo.us stuff is being implemented in Backpack, and will soon be in Basecamp. You can see a video on the 37Signals blog.

Thomas Fuchs is single-handedly revamping the web experience. While it’s the packaging with Rails that will bring it to the wider community, Thomas’ work will soon be the benchmark for providing that shiny Web 2.0 experience in a clean and convincing manner.

Boilerplate is a “general application skeleton” for Rails which provides an advanced list/form view for your data. Quick admin sections, here we come! It’s still in very early versions, but something like this could be extremely useful.

madrobby is showcasing the next generation of effect that will be coming in Rails. These ones look a little more useful than the previous version, which although pretty sweet in themselves, didn’t strike me as being very practical in the stuff I’ve been working on.

I must say, this had never even occurred to me. It’s pretty clever. In fact it’s very clever.