We've just got back from RubyDay2016 – a conference you've been waiting for for a long time. The event turned out to be a perfect feat of organisation. The speakers very thoroughly prepared for their presentations, the coffee was delicious, and the food was exquisite! Below, you can read a little bit about the presentations that we found the most interesting – we will remember all of them long after the conference.
Xavier Noria, a member of Rails' core team, opened the conference with his keynote speech. Xavier demonstrated how to write better-looking code on a number of clear examples. The keynote was probably of great use for junior developers (it used examples such as `array.max` > `array.sort.last`). Unfortunately, anyone who's had more experience with Ruby might have been utterly bored.
Mailchimp's Kylie Stradley tried to come up with a taxonomy of bugs that we experience every day, based on their causes, occurrence times and reproducibility. Taxonomies like this are aimed at helping developers to fix code issues. Stradley started off with straightforward issues that can be easily spotted already during testing. Next, she went on to give examples of more severe cases such as an invalid object in a database, and she finished with issues that have the potential to blow up the entire application (no disk space available, a corrupt database, etc.). Each bug in the presentation got its own picture and a unique name, and the presentation was really engaging – even though the topic itself wasn't extremely interesting.
Another talk about elements of functional programming in Ruby. At the very beginning of his presentation, Estes said he would like to be just as funny as Aaron Patterson, but he doesn't have any cats. In the event, his presentation contained countless pics and gifs of Shiba Inu dogs. The talk *was* full of humour, and it was a pleasure to listen to it. As far as the content itself is concerned, most of the presentation was devoted to 'pure functions'. Pure functions are functions that will always yield the same output for a given input, regardless any 'external' circumstances (the database, file system, the app's state, etc.). They also never give any 'side effects' such as mutating the states of objects or introducing changes to a database. Besides pure functions, Estes told us a little bit about the Method Object pattern and immutable objects. All of that is supposed to make testing easier and make our code ready for the future, as soon as Ruby is able to support parallelism natively.
Yet another talk that included concepts of functional programming. Simone aimed to demonstrate how working in Elixir, Go and Crystal had improved his code, but he only managed to talk about the first two. As far as Elixir is concerned, Carletti showed the concept of stateless business logic. Stateless business logic makes testing dramatically easier and eliminates the problem of mutable states (some methods in Ruby change values at unexpected times). What Carletti borrowed from Go was dependency injection – a concept that is very unpopular in Ruby. Many OO programming languages take advantage of dependency injection, which makes testing easier and allows them to change the behaviour of an object quickly just by changing its dependencies. In Ruby, though, we've got a wealth of simple ways to stub/mock, so DI isn't very popular, and many people regard it as too difficult.
Danielle Adams and her colleagues from Blue Apron have prepared recruitment tasks whose aim was not only to verify candidates' command of Ruby but also whether they can think logically and build efficient algorithms. Candidates would have to write their own version of a selected Ruby method (.map, for instance). To be able to assess candidates' skills, Danielle Adams took up the gauntlet herself and started to write her own solutions. When she had analysed the solutions she had written, it turned out that some of them execute faster than the original Ruby methods. For instance, using 'while' loops instead of 'each' improved the performance of a given method. Further on in the project, Blue Apron developed "therubyracer", a gem that allows you to challenge Ruby's original methods and check whether your solution performs better than the original. In the course of the presentation, Danielle Adams showed a few examples of methods that are faster (or slower) than their original counterparts. It's worth mentioning that a given method's performance also depended on the type of input.
Danielle said that she had never aimed to contribute her solutions to Ruby itself. Neither had she decided that she would always use 'while' instead of 'each'. Her presentation's ultimate objective was to inspire other developers to perfect their skills through constant practice, to go back to basics and to play and have fun with the language they use on a daily basis.
Luca Guidi's presentation didn't contain a single bit of code. Luca spoke about the problems he came up against when working on his open-source project, one of which was when he got forced to change the name of the project from Lotusrb to Hanami because the original name was too similar to IBM's Lotus. Guidi also gave some advice on how to encourage other people to contribute to your open-source software.
In his presentation, Benjamin Roth focussed on our dearly beloved Service Objects. He started off by saying that some Rubyists believe that it is beneficial to transfer the application logic from controllers to models, so that the latter become big and fat.
Since Rails are based on MVC, many people stop at the three fundamental layers, which often results in logic placed in views, big controllers, or even bigger models. It's actually beneficial to put application logic in services. Services usually are smaller, easier to test, and it is more straightforward to reuse them when need be.
The key element in Roth's presentation was the advice on how to deal with error handling when executing multiple services in a sequence. Roth presented his own gem, waterfall, aimed at simplifying this type of error handling.
The gem introduces one place that handles errors: the `on_dam` method that takes over the block. Roth very clearly explains how to use the gem here.
Piotr Solnica's keynote on the history and future of Rails concluded day one. The first key event in the development of Rails (apart from the initial release) was the coining of 'skinny controllers, fat models'. That was when the community realised that storing everything in controllers might not be the best idea. As a result, everything ended up in models, which wasn't that great either. In the meantime, 'Merb' was created and it turned out to be the cure for Rails' ills. Since the aims of Merb and RoR overlapped to a great extent, Merb was incorporated into Rails (in Rails 3). In 2012, ‘7 Patterns to Refactor Fat ActiveRecord Models’ was published and became a milestone in Rails' development. The patterns laid out in that blog post have been used by Rails coders ever since.
Having summarised the history of Rails, Piotr went on to discuss alternatives to RoR and demonstrated the 'dry-rb' package. Many of you will have heard of 'dry-rb', so I'm not going to elaborate on that here. The presentation concluded with Piotr's call to everyone: “Let’s continue exploring & innovating.”
The second day of the conference consisted exclusively of workshops. I started my day by attending a workshop on Hanami run by the framework's creator. Guidi presented a full overview of the basics of coding in Hanami, because many people in the room hadn't done anything with the framework before. The workshop was really interesting but only for people completely new to Hanami. Anyone who had written even the most basic CRUD in Hanami was bound to be bored.
Another workshop I went to was supposed to be a demonstration of Trailblazer... Apotonick's (Trailblazer's creator) aim was to show the new features to be released with Trailblazer2. He spent most of the two hours allocated to him trying to run a live demo, which was a complete disaster. At least it was funny.
The primary objective of Ivan's workshop was to flag up a common issue in Rails: the strong reliance of the app logic on Rails. He made a really good point that the core of our apps aren't Rails but the application logic that Rails bring. It sounds obvious, but we should give the issue a bit more thought.
Another issue taken up by Ivan Nemytchenko was how quickly the decisions we make – reflecting the requirements at any given moment – will impact the project later when its specifications change.
The workshop's participants were asked to write a simple Rails application (a sort of an e-shop). The process was split up into stages, and after every stage, the participants were encouraged to discuss the solutions they used and how they could be improved. Apart from all that, the workshop mentioned form objects and services, as is the common practice nowadays.
We would like to encourage everyone to take part in conferences. It will be a great experience for you – you'll further develop your skills, you'll meet new people, and you'll have a chance to visit new cities or countries!
Article created by: Bartosz Bonisławski, Zuzanna Stolińska, Szymon Krywult, Krzysztof Kołek