Hearing Aids and Augmented Reality

I remember clearly sitting around my father’s dining room table at Christmas about 10 years ago and listening to my parents talk about hearing aids. I remember thinking this was maybe the dullest conversation of my life. Of course it didn’t elude me that the two speakers for this topic shared DNA with yours truly and that that probably meant that some day I would more personally connected to the topic. Well that time has come.

I am at the end of a 6 week trial and while my hearing isn’t completely shit (sorry to throw you off with industry speak), the hearing aids do make me realise that I was missing things before. So yes the hearing aids are adding a function you might expect … I can hear better. Here’s what you might not expect … I can hear more than a person without hearing aids. No I’m not talking about some super powerful magnification of external sounds, I can actually hear things that aren’t there. That might sound concerning at first blush but I assure you I’m not experiences a psychotic break.

Here’s what I mean … I have fancy hearing aids which implement Bluetooth Low Energy and make my hearing aids an “Airplay device”. That means I can pick phone calls on my hearing aids, I can get Google maps directions while walking around unencumbered, I always have “headphones” for my podcasts. The veritable list of useful uses of having always-on attachments to your ears is surprisingly long. I’m now convinced that the auditory channel might be the first real opportunity to market “augmentation” to the masses. Up to now the focus seems to have been in the visual spectrum and the importance of the visual input can’t be minimised but as the Google Glass experiment has born out, super-imposing information in a useful, safe, non-intrusive way is not easy. It will happen but it may take take (and money) before we’re all tapping into our sight.

Consider instead hearing and headphones. The headphone business is a high margin, desirable business but with any business cycle the big margins will start to deteriorate as everyone wants a piece of the gold. That then leads to a need to differentiate. I suspect that higher quality audio via better D-to-A converters is more mundane part of this differentiation strategy but augmentation needs to be considered too; and it will be because:

  • Cost: It isn’t terribly expensive … the infrastructure is already there, all that’s needed is a move combine fashion with ease of wearing so people don’t mind wearing more permanently
  • Value: I’ve already found a whole host of things which are useful to impose onto my day-to-day experience and that’s without the benefit of a mainstream, big-capital industry putting effort into building these apps
  • Brand: ultimately in the game of differentiation the ability to offer “augmentation” could be seen as creating a whole new category which would almost surely command a heft brand premium and the almighty margin dollar

Anyway, my next meeting is coming up. I know because my “ears” just told me. Until next time …

Forerunner Unreliable

I’ve used various models of the Garmin Forerunner for years and feel some brand loyalty to the products but it is wearing a bit thin today as my Forerunner 620 completely screwed up yesterday! This wasn’t the first time — I was getting some VERY odd behaviour earlier in the year — but a factory reset got it back to working well up until yesterday where it decided to press the “stop” button twice on my long run. Suddenly about 10 miiles into my run I realised I had no idea how long I’d gone (as I hadn’t realised the run had been stopped)!

This was terrible but due to somewhat familiar terrain I was able to guestimate my distance and got to what I thought was 20 miles only to find out on my return that it was only 18. Very annoying.  

Vagrants in Dockerville

I’ve been playing around with Docker for a few weeks now and while I’ve used VM’s for ages I’m just starting to use Vagrant. My next task is to build a smart way for Vagrant and Docker to inter-operate. More on that once I get there.

HearthMath’s InnerBalance

I have wanted to get one of the HeartMath HRV devices for a long time and yesterday I finally did. I opted for the InnerBalance product which is mildly less expensive than the old standby the emWave 2. Cost aside the main difference with the InnerBalance is that it runs on IOS (and finally with the Lightening connector) rather than the emWave 2 which has it’s own physical unit for processing the signal. To me the smart-phone variant was superiour in every way … 

  • No additional piece of hardware required (other than the earpod measurement sensor); makes it far less cumbersome and mobile
  • The immediate feedback look, particularly when away from a computer screen, has a full display to provide feedback on rather than communicate state through a few LED lights (although admittedly this can be enough in many cases if you’re just wanting to know coherance state).
  • I assumed the ability to share my results more readily since the data and visualisation were already on my phone and therefore available to the network

It was this last point that got me writing this post in the first place … I was shocked to find that when you press the “share” button after a session what you’re sharing is NOT your data from the session but instead marketing material for the product. Really? Wow that is incredibly lame. To make it even more lame, the application I happened to share to was OneDay which I use for a personal journal. How useless is it — for all parties — to share a marketing message with myself. Annoyed.

State Management is Cool?

I know it sounds like a dry topic … do you really want to think about, talk about, or associate with others who spatter on about something as uninspiring as “state management”?

Well I’m thinking yes. At least that’s the conclusion I have come to over the past two years. For decades computer science students have been told about the importance of state management, have been given cryptic tools like K-maps, and been told that was critical to simplifying complexity. For me at least, the ideas in the classroom had a harder time translating into discrete activities in the real world. Sure “state mattered” but it was talked about it through abstractions like a functional decompositions, site maps, screen design, and many other “real-world” exercises which all dance around state management without ever addressing it head on.

What’s changed? Well I think to reach the next level of complexity, society — often unknowingly — is needing to document state more directly/explicitly in an attempt to simplify implicit models that predated them. Oh really? Is that what you think professor Ken? Well an example might help. Good point, I’ll give two examples for now and leave your creative imagine to fill in the rest.

Let’s start with EmberJS which is a new breed frontend MVC framework which set out to solve complex web applications (they describe themselves as “a framework for creating ambitious applications”). There are lots of great things the framework provides users but at the core of the value being provided is an opinionated architecture which means that to solve today’s problems we need to leave behind yesterday’s debates and Ember promotes this by having a default way of addressing many sorts of problems. This by itself is an attempt to simplify but it isn’t the crowing example I want to point to. Intead it is within this framework the core feature that really adds value for Ember developers … the router. What is the router? It is a state machine! It provides a powerful framework for developers to build complex application and at the centre of it is a state machine. Interesting.

Now for my second example. Docker. BTW, this is some hot-shit technology; if you’re a developer or in operations and haven’t played with it yet, stop what you’re doing (well right after you’ve finished my blog post) and check it out. Anyway, Docker has a feature called “Automated Builds” which scripts the building of a “machine” (well really its a container but let’s not get too technical). The goal of doing this is so that you can build the a machine in a completely explicit and stateful way. No longer your code — which no one doubts is just perfect — work just as well on that fancy OSX machine as it does on production because the “machine” you’ve used isn’t just similar it is identical. Turns out absolutes matter a lot. Identical is a lot better than similar. Fully automated is a lot better than pretty automated which is a lot better than manual. In many ways giving Docker credit for any of these things is not fair as many technologies that preceeded it at the very least laid the groundwork but my point is that the reaction to Docker is near universal in its praise. People don’t need convincing tha this technology can help them. And why? Becuase it helps to manage state.

If you’re not yet convinced that state management is important, interesting, and maybe even cool … then you are clearly a cold and uncaring person. I have already given up on you. Let’s hope you never give up on you. Harsh? Well maybe but then what do you care? You stoic, stateless bastard. :)

RAID Recovery

My Promise Pegasus RAID array demonstrated its worthiness this past week. After a lot of weird shutdown and non-graceful disk dismounts it became clear that one of my physical drives had become damaged. In a normal situation this may well have resulted in data loss but with a RAID it was simply a matter of pulling out the misbehaving drive. This immediately removed the inconsistent behaviour and without any data loss, I was able to continue on with work with no interruption. I ordered an extra drive and put then in a few days later and am now back to running in a redundant mode. As a final step I ran the same performance tests I ran last week and it appears there may now be a small improvement in disk read/write performance too now that the errors on the faulty disk have been removed:

Performance after new disk