Overall, the conference was really good. Berlin is an amazing city and the majority of the talks were really good. Of special note were the ones by Dr. Nic, Topfunky, and Evan Phoenix. Their talks about ruby magic, css generation, and rubinius were really well done.

To make things easier for you, I’ve also embeded the videos after the jump. Francis’s video is first with mine second. Sorry for the occasional fuzzy video quality, I’m still not good at filming presentations.

Let’s look at an example of user behavior to see why:

1. The user types http://superapp.com/account/logged_in into their browser.
2. This url is protected to the user is redirected to http://superapp.com/account/login and /account/logged_in is stored in session[:jump_to].
3. The user gets confused, lost, or just behaves like a typical user and navigates somewhere else.
4. Sometime later, the user goes to http://superapp.com/account/login and logs in.
5. The user is taken to ‘/account/logged_in’ instead of ‘account/welcome’. The user is confused.

Though user confusion on its own is bad, this still may not seem like much of a problem. So the user gets redirected to a different url than usual, how bad is that? In the app I’m currently working on, this behavior can be very bad. Depending on how the user is coming to the site and logging in, a bad return url can cause significant confusion to the user.

To fix this problem, the flash should be used instead of the session. Though the flash technically is the session, it is automatically cleared after each request. This prevents time sensitive data such as redirection urls from being stored longer than necessary and guarantees that you do not confuse your user with seemingly different points of entry on login.

[Model.find(1), Model.find(2), Model.find(3)] -
  [Model.find(1)] != [Model.find(2), Model.find(3)]

This does not behave as you would expect, because array subtraction compares elements on their object ids. Each find generates a new object, with a new id, so subtraction does not work. To get the behavior desired, do this instead:

to_be_removed = [Model.find(1)].map{|m| m.id}
[Model.find(1), Model.find(2), Model.find(3)].
  delete_if{|m| to_be_removed.include?(m.id)}

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

class Array
  def map_with_index(procedure=null)
    result = []
    if block_given?
      each_with_index {|item, i| result[i] = yield(item, i) }
    elsif procedure
      each_with_index {|item, i| result[i] = procedure.call(item, i) }
    else
      result = self
    end
    return result
  end
  alias :collect_with_index :map_with_index
end

[1, 2, 3, 4].map_with_index {|elem, i| elem + i } => [1, 3, 5, 7]

See how easy that was?

def make_number(x)
  lambda do |op, *y|
    if op == '+'
      make_number(x + y[0])
    elsif op == '-'
      make_number(x - y[0])
    elsif op == 'val'
      x
    end
  end
end

my_num = make_number(5)         => <#Proc>
my_num.call('+', 7).call('val') => 12

In case you can’t tell, this object creation makes use of higher order procedures. The make number procedure returns the anonymous procedure created by lambda. This form of object creation is not terribly practical, but it sure is cool.