The Code Train » git 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 Five ways to make offline working easier http://thecodetrain.co.uk/2008/10/five-ways-to-make-offline-working-easier/ http://thecodetrain.co.uk/2008/10/five-ways-to-make-offline-working-easier/#comments Tue, 28 Oct 2008 18:15:14 +0000 Neil Crosby http://thecodetrain.co.uk/?p=129 Nowadays an “always on” existence is far less of a pipe dream than it was even a year ago. Usable wireless hotspots have popped up everywhere and many of us have data tariffs on our mobile phones. It’s no surprise then that many people simply expect to always have a network connection and become flummoxed when this is taken away from them.

Not having a connection to the outside world shouldn’t be a blocker to getting work done though. On my commute to and from work I have no internet connection available to my laptop and it really doesn’t stop me from getting anything done. In fact, being disconnected from the cloud actually helps to free my mind and reduce the distractions that so often occur when I am connected.

A few people have asked me what my setup is for working on the train, so here’s a brief rundown of what I have on my laptop:

A Development Environment

For me, this is MAMP, a simple installation LAMP setup for the Mac. I personally currently run MAMP Pro, which costs money but gives me an easy interface for creating Virtual Hosts which I find very handy.

Documentation

Just as important as the development environment is the documentation to go with it. If there’s a language or tool that you use that has documentation available for it then download it – you’ll regret your decision not to if you need it and you’re away from a network connection.

Because I write a lot of PHP and it’s a little inconsistent in its naming conventions I’m constantly in and out of the documentation. I find the PHP Function Index application invaluable on the train, as it makes the PHP documentation searchable and also allows you to download and keep an offline copy of all the user comments from PHP.net.

MarsEdit

Right now I’m working in MarsEdit, the really rather nice blog entry writing tool. It allows me to write entries for multiple blogs, store them locally and sync with the blog servers when I have a network connection. It has built in support for Markdown (which matters to me) and gives a nice preview of your entries as you write them. I really wish it would let me turn on a column to show the “Post Status” of my entries though – it would make finding the half finished things so much easier.

Git

I’ve only just started using git (check out my profile on GitHub), but it’s looking like it should fit my usage nicely. Working on the train means that there are plenty of times when I solve a problem and then want to move on to a new one. With my previous setup of an SVN server on a completely separate machine I couldn’t commit my code before starting the second problem. With git though, I can commit any changes I want locally and then upload them to an external server later at my leisure. Apparently, I can even use git on the train for intermediary commits and then commit back to my normal SVN repository when I get home.

A backup network connection

Of course, there are times when you really do need a network connection and then a phone with a decent data plan really comes in handy. On those occasions though Sod’s Law will apply and you won’t have any signal. When that happens I just sit back, relax and move onto something else.

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.
]]> Nowadays an “always on” existence is far less of a pipe dream than it was even a year ago. Usable wireless hotspots have popped up everywhere and many of us have data tariffs on our mobile phones. It’s no surprise then that many people simply expect to always have a network connection and become flummoxed when this is taken away from them.

Not having a connection to the outside world shouldn’t be a blocker to getting work done though. On my commute to and from work I have no internet connection available to my laptop and it really doesn’t stop me from getting anything done. In fact, being disconnected from the cloud actually helps to free my mind and reduce the distractions that so often occur when I am connected.

A few people have asked me what my setup is for working on the train, so here’s a brief rundown of what I have on my laptop:

A Development Environment

For me, this is MAMP, a simple installation LAMP setup for the Mac. I personally currently run MAMP Pro, which costs money but gives me an easy interface for creating Virtual Hosts which I find very handy.

Documentation

Just as important as the development environment is the documentation to go with it. If there’s a language or tool that you use that has documentation available for it then download it – you’ll regret your decision not to if you need it and you’re away from a network connection.

Because I write a lot of PHP and it’s a little inconsistent in its naming conventions I’m constantly in and out of the documentation. I find the PHP Function Index application invaluable on the train, as it makes the PHP documentation searchable and also allows you to download and keep an offline copy of all the user comments from PHP.net.

MarsEdit

Right now I’m working in MarsEdit, the really rather nice blog entry writing tool. It allows me to write entries for multiple blogs, store them locally and sync with the blog servers when I have a network connection. It has built in support for Markdown (which matters to me) and gives a nice preview of your entries as you write them. I really wish it would let me turn on a column to show the “Post Status” of my entries though – it would make finding the half finished things so much easier.

Git

I’ve only just started using git (check out my profile on GitHub), but it’s looking like it should fit my usage nicely. Working on the train means that there are plenty of times when I solve a problem and then want to move on to a new one. With my previous setup of an SVN server on a completely separate machine I couldn’t commit my code before starting the second problem. With git though, I can commit any changes I want locally and then upload them to an external server later at my leisure. Apparently, I can even use git on the train for intermediary commits and then commit back to my normal SVN repository when I get home.

A backup network connection

Of course, there are times when you really do need a network connection and then a phone with a decent data plan really comes in handy. On those occasions though Sod’s Law will apply and you won’t have any signal. When that happens I just sit back, relax and move onto something else.

]]> http://thecodetrain.co.uk/2008/10/five-ways-to-make-offline-working-easier/feed/ 4