Orange is my favorite color » My Software

CFPAYMENT now on GitHub

brian — Wed, 05 Jun 2013 17:05:29 +0000

I see people in ColdFusion land still reinventing the wheel in writing payment gateways. Stop! Believe me when I tell you there are 502 ways for a payment request to fail and I’ve experienced every single one of them! The open source payment processing library, CFPAYMENT, has processed tens of millions of dollars in production applications over the past 5 years. Either use one of our supported gateways (including the very cool Stripe) or write a tiny amount of code to translate requests from your gateway of choice.

To encourage you to leverage rather than rebuild, I’ve moved the source to GitHub where you can fork and pull:

https://github.com/ghidinelli/cfpayment

There’s also a Google group where I provide support if you want to use a gateway we don’t yet include. I’ll help you understand how to use the library and extend it so you don’t go through the pain of learning the hard way how transactions can fail in production.

Faster unit tests with ColdSpring and MXUnit

brian — Thu, 28 Mar 2013 00:07:32 +0000

Nerd post today. Most of my MXUnit unit tests look something like:


	
		variables.beanFactory = createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init();
		variables.beanFactory.loadBeansFromXmlFile("/config/globalbeans.xml", true);
		variables.service = variables.beanFactory.getBean("BatchbookService");

You can read more about my localMode trick for testing remote APIs but I’m simply loading up my Coldspring configuration file for my app which includes dozens and dozens and dozens of beans. I have three problems with this:

The unit tests depend on the configuration used to run the site which might not always be in my environment
It slows down my tests by generating beans that my unit test doesn’t need
My production and test bean config may not be the same (credentials, etc)

I might be able to get around #2 by using lazy init but the principle still holds: the unit test should be as standalone as possible. In the case I’m working on today, I have a client I’ve written (and released) for a third party API from Batchbook. But I need to have some Batchbook-to-My-App conversions of JSON to queries and so forth. I don’t want to bake those into my publicly-released client so what I really want in my production app is some bean config that looks like:


	
		
	        password
	        https://somehost.batchbook.com/api/v1

But if my BatchbookClient is a nested constructor-arg, how can I get it from the beanfactory to test it?

Alternative Coldspring Configurations

Turns out there’s more than one way to load beans into Coldspring and passing a path to an XML configuration file is just one. Looking over the 1.0 reference guide, I found two additional methods of interest:

loadBeansFromXmlRaw(xmlStringConfig, true)
loadBeansFromXmlObj(parsedXmlConfig, true)

Applying that to my current unit test, my setup method now looks like:


	
	

	
		
			
				
			
			
		        password
		        https://somehost.batchbook.com/api/v1
				
				
			
			
			
		
	

	
		variables.beanFactory = createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init();
		variables.beanFactory.loadBeansFromXmlRaw(beanConfigs, true);

		variables.bb = variables.beanFactory.getBean("BatchbookClient");
		variables.svc = variables.beanFactory.getBean("BatchbookService");

Coldspring now instantiates much quicker and it only loads beans related to my unit test. Plus, I have the flexibility to directly address the BatchbookClient and run it through its paces alongside the BatchbookService.

If you only have a few unit tests, these improvements won’t mean much but as your test suites grow (and you work towards continuous deployment…) you will find that speeding up testing is always a good thing and helps encourage you to do it.

CFPAYMENT 1.0 Released!

brian — Thu, 22 Mar 2012 02:41:33 +0000

Payment processing is a lot of boilerplate code that isn’t much fun to write. More importantly, when you make a mistake, it usually means a lost sale or, worse, a double charge you have to track down and refund.

CFPAYMENT makes payment processing easy. It’s a ColdFusion library modeled after Ruby’s ActiveMerchant that normalizes various payment gateways to give developers a single interface to process credit card and ACH transactions. After years of production use and tens of millions of dollars processed, I’m proud to announce a 1.0 release is now available at cfpayment.riaforge.org.

There’s a lot of hard work from many different folks that have made this a success. If you’re interested in learning more, download the file and check out docs/cfpayment.pdf or hit up the Google group at http://groups.google.com/group/cfpayment.

Create contacts with the Batchbook API + ColdFusion

brian — Tue, 31 Aug 2010 00:47:50 +0000

This is going to be mostly code because I don’t have time to really annotate much. However, if you’re an Adobe ColdFusion developer and you also use (or are considering) the very good Batchbook Social CRM then you may also want to use their REST API in order to programmatically create or read your contact data.

While Batchbook does have the pretty cool web forms which can capture contact data from any ole web form, it doesn’t give you total flexibility with filling in customized data fields. In our case, we wanted to create companies rather than individuals as part of a sales pipeline so we needed to have more control than the web forms currently allow.

Start with a contact form

Here’s the HTML form that we’re using – it still uses the original web form field names so all I’ve done here is changed the form ACTION to point at my CFM instead of Batchbook:



Sign-up Now!

Company *

Account Type *

First Name *

Last Name *

Email *

Phone *

Organization Address

Address 2

City, State Zip
,  
Company URL

Do you have an existing service?  If so, which:

Date of next event:

Format date like mm/dd/yyyy
Questions/Comments

It’s the same contact form you’ve whipped up 100 times before. If you’re using the built in web forms, the field names must match what is above. If I was writing my form handler from scratch I would have selected more normalized names.

Note that we a hidden field at the beginning – not all of the data must be user editable. Of course, I could also just set it in my form handler. The country value is a holdover from the original web form.

Process those fields

Our next step is to process that form submission with ColdFusion and use the Batchbook API to create my contacts and populate my custom data fields:

< !--- credentials --->
< !--- get this from "Your Account", right column --->



	
	

< !--- cfdump var="#cfhttp#" --->



	
	
	< !--- cfdump var="#cfhttp#" --->

	
	

	< !--- now add location to company --->
	
		
		
		
		
		
		
		
		
		
		
	
	< !--- cfdump var="#cfhttp#" --->

	< !--- set default values for sales super tag and capture user-provided information --->
	
	
	
	
	
	
	
	
	
	
		

	
		
		
	
	< !--- cfdump var="#cfhttp#" --->

	< !--- create person--->
	
		
		
		
	
	< !--- cfdump var="#cfhttp#" --->

Some notes about the above:

What’s my password? Your password is X. Or Y. Or Z. It doesn’t matter – Batchbook only authenticates you on your unique key which is sent as the username. The password can be anything.
If you’re new to REST APIs, I suggest enabling the CFDUMPs as they will show you how data comes and goes. Plus, you’ll see what the response headers look like (hint, they aren’t all 200 OKs).
Associating people with companies – there is no official way to do this. Just make sure the “company” value for the person is a string match for the company record and Batchbook will make the magic happen on their end.
There is basically no error checking or exception handling here – I’ve got my code wrapped up in some try/catch and I fall back to sending an email to us if all else fails. Plan for failure. At some point the API will be down or the Internet will break and you need to have a contingency plan when dealing with remote third parties.

The above code took me a day or two of toying around to get working properly. While the docs are pretty good, my experience is that API implementations never quite match their documentation. Getting super tags to work (key to our sales process) took a lot of fooling around plus some assistance from the very helpful Eric Krause at Batchbook.

Next post will be how we’re integrating the results of this sales pipeline with Email Center Pro to dynamically generate and send out contracts in preparation for our sales cycle this winter.

Bounce Detector r18 Released

brian — Fri, 06 Aug 2010 04:56:43 +0000

Catching up on our unmatched nightly bounces, I released an updated version of my Bounce Detector CFC on riaforge tonight. Bounce Detector looks at returned email bodies and uses a lengthy signature list to identify the cause of the bounce. Switching to an SVN commit release numbering system, tonight’s r18 includes a few important updates:

New limited support for autoresponders and OOO messages which return a code “5″
Added new temporary, permanent and spam bounce signatures
Added new demo that doesn’t require Coldspring to simplify integration for new users

Download it from bouncedetector.riaforge.org today and upgrade!

Using BounceDetector without Coldspring

brian — Fri, 25 Sep 2009 17:38:46 +0000

James Moberg asked how to use BounceDetector without Coldspring this morning. Personally, I think you’re crazy if you don’t use Coldspring, but I whipped up a demo in order to explain how to parse the bounce signatures database and manually create the BounceDetector instance if desired. You can find the file in subversion called demowithoutcoldspring.cfm. The only real work is parsing the XML and replicating the functionality in Coldspring that creates an array of structs from an argument that uses the and tags:

But seriously, just drop in Coldspring!

Deploying assets to Amazon S3 with Ant

brian — Wed, 02 Sep 2009 17:19:18 +0000

In my previous post on storing web assets on Amazon S3, I promised to share the Ant script I developed from a week of work and testing to jumpstart your own efforts. Let’s look at what I wanted to accomplish.

The Ideal Deployment

The ideal deployment would accomplish a number of things that I listed in my post such as:

Combine multiple Javascripts or CSS files to reduce download count
Automatically set far-future headers, mime type, encoding and so forth
Grab remote scripts like Google Analytics or AddThis’ sharing widget and bundle it into our core code (see why and discussion)
Strip and minify Javascript and CSS to reduce file size
Finally, compress text files for browsers that support Gzip and upload them automatically

That’s a good wish list because it’s everything I did by hand the first time and it was a pain in the ass. Being fully automated means with one simple execution and a couple of parameters, we can push an entire repository of web assets off to Amazon S3 and keep them up to date.

Implementation

Here’s the background on my site and why this script does what it does. It’s easy to customize so you should be able to use it for your own needs with little effort but this gives some rationale as to why I’ve made certain decisions.

Be sure to check my previous post to fully understand the limitations of S3. I won’t be re-addressing here why we have two buckets, set headers or compress content separately.

Javascript

On my site, we include Google Analytics on every page. We also include jQuery and Dan Switzer’s qForms on many pages. The public facing part of our site also includes the AddThis widget that lets people share our content via social media sites like Facebook and Twitter.

Depending on the page you hit, you might have to download all four of those things. Or in certain rare cases, maybe just one of them (GA). We made the decision to create a bundle of core Javascript that would include all four of those items in a single file. When stripped and minified with a far futures expiry date (which means they would only ever download it once), we decided that the file size was small enough to send to every user instead of sending it piecemeal. jQuery accounts for the biggest chunk and since we’re moving towards more interactivity, we decided to bite the bullet and bundle the four scripts together.

Javascript is compressed by the impressive YUI-Compressor written by Julien Lecomte.

CSS

Historically, we’ve always used separate files for print and screen CSS. However, there is a technique that will allow you to put both styles into the same spreadsheet that will not only eliminate the extra file but will also reduce the total amount of CSS needed. It boils down to using this technique in your single CSS file:

@media screen {
    /* Rest of the screen stylesheet goes here */
}
@media print {
    /* Rest of the print stylesheet goes here */
}

This first part will eliminate the second file but it doesn’t reduce the overall amount of CSS. For that, I turned to this explanation of putting generic styles outside of the { } which gives you a set of “base” styles that are then overridden by media-specific styles (in my case, print). This is the “cascading” in Cascading Style Sheets. You have to laugh when you work with something for years and still learn something so fundamental. In the end, I have three CSS files that look like:

pap_screen.css:
/* general CSS */

forums.css:
/* general forums css */

pap_print.css:
@media print {
  /* print specific overrides to the general CSS */
}

During deployment, the script concatenates the three files together into a single CSS which handles both screen and print. Then it’s minimized by YUI-Compressor and gzipped for a teensy end product.

Why keep the three separate files? I find it easier to go into a smaller file to find a style than deal with one giant file all the time. If I were starting from scratch, I probably wouldn’t have gone this way but since I already had the three files in my source control, I left them as-is and let Ant put them together.

Updating files with far future Expires

Astute readers will be wondering: if you set the cache headers to expire a year from now, how do you make changes to those files? Won’t the browser use its local copy effectively ignoring the updated file on the server?

Yes.

When I consulted at Yahoo in 2003 helping them with a major search redesign, I was exposed to their internal interface to Akamai’s content distribution network. Their answer to this problem was very simple: rename the file. If the file was foo.css, name it foo2.css and update your HTML to point at it instead. Assuming the actual HTML doesn’t also have a far futures expiry, then the next request will load foo2.css instead and see the updated styles.

This sounds like a pain in the butt but is not that bad. You should already have your templates abstracted in some fashion, either in a MVC system, custom tag or some other templating mechanism that separates out the core aspects of your look and feel. That means when your core JS and CSS files are updated, and thus renamed, there should only be one or two places you need to make changes.

Ask yourself: is a tiny extra bit of work on your part worth a huge speed increase for every one of your users on every request ever made to your website? There is only one correct answer to that question.

Preparing Ant

Let’s get to business. In addition to Ant 1.7, you’ll need to also obtain the following libraries and Ant tasks:

SVNAnt – access Subversion repositories from Ant
YUI-Compressor – library and Ant task for compressing CSS and JS
Ant-Contrib – some extra Ant tasks for looping
s3cmd – A python script for uploading/downloading files to S3, so you’ll need Python too)

It’s beyond the scope of this document on how to get those working; you’ll need some Ant skills but basically it involves downloading the JARs and putting them into your Java lib/ext or ant/lib folder. On CentOS Linux, that would be /usr/java/latest/jre/lib/ext and /usr/share/ant/lib.

Why not jets3t?

There is a pure Java interface for S3, jets3t, but it didn’t work for my purposes here. It may change over time and would be preferable to an external dependency like s3cmd.

Properties Files

I use one properties file per environment that I deploy to and my Ant scripts ask me which environment I want to target when they start. For the script below, they would be named production.properties, staging.properties and development.properties:

# for production cdn
project.name=cdn
project.defaultTarget=deploy
svn.project=cdn
root.buildpath=/tmp
root.deploypath=/my/web/folder
jar.path=/usr/share/ant/lib

# aws props (we have two hosts, one is static, one is compressed, so two buckets)
aws.bucket.uncompressed=cdn-sitename
aws.bucket.compressed=cdnz-sitename
aws.accessId=yourAccessId
aws.secretKey=yourSecretKey

# system settings
exec.python=/usr/bin/python
exec.s3cmd=/usr/bin/s3cmd

# concatenated properties and subversion details
project.build.root=${root.buildpath}/${project.name}/build
project.clean.root=${root.buildpath}/${project.name}/clean
project.compile.root=${root.buildpath}/${project.name}/compile
project.compressed.root=${root.buildpath}/${project.name}/clean-compressed
project.deploy.root=${root.deploypath}/${project.name}

# construct an SVN path like http://server/root/project/ for checkout/update
svn.rooturl=http://your.subversion.com/server/root
svn.projecturl=${svn.rooturl}${svn.project}/trunk/

For running on Windows, I change a few of the key parameters like so:

root.buildpath=c:/temp
root.deploypath=c:/Documents and Settings/brian/My Documents/web
jar.path=c:\\apache-ant-1.7.1\\lib

exec.python=c:\\progra~1\\python\\python.exe
exec.s3cmd=c:\\progra~1\\python\\Scripts\\s3cmd.py

The Script

With all of the preparations done, we can try the actual Ant script. I’m sorry the formatting of this makes you scroll horizontally; I’m going to get a new code plugin soon to eliminate this. You might download the file to follow along instead.

The first and default target is picktarget – this prompts the user for which environment to deploy to and sets some Ant properties for helper libraries and options before jumping off to the target specified in the properties file:

	
	
		

		Deploy target: ${target}

I like to have an init target that cleans up existing directories and prepares the script to run. I used to remove the directory completely and recreate it but it extends the length of time that SVN exports or checkouts take over slow networks so I generally keep the source directory and only rebuild the work directory now:

The hyphen in front of this target name indicates it is private. I only call this as a dependency from other targets using the “depends” syntax. This is pretty straightforward – it uses the Svnant library to checkout my source code from Subversion using the properties file we specified.

I like to use the current svn revision number as my release number and I embed it in my application for reference. I also print it to the screen while deploying.

	

		
		
		
		
		

		
		
			
			
		

		Release version is ${revision} 

	

	

		
		

		
			
			
		

		Release version is ${revision}

Now we start to get to the good stuff. Here I’m creating the directory structure to build my static assets with a directory for concatenating and minimizing Javascript and CSS files. These files wind up in a /global directory during deployment for inclusion in my HTML templates.

One of the challenges of bundling Google Analytics and AddThis javascript code into your app is that you’re no longer getting their updates on every page request. Generally this is OK – you probably don’t need an update from them every day. But from time to time, there are new features and enhancements (especially in GA) that you’ll want to capture and update in your bundle. I’ve automated this process by fetching those files during deployment so I have the latest each time I deploy.

Note: because of the way the combined files are named, you may need to update your templates when you deploy your assets!

Now take all of the Javascript and CSS files and concatenate them into fewer files. Note that ORDER MATTERS! We list the files in an explicit order to satisfy any dependencies that we may have in the system. Once combined, we run them through YUI-compressor to squeeze them down and finally rename them back to their original names.

As we discussed above, when you set a far-futures expires header on a file and you need to change that file, the only realistic strategy is to rename it. This next target does that automatically by using an md5 hash (Ant’s “checksum”) as part of the filename. Why use this instead of say the revision number? Because we only want to update the references to these files in our HTML templates if something actually changes. It’s quite possible you could push your static assets many times and unless you updated your own Javascript or CSS or Google or AddThis updated theirs, you may not actually have any changes. Thus, save yourself the effort of updating your HTML template references by leaving the file name the same.

I will admit that I don’t like using an md5 hash because it’s hard to spot check for changes. I haven’t come up with anything better yet.

The end of this target prints the filenames to the output so you can compare them to the ones in your templates. If you were clever, you would put these filenames into a config file of some sort that your templates used so you didn’t have to actually update the templates each time.

	

		
		
		

		
		

		
		

		
		

		
		

		Most recent globals, compare with previous:

When developing locally for example, I may wish to push to a local directory rather than to S3. On our live servers, we keep a copy of our static assets on the boxes alongside our production code. In case S3 were to have a serious outage, we could update one configuration file and suddenly start using our local assets again instead of S3. Given that we don’t control S3, we feel this is a good backup strategy.

Now we use our Python synchronization utility and push our uncompressed (non-Gzipped) assets to S3. This goes to the first of the two buckets we defined earlier.

Technically the expires header should not be set further than a year in advance according to the RFP but we’re using 12/31/2010 because I’m lazy.

Notice how the S3 library is being instructed to add the HTTP headers like Cache-Control and Expires and mime-type. Those are critical!

We also want to push gzipped assets to S3 as well so this private target finds all text assets and compresses them:

And finally, repeat the push but this time to our compressed bucket. We use two uploads here – one for the uncompressed content like images which won’t be Gzipped and another for the compressed content that includes a couple of additional headers for Vary and Content-Encoding so that browsers and proxies will know what to do with it:

I like to get an email when deployments are run, so we include this:

And finally, the roll up targets. None of the above targets are really designed to be called directly. Rather, the following targets use the “depends” feature of Ant to combine multiple targets into something useful like: predeploy, deploy, redeploy, localpush, and repush. Those should all be semi-guessable in terms of what they accomplish.

You can download the full build.xml.

I hope this Ant file helps you get up and running with S3. If you have ideas or improvements, please leave them in the comments!

Flowplayer plugin for Codex wiki

brian — Fri, 14 Aug 2009 00:35:14 +0000

I’m busy setting up a Codex Wiki as a help system and needed the ability to embed screencast tutorials inline. There is a flash embed plugin but I wanted something more Youtube-like that didn’t download the video unless the user clicks on it in order to save bandwidth and keep the page loading quickly as we plan to have lots of videos.

Cue FlowPlayer and a short plugin I wrote. FlowPlayer is pretty impressive… it’s a SWF and a JS file you drop into your site and it leverages the jQuery built into Codex. If you want to use it in conjunction with Codex, you can use my plugin below. The wiki syntax looks like:

{{{ev url="http://url/to/your/movie.flv"
         height="300"
         width="400"
         alt="My alternate text description"
         splash="http://url/to/a/static/splash/screen.jpg"}}}

That code will give you a player that looks roughly like:

This was my first plugin for a Coldbox application and it was pretty easy to take an existing one and create another. It’s also the first Coldbox application I’ve worked with and so far I’m pretty impressed. I am looking at giving it a test drive for a mini app I have to build later this month for club elections and surveys.

Just drop this into your codex/plugins/wiki directory as ev.cfc. The way I’ve written the code, you can have multiple players per page as they’ll all be tagged with a class “flowplayer”:

< !-----------------------------------------------------------------------
********************************************************************************
Copyright 2009 by Brian Ghidinelli (https://www.ghidinelli.com)
********************************************************************************
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
********************************************************************************
$Build Date: @@build_date@@
$Build ID:	@@build_id@@
********************************************************************************
----------------------------------------------------------------------->


< !------------------------------------------- CONSTRUCTOR ------------------------------------------->	

    
		
		
  		super.Init(arguments.controller);
  		setpluginName("EmbedVideo");
  		setpluginVersion("1.0");
  		setpluginDescription("A video embedding plugin that uses FlowPlayer");
  		setPluginAuthor("Brian Ghidinelli");
  		setPluginAuthorURL("https://www.ghidinelli.com");
  		setPluginURL("https://www.ghidinelli.com");

  		//Return instance
  		return this;
		
	

< !------------------------------------------- PUBLIC ------------------------------------------->	

    < !--- today --->
	
		
		
		
		
		

		
		

		< !--- use a jquery onready block --->
		
		
			#HTMLEditFormat(alt)#Click to start playing" />

Getting the current RequestTimeout

brian — Wed, 22 Jul 2009 21:00:06 +0000

In ColdFusion, each page request has a timeout that is set in the ColdFusion Administrator. This is a global default for all requests. It’s independent of the timeout attribute on tags like CFHTTP and covers the entire request lifecycle. You can update it using the cfsetting tag at any point for a given request:

I had an issue with cfpayment where processing transactions in a loop was timing out. I had even written some fancy code designed to gracefully abort before timing out but it wasn’t working. I had set the timeout to 1800 seconds and I could see from transaction logs that it was ending right around 5 minutes, or 300 seconds, which is a common timeout setting in our payment processing code. I went sniffing… and this is what I found. My controller was indeed setting the timeout to 1800 seconds. Here is a simplified version of my abort-before-it-times-out code:








	< !-- I was calling cfpayment.charge() here -->
	

	
		breaking from loop!

So in my case, I had far more than 15 payments to run in a batch and the timeout was 1800 seconds. But inside of cfpayment, in the base component process() method which handles the CFHTTP code, I had this:

Crap. No matter what I set the timeout to be, as soon as I charged a card, it was reset down to just 300 seconds and so my batch processing would time out. Thanks to a clever but woefully named post by Barney Boisvert, getting the request timeout of the current context is super simple:

I have updated the cfpayment core now to have the emulate the existing behavior, which is give a CFHTTP attempt 300 seconds to process a payment against a gateway, but, if we have a longer timeout already, we won’t modify it. Now the code in base.cfc looks like this:

...

The clever part here is that we’re taking the longer timeout, current request context or configured timeout, and adding 10 seconds to it and then using the specified timeout for the CFHTTP request. In my loop scenario, it will retain the longer 1800 second timeout while using a 300 second timeout for each individual payment attempt. My controller code will also keep an eye on the overall progress and gracefully stop processing if we find less than 10% of the timeout is left. In the more common case of processing one transaction where the request timeout and CFHTTP timeout are the same, the extra 10 seconds in the RequestTimeout will afford enough time to process the results of the timed out CFHTTP (via try/catch, cferror, onError, etc).

This is a strategy I’ve used for a long time in order to be able to catch and process timeouts (send an email, etc). Ben Nadel had a post about graceful timeout recovery in 2007 which covers this in detail and it’s an invaluable tool for potentially long running network requests that MUST have error recovery such as payment processing. If you don’t use this technique, I recommend reading his post.

The good news is, if you’re using cfpayment, you already have it.

BounceDetector 1.1 Released

brian — Fri, 10 Jul 2009 23:37:39 +0000

I updated my BounceDetector project over at RIAForge last night to version 1.1. You can use this simple two-file package to analyze the content of bounced email and determine severity and cause using an extensive production-tested signature database. Paired with CFPOP, this lets you easily fulfill Zawinski’s Law. New in this release:

Changed reFind() to find() for a (substantial) speed increase as well as more precise signature matching. The signatures in the database weren’t intended as regular expressions previously. I began the process of converting the many signatures into fewer RegExps but found that it made it more difficult to determine if a signature was in the database which would make future updates more difficult. The find() method is fast enough to make improving the reFind() method unnecessary.
Removed some duplicate signatures
Added new signatures collected from our production system
Reorganized signatures slightly to put common numeric-based reasons at the top which will increase the likelihood of an early match and exit from the loop.

I renamed the files as well to reduce the likelihood that it would conflict with your existing systems. The goal was to make it easier to use as an svn:external which is how I’m including it in my applications now.