Category Archives: Documentation

Galvanize This: Hanging Out with Redis

So, I attended a Redis workshop a few days ago, at the New York “campus” (which is a buzzy, DB-esque industry word that I loathe) of Galvanize. Even though I usually don’t go for these meetup/workspace type of places, I’ll admit that this one was rather pleasant. Unlike other places, it did a good job of finding that fine line between casual and professional. For example, no beanbags anywhere. Because as much as I love beanbags myself (i.e., I have two at home), we can’t look at your screen together unless I get on my knees or I crawl onto the beanbag with you…which might be uncomfortable in many ways for the both of us. Plus, the space had reliable WiFi for most of the time I was there, unlike some other places.

Even though I’ve already been dealing with Redis at work for a little while now and generally impressed with its performance, it never hurts to try and learn something from the masters. (Unfortunately, AntiRez himself did not leave Sicily and fly over to teach us.) I was curious how they were going to showcase the tech and if we were going to just sit there and watch, when they instructed us to download Docker. As it turned out, we were going to learn the lesson via containers with Jupyter Notebooks, which I had never heard of before. And since I yearn for the era of interactive documentation, I couldn’t have been happier. (On a side note, I only recently learned about KataCoda, which I love just as much, if not more.)

Even though the second half of the day was your familiar salespitch for Redis Enterprise and Redis Cloud (which did seem to be an appealing purchase), the first half of the day was when they taught about the product itself. For the most part, it wasn’t anything new to me, aside from the occasional bit of trivia. (Lua is the language used by the Redis CLI? Huh. It’s come a long way since being just the scripting language for WoW skins.) I did learn a few tidbits about the data structures (like the existence of HyperLogLog), but since I use Spring Caching in our microservices, we don’t pay that much attention to them.

Instead, it was interesting to learn about the features of Redis that we weren’t even leveraging yet at work. For example, you can write your own extensions to Redis using C. Which I’d be tempted to do just because, since I miss writing in C…Also, it was interesting to learn about the various modules that were already available for Redis, with functionality ranging from machine learning to bloom filters. And that’s when I recognized a pattern seen before. Much like every other tech company, there seems to be the desire to get into whatever is hot, to survive as a company by being more horizontal. However, I would implore Redis to be careful and to never neglect your core mission. I, for one, don’t really need machine learning, but I’d like Redis to work with Spring (i.e., Pivotal) to further develop the Spring Data Redis layer and make it configurable, so I can easily direct reads to slave nodes. I need that, not machine learning. So, even though I didn’t learn a great deal about Redis by attending, I got to see the general direction of the company. In that way, I’d say that the trip to Galvanize was worth it.

That, and spears of fresh fruit.

You just can’t argue with fresh fruit spears, where the fruit is cut into various geometrical shapes. It just plucks the right strings of geeky hearts.

Advertisements

Ahead of My Time

As I take more responsibility over the web services within our department, I’m trying to be more standard in its development and maintenance, including its documentation. While learning how to correctly implement Swagger pages for our services (and, yes, I know, I’m late to the party), I stumbled upon this particular wonderful little feature: interactive documentation!

A couple of years ago, I wrote a piece how documentation should be more interactive, since that would ultimately result in a more effective tool to teach people about anything (an API, a programming method, etc.). Now, since it was actually introduced years before I wrote that piece, you can say that I’m actually behind my time. I’ll accept either. Even though it’s a more basic version of the idea presented in my post, it’s still cool that there’s some work being done in that direction. Much-belated kudos to the Swagger team!

How Interactive Documentation Can Be an Effective Teaching Tool, Part 1

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.