"You look a lot cooler on the website...."

Last night's London CFUG had a good detailed introduction to Model-Glue and Reactor from Mark Drew, and a good-as-ever beer session in the pub afterwards. I'm intrigued by Model-Glue, and I'm tempted to give it a go on a medium-size project that I'm prototyping at the moment.

However, at the moment I'm unsure as to how well it will scale in terms of project size - with one central XML file controlling your config, is that going to turn in to a real headache when you have 500+ events and four developers working on it at the same time?

I had similar concerns about Mach-ii also, until me-old-mucker Martin Laine told me how he was managing this complexity in a cunning way: they split the XML file into several smaller, section-specific segments, which were held in the subdirectories of the project. They then set up an event gateway on the dev server watching these directories for changes, and whenever a file changes, the gateway aggregates all the segmented files into the root mach-ii.xml.

Very cunning - but it still feels to me like a kludge. Surely there is (or should be) a way of doing this within the framework itself?

Most memorable line of last night, however, came from Kola Oyedeji and Mark when, after nattering over several pints, m'colleague Neil Roberts must have told them my name for the first time, as they turned to me and said something to the effect of :

"Oh you're the Instant Badger guy?! I read your blog all the time!"

Cue me feeling warm and fuzzy - then it was followed with the immortal line :

"I didn't recognise you - you look a lot cooler in your photo on the website!"

Hah! You've got to laugh. It's true, of course... I look a fair bit geekier in RealLife™ when i'm wearing specs instead of contacts (or shades).

I thought there was only one thing to do with that line -

Blog it!
Blog it HARD!

Hence this post. Hi guys :)

By the way - that photo in my profile box was taken in June 2004, in the middle of an interminably long queue for the Louvre in Paris. We were sandwiched inbetween a gaggle of rather small nuns behind me, and a couple of young French lesbians who were not exactly being discreet with their affections -

I have never felt more like Father Jack in my life....

Contextual Carrier-Waves in Communication - where AdSense fails

In GMail just now, I was responding to a mail inviting me to a college reunion, for the tenth anniversary of our graduation. It was a chain of 6 fairly chunky emails, and the word "Anniversary" was mentioned just twice in the whole conversation.

However, all the adsense-driven adverts down the side were completely inappropriate - it seemed like adsense had pounced on the word "anniversary" and decided that that was the most important theme of the content.

To give a couple of examples, the contextual ads included such gems as:

• "Inscribed Stone Sundials - An inscribed stone sundial makes a perfect gift for a special occasion"
• "Give him a framed share of Playboy stock + others for your Anniversary"
• "Original and Genuine Newspapers Ideal Birthday or Anniversary Gift!"

This is a shining example of when all the complicated semantic processing algorithms in the world are no substitute for actual context.

AdSense is usually pretty good at serving relevant ads on blog posts and webpages in general, but it seems a good deal less accurate in GMail. I would have expected far more ads related to college and graduation, or even parties or Durham - as these terms were much more prevalent in the actual text.

Thinking about it a bit more, I realised that there's a deeper issue, which is probably inherent in the nature of the communication mechanism.

Blogposts and web content in general are usually designed to be "broadcast" communications - one-to-many. Each page, or "message", is - or at least, should be - designed to stand on its own, and provide all the context required to interpret the communication in and of itself. When you are broadcasting to a potentially huge number of people, you must be clear, concise, and comprehensive.

Email, on the other hand, is generally one-to-one communication, or at most, one-to-a-small-group - certainly under the famous Dunbar Number. In this case, there is a lot of implied historical / social context in the communication:

• you usually have some sort of existing relationship with the person you are emailing.
• If you do not have a historical context (e.g. as with a job application) then the communication is usually much more formal, as it must provide all relevant context in itself.
• If you are, or have been, part of the same social circle as the recipient, then that social context itself implies both a mode of communication and a certain terminology, plus a whole frame of reference in terms of shared experiences, etc.

In other words, the "signal" (message) rides on this contextual carrier-wave, and this enables the message itself to be much shorter than would otherwise be the case.

By contrast, a stand-alone message such as a blog post or whitepaper must carry itself - the context must be set by the message itself, to enable the random sampling of information that is the power of the internet as a medium.

So when this large amount of contextual information inherent in one-to-one conversations such as email is missing, a contextual semantic detection system such as AdSense is always going to be limited in its effectiveness.

...Unless, of course, it gets to the next step of deriving the context from the history of messages to and from that particular contact - but it would be interesting to see how well such a system would fare, given the Orwellian fears it would be bound to stir up... and looking ahead to Web 2.1 or even Web 3.0, I feel that one of the key battlegrounds is going to be that balancing of functionality with privacy.

After all, Google are already starting to skirt the borders of what's considered acceptable, and whoever manages to get it "right" stands to do very very nicely indeed...

Not Quite Infinite Monkeys

You've all heard the hoary old line to the effect that an infinite number of monkeys at an infinite number of typewriters would eventually produce The Complete Works of Shakespeare by pure chance. Well, turns out someone has actually tried it - and not with a computer simulation, but with actual monkeys...

Notes Towards the Complete Works of Shakespeare is following the output of 7 Sulawesi Macaque monkeys at a keyboard, with a webcam feed and - coincidentally - a publication that you can buy for £25.00 + shipping.

So - is it science? Is it art? Or is it bollocks? You decide...

Slashdot Effect Claims Another Big Scalp

Well, I'm back from a fantastic climbing break in the Welsh mountains, and it's nice to see that it's not just our server that couldn't handle a full-on Slashdotting - even Sun have the same problem

Rock On

Excuse the off-topic post (I think it's my first..?) but I'm going away for a few days to go rock climbing in Snowdonia with Lise, so I won't be responding to comments for the rest of the week. I know there's a few CF-ers around London who also climb, so I'll be sticking the photos up on Flickr and any videos on the rather wonderful YouTube when I get back.

How "Big" Is A System?

Recently I was asked by a consultant to estimate how "big / complex" a proposed system would be, compared to some of our others. This prompted an intriguing debate - how can you actually define how "big / complex" a system is?

Number of CF files? That depends on the methodology used - a Fusebox app is going to have more files than a page-based one.

Size of CF code on disk? Again, not really a reliable measure - more code might just mean less efficient programming ;)

Anyway, we ended up doing a couple of quick reg-ex extended searches through our codebases on two of our flagship systems - the NIMHE / CSIP Knowledge Community, and the Big Project, which I would link to, but I'm not even allowed to NAME it yet, never mind tell you where it is - to get some counts.

The KC has been incrementally developed for about three years, and the Big Project was started in February this year. Both have a Fusebox front-end with a CFC-based object model at the back-end, and I found it interesting to compare the two :

Project	DSP files	Custom Tags	Fuseactions	CFCs	DB Tables
KC	324	4	679	98	129
Big Project	105	26	174	200	50

Now, in our own heads, the two systems "feel" more-or-less the same level of complexity, but a couple of things leap out of those figures straight away -

* The KC has a colossal 679 fuseactions, which it services with 98 CFCs.
* The Big Project only has 174 fuseactions, but twice as many CFCs (200) and 26 custom tags

This is a reflection not only of an evolving methodology - on the Big Project we've moved our object model from an item/itemmanager model to a bean/controller/DAO/gateway model - but also of evolving technology.

Thanks to a liberal spattering of Creamy AJAX Goodness™, we've been able to handle things like tagging of items almost entirely within a custom tag, plus a couple of very simple fuseactions to handle the AJAX requests. You can add and delete tags without having to refresh the whole page, and as a consequence, the app feels much more responsive. This is one of the areas where AJAX can really help - provided, of course, that you're not going mad and doing whizz-bang stuff just for the sake of it.

Also, we took the decision this time round that we were going to encapsulate as much of the business logic as possible - permissions checking, etc - within the controller methods, and the bean-with-private-data model enabled us to do a lot of the core validation within the bean itself. This has the double bonus of ensuring that there's no way that invalid data can get into the database^** and it removes a lot of the tedious checking code from the front-end fbx_switch files.

I'll blog more about the approach we used and the framework we worked out in a separate post - it took a bit of time and discipline to make the switch over, but we're very very glad we did.


^**well, OK, no easy way... you can never make anything completely un-hackable, all you can hope to do is make it not-worth-the-effort :)

BBC Innovation Labs: What We Have Learned

We're now back at Headshift Central, having spent the weekend in our various forms of recovery, and now the dust has settled we're still excited about having won a commission - an agreement to fund four weeks of work to get our idea to a demonstrable prototype.

The announcement of the final results was pretty tense. After considering their verdict for about 45mins, the judges led everyone back into the hall, and Jem proceeded to go through the projects one-by-one, announcing the flaws and issues he had with it, and whether or not he was going to fund it.

When it came to our turn, we were fairly sure that we weren't going to get it - slicker presentations than ours had already been turned down, and the summing-up seemed to be a string of "You should have thought of X, we weren't sure about Y, you didn't do Z..." we were pretty much resigned to going home with some good contacts and great insights into alternative ways of working and the idea development process, but without a contract..... however, he then finished off with "but what the hell, I'll take a punt on it - we'll take it forward"

Out of the ten teams at the London Labs, four got funding - one more than either the Manchester or Yorkshire labs - but I think what we gained out of the week is far more valuable than the actual contract.

• We like the idea of using the pitching process internally - the Good Cop / Bad Cop method was particularly effective at exposing holes in the idea that might otherwise get glossed over
• We're more convinced than ever of the value of user persona analysis
• Wednesday's session on "making it BBC-shaped" was a real eye-opener - it's an oft-forgotten but vitally important part of any pitch - why should THIS company in particular be doing this, as opposed to any other company?
• Guy Kawasaki's The Art Of Pitching is like a safe anchor in a storm - when you're in a panic over an impending presentation and you really can't think how to get started, listen to this, and remember the golden rules. If nothing else, the soporific tone of his reading style should help you calm down...;) He may be a shameless self-promoter - but isn't that what you're trying to do with the pitch?

Best tip for presenting (again from Guy K): "So What?" ... "For Instance..."

Late on Thursday, we took Riks amorphous knitted puppet, previously named "Nagging Self Doubt", and gave him the job of "So What?" guy - the idea being that every time you make a point, or say something about your idea, he says "So What?" - why should I care? And nothing answers a "So What?" better than a "For Instance..."

To give an example -

"Our hearing aids have Digital Signal Processing"

So what?

"This lets us increase the clarity of sound."

For instance:

"For instance, if you are at a cocktail party, with many conversations going on all around you, you'll be able to hear what is being said to you."

Guy K reckons that "For Instance" are the most powerful two words in any pitch - and I would have to agree. Try this method yourself, be a real sarcastic sod, and try to find the holes in what you are saying. Get someone else to sit there and practise your pitch to them, asking "So What?" at every point you make. The difference it can make to your presentation is quite amazing.