My two main gripes with ems

1. They inherit parent em sizing and make calculating the resulting size a pain
2. It can be tough to work out what 14px is equal to in ems

Fortunately, these are both easily fixed.

Use rems

Basically rems are the same as ems but are all calculated from the root (html) element. That means any level of nesting and parent em values won’t get in the way. Just set 1rem (for example) on the html element and you’re done. Browser support has been the main factor in holding back rem adoption (Hi, IE8) but fortunately there are workarounds if you don’t mind a minor JS hit.

Converting pixels to rems

Once you have an easy way to convert pixel values to rems then it’s a breeze to use them for paddings, margins etc and not just font sizes. In Responsive Web Design, Ethan Marcotte came up with a nice way to solve this:

target ÷ context = result

So with our formula in hand, let’s turn back to that 24px headline. Assuming that our base font-size: 100% on the body element equates to 16px, we can plug those values directly into our formula. So if we need to express our h1’s target font size (24px) relative to its context (16px), we get:

24 ÷ 16 = 1.5

And there we are: 24px is 1.5 times greater than 16px, so our font-size is 1.5em

With that in mind we can devise a simple Sass function to take care of this for us:

@function px($num) {
    @return ($num / 16) + 0rem; // Adding 0rem here causes the output to be nrem instead of just n
}

.some-selector {
    font-size: px(26); // font-size: 1.625rem
    margin: px(18) px(18); // margin: 1.125rem 1.125rem
}

The only thing we assume here is that the html element is set to 1rem (equal to 16). This means if you bump your html to 1.2rem then everything will scale up with it. This is great for smaller devices that need a little size boost as all your text, headings, buttons etc will remain in proportion. If you want to experiment with different base value settings then I find this calculator helps.

The other great way of controlling all your sizing via one function is that if you decide you need to switch over to pixels for some reason, then the px() function can simply be altered and the whole website receives an instant update. Easy.

Sooo, how about LESS?

As far as I know (and I’d love to be wrong) LESS does not support the kind of function syntax above. Therefore the only way I’ve managed to get it to work in the past is to list out all my variables by hand (into say sizing-vars.less) and use them that way. So something like:

@unit-type: 0rem;
@base-font-size: 16;

// Rem conversions
// ---------------------------------------------------------------------------
@px1: (1 / @base-font-size) + @unit-type;
@px2: (2 / @base-font-size) + @unit-type;
@px3: (3 / @base-font-size) + @unit-type;
@px4: (4 / @base-font-size) + @unit-type;
@px5: (5 / @base-font-size) + @unit-type;
@px6: (6 / @base-font-size) + @unit-type;
// etc

It’s not pretty, but it works. Being able to have a px() function is almost the main reason I’ve started to reach for Sass more often now.

Even if you don’t use rems right now, I’d still suggest using something like this so that when the time comes you can switch over painlessly.

Enjoy.

Move the current databases

First thing to do is move your mysql folder into Dropbox. It can be found at /Applications/MAMP/db/mysql and for example’s sake we’ll move it to ~/Dropbox/mysql

Create a symlink

Once that’s done pop open Terminal (or iTerm 2 for extra winsauce) and navigate to the db folder inside MAMP /Applications/MAMP/db/. From here run the following terminal command

ln -s ~/Dropbox/mysql mysql

That will now create a symlink to your Dropbox and everytime you make a database change it will be automatically synced.

You can double check it was created successfully by running ls -ll in the same folder and you should see something like:

mysql -> /Users/your.name/Dropbox/mysql/

Simple

Considering the flexibility that the position property affords us, it would make sense that the same rules apply to the background-position property. Sadly, this is not so.

Top left

Most developers will be familiar with setting the offsets of their background images from the top left of an element:

background-position: 100% 50%;

background-position: 10px 10px;

Limitations

But what happens when the design requires the image to remain 20px from the right side and 20px from the bottom? Not so simple when our positions are relative to the top left.

One approach requires upfront knowledge of the image dimensions and those of the element to which it is being applied:

/*
  230px = (350px - 100px) - 20px
  130px = (250px - 100px) - 20px
*/
background-position: 230px 130px;

This is a fairly hideous solution and makes assumptions that our element and image will never change width. And it requires me to do maths, which I never enjoy.

In today’s responsive world, this simply won’t fly. So what about percentage measurements? Again this requires more maths and more importantly, the spacing will vary on flexible elements:

background-position: 94% 87%;

Out with the old, in with the four

The solution is also deliciously simple:

background-position: right 20px bottom 20px;

Different values can be mixed, just as before:

background-position: right 1em bottom 50px;

background-position: right 40% bottom 2em;

Additionally three values can be used, providing the third is a keyword value:

background-position: right 1em center;

Browser support

As you could have guessed, support for this syntax is a bit spotty.

Currently, you’ll find it in:

• Firefox 13+
• Opera 10.5+
• Internet Explorer 9.0+

It’s surprising to see Webkit absent from that list, but a bug has been raised and hopefully we can expect to see it soon.

However, don’t let this stop you using it now! If you make use of Modernizr in your projects then there is a feature detect that can be easily dropped in.

One example is to simply provide a percentage-based fallback:

.element {
    background-position: right 1em center;
}

.no-bgpositionshorthand .element {
    background-position: 97% center;
}

If you feel like moving the kitten background around yourself, then there is a demo available on jsfiddle.

That’s it

A simple addition, I’m sure you’ll agree. But I’ve already found uses for it responsive layouts and hope you do too!

Further reading

• Background position on the Mozilla Developer Network - Includes a browser support table
• CSS3 background position specification

Straight to the point

The code doesn’t require a massive amount of explanation

!function(global) {

    // Wrapper function that allows us to pass it to define later
    var wrap = function($) {

        // Standard JS object stuff
        var Foo = function(element, options) {
            this.options = options;
            this.element = element;
        };

        Foo.prototype = {

        };

        // Here is the actual jQuery plugin part. It just creates a new Foo object
        // for each matched element in the jQuery object.
        $.fn.foo = function(options) {
            options = $.extend({}, $.fn.foo.defaults, options);
            return this.each(function() {
                new Foo($(this), options);
            });
        };

        // Plugin defaults
        $.fn.foo.defaults = {
            'default': 'yeah',
            'test': 'simon'
        };
    };

    // Check for the presence of an AMD loader and if so pass 
    // the wrap function to define. We can safely assume 'jquery' 
    // is the module name as it is a named module already - http://goo.gl/PWyOV
    if (typeof define === 'function' && define.amd) {
        define(['jquery'], wrap);
    } else {
        // Otherwise we assume jQuery was loaded the old 
        // fashioned way and just pass the jQuery object to wrap
        wrap(global.jQuery);
    }

}(this);

 Using the plugin

For non-AMD users (pah!) they can just use the plugin the same way they always have:

$('.some-element').foo({
    test: 'option1',
    test2: 'option2'
});

Hot sauce AMD users have a familiar experience:

require(['jquery', 'Foo'], function($) {
    // No need to pass a Foo argument as it augments the jQuery prototype directly
    $('.some-element').foo({
        test: 'option1',
        test2: 'option2'
    });
});

This is just something I came up with whilst fiddling around. Some ideas for improvements are welcomed.

Prior to using AMD it would be solved by just namespacing an object with any settings required:

MyApp.settings = {
    siteRoot: 'http://myapp.com',
    currentPage: 'home'
}

// Later on
if (MyApp.settings.currentPage === 'home') {
    // Do some cool stuff
}

With AMD you can create a settings module and just require it whenever necessary:

    // modules/settings.js
    define({
        siteRoot: 'http://myapp.com',
        currentPage: 'home'
    });

    require(['modules/settings'], function(settings) {
        if (settings.currentPage === 'home') {
        // Cool stuff
        }
    })

Populating with server side values

In the example above it’s likely that the siteRoot value would come from the server and it’s common to output these values into a script element directly in the HTML page. To do this AMD-style means adding an id (as the first parameter) to the module definition:

<script>
    define('settings', {
        siteRoot: '<?=$site_root;?>',
        currentPage: '<?=$current_page;?>'
    });

    // require as normal
</script>

Simple

One approach is to adopt the jQuery way of using AMD (hence poor man) and just load the whole library. The primary reason for this is to let us start writing Classes and other MooTools code AMD-style and enjoy the rock star status that proper dependency based JavaScript guarantees.

Use.js

If you’re at all familiar with AMD then you’ll no doubt have heard of the wonderful RequireJS. It’s my library of choice when it comes to AMD (other loaders are available) and with it you can make use of use.js. Basically, it’s a plugin that will allows use of non-AMD code (by wrapping it in a define) with our modules and it’s such a useful feature it will be landing in RequireJS 2.0 as ‘shim’.

Load me some Moo

Let’s get down to it and check out an example of configuring use.js:

require.config({
    baseUrl: 'scripts',
    paths: {
        'use': 'lib/use',
        'mootools': 'lib/mootools-core',
        'mootools-more': 'lib/mootools-more'
    },
    use: {
        'mootools': {
            attach: 'MooTools'
        },
        'mootools-more': {
            deps: ['use!mootools'],
            attach: function(MooTools) {
                return MooTools.More
            }
        }
    }
});

First thing is to ensure that the paths to MooTools are set correctly.

Next, within the use options object we merely define the files we want to pass through use, any dependencies and also how it behaves once returned to a require or define call. In this case I’m returning the MooTools or MooTools.More object. Neither provide any real use (as MooTools either augments existing objects or creates it own) but it’s the most semantic thing to return.

Using the hot AMD sauce

Once the boring stuff is out of the way you can begin having fun with your modules:

// classes/myclass.js
define(function(require) {

    require('use!mootools');
    require('use!mootools-more');

    return new Class({

        Implements: Options,

        initialize: function(message) {
            console.log(message);
        }

    });

});

// Meanwhile...
require(['classes/myclass'], function(MyClass){
    new MyClass('yeeeeaah'); // logs 'yeeeeaah'
});

That’s it, easy!

Once MooTools goes AMD for real, all you’ll need to do is update your dependency list for your classes and you’re done.

Asynchronously go forth!

Update:

Since posting this, RequireJS 2.0 has been released which includes the shim configuration that allows this kind of functionality by default. Use that instead!

Essentially the inherit property forces a child element to use (or inherit) its parent properties on a specific value. You might think that this happens automatically but one common example where this isn’t applied is changing the colour of an <a/> element.

<div class="wrap">
    <a href="#">Oh hai, a link</a>
</div>

.wrap {
    color: red; // My link didn't change
}

The link would still be it’s original (usually ugly blue) colour and a common pattern is to now write a separate declaration to target the <a/> and repeat the colour again. A cleaner workaround is to force the <a/> to inherit the red colour applied to its parent like so:

.wrap {
    color: red;
}
.wrap a {
    color: inherit;
}

A very slight change, but it saves you repeating the same value

Another great thing that has come about from Bootstrap is their use of class names to organise the styling of the framework. I’m sure the argument about exclusively using CSS classes could rage on but I’ve found on large sites with multiple developers it has been a great way to keep code modular and easy to change.

LESS is more

To give an example, Bootstrap tends to use a ‘base’ class and the build from it, like this:

<ul class="nav nav-tabs nav-stacked">
</ul>

I’ve come to enjoy this pattern, because when combined with LESS you can create some really nice, modular blocks of CSS. I’ll demonstrate with some button classes I have been writing for a design at work:

.btn {
    font-size: 14px;
    background-color: #a1a1a1;

    span {
        background-repeat: no-repeat;
    }

    &.btn-rounded {
        .border-radius(5px);
    }

    &.btn-pressed {
        .box-shadow(-1px 1px 2px 0 rgba(0, 0, 0, .1));
    }

    &.btn-prev {
        text-align: left;

        span {
            background-image: url("@{imgPath}buttons/arrow-left.png");
            background-position: left center;
            padding-left: 15px;
        }
    }

    &.btn-next {
        text-align: right;

        span {
            background-image: url("@{imgPath}buttons/arrow-right.png");
            background-position: right center;
            padding-right: 15px;

        }
    }
}

By using the & combinator we can keep the code nested beneath the .btn base class keeping the code easy to read and the resulting CSS is targeted just to the .btn class which is exactly what we want.

Overriding

In the example above I have two classes to control whether the button should have an arrow facing left or right. That’s great, but now I want to make a larger version of the button which involves overriding the current .btn-prev and .btn-next with new image paths:

    &.btn-large {
        @padding: 15px;
        font-size: 16px;
        padding-left: @padding;
        padding-right: @padding;

        &.btn-prev {
           span {
               background-image: url("@{imgPath}buttons/arrow-left-large.png");
               background-position: left 1px;
               padding-left: 20px;
               padding-right: 10px;
           }
        }

        &.btn-next {
           span {
               background-image: url("@{imgPath}buttons/arrow-right-large.png");
               background-position: right 1px;
               padding-left: 8px;
               padding-right: 20px;
           }
        }
    }

Now when I add a class of .btn-large to my <button/> element the .btn-prev and .btn-next I had already defined will be overridden by the two new definitions.

Once you start to create a little collection of classes like this, it becomes an absolute breeze to alter your designs by just swapping out different CSS classes and modifying existing ones just by adding additional classes.

However, like all things it can be easy to get carried away. So keep a sharp eye on your CSS output and ensure you don’t create needless selectors just because the nesting looks nice in your LESS files!

Luckily, I was given the fantastic task of sifting through CVs from potential candidates.

Now, if your sarcasm detector has just gone haywire then don’t worry, it’s with good reason. You see initially I presumed I would be swamped with all manner of fantastic developers all clamouring for some Radio Times shaped pie. Unfortunately it turned into being a frustrating trek through a vat of Word document treacle, and the bulk of that frustration stemmed from the quality of CVs that fell into my inbox.

I saw some good, and saw some bad. So much so in fact, that I thought I could point out a few recurring themes and hopefully inspire some developers to represent themselves more favourably.

Whatever happens show me some code!

I don’t care if you’ve just burst into flames whilst writing your CV. The last thing your charred fingers should be doing is providing a way to get to your code.

I’m not sure I can convey just how important this point is (admittedly, the topic of spontaneous human combustion might just do the trick).

The amount of developers I’ve witnessed without some form of portfolio is quite baffling. At some point in the recruitment process a technical person (most likely a fellow developer) is going to want to see how good you are; and there is no better way than checking out your code.

Linking to the home page of a site you worked on is not good enough. You may have written the whole site, or you may have altered the heading text in a sidebar. It’s impossible for the developer perusing your CV to know this. Explaining what you did specifically is a possible alternative, but you need to be sure your code won’t be re-written. Especially if someone does it badly.

If you don’t have a portfolio then upload some snippets to GitHub, jsFiddle or even Pastebin (it has syntax highlighting!). Basically, get your code in front of your potential employer as fast as possible. They’ll already be thinking “I like this guy” for making their job that bit easier.

Your entire employment history does not interest me

The web is a fast moving place and a good front end developer has to adapt to new techniques quickly. This usually means we have to drop techniques or coding practices that worked before but are no longer the best way to go.

Think how fast the landscape has changed already. Mobile first development, HTML5 and responsive design are just some examples of technologies and design patterns that have absolutely taken off. Showing awareness of these techniques and embracing them often reveals the difference between a “9 to 5″ developer and someone who lives and breathes their craft.

With this mind I found myself paying less attention to job details more than a couple of years old. Candidates tend to include a huge paragraph outlining everything they did at each stage of their employment history and frankly, knowing how awesome you were at IE6 bug fixing in 2008 is not really relevant now. That’s not to say an employment history isn’t useful (if you worked at Facebook in 2008, you should damn well make it clear!) but it’s unncessary to outline everything.

Include a short summary of your time at older positions, and pile on the detail about all the cool stuff you’ve built in the last year or two.

Keep your skills succinct

Ah, the skills list. A place to spit out every single acronym and buzz word that you can think of. It’ll make you look cool right? No, it won’t.

Limit it to the core skills that you actually use. And for god’s sake don’t list every application you’ve ever opened. I can safely assume you are competent with an IDE and Microsoft Word.

One of my favourite ‘kitchen sink’ lists

Be prepared for agencies to interfere with your CV

A few times I have seen recruitment agenices add their own front page to a candidates’ CV or even go as far as editing their actual details. This can be a problem because they’ll usually just add keywords and more skills, which of course you have not authorised.

To combat this I recommend sending your CV as a PDF (using the many free services available to convert from a Word document) and also making the file available for download from your portfolio.

Spelling and grammar still count

Don’t rely on your chosen word processor to cover your back when it comes to these two. Read your CV, re-read it and then read it again. Even better if you can get a colleague/friend to give it a vigorously strict review.

If basic mistakes like the difference between ‘there’ and ‘their’ or ‘you’re’ and ‘your’ are peppered all over you CV then you’re only going to create a negative impression. After all, if you don’t take care with your incredibly important CV, what are you like when it comes to code quality?

Oh, and definitely make sure you spell things like JavaScript and jQuery correctly (it’s not Jquery!), the little things count!

Make a big deal out of personal projects

Working outside of your scheduled ’9 to 5′ job says a lot about your attitude to front-end development. There is a lot to keep up on in the front-end world. All the new parts of HTML5/CSS3, new approaches to problems being discovered and shared on twitter and blogs, and finding the time to actually practice and learn this stuff. It’s a tricky field to remain competent in, but we do because we love it!

There isn’t a better way to demonstrate this than working on a project of your own choosing. It can be writing a useful JavaScript snippet, creating a new library, contributing to an open source project or even just making a website that uses a cool technology. Whatever you choose, it will give you a chance to write code that is free from the constraints of your place of work and gives you a real chance to demonstrate your prowess.

Personal projects speak loudly on a CV.

Don’t lie

This is a pretty obvious one but it needs a mention here. Your web of lies can easily be unwound by a few well placed technical questions or a test, and it just makes you look foolish.

A common example is candidates who boast a wealth of JavaScript experience but in reality have done little more than include a few jQuery plugins on a page and wire up some events. If you find yourself needing to bend the truth, then all you’ve done is discovered some gaps in your knowledge that you should aim to rectify with some good ol’ fashioned learning!

Conclusion

The few tips here are from own experiences and are likely not to be hard and fast rules. I will admit that until I actually had to sit down and read through a bunch of CVs I was making a few of these mistakes myself. I simply identified what annoyed me as someone who had to read them all and transferred that experience to my own CV. Annoyingly simple in hindsight.

Oh yes, we found a great UI developer for the Radio Times project in the end. Success!

At this stage it’s probably worth doing one of those disclaimers that we see in blog posts all the time. There are a lot of stupid people about so I’ll say now that all of these points/views/opinions are mine and nowt to do with the BBC or any of it’s affiliates.

Idiot speech done, yay!

MooTools is awesome

Radio Times was the first large site that I’ve built using MooTools as the main JS framework and it’s sealed itself as my preferred library. I particularly favour the way it encourages the developer to organise their code using OO concepts, something which I always longed for when writing JS with jQuery. My favourite quote comes from a site that enticed me into converting from jQuery shenanigans, the aptly named jqueryvsmootools.com:

If jQuery makes the DOM your playground, MooTools aims to make JavaScript your playground

jQuery was the first library I got involved with (I was writing it before I even knew the correct syntax for a function, ugh) and it definitely helps novices get stuff done, but if you want to embrace JS as a language then MooTools helps you achieve that. Mind you, if I need to get stuff done fast on a small site I will always consider reaching for jQuery as it comes down to what tool is best for the job.

It’s on my list to properly explore Dojo as well, but that’s a task for another time.

Should have used responsive design. Foolish error

Ah, I kick myself for not pushing this more at the beginning of the project. I remember sitting down with the product owner near the start of the project (December/January last year I believe) and explaining the benefits of this technique and why we should embrace it but unfortunately the design agency had already held us up long enough just getting desktop versions completed, so there certainly wasn’t time to start exploring layouts for different sized devices. The decision was made to “do it at the end” but as we all know, when dealing with the concept of “mobile first” that is largely impossible.

Responsive design is an even bigger deal now than it was when I had that discussion and I would go as far to say that there isn’t two ways to build a site anymore. Just do it responsively, end of. Now Radio Times wants to make a move into the mobile space and after seeing what The Boston Globe achieved I really regret not pursuing this more aggressively.

Stop trying to replicate PSDs in all browsers

One thing I am proud of is breaking the mould a bit at the BBC when it comes to defining what ‘cross browser compatibility’ actually means. If you have an ounce of interest in front-end development you can’t avoid being exposed to the preachings of Andy Clarke. Essentially he talks about the ridiculous notion of trying to achieve pixel perfect designs in all browsers. With so many devices (all with varying levels of standards support) it is next to impossible. Instead, embrace the modern browsers and their capabilities and degrade your design for the old, wheezing versions of IE that can’t keep up.

With that kind of awesome advice ringing in my ears I set out the rule early on that IE users would not get the same experience as Chrome, Firefox et al, but they should never think the site looked broken. Given that a lot of people involved with the site at BBC Worldwide were using IE8 it could be deemed a crazy idea and I was grateful that the product owner put trust in me to make this decision.

With some serious reliance on Modernizr, that goal has been achieved and users of modern browsers are rewarded with some quite lovely CSS3 uses. Forward thinking, yes!

When it comes to HTML5, 8 is the new 6

I am of course referring to the line of browsers prefixed with IE. We tried to fully embrace the use of HTML5 elements on Radio Times but by jumping ahead to this exciting new world of semantic joy, IE8 is once again holding developers back. Two tools that help us fight this sorry state of affairs are Modernizr and Selectivizr. Both are invaluable but one area that you can become unstuck in is needing to update the DOM with new elements. The RT listings page makes use of an article element for each channel and when the user selects a new time slot, the page is updated with Ajax. This is when things get a little ugly in IE.

We fought this beast by making use of a handy script called innerShiv and although it’s not ideal it’s certainly a viable way to get round IE and dynamic content issues, particularly if you don’t want to start wrapping all your clean markup in div elements.

If you’re gonna get all futuristic up in here with HTML5 and CSS3 then you need to accept that IE8 users and below are going to have an inferior experience. If you can deal with that (or rather your clients can!) then you’re all set.

Don’t outsource your site design

And if you do, ensure it’s an agency that understands the limitations and strengths of a browser. Also, some User Experience erm.. experience will help as well. Not all agencies are bad, they can’t be, but unfortunately at BBC Worldwide I’ve seen a couple of projects outsourced to a poor design agency, even when there are perfectly good designers sitting around in-house.

The design process is and should be something that continues to iterate. The front end developers and designers need to work closely to produce the best work, especially if they plan to implement a responsive design. You simply can’t just send a list of requirements off, wait for a bit, get a bunch of PSDs back and start building them. The amount of changes and queries we had with some of the Radio Times designs were crazy, equally so were some of the user experience choices. Double clicking areas of the page? Yeah that was thrown in at one point.

Back-end and front-end devs work together, but in my mind it’s even more important that designers work in that group. Crucial.

Universal IE6 is great

Fortunately the decision to drop IE6 support was made fairly early on due to the hideous amount of dev time soaked up in fixing things (IE7 & 8 were enough trouble). However, instead of just leaving a stupidly broken page for our unfortunate IE6 users it took all of five minutes to implement Andy Clarke’s awesome Universal IE6 stylesheet. It essentially strips away all layout styling and leaves a nice looking, linear page for IE6 users which is designed to allow them access to the content only.

So far I’ve not heard one complaint about this approach from our users.

Remove obstacles from developers

One problem I continually see with the projects I have been on is the need to introduce process where it absolutely shouldn’t be. And I’m referring to little things that just stop a developer from developing. On the Radio Times project for example, we would spend time in our stand up meeting putting smiley faces on sprint goals that showed how we were progressing. If anything, Project Managers should be looking to strip away as much process as possible. No one will complain that there aren’t enough wall charts and meetings. Ever.

The most productive times I’ve ever had are when I’m given a task to complete and then just left for a day or two to complete it. No meetings, no continual interruptions. PMs don’t need to justify their position with fluffy processes.

Script loaders are ace, but not the only solution

I made the mistake of thinking RequireJS was so awesome that it could simply work in every single scenario. Obviously all libraries have their uses and I got a little blinded by all the asynchronous script loading and module based sexiness. I wrote all the MooTools classes to take advantage of the dependency based approach that RequireJS affords and ensured nearly all our scripts were loaded this way.

I actually ended up having a lot of issues with load order of the scripts, particularly in IE. I’m confident I was using the library correctly as most browsers played nice and the loading issues appeared to be intermittent. However, it was deemed too risky to release with those hidden problems so I had the fun task of editing all the Moo classes!

Working with one of the back-end devs, we created a similar system that would load scripts but concatenate them into one file, all in order and also minified when the page loaded. This proved to be just as useful and even faster on the load speed (we tried the RequireJS build tool first and didn’t have much luck).

This actually inspired the creation of BoxJS and BoxCSS which essentially do the same thing.

Embrace retrospectives

One thing I’m glad we did do on Radio Times was to really embrace fortnightly retrospectives. Now, this is not all to do with the beer and snacks that we would bring along, but if you’re gonna have a long meeting on a Friday afternoon I’ve noticed no one complains when a beer is on the table.

I think we tried about ten different ways of working the Agile board and cards on this project based on feedback from these meetings, but that is preferred over battling on with a system that doesn’t work. Being able to discuss negatives and positives openly in a dev team makes a big difference to the morale of the project, especially when measures are put in place to address the problems.

Never come out of a retrospective and start quietly moaning about problems on a project. Voice them!

Using custom fonts? Test them without ClearType enabled

Here’s an interesting one.

The designs for the new site utilised the Interstate font family quite heavily and many of these fonts are quite thin. At BBC Worldwide if you’re not using a Mac then 90% of the time you’ll be on an XP machine, and helpfully the default setting for these boxes is to have ClearType disabled. Trying to read some of the Radio Times fonts like this was a taxing process, and it became more evident when the site first went into beta as many users complained about the legibility of the copy.

Being too far down the line to start altering fonts (and having paid a bucket load to license Interstate!) we had to find a fix, which came in the form of this excellent technique for detecting aliasing with canvas.

I’ll wait for one my colleagues to tell me ten things I should have learnt!