Terrence Ryan, creator of Squidhead, recently add a fourth part to his great "Running a ColdFusion Shop" series. He covers a wide-range of topics related to running a ColdFusion development shop.
Despite the number of topics he covers, the series feels very tight and is an easy read full of great information.
If you haven't read it yet, I recommend that you do so.
Last night, the newly reconstituted ColdFusion Meetup group had their first presentation. The frequency of future meetings hasn't yet been decided, but it sounds like they plan to have them at least once a month.
This presentation was titled "Attack of the Spam Bots" (about an hour) and was by Jake Munson. It was a good presentation overall and he showed some interesting approaches for fighting comment spam.
His approach emphasizes that the user should not be burdened with proving that they aren't a spammer, but that the program should bear that responsibility. His solution uses JavaScript, but will work without it.
This is due to one of my favorite aspects of his approach - it uses different factors with different weights to identify spam. I was working while watching, so I missed if it was possible to easily changing the weighting on those tests.
During the presentation one or two people mentioned that they were using his solution, CFFormProtect, and that it has resulting in a dramatic reduction in comment spam.
If you are having trouble with comment spam (or form spam of any kind), I would encourage you to take a look at CFFormProtect.
This was certainly a good start to the newly active group and I look forward to more presentations in the future.
It seems obvious that cfargument defines the arguments for your udfs/methods. It is easy, however, to have assumptions about what it does that aren't correct.
Primarily, cfargument defines that arguments that you expect for your function and the order in which you expect them. This helps document your code.
It also acts like cfparam in that it defines a data-type for an argument (throwing an error if the argument isn't of that type) and either making the argument required or providing a default (technically you can do both or neither in cfargument, but that doesn't really make sense.
It also assigns names to arguments that are passed in ordinally (that is, arguments passed in by order but without a specified name). This allows you to pass in arguments either by name or by order.
What cfargument doesn't do, however, is just as important. It doesn't restrict the arguments that come into your function to those specified by cfargument tags.
So, any arguments that are passed in by name will still exist in the arguments structure of the function. This has both drawbacks and advantages. The drawbacks primarily have to do with security. If you use argumentCollection to pass in a Form structure then any form field will be sent in as an argument.
Among the advantages are the ability to pass in argument names that are not known before hand. It also means that you can have named arguments without any cfargument tags at all (though you lose out on important documentation if you do).
Ideally, I would like to be able to check what arguments have been defined by cfargument from within the tag (so that I could programmatically delete other arguments if I wanted without changing that code every time I added an argument). I suspect it can be done, I just don't know how.
Anyone?
I started listening to the ColdFusion Weekly this year. I got started a bit late, but I have been catching up slowly. I finally got caught up recently. Of course, as soon as I got caught up, they took a week off (just my luck).
The good news is that this gave me a chance to listen to some of the interviews on cfFrameworks.com. I haven't listened to them all yet, but so far they are really good.
Peter Bell's interview in particular really impressed me. He was able to explain concepts in an enlightening and informative way. He explained concepts that I didn't understand so that I felt like I had a good idea about them and explained subjects that I thought I understood in a way that gave me a new perspective.
I liked his definition of a framework: "A set of code and conventions that embody a set of opinions about how to solve a class of problems.". He goes on to say that without code you just have a methodology and without conventions you just have a library and without an opinion its a waste of time. I disagree with the last part, but I still think that it isn't a framework unless it embodies an opinion. Anyway, that is just a sampler from the first two minutes of the interview - good stuff.
The one drawback to the cfFrameworks interviews is that the sound quality is a little uneven and sometimes that sound seems not to be cut together right. Despite that small drawback the interviews are well worth a listen.
As to ColdFusion Weekly, that has been consistently good. The topics are good as is the production quality. I had listened to a few last year and the production quality has improved noticeably since then.
I enjoy the news coverage, but I do worry that it leaves them constrained in the amount of time available for their focus topic. Even so, that is consistently well done.
If you haven't listened to ColdFusion Weekly and the interviews on cfFrameworks.com, you should give them a try.
Another podcast is potentially in the works is one by Sean Corfield. That would certainly be worth checking out as well.
I am really excited to keep listing to these podcasts - I think I am finally starting to get the hype on podcasts.
For anyone wanting to learn OO (or just OO concepts) in CF, a new resource is available. Nando has started a new section on is blog called (appropriately) OO in CF.
If you aren't familiar with Nando, he is a frequent writer on the CFCDev list (another great resource for learning OO in CF). Like many of us, he started learning OO after CFCs were introduced to ColdFusion. His explanations are always clear and helpful.
He has two posts on the topic already and they are both very well written.
Even if the topics he is currently covering seem pretty introductory, this is certainly one to watch as he is likely to cover increasingly difficult material as time progresses.
When you get the chance, read OO in CF.
A hate to admit it, but ever since I stopped using Fusebox a few years ago, I have been without a controller. I had my view separated from my model, but no controller to be seen. In fact, I even questioned the need for a controller on most of my projects (while seeing how it could help on larger projects). I was all ready to write a "Do I need a Controller" blog entry.
And then...
One of our sites gets an occasional error that position 12 of array "b" cannot be found. When I look at the code for the page, it has no comments as to what "b" is or where it was created (not in that file, needless to say).
Now, if the variable name had been descriptive ("aBacks", for example) then I would have some clue what it did without comments. I would also be able to search for it. I could search for "b", but that wouldn't really be helpful. So, now I have to go through a tedious process to find the problem just because the programmer used a single letter variable name.
I recommend that you avoid single letter variable names in all cases. Although this example wasn't my code, I will confess that I have used single letter variable names for loop iteraters before ("i", for example). No more! Even if I can't think of a goto variable name, I will at least use "ii" so that someone might be able to search for it.
In this case, the site architecture was pretty simple, so the problem didn't take long to track down. Even so, it would have been much easier with a real variable name.
So the next time that you are tempted to use a single letter variable name, please resist.
I try to avoid blog posts that just repeat what has been said elsewhere, but this is really nice.
I blogged earlier (mid-2005) about a JavaScript version of cfdump. I actually used this recently to help me implement JSMX (which I love!).
I saw an entry today the strikefish blog about another JavaScript CFDUMP which looks great. The advantage of this one is that the output more closely matches the output and behavior of cfdump. I like this in part because the format is familiar and in part because it is a really useful format.
If you just want to see the tool, take a look at JavaScript Dump.
Today I was working on some AJAX code and realized that I would rather get my data from a CFC than from XML data. A few minutes of research later and I have JSMX up and running.
I already had a CFC with the method I needed to get my data with access="remote" (hopefully more on why I have this later - a new approach that seems promising). I thought it would be nice to add another remote method to generate the XML I needed for my AJAX.
This turned out to be rather easy, but I had to set returntype="void" and output="yes" and output the XML straight to the CFC page. This worked, but seemed a bit "hacky".
I was sure that someone had thought of a better way, so off to Google I went to find it.
JSMX advertises itself as an AJAX API - which it is (actually it advertises itself as "The Universal AJAX API"). It has some distinct advantages over other AJAX APIs that I have looked at (and never used). For one, it is just one 13K JS file. For another, it can easily digest data in a number of formats.
Notably, it can digest WDDX data. This is significant because that is the format of data you get if you do an HTTP "Get" on a remote method in a CFC.
The site has a few good examples of use , but none on WDDX. I was unable to find out how it structured the WDDX data in JavaScript. Fortunately, DP_Debug came to the rescue. This is basically cfdump for JavaScript - very handy.
I used the following syntax to test the results:
<script type="text/javascript">
http('GET', 'mycomp.cfc?method=mymethod', DP_Debug.dump);
DP_Debug.dump(MyObject)
</script>
This revealed that the results are basically identical to what you would get if you used <cfwddx> with action="CFML2JS". This made the JavaScript to digest the data even easier than it was to digest the XML.
My steps to implement JSMX:
The result is that my JavaScript got smaller and easier to use and I was able to remove the file to serve up XML data and rely on the CFC to provide that data.
My only complaint about JSMX so far is that it could be much smaller than 13K if the comments and white-space were removed. Other than that small complaint, it is a thing of beauty!
Ben Forta is asking for input on his next CFWACK book. The discussion in the comments reminded of the old CFML Reference that I keep with me. It is one of a few books that I always have near my computer when I travel.
These books taken together weigh less than a pound and take up less space than your average computer book. They have still managed to be tremendously useful when I am working on the road (especially if I am trying to get some work done with no internet connection).
Anyone else have suggestions for books that they don't leave home without?
