sfeldman.NET

There was a lot of noise generated by a blog “The Duct Tape Programmer”. There were lots of responses as well (link, link, link, link, link, link, link, link…). The last one I read was from Oren, where he puts it plain – just don’t do it.

I have my reasons to disagree with the statement(s) Joel wrote in his blog, but probably the most important one is about testing. Probably the reason for that is because I was developing without TDD for quiet a while, and I saw the difference. To me tests are design, and if you drop them, well, hell with design. A good project has to have a good design, and design starts from code, expressed first in tests, and after that in production code.

PS: if you disagree, the trash bin in on your desktop, not at my blog comments. 10x

Our new system is entirely based of services (SOA solution). From the day one we had an issue with Visual Studio auto-magically generated proxies and management of those as system grew. Solution at that time was to create clients of the services dynamically, but the knowledge of WCF we had was a minimal. Now, 6+ months later, we finally getting to the point where I am comfortable and pleased with the solution. The interesting part is that WCF had that option all the time, we were not just educated enough to see it. Now we are.

The solution is to leverage ChannelFactory provided by WCF and create a client proxy from an end point defined in configuration file. Let me show the process from the client perspective:

var channel = new ChannelFactory<IWcfAppenderService>("WcfAppenderServiceEP").CreateChannel();

channel is our proxy. Reading carefully Programming WCF Services book from Yuval Lowy (page 48), it is clear that a channel has to be closed, regardless of the state it’s found in after invocation (faulted or not).

using(channel as IDisposable)

          channel.Append(loggingEventDataDto);

.NET using statement does the work.

This is it. To simplify the whole thing, we could intercept method calls on channel with a transparent proxy of ours and wrap with using statements – that way a user does not have to remember to do it each time.

Configuration file for a client would contain the minimal required information:

<system.serviceModel>

  <client>

    <endpoint address="http://localhost:4268/WcfAppenderService.svc"

        binding="wsHttpBinding" 

        contract="WcfAppender.Contracts.IWcfAppenderService" 

        name="WcfAppenderServiceEP">

    </endpoint>

  </client>

</system.serviceModel>

And the last missing part – contracts. A shared assembly with contracts would define all the service and data contracts. This is the only coupling between client and the server, which is logical, because contracts are coupling.

I am not done with my WCF adventures, but I can definitely point to a great book by Yuval Lowy as a reference for WCF. 

I have recently switched from Launchy to Executor after Terry told me about it. I test drove it for a while and find it better than Launcy, which was a great tool. Time for myself to move on to a better tool.

While reading blogs during today morning, I read an interesting one, which captures the way I feel about Pair-Programming. I have my opinion before (old posts), and it’s slightly updated since then, but at the end I still think it’s a great way and not just to develop.

We are using Hudson as a build server, and one of the lasts steps that were taken is to mark a build as ‘unstable’ when we pass a certain number of TODO comments in our code (an arbitrary number). While I am not a 100% sold on a number, I think it’s a good way of insuring things are not just marked and forgotten. Actually, we are not even tracking TODOs, but BROKEN_WINDOW comments, as those are definitely bad. Failing on HACK is another possibility. Visualization plays a significant role in my case (interpretation of things based on visualization), and here how it looks (green is all good, yellow is all passed, but number of comments has exceeded the limit).

Today I was trying to figure out how to access output Gallio is using to render a warning message. According to this, the Assert.Warning was replaced by TestLog.Warning.WriteLine. But for some reason that is not doing the job. Has anyone encountered similar problem?

We run today into this problem, while trying to update our spec-based testing framework. We got the required details from with-in the base specification (test) leveraging TestContext.CurrentContext.LogWriter.Warnings, but with no success. Anyone, ideas?

Recently I had to update our domain model and it required some NHibernate profiling. I have installed trial version of NHibernate Profiler, and it rocked. The fact that it was not only able to show what was going on, but also give suggestions how to improve NHibernate usage just rocked (unlimited records returned).

I also loved straight, cut-the-bullshit communication with Oren, who has responded quickly (to the bug that I found). Worked for me, and we are going to purchase a few licenses.

Our projects are deployed with MSIs. Each MSI file is appended with the product version number (regular staff – major, minor, build number, revision number).

While this is enough for deployment, in production, it is hard to determine what product version is installed without either searching for assemblies to see the version, or some other piece of evidence. Today I decided to leverage Wix to generate the Product Version number, based on our NAnt script.

Nant script has all parts of product version defined as follow:

  1: <property name="version.major" value="1" />
  2: <property name="version.minor" value="7" />
  3: <property name="build.number" value="0" readonly="false"/>
  4: <property name="svn.revision" value="0" readonly="false"/>
  5: 
  6: <property name="project.version.full" 
  7:           value="${version.major}.${version.minor}.${build.number}.${svn.revision}" 
  8:           dynamic="true" readonly="false" />

Next step was updating Wix installer project file to include an external include file with a defined variable for product version, called ProductVersion, and apply that to project. Here’s partial Wix installer file:

  1: <?xml version="1.0" encoding="UTF-8"?>
  2: <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:iis="http://schemas.microsoft.com/wix/IIsExtension">
  3: 
  4:   <?define build_dir = "$(var.ProjectDir)..\..\build\compile"?>
  5:   <?define documentation_dir = "$(var.ProjectDir)..\..\docs"?>
  6: 
  7:   <?include $(var.build_dir)\ProductVersion.wxi ?>
  8: 
  9:   <Product Id="5646ced5-d897-4978-b1d6-338e5baadbe9"
 10:        Name="COMPANY NAME $(var.ProductVersion)"
 11:        Language="1033"
 12:        Version="$(var.ProductVersion)"
 13:        Manufacturer="COMPANY NAME"
 14:        UpgradeCode="790b1905-c843-4973-a078-79874a7f30f2">
 15: 

Include file, ProductVersion.wxi is the one that should contain variable ProductVersion. This include is generated by nant script, injecting nant project.version.full variable.

Nant script to generate Wix include file:

<echo file="${build.compile.dir}\ProductVersion.wxi" message='&lt;?xml version="1.0" encoding="utf-8"?&gt;&#xA;&#xD;&lt;Include&gt;&#xA;&#xD;&lt;?define ProductVersion="${project.version.full}"?&gt;&#xA;&#xD;&lt;/Include&gt;' />

Which results in a file, that contains the required product version variable for Wix installer:

<?xml version="1.0" encoding="utf-8"?>
<Include>
  <?define ProductVersion="1.7.1234.4321"?>
</Include>

Once MSI is installed, Add/Remove programs contains the name with the version: