This talk will explore various techniques for measuring performance of Ruby apps. It will cover a wide set of tools: from Sam Saffron's own Flame Graphs and MiniProfiler, to rb-lineprof, and recent MRI commits that provide better information on object space allocation that will appear in Ruby 2.1. The talk will be highly technical.

Ever wonder how Sequel, ActiveRecord or DataMapper work? Let's build a working mini-ORM, complete with an application and tests! Ruby makes it surprisingly easy. We'll go over all the code in 30 minutes. There will be a GitHub link so you don't have to type furiously.

Come to San Francisco as a Rubyist, leave as a speedcuber. We are going to use Ruby, a video camera, and an insane amount of live demonstration to learn how to solve the Rubik's Cube in less than 20 seconds. You will leave this talk knowing which cube to buy, which of the five most popular solving methods you should be learning, how to practice for speed, where to ask questions, and how Ruby can help teach you to be the fastest speedcuber in town. People are solving the Rubik's Cube quicker today than any time in history and there's a reason why.

Data is a hot buzz word in the industry. Every day there are more startups with "Big Data" somewhere in their elevator pitch. There are dozens of devices to record how we sleep, what we eat, how much we exercise, even how often we breathe. Every action we take online generates data that is stored and analyzed. Understanding all this data can be difficult. Humans aren't designed to see patterns in thousands of lines of json or XML. We are good at seeing patterns in pictures, graphs, diagrams, and spots in the underbrush. Often a simple visualization is what you need to understand a problem. In this talk, I'll demonstrate tools that you can use to quickly generate "back-of-the-envelope" visualizations from a variety of data sets.

Over the past few years, Nokogiri has slowly eclipsed older XML parsing libraries to garner nearly 12 million downloads from rubygems.org. But why another XML parsing library? Isn't it boring? And what does "nokogiri" mean in Japanese, anyway?

These questions will be answered, and I'll do a brief dive into all the technologies that we use to make Nokogiri a fast, reliable and robust gem. Topics will include:

Origins of the project: motivation, problems and impact
Native C and Java extensions
FFI, and how to know if it's Right For You
Debugging tools (valgrind, perftools)
Packaging tools (mini_portile, rake-compiler)
Installation issues, and what we're doing to help

James Edward Gray II has been programming long enough to learn a thing or two about how this computer stuff actually works. Nobody cares about that. Seriously, that's not the most common thing people ask him about. Instead, they often come with questions about why James tools around in an eletric wheelchair. Were legs just not hackable enough for his taste? Does he have a Charles Xavier complex? Does he not eat enough beta-carotene? James is ready to answer all of these questions. He believes the answers might even be just a little related to programming. Don't be surprised if you find yourself wishing for some neuromuscular disease of your very own. (Note: live genetic engineering is a violation of GoGaRuCo's insurance policy, but James can teach you how to fake a disability for the purposes of gaining deeper insight into code—allowable due to the Reprogrammed Humans for the Greater Good Act of 2442.)

Going full SOA has unarguable benefits, but the steep startup cost and need for excessive forward planning goes against the agile mentality of strictly necessary, small, incremental changes. At Lumosity, we've developed a set of best practices using engines to entirely divide behavior and responsibility by wrapping new services within well-defined, small Ruby APIs. This technique obviates the need for complex network (HTTP) APIs with their well-known problems of maintenance and testing. Get rid of spaghetti code without diving into the deep end of recorded responses and fake servers. Later, if the architecture demands a separate service, the engine will already have an API fully defined and ready to port over from Ruby to HTTP.

For every enthusiastic attendee at a Ruby conference, there are a hundred people who have tried Ruby and walked away. There's also at least one person who's hit the top of Hacker News complaining about it. Are missing features or poor performance chasing people off? Is the community too international, or not responsive enough on GitHub? Maybe the problem is the ones who walk away — the inexperienced masses, poisoned by Flash, Visual Basic and PHP.

Languages and frameworks are interesting things. When you're choosing one, it's important to consider social information about your team — and the project you're evaluating — before making a decision. But while every README has bullet points listing the project's technical features, it's much more challenging to identify and extract the right social data to help that evaluation process.

Let's bring this missing information into the light and look at social data from real teams, real projects and real extracted code. We'll make better decisions. We'll understand why Hacker News exists. Everyone wins! And you still don't have to do Flash.

This talk will explore various techniques for measuring performance of Ruby apps. It will cover a wide set of tools: from Sam Saffron's own Flame Graphs and MiniProfiler, to rb-lineprof, and recent MRI commits that provide better information on object space allocation that will appear in Ruby 2.1. The talk will be highly technical.

Many of us approach regular expressions with a certain fear and trepidation, using them only when absolutely necessary. We can get by when we need to use them, but we hesitate to dive any deeper into their cryptic world. Ruby has so much more to offer us. This talk showcases the incredible power of Ruby and the Oniguruma regex library Ruby runs on. It takes you on a journey beneath the surface, exploring the beauty, elegance, and power of regular expressions. You will discover the flexible, dynamic, and eloquent ways to harness this beauty and power in your own code.

Every aspect of our lives has been transformed by the invention of general-purpose programmable computers. As a result, it's tempting to believe that computers can solve any logical or mathematical problem; that if we throw enough time, money and nerds at a question, we can produce a program which answers it.

Unfortunately the universe is never that convenient. There are hard theoretical limits on what programs are capable of doing, and there will always be straightforward problems which are impossible for any computer to solve.

This talk uses Ruby to tell a nail-biting, math-free story about the source of a computer's power, the inevitable drawbacks of that power, and the impossible programs which lie at the heart of uncomputability.

The robotics revolution has already begun. You can buy drones and robotic devices at local retail stores. Unfortunately, it’s hard to develop code for robots, and nearly impossible to create solutions that integrate multiple different kind of devices. Introducing Artoo, a new robotics framework written in Ruby. Artoo can communicate with many different kinds of hardware devices, and integrate them together. With surprisingly few lines of code, you can write interesting applications that tie together Arduinos, ARDrones, Spheros, and more… even all at the same time! The time has come for Ruby-based robotics, and Artoo can help lead the way!

Concurrency in Ruby is hard and our thread-unsafe code often works by accident. We are not used to thinking about concurrency because of the GVL but there are different implementations of Ruby with their own semantics that can unearth concurrency bugs. We have to get more accustomed to writing threadsafe code and understanding concurrency, especially with the rise in popularity of JRuby.

I will discuss approaches to writing threadsafe code in this talk, with a specific focus on performance considerations. I'll start with explaining some basic concurrency concepts, describe methods for handling shared mutable data, and touch on the subtleties of concurrency primitives (Queue, ConditionVariable, Mutex). Historical, squashed, hair-raising bugs in the Ruby driver to MongoDB will be used throughout the presentation to illustrate particular concurrency issues and techniques for solving them.

You know that smartphone in your pocket? The one with gigahertz of processing power, a surprisingly good camera, and the ability to instantly access the whole of human knowledge? Despite all of that high technology, if I want to call you, I still have to punch in a phone number—a technological relic that remains integral to our telecommunication infrastructure.

URLs are the same thing. The web is URLs and URLs are the web. Unfortunately, for the past few years, many JavaScript developers have started treating the URL as an afterthought, or a nice-to-have. In this talk, I’ll show why URL neglect happens at your own peril, and how making JavaScript apps that respect the URL can be, well, downright pleasant.

If there's anything that recent events have shown us, it's that what we thought was secret actually isn't. So what to do? Even if you're not a dissident, many of our applications need some form of private communications. And why aren't RubyGems signed, anyway? In this talk, Steve will discuss some of the basic tools, theory, and techniques that you can use to help keep secrets secret.