Friday, May 27, 2005

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.

Tuesday, May 10, 2005

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.

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

Friday, May 06, 2005

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.

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.

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

Tuesday, May 03, 2005

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.