Installing Git from source on Debian Lenny

I tend to use the most current release of Git, and had to install it on a new Lenny server today.

These are the steps required to do so:

1. wget http://kernel.org/pub/software/scm/git/git-1.6.3.2.tar.gz
2. tar -xzvf git-1.6.3.2.tar.gz
3. cd git-1.6.3.2.tar.gz
4. sudo apt-get install build-essential linux-headers-`uname -r` libssl-dev curl libcurl4-openssl-dev libexpat1-dev tcl
5. make prefix=/usr/local/ all
6. make prefix=/usr/local/ install
   

Done!

Tracking forks on Github

I have been using github for a few of my projects, and occasionally have forked another project so I can add my own changes.

Today I forked a project and made some changes, and then found another fork with some code I wanted.

The project is simple-navigation - a Rails plugin to create and manage multi-layered navigation.

After creating a fork on github, I cloned my new fork locally:

$ git clone git@github.com:rhulse/simple-navigation.git

I then added my own changes and committed them.

User edk has added some breadcrumb code that works in a similar way to some standalone code I use in my projects. I want to grab this code, have a look at the differences, and merge it in to my master branch.

The first step is adding edk's repository as a remote:

$ git remote add edk git://github.com/edk/simple-navigation.git

Step two is fetching any objects in that repository that I don't have in mine:

$ git fetch edk

The output from that command looks like this:

remote: Counting objects: 25, done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 17 (delta 12), reused 0 (delta 0)
Unpacking objects: 100% (17/17), done.
From git://github.com/edk/simple-navigation
* [new branch] gh-pages -> edk/gh-pages
* [new branch] master -> edk/master

It is then a simple matter to create a branch and put edk's master branch in it:

$ git checkout -b edk edk/master

The last step is to compare the changes between my master and the edk branch. At this stage it might be tempting to just type this:

$ git diff master edk

The problem is that while you'll see all the additions made by edk, you will also see changes made on the master branch as removals.

To see just edk's changes I used this command:

$ git diff master...edk

This does a diff from the most recent common ancestor. The resultant output contains only code made since the point at which edk started adding changes. (Hat tip to Scott Chacon who mentioned this in his Scotland on Rails git talk)

If I wanted to change any of the new code I could do it in the new edk branch, or make a third branch.

The last step is to merge the new code into my master branch. While on master:

$ git merge edk

When these changes are pushed back to github, the network display page will show the new activity and merges.

And before you ask, you can track as many remotes as you want.

Installing a Rails plugin from GitHub through a firewall and proxy

I was working on a Ruby on Rails project today with Nigel from Able Technology, and we wanted to install a plugin from GitHub.

We had a few problems because of a corporate firewall and an http proxy server. Only port 80, http traffic was allowed.

To do this in OSX the following steps were necessary:

1. Set the htttp_proxy variable in the shell:

export http_proxy=http://our.proxy:our_port

if your proxy requires a username and password the command is:

export http_proxy=http://username:password@your.proxy:your_port

2. Run the import using http instead of the git protocol:

script/plugin install http://github.com/adamlogic/showoff.git

Converting English dates to Maori with Ruby

In the project I am working on at the moment (my first Rails project) I needed a quick way to convert a date set in English (with the month and day of the week in full) to Māori.

This was a pretty simple function to write, so in plenty of time for Māori Language Week (27 July - 2 August 2009) here is the Ruby function.

It turns this:

Monday 20 April 2009

into this:

Rāhina 20 Paengawhā-whā 2009

Moving from PHP to Ruby (and Rails)

For the last year or so I have been porting a legacy PHP application to the Kohana framework. This is not really a legacy app that needs replacing - the system is still highly functional and meeting the needs of staff who use it.

The main problem has been maintaining the spaghetti code that is common in PHP apps written circa 2003. It's not really that bad, its just that things have moved on, and it would be a nightmare for anyone else to make changes to the system. Actually it is getting to be a nightmare for me, mostly because adding new features requires an increasing number of ugly hacks.

The port has been an on-again, off again. I began using the CodeIgniter framework, but changed to Kohana when they added support for PHP5 and started adding useful features not in the other framework.

One of the main issues though, has been the rate of change in both projects - CodeIgniter has been slow and steady, while there has (possibly) been more innovation in Kohana.

In the case of CodeIgniter, it did not always have what I needed (and they weren't taking patches), while Kohana was changing a lot with each major release.

I am definitely not saying that the approach taken by the writers of these frameworks is wrong. They are both good products. But for me I want to be writing business logic, not worrying about how to get a (not available) feature working, or having to rewrite code to account for internal framework changes. Life's too short...

My frustration with both frameworks has led me to look into Ruby on Rails. The byline on the website pretty much sums up what I wanted to experience in my daily work writing software - "Web development that doesn't hurt".

Alongside this we've also had the guys from AbleTech working here on a couple of projects, and I have been impressed with what they have been able to achieve with the Rails framework.

To get started I am porting another smaller web app to Rails. It is going well, and I'm getting to like the syntax very much.

True to the Rails methodology, I got the basic app running and deployed (via Capistrano) in about 20 minutes. From there it was straight into recoding the logic.

I'll be writing a follow-up post soon about the experience.