Remember the power of social media is not in broadcasting, it’s about relationship building.

…which to me means Don’t see Twitter as an advert on the radio, see it as a networking event. If you do that, you start to realise not only how to use social media in your business but also who needs to be involved. The who as well as the what is one of the keys to a successful strategy.

One thing that’s traditionally been difficult to explain or understand though, and remains that way, is the question of ‘why to refactor’. Putting work into something without changing what it does can seem like it’s going to be a big load of wasted effort. At best, it often looks like a speculative investment of time with intangible payback. Experience shows though that refactoring can pay big dividends, avoid wasted effort and create consistent direction, focus and efficiency on a project.

Martin Fowler writes that refactoring makes changing software easier in the future. That’s very true but to those new to the concept (or non-programmers) it can still be difficult to explain how that happens. It sounds a little bit ‘magic’.

For me it simply comes down to this though. Writing code isn’t only about solving a problem. It’s also about describing the solution. Really great code not only functions well but explains to other programmers what the problem was that caused the code to be written and how it was solved. That’s where the ease of change comes in. In contrast, if code is incomprehensible, often the reasons behind it aren’t fully understood when changes are needed. That tends to encourage either starting again (wasted effort), large amounts of careful tracing through the code, or unintentional breaking of parts of the system when changes are made without fully understanding their impact.

Of course, you can write comments and supplementary documentation around code and they both have their place. Documentation can easily get out of step with code without extreme care though and it’s difficult to test completeness or accuracy of the written word. Well written code doesn’t have that problem. The documentation can’t get out of step with the implementation because the implementation is the documentation.

Of course, pragmatism and business forces do count in the real world and sometimes refactoring isn’t justified, for instance on a soon to retire system. Often though, taking working code and making changes which help to teach the current and future teams about the nature of the problem it solves is well worth the effort. And just like other forms of documentation, refactoring is worth doing before the original learning and knowledge gained by the very process of creating the solution is lost and has to be re-learnt all over again. Used wisely, refactoring’s a valuable investment in team knowledge and ongoing clarity of thinking.

Since the new like button functionality automatically tries to include an image, I found it particularly useful when used in conjunction with the og:image metadata from facebook’s open graph protocol. Using og:image allows you to specify a thumbnail to include in the story and avoids the situation where a random and sometimes inappropriate image is chosen for you.

Implementing both the like button and the open graph metadata are straightforward jobs and there’s a simple guide in the Facebook Like Button documentation.

Looking round the office I’m in at the moment, there are:

• 2 x Apple Macs running Mac OSX 10.6
• 2 x Windows 7
• 1 x Windows XP
• 2 x Ubuntu Linux
• 2 x Blackberries
• 2 x Android phones
• 1 x iPhone

That diversity would have been really unusual, even 5 years ago but it’s getting more and more common. I think that’s a good thing for end users.

I regularly get asked if one OS is better than another and while I’m happy to advise and don’t tend to sit on the fence, the only honest answer I can give is that they all have different strengths and weakness. Knowing what those are and making an informed choice can sometimes bring big productivity benefits. It’s about gaining awareness of options available and using the best tool for the job and I think more an more people are become aware of those choices.

Of course to make that choice, we need to be not tied to just one operating system in the first place and that’s where cross platform software really helps. As a simple example, I recently helped a couple of users who’d decided to move to Macs (one from Windows Vista and one from a Linux desktop) and wanted to move their mail. Fortunately, both were using a cross-platform email client (in this case Mozilla Thunderbird) and a quick copy of a few files meant they were set up in seconds, with mail settings, passwords, email and inbox totally in tact as if nothing had changed.

I do understand though why some folks think that restricting choice makes the world a simpler place and that’s true to an extent, just as only allowing one brand of beer to be sold would make choices simpler on a night out or only building one type of car might make third party spare parts cheaper. But the reality is, different products suit different people and situations. In the software world, cross platform applications have a big part to play in supporting that choice and the productivity benefits that can follow. At the moment I increasingly bump into situations that suggest to me that everyday technology users are realising those benefits and factoring them into their decisions.

Included in the first batch of these changes is a new facility to allow training providers to add early booking discounts in addition to the current last minute training deals. The last minute discounts option has been very popular, with some great deals appearing on courses such as ITIL, Access, Adobe Photoshop and Prince2. Feedback so far suggests the new early booking discount feature will be just as popular and creates even more opportunities for training providers to fill courses and for students to find a bargain.

Ubuntu 10.10 in operation with the cairo dock

Ubuntu has long been one of the easier Linux distributions for the desktop user to get up and running with and the Ubuntu team really have made the setup process as easy as possible. Once you’re up and running, the debian package management for installing additional software is excellent too and the out of the box look and feel is clean and intuitive.

If you’re interested in giving this latest Ubuntu release a try yourself, take a look at the Ubuntu web site.

Fortunately Java Enterprise Edition provides an easy mechanism for intercepting every request on the way in and out of the application in the form of a Servlet filter and it’s really simple to use that to create a performance logger. The basic concept here is to capture the time as a request enters an application, then again as it leaves and log the difference between the two. We can do this in the servlet filter’s doFilter method as follows. I’m using a log4j logger to handle the output but obviously any other logging mechanism would work just as well if you prefer something else:

    long startTime;
    long endTime;
    String path = ((HttpServletRequest) request).getServletPath();

    startTime = System.currentTimeMillis();
    chain.doFilter(request, response);
    endTime = System.currentTimeMillis();

    //Log the servlet path and time taken
    perfLogger.info(path + "," + (endTime - startTime) );

To finish off the code, I’ve added a couple of configuration options for more flexibility. For starters, I prefer to have a little more control over which URLs get logged than the standard servlet url-pattern mechanism allows. For instance, I may want to only log requests containing the word ’search’ anywhere in the path. The standard servlet url-pattern mechanism doesn’t allow this so I’ve added a parameter ‘url-filter’ to allow full regular expression matching. A second parameter ‘log-category’ sets the log4j logging category to use. Wrapping this into a full example servlet filter we get:

package com.actuanceconsulting.perflog;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;

import org.apache.log4j.Logger;

/**
 * A simple filter to log the time taken to execute a request. Logging is carried
 * out via log4j to give the flexibility to add other data (such as current time)
 * and format the log as required.
 * */

 /*
 * Copyright John Patrick, Actuance Consulting Limited 2010
 * http://www.actuanceconsulting.com
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Lesser General Public License as published
 * by the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU Lesser General Public License for more details.
 *
 * For a copy of the GNU Lesser General Public License,
 * see <http://www.gnu.org/licenses/>.
 */
public class PerformanceLogFilter implements Filter {

 /**
 * An optional regular expression to use as a filter for the servlet patch.
 * Gives more flexibility than the standard servlet url-filter.
 * All requests are logged if not specified.
 * */
 private static final String URL_FILTER_PARAM = "url-filter";

 /**
 * An optional log4j category to use. The fully qualified class name
 * of the filter will be used if not specified.
 */
 private static final String LOG_CATEGORY_PARAM = "log-category"; 

 private Logger perfLogger;
 private String urlFilter;

 public void init(FilterConfig config) throws ServletException {
    String logCategory = config.getInitParameter(LOG_CATEGORY_PARAM);
    if (logCategory == null) {
       this.getClass().getName();
    }
    perfLogger = Logger.getLogger(logCategory);
    urlFilter = config.getInitParameter(URL_FILTER_PARAM);
 }

 public void doFilter(ServletRequest request, ServletResponse response,
 FilterChain chain) throws IOException, ServletException {

    long startTime;
    long endTime;
    String path = ((HttpServletRequest) request).getServletPath();

    if (urlFilter == null || path.matches(urlFilter)) {
       startTime = System.currentTimeMillis();
       chain.doFilter(request, response);
       endTime = System.currentTimeMillis();

       //Log the servlet path and time taken
       perfLogger.info(path + "," + (endTime - startTime) );
    }
    else {
       chain.doFilter(request, response);            
    }
 }

 public void destroy() {
    //Nothing to see here        
 }

}

To get the filter to run, we need to configure it in the web.xml file as follows:

<filter>
  <filter-name>performance</filter-name>
  <filter-class>com.actuanceconsulting.perflog.PerformanceLogFilter</filter-class>
  <init-param>
    <param-name>url-filter</param-name>
    <param-value>.*search.*</param-value>
  </init-param>
  <init-param>
    <param-name>log-category</param-name>
    <param-value>perflog</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>performance</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

In this case I’ve set my regular expression for the ‘url-filter’ parameter to only match paths containing ’search’. For completeness, here’s the log4j config I used too…

<appender name="PerformanceFileAppender">
  <param name="Threshold" value="DEBUG"/>    
  <param name="File" value="../logs/performance.log"/>
  <param name="Append" value="true"/>
  <layout>
    <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss},%m%n"/>
  </layout>
</appender>

<category name="perflog">
  <priority value="INFO"/>        
  <appender-ref ref="PerformanceFileAppender"/>                
</category>

…and that produces output as shown below. The CSV format of this output allows for easy analysis of the results but obviously you can choose whatever format suits you best.

2010-06-19 11:26:20,/search,81
2010-06-19 11:26:25,/advanced-search-input,66
2010-06-19 11:26:30,/advanced-search,62
2010-06-19 11:26:39,/search,56
2010-06-19 11:26:43,/search,38
2010-06-19 11:26:43,/search,39

And that’s all there is to it. It’s a simple bit of code but it can really add value when run over a period of live operation. Being able to see historical performance and spot trends can be a powerful diagnostic tool.

As a simple example, a search containing the word ‘free’ such as ‘free training’ clearly means to us humans that we want to see a price of zero, so matching ‘free climbing’ and ignoring £0 in the results clearly seems completely mental to the average user. The fix is pretty simple though. By enriching our search index with extra ‘implied’ data (like including the word ‘free’ when the price is zero) and choosing careful weightings for this data, the results quickly become far less ‘dumb’ and even at times appear surprisingly human. Obviously not always 100% perfect, but definitely better.

Automating our understanding of phrases (rather than simply isolated words) fascinates me too. I did a search today on a stock photo library for ‘Mac keyboard and mouse’. The intent of that search is clear enough to us humans but the starkly Turing-failing response was “By ‘Mac’ do you mean Apple Macintosh or Waterproof Clothing; By ‘keyboard’ do you mean computer input device, synthesizer or piano; By ‘mouse’ do you mean rodent or computer mouse?” Er, yes, I want a picture of a small rodent in a raincoat playing piano please.

That challenge for clarification is a reasonable enough question for a machine to ask but us humans know that when ‘keyboard and mouse’ are mentioned together in the same phrase, we’re pretty certain it doesn’t mean a piano-playing rodent. An what’s more, when keyboard and mouse are mentioned together with ‘Mac’, we know we’re not going to be wearing the mac.

What really fascinates me about all this isn’t really the deep, deep theory of it all (I’m a pragmatist at heart), but simply that a recognition and awareness of the weaknesses of ‘pure’ computer logic when we’re designing computer interfaces can quickly lead to huge steps forward in the usability of a system. By putting some thought into covering predictable and reasonable human expectations in a user interface, it’s relatively easy to avoid forcing your users to think like a computer, and even create a surprisingly positive experience.

From a personal perspective, what is often surprising when I start down this line of thinking, is that relatively little changes and increases in effort can bring big usability results. Even attempting (and inevitably failing) to make your user interface pass the Turing test still gives some real advantages to your users.