Baruco 2014 Reaction
And it begins
Baruco 2014 has come and gone in a flash. Like the saying goes, “Time flies when you are having fun”. And so it was; The talks, the introductions, the discussions, and the lunches were all fantastic.
First day of talks
The first day of talks started off with the creator of Ruby himself: Yukihiro “Matz” Matsumoto. He discussed a new version of Ruby called mRuby that is specifically designed for embedded systems. He went into details about how he managed to get a grant from the Japanese government to work on this project. He expressed his desire to get Ruby code into realms other than web development, specifically embedded systems. mRuby will have Ruby version 1.9 compatibility, but will have a less functionality than MRI (which he says should be called CRuby, since he doesn’t even actively develop for it anymore).
Next was a talk by Piotr Szotkowski, which emphasized the fact that Ruby has a lot of very useful functionality built into its standard libraries. He went through a few examples of using some of this functionality by showing their uses in a gem he created called signore. The first thing he showed was a module called abbrev which is called on an array of strings or symbols and returns a hash that maps each possible abbreviation to the string it matches to. This is something that can be useful to create a tab complete in Ruby. He then showed how using the standard library you can create a simple HTTP server using WEBrick. And a simple TCP server using the gserver module. He also talked about the prime module which simply checks if a method is prime. He wrote his own method, and segued into the benchmark module by showing that the prime method in the Ruby standard library actually took 3 times longer to run than his method. He showed the ease of use of the benchmark module which would later be used extensively in another talk.
Next, Pat Shaughnessy took us into the world of ActiveRecord, to pick it apart and find out how it converts and everyday query like User.where(email: “<email@email.com>”).first into SQL statements, and then how SQL works in order to find this specific record. He showed how SQL will normally do a lot of work by doing a sequential search to find all records that match that criteria then chop off the first one and return it. He showed how adding indexes to things that are commonly searched on (in the above case it would be the user’s email) to speed up the SQL query. With an index it does a binary search through the records instead. He also showed how when there were a lot of records SQL created pagination so that it could work with blocks of records in memory rather than from the disk.
Later on in the day after a fantastic lunch (a full 4 course meal: salad, paella, fried calamari, wine, and dessert) Leon Gersing AKA Ruby Buddha, gave a talk that was pure motivation. His point was to step back and view problems in a different light. I have found that that has always helped me. Sometimes a good nights sleep, or a game of Dominion, or even just a quick coffee break can clear your mind, and let you rethink something complicated.
The last talk of day one was by Ryan Levick, who proclaimed his love for Ruby on multiple occasions during his talk. He used the concept of static typing, which Ruby does not have to make one simple point: Ruby is not the right tool for the job every time. There are other languages out there, and even though Ruby is amazing, it is not always the language you want to, or even need to use.
Second day of talks
The next day, we jumped right into talks at 9:00. The second talk of the day was one about writing fast Ruby. Erik Michaels-Ober talked about some subtle differences in Ruby syntax that can improve performance in your app. His goals were simple in this presentation: optimize at code level, improve performance by at least 12%, and maintain high quality, readable Ruby code. Here is a quick summary of what syntax is faster:
yieldis 5x faster thanblock.call(1..100).map(&:to\_s)is 20% faster than(1..100).map { |i| i.to\_s }flat_mapis 4.5x faster thansomething.map.flatten(1)hash.merge!(e => e)is 3x faster thanhash.merge(e => e)This is assuming that having this hash be mutable is safehash[e] = eis also 2x faster thanhash.merge!(e => e)hash.fetch(:something) { :default }is 2x faster thanhash.fetch(:something, :default)– this is because the block is only evaluated if the fetch doesn’t find anythingsubis is 50% faster thangsub- Most of the time we only want to sub the first thing anyway!
gsubevaluates the whole string (global sub)
tris 5x faster thangsub– so why does everyone usegsub?- Using exceptions for control flow is 10x SLOWER than a if statement!
- A
whileloop is 80% faster than aneach_with_indexloop
After this Jason R Clark took us on a tour of very useful Ruby debugging tools. He started with the stuff already built in. First up being the infamous puts which, in the grand scheme of things can have its uses. He then showed how the caller method works, which returns a stack trace where it is called (super useful). He also showed how the $! variable works. Whenever it is called in the code it returns the exception that is currently being handled. In the Ruby community we use a lot of gems, and sometime our errors stem from them. So debugging a gem could potentially be very time saving. Jason showed that you can open up any gem files on your current Ruby version very easily by writing gem open <gemname> or bundle open <gemname> in the command line. You can then make changes to the code to help debug. After that you can run gem pristine <gemname> to return the gem to its original state, basically wiping all the changes you made. This will make sure you don’t accidentally commit any debugging changes to your gems. He also spoke about a few useful gems, one of them being Pry. Pry is a gem that you can use to create a kind of breakpoint in the code that then opens an interactive console at that point. You can check instance variables, write code, and move around in the file using unix-like commands (ls, cd, etc). There is also a bunch of useful pry addons to step forward and back in the code so you can see in more detail what is going on.
The final few talks of the day went over various topics, from security to monads, and ended with robots. And dancing. With them. The last speaker had more of a demo than a talk. Julian Cheal showed some of the interesting things you can do with Ruby and robots. He showed the some things you can do with Ruby code to control everything from LED lights to drones. He even set up two flying drones to be controlled by a DDR dance mat and his phone. It ended up being a very spectacular way to finish off the conference.
And it ends
All in all the conference was fantastically organized, a pleasure to be at, and a great learning experience. The speakers were all great, informative, and motivational. The lessons were practical, and easily applicable. The problem I have with most talks at conferences is that the ideas are good but they are sometimes difficult to incorporate in your everyday work. This was not the case with a lot of the stuff this year. I am very happy about spending some time in Barcelona and attending this conference. I would like to thank everyone that made it possible, namely Codegram for putting in so much effort to organize such an amazing conference!