IHateSpaghetti {code}

IServiceOriented has posted an implementation for ESB - Publish/Subscribe. I have couple of comments about the implementation.

1. I would split the ServiceBusRuntime into several partial classes each of them will be responsible for a group of logical commands, ie: ServiceBusRuntimeListner, ServiceBusRuntimePublishSubscribe, ServiceBusRuntimeService etc. This way you get maintainability and psychological (and FS) separation of the core system providing better readability and understanding of the code.

If the code file contains a lot of lines high percentage won't read it at all (read it in some article on human reaction to long block of text vs. same amount of text written sparsely.

2. They are using lightweight read/write locking mechanism. In my opinion the code will be a lot more readable if you implement a wrapper class such as:

   1: public class RWLock :IDisposable

   2: {

   3:     private bool _read;

   4:     private ReaderWriterLockSlim _lock;

   5:     

   6:     ///<summary>

   7:     ///private constructor

   8:     ///</sumarry>

   9:     private RWLock (ReaderWriterLockSlim rwLock, bool read)

  10:     {

  11:         _read = read;

  12:         _lock = rwLock;

  13:         

  14:         if (read)

  15:             _lock .EnterReadLock();

  16:         else

  17:             _lock .EnterWriteLock();

  18:     }

  19:     

  20:     ///<summary>

  21:     ///Read lock acquire

  22:     ///</sumarry>

  23:     public static RWLock AcquireReadLock(ReaderWriterLockSlim rwLock)

  24:     {

  25:         return RWLock (rwLock,true);

  26:     }

  27:  

  28:     ///<summary>

  29:     ///Write lock acquire

  30:     ///</sumarry>

  31:     public static RWLock AcquireReadLock(ReaderWriterLockSlim rwLock)

  32:     {

  33:         return RWLock (rwLock,false);

  34:     }

  35:     

  36:  

  37:     ///<summary>

  38:     ///Lock release

  39:     ///</sumarry>

  40:     public void DIspose()

  41:     {

  42:         if (read)

  43:             _lock .ExitReadLock();

  44:         else

  45:             _lock .ExitWriteLock();

  46:     }

  47: }

Basically, its a cool use of IDisposable interface that will enable the following code:

   1: using (var locker = RWLock.AcquireReadLock(_subscriptionsRWLock))

   2: {

   3:     //do some thing

   4: }

Instead of:

   1: _subscriptionsRWLock.EnterWriteLock();

   2: try

   3: {

   4:     //do something

   5: }

   6: finally 

   7: {             

   8:     _subscriptionsRWLock.ExitWriteLock();

   9: }

I read Udi's article in MSDN magazine and wanted to add more information regarding one of the issues addressed, in addition I promised to write ways to handle problematic messages in MSMQ. So here you go: code project (with sample included).

Google started a new (or at least new to me) site for social gatherings and virtual chats between two or more avatar representatives in Sims style 3D environment.

Well, you have a collection of rooms, you have your basic avatars (and you can buy more - here's one of the places that the money will come from).

I played with it a bit on the train on my way to work, I don't know what is the recommended bandwidth but although the room materialized rather fast (30 sec's), I couldn't connect from some reason, so the best I have is the screen shot below with no interaction with other users (bummer !).

BTW, the CPU took it very well - 40% usage (on CORE 2 DUO 1.8Ghz, 4GB ram, vista, dell laptop), considering that in "idle" the usage is about 15-20%.

Unit testing nowadays focuses on simple units that (hopefully), when tested together, will make your code (if done thoroughly) more robust, clean and basically better.

How every all of this doesn't guaranteed in multi thread environment. Locks, unsynchronized behavior, and general unexplained behavior is common when dealing with multi threaded environment. Specially since PLinq and the multiple core availability those problems will acute further.

So I though of a testing framework that will enable us to test this -PUnit.

Bellow I have a list of requirements that I could think of and would be useful in previous "debugging scenarios" I had in the past in this matter.

Requirements

1. NUnit & VS test support

2. Expressive syntax:

a. Test declaration

i. TestPlan RunInParallel(int numberOfThreads, delegate method, params object[] parameters);

ii. TestPlan Wait(TimeSpace timeToWait);

iii.

b. Test results

i. TestResult ExpectToCompleteWithIn(TimeSpan estimatedCimpletionTime);

ii. TestResult ExpectMaximumLocks(int maximumLocks);

iii. TestResult ExpectMinimumLocks(int minimumLocks);

iv. TestResult ExpectLocks(int minimumLocks, int maximumLocks);

v. TestResult ExpectMaximumLockingTime(TimeSpan timeTheLockWasKept);

vi. TestResult ExpectMinimumLockingTime(TimeSpan timeTheLockWasKept);

vii. TestResult ExpectLockingTime(TimeSpan minimumTimeTheLockWasKept, TimeSpan maximumTimeTheLockWasKept);

viii. TestResult ExpectSequence(ISequenceListner listnerForSequences);

3. Declarative syntax:

a. Test declarations via decoration

i. [RunInParallel(int priorityGroup, int numberOfThreads, [WaitBetweenPreviousGroup = TimeSpan])]

4. Out of the box sequence listeners - to verify valid sequence of events

a. Trace listener

b. Debug listener

c. Console listener

d. Event listener

e. Method listener

5. Allowing to set the running conditions for TestPlan, as number of method call for thread, overall runtime and etc.

I would like to know what you think about these requirement - would you needed more features? alter existing ? or things like that - let me know.

Update: THIS PROJECT DISCONTINUED DUE TO LOW INTEREST. YOU CAN FIND THE SRC HERE. 

I found a great post by Andre about NDepend (assembly metric analyzer for high quality software projects).

I highly recommend to read it.

There's new post @ InfoQ regarding best practices in model-driven software development.

Summary of the topics:

1)      Separate the generated and manual code from each other - in my opinion the separation should only physical and you can you partial classes to achieve physical separation with concrete linkage to the non-generated code of yours.

2)      Don't check-in generated code – in my opinion it's not always true (see my comments on that)

3)      Integrate the generator into the build process

4)      Use the resources of the target platform

5)      Generate clean code

6)      Use the complier – see my insights on that (between the lines)

7)      Talk in Meta models

8)      Develop DSLs iteratively

9)      Develop model-validation iteratively

10)   Test the generator using a reference model

11)   Select suitable technology – in my opinion, technologies that enforce you to tight-couple their assemblies with you code, are less preferable (future technologies upgrades might become extremely high risk to the project so that they will be discarded altogether).

12)   Encapsulate UML (and other complex meta-models)

13)   Use graphical syntax correctly

14)   Use textual syntax correctly

15)   Use Configuration By Exception

16)   Teamwork loves textual DSLs

17)   Use model-transformation to reduce complexity

18)   Generate towards a comprehensive platform