Let’s face it: the Internet is all about text. There. I said it. Textual content is still the foundation of the Internet. However little thought seems to be given to actual text delivery. As a developer you just put it in the DOM, and it appears on a users screen right?


Still too many developers, but also other disciplines as UI/UX design, get this wrong. In this blog we’ll take a look at this issue, and how you can make your web fonts blazingly fast!

Adding text can slow everything down

Wait, are you serious? That thingy from 1455 is actually slowing my site down?

If you are not careful, yes. A lot of effort nowadays is put into optimizing Javascript, techniques as lazy-loading or bundle splitting, and lots of other things. …

Switching all images on a big site is no trivial task. Yet this is exactly what Magnet.me did in the first half of 2018 in order to improve performance for our users. During this transition we switched from JPEG to WebP for all supported clients, for millions of user-uploaded images, across a variety of different platforms.

Image for post
Image for post

In this blog I’ll describe the steps we needed to take to handle this conversion without any user interruption, with minimal development effort, and without operational problems.

The basics: What is WebP actually?

WebP is an image format, developed by Google. It aims to significantly reduce file sizes compared to alternative formats such as JPEG or PNG. As such it allows images to be downloaded and shown faster to users which is especially helpful on lower-bandwidth connections such as a mobile device. …

Fat chance that if you are a software engineer who mostly works on applications exposed through browsers, you don’t think a whole lot about the network. Sure it’s there to get your content to the user. And you probably thing about download times and the like a bit.

But in general your application should just work, right? You’ll get an IP address from your hosting provider, and you’ll publish the corresponding A record in DNS. And an AAAA record (as it’s 2019). That handles the network on the side of the actual user of your application.

Once they hit your load balancers the request is your responsibility again. But what about the middle part? The actual internet? Relatively few engineers think about this step, or assume there can be something wrong there. …

When we started developing inventid in Ruby on Rails we quickly realized several things:

  1. Ruby is not particularly fast,
  2. Nor is doing stuff inside an HTTP request,
  3. Yet we have to maintain a ridiculous level of fast and concurrent HTTP responses to function.

That sounds like a dilemma. And at first it was. Until at some point we grasped the concept that not everything needs to be done right now. This is true for a lot of business decisions, but it even “truer” to IT development. Moreover, some stuff simply needs to be done later on!

So we started to separate our HTTP request cycle from background jobs. …

Yup, hold it right there.

That is a weird saying from a Ruby enthusiast though. So how come?

The DSL pandemic

At some point part of the Ruby community decided we needed a DSL for #everything. Instead of a DSL, I might focus the energy on improving Ruby’s speed or garbage collection but after all I’m just a fervent user of the language and not the entire community.

And to be fair, it can be really easy to build or use a DSL in Ruby (especially in Rails!). Logically many developers use a few of them in their projects. …

In every company, there will always be some kind of waste: Time spend badly. In general this is true no matter your size, there will always be something.

Obviously we are no different.

However I learned that solving waste can be easy. Identifying it is not.

Let me give you a picture

inventid is a completely distributed company. No office but Hipchat. Beers once in awhile. One Github to rule them all. Everyday sending an email beats a phone call. No managers and hardly meetings.

This is the perfect setup to let waste (or inefficiencies) pile up. And it was.

But we simply didn’t know it

First of all it turns out people are bad at identifying waste in their own work (including myself!). You do your job as you were once told, and keep doing that. If you are unfamiliar with other approaches, you are simply less likely to realize how something can be improved. …

So last time we got to an awesome email setup with componentized, responsive HTML emails (without hating ourselves) using React. For some more fun, let’s add some additional stuff now!

  • Text emails (we need to send those along anyhow),
  • Localized texts (because your customers may prefer another language),
  • Open tracking in your emails (so you don’t have an ESP do it in exchange for €€€$$$$)

So in case you missed the previous part, check back to that post. Otherwise, you can use the dedicated Github repository to see where we stand.

Adding text versions of your email

You need to add a text version for your email anyhow to prevent them going to Junk Mail directly. So we can let Maily generate such a version as well. …

These blogpost will be different from my previous ones, as I will show you how to setup a beautiful maily environment on which you can develop you HTML and text emails, using React and MJML. In this how-to I will guide you through all the required steps.

At the end of all how tos, you will have:

  • Componentized emails, so you can easily reuse code
  • Fluid layouts, so things render well from phone to iMac
  • An email API service which generates HTML and text emails based on input JSON
  • Open tracking in your HTML email
  • Translated emails for every user
  • A command to easily generate all emails for you to check…

Writing HTML emails has to be the biggest annoyance for every single developer. For reasons, email clients can only use HTML like done in 1995, webfonts are not supported properly, CSS can be ignored (depending on the client), and some old parsers are completely horrible (I’m looking at you Outlook! Using the Word render engine was not the best idea ever).

Image for post
Image for post
HTML email horror

For inventid we experienced the issue first hand: each of our emails was around 1000 LOC of HTML madness. In order to properly send these out, we created .html.erb files, so we could use Ruby to determine which parts of an email to show, and apply localization and customization. …

Image for post
Image for post

Software testing is like brushing your teeth. Generally not that fun to do, but a couple of years later when everything falls apart, you wish you had done a better job early on.

For us there were three good reasons to test. And it enabled us later on to perform major upgrades really quick and faultless. Read more to learn how!

Image for post
Image for post

As a developer, you are probably familiar with the feeling of writing tests. Often it comes as an afterthought. It is not that much fun to do and usually the advantages are not directly apparent.

It’s a crucial job though! At inventid we strive to keep our test coverage above 90%. No matter how dull the job sometimes can be. But there is a good reason why we stick with it: it made our lives much, much easier. …


Rogier Slag

Software Engineer. Lead software engineer @ Magnet.me, CTO @ inventid.nl. General nerd. github.com/rogierslag

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store