tobinharris.com

Ohlo looks like a cool site for seeing what technologies people are using in their projects.

I started listing my .NET and RoR stack here (I feel out of date already!).

Watch the "Grok open source" video on the home page, I was sold in minutes :)

Cool use of Google maps for selecting where you live or work during site registration.

Registration snippet from the Ohlo site

I was toying with using this approach for a venture I'm working on, but had never seen anyone use it. Will be interesting to see how easy doing things like store locators and location-based searches etc.

P.S - Ohlo looks cool!

Have you ever come across those tools that let you generate code from state machine diagrams or state tables? Just for fun, I thought I'd try turning that idea on it's head:

"Don't use a modeling tool or DSL to generate code. Instead, use a fluent interface to express state machines in your POCO entities. Then, automatically generate diagrams from the code, and use these to facilitate communication with project stakeholders. "

Note: I haven't posted the full code up here, just snippets*

1. Create State Machine framework with fluent interface

I started by writing a lightweight State Machine framework (<100 LOC). This is quite easy really. I gave it a fluent interface that allows state transitions to be expressed in readable code (see below).

2. Create POCO entity

Then created an example domain entity that used the framework. I gave it some states, set up tranistions between those states, and added a method to trigger a transition.

The event is the Raise() method, which attempts to make a transition. The transition succeeds if it is a legal path and no validation errors occur. ValidationDraftToRaised() is called automatically by the framework at runtime, during the transition. If there are validation errors, the transition fails.

3. Auto-Generate Statechart

I can generate a state chart for any entity in my system.

This chart was produced automatically from the code above. It is produced at runtime by using reflecting on the POCO to see what states and transitions we set up using the fluent interface.

The generator actually outputs in dot notation, and is great for representing state machines. Below is an example of use, I'm just showing the interface, rather than the implementation.

Does this idea have legs?

There's something very cool about coding the state machine with a fluent interface right inside the POCO, and then automatically generating a visual graph to facilitate discussion and communication. I like the fact that the knowledge is encapsulated in the POCO entities; no additional tools, state matrices or languages are required during the build cycle.

All that said, I'm not buying this this idea yet. It is kind of fun, but having FSM semantics mingling with business domain semantics makes me a little uncomfortable. Also, if my light FSM framework needs to handle more complex cases (superstates, for example), then this approach might be even more invasive.

Thoughts anyone?

Next Steps

If I persue this experiment, I have a few other ideas:

• State Machine Self Diagnosis. It will be able to check for common problems with the state machine setup: a State that never gets transitioned to, guard clauses that will never be called etc.

• Unit Testing Integration I'd like to expose those problems to NUnit, so that the unit testing catches any misuse of the DSL.

Something like this

public void TestPurchaseOrderStateMachine()
{
    foreach( CheckResult result in StateMachine.Check( typeof( PurchaseOrder ) )
    {
       Assert.IsTrue( result.Ok, result.Error );
    }
}

Which might output something like

 10 Assertions. 3 Ok. 2 Failed.
 State Machine Error. PurchaseOrder state "Cancelled" will never be transitioned to.
 State Machine Error. Guard method "ValidateRaisedToCancelled" will never be invoked.

That's it for now, any thoughts welcome!

I can't seem to get State Machines off my brain this week, sad isn't it?

I find that I use them so rarely, yet I have a nagging feeling they could be so incredibly useful. I think it's ultimately because they could let me separate concerns.

Take today for example, I was building run-of-the-mill ASP.NET wizard/form with roughly the following steps. This GUI workflow is to implement a simple online survey that people can submit.

I started out without even thinking about state machines. I just had the use-case docs on my desk, and was hacking some ASP.NET page together. It was getting messy fast.

I really wanted to use some implementation of the state pattern. But, one gripe is that implementations of the state pattern tend to take so much plumbing code to express the state transitions. This article demonstrates my point, I just didn't have time to invest in that much "stuff" (not wanting to diss the author, much of it looks fantastic, I just wanted something easier). Even drawing a state diagram takes too much time IMHO.

I was trying to dream up a simpler way of expressing this state machine kind of thing in code, and so far have come up with the following. Note that so far I'm only communicating states and transitions, but it's a start:

Start -> [Introduction || AlreadyDone]        
Introduction -> Terms -> Scores <-> Nomination <-> Confirm -> Thanks 
[Terms, Scores, Nomination] -> Saved for Later

If I could make this into C# I could then express the 15 possible transitions in only 3 lines of code!! I like that a LOT. In case you're wondering what the symbols mean, here's a brief explanation:

• -> for a one way transition
• <-> for a two way transition (essentially 2 separate transitions)
• Grouping similar transitions using [a, b, c]->d

I've just got started thinking and playing with this stuff, and I hope I can take it somewhere useful!

I'm finally getting time to dig into C# in Depth and try some stuff out. It's pleasing to see some of the terse constructs we now have.As a small example, this is great:

public decimal TotalPrice
{
     get
     {
         return 
            Lines.Sum(l => l.Price * l.Quantity * (IsVat ? 1.175m : 1) );
     }
}

I had a look around for an instant messaging client for coders, but couldn't find one.

Features I want for starters are:

• Cross platform
• Allowing pasting of large amounts of code (<=100 lines, at least)
• Code highlighting for c#, VB.NET, Ruby, Javascript, HTML etc etc
• Pasting of screen shots
• Public channels (like IRC) on particular topics, where people can collaborate
• All public discussions centrally stored and searchable

Anyone know of such a thing?

This makes me sad. So far over 313 people have given a vote of no confidence in the ADO .NET Entity Framework, and it's rising by the hour.

It's sad for two reasons:

• It's a public kicking of someone's hard work. It probably wasn't meant to be that way, but that's how I see it. I feel for the development team.
• Microsoft seem to have screwed EF up. If that's the case, developers will be led away from best practice, and a great opportunity to educate people has been missed.

I've not downloaded and studied the Entity Framework, so I wouldn't personally vote until I've made my own judgement.

On the plus side, if EF truly does fall short of the bar, then the problems might be addressed and we might all get the high quality tool we want, that encompasses best practice drawn from the last few decades of experience.

It's a shame it's taken this kind of stunt to raise the awareness, I just hope everyone gets their happy ending.

Looking forward to downloading EF and finding out for myself!

When I walk around customer offices, I see that they have rules for cleaning stuff up:

If an employee starts filling out an annual-leave request form, but then changes their mind, the form goes in the bin. If a half-completed pension application form never gets sign off, it might be filed for 3 years, and then the IFA puts it in the bin.

As soon as you write something on a piece of paper, it is persistent. Paper is a reliable storage mechanism for keeping your "Anuual Leave Request" around, even if you need to nip out for a 3 hour meeting.

Should software applications do things differently? Shouldn't our web forms all auto-save? This led me to think that business entities should be saved at any time, regardless of whether they are valid or not.

If saving entities at any time is a good idea, then we need some way to clean up the ones that are forgotten, abandoned, or lost. Otherwise our databases will just fill up with crap that is of no use or interest. The business will dictate how and when things are cleaned up, because it knows the most efficient and legal ways of keeping things tidy.

If you believe that most business rules belong in the business entity, then you might agree that this kind of business knowledge should gravitate around business entities also. I'm calling this topic Entity Garbage Collection for now. That said, if you're entities are persisted into a relational database, then it's also a kind of Database Garbage Collection.

If I were implementing Entity Garbage Collection, I'd probably want something like the following:

public class PensionApplication
{
   State[] states = new(){ Draft, Approved, Rejected, Archived };

    //anything in Draft state that's not been touched 
    //for 3 months gets binned
    void GarbageCollect_Draft()
    {
        if( UpdatedAt > 3.Months.Ago )
             GarbageCollect(this);
    }  

    //anything in archived state gets binned after 6 years
    void GarbageCollect_Archived()
    {
        if( ArchivedAt > 6.Years.Ago)
             GarbageCollect(this);
    }
}

Dada! We now have fire-and-forget entity GC; you can specify garbage collection rules for each state that the Pension Application is in. One thing I like about this is that it makes entity garbage collection a first class citizen in the domain model, and clearly visible for each entity.

How and when the GarbageCollection() is called is a separate problem.

Perhaps the DB might have a sproc that runs nightly to delete any entities in the "Garbage" state. You could write some background task would run every night/week to run the GarbageCollection checks on each entity. Alternatively, you might use .NET attributes to specify GC rules, and have a GC subsystem reflect on those Attributes and build it's own, more performance friendly, routines in the database.

As with my other random musings this week, I'm just thinking out loud and haven't actually tried any of this. Hopefully I'll get to play with it in sandbox sometime soon (probably along with some other ideas I've been toying with, and I'll be using NHibernate too I expect).

Thoughts?

Other, equally random, but related musings this week are:

• Business entities should existing in various States
• The regular State pattern may not be most suitable for business entities

I started playing around with some ideas for a simple implementation of the State pattern. I wanted something that would allow business entities to exist in various states, and have different validations and business logic in different states.

This implementation is a starting point. I've not applied it to anything real-world yet, so it might be completely naive. Thought I'd chuck it out there for opinions regardless!

   1:   

   2:  /// <summary>

   3:  /// An issue in an issue tracking system

   4:  /// </summary>

   5:  public class Issue : StateMachine

   6:  {

   7:      //define states applicable to this entity

   8:      State Draft;

   9:      State Raised;

  10:      State Closed;

  11:      State Cancelled; 

  12:   

  13:      //entity properties

  14:      public string Description;

  15:      public DateTime? FirstOpenedAt;

  16:      public List<string> History;

  17:   

  18:      public Issue()

  19:      {

  20:          //init allowable states and their transitions

  21:          Draft.CanBe(Raised, Cancelled).Initial();

  22:          Raised.CanBe(Closed, Cancelled);

  23:   

  24:          //init properties

  25:          History = new List<string>();

  26:      }

  27:      

  28:      //custom validations automagically run 

  29:      //during state transition from Draft to Raised

  30:      void Validate_Draft_To_Raised()

  31:      {

  32:          if( String.IsNullOrEmpty(Description))

  33:              ValidationErrors.Add("Description must be entered");

  34:      }

  35:      

  36:      public void Raise()

  37:      {

  38:          if( ChangeState(Raised) )

  39:          {

  40:              FirstOpenedAt = DateTime.Now;

  41:              History.Add("Issue was raised");

  42:          }

  43:      }

  44:      

  45:      public void Close()

  46:      {

  47:          if( ChangeState(Closed) )

  48:              History.Add("Issue was closed");

  49:      }

  50:   

  51:      public void Cancel()

  52:      {

  53:          if( ChangeState(Cancelled) )

  54:              History.Add("Issue was cancelled");

  55:      }

  56:  }

I've been looking at the state pattern today, with the goal of allowing business entities to behave differently depending on their state. So, an Order in "Shipped" state would have a completely different behavior to an order in "Placed" state; I might not be able to update an order in Shipped state, but I could if it were merely "Placed".

In Design Patterns [GOF], the intent of State is this:

Allow an object to alter its behaviour when its internal state changes. The object will appear to change class

Perfect. But, when I had a crack at implementing it, I got a bit peeved. Here's a few reasons why:

Too many classes; An order entity with states Draft, Raised, Packed, Shipped and InQuery would require 7 classes: One for the context, one for state base class, and one each for the states themselves. This doesn't feel right to me.

Violation of DRY? I'm repeating the interface declarations several times over. If I weren't using this pattern, I'd have only 1 class. I'm just not sure that, in my simple cases at least, the extra conceptual baggage is worth it.

Lack of cohesion. The context is delegating to the various states, and in turn each of those states contains business rules. Would it be better to keep all business logic in one place, or is State an elegant variation of the "rule object" pattern and in fact more cohesive?

Lack of real-world use. I don't see the State pattern used that much, certainly nowhere near as much as Singleton, Strategy, Factory, Iterator, Mediator, Observer and many others. I tried a brief .NET Reflector search, but couldn't find one use of this pattern in the .NET framework. A google code search came up with more possible uses.

Before I get slammed for this post, I am smart enough to see some good things about the State pattern:

• I like the fact that it uses composition over inheritance to handle state-specific behaviour.
• I like the fact that the pattern makes states a first class citizen, that's explicit.
• I also like the fact that individual states are testable.
• There's a hint of OCP here, you can add more states (extend the class) without modifying it.

I must admit, I'm not really qualified to GOF bash :) And, I haven't got the experience with this pattern to truly say I don't like it. However, I would like to find a way of implementing the state pattern in c# so that:

• Entities can only transition to allowable states
• You can have different behaviors in each state
• You don't need to create lots of classes
• You can keep business rules in one place Entity
• It feels natural!

Any thoughts?

Here's a persistence idiom I don't like:

Only save entities if and when they are valid. Invalid entities don't get saved.

In case you're wondering what I'm talking about, here is an example of it in code.

public class Order
{
    public void Save()
    {
        if( this.OrderItems.Count == 0 )
            throw new  BusinessRuleViolation("Must have order lines!")

        if( this.TotalPrice > 1000000 && ! this.IsApproved )
            throw new BusinessRuleViolation("Orders for over £1,000,000 have to be approved");

        orderDAO.Save(this);
    } 

    //insert more code here...
}

Here, we only save if the business thinks it's a valid thing to save.

One reason for this approach is to stop crap data making it into the database. Garbage in means garbage out, so don't put garbage in. I've used this approach many times in the past, but I'm starting to think it's a bad idea. Perhaps we should allow invalid entities to be saved?

Saving something has nothing to do with it being valid or not. When we put the two things together, aren't we're mixing persistence concerns with business rule concerns? Why should I let business rules block me from saving something? Isn't that simply ridiculous!? They're unrelated!

Back to the garbage analogy, can't we just put garbage in and ignore it? At least until it we've made it into something useful.

This approach seems to be gaining acceptance. Google Docs and Microsoft Office always save work in progress, even if we decide not to keep the document. Keeping the document is now a different concern than saving it.

Going back to the order example, separating persistence from business-rule validity might look like this:

public class Order
{
    public void Save()
    {
       orderDAO.Save(this);
    }


    public void PlaceOrder()
    {   
        if( this.OrderItems.Count == 0 )
            throw new  BusinessRuleViolation("You cant save an order with no order lines")

        if( this.TotalPrice > 1000000 && ! this.IsApproved )
            throw new BusinessRuleViolation("Orders for over £1,000,000 have to be approved");

        this.State = OrderState.Placed;
    } 

    //insert more code here...
}

So, we can save an order regardless of it's state, and we can execute the PlaceOrder() business logic regardless without having to save the object. Concerns have been separated. Notes - An improvement on this would be if the Save() method lived on a Repository of course.

Persistence, Business Logic and Validation

This fits in with some other patterns/idioms I like:

• Business objects are totally allowed to get into a "bad" state. In fact, they are often born in an invalid state.
• Business objects can be persisted (saved) no-matter what state they're in.
• Business objects only raise exceptions when you try and do something illegal (like call PlaceOrder() on an order that isn't ready).
• Business objects are packed with behavior and business rules.
• Business objects can let you know what's up with them - they can be Validated()
• Business objects might have many states, each with it's own Validate() method and logic for transitioning between states.

What are the side-effects of this?

• You can save objects anytime and anywhere.
• Invalid objects are stored in the same place as valid ones.
• You don't have to worry about storing objects in different places (such as the session) just because they're not "ready".
• You have a record of what people started, not just what they finished (find all orders over 1 month old that were under construction but never placed).
• Objects are always work in process. They are always in some lifecycle state.
• Other business processes have to be careful to only work with objects that are in a valid state (don't try to ship orders that are "under construction")
• You might need to do some housekeeping to make sure that old, incomplete and invalid items are deleted. There will be many of them hanging around.
• On large systems, you might need to do aggressive housekeeping.
• Database constraints are virtually a no no, the database won't be enforcing business rules, at least not with standard mechanisms.
• You might want to use the state pattern, which could result in a slight object-graph explosion

My heart isn't totally set on all this, I'm really just toying with ideas here. I do, however, feel there's something good about all this.

Feel free to shoot me down, but in the meantime I'm definately gonna play with this in a sandbox environment :)

Having done a preliminary review of NHibernate in Action, Chapter 10 last night, I'm now working on the actual edits. It's been fun!

This is a great chapter, in fact, I think it's my favourite. It focuses on architectural issues, and I always find those the most fascinating. We're talking about separation of concerns, layering applications, whilst giving lots of code samples and real-world advice.

This chapter cleverly starts with a "big ball of mud" example, where one method involves executing a use case, including data access, session management and business rules. The chapter then goes on to show how you can tease apart the responsibilities, pushing them into separate layers. It's one of the clearest approaches to describing these activities I've come across.

Chapter 10 also talks using NHibernate along with ASP.NET sessions, and how you can leverage some of the newer features of NHibernate.

I was at first surprised that Kuate chose to use the DAO pattern in the examples, rather than the Repository pattern (ala DDD). In retrospect this isn't a book about DDD, so explaining those concepts might have used too much ink. DAO still gives a clean separation of concerns, and nicely expresses the techniques involved whilst not requiring huge amounts of background explanation. A good choice. (Note that I did chuck in a small explanation of overlap between these approaches)

This chapter also talks about business transactions that span multiple requests. I'm gonna read it again, because not sure I'm completely in agreement yet! I'll be asking Pierre Henri to help me ensure I've understood it correctly. It seems that the book is recommending the session-per-conversation pattern, but that means keeping state around for a long time, and that sets off alarm bells for me.

All in all this chapter is great, it nicely intertwines the knowledge and techniques presented in the rest of the book with some good architectural principles. I'm up to page 22, so only 15 more to go!

It's 23:38, and tonight I'm working on "NHibernate in Action", Chapter 10. This is the last chapter :) But, there is lots of work ahead still...

I've found that the editing task goes much smoother if I print out the chapters first, and work on them on paper. I think this is for a few reasons:

• Working on paper means I can't get distracted by computer fun opportunities. Basically, my computer is like a huge carnival of interesting things, I find it difficult to focus when I'm hanging out there!

• Working on a printed copy also forces a separation of tasks; the task of finding potential problem areas in the text is separated from the task of correcting them. I scan the printed document as one task, and then edit on screen as another task. If I were a multithreaded, I'd happily spawn off another process to start the editing task, but it's difficult to both at once whilst being productive.

Oh, I mentioned that I find the computer a huge distraction fest. Earlier tonight, whilst "noodling", I found something cool. Check this out:

That's the freaking developers performance monitor that comes with OSX (from the Apple developer website). Like Perf Mon, It lets you monitor disk access, I/O, processor usage, memory access etc for the applications your developing. I'm a .NET dev, but tools like this really inspire me to look further into Mac development.

Best get back to that Chapter 10...

Looks like Manning publishers are running a fairly cool competition:

• Grand Prize: All of their .NET eBooks.
• Daily Prizes: Get a single .NET eBook.

Not bad eh?

I admit, I'm currently helping Pierre Henri Kuate with the NHibernate in Action book, so I'm slightly biased :) That said, I do think Manning are putting out some brilliant .NET books these days, "C# in Depth" and "LINQ in Action" to name a few.

Enter the competition...

As I mentioned earlier, I recently started helping a local developer by doing some mentoring.

Every Friday, we put a few hours aside for the sessions face to face. One thing we found last week was that we spent about 20 minutes going over the assignments set from the previous week. I can certainly talk for Britain at times, but I'm finding that time is golden, and I need make sure I leave enough time to properly cover new topics.

My student has suggested that he send me the assignments before the session, along with any questions he may want answering. Good thinking. Hopefully that will help us make better use of the limited session time, we'll see...

One thing that is working out really well is Google Apps. Their Google Sites feature is brill. I use that to write up lecture outlines for each weeks session (along with images etc), and to upload audio recordings of sessions as well as supporting materials. Of course, the site is shared with my student so he can prepare for the next week and access resources if needed. I can also put other resources like scanned sections of books etc. One thing I like about Google Apps is that it feels like there's very little friction to getting things done. It feels so lightweight and functional. [Pats Google on the back]