Ruby Cristina Barcelona

Marek Nowak September 14, 2012

Sagrada Familia at Baruco 2012 Barcelona is truly a beautiful city. Our lunar expedition was amazed by its thriving narrow streets, colorful nightlife and exquisite cuisine full of strange sea creatures. But, surprisingly, these weren’t the reasons we came here. We came here to attend BaRuCo, to listen about Ruby, talk about Ruby, and meet fellow Rubyists from all over the world. How was it then, you probably wonder? Read on!

Marek: the first thing I noticed about the conference was it’s venue – a science museum. Whoever came with the idea of putting a bunch of nerds in a building full of bizarre contraptions demonstrating various laws of physics was a genius. I was eagerly awaiting the end of the talks each day just to see it all! Ok, it isn’t exactly true, because the talks were great.

I especially liked the talks by Github’s Scott Chacon and Zach Holman, who presented ways of getting your work done more efficiently, respectively by solving the most basic problems better than before, and by automating every tedious developer task that can be automated. Paolo Perrota did a great job by humorously summarizing the history of software engineering and showing its impact on modern developers.

Among the more technical talks I enjoyed ones by Gary Bernhardt and Xavier Noria most. The first one described the structure of modern web frameworks, ways of enhancing it, and pros and cons of every approach. The other one demystified the magic of Rails autoloading mechanisms.

Most of the lightning talks were also very interesting, with topics ranging from zsh tips and tricks to a game of go to how perseverance is more important than talent.

I really enjoyed the first Barcelona Ruby Conference, and I’m looking forward to the second one :)

Phillip: BaRuCo was hosted in the CosmoCaixa museum in Barcelona, which made for a very interesting two days because when the talks were over there was still much to do, although unrelated to the conference itself.

Baruco 2012 Macbook

The conference started out with a very good keynote by Scott Chacon, co-founder of GitHub, with a topic that was not technical, but rather a point about getting work done and creating software that solves specific problems by getting back to the basic principles set forth by the company or project, respectively. The remainder of the day had many enthusiastic and passionate speakers, most notably Gary Bernhardt with his talk about deconstructing the usual controller in MVC to smaller more single purpose parts, Anthony Eden with his talk about the protocols used in the programming community, and Paolo Perrotta with his very humorous, very interesting look into the history of Software Engineering and how we have come to Agile methodologies.

After the main speakers there was a chance for the attendees to give lightning talks that were time boxed to 5 minutes. These were very interesting, ranging from quick talks about helpful tips on apps to user, to a talk about the ancient board game Go, to a guy telling a story about hope. Let me elaborate on this guy and his story, as he reached his 5 minutes mark and was buzzed to stop, but received a wave of applause to keep telling his tale. Hope was the point of his talk, in that he was an average developer, like most of us are, and he made software that actually helped people and was a relative success. This story definitely resonated with me, and, I assume, most of the attendees.

The second day had talks that seemed to be less enthusiastic but ended on a much stronger note than the day began. All in all, I think this was a very nicely organized conference with quite a few good talks. The only really complaints I have is that the wifi could not handle this many developers in one room, and at the beach party there needed to be more beer.

It’s very refreshing to get out of the office once in a while, unglue yourself from that monitor and get some fresh air. You can’t code all the time, can you?

EuRuKo 2012 entrance

All of us in the company think alike and, as the EuRuKo 2012 was coming near, we had set our sights on that conference. We struggled and won the battle for the EuRuKo tickets, braced ourselves and set off for Amsterdam, the seat of the event.

Our trip went on smoothly, the biggest group travelled by plane, some people arrived by car and we nestled in the bustling centre of Holland’s capital. We’ve managed to do lots of sightseeing before and after the conference and were very eager to attend it.

The conference Thursday started with Heroku’s Hack Day on Rails, Rubinius and JRuby core during the morning and GitHub-sponsored splendid boat trip through the Amsterdam’s canals just to warm up before the very conference. Friday and Saturday were full of talks and lasted until late afternoon.

Marek’s thoughts

EuRuKo 2012 gates

I have really mixed feelings about this year’s Euruko conference. It was organized really well, the venue was just gorgeous; there was only one area that disappointed me – the talks.

And that’s really unfortunate, because, well, the talks are the most important point of such an event, and after the conference’ s first day I seriously considered trying another programming language – it was so uninteresting. The second day was a bit better, there were more technical presentations, but still I was expecting more of the event.

Adam’s impressions

This year’s Euruko was the biggest one I have attended to date (and perhaps the biggest Euruko yet). Like in Berlin the year before, the organizers chose a cinema for the venue, which is a great choice for a single track conference with over half a thousand attendees.

The number of attendees was high, but the conference didn’t feel crowded. This is mostly thanks to how spacious Pathé Tuschinski, the cinema in which the event took place, is. It was also one of the very few Polish accents (the cinema was commissioned by a Polish immigrant in the 1920s). It’s a shame that there weren’t more of them, and especially that there were no speakers from Poland.

EuRuKo 2012 Lunar Team

Meritorically, the conference did not live up to my expectations. The first day was filled with barely technical talks, and even ones that had nothing to do with Ruby at all. The second day was more interesting, with great talks by Konstantin Haase and Charles Nutter (although I think I heard most of the JRuby talk once or twice before). Traditionally, the lightning talks were usually more interesting than the regular presentations.

In my opinion, with Euruko growing more popular and larger every year, it would be good to reexamine its format. So far it has been a very “eyes-forward” conference, with almost no audience participation. I would love to see open spaces included in the schedule. I would also like the conference to have multiple tracks – even as many as four or five. I believe that the large number of attendees is a great feature of Euruko, but the single track format does not scale well to this conference size. I am looking forward to what Athens has in store for us next year.

Kuba’s opinion

The talk I liked the most was Geoffrey Grosenbach’s keynote on the second day about watching people code. He basically did a set of interviews with well known Rubyists and gathered a whole bunch of technical and more general tips about how to be a good programmer. Some were more obvious, some rather surprising (e.g. if your code is wrong, throw it away and start from scratch), but most were inspiring in some way.

There were a few other good talks, but they were usually the non-technical ones or those not related directly to Ruby – how to make a good library, how to follow the Unix philosophy and apply it in your projects, or how to write maintainable frontend code. What I missed was a few more good technical talks on a more advanced level, where people would share their experiences with various approaches to e.g. creating APIs, designing app’s architecture or scaling apps – a few of those were on the list of proposals, but somehow they didn’t make it to the final set.

Like the rest, I also had the feeling that the conference wasn’t as good as it could have been. Everything was great in terms of organization – the WiFi worked well and the venue itself was amazing – but the choice of the talks could have been better. It was a great idea to use GitHub pull requests for talk proposals, but maybe a better tool to gather community’s opinions and votes would have helped. Also, a lot of the talks seemed to have too little content for the assigned time – perhaps it would be better to timebox them to e.g. 25 minutes and have more talks this way? Judging by the lightning talks, a few of which were really good, it’s easier to make the talk interesting if you have limited time and you have to pick only the best parts.

A word from Hania

This was my first RoR conference, so, after having heard positive impressions from my colleagues, I’ve had big expectations. Unfortunately, I could hardly find any concrete and technical presentations and those few having these qualities were so mumbled out that I wasn’t able to follow them. I was anxious about the garbage collector presentation, yet it was very poor and I guess the majority of the audience was very disappointed. The second day turned out on much better, especially the Rubinius and JRuby presentations. However, generally speaking, the event confirmed my preconception that either someone is an attention seeker and does fancy presentations without much content, or somebody possesses huge knowledge, though unluckily lacks the skills needed to present it in an interesting way. That’s a pity, because the event could be much more inspiring.

Marcin’s view

Amazing city! Amazing venue! Really great time! When I think about this year’s EuRuKo I have only good memories in my head.

Talks weren’t that interesting, true. Why? Because information in today’s world travels fast and we already could have been reading about many of things presented on EuRuKo on Twitter/Ruby Inside/etc…

Role of the IT conferences in recent years changed (or should change). I’m not expecting to learn new stuff on them anymore. I’m expecting great atmosphere and a lot of smart people to talk to. And I can say it was exactly like this.

To sum up: Good job Amsterdam!

More photos of the event.

You want to have your terminal sessions recorded and can’t find a man for the job? Hire!

I bet that your terminal has more than once witnessed and hardly withstood the grandeur of your code. You know, a moment of epiphany, when you truly understand the nature of things, become one with the universe and spawn little animals using only your thoughts.

It would be ridiculous to keep such brilliant knowledge to yourself, wouldn’t it? Say hello to our little friend –, the terminal scribe. It’s a brainchild of our seasoned Ruby engineers, Marcin “sickill” Kulik and Michał “Sparrow” Wróbel. lets you record your terminal sessions and share them with other geeks simply by running the ‘asciiio’ command in your terminal. It is fully open-source with the aim of being a “go to” place for terminal users wanting to share their hackery.

You can see it in “Vim colorscheme showcase” here: vim screenshot

The terminal scribe is very self-reliant – it has virtually no dependencies on anything except Python (which is pre-installed in Linux and OSX) and it’s very skillful – the web based player is an implementation of VT100/VT102 ANSI terminal, supporting most ANSI sequences, all text attributes and 256 colors. is lenient – you don’t need to create an account beforehand, but can do it after the recording if you want to claim your recorded sessions. It is also easily accessible, for it’s fully open source (both recorder and site/player) and everyone interested in building the greatest recording platform for hackers is welcome (source: and It is built from many parts written in Python, Ruby, CoffeeScript and bash so anyone knowing any of these languages can help. has a quaint sense of humour – it beautifully plays Nyan Cat via telnet ;) Nyan Cat!

or if you haven’t seen Star Wars in ASCII then here’s a trailer:

But, it’s serious after all – it was officially released at wroclove rb conf in Marcin’s lightning talk.

The terminal scribe is easy to work with: to install or upgrade

recorder, open a terminal and run following command:

$ curl -sL | bash

(when using zsh you may need to run rehash after above command)

That’s it! Now you can start recording your terminal sessions with:

$ asciiio


One of the practices espoused by kanban teams is to “make rules explicit.” However, after asking several times in forums and on Twitter “How do you make rules explicit?” without ever receiving an answer, I am inclined to suspect that many teams don’t, in fact, have a good way of capturing and sharing team rules. At Lunar Logic, we’re big fans of BVCs (Big Visible Charts) and our walls are covered with information radiators in the form of charts, graphs, and process lists. We’re also passionate about software quality, and so I’d like to share some of our QA process tools that serves as one way in which we make rules explicit in our teams.

Ask most people what software quality means, and you’re likely to get an answer related to the absence of “bugs” in which bugs are usually defined as features that don’t work. Too many software teams primarily address this facet of quality by eradicating bugs. That’s all well and good, and the world would be better if we could find and fix the many bugs that live in our favorite software, but this is a woefully incomplete picture of software quality.

The four dimensions of software quality that we’ve identified are these:

Well-structured, cleanly-written code with good automated test coverage which is easy to work on and follows standard conventions and coding practices with clear style guidelines that are consistently followed.

This allows new people to join the team or for a product to be handed off to new team easily. It makes it easy to add new features or to refactor code without fear of breaking existing functionality.

Good design with an architecture that allows for efficient and appropriate scalability.

Not every web application is going to have to support millions of users, but just in case the architecture should be such that migrating to cloud hosting or to a distributed delivery model shouldn’t involve massive refactoring.

Excellent quality software is a pleasure to use.

It’s not enough that the features work; they should work in a way that is intuitive and pleasant for the users.

And finally… in high quality software the features work as intended.

Without awkward workarounds or… bugs. This doesn’t just mean that the feature isn’t broken, but also that the need was clearly understood and appropriately addressed by the development team.

Every project team has its own way of ensuring high quality in each of these four areas, although some practices are embraced by everyone in the company based on experience:

all teams at Lunar Logic do pair programming and have peer code reviews on all commits. Architectural quality is reviewed periodically by having cross-team code reviews. Hallway testing new features and design changes helps to address usability issues early.

We tailor new practices according to a particular product or environment. The important thing is that every team is thinking about standardizing a set of quality practices that maximizes software quality in all four dimensions so we don’t end up with a product that looks great, but doesn’t work, or works great, but doesn’t scale.

What you might notice is that in no place in this article have I referred to software testers, or QA engineers. We have them, of course, and we highly value the perspective and skill set that such professionals bring to a team, but it’s important to remember that software quality is the responsibility of everyone on a software team, and team QA practices reflect this fact.

Using the chart

To emphasise the importance of other dimensions of software quality, at Lunar Logic we collect practices on a wall chart with four quadrants.

QA graph example

We print this chart on A0 paper (that’s a big poster size) and put it on the wall in a team room. Proposals for quality practices that come out of retrospectives are added using post-it notes and if they prove to be good ideas, they are written on the poster. These practices should be detailed enough to be consistently followed.

For example, rather than “hallway testing” we might write “When a programmer has finished work on a feature, she asks someone who’s not busy to use the feature without guidance or prompting in an IE environment before the feature is marked as ready for a code review.” Making the rule very specific in regards to who does what and when makes it far less likely to be ignored or sloppily implemented.

How do you make QA practices visible and keep them evolving?

Here’s the QA Practices wallboard chart in case you’d like to use it!

AirCasting logo

Have you ever wondered how loud, exactly, is that noisy crossroads that prevents you from having a well-deserved sleep? Is it really comparable to a herd of starting jumbo-jets pursued by a swarm of fighter planes? How could anyone put up with this madness?

Worry not – we’ve got a solution to your problem and it’s called AirCasting.

AirCasting is an Android application that measures noise pollution. It’s a light, flexible and free-for-all Android app we created for with funding from Google’s Charitable Giving Fund of Tides Foundation.

AirCasting sessions

AirCasters measure sound levels, which they can choose to contribute to a crowd sourced map of noise pollution. This allows everyone to see the best place to either walk your dog, wind down and meet your mates or, simply, test your brand new protective earplugs.

All right, all right, you may say. Buzzwords don’t impress me anymore. I would like some facts. How does it work in practice?

Sound level measurement started in New York City. Its inhabitants complained about noise to a City hotline. The usual hustle & bustle affected their sleep, health and overall well-being. As a tool to justify their claims, AirCasting becomes a vessel for public opinion. Local authorities may dismiss one claim unsupported by any evidence, but what about hundreds of noise pollution reports made on the spot?

AirCasting has been developed by three Lunar Logic pros: Paweł, Marcin and Grzester (he was testing the app). I’ve asked Paweł some specific questions about AirCasting.

AirCasting sound graph

Mirek: What does AirCasting do, in a nutshell?

Paweł: AirCasting is a platform for sharing and visualising environmental data. Currently the only supported kind of data are noise levels. These can be obtained by users with their phones and then shared through our website.

M: Which parts of the smartphone does it use?

P: Most prominently we are using the microphone to gather noise level data. Other than that we are using Google Maps to visualise the data the user and others have gathered.

M: Are there any planned extensions for the app?

P: The app is planned to support a wide range of environmental sensors with which it will connect via Bluetooth. The one that’s being engineered right now is a gas sensor for measuring pollutant concentrations in the air.

AirCasting has been live since 20th December 2011 and is available free from the Android market. The source code is available under GPL: