No one can argue that the software development industry has changed drastically in the last 10 years. No one can argue that it will continue to change.

This is a call to arms. We know that the education system is broken for software developers. We complain about it. It is not the school's problem, this is ours. It's time we do something about it.

This talk is an action plan. This is not a wish list. This is a way for companies to train their teams to lead, not follow. The plan lays out how to deal with turnover, existing skill sets and skills coming out of college. Borrowing lessons from each other consulting and product companies will both benefit.

In the end, you will create another competitive advantage.

TorqueBox is a true Application Server for Rack based applications. It's built on the world-class JBoss AS7, provides asynchronous processing, messaging, scheduled jobs, daemons, and caching that all share the same lifecycle as your application. Now you never have to manage memcached, restart a Delayed::Worker pool, or edit your crontab again. With TorqueBox, it's all in the tin.

Built with Rubyists in mind, TorqueBox gives you true speed, strength and scalability while staying out of your way. Plus, it uses JRuby, one of the fastest ruby interpreters available today. Come find out what it is, and how it can make your life perfect.

The Ruby community is obsessed with testing, supposedly. In my experience about four out of five applications have either zero or completely ineffective test coverage.

Have the courage to change it. Whether your own projects or recovering someone else's mess, let's talk strategy:

• Starting with metrics
• Refactoring for understanding
• Comment-driven development
• The unit testing foundation
• Bug reports are your best integration tests
• Focusing on value

Rescue projects are popping up everywhere, and a strategic testing approach can save the day.

Learning Clojure and absorbing the wealth of ideas about functional programming that it's built on has made me a better programmer. I bring those ideas with me wherever I go, and most often, that is to Ruby.

In my quest to program functionally in Ruby, I've uncovered many of what Matz once called "Easter egg for functional programming kids." Ruby's most influential ancestor is Smalltalk, but it's also full of ideas from Lisp and other functional languages like Haskell.

Using these easter eggs in your code is not generally idiomatic Ruby, and it can be difficult to find examples of their usage. But, combined with a notion of what "functional programming" and "programming with values" means, these provided tools can improve your code and expand your mind.

Learning is hard. But if you're like me, your biggest obstacle is yourself. It took a long time to realize how important it was just to "do it" and not spend so much time trying to "do it right."

Clean code is important. Efficient code is important. Using your chosen language/framework/system as it is intended to be used is important. But none of those things are important when you still don't know what they mean.

My talk focuses on getting your hands dirty and not being afraid to be wrong. I show how making mistakes and disregarding the advice of more experienced programmers helps you gain a deeper understanding of your domain. Of course, context is important, but having a safe place to express yourself and fail miserably without serious consequences is essential to healthy and progressive improvement. Above all, it is important to start from where you are, rather than to attempt to start from where you think you should be.

Vagrant is awesome. Awesome enough to make me actually use local VMs for testing. That's a pretty high level of awesomeness. But, with great awesome comes great responsibility. I had no choice but to sit down and write Vagabond.

Vagabond is a testing library for servers - as long as you can SSH into them, you can test 'em. With Vagabond, you're able to do BDD for our configuration management (chef, puppet, etc.). After all, your configuration management IS code - you should test it like code!

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.

Pakyow is a new web-app framework for Ruby that is planned for open-source release the summer of 2011. There are several advantages to this framework, perhaps the biggest advantage being it's approach to the front-end.

In Pakyow, views are 100% HTML; no template language, no special tags. This allows a front-end developer to built a functional prototype of an application without writing any business logic. A backend developer can then add the business layer (including view logic) without modifying the views. How does it work? Magic.

This talk will explain Pakyow's unique approach and demonstrate core concepts with working code examples. A few minutes of the talk will be used for explaining the theory of view/view logic separation and the advantages this has for a development team.

Fractals have two (well, more, but I only care about two right now) interesting properties. First, they look similar at every level of granularity. Second, they're generally the result of a simple definition. In this talk, I show how those two features can also make for better software design.

We're all familiar with various principles for designing low-level units like methods and classes (SOLID, for instance). When you apply similar principles to larger units -- all the way up to systems of interacting applications -- you get great software. Just like fractals, these systems look similar at every level, and they're built on a single set of underlying, simple ideas.

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.