Posts Tagged ‘GitHub’

The (Distributed) Version Control Hosting Landscape

Monday, March 19th, 2012

When working with complex code, configuration files, or just plain text, using Version control (or VC for short) should be like brushing your teeth. You should do it regularly, and getting into a routine with it will protect you from yourself. Our internet age has dragged us into more modern ways of tracking changes to and collaborating on source code, and in this article we’ll discuss the web-friendly and social ways of hosting and discovering code.

One of the earliest sites to rise to prominence was Sourceforge, which is now owned by the company behind Slashdot and Thinkgeek. Focused around projects instead of individuals, and offering more basic VC systems, like… CVS, Sourceforge became a site many open source developers would host and/or distribute their software through. Lately, Sourceforge seems to be on the wane, as it is found to be redirect and advertising-heavy.

When Google wanted to attract more attention to its open source projects and give outsiders a way to contribute, it opened code.google.com in 2005. In addition to SVN, Mercurial (a.k.a. Hg) was available as an alternative VC option in 2009, as it was the system adopted by the Python language, whose creator is an employee at Google, Guido van Rossum. Hg was one of the original Distributed Version Control Systems, DVCS for short, and the complexity of such a system could feel ‘bolted-on’ when using Google for hosting (especially in the cloning interface), and its recent introduction of Git as an option mid last year brings this feeling out even more.

Bitbucket was another prominent early champion of Hg, and its focus, like those previously mentioned, is also on projects. Atlassian, the company behind it, are real titans in the industry, as the stewards of the Jira bug-tracking software, Confluence wiki, HipChat web-based IM/chatroom service, and have recently purchased the mac DVCS GUI client SourceTree. Even more indicative of the fast-paced and free-thinking approach of how Atlassian has done business is their adoption of Git late last year as an option for Bitbucket, going so far as to guide folks to move their Hg projects to it.

But the 900-pound gorilla in comparison to all of these is Github, with their motto, ‘Social Coding’. Collaboration can tightly couple developers and make open source dependent on the approval or contributions of others. In contrast, ‘Forking’ as a central concept to Git makes this interdependency less pronounced, and abstracts the project away to put more focus on the individual creators. Many words have already been spent on the phenomenon that is Git and Github by extension, just as its Rails engine enjoyed in years past, so we’ll just sign off here by recommending you sign up somewhere and join the social coding movement!

Test-Driven Sysadmin with a Russo-Australian Accent

Friday, March 16th, 2012

One of the jokes in the Computer Science field goes like this: there are only 2 hard problems: cache invalidation, naming things, and off-by-one errors. Please do pardon the pun.

Besides the proclivity to name things strangely in the tech community, we often latch on to acronyms and terms that show our pride in being proficient with cutting-edge (or obscure) concepts. As with fashion, there is an ebb and flow to what’s new, but one thing that is here to stay are tests for code, exemplified by the concept of TDD or Test-Driven Development. When you work with complex systems, dependancies can become a fragile house of cards, but here’s another take on that concept: “here in Australia, “babushka doll” is the colloquial term for Russian nesting dolls. Deps” (short for dependancies) “are intended to be small, tidy chunks of code, nested within each other – hence the name”

Babushka is the name of a tool, for Mac OS X and Linux, that tests for the software or settings your system relies on – and if it isn’t present, it goes about changing that for you. Its claim of “no job too small” hints at how atomic and for-mere-mortals the tool was made to be. In comparison to configuration management tools like Puppet and Chef, which are also written in Ruby, it’s much more humble with a proportional community in comparison. The larger tools strive to deliver the ‘holy trinity’, consisting of a package, a configuration file, and a service (gathered in modules by Puppet parlance or recipes in Chef.) Babushka can just deliver the package and lets you build from there.

It was originally released a few years ago, and has recently been refreshed with new capabilities and approachable, comprehensive documentation. Unlike centralized business systems that require curation to take into account things like volume licensing, Babushka can let you reach right out to publicly available freeware. For developers it affords more conveniences like the command line tools that used to require Xcode, package managers like homebrew, and support for Ubuntu’s standard package manager as well.

Git and Github.com both play a big part in Babushka; and not just that Git’s the version control system it uses and Github is the site it can be downloaded from. If you decide you’d like to use someone else’s ‘Deps’ to set up your workstation, there is a simplified syntax to not only specify a user on Github whose repository you’d like to work out of, but you can now search across Github for all of the repositories Babushka knows about.

One way of getting started super fast is just running this simple command: bash -c “`curl babushka.me/up`”

Now installing via this method is not the most secure, but you can audit the code since it is open source and make your own assurances that your network communication is secure before using it. For examples, you can look at the creator’s deps or your humble author’s.

More fuel for the Simian fire – how does free sound?

Thursday, March 15th, 2012

Well we’ve been busy keeping our finger on the pulse of the Mac-managing open source community, and that genuine interest and participation continues to pay off. Earlier, we highlighted how inexpensive and mature the Simian project running on Google App Engine (GAE for short) is, although as of this writing refreshed documentation is still forthcoming. In that article we mentioned only one tool needs to be run on a Mac as part of maintaining packages posted to the service, and an attempt is being made to remove even the need for that. This new project was originally announced here, and has a growing number of collaborators. But that isn’t the biggest news about Managed Software Update (Munki) and Simian we have to announce today.

A technique that had been previously overlooked is now proven to be functional that allows you to use Simian as the repository of all of your configurations, but serve the actual packages from an arbitrary URL. Theoretically, if you take the publicly available pkginfo files, modify them to point to a web server on your LAN, (or even the vendors website directly, if you want them to be available from anywhere,) and your GAE service would fall under the free utilization limits with very little maintenance effort. This is big for institutions with a tight budget and/or multiple locations that want to take advantage of the App Engine platforms availability and Simian’s great interface. Beyond helping you save on bandwidth usage, this can also help control where your licensed software is stored.

Previously people have wished they could adapt Google’s code to run on their local network with the TyphoonAE beta project, but versus the recommended & supported method to deploy the server component, this is a great middle ground that brings down a barrier for folks having difficulty forecasting costs.

It’s an exciting time, with many fully-featured offerings to consider.