Sessions at GoGaRuCo 2011 with slides on Friday 16th September

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.

Interfaces are not created equal. Upon reaching the summit of a releasable product it is easy to lose sight of where you started. The disconnect grows as you explore how to build a bridge from internals to end users. Developing interfaces for others is one of the hardest things we do, but thankfully you are not alone. I have spent the last two years interacting with and creating interfaces to cloud services with fog. By exploring examples we can see patterns and establish best practices for APIs, CLIs and even library code.

CouchDB is an increasingly common member of the Ruby developer’s toolset. Its flexible model, low footprint, REST interface, and wide library support make it a natural choice for many web, mobile, command-line, and desktop Ruby apps. As community manager at Cloudant, I can tell you that Ruby is the #1 language customers use to access our CouchDB hosting service. But unfortunately, it’s also the language where I have observed the highest levels of egregious misuse. Out of the hundreds of Ruby production apps that use our service daily, an overwhelming majority are plagued by poor design, wasteful queries or inefficient indexing; and as a result, the average response time for our entire Ruby userbase is 2–3x higher than in other languages.

Beyond plain misuse, I have also noticed a rampant and severe underutilization of CouchDB; in most cases, it's dropped in as a replacement for MySQL and used in the exact same pattern you would a single-instance, relational database. CouchDB has much more to offer, and by leveraging some parts of its design, I believe it can help the average Rubyist solve very common pain-points or serve very common use-cases, from embedded Ruby apps, to mobile applications and of course, web services.

This talk will explain the best practices that I've observed, tried and implemented, from a large pool of examples that includes the customer apps I've helped optimize and debug, as well as my own. Due to the necessity of re-explaining some core CouchDB concepts, this talk may function as an introduction to CouchDB, but will also contain valuable lessons for the more experienced users.

Programming languages must be implemented in Java or C, everybody knows this. Sure, a prototype in Ruby, but that would be unusable. After all, Ruby is made for web development, right? Hard tasks, like implementing a compiler, have to happen in far more manly languages. But wait, the Rubinius compiler is written completely in Ruby, and it seems to get pretty decent performance, maybe we can use that.

In this talk, we will explore the possibilities of using the Rubinius compiler tool chain to implement our own programming language targeting the Rubinius VM. We get all the hard work that went into Rubinius for free and above all, can do the heavy lifting in Ruby, everyone's favorite programming language.

As an example we'll use Reak, a Smalltalk implementation running on Rubinius.