Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Want to simplify your BlogCFC (or other Lyla-based) captcha? Just grab this updated xml file:

right-click and save this updated xml file

If you're using BlogCFC, you can just drop it into your /blog/client/includes directory (saving your old one to restore if needed, and you may need run the query string option "?reinit=1" to reload blogCFC settings.)

This will instantly your captcha will change from this:

to this:

I've confirmed that the original captcha.xml is the same between releases 5.005 and 5.5 beta 1, where Ray is now including the changed XML file himself in the product itself.

For those curious about what I mean by "simplifying", a few weeks ago I wrote an entry explaining how you could simply your Captcha to just a couple of letters, with a much easier read background and format. I also proposed why I think it's ok. We bloggers don't need to keep out really determined hackers (with a double-keyed deadbolt lock), we just need to keep out the annoying pests (with a screen door).

Since that post, many bloggers have indeed taken up the suggestion, but I have seen blogs where some commenters have pointed our my older entry, with the blogger's saying, "I do plan to get to it". That other entry offered the specific steps to change the captcha.xml file, but if you haven't changed it yourself since implementing BlogCFC, just drop this in. Of course, if you want to do a comparison to make sure, there are lots of good compare tools. My favorite is BeyondCompare.

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Have you by any chance tried to add a comment to my blog and been unable for any reason? I'm not asking you to add one now to test. :-) But I've had at least one person report a problem.

If you have had an error, please drop me an email, charlie (at) carehart.org. I still get plenty of comments, so it's clearly something unique. If you do write, please share what browser and OS you're using (and a screenshot or other details would be appreciated). Thanks

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

I'm so surprised by how many blogs I come across where the blogger has not identified themselves in any way: no name, no bio, no email link. I suppose some may do it intentionally, as some form of anonymity (and I do realize why some may not want to list their email), but I honestly think most just had't thought about whether to list their name or anything more.

I'd like to put out a plea to at least consider listing your name, either in your title ("clever name - by blogger name"), or just in some text below it, or in your toolbar. Better still would be a small bio, or a link to a page that has one. (Maybe it would help if blog software offered an "about" pod that made you think of it more readily.) A photo would be nice, too. And for reasons (and with cautions) I propose below, I recommend you also list your email address.

Why bother with name, bio, and/or email? Because it's in your interest!

There are a couple of reasons to consider it, and they help both you and your readers.

First, as for listing at least your name, a good reason is simply to associate yourself with all the value you create by your blog. Why not get credit for your work? Plus, many would really like to know who you are. (And if your blog software puts a tiny "by" under each blog entry, I'll argue that's not enough. I've missed that myself on more than one site.) Again, whether in the title, below it, or in the toolbar, just put it somewhere! :-)

As for a bio, again, even just a couple sentences about yourself (below the title or in the toolbar) can really personalize the blog. Don't assume everyone knows your background, even if they know you by name. Many readers will appreciate knowing more about where you work, where you're from, etc. Such details can also lend perspective to what you write about. (For instance, if you're a fan or a foe of something where that would color all of your posts, it can be helpful for people to realize, "oh, he works for them|on that open source project|with that tool| etc.)." Let people know where you're coming from.) But at least consider offering some background, even a single sentence.

Finally, as for your email address, someone may want to contact you to offer feedback that's not specific to a post. They may want to offer you work (and not want to announce that in a blog comment)--and even then, which post should they enter such a generic note to you in, anyway? Keep in mind that not all readers realize that you get notified of all comments by email, so they may give up trying to contact you.

Heck, they may even have trouble posting a comment, and therefore need *some* way to contact you. I've certainly seen that before.

But isn't it bad to post your email address online?

OK, I realize you may not want to offer your email, as spambots will capture it. But you've probably noticed more and more people listing their addresses as "name (at) domain". The thinking is that people can figure that out, but spambots (at least the dummer ones) will not. I'll grant that they'll eventually catch on. You just need to way how important the benefits are against the pain of more spam. (You do have a spam catching program, I hope? I love the one I use, Cloudmark Desktop. No, it's not free, but there are certainly many of them you can check out.)

Be careful using that (at) trick with Mailto links
If you do decide to use the (at) approach, but you also offer a mailto link, like:

<a href="mailto:[email protected]">[email protected]</a>

be careful: you need to list the "anti-spammer" address in the mailto (used to launch the email) as well as between the a tags (as shown to the user). Spambots grab all the text on your page, not just what's "visible". This is a pain, because then in the email that's opened the user must notice that you've done this and change it, or the mail will fail to get to you. What I do is explain to the user that by forcing some body text into the mail that's opened. Did you know that was possible?

<a href="mailto:charlie (at) carehart.org?body=please change the spam-fighting email address format I filled in for you, replacing the (at)!">charlie (at) carehart.org</a>

And for those who maybe already knew about it, did you know that you could also use:

<a href="http://tipicalcharlie.blog-city.com/forcing_a_line_break_in_an_html_email_link.htm">force a line break within such content in an HTML email link</a>

(this is from another blog of mine, typicalcharlie.com, which is for generic, non-CF tips)

So please, bloggers, step up and identify yourself. We'll all appreciate it!

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

If you're trying to get to the bottom of high memory or CPU use or database contention on CFML servers, you may be missing a seemingly innocuous but deadly invader (or many of them, really. Many more than you may ever dream.) If you're focusing only on "what are my long running requests?" or wondering "Why does CF have a memory leak?", you may be looking at the wrong problem.

What if the problem isn't really a "leak" at all, nor "poorly performing code", nor "CF being unable to scale", but instead what if it's really all due thousands or millions of page requests, which (worse) are likely creating (unexpectedly ) thousands or millions of sessions and client variables, each day? They may even be something you're causing (but more likely not). It's a pernicious problem that many never even fathom, or may dismiss too readily.

Curious to hear more? Read on.

[....Continue Reading....]

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

When I announced yesterday the repository of recorded video presentations I labelled UGTV, I may not have made it clear enough that these are recordings from dozens of your favorite presenters. It's not just my own presentations. Indeed, right now I don't have any posted myself. :-) There are now dozens of presentations, so come take a look.

I've also since updated the look and feel, to add searching and paging, in addition to the sorting it already offered.

I also want to reiterate that I welcome (and encourage) folks to add more links to other recorded video presentations. Indeed, I hope that CFUG managers will keep this in mind as the place to post notices when they record a new presentation. The form is very simple, asking only for the title and URL for a new presentation to post.

Visit the repository at UGTV.

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

While the first 3 entries in my FusionDebug series of posts have been making the case for using the tool, the fact is that like any tool there are tips and traps that you'll do well to note. In this entry, I share several of these from my experience. First I'll share a few tips on using the tool, then a few on setup of the tool.

Tips and traps on Using the Tool

Favor "Step Over" versus "Step Into", when on tags/functions that don't open files

As you are at a breakpoint about to step to a new line of code, I'll recommend that you use "step over" in favor of "step into". The latter should be used only on tags like CFINCLUDE, CFINVOKE, CFC method calls, and other tags/statements that would open a new file. It allows you to follow the flow of control into that new file (opening it, and stopping at the first line of code within that file.)

Why would I recommend you do not use it on other tags and statements? Well, recall that CFML is built on Java underneath. I've found that sometimes "step into" will cause the Eclipse debugger to take a longer time while stepping through the underlying Java of a given tag or statement. Also, some CFML tags are built in CFML.

FusionDebug doesn't show you the underlying lines being stepped over in such Java or CFML files (it's configured not to by default), but the execution will take longer than if you had used "Step Over". I've found the problem happen with tags like CFDIRECTORY and CFDUMP as well as createobject() and findnocase(). When it happens, things will just seem to be hung, but be patient.

I'm stepping, but nothing happening

Related to the above, if you are doing stepping and things seem hung, for whatever reason, with nothing seeming to happen, watch for the term "Stepping" in the Stack Trace pane (at top right). That just means that it's working, and taking some time to do whatever you've asked. Simply be patient. Control should come back.

"I don't see the 'current instruction pointer' moving while stepping"

This is quite a gotcha, which threw off myself and the FusionDebug guys. In one circumstance, as I hit the "step over" and "step into" buttons, nothing seemed to be happening. The "current instruction pointer" wasn't changing. I thought it wasn't stepping at all.

I looked at the "stack trace" pane, and rather than show "stepping", it did indeed show that the execution was proceeding from one line to the next as I'd hit the buttons.

It turned out to be a problem related to my having opened the file using the file system, rather than via an Eclipse "Project". The docs explain how to open files "properly". Forewarned is forearmed.

Be careful holding breakpoints within CFLOCK or CFTRANSACTION tags for too long

You may not think of or notice this, but if you hold a breakpoint or do stepping within tags like CFLOCK or CFTRANSACTION, you could have a negative impact on other users in your environment.

In the case of CFLOCK, you could keep someone else (who's trying to obtain that lock) from being able to get that lock.

In the case of CFTRANSACTION, you could keep someone (even outside of ColdFusion) from being able to read or update the database you are updating within the CFTRANSACTION. The degree of impact will be influenced by the ISOLATION attribute you use (or its default) in the CFTRANSACTION.

If a runtime error occurs, FD will also seem to stop

Something to keep in mind is that if you find FusionDebug just seem to stop debugging, the problem may be that you've hit a runtime (or even compile time) error in the code, which will cause CF to send an error screen to the browser but will not send anything to the debugging stream that FusionDebug is watching. As such, FusionDebug will just lose its connection to the running program.

If debugging just stops, CFMX admin's "request timeout" may be killing the page

It's easy to forget that when you're in the midst of a debugging session, you're causing the page to take likely several seconds (perhaps even minutes) to run to completion. Recall as well that CFMX has an admin setting called "Timeout Requests after x seconds" which if enabled will cause ColdFusion to detect and halt a page if it takes longer than that time to execute.

Naturally, if it is enabled and you debug a page for longer than that duration, ColdFusion will intercept the request and send an error to the browser. In that regard, this is similar to the previous issue.

Something to noticed, however, is that this "timeout requests" setting is not enabled by default in CFMX 6.1, while it is enabled by default in CFMX 7. As such, this problem of timeouts will more likely happen in CFMX 7, though again either can be configured to support it. Just be aware.

You could also override this timeout setting in a given page by using the CFSETTING tag with its RequestTimeout attribute. (You can of course also affect an an entire application by placing that in the application.cfm.)

If breakpoints fail to fire as expected

If you have any other sort of problems with breakpoints firing, note that the FusionDebug folks have written a tech support article on the topic.

Tips and Traps on Setup

Beware of the impact of debugging on shared servers

Though you certainly can turn on debugging against a central shared server (such as test, staging, or even production), you should be aware of the potential impact.

As has been discussed before, when any user requests a page that's being debugged and their execution would hit a breakpoint, the page will appear to them to be hung until the debugging developer steps through the code to completion.

Beware of the impact of the JVM config changes

As discussed in the FusionDebug User Guide, in the section on setting up tool, one of the changes you make in the jvm.config file is to remove the UseParallelGC option. That change in the garbage collection process could have an impact on the running of the server.

This is one more reason to think twice about running the tool on production.

Understanding the "ports"

When you configure that jvm.config entry, another modification is to name the port that you want the JVM debugging feature to broadcast on. Of course, you want to point to a free port when you name that (you can use "telnet servername portnumber" at the command line to determine if a port is free).

But another point to note is that this port is NOT something you then use when you request pages, nor should it be specified as the value of your web server. Instead, this port number is then used when setting up the FusionDebug interface within Eclipse. All this is well explained in the User Guide.

Using FusionReactor? (Intergral's CF monitor tool)

If you are using FusionReactor, which is Intergral's CF monitoring tool, be sure to disable its "crash protection" feature, while doing debugging. The two features are not compatible.

Summary

Those are a few gotchas. I hope they help you. If you hit others, again, I recommend you check out the FusionDebug web site. They have the docs, faqs, articles, Captivate videos, and more. Most important, they offer free support at [email protected].

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Here's fun news. This week I was the guest in the "CF Hot Seat" on the ColdFusion Weekly Podcast. It was a real treat, especially being the show's 25th ("anniversary") episode. As another treat, those who haven't listened to the show from the beginning will learn during the interview just who was the very first voice heard on the very first episode of the podcast. (If you can't wait, give a listen to the first show.)

In the interview, the focus is FusionDebug (yes, my topic of choice in recent weeks). It's a 30 minute interview, as we had planned. Matt and Pete were great, and I really enjoyed the opportunity. I certainly look forward to it again, and was tickled to hear them mention on the show (after the interview) that they'd be open to having me back in a couple of possible ways.

The interview takes place from about minute 26, though I recommend you listen to the entire podcast. I'm a huge fan of all the CF-focused podcasts, as I mentioned them on the show--and again, Mark Kruger, where's the "muse"?! :-) Anyway, I hope folks are listening to the various CF-based podcasts. I'll share some more thoughts about them and about listening to podcasts in general in a future note.

I have to point out that sadly, during my interview, there's a very unfortunate problem of a "hiccuping" sound that lasts for about 20 seconds on an interval of about every minute for a few minutes, a couple times during the show. I'm working with the guys to see if we can correct that, and I've even pulled in the able assistance of Bruce Williams, host of the "Building the Pod" show about Adobe Audition. He's not had any solution yet. If anyone else is open to the challenge, here's a small clip, and you can hear the problem after 10 seconds. I'd welcome any thoughts.

Of course, I also welcome feedback on the interview itself.