Google-watching:

The Kremlinology of IT.

It's really a thrill to watch, like watching a game between two shodans in go. Charles H. Ferguson has an article in the MIT Technology Review that contains a very good introduction to the hobby. His summary what the stakes are is the most succinct yet:

Google and Microsoft will be fighting to control the organization, search, and retrieval of all digital information, on all types of digital devices.

Throughout the article he demonstrates a deep understanding of strategy in business and IT. He has a serious point when he says that MS could easily gut their AdSense revenues by undercutting them on adverts, but this is legally risky. One of his central points is that control of at least one platform is a prerequisite for success, and so far, Google controls none.

There are some things however that I could take issue with. Firstly, it's important to recognise that Google is a service, not an application. Google is winning on quality of service, and (as demonstrated by Google Suggest) is still evolving ahead of the competition.

Secondly, this:

Google should understand that it faces an architecture war and act accordingly.

I believe this is about right. Ferguson warns Google away from developing a client-side architecture (in the shape of a browser) elsewhere. This is because getting sucked into a war of client-side architectures with Microsoft is a surefire step to disaster. That's what Netscape did, or tried to do. So did the Network Computer, and OS/2 Warp.

However, to "act accordingly" is never a good thing, and in this case is to bend to Microsoft's will, and to lose the initiative. It would also heavily impact their response time and put a strategy tax upon their shoulders to boot.

Now, having said this, I agree with him 100% when he puts forward the need for a Google API. Rolling out a complete server-side API is an important step to Google, for several reasons:

Firstly, whether internal or external, there must be some wholesale method of adding to and querying from Google's database. This is a necessity if Google wants to expand the breadth of it's search, either into the deep web or down the long tail of personalised search. As said elsewhere, half of Google Labs is likely already using the API in beta form.

Secondly, server-side wars with Microsoft have been fought and won - J2EE has whupped COM+ etc. in the enterprise, and it's too early to tell the score for .NET. You have better odds on the server than on the client.

Thirdly, the web client is already rich enough for Google's purposes. One of the interesting side-effects of the browser war is that MS helped make the web rich enough that anyone could threaten the desktop without actually landing on it.

In this respect, their extension onto the web opened up an avenue of attack against themselves. Google only has to touch on this for Microsoft to start panicking, no doubt the desired effect. After all, MS is too big for Google or anyone else to take down by themselves. Only if Microsoft's biggest enemy (itself) starts to co-operate, then do things start looking grim.

I just had an idea

Musicians, when recording in studios, have monitors. Well, people working in offices with headphones should have a cardioid mic setup as a monitor in front of the screen, so they'll know if they're singing out of tune.

The P2P wars re-ignite

((Geek)Blogger.getUser("http://ianso.blogspot.com")).postOpinionOnBT()

In the wake of the (most likely pre-emptive) shutdown of suprnova and it's ilk, we have some of the very similar calls to action that we saw when the Napster deal went down.

Several thoughts immediately come to mind:

a) Protocol adoptions emerge slower than people expect. It took Bram Cohen three years to get BT working as it does now. And BT is a single-function app - compare this article by Joel for multi-function app development lifecycle & maturity statistics/industry practices.

b) A lot of people are saying that true anonymity is the solution. Not so: true anonymity protects more than just copyright infringers. Anyone who's peeked into Freenet knows that there is a lot of truly disgusting stuff out there that people will not download if (e.g.) law enforcement can pin a name on the downloader.

When you go for true anonymity, this is the kind of people that the MPAA et al. will associate you with, as the RIAA already prematurely attempted to do at various other levels.

c) Alternatives to Suprnova have already sprung up, and this is what's going to keep the MPAA occupied for the forseeable future: the old game of whack-a-mole, as known and loved by the RIAA. People will migrate between these, always one step ahead of the subpoenas.

d) Contrary to Pesce's statement, the centralisation of BT is a feature, not a bug. In every P2P system the 'net has seen, quality control has been a product of centralisation. Some decentralised networks have URL schemes containing hashes of 'certified' files, but these URLS have to be hosted on a site somewhere.

To put some spin on Jeff Jarvis' approach, trust and authority (therefore verification of quality) are an intrinsic function on centralisation. This goes back to my idea on community metrics and filtering, but existing P2P protocols already scale to levels far above that to which any net-based community has ever scaled, let alone a decentralised community built on anonymity. Community metrics are not the answer here.

e) Although anonymity is not the answer, cryptographically verified pseudononymity may be. At this point the conversation gets a lot more complex than I could hope to understand, but smart crypto boffins will tell you (a) it's nowhere near as easy as it sounds, and (b) this was the dream of the cypherpunks, and look where they ended up (nowhere, or co-opted by the gentlemen producing wholesome DRM such as TCPA & NGSCP etc.).

Finally, when Adam Fields says this:

Here’s what I think it boils down to - a simple choice. We as a society have to choose one of:

1) Copy protection.
2) General purpose open computing.

He's absolutely right, except you should replace "copy protection" with "information control", which is what George Tenet is actually talking about. Compare Neil Postman. This battle is bigger than BitTorrent, bigger than P2P, bigger than the Internet. And we're on the loosing side, unless we do something about it. Lessig got here way before the current crop of enraged P2P users, and I look forward to seeing what conclusions they arrive at, and how they've changed since then.

Is this not highly cool?

Publishing the Skype API was a stroke of genius.

Tangential to my ideas on uses for the Skype SDK, we now have SkypeCasting.

Why this rocks: telephony is being freed from traditional PSTN networks and corporate-borne innovation, and we're starting to see reinventions, new takes on old ideas, etc., just as we're accustomed to seeing every day here on the 'net.

A humble prediction: it won't be long before somebody uses the Skype API (or an equivalent) to come up with a killer app that will become the new must-have and change the VOIP landscape permanently. What it will be is impossible for anyone except the creator to say, but my guess is that it'll be disruptive and/or subversive in nature.

It'll be interesting to see what Skype does: stamp it out, embrace and extend, or (more positively) tolerate it or surf the wave.

Hi-tech is an interesting world.

I LOVE POLAND

Really. No kidding. Fantastic.

Software patents delenda est.

Aaargh...

I just tried to sit down and relax with a game of single-player StarCraft (a game that has many fond memories associated with it) and I found out that I couldn't, simply because doing my non-work coding would be more fun. What this means is that I've found immediate gratification doing more productive things than playing computer games.

Still playing HL2 though. But one thing sucks. Steam is a nice idea, and I really hope this model disintermediates game publishers, or at least offers alternative methods of distribution that leads to a revival of the indy games industry, as if that's not happening already. I've nothing against game publishers (except Sony, EA and Vivendi), but disintermediation is de facto a good thing, from an economical point of view if nothing else.

With Steam, however, the paucity of server capacity combined with realtime online per-play activation and a buggy client is a perfect way to turn people away from this kind of thing. I paid for HL2, I should be able to play it without having to jump through all these hoops. It's only marginally less customer-friendly than the RIAA, and treats the users with the same suspicion and half-said accusations of criminality. It's frustrating.

Anyway. That's me done whining.

Note to self

Mighty Math - Quarksparking.

Waouw! I feel good...

An interesting point on the supply and demand of attention, as relates to media. [via Waxy.] A sidepoint in the story was a service of paid aggregation/coolspotting. One of the things that the explosion of citizens media is an explosion in information overload.

Me being me, I think infographics can solve this by presenting denser information. But ultimately, you need community metrics that filter out the stuff you're not interested in.

Problem with filters is that people need to have foreign stuff shoved in their faces to broaden tastes, induce cognitive dissonance, be thought-provoking etc. This is why filters are not the ultimate solution. Perfectly filtered content becomes boring, uniform.

Side note: as part of the whole gradient shebang, which eerily synchs w/ some work stuff coming down the spike, I want take time to sploosh some of this data into sweet infographics. As I've said elsewhere, there's stories hiding in them thar mounds of data.

Gradient 1.1.0pre1

Gradient 1.1.0pre1 has landed.

Buggy as hell, but working, and more-or-less undocumented, what's new is:

No more XMPP-based file transfer. Jabber.org can breathe a sigh of release, we now transfer files via HTTP and check for XMPP integration by looking for something like in the loaded document.
One example that's relatively p2p - load up this SVG file in the client, and if by some stroke of luck the whole thing hasn't fallen over, you should see something a little interesting. [Or you can look at some screenshots.]

In comparison to what I intended to do, that's not so bad. The serverside API still needs improvement. Items 1, 4, 7, and 10 on the known problems list have been fixed, although we have more bugs in other places now.

Work continues apace.

The 'A' in ADSL...

... it stands for "Ha! Worthless user! How dare you upload to the Internet! CONSUME!"

19.9 KB/Sec upstream. I ask you!

Interesting uses for the Skype SDK:

Not that I've actually looked at it or anything:

1. Piping conversations & conference calls to lofi MP3 and broadcasting the result in realtime over internet radio.
2. Circumventing the 4 caller/conference limit by using a supernode to multiplex audio over several conferences.
   

Good grief

http://www.google.com/search?num=100&q=allinurl%3A+%22select+*+from+*+where%22

Did you know?

1. The thermonuclear coffee club is even more exclusive than the ordinary, non-caffienated nuclear club.

In other news...

The EC never seems to take decisive action. If they really want to destroy the future of the IT industry in Europe, they should make keyboards illegal. Instead they adopt directives on software patents during fishery meetings.

GRRRR.

Software patents delenda est.

Ian's rules of crunch time

1. Don't do it. HAR.

I've been working hard. As in, 16-18 hours of nonstop movement, every single day, for the past month and a half.

Things to bear in mind:

1. Exhaustion drastically affects quality of work, and mistakes are made when people get tired.
2. Good food and coffee are essential to maintaining energy levels. Breakfast especially.
   
3. Exercise is also absolutely essential. You cannot push yourself to your limits in anything if you don't stay healthy, and excercise regularly.
4. Water. Lots and lots of fridge-cold water. Keeps you alert, good for the brain.
   
5. No matter how you try, cutting back on sleep, even by one hour, will have repercussions. Sleep deficits can accumulate over weeks. Pulling all-nighters is not something that should be done more than once a quarter, and only when you know you'll not be called on to do heavy brainwork in the next two to four days, and only if absolutely necessary.
   
6. I'm tired, but I'm happy. I couldn't work this hard by myself.
7. The rest of the stuff is personal. Like it or not, humans have spiritual and emotional sides, and if your belief systems, support mechanisms, etc. aren't there, then things will be much harder than they need to be. If you believe in God, try getting Him involved. He might help you with debugging.
   

Things that are often redoubled:

• effort: 40%
• focus: 32%

I have discovered something that ROCKS:

This example of E4X in use should be enough to convince any ECMAScript coder having to work with DOM that the sooner we get this in Seamonkey, the better. The gentlemen at Mozilla are working on it now, and all power to their elbows.

This me constructing a styled SVG rectangle with the normal DOM API:


var inboundRect = document.createElementNS(SVG_NS, "rect");
inboundRect.setAttribute("class", "borderLink linkRect");
inboundRect.setAttribute("x", -padding);
inboundRect.setAttribute("y", -(textOffset+padding));
inboundRect.setAttribute("width", "0")
inboundRect.setAttribute("height", "15")


This is with E4X:


var inboundRect =
<rect xmlns="{SVG_NS}" class="borderLink linkRect" width="0" height="15" x="{-padding}" y="{-(textOffset+padding)}">


I rest my case. This is already in Rhino, so (*BOUNCE* *BOUNCE*) I can probably use it in Gradient. JOY!

Joel Spolsky:

Thank you for sharing.

This makes the alert() debugging (ECMAScript equivalent of printf() debugging) a whole lot more palatable.

Notes to self:

1. iso-8859-1 is not the same as ASCII. You'd have thought, that after 3 years in a quatrilingual country, you'd know this.
2. For developers that have to test their own code:
   
1. Stop thinking like a coder/creator, and start thinking like an intruder - "how do I break this software?"
   
2. go through all the code you wrote and write down each confirmed behaviour. This is what needs testing.
   
3. Write a series of input/action procedures that collectively confirm each behaviour.
4. Start the procedure. Note all irreularities and bugs until you come across a blocking bug. Fix all the bugs. Continue the procedure.
5. Once this is done, use the code as a user would several times, each time doing different things like deleting stuff etc. that a normal user expects to work. Not so much code paths as UI paths.
   
3. D. w/ P. Tues 1800 (I left my mobile @ home today.)
   

Uh...

Wake up Ian.

If the client generates thread IDs, then the client can ensure uniqueness, can't he? Which means you don't have to include the controller JID in inter-document messages and IQs, do we?

Sheesh.

Je répète

If it was simple, it would be boring.
If it wasn't elegant, it would be wrong.
That said, we must adapt to the terrain, hence all this:

OK, so the solution to the below is 3 and 4. 3 for inter-document comms, 4 for doc->JID comms. This means modifying the client-side routing to allow multiple threads per JID. No problemo, we move the JID identity check for controller JIDs from right at the top to right at the bottom of the routing decision tree. Neither is happy, both are ugly, I will replace them if I find something better.

Issue number two is kind've a funny one. Before we used to do document loading via XMPP, which was a bad idea, to put it mildly. Now, we do it via HTTP, and a namespaced element in the document tells the canvas to send a message to a JID with the URL and the generated thread ID.

This means we don't have to do queuing packets for unloaded documents, which is a bit of a relief (although I only figured this out after I rewrote the routing code to allow multiple 'routing tables' to be used in the same router, which is nice logic separation but needn't have been done.)

However, now the SVG "onload" event is triggered before the UpdateManager is started, meaning that we could be sending stanzas before we've let the server know our thread ID, which is obviously not cool. The solution to this is to move the XMPP networking code into documentLoadingCompleted(), which is called after the document is loaded and blocks the thread that triggers the ECMAScript onload/script & interpreter initialization code, which is what we want.

This means that although we won't be sending stanzas with a thread ID we haven't declared, we can now receive directives and stanzas for the document before we have the thread we should be executing the events and running the directives in.

What this means is that we need to keep the packets for this canvas to one side while we add the packet router as an UpdateManagerListener to the canvas, wait for the event to fire, walk our way back the reference tree (or keep an internal Map) and then start processing packets.

Which is basically what I was doing back when I sent and received documents over XMPP, because it's semantically equivalent to queuing packets for unloaded documents. Funny how things work out.

Annoyingly complicated conundrums.

So, the next version of Gradient is going to loosen up a bit and allow for XMPP traffic between loaded documents, as well as between documents and the server they were loaded from.

Each document is identified to the XMPP network by three things:

• The JID contained in the namespaced XML element that specifies the "controller" for this document
• The full URL that the document was loaded from.
• The thread ID assigned to the document by the server.

The thread ID is basically a unique identifier for the document, and a shared secret between the client and the server. When messages or IQs meant for one document alone are sent to the client, they use the thread ID to specify which document.

So how do third parties, such as other clients, interact with documents via XMPP? Well, they have to identify the target document in their stanzas. How do they do this? Using the thread ID. Points to note:

• Either the client or the server has to share the thread ID with the third party in order for this to happen
• Stanzas that arrive from non-controller JIDs are treated differently than controller-originating stanzas:
• They cannot modify the document using directives.
• They trigger different events in the DOM environment.

If the server sends an IQ to a document, the function processIQ(elements, type) is called (if declared). If anyone else sends the document an IQ, the function processForeignIQ(from, elements, type) is called. This ensures that malicious JIDs can't mess around inside of code points/decision trees/logic meant to be used exclusively by the server, unless you explicitly allow it by doing something like this, which is brain-dead from a security point of view:

function processForeignIQ(from, elements, type) {
processIQ(elements, type);
}

function processIQ(elements, type) {
//now we're not just dealing with IQs from the server here!
}

But I digress. The point is that the thread ID is guaranteed to be unique between two JIDs (client and server) as per the RFC - any other behaviour is breaking the spec. However, the thread ID cannot be guaranteed unique across all threads with all servers - i.e. it's possible to have different conversations with two different JIDs, each with thread ID "123".

This means we cannot simply specify the target thread ID on a third-party stanza meant for a document loaded from a different JID. Thread collisions become possible.

At least three options immediately came to mind:

1. Ignore this design flaw. A bad idea on principle.
   
   
2. Break the spec and put the JID in the thread ID. Also a bad idea on principle, and just plain braindead. NO.
   
   
3. Require inter-document XMPP stanzas to specify the document controller JID. This is annoyingly complicated, and precludes third-party JIDs from broadcasting stanzas to documents who ask for it, regardless of their controller.

Another problem with all the above solutions is that sharing the client-server thread ID could possibly open the model to side-channel attacks, and have other unforeseen consequences on the security model.

4. Require the document to initiate communication to third-party JIDs, by sending a message or IQ with the new thread specified. The thread could be the same as the server-client thread, but that's up to the script running on the client.

The problem with this is that it then becomes impossible for a document to initiate a conversation with another document with identical behaviour. That limits third-party nodes to a server-like role, and prevents inter-document (i.e. p2p) communication.

Grrrr.

Problem #1:

I enjoy coding, but for each hour spent creating, rewriting or refactoring, I have to spend another hour or two testing the changed code before I have any confidence in it.

I suspect this is why coders become software architects.

Oh well.

For the record:

1. I re-iterate this advice.
2. Half-life 2 does rock.
3. The most exquisite torture device known to man is woman.
4. Seamlessly opening arbitrary file types with the correct program in Java on Windows is stupidly annoying. This is the Mac version:
   

   /**
   
   * @author Frederik Zimmer
   
   */
   
   public class MacOSXFileLauncher extends AbstractFileLauncher {
   
   public void launchFile(File file) throws IOException {
   
          Runtime.getRuntime().exec(
   
                  new String[] { "open", file.getCanonicalPath() });
   
   }
   
   }
   
   

   And this is the Windows version, accessed via JNI:
   
   
   

   JNIEXPORT jint JNICALL Java_ziga_util_WindowsFileLauncher_launchFile
   
   (JNIEnv *pEnv, jobject, jstring filepath) {
   
   
   
   int length = pEnv->GetStringLength(filepath);
   
   const jchar* jcstr = pEnv->GetStringChars(filepath, 0);
   
   char* cFilepath = (char*) malloc(length*2+1);
   
   int size = WideCharToMultiByte(CP_ACP, 0, (LPCWSTR) jcstr, length, cFilepath, (length*2+1), NULL, NULL);
   
   cFilepath[size] = 0;
   
   pEnv->ReleaseStringChars(filepath, jcstr);
   
   
   
   HINSTANCE returnCode = ShellExecute(NULL, "open", cFilepath, NULL, NULL, SW_SHOWNORMAL);
   
   
   
   return (jint) returnCode;
   
   }
   
   

   
   
   I rest my case.

One two three four, I declare...

Well, that didn't take long. As usual, NTK was ahead of the crowd.

For some reason I'd been thinking more highly of Microsoft recently. Probably because they have a more human face now - I have a greater respect for Scoble and C4L than Ballmer or Allchin. Sadly it looks like I'm going to be proven wrong about the company.

On the bright side, THANK YOU POLAND! We may yet get an EU directive that embodies the principles that the Parliament voted for, instead of the 'principles' that the gentlemen at the Commision tried to present as a fait accompli.

Software patents delenda est.

Anthropology meets economics

Edward Castronova continues his good work with the study of virtual economies, and what that tells us about real people, and economies that would still exist even if people didn't have far too much spare time and money.

Money laundering though virtual economies is something that was first suggested by Rusty on K5, and I've toyed with it a little since then. The basic problem is that each universe is too small to avoid distorting markets and bell curves when washing appreciable sums at an acceptable rate. The answer to this is per-game and eBay bots, or sweatshops MMPORGers.

Running an item-generation sweatshop would be perfect cover for this kinda thing.

Aside from my nefarious musings, what I'd like to see is an inter-game object description and exchange protocol. Having a +10 Vorpal sword in a sci-fi space-combat/trading MMPORG wouldn't give you many tactical advantages against entry-level plasma cannons, but it would retain some monetary value, modulo normal item depreciation. Also, as an antique, you could decorate your office with it.

The challenges are as follows:

1) The various providers (MS, Verant, Blizzard, etc.) all have a lot of proprietary stuff locked up in their respective knowledge/skill bases, and their own way of doing things like e.g. disbursing currency.

They don't want to share the "unique" knowledge they've built up over the years, despite the redundancy of MMPORG-running/administration talent within EA, MS, Verant and Sony being a tremendous duplication of effort, and a waste of time & money, not a competitive advantage.

Every piece of code that even approaches protocol-level interop with an MMPORG is stamped on, hard, with the +5 DMCA Jackboot of Stomping. Getting these people to co-operate on something that increases fluidity for a player transitioning to a competitor would be practically impossible.

2) Each provider uses their TOS to maintain the legal fiction that in-game objects are worthless. Of course, anyone with eyes in their head can see currency, real estate and commodities being traded on eBay. If 'worthless' in-game items are not being traded on eBay, then the game is dead in the water, doomed, lifeless.

The providers force this acceptance of worthlessness on users for two reasons.

2.a) They don't want to become liable for inventory, or for in-game fraud, etc. If $1M worth of imaginary items are being traded every day in EQ, a day's downtime suddenly becomes roughly as important as disruption to a small stockmarket. They'd get sued for dupeing bugs. If God was a legal entity, just like a large corporation, then lawyers would be suing him on behalf of people who think they got a bad deal out of real life, unless he asked each newborn baby to click yes on an EULA.

2.b) An acknowledgment of value for in-game cash means that there's a legal requirement that it be regulated like any other "non-cash means of payment". See the proposed EU directive, which almost definitely has UN and DoJ equivalents, and which would have been applicable to MMPORG currencies regardless in one of the early drafts, before someone fixed that.

3) Blizzard is no more likely to allow a WoW user to transition to EQ2 than MS would allow a Passport-totin' MSN IM user to transition to AIM.

Lock-in is still a fact of life in MMPORGs as it is in IM and other areas in IT, because established players have no interest in becoming the infrastructure and platform upon which a next-generation of players can disrupt or destroy markets at their expense.

What I mean is this: imagine that you could move your character between MMPORGs, or sell real-estate in UO to characters in EQ. Imagine that the money/credits you earn or make or win in your game could be kept in banks unafilliated with any in-game universe, or invested in shares of clans or guilds in other games, or used to play on the Forex markets with gold pieces and beryllium credits, or whatever.

This is the kinda thing that could happen if MMPORG providers loosened up a bit, and let money and property flow in between these systems. MS, Verant and Blizzard could find themselves running a confederation of systems hosting virtual worlds whose 'populace' would have a GDP comparable to that of a normal western country, instead of the half-dozen equivalents to Namibia that they have right now. That's a license to print money, compared to which owning a casino would be small change.

Lock-in prevents this from happening.

Other reasons this remains a distant dream are the real-world hurdles. For example, there's nobody who can get all these players at the same table. Also, as soon as virtual currencies become big enough, governments will insist on them being regulated just like normal currencies, and therefore declared and taxed, even if the user signs the "worthless" TOS.

Despite all this, I still think that contiguous 3D net-based realities are more likely to grow out of MMPORGs than anywhere else. We shall see.

To re-iterate:

I've said it before, I'll say it again: John Perry Barlow is very smart, and a bit nuts, and has a triple-A grade blog.

Must. Code.

NOT IN TEXTUAL MODE OF THOUGHT

I recommend:

SomaFM. Beat Blender, in particular.

Thought of the day: I discovered a remote SQL-injection/XSS bug in a product I work with this week. (Not related to the below story, I assure you.) What surprises me in retrospect is that (a) I should have seen this 2 years ago, (b) the speed at which it was fixed - (2 days to patch - impressive!) , and (c) It was so obvious. It was hiding in plain sight.

Other stuff: GoogleBrowser is incredible. And, everywhere displays should, if there's any justice in the world, catch on like wildfire.

How dumb can you GET?

A co-worker told me about a site he came across that executed SQL select clauses that were passed as parameters to an HTTP request. We now have an answer to the question posed above.

The webmonkey who did that was quite obviously as thick as a post. No head between his shoulders. A few chunks short of a transfer. A 206, who 408's on everything you put to him. Accept: text/html; q=0.1, text/sql; q=0.1.

And has hardly any security considerations.

(OK, I'll stop now.)

Yay, new server

So now I go through the whole init.d thing, re-fiddle with mail servers etc. etc. It seems to me you can have: cheap, reliable and flexible, but a pain to administer (Linux, even with Webmin), or: expensive, PIA, single-vendor, a breeze to "administer", (Windows).

Sigh. I'm not sure I have time for this.

Well:

Mr. Bin Laden is helpfully removing any wiggle room that Kerry thought he had on the subject of national security. Probably not quite the "October surprise" the Bush administration was hoping for.

Now let's pray Osama's blowing smoke...

Hallelujah

I now have ADSL.

The second trend...

...the way web design is changing. Everyone knows nested tables are old-school, clean semantic (-ish) XHTML is newschool. On top of that, ECMAScript is finally being used as it should be in places like GMail etc. etc, leading us to decent webapps that actually take advantage of 6-series functionality (I would argue that Gecko, Opera 7 and Safari will go "7-series", i.e. next generation, if they ever adopt some of the specs that WHATWG is working on.)

However, in terms of UI interactivity and dynamicism, HTTP and SOAP can only take us so far - as far as client-server can take us, after which we need to look to P2P. This is where you're left with the choices of ActiveX or Flash. XMPP is my attempt at a third way, by providing a network layer in which we can do (e.g.) multicast, and all the other stuff that the JEPs offer us.

XMPP and DOM together can offer us a lot more than just a chat sidebar. It can do RSS [as PubSub shows, see comment], VP like Lluna, etc. etc.

However, a dangerous side-effect of giving a DOM full XMPP capabilities could be spam and self-replicating documents. This is something I'm working on. Until I have a 100% bullet- and spam-proof solution my solution is "don't do it". I think that most solutions seen so far, especially those revolving around code-signing, are completely broken, purely because they don't express exactly what TRUST means in this context. Would you trust a company called "click here for your free calendar"? Neither would I, and what this means is that the interface is broken and users are being mislead.

Enjoy your weekends.

Guess what:

Life is tough. Bad things happen, and sometimes you need a break.

But: the MINUTE you let yourself relax, even a little, you backslide. So don't do it.

Note to self:

On the 30th I'm going to restart work on Gradient. It's going to be a 1.1, i.e. a feature release. The features:

• Get rid of XMPP-based document transfer. It's ugly, hard on the network, and goes against the XMPP server model. HTTP will become the primary document transport. Meta tags or tags with alternate namespaces will contain an XMPP "server" JID.
  
  
• (Another approach) Consider adding a JID and/or JID-derived token to be included as an "X-JID" header (or something) in HTTP requests from a logged in client. Interesting problem: can we prove that the XMPP server has authenticated us out of band? If not, there's no point in doing it. Also, it might break the model. (JID != cookie/user info)
  
  
• Get some decent examples up and running. PollingReport.com has good figures, or I could subscribe to Gallup. (Probably contravenes their TOS.)
  
  
• Improve the serverside API, which kinda sucks right now. It should be either interfaced and static-proxied, or dynamically proxied, or EJB...

I also want to fix some things in the known problems list, (UI issues). One or two things from the roadmap, specifically allowing directives to apply to attributes and text nodes, would also be good additions.

The incomparable Smack API now understands Data Forms and Feature Negotiation, as well as Disco, so I now have the freedom to make this a lot more flexible/complicated if I wanted to.

The next release planning was based on the assumption that this would be a real app, and not a demonstrator for a set of very cool DOM extensions, but still has some weight. Some stuff in there should be done too, probably.

My end result, ten years from now, is that I want to be able to do things like: pull up a map of the world, and then chart trade deficits from one server, strategic oil reserves from another, and defense budgets and standing army sizes from yet another, all on the same map/chart, and then make those numbers dance on the resulting infographic.

The first trend that I am trying to keep on top of:

(Perfection is the enemy of completion. Structure should be inferred, not imposed.)

There are two big things on the web that are undergoing sea changes. The second is the web platform and web design ideology. (I would have loved to be @ Web 2.0.)

FIRSTLY, the continual evolution of the way in which we use the web to communicate, organise, co-operate, and collaborate. The biggest firework in the box is the blog, but this is just one example of a trend that is exemplified by lean, fast user interfaces, attention to information architecture, accessibility, utility. Deli.cio.us, Meetup, GMail, Flickr, etc. Google, of course.

Aspects of related trends include the whole GTD phenomenon, and software like Quicksilver, things like wifi, etc. What these prove are:

(a) That this not just a net-related phenom, but a true change in the way people work and interact
(b) That next-level UI is coming from Geeks hacking neat code on UNIX-based platforms. Duh. (see also: dashboard)

Also, this is a big social thing. Trust, authority, organisation (as per Buzzmachine).

Ben Harper

If you have not yet heard of and experienced Ben Harper and the Innocent Criminals, then you must RUN not walk to the nearest CD shop or computer and immediately introduce yourself to him. Start with anything from the album named "The Will to Live" and live from there.

And no sooner were the words out of his mouth...

...he has to eat them again.

Ladies and gentlemen: A smart analyst.

ANALYSTS

I've heard it said that that market analysts are to PR what black holes are to matter - they continually suck up all PR within their gravity well, the end result of which is an ultra-dense "event horizon" of hype from which no facts emerge.

It sounds like JWZ, or one of his commenters.

Follow up to brain-scan based HCI

The head- and eye-controlled cursor is very cool, and gets rid of the most damaging half of the keyboard/mouse pair. (via NS). It's software that is usable now, and even might make me go out and buy a webcam to test it out.

My only improvement would be to use left- and right- wink for left- and right-click, instead of using the equivalent of double-left-and-right click to mean click. And it will do 3D soon! Fantastic.

(To answer the "silliness" charge levelled in the NS article by the analyst, I do not care one bit about looking silly if it saves me torturing myself with the mouse, and people look stupid talking with headsets, or with headphones, so...)

Previous posts in this area: Questions, Answers, Concepts

Update: Having tried the software, I have to admit it's not there yet. I'm sure we'll get there eventually. (Also: try playing with moving your hand in front of your face...)

I hate printers.

• They are always hungry.
• When they aren't hungry, they're ill-tempered.
• They eat TREES.

Photocopiers are something that Apple should have done - just once - to show everyone else how to get the interface right.

Question:

How many cities do you have to lose control of before declaring a state of civil war?

• Fallujah
• Sadr City
• Najaf
• Ramadi
• Samarrah

Anyone? Anyone? Rumsfeld?

Your password is too short...

This is a random password generator that I stuck in my CryptUtils file. It's reasonable for website logins, etc.

private static final String VOWELS = "aeiou";

private static final String CONSONANTS = "bcdfghjklmnpqrstvwxyz";



private static transient SecureRandom random;



static {

   try {

       random = SecureRandom.getInstance("SHA1PRNG");

   } catch(NoSuchAlgorithmException nsae) {

       //... static logging here.

   }

}



public static final String newPassword(int length) {



   if(random == null) {

           throw new RuntimeException("PRNG not initialised!");

   }



   if(length < 8) length = 8;



   length -= 3;



   char[] blabla = new char[length];



   for(int i = 0; i < blabla.length; i+= 2) {

       if(i >= blabla.length) break;

       blabla[i] = CONSONANTS.charAt(random.nextInt(CONSONANTS.length()));

   }



   for(int i = 1; i < blabla.length; i+= 2) {

       if(i >= blabla.length) break;

       blabla[i] = VOWELS.charAt(random.nextInt(VOWELS.length()));

   }



   String result = new String(blabla);



   if(result.indexOf("eni") != -1) {

           return newPassword(length+3);

   }



   return result + Integer.toString(random.nextInt(999));

}

A bit nuts, but very, very smart.

I am NOT going to use this whack theory to justify frame- and applet- based website navigation.

READ AND UNDERSTAND:

"Any time you engage with information, the reality that you extract from that information is shaped by the tools that deliver it. Microsoft’s information presentation is such a monoculture that it edits out a lot of other realities. So you have a new kind of monopoly that affects the way people think in ways that are invisible to them.

...

You now have two distinct ways of gathering information beyond what you yourself can experience. One of them is less a medium than an environment -- the Internet -- with a huge multiplicity of points of view, lots of different ways to find out what’s going on in the world. Lots of people are tuned to that, and a million points of view have bloomed. It creates a cacophony of viewpoints that doesn’t have any political coherence at all, a beautiful melee, but it doesn’t have the capacity to create large blocs of belief.

The other medium, TV, has a much smaller share of viewers than at any time in the past, but those viewers get all their information there. They get turned into a very uniform belief block. TV in America created the most coherent reality distortion field that I’ve ever seen. Therein is the problem: People who vote watch TV, and they are hallucinating like a sonofabitch. Basically, what we have in this country is government by hallucinating mob."

So says John Perry Barlow.

XMPP, data transfer etc., redux

OK, so where I'm coming from:

Firstly, this post and the one below are tangentially related to Volity, but I should emphasise that I don't hack on Volity myself - the hard-working Volity coders being Doug Orleans, Karl von Laudermann & Jason McIntosh.

Secondly, these are just my serialized brainstrikes on how I riff on the whole "XML documents <-> XMPP" shebang, which is my approach to the whole idea of taking the web as a quantum leap in data density, and looking to build on that in line with the whole idea of navigable info/dataspace as an end-target.

I should mention that my next idea is to try and get the whole Gradient system working with an HTML viewport as opposed to SVG.

• I want to get surfable pages that do things like Gradient out there - this is a next-level leap in the capabilities of hypertext systems, and it's possible to do right now - preferably without any client-side installation (see below 'graphs & posts for ideas)
  
  
• The JEPs for file transfer via XMPP are, as far as I can see (and someone please correct me if I'm wrong) targeted at P2P use cases, and if one of the XMPP clients becomes a "server" of documents and starts receiving 1000 requests per second, the XMPP server starts to ask questions like "Why God WHY?!", and with good reason.
  
  
• Fortunately, we already have HTTP, which scales better than the (admittedly nonstandard) method of inserting an XML document as the child element of an IQ RESULT stanza that I use in Gradient.
  
  
• Volity are using HTTP for file transfer, and this is eminently sensible.
  
  
• HTTP can't do the kind of things XMPP can do to markup (with the help of Gradient), which why both Volity & Gradient implement two different solutions for doing the interactive & dynamic stuff. Apart from broadcast, server-client RPC is one of the things that is technically possible using some kind of hack to add a callback function on a client using the newly-crossplatform SOAP ECMAScript objects and/or the DOM3 load/save functions, but this is not exactly the most elegant of solutions, to put it mildly.

THEREFORE, and taking into account that we want normal web-pages to be able to enhance themselves using this stuff while remaining accessible to normal users, it seems reasonable to do something like this:

a) Joe loads his HTML page via HTTP.

b.i) (client-side mod) A Mozilla extension either (a) looks for <meta name="gradient" value="user@xmpp-server.example.com/index.html"> or (b) Looks for <gradient:service gradient="http://foo.com/blabla" jid="user@xmpp-server.example.com/index.html">, and upon finding one, connects to the server and does the twist using some as-yet-unspecified-or-standardized XMPP extension.

b.ii) (no installation necessary, not sure if possible) page includes an applet (up: I needn't code C++, down: applets.) that is given a reference to the Document and plays with it like so. Not entirely sure of the security issues, it's all doable.

I know that from the PoV of a web designer, webmaster, information architect or usability engineer that applets suck, admittedly, but imagine a sidebar/frame applet that (a) has a decent dynamic ToC as per the Weblogic 8 admin tool, (b) decent site-search/index as per RoboHelp, (c) IM interface letting you chat/collaborate with other surfers as per Lluna, and enables your currently viewed document to be updatable in realtime etc. etc. etc.

(I know frames also suck in general but this frame is in lieu of a Mozilla sidebar)

So, if this is the grand vision, why did I start muddying the crystalline waters of disco? My somewhat hazy vision of disco was as defining a set of IQ's for querying a hierarchical nodeset. For each page or each site that has this something like this, the client would want to know (e.g.) do we support site chat using the Lluna extensions, do we do MUC, do we have a ToC (which would be a disco tree) for the site, etc. At which point we're kinda blurring the semantics between site "features" and site "services".

File transfer & XMPP

An interesting thread got started on volity-devel on how to do file transfer using disco & HTTP. [update: see this post for a correction] Right now, Gradient file transfer is basically an ugly hack, with a transposition of the HTTP paradigm ontop of XMPP, which leads to scaling problems.

There's a couple of influences on my direction here.

Firstly, surfing via XMPP is never gonna happen in a big way - HTTP is too entrenched - so the obvious step is to enable Gradient-style extensions to webapps by including a JID/disco node ID etc. in a meta tag or namespaced head child.

This means I should either squeeze a Gradient into an applet, in which case any web-page could become a gradient-page, or fiddle with the internals of Mozilla, using the XPCOM XMPP client or something like that to construct a second Gradient client in the client-side Mozilla environment, i.e. using either the XP C++ dialect or ECMAScript. This would dificult, to put it mildly.

Secondly, disco is quite obviously the right way to do view/game-specific feature discovery & [meta]data publishing in Volity, and in a broader environment has a variety of uses, which I will enumerate briefly when I finish this post tomorrow.

It seemed like a nice idea

So I was looking at the Conway's Game of Life implementation of a Turing machine, when it struck me: a network of BF interpreters with inputs feeding into outputs, all working on the same tape, arranged into a grid pattern:

• one tape passes through N nodes as instructions, and M nodes as data.
• various configurations are possible, not just grids. It's network topology 101.

BF has 8 instructions, meaning 3 bits are needed - octal. I could add a ninth instruction 'X', that switches the input and instruction streams. This would mean using 4 bits - hexadecimal nibbles - with another 7 instructions free.

Each node would need to wait & notify based on input, instruction availability. The whole thing would be visualised fairly easily.

BF operates like a Turing machine, and has:

• one random-access storage medium - the tape
• one standard input
• one standard output
• one instruction stream

That's 5 in total. If we limit the alphabet, the input and outputs could also be composed of BF glyphs, meaning the tape would be glyphs also.

But would it make any sense? Why do this?

• There's already a Conway's Game of Life Turing machine.
• Why not a BF interpreter constructed using a cellular automaton?
• Would the rules underlying this cellular automaton run on top of a nanoscale substrate?
• Could we have nodes etched/sketched in substrate and then layered (for redundancy?)

This would give us a very large cluster of very stupid computers that are almost impossible to program, but might exhibit interesting emergent behaviour.

Problems:

• when (if) we switch data and execution inputs, what happens to the stack?
• If we add an X instruction, can we wire the output to the input and generate our own code?
• How do we program this thing? BF is a pain to begin with:
• 
  
• should we find a nicer, yet equally small syntax?
• should we compile a macro language?

• What happens when two nodes modify the same glyph on the tape?
• How do we get the thing started? can we make a pseudo-random code generator in BF?

Etc. A potentially cool hack with near-zero real-world applications, short of sci-fi equiv. imaginings.

I am Disconnected.

Jeez this is frustrating. The place I moved into used to be an office, meaning (up) there are strips along the wall with power and phone lines (beaucoup des plugs) , but (down) when they left the premises they not only disconnected the line but physically cut it too (je n'ai pas un connection d'Internet) which means that I have to either wire things or pay someone else to do it. Merde.

Welcome to the neo-luddite world of the Offline. Next thing you know I'll have brought a TELEVISION.

• I am trapped in a box.
• It is quiet. Too quiet.
• I have lots of spare time.

The problem with KISS

Is that you can KISS yourself into a corner, and when you get there, you'll realise that some serious pain is in order.

The formerly-scary technology known as RFID

"The street finds it's own uses for things"
- William Gibson

Surprise surprise, some RFIDs are hackable. Very easily hackable.

RFID is a corporate technology borne of corporate needs & requirements. But like any tech, it will get taken and used / abused by people in ways their creators never envisioned, in ways that may well be highly creative, disruptive, destructive, or subversive.

For me, hi-tech is best when it's all four.

Moving

A speculative yet interesting theory.

Moving from totally furnished (down to the kitchen utensils) to unfurnished (as in "the workmen just finished installing the sink") makes you realise: (a) how many possesions you have, (b) how many more you need.

Door stops. Kitchen towels. Coat hooks. Spoons.

The problem as stated by Jack, was that the things you own end up owning you. Flexibility is a product of what is not yet present, not that which exists already.

Deduction: I need to start getting rid of stuff. So far, I can think of these:

- extra computers
- books

Also: Gaping Void.

The worst thing, recap

Summarised, the issue is seeing the potential for elegance. From elegance flows stability, flexibility, extensibilty; beauty. How could I not do this? It goes against my nature.

The workaround is easy and nice.

((Geek)Blogger.getInstance(blogspot, "http://ianso.blogspot.com/")).postPetGoogleTheory()

"What is Google doing?" is a question on the mind of every geek, and, surprise surprise, I have my own pet theory.

Google (a) sees MSN and Longhorn coming down the pole, and (b) already has Yahoo to reckon with, who (via Overture) are suing over of a central part of Google's revenue stream: adverts.

Why is Google hiring Java and web services guys? First, but not most importantly, to keep Microsoft on their toes. As I said, Google is the master of fire and motion.

Secondly, the meat of my theory: they want to offer search as a service, by dramatically expanding the strength, breadth and depth of the Google API. People will use this service; half of Google Labs is probably using it already, in beta form. Once this service becomes part of the infrastructure, which it will, then the API upgrades and improvements that everyone will expect from Google becomes yet more fire and motion.

That's why XML: Web Services. And why Java? Because that's probably what sits between the lean mean bit machines and the service interface: Java has security, scalability, maturity, portability, and it's not Microsoft - what else would they use?

Invocation for a temperamental server

(To be said whilst standing over the afflicted machine, with a stout axe in one hand, and the other hand raised in the three-finger salute)

Oh, you poorly configured, obsolete, unmanaged, slow, crippled, sorry excuse for a Turing machine; you fragmentary, pitiful, unreliable, bug-ridden, much abused pile of weasel-droppings; you neglected, unsung, forgotten heap of wires, transistors and rusting machinery:

Hear my cry!

Boot, I beseech thee; and may aeons pass ere your system processes again slow to calcification; may the skies fall before your RAID array again fails; may the stars die before your fans again spin to a stop; and above all else, do so when someone is there to lovingly apply the hard reset, and ensure that someone is not me.

Whatever happens,

We still have some good things in life: specifically, Ben & Jerry's "half-baked" chocolate, vanilla, brownie pieces and chocolate chip cookie dough ice cream.

Today my credit card gasps in shock, and the patron saint of frugality spins in his grave.

Wheee!

You don't learn by doing things the easy way.

OK, so I got a new PSU today - a sweet QTechnology 350W gold edition. This was not just 'cos I obsessively upgrade my computer, but also because my old PSU had a rattle. PCs should be seen and not heard, except through speakers or headphones.

Anyway, so now Shodan is totally inaudible unless I pay close attention, runs 40C normal, 64 on max load - i.e. when running the screensaver - and 64 is the Intel's max rating for the 3.2 P4.

As long as I remember to turn the fans up when I shut the windows and jack the heating, then I'll be fine. I'm beginning to have doubts about the case profile though. Something like the new Lian Li would be nice, but I don't think they've yet got the envelope down pat. I'm going to wait for a few iterations and see where they go.

BELGIUM!

Not that I have a business case or anything.

I know it's typically English of me to talk about weather, but nevertheless: this morning the sun was shining, I was eating ice-cream, people were lounging about on their balconies. As I write this, it is tipping it down with rain, monsoon-style.

This happens all. The. Time. In JULY.

Belgium!

The C-word

I have trouble not feeling powerless.

The word "cyberspace" is complete cliche, with no real clear meaning. A more accurate & descriptive term for "the Matrix" that Gibson et. al. describe is "dataspace", i.e. 3D representations of information constructs.

What most present-day 3D info-navigation tools (Java 3D desktop, ...) keep forgetting is that nobody will ever want to walk into a Word document when they can double-click on it instead.

The user zooming around the data is wrong. The data should zoom around the user.

Navigable geometries artificially imposed on concepts with no relation to real 4-space is newbie eye-candy at best, and a usability obstruction at worst. We have enough scalars to play with without needing to invent more:

• time
• space
• distance
• money
• population density
• nielsen ratings
• bandwidth

3D "cyberspace" won't be truly useful until we have a widespread method of 3D immersion. As elsewhere, LCD contact lenses are my favourite idea so far.

So, if that's where we want to get, how do we start getting there?

Dataspace is the end result of the ever-increasing visual data density of the 'Net. Given where we are now, how do we increase that?

When we increase the data density, we increase the ratio of what we can learn per pixel.

• As per VDQI, a decent chart or graph can summarize and accurately convey the meaning of thousands of four-digit numbers.
  
  Any infographic such as a chart, map, or graph, can, used properly, convey far more information in far less time than the raw display of the source data that dictates the message of that infographic.
  

• There's no reason that a network-transported vector-based XML infographic shouldn't link to, or contain within itself, the raw data for anyone who wishes to (a) examine or analyse the figures for themselves, or (b) construct their own representations of the data.
  
  The important thing about information is that a) I know that it's always there, b) I know how to get it, c) it's easy for me to get. This is what good information architecture is all about. I don't know the dates of each English civil war, but I can get them using Google. Why memorise them?
  

Software patents

As per the stories, I wonder if this if just FUD or if MS is really prepared to become as hated, if not more so, than SCO. If they go down this road, all the "MS are evil" crowd people might actually have a solid factual basis upon which to make this claim.

Software patents delenda est.

I just had an idea

Wouldn't a cybernetic, biomechanical coffee machine produce a richer, more natural espresso than a normal one?

And you wouldn't have to clean it, it would clean itself. And make little baby coffee machines.

OK, maybe not that last one.

The worst thing about programming

Users. Just kidding.

Unless you're a complete imbecile, you learn things as you work. What this means is that code you wrote a year ago now looks terrible, and what's more you know exactly what's wrong with it and you can't wait to get started on fixing it.

However, there is never time for this. Instead of fixing underlying crappiness, the only thing end-users want is new features, new deployments, new customisation. Nobody will ever understand why you're spending time to test rewritten code that was tested and working exactly the same way (but slower and less elegantly) two weeks ago.

The result is that any code for which you are entirely responsible throughout the lifecycle and which was written in an environment where time is money will always come back to haunt you.

It is not that I have a problem with acknowledging mistakes. It is not that I would rather forget about the code and leave users hanging. It's seeing what is wrong, knowing how to fix it, and being prevented from doing so.

I feel much better now

Life is war against death.

So, yesterday we went rock-climbing in the Ardennes. Outdoor climbing is different from indoor in that nothing is colour-coded, and you can find yourself staring at a blank cliff-face while hanging on by the tips of your fingers and wondering how on earth the last guy got past here. Of course, there's always a way.

While there I met a guy who works as an electrical engineer for a company that makes surgically implanted hearing aids. Turns out there are a lot of similar issues as with the questions below. What I now know:

1. LCDs can scale to the limits of etching technology, which (as any chip-maker will tell you) can go right down to the nanometer level. Alrightythen.
2. Bandwidth requirements - there are several ways of putting bandwidth across empty spaces, of which radio is the least efficient. He told me about the current & future solutions to this, but they're currently deciding whether or not to patent their solutions, so I'm going to keep quiet for now.
3. Detecting brain activity can be done now and is used for people with conditions that prevent voluntary muscle movement. They can use move a cursor across a screen (so 2-bit input) and spell out words, etc.
4. This is currently done either with intercranial or scalp electrodes. Larger detectors with a continuous surface should provide higher resolution.
   
5. The whole area is a boom just waiting to happen.
   

Questions I have

Despite this crap, I do not want desensitization.

These questions are all for one reason, which I explain afterwards. I'm thinking of putting them on Google Answers with a non-trivial sum for each question.

1. To what level can we miniaturise LCDs? Is a 5x5mm 2000x1200 pixel LCD completely impossible?
2. What are the bandwidth requirements for a normal monitor cable? Can we get this bandwidth via very low power wireless at distances of a centimeter or two?
   
3. How thick is a contact lense? What is the maximum thickness for a contact lense?
4. How much power does the best 1cm squared solar panel generate?

I'm wondering how difficult it would be to make contact lenses with inset LCDs. I imagine that billions would need to be poured into R&D to find out if it's possible. More questions:

1. Neurons firing produces current. Current produces RF. How easy is it to detect that current?
2. How hard is it to do this non-invasively? Can we do it for fingers as well as arms?
   

I'm also wondering how hard it would be to build a passive RF-detector that detects impulses associated with muscle-movement, and use it for a direct interface between the brain and the computer. Wrists and fingers are fragile.

Likewise, this kind of thing would, if possible, be the result of Manhattan-level R&D. The result, however, would be worth it. Air-traffic controllers, navigators, programmers, and gamers all dream of something like this every time they sit down in front of a computer.

Media reporting & Opinion

The Crucible: How the Iraq disaster is making the U.S. Army stronger. Phillip Carter is a very smart guy, who knows his stuff.

This is what I like about the 'net, and hate about the mass media. The media see the analysis and opinion as the "value add", which is horse-hockey unless you're talking about the work of the smart, experienced and knowledgeable military correspondents working for America's biggest newspapers, of which I estimate there are less than ten in total. What the media has and that their competition (armchair analysts) don't have is boots on the ground.

I don't care what the BBC correspondent thinks about Bremer. There are people (like Carter) that are 10 times smarter and 10 times more knowlegeable, 100 times more honest about where they stand on the issues - there's no such thing as an unbiased position - and 100 times less likely to do things like make stupid mistakes over ranks, confuse the Individual Ready Reserve with a draft, confuse soldiers with marines, all things that people like Jason Van Steenwyk take so much glee in pouncing upon.

More. I'm not objecting to media analysis & opinion. What I object to is the unending confusion between that and actual reporting. Reporting is "Two marines killed in Fallujah", analysis is "Marines at war with local community". One belongs in a news report, one belongs in an analysis. There is obviously a very thin line between the two, but very few people make the effort to find it.

Stratfor is particularly good at this. So is the Economist, some people at the NYT and the WaPo, and one guy at the LA Times. I've also been told that Le Monde Diplomatique is supposed to be very good.

Damnit.

Business is a big board game.

Anyone who knows me has heard me say over and over again that (a) learning is a process that should never ever stop, and (b) change is life. No change, no life - if you refuse to change, you might as well be dead.

I'm in a post-anticlimax frame of mind.

Good Grief.

For the record, this makes me absolutely sick to my stomach. Bad, Wrong and Evil does not begin to describe it.

Google's "beta" habit is an extemely effective form of fire and motion. They ignore web standards because to them, web standards are fire and motion.

In review

I specialize in idle speculation.

Gradient is the second software project that I've carried through to completion, and the first for which I've published source code and documentation.

I had no idea just how much work is involved in actually publishing source code properly. I was expecting it to take one month, and instead it took three and a half.

The code itself does very little - and it's difficult to explain the potential it has without some flashy examples, which I don't have at the moment.

I haven't received much feedback on it yet, because I haven't spent any serious time on PR. Even if the thing never grows legs, I've learnt a lot by doing it:

• It was the first project for which I used Eclipse, which I use everywhere now.
  
• Same with Ant.
  
• Hyades - a very cool memory profiler. The code is truly impressive, both in it's capabilities, and it's use of system capabilities...
• As always, every bug you find, you learn a little about programming.

There are a number of things I could do next, but the most interesting one is to help fight software patents. We Shall See.

Camera phones as mice

Never start a blog with a hangover.

Mobile phone cameras combined with pattern recognition software has killer app potential.

Semacode is phone software that uses pattern recognition to extract hyperlinks from 2D barcodes.

Spotcode uses a similar idea for circular codes that enables the user to shift, pan and rotate, essentially using a mobile as a pointing device. The phone interfaces with the display using bluetooth.

The people behind spotcode also see the phone as becoming a storage and authentication system, which is entirely rational - mobiles are the closest thing we have right now to a personal trusted computing base.

The first missing piece of the puzzle is a similar scheme for movement in 3D. Moving the phone back and forth, and tracking the phone rotation over all three axes.

Secondly, as far as I can tell, there's no J2ME API for camera access.

Lastly, both semacode and spotcode are proprietary :-) but that's just me wishing I had something to hack on.

I'd like to see phonecam-based interfaces become ubiquitous for things like public smart displays, info-points, (such as floor plans), etc. This type of interface has the potential to surpass touch-screen technology, which is normally the chosen solution in this kind of situation.

A camera phone that also functions as a normal bluetooth-enabled mouse would be interesting.

Use cases:

• As with the spotcode website, bluetooth-enabled LCD displays for airport floorplans. Key points: "You are here" info, "Select destination gate" (a perfect example of throwing an interface) combined with route planning, flight information tracking.
  
  
• Corporate floorplans, employee directories (access protected)
  
  
• Supermarket product search (and suggestions)
  
  
• Others I'll think up later.
  

What the hell?!

My intention is to put an introductory post here, and then forget about this blog for six months.

Then I'll make a one-line post apologising profusely to a non-existent readership for the lack of posts, and promising more content in future. Then I'll put a big animated "under construction" gif on the front page.