Explorations...

It’s official. I’m honored to be among the list of speakers for the upcoming Canada on Rails conference, which will be held on April 13th-14th in beautiful Vancouver. Of course, the “big names” like DHH or Thomas Fuchs and a bunch of other great people are giving talks and keynotes as well, so be sure to reserve your ticket as soon as possible. Hope to see you there, in April!

Just a quick note, why I have been silent for so long. I just finished my master’s thesis which can be a tedious and very stressful job. Especially when it is concerned with Java Virtual Machines, I should have picked a ruby-related topic. I’m currently preparing a new release of file_column with lots of goodies, so stay tuned!

The other day, I’ve seen the following add from dice.com (a job portal).

Looking at the language syntax used here (“goto = dice.com();”??) it makes you wonder if they really know all that much about tech jobs.

I was always wondering why my migration files were numbered 1, 3, 5, 7, ... What is the secret reason behind choosing only odd numbers? Does rails trie to only use prime numbers?

Well, the last possibility was ruled out quickly, as 1 is not a prime number and 2 is one (Knuth once said: “2 is the only even prime number, but it is the oddets of all”).

But wait, things became even more mysterious: Recently I wanted to create a new migration for the first time after updating to 0.14.2 and rails generated a file with a number that already existed.

A quick look at the source and the history of the migrations generator explained everything:

Up to 0.14.2 the generator simply counted all the files in the migrations directory and added one to this number. Since my editor creates backup files by appending a ”~” character, I always had twice as many files as migrations and if you add one, you get an odd number.

Now, in 0.14.2 (or 0.14.1) they thanged this, to only count ”*.rb” files. Everything is great now, you think? Not at all! Now, rails correctly recognized how many migrations I have, but the number it used for the next migration simply was too low, as my migrations weren’t numbered consecutively in my case.

Luckily the trunk contains a new version that looks for the migration with the biggest number and increments this by one. Finally, what should you do, until this fix is included in a new release? Simply rename the migration file generated by rails to a sane number.

In the past hours I have been upgrading my applications to the rails 1.0 release candidate that is available for several weeks already. Can you guess what the biggest bummer was?

And yes, I had to edit my environment files again, because they were replaced by new versions, but I was expecting this.

Another thing, was a change in the great prototype javascript library. I was using its extend function in my own javascript code and the calling convetion had been changed a bit. But that’s fine, hey, we haven’t arrived at 1.0, yet.

However, when I deployed my application to the server, things went strange. Everything was really slow and most of the data was suddenly missing. I was panicking and looking at the database. You probably say: Dude, stay cool, it’s only rails running in development mode against your development database and you’re right. But why?

Finally, I realized I had rails allowed to overwrite my ”.htaccess” file but didn’t look at the changes. And there it was: Rails was running in CGI mode, instead of Fast-CGI. That’s why it didn’t pick up the environment setting for production mode and why everything was so slow. D’oh!

Now, everything is running nicely again. Time to get some sleep, I guess. So, don’t be afraid of upgrading rails. It usually works really well, as long as you’re just a bit smarter than I was…

Here is the new 0.3 release of the file_column library that makes handling of file uploads in rails really easy.

So what’s new? The most prominent new feature is an integration of rmagick/imagemagick so that you can easily resize uploaded images and create multiple versions in different sizes. Many thanks to Kyle Maxwell for his ideas on this subject.

You certainly ask yourself how this works? It’s very straightforward, as always. Let me just show you an example:

class Entry
  file_column :image, :magick => { :geometry => "640x400>" }
end

Just grab the release and look at the docs for more details.

As an additional goodie, I converted file_column to a rails plugin, so you can just drop it into your “vendor/plugins” directory and you’re done. This plugin thingie is certainly a cool new feature in rails.

For all of you, interested in all the details: Here’s a list of all the changes since the last version straight from the changelog:

• fixed bug where empty file uploads were not recognized with some browsers
• fixed bug on windows when “file” utility is not present
• added option to disable automatic file extension correction
• Only allow one attribute per call to file_column, so that options only apply to one argument
• try to detect when people forget to set the form encoding to ‘multipart/form-data’
• converted to rails plugin
• easy integration with RMagick

I’m happy to announce the release 0.2 of my file_column extension that makes handling of file uploads in Ruby on Rails as easy as it should be. It is a major rewrite that results in cleaner, more maintaineable code and includes some new features and a few bug fixes.

file_column now tries to auto-detect file-types (using unix’s “file” utility) of uploaded files to fix the extension if it is not set correctly. This ensures that the file is served with the correct mime-type by your web-server. So for example, if a JPEG-image is uploaded without an extension, it will be saved with a ”.jpg” extension, so that web-servers can send the correct mime tipe of “image/jpeg”. This feature was mainly developed by Michael Raidel. Thanks for your work, Michael.

For the future I’m planing to move file_column to rubyforge and to work with Kyle Maxwell to integrate this excellent imagemagick extensions. So stay tuned for more good news!

I have got a new release 0.1.3 of my file_column library. It fixes a bug that occurs when declaring multiple columns as file_columns simultaneously like this: “file_column :image, :another_image”.

Grab the new release for hassle-free file uploads in rails!

For all of you who are curious about the bug (I know you are!): I was iterating through the list of arguments with code like this:

def file_column(*args)
  for attr in args
    # a lot of meta-programming to define methods
    # that refer attr in their bodies.
  end
end

Unfortunately, Ruby’s “for ... in ...” construct seems to be heavily optimized so that every element of args is copied into attr in a way that closures don’t really work anymore. In the end, methods defined in the second iteration of the loop refered to the first attribute.

The fix was easy: Just use “args.each do |attr|” instead, which behaves as expected even in the presence of closures.

Look at this message on the Ruby on Rails maling list. A London based company is looking for developers with a minimum of 3 years experience in “Ruby/Rails”. That’s pretty hard since even Rails’s founder DHH only has around 1.5 years of experience, I believe.

When will HR people learn that not everything is about how many years you are doing something?

I’ve made a minor release of my file column library that provides even better rails integration. You can just require the file “rails_file_column.rb” in your “environment.rb” and the FileColumn methods will be automatically available in your models and your views.

You can grab “file_column 0.1.2” on the project’s homepage. Thanks to Rick Olson for the hint.

I just fixed a nasty little bug in my FileColumn library, leading to a 0.1.1 release.

I had the following code in a helper method to generate an URL where you can access an uploaded file:

url = @request.relative_url_root.to_s
url << object.send("#{method}_options")["base_url"]
url << "#{method}/" 
url << object.send("#{method}_relative_path")

Looks pretty innocent, does it? What it made it even worse is that it worked in WebRick, but totally broke when running on Apache. After the first request, I’d only get “Application error”. So what happened?

Lesson learned: Be careful with String#<< as it modifies the string in place. Strings are not immutable as (for example) in Java.