The GitHub Blog: Watercooler

Welcome to the first edition of Game Bytes, where we highlight some of the latest and greatest game development-related repositories, success stories, and other game-related tidbits.

I talked with David Czarnecki (GitHub, Twitter), lead engineer at Agora Games about some of their open source work. You might know David from a RailsConf or two or maybe his award-winning open source work? If you're at all interested in game development, for any platform, you might be interested in this...

Background

Lee Reilly: Tell me a little about Agora Games.

David Czarnecki: We develop software and systems to provide online services for video games. This may be functionality like online profiles, leaderboards, UGC, or matchmaking; but it may also involve developing functionality that game developers do not have time to develop within a game's lifecycle, like challenges or tournaments. We are also a part of Major League Gaming, so we develop all of their online properties. Even if you haven't heard of our company, you've probably heard of or have played some of the games that we've been involved with.

Lee: Wow, Impressive portfolio!

David: blushes Awwwwwwwww, shucks. It's crazy to think back on all the games we've been been involved with, like every Guitar Hero title since Guitar Hero 3 and Band Hero too. We have to update our portfolio to include some of our more recent project work like Saints Row: The Third and Gotham City Impostors. And I'm happy to say we're also working on ... oh ... I can't actually talk about those projects ;)

Open Source Work

Lee: In addition to these large commercial projects that you're involved with, you have a large number of open source projects that you've made available to the community. How do you decide what projects you're going to open source?

David: It's driven entirely by the engineering team. Typically these are components that we're extracting from larger projects like our Hydra platform or Major League Gaming sites like Starcraft 2 Battles or MLG Player Profiles. I guess that's one of the benefits of having a responsible engineering culture. We are treated like adults and the company respects and actively encourages us to be involved with the open source community and to talk about our work at local user groups and at conferences.

Lee: Your Leaderboard project looks like an extremely valuable and time-saving resource for the community. You've made it available in a number of languages. Have there been any challenges with porting it or keeping it up to date?

David: So leaderboard is a gem to provide leaderboard (scoreboard) functionality backed by Redis. The Ruby implementation is what I'd call the "reference implementation." In terms of maintained functionality, our Python implementation tracks Ruby since that's what we use in our middleware platform. The other "fuller" implementations: PHP, Java, Scala, well, sadly, not so much. It's not that I don't have the desire to maintain the other versions, it's the need. All of our systems are written in Ruby or Python, so those libraries get the most attention.

I've selfishly used porting the Ruby leaderboard library to learn other programming languages. What I like about porting the library is that it's a very specific piece of functionality, it's well tested, requires integration of a client library and gives me a chance to learn how to package all of that up and try to use the best practices in a new language. I definitely need to devote some time to showing the other implementations some love.

Lee: Any open source or indie games you know of that are using it?

I don't personally know of any indie games that are using the leaderboard library. If anything, I'd expect it to be a service that a game might use to provide leaderboard functionality. I know specifically of some uses of the library outside of video games. For example, check out the WeightTraining.com leaderboards. One of the co-founders of the site even contributed code back to the leaderboard gem to allow you to store richer data alongside the leaderboard. Yay open source!

Lee: You have a weekly Game Face blog post summarizing your weekly internal/external open source contributions.

David: We do!

Lee: awkward silence

David: I'm glad there's at least one person out there who reads the blog :) I definitely drew inspiration from thoughtbot's This Week In Open Source in starting the weekly blog post. Obviously, I had to put a gaming spin on its name. At the beginning of 2012, I did an assessment of all the open source work we had done in 2011, but it's the type of information that needs more regular attention. It doesn't do the larger community any good to find out about our projects several months or a year after they've been available. I wanted to have a single place where we could round up the open source contributions from our team, regardless of whether or not they're Agora Games projects. We're currently at 24 projects that our engineers have open sourced in 2012.

It's a pretty straightforward process to put together the weekly Game Face blog post. Each week I create a new "shell" blog post and as I see contributions to open source projects in HipChat throughout the week, I'll make notes in the blog post. GitHub Services FTW! Thursday afternoon I usually ping the team to say, "Here's what this week's Game Face looks like, did I miss anything?" I think that also helps serve as a reminder to demonstrate that we fully support and encourage open source efforts. Friday morning I do some final edits to the blog post after our daily standup and then I publish it. Obviously, this could be automated, but a technical blog post is pretty easy to cobble together. Largely, you're putting some extra words around CHANGELOG bulletpoints :)

Lee: I see that you hold 24-hour hackathons at Agora Games. Any notable open source projects come out of that?

David: Our Hack-A-Thons at Agora Games are a lot of fun. We started doing them a couple of years ago and now we're doing them regularly in 2012. Every other month, it goes like this: Thursday afternoon at 4 PM there's a kickoff meeting where the company meets to discuss project ideas and form teams. We are very loose as to what constitutes a work-related project in that you can pretty much work on anything, but you have to demonstrate something at 4 PM on Friday during the wrapup meeting. For those 24 hours, you're left to feverishly develop and flesh out your idea.

We've had a number of open source projects come out of our Hack-A-Thons. A few of those are

chai - a mocking and stubbing framework for Python similar to mocha in Ruby,
strumbar - a wrapper around ActiveSupport::Notifications with preconfigurations for basic instrumentation to be sent to statsd, and
bracket_tree - a bracketing system built to convey the visual representation, progression logic, and seed mapping in a serializable format.

Obviously, there are more open source projects that have come out of the Hack-A-Thons, however, I think some of the best projects have been from folks outside of engineering. For example, three of our producers put together a video a couple years ago to showcase Agora Games and the city of Troy, NY. Everyone can contribute something awesome to a Hack-A-Thon. It doesn't necessarily have to be code.

As an aside, the music for that video was from our producer Clarke Foley's ex-band Action Action. It blows me away that he has albums on iTunes, has opened for Flock of Seagulls (how sick is that?) and sits a few desks away from me!

Lee: Sick! I used to sit next to Scott "Dragon" Chacon, professional dodgeball player and author of some book. I know what it's like to be starstruck.

David: Sweet!

Lee: Dude!

David: Sweeeeet!

Lee: Duuuuude!

David: Suh-weet!

Lee: So yeah, I'd love to see more of the game developer community involved in open source.

David: I do too and I wrote about this on the AltDevBlogADay blog that I'm a contributor to in a post called, "Put On Your Game Face". I can't think of a game developer that doesn't use open source software in some capacity. Only good things can come from allowing your organization to contribute back to the open source community without a lot of the bureaucracy. As a gaming community, we need to keep preaching awareness of open source efforts like the Mojang Minecraft API or id Software on GitHub or GitHub support for the DCPU-16 assembly language or your collection of games-related things on GitHub.

Agora Games actually got its big break from open development. Early on, engineers at the company had put together a modification for Half-Life 2 called Plan of Attack. It was one of the earlier modifications to Half-Life 2 where statistics about your gameplay were sent to our servers that you could then view on the web. Word got out to the folks at Vicarious Visions (they developed the Wii ports of Guitar Hero), and subsequently to their parent company, Activision, that we did online functionality. And that was how we landed Guitar Hero 3. The rest, shall we say, is history :) So, open source and open development with respect to video games is near and dear to our hearts.

Life before GitHub

Lee: Agora Games was founded in 2005; the Agora Games GitHub Organization didn't exist until 2009. What were you using previously? Has Git / GitHub helped?

David: To put it in Mad Max terms, I refer to pre-2009 as the "before time" or the "long, long ago". As with many organizations, before Git we used Subversion. Most of us probably take for granted how easy it is to use Git without a central server, how easy it is to branch, how easy it is to stash changes when you're working on something and need to save that work, and so on.

If you look at the capabilities that GitHub provides beyond simply hosted Git repositories, it quickly becomes a no-brainer that we should be spending money for the service. Integrated wikis, issues, documentation via Markdown (or other), collaborators and teams, pull requests, service integrations, and so on. GitHub makes that awesome and seamless so we can focus on our core competency, which is developing software and systems to provide online services for video games.

GAME OVER

If you have any comments, questions or suggestions for future editions of Game Bytes please email gamebytes@github.com.

In this edition of The RefLog, we talk with Bryan Helmkamp. A Rubyist, GitHub User #19, and creator of Code Climate. Matthew McCullough sat down with him to talk about what Code Climate is and what its future may hold, especially for open source projects hosted on GitHub.

Matthew McCullough: When did you start formulating the ideas that became Code Climate? What are some of its major milestone dates in addition to the recent commercial launch?

Bryan Helmkamp: I had been interested in static analysis tools like Flog and Flay for years, but could never find a great way to work them into my flow. At the same time, I've worked on a number of large, long-running Rails projects and observed that even excellent developers with great intentions continued to struggle with keeping code quality high over the long term. These were high functioning, Agile teams that used techniques like pair programming, and so I started thinking if static analysis could help.

Looking at my Git log, the first commit was on March 6th, 2011, so it's been about a year and half in the making. The first program I built just counted the number of lines of code in different layers of your app (like rake stats) and charted it over time. It was cool and pretty but not that useful. This past March, about a year after I started building the product, I left my full time job to focus on Code Climate. The company is 100% bootstrapped, so that was a big milestone.

MM: Was there any inspiration from products like Sonar for Java?

BH: Most of the inspiration was from metric_fu. It did some things really well, and I thought, "What if this data was available on a hosted website, and automatically kept up to date?". The vision today is much larger than that, of course, but that was the start. Eventually I found Sonar in my research of the space. I've never run it myself, but it seems to be very detailed and comprehensive. So there's good inspiration there, but Code Climate is focused on being as actionable and easy to use as possible. That focus has led to more simplicity in the user experience than what you see in Sonar.

MM: What made you realize that there would be a market for this? What would make someone want to pay for this?

BH: What I started to do, when I felt like there could be something useful to me there, was putting together some wireframes for a "first cut" at what I thought an experience might be like. At that time, the idea that I was playing around with, just as something super simple, was just email based with no web frontend at all. It was like, what if you got an email that looked like this, every week and it had some information about how the code base had changed. I put that together in Balsamiq mockups and started asking people who I knew in the Ruby community for a few minutes of their time when I ran into them at things like conferences and whatnot. I would sit down with them and get their take on it and ask them questions about what they were currently doing to manage quality.

I also did a survey that I sent out over twitter asking people if they used static analysis tools and about their experience with that kind of thing. It was a kind of qualitative and quantitative research process I went through to get the confidence that there was an initial foothold. It was also comforting that the product is completely bootstrapped and that I don't need there to be a huge market for this business to payback VC investors or anything like that. I was really just trying to do something that I thought would be interesting and useful to me and people who had similar experiences. So, yeah, I did a lot of that stuff before really building too much of the product.

MM: Do you feel the feedback helped to shape things dramatically by correcting assumptions you had about what you were building or was it more of a confirmation that you were on the right path?

BH: I'd say somewhere in between. I think the core is still very similar to what it was in those initial wireframes using emails though much of that has migrated onto the web, at this point. There are still emails, but they are slimmed down a bit, partially because it's easier to implement things in a website than a HTML email.

MM: (Sarcastically) Wait a minute, you mean supporting different email clients is worse than the browser wars?

BH: (Laughing) Yeah, much worse. Fortunately, I don't have to support very many browsers and email clients.

So that part was fortunate and a lot of the feedback lead me to really focus on clarifying the user experience. One of the biggest improvements to Code Climate, based on the feedback I've heard since launch, was the introduction of the rating system. That's something that is unique, as far as Ruby static analysis, to the tool. Code Climate gives every class and module a rating from "A" to "F". Those ratings are an aggregation of different types of static analysis information and they're really aimed at making this sort of digestible grade, just like you got in school, for each part of the code base. That really unlocked a lot of interesting things you can do, cause now you can look at this high level of which grades changed. What are the things that are currently failing verses what are the things that are in a passing grade. So, that was the biggest change that the product has undergone since launch. When it launched, it didn't have that and it was all just numbers. So, it would say, for example, "complexity is 37 and your duplication is 46". It will still tell you those things but the grades are the focus now.

MM:The slogan is "Code Climate is hosted quality metrics for Ruby apps." Are there any plans to go beyond Ruby?

BH: I'm focusing on Ruby first because I'm a Rubyist at heart and there's a great set of open source static analysis tools available to build from. Code Climate stands on the shoulders of those tools. It will support other languages someday in the future, but right now I'm focused on making the experience excellent for Ruby. To that end, there are more Ruby/Rails-specific code insights coming soon.

MM: What's the category of user or project that should be running Code Climate? Newcomer to Ruby? Veteran? Small project? Large project?

BH: I know people and projects that meet all of those descriptions that have found benefit in Code Climate, but the sweet spot is definitely above-average teams maintaining Rails applications over the long term. Beyond a certain code base size and team size, the natural direction is for an application to become less maintainable over time. Code Climate is designed to help teams change that.

The idea with Code Climate is that it should be approachable by anybody on a team, at varying skill levels, to help the whole team produce better output. Generally with teams, you're going to have a mix of your senior engineers and also more junior engineers. Often what I see is a more senior engineer or hands-on developer-manager role is the person who sets this up, but the data and information is being made available and communicated to the whole team and you want everyone to be able to act on it.

MM: Would I be accurately summarizing in saying, if someone had limited time, Code Climate grade letter score and color coding is meant to allow them to make some improvement even though they are unlikely to bring everything up to an "A"?

BH: I think that's a good paraphrase. Except that I would add that I would never recommend that anyone ever try to get all "A's" in Code Climate. The guidance that I like to give around Code Climate is that it's not a comprehensive to-do list of things that you need to fix. Everything that Code Climate identifies isn't necessarily something that needs to be worked on. So, what I would really focus on is not having classes that are failing. So, no "D's" or "F's". That's the way that I like to use the tool. The way I do that is two fold. One, don't let classes start failing. If things are in decent shape, keep them in good shape. If it's a "C", that's fine, just don't let it cross that line. Then, if you're working on classes which are failing right now, try to follow the "Boy Scout Rule" and try to leave things a little bit better than you found them. Eventually, you'll end up with everything getting passing grades.

MM: Are you actively trying to find other channels to promote, such as at conferences, to get more open source into Code Climate. Do you feel this would sort of "lift all boats", so to speak, in the open source community if there was significant number of projects using Code Climate?

BH: Open source projects have been in a sort of private beta, so far. However, with this interview I'd like to get as many open source projects on it as are interested in using it. Conferences are also going to be a big part of that, for sure. I'm interested in any channels that are good ways to reach people.

MM: Are there any very interesting discoveries that you've made by running Code Climate on an OSS project? Any particular ones that have had a positive reaction to it?

BH: While the OSS support is pretty new, the reaction to it from the OSS community has been very positive. It's great to see that so many project maintainers are looking for ways to ensure they ship high quality RubyGems. This is also apparent from the rapid uptake of Travis CI.

The team building Data Mapper 2 was one of the earliest OSS adopters and they've been using it to refactor as they go. I don't recommend anyone strive to get all "A"s in their Code Climate ratings, but Virtus, a DM2 component, does.

MM: Do you feel like the infrastructure is well prepared for an influx if say, a thousand new projects in the next week signed on? Is it ready to take that on?

BH: Yeah, I think it will be fine. The nice thing is that the web requests don't actually do any processing. So, its just a big Resque farm that records things into Mongo and then pulling out pages is pretty straight forward. It is pretty resilient to the number of projects that get added, so I'm not concerned.

MM: What's the next area of enhancement focus for Code Climate?

BH: I try not to comment too much publicly about functionality that's not ready yet, but I can give you a sense of what I'm thinking about. I'm going to keep working to make it as easy as possible to integrate Code Climate into your day-to-day development process. It's not enough to have metrics and activity feeds on the site and send weekly summary emails. So, it's going to do more to guide teams through the process of getting their code base in shape over time and keeping it there.

We hope you enjoyed this edition of The RefLog! If you have any suggestions for future projects or communities that you'd like to see highlighted in The GitHub RefLog, tweet us @githubtraining.

The RefLog Team,
Jared, Kami, and Matthew

We're hosting our first ever OctoGala the evening of July 22nd. Join us for a night of Golden Gate Glamour, and help a worthy cause!

Put on your top hats, tails, and ball gowns, and come tip back some cocktails at Brick and Mortar. Polish up your dancing shoes and get ready for the music provided by our Noise Pop DJs. We’re providing the drinks and snacks, so all you need to worry about is how well you can do the Charleston.

Why are we dancing? We are raising money for Running Chicken, a non-profit aimed at providing education and support to women and children in need. By teaming with Rally.org, we have made sure that all your donations go straight to this amazing organization.

Space is limited, so to book your spot on the red carpet, simply go to https://rally.org/octogala, and click on “Give Now”.

The facts:

Sunday, July 22nd at Brick and Mortar
1710 Mission Street, Map
Doors open at 8:00 PM
Tickets available at https://rally.org/octogala

Today we are partnering with Andreessen Horowitz and announcing our first ever outside investment.

Why now?

In four short years we've done a lot we're really proud of. We've shipped great native apps like GitHub for Mac and GitHub for Windows. We've made using GitHub from within Eclipse even easier. We've contributed to killer open source projects like libgit2 and git. We've thrown hundreds of drinkups, sponsored tons of conferences, drawn a bunch of octocats, and, of course, made building software even better with github.com and GitHub Enterprise.

We've done all this without any outside investment. Our company has been profitable for years, is growing fast, and doesn't need money. So why bother?

Because we want to be better. We want to build the best products. We want to solve harder problems. We want to make life easier for more people. The experience and resources of Andreessen Horowitz can help us do that.

Why Andreessen Horowitz?

We loved it when Marc Andreessen proclaimed, "Software is eating the world."

Marc's venture firm, Andreessen Horowitz, is younger than GitHub. And like GitHub, they're trying to do things differently. They believe in software as the future of everything. They want to help founders build great companies. They clearly have no interest in the status quo of venture capital.

Over the past few months we've gotten to know Marc and one of his partners, Peter Levine, and we really like them. We wish we could hire them both, but they already have jobs. So instead we're going to work with them through their firm.

What's next?

We want GitHub to be even easier for beginners and more powerful for experts. We want GitHub everywhere—whether you use Windows or Mac or Linux or some futuristic computer phone that hasn't been invented yet—we want GitHub to be an awesome experience. We want to make it easier to work together than alone. We want to keep changing the way software is developed for the better by making collaborating easier and sharing a no-brainer.

We will continue to focus on making software development even better. And we're excited to partner with Andreessen Horowitz to help us make it happen.

Are you part of a software development team that's recently moved to GitHub? Where some team members are excited to use git for source control but you're more comfortable with Subversion? The good news is that you can all use the tools you already enjoy - GitHub repositories can be accessed from both Git and Subversion (SVN) clients.

This is an overview of how you can take advantage of the GitHub Flow from your favorite Subversion client.

The GitHub Flow involves iterating through the following steps for each feature/fix:

Create a topic branch from the latest master branch
Make commits in the topic branch until you're ready to merge it
Make a pull request to pull the topic branch into the master branch; discuss the changes, make more commits, etc. until the team is ready to merge it
Merge the pull request and deploy

Get Started

The first thing you'll want to do is a Subversion checkout. Since Git clones keep the working directory (where you edit files) separate from the repository data, there is only one branch in the working directory at a time. Subversion checkouts are different -- they mix the repository data in the working directories, so there is a working directory for each branch and tag you've checked out. For repositories with many branches and tags, checking out everything can be a bandwidth burden; so you should start with a partial checkout.

GitHub supports both Git and Subversion clients using the HTTP protocol, start by browsing to the repository page on github.com to get the HTTP clone URL:

Then get your checkout ready:

Start with an empty checkout of the repository. Browse to the repository page on github.com and use the HTTP clone URL:
```
$ svn co --depth empty https://github.com/widgetmakers/gizmo
Checked out revision 1.
$ cd gizmo
```
Get the 'trunk' branch. The Subversion bridge maps trunk to the git HEAD branch (usually master.)
```
$ svn up trunk
A    trunk
A    trunk/README.md
A    trunk/gizmo.rb
Updated to revision 1.
```
Get an empty checkout of the branches directory. This is where all of the non-HEAD branches live, and where you'll be making feature branches.
```
$ svn up --depth empty branches
Updated to revision 1.
```

Get Into The Flow

The first step is to create a topic branch from the latest master branch. From your svn client, make sure master is current by updating trunk; then use svn copy to create a branch.

$ svn up trunk
At revision 1.
$ svn copy trunk branches/more_awesome
A         branches/more_awesome
$ svn commit -m 'Added more_awesome topic branch'
Adding         branches/more_awesome

Committed revision 2.

You can see that the new branch is there from the web interface or a git client:

$ git fetch
From https://github.com/widgetville/gizmo
 * [new branch]      more_awesome -> origin/more_awesome

Write Some Code

Add some features, fix some bugs, and make plenty of commits along the way. This works like the Subversion you're used to - edit your file(s) and use svn commit to record your changes.

$ svn status
M       gizmo.rb
$ svn commit -m 'Guard against known problems'
Sending        more_awesome/gizmo.rb
Transmitting file data .
Committed revision 3.

$ svn status
?       test
$ svn add test
A         test
A         test/gizmo_test.rb
$ svn commit -m 'Test coverage for problems'
Adding         more_awesome/test
Adding         more_awesome/test/gizmo_test.rb
Transmitting file data .
Committed revision 4.

Discuss, Develop, Deliver

When you have your changes ready to share with the rest of the team, use the web interface to make a Pull Request:

Browse to your topic branch and click on the Pull Request button to the right of your repository name.
Fill out the Pull Request form with a description of the changes in your branch.
Discuss the changes with your team members. The discussion includes comments on commits in the pull request, comments entered on the pull request web page, and commits added to the topic branch.
Merge your pull request. The pull request page will indicate whether the changes can be merged cleanly; in most cases they can, and all you need to do is click the button and you're done! If there are conflicts, you'll need to resolve them first, which we'll cover in a later blog post.

Your changes will now be in the master branch; use svn update to bring your checkout up to date, and then start working on the next awesome thing!

Last month we kicked off the GitHub Data Challenge to see what awesome things might be lurking in the GitHub public timeline.

The entries were incredible! People from all over the world contributed queries, code and beautiful visualizations that gave a unique perspective on the millions of activities that happen every week on GitHub.com.

We all voted for our favorites to select the winners and ended up with a tie for third place.

First Place: The Octoboard

The Octoboard is a stats dashboard of GitHub activity from Denis Roussel (KuiKui).

Second Place: Emotional Analysis of Commit Messages

Ramiro Gómez (yaph) analyzed Expressions of Emotions in GitHub Commit Messages.

Example: Percentage of Commit Messages with Expressions of Anger

Third Place: Le GitHub - A Daily GitHub Newspaper

Alexandre Girard (alx) used an Arduino, a thermal printer and his Le-Github gem to print a daily newspaper of GitHub activity everyday before breakfast.

Third Place (tie!): Repository Activity by Language

Eduarda Mendes Rodrigues built a visualization of GitHub activity by language using NodeXL and blogged about her process.

Thanks

I want to thank everyone who worked on an entry for the data challenge. It was really exciting for all of us to see so many different approaches on analyzing such a rich source of data. Thank you!

Our winners will receive gift certificates to the GitHub shop, $200 for 1st, $100 for 2nd and $50 for both 3rd place winners.

GitHub for Mac is powered by TwUI, Twitter's open source, Core Animation-based UI framework for Mac. It's the same framework that drives Twitter for Mac. TwUI lets us create fast, animatable UIs using modern APIs. It's fantastic.

We've made a lot of fixes and additions in our TwUI fork:

We've been working with the fine folks at Twitter to figure out the best way for us all to make TwUI more amazing.

They invited us to join forces.

What does it mean?

TwUI has a bright and glorious future.

All of our changes are now in the original TwUI repository. That includes a lot of bug fixes, HiDPI support, and our sweet new popover:

.

We're excited to work with Twitter to make TwUI even more awesome.

The GitHub public timeline is now easy to query and analyze. With hundreds of thousands of events in the timeline every day, there are countless stories to tell.

Excited to play around with all this data? We'd love to see what you come up with.

To Enter

Send a link to a gist with your graph(s) along with a description to data@github.com before May 21st.

Prizes

GitHub staff will be voting on our favorite visualizations. Every entry will be included on our data showcase, but there are prizes to be had for the top three spots.

1st Prize: $200 to the GitHub Shop

2nd Prize: $100 to the GitHub Shop

3rd Prize: $50 to the GitHub Shop

We will also feature the three winning entries on the GitHub blog. Winners will be announced the week of May 21st.

There are over 1.5 million people working on over 2.5 million repositories on GitHub these days. Here are a few more fun stats I grabbed recently:

Exploring GitHub Data

The GitHub API provides access to the many public activities that happen on GitHub.com. Before today, if you were looking to analyze this data, you would need to archive it on your own and store it somewhere capable of querying such a large dataset.

Ilya Grigorik recently released a project called GitHub Archive.

GitHub Archive is a project to record the public GitHub timeline, archive it, and make it easily accessible for further analysis.

Analyze GitHub Data with Google BigQuery

We are happy to announce that the GitHub public timeline is now a featured public dataset available on Google BigQuery, which launched to the public today.

Running queries against the GitHub dataset is free. After logging into BigQuery, add the project name "githubarchive".

Bonus Dataset: Programming Language Correlations

This dataset, available in the language_correlation table on BigQuery, explores the relationships between programming languages as seen by GitHub. Example: How likely is it that a programmer who writes in Objective-C also programs in Java? (31%). Read on to learn more about how this data was gathered.

Generals in the Editor War may note that Emacs users are 35.2% likely to also hack on Vim, while Vim users are only 17.3% likely to hack on Emacs, so there's that.

Smart HTTP is The Future™

A while back, we launched Smart HTTP support for GitHub; this transport for pushing changes to GitHub has a number of benefits over the SSH-based approach, especially for Windows users. The biggest benefit is, instead of setting up an SSH key, you can just type your GitHub username and password.

Credential Caching in Git - Don't Make Me Type!

However, this approach has always had one major drawback - you have to type your username / password every time, which can get to be a little annoying. One of our users, Andrew Nurse, has come up with a great utility that utilizes Git 1.7.9's HTTPS Credential Caching support to provide a native password cache for Windows.

With this tool installed, you will only have to type your password once, until you change it. This utility is compatible with GitHub, as well as any other Git repository that supports the Smart HTTP protocol.

Installing the application is easy - just unzip it and double-click the EXEs. Included along with this zip file is GitPad, another helpful utility that changes the Git default commit message editor to whatever your system uses to edit text files (usually Notepad).

git-credential-winstore and GitPad for Windows Vista / Windows 7 (.NET 3.5 required)
git-credential-winstore and GitPad for Windows 8 (.NET 4.0 required)
The git-credential-winstore source code

(Note that there is no functional difference between the two, only .NET Framework versions)

Where's the Mac version?

Git Core ships the source code to a sample credential store that uses the native OS X credential cache APIs. Grab the binary here, put it in /usr/local/bin, and run the command git config --global credential.helper osxkeychain to enable it.

Fabian "ryg" Giesen (@rygorous), one of the coders of the legendary demoscene group farbrausch, has open-sourced on GitHub a repository with some of the group's work from 2001 to 2011.

There is a lot to discover in that repository. Its hundreds of C++, C and assembly files contain the source code of many of the tools that the group has been using internally during the last decade:

kkrunchy, the x86 executable compressor used by pretty much every scene group on 64k intros.
The werkkzeug3 engine, a seminal 3D engine with unprecedented procedural content generation techniques that spawned some of farbrausch's most successful productions.
lekktor, a tool for profiling, finding and removing dead-code sections. You can read more about it in this beyond fascinating blog post.
The V2 software synthesizer, still unmatched when it comes to generating procedural music and sounds in unreasonably small sizes.

On top of that, there's also the data files for some of farbrausch's award-winning productions, including:

fr-041: debris, the revolutionary demo that took Breakpoint 2007 by storm, in just 180kb. You want to watch this.

.kkrieger, a first-person shooter with Doom 3-like graphics in 96kb, also powered by the werkkzeug3 engine.
Several other intros based on RG2, such as fr-029: dopplerdefekt and fr-022: ein.schlag.

All in all, the public farbrausch repository is a masterclass on computer graphics and procedural content generation, and a living piece of history on the demoscene.

Unfortunately, not all of the code on the repository compiles out of the box. Most of it is out of date, but there's an on-going effort under the vs2010 branch to cleanup and update the different projects so they build cleanly on Visual Studio 2010. I'm sure pull requests to help with this task will be appreciated.

If you're having trouble finding your way around the code, @rygorous' ongoing series of blog posts are a great starting point.

Notch is at it again, and we couldn't be more excited. You may have heard of Minecraft, the award-winning game Notch released a few years ago that has recently marked its 5 millionth sale.

0x10c, Notch's new game, is a space simulator with an interesting twist: every spaceship in the game is controlled through a "CPU", implemented on the server through a Virtual Machine. Players program their spaceship in order to play the game. The DCPU-16 Specification identifies what the CPU is capable of. The rest is up to you, but we're here to throw you a hand.

GitHub officially supports the DCPU-16 assembly language

Today we have added DCPU-16 Assembly as an officially supported language on GitHub. Files with the .dasm16 or .dasm extensions will be automatically recognized and highlighted properly when pushed to your repositories.

Likewise, code blocks with the dasm16 tag will be highlighted in comments, and you can now choose DCPU-16 Assembly as the language for new Gists.

Example:

; Try some basic stuff
    SET A, 0x30          ; 7c01 0030
    SET [0x1000], 0x20   ; 7de1 1000 0020
    SUB A, [0x1000]      ; 7803 1000
    IFN A, 0x10          ; c00d 
    SET PC, crash        ; 7dc1 001a [*]

Follow 0x10c on GitHub

The popularity of 0x10c is spiraling out of control, and there's already plenty of excellent 0x10c repositories on GitHub to follow:

The (unofficial) 0x10c Standards Comittee
Virtual machines for Haskell, Rust, Java, Ruby, C, Python, JavaScript and many other languages.
An LLVM backend that generates DCPU-16 assembly.
A live editing environment for DCPU-16
A kernel written in DCPU assembly

We can't wait to see how 0x10c evolves, and we look forward to keeping up with the winning strategies on GitHub!

Today we're happy to open source Janky, our continuous integration server. It's built on top of Jenkins, Hubot, and GitHub.

Enjoy!

Ace is a code editor written in JavaScript. It powers Cloud9 IDE and, as of today, file editing on GitHub.

If you're using a recent version of Safari, Chrome, or Firefox here's how it works:

1. Hit the "Edit" button (or the `e` hotkey) on any blob

2. Edit your code

The basics should all work: TAB to indent, Shift+TAB to unindent, Command+/ (OSX) or Control+/ (Win/Linux) to comment out or uncomment a line.

3. Preview your changes

4. Commit!

Options

While we try to guess whether your file is using tabs or spaces and the indentation level, you can set those yourself using the options in the top right of the editor view:

Richtext

If the file you're editing is Markdown, Textile, or any other richtext format GitHub supports we'll render a preview of it instead of a diff:

More modes

If your favorite language isn't being highlighted, consider adding a mode for it! Check out Ace's "Creating or Extending an Edit Mode" wiki page for more info.

Ace

This is just the start. Help us make editing on GitHub even better by forking and improving Ace at ajaxorg/ace.

As always, please email support@github.com with any bugs you find or ideas you have. Happy hacking!

GitHub has always been about collaboration: we want to make it easy for you to work with other people to build great software. Whether that's a co-worker sitting next to you or a stranger across the globe, it doesn't matter. Collaboration should be easy and fun.

Unfortunately, there will always be people whose idea of fun is bullying others. That's why today we are rolling out a feature designed to help you control the people you interact with on GitHub.

Every profile page on GitHub now has a settings gear which lets you block a user or report them for abuse. This feature is inspired by Twitter and other social networks that let you decide whose content you do and don't see.

This is just the beginning. Moving forward, we'll integrate this functionality more tightly with the site and continue adding features to help you better control your GitHub experience.

Finally, we're sorry if abusive users caused you to have a bad GitHub experience. When you log in to github.com you should see things that make you happy: new Pull Requests, comments on your Issues, messages from people who love your software, intense debates about the quality of code. To that end, GitHub should have had "block user" a long time ago.

Let us know if you have ideas on how we can continue to improve GitHub, and please report anyone causing trouble to support@github.com — we're here to help.