Lessons on Rules from the Pinewood Derby Post: 302261754

Sponsored Content

Special Forums News, Links, Events and Announcements Complex Event Processing RSS News Lessons on Rules from the Pinewood Derby Post 302261754 by Linux Bot on Tuesday 25th of November 2008 01:08:53 PM

11-25-2008

Registered User

Lessons on Rules from the Pinewood Derby

Tim Bass
11-15-2008 09:11 AM
Remember all the fun we had when we carved out race cars for our Pinewood Derby? For those of you are were not apart of this great American Cub Scout culture, the pinewood derby is a racing event for Cub Scouts in the Boy Scouts of America. Cub Scouts, with the help of their parents, friends and kits, carve and build their own cars from wood. Cub Scouts usually start from pinewood derby kits containing a block of pine, plastic wheels and metal axles. These events are so popular, the pinewood derby was selected as part of “America’s 100 Best” in 2006 as “a celebrated rite of spring” by Reader’s Digest magazine.

Well, it so happens I was doing some research into rule complexity and what defines “complex” and “complexity” in rule-based systems, when I ran across an article on rules and the pinewood derby. Here is a few quotes from Rule complexity (Rules, Part 2), which I thought you might enjoy.

When creating complicated rule sets, people tend to create many rules are subjective or are difficult to enforce. How do the race inspectors examining wheels ensure that they weren't lathed? Are they weighing each wheel? Visually, lathed wheels can appear to be completely stock. Some races have prohibitions on cars from previous years or on pre-cut cars. The intent is to keep kids from using last year's car. I agree with the intentions - building the car is part of the fun. But who can tell for certain which cars are pre-cut or a re-paint of their older brother's car? Rules like this should be presented as guidelines that should be followed instead of rules that should be enforced.

We see so many software vendors running to sell us their lastest rule-based framework, and the network and blogosphere is buzzing with rule discussions.* So, keep this in mind, as our friend from the pinewood derby lamented:

The problem with trying to create a rule to cover every possible situation is that you can't possibly think of every possible situation.* [...] - understand[s] that the rules can't cover everything. The more complicated you make your rules, the more impossible they will be to enforce. You'll introduce conflicts, ambiguities, and loopholes - [...].

I realize a few of my colleagues (most one that are are selling rule-based systems) wish I would stop blogging and just dissappear into cyberspace without a trace left behind.* They think I have lost my marbles because I cannot jump on the “hype up rules bandwagon!” ** To simply disappear into the ether would be the easy road to go, because for anyone who actually has worked in complex operational problems (not just selling software or “talking the talk”), they understand very quickly that, as our friend at the pineword derby so nicely put it, you can't possibly think of every possible situation, rules cannot cover everything.

Source...

Linux Bot

View Public Profile for Linux Bot

Find all posts by Linux Bot

4 More Discussions You Might Find Interesting

1. Solaris

Private Lessons

Hi everyone, I'm looking to hire for private lessons a individual who is presently working as a unix system administrator or instructor in school who is teaching unix. I live in Clifton nj my nubmer is Cell **no phonenumbers on this forum** or email **no emails on this forum** please let me...

2. Programming

C Lessons

I started wrting c lessons for absoulute begginers to advanced users, I think material can be considered quality, and my students learn programming with this stuff. If you wish feel free to start reading it here: www.visualcmaniac.com its only 5 lessons for now so maybe could be easier for...

3. What is on Your Mind?

The 5 Minute Management Course (Six Lessons)

Lesson 1: A man is getting into the shower just as his wife is finishing up her shower, when the doorbell rings. The wife quickly wraps herself in a towel and runs downstairs. When she opens the door, there stands Bob, the next-door neighbour. Before she says a word, Bob says, 'I'll...

4. What is on Your Mind?

vi/vim lessons 1 - 7

Basic Editing https://www.unix.com/members/neo-albums-forum-pics-picture525-vi-vim-tutorial-1-basic-editing.gif

LEARN ABOUT LINUX

shape_stdrul

SHAPE_STDRUL(7) 					 Miscellaneous Information Manual					   SHAPE_STDRUL(7)

NAME

       shape stdrul - shapeTools RMS general version selection rules

DESCRIPTION

       The  shape release management system requires a set of standard version selection rules to be accessible project wide. These are defined in
       the stdrules file, which is to be included into the Shapefiles of any part of the system controlled by the  shapeTools  release	management
       system.	Version  selection  rules  drive  the  binding	of component names in the Shapefile to specific versions during a build or release
       process (or better: any process performed by invocation of shape(1) ). Some functions of shape_RMS allow definition of the version  binding
       rule being active by defining the VERSIONS macro on the command line. This may be set to any of the rule names listed below.

       If  you want to introduce new version selection rules for project wide use, you may add them to the stdrules file. You should be very care-
       ful, when altering this file. Do not remove any of the rules defined in the original version of stdrules (as it comes from  the	shapeTools
       distribution  tape)  because  these are essential for the release management system. When altering one of the original selection rules, you
       should be very concious of what you are doing, as you may affect the operationality of shape RMS. For a description of the syntax  of  rule
       definitions, see the shape(1) manual.

       The standard version selection rules are:

       most_recent
		 For each component select a busy version if available, the most recent saved version otherwise.

       last_proposed
		 Use the last proposed version of each component. This rule fails, if no proposed version is available

       last_released
		 Select versions from the last generated release.

       last_prereleased
		 Select versions from the last generated prerelease.

       recent_release
		 Select versions included in the last release or prerelease, whichever is newer.

       from_release
		 Select  versions from a specific release or prerelease.  When using this rule the value of the macro RELEASENAME has to be set to
		 the name of the desired (pre)release.

       extern	 Always select a busy version (a regular UNIX file). This rule should be applied to all extern components that are not under  con-
		 trol of the shapeTools version control system.

FILES

       $(SHAPELIBPATH)/stdrules

SEE ALSO

       shape_RMS(1), shape(1)

24.8.119															   SHAPE_STDRUL(7)