A friend asked me for help getting started with StructureMap. I thought it might help someone else, so here it is in all of its simplicity.  Please let me know if this helps you or if you have anything to add.

--------------------------------
using StructureMap;
using StructureMap.Configuration.DSL;

public class Bootstrapper
{
    public void Bootstrap()
    {
        ObjectFactory.Initialize(init =>
        {
            init.Scan(scan =>
                {
                    scan.AssembliesFromApplicationBaseDirectory();
                    scan.WithDefaultConventions();
                }
        }
    }
}

You can pass a predicate to "AssembliesFromApplicationBaseDirectory" to restrict it to only scan assemblies that match a rule you specify ( in case you want to only scan your assemblies, and not any referenced assemblies you may be working with - very handy).

You can also do things like "scan.AssemblyContainingType<MYTYPE>();" where MYTYPE is a type in an assembly in which you want to scan for services/dependencies.

The call to "WithDefaultConventions()" tells StructureMap to wire up interfaces like "IFooService" with concrete implementations like "FooService".

If you need to change things you can add initialization expressions in the init section:

init.For<IMyService>().Use<MyReplacementService>();

There's a lot more to it, but this is a good start.

 One of my friends just finished a new fund accounting application for nonprofits and churches - check it out at http://www.aplossoftware.com

We're using NHibernate these days and going REALLY fast, but could we go even faster if we kissed RDBMS goodbye?

http://blog.wekeroad.com/2009/12/31/hello-from-2020

I just uploaded a new project to codeplex this morning.  Check out the ExpressVal Rapid Validation Library for .NET (http://expressval.codeplex.com/).

ExpressVal

Rapid Validation for .NET

Benefits

• Be expressive with your validation rules using Expressions!
• Spend less time thinking about display messages and more time focused on the validation requirement itself!
• Simply implement and test your validation rules!
• Lightweight and nimble!
• Self-contained! (does not rely on any other external framework or project)

Features

• Create rules using lambda expression syntax
• Parses many types of expressions to create canned, English language messages
  • Examples:
  • x => x.Name != null - "Name cannot be null"
  • x => !string.IsNullOrEmpty(x.Name) - "Name cannot be null or blank"
  • x => x.HireDate >= new DateTime(2000,1,1) - "Hire Date must be greater than or equal to January 01, 2000"
  • and many more...
• Canned messages can be overridden with custom message text
• Fluent interface for building up validators
• Multiple options for loading validator rules
  • Discoverable based on assigning the Validator attribute to expressions defined in a field on your entities
  • Implementing IValidatorSource and passing your implementation to the ValidatorEngine

 

I'm working on developing a server process that needs to execute nightly.  While working out some kinks, the process occasionally throws an exception.  The server in question has Sql Server Management Studio installed on it, which uses Visual Studio as its application shell.  This means that the server tries to invoke Just-In-Time debugging whenever an unhandled exception is thrown.  This is a problem for a few reasons.

• No one is logged in to the server when the error occurs, so there is no one to actually debug the process
• The attempt to start up JIT prevents the actual exception message from being added to the event log
• The machine isn't (and shouldn't be) set up for debugging the application anyway (it's a DB server, for Pete's sake!)

This MSDN article says to simply start up Visual Studio, go to Tools --> Options --> Debugging --> Just-In-Time and then uncheck all the boxes.  This isn't quite enough.  To complete the process, I had to follow the steps in another article (Just-In-Time Debugging) and remove some registry keys.

Of course there should not be any unhandled exceptions in an application!  However, in the early stages of testing a new server process, it's nice to be able to get helpful error messages when you do experience an unhandled exception.

Lately I'm hearing a lot about agile "processes" and teams that claim to be adopting an agile "methodology".  This sort of language speaks as if certain structures and procedures can be adopted which will make a team agile. This thinking is misguided at best, damaging at worst. When Kent, Bob, Ward and the other 17 "Apostles of Agile" crafted the Agile Manifesto, they did not publish a list of procedures or processes.  Instead they provided a set of values and priorities.

Are you part of a team that is striving to be agile?  If so, ask yourself, what is the primary driving force behind your efforts?

• Structures
• Procedures
• Processes
• Methodologies

or

• Values
• Priorities
• Principles

Do we need structures and procedures?  Absolutely! They are the context in which we perform concrete actions in order to fulfill the values and priorities to which we are committed. However, it is the ability to adapt these structures and procedures that makes an Agile team. When methods and structures are rigid and unchanging, agility has ceased.

Agile is not a process, but it is about how we create, shape and adjust our processes. The real question to ponder is this: "Do current structures, procedures and metholodogies enable us to maximally operate according to our values, priorities and core principles?" This is the question of alignment (a concept I will explore further in future posts). If the answer is "no" then are you willing to do something about it?

One of the facets of the Agile methodology I appreciate is the emphasis on transparency.  Rather than ignoring the proverbial elephant-in-the-room, Agile helps us to quickly identify (and hopefully address!) the real issues that affect our teams.  This aids the continuous learning process as we must constantly face hard realities and find creative ways to address them.

A vital part of the Agile process is the retrospective.  In this process, the team members identify the events which have occurred during a previous time-period.  They then seek to discover patterns in these events.  Finally, the culmination comes as the team identifies ways they can continue doing what is working, improve on what is working, and avoid doing what has not been working.

It is important to enter the retrospective process with a dispassionate view as to the events which have occurred prior to the retrospective.  It is non-productive to place blame on individuals or circumstances.  Instead, we must work together to face reality in the form of hard facts. As we reflect on these factual events, we work collaboratively to identify possible solutions that enable the team to reach for ever more productive heights.

This isn't to say there is no room for feelings in a retrospective.  Certainly the team members may experience a range of emotions as they reflect on the events of the previous time-period.  But the idea is to avoid any form of us-them mentality, or to blame circumstances for the outcomes.

Retrospectives can be an exhilarating and enlightening experience.  They are a great tool for improving the continuous learning of your teams.

Version 1 of Microsoft's ASP.NET MVC framework has shipped.  Find out more about the framework or go download it.

In my previous post on Patterns & Practices, I discussed the fact that in order to learn P&P, you have to be willing to make mistakes.  In the early stages, it is beneficial to look for opportunities to apply patterns to your development so that you can begin to see how they take shape.  You may not understand their benefit in the early stages, but this is a vital step, akin to the experience of the "Karate Kid" as he was told to "wax on / wax off".  He spent weeks practicing the same moves over and over again, not really understanding the purpose of such repetitive tasks.  What he failed to realize was that he was developing muscle memory and creating well worn neural pathways that would prove vital in his development process.  This holds true for us as software developers as well. [For this early development stage, a key resource is a book such as Head First Design Patterns].

Eventually you gain some proficiency with the repetitive tasks.  You begin to realize that certain patterns work better than others in certain circumstances.  You might discover that some patterns can paint you into a difficult corner (Singleton is of course the prime example, though Static Gateway has its pitfalls as well). At this stage you are beginning to deconstruct the value and utility of particular patterns for certain situations and contexts.  You awaken to the realization that code can have a "smell" that communicates whether a design is fitting or not.  While you cannot necessarily name the "smell" it is clearly there.  [At this stage, you're ready to tackle Refactoring to Patterns].

Take time to identify patterns that fit well for addressing particular smells.  Look for examples in code written by others (you are taking time to read code written by others, right?).  And start looking for ways that improper use of patterns can introduce smells of their own.

In my next post in this series, I will switch gears and discuss the relationship between Patterns and Practices and why you ultimately want to emphasize the Practices over the Patterns.  Stay tuned!

When you first create a solution using Visual Studio 2008, your projects sort nicely in alphabetical order.  But then as your project grows, you begin using solution folders to organize your projects.  It is at this point that your projects no longer sort alphabetically within their solution folders. 

Of course I've heard of the trick where you just choose one of the projects in a folder, press "F2" (rename) and then leave the project name as it was previously.  But this is 1) a pain, and 2) only sorts projects in that one solution folder.

So I created a tool that will modify your Visual Studio solution file (.sln) and make the projects sort properly within the solution folders.  Check it out at CodePlex:  Visual Studio Solution Sorter (http://solutionsorter.codeplex.com/).