Alternatives to Mandrill Reviewed

I’ve been a user of Mandrill for a while, it’s a great service for sending transactional email. I only use it for a couple of personal projects (mainly because Gmail started getting funny when I was sending through them). I just checked my account and I average one email per day. It’s slightly higher than that as I send at least one a day, sometimes more. If I send fifty emails in a month it’s been a busy one.

I took advantage of their very generous free tier that offered 12,000 free emails a month (which got removed last July). I barely made a dent. So their recent announcement that you will soon require a paid MailChimp account to use Mandrill, and to pay for all email sent via Mandrill, meant my days of use were numbered (I wasn’t the only one, it wasn’t a popular decision).

There are plenty of alternatives, so I thought I would check them out and see which best suited me.

Requirements

My requirements were pretty simple:

  • A free tier (ideally) allowing for 100 or so emails per month
  • A simple web API, ideally with libraries for common languages like Python and PHP
  • Ability to host templates preferred (so I can just load the data I need rather than the entire email) and a simple templating language
  • No requirement to set up a domain (I could do it, but these emails are only sent to me, so spoofing should be fine)
  • Good deliverability (I still need my emails to get through)
  • Good documentation

The Contenders

During the outcry following the Mandrill announcement, a number of options were put forward by the community:

  • Mailgun
  • SendGrid
  • Mailjet
  • SparkPost
  • SendinBlue
  • Maildocker
  • SocketLabs
  • Pepipost
  • Postmark
  • Elastic Email
  • Sendwithus
  • Amazon SES (discounted as no free tier* and reports of poor deliverability)

* Yes, strictly speaking you can get it free for 12 months or if you have an EC2 instance Continue reading…

Front-End Markdown Gallery Script

When I converted one of my sites from WordPress to static, I lost some things. One of those was the ability to easily generate a gallery of images; thumbnails that link to larger versions.

Markdown, which is what my posts are now written in, is great for writing without the overhead of a having to wrap everything in raw HTML or stop to select icons in a WYSIWYG, but it also lacks the ability to generate the code for a simple gallery. So my only option would have been to write HTML in the middle of the text.

Instead, I whipped up a bit of JavaScript to scan the page for lists that consist solely of images (linked or not) and adds HTML to make it easy to style them into a gallery (for example, wrapping the list in a div tag and converting the list items into figures and figcaptions).

You can find an example in this post.

More details and the script itself can be found on Github.

Hosting a Site on Surge

Having converted one of my sites to a static one, I decided to try out some of the alternative options to traditional hosting packages. I drew up a list of a few options and set about trying to get my site online.

Getting Started

I began with Surge because it looked easy (having started to wade through the Google Cloud Storage instructions, which did not). That didn’t exactly prove to be the case because the dev server I happened to have the site on is running Ubuntu Precise Pangolin (12.04 LTS) and the latest version of NodeJS in the registry is old.

I ended up following the instructions here to get it installed:

curl -sL https://deb.nodesource.com/setup | sudo bash -
sudo apt-get install -y nodejs

I still got a bunch of warnings from npm about deprecated this and that, so ran the suggested command:

sudo npm -g install npm@latest

Finally, I was able to install Surge.

Creating a Site

I switched to the folder path for my static site and used the following command to create a CNAME file:

echo leepenney.com > CNAME

I then typed in the surge command and followed the prompts to create a new account and away it went.

After it had loaded the files and they had propagated to the CDN I got a success message.

I then headed over to my domain registrar and set up some CNAME records as suggested here.

Within seconds I was up and running on Surge.

Speed

In my optimization post, I stated the results of various speed tests, which I ran again once uploaded.

Original hostTest host
PS Rank (Mobile)88/10088/100
PS Rank (Desktop)93/10093/100
WPT First Byte0.156s0.464s
WPT Fully Loaded2.892s5.051s
WPT Bytes (KB)1,0931,093
GTMet YSlow88%92%
GTMet Load Time2.5s1.5s
GTMet Size (Mb)1.051.05
GTMet Requests1515

As you can see, some stats remained the same, a couple were worse and some improved. A bit of a mixed bag.

Summary

Set-up difficultyGoodAssuming you don’t have issues with your OS and/or have NodeJS already installed.
Set-up timeGood
SpeedGood
CostGoodA paid tier is available.

Final Thoughts

I’m not a massive fan of having to install things (the entire of NodeJS and npm in this case) just to upload files, but once I managed that feat the process was very smooth and literally took seconds, so it was worth the effort.

The basic tier is free and there’s a paid one at $13 a month.

So far, so good. The site was loaded 27th Jan and I’ll run it for a few weeks to see how it goes before heading off for the next host.

Experiments in Alternative Hosting

I’ve pretty much always hosted my sites in a shared LAMP environment. My host, Vidahost, has been great and their cloud hosting is the next step up from traditional cPanel fare. It’s been very reliable and is packed with features. With the re-emergence of static sites, the range of ‘hosting providers’ has increased though.

Many are non-traditional. In fact a large number are off-shoots of the gobs of storage and other services you can now find in the cloud, or are at least built on them. I have already dabbled with Github Pages, which is one example.

With that in mind, I set about drawing up a list of places to try with my newly static site. Continue reading…

Tips for Building a Site with Hugo

The documentation for Hugo is generally very good, but I ran into a few areas where it left me confused, or useful things were missing. I thought I would write up some of things I struggled with (and will possibly add to the official docs).

Some of these were down to migrating from an existing site and wanting to match things like URLs.

Variable Casing

I found it often confusing, sometimes bewildering, as to why certain variables weren’t appearing or evaluating, only to find the casing wasn’t correct.

In the layouts, variables are generally camel-cased (except for parameters in the front matter, which are all lowercase), but then you get things like RSSLink rather than RssLink and BaseURL rather than BaseUrl.

This is also true of the config file used to control the site. I found baseurl to work, rather than baseURL as stated in the docs (although the examples have it all in lowercase). A seemingly missing variable is rssURI, which defines the filename to use for the generated RSS feed (see below) and completely fails all the other ‘standards’ for variable names. Continue reading…