11–20 of 40 posts
This is awesome. I absolutely love engineering blogs like this. There's no real reason for companies to educate external devs/hobbyists/students like this, but some do, and it's really awesome.
The reason is recruiting, and it's effective.
Earlier quoted context omitted.
The reason is recruiting, and it's effective.
Because people read it and think "hey that sounds cool, I want to work there"?
There are second order effects as well. Having a good tech blog that talks about this stuff gains the company mindshare amongst developers. If, as in in the case of github, the developers (etc) are the customer, then the translation to marketshare is pretty straight-forward.
When developers (etc) are not the target audience, they still get warm-fuzzies about the company and it gains word of mouth, and non-tech who seek out a recommendation from their friends, will hear about the company with the good blog. Usually in the form of "Oh yeah, there are a couple of alternatives, but the tech at $X is top notch, look hard at them".
Earlier quoted context omitted.
Because people read it and think "hey that sounds cool, I want to work there"?
Pretty much. There are second order effects as well. Having a good tech blog that talks about this stuff gains the company mindshare amongst developers. If, as in in the case of github, the developers (etc) are the customer, then the translation to marketshare is pretty straight-forward. When developers (etc) are not the target audience, they still get warm-fuzzies about the company and it gains word of mouth, and no…
I wish they had talked a little more about the tradeoff they made. They mentioned that splitting packfiles by fork was space-prohibitive, but ended up with a solution which must take more space than originally used. (If the new heuristic refuses to use some objects as delta bases, some options which would have provided the best compression are no longer available to git)
The performance win is incredible, how much space did they give up in the process?
This is technical recruiting done right, a lucid walkthrough of a hard problem complete with links to the implementation. It must have taken at least a few weeks of engineer-time to write, Github is awesome for making this public. I wish they had talked a little more about the tradeoff they made. They mentioned that splitting packfiles by fork was space-prohibitive, but ended up with a solution which must take more s…
I didn't have any numbers on hand, so I just repacked our git/git network.git with and without the delta-aware code. A stock repack is about 300MB, and the delta-aware one is 400MB.
That sounds like a lot, but the real alternative is not sharing objects at all, which is more like 350GB.
Earlier quoted context omitted.
The reason is recruiting, and it's effective.
Because people read it and think "hey that sounds cool, I want to work there"?
If you sell developer tools, this is _way_ more effective than an ad campaign because it's completely genuine.
This is technical recruiting done right, a lucid walkthrough of a hard problem complete with links to the implementation. It must have taken at least a few weeks of engineer-time to write, Github is awesome for making this public. I wish they had talked a little more about the tradeoff they made. They mentioned that splitting packfiles by fork was space-prohibitive, but ended up with a solution which must take more s…
Earlier quoted context omitted.
That's awesome. You don't find many people that enjoy writing in C. I assumed it was Ruby.
Ruby MRI and YARV are both written in C, so to be a true Ruby hacker you need some C chops. :-)
I notice that there is an inactive user account called engineering. If at all an User Page is created by that account, it would be available at engineering.github.io.