Break

March 2005, we went on a company skiing trip. I had never skied before but a took some lessons togheter with a colleague and was reasonably confident about my skills. Well, after about 5 minutes on the mountain I broke my fibula near my ankle when I accidently launched myself over a small bump in the piste. Though I felt some pain at that point I was still able to make it down to the base of the mountain. Only when I took of my skiing boots I felt that something was not right at all. The egg appearing on my ankle joint was also a indication that things might be more serious than I would like them to be so it seemed wise to visit one of the local physicians.

Though the fracture seemed innocent enough to me on the x-rays, the Austrian physician immediately told me I had to undergo osteosynthesis upon my arrival back home in the Netherlands. This was a huge shock to me. I had only undergone surgery one time before when I had my tonsils removed and even though it happened nearly 20 years ago, I can still clearly remember the unpleasantness of it all.

However, when visiting the surgeon back in the Netherlands I was told that the fractured bones were still in a reasonable position. At that time, I still had the transportation plaster (allows for swelling) from Austria around my leg and this would be replaced by “real” plaster a week later. If the bones would maintain their current position an operation would not be necessary. So, a week later the plaster was replaced and new x-rays were made. Unfortunately the bones had indeed shifted and I was told operating would indeed be necessary to prevent my ankle joint from wearing down too much… Damn.

A week later I went to the hospital, I cannot recall ever being more scared than I was at that time. I was shown my room and a few hours later my bed was rolled towards the operating theatre. At that point I had already decided I would go for a (local) spinal anesthetic instead of general anesthetic. I was scared the anesthetic puncture would hurt but in fact it did not. Of course, I felt the sting but it did not hurt any more than any other local aneshetic would. When the feeling in my legs was gone the doctors started doing their thing and I was out on the recovery with a big smile before I really knew what happend.

Even though the nurse wouldn’t let me at first, the doctor later said I could go home that evening. Also, I had to be very carefull not to stand or otherwise put any load on my fractured leg for at at least 8 weeks. This was actually the most damaging part it seems because when I could finally start using my leg again it felt so flimsy that I was too scared to do anything with it for about another two weeks. It was only when my father (a physiotherapist) pushed me into doing regular excercises that the strength in my leg started coming back.

Now, a half year later I can walk with reasonable comfort but it’s still not the same as before the accident. People notice there’s still a slight twitch in my walking rythm and now and then I can feel some pain too but overall things are still progressing so I’m hoping the last stiffness and pains will also fade away. Continue reading “Break”

Could

Today we encountered ASP.Net’s “Could not load type” error. This error is described in http://support.microsoft.com/default.aspx?scid=kb;en-us;Q306155
but unfortunately the given solution (rebuilt your solution/project) does not work… Duh… We’re professionals here, don’t you think we’ve tried that Microsoft? Luckely, there’s still google and after a quick search we found the solution.

Here’s the situation: our company uses an acceptation server that runs a large collection of sites that we developed or are currently developing for our clients. Each site has its own folder but all these folders are placed under a single virtual folder (application). For ASP.Net this is a single web application and thus it expects all the assemblies to reside in the bin folder immediately below the virtual folder’s folder.

So, in the first situation we had placed our assembly like this:

/webroot/acceptation/client_A/bin/ourAssembly.dll

But because ASP.Net doesn’t look in this bin folder because it’s too deep in the tree. Instead, we had to move our bin folder up one level so it looks like this:

/webroot/acceptation/bin/ourAssembly.dll

When we did that everything worked fine.

Continue reading “Could”

Code

Comments are most likely the spawn of Satan and code monkeys because looking at it like this it’s not so surprising that they are almost always distracting or stating the obvious. A few years ago, at school, my teachers used to tell me: “Use comments in abundance” and alas, how blissfully ignorant I heeded their words at that time.

During actual practice however I quickly found comments a royal pain in the arse – I much more preferred to write readable code. Instead of putting in comments to explain crappy code why don’t spend time refactoring? In a post about the new XML comments for VB.Net in VS2005 Jeff Atwood mentions four essential commenting rules he believes in:

  1. The value of a comment is directly proportional to the distance between the comment and the code. Good comments stay as close as possible to the code they’re referencing. As distance increases, the odds of developers making an edit without seeing the comment that goes with the code increases. The comment becomes misleading, out of date, or worse, incorrect. Distant comments are unreliable at best.
  2. Comments with complex formatting cannot be trusted. Complex formatting is a pain to edit and a disincentive to maintenance. If it is difficult to edit a comment, it’s very likely a developer has avoided or postponed synchronizing his work with the comments. I view complex comments with extreme skepticism.
  3. Don’t include redundant information in the comments. Why have a Revision History section– isn’t that what we use source control for? Besides the fact that this is totally redundant, the odds of a developer remembering, after every single edit, to update that comment section at the top of the procedure are.. very low.
  4. The best kind of comments are the ones you don’t need. The only “comments” guaranteed to be accurate 100% of the time– and even that is debatable– is the body of the code itself. Endeavor to write self-documenting code whenever possible. An occasional comment to illuminate or clarify is fine, but if you frequently write code full of “tricky parts” and reams of comments, maybe it’s time to refactor.

I totally agree with all of them but the last one is a pet peeve of mine because I strongly believe in self documenting code. That’s also the main reason why I don’t see much value in “paper documentation” like (UML) diagrams or lengthy implementation descriptions. Of course some of these tools are sometimes invaluable during development but their value as documentation is void. The same thing holds true for everything but the code itself. Continue reading “Code”

Static

Until not so long ago, still an ignorant geek, I was a forthright proponent of strong or static typing. How often have I scoffed at JavaScript, VBScript, PHP and other dynamic languages and their apparent lack of typing. And how glad was I to switch from a classical ASP project to a C# .Net project; finally, the wonders of static typing would help me write better code once again.

Now, a great deal of object awareness later I’m seriously in doubt wether static typing is really helping me to write “better” code. The only thing that’s really different with, say some of my old JavaScript code is the fact that I have to write a lot of explicit casting to mold each instance into it’s appropriate shape. Wondering about types, performance and memory is a frequent occurence. Heck, we even seem to be discussing in bits, bytes and words and worrying about a type’s length on a regular basis when there’s one of those interresting “which sort of integer will it be” questions.

Failing to think up any clear code examples I’m calling in the words of Peter William Lount (strongly recommended read) talking about the dynamic alternative to strong typing as implemented in Smalltalk:

A reason that Smalltalk applications hold together is that the objects carry their “type information” with them as they travel through the program. This means that variables are free to hold ANY object at any time which provides the basis for “dynamic freedom”. Any “constraints” that need to be applied to restrict the “class” of objects that can be assigned to a variable are done at runtime using the full semantic power of the Smalltalk language rather than a limited “static type syntax”.

Below is his view on “static” or, maybe more appropriately, “enforced” typing:

When you apply limited – single or even multiple – “static” type specifications (either manually entering them or via type inference) to variables the possible pathways for information and objects to travel within the program is severly restricted. This reduction is a loss of degrees of freedom of movement for the program and the designer. Maybe that’s what you want, but more often than not it simply limits what you can write. This is why applying constraints to variables is less than desireable and should be applied with caution and the awareness of future limitations in the program.

Almost all typing errors the compiler catches must be resolved with a cast and we can only conclude our intentions are correct if the only thing missing is one specific word, a casting instruction that’s (even statically) implicit anyway. This means that we maybe really don’t actually need the “safety net” the compiler supposedly provides. At least not to help us create “better” code.
Continue reading “Static”

The

Some interresting facts and thoughts about Microsoft’s CLR Garbage Collector appearing on James Robertson’s blog. I think that we, who are not responsible for maintaining that (apparent) monstrum, should stop for a moment and think about how lucky we are. And how amazingly wonderful it is that the thing actually works! Who would’ve guessed that eh? No, let’s not talk about the equally amazing wonders of J2 here – check Slava’s blog (here and here for example) for that. Continue reading “The”