Mike's Blog

Though the holidays have been upon us, my deadlines (including the unrealistic ones) stand firm as does my desire to stay strictly OO on my latest ColdFusion project.  So far, so good.  Now that some major milestones have been reached, I'm able to start testing some of my services beyond the simple unit tests I had conducted up to this point and I found the results troubling.

The more my application ran and the more in-browser testing I conducted, I found that my application response time was slowing down over time.  Not dramatically, especially considering I was the only one hitting the application.  But it was noticeable and it would certainly be a problem at production time.  I began conducting slow-going, manual "process of elimination" tests to see if I could identify the problem.  I started by doing a side by side compare of the small script I was running in two versions: with Coldspring for dependency injection or handling dependencies by hand.  The latter, in an effort to produce identical circumstances (i.e. dependencies of dependencies would have to be instantiated) took a considerable amount of code!  It's no wonder these frameworks are used!

I learned, as you might have guessed, the app was definitely faster without Coldspring.  I understand that, it's less overhead.  But the difference was very significant, especially in regards to transient objects.  So, I switched to Lightwire to see if it made a difference.  And wow... it sure did.

Lightwire appears to be a much lighter weight choice if all you need to do is identify your transients and singletons and set their dependencies on instantiation.  In doing some research to see if there was a way to get Coldspring to handle transients more effectively, I did read that others have had similar problems that they've chosen to solve with Lightwire as well.

Check out Lightwire

My first official OO ColdFusion project found it's way "on the grid" as it were with a sudden business need to have it completed ASAP.  That works for me!  But would all the sudden meetings and new people in the mix require me to refactor what I've developed so far?  As it turns out, no!

I am probably about 85% complete writing my ColdFusion objects and their DAO components.  From there, I'll move on to their validation objects which I intend to use to ensure all business requirements are met before records are saved or updated.  I intend to implement my validators by overriding my save() method where validation is required.  When this is complete, I'll have complete functionality available to me without any implementation of a user interface.  My options are open in that respect.  I can integrate into an existing application via web services.  I can write a whole new UI from scratch as a standalone app.  Or, I can do a combination of both.

When the folks at work begin scheduling urgent meetings to discuss their needs, I was concerned.  Would my weeks of silent effort be overturned due to suddenly new and urgent needs that would require code rewrites?  I attended these meetings with anticipation and planned to scribble notes furiously.  Sure enough, questions flew about wildly and other people answered these questions with ideas.  They'd drop an idea on the table and look at me cautiously, asking, "Can we do that?"

They wanted reports, scheduled alerts, options for batch uploading in addition to single file uploading, "ticklers," integration within the existing front office application, and more, all of which were items specific to what I'm referring to as the "service" layer of UI layer.  The data access layer and object structures currently developed remain in tact.  The good news was I didn't have to change a single thing.  I love you, Object Oriented Programming!

On another note, I've been able to breeze through my development by drafting my model and its dependencies BEFORE writing any code.  Admittedly, I used old school tools like Excel to do this due to my lack of familiarity on Visio, but I got a good primer on how to do things more traditionally thanks to a quick tutorial from Micky.  He's since elaborated on his blog with a very thorough walkthrough on application design that I highly recommend.

Do I have your attention?  I thought so...

But really, there's some truth to the title of this post, at least from what I'm seeing whenever we open up a requisition for a new developer and begin interviewing.  ColdFusion has been around for a while now, so we're seeing resumes from developers with over a decade of experience.  What we're not seeing are developers with enterprise level experience on enterprise software solutions.  Is that because ColdFusion isn't deployed in the enterprise?  No, that can't be it... We know that it is!  So what gives?

Here's a quote from the comments on another blog:

The "Jobs available" argument is spent. Yeah, there are more .Net and PHP jobs out there, but there are more developers available for that work too. Those positions, in my view of the market, pay less, and well they should - it's a race to the bottom and the supply is plentiful.

ColdFusion is niche, and niche pays more. You want PHP/.NET developers to realize the power of CF, embrace it, see it as a viable language? Be careful what you wish for!

Is this really true?  Am I expected to pay more because you're a ColdFusion developer instead of a .NET developer?  Because guess what... I won't!  If you're unable to demonstrate a senior level skill level after a senior level detailed technical interview, and I mean TECHNICAL in the true sense of the word, then you will not be "paid more."  If you indicate that you use the createObject() function in ColdFusion and are therefore familiar with object oriented programming but you cannot define polymorphism, I'll recognize your potential to be trained but will NOT consider you a highly paid resource.  Screw "niche!"

In my entire career, and I am not exaggerating, I have accepted job offers and have been presented with job offers by people who haven't asked me one single technical question about my experience in ColdFusion.  I've been asked what versions I've used, what IDEs I've used, what size teams I've worked with, what frameworks I've used, but nothing to indicate whether or not I understand and use any of the intermediate or advanced ColdFusion functions or how I've used ColdFusion to solve advanced or complex business problems.

I have never been asked what the CFQUERYPARAM tag does.  I have never been asked how to prevent a race condition.  I have never been asked to define encapsulation.  I have never been asked how to roll back a SQL transaction in the event of an error.  And when we ask questions like that in the interviews we conduct, most applicants seem really taken aback.  And honestly, few do well under the pressure.

My point is that our community is full of bright developers with huge potential, but our community has some growing up to do.  Our small size shouldn't confuse us into thinking we should be paid more than our Java and .NET counterparts, however, many of whom perform exceptionally well with our team's interview style.  It's all about your skill.  Period.

My current OO project began as a dark secret -- one that I would reveal when the time was right, when enough of my own personal time had been invested that my employer would find deploying it attractive (cheap).  Then a discussion about the product it was meant to replace came about and I revealed what I had been writing, with little fanfare.  Then, a high profile meeting was called where I was brought in to discuss what I could do with this enhanced bit of code to a handful of executives.  My secret was officially out.  Unfortunately, my new audience doesn't know anything about or have any professional interest in the meaning of object oriented programming... but that's ok... for now.

What did come out of the meeting was that my other big secret intention of using Flex for the front end would not happen.  The VPs want this software to integrate directly into our existing front office application, which is ColdFusion powered but procedural to the core.  At first, this bugged me deeply, but with more thought it became clear that very little has to change.

I'll continue to proceed with the OO nature of the development.  I had planned to expose CFCs as services for the Flex layer, and I can continue to do that as intended with slight modifications to provide integration with the existing CF app instead.  This allows me to keep my model purely OO, separating my business logic into its own layer, and then instead of creating a new UI layer, simply adding on to an existing one.  No big deal at all, right?  Right?  God, I hope not!

We're conducting an upgrade at work, from ColdFusion 6.1 (shudder) to ColdFusion 8.  We haven't yet been authorized to upgrade to CF 9 and we have the licenses for CF 8, so we're going for it.

Straight away, I got an error when attempting to run our CFX tags:

com/allaire/cfx/CustomTag null

Not much help there, right?  Googling the issue didn't return too many results either.  So, I sat with Micky on it for a while and he pointed out that he had experienced a problem with CFX tags in ColdFusion 8 related to the location of cfx.jar.  We added the following to the Java Classpath in the jvm.config:

C:/ColdFusion8/wwwroot/WEB-INF/lib

Interestingly, we found that when we used the {application.home} variable at first like so:

{application.home}/wwwroot/WEB-INF/lib

Which was being translated as C:\ColdFusion8\runtime\wwwroot\WEB-INF\lib, an invalid path.  Using the path bolded above return successful results and we're happily running our CFX tags again on ColdFusion 8.