Blog


Dec

Nordic Ruby 2011 — The Half & Half Conference


The planning for Nordic Ruby 2011 is in full progress. If you are interested in sponsoring, please take a look at the sponsorship prospectus on the site; http://nordicruby.org.

Last year was a great success with a hundred attendees from Sweden, other Nordic and European countries and the USA.

We will continue with the much appreciated concept of 30 minute talks and 30 minute breaks, a half and half conference. This gives you a great opportunity to meet and socialise with a lot of people in the community from all around the world. There will off course be great speakers as well!

We can already announce Chad Fowler as a speaker! Chad Fowler is program chair for RubyConf and RailsConf, and author of The Passionate Programmer. We are very glad to have him.

The conference will be held at the same great venue as last year. The dinner party will be held at a new place and we’ll have some other new details. More information in the future.

You can download the wrap from Nordic Ruby 2010 on the website and also look at the sponsorship prospectus. The full site for Nordic Ruby 2011 will be launched at the end of January.

June 16th - 18th, save the date for Nordic Ruby 2011 in Gothenburg, Sweden. (The conference days are on Friday and Saturday).

Please contact us at info@nordicruby.org if you are interested in sponsoring the event.

Dec

Scopes Are Obsolete


I admit, I've never been a big fan of named_scope or just scope as it's been renamed in Rails 3. When it was first introduced I remember not being particularly impressed, as a Merb acolyte we'd had this chaining functionality in Datamapper for ages, only it was much better. In fact in Datamapper, every query you could construct was chainable. Thankfully in Rails 3 and ActiveRecord 3, queries have finally grown up so that everything is now chainable in ActiveRecord too:

class Person < ActiveRecord::Base
  def self.alphabetically
    order(:first_name, :last_name)
  end

  def self.active
    where(:archived_at => nil)
  end
end

Person.active # => [...]
Person.alphabetically.active # => [...]

In this case it seems like the scope method will give us much nicer more concise syntax:

class Person < ActiveRecord::Base
  scope :alphabetically, order(:first_name, :last_name)
  scope :active, where(:archived_at => nil)
end

But imagine if we want to add a new kind of scope to find user's with a given last name:

scope :by_last_name, lambda { |name| where(:last_name => name) }

It's getting a bit less nice, aside from the gratuitous lambda, it's still pretty okay though.

What I believe is wrong with this code though is that it is essentially recreating Ruby functionality. We're defining a method called by_last_name which will execute some code when called, only we're doing it through meta-programming for essentially no reason at all. The above could have been written as:

def self.by_last_name(name); where(:last_name => name); end

And it would have worked exactly the same. The only difference that I can tell is that scope allows you to define extension methods by passing a block, which I'm sure no one has ever used, since it's so completely useless.

The problem becomes even more striking when the code is even the slightest bit complicated.

scope :for_user, lambda { |user|
  if user.admin?
    where(:active => true)
  else
    where(:active => true, :user_id => user.id)
  end
}

That's just horrible.

def self.for_user(user)
  if user.admin?
    where(:active => true)
  else
    where(:active => true, :user_id => user.id)
  end
end

This looks much more like Ruby code and less like some kind of weird JavaScript concoction.

Stop replicating functionality that already exists, stop using scope. It is obsolete.

Nov

Our Presentations at RubyConf 2010


Two weeks ago, Jonas and I were in New Orleans for the 10th annual RubyConf. This was my 2nd RubyConf, but I had a very different experience this time. This time I was one of the speakers. And I was giving two presentations.

The Front End Testing Frontier

One of the presentations was an extended version of the Front End Testing Frontier presentation I gave at Mountain.rb in October. This time I was fortunate enough to have my colleague Jonas Nicklas as a co-presenter. Jonas is the author of the testing libraries Capybara and Evergreen, our primary tools for JavaScript testing at Elabs.

I've uploaded the slides from the Front End Testing Frontier presentation, but they're pretty sparse. Video should be available in a few weeks, and I'll update this post then.

Socialist Software Development

My other presentation was titled Socialist Software Development. I came up with the title after seeing a clip from The Daily Show about socialism in Sweden. I saw some similarities between the principles of socialism and agile development, and since it seems most Americans are terrified by the mere mention of socialism, I thought it would be fun to go to the US and talk about it. The essence of my talk came from this passage from the British Labour Party constitution:

The Labour Party is a democratic socialist party. It believes that, by the strength of our common endeavour we achieve more than we achieve alone, so as to create, for each of us, the means to realise our true potential, and, for all of us, a community in which power, wealth, and opportunity are in the hands of the many, not the few.

While I drew some inspiration from my flippant title, I mostly talked about how Sharing is Caring, and how important that is in software development.

Giving such a "soft" talk was quite a bit harder than giving a technical presentation, but I was very happy with how it went. I've posted the slides for the Socialist Software Development presentation as well, and I'll update when the video is online.

What's Next?

I've been to a lot of conferences this year, and it's been great presenting at Mountain.rb and RubyConf. The next conference on our schedule is the Scottish Ruby Conference in April next year. All the Elabs developers will be there, and I'm really looking forward to that. Then there's our own conference, Nordic Ruby, in June. This year was amazing, and it looks like the one next year will be even better.

I don't have any confirmed speaking events for next year, but I would love to do a couple and continue to improve as a speaker. But I think I'll limit it to one presentation per conference. Giving two at RubyConf was a bit overwhelming.

Nov

The "Oh Shit" Moment


You know that point when you realise you forgot something crucial, but it's too late to do anything about it? That's the "Oh shit" moment.

Last week, one of the guys at GitHub experienced just such a moment, when he accidently dropped their production database. A lot of people made fun of GitHub for this (after their data had been restored). We didn't laugh. Because we had just done something similar ourselves.

In our down time between client projects, we've been working on our own web application (more to come on that subject). It's been in private beta for a little while now, and some of our friends have been trying it out. We've been using it extensively ourselves. While trying out a new feature, we accidently deleted the entire production database. And we didn't have a backup.

What was the cause of this royal screwup? I'll get to that, but first I'd like to apologise to our friends who lost the data they had put in while helping us try out our new service. We fucked up. I'm so, so sorry!

What happened

We host our app on Heroku, and we have two environments there: the production (beta) environment and our staging (testing) environment. We were going to reset our staging database to get some new data in there by running heroku rake db:reset.

When you have multiple app environments on Heroku you specify which one you want to run a command against by appending --app appname to your command. If you leave that out, Heroku tries to guess which one you meant by seeing if any of your environments have the same name as the local directory you're in. In our case the production environment was named in the form of "appname" and the staging environment was "appname-staging". Our local directory was also named in the form "appname", which of course meant that the rake db:reset command ran against our production environment and reset the production database.

Now, we should of course have had a backup. But in our small private beta we just hadn't taken the time to set that up yet. We thought other things were more important. Now we know better.

What we are doing about it

We've taken two important steps to make sure that this doesn't happen again.

  1. We now have backups that get run automatically.
  2. We've changed the name of our production environment to the form of "appname-production" to make sure that we don't accidently run commands against it when we forget to add the --app flag.

If you were affected by our mistake, please accept my apologies. I am truly, very sorry.

Oh shit!

Nov

Build, RubyConf and Dave Hoover


Today we are 4 people at the office, half of the crew. Jimmy and Johannes, our designers, left on Monday for Build which is a design conference in Belfast. And yesterday CJ and Jonas flew to RubyConf in New Orleans were they will be giving the talk: The Front End Testing Frontier. CJ will also give a talk about Socialist Software Development.

On Tuesday we had a short but very appreciated visit by Dave Hoover, who flew by Gothenburg to see us and join Got.rb in the evening. Early on Wednesday he continued his journey by train to Malmö and Øredev Developer Conference.

A quiet day at the office.