This year, Skroutz sent a bunch of developers to attend the Barcelona Ruby Conference. The presentations on Baruco ranged from running a business and programming methodologies down to tracing and debugging code and the very internals of Ruby itself.
The way we work
Scott Chacon reminded us that we are like artists, we do creative work and we should work when we are creative. We should not be held back by the assumptions of the past and we should question and redefine our first principles. Things like working hours, office space, meetings and anything else we take for granted when we think of work are fair game for hacking and experimentation.
Michał Taszycki reminded us that we are like athletes, we have programming muscles that we have to take care of and offered us a way to do some programming exercises to stay in shape.
Paolo Perrotta reminded us that software engineering is less engineering and more science. After going through the history of methodologies on programming and the failures of trying to treat it like some form of engineering, he came to the conclusion that the agile method is in fact the scientific method applied to programming.
Zed A. Shaw reminded us that we are all quite different and each project we work on is unique enough to render all prior best practices obsolete. Each developer/project combination has its own best practices that may or may not include behaviour-driven development, agile, continuous integration, continuous deployment, todos and other methodologies we have grown to love or hate. In essence, a little like Scott Chacon said, question your way of work.
Zach Holman reminded us that we are programmers and that we could and should automate everything. There is no reason a new recruit can’t have his/her workstation up and running in 20 minutes. There is no reason for a new branch not to be automatically tested. There is no reason a new feature can’t be deployed effortlessly within the same day.
Machines are for doing stuff. People are to drink with.
The code we write
Elise Huard helped us get a
grip on the code we write by presenting an overview of some Unix
tracing tools like trace
and OS X tools like Instruments
.
Randal Thomas & Tammer Saleh shared their experiences with RubyMotion and some of the reasons they think it is not for production work. The main reasons are RubyMotion relying heavily on Objective-C and its libraries and also being a second rate language in comparison to Objective-C (almost all tutorials, documentation and examples on iOS development are written in or about Objective-C). The overhead of having to translate from Objective-C to Ruby is usually not worth the effort and totally confusing when having to pass the project to someone else to continue.
Mostly based on the Rubinius dynamic language environment, Brian Ford’s presentation focused on his goal, to change the way we write and run code. Deploying code that actually works while producing no errors, does not mean you are done. There is a separation between the states of writing and running code which should be less distinct. Digging into data/error flow analysis and a database of compiled code could lead to conclusions that will probably help us write much more optimal code.
Alex Koppel is the lead API developer at 6Wunderkinder and author of Koala gem, a large collection of Ruby wrappers upon Facebook’s API, thus he has a thorough experience on writing well structured and solid APIs. The most interesting part of his talk is the batch_create idea, inspired by DHH’s proposal for bulk requests on Rails 3.2. It is a step forward on the API request handling, because you can save a significant amount of bandwidth (batch API requests will reduce the HTTP overhead) which is one of the core targets of every connected mobile application.
The way we look at our code
Gary Bernhardt offered an alternative to the whole MVC framework which we have already injected with presenters, decorators, observers, and other conventions to help us keep controllers thin and models manageable.
Josh Kalderimis offered an insight on the way the Travis team is monitoring the beast that is Travis-CI and all its components. He demonstrated an efficient way to log events and benchmarks to monitor the performance and error rate by utilising ActiveSupport::Notification and some external tools like librato, graphite and metriksd.
The way our code works
Xavier Noria dissected the Rails autoloading process. He gave us an insight into how constants work in referring to each other and how Rails looks up in the filesystem for missing constants by first looking at the specific scope we try to access a missing constant from and then gradually moving to more generic scopes. He was one of the few to be applauded for his geeky presentation software which he wrote himself.
The Konstantine Haase
described the method dispatch and how is this implemented in order to
achieve performance in the Ruby 1.9 VM, inline caches and JIT on
Rubinius and invokedynamic
on JRuby. He explained how almost all
Ruby implementations have two common goals: finding and executing
methods as fast as possible and the way the 3 most common Ruby
implementations try and achieve those goals. He then line-by-line
described basic CRuby hooks that execute when calling a method as well
as he digs into their equivalent instruction definitions.
Conclusion
Baruco 2012 was a marvellous conference offering a broad range of perspectives on all the facets of the life and work of a Ruby developer. The CosmoCaixa museum was one of the most perfect locations for geeks to converse, containing both robots and dinosaur fossils for geeking out and a great auditorium to hold the presentation. Apart from the palpable wifi connection within the conference, we had a great time in Barcelona, the beach party was without a doubt one of the highlights of the conference and the organisation was spot on. As we anxiously wait for the presentation videos from Baruco to be released, we are looking forward to our own Euruko 2013 to start getting organised.
Some photos
We did encounter a real-life capybara inside the CosmoCaixa museum.
One of the familiar sightings during the conference.