Agilification

How to (really) turn off Just-In-Time Debugging (JIT)

agilification.nospam@nospam.sjvtech.com (jeffd) — Wed, 23 Sep 2009 03:28:00 -1400

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.

Agile Is Not A Process

agilification.nospam@nospam.sjvtech.com (jeffd) — Sat, 23 May 2009 07:07:00 -1400

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

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?

Preparing for an Agile Retrospective

agilification.nospam@nospam.sjvtech.com (jeffd) — Thu, 19 Mar 2009 17:02:00 -1400

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.

ASP.NET MVC Version 1 Has Shipped

agilification.nospam@nospam.sjvtech.com (jeffd) — Wed, 18 Mar 2009 07:12:00 -1400

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

Patterns & Practices - Part 2

agilification.nospam@nospam.sjvtech.com (jeffd) — Tue, 17 Mar 2009 15:37:00 -1400

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!

Visual Studio Project Sorting Fix

agilification.nospam@nospam.sjvtech.com (jeffd) — Wed, 04 Mar 2009 04:40:00 -1400

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/).

Patterns & Practices - Part 1

agilification.nospam@nospam.sjvtech.com (jeffd) — Sat, 03 Jan 2009 02:20:00 -1400

This is the first post in a series on Patterns and Practices. The series will explore the learning process of a developer who desires to learn and apply good patterns and practices.

Emilio and I had an interesting discussion a few days ago regarding Patterns & Practices. We observed that when a developer first adopts P&P, he behaves like it's all about the patterns. The developer begins to read books and blogs that describe the various patterns and how these can be useful. He begins to discover patterns in existing libraries and frameworks. He starts looking for opportunities to implement patterns in his own development. And he almost inevitably ends up suffering from some form of patternitis (often concentrated around an overuse of Singleton!).

I believe this phase of development is necessary for a developer. To comprehend patterns you have to actually try developing with them. You can learn a lot about patterns from a book, or by reading code from someone else's project. But ultimately the only way to truly understand patterns is to actually put them to use in a project of your own. In this regard, learning patterns is like learning to ice skate - you can watch others skate, you can read books on skating, but ultimately you're going to have to throw on some skates and hit the ice. And when you do, you're going to fall. When I learned to skate as a kid I remember that I was always afraid to fall. This fear prevented me from learning. But eventually someone told me that the only way to learn to skate was to push myself, and that meant I was going to fall sometimes.

So dig in, read about patterns, study them, learn to discover them in your code and in the code of others. And go ahead and try using some of them in your own projects. Yes, you will make mistakes, but this is a vital part of the learning process.

This post has focused on the initial process of learning patterns. In my next post on this topic, I will explore how the developer can begin to experience success applying patterns in his or her own projects.

Signature Converter

agilification.nospam@nospam.sjvtech.com (jeffd) — Tue, 23 Dec 2008 16:27:00 -1400

For a mobile application I'm working on, I needed a simple signature capture control. I found just such a control at the Code Project (http://www.codeproject.com/KB/mobile/SignatureCapture_PocketPC.aspx). The code will capture a signature and actually convert it into bitmap coordinates. This will allow me to store much less data rather than full images. But at some point I'm going to want to convert these bitmap coordinates back into an image. And unfortunately, the signature capture project only provides Java code for performing this process.

Well, if anyone else is interested, here is the Java code ported to C#. My next step will be to extend this class so that it isn't directly dependent on File System IO. But this should be enough to get anyone started who'd like to use the Signature Capture control from CodeProject, but wants to use .NET and C# to convert the bitmap coordinates back into an image.


using System;
using System.Collections;
using System.Collections.Generic;
using System.IO;
using System.Drawing;
using System.Drawing.Imaging;

namespace Agilification {
    public class SignatureConverter {

        const int baseX = 25;
        const int baseY = 25;
        
        public static void Convert(String inputTxtFile, String outputGraphicsFile) {
            List<String[]> v = readFile(inputTxtFile);
            Hashtable ht = getMinMax(v);
            int minX = (Int32)ht["minX"];
            int maxX = (Int32)ht["maxX"];
            int minY = (Int32)ht["minY"];
            int maxY = (Int32)ht["maxY"];
            int width = maxX - minX + baseX;
            int height = maxY - minY + baseY;
            Image image = new Bitmap(width, height);
            Graphics g2d = Graphics.FromImage(image);
            var b = new SolidBrush(Color.White);
            g2d.FillRectangle(b, 0, 0, width, height);
            drawImage(g2d, v, minX, minY);
            g2d.Dispose();
            image.Save(outputGraphicsFile, ImageFormat.Jpeg);
        }
        
        private static void drawImage(Graphics g2d, List<String[]> v, int minX, int minY) {
            for (int j = 0; j < v.Count; j++) {
                String[] points = (String[])v[j];
                int x1 = 0;
                int y1 = 0;
                int x2 = 0;
                int y2 = 0;
                for (int i = 0; i < 4; i++) {
                    x1 = Int32.Parse(points[0]) - minX + (baseX / 2);
                    x2 = Int32.Parse(points[2]) - minX + (baseX / 2);
                    y1 = Int32.Parse(points[1]) - minY + (baseY / 2);
                    y2 = Int32.Parse(points[3]) - minY + (baseY / 2);
                }
                var p = new Pen(Color.Black);
                g2d.DrawLine(p, x1, y1, x2, y2);
            }
        }
       
        private static Hashtable getMinMax(List<String[]> v) {
            Hashtable ht = new Hashtable();
            int minX = 9999;
            int maxX = 0;
            int minY = 9999;
            int maxY = 0;
            for (int j = 0; j < v.Count; j++) {
                String[] points = (String[])v[j];
                for (int i = 0; i < 4; i++) {
                    minX = (Int32.Parse(points[0]) < minX) ? Int32.Parse(points[0]) : minX;
                    minX = (Int32.Parse(points[2]) < minX) ? Int32.Parse(points[2]) : minX;
                    maxX = (Int32.Parse(points[0]) > maxX) ? Int32.Parse(points[0]) : maxX;
                    maxX = (Int32.Parse(points[2]) > maxX) ? Int32.Parse(points[2]) : maxX;
                    minY = (Int32.Parse(points[1]) < minY) ? Int32.Parse(points[1]) : minY;
                    minY = (Int32.Parse(points[3]) < minY) ? Int32.Parse(points[3]) : minY;
                    maxY = (Int32.Parse(points[1]) > maxY) ? Int32.Parse(points[1]) : maxY;
                    maxY = (Int32.Parse(points[3]) > maxY) ? Int32.Parse(points[3]) : maxY;
                }
            }
            ht.Add("minX", minX);
            ht.Add("maxX", maxX);
            ht.Add("minY", minY);
            ht.Add("maxY", maxY);
            return ht;
        }
        
        private static List<String[]> readFile(String fileName) {
            List<String[]> v = new List<String[]>();
            var reader = new StreamReader(fileName);
            String record = null;
            while ((record = reader.ReadLine()).Trim().Length > 0) {
                String[] points = new String[4];
                points = record.Split(' ');
                v.Add(points);
            }
            return v;
        }
        
        [MTAThread]
        static void Main(String[] args) {
            try {
                String inputTextFile = ".\\Sign.txt";
                String outputImageFile = ".\\Sign.jpg";
                Convert(inputTextFile, outputImageFile);
            } catch (Exception ex) {
                Console.WriteLine(" exception: " + ex.ToString());
            }
        }

    }
}

My Visual Studio Color Settings

agilification.nospam@nospam.sjvtech.com (emilioc) — Mon, 08 Dec 2008 02:59:00 -1400

I am really surprised that there isn't a community site for sharing Visual Studio settings. If there is one, let me know because I've looked and couldn't find anything. I thought it would be nice to share my font and color settings for the people interested. It's a version of Ragnarok Grey that I tweaked a little to fit my personal taste. I uploaded some screen shots below to give you a preview. The download only contains font and color settings so it will not change any of your other VS settings. You should still back up your current settings just to be on the safe side.

Dark-Colors.zip (1.97 kb)

You can find more color settings by Tomas Restrepo here including the original.

HTML

JavaScript

ToFormattedList Extension Method

agilification.nospam@nospam.sjvtech.com (emilioc) — Mon, 01 Dec 2008 14:54:00 -1400

Forgive me if this incorrect, but I believe the ToFormattedList() IEnumerable extension method was part of the early ASP.NET MVC previews. If you’ve used the method then you are aware of its usefulness. You pass in a format string (ex. “<li>{0}</li>”) and you get back a string of all the objects that were in your IEnumerable individually formatted ("very nice" -Borat). This is perfect if all the objects in your IEnumerable have an acceptable ToString() method. What if you are working with POCOs or business objects and you would like to use a property instead of an objects ToString() value? This is exactly the scenario that prompted me to create a ToFormattedList() extension method for IEnumerable<T>.

To satisfy this new requirement I needed to add a new parameter. My version of ToFormattedList() takes a Func<T, string> parameter to access the appropriate property (we need the func, we gotta have that func). Below is the simple code that makes this work and example of its use.

Code

public static string ToFormattedList<T>(this IEnumerable<T> list, string format, Func<T, string> func) { var s = ""; foreach (T item in list) { s += string.Format(format, func.Invoke(item)); } return s; }

Usage


    var output = companies.ToFormattedList("<li>{0}</li>", c => c.Name);

Lazy Init VS Constructor Init

agilification.nospam@nospam.sjvtech.com (emilioc) — Wed, 26 Nov 2008 10:18:00 -1400

One of my favorite things about programming is also one of the most frustrating things about programming. There's always more than one way to solve a problem. Software developers are faced with many choices. There is much to consider at every phase in the process. Efficiency, deadlines, performance, maintainability and scalability are all important topics to consider. So what criteria should you use to choose the correct convention or pattern? I'm here to let you know, there is no definitive answer (surprise). Also, this versus article is not meant to declare a victor. I wanted to use this example to illustrate my point on the choices developers have to make and the criteria that affect those choices.

Let's take on lazy init first. Below is a simple class with a Names property. Instead of initializing the list when the object is created, initialization is delayed until the property is needed. The if block is there to protect against the creation of a new list every time you retrieve the Names property. Performance is the most common argument I hear for using lazy init. Performance is a very good reason to use lazy init. As you can see, there is quite a bit going on for a simple object initialization. At minimum, you need a field and a property, not to mention the null object precaution. If you've been developing for a while, it is easy to get in the habit of starting with optimized code. Shouldn't the goal be to start simple and refactor as required? Is this common convention needless complexity?

public class SimpleClass { private IList<string> _names; public IList<string> Names { get { if (_names == null) { _names = new List<string>(); } return _names; } } public SimpleClass() { } }

And in this corner we have the challenger, constructor init. Using this approach, the Names property will be initialized when SimpleClass is initialized. One benefit of constructor init, as seen in the example below, is simplicity. There is no need for a field or an if statement. What about performance? Performance is a valid concern but it should be weighed against code efficiency. Simply put, a developer has a lot less code to write when using constructor init. The need to optimize for performance may never arise. In fact, if lazy init improves your code's performance, you might have a problem with SRP (zing).

public class SimpleClass { public IList<string> Names { get; private set; } public SimpleClass() { Names = new List<string>(); } }

It's probably obvious that I prefer simplicity over complexity. I acknowledge that complexity has its place in development and is appropriate at times. I believe the priorities and factors that lead to code complexity are an important and overlooked part of software development. If you're not sure why you need it, maybe you don't. The complex solution should answer the why.

Note: a similar comparison can be made for Service Locator and Constructor Injection but I will save that for another post.

Dependency Injection for the Compact Framework, Part 2

agilification.nospam@nospam.sjvtech.com (jeffd) — Fri, 21 Nov 2008 09:18:00 -1400

Last week I wrote about my need for Dependency Injection for the Compact Framework. Many DI frameworks do not support the Compact Framework, so I identified four options:

Don't use IoC and dependency injection
Continue to "roll-my-own" dependency injection tool
Pray that Jeremy Miller ports StructureMap to the Compact Framework
Use Ninject

Well, there is a fifth option that I hadn't considered: finding an open source project that does what I need. Germán Schuager pointed me to a project he created on Google Code called Compact Container. It is lightweight, clean and simple. After reviewing Germán's code, I found that it would support most of my needs, short of a couple of nice-to-have features.

Marking the injectable constructor with an attribute
Setting a default object life cycle for a container (rather than having to pass in the life cycle every time a type is registered with the container)
Ability to resolve concrete types that have not yet been registered with the container

In the spirit of open-source, I created the necessary code and sent it back to Germán for inclusion in the project. As of this posting, he's included the constructor attribution feature in the source repository, and hopefully he'll also add the other features as well.

My struggle with Ninject came down to the fact that it operates in a fashion quite distinct from other DI frameworks. I must admit that the Ninject DSL is quite appealing, but certain things that I'm comfortable doing with StructureMap are difficult if not impossible to attain using Ninject without creating a bunch of direct dependencies on the Ninject assemblies. So it looks like Compact Container is the winner at this point. We'll see if it sticks.

T4 Templates For The .NET Compact Framework

agilification.nospam@nospam.sjvtech.com (jeffd) — Fri, 14 Nov 2008 07:48:00 -1400

I first learned about the Text Template Transformation Toolkit (T4) about a month ago when reading some blog posts from Rob Conery and Scott Hanselman. T4 is a code generation tool that comes with Visual Studio 2008 (there's also an add-in for VS 2005). Rob likes T4 so much, that he's rewriting his SubSonic data access layer builder to use T4 template generation (check out his second preview of SubSonic 3.0).

As I wrote about a few days ago (Dependency Injection for the Compact Framework), I've recently returned to the world of building Smart Device applications using the .NET Compact Framework. I've been working on building the basic foundations of the domain model and I started running into some situations where code generation could make my team more productive. So, I tried adding a T4 template to my Compact Framework project (a file with a ".tt" file extension) and *boom*! Three errors crop up:

Compiling transformation: The type or namespace name 'CompilerError' does not exist in the namespace 'System.CodeDom.Compiler' (are you missing an assembly reference?)
Compiling transformation: The type 'System.CodeDom.Compiler.CompilerErrorCollection' is defined in an assembly that is not referenced. You must add a reference to assembly 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Compiling transformation: 'System.CodeDom.Compiler.CompilerErrorCollection' does not contain a definition for 'Add'

Why doesn't this work? Because Visual Studio is attempting to use the Compact Framework assemblies in order to process the T4 template file. But the Compact Framework assemblies don't include the System.CodeDom namespace.

I don't think Microsoft is ever going to add the CodeDom namespace to the Compact Framework. But there is a way to get T4 templates working in a Compact Framework project. You basically start off by creating two separate projects, one targeting the full .NET Framework, and another targeting the Compact Framework. Then, combine these projects into the same folder so they can share files between them. Finally, you can add .tt files to the full .NET Framework project and include the generated .cs files in your Compact Framework project. Voila! Templates for the Compact Framework.

I've created a quick-start document to walk you through the process: T4 Templates for the .NET Compact Framework

Happy code generating!

Strongly Typed Model Object Without Code-Behind (Sort of)

agilification.nospam@nospam.sjvtech.com (emilioc) — Thu, 13 Nov 2008 05:21:00 -1400

Are you using ASP.NET MVC? Do you want a strongly typed ViewData.Model object without a code-behind file? Tough, who said life was fair? I am just kidding ;p.

After reading Look Ma, No Code-Behind! by Chad Myers, I was inspired to share my approach. In my approach, I swap a code-behind file for an ordinary class file. I create a file per view folder named _ViewDataModelType.cs. The file name is optional and can be changed per view folder. I like to use the same name over and over because I am lazy.

Setup

In this file I declare all the ViewPage and ViewUserControl subclasses needed for this particular view folder. Use your namespaces wisely because if you're not careful you can run into naming collisions. Below is an example of what one these classes might look like.


namespace NoCodeBehind.Views.Employee {

    public class EmployeeIndex : ViewPage<IEnumerable<Employee>> {

    }



    public class EmployeeShow : ViewPage<EmployeeViewModel> {

    }



    public class EmployeePartial : ViewUserControl<EmployeePartialViewModel> {

    }

}

Usage

All you need now is to wire up your .aspx page. The Inherits attribute is the important piece. Below is an example.


<%@ Page Language="C#" AutoEventWireup="true" Inherits="NoCodeBehind.Views.Employee.EmployeeIndex" %>

After that, you are done. You now have a strongly typed model object at your finger tips.

Conclusion

Using a code-behind file for every view page is a non-option for me. This is a simple work around and helps keep my project slim around the waistline. I am definitely open to other solutions to this issue. I hope this helps if you are wrestling with the same issue.

jQuery and The Amazing Selectors Part 1

agilification.nospam@nospam.sjvtech.com (emilioc) — Wed, 12 Nov 2008 06:54:00 -1400

If you are looking around for a JavaScript library or looking to switch libraries, you should give jQuery a sample. If you have been doing web development for any period of time, then I am sure you've heard of it. From my experience, jQuery is an incredibly easy library to learn. I made the decision to learn jQuery several months ago and it has been a godsend. It has dramatically improved my relationship with JavaScript; a strained relationship, at best, no thanks to IE. But those days are history along with the days of getElementById. This brings me to the topic of this post. I wanted to take a little time to talk about jQuery selectors and showcase a few of my favs. When using jQuery, IDs are optional. You can select elements using class name, DOM position, attribute value and IDs (if you feel like being all precise and stuff).

Keep in my mind this is not an exhaustive list of every possible selector. It is, however, a list of my most used (read favorite) selectors.

1. var value = $('.fields:first input:hidden').val();

Selector number 1 will find the first instance of the fields class (.fields:first) and then select all hidden inputs (input:hidden) found within the containing tag. Since there is only one hidden input that matches the selection, only one will be returned. Making the retrieval of the hidden inputs value a snap.

2. $('.fields input, .fields select, .fields .someClass').click(function() { alert('hello') });

Numero dos on the list is the multi-selector. I am not sure if that is the official name but that's what I like to call it. Using this selector, you combine multiple selectors into one separating each selector with a comma. This will allow you to manipulate the matches of three selections as one. It can be very useful if you need to assign an event to multiple elements of different types.

<div class="fields"> <input type="text" id="textBox1" name="textBox1" /> <select> <option>opt 1</option> <option>opt 2</option> <option>opt 3</option> </select> <input type="text" id="textBox2" name="textBox2" class="someClass" /> </div>

3. $(this).nextAll('ul').toggle();

This selector is kind of a stretch. Inside an event you can pass in the this keyword as a selector and get instance access to the element that fired the event. If you need to find some related DOM elements you need a change in strategy. The this keyword can't be concatenated with string selectors. One possibility, is to grab the ID attribute of the element that fired the event ($(this).attr('id')). But what if your element doesn't have an ID? That's where jQuery's traversing methods make an entrance. The nextAll() method will get all sibling objects that appear after the currently selected object. You can optionally pass selectors in to the the nextAll() method ...

<div> <h3 class="toggleButton">Text</h3> <ul><li>text</li></ul> <ul><li>text</li></ul> <ul><li>text</li></ul> <ul><li>text</li></ul> </div>

$('.toggleButton').click(function(event) { $(this).nextAll('ul').toggle(); });

Conclusion

With three short examples I am only scratching the surface of jQuery's amazing selectors. I hope this post makes you hungry for more and at the very least, gets the uninterested interested in jQuery. I will be back with more soon!

Dependency Injection for the Compact Framework

agilification.nospam@nospam.sjvtech.com (jeffd) — Tue, 11 Nov 2008 17:03:00 -1400

I've spent the last 2 years developing WinForms and ASP.Net MVC applications, so it's been a while since I've worked on a .NET Compact Framework project. In case you haven't heard of it, the .NET Compact Framework is a compact sub-set of the .NET framework that can run on devices with limited resources (like phones, blackberries, barcode scanners, etc.). As I began working on the project, I decided up front that I would use the same SOLID principles I use on any other application. I almost hit a roadblock, however, when it came to choosing a Dependency Injection framework.

I began with just a simple roll-your-own dependency resolver. But this solution doesn't work well once you need to inject multiple layers of dependencies and build up your object hierarchies in a more complex fashion. So I did some research into which (if any) DI frameworks support the Compact Framework. It turns out that only one DI framework supports the Compact Framework: Ninject. Typically StructureMap has been my DI container of choice, and recently I've spent some time evaluating the Unity container from Microsoft, but neither of these support the Compact Framework. So I guess I've got a limited number of choices:

Don't use IoC and dependency injection
Continue to "roll-my-own" dependency injection tool
Pray that Jeremy Miller ports StructureMap to the Compact Framework
Use Ninject

Option 1 is not even a real option. There are too many benefits to be gained from loose coupling and depending on abstractions rather than details. Option 2 seemed feasible at first, until I needed more complicated object hierarchies. I can't hold my breath and wait on something that may never happen, so Option 3 isn't a real option either. So, it looks like I'm going to be heading to Ninja school! I'll let you know how it goes and what I discover along the way.

Stay Curious

agilification.nospam@nospam.sjvtech.com (jeffd) — Mon, 03 Nov 2008 02:05:00 -1400

Curiosity killed the cat - Eugene O'Neill

What is true for the cat is completely untrue for the agile team member. The best agile teams place a high value on learning. Curiosity is the catalyst for knowledge acquisition and creativity. It helps us remain dispassionate about personal preferences and can unlock our potential for divergent thinking. Often it seems that curiosity is reserved for R&D or design processes, but the best way to maximize its potential is to stay curious throughout the entire product development lifecycle.

Curiosity when planning. This is a vital element in a design process. We need to stay curious about potential features and requirements. We need to stay curious about resource allocation possibilities. We need to stay curious about platforms, tools and technologies.

Curiosity about processes. There is no perfect process, but there are processes that fit better for a particular context or situation. We should not simply assume that what worked before will work now. We should not simply assume that what is new is better. We should continually mold and shape our processes for maximum effectiveness.

Curiosity about personalities. Our curiosity can be applied beyond the particular task at hand by extending it to the consideration of organizational culture, people, relationships, interactions and influence. This can enable us to work better together and to maximize the potential of our teams. This can also help us diffuse conflict by minimizing presumptuousness and assumption, and instead choosing to remain curious about why other team members are acting in a particular way.

Curiosity when pondering. Retrospection is reflecting on what worked, what didn't work and what could work better in the future. Curiosity helps us to look deeply into our processes, our planning efforts, and our personalities to learn the lessons that will help us hone our skills and achieve better results as we move forward.

So if your goal is to effectively function as an agile team, reflect often, ask a lot of questions, and seek to learn from every possible facet of every possible situation. Place a high value on staying curious.

Are You Agile?

agilification.nospam@nospam.sjvtech.com (emilioc) — Mon, 27 Oct 2008 14:35:00 -1400

How do you know if you are an agile software developer? How do you know if your team is agile? It is easy to say you are. It is easy to intend to be. It is easy to lose agility if not continually maintained. On long projects focus shifts often. Success is a moving target. Agile practices have to be retuned and reapplied periodically. That’s how it was intended to work. That’s what makes it beautiful. It’s a solution to be implemented later.

The Agile Manifesto is a guideline for writing better software. You could say it is a loosely coupled collection of best practices. The Agile Manifesto does not contain a significant amount of detail and I believe that’s intentional. It’s composed of a dozen flexible recommendations. It’s not a script or a rigid doctrine of rules. There is room for interpretation. This freedom allows for easy adoption. It also allows for radical variations. Care should be taken not to let freedom become an evil mutation of agile practices. If in doubt or debate, remember, “Working software is the primary measure of progress.”

It’s easy for teams to allow existing bad habits to remain when moving towards a more agile environment. Understandably, old habits die hard. Agile teams should actively identify their bad habits and discuss ways to eliminate them. Allowing bad habits to evolve and masquerade as an agile practice is an evil mutation. To avoid this, a team should continually improve their process. Review the Twelve Principles of Agile Software as a team. Eliminate rigid and strict processes. Remove unnecessary steps in processes. Find new ways to improve efficiency. In short, tailor your process to best serve the team and your users. Determining how best to implement the Agile Manifesto is up to you.

The Agile Manifesto has a lot to offer software developers. Being agile in your profession is not limited to the software industry. Many teams can learn lessons from the guidelines put forth. Just as the software industry gained inspiration from a patterns book written on architecture. The Agile Manifesto makes good sense in the work place. So, if you strive to be agile, you should ask yourself often; self, are you agile?

Do the Quickest Thing That Works

agilification.nospam@nospam.sjvtech.com (jeffd) — Sun, 26 Oct 2008 15:42:00 -1400

The title of this entry is a standard mantra for agile programming efforts. And sometimes agile principles apply in other arenas besides software development. For example, my wife and I came up with a great idea for carving pumpkins this Halloween. In years past, I carved pumpkins like just about everyone else: with a large, foreboding knife that awakens fearful images of horrific scenes when wielded. Well no more, because sometimes the quickest thing that works is also the safest thing.

First, set the butcher's machete aside. Now trace a face on the pumpkin with a pencil. Next, grab a drill (cordless is handy, though any drill will do). Yes, I said a drill. Now make holes in the pumpkin using the drill, following the outline you drew with the pencil. The end result looks really cool and was much easier than using a knife.

So, I guess the lesson is that sometimes an unconventional approach pays off. If you try drilling your pumpkins this year, let me know how it goes.

Common Service Locator

agilification.nospam@nospam.sjvtech.com (jeffd) — Wed, 22 Oct 2008 15:26:00 -1400

Debates around inversion of control containers (IoC) have a tendency to turn for the worst very quickly. While there are common goals of loose coupling, improved testability and greater cohesion, often it seems that a lot of effort is spent debating about choices regarding which IoC container to use. The debates grow especially intense when a framework is created with a dependency on a particular container.

A couple of months ago, Jeremy Miller suggested the creation of a common library so that developers could allow consumers of their frameworks to plug in the IoC container of their choice (It's time for IoC Container Detente).

After a few short weeks, the Common Service Locator project was born. This project provides a simple adapter and static gateway for registering the IoC container of your choice into a framework that leverages the Common Service Locator. I created a StructureMap Adapter for this project that you can download on CodePlex. For simple, in-house applications over which you have complete control, there may not be a need for such an adaptation. But there are times when swapping out different container implementations is useful, so it's nice to know that it's there when you need it.