Skip to content

Instantly share code, notes, and snippets.

@schneems

schneems/gist:36cf49832b16955ae428 Secret

Created January 15, 2014 03:37
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save schneems/36cf49832b16955ae428 to your computer and use it in GitHub Desktop.
Save schneems/36cf49832b16955ae428 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.md

Personally I can talk about deployment at Heroku and the Ruby buildpack (the code that handles setting up all Ruby apps for Heroku). Specifics:

Deploy speed

We've gotten Ruby deploys 40% faster (perc50) in the last few months. We're planning on blowing that number out of the water soon. I can talk about the tools and techniques we used to get this far. Some of them are abstractable to general public like how to instrument your code for visibilty, and shaving off time by doing less while caching more. Some are pretty specific to Heroku but intersting still for example we've optimized a few parts of our platform. One of the most impressive speed bumps comes from pre-installing some of the most popular Gems for our default Ruby version.

Upcoming changes to Rails 4.1

I've done a decent amount of work on Rails 4.1. Could talk about the giant bikeshed that is secrets.yml. All of the changes to DATABASE_URL support and how the future of Rails involves less injected magic needed to run Rails on Heroku.

I can also talk semi-indepth on sprockets. There's some user facing changes coming with 4.1.

Legacy app development and deployment

I can talk about my experience developing on the buildpack which is a legacy app. When I got it there were no tests although it was handling thousands of production deployments a day. Deploys of the buildpack were infrequent, and always very minimal. Since starting work on the app we've developed a comprehensive black box testing tool for the buildpack which allow us to refactor for speed, clarity, or to add features easier. We're gradually teasing appart 5 massive Ruby classes into many smaller worker objects, and then writing faster unit tests for those objects. The result is a better tested tool, that is faster and easier to develop on. Lots of people talk about doing this, but actually doing it and being able to point out specific examples is rare.

The Future

In the future, we're planning on launching a pretty large feature with an emphasis on performance, but as it's not yet launched I can't talk about it by Thursday :) Maybe when we get a little closer I can give you some more info and you can see

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment