Cook Computing

An interesting piece by Martin Fowler:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

Another downside to always taking the quick&dirty approach is the way it causes developer morale to spiral downwards. The technical debt builds up so much that there is no chance of ever paying it off so why bother even trying. There is no easy way out of that scenario.

Seen on the Flangy News:

I certainly don't have the intestinal fortitude to set up a Linux box to mess with Mono.

Its not too bad really. It just gets intestinally challenging when you try to build the Mono debugger and you don't know enough about Linux development to ensure the right version of all the different libraries have been installed before you start building. Since trying this a few weeks ago I've still not got round to trying again and I'll probably now wait until a built version of the debugger is included with the Mono RPMs.

I hope the Mono team realize the importance of making available a built and working GUI debugger as soon as possible. Typically Windows developers will be experimenting with Mono on Linux in their spare time and will not want to plod along with a command line debugger. And they probably won't want to spend a lot of time working out how to build the debugger. There are simply too many other interesting .NET things competing for attention. Mono has the potential to be a great entry point to Linux development but only as long as the learning curve is not too steep.

[If anyone cares to explain what I need to do to get the graphical debugger built and working on a Red Hat 9 system, I'll post the details here.]

For anyone looking for information or support on Shuttle systems, this forum is an excellent resource.

Steve Dekorte has fun with a cardboard cube ITX case.

I listened to the Brent Rector edition of .NET Rocks on the drive to London on Wednesday morning and one trivial point stuck in my mind. It turns out that .NET types can have multiple fields with the same name, as long as the type of each field is different. For example the following class builds ok:

.assembly extern mscorlib {}
.assembly demo {}
.module demo.dll

.class public DemoClass
{
    .method public hidebysig specialname rtspecialname
        instance void  .ctor() cil managed
    {
        .maxstack  1
        IL_0000:  ldarg.0
        IL_0001:  call  instance void [mscorlib]System.Object::.ctor()
        IL_0006:  ret
    }

    .field public bool myvar
    .field public int32 myvar
    .field public string myvar
}

C# is obviously going to have problems with this but you can actually use the class from C# as long as you assume the type of myvar is the type specified in the first definition of the field in the class, bool in this case. For example, the following program compiles:

class _
{
    static void Main()
    {
        DemoClass dc = new DemoClass();
        dc.myvar = true;
    }
}

I don't know whether this is a quirk of the compiler or prescribed behaviour. Brent explained that this feature of IL is the basis of one of the obfuscation techniques used in his Demeanor product, to make it harder for decompilers to produce C# code from a .NET assembly.

Another interesting point about Demeanor was that it strips out unnecessary symbols and metadata, resulting in a substantial reduction in the size of the assembly being obfuscated.

The .NET exception type RemotingException can be thrown for various reasons, including two situations in which it is thrown with the following message:

An unhandled exception of type 'System.Runtime.Remoting.RemotingException' occurred in mscorlib.dll

Additional information: This remoting proxy has no channel sink which means either the server has no registered server channels that are listening, or this application has no suitable client channel to talk to the server.

One case is where the client passes an object reference in a call to the server and the server makes a call back to the object on the client. The exception is thrown because there is no remoting channel back to the client through which the server can make the call. Solution: register a channel on the client via a call to ChannelServices.RegisterChannel.

The second case is more obscure. This occurs where the client makes a call to the server, the server returns an object reference, and the client then makes a call on the referenced object on the server. If the referenced object is in a secondary AppDomain on the server the above exception may be thrown. If the the problem occurs it is because channel registration only applies to the AppDomain in which RegisterChannel is called and no channel has been registered in the secondary AppDomain. The object reference returned to the client points to the object in the secondary AppDomain, not to its proxy in the primary AppDomain, and so there is no channel between the client and the secondary AppDomain across which the call can pass. Solution: register a channel in the secondary AppDomain in which the referenced object exists.

Robert Hurlbut reports some problems installing RedHat 9 on both Virtual PC and VMware. I've been successful in both cases but this was using ISO images.

I noticed this at the weekend, Luna Scheme, an implementation of Scheme for .NET (via the LShift site). It is still at a very early stage but may be worth tracking. A version of Scheme with bindings to the .NET Framework would be interesting. HotDog Scheme seems to have stalled.

In case you missed the comment in the previous post, Chris Sells wrote:

ChrisT and I are hoping to present the results of our work at next month's Rotor conference in Seattle. Either way, we'll release the paper we wrote on the topic ASAP.

Should be very interesting from a theoretical point of view.

In the .NET work I'm doing at the moment we are having to manage manually the lifetime of objects which acquire decidedly finite resources, for example telephone ports, and text-to-speech sessions which are limited in number by licensing requirements. The using statement is useful in some cases but compared to earlier development using COM, with extensive usage of CComPtr, there is more coding involved in resource management and less certainty that resources will be released in all code paths. It will be interesting to see whether we need to modify any of our resource management practices once we enter the system verification testing phase.