You can listen to the podcast and read the show notes here.
Michael: Welcome back to the show. Today we're gonna be looking at how you can send data giving ColdFusion email a rest and there is a pun intended there with Matthew Clemente. And we're gonna look at why is an e-mail dead already? But it really isn't and how you can use e-mail as an interface for your application. And we’ll look at some CF mail settings you may not been using. But then we're going to look at some transactional mail services that are really exciting that can give you high performance and better deliverability than you may be used to. And speaking of deliverability, you may wanna check out your own e-mails deliverability however you're sending e-mail, and we'll have some tips on that. So welcome Matthew.
Matthew: Thank you, happy to be here.
Michael: And do you wanna go by Matthew or Matt? I noticed your blog has Matt in it, but like you put Matthew in the…
Matthew: The blog is Matt because someone else got Matthew.
Michael: oh!
Matthew: They got there before me.
Michael: So you are Matthew.
Matthew: I'm a Matthew. I’ll go by Matthew, thank you.
Michael: Just wanted to check that. So here's the big question. I'm sure I've read the e-mail died at least ten times in the last ten years.
Matthew: Absolutely, yeah, I’ll like to say that the only thing people have been declaring dead longer than ColdFusion is the e-mail. And from headlines going back to 2002 saying that e-mail is dead. But we know, we're developers we know that that is not… that I mean the statistics show that it's not.
Michael: Why would people say it was dead?
Matthew: You know people say that slack is gonna take its place. And people said My Space and Facebook were gonna take its place, and all sorts of things. But everything finds its own niche. And email being open, being accessible to everyone has survived and thrived. So it's going strong and definitely, definitely not.
Michael: Yeah, I think you have some statistics on that that show the email volume has being growing.
Matthew: Yeah, year over year, different companies have done studies of the numbers of email shown. And every year, they project a certain number and every year going back from 2013 to now, it's exceeded every projection. Growth just keeps going up in terms of volume so.
Michael: And how many of that is ads for Viagra.
Matthew: I think this is real emails.
Michael: Oh, real email volumes, okay.
Matthew: I didn't check the study.
Michael: It didn't look as [crosstalk] [04:43], yes.
Matthew: I'm sure, I'm sure is also through the roof.
Michael: yeah
Matthew: But you know why people spam? Because e-mail works, email gets to people.
Michael: Yeah, it gets there. I mean it'll get delivered. I mean they built the Internet and e-mail so it could reroute itself even if like the service in between. You know running or whatever or if they've been zapped by a nuclear bomb because I think that’s the original scenario.
Matthew: Yes, it's out there and it's running absolutely.
Michael: So what about using e-mail in your ColdFusion applications because you know I'm sure most people use the C.F. mail tag, but maybe they just don't realize all the things they could be doing with it.
Matthew: Yes I mean CF mail makes it incredibly easy to send e-mail and I think everyone's familiar with setting their mail setting. You can set it in CF administrator, you can do your settings in your CF mail tag. One of the things that a lot of people don't know is you can actually set your S.M.T.P. server settings in your application CFC a lot like you set your data source. You can define your S.M.T.P. server username and password, so that you can have a different server per application, and not have to hard code it in every one of your C.F.M.L. tags.
So that they gives you flexibility as well to define a different mail server for different environments. On your development server, you might want one set in and your live server a different one. There's a lot you can do there if you're defining your mail setting there in your application that's CFC which I don't know how many people know you can do that. But it's a nice option.
Michael: That is a good thing. I mean I guess the other workaround is you just stick close settings into variables that get passed around everywhere.
Matthew: Yeah, yeah I mean the there was a question on an old Ray Camden blog post about how to handle different settings, production, or a test server. And I think his answer to it was of some years back, but his answer was using a service or something where if it's production send email it instead of write to a log file, and that's great. One of the things you can do now actually, there's a service called Mailtrap. Mailtrap.io and they have a free tier, but they're a mockup of fake S.M.T.P. server.
Michael: oh!
Matthew: And if you use their settings in your… for your mail server, all the messages that you send you can see them there. They give you a digest, they give you the HTM content, the text content, all the headers, everything is there for you to look at and it doesn't get delivered to your client. So a really nice hack in that regard is that in your apps CFC if it's production, do your live settings. If it's dove set the mail trap settings and you don't have to worry about your emails going and being delivered to your clients. And you can go in there and you can actually see them. You can see I sent this email to this client, and this is the content exactly as it be rendered on production except instead of me seeing it, it will be my very important client’s inbox.
Michael: And that has the… I mean I guess the other thing we used to do is just have a fake email address or a dummy account we'd send the development e-mails to. But this has the advantage that you can send them to the real address make sure you've got that right many C.C.'s and what have you.
Matthew: Yeah, you can see it exactly as you send it. You can see all the headers exactly as they'd be sent it. Even though I mean I don't know how effective they are for everyone. It has a little spam checker in there that looks at the content of your email, and a bunch of features as well.
Michael: That's important for deliverability and we'll talk more about that later in the episode. But what about using… You know what are we using these emails for? Because I think people are actually missing a lot of things they could be doing with e-mail like.
Matthew: Yeah, one of the thing that I like to focus on is transactional emails. I mean we all know marketing emails, and no one likes marketing emails. You look for the unsubscribe button as soon as you can and you slam you know, go through all the doors to try to get off of marketing e-mail lists. But I like talking about transactional emails. The e-mails that we send from our apps to create accounts, to verify emails. There's a whole host of things; resetting passwords, receipts for purchases, updates, comment notifications, reports, digests.
They’re really the bread and butter of your application, they’re very important, and I think often, there’re neglected. We don't think of email as being an interface to our application but in the same way that the H.T.M.L. C.S.S. and the JavaScript are an interface that people use, e-mail is an interface for our application. And given the importance of these transactional e-mail, it's an interface that I think we would do well to focus on a little more. It's always ripe for improvement.
Michael: Yeah, I think that's a good point. And I've actually seen them being used as an interface. Sometimes you they have links in them like was a little… Like are you happy with your purchase? Yes/No; something like that.
Matthew: Yeah, so some companies really do focus on this and there's a nice there's a nice touch when they send something like that and there's an action that you can take in there. G-Mail has in the ability now. It's a meditative use where people can trigger an action directly from their G-mail inbox. My favorite example of emails and interface is if you sign up for a slack team, they send you a magical link that logs you automatically into the application.
And I don't know. When I did it the first time, it felt magical. It was delightful and I thought it was just an excellent use of e-mail. It doesn't need to draw attention to itself. It's just making the application experience that much better. And yes, so there's companies out there that do a really good job of using email as an interface, and focusing on that as well as the rest of their applications.
Michael: So the key point with transactional e-mail. Is it tied to something the user’s doing? It's not sent on a rope basis like a newsletter. They've interacted with your application and now they’re getting some e-mail based on interaction.
Michael: Yeah, it's based on an interaction. It's directed at an individual and because of that transactional email; true transactional emails would have a much lower spam rate and higher deliverability. And that’s the some transactional providers that will only send transactional emails. Some send marketing emails as well. But if you really focus on your transactional emails and separate that from marketing, you can build up a stronger reputation for your domain and for your email, and improve your deliverability.
Michael: And it's not just deliverability, I think almost transactional emails often you want to arrive faster. Sometimes, when you're mass sending emails they can take hours to deliver.
Matthew: Oh absolutely, yeah.
Michael: Transactional email; if there’s a password reset, people get frustrated. [Crosstalk] [10:26].
Matthew: Oh! I was working on my presentation and I was signing up for some icon service. And I eventually just didn't. I never got the verification from my account. I think it came an hour later. By then, I had moved on to another provider. So certainly, the speed of that is absolutely important. You wanna get those emails out right way.
Michael: Yeah, and you want to be deliverable so they don't go in your spam folder.
Matthew: Yeah, so it's not always frustrating. Did you check your spam folder? Shouldn't have to say that.
Michael: So is there anything more about your Dev server and how you should set up your email there?
Matthew: No, I think knowing that you can use your application that C.F.C. is good. Most people by now probably have other things set up in there using a service or something that to handle it differently. But I like letting people know that that option is out there. And when you're sending a C.F. mail, one other thing that I like to point out is that you can assuming that your current S.M.T.P. provider supports it. You can set T.L.S. or S.S.L. to true and much the way that we're moving to H.T.T.P. S. for everything online for privacy and security. You obviously want that with your email as well. So setting T.L.S. to true for your emails is a great step to do that. And obviously, CF mail makes it very easy to do that. So I recommend that for people.
Michael: And that prevents people from hacking into your account.
Matthew: It's like H.T.T.P.S. It encrypts the transactions in between so you know the content of year of your emails can't be snooped. So that it's encrypted from where you're going to your S.M.T.P. server. And hopefully from there, it's encrypted to the mailbox it's being sent to as well.
Michael: Yeah, I'm just wondering about that later stage because just thinking how that email works and emails get passed around between multiple servers. I don't know if it would staying encrypted in the whole journey.
Matthew: Yeah, it depends on the S.M.T.P. providers you're working with. Some have an option to attempt to send via T.L.S. to the inbox. Some have the option to fail at their. I mean sometimes you don't have any option at all.
Michael: yep
Matthew: But when you look into that there's a handful of approaches that different providers will take in terms of trying to keep messages encrypted or not. You do as much as you can.
Michael: Right, and then what about plain text versus H.T.M.L. email?
Matthew: I am of the mind that you wanna send both because not everyone accepts H.T.M.L. emails, and certain spam checks will look to see if you've sent both. And even if they're similar in jumping to the deliverability topic if you don't mind.
Michael: yeah sure
Matthew: There's a wonderful service out there. And we’re mentioning lots of service.
Michael: mail tester
Matthew: Mail tester, yeah. Mailtester.com. We’ll give you an email address that you can send to. And they run the email through a barrage of various spam tests. And then they’ll rate it on a scale from one to ten and tell you how deliverable it is and what you can do to improve it. And it's… I think at the free tier, you get only a certain number of checks a day, and then you can purchase more. But they’ll check it with Spam Assassin, and they’ll check it against black lists, and what… So one of the things that they check to improve your message is whether it has both H.T.M.L. and text count which you can do once again with C.F. mail fairly trivially. But I'm a big promoter of sending both.
Michael: yeah
Matthew: Just you know that you're provided there for how people wanna receive it.
Michael: Right because it's often a lot easier to read than H.T.M.L. email if you have that turned on. But if people don't have it turned on then it's gonna look like a mess so. The other thing on that I've used, you’ve probably use something like is send a score.org. That kind of text.
Matthew: yeah
Michael: But yeah, we’ll to talk about deliverability more in a bit later so. Yeah, so basically, you're saying that you want your emails to be really deliverable and fast. And that may mean you don't wanna use the corporate email server because that has some deliverability issues or isn't super-fast.
Matthew: absolutely
Michael: So then you're looking at a transactional email service that specializes in sending these really fast, and making sure they get to the inbox.
Matthew: Yes, so I've experienced them of late. There's a host of transactional email services out there that specialize in sending these emails. They're all relatively cheap, and there's a lot of functionality that comes with them. I just remembered the first time I used one of these and I was just blown away by how simple it was to get lots more data. And they’re all companies that are obsessive about e-mail, and really focus on the nitty gritty of e-mail so that you don't have to. Because I know e-mail you know, you talk about email and people's eyes glaze over. But they're there worrying about reputation, and how many emails are bouncing, and what IPs are good or bad in improving reputation. So if you use these services, you can leave the nitty gritty.
Michael: right
Matthew: Stuff of the email to the people who really are obsessed with it and focus on improving your application and benefiting from their knowledge and what they do.
Michael: Well and they're going to look after it 24/7 whereas if you use your own e-mail, if something goes wrong, you might not find out for days you know.
Matthew: Yeah absolutely, absolutely. It's nice to have you know you can have… with all of the ones that I've ended up talking about, their status pages where you can make sure that everything is up and running smoothly. There's alerts if there's ever a delay and in emails being delivered. Yeah, it's nice to know that you've got someone watching over that very important part of your application.
Michael: So what's your favorite transactional e-mail service right now?
Matthew: So all of the question I usually get is which is best. Which I think it is kind of a [crosstalk] [17:39]
Michael: loaded question
Matthew: I think well if you do searches online comparing them, there's you know advertise. They all advertise that they're the best. You know we’re better than the rest. But I think that the best and my favorite would always depend on the use case. They all kind of… I haven't looked at every transaction provider because there really are a lot of players in the space.
Michael: yeah
Matthew: But the biggest ones and the ones that I've looked into the most are AWS with their S.C.S. service. SendGrid, PostMark, SparkPost, and Melaka. And honestly, they're all excellent services. But they have different areas where one's better than the other, and where one has more functionality than the other. So I mean I can run through the little bit I see their use cases kind of shining.
Michael: sure
Matthew: If you're worried about cost, AWS with S.E.S is by far the cheapest. It's definitely orders of magnitude cheaper than the other because Amazon just you know has bargain basement prices. I don't generally recommend using S.C.S. just because if you're gonna be using one of these transactional services, you probably wanna benefit from some of the more advanced features and hands on support. And you're not gonna get that when you're paying this bargain basement prices from Amazon. All of the other providers have a lot more features, a lot more active support. But if cost is the most important, you do S.E.S and it's there.
Michael: Right and you have to configure it yourself, right?
Matthew: It's a lot more hands on than the others. You're definitely plugging in all the wires yourself and making sure that stuff's not crossed. So it's really just a step above running your own server. If you're doing a lot of marketing emails as well as transactional, SendGrid has a whole host of marketing features built into the product and a lot of support. If you're using a…
One of the things that I've recommended to companies is if they're using something like Get response, or mail champ, or campaign monitor with the whole score of marketing e-mail companies, they might be able to combine their marketing and transactional with SendGrid because SendGrid has campaigns and templates, and a lot of the features that those marketing companies advertise as well as this transactional side. So you can come it cut out the cost of the marketing and handle all of your email under one roof. If you're doing marketing and want to consolidate that, SendGrid is in my opinion the way to go. The complete flip side is PostMark.
They are very strictly only transactional emails. And they make you check boxes six times any time you set anything up to say that you only send transactional. But they really in my experience, they have the highest deliverability of the transactional providers I've worked with. When you run e-mails from them through mail tester, their scores are generally off the chart. There's a lot of great features and great transactional stuff in there. They tend to cost more. There's a volume discount, but they tend to cost more than the others. So that no marketing emails and they cost more. But in terms of transactional, deliverability, speed, and a lot of other features, they're excellent.
Michael: When you say cost more, when you know you're talking about several arms and legs here or what?
Matthew: Well it depends. If you're using PostMark, it depends. They give you a prepay option which is cheaper. And it depends how many emails you're sending.
Michael: Are we talking like 100 dollars or 10,000 dollars?
Matthew: So if we wanna run, if you're sending like 50,000 e-mails a month. If you're gonna do that on Amazon; the S.E.'s, it's like five dollars. If you're doing it on PostMark and you prepay, it's 50. So ten times more. Now as volume increases, you get e-mails cheaper. But everyone else falls within that range. SparkPost would be the next cheapest of cost at that tier because it varies by tier.
But at 50,000 for SparkPost, it would be nine dollars; nine dollars a month. And SendGrid and [inaudible] [22:56] that would both be 20 dollars a month. So there's a range there, and it varies depending on what tier of e-mails you're sending. If you're… I don't know how big people's e-mails are. If you're sending in 500,000 a month. The price that postmark is actually much more affordable if you're sending volume that high. And some of the other ones go up a bit higher.
Michael: And then you mentioned SparkPost and Mailgun.
Matthew: yes
Michael: What's this, what are they good for?
Matthew: I see SparkPost and Mailgun as very developer friendly. The primary reason for that is that they both have a free tier. So if you're just starting out a product and you wanna send these emails for free, you can do that on both of those services. At Mailgun and I think it's up to 10,000 e-mails a month for free, and at SparkPost, it's up to 15,000 e-mails a month for free. Which is really it's the other services have a free like initial offering. But once you're past that, you can't keep using the service. With SparkPost, you can spend 15,000 emails a month for forever. Mailgun 10,000 e-mails a month.
Your first 10,000 are free, and then it kind of grows with you. So if you're starting out with a product or you've got even if you want something affordable and you have something send in fewer than 10,000 emails, then that's a great option. In terms of differentiating the two and their developer friendliness, SparkPost does tend towards the marketing side in terms of what they offer, email templates, and different reports that look at engagement, that are geared towards marketing.
Whereas Mailgun has a lot more than nitty gritty developer friendly stuff. There are logging in. Their logging is better than spark post in my opinion. They've got some really robust in down email handling. You can set up a route that says, “If I have an email sent to this address and it's sent from this address, I want to store it on my server. I wanna fire a web hook, and then I want the email forwarded to someone else.” You can do some programming like that which gives you the ability to automate some stuff in interesting ways. So they've got that nitty gritty side of the developer friendly I think down very well.
Michael: And then which mail services shouldn't you be using, and then why?
Matthew: I don't like to bash email services. I think that if well… It comes out of use cases. If you're sending marketing emails, you shouldn't be using the PostMark because they'll probably kick you off.
Michael: right
Matthew: Once you get a bunch of spam reports
Michael: What I was thinking of is things like Mail Chimp. You shouldn't be using them for transactional e-mail.
Matthew: Oh absolutely! And there's a host of actually Mail Chimp has (and I wasn't involved in this because it was a little bit before I was using transactional services). Mail chimp's has a transactional service that goes along with them. It was Mandrill and at one point not that long ago, they bundled Mandrill their transactional service with their marketing e-mail. And a bunch of people who had a really great deal set up sending only transactional emails.
So when they found that they had to pay a bunch more from the base Mail Chimp price to keep using it. And a lot of developers got really upset with how they handled that. It didn't impact me, but I know that if you're out there looking, you'll see a bunch of angry posts from developers about how Mail Chimp and Mandrill handle their developer community. But that’s it. You shouldn't be using a mail service that doesn't fit your needs. So you should know what your needs are.
Michael: Right yeah, so let's talk deliverability because I think people often don't pay attention to that. And they’re sending out these thousands of emails, but they aren't all getting there.
Matthew: Yeah, there's a lot of things you can do to improve your deliverability. Regardless of how you're sending, you wanna make sure that you've got your S.P.F. records set up right. It’s a text record, text D.N.A.'s record that says what servers are allowed to send emails on your behalf. A lot of people are familiar with S.P.F. Along the same lines, there's a D.K.I.M. which basically is an encryption thing that makes sure that your message hasn't been altered in transit. So it's a digital sign based on the contents of an e-mail. When an e-mail service provider gets the message, you can say, “Okay, this e-mail wasn't changed. Someone didn't intercept it because it wasn't sent securely. Change the content of the email, and then forward it along.”
You definitely wanna set up S.P.F. and D.K.I.M. records on your domain with the transactional providers. I discussed they make it very easy too. In some cases, they don't require you to, but you should. And anything that’s checking your deliverability; any of those services, will tell you if you’ve set these up or not. Those are the basic things that you should set up. I think more important at this point is DMARC. It's a relatively newer security set up for e-mail. It's kind of built on top of S.P.F. and D.K.I.M. because those two are not tied to the visible from domain. They're still spoofing that possible even if you have your S.P.F. and your D.K.I.M set up.
If you set up a DMARC record, it gives you the ability to tell e-mail service providers what to do if an e-mail comes in and it doesn't match your S.P.F. record, or if it fails the D.K.I.M. check. You can say to G-mail. If an e-mail comes in and it says that it's from Matt Clemente.com, but I don't have an S.P.F. record saying that that domain can send either bounce it, put it in spam, or don't do anything. But make a note of that. And DMARC also has reporting and so they'll report back. If you set up a DMARC record. You can get reports back on the emails that email service providers see being sent from your domain. The problem with the reports is that there are these nasty X.M.L. documents that aren’t friendly.
But again, there's a service out there. If you go to DMARC.PostMark app.com, they help you set up a DMARC record and they’ll send you… they’ll parse the reports from the email service providers, consolidate them, and give them to you in a friendly format. So you can see that your records are set up right, who's sending emails on behalf of you. And it really gives you a good look at what's going on for your domain. So I'd look into DMARC. If you don't have a DMARC record set up, you should have one because you can tell people not to send on behalf of your domain, and that gives you a lot of security.
One of the examples that I do in the presentation is that I'll take a domain that people know that doesn't have a DMARC record set up and use a transactional service and I'll send, I’ll basically spoof that it's from the domain. And depending on what email client you're using, it can look like it's from the provider. Whereas if a DMARC record is set up, I can send it to junk and it never gets to the inbox. So DMARC, super important. That's definitely I think a very important tip if you're looking at deliverability and setting up your emails correctly.
Michael: Right because the you know these days most ISPs are running some kind of spam catching software that’s looking for these thing along with the content of the mail and few other things they look for.
Matthew: Yes, they definitely. If you look, you can look at the headers that have how their different email service providers handle your emails and they check. A lot of them check for a DMARC record putting that in place should help with your deliverability as well as giving you a lot more control and visibility into what's going on for the emails that your domain is sending.
Michael: And they definitely look for the S.P.S, and DKM records.
Matthew: Yeah, those are ubiquitous. They're across the board.
Michael: But you’ll be amazed how many people miss to configure these things or don't even set them up.
Matthew: absolutely
Michael: Or set up and they're not you know.
Matthew: Absolutely yeah, another reason they’re using some of the deliverability testing services can give you a view into what's going on.
Michael: You mentioned mailtester.com and…
Matthew: Yep, [crosstalk] [32:49] tester in case people are yeah.
Michael: Yeah, I'll put in the show notes.
Matthew: absolutely
Michael: And senderscore.org is another one I've used. I think Google has one I'm forgetting where it is. But I've used it in the past the check literally been. So definitely worth doing that and it's great to have a service that just checks like every month, or every week, or whatever what's going on. When you use one of these transactional services, do you have to change the domain you're sending from? You have to have a separate to main that you use and it can come from your domain or?
Matthew: So they all… they differ slightly and they have you set it up. From all of them, you can set it up to send from your root domain. So I can send from Matt Clemente.com. Some of them have you configure their access by adding records to a subdomain. So for Mailgun, they recommend setting up a subdomain. You verify an S.P.F. and a DK. Record to show that you control it and then you still send from the root domain, but you're configuring them at the sub domain level. Actually for all of them except for PostMark they have you set up some domain to do the initial config. But you can send from your root domain.
I should say too with the transactional services that I've talked about, their big focus is their REST A.P.I. which there are C.F.M.L wrappers for them. But you can send from S.M.T.P. using them. And they all have S.M.T.P. endpoints that you can integrate with your app really easily. It's almost a… if you make sure you do the configure I wouldn’t recommend just dropping it in. But it's about as close to dropping in various M.T.P.s as possible where you could start using the service very quickly without having to reconfigure your app dramatically in order to use them.
Michael: So which would you recommend using? The REST A.P.I. or just going straight?
Matthew: I'd recommend if you’ve got your application set up and it's running on S.M.T.P., you should use S.M.T.P. It gives you an easy path to migration, you get access to a lot more reporting that you didn't have before. Some link tracking, click tracking analytics that you didn't have, and then migrate to the rest A.P.I. as needed. There's generally more functionality that you can do with the rest A.P.I. REST generally is faster than S.M.T.P. because it's just a single H.T.T.P. call and S.M.T.P. tends to be chatty. But more… The rest A.P.I. I've found it's easier to use and you can get access to some more advanced features. But certainly, in terms of just getting started with them, S.M.T.P would be the way to go.
Michael: And then you mentioned Web hooks earlier. Tell us how that would work in these services.
Matthew: So yes, so one of the neat features that these transactional email providers provide is in addition to sending email, they give you more functionality. So you can trigger a web hook to get called when an email gets opened. You can trigger a call when emails bounce when they get delivered. You can set up inbound email parsing where if an email comes in, you call out to a web hook with information about the email. Basically, it makes email much more programmable. So you can take actions based on what's happening either with your emails or in your emails. They'll handle this in slightly different ways.
But it's nice to know you know for example, if you want to take action on an e-mail bounce. You know if an email to someone bounces maybe you wanna temporarily disable their account, maybe you wanna do something else to it because that's obviously a problem if one of your users emails is bouncing. Maybe you want to remove them from your marketing emails if a transactional email to them bounced. If someone's clicked on a link depending on what it is, you might want to do something else with their account. If it's a verification thing you’ll know that they verified, you can do something else. You can check if an e-mail was opened, so you know that it was received and trigger actions based on that.
What’s nice too with these type of calls out is that you can easily interact with other services that use A.P.I.s. So Xavier is a nice… it's like an if this then that type service that integrates with the A.P.I.s. But you can say… For example, we had a situation at work where someone wanted clients to be able to fill out a form that sent him P.D.F.s that he stuck into trello. All this different stuff which we could've built, but it would have been a lot of work. I mean it would take him some time to build for him.
But we were able to set it up so that there was a free online form service that then used one of these transactional e-mail services. So it posted the form to the transactional service which had Xavier, stuck it into trello, and I didn't have to program anything because these services all use their A.P.I.s to interact with each other. And I could keep working on a main app, and he got the functionality that he needed. So A.P.I. is open up the ability to interact with other A.P.I.s and that gives you functionality that you might not have had before.
Michael: So that gives you a lot more power in how you interact with your users and email.
Matthew: absolutely
Michael: Anything else on ColdFusion transactional e-mail you wanna tell us about or?
Matthew: I just say that it's… there's C.F.M.L. wrappers for these REST services and in terms of the value of ColdFusion, it makes it very easy to write the wrappers and to interact with these is A.P.I.s For example, SPARC post didn't have a ColdFusion wrapper. I had worked on the SendGrid one. So if you look at the commits it get I put together a basic spark post one to send emails. And in 20 minutes, I sent the first email and in an hour, it was because basically done. So ColdFusion definitely makes it possible to interact with them even if they don't… it's not one of the three or four built in A.P.I. wrappers they provide. There's ColdFusion ones either out there or that can get put together to interact with them. Which is just great I think.
Michael: That is cool. So, what's the future of ColdFusion and email?
Matthew: I think in CF mail, we've got a great tag for sending S.M.T.P. emails. I don't think it's necessarily missing anything. But there's other services out there that mean that you don't need to use S.M.T.P., but you can still use ColdFusion I would never say abandon C.F. mail. I wouldn't say abandon S.M.T.P. But ColdFusion, it's nice that it gives us the ability to use these other services to send email. It doesn't lock us into just send it via S.M.T.P. So I'd say ColdFusion’s future with emails is bright as email’s future. It's looking good.
Michael: All right, so let's just change gears good and I’ll ask you some questions I'm asking everyone I'm interviewing which is, why are you proud to use ColdFusion?
Matthew: I'm proud to use ColdFusion because it helps me make exciting products and exciting tools, and it makes my life easier. I've really enjoyed using it to write these A.P.I. wrappers and work on various A.P.I. wrappers. ColdFusion, I'm proud to use it also because of the community. I've definitely found that the people who are active in the community are willing to help someone out when they don't understand things, and are generally willing to spend time from their day to help you solve a problem. I've gotten a lot of help on the slack channel. So I'm proud to use it because I enjoy using it to make great things and there's a community that is willing to help, and I think that’s wonderful.
Michael: That is great and we’ll put the link for the ColdFusion slack channel into the show notes for anyone who hasn't discovered that yet.
Matthew: Yeah if you haven't joined it, join it, it's wonderful.
Michael: So we talked a bit earlier about how both e-mail and ColdFusion have been lambasted for dying, but they’re alive. In fact, I don't know if you can see this. I’ve got a ColdFusion alive t-shirt.
Matthew: Oh, there you go, wonderful!
Michael: For those watching on video on our YouTube channel. So what would it take to make ColdFusion need more alive this year?
Matthew: I think more people interacting with the community that's there. It's certainly a community that's passionate, and willing to help. And if you're out there and you haven't gotten involved in the Slack Channel or listening. If you're listening to this podcast, you’ve probably done that. But even…
Michael: You never know. You'd be surprised. Not everyone has heard of that.
Matthew: I think listening to this podcast, engaging in the community. The Slack Channel is a great forum for that. You can do it on Twitter as well. And then even on GitHub or something looking at the repositories that are out there. If there's a product out there or not a product. Something on code on GitHub that uses ColdFusion and you're looking to use it. If it doesn't work, create an issue there and try to help improve it or take it yourself. If you've improved it then create a polar quest and put it back up there. Or if you wanna get involved in the community, I think one of the things that I've been trying to do on my blog is if I run into a problem and I solve the problem I try to write about it.
And it's not just for the community it's for me because I know that in six months, I'll forget that I solve the problem and I'll be able to come back to the boat, and it helps me. So it's for myself. But it's also there contributing because if you've run into a problem, there's someone else who has run into it. And if you've solved it, maybe you'll solve it for them and that makes their life easier. So to make it more alive, people just need to dive into the community at large I think and try to pitch in where they’re able. Obviously, not everyone has all the time, but it's…
Michael: There's always someone else who's less skilled than you are in some area of ColdFusion so.
Matthew: absolutely
Michael: You always help someone out. And I think it's a great idea to blog about problems you've solved using ColdFusion. I also encourage people to blog about successes they've had. I'm just also gonna mention ForgeBox which is another repository of ColdFusion.
Matthew: yeah
Michael: Code you can use and contribute to. And of course, you've spoken… you’re speaking at C.F. summit and I think you spoke at N.C. Defcon.
Matthew: yeah
Michael: Did you speak at any other events this year or?
Matthew: No, I attended C.F. objective and spoke in N.C. Defcon. I’ll be at C.F. Summit. Those are my three for the year.
Michael: That’s excellent, so go to ColdFusion conferences will be the [crosstalk] [46:04].
Matthew: Absolute, absolutely yeah.
Michael: Yeah and that brings me to my final question here which is, what are you looking forward to a C.F. summit this week?
Matthew: You know I've been really focused on working on my presentation. So I've gone over the schedule. But I think again, I just keep coming back to the same thing; the community. I'm looking forward to talking to people that I've only chatted with on Slack, and interacting with them in person. And being there with the community alive actually alive face to face; that's the biggest thing that I'm looking for to.
Michael: Great! So just for folks who don't know, Matthew is one of the founding partners at season four where they solve legal problem industry stuff with ColdFusion. And he's been doing ColdFusion for a long time now. Must be at least ten years I think, right?
Matthew: Yeah, it's ten maybe 11. I started on MX 7. So, it’s a while back.
Michael: Yeah, that’s a while back. At least ten years I think. And I saw a sneak peek of your slides. It looks like you have a child who's also into ColdFusion.
Matthew: Yeah, I’ve got my one year old wearing the ColdFusion t-shirt. So, certainly not dead. It's got a future. He's one year old.
Michael: So if folks want to find you online, what are the best ways to do that?
Matthew: You can find me on Twitter @MJCLEMENTE84; @MJClemente84. I’m on GitHub, MJClemente and I blog when I have the time at blog.mattclemente.com. So come over there, give me a comment. Happy to hear anything that anyone has to say.
Michael: Great! And also CF slack channel of course.
Matthew: Absolutely, I'm on that too. I think it's MJClemente there. I don’t know.
Michael: Yeah and we’ll put all those into the show notes so you can find them easy. Well I really appreciate you staying up late in New Jersey to do this interview, Matthew. And good luck with your talk at C.F. summit.
Matthew: Thank you so much. I appreciate it. It’s been a good talk.