As developers, we want to minimize the time we spend fighting with our development environment. The less time we spend dealing with configuration issues, the more time we can spend doing what we do best... creating awesome apps! I show how you can easily set up a development environment that is both flexible and powerful. But best of all, it wonâ€™t need regular attention!
There are many strange beasts in the Ruby language. Some of them you might never have seen. Others you might have seen but not understood.
Ruby is a big language, and this presentation will show you some of the corners of Ruby that you might not have known about, or even dared think would exist in a modern language. Some of these features are useful, some of them are useless and some of them are just downright puzzling. Come here to get a tasting of the weirder parts of Ruby.
The sweeping changes brought on by Rails 3 and 3.1 havenâ€™t just make our existing development patterns easier, they have opened up the ability for us to build new patterns that accomplish more in a more beautiful and efficient way. In this session you will see how thinking about new features in a different light can lead to real innovation for your development practices. Examples include baking routing constraints into your models, application composition with Rack, truly modular design with the asset pipeline, and more.
If youâ€™re writing code that looks like User.all.reject(), youâ€™re doing it wrong. Donâ€™t worry though, weâ€™ve all done it before. ActiveRecord makes it all too easy to introduce code that is far from performant, and after awhile, we tend to forget that underneath the pretty API, weâ€™re still producing SQL. In this talk, weâ€™ll peel back the API so that we can see some of the common mistakes I see when dealing with ActiveRecord statements, and more importantly, how you can fix them.
Live podcast recording for Ruby Rogues!
Build features fast. Ship them. That's what we try to do at GitHub. Our process is the anti-process: what's the minimum overhead we can put up with to keep our code quality high, all while building features *as quickly as possible*? It's not just features, either: faster development means happier developers.
This talk will dive into how GitHub uses GitHub: we'll look at some of our actual Pull Requests, the internal apps we build on our own API, how we plan new features, our Git branching strategies, and lots of tricks we use to get everyone â€” developers, designers, and everyone else â€” involved with new code. We think it's a great way to work, and we think it'll work in your company, too.
Everybody wants to do test-driven development, but switching to TDD or BDD on an existing project that doesn't have tests presents special challenges. Often, the current code is a tangled mess of dependencies that defeats the very concept of unit testing. Worse, if somebody has attempted TDD in the past, you might have a test suite that needs to be fixed before any new tests can be written.
Don't give up. Adding test-coverage and TDD to your application will make it easier.
This session will describe techniques that you can use to bootstrap a test-driven process into your project. You'll see how to use "black-box" techniques that don't depend on the structure of the code and "white-box" techniques that interact with the code more directly.
Topics covered will include:
* Using Cucumber to perform black-box testing.
* Using RSpec to perform white-box testing
Rails has been around for seven years now, which means there's been more than enough time for us to build huge, monolithic apps that do way too much. It's no surprise, then, that we've started to see a surge of interest in the decomposing large apps into a set of smaller, interrelated services.
In this talk, I'll show just how to go about decomposing one app into these sorts of services -- from identifying splittable functionality, to extracting it, and to integrating the service back into the main app.
On some teams, pairing is the norm, and some developers really enjoy the collaboration, experiencing enhanced productivity.Others work on teams where pairing is shunned, avoided, or... faked.
I have been on a quest to discover, on the one hand, why some who call themselves craftsmen love pairing, and others want nothing to do with it. I did a short survey about pairing attitudes, and comparing successful and unsuccessful pairing experiences.
The survey produced some really clear results. Some factors most of us think are really important to a good pairing session turned out to be... meh. Other factors, though, stood out, hands down, as clearly separating good from bad pairing experiences.
I'd like to talk about these survey results, and have an honest discussion about why pairing sucks or doesn't suck, and how we can bring the two sides together.
We are known for our community. Does this mean our job is done? Are we starting to stagnate? Simply gathering Rubyists together isn't enough. How are you improving your community? Fear not as anyone of you can take action. Whether you live in a place with no organized Ruby meet-ups or you're contemplating a big regional event, we will go over why you should take action and give you practical steps to do so. We'll also bring light to not just increasing membership counts but actively making everyone better. Innovation is happening out there that we'll go over in detail. Join us, learn and get involved -- we're building something awesome!
Robert C. Martin (Uncle Bob) has been a software professional since 1970. In the last 40 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, C++ Programming and Clean Code. He has published dozens of articles in various trade journals. Today, he is one of the software industry's leading authorities on Agile software development and is a regular speaker at international conferences and trade shows. He is a former editor of the C++ Report and writes regular blogs at http://cleancoder.posterous.com/.
You are happily writing new code for your system when all of a sudden the code is not behaving the way you thought it should. Perhaps you just created a failing test, and the code you wrote was expected to make the test pass ... but it doesn't. What's the first thing you do?
Some Rubyists will drop some "puts" statements into the code. Some will add a raise statement. And still others will depend on logging to trace the internals of the code. But a surprisingly few Rubyists will reach for the Ruby debugger.
Despite a general disdain for the debugger in the Ruby community, the Ruby debugger is a powerful tool that can quickly get to the heart of a coding problem. This talk will concentrate on getting Rubyists up to speed on the debugger, how to use it effectively and learning other general debugging tips.
This talk will dive into the details of OpenShift Express and it's support for Ruby and Rack. It will also cover how we are using Ruby internally on our development of OpenShift. This session will not only walk you through how to use OpenShift to deploy a Rails 3 application, but will also dive into why we standardized on Ruby as our development language. I'll cover the following topics at a hands-on level:
Deploying a Rails 3 application with the OpenShift Express
Cover how we are using Selenium WebDriver and the Ruby bindings for automated testing on headless machines
Cover how we are using Apache Qpid (AMQP), the Ruby bindings and MCollective as the basis of our scale-out architecture
Tired of maintaining your one-off script that has now become someone's job to execute? Wishing you could create polished applications on the command line similar to git or cucumber? In my talk, I'll talk about what makes a command line application "awesome", and why you should care. I'll talk about what makes Ruby particularly suited to this task over mainstays like bash and Perl. We'll compare and contrast several Ruby libraries that can make even your lowliest automation script a polished, maintainable, and predictable application.
Are your methods timid? Do they constantly second-guess themselves, checking for nil values, errors, and unexpected input?
Even the cleanest Ruby codebases can become littered over time with nil checks, error handling, and other interruptions which steal attention away from the essential purpose of the code. This talk will discuss strategies for writing your Ruby classes and methods in a confident, straightforward style; without sacrificing functionality or robustness. In the process, we'll cover concepts and techniques points including:
The narrative style of method construction
The four parts of a method
Three strategies for dealing with uncertain input
Massaging input with coercion and the Decorator pattern
Exterminating nils from your code
The chaining and iterative styles of method construction
Eliminating conditionals with the Special Case and Null Object patterns
Isolating errors with the Bouncer and Checked Method patterns
Choosing a data storage engine is an important decision, but it doesnâ€™t have to be painful if you know the landscape. Weâ€™ll look at several DBMSs (and a few youâ€™ve never heard of), compare and contrast them based on use-cases, and how to plug each into Ruby.
Authoring the book "Seven Databases in Seven Weeks" has opened up a whole world of database alternatives that I never before seriously considered. Itâ€™s an important decision to be made by research, not buzzwords â€“ and weâ€™ve sifted through them so you donâ€™t have to. At the very least we can settle the Mongo v. Couch debate (hint: theyâ€™re both awesome).
This is not the same RailsConf talk. This is split into two parts:
The components of modern databases:
A 30,000 foot view of the current database ecosystem
Understanding why the CAP theorem is true
Understanding map/reduce from the Ruby perspective
12 databases in 12 minutes:
The similarities/differences of the most popular open source DBs today
When to use them, when to avoid them
Which Ruby drivers to use
Ever wonder how netflix can predict what rating you would give to a movie? How do recommendation engines get built?
Well, it's possible with JRuby and it's fairly straight forward. Many engines are built purely on support vector machine regressions which map arrays of data onto a classifier, like a star.
In this talk I'll explain how support vector machines are built, and how do make a simple movie prediction model all in JRuby.
We spend a large portion of our time thinking about code and technical project issues. What about the people side of things? The majority of project failures occur because of people, not technology. What we need are guides that help us navigate the waters between the people around us.
People Patterns introduces my latest effort to capture the subtleties and nuances of interpersonal relations. I'm distilling a lot of experience, a bit of psychology and a substantial amount of research and have come up with a series of patterns that can help everyone be more successful in teams and at work. How do you have those critical conversations? How do you get your point across when you think the other person is incompetent? Come and help me reveal these and join a lively discussion.
We are probably all familiar with the dreaded edge cases that creep up on our production code and sucker punch it with inputs we never expected. I bet most of us have scrambled to fix those at one time or another.
The good news is that you don't have to live in fear of edge cases. In fact, you can turn the tables and force them to work for you. That's a technique I have used quite successfully in my own programming for many years now. It can help you to have better conversations with your clients, design smarter code, choose better processing strategies, and even luck into the right algorithms.
In this talk, I'll explain how I use edge case thinking, explain what it can do for you, and show several examples of how it leads to better choices. You will learn how to stop "slurping" data (even with SQL), how to shed your fear of nil returns and how to avoid spreading that fear to others, how to think synchronously but still get an asynchronous advantage, and more.
I wanted to know, "Do I need to learn about EventMachine or node.js? Can I use threads? What is so good or bad about threading in Ruby 1.8, Ruby 1.9, JRuby and Rubinius 2.0?"
What was important to me
Did you know there are video games, both console and handheld, that talk directly to a Rails stack to provide functionality, both in-game and on the web? Did you know that there are Ruby/Rails services running 24/7/365 to process game data for over 40 million players around the world? You will learn about the code, methodologies and tools used to make all of this happen (and gain 5000 Rails XP)!