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.)