Many years ago, I wrote a program called vCardSplit.

It does exactly what it says on the tin...  It splits vCards.

 

Yesterday someone sent me an email with a bug report in it.

Which is the first in over five years.  Not bad going, I guess.  But still, a bug's a bug and I should fix it, right?

Except this requires me to install all the development tools I used to write it.  No huge deal, but firing up a VM session, cloning it, dropping the installers on it, running the installers, restoring my backups of my source code archives - it'll take an hour or two to get all that done.

And that's before I even look at the bug!

 

Thankfully, not only was the bug report clear and unambiguous, but it was also followed up by another email letting me know that it was false.  Phew!  Close call!

 

Still, this is a problem when writing software.  My last release of vCardSplit was five years ago.  But people are still downloading and using it.  A simple 33Kb program that runs in a console window, it's still the only free tool that does what it does all these years later!

 

The lesson here is that software can have a very long life, and that if software you write is a burden then the burden will live for a long time.

Luckily, nothing I've ever written has ever been burdeonsome for me.

 

Still, I did once write a password generator -  in VB!  And I don't think I have the source code for that, much less a copy of VB to support it with!  I really must take that down later this week, as I don't believe I can support it effectively any more.  Granted, it's had no complaints for seven years - but still, better safe than sorry!

 

For a few years now I've been meaning to write some software for Lotus Notes.  But I must admit that the burden of support is one of the things that puts me off.  I need one of those mythical "quiet periods" during which I can polish up code to a point where its support burden is low enough that I'm confident it can be unleashed upon the public.

When I do, I'll put it all up on OpenNTF. There's been some discussion on their change to an Apache licence, but that makes no difference to me.

 

However, it's always a matter of time.  So I wouldn't hold your breath...

 

I've converted the list of lost knowledge into an article, so that it can have a permanent home and be updated as and when required.

You can find it here.

I've also added DAMO and DB2NSF as items with an unknown date of loss, as they're technically pending right now.

It appears that I missed the announcement that DAMO is going to be history...

(Thanks to Ed and Stuart for the information!)

 

DAMO always seemed doomed to me - and not just because of the danger of Microsoft "accidentally" breaking the product with a patch or upgrade.

 

But because one of the core features of Notes - calendaring - is incredibly difficult to emulate and interoperate with.

I've seen very few calendaring implementations that are as comprehensive and complex as the one Notes has.  And that's always caused issue when trying to interoperate with other systems.

 

The most noticeable example is repeating meetings.  Check the Notes implementation out - it's incredible!  Repeating daily, weekly, monthly (by date), monthly (by day), or yearly.

And each of those has multiple options for how often it should repeat - every two days, or every two months, etc.  Plus of course if the day falls on aweekend, you can have thecalendar entry deleted, moved to the friday, or moved to the monday, or moved to the nearest weekday.

 

Notes calendaring is capable of some pretty impressive, labyrinthine calculations that make the calendar capable of expressing repeating patterns almost as people would when they talk to each other.  Which is a fairly impressive feat...

 

Unfortunately, many other calendaring systems are...  Less complex.

 

In fact, primitive would be complimentary for some calendaring implementations.  For most other systems, repeating meetings means that they happen every n days, and that's your lot.

 

And it's always been a pain in the posterior to interoperate with a Notes calendar because of this. Even back in the days of the early Palm devices, I remember repeating entries going missing because the synchronising software couldn't figure out how to represent that particular repeating pattern on the Palm.

Or worse, if you edited a repeating meeting you suddenly found it duplicated on the next synchronsation, or found that the software had deleted that repeating instance and replaced it with a standalone one - meaning that changes to the meeting invitees skipped that one ex-instance.

 

You even get the same thing on the Blackberry - which has a better calendar than a Palm, but not by much. If someone has a problem with calendar entries on a Blackberry, bet on them being repeating ones.  You'll break the bank!

 

All this data translation for other applications just gets very tricky.  Putting the Notes calendar into most other calendaring systems is like putting a V12 engine on a unicycle.  Daring, exciting, innovative and more than just a little foolhardy.

 

I mention all of this because my first memory of DAMO was a reproducible crash with a repeating calendar entry.  Every time you opened it, you crashed Outlook.

It was early days, and DAMO improved - but I always felt that these kinds of edge issues (as Ed discussed) meant that in a mixed environment, DAMO was a poor choice.  Webmail would be better - at least it doesn't crash when you open meetings!

(Now, in a pure DAMO environment, things would be fine.  Nobody can produce edge cases, so everyone's OK.)

 

I won't miss DAMO.  There are better options available for almost all purposes, and I think that the kinds of data-translation issues I've mentioned heer mean that in the long run you're better off trying to standardise on "native" clients wherever possible.

And it's not like we're short of native clients - Notes, DWA, Traveler, etc.

 

I'm not a salesman.

Selling things isn't my strong point.  Selling myself is more of a weak point.  This makes things like CVs and review cycles difficult for me.

Reviews are a pain, because "it's all in a day's work".  I do it, I'm momentarily proud, but unless I write it down I'll forget about it as an accomplishment completely come my next review meeting.

 

But this is an area where I've always thought it's difficult to crow about these things.  Often, the only people that will understand what you did are other geeks.  You end up distilling your achievements down to one-liners that mask the effort and ingenuity involved.

 

For instance, recently I did an analysis on some webservers.  They have lots of databases on them, and we needed to know what was & wasn't being served.

One month's logs were selected - February, as it's short - to make sure we got an accurate slice of data that would include any more occasional access that might be taking place.  There are four webservers, across two clusters, and all of them need to be analysed.

As a yardstick, one server picked at random shows 7.2Gb of text logs giving over 25 million hits. (It turned out that the load was distributed pretty evenly, as it happens.)

 

And all I have to do is figure out which databases those hits were served from.

 

Easy.

I could use a tool like Analog.  It's free, it's reputedly fast - but it requires setting up, and it's overkill.  I just need database names, and don't care about individual documents.  Analog will build a huge database, spend time maintaining that database, and will probably require considerable tweaking to get it to stop thinking about pages (documents, views, agents etc) and start thinking about databases.

Nope, a traditional web analytics system doesn't look like the solution.  On Rocky's Solution Correctness graph, web analytics falls somewhere between "Little overboard" and "God Help Me".

 

So I had a think, and realised that AWK was perfect for the job. It's sometimes thought of as a simple scripting language which processes text line-by-line, but it's actually more powerful.

A short while later, I had a script which reads the log files, determines the database filename, checks in an array to see if the filename has been seen before, and then either increments the filename's counter in that array or adds the database filename to the array.  Then at the end, it prints the array out.

 

Hey presto, one neat list of which databases were served, and how many hits each one got.  No details, just the summary I wanted.  Total time to develop?  An hour or two.  Time to run on 7.2Gb/25 million lines?  28 minutes.

As you can imagine, I was chuffed with that result.  An hour and a half later I had the stats I wanted for all four servers, and could start putting them into Excel and Word to make pretty graphs.

And by the way, if you think that the AWK script sounded like a waste of time, let me tell you that I spent more time trying to get Excel to produce readable charts than I did on developing the AWK script.  You'd think handling labels on a pie chart would be simple, but oh no, Excel begged to differ!

 

So what I have here are two achievements:

• I wrote a nifty AWK script, which produced the data I wanted quickly and easily.
• I bludgeoned Excel into submission and managed to get a half-way attractive chart.

 

But of course, in my review, these things will become just:

• Analysed web server usage

Which is dull, and hides all the skill and effort that it took.

 

And that assumes that I remember that I did this at my next review.  It's all in a day's work, after all...

 

	Articles
	Blog entries
	Comments