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!
Wait, are you serious? That thingy from 1455 is actually slowing my site down?
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.
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.
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:
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?
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.
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.
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!
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:
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).
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. …
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!
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. …