Fusion Authority The House of Fusion Technical Magazine	Issue: 110 May 22, 2002 June 4, 2002
	This is an opt-in magazine. To join, leave or change subscription mode, please visit the signup page. All content of this magazine is copyright Fusion Authority, Inc. It may not be reproduced without permission.

Specials

Macromedia Releases ColdFusion MX!

Breaking News: Lawsuit Judgement Against Macromedia Results in Changes in HomeSite Interface

 

Community

CFMX Certification Coming at the End of This Summer

Charlie Arehart to Speak on CFMX Hidden Gems

Macromedia Announces New Community Manager

Changes in the Fusebox Government and a New Organization Document

A Special Congratulations to Raymond Camden!

New Macromedia Desdev JRun Center

 

Tech and Tags

What's New in the Tag Gallery?

What's New on CFLib.org?

ColdFusion MX Components: A New Methodology for Building Applications

Creating CFCs and Web Services in Dreamweaver MX

ColdFusion MX Evaluator's Guide

Macromedia ColdFusion MX Training Movies

ColdFusion MX: Raising the Return on Investment of Internet Application Development

Using Java and J2EE Elements in ColdFusion MX Applications

Switching from ASP to ColdFusion

Basic Charting and Graphing with ColdFusion MX

Writing User-Defined Functions in ColdFusion MX

Migrating Your Application to ColdFusion MX

CFC Best Practices: Invoking a Security CFC Any Way You Like

Custom Tag or CFC? That is the Question

ColdFusion MX Web Service Pages with Dreamweaver MX

Creating a Web Service in ColdFusion MX

Utilizing XML and XSLT in ColdFusion MX

 

Techniques

Ten Deadly Mistakes Fuseboxers Make

 

Security

Flaw in Macromedia JRun Could Let Attacker Take Over

 

Specials

Macromedia Releases ColdFusion MX!

Macromedia ColdFusion MX Now Available

[Top]

Breaking News: Lawsuit Judgement Against Macromedia Results in Changes in HomeSite Interface

The following interface changes are in effect for this release:

• All QuickBar tabs are displayed by default and individual tabs cannot be removed.
• The QuickBar can be undocked and moved, but individual QuickBar tabs cannot be.
• The right-click toolbars menu is disabled. You can use the Options > Customize dialog box to change the toolbutton display on toolbars and to add custom toolbuttons and toolbars.
• The Resources window can be undocked and moved, but individual Resources tabs cannot be.
• The default order of the Resources window tabs cannot be changed.
• The default display and position of the Standard, Edit, View, Tools, and Debug toolbars cannot be changed.

HomeSite Release Notes (known issues)

[Top]

Community

CFMX Certification Coming at the End of This Summer

"ColdFusion Developers who are or who are becoming CF5 Certified will retain their certification status until December 2003. The certified developer will remain listed on the web site and will be allowed to use the Certified developer logo until December 2003. He/She will then be asked to re-take the new CFMX exam. The new CFMX exam will be available through VUE on August 31st, 2002. The CF5 exam will be retired from VUE testing centers in November 2002."

[Top]

Charlie Arehart to Speak on CFMX Hidden Gems

"CFMX Hidden Gems"

When? Thursday, June 6, 2002, 6:30 PM

Where? NYU Medical Center
Coles 109
550 1st Avenue (Corner of E. 31st Street)
(RSVP to attend: http://www.nycfug.org)

You've probably heard about some of the major new features in CFMX. Things such as ColdFusion Components, support for web services, native XML processing, increased integration with Flash have been talked about even before the product has been released. But there are a lot of smaller, and sometimes important new features that can really add dramatically to your programming capability and what you can do with CFMX.

Veteran CFUG speaker and CFDJ columnist Charlie Arehart will outline several of these hidden gems. He's been doing this sort of thing for each release since 4.01. Come learn what many only ever learn in his seminars and articles.

Please RSVP on the NYCFUG site (http://www.nycfug.org) if you plan to attend.

[Top]

Macromedia Announces New Community Manager

Vernon is a Certified Macromedia Professional, and has been developing web sites for seven years. He is currently developing community-centered web-based applications for Macromedia using ColdFusion. He has also written technical material for Macromedia, and he serves as a consultant and technical editor for various publishers.

Macromedia Community Managers are charged with nurturing the designer and developer communities, and acting as communication conduits between user communities and the Macromedia organization. Community managers also help broker, develop and publish informative articles and tutorials that benefit the developer community.

You can read Vernon's blog (online diary) at http://vvmx.blogspot.com. Vernon can be contacted by writing him at vernon@macromedia.com.

[Top]

Changes in the Fusebox Government and a New Organization Document

The Steering Committee is now known as the "Advisory Committee" (a better description of what they do) and they have elected four people to the Standards Committee (the group that rules on what is included in the official Fusebox standard.) The Standards Committee is made up of 10 members: the six permanent members of the Fusebox Council plus four members elected from the Advisory Committee.

The following four people have been appointed to the Standards Committee by the Advisory Commitee:

• Lee Borkman
• Benjamin Edwards
• David Huyck
• Patrick McElhaney

These changes, and others, are detailed in a new Fusebox Organizational Document on its mission and how it plans to implement it. The organization's stated mission is to:

a. Oversee, guide, and administer the open coding standard known as "Fusebox,"

b. Oversee, guide, and administer Fusebox’s accompanying development methodology known as the Fusebox Lifecycle Process (“FLiP”),

c. Support the community of users of this standard and methodology.

You can read more about the goals of the Fusebox organization by downloading the new document at the URL below:

Fusebox Organizational Document

[Top]

A Special Congratulations to Raymond Camden!

[Top]

New Macromedia Desdev JRun Center

Macromedia Application Development Center for the Java Platform

[Top]

Tech and Tags

What's New in the Tag Gallery?

BugTracks

BugTrax is a tracking and commenting application for bugs, errors or issues that are found within an application or website. BugTrax is designed to work without any modification to your current mappings and can be dropped right into your existing directory structure. All you have to do is set up the datasource to point to the included database file.

CSBanner

This is a very simple yet powerful banner management application with a simple custom tag call for inserting the banner into your page. The system gives you total control over user accounts and ad campaigns. It also allows each user account to have multiple ad campaigns and for the page views and click-throughs for each campaign to be tracked. With your purchase, you get the fully non-encrypted source code. UPDATE: Code has been updated so that you can group banners to display in specific sections of your page. For example, if you want to display Large banners at the top and bottom of your page, but want to display smaller, "promo" banners on the right side of the page, you can now select the banner group attribute when you create the campaign.

SentraCommerce for ColdFusion MX!

SentraCommerce is an e-commerce enabler application. It helps a store owner build a fully functional e-commerce site with its powerful store management features and multiple customization-integration methods. System requirements: MS Windows 2000, Macromedia ColdFusion 5/MX, MS SQL Server 7/2000.

cfx gFont 2.1.3

cfx gFont is used to render server side fonts into graphics for display on any web browser. This capability allows developers to design better looking, more customizable sites in less time. It is meant to work on the fly and by default will intelligently cache images, not re-creating images which have already been created. It can be used directly in live pages without performance consequences.

Streamline 1.0 for Tapestry

Streamline provides feature-rich workflow tools for the Tapestry content management system. Do you want an easy way for content providers to submit their new content to editors or webmasters for approval? Streamline can handle it. Streamline supports multiple workflow paths by member role and content type, including content approval, content rejection, and send to group or member. These workflows can further contain custom workflow properties (i.e. Rejection Reason) which are maintained in a thorough workflow history for each content item. Content approval integrates smoothly with scheduled site updates. Workflow management tools integrate smoothly with Tapestry's roles based security and custom workflow reports are a snap for anyone with a basic knowledge of ColdFusion programming. Finally, Streamline integrates smoothly with Tapestry's member preferences allowing each member to receive email notification of new workflows in their content inbox, filtered by priority.

CF_DateInput

Makes input of Dates a click with the mouse. Supports US and Euro format. User can change Month, Year and also move one month at a time forward or backward. This tag simply removes the need to check if the date input is a valid date. It creates a read-only input field with the name you specify. Developed and tested on IE 5.5 and greater.

PremiumSoft MySQL Studio

PremiumSoft MySQL Studio is a set of graphical database management, reporting and monitoring tools for MySQL database. JAVA developers or web programmers would makes it easier than ever to manage your MySQL database.

WebExplorer 4.0 - Content Manager

Content manager in German.

[Top]

What's New on CFLib.org?

DirectoryList

Mimics the CFDIRECTORY, action="list" command. (CFMX)

Dump

Mimics the CFDUMP tag. (CFMX)

Execute

Mimics the CFEXECUTE tag. (CFMX)

FileInfo

Returns information about a file. (CFMX)

TwosCompToDec

Decodes a 2's complement base 10 (decimal) value into an unencoded base 10 value.

WDDXDeserialize

Allows for deserialization of WDDX data. (CFMX)

WDDXFileRead

Reads a file containing WDDX and returns the CF variable. (CFMX)

WDDXFileWrite

Writes a flat file containing a WDDX packet of any CF variable. (CFMX)

WDDXSerialize

Allows for serialization to WDDX. (CFMX)

[Top]

ColdFusion MX Components: A New Methodology for Building Applications

ColdFusion MX Components: A New Methodology for Building Applications (Macromedia White Paper, April 2002)

[Top]

Creating CFCs and Web Services in Dreamweaver MX

Creating CFCs and Web Services in Dreamweaver MX

[Top]

ColdFusion MX Evaluator's Guide

ColdFusion MX Evaluator's Guide

[Top]

Macromedia ColdFusion MX Training Movies

• Create a connection to a datasource in ColdFusion MX
• Set up a site in Dreamweaver MX
• Authenticate with Remote Directory Services (RDS)
• Create a Recordset/Query with Dreamweaver MX and ColdFusion MX
• Create a Master Detail Page Set to display information from your query

Macromedia ColdFusion MX Training Movies

[Top]

ColdFusion MX: Raising the Return on Investment of Internet Application Development

ColdFusion MX: Raising the Return on Investment of Internet Application Development

[Top]

Using Java and J2EE Elements in ColdFusion MX Applications

Using Java and J2EE Elements in ColdFusion MX Applications

[Top]

Switching from ASP to ColdFusion

Switching from ASP to ColdFusion

[Top]

Basic Charting and Graphing with ColdFusion MX

Basic Charting and Graphing with ColdFusion MX

[Top]

Writing User-Defined Functions in ColdFusion MX

Writing User-Defined Functions in ColdFusion MX

[Top]

Migrating Your Application to ColdFusion MX

Migrating Your Application to ColdFusion MX

[Top]

CFC Best Practices: Invoking a Security CFC Any Way You Like

CFC Best Practices: Invoking a Security CFC Any Way You Like

[Top]

Custom Tag or CFC? That is the Question

Custom Tag or CFC? That is the Question

[Top]

ColdFusion MX Web Service Pages with Dreamweaver MX

ColdFusion MX Web Service Pages with Dreamweaver MX

[Top]

Creating a Web Service in ColdFusion MX

Creating a Web Service in ColdFusion MX

[Top]

Utilizing XML and XSLT in ColdFusion MX

Using XML and XSLT in ColdFusion MX

[Top]

Techniques

Ten Deadly Mistakes Fuseboxers Make

In the last year, I've seen a great number of developers making the commitment to learn Fusebox -- and for good reason: the Fusebox framework and the Fusebox Lifecycle Process (FLiP) give developers both an architecture and a methodology that work well in creating web applications. Even so, there are still many pitfalls that can trip up beginning (and intermediate) Fusebox programmers. If you're learning Fusebox, here are some tips on avoiding common mistakes.

Asking too much of wireframes

The Fusebox Lifecycle Process (FliP) begins with wireframes. A wireframe is a skeletal application meant to engage the client in the process of discovering what is required. (You can get more information on wireframes at www.bjork.net.) I love wireframes. I find them tremendously helpful in the opening stages of a project, when we're trying to find out what the client wants. They're also very useful as a sales tool; clients see them and get excited by the ability to actually point and click-letting them browse through a skeletal application.

But many developers, eager to get coding, treat wireframes as all that's needed to fully explore what clients want. Usually, that's a mistake. I find that wireframes work best when treated like a booster rocket-they're essential for getting us "off the platform", but, having done that, they become ballast that weigh down the project.

Wireframes work best when they help jumpstart the process of prototyping-the process of creating an HTML version of the finished application. (You can get more information on prototyping from www.halhelms.com under the CODE section.) Too often, I see developers treat the wireframe as a substitute for a prototype. This is almost always a mistake-one that, unfortunately, doesn't reveal itself until the very end of the project. Don't forget a basic truth of software development: Clients can only tell us what they want after they see it. In short, wireframes aren't a substitute for prototypes.

Omitting the prototype

This is perhaps the worst mistake we can make. It comes in two varieties. In the first, we completely skip the prototype altogether. "Don't have time," we tell ourselves.

Years ago, I was a cabinetmaker. One of the wonderful things about that experience is that it taught me patience and respect for my material and my tools. If the temptation in developing is to start coding too quickly, the temptation in cabinetmaking is to assemble too quickly. Hey-it's fun! I want to see my beautiful cabinet, chair, or curio. I want others to see it, too.

In working with wood, assembling the piece early in the process means that you're working with a largish object rather than working with what are essentially flat pieces of wood. When you do that, things like routing, drilling, and planing become much harder and you risk ruining not only a single piece of wood (a sad enough experience), but the entire piece. After a few ruined pieces, you learn to be patient, to delay gratification, to trust in the process. There's a reason they call things like cabinetmaking -- and coding -- disciplines.

Before I learned this, I often justified my zeal by telling myself, "I don't have time for all this process stuff. I need to see what I'm building." After the heart-rending pain of ruining a piece or the heart-stopping fear of almost ruining a piece convinced me to slow down, I put a sign up in my shop to help me remember. It read, "If you don't have time to do it right, how will you find time to do it over?"

If you find yourself saying, "I don't have time to do a prototype", consider this: the work of the prototype must be done prior to delivering the application. What people usually mean when they say they don't have time to do a prototype is that they want to do it in while they're writing the code. This is analogous to designing a cabinet while you're building it.

In the second variety of Mistake No. 2, we do a prototype, but don't do it completely. We whoosh through the process, putting up "sample" pages; we start coding before we know exactly what the content will be-in short, we don't have a true prototype.

But all of those details must be decided on at some point in the process. By leaving it until coding has begun, you run the risk that the client tells you something like, "Yeah, Marketing just has to insert a paragraph" only to find out that Marketing's paragraph is really a survey. Oh-and they want to use the results of that survey to tailor the user's experience of the application or site.

My advice on this is the same I gave myself when I wanted to rush to assemble a cabinet: do it right. Understand that much of what prototyping does is to create a context in which the inherent messiness of finding out what the client wants can work itself out.

If you do the prototype right, you'll find out about key people who weren't in the initial meetings (despite your insistence and the client's assurance that all key decision-makers were present). You'll allow the office politics to work themselves out on your prototype-not your code. Finally, you'll arrive at a prototype that both you and your client can agree is exactly what the finished product should look like. Then you can start coding.

How long should a prototype take? Of course, this depends on the application, but I find that almost universally, developers tend to cut the prototype short; the desire to start coding is great. In looking back at jobs I've done, I usually find that the wireframe/prototype phases take up as much as 60% of the entire job. I tempted to say the longer a prototype takes, the greater the chances for project success. Certainly, I've never found myself in a "post mortem" saying, "Gee, I wish we hadn't spent so much time on the prototype."

Not establishing acceptance tests up front

It's easy to start coding and -- like assembling my woodworking project -- it's fun. But when do you stop coding? When is done done? If you don't establish this up front, you're likely to find yourself forever chasing a moving goal line.

Did you build the application for a single machine, later to learn that the numbers of users would require a cluster? Did the client assure you they were going to use SQL Server, only to later (and without telling you) decide to adopt Oracle for all corporate projects? Did the client forget to tell you that the application must handle 5,000 transactions per second?

I've made some of these mistakes, so I can tell you that it is definitely not fun to try to convince your clients (after the fact) that no, this had not been discussed beforehand and that no, the application was not built for this. Make expectations clear: put them into the project documents right after you freeze the prototype. Determine the environment on which you run your acceptance tests and make sure that you have access to that environment while coding.

Not unit-testing code

Now, I realize your code is flawless -- a model by which to guide less experienced coders. Mine too. But we do have to work in teams with other coders and those coders -- well, they do make mistakes, don't they? If you don't unit-test code, you're going to find out the flaws when you do begin to assemble the project. At that point, finding out where the flaws occur is the old needle-in-the-haystack problem. Again, not fun.

Unit-testing code doesn't need to be difficult. I recommend building a simple test harness that creates an environment in which an individual fuse can run. This might include setting variables needed by the fuse, establishing state management, etc. Your Fusedoc provides you with all the information you need to build a test harness and I recommend building them and using them to test every fuse you write. These test harnesses can be saved and run at any point. This can be a great confidence booster when you're deeply into a critical project and could use a little encouragement. Oh, and since you don't want to make those other coders -- the ones who make all the mistakes -- feel bad, you might as well just test your code, too.

Waiting too late to integrate unit-tested code

This mistake is easy to make. There's so much to do when involved in a project-especially a large project-that it's easy to defer integrating the unit-tested code until very late in the project.

I recommend that, if you aren't already doing this, you try having regularly scheduled project "builds," where you integrate all of the code. Typically, after I've identified the fuses and written Fusedocs, I create a simple stub that says something like, "I'm home.main and I'm not implemented yet." With this, I can do a project build from the first day. Now, granted, it doesn't do much, but it does give me a framework for integrating working, tested fuses. I can build the project at regular intervals (I often do daily builds) and do what writers calls a "smoke test". You know, you click the BROWSE button and see if smoke pours out of the machine.

Daily (or weekly) builds are great confidence boosters. They also serve to alert us to areas where problems may arise. It's become something of a joke that on any project, the first 90% of the project is done in three months, while the remaining 10% takes another three months. Or six.

The problem, of course, is that we were never 90% done. We developers are nothing if not optimists. Daily builds are also helpful when working in team environments. Rather than trying to get a teammate to commit to a deadline, why not just use daily builds to see exactly how far along the project is.

The rule I use is that all completed fuses are checked in by mid-afternoon. Another rule is that only one fuse is worked on at a time. This means that at any given point, I should be able to see how the project is doing. If someone needs help, it becomes clear at an early stage and saves recriminations and blame later on. Some people find they don't like these. They make excuses for why they can't do them. Usually this is because the person is afraid to find out how the project really is advancing. But not looking doesn't make something go away.

The best way to ensure project success is to know exactly where we are. Then we can make needed changes and the project can get back on track. Depending on who your client is, you may want to give them access to a daily build site. This can alleviate a good deal of client nervousness. After all, they have reason to fear if their project fails (as most do) and a partnership approach can make you both successful.

Starting at the database

If not prototyping is the most serious mistake we can make, starting a project at the database is probably the most common. "Let's get started on the database schema," someone will say, and others readily go along. It seems to make such good sense. Besides, it's something we can do that feels concrete; we can show our managers the progress we're making.

I suggest that a better approach is to begin by identifying the conceptual components of your application. If, for example, you're dealing with a document management system, your conceptual components probably include a "Document" and an "Author". These exist quite independently of any database. In fact, a database exists only to provide a physical storehouse for these conceptual components. Beginning with a database is truly to put the cart before the horse.

Once you've identified your conceptual components, determine the various properties for each component. If, for example, my application has the concept of an "employee", I might identify its properties as employeeID, firstName, lastName, dateOfHire and so forth.

Part of writing good code is writing clear code. If you're taking your cue from the database-especially if your company has database naming standards-then you're likely to end up with variable names in your code like PRO_CDR_RTN. What does that stand for? Who knows? And once you find out, who will remember in six months?

Instead, you decide what your variables should be named. Make them clear so that in six months, you or whoever is working on your code will be able to tell the nature of the variable from its name. Then you can alias the actual database names so that they come from the database with the name that you want.

It's not just a matter of naming schemes. Beginning with a database creates a needless dependency. Code can't begin until all the database issues are resolved. But in a complex application, this can take weeks or months. Do you want to wait this long to write your code? I sure don't.

You'll want to write code to work with the eventual database record set, of course. One of the great things about relational databases is that they always return tables (or relations in relational database lingo). What starts off as a seven-table many-to-many join all gets resolved down to a simple record set. That means that you can plug in a phony record set and work with it while you're writing code. Later, you can swap out the phony code for the real thing. Your code won't break and it won't have to be rewritten.

I wrote a custom tag called <cf_QuerySim> to help with this. It's pretty simple. Here's a call to create a record set. I don't think you'll even need me to explain the syntax.

<cf_QuerySim> MyQuery firstName,lastName,musicStyle Wolfgang|Mozart|classical Danny|Elfman|modern Arnold|Schoenberg|dodecaphonic </cf_QuerySim>

Not using an architecture

Now, if you're a Fuseboxer, this doesn't apply to you. It surprises me, though, how often I hear some fairly smart people recommending to others the practice of "adapting" an standardized architecture such as Fusebox. I suppose the desire is to put one's own stamp on an architecture, but really, this is bad advice. One of the great things about standards is that they are -- well, standards. Having an "almost standard" won't help much when you run into problems and need help either debugging or finishing code for a project. And unless you want to be stuck forever maintaining code you've written, you'll want to write to a standard so that others can pick up what you've done quickly and easily.

Standards are especially important if you're working on a team. One of Eli Whitney's great contributions to the world was his understanding that standardizing parts could allow products to be built cheaper, faster, and better than the old practice of each person doing their own thing. Whitney was a genius; his advice should trump that of the gurus who are merely legends in their own minds. So, don't "adapt"-use a standard.

Not using projects to learn new technology

You've noticed that technology is whizzing past you? Why not use your projects to help both you and your company by increasing your knowledge? Now, far be it for me to discourage anyone from going to training classes (since I offer them!), but I do encourage you to also use the project you're working on to do some experimenting. I'm not suggesting that you turn your project into a science project, but rather select a very specific and relatively small technology (or a small portion of a large technology) to play with. Besides, have you noticed that companies tend to send their best people off to training-people who have taken initiative and actively seek out learning experiences?

For example, you might decide to experiment with integrating ColdFusion with XML on a project. Brett Suwyn at SiteObjects.com has some pretty neat custom tags that will help you get started with minimal pain. Or you might decide to try implementing the Model-View-Controller design pattern on your application (or a small part of it). (I've written about the MVC design pattern on my site, www.halhelms.com.) If you're using a good methodology like FliP, you'll have time to do this without endangering the project at all.

John Quarto remarked to me recently that "the difference between a programmer and a plumber is the programmer's knowledge." If you don't invest in yourself-in your knowledge-you're likely to find yourself without current skills, putting both you and your company in jeopardy. So be strategic: select a specific area that won't consume an inordinate amount of time and go to school on it!

Fixing problems

We've all done this one: pressure on, little time left, deadline looming-and we have a bug. What do you do? Why, reach for the can of Lucky Brand Magic Fixit Powder, of course. This may take the shape of finding someone who you think may know more than you, shipping off all of the code for the entire project with an accompanying email that goes something like this: "My code isn't working. Please help! I've got a presentation in 2 hours!!! TIA"

Or you might find yourself commenting out variables that are giving you problems, or adding in variables just to make the code "work." Believe me, I am sympathetic. I know the frustration and panic that such a situation induces. But the solution is not reaching for the Magic Fixit Powder. Once simple syntax errors are resolved, you're not dealing with a bug. Instead, you're getting valuable feedback telling you that your understanding of the logic of your program is incomplete. That's all. The solution, therefore, is to gain a complete understanding.

How? Well, one thing I recommend without fail is to use Fusedocs to document your code. You can see easily what variables are supposed to be entering and exiting your code. Are they doing what they are supposed to? Use test harnesses to ensure that what you think is happening really is. You can set self to the value of a page that simply calls Dan Switzer's wonderful Debug.cfm custom tag (www.pengoworks.com) that will give you lots of information about the state of your application.

The important thing to realize is that you're in a situation that is not a singular occurrence. For as long as you're programming, you're going to be dealing with code that doesn't do quite what you expected it to, so craft a long-term strategy.

Isolate the problem, use snippets of code running in a test directory to make sure that each individual piece of your code works. The downside of this advice is that you are likely to end up getting those emails thanking you in advance for "fixing" someone else's problem!

Not asking for help

Wait a minute. I just told you not to rely on others to save you. Now I'm saying that one of the deadly mistakes that Fuseboxers make is not asking for help? Well-yes, that is what I'm saying. Do your homework, for sure. Isolate the problem so that you know exactly where the problem is occurring, but if you still can't figure out where the problem is, ask for help.

Innumerable times, I've found that printing out the code in order to go over it with someone else reveals the problem quickly. I know someone who has a stuffed animal on their monitor that they talk with when running into problems. The point is to break a mental logjam by changing the environment.

Programming, sadly, is often a culture of one-upmanship, where lack of knowledge is a sign of weakness and revealing any weakness is seen as shameful. That's bunk. Our job is to produce a successful software deployment, not to prove to someone that, like Al Franken's character, Stuart Smally, who needed constant self-assurance that he was "smart enough, good enough, and-doggone it-people like me".

Like the ColdFusion community, where Fusebox had its start, one of the great things about the Fusebox community is its collegiality and closeness. If you're not a subscriber to the Topica Fusebox list, you'll benefit from having a very helpful bunch of people who are more than willing to help. You can sign up at my website, www.halhelms.com. While you're there, you can also sign up for my "Occasional Newsletter" that deals regularly with FLiP- and Fusebox-related issues.

You can learn more about:

Wireframes: http://www.grokdotcom.com/wireframing.htm

Prototyping: http://www.grokdotcom.com/prototyping.htm

Fusedocs: http://halhelms.com/index.cfm?fuseaction=code.detail

[Top]

Security

Flaw in Macromedia JRun Could Let Attacker Take Over

Flaw in Macromedia JRun Could Let Attacker Take Over

CERT Advisory CA-2002-14 Buffer overflow in Macromedia JRun

Next Generation Security Software Advisory (#NISR29052002)

MPSB02-02-Patch Available for ISAPI buffer overflow in JRun 3.0/3.1

Product Page for JRun (to Upgrade to JRun 4)

[Top]