Sessions at RubyConf 2011 on Friday 30th September

Learning how to be a well versed and competent developer is a life long process, but it must begin somewhere.

One of the toughest parts about starting a career as a developer is the massive technology stack involved in pushing anything out to the real world. Similar to learning physics, chemistry, or biology for the first time, there is a whole language you need to learn before you can achieve any sort of mastery.

With Limelight, you can teach the fundamental principles of becoming a Software Craftsman while only using Ruby!

We will first explore Limelight as an educational tool, and then get our hands on our keyboards and work through an example Limelight Lesson. We will actually be writing some code!

If you have JRuby on your machine, Limelight will do the rest of the setup.

Diaspora is the crowd-funded open-source decentralized social network built on Rails. Full buzzword compliance: on by default. We have many thousands of active users and they generate a lot of social data. But after nine months of full-time development with MongoDB as our primary storage engine, a few months ago we converted it all to MySQL.

Wait...what? Most people are going the other way, dropping Mongo into a project in place of MySQL or PostgreSQL. Plus, conventional wisdom says that social data is ill-suited to a traditional data store.

Come hear a story about a large-scale Rails project that tried it both ways. You'll see crisis and redemption, facts and figures, nerds, kittens, ponycorns, and, of course, the secret sauce.

Hecklers will be piped to /dev/null.

The Ruby community has driven a lot of technical innovation in deployment and configuration management over the last few years, and so the idea of delivering high-quality software rapidly should be familiar to many of us. But although many of our tools are state-of-the-art, our practices could stand a bit of scrutiny. Your friendly neighborhood server admin probably isn't thrilled with running RVM or compiling gems in production, and your nervous project manager is asking why deploying constantly is such a great idea anyway. Won't you just stop coding for, like, five minutes and click around the app for a bit, just to make them feel better?

In this talk, the maintainers of two competing continuous integration servers at two competing shops lead you on a Socratic tour of the past, present, and future of continuous delivery as seen through an Agile Ruby lens. We'll talk about the changing deployment toolchain, the difficulty of evolving code as it's deployed, and how to coach your developers, testers, and client to be "production-ready, any time."

What does really happen when we call a method? How do the different Ruby implementations actually figure out what code to execute? What plumbing is going on under the hood to get a speedy dispatch? In this talk we will have a look at the internals of the four major Ruby implementations - 1.8, 1.9, JRuby and Rubinius, focusing on their dispatch. From look-up tables and call site caches, to inlining and what on earth is invokedynamic? Expect C, C++, Java, and, of course, Ruby code. But fear not, all will be explained!

Ruby code creating services for it to then consume aka Service Metaprogramming

A very large number of Ruby apps are deployed in hosted environments. Many of these hosted environments offer both internal and external services with APIs that your Ruby app can consume. The problem is that the use of these services often requires provisioning tasks for each service and the service must always be there or the app will fail.

This session will show Metaprogramming Ruby code and a RubyGem for provisioning/de-provisioning, binding/unbinding, sharing configuration state, and more. This allows your application to create a Redis or MySQL instance only if needed (say on initial startup) or bind to a specific service, but only if/when it is present. This approach eliminates many of the forgotten steps during deployments and makes it easier to understand what your Ruby code really depends on because it is all encapsulated in the application’s code itself!

It's been two years since _why the lucky stiff has departed Ruby. His work, however, carries on. Shoes was one of _why's most ambitious projects, and a tiny but scrappy team has kept Shoes alive.

If you haven't heard of Shoes, it's a GUI toolkit for Ruby. Most of these are simply bindings to toolkits written in other languages, like QT or Tk. Shoes is native to Ruby, so it uses Ruby-only features heavily, such as blocks. Shoes also includes packaging functionality that allows you to distribute your apps on Linux, OSX, and Windows.

In this talk, Steve will cover the basics of building applications with Shoes, the challenges of maintaining a large polyglot project with an absent inventor, and what's in store for the future of Shoes.

JRuby is a top-notch Ruby implementation. It’s also your gateway to polyglot heaven. Ruby can do anything, but it’s not always the best tool for the job. With JRuby, you can take advantage of other JVM languages. Build part of your application in Clojure, taking advantage of its immutability and transactional guarantees. Build another part in Scala, leveraging its flexible static type system and actor libraries like Akka. Use JavaScript via Rhino to test pages or run JS on the server alongside Rails. Use Mirah to build fast-as-Java algorithms in a Rubilicious syntax. The JVM is a haven for polyglots, and JRuby’s your ticket to ride.

We will start with an overview of what exists today (Ruby 1.9.3) in Ruby's OpenSSL wrapper and how and where you can use it and why you should. After this brief introduction we will encounter new features that could find their way into future versions of Ruby OpenSSL.

Among these is OpenSSL::ASN1::Template, a DSL that allows parsing/encoding ASN.1 structures with simple declarations that look similar to ASN.1 itself. We will find out why I finally decided to ditch a working implementation in pure Ruby just to replace its majority with C code - including the lessons learned about performance.
Another feature would be XML signature support (OpenSSL meets Nokogiri) and a clean solution to finally stop people from using OpenSSL::SSL::VERIFY_NONE by making certificate validation less of a pain while still improving the security.

Finally I'd like to revive a concept that never really found broad acceptance although it would largely increase the trustworthiness of our beloved gems - *digitally signed* gems.

Ruby has demonstrated itself to be an extraordinary tool for the rapid development of prototype systems in an environment of unclear, undefined, ill-defined, missing requirements. As a dynamic language its ability to rapidly morph based upon the needs of the moment is remarkable. The way that it can be used to hide complexity via domain specific languages is unparalleled.

This session reviews 5 years of success using Ruby within a research and development lab of a major USA defence contractor. Lessons learned, evolved patterns and suggestions for future improvements are on the agenda.

There are movies. Bring your own popcorn.

I have completed a second major release of a library that fully conjugates Classical Latin verbs in each of their 133 froms * 5 standard paradigms.

Owing to the irregularity of human communication, modeling the provision of unambiguous answers (return values) to ambiguously asked things (flexible / incomplete method calls) might have required hundreds, if not thousands, of method definitions or static values entered in a database.

But what if heuristics could be given to a Ruby class such that it "thought" as language learners are taught to think? What if it could be taught to be flexible in respecting the ambiguous calls given and to still give precise, correct answers back - as human language learners are capable of doing? By adopting this design paradigm code could become leaner and more reflective of human cognitive process.

Thankfully for Rubyists, this is not a dream, this is reality. Our programs can operate more intelligently, more heuristically, and more insightfully. We can save ourselves days of development time by integrating the next tier of metaprogramming patterns I seek to demonstrate. This is perhaps what makes Ruby so unique, so mysterious, so enticing and so special.

MacRuby is an implementation of Ruby 1.9 that is directly on top of Mac OS X core technologies. Recently, MacRuby has become viable as a tool for developing useful desktop applications for Mac OS X.

However, as of March 2011, MacRuby is still missing some functionality that is present in cRuby. Therefore, MacRuby is not able to run Ruby on Rails.

In my presentation, I will explain how I modified MacRuby to make it a suitable foundation for running Rails. I would also like to explain some of technical intricacies that I discovered along the way.

An examination of a large handful of features and characteristics of Ruby that, once understood, provide a solid foundation for continued learning and/or mentoring

Fancy is a self-hosted, dynamic, class based, pure object-oriented programming language heavily inspired by Smalltalk, Ruby and Erlang that runs on the Rubinius VM.
It has first class integration with Ruby, support for asynchronous message sends, futures and actors, a simple syntax and consistent semantics, object oriented pattern matching that preserves encapsulation and much more.

Fancy runs on Rubinius, a modern bytecode virtual machine designed for Ruby. It is the first fully self-hosted language running on Rubinius besides Ruby.

This talk will show Fancy’s semantics and language features, its integration with Ruby code, as well as how the new implementation for the Rubinius VM works and what Rubinius has to offer for programming language creators alike.

Maybe, Ruby 1.9.3 will have been released at the time of RubyConf2011. In this talk, I will introduce the news about this latest release. This is not a language features, but a implementation features. I will also introduce other developing features which can not implement on 1.9.3 in time. Moreover, I will introduce our research activities such as real-time profiler, pragmatic compilers and our approach to introduce parallel execution into Ruby - MVM.

Ruby (MRI) has an unit-testing library, 'test/unit'. This is used for ruby's `make test-all`. In February 2011, I committed a patch ("parallel_test") that allows us to run multiple Test::Unit::TestCase-s at the same time.

Because of this patch, ruby's `make test-all` can run tests faster. This patch also affects to existing tests using `test/unit`.

In this talk, I take you into the parallel testing world. We'll talk about general parallel testing, benefits of parallel testing, multi-threaded or multi-process, etc. Then talk about the patch, the story of making the patch and describe how the patch works.

Rubyists love testing, and test-driven-development is becoming THE way to write code. But, do we do this with our command-line tools? How DO you write a test that your awesome application cleans up its temp files? How does one make a failing test for a missing command-line option? What's the easiest way to check our app's exit codes? This talk will answer these questions with some real-world examples. We'll talk briefly about the challenges particular to testing command-line apps, and then dive into some code where we'll show off techniques for organizing code for testability, tools for interacting with the filesystem, and how to create full-blown acceptance tests for your command-line app. In no time, you'll be able to write your command-line apps the same way you write your other code: test-first.

Forget about JRuby. MacRuby? Forget it. Forget even Rubinius. As cool as each of them is, they are old. Like, you know, for adults. Introducing the real future of Ruby: KidsRuby... because the future is about the kids! http://kidsruby.com

KidsRuby was born as a fresh approach to the most important problem we as an industry face: who is going to maintain our code in its old age? Most of us in the Ruby community are aware that it is a great time to be a programmer. However, it's not so great to be some company trying to find an experienced programmer to hire. And the problem is only going to get worse, since the state of computer programming education is the US and UK is down, even as demand increases. Like becoming a master musician, master programmers are not created quickly. Many of the best programmers today started when they were young. There have been a number of excellent contributions for teaching kids to program using Ruby. The most famous Ruby environment for kids being Hackety-Hack, from _why the lucky stiff. However Hackety-Hack is showing its age and inherent limitations, especially if you want to use it with any normal gems, or want to contribute to it. Even the 1.0 release suffers from these problems. KidsRuby is a real Ruby, so that kids are not treated like second class citizens just because they are learning Ruby. It helps to solve a number of the biggest technical problems with teaching Ruby to kids. In 30 minutes I will share not just the technology used to build KidsRuby, but more importantly the social glue needed to help start out the next generation of programmers with the language we all love.

It it time for a general call to arms to the Ruby community. We all need to get serious now about training the next generation of hackers. After all, think of the children!

Why do some people keep talking about diversity? Who cares if we're all the same? So long as we're not technically discriminating against anyone, that means we're good, right? If we only get applications from white dudes, that must mean that white dudes are the only ones out there. Right? Right?

When we feel threatened, we find comfort among people who seem most like us. As specialization increases in the community, we glom on to people who look like us, talk like us, and think like us. There's safety in a crowd.

But there are real dangers in becoming too much alike: monotony breeds more monotony. Real innovation happens when you think different than everyone else. What happens when we ruthlessly eliminate different thinkers, as we winnow the stack of resumés to those that seem most likely to "fit in"?

Come to this talk to find out what you can do to diversify - yourself, your organization, and your peers - and how you can help grow a better, stronger, more diverse community.

Ruby, the beautiful, malleable language with a lovely object model and great reflection capabilities... and almost zero tools. If I had a coin for every time some Smalltalker gloated about the Smalltalk class browser or some bloke bragged about the Java refactoring tools, I could start my own bitcoin.

Building great tools for Ruby requires great support for Ruby itself. The problem is, there is often a giant molten blob of C or Java code in the Ruby implementation with a thin veneer of "Ruby" method bindings. Rather than supporting great Ruby tools, that effectively prevents building them. How does one browse core library classes like Array when the code is not even Ruby?

Rubinius addresses this situation on two levels. Firstly, the Rubinius core library is written primarily in Ruby. Curious what that Array#[] method does? Just pull up the Ruby code and take a look. Rubinius also creates first-class Ruby objects for Ruby infrastructure. When a method is defined, there is actually an object, CompiledMethod, that you can lay your hands on, inspect, and manipulate like any other Ruby object. Secondly, Rubinius builds essential tools into the virtual machine. There is a built-in debugger, profiler, and also stats for the garbage collector. Further, Rubinius has a facility, named Agent, for querying and controlling the virtual machine.

Nikita is a top-secret project to create a set of simple, integrated applications that use the Rubinius facilities to build tools for Ruby. The interface is a Sproutcore application, which enables using the tools remotely, for example, to monitor servers.

In this talk, we'll look at the Rubinius features that support writing tools for Ruby and examine how those features are used in Nikita. Then we'll set Nikita loose on some problem code. It might get bloody.

Minecraft is the indy gaming sensation which appears to be growing about 1 million users every six months. Minecraft presents a blocky (voxel) world in which you and rip down and build up the world as you see fit. People make buildings, fight monsters, farm, and dig expansive tunnels down to the bottom of the world. A deceptively simple and addictive game.

One Minecraft feature of interest to programmers is that users can run their own multiplayer servers with the freedom to apply modding frameworks that tweak the rules of the game. The Minecraft makers are happy with the extensive Minecraft modding community. Purugin (https://github.com/enebo/purugin) is a Ruby-based framework written on top of the CraftBukkit mod framework which allows programmers to easily extend Minecraft. Want your own teleportation system? Want to control the weather? Want special physics for particular type of block? Purugin is there to make Minecraft be the game you want it to be...

This talk will give a brief demo of Minecraft and then dig into the Purugin system. You will learn how to make your first plugin and then learn the boundaries of where minecraft modding can go. Guaranteed fun for the whole Ruby family...

Nobody said it was going to be easy, but documentation is an important part of making your libraries and tools usable by others. Without good documentation, your users will have a hard time adopting your code. But what is "good documentation", anyway?

This talk will outline what is important to communicate in our documentation, how we should write it, and what makes documentation "good". We will look at some common pitfalls we come across when documenting libraries and frameworks, and how we can use tools like YARD to make it easier to document code. We will see how writing documentation should really not be an afterthought, but an important part of the entire coding process, and how it can be used to validate the design of your library or framework as you write it. Ultimately, this talk will show you how documentation can inform your development process and lead to stable working APIs from the get-go rather than simply leaving your documentation to the end.

We're using Float values anywhere in our Ruby scripts.

Have you gotten any troubles with Float?

Have you read the article "What Every Computer Scientist Should Know About Floating-Point Arithmetic"?

Have you been scolded about issues of floating-point numbers from Ruby committers in redmine.ruby-lang.org ?

I'm afraid if you think it's difficult to use floating-point numbers.

These troubles, difficulties, and tragedies should be removed from Ruby and its communities.

I show you the way to solve these issues.

Over the past 5-6 years we have seen a lot of changes in the way that Ruby apps speak HTTP -- from Rails' "REST" conventions, to the brilliantly simple Sinatra, to the modular Rack abstraction -- but we haven't yet unlocked the entire subtle power of HTTP. We know HTTP is so much more than verbs and URLs that correspond to CRUD, and yet it's still too hard to do conditional requests, content negotiation, and then return the right type of response.

What if, instead of forcing HTTP into our MVC-shaped applications, we shaped our applications like HTTP? Instead of forcing a resource into seven controller actions or verb/URL-specific methods, what if the resource itself was the abstraction? A whole world of subtle and powerful programming patterns emerge.

This is the world of Webmachine, a toolkit for building HTTP applications and a port of the Erlang toolkit of the same name. I will introduce Webmachine's unique programming model and demonstrate how to easily expose rich HTTP behavior in a few short lines of Ruby code.

Mocks have an a bad rap lately. We've all seen brittle and unreadable test code riddled with 'should_receive' and 'mock_model', leading to classes people don't dare to touch. RSpec has now taken "mock_model" out of their default scaffolding for Rails controllers, and is preferring real objects. Does this mean that the concept of interaction testing is flawed?

Well designed code is easy to test, and mocks enhance your sense of smell. State-based testing will lie to you and hide your bad code for longer, but your interaction tests explode if you don't keep your code clean and your object collaborators few. That's as it should be.

Come to this talk if you want to hear a robust defence of mocks as a testing tool, see some examples of ruby code exhibiting the dangers of a reliance on state-based testing, and hear how you can use mocks to heighten your sense of smell, decrease coupling and increase cohesion.