Four things to consider when using Redis in production
Ruby programmers rely on Redis as a high-performance key-value store for many different jobs. Redis is suitable for many different tasks, including caching, acting as the transport medium for a message bus, and service analytics. Redis is often one of the first external dependencies you reach for as a Ruby programmer because it forms the backbone of the Resque and Sidekiq asynchronous job systems.
When you’re starting a new project, it is tempting to set up the bare minimum configuration for Redis because it works well out of the box. However, once you’ve started to put some load on the system, there are several concerns that you should be aware of when using Redis. In this post, I’ll talk about some of these concerns and some high-level ways of addressing them.
The four main concerns I will discuss in this post are monitoring, security, high availability and redundancy, and horizontal scalability. This is the first in a series of posts where I will cover these intermediate-to-advanced topics in depth.
Creating a subset font
Using custom font faces on a web page introduces several potential issues. Most commonly, these issues manifest in one of two types of problem: the dreaded “flash of unstyled text” (FOUT) or “flash of invisible text” (FOIT); or poor initial render time due to font faces specified in blocking calls to outside services. By placing only a subset font in the critical render path, you can reduce the amount of FOUT/FOIT and speed up the initial render performance.
However, the creation of the a subset font is not described anywhere that I found. This post discusses how I went about creating a subset font, the tools I used, and some thoughts on what exactly you should subset in your font.