Space Babies » ruby

The value of continuous integration

joost — Thu, 11 Aug 2011 21:27:34 +0000

It took a sweet while, but I am finally beginning to see the value in Continuous Integration. My Zelda gem is now being tested by Travis every time I push code into the repository and I can release my software with confidence.

As a Ruby programmer, a CI tool always struck me very C/Java-esque. There is no real build process in a scripting language, right? Well, turns out CI has other useful properties.

My gem has a (small, but thourough) spec suite. Travis runs this suite every time I make significant changes. A few minutes later I get the results in my e-mail. When everything’s OK, I know the software is good to go.

The true value dawned on me just now, where (frustratingly) Travis would report an error, but my local tests ran fine. Travis (on an older version of Ruby by default) didn’t like my use of method_missing much. And to be honest I didn’t either. So I yanked that out and replaced it with more well-behaving code. Travis passed right away! A clear example of a CI tool improving the code internals.

I am now much more confident that Zelda will play nice with all the Ruby versions out there. I will definitely add my other gems to Travis as well.

Random Active Record

joost — Wed, 03 Aug 2011 13:05:31 +0000

There is no method provided in Active Record to return a random record (to my knowledge). In the past I have used the ever so easy order by rand() for my random record needs. Problem: this is MySQL specific.

Since we now hate MySQL this had got to stop. Enter Randomizr. Include that in your Rails project and you’re golden. Just use Model.randomizr and you will receive one random record provided using ANSI SQL. Now you can migrate to PostgreSQL too! Like the big boys.

Grab the popcorn

joost — Thu, 26 May 2011 21:16:28 +0000

Intense debate. Warring factions. Constructive criticism. Fiasco. Unproductive nerd rage. Does this sound intriguing to you? It’s about the current state of Rubygems, a system that distributes Ruby software. TL;DR version: the Rubygems maintainers keep breaking their system and Ruby developers are pissed off.

Sea creature’s blog explains what’s happening in greater detail and it’s fascinating to see unfold in real time. For instance: follow @seacreature, @wycats, @JEG2 and @rbates instead of going to a movie! It’s just as entertaining and you can enjoy it from the couch. Fascinating stuff.

Fixing ASCII-8BIT encoding for Rails 2.3 ERB

joost — Tue, 22 Feb 2011 11:05:20 +0000

The combination of Ruby 1.9 and Rails is so much fun when it comes to character encoding. Words to adequately describe the sheer joy it gives me are hard to find. They are often four-letter though. Maybe that’s significant, I don’t know.

What I do know is this: ERB in Ruby 1.9 and Rails 2.3 will happily force all your templates to ASCII-8BIT while your database strings are most likely UTF-8. Hilarity ensues. There is no way to change this behaviour besides monkeypatching a bunch of internals.

So without further ado here are the monkeypatches: gist.

Drop in config/initializers and enjoy.

Why Ruby is so charming

joost — Sat, 19 Feb 2011 13:31:16 +0000

Part of why the Ruby community is so great is that it seems to attract quirky, ironic, playful and creative people. Can you imagine .NET programmers posting Friday Hugs or Lolcats on their blog? Or libraries named “can haz something”. Nope. It’s why I am extra grateful a person named Avdi has now created a completely serious gem to end all gems. I use it in my production system and it rocks!

Fixing MySQL encoding issues with Ruby 1.9.2

joost — Thu, 23 Dec 2010 13:53:46 +0000

There have been tens, hundreds, thousands blogs posts related to Latin1/UTF8 encoding issues. So here is yet another, this time related to upgrading from Ruby 1.8.6 + mysql gem to Ruby 1.9.2 + mysql2 gem.Here’s the thing: ever since Rails 2.1 I was under the assumption that all strings in my app were UTF-8 throughout. Wrong. Depending on your database settings, HTML HEAD, database driver and Ruby version you might will have a mix of character sets. Jay!

A recent upgrade of www.zappelin.nl brought this to light:

utf-8 present in HTML HEAD;
generated Rails app with all utf-8 defaults present;
mysql database still had latin1 as default character set;
same for the table;
using the old mysql driver gem.

The above combination led to strings still being stored as latin1 in the database.

MySQL documentation mentions charset conversions using ALTER TABLE. These did not work — the offending characters remained in their original character set. In the MySQL console these were printed fine: for instance ë was visible in the correct places. However in the Ruby world this was displayed as Ã«. Wuh?

I briefly considered dropping down to unix and using iconv on the database dump.

Luckily I was just too lazy today. Turns out you can convert the offending column to BLOB first and then to the correct character set. This worked! So if you have this problem the query below might fix things.

ALTER TABLE tbl_name MODIFY col1 BLOB;

ALTER TABLE tbl_name MODIFY col1 VARCHAR(255) CHARACTER SET utf8;

However, it still needed a bit of magic with regards to the default charset on the table. My best combination was to first convert the entire table to use latin1 by default, then run the conversion, then set the default to utf8. However, this didn’t work always.

ALTER TABLE tbl_name CONVERT TO CHARACTER SET latin1;

Keep in mind to always use the mysql2 gem when running under Ruby 1.9.2. Anything else is rubbish since this will not know how to deal with UTF-8 and you app will break and you will cry.

My wish for 2011: a definitive end to character set issues plz. This really is no fun.

UPC Customer service FAIL

joost — Wed, 10 Nov 2010 21:35:12 +0000

Honest to God, actual autoreply from UPC (our cable company, possibly the worst customer support in the world):

Let op: onderstaande link verwijst naar een pagina die op dit moment niet in gebruik is. Onze excuses hiervoor.
http://vragen.upc.nl/app/account/profile

Which translates to:

Please note: the link below points to a page which does not exist. Our apologies for this.

Which is just fucking sad. UPC, you suck.

Nerd humor

joost — Sat, 11 Sep 2010 12:19:41 +0000

Specifically: Ruby humor. Thanks lenmeister.

Installing ImageMagick on Snow Leopard

joost — Fri, 11 Dec 2009 11:11:08 +0000

Getting ImageMagick onto your computer would be so incredibly difficult I would often just forgo the entire thing and pray that image manipulation would sort of work on the server. Well, no more. Claudio Poli has written a great bash script to install the whole thing with one command. Clone this repo and execute it. Works perfectly!

Afterward I had to add this to my Rails development.rb file:
Paperclip.options[:command_path] = "/usr/local/bin"

ActiveResource Twitter client

joost — Tue, 01 Dec 2009 22:09:28 +0000

Every tech blog should have a post about a Twitter client. Here’s mine. To be fair, my client has only ~~eight~~ seven lines of code, so it rocks.

To update a Twitter status in a Ruby on Rails app, you might resort to using some kind of plugin or library. You link that library, maybe include a parser or two, an http lib, who knows what. After you know your Tweet has ballooned into 1200 lines of code and is a mess to manage.
It can be so much simpler, provided you’re inside a Ruby on Rails application.
RoR has a RESTful service builtin, called ActiveResource. Turns out it is quite capable of tweeting:
class Tweet < ActiveResource::Base self.site = "http://twitter.com/" self.element_name = 'status' self.timeout = 5

self.user = USER self.password = PASS end

To tweet, simply execute this line:
Tweet.post(:update, :status => "7 LOC Twitter API client FTW") if Rails.env.production?

Did you notice the check for production environment? That's just how leet this client is. Also, you might want to put a rescue block after it. Twitter tends to timeout, which raises an exception in ActiveResource.