After using Mercurial for 7 months we at 9elements have finally given in to the internet peer pressure und switched to git (Well, to be honest, several shortcomings in Mercurial played an important role too). Since then I’ve become accustomed to git and today ported over REST in Place from Subversion to Github.

The Github project page ist located at http://github.com/janv/rest_in_place/, the repository can be found at git://github.com/janv/rest_in_place.git.

I’ve updated the README and the project page with the new information.

I’ve also published my dbserialize plugin at Github.

Why didn’t ANYONE notice how FUCKED UP this is:

These factors led to the development of Automake. automake, like autoconf, is a program run by a developer. The developer writes files named Makefile.am; these use a simpler syntax than ordinary Makefiles. automake reads the Makefile.am files and produces Makefile.in files. The idea is that a script generated by autoconf converts these Makefile.in files into Makefiles.

… which are then read by make to run the compiler.

Seriously, if a build process needs 5 different programms in 3 different languages that, in part, generate each other, change the god damn build process to something simpler. So I don’t have to deal with this crap in 2008.

(from http://sources.redhat.com/autobook/autobook/autobook_10.html#SEC10)

In preparation for the work on my Haskell NXT Library, I needed to install Yampa today. The official page lists version 0.9.1 as most recent, though that release is from 2002. Newer (though kinda “inofficial”) versions are available through Hackage/Cabal. Getting Cabal to work wasn’t difficult at all in the end, but scraping together all the information on how to get there was a bit tricky for an absolute n00b like me. I publish my steps here so that others trying to get Cabal to run on Leopard (or other systems) can save some time.

Ever since Rails 2.0 came out, my REST in Place Plugins stopped working because of the request forgery protecting introduced into ActiveController. The AJAX request didn’t submit the rails authenticity token and the requests weren’t answered.

I fixed that problem yesterday in both the jQuery and the Prototype version (both included in the plugin.)

Check it out on the REST in Place project page.

Today a post by Reg Braithwaite brought to my attention several blogposts about ActiveRecords alledged shortcomings. Most of their writers are posting rants rants about some ideas they have about ActiveRecord without ever having really used it, it seems. The main issues seem to be

• Domain-code in your controllers instead of your models
• Rails choice of inheritance (AR as a base class for models) for implementing AR

Putting domain code inside your controllers is a programmer problem, not a framework problem. I won’t even elaborate this any further.

The other issue is trickier. Not because of technical issues but because there’s a problem with the perception of Rails ActiveRecord. I first didn’t even want to waste my time to write this rant but then I started a comment on one of the postings that turned longer and longer until I decided to make a post of it.

Bill Karwin wrote some observations that I can mostly agree with. There’s one exception though: I don’t see any problem with AR being implemented as a base class for your models.

One perceived problem is a lack of separation of concerns, the idea that you should separate model logic and database logic and that ActiveRecords fails here.

But one must look beyond the separation-of-concerns dogma here and ask what motivates this principle. Mixed concerns lead to confusion, confusions leads to errors and redundance (and thus to more errors). So, the motivation is to maintain a clear view over your methods and to reduce redundance.

Both goals are maintained by Rails although the models contain a mix of model- and database logic. Because most things can be expressed very concisely in Ruby, one line or even no code at all (using the powers of reflection) is enough to achieve what you want. If all your model-functionality and ORM-functionality fit within one page on your screen, the benefit of splitting both into separate modules and/or files becomes too low to justify the cost.

The second problem with inheriting your models from AR::Base is supposedly the tight coupling between your model and your DB-access layer, requiring you to have a database ready for unit testing. If you’ve ever written tests for Rails, you know this is bullshit. Testing is a non-issue and the support for the testing database so seamless that I can’t imagine it being any more simple. One rake task sets up your testing database after a migration, the rest is handled automatically.

Pretending that relying on AR so much for your models is still bad somehow because you might want to change your record-store a some point in the lifetime of your application is nothing but a bunch of bullshit. NO solution EVER will enable you to do THAT in a way that’s so seamless that you’d want to. We’re talking about software here, not lightbulbs that you just screw in. Abstractions are always leaky and talking as if they were not is foolish.

The whole point is that Rails set out to to one thing well, and that is to write web apps in a certain way that has proven to be quite productive and covering the needs of most projects pretty well. You get a lot of comfort following that way but you pay a price if you don’t, namely losing that comfort. People are demanding stuff that Rails never promised to deliver. About their motivations I can only speculate. Maybe they’re just clueless, maybe they just want to make some noise. In any way, they’re hell of a reason to stay away from Digg and Reddit and stick to some bloggers you trust with not wasting your time.