Ruby is one of the best object-oriented languages around. Ubiquitous objects, duck-typing, mixins, expressive syntax with low ceremony, powerful reflection and metaprogramming. But Ruby has a mixed heritage that incorporates functional and procedural models along with OOP. This flexibility provides many options for how to solve problems, but it can also lead even experienced developers into a confusing mix of programming styles and hard-to-understand software designs. But what can we do to keep things simple and easy to understand?

Ever since I have learned the Ruby language, I thought I can use it to program virtually anything. Well, I was wrong and I’d like to share this sad story with all of you.

Ruby on Rails gives us M, V, C, routes and helpers. Some people add observers and concerns, among others. We’ve standardized on presenters. Service objects are gaining popularity. Uncle Bob wants you to add interactors, request models, response models and entities.

In object-oriented programming, there is a well-known anti-pattern called ‘Fear of Adding Classes’. It describes the fear of solving a problem by adding another class because of the (often wrongfully) perceived added complexity. With systems moving towards a distributed nature through the usage of external services, a similar pattern can be seen: the fear of adding dedicated components, mostly independent processes to the system, because of the fear of added management overhead through doing so.

Ruby is an industrial programming language. In the past eight years, tens of millions of dollars, if not more, have been invested in Ruby itself, and in frameworks and libraries for the language. Many times that have been invested in companies that have been built around Ruby.

Building software is a young discipline, but it already has a fascinating history. For a young rubyist, it’s easy to forget where we all come from, and why we do software the way we do today. Let a slightly-less-young rubyist tell you the story of software engineering: a story of big problems, brilliant solutions and miserable failures.

Ruby 2.0 is coming very soon. The specification is fixed, and the first stable release will be in production in several months. Now is the time to get prepared for 2.0. What new features are available in 2.0? How can our code, and lives be improved by these new features? Where are the examples? This session will detail some of the great improvements in Ruby 2.0.

Ruby 2.0 to be released in next February. Ruby 2.0 doesn’t have drastic changes in behavior except adding some new features. However, an internal of Ruby 2.0 Virtual Machine (VM) is changing to improve performance! For example, we changed VM data structures and method invocation processes to achieve fast execution. This presentation introduces the internal changes and its performance.

More and more applications are being written in dynamically typed languages like JavaScript and Ruby. Theoretically, this is progress. But, what happens when they go bad? What are the recovery options. This talk explores methods for making sense of, and recovering large legacy code bases in dynamically type languages. It concentrates on the differences between them and their statically-typed counterparts.

Whether you are using a statically typed or dynamically typed language, there is typically a rigid separation between writing code and running code. Smalltalk environments focused on running code where writing code was actually a function of the running program. However, this approach was usually implemented using a snapshot of a running process that makes sharing code and managing changes over time quite difficult.