Amcom Home Page

 cfcatch Gotcha (it got me)

The other day I had a client call about a bug in an application that we had released a few weeks back. This particular piece of the application allows users to import an Excel spreadsheet, which is parsed and inserted into a database. The reported bug was that the user (apparently) successfully imported their .xls file (no errors were reported by the system), but the records didn't show up in subsequent searches. Hmm....

The majority of the import happens within a single method. At the top of the method, I declare a variable to hold any potential error messages... initially set to an empty string:

<cfset var insertErrorMsg = "" />

Further down in the method, the actual SQL INSERT is done within a <cftry> block. actually, it's a number of INSERTs done inside of a <cfloop>. after each INSERT, i have the following <cfcatch>:

<cfcatch type="database">
	<cfset insertErrorMsg = cfcatch.detail />
	<cfbreak />

At the end of the method, if the length of the value of the insertErrorMsg variable is 0, I assume all is well and indicate to the user that their import was successful.

In this case, however, all was not well. Something went horribly, horribly wrong and under a specific set of circumstances (which I later identified), a specific variable that was intended to be an integer was sent into the method as an empty string. ColdFusion would error with Invalid data '' for CFSQLTYPE CF_SQL_INTEGER. Why then, wasn't my bulletproof error handling working? I added a <cfmail> to the <cfcatch> with a dump of the <cfcatch> scope:

Note the empty string for the detail key. Yeah, I know. So there were any number of easy fixes that could have been done (using the cfcatch.message string, or incrementing an errorCount variable that's initially set to zero). It's not so much about the solution as it is about the problem. This isn't one that I would have anticipated. Thought it was worthwhile to throw out there in case others may be using, or considering using, similar conditional logic.

 How I Learned to Stop Worrying and Love Eclipse

Here at Amcom we're starting to formalize our coding processes, which includes coding standards, tools, etc. While I don't think we'd ever mandate the use of a specific IDE (as long as the final code adheres to the agreed upon standards, it's not really important how it was created), we find that we keep coming back to Eclipse.

We've discussed unit testing and MXUnit (Eclipse plugin). We've discussed the CF8 debugger (Eclipse plugin). We've decided to use the ColdBox framework (which has Eclipse plugins). We do a good amount of Flex work (FlexBuilder being available as a standalone Eclipse product or as an Eclipse plugin). And of course, as a ColdFusion shop, there's CFEclipse (Eclipse plugin).

A few of us have been using Eclipse (and various plugins) for a while, but some have yet to make the leap. I recalled my first efforts to make the switch from HomeSite+ (previously ColdFusion Studio) to Eclipse, and some of the challenges that I faced.

I was a bit overwhelmed at some of the terminology like "Perspective" and "View" and don't even get me started on the concept of a "Project". It took me a good couple of tries switching back and forth between Eclipse and HS+ before I was truly comfortable developing in the Eclipse environment. I put together a document that was intended to be used internally to help demystify Eclipse as an IDE. At this point it's pretty basic and a work in progress. But it was suggested that it might have some value to the community, and might help others that are considering making the switch but having a hard time mentally reconciling the Eclipse environment versus their current environment. I've attached a pdf to this entry, available at the "Download" link below.

If anyone finds this to be useful, please let me know and perhaps I'll flesh it out a bit more. If there's anything in the document that needs further clarification or correction, please bring that to my attention as well.

 Hello Swiz...

Well apparently I'm one of the only people around that really doesn't mind Cairngorm. In fact I'd say I quite like it. It has served me well for the last couple years, and when you add first class IOC like Prana you have a well documented, flexible, lightweight and battle tested MVC.


 Building Business Objects with Transfer

So last time we had just finished an abstract class diagram for the business objects that we want to create for use in our Model. To write them by hand including the ability to save them to a database, would require you to write your own data persistence layer. Which would (should) include one (or more) of the multitude (DAO/Table Data Gateway/Gateway/Active Record/Data Mapper...) of design patterns dealing with persistence. They are all meant to solve essentially the same problem, separating the data access implementation from your business logic. Some of those patterns are quite different from each other and some are virtually identical. Implementing virtually any one of these strategies is a good start, but you will still need to deal with the assembly of the objects once you have the data.


 ColdFusion 8-Enhancements You May Have Missed

Telling ColdFusion developers about how great ColdFusion is, is preaching to the choir. It's immediate and automatic fanfare, but breaking out of the ecosystem to promote the technologies you believe in help grow the community.

Amcom's Charlie Griefer has done just that with an excellent post at PACKT Publishing's online articles, with a great recap of the enhancements in ColdFusion 8 that people may have missed or not be aware of.

Check it out!

 Building the Model : Business Objects

As part of our recent evaluation I developed a simple demo application for each of the MVC frameworks that we were considering here at Amcom for use on future projects.

I'll be writing several posts describing how I went about building the demo, what technologies were used and just general impressions and opinions about using ColdFusion to build object oriented applications. I plan on breaking the posts up into roughly these topics:

  • The Model : Business objects
  • The Model : Service Layer and Gateways
  • The Client with Coldbox
  • The Client with ModelGlue
  • The Client with MachII
  • The Client with Flex


 Amcom Technology chooses the ColdBox MVC Framework

In the upcoming weeks we plan to share a number of documents that we've created that will help those interested in learning more about Frameworks, techniques, SDLC, and software architecture. There are three audiences that we have in mind; technology managers (like myself) who view things from the business (e.g. strategy, ROI, competitive advantage, and value) perspective, intermediate developers who want to grow their skills, and advanced developers who are looking for additional perspectives.

In preparation for a large insurance focused Enterprise CRM application for one of our customers, we've been gathering requirements (use cases, domain modeling, business analysis, etc...), determining implementation strategy, application architecture, and finalizing the technology stack that best meets the requirements. As a part of that effort we evaluated the major ColdFusion MVC Frameworks, and are publishing our analysis (authored by Jon Messer) to the community. Although we have extensive Model-Glue II skills within the team, we have decided to move forward with the ColdBox Framework.

The analysis document explains why, but from a casual perspective here's my synopsis (the technical management perspective).

The project we're working on has undergone months of planning – lots of analysis over how the business functions, process engineering, domain modeling, use cases, usability analysis, you name it. In putting together the technology stack, the same spectrum of tools was evaluated from data modeling tools, database servers, data warehousing, reporting & analytics, to front end technologies like Flex.

Obviously it would take a year to do an exhaustive review of all the options and wouldn't necessarily yield significant value - so usually the evaluation was a trivial sanity check. But regardless of the type of technology or methodology, it came down to a BUSINESS decision. Meaning it's not about determining not what the best technology is, but rather what the best option for the business is.

Few would debate the merits of MVC, so when it came down to making a choice for a ColdFusion Framework the considerations or evaluation criteria that mattered to the business include:

  • Documentation:
    • This is the foundation to many other considerations.
    • Strong documentation helps reduce learning curve, and it makes the team function efficiently by reducing wasted time through trial and error.
  • Development Velocity:
    • This is an umbrella category that encompasses many things.
    • It has to do with how fast developers can learn the Framework, how agile we can be, reduced time on maintenance, reduced time on defects, reduced overhead, standardization, how long it takes to ramp up new developers, unique features of the Framework, etc...
    • One option is you could write your own Framework, but the question is what is the value in doing that? Its opportunity cost – those man hours could have been spent elsewhere. More importantly, leveraging the efforts of those who have built these Frameworks effectively makes your team bigger (as if they built it for you).
  • Strengths of the team:
    • You want to always play to your strengths.
    • It's why companies will sell off divisions that have nothing to do with their core strength. Another technology may be hands down better, but if you can get to market using your existing skills faster than having to learn new ones, that's an important factor.
    • In this case we have team members with extensive Model Glue skills, but at the same time have a diverse skill set.

  • Third party risks:
    • When you utilize a small open source initiative (small in the sense of number key project developers), there are risks.
    • As a manager you want to always cover your bases, even if the likelihood of an issue is minimal. Taking risks is good, but make your risks based on information (vs. emotion) where the value outweighs the risks.
    • To mitigate these risks, we made note of:
      • Development activity
      • Size of community
      • Published Roadmaps
      • Published Bug tracking system
    • Though, in the worst case scenario you could manage the Framework yourself, and even better if you architect your Model right you can swap in a different Framework. In Jon's evaluation he did exactly that, and had the same application running on 3 of the major MVC Frameworks, including one Flex front end, all using the same backend Model.
  • Professional Support.
  • Cost.

From a technical level, our own experiences and research showed that all the MVC Frameworks we evaluated were generally equal in performance and scalability. However we found that ColdBox offered distinct advantages in other areas; particularly the toolkit nature of the project which offers various features like debugging, custom exception handling, interceptors, and AOP error logging abilities, but also the fine grain ability to hook in and extend the Framework.

From a business perspective, it was a no brainer. The level of documentation rivals professional technical publication teams. And the high degree of long term persistent development activity on the project provides security in the sense that these guys have an unlimited amount of passion to remain committed at that level for so long.

So a tip of the hat to the folks behind the ColdBox Framework for an outstanding job (Luis Majano, Russ Johnson, Rob Gonda, and Sana Ullah). We look forward to their continued efforts, and we hope to contribute to the project as well.

BlogCFC was created by Raymond Camden. This blog is running version 5.9.002. Contact Blog Owner