A selection of posts that originally appeared on some of my older blogs hosted at

How To Remove Phantom Unread Events From Outlook After Importing iCal File


Originally posted to microsoft.public.outlook.calendaring Usenet group, April 10th, 2007

I just spend about 4-hours between yesterday afternoon and this morning trying to import an iCal file into Outlook 2003. No errors occurred during the numerous importing attempts, but afterwards the events did not appear on the days that they should have. Yet the number of unread/upcoming events next to the calendar name increased every time I tried to import.

I tried searching for the missing items using the Advanced Find dialog, but they would never appear in the results. I even tried exporting the whole calendar as an Excel file using a very wide date range (all events from 1970 through 2038), but the events were not listed in the export either.

Finally, I tried applying the predefined “By Category” filter to the standard Calendar view (available in the Advanced toolbar group). There were all of my phantom events – they included no information whatsoever and were in fact listed as email items rather than calendar items. I was able to delete them from that view and return my item count back to normal.

Now I just had to get around the importing problem. After searching various resources for an explanation, the best that I could come up with is that Outlook doesn’t like some Timezone data that tends to get included in iCal files that originate from a Mac client. No other information was included on what in particular Outlook didn’t like or if there was a direct work around, so I did some experimentation on my own. The solution is actually easier then you might expect. First, I imported the offending iCal file into a new Google calendar. Then, I downloaded Google’s rendition of the file from the Private iCal link under the Manage Calendars panel. Finally, I imported this new iCal file into Outlook using the normal Import/Export dialog. Now the events appear as expected.

If you’re interested in trying to this all yourself, you can find the original iCal file at – Import the file as-is into Outlook, then apply the “By Category” filter to see where they went to.

* This post was originally published on April 10, 2007 at

IE getElementById Bug Strikes Again


I was burned by the document.getElementById() may return incorrect element in IE and Opera bug again today. This time though it was particularly bothersome as I spent the better part of the afternoon trying to figure out why I couldn’t access the length property of the value of a textarea element in IE when the same code worked fine in Firefox. I mean, getting the length of a value of any form element through JavaScript usually isn’t like rocket science.

<textarea id="description" name="description">Here is some text</textarea>

<script type="text/javascript">
var myElement = document.getElementById('description');
alert(myElement.value.length); //alert: 17

Every time I tried to execute that code in IE it would complain that 'value.length' is null or not an object.

After a whole crap load of debugging I finally tracked it down to the fact that IE was actually referencing the <meta name=”description”> tag in the head section of the page. Yeah, see even though the function is getElementById, IE still thought I meant the element with the name attribute equal to “description”. Or as my brother put it in a comment to the original post (before the comments were wiped in the great Data Loss of ’06), maybe IE thought I was calling the getJustAboutAnythingIFeelLike() function…

Damn you IE for making me have to change my ID attributes to suite your leisurely implementation of the DOM!

* This post was originally published on April 5, 2007 at

Assumptions And Requirements – Tips on avoiding scope creep


If you’re old enough, you might recall the old facsimile that use to adorn at least one wall of every office, back when facsimiles were in fashion, which compared the process of product design to a tire swing. You know the one. (Or perhaps you prefer the “Tire 2.0” version?)

I’ve recently been working on a project that has managed to creep wildly out of scope. About 300% out of scope, really. And I think the old tire-swing adage just about covers the reasons behind the scope creep:

  • The customer already had A
  • The customer asked for B, an update & rewrite of A
  • I understood it as C
  • I built it as D, adding in a few extra features that I thought were “cool”
  • When I demo’d the final version to the customer they discovered what they really wanted was E, which was a lot like A

Now that I’m almost finished building E, I have a few thoughts in mind for making sure this doesn’t happen with future projects.

  1. Save the analysis for later

    I have a bad habit of starting to analyze how to go about transforming something to a digital process while I’m still in the middle of discovery. I’ve always assumed that this pre-analysis would help me identify gaps or other obstacles while I was still with the client, thus leading me to ask more questions before leaving. In essence, I was trying to complete the discovery phase in a single meeting, something that is completely unrealistic as well as careless. Another problem with this approach is that it means that while I’m busy analyzing in the back of my mind, I’m only partially focusing on the client’s description of what they want. If I instead wait to start the analysis until after the initial meeting and accept that it may take several additional meetings before the discovery phase is complete, then I can focus all of my attention on getting the details of what the client is asking for. Any questions that come out later during the analysis phase can be addressed then.

  2. Discover the client’s assumptions

    It’s not enough for me to just listen to what the client is asking for. Often times there will be details that have gone unmentioned. Perhaps the client feels intimidated by what they perceive as my technological superiority. Perhaps they feel that a certain question is “stupid”. Perhaps they assume that something is already a given. Or, perhaps they just forget that they have inside knowledge about their organization that I don’t. For these reasons, it’s important to to try to uncover these assumptions during discovery. The easiest way to get at these is to ask questions about the current process, about the organization, and about the intended solution. Another method would be to ask for a list of measurable goals that will define the success of the project once it is complete. Basically, I need to keep asking questions until I’m out of paper or the client is out of time.

  3. Analyze the process, not the request

    Perhaps the foremost change I need to make when scoping out a project is to stop making the mistake of taking the project description from the customer as the be-all, end-all. The customer may be describing what they want, but is it really what they need? By taking the time to understand not just what they are asking for, but rather what they are trying to accomplish I will be better poised to deliver what they truly need.

  4. Understand my role(s)

    I may label myself and advertise my services as a web application developer, but most of the time it’s assumed that I’m acting as a consultant at the initial meeting. It’s only later, once the project is approved, that I start acting as a developer too. In my consultant role, it’s my job to make sure the client isn’t overlooking some process that is already in place that can be used as-is or with little modification. In some cases it might be my job to inform the client that they don’t really need my services because their problem is either already solved by an existing application, or doesn’t need to be or won’t benefit from being automated. In any case, my only task during discovery should be to understand what the client needs to accomplish and to guide them through the discovery process. That’s it. The “developer” can kick in later and pick apart the process during analysis. Until then, I must concentrate on solving the client’s problem.

  5. Shadow the users

    Chances are that the client hasn’t had a chance to work out all of the gaps or consider other alternatives when drafting their request. In order to help them discovery these missing pieces it is essential that I understand how the process currently works. Job shadowing is great for this. Once I identify the key people who are doing the work I can make arrangements to follow them for all or part of a day, watching their daily activities and observing the important parts of the process. It doesn’t need to be an interview, in fact I may not need to ask many questions at all. The important thing is that I observe what happens now, so I can translate that into an automated process later. I may even be able to find pieces of the process that can be eliminated or streamlined, perhaps by interfacing with other already automated processes. It may also give me insight into any restrictions that must be worked into the automated work flow. For instance, it may be discovered that a touch-screen interface is required at some access point due to environmental or physical constraints. These on-the-job observations will also help me understand not just what the project must accomplish, but how it will affect the greater organization.

Putting all of these into practice is sure to elongate the discovery phase, but I think that’s a good thing. Much of it will still be billable since much of the discovery occurs after the initial proposal. It may be difficult getting clients to see it that way (most of the time they want to know “how much and how long” at the end of the initial meeting), but I think I will be able to justify it knowing now what the alternative may result in.

Do you have trouble with scope creep? Got any other tips for keeping it under control? Please share in the comments section below!

* This post was originally published on April 4, 2007 at

Dear Ecma, how about standardizing your date functions, eh?


Dear Ecma,

I would just like to point out how completely asinine your JavaScript Date object implementation is. How did so many of it’s member functions come to operate in such a non-intuitive way in relation to each other?

Why does getDate() return the day of the month instead of the date itself, while getDay() returns the day of the week and not the day of the month?

Why does getMonth() return a value from 0-11, but getDate() returns a value from 1-31?

Do you know how utterly confusing that is???


* This post was originally published on March 22, 2007 at

CSS Tip: Avoid applying positioning at element level


Here’s a little CSS tip: Don’t apply positioning rules (including alignment, margins, floats, etc) to a base element, for there will surely come a day when you say, “But I don’t want <label> elements to float left on this page!” Instead, use a rule based on a class or id. You may find that every single instance of said element now has the same class attribute, but it will make life much easier in the long run.

The Bad

The Good:

* This post was originally published on January 8, 2007 at

Go to Top