Attention User Group Leaders, INETA Volunteers, and Speakers! INETA would like to invite you to join us for a Mini-Summit on Monday June 2nd, 2008 at the Orlando Convention Center. We're going to be holding a somewhat informal gathering from 3-7 PM to provide user group leaders and chance to network, meet the new board members, and spend some quality time talking with us about community....

Read full article

Recently, Zach Young, a colleague of mine, and I started working on a project with the goal to lean several new things.  I had the idea for the application, a simple web application that would displayed the post from registered RSS feeds sorted by publish date. 

Which sounds pretty simple, but it became more clear the more we talked about it that we need requirements.  It is the same problem that is apparent in any software project.  I am for this instance play the role of the customer, and I have a vision of a product I want someone to build for me. 

The Problem

The problem is getting this vision out of my head, where it is perfect of course and into a form that can be clearly communicated to the development team so that I can feel confident that what they deliver will be what I ask for.

I spent a few days diving into Use Cases and found that I didn't feel like I was getting anywhere.  I was typing a lot of information but still didn't feel like the developer would get what I am saying.  A quick phone call to another colleague, Raymond Lewallen and I was off checking out User Stories.  And guess what they are small, light, easy to write and easy to read.

So what is a User Story?

Well, according to wikipedia, A user story is a software system requirement formulated as one or two sentences in the everyday language of the user.  This was exactly what I wanted.  Since this is a side project and mainly to be used to learn I don't want to spend all of my time writing tomes of requirements documentation before I get to writing some code.

Dan North: What's in a story

I decided to create User Stories following what Dan North has introduced in his What's in a Story post.

The simple format of the BDD style user story is quick to write and ubiquitous is easy to achieve.  Let's take a look at the format.

Title (one line describing the story)

Narrative:
As a [role]
I want [feature]
So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title
Given [context]
    And [some more context]...
When [event]
Then [outcome]
    And [another outcome]...

Using this has allowed me to get the requirements documented quickly, in a form that both Zach and I can easily understand and we rarely have to go back over what is in the user story for a feature and could move on to learning how to write test to satisfy the user story.

If you are interested in checking out our project and looking at the User Stories we are developing you can find it at http://code.google.com/p/hermesreader.  This project is intended to be an educational and you are interested in helping out drop me a line.

I will continue to post regarding the progress and concepts are are applying to the project as we tackle them.  Hopefully this information will save you some time and help you get the code out the door.

This weekend I attended an awesome event in Dallas, TX, the Community Leader Summit.  Soon to become CommunityCamp.  Thanks Caleb for organizing this event.  There were user groups there represented by a huge cross section of the user community.  Everything from .NET to Podcasting, and Joomla. 

It was very interesting to see that even though our groups are focused on different technologies that we all struggle with the same things.  And it was great to see how other groups has solved them.

I am sure the next CommunityCamp will be even better as we dive deeper into how to solve these problems and get to making our groups thrive and grow.

I recently learned about a very cool option in Visual Studio, the ability to extract an Interface from an existing class.  This has made me much more comfortable in trying to adhere to a principle of not creating unnecessary code.  I often found myself thinking I should create an interface first before creating the concrete implementation even for objects that I didn't have any current plans for extending. 

This post will show you step by step how to extract an interface from an existing class, so keeping with open closed principle we can still extend the code base with our modifying the current object.

First lets consider the the Attendee class.

namespace Attendee
{
    public class Attendee
    {
        private int _age;
        public int Age
        {
            get { return _age; }
            set { _age = value; }
        }

        private string _firstname;
        public string FirstName
        {
            get { return _firstname; }
            set { _firstname = value; }
        }

        private string _lastName;
        public string LastName
        {
            get { return _lastName; }
            set { _lastName = value; }
        }

        public bool Save()
        {
            return true;
        }
    }
}

This is a very simple class implementation of an Attendee, a class I use in my Model-View-Controller presentation.  Note this is a very simple domain object with no logic.  To extract an interface place your cursor in the class name, Attendee in this case, select Extract Interface... on the Refactor menu.

This will launch the Extract Interface wizard.  We can now modify the name, file name and the members to include in the interface.

Clicking OK after making your selection will generate the interface below.

using System;
namespace Attendee
{
    interface IAttendee
    {
        int Age { get; set; }
        string FirstName { get; set; }
        string LastName { get; set; }
        bool Save();
    }
}

Now you are free to create a new implementation of the Attendee class with out having to change any of the code in the old Attendee class.  This has really reduced the fear of not creating an interface for everything first.  Of course I still do for most of my objects but if there is no reason to create it right now, this give me the confidence that I can defer creating the interface and extension point until it is necessary.