tobinharris.com - Blog

Links for 2008-07-19 [del.icio.us]

2008-07-20T00:00:00-05:00

Links for 2008-07-17 [del.icio.us]

2008-07-18T00:00:00-05:00

Best Life Magazine: Work & Finance: Mark Cuban's Three Rules for Building a Company

18s Video: OSX + XP + Spaces + .NET

2008-07-17T18:56:00Z

I'm really starting to enjoy the Mac OSX + VMWare + Windows for .NET and Rails development.

This video shows some of the cool features that OSX Spaces + VMWare gives.

Using keyboard shortcuts to slide different desktops in and out.
One desktop is OSX Leopard, the other Windows XP
Using Expose to allow mouse movement to trigger window selector, or dekstop selector
Dragging and dropping files between Windows and OSX
Did you notice I had 2 instances of *Visual Studio 2008*, 2 instances of *Microsoft Word 2007*, and *SQL Management studio* running on XP!?

All this on a 30" iMac 2.4Ghz with 4GB Ram. It's cool stuff :)

Friendliest console installer EVER!

2008-07-17T10:27:00Z

This is the friendliest console-based-installer I've ever used:

I love the way it keeps the stress down by saying stuff like: "But don't worry, this installer will tell you how to ...". Very friendly indeed.

It's for Phusion Passenger - a module for hosting Ruby on Rails apps in Apache. Credit to the makers. It makes hosting Rails totally simple. I just switched from using modproxybalancer and mongrel, and it's a walk in t' park so far.

Links for 2008-07-16 [del.icio.us]

2008-07-17T00:00:00-05:00

Links for 2008-07-15 [del.icio.us]

2008-07-16T00:00:00-05:00

Links for 2008-07-14 [del.icio.us]

2008-07-15T00:00:00-05:00

Links for 2008-07-13 [del.icio.us]

2008-07-14T00:00:00-05:00

UI
Summary site of top usability blogs.
UPA User Experience Magazine: Volume 7, Issue 1, 2008
UX User Experiance magazine. Online PDFs and articles.
Latitude/Longitude Finder Utility
Rhino Commons - Ayende @ Wiki
Rhino mocks. Ayendes great collection of tools for working with NHIbernate, Dependecy Injection, Threads etc etc

VMWare Fusion Tip: Use OSX Spaces for seamless switching

2008-07-12T18:14:00Z

I just discovered a tip that’s made my VMWare fusion experience loads better.

I like using my XP/Vista VM in full screen mode, but it’s a pain using Apple-H to hide the machine to get back into OSX.

A better way is to use Spaces and allocate one space for VMWare fusion.

Start your XP/Vista/Ubuntu virtual machine as usual
Enable spaces in your System Preferences
Also, allocate one space to your virtual machine in the dialog
Setup a hot key for transitioning between spaces (Shit-Apple-Arrow is what I use).

It’s much nicer, and you get the beautiful slide transitions between spaces :)

Links for 2008-07-10 [del.icio.us]

2008-07-11T00:00:00-05:00

GoodAgile Scrum Training -
InfoQ: Beyond SOA: A New Enterprise Architecture Framework for Dynamic Business Applications
stems, based on their interaction w
Jungle Disk - Reliable online storage powered by Amazon S3 - JungleDisk
Recommended backup utitlity that leans on Amazon S3. Apparently very slick.
ack -- better than grep, a power search tool for programmers
Home - Org - Terracotta
Network Attached Memory. Possible alternative to memcached?
NHibernate - Billy McCafferty
S#arp looks cool! It's a ASP.NET MVC + NHibernate achitecture + framework.

What Open Source stack do the gurus use?

2008-07-08T04:49:00Z

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 :)

Nice use of Google maps in registration

2008-07-08T04:48:00Z

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!

Generate State Machine diagrams from your POCO Entities

2008-07-06T02:59:00Z

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!

A simpler DSL for GUI state machines

2008-06-30T06:12:00Z

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!

C# aint blunt!

2008-06-26T18:36:00Z

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:

<style type="text/css"> .csharpcode, .csharpcode pre { font-size: 9px; color: black; font-family: Consolas, "Courier New", Courier, Monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } </style>

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

Instant Messanger For Coders?

2008-06-26T02:58:00Z

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?

Sad :-( Over 313 Votes of no confidence for ADO .NET Entity Framework

2008-06-26T02:54:00Z

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!

Database Garbage Collection (for Business Entities)

2008-06-23T17:20:00Z

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:

A .NET state pattern for business entities

2008-06-23T03:05:00Z

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!

<style type="text/css"> .csharpcode, .csharpcode pre { font-size: 0.95em; color: black; font-family: Consolas, "Courier New", Courier, Monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } </style>

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:  }

Is the State pattern broken?

2008-06-22T04:26:00Z

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?

Not persisting invalid entities is rubbish!

2008-06-19T20:42:00Z

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 :)

NHibernate in Action: My favourite chapter

2008-06-19T07:06:00Z

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!