« January 2008 | Main | March 2008 »
February 29, 2008
Tracking Construction Progress by Satellite
I drove down to Los Angeles last weekend and crossed the Benicia-Martinez Bridge. It carries Interstate 680 across the Carquinez Strait, northeast of San Francisco, and is the bridge you would cross if driving from (say) Sacramento to San Jose. I know, you are all thinking, "If you insisted on detouring towards the Bay Area, how come you didn't head just a bit further west to cross the Al Zampa Bridge?", all I can say is that I was in a bit of a hurry (a poor excuse, agreed).The Benicia-Martinez Bridge is now two bridges, with southbound traffic on the old bridge and northbound traffic on the new bridge, which opened last August after being under construction for several years (there is also a railroad bridge which sits between the two road bridges). I was looking at satellite photos of the bridge, and noticed that different sites captured different phases of construction of the new bridge.
First you have the Google Maps view, where about half the piers haven't been started. On Yahoo Maps the piers are mostly above the waterline. In the Live Maps image the piers are done and parts of the roadway are in place. Mapquest has the roadway almost complete. And on TerraServer the bridge looks finished (if you want to look at different systems, start with the WikiMedia GeoHack page for that location).
I was actually expecting that they would all be sharing the same satellite imagery, or maybe a couple of different sets; the fact that all 5 were different is surprising. And if you knew the details of when the bridge was constructed, you could actually tell pretty closely when each picture was taken.
Posted by AdamBa at 10:13 PM | Comments (2) | TrackBack
February 26, 2008
The Wiki and the Handbook
There are two internal sites at Microsoft which have similar goals, both under the aegis of Engineering Excellence: the EE wiki, and the EE Handbook (the internal URLS are http://eewiki and http://eeh, respectively).The wiki is a wiki, whch means that anybody can modify anything at any time. It does track the corporate network login of the person making each edit, so outright defacement is unlikely, but other than that it's fair game, and if you make an edit it is immediately available for everybody to see (right now, most of the edits are done by people in Engineering Excellence; one of the things I've been doing to try to change that is have every class I teach make at least one edit to the eewiki, however trivial, so they get a feel for how easy it is). The wiki is very convenient place to put information, for example for any topic that we teach such as formal inspections, the eewiki page will have a section "teams at Microsoft using formal inspections" and we ask people to add themselves to the list if they are using them.
There is also the Handbook. This is a website running on technology developed within EE for the specific purpose of hosting the Handbook (the eewiki currently runs on FlexWiki). It has a sophisticated layering model where there is a base handbook, then teams can replace specific pages, or let them flow down from the base page, and so on down the hierarchy. Also, there is a workflow involved in making changes, in which they are shepherded through by people in EE (such as myself), submitted to a team of editors and content architects, and then updates are queued up and published on a regular basis.
It's the standard short head vs. long tail situation, and you may not be surprised to hear that on the dev excellence team, anyway, the eewiki is winning out. We do occasionally drive Handbook changes, and there are useful pages in the Handbook that I show off in class, but our go-to place for storing information is the eewiki. This includes both stuff that is internal to our team (such as outlines of courses under development) and material intended for the broader Microsoft audience. So the experience for somebody outside our team (but inside Microsoft, of course, since the eewiki is only available on the corporate network) is a mish-mosh.
I think a bit of it is that we're being lazy and don't want to deal with the Handbook workflow, so we make the quick eewiki edit without worrying whether it is the best experience for our customers. But I also think that there is something "developer-y" about favoring a wiki over something more formal (other teams in EE have different balances of wiki vs. handbook; I'm pretty sure the dev team is the most wiki-centric). The fact is that the wiki is a much closer approximation to how we write code. The trend in software development these days is to be more "agile" and empower people to complete things on their own, and the wiki definitely fits in that model better than the handbook. So for better or for worse, it's no surprise that we devs feel more comfortable there.
Posted by AdamBa at 09:31 PM | Comments (0) | TrackBack
February 25, 2008
Body Modification
When my parents were visiting at Thanksgiving, they listened to a webcast of the science radio show Quirks & Quarks (excellent show, by the way). This particular episode featured an interview with Gary Taubes, author of Good Calories, Bad Calories. Taubes, who is a science writer, not a diet seller, says that all the actual medical research he could find indicates that the way to lose weight is to cut carbs, and the prevailing advice to cut calories is based on a biblical notion that you need to suffer in order to lose weight.I had heard this before; it's what the Atkins diet is based on. I had previously suspected, as I wrote a long time ago on a website far, far away, that cutting calories was the key to losing weight, and the Atkins diet was really just a clever way of making you consume fewer calories (by making you pay attention to what you were eating, mainly). But Taubes was saying no, that the "3500 calories is one pound" rule was a myth, and it really was about cutting carbohydrates, not calories.
At the time I had just signed up for my foray into acting, and I figured it wouldn't hurt if my character looked a little emaciated. So, I decided to try cutting out carbs, while eating whatever protein and fat I wanted, and see what happened. I didn't buy any books, just looked at nutritional labels and tried to get carb intake as close to zero as possible.
So what did happen? Well, I certainly enjoyed the delicious omelettes with prosciutto and bergenost (courtesy of Costco) that I would whip up in the mornings. And I was able to use the fact that I was conducting a scientific experiment as an excuse not eat a bunch of junk I didn't need to over the Christmas holidays. BUT, although I did lose about 5 pounds in a couple of months (with my carb avoidance trailing off gradually towards the end), I still felt like I was also eating less, in particular at work because I would wind up not eating half my meal, and also because I essentially cut out all desserts. So it really wasn't clear if it was the carbs or the calories. Also, although I wasn't overweight to begin with, there certainly was no "the weight just melts off effortlessly" effect. In the end, the experiment was inconclusive.
I did one other body modification for the play: I grew a goatee. Originally it was going to be a beard, but the director decided that a goatee would be better.
After the last show I shaved it off. This is the before and after view; to frighten the children I stopped at an intermediate point with just the mustache, which I don't think I would ever wear out in public:
Posted by AdamBa at 09:02 PM | Comments (1) | TrackBack
February 22, 2008
Is There a Services Mentality?
There is lots of discussion at Microsoft these days about the "services mentality", meaning the way programmers who work on services need to think. The implication is that it is differet from the packaged software mentality that most developers at Microsoft have grown up with.Certainly writing a service is different from writing packaged software, but within the realm of packaged software there are also huge differences. Writing a Windows kernel driver is very different from writing an Xbox game, but is it more different to work on a service? As with any software, when working on a service you have a layer above you and a layer below, and you stitch them together while implementing your requirements. You may have some different sorts of requirements, for example that the service can be upgraded without bringing it down, but packaged software also has a wide range of requirements.
I've been asking people about this and I haven't got back much that really felt "different". BUT there is one thing that seems to stand out that really is a change in thinking when working on a service: you have to expect and deal with failure.
If you're working on an Office app and you get a wierd error from the video display driver when trying to draw a graph, you will in all likelihood expose that error to the user: either by mysteriously failing, or by poppping up an incomprehensible error code. You may realize, in the back of your mind, that some very very small percentage of the time this will actually happen (a one-in-a-million Vista issue will still affect about 100 people), but you still view it as an unnatural event that you can't be expected to accomodate in your code (some errors, of course, are common enough to be handled, such as running out of disk space, but those are the exception, not the rule). So you let the customer figure out what to do (reboot, restart the app, whatever). I don't mean to make us seem callous or uncaring about user-visible errors; certainly you try to handle the common ones, but if you think of all the possible error codes that a Windows API can return, your code can only include specific responses for a small subset.
On a service, given the number of machines you may have in your data center, the distance that your data has to travel and the relative imperfection of the path (network vs. bus), and the knowledge that the customer has no ability to poke your computers, you know you have to handle failures gracefully--and that means ALL failures, not just the ones you can think of.
I consider this a mind-shift because it colors how you solve other problems also. A packaged software person who is given the problem of designing a system that can be updated on the fly may come up with a centrally managed system in which the remaining computers are notified when a subset of the data center is going to be offline, they then adjust to not even try to contact them, and then are told when they are back. So the machines go offline but in a controlled way and nothing unexpected ever happens. Meanwhile, somebody designing with the services "expect failure" mentality is going to architect a system that can adjust for machines disappearing and reappearing at any time, so their in-place upgrade solution can be to have the operators hit the power switch on the machines they want to upgrade, upgrade them, and then put them back in service.
I was thinking about this and I realized that my formative years were spent writing code for this kind of environment. I worked on network transports, and the entire point of a network transport is to recover from mysterious failures: dropped packets, delayed packets, duplicated packets, misordered packets, etc. The mainline path is easy; it's handling the errors that is all the work (I once wrote a sample network transport for the device driver kit that didn't handle any errors; it was about one-tenth the size of the real one). In retrospect I think this was great training as a developer, because it got me thinking in the "services mentality" way back when. And in the future, ideally all packaged software developers would borrow that approach from services, and use the expectation of failure as a way to engineer reliability into software that runs on just one machine.
Posted by AdamBa at 07:35 PM | Comments (2) | TrackBack
February 13, 2008
Dubious Interview Questions
Somebody sent me a link to a page on the corporate network that had some sample technical interview questions. I won't link to the page here, but suffice it to say that the questions are of dubious value (I contacted the owner of the page in question, and we're going to work to update it to have better questions).Consider the first 3 questions on C++; obviously whoever wrote these had just spent some time reading the part of the manual that talks about structs, because the questions are: "What is the difference between class and a struct", "Why is a struct public", and "Can you inherit and have member functions in a struct". The correct answers are not, as you might suspect, "I don't know", "To confuse people who have figured out copy constructors", and "I'll say yes, because it sounds like a bad idea so C++ probably allows it" but actually have to do with the fact that a struct is public, to allow backwards compatibility with C. The problem with this type of questions in general is that they rely too much on knowing specific facts, rather than how willing and able people are to learn new things. And going beyond that, those specific questions deal with some arcana of the C++ language that few right-thinking developers would ever take advantage of. I mean, you have a struct which is like a public class, which is a dumb idea, and then you'll put member functions in it (so much for backwards C compatibility), which is even dumber, and then to top it off you'll subclass (or substruct, I guess) the whole thing? If somebody knew the answer to this question it might imply that they had actually written code like that...which might make me less likely to want to hire them, not more (then for extra measure, there are two other questions about dynamic casts and unions...it's like a police lineup of bad C++ techniques).
Most of the rest of the questions are like that; they ask about a single fact, many of which are esoteric--except for the ones that are trivial. For VB, the first question is "What is a method" (trivial) and the next one is "What are the four states a Form can have in Visual Basic?" (esoteric). For Java you have a question on what an interface is (trivial) and then one about .java files with multiple classes definitions (esoteric). Then there is this classic about SQL: "What is the difference between locking and deadlocking?" That last question reminds me of a quote from Jack Vance: "[he] was a man beyond her understanding; whether he were vastly more subtle than she or vastly more elemental, she would never know."
The problem with questions like that, especially the esoteric ones, is that getting them right or wrong doesn't mean much. A great potential hire might not happen to know much about VB forms; a "no-hire" might by happenstance have recently tried to create a .java file with multiple public classes in it. When I talk to people about interview questions, I always encourage them to pick questions that give the candidate an opportunity to think, not just spit out facts. For example, most of the sample questions on that page could be improved by giving the candidate the answer and then asking them to talk about why they think it works that way. And requiring thinking on their feet is one reason that coding questions work well; it's not whether they write great code, it's whether they think about it first, how they decide if it is correct, how they discuss possible improvements...that's what you need a good interview question to show you.
Posted by AdamBa at 09:45 PM | Comments (1) | TrackBack
February 09, 2008
Peoples of the Caucuses
Today I did something I have never done before: I went to the caucus meeting to elect delegates for the presidential election.
In a normal year the candidates are decided by "Super Tuesday", and by the time the Washington caucuses roll around, one candidate has established an unbeatable lead and it's all over but the shouting. But this year, with Obama and Clinton neck and neck, Washington suddenly became important (I'm talking about the Democrats here; as readers of this blog may know, I'm an inveterate liberal). Both candidates visited the state yesterday, and we received many phone calls (some automated, but most not) from people urging us to attend our local caucus. My wife spent some time talking to a 74-year-old Obama supporter from California.
For state constitutional reasons, Washington has a primary in ten days, but the Democratic party chooses its delegates via caucuses and then ignores the primary results. It starts out at the precinct level, then they elect delegates to a county caucus, then that rolls up to a state caucus, and there they choose the delegates to the national convention. I was actually unaware of this until recently, but people did a good job of getting the word out that the important votes were happening today at 1 pm.
About ten precincts were caucusing at our appointed site, which was the school district building (the place was a zoo; see photo). My precinct, which I recall from letter-writing campaigns for Laura Ruderman has about 200-300 houses, had 58 people show up, which I think is an impressive number (evidently the turnout was more than double that of four years ago). We had already indicated our preliminary votes and the tally was 36 for Obama, 21 for Clinton, and 1 undecided. Each camp (included the undecideds) could pick one person to give a one-minute speech, in the hopes of swaying the other side. Then they asked if anybody wanted to change their vote (nobody did). Our precinct is allocated 5 delegates to the county caucus (which is in April), and because of the votes the Obama camp got to pick 3 delegates and the Clinton camp got to pick 2. The undecideds would have been able to pick an undecided delegate if there had been enough of them.
In the days leading up to the caucus I had been having an internal debate about who to vote for. I think that both Obama and Clinton would make fine presidents (so for once, I have sympathy for undecided voters); my overriding concern is getting a Democrat elected so that they will form a Democratic administration. Many people seemed to have the same opinion, although there were some people who were basing their decision on their perceived qualities as president (summary of the anti sound bites: Obama is inexperienced, Clinton is compromised by special interests). I think Clinton has higher positives but also higher negatives, and in the general election the positives don't matter much, it's a question of what the Republicans can do with the negatives. I also am slightly annoyed with Bill Clinton's behavior vis-a-vis Obama, which is veering into win-at-all-costs (as it did when he was president; if he had just taken his lumps and allowed himself to be impeached, Al Gore would be president right now). And, fairly or not, I do view a Clinton presidency as "8 more years of Bill and Hillary", and that is also how the Republicans would spin it.
Anyway, I was one of the 36 for Obama, so we gathered to vote on our 3 delegates. There were 6 people who wanted to do it: 3 high school seniors, and 3 adults. They all gave little speeches about why they wanted to be a delegate, and then we voted. In the end the 3 high school kids got chosen. So the delegates from precinct 2448 are Griffin, Marcus, and Kate. Marcus had essentially the same attitude as I did, but Griffin and Kate seemed genuinely jazzed by the promise of Obama. I gather many of the high school students had skipped school to go to his rally yesterday, and Kate mentioned that she had shaken his hand (and like all teenage girls these days, and my daughter, ended her speech by saying, "and so, um, yeah").
There was something really neat about being there at the start of the process that would eventually lead to choosing a candidate. And the down-homey feel of the local caucus reminded me of what I picture a New England town hall meeting being like. I hope our delegates have fun at the county caucus; I suspect that at the next level the knives will come out and the delegates chosen will be the cynical, hard-bitten types, but for today youth and optimism won out.
Posted by AdamBa at 10:30 PM | Comments (3) | TrackBack
February 06, 2008
The Kevin Hart Saga, Local Version
I figured the local papers must be all over this story, and sure enough they are. The Reno Gazette-Journal has a series of articles on the story. The most recent is the "I made it up" one, and from there you can see them all, from the initial coverage of the press conference, to doubts beginning to surface, the mystery deepending, rumors of a shadowy middleman being involved, and then the denouement.
The most poignant, or strange, article is the very first one, the initial press conference. This is covered as a straight "Cool things happening in Nevada story". It starts out "As recently as three weeks ago, Fernley offensive lineman Kevin Hart was all set to commit to Oregon. But on Friday, during an assembly in front of the entire school, Hart chose California over the Pac-10 rival Ducks." (while he was pretending that one school was recruiting him, why not raise the stakes by pretending that multiple ones were and he had pulled a late switch-eroo?). Hart put an Oregon hat and a Cal hat in front of him, then chose the Cal hat (a moment captured in the picture above from the RGJ website--what precisely is going on inside his head at that instant?). Hart, described as "the first Fernley athlete to receive a full scholarship to a Division I school directly out of high school", is quoted as saying "I'm sure it won't hit me until I hit the practice field and get welcomed to the Pac-10"...and then the team coach says, "This is a great day for Fernley High School...This is one young man who is going to represent us on the national level. But we'll always remember he came from Fernley." It's all too horrible/awesome to believe.
The most thorough coverage of the story that I've found is this article at bearterritory.net, a site that covers Cal recruiting and was evidently the first to suspect that something was amiss. The sad part is that Hart really was ranked at a 5.2 by rivals.com, which puts him right in the middle of the 5.0-5.4 band described as "Division I prospect; considered a mid-major prospect; deemed to have limited pro potential but definite Division I prospect; may be more of a role player." So even if he didn't make a D-1 school, he probably could have played in Montana or something. But now it's doubtful any college coach anywhere would take a chance on him.
Posted by AdamBa at 09:52 PM | Comments (2) | TrackBack
February 04, 2008
In the Model Shop
During one of my periodic visits to Legoland, I was talking to a Master Builder and they mentioned that there were actually several different jobs in the Model Shop; besides being a "designer", the highest rank, you could also be a builder, a repairer, or a mere gluer (for more background info, follow the link from this Brickwiki page to this sordid tale of glue shortcuts and melted bricks). But they also commented that the distinctions mattered less than you might think; "Once you're in the model shop, you're in the model shop."[New thought] As you might know from my incessant promotion, my children like to perform in shows put on by Studio East. Studio East also has training classes, and one that they offer each summer is a two-week, four-hours-per-evening class for adults interested in theater (it overlaps with a much more intensive 6-week program for teenagers). Out of curiosity for what my kids were doing, I enrolled in it last summer. The students were mostly parents on a lark like myself, although there were a couple of younger people who were taking it as serious training (and it was certainly worthwhile in that respect). We did scene work, improv, masks, audition practice, Shakespeare, camera, and stage combat.
I, and everybody else, had a great time in the class. Fast forward to late last fall, when the Studio was casting roles for the show "I Never Saw Another Butterfly". This is a very moving play about life in the Terezin concentration camp during World War II. It's based on a book of the same name, focusing on a survivor named Raja Englanderova (a real person) and a teacher she meets in the camp (fictional, but based on Friedl Dicker-Brandeis). One of the early scenes involves Raja remembering life in Prague before her family was sent to the camp. The scene features her father, mother, aunt, and older brother. Well (you can probably see where this is going), the director needed somebody to play the Papa role, and she asked me (she actually needed two somebodies, because the show is double cast). Of course I accepted.
I remember that when I proposed to my wife, I found it somewhat hard to wrap my brain around the fact that I had started in motion the process, previously observed being undertaken by others, that would eventually lead to my being in front of an audience at a wedding; it was difficult to believe that such a simple act had started such a complicated chain of events (but it did!). It's been the same with the show. Starting in early December I've been through the whole sequence: callbacks, read-through, early rehearsals, costume fittings, tech day, dress rehearsals, and finally opening night on January 26th.
We're in the middle of the run now (6 out of 10 shows that my cast will do are in the books) and it's been an absolute blast. I'm not really an actor, I'm just playing one on stage, but evidently I can do a decent job pulling off the role of a Jewish father, and it's been very interesting thinking about my preoccupation and inner monologue and other actor-y notions. But the best part has just been being in the cast. There are 4 adults and the rest is kids between the ages of 7 and 16 (including one of my children). From our call for a show (which is when you have to get there) to the end is almost 4 hours, and there's a lot of downtime in there, with nothing particular to do except keep an eye on the stage monitor to avoid missing your entrance. Technically there are separate boys and girls dressing rooms, but none of the boys/men have any revealing costume changes, there are only 5 of us so the room is less crowded than the girls dressing room, and the small size of the theater means that oftentimes actors have to walk through the boys dressing room on their way to or from the stage. The net result is that a lot of people of both genders wind up hanging out in our dressing room (oh, and boys are cooler also). It's been vastly entertaining observing the cast interact--and also being a part of it, since I am a real member of the cast. The ridiculous stuff that goes on backstage and the hilarious accidents that happen during rehearsal are memories that I'll always treasure. Yes, these are the social networking kids (currently on Facebook) that I've written about before, and there is some inevitable sniping and drama, but mostly it's just good times (I'm not Facebook friends with any of them; I think that's a line I won't try to cross). I may have a small part (my character is on stage for about 6 minutes total, and gets sent off to Auschwitz early on), but now I know what it feels like to be let into the model shop.
Posted by AdamBa at 09:43 PM | Comments (0) | TrackBack
