Software marches forward; each new piece is better than the last in every way! Not quite... it's a bit more subtle than that. There are patterns in the history of our industry: each tool or practice is a reaction to something before it. By paying attention to the pattern, and to the types of reactions, we can better understand our history and our current tools' place in it. More importantly, we can avoid repeating the mistaken reactions that our predecessors have had to new tools.
Threads versus events: which should you choose? How about both? In this talk you'll learn about the Celluloid concurrency framework, which combines OOP and the Actor Model to give you concurrent Ruby objects. You'll also learn about how Celluloid lets you combine blocking I/O and asynchronous evented I/O, offering you all the benefits of EventMachine without the restrictions of a single event loop. The talk will also provide a brief introduction to DCell, a distributed extension to Celluloid.
Do you know what SRP and SOLID mean? No? Then this talk is for you. This talk will introduce you to some lesser-practiced techniques in the Ruby world. These techniques will allow you to write code that is easier to test, easier to maintain, and easier on the eyes.
In this stunning half-hour EXTRAVAGANZA of mind-blowing talkifying, I will show you what's wrong with Ruby's objects is actually what's right about Ruby--and how this has led a lot of programmers down the garden path to unintentionally writing hard-to-maintain code.
You may think you know how to problam with the Object Oriented Things. But! My friend, listen: There is a worldwide CONSPIRACY TO HIDE THE TRUTH about REAL object-oriented programming!
BUT NO MORE! For in this big-budget presentation MAELSTROM OF KNOWLEDGE, I shall RIP ASUNDER the veil of ignorance and together we will walk, hand in hand, arm in arm, or at a polite distance of your prefererence, into the LIGHT OF WISDOM.
I'm gonna bring some nasty code, and we gonna refactor it. We will use objects. We will use Immutability. We may even use EAST-FACING CODE. That didn't actually need to be in caps because it's a real thing. And it's going to be sweet. CAN I GET AN AMEN
Pry is a relatively young tool that makes DRb a whole heck of a lot more useful. Paired with pry-remote for easy setup with Pow or Passenger, it provides a useful window into the execution of your app/program/nuclear launch script, with its mad live-code-modification-fu and step-by-step execution.
We've all seen monolithic Rails models: pages and pages of methods all dumped into one class. Inevitably, someone starts moving things around just to feel better about the line count, but this doesn't make any real difference to the overall structure of the code. How can we reify actions on an object and simplify our classes?
In this talk I'll speak about using the concept of "middleware" (in the way Rack uses "middleware") as a general purpose abstraction for improving the organization, testability, and maintainability of complex pieces of code. I'll talk about my first hand experience of using middleware to power Vagrant (http://vagrantup.com), and we'll use these ideas to simplify an existing application.
MiniTest is a full-featured testing framework for Ruby that ships with the standard library in Ruby 1.9. Unlike some of the more well-known incumbents in the Ruby testing world, the MiniTest library is blazing fast and incredibly concise. It can be used for writing unit tests, BDD-style expectations, mocks, and benchmarks. Become familiar with MiniTest, and you'll gain a valuable tool you can use to improve any Ruby project you'll ever work on.
All Ruby projects start small and begin to grow. Where, exactly, do they go wrong? Is it when they begin to rely on 3rd-party services? When the tests get slow? When the framework falls behind by a major version?
When your project gets unmanageable you stop having fun. Let's talk about the actual metrics you can use to track when your project is starting to fall apart and what you can do about it. We'll cover cyclic complexity in code, test suite refactoring, project size awareness, naming and organizing conventions, gem extraction, and how to split projects in half.
Business Intelligence: it's not just a buzz word for the enterprise! The modelling requirements for business analysis are at the opposite end of the spectrum to those of a transactional system (your website), yet all too often they are muddled together in a solution that serves neither purpose well. Learn the basics of dimensional modelling, how to apply and build them in a typical Ruby environment, and get an inside look at how it fits in to the bigger picture of the analytics platform at Square.
Ruby is a fantastic language, largely because it pays attention to the Little Things. Details matter! Here you'll hear about some of the littlest things that make Ruby big, and you'll learn about why they matter. Whether you're an experienced Rubyist or a newcomer, you'll come away with a greater appreciation for the language, and hopefully put a few more tools in your toolbelt.
Rails did a lot to bring REST to developers, but its conception leaves the REST devotee feeling a bit empty. "Where's the hypermedia?" she says. "REST isn't RPC," he may cry. "WTF??!?!" you may think. "I have it right there! resources :posts ! What more is there? RPC? Huh?"
In this talk, Steve will explain how to design your APIs so that they truly embrace the web and HTTP. Just as there's an impedance mismatch between our databases, our ORMs, and our models, there's an equal mismatch between our applications, our APIs, and our clients. Pros and cons of this approach will be discussed, as well as why we aren't building things this way yet.
When you write code, how long is it before that code makes it to production? Days? Weeks? Months? LONGER?!?! Deploying code to production multiple times a day as automatically as possible will make all your dreams of green grassy meadows filled with rainbows and prancing unicorns and ponies come true. Or at least one or two of them.
Everyone has *heard* about SOA. If you've come from Java, you were probably forced to do SOA at a past job. But what does it mean to actually do SOA in Rails apps? What does it afford? What are some common patterns and implementations? And most of all, what works and what doesn't?
At Goldstar, our small team has been slowly breaking up our monolithic Rails and Perl legacy application into small apps that handle just one part of our business at a time. We love it. Our small apps are self contained, have crazy fast test suites (without parlor tricks) and it's made our mean time to delivery faster than ever. I'll tell you what has worked, what hasn't, and some patterns that have made the job easier.
Free online educational resources like Kahn Academy, the Stanford online CS classes, and the MITx program have gotten a lot of attention lately, even outside the education technology nerd circles. These programs are changing how educational content is created and consumed online. It's a great time to catch this wave and create your own educational tools, games, and content; regardless of the scale or whether it's free for everyone, meant for specific K-12/Higher Ed curriculum, or for corporate training.
This talk will show you how to use current standards and protocols in your Ruby applications that make them available as educational resources. You'll see how your apps would be used in the context of a traditional K-12 or college course, and I will demo some cool implementations like interacting with Khan Academy.
Schemaless database are a joy to use because they make it easy to iterate on your app, especially early on. The relational model isn't always the best fit for evolving and messy data in the real world. And let's be honest—it's painful to persist rich domain models across millions of little tables. However as your data model stabilizes, the lack of well-defined schemas becomes painful. On the other hand, relational databases are proven, robust, and powerful. How are we supposed to pick one or the other? Simple: pick both.
Devops is a buzzword, but in reduction it means putting the people who are responsible for new features in charge of getting them out there. At Pivotal Labs we work with 30 startups at a time, and have seen what works well and what makes developers cringe and slows down progress. I'd like to convince every developer to start running the sites they work on, embrace change throughout their infrastructure, and give some tips for how to do it along the way.
All too often programmers get into a productive rhythm where they receive their requirements, write tests aligned to those requirements, and then look for the green and red. While this process is proven to be highly effective, it can lead to developers missing the mark, as they aim for functional completeness and not the polish that an end user requires.
We should start proposing breakpoints for developers to step away from their automated tests, and play with the features they are working on. It's too easy for developers to get caught up in their process and forget about the end user experience. In this presentation you will learn several techniques for developing for the user experience, even when you're buried in code.
On some teams pairing is the norm; developers enjoy the collaboration & experience enhanced productivity. Others, though, work on teams where pairing is shunned, avoided, or just faked. Why do some craftsmen thrive with pairing while others want nothing to do with it? Why does coach- enforced pairing turn into something dry, distracted, imbalanced & ineffective? Effective pairing can increase creativity, energy, speed & quality. What factors make that possible? Learn how to take action on your team to put an end to soul-sucking, miserable, fake pair programming, and begin teaching your team to collaborate effectively on code.
Everyone draws inspiration and motivation from different sources.
For most, it's often frustration.
We make life decisions, define new features, or refactor code when we get too annoyed by current circumstances. This is where I admit that I have a low tolerance for frustration. Having been frustrated a great deal during my career, I'm going to discuss several anti-patterns that I've seen in code and how to use the Dark Side of the Force (frustration, anger, and rage) to escape from them.