Sessions at RubyConf 2011 on Saturday 1st October

As Ruby programmers our server side programs throw us in all kind of troubles. Hung processes, memory leaks, process spending too much time in GC, profiling etceteras.

As mostly live coding and hands on session, I intend to show - how to use modern tools to find and fix these problems. I will be demonstrating, how to use GDB with live process, using rbtrace, perftools and various ways to detect memory leaks & performance bottle necks in your process.

Now that there are now over 25,000 gems on RubyGems.org, it's time we took a step back to look at the quality of what we're producing and the best practices we can all follow that will benefit the community.

Other languages expend a lot of effort maintaining a standard coding style and consistent APIs among their shared libraries, but the Ruby community doesn't. This has done a lot to lower the barrier to entry and allow the Ruby ecosystem to flourish, but it has also produced a lot of code of questionable quality that doesn't always mesh well in our applications.

There are simple conventions we can follow, though, that will make a big difference in establishing a consistent baseline for our gems. These include things like writing gemspecs instead of Rake tasks that generate them, properly namespacing your libraries, and not polluting the load path. But there are also other practices that will benefit others, like producing good documentation, including binaries when needed, and establishing a sane versioning strategy.

We'll cover the full lifecycle of a gem from beginning to end, from your first push to RubyGems.org to making and accepting community contributions, and consider the conventions that we can establish each step of the way to increase the value of the gems we're producing.

The last two years have been a personal tour of EventMachine, Fibers and Threads for me as I've toured the ecosystem looking for a developer-friendly, efficient solution for scaling Ruby. Historically Threads have performed poorly in Ruby but guess what? - recent events may change your mind. Now would be a good time to give them a second chance.

Build features fast. Ship them. That's what we try to do at GitHub. Our process is the anti-process: what's the minimum overhead we can put up with to keep our code quality high, all while building features *as quickly as possible*? It's not just features, either: faster development means happier developers.

This talk will dive into how GitHub uses GitHub: we'll look at some of our actual Pull Requests, the internal apps we build on our own API, how we plan new features, our Git branching strategies, and lots of tricks we use to get everyone — developers, designers, and everyone else — involved with new code. We think it's a great way to work, and we think it'll work in your company, too.

Almost every developer has dreams of grandeur made up of machines bending to our every will. This is now not only possible, but its a good a practice! Harnessing some Ruby power and by scripting Vagrant, an application to build virtualized environments, virtual machines can be used in previously unthought ways. In this talk, learn how to script Vagrant and use it to build testing environments for your Ruby libraries and applications. The end result is that your applications and libraries are now known stable on systems which were previously difficult to test.

JavaScript is great, but let's face it, being stuck with just JavaScript in the browser is no fun. Why not write and run Ruby in the browser, on the client, and on the server as part of your next web application?

Don't believe it, think its a crazy or an awesome idea, or think that it just plain won't work? Drop by to learn about Google Chrome's Native Client (NaCl) project which is aiming to allow web developers to seamlessly execute native code inside the browser. We'll take a look at the motivating use cases, dive under the hood to understand how it all works, and also work through a functional example of running Ruby code in the browser!

Go is a statically-compiled systems language geared to developing scalable and type-safe applications whilst leveraging type inference to approximate the light touch of a dynamic language. It could be characterised as the static-typing world's response to Ruby.

In this session we're going to explore the Go language, its tool-chain and idioms such as CSP-based concurrency and dynamically inferred interfaces to see how they influence the design of Go applications. We'll compare these to equivalent Ruby idioms where they exist, model Go-style concurrency in pure MRI Ruby, and look at interoperability between the two languages.

Along the way we'll meet gotest (Go's testing and benchmarking framework), CGO (for linking to C libraries), goinstall (the remote package installer) and Go's powerful reflection and type manipulation features.

There'll be a good mix of Go and Ruby code so that by the end of the session you'll be comfortable reading Go source code, have a basic feel for developing with the language and the necessary background to start using Go components in your dev projects.

We are known for our community. Does this mean our job is done? Are we starting to stagnate? Simply gathering Rubyists together isn't enough. How are you improving your community? Fear not as anyone of you can take action. Whether you live in a place with no organized Ruby meet-ups or you're contemplating a big regional event, we will go over why you should take action and give you practical steps to do so. We'll also bring light to not just increasing membership counts but actively making everyone better. Innovation is happening out there that we'll go over in detail. Join us, learn and get involved -- we're building something awesome!

I wanted to know, "Do I need to learn about EventMachine or node.js? Can I use threads? What is so good or bad about threading in Ruby 1.8, Ruby 1.9, JRuby and Rubinius 2.0?"

What was important to me was the the choice was abstracted away. I wanted to write normal, step-by-step Ruby code. Yet I wanted it to be performant.

I've asked a lot of people. I even hosted EM RubyConf (http://emrubyconf.com) during RailsConf 2011 in order to gather the brightest minds in the Ruby community.

"What choices do I need to make, how different does my code look, and how do I do testing?" These are the questions I searched for answers.

I'd like to now share the answers.

APIs are becoming ubiquitous, but they are really hard to design well. In this talk, we'll discuss how to design and implement an API that isn't just functional, but makes people stand up and cheer. We'll also cover tips for integrating with other people's APIs.

But an awesome API isn't just a feature. APIs are currently transforming the world, just like open source software has changed the world for the last decade. We'll talk about how this transformation impacts developers and changes the rules.

Someone once told me that software development is a constant battle against complexity. Over the past three years we've built several large systems at GitHub and if anything, that saying is an understatement. Things like tight coupling, insufficient testing or documentation, lack of versioning discipline, and underspecified design documents can easily lead you down a path of ruin. In this talk I'll cover many of the techniques we use at GitHub to defend against complexity in our Ruby systems, including Readme Driven Development, Semantic Versioning, TomDoc, Git/GitHub workflow, modularization, metrics, and exception reporting.

What truly makes Ruby special as a language is its focus on expressivity, flexibility, and dynamism. Yet these same properties - and their widespread use in the community - make even straightforward application code difficult to analyze statically in a meaningful way.

Laser seeks to change that. As a general-purpose analyzer using traditional compiler techniques, it statically discovers properties of real-world Ruby programs that no existing tool can. This talk is a whirlwind tour of what Laser can do, how it does it, and what it means for a typical Ruby programmer (who doesn't want to litter his or her code with type annotations). Among the questions it attempts to answer:

• What code never runs?
• What variables are unused?
• What code runs, but has no meaningful effect?
• What exceptions might a method raise?
• Are blocks required, optional, or ignored by a method?
• What variables are constant?
• What methods get generated (or removed) by loops at load-time?
• What types are being used, and where?
• What gets added to a class by calling a method like acts_as_list?

Most importantly, Laser uses this information to find bugs and tell you about them, in addition to warning you about potential mistakes. It has a clear integration path with YARD and Redcar, as well as a possible future in optimization. On a broader scale, Laser exposes and builds upon the underlying strength and regularity of Ruby and modern Ruby techniques, without restricting Ruby's natural expressivity through static typing.

Programming languages, such as Ruby, are natural and elegant. But to achieve this elegance, things have to happen under the hood. Garbage Collection, concurrency, Global Interpreter Lock, metaprogramming, C extensions are just some of the things happening with or without our knowledge. Trying to understand these concepts, their implementations and their implications in daily coding might seem daunting. However, having a good understanding of these topics will make you a better developer. No CS degree or PhD required to attend this talk.

An exploration of how the DataMapper pattern used by MongoMapper works very well with key value stores, in general, and how exceptionally well it works in a Document store like Mongo exceptionally, versus it's less ideal match with a schema based document store like an RDBMS. Tim will be comparing benefits of how the ease of modeling your data in such a way, versus the iconic DB modeling of 3rd normal form, which brings up issues of composition over inheritance, which favors 3rd normal and how ruby's mixin system plays into that tension.

This all leads up to having a data model that is trivial to make excessively dynamic, and challenging to keep sane and consistent, in such a system. Methods of migration and data massage are discussed with Tim suggesting what has worked best on some real Mongo projects, but such an approach would work well with any kv store.

You might never find the need to sandbox ruby, but trying to sandbox ruby is fun. We get to dive deep into the internals of Ruby and learn all the ways running ruby code securely can fail. We’ll walk through some different approaches and how they can be broken:

• REGEX to the Rescue
• Threads and $SAFE
• JRuby/MacRuby Sandbox
• RubyCop – A ruby static analyzer

And after surveying the sandbox scene we’ll draw some conclusions on how to mitigate potential sandbox failures and how Ruby itself can change to make really sandboxing Ruby a reality.