Ruby developers have many great options for simply hosting their web applications. But what happens when your product outgrows Heroku? Managing your own servers can be an intimidating task for the average developer. This session will cover the lessons we've learned at Braintree from building and maintaining our infrastructure. It will cover how we leverage Ruby to automate and control all of our environments. Some specific topics we'll cover:
Orchestrating servers with capistrano
Using puppet for configuration management
Our cap and puppet workflow using git
How vagrant can provide a sane test environment
Some pitfalls you should avoid
We all know data is growing at a rapid pace and our ability to store it has become cheap. But what do we do with all this data? Do you feel overwhelmed with the infinite amounts of decisions you could make?
Big data was supposed to improve how businesses run, though in most cases it has complicated process. We have become apathetic to the amounts of data that are bombarding us.
This talk aims to help overcome this apathy towards the sheer amount of information out there. It will teach you how to come up with methods to finding metrics, and new dashboards specifically for your business.
We will talk about:
Backward induction, or goal based metrics.
Classification algorithms for making sense of data.
Graphing in higher dimensions.
By the end of this session, you will know how to be effective with data. You will understand how to find what you are looking for, how to classify it, and how to visually make sense of it all.
Building services and integrating them into Rails is hard. We want smaller Rails apps and nicely encapsulated services, but services introduce complexity. If you go overboard in the beginning, you're doing extra work and getting some of it wrong. If you wait too long, you've got a mess.
At Yammer, we constantly clean up the mess that worked well in the early days, but has become troublesome to maintain and scale. We pull things out of the core Rails app, stand them up on their own, and make sure they work well and are fast. With 20+ services, we've learned some lessons along the way. Services that seem clean in the beginning can turn into development environment nightmares. Temporary double-dispatching solutions turn into developer confusion. Monitoring one app turns into monitoring a suite of apps and handling failure between them.
This talk looks at our mistakes and solutions, the tradeoffs, and how we're able to keep moving quickly. Having services and a smaller Rails codebase makes for scalable development teams, happier engineers, and predictable production environments. Getting there is full of hard decisions -- sometimes we’re right, sometimes we fuck it up, but we usually have a story to tell.
Big team, small team. Huge company, tiny side business. No matter which, time is what you're short on. You're already using tools like Ruby and Rails to make more with the time you have. But what about non-web apps? What databases, development tools, and other libraries let you do more or do bigger things in less time?
Finding high-leverage tools is a handy skill. Once you've found a tool that is simple to use, performant, and reliable, you can use it all over the place. We'll look at four tools: Faraday, Celluloid, Metriks, and Pow. These will help us talk HTTP, write concurrent programs, instrument our apps, and set up apps quickly. We'll see how to use them for multiple applications, play to their strengths, and work around their weaknesses.
This talk is an exploration into five lesser-known things that Chef can be used for, or is capable of doing. Some of these features and capabilities are unknown by all but the most experienced Chef users. Some of them are anti-patterns but still really useful. And others give you additional flexibility for using Chef in your environment.
In-place File Editing for Greater Good
Use Chef's Built-in Version Matching
REPLs are fun, so Chef has one!
Take the Resource Collection for a Stroll
The Anatomy of Loading and Executing a Single Recipe
Tobi Lutke wrote the first line of code for Shopify nearly 10 years ago to power his own Snowboard shop. Two years later Shopify launched to the public on a single webserver using Rails 0.13.1. Today Shopify powers over 40k online stores and processes up to half a million product sales per day across the platform. Over 30 people actively work on Shopify which makes it the longest developed and likely largest Rails code base out there.
This is the story of how Shopify has evolved to handle its immense growth over the years. This is what getting big is all about: evolving to meet the needs of your customers. You don't start out with a system and infrastructure that can handle a billion dollar in GMV. You evolve to it. You evolve by adding caching layers, hardware, queuing systems and splitting your application to services.
This is the story of how we have tackled the various scaling pain points that Shopify has hit and what we have done to surpass them, what we are doing to go even further.
To keep doing what you love, you need to maintain your own systems, not just the ones you write code for. Regular exercise and proper nutrition help you learn, remember, concentrate, and be creative—skills critical to doing your job well. Learn how to change your work habits, master exercises that make working at a computer more comfortable, and develop a plan to keep fit, healthy, and sharp for years to come.
Data arrives in all sorts of forms, more and more today we are seeing data arrive in event-like systems: server logs, twitter, superfeedr notifications, github events, rubygems web hooks, couchdb change notifications, etc. We want to analyze streams of data, and find useful pieces of information in them.
In this talk, using an existing dataset, we will go through the process of obtaining, manipulating, processing, analyzing and storing a stream of data. We will attempt to touch upon a variety of possible topics including: differences between processing static datasets and stream datasets, pitfalls of stream processing, analyzing data in real time and using the datastream itself as data source.
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. DCOps can now take a networking device, rack it, cable it, power it on, and walk away knowing it will be provisioned quickly and correctly. We've learned a lot over the past year and feel we have some very valuable information to share with people regarding:
How to identify services in existing places
How to identify boundaries between services
How to ensure code matches language
Common mistakes when building services
What started with two brothers in the McKinney Public Library is now a world wide word phenomenon on multiple mobile platforms. We’ll look at how we have grown, the mistakes we made, and the changes we have made along the way:
Serving millions of players a day: Stats, stats, stats!
Working with constraints: * 1 service, 6 games (and counting) * Native clients means backward compatibility, ftw!
How do I know what to fix? Instrumenting and reporting on everything
Where is the data? Using the database, memcache, Redis to the fullest
What we did wrong? What we did right? What would we do differently?
Like REST itself, Hypermedia is one of those topics everyone is talking about but few understand. Many discussions on the topic devolve into chaos until someone screams out "Fielding, dang it!" in exasperation. Even more civilized debates have a healthy dose of "READ THE F-ING SPEC!"
API consumers don't care about your API, your architecture, or your specs. They just want your data. This talk aims to provide a real world perspective of Hypermedia and show why it matters as we walk through the evolution of the GitHub API and the design decisions behind those changes. We'll dive into HATEOAS, media types, HAL, Collection+JSON, link templates, and the growing landscape of Ruby libraries for making all that easier to implement.
We'll also look at the impact of Hypermedia on API clients and when it might not be the best design pattern.
Metaprogramming. It's awesome, right? Powerful? Maybe a little scary?
Let's kick things up a notch. If writing code that writes code is powerful, what's hacking the life of the programmer writing the code? That's got to be an 11 on the meta-meter. At least. We'll talk about some of the bad assumptions we've made, lies we've bought into, and why we have the most awesome job ever.