Iterate and improve

I think I tend to have this picture in my head that “master programmers” just get it “right” on the first pass. It’s incredibly comforting to know that being a great programmer is not about never making mistakes; rather, it’s about knowing how to continually iterate and improve on a solution.

– Ben Nadel reviews “Clean Code: A Handbook of Agile Software Craftmanship” by Robert C. Martin (a.k.a. “Uncle Bob”)



Adobe unveils Brackets, “A free, open-source code editor for the Web”

Adobe Brackets LogoAdobe today announced the general availability of Brackets, a lightweight, “free, open-source code editor for the Web”. Built entirely with HTML, Javascript and CSS (though currently running in a OS-specific wrapper rather than the browser) this is a very early release. In the few hours I’ve been using it, it has been generally stable on both Windows and Mac though it still suffers from lack of features and sluggish performance. Despite this it’s certainly usable and gives a good indication of where Adobe are heading with this app. Two of the features that are included are worthy of note, incomplete though they are:

  • Inline editing
    Also called “the quick editor”, this is definitely an innovation worth having. With this feature we can place the cursor over, say, a body tag and click Cmd/Ctrl-E and a small inline editor overlays pops up showing all of the css rules that apply to that tag, even though they may be defined in multiple, external files. Better yet, we can edit them in place and save them back to their original files, all without leaving our main editor window.
    This feature already works pretty well (it can be a little slow to open) – I’d really like to see it appear in other editors (Sublime Text, for example).
  • Live Development
    Live Deveopment  allows you to make changes in the editor and instantly see them applied in the browser, without having to refresh the page. If you work with two monitors or a large screen this can be a very productive way to develop. Mac developers may already be familiar with this kind of syncing from apps such as the excellent Live Reload though this is the first time I have seen it built directly into the editor.
    Unfortunately, I couldn’t get this to work reliably using Chrome 20 beta on OSX Lion… changes would sync and appear in the browser, only to be followed by an error message and a prompt to reload Chrome.
Both of these features are shown in the following video from Adobe:


Adobe are keen to emphasise that this is a very early, unfinished, pre-release version of Brackets with many missing features and a long way to go before it matches the polish or performance of other code editors such as Sublime Text. Despite that, it’s an ambitious project and has the potential to really deliver something fresh and innovative. I’d recommend that you get a copy and give it a try for a few days and, if you have any HTML, CSS or Javascript skills, have a look at the source code that comes with the download and consider making a contribution to help make it even better.



The easy way to E.U. “cookie law” compliance

In May, 2012 a new e-Privacy Directive (adopted in 2009) became law throughout the European Union. Know colloquially as the “EU cookie law” (though it also regulates Flash ‘cookies’ and HTML Local Storage) this sets out rules about when and, to a lesser extent, how a website visitor must be asked for permission before a cookie is set in their browser. Unfortunately, despite having years to plan and implement the new regulations, their introduction has been botched. With each member state left to interpret the rules as they see fit, the result is a hodgepodge of laws, guidelines and contradictory advice which neither meets the needs of webmasters or the users of their site. The end result has been that, so far, many companies appear to have decided that ignoring the law is the best and/or cheapest option, despite the fact that failure to adhere to the regulations  can result in a hefty fine – in the U.K. the Information Commissioner’s Office (ICO) have the ability to impose a penalty of up to £500,000 for non-compliance.

Should you decide that you do actually want to comply with the law, you’ll find that it doesn’t have to be difficult or time-consuming. There are plenty of ready-made solutions,  my own favourite being Cookie Control from Civic UK. This free, jQuery based library provides a clean, unobtrusive and attractive way to notify the user of what exactly you are planning to use cookies for and, optionally, to gain their permission. It provides a comprehensive selection of display options to suit your usage patterns and built-in support for geolocation using the geoPlugin service so that you can target only those with EU-based IP addresses. I particularly like the triangle icon option that sits in the bottom left hand corner of the screen – as Civic develop for many U.K. government agencies, it’s likely we will see it becoming a commonplace and recognisable icon that immediately alerts site visitors to cookie policy.

With it’s online configuration tool, it takes next to no time to integrate into your site(s) – depending on how many cookies your site is setting it will most likely take you less time to implement that it took me to write this blog post.

The Cookie Control configuration interface


The Civic UK site provides comprehensive instructions for deployment of Cookie Control and while this is a job for a developer, it’s no more difficult than implementing any other jQuery-based library or plugin. The only feature I would like to see added to the Civic site is some links to the library in action. For now though, you can find a minimal version of it on their own site at and a more comprehensive implementation at this public library site –

Bonus: it was developed in Scotland.


Javascript: Accurate timing is (almost) here

If you’ve ever tried to optimize or locate a bottleneck in your Javascript code you’ve most likely ended up using Date().getTime(). As this function returns the number of milliseconds since the 1st of January, 1970 we can easily determine the total run time of the code we wish to test by taking two readings, one immediately prior to the code to be tested and and one immediately after. A simple subtraction will then give us the total run time in milliseconds:

var start, end;

start = (new Date()).getTime();

// Run a test

end = (new Date()).getTime();

alert(end - start);

While this is easy to use and consistently implemented across browsers it has a three flaws that make it less than ideal for benchmarking – the value returned is an integer so it’s useless for timing anything that takes less than a millisecond, it’s derived from the system clock which may be unstable or subject to adjustment and, depending on the operating system and browser, can be significantly wrong.

With the recent release of Google Chrome 20 to beta we now have the opportunity to use a new, more reliable and more precise timer – High Resolution Time a.k.a. More specifically, we can use the Chrome, vendor-prefixed, version – performance.webkitNow.

As performance.webkitNow returns the number of milliseconds since the navigationStart of the page and is not tied to the system clock we get more reliable timings. Better still, it returns the elapsed time as a double with microseconds in the fractional part, allowing us to have more accurate, sub-millisecond, timings.

If we rewrite the previous example to use High Resolution Time instead of Date().getTime() our code would be:

var start, end;

start = window.performance.webkitNow();

// Run a test

end = window.performance.webkitNow();

alert(end - start);

Running this example would give us results such as 0.005999987479299307 whereas our original, Date-based, example consistently returned zero.

Of course, it’s never so simple. This will work fine in Chrome 20 Beta but will error in all other browsers (and earlier versions of Chrome). To allow for other, as yet to be released, vendor-prefixed versions and to be usable today we must create a small shim function:

 var now = (function() {

// Returns the number of milliseconds elapsed since either the browser navigationStart event or
// the UNIX epoch, depending on availability.
// Where the browser supports 'performance' we use that as it is more accurate (microsoeconds
// will be returned in the fractional part) and more reliable as it does not rely on the system time.
// Where 'performance' is not available, we will fall back to Date().getTime().

var performance = window.performance || {}; = (function() {
return    ||
performance.webkitNow     ||
performance.msNow         ||
performance.oNow          ||
performance.mozNow        ||
function() { return new Date().getTime(); };



This will use the “official”, if it is available. If not it will try each of the vendor prefixes, then ultimately fall back to Date().getTime(), allowing for all eventualities now or in the near future. Using this function is no more difficult that our previous examples:

var start, end;

start = now();

// Run a test

end = now();

alert(end - start);


You can try out this function on jsFiddle or grab it from Gist or Snipplr.



“Don’t be a semi-colon”

I missed it at the time but this blog post by Christian Heilmann is really the only thing worth reading with regard to the whole Twitter Bootstrap “wilfully screwed up code” debacle.

The reason why our parsers are so lenient is that the web is already filled up to the brim with horrible code and we don’t want to break backwards compatibility. It is not a carte blanche to write more sloppy code. We’ve done that, we should not write more code faster but cleaner code and re-use it more often.

— Christian Heilmann


Note to self: MultiMarkdown style within-document links are not supported in GitHub markdown

MultiMarkdown (MMD) lets us very simply add within-document links (also known as cross-links or cross-references).

Where a heading is defined in a page, like so:

### The Heading

all that we need to do to link to that heading from elsewhere in the same page is to include:

[The Heading][]

This makes it very easy and very quick to, for example, add a table of contents to an existing document – there’s also no need to add extra markup to the linked to heading (in this case) which simplifies and streamlines our document.

This syntax is available in most, if not all, editors that support MultiMarkdown, including my favourite Byword. The important phrase here is “that support MultiMarkdown” – this is not a feature of regular Markdown. Unfortunately, the Markdown supported by GitHub, GitHub Flavored Markdown (GFM), is a variation of regular MarkDown not MMD so, to include within-document links we have to revert to an ugly kludge. Firstly we have to precede the heading we want to link to with a HTML anchor tag:

<a name="headinglink">
### The Heading

and then link to it:

[Click this text to return to the heading](#headinglink)

This works because Markdown allows HTML to be embedded within a Markdown document. As MultiMarkdown is a superset of Markdown, it also supports this syntax as well as the newer style so this should be an acceptable, if ugly, solution in all cases. Note also that, unlike regular HTML, the heading being linked to must be on a separate line from the anchor tag. If you place them on the same line GitHub won’t render the heading properly.

Thankfully, GitHub makes it very easy for us to write and test our Markdown before committing it by providing three very useful resources:

  • Pressing the ‘m’ key while on pops up a Markdown cheat sheet showing the supported syntax
  • GitHub Flavored Markdown describes in more detail the options supported by GitHub and the differences between them and regular Markdown
  • The GFM Live Preview is a web page that allows us to enter some Markdown and instantly see how GitHub will interpret it.

jList: Version 1.3.0 adds three new functions

Today I pushed version 1.3.0 of jList to GitHub. This version of the library, which brings ColdFusion-style list handling to Javascript, adds three new functions, bringing the total to twenty:

  • listChangeDelims
    Changes a list delimiter.
  • listValueCount
    Counts the instances of a specified value in a list. The search is case-sensitive.
  • listValueCountNoCase
    Counts the instances of a specified value in a list. The search is not case-sensitive.

All documentation is updated so full details of the new functionality is on the jList GitHub page.

The three new functions have also been added to jsFiddle should you wish to try them out – listChangeDelims, listValueCount, listValueCountNoCase.