Consultant buzzwords Last updated:20 March 2010

Some builders propping up a collapsing building Consultant-speak buzzwords have been around for a while, of course, but the one that really gets up my nose is “underpinned”. Often used when announcing some new development or innovation, it is somehow (deemed) far more impressive to say that it’s underpinned by this, that or the other. I thought that was what you did to a building that’s in danger of falling down. What on earth’s wrong with “supported”?

Equally bad, the use of “architected” instead of “designed”. Particularly prevalent in software ITTs.

It’s not big, and it’s not certainly not clever…

Feel free to offer your own personal favourites.

Blackberrys, naval signalling and thinking for yourself Last updated:20 March 2010

Scott of the Antarctic - David Crane I’m reading this book about Scott’s expeditions to the Antarctic at the moment.

A bit of background information about the Royal Navy particularly interested me. It talks about communication between naval vessels in action. In Nelson’s time in the early 1800s it was very difficult, with the result that each captain had to rely on his own judgement and initiative. By the mid to late 1800s, however, improvements in naval signalling meant that captains relied far more heavily on orders from superior officers, with the result that initiative and individual thought was largely stifled, and the quality of naval leadership suffered badly as a result.

It struck me that there are parallels with today’s “always in touch” culture via mobile phones, emails, Blackberrys and the like, all of which discourage people from using their initiative and making a decision, because there’s always someone else to refer the decision upwards.

Maybe one day a week should be declared “trust your own judgement” day…

Loading a webpage in stages Last updated:1 March 2010

I reworked my homepage this weekend and wanted to display the latest Wordpress blog post on it. No problem there. However, the initial response times for my blog are sometimes quite slow, and this then meant that the whole of my homepage was slow to display, because the page was waiting for the blog to respond before displaying anything.

So what I wanted to do was display the home page immediately, and then load the blog post when it’s available. The solution was to use AJAX, which turned out to be very straightforward. More information on AJAX here, but essentially it allows a page to communicate with a server without refreshing the whole page. First things first – here’s the php code to retrieve the latest post from Wordpress as follows (I originally had this on the homepage itself):

<?php require($_SERVER['DOCUMENT_ROOT']."/blog/wp-blog-header.php");
query_posts('showposts=1');
while (have_posts()): the_post();?> 
<h2><a href="<?php the_permalink(); ?>" title="Blog">
Latest blog: <?php the_title(); ?></a></h2>
<?php the_excerpt(); ?>
<?php endwhile;?>

I saved this code separately into a file called latest_post.php (stored in my “includes” folder).

In my homepage file I added some “placeholder” code where I want the blog post to appear. This will be displayed until the data comes back from Wordpress:

<div id="latest_post">
<h2>Latest blog: loading...</h2>
</div>

Note the id of latest_post assigned to the div. Then I added the following javascript code to the <head> section of the homepage

<script type="text/javascript">
window.onload = new Function("loadXMLDoc('/includes/latest_post.php');");
function loadXMLDoc(url)
  {
  if (window.XMLHttpRequest)
  {// code for IE7+, Firefox, Chrome, Opera, Safari
  xmlhttp=new XMLHttpRequest();
  }
  else
  {// code for IE6, IE5
  xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
  }
  xmlhttp.open("GET",url,false);
  xmlhttp.send(null);
  document.getElementById('latest_post').innerHTML=xmlhttp.responseText;
  }
</script>

The function loadXMLDoc retrieves the php file I’ve created above (latest_post.php) and then the last line replaces the text within the element with id “latest_post” with whatever is retrieved. This is standard ajax code which can be used for any purpose. Only the last line is specific to my page.

The code window.onload... calls this function when the page is loaded.

So, when the page is requested the php and html that’s on the page display the page with the placeholder text, but without the blog post, so the page loads nice and quickly. Once the page loads, the javascript is fired which calls the AJAX function to retrieve the blog post, and this loads on the page when it’s available.

This was the first time I’ve used AJAX, and it seemed quite a neat little solution, so I thought I’d post it here. This is the basic solution which could be further enhanced with some error handling.

Stop Wordpress adding <br/> tags Last updated:6 February 2010

Been swearing at Wordpress this afternoon…

I’ve been trying to transfer an html form, which I had working perfectly on a static html page, onto a Wordpress page. Wordpress insisted on adding multiple <br/> tags where I didn’t want them. Mutter.

Eventually, after much searching, I identified a parameter within wp-includes/formatting.php, which allows you to disable this irritating feature. If you open formatting.php and find the function wpautop you’ll see this:

function wpautop($pee, $br = 1)

Change this to:

function wpautop($pee, $br = 0)

Save the file and publish it back to your server and that’s it. Works fine in WP2.8.

Note: WP 2.8.3 overwrites formatting.php so this change needs redoing.

The lifespan of IE6 Last updated:18 January 2010

Read an interesting article this morning about the use of Internet Explorer. Specifically, the article suggests that now that IE8 is launched, users will migrate from IE7, but many who are still using IE6 will remain, to the point that IE6 will become more popular than IE7. Sound mad? Not really, because many corporate web applications were designed for IE6 when it was effectively the only browser available, and they won’t work with IE7. Larger companies tend to be intrinsically risk-averse anyway, upgrading a browser is low priority – my own experience certainly supports the argument.

A couple of sets of web stats highlight the issue. Looking at some stats from a large public sector website, 80% of visitors are using IE, of which 40% use IE6. This website will be frequently accessed by people at work. By contrast, one of the sites I run, which tends towards consumer usage, has only 60% IE users, of which only 15% use IE6.

So the bad news is IE6 may live a lot longer than we might like…