2016 hackathon review

2016 Hackathon Review

This year we challenged you to “Build Something Awesome” with SparkPost. To motivate you further, we sponsored 5 different Hackathons across the USA with cash and prizes. We also sent along our own engineers in order to mentor those who accepted our challenge. As a result, the response was incredible and we’d like to recognize the winning teams.

Developer Week

We started the year in February at the Developer Week Hackathon in San Francisco. We selected three teams that demonstrated the best use of our Inbound Email, Data & Analytics, and the SparkPost Heroku Add-on.

Best Use of Data & Analytics

Kaushik Ashodiya and his son created SparkPost ONTAP, combining our data with Net Cloud ONTAP to store webhook and campaign data. It allowed users to view or edit historical campaigns, as well as replicate the storage for disaster recovery and availability purposes.

Best Use of SparkPost Heroku Add-on

The team comprised of George Portillo, Stephen Fuller, Victor Sanchez, and Sal Casillas created Grab & Go, an application that leveraged the SparkPost Heroku Add-on to help alleviate the long lines found at the local food trucks. Their solution uses our transactional email to alert customers when their food is ready for pickup after placing an online order.

Best Use of Inbound Email

Marlon Frausto, Anna Wu, Ravender Virk, and Jigesh Parekh set out to tackle San Francisco’s affordable housing dilemma and created DwellWell. They used our Inbound Email to set up a double blind communication channel, allowing people to request information about a particular housing option with some anonymity. The DwellWell team has since continued their partnership with SparkPost to create PublicBNB.

BrickHack

In early March, we headed to Rochester Institute of Technology in New York for BrickHack. After 24 hours of hacking, we selected UBinE by Stephen James as the Best Use of the SparkPost API. This application uses transactional email to assist in planning, tracking, and notifying students of campus events.

Bitcamp

In April, we headed to Bitcamp at the University of Maryland. Because of our close proximity, we got to send multiple engineers of our own to mentor at this 36 hour hackathon. Henry Saniuk, Sneha Vaswani, and Stuart Olivera won our “Build Something Awesome using SparkPost” challenge with their PiggyPennies application. This application made use of our inbound and transactional email and the CapitalOne API to while helping friends save money together.

SDHacks

After a long summer break, we headed to the University of California San Diego’s SDHacks, a 36 hour hackathon. At this event, Kevin Burns and Jack Zeiders had some fun with SparkPost and created an email based gaming service called QuibbleMail. Using only your email, you can challenge a friend to a game of Chess or Tic-Tac-Toe. Their use of SparkPost inbound and transactional email allows you to play without leaving your email client.

MLH Prime Southwest Regional

Finally, we wrapped up 2016 in Austin, where Major League Hacking pulled together the region’s best hackers for 24 hours. Bailey Breaux, Ali de Jong, Yuriy Minin, and Patrick Edelen blew us away with Mochi, their Jibo robot integration for patient care. The team used SparkPost’s inbound and transactional email to empower Mochi to contact a patient’s family via email and read aloud any replies.

At each event, the response to our challenges was amazing. So many of you Built Something Awesome and we thank you. As a result, we’ll be back out there in 2017 and we’ll be sure to keep you updated. Our first stop will be a return to Rochester in February for BrickHack 3. Because we take your feedback into account, we’d love to hear what events you’d like us to attend. You can chat with us on our community slack or send us a tweet @SparkPostDev.

— Aydrian

So, what’d you think of our 2016 hackathon review? What were your favorite hackathons from 2016? Any hackathons on the agenda for 2017 yet? Leave us a comment below.

Email Templates

Why Shifting from Internal Template Generators to Newer Platforms Makes Sense

Everyone has an opinion on how to build the best ’email templates’ that capture a customer’s attention and leads them to a call-to-action. Some leverage great graphics. Others use captions like, “The 10 Best Mistakes That Cost You Millions of Dollars That You Will Do Again!”

What’s often neglected is ‘how’ to build these email templates in a flexible manner that supports the dynamic needs that drive today’s complex business. At SparkPost, we have found that most companies moving from either an on-premises MTA or a self-service cloud ESP were forced to build their own template generators. Some are fairly sophisticated and flexible with a UI. Most, however, are complex pieces of code that build the email through a series of conditionals and saved text.

Over time, these applications have become fragile systems so changes or upgrades are rare, if any. Even simple changes to text within an invoice email can take weeks given the backlog of work development already has. Plus, they need to test it to make sure they’re not introducing further bugs.

With this in mind, I’m writing this blog, and eventually a series of blogs, to help our SparkPost customers see a vision of how they can move from these older systems and leverage the SparkPost templating system such as:

  1. Why making the shift from internal email generation systems to newer platforms makes sense
  2. The simple stuff, moving from SMTP and fully built emails compiled by development
  3. White labeling email templates; Using substitutions to modify look and feel of the HTML output for branding and white labeling
  4. Shared or Global data versus Recipient data
  5. Arrays and how to leverage them
  6. Dynamic output with multiple rows and columns of data
  7. Multi-language support

Many customers write their own templating system out of necessity. And since most are code-rich and depend on development to make the simplest of changes, Marketing gets hamstrung in their ability to keep up with the demands of a rapidly changing world. Because of this demand for change, when possible, it’s better to separate Marketing Design from Development; this is the key factor for moving to templating for many customers. This doesn’t mean that development won’t help build or customize some of the email templates. It just means that much of the work they were doing is minimized. In a perfect world, development worries about obtaining the right data that goes into the message. And marketing worries about the aesthetics and wording of the message.
In the long run, the speed of change that takes place by separating the creative from development is well worth the change.

Now that development doesn’t need to worry about the creative, they can simply focus on three things:

  1. What data to send each customer,
  2. What events trigger sending the content, and of course,
  3. Any segmentation to target the right users during larger blasts such as newsletters.

Another benefit of separating the creative from development is that pulling the data for each user becomes simpler. The need for conditional after conditional to get the proper data for a given template can be simplified to gather all the data for a user, then letting the template decide which data to use. If the template doesn’t use the data, we only lose the cost of transmitting it from the back end server to the SparkPost platform. However, don’t take this approach to the extreme by sending obnoxious amounts of unused data. Typically, there’s a bulk of personalized information that one can gather and send as a standard bit of personalization data for a template to use. Now, Marketing and Development can synchronize on what data will be available. Then, Marketing can ensure it’s used properly and presents itself in a manner fitting to their banding and messaging.

Now that we have a business case of why to shift from internally built email generation systems to newer platforms that separate out development from the creative, we’re ready for our next blog post. In the next one, I’ll discuss gathering the data necessary for substitution and moving away from fully built out emails sent via SMTP.

Happy Sending,

Jeff Goldstein
Sr. Messaging Engineer, SparkPost
Some Sample Email Templates

we love developers

 

Howdy there! You and I have talked before about how we build Slack bots at SparkPost, but I didn’t say much about how we use them. We use bots at SparkPost to do all sorts of things. We’ve learned a lot and I thought now would be a good time to share some of that with you. I love bots, you love bots, so let’s turn the lights down, light a few candles and have a nice glass of your favorite beverage over some bot talk.

How we use slack bots to stay productive people connected via slack

How We’re Using Slack Bots to Maximize Productivity

Like I said, we use Slack bots for a lot of things. We run our standups with bots, we use them to get links to our docs, to post sample data from our endpoints, and to encourage each other. We do internal reporting and monitoring from bots. We track the status of our deploys along with any new PRs and issues on our Github repos all from Slack.

Why do we use bots for all these things? I mean, there are other tools that do almost each one of the things we use bots for. Well, that’s the thing: there’s at least one tool for each of those things. Our Slack bots consolidate everything into one place and one interface.

There are some advantages to using Slack as that central platform for us at SparkPost. First, since we’re a distributed team, Slack has become lingua franca – it’s our primary communication tool – so everyone is comfortable with it. Slack access doesn’t require any special VPN connections (though you should set up two-factor auth for safety). It’s accessible on mobile devices so we can make API calls from just about anywhere. We make our Slack bots easy to use for non-technical people so they don’t have to use developer tools like cURL or Postman.

Basically, since we’re already in Slack on a regular basis, it’s easier and faster to simply perform as many of our everyday tasks from there as possible. Not only does it mean fewer steps to complete something, but we also don’t have to leave the interface where we’re already spending a lot of time. Just repeat this over and over with me:

NEVER LEAVE SLACK. NEVER LEAVE SLACK. NEVERLEAVESLACK. NEVERLEAVESLACK. It’s probably fine.

Botify All the Things!

So how do you choose what to add to your bot? Be on the lookout for things that are inconvenient or painful. Start with the things you do a lot. For example, in our community Slack team we found we spent a lot of time tracking down links to our docs: we’d open a browser, go to the docs page, search for the right resource, copy the link, go back to Slack… It was just awkward. And in that time the conversation would often have moved on. Now we have a single command that will give us a link to the resource our users need when they need it.

Do you have something that only you can do because you’re the only one technical enough? Bam! Slack bot! Or do you want to empower your team to do things on their own? Botify it! Want to let new users know what’s up when they join your Slack team? Bot time! You get the picture. It’s open-ended, the only limits are your creativity and a few pesky natural laws.

How to Succeed at Bots Without Really Trying

Ok, you have this awesome idea for this bot that is going to save you time and frustration and probably the world. You set up a repo and a sweet continuous deployment pipeline for easy deployments. You’ve got 100% test coverage, the build is green. But nobody is using it. Nobody? Seriously? Yep, nobody.

Remember, bots are an interface, just like a web page. And just like any web site they can be hard to use or unintuitive or just plain off-putting. Bots have the extra challenge of being a pure text interface to your code and code is rigid and brittle. But human language is fluid and nuanced and weird. So when you build your bot be creative, funny, and offbeat. Find that unique voice inside of you and channel it into your bot. That helps offset your bot’s rigidity (and even make it endearing!).

Making your bot enjoyable goes a long way to getting users to engage with them. We’ve also found a lot of success by including help text for every command. The skellington library we use for our bots makes help text a first-class citizen and makes it easy to add help messages. The easier and more fun you make the bot to use, the more people will use it!

If you use Slack or some other chat program, bots are a great way to empower your team and make rote tasks easier. Make your bots useful, interesting, and entertaining (in that order) and before you know it your bots will take over the world! Ok, not the world but at least the hearts of your users.

– Cole Furfaro-Strode

We’d love to hear how you’re using bots! Either post a comment below, or come find us in our Community Slack channel.

we love developers

SMTP Relay Graphic Cloud Monitor

 

Note: If you’re using SMTP to route all of your personal mail through SparkPost, awesome! However, be sure to use an email address with a different sending domain (not one associated with your SparkPost account) for your account login. That way, if you ever run into any issues, you’re still able to contact us for help.

You know you need to send email, but you don’t want to spend a lot of time or effort on it — you just want something that works out of the box. It’s not too much to ask! Many frameworks, languages, and tools come with SMTP support, but the last step is the most important – an SMTP server. SparkPost fills that need with SMTP support and a simple setup process.

Today, I’ll be demonstrating how to set up an SMTP relay, so you can use your own email client to send emails from your personal domain. I’ll be using Gmail as my email client, and shopwithkindness.org as my sending domain.

Let’s get started!

How to Setup SparkPost as your SMTP Relay

There are a few things you’ll need before setting up an SMTP relay.

  1. A verified sending domain.
  2. An API key with the “Send via SMTP” permission enabled.
  3. An e-mail client or service which allows you to enable SparkPost as your SMTP relay.

For this walkthrough, I’ll be using Gmail. To begin, navigate to the settings.

navigate to the settings button smtp relay

From there, click on the “Accounts” tab.

click on the accounts tab smtp relay how to

Next, click on “Add another email address you own”.

add another email address you own smtp relay how to

In the pop-up menu, enter the (verified) email address and press next. I’d like to be able to send with “vincent@shopwithkindness.org”, so that’s what I type in.

enter the email address you'd like to use smtp relay how to

Then, enter “smtp.sparkpostmail.com” as the SMTP Server,“SMTP_Injection” as the username, and 587 as the port. Your password should be your API key with “Send via SMTP” enabled. This information can be found under Account -> SMTP Relay in your SparkPost dashboard.

enter your username and port smtp relay how to

 

Let’s get started!

Lastly, you’ll need to login to your inbox to confirm. After that, we’re done! Time to send some Shop With Kindness emails.

Other Resources

If it turns out that SMTP isn’t the right email solution for you, consider taking advantage of the SparkPost API. The API has many pros (and cons). Take a look at Dave’s blog for more information regarding the differences between SMTP and API.

Lastly, if you’re having problems setting up an SMTP relay, join our Community Slack channel, tweet us at @SparkPost, or shoot us an email!

-Vincent

Dev Survival Guide Blog Footer

Community Spotlight Q&A SparkPost Tutorials

One of our greatest joys here at SparkPost is creating tools and watching our community members run with them. From improving on what we’ve built, to creating SparkPost tutorials for other community members, to writing entire client libraries, it’s clear that we’ve got a talented group of people using our product. As our social media manager, it’s so incredible to see these tools and libraries evolve and ignite some great conversations online.

We’re continuing our community spotlight series today by sitting down with Chris Pitt, a community member that we first met at Fluent, who’s contributed to our community in a number of different ways. Aside from his What is SparkPost blog, he’s also featured SparkPost tutorials in a daily coding series on his YouTube channel – you can view “Sending Email with SparkPost” parts one, two and three there. Chris is an overall delight and a very talented developer. Enjoy!

How long have you been a developer, and what got you started in the tech world?

When I was younger I wanted to be an electrical engineer. My parents got a computer, and I started spending more and more time on it, mostly playing rogue-like games.

Later, they bought me a computer. By the time I finished school, I really wanted to do something with computer hardware. A family friend had a business selling, amongst other things, computer networking hardware. He had a website (which was a big thing at the time), so he convinced the agency managing it to let me “hang around” and watch what they were doing. I guess I just never left…

What do you like about being a developer?

I love learning new things. Programming gives me an out for that, because there are more new things happening all the time than there is time to learn all the new things.

What’s a myth about software development you wish you could dispel?

That it is too complex for some to learn. That belief turns many capable people away and becomes a goal-post for others. They chase complexity as a demonstration of how well they know the limitations of a language or the nuances it provides.

The best programmers I know thirst for simplicity. They set fire to their old code and habits. They realize how vital it is that others can understand what they’ve written.

Do you think having a developer’s mindset causes you to see solutions to non-technical problems in any particular way?

I think that depends on what you enjoy about programming. For some people, approaching things analytically is just natural. They are the kinds of people that have to solve a problem, when sometimes all you want is for them to hear you. On the other hand, having someone around who won’t quit until things are “just right” can be a source of sudden and unexpected progress.

For some people, the expression of creativity is the most compelling thing about programming. For those people, programming is just a learned expression of the tools they already have and use.

Any interesting examples come to mind?

I work with this really talented woman, who uses JavaScript to augment her sketches and paintings. She enjoys learning how code can extend the talent she already expresses, and would continue to make amazing artwork even if she never opened another code editor.

I’m one of those people who wants to analyze everything. It takes a lot of effort to just listen, because I just want to fix all the things.

What does community mean to you as a developer?

It’s a matter of life and death to me. I often go back to an article called “The Ghost Who Codes” because it so accurately describes what I was like before I actively sought community with other developers. In it, Troy Hunt describes someone who takes and takes, never trying to give anything back. A person without a paper-trail. A ghost.

I can tell you exactly when I started to play an active part in the PHP community because it made such a difference to my enjoyment of programming, and my career growth as a result. It was when I joined my first user group, about half way through 2013.

Since then I’ve presented at ten conferences, published four books, and traveled the world. These are things I would not otherwise have had the support, encouragement, or ability to do without the community.

How do you like to communicate and socialize with other devs?

Meet-up groups and conferences are the best places to meet other programmers in person. For everything else I use Twitter. I would be in such trouble if it went down for good…

What are some of the issues (pro or con) you’ve run into when contributing to open source work?

People can be jerks sometimes. The weight of maintaining a successful open source project forces people to either be unresponsive or terse. Sometimes that terseness becomes rude. At that point it’s hard to continue being excited about contributing to that project…

What’s your favorite language and why?

I’m really liking JavaScript at the moment. Some of the newer syntax make it easier than ever to write simple, functional code. I enjoy PHP mostly because of the community working with it.

What are you working on right now?

I’m spending a lot of my time writing these days. If you set aside my day job, I probably spend about 75% of my career time on writing. The rest I spend working on various open source tooling things, like undemanding testing frameworks and async PHP standards.

What’s in your dev toolkit?

I develop on a Mac, using PHPStorm for any serious PHP development, and Atom for everything else. PHP/MySQL is installed locally (no virtualization), as I find my Macbook too underpowered to run iTunes, Chrome, PHPStorm and VirtualBox all at the same time. Now that Docker (Beta) works without VirtualBox, maybe I’ll switch to using that. For hosting, I use Digital Ocean and Laravel Forge, for continuous integration, I use Travis and Scrutinizer.

How do you use email in your apps and projects?

Email is a huge part of account management. You can’t really build any substantial application, these days, without sending a few different types of transactional email. For a long time, the task of sending those emails fell to Mandril. Then they ended their free account support and in a panic I discovered SparkPost.

How did you find SparkPost?

I heard about SparkPost at a conference. They were one of the sponsors and were honest about their services and competitors. The kind of honest that made me want to check them out…

What led you to contribute and create the SparkPost tutorials live coding videos?

Streaming is a way for me to commit to learning something new every day. After the conference, I decided to write some code to talk to the API – a kind of alternative to the PHP client their already have. It was quite fun actually. You can check it out on YouTube, if you’re keen to see what I got up to.

What’s something you love/hate about email?

Setting up and maintaining a trusted email server is a pain. I love being able to use services like Gmail (for personal email) and SparkPost (for transactional email) and not have to worry about my mails bouncing. Ain’t nobody got time fo’ that!

What are you passionate about outside of work?

I have the best family. Don’t even try to argue! I enjoy hanging out with them and making them laugh.

-Chris

 

Thank you, Chris, for taking the time to chat with us, and all of your contributions to the SparkPost community!

To keep up with Chris, be sure to follow him on Twitter or subscribe to his blog.

Community Pull Requests Blog Gears Collaboration

How Community Pull Requests have made migrating from Mandrill to SparkPost smooth

The last two months have been a rush! As the community manager here at SparkPost, a large part of my job falls into the hard to measure categories of brand awareness and garnering feedback from the community. This is usually what they call a long-tail endeavor — something that you don’t expect to see dramatic results from immediately. Until, that is, something upheaves the industry.

This is every community manager’s dream — what we were made to do! I refilled my coffee mug, rallied the troops (most of whom were already online), and we took up the banner of answering questions, pointing people to resources, and burning the midnight oil helping out developers who were left treading water in the wake of the news.

You all came out of the woodwork suggesting feature requests, offering feedback, giving us new use cases, and in general being awesome. We hope that you’ve seen us respond in kind with our wholehearted appreciation and support, and occasionally a t-shirt or sticker thrown in.

If you’ve missed the recent digests with everything we’ve pushed out in the last few months, check out what Amie Durr and Josh Aberant have to say. But we aren’t stopping there! We’re still prioritizing new feature requests, building new tools, accepting pull requests, and more, as well as having daily conversations with you all in our Slack channel.

We know you’ve been busy as well. We know this because we’ve watched you pull together as a community, build resources to help each other out, answer each other’s questions, and submit pull request after pull request after pull request after pull request after… well, you get the idea.

lucy-chocolates

On behalf of myself and all of us at SparkPost, thank you, thank you, thank you! All of your pull requests, contributions, feedback, support, and encouragement have meant the world to us. Your feedback is directly affecting our decisions, priorities, and direction as a company. After all — you’re the ones using the product! It’s been a crazy ride so far (and we know it’s not over yet!), but messages like these have kept us going, and warmed my community-loving heart:

In short, we ♥ developers and we ♥ you. We’re all in it to make SparkPost the best possible service for our customers. And while the last 2 months have been full of all sorts of exciting developments, keep your fork — the best is yet to come! Also, if someone wants to invent an IV coffee machine and send us a prototype, I don’t think anyone would complain 😉

-Mary

Biz Eval Guide Blog Footer

This last weekend we sponsored Bitcamp, held at the University of Maryland, and in my opinion, it was one of the best hackathons we’ve ever attended!  Now would be the right time to disclose my bias: I was a Bitcamp organizer in college. So having my first experience on the other side of the sponsor booth be at my favorite hackathon, was truly special.

It was also a significant event for our Developer Advocacy team. SparkPost has sponsored small to midsized hackathons in the past, but this was our first delve into the larger student-run events, and we came prepared!

We started Friday night off by giving away tons of swag, including the limited-edition SparkPost Bitcamp stickers.

bitcamp sticker piggy pennies
SparkPost Bitcamp Stickers

These were such a hit with the hackers that we’re in the process of creating limited-edition stickers for other events! Come see us at one of our next events to get yourself one.

On Saturday, we brought in a slushy machine and served Monster Energy slushies (there was a fruit punch flavor for those who had actually slept).

slushie cups piggy pennies
Limited Edition Slushy Cups

Handing out swag and raffling off prizes is always a fun time, but what made the event really worthwhile was being able to help students with their projects. Throughout the weekend, we had six SparkPost engineers answering questions and mentoring hackers.  Nothing took me back to hackathon participant times like debugging a node.js app at 3 AM on Friday night! We even got a shout-out from one of the hackers on Twitter.

twitter piggy pennies

Whether hackers built their projects with SparkPost in mind or quickly incorporated, we got a lot of great submissions for our challenge. The deliberation was tough, but Piggy Pennies walked away as the winners of the SparkPost Challenge, with $500 in Visa gift cards. Piggy Pennies allows you to automatically round up the change of your purchases in order to save money towards a common goal with friends. The team leveraged the Capital One API (available only at hackathons) to process financial transactions, and used SparkPost Transmissions and Templates to deliver detailed updates and reports on the group’s goals. The team also implemented ways to trigger money transfers by replying to the reports using our Inbound Relay Webhooks.

bitcamp winners piggy pennies
Piggy Pennies – The Winners!

The rest of the challenge submissions were amazing too — 6 of them won major prizes from other sponsors as well. They were so cool we had to pick two honorable mentions to send to extra swag to. Contap took a new approach to the “tap phones to exchange info” concept, by automatically starting an email intro and implementing Amazon Echo Alexa reminders to contact the person. The second honorable mention was part of a surprising amount of hardware heavy submissions. Fireberry Pi used sensors and a RaspberryPi to send a warning text message including a picture of the room when gas levels were too high. This team was particularly crafty, figuring out how to use carrier email to sms gateways to send a text messages using SparkPost.

Bitcamp’s theme this year was “Explore new grounds,” and I can confidently say the SparkPost team did just that. It was a great place to meet up with such a large number of developers at varying stages of experience and skill levels. We got really valuable feedback on our product and even met a participant who had recently published a SparkPost Cake-PHP Library!. Thank you to Bitcamp for putting together such a creative atmosphere. Thank you to all the hackers, we hope to see you again soon.

Make sure to reach out to our team on Twitter or in our community Slack channel if you want to connect!

-Jose

leap day 2016

Happy Leap Day, friends! It’s that magical extra day that occurs on years divisible by 4… except if the year is divisible by 100. Oh, but if the year is divisible by 400, then we do celebrate Leap Day. So easy to remember, right? No? How about we make a function to determine if this year is a leap year.

So there you go. 2016 is a leap year. 2017 is not (it’s not divisible by 4). 1900 is not (it’s divisible by 4 and 100, but not 400). 2000 is (it’s divisible by 4, 100, and 400). It’s incredible how much code is required to determine if Leap Day William is bringing you candy this year. Sadly, we as developers can fall victim to errors in calculating dates, but it does make for some good stories. Here are a few of our favorite Leap Day bugs:

  • Back in 2012, there was a bug in Gmail where all chats saved on February 29th showed up as December 31st, 1969.
  • There’s a known bug in Microsoft Excel where it thinks the date 2/29/1900 is real! This means the WEEKDAY function too is incorrect for dates before 2/28/1900.
  • Users of Microsoft Azure experienced an outage on February 29th, 2012 because the service was creating certificates that expired on February 29th, 2013, which is not a valid date.

Fortunately, there are libraries such as moment.js that can help avoid these types of bugs. For instance, you can create dates and determine if they are valid just by doing the following:

However, sometimes you have to be careful with using libraries such as moment.js to calculate dates! One example is determining the monthly billing period for a customer, since days of the month can vary. We define a user’s billing period relative to the date of the month they signed up for a paid account. For instance, if you sign up for an account on January 15th, then you will be billed on January 15th, February 15th, and so on and so forth. Easy, right? But what happens if you sign up on January 31st? February 31st is not a valid date (not even in leap years). In this case, we decided the logical choice is for you to be billed on the last day of the month. So if you sign up on January 31st, you should be billed on January 31st, February 29th, March 31st, April 30th. We use moment.js to handle date calculation, but we have to be careful with it. Check out the following ways to calculate what February 31st might be. (Note: months range from 0-11 in JavaScript, which is why set the month to 1 for February).

In the last line, moment.js assumes you mean “31 days from February 1st,” which turns out to be March 2nd! Not the result we were looking for.

So on this Leap Day (or better yet, before Leap Day), we encourage you to take a moment and test your code for date-related bugs. Does your code know about February 29, 2016? What does it think the date is a year from now? Is that the result you expected? Or maybe it’s time for all of us to switch to that metric calendar system! Whatever happens, just don’t tell your users it’s December 31st, 1969.

–Nancy

developer week 2016

San Francisco’s largest tech event of the year, Developer Week, is back and we’re proud to be sponsors! Developer Week is an intense seven days of events, including a hackathon attended by 1000+ developers, a conference with more than 13 tracks, congresses, and forums, and last but not least, a fantastic expo hall.

Come find us on Saturday at the hackathon to kick off your weekend in style. Join other passionate developers who will be building applications with some of the best APIs in the business! We’ll be giving a brief demo on the main stage first thing that morning and you won’t want to miss our expanded demo at 12:00 where we’ll dig into our inbound relay and break down our sample app. Given that it’s Valentine’s Day weekend, we’ll be riffing off the idea of compassion and love… we can’t wait to show off what we have in store for you!

After the demos, you’ll have a chance to work on your apps and integrate with SparkPost’s API to build something awesome. Interested in winning one of our three challenges? We’ll be giving away nearly $10,000 in cash and prizes to the teams that demonstrate the best uses of our inbound email relay, analytics, and Heroku/SparkPost integration. Be creative, impress us, and most importantly, have some fun! One of our mottos here is “Build Something Awesome!” and we want to help you do just that.

If you can’t make the hackathon, don’t worry – we’ll be at the expo hall Tuesday-Wednesday handing out swag, talking to folks, and walking people through everything new and improved about the best cloud-based email delivery service around!

Can’t make it to either event? You can still build awesome things with the SparkPost API! Be sure to check out our client libraries, support docs, and more resources at the Developer Hub.