# Thursday, November 01, 2007

In my previous post I assumed that I would need to explicitly load my child objects through my service and provide a finer grained service interface to support that model.  After digging through Udi Dahan's blog posts again I found a very relevant post about using a fetching strategy to specify how deep you want the object model to be for any specific request.  By being able to specify a fetching strategy in the consumer code I can return the proper size object graph without making my service interface chatty.

This does leak some of the service logic into the client code, but really I'm OK with that.  The alternative is to explicitly call each service method which I think is harder to maintain and makes the object model pretty difficult to use. 

After using Mule ESB at my last job I've found it kind of hard to go to plain old web services.  I really like the messaging paradigm and separation of concerns an ESB provides.  Now if I could just find the SVN repository for NServiceBus.

Thursday, November 01, 2007 5:43:20 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 

I downloaded the NHibernate VS2005 plugin and started to use it - its very similar to the Hibernate support built into Eclipse.  Unfortunately after playing around with it for about 20 minutes I realized my data model (in the DB) was complete poo and the plugin wasn't built to handle legacy databases, which I completely understand because that's where the majority of NHibernate's complexity lies IMO.

I really don't want the crappy data model to leak into my object model - even though it would be super easy and fast to "whip it out" using the plugin or another code generator.  I'm kind of stuck on what to do right now.  Part of the problem is I'm not sure I have time to "do it right." I have a hard deadline looming from a 3rd party that can't budge.


I think I may start out modeling my object model from scratch, which isn't too bad with Re# installed.  Then from there start manually mapping some of this stuff to the existing sprocs or creating some new views.  I also have the problem that this will all be serialized and sent over a web service and/or NServiceBus, so I'm not sure how to handle relationships.  Probably in most cases I'll just have IDs of the FKs and then explicitly make another fetch from the service since lazy loading is pretty much out of the question.

Thursday, November 01, 2007 3:17:34 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, October 29, 2007

I opened up another tab to Udi Dahan's blog, at which point my PC came to a screeching halt.  After finally getting the task manager open I noticed FireFox was using 1.5GB of RAM.  Wow!  IE never uses that much memory - in fact IE usually crashes well before it ever gets that much memory consumed.  Here's a look at my memory usage after I killed FireFox, note the huge drop in the Physical Memory Usage History (blue line).

FireFoxMemUsage

WTF
Monday, October 29, 2007 5:44:12 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, October 26, 2007

I just checked off my last item (fast PC) from the "Programmer's Bill or Rights."  Compared to my last job that's a 66% improvement.

Friday, October 26, 2007 5:25:22 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 

Setting up a new Windows development machine is a pain.  In fact it's more work than setting up a Linux development machine.  In Linux the package manager for the OS, the Rails package manager, and/or the Eclipse update manager handles most of this for me.  In Windows I'm forced to install things individually using separate installers.  Here's the minimum I had to install on my brand new Windows Vista box to get a decent development environment:

  • Visual Studio 2005
  • VS 2005 SP1
  • VS 2005 SP1 patch for Vista
  • Windows Vista SDK
  • WCF for VS 2005
  • .NET 1.1 Runtime (yes, I still have a project that compiles .NET 1.1)
  • ReSharper 3 for C#
  • SVN
  • TortoiseSVN
  • VisualSVN

That's just to get my machine compiling our code, that doesn't even include the numerous other tools I need to be productive like Paint.NET or MS Office.  All in all, I had to install around 30 applications yesterday!  No wonder I've been dragging my feet on getting a new system for the past month.  The good news is, I'm now done and this new 3GHz dual core system with 3GB or RAM freakin' rocks compared to my old Dell Dimension 4600.

Friday, October 26, 2007 5:17:09 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Sunday, October 21, 2007

Scott Bellware brought up SmartBear Code Collaborator code review tool as a way to annotate code on the ALT.NET mailing list today.  It looks really interesting to me since my entire team works remotely and facilitating code review is pretty difficult.  We've used NetMeeting in the past, but I would like something that promotes a more organic code review which naturally happens when co-located.

The really neat thing is that integrates tightly with source control systems such as Perforce's Windows client so that you can initiate a code review of a particular changelist before checkin.  I didn't see any mention about SVN integration...

Sunday, October 21, 2007 6:17:41 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, October 18, 2007

It seems I keep running into situations where I want to mock or stub a class that is responsible for saving something out to disk.  The problem is that using a StreamWriter (or similar) is the lifetime of the writer object is shorter than the containing class, which makes it impossible to mock effectively.

Often the way around this is to implement an interface with three method calls: Open, Write, Close - so you can reuse the writer instance for multiple files thus changing the lifetime of the writer to the same as the containing class thus allowing you to mock the writer.

I've never liked this solution, it always has felt like a workaround for testability.  Instead, how about splitting the two parameters (contents and file path) into separate fluent method calls and having the Write auto-close the file like this example:

keyWriter.Write(exportKeys).To(destinationFolder);

 

...

 

public interface IExportKeyWriter

{

    IExportKeyWriter Write(ImageExportKeys keys);

    void To(string destinationFolder);

}

 

I like it because its very readable and more importantly its mockable.  I can inject a single instance of the IExportKeyWriter into my class under test.  When Write is called, the object is queued for writing to disk, and when To is called the destination file is opened, written to (using the queued object), and finally closed.

The only Problem I can think of is that it may not be obvious that you need to call the To method to have the file actually written out.

I'm hoping for some feedback on this, so I ask dear reader, what do you think?

Thursday, October 18, 2007 1:29:09 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, October 17, 2007

This isn't something I have had to deal with a lot, but this PDF looks likes its useful for coming up with a XML versioning scheme.  So far I've just chosen to go down the path of least resistance and add a schemaVersion to my XSD along with a schema version attribute in my XML instance docs.

XML
Wednesday, October 17, 2007 5:20:38 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, October 16, 2007

The following code snippet causes a stack overflow exception.  Can you spot it?  I almost didn't catch the case difference.  See it now?  I'm surprised the compiler didn't complain - at all, however ReSharper found the recursive call and squiggled it.  Yet another reason to get Re#.

 

public string CreatedDate

{

    get { return createdDate; }

    set { CreatedData = value; }

}

Tuesday, October 16, 2007 7:33:42 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Sunday, October 14, 2007

I needed the ability to kill a process and any of its child processes, but System.Process.Kill() does not kill any child processes. 

I tried using the JobObjectWrapper library, but unfortunately it doesn't work when running from an existing job, which is exactly the scenario I needed since Visual Studio 2005 on Windows Vista is already running under a job.

The solution I opted for was to use the WindowsXP Pro/Windows Vista taskkill.exe utility since it supports kill a task tree.

/// <summary>

/// Will kill a process and all its child processes.  This class requires

/// taskkill.exe present in the WINDIR\System32 directory.

/// </summary>

public class TaskKill

{

    private readonly int pid;

    private readonly string imageName;

 

    public TaskKill(string imageName)

    {

        this.imageName = imageName;

    }

 

    public TaskKill(int pid)

    {

        this.pid = pid;

    }

 

    /// <summary>

    /// Kills the process associated with this TaskKill instance.

    /// </summary>

    public void KillAssociatedProcess()

    {

        if (!string.IsNullOrEmpty(imageName))

            KillProcessByName();

        else

            KillProcessById();

    }

 

    protected void KillProcessById()

    {

        string killArgs = string.Format("/F /PID {0} /T", pid);

        ExecuteKill(killArgs);

    }

 

    protected void KillProcessByName()

    {

        string killArgs = string.Format("/F /IM {0} /T", imageName);

        ExecuteKill(killArgs);

    }

 

    protected string GetTaskKillExePath()

    {

        string taskKillPath = Path.Combine(Environment.SystemDirectory, "taskkill.exe");

        if (!File.Exists(taskKillPath))

            throw new FileNotFoundException(

                "Cannot find taskkill.exe in the Windows Sytem32 directory.  Are you running WindowsXP Home which doesn't include this utility?");

 

        return taskKillPath;

    }

 

    private void ExecuteKill(string processShellArgs)

    {

        ProcessStartInfo info = new ProcessStartInfo(GetTaskKillExePath(), processShellArgs);

        info.CreateNoWindow = true;

 

        Process process = new Process();

        process.StartInfo = info;

        process.Start();

        process.WaitForExit(5000);

    }

}

 

The code that uses the TaskKill class looks like this:

[Test]

public void Test1()

{

    ProcessStartInfo info = new ProcessStartInfo("notepad.exe");

    Process process = new Process();

    process.StartInfo = info;

    process.Start();

 

    Assert.That(!process.HasExited, "Process exited early");

 

    TaskKill taskKill = new TaskKill(process.Id);

    taskKill.KillAssociatedProcess();

 

    Assert.That(process.HasExited, "TaskKill failed to kill the process");

}

Sunday, October 14, 2007 6:07:44 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  |