LunchConf talk recommendations
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
Title of talkSpeaker nameTalk abstractLength of talkLink to video of talkLink to slides for talk
Therapeutic RefactoringKatrina OwenEnter deadline center stage, exit best practices, quietly, rear stage left. The results are rarely pretty. Refactoring can pry panic’s fingers away from your poor, overburdened adrenal glands and restore your sanity. Not that it went missing, of course. Never that! This talk will cover the two reasons why refactoring works as well as (or better than) whiskey, sky diving, and massages as therapy, explore a handful of effective strategies to ensure that the rubber meets the road, and contains gory before shots and slick after shots of ruby code that has served therapeutic purpose.
(Ruby examples, but probably techniques apply to non-Ruby too)
Here be DragonsKatrina OwenIt's not your fault. Code rots. We don't hold entropy against you, but we expect you to give a damn. This story is about code that brings new meaning to the word 'legacy'. The accidental discovery of this body of code provoked a moral crisis. I wanted to pretend I hadn't seen it, yet I couldn't justify tiptoeing quietly away. This talk examines the dilemmas we face when balancing our choices today with their cost tomorrow. It's not your fault. Even so, it is your responsibility.24
First Do No Harm: Surgical RefactoringNell Shamrell-HarringtonWhen a developer comes into an existing code base the urge to refactor can be overwhelming. However, legacy code bases – even those created and maintained with the best intentions – often resemble living organisms more than modular machines. Rather than simply taking out a module and replacing it with a better one, we have to surgically slice intricately connected sections of a code base apart and precisely tie each one off to prevent it from bleeding into another section. We also have to operate with the fear that a change in one part of a system may adversely affect other parts or even kill a critical piece of our application or infrastructure. This talk will teach you how to recognize the difference between necessary and cosmetic refactoring and how to assess and evaluate the risks of each. You will also walk away knowing how to develop safeguards and bypasses to minimize potential harm before, during, and after a refactor, as well as how to recognize the point of no return when rolling back a refactoring is riskier than keeping it in production. Maintaining a code base means you must constantly juggle the wish to improve it through refactoring and the potential side effects – you will walk away from this talk with clear techniques to help you find and maintain this balance.31
Beneath The Surface: Harnessing the True Power of Regular Expressions in RubyNell Shamrell-HarringtonMany of us approach regular expressions with a certain fear and trepidation, using them only when absolutely necessary. We can get by when we need to use them, but we hesitate to dive any deeper into their cryptic world. Ruby has so much more to offer us. This talk showcases the incredible power of Ruby and the Onigmo regex library Ruby runs on. It takes you on a journey beneath the surface, exploring the beauty, elegance, and power of regular expressions. You will discover the flexible, dynamic, and eloquent ways to harness this beauty and power in your own code.32
All The Little ThingsSandi MetzTheory tells us to build applications out of small, interchangeable objects but reality often supplies the exact opposite. Many apps contain huge classes of long methods and hair-raising conditionals; they're hard to understand, difficult to reuse and costly to change. This talk takes an ugly section of conditional code and converts it into a few simple objects. It bridges the gap between OO theory and practice and teaches straightforward strategies that all can use to improve their code.
(Gilded Rose kata)
The Magic Tricks of TestingSandi MetzTests are supposed to save us money. How is it, then, that many times they become millstones around our necks, gradually morphing into fragile, breakable things that raise the cost of change?
We write too many tests and we test the wrong kinds of things. This talk strips away the veil and offers simple, practical guidelines for choosing what to test and how to test it. Finding the right testing balance isn't magic, it's a magic trick; come and learn the secret of writing stable tests that protect your application at the lowest possible cost.\
Get a Whiff of ThisSandi MetzMost code is a mess. Most new requirements change existing code. Ergo, much our work involves altering imperfect code.
That's the bad news.
The good news is that every big mess consists of many small ones. Certain small problems occur so frequently that they've been given names, and are collectively known as "Code Smells".
This talk shows how to take a pile of perplexing code, identify the "smells", and surgically apply the curative refactorings. It breaks a messy problem into clear-cut pieces, and proves that you can fix anything without being forced to understand everything.
Time flies like an arrow; fruit flies like a banana: Parsing for fun and profitHsing-Hui HsuHow do we make sense of a regular sentence, especially when they take us down the "garden path"? For example, when we see a sentence that starts with "The old man," most of us would expect the next word to be a verb. So when we read, "The old man the boat," we have to backtrack to re-evaluate what the subject of the sentence really is. Humans are naturally attuned to parsing grammar in natural languages by analyzing the role and meaning of each word in context of its sentence. However, people may find the idea of parsing a computer language intimidating. In this talk, we'll explore the way we normally make sense out of an expression and relate that to the way parsers are used in computer science. By understanding the way we are inherently programmed to parse sentences, we can better understand common parsing strategies and how we can incorporate those tools into our code.30
Twenty Thousand Leagues Under ActiveRecordPat ShaughnessyWe all know ActiveRecord allows you to perform complex SQL queries using simple, elegant Ruby code. It’s like magic, a useful magic we all use everyday in our Rails apps. But how does it actually work? We’ll find out by first exploring the shallow waters just under ActiveRecord: What is relational algebra? How does the Arel gem generate SQL strings from Ruby objects? Later, we’ll dive into much deeper waters - all the way inside the PostgreSQL database! We’ll discover what does Postgres does with our SQL strings, where our data is actually located, and how Postgres finds what we want. Join me and learn exactly how your Rails app gets the data it needs. Like the strange places and creatures Jules Verne described in his underwater adventure, we’ll discover fascinating data structures and computer science algorithms you never knew you were using.38
Ruby InternalsPatrick FarleyRecommended by someone as "The clearest explanation of Ruby method dispatch that he's seen"50
wow such fair isle: Adventure in Electronic KnittingAmy WibowoIn the 1980's, Nintendo had plans for making a knitting add-on to the NES, with an interface that resembled Mariopaint, but with patterned mittens, sweaters, and scarves as output. Sadly, this product never saw the light of day. Devastated upon hearing this and dreaming about what could have been, a group of Airbnb engineers (who knew nothing about machine knitting) set out to hack a knitting machine from the 1980's to be computer-controlled, using a tutorial from adafruit as a starting point.

Hear about our struggles and triumphs, which ranged from learning to replace knitting machine needles and conduct basic repairs, to emulating a floppy drive and hacking together a custom cable cable to send our own patterns to the machine, to writing our own yarn printer API in ruby/rails and printing our first doge meme in yarn. And watch us (LIVE!) as we send images and knit requests to our yarn server, and behold as it knits ugly sweaters from those images!
Visualizing Garbage Collection in Rubinius, JRuby and Ruby 2.0Pat ShaughnessyIn this talk we’ll dive into Ruby internals and take a close look at an ugly topic: garbage collection. How do these Ruby VM’s allocate memory for new objects? How do they identify unused objects? How do they reclaim memory from garbage objects, allowing it to be used again? You can learn a lot about someone from their garbage. Using a series of diagrams, we’ll visually compare and contrast the complex algorithms these very different Ruby implementations use. What computer science research is behind each garbage collector? We’ll also look at the GC changes planned for the upcoming Ruby 2.1 release.35
Speed ScienceRichard SchneemanRun your app faster, with less RAM and a quicker boot time today. How? With science! In this talk we'll focus on the process of turning performance problems into reproducible bugs we can understand and squash. We'll look at real world use cases where small changes resulted in huge real world performance gains. You'll walk away with concrete and actionable advice to improve the speed of your app, and with the tools to equip your app for a lifetime of speed. Live life in the fast lane, with science!41
How to performanceEileen UchitelleUnderstanding performance output can feel like reading tea leaves. It makes sense to a few people, but many of us are left in the dark; overwhelmed and frustrated by the data. On top of that there are a ton of performance tools to choose from; StackProf, RubyProf, AllocationTracer. Where do you even start? While working on speeding up integration tests in Rails source, I learned that the key to improving the performance of Ruby code is having a baseline, not relying on one profiler and understanding the advantages and limitations of your tools. By utilizing these methods, integration tests are now 3 times faster than they were in Rails 4.2.0, with more improvements being made every day. In this talk we will not only look at how to read performance output, but when and how to use the right profilers for the job. We'll discuss a variety of methods and techniques for benchmarking and profiling so you can get the most out of any performance tool.26
Thread Safety FirstEmily StolfoWe rubyists historically haven’t been in the habit of thinking about concurrency but the reality is that our thread-unsafe code often works by sheer luck. There are different implementations of Ruby with their own semantics that can unearth challenging and unexpected concurrency bugs in our code. We have to become more accustomed to writing threadsafe code in order to anticipate these potential surprises, especially in light of the rise in popularity of JRuby. I will discuss approaches to writing threadsafe code in this talk, with a specific focus on performance considerations and testing. We’ll look at some basic concurrency concepts, describe methods for handling shared mutable data, and touch on the subtleties of some concurrency primitives. Hair-raising, real-world bugs will be used throughout the presentation to illustrate specific concurrency issues and techniques for solving them.43
Dissecting Ruby with RubyRichard SchneemanUnderneath the beautiful veneer of our Ruby libraries lies a twisted tangle of writhing guts. Maybe you're curious how the pieces fit together or maybe you're tracking down a bug, either way it's easy to get lost in the blood and bile that ties our code toget ou'll learn how to use simple and sharp Ruby tools to slice into large libraries with surgical precision. Turn your impossible bugs into pull requests, and level up your programming skills by Dissecting Ruby with Ruby.42
SuccessionKatrina OwenRefactoring sometimes devolves into an appalling mess. You're chasing a broken test suite, and every change just makes it worse. An even more insidious antipattern is the slow, perfectly controlled process culminating in dreadful design.

This talk presents an end-to-end refactoring that demonstrates simple strategies to avoid such misadventures.
Easy rewrites with ruby and science!Jesse TothRuby makes it easy to prototype a new data model or codepath in your application and get it into production quickly to test it out. At GitHub, we've built on top of this concept with our open source dat-science gem, which helps measure and validate two codepaths at runtime. This talk will cover how we used this gem and its companion analysis gem to undertake (and complete!) a large-scale rewrite of a critical piece of our Rails app -- the permissions model -- live, side-by-side, and in production.34
Stuck in the Middle: Leverage the power of Rack MiddlewareAmy UngerBefore a request ever hits your Rails application, it winds its way through a series of pieces of Rack middleware. Middleware sets session cookies, writes your logs, and enables the functionality in many gems such as Warden. With Rails or any Rack app, you can easily insert your own custom middleware, allowing you to log, track, redirect, and alter the incoming request before it hits your application. You will leave this talk confident in writing your own custom middleware, better able to troubleshoot gems that rely on middleware and with an understanding of how your Rails app functions.35
Why You Don't Get Mock ObjectsGregory MoeckAlthough the Ruby community has embraced TDD like no other community ever has, we have always looked at mock objects with disdain, and perhaps even a little hatred. I've heard conference speakers call them "Wastes of time", "Scams", and even "Testing Heresies". Why would anyone have ever developed these pieces of junk? In reality though many in the agile community have embraced mock objects within their testing cycles because they have found using these fake objects improves the design of their systems. But why not Rubyists? Most Rubyists don't get mock objects because they don't understand their history or their creators intent. They try to fit them into their current workflow without understanding them, and find them unhelpful and stupid. After all, almost all of the good literature on the subject is written in Java, and we know how frustrating it is to read Java when your used to Ruby. As such, this talk will attempt to demonstrate in Ruby the usefulness of mock objects, and how to use them to improve the design of your system. Specifically the following will be covered: * Why do we need mock objects (Following the 'Tell, Don't Ask Principle') * Why you should only mock objects you own * Why you shouldn't use mocks to test boundary objects like external API calls * Why you should mock roles, not Objects * Why you should only mock your immediate neighbors * Why listening to your unit tests will tell you about design problems in your code45
Main menu