Debugging Techniques

Always look at the top error message in the spew that comes out from the compiler. This is usually where the problem is triggered. Junk after that is often spurious, especially if the first problem is a syntax error.

Use a revision control system like Git or Mercurial, and make a checkpoint of your code when ever you have made a significant addition. This way, you don’t get into the situation where you had it working, you broke it, and you can’t get it running again. Git has a little bit of a learning curve, but it rocks. If you are comfortable posting the code where other people can see, you can push your changes to github, and then if you have a catastrophic machine failure, you don’t lose your work.

The binary search is your friend. If you know that the error is somewhere between lines 10 and 20, Comment out lines 15-20 and see if you still have the problem. If so, comment out lines 13 and 14, and so on. A binary search means that you can search 1000 lines of code in 10 comparisons, and save yourself a metric shit-ton of time.  A metric shit-ton is an industry term.

Step through your code in a debugger, line by line, to make sure you know what it is actually doing, not what you think it is doing. Very illuminating. If you don’t have access to a debugger, make liberal use of trace statements. In gcc I often use:

#define TRACE() printf (“%s:%s:%d\n”,__FILE__,__FUNCTION__,__LINE__)

There is something comparable in most languages.

Always work from success. When I start a new C program, I start from

int main(){ printf (“Hello, World.”);}

And compile and run between each minor change.

Don’t be afraid to ask for help. A second set of eyes will often quickly see what you missed. Even more so, when you explain the code to someone else, you often solve the problem yourself. This is known as “verbal debugging.”

Candlepin: Metaphor for an Entitlement System

The planning meeting was held in Massachusetts. When brainstorming project names, someone mentioned that most New England of activities: Candlepin Bowling. Thus, the project is named Candlepin.

When describing a project, especially something fairly abstract like an entitlement system, you can clarify communication by using a strong metaphor for the system. So, to explain entitlements, I am going to use a bowling alley as my metaphor.

One way to think of an entitlement is this:

An entitlement is contract that you can hook up your computer system to my content stream.

But for our metaphor  I’m going to say:

An entitlement is kinda like getting a lane a bowling alley.

To which you say:


Think about it.  When you go bowling, you pay money, but you don’t get a good, and you don’t get a service.  What you get is access to a resource for a limited time.  Say a small company wants to do a team building activity:

We’re going bowling!

This company has 18 employees.  So, we go over to Westgate Lanes (A nod to the local Candlepin Alley of my childhood.  Indulge me) and we walk to the main desk.  We’ve self organizaed ourselves into six teams of three people each.  We get our shoes, and our group gets three lanes assigned to us.  We go, and each team pairs up with another team, the two teams select a lane from the three available, and they bowl.  After each game, the teams re-shuffle the match ups, switch lanes and  play another game.  When each team has played against all the other teams, we return our shoes and go home.

Here is how the analogy maps to entitlement management.

The Data Center is the Bowling Alley.

The lanes are the physical machines that the virtual machines will run on.

The company is still the company paying the bills.

The front desk is the assignment system where you buy slices of time on the machines of the data center.

The three lanes that our company is assigned has a communication network due to the fact that we all need to coordinate our games.  This is the VPN and VLAN setup that lets you specify a cluster of machines can all work together.

The pin setter and the ball retrieval and the scoring projector are analogous to the resources required to run the programs.

The score card is the backing store for the database instance that your applications talk to.

We can extend the metaphor to a larger world, too.  Say we have a bowling league that spans multiple towns and multiple bowling alleys.  This league is composed of teams.  The league sets the schedule, the games are played at the various alleys through out the district.  At the end of the season, the lead team from our league actually plays against the lead team from another league.

This reflects the hierarchical structure of resource management.  You can see that the bowling alley doesn’t really care about leagues except as a way to generate traffic through the alleys.  From the Alley’s perspective, the league is just another customer, paying for lane time.  Perhaps in some cases, the league pays for the time, in others, the individual teams do.  Authority to use a specific lane may have to be cleared not only through the clerk at the desk of the alley, but through the league official that is managing a tournament.  Just like if my company buys a chunk of virtual machines on a cloud somewhere, and then delegates them for internal usage.

Note that the metaphor works for internal clouds as well.  At the Really Big Company (RBC) campus, they take their bowling so seriously that they have a series of lanes installed into a building on their campus.  Now, the scheduling and resource management have been brought in house, but the rest of the rules still apply.

Lexington Green

When summoned by the horseman’s cry
from breaking fast and tending barns
The Yeoman farmers trained response
was to secure their ready arms

The nineteenth dawn that April bore
revealed a revolutionary scene
Captain Parker’s men had met
to learn the news on Lexington Green

But red clad soldiers marched all night
From landing ships on Cambridge shore
And through Lexington they’d pass
En route to capture Concord’s Store

Lieutenant William Sutherland
Called to the men across the sward
Commanding them “Disperse Ye Rebels
Ye Villains, most unruly mob.”

Outnumbered, Captain Parker’s men
were ordered to disperse once more
But chaos and uncertainty
lay beneath the fog of war

Who fired first? the tales suggest
Perhaps a sniper off the scene
but British shot and bayonets
Killed nine men on Lexington Green

Lieutenant Colonel Francis Smith
Arriving with three companies
Ordered drumbeats for the march
To Concord’s Bridge and history

In Concord town the Minutemen
Had learned of Lexington’s Melee
On Punkatasset over-watched
As Redcoats made their first foray

Searching houses, barns and fields
for weapons cached and powder kegs
but long since moved and all they found
were milk and barely, ham and eggs

When searching soldiers caught the site
Of mounds fresh piled in the fields
And ready spades we turned to dig
And three great cannon were revealed

But as they searched, the Minutemen
From Acton, Bedford, and Westford
Joined the Lincoln men above
The Concord rivers northern shore

A Regiment of militiamen
descended  Punkatasset Ridge
assaulted Captain Parson’s Force
assigned to guard the Northern Bridge

The Regulars formed to volley fire
As if for warfare in the town
A warning shot rang out and then
the musket balls were raining down

They fled their post and headed south
to form with Regiments complete
and leaving off their fruitless search
the British Colonel called retreat

The local men who took the bridge
Had learned to shoot when they were Boys
Some had marched to Montreal
To fight the French and Iroquois

At Meriam’s Corner, and Brooks Hill
The local muskets took their toll
and passing through the ambuscade
at Bloody Angle Thirty  fell

At last they came back to the field
where shot had shattered dawn serene
And Parker had then his revenge
Upon the sward of Lexington Green