FusionDebug Part 1: Why get excited?
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.Since the announcement of FusionDebug a couple weeks ago, there's been relatively little other news or blogging about it. I think that's a real shame and I'd like to address that here in a series of entries introducing you to it, and sharing tips and traps.
I've just given a talk tonight at the Atlanta CFUG (which I'm open to presenting to other groups via Breeze, if not on-site should I be traveling there for other reasons.
Over the next few entries here I'd like to share some of the points I did in the presentation. I'll cover such things as FusionDebug features and some gotchas to watch out for, as well as answer some frequent questions.
But I'd like to start with why I think people should be excited.
What is interactive (step) debugging?
What do we mean by interactive or step debugging? It's not about the debugging output at the bottom of a CFML page. Instead, it's about single-stepping through the code line at a time, while being able to watch the values of expressions and variables--and even change variables on the fly.
Where do you stand on using debugging?
Have you ever used an interactive (step) debugger? They are common in other languages (Java, .NET, Javascript, Flex, Flash, and more). Since many CFML developers have not used those, they may not even miss a debugger. Similarly, there are some who know about them and still are not excited about them. To each his own. I think that most will indeed find value once they've used it.
Many don't know it, but there was indeed interactive debugging in CFML in CF 4 and 5, by way of CF Studio (or now HomeSite+). In a future entry I will talk about how you can demonstrate and use that (with CF4 and 5 only). But Macromedia/Adobe chose not to carry that feature forward into CFMX, so FusionDebug represents the first and only current way to do step debugging in CFML for CFMX (6 and 7).
As a commercial product, you can also take consolation that it will indeed work as advertised and if it doesn't that there will be a company behind it to help support, improve, and evangelize it.
About FusionDebug
FusionDebug is an Eclipse plug-in. Just like FlexBuilder is a commercial plug-in on top of the free Eclipse framework, so too is FusionDebug a commercial plug-in on top of Eclipse. It's priced at US$ 299, with an available 10% discount code (CFCOMMUNITY) as well as volume discounts. There is also a free 20-day trial. Your first response may be that you don't think you should have to pay for such a product, but with no debugging tools seemingly on the horizon from Adobe, it's really a rather small price to pay if you will benefit from debugging.
Your second response, if you don't use Eclipse currently, may be to worry about having to use it. First, note that you don't need to give up your favorite CFML editor (DWMX, CF Studio, HomeSite+, CFEclipse, or whatever). Further, it's easy to learn how to use the minimal amount of Eclipse functionality you need to understand to use FusionDebug.
You do need to download Eclipse (which is free), unless you already have it installed (for instance, if you have FlexBuilder or CFEclipse). The FusionDebug User Guide explains how to get and install it (which is very easy).
It also requires just a minor change in the jvm.config file for the CFML server that you'll be debugging against (again, easy to do as well-documented in the User Guide). Here you indicate a port that the debugger will listen on, and you then do a minor setup in Eclipse to enable debugging against that server (again, well-documented and simple).
In the next entry, I'll actually introduce the features that FusionDebug enables. In the meantime, if you're too excited to wait, you can can read about the features, including screenshots, or you can even view some Captivate videos.
In future entries, I have several hidden gems and gotchas that I'll share.
As for step debugging, I think it's worthless. I haven't used a step debugger since I was a novice Pascal programmer back in the 80's. Actually, I tried them again in the 90's with C++ but still found them worthless.
I saw the announcement about this a while back and it did raise my interest. When I read the installation steps, I was somewhat put-off. After all, I had step debugging way back in the day (CF 4.5 or what have you) and tried it a few times but never found any value in it.
To be honest, Sean's comment is a relief. I just thought I was too dim to see the value.
That being said, I am curious to see what value a tool of that kind can offer.
Did the folks from Intergral identify the cause and solution to that problem? I'm sure they'd want very much to help. I do so hope you didn't just keep the problem to yourself in disdain. You and i both know that people have done that with CF (and BD and every software product), and while a sense of indignation offers some consolation, it does nothing to make the vendor prevent the problem happening to someone else.
Further, if such a problem is not reported, neither you nor the vendor knows how often it's happening (are you the only person to whom it's happened? Or does it happen to many who also have not reported it?) Let me say also that of course you may well have already reported it, which would be great. I'm sharing this response more for others who may also have problems with this or any software product. As the saying goes, "it's better to light one candle than to curse the darkness".
I hope things can be resolved for you, and I hope all the more that your bad experience won't happen to others--nor taint their interest in giving it a try. Such a threatening sounding experience could really scare others off. Just as we wouldn't want one bad experience for a CF user to be held against the product as a whole, I hope you and others will consider the same with FD. As I was going to write about in a later entry, my experience with them and their support so far has been stellar.
As for Sean's comments, I sure do hope that people don't take too much consolation in his disdain. Seriously: we all know that some hold one framework in ill esteem (or the use of them at all), while many others will laud and praise another (or any at all). In the same regard, I really do hope people will give this a serious look.
As I said in the entry, and as you alluded to, we had CF debugging in the past, and some couldn't get it to work well, which soured their experience. I'm sure it's just a matter of time before people will begin to identify clear and obvious situations where step debugging was about the only way (or clearly the more effective way) to solve a problem. I have some in mind already, and will write of them in future entries.
In the meantime, I hope all will try it for themselves--and to those who may fear Sean's experience despite my hope that it's an isolated incident, here's something I didn't think to mention in my last comment: just create a new installation of Eclipse, rather than try to install it into an existing one. Installing Eclipse is drop dead simple (there's not even an installer, you just extract the zip into a directory). Once you're happy with it, then you can consider installing it also into your main Eclipse build.
Hope all this is helpful to some.
As a side note to Charlie's post - another good way to learn Eclipse, but more focused on CFEclipse, is the ACME guide from Stephen Collins:
http://www.stephenco...
This is the best darn PDF I've read in my life - in terms of usefulness I mean.
Honestly I don't remember for certain what the steps were. I believe it was the JVM configuration. I work with a variety of clients in different hosting situations (including shared) so I would effectively have to copy code to my local server to take advantage of the step debugging.
If I recall correctly, I was able to get the debugger in ColdFusion Studio working, I just didn't find a situation where it gave me any more benefit over cfdump (obviously not available then) and cfabort.
Again, none of this is to say that I am closed to learning more about step debugging or this product in particular. I am very interested to read more about it and perhaps find a way to get value of the approach that I haven't so far.
Integral does also provide very good support. While evaluating FusionReactor I had a few questions and they weren't afraid to give me the very low level details I was looking for without having to prompt them with a lot of questions.
However... I too have never found a use for step debugging outside of Assembler. It's nice to see what memory registers are doing when you're coding that closely to the hardware, but otherwise I can't say I've ever been in a situation where it's been handy in other languages I've used (C, Java, Python, CF). I think this is especially true with good OO programming.
Perhaps if there were something that could visualize concurrency interactively and point out threads stomping on each other via shared variables, but that's a whole different ball of wax.
What I would like to know is what benefit do I get from using FD as apposed to just using cfdump to dump all the scopes at the bottom of the page? I can see using a step debugger in .Net since the errors code can sometimes be totally confusing, but I have never encountered an error in CF that didn't give me a clear description of what exactly the problem is and where it was.
I think one of the big stumbling blocks to using FD will be the configuration of the JVM. 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.
I just wanted to clear up that Sean did contact us and we have been working to understand the issue. This has been the only reported case of FD causing an issue in Eclipse from all of the downloads so far. Should any such issues arise further we will of course do our best to resolve them as quickly as possible. Thanks to everyone for their comments and inputs.
It seems like this can only be a good thing to make CF even easier to use. I certainly appreciate hearing about bad experiences with installation and configuration, but I don't really care who likes the idea of a step debugger and who doesn't, because I know there would be value in this product for me. Thanks for the prompt Charlie. I'm definitely going to check it out, and look forward to future posts on this topic.
I'm also one of the people who got the debugger working in CF Studio only to try it and go "I just don't see what the big deal is". Since most CF'ers have never had access to a debugger, seeing someone using it might be the catalyst to get people thinking. Just my 2 cents.
Further, I do plan to record my presentation where I do demo it. As you say, I can see when I present step debugging to people that for many, it's a total eye opener.
FWIW, and in response to several people commenting here, I thought the installation instructions were crystal clear and pretty simple for something as "intrusive" as FusionDebug so kudos to Intergral for that.
In response to Brandon: I find Eclipse to be rock solid and this is only the second time - in several years of use - that a plugin has caused me problems of any note. And that includes when I was actually building some plugins of my (and running builds of CFEclipse from source using the latest code from the repository!).
Since my comment was a bit of a drive-by shooting, I should probably elaborate on my "disdain" for step debuggers.
If you have no idea where in your code a bug is, you're going to have to step through a *lot* of code and watch pretty much every variable in order to track it down. That just isn't feasible for large, complex systems. On the other hand, if you have some idea of where the bug is, you can zero in on it very quickly with a few judicious cflog or cfdump tags - even in a large system. And, of course, if you have a small system then you don't have much code to either step through or fill with cflog / cfdump tags (but if you have a small system, you have less code to find bugs in anyway!).
What I think we really need as a community is more information about how to become better at debugging our code - without that basic understanding, no amount of tools can really help.
Had they somehow made you put in new JARs that overrode those in CF or something more heavyweight, one might agree, but this seems remarkably lightweight and decidedly unobtrusive--especially in that it came from a company that did it all on their own.
As for the experience of Eclipse plug-ins and their corrupting them, besides Brandon's experience I will add that just today I heard this week's ColdFusion Podcast where Bryan and Michael were talking about how the use of the Subclipse plugin had corrupted their Eclipse environment, so it's clearly something that can happen. The FD one seems pretty simple, so it would seem this was indeed unique (and Darren's own confirmation based on all the downloads so far seems to confirm that.)
As for the initial comment being something of a "drive-by shooting", I'll concur that it's what it felt like. :-) Thanks for the clarification of your perspective. I have some thoughts of my own to help justify where I think a debugger can help. I hope that discussion from that or this (or others' entries) may help spur a discussion to help everyone learn what makes the most sense for them. Until then, I hope folks will have an open mind.
Just to be sure, though, I do copy my entire eclipse-installations, eclipse-workspaces, and eclipse-extensions directories in their entirety to backup folders on a semi-regular basis. This way, just in case something goes horribly wrong, I can get back to a known point without the hassle of rebuilding everything.
Sure when you're starting a project maybe you don't need to use it all the time; but as someone else (sorry too lazy to find who it was!) said it's great for seeing exactly what's going on and where you've accidentally set the wrong variable etc...
As a senior developer I also find it very useful for training others in what CF is actually doing. Especially when developers have come from a Visual Studio or other step-through debugger type environment. I find it's a lot easier to show a new developer what's happening line by line with the ability to show variable contents etc as it's being executed rather than explaining final outputs.
Sure there's the "why don't you just put cfdump/cfoutput/cfabort all through your code?" question but who wants to do that when there's a tool thats right there in your IDE?
Just my 2p... Comments appreciated
That was more than a drive by shooting... more like an IED. I sure hope that wasn't the "Kiss of Death" for Fusion Debug.
1) Simply stop offering certain types of code example and advice.
2) Being more controversial.
That's led to my reputation for saying "It depends!" - I'm just trying to get people to think for themselves a bit more. I don't want anyone to just slavishly follow anyone's recommendations...
When I get time (hah!) I'll rebuild my Eclipse environment from scratch and try installing FusionDebug again and if I can get it working successfully I'll write about it (which was the whole point of trying to install it in the first place!).
Clearly, from the comments here, some people *do* have problems with Eclipse and plugins and *are* concerned about modifying JVM configuration. I hope some people *do* find FusionDebug both easy to install and useful - the Intergral team have clearly put a lot of work into the product - but at the same time, I also overheard negative conversations about the preview at CFUNITED so it really is a case of caveat emptor.
But I will say I do favor "sharing" over "scaring". :-) In that regard, I hope any who had such negative conversations have taken their issues to the vendor, rather than just keep their experiences to themselves (as I said in the first comment above). Since Intergral is reporting that only one such occurrence has happened, it's imperative that any with such experiences report them so they can be dealt with, rather than speculated or rumoured upon.
And as for saying "it depends", I'm totally with you. I'm not at all saying that everyone should be using the tool, but I do think everyone should give it more serious thought and attention that it seems most have (judging by the blogosphere and [lack of] mailing list traffic I've seen). I certainly don't expect anyone to "slavishly follow" that recommendation. I'm just trying to sincerely motivate them. That's all. :-)
If you're lucky enough to have a veteran ColdFusion developer introduce you to cf, then I can imagine a scenario where the developer would install Eclipse on your computer, install cfEclipse, install Fusiondebug and then say "OK, now let's start learning ColdFusion."
But if you are like most people - on your own (and most learning is done on your own), then the scenario goes quite different. The first thing you do is start playing with the tags.
"Now let's see:
cfset x=1, check.
cfoutput x, does it equal 1? check.
cfinput X, does it equal 1? No. Why not?"
It would be nice to have an editor that showed the difference between variables.X and FORM.X, but I don't think the first thing a cfPadawan will do is download a plug-in for an open-source editor that isn't mentioned in any of the adobe documentation.
Especially when they're struggling with why "LET X=1" isn't working.
If instead your indirect point is more to wonder whether and why Adobe does not offer debugging, well, it's not a new discussion. Debugging was dropped in CFMX because the sense then was that there wasn't enough interest. I argued that it was more just that people didn't know it was supported by CF Studio in CF4 and 5, but the decision was made.
Given now the rather tepid response to FusionDebug so far (and the clear antagonistic sentiment of some toward debugging in general), I don't think we should hold our breath that Adobe will come out with one.
Further, if the tool does the job well and couldn't be much improved (and Intergral are already working on their own improvements), and especially if Adobe didn't also give away any debugger they'd make, there just seems little motivation for them to bother.
But we can't know how the future will unfold. Until and unless Adobe does do such a debugger, let's simply celebrate, enjoy, and benefit from the fact that we do now have FusionDebug. :-)
I just wanted to correct the record to say I have *not* praised SeeFusion!
However, FusionDebug still won't connect to the localhost JVM :(
I'm in communication with the Intergral support folks...