Usually when I develop, I write individual tests and then run individually with TestDriven.NET and collectively with Resharper.  In this case, as I was writing one unit test, it kept failing with TestDriven.NET.  At first I thought it was just me being stupid (always a good place to start), and then I was worried that perhaps the documentation for TypeMock was to blame.  So, I sent a email to Avi at TypeMock, mostly expecting confirmation of my stupidity.

Turns out the problem in this case was pretty obscure one (to me).  At home, I do my development in a VM running Windows 2008 64 bit.  When Resharper runs your unit tests, it does in a 32 bit process.  TD.NET, on a 64bit OS,  runs as a 64 bit process.  If you get TD.NET to run as a 32 bit process, then your tests will run fine under TD.NET.

To do so, from the Visual Studio 2008 Command Prompt, change to the directory that you have TD.NET installed in.  Then use corflags:

corflags /32bit+ ProcessInvocation.exe

Note that it’s probably best to do this when logged in as the Administrator.

I will say that I was happy with the support I got from the guys (Avi, Gil and Ohad) at TypeMock.  Given the fact that we’re about a half a world apart (western Canada vs. Isreal), they provided prompt, excellent support.  My thanks to them.

The rich user experience that Silverlight brings to the web-browser, will, I think raise the bar for what web applications will do for businesses.  Forget all the buzz about ASP.NET MVC or MonoRail or ASP.NET 3.5.  This is just another layer of makeup on the tired, old, hooker that is application development in .NET.  Silverlight is what will make business users oh and ah and get excited about web apps again.

Those who were at last night’s talk will remember that Rod was using a fairly large database that he got from freedb.  It’s fairly large, not quite 7GB of data.  I did get a copy of it, in MS-SQL Server format.  When I compressed it (tar.gz), I got it down to 2GB in size.  If you’re interested in a copy of the database for your own purposes, leave me a comment here and we’ll work something out.

Note:  I would like to state that Don is usually drunk, and as such you shouldn’t believe some of the wild things he said last night, especially about me.

I’m not to sure I’m a big fan of how openSUSE mounts (or tries to mount) my external HDD.  It just doesn’t seem as…seamless…as how Windows XP does it.  I’m use to just plugging in my external HDD, and not worrying about it until it’s time to disconnect.  openSUSE seems to get a big confused with automounting, and I always seem to have to help it along.  It’s something I can live with for now.

The other thing I notice is that openSUSE doesn’t seem to want to share the sound card with VMware.  I’m getting more than a few alerts from VMware that the sound card is not available and can’t be used.  Again, nothing to critical – for now.

The third thing I’m noticing is that some HDD enclosures seem to work better than others.  I’m noticing that at least one HDD enclosure (a SmartDisk FireLite with a 250GB HDD inside) doesn’t seem to want to consistently and reliably work.  I did have VMware (and openSUSE) complain that they could not write that particular HDD as it could no longer be found.

So far, I am pleased with how Linux is handling NTFS as well.  I remember back five or six years ago that NTFS support for Linux was pretty much read-only.  Read-write was for people who were delusionally insane or who go to the same hair stylist as Justice Grey.

A couple of lessons learned:

• Get lots of disk space.  I’m thinking it may be time to get a 320GB HD for my laptop, and keeping my "working" VM’s there.  I’d have something like a 100 GB partition for Windows XP, and then 220GB for openSUSE.
• Backups – I’m very happy that I made copies of my VM’s and worked off those. 
• Fear not the command line.  But if you’re a *nix guys, you’re probably there already.

I first repartitioned my hard drive (thanks gparted), and set aside a 15GB partition.  On this partition, I installed OpenSUSE 11.

My plan is to run OpenSUSE 11 as the host OS, and then use VMware to run VM’s for my work and such.

I’m curious as to how it will work out.  I know the one hurdle I would like to come is the stupid DRM that Apple iTunes uses.  Anybody have some suggestions, so I can do this while it’s still legal to format-shift in Canada (or perhaps I should spell it Kanada if bill C-61 passes).

Likewise, if you’re British, I would suggest taking a moment today and reading up on Sword and Gold beach.

And, if you are American, then perhaps read up on Utah and Omaha beach (the most heavily defended beach of the whole invasion).  And no, watching Saving Private Ryan doesn’t count.

Granted military history (which I read a lot of) can be kind of boring and slow sometimes, but D-Day was a very important day in the 20th century, and some of the troops involved had been training for almost a year for just this one day.

Client side, the user would click on a button in their browser, in order to "check out" or "check in" – pretty simple stuff.  Click a button, update a record in the database.  I wanted this done via AJAX, as the page itself is pretty heavy with data, and I didn’t want to go through the whole page lifecycle.  I spent some time Googling how to do this on the web, but I didn’t find anything that seemed to be suitable for something as simple as this.

So, enough boring stuff, on with the issue.  In my current application the ASP.NET web service that the client should call looks something like:

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[ScriptService]

public class CampaignProductCheckoutService : WebService, ICampaignProductCheckoutService

{

  [WebMethod]

  public void CheckIn(int campaignProductId, int loginId)

  {

    // Do something...

  }


  [WebMethod]

  public void CheckOut(int campaignProductId, int loginId)

  {

    // Do something...

  }

}

Pretty simple webservice, nothing fancy.  Here is the corresponding Javascript on the browser:

$.ajax({

  type: "POST",

  url: "CampaignProductCheckoutService.asmx/CheckOut",

  data: "campaignProductId=3&loginId=4",

  beforeSend: function(xhr) {

    xhr.setRequestHeader("Content-Length", "campaignProductId=3&loginId=4".length);

    $("#progressBarContainer").show();

  },

  dataType: "xml",

  complete: function (xhr, msg) {

    $("#progressBarContainer").hide();

    if (xhr.status == 200) {

      alert("Happy Times!");

    }

    else {

      alert("Wailing and gnashing of teeth!");

    }

  }

});

This looks busy, but in reality, it isn’t. Now, for a detailed explanation of what is going on here, I’d suggest reading the book jQuery in Action.  It is a most helpful book for learning jQuery.

Anyway, here is a quick rundown of what is going on:  the $.ajax is a jQuery method that will perform the AJAX call, using the parameters that we provide it.  jQuery will perform an HTTP post to web service specified in url.  As part of the POST request, you can see that we’re passing in the parameters for the webservice call.  So far, pretty straightforward.

The next line, beforeSend, is a javascript method that jQuery will call before it does the POST.  In this case, we make sure that the request header has the length of the data being sent, and we show a progress bar to the user.  The funny syntax you see there is how we select the DIV element holding our animated gif and display it to the user.

Your standard ASP.NET web service will return XML to the client, and we inform jQuery of that with the dataType parameter.

By default, jQuery will perform the AJAX call asynchronously, so in the final line we provide another Javascript callback.  jQuery will call this function once the request is finished.  In this case, we hide the DIV element holding the progress bar, and we check the XMLHttpRequest object that is returned from jQuery. If the status is 200, then all okay and we display a happy message.  Otherwise we assume the request failed, and display a sad message to the user.

There you have it, a quick and dirty explanation of using jQuery to call an ASP.NET Web Service.

I remember when I first discovered Ant, and then Nant* .  I was pretty happy, as it allow a decent way to compile my Java (and C#) without using make files.  Life was good as I could finally introduce some structure into HOW code was compiled.  The build process was no longer using whatever “build” command the IDE exposed, hoping that I didn’t forget a compiler directive or a file or a reference to some other library along the way.  Other programmers could also compile the code with out fear as well.  Having a tool like Nant is pretty crucial to the whole concept of continuous integration.

Somewhere along the way, though, Nant lost it’s shine.  It isn’t to hard to find these monster Nant scripts with all kinds of crazy things happening inside them.  Trying to work with these files can be a bit of a burden, to say the least.

This takes me back to the title:  it seems to me that build tools like Nant have kind of peaked, functionally speaking.  What does that mean?  We can always add more tasks (created in a real programming language) to do things for us, but in a lot of ways Nant is constrained by the fact that it is just XML.  We can always add tasks to Nant, but somethings just can’t be handled by out of the box, one size fits all tasks from Nant (or NantContrib).  As soon as you run into those things, you need to start writing code.  XML is good for config files (to a point).  It’s bad for programming logic.  It is not at all uncommon to see in build files if statements doing all kinds of things.  We don’t need to (and should not) make XML into another programming language. 

I spent a bit of time tonight playing with Bake.  For those who don’t know, Bake is to boo what Rake is to ruby.  Or, in other terms, think of a build system that is actually based on a programming language, and not a configuration file.  Why did I pick Bake?  Well, it’s boo, and I want to learn boo.  Boo is .NET, so I can leverage what I already know.  Plus, I’m reading Ayende’s book Building Domain Specific Languages in Boo, so Bake just seems to be a natural fit.

So far, I’m liking it.  In the span of a couple hours, I managed to figure out how to create a quick bake script (~ 40 lines of boo) to compile some code.  I’d say that this script more readable (or soluble, to use the words of Scott Bellware) when compared to a Nant script.  Being pretty new, Bake doesn’t have as many tasks as Nant.  However, it does seem pretty easy to create tasks for Bake.  Plus, I have all the expressiveness of a programming language available to me now

I did have one glitch that is worth mentioning:  the task to compile my code was using the CSC.EXE from .NET 2.0.  This is a problem when you’re working with a .NET 3.5 codebase.  But, no fear, I hacked out a quick fix inside of about 15 minutes, and all is well again.

I imagine that someone soon will blog about using Rake to build your .NET projects.  I eagerly await such a post.  In the meantime, I’m going to continue on with Bake, and see if it will meet my needs.

* NOTE:  I lump MSBuild in with NAnt as MSBuild, IMHO, is a clone of NAnt.

I found it to be a pretty hard topic to cover in not quite 120 minutes.  There is just so much to cover and explain.  As well, it seemed that there were a couple in the crowd that felt a bit overloaded.

Congratulations to Carlos for finding the spot in my sample code where <technobabble>dependency injection could be use to create a less-tightly coupled controller</technobabble>.  I was going to give him the Reshaper license for finding it, but he had already has one and so declined.  It was eventually raffled off at the end of the presentation.

For those who wanted the code and slide deck, here they are.

Someone else asked for a sample MonoRail application that they could look to help them learn MR.  Here are a couple

1. altnetconf on googlecode.  This is the code for the website of the first altnetconf held in Austin, TX in October of 2007
2. Gearblog:  a blog build on MonoRail
3. mr-blogengine:  Another blog build on MonoRail.  This code is part of a series of blog posts about incremental development in MonoRail.

Lessons learned – a lot of them relate back to what are considered good, OO practices:

• DRY, especially with the very small things.  When Jeremy was adding support for .NET 2.0, the generic support was problematic.  
  Example:  Want to resolve a Repository<T>.  You can’t just look for the class Repository`1: i.e. was trying to resolve the class by using  typeof(Repository`1).  This did not work.
• Tell, Don’t Ask.  Didn’t follow this to heavily at first, and so now effort has to be taken to rewrite code to adhere to this principle.
• Using a lot of Double Dispatch (hah!  look Jeremy the picture did turn out):
  
• If you need to refactor, do it now.  Procrastination only makes it (refactoring) harder and more costly.
• If you want to build a .NET framework and keep it around for four to five years, you should probably learn a bit about the fundamentals of .NET.
• Small steps, frequent commits to source code.
• Good solid battery of unit tests really helps with major changes.
• Moving more towards coarser grained tests.  Does the test check the functionality?  Not to worried about the intermediate steps.
  • Assertions based on side effects really don’t work well.  Not very expressive, sometimes hard to figure out what what you’re trying to test.
• It helps have tooling inside your tests in order to help you quickly create tests, especially the difficult to setup/create tests.  Will result in a faster feedback cycle.  This infrastructure is more strategic, can be very help.
• Jeremy recommends "Pragmatic Programmers"

Brief discussion about where to start learning all these pattern.  Advice is given to learn principles first (DRY, OCP, SRP, SOC, etc) as this will greatly help with the understanding and proper use of design patterns.

1. Mono.Cecil.  For all your reflecting and assembly modification needs.
2. Mono.Addins.  I’ve been looking at this off and on today, and I have to admit it looks pretty intriguing
3. Mono.Rocks:  Handy extension methods.
4. Mono.Zeroconf: Zero configuration networking library
5. DBus#:  A C# implementation of D-Bus.
6. MonoCurses: An API for console based applications
7. GTK# vs Windows:
   • My suggestion is to consider the target environment.  If you targeting Windows, stick with WinForms.  If you’re targetting Linux/Mac, go with GTK#. 
   • Another issue that might influence your decision is that the documentation for GTK# is pretty sketchy, not very good.
8. IOMap.  Turning this flag on, will help you with some of the cross-platform development issues.  This is a portable library that will help resolve things like directory seperators, case sensitivity in paths, and that sort of thing.

A short session, which isn’t bad.  Gives me a chance to float around to check out some other things.