I'm currently working on a search screen for a shipment tracking system.  At the bottom of this screen, there are 4 checkboxes that will determine whether or not we are supposed to display Imports, Exports, Air shipments, or Ocean shipments - in whatever combination the user wants:

Down in the depths of the search process, I am creating a "finder" object, as Ayende talked about quite a while back. In this object, I have to account for the checkbox values here - whether or not the user wants to display whatever types of shipment (import or export) and/or the method of shipment (air or ocean). What gets really interesting is that when a box is un-checked, I should not show that particular type or method.

A quick analysis of these 4 checkboxes will come up with the following variants that must be accounted for when building the query.

1. Show Imports Only
1. Ocean and Air
2. Ocean only
3. Air Only
2. Show Exports Only
1. Ocean and Air
2. Ocean only
3. Air only
3. Show Imports and Export
1. Ocean and Air
2. Ocean only
3. Air only
4. Show no imports or exports (returns no results)
5. Show no ocean or air (returns no results)

All totaled up, that's 11 different query variants that have to be accounted for.

The end result of my query build methods is the following:

private void AddShipmentMethodCriteria(DetachedCriteria criteria)

{

    ICriterion air = Restrictions.Eq("ShipmentMethod", "Air");

    ICriterion ocean = Restrictions.Eq("ShipmentMethod", "Ocean");

    if (searchCriteria.ViewAirShipments && searchCriteria.ViewOceanShipments)

        criteria.Add(Restrictions.Or(air, ocean));

    else

    {

        if (searchCriteria.ViewAirShipments)

            criteria.Add(air);

        else

            criteria.Add(Restrictions.Not(air));

        if (searchCriteria.ViewOceanShipments)

            criteria.Add(ocean);

        else

            criteria.Add(Restrictions.Not(ocean));

    }

}

private void AddShipmentTypeCriteria(DetachedCriteria criteria)

{

    ICriterion import = Restrictions.Eq("ShipmentType", "Import");

    ICriterion export = Restrictions.Eq("ShipmentType", "Export");

    if (searchCriteria.ViewImports && searchCriteria.ViewExports)

        criteria.Add(Restrictions.Or(import, export));

    else

    {

        if (searchCriteria.ViewImports)

            criteria.Add(import);

        else

            criteria.Add(Restrictions.Not(import));

        if (searchCriteria.ViewExports)

            criteria.Add(export);

        else

            criteria.Add(Restrictions.Not(export));

    }

}

By having the first If statement check for both 'Import' and 'Export' being requested, we can properly create our query to show both of them via the Restrictions.Or() criteria. Additionally, we have to account for either or both of them not being checked and explicitly call them out to say that we do not want to show whichever one is not selected. The same is true for the 'Air' and 'Ocean' shipment methods.

The end result is that the user can select or un-select whichever shipment methods and shipment types they want, resulting in the correct data being displayed.

...

On a side note, there's probably some abstraction that I could create where I pass in the ICriterions and the boolean flags to help reduce code redundancy but that's not the point of this post. I'm really trying to illustrate the complex logic used in creating the correct NHibernate ICriteria/DetachedCriteria, and the analysis that you need to undertake for what looks like the most simple of situations. After all, how hard could it be to create a query based on 4 check boxes? ... more difficult than you might imagine, at first. Take the time to analyze even simple scenarios like this.

Yesterday, I posted a quick thought on code generation, and one of the statements I made is worth re-stating to stand on it's own.

In Agile/Lean software development, a single User Story is one piece flow when implemented via TDD, in a Workcell

In Lean Manufacturing, one piece flow is the idea that you do not produce anything in batches, but that you produce one product from start to finish per a customer's order. In Lean / Agile software development, this is analogous to an iteration with user stories. An iteration backlog is a customer order - a set of behaviors or features that are requested to be delivered in the current iteration. A user story is the single piece that we want to flow from beginning to end - from the start of coding all the way to acceptance via user testing.

In manufacturing, a Workcell is used to facilitate one piece flow through the manufacturing process. In software development, a Workcell is also used to facilitate the one piece flow. The Workcell may be 1 person, pair programming or a three person team. In order for it to truly be one piece flow, though, strict standards such as TDD and automated acceptance tests must be followed.

I'm not going to detail the benefits of one piece flow, here (not yet, anyway... another post for another time). I highly recommend that you read The Toyota Way and Lean Thinking for a good understanding of this concept and the benefits it provides.

Until around a year ago, I was an advocate of code generation via CodeSmith. Having marginal "success" with it in the 4 years I advocated for it, I'm now of a different opinion.

Code generators, such as CodeSmith, are automated overproduction machines that require prior overproduction, in the form of schema, to be used

Micro code generators like as Resharper, are much closer to JIT machines when lined up in one-piece-flow processes, such as Test Driven Development

...

If you had told me, 2 years ago, that I would make these statements today, I probably would have laughed at you.

A coworker asked this question about our automated integration test suite, recently:

"with the RowTest feature of NUnit, does the test data being used need to be hard coded into my code or can it be a variable that gets defined based on some rule?"

Here is my response, outlining the need to know the state of the database (know every value of every field, in every table) before and after the test suite is run:

The short answer is that the tests will have data hard coded into them.

This may be a change from how you have looked at integration testing, previously – where the data is changed on each run, so as not to duplicate the data in the system. Rather than changing the data that is used during each test, we need to ensure that the data is exactly what we expect, before and after each test. If the data is not what we expect before the test is run, the test cannot produce the data that we expect to have after it is run. If the data is not what we expect after a test is run, the test fails.

At a very high level, automated tests against the database require three things:

1. A known, state of ALL data in the database
2. A known, suite of unit tests that manipulate said data in predictable ways
3. An expected, verifiable suite of data returned by the software and manipulated in the database

The data is not necessarily "perfect" in that it has no flaws in it – rather, every last character in every last field of every last table is known, and all of the ramifications of that data is known with the explicit purpose of that data being there to support the automated tests. The automated tests expect this "perfect" data to produce the desired results and verify that the system works as expected. Any data that is manipulated in the system is expected to be in a predictable state, so the tests can verify that the system manipulated the data correctly.

When it comes to implementation of this, there are some fairly strict requirements for it to work:

1. Before the first test is run from the test suite, the data must be exactly what the tests expect
2. After the tests have run, the data must be exactly what the tests expect
3. Repeat for each run of the test suite

What this really means is that we cannot add or modify data between two test runs, without changing the tests that work with the data. In order for the tests to run multiple times throughout the day and/or on-demand, we have to ensure that the data being manipulated is what we expect it to be. Therefore, the first step of any run of the test suite is to revert the database to the known state, through sql scripts or code that are automatically run before the tests are run.

Here's the format that my team is currently using for User Stories and Acceptance Criteria. These formats are primarily learned from Scott Bellware's training that we have had recently, but is also influenced by the actual project that we are currently working.

User Stories

As a [Role], I want to [Goal], so that [Motivation].

Role: Who is using the system

Goal: What you want to do with the system

Motivation: Why you want to use the system.

I typically see people asking questions about Motivation - why it's important, etc. It's important because it gives the implementer a frame of mind for the behaviour.

Example:

As a Nurse, I want to record patient pain levels, so that I can adjust their medication doses appropriately.

vs.

As a Nurse, I want to record patient pain levels, so that I can show the pain trends with certain types of medication over a period of time.

When I read these two stories, as a developer, I begin to see drastic requirements differences and expect certain Acceptance Criteria based on the requirements differences that I expect to see. If I'm only adjusting their medication level, I probably only want to see what their current pain level is and whether or not I can adjust the level within dosage limitations. If I'm monitoring trends over a long period of time, I will want to record more - dose for period of time, when adjusted and why for the pain level, what other medications were involved in that patient in the same time periods, etc. The motivation can cause a huge difference in how the story is implemented.

Acceptance Criteria

I've noticed that there are two types of Acceptance Criteria: Behavioral (functional) and technical (non-functional). As such, there may be two different formats for a story.

Functional Acceptance Criteria

When [verb], should [verb], should ...

Example:

When recording the patient pain level
  Should represent the level on a scale of 1 to 10 where 1 is no pain and 10 is extreme pain

Non-Functional Acceptance Criteria

Should [technical detail]

or

When [functional criteria], Should [technical detail]

Example:

The pain level recording screen must be usable via a touch screen tablet pc.

or

When recording patient levels on a tablet pc, the data should be cached locally and synchronized to the master database when the nurse docs the tablet pc.

I believe the functional acceptance criteria should be stated in technology and implementation agnostics terms - imagine for a moment that you are going to implement the requirements via building blocks, paper forms, or printed circuit logic. If you have to change the functional acceptance criteria based on the implementation technology, then the criteria is not formatted correctly in the first place.

Avoid joining functional and non-functional acceptance criteria into a single acceptance criteria. It is easy for a developer to lose sight of the behavioral goals when these are mixed, and may prevent a UI/UX specialist from creating the greatest workflow ever.

Thanks to everyone who put together and presented at Austin Code Camp '08, on Saturday. It was a ton of fun. I learned a lot (especially in Ben Scheirman's Resharper-Fu session), met a lot of great people (the 3 LostTechies that presented, plus many more - including some that traveled all the way from Arkansas!), and participated heavily in Chad's Fishbowl TDD/BDD Discussion session.

You can see what classes I attended, over at my Twitter account - in the few days I've been on Twitter, i've become an addict.

The gathering after was also great fun. I'd never been to NxNW before. Good food, good drinks (micro brew), excellent conversation. I met some more great people, including Gordon Montgomery - he's doing some really cool stuff with User Experience and did a session @ACC that I wasn't able to make it to.

But best of all, I got to see what Scott Bellware will look like in 20 years (sorry for the lousy picture quality - taken from my cell phone).

No, not the lady in the skirt... the guy with the hat and glasses.

...

Looking forward to Austin Code Camp '09!

I've been toying around with various ideas in code, and I've come to the conclusion that the following formula is true:

Lambda Expressions + Func<> and Action<> = Easy Command Patterns

As a very contrived, quick example:

public class DoStuff

{

    private Func<CommandResult> Step1 { get; set; }

    private Func<CommandResult> Step2 { get; set; }

    public DoStuff(Func<CommandResult> step1, Func<CommandResult> step2)

    {

        Step1 = step1;

        Step2 = step2;

    }

    public void DoTheStuffProcessing()

    {

        CommandResult result = step1();

        if (result.Succeeded)

        {

            step2();

        }

    }

}

It's ... so ... beautiful ...

I decided to jump on the bandwagon of Twitter, to see what it may be able to do for me and getting into the community a bit more. You can follow me, at

http://twitter.com/derickbailey

For my client, I've installed Twhirl, which uses Adobe AIR as it's platform.

http://twhirl.org/

It's a pretty nice client, so far. Easy to setup and use. Thought it's my first Twitter client, so I don't really have anything to compare it to, other than standard IM clients.

If you have a batch file that takes two parameters with quotes around them, and you concatenate them together, you get too many quotes.  For example, if you have “test.bat” file with this code in it:

Echo %1%2

And you run it like this:

Test.bat “C:\” “Program Files\”

You end up with this result

“C:\””Program Files\”

Which is not a valid folder. I’m trying to get this result:

“C:\Program Files\”

The problem is, I have to put quotes around both parameters on the command line, in case there are spaces in the folder names. The solution to this is to use a ~ character in the variable, like this:

Echo %~1%~2

Running that command in the test.bat file produces this result:

C:\Program Files\

More info and parsing capabilities can be found here:

DOS - String Manipulation

There are a few examples in The Toyota Way, of American manufacturing companies that were thought to be world class Lean Manufacturers. When representatives from Toyota began working with these companies, though, the result was quite a shake-up. The companies that were thought to be lean, were merely implementing some of the surface level processes of lean manufacturing. They had not realized that there was a root cause of the process that they were implementing.

The Principles, Not The Process

A coworker recently asked me to help out with a presentation on Model-View-Presenter. He had some specific questions about why we would want to use MVP vs. MVC vs. any other UI pattern. Many of the questions centered around various benefits that have been promoted by myself and others out in the developer world via blogs and articles - items such as testability, changeability, flexibility, and other "ilities". My answers to some of these questions surprised me.

Model-View-Presenter is often thought of as a journey and an end in itself. When I first started learning MVP just over a year ago, this is exactly how I saw it. I started with the intention of learning how to separate my core process from the form implementation, with the intention of being able to unit test the core process. I was working under the impression that I could find a way to implement MVP that would truly allow me to swap out my UI - to the point of changing the workflow within the UI. I had the goal in the mind, of being able to write one presenter and have it support WinForms, WebForms, Web Services, and any other client-facing API.

One year and several projects later, I have some good lessons learned. I have implemented various forms of MVP - automagic view injection, manual everything, and a lot of ideas in between. My understanding of MVP is fairly solid, and I am capable of implementing it in WinForms, WebForms, Web Services, and other client-facing API's.

What I have realized recently, is that MVP is not (or, should not be) a journey and a goal in itself. MVP, MVC, and other UI related patterns are actually an effect of other underlying principles. The underlying principles of object oriented development - such as Separation of Concerns, Single Responsibility Principle, Dependency Inversion and others - are the real cause of MVP, MVC, etc. Testability, flexibility, and the other "ilities" are merely side-effects of good design and implementation. And while Testability is a valid goal in itself, seeking it as the primary or only goal will only lead you part way down the path. You will end up like the American manufacturers that thought they were world class lean companies, only to find out that they had barely scratched the surface of lean process.

The Journey, Not The Goal

Despite the success of Toyota as the creators of lean manufacturing, they believe that they are continuously learning about lean, so they can continuously improve. Similarly, despite my many years of software development experience, I now believe that I know little about software development. I have a good knowledge of .NET and general knowledge of Object Oriented Development, but I don't know much about other paradigms like Functional Languages or Duck-Typed languages such as Ruby.

In my professional growth as a developer, I have set goals for myself at various times. Most of these goals were set with the belief that they would make me a great developer. However, I've found that every time I have reached a goal, there is an entirely new world of possibilities ahead and what I thought was a great developer was merely the beginning of a journey. I've discovered that the journey itself is often far more important than what I believed the goal to be.

I'm not advocating that you forget about setting goals and let your career happen as it will - that's a great way to become burned-out, outdated, and irrelevant. What I am advocating is that when we have a goal in mind, we set out with the understanding that the goal itself may only be a small leg on a long journey. In this case, the journey is the process of learning. The journey itself should be viewed as the long term strategy, to the point where you allow the individual goals to come and go as needed. You may not accomplish a specific set goal - but the experience gained while working toward that goal may open up opportunity for other goals to be reached easily.

Learn The Principles Via The Process

All this talk about knowing the underlying principles is great - but how can we understand the principles and philosophies without knowing the process? Unfortunately, I don't know if that's possible for most of us. I'm sure that somewhere out there, someone has read SRP, DI, SoC, and other principles, and as a result began writing code that was modeled in a manner similar to MVP (Martin Fowler, for example). For the majority of us, though, learning the principles is done by first learning the process - study the implementation of the effect to learn the cause.

Conclusions

The journey itself is how we build our experience and understanding. For most of us, that journey begins with a goal of learning a new process. Find a goal or two that you believe will help you be a better developer and learn the processes. Along the journey of reaching for this goal, always keep in mind that there is an underlying principle or philosophy that enables the process. By learning the principles and philosophies behind the process, the process itself becomes a trivial matter - an implementation of the principles and philosophies, and not a goal in itself.