|By Hal Helms||
|December 18, 1999 12:00 AM EST||
I'm writing this prior to the turn of the new year, so I trust that somehow civilization bungled through and that you're not reading this by the light of your last candle, alert to the strange sounds outside your door that are growing ever nearer.
With the new year we're introducing a monthly column dedicated to all things Fusebox. First, I want to thank all of you who attended the Fusebox session at the ColdFusion Developer's Conference in Boston. Over 300 people attended the session and some were turned away for lack of room. While I'd like to attribute that to my galvanic oratorial skills, I suspect that it had more to do with how important the quest is for a methodology that works well with ColdFusion.
Why do we need a methodology? Let me reiterate a little of my presentation at the conference and draw an analogy between the state of programming today and that of rifle making 200 years ago. An odd pairing? Well, consider the similarities:
Into this highly inefficient situation stepped an American genius: Eli Whitney. Whitney had already achieved great fame (but not wealth) with his cotton gin. Assessing the situation, Whitney decided that he was just the one to solve the "rifle crisis" and proposed to the new national government that he be awarded a contract to produce 10,000 rifles at a cost of just over $13 each.
The idea was preposterous but Whitney had already proved his ability to effect miracles. Thus the largest single financial transaction in the young nation's history was agreed upon. Whitney's plan for meeting the contract was to standardize parts so they could be reused among different rifles. The rest, of course, is history. (Perhaps, however, Whitney should be the patron saint of programmers, as he delivered late on the contract.)
Today we face a "software crisis." According to one magazine, two thirds of corporate software projects are never deployed or are declared failures. I think you'll agree those numbers are stunning. But what else could we expect with the situation outlined above?
In other issues of CFDJ I've argued that one of the great reasons for Allaire's huge success with ColdFusion is the degree to which it masks complexity from developers, letting them get code out of the programming shop and into use. What we've lacked is a methodology that would direct our programming efforts to produce maintainable, reusable code. I believe that Fusebox goes farther along that path toward radical simplicity in our development efforts.
If we're to get beyond the practice of "one-off" software, in which each bit of code is written one piece at a time, we need to agree on certain standards. We need to document our code with the understanding that it will be fitted into other applications and maintained by different coders many times during its life. And, as we've just recently seen with the Y2K issue, there's no telling just how long that life may be.
This is nothing new, of course; we know documentation is good practice. Why, then, is it so rare? Perhaps we feel something like Mark Twain did when he was asked by a reporter whether there was anything he feared. Twain mulled the question over before drawling, "A blank piece of paper." It's intimidating to think we have to engage in writing a novella with every code file. What exactly should we put in it? What format should it have?
You may already have a standard for documentation. If not, I suggest one for you to evaluate. I call this Fusedoc an appropriate name as the idea was borrowed from its cousin, Java, with its Javadoc specification. Fusedoc was written to work with Fusebox, but it can be used with any code files. It's usually the first step I take when helping a new company implement Fusebox as it's easy to adopt and provides immediate benefits.
The Fusedoc format I took out of one of my fuses is given in Listing 1. One of these goes at the top of every code file.
Here's how to read the Fusedoc:
<!-- actValidateUser.cfm --> The name of the fuse is set in an HTML comment, so if we do a "View Source" from within a browser, we can immediately tell what files are in play.
<!--- || I make sure that the username and password given to me are valid entries in the USERS table. If they are, I will return to...
This is the "Responsibilities" section of the Fusedoc. I write this in the first person (as if the fuse were speaking) and try to provide enough information for another person to tell immediately what's happening with the fuse. My goal is to provide enough for a CF coder, armed with a copy of the data schema, to write this fuse without any knowledge of the application in which it'll be used. The double pipe symbols (||) will be used by our "magic box" to extract individual pieces of the Fusedoc.
You may want to keep historical information here about revisions, testing, etc.
--> userName: a STRING
--> password: a STRING
--> RFA.successfulValidation: a valid FUSEACTION
--> RFA.failedValidation: a valid FUSEACTION
<-- [badlogin]: "yes"> <->
++> dsn: an APPLICATION variable ODBC datasource
--> an incoming parameter: the text following the prefix provides more information about the parameter
--> [square brackets indicate that this incoming variable is optional]
<-- an outgoing parameter
<-- [same explanation as the square brackets above] <->
a parameter that will be received by and sent from the fuse without being changed
++> a global variable not explicitly passed into the fuse, such as server, application and session variables
+++ any file that is required by this fuse. This may include files, fusefunctions, etc.
This just ends the Fusedoc section.
I've found this system to be very workable; once used to it, programmers find it very helpful as it concisely communicates a good deal of information. Even pointy-haired managers and customers can look at the code and have a sense of what's going on.
We can make it even more useful if we process this code through our "magic box" a code file (fuseDocumentor.cfm) that parses the individual elements of the Fusedocs and outputs them on the screen. Fuse Documentor was written to be called as a custom tag. For parameters, it takeswell, let's just run the Fuse Documentor through itself to find out more about it (see Figure 1).
If you want to see particulars on every file in a directory, you can write a little code that will loop through the directory and send each file to Fuse Documentor (see Listing 2). This will let you see very quickly what's going on in an entire code repository.
Fusedoc is a small, lightweight system for seeing the structure of code. I've found it to be helpful in writing maintainable, reusable code. I hope you find it similarly helpful.
You can download the Fuse Documentor file as well as a CF Studio template at www.TeamAllaire.com.
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Cloud People: A Who's Who of Cloud Computing
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Adobe Flex 2: Advanced DataGrid
- Web Services Using ColdFusion and Apache CXF