Stories about Software


Why is Github Taking over the World?

Editorial Note: I originally wrote this article for the SmartBear blog.  Click here to check out the original.  If you like this content, take a look around at their offerings and their posts from other authors.

There’s a word out there that you’d be a lot more likely to hear from journalists, pundits, and authors than you would from techies: zeitgeist.  The dictionary definition of the word, “the general beliefs, ideas, and spirit of a time and place,” is straightforward enough.  But when used by the people I mentioned, zeitgeist, as a descriptor, imparts gravity on the thing it describes.  It I say that Github captures the zeitgeist of the programmer world of the 2010s, I am thus saying that Github is at the absolute core of the software development universe.

And I do say that.

If you’re not familiar with Github, I’ll offer a brief description.  It is a website that wraps a software version control system called “Git” and allows software developers to host their code online for free (though there are paid models available).  If you’re a software developer, Github is a repository for you to store, exchange, trade, and talk about code.  This may not sound like the stuff of which zeitgeists are made.

The sheer, raw popularity of Github alone doesn’t explain this classification, either, though it is popular.  Alexa, a web analytics company (not to be confused with Amazon’s Echo personality), ranks Github as the 83rd most popular site on the planet, as of the time of this writing.  That’s particularly impressive when you stop to consider that Github’s audience is the slice of software developers that feel like freely exchanging source code with one another.  Other popular sites occupying top rankings, like, Facebook, Amazon, or Google, on the other hand, have an audience of literally everyone on Earth.

It isn’t the improbable, raw volume of traffic to Github that elevates it to Zeitgeist level, however.  It isn’t even the growth or the market cap of the company or the number of contributing developers.  Those things alone can’t explain why Github is a zeitgeist — why it’s taking over the world.  To do that, let’s look at it in a bit more detail.

From Improbable Beginnings

Let’s take a little known, somewhat pedantic approach to storing code, wrap it in a cute user interface package, sprinkle a little social media on it, compete with an entrenched market dominator (sourceforge), give it away largely for free and change the world!

If I could go back to around 2008, when Github was just starting out, I can’t say I’d be clamoring at the bit to become an investor.  At least, not without 20/20 hindsight.  It doesn’t really sound like a game-changer, and yet that’s what it became.

And yet, if you look at tech trends, the makings were there, if subtle.

Distributed Version Control for a Remote World

If you’ve been writing code for a long time, you no doubt remember the bad old days of remote work when it comes to source code version control.  At the time Github first started attracting notice, centralized version control schemes were the standard, and when you were somewhere the source control server wasn’t, things could get painful.  I remember using a tool called Rational Clear Case that was setup in such a way that it took me most of the morning to commit a few files to source control if I was working from home.  As bad as that sounds, it could be worse — if you were on a plane or somewhere without internet access, you wouldn’t be able to work at all, unless you had planned ahead of time to acquire an “offline” version of the code.  And then, getting it back online could be quite painful once you re-connected.


Git, the version control system upon which Github is based, changed all that with distributed version control.  Git was the version control of Linux — a decentralized, democratic tool that could support ad-hoc, global collaborations.  Github, the website, wrapped Git up and encouraged you to work with the full safety of source control wherever you were.  And, don’t worry, they reassured you, it’ll be a breeze to sync back up when you’re connected again.  And it was.

Github offered remote coding to an increasingly remote workforce.

Read More


Failed to Open storage.ide

I don’t make a lot of “lessons learned” posts anymore, but here’s hoping this quick post saves some of you out there a headache when you get this message and google it.

A few weeks back, I had an issue with the Git source code provider in Visual Studio and tweeted about it here (though in my haste/ire, I incorrectly described it as “tfs-git”):

It was a weird problem, because I’d been hitting that code base from 3 machines, each with the same version of Visual Studio installed. One of them never had any problems, and the other two always bombed out with this message, forcing me to go into the command line and committing from there, which worked. I have no idea what’s different among these machines and why it would work on one but not the others. Weird.

A long way down in the reply chain, Buck Hodges provided the answer that worked:

Sure enough, I went in and added this to my .ignore file, and it did the trick. This never would have occurred to me, however, as a possible solution. That whole directory and all of the files in it were created by the IDE-Source control apparatus anyway. It’s not like I went in there and created those files, and it’s not like I was using them for anything. I actually would have assumed they would already be in that auto-generated .ignore file. I mean, this is sort of like the IDE saying to me, “I can’t check in your code because this file I created without your knowledge is being used… by me.” (When troubleshooting, I investigated which process was using the file, and the only one was Visual Studio).

Nevertheless, I was grateful for the fast response and the fix that worked, so I won’t look a gift horse in the mouth.


GitHub and Easy Moq


Not too long ago, I signed up for GitHub. I had always used subversion for source control when given the choice, but the distributed nature of Git appealed to me, particularly since I often do work on a variety of different machines. GitHub itself appealed to me because it seemed like the perfect venue for reusable code that I’ve created over the years and tend to bring with me from project to project. Here is a unique idea – sites like Sourceforge want to store code by basic unit of “project” whereas GitHub wants code for the sake of code. This code need not be finished or polished or distributed on any kind of release schedule. That is perfect for a lot of my portable code.

One thing that I noticed about GitHub upon arrival was the lack of .NET work there, compared with other technologies. There is some, but not a lot. Presumably this is because sites like Code Project already offer this kind of thing to the .NET community. After reading about Phil Haack leaving Microsoft to be GitHub’s Windows Ambassador, I decided that this was a good indicator that GitHub was serious about growing that portion of its user base, and that I’d start porting some of my code there.

Another thing that I’d read about git before trying it out was that it has a steep learning curve. To back my general impression of this as a widely held opinion, I did a quick google search and ran across this post.

Given the steep learning curve many (including myself) experience with Git, I think I can safely assume that many other people have this sort of problem with it.

So, there’s at least one person who has experienced a steep learning curve and at least one other person with the same general sense as me about many finding the learning curve steep.

I must say, I haven’t found this to be the case. Perhaps it’s my comfort with Linux command line interaction or perhaps it’s my years of experience using and administering SVN, but whatever it is, I read the GitHub primer and was up and running. And, I don’t mean that I was up and running with commits to my local repository, but I was up and running committing, pushing to GitHub, and pulling that source to a second computer where I was able to build and run it. Granted, I haven’t forked/branched/merged yet, but after a day of using it, I was at the point where the source control system retreated into the mental background where it belongs, serving as a tool I’m taking for granted rather than a mental obstacle (by contrast, even with a couple of years of experience with Rational Clear Case, I still have to set aside extra development time to get it to do what I want, but I digress, since I don’t believe that’s a simple case of needling to mount a learning curve). So, after a day, I’m developing according to my schedule and running a commit when I feel like taking a break and/or a push when I want to update GitHub’s version. I’m sure I’ll be hitting google or StackOverflow here and there, but so far so good.

Easy Moq

So, what am I doing with my first GitHub project? It’s something that I’m calling Easy Moq. I use Moq as my main mocking framework, as I’ve mentioned before, and I’ve had enough time with it to find that I have a certain set of standard setup patterns. Over the course of time, I’ve refined these to the point where they become oft-repeated boilerplate, and I’ve abstracted this boilerplate into various methods and other utilities that I use. Up until now, this has varied a bit as I go, and I email it to myself or upload the classes to my web server or something like that.

But, I’m tired of this hodgepodge approach, and this seems like the perfect use case for trying out GitHub. So, I’m looking over my various projects and my use of Moq and creating my own personal Easy Moq library. If others find it useful, so much the better – please feel free to keep up with it, fork it, add to it, etc.

At the time of writing, I have three goals in mind (these may change as I TDD my way through and start eating my own dog food on real projects). In no particular order:

  • Create Mock inheritors that default to having specific test double behavior – dummies, stubs, spies, etc.
  • Be able to create and use my doubles with the semantics Dummy() or new Spy() rather than new Mock().Object
  • Be able to generate an actual class under test with all dependencies mocked as Dummy, Stub, Spy, etc.

For the first goal, I’ll refer to Niraj’s take on the taxonomy of test doubles. I haven’t yet decided exactly how I’ll define the particular doubles, but the ideas in that post are good background for my aims. Up to this point, if I want to create one of these things with Moq, I instantiate the double in the same fashion and my setup differs. I’d like to make the declaration semantics more expressive — declaring a DummyMock is more expressive as to your intent with the test than creating a Mock and doing nothing else to set it up. For more complicated doubles, this also has the pleasant effect of eliminating manual boilerplate like “SetupAllProperties()”.

For the second goal, this is probably lowest priority, but I’d like to be able to think of the doubles as entities unto themselves rather than wrappers that contain the entity that I want. It may seem like a small thing, but I’m a bit of a stickler (fanatic at times) for clear, declarative semantics.

For the third part, it’d be nice to add a dependency to a class and not have to go back and slaughter test classes with “Find and Replace” to change all calls to new Foo(bar) to new Foo(bar, baz), along with Baz’s setup overhead, particularly when those old tests, by definition, do not care about Baz. I realize that there is already a tool designed to do this (called AutoMoq), but it appears to be for use specifically with Unity. And besides, this is more about me organizing and standardizing my own existing code as well as getting to know GitHub.

So, that’s my first pet project contribution to Git Hub. If anyone gets any mileage out of it, Cheers. 🙂