The RefLog - July 2012

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

The First OctoGala

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, 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, and click on “Give Now”.

The facts:

Investing in GitHub

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

Collaborating on GitHub with Subversion

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:

  1. Create a topic branch from the latest master branch
  2. Make commits in the topic branch until you're ready to merge it
  3. 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
  4. 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 to get the HTTP clone URL:

Then get your checkout ready:

  1. Start with an empty checkout of the repository. Browse to the repository page on and use the HTTP clone URL:

    $ svn co --depth empty
    Checked out revision 1.
    $ cd gizmo
  2. Get the 'trunk' branch. The Subversion bridge maps trunk to the git HEAD branch (usually master.)

    $ svn up trunk
    A    trunk
    A    trunk/
    A    trunk/gizmo.rb
    Updated to revision 1.
  3. 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
 * [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:

  1. Browse to your topic branch and click on the Pull Request button to the right of your repository name.

  2. Fill out the Pull Request form with a description of the changes in your branch.

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

  4. 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. pr-merge1 pr-merge2 pr-closed

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!

GitHub Data Challenge Winners

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

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.


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.

Twitter + GitHub = TwUI

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 Data Challenge

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 before May 21st.


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.

Data at GitHub

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

Credential Caching for Wrist-Friendly Git Usage

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

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

Ten Years of farbrausch Productions on GitHub

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.

Take Over The Galaxy with GitHub

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.


; 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:

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

Edit like an Ace

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!


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:


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.


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 with any bugs you find or ideas you have. Happy hacking!

Rolling out the Redcarpet

Here at GitHub, we love Markdown. We use it everywhere: to render the wikis, issues, pull requests, and all user-generated comments. We even encourage developers to write their READMEs in this awesome markup language. In fact, we use it so much that we've learnt a few lessons on Markdown parsing the hard way.

Every day, GitHub renders thousands of Markdown documents with all kinds of user-submitted content, ranging from poorly formatted to downright malicious. Your average Markdown parser is not prepared to deal with potentially pathological inputs, and hence is vulnerable to DOS attacks. That's why we've decided to take Natacha Porté's awesome library, Upskirt, and pimped it with everything you'd expect in a Markdown library for the web - both in features and in security.

Our fork of the library also comes with a Ruby wrapper, aptly named Redcarpet. Redcarpet works as a drop-in replacement for BlueCloth and RDiscount; we've been slowly deploying it through all our frontend machines, and so far none of them has caught :fire:. We consider this a tremendous success, but since we strive for perfection, please report any rendering errors you may encounter in your Markdown documents to help us improve the library.

Finally, to celebrate the release of the new library we're enabling syntax highlighted code blocks in GitHub Flavored Markdown.

Four space indentation is now no longer required when including code, backtraces and other text in a comment, issue, Gist or any other Markdown-enabled text. Instead, simply create a fenced block with ```. An optional language identifier after the backticks will syntax highlight the code in that language.

``` ruby
require 'redcarpet'
markdown ="Hello World!")
puts markdown.to_html
require 'redcarpet'
markdown ="Hello World!")
puts markdown.to_html

GitHub + Rebase Support in IntelliJ

The IntelliJ platform has had GitHub integration for a few months, but today they rolled out Advanced GitHub Integration: Rebase My GitHub Fork.

What is it? Rebase support.

Now staying up to date with upstream repos is easier than ever in IntelliJ! Best of all, it's available in the free community edition of IDEA as well as the commercial edition. Integration for other products is underway.

Check their blog post for more information and a screencast, and keep watching for more awesome stuff from the JetBrains team in the future.

Download IntelliJ

Mind Control with Frickin Lasers

Several months ago I hosted a GitHub meetup in Boston to which tons of local geeks attended and drank free beer. During that meeting, I talked to a local graduate student in biophysics at Harvard named Andrew Leifer who told me that he loved GitHub and was in fact using it to collaborate on a program that accomplished mind control. with lasers. on worms.

Well, it turns out that I had not in fact been drinking too much and the project is real. Andrew's research is called CoLBeRT: Controlling Locomotion and Behavior in Real-Time and works by running real-time analysis on video of a 1mm long specially bred light-sensitive C. elegans worm. The CoLBeRT system tracks the worm as it moves and shines laser light on specific neurons as the worm is moving to stimulate or inhibit those neurons.

The system can make the worm paralyzed, lay eggs, back up, speed up or sense touch in different areas of its body, all by directing laser light into specific neurons. That's right, I said lay eggs. Check out this kick-ass laser:

If you aimed that at me, I'd probably lay eggs too.

Andrew's research has recently been published in Nature Methods and covered in Science News and Scientific American and true to his word the source code for laser worm mind control is on GitHub, aptly named MindControl, and is open source.

So, though the human brain has over 100 billion neurons instead of the worm's 302, and we're not photosensitive, this project brings us 1 evil pull request closer to total world domination. with frickin lasers.