August 28, 2002
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!).
August 27, 2002
More useful gadgets
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.
August 20, 2002
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:
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:
function SomethingWhichNeedsToSetAProperty( sPropertyName, x, y, z )
// and finally the listener
function OnPropertyChanged( sKey, pValue, bLocal )
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.
August 15, 2002
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.
August 14, 2002
Forgotten, but not gone
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.
Released today: Groove Workspace 2.1. Several things you'll likely find worthwhile in this release:
August 13, 2002
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?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....!)
Daniel Castillo asks some good questions:
a)the integration Groove X Outlook does not exist for trade names or problems of API?
(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
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.
(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...!)
August 12, 2002
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.
U.N. worldwide survey
Via Michael Mussington: Subject to Change: U.N. Survey Result (Found Object)
August 11, 2002
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).
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.
August 08, 2002
Very cool. Ray at play.
August 06, 2002
August 04, 2002
It's a beautiful sunny day here in Henley-on-Thames, and I'm sitting ten yards from the river. Thank you, SSID 101!
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:
[ /* more blogroll to follow */ ]
The views expressed on this weblog are mine alone and do not necessarily reflect the views of my employer.