July 29, 2003
Computerworld, Meeting of the Minds:
Swarming is a type of collaboration in which large numbers of geographically dispersed people quickly self-organize in a peer-to-peer network to deal with a problem or opportunity. It's a fluid, shifting network with no central control or hub. A swarm can be as complex as a global business network or as simple as a "cell phone posse"
July 23, 2003
Jef Raskin interview
at Ubiquity: widely rambling, fascinating interview with Jef Raskin, the man behind the Mac (inter alia).
Another example is the absurd application of icons. An icon is a symbol equally incomprehensible in all human languages. Whatever language you know, you have to learn the meaning of an icon anew... Just look at a typical directory menu; a flood of identical icons distinguished only by (gasp) words! Ever notice that those little tips come up to explain icons are words? Note that we don't have little icons pop up to explain words.And about THE,
I just call it "The Humane Environment" because it's meant to be humane. It treats human beings well. By contrast, the present GUI interface was meant to make conventional computer structures more accessible... The operating system is the program you have to hassle with before you get to hassle with the application. So instead of trying to gussy up everything and put these various wolves in sheep's clothing, I got rid of the wolves.
July 22, 2003
Groove, small business, and invisible infrastructure
At a very high level -- I know this is silly -- but the wildest vision is that [communication technology] disappears into the background and we don't think or talk about it anymore... You have to care about how people interact with one another and [about] social dynamics in order to be successful in this kind of endeavor. And so, if you find yourself talking about technology a lot, you're probably not thinking about the right thing.and a story For Some, the Godsend of Groove:
Some of Groove's customers exhibit a frankly evangelical zeal for the product, and Lazar is no exception... "Our CEO at least once a day is cursing at me about our server and our networks, so I would love to see the day when all of that will disappear," he says. "I could really see just doing away with the network and doing all of our functioning on Groove. I think that is within the realm of possibility."Of course "doing away with the network" doesn't mean you can actually dispense with connectivity, just that it disappears from your radar screen...!
July 21, 2003
It would be really interesting to use the hyki in a meeting. It's so very unstructured that repeated usage should quickly grow its own conventions - which I could imagine being packaged as "hyki templates", with for example a set of default pages for MeetingAgenda, MeetingAttendees, and so on.
The current version (all 5 hours' work...!) is rough, experimental, and unlikely to scale robustly. Basically it doesn't do "transaction distribution", it does "page distribution". In practice this means that (unlike Hydra and Groove text tool) page-level conflicts are resolved by "last edit wins", and that any simultaneous page edits are a conflict. Whereas, with a command-coordinating system, individual keystrokes or character-level edits could be applied independently on a page. With the "page distribution" model I'd need to get into performing HTML diff, and I really really don't want to go there.
But, again, I'm quite fascinated by the potential of a tool like this. Immediate enough to be useful face to face. Divergent enough to support an explorative, brainstorming group activity. Persistent and awareness-enabled enough to handle distributed groups too. If you want to take it for a spin together, drop me a note.
Of course I couldn't resist hacking one together, using Groove Web Services...
July 17, 2003
BoingBoing: Firewalls are broken:
Firewalls are predicated on the notion that trustworthy people are inside your network and untrustworthy people are outside your network. Despite the obvious untruth of this -- the CEO goes home with her laptop and is treated as untrustworthy; an employee opens a trojan and has his box r00ted by a script-kiddie in Belarus, and is still treated as trustworthy -- we persist in using them, and then get surprised when they fail....pointing to a (fairly content-free) VNUnet article about the dangers.
Related: Ray; Jon Udell and PJ Connolly.
Out Of Office
Intranet Journal, Groove and Microsoft Take Office Out of the Office:
Groove Networks is getting its groove on with Microsoft's SharePoint in a pairing that brings big benefits to mobile intranet users. Separately, each product has a lot to offer, but together they offer an ideal solution for mobile professionals that neither alone can provide.
Julian Bond quotes Frank: "Total Criminalization was the greatest idea of it's time and was vastly popular except with those people who didn't want to be crooks or outlaws. So they had to be tricked into it. Which is one of the reasons why Music was eventually made Illegal".
Charles Miller: "I have a stack for significant tasks that is two deep. Any more and I crash".
July 16, 2003
Rather, I thought it would be maintenance-light. But one itch just had to be scratched: responsiveness. If Groove is very busy, or is prompting for password at the time, the HTTP call blocks. Which in this case means that my non-Groove application stops responding, too. And the startup performance isn't great, because I kick in when the application loads, and my GWS calls pretty much block the user interface until they're done.
The bottom of the stack looks like this (Some, but not much, pseudocode mixed in here to keep it readable):
So, I build a SOAP message and punt it down the wire; the return message is some XML, which gets passed to a parser and a factory where the result (an object or an enumeration) is built and returned to the caller. Errors throw.
The caller has a nice high-level approach, for example:
And there's a middle layer, where the GrooveFileDescriptor, GrooveFilesToolData and my other classes live.
Let's assume that we can make the HTTP calls asynchronously. My code will fire off a Web request, carry on running, and later be interrupted. But that SOAPCall() function can't have a meaningful return value anymore, because the request won't be done. Everything gets split into fragments. At the lowest level we have something like:
and at the top, the code seems likely to become
What other parameters might my callback need? Plenty, as it turns out (local variables, not just "this"). And what about error handling - where will errors be thrown to?
There's a simple switch on the HTTP object which makes it asynchronous: HTTP.open( sReq, sURL, true /* asynchronous */ );. Then you fire and forget; some while later, a COM event fires ("onreadystatechange"), and if readystate is "4", we have data. The "onreadystatechange" handler is can be set easily enough, but it doesn't get any context. Not even a pointer to the HTTP object which fired the event! How are we supposed to know what fired, to even find its readystate, let alone what we should do with it?
A singleton caller? - too clunky. Global variables? - please no! Some sort of timer? Aaaargh!
Closures (basically, anonymous inner functions, which retain the surrounding context) really help fix this. Additionally, I made the synchronous/asynchronous choice completely optional, by just adding an optional callback parameter to the generic SOAP call. Here's some of the reworked code (actually, this is nearly all of the rework right here).
The only wrinkle I'm eliding below is error handling. Instead of throwing, I construct an error object, and pass it back; below we can see the caller check for one of these.
And the caller...
The callback is declared inline -- literally, as the second parameter to the .ReadFile call -- and it's a closure.
July 11, 2003
Clear your schedule, because once you've started reading this interview, you won't be able to put it down until you've finished it.Yesterday evening - looking out over the beautiful Seattle waterfront - I had exactly the same conversation with a friendly retired couple who asked me how I managed to be on the net, sitting on a downtown bench. We got to talking about digital pictures -- I'd left my camera at home -- and agreed that the only sensible way to ship lots of pictures around was by post.
We'll fix that one sometime soon, right?
But, as the saying goes, never underestimate the bandwidth of a truck full of DVDs...
July 05, 2003
Bill de hÓra: Foundations for component and service models:
The core problem of component and service architectures is easy to express: how do I change a published interface without breaking the callers?Mostly to bolster my argument for a four-method API to GWS (of which more sometime)...
Innovation and Conformity in a Microsoft World
Innovation by users. Some good stuff here.
Empirical research is finding that users rather than manufacturers are the actual developers of many or most new products and services – and that they are a major locus of innovative activity in the economy. This finding opens up new questions and avenues for exploration in fields ranging from economics to management of technology to organizational behaviour to marketing research. Examples are patterns in innovation by users, characteristics of innovating users, design of a user-centered innovation process, economics of a distributed innovation process that includes users as innovators, and social welfare implications of innovations by users.(via machinelake)
At SPSFAQ: SharePoint V2 web parts in five easy-ish steps.
CSS slant tricks
(via Pete Cole)
July 02, 2003
Groove Files Preview Gem
Paresh describes a neat way to use the Groove files tool to store and browse offline web pages. Seth and Paresh showed me yesterday: it's surprisingly useful.
[ /* more blogroll to follow */ ]
The views expressed on this weblog are mine alone and do not necessarily reflect the views of my employer.