Chorn Sokun's Weblog

Conquer inner fear, push it to the limit!

Archive for April 2009

Myth of Cambodia Geography Identification Code

with one comment

How many of you are familiar with Cambodia Geography Identification code. Do you know the myth behind it code assignment? Well, it’s all started like this:

  • There are 4 levels of administration
    • Province
      • District
        • Commune
          • Village
  • Each level add up 2 digits begin with Province 2 digits
  • Identification code are stored in numberic form (Integer)

That mean valid village code length bewteen 7 and 8 for example code 24020406 would identified as:

  • Village Name = Ou Ressey Loeu (24020406)
  • In Commune  = Ou Andoung (240204)
  • In District = Sala Krau (2402)
  • In Province = Pailin (24)

Now suppose these Geography represent in 4 separate tables (SQL Server for ghost shack!) 


By knowing a village code (eg:  24020406) I want to extract province code and I want the quickest way possible any thought? Oh ! there will be a reward for best answer.

Written by Chorn Sokun

April 28, 2009 at 5:27 pm

Rhino-Tools a smarter Guard

with 4 comments

When Ayende typed Guard.Against(condition, error_message) it clicked in my brain. I thought wow that was nice and easy to use what it does was check if the condition is true it will throw and exception with error message specify. I had an idea using this litle beast for business validation, since it doesn’t required any special configuration all you have to do is adding reference to Rhino.Common.Clr.dll.

However the original Guard API only has only two static method Guard.Against() it was limited for web application. In web application we might want to report back all problems so user can make the correction before they re-submit the form again, but using Guard.Against() we only catch one problem at a time, if we have multiple codition to check you can imagine how annoy for web experience.

Ayende is kindly enough accepting my patch for two additional method for the Guard bellow:

  • Guard.Check(condition, error_message) – same behavior as Guard.Against() but it won’t throw and exception instead keeping records of problems
  • Guard.Report() – until .Report() get call and exception known as GuardSpotException will be throw.

Let see how I can improve my usage experience with these methods

  new Guard()
    .Check(pay.Date.Equals(DateTime.MinValue), "Invalid payment date.")
    .Check(pay.Amount == 0, "Invalid amount, should it be something other than zero?")

  // persist pay instance to the database
catch(GuardSpotException ex)
  // list of errors message
  PropertyBag["errors"] = ex.GetErrorSummary();

First I instantiate a new Guard object and start checking conditions (business rules) finally I call Guard.Report() if there is any true condition (= business rule voilated) and exception known as GuardSpotException will be throw you then can catch and examin all problems.

Isn’t that cool?

Written by Chorn Sokun

April 10, 2009 at 10:37 am