Resetting Mac OS X

We were looking to give some old Macbooks to other people, so we wanted to reset it back to a vanilla state, without the original OS disc. This means performing:

1) Remove user data/profiles

2) Securely erase free space so undelete will not recover anything.


I found these links which helped when operating in single user mode (hold command + s at startup):

– resetting users and the installation:

– erasing freespace –

Both can be achieved from the same single-user session. Once rebooted, the computer will launch the Welcome experience

On some newer macs, the diskutil utility may not work from single-user mode, so I ended up booting with a Mac OS X  upgrade USB (this one was for Mountain Lion for use on another computer) to use the DiskUtil GUI tool to clear the free space.

Note that applications will be left intact, so if you wanted to remove anything and tidy up the Applications drawer, you’d have to do this before removing the user profiles. These steps worked for an old G4 Powerbook and the original Macbook Air.

(this is useful too –


Timing HTTP GET with curl

I was looking for a way to time the effect of PHP code changes, and using Firefox Firebug net timing becomes cumbersome quite quickly. The alternative route is to do this simply is via the commandline using one of the net tools.

This is a simple bash alias to retrieve total time to retrieve a web page (without the content nor headers) – place this into your ~/.bashrc file:

timecurl() { curl -s -o /dev/null -w '%{time_total}\n' $1; }




> timecurl


Out of the various visual diff tools I’ve used, Meld was the excuse to fire up the NX terminal to Ubuntu instead of using the natively run Windows tools like WinMerge or Kdiff3. Occasionally I’m not on my home network so I needed to find a way to have it running properly on my Windows 7 laptop. Unfortunately it isn’t available as a native Windows application, but it is written in Python with a number of prerequisites.

Thankfully, someone else resolved all the issues so it can be run natively –


Integrating compass into an Eclipse workflow

After putting off any changes to my workflow due to the amount of work lately, I recently took the plunge into using the Sass preprocessor / Compass to help make managing stylesheets bearable again. Compass especially serves to give developers access to some lovely sugar, with commonly implemented solutions ready to integrate into your stylesheets – and will seriously reduce the amount of work dealing with different browser differences.

There are already many articles about  CSS extenders / preprocessors, and without going into the debate of Less vs Sass, the main downside is having to set up the development environment to process the enhanced stylesheets before we can view the results.

Installing Compass

Arguments against Sass (and implicitly, Compass) requiring Ruby to work are easy to workaround – there are guidelines for all platforms at – for Ubuntu 10.04, I ran:

sudo apt-get install rubygems

This installs all the necessary prerequisites. The Compass installation page gives all the necessary steps to get started.

You may need to add a path to the gems for the commands to work – assuming the scripts are located at /var/lib/gems/1.8/bin/  (say in the case of ruby 1.8) add this to the end of your ~/.bashrc file:

export PATH=/var/lib/gems/1.8/bin/:$PATH

With Windows, this is even easier. The rubyinstaller also sets up the paths for you! The remaining steps of installing sass / compass via gem applies.

Setting up a compass with an existing project

If you already have existing stylesheets, you will want to turn off preset scss files generated by compass with the bare option. You can also direct compass to follow your project’s folder structure.

Run this within your project root (for example /var/www/htdocs)  – note that this is just an example – and reflects my own setup:

compass install bare --sass-dir "app/pub/sass" 
   --css-dir "app/pub/css" --javascripts-dir "app/pub/js"
   --images-dir "app/pub/images"

(this should all be one line)

Directories will be created if they do not already exist. A config.rb will be created in your project root that tells compass which folders to scan. See for further guidelines and a nice wizard to guide you in setting up compass.

Usage overview

The main out-of-the-box route to processing SCSS/SASS files and/or Compass projects  is to run the command line app when you are ready to test new changes – in the case of compass:

compass compile yourapp/trunk/

This can be rather tedious though especially with the rapid approach to web development, and where simply refreshing the browser can suffice to see changes. To automate this process, compass and sass can watch for changes and compile automatically as required – just run this at the start of your session:

compass watch yourapp/trunk/

Again, you have to remember to start this process every session. There is a [paid-for] desktop GUI application to deal with this too, but personally, I’d rather not have to think about this!

Builders in Eclipse

I started looking into methods to automate this within Eclipse. We can break this down: the objective is to run compass after saving the SASS files.

One answer that has popped up several times on stackoverload is to write an extension to run an action on the save event – however without proper tooling in Eclipse, this would presumably be another project to consume your time in!

There is a solution however in the form of project builders.

Within Eclipse project properties (Project menu item > properties), you can find the  ‘Builders’ section, (this is also where you can enable or disable JavaScript parsing). The ‘New’ button allows developers to add external programs that run as part of the project build process.

In our case here, every time we save a file, we can trigger an automated rebuild of this file, and we need Project > Build Automatically to be enabled for this to happen.

Firstly though, we need to create the new builder. Just for information’s sake, I am running Eclipse Indigo SR2 with PDT v3 on Windows 7, but these apply equally for Macs and Linux platforms). These were the steps I performed:

  1. If not already, open the project property window (Project > Properties), and navigate to the Builders section.
  2. Click [New…]

    New builder dialog and the Project Properties window
  3. A dialog titled ‘Choose configuration type‘ will appear. Select ‘Program‘, and [OK].
  4. The ‘Edit Configuration’ window will appear for the builder settings. Name the new builder something relevant – in this case I used ‘Compass’;
  5.  The tabbed sections with notes:
    • Main page configures the external program –
      • Location: path to compass script. This must either be within the environment path (as set in the Environment page), or be the full path to the gem script. I’ve set this to [C:\Ruby193\bin\compass.bat] in my case. The dialog here will report if the program cannot be located.
      • Working directory: the project path as specified for compass (or where you want sass to operate). Mine is [Y:\ddc\htdocs]. Even though I use RSE to remotely access these files within Eclipse, external apps like Compass requires an actual filesystem path.
      • Arguments: compile

        Main settings for the Compass builder
    • Refresh specifies what you want to do after the program has finished compiling. I would like Eclipse to recognise the updated css files!
      • Refresh resources upon completion‘ is [checked]
      • Specific resources‘ is set to the output folder where the css files are saved to – in my case [app/pub/css] is ticked.
    • Environment allows you to set specific variables applicable to the command line or your application
      • Path – here, compass.bat would not run as Eclipse could not find ruby.exe, so the ruby/bin path had to be setup (in fact, I copied this from the Windows environment settings). Note it’s likely that this would not apply to Linux or Mac environments.
    • Build Options – what triggers this builder? plus miscellaneous.
      • Allocate console‘ [checked] so we can see the results in the console panel
      • Run the builder: [After a clean], [During manual builds], and [During auto builds].
      • Specify working set of relevant resources‘ [checked] – set this to the sass source folders – in my case, [app/pub/sass]. Any changes found in this folder will trigger this builder.
  6. When all done, [OK] the configuration. The new builder should appear as the last item of the list.
  7. Make sure that Project > Build Automatically has been ticked in the menu to enable automatic compiling.


Refresh settings
Environment variables
Build Options


The easiest way to test the new builder is to open the console panel, and create/edit a SCSS (or SASS if you prefer) file, and save within the sass folder. If everything is working, ‘building workspace’ should appear in the status bar, and the console should display the program path, and the results.

Auto-build console output

The icing on the cake – you only have to perform this once for each project instance!


An automated build process using external tools – applicable with other preprocessors – i.e. javascript minifiers. A streamlined workflow. One less thing to think about.

Using svn+ssh in TortoiseSVN over a custom port

Just discovered this – to connect to subversion over a SSH tunnel that’s not on the usual port 22, you need to save a PuTTY session using the custom port, and refer to the session name in place of the hostsname in TortoiseSVN.

It seems whilst TortoiseSVN accepts the usual svn+ssh://myhost/repository/path URI (and even the svn+ssh://name@myhost/repository/path variation), this assumes that SSH is running on the usual port 22. I have tried (using port 333 as an example) svn+ssh://myhost:333/repository/path and svn+ssh+333://myhost/repository/path, however these will cause a host not found error.

It turns out that TortoiseSVN accepts a session name in place of ‘myhost‘, and the session name can include characters such as “:” so this would be one way of making the innocent looking svn+ssh://myhost:333/ work!

i.e. create a PuTTY session named ‘new-sess:ion2’ using the SSH protocol connecting to port 333 – and this should work in TortoiseSVN:


– or a session named mysession:333 –


Now thankfully I do not have to be at home to view log information!