Rails I18n translate with empty string – bug?

Normally, it's pretty easy in Rails to take advantage of the simple i18n tools provided.  You just write I18n.t("some_key") and it'll translate that into whichever language.

Today, however, I discovered what seems like a problem.  If you do I18n.t(""), it returns a hash of all possible translations!  And if you give it a nil, it returns an error because that's not a key in the DB.

The first behavior doesn't sound correct at all, and the second seems dubious as well.  I'm thinking about fixing it like so:

  def translate(key, options = {})
    return nil if key.nil?
    return "" if key == ""
    locale = options.delete(:locale) || I18n.locale
    backend.translate(locale, key, options)
  rescue I18n::ArgumentError => e
    raise e if options[:raise]
    send(@@exception_handler, e, locale, key, options)

Is there any reason not to do this?

OpenSSL::SSL::SSLError (hostname was not match with the server certificate)

I got this error in one of my Rails apps that I migrated to 2.2. It occurs when you try and send mail with ActionMailer, which makes it especially annoying because the exception notifications I normally receive when there is a problem weren’t being sent!

I wasn’t able to track down the root cause of the problem – apparently something about an SSL certificate not being there or not being right, but here’s the change that causes ActionMailer to fool around with SSL mail:


I was able to “correct” the problem (or at least get things working again) by commenting out this line of code:

smtp.enable_starttls_auto if smtp.respond_to?(:enable_starttls_auto)

Perhaps it should be a configuration option, or there should be better error detection with regards to the certificate. If anyone comes up with a nicer answer, leave a comment, but in the meantime, I thought I’d post my quick and dirty fix.


I fixed the problem by running this as root:

make-ssl-cert generate-default-snakeoil --force-overwrite

Which regenerates the SSL certificates.

Won’t fix… why?

I discovered a minor Rails annoyance today, and, looking around for an answer to the problem, I found this, which is a perfect description of the issue, and includes a fix:


Unfortunately it has marked as “wont fix” with no reason specified.

Perhaps there is a reasonable answer that was perhaps discussed elsewhere, and just didn’t make it into the bug report, making it invisible to people like me who find it via Google, which is pretty annoying. The other explanation is more along the lines of “don’t wanna” (or fuck you, as the case may be), but at least come out and say so. “We’re not going to do it, as it’s not part of our English-centric vision” or what have you. Being a native English speaker, even when doing stuff for Italian or Austrian or whatever clients, I tend to code in English, because it’s 1) fast, 2) easy and 3) it’s pretty much universally understood by programmers. However, I can see the case for specific things to be in a particular language, and on the surface, this one line patch makes that a little bit easier, and doesn’t appear to be costly, so why not?

Just closing the bugs of people who have taken the time to try and help (this is clearly not just a “dude, it’s, uh, broke” bug) is the twin of the equally annoying people who don’t bother to take 30 seconds to send an email or bug report about software they’re using, and both are things I greatly dislike.

Ruby YAML Bug & Fix

Besides the nasty Ubuntu bug, which I was unable to do anything meaningful with, yesterday I also found a small bug in Ruby’s YAML package:

irb(main):004:0> YAML::load('1900-01-01T00:00:00+00:00')
ArgumentError: time out of range

The problem is that the YAML implementation that Ruby is using, called “syck” interprets that kind of date as something that it should make a Time for:

        else if ( strcmp( type_id, "timestamp#iso8601" ) == 0 )
            obj = rb_syck_mktime( n->data.str->ptr, n->data.str->len );

So I did a little bit of hacking on the C code, and made it create a DateTime object instead. My fix works, although I’m not sure it’s the best possible way of tackling the problem. The patch is attached to the bug report here:


This matters because my Rails text fixtures had some dates in them that were quite old, and this was causing problems.

Another “Mysql Doesn’t Do that?!” Moment


I think the real reason there was resistance to this change is that MySQL doesn’t support DDL transactions; and wrapping migrations in a transaction is mostly pointless without this feature. Since MySQL doesn’t support it, most Rubyists don’t know what DDL transactions are – so here’s a quick primer on this incredibly useful and certainly underrated feature.

DDL = data definition language, also known as the schema. DDL commands include CREATE TABLE, DROP TABLE, ALTER TABLE, and CREATE INDEX. DDL transaction support means that the following sequence of SQL commands will not modify your database

I never even thought of that. I was fairly confident in my vision of Postgres getting faster and faster, and Mysql become a “real” database… that the two systems were converging on something resembling a common speed/feature set. But things like this still occasionally rear their ugly heads and I’m happy to be a Postgres user.

Quick, Dirty Rails Deployment Benchmarks

I have started to look at Passenger (mod_rails) + "Ruby Enterprise Edition" (which is just a corny name for a nice GC hack that significantly reduces memory consumption) because of the aforementioned problem with Slicehost’s x86_64 amplifying Rails’ already voracious memory gobbling. So I did a few crappy benchmarks, comparing Mongrel to mod_fcgid and mod_rails. I didn’t look at concurrency, as that’s a can of worms I wasn’t prepared to open. I just wanted to see what raw speed was like. I used two methods from a project of mine, one, showall is quite DB intensive, and index does hit the DB, but not so much. 

Bad Rails Benchmarks

Looks like mod_fcgid and mod_rails (both running in devel mode) are faster, at least for this very unscientific benchmark. One other advantage those two Apache modules have is that they make life simpler – mod_rails even more than mod_fcgid, and don’t require an alphabet soup of mongrels and proxies and nginx, lighttpd or whatever the event-based server du jour is. Like I said though, the benchmarks are quick and dirty, and probably have issues. I’d be curious to see better ones *as long as they include mod_fcgid*.

Incidentally, it looks like linode.com uses regular x86 servers, so if you’re doing Rails, this is definitely a point in their favor, or at least something to consider when you compare the memory that they and slicehost give you.

“Enterprise Ruby” Developer Looking for Mac Access


That said, I still don’t have stable access to a Mac. Does anybody have
a 64-bit OS X server and can provide me with SSH access? Preferably
something that I can have access to for a long time, so that I don’t
have to keep asking for OS X access. 🙂

He’s in .nl if it makes any difference. I’m not that wild about “passenger” by itself (mod_fcgid does ok for what I need), but the “enterprise ruby” project, which is basically a reworking of how Ruby’s garbage collection functions, is a useful and timely idea, given how much of a memory hog rails is.

Generating Rails Fixtures From Large Datasets

I’ve been working with Tomaso Minelli doing some Rails work, and one thing we needed to do was set up some tests. The situation we are in is that we already have a large set of data to work with in our development environment, but getting that data into .yml files is no easy task. Since we have a fairly large number of interdependent tables, dumping one of them alone is pretty useless, unless you manage to get the other tables it links to, and so on and so forth. Dumping all the data would make testing quite slow, and really is too much to be useful. Here’s the rough solution we arrived at:

@fixtures = {}
@seen = {}

# Do something with a fixture.  In this case, we store it for later.
def handle_fixture(record)
  @fixtures[record.class.table_name] ||= []
  @fixtures[record.class.table_name] < STARTING_LIMIT)
        related = record.send(r.name)
      related = [related] unless related.is_a?(Array)
      related.each do |related_record|
        if related_record
          puts "    New Record #{related_record.class.name} #{related_record.id}"
          @todo < e
      puts "    ERROR: #{e}:n#{e.backtrace.inspect}"

@todo = []

namespace :db do
  namespace :fixtures do
    desc 'Create YAML test fixtures starting from a single model using reflections'
    task :modelbase => :environment do
      STARTING_CLASS = Foobar
      STARTING_FIND  = :all

      tmp = 0
      totale = STARTING_CLASS.find(STARTING_FIND, :limit => STARTING_LIMIT).size
      STARTING_CLASS.find(STARTING_FIND, :limit => STARTING_LIMIT).each do |m|
        tmp += 1
        puts "#{tmp} su #{totale}: #{m.id}"
        @todo < 0
          i = "000"
          filename = "#{RAILS_ROOT}/test/fixtures/#{name}.yml"
          puts "Create #{filename} for class #{fixture.class.name}"
          FileUtils.mkdir(File.dirname(filename)) unless Dir[File.dirname(filename)].size > 0
          File.open("#{RAILS_ROOT}/test/fixtures/#{name}.yml", 'w') do |file|
            file.write fixture.inject({}) { |hash, record|
              hash["#{record.class.table_name}_#{i.succ!}"] = record.attributes
          puts "Fixture for #{name} is EMPTY"

It’s written in a somewhat quick and dirty way, but it gets the job done. What it does:

It takes a single class – hopefully a well connected one – fetches a few of them, and goes from there, exploring all the other objects that the initial ones are connected to, and then dumping them in .yml files in the fixtures/ directory. It could certainly use more work:

  • Additional starter classes, for ones that aren’t connected to others.
  • Intelligent examination of data and data sets…
  • For example you could check to see what classes aren’t connected to the others and use them as starter classes.
  • If you wanted to waste a lot of cycles, you could also try and aim for a representative set of examples. For an object that has_many something elses, you could try and find one with zero, one with one, and one with a lot, to cover various cases. That could quickly get out of hand for largish data sets though.
  • I’m sure there are various other tweaks, knobs, and levers that could be added to work more efficiently. I’d love to see them!


For those who use emacs with Ruby on Rails, and perhaps even use rhtml-minor-mode, I have published an update:


It now handles .html.erb extensions for layouts/ files and layouts/application.html.erb files (or .rhtml).

Something that would still be nice to see is some hacking to better integrate partials, which currently don’t really know exactly where they fit in their parent document. That would take some work though, as you’d have to scan for use of the partial in question and perhaps do some other parsing of ruby code. If you’re clever though, you could probably get the most common cases by looking for something like :partial => ......

Cache it all

I recently redid my personal web site, at welton.it. Wanting to be quick about it, and make the look and feel a bit more uniform than it has been in the past, I hacked together some pages in Rails. Despite this being sort of a “killing a fly with a bazooka” situation, I’ve been doing lots with Rails, so it was quick to use. Here’s the thing, though: Rails is definitely overkill, as the site is basically static. I don’t need to calculate anything or fetch stuff from a database – I just wanted a reasonably good template system, and I am quite comfortable with Rails these days.

But the idea of leaving Rails running for a static site was of course no good: I basically need to cache the entire thing, so that Rails is simply not involved. How to do this as quick as possible (in between diaper changing and other baby duties!) ? Ideally, it would be possible to introspect Rails in order to know exactly which pages are present, then cache those, and avoid Rails on the server entirely (just generate them locally and put them in subversion), but that proved to be fairly hacky, so I settled for this code, which simply caches all pages which comes across, when caches_pages is placed in application.rb:

class CacheFileName
  include ActionController::Caching::Pages
  include ActionController::Caching::Pages::ClassMethods

  def cachedname(path)

def caches_pages()
  return unless perform_caching
  after_filter do |c|
    res = c.cache_page
    cfn = CacheFileName.new
    cf = Cachedfile.new :filename => cfn.cachedname(c.request.path)

It simply caches everything. To be able to easily clear out the cache if there are any changes to the site, we record the changes in the Cachedfile model, which is defined like this:

create_table "cachedfiles", :force => true do |t|
  t.string   "filename"
  t.datetime "created_at"
  t.datetime "updated_at"

with this model:

class Cachedfile < ActiveRecord::Base

  def Cachedfile.clean_cache
    Cachedfile.find(:all).each do |cf|
        fn = ActionController::Base.page_cache_directory + cf.filename
        File.delete fn
      rescue => e
        logger.error "Error deleting #{fn}: #{e.inspect}"


which has a class method to go through and clean out all the cached files. I call it manually from ./script/clean_cache:

#!/usr/bin/env ruby

ENV['RAILS_ENV'] = ARGV.first || ENV['RAILS_ENV'] || 'development'

require File.dirname(__FILE__) + '/../config/boot'
require "#{RAILS_ROOT}/config/environment"
require 'console_app'


It’s not a beautiful system, but it gets the job done.