Who do you want to be when you grow up?

So, you’re young and you’re a programmer. Maybe even a successful one. You have a cool job: the salary is good, the tasks are challenging and your coworkers are both intelligent and funny. Perhaps you’re not “just” a programmer, maybe your job title is something like “developer/designer” or “leading programmer”. I bet your parents are proud of you and most of your non-geek friends envy you. You have probably already created something you’re proud of: some cool app or a web framework. But…

Tales from the WTF company, part II

Welcome to the followup of my Tales from the WTF company. If you haven’t read the first part yet, I’d suggest you do. Otherwise you’ll miss important background info and a really funny story, too. This part starts where the last part ended, around noon of the second day.

Tales from the WTF company, part I

Some time ago I had a short episode of working for a Polish branch of a Germany based software company. In this entry (and probably a few following) I’m going to share with you a couple of WTF moments, so if you’re in for a few good laughs, read on! There is also part II of this story.

Multilingual page caching in Ruby on Rails

There is plenty of stuff written about caching in Ruby on Rails. You can easily cache anything from objects returned by a query to fragments or even whole pages. Especially storing full pages (known as page caching) in a directory when Apache¹ can grab them is really efficient. And there are quite decent tutorials about it.

Sadly, most of the tutorials assume that you live in a small, cozy, speak-english-or-die type of world and your only contact with foreign languages is when you order “pommes frites” at MacDonald’s.² The rest of us, working on multilingual applications, might have a lot of problems with implementing page caching. Fortunately, it’s not that difficult. Read on to see for yourself.

Teh worstest answer on a job interview ever

I was asked by our company’s HR guy to take part in a job interview with a candidate and ask a few “technical” questions. The candidate was final year undergraduate at the Technical University and hasn’t worked anywhere yet (at least his CV was silent about it), so I prepared really easy questions for him. The interview started like this:

Me: Can you tell us about some of your bigger projects? What were they about? What technologies did you use?

Candidate: Well… I haven’t done anything bigger. Only the tasks they gave me at the university. And some examples from the books.

Cookie handling in multi-domain applications in Ruby on Rails

My team is working on a multilingual multinational application in Rails (I know this sounds incredibly pushy but bear with me). The application is at susuh.de if you want to have a look at it, but it’s still alpha version.

In practice, this multi-multi-blah-blah means that we want to use both various national domains (like susuh.at, susuh.pl — those links don’t function yet, they are only examples) and various subdomains (like pl.susuh.de or en.susuh.pl). The national domains will filter content only to respective country (so susuh.de will only have content from Germany) and the subdomains will be used to change the default language for the national domain (so if you are an English-speaking person living in Germany, en.susuh.de is your place to go). The subdomain will also be important in multilingual countries like Switzerland.

Trying to implement this scheme we’ve run into problems with cookie domain handling in Rails. And cookie problems lead to session problems for users, like being erroneously logged out or loosing other settings.

You didn’t think I would write about cookies without an image of cookie monster, did you?

It seems that there are two official (normal) ways of handling this — at least that’s what Google says. Either you set your default session options in environment.rb like this:

ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:session_domain] =
  ‘.susuh.de’

Or you don’t set it at all.

The former lets you set cookies for any subdomain of susuh.de, like pl.susuh.de, but no other domain. The latter sets cookie independently for each subdomain, causing different cookies for pl.susuh.de, en.susuh.de and susuh.pl. Neither is what we really want.

So tell me what you want, what you really really want?

What we really want is to have the same cookie for any subdomain of susuh.eu and a different one for any subdomain of susuh.pl and so on. Nota bene, I’m not talking about a Single Sign-On problem, this is on much more basic level. We tried experimenting with setting DEFAULT_SESSION_OPTIONS “on the fly” in before_filter, but found out that this is too late (basically, this sets cookie domain for next request).

Fortunately, all is not lost. If all else fails, start reading code. And that’s what I did. The “entry point” for Rails is defined in dispatcher.rb file. Glancing over the code, I noticed something new for me: a before_dispatch callback. Google agreed that this may be a way to go, giving us link to http://m.onkey.org/2007/10/16/dispatcher-callbacks, among others.

Here’s our solution:

require 'dispatcher'
module ActionController
  class Dispatcher
    def set_session_domain
      ApplicationController.session_options.update(
        :session_domain => "#{@request.host.gsub(/^[^.]*/, ”)}”)
    end 

    before_dispatch :set_session_domain
  end
end

Does stubbing make your tests brittle?

Stubbing and mocking in unit tests is generally considered a Good Thing. It can make your tests run faster, it helps you not to cross boundaries. But it also makes your tests more brittle.

The reason for this is simple. If you want to stub out some method, you have to do it very precisely. You have to know the underlying implementation and choose a very concrete instance and method for stubbing. This makes your test very tightly coupled to the implementation details of tested class. And tightly coupled is brittle. Let’s look at some trivial example:

Learn a new programming language

As many of the luminaries of programming say, you should learn a new programming language every new year. That’s what I’ve been doing for several years now. Maybe not that strictly to start on January 1st with a completely new language and lose all interest in it on December 31st, but learning new things (including new languages) is one of my favorite things to do. And since I can probably list more languages that I think I “know” than I have spent years as a professional programmer (whatever that means), I think I’ve been true to above mentioned rule.

Too much intuitiveness will kill you

Recently I wanted to export some of my snippets from Textmate, so my teammates could use them too. I tried everything: right-clicking on snippets and bundles, clicking various buttons in Bundle editor, searching through menus and options, but I couldn’t any command for doing so. After several minutes of frantic clicking, I resorted to reading help file. To my surprise, exporting and importing bundle items is very simple, almost too simple.

If you want to share a bundle or particular bundle item then you can drag it directly from the bundle editor (from the list in the left side of the window) to the Finder.

This item can then be sent to other people and they will be able to double-click it to install it. Note: this also works for single items, like a snippet or a command.

TextMate manual

Moral of the story: too much intuitiveness will kill you. Or: if you make something too simple, some people may overlook it. Maybe you should add a less intuitive option for them too (like right-click menu item).

Unstubbing methods in Mocha

Recently I needed to ‘unstub’ a method in Mocha. Browsing Mocha documentation and googling yielded no results. Apparently, Mocha doesn’t support a concept of ‘unstubbing’, i.e. recovering original implementation of a method that has been stubbed. After a little hacking, I found out that it’s quite easy (though not necessarily elegant) to call original implementation.

Forgotten Internet services

The Internet is a relatively new invention, yet it already contains many artifacts that appear ancient to modern users. Having discovered Internet around 1994, I remember a couple of services that where quite popular then and later disappeared from the face of the Internet.

Make your tests run 25% faster

How?

By turning off the use_instantiated_fixtures feature.

But why?

Because they’re slow! Didn’t you read the comment in your test_helper.rb? Yes, this one:

# Instantiated fixtures are slow, but give you @david where otherwise you
# would need people(:david).  If you don't want to migrate your existing
# test cases which use the @david style and don't mind the speed hit (each
# instantiated fixtures translates to a database query per test method),
# then set this back to true.

But what about those nice @david variables?

They must be gone. Sorry. The tests are slow because of them. The above comment explains why.

Looping in a no man’s land

…or: how to put class scope to use

The class scope, i.e. the space inside class declaration, but outside method definitions, is a no man’s land in many languages (particularly in Java). By this I mean that you can define methods, variables, and other classes there and you can even execute some code (in variable initializations) but nothing more. Fortunately, in Ruby empty space between method definitions can be filled with all kinds of useful, executable code. Let’s check a few examples.

Table transposition in SQL

Here’s a cool SQL trick for doing a partial transposition of a table:

select id,

  max(case when language_id = 1 then text else null end) pl_text,

  max(case when language_id = 2 then text else null end) en_text

from translations

group by id;

Subversion updates notification with growlnotify

Here’s another cool use for growlnotify: informing about incoming SVN updates. For me this is crucial when working with TextMate, as it doesn’t have ‘Synchronization view’ like Eclipse has. And keeping up to date with files modified by your teammates helps minimize the number of SVN conflicts you’ll have to resolve.

Way beyond cool: autotest + growl + Doomguy

Here’s something that will amaze your friends to no end. Your male geek friends, that is. Type some code in your editor, save file and… a smiling Doom Marine tells you that all your tests passed. Or, if there were some errors, the Marine is bleeding. The more errors, the more blood. Is it cool or is it cool?

Just look at the screenshots. First: Marine is happy that your tests passed.

Next: there were some failures. The blood starts to flow!

Even more failures, even more blood.

Oh my, it looks like we killed him, we bastards!

How to do this? Read on.

Rails plugins & svn:externals

Rails plugins are cool. Installing them as svn:externals is cool (mostly). What is not so cool is that some plugins have svn:externals incompatible URLs. In my current project there are two such plugins:

• Globalize with url: http://svn.globalize-rails.org/svn/globalize/branches/for-1.2
• Mocha with url: svn://rubyforge.org/var/svn/mocha/trunk

When you install them with script/plugin install -x, they are installed as for-1.2 and trunk, respectively. This is because Rails’ plugin installer takes the final part of a URL as the plugin name and apparently there is no way to change it.

Of course, names like trunk are not very good. In bigger projects with several plugins it may be difficult to remember which name points to which plugin. It’s also easy to imagine that someday we might want to use another plugin that has a URL ending with trunk.

You cannot change names of external directories with svn move and mv tool also doesn’t seem to work. Fortunately, I found other ways to fix this situation.

RESTful Rails: extending scaffold_resource generator

The scaffold_resource generator is quite cool, but lacks one feature that my team found quite useful. Sometimes we want to generate RESTful scaffold with different names for model and controller.

Why would we want that? Well, mostly because in some cases we want to have two separate controllers for one model. The first controller contains ordinary functionality and the second — stuff only an admin can use. We feel that this separation is helpful for maintenance.

For example, we want to have User model class, UsersController accessed as /users/... with methods for signup, user profile edition etc. and AdminUsersController accessed as /admin_users/... with administrative functionality like deleting, granting or revoking access rights etc.

Unfortunately, Rails’ standard scaffold_resource generator only accepts model name and derives all other names from that. So it’s either User and UsersController or AdminUser and AdminUsersController. One possible solution is to generate it both ways, then delete AdminUser and manually change AdminUserController and its views to use User instead. This requires editing several files which is tedious and error-prone.

‘There must be a better way’ we said to ourselves and indeed there is: write your own scaffold_resource generator.

Extending Rails’ magic finders

One of the many cool things of Ruby on Rails are magic finders, or Dynamic attribute-based finders as the documentation calls them. Thanks to them we can write:

User.find_by_login_and_status(some_login, 1)

instead of:

User.find(:first, ['login = ? and status = ?', some_login, 1])

The first form is shorter and easier for human to parse.

Unfortunately, we can only combine attributes using and operator, but the possibility to use or and not operators would also be nice. And, as always when using Ruby on Rails, when we find that library is lacking some feature, we can easily add it. Let’s see how to do it.

each-require anti-pattern

This is going to be a little rant. This little anti-pattern I see all over in Ruby code by various people:

%w{yaml fileutils}.each { |lib| require lib }

I cannot understand why do people write it like this. This is neither shorter nor easier to read than the ‘normal’ version:

require 'yaml'
require 'fileutils'

Self-referential many-to-many relations in Ruby on Rails

…or is my friend’s friend my friend too?

Recently I tried to implement a feature that is commonly used in social sites like Xing or Linked-in: a friends list, also known as buddy list or contacts list. Basically this means that a user can link to any other user to indicate that they are friends or know each other. Normally, the other party has to confirm the link proposition for the link to be established. Having a contact network, the site can implement various cool features, like finding the shortest path between two random users or telling you that there are ‘820 contacts of your contacts’.

Implementing this proved not to be that easy in Ruby on Rails, partly because of lack of documentation and mostly because of my poor knowledge of Rails, so here’s a solution that works for me. It should be noted that this is rather a story of trial and error (although I will spare you visiting all the blind alleys with me) than an emanation of guru-like knowledge, so if anyone knows a better way, I’ll be glad to hear about it.

A simple shuffle that proved not so simple after all

Yesterday I found following snippet of Ruby magic to shuffle an array:

class Array
  def shuffle
    sort { rand(3) - 1 }
  end
end                                                      

arr = (1..10).to_a
# => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]                                                     

arr.shuffle
# => [1, 8, 6, 10, 9, 3, 7, 2, 5, 4]                                                     

arr.shuffle
# => [3, 7, 10, 4, 5, 8, 2, 6, 9, 1]

There is one thing wrong with it, but the original site no longer permits commenting on this entry, so I thought I’d share my thoughts here.

Hello World

Hello World! I knew you needed yet another blog, so here it is!