Your current filters are…
by Ron Evans
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!
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!
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.
There are lots of reasons to understand distributed systems. Among them are the facts that the principles can improve your site's availability, performance, and even maintainability. We'll talk about principles, patterns, and pitfalls to watch out for when writing your first distributed system.
by Wesley Beary
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.
by Corey Haines
Look at your Rails unit test suite. Now look at mine [ http://screencast.com/t/O2LhGoVSG ]. Now look at yours again. Mine are sub-second. Yours aren't. Having a slow unit test suite can hinder an effective test-first or test-driven approach to development. As you add tests, the suite starts to slow down to the point where you stop running them after each change. Some people even talk about multi-minute unit tests suites! Band-aids like spork are just covering up the problem. Test-driven development is a major player in keeping your design malleable and accepting of new features, but when you stop paying attention to the messages your tests are sending you, you lose this benefit.
In this talk, I will go over some techniques for keeping your test suite lean and fast. Along the way, we'll discuss the design improvements that come out of these changes.
Now, look at my unit test suite again. Yours can be like mine.
by Tim Anglade
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.
by José Valim
In this talk, José Valim will share what he has learned about Ruby through writing a small programming language. He will discuss the basic structure of a programming language, suggest improvements and debate about Ruby's parser, object model, methods, iterators and blocks.
The Go programming language, invented at Google, brings a novel new approach to parallel programming. With a strong focus on developer productivity and software readability, Go shares a lot of design philosophy with Ruby while targeting a different set of problems. Though the use of new language primitives, goroutines and channels, Go applications can solve programs in a highly parallel fashion without the use of locks.
This talk introduces the Go programming language, discusses the innovative parts of the language's design, and demonstrates how these concepts can be applied to Ruby.
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.
16th–17th September 2011