Engineering

About the conference

The conference (#rubyunconfeu) took two days and was located in the facilities of the Hamburg University of Applied Sciences. It was organized by the volunteers of Boot e.V., who did a great job. Around 200 participants enjoyed a keynote, 20 talk sessions and a handful of lightning talks.

The really interesting thing about Ruby Unconf is that it is an unconference. This means it has no program committee that crafts a schedule in advance. All participants can bring in their own talks instead and pitch them in the opening session of the day. Everyone can afterwards vote for the talks with emoji stickers. As the resulting schedule consists of talks that participants are interested in, engagement with those talks is generally high.

I also appreciated very much that it is people "like you and me" who give talks at the conference. The talks were focussed on everyday software engineering problems rather than singular problems of big engineering companies. Although the conference has "Ruby" in its title the talks were not constrained to that. Other technical topics were also covered, as well as purely non-technical aspects of software development.

You can get in contact with literally everyone, and everyone that I talked to was open-minded and willing to share. This might very well be due to the unconference concept. The event is not too big and you quickly get to know many of the faces.

Now I want to share some interesting sessions with you.

How do I review the code

Denys Yahofarov of solarisBank gave his personal insights on what makes a good code review. His principles are:

• Code in master brings value - keep focused on that
• No software is perfect - comment only the important things
• Respect your contributors - they deserve it
• Choose your words carefully - think twice
• Use a clear language, and wrap up your individual review comments in a final summary
• Playing code review comment ping-pong can waste a lot of time - switch from async to sync communication were necessary
• Be positive - don't only criticise, but also praise what's good

I think reviewing code in a Github-PR-review like process is a good habit and a great step forward towards better quality. If you don't do code reviews today, you should start it. If you do it already, this talk might give you some nice pointers. Having said that, I think that even better than code reviews is to pair frequently. It gives you the same achievements - sharing knowledge, and ensuring quality -, but faster, and at deeper level. (slides, video)

No estimates - user stories without estimating effort

This session wasn't a talk, but a fishbowl discussion. I never attended one before, so I think this deserves explanation. In this discussion format five chairs are arranged in the centre for the discussion participants. This is the fishbowl. The audience is seated in circles around the centre. One chair in the fishbowl must always stay free. Everyone from the audience may occupy the free chair at any time, and then an existing member of the fishbowl must leave. This format allows for much participation, and fits very well with the open-minded atmosphere of the conference.

Now to the topic. The #noestimates movement advocates that you work on your user stories without first estimating the effort. The rationale behind this is that the outcome of estimating is not worth the time spent for it. During the session it became clear to me that this is already the crucial question: What do we need the estimate for?

The spectrum of answers is wide, but the general gist is that we need the estimates to plan ahead. And it depends on the consequences of failing that plan how accurate the estimate should be, or if it is necessary at all.

Tina Umlandt, the moderator of the fishbowl, is working as a project manager in a software development team. They follow the no estimates approach. Instead of estimating the necessary time or story points for a user story, they decompose every story into all steps that are necessary to implement the story. There is a constraint: no step may take longer than one work day to implement it - in that case it must be broken down further.

I haven't tried this out yet in any project. Whether you're estimating effort for a user story or breaking it down into implementation steps - you have to think it through. I just think that with the first approach you are more prone to gloss over relevant details.

Settings - a clean way to handle custom configuration values

Every application depends on environment variables for configuration. Usually, they are directly accessed via ENV['MY_VAR_NAME'], and this is spread throughout the code. If you are thorough, you might even document all environment variables in the README - that's what we do.

Andreas Finger suggests a different approach. What if you centralized all environment variable access in one single file? That would spare you the extra documentation. And what if you required that single file in the rails initialization process before anything else? That would prevent any load order surprises. Now if you spice that up with very few convenience methods, you can comfortably access the settings in the rest of your code. The amount code for this is so small that it doesn't warrant extraction into a gem. You can just copy it into your application.

PgHero - A performance dashboard for Postgres

This session was a short five minute lightning talk. It introduced PgHero to us. That's a nice web UI that helps you to tune Postgres database performance. You can see slow DB queries, duplicate indexes, tables taking up much space, and other useful stuff. PgHero can be mounted into your Rails application as a Rails engine, or you can get it as a Docker image.

After the conference I gave this tip to a colleague. He directly tried it out. The integration into the Rails app went smoothly. The first results looked interesting. Now we have to see if we want to have this additional dependency in our app for the long term. (video)

Conclusion

I really liked the whole event. It has a very nice atmosphere and definitely was worth the journey to Hamburg. Maybe I wouldn't go there every year, as a "real" conference or a conference with a different focus also interest me. But if you're into Ruby, I advise you to try out the Ruby Unconf for yourself at least once.

The next unconferences on my radar are the SoCraTes International Conference for Software Craft and Testing (August 22nd-25th) and SoCraMOB Open Space (September 7th). Given my experience with unconferences there is a good chance you will see me on one of them.