Sessions at Nordic Ruby 2011 on Saturday 18th June

You open Twitter. Five people say go left. Five say go right. You read a blog post saying this, but another says something else. "Whatever you think, think the opposite" is no longer good advice because everyone is scrambling to think in every direction, and they're all vying for your attention.

This is a talk about dealing with the daily noise we all face in our digital lives and carving out one's own path in the world.

Computers are being built with more and more CPUs and those CPUs in turn have several cores. Powerful calculations are now performed either on many-cored machines, or on distributed systems. In this context, it's in the developer's interest to start thinking about concurrent programming. But concurrent programming is tricky - one has to deal with race conditions, locks, anything to do with shared state. The last few years have shown that very few developers get this right when faced with conventional shared state threads.

One of the ways to simplify concurrent programming is the actor model. In the actor model, programs are made of actors sending each other messages, and acting on the messages they receive. The actors don't share any state, and communicate purely by messages.

In this talk I explore several ways to implement the actor model in Ruby.

The existing actor implementations in Ruby:

Rubinius actors

existing actor gems (cross Ruby implementations)

Actor implementations that are a little more 'out there':

An actor implementation using zeroMQ I'm working on.

bindings with the Akka framework in Scala with JRuby

bindings with erlang, the first mainstream implementation of the actor model

And their advantages and drawbacks, and (fun) code examples.

The talk will also allude to the fact that threads in Ruby should ideally have separate state, so that all programs using threads could also use the actor model (or other similar concurrency models).

Have a peek into the future. Ruby is now more popular than Java, even ACME uses it to write enterprise applications. But there's a new language in town. It's called Blub and all the cool kids are using it. They say that Blub is more powerful than Ruby, but exactly what does that mean? And shouldn't we just keep using Ruby?

Ruby won't be our first choice forever. As attendees of a Ruby conference, we have broad horizons already, but keeping it up requires constant work. This presentation will do the work for you. It will examine some core features in languages more powerful than Ruby. It will hurt your feelings, but it will also make you think about what evolution's next step might be like. In the end, it will make you less reluctant to getting your hands dirty with Blub when the time comes.

Unlike your modern apartment, your modern web app does not require a fancy view. In fact, HTML views are becoming less relevant in server side programming. With tools like sproutcore and backbone.js, we can conclude that our server side apps should be focusing on providing a robust APIs. In my talk I will cast my vision for what our modern (template-less) web apps will look like.

Since there has been great religious debates surrounding HAML & ERB, you can imagine that Rubyist will be very interested when I say that HAML &ERB are rubbish and they should use neither and render templates on the client.

When people think about working on Rails applications, they rarely think about refactoring legacy code. Let's look at what it means to deal with legacy code when talking about Ruby applications. We'll learn to deal with techniques for testing difficult code, maintaining API compatibility, and how to maintain your sanity. We will laugh, we will cry, but mostly we'll fix broken code!

"Legacy software". These two words evoke many feelings among developers, system administrators, and business people who rely on IT. Most of these feelings are negative. "Legacy" implies toil, trouble, expense, problems, burnout.

Is "legacy" a bad word? What does it mean to leave a legacy? Why don't we hope to do that in software development as we do in other fields? How might we work differently if we did?

Are you pushing yourself with the right force, in the right direction, to achieve what you want, what makes you happy, what you're capable of?

Based on her experience of training for Ironman distance triathlons, Keavy will discuss the preparation involved in pushing herself towards her own mental and physical limits, and the effects this has had on other areas of her work and life.

The talk will explore some attitudes and processes in the practice and performance of sport that are critical in reaching your full potential. It will look at how these approaches can also benefit the journey not just of personal development, but career development. It won't be about achieving some grand vision of mastery, but rather on pursuing outcomes that are true to the individual; on making informed, conscious decisions about what to focus your energy on; and maintaining the drive to get there.