RicRoberts :

Ruby on Rails Linked Data content negotiation skeleton code

Wed, 15 Jul 2009 18:10:00 +0100

Bill wrote on his blog a few days ago about an example Rails app that he created to demonstrate the basics of how we do Linked Data content negotation at Swirrl.

As he mentions in the article, Bill put this together partly in response to a discussion on the LOD mailing list about ways of implementing the content negotiation process without reliance on Apache.

Take a look at the README in the Github Repository for more details.

RubyInside roundup

Mon, 13 Jul 2009 12:50:00 +0100

I’ve recently started blogging regularly over at RubyInside.com (the Ruby news, links, code and tips blog), which explains why I’ve been a little bit quiet of late. To try to fill the silence, I thought I’d post a list of links to my recent posts:

Now that I’ve got used to the style and content required for RubyInside, I’ll try to step-up activity on this blog again.

5 Ruby-related blogs for July

Wed, 01 Jul 2009 11:59:00 +0100

Last month, I posted my first set of five ruby-related blogs for your delectation. Here’s five more for your RSS reader:

Ruby Inside: A Ruby news, links, code and tips blog, to which I’ve recently started contributing.
Robby On Rails: A blog by Robby Russell from Planet Argon. Full of useful rails tidbits.
A Fresh Cup: Mike Gunderloy’s mostly link-based blog focusing on Ruby On Rails. I always find something interesting here.
Alex Young: Blog from a London-based web developer, who runs Helicoid and QuiteUseful.
Igvita: Ilya Grigorik’s blog, often featuring Ruby-related articles.

Getting to grips with git - Part 3: rebasing

Mon, 22 Jun 2009 12:02:00 +0100

This is the third post in my Getting to grips with git series. In previous articles, I’ve covered the basics and merging, branching & tags. This time, I’m going to introduce the concept of rebasing. I think it justifies its own article as it’s a potentially confusing subject.

Rebasing

Rebasing is similar to merging in that it allows you to apply changes from one branch to another. Rebasing lets you replay/rewrite the history in your current branch against a particular point on another branch, so you can choose where in the history your changes appear.

For example, if say you branched from master to work on a new feature. When you branched, the state of the master branch was A, and after you’ve added some code, the state of your new feature’s branch is AB (i.e. A plus some new stuff B).

---A        master
   \
    ----AB  new feature branch

After working on your new feature for a bit, the state of the master branch might have moved on (maybe some bug fixes have been applied).

---A---------A'  master
   \
    ----AB       new feature branch

Now, to get those fixes into your new feature’s branch, you can rebase. From the new feature branch, run:

 git rebase master

This will bring the fixes into your new feature’s branch, as if you branched after the fixes were applied to master.

---A---------A'        master
             \
              ----A'B  new feature branch

A quick look at the history will confirm this.

 git log

Finally, to get your new feature into master, you can just do a merge as described in my previous blog post (from master):

git merge <new_feature_branch>

The steps I’ve just described form a common workflow. i.e.

Create a new branch B from an existing branch A
Make changes on new branch B
Rebase updates from branch A into branch B
Merge changes from branch B into branch A

Useful references on rebasing

Next time…

I still have a couple more posts planned, to cover a few more commands, git tools and forking.

Rails Underground Conference

Mon, 22 Jun 2009 10:18:00 +0100

At the end of last week, I booked my tickets for the Rails Underground conference in London which takes place towards the end of next month.

The speaker line up is really impressive, and features (to name but a few) Obie Fernandez, DHH, Robby Russell, Jim Weirich, and Dr Nic.

It will also be a good chance to catch up with some London Rubyists who I haven’t seen for a while.

Drop me an email or leave a comment if you’re attending too and want to meet up. See you there!

New blog on the web of data

Fri, 19 Jun 2009 11:16:00 +0100

At Swirrl, we’ve long been convinced of the benefits of the semantic web and linked data – and indeed those technologies underly the design of our application.

My co-founder, Bill, has just started a new blog where he’ll be exploring these topics in more depth: www.webofdatablog.com.

Getting to grips with git - Part 2: Branches and Tags

Sat, 13 Jun 2009 16:26:00 +0100

This is the second post in my Getting to grips with git series. Last time, I covered the basics; this time we’ll explore branches and tags.

Branches

How branches in git work

In git everything is treated like a branch, so they’re quick and easy to create and manage. Branching doesn’t involve copying the files into a new directory, like in other version control systems. Git keeps track of only the most recent commit to that branch and from there, it can ﬁgure out all the changes in that branch. (The history of changes in git takes the form of a Directed Acyclic Graph).

Branching marks the point that files in the repository diverge onto two different paths. Each branch keeps track of the changes separately. Changes in branches can be merged together later if you like.

So, what would you use a branch for?

You can use a branch for whatever you want, but they’re especially useful for keeping experiments or new features separate from bug fixes to already-released code.

Making a new branch

To make a new branch from the current one, use:

git branch <name of new branch>

If you then run the branch command with no params, it will give you a list of all the existing branches (with an asterisk indicating the current one):

> git branch
* master
  my_new_branch

Working with your new branch

Now, to start working on your new branch, you need to check it out. Remember, I mentioned last time that checkout means something different in git to subversion? In git, it refers to switching your working tree over to using that branch. Don’t worry – any committed changes will safely remain in the other branch (even if you’ve not pushed them to your central repository).

git checkout my_new_branch

Pushing your branch into Github

Once you’ve made some changes to your branch, it’s likely that you’ll want to share them with your colleagues. To push the branch up to Github, you can use:

git push <remote_repository> <branch_name>

e.g.

git push origin my_new_branch

Getting an existing branch from Github

What if someone else has made a branch and pushed it up to Github already? You can see a list of all the remote branches for a repository with:

git branch -r

It’s then simple to create a local version of that branch:

git branch <name of branch> <remote branch>

Merging branches

As I mentioned earlier, branches are commonly used as part of a release-process, to keep fixes to ‘live’ code separate from ongoing development. At some point, it’s likely that you’d want to get the bug fixes into the main development branch. This is where merging comes in.

There are three main types of merging:

Straight: Commits are just merged in as they appear in the source branch.
Squashed: All commits from the source branch are applied to the target branch as a single commit.
Cherry picked: A single commit from the source branch can by applied to the target branch.

For all types of merging, commands must be run from the target branch (i.e. the one you’re merging to).

Straight Merge

git merge <source branch>

Squashed Merge

git merge --squash <source branch>

Note that for squashed merges, the changes are applied as staged (not committed).

Cherry Picking

git cherry-pick <commit name>

... where the commit name is the SHA-1 hash of the commit you want to pick (or at least, enough characters of it to uniquely identify a commit). You can stage multiple cherry-picked merges by adding the -n argument.

Merge tracking and conflicts

Git has automatic merge-tracking that keeps tabs on what commits have been merged together, and so wont merge the same thing twice. Git will also warn you when you try to merge and it can’t resolve merge conflicts automatically.

Next time…

There’s still plenty more material to cover, including rebasing, diff, undoing changes, forking and git tools.

Update: Part 3: rebasing is now available.

5 Ruby-related blogs for June

Sat, 06 Jun 2009 16:55:00 +0100

Over the years, I’ve collected a fair number of Ruby blogs in my feed reader. I thought I’d start sharing them for the benefit of others (in no particular order). Here’s the first installment – I’ll list some more at a later date.

Ruby Best Practices – New(ish) blog about writing better Ruby code, to accompany the new O’Reilly book of the same name.
Ruby Flow – Community generated Ruby links site.
Rails Envy – Amusing but informative Rails-news podcasts by Jason Seifer and Gregg Pollack.
Ryans Scraps – Great resource for keeping up with developments in Edge-Rails.
The Rails Way – Blog about Rails best practices, run by Michael Koziarski, Rails-core member.

What is the semantic web and why is it important?

Wed, 03 Jun 2009 09:31:00 +0100

I posted a new article on ThinkAboutTech earlier today, about the semantic web:

Semantics are important. They always have been and they always will be, because they are fundamental to the process of communication. What’s been changing recently is the means that we use to record and communicate information, especially with the advent of the internet…

(read the rest of the article)

Getting to grips with git - Part 1: The basics

Mon, 01 Jun 2009 20:44:00 +0100

Introduction

I’ve been using the version control system, git (along with github) for a couple of months now, for my open source projects: grrid.js and Taskit. At Swirrl, we recently decided to take the plunge to start using git for our main code repository.

With this series of blog posts, I hope to ease the transition from subversion (or sourcesafe, or whatever) to git. In this article, I’ll just cover the basics. More advanced stuff will come later.

Why switch to git

There are several advantages to using git over other version control systems:

Being a distributed version control system, with git everyone has their own version of the whole repository. The central repository (at github in my case) is just arbitrary. This means that you can do operations such as tagging, branching and diff without having to be connected to the central server. This article by Eric Sink is a good explanation of how git differs from traditional version control.
Due to the git:// protocol and the way git stores and tracks the data and changes in repositories, it’s really fast and the repositories don’t take up much room on disk.
Quick, cheap, easy branching.
The repository and branches are separate from the filesystem.
Github. Why go to the trouble of hosting a central repository yourself, when you can do it securely, cheaply and quickly with github? There’s Sourceforge for svn, but for me Github does it better. If you can get to grips with Github, it opens up a world of possibilities for publishing or consuming open source code.

A little background about how git works

With git, the whole repository is stored in a (hidden) folder called .git at the top level of your project structure. The working tree (i.e. the actual files in your project) are just the ones you happen to be working with at the time. Git doesn’t track the files themselves, it just tracks their content along with some metadata (read more about this here).

There are a few locations for your content in git

The working tree. This is the file system, where you manually make the changes.
The staging area, where changes lie until they’re committed.
The repository itself, where committed changes go (you can have local and remote repositories).

Commits in git are labeled with an SHA-1 hash instead of version numbers. There’s a very small chance of the hashes ever colliding, so they can be assumed to be unique. Git actually generates a 40 character-long hash but normally the first 7 or 8 characters are enough to uniquely identify a commit.

Getting started with git

If you’re on Mac OS X like me, the easiest way to install git is to download the installer from the Google Code project. I used version 1.6.2.2. Alternatively, you can compile it from source or use Macports (see this guide).

If you want to share your code with others, you will need a centrally accessible server. Github provides just that, so go and set up an account and set up an SSH key.

Before doing anything else you should set some global parameters on your computer to tell git what your github username and email address is (you can override these on a repository basis if you like). For example:

git config --global user.name "RicSwirrl"
git config --global user.email my.email@address.com

Setting up a repository

Getting code on your computer into a repository in Github

First, just make the repository via the Github web interface.

So, you have a project on your computer that you want to track using git. Initialize it by changing into its directory and running:

git init

This will create the .git folder. Change into that folder, and edit the config file therein:

cd .git
mate config

Make the config look like this, using your github username and repository:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

[remote "origin"]
url = git@github.com:<username>/<repo>.git
fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
remote = origin
merge = refs/heads/master

(Update: you can also set the config values with git commands, as someone mentioned in the comments).

You then need to add all the files in the directory to the repository as at this point they’re not being tracked by git yet. To do this, run:

git add .

This will add all the files in the directory to the staging area I mentioned earlier. You can then commit these to your local repository, with a message:

git commit -m "my initial commit"

Now you have a fully fledged repository on your computer. To send it up to Github, just run:

git push

Note that by default git will push to the “origin” remote repository in your config, using the current branch. If you want to push to a different remote repository, using a different branch, you can run something like:

git push github mybranch

(Note: for this to work you’d have to define ‘github’ in your config file as another remote repo, and have a ‘mybranch’ branch).

Push is a similar to a subversion commit, in that it allows you to share your changes with your colleagues.

Working with a repository that’s already on Github

What if one of your colleagues has already set up the repository on Github? To get started, you just need to clone the remote repository like this (using the clone url displayed on the github page). For example:

git clone git://github.com/Swirrl/grrid.git

I suppose this is equivalent to a subversion checkout. Watch out, though, because checkout means something a bit different in git.

Working with the repository

Adding files to the staging area

You’re now ready to start making changes to your code. Once you’ve made a few changes, you can see what’s happened by running:

git status

If you’re ready to commit some of these changes to your local repository, you need to run git add on each file you want to commit. This adds these changes to the staging area.

git add <filename_to_add>

What’s the point of the staging area?

The staging area lets you choose which of your changes you want to commit – a bit like checking/unchecking files in the svn commit dialog in TextMate (or your editor of choice). You can change the files in your staging area as many times as you like, before committing.

Committing to the local repository

You can run git status again to check what’s going to be committed. When you’re happy, run:

git commit -m "my message"

...and the changes will be committed. If you know you just want to commit all the changes that you’ve made, you can do it all in one go by running this (i.e. skip the staging step):

git commit -a -m "my message"

Pushing your changes to the remote repository

At this point, the changes have been committed to your local repository, but the remote Github repository remains unchanged. For your colleagues to be able to see your commits you need to push them up to the remote repository with:

git push

Pulling changes from the remote repository

If you want to see what your buddies have been up to, you need to pull their changes from the remote repository.

git pull

This will fetch the remote changes and merge them with your local ones. (It’s a bit like the update command in subversion).

Viewing the log

To see the history of the commits in a repository:

git log

Getting Help

Many git commands can take multiple optional arguments which I haven’t covered here. To get help on the usage of any command you can do:

git help <command>

Next time…

I think that’s enough information for one blog article. I’ll follow up soon with more advanced topics such as branching, merging, tagging, diff, and undoing changes.

Update: Part2: Branching and Tags is now available.

RicRoberts :

Ruby on Rails Linked Data content negotiation skeleton code

RubyInside roundup

5 Ruby-related blogs for July

Getting to grips with git - Part 3: rebasing

Rebasing

Useful references on rebasing

Next time…

Rails Underground Conference

New blog on the web of data

Getting to grips with git - Part 2: Branches and Tags

Branches

How branches in git work

So, what would you use a branch for?

Making a new branch

Working with your new branch

Pushing your branch into Github

Getting an existing branch from Github

Merging branches

Straight Merge

Squashed Merge

Cherry Picking

Merge tracking and conflicts

Tags

How should I use tags?

Next time…

5 Ruby-related blogs for June

What is the semantic web and why is it important?

Getting to grips with git - Part 1: The basics

Introduction

Why switch to git

A little background about how git works

Getting started with git

Setting up a repository

Getting code on your computer into a repository in Github

Working with a repository that’s already on Github

Working with the repository

Adding files to the staging area

What’s the point of the staging area?

Committing to the local repository

Pushing your changes to the remote repository

Pulling changes from the remote repository

Viewing the log

Getting Help

Next time…