Be Still

For those offended by religious references, go ahead and move to the next entry.  I very rarely put non-tech stuff on here, but this piece really grabbed at me.  As some of you may know I hiked rim to rim across the Grand Canyon with my father November ’05.   As we spent those days working our way through endless sights of absolute awesomeness, I never once considered finances… deadlines… error exceptions… design concerns… conflicts…  anything.  Being totally unplugged and immersed in such a magnificent place is a sure way to find what is really important in your life.  The night before our exit from the canyon, we sat out on Plateau Point and watched the sun set, looking down 1500 feet to the CO River and looking up another 2000 to where we would be the next evening.  I felt the exact same thing that this author felt.  I am sure that this means more to me than it will to anyone else, but hey… it’s my blog. :)

……..

SITTING at the edge of the Grand Canyon silenced me. Canyon stretched before me as far as the naked eye could see. There seemed to be no end to it. In the quiet, I watched light reflecting off the walls, creating splashes of red, blue, purple, yellow. A jagged rock towered nearby, reflecting light to the east side. Snow glistened on the canyon rim where the trees staggered on the edge. Below I could see the river storming through what looked like cracks and crevices.

As I sat, I was mesmerized knowing that God created this beauty. But my thoughts turned as I heard in my heart the words, “Be still.” Anxiety rushed up: worries over relationships, finances, and schedules. But as I gazed at the scene unfolding, I heard the words echoing across the canyon, “Be still, and know that I am God.”

The God who designed this canyon has designed you and me with the same infinite care. When we ponder the greatness of God who watches over all creation, both the Grand Canyon and us, silent awe seems an appropriate response.

Michael C. Lyons (Ohio, U.S.A.)

VAR scoping using structures

At this stage in the game of ColdFusion, it is common knowledge why you must var-scope all variables in your methods in order to protect your data.  In case this is something new to you, say you set a variable named “myVar” in method A.  Say you had a method B and in it you had another “myVar” with a different purpose.   Unless you declare your variables like this: <cfset var myVar = “something” />  that data is shared between both methods and can be overwritten.

So typically when you have a method you var-scope all your private variables including queries or anything else like this:

<cffunction name=”a” output=”false” returntype=”void”>
<cfset var myVar = “” />
<cfset var qQuery = “” />

<….. then all your code …>
</cffunction>

One thing I have never been fond of is that once this is done there is effectively no visible difference in your code between variables that are var scoped and variables that aren’t.  For example, let’s say I var-scope mVarA and don’t var-scope myVarB.  When I access them in the method they visibly appear to be in the same scope… like this:

<cffunction name=”a” output=”false” returntype=”string”>
<cfset var myVarA = “” />
<cfset myVarB = “” />

<cfreturn myVarA & myVarB />
</cffunction>

Looking at this, there is no visible way to see which of those variables is var-scoped without looking at the top of your method to see what you have done.   Plus, as you add variables to your methods, that var-scoping area will grow and you can have a large section of protected declarations.  I have found a different way to approach this by var-scoping a structure named “private” at the top of my methods.  Then in my code I can simply use <cfset private.myVar = “” />.  For example, the code above would become:

<cffunction name=”a” output=”false” returntype=”string”>
<cfset var private = structnew() />

<cfset private.myVarA = “” />
<cfset myVarB = “” />

<cfreturn private.myVarA & myVarB />
</cffunction>

By doing this, I no longer have to go var-scope each individual variable, plus the code becomes far more obvious as to which variables exist in that “private” scope.

Picked my pre-CFUnited classes

This year, CFUnited will be running 4 days (Wednesday through Saturday) as opposed to 3 Days (Wednesday through Friday) in ’05.   In addition to the conference last year, I attended the pre-conference classes on Monday and Tuesday… man, what a great opportunity that was!  I took two one-day classes, “Designing and Developing OO Applications with CFCs” by Hal Helms, and “Forms and Beans: Refactoring Existing ColdFusion Using Objects” by Joe Rinehart.    Those two classes gave me a complete re-awakening in my development career and have really inspired me towards notable growth since that time.

So this year, since I will be making the trip to DC, I decided to make the most of it and signed up for the pre-conference classes again.  Once again there is a great array of choices.  The ones I chose are highlighted in yellow:

Monday:

  • Leader of the Pack (strategies for building better software)
    Simon Horwith – Monday 6/26
  • Fundamentals of Relational Database
    Kurtis D. Leatham – Monday 6/26
  • ColdFusion Server Administration: JRun J2EE Deployment
    Adam Wayne Lehman – Monday 6/26
  • Testing ColdFusion
    John Paul Ashenfelter – Monday 6/26

Tuesday:

  • Ajax intensive for ColdFusion Developers
    Rob Gonda – Tuesday 6/27
  • XML, XPath, and XSLT for ColdFusion Developers
    Jeff Peters – Tuesday 6/27
  • Domain Modeling
    Hal Helms – Tuesday 6/27
  • Beyond Basic SQL for CF
    Nate Nelson – Tuesday 6/27

As for why I chose the ones I did.  here are the specific descriptions of both:

  • Testing ColdFusion  – Learn how to make your ColdFusion software more robust, your QA process more reliable, and your development able to better support changes through unit, regression, functional, and load testing. We’ll start with an overview of the testing process and jump right into tools to help your development process immediately — CF(C)unit to test your ColdFusion code and dbUnit for resetting the database to a known state to support testing from a known good state. We’ll spend a good bit of time on automated functional testing with Selenium to avoid all the repetitive testing tasks you are probably doing by hand. Load testing tools will be on the list as well — so we can help find those nasty race conditions and have some confidence about what kind of load the site can support. Finally, we’ll pull it all together with automated tools to build, test, and release your software on a regular basis so you can spend more time coding and less time worrying.

    Note: All of the software used in this class is open source *and* cross platform — you’ll go home with everything you need to start implementing the testing tools that are relevant to you immediately.

  • Ajax intensive for ColdFusion Developers – Ajax, Web 2.0, RIAs, single-page-applications are just a few buzzwords that every developer needs to know in 2006. Learn the history of Ajax, what it means to you, why you should pay attention, who is using it, what is available, and how to implement it. This session will get you up to speed with Ajax, compare the different existing frameworks, and provide you helpful tips of do’s and do not’s with Ajax.

    Learn how to enrich your users experience by the use of AJAX. Examples start at –hello world– and build up all the way to object oriented MVC applications. By the end of this session, you will know how to enhance your site through simple AJAX widgets or build full AJAX application including enhanced security and debugging techniques. Learn common mistakes such as delegating business logic to the client side, and learn to avoid them by keeping your logic in the server and loading scripts on-demand.

My Segment on WebDevRadio

I blogged the other day about my response to some statements on www.webdevradio.com by Michael Kimsal regarding ColdFusion.  This started an interesting chain of events.  Michael read my post on the webdevradio.com forum and apparently came here and read my blog.  He contacted me later that day and told me he appreciated my comments on the forum and wondered if I would be interested in doing a short segment on his show about the Mach-II/Reactor Jumpstart application.    Heck yeah!

So Friday night I put together a segment and sent it to him.   He released the new episode today and you can hear my segment in that show.  Below is a direct link to the episode, but make sure to subscribe to his podcast.  He regularly has good information on it.

Episode 18: Listener feedback Audio Download (31:08 min / 14.3 MB)

In defense of ColdFusion

I was listening to the Feb 28 podcast of WebDevRadio on the way into work this morning, which is a kind of PHP-centric podcast that branches out a bit into other areas of web development.  The speaker (Michael Kimsal) was commenting briefly on ColdFusion and how it is a quirky language with a small group of loyal follower, and how it is a tag based scripting language that allows people without much programming experience to create functionality with relative ease, allowing users to use tags in place of having to write lots of code.  Anyone who is a somewhat serious ColdFusion programmer would know that this does not really reflect the nature of ColdFusion today.  He also mentioned that it was really hard to find any current information about ColdFusion on the internet, and that most information that he comes across is outdated. To his credit, he did give props to Mark Kruger’s blog and to Hal Helms and Jeff Peters’ Helms and Peters Outloud.   I was going to email the podcaster with my reaction to his comments about ColdFusion, but couldn’t find an email on his site.  I did however, find that he has a forum set up where people can post comments about the podcasts.  I made the following post regarding his comments.

Subject:  In Defense of ColdFusion
… ok “defense” is obviously not the right word, as it clearly wasn’t attacked, but I did want to offer some further discussion and counter points to your comments on ColdFusion from the 2/28 podcast. I would like to preface this by saying that this is by *no* means intended as a rant, but more to shed light on a couple of things that you might not be aware of.

Before I get to that, I would like to validate your comments about Helms and Peters Outloud. This is a tremendous series that not only benefits ColdFusion developers but developers in general. Hal and Jeff are both extremely knowledgeable and talented guys that have a wealth of information to share.

The first point I wanted to make was in response to your description of ColdFusion. I am guessing from your comments that you have not worked with ColdFusion since the release of MX, or have tapped into the dramatic changes of the language since that time. To describe it as just “a tag based language that makes it simple to add functionality to a site” (poorly paraphrased) is completely missing the target. I will bullet point a few of the reasons I make that statement.

  • Since the release of MX, ColdFusion now sits as a layer on top of Java. Java classes can now be accessed directly from ColdFusion now leveraging a tremendous amount of power that wasn’t there previously. If I want to have my entire data model set up in Java I can do so, then access those objects with ColdFusion as I would if they were part of my application.
  • Design Patterns have really been made part of best practices in the ColdFusion in the past couple of years. I find more and more applications that are built with strict adherence to the MVC design pattern, creating far more scalable and robust applications than in days of old.
  • OOP is a reality with ColdFusion. The way in which people create applications these days is much more in the vein of writing Java applications. Bean, DAO, Gateway, and TO patterns are typically the way that people access/persist the data in their applications. Long gone are the days of sloppily dropping in a query here and there in a CFM template and putting all your business logic in the page, making brittle applications that have the potential to die if changes are introduced elsewhere. Best practices today abstract all of that and make classes do the work, leaving applications much more insulated from change, and much more portable.
  • Duck typing – not something to be ashamed of anymore! Smile In the not too distant past, ColdFusion would be criticized for being a loosely typed language. With the growing popularity of things like Ruby that are obviously loosely typed, people are starting to realize that sometimes there is power being able to duck type objects.
  • Incredible amount of growth in the past 18 months… ColdFusion developers were described in your podcast as a small but loyal following. If you look at the recent TIOBE ranking system (which is kind of a buzz meter imho), they rank ColdFusion at #13 of all languages (not just web languages) for March 2006, which is up 13 places from this time last year. In comparison VB.Net is at position 20, and I wouldn’t necessarily describe them as a small group.
  • Enormous amount of new frameworks and methodologies… There are now a number of strong application frameworks that employ MVC patterns to ColdFusion design, such as Fusebox, Mach-II, and Model Glue (which is now being ported to other languages). In addition to the application frameworks, there are now ORM frameworks such as Reactor for ColdFusion that offer tremendous power using database introspection ond object factories. For example, the simple fact that a table called UserAccount exists gives me a Bean, DAO, Gateway, and TO of a UserAccount object with all getters and setters, validation, and any methods I need to do what I need to. With Reactor I can also wire all my object relationships in XML, and by simply instantiating a bean I have Iterators available of all its children and there children. There is also ColdSpring that allow you to inject object dependencies via XML.
  • As for the comment about it not being open sourced. I am not sure how that is much of an argument against it at this point. I have yet to ever meet a PHP developer who has altered the source of PHP, and if cost is an issue, you can find ColdFusion hosting for $5.00/month at will these days.

I would like to bring up one other point. It was mentioned in your podcast that it is hard to find updated information on ColdFusion. There is a large number of active bloggers in the CF blogosphere, of which Mark Kruger (who also keeps a podcast of that blog), who was mentioned is on, as am I at www.daveshuck.com. If you want all the ColdFusion info you can handle in one place, you must check out the blog aggregator www.fullasagoog.com. Add a live bookmark to the ColdFusion feed an never be left in the dark again! Smile There are a few others as well such as www.feed-squirrel.com, www.codebulletin.com and the MXNA list at http://weblogs.macromedia.com/mxna/. The folks at www.asfusion.com have created a cool blog reader for MXNA built 100% in ColdFusion using 100% ColdFusion with Flash Forms. Go check that out at www.asfusion.com/mxna.

I seriously hope this did not come off as a rant, and I really enjoy your podcast. Keep up the good work.

Hiding Mach-II (or Reactor or any) XML config file

I have had kind of an uneasy feeling about having my application framework model, or in the case of Reactor, my object relationship model available as a publically accessible file.  Obviously you can go bury those in other locations on the server, but there is something nice about having your config directory right there in the site you are working on.  On the way home from work yesterday I was considering this and came up with an approach I tested a few minutes ago with success.  Instead of having *.xml extensions, make them *.cfm extensions, then enforce <cfsetting enablecfoutputonly=”true” />.  As your ColdFusion application reads the file, it will treat it like any text document, and will not run through the parser.  Then if someone tries to hit it from a web browser, they can only see what you want them to see.  Here is an example using a Mach-II config:

Here is how it used to be:

<mach-ii version="1.0">

    <!-- PROPERTIES -->
    <properties>
        <property name="applicationRoot" value="/" />
        <property name="defaultEvent" value="showHome" />
        <property name="eventParameter" value="event" />
        <property name="parameterPrecedence" value="form" />
        ...and on and on.....

Now, I have added a single line to the top:

<!-- <cfsetting enablecfoutputonly="true" /> -->
<mach-ii version="1.0">

    <!-- PROPERTIES -->
    <properties>
        <property name="applicationRoot" value="/" />
        <property name="defaultEvent" value="showHome" />
        <property name="eventParameter" value="event" />
        <property name="parameterPrecedence" value="form" />
        ...and on and on.....

And the call to the file has changed from:

<cfset MACHII_CONFIG_PATH =ExpandPath('/config/mach-ii.xml') />

to

<cfset MACHII_CONFIG_PATH =ExpandPath('/config/mach-ii.xml.cfm') />

As your application reads this file, it will ignore the first line since it is an XML comment and parse the rest as it should.   When a web client tries to access the file directly, they would only see the following in the HTML source:

Very simple and very effective!

Unexpected CFPARAM behavior

In  working with a new MachII / Reactor application, I decided to tune it the best I could be creating the Reactor factory as a property in MachII, then create application scoped factories for the Gateways and DAOs.    Sean Corfield was looking at the code I was using to accomplish this and pointed out a big error in my thinking.  I will specifically show the code that I was using for the Reactor Factory, but I was using the same method on the other factories as well.  Here is the code I had.

<cflock name=”#application.applicationname#_ReactorFactory”

type=”exclusive” timeout=”30″>
<cfparam name=”application.ReactorFactory”
default=#createObject(“Component”,
“reactor.reactorFactory”).init(expandPath(“/config/reactor.xml”))# />

</cflock>

My thinking on this was that if application.ReactorFactory didn’t exist, it would then instantiate it and place it in the application scope, thereby only instantiating once per application instance.  However, I got the following response from Sean.

However, <cfparam> evaluates its default= value *every* time so you’ll
be creating a new Reactor gateway each time through this code – even
tho’ you only store the first one. <cfparam> is not really a good way
to set application scope variables (for this reason).

…If it’s any consolation, I had no idea whether <cfparam> behaved like
that so I had to go off and write a test class to find out… I
suspect the default= on <cfargument> may behave the same way (but have
no tested that… yet!).

I found this quite surprising, and it obviously killed the entire concept of what I was trying to achieve.  Secondly he pointed out that the best practice way of locking the scope was not being employed.  Here is the code he suggested as an alternative and is what I now have in place of the cfparam.

<cfif NOT structKeyExists(application,”ReactorFactory”)>
<cflock name=”#application.applicationname#_ReactorFactory” type=”exclusive” timeout=”30″>
<cfif NOT structKeyExists(application,”ReactorFactory”)>
<cfset application.ReactorFactory = createObject(“Component”, “reactor.reactorFactory”).init(expandPath(“/config/reactor.xml”)) />
</cfif>
</cflock>
</cfif>

You may notice the way that the application.ReactorFactory is being tested twice.  As Sean pointed out this is considered a “best practice” way of ensuring thread safety.  The logic behind this follows.  Take a case where this code is being run for the first time in the application.  User A has made the request, and has reached the line of code of the first conditional test.  In the mean time, User B has also made a near simultaneous request.  In the time between User A’s conditional check and User A’s <cflock>, User B has also passed the conditional check and has jumped through and set application.ReactorFactory.  Without the second conditional check, User A would then proceed to <cflock> the application scope and again set application.ReactorFactory.  In hindsight, this is obvious, but it was something that I had not previously employed.