Say hello to Flicker

Genius name no?

Before going any further it’s probably a good idea that I provide a link to the files which can be found on GitHub. Got em? Good.

Using the Flicker class is pretty easy, you just need an element to contain the photos and your user ID:

new Flicker( $('container'), '41265688@N02', { /* options */ } ).getPhotos();

Once you call getPhotos a request to the Flickr service will be made you will get a list of the latest photos from your photostream. This will also work with any other username, it doesn’t have to be yours.

I like options

I’ll simply list the default options object from the source as it has self-explanatory comments and it would be a bit pointless of me to re-write them:

options : {
    num : 6,

    // Type of element to contain each photo
    element : 'li', 

    // Attached to each containing element
    className : 'flickr-photo', 		

    /*
	Size of images to return:
	_s = 80x80
	_t = 100x75
	_m = 240x180
	'' (empty string) = 500x375
    */
    imgType : '_m',
    random : false,

    // Callback passed array of photo elements
    onImagesReady : function( elements ) {

	elements.fade('hide').inject( $(this) );
	    elements.fade('in');

	}
    }

That’s pretty much it for the Flicker class, but what about loading images from a specific set?

Flicker.Set

You will need a few more details to be able to load photos from a specific set. As well as a user ID you will also need the set ID and request an API key from Flickr.

Ensure you have both the Flicker and Flicker.Set classes on your page and just pass the extra arguments:

new Flicker.Set( $('container'), '41265688@N02',  '72157626037018637', 'xxxx API Key' ).getPhotos();

As well as the options provided by Flicker, there are a few changes to handle a set:

        // Additional data to request from Flickr API
	// http://www.flickr.com/services/api/flickr.photosets.getPhotos.html
	extras : 'date_taken,url_sq,url_m',
	photosetLinkText : 'View this set on Flickr',
	photosetLinkPos : 'after'

I’ve only listed the ones you’re likely to change.

With all that in place you should now be seeing a list of images from your chosen Flickr set. Easy!

Taking it further

If you check out the source of this blog’s home page you can see my usage of the Flicker class. You will also notice that I’m actually calling a class called Photoset.

To add the additional functionality (shuffle, Highslide pop-ups) I extended Flicker.Set; creating a nice structure of MooTools classes.

I’ll leave you to play about with it.

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!

Separate methods for event handlers

Personally I prefer this pattern

var Example = new Class({

    initialize : function( element ) {

        this.element = $( element );
	this.element.addEvent( 'click', this.fetchItems );

    },

    fetchItems : function( event ) {

    }

});

instead of this one

var Example = new Class({

    initialize : function( element ) {

        this.element = $( element );
        this.element.addEvent( 'click', function( event ) {

        });

    }

});

Keeping your event handlers separate looks cleaner, it’s easier to test and gets you girls. Paul Irish touches on it briefly in his jQuery anti-patterns talk (slide 13).

What’s da problem?

So you’ve decided to separate your event handlers into their own methods, but things can get a little tricky when you wish to refer to a property of your instance, maybe an option for example:

fetchItems : function( event ) {

    console.log(this.options.amount) // Errar! this refers to the element you clicked on

}

If you don’t need any reference to the element then feel free to dive in with the standard Function.bind:

this.element.addEvent( 'click', this.fetchItems.bind(this) );

The console.log from earlier will work fine. Hooray.

I want both!

Ha! I thought so (otherwise why would you be reading this?). All you need to do is include the Function.bindEvent extension and then adjust the above code to use .bindEvent

this.element.addEvent( 'click', this.fetchItems.bindEvent(this) );

Now your event handler gets an additional argument for you to play with:

fetchItems : function( event, _this ) {

    console.log(_this.options.amount) // works!
    this.addClass('pow') // this works too!

}

The current context gets passed as an argument along with the event object. Also any additional arguments will also be passed to the event handler, just like normal Function.bind.

It’s not ground breaking but I probably use this snippet of code more than any other MooTools extension.

Grab it from GitHub!

To my delight, all that is needed is a bit of patience and some spare time to make Windows 7 visually suck less.

First, the goal

Try and tell me you don’t want this in your life:

Ingredients

You will need:

• RocketDock
• Simple Dark (theme for RocketDock)
• Windows 7 Glass Onion Theme
• Lucid Icons
• Sexy lady

Setup

Get the Glass onion theme installed first.

Fortunately the theme provides detailed documentation and literally every tool you need to install the various files. But you will be overriding a few crucial Windows files so ensure you backup!

Provided that has gone successfully, the most time consuming part will be creating application short cuts, dragging them on to RocketDock and then changing each icon.

One thing I noticed here is that the Simple Dark theme has a slight bug that seemed to stop me dragging icons on to it. Just select a different theme to get everything set-up and then switch back when you’re done.

RocketDock settings

Here are the settings I used for the RocketDock setup pictured:

Bask in the minimalism!