tsJensen

A quest for software excellence...

DomainAspects: Inject Fake PrincipalProvider and Avoid Fake HttpContext for Testing

Today I began playing with the DomainAspects project again and realized that my tests were breaking when I switched to the .NET 4.0 Framework. After a little research, it became clear. My test helper class in the previous version of DomainAspects committed a Class A coding misdemeanor. It relied on reflection to set the value of a private member on object returned by an internal method in the Thread class.

In my own defense, I did not write that code. I borrrowed it from somewhere online to allow me to set the HttpContext even when there really isn't one available when I run my tests. This was clearly bad form and came back to bite me. So I decided to eliminate the need and just added a facility in my DomainFactory class to substitute one or more of the Windsor components used by the DomainFactory.Create<T> method which is wrapped in an IDisposable via the DomainProxy<T> class being used in the tests.

Here is the simple addition to the DomainFactory. Note that we must remove these components in reverse order and then add them back since there are dependencies involved. Also note that this method will fail if you have already created an instance of a domain interface using the proxy or factory class.

/// <summary>
/// Replaces default aspect oriented operations components with client supplied components.
/// Used for testing or customizing operations withing the factory IoC container.
/// </summary>
/// <param name="principalProviderType"></param>
/// <param name="operationAuthorizerType"></param>
/// <param name="operationAuditorType"></param>
/// <param name="operationInterceptorType"></param>
/// <exception cref=""></exception>
public static void SubstituteComponents(
	Type principalProviderType = null, 
	Type operationAuthorizerType = null, 
	Type operationAuditorType = null)
{
	//set default types where param is null otherwise check for proper interface
	if (principalProviderType == null)
		principalProviderType = typeof(PrincipalProvider);
	else if (principalProviderType.GetInterface(typeof(IPrincipalProvider).FullName) == null)
		throw new ApplicationException("principalProviderType is not of type IPrincipalProvider.");
		
	if (operationAuthorizerType == null) 
		operationAuthorizerType = typeof(OperationAuthorizer);
	else if (operationAuthorizerType.GetInterface(typeof(IOperationAuthorizer).FullName) == null)
		throw new ApplicationException("operationAuthorizerType is not of type IOperationAuthorizer.");

	if (operationAuditorType == null) 
		operationAuditorType = typeof(OperationAuditor);
	else if (operationAuditorType.GetInterface(typeof(IOperationAuditor).FullName) == null)
		throw new ApplicationException("operationAuditorType is not of type IOperationAuditor.");


	if (container.Kernel.RemoveComponent("OperationInterceptor")
		&& container.Kernel.RemoveComponent("OperationAuditor")
		&& container.Kernel.RemoveComponent("OperationAuthorizer")
		&& container.Kernel.RemoveComponent("PrincipalProvider"))
	{
		container.Register(
			Component.For<IPrincipalProvider>()
				.ImplementedBy(principalProviderType)
				.Named("PrincipalProvider")
				.LifeStyle.Transient,

			Component.For<IOperationAuthorizer>()
			.ImplementedBy(operationAuthorizerType)
			.Named("OperationAuthorizer")
			.LifeStyle.Transient,

			Component.For<IOperationAuditor>()
			.ImplementedBy(operationAuditorType)
			.Named("OperationAuditor")
			.LifeStyle.Transient,

			Component.For<OperationInterceptor>()
			.Named("OperationInterceptor")
			.LifeStyle.Transient);
	}
	else
	{
		throw new ApplicationException("SubstituteComponents failed due to invoked component dependencies.");
	}
}

Once the new method was added to the DomainFactory class, I removed the TestHelper.cs file which included this very naughty code which fails in .NET 4.0 because the implementation of the Thread class changed and the GetIllogicalCallContext internal method went away.

//broken in .NET 4.0 - GetIllogicalCallContext does not exist in Thread class anymore
public static void SetCurrentContext(string fileName, string url, string queryString, FakePrincipal principal)
{
	var context = CreateHttpContext(fileName, url, queryString);
	context.User = principal;
	var result = RunInstanceMethod(Thread.CurrentThread, "GetIllogicalCallContext", new object[] { });
	SetPrivateInstanceFieldValue(result, "m_HostContext", context);
}

Now that the offending code is gone, the RegistrationServiceTests test class is broken as you see below:

[TestInitialize]
public void Initialize()
{
	//set up a fake http context with fake IPrincipal
	string[] roles =
		{
			 "Admin",
			 "User",
			 "Local Office"
		};
	TestHelper.SetCurrentContext(new FakePrincipal("Fake", "testuser", true, roles));
}

I replaced that code with this:

static bool isInitialized = false;

[TestInitialize]
public void Initialize()
{
	if (!isInitialized)
	{
		isInitialized = true;
		//only do this once per test/process run
		DomainFactory.SubstituteComponents(typeof(FakePrincipleProvider));
	}
}

And created the new FakePrincipleProvider class to create and deliver the IPrincipal as required by the IPrincipalProvider:

public class FakePrincipleProvider : IPrincipalProvider
{
	FakePrincipal principal;

	public IPrincipal GetPrincipal()
	{
		if (principal == null)
		{
			string[] roles =
			{
				 "Admin",
				 "User",
				 "Local Office"
			};
			principal = new FakePrincipal("Fake", "testuser", true, roles);
		}
		return principal;
	}
}

And now my tests pass again because my IoC container is passing along the FakePrincipleProvider to my OperationAuthorizer class.

There will be more to come with DomainAspects soon.

DomainAspects_v1_2.zip (2.97 MB)

ASP.NET MVC 4 Beta Released

I’m excited to watch the rollout of ASP.NET MVC 4 Beta and looking forward to finding the time and a good solid project to take advantage of the new mobile support and Azure SDK.

Here’s a basic list of what’s new.

  • ASP.NET Web API
  • ASP.NET Single Page Application
  • Enhancements to Default Project Templates
  • Mobile Project Template
  • Display Modes
  • jQuery Mobile, the View Switcher, and Browser Overriding
  • Recipes for Code Generation in Visual Studio
  • Task Support for Asynchronous Controllers
  • Azure SDK

I want to hear your ASP.NET MVC 4 stories. Let me know what you think about it. You may get a chance to deep dive before I do, given my current project priorities.

Situational Intelligence Leads to Certainty and Confidence

I like this quote from General Stanley McChrystal on crisis communication:

“I think when any leader faces crisis, this is true on the battlefield but I think it's also true in other areas as well, one of the things you fear most is not understanding the situation. And I think it's that uncertainty that actually is most unsettling to many leaders and causes them to be undermined in their confidence.”

Understanding the situation. If you lack context. If you lack critical knowledge. You cannot effectively lead. First, seek to understand. Listen and absorb. Contemplate. Then, and only then, act.

Goal Oriented Meetings in Software Development

I’m fascinated with the subject of meetings. It is a topic of discussion across the wide webbed world. There are nearly as many opinions on this subject as there are stars in the sky. So adding my own here cannot possibly disrupt our little corner of the multiverse, nor will it likely establish a new or even affect an existing trend. But before I bore you with my own opinion, let me share with you some links to some very cogent resources that have helped me, in addition to my own years of experience, to form my opinions here.

  • Firemen, donuts and meetings – Seth Godin: “Don’t bother to have a meeting if you’re not prepared to change or make a decision right now.”
  • Reduce Meeting Time by 30 Percent – Max Isaac: “Prior to the meeting, send an email with the proposed Purpose, Process and Preparation, and attach documents that should be reviewed.”
  • Meetings frustrate task-oriented employees – American Psychological Association: “…people high in accomplishment striving, who tend to be highly task and goal oriented, were most negatively affected by meetings...
    ...people who participate most in meetings, such as those who identify themselves as upper-level management, tend to view them most favorably...solely because they get to talk a lot, they inevitably miss other key pieces of meeting effectiveness, including their ability to successfully lead the meeting.”
  • Why Goal-Oriented Requirements Engineering – Yu & Mylopoulos: “The identification of goals naturally lead to the repeated asking of "why", "how" and "how else" questions... Stakeholders also become more aware of potential alternatives for meeting their substantive goals, and are therefore less likely to over-specify by prematurely committing to certain technological solutions.” (This paper is not about meetings but contributes to the opinions expressed below.)
  • Goal-Oriented Idea Generation – multiple authors, taken from summary of results: “The goals obtained from the ideas have high quality. During the activities for grouping ideas, it was frequently observed that the stakeholders could find their misunderstandings and tried to resolve them. As a result, the obtained goals were based on the consensus and the agreement of all of the stakeholders.” (Again, this is not about meetings but contributes to my ideas on the subject.)

It has been my experience that any form of software development, including my personal favorite: behavior driven design/development first introduced by Dan North, generally requires more than one person in the process. There is at least a user and a programmer, at least for any software that one might be paid to produce. And where there is more than one person in a process, there is the inevitability of a meeting.

The real question is what is the nature of the meeting. And by nature I mean how will it be planned and conducted, and what if any follow up will occur as a result of the meeting.

Bad Meetings: Vague, Purposeless, Meandering Time Wasters
The world of software developers could fill terabytes of hard disk space with examples of meetings that were a complete waste of time, ineffective, resulted in no change to the status quo nor the discovery of anything that was not already immediately discoverable in an issue or project tracking system.

Rather than go through any of these bad examples in detail, I will simply summarize that these meetings most typically include in the email invite only a vague subject line, a time and place, a dial-in number for remote attendees, and by virtue of the most commonly used tool to send the invite, a list of attendees, most often the entire team. Too many of these meetings and your organization has fallen hopelessly into the “Meaningless Meetings Machine.”

Goal Oriented Meetings: Purpose Driven, Limited, Action Packed
The very best meetings I have ever attended or conducted (yes, I’ve conducted my share of bad meetings too) have had the following qualities:

  • Goal oriented – the agenda focuses on stated goals. (See Mark Schiller’s cogent treatment in Fixing IT Productivity Destroyers.)
  • Limited scope – the time and agenda are limited to specific related goals.
  • Parking lot – good but unrelated ideas go into a “parking lot” to be discussed at another time and often in a different forum.
  • More listening (less talking) – participants listen carefully with their full attention and speak only when they have something relevant to contribute or need clarification in order to make a decision or understand an action item being assigned to them. And NEVER, NEVER, NEVER do participants rudely talk all at once.
  • Previous action items related to goals on the agenda are reviewed in summary fashion – discussion is limited to reporting outcomes and/or impediments that require attention by the group. This does NOT mean that the group attempts to resolve these impediments during the meeting. They are noted and may generate an action item for a participant, but under NO CIRCUMSTANCES will the meeting get side tracked to solve the problem in the moment.
  • Goals drive actions – starting with diverging opinions and working toward consensus in these steps:
    • affirming the goals are properly stated
    • identifying actions required to achieve the goals
    • identifying (or getting volunteers) to take those actions
  • Decisions are made – work toward a consensus but have a meeting leader who can make a final decision right there, right now, after having considered the input of meeting participants. Perfect consensus is not the goal. Decision and action from team input and reasonable discussion is sufficient. (And as Seth points out, don’t bother having a meeting unless you are prepared to change your mind. If you have already made your decision, just announce it, assign the tasks and follow through—don’t waste your team’s time with a meeting to maintain the illusion that you care about what others think—they know you don’t.)
  • Minutes, including action items and commitments, are recorded and published post haste. They are also maintained in a team public place such as a wiki or project portal for reference and follow up.

Goal Oriented Meetings Foster Better Software Development
I included some links already that talk about goal oriented requirements engineering and behavior driven development (BDD). In Dan North’s treatment of BDD, he presents two single sentence templates for defining each of the requirements of any software system. With my own explanations, they are:

To define a feature or user story:

As a [X], I want [Y], so that [Z].

Where [X] is the role of a user, [Y] is the feature, and [Z] is the benefit or value (the goals) of the feature.

And to define the acceptance criteria for that story:

Given [some initial context—the givens], when [an event occurs], then [ensure some outcomes].

The outcomes to be assured also define the goals of the user specifically within a certain behavioral or system state context.

When the goals of stakeholders are clearly understood and can be codified in a manner such as the BDD form, the development team can move forward more quickly and with greater confidence. And when meetings are equally focused on goals and achieving them, meetings will be an asset rather than a liability. And your team will have a much greater opportunity to succeed.

Enterprise Content Management for the Win in 2012

December was an interesting month with multiple pieces on the chess board moving all at once insuring an interesting and exciting new year for me. And that new year is upon us. I picked up my copy of CIO Insight magazine, the November/December 2011 issue, this morning and read with delight the article entitled Where the IT Dollars Are Headed in 2012.

One passage in the study mentioned in the article (included in the print version and linked to online) caught my eye:

“Elsewhere in enterprise applications, collaboration, and content and project management are rapidly gaining popularity, which makes sense given the new mobile opportunities for these categories. Collaboration and content management are seeing increases in 2012 over 2011 of roughly 10 percentage points in the number of organizations budgeting; and among those that already were spending in these areas, budget growths are averaging 14.6 percent and 7.3 percent, respectively—both significantly higher than 2011’s growth.”

I have a recently renewed and very keen interest in the potential growth of the enterprise content management market. And I will blog more about this in the coming weeks which are sure to open up new opportunities for personal and professional growth.

SQLite and Fluent NHibernate with “Code First” in C#: Rewriting the OpenCollective Wiki

Introduction
Seven years ago, I wrote a wiki for managing requirements for multiple software development projects. I used C# in a simplistic ASP.NET web forms application with SQL Server as my data store. I published it under the name OpenCollective on Code Project and since then it has been viewed on just over 196,000 occasions and downloaded a little more than 1,600 times.

I still get an occasional question about OpenCollective, so a month or two ago I decided to rewrite it in order to explore using SQLite and Fluent NHibernate in a “code first” approach set in an ASP.NET MVC 3 application written in C#. The original OpenCollective was in some ways an experiment with technologies and techniques I was interested in at that time, so a rewrite to learn and explore something new seemed like a good idea.

The plan is simple. As time allows, I’ll rewrite OpenCollective and blog about my progress whenever it seems I have something of value to share. With some of these posts, I’ll share the entire code base for download. Others may just illustrate something I’ve learned or something I want to preserve for my own future reference. I tackled the first chore over a month ago but work and other activities pushed this project aside for a while, so I’m just getting around to blogging about the code now. I suspect this will be a priority driven pattern for this project.

Code First with Fluent NHibernate and SQLite
The first thing I wanted to accomplish in the OpenCollective rewrite was a move to SQLite and Fluent NHibernate in a “code first” approach to replace the SQL Server schema and the old ADO.NET code in the original. Some quick searching led me to the Fluent NHibernate Getting Started page. (If you haven’t read it, do so now.) Combining that with what I have already learned in exploring SQLite in this blog, I soon had a code first database being generated.

I’ll attach the entire code in 7zip (saves me 25% in bandwidth over standard zip), so I’m not going to go through all of the code in text here, but I do want to share with you some of the key steps in the my code first with Fluent NHibernate and SQLite adventure.

First, create your POCO entity class:

public class Project
{
	public virtual long Id { get; private set; }
	public virtual string Name { get; set; }
	public virtual DateTime Updated { get; set; }

	public virtual Author Author { get; set; }
	public virtual IList<Topic> Topics { get; set; }
	public virtual IList<Attachment> Attachments { get; set; }

	public Project()
	{
		Topics = new List<Topic>();
		Attachments = new List<Attachment>();
	}

	public virtual void AddTopic(Topic topic)
	{
		topic.Project = this;
		Topics.Add(topic);
	}

	public virtual void AddAttachment(Attachment attachment)
	{
		attachment.Project = this;
		Attachments.Add(attachment);
	}
}

Second, create a Fluent NHibernate mapping class:

public class ProjectMap : ClassMap<Project>
{
	public ProjectMap()
	{
		Id(x => x.Id);
		Map(x => x.Name);
		Map(x => x.Updated);
		References(x => x.Author);

		HasMany(x => x.Attachments)
			.Cascade.All();

		HasMany(x => x.Topics)
			.Cascade.All();
	}
}

Third, create a factory class that will return the NHibernate ISessionFactory and generate the SQLite schema and database file:

internal class DataFactory
{
	string _dbFile = string.Empty;
	bool _overwriteExisting = false;

	public DataFactory(string dbFile, bool overwriteExisting)
	{
		_dbFile = dbFile;
		_overwriteExisting = overwriteExisting;
	}

	public ISessionFactory CreateSessionFactory()
	{
		return Fluently.Configure()
			.Database(
				SQLiteConfiguration.Standard
					.UsingFile(_dbFile)
			)
			.Mappings(m => m.FluentMappings.AddFromAssemblyOf<DataFactory>())
			.ExposeConfiguration(BuildSchema)
			.BuildSessionFactory();
	}

	private void BuildSchema(Configuration config)
	{
		if (_overwriteExisting)
		{
			if (File.Exists(_dbFile)) File.Delete(_dbFile);

			var se = new SchemaExport(config);
			se.Create(false, true);
		}
	}
}

Fourth, create a repository class that will let you create the database and perform CRUD operations using your entity classes:

public static class OcDataRepository
{
	public static void Create(string dbFile)
	{
		DataFactory df = new DataFactory(dbFile, true);
		using (var sf = df.CreateSessionFactory())
		{
			sf.Close();
		}
	}

	public static void AddProject(string dbFile, Project project)
	{
		DataFactory df = new DataFactory(dbFile, false);
		using (var sf = df.CreateSessionFactory())
		using (var session = sf.OpenSession())
		using (var trans = session.BeginTransaction())
		{
			session.SaveOrUpdate(project.Author);
			session.SaveOrUpdate(project);
			trans.Commit();
		}
	}
}

Finally, write a little test console app to see if it all works:

class Program
{
	static void Main(string[] args)
	{
		string dbFile = @"C:\temp\test4.db";
		OcDataRepository.Create(dbFile);

		Project project = new Project
		{
			Name = "My First Project",
			Updated = DateTime.Now,
			Author = new Author { Name = "John Smith", Username = "smithj", Email = "jsmith@gmial.com" }
		};
		OcDataRepository.AddProject(dbFile, project);

		Console.WriteLine("done");
		Console.ReadLine();
	}
}

Examine the SQLite db file with your favorite SQLite tool and see the SQL:

CREATE TABLE "Project" (
	Id  integer, 
	Name TEXT, 
	Updated DATETIME, 
	Author_id INTEGER, 
	primary key (Id)
)

If you don’t have 7-zip, download and install it first. Download the code: OcWiki.7z (696 KB)

Estimating Software Features and Fixed Feature Compensation from 8th Light

I just finishing reading a fascinating blog post by Paul Pagel of 8th Light called Fixed Feature. I recommend that you read the post and download and study the linked PDF entitled From Estimate to Commitment.

Companies willing to pay for software development on a time-and-materials basis are fewer and farther between. They don’t have the resources to monitor such work to assure themselves that the team is progressing as it should. Understandably, they cannot shoulder this risk. So they want their teams, internal and external, to give them a fixed bid for a project: fixed time, fixed cost, fixed features.

Pagel points out, “software is a craft with a close problem finding to problem solving loop.” In other words, we’re not always very good at anticipating problems in a development project until they are just about to happen. Sometimes we don’t even see them coming. We can minimize these events through continuous review and refinement of our processes and practices, study and evaluation of past performance versus estimates and the assumptions that went into those. Too often we do not take the time to do so, dooming ourselves to historical repetition.

Rather than attempting to created a fixed bid for an entire project, 8th Light, according to Pagel, estimates each feature using PERT and creates a price point for each feature. At the end of an iteration, they bill the client for features accepted by the client. This is an interesting approach to combining the desire for fixed bid pricing and Agile development.

Of course, this or any variation on fixed bid pricing requires that we improve our track record on creating estimates. If you visit our friends in Mountain View and search for estimating software development, you will find over four million results. There are tools and whitepapers and blog posts galore. But before you spend more money on tools or consultants, look to your own experience. Be willing to record what you’ve done, evaluate it honestly and boldly, and make adjustments based on what you have learned. Surely this will be less painful than blindly repeating the past.

Read Pagel’s work on this subject and let me know what you think.