« January 2007 | Main | March 2007 »

February 27, 2007

Watson and Dr. Watson

I heard a story today that explained something that always confused me: the difference between Dr. Watson and Watson.

Watson is the technology that reports errors to Microsoft when an application crashes; technically Watson ships with Office, and in its Windows incarnation it's known as Windows Error Reporting. But I always knew that if you installed Visual Studio on a machine, it would disable the logging back to Microsoft, because Visual Studio would be launched when an application crashed with an unhandled exception; and the trick to turn the Watson reporting back on was to run the command "drwtsn32 -i". So were Dr. Watson and Watson the same thing?

It turns out no. Dr. Watson was a simple just-in-time debugger that dates back to Windows 95 or thereabouts. When Office first began working on the unhandled exception logging technology, they called it Watson because of Dr. Watson. Actually, to make matters a bit more confusing, they called it D.W., which was technically short for DAD Watson (DAD at the time being the Desktop Applications Division, which was more-or-less Office) but was also a homage to Arthur's moppet-like little sister on the television show Arthur. Calling it D.W. as a way to distinguish it from Dr. Watson reminds me of the story that the state of Washington was originally going to be named Columbia, but the name was changed to avoid confusion with the District of Columbia. Anyway, the D.W. technology eventually became known as Watson, and then morphed into Windows Error Recovery.

And the drwtsn32 thing? It turns out that doing that actually just removes Visual Studio as the default handler of last resort, and restores it to the system default. The system default is Dr. Watson, but Dr. Watson at this point, in current Windows versions, is smart enough to know that it should do nothing, and hands the exception over to Windows Error Reporting. Meanwhile Office still ships with the same Watson technology linked in as its unhandled exception handler. So, technically, when an Office app crashes the system invokes the unhandled exception handler built-in to Office, and when a random app (with no unhandled exception handler) crashes the system invokes a default handler...but since they both wind up being Watson, the user doesn't really notice much difference.

Posted by AdamBa at 10:34 PM | Comments (3) | TrackBack

February 26, 2007

Ease of Deploying Web Applications

Microsoft recently had a planning forum for the next version of Windows, where various people came and talked to the team about issues they should keep an eye on. I'm not actually in Windows, but I went to many of the sessions, looking for free eats (which come to think of it, there weren't any of).

In one of the talks, someone was comparing traditional standalone application development with web development, and listing the pros and cons of each. One of the items he listed as an advantage for web development was "ease of deployment".

Now, I think I know what he meant; he meant that IF you already have a website all set up, it's pretty easy to roll out your new application, and pretty easy to do updates. And you don't have to worry about old buggy or incompatible versions floating around out there.

BUT, to me there seems to be a big hurdle to get over first. If I write a standalone .exe, sure I may not be able to get anyone to use it, but I can pretty easily slap it up on a server somewhere and invite people to download it. If I want to deploy a web app, I need a public web server to deploy it on; not just a place to store a binary, which I can find easily, but a place that will actually let me run the database I need, and run the web server and application, and debug the thing when it crashes, and restart it when it needs to be restarted.

So then I was wondering, are there places out there that will do that for you? Let's say I get my little web app working perfectly on my development machine, running the database/web server/etc on the same box I am running the browser on. Now I want to slap it up in public. Can I do this easily/cheaply? I asked this question of the speaker, and he admitted (ba-rump) that he wasn't a developer, then proceeded to misunderstand the question as relating to the development of the app, not the deployment. He pointed me at dev.live.com, but this seems more like MSDN for the web set.

I basically don't know the answer to this; maybe one of my readers (or both of them) do. Someone said they thought you could develop a web app under Visual Studio and then click a button to publish it to some magic place in the cloud that Microsoft maintains. In my personal case, I already have a website (this one) which runs a database-backed Perl web app (Movable Type), and I know the place that hosts it has all kinds of Perl extensions loaded, so I could at least hack up my own Perl web app. But is there some general free solution out there?

Posted by AdamBa at 10:36 PM | Comments (5) | TrackBack

February 23, 2007

Washington State Quarter

The Washington state quarter is due to come out next month. Hard to believe it's been 8 years since the program started. In a shockingly anticipated non-upset, the design features Mount Rainier and a salmon. The governor chose between three designs, shown at the bottom here; one of the others had Mount Rainier and a salmon AND some apples; the third was a neat-looking Native American drawing of an Orca, which finished last in public voting.

I had a brilliant idea (too late of course): we should have chosen the same bust of George Washington that is on the back, and put it on the front (but with the words Washington 1889 etc). It would have been a double-headed quarter. How cool would that have been?

Posted by AdamBa at 08:53 PM | Comments (0) | TrackBack

Fame Comes to Hub Kittle

A little while ago I mentioned that my smiling mug was being used for a persona within Microsoft. Well, evidently the building in which the relevant team works is now festooned with posters of me in my new persona. Someone who works with me was kind enough to pry one loose from the festoonment and post it on the wall outside my door.

My alter ego is named Gilbert and is a game developer student. His ambition is to work for a game studio. Below the picture, the poster lists a bunch of facts about Gilbert ("I'm learning how to organize & prioritize my work;" "I won't worry about selling games until I work for a game studio"). It's quite diverting to have me staring down at myself from the hallway. And as you may not know, the first major pieces of programming that I did were in fact games I wrote; it was in high school not college, but basically I was the Gilbert persona back in the day as I cranked out my Pac-Man, Q*Bert, and Robotron clones, written in Compiled Basic on an original IBM PC.

Posted by AdamBa at 09:26 AM | Comments (0) | TrackBack

February 20, 2007

"Google 101" class at UW

Interesting article in the paper about a Google developer who created a programming class at the University of Washington. He evidently did it in his 10 percent time (isn't it 20 percent? Was that cut down at some point?). It was a 5-week course for 15 students.

The article promises that "The class is aimed at creating programming prodigies and revamping the way colleges teach computer science". But on reading more, it sounds like they are just teaching the students how to distribute computing across a bunch of machines. Certainly a worthwhile addition to the curriculum, but not earth-shattering. To their credit, Google appears to be doing this purely for the students' benefit, not as a recruiting tactic, at least not a direct one.

Posted by AdamBa at 11:20 PM | Comments (4) | TrackBack

February 15, 2007

Bits vs. Paper

Microsoft used to have an internal newsletter called the Micronews. The first edition appeared on June 2, 1982, and for a long time it was a comforting presence in your mailslot. Then at some point they stopped putting it in your mailslot, and would simply leave them in a stack in the mailroom (which was fine). Eventually the dead-tree burden got too big, and the issue of November 5, 2004 was the final printed one. It turned into a website; but on Dec. 22 of last year the Micronews breathed its electronic last, as it was merged into the main internal Microsoft portal (I know some of these dates, incidentally, because of a nice retrospective site, complete with front-cover images throughout the decades, that is linked to from the FAQ for the new site; it includes a couple issues of the Microsnooze parody version, complete with the Stone Cold Steve Ballmer picture).

One feature of the Micronews that was extant at least by early 1990, when I joined, was classified ads. For a while they were called the "Unclassified Ads", because it was an unordered list of items; then it became the "Semi-Classified Ads", which were very loosely grouped into 5 or 6 categories (something like transportation, housing, furniture, etc).

As a convenience to employees, they started printing the classified ads in a separate insert, the idea being that the newsletter itself was for employees only, but you could bring the insert home. So for many families it was a ritual that every Friday after work they could look through the Micronews classifieds. There was an unspoken notion that since the items were for fellow employees you offered good deals, where "free if you haul it away" was a common price for items that had outlived their usefulness.

Anyway, at some point they transitioned the Micronews classified to an online site, and then last summer they moved them to the Windows Live Expo site. Expo allows communities, and a special "@microsoft.com" community was created for employees.

Since you can filter your listing view by community, you can achieve the same functionality as the old classifieds (and their online version). It's nice that it's online so you can search and all that, and I understand the value in dogfooding our public Expo site. You can even invite an external person to join the community, so your spouse can check the classifieds also. But the feel of the old classifieds is completely gone. The idea was NOT to be a savvy online shopper on the prowl for great deals; it was to scan through for the random junk that your co-workers were unloading and decide that hey, maybe you would take a flyer on a secondhand Costco trampoline.

Yet, I think there are people who totally don't get this, and can't imagine any way in which the old way was preferable to the new way. I also notice this in people who read books online, particularly on their PDAs. To me reading books in electronic form really has no advantages and significant disadvantages. But I think for some people the calculus looks something like:

  • Lousy contrast: -10
  • Small display: -5
  • Inconvenient navigation: -15
  • I'm reading a freakin' book on my freakin' phone!!!: +200

Well, I'll continue to read books on paper, and I miss the old Micronews classifieds.

Posted by AdamBa at 10:19 PM | Comments (7) | TrackBack

February 14, 2007

Bruce Payette's PowerShell Book Now Available

Bruce Payette's book Windows Powershell in Action is now available from Amazon (and soon from a bookstore near you, presumably). There is also a book page at Manning's site. The bio for Bruce says "Bruce Payette is a founding member of the PowerShell team at Microsoft. He is a co-designer of the PowerShell language and the principal author of the language implementation." Normally you would expect such a description to be laden with hype, but Bruce really is all those things. He is also a walking encyclopedia of language design, who can confidently toss off sentences like "The POSIX shell is based on a subset of the Unix Korn shell, which is itself a superset of the original Bourne shell."

I've looked through a PDF of the book, and it's also been discussed and highly recommended on our internal alias. It has a bit too much dorkspeak for my tastes. But the arrangement of the material seems good, the comparison to other languages are very interesting, the insights on language design are priceless, and overall it looks like THE book to choose from the (surprisingly rapidly) burgeoning bookshelf on the topic.

Posted by AdamBa at 09:05 PM | Comments (0) | TrackBack

February 10, 2007

Review of "Dreaming in Code"

[Editor's note: This is the review I submitted to Slashdot; there was some confusion because the article was marked "accepted" and I got a bloglines link to a Slashdot aggregator saying it had been posted at "Wed, Feb 7 2007 8:32 PM". It turns out that as I feared, it was scotched because a link to an interview (not really a review, but what can you do) with Rosenberg had recently been posted on Slashdot.]

Scott Rosenberg's new book Dreaming in Code chronicles the attempt by Mitch Kapor's Open Source Applications Foundation to produce a new Personal Information Manager, code-named Chandler. Beginning in the spring of 2002, Kapor gathered programmers together with the somewhat vague goal of producing a new piece of software inspired by Agenda, a Lotus product from the late 1980s. The new product would be cross-platform and open source; the other details were still to be determined.

Rosenberg's book sports the obligatory back cover blurb comparison to The Soul of a New Machine. It's the latest in a long line that purport to be the worthy successor to Tracy Kidder's Pulitzer Prize winning 1979 tale of a computer project at Data General. Although the book is worth reading both for programmers and the rest of the world, it falls short of the master in a couple of ways.

First of all, unlike Kidder's heroes who eventually triumph over long odds, Chandler doesn't get finished (disclaimer: I work at Microsoft, which produces Outlook, a potential competitor to Chandler). It progresses at an excruciatingly slow pace, until after 3 years Rosenberg gives up and publishes the book. The product is still shuffling towards a 1.0 release; one of the best aspects of the book is that the participants are still out there, blogging and coding away. Chandler may well mirror the Mozilla project, getting bogged down at the start before gradually moving out of the "large pile of interesting code" phase at which the book bids it adieu, and eventually maturing to take over a part of the world; but right now it's unclear what the future holds.

More importantly for the story, Rosenberg does not spend much time delving into the motivations and inner feelings of his characters. Kidder's big advantage at Data General was that he was actually present during the project, rather than relying on the after-the-fact interviews that guide many similar books. Rosenberg was also there for the duration, sitting in meetings and watching the team work. But aside from some quotes from blog posts at the time, we never get a sense for what the characters are thinking. They wind up very two-dimensional, identified mostly by their previous work experience and area of Chandler that they own: there's the old Mac guy working on a prototype of the UI, the Next manager trying to architect the system, the former Lisp programmer designing the repository, the two dudes from Netscape thinking about network protocols, and so on (somewhat strangely, but presumably intentionally, Rosenberg rarely even describes anybody's physical appearance). It's like watching MTV's "The Real World" without those juicy individual confessionals.

This is an important oversight because it is apparent that the participants are not completely aligned in how they would implement Chandler; the slow pace is partly due to doubts about the technologies, algorithms, and features that have been chosen. The result reminds you of a basketball team composed of All-Stars who haven't practiced together much, with each one grumbling that if they were only given the ball more, the team would win. Drawing out some of this internal dialogue would have emphasized its impact on the project. It also would have demonstrated the somewhat artificial nature of the open-sourceness of the project; people were initially brought together and told to work out their differences, rather than being able to evaluate the current state of the project and decide if they wanted to participate (one notable battle is between the team members who want to get some code working and then improve it, and those who want to do more up-front design: the fight continues until those who advocate the former plan give up and abandon the project one-by-one).

At one point Rosenberg actually writes, "By now, I know, any software developer reading this volume has likely thrown it across the room in despair, thinking, 'Stop the madness! They're making every mistake in the book!'" (luckily, he said it about 10 pages before I was about to do just that). Certainly the Chandler team did err in a variety of ways, but to my mind they made one overarching mistake. They ignored the obvious "elephant in the room" problem with their plan: trying to make a distributed PIM that synchronizes without a server. Instead of figuring out an algorithm that would work for that, they spend their time debating over details of visuals and network protocols. It's somewhat puzzling why such an individually experienced team would have such a collective blind spot. In the end it takes a new arrival on the team to point out that this problem is extremely hard, and eventually redirect the project towards a server-based approach. This new person is also the first one with prior experience working at Microsoft, a fact that you can interpret as you wish (to me, as a Microsoft employee, it made the mild potshots that Rosenberg directs at the company seem silly).

The other decision that caused problems, but is never questioned by the team or the book, is the plan to produce an application that runs on multiple platforms (Windows, Mac, and Linux). The fact that Microsoft writes almost all of its software for a single platform is an often-overlooked technical advantage, which makes it simpler for the company to develop applications, and lessens the test burden significantly. The decision to go cross-platform leads to a dependency on a cross-platform GUI builder, which leads to problems when it doesn't support features that the team needs. Although I understand the motivation to go cross-platform, the team also missed the fact that for an open-source project, cross-platform porting is a perfect task for someone outside the core team. Get your code working great on one platform, induce extreme amounts of envy in someone who runs a different platform, and let them scratch that itch until you are cross-platform.

Rosenberg takes a 70-page break in the middle of the book to look back on the history of software development in general, trying to understand if there is a better way. He presents some fascinating research from the early days of programming, making you realize that all the problems we have today were perfectly anticipated by programmers 30 years ago (unfortunately, they didn't have any better answers than we do). I was hoping that I would get some good advice from this section, but his overview of development practices is somewhat cursory, and he gives roughly equal time to the important (test-driven development), the futuristic (Jaron Lanier has resurfaced after his virtual reality heyday and is now somewhere beyond the gravitational pull of the inner planets), and the incomprehensible (Charles Simonyi and his thing-that-Charles-Simonyi-is-working-on-that-nobody-groks). Rosenberg admits that he doesn't fully understand all this stuff, and we have to cut him some slack: we don't fully understand all this stuff either.

A better place to gain wisdom for your own software project is simply to play fly-on-the-wall as the team--despite the best of intentions, no financial concerns, and very smart people--makes the same kinds of mistakes that we always read about, but "know" that we would never make ourselves. They plan too many features, don't make realistic schedules, can't decide on goals for their interim releases, etc. They even have the advantage of a brilliant (to my mind) usability design insight, that the program should present the user with a model based on David Allen's "Getting Things Done" plan of a single to-do list. This is the direction in which Outlook is moving, but the Chandler team nevers takes much advantage of this vision. In the end the project is a great example of what not to do, and Rosenberg does a great job of telling that story. As Kapor muses at the end, "I do think that organizationally and personally we've learned an enormous amount about how to develop software. We've kind of reinvented the wheel. These are things that other people know, so it's taken us a little longer to learn those things. But having learned them, that's a kind of intellectual capital, and I'm absolutely firmly intent on reapplying it and staying the course." It's not clear why the Chandler team needed to reinvent so much that others already knew; but hopefully people who read the book will realize thay they are not immune to problems either, and do a little bit more of whatever it is that you need to do more of, and a little bit less of whatever it is you need to do less of. The question of just what those things are won't be any clearer when you are done reading Dreaming in Code, but at least you will know that you aren't alone.

[Me again. If you are interested in more of my pithy thoughts, here are other reviews I wrote for Slashdot: Juiced by Jose Cansesco, How Would You Move Mount Fuji? by William Poundstone, the movie Revolution OS by J.T.S. Moore, and Breaking Windows by David Bank.]

Posted by AdamBa at 11:32 AM | Comments (0) | TrackBack

February 08, 2007

Higher Female Enrollment at Universities

My old hometown paper, the Montreal Gazette, had an interesting series this week called "Degrees of Separation". Do you know that across Canada, more than 60 percent of university students are women? A decade ago, it was split 50/50. The gap is even larger at the French universities in Quebec. It's interesting that when I was at Princeton the ratio was about 60/40 male/female (it's about even now) and this was a source of common complaint from the men, but the women don't seem too fazed by the reverse.

The series is in five parts: A woman's place ("There are no plans to adopt affirmative action policies or otherwise alter entrance criteria to beef up male enrolments"), Women learn better, faster ("But among younger students...it's the girls who immediately buckle down, do the required readings and put in extra lab time"), When women take the field ("Female doctors now make up 36 per cent of the province's general practitioners and specialists - but two-thirds of physicians under the age of 40"), Why female academics drop out ("The 'leaky pipe' phenomenon describes the tendency of women in science to slip away after each level of study at a far greater rate than men do"), and Academic amazons puzzle over work/life equation ("'Women's entry into the job market has been dramatic; men's entry into housework has been gradual'").

Here's a few more quotes: "Already, more than half of Canada's doctors and dentists are women. Given the current trend, odds are by 2015, your pediatrician, investment broker, family veterinarian, divorce lawyer and therapist will be a woman, but your computer technician, housing contractor, electrical engineer, orthopedic surgeon and member of Parliament will still probably be a man" and also "Universities still welcome thousands of brilliant young men with ambition, dedication and drive. However, women now outnumber men in all but a smattering of disciplines, notably mathematics, engineering and computer science." Or how about "Girls, meanwhile, have been buoyed by the women's movement and programs created to overcome historical disadvantages. Throw in a supportive environment and strong role models - a father who's an engineer, a mother who is a doctor, or a math teacher who pushes the girls to succeed - and these daughters of the feminist 1970s and '80s are taking flight, leaving the boys next door to fiddle with their iPods and video games." Of course, fiddling with video games--or more precisely WRITING video games, which I guess isn't the same thing--is what taught me how to program and led me to where I am today.

Posted by AdamBa at 08:32 PM | Comments (0) | TrackBack

February 06, 2007

My Slide Template Can Pwn Your Slide Template

Engineering Excellence puts on various events, and usually we will have a different Powerpoint slide template for each one. This is to unify the talks at one event and differentiate them from other events. The slide template covers not just the background image and font, but also the colors for titles, bullets, tables, and various predefined shapes. There is an artist in the group who works all this stuff out.

I just got the slide template for an upcoming conference I am speaking at, and let me tell you this is the baddest slide template I have ever seen. I'm probably not supposed to post details in public, but let's just say the slide background looks like what you would see from inside a black hole, and it just goes from there. The colors are sui generis. Most templates have a slide warning you away from certain colors that don't show up well at a distance (red on royal blue is one common mistake). Well, for this template the warning is not to use gold or purple. The fact that the other colors might actually warp your brain enough to make you even consider gold or purple should tell you just how outre they are. With the visual pummeling that the title slide should administer, I doubt I even need to prepare the rest of the presentation.

It's normal to feel this way about a slide template, isn't it?

Posted by AdamBa at 07:06 PM | Comments (4) | TrackBack

February 03, 2007

Dreaming in Code

I finished reading Scott Rosenberg's Dreaming in Code and sent a review off to Slashdot; we'll see if they publish it. If not, I'll post it here. Perhaps you reading this because you followed the Slashdot link from my hopefully-accepted-in-the-future article, although I might have been scooped by the fact that a story was posted today about an interview with Rosenberg on Salon, the site he cofounded.

I agree with Joel Spolsky who found the book worthwhile but was frustrated by the foibles of the team it chronicles. They were a group of very experienced developers, yet they made all the same mistakes that you expect junior developers to make--in spades. Somehow their experiences didn't transfer to the new project, or perhaps as a group they couldn't leverage their experiences as much as they could individually. In any case they seem to feel, at the end of the book, that they have figured it out, but you wind up doubtful that their next project will be any better.

If you are looking for updates, the most basic is one from the OSAF blog about "Where we are today". Here is the website for Chandler itself (it's not just a Personal Information Manager, it's an Interpersonal Information Manager). These include screenshots, which look a lot like Outlook 2007 (not to imply it was ripped off, just that there is only so many ways to display this type of data). Although the calendar overlay looks pretty neat. Also, since I was curious what everybody looks like (something Scott Rosenberg doesn't really get into), here are pictures of Philippe Bossut, Donn Denman and Andy Hertzfeld (among others), Lisa Dusseault, Chao Lam, Ted Leung (scroll down), Lou Montulli, Sheila Mooney (on the right), Katie Parlante, Aleks Totic, and Michael Toy (bottom picture). Couldn't find any of Andi Vajda. Mitch Kapor, of course, looks like himself, but with more grey hair.

Posted by AdamBa at 04:56 PM | Comments (0) | TrackBack

February 02, 2007

Phil and Willie

Today was Groundhog Day, as you probably know. Punxsatawney Phil did not see his shadow, which means spring will arrive early (I always have to reconstruct what it means by remembering that it seems backwards: if he sees his shadow it's sunny, which is cold at night and thus more winter; no shadow (as it was this year) means it is cloudy and thus warm at night, so spring is on the way).

It turns out that the early spring is actually rare; you can see that, global warming be damned, he has never had two years in a row where he missed his shadow, but he has had many long streaks of cold-and-sunny, including one memorable string of scaredness from 1903 to 1933 (the Little Appalachian Ice Age, I think that was called). By the way, a woodchuck and a groundhog are the same beastie.

You may not know that there is also a Canadian version of Phil, called Wiarton Willie--the second most famous of a raft of mesmerizing marmotas. And yes, he is trumpeted on the Canadian news in a vaguely embarrassing, It Happened in Canada way. You should read the Wikipedia page on Willie, it features more alcohol consumption, mythical-northerliness, decomposing bodies, and double murders than a fistful of Robert Service poems.

What both these places have in common, besides groundhogs, is that they are relatively in the middle of nowhere. Punxsatawney is in western Pennsylvania, roughly in the middle of a triangle defined by Erie, State College, and Pittsburgh; and Wiarton is in Ontario yet is not a suburb of Toronto, 'nuff said. Basically if you started in Traverse City, moved eastwards across Michigan, plunged into Lake Michigan (which would likely seem appealing at that point) and somehow emerged on the other side, you would be near Wiarton. Bring your curling broom and your pancake recipe.

Posted by AdamBa at 10:58 PM | Comments (1) | TrackBack