User Stories Applied is a book that has often been mentioned to me in the six months I’ve been at ThoughtWorks and over the last two weeks I finally managed to get my hands on a copy. It’s not a very long book (230 pages) and it took me about 3 plane trips to finish it.

The Good

This book provides a very good outline of how user stories work and the intent behind them. Even though I work with user stories every day I found some of the details quite refreshing – especially how user stories are not meant to contain the details behind features, but rather to be a medium for us to start discussions around features.

I particularly liked the discussion on how to write good user stories and the guidance on when stories are too small or too large. This is an area where I think experience really helps, but the pointers in this book are a great starting point.

The Bad

Every chapter in the book ends with a summary and an outline on how the chapter influences the different roles on a development team. I’m not a big fan of this kind of writing – it reminds me of the textbooks I had at school and it doesn’t seem to really add any value.

The second half of the book seems to focus on comparing user stories to other approaches. I felt like the author was trying to defend user stories, but the arguments presented were more focused on the shortcomings of the other approaches rather than the advantages of user stories. Having said that, this can be very helpful if you’re trying to convince a client to use this practice on a project.

Interesting

I was rather intrigued by the difference between how the author describes user stories and what I’m used to. The author advocates that user stories should contain very little detail and the details should be discussed when the story is developed. I’m used to user stories containing most of the detail around a story – in fact stories will usually be pushed back if the details are left out.

I think using user stories as a placeholder for conversations around the details can work really well, but on projects with a large amount of developers (I’m guessing more than 8 developers) the interaction with the user will quickly become a bottleneck. User stories can therefore also work very well when they contain all the necessary details which are analysed and discussed in full before development is started – it’s not a massive difference, but on large teams it can certainly have a massive effect.

User Stories Applied as an excellent resource for anyone who wants to gain a better understanding of the ideas behind user stories. The book has very good examples and guidelines on writing better user stories and integrating them into your development process.

brew install postgresql

initdb /usr/local/var/postgres

Then starting it with

postgres -D /usr/local/var/postgres

This all went great and my database was up and running! Only problem was when I tried to run a migration against my local instance – I got a page full of errors including:

could not connect to server: Permission denied

Is the server running locally and accepting

connections on Unix domain socket “/var/pgsql_socket/.s.PGSQL.5432”?

Luckily someone has already solved this problem. I followed the instructions on that site (which looked very promising), but I was still stuck with the same problem.

Lucky for me someone in the comments mentioned an additional step you might need to run if you have already run bundler:

gem uninstall pg

gem install pg

Hopefully this will help someone with the same problem. Happy coding.

I agreed with most of what he said and it was very thought-provoking – it really made me think about how Rails is different and what it means for everyday development as well as the future of the framework.

The Ideas Underlying Rails are still controversial

Rails has always promoted the idea of convention over configuration. If you’re using Rails every day you probably don’t think about it, but this is actually a rather controversial idea. Every other web-framework focuses on being flexible rather than being opinionated and trying to eliminating some of the default choices developers face on a daily basis.

For example, consider the REST conventions introduced in Rails 2. Before RESTful routes were introduced we constantly had to make decisions about what we wanted our different routes and actions to look like – decisions that we had to make over and over for every application we developed. While we did have to take some pain in switching over to RESTful routes, there were benefits which made it all worthwhile.

I don’t think I’ve ever had a conversation about how we choose our routes since then – even though the introduction of REST was a controversial decision the existance of a convention meant Rails had already made the decision for us. In my opinion this is a good example of how the introduction of a convention has been a big win for Rails – it doesn’t actually matter that we chose REST. The mere introduction of the convention has removed the need for a trivial decision that we all had to make.

The other type of common problem that Rails tries to solve is problems which are very hard to understand. A good example is XSRF protection – it’s a reasonably tricky problem to understand, but we all have to deal with it. The fact that Rails has this protection built-in means we don’t have to worry about it – the framework solves the problem for us.

So Rails tries to eliminate trivial choices and solve problems which are difficult to understand by introducing conventions. What does this mean for the future of Rails?

JavaScript Applications versus HTML Applications

Rails 3 has very good conventions for developing HTML applications – you get MVC, RESTful routes, helpers, a templating engine – pretty much all the different elements you need for developing an HTML application. Where Rails doesn’t currently have strong conventions is with developing JavaScript applications – applications which are developed using client-side frameworks such as BackBone, Spine, Ember or JavaScriptMVC. In these types of applications Rails is primarily used for serving and consuming JSON.

Yehuda has been working on ActiveModel Serializers – this is a library that integrates with Rails and allows you to easily standardize the JSON being returned from your Rails. I didn’t actually think about it until he pointed it out, but there are various decisions to be made when returning JSON – whether or not to include id’s, how much of the object graph to load, how associated objects should be serialized (do you include only the id or do you include the entire object), etc. When your Rails application is primarily used for this purpose you end up having to make these decisions over and over – clearly an area where Rails could introduce some conventions to help us out.

My 2 cents

I agree that this is the correct direction for Rails to take – it should be easy to develop JavaScript applications with Rails. Personally I would like to see Rails push the limits in this area and expose a Hypermedia API by default. This means the JSON being returned would include links to the different objects being exposed by your application. Yehuda did mention this in his presentation and I think this would be a great addition to Rails.

The other area I would like to see Rails standardize on is with authentication and authorization. Currently most applications use libraries such as devise and it seems very strange that there is no standard solution within Rails.

Happy coding.

SELECT * FROM Users WHERE name LIKE ‘%bob%’

I couldn’t find anything similar in the Mongoid documentation, but according to the MongoDB documentation you can do regex searches.

User.where(name: /bob/)

Happy coding.

The conference took place over 3 days with various keynotes and 3 different tracks as well as numerous smaller sessions. As you would expect from a conference of this status all the speakers set a very high standard and all the keynotes were very thought-provoking. I really enjoyed all the session I attended – from the opening keynote by DHH to the lightning talks on the last day.

Some of my highlights were the opening keynote, as well as the sessions by Steve Klabnik and Yehuda Katz. Steve is very well-known for his work on Hypermedia APIs (which was also the topic of his session). Yehuda Katz presented a very thought-provoking session on the future of Rails.

I would definitely recommend the conference to any Rails developer – it’s a great way to open your eyes to the different technologies around Rails as well as get to meet other developers.

Overall I think the conference was a massive success and I would recommend it to any developer. Austin was the (awesome) venue which meant I also got to sample some of the local food and enjoy some of the local attractions – what could be better?

[BUG] cross-thread violation on rb_gc()

I was using RVM and bundler, so as far as I knew (which isn’t all that far) everything should just work.

I did what every responsible dev would do – I googled the error message. Unfortunately this doesn’t seem to be a very common problem and most of the solutions involved removing and reinstalling the json gem (which didn’t work for me).

I tried quite a few solutions, including nuking all local gems (so gems not installed through bundler) – no luck. I also reinstalled Ruby 1.9.3 – no luck. I even pulled down the project into a different directory and I still got the same error.

In the end the problem was with the RVM gemset. I simply removed and recreated the RVM gemset and this fixed the problem.

rvm gemset delete your_gemset_name

Hopefully this will help someone else with the same problem. Happy coding.

Here’s what to do.

1. Navigate to the beginning of the first line you want to comment
2. Press Ctrl + v
3. Select the lines you want to comment with j and k
4. Press Shift + i
5. Press #
6. Press Esc

Voila! If you want to do the opposite follow steps 1 to 3 and then simply press d.

This is really just multi-line editing. Happy coding.

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.