Ruby has many inspection features to understand the behavior of your Ruby program. In this presentation, I will introduce such inspection methods, from simple ones to more complex ones. I will also talk about the progress of Ruby 2.2, next version to be released at the end of this year.

Let's talk about speed! In this talk, we'll examine ways that we've been speeding up Rails for the next release. We'll look at techniques used for speeding up database interaction as well as view processing. Techniques for finding bottlenecks and eliminating them will be presented, and we'll talk about how these techniques work with regard to Rails applications themselves. The presenter will also be discussing ways to speak in first person.

Abstraction is a fundamental approach in programming. It shapes how we solve problems, it is a defining factor in how we view the internals of software and even the world surrounding it and us. The questions of when, how and what to abstract are some of the biggest in computer science and can make the difference between good and bad code. This talk is a fresh take on different facets of abstractions we encounter, build on and have to fight with.

Docker is "an open source project to pack, ship and run any application as a lightweight container". In this talk, we'll explore the basics of Docker, the advantages of container-based virtualization, and how to setup Rails deployments using both.

Like a garden, open source projects require cultivation, diligent maintenance, and pruning to sustainably produce a harvest. Without proper care, they become a burden that smothers your reputation, causes harm to your product, and kills your morale.

Tending the open source garden is not easy, and it's not for everyone. At GitHub, we have released a lot of open source code over the years and we have experienced both the benefits and the costs. This talk will examine the lessons I have learned in cultivating and maintaining open source projects.

Avoiding complexity is one of the greatest goals in programming. The tools we use, libraries and frameworks, must be helping us in achieving that goal. There must be a reasonable balance between convenience and simplicity as growing complexity is the price we pay for that convenience.

This talk is about seeking simplicity when dealing with data and behavior showing alternative approaches to object relational mapping and persistence concerns.

fluffmuffin, peppercorn, gilligan — those are just a few of our users' plain text passwords.

I have 80,000 more, and it only took me 87 seconds to gather them from our customer database in a white-hat attack.

In Act I, we'll cover the history of secure password storage, examine the hack, and mitigate the threat. Act II will address the difficulties of working on libraries with complicated external dependencies (like bcrypt-ruby, of which I'm now a maintainer). In Act III, we'll celebrate the power of global collaboration via OSS.

[Scene.]

I love Ruby! But as in any relationship, to love means that you (often) have to accept the “dark side” too! Ruby is human in nature and has a lot of gotchas, tricks, weirdness and sometimes scary features that I plan to highlight. This talk aims to provide the “Ah-ha!” moments when working in Ruby.

This talk is for beginners and experts alike - in fact, I tag slides to mark their level and beginners can choose to tune out of the heavy stuff! My talk shall cover the dark side of the following features of Ruby (in no particular order)

• Keyword wierdness
• method missing
• Module inheritance! (huh?)
• Accessor righteousness
• Curried Procs for the hungry
• Base Conversions
• Cherry picking module methods
• Oniguruma games
• Object id weirdness
• procs, blocks and our friend stabby.
• ==, ===, eql? and equal?
• and more…

As with most of my talks, humor plays an important role and I shall aim to get everyone high on Ruby with a deep dive!

Recently it has become common practise for development teams to deploy their code several times a day, as well as encouraging new developers to deploy on their first day at work.

In this talk, I will discuss how I use continuous deployment to push these practises to the extreme. Automatically deploying the master branch on new changes is an awesome way to improve your development process.

Automatically deploying master will fundamentally change how you work. Gone are the days of the epic pull request. You'll quickly find yourself writing smaller more manageable chunks of code, that overall have a great impact on the quality of the software you produce.

By the end of the talk you'll know how to change the GitHub merge pull request button into a deploy button - and have the confidence to do so.

Some things I'll go over in the talk:

• How to setup your CI environment for deployments
• Why having fast tests are important
• How to use your Staging environment for testing deployments
• How to use feature flags to hide deployed features from some users
• Zero downtime deploys, even when there are database migrations
• Your new deploy button, AKA The GitHub merge pull request button
• What to do when deployment goes wrong

As developers, we know that we should use the right tool for the right job. While we may love Ruby, there are also many interesting technologies that may complement our favourite programming language.

This talk introduces Elixir, a programming language that is built on the legendary Erlang virtual machine. I will first give a quick walk through of the language, focusing on core concepts such as concurrency and fault tolerance - areas where Elixir shines.

After that, we will dive straight in to an example application to see how Ruby can exploit the powerful features of Elixir. More importantly, the audience would realise that there's more to Ruby than just Ruby.

It will be a fun ride!

Active Record is awesome. But how does ActiveRecord handle generating complex SQL queries? Under the hood it's handled by Arel. Most of the time, Rails developers don't have to know about how Arel works.

But sometimes Active Record can't satisfy our needs. Also Arel has many strengths not exposed through Active Record.

Let's experiment with Arel directly and wield great SQL power in database agnostic way.

Data streams (ex: logs) are becoming larger, while analytics in (semi-) real time is also becoming more important today. We want to collect huge data sets from many sources, and analyze these data in various way to gain valuable business insights. For these purposes, software on jvm (Hadoop, Flume, Storm, ...) works well, but we (Rubyists!) need more Ruby-like, scriptable, ease-to-deploy and extensible software. That is Fluentd.

I'll introduce Fluentd, a famous log collector in Japan, and its plugin systems. Fluentd is a very simple and well-designed software that have various plugins to collect/convert/aggregate/write stream data, which are already used in many production environments. And I will also talk about Fluentd's development plans, newly implemented features and case studies in LINE.

Domain Driven Design is a software development process that focuses on the finding a common language for the involved parties. This language and the resulting models are taken from the domain rather than the technical details of the implementation. The goal is to improve the communication between customers, developers and all other involved groups. Even if Eric Evan's book about this topic was written almost ten years ago, this topic remains important because a lot of projects fail for communication reasons.

Relational databases have their own language and influence the design of software into a direction further away from the Domain: Entities have to be created for the sole purpose of adhering to best practices of relational database. Two kinds of NoSQL databases are changing that: Document stores and graph databases. In a document store you can model a contains relation in a more natural way and thereby express if this entity can exist outside of its surrounding entity. A graph database allows you to model relationships between entities in a straight forward way that can be expressed in the language of the domain.

I want to look at the way a multi model database that combines a document store and a graph database can help you model your problems in a way that is understandable for all parties involved.

It's my personal goal to introduce as many people as possible to open-source and make it dead simple for them to contribute.

What happens if you have something specific you want to contribute?

This talk will show you the best practices for discussing features and ideas with ruby-core. We'll show you how to get your high-level concepts imagined through efficient channels of discussion to implementation.

We should talk about how fear and language barriers play a role in getting the right kind of feedback. We'll also talk about how ruby-core operates with the vast distance between its members.

Most importantly, we'll give you the confidence to work effectively with ruby-core and how we can improve Ruby together.

This talk covers following SOLID design principles in Ruby with live code examples.

Single responsibility principle: an object should have only a single responsibility. Open/closed principle: an object should be open for extension, but closed for modification. Liskov substitution principle: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program Interface segregation principle: many client specific interfaces are better than one general purpose interface. Dependency inversion principle: depend upon abstractions, do not depend upon concretions Talk will have live code example which will be evolved step by step to use all SOLID principles. This talk will also answer the question why just following these principles will make your code more clean readable, extensible and better. Also make you better programmer.

RSpec, like it or loathe it is a widely used testing framework and this year will reach it's latest major version. Version 3. Why is this a big deal?

It's the product of many months of work by the core team and makes a lot of changes to improve its code base both internally and externally. Some of the changes are contentious and some are just cool, but why did we make those decisions?

Let me take you thought the major changes in RSpec3 and detail why we took that decision you don't like, why did we deprecate that feature or why do we recommend this way of doing things. Hopefully you'll be encouraged to write better specs or maybe just understand this little piece of the Ruby ecosystem a bit better.

I have spent some time working on a project where we've built 8 micro services and 2 applications, and planned to carve out a few more. Deployment was carried out in a farm of 25 servers in production with a single click in less than 3 minutes.

In this talk I will share our experiences with building a micro service based architecture - the good, the bad and the ugly.

• What are micro services?
• When/Why/How micro services?
• Why NOT micro services?
• Managing Continuous Integration and Continuous Delivery with micro services
• A few design principles that we followed and that worked for us

An overview of ActiveSupport::Notifications and how they form the backbone of a live status page to tell you exactly what is going on with your site.

Single page web applications have been all the rage recently. At Shopify, we wanted to make our admin interface a dynamic and fluid experience for our users. We created our own JS MVC framework and used it to rebuild our admin. Now we have decided to change course. What fueled this decision? What lessons have we learned? What worked and what didn’t? This talk will share our experiences, as well as our new hybrid approach: A modified version of Turbolinks combined with a lightweight binding system.

Ruby gives you a great power, such as easy Duck Typing. As the saying goes, "With great power there must also comes great responsibility!" It comes at a price. We cannot afford to blow off everything when shipping. That's why it's important to put in place different strategies to help us to catch errors asap, but also to avoid the cruft long term. Like a safety net, they allow you to go forward with more confidence.

How can we make Ruby programming more pleasant? The most common (and easiest) methods are to make RubyGems or fix Rails defects. How about contributing to Ruby? Most people think that it's difficult to contribute or fix Ruby. Well, it is actually easy to contribute to or fix Ruby and many more people would be affected by your effort!

How can you start fixing Ruby? I'll introduce the methods to get started in improving Ruby, such as proposals of new features, writing documents, fixing websites, reporting defects and more.

Furthermore, there are techniques to help get your proposals accepted, and I'll talk about those too. You can improve the world by contributing to Ruby.

How to use grape to build a REST API that applying best-practices patterns.

• Handling errors
• Versioning
• Pagination and partial response
• Multiple formats
• Handling exceptions
• Logging
• Authentication
• Testing

We will learn how to generate static html pages with Jekyll and host them effortlessly on Github Pages and run automated continuous integrated with Travis CI.

Podcasting needs additional features along with a blogging site. With Jekyll we will learn how to generate feeds file for iTunes or an RSS reader, sitemap and post meta info for each episode.

From an engineer's perspective, algorithmic (or quantitative/systematic) trading is about developing a trading system that applies mathematical and computer models for making transaction decisions in the financial markets. This talk will explore the algorithmic trading process and how we can use Ruby for research and development of profitable stock trading strategies.

In December 2013 I quit my job, bought a ticket to the other end of the world, took my backpack and and went to the airport. Since then I've been travelling from country to country, visiting new places, experiencing new cultures, attending meetups and conferences, and working as a freelance Ruby developer. This is not another "I quit corporation" talk. What I want to tell you is: why it's exciting to become a nomadic programmer even just for a few months, what problems you can expect when you change your place once a week, and how to work effectively without your own office, big screen and fast, reliable internet connection.

A complex application usually uses a number of external dependencies. Installing these on every developer's machine individually can be quite a hassle. How can you simplify this process and make sure everyone has the same configuration? Join us in the talk to understand how this can be done in a matter of seconds with the help of Vagrant!