From Ben Metcalf:

Opera licenses sans-adverts, gratuit... get 'em while they're hot:

http://my.opera.com/community/party

There's clearly not the same hyper-networking amongst the UK Web2.0 community as there is in the Valley and I was surprised that more people didn't know about the Flickr workshop. I'm always grateful to find out about new events so for those who don't know a couple that are about to come up are:

Our Social World - 9th Sept - Cambridge - £100
British Podcasting Event - 17th September - London - free

If there's anything I've missed then please do tell me.

Saw this linked to by the O'Reilly blog - very cute :)

Southpark meets Google:
http://channel9.msdn.com/ShowPost.aspx?PostID=104073

Last Thursday saw me head up to Kensington to listen to the wisdom of Cal Henderson at Gillian and Ryan Carson's Flickr workshop. The day was cheap by corporate standards (£300) but a pretty big hit for a single developer though nonetheless worth it. The title was "Building Enterprise Web Apps on a budget" and those sort of talks don't grow on trees around here so it was well worth the trip.

As always, it was really good to meet other like minds - Ryan's a man after my own heart and I'm really pleased that he and Gillian are doing so well, Ed didn't turn up till late evening but it was good to see him and also John Hornbaker who has just landed from the states. I was also lucky enough to chat with Gareth Knight, the MTV guys, some of the Skype-kids and Tom Dyson from Torchbox, who I haven't seen in a long while.

Cal, gave a really solid day of talks and some really good insights into the issues surrounding clustered databasing and the realities of Web 2.0 development - good day - good job. A big thank you to Cal, Ryan and Gillian and look forward to bumping into everyone again soon.

I'm going to switch the tone of my blog from being a place where I publish my thoughts to a thought-train. There's a load of stuff that I'd like to share but writing my usual type of post takes me about a day and really conflicts with my real (aka code) writing.

Ultimately, this site's going to be completely revamped and will become an outlet for a number of different feeds but that's going to happen inline with the release of the software I'm developing so not for a little while yet. Meantime I'm switching to news-node style which means you may well have seen much of what I'll post elsewhere in the blogosphere.

Exhausted after working late last night, I fell into the sofa to watch Double Jeopardy. I've seen it before but back then I was still in college. That first time round, the part I found hardest to swallow was Ashley Judd's fall from society after the conviction of her husbands murder. In an instant she goes from being the hostess with the mostess to simply most wanted.

Watching it last night I didn't feel myself shocked so much as empathetic. I'm on no murder charge but I sometimes feel as distinct from my peers as if I were. Developing a product on a shoestring isn't fun and it isn't glamorous. Ask James Dyson, he spent ten years doing it.

Today, Dyson is one of the richest and most significant business people in Britain. Eleven years before that he was a significant and an accomplished designer. For ten years in between though, for ten whole years he was a man making cardboard vacuum cleaners in his dining room.

A few years ago, I read his autobiography and wondered at how he held it together in the face of such cynicism and isolation. I didn't think that I would ever be able to hold out like that.

Well, I'm not sure that I could but it's coming up for two years now and at least I'm getting an idea of how he felt. I also begin to know how he kept it together. He knew what he was creating and he knew its potential. He knew that there was no guarantee of success but he knew his concept was better than anything that currently stood.

It's not easy to hold that type of belief, especially when others don't. A lot of people ask why something that's apparently so special hasn't already been done. It's a smart question when what it is asking is, "how will this succeed". It's surprising though how many people ask because they they genuinely believe all the smart things have already been done.

Sometimes even smart people cannot conceive of improvement and have 20:20 but entirely retrospective vision. When Hoover told him that he was onto a non-starter all Dyson had was his own belief and confidence in his product. Remember, Rocky wasn't Rocky until he beat Apollo Creed, until that happens he's just Balboa.

Confidence is all anyone who takes this gamble can hope to have and it's all that keeps us going. That and our friends and relatives. Even they though, ultimately feed from our vision which itself feeds from our belief in what we are doing. In the end, it's all about the product.

Some of us will be right and some will be wrong. Some will be right but have terminal execution and some will be wrong and get lucky. Any which way, the most significant things will not be iterative and will have taken time to make. Mutation is quick and easy but design is not. Anything can mutate but only humans design.

Every morning, after showering and before breakfast I go for a short walk. I walk down to Parson's Green at about the same as the commuters are setting off. Everyone goes in the same direction, towards the station and I walk with them, part of the crowd. Once there though I loop around and come back.

On the second part of my journey, there is no crowd. On the second half I see peoples faces not their backs. Occasionally I also see where they look and guess at what they're thinking. Mostly they're concentrated on walking fast or listening to music but every now and then I see a flicker of confusion. Every now and then I can see someone wonder why it is I'm walking away from the station and not towards it with everyone else.

Terrible news today that things were perhaps even less incriminating than was first thought. It's now reported that Jean Charles walked into the tube station, bought a newspaper and then went and sat down on the train. After a policeman jumped him and bound his arms to his side another leapt in and fired a volley of shots into his head.

Terrible that an innocent man should lose his life in an accident that was of human hand. Terrible that this should have been anything less than unavoidable. Terrible some may now rightfully feel fear of nervous armed police.

It's also terrible on a different count though too. I'm ashamed of some of our press. Not all of them but definitely some. One of our TV channels is painting a picture of a conspiracy to delay the investigation into the death by Sir Ian Blair. They talk of how he requested the investigation to be delayed and they have testimony from a solicitor saying that such a delay would be very damaging and is very unusual.

This makes me angry.

It seems surprising that people should need to be reminded but on the day before this shooting, five men had proved their intent to blow up tube trains. After doing so, they melted into the streets of London to regroup.

Policemen and women were working round the clock to find those terrorists. Policemen and women were working round the clock to stop five men before they used the lives they had committed to terrorism to tear apart the bodies and the families of more of London's commuters.

Ian Blair wasn't chosing betweent the efficient execution of a police enquiry and a perversion of justice. He was chosing between the lives of the public and a police enquiry. There was no choice to be made. As a direct result of these efforts and only weeks later, all bombers were in custody.

Anyone who choses to paint a picture of Sir Ian Blair as a subverter or criminal should carefully consider the position they are carving for future police commissioners. If Sir Ian has to resign as a result of this we will all be the poorer for the loss of a good man. We will be poorer still for the loss of capacity in a role that exists to protect the public.

To the individual reporters of those networks. You have been given influence. You may have earned your position but that doesn't mean you've earned that influence. You may ignitite calls for resignation and that may get you your fifteen minutes and your position away from daytime TV. Enjoy your new evening slot. Be proud but also know that if people die as a result of our inability to defend ourselves, it will be you who laid the path.

This is a very difficult and sensitive topic and needs to be approached with the balance and restraint that most of the press have shown. To those that haven't, I am ashamed of you.

My last post ended up sparking off an interesting discussion with Nick Fessel about the architecture for rich internet apps. We got onto the topic of Flash and its potential in a web-services environment.

Well anyhow, Nick pointed out some reallly interesting links to both Flash and Ajax apps which you can go back and look at but which I won't reproduce here to make sure you do.

Nick - I had heard of Laszlo before but never knew what they did. One thing I do know is that you can still produce their type of applications (albeit perhaps without their backend) using standalone Flash. I know it's not cheap to buy MM Flash but you don't actually need all the rest of the shenanigans. The Rico suite was very nice, it reminded me an awful lot of the scriptalicious libraries - have you come across them?

So what do other people think? Finally and thankfully it seems that rich internet apps are going to take off, what do you see becocming the dominant architectures?

A post I put up on the comments of the O'Reilly blog and which I'd be sorry to not put here:

When I first heard of the web in ’95, I thought a lot about the consequences of networking the computers sat on every desk. I heard talk of how that virtual-proximity would remove barriers to information-flow and leverage many hands to make light work of large problems, how new communities would form and ideas be exchanged. All of this was true but not nearly as much I expected.

For most people, the true potential of online communities is something they read about only in the Sunday newspapers. Dave Winer may be sought out by readers in every village he visits but for most people it takes years to reach out in even a city and retirees and young mothers find themselves sometimes unbearably lonely once isolated from those physical networks.

For the majority of people, the human-networking potential of Web1.0 never emerged. Everyone uses the web but ask most people what they do with it and they’ll tell you that they use it for shopping, email, research and news. For the man in the street, the internet revolution was arguably less of a revolution than an evolution.

Web1.0 explored what was possible when we took out the human middle-man and allowed our computers to connect direct to computers and data in other networks. It was about what became financially and technically possible when we no longer needed a remote operator in order to interface with a remote machine or a physical network to deliver remote information.

That’s not to say that machines couldn’t communicate before ‘95. Be it counting handle-turns or pulses of light, machines have always had a language of interaction. Nonetheless, the creation of one common language (or triumvirate of languages) lowered the barriers sufficiently to mean more people and machines chose to connect. At the same time, servers allowed those machines to safely expose useful data from their vulnerable interiors to the world at large. More information and lower barriers created more entrants, more entrants created more still and Web1.0 cascaded into existence.

Humans have always been able to communicate and network but when we look to our virtual networks, the lockin of email and the hassle of publishing and reading has kept most of them ultra-private and defensive. Those defence mechanisms are so strong we will sooner reject an email from a friend than let risk spam and even when we want to, we will sooner sit in alone and in silence than chance an interaction with a stranger.

Humans are the network that Web2.0 connects and RSS is the common language. RSS is to conversation what TCP/IP was to data and blogs are to humans what server-software was to computers. We have always been able to communicate but RSS makes it that little bit easier and more reliable. RSS lowers our threshold to reading and hence raises our audience for writing whilst blogging allow us to put a little bit of our sensitive data outside our personal firewalls and to give others something to interact with. We all start to realise that giving a little of ourselves can bring far more in return. More interaction breeds more ideas and RSS and aggregators give those ideas a network they’ve never before known.

TCP/IP was DNA for data on a network, it charted its delivery and guaranteed its integrity. XML and RSS are fast becoming the DNA for ideas on a network. Words become nucleotides, items become genes and just as with real genes, we are the vehicle to take the best of them to the next generation. Some survive, some multiply, some will be lost and some will never get read but one way or another, RSS lets them evolve faster than fruit flies.

The blogosphere is the detailed transcription of an entire population’s intellectual DNA, an exhaustive textual, audio and video description of the ideas and emotions of a community. The blogosphere and what it will evolve into become not just the zeitgeist but the very definition of the human state. If the handbook for the revolution is Surowiecki’s excellent “The Wisdom of Crowds” then note that the blogosphere is the crowd - ignore its wisdom at your peril.

Where Web1.0 allowed us to connect to remote computers without an analogue call centre worker, Web2.0 allows us to connect to remote people without an analogue journalist. Despite what’s bandied around this don’t mean we’ll dispose of all journalists and publications any more than online news meant we disposed of newspapers. There will be change for sure but good journalists add value far beyond the information they transcribe and those who think it’s all change are more naïve than those who believe it’s none.

Some argue that Web2.0 really isn’t an event - it’s incremental and undeserving of a name. In some ways they’re right. 2005 and “Web2.0” isn’t where rich human networking started any more than 1995 and the “Information Super-Highway” were where computer networking started.

“Web 2.0” applications were around long before today. EBay was 2.0 and so were Citeseer, Friends Reunited and P2P. Spam email may have been 1.0 but the “I love you virus” is 2.0. Amazon isn’t a 2.0 company but its reader reviews were. Page rank wasn’t a Web2.0 application though auctioning Adwords certainly was.

So what is it that makes Web2.0 a big deal? It’s a big deal because people say it’s a big deal. Lots of people. Lots of people are blogging, lots of people are tagging and the number grows almost exponentially. When a lot of people do something one month and twice as many people do it the next month, it makes it a big deal. The participation in Web2.0 has grown well beyond the founders-circle and shows no signs of slowing down.

And why give it a name? Well when lots of incremental things start happening in a short space of time and when those incremental things build into a qualitative change of state we need a way to distinguish the new one from the old one. Web2.0 seems a very apt descriptor for where we are about to arrive.

Tagging and blogging are the poster children of 2.0 and it’s interesting that many still dismiss them as they dismissed the directories and homepages of ’94. A few years ago they would have been credible. Not today though. Today there is too much noise from too many directions and too many demographics.

The bloggers of today aren’t scouts looking for water and flatlands, those pioneers came and settled back in the late nineties. Those that you see now are the forward party of a full blown caravan and land is being settled. There’s a city being built and I imagine that anyone who doesn’t settle right now will soon be unable to afford the land they stand on.

Web 1.0 was about connecting machines. Web 2.0 is about connecting humans. For my money, when it comes to interaction, human beats machine every time and my work, my emotions and my livelihood are all staked on Web 2.0 being a very Big Deal.

I just found this on my hard-drive and wanted to pop it up. It was something I copied down ages back but can't remember from where. If you know whose it is then please tell me and I'll credit them.

Software development cycle:

1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs.
5. See 3.
6. See 4.
7. See 5.
8. See 6.
9. See 7.
10. See 8.
11. Due to marketing pressure and an extremely pre-mature product announcement based on overly-optimistic programming schedule, the product is released.
12. Users find 137 new bugs.
13. Original programmer, having cashed his royalty check, is nowhere to be found.
14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
18. Programmer produces code he believes is bug-free....

Cutting through the problem like a hot knife through butter was Brit-blogger Ed. He got everything right except for his last statement which was a little off track (and actually contrary to the first two). Despite being picked up by both Sarah and Eric I completely failed to notice this and initially gave Ed first prize.

So in a rather embarassing (to me) re-awarding ceremony, the first prize is actually going to have to be shared between both Ed who was first through the door and got the logic right and Eric who got both the logic and the fact that bricks are denser than water.

Well done both of you, you certainly did a lot better than I did in my interview. If I recall correctly my response was:

1. sweat nervously
2. answer: stays the same
3. answer: goes up
4. find door

If the answer doesn't make any sense to you then here's a bit more of an explanation. It may or may not help:

Pressure in water decreases as you go downward. This is because the water at the bottom has to support the water above it.

Because the pressure increases with depth, the pressure at the bottom of an object in water is slightly greater than the pressure at the top. This means that there's a net force pushing the object up - buoyancy. Do the figures and it turns out that the strength of this force is equal to the weight of the displaced water.

So, the water is pushing the object up (buoyancy) and gravity is pulling the object down (weight).

If the object's weight is greater than its buoyancy it sinks, if it's the same it just hangs in the water like a jellyfish and if it's less then it floats.

The buoyancy of the brick is equal to the weight of a brick sized lump of water and since a brick sized lump of water weighs less than a brick-sized brick, the brick sinks.

When the brick is in the boat it pushes the boat down. As the boat takes the weight of the brick it sinks into the lake and displaces enough water to provide the extra buoyancy required to keep them both above water. If it didn't do this they'd both sink - try putting a brick in a paper-boat.

However, when the feller chucks the brick out of the boat, the boat bobs back up again while the brick now only displaces its own volume. Since a brick-volume of water is less than a brick-weight of water, the level of the water in the lake goes down a little wrt the shore.

(Jeff gets second place prize for making me laugh)

From Dew B's take on Tech PR:

--------------------------
--------------------------

I've signed up.

(tech-talk-post)

The application that I'm developing lives on the client (Firefox) and, after having downloaded its script files, all subsequent communication with the server is in XML. Getting data from the server in XML is a pretty well documented process, there are several articles out there on the XMLHttpRequest object. Sending XML back to the server though seems to be a less trodden path.

XML games

Let me take a moment to explain the problem. When we download XML using the XMLHttpReqest object, it is automatically parsed and packaged up into a XMLDocument object with all of the associated DOM methods and niceties.

Using the document.implementation.createDocument() method we can also create our XML document objects from scratch on the client. Firefox is a wonderfully well equipped environment for working with XML and comes with all sorts of tools including XPath that we can use to query and manipulate the document.

These XML tools are without a doubt the client-side data layer to use for a serious AJAX app. However, until recently, I had laboured under the assumption that the layer came without an exit route.

Packing to go home

After having played with our XML document and used our powerful but thin client to manipulate the data in that document, how then do we post it back to the server? Previous articles I've seen have literally build the document up as a string:

var xmlString =" <?xml version="1.0" encoding="UTF-8"?>
<root><data></data></root> ";

Chances of me packaging up 30k of XML by hand? Not likely. Clearly a serializer is required and I figured there had to be a method built into the browser to do this.

Try as I might though I couldn't find one. The standards based solution (as exemplified in PHP5) is a method on the XMLDocument object called saveXML(). This method converts the DOM object into a string. Easy.

Mozilla does seem to have it on its to-do-list but judging what I can see in Venkman, there's currently no implementation (Firefox 1.0.6).

A hack solution

So faced with my little problem, I had three solutions:

1. Keep looking for a serializer method somewhere in the Mozilla documentation
2. Write my own serializer method
3. Think of something clever that required less work than option two

After exhausting option one I considered two, realised (with considerably more foresight than usual) that it was going to take me down a long dark road I didn't want to tread and came up with a hack. The hack went thus:

• create a new div object using window.document but don't append it to the tree
• grab the root node from the XML document
• append the root node to the div as a child node (oh-yes)
• grab the contents of the div using the innerHTML property

Rather clever even if I do say so myself. Well, rather clever until I started sending RSS back up to the server and it wouldn't parse. Oh tits.

Well it turns out that when you add the XML node to the div node, it gets converted to semi-valid XHTML. Semi valid because whilst the browser doesn't allow elements such as title or link to have any text-content, it's perfectly happy to sit the text content down next to the title or link tags and not to bother closing them. Thanks a bunch.

Uh-oh. Looks like it's serializer writing time and we all know the ever expanding time-greed of this type of task.

A light in the tunnel

Then suddenly and totally out of the blue some XDivinity injected the term XMLSerializer into my head (retrospectively it sounds slightly less divine than it seemed at the time).

Mwa-ha, come sit next to me little one. No idea what you are but let's go Googling and find out. Answer: nada. Twenty links to articles saying how the Mozilla serializer's got a big bad security hole in it but nothing telling how to use the damn thing.

Google, you sod, I need more info than just .NET porn, give me some meat! Finally I checked del.icio.us but even there, there were a couple of links but still no documentation.

There's clearly only one thing left to do. It's time to ask the debugger.

Venkman says

Trying to contain my nervousness, I crack open an new session and create a XMLSerializer instance. It works. I can't see any properties but there are two methods hidden in there:

XMLSerializer .serializeToStream()
XMLSerializer .serializeToString()

Hubba hubba. Next things next so I create a new XMLDocument object, add a couple of nodes and, as the "potatoes first and sausages last" kind of guy I am, I go straight for serializeToStream. Nothing. Gah.

The meal's not over yet though - it's time to eat that cumberland.

With shaky hands I give serializeToString a nice document object, hit return and... result! It returns me a string containing my XML. Bingo bango, we're cookin' on gas!

I guess when you spend all day programming, you take pleasure in small things but as you can tell this little nugget made me one happy bunny. I can guess at what serializeToStream does but since serializeToString has what I'm looking for I ain't that fussed.

Sample script can be found here:

http://www.webkitchen.co.uk/errata/mozilla_xmlSerialize.htm

No idea whether it works in any of the other browsers but since I'm only developing for the Fox I'm not bothered. One thing to note is that it only serializes downward from the root you specify i.e. you're going to have to package in your own doctype but that's easy enough. Other than that it seems to do what it says on the tin.

Updates:

1. I've now realised I was originally only searching Google UK and there are actually a ton of links out there including Mozilla's own documentation both here and here - heh!
2. Sorry Google.
3. I'm pretty certain that the Mozilla security hole has now been patched

Stick 'em below

A man stands in a yacht which itself floats in a lake. In his hand he holds a brick. He throws the brick out of the yacht and into the lake. The brick sinks to the bottom of the lake and rests on the floor.

The question

Does the level of the lake go up down or stay the same in relation to the shore?

This is a pure logic (and physics) question. There are no tricks and you've got all the information you need to know.

The rules:

1. Don't answer if you've already heard the problem. It's no fun if people just write what they already know, this is a teaser not a survey.
2. Winner is the first correct submission.
3. POST ANSWERS IN THE COMMENTS OF THE NEXT POST

I've suddenly realised that there are a number of solutions to the bearing problem. I hadn't worked it out in years and was relying on the competitors to remind me how it was done.

When I started thinking about it though I realised that while both Jeff and Atacrawl had come up with a different way to do the second part of the problem (4 unknown), my way was in fact different again.

Now I've looked at the three alternatives to the second part and they all seem to be both correct and distinct solutions. If you think they're not then speak now or forever hold your peace.

A different method for the 8-unknown

What I've suddenly realised is that there's also at least one other solution for the 8-unkown section of the problem and I'm starting to suspect there may be more. Is there perhaps even another alternative to the initial 8/4 split?

If you want a clue as to how the alternative solution to the 8-unknown works then have a look at the second comment I wrote on the previous post which describes an alternative to the 4-unknown. First person to this or any other solution will join the ranks below.

Current winners:

Jeff Koke - first to a solution on both the 8-unknown and 4-unknown
Atacrawl - a different solution to the 4-unknown
??

Congratulations to Jeff Koke who was the first person to solve the puzzle.

I wrote on the original post that I'd be interested to see if there was a super-fast way to do this puzzle but in retrospect what of course I meant was that I hope no-one solves it quicker than the four hours or so it took me. Seems Jeff's got me down by half but I'm glad that no-one slipped in under the hour.

ding ding

Second round. Since everyone needs a bit of work avoidance I'm going to drop another couple of these puzzles into the feed next week and give y'all an excuse to get head scratching again.

The next one will be a physics problem (that I was asked at my university interview and failed dismally and embarassingly to answer correctly) and then the one after that will be probability (this one also needed to be explained very slowly to me).

Don't fear the possibility of intellectual alienation for all conundrums will of course wrapped up in a nice everyday scenario like needing to find the odd-bearing (and you can always reassure yourself with the fact that I floundered like a fish in a puddle with the next two).

If you'd like to enter the ball-bearings competition then post your answer in the comments below:

I've just been playing around with the fish-teaser that cropped up on a blog link this afternoon. Reputedly written by Einstein he also pronounced that only 2% of the population could solve the problem though smart as he was I'm not entirely sure where he plucked that figure from.

There is however a way to do the fish problem visually that makes it fairly straightforward. One that I'd be intrigued how to simplify however is the following which kept me tied up for hours at a July 4th party (back in the days before entrepreneurship when I could afford to be cavalier with social contact).

Pauli's steel

I'm not sure who invented this but for the sake of keeping up with the Jones', let's say that it was Pauli. Apparently the little devil is soluble by only 1% of the population though that could be something to do with the phenomenon that everyone who solves it immediately forgets the answer to Einstein's riddle and vice versa. Strange.

Odd-ball out

You are presented with 12 steel ball bearings and a set of weighing scales. All the ball bearings are identical except for one. That single bearing has the same size and appearance as all the others but a different mass. You don't know whether it is heavier or lighter than the others, all you know is that it's different.

Ethan, your mission is to find out which ball is the odd one out and to do this you may use nothing but the scales. Furthermore, you are limited to three weighings and three weighings only. That means that you can put any combination of balls on the scales, note the outcome and repeat the process two more times but that is it.

You can't drop the balls, roll the balls, taste the balls or do any other form of jiggery-pokery. This is not a trick problem, there is a solution and it is a unique solution (Update: it's not a unique solution at all! It seems there are at least five solution combinations and possibly more). If you want a very basic clue then see the bottom of this post.

The winner will be the first person to post an answer on comments of the next blogpost after this post. DO NOT POST YOUR ANSWER ON THIS POST as it will spoil it for other people.

(disclaimer: this post was a little pithier half an hour ago but then Blogger decided to delete the whole thing - grrrrrrr)

Clue - highlight to bring to life:
The problem demands that you use every piece of data you can from the second and third weighings - you must be able to deduce something different from the scales going down to the left, down to the right or staying the same

I had absolutely no idea that it was possible but a couple of weeks ago I discovered that it was possible to create private methods in Javascript.

I really enjoy programming in Javascript and actually far prefer it to several other languages including PHP. I'm always looking for ways to improve my code though and so the ability to reign scope as tightly as possible is more than welcome.

Private methods aren't mentioned in any of the Javascript literature and could arguably be described as a hack but are nonetheless gratefully received.

How?

Javasacript object methods can be defined either in the constructor or via object prototyping and this duality had always confused me. I couldn't figure out what the difference between the two was and why they both existed. It turns out that defining methods in the constructor creates either private or privileged methods and using prototyping creates public methods.

Links

The implementation is not difficult but I'm not even going to touch on it here as I'd just be repeating the excellent tutorial on Douglas Crockford's site.

Crockford also has a number of other very interesting articles on Javascript and points to another big man in the field, Richard Cornford who has a very promising article explaining the concept of javascript closures (which I have still to read).

I have a lot of respect for patents both within and without of software. Sometime I'll write a post on why I think they're a valuable but flawed solution to a genuine problem.

What I don't fully understand is the logic that lies behind the patenting of busines methods. Business methods are not patentable in the UK but they are the US and to my untrained eye they seem to allow for some pretty unwholesome lockups.

Amazon's Jeff Bezos does seem to realise the ridiculousness of the status quo as he is calling for patent reforms. Calling for reform he may be but the big-book man is either a two-faced hound-dawg or caught in an unavoidable arms race as it hasn't stopped him registering the infamous 1-click patent or the concept of recommending something to someone based on what they've already bought.

Ho-hum - this is patenting of sales 101, can't be a good thing can it? There's a big difference between protecting vulnerable companies and investments and simply auctioning peoples' rights to free and efficient trade. America though seems to be getting a little confuddled.

Today I see that the company that does no evil is attempting to patent the concept of RSS advertising. In summary, their patent looks to protect advertising based on the keyword content of RSS items and whose effectiveness is tracked via clickthoughs.

To my mind there are at least four very basic reasons why refusing this application should be a no brainer:

First off is that patents cannot be granted when there has already been a public disclosure - this puppy's been pooping in the wild for two years already.

Second is that patents are supposed to be granted for non-obvious inventions and for something that someone without an ounce of creativity or lateral thinking could not have created. It has become a truth of our world that people will advertise anywhere they possibly can, including on their heads.

The concept of advertising on an emerging medium must surely be the very definition of an obvious invention and the firm behind the "Are you thinking what we're thinking" campaign is nothing if not a blow to the latter criterion. It was smart when it first came out but keyword/clickthrough advertising is a done-deal. Google's already eaten this particular cake.

The third reason is unlikely to make a difference to the lawyers. However, should the case hang in the balance then it's worth remembering that Google is not a vulnerable company with a huge amount of unsecured investment that could be destroyed without an adequate return period. It's the largest advertising company on the internet with a big barn full of greenbacks and has invested almost nothing to create this technology-tweak.

Fourth is again unlikely to sway the lawyers but is to my mind the most significant and potentially damaging issue. That is that granting unnecessary patents to large companies stifles other companies and prevents market variation. Patents such as this ironically work to smother, not protect innovation.

I do think that patents are both important and valuable but some of these applications make me not a little uneasy.
Update:
I've subsequently discovered the patent was in fact filed two years ago. The only reason it's only just breaking in the news was that it was originally filed under the name of a Google employee rather than the company itself. Nonetheless it still seems that RSS advertising was had been suggested and hence disclosed even before this date.