Pry bills itself as "a powerful alternative to the standard IRB shell for Ruby", and it ain't kidding. With integrated tools like Slop and Method Source, Pry is a full-fledged Swiss army knife of command-line kung-fu at your disposal.
But why stop there? With an architecture built for plugin extension, the limits of Pry are really only a reflection of the limits of your own imagination.
So come learn the basics of creating a Pry plugin as we dive into some of Pry's internals and walk through the process of creating a plugin that adds a custom command to the Pry CLI. Where you take it from there, only you know.
What trick do companies like Google and Heroku know about API development that you don't? How do they reduce the maintenance burden of maintaining client libraries while also making their server-side validation and response generation simpler? Schemas!
Whether you're building APIs for the public, for internal micro-service infrastructures, or even just consuming other's APIs, Schemas can make your life easier. This talk will break down the differences between Descriptive Schemas and Prescriptive Schemas, and when you might want to use each. We'll look at real examples of usage in the wild, and tips for implementing Schemas in your environment.
Code reviews are not about catching bugs. Modern code reviews are about socialization, learning, and teaching. How can you get the most out of a peer's code review and how can you review code without being seen as overly critical? Reviewing code and writing easily-reviewed features are skills that will make you a better developer and a better teammate. You will leave this talk with the tools to implement a successful code-review culture. You'll learn how to get more from the reviews you're already getting and how to have more impact with the reviews you leave.
Congrats! You've built the one API to control them all, and it's amazing. It's fast, well-architected, and Level 3 Hypermedia. However everyone is still using your competitors sub-par product... Why? We developers are lazy and you're making it hard for us to use. We're diving into your SDKs tests to solve basic tasks, your SDK + API errors annoy and don't help us fix our mistakes, and the lack of logical defaults leaves us playing parameter roulette.
Let's explore how to build API-enabled products that fellow developers will love using with great docs, tooling, support, and community.
Run your app faster, with less RAM and a quicker boot time today. How? With science! In this talk we'll focus on the process of turning performance problems into reproducible bugs we can understand and squash. We'll look at real world use cases where small changes resulted in huge real world performance gains. You'll walk away with concrete and actionable advice to improve the speed of your app, and with the tools to equip your app for a lifetime of speed. Live life in the fast lane, with science!
With the rise of client-side frameworks you might wonder if your days using Ruby are numbered. You came to Ruby for its expressiveness and beauty. You don’t want to leave that completely behind.
Luckily, you don’t have to. With a nod to the Single Responsibility Principle we all love, this talk looks at how to leverage a front-end framework like Ember.js to handle application state at the UI layer and leave Ruby or Rails to do what it does best — everything else.
Something to keep in mind: that everything else is the heart of your entire app.
Capybara has allowed us to build complex and ambitious applications with the confidence that everything comes together in the user experience we're targeting. As the capabilities of the web have grown, interactions and behavior in our applications have become more complex and harder to test. Our tests become coupled to CSS selectors, fail intermittently, take longer and our confidence dwindles. In this talk, I'll go over best practices for working with a large capybara test suite and dig into APIs and options we can use to bring back the confidence Capybara initially gave us.
Everyone keeps telling us that Github is the new resume. But we live in a world where there are -- literally -- millions of Ruby developers. Why do so few of them ever contribute code back? What could our community do if we moved that needle just a little bit?
The gap between “Ruby developer” and “Ruby open source contributor” is still distressingly large. All our recent efforts for better documentation and friendlier maintainers hasn’t helped narrow it as much as we hoped. It’s time to look at this problem in a new way: through our code. Using the RSpec codebase as a starting point, we’ll explore the invisible forces that create and maintain this gap in the face of all our efforts to close it.
We all know ActiveRecord allows you to perform complex SQL queries using simple, elegant Ruby code. It’s like magic, a useful magic we all use everyday in our Rails apps. But how does it actually work?
We’ll find out by first exploring the shallow waters just under ActiveRecord: What is relational algebra? How does the Arel gem generate SQL strings from Ruby objects? Later, we’ll dive into much deeper waters - all the way inside the PostgreSQL database! We’ll discover what does Postgres does with our SQL strings, where our data is actually located, and how Postgres finds what we want.
Join me and learn exactly how your Rails app gets the data it needs. Like the strange places and creatures Jules Verne described in his underwater adventure, we’ll discover fascinating data structures and computer science algorithms you never knew you were using.
Not all work can be done in-band. At some point, you need to run code asynchronously to better scale your system. There are no shortage of off the shelf job systems out there to make this easy, but they all make assumptions or have a certain view point that may not mesh well with your application. Sometimes you need to roll your own, and that isn't always a bad thing. But it's a decision not to be made lightly. In this talk, we'll go over why Tapjoy decided to skip an off the shelf solution, build something from scratch to fit their needs, and finally opening it up to share with the Ruby community at large. We'll go over the technologies we reviewed, why we settled on something custom, how we scale jobs, and some interesting lessons learned about jobs systems, monitoring, and bugs in Ruby itself.
We build web applications, but how do we really know they’re secure? You’re savvy, so you use SSL, bcrypt your passwords, use only key-based authentication, protect your admin passwords and accounts with solid password management, and generally follow the Rails Security Guide. So you’re safe right? Nope. There’s more. A lot more. In 45 minutes, You’ll be introduced to some of the most common attacks fraudsters and hackers use to break into your site. We’ll discuss some of the consequences of your web application being hacked and how to detect and prevent these attacks.
Change is a constant, though often we don’t build our team, technology or process for it. Instead of using it to our advantage we have to deal with it’s problems. I will go into detail on how change affects us and how we can find a way to visualize our ability to deal with change. Also techniques like letting your repository drive your infrastructure, using immutable components and how the Cloud affects our ability to deal with that Change.
Travis CI is a hosted distributed Continuous Integration service. In this introduction, Hiro Asari gives you an overview of the build system and its fundamental features.
This talk discusses Softcover, an open-source Ruby-based system for typesetting and publishing technical ebooks. We'll discuss the design of the core publishing system, which connects together a mix of Ruby gems, custom Ruby, and an underlying C++ parser to output high-quality ebooks. After a live demo of the ebook production system, we'll deploy the results to an integrated sales platform with a single command. We end with a discussion of how to use Softcover to build a product business based on the Ruby on Rails Tutorial model.
In this day and age, we have a thousand ways and reasons to test our code. On it's face, this is great! But the sword is double-edged: when I open a test that I'm not familiar with, I have to determine why it exists from any of a thousand possible reasons. If I want to add my own tests, I must decide how to implement it from any of a thousand possible methods.
The most immediate abstraction we have for wrangling the motivations and implementations of our tests is the "test suite". By cordoning off each group of tests based on the value we hope to get out of them, we can develop unprecedented clarity in our working relationship with tests.
This talk is an example of how to do that. Hopefully, it's at just the level of detail you'll need to ponder how to apply a similar approach to your teams and applications.
Rob will walk us through some of the work he's been doing with Ruby to manage some of the pieces involved in a Continuous Delivery environment.
As software systems become more complex, Service-Oriented or Microservice architectures become common. While these architectures have their benefits, they make building and testing your Rails application more complicated because of runtime dependencies. Chris shares his experiences building Rails applications in an SOA that keeps Rails development awesome.
Flo will show how to get started with Rails on ElasticBeanstalk with and without their new Docker support.
In this talk, Mike will show how you can use PageObjects to keep your Rails integration tests DRY, expressive, and more maintainable.
Learn how to lean on Rails conventions to architecture flexible and DRY CSS using Sass.
Jesse has been dealing quite a bit with Rails security issues recently and he will share some of his experience in this Lightning Talk.