It was a very Ruby weekend over the 18th and 19th of March at the wroc_love.rb conference! It’s our third time supporting this awesome event, and it only gets better.
Over the weekend a lot of familiar faces from the Ruby world converged on Wrocław. We came from all corners of the globe to exchange different points of view, and debate the finer points of the Ruby programming language and its ecosystem.
Wroc_love.rb is one of the largest and most recognizable Ruby programmers community events in Europe, with over 200 participants and 10 speakers; 5 iRonin team members in all attended the conference.
The Information Technology building at the University of Wroclaw campus set a brilliant scientific atmosphere and tone to the event. Here we could experience various technical talks: lectures, panels, brain storms, lightning talks - oh and we can’t forget about those mysterious discussions during the after party!
Topics highlight
1. Predicting Performance Changes of Distributed Applications - lecture, materials
2. We All Make Distributed Systems - lecture, materials
3. Fault Tolerance in Ruby - lecture, materials
4. Automated Type Contracts Generation for Ruby - lecture, materials
5. How to survive in the JavaScript world as a Ruby programmer and stay sane (in 2017) - Discussion panel - lecture
6. Bindings in Ruby - Behind the Magic of Blocks - lecture, materials
7. Panel: Ruby vs Elixir (this one got heated up!) - lecture
8. The Overnight Failure - lecture, materials
9. Machine Learning to the Rescue - lecture
10. Concurrent-ruby v1.1.0: new framework, new way of writing concurrent code! - lecture
Want to know what got our juices flowing during the conference? Here’s a few topical points our team were really digging during talks, enjoy!
Artur’s lightning talk about unexpected case of rescuing exception
During a lightning talk session, our team member, Artur, presented to the group an interesting use case based on a problem we faced in one of our projects. This is a short story of how a rescuing Exception class can compromise your codebase and break your tests. If you want to hear more, check out our post that describes the issue in greater detail - a must read for devs.
We All Make Distributed Systems
Łukasz liked the interesting talk delivered by Wojciech Rząsa (Rzeszów University of Technology) about predicting performance changes of distributed applications. Based on real-life case studies, he demonstrated, using a model described in Ruby-based DSL, how we can simulate possible application performance change, according to what kind of architecture we decide to use.
The first case study was about the Rap Genius - Heroku dispute. The cooperation between the two sides was going very well until the time when Heroku decided to change the way in which its router processes requests. Before the change, the router "intelligently" picked the the dyno with the smallest CPU load. After the change - randomly. The simulation results were pretty obvious - in most cases, the intelligent router won the "competition".
Wojciech also demonstrated to us what would happen if we had more independent intelligent routers, and how it would compare against one random router. It turned out that the more independent intelligent routers we have, the worse the system performs. However, if we pick the right number of these routers it will perform better than one random one.
The second case study addressed the question "Scale or not to scale?". Wojciech showed the difference in performance between horizontal and vertical scaling, taking the Heroku dynos offer as a reference. The simulation he presented stated that to some point, it's more beneficial performance-wise to afford 6 standard 1x dynos than 3 standard 2x dynos.
Ruby vs Elixir
Przemek is Elixir fan and was excited to hear more about this programming language. In this years edition there was a comparison of two different programming languages Ruby and Elixir with their frameworks Ruby on Rails and Phoenix. Super interesting and highly heated!
How to survive in the JavaScript world as a Ruby programmer and stay sane (in 2017)
Mateusz enjoyed a discussion panel about the current state of JavaScript world - from the Ruby developer perspective. Numerous opinions have been raised about this in the past.
We started the panel with a statement: that adding a webpacker gem for managing JavaScript modules in Rails is a good move, because there is a hope that webpack is finally a stable solution for the years to come. However, some folks said the move has come a little bit late, because nowadays we should build separate apps for backend and frontend.
In our next panel topic, everyone agreed that the new version of CoffeeScript doesn't change anything - currently we have better solutions as ES6/ES7/Typescript. Nonetheless, the community should be grateful for its impact in the past.
The most controversial topic of the debate was about concepts in popular JS frameworks. Not everyone gets the hype about ReactJS, because of mixed HTML, JS and CSS code. On the other hand, Vue.js requires learning additional DSL and syntax which adds some complexity in comparison to native JavaScript methods. For internal apps we always use Ember.JS - in conjunction with Rails it just works :)
For me, the conclusion from the panel is that it's not easy to stay sane in a JavaScript world; not only as Ruby developer, but as a web developer as well. We still haven't found the best solution for writing and managing JavaScript code and probably we will never find it. In spite of improving the JS toolset, the debates about which one is the best will continue on…
The Overnight Failure
Darek participated in an interesting talk given by Sebastian Sogamoso (Colombia) about his experience with a big failure of his company’s product.
The product was a car pooling application, which allowed users to share a car ride with other people while going to work. It had automatic payments for users, and one day this payment system broke down.
The problem resulted in many duplicated payments: users were charged multiple times. The consequence of this bug was very serious: some people were left without any money left in their bank accounts at all!
Sebastian described his entire day (Saturday) when he was dealing with the (very serious!) problem. To sum up, he told us a number of very important things that we should remember to avoid such cases in the future, namely:
- Remember that: Anything that can go wrong will go wrong - Murphy's Law
- Remember that we won’t be judged for our mistakes
- Make sure that we understand exactly what happened
- Make fixes very carefully to not cause other issues
- Document our failures and solutions for them
- Share the information about failures with others
This last tip is very important. We should always share our failures with team members ASAP!
Let’s imagine a sample failure scenario where all developers are able to deploy an app.
Problem: Something has been changed with the deployment configuration and it wasn’t described carefully.
A developer, John, comes to work and decides to deploy his finished tasks. As always, he follows the deployment guide, builds the app, and successfully deploys his changes. After a few minutes he realizes that production is not working at all. John asks his teammate why this has happened and what the root of the problem is. It takes around 20-30 minutes for John to learn what has been changed, update his deploy config, build the app again and deploy the changes once again. John solves the issue, but the production system wasn’t working for around 30 minutes. John decides to update the team deployment guide to avoid this issue in the future.
In the afternoon, another developer, James, decides to deploy his finished tasks. He doesn’t look at the deployment guide, because he already knows the flow very well. Unfortunately the same issue happens to James and production is down the same day once again.
Summary: If John had shared the information about the failure with a team notification (instead of only updating the guide), then James would not have the same problem.
See you next year!
Discussions from the conference on our internal channels have been continuing for weeks after the conference. The Ruby vs Elixir debate is still raging - giving us prime popcorn conversation for perhaps a whole year 🍚
P.S. There was also no shortage of conference swag - we left with nerd socks in rubies 😃 Courtesy of Monika 😋
