Books I currently flip through #6

Methods

• Implementing Lean Software Development
• Lean Software Development: An Agile Toolkit
• Microsoft .NET - Architecting Applications for the Enterprise
• Test Driven Development: A Practical Guide
• Fit for developing Software: Framework for Integrated Tests
• The Art of Agile Development

Finance

• The (Mis)behaviour of Markets (Benoit Mandelbrot)
• The Ascent of Money

XPath

XPath came handy lately as I needed to look-up an in-memory XML document.
I know it's probably smoother with Linq to Xml but my project had to compile under VS2005 so I used the .NET 2.0 library which does not contain Linq but contains XPath.

Starting from the following xml file:

<?xml version="1.0" encoding="utf-8"?>
<pigs>
  <piggy infected="false" name="bob"/>
  <piggy infected="false" name="alfred"/>
  <piggy infected="true" name ="rodrigo">
    <disease name="swine flu"/>
    <disease name="boredom"/>
    <disease name="pig blues"/>
    <address>confidential</address>
    <phonenumber>01234546576</phonenumber>
  </piggy>
</pigs>

To load the XML in memory:

XmlDocument doc = new XmlDocument();

try

{

doc.Load("piggy.xml");

}

catch (XmlException e)

{

Console.WriteLine("Could not load the file. Detail: " + e.Message);

}

To query elements based on their name:

XmlNodeList allPigs = doc.SelectNodes("/pigs/piggy"); // Returns all nodes called 'piggy' located inside the root-level node called 'pigs'.

foreach (XmlNode node in allPigs)

Console.WriteLine(node.Name + " " + node.Attributes["name"].Value);

To query elements based on their attribute name:

// Returns only infected pigs

XmlNodeList infectedPigs = doc.SelectNodes("/pigs/piggy[@infected='true']");

foreach (XmlNode node in infectedPigs)

Console.WriteLine(node.Name + " " + node.Attributes["name"].Value);

To return a single node (same query as above but only one node is expected):

// Returns the single infected pig

XmlNode infectedPig = doc.SelectSingleNode("/pigs/piggy[@infected='true']");

if (infectedPig != null)

Console.WriteLine(infectedPig.Name + " " + infectedPig.Attributes["name"].Value);

To do a query relative to the current node:
All queries above were made relative to the top of the document. But it you call SelectNodes against an XmlNode, you can do a query relative to that node. Just ommit the '/':

// Query relative to the current node. Returns all diseases for the infected pig

XmlNodeList diseases = infectedPig.SelectNodes("disease");

foreach (XmlNode node in diseases)

Console.WriteLine(node.Name + " " + node.Attributes["name"].Value);

Resources:
MSDN: XPath Syntax
LINQ to XML queries
XML Support in SQL Server 2005

Webforms vs MVC (London .NET User Group)

100 people listened to Sebastien Lambla and Phil Wistanley at the Microsoft customer centre in Victoria. They talked for 2 hours without a break. Two hours is a long time but the formula they adopted was entertaining and fun. Seb was supporting MVC, Phil Webforms. They kept rotating at the mike, going through humorous slides, throwing jokes at each other and interacting with the audience. Seb:

• Webforms has a tendency to hide HTML and actually generates a lot of goo.
• MVC relies on you knowing HTML but once you learn it, things get pretty easy.
• Webform's page lifecycle is complex
• Webforms is for morons.

Phil:

• MVC is too complicated,
• Webforms has a lot of ready-made controls, lots of 3rd party vendors
• Uses a familiar event model
• MVC is for hippies.

To sum it up, Webforms is for building apps quickly (better suited for the financial world), MVC is good if you need a high level of quality and testability.

C++/CLI Cheat Sheet

My C++/CLI pocket reference...

• Declare a string

System::String^ myString = "";

• Declare a null reference

System::String^ myString = nullptr;

• Pass a string by reference to a method (the reference to the string will be modified, not the string itself since strings are immutable). Use %:

void MyMethod(System::String^% myString)

{

}

• Declare an array of strings

    cli::array<System::String^>^ stringArray = gcnew cli::array<System::String^>{"Skype","Blogger"};

• Declare a managed member inside a native class

class IAmNative

{

    gcroot<IAmManaged^ > managedMember;

public:

    IAmNative():managedMember(gcnew IAmManaged())

    {

    }

};

• Declare a managed member that will self destroy

#include <msclr\auto_gcroot.h> 

class IAmStillNative

{

    msclr::auto_gcroot<IAmStillManaged^> managedMember; // Will be disposed when IAmStillNative is destroyed

public:

    IAmStillNative():managedMember(gcnew IAmStillManaged())

    {

    }

};

• Convert a native STL string to a managed string

System::String^ ToManaged(const std::string& nativeString)

{

    return gcnew System::String(nativeString.c_str());

}

• The same backwards:

std::string ToNative(System::String^ managedString)

{

   char* str = (char*)(void*)System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(managedString).ToPointer();

   std::string result(str);

   System::Runtime::InteropServices::Marshal::FreeHGlobal((System::IntPtr)str);

   return result;

}

Things you can do

• Instantiate managed types, call managed methods from native code provided it compiles with /CLR.
• Instantiate native types, call native methods from managed code
• Link to the native types of a mixed static lib (/clr)
• Declare managed methods that have native types in their signature

Things you can't do

• Link to the managed types of a mixed static lib
• Link to managed types in a DLL if those managed types have methods with native types in their signature.

First Contact with DevExpress

Recently I had the opportunity to use DevExpress controls for WinForms. Overall I wouldn't say those controls save you time if you compare with regular Windows Forms controls. The time you save in coding you spend it reading documentation and experimenting with the controls. However the results are definitely superior to WinForms: better looking and with plenty of niceties that come for free (grouping, sorting, customizing, dragging and dropping, advanced tooltips, etc...) The controls I used to far:

• GridControl
• VGridControl
• PropertyGridControl
• TreeList

GridControl Comes with plenty of default features such as very powerful grouping and filtering options accessible to users at runtime. To populate it, simply set its DataSource to a DataTable or an IList.

• If all you do is setting the DataSource then the control doesn't know anything about the data layer, which is good.
• However if you add columns from the designer (either manually or from a datasource) then you create a tight coupling with the data layer, which might be ok depending in the type of app you're creating. I find the designer is great for discovering functionality but when given a choice, it is better to write code: this avoids having the UI know too much about the data.

VGridControl and PropertyGridControl From a distance VGridControl looks like a Property grid control. The main difference is you can display many records at a time while a property grid control displays a single record.

• Both theVGridControl and PropertyGridControl use reflection to display the properties of an object.
• For some reason PropertyGridControl works fine for public properties with exotic types (such as collections) while VerticalGridControl simply doesn't display collection properties -unless there is something I missed...

TreeList The first column contains the tree, the other columns display data in a grid. Handy when each node of the tree contains usefull info and you don't want users to click each node to see the info. Instead you display the info directly in the grid and users can sort and filter as they see fit. Most of the effort with the DevExpress controls is working out what they do. Two main sources:

• The DemoCenter that comes with the DevExpress install
• The blonde and brunette from DevExpress TV

T-SQL vs PL-SQL

"Oracle PL-SQL is the same as Microsoft T-SQL. If you know one, you know the other"

Not really.

Here are a few differences, some of them can have a serious impact of the way you write sproc code.

Good:

• T-SQL: stored procedures return result sets very easily: all you have to do is write a select statement without any 'INTO'. PL-SQL: you have to select into a ref cursor and define this ref cursor as output parameter.

Bad:

• T-SQL: stored procedures do not rollback automatically if something fails. Until SQL Server 2005 you had to test @@ERROR after each and every statement and goto a handler to rollback. Ugly, tedious and error-prone. In 2005 you can use a TRY CATCH, which is much more elegant. However you still have to rollback explicitly
  PL-SQL: sprocs are atomic. Any error inside a sproc rolls everything back up to the point where the sproc was called.
• T-SQL: no %TYPE! You can't refer to the type of a column without repeating it.
• T-SQL: RAISERROR does not break the flow. It simply returns an error string or message but the sproc still returns normally. Unless you use it within a TRY block, in which case the flow is diverted to the CATCH block (for SQL 2005 and beyond). Depending on the severity level you specify, RAISERROR within a TRY block either
• returns an error number without breaking the flow
• jumps to the CATCH block
• breaks the current database connection (wow!) (provided you have sysadmin role)
• PL-SQL: raise_application_error throws an exception, exits the current sproc, rolls back till implicit savepoint at the beginning of the sproc...

Other differences:

• Oracle does not have a BOOLEAN column type, although you can define a BOOLEAN variable in PL/SQL. SQL Server has a BIT column type where values can be only 0 or 1.
  

Using NUnit with C++ - Part 2

Follow up from part 1 We've been experimenting at work with writing unit-tests against native code for 2 months now. We're using NUnit together with CruiseControl and it works fine.

• the test project is a C++/CLI DLL compiled with /CLR option.
• the project containing the code under test has an additional project configuration that generates a static LIB instead of an executable.
• the test project links to the native LIB above.

What if the code under test is C++ compiled with /CLR? For some reason I thought it wasn't possible to create a static LIB when the /CLR option was active. C++/CLI is very flexible and you can generate a static library containing a mix of managed and unmanaged code. The purpose of building a mixed static lib is to easily import native code into a test project. We keep the test project and the code under test in separate solutions.

Get time in HH:mm format regardless of the local culture

DateTime.Now.ToShortTimeString() returns a string that depends on the culture. DateTime.Now.ToString("HH:mm") is deterministic. Use DateTime.Now.ToUniversalTime.ToString("HH:mm") to get the current HH:mm time in UTC.

Using NUnit with native C++

NUnit was designed to be used with managed apps. So what?

All you need to do in order to test native code is create a C++/CLI project to host the test files. To link the test project to the native C++ project, simply add a configuration to the solution and call it ReleaseUnitTests for instance. This configuration will build the native C++ project as a static library as opposed to an executable. The C++/CLI test project links to this library and can call into any public method of the native project.

Job done! Who needs cppunit?

Detailed steps:

1. Install NUnit.
2. In Visual Studio Pro, create a native C++ project and call it CatHouse
3. Add a class called Cat with a public method void Feed()
4. Add another project to the solution: choose Visual C++ > CLR > Class Library and call it CatHouseTests. This will create a mixed assembly containing both native and managed code.
   Add a C++ managed class called CatTest. Declare it public because we want it to be a managed type that can be seen by Nunit. Add a public method called TestFeed().
5. Open CatHouseTests project properties, go to Common Properties > References and add the nunit.framework.dl assembly.
6. In CatTests.h, add the line using namespace NUnit::Framework.
7. Now you can add the [TestFixture] and [Test] attributes to the class and test method declarations respectively.
8. By default the CatHouse project has a Debug and Release configurations. Add a new one called ReleaseUnitTests: in Build > Configuration Manager in the Active Solution Configuration drop-down, select New. In the dialog, type ReleaseUnitTests and in Copy settings from choose Release. Click OK. Now all projects have a configuration called ReleaseUnitTests.
   Using Configuration Manager, ensure that the Debug and Release solution configurations build CatHouse only and not CatHouseTests. Ensure that ReleaseUnitTests builds both CatHouse and CatHouseTests, both having project configuration ReleaseUnitTests.
9. Open the properties of project CatHouse and in Configuration Properties > General, select Configuration ReleaseUnitTests. Change configuration type to Static Lib (that will make it possible to link all the content with the test program).
10. Make CatHouseTests link to the .lib generated by CatHouse. In Project Properties of CatHouseTests, go to Common Properties > Add New Reference > Projects > CatHouse.
11. Add a #include "Cat.h" in CatTest.cpp and change the project properties so that it knows where to find the include.
12. In the TestFeed() method, instantiate a Cat object on the native stack and call its Feed() method.
13. Build the solution in Release mode then in ReleaseUnitTests mode.
14. In the NUnit GUI type Ctrl O, select the CatHouseTests.dll. The TestFeed test should appear in the tree view.

TechEd EMEA 2008 Developers Wrap

What I got out of this TechEd Saw a total of 15 sessions and did 4 labs. If I had to pick just one thing, that would be VC9 DBPro (VSTS2008 Database Edition) with its database deployment and sproc unit-testing features. I saw a talk about it then played with it at the lab. It has the potential to remove a LOT of pain from schema upgrades. Because most sessions I picked were centered around unit-testing I'm a bit less ignorant about the subject:

• now I know there is a descent framework for unit-testing native C++ code in VSTS2008 Dev. Ok you have to write C++/CLI but the next best thing is cppunit so... VSTS2008 Dev is apparently the best tool around for the moment.
• database unit-testing in VC9 DBPro where it creates a C# class for you that automatically calls a T-SQL sproc where you write your test.
• other tools: I had an overview of the tools available for managing unit-tests and IOC containers: Pex, TypeMock, TestDriven. They're on my list of things to try out next.

Integration Testing:

• It's worth digging into SpecExplorer 2007 and see what can be done with it. The idea of creating a simplified state model of your system and having the tool generate all possible paths for you is very interesting.

Methodologies

• I am now a bit more familiar with IOC frameworks, interface-based coding and TDD so I feel more confident to start writing my first unit-tests. One day maybe I'll write tests before the code...