Entourage is taking a work break

I honestly don’t remember when I first started using Entourage. I suspect it was back before Project Athena was named Entourage, and was simply the Mac version of Outlook Express. I’d hooked up my work Exchange server account via IMAP, and later Entourage’s built-in Exchange support. Yesterday, for the first time in many moons, I can’t use Entourage to access my work e-mail.

The reason: We’re moving on up. Many Microsofties’ accounts are getting migrated to Exchange 2010 so we all can dogfood, dogfood, dogfood. And WebDAV in Exchange 2010 has gone the way of the dodo¹.

Never fear, intrepid Mac Office users: in lieu of switching to the aging, legacy, Windows-centric MAPI, the Mac Office folks are designing forward to the newfangled Exchange Web Services (EWS), the faster replacement for WebDAV. EWS works on Exchange 2007, and will have expanded capabilities in 2010.

Nonetheless, we dogfooders are stuck choosing between hot dogfood-on-dogfood action (i.e., the latest builds of Entourage EWS against the pre-release Exchange 2010) or waiting until Mac Office makes their release. Since I’m no longer on the team (i.e., not building and debugging it day in and day out), and it’s both about my home and my work data, I’m inclined to sit this one out, and wait on pins and needles until they come out with the new coolness.
--
¹A better list of changing APIs for Exchange 2010 can be found here.

Home networking and its woes

A couple weeks ago, I updated all of the Ethernet hubs in the house to support gigabit ethernet. It’s not that I have many devices that would take advantage of this, but I suspect more and more as time goes on will. Nonetheless, this most recent upgrade still didn’t quite work out perfectly: the Netgear ProSafe GS108 in the office connecting to the Netgear ProSafe GS105 up inside the Leviton Structured Media™ box won’t train to gigabit speeds, always falling back to 100 megabit. Grr. Not sure exactly how to diagnose the problem. (The same problem doesn’t occur between the 105 and an identical 108 unit in a different room.)

At the same time I updated the hubs, I decided it’d be nice to actually have more than one working telephone jack available. (I mean, it’s downright tragic to have this awesome patch system in the Leviton box and yet only have one real phone line—connected to the modem itself.) I could put little DSL filters in front of them, but that posed a problem for the only other (prospective) phone in the house — a wall-plate-mounted kitchen phone. We didn’t have a DSL filter that would fit that and have it stay on the wall. So, I did some research and found that of course Leviton makes a DSL filter board (47616-DSF) to stick into the box. When I got it, I realized that I didn’t have (nor really know how to use) a punchdown tool. Fortunately, one of my friends who is a hardware geek did, and gave me the explanation on how to use it. I rewired the phone to go through the board first, but got zero love -- no signal seemed to come out of the “to modem” (or at least it never reached the modem), even though the phone lines still seemed to work correctly. Double grr. Now it’s re-patched to the original configuration, and there’s still no phone in the kitchen.

After all this, we started noticing that our internet service seemed seriously degraded. We have Qwest “Platinum Package” using Drizzle as our ISP. Today, I looked at the modem’s web interface, and it said that our 7 Mbps connection was connected at 3360 Kpbs. That seemed rather unreasonable, so I did some research and found some ugliness — the current description of “Platinum Package” advertises “up to 7 Mbps” (and that makes sense to some extent, seeing as though they could have the fastest modem connection ever, and the ISP may still be the slow link), but they only guarantee at least 3 Mbps! I don’t remember that being part of the deal when I signed up; perhaps they changed the policy? (It’s not like they publish the historical policy changes so that you can see when the terms of the service changed out from under you.) I thought that it was possible that it was my forays into rewiring the punchdowns that caused the problem, but after connecting the modem directly into the telephone test jack where the phone comes into the house, it got even worse training. Putting it back where it was retrained it to 4400 Kbps, but then I updated the firmware on it (which required a reset and retrain), and now it’s back to 3700 Kbps. Let’s just say that our instant-watch Netflix movies on the Xbox 360 went from 4 bars, sometimes dropping to 3, to starting at 2 bars and bailing out entirely within a couple minutes. Really rather frustrating. Qwest’s web page talks about a “Quantum Package” (aka Fastest) that goes “up to 12 Mbps” (with a guarantee of what?), but their availability query suggests it’s not available for my phone/address.

I am tempted to jump the Qwest DSL ship (or at least them running the show — using Speakeasy or something) and venture into cable-internet. I just really want to have something akin to a guaranteed 1 MB/s (8192 Kbps) down and not have it preclude the ability to connect from the Internet into a machine on the home network.

With all of these sequential failures, I’m even less inclined to continue to plan an updated wireless network, complete with a guest VLAN. I had hoped that perhaps the ReadyNAS NV+ would support some RADIUS service so I could just make the denizens use 802.1x, and route guests only to the internet. Maybe someday.

Silverlight 3

Our partners over in the Silverlight Runtime (SLR, formerly Jolt) have done a bang-up job working on Silverlight 3, which is released to the public today. There are scads of new features. Go check it out!

We did some very targeted features in the CoreCLR for Silverlight 3, but it is largely the same engine as it was before. One of the important parts for Mac users is that there are some changes to be compatible with Snow Leopard in there. (Silverlight 2’s CoreCLR mostly works, but there are some edge cases that might show up issues, depending on the Silverlight application.)

Over here, we have our heads down for the most part, putting the finishing touches on the Visual Studio 2010 (aka Dev10) release. We’ve already released a Beta 1 of the new .NET Framework v4 (including our CLR bits). Finally, the desktop CLR will see some of the stuff that we’ve been showcasing in the CoreCLR! Furthermore, Visual Studio will have several improvements to support the design and debugging of Silverlight content.

It’s always nice to see one’s work finally make it to the public.

Proof positive that the GPL kills kittens

Daniel Jalkut, over on Red Sweater Blog, recently had a good rant about the GPL. Ok, maybe not proof about the kittens, but still…

Back in action

Just received a replacement hard drive, the 500GB Seagate Momentus 7200.4, and after spending 40m yesterday taking out the old 320GB 5400RPM drive that would periodically stop responding, I’ve been spending time getting my MacBook Pro back into action.

Transferring my Mac OS X partition with Disk Utility and my WinXP bootcamp partition with WinClone went very smoothly, and now I’m finally at the point where I'm going to put a code enlistment back on it. DevDiv for this release is using Team Foundation Server for our source control, and for the Mac side, we’re using the Teamprise client to access the server. It’s churning along in the background considering what files it’ll need to pull down to replace my deleted enlistment.

On the cool side, due to our data-at-rest policies for laptops, I’ve recreated an encrypted sparsebundle disk image for the purpose of storing my source. Historically, I would have just used the -encryption flag to hdiutil and relied on the security of my local machine’s keychain to keep the secret. However, since Gemalto has released Mac OS X tokend plugins for its .NET v2+ cards, I can use the certificate off of my Microsoft badge as the security, now requiring thieves to either crack the stock encryption or to also steal my badge and my PIN. (Good luck with that.)

Building services are going to be replacing the carpet and putting a fresh coat of paint on the walls this evening, so I’m putting all my books and peripherals into boxes. I only hope that my sync is done by the time my office is packed so I can go work in the new commons.

The shackles of IP taint

or
How it’s easier to drink the Kool-Aid™
if it’s the only drink you’re allowed to have.
The problem: If you, as a developer, introduce intellectual property into Microsoft’s distributable software portfolio¹, and the ownership of that intellectual property is under dispute, Microsoft may come under (additional) threat of lawsuit.

The “solution”: Make the policy such that Microsoft employees have no way of copying any external IP—make it against the rules to read Open Source code by default, even outside of their job.² To a lesser extent, except for specific competitive reviews, even using alternative products (esp., if it’s a development product) is frowned upon lest you absorb possible IP in the visible framework code.

The ramifications for your average Microsoft software group aren’t that problematic. They’re generally consuming the Windows OS (Microsoft), using the Visual Studio tools to build their project (Microsoft), and the majority of the analysis and testing tools are Microsoft. Furthermore, if you don’t understand an API’s MSDN documentation, you can just load the symbols and debug right into it and find out for yourself what is going on (or going wrong).

But it does mean that you are limited to what the “state of the art” is to what the Microsoft-available solutions are, and furthermore to not really know what you’re missing.³

As soon as you get on the fringe, the all-Microsoft strategy starts to slip. As a MacBU developer and now as a CLR developer working at least part time on the Macintosh CoreCLR, very little is in-house. Trying to track down something in a closed-source Apple product is just as bad as Apple trying to track something down in our closed-source products, so we get a taste of what it’s like to be a third party. But even when it’s open source, we still can’t download it and look at it. Even if it would be expedient to do so to figure out what our (mis)use of it was. Even when the documentation is sketchy or ambiguous.

So as it stands, we rely heavily on ADC. We can’t peer into the code, but they can and give us hints, or code samples. And obviously, they go and fix bugs we report in their software, as well as in the family of open source projects that are released with Mac OS X. Which leaves us back again working in our own sandbox.

It sometimes takes years for external ideas and outstanding tools to penetrate into Microsoft, and it seems to me, almost entirely through people who are new industry or college hires, bringing in their previous backgrounds (taint notwithstanding⁴) with, generally, open source community. The rest of us have to work hard (and run a rather annoying gauntlet) to keep from relaxing into navel-gazing.
--
¹As opposed to in-house tools that are not distributed.
²Unless it can be demonstrated that there are sufficient business reasons to justify the expense of having the legal team review the licensing, and incur the additional risk to Microsoft.
³On the other hand, we also have the problem that there are usually many different (sometimes nigh identical) solutions to the same problem that aren’t well publicized and thus proliferate.
⁴If a new hire made significant contributions to an open source product, then they’d be barred from working on any Microsoft product that would be of similar ilk, presuming that that would be the IP they might leak from external sources into the MS codebase. Unfortunately, there’s no good mechanism to determine what the overlap is, so it’s just a matter of how much risk the dev managers and legal team think they’d incur.

Baked Mac & Cheese

I’ve never really been particularly good in the kitchen. I tend to need a recipe and to have all the ingredients, and generally to only work on one thing at a time. That and I’m never quite sure where everything is, and generally have to look in three separate places.

Nonetheless, recently, I’ve been making a particular dish multiple times, and am getting better at timing things to be ready Just In Time™: The Joy of Cooking (‘97 edition)’s Baked Macaroni and Cheese.

My friend Mason, author of the Tiny Kitchen iPhone application, swears by the Cook’s Illustrated version (the older, adult version), and I will have to try it eventually. Nonetheless, his app has helped me on more than one occasion to set up a shopping list so I can remember to get everything I need for it.

Towards that end, I am adding it here, in Tiny Kitchen form, sans Joy’s copyrighted description:

---begin-tinykitchen---
Title: Baked Macaroni and Cheese (Joy of Cooking)
Time To Cook (in minutes): 45
Tags: dinner

----
2 cups elbow macaroni
3 tbsp. butter
2 tbsp. flour
2 cups milk
0.5000 - onion (minced)
1 - bay leaf
0.2500 tsp. paprika
2.2500 cups sharp Cheddar or Colby cheese (grated)
- - black pepper (freshly ground)
0.5000 cups bread crumbs (fresh)

----

Guid: 4EC3A73B-5A81-4EA2-A600-8C20A84AC72F
---end-tinykitchen---

I’ve tended to shop at Trader Joe’s for the ingredients, and use these specifics:

• Like Cook’s Illustrated suggests, I use a blend of mostly sharp cheddar (extra sharp Celtic or extra sharp Wisconsin, for more orange-y look), and some Monterey Jack.


• I use fusilli rather than elbow macaroni.


• I use (organic) whole milk.


• I also buy frozen chicken breasts, and broil two to add a little tasty protein to my fat and salt.

I’ve used Tiny Kitchen’s recipe scaling feature multiple times, having prepared it in a single batch only once. More often it’s in two or three times quantities. I’ve found it difficult to figure out what the right amount of time, or really, the right creamy consistency to reach before pulling it off the stove and adding the cheese. Also, trying to add salt and pepper to taste for varying quantities seems hard to get right.

I made it again this past weekend in a double batch, half for us, and half for our newly-parents-again friends S. Ben, Meghan, “little” Nathan, and now Eliza. From my own tastebuds, it was a good run.