Video recording and production done by RubyConf Portugal
There’s nothing more frustrating than not being able to deliver new features because of unnecessarily complicated code. You may decide it’s time to throw it all away and start over… and what starts off full of optimism, drags on for months and months, adding even more complexity and various levels of legacy.
It doesn’t have to be this way! In this presentation, you’ll hear a first-hand experience of a rewrite project that was successful in more ways than expected.
This talk will teach you lessons on how to start, and most importantly, finish a big rewrite project. You will learn how to avoid the most common pitfalls when changing the architecture of a complex codebase, how we took our first steps towards a service oriented architecture, and moved to continuous deployment.
This rewrite project was a transformative process, not only of our codebase, but of our culture. During this time, our company discovered that by working together in cross-functional teams we can be more productive and deliver better products.
Writing good object-oriented code is hard: object boundaries are not always as clear-cut as we’d like, their responsibilities and reasons to change tend to grow over time, inter-object coupling makes isolated testing complicated – and emergency refactorings are tiresome, gnarly and seem to always happen too late. At the same time it’s often hard to see the exact moment when a simple refactoring would save a given class from taking the wrong turn, and real-life projects tend to have real-life sadlines with their tireless chants of ‘let’s refactor this in thenext sprint’.
Ruby’s dynamism means static code analysis is tricky (to say the least), but tools like RuboCop and reek bravely show it’s not impossible. This talk shows how to effectively use such tools, make informed decisions on when and how to refactor, and – most importantly – learn over time to spot potential code smells right when they’re introduced.
Up until the 17th century, the world was mostly limited to what we could see with the naked eye. Our understanding of things much smaller and much larger than us was limited. In the past 400 years our worldview has increased enormously, which has led to the advent of technology, space exploration, computers and the internet. However, our brains are ill equipped to handle dealing with numbers at these scales, and attempt to trick us at every turn.
Software engineers deal with computers every day, and thus we are subject to both incredibly tiny and massively large numbers all the time. Learn about how your brain is fooling you when you are dealing with issues of latency, scalability, and algorithm optimization, so that you can become a better programmer.
You arrive at a foreign land just as the day is ending. Soon, you encounter your first obstacle: the directions you had to your hotel do not seem correct. You know the local language and feel confident enough to find directions on your own. A few steps along the way, you find the first sign:
Possible infinite loop. Choose direction carefully.
We all been here before, trying to find a path to understanding in code written by many different hands and voices. This talk examines the balance between being the traveller of legacy code and one of the its narrators to future visitors.
Everybody seems to be into sexy consumer apps or small business SAAS these days.
We are not quite.
In the last two years we built numerous applications for the industry, from production management in printeries to warehousing/accounting for one of the biggest cargo handlers at Frankfurt Airport.
In this talk I want to give an overview over the technologies we used, starting with Rails and ending in mobile techs like Ember, Cordova or even native Swift. I present a report from the battle field, where we experienced many problems first-hand and had to make sure our precious tools hold up to the dirty production world of warehouses full of barcodes and ink-fumed printing shops.
What we learned however is applicable to every Rails programmer out there, especially when a multitude of (mobile) devices come into play. Also, I want to show you how awesome and indeed sexy it is to work for the industry, while they are starting their fourth revolution, which is software and UI/UX driven and thus shaped by us, the software writers.
The most useful APIs are simple and composeable. Omnipotent DSLs can be great, but sometimes we want to just write Ruby. We're going to look at the process of designing a new API for attributes and type casting in Rails 5.0, and why simpler is better. We'll unravel some of the mysteries behind the internals of Active Record. After all, Rails is ultimately just a large legacy code base.
In this talk you'll learn about the process of finding those simple APIs which are begging to be extracted. You'll learn the refactoring process that can be used to tease them out slowly. And you'll be getting a sneak peak at several of the features coming in Rails 5.0.
Keyword parameters are introduced from Ruby 2.0. This feature helps us to write readable Ruby program. However, Ruby 2.0 and Ruby 2.1 have a performance issue because the keyword arguments are passed by Hash objects. Ruby 2.2 solves this performance issue and achieves over 10 times faster implementation. In this presentation, I introduce a brief history of Ruby's keyword arguments and keyword parameters, and implementation techniques to make them faster.
Learning a new language is a great way to appreciate languages you already know. In this talk, Steve will teach you about Ruby internals by comparing and contrasting them with Rust code.
Defensive programming is one of those abstract ideas that seems great. We all want to use these ideas to ensure the long-term maintainability of our codebases. It is, however, often unclear what we should be defending against and what form those defenses should take. We can find places where defensive patterns could be added by looking at the edge cases that occur in our system. Where it seems appropriate, we can then apply ideas and patterns from defensive programming.
In this talk we'll look at some of the extremely defensive patterns that have been driven out in RSpec throughout the years. We'll look at building Ruby that works accross a wide range of interpreters and versions (including 1.8.7!). We'll investigate how you can write code that defends against objects that redefine methods like send, method and is_a?. We'll also see how the behaviour of prepend can occasionally confuse even the most mature source bases.
You should come to this talk if you want to learn about inheritence and method resolution in ruby, defensive programming techniques and cross interpreter Ruby patterns.
"Did you really think you could make changes to the database by editing the schema file? Who are you, Amelia Bedelia?"
The silly mistakes we all made when first learning Rails may be funny to us now, but we should remember how we felt at the time. New developers don't always realize senior developers were once beginners too and may assume they are the first and last developer to mix up when to use the rails and rake commands.
This talk, presented in a storybook style, will be a lighthearted examination of some of the common mistakes (and causes of those mistakes) made by beginner Rails developers.
There are over 100,000 gems in Rubygems, enough for the Ruby community to have coined the half-joke “there's a gem for that” as an answer to everything. When presented with a new problem, a rubyist's first impulse is often searching for that gem. And yet, it is often the case that, for the sake of simplicity, we would be better not doing that. Why add another dependency without first checking whether the standard library already covers that. Because there are many overlooked pieces of the standard library that will be handy for us and solve our problems in a simple, dependency-free way.
This talk will cover 5 of them (since it is impossible to show them all). You'll learn how to use 5 new tools that you already have, and on top of it you'll learn to always look there first ;)