Dont worry fellow San Franciscans! There’s still a drinkup slated for the home front. We’ll be in SOMA at John Collins this Thursday December 3rd at 8:00pm.

That’s right, three different drinkups, three different states. A free Large account for life to anyone who can make it to all of them (proof obviously required. Also, the recipe for your teleportation device).

I’ll be in Philadelphia this week and my pal trotter and I will be orchestrating a GitHub Drinkup on Thursday, December 3rd at 8:30pm at National Mechanics (map). If you’re in town, come on by to escape the cold and grab a brew with some good friends. First drink’s on us!

I’ll be in NYC this week speaking about GitHub (RSVP if you haven’t already) and hosting a GitHub Meetup.

The meetup will be Thursday, December 3rd at 8:30pm at Temple Bar (map).

Stop by if you’re a GitHub fan and say hi! The first drink’s on us.

The Changelog is a new blog and podcast which keeps you up to date on open source happenings.

While it seems to be mostly Ruby-centric, it also dives into JavaScript, Google’s Go, and some Cocoa.

A neat feature of the blog is the meta information available on each post, which shows the number of comments on that post as well as the number of GitHub forks and watchers for the project being profiled.

Follow along by checking out their twitter, or just start with their Rob Pike interview.

It’s great to see sites like this spring up. Another worth noting is the Django-centric Django Dose.

Thanks to pengwynn and adamstac for putting it together!

I’m pleased to announce that GitHub now hosts an official Git version of Erlang/OTP. The core Erlang team states:

Beginning with this release [R13B03] we will maintain (and update on a daily basis) a GIT repository on GitHub. The intention is that this will make it easier for users to contribute with bugfixes and new functionality and also easier for us to receive the contributions.

This marks a huge leap forward for the open source Erlang community. With this move, the core Erlang team has shown their dedication to an open development process for Erlang, and finally creates a standard way for Erlang hackers to submit patches to the project. Erlang/OTP is already an amazing project and by leveraging the social collaboration tools of GitHub, it will only get better!

Today we’re rolling out Phase 1 to our GitHub Jobs search engine. Under your Account Settings page, there’s a new tab called Job Profile.

There you’ll see a simple text area to paste in your resume (or whatever you’d like really), along with a checkbox to confirm you’re available for hire. This is an opt-in program, if you’re not looking for work there’s nothing to do.

We think the code you’ve put on GitHub is an extremely valuable tool in finding you a great place to work, so now is the time to dust off the code you’re afraid to push and get people excited about it. Also, make sure you’ve filled out your profile information: your name, location, blog/website, and email. All of that information is going to be help you find work.

Phase 2 of the GitHub Jobs rollout is to expose this information via a private search interface, but we need to know if you’re available for hire first. Please note that none of the data you enter will leave GitHub.

Step 1 to finding a new job is just a checkbox away!

Do you want to learn about OEmbed? OAuth? Are you dying to hear more about Resque? Is comet still just a buzzword to you? Are the mysteries of BERT-RPC keeping you up at night?

Well, sir or madam, you are in luck!

l’ll be talking about GitHub at the Gilt Group’s “Expert Talk” on December 2nd in NYC. Joining me will be leah discussing OEmbed and OAuth.

Make sure you RSVP if you want to attend. See you there!

We spend a lot of time optimizing the front end experience at GitHub. With that said, our asset (css, javascript, images) packaging and serving has evolved to be the best setup I've seen out of any web application I've worked on in my life.

Originally, I was going to package what we have up into a plugin, but realized that much of our asset packaging is specific our particular app architecture and choice of deployment strategy. If you haven't read up on our deployment recipe read it now. I cannot stress enough how awesome it is to have 14 second no downtime deploys. In any case, you can find the relevant asset bundling code in this gist

Benefits of our asset bundling

• Users never have to wait while the server generates bundle caches, ever. With default Rails bundling, each time you deploy, each request until your server generates the bundle has to wait for the bundle to finish. This makes your site pause for about 30s after each deploy.
• We can use slower asset minifiers (such as YUI or Google Closure) without consequence to our users.
• Adding new stylesheets or javascripts is as easy as creating the file. No need to worry about including a new file in every layout file.
• Because we base our ASSET_ID off our git modified date, we can deploy code updates without forcing users to lose their css/js cache.
• We take full advantage of image caching with SSL while eliminating the unauthenticated mixed content warnings some browsers throw.

Our asset bundling is comprised of several different pieces:

1. A particular css & js file structure
2. Rails helpers to include css & js bundles in production and the corresponding files in development.
3. A rake task to bundle and minify css & javascript as well as the accompanying changes to deploy.rb to make it happen on deploy
4. Tweaks to our Rails environment to use smart ASSET_ID and asset servers

CSS & JS file layout

Our file layout for CSS & JS is detailed in the README for Javascript, but roughly resembles something like this:

public/javascripts
|-- README.md
|-- admin
| |-- date.js
| `-- datePicker.js
|-- common
| |-- application.js
| |-- jquery.facebox.js
| `-- jquery.relatize_date.js
|-- dev
| |-- jquery-1.3.2.js
| `-- jquery-ui-1.5.3.js
|-- gist
| `-- application.js
|-- github
| |-- _plugins
| | |-- jquery.autocomplete.js
| | `-- jquery.truncate.js
| |-- application.js
| |-- blob.js
| |-- commit.js
`-- rogue
    |-- farbtastic.js
    |-- iui.js
    `-- s3_upload.js

I like this layout because:

• It allows me to namespace specific files to specific layouts (gist, github.com, iPhone, admin-only layouts, etc) and share files between apps (common).
• I can lay out files however I want within each of these namespaces, and reorganize them at will.

Some might say that relying on including everything is bad practice -- but remember that web-based javascript is almost exclusively onDOMReady or later. That means that there is no dependency order problems. If you run into dependency order issues, you're writing javascript wrong.

Rails Helpers

To help with this new bundle strategy, I've created some Rails helpers to replace your standard stylesheet_link_tag and javascript_include_tag. Because of the way we bundle files, it was necessary to use custom helpers. As an added benefit, these helpers are much more robust than the standard Rails helpers.

Here's the code:

Our application.html.erb now looks something like this:

<%= javascript_dev ['jquery-1.3.2', "#{http_protocol}://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"] %>
<%= javascript_bundle 'common', 'github' %>

This includes jQuery and all javascript files under public/javascripts/common and public/javascripts/github (recursively). Super simple and we probably won't need to change this for a very long time. We just add files to the relevant directories and they get included magically.

For pages that have heavy javascript load, you can still use the regular javascript_include_tag to include these files (we keep them under the public/javascripts/rogue directory).

Bundle rake & deploy tasks

The javascript_bundle and stylesheet_bundle helpers both assume that in production mode, there'll be a corresponding bundle file. Since we are proactively generating these files, you need to create these manually on each deploy.

Throw this into lib/tasks/bundle.rake and the corresponding YUI & Closure jars and then run rake bundle:all to generate your javascript. You can customize this to use the minifying package of your choice.

To make sure this gets run on deploy, you can add this to your deploy.rb:

Tweaks to production.rb

The last step in optimizing your asset bundling for deploys is to tweak your production.rb config file to make asset serving a bit smarter. The relevant bits in our file are:

There's three important things going on here.

First— If you hit a page using SSL, we serve all assets through SSL. If you're on Safari, we send all CSS & images non-ssl since Safari doesn't have a mixed content warning.

It is of note that many people suggest serving CSS & images non-ssl to Firefox. This was good practice when Firefox 2.0 was standard, but now that Firefox 3.0 is standard (and obeys cache-control:public as it should) there is no need for this hack. Firefox does have a mixed content warning (albeit not as prominent as IE), so I choose to use SSL.

Second— We're serving assets out of 4 different servers. This fakes browsers into downloading things faster and is generally good practice.

Third— We're hitting the git repo on the server (note our deployment setup) and getting a sha of the last changes to the public/stylesheets and public/javascripts directory. We use that sha as the ASSET_ID (the bit that gets tacked on after css/js files as ?sha-here).

This means that if we deploy a change that only affects app/application.rb we don't interrupt our user's cache of the javascripts and stylesheets.

Conclusion

What all of this adds up to is that our deploys have almost no frontend consequence unless they intend to (changing css/js). This is huge for a site that does dozens of deploys a day. All browser caches remain the same and there isn't any downtime while we bundle up assets. It also means we're not afraid to deploy changes that may only affect one line of code and some minor feature.

All of this is not to say there isn't room for improvement in our stack. I'm still tracking down some SSL bugs, and always trying to cut down on the total CSS, javascript and image load we deliver on every page.

We've always had the ability to embed multiple file gists:

But today we added the ability to embed specific files in a multi-file gist!

We also added permalinks next to each file name so you can hard link to specific files like so

Enjoy!

In SF for RubyConf? Join us this Thursday the 19th at Zeitgeist (map) starting at 9pm!

Zeitgeist has pitchers and ample outside seating, so bring a jacket. Also: cash only.

Coming from the conference? Take BART to the 16th st Mission stop then walk North on Valencia (map)

See you there!

It’s the last stop on our Europe tour and we’re capping things off with an evening at the Royal George 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!

View Larger Map

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 Gloria Flames 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!

If for some reason we need to change venues, check our twitter accounts “mojombo”, “pjhyett”, and “chacon” for updates.

View Larger Map

This is the second of many themed Rebases to come…our first was the book edition. In related news, the column has also been going on for over a year now! If you’ve got ideas for projects to feature or themes, don’t be afraid to message me.

Featured Project

ooc 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 set it up. The language has some neat features: everyone’s favorite generic types, a clean import/use system that makes Ruby’s require look like yesterday’s news, and the cover 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, check it out.

Notably New Projects

rock 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.

ooc-sqlite3 is an SQLite driver that’s also just getting off the ground, but it’s starting to pick up some steam. Next stop: a web framework!

woot 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!

ooc-glew uses GLEW to open up the power of OpenGL to ooc. There’s also a little Ruby magic baked in to generate the bindings since there’s a lot of functions.

Stirling3D 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.

ooc-yajl is a set of bindings to yajl, a former featured project that is a lightning fast JSON parsing library. It’s also a neat example of how easy it is to hook into C libraries and how the .use files work.

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.

I previously covered the updated dashboard repository lists and gist improvements, but I haven't had a chance to go over the new userbox, profile pages, account pages, and dashboard headers.

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.

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.

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.

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.

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! :)

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.

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.

Tom, PJ, and Scott will be hanging out at MOOD Club 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!