define( 'WPCACHEHOME', '/srv/www/' ); //Added by WP-Cache Manager development | Ian Chilton


Archive for the ‘development’ Category

Why Can’t Developers Estimate Time?

April 9th, 2011 1 comment

Ashley Moran just wrote an interesting article about why developers can’t estimate time.

Something most developers find hard is estimating the time something will take.

If it’s something you have done before, a repeatable task, then it’s easy – although most of the time things take longer than you think they will when you think it through in your head and quite often it turns out to be more complicated than you thought when you get into it or you hit a bug of some kind that you end up having to debug which takes a long time and compounds the issue.

Sometimes the problem of bad estimates is made worse is when estimates (which are at the end of the day an educated guess) are taken as a promise and therefore if it takes longer then there is a feeling that it should have been done quicker.

I particularly found these quotes interesting and amusing:

We can’t estimate the time for any individual task in software development because the nature of the work is creating new knowledge.

Rule of thumb: take the estimates of a developer, double it and add a bit

The double-and-add-a-bit rule is interesting. When managers do this, how often are tasks completed early? We generally pay much more attention to overruns than underruns

Categories: development Tags:

HTML5 Boilerplate Reaches v1.0

March 21st, 2011 No comments

This afternoon sees the HTML5 Boilerplate project (H5BP), led by Paul Irish, reach it’s much anticipated v1.0 release.

If you have not heard of the HTML5 Boilerplate (or H5BP as they started calling it recently) before, it’s an excellent and essential resource for web developers. It can either be used as a complete starting point for a new web project or as a large collection of cross browser recipes and best practices to incorporate into your existing projects.

To quote from the HTML5 Boilerplate Website:

HTML5 Boilerplate is the professional badass’s base HTML/CSS/JS template for a fast, robust and future-proof site.

After more than three years in iterative development, you get the best of the best practices baked in: cross-browser normalization, performance optimizations, even optional features like cross-domain Ajax and Flash.

A starter apache .htaccess config file hooks you the eff up with caching rules and preps your site to serve HTML5 video, use @font-face, and get your gzip zipple on.

Boilerplate is not a framework, nor does it prescribe any philosophy of development, it’s just got some tricks to get your project off the ground quickly and right-footed.

Today’s release of v1.0 isn’t just a bump from the Release Candidate to the final version, it also brings with it some exciting new material:

  • A Boilerplate Custom Builder – providing a custom package with only the features you require (similar to Paul’s previous Modernizr builder.
  • Improved Documentation
  • Improved Build Script
  • New video guides
  • Support for lighttpd, Google App Engine and Node.JS
  • Reduced size (50% smaller!)

You can find out more about the Boilerplate by watching the following videos. The latter is particularly entertaining and Paul is a great presenter.

Categories: development Tags: ,

DOM Monster

March 17th, 2011 No comments

There is an interesting new JavaScript tool circulating today – DOM Monster.

DOM Monster is our answer to JavaScript performance tools that just don’t give you the full picture.

DOM Monster is a cross-platform, cross-browser bookmarklet that will analyze the DOM & other features of the page you’re on, and give you its bill of health.

If there are problems, DOM Monster will point them out—and even make suggestions on how to fix ‘em.

You can read more and get it from here.

Categories: development Tags: , ,

Logging to Syslog with Kohana 3

March 16th, 2011 No comments

By default, the Kohana PHP Framework logs errors to files in the application/logs directory, separated into directories and files for each year, month and day (eg: application/logs/2011/03/16.php).

To change this behaviour to use the system log daemon, you change the following line in bootstrap.php:
Kohana::$log->attach(new Kohana_Log_File(APPPATH.'logs'));
Kohana::$log->attach(new Kohana_Log_Syslog('site_identifier', LOG_LOCAL1));

By default, these will probably appear in your /var/log/syslog file (on Debian/Ubuntu anyway – some other distributions use /var/log/messages).

You can configure syslog to put these in their own file by adding this to your syslog configuration file (on Debian/Ubuntu it’s done by adding a file into /etc/rsyslog.d):
local1.* /var/log/local1.log

If something else is already logging to local1, you can change that and LOG_LOCAL1 above to local2 and LOG_LOCAL2.

If you would like to write your own messages to the log, you can do so with:
Kohana::$log->add(Log::ERROR, 'error text');


If you would like to pull out different types of errors into different files, you can use this in your syslog configuration:
local1.=alert /var/log/local1.strace.log

Note that the errors are not actually written until the request has completed. You can force them to be written with the following:

You can also force this behaviour by setting Log::$write_on_add = TRUE; in bootstrap.php, but be aware there is an overhead to doing that.

If you would like to ensure that logging is setup before writing to the log, you can do the following:

if (is_object(Kohana::$log))
// Add this exception to the log:
Kohana::$log->add(Log::ERROR, $error);

// Make sure the logs are written:

Categories: development Tags: ,

weinre – Web Inspector Remote

March 15th, 2011 No comments

I recently blogged about a remote JavaScript debugging tool that Remy Sharp had created.

Along the same lines, this is something similar going around today that re-uses the interface for the Webkit Web Inspector (which is a bit like Firebug).

You can read more information here or watch the video below for a cool demo.

Categories: development Tags: ,

Technical Debt

March 12th, 2011 No comments

I listen to technical podcasts whenever I am driving alone in the car (i.e the daily commute). One of my favourites is Build & Analyze – A weekly news and discussion show about the world of iPhone, iPad, iOS, and mobile web development. Hosted by Dan Benjamin and Marco Arment (founder of Instapaper and the former cofounder of Tumblr).

This week, one of the discussion points was an interesting topic in which Marco entitled “Technical Debt”, which I found very interesting (and from experience, very true!).

The theory behind the concept of the term “Technical Debt” is this:

As a developer, every time you cut a corner, implement a hack or a short cut, or implement something in a sub-optimal way, you incur technical debt. Technical debt can be caused by time pressure, deadlines, commercial pressure or simply not knowing any better. While the feature may work fine for a while, technical debt, like financial debt has a habit of coming back to bite us later.

The re-percussions of technical debt can be things such as having to later re-write code to be able to add future improvements or tidy it up or it can be in the form of performance problems or outages – possibly brought about by a surge in popularity/traffic or increase in the amount of data in the system. You can guarantee that the effects will manifest themselves at the most inconvenient of times too.

Martin Fowler and Jeff Atwood (of Stack Overflow fame) have both written interesting posts about this concept and it’s something to bare in mind in the future when there is a temptation to cut some corners to get code finished.

EDIT: Here is another interesting article about Technical Debt.

Categories: development Tags:

Backing up a Subversion (SVN) Repository

March 4th, 2011 No comments

Here are some crude cron jobs I use to create nightly backups of svn repositories on the server (which will then get backed up elsewhere as part of the server backup).

The nightly backup will get overwritten each night, but a weekly backup is kept permanently.

When I say crude, they work fine for a quick job, but they are limited:

  • It’s only backing up a single repository.
  • If you need something from a few nights ago, you are stuck – you’ve only got last night and then it’s back to the last weekend (not so much of an issue with version control though as that’s the point of it! – the latest backup is all that should be needed….in theory).
  • There is nothing to delete the weekly backups. So, depending on the disk size and the size of the repository, you might fill the disk up a few years down line……hopefully you have monitoring to alert you before you get that far!
  • If the server happened to be down at the time the backup was supposed to run, you wouldn’t have a backup for that day/week
  • That said, here we go:

    # At 01:05 each day, dump the repository to a file:
    5 1 * * * svnadmin dump /home/svn/my_repository 2>/dev/null | gzip > ~/svn-backups/my_repository.svn.gz

    # At 01:15 each Saturday, dump the repository out to a unique file:
    15 1 * * 6 DATE=$(date +"%Y-%m-%d"); svnadmin dump /home/svn/my_repository 2>/dev/null | gzip > ~/svn-backups/week/my_repository-$DATE.svn.gz

    Categories: development Tags:

    Moving a Subversion (SVN) Repository to a New Server

    March 4th, 2011 No comments

    Moving a Subversion (SVN) repository from one server to another (or backing and restoring up your Subversion server) and keeping all of the history and commits is actually very easy:

    1) Dump the old repository: on your old svn server, run the following command to export out (and compress with gzip) your full repository (including all history and commits):

    svnadmin dump /path/to/repository | gzip > dump_file_name.svn.gz

    2) Copy the dump file to your new svn server:

    scp dump_file_name.svn.gz user@newserver:

    3) Create a new repository: on your new svn server, run the following command to create a new repository:

    svnadmin create /path/to/repository

    4) Import the dump file into the new repository:

    zcat dump_file_name.svn | svnadmin load /path/to/repository

    5) You then need to either re-create your working copies using “svn co” or you can use the switch command with –relocate:

    svn sw --relocate \ \

    Note that I broke the above command up over multiple lines for ease of reading but you can obviously ommit the \ if you put it all on a single line.

    Another interesting thing you can do with the dump command is just dump a single commit. The following command will just dump out the commit with revision number 100:

    svnadmin dump --incremental -r 100 /path/to/repository > dump_file_name.svn

    Categories: development Tags:

    Vagrant Install on Mac OS X

    February 20th, 2011 No comments

    Gareth Rushgrove recently wrote a good blog post about why you should be using virtualisation.

    (incidently, it got coverage on Hacker News and David Singleton also blogged a follow up).


    Vagrant is a tool for building and distributing virtualized development environments.

    To quote the Vagrant website:

    By providing automated creation and provisioning of virtual machines using Oracle’s VirtualBox, Vagrant provides the tools to create and configure lightweight, reproducible, and portable virtual environments.

    The installation instructions are simple:

    $ sudo gem update --system
    $ gem install vagrant

    However, there were a few small gotcha’s a came across which are worth sharing.

    Firstly, you need to run the vagrant install under sudo (runs it with root privileges), otherwise it complains about permissions:

    $ sudo gem install vagrant

    Secondly, I got the following error:

    $ sudo gem install vagrant
    Building native extensions. This could take a while...
    ERROR: Error installing vagrant:
    ERROR: Failed to build gem native extension.

    /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb
    mkmf.rb can't find header files for ruby at /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ruby.h

    Gem files will remain installed in /Library/Ruby/Gems/1.8/gems/json-1.5.1 for inspection.
    Results logged to /Library/Ruby/Gems/1.8/gems/json-1.5.1/ext/json/ext/generator/gem_make.out

    It turns out this is easy to solve – all you need to do is dig out your OS X install CD, go into the optional extras and install Xcode.

    It takes a while to run but once it’s complete, Vagrant installs fine.