ColdFusion Frameworks

The best retrospective of ColdFusion frameworks I've found on net. Article will give you insight into most popular frameworks and categorization.

Read It!

Unit testing in ColdFusion

Why would CF community differentiate from any other community? That's why "all" Unit testing platforms are derivatives of xUnit project. My choice is CFUnit, because CFCUnit looks abandoned (not sure is it really), it has Eclipse plugin and it's better documented. But, after all, both environments do the job well.

• Download CFUnit from Sourceforge.
• Unpack zip file content ("net" dir) into web server root (ie Apache doc root or IIS webroot).
• Test it on http://localhost/net/sourceforge/cfunit/CFUnitExample/mytest.cfml
• Eclipse Plugin comes prepacked with the latest CFEclipse distribution.

So much about installation. Nnow, when you have everything you need, you just need to know what to do with it. Well, go and read CFUnit primer. It's the fastest way to learn how to use CFUnit.

More to read:
Test Driven Development with ColdFusion (part I-III)

CFC variables.instance

When I saw for the first time, in cfc code, variables.instance = StructNew(), I asked myself "What, what, what?" :) Well, purpose of "subinstancing" of variables structure, is nothing more but teh convenience:
1. It's organized better. All variables of same kind can be grouped in that manner.
2. Easier for cfdump-ing. Do and you'll see what I'm talking about.
3. And it is more obvious what you do: variables.instance.myVar="A" means "I am adding (assigning value to) myVar into instance of variables structure"

Not necessity but can be handy

Developer Guidelines

I found this in "Developer Guidelines" on R-Project developer page. This is something I was always followed during my work but never had it written and digested. So, thank you r-project people for this :) Here it goes:

• DO fix simple bugs
• DO NOT fix bugs that require extensive modification
• DO NOT fix exotic bugs that haven't bugged anyone
• DO make small enhancements if they are badly needed
• DO NOT let one user decide what is badly needed
• DO fix configuration for broken platforms
• DO NOT break functioning platforms in the process
• DO NOT fix things that are not broken
• DO NOT restructure code
• DO NOT add experimental code
• DO NOT modify the API (unless absolutely sure it is buggy)
• DO NOT change defaults without a *very* good reason
• DO clarify documentation
• ONLY add or modify examples if needed for clarification
• DO NOT reword messages
• DO NOT modify regression tests (except if they were buggy)
• DO NOT add code that cannot become reasonably complete by the next release.

Obviously none of the above rules are carved in stone, and all are subject to interpretation in actual cases

Eclipse and SVN Client

I choose Subclipse as my favorite SVN Client plugin for Eclipse. Why? Because most people use it. To install it go here

To start working open Eclipse, go to Window -> Show View -> Other, open up the SVN Folder and pick the SVN Repository, click on the "Add SVN Respository" button and enter the address of your SVN server (svn:// or svn+ssh:// or http:// ot https://). That's it.

Few basic commands (abstract from SVN online book):
The typical work cycle looks like this:

1. Update your working copy.
• svn update

2. Make changes.
• svn add
• svn delete
• svn copy
• svn move

3. Examine your changes.
• svn status
• svn diff

4. Possibly undo some changes.
• svn revert

5. Resolve conflicts (merge others' changes).
• svn update
• svn resolve

6. Commit your changes.
• svn commit