Category: ruby on rails

ActiveRecord: the Visual Basic of Object Relational Mappers

I’ve been working with Ruby on Rails intensively for several months, and I’ve finally found a place where Rails can’t readily be extended to do what I want. It’s ActiveRecord, which is probably the most controversial part of Rails.

I’m reminded of a James Gosling quote disparaging Microsoft tools, particularly Visual Basic: “The easy stuff is easy, but the hard stuff is impossible.” There’s a parallel between VB and Rails in this instance, in that if you only let yourself use the high level tools, the hard stuff is impossible, but the designers specifically tell you to do the hard stuff using a lower level toolset. The controversy that surrounds “X can’t do everything, therefore it sucks” should really be focusing on the feasibility of going through that trapdoor to do things “the hard way”. This is what Delphi did, which is why so many folks chose it over VB; it made the hard stuff easier.

Continue reading “ActiveRecord: the Visual Basic of Object Relational Mappers”

Immature developer attitudes revealed in flames regarding CDBaby

Derek Sivers of CDBaby kicks ass. He got a sophisticated and very very user-friendly, efficient, straightforward e-commerce system (including the back-end systems) written in PHP. Based on what I’ve read, he’s up there with Phil Greenspun in my opinion; that is, he’s among those who understand strategy and customer service and low-level technology and are able to build systems that don’t suck, resisting the temptation to be distracted by technological panaceas and fads. I may disagree with their individual technology decisions, but their higher-level thinking is excellent, so they’re definitely in the class of people who I’ll give the benefit of the doubt.

So when I read 7 reasons I switched back to PHP after 2 years on Rails I was a bit surprised, but not much. He’s experienced with PHP (he says he’s written 90,000 lines of code for CDBaby!), and has a huge installed base of code he wrote and understands intimately. He tried Rails, it didn’t work the way he wanted, and he went back to PHP. It was immediately obvious to him that this was what he should continue using.

The most shrill and arrogant among the Rails community have been rather unkind, partly due to this rather poorly written Slashdot headline that misrepresents what Derek says in his article.
Continue reading “Immature developer attitudes revealed in flames regarding CDBaby”

Making the Rails acts_as_tsearch plugin work with fixtures

acts-as-tsearch is pretty cool, except for the fact that it uses Ruby (app layer) instead of PL/pgSQL (DB layer) to update the tsvectors that are indexed for full text search. That means that fixture data gets inserted without being full text indexed. D’oh!

Here’s some code that changes that.
Continue reading “Making the Rails acts_as_tsearch plugin work with fixtures”

Making Rails’ rake:test not drop your PGSQL database

Let’s say you’re using Rails with PostgreSQL and the TSearch2 built-in full text search engine.

Did you notice that every time you run rake test, that depends on db:test:prepare, which depends on db:test:clone, which depends on db:test:purge, which drops the database and creates it again?

Along with your dropped database goes the TSearch2 functions that wrap the C libraries that do the actual work. So, in effect, you no longer have TSearch2 installed. (“Uh… I kinda needed those…”) Presumably if you have tests that exercise search functionality, they will always fail because the TSearch2 functions are gone by the time the tests run.
Continue reading “Making Rails’ rake:test not drop your PGSQL database”