rubyday 2020
16 Sep 2020 at Verona

Abstractions are both our blessing and our curse. Because of them, we're so powerful. But also we so often fall into the trap of miscommunication :( Abstract rules, operating with abstract terms, built on top of other abstract ideas. Ugh... In this talk, we're going to build a visual language to make things LESS ABSTRACT. I'll show you how it helps in: 1. teaching others 2. explaining non-obvious concepts 3. refactoring messy code 4. tracking codebase changes

3

As Rails developers, using ActiveRecord as our database library is a given. As our application grows, we start noticing that some of our new requirements aren't exactly supported by the ActiveRecord API. So, we pull up our sleeves and write that raw SQL snippet, re-create some queries without models to get that extra performance gain, or work around that bug in the library, and move on. But gaining this technical debt isn't necessary if you're using a library that supports your advanced use cases. Enter Sequel, an alternative ORM for Ruby. In this talk we will show some advantages that Sequel has over Active Record, covering topics like the query API, building SQL expressions (Arel), connection pools, immutability and more.

Enterprises have embraced Open Source software - but their grip is suffocating. Business critical software is plagued by vulnerabilities because of maintainer burnout. We're looking for more sustainable models, and regaining control over what our code can be used for - enter the Hippocratic License. GitHub taking down software that was vital infrastructure for opposition groups in Spain shows us that no one party (let alone company) should own access to open source software. The world runs on open source, how do we make sure it can do so sustainably and reliably?

Product metrics could be handy to analyze feature performance and get in-depth into business essence. But they are mostly out of the developer's scope. I am going to tell you why developers should use product analytics and how easy set it up in your project.

We all know the good feeling that comes from starting a green field project and being able to use all the great new technology. But what if you have a 460k LOC monolith but you really feel that a new GraqhQL API is the way to go. Well, if you have good design, you can totally do it, and here's how. GraphQL is all the rage for good reason. It's geared towards solving the problems REST API's have when used by modern front-end apps. However, new technology often has a way of breaking apart when subjected to legacy projects. How easy is it to create a GraphQL API for a commercial project with 7 years of active development and 400k users? What difficulties might you encounter that blurbs and blog posts won't tell you about? I'll cover all that and more in this riveting tale of fun, sweat and tears (of joy).

Peer deep into Rails' database handling and you may find the code overly complex, hard to follow, and full of technical debt. On the surface you're right - it is complex, but that complexity represents the strong foundation that keeps your applications simple and focused on your product code. In this talk we'll look at how to use multiple databases, the beauty (and horror) of Rails connection management, and why we built this feature for you.

If you work around Ruby long enough, you’ll learn that certain ideas are just taken as gospel. Don’t use for loops, avoid global state, use symbols pretty much wherever possible. This talk will go deep into the ‘why’ behind some commonly accepted advice on Ruby, dig into the internals, and what we find might just surprise you.

Most programmers don't need to think about allocating or deallocating memory, and they have the garbage collector to thank for that! In this presentation we'll discuss the latest developments in GC compaction as well as how the GC allocates and arranges memory internally. Once we understand this we'll explore a strange way Ruby is decreasing memory usage by allocating more memory. The GC manages memory so that you don't have to, but we're going to see how it's actually done!