The Rogues talk to Github's Zach Holman.

Special Guest: Zach Holman.

 

That’s how you’d be an expert, though. You only talk about stuff that you know; not about the stuff you don’t know.

Darn it. We’re doing it wrong!

Hey everybody and welcome to Episode 84 of the Ruby Rogues podcast. This week on our panel, we have Josh Susser.

Hey, good morning everyone!

James Edward Gray.

We’re recording this episode on what’s likely the last three digit date in my lifetime. Not three digit, three repeated number date – 12-12-12.

Katrina Owen.

Good evening.

Avdi Grimm.

Good morning.

I’m Charles Max Wood from www.devchat.tv and this week, we have a special guest – it’s Zach Holman.

Good morning.

Now, David Brady is out this week. I’m the only one that can really make this joke; but he is out courting his third wife. So… [laughter]

Is that like the standard thing to call in sick when you live in Salt Lake City?

Or you live in Utah? [laughter]

Oh yeah. He’s been pretty sick for the last four or five days. So anyway, he’s sitting out this episode.

So who is this Zach Holman guy?

Wait. Let’s do Best of Parley.

I'm so confused. Okay, what’s the best of Parley this week?

You’re confused. The whole good evening/good night thing broke my brain.

It’s almost like we’re in a planet where different people live in different zones where the time is different.

It’s so confusing.

I can imagine.

Katrina, hurry up and move to the U.S.

I'm working on it.

Okay, alright. So, Best of Parley this week. There were actually multiple threads along the lines of ‘How do I get Ruby into my .NET shop?’ or something similar like that and into an environment where we’re not using it heavily. And that’s cool because really, I have no idea. I know pretty much nothing about that. But the cool thing about Parley is there are so many people on there that are doing it. You get your questions answered anyway. That’s cool stuff.

The fun thing about that thread for me was it was like a flashback to the ‘80’s and listening to conversations of people trying -- you know, talking about trying to get Small Talk intoCobol organizations.

Nice. So yeah! There’s always something interesting going on Parley even if we don’t know about it.

Yeah.

Yeah. Is somebody going to try and take over Ruby Rogues Parley and make it Python or something?

Actually, I believe we’re moving Emacs.

Emacs. [laughs]

Emacs Parley. That’s it.

Oh there we go. All right. One other thing I want to quickly remind everybody of is the Ruby Bits course. You can go get it for free at RubyRogues.com/RubyBits. This episode will come out probably toward the tail end of when you can get it for free. After that, you’re going to have to sign up for Code School to get it. So if you want it, go get it today. Was there another announcement or are we just ready to jump in?

We’re ready. Back to who is Zach?

One other thing I want to remind everybody of - Book Club. The Book Club book is Sandi Metz’s

Practical Object-Oriented Design in Ruby. And we’re going to be reviewing that with her on January 2nd. So, that means that if you want to have the book read by the time we get around to doing that, then you probably need to have it read by around January 9th because that’s when the episode will be released.

Or you could read it beforehand and ask us -- put in your own requests for questions and topics on the air.

Absolutely. We’ll probably actually open up the discussion for questions on the Parley list. So, if you want the inside track on that, then go sign up for Parley. And you can do that by going to the website and it’s in the sidebar on the right.

Don’t we have a page for that yet?

Not yet. I am working on it.

Okay, cool. We’ll have a page for that sometime soon.

Someday…somehow…

[chuckles] Okay. So, hi Zach. Who are you?

That’s like the third time it’s been asked. I kind of just,we should just keeppeople in suspenseand never introduce me. [laughter]

Maybe at the end of the show: So who were you who we talked to here?

Who's that Zach guythat has been on the call the whole time?

So which employee number at Github are you?

Number nine.

Oh, that’s pretty low.

It's not bad.

How many employees are there now?

We’re like at 140, something like that.

I didn’t realize it was that big.

So, more important question. Which user number are you on Github?

I'm like 2,000 something.

I got you beat there. I'm like 153.

Oh, I can change that. [laughter]

I would appreciate a single digit user number.

Correction. You were 153.

Now,I'm 2,000. [laughs]

So Zach, tell us about what you’ve been up to at Github lately? What are you working on?

Man! This year, I’ve been doing a bunch of talks, a bunch of travelling doing conferences and that whole bracket. I'm hoping next year, I can actually sit down and build some product again rather than talk about it, actually do things a little bit more.

So you’re the PR team.

Oh God! I guess. [laughs] [laughter]

Someone called me a developer evangelist at some point and it kind of frightened mebecause it’s just so weird, you know. It’s creepy.

I know what evangelists are. They walk around with books of Mormon and wear white shirts and ties, right?

That’s pretty close to what my day-to-day is.

Wasn't Guy Kawasaki the first developer evangelist?

I don’t know.

I think they may have invented that title for him at Apple way back in the ‘80’s.

Interesting.

And he’s done quite well with that.

So Zach, you didn’t have anything to do with newly-released gists, right?

Yeah, that was all me, front-end, back-end….

I'm just kidding. No, not at all.

All the bugs.

No, those were somebody else’s.

But can you at least tell us about the cool technology it’s built on?

Sure. So I don't know if you notice this, but gist lookedhorrible for, I don’t know, five years, pretty much. So this has been kind of our big redesign. For those time-shifting this podcast,gist wasrelaunched yesterday. Sogist has sort of beenthe redesign, we started fresh and built it all upfrom the front-end differently and in the back-end, it is completely new too. We’re using libgit2 as the core of all of our git stuff. Previously, we used grit, which is sort of our Ruby-based git adapter whichtalks to git for us. Now all this is libgit2 via the use of the rugged gem which is much faster, much cleaner, much fewer bugs hopefully.

That’s cool.

The only thing I noticed is it’s pretty.

Well, that helps too. [laughter]

Does rugged and libgit2 make it prettier?

Makes it pretty fast.

I like fast.

No, it’s mostly just a way of -- libgit2 is our open source C project we’re helping with. So that is pretty much available in every language at this point. It’s just a very nice, clean, adapter rather than -- Grit was sort of we built out over the years and kind of threw everything into it. And it was slow and chunky and…

That’s been like that’s a five year-old project at this point.

Yeah. I mean, it pre-dates Github by two weeks, I think.

[laughs] Yes. I think I remember the first presentation on it way back when -- I said, “Oh, this is cool!” But so libgit2 it’s all on C, it’s open source, it’s super fast. Anything else to know about it?

What’s thisstack youbuilt on top of it? You said rugged and [crosstalk].

Yeah, the core of it is libgit2, which is written in C and then rugged is our Ruby Gem accessing C directly. And then on top of that, internally we have something called Git RPC which is sort of our networked Git layer. So it helps us run all this Git commands on all of our, I guess, 50 - 60 some servers at this point, just to sort of handle...it handlesa lot of the caching and stuff, so you don’t have to inefficiently query a bunch of Git stuff over the wire back and forth. Things like that.

So, Zach you talked about this kind of replacing Grit, does that mean we’re going to see Github the proper site go through that change as well?

Yes. It’s going to be a long process, but we’re starting on it now. Last week, I guess, we launched the file attachment stuff. Or no, well we launched that too, but the new file stuff where you can click onrepo, then create a new file straight from the web interface,that was the first use of Git RPC and Rugged in github.com proper. And now, we’re starting to go backand replacing some of our really low-level objects and replacing that with Rugged and it’s going to be a slow piece-by-piece process. But by the end of it, hopefully, I mean, some of the stuff that Rugged can do is justorders of magnitudesfaster than how we were doing it in Grit. So that’s going to be awesome.

Are we talking months or years?

At least number of months. It’s just -- I mean, Git is sort of all over our code base at this point and all of the Grit calls and stuff like that. And there’s some stuff we can just sort of swap out but you don’t want to do that overnight becauseyoucan really mess up a bunch of stuff that takes a long time to piece back together. Hopefully, by the end of the year maybe, itwould be nice to have a whole bunch of stuff switched over. Hopefully sooner than that but it's one of those thingsthings that you kind of have to go piece by piece and see how fast it goes and what problems it causes us.

So is the main -- I mean, is the main driver behind this the performance? And is there any real savings that you guys get money-wise as far as your hosting costs going down because it’s more efficient memory-wise or something or it's faster or what?

Faster probably means we can do more with less. And definitely in terms of like Git RPC will let uscache a lot of operations a lot smarter so we don’t have to do as much work on our actual servers. So, the main reason is not necessarily money. It’s much more about having a clean interface rather than some sort of all-over-the-place crazy code. Like some of the actual Grit code we have right now, it’s just a mess because it’s just been added on and added on and added on over the last five years. So having sort of a nice, well-tested library is going to be great. And the other cool thing about this is, since it has adapters onso manydifferent languages, we started out by putting it into Github for Mac through the libgit2Objective C stuff, and then Github for Windows is almost entirely based on libgit2, I believe. So it’s kind of nice so you can see bottlenecks and other places before we end up seeing them on github.com and get them fixed and pushed upstream and stuff like that.

Are there any features that this is going to? Because it sounds like most of this is kind of on the backend and it’s not stuff that we’re going to see. Is this going to enable any other features that we haven't yet seen on Github that we’re going to be able to use?

It’s going to probably enable us to do cool stuff but probably not through the protocol itself. I think the idea is that the libgit2 team wanted to be sort of have feature parity with Git proper by the end of the year. So that’s sort of the first stepping stone of ‘Can we get to what the normal Git binary can give us’? And then once we do that, maybe they can start looking at different ways of accessing information that’s a lot quicker or maybe there’s some other cool stuff you want to build on top of it. There are a few things that are really difficult right now. And Git,though it wouldbe nice if we sort of owned the whole and then stack where we could sort of optimize for the case of we have X million users accessing a repo. Maybe it’s quicker and better to just stash this some other place. Stuff like that is probably going to be the big win instead of really crazy user features.

Okay.

I'm curious if this will make calculating my network graph go faster.

Yeah, the network graph is interesting. That’s all I'll say about it. I don’t know. It’s an interesting piece of code.

Where do you access that? Or is that something that’s done through the API?

The network graph itself, from our perspective?

It's in the UI, if you [crosstalk].

Yeah, it’s on the UI page, Chuck,if you just go to some repository and click like the network tab, I thinkit is, or something.

Oh, I see; where it shows all the branches and stuff?

Yup.

Okay.

It’s a good idea. My guess, we’ll probably replace that with something a bit more useful at this point because it’s just, especially if you have a big active repository, that just becomes really crazy, really fast.

It’s time to update to use D3. [laughter]

We can do that for all our other graphs and stuff. All those got swapped out for D3.

Oh, pretty cool.

Yeah.

So the first of the graphs is the last one to use the old style.

Maybe. I mean, we ditched the impact graph. I think that may have pre-dated network graph. I don’t know. I mean, that stuff has been in there for four years or so at this point.

Or maybe five. I think it was like 2007 that I remember Tom showing off that first network graph stuff.

But Github didn’t launch till 2008.

Well, maybe it was around 2008. I'm not sure. [laughs]

Well, they were definitelyhacking on stuff earlier. Or at the late end of 2007.

Yeah, yeah. We used to see stuff before things got to the public--way back when.

When you’re as old as Josh, things just tend to run together, right?

There is that. It’s like I always confuse Zach with at least eight other Ruby developers. [laughter]

Hopefully they’re all good. But no, I’ll take it. That’s fine with me.

Sure, we’ll go with that. [laughter]

Okay, so one thing we wanted to ask you about Github was how Ruby fits into the sort of polyglot ecosystem of all the different programming languages there. I think you said you used something like 42 different programming languages to implement Github?

Yeah, maybe. We used a bunch at this point.

All of them, I think was the quote.

All of them. Yes, every single language. I don’t know. It’s -- I can’t remember it. I think Icounted this upat some point. But we used a whole bunch of different things. Ruby is sort of our default just because that’s what the founders sort of used and that’s where Github.com was created and everything sort of stems from that. But I mean, we dropped on toC a whole bunch for different performance reasons. We have a whole bunch of Java. The closest thing to Ruby is probably JavaScript/CoffeeScript where everyonecan sort of jump in and hack onqueuebot or a couple otherapps we have. But other than that, Ruby is kind of the tried and true thing that we can always go back and rely upon.

Are you using Erlang for RPC or anything like that?

I forgot what the state of Erlang was. Erlang used to route different requests and stuff on our backend service to theappropriate server. And at some point, I think that just got replaced by Unicorn which is kind of a ridiculous abuse of Unicorn and I love it. It just handles all that stuff like a champ. I think that may mean -- I think that (I haven't looked into this stuff in awhile, obviously) But I think that replaced all use of Erlang. We’re trying to get Erlang back in some of the Github pages stuff, but we’ll see when it actually ships. But yeah, we used Erlang for a number of years.

That’s cool. So did different developers like specialize in different languages or just kind of things people pick up on the side or how does that work?

Yeah. People just have weird backgrounds sometimes. Like, I'm not even talking about languages, people are just weird here. And it’s kind of cool to get like diverse backgrounds like somebody maybe. I don’t know. Some weird academic in some specialized field or something. But I mean, definitely different languages get used. Maybe not necessarily in production, if it doesn’t make sense, but it’s kind of nice where if you are learning a particular language and you want to know more, there’s probably someone else you can ask and sort of pair with and learn more about it and then eventually, you know.We’ve had a number of cases where someone’s really interested inNode a few years back. So they'd hackon a couple of side projects and then eventually before we know it, we have a bunch ofNode appsrunning in production. So it’s kind of a nice little way to go from 'I'm curious about this' to 'let’s ship it live.'

You talked about ‘let’s ship it’ and you actually told us before the call, that you had been using the new Gist for a while and it was nice that is was now finally public. Tell us how that works.

That’s sort of our philosophy overall,is we’d rather get stuff out to put on correction as soon as possible, at least for staff only or in that, at least for yourself. And that’s just all handled with really dumb conditionals like...stuff like that. And the reason behind that is partially technical. We don’t have to deal with really hairy merges and trying to go back and forth between masteringyour future branch which has helped us in a lot of ways. Like the Issues2.0 launch, we did two years ago at this point, Kyle launched that on stage in a lightning talk and that seems kind of crazy to just sort of say like, “Yeah, it’sdeployed now for real...like, something that big.” But it doesn’t really matter when it’s been deployed for us internally, pretty much since the inception for like three or four months. Sothat just makes it really easy to not have to deal with, like, a really scary launch. And then the other thing is just, it gets real world feedback really early. So we’ve had Gist running internally since probably at least the summer. And it lets people use the new Gist internally and share Gist that way and you end up catching just a whole bunch of bugs that you normally wouldn’t otherwise catch because everyone’s had the time where you deploy some app and you think something is really good idea and then you go back and, a month later, you're like"this is the dumbest idea ever.

Why would we ever possibly shift this?" And we just take it out and shift something else.

You guys build quite a few internal tools, right?

Yeah, tons.

And those too can pop upin like any language and stuff?

Usually. If we’re doing mostly web stuff, it’s mostly going to be Ruby. We used to do a bunch ofSinatra apps because we had a whole bunch ofSinatra creators and maintainers on our team. And I think we’re now, just sort of end up doing Rails for everything because it’s easier and you have less stuff to learn. And then, that’s also where we get all of our internal apps running on. It’s just like kind of the Ruby Rails standard.

That’s cool.

Now, the internal tools, is that just things that pop up as people see a need for it or do you have -- I know Square was doing their hack week this week and just everybody takes time off from their regular deliverables to go crazy and dream up new stuff. And I’m told that the Square Walletstarted asone of those projects, so it’s pretty productive for them to come up with new product ideas and things that way. Do you guys do something like that at Github or is it just that way all the time?

Yeah. It’s definitely that wayall the time. Like we kind of laugh at -- the running joke is ‘Google is 20% time’ and we just call it 100% time because you want to work on interesting stuff that is kind of relevant towards your particular perspective on stuff and that’s been really amazing for us. Looking back, if you lookat some of the internal, you know,side projects that peoplehave builtbecause they said, “Hey, our current X sucks.” Everything that hasstemmed from that likeHughBot, our Chatbot, stemmed from that, our whole crazy CI infrastructure, deployment infrastructure, that all stemmed from people just saying, “Man, this kind of sucks. I'm going to take time away from my “actual work” in order to work on this, eitherbecause it’s fun or it’s interesting or I think it’s relevant to the company. And now, we just have this crazy infrastructure that means we can deploy to everything with very zero interaction with CI, like, it’s all very automated and that’s really awesome. Looking back, it’s not really waste of time at all, which is really cool.

So one thing I'm kind of wondering about then is, is there an overarching direction that you’re trying to go in as far as the company goes or does everybody just kind of add in what they think it needs?

A little bit of both. I think people have a pretty solid vision of where we want to go. Weget that just from constantly discussing crap all the time. We do a bunch of high-level vision stuff; like twice a year, we get the whole company together and talk about like, “What do we want to do in the next six months, the next 12 months?” I think that really helps people with sort ofthe direction you want to go in. It’s not just kind of like, “Well, you know, we’ll do whatever today." And then sort of -- the reason why that works, I think, is that there’s a very strong culture of like ‘I'm going to show everyone what I'm working on early, and if people don’t like it, they can just tell me no’. And I haven't lost a lot of time and it’s not like some big traumatic thing if someone says, “No, I don’t this works.” Then I can just move on to something that does work. And that culture really works well for us.

Do you find that your developers aregood at doing that? Like, I know a lot of developerswho, they get attached to their idea, or they can’t let it go, like I know that sometimes I'll hear someone say something like, “Oh, it’s 200 lines, so if we haveto throw away the whole thing, who cares?” And I always think, “Wow, good for you.” I think it’s hard to think that.

Yeah, it’s much more of a human problem than anything. It does kind of suck if you’re really tied to an idea or a feature or a bug or whatever you’re working on, and someone says ‘no’. And it’s much more a matter of we try and stress that ‘it’s best argument wins’. It’s the phrase people end up saying. And it should be that if a lot of people are saying, “No, this doesn’t work.” That should be a sign that it probably doesn’t work. But you still have to sort of be cognizant that it’s -- it’s kind of a personal thing sometimes. And you don’t want to just be a jerk to your fellow co-worker.

Right, yeah. That’s good, though. It probably fosters better communication than the process, I

would assume.

Yeah, hopefully.

Very cool. So James, I think you have a whole long list of questions.

[chuckles] How about Gists [inaudible]?

I have a few questions about Github and how they use Github. Because I'm assuming that Github itself is hosted on Github.

Yes.

Do you guys use the main [crosstalk]

That's actuallyone of Zach’s talks. I think that’s the first time I ever saw him live. He gave a talk, ‘How Github uses Github tobuild Github’.

That was a lot about, like, pull requests and code reviews, right?

Yeah. A lot of that sort of stuff, and kind of theinternal shipping stuff to staff and things like that.

So which version of Github do you guys dogfood? Do you do the public Github or do you have an enterprise Github set up for your own internal use?

I can't remember what the enterprise team is doing now. I think the idea is that they are dogfooding enterprise at this point. If they aren't doing it now, that’s the goal is to get them on their own enterprise instance and get them working on that.

But in general, the team is on the public Github?

Yes, more or less. We have -- if you enable staff mode, we have tons of stuff running concurrently that-- it’s sometimes a weird thing tobelike "what’s actually deployed and what's not?"

And how do I enable staff mode?

You talk to me and we’ll see if we can hire you. [laughter]

Does the dogfooding include when the server goes down, everyone pops on to Twitter and complains about it? [laughter]

No, we see enough of your complaints already. [laughter]

Good answer. I did see something cool the other day, speaking ofoutages:you guys justshipped, pretty recently, a newstatus API for checking on status and stuff. And the reason I took note of it is it has an optional hypermedia angle to it. So, you can either just hit the URLs you want directly, if you just want to use it more like a traditional API. But if you want to go the hypermedia, route, you can hit like the top-level, and it will give you the list of what’s available on and you can follow these links and stuff. It’s pretty cool.

Yeah. We’re probably going to end up doing a lot more of that in the API proper. There’s some cool exciting -- I'm not an API geek, but for those of you who are API geeks, which, I love you guys to death,I just can't get into hypermedia stuff like that. But we’ll probably end up doing a lot more of that in the Github API proper. It’s kind of cool.

That is cool. I actually -- I just read like Steve Klabnik’s book a few months ago or something. I got totally hooked on it now. I'm just like bubbling hypermedia API’s for everything. It’s cool.

You said earlier that Github isstill running on Rails 2.3.

Mm-hmm.

Yeah, but it’s more like the Back to the Future time machine: It’s a Delorean on the outside. [laughter]

But it’s the Enterprise D on the inside.

So, if it’s aDelorean on the outside and the Enterprise D on the inside, then it’s bigger on the inside. That makes it a Tardis, right?

I like where you’re going with this. Can we somehow fit The Death Star in there too?

Something, something. Mary Poppinsis a time lord. [laughter]

Tell us about your Rails 2. Geez! Old and busted! I don’t know.

Oh, c’mon! It’s not old and busted. This is...

Old and fast.

Yeah.

If you did that, that will be amazing, by the way. Iwould just be impressed. CHUCK: We do have him on call.

He does not take my calls. [laughter]

Just in terms of the 2.3 stuff, we’ve always kind of been, I guess, slow to uptake just because there’s a lot of code in Github and swapping that stuff over to 3X would be -- it’s...We’ve had a branch going for 1.9 and for 2.3, 3.1, 3.2. We’ve had those branches running for at least two years now. It’s like people would do the big things and then -- it’s just we didn’t have enough motivation to make the big swap over. I think that’s kind of the scariest thing for us is that -- I mean, look at the Rugged stuff, the libgit2 stuff. That’s like the core of our entire site. And the reason why that’s fine is because we can swap it over method by method and not completely destroy everything.And switching over to Rails method by method doesn’t really work. So we’ve been very cautious about that. We’re kind of skeptical of the performance that you take with AR3. So instead, we have our own asset pipeline in 2.3. We have the escape by default stuff. We have a whole bunch of things from the Rails 3 line of tooling that we like. But we just haven't gone the whole way yet.

So when you pull that stuff in, do you actually go and kind of rip it out of Rails? Because Rails is open source. And move it into your stuff? Or do you sort of re-implement it?

It depends. Like the asset pipeline, for example.We have the people who built the asset pipeline. So they’re very good at either ripping it out or just kind of buildingyour own custom sort of thing. And in the cases where it makes sense to extract it for other people to use, we’ll go down that route as well, because I think that there are a lot of people who are still sort of stuck in this 2.3 world.

Oh yeah. Pardon me, I forgot. Everybody who doesn’t work for Living Social or Groupon works for Github.

That works.

Or will. [laughter]

The 2.3 thing, I think that there’s probably a bunch of other companies still running on 2.3. I know that I still run something on 2.0 so it’s not too surprising. I don’t know why there isn’t a public fork of Rails 2.3 that people are collaborating on sharing their back ports and security fixes and things like that.

There was talk of doing that at one point, I don’t think anything really came of it, but it’s a really weird place because you have all of the early adopters saying, “Oh screw you, you’re not on the latest and greatest, I don’t want to deal with you.” And then you have the rest of us ‘neck beards’ I guess who care about stable products. I don’t want the latest and greatest right now. It’s kind of a weird middle ground that maybe doesn’t exist.

That’s interesting.

It is open source so I assume the problem can correct itself when it gets bad enough.If it ever does.

Yeah, we’ll see.I mean there’s definitely a lot of stuff in Rails 3 that we’re interested in having. It would be cool if we could somehow get Active Record 3 backported and then slowly upgrade from there. It’s really hard when the upgrade process is as killer as the 2.3 to 3.0 switch was and especially if we are going on to the next version of Rails which also seems precarious. It takes a lot of time when we’d rather be building features and stuff.

It’s true, I mean if you guys got the S.I pipeline working, you’re about 98% there.

Yeah, I mean, we should just be able to gem install Rails 3, right?

Rails comes with this, I don’t know if you’re aware of this, there’s an upgrade script that is delivered with Rails. You just run Rails upgrade and the rest of your application is fixed.

That’s the idea.

How well does that work in practice? Ithink that was a lot easier for you to say… [laughter]

Okay. I have a left-field question for you Zach. Years ago, Github did a challenge for a NetFlix-like recommendation system for who people should follow. They actually announced a winner of the challenge. And yet, I’ve never noticed my follow recommendations get significantly better.

Was that for the people who follow? I know we did one for the fastest version sorter for tags. I don’t know if we did one for followees.

That was a long time ago. It may have just been in the time period of the challenge following stuff being a thing that the company cared about recommending. I remember there was this whole challenge. The version sorting was another one. I never noticed what happened with that one though.

I think we used that code. The following stuff is...the whole recommendation thing, I think, is really interesting. It would be cool to get more things surrounding that. Recommended repos and all of that sort of fun stuff.

Well, all those recommendation engines, I think it’s funny, because like on Facebookit has the ‘You should follow this’. Or Twitter. It’s like, “You follow Josh Susser. So you may be interested in James Edward Grey, Avdi Grim, and Mitt Romney.” And it’s like, "Where did that last one come from?!"

Have you seen Mitt Romney’s code? He’s great at programming.

Actually, we’re good friends. [laughter]

We worked on a project in Small Talk back in the 80’s.

That would be about right, time-wise.

He never got OOP.

But you know, you get two or three…

I was watching Mad Men and he’s actually mentioned in one of the episodes. I think season five of Mad Men.

Seriously?

Yes.

I should watch that.

I just think it’s funny because it’s like two or three that is like, “Oh yeah, I could see that.” and then the last one and you’re just like, “What!?”

It’s like they always have to throw in the odd one, right?

Yeah. [laughter]

It might be a way of trying to expand your filter bubble, or burst it.

Yeah, get you out of your echo chamber.

Yeah, broaden your mind man.

I live in Utah.

Or it could be them just pretending to do that by recommending someone they know you would never follow just to sort of pretend that there was some variety. I don’t know where that came from. So Zach, there’s a lot of stuff I’ve been hearing about people using Github for projects that are not related to software. Like people putting novels up on Github or legislatures using it for their laws andthings like that.

Wasn't it Germany that did their laws there?

Yeah, Ibelieve so.

So what’s the coolest non-coding use of Github that you’ve seen?

There hav been a couple people thatwho their DNA results, their genome or something? That was really cool. Then there was one guy who put his life on there, basically. So he would go back and make commits about important parts of his life. I don’t know if he put branches in them or something like that? People could fork them and say, “You shouldn’t have gotten married here.” I don’t know, it was kind of funny, looking back.

I definitely wish I couldfork various places in my life and then re-base. [Crosstalk]

It’s very strange. It’s a good sign though, right? I mean, about how easy it is to collaborate over that stuff. If a government can actually consider Github an easy way to throw a law out there and let people fork and provide revisions and stuff. It really is kind of a social coding, right?

And how much attention does Github pay towards new features for people who aren’t coders?

I would say it would be very difficult to build anything that makes sense for a non-coder without making a whole new product, more or less. So my mom’s a lawyer, for example. And I know her friends and I know none of them would ever understand any aspect of Github at all. It’s much less -- nerds get all the really cool stuff like ten years before all the rest of the people do. And it usually trickles down in a less effective form but it’s more accessible to more people and that would be a better approach than trying to shoot more in it and make Github kind of accessible for the nontechnical person necessarily.

So Github is right now in the stage of dial-up Internet back in the 80’s?

Your AOL days.

Maybe.

And you’re saying that in five years, we’ll be at DSL? And everyone will have Github?

Maybe. We get all the cool stuff! It’s not like it's a bad ideato haveversion control.It just hasn’t sunk in for the rest of humanity yet.

You maybe underestimate the general appeal.I’ve definitely been on projects where we’re working on something and the non-technical person sees a misspelling on a page or something and manages to navigate to the right part in Github which is probably the hardest part for a nontechnical person. But then, making the edit is very easy, right? You can bring up the editor, tweak the words and you’re good.

I guess I’m comingat itmorefrom like atooling standpoint. If you look at Git itself, Git doesn’t make any sense whatsoever.Staging this commit and then you have this shaw and then what is a shaw? Every step of the way is something that is really confusing that only makes sense if you’re a programmer in some aspects.So I think while version control, in general, makes sense for everybody, people may be able to understand parts of Github’s website but it’s just not the right outlet for a normal human being.

Yeah, my father has a hard enough time understanding that the settings dialog is where you go to change your username. And he’s a really smart doctor.

At least he can find the settings dialog. That’s light speed ahead of a lot other people too.

So according to Hacker News, we’re all going to be programming in Github instead of our editors in the next ten years. The obvious question there is, when is Github going to implement Emacs Doctor so I can psychoanalyze myself? Only Emacs users got that joke.

When you said "according to Hacker News," I just thought you were being ridiculous. [laughter]

Well that was a real comment, right? I didn’t actually follow up on that.

Yeah, it is a real comment.

More seriously, you’ve been working on a lot of features for editing code right on the site. Do you see a lot of people using that to collaborate?

Yeah. The updates specifically for the new file stuff,was really kind of fun to watch because it’s more targeted for the people that know how to do all that stuff in the command line but if you can make it simpler, why not go those steps? So it’s been really cool to see that.

I was really impressed with it the other day. I accidentally hit edited on a file that was in the original project instead of in my fork of it. And I hit submit on it and it basically said, “Hey, you were actually working on the original, so we’ve automatically moved this and put this onto your fork of the project,” and submitted it as apull request. So it was a very, very smooth processes. I was really impressed with that.

Yeah, stuff like that’s really cool. Definitely could be cleaned up a little bit more but it’s a really fun thing to discover like that.

I’m seeing more and more, you know the Bespin project which became Cloud9. It seems like that’s an idea that’s actually starting to gather some legs.

Everything with the Cloud, right? That’s the future of everything.

Yeah, until it cycles back around.

Until it comes back. That’s what I was thinking. That’s interesting. So tell us the coolest thing we don’t know about Github, Zach.

The coolest thing you don’t know about Github.

And we already know that you work there. [laughter]

So that’s off the table.

That’s the most miraculous thing. I don’t know, I like digging our process sort of stuff and I love kind of saying the fact that we are at 140 people- ish, give or take, and we still have nobody that has left the company which I kind of find really fascinating. CHUCK: Nobody has left? Ever?

No one has quit.

Wow!

I’ve never heard of any company come even close to that. Usually people are around the 50% mark. They end up doing other stuff.

I worked for a company that they kept saying that everybody who had ever left had come back. That didn’t hold. [laughter]

That’s pretty good. I know that Pivotal Labs used to brag a lot about how many people who had left the company came back and sort of had the revolving door thing going. There were a lot of people who would leave and come back because it was agreat place to work and they were between things that they would go back there but people left. I think Github definitely has something up on that.

I mean, it won’t last forever but it’s definitely nice in the meantime. We don’t have to deal with -losing a person really sucks in terms of trying to recoup the institutional knowledge they have of whatever projects they’re working on. There’s something to be said for kind of the way of how we work that I think is kind of interesting and retains people.

It should be interesting. You guys have such an iconoclastic - is that the right word - set of policies for how you run the company. It’s so different from most companies out there. Since you’ve never really had to deal with the problem of people leaving the company, you haven’t addressed that yet.

It would be interesting to see what the company comes up with for people leaving.

I’ve been suggesting murder. [laughter]

We’ll just have people start disappearing.

No wonder no one's left! [laughter]

Geez! Now we know why.

Go to a Drink Up, never come back. [laughter]

We’ve read a lot about how different Github is and how they run their business.What is the thing that you like most about working there that’s maybe unusual?

We have a bunch of perks and stuff like every other company. But I think when you look at what actually creates happy people, it’s the very core of how do you work. I think it’s sort of, we don’t have work hours, we can work wherever you want. We are like 60% remote and then of that, maybe half the people show up to the office every day. We’re very friendly in terms of how you want to get work done. You can have a family life outside of work. Things that are very sensible things that not a lot of companies end up doing very well. I think if you want to look at employee happiness, you have to look at the very basic level of ‘Are you happy doing work day to day’.

It’s a good point. Now, you guys got a lot of these ideas from Valve, right?

Not necessarily Valve. Valve “leaked” their handbook earlier this year. And for us, that was more a matter of we had heard of Valve doing similar things, but we didn’t know how closely we matched up to Valve. That was really kind of just, comforting because they are more than double our size and it’s nice to know that when you’re doing stuff like this, that somebody has been doing it longer and on a bigger scale than you. In terms of how we work, I think we just ended up having a bunch of founders who worked at really crappy places. More than anything else, I think this is just a reaction towards stuff like that. We have no deadlines, for example.We ship stuff when stuff is ready and that stemmed directly from, Chris Wanstrath worked at a place where you had to meet your deadline and stuff. And it sucked and ended up with crappier codes. I think we’re motivated by fear, maybe. Fear of a crappy company, I guess.

Interesting. Are there any other things that we want to talk about before we get into the picks?

Zach, can you spill the beans on anything as an exclusive for us?

No. [laughter]

Why did we have this guy on the show?

Remember the whole murder thing he talked about earlier? I can’t even believe you asked.Geez!He’s in your time zone.

They have to hire him first to do that.

Not necessarily.

That’s the downside of getting staff mode. [laughter]

It’s got that feature that can reach out of the computer.

If you’re in staff mode, you’re also in murder mode.

It doesn't actually kill you. It just sort of sucks you into the whole Tron/Matrix thing.

They have this internal app called Guido and they can just make a person... [laughter]

So are you saying their app is written in Python? [laughter]

He’s going to give us an exclusive and I can just see the headlines, “Rogues Found Dead.” [laughter]

Only David Brady survives.

Okay, Zach.So, important question, what’s the most popular draft in the Kegerator?

I don’t know.I’ve been out of town for two weeks.

Oh! It changes that quickly?

Yeah, I don’t know. We don’t really end up drinking a lot of the draft beer. We have a bunch of other interesting …

That’s not true. We’ve seen the blog posts, Zach. Don’t lie, c’mon! [laughter]

We throw drink ups. I actually drink a lot less at Github than I did in the early days. So I don’t know. It’s more of a chill out thing than anything else. Somebody made the comment, that as soon as you end up with beer and alcohol all over the place, people just stop drinking and that’s kind of the case. [laughter]

You don’t drink as much as the early days. I suddenly had a vision of you going through code and going. “Oh, this must have been one of those days.” [laughter]

As long as you stay in the bomber peak, you’re pretty set.

You write the tests sober. It doesn’t matter how drunk you are when you’re programming.

That’s right as long as it takes.

I think I can disprove that.

Alright so what’s your favorite beer then to drink while coding?

I don’t know while coding? So I keep track of all my beers I drink for the last three years. I don’t know why, four years at this point.

You have a Git repo?

No it’s all on Daytum.com/holman. I don’t know, it doesn’t matter how much I’ve had to drink but I will always write down my beer. My number one right now by a large amount is Anchor Steam because that’s like water out here in San Francisco. It’s everywhere.

It is somewhat unavoidable.

Runs hot and cold in Anchor Steam, huh?

My biggest wish is if I could get Yuengling out here because I went to school in Pittsburgh and Yuengling is amazing. But you can’t get it past Ohio, basically.

You could say the same thing about Iron City but I don’t think anyone ever complains about that.

No one says that about Iron City.

When I was back in Pittsburgh in August, I had an Iron City and I was like, “Oh yeah I didn’t miss that at all.”

Yeah, it’s not good. Isn’t it gone at this point? I think they killed it.

No it’s still around. [Crosstalk]

Let’s get into the picks. I think we’re pretty much there.

Yeah, we’re talking about beer. It must be pick time. [laughter]

Avdi, do you have a beer pick? Let’s do this. Zach, it sounds like you have some ideas and stuff you like, you want to go first?

Whatever, up to you all.

Okay, go ahead.

My only real pick is, I’ve been travelling and I don’t even know what’s going on in the Internet anymore. I’m jet lagged, whatever. So I re-launched my blog yesterday and the cool thing I used on that was stuff from Symbol Set. They make a whole bunch of really cool icon fonts. The one I used was SS Social which is a bunch of social icons. They are like an Octocat for Github, they have a Dribble icon, a Twitter icon, and I love icon fonts, at this point, because they are very sharp. Do you guys have Retina Macbook Pros? It’s a totally different Internet. You can see which sites care about this stuff and which don’t.

Alright. James, what are your picks?

I was looking at the font Zach was saying. I’ve got three, so I’ll try to go quick. The first one is a cool video I saw called the Black Magic of SSH. So if you’re an SSH novice or so, you’ll probably get a lot out of this. It’s pretty long; it’s like an hour. He spends the first half talking about redirection in SSH. So from the client to the server, the server to the client but it’s probably the best description of it ever because he really gives you ‘why would you use these’ and ‘what would you use them for’ and stuff. So if you don’t know what SSH redirection is, you should totally watch that, or if you kind of know, but you get it right by accident, this would probably clear it up. Then the second half of the video is just several miscellaneous grab bag features of SSH which are cool. Multiple, I didn’t know about at all. So that’s cool. Then another video I saw recently that I enjoyed was Peepcode’s new series called Up for Scaling Up. They released their first video and it’s Eric Lindvall just explaining how he scales Papertrail. The conversation’s really good. And at times, it’s pretty common sense stuff but he does get into some tools and techniques that are neat. There’s a couple of annoyances in this Peepcode video just in their chapter headers.There are sometimes like two of them and then the music doesn’t make sense and the questions are all just these slides on the screen.There’s no code or anything and you can just listen to this thing in the background, except you wouldn’t know what questions they were asking. There is sort of like a slide on the screen, so you have to keep switching back to the video and that’s kind of annoying. But as far as scaling up your app, it gives some interesting ideas and ways to think about it. Then finally, people liked my recent pick of children’s toys from when I was Christmas shopping for my daughter. So, here’s another one I found since Christmas is On The Horizon.It’s kind of a cool little role playing game, you can play it on and just set it up and do little adventures and it gives you the parts to play with them. It’s good for 4-year-olds and stuff. So I’ll admit, I haven’t actually tried it in practice yet because my daughter is only two. It’s probably still a bit above her what she’s ready for it but it looks cool to me and it’s cheap. Okay. Those were my picks.

Awesome. Josh, what are your picks?

I had a kind of busy and distracting week. And I don’t have much in the way of picks. But I do have one thing that I thought was awesome. So I will pick that.And that’s Aaron Patterson organized an online meeting of Ruby implementers. So, all of the major Ruby implementations have representatives. They did on an IRC like two days ago, it was Monday this week. And it was on IRC so it’s easy to just grab the output as meeting notes. It’s pretty fascinating reading to see what’s going on and the people who create the Ruby implementations, what they care about. So, I think it’s great that there are people coordinating all of this stuff and who care about providing some consistency among the different language implementations. So, I think that’s pretty cool. So that’s my pick.

Awesome. Katrina, what are your picks?

I have two today. The first is a pipe-in library called httpie, maybe. I'm not quite sure about the pronunciation. It’s http for humans. So if you spend a lot of time [inaudible], this will make your life a little bit nicer. The other pick is a book, like old school. It’s called The Anatomy of Story. It’s not really for techies, it’s written for people who like fiction and screen like movies and things. But if you do a lot of conference presentations, this would help structure your presentation in a more compelling way. So, Anatomy of Story.

Is this related to Nancy -- she did The Secret Structure of Talks.

Nancy Duarte? No, not at all.

Yeah, okay. Yeah, Nancy Duarte. I love that video. I think that was someone’s pick recently.

Yeah.

Yeah, sounds like I have another thing to watch.

Awesome. Avdi, what do you pick?

Read Josh. It’s a book. Read.

Wait, wait, wait. I actually have to use my words. [laughter]

We’ll explain it after the show.

[laughs] Avdi, what are your picks?

Let’s see. I read a couple of good blog posts recently. There's this one from Eric Ries and Sarah Milstein on the Start-up Lessons Learned blog about solving the pipeline problem. It’s all about how they handled creating their link start-up conference with a pretty remarkably diverse speaker line-up relative to other technical conferences. And they go into things like the blind review or somewhat blind review process but that not being the whole story. They talk a lot about religious, the importance of getting outside of your circle, your inner circle basically. And how a lot of this diversity stuff isn’t about like you’re trying to find token people from other ethnic groups or something like that but it’s really about the fact that people have circles that they don’t really think about. And those circles exist probably for historical reasons but those circles tend to be fairly homogenous. And they just don’t really think about how tight those circles are. So a lot of the posts are just about thinking outside that box and getting help to think about outside that box and how their conference was much improved by it.

Avdi, I hate editorializing other people’s picks but I feel impelled to [crosstalk]. Yeah. The only thing I want to say about that is that it sounds like it’s a lot of work to do what they did. And if you ascribe to the position that diversity has value, things that have value are worth working for. So, it’s just I think people who would show up at a conference and are pleased by the diversity or displeased with the lack of diversity, you should understand that it actually takes work to create diversity in a conference these days. I hope that someday in the future, someday soon maybe, it’s not that much work and we have a lot more diversity in the community so it just happens more naturally. But these days to create that value of diverse viewpoints and a more robust ecosystem, it just takes work and it’s great to see people documenting how they achieve that.

Yeah, absolutely. And of course, your conference called [inaudible] was a great example of that really succeeding and a better conference coming up because of it.

And people take different approaches to that where like Ruby Midwest where they had opportunity scholarships. Was that Midwest or Rocky Mountain?

I don’t know. [crosstalk]

That’s Rocky Mountain.

Yeah, Rocky Mountain. They did a great job with that. I think they might see more of that kind of approach in the future too. Anyway, enough about my editorializing.

Another good blog post read recently is called Everything You Ever Wanted to Know about Constant Lookup in Ruby and is exactly what it sounds like and I learned...

It’s great.

Yeah, it’s really great. I learned a few things from it. It’s just constant lookup but it’s good to know these things. You’ll be less confused about why your code isn't seeing constants that you think it should be seeing after you read this article. And finally, a hardware pick. I recently picked up a lightly used ShuttlePRO 2 controller device. It’s a jog dial or a jog shuttle dial, I'm not sure what it’s called. Anyway, it’s a tool for video and audio editors and it has an inner wheel that is used for advancing frame by frame. You can spin it as fast or as slow as you want. It’s got little tiny clicks to indicate each frame. And then it’s got like an outer dial, an outer ring which is spring loaded that you can sort of twist to the left, to the right, to fast forward and rewind in whatever your editing application is. And the farther you twist it, the faster it goes. And then when you get to the point you want, you can slow down, you can just release it and it springs back. And then it’s got like 15 programmable buttons on it as well. I’ve been using it in my editing of Ruby Toughest Videos and it’s just great. The thing I love about it is that it’s got enough programmable buttons on it that generally, I'm not like shuffling my hands between three devices - the keyboard, the jog dial, and the mouse. I can pretty much just keep my left hand on the jog dial and my right hand on the mouse and do most of the common operations that I do on video. So if you have a video and audio or audio or anything like that, totally take a look at this thing.

Sounds good. All right. So, my picks are first off, I just wanted to explain briefly. I know I’ve championed them in the past but I’ve been working on this project for the last six months and the team has adopted Emacs. And since we’re pairing all day, you don’t really get a choice in using something else. And so, I have actually switched to Emacs just because the context which from Emacs back to them is so painful that it’s just not worth it. So when I made the switch, I went around trying to find an acceptable Emacs that would run all of the plug-ins that we’re using for this client. And the one that I found is Emacs for Mac OS X. And I’ll put a link to that on the show notes, EmacsforMacOSX.com. The other thing that I experienced this last weekend was Global Day of Code Retreat. That’s something that’s organized by Corey Haines and a few other folks. And I also went to one of those local here and just had a terrific time. Code Retreats are awesome. And if you want to get some challenges in different languages or different techniques or putting different constraints on your project, then this is just a terrific way to go to learn some of the ways you can vary on what you’re doing in your code. So, I highly recommend if you have an opportunity to go to a code retreat to do it. And you can find out when there’s schedule at CodeRetreat.org. Those are my picks and we’ll go and wrap up the show. I just want to remind everybody again to go check out Ruby Rogues Parley. You can just find it on the RubyRogues.com website at this point. The Book Club Book which we will be reading at the beginning of January. Go pick that up. There is a discount code. If you buy two books, you get 40% off. So you can get Practical Object-Oriented Design in Ruby and another book and they get 40% off. That was the coupon code that they gave us. Are there any other announcements, anything else you want to bring up?

Code Bits.

Oh yes, Code Bits. Go sign up for Code Bits. You can get that, like I said, probably for another day or so. And you can do that at RubyRogues.com/RubyBits.