| CARVIEW |
Select Language
HTTP/2 302
server: nginx
date: Mon, 22 Dec 2025 12:33:56 GMT
content-type: text/plain; charset=utf-8
content-length: 0
x-archive-redirect-reason: found capture at 20091116124410
location: https://web.archive.org/web/20091116124410/https://feeds.feedburner.com/github
server-timing: captures_list;dur=0.597601, exclusion.robots;dur=0.049204, exclusion.robots.policy;dur=0.038777, esindex;dur=0.012006, cdx.remote;dur=5.799309, LoadShardBlock;dur=159.195591, PetaboxLoader3.datanode;dur=109.188428
x-app-server: wwwb-app217-dc8
x-ts: 302
x-tr: 195
server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0
set-cookie: wb-p-SERVER=wwwb-app217; path=/
x-location: All
x-as: 14061
x-rl: 0
x-na: 0
x-page-cache: MISS
server-timing: MISS
x-nid: DigitalOcean
referrer-policy: no-referrer-when-downgrade
permissions-policy: interest-cohort=()
HTTP/2 200
server: nginx
date: Mon, 22 Dec 2025 12:33:57 GMT
content-type: text/xml; charset=UTF-8
x-archive-orig-last-modified: Mon, 16 Nov 2009 02:03:34 GMT
x-archive-orig-etag: 1YqnlU07Vvyrx98sQgyCBDltQyk
x-archive-orig-date: Mon, 16 Nov 2009 12:44:10 GMT
x-archive-orig-expires: Mon, 16 Nov 2009 12:44:10 GMT
x-archive-orig-cache-control: private, max-age=0
x-archive-orig-x-content-type-options: nosniff
x-archive-orig-x-xss-protection: 0
x-archive-orig-server: GFE/2.0
cache-control: max-age=1800
x-archive-guessed-content-type: text/xml
x-archive-guessed-charset: utf-8
memento-datetime: Mon, 16 Nov 2009 12:44:10 GMT
link: ; rel="original", ; rel="timemap"; type="application/link-format", ; rel="timegate"
content-security-policy: default-src 'self' 'unsafe-eval' 'unsafe-inline' data: blob: archive.org web.archive.org web-static.archive.org wayback-api.archive.org athena.archive.org analytics.archive.org pragma.archivelab.org wwwb-events.archive.org
x-archive-src: webgroup-20100504231338-00039/ARCHIVEIT-1147-WEEKLY-SCEMPR-20091116123913-00241-crawling105.us.archive.org-8090.warc.gz
server-timing: captures_list;dur=0.595315, exclusion.robots;dur=0.020178, exclusion.robots.policy;dur=0.009742, esindex;dur=0.015259, cdx.remote;dur=6.601379, LoadShardBlock;dur=138.427470, PetaboxLoader3.datanode;dur=194.592453, PetaboxLoader3.resolve;dur=180.515948, load_resource;dur=252.691124
x-app-server: wwwb-app217-dc8
x-ts: 200
x-tr: 424
server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0
x-location: All
x-as: 14061
x-rl: 0
x-na: 0
x-page-cache: MISS
server-timing: MISS
x-nid: DigitalOcean
referrer-policy: no-referrer-when-downgrade
permissions-policy: interest-cohort=()
tag:github.com,2008:/blog
The GitHub Blog
2009-11-15T17:56:53-08:00
tag:github.com,2008:Post/548
2009-11-15T17:55:36-08:00
2009-11-15T17:56:53-08:00
GitHub Meetup London
<div align="center"><img src="https://theroyalgeorgewc2.co.uk/images/home5.jpg"/></div>
<p>It’s the last stop on our Europe tour and we’re capping things off with an evening at the <a href="https://theroyalgeorgewc2.co.uk/">Royal George</a> near Soho in London at 19:00 on Monday the 16th. PJ, Scott, and I will be in attendance along with (if the rumors are true) a ton of local developers and tech luminaries from the greater London area. This is a meetup you will not want to miss!</p>
<p><iframe width="475" height="300" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="https://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Royal+George+near+london&ie=UTF8&hq=Royal+George&hnear=London,+UK&ll=51.530106,-0.122051&spn=0.055333,0.181274&z=13&iwloc=A&cid=4414905488058032507&output=embed"></iframe><br /><small><a href="https://maps.google.com/maps?f=q&source=embed&hl=en&geocode=&q=Royal+George+near+london&ie=UTF8&hq=Royal+George&hnear=London,+UK&ll=51.530106,-0.122051&spn=0.055333,0.181274&z=13&iwloc=A&cid=4414905488058032507" style="color:#0000FF;text-align:left">View Larger Map</a></small></p>
mojombo
tag:github.com,2008:Post/547
2009-11-10T17:19:44-08:00
2009-11-10T17:27:17-08:00
GitHub Meetup Oslo, Norway
<div align="center"><img src="https://img.skitch.com/20091111-bir68bb7kn76kdpdtr1988m1yr.png"/></div>
<p>Continuing our tour of Europe, PJ, and Scott, and I will be in Oslo on Friday the 13th and we’d like to invite you to join us at <a href="https://www.gloriaflames.no/">Gloria Flames</a> at 20:30 for drinks and good times. We’re rolling through Oslo specifically to meet the locals, so don’t disappoint us! I’ll be wearing a “fork you” tshirt so I’ll be easy to identify. See you there!</p>
<p>If for some reason we need to change venues, check our twitter accounts “mojombo”, “pjhyett”, and “chacon” for updates.</p>
<p><iframe width="525" height="300" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="https://maps.google.com/maps?client=safari&oe=UTF-8&ie=UTF8&q=%22gloria+flames%22+oslo&fb=1&hq=%22gloria+flames%22&hnear=oslo&ei=1w_6SuuAG93TOP69hIcP&ved=0CBAQpQY&hl=en&view=map&cid=16559423027679171250&iwloc=A&ll=59.91291,10.761501&spn=0.006295,0.006295&output=embed"></iframe><br /><small><a href="https://maps.google.com/maps?client=safari&oe=UTF-8&ie=UTF8&q=%22gloria+flames%22+oslo&fb=1&hq=%22gloria+flames%22&hnear=oslo&ei=1w_6SuuAG93TOP69hIcP&ved=0CBAQpQY&hl=en&view=map&cid=16559423027679171250&iwloc=A&ll=59.91291,10.761501&spn=0.006295,0.006295&source=embed" style="color:#0000FF;text-align:left">View Larger Map</a></small></p>
mojombo
tag:github.com,2008:Post/546
2009-11-10T06:23:12-08:00
2009-11-10T06:27:58-08:00
GitHub Rebase #30
<p>This is the second of many themed Rebases to come…our first was the <a href="https://rebase.github.com/22.html">book edition</a>. In related news, the column has also been going on for <a href="https://rebase.github.com/archive.html">over a year</a> now! If you’ve got ideas for projects to feature or themes, don’t be afraid to <a href="https://rebase.github.com/howto.html">message me.</a></p>
<p style="text-align:center;"><a href="https://gitshorty.net/"><img src="https://cloud.github.com/downloads/rebase/rebase.github.com/gitshorty.jpg" alt="" /></a></p>
<h3>Featured Project</h3>
<p><a href="https://github.com/nddrylliog/ooc">ooc</a> is a statically typed, object oriented language with some functional programming hints that’s growing up right here on GitHub. The compiler is currently written in Java, and it boils down to C99 so it can run anywhere. Grab the zip from the Downloads section or clone away and <a href="https://ooc-lang.org/setup">set it up</a>. The language has some <a href="https://ooc-lang.org/">neat features</a>: everyone’s favorite generic types, a clean <code>import</code>/<code>use</code> system that makes Ruby’s <code>require</code> look like yesterday’s news, and the <code>cover</code> keyword that allows for some really neat abstractions over types and clean interfacing with other C code. If you’re a language geek or need a breath of fresh air, <a href="https://ooc-lang.org/docs/">check it out</a>.</p>
<h3>Notably New Projects</h3>
<p><a href="https://github.com/nddrylliog/rock">rock</a> is an ooc compiler written in ooc, of course. This has some great examples of quite complex ooc code and aims to replace the Java compiler.</p>
<p><a href="https://github.com/kuzux/ooc-sqlite3">ooc-sqlite3</a> is an <a href="https://www.sqlite.org/">SQLite</a> driver that’s also just getting off the ground, but it’s starting to pick up some steam. Next stop: a web framework!</p>
<p><a href="https://github.com/nddrylliog/woot">woot</a> is ooc’s first unit testing system, and is headed towards a bright future since it’ll be used to test ooc itself. This dogfood is tasty!</p>
<p><a href="https://github.com/OneSadCookie/ooc-glew">ooc-glew</a> uses <a href="https://glew.sourceforge.net/"><span class="caps">GLEW</span></a> to open up the power of <a href="https://www.opengl.org/">OpenGL</a> to ooc. There’s also a little Ruby magic baked in to generate the bindings since there’s a lot of functions.</p>
<p><a href="https://github.com/eagle2com/Stirling3d">Stirling3D</a> is also for the graphically minded. This project is a graphics/physics engine that also hooks into OpenGL and is starting to render some neat stuff.</p>
<p><a href="https://github.com/fredreichbier/ooc-yajl">ooc-yajl</a> is a set of bindings to <a href="https://lloyd.github.com/yajl/">yajl</a>, a <a href="https://rebase.github.com/21.html">former featured project</a> that is a lightning fast <span class="caps">JSON</span> parsing library. It’s also a neat example of how easy it is to hook into C libraries and how the <code>.use</code> files work.</p>
qrush
tag:github.com,2008:Post/545
2009-11-08T17:33:36-08:00
2009-11-09T11:16:23-08:00
Recent UI updates to GitHub
<!-- -*-Markdown-*- -->
<p>On my first day at GitHub, I asked the crew what they wanted to me to do around here. Their response was something along the lines of "make GitHub sexy" Now that we've been rolling out steady UI updates for about a month, I thought I'd take some time and go over what all I've been working on.</p>
<p>I previously covered the <a href="https://github.com/blog/513-new-repository-lists-on-your-dashboard">updated dashboard repository lists</a> and <a href="https://github.com/blog/523-gist-improvements">gist improvements</a>, but I haven't had a chance to go over the new userbox, <a href="https://github.com/kneath">profile pages</a>, <a href="https://github.com/account">account pages</a>, and <a href="https://github.com/dashboard">dashboard headers</a>.</p>
<p><img src="https://share.kyleneath.com/captures/skitched-57-20091108-173421.jpg" alt="New userbox" /></p>
<p>The new userbox was rolled out to solve a problem we had -- people with long usernames were breaking the UI, forcing links into the next line. I also took the time to reorganize the navigation and spruce up the look & feel.</p>
<p><img src="https://share.kyleneath.com/captures/skitched-58-20091108-173443.jpg" alt="New profile pages" /></p>
<p>The new profile pages were one of the first purely cosmetic updates to the site. You'll notice a new style of page header being rolled out. This header does have some functional benefits -- but they're subtle. On pages that are yours, you'll notice a slight yellow highlight. This isn't terribly useful right now, but as we roll out new features you'll see why I'm going this route.</p>
<p>I was also testing out the waters with this page. GitHub has an extremely particular and vocal audience that doesn't represent the typical web user. I wanted to make sure that the general reaction was positive. Judging from the twitter updates and in-person feedback I've gotten, people seem to like the changes -- so you'll see more of this style around the site in the future.</p>
<p><img src="https://share.kyleneath.com/captures/skitched-59-2-20091109-111602.jpg" alt="New Account Settings Pages" /></p>
<p>Along with the new profile pages, we also rolled out updated account settings pages. Previously, you had to edit your profile information in-place on the profile page, but now it's grouped with the rest of your settings.</p>
<p><img src="https://share.kyleneath.com/captures/skitched-60-20091108-173516.jpg" alt="New billing page" /></p>
<p>Previously all of the billing information was crammed into a little grey box in the upper right of the account settings page. With the updated account settings page I decided to create a dedicated billing page. This page shows your plan usage in an easier to access manner and (hopefully) makes it easier to upgrade to paid accounts! :)</p>
<p><img src="https://share.kyleneath.com/captures/skitched-61-20091108-173545.jpg" alt="New dashboard headers" /></p>
<p>The last update we've rolled out are new-style dashboard headers. The reason for these aren't entirely obvious right now -- but in time they will become a lot more useful. I realize these new headers do push down the repository lists by about 60px, but it was a compromise that I decided to make to give us room for the future.</p>
<p>Hopefully you guys are enjoying the evolution of the GitHub interface, I've been having a blast watch the feedback pour in after each push.</p>
kneath
tag:github.com,2008:Post/544
2009-11-07T09:06:04-08:00
2009-11-07T09:06:27-08:00
GitHub Meetup Poznań, Poland
<p>Tom, PJ, and Scott will be hanging out at <a href="https://moodclub.pl"><span class="caps">MOOD</span> Club</a> at 21:30 tonight (Saturday) in Poznań, Poland following the first day of the RuPy Conference. If you’re local or in town for the conference, come by and say hi!</p>
<div align="center"><img src="https://moodclub.pl/UserFiles//File/OpenCzerwiec2008/080627_Poznan_Mood_004.JPG"/></div>
mojombo
tag:github.com,2008:Post/543
2009-11-04T10:35:55-08:00
2009-11-04T10:40:19-08:00
New Resque Web UI
<p>Behold the power of open source! <a href="https://github.com/adamcooke">adamcooke</a> has reskinned <a href="https://github.com/defunkt/resque">Resque’s</a> web UI.</p>
<div align="center"><a href="https://img.skitch.com/20091104-jsqydh9jgg9ju4tkt66jqm2399.png"><img src="https://img.skitch.com/20091104-8c41b9jmdtyc79jc76yap53igc.png"/></a></div>
<div align="center"><a href="https://img.skitch.com/20091104-k3iuxw8hqsce86b5pdphsctsg4.png"><img src="https://img.skitch.com/20091104-cs222tun9yna4s46ywt7jqdjqk.png"/></a></div>
<p>Also now includes live updating:</p>
<div align="center"><a href="https://img.skitch.com/20091104-88wn3wtc9jnacas3mytxxwn6c9.png"><img src="https://img.skitch.com/20091104-1nqebsad9kuac6ixaqgykqmste.png"/></a></div>
<p>Thanks Adam!</p>
defunkt
tag:github.com,2008:Post/542
2009-11-03T09:36:46-08:00
2009-11-03T10:02:46-08:00
Introducing Resque
<!-- -*-Markdown-*- -->
<p><a href="https://github.com/defunkt/resque">Resque</a> is our Redis-backed library for creating background jobs, placing
those jobs on multiple queues, and processing them later.</p>
<p>Background jobs can be any Ruby class or module that responds to
<code>perform</code>. Your existing classes can easily be converted to background
jobs or you can create new classes specifically to do work. Or, you
can do both.</p>
<p>All the details are in the <a href="https://github.com/defunkt/resque#readme">README</a>. We've used it to process
over 10m jobs since our move to Rackspace and are extremely happy with it.</p>
<p>But why another background library?</p>
<h3>A Brief History of Background Jobs</h3>
<p>We've used many different background job systems at GitHub. SQS,
Starling, ActiveMessaging, BackgroundJob, DelayedJob, and beanstalkd.
Each change was out of necessity: we were running into a
limitation of the current system and needed to either fix it or move
to something designed with that limitation in mind.</p>
<p>With SQS, the limitation was latency. We were a young site and heard
stories on Amazon forums of multiple minute lag times between push and
pop. That is, once you put something on a queue you wouldn't be able
to get it back for what could be a while. That scared us so we moved.</p>
<p>ActiveMessaging was next, but only briefly. We wanted something
focused more on Ruby itself and less on libraries. That is, our jobs
should be Ruby classes or objects, whatever makes sense for our app,
and not subclasses of some framework's design.</p>
<p>BackgroundJob (bj) was a perfect compromise: you could process Ruby
jobs or Rails jobs in the background. How you structured the jobs was
largely up to you. It even included priority levels, which would let
us make "repo create" and "fork" jobs run faster than the "warm some
caches" jobs.</p>
<p>However, bj loaded the entire Rails environment for each job. Loading
Rails is no small feat: it is CPU-expensive and takes a few
seconds. So for a job that may take less than a second, you could have
8 - 20s of added overhead depending on how big your app is, how many
dependencies it requires, and how bogged down your CPU is at that time.</p>
<p>DelayedJob (dj) fixed this problem: it is similar to bj, with a
database-backed queue and priorities, but its workers are
persistent. They only load Rails when started, then process jobs in a
loop.</p>
<p>Jobs are just YAML-marshalled Ruby objects. With some magic you can
turn any method call into a job to be processed later.</p>
<p>Perfect. DJ lacked a few features we needed but we added them and
contributed the changes back.</p>
<p>We used DJ very successfully for a few months before running into some
issues. First: backed up queues. DJ works great with small datasets,
but once your site starts overloading and the queue backs up (to, say,
30,000 pending jobs) its queries become expensive. Creating jobs can
take 2s+ and acquiring locks on jobs can take 2s+, as well. This means
an added 2s per job created for each page load. On a page that fires
off two jobs, you're at a baseline of 4s before doing anything else.</p>
<p>If your queue is backed up because your site is overloaded, this added
overhead just makes the problem worse.</p>
<p>Solution: move to beanstalkd. beanstalkd is great because it's fast,
supports multiple queues, supports priorities, and speaks YAML
natively. A huge queue has constant time push and pop operations,
unlike a database-backed queue.</p>
<p>beanstalkd also has experimental persistence - we need persistence.</p>
<p>However, we quickly missed DJ features: seeing failed jobs, seeing
pending jobs (beanstalkd only allows you to 'peek' ahead at the next
pending job), manipulating the queue (e.g. running through and
removing all jobs that were created by a bug or with a bad job name),
etc. A database-queue gives you a lot of cool features. So we moved
back to DJ - the tradeoff was worth it.</p>
<p>Second: if a worker gets stuck, or is processing a job that will take
hours, DJ has facilities to release a lock and retry that job when
another worker is looking for work. But that stuck worker, even
though his work has been released, is still processing a job that you
most likely want to abort or fail.</p>
<p>You want that worker to fail or restart. We added code so that,
instead of simply retrying a job that failed due to timeout, other
workers will a) fail that job permanently then b) restart the locked
worker.</p>
<p>In a sense, all the workers were babysitting each other.</p>
<p>But what happens when all the workers are processing stuck or long
jobs? Your queue quickly backs up.</p>
<p>What you really need is a manager: someone like monit or god who can
watch workers and kill stale ones.</p>
<p>Also, your workers will probably grow in memory a lot during the
course of their life. So you need to either make sure you never create
too many objects or "leak" memory, or you need to kill them when they
get too large (just like you do with your frontend web instances).</p>
<p>At this point we have workers processing jobs with god watching them
and killing any that are a) bloated or b) stale.</p>
<p>But how do we know all this is going on? How do we know what's sitting
on the queue? As I mentioned earlier, we had a web interface which
would show us pending items and try to infer how many workers are
working. But that's not easy - how do you have a worker you just
<code>kill -9</code>'d gracefully manage its own state? We added a process to
inspect workers and add their info to memcached, which our web
frontend would then read from.</p>
<p>But who monitors that process. And do we have one running on each
server? This is quickly becoming very complicated.</p>
<p>Also we have another problem: startup time. There's a multi-second
startup cost when loading a Rails environment, not to mention the
added CPU time. With lots of workers doing lots of jobs being
restarted on a non-trival basis, that adds up.</p>
<p>It boils down to this: GitHub is a warzone. We are constantly
overloaded and rely very, very heavily on our queue. If it's backed
up, we need to know why. We need to know if we can fix it. We need
workers to not get stuck and we need to know when they are stuck.</p>
<p>We need to see what the queue is doing. We need to see what jobs have
failed. We need stats: how long are workers living, how many jobs are
they processing, how many jobs have been processed total, how many
errors have there been, are errors being repeated, did a deploy
introduce a new one?</p>
<p>We need a background job system as serious as our web framework.
I highly recommend DelayedJob to anyone whose site is not 50%
background work.</p>
<p>But GitHub is 50% background work.</p>
<h3>In Search of a Solution</h3>
<p>In the Old Architecture, GitHub had one slice dedicated to processing
background jobs. We ran 25 DJ workers on it and all they did was run
jobs. It was known as our "utility" slice.</p>
<p>In the New Architecture, certain jobs needed to be run on certain
machines. With our emphasis on sharding data and high availability, a
single utility slice no longer fit the bill.</p>
<p>Both beanstalkd and bj supported named queues or "tags," but DelayedJob
did not. Basically we needed a way to say "this job has a tag of X"
and then, when starting workers, tell them to only be interested in
jobs with a tag of X.</p>
<p>For example, our "archive" background job creates tarballs and zip
files for download. It needs to be run on the machine which serves
tarballs and zip files. We'd tag the archive job with "file-serve" and
only run it on the file serving slice. We could then re-use this tag
with other jobs that needed to only be run on the file serving slice.</p>
<p>We added this feature to DelayedJob but then realized it was an
opportunity to re-evaluate our background job situation. Did someone
else support this already? Was there a system which met our upcoming
needs (distributed worker management - god/monit for workers on
multiple machines along with visibility into the state)? Should we
continue adding features to DelayedJob? Our fork had deviated from
master and the merge (plus subsequent testing) was not going to be fun.</p>
<p>We made a list of all the things we needed on paper and started
re-evaluating a lot of the existing solutions. Kestrel, AMQP,
beanstalkd (persistence still hadn't been rolled into an official
release a year after being pushed to master).</p>
<p>Here's that list:</p>
<ul>
<li>Persistence</li>
<li>See what's pending</li>
<li>Modify pending jobs in-place</li>
<li>Tags</li>
<li>Priorities</li>
<li>Fast pushing and popping</li>
<li>See what workers are doing</li>
<li>See what workers have done</li>
<li>See failed jobs</li>
<li>Kill fat workers</li>
<li>Kill stale workers</li>
<li>Kill workers that are running too long</li>
<li>Keep Rails loaded / persistent workers</li>
<li>Distributed workers (run them on multiple machines)</li>
<li>Workers can watch multiple (or all) tags</li>
<li>Don't retry failed jobs</li>
<li>Don't "release" failed jobs</li>
</ul>
<h3>Redis to the Rescue</h3>
<p>Can you name a system with all of these features:</p>
<ul>
<li>Atomic, O(1) list push and pop</li>
<li>Ability to paginate over lists without mutating them</li>
<li>Queryable keyspace, high visibility</li>
<li>Fast</li>
<li>Easy to install - no dependencies</li>
<li>Reliable Ruby client library</li>
<li>Store arbitrary strings</li>
<li>Support for integer counters</li>
<li>Persistent</li>
<li>Master-slave replication</li>
<li>Network aware</li>
</ul>
<p>I can. Redis.</p>
<p>If we let Redis handle the hard queue problems, we can focus on the
hard worker problems: visibility, reliability, and stats.</p>
<p>And that's <a href="https://github.com/defunkt/resque#readme">Resque</a>.</p>
<p>With a web interface for monitoring workers, a parent / child forking
model for responsiveness, swappable failure backends (so we can send
exceptions to, say, Hoptoad), and the power of Redis, we've found
Resque to be a perfect fit for our architecture and needs.</p>
<p><a href="https://github.com/defunkt/resque"><img src="https://img.skitch.com/20091102-rpekt191w28xfhwyussru44nsw.png" alt="web ui" /></a></p>
<p>We hope you enjoy it. We certainly do!</p>
defunkt
tag:github.com,2008:Post/541
2009-11-02T20:21:47-08:00
2009-11-02T20:21:57-08:00
Commons Based Peer Production
<p><a href="https://github.com/ab5tract">ab5tract</a> has a <a href="https://mastersofmedia.hum.uva.nl/2009/11/01/git-virtue-github-and-commons-based-peer-production/">great post</a> looking at GitHub “through the lens of the ethics of commons-based peer production.”</p>
<p>A key quote which puts it in perspective for me is this:</p>
<blockquote>
<p>The software further induces virtue in its participants through the `git blame` function, which immediately calls up the person responsible for a commit. In practice it used as much to know who to praise as it is to know who to berate, but it fulfills one of the the paper’s common criteria for extant commons-based peer production: that of a mechanism to mitigate the potential impacts of malicious users. Slashdot has its moderation system, Wikipedia its editors, and git has `blame`. In fact this functionality is a crucial part of what enables the ‘virtue spreading virtue’ element of such peer production.</p>
</blockquote>
<div align="center"><a href="https://mastersofmedia.hum.uva.nl/2009/11/01/git-virtue-github-and-commons-based-peer-production"><img src="https://img.skitch.com/20091103-wtqrk9ppq3si3sxh2uf3kuwhj.png"/></a></div>
<p>Read <a href="https://mastersofmedia.hum.uva.nl/2009/11/01/git-virtue-github-and-commons-based-peer-production/">the blog post</a> for the whole scope. Thanks <a href="https://github.com/ab5tract">ab5tract</a>!</p>
defunkt
tag:github.com,2008:Post/540
2009-11-02T14:22:57-08:00
2009-11-02T16:17:57-08:00
GitHub Meetup SF #9
<center>
<p><img src="https://img.skitch.com/20091102-nefu38n6pc6crqr5e9ump6tge6.jpg"/></p>
</center>
<p>Its time for a meetup! This week we’ll be going to a faraway place, a place once thought to only exist in legend, a land they call the ‘Richmond’. According to local lore there’s a bar called <a href="https://maps.google.com/maps?hl=en&ie=UTF8&q=buckshot&fb=1&gl=us&hq=buckshot&hnear=San+Francisco,+CA&cid=0,0,1774702738057692503&ei=9DzvSprjE42cswPYuNj1Aw&ved=0CCsQnwIwAw&ll=37.782299,-122.460887&spn=0.00987,0.017316&t=h&z=16&iwloc=A">Buckshot</a> where you can play skee ball and shuffleboard while you shoot the breeze. And even if you dont actually spot any mythical beasts, you might get a chance to talk to Chris about <a href="https://github.com/blog/517-unicorn">unicorns</a>. 8pm Thursday November 5th.</p>
luckiestmonkey
tag:github.com,2008:Post/538
2009-11-02T11:59:36-08:00
2009-11-02T12:03:59-08:00
Load Balancing at GitHub
<p>We’ve had a number of inquiries into why we chose <a href="https://www.vergenet.net/linux/ldirectord/">ldirectord</a> as our primary load balancer for the new GitHub architecture. As I’ve mentioned before (and more on this later), we’ve hired the excellent team at <a href="https://anchor.com.au">Anchor</a> as our server specialists. Our team lead over there is Matt Palmer, and we left the choice of load balancer up to him and his expertise. He’s taken it upon himself to explain the driving factors behind his choice, and it makes for an enlightening read if you’re interested in such things. Just head on over to the Anchor blog to check it out:</p>
<p><a href="https://www.anchor.com.au/blog/2009/10/load-balancing-at-github-why-ldirectord/">https://www.anchor.com.au/blog/2009/10/load-balancing-at-github-why-ldirectord/</a></p>
<p>Be sure to read the comments where the author of <a href="https://haproxy.1wt.eu/">haproxy</a> weighs in on the post and adds some additional perspective. Like most technology decisions, there is no single correct answer. Only tradeoffs and preferences.</p>
mojombo
tag:github.com,2008:Post/537
2009-10-30T12:00:13-07:00
2009-10-30T12:04:08-07:00
Post-Mortem of This Morning's Outage
<p>At 07:53 <span class="caps">PDT</span> this morning the site was hit with an abnormal number of <span class="caps">SSH</span> connections. The script that runs after an <span class="caps">SSH</span> connection is accepted makes an <span class="caps">RPC</span> call to the backend to check for the existence of the repository so that we can display a nice error message if it is not present. The vast number of these calls that came in simultaneously caused some delays in the backend that cascaded to the frontends and resulted in a piling up of the scripts waiting for their <span class="caps">RPC</span> results. This, in turn, caused load to spike on the frontends further exacerbating the problem. I removed the <span class="caps">RPC</span> call from the <span class="caps">SSH</span> script to prevent this bottlenecking and soon after the barrage of <span class="caps">SSH</span> connections ceased.</p>
<p>Another unrelated problem caused the outage to continue even after the <span class="caps">SSH</span> connection load became nominal. Last night I deployed some package upgrades to our <span class="caps">RPC</span> stack that had tested out fine in staging for two days. While debugging the <span class="caps">SSH</span> problem, I restarted the backend <span class="caps">RPC</span> servers to rule them out as the problem source. This was the first time these processes had been restarted since the package upgrades, as they were deemed to be backward compatible with the changes and staging had shown no problems in this regard. However, it appears that these restarts put the <span class="caps">RPC</span> servers into an unworking state, and they began serving requests very sporadically. After failing to identify the problem within a short period, we decided to roll back to the previous known working state. After the packages were rolled back and the daemons restarted, the site picked up and began operating normally.</p>
<p>Full site operation returned at 09:34 <span class="caps">PDT</span> (some sporadic uptime was seen during the outage).</p>
<p>Over the next week we will be doing several things:</p>
<ul>
<li>Further testing on staging to attempt to reproduce the behavior seen on production and resolve the underlying issue.</li>
<li>Better <span class="caps">SSH</span> script logging to more quickly identify abnormal behavior.</li>
<li>Working towards a more fine-grained rolling deploy of infrastructure packages to limit the impact of unforeseen problems.</li>
</ul>
<p>On a positive note, the outage led me to identify the source of several subtle bugs that have been eluding our detection for a few weeks. We are all rapidly learning the quirks of our new architecture in a production environment, and every problem leads to a more robust system in the future. Thanks for your patience over the last month and during the coming months as we work to improve the GitHub experience on every level.</p>
mojombo
tag:github.com,2008:Post/536
2009-10-29T09:40:49-07:00
2009-10-29T09:40:56-07:00
jQuery!
<p><a href="https://jquery.com/">jQuery</a>, which we use for GitHub itself, is now hosted right here: <a href="https://github.com/jquery/jquery">https://github.com/jquery/jquery</a></p>
<div align="center"><a href="https://github.com/jquery/jquery"><img src="https://img.skitch.com/20091029-dbpp26n16mqwhxgrbscsgabf89.png"/></a></div>
<p>If you’ve never contributed to the project, now’s a great time. Welcome, team!</p>
defunkt
tag:github.com,2008:Post/535
2009-10-26T14:06:06-07:00
2009-10-26T14:07:06-07:00
Setting up a Mac to Work with Git and GitHub
<p>Bob Silverberg just posted a nice guide to <a href="https://www.silverwareconsulting.com/index.cfm/2009/10/26/Setting-up-a-Mac-to-Work-with-Git-and-GitHub">Setting up a Mac to Work with Git and GitHub</a>. Thanks Bob!</p>
tekkub
tag:github.com,2008:Post/534
2009-10-25T20:40:53-07:00
2009-10-25T20:42:55-07:00
GitHub Rebase #29
<p>Time to get your Rebase on! Send me a message about your project if you want to see it featured here, and please check out the Rebase <a href="https://rebase.github.com/howto.html">howto</a> as well. I’d love to see more than just web development stuff too. (but don’t stop that either!) Perhaps a collection of computer graphics related projects? AI? Music? You name it, just <a href="https://github.com/qrush">send me a message!</a></p>
<p style="text-align:center;"><img src="https://cloud.github.com/downloads/rebase/rebase.github.com/GottaGitItOnLP.jpg" alt="" /></p>
<h3>Featured Project</h3>
<p><strong><a href="https://github.com/subsonic/SubSonic-3.0">SubSonic</a></strong> is not your average <span class="caps">ORM</span> for .<span class="caps">NET</span>. This C# library is a veritable workhorse that follows <a href="https://en.wikipedia.org/wiki/Convention_over_configuration">convention over configuration</a> and even allows developers to choose different data mapping paradigms, one such being <a href="https://martinfowler.com/eaaCatalog/activeRecord.html">Active Record</a>. I wasn’t kidding about the workhorse bit: out of the box, it’s got support for <span class="caps">LINQ</span>, connecting to multiple DBs, and even a <a href="https://subsonicproject.com/docs/MVC_Starter_Template">starter app</a> to get you going. There’s an unbelievable amount of information on how to use it with your flavor of .<span class="caps">NET</span> on <a href="https://subsonicproject.com/docs/">their wiki</a>, and definitely check out <a href="https://subsonicproject.com/docs/Comparisons">how this shapes up</a> compared to the other available ORMs. Besides, who else can beat screencasts set to <a href="https://subsonicproject.com/docs/The_5_Minute_Demo">Led Zeppelin</a> and <a href="https://subsonicproject.com/docs/T4_Templates">Rush</a>?</p>
<h3>Notably New Projects</h3>
<p><strong><a href="https://github.com/evanmiller/ChicagoBoss">ChicagoBoss</a></strong> claims to bring together the best of Rails and Django into the world of Erlang. Sounds neat, but how exactly does that work? Check out the <a href="https://www.chicagoboss.org/example.html"><span class="caps">MVC</span> examples here</a> and even some fledgling <a href="https://www.chicagoboss.org/api-view.html"><span class="caps">API</span> docs</a> for how this framework is shaping up. Another neat thing: <a href="https://1978th.net/tokyocabinet/">Tokyo Tyrant/Cabinet</a> support is built in, so you can key/value store to the list of buzzwords that Boss already has. Get forking!</p>
<p><strong><a href="https://github.com/thedarkone/firepicker">Firepicker</a></strong> is a Firefox extension that adds a color picker into <a href="https://getfirebug.com/">Firebug</a>. Now, you won’t have to fumble around trying to find a specific application on your OS to do this when you’re playing with <span class="caps">CSS</span> in Firebug. Secondly, if you’re new to <span class="caps">XUL</span> and Firefox development in the first place, this is a great project to look at to get started. Check out some screenshots and how to install it <a href="https://thedarkone.github.com/firepicker/">here</a>.</p>
<p><strong><a href="https://github.com/Papervision3D/Papervision3D">Papervision3D</a></strong>‘s readme may be short, but don’t let that deter you. It’s better if you just <a href="https://www.papervision3d.org/">go look for yourself.</a> Ok, so it’s a fully immersable 3D world written in ActionScript that’s open source. Whoever the first person to write a game for this environment is, please invite me to your private beach and/or yacht. There could be a ton of neat ways to implement this: perhaps a more 3D StreetView, planetarium, panoramas, the list goes on and on. Papervision’s <a href="https://dev.papervision3d.org/">dev blog</a> has a lot of neat related links too.</p>
qrush
tag:github.com,2008:Post/532
2009-10-21T11:16:35-07:00
2009-10-21T11:27:15-07:00
GitHub Meetup SF #8
<center>
<p><img src="https://images-0.redbubble.net/img/art/size:large/view:main/2712622-2-blackbird-fly-away.jpg" /></p>
</center>
<p>Come get your drink on with the people of the Hub at <a href="https://maps.google.com/maps?hl=en&ie=UTF8&q=blackbird+san+francisco&fb=1&gl=us&hq=blackbird&hnear=san+francisco&cid=0,0,6763374940088794175&ei=_E3fSvCtA4S0swO3ntzdDw&ved=0CAsQnwIwAA&ll=37.768086,-122.429688&spn=0.009736,0.017316&t=h&z=16&iwloc=A">Blackbird</a> this Thursday October 22nd at 8pm. Also, be sure to look out for a possible Drinkup:Shanghai, China edition in the next few days- PJ and Scott are headed out for <a href="https://kungfurails.com/">KungFuRails</a> right now!</p>
luckiestmonkey