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 google.com
timecurl http://username:mypassword@testsite.co.uk/page/


> timecurl http://google.com


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 http://www.ruby-lang.org/en/downloads/ – 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 http://compass-style.org/install/ 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!

Reference: http://svn.haxx.se/tsvnusers/archive-2007-01/0272.shtml

Difficulties of choosing a content management system

How difficult can it be to settle on a system?

I have been evaluating different CMSes for various projects I am working on, and I can tell you, there is no such thing as a perfect CMS! For the uninitiated (and there will be!), a content management system (CMS for short) helps web site operators write and manage articles, pages, blogs and so on, without having to get with the nitty and gritty of coding.

Whilst I could just stick to using WordPress (which I am using for this site) for the new projects, it lacks certain things such as versioning (made a mistake? roll back!), transparent content translation, and proper access control list for finer grained control over what users can access.

Yes, WordPress itself has i18n for templates and the admin, but there is a difference between your application being usable in different languages, and your web pages having transparent translations.

So what am I looking for? This should cover most of the criteria:

  1. Clean URLs – the ability for the CMS to output user (and search engine) friendly URLs – i.e.  mysection/pageitem
  2. Hierarchical pages – being able to group pages together is pretty important for larger sites
  3. Clean/customisable administrative interface – so I can pass it over to the client and let them get on with it with the minimal of fuss withou them being confused nor intimidated.. likely through …
  4. … some kind of ACL / user access control … Give the client edit-only access to the content.
  5. Full template customisation – this requires strong/complete logic-design seperation, and allows the template designer freedom with the code
  6. Template as a file – rather than them being stored in the database;
  7. Per-page-per-template ability – full customisation of each page with its own look and feel
  8. Customisation per-page content variables – i.e. some pages may have two / three blocks of content which would need seperate content entry
  9. Ability to access/create extra database tables/objects – not all content may be in page format
  10. Accessibility of extending the system or integrating other applications with minimal of core-code hacking
  11. Good documentation!

Plus these are very nice to have, but the lack of will not be too much of a deterent, though this depends on the project, and providing it fulfills the other criteria (some of these are as mentioned previously):

  1. Content versioning – many good reasons to have this, the only negative would be extra complexity and space usage, though a good CMS would handle this transparently no?
  2. Content translation – straightforward method of allow the site editor to input content for a page in another language, and for the visitor to access the site in the language of their choice (if available)
  3. Image gallery support – especially for uploading images en-masse, the simple input-browse form element will not do!
  4. PHP-based templating system – no need to learn some obscure tagging system (read more on this at http://thephppro.com/articles/pte.php)

The target websites are your standard business-brochure-sites with a bit of jangle i.e. galleries, hierarchies of content, possibly even some ecommerce! So what’s out there that caters to this?

WordPress as a CMS

Now, since WP2.5 has been released, it has matured into a nice tool for its intended purpose. The new administrative design is certainly much more pleasing on the eye, as well as being simpler; it is much more intuitive for new users to find what they want now. Granted, I have used WP before to power a client’s site, however that was indeed a simple site, though I wish they had dealt with the image-resizing-after-upload back then!

As I wrote the above lists, I’m thinking, hang on, WP does cover much of them right now! It can output clean URLs, has a nice admin interface, does hierarchy for the pages, has PHP-based templates, and you can set up templates for each page. It has a huge community, with many modules and much support out there.

On the negative side, it does show its blogging roots with the lack of versioning and support for customised objects (via the database typically), and you are trading flexibility with content handling for straightforward simplicity.

So, a good choice if you can live with the limitations, or if you’re happy to hack- or should I say, mold – away at the code. Don’t expect to be too impressed at the procedural code base!

The other CMSes

The CMS scene has changed quite a bit since I last looked around, with new and promising systems coming in, and old going out – seen many *nuke systems being recommended much these days?

With the move towards PHP5, it has gotten more interesting.

Those quickly rejected

  • Joomla – if my last experience with Mambo (back then before it split into Mambo and Joomla) was anything to go by, I would quickly give this a miss. I had nightmares with trying to modify the logic to output tableless HTML, and I suspect it wouldn’t be so easy for the developers to change the inherent application design to seperate the design from the logic. Ever wonder why most Joomla-based sites looks similar? I have read some promising news regarding this though. For now, a quick miss.
  • Drupal – I gave this a go last time, and I tried again this time. I quickly remembered why I gave this a miss: the amount of faffing about you need to do to get it working the way you want it to. Yes, version 6 is indeed better – the admin looks cleaner to work with, and plus the taxonomy system is great for classifying content in whatever way you wish.

    The downfall is the amount of PHP code you must put into the node filters, or whatevernots to customise it away from it’s default drupal behaviour – i.e.  to output content in a particular way depending on the content classification.There is no straightforward content-structure seperation here – you add new content which needs a certain so and so, you will have to modify each filter for each block/template/plugin, and so on.

    I tried to like Drupal. If your particular site is compatible with how Drupal likes to deal with templates and content, good. Otherwise, time and hack sink. Targetted at the community website crowd, I’m sure there are many developers who are happy with how Drupal works, but I’m not one of them. It does have content versioning though.

  • EZpublish – this still feels rather slow and bloated for my needs, and still rather complicated to use, so no. Lack of community seems to deter too.
  • TYPO3 – enterprisey – though is that always a good thing? large server footprint required for this, so no, not good for performance.

Maybe, but…

  • Expression Engine – Looks very promising, especially with the amount of features and support coming from the users, and the unique way it handles content. The show stopper? the license. Whilst I could probably try using the Core edition to try an implementation, that’s yet more time investment to decide if it is suited to the project. Will be worth it one day if a project comes up that can cover this investment though.
  • Textpattern – It’s been raved about for how flexible it is. I looked at it… and drawbacks for me: templates are stored in the database, and it uses its own (XML-based?) templating system. Another is how little activity there seems to be with the developers! There is a new branch called ‘xPattern’ though.
  • Symphony21 – (not to be confused with Symfony, the PHP5-based development framework) This looks very promising, and whilst it does mean understanding XSLT instead of using PHP, it is rather powerful. The admin interface is beautifully minimalistic. A possible downside could be that XML-XSLT transformation may be slow, though it shouldn’t be an issue with caching. Only issue? I tried to sign up to download the release, and no email so far. Oh well, I’ll try again some day. Check out their spiffy videos too.

Currently evaluating

  • MODx – My initial look at this was of ‘this administration looks cluttered!’, but reinstalling it again, it doesn’t seem too bad. There are customisable content types, custom template variables and hierarchical pages and URLs are supported. Reasonably decent ACL. The downsides I’ve found so far is the custom template syntax (it uses [[var/command]] , and that’s just for starters) – yet more learning to do, and the admin interface still being slightly unintuitive. I will be looking at the code and extensions some more, but the community seems to be there.
  • Silverstripe – strong new contender here, it has a nice looking admin (though there are a few niggles and issues when trying to rearrange the site structure), and I’m sure a non-technically-proficient user will get to grips with this once they’ve been kept away from the whole setting up sections. The PHP5 OO coding is a big plus – it looks reasonably straightforward to extend the page types with your own demented needs. Current negative points are: custom template syntax, whilst simple to look at, it is lacking custom loops. It also does not support hierarchical URLs – and this is a popular request. I have been leaning towards this CMS, until I realised the lack of hierarchy. Good news is that the people behind this system are working on it.

Cutting my own CMS

What’s wrong with just rolling your own system? There is considerable time investment involved though. I have already built several CMS apps based on my own framework, and this is something that took place in leaps and bounds from project to project over a period of a couple of years.

They are lacking some of the features I am looking for in other CMS’s – I envy WordPress’s upload system and design, and they are basically beautified database-interfaces, no versioning nor multi-lingual ability, but it has search, and it has paging. It does the job, and a big plus of rolling your own system is that you can tailor it exactly how you want it! I am however reluctant to further work on the PHP4-based app, when I am already working on a PHP5 Zend Framework based system. If a client needs some custom development work, and pays well enough… well, this is always an option.

So back to the GO square…

So, carry on with the evaluations, and juggle with using WordPress…ah why not…

BTW any good image uploaders out there? Gallery outputs are easy to code; the uploading and captioning is not!