CM Basics - October 2006 is now available online

CM Basics offers readers the answers to their configuration management

"how-to" questions with tips from the experts, real-life case studies,

product reviews and industry news coverage.

=================
In this Issue
=================

1. Ask Mr. Make: Tips and tricks from the automatic dependency
generation masters
3. Lightweight Code Review Episode 3: Pros and Cons of Four Kinds of
Code
4. Webcast: Knowledge-centric Application Lifecycle Management
5. The CM BlogZone
6. Enhancing CM Tools with Triggers
7. DevZone: Build and Release Management
8. Recent Discussion in the Forums: Issue vs Problem vs Defect vs
Change

http://www.cmcrossroads.com/content/view/7180/236/


===========================================
Tips and tricks from the automatic dependency generation masters
by John Graham-Cumming
===========================================

Any project larger than a simple example faces a dependency management
problem. Dependencies must be generated and kept up to date as
engineers add to, modify and delete from the project. And Make itself
provides no tools for dealing with this problem; all Make provides is a
mechanism for expressing the relationships between files with its
familiar target : prerequisite1 prerequisite2 ... syntax.

GNU Make's mixed dependency syntax
Even Make's dependency syntax is flawed because it incorporates both
'foo.o must be updated if header.h, system.h or foo.c are changed' and
'foo.o is the result of compiling foo.c'. Thus, anything to the right
of the : is a prerequisite, but the first prerequisite where there's a
rule body (i.e. commands) is special: it's the prerequisite that will
be passed to the compiler (or other command) to actually generate the
target.

Read More >>
http://www.cmcrossroads.com/content/view/7172/202/


=====================================
Lightweight Code Review Episode 3:
Pros and Cons of Four Kinds of Code
by Jason Cohen
=====================================

In Episode 2 we explained why the venerable Formal Inspection technique
isn't used in practice and why a "lightweight" style of review might be
useful. In this Episode we explore the pros and cons of four other
common styles of code review and see which one is the most promising
candidate for effective but not time-consuming practical peer code
reviews.

Skinning Cats
There are many ways to skin a cat. I can think of four right off the
bat. There are also many ways to perform a peer review, each with pros
and cons. I hope this turns out to be a bad analogy...

We've already explored why the tried-and-true Formal Inspection method
of code review doesn't work in practice. Several other, simpler
techniques suggest themselves as alternatives:

Read more >>
http://www.cmcrossroads.com/content/view/7171/202/


=======================================
CM Crossroads Webcast Series:
Knowledge-centric Application Lifecycle Management -
what you need to know
=======================================

While application development conjures up many thoughts, the
fundamental core lies in the knowledge gained and used throughout the
development process. From informal ideas and feature requests, to
formal specifications, design documents, development plans, test cases,
release notes, and user documentation, Application Lifecycle
Management (ALM) is a knowledge-centric process. Historically,
however, development teams have managed these vast repositories of
knowledge in virtual silos, with each functional group building their
own knowledge isolated from the team as a whole. In today's
competitive software development environment, the silo-based models
will no longer support the ever-changing demands of large distributed
organizations.

[Sign Up for this Webcast]
http://www.cmcrossroads.com/webcast/1807


================================================== =====
CM Blogzone:
Read the latest from the CM Crossroads bloggers
http://www.cmblogs.com
================================================== =====

Some Assembly Required
by Mark Bools
------------------------
- The Long Road Ahead
http://www.cmcrossroads.com/content/view/7164/230/

- Zero day
http://www.cmcrossroads.com/content/view/7168/230/

- Day 1: Down to work...
http://www.cmcrossroads.com/content/view/7174/230/

Configure This!
by Carson Lucky
-------------------------
- Chapter 3.1: The Master and the Note
http://www.cmcrossroads.com/content/view/7179/230/

Practical Code Review
by Jason Cohen
------------------------------
Why review code?
http://www.cmcrossroads.com/content/view/7162/230/


===========================================
Enhancing CM Tools with Triggers
by Ben Weatherall
===========================================

There are two ways of enhancing CM tools: wrappers and triggers.
Wrappers "wrap" the execution of Command Line calls or API calls, and
triggers are invoked from within the CM tools themselves via hooks or
API calls. Wrappers are "old school" and they work, but they generally
only block a command or to do post-command processing. Triggers, since
they are invoked from within the tools themselves, allow a finer
granularity - especially when dealing with macro-level commands. The
rest of this article will concern itself only with triggers though the
general concepts will work for wrappers as well.

There are three basic types of triggers:

Read More >>
http://www.cmcrossroads.com/content/view/7170/202/


=======================================
DevZone: Build and Release Management
=======================================

The New Build and Release Management Developer Zone has been created in

conjuctionwith IBM Rational as an environment where people can learn,
collaborate,
and share ideas about strategies and techniques to achieve build and
release
excellence in their organizations. We hope you'll become a part of
our community.

Visit the Build and Release DevZone >>
http://www.cmcrossroads.com/content/blogsection/14/206/


===========================================
Recent Discussion in the Forums:
Issue vs Problem vs Defect vs Change
===========================================

Do you consider Issue Tracking, Defect Tracking, Problem Reporting, and
Change Request systems to be one and the same? Are people just using
different terminology or is there a real difference?

One distinction I want to make up front is that I am not talking about
IT HelpDesk type solutions. While there are similarities, I consider
that a different animal with a different purpose than one you would
have for software development and SCM (even if there could be a
connection between the two).

Or maybe everyone considers issues, defects, and problem reports to be
one and the same but change requests to be different with a different
life-cycle even though all possibly result in a change. Change
requests may be more associated with functional changes rather than
"fixing" the software.

In this case, do you have one system or two? And if you have one
system, does it treat a problem different than a change request as far
as life-cycle or do they both have to fit in the same "flow"?

Let me know what you think. Thanks.

Read More>>
http://www.cmcrossroads.com/compone.../topic,69340..0



----------------------------------------------------------------------
© Copyright 1998-2006 CMC Media Inc. - All Rights Reserved
3905 State St. 7-235 - Santa Barbara, CA 93105 - 805-683-1200