Entries from May 2006 ↓

iRows: A Nail in the Coffin of MS Office

iRows is Excel for the web. Although a little sluggish, the tool is powerful and well-designed (demo). I’ve been using it for the past couple weeks and it’s turned out to be a useful tool.

Only a few of these online office applications will survive the coming age of “moving the desktop to the web,” but no matter which ones make it I don’t see how we, the consumers, can lose.

80% of the people I know would be perfectly happy using Writely, iRows and Gmail and saving the $200-300 they normally spend on MS Office. Once someone implements a “disconnected mode” that allows users to edit files without internet access, and to download and backup our files, I’m going to start advocating pretty hard for this golden combination of simplicity and convenience.

People are fed up with Vista (Microsoft’s new Operating System). They’re fed up with missed delivery dates, high price tags, and seven versions of the same software. I’m a Microsoft developer, so I’m the last one to dig my canines into the hand that feeds me, but consumer desktop office applications are on their way out.

It will take two years before the technology is mature enough for consumers to take a risk, but once 95% of us have high speed internet and the cost of Microsoft Office becomes 3x the cost of the laptop, people are going to find alternatives. And they’re going to turn to the techies (that’s us) for guidance.

I’ve been holding off on recommending online office applications to my family and non-technical friends, but the clock is ticking.

Steve Jobs at Cupertino City Hall

I’ve seen a few posts commenting on Steve Jobs’ appearance at a Cupertino City Council meeting a few weeks ago. Jay Zipursky’s caught my eye as a keen analysis of Jobs’ motive for “dropping in” on a Cupertino City Council meeting.

Don’t get me wrong, I’m sure this billionaire businessman and brilliant manipulator has nothing better to do than hang around city hall in his copious spare time, but assuming he did have an ulterior motive, I’d bet my last Clif bar that he’s tangled with construction problems before and knows that of all the organizations you have to deal with, the city is the one that can stop even a multi-billion dollar businesses’ plans for development.

I worked for an electrical contractor for a few years after college and of all the obstacles we ran into during construction, the city was the most feared. One project manager I worked with was revered by our executives because he had an “in” at the city and was able to scoot the permit process along for the cost of a nice dinner and a bottle of wine. When you’re planning to build something where the city starts to give you flak – be afraid.

By appearing in person he showed how important this project is to Apple. He also got their buy-in on camera (a clip that’s now all over the internet), which is a powerful currency he and his general contractor will spend time and time again at permit counters and meetings with city planners.

What can we learn from this? Before going head-to-head with a much larger opponent see if you can flatter him into submission, instead.

4 Entertaining Developer Links

How to know if you’ve inherited a disaster.

How to respond to a stupid interview question.

Signs you’re a crappy programmer and don’t know it. I don’t agree with half of these, but they are interesting discussion points.

Murphy’s Laws of .NET

Two Crazy .NET Bugs

This post is a complete geek-tangent, so if you’re a non-developer excuse me for the next three and a half minutes.

A Nasty .NET Constants “Bug”
Two days ago we ran into one of the nastiest bugs I’ve seen in many moons. With large systems I’ve found that bugs in code are the relatively easy to fix, while bugs with deployment, configuration files, connectivity and the Global Assembly Cache (GAC – a folder where .NET apps can store shared assemblies) are just plain nasty. They’re hard to reproduce, hard to troubleshoot (there’s no “step-through debugging” when you’re trying to connect to a partner’s web service), and generally eat up a ton of time.

Here’s the problem we recently encountered:

We have an assembly that’s used by 12 applications, let’s call it “constants,” that holds authentication credentials (username/password) that to login to a web service. We deployed the 12 apps and the constants assembly to a QA server and everything ran smoothly. Several months later we needed to a) point our apps to a different version of the web service and b) update the authentication credentials. After making a change to our global config file to re-point our apps, we deployed a new version of constants with the updated credentials. Upon firing everything up we received “401: Unauthorized” errors.

After a day and a half of troubleshooting Jeremy found this article that talks about how .NET constants are compiled into external assemblies. So although the constants assembly is referenced at compile time, it does not exist after that. This makes sense if you think about it; constants shouldn’t change, and hard-coding the constant values into the calling assemblies is certainly a performance gain. But when you’re in the midst of a deployment, this is not the first behavior that comes to mind.

Our workaround? As the article discusses, we used “static readonly” in place of “const.” We’ll take a very slight performance hit, but gain the functionality we’re looking for.

Another Nasty One – .NET Web Services and the Word “Specified”
While I’m on the subject of weird .NET bugs, did you know if you have a boolean web service parameter with the word “Specified” at the end of it and you add a web reference to it, that Microsoft will add a second version of the same parameter with a “1” tagged on? An example:

Create a web service method with the following signature:

public string DoStuff(string firstName, bool firstNameSpecified)

When you add a web reference to it, your proxy class signature will be:

public string DoStuff(string firstName, [System.Xml.Serialization.XmlElementAttribute(“firstNameSpecified”)] bool firstNameSpecified1)

I’ve been unable to find an explanation for this behavior, but I’m sure it’s a side effect of some deep, dark secret well-hidden in the .NET framework.

Our workaround? Use the word “Provided” instead of “Specified.”

Sometimes a high-tech problem requires a low-tech hack.