February 2005 - Posts
Dinner in Prague:

Some lifecycle concepts have been seriously considered by the whidbey teams. Here's a quick walkthrough to illustrate the way Unit Testing is handled in VS2005.
I create a (highly complex) mathematical class as follows:

To automatically create a test for the Add method, right-click, and select Create Tests. You'll see the Test Menu:

Select what you want to do, and click Generate. The Test generated for my class looks as follows (note the NUnit-like attributes):
[TestMethod()]
public void AddTest()
{
int OneInt = 2; // TODO: Initialize to an appropriate value
int AnotherInt = 5; // TODO: Initialize to an appropriate value
int expected = 7;
int actual;
actual = Ernst.Testing.MyMath.Add(OneInt, AnotherInt);
Assert.AreEqual(expected, actual, "Ernst.Testing.MyMath.Add did not return the expected value.");
Assert.Inconclusive("Verify the correctness of this test method.");
}
Running tests is summarized in the Test Results-window:

Tests are managed from the Test Manager, which looks something like this:

Now I don't know if the “Generate Tests” functionality is such a good feature - personally I wouldn't have my team use it, since it totally defies the object of Test Driven Development. (This is more something like Development-Driven Testing).
There you are - look forward to it yet? VS2005 is seriously cool, that's a promise! And that's enough screenshots for one post.
Something I found out today (thanks Justin!) is that in .NET 2.0, you can restrict access to your properties' getters and setters individually, like so:
public
string MyProp {
get { return _myProp; }
protected set { _myProp = value; }
}
As long as the nested modifier is more restrictive than the property declaration's (public in my example). This also applies to indexers. Cool!
The Eastern Europe / Middle East / Africa Regional MVP Summit is being held in beautiful Prague over the weekend, so that's where I'll be heading on Thursday. The average day-temperature difference between Durban and Prague right now is about 32 degrees Celsius! (So much for my mostly-boardshorts-and-flops-wardrobe)
I said that we're using Team System in our current project. Well, at the moment Team System does not provide us with enough functionality to live without the following open source tools:
- CVSNT
- TortoiseCVS
- CruiseControl.NET
- NUnit
- NAnt
- NMock
One of the coolest enhancements with Whidbey is that project- and solution files act as “build scripts” for MSBuild, the new .NET build engine. These files look similar to those XML NAnt scripts. We have customized CruiseControl to run with MSBuild with moderate success (CCNET can't parse the output of MSBuild yet).
I know that Team System in combination with Visual Studio 2005 will provide most of the functionality provided by these tools, and eagerly await the official Beta2 release.
[UPDATE] You can write an XML-Logger for CruiseControl that puts the MSBuild output into a usable XML-form. This can be rendered by creating an XSL for it. Works well enough to see why and where code breaks.
Armand and myself will start a few online Agile tutorials and discussions soon - keep your eyes on SADeveloper.net for details. We plan on having an online, guided Agile project, for members that are keen on learning the Agile processes, to participate in.
The most important concept to understand regarding DDD is that everything in your solution is driven by the business domain. Everything in your application can be seen as services to the Business Layer, which is where the real intelligence of a solution resides. The data-layer (fallacy or not!) is a service to the BL, as is the UI.
The UI is a service that captures external events (from a user) and relays that to the BL for usefull, intelligent processing. It also (visually) represents *only* the intelligence contained in the BL to the (external) user. The DAL is another service to the BL that enables the BL to persist certain facts. I like keeping as little business logic as possible in the database - business logic in stored procedures should be avoided just as much as business logic in the UI. It's all about the domain baby!
Countless posts of toys have been posted... I just had to have a go. This is a recently assembled toy I spend as much time as is possible with:

Cutting edge is where it's at - right now I'm involved in what is possibly the coolest, hippest project around. We are developing a fairly large project, using the latest technologies available, and our Agile methodology diligently follows the analysis- and design principles described in Eric Evans' brilliant Domain Driven Design. Technologies currently utilized in the project:
- Visual Studio 2005
- SQL Server 2005
- Visual Studio Team System (the full system)
- Virtual Server 2005
However painstaking it is developing on a beta framework, we find it still faster than developing with the 1.1 version of .NET, which says lots about “whidbey”. Watch this space!
Tech Ed 2005 dates are up (23 - 26 October 2005, Sun City) and I see absolutely no way of missing it - not after being totally impressed at my first Tech Ed last year.

Ayal Rosenberg on Saturday's P&P session: “The best way to do Java today, is on .NET”.

Tomorrow's session:
A: Domain Driven Design and Application Frameworks
B: Architecture of a Distributed Application
C: Design of a Distributed Application
D: Specialized .NET Technologies Required:
i) Reflection
ii) Remoting
iii) Enterprise Services
iv) Multi-Threading
I hope to see you there tomorrow.
[WARNING: Valueless non-technical plug]
A few of the Agrista folks went for some wine tasting at Snap last night. I highly recommend this spot; there's a nice variety, and the owner seems to know his wine and talks about it endlessly. I might be back on a regular basis!