A general way to describe caching is storing the result of some code so that we can quickly retrieve it later. In some cases, this means storing a computed value to avoid needing to recompute it later. However, we can also cache data by simply keeping it in memory, without performing any computations, to avoid having to read from a hard drive or perform a network request. This latter form is particularly relevant for ActiveRecord, where the database often runs on a separate server.

Caching is a general term that means storing the result of some code so that we can quickly retrieve it later. This allows us to, for example, avoid hitting the database over and over to get data that rarely changes. Although the general concept is the same for all types of caching, Rails provides us with different aids depending on what we are trying to cache. For Rails developers, common forms of caching include memoization, low-level caching (both covered in previous parts of this caching series), and view caching, which we will cover here.

Types of Caching Caching is a general term which means storing the result of some code so that we can quickly retrieve it later. This allows us to, for example, perform some heavy number-crunching once and then just re-use the value without having to recalculate it again. Although the general concept is the same for all types of caching, there are various mechanisms we can use depending on what we are trying to cache.

It’s no secret that developers who create toy apps, side projects, or tutorials, benefit from the process. Initially, I thought this could be boiled down to just being good forms of learning. Building something new, and even more so teaching something new, are both great ways to learn. There is another benefit, however: Developers who do this are building their own code library. Sure, maybe the code isn’t production-ready, but it’s at least a (hopefully) working example that can act as a combination of reference implementation, quickstart guide, and memory-jogger.

I remember the day my code comments died. It was 2012, I had moved up from Junior Developer to Developer. My project had started as pure R&D, then moved to prototyping, and finally to production. As part of the work, I had to develop an algorithm to run over an incoming stream of measurements and detect outliers. Once we had settled in on our approach my supervisor asked me to write it up.

Sprints My first “real” day job as a software developer was for a large and well-established company. When I started the software teams followed the Scrum form of Agile. I strongly dislike some of the terminology used in Scrum, the two main offenders are “velocity” and “sprint”. Poor naming aside, the general approach to software work in Scrum, and many other capital-A Agile methodologies, is to treat the work as a never-ending stream of tickets to be completed over time.