Mailgun and ColdFusion

A while back I was playing around with Ghost, a blogging platform written for NodeJS. Crazy simple to setup, one of the nuggets that I found during the 5 min install was a reference to Mailgun.

Mailgun is advertised as "The Email Service For Developers", allowing you to send 10,000 emails for free every month. It has a nice API, and is very simple to use. A common problem that many ColdFusion developers have, when writing an app, is having access to an SMTP server solely for development practices. You can setup a local server, use some Windows SMTP service, or traffic mail through your personal accounts, but it really is better to have a sandbox that's a bit more separated, for security, sanity, and other reasons. ColdFusion 10+ have a built in SpoolMail utility (based loosely on Ray's project), but sometimes you just need to see the real output in a mail client instead of the browser.

Setting up an account was easy on Mailgun. Right from the homepage was a link to the free sign up page. Once the account was created I was given a Mailgun Subdomain. This is my sandbox to play in, so I clicked on the domain name, for the domain admin page, then clicked on the "Manage SMTP Credentials" link on the "Default SMTP Login" line item. From this page I was able to create a new sender (you can use the default if you wish, but sometimes I'll setup separate addresses for specific tracking purposes).

The final stage is to put the settings in the ColdFusion Administrator. From the mail settings area I entered my new "sender" address as my SMTP server username, the password that I created with the account, set the SMTP server address to "smtp.mailgun.org", and changed the SMTP port to 587. (The default port 25 will NOT work, but 587 with no other settings changes will work fine.)

Now I can send mail with ColdFusion from my dev environment without having to load my own SMTP server or subbing out my personal addresses.

Math, PhantomJS and Command Line Arguments

So, recently I've been playing with PhantomJS. For those who are unfamiliar, PhantomJS is a headless webkit engine, that you can use to perform automated testing, take screenshots, and dozens of other things.

Phantom is still fairly new, and this has been a learning experience. My first trials were using the phantomjs-node module for NodeJS. I soon discovered (with some assist) that this bridge has some performance issues of it's own, and had to move to the command line.

When working with PhantomJS in this fashion, you write a script (in JavaScript), and pass it to PhantomJS along with any necessary arguments. I call this command line from NodeJS directly, but you can do so in Terminal or the cmd shell if you want.

Here was the catch. I had some math in my PhantomJS script. Not even complex math, really, just some basic equations converting milliseconds to seconds and rounding it off:

view plain print about
1var system = require('system'),
2 args = system.args,
3 pageArgs = {
4 elapsedTime: args[6] // this value is in the command line as 13762
5 };
6
7 var totalTime = Math.round((pageArgs.elapsedTime)/1000);
8 console.log("The answer is not " + totalTime);

Now, you and I know the answer is 14, but PhantomJS didn't seem to like that:

The answer is not 0

If I hard code the numeric value of elapsedTime (13762) into that statement then the math parses correctly. It appears that performing math on the values passed in causes the issue. I can change up the equation by adding 250 milliseconds:

view plain print about
1var totalTime = Math.round((pageArgs.elapsedTime+250)/1000);

But PhantomJS still doesn't like it:

The answer is not 413

Crazy, right? What I found was, if I needed to do any math to set some variables for use in the script, then I needed to do those in my node process, and pass the evaluated values to my PhantomJS script as arguments in the command line.

REVISION NOTE: Further testing shows that the command line arguments will all come across as a "string" type, which may be why these equations were miss firing. Remember to explicitly convert your command line arguments to the necessary data type, to avoid this type of issue.