When I was younger I managed a 60 mile ride in Yorkshire and my legs felt like jelly afterwards – but at least I know I can do it.

As part of the charity ride event I wanted people to track my progress on the day so I created a page where you can do just that. The page currently just shows the route I will be taking but on the day it will show markers for where I am (I’ll update from my handle-bar mounted phone as I’m riding). I’ll also being using the hashtag #JDcharityride to tweet and post picture every now and then on the ride. Feel free to use the hashtag to tweet your encouragements

The charity I’m riding for is the Douglas Macmillan Hospice and have an initial target of £100 I’d like to raise, so any donations you could submit will be much appreciated!

Looking at the weather at the moment, it doesn’t look great but I’m at least hoping for some sunny spells to dry me out if it does rain.

Keep an eye on the charity ride page on Sunday around 10am (Not exactly sure what time it starts – I’ll update you soon)

By being de-centralised, GIT differs from some other version control systems like Subversion (SVN) that stores the history of the project on one central server — a single point of weakness if the project were to become corrupted or lost. With GIT, all users have a full working history of the project so the problem of a central repository is solved.

GIT has many features beyond simply tracking changes within a repository. For example, branching is useful for working on a feature of a project without affecting the main project. Once you are happy with a feature, you can merge your changes in the main branch. All the daily-use features of GIT will be discussed in this article.

First of all, let’s take a look at what a repository might look like:

.git/
.gitignore
README
index.html
css/
- styles.css

This is what a very simple website might look like in a GIT repository. There are 2 things to notice. First, the .git/ directory. This contains the entire history of the repository. Unlike SVN, a .git/ directory only appears in the root of the repository and not in every sub-directory as well. Secondly is a file called .gitignore. This is a plain-text file containing line-separated rules that tell GIT to not track the changes of specific files. For example you might want to disable tracking of cached files, config files etc that would be be unique to each person working on the project.

First make sure you have GIT installed on your computer (link in the useful resources at the end of this post). I assume you are using Linux or Mac — I have no experience with using GIT on Windows…

OK, so how do we create a repository? Navigate to the root path of the directory you want to become a repository in the terminal and type:

git init

Your directory is now a repository! At the moment GIT knows about the files in the repository but isn’t doing anything with that information. The files are in an ‘untracked’ state. There are three state to be aware of.

untracked/unstaged ——> staged ——> committed

A file that GIT hasn’t seen before, such as a newly added file (or in the case of a newly initialised repository like above, all the files are new to GIT) is labelled as untracked. If a file has been modified or deleted since the last commit, it is labelled as unstaged.

You can check the status of your working copy by issuing the following command:

git status

This will show you which files are untracked, unstaged and which are staged. Staging a file means that you want to commit it to history of the project. To stage a file type:

git add /path/to/file.txt

You can also issue variations on this command to stage different things:

git add file1.txt file2.txt

This stages multiple files by space-separated paths.

git add -A

This stages all untracked and unstaged files.

Once your files are staged and you want to commit those changes to the history of the repository, you type:

git commit -m “commit message”

It is important that you write a commit message (in fact GIT won’t allow you to commit changes without one) because this will be used by yourself or others in the future to quickly identify the purpose of the commit. An example of a commit message might be “Fixed a bug in the CSS that was floating the header to the left”.

You can also stage and commit in one move:

git commit -a -m “commit message”

It is good practice to commit your changes regularly so that you can go back to previous versions incrementally if something goes wrong rather than just committing when a feature is complete.

Once your changes are committed to the repository’s history you can type:

git log

This will show you the history of your repository. Each commit gets a unique identifier which can be used to return your working copy to that commit. By typing:

git checkout 780a2fc

you revert your working copy to that commit. Note that you don’t have to type the entire commit identifier — the first 6 or 7 characters are usually unique enough for GIT to realise which commit you mean. By checking out a different part of the history of the project, you will notice that the actual files in the directory will change to reflect the history of the project at the time of the commit.

You will actually need to stage and commit these files if you want to save this back to the top of the history as this will become a new commit. But if instead you want to go back to the top of the history just type:

git checkout HEAD

HEAD is a special identifier that always points the last commit of the project.

Perhaps you want to see exactly what you’ve changed rather than just what files you changed since the last commit (remember, use git status to see what files are untracked/unstaged). You can use the following command:

git diff

This will show the lines in the files that have been changed. Red lines represent lines that have been removed and green lines show new lines that have been added. Red lines followed by green lines show where you have modified a line or lines (GIT assumes you removed the lined and replaced it with a modified version of the line)

To just get a summary of the changes (just the number of lines added/removed for each file) type:

git diff -stat

There are various other commands that are useful for manipulating the status of a staged file, such as

git reset

git rm

git mv

Next up, we’re going to look at branching. Branching is a great feature of GIT. Say for example that you want to start an experimental feature of a website that you’re not sure will work out (it’s experimental after all). You can create a separate branch to work on that feature while keeping the main branch (called ‘master’) clear to do your main work. You can create a branch by typing:

git branch branch_name

This also switches you to working on the new branch. Any work you now do will be committed to this branch (which also contains all the history up to the point at which you branched off). You can carry on using GIT in the same way until you are happy to merge the changes you made in this branch into the master branch (or perhaps just discard the branch as it didn’t work out).

You can get a list of branches by typing:

git branch

To switch between branches, just type:

git checkout -b branch_name

This reverts your working copy to that branch.

To merge the changes from the experimental branch into the master you must first checkout the branch you want to merge into (in this case master). Then type:

git merge branch_name

This will merge the changes you made in the experimental branch into the master branch along with the history of commits you made while you were on that branch. Most of the time this works fine, but occasionally you may have modified a line in a file in the history of both branches — this causes a merge conflict. GIT will put merge conflict markers in the file that the conflict occurred in. You can manually edit the file and select the version of the line(s) you want to keep and then mark the file as resolved by typing

git add conflicted_file_name

Finally if you want to delete a branch (make sure you don’t have it checked out at the time) you can type:

git branch -d branch_name

This concludes our simple look at how branching works. Next we’ll look at at how to contribute with others.

Perhaps you are not the initiator of a project. But someone else on you team has made their repository available to you. You can clone their repository along with the entire history of the project by typing:

git clone git://192.168.1.100/home/repos/repo_name.git

This will clone the repository into your current directory. There are several protocols used to make a remote repository available, git://, ssh:// and http(s)://. There are advantages and disadvantages to each that you can explore yourself.

You can also create a repository on a remote server that everyone on your team has access to. You can then set the remote repository that your local repository should look for when pushing and pulling changes to and from the remote server. Just type:

git remote add remote_name user@remote.location:remote_repo/location.git

The remote_name is an identifier that you will use for pushing/pulling. Once you have added the remote repository you can fetch changes from the remote server by typing:

git fetch

Then to merge the fetched changes into your master branch:

git merge

You can also combine the 2 command into one (which I find more useful):

git pull

If you have multiple remotes and/or you want to pull a certain branch down to your local repository, you need to type:

git pull remote_name branch_name

After resolving any conflicts you now have the latest working copy from everyone on the team.

To push your own changes to the remote repository, type:

git push

or

git push remote_name branch_name

I always find it beneficial to pull and resolve any conflicts before pushing my own changes. Pushing your changes doesn’t need to happen as regularly as your commits — maybe once or twice a day depending on how your team works.

There are many complicated working patterns that a team may develop when implementing a version control strategy. For example, you may want all team members to push changes to a particular person that dictates whether to include them in a master repository. Or maybe you might have a testing remote repository that you push changes to for testing on a replica of the production server before pushing to the production repository itself. The sky is the limit for coming up with better ways to work with others.

That’s about all you need to know to get started with GIT. There are of course many more advanced features like stashing, tagging, hooks etc that I haven’t talked about here but the following resources are a great place to start if you want to delve deeper.

Some great GIT resources

http://gitref.org/
http://git-scm.com/book
http://git-scm.com/downloads

GIT repository hosting

The following links point to websites that you can use to host your repository online. You can make the repositories public or private (there may be a charge for private repositories). There are some great features to using these sorts of sites, especially for working with others (such as issue tracking)

https://github.com
https://bitbucket.org

GIT GUI clients

If using the terminal is getting you down or you’re more of a visual person then maybe using a GUI client might be for you. Here is a non-extensive list of free and paid-for applications:

Tower – Paid – Mac
Gitbox – Paid – Mac
GitX (L) – Free – Mac
Git Extensions – Free – Windows
SourceTree – Free – Mac, Windows
git-cola – Free – Mac, Windows, Linux
SmartGit – Paid – Mac, Windows, Linux
GitEye – Free – Mac, Windows, Linux

The challenges ranged from deployable greenhouses on Mars to exploration of the dark side of the Moon. As I was working alone, I decided on the My Space Cal challenge. This involved querying various sources of scheduling data for space based telescopes and collating it into a calendar that scientists and researchers could use to plan space observations using the various telescopes.

The data gathering process was more laborious than I had expected as each telescope presented its data in different formats. Some had websites that could be scraped, some had CSV files I could download, and some had data in such a random format, it was almost impossible to parse the fields I needed. This process of building scraping scripts took most of the first day, along with creating a DB schema to hold all the scheduling data.

On the second day I got my hands dirty with the D3 JavaScript library – something I had been looking for a use for for a while. Rather than just building a simple calendar I thought it would be more useful to created a timeline of events so it was easy to compare different telescopes at the same time.

Although I spent a good amount of time working on it, I didn’t manage to get all the features built into it that I would have liked in the 48 hours. I wanted to be able to add filters for target names and wavelengths as well as a cron job that could retrive data automatically each day. Also some telescope data is missing such as for the Hubble, Spitzer and Chandra telescopes. I plan on working on this some more in the future as I think it would be a really useful tool for professional astronomers to use.

You can check out the Telescope Schedules application (works best in chrome) – the source code is available over at github.

UPDATE

I received an honourable mention for my application at the awards for virtual participation. Very happy with that!

Professional - A person following a profession, especially a learned profession.

Amateur - A person who engages in an art, science, study, or athletic activity as a pastime rather than as a profession.

As concrete as these definitions appear to be, I believe there is more and more overlap these days. People with hobbies in Astronomy, Art, Sport, Computer programming etc are making greater and greater contributions to their fields of interest.

For example, amateur astronomers are discovering exo-planets many light years away. Enthusiasts are building and engineering solutions to problems using open-source technologies built on top of Arduino microcontrollers and the Raspberry Pi. 3D printing will soon be cheap enough that people can print almost any 3D object they can imagine.

Amateurs can lift their heads high, above the stigma of tinkerers and dabblers. Amateurs often have several hobbies and interests. They’re sometimes labelled as Jacks of all trades, masters of none – a derogatory turn of phrase, that I believe amateurs should no longer need to endure.

The 80/20 rule that seems to rear its head a lot in the universe can be applied quite well here. Amateurs can obtain 80% of the knowledge of a professional in the same field whilst dedicating perhaps 20% as much time as a professional.

Do you need to need to gain 100% knowledge in a field to make valid contributions. No, I don’t think so.

And by not trying to become a professional in a field, you open up so many more possibilites for learning. You can become competent in many fields. This is something employers are looking for more often these days due to cuts in the economy. People who are multi-skilled are valuable. And not only in the job market. Multi-skilled amateurs can combine their skills to come up with concepts and products that a single skilled person could never dream up.

The think tank, Demos, released a short ebook about the impact of professional amateurs. It’s well worth a read. Professional amateurs or (Pro-Ams) are described as amateurs who ‘work’ to a professional level but do not consider their interests/activities as their profession. It is an aspiring title that doesn’t come with the pressure of performance for your livelihood. Instead you ‘work’ at a professional level for the fun of it and can still make significant contributions to the development of your field(s).

As an aside, I wanted to briefly talk about autodidactism. An autodidact is someone who learns on their own. They gain knowledge by reading and by experimentation. This is of course the opposite of learning via traditional education – school, college, university. So much can be learned now that information is such an abundant commodity on the internet. Traditional education has its merits of course. It’s much more structured for example, and you are learning from experts. But you can’t tackle multiple fields of interest at university level. It would cost too much in time and money and traditional education in almost all cases focuses on a smaller and smaller niche of a field, the further you study – Bachelors degree -> Masters degree -> PhD -> and beyond.

Amateurs are natural autodidacts. They crave information about their chosen field(s). Their thirst for knowledge is insatiable. Most of all, they pursue their interests because it makes them happy. They don’t need to become a professional to reach this goal. That only limits us. Be proud to be an amateur. Widen your field of view and see what you can create, achieve, contribute and discover.

Facebook – strictly for communicating with close (real world friends – i.e I physically see them at least once a year) and family*
Twitter – this is the only place I will actively network with people and organisations I don’t know personally. If I have interesting news or tidbits, I will most likely share them here.
Flickr – will become my home for any photos I take, whether it be with my phone, or new camera. May occasionally share some of these photos with Twitter and Facebook manually.
Github – any code I create that I’m happy to share with the world will be found here.
Soundcloud – any music I make will end up here (again only if I’m happy to share it)
Spotify – if you wanna send me a tune, feel free, I’ll take a listen…
Skype - If I’m online, I will be on Skype. This is by far the quickest way to get in touch with me
This site – for anything much longer that 140 characters, it will appear on this blog.

That’s it! It may still seem like a lot, but I’m only using each network for a specialised function. I think that a lot of new social networks that pop up everyday don’t offer anything new, and just suck your productivity away. All the links for these accounts are in the header of my website above.

Some networks that didn’t make the cut:

Instagram – poor quality photos that I can post on Flickr anyway now and I don’t have many connections here anyway.
Google+ – again not many connections and although it has some nice features like the communities, it’s not worth my time sharing stuff to it.
LinkedIn – my profile will remain, but I’m not going to actively participate anymore.
Many more - I no longer interact with a lot of other services that I’ve probably forgotten the login for anyway. I will close these down as and when I come across them again.

I will be retreating from these networks over the next month.

What are the benefits of reducing the networks you involve yourself with?

1. Less likelyhood of identity theft (especially if you sever all cross-pollination plugins that post facebook messages to twitter etc etc).
2. Less services to feel compelled to check and interact with every day.
3. No more reading the same things by the same people on different platforms – what a waste of time.
4. More time to spend in the real world doing real things (that ironically become worth sharing with friends on social networks)

* I also need access to various facebook pages for business use and to one or two Facebook groups for my studies, but that’s by-the-by.

In my Cosmology module, we had to read and understand about the basic particles and their interactions and so I thought I would create a diagram to help me remember how particles are classified, e.g. an electron is a lapton and a fermion etc…

Hopefully others will find this useful too. I intend to compliment this diagram with another one to show how the various particles interact and the forces between them some time in the near future.

If you spot any mistakes, let me know…