• All in the Memory -- bookkeeping services
• Arabella -- a dynamic musical duo
• Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
• Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
• Champagne Beadworks -- handcrafted jewelry and beadwork
• Crafted By Carol -- handcrafted jewelry and beadwork
• Dana Fontaine -- unique photography-derived art
• Dymond Graphics -- note cards, pet/people photography
• Fountains & Funktini -- glass art and more from Beth Keenan and JoAnn Rawley
• Gemini Gypsy -- Carole Good-Hanson's fused glass frames
• Mary Kollman Fine Art -- lovely floral watercolor originals
• Primrose Studio -- terra cotta switch plate covers and wall art
• Ratso's Studio -- astoundingly realistic bronze sculpture
• The Spiral Gallery -- local artists exhibit in the Oregon Cascades foothills
• The Roaming Artist -- info and resources for artists "on the road"
• Van Dyke Sepias -- Jan Van Dyke's nostalgic sepia toned photography
• Veggiemog -- life and times of Kelly O'Toole's Unimog, running on biodiesel
• Village of Willamette Arts Festival -- annual visual/performing arts festival, third weekend of September
• Whitehorse Designs -- Gwen Miller's beadwork and fused glass
• West Linn Arts Commission -- city support for the arts

Useful Metrics

• Measure nothing . This means you cannot claim success by any but the grossest measures, i. e. "did you improve upon normal schedule and budget," which we've already stated will be a long shot on a first Smalltalk project.
  
• Measure everything . The resulting sea of data might be as useful to adversaries as it is to you! For example, "lines of code per person month" will look dismal if a lot of re-use is realized or if your team is inexperienced, and "defect count" may look abnormally high if your process stresses continuous testing.
  

• Locality of reference : how often is "self" and "super" used? (How little are globals, class names, and class variables used? Coupling vs. cohesion analysis.)
  
• Degree/use of abstraction : How deep is the hierarchy? How little are concrete class names used?
  
• Code thrash : what is the average number of changes per method?
  
• Interface size : how "thick" is a module's external interface? (How many methods are public, both by design and de-facto?) How "deep" is a module's interface? (How much of the implementation exposed -- does it require any Collection as an argument, or must it be an instance of MySpecificCollectionThatDoesOneThingOnly ?)
  
• Function count : how many distinct functions does a module perform? ("A module having more than one design decision is 'poorer'" [Bilow 93])
  
• Specification quality : What is the commentary/code ratio? Are methods/classes/modules usable without looking at (and figuring out) their code?
  

  [ prev | top | next ]