Baruco 2014 recap
Baruco 2014 is over. I was lucky to be there and soak in all that it offered. Let me share some of my thoughts.
Tapas
I arrived to Barcelona early enough to take part in one of the workshops prepared by organizers as a kind of a side dish to the main event. “Test drive a browser game with angular” held by Test Double crew – Zach Briggs and Todd Kaufman – was my choice. I figured this would come useful for my day-to-day work, as angular is our first front end choice here at Lunar. Although in technical terms I did not learn anything new about the framework – the code written during workshop didn’t go past simple controller, few ng-models and some ng-repeat here and there – there was a great deal of added value in what Zach and Todd shared between the lines. They took a stand in the ongoing debate on vitality of TDD, and their approach seems to be moderate yet reasonable – test drive your business logic, test drive complex parts but don’t be dogmatic about it. There are uses and misuses. And it’s crucial to remember that TDD is not only about feeling safe and having your back covered but more importantly is about design emerging from your code driven by tests. Having this in mind Zach led the workshop during which we wrote a pure JavaScript app entirely separated from angular, test driven with jasmine. Tasty!
First course
The main event started with a blow – dry ice, gig-like atmosphere, and all the conference heroes presented in a stunning animated intro. To be honest – I had mixed feelings about Baruco’s marketing theme. Superheroes? Seriously? You can hardly find a more exploited topic in programming world. But the Codegram crew had really pulled this one off. It was the perfect delivery with all the little details that made it work. And you could easily tell how it boosted everyone’s morale – the speakers’ and the audience. Being part of this made me feel great. But this is ruby community – that’s probably the right way to feel, isn’t it?
On the first day we had a pleasure to hear Yukihiro Matsumoto speaking about his current undertaking – mRuby – the smaller version of ruby interpreter dedicated for embedded systems. He made a nice run through various ruby implementations, dismissing each one of them as not good enough for embedded systems. CRuby* for instance is too much POSIX based. It was interesting to hear that with mRuby it may be possible to write software for vending machines, home automation or even some simplistic versions of satellites. Being a language designer as Matz called himself (as opposed to a programmer) seems like a cool job.
If you launch rockets I hope you don’t use ruby
Next came Piotr Szotkowski, whom I remembered for a great talk about Bogus he gave at this year’s wroc_love.rb conference. I was expecting yet another tasty technical presentation and I was not disappointed. Piotr talked about powerful, but somewhat hidden features of ruby stdlib. He showed good code examples and gave sound pieces of advice.
MIL**: Study enumerable module. Then study it again.
Don’t return nil from your methods.
Warmed up by @chastell, we were ready for heavy artillery. Pat Shaugnessy entered the stage digging deep into ActiveRecord, Arel and Postgres internals. He went through stuff like AST, visitor pattern, yak parser, btree algorithm, db indexes implementations and alike. Demanding topics, yet Pat managed to keep audience interested. Be sure to check out his newest book Ruby under microscope.
MIL: Learn the stuff down there, know the internals of the tools you use at least to some level – it will make you a better engineer.
The only lady among the Avengers – Emily Stolfo – had a much less technical talk on responsible release process.
Emily cleverly laid out her ideas dividing them into 3 main areas: maintaining simple API, clear communication and semantic versioning.
Check out my notes to see more details or watch Emily’s talk if your are responsible for any gems or libraries. I will definitely come back to it when the time comes for me.
MIL: Think of your API as a user interface and provide good user experience to establish and maintain what’s most important – trust.
Speaking of responsibility, enter Jose Albornoz with his talk about … irresponsibility. Coincidence? I don’t think so.
The youngest of the speakers took us on a trip through his personal experience of, what he called, a conference driven development.
In an entertaining way he described how he created the first ruby Gameboy emulator from scratch just to find out that it was… not the first.
Technical details were a bit dry but the main point was clear – find time to write irresponsible code just for the sake of it, learn and embrace the fun of coding.
MIL: You don’t have to know the difference between bits and bytes to write code.
So we are sitting there, half way through the day one and then comes this guy – Leon Gersing – starting with this quote from Las Vegas Parano. Yeah. This is going to be good. It’s impossible to sum it up – just watch it when it comes out, it’s worth your time.
MIL: Thought can’t be replaced by a process. You can’t adopt the culture without understanding it – this goes especially for Agile philosophy.
Also: The Perfect High
Main course
The last talk of the first day by energetic Rayn Levick, corresponded well with the first talk of the second day delivered by Brian Shirai. Both gentlemen talked about a recently hot topic – static typing and type safety, and whether we need it in ruby. Interestingly enough Rayn and Brain found themselves on the opposite sides (mark, not ends) of the problem’s spectrum, former pointing lack of types as a ruby’s weakness, the latter explaining how they can do more harm than good. If I was to judge – Brian presented a much stronger case. His talk was thorough, contained many cross references and left me with a huge material for further study. Having it difficult to grasp all on the spot, I will be definitely coming back to it.
MIL: Types don’t fit where there is much interoperability (objects). Programming is a behavioural science. Proposition as types = logic as types and it is not a good idea because we can’t really use logic well.
Having such a good start into the second day, we were about to see even better stuff. Erik Michaels-Ober enchanted us with beautifully illustrated and content heavy story of how optimizing ruby code for performance can be fun and not code obscuring. It turns out you can write fast and pretty code at the same time. Lots of good tips, simple code examples, each one backed by benchmark analysis. Watch the slides or check my notes for details. Fully professional talk from every standpoint. 10/10. If I had to choose only one of the talks to watch – this would be the one.
MIL: Performance optimizatoin can be fun and even have a therapeutic effect.
@sferik on misusing String#gsub where Sting#sub would suffice: "You're done, you've replaced it, move on with your life." sub is faster btw
— Tomek Rusiłko (@rusilko) September 13, 2014
Next up was Jason Clark on various debugging practices and tools. Well prepared talk, spanning across the entire scope of debugging options out there. I will be definitely reaching to this presentation in times of need.
There couldn’t be a ruby event without at least one talk about services. Evan Phoenix filled this spot nicely balancing out pros and cons of services, leaning towards conclusion: use services, when the problem becomes too complex to grasp. Definitely worth watching if you never used SOA or felt like you used it wrong. What I liked most is that Evan pinpointed some easy to follow good practices, e.g.: never share AR model between services, start with services that map to boxes drawn on the white board, do a fire drill once a month, have one convention of how services should talk to each other – set it and don’t discuss it too much, just like you don’t discuss method calls.
MIL: Every sufficiently complex problem domain will require an app larger than human cognition mass threshold, and team’s threshold is smaller than a single developer’s.
If an app is never deployed, was it written?
Did you hear about the Monad tutorial fallacy? In short it states that once you understand what a monad is you are unable to explain it to others. Seems like this no longer applies thanks to Tom Stuart (@tomstuart), whose presentation on Monads implementation in ruby left me in awe. Unfortunately I can’t explain it to you. Watch this talk when available, I dare you.
Book tip: Understanding Computation.
At this point my brain was swollen and we had still 3 more talks to go. I didn’t take much notes from them so let me just really quickly summarize: Matt Amonetti told a colorful story about pitfalls of cookie based authentication. Well prepared speech, definitely worth watching.
Tom Stuart (@rentalcustard) gave a somewhat vague talk about simplistic, 3-legged construction of lisps interesting features of Smalltalk, Lisp and Bash, that surprisingly make them impractical. As to why that is – he left us with an open question. Or I might have gotten it completely wrong. Last but not least we had some fun with blinking arduinos and drons flying over the stage in the rhythm of psycho gangam style. All of that controlled by ruby programmed PS dancing mat with Julian Cheal jumping on it. Not everything worked as Julian had planned, but nevertheless the audience was in sheer joy for good couple of minutes. Perfect ending.
Dessert
Conference organisers have done a tremendous work making attendees (around 500?) feel taken care of. The auditorium was comfortable, lunch spots offered great Catalan food and evening parties were fun. Conference announcer Jeremy Walker also didn’t stay behind, even managing to do some live coding on stage.
My thanks go to all the heroes and Baruco team amongst them. Great job. See you next year!
Oh. And Barcelona, you too.
* Matz argumented that we should probably stop using MRI name for his first interpreter and switch to CRuby.
** Most Important Lessons