EuRuKo 2019: A Recap

On June 21, the European Ruby Conference (EuRuKo) welcomed several hundred Rubyists aboard the ss Rotterdam, a historic ship. The two-day, single-track event featured a keynote from Yukihiro “Matz” Matsumoto, the inventor of the Ruby language, ample networking opportunities, and more boat puns than anyone had prepared themselves for.

Talks this year ranged from highly technical discussions of new features in the upcoming release of Ruby 3.0 to a fun memory hack that involved Pokémon doodles for common code smells. In an event dedicated to the Ruby language, there was a surprisingly wide array of subjects. The entire conference can be viewed on the EuRuKo YouTube channel.

Full talks: Day one

Keynote: Functional (Future) Ruby by Yukihiro “Matz” Matsumoto

In 1995, Yukihiro “Matz” Matsumoto announced the release of Ruby 0.95. Twenty-four years later, Ruby maintains a loyal following, and is the 11th most popular programming language worldwide. In his talk, Matz presented the major features for the release of Ruby 3.0, which is currently slated for December 2020.

“We have to keep moving or we’ll die,” Matz said. To that end, the core Ruby team has been hard at work filling in the missing pieces of the language—those related to static analysis, performance, and concurrency.

Inspired by functional programming languages, Ruby 3.0 will ship with support for static typing. It was important for Matz and his team to consider developer experience when adding in static typing—it should be easy to use and be backwards compatible. Therefore part of the solution will include a type compiler that will suggest types based on existing code. Types will not be required, but a type compiler will be available to check for possible type errors. (A later talk discussed this type compiler in depth.)

When debugging performance problems, Matz explained, memory is the first bottleneck. Ruby’s garbage collection performance has improved over time and the team will continue to work on this issue. They will also be focusing on improvements for CPU use and I/O (input/output), keeping in mind that the Rails framework—the most popular use of the Ruby language—requires a slightly different approach, based on its size.

Ruby 3.0 will also ship with better support for threading, adding “Guilds” and “AutoFiber”. Both of those names are currently under development and may be released under different monikers. Guilds will improve CPU bottlenecks, while AutoFiber will speed up I/O communication.

Finally, Matz hinted at other improvements to come in Ruby 3.0: Numbered block parameters, JSON-like pattern matching, a potential pipeline operator inspired by the F# programming language, and right assignment.

From Multiple Apps to Monolith—#BuildingMonsterservices by Kaja Santro

A back-end developer at Absolventa, Kaja Santro has recently brought four distinct full-stack employment-listing applications under one roof at her company. The transition allowed for vastly improved developer experience and efficiency, much lower fees on its cloud host, a better staging environment, fewer dependencies, and consistency of business logic, while also making it much easier to spin up new apps for the company.

There were “absolutely no damages and many advantages for the team,” she said, championing the monolith. Risks involved included local views loading slower as assets for parts of other apps needed to load, slower tests and deployment, and more merge conflicts, although she stressed that these were all manageable and well worth the trade-off.

Furthermore, during the transition, her team was able to clean up a lot of code and she expects to continue to benefit from this decision well into the future.

Surrounded by Microservices by Damir Svrtan

Directly after a talk advocating a monolith “monster,” Damir Svrtan, Senior Software Engineer at Netflix, promoted microservices, demonstrating that there are many successful development patterns in the tech community.

Svrtan works for Netflix’s Studio Engineering Team, which is aiming to digitalize the still mostly paper-based movie and TV production business. Though Netflix started as a Rails monolith, it now consists of many microservices that perform specialized tasks. The goal is to set boundaries around domains/data, not improve performance, he explained.

Because the data coming into the studio system is from many diverse sources, Netflix’s microservices need to be able to work with data in many different forms. To do this, Active Record model business logic needs to be separate from data, and have no knowledge of how it is stored. This type of architecture is called hexagonal. For instance, a find_by_id method can require a method stored with the data about how it is searched. In this way, the data itself can determine how to implement a common execution without the application itself being concerned with the type of data available.

Svrtan also encouraged attendees to make decisions about architecture late in the development of a system. Typically, these decisions—what database to use, how to validate data—are made before the system has a chance to operate and when developers have the least amount of information about how it will work. If a decision can be delayed, a better solution will inevitably present itself as the life of the project progresses.

What Causes Ruby Memory Bloat by Hongli Lai

Cofounder of Phusion and developer of the Passenger application server, Hongli Lai dug into the way Ruby allocates memory following a problem with a simple app taking up far too much CPU memory.

After a brief introduction about how computers use memory, he walked the audience through his detective work to uncover why his application was bloated. In the end, he revealed that Ruby threads are assigned their own OS memory allocation, and the default implementation that writes to this memory is inefficient and reluctant to release unused memory back to the kernel.

To solve this problem, Lai released Fullstaq Ruby during his talk, a new Ruby distribution that prioritizes memory efficiency. This distribution of Ruby uses 17%-20% less memory than base Ruby, but users will see a 7%-20% performance drop, he said. Depending on what your application is doing, this may be a useful trade-off. His team is continuing to work on performance improvements.

It’s Very Effective; Using Pokémon to Catch All Code Smells by Melanie Keatley

Doodling is very helpful for understanding and retaining information, shared Melanie Keatley, a Developer at YoungCapital. Humans process images faster than text, which is ideal for memorizing data. To that end, she created a system for identifying and remembering code smells—patterns in code that could point to potential problems or places that need refactoring.

Keatley’s system involves a series of Pokémon, the Japanese collection of Pocket Monsters—for each set of common code smells she uses an illustration of a simple Pokémon. For instance, “Fency” is a doodle for “feature envy,” a code smell wherein an object accesses data from another object more than its own.

Building Bricks with mruby: A Journey to mruby on LEGO Robots by Torsten Schönebaum

Proving that LEGO is not just for children, Torsten Schönebaum, a Software Developer for Sage Accounting, demonstrated a robot he constructed and coded for the LEGO EV3 Brick computer. The EV3 comes with its own Sketch-like programming interface, but Schönebaum found it too slow to work with. Instead, he wanted to run Ruby.

To work with the robot’s computer, mruby, an alternative interpreter for the Ruby language, proved useful. It has a much smaller footprint than CRuby, but is missing many core Ruby methods. Schönebaum offered several lessons learned from working with embedded Ruby:

• It is not easy to determine which methods are available in MRuby and which are missing. The source code can be easier to read than the docs.
• Load order is important for MRuby files—he needed to prefix some files with the letter A for them to be able to load first.
• The EV3 programs/sensors can be too slow for normal execution—they “miss their mark” and fail to register the correct angle of rotation, for instance.

A Gentle Introduction to Data Structure Trees by Ashley Jean

ASoftware Engineer at mdlogix, Ashley Jean gave a crash course in one of the basic structures of computer science: Trees. She covered Big O Notation, which measures the worst case time for a program to run, the way trees are organized, and examples of natural tree systems.

Tree structures are faster to search than other data structures, like arrays, she explained. And a binary tree is a special structure in which each node has at most two children. A node in a tree that has no children is called a leaf.

Jean also briefly discussed self-balancing trees, AVL trees, and splay trees—different methods of organizing data in a tree structure.

The Miseducation of This Machine by Laura Laugwitz

“Knowledge that machine learning produces is no coincidence,” said Laura Laugwitz, a working student at the Free University of Berlin and former organizer of Rails Girls Berlin. Machine learning can only produce data that is similar to what it is given. In other words, it “predicts the future based on past data.”

She explained how convolutional neural networks can identify what an image contains. She continued with how they can be used to identify hate speech online, as shown by her project nohate.online. But the greatest challenge with machine learning, she concluded, is in reflecting on the data and telling a computer how to interpret it. In the case of hate speech, language can seem very innocuous, but in fact be very offensive to those who understand the hidden messages.

Full talks: Day two

Yes, I Test in Production… And So Should You by Charity Majors

Every developer tests in production, proclaimed Honeycomb’s CTO, Charity Majors. Whether we want to think about it or not, we all catch bugs in production and have to fix them. And if we aim to learn in production, we have more chance of learning how users actually interact with our products.

Tests are great for catching problems we know about, but there is no way to anticipate everything that could go wrong. And a staging environment is where we think we are demonstrating real-world interactivity. But “Staging is not production. It will never be production,” Majors said. By employing monitoring systems, we can eliminate a staging environment and instead allow our code to run naturally, catching errors as they occur. A major benefit to this approach is that we will become familiar with how our code runs in production, and gain experience of fixing things as they occur in production. Currently we have a lot of experience working with our local environments and testing things through staging, but we have very little experience working and testing our code in production, which is where it matters.

Of course, there are risks to relying on production as a proving ground, including data loss or contamination, a loss of rollback options if you make critical errors, a tendency for chaos to cascade (fixing a problem can cause more problems), and users may have a bad experience. All of these trade-offs are a good deal for Majors, who encouraged the audience to “be less afraid” and get more experience fixing things in production, so that we will become better at doing so.

How We’re Making Tech Documentation Better, Easier, and Less Boring by Bilawal Maheed

Many companies lack excellent internal documentation. Spotify, where Bilawal Maheed is a Software Engineer, was one of those companies until his team constructed a process to make code documentation easy and accessible.

He worked to improve the discoverability, trustworthiness, and ease of use and creation of all of Spotify’s internal documentation. Taking inspiration from systems across the web, his team created a version-controlled docs system that automatically reads from each team’s GitHub repos and publishes to an internal dashboard. Everyone in the company can access docs from any other team.

Spotify prioritized documentation in order to improve developer efficacy. Maheed argued that good documentation can help with imposter syndrome, and improves the overall health of the code base.

During this project, he learned a few tips for handling documentation at any company:

• Concepts should be documented (using terms such as API, or HTTP codes), so provide links to relevant materials.
• Predictable URLs should be used so users can easily jump around to find what they need.
• Users will want to search in a page, so don’t segment individual docs too much.
• Create tools that can power command-line users.

A Plan Towards Ruby 3 Types by Yusuko Endoh

As a core Ruby contributor, Yusuko Endoh is helping create what will become Ruby 3.0 when it is released next year. He continued the demonstration started by Matz the previous day on what we can expect—he has been working on improving Ruby’s static analysis tools.

One of Ruby’s new features will be static typing, something that is present in many languages and is growing in popularity across the web-development world. To add it to Ruby, static typing must be optional. Therefore, the type system has been created to have two levels—one a type checker without signatures and another to read developer notations of types.

The level-one type checker will look for typing based on how a method or variable is called, noting one or more types that could be valid for the code. This will reduce no-method and type errors. The checker is still “very experimental,” said Endoh, as he encouraged the audience to contribute comments as development continues.

The Musical Ruby by Jan Krutisch

Jan Krutisch, cofounder of Depfu, demonstrated a completely handwritten program to create music with code. He started by producing a single note, which required about 15 lines of code. From there, he was able to adjust the pitch, frequency, and volume over time to produce a much more enjoyable sound. Next, he used random numbers to generate white noise, which he then manipulated to create various drum beats.

By the end of the demonstration, he had shown how he created an entire song with pure Ruby code.

Steal This Talk by Aaron Cruz

Experienced conference presenter and freelance developer Aaron Cruz was out of talk ideas. Then he discovered convolutional neural networks and realized he could train one to create a talk. To gather his dataset, he collected or created transcripts from as many Ruby talks on YouTube as he could find.

To train a neural network, one runs a dataset through multiple times. During each pass, the neural network becomes better and better at creating an original item based on what it has been fed. Cruz demonstrated the output of his algorithm at each step, moving from random letters to nonsense syllables, going all the way up to a tech presentation that resembled English.

The goal as the algorithm progresses is to reduce the loss function—a number representing how far the output is from the input. A number less than one is considered acceptable for his dataset, Cruz said.

The Life-Changing Magic of Tidying Active Record Allocations by Richard Schneeman

Taking inspiration from the popular cleaning guru Marie Kondo, Richard Schneeman, creator of CodeTriage and a maintainer at Puma, encouraged the audience to clean up their code. Every object in your code base should be necessary, useful, clean, and performant, he said.

As he refactored his own code, he found that decreasing memory allocation by 1% improved performance by the same amount. As opposed to other methods of improving performance, this is low-hanging fruit. Using a tool called Memory Profiler, he was able to move through his code and find where the greatest memory allocations occurred. By refactoring the most egregious memory hogs, he dramatically increased performance in his system.

The Past, Present, and Future of Rails at GitHub by Eileen Uchitelle

When GitHub Staff Engineer Eileen Uchitelle joined the GitHub team, its code base was built on a forked version of Rails 3, two full major versions behind the Rails master branch. In 2008, the GitHub team decided to fork Rails and start building the features they needed, but, as Uchitelle explained, this quickly created technical debt for the company as they now were responsible for security patches, re-implementation of features, and merge conflicts between new Rails code and their internal version. She led the upgrade of GitHub’s system to work with the newest version of Rails, and the company’s code base is no longer written on a fork of Rails.

Upgrading to the newest version of a library or framework is expensive and time-consuming, she argued, but not upgrading is worse because of the debt that accumulates. When working on a fork it is harder to hire, development is slow and painful, dependencies may not work or may stop working on your version, and you are now responsible for security fixes and need to have security skills on your team that would otherwise be handled by the library’s team.

To successfully upgrade, companies need to have a dedicated team—redundancy of skills and knowledge is important to maintain momentum, she said. This team must make a plan for the upgrade, fix deprecation warnings early to save time later, and finally, create a system to incorporate new updates into the existing code base so that it does not fall behind again.

What we learnt from the event

After two full days of Ruby talks spanning a great deal of concepts, attendees took away the following:

• Ruby 3.0. Late next year, we can expect a new major version of Ruby with performance and concurrency upgrades, and major changes to the suite of static analysis tools available for the language.
• Neural networks. Two inspiring talks on AI technologies left attendees wondering how they could incorporate neural networks into their own work or side projects.
• Performance. Lai and Schneeman’s talks helped attendees conceive of how they might restructure some of their code to improve performance.
• Side projects. A number of the talks highlighted projects that the speakers worked on in their free time that may not necessarily be commercially useful. These were some attendees’ favorite talks—they demonstrated how fun coding can be, even if it is also a job.

What we liked about the event

• EuRuKo organizers and attendees are welcoming and generous with newcomers and outsiders. From the reasonable ticket price to the multiple social events held during the conference, the organizers showed they cared that everyone felt included. The event is held in a different city each year, hosted by the local Ruby community.
• There was a huge variety of subjects and even developer-experience levels presented during the talks.
• Boat puns! Because the conference took place on a boat, the organizers told more shipping, sailor, and pirate jokes than seemed possible.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustrations by WTTJ