GitHub loves Ruby. Many of our products, tools and infrastructure are built with Ruby.
In this talk, we will look at the libraries, practices and conventions that GitHub uses with Ruby. We will survey all of the repositories maintained by GitHub to get insight into how it is used, and we will also examine some of the areas where we opt to not use Ruby.
Someone once told me that software development is a constant battle against complexity. Over the past three years we've built several large systems at GitHub and if anything, that saying is an understatement. Things like tight coupling, insufficient testing or documentation, lack of versioning discipline, and underspecified design documents can easily lead you down a path of ruin. In this talk I'll cover many of the techniques we use at GitHub to defend against complexity in our Ruby systems, including Readme Driven Development, Semantic Versioning, TomDoc, Git/GitHub workflow, modularization, metrics, and exception reporting.
It has been said that software development is a constant battle against complexity. GitHub has built several large systems over the past three years, all while engaging in the proverbial battle against complexity. Things like tight coupling, insufficient testing or documentation, lack of versioning discipline, and underspecified design documents can easily lead developers down a path of ruin. This talk will cover many of the techniques GitHub uses to defend against complexity in Ruby systems, including Readme Driven Development, Semantic Versioning, TomDoc, Git/GitHub workflow, modularization, metrics, and exception reporting.
Tom Preston-Werner is a cofounder of GitHub, the social coding phenomenon that has captured the imaginations of hackers around the globe. He is also a serial entrepreneur having sold Gravatar to Automattic and run a web/graphic design firm, Cube6 Media, out of San Diego.z
When you type “cap deploy”, “ey deploy”, or “git push heroku master” your intent is to deploy your local application source to your running system on the Internet. That seems to be the point - you changed your code, and you want to Just Ship It. But what is your actual objective? Is it really to just “deploy app code changes”? Is this “app-centric” view and user experience satisfactory?
Code deployment is your intent on some occasions. On others you want to change your production environments for applications, or change scale attributes of your system, or change how applications and services within a system communicate with each other, or with remote services (such as facebook).
Is “app-centric deployment” the best mental model and toolchain for shipping changes to productions systems? Or is “environment-centric” or “node-centric”, enabled with frameworks like Chef or Puppet, the most powerful & effective model of the system to allow you to deploy and manage change?
Or perhaps we should describe the entire system - all the apps, all the system dependencies, all the interconnections, all the scale attributes - and command it to come into existence? To command the system to go from nothing to v1 to v2 to v3, where each version includes changes in attributes of the system.
Where should configuration/manifests/attributes go? Source code files in the config folder? PaaS configuration or environment variables? Or should components of a system dynamically discover information about itself and configure itself?
Perhaps we need the benefits of a “system-centric” build toolchain, with an “app-centric” user/developer experience to trigger deploys, with a “node-centric” experience for sysadmins.
In this talk, we will reflect on the current state of deploying production systems, including build/deploy toolchains, and continuous deployment. We’ll look at the attributes of a complete system, how we explicitly or implicitly describe them and their relationships, and how to orchestrate changes in the system - from app-centric, node-centric and system-centric views.
Let’s discuss the difference between deployment in month 1 and living with your system for the next 59 months.
If you've ever done anything in ruby, you've probably used rubygems and rubygems.org to search or install your favorite gem. On October 17, 2012, rubygems.org went down. A Dependency API was built to be used by Bundler 1.1+ to speed up `bundle install`. Unfortunately, it was a bit too popular and the service caused too much load on the current infrasture. In order to get rubygems.org back up the API had to be disabled. You can watch the post-mortem, http://youtu.be/z73uiWKdJhw, for details.
Members in the community stepped up and built a compatible Dependency API service called the Bundler API. Working with the rubygems.org team, we were able to bring the API up for everyone within a week. In this talk, I will cover the process we went through of extracting the API out into a separate Sinatra app that now runs on Heroku. I'll go over how the API works and how Bundler itself uses it. Since we don't have direct access to their database, we needed to build a syncing service to keep our local cache up to date. We'll discuss the original sequential implementation of the sync code and how we improved performance through the use of a consumer thread pool. The sync time down was cut from 16 mins to 2-3 mins. Next, we'll talk about the productization steps we took for visibility to make sure the app is performing well.
We're prototyping a replay service, to replay production traffic to different Heroku apps. With this we can compare the performance between the current MRI app in production and the same app running on JRuby. This will also allow us to test any changes/features against real production load. We'll go over how to set this up.
Messy code often begins with a simple "if". Continuing down that path is a road to ruin, but there's a simple way to avoid it. East-oriented Code is an approach that helps you follow Tell, Don't Ask. It guides you away from Feature Envy and toward better encapsulation. See before and after code and walk through easy to repeat steps that will make your Ruby programs better and easier to maintain.