How My Website Was Eaten By The Big Nothing

Those of you who follow me on Twitter will probably remember that around the time Scienceblogs shifted to a new format, I was busy doing a final piece of development on my old website, SciencePunk.com. I felt it had sat in stasis for too long, and I’d outgrown a lot of the views and content on there. I wanted to paint something fresh onto it, but that required a blank canvas. Rather than delete everything (which seemed like quite a blunt act), I thought it would be more fun to visualise the neglect that it was suffering.

So, with the help of  Steve Moss, I had a plugin that would gradually decay SciencePunk.com. I called it digital rust, and you can see the code for yourself here. The code is nestled in the footer of the website, and triggers every single time a page is loaded. When this happens, one blogpost is selected at random from the hundreds of entries, and ten per cent of the characters in the title and main copy are replaced by blank spaces. The only exception is that the page you are looking at will not be the one degraded. As such, it is the least-viewed pages that decay first, while the most-trafficked ones suffer the least. With remarkable speed, my website started to degrade.

Recently, I noticed that SciencePunk.com was failing to load. On further inspection, it seemed by decay code had gotten a little out of hand.

So what happened?  When the code is run, it counts how many characters appear in the text of the blog post and therefore how many need to be replaced to achieve a ten per cent decay rate. A post that has 1,000 characters will have 100 replaced by blank spaces.

However, there’s a problem: all the popular browsers automatically compress multiple spaces. To preserve the word structure and give the appearance of missing letters, non-breaking spaces are used in the digital rust plugin. The HTML code for a non-breaking space -   - is six characters long. So in the final output, those 100 blank spaces are rendered using 600 characters, and the blogpost is now an extra 500 characters long. The next time it is selected for decay, the 1,500 character long post has 150 characters selected for vaporisation, and they become 900, bumping the blog post up to 2,250 characters. And so on – and on, and on, until the website starts to crash because all the blogposts are gigantic strings of blank spaces.

Some posts seem to be hardly affected, while others are sinking under the weight of pseudo-blank canvas. This shouldn’t surprise us – the bug outlined above leads to an exponential rise in blog post length. The decay code is actually making my website longer. It’s an aggressive nothingness, a big bang that explosively increases space whilst wiping out the space that it’s in.  I've deactivated it for the moment to give myself a chance to debug the system.  Ultimately, it looks like the decay code needs to be degraded.