Posts Tagged ‘web’

JavaScript: The Good Parts

Friday, February 20th, 2015 | Books

I’ve read Douglas Crockford’s book on JavaScript several time before, but it is always goof to have a refresher. It’s super-helpful and so short that you can easily get through it in a day if you try. I think the appendices are actually bigger than the text.


3 technical challenges we just cannot get right

Saturday, August 3rd, 2013 | Limited, Programming

Having worked on a lot of different projects at a lot of different companies over the years, there are some issues that recur time after time. These are problems that maybe we just don’t have satisfactory patterns for, or developers have a blind spot for. But whatever the reason, they certainly merit more attention in order to reduce how frequently they arise.

Below, I’ve listed three with some suggestions as to how to help mitigate them.


Caching is essential to good performance in most applications. Remember your ABC – Always Be Caching. Indeed, if you ever want to sound clever in a discussion about system architecture, say “have you thought about caching that?”. Caching is the solution to almost everything. But causes some problems too.

For the non-technical, caching is storing information in short term memory so it can be delivered faster. It’s like remembering things. You probably have a big pile of books at home, and you can’t remember most of them, so for most facts you have to look them up in a book. But you can remember a few things, so for the questions you get asked most, you memorise the facts so you can say them quicker. That’s basically what caching is.

The problem is that when you update something, the cache can end up serving the old content, rather than the new. This results in data being out of date and often results in web applications not appearing correctly because the HTML has updated, but the CSS and JavaScript happens.

Here are a few tips to help mitigate such problems:

  • Have scripts to clear out your various caches. Make sure you know what/where the cache layers are.
  • Understand what cache headers you are serving via you sending via your web server.
  • Have a mechanism for changing files such as stylesheets and JavaScript when you release a new version.
  • Turning caching off on dev environments is fine, but make sure you have it turned on on your staging/pre-production environment so you can spot potential problems.


While Britain insisted that time starts and stops in Greenwich, we did allow the rest of the world to make adjustments at hourly (or even half-hourly) intervals based on where they are in the world. This has caused no end of headaches for software developers. Even within one country, one problem that comes up time after time is that systems go wrong when the clocks are changed for daylight savings.

Every six months it all goes wrong every six months and we promise to fix it by the next time the clocks change, but usually never do. Even Apple got it wrong on their iPhone alarm – twice!

Here are a few tips to help mitigate such problems:

  • Set your servers to GMT/UTC and leave them there, regardless of where you are in the world and where DST is in effect or not.
  • Use prper DateTime objects, and specify the timezone.
  • When sending a DateTime string, use an ISO standard and be explicit as to what TimeZone it is in.
  • Unit test DST changes, using a mock system time if required.
  • Perform manual testing on the DST switch.

Load balancing

As systems scale, they inevitably need to spread across multiple processes, applications and bits of hardware. This brings a whole new layer of complexity, though, having to keep everything in sync. It’s very easy to lose consistency and that almost always ends in one thing – say it with me everyone, “race conditions”!

There are two common problems we find in this situation. The first is that one node stops working but the other one is working fine, or maybe something as simple as one node having old code on it. You get intermittent problems but when you try it it works fine or at least works fine 50% of the time. It could be that it is hitting the working node but at other times is hitting the other.

Here are a few tips to help mitigate such problems:

  • Ensure you can (and ideally do automatically) test individual nodes.
  • Use a tool like Chef or Puppet to make sure all your nodes are consistent.
  • Have the ability to easily take out nodes that are not working.
  • Aggregate your logging where possible so you don’t have to tail them on each individual node.

The second is race conditions. This is particularly prevalent when using a master and slave database setup. You will write the update to the master than query for it the results – but because your second query is a read, it will be passed to the slave, which may nor may not have updated yet with the new information.

Here are a few tips to help mitigate such problems:

  • Have the ability to manually specify master or slave so time critical reads can be pointed at the master.
  • Ensuring your staging/pre-production environment load balances everywhere your production environment does so you can spot potential issues.
  • Where possible, rely on one server for the time as different machines can become slightly out of sync.

CSS properties worth remembering

Tuesday, June 4th, 2013 | Limited, Programming

A lot has changed since I wrote my first line of CSS – which is probably going on a decade ago now. Other things have been there all along, but have sometimes been overlooked or neglected. Below is a collection of CSS that it is easy to forget exists.


Obviously you can use . # * etc, but there are actually far more options. As well as chaining them (p, div) and specifying them being inside each other (p div) you can also specify they must be the parent (p > div) or immediately after one another (p+div).

As well as checking attributes (input[type=text]) you can also do contains (input[title~=something]) and starting with (input[type|=something]).

We’re probably all familiar with :visited and :hover states, but there are actually dozens you can use – :focus, :first-letter, :first-line, :first-of-type, :last-of-type, :only-child, :empty, :enabled and “checked just to name a few.

Sizing in rem

It’s good practice to use em sizing to make everything relative – that way if a user scales up the page then everything stays in proportion (though modern browsers tend to handle this well anyway). But isn’t it annoying that it stacks? A 2em value inside a 2em value will give you a font size of 4.

You can solve this by using rem. Specifying 2rem will make it 2 x the root (html) element of the document – so you can make it all relevant to that and not worry about nesting.


You can add gradients as backgrounds and even create complex patterns with multiple colours starting and stopping at different points.

background-image: linear-gradient(bottom, #22E7D2 12%, #3EFFFC 56%, #2FAB24 100%);


It’s simple to add a drop shadow to an element.

box-shadow: 10px 10px 5px #888;

You can add it to text as well.

text-shadow: 2px 2px #ff0000;

Box sizing

Tired of having to work out what width you want something to be, then taking off the padding and the border? Sometimes maybe you don’t even have the option to do that because you want it to be 100% wide. Box sizing to the rescue. Set the box sizing to border and it will calculate the width factoring these properties in.

box-sizing: border-box;

Border radius

Want some nice rounded corners? Easy.

border-radius: 5px;
border-top-left-radius: 3px;
border-bottom-right-radius: 10px;


You probably shouldn’t clip as it means you’re sending an image to the browser that is too big and then cutting it down. However, the functionality to do it does exist within CSS>


There is a background-clip property too.


Want to present your text in a series of columns? Theres a property for that.

column-count: 3;
column-gap: 5px;

Life at the BBC

Sunday, October 14th, 2012 | Tech, Thoughts

Having heard another talk about the BBC’s technology side on Sunday, I’ve come to the conclusion that it must be a pretty awesome place to work.

While they don’t perhaps have the funds that private sector organisations do, I guess I assumed that being a public institution that would be large and lumbering, risk adverse and slow to react.

Nothing could be further from the truth.

For example, they use Scrum. Scrum is an agile methodology used for developing software in the real world (ie, a world where the client is always changing their mind). But they don’t just use it for software – they use it for managing projects right across the business.

Secondly, they’re really up on technology. The speaker on Sunday was telling me about how they had developed an open source project for parsing Gherkin – a lot of software developers might not even know what Gherkin is!

They’ve also previously developed their own JavaScript library, which was a contender alongside jQuery and Prototype (you know, before everyone accepted jQuery was the best, but then everyone realised you could actually just use selectors and not load any library at all).

Not to mention the pioneering work with iPlayer. They launched iPlayer in 2007 – that is five years ago! I can’t really remember a time before iPlayer now, but I don’t think there was many other people doing it at the time. Not to mention that they also have iOS and Android apps available for it too.

In reality, the BBC is no lumbering institution at all – it’s an fast moving, agile, technology-savvy organisation that must be amazing to work at.