ColdFusion Muse

Building a Robust Error Handler

If you have been around the ColdFusion world as long as the Muse you have heard of Mary Jo Sminkey. Mary Jo built a popular ColdFusion ecommerce platform called CFWebstore. She has vast experience in ColdFusion and a seemingly boundless fountain of energy. Her eclectic interests range from technology to baking to dog training. As far as CF Webtools and the Muse can tell, Mary Jo excels at everything she does. We frankly suspect she is actually twins or triplets pretending to be only one person :) The following article is by Mary Jo and details her approach to application specific error handling. She has a detailed and thorough knowledge of the topic. Using this approach she has been able to reduce the number of errors on a very high traffic E-commerce site to practically nil. In the first of 2 articles MJ (as we call her with great affection) details the structure and usage of the handler.

Building a Robust Error Handler (by Mary Jo Sminkey)

Let's face it, sometimes we put less effort into the error handler than into the rest of our code. We might put something in place that throws up a "user friendly" page, and maybe email a dump of the catch or error structure, but when the site goes live, and we are deluged with errors due to search bots, hack attempts and poorly coded pages we turn it off or send all those emails to a seldom-visited mailbox. Sometimes we implement error handling as cftry/cfcatch blocks that do little more than preventing errors from being thrown, instead of helping us track down the issue.

I look at the error handler as a way to help make a site as bug-free as possible. By having it email me as much information as possible about errors, I troubleshoot, fix and patch, and get to a point where errors are the exception rather than the rule. In this article, we'll look at building a single-page, comprehensive error handler. In a future article, we'll look at integrating that error handler with the open source bug tracker BugLogHQ. Before we begin with our error handler let's talk about our error handling strategy.

ColdFusion Server Infection Using the Missing Template Handler

We were recently called to fix a hacked ColdFusion server. This was a file hack. Something was appending JS code to the end of variuos .cfm files on the server. The appended code redirected the user's browser to a different site (to sell them viagra or puppies or whatever). When analysing the server we found an interesting attack vector. I say interesting because it used a technique I had not seen before that leveraged a quirky feature of ColdFusion. The end result of the hack was a layered infection that was difficult to find and resulted in the infected files coming back regardless of our lockdown efforts. If that sounds like something you are experiencing or if you are interested in ColdFusion security, read on!

Resistance is not Futile: Why Change is so Hard

CF Webtools does more than 3000 hours of consulting every month. As you might imagine there launches, releases and deployments happening constantly. One thing we run into constantly is resistance to change. When users are confronted with a new screen, new functionality, or (especially) a new system there is always resistance. It can range from a mild teeth gritting to kicking and screaming depending on the depth of change. Developers and managers are often nonplussed by this resistance. In virtually every case developers see the changes they have made or the systems they have created as enhancements or improvements over the "old way of doing things." They usually see resistance as futile and self-defeating - not to mention a little absurd. I think this is one of the reason's that developers often have a negative view of end users who are not technical. They simply don't understand the dynamics at play because they are not thinking through the human dimensions.

Great New Systems Still Face Resistance

Take a deep breath and listen to the muse - resistance to your improvements is not based on the quality, appeal, innovations or the time saving nature of your improvements. In other words, the fact that it's the greatest thing since your mother's apple cobbler is not going to make users like it or want it. See if this rings true for you. You are presenting a new system to stakeholders. Say you re-engineer the process for approving a manufacturer's wholesale orders. You create a slick application that interfaces with the companies ERP system. You add approval gates and requirements that must be met to move the process forward. The CEO is ecstatic. It used to take 2 weeks to get an orders done because so many folks had to sign off on the pricing and the deadlines. Now the request won't sit around in someone's inbox or on their desk. The system will move it forward and acquire the needed vetting and approvals. Decreasing the time it takes to get bulk orders approved improves cash flow and the bottom line.

Sales folks are unhappy about it however. Why? Doesn't it mean faster commissions, more time for sales? Well maybe, but what you will hear from them is "We have always done it this way." Let's call that the WHADIT Way. Now before you get all huffy and accuse them of intransigence you should look a little deeper. There's a good reason that folks fall back on the WHADIT Way and its Cousin the WNDIT Way (i.e. "We've never done it that way before"). Consider for a moment how regular users of a system differ in perspective from you. When you got your new IPhone it was a splendid day right? You spent hours noodling with it and figuring out all the bells and whistles. That's because as a developer or IT pro you are a technology adapter. Far from being intimidated by new systems, hardware, phones and devices, you embrace them and revel in learning how to make the most of them. It's not a trial for you to learn. Indeed it's only a minor investment for you. Why? Because your day is filled with climbing up to the cutting edge of technology. You are oriented toward the new.

Now let's talk about the broad masses that include everyone else. Yesterday my wife (who is not technical) was frustrated trying to send a picture from her iPhone. She has a 5s and she was sending via email to her own email inbox. She was doing this to get the picture from her phone to her computer. She would take a picture and when she wanted it on her computer she would forward it to herself, then check her email on her computer to pull it up. Because of some network issue or whatever the email would not leave her outbox. I said to her, "Use the synch cable and copy it directly." The fact that she could do this was news to her. Given one solution to getting a picture out of her phone, it did not occur to her that there might be several.

So here's the question. What is it about me (and you Muse reader) that is different from my wife Ann? Why did I have a ready solution? Is it just because I'm smarter? I can tell you that this is not the case (my wife is extremely smart and savvy). The answer is that I envision technical solutions to problems and I assume that such solutions exist because "that's what I would have done" if I was building a UI, a site or an interface. I knew that the cable would work of course, but let's suppose I did not know. I have no doubt I would simply assume that there was a way to connect and copy images off of my phone. Why? Because it "stands to reason" - not Ann's reason or a regular user's reason - a technology worker's reason.

But this is not the case for the majority of folks who have to use your system (unless you are building it for IT, in which case they will pick it apart long before you get to brag about it in a meeting). Most people can't make leaps and confident assumptions about what something should do or can do or ought to do. They are tethered to what they know. They have made a major investment in knowledge to get things done surrounding their job. This knowledge might be how to fill out forms or which requests should go first or who to contact to get prices changed or how to navigate a legacy menu. It will almost certainly include some knowledge that they feel makes them important and is a source of status.

This idea of status is one we often forget. Consider how your technical knowledge makes you feel about yourself. Doesn't it heighten your sense of worth at the workplace? When people stop by your desk to ask about their hard drive or printer you get exasperated but inside aren't you secretly gratified that they depend on you? Non technical users are not so different, they just have different realms of knowledge. The WHADIT Way is really a ritual that binds users together. The current process might be byzantine and require lots of hoops, but knowing how to get it done is part of the power invested in competent employees. Once that power resides in an automated system it no longer requires special knowledge.

So new systems very often have this downside - they diminish the sense of value that employees feel when doing their jobs because they take things out of their hands.

So the Muse always recommends to board room types that they take a different approach when implementing new systems. Here are the Muse tips for stakeholder buy-in.

Campaign

Start with a sort of marketing strategy. Advertise the new system. Gather testimonials from pilot users. Put screen shots in the newsletter. Find a way to project a positive image for your new system prior to roll-out. This will make adoption easier and it will be harder to criticize.

Engage Early

Early on in the process of outlining the new system, engage your stakeholders and get their input. Make sure the system is not just solving problems that are seen by management. Get real input from users and solve their problems as well. If you get early engagement from the end users they will feel invested in the outcome and grease the skids at release.

No Implementation By Fiat

CEO's and CIO's are famous for saying "They'll just have to live with it." This simply never works - at least not in the U.S. Here we value creativity and innovation. We are looking for thinking, energetic employees who solve problems, not automatons who do things by rote. Valuing creativity and innovation comes at a cost for the manager. He or she cannot afford to force feed employees a solution. When it's tried it is a matter of weeks before there are workarounds and alternate paths for tasks that circumvent the new system. Instead, managers must find a way to:

• Insure that all voices at the table are heard.
• Find ways to alleviate concerns by stakeholders and users - and do it in a way that makes it clear you are investing in those concerns because of the input given by those individuals. In other words, they have to feel empowered to make a difference in the solution.
• When changes in responsibility are needed due to automation, find ways to organize responsibilities, titles and job descriptions to take the sting out. For example, if your customer service manager can no longer approve an RMA without a new gate, give them the ability to provide free shipping or incentivize staff in some other fashion. The idea here is to provide for a lateral move with regard to status and responsibility.

Conclusion

In reality user Buy-in is probably more important than the slickness or usefulness of the system itself. So for all you techies in my audience, have a care with those users. Remember who writes the checks in our world. Take time to help them out.

The Muse Wants Your Talent (and Your Resume)

Yes it's true! CF Webtools is looking yet again for qualified advanced developers. We have two immediate openings on our development staff at this time. It's not due to turnover (far from it). Rather, it's because we have a burgeoning list of extremely exiting customers and projects that need our expert attention. What's it like working for CF Webtools?

• Never Boring - our staff is lively, energetic, positive and usually funny (well... they think they are funny). Among our eclectic group are golfers, motorcycle enthusiasts, belly dancers, photographers, gamers (shocking I know), fencers (as in touche'), rock climbers, fisherman, fireman, musicians, family people, single people (mostly hot), dog people, cat people, PC people and Mac people. We even have the mother of a fashion model. With all that energy it's a wonder we get anything done. But the truth is we all love what we do and we are stronger together than separately.
• Professionally Stimulating - Stay with us long enough and you'll work on every version of ColdFusion back to version 5 (or at least you'll hear stories). We have large legacy codebase's that we maintain, as well as pure greenfield projects. We have mobile (lots and lots of mobile), Mura, FW/1, Home Grown, Model Glue, Mach II, Fusebox, ColdBox, and a box of crackers in the break room. We use MS SQL, Oracle, MySQL, and Sybase. We have apps using maps, apps using web services, apps using APIs and API's using our apps. If there's a "way to do a ColdFusion application" we have seen it, done it and probably maintained, refactored it and maybe invented it. So if you are a lover of programming, programming languages and ColdFusion in particular, you will love it here.
• Interested in Balance - as noted above we are not looking for developers who are so entrenched in a technical life that they have no time for anything else. Professional developers with high productivity and high aptitude are above all balanced. They love ColdFusion and can't wait to code (most days) but they also love eating out, movies, spending time with their kids, going to the gym, cruises, photography, and vacations. We have found that the developer with a whole life (I mean balanced and full of loving relationships - not the insurance) is the one that fits our staff, communicates well, and thrives here at CFWT.

Ok admittedly that is a lot of hyperbole but I know you've come to expect nothing less from the Muse. Meanwhile it is a great place to work and we are thrilled to be able to employ so many talented and wonderful developers.

• Take ownership of a problem.
• Think around all angles of a problem for all possible solutions
• Love the tech community as a place to engage and learn.
• Have evolved skills in an eclectic mix of technologies and like to learn new ones.
• Can explain technical concepts to non-technical folks.
• Know how to honor non-technical people for their own skills and expertise.
• Can laugh, chortle, guffaw and otherwise split a gut with a group of insanely funny people - without the need to put anyone down.
• Are anxious to be a part of a close knit team who encourages and believes in you.

• Advanced ColdFusion - note, we will test you. We are looking for folks who know more than syntax on a web page. You should be well versed in the guts of complex ColdFusion application building.
• Advanced Database Skills - I don't mean you need to know how to build, manage and restore DBs. But you should know how to write a complex query and/or a stored procedure for one or more of the "big three" DB platforms.
• Some diverse technology skills - we don't necessarily dictate what that is but we are looking for folks with a broad swath of skills. Right knowing and developing in .NET, doing IOS/Droid development (or phone gap), and troubleshooting CF servers and server admin are skills that might give you an edge in your application. But if you come to us with several skills that we don't need at the moment you would still be an attractive candidate.

Frequently Asked Questions

• Do you allow telecommuting? Yes all our development positions are full-time remote positions.
• What sort of dev environment can I expect? We are en eclipse shop and rely on SVN, Jenkins, and an agile like approach to development. Having said that, as an outsource development company we frequently integrate with external teams. That means you can't always predict everything about the approach for the project you are working on.
• What Industries are you working in? We have sites we develop and maintain in the Financial sector (stocks, options, commodities, retirement planning and management etc.), Insurance, Medical, Pharmaceutical, retail sales, real estate, etc. We have a very broad client list.
• Will I get to meet the Muse? Yes of course... you'll be sick of me inside of two weeks. Eventually you can stop calling me the muse but the shrine has to stay up for at least a year.
• Do you use frameworks? Yes - all of them all the way back to Fusebox 2. We work on new projects in common frameworks like FW/1 or DI/1, but we also support a host of legacy applications done on custom frameworks or with no framework at all.

As stated above, our positions are full-time remote telecommute. On rare occasions they might require some travel. We pay a competitive salary and benefits. CF Webtools maintains sites on virtually all ColdFusion and Database platforms. Our work is challenging, invigorating, sometimes poke-your-eyes-out frustrating, but never boring. Our development group is full of witty, interesting and extremely talented developers. It's a true mentoring community. If that sounds like a place you would like to work (and you meet our high skill-set standards) send your resume to jobs@cfwebtools.com - or contact the Muse directly if you like. Tweet me @cfwebtools or use the "Ask a Muse" link on this blog (I'm easy to find). You can also call 402 408 3733 and ask for Mark or Jason - we'll be thrilled to speak with you about our opportunity. The official job posting may be found on our corporate site at the Job Openings page.

email connection crossover workarounds

As a follow up to yesterday's post (regarding sending mail and having it end up in someone else's "sent" folder) I thought I might put some flesh on the workaround suggested both in the bug report and on CF-Talk. The suggestion is to:

ColdFusion email security Bug: Your mail in the wrong sent folder?

A recent conversation on CF-Talk piqued my interest. It turns out there is a tricky bug with regard to sending authenticated mail. Here at CF Webtools we have internal relays (protected, internal only IPs, listed in SPF and handling domain keys) whose sole purpose is to relay mail from our web servers - so we do not have "authenticated" email per se. But in the case of this bug (you can see the report here) it's possible for email from one user to wind up in the "Sent" folder of email from an entirely different user. Needless to say this is a security concern for those of you on shared servers especially.

Here are the conditions that need to be met for this to occur (as I understand it).

CFHTTP, IIS 8 and Server Name Indication (SNI)

Guest Post by Wil Genovese

(Muse Introduction)
Most readers know that the Muse is deeply indebted to a large and talented group of developers working here at CF Webtools. These folks solve problems and undertake Herculean programming tasks on a daily basis. They are constantly making me look good and I would not be able to play golf or spend the day wise-cracking in IM and tormenting my assistant Melissa without them on my side. Among these folks is one of my favorite characters, CF guru Wil Genovese. Wil has worked with us for a few years now and he writes an excellent blog at Trunkful.com. If you have not already done so, you should add it to your list of must read blogs.

Meanwhile, a few days ago Wil was trying to troubleshoot a head scratching issue with CFHTTTP and SSL. Now such issues almost always come down to getting the certificates properly installed in the keystore, using the correct URL (correct in all respects for the certificate), name resolution and SSL protocol levels (as in "do you need to lower Java's draconian SSL defaults to allow for less secure protocol"). After beating his head against the wall repeatedly Wil finally decided the issue was on the other end - the certificate on the server was somehow wrong, misconfigured or behaving unexpectedly. I thought this was dubious at best, but as is so often is the case the Muse was wrong and Wil found out (with apologies to Monty Python) something completely different. It turns out a new feature in IIS 8 (Windows Server 2012) was the culprit. Since this setting affects all Java versions prior to 1.7 and even affects CF 10 on Java 1.7, you should probably pay attention. My guess is that you will run into this issue eventually - given the ubiquity of IIS and the coming upgrades to Windows server 2012.

Anyway, I invited Wil to write the following entry detailing his findings. If you want to know more read on:

A Frank Discussion About Protection

I know it's an uncomfortable topic. I understand that you would like to keep your validation private. You would probably rather learn about this from your friends at the coffee shop, Jeremy who is two cubes down from you, or some guy on a forum (shudder). Still, the Muse has an assignment in life to point these things out and make sure you are well informed and prepared when temptation strikes. Oh I know what you say now. I know what I'm doing. The risk factor is slight. I'm too small... I mean... my application is too small to need it. But take it from me - you will need to understand how to use protection or bad things will happen. So let's talk about it.