So I’m going to give it a whirl, it might be rubbish – but lets hope not.

However instead of posting on this site under an F1 category I decided to start a new site entirely dedicated to my F1 musings, to keep it separate from all the techy stuff I write here, so behold F1heat.com.

Hulu is a (US only) website which allows you to stream TV shows (in pretty good quality) to your computer via Flash, it has deals with some of the major US TV companies and has shows added very shortly after they are originally aired and seem to stay available online for a long time (e.g. much more than the 7 days you get with the iPlayer). You get very few advert interruptions, roughly 4 or 5 for a program that would run an hour on TV, and the adverts generally only last around 15 seconds or so, aiming to take the amount of time that you would normally spend fast forwarding through 3+ minutes worth of adverts if you recorded a program on your PVR.

It really is a top-notch user experience and it is the kind of thing that could really take off big, and from what I’ve seen of other services is the closest thing in to my In an ideal world thoughts when I wrote about the BBC iPlayer over a year ago.

boxee is a wonderful-looking piece of media centre software (which by the way is going to be running on my next media centre when I get round to doing that) that not only allows you to play media on your machine or from DVD’s etc. but also connects to some popular TV streaming websites — such as the BBC iPlayer, Hulu and more.

The "situation" is that Hulu has been forced by the content providers to not support boxee any more, their blog post on the situation and on the boxee blog for a start).

I personally don’t understand it, I assume that the TV companies don’t pay Hulu to support their distribution costs – so it probably costs them next to nothing — but will probably be currently providing them less revenue than traditional broadcasting. However why they see a difference between using a piece of software to make getting TV programs onto your TV a little bit easier than using a browser on the same machine really makes no sense.

This is the kind of thing that leads people to fall back to other almost-as-frictionless means of getting the same content we currently have available, which of course currently means torrents. And that is what the rebuttal on lifehacker basically says and shows you what to do if you were so inclined.

My guess is this whole situtation thing is because the media companies are currently doing deals with set-top box companies to make hardware to do the same thing as the boxee/hulu combination, but obviously with more control, more revenue for them and probably more adverts, more restrictions and a less polished user experience.

While that is working perfectly adequately for my current setup it does have one downside, when I setup a new server I will have to setup the crontab file too. With this method when I deploy my app my scheduled tasks would get deployed and be running out of the box. Nice.

I had been referred to a dentist that specialises in doing root canals, so this was my first visit to this dentist and he did a few things that showed he really empathised with his customer.

When I arrived one of the first things that the receptionist asked me to do was to pick a music CD from a list of 100, which seemed a little strange but I didn’t ask any questions.

What the dentist did when I entered his room really showed me that he empathised with people who had to undergo this (hour long) treatment. It included the following:

1. He spent about 5 minutes explaining the procedure in detail with me, explaining what each step would entail and what the goals of each step were and answered any questions clearly.
2. When he was giving me the injection to numb my mouth he gave me extra just to make sure – as my tooth had been causing me some pain before hand.
3. And here’s the big one. As I couldn’t do anything for the hour I was there, except sit still, the music "CD" I’d chosen from the list turned out to actually be a music DVD which he played on a plasma screen on the ceiling directly above me.

How considerate is that? Now I couldn’t hear it all the time, but most of the time I could, and in any case it gave me something to help pass the time and to think about/concentrate on during the hour I couldn’t do or say anything. If I’d know that’s what the choice of music was for I’d have spent a little longer looking at the list.

I don’t know if other dentists do this, as I have been with my dentist my entire life, or if this one came up with it all by himself, but either way it shows that he empathised with the customer and their situation by doing a few small things that made the process easier for me (and in turn probably easier on him too).

Advertisement: JavaScript Image Cropper UI Download my feature-rich JavaScript Image Cropper.

I also tried on different browsers and get the same issues – is anyone else getting this? Either way it’s a little disconcerting that a bug like this can find its way into Google, but also in its own way a little reassuring that everyone has bugs.

Update: Yep it appears to be everywhere, this TechCrunch story covers it.

Update: The BBC have a bit more detail, seems an import of data from Stopbadware.org flagged everything as dangerous – do you think someone updated the query recently and missed out the WHERE id = [id] part, I know I’ve done that on in dev more than once. :)

The solution we came up with was not too dissimilar to the one discussed in this months A List Apart article Progressive Enhancement with CSS and that article is well worth a read. But I also thought I’d write a little about the setup that we came up with and how it worked out for us.

The basic setup was as follows:

• Split the styles into their three components of the CSS make-up: layout, typography, skin (with the skin file containing the colour and graphics). As this kept things nicely compartmentalised and meant that we could re-use some styles from one site (e.g. the layout generally was the same for most content across all the sites) while applying extra changes specific to that site.
• The stylesheets were organised into directories based on the section (or sometimes specific page) of the application. So for example home/layout.css, home/skin.css, news/layout.css and news/skin.css etc.
• We could then also import specific stylesheets for each of our sites on top of these (both at a global and section level) which usually just overrode a few style declarations to keep these site-specific style rules to a minimum.
• All of this was managed server side using a configuration schema which knew where to look for the stylesheets for a given section of the application (as well as the global ones) and include them as appropriate for the given site.

We also had common comment styling for breaking the larger stylesheets into sections (which makes it easier to find things) and tried to alphabetise our properties within each style rule (although it’s not something that I personally could always stick to).

This was quite a good system, it may have looked complex based on the number of stylesheets that were imported for any given page but it worked out really well and we never really had any problems with our CSS system.

I’ve even used it on a few of my own larger side projects with minor tweaking to the system (e.g. dropping the configuration schema and following a Rails-like "Convention over Configuration" setup), and as I say it is very similar to the one described in the A List Apart article Progressive Enhancement with CSS — that has a really good idea for handling the different media types, which we handled via our schema.

It’s quite a nice idea and really well executed. What I really liked is the fact that they’ve obviously spent a little time designing this thing (both from a UI and functionality point of view). It’s really quite refreshing to see something like this appear in an era when most simple ideas I see like this end up running on a blog or a wiki platform.

So if you’ve got an iPhone head over there and vote, if you haven’t head over and take a look at the design.

I, like many others no doubt, thought that it was all based on the money that we deposit in banks; they invest some of that and keep some aside to let other depositors (and me) have access to some of that. But that still didn’t answer the question as to where the rest of the money comes from but the video does a great job of explaining it.

And if after watching that you’re not a little concerned then you must be a banker.

M: I was thinking about the event.setArg() method, and thought it would be nice if you could have it set the variable to session or cookies within the same call, e.g. event.setArg(‘name’,'value’,true,true), what do you think?

Me: I see what you’re thinking, but I don’t like it. I think that your code should be clear to you and others what it is doing and those true arguments don’t give you much insight into what they’re doing.

You’ve got to think about someone else coming to maintain your code, would they be able to see what it was doing without digging through to find the definition of event.setArg()?

Also how many times will you use it, and if not many, will you have to check the definition yourself to remind you which one is setting the cookie and which the session next time you see it?

So in the end I proposed 3 methods, the original setArg() method and two for setting cookie values & session values, basically a couple of cookie and session façades, and I think that’s what he went for in the end.

In my view the few times you’d want to set the same value to cookie and or session is very rare and the following example shows the worst case scenario where you want the value in all 3 places:

event.setArg( ‘myArg’, myVal );
cookie.set( ‘myArg’, myVal );
session.set( ‘myArg’, myVal );

It’s not the driest piece of code, but in my opinion much better than being presented with event.setArg(‘myArg’, myVal, false, true).

So that brings me to the title of this post, “Coding Clarity Over Cleverness”, the example with the extra façades for the session & cookie can’t really be any clearer in my opinion, it’s not the cleverest or driest solution but as far as readability and future maintenance in my opinion it’s much better. Presented with that code you probably wouldn’t even dig into the documentation or code to see what cookie.set() and session.set() are doing as it’s pretty clear.

The clarity over cleverness argument goes for any coding situation, you might hide some really clever code behind a method or function, but it’s name and signature should clearly show what it’s doing.

So the next time you come up with a clever solution, ask yourself if it’s clear what the code is doing if not then re-factor it so that it is.