Where to start? It seemed like a big task…

There are two distinct activities to solving a hangman game:

1. Finding a list of possible words
2. Figuring out what letter to guess next

Each can be developed independently and then brought together for an effective solution.

There are many, many ways to do this, but I thought I’d just start hacking away in Ruby and then transition to something else at the pain points. Ater a couple hours of late-night coding, I found the Ruby-only solution to be good enough for personal use.

Part 2 deals with figuring out which letter to guess next
Part 3 focuses on how to find the list of possible words
Part 4 brings them together
Part 5 talks about next steps

Because the two pieces of the puzzle (word list and next letter) are independent I can begin with either. I started with the letter frequency analysis because it seemed like a more tractable problem.

Ok, so it seemed easier but where should I start? Since I’m not totally clear on what it should do yet, I’ll start with the tests (aka how it should behave).

Given a list of viable words,

• it should count how many words a letter appears in
• it should only count a letter once per word
• it should count each letter of the word

Here’s the full RSpec for those tests:

    describe "letter frequencies" do
      before(:each) do
        @words = ["lilly", "silly"]
      end

      it "should not return nil" do
        Frequency.letter_frequencies(@words).should_not be_nil
      end

      it "should return a hash" do
        Frequency.letter_frequencies(@words).is_a?(Hash).should be_true
      end

      it "should count the number of words with that letter" do
        freqs = Frequency.letter_frequencies(@words)
        freqs[:s].should == 1
        freqs[:y].should == 2
      end

      it "should not return a frequency larger than the number of words in the list" do
        freqs = Frequency.letter_frequencies(@words)
        freqs.values.count {|c| c> @words.length}.should == 0
      end
    end

    describe "letters per word" do
      before(:each) do
        word = "lilly"
        @letters = Frequency.letters_per_word(word)
      end
      it "should not return nil" do
        @letters.should_not be_nil
      end
      it "should return an array" do
        @letters.is_a?(Array).should be_true
      end
      it "should convert the letter to symbols" do
        @letters.count { |e| e.class == Symbol}.should == @letters.length
      end
      it "should only include repeated letters once" do
        @letters.count { |e| e == :l}.should == 1
      end
    end

Hmm, that’s a little more straightforward than I thought. Let’s make those tests green.

My first pass:

  class Frequency
    def self.letter_frequencies(words)
      freq = {}
      words.each do |word|
        letters_per_word(word).each do |letter|
          freq[letter] ||= 0
          freq[letter] += 1
        end
      end
      freq
    end

    def self.letters_per_word(word)
      chars = []
      word.each_char do |char|
        char = char.to_sym
        chars << char unless chars.include? char
      end
      chars
    end
  end

Ok, so more code to the tests than to the actual implementation. That seems about right...

Next we'll deal with how to make the word list contain only the words we actually want.

The most recent version of the code is available at GitHub: https://github.com/jeffweiss/hanging_solver.

Both had code somewhat like this:

  System.Threading.Mutex mutex = new System.Threading.Mutex(false, "SHARED_MUTEX");
  //some prep work

  //get the mutex for the shared resource
  mutex.WaitOne();

  //work with the shared resource

  //done, release the mutex
  mutex.ReleaseMutex();

Wha?!

I double checked the system mutex name, that was fine.  Didn’t seem like it should be a permissions issue.  The note in the documentation about Terminal Services kept nagging at me.  We weren’t running Terminal Services on the virtual test machine, but we were using Remote Desktop (Terminal Services lite, if you will).

I started by prefacing the mutex from my colleague’s app with “Global\”.  All of a sudden, the apps were working fine on the test system.  But I hadn’t changed my windows service app’s mutex name to look at “Global\”!

  System.Threading.Mutex mutex = new System.Threading.Mutex(false, "Global\\SHARED_MUTEX");
  //some prep work

  //get the mutex for the shared resource
  mutex.WaitOne();

  //work with the shared resource

  //done, release the mutex
  mutex.ReleaseMutex();

It turns out that because my portion was a windows service, it’s execution context changed from being part of the Terminal Services/Remote Desktop session, to being global.  The other app was still in the Terminal Services/Remote Desktop session context because it was an interactive application.  In order for it to lock on the same mutex, it had to explicitly look for the mutex in the Global namespace rather than the Local session namespace.

Makes sense, I guess, but still a little weird. Glad I didn’t spend all day tracking it down either…

Ideally, we’d be able to use the same underlying business objects for both access paths, but we were unsure how well WCF’s DataContractSerializer and XMLSerializerFormat would play together.  Our existing SOAP interface made heavy usage of the DataContractSerializer; I know we could have used that for the REST interfaces as well, but we needed to support XML attributes to align and integrate with other internal projects.

It turns out that you can mock up the business objects with attributes for both DataContractSerializer and XmlSerializerFormat, but the interfaces that expose these objects must be different.  So you can’t have, say, an IDataService that functions for both a DataContract interface and an Xml interface.  The attributes annotating the interface methods must be distinct, otherwise the DataContractSerializer will usurp the XmlSerializerFormat.

[ServiceContract]
[DataContractFormat]
public interface IDataService
{
  [OperationContract]
  List<MyObject> GetMyObjects();
}

[ServiceContract]
[XmlSerializerFormat]
public interface IDataService2
{
  [WebGet(UriTemplate="")]
  List<MyObject> GetMyObjects();
}

[DataContract]
[XmlRoot("myObject")]
public class MyObject
{
  [DataElement]
  [XmlAttribute("name")]
  public String Name { get; set; }
}

This may be not be ideal because now we have two interfaces. So, an alternative is to change to a single interface and pushing the attribute annotations to the implementations. That looks more like this:

public interface IDataService
{
  List<MyObject> GetMyObjects();
}

[ServiceContract]
[XmlSerializerFormat]
public class RestDataService : IDataService
{
  [WebGet(UriTemplate("")]
  public List<MyObject> GetMyObjects()
  {
    return new List<MyObject>();
  }
}

[ServiceContract]
[DataContractFormat]
public class SoapDataService : IDataService
{
  [OperationContract]
  public List<MyObject> GetMyObjects()
  {
    return new List<MyObject>();
  }
}

We talked about the sharp wit of Black Books and how Dylan Moran plays the same (but still quite funny) drunken Irishman in most of his roles to the funny, but obnoxious, Jeremy Clarkson and Top Gear. No mention of British TV is complete without the obvious discussion of The Doctor (based in London, but filmed in Cardiff), though we didn’t get to Doc Martin, I am enjoying it.

We talked of the great murder mystery cozies: Miss Marple, Foyle’s War, Midsomer Murders, Wallander, and Inspector Lynley; and of grittier dramas of MI-5 (Spooks in Britain), Rebus, The Last Enemy, The Prisoner, and Life on Mars.

I also learned of a few great shows that I hadn’t heard of, like Peep Show and That Mitchell and Webb Look.

Sampling of the greats:

• Black Books (Hulu)
• Doc Martin (Hulu: S1-3, Netflix WI: S1-4)
• Doctor Who & Torchwood (Netflix WI: S1-4)
• Foyle’s War
• Inspector Lynley Mysteries
• The IT Crowd (Netflix WI: S1-3)
• Jekyll
• The Last Enemy (Netflix WI)
• Life on Mars
• MI-5 / Spooks (Netflix WI)
• Midsomer Murders
• Miss Marple
• That Mitchell & Webb Look (Netflix WI)
• Peep Show (Hulu)
• The Prisoner
• Rebus
• Sherlock
• Top Gear
• Wallander
• Yes, Minister

This week I did hit what I consider to be a major flaw in the application: no video out on the 3GS.

Over the last week I was in San Diego, on vacation, without my laptop. I had been mulling over getting the Apple AV cable because it would make Netflix Watch Instantly way easier at home: my wife or I could just dock an iPhone and start watching. (No, we don’t have TiVo, which has Netflix built in; we choose not to subscribe to cable service.) Our current setup is a laptop with S-Video out connected to a hand-me-down receiver. We swung by the Apple store, picked up the cable, and headed back to try it out on an episode of Doc Martin. Sound, but no video. YouTube and local videos worked fine, but no go for Netflix (or Hulu Plus, for that matter). As I mentioned, major flaw.

Another issue that is mostly an annoyance rather than a glaring problem is the limitation of only being able to see the first 20 items on your WI queue.
Also, beware of which plan you have. This app doesn’t work if you’re on the el cheapo $5/mo plan. Any normal plan should be fine though.

Bottom line: The Netflix app is one that makes me hope I’m grandfathered in for unlimited data usage when I eventually upgrade. It’s a great app, but would be made better by supporting video out on the 3GS.

First up attempt, Sherlock on PBS.

Watch the full episode. See more Masterpiece.

Two immediate problems. 1) We had left off at about 20 minutes in, but the video in Skyfire offered no way scrub to that location. 2) Audio not sync’d with video, off by about 1.5 seconds.

Second attempt, Fringe on Fox.  This worked, although I did get interrupted, and had to come back to it.  After which I had to start the video from the beginning again because of the lack of the scrub bar to seek to a location.  But at least the audio was synched and the picture looked pretty good for 3G.

Bottom line: $3 price tag is the upper limit of what I’d pay for this.  At least it’s a one-time cost and the service will hopefully improve with time.  The real value here is not the browser, but the backend service to transcode Flash videos.

This is what makes Hulu Plus a hard sell: Paying for TV and still having to watch ads.  But, there was the perfect storm of vaca w/o laptop or wifi, Hulu Plus offering free trial week, and a couple show backlogs.  So, I decided to give it a shot.

What isn’t immediately clear until you sign up for Hulu Plus, is that not all shows that are available on Hulu are available on your device (iPhone in my case), dealbreakers for me were: Psych, Fringe, and Chuck.

Aside from all the shenanigans with the subscription costs and ads, the app itself was a little buggy.  It outright crashed a handful of times, and often I would have sections of a show pause, buffer, repeat from about 15 seconds, and then pause at the same place again.  These could have been related to the 3G connection instead of wifi, but that’s really no excuse.  The plus side of the bugginess is that the ads rarely worked either.

Oh, and on an iPhone 3GS, the Hulu Plus app doesn’t allow output to TV via Apple AV cable.

Bottom line: With limited device content, bugginess, no TV out, and adverts, still not worth the reduced cost of $8/mo.

The move required a few changes to my MX records, so I may have delays getting and answering @jeffweiss.org emails…