schuerrer.org Weblog: Tag rails

F still comes before S

MSch — Sat, 07 Jan 2006 21:24:00 +0100

Some time ago David Felstead, a senior Site5 engineer, said that Site5 was considering switching from FastCGI to SCGI and so I decided that if Site5 was considering it, I could simply do it.

He wrote about some major pains in the proverbial with FastCGI:

It’s hard to set up
It’s hard to monitor
It requires dedicated tasks to keep working (reaper, spawner, spinner anyone?)
Currently no one is actively developing the Apache module.

According to him SCGI is better, because it only took him 15 minutes to set up properly. And now for the but:

As you, dear well informed reader, of course know one feature of FastCGI is to keep multiple instances of the Rails dispatcher open. SCGI in combination with the Apache module supports exactly one instance of the dispatcher. There is one obscure and in reality impossible way of changing that but believe me you don’t want to do this.

For me monitoring seemed easier because reaper, spawner and spinner already exist for FastCGI opposed to my self-written Ruby script that tries to do the same for SCGI.

And if that wouldn’t be enough SCGI also simply delegates every request below a defined path to Rails, which of course sucks if you have static content in your application. You can try to work around that, but once you generate .js or .css files through Rails, you pretty much start hating SCGI.

But uninformed as I was, I just went ahead and let SCGI handle my requests. Till today. Today I made Rails use FastCGI. I didn’t exactly follow the instructions in that article, instead of compiling anything myself I just let apt and RubyGems do all the hard work:

sudo apt-get install libfcgi-dev
sudo gem install fcgi

For me switching from SCGI to FastCGI brought nothing but relieve: My requests seem to get handled faster (probably because of the multiple instances running concurrently) and I no longer have to breach DRY, as my .htaccess doesn’t need to exclude non all rails handled requests.

Convention over configuration

MSch — Sat, 17 Dec 2005 13:31:00 +0100

Lucas Carlson tried to fix ERB’s html_escape to escape special characters, because he didn’t like that Rails produced instead of with this statement:

button_to '&lt; Back', :action => 'view', :id => 3

So he went on and patched ERB so that it supported escaping of ampersands (by prefixing them with a \) and till yesterday that seemed like the Ruby like solution to my. But then I woke up today and everything seemed clear.

I was a fool. Not only did I completely ignore the potential security breach (XSS) that was introduced by essentially removing html_escape’s teeth, but I also neglected to see the really Rails like solution.

Rails is based on many principles that sound like buzzwords, but in fact aren’t. Convention over configuration is one of them, and it means that there’s always one favoured way to do something. And for his problem this way is replacing the < with a plain old <:

button_to '< Back', :action => 'view', :id => 3

How I updated my typo installation

MSch — Fri, 16 Dec 2005 17:43:00 +0100

Yesterday I went from some revision I never cared to remember to the new and shiny 762. But not everything went smooth. While the svn update worked perfectly, the migrations simpley kept on failing. I even considered looking at the SQL for myself, but thankfully I rerun them once again, and voila, everything worked. This is a documented bug, but no fix is available as of now and why my “solution” worked is incomprehensible to me. (Also, I didn’t investigate)

In other news: Typo has lots of javascript problems

Even considering all these bugs Typo is still the best blogging software around (not only because it’s written in Rails) and I’ll happily keep on playing beta testing guinea pig.