SparkPost is built by and for developers and as such, we value your input. We showed you our true colors during the Mandrill migration and we’ve added lots of new features and enhancements based on your suggestions. We’ve also opened up a communication stream for you to share feedback with us on a regular basis. Now that we’ve gotten to know who you are, we want to pull back the curtain a little and introduce ourselves.
Mark down September 21st on your calendar to hang out with us LIVE and get to know our Dev Relations Team in our new All Things Delivered live stream. In our first live stream find out who we are, what we do, and why we’re passionate about delivering the best email cloud service on the planet to you, our community.
Starting in September, on the third Wednesday of every month, we’ll be coming to you LIVE for 30 minutes to discuss what our team is working on and walk you through our client libraries, the SparkPost CLI, or other technical topics. We’ll also be covering common questions and issues that you, our community members, have brought to our attention; helping you troubleshoot issues and get a better understanding of how to look for information that will help you do your job better and land your messages in the inbox.
We’ll also be taking questions from you in real-time via the #SparkPostLive hashtag on Twitter and via the SparkPostLive channel in our Community Slack.
Here are some dates to add to your calendar for All Things Delivered:
- Sept 21, Dev Relations team: Who, What and Why – Add to Google calendar
- October 19, SparkPost API basics & CLI – Add to Google calendar
- November 16, SparkPost Client Libraries – Add to Google calendar
- December 14, Community Driven Roadmap – Add to Google calendar
How can you participate?
If you’re unable to participate live, you can always watch the playback on our YouTube channel.
Looking forward to seeing you soon!
Making Email for Developers Easier
Back when I was a fresh-faced young web developer (just how much younger, I’ll leave to your imagination, though the fact that I was working with a Perl CGI script on a Netscape web server might give you some idea…), I was given the task of writing a script that would accept an email address from a web form and auto-reply an email with some bit of information (a thank-you note, if I recall correctly).
For obvious reasons, my script needed to parse the submitted data to make sure the user had entered a valid email address. Easy, I thought; the regular expression was going to be really straight-forward. I think I came up with something like “ \w+@[\w\.]+ ” After I had built out enough code to get a working demo, I showed the senior programmer on our team my work. He just shook his head, and promptly schooled me on how sloppy my assumptions were and showed me why my regex was many orders of magnitude insufficient. If you’ve ever tried to grep email addresses, you know how hard it is to write a regular expression that covers all of the bizarre edge cases.
Fast forward to today, and you can understand why I lol-ed reading the title of a blog post written by a developer a few years ago: “I Knew How to Validate an Email Address Until I Read the RFC.” The more things change…
The task of grepping a valid email address neatly captures the exasperation that nearly every developer who works with email has felt at some point. There’s really no getting around it: email can be a pretty strange beast with conventions, dependencies, and quirks unlike anything else, and many of us have a love/hate relationship with making it work. We love email because it’s ubiquitous, open, flexible, and effective; we hate—or perhaps have learned to treat it with a wary respect—because getting an email from point A to inbox B has so many variables outside our control. In short, it’s easy to feel like “I Knew How Email Worked Until I Started to Build an App that Sends Email.”
Fortunately, services like SparkPost let developers offload the operational considerations of building and hosting email infrastructure. We deal with the challenges of sending email at scale, the arcana of sender authentication, and the weeds of email deliverability so you don’t have to.
But even so, if you’re building email into your app or business process, email presents a number of messy details and idiosyncrasies that turn out to be gotchas for many developers. So, to save you a little bit of grief as you dig into the quirks of email, check out “The Developer’s Survival Guide to Email.” It’s an easy read that highlights 10 things builders new to email might not realize about implementing and sending email (and gives some great tips for solving them) – email for developers!
Let me know what you think. What are some of the things that surprised you about email as you began working with it? I’d love to hear about the challenges (and solutions!) you found.
TL;DR: All systems are go. Here’s what you need to know to make it through the final countdown and migrate to an alternative before the Mandrill shutdown.
When Mandrill announced that they were shutting down as a stand-alone service and being rolled into MailChimp’s full-service product, a whole lot of developers took to the net to find a Mandrill alternative… and to tell us what they really needed in a developer-focused email delivery service. (Maybe you were one of them!) We listened—on Twitter, Reddit, Github—and took your feedback to heart.
New SparkPost Features to Help Developers Ahead of the Mandrill Shutdown
We knew we already had the core requirements nailed. SparkPost is just a year old, but we’d already built the industry’s highest-performing, scalable, and reliable email delivery service. As a developer-led company, we knew our APIs were a joy to use. (Really! Joy!) So, we were ready to get to work building some of the specific features and tools you and other developers asked for to make handling the Mandrill shutdown and conversion to SparkPost easier. Here are some of the highlights.
- MST3K Mandrill template converter. This Mandrill template translation tool is a lifesaver. Built by a team of engineers that went to work right away on the issue facing anyone wanting to convert off of Mandrill to SparkPost, this converter intelligently brings templates over from Mandrill to SparkPost. We’ve heard that in some cases this tool has saved around 90% of the time for dev shops to migrate. That’s awesome.
- Subaccounts. Devs spoke up and said you need subaccounts. We already had subaccounts on our roadmap, but we prioritized it to make life easier for Mandrill refugees. Our engineers went to work and released the first wave of subaccount functionality a few weeks ago. This past week, they released more. We’ve heard some innovative requests, and we’ll be rolling out more functionality around subaccounts in the coming weeks. Developer feedback is the gift that keeps on giving and we appreciate it.
- CSS inlining. CSS in email really isn’t much fun, and it turns out devs don’t like to deal with the CSS inlining requirements of email. Go figure. They’d rather a tool do that for them so we built them one.
- Forwarding service. We recently released the sp-forwarding-service for Heroku. It consumes inbound message webhooks and forwards them through SparkPost. It’s so new we haven’t even blogged about it yet! Stay tuned, and we’ll say more about it soon.
- Suppression list import. Developers who’ve been through a migration before know how important it is to bring over your current suppression lists. Our team wrote a command-line tool that makes it easy to import suppression lists from Mandrilll to SparkPost, without resorting to using the manual web UI.
- Test mode. There’s no undo when sending email. That’s why a test mode can give peace of mind while coding. You asked, and so we built it.
- Community Slack. We launched a SparkPost community Slack channel. You showed up. 👋 More devs keep joining. Community members have started helping other community members. We’re in awe of the knowledge and general awesomeness you’ve been sharing in the community channels. Thank you.
And Some Awesome Contributions from the Developer Community
The response from developers has been incredible. We’ve seen you take our platform to another level with your skills and willingness to contribute back to the community. Here’s some of the awesomeness:
- C# library. We hadn’t yet built a SparkPost C# library, but @darrencauthon on Github needed one. So, he built it and contributed it to the community.
- Drupal module. Github user @zaporylie wanted to use a SparkPost Drupal module, so he built one and gave it back it to the community.
I think you can see the pattern of community greatness. These are just a couple examples of many. Many other smart creative devs took on SparkPost for Ruby on Rails (ActionMailer; thanks @dgoerlich!) and SparkPost Python (many devs here… thanks @pegler, @mathiasose, @gnarvaja, @puttu, @svisser, @bartdag to name a few!), extended them, and made them better. There isn’t enough space in this blog post to list everyone that’s made meaningful contributions. Thanks to all these devs!
There’s one more contribution for a quick shout-out:
- Dev Chris Pitt felt there should be some video examples of programming SparkPost, so he created a set of walk-through videos. Thanks Chris, this is amazing. We heard from other users just how helpful your videos are!
With just one week left until the scheduled Mandrill shutdown, I wanted to take a breath and thank our developers and users for joining us on this journey. We’re going to keep trying our hardest to build the best and easiest to use cloud email platform, so that you can focus more on building your apps and services.
Your contributions and feedback have made SparkPost even better than before. It’s why we’re so happy to use the hashtag #WeLoveDevelopers. #AndWeDo.
P.S. Still need to do a last-minute migration to SparkPost before the Mandrill shutdown? We’ve got your back. Check out our Mandrill Migration Survival Guide for the essentials of what you need to make the transition as easy and reliable as possible.