Unit testing reality

I has been a pleasure reading Roy Osherove's articles on unit testing. In "Write Maintainable Unit Tests That will Save You Time And Tears" he talks about some of the pitfalls of unit testing, the list is probably not complete, but I good read.

On a side-note: I feel that articles written with the intention of explaining shortcomings (scope) and pitfalls are much more educational then the ones simply explaining the usage. I felt this strongly when reading about Fitness where I had problems in figuring out its scope.

The other article, discussed unit testing database access layer code. It had the excellent suggestion of using COM+ 1.5 SWC to encapsulate the unit tests in transactions, thus ensuring independence between unit test. I am looking forward to following this suggestion.

Polymorphism and Interfaces

The following code did not behave as I expected. It returns "A::f" twice, but I expected it to return first "A::f", then "B::f".

There are two ways of getting the desired behavior, either declaring A.f() virtual or explicitly stating that B implements I. The latter is not desirable since I don't think B should need to know that A implements I, and the former I don't think is intuitive.

Any thoughts?

   public interface I
   {
       void f();
   }
   public class A : I
   {
       public void f() { Console.WriteLine("A::f") ;}
   }
   public class B : A
   {
       public void f() { Console.WriteLine("B::f"); }
   }
   public class C
   {
       static void Main()
       {
           I i1 = new A();
           I i2 = new B();

           i1.f();
           i2.f();
       }
   }

Completing the design

The simple concept of refactoring has helped me allot. I have the tendency of not being able to start implementing before I think I have the design all figured out. This is something I think I got imprinted in school through all the "bugs-found vs. development-phase" graphs, and perhaps it is in my character as well :) Now I just tell myself: "this might not be perfect, but I will just refactor it later", and it does wonders for my throughput :)

I have in fact turned quite against completing the design before coding. In particular, I think that one should not try to guess how a particular class might be used in the future, e.g., by adding numerous accessor functions no one uses but need to be maintained and unit tested.

Delegate smell cont.

How come that delegates can call private functions, as in (inspired by MSDN):

ElapsedEventHandler eh = new ElapsedEventHandler(OnTimedEvent);
...
private void OnTimedEvent(object source, ElapsedEventArgs e) { }

Smelly.

== does not equal Equals()

I discovered that for boxed System.ValueType the == operator behaves differently from the Equals() function. When using == with two boxed ValueType-s it will compare their references, thus "always" returning false. Equals(), on the other hand, has been overloaded by Microsoft for the ValuType-s, so that it does a value comparison of the boxed objects, giving the expected result.

I wonder why Microsoft did not also overload the == operator?

Deep copy of Hashtable

In order to solve my problem of returning a hashtable by reference (see previous post), I first tried to use Hashtable.Clone() to give me a copy of the hashtable. However since Clone() only does a shallow copy of the hashtable, this did not work since the hashtable contained Objects and changing them in the calling code caused side-effects in the originating class. So what was needed was a deep copy of the hashtable and this proved to be really simple:

       private Hashtable mMeasurements = new Hashtable();
       ...
       MemoryStream ms = new MemoryStream();
       BinaryFormatter bf = new BinaryFormatter();
       bf.Serialize(ms,mMeasurements);

       ms.Seek(0,SeekOrigin.Begin);
       clonedMeasurements = (Hashtable)bf.Deserialize(ms);

Are there any concerns regarding this code?

Mocking SAO

I have been unit testing a class that interacted via Remoting with a Singleton. I wished to eliminate the remoting part and use a mock object for the singleton. There was one hinge to that: One of the singleton's public methods returns a Hashtable. The Remoting automatically took care of serializing the hashtable and recreating it at the client. However, when I started using the singleton directly (in the same assembly) as the class under test, the hashtable was returned by reference causing undesired side-effects when the class under test started manipulating the hashtable!

More on the solution shortly...


P.s.
Same problem arrises for SingleCall objects and CAOs.

UdpClient.Receive()

I have been exposed to System.Net.Sockets.UdpClient recently. One of its member functions is Receive(ref IPEndPoint). I was wondering why IPEndPoint was passed to the function as a reference (pointer to a pointer actually). So I downloaded the source code for the Mono project, thinking that it would give me a clue. There the object passed in is never used, but a new IPEndPoint created and it passed back to the calling function. This actually makes sense since the returned IPEndPoint contains the IP address of the party sending the UDP package. But why then not define Receive() as Receive(out IPEndPoint)? Thus making the intention clear.

In fact setting IPEndPoint as null before passing it into Receive() works fine.

P.s. It was not necessary for me to pull out the Mono source, the Reflector gave me the code just fine :)

public byte[] Receive(ref IPEndPoint remoteEP)
{
      EndPoint point1;
      if (this.m_CleanedUp)
      {
            throw new ObjectDisposedException(base.GetType().FullName);
      }
      if (this.m_Family == AddressFamily.InterNetwork)
      {
            point1 = IPEndPoint.Any;
      }
      else
      {
            point1 = IPEndPoint.IPv6Any;
      }
      int num1 = this.Client.ReceiveFrom(this.m_Buffer, 0x10000, SocketFlags.None, ref point1);
      remoteEP = (IPEndPoint) point1;
      if (num1 < 0x10000)
      {
            byte[] buffer1 = new byte[num1];
            Buffer.BlockCopy(this.m_Buffer, 0, buffer1, 0, num1);
            return buffer1;
      }
      return this.m_Buffer;
}

Listening to UDP broadcasts

I found the following statement on MSDN:

"The UdpClient class can broadcast to any network broadcast address, but it cannot listen for broadcasts sent to the network. You must use the Socket class to listen for network broadcasts."

However this simple UdpClient:

    client = new UdpClient( 1234 );
    point = new IPEndPoint( IPAddress.Any, 0 );
    while (true)
    {
        Console.WriteLine(Encoding.ASCII.GetString( client.Receive( ref point ) ));
    }

works equally well for broadcasted (*.255) as well as unicasted (*.131) udp packages.

I am confused.

Small VS2003 tid bit

I found out an interesting fact about adding references to 3rd party dlls in VS2003 projects (have not tried this in VS2005). If, when browsing to the dll, you go through "My Documents" the dll will be placed in the the project file (*.csproj) with an absolute path. If, however, you store the dll in some 'normal' folder on the hard disk (C-drive typically), then the added reference will placed in the project file with a relative path.

The reason for this behaviour is probably that "My Documents" is treated as a mapped network drive.

This tid bit is not going to be of much interest to you unless you share your project files with other developers, then it will cause you pain if your paths to the project files are different. The lesson is not to store your code under "My Documents" :)

Introducing mock objects in unit testing

The problem is: During unit testing I wish to replace (mock) a certain class (A) that is being used by the class (B) being tested.
The question is: how is this best done?

I can think of three ways:

1. Inherit B (with class C) and override the (protected) method that loads up A. In C, A-mock would be loaded instead of A. During testing run the unit tests on C instead of B.
2. Add public or internal methods to B that allow A being set. During testing give B A-mock instead of A using these new methods.
   
3. Use reflection to load A dynamically based on the configuration (in app.config, e.g.). During testing replace A with A-mock in the configuration.
   

All these ways impose some change to the class, B, under test, but what change is most acceptable?

Unfortunately I don't have the answer to that :)

Fitnesse

I took a look at Fitnesse "a software development collaboration tool", I had had some experience with it earlier, but had forgotten how it functioned :)

It helps me to understand what Fitnesse is by breaking it up into two parts:

• It is an extension to xUnit which allows you to configure the unit tests (without changing code).
• It is an UI which facilitates the configuration of the tests.
  

In fact the UI part is presently implemented using a Wiki, but could "easily" be replaced by another technology.

One thing bothered me while reading about Fitnesse, i.e., that the Fitnesse tests are called "acceptance tests". I think it is misleading to say that the customer writes the test, what he is actually doing is configuring the test that have been written by the developer. For me "acceptance test" is where the customer actually defines how and what to test, he should not rely on the developer to write the correct tests. The customer gets the final product and plays with it.

This, however, does not diminish the usefulness of Fitness tests, they do add value to the unit tests, especially if they get the customer more involved in the project. Maybe I am going overboard with this discussion, not having even installed or tested Fitnesse :)

O/R libraries

htomasso suggested in a comment to my last blog entry that I should take a look at NHibernate for my object/relational mapping needs. I remember learning about object oriented databases, but this seems solve the problem as well, i.e., persisting objects to a database (for retrieval).

My current problem is storing data from a hierarchal DTO model to a database. This data is used to calculate summary statistics, doing trend analysis, profiling, and debugging. But the DTOs are never actually retrieved back as DTOs from the database. So, although it looked promising initially (simplified the storing part), I think that O/R libraries are not suited for this scenario.

I did some web-research to find out what was being said as to when O/R libraries apply, but could not find any definite guidelines :(

StrokeIt

I use the mouse-gestures in Firefox, it is one of the key reasons for why I favor Firefox over IE (the two others being adblocking and tabed-browsing). Recently I found out that there is an application that allows you to add mouse-gestures to all applications, it comes with the thought-provoking name "StrokeIt". I immediately found one good use for it, namely to navigate back and forth in VisualStudio. It has not caused me any problems yet (2 days of use), so I feel that I can recommend it.
Happy "stroking"!

P.s. I finally gave up on StrokeIt, it was causing some spurious mouse movements that in time became too irritating to tolerate.

Other nice tools

I found another nice tool from the same people as did the Snippet compiler: SmartSniff. It sniffs the network for activity, very useful for analyzing program behavior. While on the subject, I also frequently use FileMon to locate problems with programs I use, it is a life-saver.

Other nice tools I use are:

• ScreenHunter, for screen-capture. Often handy when reporting some failure.
• Notepad2, a slightly improved version of Notepad. There are several Notepad replacements, I also have installed EditPadLite.
• Reflector gave me a slight shock, it showed me that the .NET dlls are very easily decompiled. We will be using an obfuscator to amend that.
  
• I have been using Baretail to tail my log4net-logs, but I am still looking for another tool I once used and was better :(
• FireFox needs mention since it is probably the tool I use the most (with the Adblock and All-in-one Gestures extensions).
  

This list is not complete, and I don't think I will keep it up-to-date, but we'll see.

CruiseControl

I recently installed CruiseControl.NET, and now it is building 3 of my projects. Included in a build is checking out the newest code from Subversion, compiling it, running the unit-tests and generating the documentation (NDoc). It is on the agenda adding NCover and FxCop to this build process.

Actually, I first started installing Draco because I had read it somewhere that it was preferable for smaller projects/teams. I was rather disappointed with that. First, the schema for the config file was too strict, it did not allow me to specify the mailserver without a domain ending or the email senders/recipients without a host ending, both of which are valid for my setup. This forced me to add an alias domain to the SMTP server of IIS (an inconvenience). Second, I am currently not using a Subversion server (Apache nor Svnserve), but simply a network share (FSFS), and I have not figured out to make this work with Draco. Anyhow, CruiseControl is working fine and was not hard to set-up, so I will stick with that.

Nice tool

I found this nice tool: Snippet compiler, which is just a mini environment to program in. Next simplest thing to using Notepad and CSC.

Acronyms cont.

I have to make one confession...
Even though I find that some over-use acronyms, there are 3 acronyms related to software development that I am fond of, i.e., DRY (don't-repeat-yourself), KISS (keep-it-simple-stupid) and YAGNI (you-ain't-going-to-need-it).

Invasion of the acronyms

What's up with the acronyms: Pragmatic unit testing: summary? I fear that sometimes content is sacrificed for a good acronym.

When to apply OO in programming

I have been thinking some more on Object oriented programming. In school we read "Object-Oriented Modelling and Design" by Rumbaugh et.al.. The book and the teacher made a big issue out of mapping real-world objects to programming-objects and that inheritance promotes code reuse. I was quite enthusiastic about the book at the time, but now don't think this book did me much service.

Now I think that OO shouldn't be applied forcefully in the design phase (one-off design), and I don't think code-reuse is a big issue. I am convinced that inheritance relationships often do not become apparent until the code is refactored. I also think that one should not force a inheritance relationship onto classes except where needed, i.e., at the hinge-points (as Robert Martin calls them). Inheritance should be introduced while refactoring in order to simplify the code, manage its complexity, as I think Steve McConnell would put it.

Dual monitor

I installed a secondary monitor this week. After some failed attempts: 2 nvidia pci cards that gave me the blue screen and an agp card that disabled my on-board card, I finally bought a dual head Matrox Millennium G450 which works fine (I am only working in 2D). I am really excited about this new set-up, now, e.g., I can run my 2 consoles programs on one screen while stepping through the third one in VisualStudio. It is also nice to be able to keep the Task List on the secondary monitor.

Additionally, I installed a freeware called MultiMonitor Taskbar which extends the taskbar to the secondary monitor, a really commendable work by Roman Voska.

P.s. I am sad to say that I have uninstalled the G450 since it started giving be repeated blue-screens :( What a bummer! I have become hooked on working with two monitors.

A Design Smell, cont.

I blogged recently about a bad smell from event. I found further evidence for the stink in a MSDN article I recently read, it says:

"If you want to use a multicast delegate, then it makes little sense for the delegate to have a return value." and " If several delegates are combined, what value is returned? The answer is the return value of the last delegate to be called—and hence the last delegate to be combined. All other return values will be discarded."

I see this as further evidence that multicast delegates were an afterthought, and not a good one.

P.s. This article states what has become obvious to me, i.e., that events are hyped-up multicast delegates.

Hidden feature of VisualStudio

I came across a blog entry regarding a hidden feature of VisualStudio (I cannot find the entry again). By adding a registry entry it is possible to let VisualStudio display vertical lines in the code viewer. This is a useful reminder to limit the number of characters per line (so that the print-out become more legible). You can try it out following the instructions below:

• find the registry entry: [HKEY_CURRENT_USER]\Software\Microsoft\VisualStudio\7.1\Text Editor
• add a string with the name "Guides" and the value "RGB(128,0,0) 90"
• restart VisualStudio

This instruction works for version 2003, but by editing a similar registry entry it should work for versions 2002 and 2005 as well. The above gives a red line at column 90.

Documenting Design

I came across the following gem by Martin Fowler:

"One of the most important things to document is the design alternatives you didn't take and why you didn't do them. That's often the most forgotten but most useful piece of external documentation you can provide." (UML Distilled, 3rd ed., p. 32)

Console text color in .NET

I found an article explaining how to change the text-color in the Console. Useful, e.g., when many threads write to the same window.

A Design Smell

I think there is a serious shitsmell (ISL. skí­talykt) to how delegates and events are used to support the publish/subscribe mechanism. I think delegates are fine, but my guess is that someone had the "brilliant" idea of using them to implement the publish/subscribe mechanism as well, and this was done by making all delegates multicast. So now the delegate is actually a container of delegates and you can start adding delegates to delegates, certainly not in accordance with the normal use of other types. Sometimes you will be using delegate-the-container and sometimes you will be using delegate-the-function-pointer, this can be confusing.

Another guess: In order to fix the problems that arose when using multicast delegates to do publish/subscribe, events were introduced (see a previous post). This is obviously just a band-aid, as can be clearly seen by the event declaration syntax: Instead of the normal declaration syntax: "(access) (type) (variable)", you have "(access) (event) (type) (variable)"!!

I think that multicast delegates and events both break the the norm, and I cannot figure why I have not seen more outbursts over this terrible language design stink; it has troubled me for some time now :(

Events and delegates in C#, cont.

This is a continuation of a previous post.

Clarification:

• The "delegate" keyword is a reference type ("class" and "interface" are also reference types).
• The "event" keyword is a modifier (such as "public", "private", etc.), used exclusively with a delegate.
• All delegates are multicast.
• It is possible to use both delegates and events to implement the publish/subscribe mechanism in the Observer pattern, there are differences however.
  

The differences in using delegates and events in implementing publish/subscribe are the following:

• Events cannot be fired outside the class they are defined in (delegates can), i.e. MyEvent("message") is only possible within the class MyEvent is defined.
• Delegates can only be attached to events through += and detached through -=, e.g. MyEvent += new MyDelegate(Update).
• Delegates can, additionally, be attached to delegates through =, but this discards those delegates that have already been added.
  

Conclusion: applying the "event" modifier to a delegate restricts its use and makes programming with them more safe. This is enforced at compile-time.


P.s.
The Observer pattern, as defined by the Gang-Of-Four (GOF), is actually different from the publish/subscribe mechanism using delegates. The GOF pattern uses ConcreteSubject and ConcreteObserver that implement the Subject and Observer interfaces, respectively.

P.p.s.
Why have I not seen this simple explanation of the event keyword elsewhere? Hopefully this post will save someone else the trouble of making some sense out of it.

Comparing programming languages

I think that Stroustrup's comment on comparing programming languages gives the rest of us a welcomed rest from trying to do so :)

"Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness." (p.5 in The Design and Evolution of C++)

"class" vs. "type"

An interesting quote from Stroustrup's The Design and Evolution of C++:

"When class means user-defined type in C++, why didn't I call it type? I chose class primarily because I dislike inventing new terminology and found Simula's quite adequate in most cases." (p. 31)

I would have liked "type" better :)

Events and delegates in C#

It has been a source of great frustration that I could not figure out why the event keyword was necessary. To me it looked like you could just drop it, and in fact this is true. The "only" (I am told there are also some finer differences) difference between a delegate and an event is that "events are like delegates that can only have the += and -= operators applied to them." (from an article by Eric Gunnarson). So simple, yet I have not seen this stated anywhere ... and I have looked in many places!
Grrrr

Reference/Value type/parameter, cont.

I have blogged previously about how objects are passed in C#. I sometimes forget that this is done differently in Java, in Java in a Nutshell it says: "Java manipulates objects 'by reference,' but it passes object references to methods 'by value.'"

Quotes from "The Design and Evolution of C++"

A quote from "The Design and Evolution of C++" which I thought was enlightening:

• "I firmly believe that language design isn't an exercise in pure thought, but a very practical exercise in balancing needs, ideals, techniques, and constraints. A good language is not merely designed, it is grown. The exercise has more to do with engineering, sociology, and philosophy than with mathematics." (p. 104)

A different quote, which I also found interesting, even though I have not completely formed my own opinion on it, is:

• "the most fundamental reason for relying on statically checked interfaces was that I was - as I still am - firmly convinced that a program composed out of statically type-checked parts is more likely to faithfully express a well-thought-out design than a program relying on weakly-typed interfaces or dynamically-checked interfaces."

Object Oriented defined, cont.

In a previous post I tried to define "object oriented", I am currently reading the opening chapters of Bjarne Stroustrup's "The Design and Evolution of C++", there he quotes himself saying:

• "Object-oriented programming is programming using inheritance. Data abstraction is programming using user-defined types. With few exceptions, object-oriented programming can and ought to be a superset of data abstraction."

I have to admit that I patted myself on the back reading that quote :)

P.s. Ravi Sethi says in his Programming Languages: "The popular term object-oriented programming refers to a programming style that relies on the concepts of inheritance and data encapsulation." (p.206, 1989). I seem to have been right on the money (or perhaps I just retrieved this info, subconsciously, from my memory?)

Interview with Steve McConnell

In this interview with Steve McConnell he shares some sobering thoughts on software development. I found item 3 of particular interest, there he talks about recurring problems in software development (for the last decades):

• Code and fix practice
• How much design up-front should be done
• Trying to anticipate future functionality
• Silver bullets to increase productivity (tooling e.g.)
• Uninformed use of software development practices
  

Code Complete 2: Design in construction

I downloaded chapter 5 in the new version of the famous Code Complete. It had many good point, amongst which I found the following most interesting:

• "Once you understand that all other technical goals in software are secondary to managing complexity, many design considerations become straightforward."
• Abstractions and encapsulations are just sub-themes to managing complexity.
• We need to manage complexity because our brain capacity is limited: "Hiding complexity so that your brain doesn't have to deal with it unless you're specifically concerned with it."
• Two reasons why we hide details: to hide complexity and to hide sources of change.
• "A study of great designers found that one attribute they had in common was their ability to anticipate change."
• "One of the most effective guidelines is not to get stuck on a single approach [in design]."
• Reviews: "If the goal is quality assurance, I tend to recommend the most structured review practice, formal inspections ... But if the goal is to foster creativity and to increase the number of design alternative generated, not just to find errors, less structured approaches work better."
• "Design is a wicked problem ... a wicked problem [is] one that could be clearly defined only by solving it, or solving part of it".

I have to mention that I found the reading of the chapter rather boring though, it is too wordy, as is often the case with North American technical literature.

UML diagrams

I find that I usually only use 3 types of UML diagrams: the class diagram, the sequence diagram, and the activity diagram. Perhaps this is so because it is often almost as easy to describe other parts of the design in words as it is with diagrams, as, e.g., for components and deployment. Or perhaps it is just that sometimes the UML standard intimidates me: I feel that I am serving it rather then it is serving me :|

P.s.
A fine summary of UML 2.0 diagrams is maintained by Scott Ambler.

Object Oriented defined

I was once asked in a job interview to explain what object oriented meant, I was a bit taken by surprise and I don't think that I gave a good answer (at least I did not get hired ;). I have been thinking about it since. I like to distill things rather than listing everything that comes to mind, like I feel that Americans tend to do, and my distilled version of what OO is is:

• Object oriented programming/design is class inheritance coupled with class data encapsulation.
  

Here I deliberately omit the following concepts: "polymorphism" (included in inheritance), public/private/protected visibility constraints (implementation of data encapsulation), abstract classes (sub theme of inheritance), interface (actually interfaces are rather a super theme to OO), classes (assumed known that classes are composed of data and function definitions), objects (instances of classes).

In distilling I think it is important not to over-generalize or become too metaphysical, but focus on what are the primary concepts and which are derived or auxiliary.

Sobering words on design patterns

Sobering words by Erik Gamma regarding design patterns: wisdom. I have experienced this urge to use design patterns where ever possible, not knowing them well enough being the only thing stopping me ;)

These two guys agree with Erik: Darrell and David.

Pervasive enterprise focus in design

One thing that has bothered my lately is the enterprise focus in everything I read. This would be tolerable should it be explicitly stated, but often this is not the case, recommendation given in articles and books that I read often silently presume that the problem is in the enterprise realm. One example of this is found on Ingo Rammer's site:

"No matter which category your application belongs to, I heavily recommend NOT to use events, callbacks or client-side sponsors for networked applications. Yes, it's possible to use them. Yes, they might work after applying one or another workaround. The real trouble is that they are not exactly stable and don't really perform that nicely."

I have seen people follow this advice, and I was inclined to do so myself, although I did not fully understand why. It was not until I read his book, Advanced .NET Remoting, that it became obvious that this advice was for client-server scenarios with many (100+) clients. The problem with callbacks actually first arises when the number of client is so high that using synchronous callbacks to dispatching the event to all the clients takes too much time, or when using asynchronous callbacks, non-responsive clients start to burden the dispatching (both because of the connection timeout and the limited thread-pool). Having just a few clients, a couple of which are on separate machines, this does not apply to my scenario.

Some of us are just doing "simple" client-server applications that are not intended to scale to infinite number of clients :) We should not sacrifies (or downplay) a valid system attribute (e.g. responsiveness) or a simple design for a fictitious scalability requirement.

P.s.
Another example is this dogma that web services is the only reasonable remoting mechanism, which I find myself reading about everywhere.

Development environment

[Update 13.10.05] I've started to use CruiseControl.NET to schedule my builds, an impressive tool.
[Update 29.09.05] I have become addicted to ReSharper and have started using NMock.

I have been polling friends and Google, finding out what would be the most productive environment for .NET development. The advice I have got, and what I have started to use is:

• Use TreeSurgeon to set up the directory structure (should be read in conjunction with Mike Roberts' blog)
• Use NDoc to document the code
• Use NAnt to run and maintain the builds and tests (is installed by TreeSurgeon)
• Use NUnit to write the unit tests (is installed by TreeSurgeon)
• Use CruiseControl.NET to do continuous integration (I have not installed this one yet)
• Use TestDriven.NET to run the unit tests within VisualStudio (handy but not crucial to have)

It did not take much time installing and starting to use these tools, but then I have used Ant and JUnit before so it did not require a new mind set.

P.s.
I found a good tip on how to run NAnt from within VisualStudio, the only change I did was to set "$(SolutionDir)\.." as the Initial directory, which is the default location where TreeSurgeon places the build file.

P.p.s.
I expect that this list will change as I start the coding for real.

Not lock() on this

I started reading more of what Jon had written, and, among a load of very interesting stuff, I found this small gem:

"Many books and articles recommend locking on this for instance methods and typeof(MyTypeName) (the Type object for whatever type you're writing code in) for static methods. I believe this is a bad idea, because it means you have less control over your locks. Other code may well end up locking on the same object as you do within your code, which makes it far harder to ensure that you only obtain locks in an appropriate order."

I had never thought about this earlier, perhaps because I have not done much serious thread work before ;)

Reference/Value type/parameter

I had to look up how parameters are passed to functions (in C#). Found an excellent article explaining the difference between value and reference types, on the one hand, and pass-by-value and pass-by-reference, on the other: Jon. For me, it was easiest to remember the different scenarios by thinking of pointers and pointers to pointers, e.g., a reference type is like pointer and a reference type passed-by-reference is like a pointer to a pointer. Now I just have to remember which types are value types and which are reference types :) An additional good point made by Jon is that a string, although being a reference type, is immutable, so it can be passed around without fear of it changing unexpectedly.

Word templates

I was rather disappointed learning that if you attach a Word template (.dot) to your documents and later change that template, only the styles of the template (Heading1, etc.) are updated in the documents, not the headers/footers, fields, watermarks, margins, etc. Lame. LaTex rules with respect to customizations like this. And I guess XML/XSLT would be good too.

Serial ATA

"First-generation Serial ATA interfaces have a bandwidth of 150 megabytes per second (MB/s) ... Serial ATA II (available as of 2004, with the release of Nvidia nForce4 chipset) doubles the maximum throughput to 300 MB/s, and 600 MB/s is planned for around 2007."
-Wikipedia

It is interesting how serial communication is becoming the norm (USB, Firewire,...), what happened to parallel communication?

ISO 9001:2000

Been involved in establishing an ISO 9001:2000 quality management system. What I have distilled from that process is the following:

The 4 fundamental pillars are

• Responsibility, i.e., it should be clear who is responsible for what.
• Traceability, ensured by logging all activities.
• Repeatability, ensured by documenting the work processes.
• continuous process improvement, done by evaluating the processes regularly.
  

An important practice is that all reactions should be proportioned, e.g., one should not go overboard to fix an insignificant issue.

A common misconception about ISO 900x is that it has to do with the quality of the final product. This is the ultimate goal, however the ISO standard is primarily focused on the processes used to produce the product. It is quite easy to have a ISO 9001 certified company that produces rubbish, so long that all processes are documented and logged, and the delegation of responsibility is clear :)

P.s.
It was a surprise to find out how short the ISO 9001:2000 standard actually was, only 19 pages in the format I have it!

XHTML/CSS validation

Thought I should check how well I did some html/css/javascript work. Used W3C validation service to check my (X)HTML and W3C CSS validation service to validate the CSS part. I got a pass :) Did though get a comment on my use of fonts, its was recommended that I provide a generic font family as a fall-back. This sent me on a search for more info on fonts, found a good reference which explained the five different generic font families, I decided on sherif.

RSS feed directories

There seems to be a number of directory services for RSS feeds:

• Syndic8
  
• 2RSS
• Google directory
  

P.s. here is a short annotated list of RSS feed readers; at the same place are articles regarding the history of RSS.

P.p.s I really like this new web-model, i.e., you get the (relevant) information 'pushed' to you instead of having to 'pull' it from the web.

CSS adventure

I went on a CSS adventure, trying to figure out how to personalize by blog. Learned about div, span, classes, and ids.
Notice the in-page display of the comments and some change in style. Now that I feel confident in how CSS works I will be making further changes to the blog-stylesheet in the future.

The appeal of new technology

Trying out new technology is a strong driving force for most developers, I think. It is so at least for me. Let the developer make technology decisions and (s)he will very likely give into this force.

Currently I have to choose between using a specification the runs over (D)COM (stateful) and one that runs over WebServices (stateless). My common sense tells me to use the (D)COM specification since it is X17 faster (I am doing real-time monitoring and control), but (having not used WS) am much wooed towards trying out WebServices.

A side note: why is it that Microsoft is promiting WebServices with such force? I have seen guidelines from them to use WebServices between layers (not tiers) within an application. I will add the link when I find it.

My first blog comment ... ApplicationDomains

Many firsts for me this year, am I becoming more bold? The most recent first is that I commented on a blog: Raymond. My comment was on ApplicationDomains, what is the practical use for them? Is it perhaps only where you are excuting an assembly you do not trust?

Review on Amazon

I posted my first book review on Amazon today :) See Professional C#.

Feeds

My vocabulary recently increased by 6 words: RSS, Atom, OPML, Blogroll, Syndicate, and Aggregator.

I am really exited about this new technology. Now I am busy adding feeds to my SharpReader and inspecting other's OPML/Blogrolls. What a great time-saver this will be!

I have to find out how to present my OPML blogroll in this blog.

Things to blog...

These are the things I have in store and will blog about when time allows:

- loose-coupled inter-process communication
- hosting alternatives
- LCE issues


Had I started this blog earlier I would have written about LaTex and Matlab, but I am not using them any more :)

First post

I intend to use this blog to discuss the ideas I get and problems I encounter during my .NET development.