Wroc_love.rb is one of Europe's largest and most recognizable Ruby programmers community events, with over 200 participants and 10 speakers. As a top Ruby on Rails development company, we couldn't miss out on this event, ending with 5 iRonin team members attending the conference.
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 fantastic event, and it only gets better.
Over the weekend, many 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.
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, brainstorms, and lightning talks. Oh, and we can't forget 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, a new way of writing concurrent code! - lecture
Want to know what got our juices flowing during the conference? Here are a few topical points our team was really digging during talks; enjoy!
Artur's Lightning Talk about the unexpected case of rescuing exception
During a lightning talk session, our team member, Artur, presented an interesting use case to the group based on a problem we faced in one of our projects. This short story is about 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 developers.
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 how we can simulate possible application performance change using a model described in Ruby-based DSL, 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 Heroku decided to change how its router processes requests. Before the change, the router "intelligently" picked the dyno with the smallest CPU load. After the change - randomly. The simulation results were pretty obvious - the intelligent router won the "competition" in most cases.
Wojciech also demonstrated what would happen if we had more independent intelligent routers and how they would compare against one random router. It turned out that the more independent intelligent routers we have, the worse the system performs. However, picking the right number of these routers will perform better than one random one.
The second case study addressed "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, at some point, it's more beneficial performance-wise to afford 6 standard 1x dynos than 3 standard 2x dynos.
Ruby vs Elixir
Przemek is an Elixir fan and was excited to hear more about this programming language. This year's edition compared two 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 the JavaScript world - from the Ruby developer perspective. Numerous opinions have been raised about this in the past.
We started the panel with a statement: adding a webpacker gem for managing JavaScript modules in Rails is a good move because there is hope that webpack will finally be a stable solution for the years to come. However, some folks said the move has come a little late because, nowadays, we should build separate apps for the 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 such as ES6/ES7/Typescript. Nonetheless, the community should be grateful for its impact in the past.
The most controversial topic of the debate was 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 compared 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 a Ruby developer but as a web developer as well. We still haven't found the best solution for writing and managing JavaScript code, and we will probably never find one. Despite improving the JS toolset, the debates about which one is the best will continue on…
The Overnight Failure
Darek participated in a fascinating talk given by Sebastian Sogamoso (Colombia) about his experience with a big failure of his company's product.
The product was a carpooling application that 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 severe: some people were left without any money in their bank accounts!
Sebastian described his entire day (Saturday) when dealing with the (very serious!) problem. To sum up, he told us many critical 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 what happened exactly
- Make fixes very carefully so as not to cause other issues
- Document our failures and solutions for them
- Share the information about failures with others
This last tip is essential. 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. 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. John solved 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 well. Unfortunately, the same issue happened to James, and production was down once again on the same day.
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 had 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 🍚
If you need any help from experts in Ruby and Ruby on Rails - contact us.
P.S. There was also no shortage of conference swag - we left with nerd socks in rubies 😃 Courtesy of Monika 😋
