Friday, 28 February 2014

Evaluating the BlueCats Starter Pack: Part 1 - iBeacons

I've been evaluating the BlueCats micro-location solution for the last month or so and thought it was about time I shared some of my observations. The BlueCats solution comprises beacon hardware, a server side application that provides administration and analytics functionality, and an SDK for integration with mobile apps.

I'll leave the other components of the system for future posts and start with the component that first caught my eye - the Bluetooth LE compliant beacons.

The beacons are approximately 7cm in diameter (excluding "ears"), 2.5 cm in depth and according to the office postal scales they weigh 93 grammes with batteries fitted. As you''ll see from the photo below I was shipped both black and white units.

Each beacon is powered by 2 AA batteries and the BlueCats FAQ states that a set of batteries will last "at least 3 years". This is a good thing, as you'll want to mount these where they cannot be easily removed or tampered with.

I personally like the design of the beacons, though I imagine the cat motif could strike those of a particularly serious disposition as perhaps a little whimsical for a production environment. They appear to be made of ABS plastic and feel fairly robust; I'm not sure how they'd fare in a drop test and, given replacements would need to travel all the way from Australia, I don't feel inclined to find out.

A litter of BlueCats

You'll see from the middle beacon in the above photo that BlueCats have attached a handy label to the rear of each device showing the beacon's major and minor IDs, which is a nice touch and useful for reference purposes when testing. One of my beacons was actually mislabeled, but it was nothing that couldn't be fixed quickly with a sharpie pen.

Beacons can be permanently installed by attaching a back plate to a wall, or other surface, and then fixing a beacon on to it (the flat round object in the bottom left corner of the photo is a back plate). Adhesive strips or magnets are also good options and BlueCats thoughtfully include a few velcro strips in the box. A beacon is fixed to a back plate by presenting the unit at the correct angle and then twisting to clip it securely into place.

One slight gripe I have with the back plate design is it's easy to inadvertently put the plate on the wrong way round. The back plate will stay in place but will not be held securely, so the beacon could fall or be easily knocked off if it were fixed to a wall in this orientation. Of course the solution to this is not to fit it incorrectly in the first place, but some visual indicator might be helpful.

Putting aesthetics aside, the key question is obviously how the beacons perform. I've tested them with BlueCats' own demo application, with Radius Networks' iBeacon Locate and with my own Android based demo application (leveraging the Radius Networks SDK) and experienced no issues. Performance is consistent and is on a par with my Raspberry Pi test beacon, and with iBeacons I've had running on an iPhone and iPad.

The sample application and SDK are currently iOS only, so if you're interested in integrating an Android app with the BlueCats ecosystem your options are limited. More on this when I crack open the SDK.

Having validated the beacons it was time to test them with the BlueCats Enterprise Platform (an evaluation account is included in the start pack). I'll let you know how I got on in a future blog post.

Tuesday, 25 February 2014

Energy Harvesting Nano Beacons

They may sound like the monster of the week from an upcoming episode of Doctor Who, but these energy harvesting nano beacons are actually part of a real time location system from Netclearance Systems.

Here's a picture of one of the devices from the tweet linked above:

Embedded image permalink

I assume the energy the device is harvesting is solar, which would make these little critters ideal for deployment in a retail space...though maybe not in the dark netherworld of your local Hollister store.

Very interesting...

Update: 01/03 - the following tweet from Netclearance seems to confirm the beacons are indeed photovoltaic. Energy harvesting just sounds better though, right? ;-)

"Energy harvesting #iBeacons. no batteries - no wires. just plain old light. Stay tuned for our video and demo this week"

Monday, 24 February 2014

Principles of Alerting - Part 1

One of my colleagues recently drew my attention to this story about last year's security breach at Neiman Marcus, and specifically the 60,000 or so alerts that were apparently generated but not acted upon.

This led me to once again consider the process for handling the myriad log entries, automated alerts and status emails that are generated on a daily basis within the applications and infrastructure my team supports.

Thanks to the team's ongoing efforts we have in place good tool support, comprehensive alerting and monitoring, and a proven mature process. That's great mitigation, but the reality is that just one missed alert has the potential to cause significant trouble.

So, this seems an opportune moment for our management and engineering teams to refresh our thinking on the guiding principles underpinning our monitoring and alerting activities. I thought I'd start by documenting some of my candidate principles here and then use this to start a conversation within the team.

Here are the first five, in no particular order...

Work on your signal to noise ratio.

Think about what you're alerting and why you're doing it, make every alert earn its place in the application landscape.

A "success!" email at the end of an 8 hour batch process seems like it'd probably be useful - all sorts of people in the organisation would probably want to know about that. An "everything's OK!" alarm that sends an email to the support team every 5 minutes and clogs up the team's inboxes would need some serious justification.

The more background noise the team need to wade through before they get to useful information the greater the chance that something important will be missed. Or inadvertently moved to a seldom opened subfolder, via an email filter...defined by an engineer who is drowning in well meaning spam.

Give us a clue.

There are some pretty cryptic alerts out there - weird job step IDs, arcane code fragments, and terse (or missing) descriptions are all too common. Such a format can work if you're the person that developed the module in question, but chances are that when the alert pops up on a console at 2:30 am on a Saturday morning you'll be elsewhere, and a member of the out of hours monitoring team will have to hit the Ops Guide to see what remedial action an ERR-28001 requires.

Every second counts when you have a live incident, and critical information should be pushed to the people who need it. Why not include the remedial action (if known) in the alert text? Give the unfortunate recipient of the bad news the information they need to rescue the situation and minimise or negate the impact on end users.

Configurable is good.

Rather than following the traditional approach of hardcoding alerts into the application, consider using a tool that allows you to implement and adapt your alerting strategy at runtime. This approach has numerous benefits, including:
  • You won't need to change application code to add, remove or modify alerts - this is a good thing because as we all know every change is a risk, right?
  • You'll be able to reconfigure escalation strategies on demand. Need to include the Ops Director on a specific alert over the peak trading period?...Want to SMS the team in Poland if it's a Wednesday?...Need to change the email address for out of hours alerting? All eminently possible with monitoring and alerting tools. 
Many tools exist that'll perform some or all of the functionality described above; if you're looking for somewhere to start I can recommend the Open Source version of Hyperic.

Make sure someone is listening

Even better, make sure that "someone" is the right person (or team), that they know what to do and who to contact, and that they understand the likely impact of the underlying issue (see Give us a clue, above).

Typically your service desk and out of hours operations teams will be receiving and performing triage on alerts, so ensure they spend time with the engineering team on a regular basis to understand how key processes can fail and what can happen when they do.

A communication plan that includes internal, customer and third party escalation paths is key to reacting quickly and keeping everyone in the loop when a serious incident occurs. Ensure your front line team know who is on call, and how to get hold of them in a hurry.

Agree a standard process for known failure modes where possible, and get these agreed with your customer. When an incident occurs out of hours and you're convening a conference call at 3am, you'll be glad that you made some of the big decisions up front.

Consider leveraging your customer's prior investment.

Not as generally applicable as the principles described above, but if you're providing support services to a client there's a good chance that they will have already invested in alerting and monitoring tools. In this case it may make sense to piggy back on the infrastructure they've already put in place rather than implementing a parallel tool stack.

Going down this route can make ongoing maintenance easier, as the customer may well take responsibility for ensuring the agents are kept in good working order, and the risk of unwanted side effects from running two monitoring systems on the same server is removed.

You may need additional resources to accomplish this, for example Microsoft's SCOM requires that a gateway exist within the customer's domain, but if the opportunity presents itself it is definitely worth considering.

Well, those are my initial thoughts. I'd love to hear suggestions for additions (and corrections!) to this list - please feel free to comment below.

Tuesday, 4 February 2014

Cordova issues - adding platforms to a project on Windows 7

Just thought I'd share a particular issue I had using Cordova on Windows 7 (specifically version 3.3.1-0.1.2). For now, let's just quickly skip over the question of why I'm doing cross platform development on Windows when I have a Mac available.

I followed these instructions for getting started (outdated, but still relevant) I since found the latest documentation here. I then created a sample project.

Then it was time to turn my generic hello world project into an Android project...I executed the cordova platform add command (from my project's root directory, per the instructions) specifying android as the target. The internet can be a harsh and cynical place, so here's a cut and paste from the command window, just to prove this actually happened:

c:\projects\Beacon>cordova platform add android
Creating android project...

I tried this a few times with no success, it seemed I had a hanging process on my hands. I thought, hmm...maybe this does just take a while, so I left it running over the weekend...still no output.

I've worked through the installation process again and verified that Eclipse, Java, node.js & Cordova are all installed properly, and all of my environment variables seem to be configured correctly.

I had a quick dig around to see if there's a log file produced by Node.js that could point me in the right direction, but no luck there.

Updating to the latest version of Cordova, which at time of writing was 3.3.1-0.3.1, did not help.

I think the next step is to see if I can get under the hood of Node.js and see what's causing the apparent hang...or I could just move to the Mac, but where's the fun in that. ;-)