Timeline

We’ve all heard the phrase “Rails doesn’t scale”. Long running test suites and no standard for implementing multiple databases makes it hard scale monolithic Rails applications. Rails 6 will start making Rails scalable by default with parallel testing and improved support for using multiple databases. You’ll no longer be forced to reinvent the wheel and create your own solution to these problems. In this talk we’ll take a look why these improvements are important, how they work, and ways in which small ideas can quickly snowball into major changes. This is just the beginning of Rails 6.

As day-to-day developers we all struggle with bugs, maintaining and moving around each other’s code. Piling up layers of it makes our code bases grow out of control to the point where bloated code obscures the understanding of our own solutions.

Losing trust in the tools we use is the first step to writing legacy code, and dealing with codebases like these is one of the primary sources of stress and discomfort in our jobs.

So what makes code comfortable? What makes a codebase habitable? Why do we strive to write simple solutions and what are the obstacles behind them? We’ll go over this questions while looking at code samples from various less-popular-yet-powerful tools in Ruby-land , trying to spot the “less-code” in them.

I’ll also share some of my experience in how this less code type of thinking helped me to get back to the basics and spot my own ignorance, to become a better programmer.

Want to build a Bot without the hassle of provisioning and managing servers? Amazon’s got a service for that and it’s called AWS Lambda - it executes your code only when needed, scales automatically and you pay only for the compute time you consume.

There’s one problem with Lambda - it doesn’t support Ruby! 
Let’s checkout multiple options on how to build a Ruby Bot and package it into an executable which you can run on any machine without the need to actually have Ruby installed.

All technology professionals should understand machine learning well enough to recognise situations where it is most beneficial and appropriate. Even if you are familiar with machine learning, you will walk away with renewed interest and inspiration for ways you can apply it, and maybe learn about food and wine along the way.

I’ll introduce you to machine learning, some ways it can be applied, when it is most beneficial, as well as the major tools available in Ruby. I’ll also show you a practical example: my wine pairing chat bot. We’ll go through the process of breaking down the fundamentals of tasting, and introduce the challenges around pairing wines, and wine-food interactions. I’ll show you how I use machine learning to enable the bot to converse, recognise flavours, and recommend wines based on those flavours.

A junior developer will join your team. If nothing is done, he/she will be very likely unproductive for a long time. You and me have been there too. This is not a great experience, for nobody. Still, great engineers need to be made, and it starts from day one. Based on my experience and the EURA NOVA onboarding, I’ll discuss why onboarding is important, which elements are required, how to plan and do it, and which common pitfalls to avoid.

It is a case study combined with some nice Ruby technology. In the mid-late 2000s, I was doing web sites for financial companies. These were combinations of static content with dynamic content and small applications. They needed to be fast, to be reliable, to almost never go down, and to be able to scale as needed; they also needed to be cheap to run. What evolved from this was a 100% Ruby stack, from the layer that interacts with the user’s web browser to load balancing of requests to the application back ends, that was all written in Ruby.

It was fast (really, even in the Ruby 1.8 days), stable, capable, and extensible, and has evolved in use on production web sites for 10 years.

We’ll look a little at the components involved, why it was done this way, and some practical lessons for modern web sites.

This presentation is a deepening of the graphql-ruby and graphql-batch gems, with a proposal of a modern, domain driven, backend API architecture.

It’s a re-organization of the Rails basic MVC architecture, with only one controller, the GraphQL controller, the models, and all the code in the graphql folder, separated by domains.

The idea is to have for each domain: a type, an input type, and a service object, that exposes the index/show/create/destroy/update methods, which can be rewrite to add business oriented code.

This architecture is live in the startup I work on, and is delightful to maintain.

In 2001, we produced a exhibition work “A Hands-On Model of the Internet” at the National Museum of Emerging Science and Innovation in Tokyo. The work shows the workings of “packet switching” mechanism with white and black balls.

How many times have we dutifully repeated the same mouse and keyboard actions, missing the irony that we spend our lives automating things for others, but so often neglect to do so for ourselves?

This talk will walk you through the design and implementation of a wifi command line utility for the Mac – one that you could use as a model for automating your own manual process, including:

• the multitude of cost/benefit decisions, including many compromises for speedier completion.

• command suite (e.g. git) vs. option based (e.g. grep) design

• how to address a target audience that includes non-Rubyists

• class design, including separating back end functionality from command line & user input plumbing, and multi-OS support

• providing an interactive shell in your utility

After this presentation you will be able to make a better informed decision about the optimal balance of effort and functionality, and be better equipped to write an excellent implementation.

In this talk we would take a look in why keeping your application up-to-date is important and different strategies to upgrade Rails application to the newest version taking as example a huge monolithic Rails application. We will learn what were the biggest challenges and how they could be avoided.

In applications that persist data, getting the current state of the system is trivial. But often the question is not only where are we now, but how did we get here? Event sourcing is a pattern that stores changes to state as a sequence of events. The events encapsulate all the information needed for a record to change from one state to another, and the current state can be completely destroyed and rebuilt by replaying these events. Sounds great, right? But how do we take a system that is not designed using event sourcing, and start to apply some of these patterns? I’ll give an overview of the architecture’s key components and share some examples of how to adopt event sourcing into an existing application.

Runtime errors can sometimes turn into dark and unpleasant journeys which lead you to question the nature of reality. Thankfully, Ruby often provides friendly feedback for understanding the cause and remedy for exceptions. Yet, there are situations in which programmers don’t receive clear enough context for what really caused an exception and how to address it. We’ll look at Ruby’s error feedback mechanisms and search for constructive ways in which they can be made more helpful to humans.

The RubyGems is a mechanism to install libraries via the Internet without standard libraries. As maintenance manager of RubyGems and core member of Ruby core team, I’m working to merge the latest version of RubyGems with a latest stable version of ruby every year.

In this presentation, I will introduce the new feature of RubyGems 2.7 and describe the mechanism of integration with Bundler. Finally, I introduce a roadmap for RubyGems 3 and 4, which is developing for Ruby 2.6 and 3 release.

Through this talk, you will be able to enjoy the ruby world more by understanding RubyGems at the center of ruby’s ecosystem.

Many devs struggle when understanding humans. Why can’t they be as simple as code? But sometimes, living with humans gives interesting lessons to apply to your code. Are you an engineer or manager? A beginner or experienced coder? We have many code principles that can be weird, or dangerous if applied too litterally. My goal is to give simple metaphors, for you to explain to your teams how patterns can be used or misused, for a cleaner codebase and better team communication.

We all enjoy the flexibility and expressiveness that languages like Ruby give us, but such flexibility is also paired with the unknown. Dealing with dynamic data and runtime conditions can lead to unknown scenarios and runtime errors.

Compiled languages, specially today offer a fresh perspective and help us developers better understand and shape our code.

This talk aims to discover certain techniques transfered from compiled languages’ realm and transfer those to dynamic languages like Ruby. Will talk from my experience working on mid-size Ruby projects (8K+ LOC).

Full description here: https://gist.github.com/luislavena/2adca9ccb341f0a675f9767ed0b0e54b

Writing tests is a significant part of the Ruby development process.

The test suite’s run time increases as the application evolves. We don’t care until we found ourselves wasting too much time waiting for the green light.

What makes tests slow and how to heal them? Let’s answer these questions.

I would like to start the talk by answering several questions, e.g., “Do you write tests?”, “How long does your test suite run?”, etc. Some stats & charts.

In the first part of the I would like to share a few real-life stories: “Our tests were slow, we did some investigation, and the reason was X.” Most of these reasons are related to incorrect environment configuration for tests.

The second part of the talk is answering the question: how to find bottlenecks in your tests?

I’m going to introduce the tool called TestProf–a toolbox for profiling test suites and a set of ready-made recipes to write faster tests and fix your existing slow codebase.

Let’s make tests faster!

An exploration of the challenges that Ruby faces today, combined with ideas regarding how we can change things for the better. We’ll talk about the language, its ecosystem and its community. While on this bold adventure we’ll plot a course towards Ruby 4.0 - a mystical and magical Ruby release that would ensure Ruby’s dominance to infinity and beyond! Oh, and did I mention we’ll have a ton fun while doing so? We’ll most certainly do!

Much of how we understand, describe, and value code is based on subjective criteria that are easy for us to grasp intuitively but almost impossible to define or communicate objectively.

Can advances in applied aesthetics and theoretical neurology provide insights into the advantages and disadvantages of relying on such elusive criteria? Do mathematical and evolutionary theories indicate that our code evolves aesthetically to enhance its survivability, durability, and success?

This talk will explore the role that concepts such as beauty, sublimity, completeness and simplicity play in the way that we model reality in software, relate to our own and other people’s code, and ultimately measure the value of our work as professionals.