EuRuKo - the European Ruby Conference - is an annual conference on Ruby, a programming language upon which skroutz.gr, alve.com, and scrooge.co.uk are built. EuRuKo 2016 took place in Sofia, at the majestic National Palace of Culture (NDK), and our team could not miss it!
We asked each member of our team to write a summary of the talk they loved most.
Keynote
Euruko 2016 started with the keynote by Yukihiro Matsumoto, known in the Ruby community as Matz. In the talk we got a glimpse of what the CRuby core team is working on for Ruby 3.
Two of the main areas Ruby 3 will try to improve are performance and concurrency. Matz has set a goal to make Ruby 3 three times faster than Ruby 2. He called this Ruby 3x3.
To improve the Ruby interpreter’s performance the Ruby team is looking at a couple of options. First is just-in-time compilation (JIT). Another way to improve performance is to add support for typing information; that would allow the interpreter to perform more aggressive optimizations on the code. Since Matz doesn’t like static typing or type-hints, he’s looking into an alternative approach called “soft typing”. As far as I understand it, soft typing has the interpreter or soft-typing checker try to extract typing information from the code in a “best-effort” kind of way.
On the concurrency front, the CRuby team explores two avenues: guilds & general GIL optimization/removal. Ruby is currently far behind languages like Erlang in the concurrency field and that’s in big part because of the Giant Interpreter Lock (GIL). Guilds look to address this by allowing a careful programmer to break up their code into independent parts - the guilds - which are safe to run in parallel. To ensure thread-safety - or rather, guild-safety - every object in the program belongs to a single guild and each guild can only mutate objects it owns. Guilds will be able to communicate with each other and even trasfer an object’s ownership via channels (this sounds like Golang, yey!).
All these exciting things will take a lot of work though, so don’t hold your breath for Ruby 3. Like Matz said:
When will Ruby 3 be released? Maybe in 3 years’ time.
We look forward to it nevertheless.
GraphQL on Rails
Marc-André Giroux presented the problems of existing API approaches, namely REST with the too many round trips and custom endpoints. He then proposed the GraphQL and more specifically the graphql-ruby gem as a better approach solving many of the existing approaches’ issues.
An extended reference was then made to the pain points of the GraphQL approach and the suggested solutions or workarounds:
- N+1 queries
- HTTP Caching:
- Security (Cyclic queries):
- Add hard limit Timeouts
- Add Query Depth Control
- Add Query Complexity Control
Finally, he presented some of the future features for the graphql-ruby gem:
- Subscriptions: Pushing data from the server when they change.
- Deferred Queries: Anotate parts of the query to be sent in a second response, in order to have the first and most important results quicker.
- Efficiency Improvements
- Predictability Improvements
Building distributed fault-tolerant applications with Elixir
José Valim presented his incentives behind creating a new programming language to deal with the shortcomings of Ruby (concurrency, state accumulation).
How he took the opportunity to build on the excellent Erlang VM and leverage the power of the Open Telecom Platform (OTP) which is specifically designed for long-lived distributed applications.
Most modern devices (phones, tablets, laptops, etc) have CPUs with multiple cores, yet it isn’t that easy to write software to take advantage of them. Elixir aims to fill this gap by combining the elegance of a Ruby-like syntax while maintaining full compatibility with OTP.
He specifically pointed out how important it is to be able to isolate failure and declare process dependencies and actions to be taken upon failure so to always have the system in a state guaranteed to work.
He also demonstrated the language’s flexibility by creating DSLs using macros with readability in mind. The talk ended with the main features concerning developer happiness and productivity:
- First-class documentation
- Tooling (ExUnit, IEx, Mix)
- Hex Packages
Organizing Remote Internships for Ruby developers
The not entirely technical presentation of Ivan Nemytchenko was (in my opinion) one of the best presentations in Euruko2016.
Ivan after working in several companies decided to work on an idea he had for a long time: “Organizing Remote Internship for Ruby Developers”.
He started by studying SOLID principles, design patterns, refactoring techniques, architecture types and identification of code smells.
Then, he organized his idea by promoting it at his blog. The post drew attention to many more people than he had originally expected and so he had to make a choice and pick the best applicants. To do so, he created an aptitude test that included the implementation of an app with three parts, each one more difficult than the previous.
According to Ivan, the final result was a complete disaster, with interns making common mistakes such as:
- Ignorance of abstraction levels
- Gamification
- Lack of service objects
- Business logic in random places
- Bad naming
Then Ivan decided to organize group hangout code reviews and lectures about patterns and refactoring. All these things in the end worked out really well but the huge amount of teams (interns), the collective irresponsibility, the inability to communicate, the lack of motivation and the lack of mentors led to Ivans BURNOUT.
In conclusion, what a ruby intern needs:
- Real tasks to work on
- Some achievement to put into portfolio
- Whole development cycle experience
- Team work experience
And the solution:
- Conferences (trigger to study new things)
- Book reading
- Pet projects (be a down to earth person)
- Open source (find interesting issues to solve, get feedback)
- Learn from the seniors (follow their way of thinking in solving problems)
Come on Ruby Together
Despite the fact that gems are multiplying and gem downloads are increasing exponentially, volunteer help falls short. That’s what pushed Andre Arko to found Ruby Together and talk to us about it, in his presentation.
Ruby Together is a non-profit organization dedicated to build, update and maintain important tools for the Ruby community, such as Bundler and Rubygems.
On the first part of his talk, Andre mentioned that although there have been bursts of volunteers when problems appeared, there is a serious lack of continuous voluntary contribution and underlined the fact that companies don’t invest on giving back to the ruby community despite profiting from open-source tools.
On the second part, he focused on the accomplishments of Ruby Together over the last year and a half. Some of them are:
- Multiple feature and bugfix releases for both Bundler and Rubygems
- Google Summer of Code and RailsGirls Summer of Code student mentoring
- Multiple security patches
- Gemstash tool
Moreover, he announced that they have been working on merging Bundler and
Rubygems codebases, while maintaining both gem
and bundle
commands.
He concluded, saying that Ruby Together’s progress has been astonishing. However, fewer and fewer companies offer any kind of support and if that doesn’t change, it will eventually result into not being able to maintain the current sustainable situation.
The Illusion Of Stable APIs
The final talk at EuRuKo 2016 was given by Nick Sutterer a Ruby on Rails expert, Rails contributor and gem author. His talk was about APIs, design flows and their importance on the architecture of a web application.
He made a few valid points stating why Rails should not isolate itself to the MVC paradigm, should not stick to DHH’s Rails Doctrine and that more layers should be added to the framework in order to avoid fat models and complex controllers. The example he focused most on, was getting model validations out of the model in another layer that will allow for multiple validations depending on the context (such as a simple User and another User that is also an Administrator). For the multiple validations example he also compared the standard approaches between Rails and Phoenix (a web framework written in Elixir ) showing that Phoenix uses separate modules in order to divide responsibilities of a model such as database access, query generation, and validation. More specifically he pointed out that Ecto (equivalent to Rails ActiveRecord) uses the changeset to perform validations.
Finally, to support his statements on why Rails has architectural flaws he talked a little bit about one of his projects called Trailblazer, a thin layer on top of rails that gently enforces encapsulation, an intuitive code structure and gives you an object-oriented architecture.
Authors
- Keynote: Chris Nitsas
- GraphQL on Rails: Christos Lontos
- Building distributed fault-tolerant applications with Elixir: Dimitrios Zorbas
- Organizing Remote Internships for Ruby developers: Filippia Zikou & Kostas Karampinas
- Come on Ruby Together: Argiris Ntalianis
- The Illusion Of Stable APIs: Konstantinos Kostis
Some photos
Walking through the NDK park towards the conference center.
View from the 6th floor of the National Palace of Culture.
Conference venue hall.
A full auditorium for Matz’s keynote speech.
The beautiful NDK park.
P.S. We were looking forward to Bhozidar Batsov’s talk “Ruby 4: To Infinity And Beyond”, but unfortunately he had to cancel due to health reasons - we hope you feel better Bhozidar! We’ll see you in the Athens Ruby Meetup in November!