Ariejan de Vroom – 7 June 2012
957 words in about 4 minutes

Kabisa got to attend EuRuKo, an annual Ruby conference that was held in Amsterdam this year. We got a chance at meeting lots of interesting people, listen to some great presentations and learn how to make great coffee. The official EuRuKo video gives you a great impression.

The talks

There were some interesting talks around solving specific problems, such as Sean Cribb’s A Case of Accidental Concurrency and Terence Lee’s Bundle install Y U SO SLOW. We got to meet some interesting ‘unfamiliar’ technologies, such as Erlang in Martin Rehfeld’s Ruby & Erlang, full object-orientation in Konstantin Haase’s Beyond Ruby and Rick Olson’s ZeroMQ: Supercharged Sockets. And then there were more in-depth presentations, such as Elise Huard’s Ruby’s bin men, Brian Ford’s Code Insight: Rubinius 2.0 and Nikita and Charles Nutter’s JRuby, dudes!.

But here some highlights of the the talks that stood out most to us:

“Ruby matches my brain. I know, I designed it that way.”

Matz told that developers use Ruby because it matches how their brains work. But one Ruby size does not fit all — if standard Ruby fits your brain but not your computer, you can use another Ruby. There’s already JRuby, Rubinius, Maglev and now Matz is working on mRuby: Matz’s eMbeddable and Minimalistic Ruby, which is aimed at small devices.

The great thing about mRuby is it’s small size and its use of bytecode. You can compile Ruby to bytecode and run it on the mRuby VM. This means the devise running the VM does not have to perform any source parsing and compiling. Another great feature is the ability to select which standard libraries to included. At this time the minimum size required for mRuby is only 200kB.

mRuby has been public for a couple of months now, and already is attracting some open source attention, but as of yet remains an “interesting toy”.

“We do not believe in the JRuby”

Vincent Marti explained that Github does not believe in JRuby. Rather than porting the codebase for to use the same JRuby codebase as the Github:fi project (no Github:enterprise), they did the opposite and stuck to a Ruby MRI codebase — not because MRI is better than JRuby (it clearly isn’t), but because Unix is better than the JVM. Complexity is the hardest to scale, and Unix makes that easiest. And Ruby and Unix were just made for each other. The JVM, regardless of improvements in recent years, is so complex it will become self-aware and turn into Skynet in a couple of commits, and this makes it much harder to manage as a server process.

Bruno Aguirre added some examples of problems we no longer need to solve ourselves, as they have been solved already — such as database-level data integrity. We can learn from each other and from the past by watching our own local communities, looking beyond to other communities and standing on the shoulders of giants.

“Happy little modules”

Roy Tomeij switched our attention from the back-end to the front-end and suggested we abandon the page metaphor for websites and embrace the concept of modules. A website can be regarded as a collection of independent modules that can be freely mixed and matched, allowing you to write your HTML, CSS and JavaScript around said modules.

“It’s not about the code. It’s about our understanding.”

Geoffry Grosenbach took us on a tour of lessons learned from working with some inspiring developers at Peepcode. He showed us examples of picking the right tools for solving a problem, achieving focus on the right problem, understanding problem context, reducing distractions in your environment and your code and how to manage your flow. The most important take-away was that as developers, we don’t work on code — that’s just a by-product. What we actually work on is our understanding of a problem.

“Without support, your code is just reference material”

Mitchell Hashimoto described some of the areas where the Ruby community can improve its libraries. We’re great at testing, but we often forget about some other aspects. We should provide proper configurability with an emphasis on clarity, not cleverness. It should provide the proper hooks and namespaces to allow for per-library logging and error handling. Documentation should not be an afterthought, but be maintained along with the code. And support is crucial, otherwise your code is just reference material. Even a mailing list or IRC channel can be enough to create a point of contact for other developers.

“Ruby & Erlang”

Martin Rehfeld showed how Wooga is using Erlang to manage more than 14 billion req/month and over 100k database operations per second. This was a talk about some real-world problems Wooga encountered with their back-end systems for Monster World. Wooga’s first attempt was to use Erlang to accept incoming connections and then passing those requests on, via ZeroMQ, to ruby workers, who’d do the actual processing. After testing this setup with bigger loads it became clear it didn’t scale as well as anticipated. Martin and his team rewrote their Ruby code to Erlang and saw a tremendous increase in performance, even for bigger loads. The most important thing that Martin Rehfeld showed was that Ruby is a great tool, but not always the right tool for your problem.

The take-away

Surely over coming days and weeks, more videos and slides will be published online so you can see for yourself. But after two days of talking with fellow geeks, interesting presentations and awesome lightning talks, it is clear the Ruby community these days is about more than Ruby. It’s as much its neighbours, about maturity and about practicing software craftsmanship. It’s an awesome community to be a part of.

Ariejan de Vroom

Software Engineer • CodeRetreat Facilitator • Ruby, Go and C Programmer • Electronics Apprentice