February 2007 Archives

less is always more.

It looks like you can do anything and the features are so attractive... Until you attempt to actually *do* something then she slaps you in the face and says she is not ready yet.

My cleaner shrimp decided a couple of days ago they are hungry and started snacking away on my two clams. They already made a 10c hole in my Crocea, and is starting to work on my Maxima too. It started with a very small pinch that they started to work on and eventually caused the clams to retract their mantles almost completely.

A while ago I acclimated a black molly to my QT saltwater tank for the ribbon eel to consume. The irony is that the ribbon eel never ate him so now I have one lost molly. See, the fish firmly believes he is a saltwater fish. Eats mysis/brine/seaweed, and is especially busy during the day eating micro algae from the glass panes and substrate.

My Sexy Shrimp decided eating Christmas worms is far nicer than leftover pieces os mysis. I found the little bugger eating on the foot of the Christmas worm, and something underneath that foot kept coming out - almost like a little claw - and tried to chase the Sexy Shrimp away. Fortunately when the Sexy Shrimp decided to jump on the Christmas worm, it retracted.

Ribbon eel ate for first time since I got him. He did not take at anything other than LM prawn. Only a small piece worked - bigger pieces were rejected. He ate about 3 pieces in total.

For the first time since I got my Ribbon Eel about 2 months ago, he ate a big piece of prawn... It took a couple of minutes of persuasion, but I knew he was hungry in the way he poked the lance fish I tried to feed him with initially.

I just hope he continues to eat...

Whilst implementing a .NET application for one of my clients, I recently ran into a problem where a long running task would just suddenly stop working after about 30 minutes. No error, no exception - nothing.

I had been troubleshooting this for 3 days now, and that is a very long time for someone with my experience (if I may say so myself). The difficulty with this problem is that there are no - and I mean absolutely NO errors. The only thing I could gather is that the long running task stops because the IIS worker process dies.

I even added detailed trace statements - none of which helped. The output stopped dead at one my of audit entries:

Workflow.Audit.AddAuditEntry(new XXXAudit.XXXAuditEntry(this,
   "Some message"));

A couple of minutes ago I decided to put trace statements in the getters I am using here:

 protected IWorkflow Workflow
    {
        get
        {
            return workflow;
        }
    }

 public IAudit Audit

        {

            get

            {

                return Audit;

            }

        }

Now if you have a sharp eye you might have spotted the bug already. It is trivial, though extremely hard to spot in a 40 000 line application.

Only when I saw a runaway amount of debug output entries in the getter for the IAudit interface did I immediately realise what was happening.

A stupid thing like a recursive call caused me 3 lost days on a project - that is unacceptable. I guess it is all my fault - I could have used different naming conventions, could have spotted the little recursive icon next to that line in my IDE - but none of that is relevant. Coding conventions certainly help with this problem - and in my own projects I do use a different naming scheme, but in this case I had to follow the client's naming scheme which is based on Microsoft's recommendations.

The root problem is that Microsoft should have implemented a check in their compiler to catch this extremely easy to make mistake in your code, and at least let it fail with an error in the trivil case where recursion is infinite. The problem is that getters' syntax makes this kind of mistake extremely easy to make.

Another root problem here is the fact that Windows choose to kill the IIS worker process silently and not do like Java does on an infinitely recursive call - abort the call with a StackOverflowException. That would have helped too. Instead there are no exceptions, no (helpful) EventLog entries and just silent death of a process...

Whilst working on my Windows XP SP2 machine, this kept on popping up.

(Update: For those who did not get it, \$BitMap is a MFT system file - for Windows to suggest I have to save it elsewhere is just downright hilarious - that would cause even more problems! They should have presented a different popup message for system files.)

I was busy implementing a system for a client using C++ on Win32 when I had to use the sprintf function. As I knew it was insecure I looked up the function's details - only to be caught in an infinite web of evasion.