Espresso Fueled Agile Development : patterns & practices

If you missed the patterns & practices summit....

mpuleio — Thu, 04 Dec 2008 12:37:00 GMT

Ajoy has posted that three of the sessions have been made available online at pnp Summit videos online. Since one of the three sessions is one that Grigori and I did about the Acceptance Testing Guide, Driving Development with Acceptance Testing, I figured I'd share the information. The other two sessions are Ade talking about distributed agile development, and a discussion with Ajoy on the new SharePoint guidance from p&p that I have mentioned before (Guidance on SharePoint, Unit testing SharePoint). If you missed the Summit and want to attend next year in Redmond (or elsewhere), keep an eye on http://www.pnpsummit.com/, which will eventually be updated with information on the next conference.

Who is using WCSF?

mpuleio — Wed, 03 Dec 2008 21:48:51 GMT

Blaine and I would like to ask the community to let us know "who is using WCSF?" We know that WCSF has been fairly successful based on:

WCSF has been downloaded a few times (ok, it is really many thousands of times)
The discussion forums on CodePlex are fairly busy
Direct customer engagement with a number of companies

However, there are a lot of folks who are using WCSF that we do not know about. Since we get requests all the time about who is using WCSF, the size of projects, the size of dev teams, etc, we would love to collect some more data and statistics. So, if you have used or are using WCSF on a project, let us know via comments, email, or discussions on CodePlex. If you have stopped using it, please let us know why, so we can possibly address concerns.

To make things simple, I have created a thread on the WCSF CodePlex discussion forum so you can easily provide feedback: http://www.codeplex.com/websf/Thread/View.aspx?ThreadId=41405

Thanks.

Where is WCSF headed?

mpuleio — Wed, 03 Dec 2008 21:24:19 GMT

Blaine & I have been getting a lot of emails, messages, comments, etc about WCSF. There are a lot of people interested in a public statement from patterns & practices about the roadmap for WCSF and future support of WCSF, in addition to the "normal" feature requests.

Well, we have some good news: Blaine has publicly released the WCSF roadmap in his blog as Roadmap for WCSF.

Basically, right now, we are asking for feedback from the community. Let Blaine and/or I know what you want via our blogs, email, or the WCSF CodePlex site at www.codeplex.com/websf. You can also create work items/ issues on the WCSF CodePlex site and have people vote on them (http://www.codeplex.com/websf/WorkItem/List.aspx).

Thanks in advance for the feedback...

[Edit: I created a specific thread on the CodePlex discussions board to facilitate feedback: http://www.codeplex.com/websf/Thread/View.aspx?ThreadId=41403). Enjoy]

Back from vacation... and a lot has happened in the last week

mpuleio — Mon, 03 Nov 2008 22:48:30 GMT

I took a week off, which was good. I visited family and spent time relaxing and playing video games. (Fallout3 rocks so far!!). I got back this morning to hundreds of emails to go through. After reading almost all of it, there were a few things that happened recently I wanted to share... Here are the highlights:

Grigori and I have been working (with Gerard and Jon) on the Acceptance Testing Guide...and we released a beta. (Grigori talks about it here: News: Acceptance Test Engineering Guidance BETA1, and the guide is under Releases here: http://codeplex.com/TestingGuidance). We would appreciate feedback.

Unity 1.2 and Enterprise Library 4.1 were both released. Way to go Chris, Grigori, and the rest of the team. (Just Released: Microsoft Enterprise Library 4.1 and Unity 1.2 and And we're live! Entlib 4.1 and Unity 1.2 are released.) Unity had some very neat (and hard to implement) stuff added to it in this release. I know since I paired with Chris on a small part of re-work that allowed the Policy Injection Block functionality to be added. This is a good, solid release of both projects.

p&p opened up the patterns & practices Agile Development Showcase, starting with a paper Ade wrote on Distributed Agile Development at Microsoft patterns & practices. I reviewed the paper and bounced ideas around with Ade. The paper has a LOT of information and helpful hints. (Ade's blog post about it is here: patterns & practices Agile Showcase)

The Redmond patterns & practices Summit is this week (http://www.pnpsummit.com/). I've got to prep for a talk tomorrow after being out for a week (fun). Here are a few other random posts on the topic: patterns & practices Summit in Redmond, Crazy Times Ahead - PDC, P&P Summit, Tech Ed EMEA). The Summit is always fun, and I am looking forward to it.

After the Summit, I'll be ramping down on the Acceptance Testing project now that the Beta is out. I will continue to work on it, just not as my primary focus, as it gets cleaned up, reviewed, re-worked, edited, etc. I'll blog soon about my next challenge.

How to migrate from CAB/SCSF to Composite WPF

mpuleio — Tue, 14 Oct 2008 20:12:10 GMT

Blaine recently posted that there is a CAB to Prism Comparison Available on Codeplex. This links to Composite Application Guidance for CAB Developers, a download from the CompositeWPF community site.

While this document does not help you decide IF[*] you should switch from CAB/SCSF to CompositeWPF, it does help with HOW, the differences between the two coding models, where the WorkItem went, how to emulate the behavior of WorkItems, and a few other interesting things. If you are a CAB developer considering the transition to WPF, you should definitely read this.

[*] Deciding which to use should be fairly simple: If you already know CAB/SCSF and you need to work in Windows Forms, stick with CAB/SCSF. If you need to host some WPF widgets in a Windows Forms environment, use CAB/SCSF. If you need a full WPF stack, use the Composite WPF guidance. If you are not constrained by the technology choice, things get tricky and the decision should factor in a whole bunch of factors including (but not limited to) which framework you are more comfortable in, which your team is more comfortable with, and where you see future investments in technology going. For each team/group/organization/company this is a different decision with different factors to consider.

Finally, a common Service Locator

mpuleio — Mon, 13 Oct 2008 20:03:57 GMT

I know that this is old news by now, but Chris Tavares, Glenn Block, and a few others around here have been working with a number of folks from the wider .NET community to create a common wrapper for IoC containers. Chris & Glenn created a community site (http://www.codeplex.com/CommonServiceLocator) and shipped it about two weeks ago (http://www.codeplex.com/CommonServiceLocator/Release/ProjectReleases.aspx?ReleaseId=17694).

Here are a few more posts about it:

The interface itself is pretty darned simple, and creating a wrapper around any IoC implementation should be pretty darned simple.

Personally, I think this is great, as it will allow us developers at p&p a way to easily create guidance using DI/IoC without tying our users to a particular container implementation, which has been a long requested feature. I know Prism did a great job with this concept already, and created their own facade, but this is a further step in the right direction as the broader DI/IoC community seems to be behind it. When/If I get a chance to work on WCSF again, I'll definitely go about hiding the container behind this interface.

Acceptance Test Engineering guide Alpha Available

mpuleio — Wed, 27 Aug 2008 21:00:00 GMT

Last night I posted the Alpha version of Acceptance Test Engineering guide - How to Decide if Software is Ready for You or Your Customer to the Acceptance Test Engineering CodePlex community site. There are 300+ pages of content. It is still a bit rough, has some gaps in it, and needs some work, but there is a lot of good information too.

I would ask for some help from the public (developers, testers, PMs, and folks who act as customers or sponsor software projects): Read the Alpha (or just part of it) and reply to the Feedback Discussion with anything you think we got wrong, anything we got right, or anything we missed entirely. Thanks.

Unit testing SharePoint

mpuleio — Sat, 23 Aug 2008 00:38:00 GMT

Francis has an article on Unit Testing SharePoint 2007 Applications

He also did a brownbag talk on this yesterday, which was very interesting and brought up a few big challenges and ways to work around them.

Enjoy

Guidance on SharePoint

mpuleio — Thu, 14 Aug 2008 01:38:31 GMT

You all might be amazed by the number of emails, messages, and calls I get asking for any of the following:

Guidance on SharePoint
Requests to add SharePoint Guidance to WCSF
Requests to add "Office applications" support to SCSF

Well, I can finally help out folks looking for guidance on how to build SharePoint applications by saying "go check out the CodePlex project for patterns & practices SharePoint Guidance (http://www.codeplex.com/spg)." If you are hoping for SharePoint support in WCSF, you should probably check this out too.

Blaine and Francis are leading the effort on this project. I understand that they are tackling a few big challenges that customers have ranked as the most important including (this list is from the project's Vision Scope slide deck):

Unit testing and debugging
Packaging and deployment
Setting up a team development environment
Unclear which SharePoint features/ components to use and when
Solution maintenance/upgrade
How and when is SharePoint Designer applicable

If you do SharePoint development, you should check it out.

See Real Results With patterns & practices

mpuleio — Wed, 13 Aug 2008 01:38:43 GMT

I visited the p&p homepage on MSDN today, and saw an announcement for a research report by Nucleus Research about patterns & practices, and what companies that use our guidance think the benefits are. Check out See Real Results With patterns & practices (an overview) and download and read the full report. As a member of p&p I thought it was informative and showed a few areas that we can improve. It also showed areas where customers have reaped big benefits from using p&p deliverables, which I would be interested in if I were "out in the real world" and looking to re-use one of the p&p application blocks or an open source alternative. To borrow a few lines from the report:

"THE BOTTOM LINE
Companies use Microsoft patterns and practices to make their development environments more productive, consistent, and standardized. Whether used by an independent software vendor, consultancy, or enterprise, patterns and practices can accelerate project cycle times, reduce costs, and shift application development efforts away from code building and toward maximizing business benefits."

-- Guidebook: Microsoft patterns & practices, Nucleus Research Inc., April 2008,
http://www.microsoft.com/downloads/details.aspx?FamilyId=3696068D-BE4A-4731-AB15-492377AA4C6D&displaylang=en

Enjoy.

Acceptance Testing Guide Community Preview 2 Available!

mpuleio — Mon, 04 Aug 2008 20:16:38 GMT

As I have mentioned before in a few posts (Acceptance Test Engineering Guidance, Acceptance Testing Guidance Survey, and Acceptance Testing Guide Update), I am working with a team on guidance around acceptance testing. We still have a lot of work to do our the guide, but we have made available a second community preview to show you how things are shaping up and to give you a chance to provide feedback.

Check these out:

The Acceptance Test Engineering Guidance community site on CodePlex (so you can follow the project)
An announcement about the guide (which is being handed out at the Agile 2008 conference this week)
The second community preview of the guide (it is a bit rough, but you should be able to see where we are headed with it)
Provide Feedback on Community Preview Aug 4, 2008 (so we can make changes, add topics we missed, etc).

Composite Application Guidance for WPF Shipped!

mpuleio — Thu, 31 Jul 2008 20:26:13 GMT

A while back, I was Dev Lead on the Smart Client Software Factory (SCSF) when we added the ability to host WPF controls in a Composite Application Block (CAB) application. Since then, the thinking in the WPF space has changed a bit, and p&p decided that offering guidance on full WPF applications was a good idea. Blaine, Francis, Bob, and Glenn have worked with a great team to create guidance for building composite applications using WPF. This guidance was started from a clean slate, as there are enough differences between Windows Forms and WPF (as we learned doing SCSF) to cause challenges. The result is the Composite Application Guidance for WPF June 2008, which recently shipped (formerly code-named Prism). This guidance is simple, easy to consume, can be used piecemeal, and should not have the steep learning curve that CAB and SCSF have. You can learn more at the Prism CodePlex Community Site, or at any of the places below.

Check out Francis's post, SHIPPED!!! Composite Application Guidance for WPF June 2008, for details and where to get it.

Or take a look at Glenn's post on the subject: Composite Application Guidance is Live

And here are a few other posts about what they have been up to, by person in chronological order:

From Francis:

From Blaine:

From Glenn:

I know I am looking forward to using this guidance when I get a chance to work with WPF more seriously.

Enjoy.

Proof of Concept: a simple DI solution for ASP.NET WebForms

mpuleio — Thu, 17 Jul 2008 23:32:22 GMT

Chris Tavares and I were chatting yesterday morning about an idea Chris had: building a simple, reusable Http Module that gives folks DI scoped to the Application, Session, and Request. Yesterday afternoon, during the p&p Dev team's weekly "Code Kata" we threw together a spike/proof of concept in a couple of hours. "Code Kata" is a three hour block of time that the p&p Dev team uses for a number of things:

cross-project pollination of ideas, things that work, things that don't work across project teams
investigating new and emerging technologies that p&p may work with in the future
investigating new and emerging platforms to determine if p&p may want to provide guidance in the future
play with new shiny bits :-)

There are no unit tests, just simple acceptance tests written as a really simple web site. If the site works and shows the right text, the test passes. We started with a list of requirements (scaled to just the application level) on the whiteboard that looked sort of like this (which I am creating from memory):

Create a DI container for the application
Create a way to get to the container ( we choose an extension method on the Application class)
Allow a way to configure the container
Allow DI to work for pages
Allow DI to work for user controls
Allow DI to work for master pages
Allow DI to work for ASMX web services
Allow the above functionality in a simple and self contained way

So, we created a simple Web Site Application and a DLL to hold the custom HttpModule. We created a simple web page that needed a property injected into it. We then wrote the code to make my "test" page work properly. First we wrote an extension method for HttpApplication. After a short bit it changed to one for HttpApplicationState:

using System.Web;
using Microsoft.Practices.Unity;

namespace UnityForTheWebLib
{
    public static class HttpApplicationStateExtensions
    {
        private const string GlobalContainerKey = "Your global Unity container";

        public static IUnityContainer GetContainer(this HttpApplicationState application)
        {
            application.Lock();
            try
            {
                IUnityContainer container = application[GlobalContainerKey] as IUnityContainer;
                if(container == null)
                {
                    container = new UnityContainer();
                    application[GlobalContainerKey] = container;
                }
                return container;
            }
            finally
            {
                application.UnLock();
            }
        }
    }
}

Basically, we have lazy initialization of the container and a mechanism to stuff it into the application state. And then the initial HttpModule that only does injection on a Page:

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using Microsoft.Practices.Unity;

namespace UnityForTheWebLib
{
    public class UnityHttpModule : IHttpModule
    {
        #region IHttpModule Members

        ///<summary>
        ///Initializes a module and prepares it to handle requests.
        ///</summary>
        ///
        ///<param name="context">An <see cref="T:System.Web.HttpApplication"></see> that provides access to the methods, properties, and events common to all application objects within an ASP.NET application </param>
        public void Init(HttpApplication context)
        {
            context.PreRequestHandlerExecute += OnPreRequestHandlerExecute;
        }

        ///<summary>
        ///Disposes of the resources (other than memory) used by the module that implements <see cref="T:System.Web.IHttpModule"></see>.
        ///</summary>
        ///
        public void Dispose()
        {
        }

        #endregion

        private void OnPreRequestHandlerExecute(object sender, EventArgs e)
        {
            IHttpHandler handler = HttpContext.Current.Handler;
            HttpContext.Current.Application.GetContainer().BuildUp(handler.GetType(), handler);
        }
    }
}

This is a very simple module that calls BuildUp on the page.

At this point we added another test, and implemented it. After a few iterations of this we ended up with tests for injection into a User Control and a Master Page, an interface that needed to be configured on the container. The final implementation of the Http Module looks like this

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using Microsoft.Practices.Unity;

namespace UnityForTheWebLib
{
    public class UnityHttpModule : IHttpModule
    {
        #region IHttpModule Members

        ///<summary>
        ///Initializes a module and prepares it to handle requests.
        ///</summary>
        ///
        ///<param name="context">An <see cref="T:System.Web.HttpApplication"></see> that provides access to the methods, properties, and events common to all application objects within an ASP.NET application </param>
        public void Init(HttpApplication context)
        {
            context.PreRequestHandlerExecute += OnPreRequestHandlerExecute;
        }

        ///<summary>
        ///Disposes of the resources (other than memory) used by the module that implements <see cref="T:System.Web.IHttpModule"></see>.
        ///</summary>
        ///
        public void Dispose()
        {
        }

        #endregion

        private void OnPreRequestHandlerExecute(object sender, EventArgs e)
        {
            IHttpHandler handler = HttpContext.Current.Handler;
            HttpContext.Current.Application.GetContainer().BuildUp(handler.GetType(), handler);

            // User Controls are ready to be built up after the page initialization is complete
            Page page = HttpContext.Current.Handler as Page;
            if (page != null)
            {
                page.InitComplete += OnPageInitComplete;
            }
        }

        // Get the controls in the page's control tree excluding the page itself
        private IEnumerable<Control> GetControlTree(Control root)
        {
            foreach (Control child in root.Controls)
            {
                yield return child;
                foreach (Control c in GetControlTree(child))
                {
                    yield return c;
                }
            }
        }

        // Build up each control in the page's control tree
        private void OnPageInitComplete(object sender, EventArgs e)
        {
            Page page = (Page) sender;
            IUnityContainer container = HttpContext.Current.Application.GetContainer();
            foreach (Control c in GetControlTree(page))
            {
                container.BuildUp(c.GetType(), c);
            }
        }
    }
}

Configuration of the container can happen in the Global Application_Start handler like this:

using System;
using Microsoft.Practices.Unity;

namespace UnityForTheWebTestSite
{
    public class Global : System.Web.HttpApplication
    {

        protected void Application_Start(object sender, EventArgs e)
        {
            IUnityContainer c = Application.GetContainer();
            c.RegisterType<IControlData, ControlData1>();
        }
    }
}

So, from the initial requirements we have this:

~~Create a DI container for the application~~ Lazy initialization
~~Create a way to get to the container ( we choose an extension method on the Application class)~~ Extension Method
~~Allow a way to configure the container~~ Application Start
~~Allow DI to work for pages~~ Add the HttpModule and Attributes
~~Allow DI to work for user controls~~ Add the HttpModule and Attributes
~~Allow DI to work for master pages~~ Add the HttpModule and Attributes
Allow DI to work for ASMX web services
~~Allow the above functionality in a simple and self contained way~~ This is all in a single module

We met the last requirement (simple and self contained) since all we did to the web application was add a single line to the web config. That met the requirement.

The last area is one we met, but we are not happy with the solution. Basically, we need to do a bit more research and see if there is a way to get into the pipeline for an ASMX request early enough to do injection and not screw things up for the normal use case or the Ajax extensions. Until we get this figured out right, the solution is to have your Web Service constructor ask the container to do injection. This is an ugly hack and looks something like this:

using System.ComponentModel;
using System.Web;
using System.Web.Services;
using Microsoft.Practices.Unity;

namespace UnityForTheWebTestSite
{
    [WebService(Namespace = "http://tempuri.org/")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    [ToolboxItem(false)]
    // To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line. 
    // [System.Web.Script.Services.ScriptService]
    public class MyWebService : System.Web.Services.WebService
    {
        public MyWebService()
        {
            HttpContext.Current.Application.GetContainer().BuildUp(this);
        }

        [Dependency]
        public IControlData Data
        {
            get;
            set;
        }

        [WebMethod]
        public string HelloWorld()
        {
            return "Hello World " + Data.GetText();
        }
    }
}

To add the ability to have a container at the Session level and the request level should be as simple as following the pattern for the extension method and the http handler above. (I will leave it as an exercise for the reader.) You could use the same container for everything, or have the Session container a child of the application container, and the request container a child of the session container. When and if we do a real implementation (as opposed to a proof of concept) we will figure out the best approach for most cases. When and if this happens, I will update my CWAB with Unity solution and dramatically simplify it. :-)

Acceptance Testing Guide Update

mpuleio — Fri, 11 Jul 2008 03:27:48 GMT

The team has been writing, editing, re-writing, and working hard on putting together a guide on Acceptance Testing. We have made quite a bit of progress, decided on an organization scheme, the basic format of how we want to write each chapter, and have re-worked a lot of content to fit this model. We recently posted two things on the Acceptance Testing Guidance CodePlex site:

A survey on What is Hard To Test?
A preview release of a few chapters/snippets/etc.

So, please answer our survey. It only has ONE question.

Also, send us feedback on the draft sections of the guide we posted by starting up some discussions in the Acceptance Testing Guide Discussions group.

Converting the Composite Web Application Block to Unity - Using the UnityCompositionContainer

mpuleio — Wed, 21 May 2008 19:38:11 GMT

This is the sixth post in a series. The other post include:

If you want background, go read the earlier posts.

Based upon feedback, I am making the source code available at CWAB and Unity.

For those who have been following along, you all know I am making this up as I go. So, I am asking that you be patient with me as we figure this out together. This article (in particular) may have a few false starts, and "ooops" moments. We are replacing something that was not meant to be pluggable, and all of the refactoring work that has been done up to this point may not be enough.

Reminder: This is a proof of concept. The version of CWAB I am creating here is not a supported product or guidance from patterns & practices. If you really want Unity support in WCSF, please go to the Issue Tracker on the WCSF Community Site and vote for the work item to get Unity support for WCSF.

At the end of the last post I planned on trying to actually use the UnityCompositionContainer, and then nuke the old CompositionContainer.

Let's get started by replacing any calls that creates a CompositionContainer with code that creates a UnityCompositionContainer. There is ONE spot, in WebClientApplication. Simple. Change, recompile, re-run unit tests, and we are green.

If it really was that simple, we should be able to remove the CompositionContainer class (and its test fixture) from the solution, and not have any challenges. Let's try that.

We fail to compile. Our TestableRootCompositionContainer is part of the problem. MockContainer in ManagedObjectCollectionFixture is the rest of it.

If we derive TestableRootCompositionContainer from UnityContainer, and remove everything from the class (as a temporary measure), we go from two to 27 build errors.

<timewarp duration="an or two"/>

Not good. But not too bad, considering what comes next. After fixing these build errors, I got on a roll, and did the following:

Removed references to the old ObjectBuilder.dll in both unit test and system projects
Removed the BuilderStrategies folder in both unit test and system projects
Removed the Collections folder in both unit test and system projects
Removed the ObjectBuilder folder in both unit test and system projects
Removed the ProviderDependencyAttribute and its fixture
Removed StateDependencyAttribute and its fixture
Removed OptionalDependencyAttribute and its fixture
Removed ServiceDependencyAttribute and its fixture
Removed all references to the old ObjectBuilder namespace
Replaced any [CreateNew] attributes with the Unity [Dependency] attribute
Hacked on WebClientApplication
Removed the Services collection. Replaced calls to container.Services.Add with container.RegisterType. If needed added a call to container.Resolve, when the Services.Add call was supposed to return an object.

Ok, things are compiling again. Finally. But there are a few failing unit tests, about 20 or so... Let's fix those.

<type... type.... swear.... type />

Getting those test to pass was fairly simple. All of them required a little bit of container setup that was different than before. This was not a big deal.

There is one major change I did make in the process, and a related renaming. First, the renaming, Page became InjectablePage; MasterPage became InjectableMasterPage, and guess what UserControl became? Excactly, InjectableUserControl. These are better descriptions and will remove the confusion I have dealt with on the forums where people use the wrong Page base class. The other change is that, previously CompositionContainer had two Builders: one for things like services that stayed around, and another for Pages and transient items like presenters. We no longer need two builders, and can get containers and lifetime managers to handle the differences. The approach I took for simplicity is to have each page create a container that is a child of the correct Module container, use this for doing injection on the page, and then nuking the container on Page.Dispose. This is quick and dirty, and it works, but I may revisit it later.

Now, since Unity 1.1 just shipped, it is time to upgrade. I replaced the binaries and...

Everything still passes.

I think that is enough for today.

As a quick check, I just looked at the solution statistics for the original version of CWAB and the current solution. CWAB went from 26KLOC (pre-article one) to 14KLOC, both numbers including unit tests. And I bet that there is more to be cut out and cleaned up. Having a purpose built, re-usable component for DI helped a lot here. For this edition, windiff will probably be the best bet for following all the types of changes I made. This one took a while and impacted a lot of code.

Next, I am going to review unit tests, run code coverage, determine if there are gaps in test coverage after all the hacking. After that, it will be porting one of the quickstarts over to the new version of CWAB. After that, the RI, at which point I will be sure that the updated version works well enough to be a good proof of concept.