Category Archives: Quick Tangent

Quick Tangent: Dumb Bots

So, there’s been so much talk about AI lately, and in particular, there’s a great deal of interest in bots. No, not the Mirai kind (which hopefully isn’t plentiful in the future, despite its Japanese translation). No, I’m talking about the friendly, enterprise kind. You know, the chatbots on Facebook that are supposed to be helpful snippets of AI, capable of booking hotel rooms for you. Of course, I don’t really understand the usefulness of these bots, since there’s no way that a bot could help me find the ideal room faster than my own investigation. In fact, they seem kinda…well…dumb. But these bots are probably not aimed at a self-appointed pariah of social media like myself. Instead, it’s probably meant for those people who are younger (i.e., millenials) and who are more predictable (troves of available marketing data via Facebook, less variety of purchases, etc.). In that case, I suppose that it’s useful for some but not for myself…or is it?

Similar to my reaction to chatbots, I never quite understood the newfound love for Slack. It’s a messenger app…so what? However, as I started to delve more into it, I started to understand its appeal through its extensible functionality, especially to developers. I can create a simple bot (or a basic web service) on my public-facing servers, so I can use Slack to talk with it on my phone and get the status of machines and processes? Okay…that’s kinda cool. (Assuming that your company and networking department embraces the idea of allocating machines just for this purpose. Trust me, I know…that can be a hard sell.) So, maybe, must maybe, I could be down with these chatbots. That way I could use Slack (or Skype) and be hip like the cool kids!

Hmmm…so how I could I actually pitch this one to the brass? Curious, I looked to see if there was already an enterprise version of such a solution, and though I did find one or two, they seemed to be costly and less flexible than desired. So why not just build one cheaply on my own? Since I recently read something about Microsoft’s nascent bot framework and its integration with Skype, I figured that I could start there as a quick way to prototype. After proceeding through a few quick tutorials, it became obvious that a chatbot is nothing more than a tailored RESTful web service, and with that realization, I quickly assembled and got working the prototype that I had in mind.

However, over the next few weeks, I started to realize that it wasn’t viable. One, since this framework is too young to even stand on its own wobbly legs, Microsoft keeps updating the framework and breaking my stable prototypes. As with previous experiences when dealing with a Microsoft gestation, I wondered again if Redmond’s new projects (along with their frenetic and seemingly bipolar updates) are victims of Conway’s Law…Two, I read about how Skype does not and will not support third-party bots that are not publicly registered in their Bot Directory. I’m fairly sure nearly all of the company brass would have a problem with a publicly available chatbot that tells the status of our internal servers. Just a hunch.

After taking a quick look at other platforms, I came away with similar impressions. In the end, I’d say that chatbots are like a lot of new tech these days: lots of potential but some distance away from ultimately being practical.

Quick Tangent : XML Schema Evolution

So, after my last post, I got curious: is there any software out there that performs XML schema evolution, even if it’s proprietary? Oddly, after searching for a few minutes, the answer “no” seemed to be coming back from the web. Now, Oracle and IBM do offer a service to update your current XML documents according to a new schema…but only if it doesn’t invalidate the old schema. Basically, their “evolution” functionality allows you to further refine your schema’s rules, like changing the maximum/minimum of a tag’s occurrence or adding a new required tag. That’s hardly any sort of evolution; it doesn’t even provide the ability to automatically rename tags/properties like Avro! So, the claims of Oracle and IBM might be more marketing than engineering.

But I guess that marketing and buzzwords are all too normal in software…After all, whoever coined the term string interpolation definitely took some severe liberties, since it’s sure a long way off from real interpolation. In any case, there seems to be an opening for a niche market here, one which could be somewhat lucrative. However, these days, all the big bets of towering chips are on the table of machine learning, big data, and AI. In the eyes of the major league, anything that deals with XML (i.e., old-school data processing) should go play the slot machines.

Good for me…I don’t mind being stuck alone in a dark corner! Reminds me of playing Street Fighter 2 by myself in the back of a pizza parlor and having a blast…In any case, I was looking for tools that could help build an engine for XML schema evolution. Interestingly, I found an open source project by Dmitry Pekar that can convert both ways between XML and Avro. That could help by extending the functionality already in Avro…but besides the simple renaming of tags/properties, it doesn’t satisfy my proposed requirements. (Plus, your distributed architecture would have to ultimately use Avro, which would be a refactoring headache in some instances.) I haven’t found anything else yet, which makes me suspect that my handcrafted MDD approach might be the only viable option.

Quick Tangent: An Open Standard for Indoor Navigation

“Since when did this blog become solely about indoor navigation? I thought that this thing was supposed to be about metadata?” Well…I can’t argue with you. I need to get back into that at some point.

In any case, after sampling different platforms for indoor navigation, I’ve come to notice something: there is no open source standard for indoor navigation yet. Of course, there is much discussion about indoor navigation within the gaming industry, especially within the community for Google’s Project Tango…but there isn’t as much talk when it comes to API standards. Considering that open source standards seem to be falling from the sky in the last few years (for cloud computing, for automobiles, etc.), it seems fitting that one of the bigger players (like Indoor Atlas or Estimote) should take this opportunity to lead the way with an open standard. As IoT invades our lives, indoor navigation will probably become more prevalent, and more development standards would be beneficial to the industry. (Of course, these Northern Europeans are probably too busy slugging it out, since that’s part of the travails of being a startup company.) I suppose another unmentioned company could also take this lead, but I’ve found that many are not as developer-friendly as Indoor Atlas and Estimote; most require any interested parties to fill out an application before even allowing access to their documentation.

Now, it wouldn’t have to be an all-encompassing standard, but it should probably take into account each of the strengths in the current set of available platforms. In addition to the practice of emulating Apple’s Location Manager (which they all seem to do in their iOS SDKs), an open standard could include interface methods for functionality like:

  • The ability to overlay the indoor navigation map over an actual world map (which is offered by Indoor Atlas).
  • The ability to generate a map of the indoor space dynamically (which is offered by Estimote).
  • The ability to raise a signal (email, text, etc.) when someone enters the navigable area (which is offered by both Indoor Atlas and Estimote).
  • The ability to generate an account with the vendor’s services programmatically (which I could see as being helpful to developers who want to incorporate these services into their own products).

Maybe I’ll create a sample and upload it to Github in the near future, as a more verbose example.

On a side note to this new standard, we can leave out some of those confusing and misspelled messages that are generated by Apple’s Location Manager. Who comes up with these things?

Quick Tangent: Baby Steps

So, after eating ice cream and crying in order to get over the reality of an unlikely romance with my beloved vaporware, I emerged from my sadness with the determination to still create a prototype of my haunted house game. So, I decided to bite the bullet and start on my long trek to becoming a bit more experienced with creating IoT devices on my own. Not really knowing where to start, I looked online, and on a whim, I ordered the Windows 10 IoT Pack by Adafruit.

Since my last excursion with soldering took place when Radiohead was still a nascent band, it’s reason enough to say that my return to circuits will probably involve a significant learning curve. (That, and I momentarily thought that the kit’s mini breadboard was a thoughtful snack included in the package.) I’ll be playing with the various peripherals in the upcoming weeks, with the hopes that I’ll actually make some progress. First goal: make the Raspberry Pi repeatedly poll an Azure web service and get an indication to turn on a LED light. Even though it’s a modest goal, I’m sure that it won’t seem that way when it’s finally done. Good luck to me!

Quick Tangent: An Alternate to the Interviewer Norm

For over a decade, I have served regularly as an interviewer (specifically as a technical screener) for candidates that come through our doors. Of course, I’m expected to provide further insight as to their general compatibility with our teams, but the main priority is to gauge their prowess as a developer. It’s always imperative for me to be as transparent and considerate as possible, since I remember being on the other side of the table. In addition, it’s essential that I remain contextual while conducting my evaluation. When I was younger and pursued other opportunities, I remember attending various interviews and discovering a dearth of all three elements: transparency, consideration, and contextual evaluation. Even though the absence of the first two was somewhat annoying, I found the lack of the third to be maddening. Upon exiting an interview, my mind would be a cauldron of questions. “Why are you asking me to tell you about the quicksort algorithm, especially when it’s just memorization? How does this actually prove my more dynamic capabilities and get me better acquainted with your daily goals?” (Though, as I can tell you from personal experience, it’s probably best not to vocalize these thoughts to the interviewer, as constructive as this criticism may be intended.) Of course, the prospective candidate should be tested to ensure their command of a platform, a language, and all other important developer requisites. However, unless the position has a particular focus such as graphics optimization or a trading platform, a more general position (like within IT) should look for optimal employees by focusing on their overall problem-solving skills, especially in relation to the actual business at hand.

So, fulfilling a promise of long ago, I have made it a point to focus any tests on a potential employee’s problem-solving abilities, and apparently, there are others who think the same way. (Though, I’m not sure that I would entrust the DoE with understanding that same idea.) It’s important to recognize that all of computer science relies on the heavy-lifting work of algorithm creation done by our seminal predecessors, and all developers should have some foundation in that…but in this day and age, we should also recognize that the majority of software work today does not dwell in such deep, dangerous dungeons. So, when I prepare for an engagement with an interviewee, I always have work-relevant conundrums available for presentation. Some questions of this quiz only require a short audible answer, some of them exist as simple tests (i.e., condensed versions of work issues) that must be solved with some written code. If the interviewee feels comfortable while I watch and question the work, then it’s even better. In doing so, this interview becomes mutually beneficial to both parties. For the interviewee, this discourse provides a preview of the actual assignments and interactions to be expected upon employment. As for me, I get a better sense of the candidate’s ability to reason and of their general approach to development. For example, you can actually detect whether the developer has the ability to quickly infer whether certain functionality should be considered reusable or not. (You can’t realize such a quality of a person by asking them to recall the steps of the quicksort algorithm.) Consequently, I have found such a technique to be repeatedly favorable for all involved, and it’s my hope that more interviewers will also employ such a method in the near future.

Quick Tangent: The Heartbreak of VDKs

As I proposed in an earlier post, it would be cool to transform one’s home into an haunted house. However, given that it would be a rather tiresome chore to implement all of it from scratch, I wasn’t seriously thinking about committing to such an endeavor…until someone pointed a possible replacement for all of the hardware and software regarding the sensors: the Tile App product product. Hmmmm…that would be a cool idea, if they happened to have a SDK available for it. “They wouldn’t…wait a minute…they’ve been talking about an available SDK since 2014?” Excited, I looked for this promised SDK on their site…but to no avail: my dream of a SDK turned out to be a real VDK (i.e., vaporware development kit). Hopefully, my broken developer heart will one day bloom again with the sight of such a shiny, new SDK…but based on past experience, I’m not holding my breath.