Chris Kelly

String Theory

Peer into the dark and mysterious world of Ruby internals, delve to the point that the basic String becomes a complex web of optimizations, flags and peculiarities. The starting point for String Theory is the observation that immutable strings are more performant than mutable ones, and 23 character stings are more performant than longer ones. The how and why of these idiosyncrasies is where our journey begins. We'll chip away at the Ruby VM to explore how String is implemented in C, to fully understand String Theory we'll need to journey into Ruby memory structures and ultimately to the garbage collector. Get your spelunking gear ready as we discover how the GC has evolved, once we emerge from the darkness you'll see Ruby in a whole new light.

Emily Stolfo

Wrapper's Delight

Many of us have found ourselves writing a Ruby API to wrap another API but caught up in the tension between feature over-exposure and idiomatic consistency. It isn't always obvious whether it's better to favor flexibility by exposing the underlying API itself or to commit to a concrete level of abstraction. In using the Ruby driver to MongoDB as an example, we'll explore some of the choices us wrappers have to make in building the best API.

There are two main points to keep in mind while building an API and making design choices: Ruby gem API design is a form of user experience design and a good API should be easy to maintain. We'll take a look at a number of UX principles and see how they apply to API design and discuss how to optimize for unanticipated changes in what we are wrapping.

Yannick Schutz

Postgresql for the ruby/rails developer

Frameworks tend to abstract more and more the database to provide users a similar experience using mysql, sqlite, postgresql and some even try to abstract over MongoDB. It is important to bring back the power of the database to the web developer.

The database is where all your data lives and is the most important piece of your architecture. Tame your database and learn its inner power to bring a better experience to your users. My favorite animal is PostgreSQL. What you will learn here:

• How multi columns indexes, partial indexes and functional indexes will turn your old Lada to a Lamborghini.
• JSON and Hstore columns. Bring the NoSQL to your SQL with grace. See how your tables says thanks when you stop adding columns to them every 5 minutes when a store column give you power for the next ten features.
• Arel: How to level up your ActiveRecord to do what basic it cannot do alone. I'm looking at you OR queries.
• Plain text queries in your Ruby and how it is not always SQL injection-ish. SQL can do magical stuff for you too.
• psql, EXPLAIN ANALYZE, testing indexes, using pg_stat_statements, and some queries that will tell you what is wrong with that database.

It might also interest you, GO/PHP/Python dev!

Sam Phippen

Anatomy of a mocked call

RSpec is often accused of being "full of magic". For the most part: I disagree. However: mocking a method on an object, calling it, recording that call and then working out if expectations have been violated after the fact is a complex set of operations.

This talk will give a guided tour, with code, through RSpec's mocks. We'll look at one of the most simple cases possible. We'll also look at the most complicated case I can conceive of. Hopefully everyone will learn a little something about testing whilst watching this talk.

Eloy Durán

RubyMotion under the bonnet

RubyMotion is a toolchain that let’s you develop native applications using a the Ruby language. This talk will focus on what makes RubyMotion tick and take a look at Ruby from a static point of view, covering topics such as AOT vs JIT compilation, memory management, and interfacing with different languages and runtimes.

Konstantin Tennhard

Large-scale Rails Applications

Building large-scale applications is a demanding process – no matter which framework you use. The true challenge, however, lies in maintaining these applications. To guarantee maintainability, we need to focus on the following three aspects: comprehensibility, modularity, and robustness. And easy to maintain applications make developers happy!

This talk is about building large scale applications on top of Ruby on Rails. The framework is known for getting you started quickly, but is it still a good choice when your application grows past 100,000 lines of code?

During this talk, we will mainly focus on how to model complex business processes efficiently, that is, how to extend Ruby on Rails with a modular service-layer that plays nice with ActiveRecord. You will see how to take advantage of some of Ruby's unique and more advanced language capabilities.

But most importantly, you will learn how to use all these techniques to improve the design of any existing Rails application.

Joshua Ballanco

What's Eating Ruby?

Will you be writing Ruby 10 years from now? 20 years? Recently Ruby has been described as “maturing” or even “dying”, but why? Sure, many up-and-coming languages are better than Ruby at some things, but can any of them really replace Ruby for all things? Indeed, why shouldn’t Ruby stick around? We’ll take a broad look at how Ruby has influenced the development of new languages, and whether or not Ruby can remain relevant in the face of increasing competition.

Phil Nash

Asset Redux

Web application speed is paramount. Our users want our application and they want it now! We can optimise application code, database queries and so on, but that's all wasted if the page takes ages to appear. A fast back end and a slow front end can end up leaving a bad taste in the mouth.

Using Rails, we'll look at the best ways to speed up the delivery of your application. Going beyond just minifying our assets, we'll look at techniques to get our site in the user's browser quicker, improving both real and perceived speed. We'll also discover the best tools to use to check out speed and get a better idea of the user's opinion of the site.Once finished, our sites will load in a flash!

PJ Hagerty

Coding and the Mozart Effect

Most developers code to music… some are even musicians themselves. Is it possible to streamline workflow by adjusting how we listen to music and what music we listen to? Studies have shown that exposure to certain kinds of music can help to develop cognitive strength and improve performance of tasks.

This talk will explore those studies and show what sort of things can be done to improve the listeners environment and help people to create better code.

After party

Join us at Ayers Rock Boat and enjoy the party!

Tom Stuart

Compilers for Free

Partial evaluation is a powerful tool for timeshifting some aspects of a program's execution from the future into the present. Among other things, it gives us an automatic way to turn a general, abstract program into a faster, more specialised one.

This maths-free talk uses Ruby to explain how partial evaluation works, how it can be used to make programs go faster, and how it compares to ideas like currying and partial application from the world of functional programming. It then investigates what happens when you run a partial evaluator on itself, and reveals some surprising results about how these techniques can be used to automatically generate compilers instead of writing them from scratch.

Paolo Perrotta

A Problem with Frogs

When you tell people that you’re a programmer, they think that you work with complicated stuff. But you know better: not everything that you do is complicated. Most things that you do are much worse than that.

This is a speech about the theory of complexity—but don’t worry, it’s more fun than it sounds. I’ll try to answer a question that applies to most things you do as a developer, from writing code to talking to customers: how do you solve a problem, when you don’t even know what the problem is?

Arnab Deka

Modern Concurrency Practices in Ruby

So you think that concurrency is a subject lost in the Ruby world? That it's not practical because of the GIL? That the concurrency paradigm that's bundled with Ruby (a.k.a threading) is not the best way to do concurrency? Or that you already have multi-processes and don't need multi-threading concurrency.

Think again. The Ruby concurrency story has advanced a lot in the last couple of years. Have you heard of people talking about actor-based concurrency, using futures, Software Transactional Memory, channels etc. and want to know more about those?

This talk is a primer on these different paradigms of concurrency, briefly touching on the traditional threads-based model, but focusing more on modern paradigms like actors/futures/STM/channels, with examples and demos. Along the way we'll also see what's already possible in Ruby (and in other implementations like JRuby and Rubinius, using gems like Celluloid and friends).

Cameron Daigle

More Code, Fewer Pixels

Removing the "Design Phase". Eschewing Photoshop. Using frameworks. The malleable, flexible, agile nature of web apps these days requires a drastically new approach to how UI concepts are transformed into working code.

Join me as I dive into the vagaries of Hashrocket's design-develop-revise-repeat feedback loop – and learn how we turn static markup into an essential communication tool through rich UI prototyping, generated content, and general cleverness.

Terence Lee

Ruby & You

On November 22, 2013, a devastating security exploit was publicized to the Ruby community: Heap Overflow in Floating Point Parsing CVE-2013-4164. There was no fixes provided for Ruby 1.9.2. In fact, Ruby 1.9.2 has never had a formal end of life announcement.

At Heroku we realized this impacted our ability to provide reliable runtime support. Not wanting to leave our customers high and dry, Heroku released Ruby 1.8.7 and 1.9.2 security patches on our runtimes and pushed to get them upstream.

This situation paved the way for me to join ruby-core to help maintain security fixes for 1.8.7 and 1.9.2. Over the course of the year with help from zzak, I’ve been figuring out how to work with ruby core as well as proposing policy changes for more transparency.

This talk, goes through the steps and mistakes that I learned on how to interact with members of ruby core as well as telling war stories of my experience on core. We’ll remove the opacity around getting contributions upstreamed and how you can have meaningful discussions with the implementers about the language we all know and love. Help us make Ruby better.

Discussion of Ruby's future