Ashok's Weblog

Ashok has a weblog!. Must reading.

Finally... a kettle!

I'd like to share some of my inane glee with you: I found a real electric kettle. In Linens & Things, Endicott St they actually have a selection - not yer "hot pots", but real kettles (I balked at the shiny $70 Cusinart version, though!).

Custom development

Ashok (who I'm trying to persuade to start a weblog) apparently now has a full development team in place, ready and able to build Groove stuff.

More useful gadgets

Ron Lusk gives some useful advice about finding kettles. He also links to the wonderful Conference Bike.

Kettles

Listen to what one satisfied customer has to say:

You can make a cup of tea in about 1 minute. I also like the design... It looks sleek and at the same time it's very functional. In the clear strip you can actually see your water boiling, I thought it was kinda cool.

I just can't find a kettle in any stores here - in a couple of places the shop assistants simply didn't know what I was talking about. Incredible.

Instance ID

Here's a trick for the list (sometime I'll sort my own categories out...): generating your own instance ID for properties. Read on.

I use the PropertyList for all sorts of things. When listening to a propertylist, the event handler looks like this:
PropertyList_OnPropertyChanged( sPropName, pValue, bIsLocal )
{
// do stuff
}

The "bIsLocal" boolean flag tells you whether that property changed locally or on another user. It's useful, in principle: a good pattern is to have your property "setter" independent of the property "listener", so you might set a property in response to a UI gesture, then use OnPropertyChanged to hear what other users have been doing and update your own UI appropriately. In that case you really don't want to listen to events which you caused.

Unfortunately, the "local" flag is a sledgehammer. If you use "open tool in new window" (so you have two instances of the tool UI running), any properties set by your tool won't appear "remote" to the other instance.

So, I like to wrap properties up inside an XML element (which buys some more flexibility anyway), and tag that element with an instance-ID which is unique to that actual instance of the UI code.

To do this:

var g_sSessionID;
function Initialize()
{
// UI gluecode initialization
var pGuidGenerator = GROOVE_GLOBAL_MISC_POINTER.OpenGUIDGenerator();
g_sSessionID = pGuidGenerator.CreateGUIDBase16();
}

function SomethingWhichNeedsToSetAProperty( sPropertyName, x, y, z )
{
var pEl = CreateNewElement( "urn:groove.net:something" );
pEl.SetAttribute( "SessionID", g_sSessionID );
pEl.SetAttribute( "x", x ); // etcetera
PropertyList.SetPropertyAsElement( sPropertyName, pEl );
}

// and finally the listener

function OnPropertyChanged( sKey, pValue, bLocal )
{
// assuming pValue is an element (may depend on the propertyname)
var sSessionID = pValue.OpenAttribute( "SessionID" );
var x = pValue.OpenAttribute( "x" ); // etcetera
var bNonLocal = (g_sSessionID != sSessionID);
if( bNonLocal )
{
// do stuff with that propertychange
}
}

Groove tips

Paresh is running a category of Groove programming tips and tricks at his weblog, which I strongly recommend to anyone building Groove tools. Most of what I know, I learned from (or via, or otherwise influenced by) Paresh.

Future tips might also include gems such as: when to use CreateDelta() versus OpenTransaction(); why holding a tool reference beats an engine reference; trace utils; and oodles more good stuff.

Bayes

ifile uses Bayesian techniques to file mail in the right folders. Looks promising. It's a pity that the most prominent desktop use of Bayes is still the hated Clippie, which just never seems to learn at all; and that Microsoft's OfficeXP "menu hiding" is even dumber.

Review

vowe reviews Groove 2.1 (German) (babelfish) - likes the performance ("ein eklatante Verbesserung") and Notes integration; still waiting for search, print and spellcheck.

Forgotten, but not gone

Wired News:

despite no meaningful update in about 15 years... "It was and still is the most significant tool I've ever used," said Richard Wanderman, a technology consultant and, at one time, a leading advocate.

The software? Hypercard.

[Bill Atkinson, the developer] feels that if only he'd realized separate cards and stacks could be linked on different people's machines through the Net -- instead of cards and stacks on a particular machine -- he would have created the first Internet browser.

That's still a dream worth chasing - I'd do it as a Groove tool. Don't laugh; it could be insanely great.

Groove 2.1

Released today: Groove Workspace 2.1. Several things you'll likely find worthwhile in this release:

• Performance. Especially if you defragment after installation (and here a few more performance tips, via our CEO).
  
• Richtext instant messages! Forward instant messages! (Such little things. But I like it).
  
• Notes On-Ramp. Check the Actions menu in your email database - wow!

Microsoft

Jeff Raikes interview in InfoWorld.

InfoWorld: But with the edge services project that Ozzie is working on, do you see that as having implications for SharePoint directly, or is that just a solo group initiative?

Raikes: Yes we're working closely with him on that. I mean, that was one of our goals with the .Net platform and that's an example of that technical collaboration. But in this context I was more thinking about how you can start out in a peer-to-peer environment and, as it grows into something that's more broadly used, you may want to get it into more of a robust managed server environment. And he has that model and that's a little different than the Edge services project. That's the idea of Groove having servers that allow corporations to do some of what they do in terms of a service.

That's an interesting (and to me unexpected) perspective. Groove has long had the capability to provide "central peers", via the Enterprise Integration Server aka Bot server, and that's a great integration point: the server is always-on, can live behind the firewall next to your internal enterprise servers, yet function as a peer in spaces shared with external participants.

Of course we're also building strong Sharepoint integration, and there's a lot of sense in taking Groove shared spaces -- starting out in a peer-to-peer environment -- and moving some of that to a wider, or more occasional, or more "repository-like" environment: STS, SPS and so forth. Weblogs, even. Hmmm....!

Meanwhile, Phil Wainewright thinks that Microsoft is "suddenly faced with the prospect that its championing of XML web services is about to cannabalize its almost total dominance of the desktop software market". I honestly don't get that. What sort of client software should function as a web service? (hmmm....!)

Questions

Daniel Castillo asks some good questions:

a)the integration Groove X Outlook does not exist for trade names or problems of API?
b)promise of web services "does not seduce" the Groove Network to connect the Groove to other services (ex:Blogs, Klogs and others)?
c)The Forms Tools has future? in case that an beginning user decides to invest in the Groove, which the adequate tool oara the development?
d) Finally, what to wait for the future (Groove 3.X and 4.XXX)

(I'm going to guess my way across the language barrier a little - is Groove as big in Brazil as it appears?)

- There's already some neat Outlook integration: pulling a mail thread into a Groove shared space so you can actually get together to nail things down. The same sort of functionality is available for Lotus Notes in version 2.1 (real soon now). The Outlook integration is actually quite straightforward; it uses the Outlook APIs in a standard COM addin, which creates a temporary .GRV bootstrapper file, which gets you a shared space.

- Our web services work will make it a lot easier to connect non-Groove systems -- Java especially -- to Groove shared spaces. Going the other way, we're doing a lot of work around Sharepoint (with WebDAV and some other stuff), and of course there are several of us now blogging, and very interested in the intersection of Groove and blogs. But that hasn't reached "product" yet.

- The forms tool is pretty good. Extremely flexible, especially when you start scripting it. (When I saw the first prototypes I was sceptical, but Rob proved me very wrong indeed). It very definitely has a future. If you're looking for a quick and simple way to add some structure into the way your Groove shared spaces handle data, this is it. I think in fact about 80-90% of custom enterprise Groove applications can be built with Forms.

- I honestly don't know what the future holds. I could guess: more tools; more services; more integration. But a lot of this will be determined by what customers need and ask for.

Groove, Windows, etc

Russell Beattie (via Jeroen) has a good bunch of things to say about Groove. Quite a few important things there. Let me just talk about a couple of them.

Russ says

At the beginning Groove was making noise about being developer agnostic - you could create Tools by using their collection of XML file formats and whatever language you wanted - VB, Java or even JavaScript if you wanted to. But now it's obvious that Groove is basically a Microsoft only area. That's too bad. Also, it's becoming apparent exactly how difficult it is to develop custom apps for Groove - it's not Notes Next Generation by any stretch.

It's hard to disagree that building Groove tools is too difficult. I've had a lot of practice, and it still takes me a couple of days to build anything interesting. To be really effective, there's a depth of knowledge you have to acquire over time; and to get anywhere at all, you gotta climb over a big learning curve. IMHO the best way to do this is to go through developer training. (There are some good books, too).

But yesterday, one of my chance corridor chats was with John Guidice, who's product manager for some of our tools. I dont think John's really a hands-on developer. But he mentioned how he just sat down and built a real, functioning, collaborative, deployable Groove tool in ten minutes.

How? This is the VS.Net stuff which Jay and Sam and co have been working on; first time I saw it in action. This is the sort of leverage which takes it even beyond "Notes next generation".

(I still haven't crossed the .NET rubicon myself - I wonder if that'll be an easy transition from my Java days. We'll see...!)

Relocation

America's decidedly weird. Even the light switches are upside down. I keep forgetting left and right (especially when those road signs say "left lane must turn left"). What's "turn on red" (and why do people keep beeping their horns at me)? What does a flashing red light mean? How can a road be route 1 and 62? Are the Sunday papers just for keep-fit exercise? Why don't displayed prices include sales tax? Do I need a SSN and a 401k to go with my H1B and I94? Why don't you have Radio Four? What's that New Hampshire all about, huh?

But it's beautifully warm and sunny, which beats flash floods. I'm here alone, for now; the family will follow when we find somewhere nice to live, bring our container out of customs, and organize some transportation. With luck that'll happen soon enough for them to acclimatize before school starts.

Working as a Groove employee in the UK has been even harder than working for myself. I've been in the job for almost six months, but still feel reactive -- task-driven -- because I'm so isolated from the organizational context. Computer-mediated communication is good, and I'm even getting familiar with using a telephone, but these are still low-bandwidth ways to connect with people and require a reason for connection - the cost of "accidental connection" is very high. Sitting in the home office, I didn't much bump into colleagues in the corridor, the restaurant, by the water-cooler. Equally, teleconferences don't work, unless you have an agenda. I don't have an agenda, I just want to be in an environment where I could honestly put "instigator" on my business card again.

Those chance interactions are really important ways to find "what you don't know you don't know".

So, it's Monday morning, and there's a whole lot of interesting work to look forward to.

The 5k awards

Via Langreiter: the5k.org : winners. Some tiny and cute uses of DHTML.

U.N. worldwide survey

Via Michael Mussington: Subject to Change: U.N. Survey Result (Found Object)

Service decomposition

I guess I'm contractually bound to read anything which Ray says is a pre-requisite. So, I've been mulling the paper he referenced about modularity in technology and organization design. It's an erudite and interesting survey of the role of modularity in technology, and application of some modularity and decomposability principles to the structures of organizations, calling in via the thorny world of property rights.

There's one word which is conspicuous by its absence, and which can operate as a scalpel: service.

A service viewpoint is indispensable in building component software (especially in asynchronous structures). Saying simply "this is a component" (or even "an object") doesn't much illuminate the interfaces between one component and the rest of a system. But things become very clear when you start talking about the services which one component requires from others, provides to others, about the service levels which can be expected, and about the types of notification which consumers will need whilst their service is being performed. "Web Services", incidentally, is a great term for just this reason. Groove's software architecture is quite cleanly structured around abstract service providers: transport, security, storage, and so on.

The thin abstraction above a single component then becomes "provider": an abstract service provider creates an interface by which you can obtain services of a particular class, appropriate to your needs, with very little knowledge of the inner workings of that service's provision. You get "mix and match". Within an application, this begins to let you maintain multiple versions of componentry which might be revised, on different timescales, largely independent of each other.

The same is true organizationally, and in discussing property rights (authority, alienability and residual income: all important aspects of property, but I read too much Proudhon to take that stuff seriously) you miss the point of organization. The structure of The Firm is not primarily to consolidate property rights (a defensive model), but to enable growth (an expansive model). Growth requires innovation. Modularity of service enables innovation.

In an organization decomposed by service provision, strategic outsourcing decisions can be made quite easily; the Firm becomes flexible not only because it inherits the ability to expand and contract the workforce overnight (the commonly-held negative viewpoint), but because the service interface is an entrepreneurial interface understood by the outside world. If you build a world-class service unit, it can operate entrepreneurially: its customers can live inside or outside of the Firm. (I've worked in the past with one interesting company which has exactly this viewpoint). Many industries have already seen the widespread emergence of a "provider interface" in human resources, in the supply chain, and so on.

Now, I'm not arguing for decomposition of the company per se, just as I don't often argue that Groove would take over the world if it were to open-source its componentry. There are real-world interdependencies which often cut deep with good reason. Our QA team, for example, provides great service: file a bug report, and they track it through triage and resolution, providing callback notification if you wanted that. But the service viewpoint from one customer is different to the viewpoint offered other customers (GrooveQA Implements ITrackBugs, but also GrooveQA Implements IManageRegression, IRunVariedTestEnvironments, and much more). This is true both of software and organizations. The "re-composition" -- providing multiple interfaces, to give a coherent customer service -- is still not an easy design task.

I'm also certainly not arguing for price-oriented contracting. Price is one of the least useful metrics imaginable; simple price competition creates problems in structural inequity and false accounting of externalised operational costs. It's vitally important that we find alternatives which are less likely to destroy the world and cause misery for millions of its inhabitants. Given the choice, I wouldn't call on a transport service which caused a huge memory leak; but industry seems happy to outsource services to minimise cost regardless of environmental or human concerns. I don't have any easy answers there. Software's so simple, sometimes.

It's a useful thought-experiment, though: outsource your group. What services do you provide? Who are the customers? What internal process gains can you envisage if you clarify the current interfaces? What structural changes would be required, and what optimisations would it bring, if the collection of interfaces were different? Who else might require those services, and under what circumstances would it be appropriate to provide them? (The "GrooveConceptDevelopmentTeam.idl" is part of my agenda for next week).

Telecom

Bob Frankston on The Economist, the Internet, Telecom and the Dow. Strong stuff, this.

In 1900's there was a real telecommunications industry just like in the 1800's when there was a thriving business in transporting ice from frozen lakes to warmer climes. Just as refrigeration put an end to the need for buying ice, the Internet has put an end to the need to buy telecommunications services from others. We just need commodity connectivity.

SeaChalking

Very cool. Ray at play.

Yay!

Have visa, will travel. Whooo!

Why We Blog

Ray Ozzie on Why We Blog

Sunny Henley-on-Thames

It's a beautiful sunny day here in Henley-on-Thames, and I'm sitting ten yards from the river. Thank you, SSID 101!

parseInt

I was hit by a weird JavaScript-related bug: parseInt(n) returned zero, when n was a plainly numeric string.

Turns out, n was "08". And any string beginning with a zero is treated by parseInt as octal! Rather than throwing an exception, jscript just throws the 8 away. Is octal really used, anywhere (except Unix file permissions)?

Two lessons from this:

1. parseInt(n,10)
2. Octal should have been killed thirty years ago...