Enterprise Architecture

CMAP Code Camp Wrap Up - Dependency Injection and IoC Containers

Matthew Podwysocki — Mon, 14 Apr 2008 03:45:14 GMT

I really enjoyed speaking at this past weekend's CMAP Code Camp. I hope you all enjoyed my presentation on "Loosen Your Dependencies with Dependency Injection and Inversion of Control Containers". It was a great discussion to have with everyone and I like to learn there as much as I teach.

I also enjoyed teaming up with Scott Allen on his "A Gentle Introduction to Mocking" where we talked about mocks versus stubs, test pattens and mock frameworks such as Rhino Mocks and Moq. Hopefully we'll be doing some more ping-pong sessions in the future.

Once again, I'd like to plug my DC ALT.NET group that I run. Our next meeting is scheduled for April 23rd and the topic will be Continuous Integration with Jay Flowers. We'll announce the location shortly for our group. You can go ahead and sign up for our mailing list here.

Anyhow, here are some resources that can help point you in the right direction. This includes articles, blogs and such that I find will be useful in your journey to better understand these things:

My presentation materials have just been uploaded to my SkyDrive. The PowerPoint presentation can be found here and the code samples can be found here.

If you note, I my code uses the following products in order to get it to run:

Feedback is always appreciated.

Unity Community Contributions and Interception

Matthew Podwysocki — Fri, 11 Apr 2008 23:35:05 GMT

Now that Unity has been released into the wild, there has definitely been a bit of interest swirling around it. One of my key wants for a good IoC container is basic interception capabilities. My criteria for evaluating a container usually comes down to the following:

Configurability (XML, DSL, Code)
Dependency Resolution, usually opinionated
Lifetime Management (Per Thread, Pooled, Singleton, Transient, etc)
Extensibility for Interception

So, I realized that Unity was missing some of these things in the first go around. Since Unity was built on top of ObjectBuilder2, a next generation version of the often maligned ObjectBuilder which also included some sample DI containers and a flexible interception model. Today's post will cover that and a bit more. I realize that I still am working on a post of AOP in the Enterprise and Spring.NET which is coming soon.

Where We Are

But, before we begin today, let's see what we've already covered in the past:

Unity 1.0 Released into the Wild
Unity 1.0 released and available on MSDN. Unfortunately, registration is required...
IoC and Unity - Configuration Changes for the Better
Covers the configuration changes to allow for better parameterization for constructors
IoC and Unity - The Basics and Interception
Talking about the basics of IoC containers and the interception models
IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block

Now that we've look at the history of this series, let's go ahead and get started.

Unity Contributions

Since Unity was released last Friday, there has been a community effort much like the ASP.NET MVC Contributions, MVCContrib, called Unity Community Contributions. This project is intended to fill in the gaps where the community feels that Unity can be extended, much like most other IoC containers. As I stated above, one of those crucial things that I thought was missing was taking the ObjectBuilder2 Interception model and applying it towards Unity. I wasn't interested as much in the Policy Injection Application Block, although nice, is a bit heavyweight for the basic operations I would like. Instead, the OB2 would suffice for most things that I'd want with a container. So, that led me to another topic...

ObjectBuilder2 Interception == Unity Interception?

Since I was particularly motivated to see the OB2 Interception model pushed into Unity, I decided to give it a go myself. For the most part, I was successful in a way, but I wasn't using the right extensibility model. From that point, I got in contact with Scott Densmore, a PM within the Patterns & Practices group and one of the authors of ObjectBuilder2 along with Brad Wilson. From that point, he was able to take the original OB2 Interception model and fit it nicely into the Unity extensibility model. The code is now available on the Unity Community Contributions and you can find those commits by Scott here.

So, let's take a look at what it entails. As I tell most people, you learn the most about the software with good unit, I mean behavioral tests where I can really grok the intent of the code much better than most documentation. I encourage most people to do the same. I'd rather stay away from those projects that don't have tests to back up their work.

Like I said before, ObjectBuilder2 had several ways of intercepting calls. There are several interception strategies worth mentioning:

Virtual Method interception
Interface Method interception
.NET Remoting interception (MarshalByRefObject)

From that, you have two ways of registering your interest for interception:

Intercept via code
Intercept via attributes

Now that we've laid down the basics, let's take a look at some of the unit tests. You'll notice that xUnit.net was used for the unit tests. Yes, I know, I've mentioned it a few times lately. Anyhow, let's look first at virtual method interception.

Before we get started on that, in order to perform interception, we need to implement the IInterceptionHandler interface. For the unit tests, this will be used to record the various actions that happened during the interception process. But you can imagine it to do any number of things such as logging, transaction management, security and so on. Any of those cross cutting concerns, really.

    public delegate IMethodReturn InovkeHandlerDelegate(IMethodInvocation call,

                                                        GetNextHandlerDelegate getNext);

    public delegate InovkeHandlerDelegate GetNextHandlerDelegate();

    public interface IInterceptionHandler

     {

        IMethodReturn Invoke(IMethodInvocation call,

                             GetNextHandlerDelegate getNext);

     }

 } 

   public class RecordingHandler : IInterceptionHandler

    {

        readonly string message;

        [InjectionConstructor]

        public RecordingHandler()

        {

            message = "";

        }

        public RecordingHandler(string message)

        {

            this.message = string.Format(" ({0})", message);

        }

        public IMethodReturn Invoke(IMethodInvocation call,

                                    GetNextHandlerDelegate getNext)

        {

            Recorder.Records.Add("Before Method" + message);

            IMethodReturn result = getNext().Invoke(call, getNext);

            Recorder.Records.Add("After Method" + message);

            return result;

        }

    }

We have the ability through the Invoke method to do things before the method as well as after. Should we need to modify values before the method is called, we can go ahead and do so. Now that we looked at that, let's get to some unit tests. First off, let's look at interception through just code. I like this approach as opposed to attributes due to not cluttering the domain model and making it more configurable at run time.

            [Fact]

            public void InterceptViaCode()

            {

                Recorder.Records.Clear();

                IUnityContainer container = new UnityContainer();

                container.AddNewExtension<InterceptionExtension>();

               container.Configure<IInterceptionConfiguration>().InterceptVirtual<SpyVirtual>
                   (typeof(SpyVirtual).GetMethod("InterceptedMethod"), new RecordingHandler());

                SpyVirtual obj = container.Resolve<SpyVirtual>();

                obj.InterceptedMethod();

                obj.NonInterceptedMethod();

                Assert.Equal(4, Recorder.Records.Count);

                Assert.Equal("Before Method", Recorder.Records[0]);

                Assert.Equal("In Method", Recorder.Records[1]);

                Assert.Equal("After Method", Recorder.Records[2]);

                Assert.Equal("In Non-Intercepted Method", Recorder.Records[3]);

            }

public classSpyVirtual

            {
public virtual void InterceptedMethod()

                {
Recorder.Records.Add("In Method");

                }

public void NonInterceptedMethod()

                {
Recorder.Records.Add("In Non-Intercepted Method");

                }

public virtual void ThrowsException()

                {
Recorder.Records.Add("In Method");
throw new Exception("This is my exception!");

                }

            }

As you see above, we can simply register our interest through the registration of the InterceptionExtension and then set up the configuration through the IInterceptionConfiguration. From that point, we then say which kind of interception we want whether it be virtual, remoting or interfaces. We specify the method we want to intercept by name.

You can also do the interception through the use of attributes. From this point, we need to decorate our methods with the attribute and the particular interception handler we want to use. We need to be aware of which interception strategy we're using as well when we decorate our classes. You can intercept methods as well as property accessors by decorating the get or set. Below is a simple example of a virtual interceptor registration.

             public class SpyVirtualAttributes

            {

                [VirtualIntercept(typeof(RecordingHandler))]

                public virtual void InterceptedMethod()

                {

                    Recorder.Records.Add("In Method");

                }

            }

I'm not going to post all of the tests, but I want to give you an idea of the power of this. It's still early in the process and there is some cleanup still going on. But, I encourage you to pick up the source, read it, grok it, give it a try and give feedback.

Conclusion

As you can see, the extensibility model of Unity works in that we can add interception to Unity. So, we can start thinking about moving our cross cutting concerns to these layers should we so choose if Unity is your container of choice. There are plenty of containers out there to choose from, so it's best to give them all a try and pick one based upon features, programming style, and heck, maybe even licensing. I'll be showing some of this stuff off tomorrow at the CMAP Code Camp, so if you'll be at my 1PM session, be prepared. Until next time...

RockNUG IoC Container Presentation Wrapup

Matthew Podwysocki — Thu, 10 Apr 2008 22:10:21 GMT

I want to thank the fine folks at the Rockville .NET Users Group (RockNUG) and Dean Fiala for giving me the opportunity to speak last night. It was a record crowd last night, so I'm glad that people were interested in Loose Coupling, Design Patterns, Test Driven Development, Behavior Driven Development and Inversion of Control containers. I hope everyone got some good information, and if not interested in using containers, design patterns and such, at least know they exist and have their use. Based on the feedback I've already received, it was warming and why I like presenting at user groups, so that both of us can learn.

Once again, I'd like to plug my DC ALT.NET group that I run. Our next meeting is scheduled for April 23rd and the topic will be Continuous Integration with Jay Flowers. We'll announce the location shortly for our group. You can go ahead and sign up for our mailing list here.

Anyhow, here are some resources that can help point you in the right direction. This includes articles, blogs and such that I find will be useful in your journey to better understand these things:

After my CMAP Code Camp session over the weekend, I will go ahead and post my slides and code samples for your enjoyment. So, if you're in the Columbia, MD area this weekend and haven't signed up, go ahead and do so. Hope to see a great crowd there!

Understanding AOP in .NET

Matthew Podwysocki — Fri, 28 Mar 2008 23:45:16 GMT

In my previous posts I have talked a bit about Inversion of Control (IoC) containers with respect to Interception and Aspect Oriented Programming (AOP). It's not only important to understand the uses and strategies for implementing your solutions using it, but also how interception and AOP works deep down in .NET. Instead of a long, drawn out post, I think I'll just include some articles and posts that do a very good job of explaining some of the ideas behind it.

Articles and Posts

I think it'd be good if we just start out with some basic MSDN articles and such regarding AOP and interception. Some of them may be older but the concepts will still apply to this day:

7 Approaches for AOP in .NET
Ayende covers a few ways of doing AOP in .NET using existing frameworks
Decouple Components by Injecting Custom Services into Your Object's Interception Chain
Juval Lowy, in the March 2003 MSDN magazine, writes about using contexts for an object's execution scope and intercepting calls to and from that object.
Aspect Oriented Programming (September 2005 Technical article)
Matthew Deiters describes aspect oriented programming and covers joinpoints, pointcuts, advice and mixins with regards to a simple example using VB.NET.
AOP: Apsect Oriented Programming Enables Better Code Encapsulation and Reuse
Dharma Shukla, Simon Fell and Chris Sells write in the March 2002 MSDN Magazine with regards to the history to COM and AOP and then relate how it works in .NET. Rather dated article but the foundations still apply.
AOP using System.Reflection.Emit
Roberto Loreto writes on CodeProject how to intercept method calls of an external type and generating method proxies by using Intermediate Language (IL) injection.

Just Read the Code

There are many AOP frameworks out there in the wild right now for .NET. To understand them pretty well, it's best if you just crack open the code and follow the unit tests. Most of these are no longer active. Let's cover some of the AOP frameworks out there:

PostSharp
NKalore (No longer active)
Gripper LOOM.NET
Rapier LOOM.NET
AOP.NET (No longer active)
Aspect# (No longer active)
AspectDNG

Many containers also implement AOP through the IoC container such as:

Conclusion

For those willing and able to go ahead and learn about AOP, it's actually quite interesting. it's also quite a challenge especially when dealing with IL emitting. Go ahead and look at the source code and samples and give some of it a try. Next time we pick up, I'll be talking about AOP in the Enterprise and Spring.NET. Until next time...

IoC and Unity - Configuration Changes for the Better

Matthew Podwysocki — Thu, 27 Mar 2008 23:52:01 GMT

In my previous post about Unity and IoC containers, I made note of some changes in the latest drop of the Unity Application Block. As Grigori Melnik, the PM of the Unity and Enterprise Library team noted, Unity should be released in its final form on April 7th, so stay tuned. In the mean time, the latest drop of Unity was on March 24th, so go ahead and it pick it up.

Configuration Changes

As I noted from above, the public APIs really haven't changed all that much. Instead, most of the efforts recently have been around performance improvements in the ObjectBuilder base and the configuration of the container itself. I must admit that previous efforts left me a little cold with having to decorate my classes with the DependencyAttribute. Well, you shouldn't have to do that anymore, now that the TypeInjectionElement has been added so that you can map your constructor arguments and so on. Let's walk through a simple example of doing so.

First, let's go through my basic anti-corruption container that I use for Unity and any other container that I use for registration and so on.

namespace UnitySamples
{
    public static class IoC
    {
        private static IDependencyResolver resolver;
 
        public static void Initialize(IDependencyResolver resolver)
        {
            IoC.resolver = resolver;
        }
 
        public static T Resolve<T>()
        {
            return resolver.Resolve<T>();
        }
 
        public static T Resolve<T>(string name)
        {
            return resolver.Resolve<T>(name);
        }
    }
}

Remember this is just a quick spike sample of my anti-corruption container which was taken from Ayende. And then in order to configure my UnityContainer through the implementation of my IDependencyResolver interface. Let's take a brief look at that:

namespace UnitySamples
{
    public interface IDependencyResolver
    {
        T Resolve<T>(string name);
 
        T Resolve<T>();
    }
}

And then the implementation of the interface for Unity would look like:

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    public class UnityDependencyResolver: IDependencyResolver
    {
        private IUnityContainer container;
 
        public UnityDependencyResolver()
        {
            container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.Configure(container);
        }
 
        public T Resolve<T>()
        {
            return container.Resolve<T>();
        }
 
        public T Resolve<T>(string name)
        {
            return container.Resolve<T>(name);
        }
    }
}

Now, if you look at the constructor for the UnityDependencyResolver above, I am using the default container in order to configure my container. But, I have the option of specifying a name for it as well or even just an index. I could just easily change that code to this and it would work if I name my container default. This is a little bit of a change from before when I had to use the GetConfigCommand() method in order to configure the container which was a bit too chatty for my tastes.

            container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers["default"].Configure(container);

So, the idea that I want to do is create an object graph so that I have classes with dependencies that have dependencies. Without doing AOP and some basic interception, we could take the approach of keeping around something like an IContext which would have our cross-cutting concerns in one location such as logging and whatnot in one area so your objects don't sit there with 16 constructor parameters, and instead has a context from which it can pull. This approach has worked for me in the past, so let's just go through that one right now.

First, let's look at the context that has those cross-cutting concerns and the actual implementation:

namespace UnitySamples
{
    public interface IContext
    {
        ILogger Logger { get; }
    }
}

And then the concrete implementation might look something like this:

namespace UnitySamples
{
    public class UnityContext : IContext
    {
        private readonly ILogger logger;
 
        public UnityContext(ILogger logger)
        {
            this.logger = logger;
        }
 
        public ILogger Logger
        {
            get { return logger; }
        }
    }
}

So, what I do here is inject my logger into my context, and probably anything else that might be cross-cutting as well. So, now in one of my classes, then I can accept the IContext in to do what I need it to do. That would look something like this.

namespace UnitySamples
{
    public class Customer
    {
        public string CustomerId { get; set; }
 
        public string FirstName { get; set; }
 
        public string MiddleName { get; set; }
 
        public string LastName { get; set; }
    }
 
    public class CustomerTasks
    {
        private readonly IContext context;
 
        public CustomerTasks(IContext context)
        {
            this.context = context;
        }
 
        public void SaveCustomer(Customer customer)
        {
            // Save customer
            context.Logger.LogEvent("Saving customer", LogLevel.Information);
        }
    }
}

I'm not doing anything special, instead, just showing how this pattern might apply. And then just tying it all together is my console application (sometimes my favorite UI for quick spikes).

namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IoC.Initialize(new UnityDependencyResolver());
            CustomerTasks tasks = IoC.Resolve<CustomerTasks>();
            tasks.SaveCustomer(new Customer{ CustomerId = "12345", FirstName = "Joe", LastName = "Smith", MiddleName = "Frank"});
        }
    }
}

But the more interesting part about this is the XML configuration. I know many people such as Ayende have declared war on XML configuration, but I think for this quick example it does quite well. If we start talking about complex object graphs, then I'd certainly agree and I'd rather do it programmatically. But, let's first look at how I'd wire up the whole thing in the app.config file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
    </configSections>
 
    <unity>
        <typeAliases>
            <typeAlias alias="string" type="System.String, mscorlib" />
            <typeAlias alias="ILogger" type="UnitySamples.ILogger, UnitySamples" />
            <typeAlias alias="ConsoleLogger" type="UnitySamples.ConsoleLogger, UnitySamples" />
            <typeAlias alias="DebugLogger" type="UnitySamples.DebugLogger, UnitySamples" />
            <typeAlias alias="IContext" type="UnitySamples.IContext, UnitySamples" />
            <typeAlias alias="UnityContext" type="UnitySamples.UnityContext, UnitySamples" />
            <typeAlias alias="CustomerTasks" type="UnitySamples.CustomerTasks, UnitySamples" />
        </typeAliases>
        <containers>
            <container>
                <types>
                    <type type="ILogger" mapTo="ConsoleLogger" name="defaultLogger"/>
                    <type type="ILogger" mapTo="DebugLogger" name="debugLogger"/>
                    <type type="IContext" mapTo="UnityContext">
                        <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">
                            <constructor>
                                <param name="logger" parameterType="ILogger">
                                    <dependency name="debugLogger"/>
                                </param>
                            </constructor>
                        </typeConfig>
                    </type>
                    <type type="CustomerTasks">
                        <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">
                            <constructor>
                                <param name="context" parameterType="IContext">
                                    <dependency/>
                                </param>
                            </constructor>
                        </typeConfig>
                    </type>
                </types>
            </container>
        </containers>
    </unity>
</configuration>

As you may notice from above, Unity gives us the ability to give type aliases so that we can reference the short names instead of the long ugly fully qualified type names by using the <typeAliases><typeAlias> nodes in the configuration. Much as before, we still register our types with a name, type and so on.

But, what's interesting is that we now have the ability to do type injection through a Unity extension called the TypeInjectionElement. This allows us to inject into the constructor and put in our parameters as need be. But we could also replace that with <method> or <property> in order to do method injection and property setter injection respectively.
Within the <param> element, we can specify our given injection element parameters. This allows us to specify the name of our given parameter, the type, but also for the dependency check, we can specify the name and type to alias the other <type> elements that we wish to get a reference of. We can also specify the values if we so desire of strings, integers and so on. Below is a simple example of using both dependency references and values.

<constructor>
    <param name="logger" parameterType="ILogger">
        <dependency name="debugLogger"/>
    </param>
    <param name="dbName" parameterType="string">
        <value value="AdventureWorks" />
    </param>
</constructor>

I find the best way to learn about these features usually isn't through documentation, although it's a nice thing to do, but instead the tests. I look for the functionality that I'm interested in and go deep. A project this size without good unit tests == FAIL in my opinion. Anyhow, this is better looking than it used to be and much more intuitive.

Interception Revisited

As Chris Tavares, the developer of Unity noted on my blog before was the fact that he could easily put in the interceptors from the ObjectBuilder2 since ObjectBuilder2 is modular and Unity is built upon it. It shouldn't have been news, because I've been working on that myself to get lightweight interception to work on it. Maybe when I get it fully implemented I'll share it. But in the mean time, it's just a spike.

Conclusion

I think this approach has helped in the XML configuration goo that had been a bit confusing. I didn't want to clutter my domain models and processing code with excess attributes stating intent, and would rather keep it clean. This makes a step in that direction. In the next installation of looking at IoC will revolve around Spring.NET and AOP in the Enterprise, so stay tuned... Until next time...

Starting Junior Programmers on the Right Agile Track Guidance

Matthew Podwysocki — Wed, 02 Jan 2008 00:53:05 GMT

Part of my job is not only to design and implement solutions for my customers, but also to make my customer's developers stronger as well. During these customer engagements, there are many times when junior developers are involved. My job is to help those on the team to be stronger and then in turn help become leaders.

Where to start?

Well, I could start with a stack of point technology books (ASP.NET, SharePoint, BizTalk, etc) that become obsolete right during their printing, so that's not where I start. You find that many times, the books were written during the beta phase of the product and sure enough, things change, rapidly... But, I will mention a few that earn my admiration that form a basis for a good development background.

So, first things first, surveys are always in order to find out the comfort level with such things as:

Agile Software Development
Scrum
Domain Driven Design
Test Driven Development
Object Oriented Design
Enterprise Design Patterns
Secure Development Lifecycle
Point Technologies (ASP.NET/BizTalk/SharePoint/WCF/WPF/etc)

So, as you can see, it's quite a list of things to cover. But, no matter, we can come up with a list of things to know and teach and how to do it.

Topics to Know

When it comes to making stronger Agile Object Oriented Designers/Programmers, it's important that they know a few topics inside and out. They can be found easily on the net and some books that I will feature later on. Some of these include:

Separation of Concerns
Breaking a program into distinct features that overlap in functionality as little as possible. A concern is any interest or focus in a program. Concerns are synonymous with features or behaviors.
Liskov Substitution Principle
Subtypes must be substitutable for their base types
Law of Demeter
A given object should assume as little as possible about the structure or properties of anything else, including its subcomponents.
Single Responsibility Principle
Every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.
Open/Close Principle
Software entities should be open for extension, but closed for modification. The entity can allows its behavior to be modified without modifying the source code.
Interface Segregation Principle
Modules that encapsulate high level policy should not depend upon modules that implement details. Rather, both kinds of modules should depend upon abstractions. Abstract classes should not depend upon concrete classes and concrete classes should depend upon abstract classes. Clients should not be forced to depend on methods that they do not use.
Dependency Inversion Principle
Virtual member functions of derived classes must expect no more than the corresponding member functions of the base class; and should promise no less. It also means that virtual member functions that are present in base classes must also be present in the derived classes; and they must do useful work.

Stocking the Library

Knowing these fundamentals go a long way to making a stronger object oriented programmer. Ok, so reading just an article or two doesn't always make things sink in. Some books may be in order to help as well: Let's walk through some fundamental books for solid developers. Note that these do not include any point technologies, and instead focuses on gaining strong fundamental skills. It's not enough to pick up an ASP.NET book, and boom, you're a solid developer. So, let's go through some of them:

But what about technical books diving into point technologies, well, there are some of them that come highly recommended:

C#/.NET Framework
- CLR via C#, Second Edition (Jeffrey Richter)
- Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Krzysztof Cwalina)

This by no means is an exhaustive list, but a way to get started. By no means should they read all these books at once and should be tailored for those who need work in those related areas. These books will get the junior developer starting to think abstractly in a more agile mindset. But, how do you reinforce these behaviors in the development environment. It's not enough to read a few articles, a few books and call it a day.

Going to the next level

In order for those developers to get to that next level, paired programming is the key. This can reinforce what they have learned in a nuturing environment and even those who are more senior programmers can still learn a thing or two. One great way to get this kick started is to do Test Driven Development between programmers. Have the first programmer write a unit test and have it fail. Hand the keyboard off to the next programmer and have them make the unit test succeed. Then work on refactoring and move onto the next. Simple things like these go a long way.

Mentoring is also important. Have a mentor assigned to check how the junior developer is doing with learning these new concepts. Follow-up from the mentors is important as you track their progress. Make time to answer questions and challenge them.

What about Agile?

Many organizations in the software development world don't work in an Agile mindset, so what are some of the ways to get there? An Agile Coach is a great way to start an organization on the right step. No, they aren't the Agile Police, nor should they be. The Agile Coach brings quite a few things to an organization. These can include:

Ramping an organization up on agile processes and ways of thinking
Experience with the Agile Process
An effective agent of change
Environment assessment
Being a certified Scrum Master

Holding brown bag sessions is quite important in reinforcing learned ideas and learning new things. Of course you must make it worth people's while to attend. These can also get the junior developers more excited and involved and people can take turns creating these sessions and presenting.

Conclusion

I hope this post gets you in the mindset of changing organizations for the better, getting junior developers to become stronger ones and creating a more dynamic atmosphere. This of course is only the beginning on a lifetime or learning and being challenged. Develop, mentor and inspire!

Enterprise Service Bus on the Microsoft Platform Presentation

Matthew Podwysocki — Mon, 03 Dec 2007 19:15:00 GMT

Join us for the latest Microsoft Integration and Connected Systems User Group (MICSUG) on December 17th at 7:00PM, where we will talk about the Enterprise Service Bus Guidance provided by Microsoft on CodePlex. Since Geoff Snowman will be out, I will be running the show that night, so I hope you come out and hope to have a great crowd. As someone who is currently using this technology on a project, it's always great to see new ideas and perspectives on the technology.

In case you don't know what ESB is, let's go over a few links:

Enterprise Service Bus on the Microsoft Platform

The Microsoft ESB Guidance uses Microsoft BizTalk Server 2006 R2 to support a loosely coupled messaging architecture. BizTalk Server includes a powerful publish/subscribe mechanism for messaging applications that works by creating and filling subscriptions, which provides a highly efficient and scalable platform for service-oriented architecture (SOA) applications. The Microsoft ESB Guidance extends the functionality of BizTalk Server to provide a range of new capabilities focused on building robust, connected, service-oriented applications that incorporate itinerary-based service invocation for lightweight service composition, dynamic resolution of endpoints and maps, Web service and WS-* integration, fault management and reporting, and integration with third-party SOA governance solutions.

Scott McHugh, Principal Architect, RDA Corporation
Isaac Ferreira, Senior Software Engineer, RDA Corporation
December 17th, 7:00 PM

Location:
Microsoft Reston office address:
12012 Sunset Hills Rd.
Reston, VA 20190
Phone: (703) 673-7600