However when I installed the extension, I was a little annoyed to see that there was no bash tab completion for patch names. This was pretty important for me, saying as my patch names can be pretty long (I like to keep them descriptive).

Thankfully, I found an easy way to enable this in Ubuntu:

Just add the following to your /etc/bash_completion.d/mercurial file:

_hg_cmd_qup()
{
	_hg_cmd_qpush
}

Then you’ll need to source the file to enable it:

$ source /etc/bash_completion.d/mercurial

This should work with any OS with bash, you just might have to go looking for the right bash_completion file.

This is a god-send for people who develop websites in linux (myself included). Before I had a host of virtual machines running WinXP, each one with a different version of IE on it. This may seem a bit bloated, but I was convinced that many of the multiple IE solutions already in the wild seemed alright, but missed some of the subtle rendering problems of the proper versions. It would be awful to think a site was rendering properly in all target browsers, when in fact some subtle things went unnoticed.

I viewed this product with similar skepticism, but the benefits that it would bring me still warranted a look. So I gave it a go, and decided to test the rendering of the Acid2 and Acid3 tests. The advantage of these tests is that they also probe the javascript support for each browser as well as the visual rendering. Accurate rendering of these tests would indicated that IETester is behaving exactly as each browser should.

Results

The results are pleasing:

Acid2

IE Version	IETester	Reference
IE 5.5
IE 6
IE 7
IE 8b1

Acid3

IE Version	IETester	Reference
IE 5.5
IE 6
IE 7
IE 8b1

The screenshots show great rendering compared to the reference images. Differences in resolution and viewport size makes some of the renderings look off, but the actual content is rendered properly. The eagle-eyed will have spotted that some of the numbers in the Acid3 tests are different. I believe this is due to the screenshots being taken before the javascript tests were completed. In any case, the rest of the rendering of the Acid3 is spot on for all browsers, so I’m not worried about this little difference.

Conclusions

This is a fantastic tool for cross-browser testing. I have enough confidence in its correctness to now get rid of my entire farm of virtual machines. Not only is it accurate, but it is also very nice to use, with a well thought out user-interface. There are some little bugs in the program itself, but this is to be expected from such a young project. None of them are obtrusive enough to put me off using the program. On the whole I’m very happy to use it—saves me a lot of hassle.

Resources

• IETester Homepage – Get IETester here
• Browsershots – A fantastic free service that renders a screenshot your website in a practically every browser in the wild—and then some! (Used for the reference images above.)

Your Thoughts

Comments, questions and suggestions are always welcome. Just leave a comment.

— Martin McNickle

Motivation

We’re currently moving all of our repositories to a brand new, purpose built development server. In an attempt to do everything right from the start, this particular task was on my to-do list. Everytime the old server was restarted, I had to go in and start the subversion server manually. This script does away with that.

How?

Download the startup script and copy it to the /etc/init.d/ folder. You will need superuser access for this. (Either sign in as root, or type sudo before each of the commands). This can be done in the terminal:

$ cd /etc/init.d/
$ wget http://www.whompbox.com/wp-content/uploads/2008/07/svnserve


Next you want to make the script executable:

$ chmod +x svnserve

Now add it to the startup sequence:

$ update-rc.d svnserve defaults

Now you should configure the few things in the script which are specific to you. These can be found at the top of the file. The two that you are most likely to change are

SVN_ROOT_PATH
SVNUSER


which tell the scripts where your repositories are on the system and what username you want the daemon to run under.

Finally:

$ /etc/init.d/svnserve start

to start the server.

Resources

svnserve startup script

Your Thoughts

Comments, questions and suggestions are always welcome. Just leave a comment.

— Martin McNickle

Motivation

More and more of the projects (mostly website development) that I am involved with involve a number of developers. We use Basecamp to keep a tab on our correspondence, deadlines, bugs etc. This has proved pretty successful, and with the intention of its continued use, I set out to make it more useful for our particular (code-based) needs.

Another tool used on these projects is Subversion (SVN), to keep a track of changes in the codebase. It seemed like a good idea to tie SVN in with Basecamp, keeping the people on the project informed in the changes in the code.

Luckily Basecamp has an open API, making this sort of integration very easy.

Assumptions

This article assumes working knowledge of SVN i.e. how to create and access repositories etc. You should also have full access to the server on which the repository is hosted i.e. an ability to add/remove files, change folder permissions etc. The installation below is based on a linux system and basic linux console commands are assumed. A tiny amount of PHP is required.

Basics

You must have the API support turned on for your Basecamp account, this can be done in the settings page.

You should have a working SVN repository already installed. The examples assume the repository is installed at /path/to/repository/.

Installation

The script will be run after someone commits a change to the repository. A default installation of Subversion has a series of scripts that are executed at various stages of the commit process. These “hooks” can be found in the folder /path/to/repository/hooks/. The one we are interested in is the “post-commit” hook. We will instruct SVN to run our PHP script in this file.

The files in the hooks/ folder are just skeleton scripts. You will notice that they have a .tmpl extension. This must be removed before SVN processes them:

$ cp post-commit.tmpl post-commit

The script must also have execution rights:

$ chmod a+x post-commit

Now it is a matter of installing the custom scripts.

My code is based on a PHP wrapper written by Aaron Quint. This bit of code requires two PHP modules to work — HTTP_Request and XML_Serializer. These may be included in your installation of PHP already. If not these can be installed via PEAR (may need root access):

$ pear install HTTP_Request XML_Serializer-0.18.0

Now download my code. It contains all the files you need. This can be downloaded from the console using wget.

Unpack this into the hooks/ folder:

$ tar -xzvf BasecampSVN.tar.gz

You now need to configure notify.php with your particular Basecamp details. These are stored in variables in notify.php:

$bc_user
$bc_password
$bc_base_url
$bc_project_id
$bc_category_id
$bc_company_id

Their explanations are pretty self-explanatory, but there is additional information in the script.

Now add the following lines to the post-commit file to tell SVN to run the notify script:

REPOS="$1"
REV="$2"
php $REPOS/hooks/notify.php $REPOS $REV


Testing

Give it a try now, change some files in the repository and commit them. All going well, you should see a message posted on Basecamp, detailing the changes to the repository.

If this isn’t the case, you can run the script manually and look for any error messages that may be returned:

$ php notify.php /path/to/repository revision_number

Other features

Just like any other Basecamp message, you can tell the script to send email notifications to people in a certain company and make the post private. These options can be set in notify.php.

Conclusion

This script has certainly proved successful on the projects I have been working on. It provides the practical advantange of letting the developers see where and when the code has been changed. It also lets the client of the project see that the project is making progress, something that can be difficult to convince them of at times

Special thanks to Cazinc Web Design for supporting the development of this open source project.

Resources

BasecampSVN - v0.1.2

Your Thoughts

Any problems, bugs, comments or suggestions are always welcome. Just leave a post below.

— Martin McNickle