I would highly recommend this video to anyone who is looking for a better understanding of these three topics.

To get started, let’s look at a very basic example of a closure.

def run_proc(p)
  p.call
end

name = "Bob"
puts_name = proc { puts name }
run_proc puts_name
# Bob

This code obviously works, but keep in mind what is really going on here – we are creating a proc which references the name variable. We then execute the block in the context of the run_proc method, where the name variable doesn’t exist! So this little snippet of code is actually doing something really complex.

Ruby actually attaches the name variable to the block which then makes it available when we want to use it! This is called a closure.

Let’s look at another example, using a lambda instead of a proc.

def run_lambda(l, val)
  l[val]
end

a = 5
multiply_by_a = lambda do |x|
  x * a
end

puts run_lambda(multiply_by_a, 2)
# 10

Again, this works as we expected it to – the a variable is attached to the lambda and can be accessed when the lambda is executed. Now we can try something really strange.

def run_lambda(l, val)
  l[val]
end

a = 5
multiply_by_a = lambda do |x|
  x * a
end

a = 10
puts run_lambda(multiply_by_a, 3)
# 30

What this snippet is illustrating is that Ruby closures actually attach a reference to the variable being used. That’s why we can update the a variable and have the lambda use the updated value – this is actually different to how a number of other languages implement closures. Happy coding.

Turns out, it’s pretty simple – the syntax is just a bit different.

class Person
  def self.all
    %w{ Bob Steve }
  end

  class << self
    alias_method :old_all, :all

    def all
      old = self.old_all
      old << "Peter"
      old << "Owen"
    end
  end
end

p Person.old_all
# ["Bob", "Steve"]
p Person.all
# ["Bob", "Steve", "Peter", "Owen"]

Happy coding.

To refresh your memory, the zip method will combine the elements of two different arrays.

names = %w{ Michael Tobias Ann Barry }
surnames = %w{ Bluth Funke Veal Zuckerkorn }

p names.zip(surnames)
# [["Michael", "Bluth"], ["Tobias", "Funke"], ["Ann", "Veal"], ["Barry","Zuckerkorn"]]

I also mentioned that you can actually combine multiple arrays in this way.

names = %w{ Michael Tobias Ann Barry }
surnames = %w{ Bluth Funke Veal Zuckerkorn }
ages = [ 42, 44, 17, 49 ]

p names.zip(surnames, ages)
# [["Michael", "Bluth", 42], ["Tobias", "Funke", 44], ["Ann", "Veal", 17], ["Barry","Zuckerkorn", 49]]

What I didn’t realize was that you can very easily create a hash mapping between two arrays when you use this method in combination with the [] method on the Hash class.

names = %w{ Michael Tobias Ann Barry }
surnames = %w{ Bluth Funke Veal Zuckerkorn }

p Hash[names.zip(surnames)]
# {"Tobias"=>"Funke", "Michael"=>"Bluth", "Ann"=>"Veal", "Barry"=>"Zuckerkorn"}

This is a pretty cool trick. Lastly, we can actually pass a block to the zip method – the block will execute exactly the same as an each block executed on the result.

names = %w{ Michael Tobias Ann Barry }
surnames = %w{ Bluth Funke Veal Zuckerkorn }
ages = [ 42, 44, 17, 49 ]

names.zip(surnames, ages) do |elem|
  p elem
end
# ["Michael", "Bluth", 42]
# ["Tobias", "Funke", 44]
# ["Ann", "Veal", 17]
# ["Barry", "Zuckerkorn", 49]

I still don’t really get the name of the method, but it’s pretty useful. Happy coding.

One of the ‘tricks’ I found particularly interesting was checking for a substring. Let’s say we have the following string, and we want to check if it contains the word ‘test’.

s = "this is a test"

The normal way of doing this would be to use a Regular expression.

if s =~ /test/
  puts "Found the substring"
end

I know many developers absolutely love Regular expressions, but I’m not a fan. I find them difficult to maintain and not intuitive at all. (This is perhaps a discussion for another day) In any case, a nice and easy way of testing to see if a substring exists is with the following snippet.

if s["test"]
  puts "Found the substring"
end

Here we are actually calling the [] method on the string class – which will simply return nil if the specified string doesn’t exist. As far as I can tell the only downside here is that we can’t ignore the case of the substring. If we want to do that we’ll have to revert back to the Regular expression.

if s =~ /Test/i
  puts "Found the substring"
end

The [] method will happily accept a Regular expression, but I think it’s probably better to stick with this syntax. Happy coding.

The for loop is a syntax construct, similar to the if statement. Whatever variable you define in the for loop will remain after the loop as well.

list = %w{ google yahoo bing duckduckgo }

for engine in list
  # do something with engine
end
puts engine
# duckduckgo

On the other hand, Enumerable#each is a method which receives a block. A block introduces a new lexical scope, so any variables we declare in the block will not be around after the block executes.

list = %w{ google yahoo bing duckduckgo }

list.each do |engine|
  # do something with engine
end
puts engine
# NameError: undefined local variable or method ‘engine’

The for loop is very rarely used in Ruby. I don’t think it’s that bad to be using it, but the each method does decrease the possibility of side effects.

A few of the example revolved around the Enumerable module, so I’m going to take a look at some of the built-in methods within this module. We also discussed how it’s good practice to try and implement these methods yourself, so I’m going to try that.

Enumerable#any?

Let’s say you have an array of numbers and you want to test if any of them are higher than 10. You might write the following:

arr = *1..15

higher_than_10 = false
arr.each do |elem|
  higher_than_10 = elem > 10
  break if higher_than_10
end

Which is rather ugly and unnecessary. You could also try several of the other Enumerable methods to get to the same result:

higher_than_10 = arr.select { |elem| elem > 10 }.length > 0
higher_than_10 = arr.count { |elem| elem > 10 } > 0

Which seems better, until you realize that you should be using the Enumerable#any? method:

higher_than_10 = arr.any? { |elem| elem > 10 }

Implementing the any? method is pretty straightforward.

def any?(list)
  list.each do |elem|
    return true if yield(elem)
  end
  false
end

Enumerable#all?

As the name implies, this method applies a block to the collection and returns true if the block evaluates to true for all values.

all_higher_than_10 = arr.all? { |elem| elem > 10 }

What might the Enumerable#all? method look like if we tried to implement it?

def all?(list)
  list.each do |elem|
    return false unless yield(elem)
  end
  true
end

Pretty neat.

Enumerable#take_while

I can’t really imagine a scenario where this method would be useful, but I guess it’s good to know that it exists.

first_few = arr.take_while { |elem| elem < 25 }

What might the Enumerable#take_while method look like if we had to implement it ourselves?

def take_while(list)
  res = []
  list.each do |elem|
    return res unless yield(elem)
    res << elem
  end
end

I feel there should be a nicer way of implementing this, but I can’t really see it.

Enumerable#zip

Once in a while you might find yourself in a situation where you’re working with multiple arrays of the same length containing corresponding values. For example, you might have two arrays – one with a list of names and one with a list of surnames. This usually leads to some pretty messy code when we try to iterate over this.

names = %w{ Bob Steve Dave Peter }
surnames = %w{ Miller Scott Parker Smith }
for i in 0...names.length do
  puts "#{names[i]} #{surnames[i]}"
end
# Bob Miller
# Steve Scott
# Dave Parker
# Peter Smith

It’s not all that often that we need to use a for loop in Ruby – we can get rid of it by using the Enumerable#each_with_index method.

names.each_with_index do |name, i|
  puts "#{name} #{surnames[i]}"
end
# Bob Miller
# Steve Scott
# Dave Parker
# Peter Smith

This is still pretty messy – luckily Ruby has the Enumerable#zip method. This converts each element to an array and then merges each array with corresponding elements from the arguments. (You can actually pass in multiple argument arrays, which makes it a bit trickier)

names = %w{ Bob Steve Dave Peter }
surnames = %w{ Miller Scott Parker Smith }

p names.zip(surnames)
# [["Bob", "Miller"], ["Steve", "Scott"], ["Dave", "Parker"], ["Peter", "Smith"]]

Ruby will substitute nil if there are no corresponding elements in the arguments. Can we try and implement Enumerable#zip ourselves?

def zip(list, *args)
  res = []
  list.each_with_index do |elem, i|
    elem_arr = elem.to_a
    args.each do |arg_arr|
      elem_arr << arg_arr[i]
    end
    res << elem_arr
  end
  res
end

I’m not too crazy about the double loop – if you have a better implementation, I would love to see it! Happy coding.

The conference took place over two days and had close to 100 delegates attending. Obviously this is nowhere near the size of some of the conferences we have in the US, but considering that this is only the second iteration of the conference I consider it a smashing success. If you’re a Ruby developer in South Africa make sure you attend it next year. (The conference has a twitter account for updates)

I was quite surprised by the number of international speakers – out of the 20 speakers only 12 were based in South Africa. They key note was done by Sven Fuchs who is very well-known in the open source community. There was a good mixture of technologies being discussed (including two relating to CoffeeScript) as well as general talks on structuring and abstracting code. I predict in a few years the popularity of the conference will require multiple tracks to be introduced which usually improves the overall quality of presentations even further.

I would definitely recommend the conference to any Ruby developer (no matter what you level of experience) and if you feel up to it – try and present. The conference also has lightning talks (which are usually less than 5 minutes) if you only want to wet your feet with a very brief presentation.

As part of the conference there was also a Code Retreat – basically a day of talking about the right way of writing code and pairing with different developers. I really enjoyed this part of the conference as it really opens your eyes to different ways of thinking about practices like TDD.

As I said, I would highly recommend the conference. It’s a great way to learn about different technologies in the Ruby world and meet other developers. Cape Town in February – what could be better?

I’m going to illustrate how scopes can be used with a simple example.

A Product Application

I’ve created a very simple application to manage products. All the basic functionality is there – view/create/edit/delete.

The controller code for viewing the list of products is very simple.

def index
  @products = Product.all
end

You’ll notice (in the screenshot) that each product has a status – ‘Available’ or ‘Coming Soon’. Let’s imagine that the user wants to be able to view all Available products. How might we accomplish that?

The easiest way to do this would be to add a separate route and action which simply filters the products to only those with the correct status. First, let’s add the route.

get 'products/available' => 'products#available', :as => 'available_products'

Now we only need to add the controller action.

def available
  @products = Product.where(:status => 'Available')
  render 'index'
end

This certainly works, but there’s a cleaner way of doing this.

Using a named scope

Instead of using the where method in the controller, we can move the behavior to the model. We could create a class method to expose this filter, but Rails has a much nicer way – named scopes. Let’s see what that looks like.

class Product < ActiveRecord::Base
  scope :available, where(:status => 'Available')
end

Now our controller code is much cleaner and easier to read.

def available
  @products = Product.available
  render 'index'
end

And everything still works exactly as before. Hurrah!

Using default scope

As I mentioned, we also have the functionality to delete a product. However, we might not want to delete the record out of the database – we simply want to mark it as deleted. (There are a number of reasons why we might choose to do this – for example, we might have transactions linked to a product)

Here’s the code for deleting a product.

def destroy
  @product = Product.find(params[:id])
  @product.update_attribute(:deleted, true)
  redirect_to products_path
end

Let’s take another look at our list of products.

The deleted products are showing up in our regular list! While this makes sense (since we’re simply flagging them as deleted – not actually deleting them), this is definitely not what we want. So how do we fix that? One way would be to update all our queries to include :deleted => false. As you probably guessed, Rails has a neater way of doing this – using default scope.

class Product < ActiveRecord::Base
  default_scope where(:deleted => false)
  scope :available, where(:status => 'Available')
end

As the name implies, default_scope changes the default list of products being returned. Our list of products no longer shows deleted products. For example, Product.all will exclude deleted products. Pretty neat.

What if we want to bypass the default scope and actually get all products? For example, I might want to have an admin function that lists all unavailable products – meaning products which have their status set to something other than Available. We can do that by using the unscoped method.

def unavailable
  @products = Product.unscoped.where('status <> ?', 'Available')
  render 'index'
end

Pretty cool.

Conclusion

This is one of those pieces of functionality that you probably won’t miss until you know it’s around. It can definitely clean up your code and make it a bit more readable. I would probably be wary of using default_scope, but in certain scenarios it probably makes sense.

If you would like to play around with this code you can find it on Github. Happy coding.

There is a massive amount of overlap between these two approaches – they’re implicitly linked. A large part of making something easy to use is to make it visually appealing, and a large part of making something visually appealing is to make it easy to use! I try to think of it as two different targets within user interface design. Design tends to focus on the visual appeal as the end goal, while user experience tends to focus on ease-of-use as the end goal. The key word here is focus – I’m not saying that design doesn’t consider ease-of-use and vice versa.

Why is this distinction important? While these two approaches have a very similar goal in mind, they follow very different development cycles. Most design firms will happily create the entire design up front, before the application is anywhere near completion. User experience – on the other hand – can’t guarantee the design up front and will evolve the design over time. The design will evolve as the user experience is refined and improved.

Case in Point

The Flight Card iPhone app is a good example of this distinction. It’s one of the best-looking apps out there. Just look at it – absolutely stunning. The fonts, colors, layout – everything is just perfect. You would think this would be one of the top-selling apps out there.

Not quite. A mere three stars out of 20 reviews? What went wrong? Let’s take a look at some of the reviews.

This app is quite visually appealing, but it has some issues that make it harder to use. You cannot add trips more than 3 days in the future (hard when you want to put an literary in). You can’t swipe between flights.

First, the app is stunningly beautiful. It’s simply a joy to look at. But it’s missing some basic functionality. First, there is no way to swipe between cards. You need to menu back to list view and choose the next card. Not so big a deal except for the page dots at the top. You can tap the dots and they will change as if you’re changing cards, but you don’t change cards. And the dots are maddeningly hard to hit.

It seems that while the visual design is off the charts, the user experience is terrible. (I haven’t used the app, I’m only going on what the reviews say) This is perhaps an extreme example, but I’m trying to point out that a bad user experience means a bad app.

Guarantees

At the moment the popular approach is the design approach. No doubt about it. I think from a client’s point of view this is regarded as the ‘safe’ approach. Because we start out with the design and do pretty much the entire design up front it’s guaranteed – we have a good idea of what the final application will look like, even though we don’t know exactly how it will work.

The user experience approach is perhaps considered to be the ‘risky’ approach. We don’t have a good idea of what the application will look like – we only know that we will get much more input into the design and the user experience as the application is built. We’re almost guaranteed to end up with a better user experience, but because we don’t have a good idea of what the final application will look like, it feels like we’re taking a risk.

History repeating itself?

I think we’re facing a similar challenge to the one we faced 10 to 15 years ago – when agile started being introduced. Clients felt safe with the waterfall approach – all the planning being done up front meant that we had a very good idea of what the software would look like in the end. Then agile came along and suggested that the initial idea is less important, and we should rather focus on refining this idea as we go along.

Selling agile 10 years ago was probably similar to selling the user experience today. I do think that approaching the user interface from a user experience point of view is inevitable – it simply makes the most sense from both the user’s and the client’s perspective.

To illustrate this, I’m going to recreate a problem I recently came across when working on RapidFTR – one of the social projects I’m involved in at ThoughtWorks.

Let’s see some code

To start off, I’m going to extend the example I was using in my last post about routing. I’m basically managing products – I’ve created a Product model, a Products controller and I have a single entry in my routes configuration.

resources :products

When I run rake routes I get the following list of routes.

Right, now we have a new requirement – we need to be able to mark a product as a duplicate. We might have 2 admin users adding products and somehow we end up adding the same product twice. We don’t want to delete it (since some users might have bought the duplicate, etc) so we’re only going to mark it as a duplicate and link it to the non-duplicate product.

At the moment I can perform two actions on each product – view and edit. So I now want an additional action – mark as duplicate. This should take me to a page where I can select the non-duplicate version of the product.

Doing it the wrong way

Sounds easy enough – I’m probably going to need two additional actions on my controller – one to view the page and one to handle the page being submitted. To get started, let’s add 2 new routes.

get 'products/duplicate/:id' => 'products#new_duplicate', :as => 'new_duplicate'
post 'products/duplicate/:id' => 'products#create_duplicate'

Running rake routes reveals that we now have two additional routes.

Now I just need to add two method to my Products controller. This could be done better (moving some of the functionality into the Product model, for example) – I put all the code into the controller to make it clear what’s going on.

  def new_duplicate
    @product = Product.find(params[:id])
    @all_products = Product.where(['id <> ?', params[:id]])
  end

  def create_duplicate
    @product = Product.find(params[:id])
    @duplicate_of = Product.find(params[:duplicate_of_id])
    @product.duplicate = true
    @product.duplicate_of = @duplicate_of.id
    if @product.save
      redirect_to products_path
    else
      render 'new_duplicate'
    end
  end

We can mark a product as duplicate! Hurrah! Are we done?

Doing it the right way

While this code certainly works, I don’t think it’s really the Rails way of doing it. It’s actually quite easy to end up with too many methods on your controllers – to avoid this, it helps to think in terms of resources, rather than models and controllers.

In this case, we can think of duplicates as being an additional resource. So instead of marking an existing product as a duplicate, we’re creating a new duplicate resource. As you’ll see, this enables us to use the regular REST verbs – new, create, edit, update, etc. Enough talking, let’s see how this would actually work!

I’m going to start off by changing the routes. Here I’m using a nested resource.

resources :products do
  resource :duplicate, :controller => 'duplicates', :only => [:new, :create]
end

Now our routes look a bit nicer.

You’ll notice that our route now includes the :product_id, instead of just adding an id at the end of the route. This enforces the idea of a duplicate resource, which is available on product resources.

Now I only need to move my two actions to the newly created Duplicates controller.

class DuplicatesController < ApplicationController
  def new
    # same code as before
  end

  def create
    # same code as before
  end
end

More Examples

I first came across this concept in The Rails 3 Way – the common example seems to be in creating sessions. Instead of adding login and logout methods to the Users controller, we can think of sessions being a resource. So we might end up with a Session controller with new, create and destroy actions. Which actually makes a lot more sense.

If you would like to have a look at the code you can find it on Github. Happy coding.