1. Next Stop, Tokyo

    August 14, 2009

    A massive change in my life that I have been preparing for for some time is drawing very close - today is my last day in charge of the technical team at Outside Line. I've been Technical Lead at Outside Line for over two years, and have been fortunate to work with some of the most talented and creative designers and developers you are ever likely to meet - we've put together some brilliant websites in that time, and I am really proud of the work I've been a part of.

    Next week my girlfriend and I will be fulfilling an ambition that we've had for close to two years by packing our bags and moving to Tokyo, Japan. After visiting the country in 2008 and falling in love with the sights, sounds and smells, we have both been desperate to spend more time in the country. I will be taking up the role of UX Engineer with Cirius, where I will be helping to develop and extend their products in the international market. I'm really looking forward to working with some very talented people in a fresh, agile environment, and all within a city as vibrant and exciting as Tokyo. See you all on the other side.

  2. Extending Codeigniter for REST

    August 4, 2009

    I've recently been developing a little something in CodeIgniter that features an API that is as true as possible to the principles of REST. In order to do this, I had to extend the core CodeIgniter Input library to allow access to properly escaped values from DELETE or PUT input in the same way as you would normally access GET/POST input.

      function delete($index = '', $xss_clean = FALSE) {
        if (strtoupper($this->server('REQUEST_METHOD')) != 'DELETE') {
          return FALSE;
        parse_str(file_get_contents&#40;"php://input"&#41;, $_DELETE);
        return $this->_fetch_from_array($_DELETE, $index, $xss_clean);

    The code is pretty simple, and unfortunately does require file_get_contents until I can figure out an alternative way of accessing the input. The whole class can be downloaded, played with and forked from my GitHub account.

  3. Accessing Flickr & HostIp.info with PHP

    July 31, 2009

    Recently, we at Outside Line launched a new website for Golden Wonder's new noodle brand, The Nations Best. In a departure from the normal day-to-day, I built the bespoke server-side functionality to power the nifty Flash front-end. In doing so, I put together a few PHP libraries, one to access the Flickr API and one to access the Host IP geolocation service API.

      $images = $this->flickr->get('flickr.photos.search', array(
        'per_page' => '50',
        ’sort' => 'relevance',
        'text' => 'Exmouth Market',

    Both classes, being built at the same time, have a similar structure and similar functionality. They both feature a cache mechanism to limit your requests and enhance performance, and the both are pretty open ended in what they allow you to do. The Flickr class allows access to any method that doesn't require authentication, and returns the results as a PHP array, (in the same format as the original Flickr response).

      $latlong = $this->hostip->getLatLong('');
      $location = $this->hostip->getLocation'');

    The Host IP class is slightly more limited, but is easy to extend if more information is required. The results are obtained form a parsed XML response, and contain information outside of the latitude, longitude, city and country. Because of the way in which SimpleXML handles the name spaces, there is also bit of hacking in place to parse the XML.

    You can download the Flickr and Host IP classes from my GitHub account, and they are both offered freely but with no support or guarantee.

  4. Detecting visited sites with jQuery

    May 6, 2009

    My recent adventure in writing a jQuery plugin led to me considering what other notionally unattainable client-side information could be gathered using a bit of Javascript and CSS manipulation. A bit of playing, (and a lot of understanding Safari's rather greedy method of storing styles) has resulted in my second jQuery plugin in as many months.

    With the same disclaimers about elegance and infallibility, this plugin allows you to test a user's browser history against specific URL, returning a true/false value if they have visited the site in question.

    if ($.history.test('http://www.flickrshow.com')) {
      alert('You tasteful bugger.');

    Much like my previous effort, this plugin works by creating an HTML element, in this case an <a> tag, and some associated CSS properties to alter the element in a measurable way. In this case, by adding some very specific styles to the :visited property of the link that can be measured in a fairly precise manner if the link has been visited in the past.

    This isn't a bulletproof solution, however. You can only blindly test against the browser history, so need to make educated guesses and allow for changes in a URL, (such as trailing slashes or additional query string parameters). I've found that testing for one or two minor variations gives the best result – I might even add some minor intelligence to the function to account for this.

    As before, the plug-in is of beta quality but seems to work in Safari 3, Firefox 3+, and IE 6+. I've bundled everything together into a GitHub repository, where you can also download version 1.0 of the plug-in in uncompressed and compressed form.

  5. Exploding the myths of web design: Only use web fonts

    April 29, 2009

    This is a reproduction of a boxout written for the ‘Exploding the myths of web design’ feature in .Net magazine, issue 189.

    Have you ever been handed a design for a website and wondered what font the designer has used for the body copy? Because I can honestly say I never have, and this certainly isn't down to web designers having a love for Georgia and Arial. Instead, it's down to a common misconception that the only fonts that can be rendered in a browser are the old 'favourites'. The thing is, a modern web browser is perfectly capable of rendering any font that a user has installed, and because of the popularity of particular software packages, the list of relatively commonplace fonts includes some beauties.

    On 24 Ways, Richard Rutter showed that if you take into account fonts installed by Windows and Mac OS X along with those from Microsoft Office and Adobe's Creative Suite, the resulting list includes some rather lovely serif and san-serif fonts that a designer can use to bolster their designs. With some carefully selected fall-backs, there's no reason why a good developer can't provide users with Caslon or Jenson in place of Georgia, or Helvetica Neue in place of Arial. By using the CSS font-weight property, you can even use differing weights to further enhance your work.

    Most websites are launched to a specific audience or demographic, and if they aren't then your marketing team is missing a trick. If you have a good idea who will be looking at your site, it's then easy to treat them to some nicer typography. For example, Panic achieves this on the company's website for FTP client Coda by using Helvetica Neue Light, after surmising that the majority of visitors will be Mac OS X users, who have the font installed on their system by default. Even if you don't have such a targeted audience, you can still play the percentage game, and in doing so, you can at least treat a portion of your visitors to a more refined, unique look. Call it typographic progressive enhancement!

  6. Detecting installed fonts with jQuery

    April 22, 2009

    I'm a massive fan of pushing the typographic capabilities of our current crop of web browsers and the supported HTML and CSS standards. I'm not talking about embedded fonts or Flash/Javascript-based font generation but using simple CSS rules to bring nice fonts to the user, if available on their system. Richard Rutter, Guillermo Esteves and myself have all published tutorials on how to include non-generic font families in your CSS declarations—the very same methods that allow me to use Adobe Caslon Pro on this website.

    These methods are excellent for progressively enhancing the typography of a website, but are, (rightly so), based on providing a carefully selected set of fall-back fonts should the favoured family be unavailable. At present, there is no elegant way to determine whether your chosen font is being used and, if not, which of the numerous families in your font stack are instead.

    Although I am loathe to call this solution elegant or fail-safe, I've tried to solve this problem by building a jQuery plug-in that should shed some light on which families your site is rendering in, and allow you to alter a site's behaviour, content or appearance accordingly. I've created a [demonstration page] that uses the plug-in to show which of the fonts you currently have installed and enabled out of a list that is fairly arbitrary, (the fonts currently active on computers around the Outside Line office).

    The plug-in works by generating a paragraph of text, outside of the viewport, in a monospaced font. The paragraph is measured and re-rendered in the test font, (if available). If the paragraph dimensions change, then the rendered font must have too, and so the family must be installed/enabled.

    if ($.font.test("'ACaslonPro-Regular','Adobe Caslon Pro'")) {
      alert('You lucky bugger.');

    Usage of the plugin is fairly simple, returning a boolean true or false value when you pass in a CSS-style font-family declaration. You can also pass in, optionally, a font-family declaration that you know is different in dimensions and available to test against, should the defaults not work so well.

    $.font.test("'PanicSans','Panic Sans'", "Georgia, Times, serif");

    The plug-in is of beta quality, and has only been tested to the extent of the fonts available to me. It works in Safari 3, Firefox 3+, and IE 6+. A lot will depend on the font names/post-script names/family names of the fonts you are testing for, as they tend to differ between vendors. In terms of example usage, aside from the demonstration pages, I've updated the about section of this site to deliver a more relevant message describing the design of the site. You can download version 0.1 of the plug-in in uncompressed and compressed form.

  7. Enabling mod_rewrite in OS X 10.5 & 10.6

    January 4, 2009

    Apache's [mod_rewrite][1 functionality allows you to redirect and rewrite your web site URLs, providing a developer with an easy way of creating human readable, well structured and, most importantly, navigable page addresses. It's used by almost all Apache-based software from Wordpress to Codeigniter. Enabling it within Apple's latest iteration of Mac OS X is, unfortunately, a bit of a fiddle.

    Updating the Apache configuration to allow the use of this functionality is achieved by modifying two files, one for the global web-server directory and one for your local web-server directory, (the much easier-to-access ~/Sites folder). The first file to be modified is the global configuration file, and it needs to be modified around line 205.

    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    # Options FileInfo AuthConfig Limit
    AllowOverride All

    The second file, allowing you to use mod_rewrite within your own ~/Sites folder, is the one that seems to break Apache on a more regular basis. The values below, located at the top of the file, yielded the best results, enabling the functionality without causing server errors.

    <Directory "/Users/beseku/Sites/">  
      Options Indexes FollowSymLinks MultiViews
      AllowOverride All AuthConfig
      Order allow,deny
      Allow from all

    After making and saving these changes, you'll need to restart Apache, (easily done via the ’sharing' system preference pane, just un-check then re-check the ‘Web Sharing’ checkbox). If everything went well, Apache should start up again and you should have full mod_rewrite functionality.