Top Tip: Upgrade Git on Cygwin

The current version of git installed with Cygwin (1.5.x) has at least one annoying bug so it’s worth building  the latest version (NB I have almost all of Cygwin installed – you may need to install additional development tools and libs):

1. Download and unpack the source code. Pointer here
2. Run ‘./configure –prefix=/usr/local’
3. Run ‘make test’
4. Ignore errors relating to not detecting unwritable repos
5. run ‘make install’
6. run ‘hash -r’
7. Make sure it’s installed with ‘type git’ and ‘git –version’

Update March/09 — I found more detailed instructions

Handy Hack: Comparing two directory trees on Solaris 8

After some information from jim mcnamara I developed a script to compare two directory trees. I needed something that worked on Solaris 8 so it uses basic UNIX tools (and dircmp was not very useful). If you are using a more modern system then try this

#!/bin/ksh

#  Compare 2 directories for differences (e.g. current release and new release)

CURRENT=$1 ; shift
NEW=$1; shift

CURRENTDIFFFILE=/tmp/$(echo $CURRENT | sed -e 's/[/.][/.]*/_/g')
NEWDIFFFILE=/tmp/$(echo $NEW | sed -e 's/[/.][/.]*/_/g')

# File pattens not to be included in compare
cat << 'EOF' > /tmp/patternFile
^.git/
^.*\.log
^logs/.*
^.*\.tmp
^.*\.err
EOF

for i in $CURRENT $NEW ; do
	cd $i
	# cut removed ./ that find puts at start of path name
	find . -type f -print |cut -b3- |egrep -v -f /tmp/patternFile | sort > /tmp/$(echo $i | sed -e 's/[/.][/.]*/_/g')
	cd -
done

echo New files
comm -13  $CURRENTDIFFFILE $NEWDIFFFILE

echo
echo Deleted files
comm -23  $CURRENTDIFFFILE $NEWDIFFFILE

echo
echo files that are different
# xargs has limitations so must pipe into a second shell
comm -12  $CURRENTDIFFFILE $NEWDIFFFILE | xargs -i echo cmp -s \"$CURRENT/{}\" \"$NEW/{}\" \|\|  echo {} changed | sh

It’s all about the process stupid!

BBC NEWS | Health | Surgical checklist ’saves lives’

Using a simple surgical checklist during major operations can cut deaths by more than 40% and complications by more than a third, research has shown.

Does ANYONE need persuading on the value of a process when performing technically complex work? Including software development and service management…

Application deployment and change auditing with git

Updated 6/Feb/09

I’m currently working on on a project to deploy some complex banking systems and we have some somewhere in the region of 40 environments (various testing, production and development instances)

I’ve written some Perl to automatically configure environments using Text::Template. Now I’d like to automate deployment and have some form of change auditing (c.f.AIDE or Tripwire).

So a new project (which I hope will also  have some useful ideas for others):

• Project Outline and User stories
• General Approach using git (other tools could probably be used)
  • Define a staging repo
  • Create a remote branch of each deployment environment
  • Create a repo on each environment
  • Define a custom merge driver that overwrites (old files with new releases)
  • For each release
    • Create a new branch (overkill?)
    • Add new release to new branch
    • tag
  • To deploy
    • Merge (using new driver) onto environment branch
    • tag
    • Push to remote
    • On remote perform git reset --hard HEAD
    • configure
    • add and commit configuration changes
    • on staging pull config changes from remote repo
  • Now use git status etc. on environments to track any changes
  • Staging should have historical record of changes

Top Tips: Using the EEEPC 1000H

I’ve has my EEEPC 1000H for over a week now and I’m so totally enamoured of the small device that it’s become my sole platform for all my computing. Obviously this has involved some adjustments.

1. The keyboard requires considerable patience — at least for someone with my large fingers
2. My fingers are having to learn new positions to try and stop keep brushing the trackpad and moving the cursor to somewhere completely different. This is currently the most frustrating aspect of using the machine.

Some things to try.

• Get a bluetooth mouse
• Try the LXDE desktop and the Xfce4 desktop. They are both tuned for low resource use
• Consider using DevilsPie to reduce the amount of screen space used by removing the title bar and forcing all screens to be full maxiumum, partucurly of your screen is smaller than 10″
• Configure Skype to use the hda sound devices
• Carry a short USB cable for thumb drives etc. Thy can’t always fit in space you have at the side of the netbook
• Get used to using keyboard shortcuts — it mush  easier than using the trackpad
• Try using Vim and it’s plugins rather than  a large IDE
• Try using an alternative email  and PIM program to Evolution. Thunderbird for instance works better on the smaller screen and is faster
• Use multiple desktops and flip between them using <ctrl><alt><arrow> (Gnome default), for instance when referring to other material in the middle of witing an email. It’s an easier way of switching back and forth between two applications that using something like <alt><tab>
• Use the <F11> in Firefox to move into full screen mode (many other applications have a similar feature)
• Do as much as possible by typing at the terminal

Thanks to git I’m releasing IP into the wild!

This week I at last did something I’d wanted to do for a long time and  release some of Voga’s intellectual property to the wider world.

I have already made material available either through this blog or via Slideshare. However for a geek it’s obviously better to publish complete projects in an Open Source manner so  they can be freely copied, modified and shared.

For historical reasons this had been inconvenient to do as I used to hold everything in a single Subversion repository. Not only did this contain my potentially open material, but also my customers private data and my business records (yes, I keep my accounts database in a version control repository!). A few months I migrated my Subversion  repo to git, but I still had a single large repo and no time or skill to fix it.

However today I bit the bullet

1. Removed all my possibly public data to another directory structure
2. Tidy up my current repo by removing all the old ‘trunk’ directories — as a solo consultant I was lucky and had never had to branch my projects. Commit my new streamlined repo

Now to work on the the public projects

1. Identify a complete project and make sure it had no proprietary data. This is potentially time consuming
2. Tidy up some of the names
3. Create a new git repo; add the project files; and commit
4. Create a new repo on Github for my project
5. Follow the simple instructions to upload my project to github

To Do

• Update existing references to my projects I can find and update to point to the repo
• Add the correct license files
• Start again for as many projects as possible, please be patient

I’ll still keep presentation copies on Slideshare because that is much more convient for most people.

A big thank you to the git developers and github for making this so easy