The Code Train » head conference http://thecodetrain.co.uk Where Neil Crosby talks about coding on the train... Sun, 03 Apr 2011 18:15:12 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Why git? http://thecodetrain.co.uk/2008/11/why-git/ http://thecodetrain.co.uk/2008/11/why-git/#comments Mon, 17 Nov 2008 08:20:23 +0000 Neil Crosby http://thecodetrain.co.uk/?p=149 As should be obvious by now, I write most of my code whilst I’m on the train. Up until a couple of weeks ago I’d been using Subversion as my Version Control System running on a remote server, but this had never sat completely easily with me because I had to wait until I got home (and got a network connection) to be able to make all my commits from the journey.

So, “why didn’t you just run a Subversion repository on your local machine?”, I hear you cry. The answer is simple – I wanted to make sure I had the code backed up off-site and easily accessible from different machines. I also occasionally collaborate with others on the code I write, so having the repository on my local machine that only tends to be on when I have no network connection would be a bit of a non-starter as well.

Now, I’d been aware of git (and also bazaar) for over a year, but had never taken the time to look at them properly. The reason was that whilst I wasn’t particularly happy with the fact that I had to hold my commits in my head until I got home with svn I had been able to work this way and get things done. I was also not convinced by what I considered “fad” Version Control Systems, and I didn’t relish the prospect of moving from one to another. This all changed for me when I watched Robert Lee-Cann’s <head> conference talk about git. Although more in the style of a Barcamp (rather than conference) talk, Leeky’s session was far and away the one that I gained most from over the course of the event. The tipping point for me was that I could, if I wanted to, use git on the train to do intermediary commits and then commit back to svn when I got home. This fitted my mental model, and I was happy.

Of course, things didn’t quite happen that way. I started using git with GitHub as my remote repository for a couple of minor projects, decided I really got on with git in the limited way I was using it and decided to move across wholesale from svn.

Github

A big part of the reason I fell in love with git was GitHub. Ostensibly, GitHub is just a place to publicly store your code, but that word “publicly” is so very important.

One of the things that I wanted to do when I moved from Working With Me to The Code Train was create a sandbox area where I could make my half finished code public and allow people to fiddle with it and use it. Previously I’ve been much more likely to sit on code for months at a time, willing it to become more stable and generalised before pushing it out to the public, meaning that so many of the ideas and hacks I play with don’t make it out into the real world to be fiddled with by others. It turns out that I don’t need to create that special section of my site any more – with GitHub I get it for free! Now, whenever I start hacking on something, however small it may be, I’ll immediately start a new git repository and stick it up onto GitHub.

There are quite a few benefits to working this way:

  • I get to benefit from the eyes of people I work with and greatly respect.

    Whilst most of the code I stick up will be hacky in nature having other people be able to look at the things that interest them means that bugs, issues and mis-thinkings are much more likely to get picked up on. I love the idea of code reviews, and using GitHub is yet another, informal, way of allowing them to happen.

  • I get to share what I’m working on publicly, which might just help someone, somewhere.

    Just because I don’t think that something is ready for production use doesn’t mean that what I’ve done won’t be useful so someone out there. Whether it’s useful in solving a problem, or they just decide to use it wholesale, that’s all good.

  • I get added incentive to improve my code.

    Because there is the opportunity for so many eyes to be watching the code that I’m producing I feel a greater urge to improve it more quickly. I see this as a game that I get to play, and by playing it everyone’s a winner.

    Mike introduced me to Calendar About Nothing which similarly turns writing code into a game. Calendar About Nothing attempts to add incentive to writing code by giving you your own personal calendar that has each day crossed off as you commit public code to GitHub. The idea is to build up longer and longer unbroken chains of committing code to the public good each and every day. As well as the personal incentive of making your chain longer, the site also has lists of people with the longest chains currently and of all time. The longest chain of all time is currently at 59 days. My aim is to make it to 60 days of committing public code which actively makes something better.

So there you go – I’m loving git, and I’m loving GitHub. If you want to check out the projects I’m working on, head on over to my GitHub profile.

Probably the most interesting projects I’m working on right now are:

  • WikiSlurp – a tool to pull HTML formatted data out of Wikipedia.

  • Multi Level vCards – use your vCard to publish information to the web, allowing only certain people to see your more sensitive data.

  • TwitBot – a tool to allow easy creation of bots for use on twitter.

So, what are you waiting for? Get yourself onto GitHub and lets see the code you’re writing! Oh yes, and don’t forget to read what Mike and Steve have to say on the subject of GitHub too.

Neil Crosby also blogs at about t-shirts at I Wear Cotton, writes Ten Word Reviews, and uploads photos to flickr. You can follow a combined feed of posts at NeilCrosby.com.
]]> As should be obvious by now, I write most of my code whilst I’m on the train. Up until a couple of weeks ago I’d been using Subversion as my Version Control System running on a remote server, but this had never sat completely easily with me because I had to wait until I got home (and got a network connection) to be able to make all my commits from the journey.

So, “why didn’t you just run a Subversion repository on your local machine?”, I hear you cry. The answer is simple – I wanted to make sure I had the code backed up off-site and easily accessible from different machines. I also occasionally collaborate with others on the code I write, so having the repository on my local machine that only tends to be on when I have no network connection would be a bit of a non-starter as well.

Now, I’d been aware of git (and also bazaar) for over a year, but had never taken the time to look at them properly. The reason was that whilst I wasn’t particularly happy with the fact that I had to hold my commits in my head until I got home with svn I had been able to work this way and get things done. I was also not convinced by what I considered “fad” Version Control Systems, and I didn’t relish the prospect of moving from one to another. This all changed for me when I watched Robert Lee-Cann’s <head> conference talk about git. Although more in the style of a Barcamp (rather than conference) talk, Leeky’s session was far and away the one that I gained most from over the course of the event. The tipping point for me was that I could, if I wanted to, use git on the train to do intermediary commits and then commit back to svn when I got home. This fitted my mental model, and I was happy.

Of course, things didn’t quite happen that way. I started using git with GitHub as my remote repository for a couple of minor projects, decided I really got on with git in the limited way I was using it and decided to move across wholesale from svn.

Github

A big part of the reason I fell in love with git was GitHub. Ostensibly, GitHub is just a place to publicly store your code, but that word “publicly” is so very important.

One of the things that I wanted to do when I moved from Working With Me to The Code Train was create a sandbox area where I could make my half finished code public and allow people to fiddle with it and use it. Previously I’ve been much more likely to sit on code for months at a time, willing it to become more stable and generalised before pushing it out to the public, meaning that so many of the ideas and hacks I play with don’t make it out into the real world to be fiddled with by others. It turns out that I don’t need to create that special section of my site any more – with GitHub I get it for free! Now, whenever I start hacking on something, however small it may be, I’ll immediately start a new git repository and stick it up onto GitHub.

There are quite a few benefits to working this way:

  • I get to benefit from the eyes of people I work with and greatly respect.

    Whilst most of the code I stick up will be hacky in nature having other people be able to look at the things that interest them means that bugs, issues and mis-thinkings are much more likely to get picked up on. I love the idea of code reviews, and using GitHub is yet another, informal, way of allowing them to happen.

  • I get to share what I’m working on publicly, which might just help someone, somewhere.

    Just because I don’t think that something is ready for production use doesn’t mean that what I’ve done won’t be useful so someone out there. Whether it’s useful in solving a problem, or they just decide to use it wholesale, that’s all good.

  • I get added incentive to improve my code.

    Because there is the opportunity for so many eyes to be watching the code that I’m producing I feel a greater urge to improve it more quickly. I see this as a game that I get to play, and by playing it everyone’s a winner.

    Mike introduced me to Calendar About Nothing which similarly turns writing code into a game. Calendar About Nothing attempts to add incentive to writing code by giving you your own personal calendar that has each day crossed off as you commit public code to GitHub. The idea is to build up longer and longer unbroken chains of committing code to the public good each and every day. As well as the personal incentive of making your chain longer, the site also has lists of people with the longest chains currently and of all time. The longest chain of all time is currently at 59 days. My aim is to make it to 60 days of committing public code which actively makes something better.

So there you go – I’m loving git, and I’m loving GitHub. If you want to check out the projects I’m working on, head on over to my GitHub profile.

Probably the most interesting projects I’m working on right now are:

  • WikiSlurp – a tool to pull HTML formatted data out of Wikipedia.

  • Multi Level vCards – use your vCard to publish information to the web, allowing only certain people to see your more sensitive data.

  • TwitBot – a tool to allow easy creation of bots for use on twitter.

So, what are you waiting for? Get yourself onto GitHub and lets see the code you’re writing! Oh yes, and don’t forget to read what Mike and Steve have to say on the subject of GitHub too.

]]> http://thecodetrain.co.uk/2008/11/why-git/feed/ 2