Monthly Archives: May 2011

Mongo Remembers All Keys

On the MongoMapper group list, Nick was wondering about getting key names from the model. But he noticed it remembered keys that had once been used… He wanted to only be able to see the current state of his MongoMapper class, I suppose… No dice, Nick!

Remember, MongoMapper Don’t Care! MongoMapper also does not forget! You can always see what keys were ever used as demonstrated here:

MongoMapper.database.collection('users').drop
class User
  include MongoMapper::Document

  key :name, String, :required => true
end
User.destroy_all
text = []
text << "After model with key :name, String"
text << User.keys.keys.inspect

text <<  'User.create(:name => "Fred")'
User.create(:name => "Fred")
text <<  User.keys.keys.inspect

text <<  'User.create(:name => "Fred", :email => "me@me.com")'
User.create(:name => "Fred", :email => "me@me.com")
text <<  User.keys.keys.inspect

text <<  'User.destroy_all'
User.destroy_all
text <<  User.keys.keys.inspect

text.each {|t| puts t}

You can see how the model keys reflect what is in the model class and in the actual document store (that is, dynamically added via a create):

After model with key :name, String
["name", "_id"]
User.create(:name => "Fred")
["name", "_id"]
User.create(:name => "Fred", :email => "me@me.com")
["name", "_id", "email"]
User.destroy_all
["name", "_id", "email"]

Now let’s extend the model class to add a new city key:

class User
  include MongoMapper::Document
  key :name, String, :required => true
  key :city, String
end
text = []
text <<  'Extended the class, adding city'
text <<  User.keys.keys.inspect
text.each {|t| puts t}

As expected: there is the new key:

Extended the class, adding city
["city", "name", "_id", "email"]

Removing Keys

If you accidentally added keys, then you should remove them. For example, I accidentally had an uppercase key in the model for a while (oops). Here is how I eradicated it from the database store:

  def self.purge_msid_key
    uppercase_msid_acts = Account.where(:MSID.exists => true).count
    if uppercase_msid_acts > 0
      Account.unset({}, :MSID)
    end
  end

Related MongoMapper Issue: Track Loaded Keys at the Instance Level

You Don’t Always Have to Follow “The” Rules

A user was asking the following on the Agile Modeling list:

What experience does anyone have about standards for stories written for
non-UI components? I’m working with a proxy PO who feels the standard story
format (As a <user> I want to <activity> so that <purpose>) simply won’t
work for something that doesn’t have a user interface. Imagine, for this
example, a project that has the sole purpose of encrypting data without any
user interaction.

For my needs, I often apply the principles behind the concepts, if not always the exact template of a suggested practice. Take for example, the use of my favorite tool, Cucumber, to write Acceptance Tests. Typically, cukes are written from the user point of view in classic “Given – When – Then.” But sometimes I like to use the cucumber style for testing APIs that I am building.

Here is one example at the Cucumber level (with the companion RSpec shown below):

Feature: Version 2.0: As we parse PDFs, we need to be able to collect a list of fonts
  as a way to help discern the structure of the parsed document based on
  heading levels, density of upper case text, and what not.

Scenario: Parsing a simple document
  Given a sample set of text
  |reference|points|value|
  |R9| 10| Patient: FRANKLIN, BENJAMIN|
  |R9| 10| CHIEF COMPLAINT:|
  When i parse the text
  And provide a set of base fonts
  |ref |basefont|
  | R9 | Helvetica-Bold|
  |R10 | Helvetica     |
  Then I should have the following font stats
  |reference|points|upper_cnt|lower_cnt|percent|
  |R9       | 10   | 4       | 1       | 83    |
  And the following font names
  |reference |points|basefont|
  |   R9     |  10  |Helvetica-Bold|
  |  R10     |  10  |Helvetica     |

Scenario Outline: Parsing a simple document
  When collecting a set of text , ,
  Then I should have  and  word counts and  Uppercase stats

  # Note: the counts are cumulative
  Examples:
    |reference|points|value|upper_cnt|lower_cnt|percent|
    | R9| 10| "Patient: FRANKLIN, BENJAMIN" |  2 |  1 | 66 |
    | R9| 10| "CHIEF COMPLAINT:"            |  4 |  1 | 83 |
    | R9| 10| "PRESCRIPTIONS"               |  5 |  1 | 89 |
    |R10|  9| "Motrin 600mg, Thirty (30), Take one q.i.d. as needed for pain, Note: Take with food, Refills: None."| 0 | 13 | 0 |
    |R10|  9| "(Discount Medication) < Michael L. Panera, PA-C 7/13/2010 17:40>"| 0 | 17 | 0 |

And here’s another one:

Feature: Extract meaningful data from Discharge Message

  Scenario: Extract headings
    Given a discharge message
    When the message is parsed
    Then I should see meaningful information, structured as headings and paragraphs
    And I can get formatted values for HTML display

  Scenario: Extract headings from second message
    Given a second discharge message
    When the message is parsed
    Then I can get formatted values for HTML display

But wait! There is more!

At the “Unit Test” level, RSpec’s can be made rather “english friendly” yet still be all about the underlying API as this diagram and snippet show:

RSpec for an API

The Font Collector RSpec tests

describe PdfParser do
  describe PdfParser::FontCollector do

    before(:all) do
      PdfParser::FontCollector.clear_all()
      ...
    end

    context "initialize" do
      it "should reject missing font reference" do
        ...
      end
      it "should reject missing points" do
        ...
      end
      it "should reject missing value" do
        ...
      end
      it "should accept valid inputs" do
        ...
      end

      it "should start off with simple stats" do
        ...
      end

      it "should recognize reference+size is unique" do
        ...
      end
    end

    context "clear" do
      it "should clear the font list" do
        ...
      end
    end

 

Pair Programming Comments

Yves Hanoulle had some questions from class participants on his post about Pair Programming. I am not a very experienced pair programmer, but that didn’t stop me from providing some answers šŸ™‚

* Can you PP over skype?

Yes — or other similar screensharing technologies (iChat) that allow you to switch control. @jbrains and I did pairing for a code retreat a couple of months ago. You can see the code and a video link here on github.

* Do we need somebody to ā€˜superviseā€™ the way you do PP ? (Esp in the beginning?)

Might not be a bad way to more quickly learn from someone else’s tips and techniques. But even better, just switch up the pairing so that you gain insights/ideas from other people with more experience.

* What if thereā€™s no option possibility to use some OS/Computer

With no computer to program on, you would have to stretch the limits of the definition of pair programming I suppose. Pair Yapping About Programming — P-YAP?

* What to do if there is a conflict between the two, a discussion??

Try and sketch out the competing ideas in code. Unless the argument is about which beer is best… then you need to take it to the bar and do a double-blind taste test.

* It canā€™t work with any type of character, how do you manage?

Pairing should be optional.

* What if one uses AZERTY and another one QWERTY keyboard?

You could solve that with technology.

* Doesnā€™t it make it harder to plan a project or resources people (Yves re-framed resources to people)

I would suspect the team that pairs is not that much different than a team that doesn’t pair. Both teams are probably lousy at estimating <g>. Instead of stressing at how PP affects your team, just make an initial guess at your estimates and alter the guess after each iteration.

* Can someone do PP with 1 person and PP for something else with another person?

I don’t understand the question. If you mean simultaneously, no. If you mean one time someone does Pair Programming with person X, and later does Pair Painting with Person Y — sure, this is possible. But what does it have to do with anything?

* Can you get into ā€œthe zoneā€ when youā€™re PP-ing?

Probably. You’ll just have to try it and see.

* Does Promiscuous Pairing kill the flow? (30ā€² interrupts)

Never tried it. Let the team try it and see what happens.

* Why not use PP all of the time?

Let the team try it and see what happens.

* PP = More talking = more annoying for other nearby teams?

It is more annoying for people that are bothered by such environments. I suppose some people prefer quiet.

* Do you plan who is going to do what or how do you choose whose turn it is?

Let the team decide.

* Can you do PP with > 2 people?

You can do whatever you like. Just observe if it is effective or not. I suspect you might find diminishing returns.

* How do you handle the ā€œDonā€™t careā€?

What does this have to do with PP? If you have done everything humanly possible to help someone become a productive member of the team and they are intent on being a-holes; and you have warned them of the consequences of being an a-hole to the team; then fire them so that the team morale is not broken by “one bad apple.”

Cucumber Parser Smarter Than Me

So that I don’t lose another 15 minutes… I had a step like this:

Given a valid outpatient A01 Admit message (without extra ZP1 segment) with Patient Num "12345678"

And in the steps.rb file:

Given /^a valid outpatient A01 Admit message (without extra ZP1 segment) with Patient Num "([^"]*)"$/ do |pn|

Which happily kept not working:

You can implement step definitions for undefined steps with these snippets:
And /^a valid outpatient A(d+) Admit message (without extra ZP(d+) segment) with Patient Num "([^"]*)"$/ do |arg1, arg2, arg3|
  pending # express the regexp above with the code you wish you had
end

UGH!

After getting rid of A01 and ZP1, I still had this “error,” but it led me to realize it was ALL in the parentheses in the steps.rb file! Why? Because parentheses are valid regex elements. Duh. Once I escaped those, all worked like a champ:

Given /^a valid outpatient A01 Admit message (without extra ZP1 segment) with Patient Num "([^"]*)"$/ do |pn|

Mystery solved.