For the most part, college professors are an odd breed. As a student, I received some amount of education from them, but I was always more entertained by their eclectic personalities and by their proclivity to become volatile at the drop of a hat. Even though some of them had the ability to entertain me with their odd quirks, my favorite professors of computer science were the few who had both mastered the subject and possessed a keen passion for conveying its principles to a room of nascent minds. In my opinion, their greatest tool was the working example. Unlike their more pedantic colleagues, those mentioned few would spend less time simply being loquacious. Instead, they would engage their students through presenting problems on the blackboard and collaboratively helping the students to solve those problems. Even their assigned homework would contain working examples that were obviously treated with meticulous care; unlike other professors’ assignments, they nearly always compiled without an issue and ran exactly in accordance with their given description. By having some concrete form of the abstract ideas presented in class, those code samples had the necessary weight needed to sink into the nether of my mind. With them, I had an established baseline, and by making code changes and then observing their consequential behavior, I could learn through experimentation. After discussions with my classmates, I found that I wasn’t the only one who placed such value in them. In fact, we all could benefit from the use of working examples whenever we learn something new. This sentiment isn’t restricted to an academic setting and can even be applied to the workplace. For example, documentation of IT projects can be thoroughly descriptive and can convey some broad sense of an architecture, but even they can use the inclusion of detailed examples in order to better illustrate an idea. In fact, with modern tools, it’s now possible to provide user-friendly, interactive sessions that can showcase the various facets of an elaborate design. With them, a stakeholder can thoroughly absorb the presented blueprint for an architecture within an online manual, idiosyncrasies and all.
While reading the documentation for REDIS, I came across an interesting bit about the EXPIRE command. Apparently, you can set an absolute time for a key to expire, and any request for an expired key will result in its expulsion from the cache. REDIS then uses an algorithm to help retire these keys by periodically polling a random set of 20 keys; this repeated probing assists with the general maintenance of the cache. All of this information leads me to conclude the following: you can’t set a key to expire after a certain period of being ignored (i.e., no user requests for the key). Perhaps I’m missing something…but don’t you want a configurable option to set an expiration time due to inactivity? So that you can keep your cache hit rate as high as possible? Or am I the crazy one?