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.