After discussing the first implementation with the users, the request was made to allow multiple IDs to be entered at once.  Initially, I was worried that the validation for such entries might prove fairly onerous.  The next implementation allowed for multiple entries separated by commas.  The following shows a screen shot of the relevant prompt with some requested items.  Note that one of the requested item IDs refers to an item that is de-listed, and another to one that does not exist (some “fat-fingered” commas are thrown in for good measure).  An already-existing item is shown for context.

Requesting multiple items at once -- some are not valid.

The results of the requested items are shown next:

Requested items listed after request for multiple IDs returns.

The two existing items are added, the item that does not exist is described as such with a prompt to allow creating it inline, and the invalid item is also specified as such.

The utility of this approach was quite dramatic.  A significant number of individual retrievals requiring separate inputting by the user along with separate calls to the server were collapsed into a single input (possibly a paste from an existing list elsewhere) and a single server request.  Typos would potentially show themselves as new item requests, and these could be safely ignored if required.  The single ID entry approach was not lost with this option either, thus providing trainees or infrequent users with a continued straight-forward process.

An alternate approach to this might have been to provide some form of type-ahead search (à la Google search).  Although possibly easing the requirement of “knowing the IDs”, this would have restricted the work-flow to retrieving a single item at a time (or, at a minimum required individual server calls to handle the type-ahead resolution).

Domain experts tend to spend a lot of time working in their applications, and get very good at using them.  Catering to their domain expertise in the features we provide helps to promote their power use.

Copyright © Cliff Mees 2010; all rights reserved.

1. Microsoft Remote Scripting and JavaScript Remote Scripting.  Introduced me to the remote procedure call approach; mostly to classic ASP JScript functions.  This transitioned naturally to Ajax later on.  Not really a JS language aspect, but important nonetheless…

2. Florian Gross implements Ruby-esque features in JavaScript.  I was investigating Ruby, and was delighted to be able to use these approaches in browser code!  It also led me to realize that there was more to JavaScript than I initially thought.

3. Daniel Brockman’s paper: Object-Oriented Event Listening through Partial Application in JavaScript.  I came across this while initially looking at Prototype.  The paper introduced closures in JavaScript to me and how they could be used.

4. Prototype – the first of the modern cross-browser libraries I used with many features of 3 and 4 (above) applied.  I wrote a fair amount of JS that emulated its style.

Lately, I’m using JQuery and enjoying it.

Now, where will my next key influencing driver show up?

Copyright © Cliff Mees 2010; all rights reserved.

Each question is in fact a failing test that focuses on some aspect of Ruby. In fact, the emphasis on testing is such that the first koan introduces asserting.

Occasionally, the koans are broken out into a slightly more substantial “project” exercise. One of these: about_scoring_project.rb requires you to write a method to determine the score of a simplified version of the Greed dice game. As with the other koans, a set of failing tests is provided.

For context, here is the comment section of about_scoring_project.rb that provides the scoring rules:

# Greed is a dice game where you roll up to five dice to accumulate
# points.  The following "score" function will be used calculate the
# score of a single roll of the dice.
#
# A greed roll is scored as follows:
#
# * A set of three ones is 1000 points
#
# * A set of three numbers (other than ones) is worth 100 times the
#   number. (e.g. three fives is 500 points).
#
# * A one (that is not part of a set of three) is worth 100 points.
#
# * A five (that is not part of a set of three) is worth 50 points.
#
# * Everything else is worth 0 points.
#
#
# Examples:
#
# score([1,1,1,5,1]) => 1150 points
# score([2,3,4,6,2]) => 0 points
# score([3,4,5,3,3]) => 350 points
# score([1,5,1,2,4]) => 250 points
#
# More scoring examples are given in the tests below:
#
# Your goal is to write the score method.

My initial implementation used a hash to track the count of each die result. It worked (i.e. passed all the tests), but seemed to be somewhat clunky. Here it is:

def score(dice)

  dice_count = {:"1" => 0, :"2" => 0, :"3" => 0, :"4" => 0, :"5" => 0, :"6" => 0}

  for die in dice
    dice_count[die.to_s.to_sym] += 1
  end

  score = 0

  # * A set of three ones is 1000 points
  if dice_count[:"1"].between?(3,5)
    score += 1000
  elsif dice_count[:"1"] == 6
    score += 2000
  end

  # * A set of three numbers (other than ones) is worth 100 times the
  #   number. (e.g. three fives is 500 points).
  (2..6).each do |non_one|
    if dice_count[non_one.to_s.to_sym].between?(3,5)
      score += (non_one * 100)
    elsif dice_count[non_one.to_s.to_sym] == 6
      score += 2 * (non_one * 100)
    end
  end

  number_not_in_set_of_three = lambda do |num|
    key = num.to_s.to_sym
    if [1,2].include? dice_count[key]
      return dice_count[key]
    elsif [4,5].include? dice_count[key]
      return dice_count[key]-3
    else
      return 0
    end
  end

  # * A one (that is not part of a set of three) is worth 100 points.
  score += (number_not_in_set_of_three.call(1) * 100)

  # * A five (that is not part of a set of three) is worth 50 points.
  score += (number_not_in_set_of_three.call(5) * 50)

end

I didn’t really like how checks for second triples, or numbers not included in a triple seemed to require near-duplicate code (i.e. all those elsif statements).

I ditched the hash of counts approach and came up with:

def score(dice)

  score = 0
  triples = dice.sort.each_slice(3).map(&:join)

  # * A set of three ones is 1000 points
  score = triples.grep("111").count * 1000

  # * A set of three numbers (other than ones) is worth 100 times the
  #   number. (e.g. three fives is 500 points).
  (2..6).each do |num|
    score += triples.grep([num,num,num].join).count * num * 100
  end

  # * A one (that is not part of a set of three) is worth 100 points.
  # * A five (that is not part of a set of three) is worth 50 points.
  {1=>100,5=>50}.each do |num,multiplier|
    score += dice.grep(num).count % 3 * multiplier
  end

  return score

end

That’s a lot more terse, and the near-duplications have been cleaned up. I’m still not too pleased with the [num,num,num].join bit, but couldn’t think of a more elegant but short way to achieve the same thing.

The more terse things get, however, the more I find it is necessary to have comments as the intent of the code becomes more obscured.

RubyKoans was a lot of fun. I encourage you to give them a try!

Copyright © Cliff Mees 2010; all rights reserved.

I thought I’d give it a whirl as well, and decided to actually blog about it too (this is my first meaningful post dear reader; please be gentle!  ).

I focused on the DRY issue that John noted in his analysis: that the base pay calculations were duplicated in  WageCalculatorForEmployee::CalculateWithoutOvertime and WageCalculatorForContractor::Calculate.  To resolve this, I decided to split up the methods to calculate regular and overtime hours as well as the methods to calculate the corresponding pays.

I retained the 3 classes that John established, but modified them as follows:

    public abstract class WageCalculatorBase
    {
        public const Decimal MAXIMUM_BASE_WEEKLY_HOURS = 40;
        public const Decimal MAXIMUM_TOTAL_WEEKLY_HOURS = 80;

        public Decimal HoursWorked { get; protected set; }
        public Decimal HourlyRate { get; protected set; }

        public WageCalculatorBase(Decimal hours, Decimal hourlyRate)
        {
            if (hours  MAXIMUM_TOTAL_WEEKLY_HOURS)
                throw new ArgumentOutOfRangeException(
                    String.Format("Hours must be between 0 and {0}.",
                    MAXIMUM_TOTAL_WEEKLY_HOURS));

            HoursWorked = hours;
            HourlyRate = hourlyRate;
        }

        public Decimal Calculate()
        {
            return CalculateBasePay() + CalculateOverTimePay();
        }

        protected Decimal CalculateBasePay()
        {
            return HourlyRate * BaseHours;
        }

        protected abstract Decimal CalculateOverTimePay();

        protected Decimal BaseHours
        {
            get
            {
                return HoursWorked <=  MAXIMUM_BASE_WEEKLY_HOURS ? HoursWorked - MAXIMUM_BASE_WEEKLY_HOURS : 0;
            }
        }
        protected Decimal OvertimeHours
        {
            get
            {
                return HoursWorked > MAXIMUM_BASE_WEEKLY_HOURS ? HoursWorked - MAXIMUM_BASE_WEEKLY_HOURS : 0;
            }
        }
    }

  public class WageCalculatorForEmployee : WageCalculatorBase
  {
      protected const Decimal OVERTIME_MULTIPLIER = 1.5m;

      public WageCalculatorForEmployee(Decimal hours, Decimal hourlyRate)
          :base(hours, hourlyRate)
      {
      }

      protected override Decimal CalculateOverTimePay()
      {
          return OvertimeHours * OVERTIME_MULTIPLIER * HourlyRate;
      }

  }

    public class WageCalculatorForContractor : WageCalculatorBase
    {
        public WageCalculatorForContractor(Decimal hours, Decimal hourlyRate)
            :base(hours, hourlyRate)
        {
        }

        protected override Decimal CalculateOverTimePay()
        {
            return OvertimeHours * HourlyRate;
        }

    }

Shortly after John’s post (and after I had sent a copy of my refactoring to John), I saw the response provided by Cory Fowler [@SyntaxC4], as well as another by Jon Skeet [@jonskeet].  Both certainly are interesting and provided me with some new insights.  They also added to the original requirements by considering a person who earns a different rate for various amounts of overtime worked.  I decided to try to implement something like this as well, and was able to do so without having to alter my originally refactored design.  Given this, I figure the Template Method approach was a decent fit to the problem.

    public class WageCalculatorForMultiRateContractor : WageCalculatorBase
    {
        protected const Decimal BASE_OVERTIME_HOURS_SPAN = 10.0m;
        protected const Decimal EXTENDED_OVERTIME_HOURS_SPAN = 20.0m;
        protected const Decimal MAXIMAL_OVERTIME_HOURS_SPAN = 10.0m;

        protected const Decimal BASE_OVERTIME_MULTIPLIER = 1.5m;
        protected const Decimal EXTENDED_OVERTIME_MULTIPLIER = 2.0m;
        protected const Decimal MAXIMAL_OVERTIME_MULTIPLIER = 2.5m;

        public Decimal BaseOvertimeHours
        {
            get
            {
                return Math.Min(OvertimeHours, BASE_OVERTIME_HOURS_SPAN);
            }
        }

        public Decimal ExtendedOvertimeHours
        {
            get
            {
                var moreThanBaseOvertimeHours =
                    Math.Max(OvertimeHours - BASE_OVERTIME_HOURS_SPAN, 0);
                return Math.Min(moreThanBaseOvertimeHours, EXTENDED_OVERTIME_HOURS_SPAN);
            }
        }

        public Decimal MaximalOvertimeHours
        {
            get
            {
                var moreThanExtendedOvertimeHours =
                    Math.Max(OvertimeHours - BASE_OVERTIME_HOURS_SPAN - EXTENDED_OVERTIME_HOURS_SPAN, 0);
                return Math.Min(moreThanExtendedOvertimeHours, MAXIMAL_OVERTIME_HOURS_SPAN);
            }
        }

        public WageCalculatorForMultiRateContractor(Decimal hours, Decimal hourlyRate)
            :base(hours, hourlyRate)
        {
        }

        protected override Decimal CalculateOverTimePay()
        {
            var baseOvertimePay = BaseOvertimeHours * BASE_OVERTIME_MULTIPLIER * HourlyRate;
            var extendedOvertimePay = ExtendedOvertimeHours * EXTENDED_OVERTIME_MULTIPLIER * HourlyRate;
            var maximalOvertimePay = MaximalOvertimeHours * MAXIMAL_OVERTIME_MULTIPLIER * HourlyRate;

            return baseOvertimePay + extendedOvertimePay + maximalOvertimePay;
        }

    }

Copyright © Cliff Mees 2010; all rights reserved.

Now, to tinker with some settings…