Shooting the trouble

I would say that about half of my day is spent troubleshooting code.  It’s not that we necessarily write bad code, it’s just that we don’t always write the most efficient code, or as humans, we make mistakes.  It’s not uncommon to spend hours trying to figure out why a piece of code doesn’t work, and finding the solution in a missing piece of punctuation.  For those of you non-coders, you may laugh and think that it’s ridiculous, but for those of us who write the programs you use, uh, yeah, you get it.  Even better is that as a Coldfusion programmer, I not only need to know Coldfusion, but I also need to have a pretty good grasp of whatever Javascript library the designers throw at me, as well as css and html.  Something that shows up on the screen oddly could be in any combination of the browser, server, or code, and the code could be from any number of the languages being used in the particular application.  It usually doesn’t take long though to narrow down what’s at fault, and then it’s even trickier to figure out what’s gone wrong and how to fix it.

My goal as a programmer is to understand the languages I use most commonly and to continue to grow my knowledge within the languages and within the technological world as a whole.  Since there isn’t much time left in the day to do this when all is said and done, I have to pick and choose what I learn.  My latest learning adventure has been about SeeFusion, which should in time help me write better Coldfusion application code by determining wasteful behavior.  Alongside that, I am continuing to dive deeper into the language of Coldfusion and the tags that are available to me.  Two tags that I plan on spending some quality time with in the near future are CFTrace and CFTimer.

Traditionally when I am debugging a Coldfusion application, I write my code, upload the page, test and see what comes back.  If I get an error I have to go through the short process (sometimes) of figuring out why the error happened.  If there are no visible errors, but the output is not showing what I think it’s supposed to, that’s the bigger issue.  CFTrace should be able to help me out there.  Normally what I will do is throw in a CFDump to dump out my variables to the screen so I can find out if they’re being set correctly.  CFTrace can do the same thing, only I can set it so that it does not throw out stuff inline.  This could be handy for situations where I need to keep the output looking one  way, but then show a bunch of information at the bottom of the screen showing the progression of a variable.  It can also pop information into the logs if I need it to.  This would be very handy if I’m in a CFC where I don’t get output.  Then I can specify where I am in the logs, to keep a constant watch as things jump from function to function.

So, since I’ve spent enough time talking about it, I have to get down to making it work.  Next week I’ll give up some code and talk about further helping applications move along with cftimer.