There are many regular Ruby conferences all over the world. One of them is called Euruko, and the last edition took place on the 23rd and 24th of September 2016. When we heard about the event for the first time, we didn’t hesitate for long before we started looking for flights. Fortunately, we found a cheap one from Berlin, booked a comfortable apartment and we were ready to rock and roll! Sofia, here we come!
So, here are a few short summaries of the presentations that made the biggest impression on me:
Day one kicked off with a keynote from Yukihiro Matsumoto, the creator of the Ruby language. He spoke about some ambitious plans of his to make Ruby 3 times faster in version 3.0 in comparison with version 2.0. Matz mentioned a couple of ways that the Ruby team wants to pull this off. One of the tricks up their sleeve is to add the Just-In-Time (JIT) compiler to Ruby. Another two topics Matz talked about were the proposed Guild-based concurrency model and the influence the type of system has on performance and developer experience. I'm especially happy about the concurrency part - we already live in an era when it’s not that weird to have a smartphone with 8 cores in its CPU. Matz also mentioned that increasing the performance of a language such as Ruby is no easy task since during its more than 20 years of development most “low hanging fruit” in terms of performance has already been picked. We can be sure that Ruby is not going away anywhere anytime soon and the future looks interesting!
Day two opened with an excellent talk by José Valim.
Just before his actual presentation took place, José had entertained the crowd with a short live coding session where he showed off some intriguing features of the Elixir language. He dazzled his spectators with pythonesque doctests, stupefied them with beautiful, coloured diffs in unit tests and astounded them with the basics of sharing code between distributed machines.
The actual talk got underway with an abridged history of how Elixir came to be. Like most inventions, this one originated from necessity. José, disillusioned with Ruby's approach to concurrency, needed a language that was more suited to the requirements of the modern world. A language that could tap into the power of the multiple cores that our machines were already packing under the hood. Maybe a functional language, with explicit state and immutability, that would solve most of the problems related to dealing with the concurrent code? Erlang was just that language. If only it had better tooling, nicer syntax and provided some constructs available in many other languages... Thus Elixir was born.
The second part of the talk focused on concepts that all Erlang VM-based languages use for building distributed, fault-tolerant systems. Things like processes - similar to OS processes, but isolated and light-weight, run in hundreds of thousands on the same machine. Like supervisors - processes the sole responsibility of which is to react to failure by respawning the failed process. Or - like applications - larger components made of processes and supervisors. All of these concepts were reinforced in a live demo, which made great use of the (fantastic!) Erlang Observer tool (for the osx crowd - think Activity Monitor for your Elixir app).
In the last part, José explained what Elixir brings to the table: compatibility with Erlang VM, extensibility (compile-time metaprogramming with macros and polymorphism via protocols) and productivity by having excellent tooling and documentation. And a marvellous, Ruby-inspired syntax to top it all off.
If you still haven't dipped your toes into Elixir, this talk will persuade you to get dipping right away. Don’t be shy! Head over here and give this bad boy a spin!
This talk by Nick Sutterer wasn’t about Rails API and Active Model Serializers as you might have expected. APIs are an amazing thing because we can use stuff that other people wrote and we don’t have to really understand what’s happening inside. Being abstractions, they help people out a lot and may be extended easily, by adding a functionality at the top. An excellent example of how an API can be extended is allowing users to sign in via Facebook or Github, but we should keep in mind that API doesn’t mean that it has to stay as it is for the rest of time. Amending makes sense. If you look at one of Rails purposes there’s one part called MVC pattern. The problem is that we have been led to believe it’s perfect because of the Rails doctrine written by DHH, but it isn’t. Maybe we could add more layers to the application than mere models, views and controllers. It turns out that strict adherence to the pattern ends up with the really convoluted code so, as a good software developer, you have to change the abstraction of your API.
Let’s say you have a User model with some validation, but you also need to create an admin user by skipping. For instance, the name length validation. Pure Rails doesn’t allow this, so maybe you would be better off thinking about a different solution? Moreover, maybe validations shouldn’t be located in the model but in a completely different place. At that moment, Trailblazer swoops in to save the day with a thin layer on top of a Rails app. This is just a small example of when an API must change but there are many many more situations when the old Rails way is not the best and changing the structure of your API will be the right way to go. Conclusion? Innovation = change. If you’re changing your API, you’re an innovator. Don’t be afraid of change.
If you’d like to get to know some more and watch all the presentations (as we highly recommend), just visit Euruko 2016 Youtube channel. Not enough? The next edition is going to be in Budapest, Hungary, so see you there!
Article created by: Bartosz Lecki, Grzegorz Unijewski, Mateusz Stebnicki.