« April 2009 | Main | June 2009 »

Rails script/runner + logging + cron + production

May 26 by Andre in system »

A quick tip: you're using script/runner in production (likely invoked via cron for a periodic background task), you probably are not seeing logging output in your production.log. Why? In production mode, the Rails logger doesn't auto-flush. As far as I can tell, the logging output is simply lost.

An easy solution that worked for me: adding a Rails.logger.flush to my script/runner call in cron.

Before:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it'

After:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it; Rails.logger.flush'

Bonus tip: to capture any other output from the cron task, use this:

*/1 * * * * deploy PATH_TO_APP/script/runner -e production 'MyClass.do_it; Rails.logger.flush' >> PATH_TO_APP/log/my.log 2>&1

Happy logging!

Contributing on Github? Don't forget the tests!

May 22 by Andre in GeoKit » , Open source »

I just wrote up some tips for contributing patches to Geokit. Pretty applicable to any open source project. If I had to condense it to just one word, that word would definitely be tests :-)

Also some specifics on running tests for the gem and the plugin there.

Ruby 1.9.1 is the bomb

May 12 by Andre in Ruby » , Ruby on Rails »

More on this soon. All I can say for now is:

Ruby 1.8.6:

Completed in 3368ms (View: 2256, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3668ms (View: 2420, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3312ms (View: 1964, DB: 12) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 3296ms (View: 1896, DB: 8) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]

Ruby 1.9.1

Completed in 989ms (View: 593, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 1035ms (View: 591, DB: 6) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 1055ms (View: 588, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]
Completed in 985ms (View: 592, DB: 7) | 200 OK [http://hotspotr.com/wifi/list/14-austin-tx]

Get your character encodings synched up

May 01 by Andre in Ruby on Rails »

With Ruby 1.9 out there and all the multibyte string goodness it brings, it's a good time to think about your character encodings. Here are a few pointers on getting everything synched up.

1. MySQL encoding.

How to check it: I use Sequel Pro ... just click on a table name for the metadata:

How to change it if it's wrong:

I had a bunch of UTF content living in a latin1 table (MySQL calls it ISO-5589-1 latin1). To fix this, export your database and re- import as UTF Details are here, but the gist of it is:

mysqldump -uUSER -pPASSWORD --default-character-set=latin1 DB_NAME | sed 's/latin1/utf8/' > temp.sql 
mysql -uUSER -pPASSWORD DBNAME  < temp.sql

Why not just run the conversions in-place (ALTER TABLE table_XXX CONVERT TO CHARACTER SET utf8 COLLATE utf8_ci;)? That's a different operation -- CONVERT TO CHARACTER SET is appropriate when your content and your DB's encoding already match, and you want to convert it to another encoding. If you have a mismatch in content and encoding, the export/import trick is just what you need. Discussion on additional techniques are here.

2. The charset defined in your HTML headers

How to check it: use curl

~ $ curl -I http://hotspotr.com
HTTP/1.1 302 Found
...
Content-Type: text/html; charset=utf-8

Rails uses utf-8 by default, so unless you've consciously changed it you should be good.

3. The charset specified in your HTML metatags.

How to check it: just view your source and look for something along the lines of <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />. Yes, this is different from the charset in the headers. Mine didn't match on one site. Fortunately, browsers pretty much ignore the metatags in favor of the value given in the header. Still, if you've got a mismatch, it's trivial to fix.

How to fix: open up your application.html.erb and make the change.

4. Your database.yml

Just make sure you have the line encoding: utf8 in your database configuration blocks in database.yml.

5. One more thing to look at...

if you're doing static html caching, then Apache (or whatever web server you're using) probably controls the charset when it serves up the cached page. Make sure it's setting the right charset. More details here