Fluency is "what you can say without having to think about how to say it." "Refactoring" is a language that describes ways to make your code suck less. I want to inspire you to become more fluent in that language, so you can make your code suck less without having to think about it.
I'll walk you through the process of reworking a 50-line Rails controller action that's hard to comprehend, let alone refactor. We'll tease apart fiendishly intertwined structures, embrace duplication until we grok what it's telling us, use evil hacks to our advantage, and uncover responsibilities—and bugs!—that weren't obvious at first glance.
The brand new Spree 2.2 release contains a complete refactoring of how adjustments are handled. Whether you're interested in taxes, shipping or promotions you'll want to attend Ryan Bigg's comprehensive talk and learn more. The talk will include motivation for refactoring as well as how to get up and running with the new adjustment code.
You know you should be testing all the time, but do you know why you are testing all the time? One of the main benefits of testing all the time is that it lets you refactor with impunity. Unfortunately too many times we leave the “refactor” out of the red-green-refactor. In this talk I will convince you that you should be refactoring all the time and I’ll show you some of the techniques on how you can do it. With good refactoring techniques and regular refactoring even the hairiest of codebases can be tamed.
Sure, the TDD cycle is red-green-refactor but what exactly are we refactoring? We just wrote the code, it's green, and it seems reasonable to us. Let's move onto the next test. We're have a deadline, remember?
Whether we're working with code we just wrote or opening up a project for the first time, being able to listen to the hints the code is trying to give you about how it wants to be constructed is the most direct path toward successful refactoring. What the code is telling you nuanced however: no code smell is absolute and none in itself is an indication of a problem. How do we know we need to refactor? What are the code smells telling us to do? How do we balance our short terms needs of shipping our software with the long term maintainability of the code base? In this talk we'll talk through some of the classical code smells and dive into examples of how to put these smells to work for you.
Rails as a framework is famous for getting an application up and running quickly, but the very paradigms that make it so easy at the start can lead to maintenance nightmares down the road. Successful applications grow rapidly larger, more complex, and harder to extend and maintain. One way to approach refactoring a monolithic application is dividing it up into a series of smaller applications that organize the work of the system through internal APIs and message queues. In this presentation you will be introduced to tools to enable this architecture, gain insight on how best to use them, and explore the guiding principles behind the SOA approach to refactoring.
Ruby is used for a lot of things, but for some reason, only a few people are using it for music. In a language that is meant to make programming fun, the lack of such creative code is scary. Let's fix the current landscape by learning how to use the tools available in Ruby (and some not) to let those creative juices flow. We will be focusing on how to build sounds from the ground up (the powerful amplitude, and the majestic waveform), so you don't need any prior audio wizardry. Just bring yourself and a Ruby console and we just might create some beautiful music in a beautiful language.
In Ruby, it's easy to create classes, methods, and objects. For instance, did you know that a hello world sinatra app uses 43 classes, 155 methods, and dispatches 548 methods for a single request. In this talk, we're going use TracePoint API to look at how you can find out this information among other things. Additionally, now that we have all these objects from our Ruby app, the evolving ObjectSpace API we can glean information about rough object size in memory. Let's take a walk through objects in Ruby.