Rob's Ramblings

This post is one of those where I am hoping somebody can provide me with some assistance.

I have been using CFBuilder on Snow Leopard for months now. I love it. I especially love the server consoles, the tailview, and the RDS services. The only thing I have not loved about it are the occasional crashes, but I expect it from beta software.

In the last week however, they have become more than occasional. They have become regular. CFBuilder constantly is hanging, eating up all of my CPU, and giving me constant Java Heap Space errors. Ususally it's trying to build project settings or index projects, and I can let them go on for literally hours at a time and nothing will happen. I've had to Force Quit CFBuilder numerous times now.

I went so far as to uninstall it and do a fresh install, no avail.

If anyone has some things that could help me, I would be appreciative. I'm back using CFEclipse, and it's just not the same for me.

Okay, the title is meant to be facetious, and attention grabbing. Just so we're all on the same page. But it's not untrue.

Through Ben Nadel's fantastic blog, I learned the practice of creating and scoping a LOCAL struct in a CF function (CFMX7 and CF8), and assigning any other local variable created in the function into that struct. That way I did not need to manage multiple variables, trying to make sure they were all locally scoped. It seemed more efficient.

Well, with the migration of my VPS to CF9 (and the impending upgrade of my work's servers to CF9), I found blog posts talking about how others that had used this practice were finding oddities with their code upon upgrading. It seems that this practice was somehow colliding with the new protected "local" scope within functions in CF9. The new scope allows coders to do exactly what I was doing, only without having to scope that local struct first.

In trying to figure out what changes I needed to make, I went asking around trying to find out if this meant that we no longer had to scope local variables anymore inside of functions, if unscoped variables would automatically get put in the new local scope. To hear and read the documentation, you certainly could come to that conclusion.

Thanks to Ray Camden, I have been straightened out. It turns out this is not the case, and I am not the first to ask him this. He was kind enough to make this topic an entry in his just as fantastic blog.

Bottom line, you don't have to scope things put in the local scope, but you must explicity call the variable in the local scope (local.myVariable). And all other variables must still be scoped for protection.

On a legacy application that I maintain, I have seen a rash of errors recently that are new. They are all in regards to form fields missing on a form action page. The things that make this one different is that:

1. The fields in question are empty text fields, not unchecked radio buttons or checkboxes.
2. The browser type of all these errors in Google Chrome

Now, while the fix is the same for all of these issues (CFPARAM the form fields), I was wondering if others have been seeing this with Chrome at all, and if there's any insights as to why Chrome seems to not want to pass along empty text fields, like every other browser out there does. I have not played with Chrome at all, and our applications do not officially support that browser at this time, so I can't spend much time at all investigating these errors in light of that. So I am hoping that some of y'all might have some information you would be willing to share?

So my blog has gotten a little dusty, this is going to happen from time to time. This is beginning the my busiest time of the year annually at work, and I also had some elective surgeries done in January to repair some longstanding issues finally fixed. While being doped up on Vicodin would make for some interesting blogging, I felt discretion was the bestter path to take...

But today Viviotech gave me a late Christmas present and upgraded my VPS to ColdFusion 9 (woo hoo!) and my old Mango Blog bit the big one because of it (boo!). I'm not sure why this happened, I had not altered the code in any meaningful way that shold have caused it to bomb. And to be frank, Mango Blog's error handling is... less than informative - even with Coldfire running I couldn't find much in the way of meaningful error messages to work on.

So, I backed up the database (God love MySQL for making this task a cinch compared to MSSQL), and nuked my old blog code and installed the latest (v1.4.3). Then after a little trial and error with the database, I got it all back running. In doing so, I had lost the mods I had made to the old design, so I am using this one as a starting point. I like the layout, but not a big fan of the blue, so on my to-do list now is a revaming of the color scheme.

Now that I have CF9 on here, I'm looking forward to some big things in 2010. It will get even better when my day job finally gets out of the Stone Age and gets up up from CFMX7 to CF9 in a few months! It feels like being caged when there's so much that you either cannot do, or have to jump through so many hoops that it's more cost-effective to wait for the CF9 cavalry to arrive.

I was trying to set up SSL for one of my sites. It is a CF7 site, and I have a multi-server setup using JRun4. I followed this blog post (http://www.webopius.com/content/355/getting-mamp-working-with-ssl-on-os-x) to get MAMP Pro set up with my test certificate. But every time I tried to go to the SSL site, I got a 500 error on the screen, and this error in the Apache logs: "JRun will not accept request.  Check JRun web server configuration and JRun mappings on JRun server."

After pulling my hair out on this for almost a day, House of Fusion came to my rescue. They asked if I had my JRunConfig Bootstrap set to the port of the CF7 instance inside the virtual host block in my ssl.conf file. It turns out I had not. So, I addressed that by copying my CF7 connector settings from the "Customized Virtual Host General Settings" field in the Hosts window of the MAMP Pro console into the VirtualHost block for that site in my ssl.conf file.

A restart of Apache, and all is good!