Slide 1
Slide 1 text
from github’s codebase
Ruby Patterns
Slide 2
Slide 2 text
@holman
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
Like everyone, we have
some really dumb ideas.
Slide 5
Slide 5 text
But we have some
good ideas too! Honest!
Slide 6
Slide 6 text
So let’s talk about a few.
Slide 7
Slide 7 text
bootstrapping
making your app newbie-proof™
Slide 8
Slide 8 text
your company is going to have
TONS OF SUCCESS
which means you’ll have to hire
TONS OF PEOPLE
Slide 9
Slide 9 text
GitHub has 200+ repositories.
and 60+ employees.
and 20+ languages.
and about a billion egos.
Slide 10
Slide 10 text
It needs to be QUICK AND EASY
to step into an unfamiliar app
Slide 11
Slide 11 text
script/bootstrap
Slide 12
Slide 12 text
Most of our Ruby projects have a
file called in the
directory.
bootstrap script/
Easily jump into a project and start
contributing.
Slide 13
Slide 13 text
{
script/bootstrap
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
Slide 14
Slide 14 text
{
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
is mysql installed?
(here’s how to install it)
is redis running?
(here’s how to run it)
Slide 15
Slide 15 text
{
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
bundle install \
--binstubs \
--local \
--path=vendor/gems \
--without=production
Slide 16
Slide 16 text
{
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
rake db:create
Slide 17
Slide 17 text
{
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
rake db:migrate
Slide 18
Slide 18 text
{
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
script/replicate-repo
(see rtomayko/replicate)
Slide 19
Slide 19 text
{
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
404, 500
Slide 20
Slide 20 text
{
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
python, c, erlang...
Slide 21
Slide 21 text
{
static page compilation
language compilation
db seeding
dependency checks
bundler
db creation
db migration
t
Slide 22
Slide 22 text
cache bootstrap results
Slide 23
Slide 23 text
md5 << File.read('Gemfile')
checksum = md5.hexdigest
installed = File.read('.bundle/checksum').strip
Check if we need to bundle install
Slide 24
Slide 24 text
should be fast,
straightforward, and require no
knowledge of the underlying
language or app setup
script/bootstrap
Slide 25
Slide 25 text
You can also run
during any process that loads the
environment, like
script/bootstrap
script/server
Slide 26
Slide 26 text
You can do the same with your
testing environment, too.
Slide 27
Slide 27 text
Our CI server only needs to
ever run .
script/cibuild
We add to most
projects. Lets us keep test
config in the repository.
script/cibuild
Slide 28
Slide 28 text
{
script/cibuild
export RACK_ROOT=["..."]
export RACK_ENV="test"
script/bootstrap
bin/rake
Slide 29
Slide 29 text
QUICK AND EASY
Make sure your environment is
to set up.
Slide 30
Slide 30 text
conditional monkeypatching
just like a good rubyist
Slide 31
Slide 31 text
- GitHub is a Rails 2.3(ish) app
PROBLEM:
- Upgrading to Rails 3.x sucks
- Biggest concern is escaping-by-default
- We wanted incremental rollout
Slide 32
Slide 32 text
JOSH PEEK Yo let’s just make it
staff-only like
everything else we do
Slide 33
Slide 33 text
def enable_xss_escaping(&block)
if staff?
ActiveSupport::SafeBuffer.enable_escaping(&block)
else
yield
end
end
Slide 34
Slide 34 text
def enable_xss_escaping(&block)
if staff?
ActiveSupport::SafeBuffer.enable_escaping(&block)
else
yield
end
end
Slide 35
Slide 35 text
def enable_xss_escaping(&block)
if staff?
ActiveSupport::SafeBuffer.enable_escaping(&block)
else
yield
end
end
(#enable_escaping is just a patch on SafeBuffer)
Slide 36
Slide 36 text
Use Ruby’s strengths to limit your
liability during big code changes.
Slide 37
Slide 37 text
Also, use partial deployments to
further limit your exposure.
Slide 38
Slide 38 text
api design
github api v3
Slide 39
Slide 39 text
Sinatra is (naturally) great for an API.
get “/” do
“an web app”
end
translates
easily to
GET / HTTP/1.1
Slide 40
Slide 40 text
GITHUB API V3
~30 Sinatra apps
located in app/api in our Rails app
mounted at api.github.com/
(version in headers)
routed in rack with path regex
Slide 41
Slide 41 text
USE HELPERS, SIMPLIFY ROUTES
# List a user's followers.
get "/users/:user/followers" do
control_access :public_read
deliver find_user.followers.paginate(pagination)
end
Slide 42
Slide 42 text
USE HELPERS, SIMPLIFY ROUTES
# List a user's followers.
get "/users/:user/followers" do
control_access :public_read
deliver find_user.followers.paginate(pagination)
end
control_access
verifies user has permission for the request
pulls user data from currently-authenticated user
Slide 43
Slide 43 text
USE HELPERS, SIMPLIFY ROUTES
# List a user's followers.
get "/users/:user/followers" do
control_access :public_read
deliver find_user.followers.paginate(pagination)
end
find_user
auto-populated based on params[:user]
manages error handling for nonexistent users
Slide 44
Slide 44 text
USE HELPERS, SIMPLIFY ROUTES
# List a user's followers.
get "/users/:user/followers" do
control_access :public_read
deliver find_user.followers.paginate(pagination)
end
pagination
auto-populated based on per_page & page params
Slide 45
Slide 45 text
USE HELPERS, SIMPLIFY ROUTES
# List a user's followers.
get "/users/:user/followers" do
control_access :public_read
deliver find_user.followers.paginate(pagination)
end
deliver
handles nil objects (404)
appends OAuth scope & rate limiting headers
encodes as JSON and sets Content-Type
handles JSONP callbacks
Slide 46
Slide 46 text
USE HELPERS, SIMPLIFY ROUTES
# List a user's followers.
get "/users/:user/followers" do
control_access :public_read
deliver find_user.followers.paginate(pagination)
end
Slide 47
Slide 47 text
USE HELPERS, SIMPLIFY ROUTES
Extract all these little methods out
Your API becomes extremely
Your API becomes extremely
readable
testable
Slide 48
Slide 48 text
inner-app projects
for services that aren’t yet services
Slide 49
Slide 49 text
Big apps suck, services are great.
Slide 50
Slide 50 text
Single responsibility principle and all
that jazz.
But it’s harder to do!
LET ME JUST THROW
THIS IN THE MODEL!!!!!!111
Slide 51
Slide 51 text
Compromise: library-in-an-app
Slide 52
Slide 52 text
lib/#{project}
test/#{project}
Slide 53
Slide 53 text
INNER-APP README
GitHub displays READMEs for every
directory we find
Clear area to add documentation
Slide 54
Slide 54 text
Easy access to your models
y
Slide 55
Slide 55 text
(Potentially) easier to extract
Slide 56
Slide 56 text
TEST HELPERS
Separate your project’s helper methods
Fixtures, too
Slide 57
Slide 57 text
As you grow, it’s harder to mentally
grasp your entire app. Splitting into well-
documented chunks can really help.
Slide 58
Slide 58 text
github hd™
zooooooooooooooooooooooom
Slide 59
Slide 59 text
Okay this totally isn’t Ruby, but it’s cool.
Slide 60
Slide 60 text
⌘+ ⌘-
ZOOM IN ZOOM OUT
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 text
No content
Slide 64
Slide 64 text
No content
Slide 65
Slide 65 text
280px
120px
SCALE IN-BROWSER
Slide 66
Slide 66 text
This is great for iPhones and iPads, too.
Slide 67
Slide 67 text
documentation
really doesn’t have to suck. honest.
Slide 68
Slide 68 text
As you grow larger, it’s harder to
understand your entire app.
(I’m totally a broken record)
Slide 69
Slide 69 text
DOCUMENTATION!
TO THE RESCUE!
Slide 70
Slide 70 text
We TomDoc the
shit out of everything
Slide 71
Slide 71 text
Pretty much every method has 3-6
lines of documentation
Slide 72
Slide 72 text
Sure, you can laugh.
But working on highly-documented code is
AMAZING.
Slide 73
Slide 73 text
...particularly in Ruby, because following this sucks:
def mailing_address
full_name + “\n”
street_address_1 + “\n” +
street_address_2 + “\n” +
“#{city}, #{state} #{zip}”
end
def street_address_1
house_with_street.formatted
end
def house_with_street
StreetAddress.new(data)
end
Slide 74
Slide 74 text
Debugging a STRONGLY DYNAMIC
METAPROGRAMMING-HAPPY
FLEXIBLE LANGUAGE is hard.
Slide 75
Slide 75 text
SPEC:
TOMDOC
GOAL: internal API documentation for
your developers
tomdoc.org
(generated docs not a priority)
Slide 76
Slide 76 text
# Cures cancer. Beware of race conditions or else you’ll turn into a
# newt or something.
#
# options - A Hash consisting of:
# age - The Integer age of the patient.
# money - The Float amount of money in the patient’s account
# valuable - A Boolean value of whether the patient is valuable
# to society or not.
# rollback - A Boolean of whether we should troll the patient and give
# cancer again once they’re cured.
#
# This returns a Patient record. Raises UncurableError if the patient can’t
# be cured.
def cure_cancer (options, rollback)
# boring implementation details, you can figure it out yourself
end
Slide 77
Slide 77 text
# Cures cancer. Beware of race conditions or else you’ll turn into a
# newt or something.
#
# options - A Hash consisting of:
# age - The Integer age of the patient.
# money - The Float amount of money in the patient’s account
# valuable - A Boolean value of whether the patient is valuable
# to society or not.
# rollback - A Boolean of whether we should troll the patient and give
# cancer again once they’re cured.
#
# This returns a Patient record. Raises UncurableError if the patient can’t
# be cured.
def cure_cancer (options, rollback)
# boring implementation details, you can figure it out yourself
end
Slide 78
Slide 78 text
# Cures cancer. Beware of race conditions or else you’ll turn into a
# newt or something.
#
# options - A Hash consisting of:
# age - The Integer age of the patient.
# money - The Float amount of money in the patient’s account
# valuable - A Boolean value of whether the patient is valuable
# to society or not.
# rollback - A Boolean of whether we should troll the patient and give
# cancer again once they’re cured.
#
# This returns a Patient record. Raises UncurableError if the patient can’t
# be cured.
def cure_cancer (options, rollback)
# boring implementation details, you can figure it out yourself
end
Slide 79
Slide 79 text
# Cures cancer. Beware of race conditions or else you’ll turn into a
# newt or something.
#
# options - A Hash consisting of:
# age - The Integer age of the patient.
# money - The Float amount of money in the patient’s account
# valuable - A Boolean value of whether the patient is valuable
# to society or not.
# rollback - A Boolean of whether we should troll the patient and give
# cancer again once they’re cured.
#
# This returns a Patient record. Raises UncurableError if the patient can’t
# be cured.
def cure_cancer (options, rollback)
# boring implementation details, you can figure it out yourself
end
Slide 80
Slide 80 text
# Cures cancer. Beware of race conditions or else you’ll turn into a
# newt or something.
#
# options - A Hash consisting of:
# age - The Integer age of the patient.
# money - The Float amount of money in the patient’s account.
# valuable - A Boolean value of whether the patient is valuable
# to society or not.
# rollback - A Boolean of whether we should troll the patient and give
# cancer again once they’re cured.
#
# This returns a Patient record. Raises UncurableError if the patient can’t
# be cured.
def cure_cancer (options, rollback)
# boring implementation details, you can figure it out yourself
end
Slide 81
Slide 81 text
# Cures cancer. Beware of race conditions or else you’ll turn into a
# newt or something.
#
# options - A Hash consisting of:
# age - The Integer age of the patient.
# money - The Float amount of money in the patient’s account.
# valuable - A Boolean value of whether the patient is valuable
# to society or not.
# rollback - A Boolean of whether we should troll the patient and give
# cancer again once they’re cured.
#
# This returns a Patient record. Raises UncurableError if the patient can’t
# be cured.
def cure_cancer (options, rollback)
# boring implementation details, you can figure it out yourself
end
Slide 82
Slide 82 text
# Cures cancer. Beware of race conditions or else you’ll turn into a
# newt or something.
#
# options - A Hash consisting of:
# age - The Integer age of the patient.
# money - The Float amount of money in the patient’s account
# valuable - A Boolean value of whether the patient is valuable
# to society or not.
# rollback - A Boolean of whether we should troll the patient and give
# cancer again once they’re cured.
#
# This returns a Patient record. Raises UncurableError if the patient can’t
# be cured.
def cure_cancer (options, rollback)
# boring implementation details, you can figure it out yourself
end
Slide 83
Slide 83 text
DON’T WORRY, IT’S NOT VERBOSE:
Most of your TomDoc will only be two lines:
# EXPLANATION
#
# RETURNS
Complicated methods (like the previous example)
will require more detailed TomDoc.
Slide 84
Slide 84 text
IT’S FLEXIBLE:
Document as you see fit; it’s a loose spec.
Slide 85
Slide 85 text
IT’S ALWAYS UP-TO-DATE:
If you update the code, update the fucking docs.
Slide 86
Slide 86 text
IT’S OUTRAGEOUSLY HELPFUL
Humans will always read English easier than code.
Slide 87
Slide 87 text
IT HELPS WITH TESTS
You’re detailing input + output already.
Slide 88
Slide 88 text
TOMDOC IS NOT REQUIRED
If you don’t dig TomDoc, choose something to
document your code.
Slide 89
Slide 89 text
LONG-FORM IS GREAT TOO
Inner-app READMEs, wiki entries, internal posts.
Slide 90
Slide 90 text
DOCUMENT EVERYTHING
DOCUMENT EVERYTHING
— no, really —
Slide 91
Slide 91 text
beware novelty
custom vs. stock
Slide 92
Slide 92 text
GitHub has opinionated employees.
Slide 93
Slide 93 text
Custom hacks become difficult to
deal with as you grow larger.
Slide 94
Slide 94 text
jump to Rails 3.x
speed of new hires
possible reliability
IMPACTS OUR
Slide 95
Slide 95 text
“Doing It Yourself” isn’t wrong
...but be wary of the implications.
Slide 96
Slide 96 text
maintainability,
A lot of this is focused on
especially as you grow.
Slide 97
Slide 97 text
Technical scaling is sometimes
easier than organizational scaling.
Slide 98
Slide 98 text
Keep that in mind as you build
your Next Big Thing.
Slide 99
Slide 99 text
Thanks.
Slide 100
Slide 100 text
Zach Holman
zachholman.com/talks
@holman