I will host a game of Jeopardy with questions and answers based on Ruby's syntax, features, standard libraries, etc. Anything that ships with Ruby 2.0 is fair game, new or old.
Three contestants of high Ruby skill will compete to score points with their arcane knowledge of our favorite language. There will be a prize for the winner of the game.
Underneath the beautiful veneer of our Ruby libraries lies a twisted tangle of writhing guts. Maybe you're curious how the pieces fit together or maybe you're tracking down a bug, either way it's easy to get lost in the blood and bile that ties our code together. In this talk you'll learn how to use simple and sharp Ruby tools to slice into large libraries with surgical precision. Turn your impossible bugs into pull requests, and level up your programming skills by Dissecting Ruby with Ruby.
At Rackspace, every minute spent on a manual task is a minute less spent providing fanatical support to customers. It's vital that we automate manual work. This talk is a case study of a group of Rackers who automated network device provisioning by leveraging new and existing services. Automating provisioning processes that stretch across the physical world and multiple applications is challenging. Shipping features on a time table and keeping a maintainable codebase require making intelligent tradeoffs. We want to share with you some of our insights into making these necessary tradeoffs.
This talk explores how the widespread proliferation of cheap sensors of all kinds will create a vast collective memory for the planet which will serve as a record of every cause and effect. This data will be scoured for associations that will be turned into algorithms which optimize every decision we have to make in life. And while we may not always choose to do those things, it will effectively make every person on the planet vastly wiser than the wisest person who has ever lived. In the future, no one will ever need to make a mistake again.
In this talk, I am going to briefly talk about “what cloud is” and highlight the various types of cloud (IaaS, PaaS, SaaS). The bulk of the talk will be about using the fog gem using IaaS. I will discuss fog concepts (collections, models, requests, services, providers) and supporting these with actual examples using fog.
Elixir: Power of Erlang, Joy of Ruby
I’m a language nut. I love trying them out, and I love thinking about their design and implementation. (I know, it’s sad.)
I came across Ruby in 1998 because I was an avid reader of comp.lang.misc (ask your parents). I downloaded it, compiled it, and fell in love. As with any time you fall in love, it’s difficult to explain why. It just worked the way I work, and it had enough depth to keep me interested.
Fast forward 15 years. All that time I’d been looking for something new that gave me the same feeling.
Then I came across Elixir, a language by José Valim, that puts a humane, Ruby-like syntax on the Erlang VM.
Now I’m dangerous. I want other people to see just how great this is. I want to evangelize. I won't try to convert you away from Ruby. But I might just persuade you to add Elixir to your toolset.
So come along and let me show you the things that I think make Elixir a serious alternative for writing highly reliable, scalable, and performant server code.
And, more important, let me show you some fun stuff.
Ruby is a delightful language to work with. And yet, for years, we've been hearing about how MRI is too slow and inefficient for "serious" use. What does that mean? What would a "serious" Ruby runtime look like?
To understand these questions, we need to dig into the design of MRI. How does it work, and what are the underlying principles? What does common Ruby code look like as its executed by MRI? Once we've discovered what makes MRI tick, we can compare it to modern runtimes like Hotspot and V8 to understand why MRI is slower. From there we can take a look at JRuby and Rubinius and see how they seek to close the gap between Ruby runtimes and the competition.
In this talk, we'll dive into the internals of MRI, seeking to understand how it executes Ruby code. We'll look at ways to make our code faster, reduce garbage collection overhead, and find more concurrency in our programs. At the end, you will have a better understanding of how MRI works and how to write better code for it.
Rails as a framework is famous for getting an application up and running quickly, but the very paradigms that make it so easy at the start can lead to maintenance nightmares down the road. Successful applications grow rapidly larger, more complex, and harder to extend and maintain. One way to approach refactoring a monolithic application is dividing it up into a series of smaller applications that organize the work of the system through internal APIs and message queues. In this presentation you will be introduced to tools to enable this architecture, gain insight on how best to use them, and explore the guiding principles behind the SOA approach to refactoring.
Time and time again, skilled developers with good intentions set out into the green field of their new Rails app. Alas, as days turn to weeks, weeks to months and months to years, they find themselves with an ever increasing maintenance burden. Adding new features in a well-designed way starts to feel like an exercise in futility, so they resort to liberal use of conditionals to avoid breaking existing code.
This leads to more complexity, and on the cycle goes.
It doesn't need to be like this. There's no silver bullet that will save your project from this fate, but by practicing a holistic approach to code quality you can stave off the maintenance monsters and keep your app's code feeling fresh and clean. This talk will look at low ceremony, common sense approaches to taking control of the quality of your codebase. You'll leave with an expanded toolbox of techniques to build a culture of quality within your organization.
There's no shortage of choice when it comes to application servers for Ruby/Rack apps. This talk will explain some of the differences between several options, explore configuration required to get them running, and attempt to benchmark performance of a simple application running behind each.
The world of Ruby is a big and beautiful one. Like Cane from Kung-Fu, you could spend a lifetime wandering it's surface and never lack for an abundance of wonder. But there is an even larger world outside its walls that is also filled with amazing things. Based on lessons learned writing C extensions, Java extensions as well embedding interpreters (v8) and applications (Jenkins) inside Ruby, This talk will take you through the best ways to dress up any citizen of the galaxy in order to make it indistiguishable from one of our beloved planet Ruby.
If you work in Rails and have ever wondered about Ember.js, you should know that Ember and Rails go together like Nutella and pretzels. (Which is to say, quite well indeed.)
Get an inside look of the experience of going from having never tried Ember to shipping a production application in it. What makes Ember a good match for certain types of applications? What's so different about it compared to other frameworks? What are the drawbacks?
Using anecdotes, code, and crudely-drawn stick figures, we'll dive into using Ember and Rails, including war stories of climbing over some of the (often surprising) roadblocks encountered along the way.
With this quick tour, you'll be equipped to jump in and start seeing the kind of crazy-ambitious applications you can build when you've got Ember.js in your toolset.
Rails Engines are useful. We can make our code well structured and reusable using Engines.
Rails Engines are fun. You can publish your Engine repo to the world, then make yourself and the world better and happier.
Rails Engine is a sophisticated system. Even though 猿人 (en-jin) in Japanese means "ape-man".
Rails Engine is zen. Everything in our Rails app is an Engine, and Engine is everything. Even the Rails app itself should also be an Engine.
During my talk, you will get to know what exactly Rails::Engine is, and you will see some of my crazy Engine tips, ideas, and implementations around Rails::Engine.
Shifting from an amateur web developer hacking away at my own projects in my living room to a professional Software Engineer at a startup in San Francisco was a huge change in the way I developed. After joining Mavenlink a year ago I went from tiny apps that were 100% my code, with fast test suites, hosted on Heroku to a giant Rails app with a complicated data model, a CI test suite that took an hour, and a legacy codebase touched by 30+ people. I've worked hard the last year to step up to the challenge and I've learned so much in the process. As the developer pool gets more and more junior there will be more people making the same journey as I did.
In this talk I will cover:
skills that are important (some I had, others I had to develop)
contributing to a team much more skilled than you
pair-programming with someone much more senior or junior than you
how culture at Mavenlink has helped me succeed
what you can do to help onboard and train up your Junior Developers
things you should look for in a Junior Developer candidate
I hate to break it to you, guys, but Ruby is old enough to drink. What started out as a small community full of fun, silliness, and connection has been growing. Our small codebases are now large. Our small companies are now large. And the large companies have finally figured out that they want in, too.
So maybe it’s time to start tackling Real Problems and Real Solutions in the world of Real Innovation. Maybe it’s time for the community to grow up, stop playing around, and get Serious™.
But…that’s not who we are. Our community thrives on creativity, play, and luck. And those things aren’t just a weird perk like not having to wear shoes in the office – creativity, play, and luck, when present, actually produce better software. As we grow our projects and our teams and invade the corporate cube farm, there are some things we can lay aside, and there are others we must hold on to as if our very identity depended on them.
Because it does.
TDD has been tattered, torn, twisted, stood on its head, and pounded into an pulp of techno-fetishism. TDD was a game-changer, but the focus in the interceding years has shifted from technique to tools, and TDD has been devolving into a lost art. By tearing TDD down to its bones, this presentation presents TDD in its essence, free of tools, and reinforcing the primary focus on design principles. It attempts to convince you to return to a simpler time when TDD was still about design, and software developers were dutifully steeped in the critical importance of design principles. To avoid being held to any particularly offensive positions, this talk liberally attacking the status quo of testing and contemporary tool-focused TDD in Ruby, while introducing yet-another testing library in Ruby. :)
Many of us came to Ruby by way of Rails (including yours truly about six years ago). We came because our current solutions were clumsy and inconvenient. We came because we appreciated the relative simplicity that Rails offered. And we came because we believe that change is often a good thing.
But not all changes are beneficial.
Over several blog posts, books, and a couple of years, the Rails community has begun to choose complexity over simplicity. Let's talk about why. And let's talk about how we can try to recapture that simplicity that we so once adored.
Rake is ubiquitous in our community, it's in just about every project. But why is this so, it is awkward and inflexible (try passing some arguments to rake tasks), and the way we've come to use it almost encourages bad design. Interestingly we've had a better way, to handle the things that we use Rake for, since before Rake even existed - command-line apps. Apps that do one task and do it well, it's the unix philosophy.
The problem is that as far as most of us know, writing a good command-line app in Ruby is not easy. Fiddling with OptionParser to produce a hacky script is no better than Rake, if anything it is worse. But what if we had the technology to build excellent command-line apps simply and easily? Well, to some extent we already do, but most of the tools available don't go far enough and so never become a viable Rake alternative.
In this talk we'll try to figure out what features a command-line framework needs to become your go-to tool instead of Rake (and how close existing tools are to this ideal). We'll cover things like:
What exactly is so bad about Rake
What makes a good command-line interface
Configuring your command-line apps
What are your options for parsing options
Can a command-line framework encourage good code design?
Writing highly testable CLI apps
And as an added bonus, while we talk about all this, we'll touch on good and bad code design as well as look at some of the unexpected corners of your app where 'bad' code is hiding.
Neural networks (NNs) not only sound really cool, but they can also solve some pretty interesting problems ranging from driving cars to spam detection to facial recognition.
Solving problems with NNs is challenging, because actually implementing a NN from scratch is difficult, and knowing how to apply it is more difficult. Fortunately, libraries, such as RubyFANN, exist to handle the first problem. Solving the second problem comes from experience.
This talk will show a few different approaches to applying NNs to such problems as spam detection and games, as well as discussing other areas where NNs might be a useful solution.
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.
Open Source projects can be hard to navigate for both new and old contributors alike. In this talk, we'll walk through some tips and tricks for dealing with the various pieces of open source projects. From dealing with trolls to nurturing one shot patch submitters into long time contributors we'll walk through various tips to get the most out of your open source experience
Fluency is "what you can say without having to think about how to say it." "Refactoring" is a language that describes ways to make your code better. I want to inspire you to learn more of that language, so you can make your code better without having to think about it.
I'll walk you through the process of reworking a 50-line controller action that's hard to comprehend, let alone refactor. We'll tease apart fiendishly intertwined structures, embrace duplication, use dirty tricks to our advantage, and uncover responsibilities—and bugs!—that weren't obvious at first glance.
The talk is a narrative retelling of how I took an application that needed to communicate with a slow external API and improved the user's experience in terms of speed. I'll talk about the situation that we started with, and then retell the story of measurement, and improvement and measurement and improvement.
I'll talk about perftools.rb, improving the *perception* of speed without having to actually make your code faster, MRI's Threads (when they're a good fit, and how and why we used them), a few strategies for managing threads, and a few other related topics. None of these topics will be discussed in great depth; the format is intended to be a retelling of the project, so I'll limit my discussion to the scope of how it applied to this specific project.
The talk will probably be of most interest to people who have little real-world experience with MRI's Threads and/or making users feel like an application is responding quickly. My hope is that showing these things in the context of a real project can help solidify understanding of topics that are often covered in contrived or theoretical examples (I know it did for me: I was totally new to a lot of this stuff when I started the project).
While Ruby is a terrific language, it doesn't offer a lot of ways to deal with asynchronous tasks using the default libraries. Thankfully, the community has come up with several great options for bringing asynchronicity to your applications. Resque is one of the forerunners of this, and it offers a lot of functionality and flexibility with an easily approachable API. Here, we'll go over several techniques for utilizing asynchronous workers to benefit your projects.
We'll start off with a review of how asynchronous processing works, and then we'll delve into three different things you can use Resque for: speeding up your applications by processing slow operations on the side, performing sequential updates with pipelining, and performing periodic maintenance tasks. We'll go over example code for how to handle these different situations and ideas for how to integrate them with existing applications.
While the examples will be given using Resque, the ideas and patterns discussed will be applicable to other worker queues, such as delayed_job and Sidekiq.
It's been scientifically proven that more diverse communities and workplaces create better products and the solutions to difficult problems are more complete and diverse themselves. Companies are struggling to find adequate talent. So why do we see so few women, people of color, and LGBTQ people at our events and on the about pages of our websites? Even more curiously, why do 60% of women leave the tech industry within 10 years? Why are fewer women choosing to pursue computer science and related degrees than ever before? Why have stories of active discouragement, dismissal, harassment, or worse become regular news?
In this talk we’ll examine the causes behind the lack of diversity in our communities, events, and workplaces. We’ll discuss what we can do as community members, event organizers, and co-workers to not only combat this problem, but to encourage positive change by contributing to an atmosphere of inclusivity.
Educate about the lack of diversity and why it is a problem
Examine what is contributing to both the pipeline issue as well as attrition
Isolate what is and isn't working
Inspire direct action by examining our own behavior and learning more about the people around us so we can empathize better