No Login after upgrade to Rails 2.3?

It cost me some hours on a sunday afternoon. After I upgraded to Rails 2.3.2 the login didnt work anymore. I read the release notes and followed all the instructions for cookie based sessions, like renaming session_key to key in the session config hash but still no luck. Things got more confused because locally everything worked fine. To make it short the solution is really very simple but you dont read much about it: you need to upgrade passenger to the newest version.


gem install passenger

passenger-install-apache2-module


And dont forget to adjust your apache config with the new settings. These are generated by the installer so you can just copy them.

switching to passenger

Though I am working with passenger for a while now, I just had new projects which started from the scratch using passenger. This week I switched my first mongrel based rails app to passenger. The idea was using passengers GlobalQueue option to optimize overall perfomance. One of the major mongrel drawbacks is its port based queues. If you have long running requests all others in the queue for that port have to wait. Thats different if you have just one global queue which doesnt pass request to busy processes.

While this works well as expected there are some minor modifications in the request header because the proxy has gone. For instance the webapplication read the calling ip address with the HTTP_X_FORWARDED_FOR header info. This is empty now with passenger.

So instead of calling

request.env['HTTP_X_FORWARDED_FOR']

I had to use

request.env['REMOTE_ADDR']
which has just the same info, the calling IP.

legacy databases with datamapper

For my current project I choose datamapper wich has some advantages over ActiveRecord. I need a thread safe ORM which doesnt need to do much but performing real fast. I am dealing with legacy table names but couldnt find any documentation how this is done though its very simple:

Your model needs a method storage_name like :

def self.storage_name(repository)
  "your_legacy_table_name"
end

Repository can be ignored if you are just dealing with one database.

ps: afcool83 mentioned a smarter way to do this:

storage_names[:default]='your_legacy_table_name'


the power of testing

I really thought we are over this point yet but it turns out to be a mistake. I work in a couple of projects in parallel so I meet a lot of developers and see many different types. I am really surprised to realize that the need to write tests still is so much underestimated.

All the classics like "no time to write tests", "is it really worth the effort" to "I thought this is just a webapp, so there is no need to write tests".

It happend to often too me, so here is my lesson learned if you start a new project with existing code. Ask for the tests. Take a peek a their test code, it gives you far more insight then any arbitrary code. It doesnt mean dont take any projects where no tests have been written, but it gives you different arguments. Its like dealing with legacy code, you cannot start implementing features as everything is fine.
But if the project leaders dont realize this fact forget the project, its a death march.


To say it with Obie Fernandez words
"Delivering Rails applications without automated test coverage is irresponsible and unprofessional."

620 Errors while testing with Google Geocoding

If you are using Googles Geocoding Api you might experience occasional problems with 620 errors, especially while testing. The reason for this is Google prohibits too many calls in a short period. But for most testcases geocoding is not an issue so you should disable it for these.

Fortunatly in Ruby its easy to override existing methods to mock them. I use the geokit plugin and with it this could be done by the following method:

def disable_geocoding
    GeoKit::Geocoders::Geocoder.instance_eval do
    	def geocode(a)
    		res = GeoKit::GeoLoc.new
    		res.lat = 13.423007
    		res.lng = 52.534194
    		res.success = true
    		res
    	end
    end
  end

Include this in your testhelper and call disable_geocoding in your setup method.

Annoying floating point conversion in Ruby

Try (4.85*100).to_i in irb and you will get:
484

This is weired and totaly unexpected for me. I understand that floating points are not accurate and conversions have their limits. Type "%.32f" % 4.85 and you see the real value of this float. The reason is that to_i does just a truncate.

If you want the expected result you have to use:
(4.85*100).round.

Some GTD criticism

I believe in chaos. Not that I say I love it. We are all in it by nature. For me its not a fight against, its more a dealing with it. You can try to keep its entropy low but you always need creativity to deal with the unforseen. GTD on the other hand is very strict and makes many assumptions. For me its hard to put all my tasks into one big pot and to decide when to write this or that task down for instance. GTD is sometimes too inflexible for certain situations. Sometimes projects need more attention, and they have much shorter cycles than less imortant or long running tasks. They grow bigger and they split or subprojects emerge and so on.
I am sure I did not get everything Allen is saying us so I am misinterpreting one or the other point. But I mean, hey, this book is like a bible, and I dont like the idea you have to read the same book many times to get a simple thing.
Dont get me wrong, I am still using GTD, not too dogmatic, as its fits and I am sattisfied with it. Good tools like Omnifocus are a great help there. I am still experimenting with it but I think dealing with the habits is more important because they are the source when we did a failure. So for me GTD is just a small tool in a complex world ;-)