Recently in ruby Category

From the Guardian

Ashley Highfield, the BBC director of new media and technology, also announced proposals to put the corporation's entire programme catalogue online for the first time from tomorrow in written archive form, as an "experimental prototype"

This is the cool Ruby on Rails project that Matt Biddulph was working on last year.

More announcements tomorrow apparently.

Update: It's alive

Joel Spolsky has been playing with Ruby on Rails. He's written about some of the problems that he found. This has upset some members of the Rails community.

On of the best points that Spolsky makes is one I've mentioned here before - the fact that ActiveRecord is a horribly crippled ORM system - it seems to have been written by people who are afraid to let their database do what it does best (i.e. deal with data).

Update: As Mike points out below, the article wasn't written by Joel Spolsky, but by an anonymous contributor to the "Joel on Software" discussion boards. Apologies for any confusion caused.

Update: Oh look. these people saw my error and spent an amusing hour or so taking the piss out of me. Glad I amused them so much.

When I saw him in Amsterdam, Matt was talking about a secret project he was doing for the BBC. And now he has revealed what it is. He's putting a web front end on the BBC Programme Catalogue. That's a database that contains details of almost a million programmes that the BBC have broadcast over the last few decades. It all sounds really exciting. Matt is ably assisted by Ben (who seems to be following me around on my 2005 tour of old media outlets) and Murray - both chaps who really know their stuff.

First previews should appear within a few weeks. I'm looking forward to it.

Last week David Heinemeier Hansson wrote a rather controversial piece about the use of stored procedures, triggers and relational constraints in databases. Later in the week Alex Bunardzic backed him up. What they both seem to be saying is that because we now have powerful tools to represent our data models in code[1] then there is no longer any requirement for the database to use any of these features which model parts of an application's business logic. The argument seems to be that they want to model all of the business logic in the application code and that splitting it between the code and the database only complicates matters unnecessarily.

I just can't agree with this point of view. If there are business rules which describe the valid states of your data then those rules belong in the database. The most obvious reason for this is that there will always be other applications that want to access the data in your database. These systems might not be built using the same tools as your original application and that makes it unlikely that they will be able to use your carefully constructed ActiveRecord code. Which means that someone else will need to reimplement the same business rules using their own favourite technology. And everytime the same logic gets reimplemented, there's a chance that discrepancies will creep in. This is the Don't Repeat Yourself principle in action.

The original articles recognise this problem and they think they have an answer. They talk about the difference between application databases and integration databases. They say that their rules only apply to "application databases", which are database that only support a single application, as opposed to "integration databases" which are there to share data between multiple applications.

I think that this distinction is nonsense. In the real world, these "application databases" simply don't exist. Or, rather, there are so of them that it's not worth considering them separately. Oh sure, most databases start out supporting a single application. But once you start getting an interesing amount of data in it, there will be other applications that want to use it. And then they'll want to start adding their data to your database. And before you know it your "single application" database is the company data warehouse.

Yes I'm exaggerating. But it happens. I've been building databases for almost twenty years and I don't think I've every seen one that didn't eventually become an "integration database". And for a multi-application database you need to put as much as possible of the business logic into the database.

If the Ruby on Rails people are seeing a lot of single application databases then good luck to them. But I think it puts a serious question mark over their experiences with databases in the real world.

[1] They are tailking about the Ruby on Rails database access layer, ActiveRecord, but their points are just as applicable to things like Perl's Class::DBI or Java's HIberate.

All the cool kids are talking about Ruby on Rails. It's apparently the next big thing in web development. As Danny O'Brien said at OSCON, Ruby on Rails seems to have gone through the whole "first they ignore you, then they laugh at you, then they fight you, then you win" process in about three weeks. It would be interesting to investigate why Rails has become so popular when similar Perl-based frameworks like Maypole and Catalyst still languish in relative obscurity. I suspect it says something fundamental about the Perl community's ability to promote its projects.

I've looked at Ruby before. It seems to be a nice language. In many ways it's close to what Perl 6 will be - with, of course, the obvious advantage that Ruby is here now. So I decided I needed to take a closer look and did what any self-respecting geek would do - I've ordered some books. Copies of Programming Ruby and Agile Web Development with Rails will be on their way to me just as soon as Amazon gets them back in stock.

I'll let you know what I think.