Jim Morris's Thought of the Week (or month, or year, ...)
Friday, January 26, 2007
Bluetooth Makes a Cable Look like an Elegant Solution
When my Treo 600 finally died, I bought a Bluetooth-equipped phone and looked forward to joining all those hip people with flashing blue lights in their ears. After slogging through an incredible maze – get the earpiece to sniff around, burrow into the MS menus on the phone to find “Add Device,” and give the “0000” password – I finally got to listen to my phone through an earpiece. Who were the clowns that created this labyrinth? I had always just assumed that Bluetooth would use Ethernet rules: Connection is trivial, many-to-many, and service might require negotiation. I can’t imagine why there’s all the setup hassle imposed upon a very local, lightweight system. I’m told Bluetooth is intrinsically insecure anyway.
Now that I know the nonsense one must endure to use a Bluetooth device, I’m afraid wearing one brands me as a geek.
Here’s an alternate design: Any device would have a small receptacle into which you can insert the end of a copper wire. Putting the opposite ends of a wire into two devices connects them. You can tell what is connected to what by visual inspection. Security is not a problem if nobody is tapping the wire.
posted by Jim Morris @ 11:06 AM
Tuesday, January 16, 2007
Why Basecamp Doesn’t Work
I often run ad hoc projects using email. We all use the “reply-to-all” command and attach Word and Excel documents. As a project extends and grows, this method begins to lose its effectiveness. Versions of files get confused, and a new arrival can get acclimated only by reading a lot of wandering mail, if one can even find it. Basic follow-up is difficult.
Embarking on a project involving twenty or thirty people from all over the place, I decided to try Basecamp. It is a minimalist, web-based management tool supplying messages, milestones, to-do lists, and whiteboards—all delivered in a wiki-style, free-for-all package. Its greatest attraction is the ease with which one can get started and introduce it to others.
Basecamp’s Achilles Heel is that it cuts us off from direct use of all our favorite tools. I want to use my chosen editor, mail client, and calendar to participate in this project. So does every other participant. Basecamp has its own wiki-style editor, distribution list, message archive, calendar, etc. It does its best to communicate with the outside world: messages are emailed and documents are exported in many formats.
Nevertheless, I find that the very notion of being inside or outside Basecamp—requiring importing or exporting—is a problem. At least, it seems to be inhibiting uptake by most people on the project. All of them are virtual volunteers who have many other things to do and preferred ways of doing them. Basecamp’s walls, permeable as they are, are simply too much for us. The biggest problem is that things scheduled in Basecamp don’t propagate to people’s calendars.
I’m sorry to be picking on Basecamp because it is a very nice thing. Virtually every collaboration tool I have tried for the past twenty years has had the same problem, but worse. Its permeability problem is endemic to our reigning software environment. I think the general problem is just too hard to attack, so I’m just focusing on this single tool.
The general problem has two obvious solutions: everyone use Microsoft standard applications or work out general inter-application communication protocols. The former might happen to us if we can’t manage the latter. Is the latter what they mean by “service-oriented architecture?”
The last working inter-application communication protocol I saw was Unix pipes. The designers decreed that every application swallow and disgorge an ASCII stream. The rationale for this was that every application began life talking to a human who was typing characters and reading TTY output. Therefore, application linking could be done through those interfaces that already existed for speaking to humans.
This worked great, but it was overwhelmed by the display-based interface. Everyone has been looking for the display-oriented equivalent of the ASCII stream every since—everyone except the author Neal Stephenson, who once wrote a book-length rant on why we should all go back to the command line interface. He has a point, but we won’t go back.
The problem is that the display interface is so much richer than a stream. However, HTTP took a stab at a narrow, finite protocol. Dumb questions: Is there a way to create a web page that calls other web pages like subroutines using HTTP. Is that what AJAX does?
posted by Jim Morris @ 1:34 PM
Tuesday, January 02, 2007
Your Name Here, Pennsylvania
Pittsburghers are grousing that their Mellon Arena will soon be called “The Bank of New York Arena,” which would make this the first name change for a Pittsburgh sports venue. They would prefer it be torn down. They should get over it.
Last week I drove past Oakland’s newly renamed McAfee Coliseum and Oracle Arena. Oakland is a model of stability compared to San Francisco, which should use the electronic traffic signs to name its two parks: PacTel/SBC/AT&T and Candlestick/3Com/Monster, so that it can more easily update the parks’ frequent name changes.
The days of naming things permanently after civic-minded people or activities are over. Cities are going bankrupt while corporations are thriving. Corporations can afford to buy naming rights for whatever they want. Clark, Texas renamed itself DISH permanently in return for EchoStar giving it free television for ten years. Pittsburgh, which unfairly has a bad image, should happily rename itself Heinz in return for a bail out. How much would Mountain View like for becoming Google, California?
posted by Jim Morris @ 11:02 AM
Previous Posts
Archives
