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.

Wish you could simplify your captcha's? If you use Peter Farrell's Lyla Captcha, as I do because it's embedded in Ray's BlogCFC, I'll show a few quick changes you can make that will make them much easier for your users to read.

Sound counter-intuitive? Aren't captcha's supposed to be difficult to read, to hamper spammers? In my last entry, I made a call for simplifying captchas and why they aren't all bad. As a blog owner who uses them to weed out the random spambots who would otherwise clog my comments and feedback mechanisms, I like captchas, and I'm grateful for the work Peter's done.

That said, I have to admit that as I've encountered them in the blogs of others, I've grown a tad weary of their complexity. They require the user to type several characters and have several swirly ovals, random lines, and a wavy background. Frankly they're quite hard to read, and it would be a shame to lose commenters for that reason.

Again, the intent is to make it hard for some spammer to scan the captcha request somehow and figure out what's being requested so as to automate around it. Fair enough, but as I said in my last entry I'm really not that concerned about protecting my site from determined break-ins. I'm not a bank. I just want to keep out the automated pests.

With just a couple of changes to Lyla's captcha.xml file, you'll have a much simplified captcha, if you want one.

Lyla is highly customizable

On a lark, I decided to try to find out if Lyla might just be modifiable to dial down the intensity. Turns out it is, by simple changes in the lyla captcha.xml file, as documented in this PDF. Thanks again, Peter! :-)

After a few simple tweaks, I reduced my captcha to just asking for 3 characters, all lowercase, without all the swirly ovals, lines, and wavy background.

Changing Lyla's captcha.xml

In BlogCFC, the captcha.xml file is located in blog\client\includes (or just \includes if you've installed the blog client directory as your webroot.)

To effect the change I wanted, I ended up with the following values for the following entries. Again, see the docs for more info:

You can change them to suit your taste. Note that if you do change the randStrLen, the value selected represents the "average" length of the string that users will be asked to enter, and may vary by +/- 1 from that.

Make the changes, and check 'em out for yourself. Note that with Ray's BlogCFC, you need to reinitialize the blog (add ?reinit=1 to your blog URL) to see the changes. What I did was had one browser page open to do that, and another sitting on a blog comment form. After running the reinit, I could then just reload the comment page to see the impact. (If there's a still-simpler way to test changes to the captcha.xml, let me know.)

If you don't use BlogCFC, then you have to re-instantiate the captcha object after making changes to the XML file. If you've stored it in a shared scope (like application), you need to run some code that reloads it. Of course, restarting ColdFusion will also reload the CFC in whatever scope you stored it in.

Conclusion

Making these changes won't solve the accessibility problems some have with captchas, and it certainly could increase the risk of a determined spammer more easily breaking your captcha. As I said in the last entry, I doubt that's a real concern for most of us. If it proves to be so, then you can dial the intensity back up.

I just want to keep from annoying my readers, and I hope others will consider these changes to keep from annoying us all. :-)

PS: I do realize that one could skip the captcha graphic entirely and just go to prompting the user for a random string. That may just a bit "too" easy for a spambot to get around. To each his own.

Thanking Peter

One last note: while Peter certainly appreciates your kind comments (and do share them, as I'm sure many don't bother), those who REALLY appreciate his work should note that he gratefully accepts contributions by way of his Amazon Wishlist or you may may make a donation with PayPal, using his address, [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.

Most by now understand what captchas are. Some love 'em, some hate 'em. I want to dial down the rhetoric some with this perspective: as a blog owner fighting frequent spam in comments and trackbacks, captchas (in some form, not necessarily a graphic) have their place to keep out spambots, and they can indeed be simplified (even the graphics ones) and at no loss of benefit. My bottom line: I don't use them as a double-key deadbolt lock to keep out intruders, I just use them as a screendoor to keep out random pests.

If you use Peter Farrell's Lyla Captcha, which I use because it's embedded in Ray's BlogCFC, in the next entry I'll show a few quick changes you could make in the Lyla captcha.xml file to make them much easier to read, going from this

to this
.

Before that, I just want to expand on those thoughts above on the general angst against captcha's, and why I think it's ok to make them easier to read.

The Haters

I realize that some have gone to great lengths to decry captchas primarily because they are not "accessible" (to those using screenreaders), though audio ones help solve that.

Others simply hate them because they're too darned difficult to read. I've surely seen that, even in the ones created by default in Lyla (thus my next entry on addressing that).

Now, while most use a graphic that a user must read, it's not the only approach. As the previous link discusses, other approaches include simpler approaches like asking the reader to add some numbers or answer a question (that only a human could reasonably do).

But the other complaint is that they give those who use them a false sense of security, because they can be easily broken, even the graphic ones.

But my Blog is Not a Bank

Here's the thing: my blog is not a bank. While the difficulty in breaking a captcha may be important to a bank or commercial site trying to use them for authentication, I just want to make it hard for an automated spambot to post crap in my blog comments and trackback forms. If you have any similar king of input form on a publicly accessible site, you may suffer similar problems.

I really can't believe anyone would go to the lengths of scanning and breaking the captcha on my site (random as it is) to get a crap spam comment into my lil' ol' blog. And some of the comments are just nonsense; it's not like they're trying to drive traffic to another site or something--so the popularity of my (or your) site isn't the issue. It's just the annoyance factor (both to me as I get notified of comments and to readers who would have to sift through them if I didn't delete them as I do now).

Having made the case for why a simpler captcha may suffice for some purposes, in the next entry I'll show how to control the degree of difficulty in reading them for captchas built using Lyla Captcha.

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've ever needed to know how long your CFMX instance has been running, did you know there's an incredibly simple solution? It's not really obvious, and in fact it may not work on trial editions of ColdFusion (for reasons explained below), but it's worked on the Enterprise and Developer editions that I and others have tested it.

Some may have noticed that there is a server.coldfusion.expiration variable (one of many read-only variables in the server scope, within the coldfusion structure). According to the docs, it's supposed to represent the date on which a trial edition of CFMX will expire.

But some have found (and I've confirmed) that on non-trial editions it instead reports the time that the server started. Try it youself:

It'll be a date, but is it in the future? or the past? Assuming it's the past, and you're not running on a trial edition, then it's likely the time your server had started. If you could restart your server and test again, you'll know for sure. :-)

Better formatting of the result

Now, if you want to easily determine how long the server has been up, just use the datediff function to report how many minutes there are between the time reported and the current time:

Now, that number will be in the thousands after only one day. If you just want to better format the number of minutes, you could use the numberformat function which (without any formatstring) simply adds commas where they would be appropriate:

But even better, you could use one of the nifty functions available at the cflib.org that could help present the result minutes in terms of days, hours, and minutes (duration()). Assuming you included the latter in your page, you could then output the value as:

I may put together a UDF to submit to the cflib to pull all this together, and which also checks if indeed the server being checked is a trial edition, etc. But I'll look forward to hearing people's feedback first.

Other options

Of course, it's worth pointing out that there are of course many tools that will monitor a server's uptime by watching it externally. It may also be possible to ask the operating system to report how long a given process or service has been running. I'll leave that for others to investigate.

Finally, I'll point out that there is indeed a tag in the Adobe Developers Exchange, CF_UpTimeMonger, that purports to help detect server uptime and says it works even for CF 4 and CF5. I have not explored 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.

Have you ever been annoyed when some web form (feedback page, blog comment field, or webforum) fails to properly convert your CFML or HTML so that it's displayed? Does it just disappear? Many know the solution is to convert the tag brackets to their equivalent character entities, > and <), but it's a hassle to do that manually! Last year I wrote about a free web-based tool in another blog of mine, tipicalcharlie.com, and as the challenge came up today on a CF list, I thought I'd point it out here:

http://www.tipicalcharlie.com/convert_markup_for_display.htm (Update: tipicalcharlie domain is no more, but page recovered using Archive.org.)

Note that this is not a tool you need to download and install; it's a hosted tool, just a simple but useful web form that converts whatever code you paste! You can then just copy the result and paste it into your desired form. Enjoy!

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 a blog entry from another site on a topic that I think some of you may enjoy very much:

"Don't miss out on the many powers of the Google Toolbar (some hidden buttons, some new context menu options, and more)"

http://www.tipicalcharlie.com/google_toolbar_1.htm (Update: tipicalcharlie domain is no more, but page recovered using Archive.org.)

Now, if you look closely at the URL, you'll see it's got my name in it. :-) And indeed, it's mine. I started the blog long before this one and in it I share all manner of tips related to computing (not CF-specifically).

I'm always torn about whether to post some topics here or there. I try not to cross-post much at all (and not even to blogs of other folks) unless it's something that I think you might really appreciate and otherwise miss. Such is the case here.

If you like the stuff there (see the categories, as there may be past entries you'd not want to miss), be sure to signup to receive new entries by email (as you can do here), or add it to your RSS reader of course. Not everyone uses them yet. Indeed, see the entry I did there on how to get notification by email of new entries from any blogger who may not offer their own email subscription feature.

(Update: Sadly, squeet (a tool to send RSS feeds by email) is no more. But there are other alternatives, that I track in a category of my CF411 site: http://www.cf411.com/rss_email.)

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.

Exactly one month after releasing Spry 1.2, the Adobe Spry team has responded to user feedback and also slipped in some new features in a new 1.3 preview release.

As part of my ongoing series on Spry, here's my take on what's new. The primary new feature set is "Spry Effects, for introducing animations and color effects to your pages." While it may sound like just eye candy, there are some useful things. More on that below.

There is also an interesting new 2-selects related demo (more below) and various new features to existing things, like new methods to manipulate the accordion, fixes to various aspects of the Ajax (SpryData.js) functionality, as well as support for new setup/finish callbacks for the effects. See the site/docs for more on those. Here, I want to highlight the 2-selects related demo and a brief discussion of the effects.

Nifty 2-selects related demo

One thing that's easily missed (not highlighted anywhere) which may appeal especially to CF developers is a new 2-selects-related demo, though they call it a "master detail" demo instead. It shows how to make 2 selects relates data between 2 datasets. The code is remarkably easy, as explained in the one paragraph there and shown in the few lines of code which you can see doing a "view source" there. Again, this is the beauty of Spry: those few lines of code in the browser are indeed all that you need to write, and all that the browser needs to execute.

For those new to Spry, note that the data can come from any file of XML data or template that generates it, as requested in a line of Javascript (the only javascript code you need to write on the page):

I'll also remind those new to Spry to check out all the entries in this series on Spry, as well as my Spry Compendium of resources to help get you started.

The new effect library

The Spry Effects are the following:

• Appear/Fade Makes an element appear or fade away
• Highlight Flashes a color as the background of an element
• BlindUp/BlindDown Simulates a window blind, up or down, where the contents of the affected elements stay in place
• SlideUp/SlideDown Simulates a window blind, where the contents of the affected element scroll accordingly
• Grow/Shrink Increases/reduces the size of the element
• Shake Moves the element slightly to the left, then to the right, repeatedly
• Squish Reduces the element to its top-left corner and disappears

Some will find more value in various aspects than others. Let's keep in mind that the focus for Spry is on non-technical HTML developers, to ease access to not just Ajax-style development but also the DHTML-based (CSS, Javascript, and HTML) visual components that often go along with those. A key point is that these changes in screen appearance happen without a browser refresh. An interesting point they make is the following:

As with previously-released Spry datasets and their accompanying widgets, we designed Spry effects to be easy to implement on the page while letting the framework do the real work. No new tags or strange syntaxes are required. Designers with a rudimentary understanding of JavaScript can easily implement any of these effects. More advanced users can combine base effects to create more complex and sophisticated effects.

The following shows an example of a basic effect :

onClick="Spry.Effect.AppearFade('target',{duration: 1000,from: 0,to: 100, toggle: true;});"

You can apply an effect to almost any page element, and the code is easy to understand and edit. With the trio of Spry framework features--datasets, widgets, and effects--Adobe hopes to provide designers and developers the tools they need to easily create Ajax-enabled pages.

Why Is Adobe Re-inventing the wheel on effects? Why not just use an existing library?

Sure, there are other libraries that do more, but at least Adobe is working to add more and more. In fact, some may wonder why they are bothering to create their own when there are those other packages. They now specifically address the question of why they don't just integrate with some existing library, like Scriptaculous, and instead are using them as a model while keeping focused on their own vision.

All that said, I could even see CFML folks taking ready advantage of things like the blind, shrink/grow, slide, and squish, such as to add online help on a page that appears and disappears. Again, sure, if you know how to do CSS and/or javascript yourself, you can do it yourself.

I must admit that when shown on this combo page, I'm left wondering how the slide and blind differ from each other (and even the accordion). :-) If you view the demo that works with images instead, the difference becomes more apparent.

The effects are enabled in a new .js file (SpryEffects.js), but beyond that and 3 others it's still quite a light-weight framework.

Other Comments

Note that they indicate in the readme that they've removed the docs from the download, and they are available now only online. Still, it seems most of it has just moved to an articles directory, and there are of course still the reamdme, changelog, and other HTML files in the download.

Finally, they do clarify (frequently) that this is pre-release software, so jump on board and be a part of making it happen--but have patience that things will change as they learn and evolve the product.

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 try to use the Flex Builder CF Wizard, you may get tripped up by trying to deploy the resulting SWF (with its communication back to the CF Server) on a remote box (where that CF Server would live). It's easy enough to do, but it may fail to work, if you're not careful about how you configure things while running the wizard, to indicate that remote server URL. It was causing quite a bit of consternation for some, and finally Ken Reiss has observed the solution and blogged about it:

http://www.kenreiss.com/blog/index.cfm/2006/8/10/Flex-20-with-CFMX-702--SUCCESS

I just think this is something that others may trip over in the future and not find readily, so I want to point it out to those that I can.

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.

Folks often ask me whether I know if BlueDragon can run either of the two performance analysis tools, SeeFusion and FusionReactor. The answer is a qualified "yes". They will run (currently) on the J2EE edition of BlueDragon, but not the standalone editons, BlueDragon Server and Server JX.

Both SeeFusion and FusionReactor are based on an underlying java-based mechanism called Servlet filters. On the surface, it might seem that things should work since the standalone versions of BD are built atop ServletExec (just as CFMX standard and enterprise standalone editions are built atop JRun).

Sadly, the edition of ServletExec that New Atlanta chose to bundle under BD (a choice made a few years ago) does not support servlet filters. ServletExec itself has indeed supported servlet filters for a few years; it's just that New Atlanta never had any motivation to update the version that was underlying BlueDragon. Who knows if that may change in the upcoming BD 7.

The good news is that it seems you can indeed use both SeeFusion and FR with BD/J2EE. I've previously done the former, and my reading of the FR docs for now suggest it would work fine. The installer guide for FR has a section on "manually installing FR", and where it discusses the directories to be updated for working with Tomcat and Jboss, it's really the same info that would apply to BlueDragon deployed on those servers (or any like them). (I've tried it tonight and hit a snag, and the guys from FR are working with me to get through it. I'll update with a comment here whatever I find.)

Finally, of course, BD.NET doesn't support servlet filters at all, so you can't use SeeFusion or FusionReactor on that product.

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 looking for yet another avenue of introduction to Flex and its intergration with CF, particularly a free one-hour Breeze session, check out the recording of BEn's presentation from a couple weeks ago:

http://www.adobe.com/cfusion/event/index.cfm?event=list&type=ondemand_seminar&loc=en_us

On that page, select ColdFusion or Flex from the product list on the right, and on the resulting page, don't be thrown off by the title, "Government: Building Rich Internet Applications". It's of value to all viewers.

As Ben is wont to do, he avoids being powerpoint-centric and jumps right into some generic Flex demos first, and then 20 minutes into it starts to really talk about Flex/CF integration. There's about 5 minutes of discussion after that and then he jumps into code-centric demos, showing the CF-related integration in some flex code and in the Flex Builder, including the wizard. By about 45 minutes he instead starts coding Flex/CF integration manually within the builder, which some may find compelling. There is Q&A throughout (which as always in Breezo's is a bit of a struggle, torn between answering questions and staying on topic) and a lot of Q & A at the end, which many may especially enjoy.

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.

Following onto my 2 previous entries related to updating JDBC drivers in CFMX 6 and 7, some readers may appreciate a little more help on the matter of determining just what version of the drivers they do now have installed.

This news has been shared in various blog entries over the past couple of years. I'd like to reprise them here for your edification. (Note that while they may show how to look at some particular driver, like SQL Server, you can--and would need--to change what they show to look at whichever driver you are interested in. More on that below.):

• Pete Freitag showed some CFML code that gives you the answer on screen
• Brandon Purcell showed a CFML approach that writes its output instead to the CF log files instead (see below for more)
• Steven Erat did a post that is a take-off on Brandon's approach. He too writes his result to the logs, but he shows code naming several different driver class names and showing their versions (at least as they were known then, in 2005). That list of classnames may still be useful in later years. See below. [Indeed, as an update, in 2008, Dan Switzer did another take on that hard-coded listing of driver names, and comments in 2013 showed it working for CF10 then.]
• Finally, Sarge showed how to get the info via the command line (again, see below for more on this, and see also my last comment in the comments section below the post, for a related tip on running that java command)

So a couple more thoughts on all this.

And about the last two options above

First, in the case of the second two options above, note two things:

• Those last two links are versions of each page as recovered using the good 'ol internet archive/wayback machine. For more on the value of this wonderful tool, see my post on that.
• Note that those last two links make reference to files or folders under C:\CFusionMX\ or C:\CFusionMX7\ folders, reflecting the time they were written. For those on CF10 and above, you would look now instead under [yourcf]\cfusion\, or if using instances, [yourcf]\[yourinstance]\.

Finding the version of the driver YOU are using

Second, I said above that you would need to use the name of the driver you really mean to look at, which may be different than what their example show. For instance, Pete's code shows looking at the SQL Server driver, macromedia.jdbc.sqlserver.SQLServerDriver. So what if you're using the Adobe-provided Oracle driver? Or any other?

Well, some good news if you use an "other" driver type (where you choose that in the CF Admin DSN page), then you must provide the driver classname yourself. That would be the name to use.

But what if you one of the several other kinds of drivers listed on that page? CF doesn't show you the classnames it uses for that. (And I could not find it in several places I looked. More below.)

But again see Steven Erat's code above that listed several of the class names known at the time (and which still seem fairly accurate more recently).

And while there are still other places that clever readers may want to point out that may hold them, I could not find them in these places:

• The DSN classname is not listed in the CF Admin page where you add/edit a DSN
• The DSN classname is not not listed in the CF Admin "settings summary" page, even though that does offer useful additional info, like the underlying jdbc URL that CF builds, when using its built-in DB drivers
• They classname is also not listed in the XML within the neo-datasources.xml or neo-drivers.xml files, if you know about them. There ARE classnames there, but you will see that if you look, for instance, at the SQLServer one, it does show a classname (in the "class" xml element). But it's just macromedia.jdbc.MacromediaDriver, not the macromedia.jdbc.sqlserver.SQLServerDriver used in the examples above.
• They're also not listed in the "system information" page in the CF admin--the "i" icon in the top right--which shows the "CF Server Java Class Path". That does not list the class names for the Adobe-provided DB drivers, because they are instead all embedded in one jar, called macromedia_drivers.jar. Really determined folks may know you can unzip that and dig around and determine class names and paths, but I won't elaborate that here.

So it seems that for the built-in CF-provided drivers, you're best off just using the variations offered in those examples above (especially Steven's).

Hope all that help others as much as they have me over the years.