Like last year, our Netguru folks attended the annual Ruby conference in Europe called “EuRuKo”. It took place in the city of Budapest, which happens to be beautiful and not very far away from Poland. This time, the event attracted over 600 participants in total, who had an opportunity to listen to two days' worth of technical and non-technical presentations. The talks concerned Ruby, Rails, software development, and working culture in general. We prepared short summaries of the talks we found the most interesting – have a look below!
Main picture source: @euruko on Twitter https://pbs.twimg.com/media/DK5WragXkAE5RYO.jpg
Source: @euruko on Twitter https://pbs.twimg.com/media/DK9aFmnW4AAB6ZN.jpg
Yukihiro “Matz” Matsumoto, the chief designer of our beloved Ruby programming language, started Euruko2017 with a keynote about the Ruby3x3 project. Once again, we could hear about the future plans of making Ruby 3.0 three times faster than Ruby 2.0 – Ruby's team has worked on that for a few years already. It is something worth keeping in mind, because each version of Ruby from 2.0 to the current 2.4 have improved the performance by about 5-10%. Matz also shared the principles that guide the language's design: not making drastic changes that could divide the community; using a macro, optcarrot benchmark, instead of micro ones; and, finally, not relying on a closed technology that they could not really influence. Matz spoke about MJIT, created by Vladimir Makarov, which is not only open-source but, according to the optcarrot benchmark, it is already about ~2.8 times faster than Ruby 2.0. This means that it does not violate the design principles, and it can make Ruby 3.0 actually happen. MJIT is still in the early stages of development, and while this means we might need to wait some more time for Ruby3x3, it also means there’s still room for a lot of performance improvements!
The Overnight Failure
Sebastian Sogamoso, coming from Colombia, told about his huge failure happened at night to an app he had been building some time ago. The application was responsible for helping people to commute, where passengers are able to find a match for a trip and pay for it to the driver. Simple carpooling. The whole billing process is triggered once a week in the background jobs. On a Saturday at 6am users started complaining about charging them a lot of money from their credit cards. It turned out that there were a few problems. Firstly, instead of adding N jobs to the queue like passenger - driver pairs, they were adding N^2 jobs, which was extremely increasing the amount of jobs to process. Secondly, they didn’t have a test how many times the job goes to the queue, considering it as an edge case. Furthermore, they should have checked that each pair goes to the queue only once a week and without any duplications. Fortunately the broken charges have been stopped in the morning, but investigating all the issues and till the fix was deployed to production took the whole day. As a result thousands of users were affected by the bug, some of them were charged even up to 200 times whereas there was a single user was charged over $5000. What can we get from this lesson? First of all, embarrassing things happen to all of us, we are only humans. Also, we need to make admitting mistakes easy and trust that we won’t be judged. After that we should fully understand what happened to avoid such problems in the future, document the problem and the fix as well. I recognize this approach what we follow at Netguru, which means “you’re not your code”, and we could add now “you’re not your failures”.
Charles Nutter is one of the key people behind the development of JRuby for several years.To those not familiar with it JRuby is an alternative implementation of Ruby based on JVM. Thought not 100% compatible with MRI Ruby it's a really neat option worth considering.By using JVM it's highly portable, performant and allows using vast array of tools designed for Java (like profiling tools for example).
Moreover it supports GUI applications and is now used in production in Brakeman Pro.
The drawback is that it can't use native C extensions - those should be ported to Java in order to make them work.
Based on charts presented by Charles in benchmarks JRuby can get up to about 28x faster than C Ruby which is a huge leap.In conclusion JRuby tries to combine the stability of JVM with flexible syntax of Ruby.
The current JRuby version is compatible with Ruby 2.3.0 and more information can be found here. It looks very promising.
Predicting Performance Changes of Distributed Applications
Wojciech Rząsa is a PhD at Rzeszow University of Technology and uses Ruby in his research concerning distributed systems. During implementation of security mechanism for large distributed system he encountered problem, that many developers had to face: how big would be performance penalty after adding new mechanism(feature)? In his case performance was good enough and after some experiments and calculations he realized that overhead wouldn’t be too large. Unfortunately most developers don’t have tools and scientistic knowledge such as formal methods, which would’ve helped them assess performance change. Wojciech mentioned that in 2013 Heroku switched from so called „Intelligent Routing” to random routing. He presented how using his simulation model he was able to check difference in performance between those two solutions. He also used his model for simulating Heroku’s dynos and checking how they’re scale, that is, whether is better to use more expensive dynos or twice as many cheaper ones. In his simulation he checked two scaling variants for more expensive dynos: horizontal and vertical. After that he made some experiment on real Heroku app, with CPU intensive task and compared the results with his simulation’s ones. Thanks to simulation done earlier he only have to make short experiment on real application, thus don’t have to made costly experiment on real app.
For now tool used for simulations is university’s property, but Wojciech is making an effort to make it available for developers.
Issues with asynchronous interaction
Anna Shcherbinina, software engineer at Artec3D (developer and manufacturer of 3D scanning hardware and software) gave a fascinating talk about common issues arising when dealing with asynchronous interaction and presented some of the patterns which could be successfully utilized to resolve them.
The patterns described in detail by Anna included ‘Asynchronous Request-Reply with Timeout’, ‘Asynchronous Request-Reply with Notification Timer’, ‘One Request, Multiple Responses’, ‘One Request, Mandatory Response and Optional Response’, ‘Subscription’ and ‘Unsolicited Notification’. It has been emphasized that an application relying on asynchronous interactions should have the capability to function in an event of network unavailability.
Anna also brought up the subject of application scaling, identifying proper monitoring (server events, backup statuses, firewall activity and application services), centralized logging, distributed tracing, exception tracking and the ability to learn from every failurealong the way as the main factors which influence the success of a scaling process.
Talk by Bozhidar Batsov was an ironical science fiction about future of Ruby. During keynote Yukihiro Matsumoto was talking much about Ruby 3 performance. Not so much about adding new features or deleting obsolete ones.
Ruby was never designed to be fast. People are using ruby mainly in web development and performance of the language is rarely an issue. Most problems come from not optimized database queries, networking and other web specific issues.
Ruby was designed for developer happiness. And Bozhidar suggests that it should continue to optimize for that.Ruby could catch up with younger languages by adding immutable data structures, namespaces, optional static typing, better concurrency api, immutable strings and many other desired features by most of developers. On the other hand there are some features that didn’t catch attention of Ruby crowd: for loops, BEGIN..END flow instructions, flip-flop operator, block comments, procs, reassignable constants, class variables.
At the end of the talk Bozhidar announced a date for Ruby 4.0 release: probably never. Which is sad because without innovation Ruby will probably become obsolete in the future. And it doesn’t have to. Our community is very open to changes and adapts them quickly. This is also a reason why developers can migrate to new shiny technology if we stop to polish our favourite gem that is Ruby.
See you next year in Vienna!
Authors: Grzegorz Unijewski, Dominik Filip, Krzysztof Kołek, Szymon Krywult, Jakub Kubacki, Jan Kamyk