I Really Don’t Know

luuuurvely

BBC via Clarke Ching via alan francis:

Internet portal Lycos has made a screensaver that endlessly requests data from sites that sell the goods and services mentioned in spam e-mail.M

Lycos hopes it will make the monthly bandwidth bills of spammers soar by keeping their servers running flat out.

Update: I did start to wonder if this was for real. I mean, there are probably laws that this screensaver violates – or should. But I took a look at what it’s doing. I turned on the logging on my firewall and it really does visit the sites, it makes several requests…

so, being suspicious I wondered if the domains might be bogus…

Domain Name ANYSOFT.BIZ
Domain ID D8128287-BIZ
Sponsoring Registrar GANDI SARL
Sponsoring Registrar IANA ID 81
Domain Status ok
Registrant ID O-876962-GANDI
Registrant Name Sergey Gachichiladze
Registrant Organization Sergey Gachichiladze
Registrant Address1 11, Ulan-Bator St.
Registrant City Moscow
Registrant Postal Code 117142
Registrant Country Russian Federation
Registrant Country Code RU
Registrant Phone Number +7.0957899432
Registrant Email whois@hqlists.com
Administrative Contact ID SG1094-GANDI
Administrative Contact Name Sergey Gachichiladze
Administrative Contact Address1 11, Ulan-Bator St.
Administrative Contact City Moscow

The screensaver appears to send junk messages such as:

<makeLOVEnotSPAM>6Ad;&o2RbS\{)Q&{q/<TN;z%?E|9uXv%%;m~C,dA}7.jGqD;|ym14Bck#N&aT[B+T</makeLOVEnotSPAM>
</TN;z%?E|9uXv%%;m~C,dA}7.jGqD;|ym14Bck#N&aT[B+T</makeLOVEnotSPAM></makeLOVEnotSPAM>.

So, surprisingly, judging by Starring, the company who came up with it:

Our business concept is to

help companies do things that give them something to say.

it appears to be for real.

The promises (and arrogance) of youth

I’m working on a product team building the next generation of a very large metadata storage solution core to library systems. I’ve been about 6 weeks now and have spent a good chunk of that time looking at the standards and protocols that are in use in the environment.

The first is “a computer protocol that can be implemented on any platform, defines a standard way for two computers to communicate for the purpose of information retrieval” – the ANSI/NISO standard for Z39.50. The interesting thing, having been working with web services since 1999, is that this standard was ratified in 1988 and by 1992 had a second ratified version. Even more interesting is that it is both more efficient than SOAP and delivers on 90% of the promises made by SOAP, which is probably more than SOAP does.

The second “defines a data format that emerged from a Library of Congress-led initiative that began thirty years ago. It provides the mechanism by which computers exchange, use, and interpret bibliographic information, and its data elements make up the foundation of most library catalogs used today”. This is MARC, MAchine-Readable Cataloging, and delivers a structured format general enough to exchange any data. The first definition of this standard was made by the Library of Congress in 19… 66.

Both of these standards (and you pass MARC records over Z39.50 if you want to know the relationship) were formed at a time when many of us were, in the case of MARC, not born and in the case of Z39.50 still at school.

Now, everything goes in cycles, but this is quite amusing. These are great standards that deliver on inter-platform and inter-vendor interoperability and have been established and underpinning our libraries for decades.

Wow, it’s way too easy to think our thoughts are new.

Advice for Interviewees

The signal-to-noise ratio of technical recruitment amazes me. The number of CVs I see where the technologies listed don’t match the must-haves of the job spec is astounding.

› Continue reading

Use Cases and iPod

Talking with some friends a few days ago we were talking about the value of use cases, amongst other things.

My product team are in the process of identifying user classes, looking at defining personas for them and getting really clear on the use cases required.

A colleague of mine, Ian Corns, is an excellent analyst, new to the analysis game and gaining a head of steam very quickly. He’s been reading Wiegers book on software requirements which appears (not having read it) to be very sound.

But I’m keen to avoid one of the main thrusts of processes like RUP and the Rational approach and also espoused by a new found friend of ours, Ian Alexander – Traceability. And that’s what we were talking about.

My previous employer, a services company, had a chief architect who designed an enormously contrived UML “world” solely on the basis that requirements should be traceable through to lines of code. Woah, what an idea. Maybe, in some world that I’m not living in that may be true, but I think it misses the point.

Product companies dream of having a product as successful as the iPod, people have talked for a long time about the apple factor and apple appeal. So the question is: Will you get an iPod if your focus is on Use Cases and traceability?

I don’t believe you will, I think you’ll get something very different. By isolating each use case and focusing on the traceability you establish the criteria that is being measured. And if you don’t measure what you value you end up valuing what you measure.

To make traceability measurable, use cases and their realizations start to form a one-to-one mapping. “I’ve done that use case, see here’s the screen” whether at the design or build stage.

But the iPod clearly doesn’t do that. The iPod has a set of capabilities – a wheel and a centre button that drive a very adaptive menu. The behaviour of the iPod changes depending on where in the iPod you are. Can you imagine the many-to-many mapping diagram for the use cases of an iPod and the components within it? It may not even be measurable.

My Creative Zen 60Gb player is a different story. You can map the use cases of that almost one-to-one with the physical controls. It’s horrible. I’ve hated it since the day I bought it (buy an iPod instead). The sound quality is awesome; it plays WMAs (of which I have many) and it’s only a little larger than an iPod. But it’s horrible: it takes two hands to use; operations often take several trips through the menu to achieve and it’s ugly.

How do Use Cases and traceability allow me to define a product that users will love, not just one that meets the use cases?

The answer, of course, is Interaction Design. As Alan Cooper so beautifully puts it in The Inmates are Running the Asylum, the whole industry is crap and interaction designers are the only people who can save us.

And I think that’s so true. Almost. Well, maybe, if you’ve had a beer or two.

But the point he raises is very real. So many of us work in environments where a requirements document is handed to a developer to work from. In some cases an architect may have pinned some technical constraints or ramblings to it, but broadly speaking there is little or no Interaction or UI design.

So, why do we get crap instead of an iPod? Rhetorical Question.

New Toy

Last weekend saw an impulse purchase of Canon’s new EOS 20D Digital SLR. Well, hardly impulse actually. I’d been thinking about buying the 10D for some time, but had never quite convinced myself; then I heard the spec for the 20D, jumping up to 8 mega pixels. I’ve checked and they’re all there.

› Continue reading

in cahoots

This morning’s news includes an item about Internet bank Cahoot, run by the Abbey. Internet banking is something I know a little about, and listening to Tim Sawyer, head of Cahoot, had alarm bells ringing.

A wonderful quote posted on the BBC has Tim saying “We did not fail as an organisation because there was no risk of financial loss…”. I wonder if Cahoot customers agree? Or the Data Protection Act?

If you walked into a bank and asked for a balance on accounts you’d be asked for ID and if you weren’t it would be considered serious, so why does Tim not think that this was a failure? The bank’s legal responsibility is not only to protect your money, but also your information.

He also went on to talk about how, in order to see someone elses account details, you’d have to know their “confidential” customer identification. One of the commonly misunderstood fundamentals of username password systems such as Cahoot’s is that the username is not part of the secret. You have to assume it is known. I hope this was just bluff and blunder by a non-detail management professional rather than Cahoot’s real security model.

But more worrying is that bugs like this (which was a very simple breach) show that the developers working on this “browser based secure internet banking application” are actually building it in the same way they’d write a guestbook for their geocities homepage.

One of the problems of the web is that the barrier to entry for simple sites is so low, yet the complexity of writing genuine browser delivered applications is very high. Akin to writing complex win32 apps and certainly more complex than writing windows apps in VB.