I would love to come to your user group and present on any of the following subjects.  If you would like to have me present, please feel free to contact me using the contact option above.BizTalk Server 2004This overview of BizTalk Server 2004 will work with more real-world examples than the standard Microsoft overview.  During this presentation the demonstrations will include creating schemas, maps and orchestrations.  Schemas will include creating a flat file schema to produce a simple X12 EDI.  The specific example covered in the presentation takes the non-existent Claims Corrector Medical Claims Clearinghouse (CCMCC).Black Belt XMLThis presentation covers high level XML tips which can have an immediate impact on how the attendees use the System.Xml namespace.  Including performance, caching, and object use tips this presentation.  Also included in this class is a hands-on demonstration of code profiling using the open source tool NProf.Test Driven DevelopmentThis is an overview of the Test Driven Development methodology.  The presentation uses NUnit to show the basic concepts behind TDD and how it has grown out of the existing methodologies of software development.COM+ Development in .NETCOM+ provides access to many options not otherwise easily available within the .NET Framework, most importantly the ability to perform distributed transactions.  This presentation will cover the basics of COM+ for those not familiar with it, and then show how to create COM+ component from within the .NET Framework.Free Tools You Need To KnowThis presentation is a tour of some of the most powerful open source and otherwise free, tools which are available for the developer toolkit.  Common tools to be included are NUnit, NCover, NProf, FxCop, and NAnt.  There is also an optional add on to this presentation which quickly covers three commercial tools that all developers should be aware of that can be added if your group does not mind the discussion of commercial utilities.Code GenerationUsing CodeSmith, produced by CodeSmith Tools LLC, this presentation covers how code generation can significantly reduce the amount of repetitive work required from developers.  This presentation will show how to use Code Generation for creating a Data Access Layer set of components.  It will also cover how this same technology can be used to ease the pains of not only data access woes, but presentation layer and XML problems as well.

BizTalk and the Singleton Pattern

We've recently had a problem at my employer where we were performing a very large number of database retrievals in a class called from a BizTalk Orchestration.  The class was already performing checks to ensure it only went after a particular piece of data once, but performance was still lacking compared to the desired results.  What was needed was to look for "economy of scale" solutions to this problem, because we were likely to be calling this Orchestration on multiple threads at once almost all day.The solution?  A Singleton Pattern caching mechanism so that multiple threads would retrieve the rows in question only once and then store it in memory for a short period (the data was over a very non-dynamic nature).  The solution hinges on a very important thing for .NET developers to remember about BizTalk Server : BizTalk Server 2004 is itself a .NET application!  This means that the service which runs all of the Orchestrations creates a .NET AppDomain when it starts and a static structure (like a Singleton) will be reachable by any threads started within the AppDomain.  Once a single thread had caused the cache to contain a particular row of data, all other threads would be able to work from the copy in memory.  We saw radical increases in performance from this relatively simple change.Disclaimer : Be certain to thread-safe your Singleton, or you will throw your entire BizTalk Server into a race condition very quickly.

NProf saves the day...

Today did not start as a good day.  After considerable time in development (months), a major component of our project was put under load-test yesterday and left to run overnight.The "load" in this case was a trivial load, a fraction of our daily business at the current time.  That trivial amount of load took 11 hours to process, which I was informed at 8:30 AM this morning.  I was not a happy architect.  So with thousands of lines of code to consider, my first step was a manual quick-scan looking for blatant problems.  In retrospect, I shouldn't have done this.  It yielded some results, but missed the mark on the big issue (even if the DB access inside the component did have considerable problems).So I went off in search of a profiling tool, something that could help me isolate the problem.  Google resulted a top hit on NProf, a link from Larkware by Mike Gunderloy who I read religously where he had reviewed this tool.  I set it to work on a simple executable I wrote to create an isolated test of this component (yes, I had a Unit Test Library, no I didn't want to spend the time to figure out how to make it work with NUnit just then).  The offending method popped up in the results very nicely, and has been slated for immediate refactoring tommorow.Of particular note is that this profiler does not stop at calls to your code, but traces the entire framework during your application run.  As such I know not only which method of mine is offending, but which of the methods it calls offends the most, etc, etc, etc.As a side note, that code calls the String.get_Chars(int32) some 238 MILLION times in the course of it's 5 minute run.  And that only accounted for 2.54 percent of the total time.