h1ghlevelb1ts

It was about time to do a Ruby conference. My new language of choice needs to be taken care of. So I decided to join nordic ruby in Gothenburg this year. I heard lots of good things about the first version a year ago so it was not hard to make the case of going.

The conference is located in Eriksberg an old shipyard area of Gothenburg. The venue is an industrial building remade into a hotel so we are basically living the conference for 2 days.

The first day started with github founder Tom Preston-Werner that talked about some of the useful practices they use. Readme Driven Development is about doing just enough of specification before you start coding. TomDoc is human readable code comments that is sweeter to the eye than rdoc or yard. Semantic versioning is by no means a new thing. Tom talked about how it enabled them to modularize heavily without getting lost in dependency hell. All in all a nice talk that shows how it is possible to build something useful with a couple of simple and powerful practices. Much of what Tom said might seem obvious and every simple practice is - the challenge is to not add any other complexities.

Anthony Eden talked about good APIs. "If you are a software developer you are an API designer." We should think about all our work in terms of it being an API. He introduced the 5 C's - consistent, clear, convenient, concise and complete - characterizing a good API. Then some examples. Net::HTTP was trashed to shreds in a funny way. The same task made good was shown with Typheous and a non-API approach with openuri (that extends the standard File class with URL behavior).

Thorben Schröder made a swift dive into a new set of tools for avoiding code duplication in javascript/ruby applications. Apparently there are several new libraries for interchanging calls between ruby and javascript. Definitley something to look into a bit more.

Joseph Wilk talked about a concept called the limited red society taking its WIP counterpart and zooming in on the coding process. The point being that the red phase in coding when test fails basically means "work in progress". He talked about using different metrics to get feedback from your process. Questions like: "how long have I been in red for each coding step?" can help us improve our internal processes. It can also be a useful ground from which to start dialogue in a group of coders. But as always metrics are useful but shouldn't be seen as a nirvana. They are not the bigger picture but they help us build it.

Over lunch I had the opportunity to meet up with my cousin that develops software for Volvo car engines. Always interesting to hear about a different kind of development. I also got to ride in a test car!!!!

After lunch started of with Joshua Wehners talk on diversity. Our industry has always been kind of single minded and the Ruby community may be even worse with its huge majority of young, white males. Check out the page for the rails core team. Joshua made a good case to what we would gain with an increased diversity. He backed this up with all kinds of data from different studies. One interesting study shows that lucky persons are more likely to try new things than unlucky ones - meaning that it might not be so much about luck as about a different mind set. Being among the oldest in the room (at 39.....) I may have increased the conference diversity by a little.

After that there was this really speedy talk about statistics by Randall Thomas. He started with pointing out some problems with the standard approach to statistics. For example when we say that there is a 50/50 chance of getting heads when flipping a coin we assume that this is true over an infinite number of tries. So it is a purely theoretical stance. He went on to describe bayesian nets that are a technique where previous results affect upcoming results and then he showed some really cool thing that is doable with some csv data and a ruby library for bayesian nets.

The last scheduled talk of the first day was about education by Joe O'Brien. It was about the common frustration that is present at all conferences with brilliant people. What shall we do with the others? How can we improve the overall quality of our business? Some take aways from this session was the difference between a programmer and a developer. Most of us are actually business developers - we don't need to understand most of the technical details. It is all about getting the right software delivered to our customer.

Then a round of lightning talks - entertaining as they should be. Dinner party outside next to the river cafe - a bit chilly but a great time!

Saturdays first speaker was Paul Campbell with a speak entitled In search of 'Mé fein'. (me fein = myself) He gave us a swift retrospect on his life described as the days of the week. It was intertwined with links and fun stuff from the week. Some really fun stuff and some thoughts to bring home.

Elise Huard used movie style slides to her talk about actors - a nice way to parallellize the execution of programs. Sadly there is no native support for this in Ruby and apparently no plans of doing it either. On the other side of the coin it is possible to use scala actors via jruby (and I guess erlang actors via the jvm erlang that is in the making).

Jakob Mattson - the only local speaker talked about how Ruby is such a static language. You can't define anything you want in Ruby. Say you want to write javascript in Ruby for example => not possible. Say you want to change the meaning of . => not possible. This may or may not be useful. Most programmers would benefit from more restrictions - not less. Using a DSL may be good sometimes but in many cases it is better to stick with a general purpose language like Ruby and just make sure that the code is as readable as possible. Nevertheless - this was a really thought provoking talk and I hop that Jakob gets more than 15 minutes next year.

Ryan R. Smith of Heroku described some work he did with getting real concurrency into a job queue application. It did not include queue software but "just" nice and simple use of a database. It fit well with my conclusion that we buy lots of software for no reason when there is a nice, simple and scalable solution close at hand. Strange that is should be so hard to stick with simplicity.

Then some tenderlove from Aaron Patterson about dealing with legacy systems. He showed a number of sweet ways to alter a legacy code base without too much of a risk. And a key conclusion that I actually have done myself: mocking and stubbing and whatnot is not needed when using Ruby. The meta programming capabilities built into the language makes it very easy to build around any problems that you would have to work hard to mock/stub/whatnot in Java. Gave me more inspiration to delve deeper into the inner workings of Ruby. I *get* most of the techniques but I am not skilled to use them wen needed. (And as seldom as possible since the readability of the code probably goes down a bit....)

I was looking forward to the talk by Chad Fowler and I was not disappointed. His talk was also about legacy but in a positive way. How do we build systems that becomes our legacy - that will outlive us and seen as great software generations from now. He did not give a clear answer to that question but certainly put a nice perspective on things. Software that has survived since the 70s or so are typically smaller pieces like unix tools or the apache web server. A conclusion of this is to build systems from small parts or cells that in themselves can become a great legacy over the years. I don't know if it is important to be remembered after I die but to be able to make a contribution that is useful would give satisfaction for sure.

The concerence ended with a ironman talk by Keavy McMinn. She basically went through how she prepared for the ironman and the succeeded over expectations. I like this cross discipline thinking that the ruby community gots lots of. Coding is not only about technical details but also about personal development and we can certainly learn from many other areas about this.

This was a great conference and I will probably attend again. The opportunity to meet so many great developers is truly something. I was a bit surprised about the lack of technical depth - just a couple of sessions actually had code in them. This probably reflects that the audience at a conference like this already know it all about Ruby. A newcomer to the language would not have much to takeaway in terms of new knowledge about the language itself.

More information and links about the authors at the conference site. All my amateur pictures from the conf is over at flickr.

Finally a thank you to CJ and his team from elabs that made this such a great event! Even the coffee was great.