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.

http://www.syngress.com/catalog/?pid=3820

Sale ends tomorrow (Sep 30).

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.

See the details at: http://www.fusion-reactor.com/fusiondebug/buy.html

Note that (according to the footnotes on the page) that the special pricing and community edition offer end on Oct 31. Get it while it's hot!

And to learn more about FusionDebug, see my previous entries on FusionDebug.

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.

Many CFUGs don't seem to be taking advantage of the feature, so I wanted to point it out. Your manager may not know about it, or may have forgotten, or just may not be seeing the benefit. I share this to help you inform and encourage them. (This account is only for use with user group related activities.)

Let me expand on each of the reasons to consider using it.

Gives you access to remote presenters

The most obvious to some is that it permits a group to have a presenter who's not local. Many CFUGs have a hard time getting presenters from within their ranks. Some do get remote presenters to come live, such as if they're in town (which is always nice), but at least a Connect-based presentation is better than having none. It can also inform you of techniques from specialists holding expertise just not available within your group.

Such Connect-based presentations have been very successful. Not always perfect (audio, video, and bandwidth problems can play up), but successful far more often than not judging from those who try it once and then do it again.

Permits you to welcome attendees who might not normally come

Yet another benefit, whether you have a remote presenter or not, is that it can also be used to let others in your group (or even outside your group) see the presentation without being there. Yes, this is a two-edged sword, in that you don't want to cannibalize your local attendance by people saying, "I'll just stay home". We all know that being there is very important, so one wouldn't want to always substitute "watching" for showing up.

Still, there are some who for family reasons, or due to other commitments, can't make some or even all the meetings. This is a nice way to connect them to your group (and promote whatever other services your group may offer).

Naturally, this also opens the door to folks who aren't even local to your group to join in. There are ways you could limit who can participate, but the general thinking among most groups is that you should just let anyone in.

I'll talk about recording and watching recorded presentations in a moment. But this idea of having lots of online attendees brings up a point worth noting.

Sidebar: Challenges of a large number of online attendees

You may wonder, "should I worry at all about how many online attendees join in?" Yes, you might want to be aware of a couple of points. First, the Connect account that is shared is designated to have no more than (I think) 150 total participants at once, across all groups that may share it at once.

Second, when you have lots of online attendees, they tend to engage in chat, which may be a challenge for your presenter to keep up with. I do believe that the person running the Connect meeting can turn off the chat. I'm pretty sure it can be switched on at the end of the meeting (or when desired during the meeting), to open the floor to questions. Such online chat is a two-edged sword, as it can give detract focus from your local attendees. Like any tool, all must use it responsibly.

Recording your presentations, whether a local or remote speaker

Another really nice benefit of using the Connect account (even if you have no remote attendees) is that you can use Connect to record your presentation--even if you have only a local presenter. That's not something that many have yet thought of.

These recordings can then be made available for anyone to watch. They are saved on a server at Adobe (part of the account that's offered). Once recorded, you can share the URL of that recording with others in your group (such as those who missed the meeting, or want to see the presentation again), as well as those outside your group. There's no cost to watch the presentations, nor does is there any limit for the group on how many people can watch the recording. As far as I know, there's also no time-limit for how long the recorded presentations remain available at Adobe.

Speaking of these recorded meetings, I've long been meaning to create a repository for such, and writing this post finally motivated me to do it. It's now available at http://www.carehart.org/ugtv/. I may break it out into its own domain eventually, if it takes off (ugtv.com and .org are already taken). I'll also share the link with Ray to add to his nifty CF portal, where he links to such CF resources.

As far as the issues above about having too large a number of online attendees, or a concern over cannibalizing local attendance, note that you can choose in a meeting to not allow any remote attendees, and only offer the recording. That's your own call.

Showing previously recorded presentations at your meeting

One final benefit of these recorded Connect presentations is that you can use them as alternatives to live speakers. I mean, think about it, if you're viewing a presenter via Connect, it's not much different to just view such a presentation, recorded previously.

I know some may lament, "well if we can just watch the recording, couldn't we do that on our own?" I'll say, sure, you could, but would you? Do you? I know I have a really hard time getting around to watching all the available recordings that already exist. Just like we could also read a book or article or blog entry and perhaps hear all that a given speaker would say on any topic.

Yet still we go to the CFUG, both because we might not otherwise get around to reading up on the subject, and because we may never even think to in the first place. And of course, there's also the networking and camaraderie that comes from actually being at the meeting.

Those who know me know that I'm a huge fan of CFUGs, both learning from them and contributing to them. I've spoken to several dozen of them, many several times, over the past 7 years. I was also manager of the Atlanta CFUG in 2006-7 (and previously managed the Southern Maryland CFUG in 2002-2003). I offer this as one more way for the community to share and strengthen itself. I hope it proves helpful to many.

PS: The Virtual Online CFUGs

While we're on the subject of Connect-based presentations, note as well that there is a long-standing "virtual" meeting, called the ColdFusion Meetup, now run by myself and Ra Camden. It meets about monthly, and he often posts recordings of past presentations on the site. Ray had also previously started a new "Jedi Virtual User Group", with one meeting described here (if he has a link to all of them I'll change to that).

Getting access to the free Connect (aka, Breeze) account

If you're a user group manager, or want to encourage your manager to take advantage of these benefits of having remote speakers, attendees, or recorded meetings, the user group manager should contact the adobe user group program coordinators. All user group managers should know how to reach those folks. I'm just reminding you to do it. :-)

In the meantime, come take a look at my UGTV listing of previously recorded user group presentations, and add any that I'm missing.

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.

Note that I say starting at because there are going to be two editions, with the full-featured version being called Adobe Connect Professional. Many will miss that in the early hours of this announcement, I fear.

Note as well that it's not released today, but will be in November, "as a free trial version through the end of the calendar year. The commercial release of Acrobat Connect, initially available in English, is expected to be available in early 2007," according to the press release.

The base version is limited to just one meeting room, and to a maximum of 15 participants, which is still fine for many needs. Further, it will NOT include audio (which means you have to use the phone and a conference call for audio), and it will not include the ability to record meetings (important for some), among other things.

Adobe outlines all the differences in a comparison of the two editions.

Still, the base edition does include screen sharing, chat, and more. And even for 15 people it compares very favorably to other solutions in that space, such as GotoMeeting, which I've long favored because of its more reasonable price. Breeze, or I mean, Adobe Connect, will give that a serious run for its money.

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 the presentation title and description:

Understanding SQL Server 2005 ReportBuilder

You may have heard that SQL Server 2005 offers a new ad hoc report building capability. What's in it for you? How do you use it as a developer or DBA? What does it give to your end users? Or how might it help you or others in-house in building reports more easily--even if never exposed to outsiders via Reporting Server? In this talk, veteran IT developer, DBA, and speaker Charlie Arehart will introduce the new reporting capability, including the Report Builder tool, and the process of creating report models in the Business Intelligence Development Studio. More than just a quick walkthrough of basics, Charlie will share his hard-earned experience deploying the tool in production, including some hidden gems that may aid those with experience already using these tools.

Having doubts about whether the talk or solution suits you? Perhaps you've not yet installed SQL2k5, or you just aren't ready to convert your have SQL2k5 installed? No problem. The tool can report against SQL 2000 databases. Just allocate a new box on which to install Reporting Services. What if you have no intention of letting customers "report against" your data? Well, it could still be useful for some in your organization who won't be up to the more developer-oriented Visual Studio Report Designer. Finally, what if you've just never gotten into the whole Reporting Services thing? Again, no problem. You don't need any prior experience.

For more information on other talks I have given (and can give), see my presentations site:

http://carehart.org/presentations.cfm

(For those who are curious, CodeCamps are free, community-run but MS-sponsored conferences that are typically one or two weekend days (typically annual or bi-annual). As my talk here shows, just because it's an MS-sponsored event doesn't mean that CF developers won't get value. Talks are as often on .NET and ASP.NET as on SQL Server, Visual Studio, Atlas, SourceSafe, and more.)

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 am open to presenting it again to other groups, live or remote (and will be creating a recorded version soon). Drop me a note if you'd like me to present to your group.

Here's the topic title and description:

Step through your CFML code with FusionDebug

In this talk, veteran CFML developer Charlie Arehart will introduce and demonstrate the ability all ColdFusion developers now have to step through their code interactively. FusionDebug is a commercial plug-in for Eclipse (www.fusiondebug.com) that gives you that ability. No, it's not free, but it's a small price to pay (under $300) if you want to do step debugging. Charlie will show all the features, as well as some tricks and traps.

Don't worry if you don't care for Eclipse. You don't need to use it for editing. You can continue to use DWMX or CF Studio/HomeSite+. Just use FD for your debugging. Charlie will show you how easy it is and the problems it can solve.

And if you're thinking you don't need interactive debugging, Charlie will also explain over a dozen benefits this offers over traditional CFDUMP/CFOUTPUT debugging. Finally, he has also arranged with the vendor to give away 2 free copies (there is also a free trial).

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.

In this entry we'll actually see how things work. Fortunately, the guys at Intergral have done a great job creating plenty of screenshots and Captivate videos that help you readily see how it works. What I'd like to do is first use those to show how you use it and I will save how to configure it for the next entry. Entries beyond that will show some features that go beyond the basics.

A Challenge To Note
Some of you may have already used step debuggers before, while others will be new to them The challenge in presenting this topic is speaking to both audiences. Indeed, as has been discussed in the previous two entries (and in comments from other folks there), there's a degree to which those with prior debugging experience might sometimes even give FusionDebug short-shrift by their assumptions about what it can or can't do.

If you've not yet read those entries, please do go take a moment to do so now. It's one thing to appreciate how FusionDebug works--it's another to appreciate why you should care. :-)

So What is a Step Debugger?

If you've ever wished you could watch as your program executes from line to line, that's exactly what a step debugger does for you. In the case of FusionDebug, it's a commercial plug-in that's added to the free Eclipse editor. Again, even if you don't (and don't want to) use Eclipse (or the CFEclipse plug-in), that's ok. You only need to know a few things to use FusionDebug.

The FusionDebug User Guide does a great job of introducing how to download, install, and configure the product, as well as how to get started loading a file and setting a break point. Assuming you've followed those steps (which I'll go over later), you then have the opportunity to tell the tool that you want to stop execution on a given line of CFML code. This is called setting a breakpoint. You can just right-click on the line of code in the FusionDebug (Eclipse) editor, and choose Toggle Line Breakpoint.

Stopping on a Breakpoint

When that CFML template is requested and that line of code would be executed, the program will halt and the FusionDebug interface would reflect that execution has halted. It will open the file (if it's not already open) and show the line of code on which execution has stopped:

The blue dot to the left of the line shows where a breakpoint had been set, and the blue arrow and shading on the line indicates that control has halted on that line. (The browser in which the page had been requested will generally appear as if the request is just taking a long time.)

Indeed, a really cool thing about the way FusionDebug works is that it can intercept the request from any user, not just the user who has initiated the debugging session. This is a two-edged sword:

• it means that you can use it to intercept a request other than one you yourself initiated. How often have you tried to understand why a problem was happening to a user in production, but you couldn't recreate it locally? Or, as I noted in my last entry, it can also intercept a request via web services, or Flex, Flash, Flash Remoting, or Ajax.
• The problem, of course, is that it also means that anyone on that server being debugged will be affected when you set a breakpoint. This certainly speaks to taking caution about setting breakpoints in production. Still, it's nifty that can. With power comes responsibility.

Observing Program State Information (Variables)

Being able to stop the program in its tracks may seem only mildly interesting, but the real power comes in the fact that while you are stopped at a breakpoint in the debugger, you can learn a lot about what was going on in the program at the time. For instance, you can see all the variables that may have been set (either in the program or perhaps as set in other templates before this one executed).

FusionDebug provides a "Variables" view, which in the case of the code above would show the following:

You can see that a structure with a key and an array has been created. Note how you could expand both the local "variables" scope as well as any application, session, server, and other scopes. Indeed, if we were stopped within a method (CFFUNCTION or CFSCRIPT function), we could also see the local ("var") and "this" scopes. Isn't that a whole lot easier than putting in CFDUMPs, CFOUTPUTs, etc.? And having to remember to remove them? And as I talked about in the last entry, there are simply situations where you just can't use CFDUMP or CFOUTPUT.

If you had a large number of variables that would make it tedious to explore this Variables view, yet another option available is a set of "watched expressions". This is even more like using old-style outputs, except they never send output to the browser. Instead the results are shown inside the debugger. With this other "Expressions" panel, you can choose to watch any variable or expression. (An expression can be anything you might put on the right side of the "=" of a CFSET, or in a CFIF condition, including variables, functions, and so on.) Here's an example:

You can enter expressions by right-clicking in the Expressions View, selecting Add Watch Expression, and typing in the expression manually. Even nicer, you can highlight an expression in the code editor, and right-click and select Watch Expression:

Setting Variables On the Fly

Perhaps one of the most compelling things about step debuggers is that they permit you to do something you simply can't do in your code (once the program is running): you can alter the value of any variable while the program is running. All you need to do is right-click on the variable in the code editor and choose Set Variable. You then indicate the value to set, and (while at a breakpoint) that will take effect for the remainder of the request. Nifty!

Stepping Through Lines of Code

As useful as it is to stop at one point in the program and view all of the above, there's still much more to a step debugger. We're about out of time and space in this entry, but one of the most important remaining fundamental features is the ability to step through your code.

Consider the following code and the display showing it being stopped at the indicated breakpoint:

How do you tell it to proceed? Still another pane in the FusionDebug (Eclipse) interface is an available Stack Trace pane. In it, you will notice some icons at the top of the pane:

These represent the ability to tell the program to continue to the next line of code. Perhaps the most common one to use is the rightmost in the above screenshot, though others exist outside of what's visible in the screenshot. This is called Step Over, and it simply executes the next line of code.

Where all the examples so far have talked about things you can do while stopped at a breakpoint, they also of course apply while stepping through code as well.

Also available are options to indicate whether you'd want to follow the flow of execution into another file, such as a custom tag, CFC, included file, and so on. Note that the screenshot showing the breakpoint above indicates that the next line of code is a custom tag (cf_getEmployee). If we were to use Step Into, the icon left of Step Over, then FusionDebug would open the getemployee.cfm custom tag and stop at the first line of CFML within that. Assuming that was on line 1 of that template, the stack trace would look like the following:

If you didn't want to bother stepping any more within the nested file, you could use an available Step Return button. And if you didn't want to bother stepping any more in any of the files in the request, you can use the left-most of those icons (what looks like an green arrow) which is called Resume. It would let the request run to completion (unless it hit another breakpoint).

As I've said, there's a lot more to show, but this should be enough to whet the whistle of those who haven't explored a debugger before. You can read the docs, see additional features, view videos, and see additional screenshots on the FusionDebug site. Until next time.

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.

Join PASS in Microsoft's backyard for 100+ technical sessions presented by more than 80 user-experts, MVPs and members of the Microsoft development team.

This year, PASS will welcome two Microsoft executives, Steven Ballmer, Microsoft CEO, and Paul Flessner, Sr. Vice President of Server Applications at Microsoft, to kickoff the main event as keynote speakers. Click here for details.

My presentation, "Taking Your SQL Beyond Selects and (simple) Joins", will introduce important features of SQL that will save you time and create more effective applications. You'll learn how to slice and dice data in many ways, including handling distinct column values, summarizing data (counts, averages, etc.), grouping data, manipulating data in the database rather than code, and understanding the value of outer and self-joins.

Join myself and others as PASS brings you an impressive lineup of presentations held November 14-17. Check out all the great sessions PASS is offering and build your own personal itinerary using the Community Summit Personal Itinerary Builder. This helps PASS to see which sessions are most popular among attendees and give YOU the opportunity to see what's available.

There are additional benefits to attending the 2006 PASS Community Summit! As part of your full registration, you will receive access to the entire online multimedia recreation of the event--complete with synchronized audio, slide presentations and demos--at no additional cost shortly after the end of the event.

Having FREE access to the impressive lineup of SQL Server gurus is a great resource and benefit that only PASS can provide.

Register by October 31 and save $300 with early bird rates! Secure your attendance at the year's largest event dedicated exclusively to SQL Server education and networking!

Hopefully you can join me at the Washington State Convention & Trade Center, November 14-17, 2006 in Seattle, Washington. If you have any questions about this event or PASS, contact PASS at [email protected] or 312.527.6742.

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.

Supported versus Unsupported Attributes on CFCOMPONENT, and GetMetaData()

First, there's no NAME attribute listed for CFCOMPONENT in the CFMX docs. If one wants to give a friendly name or description to a CFC, that's the purpose of the DisplayName or Hint attributes instead.

More important, whenever you use any attribute on CFCOMPONENT that's not otherwise supported, the only programmatic motivation would seem to be to take advantage of the fact that a GetMetaData() call against that CFC will return that attribute as a key in its result.

But it turns out there is ALREADY a getmetadata key called "name" that's always returned from a getmetadata call against a CFC, and it always returns an internally generated value indicating the name and location of the CFC, and more to the point, this value returned is NEVER affected by your use of a NAME attribute on CFCOMPONENT.

Curiously, I do find that different versions of CF and BD return slightly different values for that (more on that in a moment). And for those who may wonder, neither the use of NAME nor any unsupported attribute affects the output of the CF Component browser.

That's why I'll argue you shouldn't be using NAME at all. It not only does nothing (is not returned by getmetadata), but it may lead someone to be confused that it should. I don't know if I will go so far as to propose that CF (and BD) should raise an error when it's used. Sadly, a google search for "cfcomponent name" shows hundreds of pages using it (and those aren't real code running on people's servers but instead code people are sharing on the web for demonstration purposes), so restricting that could have a lot of impact.

If one wonders how people started using it, I'll note that (sadly) the CF7 docs user guide section on "documenting CFCs" does shows using the NAME attribute. I will leave a comment there pointing to this blog for folk's consideration (and perhaps to get Adobe to remove that, if all this observation holds true).

Further, the person asking me about this did so because they noticed that the CFEclipse CFC wizard also implements the NAME attribute in CFCs it creates. Again, unless comments to this suggest otherwise, it seems that perhaps that should be changed.

I am open to hearing from others. It sure seems that all is as I see it, but if I've missed something, I welcome comments below. If there is any egregious problem or misunderstanding I've created, I will offer a follow-up entry to correct things.

What getmetadata's NAME key returns on different CFML engines

I mentioned above that if you use GetMetaData against a CFC instance, it does return a NAME value. What does that value hold? Well, the docs for CFMX 6.1 simply indicate that it's "the component name", with no further explanation. The CF7 docs reference on GetMetadata does elaborate further, now saying that it's the "Component name, including the period-delimited path from a component search root such as the web root or a directory specified in the administrator Custom Tag Paths page."

I mentioned before that I'd found differences between the two versions of CF as well as between editions of BlueDragon. Here's a demonstration. I setup a simple test hello.cfc file in a /demo directory off my webroot:

Note that in the CFC I have set the value of NAME to "hellox". I did also test it using simply "hello" or "hello.cfc", and it made no difference at all in the following results. I then called it with a template that used Getmetadata:

The dump of the getmetadata result always showed a NAME key and it was always the same whether I provided one or not, and regardless of what value I provided. But there was a slight difference among the engines, which showed the following values for the getmetadata name key:

The big difference is that CFMX 6.1 does not show the location of the CFC as found, just its name. Both CFMX 7 and BD show the directory name in which the CFC was found, as explained in the CF7 help above. This value can be useful for times when you wonder which CFC you have found on an invocation (since both CFMX and BD have a variety of search locations that they use), although note there is also a "path" key returned by getmetadata which returns the absolute rather than relative path.

You'll note I've put an asterisk next to the BDJX test. To do this testing among the 4 engines, I'm running on Windows XP with IIS, so I can't have multiple web sites. (Yes, I know about tools to get around that and that Apache would let me have multiple sites.) Instead, I setup multiple virtual directories, each pointing to the different engines (as I document in a CFDJ article), so that I could call the page invoking the CFC using each of the different versions of CF and BD. On my laptop, I use virtual directories named _cfmx, _cf7, _bdjx, and _bdnet (so calling my demo page above might be http://localhost/_cf7/demo/invoke_hello.cfm.) I was surprised to find that in BDJX (only), the resulting name key returned did also show the name of the virtual directory as a prefix to the value returned, so the getmetadata name value returned by BDJX in my example was _bdjx.demo.hello. Of course, you won't see that difference if you don't use virtual directories.

Those who delight in the discover of the new value returned in the pre-defined getmetadata name key may find the above details useful. The more important point, again, is simply that the use of a NAME attribute on CFCOMPONENT has no programmatic purpose at all. It's not a supported attribute, and unlike any other unsupported attribute, it's not returned by GetMetaData, so it seems it should not be used at all. Let me know if you think otherwise.

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'd like to address that sentiment in this entry, showing the many ways (13, to start) that interactive step debugging can indeed be a valuable tool in the arsenal of a CFML developer, to solve problems they might otherwise find very difficult.

(I fear that if I instead proceeded with taking the time to first show the tool, some would stop listening because they have preconceived notions of what it is and can--or can't--do. More than that, I bet some will be surprised that it does things they never expected were possible, whether that perspective was formed by their work with debuggers in other languages or in the CF4/5 debugger.)

You can't always do a CFOUTPUT/CFDUMP

As others have commented, a first reaction some may have is that they can do all the debugging they need by using judicious (or indeed copious) CFOUTPUTs and CFDUMPs, or perhaps CFTRACE or CFLOG.

One problem, though, is that there are places where you can't create output.

For example, within a CFC or method where OUTPUT="no" has been set, CFDUMP and CFOUTPUT create no output. Now, you may think, "well I can just disable it," but there are times when doing so will introduce errors or otherwise unexpected results.

Another situation in which you can't create output is within CFSILENT. No output is rendered to the browser. Especially in complex apps and most frameworks, it's common for CFSILENT to be used, and you will have to find and edit the file that sets that to disable it while you do your debugging. There may be a negative impact by disabling the CFSILENT as all the code between there and what you're looking at executes.

Finally, you'll also need to remember to set all those changes back. (More on that later.)

You don't always have a browser to output to (Flex, Ajax, Web Services)!

The point above was about whether you could or could not use CFOUTPUT/CFDUMP. Beyond that, what if you're writing CFML code that is called by a Flex or Ajax client, or that's called as a web service? You can't then always reasonably add debugging output--and you certainly can't do a CFDUMP, if the client is expecting XML, since CFDUMP creates a big HTML table.

FusionDebug can indeed be used for debugging requests from Flex, Ajax, or web services apps. Indeed, it can intercept a call from any kind of client that requests a CFML page or CFC. More on that in a moment.

Now, some may point out that you could in such a case use CFTRACE or CFLOG to write out such output to a log file, and that's so, but it's certainly not as simple as dumping output to the screen.

You can intercept and debug a request from any user, not just the developer

This is a very important point, and actually is an extension of the point above. Unlike the CF4/5 debugger, FusionDebug is NOT limited to only debugging what you as a developer can browse yourself. It can intercept and show to the debugging developer the step-by-step execution of any template or CFC (or custom tag or included file) run by anyone in any manner. So you can use it to debug when someone else is running the request (where writing output to the browser would go to someone other than the developer). I know that may sound a warning bell to some. Hold that thought for a moment, and through the next couple of points.

You can debug a remote machine!

This may be the most powerful feature to some. FusionDebug can do debugging against any CFMX server for which it's been configured. It doesn't need to be just a CF server on the same machine running Eclipse. Not at all.

In a comment in my last entry, developer Tony Petruzzi said, "I believe that if FD had a remote debug like VS.net does, then it would be more appealing. Most of the time you need a step debugger when something totally whacky is happening and usually this occurs when the application is in production."

Well it does indeed do that, and his comment leads to yet another benefit.

You can debug against production!

As stated above, often the challenges you face are ones that you can't recreate in your development environment. Because of its design, there's absolutely no reason you couldn't do debugging against a remote server (production) and with the real end user running the request that's causing the problem you want to debug.

Of course, the above three points represent a two-edged sword. You can't currently limit the debugging to take place only for a given user, so if indeed you are using it on a server being used by multiple users, it will impact anyone who makes the request while you have debugging enabled.

Again, there's much we've not yet discussed on using the tool, so let me be clear: for this to happen, a) a developer would have to have opened Eclipse with FusionDebug, b) turned on debugging against that application/project, c) enabled a breakpoint for a given template, and d) the user would need to request that page and run through that code that would hit that breakpoint. (I'll discuss the details of enabling the debugger and setting a breakpoint in future entries, or it's discussed on the FusionDebug web site).

In such a case, a user would see the page appear to hang until the developer with debugging enabled responded to let the page proceed. I don't say this to scare you: it's just a responsibility to be aware of that comes with the power of the tool. (There's also some modest impact in configuring the server's JVM config to support debugging, so you may want to think carefully about leaving it enabled all the time in production. Again, I'll discuss this point in more detail in a later entry.)

There's no need to change code to get debugging info

With the previous points focusing on some of the unusual and surprising aspects of where and when you can use the tool, I don't want to lose sight of a very important point, perhaps too easy to miss. While some would argue they could just throw some CFOUTPUT/CFDUMP tags in to the code to do debugging, that's clearly less palatable to do in production.

Or perhaps you are doing debugging against some code that someone has ruled that it should not be touched (edited), or it may well be in a directory where you don't have access to edit the code to add any debugging tags. Or, as was discussed in one of the first points, even if you DO disable CFSILENT or the OUTPUT attribute of a CFFUNCTION of CFC, you have to remember to re-enable those when done debugging.

This calls for clarifying a key point: FusionDebug does not require that you edit the code. Again, we're a little ahead of ourselves if you've never seen a debugger and don't understand what setting breakpoints is about. Take my word: it's trivial.

You don't need to be able to enable CF's debugging output

Related to the above points, it's worth noting that by using FusionDebug, you don't need to enable CF's debugging output. Again, whether in production or simply on a server where you've not got control to get debugging turned on, this can be a valuable benefit.

You can change the value of variables on the fly during execution

Still another cool feature of step debuggers (in general) is that they permit you to change the values of variables within the code being debugged, such that on the fly, while the code is running, you can change the behavior of the app should you need to. This sort of thing can be easier than changing the code to effect that changed value (recall the previous point about how you may not even be able to edit the code to change a variable manually).

Sometimes a simple CFOUTPUT/CFDUMP will not suffice to solve a problem

Since we haven't shown how to use the tool, you'll also have to take this on faith: the features for viewing the current state of the application are also very powerful. While you're stopped at a breakpoint, you can view the value of ALL variables in ALL scopes. FD presents a very easy to use tree view to traverse and view the scopes. This also includes query resultsets (with still more unique features) and more.

And since you can view them all, you may be able to see information or make connections that you might not have thought to dump or output with traditional approaches.

You can use the debugger to understand the flow of execution of the request

Still another truly unique feature of a step debugger, that has nothing at all to do with outputting variables, is that they give you a clearly visual representation of the flow of a request. If you're ever wondering whether the code went into one IF statement or loop, or indeed if it included a file or called a custom tag or called a method in a CFC, these are all things that you can readily see in FusionDebug. Again, we haven't showed it in use yet, but we will in later entries see how it visually shows as you step from line to line or into nested tags, include files, custom tags, CFCs, and so on.

Further, the tool opens each such file as it is requested, so you may not even readily think of or see what files you would need to open if you did want to put manual debugging statements into them. That leads to one last point...

You can debug in situations where you don't even know where in a complex app to try to do CFOUTPUT or CFDUMP

That aforementioned feature of opening files as you step through them, and following the flow of execution, can be especially valuable in very complex applications. Let's consider (just as one example) a Model Glue application. When I run the modelgluesamples/legacysamples/contactmanager/index.cfm and view the files in the debugging output (showing all the files that were used to render the request, including CFM and CFC files and methods), there are nearly 150 shown. If something's amiss, you may be hard pressed to think where to begin.

For now, FusionDebug lacks something that the CF 4/5 debugger had that would make this last point especially valuable. That tool had a wildcard breakpoint, or what may be considered a conditional breakpoint: it would stop when a given condition was met. That's SO valuable. You can use it to find out when some condition arises (such as when some variable obtains or exceeds some value, or is set at all, or when some query exceeds a given executiontime--using cfquery.executiontime, and so on.) I have requested this latter feature of the FD team, and we can hope it may make it in the future. I have some other wishlist items which I will list in a future entry.

You can view the stack trace during execution

Following on to the previous point, while the traditional CF debugging output shows at the end of the page request what files were called to run the entire request, it doesn't really help you to know which were opened just to get a a particular point within a given template or CFC method. In FusionDebug, while you're sitting at a breakpoint, you will readily see the stack trace showing what files were opened to get to that point.

You can view the Java classes called to execute your code

Called the "java detail mode" in FusionDebug, it's an option which (if enabled) will show you all the java classes and methods called both to get to that point and which represent the kind of data in variables currently set. Indeed, if you double-click on a java class shown, it will show you any variables that were created from that object. For more info, including a screenshot with quick and easy explanations, see the FD site page for this feature.

Conclusion

That's a long list of reasons and benefits, and it's not even all of them. I just came up with these off the top of my head, wanting to help address the concerns of some who would dismiss the value of step debugging. There will surely be comments from folks on both sides of the fence (supporting it, dismissing it), and perhaps more info will be shared by others elsewhere. Let's get the conversation started.

So again, here is a summary of 13 things you can do with FusionDebug that I argue can't be done easily otherwise:

• can debug when a CFOUTPUT/CFDUMP may not be possible (CFCOMPONENT/CFFUNCTION OUTPUT=false, CFSILENT)
• can debug without having to rely on finding the output of CFLOG or CFTRACE (or enabling the latter)
• can debug requests from Flex, Ajax, or as web service
• can debug when someone besides the developer is calling a template
• can debug against production
• can debug on remote machine
• can debug without needing to change code
• can change the value of variables on the fly during execution
• can debug in situations where a simple CFOUTPUT/CFDUMP would not suffice
• can use the debugger to understand the flow of execution of the request
• can debug in situations where you don't even know where in a complex app to try to do CFOUTPUT or CFDUMP
• can view call stack during execution
• can view the Java classes called to execute your code