Month: December 2006

At first I thought “that isn’t a factory!” but that is because the entire post wasn’t there in RSS.

My buddy David Redding has what could be the funniest explaination of the Abstract Factory Pattern that I’ve ever read.

He also mentions the Ann Arbor DotNET Developers meeting coming up on January 10th. It will be awesome to have an expert on Windows Workflow in town. If you are in the Ann Arbor area, stop by at 6pm and see Matt Winkler.

I almost always tend to agree with Jeremy D. Miller over at CodeBetter.Com. This time, I still agree with him. I agree so much that I am wondering if he is joking or was having a bad day and posted this in frustration.

Jeremy, of course Downcasting is a code smell. It does all the bad things that you said it does. I thought that this was a given. I see code like this and I immediately assume that the person who wrote it either 1. was in too much of a hurry to take pride in their work, or 2. had no idea how to program using good OO concepts.

When I run into code like this I usually get VERY frustrated. It is never fun to run into ugly code. It is more frustrating to run into code that could be so much better with just slightly more than trivial understanding of the underlying libraries. I guess this is exactly what I wrote on with respect to System.Data over a year ago. Not the downcasting part, but rather just good use of the supplied interfaces instead of always using the concrete class.

It was downcasting that inspired me to write those posts over a year ago. I was working with a project which was using the DAAB from EntLib 1.0. DAAB returns IDbConnection and it was being Downcast to SqlConnection everywhere it was using in this project. I cursed a bit. Then I realized that all of the code was in my hands, and I went about cleaning it up. It was not difficult. That was something I COULD take pride in. Stupid, yes. Maybe a waste of time, but now I know that the next time I go into that module I won’t be disgusted by what I see.

If you use subversion for version control, you are probably aware of the .svn issues.

I feel like Studio 2003 is Developing Old School. I’ve fully embraced 2005. Now I can hear you developers that are ten and twenty years older than me talking about programming with buttons and switches and the graduation to teletype and finally dumb terminals. While I haven’t experienced that first hand, I can say that I can still develop with notepad or vi with the best of them.

Still, stepping back to Visual Studio 2003 after a full year of 2005 just feels old.

OK, the point is, that I am doing this. I’ve run into the well known .svn issue, and after some searching I think I’ve come up with a better fix than I’ve seen suggested yet.

My fix:
1. Close the project file.
2. Open in a text editor such a gvim or notepad2.
3. Change the value of the ProjectType attribute to “Local” from “Web” under the /VisualStudioProject/VisualBasic node.
4. Open the new project file in visual studio.

It turns out that the web project is just a class library project with a remote target. Why MS feels compelled to continue to abstract this for developers is beyond me. Developers should have a deep understanding of filesystems, both local and remote. If they do not, then purhaps they need additional training, or should consider a different career.

Y E S !!!!!

As usual I couldn’t agree with Oren any more. Of course I read the Joel article when it was released 15 months ago. It is just as true now as it was then. Honestly, I have zero use for the Enterprise Library as a whole. What does it do for me? It doesn’t help me with good design (and architecture, but I hate the “arch” word) like Castle’s Windsor helps me. It doesn’t help me with Database abstraction like NHibernate or Castle’s ActiveRecord. I already have logging with log4net. So what does Enterprise Library do for me? Caching, Configuration, Instrumentation? mmm… Maybe. I’m not sure. I’d rather just enable an NHibernate Cache. For Configuration, Windsor does a lot of this for me. Instrumentation. OK. I’ll investigate the Instrumentation block. I think the Enterprise Library team could learn a lot from Castle.

FIX: Error message when you use the debugger in Visual Studio 2005 to debug an MFC class library application: “Managed Debugging Assistant ‘LoaderLock’ has detected a problem in ‘‘”

I liked Visual Studio 2005 a WHOLE lot more when I wasn’t running into its bugs. Right now, I can’t debug my application. So what am I to do? Resort to pre-debugger techniques? I don’t even remember those. printf littering? log4net for no reason but debugging. This was supposed to be a trivial app to be written in one hour.

Another day, another bug.

I actually write .NET Command Line applications for Windows. I write little tools, that maybe would be usually be written in VBScript by a sysadmin, but since I was a sysadmin and AM a C# guy, I write in the latter. One thing that Microsoft seems to ignore (at least until PowerShell) is the command line and easy programming for the command line. I’ve never seen an equivalent to getopts in any MS Shell, or any API.

Mono implements a getopt library called Mono.GetOptions which works very nice on the Microsoft Platform as well. Just install Mono and copy the Mono.GetOptions.dll from C:\Program Files\Mono-1.2\lib\mono\2.0 or C:\Program Files\Mono-1.2\lib\mono\1.0 depending on which framework version you are targetting. I typically treat this dll as I do any third party dll as part of my project. In my case that means place in a lib directory and keep it under version control. I would prefer the Linux approach of no binaries under source control, but that doesn’t seem to be the standard on Windows projects.

Add the reference within your project to the lib/Mono.GetOptions.dll

The library works by extending Mono.GetOptions.Options and marking member with attributes.  The library includes many helpers, including the ability to automatically generate help messages.

class Options : Mono.GetOptions.Options {
  [Mono.GetOptions.Option(1,"Display this help message", 'h', "help")]
  public override Mono.GetOptions.WhatToDoNext DoHelp()
  {
    return base.DoHelp();
  }
}

The OptionAttribute has a number of default constructors.  In this case the arguments are maxOccurs, shortDescription, shortForm, longForm.  This allows the help to be displayed if you call Options.ProcessArgs with -h or -help.  See the source for more constructor forms: OptionAttribute.cs

To actually allow these options to be processed, you must call Options.ProcessArgs as I stated above.  You can play with options using this simple program:

    class Program
    {
        static void Main( string[] args )
        {
            Options lOptions = new Options();
            lOptions.ProcessArgs( args );

        }
    }

If you do this much and test by invoking with -h or -help, you will notice that there are some other options displayed in the output.  -help2 shows a couple of GetOptions debug and verbose options -~ and -. respectively.
  You will also see a message about using some assembly Attributes if you have not already added them.

[assembly: Mono.About( "This program does stuff." )]
[assembly: Mono.UsageComplement( "nonoptarg1 ... [nonoptargn]\nDo Stuff with nonoptarg1" )]
[assembly: Mono.Author( "Jay R. Wren" )]
[assembly: Mono.AdditionalInfo( "With no args this progam does stuff." )]
[assembly: Mono.ReportBugsTo( "jrwren@xmtp.net" )]


These assembly attributes work with the library to output usage information along with the normal System.Reflection.{AssemblyTitle,AssemblyCopyright,AssemblyDescription,AssemblyVersion} attributes.

Example:

Program 1.0.0.0 - Copyright c MyCorp - MyDiv 2006

Please report bugs to <jrwren@xmtp.net>


Depending on your application you can use Options members such as:


[Mono.GetOptions.Option("debug level",'d',null)]
public int DebugLevel = 4;
[Mono.GetOptions.Option("warning level",'w',null)]
public WhatToDoNext SetWarnngLevel(int warningLevel)
{
  this.WarningLevel=warningLevel;
  return WhatToDoNext.GoAhead;
}


And now you can simply access the Options.DebugLevel and Options.WarningLevel members. They will be set if the -d and/or the -w options were used on command invocation.

Further examples can be seen in the mcat sample from Mono subversion.

Sometime last week Hammett posted links to a history of Castle in honor of its two year birthday.

I love history.

Reading about how castle sprung(punny?) from the Microkernel Pattern was interesting. I often forget that Castle started from Apache Avalon.

Early implementations of “Avalon Castle” could probably be found in CVS or SVN some place if you looked hard enough.

I find explainations of design decisions helpful to understanding a project.

Only 2 months later the Rails ActionPack inspired “Castle on Rails” was born. I think back to what I was doing then, and I realize I was still learning C# and messing with Web Services.

Just 2 days later(Nov 18th) the “Castle Project” was born.

And a few days later the concepts were introduced. Now that I think about it, Castle Project started much like TurboGears. Take the best of breed of some things and enhance them. ActiveRecord is just enhanced and simplified NHibernate. MonoRail’s default view engine is an enhanced NVelocity. Brail is boo, but enhanced for web views (whitespace matters less).

Thanks to everyone developing Castle, especially Hammett and Ayende. Their blog posts have helped me the most.