Eveningcreek.Evolve()

Vijay, a co-worker, took this photo (with a camera phone) while demonstrating a feature in our product. While the content was simply for demonstration purposes I couldn’t help but laugh.

Anyone familiar with developing for this framework will undoubtedly know that there’s a LOT of missing functionality compared to its big brother. Our product cross-compiles to both .NET and .NET Compact Framework platforms so it’s even more obvious!

Momma always said, when developing with .NET Compact Framework its like working with a few short of a dozen.

A few nights ago I was catching up on some .NET Rocks! podcasts listening to Episode #458 – Scott Hanselman and Phil Haack at NDC! (6/25/2009). The show wasn’t about anything in particular but I busted up laughing while walking my dog and recommended it for easy listening.

On item in particular that got my attention was mention of Scott’s tool list:

Carl Franklin: We’re just talking about what’s new and cool because, Scott, you’re like the uber geek who’s always up.  Scott Hanselman, by the way, has a list of tools and toys that Bar None is the best I’ve ever seen on the internet. 

Scott Hanselman: If it’s been written, I’ve installed it.

(Nerd!)

Scott’s tool list was not updated at the time of the recording but today I got interested so I took a peak. To my create pleasure he has recently published his ‘09 list:

• Scott Hanselman’s 2009 Ultimate Developer and Power Users Tool List for Windows

Wow! As one of my peers said “It’s like Christmas!!” There’s a lot of tools. I’ve used or heard of maybe half. Many of those listed  would also be on my list such as SharedView, AutoHotKey, Live Writer, LINQPad, .NET Reflector, and others (DOSBox could come in handy for those old ASCII games). The Regular Expression and Things Windows Forgot sections looks very interesting. I would also add Expresso and FileZilla to the list. The top tools that I need now are Paint.NET and PureText.

Let’s get to work!

This made me laugh pretty hard. I found this quote in a Windows Mobile Developer Center forum post while researching a problem with a Compact Framework project. Completely reasonable yet completely, totally, unequivocally unhelpful.

To sum up: if you’re getting NotSupporrtedException <sic> that generally means whatever you’re trying to do it [is] not supported.

Ohhhh – thank you sir!

While my sister-in-law was visiting last weekend the topic of teams and their interactions came up. Every person that has ever worked with other people has undoubtedly been influenced by his or her interactions both directly and indirectly. I feel that this topic is such an importance I wanted to blog about my experiences.

I once had the experience of interviewing for a software engineering position where the project’s architect asked me:

Do you consider yourself:

a creator,

an executer,

or a refiner?

Hmmm. I’ve never been asked this before nor had I ever really thought much thought about it until then. I answered ‘all’ but I wasn’t sure. Looking back I realized I was answering what I can do instead of what I do best. In my entire professional career I have never been required to take nor give a personality test.

Anyways, all went well and I got the job. However after a short period of time it became evident that something on team of twelve was off: things didn’t coalesce. This brought me back to the creator/executer/refiner question I had when I interviewed for that position.

I did some research and asked around. The DISC assessment came up a lot but it wasn’t exactly what I was looking for. I then came across Insight Publishing’s Team Dimensions profile (NOTE: I bought mine through the onlinedisc.com reseller but there’s many others).

DISC is for who you ARE.  Team Dimensions is for what you DO.  Use both for team development.

The Team Dimensions Profile helps individuals learn to work from their strengths
by identifying their most natural team role, while giving them added appreciation for
the contributions of others. As a result, team innovation and productivity increase as
conflict and project-cycle time decrease.

Team Dimensions describes a person’s:

1. Personal Approach in thinking and behavior in the team process;
2. Primary Role in the "Z Process" for teams; and
3. Personal Profile Talents Pattern on the team.

Used in team development, team building, resolution of team problems, and building collaboration and cooperation on teams.

I read the literature, looked through the test cases and spent the reasonable $27 (I also bought the DISC profile to round out the assessment). After spending the 10-15 minutes doing the online test I was immediately sent the 21 page report. To be honest, the resulting role assessment was different than what I was expecting but after reading the explanations it wasn’t surprising. The most helpful portion for me was the interactions between the roles (including mine with others).

There are four main team roles:

1. Creator – generates new ideas and concepts.
2. Advancer – communicates new ideas and carries them forward.
3. Refiner – analyzes idea for flaws or revise projects systematically.
4. Executer – delivers concrete results and seek successful implementations.

An equal combination of all four roles is called the flexer. According to their 2006 research report each role is almost balanced, between 22 and 25%, with the remaining 5% being a flexer.

Each role is mapped on a talents model where vertical axis measures a person’s focus on possibilities or realities while the horizontal axis measures a person’s focus on analysis or interaction. The closer to the edge of the model the more prominent those qualities and the less of the opposing qualities you possess. I think it’s important to note that even though a person surely has the ability to perform in any role they have a sweet spot they perform most efficiently and with greatest amount of success.

Below is Insight Publishing’s example (it’s not mine) of an assessment and the qualities that each has.

The profile also defines the “Z process” – the flow of an idea being handed off to other team members. This is useful in understanding your role and responsibilities in the idea lifecycle.

Inscape also has a Team Group Facilitator product that will evaluate and summarize your entire team.

I used the report for personal self-awareness and help me understand the overall team and our friction points. I recommend that anyone interested, even if just for curiosity, spend the mere $27: http://www.onlinedisc.com/team.htm

After analyzing the primary domain information in the last post we started putting together a domain model with an added focus on normalization and aggregation:

Aggregation in this sense is applying the Aggregate pattern per Domain Driven Design by Eric Evans. This pattern states that aggregates are clusters composed of objects that are typically worked with as single units (loading, rules evaluation, etc.)

There have been additional refinements and additions to the domain model since last time:

1. Standard regions (states and provinces) in Canada and USA must be pre-defined, however other countries (e.g. Mexico) should still be selectable without a region. In this scenario the region will be filled in manually as part of the address block.
2. Multiple phone types (e.g. home, mobile, etc.) and address types (e.g. home, business, etc.) will be available but we must be able to easily add new types without changing the application. This means we will normalize the data and avoid compile-time enumerations. The same applies for item types and option types.
3. Orders must have at least one line item.
4. Orders will have a process state. The states are well defined and will not change once the application is deployed so they don’t have the same requirement are phone types.
5. There will be no support for password recovery – only password resets.

At this time we are not implementing any change tracking support as there is no requirement for it (although it will come up later).

Below is the model diagram so far (cheating by using Visual Studio’s class diagram in place of UML). So far we’ve exposed four aggregates:

1. Regions
2. Contacts
3. Orders
4. Orderable Items 

We will continue driving out the model for each of the aggregates. There will be additional entities to deal with things such as default settings but we will avoid those until needed.

We are not addressing implied validation unless required. For example we do not explicitly state that a date field must be a valid date.

Contacts & Regions

A customer is simply a generic contact that contains information typical of an address book entry. It may contain multiple phone numbers and address of a pre-defined type.

Employee will extend a contact since an employee could also be a customer. This allows reuse of the logic for managing employee contact information as customers. The employee will have a unique username and hash of his or her password.

PhoneNumber is a 10-digit NANPA (North American Numbering Plan Area) format or ‘+’ notation for international numbers. Reformatting of entered phone number is allowed. Up to one of each PhoneType where types are types Business, Home, Mobile, and Fax.

Address is mostly optional. The Street field will be multi-line capable to allow adding mail stops,  c/o, and arbitrary international shipping information as required.

Country, by default, will contain all the countries in the world adhering to the ISO 3166-1 alpha-2 country code standard. Abbreviation is two-letter country code (e.g. USA is US, Canada is CA, Mexico is MX, etc.).

Region, by default, will contain all the regions (provinces and states) in USA and Canada adhering to the ISO 3166-2 region code standard. Abbreviation is 2nd-part of region code consisting of two letters (e.g. CA is California in USA, AB is Alberta in Canada, etc.).

Orders & Orderable Items

Each Order is composed of orderable items (Items, ItemProperties, Options) and a variety of Contacts or specific Contact Addresses.

The lower portion of the order model diagram is complicated on how an Item is associated with types and properties. The following order snippet is used to explain the relationships between orders, items, and properties when the Imperial Marcesa Item is ordered.

An Order has OrderItem line items. Each OrderItem is composed of:

• A single Item (e.g. Imperial Marcesa and Adjustable Screen)
• A collection of OrderItemProperty’s.  An OrderItemProperty holds the ItemProperty value for each OrderItem (e.g. Width of 15’ for Imperial Marcesa)

Each Item is of a defined ItemType (Imperial Marcesa Item is a Window Awning ItemType and the Adjustable Screen Item is an Accessory ItemType). The ItemType is important as it defines which ItemProperty’s are available (Window Awning ItemType has Quantity, Width, Projection, Fabric, Control, Motor Type and Hood Cover ItemProperty’s while the Adjustable Screen ItemType only has the Quantity ItemProperty).

ItemProperty also defines an ItemType’s Optionality (required/optional/not available). Patio Awnings ItemType require the quantity, width, projection, fabric, and control side columns filled (Optionality = 1) while motor type and hood cover columns are optional (Optionality = 0..1).

To help further this concept the following relational diagram can be used since domain model data (but not the behavior) tends to closely map to a entity relationship diagram (ERD). It illustrates the relationships for an Order of an Imperial Marcesa Item that has a Width PropertyType of 15’.

In the next post we’re going to evaluate user experience (UX) requirements to help define some of the infrastructure.

In this post we analyze the two main forms that the Awning Factory uses to process and track their orders. We are looking to define what the pieces of information are and how they interrelate. As we start to understand this domain information we will explore where this information comes from and how it is processed.

Below is an example of a filled order form.

Order Form

As discussed in a previous post, the Awning Factory manually fills in and faxes supplier order forms then replicates some of the information in a Microsoft Access database form for tracking.

There are three sections to the order form: Details, Line Items, and Options.

A. Details

B. Line Items. One line per item ordered with a maximum of 10 lines/order. This limitation is based on the formatting of the order form.

• B1. Item. Awning type is an orderable item. Items are usually awnings listed in categories however it does not need to be an awning and could also be an accessory or a custom item (free form) for this specific order. Item examples:

• B2. Item Properties. For each item ordered, the item has a varying group of properties with specific rules that must be met depending on that item’s category. The table below outlines the item properties where
  • R = Required
  • O = Optional
  • ‘-‘ = Not applicable

C. Options. Order options are simple yes/no checkboxes however they may have specific rules depending on options of items ordered.

• C1: Option category. The option category (e.g. Motor, Crank, etc.)
• C2: Option values. The selected options for each option category.

When an item is order that is an awning it requires specific options (D1) to be completed. Similarly when a Motor Type option is selected for an item it too requires specific options (D2) to be completed.

However since multiple awnings can be ordered on the same form it becomes unclear which options are related to which item. In this scenario the Awning Factory uses the comments section to define awning options and does not check an awning options. For simplicity we will always use Multiple Awning Validation Rules.

Database

The Access database used to track the orders contains much of the what is on the order form with a few more fields.

Enhancements

Enhancements are fields that the user wants to track addition to what has been harvested from the order and access forms.

In the next post will begin distilling our domain model based on this analysis.

While designing we will be drawing on terminology and other elements from these sources

• Applying Domain-Driven Design and Patterns by Jimmy Nilsson
• Domain Driven Design (DDD) by Eric Evans
• Patterns of Enterprise Application Architecture (PoEAA) by Martin Fowler
• Head First Design Patterns by Elisabeth Freeman et. al.

and many others later once we start developing with the technologies. We will also be taking a healthy dose of inspiration from The Pragmatic Programmer. 

Acronyms

We try to keep acronyms to a minimum but these exist in the domain.

• TAF – The Awning Factory
• RTS – Radio Transceiver System
• PI – Plug In
• T1 – Transceiver, 1-up
• T4 – Transceiver, 4-up

Personas

Personas define our virtual entities to use when communicating scenarios.

• Company – The Awning Factory (TAF for short)
• Order System – Taffy
• Manager – Michael
• Employees
  • Dwight
  • Andy
• Customers
  • Bob
  • Perry

Next up we’re going to analyze the domain based on The Awning Factory’s order and access forms before distilling a draft domain model.

While flipping through Clean Code : A Handbook of Agile Software Craftsmanship I found cartoon below in the Introduction that made me laugh out loud (LOL for you texters).

 

Taffy is the code name for a custom web-based order entry system for an awning manufacturer simply called The Awning Factory. It was started as a learning project with the primary goal to fulfill functionality and quality requirements as though it were a paid contract.

While developing this product we will apply many different yet inter-related design methodologies including domain driven design (DDD), test driven design (TDD), and behavior driven design (BDD). It will be developed in C#/.NET and, although jumping ahead, we expect it to consist of a SQL Server database and a Silverlight rich client utilizing Windows Communication Foundation (WCF) and NHibernate OR/M. All along the way we will be striving to be pragmatic, and expanding our knowledge of .NET, patterns, and best practices.

Background

When selling awnings,  the Awning Factory must submit orders to its supplier using a predefined order form. The order form is manually filled then printed and faxed to the supplier.

To track orders, the Awning Factory currently uses a Microsoft Access database with a flat table (i.e. not normalized) and a primitive form. No queries are supported and reports are generated by manually exporting data to an Excel spreadsheet.

Problem

There’s the obvious disconnect between the form and the Access database and the lack of querying capability. Although the database is extensible and has worked for them in the past it has severe limitations. It’s manual, time consuming, and deeply prone to errors. As the company grows they want to fix these problems and enhance its functionality in the following ways [1]:

Usability:

• Remote accessibility. Sales members can access the system from local and  remote locations without changing the method of access. (i.e. no remoting software required)
• Concurrent users. Multiple sales members can use the system simultaneously without possibility of corruption.

Capabilities:

• Order form generation. The supplier order forms can be generated with order information in PDF format.
• Reporting:
  • Generate year-end reports
  • Geographical sales analysis including sales mappings
• Relational. Sales members can query items and drill into details.
• Change tracking. Item changes should not affect histories.
• User Maintainable. A manager can adjust the system for changes in products, line item properties (quantity, width, etc.). The manager can create and upload new order forms that support auto population.

Solution

We will continue to analyze this problem by applying Domain Driven Design (DDD) techniques in future articles.

Notes:

• [1] An item may be anything in the domain such as customers, orders, products, addresses, etc.

As mentioned in a previous post I’ve started a learning project called Taffy – a custom web-based order entry system. The posts for this project will be listed on the Taffy main project page.

Taffy is the code name for a custom web-based order entry system for an awning manufacturer called The Awning Factory (fy). It was started as a learning project with the primary goal to fulfill functionality and quality requirements as though it were a paid contract.

While developing this product we will apply many different yet inter-related design methodologies including domain driven design (DDD), test driven design (TDD), and behavior driven design (BDD). It will be developed in C#/.NET and, although jumping ahead, we expect it to consist of a SQL Server database and a Silverlight rich client utilizing Windows Communication Foundation (WCF) and NHibernate OR/M. All along the way we will be striving to be pragmatic, and expanding our knowledge of .NET, patterns, and best practices.