Oh yeah, we're kicking it up with the DevTool entries.

That's typically what happens as I ramp up on a project; I'll end up coming across a whole slew of awesome tools that I end up aggregating in my C:\Program Files directory (my application menu is about to go past the second page...I had to uninstall a lot of stuff previously to get it back down to two pages).

Today's entries are tools to help you think "contract first".  I hadn't really thought of XsdObjectGen.exe as a tool that helped you work in a contract first fashion, but Peter Bromberg seems to think so and so does David Truxall.

Unfortunately, XsdObjectGen.exe, as great as it was, is ill suited for .Net 2.0 and the introduction of generic types and lists.  I briefly contemplated using it for my .Net 2.0 project that I'm on now, but couldn't bring myself to it; there must be a better way, right?  Well, up until now, the only other .Net solution that I had come across was Matias Wozloski's GAT implementation (with slight modification?) of Daniel Cazzulino's (kzu) version of XsdObjectGen.  Having looked at that and the new xsd.exe that ships with VS2005, I have to say that I'm sorely disappointed in both since they rely on the XmlSchemaImporter and XmlCodeExporter classes to do their dirty work.  The resultant markup is not nearly as nice as the output from XsdObjectGen.exe.  As I've mentioned in the past (see the end of my workshop on XsdObjectGen.exe), while kzu's implementation is obviously much more flexibile since you can create new extensions and what not, it is ultimately somewhat clunky and not as easy to work with.

I briefly contemplated extracting the source from XsdObjectGen.exe and rewriting the codebase (it uses sort of an "intelligent templating" approach) to utilize some of the .Net 2.0 code features and generate better code, but after digging through it with Reflector, I realized I didn't have enough time (and I probably didn't have the rights) to extract and rewrite the codebase.

Enter dingo and thinktecture's WSCF.  While dingo is still strictly a .Net 1.1 tool, the project leader has a recent news item that claims forward development will continue this summer after some more work on a rules engine (anyone know of .Net APIs for working with RuleML?).  WSCF, on the other hand, looks like it's good to go with respect to .Net 2.0.

So have a look at WSCF.  I'll be downloading and evaluating it today and keep this updated with my take on it.

Update: See comments.

I thoroughly enjoyed this post

I installed an updated version of the NUnit VS add-in (aka: TestDriven.Net) today and discovered this little tool called NCoverExplorer.  Curious, I started to dig into it and that lead me to NCover.  NCoverExplorer is a GUI interface to NCover output files. 

What is NCover?  It generates code coverage information when it runs your NUnit tests so that you can see how much of your code base your tests are really touching (I perfer the output from Cenqua's Clover.Net, but I guess that's just a matter of using a better XSL transform?).

Both are great tools and should work their way into your development cycle!

It helps to have a simple batch file to run it:

"C:\Program Files\NCover\NCover.Console" "C:\Program Files\NUnit-Net-2.0 2.2.7\bin\nunit-console.exe" "..\bin\debug\SomeProject.Tests.dll"

PAUSE

In an automated environment, you'll want to take out the PAUSE.  It's only there so that if you're running it manually, you can watch the result of the run.

Man, this thing is dense.

I was able to get a very snazzy sample up and running with Castle.Windsor in under an hour, but it'll take quite a bit of time to get the same demo working with ObjectBuilder.  Admittedly, the PAG team states that it wasn't designed for prime time (yet), but what I would be interested in is seeing Microsoft integrate some open source projects into their own OSS projects.  Why reinvent the wheel? 

From my brief review of ObjectBuilder, it seems like it requires way too much work to use at this point.  It uses a mixture of configuration and compile time attributes to make the magic happen.  Why not have the option of doing it all in the configuration file?  It seems to require a lot of custom code to utilize ObjectBuilder whereas the Windsor container requires almost no custom code for wiring; it can be done in one line of code.

On a tangent, I found out that contrary to lack of activity on NDoc, a 2.0 version is in the works and has been mostly underground due to the fact that it's, from what I gather, a complete rewrite.  I tracked down a post by Kevin Downs, the project leader for NDoc over at Fabrice Marguerie's blog dated 2/23/2006:

Originally I had planned to do a simple upgrade of NDoc 1.3, but this proved almost impossible. NDoc2 is, to all intents and purposes, a complete rewrite (a huge undertaking) and has taken far longer than I originally anticipated due to illness. I was forced to 'go dark' on this development because I was getting some fairly offensive emails *demanding* a new release, and I could not give a firm time-line due to the above mentioned illness.

So if you're interested in being a tester, track down Kevin and get on the mailing list.

Every developer/graphic artist hybrid like me eventually comes across the need for some spiffy icons to go with our badass applications.

Good icons are hard to find.

Good free icons are harder still.

So it's a rare moment when I come across good, free icons.  So I must share

http://www.famfamfam.com/lab/icons/

Excellent icons.  Enjoy.

So I'm back from Utah.  Quite a trip.  I left New Jersey Monday morning at ~7:00AM EST and touched down in Utah ~11:00AM MT.  It only dawned on me when I got into the office there that it was quite a morning commute

Some of the highlights and commentary from the week that was (in random bulleted list format):

• Brad, our CEO, cooked for all of us one night at his house.  Made some very delish fresh baked bread, pasta, and jumbo tiger shrimp from Costco (I'm gonna have to go pick some up one of these days too).  I remarked to my wife that the square footage of his kitchen is larger than the footprint of our townhouse.
• I have a distaste for American cars.  Numb steering feel has to be my number one complaint.  The Cobalt just feels terrrrible with regards to steering feedback.
• Wow.  I was able to convince everyone on the team to use Subversion and Trac.  Amazing.  So I spent most of Thursday night setting up Subversion over Apache and also setting up Trac as well.  Took me roughly 6 hours ...and I'm still not 100% done.  But I'm excited.  I've just had terrible experiences with VSS.  It had gotten to the point where I was doing a daily .zip backup of my local files to an external HD since I didn't trust the VSS repository.  It's also great that it runs over HTTPS; much easier to bring new team members on board and we don't have to worry about licensing.
• We also decided to go with .Net 2.0 and VS2005 for all new development.  Woohoo!
• Brad is quite excited about Trac.  I'm slightly concerned that he's going to go crazy making tickets.

Now some not so random stuff.

It took me exactly 12 hours to get from Salt Lake back to New Jersey.  My return flight was supposed to stop over in Cincy, but because of thunder storms, we were diverted to Chicago.  Very scary stuff.  The pilot was trying to squeeze into a small window in the storms to see if we could get in there, but seconds later, came back on and let us know that we were running out of fuel.  We had to touch down in Chicago to pick up more fuel.  All was well, but I missed my connecting flight out of Cincy once I got into there.  So had to settle for a later flight

I don't think I've ever really been afraid of flying since I've been flying around since I was a toddler.  But for a brief moment, a deep sense of grief and fear overcame me as we were in the sky, being battered by the turbulence and hearing the pilot tell us that we were running out of fuel.

Aside from the return flight, it was a good trip.  I think we really had a better sense of team this time around and it'll be good to have Brad around now since it gives a better sense of purpose and clearer direction.

I also finished the NHibernate documentation on the return flight.  Very good stuff.  After reading it, all of the stuff that I was struggling with the first two times around made much more sense.  NHibernate is perhaps too flexible and powerful for its own good; it offers so many alternatives to get at the persisted objects, that it really takes a lot of practice and study to figure out the use cases for each of the different access methods.

The only part of the documentation that I was really disappointed with was the tools portion; it was pulled directly from the Hibernate documentation and still referenced Java command line instructions and what not, which is obviously disappointing since it raises the question of where else the documentation could be wrong with respects to differences in Hibernate and NHibernate implementation and syntax.

NHibernate, at this stage, does almost everything that DLINQ does (from the early documentation that I've covered) with respect to ORM with the obvious exception of language integration (they'd have to write a custom compiler or comipler extension to get that).

Sooo psyched about the New York International Auto Show this year.

Nissan will have a big show there with the unveiling of the new Altima, among other things.

To get ready for this event, I put together a gallery of the shots from last year's show.

Enjoy!

A journey of a thousand miles begins with a single step.

Man, I can remember just a few months ago when NHibernate had almost no documentation (and what little it had was terrible).

Now it's a 145-page beast.  Okay, not quite as dramatic as 1000 miles, but still, damn thing took me like 15 minutes to print all of it.  And no way in hell I'm getting a staple through all of the pages.  I kinda liked reading the DLINQ documentation, so I figured it's probably a good idea to reacquaint myself with NHibernate on a more intimate level.

I'm going to try and finish it on the plane trip in and out of Utah next week.  Yah, I'm bringing my camera this time; missed some beautiful scenary last time   I think this week, it'll really feel like I'm working at a new company.  It's been slow going as the company's CEO has been working onsite with a client and the engagement is just ending now.  This means that hopefully, the fun's only starting to begin.

It's 1:04 AM...what am I doing up reading about NHibernate?

Wow.  Just wow.

Bush Blames Iraq's Instability on Hussein

WASHINGTON (AP) -- President Bush said Wednesday that Saddam Hussein, not continued U.S. involvement in Iraq, is responsible for ongoing sectarian violence that is threatening the formation of a democratic government.

What?!?  Is he for real?

A little more than a year ago, I did my first sample project with NHibernate during some extended down time at Immedient.

At the time, the project was still in the .x releases (I believe I started with .8).  The one thing that really turned me off was the lack of good samples and starting points to learn from (although I did eventually dig up enough info to get my sample project up and running) and, in particular, the lack of strongly typed lists and collections. 

This is a legacy of the Java implementation of Hibernate, which was addressed some time last year with the release of .Net 2.0 and Generics, actually, but I never got a chance to look into it more as the end of the year was a busy quarter for me.

Over the last few days, I've been doing a little bit of studying regarding DLINQ for object persistence (incidentally, I also learned how to do duplex printing with my printer, which was far too confusing).  I recall being quite excited about ObjectSpaces when I was working at Factiva, but I was never able to get my hands on the preview bits.  From what I understand, it was actually very similar to NHibernate in that it required the use of intermediate XML mapping files (although DLINQ also needs those, but only for generating class files since it relies on the use of attributes).

DLINQ is the heir apparent to ObjectSpaces and is superior in every way...it's just that it's still in very early alpha stages and won't be ready for primetime until the release of C# 3.0.  While I love the technology, I'm just not ready to put time into something that's so open to change at the moment.

So, while I would love to implement DLINQ, it just seemed safer to take a second look at NHibernate, at least for the time being.  The last time that I took a look at it was probably around summer of last year, when I implemented a "toy" site for my sister using Cuyahoga CMS (which uses NHibernate).

With that in mind, I came across a very good CodeProject article on best practices for using NHibernate in a web environment.  As soon as I saw the bit about Generics, my interest was piqued again.  I downloaded the source and followed along and, to my surprise, it seems that my earlier frustration with good examples and usage has slowly been counterbalanced by increased usage of NHibernate.

As a bonus, I came across a great set of links and finally took some time to read about Martin Fowler's article on Inversion of Control.  This lead me to two frameworks for implementing IoC in .Net: Spring.Net and Castle/Windsor.  To be honest, I didn't quite "get" IoC and Castle the first time I looked at it (again, when I first started playing with NHibernate).  But I think I'm finally starting to understand it (I won't say I do fully until I use the framework and really "get" it).  I implemented something similar in a small project that I worked on last year at INS/Immedient (probably would have been much easier to use this instead).

The thing is, I've begun to become more and more obsessed with building loosely coupled systems.  So this is just the fix that my brain needed to start thinking about better designs.  Both Spring and Castle seek to address the same issue by utilizing IoC to remove dependencies (see here and here for a comparison of the two, although note that these were written over a year ago and were written by the project leader of Castle).

BONUS: I also came across a blog posting on how to simulate an HttpContext for testing written by the guy that's leading the Subtext project.  This is actually something I had been curious about (but too lazy to do anything about ) for quite a while.