ColdFusion Muse

Henry II on Vacation - Why Teams Matter

"Just add more resources..." is a comment I hear quite frequently in our corner of the tech world. It is often thought of as an easy "solution" to IT challenges. Unfortunately, adding additional developers can often result in further bottlenecks. The following is a real life example (the names have been changed to protect the innocent)!

Let's talk about Lead developer Henry II and his role within ACME Company. In spite of being obsessed over ownership of the Aquitaine and looking vaguely like Peter O'toole, he's a terrific programmer, smart, aggressive and a problem solver of the first order. He tackles tasks with a great deal of energy and seems to be able to see the whole picture. Were he the only programmer (a team of one) these qualities would serve him well to get the most out of what he has to offer. As it is, these qualities combine with ACME's development model to serve as a constraint to efficiencies of the team.

Henry, due to his sense of ownership and responsibility, does what needs to be done. He wraps his arms around tasks that demand attention, sometimes without differentiating between effective and ineffective use of his valuable time. He spends too much time working "within" the projects and and not enough time working "on" them – meaning the strategy and direction and planning and mentoring (the stuff a lead usually does) – where his domain knowledge is the most valuable. A quick illustration might be helpful.

ACME has a process that synchronizes files from a watched directory on an internal share out to the servers at the NOC. The process allows customer service to get new content onto the server by simply dropping a file in a local directory. Periodically one of the several dozen directories has a problem. A file to be synched "hangs" and is not copied over. No one knows why, but it is always a file in the same directory. The fix is to log into the synchronization software and reset it. This kick starts the synch and the file is then copied.

While Henry was touring one of his estates in the low countries this problem re-occurred. A ticket was written and a developer (doubling as Sys-Admin) looked at it but could not readily ascertain what was happening or find a way to fix it. The result was a note back to customer service that this task would have to wait till Henry the Armada returned from Denmark.

This event is not an isolated sort of event – Henry getting called in to save the day because he knows all of the who, what, when and how. So let's note a few things at work here in the aftermath.

Wrong Resource? The first question is probably, "why is a software programmer troubleshooting file synchronization?" There is a case where that is necessary – usually when a team is too tiny to have a lead at all. That's not the case here so, is this the best use of a key resource?

Documented Process? Is there a place where developers can go and search for troubleshooting tips on the synch process? This was not a new problem, it occurs periodically. The fix should be routine and documented so that anyone tasked with support, even a developer, could resolve the issue. By the second time someone had to fix this he or she should have opened a wiki page for "server content file synchronization" and added a header called "troubleshooting" along with mitigation steps.

Troubleshooting Ownership? If this had been one of my team members who bailed until "Henry comes back from hunting grouse" I would have questions – and not just "what in the ham sandwich is a grouse?" This is not the sort of problem that has the potential to bring down the server or cause other problems down the road – i.e. it's a manageable, solvable problem with the knowledge at hand, even if you know nothing about the synching process. For example, a developer or sys-admin could copy the file directly to the server.

This brings to mind a third related question. Why are the developers tasked with support bailing on such a simple issue? There are probably two reasons.

  • Empowerment – They did not feel empowered to resolve the issue. Perhaps they feared being locked in the Tower of London if their solution was not the one Henry endorsed. If this is the case then some mentoring is in order and some rethinking about roles.
  • Passivity and intransigence – in large applications developers "get away" with punting. Software is a black box to most end users and developers can narrow their focus down to just the tasks they most enjoy or that they are the most comfortable with. In those situations and given a superstar resource (Henry) who knows and does everything that needs to be done through his own high level sense of responsibility, developers do not reflect the same urgency of end users on bugs and service issues – knowing it will be resolved without holding them to account. Note – this matters if you are going to have your developers supporting end users. They have to adopt urgency and take ownership of an issue.

Also note that Henry's role (and personality) serve as an enabler for this to occur. As long as he's the repository of knowledge and the chief fixer we can't resolve this problem. Fixes, routines, process idiosyncrasies and procedures belong to institutional knowledge, not individual knowledge. His role actually makes him a bottleneck for work and support rather than shortening the time to fix and deploy things. His developers are less productive than they could be because he is so good at his job.

I call this team model the "superstar programmer". One guy is head and shoulders above everyone else, knows more, does more and everyone orbits around him. He does everything with excellence and alacrity but has so much on his plate that his speed and knowledge are self-defeating.

Teams matter. To get the most out of them they have to be organized around both talent and personal growth. Henry is doing too many things and especially too many trivial operational things that could be done by anyone. Those operational things need to be documented.

Let's discuss team productivity. Many people are surprised at the math of team development. If I can gain 150 hours of development, per month, from a single developer I should, theoretically, be able to get 300 hours per month out of 2 developers, 450 hours out of 4 etc. Reality doesn't work that way. A team is a network of individuals who work toward goals together. They must interact so as not to overlap. They have to meet and plan. You may not be able to divide the work up into discreet 150-hour chunks. With each new team member this problem is exacerbated as new connections, meetings, planning and divisions are made. So, a team of 5 developers may be 60 or 75 percent as effective as a team of 1 or 2. At some point economies of scale kick in and the productivity curve levels off. But the pattern resembles this chart.

Note that this inefficiency is a healthy curve. If you have done well at building your team you can expect this reduced level of productivity as the best possible outcome.

But what happens when have a rock star model? At 3 developers your rock star is managing the tasks and responsibility of his own work plus 2. At 4 developers the problem is at a breaking point. The curve dips down. There is not enough supporting work to divide up among the secondary developers. The rock star takes on more and more of the mission critical work himself. Support tasks and management tasks build up and your major talent becomes a fireman. His whole world is putting out fires all day long and he is behind the curve on each project and task trying to juggle assignments while he's still doing what he's always done.

The Fix

This is why teams and institutional organization really matter. Evolution is fine for birds but software developers tend to propagate mutations that are less rather than more beneficial. Make sure knowledge is systemetized and institutional. Don't be seduced by the superstar. To get the most out of her or him you will need to build a well supported system - otherwise she will fly off the rails as you allow her to take ownserhip of everything. Finally, prioritize between the urgent and the important. If you do have a superstar, chances are your best use of his talents will be at a higher level than troubleshooting operational issues - unless he's a sys-admin at heart (in which case hang on to him like grim death).

ColdFusion SFTP and FTPS Secure Connection Failure

I have seen a lot more people asking questions about making SFTP or FTPS secure connections from ColdFusion using the <CFFTP> tag. They are trying to figure out why they cannot make a connection. Often the error is "Algorithm negotiation fail" or "Connection Error". People are posting their questions on many support forums including Adobes forums and their new ColdFusion Community Portal. This is a problem people are experiencing in ColdFusion 10 and ColdFusion 11.

In the last few years we've seen a huge shift in SSL/TLS security including the removal of older less secure protocols and forcing secure connections to use the newer stronger protocols with stronger TLS certificates and stronger encryption cyphers. As such older systems need to be upgraded to handle the newer security protocols. More recently plain old unsecure FTP portals have been the focus of change to SFTP or FTPS.

At CF Webtools we've run into this same problem several times with multiple clients. It was so much of a problem that I needed to spend some dedicated time to see how we could resolve this issue.

The first thing I discovered is that this issue is a known "bug" that has been reported to Adobe. It's been a long known issue and somehow the fix which is in ColdFusion 2016 has not been included in an update for earlier ColdFusion versions. However, Adobe has affirmed to me that this fix is scheduled for an upcoming update.

Because it was fixed in ColdFusion 2016 I was able to inspect the included jar files to see if the one that handles CFFTP or secure communications was newer than the one(s) in ColdFusion 11. What I found is that jsch-0.1.44m.jar had been replaced by jsch-0.1.52m.jar. The JSCH jar library is the library that handles Java Secure Channel communications. "JSch allows you to connect to an sshd server and use port forwarding, X11 forwarding, file transfer, etc., and you can integrate its functionality into your own Java programs."

After seeing this was upgraded I had an ah-ha moment and figured it was worth a try to copy this newer version into my ColdFusion 11 test server and see what happened. The new version is in ./ColdFusion2016/cfusion/lib folder. You can download the free ColdFusion 2016 Developer Edition and install it anywhere so you can get access to the updated jar file. Once you have the new jar file copy it into ColdFusion 11. The proper way to do this is to remove or rename the old jar file version in your ColdFusion11/cfusion (or instance name)/lib folder then copy the new jar file version into the same folder. Then start or restart ColdFusion 11. That's it. You're done. The bug is fixed and you're good to go with SFTP or FTPS using <CFFTP> in ColdFusion 11.

This is not an approved fix from Adobe. I do not know if there is some unknown issue that could be created by doing this. However, I do know that everyone I've talked to that has tried this has had their secure FTP issues resolved. Additionally I have not tried this 'fix' in ColdFusion 10. However, if you are running into this issue with ColdFusion 10 it's worth the minimal effort to give it a try.

If you need someone to make this change on your ColdFusion server then contact us, we can help. CF Webtools is here to fill your needs and solve your problems. If you have a perplexing issue with ColdFusion servers, code, connections, or if you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations @

Connect ColdFusion JDBC to Sybase SQL Anywhere 16

This is something that might not come up often, but every once in a while we have to connect to a Sybase database. This is a built in feature in the Enterprise version of ColdFusion. However, if you have the Standard version of ColdFusion you have to manually add the JDBC jar file and build the connection string by hand. This is easy to do once you have the correct information and correct format of the connection string. Finding that correct information was nearly impossible and required a lot of trial and error.

Here's the case we had to resolve at CF Webtools. One of our clients has been using ColdFusion and Sybase for ages. For the record this is Sybase SQL Anywhere 16. For those that are not aware SAP owns Sybase thus the official name is SAP SQL Anywhere 16. For the longest time they were using ODBC connectors and older versions of ColdFusion on older Windows servers. More recently they have upgraded to ColdFusion 11 on newer Windows servers and were still trying to make the connections to Sybase via ODBC. This is a large multi-tenant operation in which there are hundreds of databases on the Sybase servers. Yes, plural servers. There are two servers that are replicated and handle failover. This means the ColdFusion Datasource connection also needs to handle failover. With ODBC failover is handled by Microsoft ODBC settings. With JDBC we had to setup failover in the JDBC connection string.


How to handle TLS1.2 for ColdFusion 9 and Older

The upcoming Authorize.NET switch to using TLS 1.2 only has a lot of people scrambling to get their servers updated. This has been a long planned transition at Authorize.NET and at many/most/all other payment processing companies. The inevitable facts are that TLS 1.0 and TLS 1.1 are outdated and they are going away. CF Webtools we have been preparing for this inevitable day for the past few years.

ColdFusion 9.0.n is not tested to work on Java 1.8 and I have had cases were certain features of ColdFusion 9 did not work with Java 1.8. I have not tried any older versions of ColdFusion on Java 1.8 and I'm not going to. Adobe has not certified any versions of ColdFusion older than version 10 Update 14 (or ColdFusion 11 Update 2 and older). All of that being said, there is a workaround that uses a 3rd party commercial solution to make TLS 1.2 connections from ColdFusion 9. It works well, but I do not recommend that as a long term solution. The preferred long term solution is upgrading the server(s) and ColdFusion version to currently supported versions. This way there will be security updates to help protect against new threats. The commercial third-party CFX tag will require recoding the CFHTTP calls for the new CFX tag. The tag is CFX_HTTP5 and it is available here.

Follow the installation instructions that comes with the download and then you will have to recode your CFHTTP calls similar to the examples below. The code examples are for the older Authorize.NET Advanced Integration Method (AIM) API calls that you are most likely using in your older ColdFusion CFHTTP calls.

<cfset authURL = "" />
<cfif AuthNetMode eq "live">
<cfset authURL = "" />

<!--- CFHTTP Call - Your code might look something like this --->
<cfhttp url="#authURL#" method="post" result="cfhttp">
<cfhttpparam type="FORMFIELD" name="x_Login" value="#AuthLogin#">
<cfhttpparam type="FORMFIELD" name="x_Password" value="#AuthPassword#">
<cfhttpparam type="FORMFIELD" name="x_merchant_email" value="#AuthEmail#">
<cfhttpparam type="FORMFIELD" name="x_delim_data" value="true">
<cfhttpparam type="FORMFIELD" name="x_test_request" value="#x_test_request#">

<!--- we're using AUTH_ONLY so the card isn't charged until the order is processed --->
<cfhttpparam type="FORMFIELD" name="x_type" value="AUTH_ONLY">
<cfhttpparam type="FORMFIELD" name="x_method" value="cc">

<cfhttpparam type="FORMFIELD" name="x_amount" value="#orderTotal#">
<cfhttpparam type="FORMFIELD" name="x_card_num" value="#cardNumber#">
<cfhttpparam type="FORMFIELD" name="x_exp_date" value="#cardExpiration#">
<cfif isDefined("cardSecurityCode") and cardSecurityCode eq "">
<cfhttpparam type="FORMFIELD" name="x_card_code" value="#cardSecurityCode#">

<!--- If you want an email to go to the customer via change this to true. Make sure is configured properly. --->
<cfhttpparam type="FORMFIELD" name="x_email_customer" value="#x_email_customer#">

<cfhttpparam type="FORMFIELD" name="x_first_name" value="#billingFirstName#">
<cfhttpparam type="FORMFIELD" name="x_last_name" value="#billingLastName#">
<cfhttpparam type="FORMFIELD" name="x_company" value="#billingCompany#">
<cfhttpparam type="FORMFIELD" name="x_address" value="#billingAddress#">
<cfhttpparam type="FORMFIELD" name="x_city" value="#billingCity#">
<cfhttpparam type="FORMFIELD" name="x_state" value="#billingState#">
<cfhttpparam type="FORMFIELD" name="x_zip" value="#billingZip#">
<cfhttpparam type="FORMFIELD" name="x_country" value="#billingCountry#">

<cfhttpparam type="FORMFIELD" name="x_customer_ip" value="#cgi.remote_address#">
<cfhttpparam type="FORMFIELD" name="x_Email" value="#billingEmail#">
<cfhttpparam type="FORMFIELD" name="x_Phone" value="#billingPhone#">

<cfhttpparam type="FORMFIELD" name="x_ship_to_first_name" value="#shippingFirstName#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_last_name" value="#shippingLastName#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_company" value="#shippingCompany#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_address" value="#shippingAddress#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_city" value="#shippingCity#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_state" value="#shippingState#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_zip" value="#shippingZip#">
<cfhttpparam type="FORMFIELD" name="x_ship_to_country" value="#shippingCountry#">
<cfhttpparam type="FORMFIELD" name="x_Description" value="#description#">
<cfhttpparam type="FORMFIELD" name="x_invoice_num" value="#invoicenum#">

<cfset response = cfhttp.fileContent>

To refactor your code you will want to do something like this.

<cfset authURL = "" />
<cfif AuthNetMode eq "live">
<cfset authURL = "" />
<!--- CFX_HTTP5 Call - You'll want to refactor your code in this fashion --->

<cfset httpBody = "x_Login=#AuthLogin#&

<!--- If you want an email to go to the customer via change this to true. Make sure is configured properly. --->
<cfset httpBody = httpBody & "&x_email_customer=#x_email_customer#">

<cfif isDefined("cardSecurityCode") and cardSecurityCode eq "">
<cfset httpBody = httpBody & "&x_card_code=#cardSecurityCode#">

<cfset cfxhttp = {}>
<cfset headers = "Content-Type: application/x-www-form-urlencoded">
<cfx_http5 url="#authURL#" method="post" out="cfxhttp.body" outqhead="cfxhttp.QHEAD" outhead="cfxhttp.RHEAD" ssl="5" body="#httpBody#" header="#headers#">

<cfset response = cfxhttp.body>

The code is a minor change and relatively easy to do. I've tested this method in a production environment and it works fine. I do not recommend this as a long term solution. The preferred long term solution is upgrading the server(s) and ColdFusion version to currently supported versions. This way there will be security updates to help protect against new threats. If you are on ColdFusion 10 or 11 then the best option is to install the ColdFusion patches and upgrade the Java version to 1.8 then you will be good to go. If you need an experience ColdFusion developer to make these changes then please do contact us, we will be happy to assist.

The CFX_HTTP5 tag uses WinHTTP which is a built into Windows PROXY server. Here is where part of the problem exists. Microsoft didn't update WinHTTP on Windows 2008 Standard SP2. They've only updated it for Windows 2008 R2 and up. See this update ( This leaves us not being able to use CFX_HTTP5 on Windows 2008 Standard and older.

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at


  • This fix will not work for Windows 2003 Server, for any version of ColdFusion, as there is no support from Microsoft for TLS 1.1 or 1.2 in this server version.
  • This fix will not work for Windows 2008 Standard Server (not R2), for ColdFusion 9.0.n and older, as there is no support from Microsoft for TLS 1.1 or 1.2 for WinHTTP in this server version.

Authorize.NET Temporarily Ending TLS 1.1 and TLS 1.0 Support

At CF Webtools we have been preparing for this inevitable day for the past few years. We've been upgrading our clients servers and services to handle TLS 1.2 calls to Authorize.Net and other third party processors for a while now. Recently Authorize.Net announced a "Temporary Disablement of TLS 1.0/1.1" for "a few hours on January 30, 2018 and then again on February 8, 2018." This is in preparation for the final disablement of TLS1.0/1.1 on February 28, 2018.

As you may be aware, new PCI DSS requirements state that all payment systems must disable earlier versions of TLS protocols. These older protocols, TLS 1.0 and TLS 1.1, are highly vulnerable to security breaches and will be disabled by Authorize.Net on February 28, 2018.

To help you identify if you're using one of the older TLS protocols, Authorize.Net will temporarily disable those connections for a few hours on January 30, 2018 and then again on February 8, 2018.

Based on the API connection you are using, on either one of these two days you will not be able to process transactions for a short period of time. If you don't know which API you're using, your solution provider or development partner might be a good resource to help identify it. This disablement will occur on one of the following dates and time:

  • Akamai-enabled API connections will occur on January 30, 2018 between 9:00 AM and 1:00 PM Pacific time.
  • All other API connections will occur on February 8, 2018 between 11:00 AM and 1:00 PM Pacific time.

Merchants using TLS 1.2 by these dates will not be affected by the temporary disablement. We strongly recommend that connections still using TLS 1.0 or TLS 1.1 be updated as soon as possible to the stronger TLS 1.2 protocol.

This means that if you are using older methods to make calls to Authorize.Net that are not capable of making TLS 1.2 connections then you will NOT be able to process credit card transactions.

This affects ALL ColdFusion versions 9.0.2 and older! This also affects ColdFusion 10 Update 17 and older. If your server is running any of these older versions of ColdFusion and your server is processing credit cards with Authorize.Net then this advisory applies to your server.

CF Webtools has been successfully mitigating this issue for clients servers for the past couple years and we are very experienced in resolving these security related issues. In a previous blog post I tested which SSL/TLS levels were supported by various ColdFusion versions on various Java versions and produced an easy to read chart.

If your ColdFusion server is affected by this or if you do not know if your ColdFusion server is affected by this then please contact us (much) sooner than later. Our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at

ColdFusion MailSpoolService Performance

In my last article about the Adobe ColdFusion MailSpoolService I mentioned that I was going to try to get specifics on expected performance in the Standard Edition vs Enterprise edition of the MailSpoolService. Adobe has not respond to my requests with actual data. While attending the ColdFusion Summit 2017 I tried to get a clear answer from any of the Adobe ColdFusion engineering team members that were at the conference. They didn't know the answer. Because I didn't get the response I wanted from Adobe I decided to start testing.

My first test was to setup a Windows VM with ColdFusion 11 installed with a standard license. I also created a simple CFML page that uses CFMAIL to send an email with a CFLOOP to send that same email a lot of times. To make this a more realistic test I made up a new disposable email address on our mail server at CF Webtools and sent the emails from my email server on AWS. This means that the ColdFusion MailSpoolService has to actually communicate with a mail server. SMTP connections can at times take time. The emails I generated have several paragraphs of Lorem Ipsum text to simulate actual email sizes. My first test was to verify one email did indeed get sent. It did. The next test was to send 1000 emails while timing with my iPhone's stop watch. We also have ColdFusion 11 Enterprise which meant I was able to test the performance against the Enterprise Edition. Lastly, I was asked to test on the Developer Edition because it is often stated that the Developer Edition is essentially Enterprise Edition with a two connection limit. I ran this test a couple times each from ColdFusion 11 Standard, ColdFusion 11 Developer, and ColdFusion 11 Enterprise servers.

Standard Edition
It took approximately 23 minutes to process 1000 emails in the mail spool. This comes down to about 44/45 emails per minute. Which works out to about 11/12 emails per 15 second pooling interval or 2600 email an hour. Which is a little more that 60,000 emails per day processing 24 hours straight without any connection issues. That's not too shabby for being the single threaded version of the MailSpoolService.

Developer Edition
After running the same tests a couple times in Developer Edition I got the exact same results as I did for Standard Edition.

Enterprise Edition
This is where you can say "You get what you pay for!". Before I go into the numbers let me also remind everyone that the Enterprise Edition of the MailSpoolService is multi-threaded and you can specify the number of threads. I think the default is 10 threads. This setting is in the Mail section of the ColdFusion Administrator Enterprise Edition ONLY in the sub section "Mail Spool Settings". There is nothing that indicates that there is a maximum number of threads. My tests are with 10 threads.

I had to run this test several more times just to make sure I saw what I saw. All 1000 emails were sent in a single polling of the mailSpoolService. That's 1000 emails sent in under 15 seconds. I ramped it up a bit and sent 5000 emails. This time it took two polling intervals and sent 5000 emails in about 30 seconds. To get absurd I increased the test to 10,000 emails and the Enterprise Edition cleared those out in less than 60 seconds. This means it took 4 polling intervals to process 10,000 emails which comes out to 2,500 every 15 seconds with 10 MailSpoolThreads. I wanted to verify this exactly so I decreased the polling interval from 15 seconds to 30 seconds. I wanted to fill the mail spool completely beforehand and see how many emails were processed on each polling interval. What I saw is that I'm not nearly at the limit of what the Enterprise Edition MailSpoolService can handle. By slowing down the polling interval my CFML script was able to put all 10,000 emails into the mail spool folder before the MailSpoolService started processing. Then it happened, all 10,000 emails were process in one single polling interval of less than 15 seconds time. I'm not sure were the limit is, but it's fairly clear that the Enterprise edition can send more emails than most of us will ever need. Even if you're running a bulk mail service.

My results are not scientific. However, I do believe they are closer to what real people will see on real servers based on my experience with hundreds of servers. It would be really nice if Adobe would respond with some real numbers so we could help clients decide if this feature is worth buying Enterprise Edition instead of Standard Edition. However, based on my testing, if sending emails is your high priority and the amount of emails is going to be over 50,000 emails per day then you might want to weigh the cost of an Enterprise license.

The reason I was testing on ColdFusion 11 is this is the version that several different clients have that are having issues with the MailSpoolService. I think I know that for one client they really are trying to send near or over 50,000 emails per day and this is why they thought there was an issue with the MailSpoolService.

Cryptocurrency Miners Hacking Servers

Are your free CPU cycles making others rich? There's a chance they are and it's at your expense. A recent article at states that "At Least 1.65 Million Computers Are Mining Cryptocurrency for Hackers So Far This Year". If this is to be believed then it's possible a server you are running has been compromised and is actually mining cyrptocurrency for the hackers.

Cyrptocurrency is an anonymous, digital currency that is supposed to be untraceable. It's used on the internet to purchase more and more products and services. One of the most common forms of cryptocurrency is Bitcoin. This is from the Wikipedia entry on Bitcoin.

Bitcoin is a worldwide cryptocurrency and digital payment system called the first decentralized digital currency, since the system works without a central repository or single administrator. It was invented by an unknown programmer, or a group of programmers, under the name Satoshi Nakamoto and released as open-source software in 2009. The system is peer-to-peer, and transactions take place between users directly, without an intermediary. These transactions are verified by network nodes and recorded in a public distributed ledger called a blockchain. Besides being created as a reward for mining, bitcoin can be exchanged for other currencies, products, and services. As of February 2015, over 100,000 merchants and vendors accepted bitcoin as payment. Bitcoin can also be held as an investment. According to research produced by Cambridge University in 2017, there are 2.9 to 5.8 million unique users using a cryptocurrency wallet, most of them using bitcoin. ...

Bitcoin Mining is a record-keeping service that runs on peoples computers, servers, or specialized Mining Devices, that are setup by individuals to help process Bitcoin transactions. As a reward for doing this you are given newly created bitcoins and transaction fees. ie. You can make money by mining for Bitcoin.

This reward is enough that hackers have taken it to the next level and started hacking servers around the world so they can install mining software and use YOUR computers and servers to make money for themselves. Just this week it was discovered that some of Showtime's web servers were mining cryptocurrency. This isn't a new thing either. Back in 2014 Iowa State University servers were also hacked for the purpose on mining Bitcoins. These are not isolated occurrences. They are happening regularly. This practice is free to the hackers an costly to the owners of the servers. Here's why.

Case Study

CF Webtools has seen this type of hack in the real world. We recently had a company come to us seeking our services for both Server Administration and ColdFusion programming. Part of taking this new company on as a client we performed a security review on all of their servers. They also had existing issues that we needed to look at in particular. One of their web servers was rebooting multiple times per day at what seemed like "random" intervals.

Upon review we found the web server was always running at 100% CPU usage with no services claiming to be using that much CPU power. Certainly not ColdFusion or IIS. After completing additional research we decided to install a malware removal tool and scanned for malware. It didn't take long to find that indeed there was malware running on the server. What we found surprised us only because we had not seen this in action before. It was a cryptocurrency miner and it was so intensive that it would crash the server. All attempts to remove the malware failed. It would end up back on the server in a short period of time. The fact is this server was compromised. To resolve the issue we sent one of our decommissioned, but powerful servers, preinstalled with a clean OS to their data center. Then our Operations Manager went on the road to install the new server as well as a physical firewall. We essentially rearchitected their entire server setup. Meanwhile the malware removal tool did it's best to keep the malware at bay while I recreated their web server on the new server. It was a busy week (or more), but we were able to clean the code on the clients server and put that on the new server. We also had to research and rebuild all the dependancies from scratch. When it was all said and done we replaced the compromised server with the new one and put all their servers behind a Cisco ASA.

This case of Hacking for Bitcoins proved costly in the end to the company who's systems were compromised all while providing a free profit to the hacker(s).

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at

ColdFusion Security Patches ColdFusion 11 Update 13 and ColdFusion 2016 Update 5

Adobe just released security updates for ColdFusion 11 and ColdFusion 2016. This is a critical security update and you should be updating your ColdFusion servers. The information below is from the CF Webtools operations group. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at Meanwhile, this info below will help IT staff and DIY types get started.

With ColdFusion 11 Update 13 and ColdFusion 2016 Update 5 there are additional manual updates that are required to complete the security patch. The additional requirements are the same for both ColdFusion 11 and ColdFusion 2016 and the remaining information pertains to both versions. Both updates require that ColdFusion be running on Java version 1.8.0_121 or higher. For reference, ColdFusion 11 comes with Java version 1.8.0_25 and ColdFusion 2016 comes with Java version 1.8.0_72. The Java that needs to be installed is different from the "Windows User" Java client that may already be installed. The installer is available from Oracle. Once the new Java version installed, the jvm.config file for each ColdFusion instance needs to be updated to point to the new Java version installation path. If you're running the Enterprise version of ColdFusion, there's a likely chance there is more than one ColdFusion instance running.

Part of the instructions from Adobe says that if your ColdFusion server is installed as J2EE server then there is an addiction manual configuration that you ned to do. However, every installation of ColdFusion since the release of ColdFusion 10 is a J2EE or JEE installation. What Adobe really meant was that if you are using a third party JEE server and not the built-in Tomcat JEE server.

If your ColdFusion server is running on a third party JEE server such as WebLogic, Wildly, custom Apache Tomcat, etc (Not the built in Tomcat that comes with ColdFusion), then the following step needs to be completed.

Set the following JVM flag, "-Djdk.serialFilter=!org.mozilla.** ", in the respective startup file depending on the type of Application Server being used.

For example,

  • On Apache Tomcat Application Server, edit JAVA_OPTS in the 'Catalina.bat/sh' file
  • On WebLogic Application Server, edit JAVA_OPTIONS in the 'startWeblogic.cmd' file
  • On a WildFly/EAP Application Server, edit JAVA_OPTS in the 'standalone.conf' file

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them or if they are not familiar or knowledgeable with ColdFusion contact us at CF Webtools to patch your servers.

As always, if you need help migrating to the next version, scanning your ColdFusion server for security vectors or installing this patch and new Java version, contact your project or account manager directly, or send an email to You can also simply respond to this email (or call 403-408-3733).

*Note: ColdFusion11 when it was first released came with a version of Java 1.7.0_nn. Adobe later re-released ColdFusion 11 with Java 1.8.0_25. If you have ColdFusion 11 still running on Java 1.7 I highly recommend that Java be upgraded to Java 1.8. Oracle is no longer supporting Java 1.7 and 1.7 is long past it's end of life. Even though the Adobe instructions for this current security update states that you can run Java 1.7.0_131, I highly recommend upgrading to Java 1.8.

Mary Jo Sminkey: Robust Error Handling Part 3 - Ajax

Part 3 in the super-guru's Mary Jo Sminkey's series on robust error handling. Enjoy!

So in my last post on error handling, I promised in this next one to cover logging of Ajax requests. As more and more of our site involves Ajax requests, this has become an important part of my error logging and debug work. If you want to know how to do this read on!


"Send us a Developer Oh Lord!" - He cried from his lonely chariot.

p> Yes yes yes! CF Webtools is hiring again. We are looking for 1 to 3 advanced ColdFusion programmers to add to our already large team of CF folks. Here's the stuff everyone wants to know.
  • Yes these are remote development positions.
  • No we are not hiring outside the U.S. (sorry!)
  • Yes the position is W2 with benefits after a short (30 day) trial period.
  • Yes benefits include health care.
  • No our health care is not as good as congress' health care - but it's pretty good for a small company.
  • Yes there are other benefits - 401k, dental, PTOs, disability, life insurance, and hearing from me almost every day.
  • No our developers don't walk on water every day - we save that for the second Tuesday of months ending in "Y".
  • Yes we work on interesting projects and applications accross the board in Insurance, government, health care, finance etc.

We are a company out to build a positive culture and work environment where you can shine and feel good about what you do. We are looking for developers that match our culture of Can-do, Caring, Communication and Competency. Here are some examples of what we expect.

  • You should be able to setup multiple local environments, or at least not be scratching your head at that phrase. Mac and windows are required. Advanced developers do advanced things like (for example) set up an Apache or IIS web site and connect ColdFusion to it. We see this as indicative of your problem solving ability as well.
  • You should be able to work with SVN or GIT (and no we don't want to see your white paper on why GIT is superior).
  • Maintain positive attitude - We are not looking to hear about your pet technology peeves, your problems with Adobe or why the command line is always superior to a gui. If you are not interested in being a net blessing to a larger group (or if a lack of snark makes you queasy) we are probably not a place for you.
  • Maintain and enhance your skills set - you will be given the opportunity to work on lots of code, different versions, platforms, integrations, libraries and SDLC organization and procedure. Everyone of these is a growth opportunity. If that has you licking your chops climb aboard.
  • Balance - We like devs who have a full life. If you enjoy fencing, equestrian sports, skydiving, guitar playing, dog training, macrame, Golf, racquetball, Mandarin, Politics (careful!), family outings, child rearing, school plays, choirs, baking (all activities enjoyed by folks on our team) then we think those things make you a better developer! We aren't looking for 80 hour a week developers slavishly devoted to coding. We are looking for eclectic, interesting people who enjoy coding and want to do it for a living.
Hopefully this helps explain how we operate enough to pique your interest. If you want to take a shot send your resume to or call (402) 408-3733 ext 102 and ask for Jason. We look forward to hearing from you!

Up to $1000 Referral Fee!!

CF Webtools has revamped its awesome referral program to make it awesomer - or even more awesome. As you may know we have been offering generous referral bonuses to developers for years. If you bring us business we try and reward you. In 2016 CF Webtools paid out nearly $100,000 in referral bonuses! But our old program was hard to understand so our marketing guy - Curt - has twisted my arm to make better.

Here's the Deal

If you bring us business you get $500.00. Any business. A mom and pop store, someone selling pet insurance, an app for measuring dog poo by volume and color - we don't care. If it's business and we make a sale, you get $500. But wait there's more. If said business turns into at least 150 hours you get an additional $500! So, you can make $1000 just by name dropping.

The Part Curt Doesn't Like

Now I will have to avoid Curt for a few days after I say this, but if you bring us a whale - a customer with regular work involving at least half a developer (hopefully the top half) I will be even generouser - or even more generous. Call me and we'll make a deal. I promise we'll make it worth your while.

CF Webtools Pledge

So, your grandma is selling needle point online and you want to refer her to us but you are afraid. Maybe you fear we will treat her poorly, or that we won't take "" seriously. Be reassured by the following Muse Pledge to you:

We will Reward You.

We will Make you Proud.

We will not Embarrass you.

We want to make you happy you turned over work to us. We will make every effort to insure it is a good experience.

What sort of thing qualifies?

CF Webtools has a large and diverse staff. Don't assume we won't be interested just because we shout "ColdFusion" all the time. We have a dedicated operations group for managing large technology stacks. We do IOS and Droid development. We manage complex databases and are familiar with many different environments. Give us a call and find out.

It's complicated

Ok, so you have a problem client or former employer where you had a bad experience. We get that. From month to month we are often embroiled in handling a "hand off" from a developer or company where things went south. We specialize in working hard to smooth things out for the customer and we do it without throwing the former developer under the bus. We will concentrate on the work and do our best to make you look good. If you don't want us to mention your name we won't. If it will help and you say it's ok we will. You will find us easy, dare I say charming to work with.

How do I make it happen?

  • Call Curt Lovegren at (402) 408-3733 ext 104 or...
  • Email your lead with as much information as you wish to
Before we call or email your lead we will contact you via email (or phone or carrier pigeon, whatever you prefer) and discuss the details and how to move forward. Our approach can involve you directly or we can leave you out of it - it's totally up to you.

We'll look to glean any information that can help us be of benefit to the prospective customer. Just reach out and let our staff do the rest. Easy, right?

Building a Robust Error Handler Part 2

The Muse is fortunate to have a number of very talented and smart developers work for him. Mary Jo Sminkey has been with CF Webtools for several years now and we simply love having her around. She's a fantastic developer and a fantastic resource. You might catch her at cf.objective() where she will be speaking next week.

Meanwhile, you might remember part 1 of this series – Building a Robust Error Handler. Below is part 2 in that 3 part series. Enjoy!

Well it's taken a couple years to get around to it, but at long last here is part 2 of my error handling post! Of course, in that time I've continued to work on improvements to my error handler, so many changes that I'm going to need to break THIS post up into multiple parts as well. I'll try not to take too long to get the final part out to you!

So in part one we looked at things like using the error handler for both global errors as well as in cfcatch blocks, dumping all the available scopes while scrubbing them for any sensitive data, keeping track of already reported errors to prevent receiving tons of duplicate emails for the same error, etc.

In this post (part 2) we will expand the functionality of the error handler and talk about strategies for use throughout the application. Let's start with how to handle errors "in depth".


Customers and how they Contribute to Estimating Angst

This is the moment the developers have been waiting for. After having thrown both the developer and his application under the bus, we are going to make room under there for the customer. Now if you are customer reading this, take heart. While I'm going to say some things that will hurt, in the end I'm going to rub salve on the wound and we will all sing Kumbaya together. Here we go.

The Muse finally has a number - a project that we've estimated at 350 hours. Of course, this estimate is not correct. Why? Because no estimate is ever correct. Please refer back to the first post in this series. The majority of estimates are wild guesses. We've done our best to find out all we can about the system, requirements, priorities and every little nitpicky detail we can imagine. Our estimate is based on that discovery. If all of our dozens of assumptions are correct then our estimate is rock solid. But of course, there are still things we don't know and many of our assumptions are simply off. Much of what we need to know we simply can't know until we dig in and start doing the work. For that reason we will give Bob a range of hours - say 275 to 375 hours - and dozens of caveats that he will epically fail to hear and absorb. What he will hear is the number 275 and that will be the basis of his expectations.

Let's check in with the Muse and Bob as they finalize the project.

  • Muse: Well Bob, as you can see by the painstakingly detailed 13 page document in front of you, we estimate 275 to 375 hours. Have you read the document?
  • Bob: I read... I got to page 2... uh... I did see the estimate at the end. So, 275 hours?
  • Muse: [caveat 1] 275 hours to 375 hours. You can expect it to be somewhere in the middle.
  • Bob: 275 eh? Wow that's a lot. But I get everything I asked for?
  • Muse:[caveat 2] To be clear you get everything we have carefully outlined and detailed in the proposal. If it's not in the proposal it would be "out of scope" - not included in this estimate.
  • Bob: Well, I can probably swing 275 as long as I can have it in 6 weeks.
  • Muse: [caveat 3] Well the timeline depends on resources and other factors. This is probably a one-woman job. It will take her around 4-5 weeks to do the core programming, then QA, revisions etc. You are probably looking at 8 to 10 weeks. [Caveat 1 again] It's 275 to 375 hours not including out of scope items that tend to arise.
  • Bob: Hmmm.... ok, I think we can do it. But just one thing. Did we discuss adding reporting to this application?
  • Muse: ...
  • Bob: Muse... you there? Did we lose our connection?
  • Muse: I'm here Bob... I was just asking my assistant to quickly remove sharp objects from my immediate vicinity. Now about your reporting...

Most clients are not quite as bad as Bob. Still, every contractor or development shop owner has a story remarkably similar to the one above. I know most Muse readers are developers. I can see you now in my mind's eye with righteous indignation and clenched fist saying, "You tell them muse, clients are the worst!" But actually, this is not their fault. Your customer has his or her own domain of knowledge. I have a customer who is a commodity trader. I expect him to know the difference between a bull call and a butterfly spread, but I do not expect him to know the difference between MySQL and MS SQL, how the cloud works, or why it takes 10 hours to program something. The basic issue is threefold:

  • Communication
  • Expectations
  • Cart and Horse problems
Today let's tackle the first two.


Developers, Can't Live With 'em, Can't Deprecate 'em

When last we checked in with Bob and the Muse (part 1 - applications) they were trying to come to grips with Bob's complex... I mean his application's complexity. We are now at the stage called "developer involvement" where he and the Muse are speaking with Sugar Sweet - the Muse's crack developer (and the name of a girl I dated in college). Let's go live to the conference call (be careful not to spook them).

  • Muse: Ok, we've outlined changes to the onboarding and broken it out into 3 programming tasks. Sugar will get us an estimate but it seems straightforward.
  • Sugar: Muse, a moment.
  • Muse: Sure what is it sweetie? (Don't judge me - it's her nickname so it's not harassment)
  • Sugar: I've taken a look at this application and the entire thing will need to be rewritten.
  • Bob: Wait what? That sounds expensive.
  • Sugar: I'm afraid we have no choice Bob. It's written in tags and the variable naming is all wrong. Plus the previous developers used... sorry, this is hard, I'm getting a little choked up... cfqueries instead of stored procedures. [small sob]
  • Muse: I'm going to step in here while Sugar get's a drink of water. We will work to retain as much of the legacy code as we can and focus only on security issues Bob. In other words we Won't refactor your code unless it's necessary to protect your investment. How does that sound.
  • Sugar: [sounding a little hurt] But the queries... and our best practice guide!
  • Muse: I think we can work with what we have here...
  • Sugar: This is so hard. I feel beet down. I'm not sure I cane work here anymore.

Developers come in all stripes and their views will greatly impact your estimate. Some of them have a religious devotion to certain technologies, libraries and approaches to development. To be a developer (at least on my staff) requires high aptitude, intelligence, breadth of knowledge and confidence. Those traits generate towering personalities like the Muse (whose lack of modesty is his only real flaw), and of course egos. They have opinions and they are usually not afraid to use them. Their defensive ferocity increases exponentially the closer you get to their favorite technology. If you don't believe me try yelling "Windows rules" at an IOS conference (and hope it's not an open carry state). For this reason, it's always a good idea to have non-developers involved in your estimates. Around here we call them project managers. They use their knowledge of the developer and the customer to "find the sweet spot" that meets the needs of the application and its stakeholders.

Muse Wisdom: Estimating is usually a joint effort.

Of course, not every estimate needs the once over by a project manager, but larger projects or enhancements should always be a collaboration. Developers need to be able to justify the estimates they provide to someone who knows them well enough to understand how they might get tripped up. Here are a few "types" of developer estimators.

The Refactorer

Sugar is in this camp. She will like over-estimate every task on older code because she sees any legacy code as debt that needs to be paid. To her this isn't optional, it's essential. In the real world it's definitely optional. Is script better than tags - in most cases yes (don't email me). Is using jQuery better than custom JS libraries? I believe it is. Are stored procs better than queries? Usually they are (though I've seen some god-awful stored procs). Best practices, frameworks, indentation, file naming conventions - these are all important parts of competent development. But when approaching legacy code there is a lot to consider. For example, has the customer managed to get a return on his initial investment? If he has, he may be ready for a rewrite. If not, we may need to work with what is there and not break the bank rewriting huge swaths of code. The business decisions rule the day. It's important for developers to understand the economics in play.

The Blithe Underestimator

Estimating is about imagining what could happen. What if the user doesn't check the box - what happens then? What happens when a user doesn't follow your pattern and puts in letters where numbers are indicated? Most developers react to these conditions with frustration. Who would do that? Why would a user use the application in that way when it's clearly designed to be used this way. A good estimator considers all these what-ifs. Estimating is also about accounting for what you still don't know. It's about challenging your assumptions. The underestimator concentrates on what he sees in front of him. His estimate comes with the caveat "if all my broad assumptions are correct". A good project manager will know the developer well enough to A) challenge him on his assumptions and B) add hours to the final estimate to insure it's adequate.

The Over-Complicator (Chicken Little)

Some developers are the opposite of the blithe underestimator. Instead of broad assumptions they build a huge list of unknowns and caveats. How do you know if you are an overcomplicator? Here's a little test for you. Let's say uou pull up Google and the page fails to load. Order the following list by probability.

  1. Google is down
  2. The entire internet is down
  3. It's the zombie apocalypse
  4. You've typed in "" accidently
  5. Your wireless connection is bad
  6. The network is under attack
  7. Your mom changed the wireless password again (for those you working in your basement)
  8. The NSA is monitoring your computer
  9. DNS is not responding
If anything but number 4, 5, 7 or 9 is near the top of your list you may be an over complicator.

Some time ago I was helping a Muse reader with an error via screen share. On the screen the error debug information had query code and indicated a malformed query. I asked what he had tried. "I tried a new DB driver, checked the network connection and I've been googling how cached execution plans work." I took a closer look at the debug output on the screen, highlighted a portion and said "You are missing a comma after this column." A good manager will know his devs well enough to spot an over estimator and adjust estimates accordingly.

The Technology Hammerer

Finally, there is the developer for whom everything is about tech. The saying goes that when your only tool is a hammer everything looks like a nail. Developers need to be reminded that what they are solving are behavior problems, not (typically) technical problems. When we build a new search engine for a company selling nuts and bolts, the problem we are solving is not faster indexing, better sorting, or more granular pattern matching. nope. It's the basic problem of folks rummaging through bins trying to figure out thread and length. We are trying to make that task easier.

The tech hammerer will turn to the technical aspects of a project over and over because that is her comfort zone. She will suggest products, approaches and solutions that may or may not solve the basic problem underlying the project.

Tech hammerers usually need to learn that it is highly beneficial to gather domain knowledge about your customer. What does the company do? How do they make money? (that's the most important question for a dev company like ours) What sort of problems do they solve with their application? These questions inform our decisions in ways that mere technical questions cannot. Moreover, they tend to make us better partners - better at suggesting changes that save or make money for the customer. "What if we chose to do it this way Bob, would that save your users a step? Do you really need this field, it seems like we have this covered with earlier data. Explain how this will help your user - I want to understand."


The main takeaway here is that developers and their personalities have an impact on your estimates. Estimating is a team effort and requires give and take from several sectors. In our next post we are going to throw customers under the bus - gently of course.

Why is Estimating So Dang Hard

Let's go Live to Bob and the Muse

Consider this typical interaction with a prospective customer:

  • Muse: Tell me what you need Bob.
  • Bob: I have an application hosted on ColdFusion 9. I want to upgrade to the latest version and move it to the cloud.
  • Muse: That's a good choice. The latest version of ColdFusion performs splendidly in the cloud and is much easier to manage. (yes the Muse uses words like "splendidly").
  • Bob: Great! How much will it cost me.
  • Muse: Well.... [lengthy pause]
  • Bob: Did I lose you? Muse... Hello...
  • Muse: Oh I'm here. I have some questions. What kind of application is it?
  • Bob: It's a customer portal where folks log in and use our whizzbang service.
  • Muse: Do you use any third party APIs?
  • Bob: Pbbbt... of course not.
  • Muse: Excellent - how about jar files. Do you remember using any jar files in your code to access Java stuff?
  • Bob: Jar files? What in the ham sandwich is a jar file?
  • Muse: It's a way you package Java classes. You might use it to do some complicated Java thing that ColdFusion can't handle on its own.
  • Bob: Uh... [Lengthy Pause]
  • Muse: Did I lose you? Bob... hello? Maybe we'll put a pin in that one.
  • Bob: Sorry my eyes just glazed over there for a second. Anyway, how much did you say?
  • Muse: Well I'm not sure I have enough information to uh...
  • Bob: Oh! and we also need to upgrade our thingy that posts reviews to Amazon and Yelp. Something about bees... apiary or something.
  • Muse: API Library maybe?
  • Bob: That's it!
  • Muse: [banging head on the desk] ok how about you walk me through the app.
  • Bob: Sure ... but... how much will it cost?

Now it's not the Muse's fault that he's having a hard time communicating. After all, if it was easy I'd be flipping burgers and still driving my '72 delta 88 from College. And before you get all up in Bob's grill, it's not his fault either. We IT natives tend to use lingo as if everyone has been exposed to the concept of an "API" or "java integration" or a "mouse".

So I'm going to let you in on a little secret. The bald truth is that development companies usually have no idea what something will cost even after you describe it to them thoroughly. The most accurate estimate for enhancements will always come from the original developer, and even then, they are often guessing wildly.

Muse Wisdom: Don't trust quick estimates or high levels of certainty!

Chances are if someone is throwing numbers around without asking a lot of questions and without being nervous about "guaranteeing" the cost, you are about to enter a relationship you will regret. Think Vegas chapel and too much bourbon and you'll get the idea. To help further the conversation about estimates I offer this 3-part blog series on "The hard task of estimating". My hope is that in the end, readers who are customers and readers who are developers will both come to understand a little more about this maddeningly ticklish task that we all must do.

Estimating is hard and estimates are often unreliable because of three main areas where issues arise:

  • Applications
  • Developers
  • Stakeholders or Customers
In this post we are going to talk about your application.


More Entries

Blog provided and hosted by CF Webtools. Blog Sofware by Ray Camden.