Category Archives: Product Reviews

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.


Red Shirt Tour NYC

A few weeks ago, Microsoft VP Scott Guthrie stopped in NYC as part of his promotional tour for Azure’s cloud services. Normally, I don’t really care for these long informercials, but I decided to go in this case for two reasons. One, it took place in Cooper Union’s Great Hall, which was something historic I had always wanted to check out. Two, even though I’ve played with Azure’s offerings on occasion, I was curious what Guthrie would highlight in his presentation, especially after friends and colleagues had talked up Azure in the last couple of years. So, I went, and I was surprisingly glad that I did.

A few years ago, when I learned of some of Microsoft’s ambitions in the cloud space, I bought some MSFT shares and thought that they might catch up with Amazon in the cloud space. Impatiently, after a year, I began to have my doubts, and I sold off the shares. If you look at its latest price, that was clearly a mistake. I should have held onto them, and while listening to Guthrie’s presentation, it became painfully obvious as to why. Of course, he talked about the inherent power of Azure, with its various data centers around the world. (Which were all shown in a dramatic video seemingly directed by Michael Bay, with an intensely dramatic score blaring in the background.) However, it was the maturity of the platform, with its various tools and considerations for the user that was impressive.

Even though I’ve only dabbled with cloud platforms, I especially appreciate their raw power and penchant for structure. Even when you create apps that are meant to be deployed for the cloud, it heavily reinforces structure in their templates for developers. For example, if you build a web app within Visual Studio destined for Azure, it refers to queues in the project template by default (which are automatically available in Azure). You might question its need to reinforce such a feature through templates, thinking that the usage of queues in a web app as obvious. “What vital web service that receives a POST wouldn’t automatically queue that request, since the resources to fulfill the request might be temporary unavailable? Who wouldn’t do that?” Oh, you’d be surprised. Let’s just say that such bug-ridden deployments are not unheard of.

First, Guthrie talked about the typical use cases of cloud offerings, like creating and deploying a serverless app with ease or creating a container and deploying it with Kubernetes. Even when he talked about deploying apps to specific data centers, those features were interesting but expected. (I still have mixed feelings about the Azure Portal dashboard, but since that’s an argument about interfaces, that’s an entirely different subject.)

However, I was more impressed when he started talking about the other free tools offered by the platform that were supplemental. For one, its inherent monitoring system was akin to Splunk, and it could be used to monitor and query your entire setup (apps, databases, hosted servers, etc.), and you could customize your system instances with networking rules (like lock port 54545 every morning). Next, the number of devops options seemed more diverse than I remembered (with build options including Maven). There was even a tool which would suggest how you could reduce your expenses, like by consolidating servers and minimizing resources (storage, # of dedicated CPUs, etc.). After watching some examples of machine learning and image recognition, my only regret was that I had no reason to use them in my own projects.

After several years of concentrated effort, they had created an impressive, mature cloud platform that definitely could give Amazon a run for its money. I only had two points of contention. One, this promotional tour was somewhat eponymously named The Red Shirt Tour, since I was told by staff that Guthrie has a certain love for them. Aside from a terrible name for the tour, I would say ditch the symbolic shirt, since that will forever more belong to Jobs. Pick a hat, and in order to reinforce Azure, go for a blue beret instead.

Two, they served Subway for lunch. To which the answer is always no.

Yes, it was free. However, just like if you were offered torture for free, you shouldn’t accept it.

Aside from that, though, I walked away impressed. Nicely done, Guthrie and MS!

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!

And the Search for (Inexpensive) Indoor Navigation Goes On

So, as for the waiting addressed in the last post (i.e., the latest about the Haunted House saga), it ended when the next package of beacons finally reached my house. Almost immediately upon arrival, I registered the beacons using my Estimote account, and now having a total accumulation of six beacons, I placed them around my home and started the Indoor Location app on my iPad. As excited as Ralpie Parker with his BB gun in A Christmas Story, I started the app and followed the tutorial. “Okay, now I just need to create a location with the ‘Add new location’ button…where is that button…” After a minute of being unable to find it, I looked online and found nothing to assist me, feeling a little like a newb for not being able to resolve my problem.

Defeated (and now feeling more like Ralphie when he shot his eye out), I sent an email to Estimote so that they could enlighten me. Now, they did respond quickly with an explanation…but it wasn’t exactly the one that I had wanted to hear. It seems that the iPad could only navigate an indoor location with their app; if you wanted to setup a location with their app, you needed to have an iPhone. “Say what?” Yes, you’ll want to navigate a location using an iPad’s wide display, but you’ll have to create the location with the phone. It is, for the most part, a two-device solution. (My only guess is that the Bluetooth capability of the phone is more powerful than the pad.) Of course, one can imagine how happy that answer made me, but in fairness to Estimote, they empathized with my plight by refunding the cost of the beacons to me. Still, I would recommend that they explain the hardware requirements in flashing red letters on their site for future customers, since that might be something of interest to them before making a purchase.

So, back on the hunt I went. I was definitely finished with looking for a hardware-specific solution, and after looking around a bit more, I found a compelling product that needed no peripheral hardware at all: Indoor Atlas (i.e., IA). Interestingly, their solution did not need beacons since instead of using Bluetooth or GPS, it relies mainly on the electromagnetic fields that exist within the confines of a building. Based on my limited time spent reading (i.e., scanning every other word) and as I understand it, it seems that each room has an unique signature in terms of its EM field, and if you walk around your appartment with scattered waypoints, it can create a traversal graph based on your walk, with the unique EM fields being nodes. (If some WiFi is available on the premises, that can be of some help as well.) And all you need is your phone and nothing else. Cool! Even though I’d been let down so many times before, I got excited once again, and I downloaded their Map Creator app in order to get crackin’.

So, creating a map went fairly smoothly, with me walking from waypoint to waypoint in order to exhaust all permutations of possible navigation. In fact, as you create all possible edges between vertices in this messy graph, the app shows you its estimation of where you are, and with each new edge, it does seem to get smarter. Once I was done with my walkthroughs, I uploaded the data from the MapCreator app to my Indoor Atlas account, and I proceeded to generate a map of my place. The only question was: how can I use it? With Estimote, they had an app to showcase their tech, so that you could watch it in action before writing one line to call their API…but not so with IA, it appears. Basically, if you want to navigate your generated map, you’re going to need to get dirty: create your own app and access the map through the Indoor Atlas API. Since IA supports both Android and iOS, I was hoping for some sort of Xamarin solution…but, unlike Estimote again, no dice. It looks like I’ll be blowing the dust off my buddy’s aging MacBook in order to see what I can cook up on my own.

Initial Estimations of Estimote

So, in my last post about the Haunted House saga, I had finally found a product that offered me hope when it came to a technical foundation for creating and tracking objects in a very local space. (Just the thought of pouring over books about math and Bluetooth hardware gave me a headache.) So, with joy, I started to read about the services offered by Estimote. Basically, they supplied both IoT devices (i.e., beacons) and a SDK that enabled you to detect their beacons (which you would deploy yourself around a space). That was interesting by itself…but then I found the mother lode: their Indoor SDK package. Basically, with that SDK, they provided the software that created a 3-dimensional model in your app…and helped you track someone/something in it! And their platform was available for both iOS and Android…and Xamarin had even created components for both platforms! Oh Mommy!

Since their business office is here in New York, I got the opportunity to have coffee with one of their sales people, and he was kind enough to offer me a discount on my initial purchase. Excited, I bought a kit of 3 location beacons, and once they arrived, I set them up using their online tutorial and downloaded some of those Xamarin Android projects. (When you create your online account, you can change your beacons’ settings through your account, and then the Estimote app on your phone pushes those settings onto the beacons from the cloud.) First, though, I started by playing with the Estimote app (in order to confirm my beacons were working properly), and even though the app did notify me when I had approached one of my beacons, it seemed to have a hard time with estimating distance…and it seemed to think that I was moving when I wasn’t. Nonetheless, it was working, and I was building a prototype for a game, not a rocket! So, with some positive results as fuel, I dove into their Xamarin projects with more simple functionality, like notifications. I got mixed results, but again, I was prepared to get my hands dirty if needed. Indoor SDK, here I come! Oh, wait a minute…something is not right…I need 4 of these beacons that are sold in packs of 3? And the Indoor SDK is only available on iOS??? Grumble, grumble, grumble… Well, kids, take this lesson to heart: always read the fine print first before you get too excited.

Of course, when I thought about it, it made perfect sense: Android hardware is too varied in quality and specification to write accurate libraries for all of them. I get it..So, at this point, I asked myself the simple question: do I call it quits here? Uhhh…is my name Quitter McQuitFace? Exactly. So, I went ahead and ordered another pack of 3 beacons, bought a refurbished iPad, and arranged to get an old MacBook loaner from a friend. While waiting for my next beacon package to arrive, I’ve played with some of their more fundamental iOS code samples, since it would be a while before I would get to play with the samples for the Indoor SDK. Again, as I noticed when initially playing with the Estimote app, some of my results were anomolous. For example, when playing with a notifications sample deployed to the iPad, I seemed to receive inconsistent alerts when approaching or leaving a beacon’s domain; in fact, at times, it seemed to tell me that I was approaching a beacon when I had walked away from it! Hmmmm…I’m slightly concerned, but my curiosity and optimism is too high to be knocked down. Now, in order to get to the good stuff (i.e., the Indoor SDK), I just need those extra beacons. “Oh, and the waiting is the hardest part…”