

Ruby Patterns from GitHub's Codebase - nephics
http://zachholman.com/talk/ruby-patterns

======
johnbender
I was under the impression that the good folks at github were using Vagrant in
some capacity. Assuming they've used it or heard of it I'm wondering if/how it
fell short for their server based projects.

~~~
heretohelp
I don't know Github's reasons, but I can tell you mine!

Unnecessary statefulness for what should be a script sucks.

Running a whole VM just to run an app is immensely irritating.

Also, Vagrant breaks in the same ways the usual bundler mess breaks as well.

~~~
larrywright
I'm not sure what your opposition is.

It probably depends on what you're doing, but I've found Vagrant extremely
valuable for doing sysadmin work. I do a lot of work with Chef for various
clients, and Vagrant makes it trivial to test. From a clean Ubuntu or CentOS
VM to a running system in a few minutes. I could see a lot of benefit to using
this for application development and testing as well.

~~~
johnbender
This was the original reason that Mitchell and I started the project. We were
Rails consultants at the time who just got sick of juggling application
environments.

------
netmute
I really miss his videos. Looking at slides without any commentary isn't that
interesting.

------
whatthefunk
Regarding the part where you say "document everything". I'm assuming you come
from a mid-sized company standpoint where there is more than 1 person working
on the app. I might be wrong but I think documenting everything from the start
is counterproductive.

~~~
crymer11
Curious as to why you think documenting everything from the start is
counterproductive. Are you opposed to documenting everything or documenting
from the start, and why?

I mean, I hate writing documentation, but as someone who has had to come back
to code I've written months prior (and I was the only one to work on the
project), let alone code someone else wrote, I'm incredibly grateful when I
look at old code that's actually documented. Plus I feel that writing a couple
lines of documentation helps me figure out exactly what I want the code to do.

~~~
whatthefunk
True. I have been in that situation too. Although I also have some cases
wherein I thought prototyping something up to a point to prove it's worth is
not subject to "document everything." I guess my question now is, is it better
to do it from the very beginning knowing this fact?

~~~
crymer11
Since I think accurate, up-to-date documentation is as important as existent
documentation, I'm inclined to believe that documenting everything doesn't
have to be started at the beginning, but I know the longer I put it off, the
less likely I am to actually write it. I've been trying to document my code as
soon as I have a good idea of how the function, method, etc. is going to work,
which sometimes is before I write any code, sometimes after I'm finished, but
usually as I'm writing it.

------
mc
Any examples of library-in-app in the wild. I get the idea, but want to know
what this looks like in practice.

Mounting engines or Sinatra apps? Creating a new gem to for extractable
functionality? Just curious about what this looks like under the hood.

------
aakashd
I don't agree with code is not readable. If the code is not readable, you
really need to look at your naming conventions and abstractions.

Using documentation as an alternative to readable code is a pitfall.

------
jamesgeck0
Could you give more detail about how you use inner-app services? They seem
like a good way to manage project complexity, but I can't find much
documentation on how they work in Rails.

------
tabbyjabby
Do your Sinatra apps have access to the Rails models?

~~~
baghali
I don't know what github is doing about their models, but I have fairly easy
solution of my own: I always symlink models in my projects.

We have 2 large Rails projects and an API server using Goliath[1], one of the
Rails projects and the goliath server use models with symlinks.

[1] Goliath: <http://postrank-labs.github.com/goliath/>

~~~
bretthopper
Why not package them as a gem?

~~~
baghali
We are still doing massive development, once our codebase is stable enough we
will move them into small gems, right now it's just a bit of hassle running
bundle update for every small increment.

~~~
heimidal
You can plan this migration ahead of time by moving your models into gems
stored in, say, vendor/future_gems/. Then just reference each gem in bundler
as:

gem "my_models", path: "vendor/future_gems/my_models/"

Once you are able to break them out completely, just remove the path reference
and use a gem server instead.

