The iPod Nano (the crap one)

I've not tried one, but initial impressions aren't good. It looks ugly. A touch interface feels inappropriate with such a small screen.

All of the 'but for a little bit more, you can get an iPod Touch' harping, though, just reminds me of when the iPod mini was introduced, and people all said it was stupid to save a few quid when a full sized iPod has way more storage.

I think if this nano fails, it won't have anything to do with price/features, it'll be because it's a bit ugly, and difficult to use.

The new iPod nano is a fifth of the weight of the new iPod Touch. (≃20g vs ≃100g)

The new iPod Touch is almost five times the volume of the new iPod Nano. (2.8 cubic inches versus 0.6 cubic inches)

I guess the iPod Nano is the gym iPod. It's small and light and has a clip. As such it's certainly more niche. I'd expect far fewer sales of iPod Nanos versus iPod Touch, but that doesn't mean it's failed, it just indicates how the market has segmented.

Hywel's Law

The grammatical correctness of an email request for tech support is inversely proportional to the stupidity of the question therein.

That is all.

Tefal Quick Cup

A year or two ago, our kettle broke. We got a Tefal Quick Cup to replace it. Just the right amount of water is heated as it passes through an element, meaning you only heat the water you need. It also dispenses cool filtered water. What's not to like ?

What's not to like:

1. The 'cool' water is room temperature, which is hardly cool on a hot day. If you want cool filtered water, get a water filter jug and keep it in the fridge. If you want cool water, get it from the tap.

2. 'Cool' water remains in the pipe/element until the next time you use it. This means that you get a small amount of cold water in your cup. The workaround is to start the hot water for a second, stop it, empty the tepid water into the sink and then start making a drink. If you forget to do this it makes instant black coffee even more disgusting than it normally is, and white coffee undrinkable. Tea is a disaster. Coffee in a cafetière is just about OK, except ours doesn't fit under the Quick Cup's spout easily.

3. Tea is a disaster. Boiling water plus teabag in a mug may be against the law, but it's how most people make tea these days. While it's not as nice as making it in a warmed pot with a little patience, it'll make a fairly decent cuppa. WARNING! DO NOT MAKE TEA WITH A TEFAL QUICK CUP! No. Seriously. Don't do it. It'll be like American tea, where you get cup of warm water and a teabag on the side.

4. You'll need a kettle anyway. Being impatient, we ended up buying a cheap kettle anyway, for boiling water to make pasta etc. Turns out it's good for tea as well.

5. It feels more inconvenient. If you're making one cup or two, it's probably better. Making four or six or eight makes you feel like a galley slave. Worse though, is that it engenders an entitlement to instant gratification. Whereas with a kettle, it's automatic to fill it to a desired level as you put it on, with the TQC, it's automatic just to hit the button. Fine if the reservoir is full, but SO UNFAIR if, mid cup, it starts spitting out steam and coughing.

6. It dispenses a set amount of water. This is mostly a convenience. Press once, get a mug full of water. Not all of our mugs are the same capacity, so some get dangerously full and others pique the pessimist in me and seem half empty.

7. It dispenses a set amount of water, but with no intelligence, and it encourages a lack of attention from the user. Press the button a second time, and it stops. Press it again and it'll yield a whole mug's worth again. Usually not a problem, but if the reservoir runs dry, and you're forced ALL THE WAY across the kitchen to fill it up, when you poke that button, you get a full cup's worth. If you're not paying attention, that could be half a cup's worth of dilute coffee all over the work surface.

8. It dispenses a set amount of water. See 4 and 5.


In summary, this is what it's good at:

1. Instant black coffee, as long as you remember to purge the spout.

This is what it's bad at:

2. Everything else.

Buy a kettle instead.

Postcode Search Usability Fail

[RANT]
When searching online for goods in stock in nearby stores, I get really wound up by having to put in a full postcode. This is normally mildly annoying, in that I know my own full postcode, but there are some places for which I only know a partial postcode.

Example: I live in Kent, but work in Hampshire. The local Argos doesn't have stock of the printer ink I need, but it is listed, and is available for home delivery. PC World, Comet, Curries, Tescos, etc, no longer stock the ink.

I attempt to search the Basingstoke store. I enter "RG21", which I know is the town centre. It's rejected because it's not a full postcode, even though an area postcode should be sufficiently accurate in this instance. Grrrr!
[/RANT]

Functional Testing Tools.

This week, I've spent a fair amount of time reading about functional test tools. Both for automated testing, and for manual testing, for two different projects.

I don't know what it is about tools for testers, but they feel terribly prescriptive and constraining. We tried Seapine's TCM tool a couple of years ago. The idea was to replace our slightly flaky Excel based scripts. It was chosen because we use Seapine's defect management tool, Test Track Pro, and it made for an integrated solution.

Test Track Pro is fine. I don't think we get much out of it that couldn't be achieved with Bugzilla or a hundred other defect management tools. It's not perfect, it's not simple enough for my tastes, but it's reliable and does what it needs to do.

What happened was that I spent a couple of months writing macros to convert our Excel scripts into a form that Seapine could handle, and using their SOAP/WSDL API to write a Java utility to inject the scripts as new test cases. I also spent some time writing another utility to generate a project status summary using the fundamental metric we measure against, which is number of test steps. It's not a particularly good metric, with tens of thousands of steps, we have a good feeling for how long scripts take to execute.

We also tend to write very long scripts, some with many hundreds of steps. It's probably bad practice, but it works for us, and historically, with no TCM, it was easier to manage a few long scripts rather than many short ones. I've written some fairly extensive VBA macros to make the scripts manageable. It used to be a manual task to clear results prior to a new test run, for example, but that's now one click away. Other macros allow steps to be included or excluded from a test run quickly based on context (e.g. enable different steps for hardware keyboard and touchscreen, or disable steps for deprecated devices). These macros were written, fundamentally, to save us time. They're written by the testers for the testers.

Trying to use a COTS TCM solution after being used to this kind of freedom was a nightmare. A few of the testers never even got started. I was quite enthusiastic, but other than a trial project, to prove the feasibility, it never got adopted.

Developers don't put up with these kinds of tools, and neither should testers. I think a lot of the test tools are designed by process nutjobs. Managers writing requirements for they way they think things should work and implemented blindly by developers, but the users, the real world testers, don't get enough say. It's a shame.

On the automated test side, things look a little better. I think it's because there's more developer influence. A lot of developers will want to use the tools themselves and their ideas get incorporated. In terms of web testing, there's plenty to choose from. Selenium and Watir seem to be top. Selenium's IDE for recording scripts is nice and simple, and the ability to convert these to Java or Ruby or Perl of Python means reusable modular tests are nice and easy to write. The problem I have is that I need to test Java. Specifically in-browser applets. Selenium can apparently do that through FEST, but on reading the instructions, I really can't be arsed, I'm not convinced that I'd actually get it to work at all.

The two front runners in this contest are HP's Quick Test Pro and Froglogic's Squish. Squish would let me use Python, which is a massive win, it's Eclipse based and the object lookup appears to be astonishingly good (from the demos). Froglogic have loads of information available on their website, including the user guide, so I can really find out about how it works. HP's on the other hand seems impenetrable. Quick Test Pro really is the industry standard, it'll look great on the CV, but it'll mean a VB-like language, which is a real shame. Head says QTP. Heart says Squish.

Inception (no proper spoilers)

When I say no spoilers, if you read on, you may read something that makes the film less enjoyable, but there are no plot giveaways.

I don't get to the cinema often these days. I'd not heard of Inception until last week, when it was decided that I should take my twelve year old son to the cinema. He wanted to see it, it looked above average and so we went.

I think it was the first film we've seen together at the cinema that wasn't a kids film. We enjoyed it, we talked about it on the drive home. I thought the end of the final scene, just before the credits, was great.It made for a nice few hours of quality father-son time.

Two things distracted me. A phone rang. I was drawn out of the film, back to the theatre, frowning in the direction of the offending sound. But it was in the film, not in the audience. I've no idea how film-makers are going to deal with that problem.

The second distraction was Marion Cotillard, who plays DiCaprio's wife. She's simply ridiculously, compellingly, extraordinarily beautiful in this film. Whenever she was on screen, I simply forgot about the film.

So, decent enough film. Gets the brain working a bit, but it's not difficult to follow if you take Kermode's advice and don't go to the loo. My son loved it. It looked stunning.

This week, I've had the luxury of being able to read some of the criticism of it. I could argue that they should get off their high horses and enjoy it for what it is, but they all seem to have a point: There's way, way too much exposition. I can't see how they'd strip out all of it, but it's a film that explains itself far too well and leaves the viewer with (almost) no questions.

I've not thought about the film this week beyond just one niggling technical question (to which I think I know the answer). If it had been made without explaining itself as it went along, I'd have been begging friends to see it so that we could talk it through and try to figure it out, argue theories.

It's not going to stand the test of time.

Please say what I'm thinking.

Was just reading Matt Gallagher's Is a virtual machine for Cocoa programming inevitable? on Cocoa With Love. I subscribe, but often don't read a lot of the posts. They're too technical for my current ability and level of interest. I want to be more interested, but I just don't have the time/inclination at the moment. I'll be reading every word of this one because I kind of hate C.

I read the introduction wanting Matt to say what I was thinking, which is essentially that C pointers suck. There are other things I dislike about the language, the curly braces and the misuse of '=' for assignment and '==' for equality, for example, but much of this is cosmetic. The pointers are a deeper issue, although there is a element of cosmetic unpleasantness about them too.

What was I thinking ? Well, in Matt's words (Yay!) :

More relevant in the long term is the one feature that Objective-C can't remove or fix: complaints about C itself, in particular C pointers.

Even though this isn't the point Matt is making, I'm reminded of Robert B. K. Dewar's lectures on Ada. I've embedded part 3 below (will remove if requested to do so)…

The key thing to take from this is the rigour of the Ada compiler compared to C, the cost of finding defect at compile time versus runtime and the amount of time spent in debugging in Ada compared to C. I'm not saying Ada should be used instead (it shouldn't), but C in particular lets things through to runtime that are going to be a bugger to find and resolve. The nature of Cocoa, object based and dynamic is a much better fit to Python. If a virtual machine is proposed, a language like Python would be much more suitable.