Came across a gnarly difference in behavior between .NET runtime and Mono runtime. Take a look at this snippet.

[SetUp]
private void Setup()
{
  this.layout = new FeedLayout();
  this.layout.ActivateOptions();
  this.writer = new StringWriter();
}

Test-driven development using JUnit left me with the arguably proper habit of defining setup/teardown methods private. This practice works in nunit under .NET runtime - but not under mono. You must change the modifier to public - as in...

[SetUp]
public void Setup()
{
  this.layout = new FeedLayout();
  this.layout.ActivateOptions();
  this.writer = new StringWriter();
}

One of the most ubiquitous patterns in life is the template. It enables us to generalize behavior - thus ignoring or postponing complexity.

This ability to generalize behavior - deferring derivative details - turns out to be extremely useful in agile software development. It encourages mock-object practices. It encourages simplest possible solutions. It encourages test-driven development. And most importantly it embraces change.

What is the template-method pattern? A good example is found in JUnit. TestCase.run() defines a generic process: 1) setup before running test; 2) run test; 3) tear down after running test. The complexity is provided by derivative TestCase types - but the process is same for every run.

public class TestCase {
  // details elided
  public void run() {
    setup();
    runTest();
    tearDown();
  }
  protected void runTest() {
  }
  protected void setUp() {
  }
  protected void tearDown() {
  }
}

Continuing the topic of smartening up Visual SourceSafe - how might we compensate for its inability to lock a branch?

One way would be to notify those concerned when a revision a.k.a. check-in occurs. Certainly one approach would be to create a CruiseControl.NET project that merely notifies when check-ins occur.

For a low-tech solution I use this approach. No attempt was made on usability - so improvements should come easy.

When is it okay to use fields? When are properties yagni? This was the topic of an email thread I was recently involved in. A friend of mine had determined to answer - once and for all - the overhead of using properties. The results of his testing indicated that property-usage has negligible impact on execution time. That in all but the most dire situations, property-usage is not a performance variable.

I actually looked into this about two years ago. I wrote a console app that benchmarked field/property access and mutation. The results were similar. But what I found useful was to compare the MSIL operations. The attached source is similar to that original code. It was compiled, tested, and disassembled under mono on Linux. You can run the binary as console app or nunit test fixture.

In software development process, one of the things that developer is afraid of is breaking the build. Usually I do is to create another source code tree, then get the lastest code, then manually copy over changes from my working branch; finially start a release build from this test branch to verify everything is compilable. This process is very lengthy and time consuming if you have tons of code.

After I moved to a new development environment, we have this "Build Farm" environment, I think it is a very good way for developer to verify their code changes before check in the code.

Everyone needs the ability to monitor performance and track statistics inside applications. As developpers our code is a black box when running. We can't really tell how many times a loop is runs or how long an operation has taken, other then using log files. Another sexy way is to use the PerformanceCounter class. It lets your report statistics that can be viewed using the "PerfMon.exe". The bueaty is you can create custom counters to be used any way you please. Lets go over the steps to register and use some custom performance counters.

The CounterCreationDataCollection is used to store a list of counters. The first step would be to populate the collection with all your counter types. The PerformanceCounterType enumeration lets you control the type of coutner. I recommend reading the documenation to review different types you can use. Below is a example creating a collection of 2 custom performance counters.

If a user wants the ability to customize buttons on a form, or a trader needs to develop custom formulas to execute his trading strategies then use CodeDom. These types of requirements can be easily accomplished using the CodeDom namespace. The System.CodeDom namespace is very powerful because it lets you compile source code at run time. The output is an assembly that can exist in memory or saved on your disk. We can use this feature of .NET to create customizable functions in our applicationswithout the need to compile and release new version.

Lets say a user creates a C# file called Formual1.cs to perform some calculations and need to use it in our program. In order to accomplish this we should have an interface the user must implement. This will make it easier for us to execute his or her code.

I have a good amount of experience in real-time trading systems. One area of expertise is in developing GUIs that can handle real-time updates. I want to explain and show you some of the techniques I use when developing a GUI to handle this many updates.

Task:

• Create a GUI to receive real-time updates and display them in a grid.
• Use a DataTable and bind it to a Grid.
• Use a background Thread to simulate real-time updates.

Issues to be aware:

• Updates can and will be occurring faster then you GUI can handle.
• The GUI must always be responsive. Users do NOT like it when the application freezes because of updates occuring.
• Updates will not be real-time. It will appear to be real-time because of the implementation, but users should not see any noticeable delays.

I am not really going up against these guys, and not because I don't think 1 person could do it better. I just wanted to choose an interesting project to show you how easy socket communication is in .NET. The objective is to show you how to connect or listen on a socket, plus transmit and receive data.

I am organizing the solution into 3 parts: Client, Server, and Shared. The Client is a simple front-end to input messages that will be sent and display messages received. The Server will listen for client connection and route messages to the clients. The Shared project is where the standard communication engine will be developed the Client and Server will need a reference and re-use the same communication engines. The Client and Server will only need to implement specific functions unrelated to communications.

Do you run out of memory becuase everything is cached in memory and hit the limitation imposed by 32-bit machines?
Do you need to preserve objects when your application restarts?

If you answered yes, then I have a simple solution. Use serialization to cache objects to disk. When objects are added or updated to a collection then serialize it to disk and de-serialize when a retreive request is made.

I started this project called PersistentCaching and created a class called PersistentArrayList. The first step was to define methods I wanted to support, and I decided on the following: Add, RemoveAt, Clear, Item, and Count.