Yesterday at about 5:30pm my Grandma passed away.

In simple terms I am devastated about this, my grandma was the only grandparent I knew, I don’t remark this in a bitter way its simply how life ended up. So devastated, yes, but in other ways I feel joyous and pleased. Joyous and pleased, for rather than this being a tragic situation, a life taken away in its prime, an unexpected shocking demise, it is a chance to celebrate a remarkable life.

Nana Kath, as she was known to everyone was just over 100 years old. Now in years to come this may not be a remarkable age, but today it is. Think about this, my Grandma was born Sept 22nd 1912, thats two years before the first world war. In 100 years she has lived through a lot and seen unprecedented change.

Unfortunately I couldn’t give you the history and life story of my Grandma, there are many facts I would end up getting wrong and 65 years had already been and gone when I was born. What I can tell you is that during all of the years I was privileged to have with her I have rarely met a keener mind. Her memory always amazed me, she recount stories from her childhood as if it was yesterday. In another time and place she would have achieved so much, but shackled by circumstances and the time of life she achieved everything a mother, grandmother and great-grandmother should.

Right up to the age of 100 she lived an independent life, a quiet life in the heart of yorkshire. She lost her beloved Charlie nearly 30 years ago, a long time to be apart.

In her last few years she was loved and remarked a sense of awe by all she knew and met. Her 100th birthday party being a fantastic celebration where she far outlasted even the most optimistic expectations of her. Family and friends from far and wide together in appreciation.

The last 6 months have been hard and in the end I like to think she knew it was time to go and I am thankful for the small mercy of her not suffering. Its time to be reunited with Charlie.

In her final days in hospital two tales epitomise my Grandma for me. When she was first admitted to hospital her first remark to the nurses was:

I hope you’re not going to put me in a ward with all the old folk.

And when a nurse found out she was 100 she asked whether she had received a telegram from the Queen and if she had put it up on her wall, her reply was:

Oh yes I got one of those but there’s no room for it on my wall, its full of important pictures of my family.

She kept her humour to the end and even in her wane was still a shining light.

R.I.P. Nana Kath, I love you.

To my surprise when I open it up in IE9 there was appeared to be no serious issues. A pleasant surprise, the text lacked text-shadow in a few places, but this is an aesthetic issue not a downright broken issue so I can live with it. Feeling bolder I moved on to IE8 and was very disappointed when the site was a wreck, not slightly broken but very broken.

This was a bit unexpected as I tend to develop using well known patterns which only occasionally need tweaking. Something else must have been the issue. Following a brief conversation with a dev friend he pointed out that IE8 doesn’t support media queries. All of my layout and navigation was defined in media query, hence the massive fail.

The solution was a straight foward approach:

1. Copy the CSS out of the media query into a separate file
2. Conditionally include it in the header for IE8 (and below)

This approach does however pose a maintenance overhead, if I make changes to the desktop CSS this needs to be carried through to the external file. Ideally I want to be able to maintain one file which is referenced in the main file. The media query spec does not allow you to use a CSS import inside it, so this approach is not available.

Fortunately I use a CSS pre-processor to create my CSS, I use {less}, less allows you to use multiple files and import them into a single output file. My approach was to simply copy the less into an external file and use the @import syntax in the main file. I could then reference the compiled external file in a conditional comment.

@media only screen and (min-width: 769px) {
  @import "desktop";
}

This did not work unfortunately, the less parser currently does not understand this construct and the import is ignored. It is a well known issue and has been discussed for some time. It is fixed for now in the master branch and is scheduled for the 1.4 release but isn’t out yet. Instead I have used the following work around.

Wrap the code required in a mixin in an external file (desktop.less) i.e.

.desktop() {
  less code...
}

Then import the code outside of the media query and call the mixin inside the media query (main.less) i.e.

@import "desktop";
@media only screen and (min-width: 769px) {
  .desktop();
}

Finally I created an extra file which includes the code outside of the media query which can be compiled and conditionally added (ie.less) i.e.

@import "desktop";
.desktop();

One file to maintain, compiled into the main CSS file, and and another CSS file for conditional inclusion. When 1.4 is released my first approach will be available and you won’t need the extra file, until then this is a good work arund.

Back in the early 2000′s there were basically two browsers of note (I am deliberately generalising here and am well aware there were more than two browsers) IE6 and Netscape, roughly speaking it was a 90/10 split. IE6 was the ground breaking browser, way better then Netscape, and it was believe me. As a developer you spent most of your time developing to IE6 well aware of the fact it probably broke a bit in Netscape. Never a comfortable situation but it did allow you to take advantage of the better features in IE6 which seemed a good compromise.

Fast forward a few years and the next chapter in the browser wars, the standards movement. Raising Microsoft out of their slumber it pushed the web forward, IE7 was awful, IE6 the bane of developers lives with IE8 and Firefox the leading lights. It was bad for a few years but we moved forward, slowly but surely we started leaving behind IE6, sure there was still 10% of people using it but sacrificing these users for the good of the 90% was acceptable.

And now we are in modern times, Chrome has emerged as the new darling of browsers, IE9/10 makes it again one of the contenders, Firefox is still in the mix and everywhere mobile is the new must support platform. And then there is IE8… Yep you guessed it, representing about 10% of your users.

Given the importance being placed on mobile as a platform, and the fact that most mobile/tablet computers have fairly good support for modern standards is it time to sacrifice the 10% again. Some big sites and big players such as Google have already signalled the end of IE8, is it time for this to become the norm? IE8 usage will only drop and mobile looks set to increase, in my eyes the time is now…

In recent years there has been a large movement towards offering the best of both worlds in a responsive site. A site which isn’t constrained by the fixed dimensions, that works equally well on a large display or a small screen mobile device.

I haven’t touch the design of my site for a couple of years now. I went down a “design” by iteration route until I got to the point where I was happy enough with the design that I stopped. Since then I have wanted to update the site on a few occasions and even got to the point where I have been tinkering with the layout, fonts and overall design. What became clear as I was doing this was that making the site that I already had responsive was not going to be a quick and easy task.

Today I have decided to drop my theme and instead of wasting my time on creating a theme use the latest in-built theme from WordPress. I have installed and activated Twenty Twelve, the new responsive theme from wordpress.

It takes all of the heavy lifting out of the design and what I end up with is an extremely flexible design which not only functions extremely well in the responsive world but also in my opinion looks great as well.

I’m sure over the coming months I will add my own little touches here and there. I also still haven’t given up on the idea of creating my own responsive design, however I think I will use my commercial site to work this out on, so stay posted for news in this area.

I have always solved this issue previously by simply creating a slide template and creating pages which are assigned to this template, usually as child pages of the homepage. A page has a few common parts, title, body copy, featured image which can all be used to create the content. Then if there are other structured requirements you can use custom fields on a post to add these elements. Overall the standard page functionality can be manipulated to achieve the desired result. This approach works, to some degree but it isn’t user friendly and can frankly be a pain to use.

Another way of doing this is to find a plug-in which adds slide functionality, and there are a large amount of plug-ins of varying quality which do this. I hate plugins in general, the quality of them is outside of your control, they can break or hinder the upgrade path unless actively developed and often they add bloat to your theme. Sure they are much more user friendly but as a plug-in is often a generalisation of the problem rather than a specific answer to a problem a plug-in doesn’t always fulfill your requirements.

The third and final way is basically a mash of the two, custom post types. A custom post type is often basically what a plug-in is. However as you are defining it you get to control it. Where you are using custom fields you get to layout the edit screen in exactly the way you want to, label the custom fields appropriately and make the creation and updating of the content much more intuitive and user friendly.

There are 2 things you need to do to get custom post types working:

1) Register the post type

register_post_type( 'home_slide',
    array(
      'labels' => array(
        'name' => __( 'Home Slides' ),
        'singular_name' => __( 'Home Slide' ),
        'add_new_item' => __( 'Add New Home Slide' ),
        'edit_item' => __( 'Edit Home Slide' ),
      ),
      'public' => true,
      'show_in_menu' => true,
      'supports' => array(
        'title','editor','thumbnail'
      ),
      'rewrite' => array( 'slug' => 'slide' ),
      'exclude_from_search' => true
    )
  );

2) Create the code to define the post type. I won’t go into detail on this one but I found the following tutorial useful to get me started:

http://wp.tutsplus.com/tutorials/plugins/a-guide-to-wordpress-custom-post-types-creation-display-and-meta-boxes/

From now on I will be using these on a lot more word press projects.

I’ll freely admit that I’m not a designer and that if I was I’d probably get just as annoyed when looking at a design where something doesn’t quite fit in with the overall feel as when I see a piece of code which is not as aesthetically pleasing. However if the code works I’m inclined not to change it, after all if it ain’t broke don’t fix it. So why, if there are such compelling reasons not to, do designers insist on changing the look of native form controls? Specifically I am talking about <select> and <input type=”file”> for fields, although this can easily be extended to checkboxs, radio buttons and to some extent submit buttons.

I won’t argue as to the how good or bad they look as to me its a bit of a non issue, but I can come up with some fairly compelling arguments as to why changing them, probably through the use of JavaScript is a bad idea.

• Native controls are bullet proof – by this I mean the browser makers have spent considerable amounts of time coding and testing the native controls to ensure they work correctly. They have found and fixed all of the hundreds of edge cases, as opposed to a JavaScript solution which potentially cannot handle a multiple selection use case, or a list which is 1000 options long.
• Native controls are future proof – what happens to your JavaScript implementation when a future browser gets released that changes the way it handles scroll events? Native controls don’t suffer from this, they will work in future releases as the browsers makers test them for you.
• Native controls are familiar – everyone who browses the web will have come across a native control, will recognise is and will be fairly comfortable with how it works. In terms of usability you can’t trump that.
• Native controls are accessible – going back to my first point, native controls have a lot of inherent accessibility built in, you can use the mouse or keyboard to interact with them and things like screen readers are well aware of them. Unless your JavaScript implementation covers all the same use cases that a native control does then you are simply using a inferior form element.
• Native controls are (more) secure – a standard file control has a lot of security built in. Drag/drop interfaces whilst nice don’t always have this inherent security built in.
• Native controls are cross browser compatible – you don’t need to worry whether your JavaScript implementation works in IE6, it just does.

This list isn’t exhaustive but it does highlight the advantages of using native controls. I’ll give a couple of recent examples.

For a project I recently did one of the requirements was to be able to upload a file via a public interface. The design had a lovely branded purple browse button and accompanying , which granted probably looked better than the standard browse button. I explained at the start of the project that styling a file form field is difficult to do and I wouldn’t recommend it. Regardless it went ahead, but I caveated my quote with a non guarantee that it would work cross browser. I styled the button using a JS implementation and for the most part it worked. I then got a bug report that it didn’t work in Firefox 14, sorry I can’t guarantee it will work. Not a huge deal as it turns out the work/won’t work scenario was intermittent (great!!). Next is this doesn’t work in iPad, well no of course it doesn’t file fields don’t work in iPad, thing is that on an iPad the native file field would be greyed out and disabled, the styled file field isn’t, there are probably a hundred mobiles that this is the case for. If we had used a native form field both of these problems would not have been a problem, it still wouldn’t have worked on an iPad but at least the user would have known.

The second example (from the same project) was that a drop down menu that had been styled didn’t work in Safari 6. It was another JS implementation, fairly good cross browser support and had recently been updated so still actively maintained. But still it had certain use case where it didn’t quite work as intended.

I’m not going to argue that layering on top of native form fields isn’t a viable progressive enhancement technique especially if there is a good usability case for improving the functionality. However to do it for purely design reasons ignoring the disadvantages of doing so doesn’t seem like the brightest idea to me. Stick what CSS can do and you can’t go far wrong, bring JavaScript into the equation and you’re asking for trouble.

Now I have to get on with some work, ah yes a lovely dropdown menu design sigh…

5f4dcc3b5aa765d61d8327deb882cf99

The average person may say a code of some sort? A slightly more techie person may say its an encrypted word? A even more techie person may even be able to identify it as an MD5 hash? And someone with moderate technical experience would be able to identify it as the MD5 hash of the string “password”. And that people is the issue, if you can easily identify the single string you could easily hack a lot of web sites.

A lot of websites require a login of some sort. You know the drill you’ve done it a thousand times, register for this site with an username/email and password. Some sites may go as far as imposing some password complexity rules, but a lot don’t, and you probably end up using the same password for every site you register for. This is an accident waiting to happen. Why? Well because when you register for a site you expect the developers of the system to be competent people who know what they are doing with your sensitive information. Let me tell you now they don’t, and it is beginning to scare me more and more.

Any developer should know at least one thing about security, don’t store the passwords in plain text. Simple answer encrypt them? Find a one-way hashing algorithm (such as MD5) and store them encrypted. That way if anyone got hold of the database then they wouldn’t know what your password is. But increasingly this is wrong, OK I’ve encrypted them using MD5, but as I’ve shown from the example above anyone who is stupid enough to use the password of “password” I know what it is, it may as well have been stored as plain text, and this unfortunately is true of every single word in the dictionary, and also unfortunately true of just about every random string of letters and numbers up to a reasonable length.

So at the very least if you are encrypting passwords add some salt to the beginning, end or both. Salt changes your 8 character password into 32 character+ passwords and makes recognising the password “password” much more difficult. That any developer friends is the very least you should be doing, add salt to your passwords please please please. But in reality you shouldn’t be using MD5 anymore, its insecure, and SHA-1 isn’t much better either but at least its a step up. My recommendation would be to set the minimum bar at salted SHA-1 encrypted passwords.

The reason for this is that I am getting more and more amazed at how many registration systems don’t do this. I’ve come across many a home grown system that just MD5′s the password, and even some fairly big systems, Drupal 6 being one of them!!!

And this is the problem, all it takes is a site of sufficient size getting hacked (like linkedin for example) who only use plain old MD5 and your password can be determined. Same password for most sites = trouble. And this is probably the case. Your password may only be as secure as the weakest password on the site, which is a scary thought these days.

So around Christmas time when I was trying to desperately come up with a good gift for my wife I turned to Apple once again and bought an iPad. The device doesn’t fit my needs personally, if I’m surfing the net then I want to do it on a fully functioning laptop. If I’m casually surfing, my phone suffices. For my wife however it did fit the need, I wanted a replacement to my wife’s ageing netbook and the iPad fit the bill.

I also had a sneaking suspicion that my one year old Adam would take to it as well. What I didn’t realise was how much and how easily he would take to it. Bear in mind that we are talking about a baby who cannot yet talk and has the attention span of a fly. He was instantly hooked, and in some ways obsessed with the device. It could keep him amused for minutes (a big thing for him)! He instantly got the interaction and was happily switching between apps and making noises, and turning the screen to flip it to the right side. Amazing really for someone so young.

Fast forward 6 months and whilst he still can’t talk (he’s getting there) his level of understanding of what the iPad plays is astounding. We downloaded apps that make animal noises as he likes animals and the education that the iPad has given him is brilliant. As the following video shows, he can identify animals I wouldn’t have believed possible for a 21 month year old. And he definitely hasn’t memorised the locations, they change between portrait/landscape modes, and there are multiple pages. He literally knows what an Elephant is, looks like and sounds like. The video doesn’t show it be he equally can point out flamingos, camels and crocodiles, not your average farm yard.

I never had anything like this as a kid, as obviously the technology wasn’t there, but today it is. I am filled with a sense of awe of what children today will be achieving in 20-30 years with a foundation such as what is the norm today. Technology is amazing.

Still there is always those odd occasions to deal with. Because they are so infrequent I have so far gotten along with hi-jacking a colleague’s PC and hoping its a quick fix. Of course this was never going to be a long term solution as its not always going to be a quick fix and it isn’t always going to be available to me. A more permanent solution is required.

As I saw it I had 3 options:

• Buy a test machine
• Purchase Parallells and a Win7 License
• Find a free option

The yorkshire man in me wanted to opt for the third option, after all I have spent a hefty sum on a Mac to do development, spending more money for the odd occasion irked me. Ultimately tho I didn’t hold out for a free option so have been looking to buy a test machine which could double as a machine for my wife. Only problem here is that if my wife has it and I need it then back to square one.

Well this morning I stumbled upon a tweet which looked like it could fulfil my needs. I’d heard of VirtualBox (and even had it installed) but the idea of subsequently having to install an OS such as Win7 seemed like more expense and a lot of hassle. Step forward Greg Thornton who has provided a wonderful script that does everything for you to get up and running with VirtualBox in kinda no time!

Visit Greg’s github page for instructions on how to install it on Mac, then be prepared to wait as it downloads a massive 4GBish of data, just to install IE9. But post install I finally had IE9 available on demand on my Mac for free.

There were a few things I had to discover post install to help with dev which I will detail below but its all available with a quick Google and certainly isn’t a complaint from me.

• Password to login as Admin was “Password1″ – this gets hinted to you on the login screen but still would be nice to be in the README file
• To access my Mac’s localhost, use the IP 10.0.2.2
• Hosts file needs to be edited as administrator, right-click on Notepad.exe and select “Run as Administrator”

And thats it, I was happily debugging an IE7 mode in IE9 without having spent a penny. The silver lining was that the money I was saving for a test machine I have spent on a shiny new 27in LED monitor :-)

I’m very late to the party here, CSS pre-processors have been around for a while now. I hadn’t looked at them for a few reasons:

• I didn’t want to learn a new syntax
• I was worried about source control
• I was worried I would become dependent on it
• The compile step may slow me down
• I don’t actually do a great deal of new projects, I do a lot of maintenance

I’m sure people who haven’t used css pre-processors probably would consider the above to be a pretty standard list, I’ve heard others like you can’t work remotely on a file that then needs compiling etc. Lets be honest though none of the above have that much weight really. Probably the biggest reason was that I was being lazy.

So when I got my last small project which was a 2 day max start to finish brochure site I decided to bit the bullet and go for it. I had a choice between SASS and Less to make, I don’t know if there is a religious war between these two but I chose Less for no other reason than I have used Twitter Bootstrap in the past. A big project like this which uses Less seems like a pretty good advocate of the system. It also gave me a ready made reference guide with real world examples.

I solved the compile issue by purchasing LiveReload which not only compiles Less/Sass on the fly it also refreshes your browser without needing to switch to it. I am not feeling the full benefit of this part yet as I mostly work from my laptop in a single screen scenario, which is less than ideal. But a quick tab back and forth is still quicker than a tab, Cmd-R. I thoroughly recommend this app.

As to learning the new sysntax, it took me roughly 5 minutes to get used to it. Mixin’s – a breeze, the nested structure – intuitive, variables – a god send. In short I can’t believe I hadn’t used it earlier it was amazing. I also downloaded Less Elements which was a handy starter library for common mixins, a great way to get used to them.

I still have concerns over source control, because in a multi-person team someone could edit the css file direct and then the less file is out of date. This is a communication/discipline issue however and should be addressable.

Did I grow to depend on it, well not yet, but I could see it happening easily. Even now when I am doing a maintenance task I find myself wishing I could use Less on it. Just like when I don’t have my favourite MVC framework available I have to slow down and think about things and wish I had a convenient wrapper library about some basic functionality. If anything not using it all the time means that when I use it again I will probably have to re-learn it, which doesn’t worry me in the slightest.

If you’re not using a CSS pre-processor I seriously recommend giving it a shot.