RubyNation 2010 schedule

Unscheduled

Yehuda Katz has done some great Ruby refactoring for Rails 3 over the past year, but do you really understand what he's done? In this talk, Gregg Pollack will attempt to examine Yehuda's work, identify and deconstruct each programming technique that he's applied, and then teach them in a way that everyone can understand.

"Startups don't fail because they lack a product; they fail because they lack customers and a proven financial model." So says Steve Blank, entrepreneur, Stanford professor, and author of the excellent "Four Steps to the Epiphany". And he's right: if you look at the startup graveyard, you'll find it cluttered with lots of great products that no one would pay for.

As a developer this is a pretty discouraging realization. As makers, our skills center around creating a product, not around finding a market. So how do we take our maker skills and apply them to what Steve calls the "Customer Development Process"? That's exactly what this talk will explore, including a crash course in Customer Development and a roadmap any developer can follow to make sure they're building a product that is actually viable.

If you have an entrepreneurial bone in your body you won't want to miss it!

Continuous integration is a great way to keep your code base clean and well tested, but if the suite takes too long to run developers lose their constant feedback loop. We'll explore methods of speeding up your test suite from cheap 5-minute operating system tweaks to external tools that will run your tests on multiple cores and servers. You won't believe how fast we run our tests.

Michael Jordan will never be an effective NBA coach. He was the greatest player ever, but being great at something is a fundamentally different skill set than being able to coach others to greatness.

The Ruby community moves too quickly for any of us to be an expert in everything. We all need to be both teachers and learners, coaches and players.

Being a great programmer won't make you a great coach. As programmers and managers, you can multiply your impact by raising the game of those around you. Like basketball, there are just a few techniques that you need to be great - then it takes practice. In this session we'll crunch years of education study and practice into three principles you can deploy tomorrow.

In this session we'll explore each concept then work through examples applying them to the typical development shop. Attendees will leave with the understanding and framework to be great teachers.

A document database like MongoDB seems like a great idea. But when it comes to building an application, we may start to miss all those patterns familiar to us from relational databases. Where are my joins? How do I handle polymorphic associations? Here, we'll examine a dozen ideas for working the MongoDB way, including plenty of code examples. These techniques will highlight the unique features of the database, among them atomic updates, map/reduce, and the notion of embedded documents. We'll also consider the hard questions, including how to achieve durability, plan for scale, and reassure our relational-database-oriented brethren of the viability of a document database like MongoDB. You'll come away with a good sense for the surprises and joys of building apps in MongoDB.

There's a lot of Rails 2.x series code floating around. This talk is a practical walkthrough of how to upgrade an app to the upcoming Rails 3 release, as well as a look at some of the new features that can be used to improve existing codebases.

While others have been debating whether Rails can scale to enterprise levels, Neal Ford has been demonstrating it. His company, ThoughtWorks, is running one of the largest Rails projects in the world, for an Enterprise. This talk discusses tactics, techniques, best practices, and other things Neil has learned from scaling rails development. He discusses infrastructure, testing, messaging, optimization, performance, and the results of lots of lessons learned, including killer rock-scissors-paper tricks to help you avoid babysitting the view tests!

Most people know that Rails is the original productive web application framework that all the others copied, and most know that it has been runnable on the Java Virtual Machine for years via JRuby. What a lot of people don't know is how to properly integrate Rails and Java; that is, how to incrementally introduce Rails into your legacy Java environment and leverage its strengths without ditching your Java infrastructure.

Finally, all the pieces are in place to make Rails development and deployment in a polyglot Java environment possible. Rails 3 brings all the goodness of Rails in bite-size, composable chunks. Ant and Maven are becoming more Ruby- and Rake-savvy, so you don't have to give up your build infrastructure. Multiple database possibilities await, so you don't necessarily have to switch to ActiveRecord. Use Ruby and Rails where it hurts the most to give your project more flexibility!

In this session Nick will make recommendations on some of the best ways to making Rails and Java play nicely together using JRuby, and run through some demos of the more practical ways to get things done. Most exciting, you'll get a preview of the quickly-evolving JRuby on Rails stack.

The 5 SOLID design principles (the Single Responsibility Principle, the Open/Closed Principle, the Liskov Substitution Principle, the Interface Segregation Principle and the Dependency Inversion Principle) form a great foundation for understanding good Object Oriented design. But the SOLID principles were originally conceived with statically typed OO languages, such as C++ and Java, in mind. How well do these principles hold up when the implementation language is Ruby? Are the principles just as pertinent as they were in Java, or does the dynamic nature of Ruby change what we mean by good design? In this presentation we will examine the SOLID principles to understand their core purpose, and then run them through the "Ruby Filter" to see if any of these core principles survive. By understanding these principles, we become better Ruby programmers.