Arrrrcamp 2012: Pirates on Rails

This is an archive of blog post I wrote during my second venture (Sybil).

Why?🔗

As a developer, I think it's important to attend some tech event for several reasons: to be in touch with the community, to meet other developers, to see again some acquaintances or friends, to learn something new from known tech leaders, to discuss and debate some technical topics.

As a founder, in addition to all of the previous reasons, it is a situation that forces you to dig into the technical part of the job, with no or few interruption. The fresh air is welcome.

Last Thursday and Friday, we were at Arrrrcamp, the Belgian conference about Ruby, Rails, and other related topics in software and web development (and pirates!). As I'm not so a veteran in those technologies, it's the opportunity to confirm I've learned this year. It's also an occasion to present Sybil to some speakers and get feedback.

What?🔗

This year, the Arrrcamp was organized on 2 days and aligned an impressive bunch of speakers such as Yehuda Katz, Steve Klabnitz, Roy Tomeij, or Konstantin Haase. The event was still very well organized at a nice location and with good catering with the coffee and the sweeties. Two tracks of talk were available in parallel, that means you could attend 6 talks per day. After each day, you could take a beer, or two, at a networking event, chill out, meet new persons, and talk tech.

The talks🔗

Generally, the quality of the talks has improved since the previous session. But I would like less introduction in talks, and more sharp and high technical contents. With 40 minutes, it's a hard exercise, but possible. I also expect some strong motivated opinion from speakers because they are food for thoughts even if you don't agree. The humor is also a good component, and I have to admit there were fun and humor in lot of talks.

I've attended the following talks:

• Y Not? Adventures in Functional Programming by Jim Weirich,
• Dealing with Scale at Yammer: Caching and Services by Yann Armand,
• We don't know HTTP ( video) by Konstantin Haase,
• Crying over spilt cruft by Yehuda Katz,
• Bug Requests and Pull Reports ( video) by Adam Rogers,
• Static analysis and detecting security vulnerabilities in Rails ( video) by Dave Worth,
• Using Rails without Rails ( video) by Piotr Sarnacki,
• Modular & reusable front-end code with HTML5, Sass and CoffeeScript ( video) by Roy Tomei j,
• RubyMotion: Ruby in your pocket by Laurent Sansonetti,
• Why should I care about Rails 4 ( video) by Steve Klabnik, and
• Therapeutic Refactoring by Katrina Owen.

I won't go through all the content (and will link the titles with the slides when published/provided, most of the current linked presentations are not given at Arrrrcamp). I rather share some thoughts about some of those topics.

Showcase is good, numbers are better🔗

A showcase is always interesting because it demonstrates what's possible. The scalability experience at Yammer shared by Yann Armand is really interesting. Yes, the solutions are classic, but you know that if you have to serve about 6M users you could do it with that approach. But as Steve Klabnik discussed, you couldn't advocate for one or another solution only on hypothetical reasons. You should test and measure. That's the only way.

In practice, a system could vary from another one in so many ways that it's impossible to predict the result only from a canonical test case. The intertwining interactions between the different elements of a running environment are now so complex that you cannot embrace them all. You cannot predict the effect of an optimization without testing it, measure it, and understand it in a specific case.

Cache is not always the solution🔗

I've especially liked Konstantin's talk. He came back to the definition of the HTTP protocol and explain how it could be leveraged to make your application more scalable or secure. Before thinking about how to improve on the results, you should start asking yourself if you are using the protocol properly. Clearly understanding the elements you're building on top helps you to design better architectures. You just have to think them in terms of request, resource, and representation.

Help others to help you, and collaboration could happen🔗

Even if Adam focused on open source projects, I think he put the finger on a very important point for collaboration even in corporate environment. When there is a bug to fix, even if you know and can fix it, you shouldn't always do it especially if it was reported by someone else. Indeed, by doing it so, you waste an opportunity to help a person to learn and collaborate. Instead, it would be better to start a discussion and guide her to resolve the issue.

It's the same in company environment, code are not just the sum of subparts maintained by different and lone developers. As Martin said, the culture emerge because of the interaction of developers over the same pieces of code. That's why Martin and I frequently swapped our code assignations. That does use some time, but it's not a waste because it allows you to learn and progress thanks to shared point of view and discussions.

Reasons are more interesting than the resulting choices🔗

The choices or advices are always interesting, but explaining them even more so. It's relevant concerning talk but also code. When you just present your choice, you don't give to your reader or spectator the power to understand it or to apply the same path in similar situations.

Yehuda has very well underlined that problem with cruft. The cruft are usually results of choices supported by very good reasons. They resolved some edge cases or simply the mirror of the complexity of the real world and the human being. If you don't track those cruft and document them, i.e. providing the assumptions and reasons behind, you don't give the power to a future developer to understand why they are there. It's a big risk to not transfer that knowledge.

What's certainly true for weird choices is also for good choices. When Roy taught us his modularity approach in front-end development, he has always motivated his choices. Whatever the reason (e.g. maintainability, low coupling, factual performance, coherence), there was one. You may not agree (at least when the reason is not supported by fact), but you can at least think about it.

Don't tell, show.🔗

It's probably obvious and standard, but it's enough to restate it. It could be about functional programming, static analysis in Ruby, new features in a next release of Rails, or refactoring. Demonstrating it, it's concrete and easy to remind. Add some emotional element as humor or great Ross' paintings, and I'll remind it better. Thanks you Arrrrcamp speakers !

Arrrr🔗

Beyond the talks, we've also demonstrated Sybil to some speakers (Yann, Yehuda, Konstantin, Roy, and Steve) and got interesting feedback from them. We've exchanged opinions or experiences with other participants during the coffee breaks. We've enjoyed the lightning talks ( Big kudo for the new programming language: librarian). Definitively a good event, we’ll attend again next year. You should too. Arrrr!

You can also discuss that post on Hacker News.

If you have any comment, question, or feedback, please share them with me.

Subscribe to the blog!