david sidlinger

Today, I ran the jailbreak on my iPod touch. I was perfectly content to leave it locked up and wait for ISVs to get their hands on the SDK in February. The only thing that I wanted was the ability to add and edit events in the calendar application. I give Apple a lot of leeway (and a lot of my money,) but the artificial limitation they placed on the calendar app on the touch was too much. Apparently, it’s the same binary that runs on the iPhone with a configuration property change. What in the world were they thinking?

I recently started using VMware Fusion instead of Parallels Desktop to run virtual machines on my MacBook. The main reason I switched was support for multi-processor VMs, but I also had a nagging suspicion that Parallels’ kernel extensions might be behind the sleep issues my machine has been having.

I think Fusion is a great product, but I’ve run across something that caused me huge amounts of frustration. Sometimes, it would warn me that it couldn’t write preference information. Once that happened, it was all downhill. Attempting to change the application preferences would cause the whole application to die immediately. Most of the other applications I use would start acting funky.

It turns out you should never ever launch Fusion using Quicksilver.

I don’t know what exactly VMware is doing, but Fusion has earned the dubious distinction of being the only application that I know of that won’t work with the best application in the explored universe. My first guess is something to do with changing the process identity.

I like to imagine that it does feel some shame being the only item that I’ve had to add to my dock since installing Quicksilver.

The latest on the reading list is Programming WCF Services from Juval Löwy. I’m having a real hard time maintaining interest in this book for a variety of reasons, but I’ll save the review for when I’m done.

I was only in the first paragraph of the preface when I hit a statement that sums up how I have been feeling about Microsoft development lately. In Juval’s own words:

Then, in July 2002, during a C# Strategic Design Review, the remoting program manager outlined in broad strokes plans to rework remoting into something that developers should actually use.

Now, Juval is not a Microsoft employee so much as a Microsoft shill; so, nothing he says can be taken as anything official from on high. However, I think that one statement has focused my frustration enough that I can articulate what has been bugging me. It shows a complete and utter disregard for the people that have been building their products on the .NET platform by Microsoft and their evangelists. This type of behavior can be seen in almost all facets of their development tools and technology stacks (e.g. distributed systems, data access, web applications.) They come out with yet another new solution to a problem only to turn around and rework it from the ground up and tell us what a piece of crap that last implementation was.

Outside of the standard disclaimers on alpha and beta software, I have never seen or heard Microsoft say that we shouldn’t be using their current technology stack. If remoting was so bad (I do think it was and still is,) why didn’t they caution us against using it? Why do they continually come out with shiny new toys that require the people driving their success to rewrite mountains of code?

The simplest answer is that most of what they put out does suck. While there have been some real “gems” thrown out there for people to risk their business on, I don’t think that completely explains it.

The second simplest answer is that Microsoft has shareholders and loads of salespeople and middlemen to appease. They cannot survive without a constant stream of revenue pouring in. They could accomplish that by being the hands-down best platform out there. Instead, they choose to feed the MSDN beast and get developers whipped into a frenzy about something that will require more upgrades, training, etc. Incremental, but substantial, improvements with a lot of thought put into maintaining compatibility with existing code do not keeping cash flowing into the maw.

A lot of people have written about this. Some of Microsoft’s own people have had moments of sanity. I just wanted to register my disgust. If anyone from Microsoft comes upon this, know that you’ve lost another “heart and mind.” I have unwittingly done my part to push your products and agendas in the past. I won’t be doing it anymore. Will I stop using the .NET platform altogether? No. Will I avoid subjecting my employers and clients to change for change’s sake? Absolutely. Will I make every reasonable effort to get them to consider alternatives? You better believe it.

Update: As with all things, I should have looked to Looney Toons for an appropriate analogy. We developers are Elmer Fudd, and whatever Redmond is pushing is Bugs Bunny in a dress. We just keep falling for it every time.

Do you think they would have let this bug escape if they cared just a little bit about unit testing?

An Evangelist at Microsoft thinks that “the Browser is on life support” due to Apollo, WPF/e, and their kin. Wow. Is it just me or is that a pretty big leap?

Browsers were definitely not the first way to interact with the internet, but they have persisted due to the (fairly) easy to understand page abstraction. If Flash is any indication, these technologies are pretty painful for the average user, because they take away a lot of the things that are baked in to the browser experience (bookmarks, for example).

[Update] Removed the screen grab and ad hominem attack. ;)

I now have (somewhat) definitive proof that awareness of wireless security is spreading. Just six months ago, better than 75% of the many wireless networks I can see from my house were totally unsecured. Now just two out of 20 appear to be running at least WEP security. A few are using WPA. These are the same networks that were around before; so, I can’t attribute it to some ISP tech doing the right thing during setup.

This is interesting to me for two reasons. One, it appears that something I would consider to be off the radar of the “normal” home user is not. And, two, it severely puts a crimp on my…how do I say this delicately…alternate connection to the net when the cable modem won’t sync.

Over the past few years, a lot of my work has been centered around Microsoft BizTalk Server. While I have a lot of good things to say about the product, there are a few things that really get under my skin. I had very high hopes that they would be addressed in BTS 2006, but it seems that there are some things the BizTalk team just isn’t ready and/or willing to address.

If I’m way out of line on any of these, please let me know. I would love nothing more than to be shown how to address these issues.

Building BizTalk Projects

Unless I have just really missed the boat on something, integrating BizTalk projects into any kind of automated build process is really a nightmare. When Visual Studio 2005 came out, it really looked like Microsoft was “getting it.” With the .NET Framework SDK installed on a machine, you could build your projects without Visual Studio or any other software installed. Project files are now just build scripts in disguise. Project files, that is, other than the ones for BizTalk projects. For some inexplicable reason, BizTalk projects are still in the same old Visual Studio 2003 format. This exempts BizTalk projects from things that are generally considered good development practices, like continuous integration builds.

Some of you (if there are any of you at all) will argue that there are workarounds and custom build actions that enable the building of BizTalk projects. This is accomplished by subverting the normal build process and shelling out to Visual Studio. There are at least a couple of problems with this. First, it means a Visual Studio/BizTalk installation on the build server. Not only does this mean licensing costs, it also feels a lot less clean. By ending around the “normal” build tool, I would imagine that logging and transparency are comprimised.

Another side effect of this is that developers without BizTalk installed can’t build the projects. Restricting their ability to edit the projects is one thing, but keeping them from building the project prevents them from determining if a code change will break the build when checked in.
Everything in the GAC

The GAC can be a very powerful tool. It can also cramp a developer’s style like nobody’s business. I can’t tell you how may times I’ve made a change to a component consumed by BizTalk only to wonder why I wasn’t seeing a change in the behavior. Is there not any other way that this could be approached? The workarounds for GACing your assemblies are almost as cumbersome. I’ve used the registry key for assembly resolution. I’ve tried editing the BTS AppDomain creation information to use a different base path. Nothing seems to stop the interruption to my normal development flow.

Another consequence of this is that providing configuration information to your BizTalk artifacts is hampered. Editing the BizTalk service configuration seems risky and, once again, just makes BizTalk development seem different than anything else you encounter in the .NET world.

Poor Facilities for Unit Testing

Has anyone actually come up with a workable solution to BizTalk unit testing? There are a few tools provided to execute pipelines, etc., but they don’t really integrate well with the MS Test framework. Testing an orchestration without jumping through the deployment and binding hoops is next to impossible. I was extremely excited when I heard about BizUnit. That lasted until I realized that the tool was not correctly named. BizUnit performs what I would consider acceptance or integration tests, but does not allow you to test BTS artifacts in isolation. Last time I checked, a unit test meant testing a unit of code and as little as possible of anything else.