An annual event held in Bend, Oregon the first weekend of March.
Developers are encouraged, and sometimes required, to study Computer Science, however a large percentage of us are self-taught or have entered programming through related fields. This sits in stark contrast to most other engineering disciplines, and this diversity is possibly our greatest strength.
Programming sits at the intersection of science, art, and craft. I contend that, given introspection on each of these facets, we will all improve. Learn how formal Computer Science techniques map to real-world problems. Contemplate code as an art form. Think of code as your craft, and continue learning new techniques. Take the time to look at problems through many lenses, and form diverse teams that allow us to solve problems from many different angles.
Removing the "Design Phase". Eschewing Photoshop. Using frameworks. The malleable, flexible, agile nature of web apps these days requires a drastically new approach to how UI concepts are transformed into working code. Join me as I dive into the vagaries of Hashrocket's design-develop-revise-repeat feedback loop – and learn how we turn static markup into an essential communication tool through rich UI prototyping, generated content, and general cleverness.
Creating games is crazy fun and dirt simple with Ruby. You will leave this session with a working game; no previous game development experience necessary. We will introduce basic concepts of game programming and show how to implement them using the Gosu library. This includes the game loop, sprites, animation, camera movement and hit detection. We will build a complete game, so you might want to bring your notebook and follow along.
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.
With a peculiar vocabulary, strict traditions, and heaps of arcane lore, brewing beer yourself can be overwhelming to the uninitiated… not unlike learning programming. But the basics of homebrewing are easily accessible with a bit of knowledge and some modest equipment. Like Ruby, brewing can be eased into, the complexity and variety of your tools growing alongside your skills. Step by step, we'll see how to make a delicious, quaffable beverage. Along the way we'll highlight how simplicity, experimentation, and an eye for quirkiness can make the act of creation--be it beer or code--awesome fun.
To paraphrase Mark Twain, "I didn't have time to write some small classes, so I wrote a BIG ONE instead." Now what do you do? Refactor! In this talk we'll refactor some large classes into a series of smaller classes. We'll learn techniques to identify buried abstractions, what to extract, what to leave behind, and why delegation, composition and dependency injection are key to writing small things that are easier to test.
In late 2011, at age 30, I was diagnosed with ADHD. This is the story of how I noticed something was wrong and eventually got treatment. I'll talk about how ADHD is defined, what it looks like for me, how it has affected my life, and what I did to help myself.
In theory, object-oriented applications consist of small, interchangeable objects which know almost nothing about one another. In reality, many Ruby apps contain big classes full of long methods built of many conditionals. Our classes act more like procedures than objects; they know too much, they contain code we can't reuse, they're hard to change and they get worse every time we do so. This talk uses the principles of object-oriented design to break ugly procedures into pleasing objects which have just the right balance of knowledge and ignorance. It bridges the gap between theory and practice and reveals a few simple secrets of OOD that you can use to convert confusing, unmaintainable faux-OO code into understandable, reusable, easily testable objects.
It all started with a dream. A dream of a world where people have learned to live in harmony with nature, where war is a distant memory, where humankind reaches unimaginable heights of technological innovation and Magic: The Gathering players no longer need to sort their cards by hand. This presentation will describe in detail the life-changing technological leaps that led us to this collectible card game utopia, examining the scanning, recognition and sorting of small bits of cardboard and all the Ruby that allows the magic to happen. If you've ever dreamed of being able to live your planeswalking dreams without the requisite hours of collating your cardboard collection, this is the presentation for you.
Distributed systems are big, in every sense of the word. From the biggest social networks and search engines to the simplest web or iOS application, distributed software causes problems, stemming from its greatest feature: the system should continue working even when parts break. Client applications without network connections still want to capture data, backends with a failed service or two shouldn't break the entire application, and the app should still mostly work even when the big datacenter (you know the one) goes down. How do you grow a simple monolithic Rails app into a distributed system? What does it take to make your UI save data for a network connection later? How do you even test all this stuff?
Really? Math? With the boring formulas and definitions and proofs? Yes, math. But not that kind of math! The kind of math that challenges our creativity. The kind of math that explores the beautiful patterns that connect seemingly unrelated things in wonderful and surprising ways. The kind of math the helps us understand the problems we solve and the programs we write, makes complex things simpler, difficult things easier, and slow things faster. The kind of math that just might make you excited about learning math for the first time. The kind of math that you didn't even know was math. So come get some math in your Ruby. I think you'll like it.
It's your first day at Hogwarts.com, and everything is wonderful and thrilling. You dig in to classes, and soon find a dusty book with a cryptic warning:
"Do NOT on any circumstances make ANY change to this magic incantation without talking to Doug first!!!"
Sound familiar? Approaching a legacy code base can feel like unraveling a mystery, not just about the code, but about the personalities who wrote it. What tools and techniques can help you solve the maze of twisty code? Let's explore how to get a handle on legacy code, how to negotiate joining an existing team of developers, and how we can get asumma cum laude at graduation.
Maintaining RubyGems, RDoc and other Ruby libraries has grown from a hobby to my full time job over the past six years. Working on and maintaining open source projects has brought me lots of fun and enjoyment. I'll cover the joy and pain of being an open source developer, strategies for maintaining both your project and the interest and happiness you derive from it. I'll also talk about some of the things that keep me motivated to continue working on open source.