Project – Card Skimmer Detector via Make

It’s summertime, which means the kids are on and off camp throughout the summer.  We’ve done a few projects in the past with Raspberry Pi and Arduino, and this project for a Card Skimmer Detector came across my feed from Make.

Not content with just following instructions, I ordered a slightly different display than the one used by Tyler Winegarner for the article.  I’m hopeful that it’s similar enough, and a quick review of the driver referenced in Tyler’s code seems positive.

Two of my kids will attempt to get this going on Pi Zero W’s with preinstalled headers from Adafruit, and I’ll dig in with some soldering required.  I also ordered some small piezo speakers and a USB GPS receiver that I might try to integrate.  I pre-printed a handful of basic Pi Zero cases from mynameishamish via Thingiverse but will probably design something more custom after we see how the project comes together.

Reading List: What’s the Future and Why It’s Up To Us


On the flight out to Seattle on Sunday, I finally finished up Tim O’reilly’s overtly named What’s the Future and Why It’s Up To Us. In a coincidence of timing, this morning I also scanned across Jeff Atwood’s reference to an observational call to action (from Pamela Druckerman) in the following tweet:

The book was a deep read on how Tim has observed transformative change occurring in recent decades.  There are ample examples, including very current trends in politics, technology, and economics, where the reader is walked through the development of a new mental map to understand why the change made sense.  It’s often the case that looking back on disruptive changes, they seem obvious and inevitable, but it takes a spark of ingenuity or genius to build that new map without the benefit of hindsight.  The challenge that the book hopes to instruct, is to identify opportunities for reframing our own views in ways that lead to constructive, but disruptive change.

Tim has been well positioned to observe and report, and includes anecdotes and quotes from key players in past significant disruptions.   There are also many references to traditional business authors, like Drucker and Collins that will be familiar to many MBA students, including critical takes on some widely held beliefs about what makes business tick, especially in the United States.

Beyond understanding the processes of disruptive change, the book spends quite a bit of print developing ideas about what types of changes are good for people, good for humanity, and good for the future.  In what seemed like an echo of this theme in the book, this morning I sat through an amazing keynote by Microsoft’s Satya Nadella which included a professorial call to action for developers to build the future that humanity needs by embedding privacy, security, and ethical choices in the systems and AI that we build for the future.

This book is a great read if you want to gain some knowledge about historical twists and turns in the technology industry, to slightly reprogram your brain for how to look out for disruptive change, and prepare yourself to help make a positive impact on the future.

Starting a new Adventure

After 99.5 months (sounds more interesting than “8+ years”) at Microsoft, I’m heading off on a new adventure with Cloudera. Over the years with Microsoft I have worked with some amazing folks in support, consulting, and sales.

Thanks to all the folks from Microsoft who have mentored me, worked along side me, and who wished me well as I made the difficult decision to depart. I know that I started some lifelong friendships along the way.
Last day at Microsoft:
IMG_3059

And thanks to all the Clouderans who have helped me find this new opportunity, believed that I was up to the challenge, and welcomed me to the team. I’m excited about focusing intently on the Hadoop ecosystem, and I feel like I’ve found a great fit with the energy and culture I’ve seen so far at Cloudera. It’s going to be a fun adventure!
First day at Cloudera:
IMG_3081

Reading List: Rework

I just finished reading Rework by Jason Fried and David Hansson and found it to be a very interesting treatise on what “right” can look like for a small business.  The authors do a great job of deconstructing the assumptions around “corporate” behavior, and the alternative work environment they describe seems almost Utopian.

Whenever I read books about behavior and organizations, one of the mental filters I try to put the ideas through goes something like: “Would this work for a non-profit volunteer group?”, “Would this work for my local McDonalds?”, “Would this work for a government agency?”.  I don’t do this in order to find flaws in a model, but rather to understand it better, to identify assumptions, and to see what truths in the model might be universal or transferrable. The main blocking point to pulling some of the ideas in the book into any organization would be that there needs to be a baseline of mutual trust and respect that might be lacking in some arenas.  With that said, I think many of the lessons on decision making, planning, and communication can be helpful wherever they are applied.

To a certain extent, the advice in the book is prescriptive and not necessarily transformative.  This is by design, and I see a lot of great ideas for avoiding pitfalls that many entrepreneurs, managers, and employees fall into. It’s hard to find any direct critique because the tone is very conversational and easy to read, and instead of telling the reader what they should do without any real backing, they simply describe what has worked for 37Signals. It’s folly to argue with a set of behaviors that have shown to be successful over the years.

If I ever find myself starting a small business, or working at one, this will be a definite periodic re-read.  As it stands now, I’m trying to absorb how these ideas fit into my personal sphere of influence.

The book is available from Amazon

Reading List: Ruby on Rails Tutorial: Learn Web Development with Rails (2nd Edition)

Over the past several months, I very slowly worked my way through Michael Hartl’s Ruby On Rails Tutorial and just wrapped things up last weekend.  As someone who has worked in many different programming languages over the years, I found this to be a great survey on how Rails can be used to build functional web apps.

The majority of the book is spent methodically building out a basic Twitter clone.  I like the way that concepts like MVC and TDD were introduced, but I question whether I might have been a bit lost if I wasn’t already familiar with them.

The writing style was very easy to follow, and I liked the predictable flow of Write Tests, Code, Test, Repeat.  I do wish that whomever curates the Kindle version would eliminate all of the “Click here to view code image” links, but that was only a minor distraction.

The author rightly states in the intro that a basic understanding of HTML and CSS is needed.  If you’re starting without that baseline, a lot of the sample app is going to seem like magic, and relying on magic is a bad way to code.  As it stands I feel like a lot of the Ruby code in the book was a bit on the mystical side, so I’m probably going to find a good Ruby book for my next technical read.  If you want to take a look at where my sample ended up, you can see the code at: https:/github.com/hallihan/rails_tutorial and I’ve got the sample running on Heroku at http://yamf.net.

Overall I’d say that if you’re familiar with other web frameworks like ASP/ASP.Net, PHP, JSP, etc. this is a great book to introduce the Rails framework.  I’d probably recommend diving into a Ruby book first if you have the interest.

The book is available from Amazon

Waking me up to complain about a low battery is terrible UX

If you design a product that might wake me up in the middle of the night, you should meet the following bar: I, or someone I love, must be in danger.  Not a hypothetical “If the power goes out and if something in the house is still managing to produce CO without power” type of danger, but something more actual and imminent.

Smoke and CO detectors seem to have been designed with a severe disregard for how the customer will react to the various interaction points other than a true emergency.  I can remember several times in my adult life when a chirping detector has induced me to get out a ladder in the middle of the night and climb up to check on various possible sources of the chirp, all in a semi-alert state.

Last night, the culprit was a CO detector that happened to be plugged in to the wall in our master bedroom, perhaps about 3 meters from where I sleep.  The acoustics of the alert sound on this device seem to have been designed to make it echo and reverberate around the house, which is great for an a alarm, but again is horrible for a low battery warning.  In my efforts to find the noise that only repeated every minute or two I got out two different ladders, stood on the ladder near the upstairs smoke alarm, then the downstairs one, then climbed into the attic to check that one, then stood in the room listening for the chirp again, then up to the attic to see if maybe there was another alarm up there that I didn’t know about.  Thankfully my wife happened to look down at the right moment and correlate a chirp with this CO detector plugged in to the wall.

I know that I should have probably replaced the battery at some point, but honestly I had totally forgotten about this particular detector.  It’s one of 3 CO detectors in our house, and I’m pretty sure that it’s been 3 or 4 years since the battery was changed because it runs off house power and the battery is just for power failures.  The end result of this particular warning was that the device was unplugged and batteries removed so that we could get back to sleep.

This morning as I tried to get back to sleep I was wondering how many middle-of-the-night ladder injuries are attributable to low-battery chirps.  I’m guessing that the low battery behavior is probably design-by-regulation and that manufacturers like First Alert don’t have a lot of latitude to make this better, but I see that Nest Protect is trying to solve the UX gap, although at quite a premium on price.

Recovering from a lost SSH Key File on Amazon EC2 Linux Instance

Recently I went to log in to an EC2 instance and I realized that I could no longer find the private key file that I needed to connect via SSH.  I looked around the Internet for recovery instructions and found some complicated pointers regarding creating a snapshot and then an AMI then using that to create a new instance.  This seemed like overkill, and I couldn’t get it to work when I tried it anyways (The new instance always stalled at 1of 2 Status Checks and I couldn’t connect).

On a whim, I decided that the key file had to be somewhere on the image and that I could probably find and replace it.  I was successful so I thought I would outline the steps here for others.

Warning, the following comes with a “Worked on my machine” guarantee, which basically means that you shouldn’t try this unless you understand what’s going on.

For the sake of keeping things straight, I’ll refer to the instance with the lost key as Instance A.

  1. Create a new instance with the same Linux build as the instance you need to access.  Create a new key pair.  Remember to actually save and back up the private key this time.  I’ll call this new instance “Instance B”.
  2. Shutdown Instance A.
  3. Detach the root volume from Instance A.  Note where it was attached, usually /dev/sda1
  4. Attach this volume on Instance B, note the mount point.  It will probably be something like /dev/sdf. Some Linux distros will actually use /dev/xvdf instead of sdf.

  5. Connect via ssh to Instance B.
  6. Run: sudo mount /dev/xvdf /mnt (using the device that was noted when you attached)
  7. cd to ‘/mnt/home/ec2-user/.ssh’  (this will be ‘/mnt/home/ubunto/.ssh’ on Ubuntu builds, may be different for other distros)
  8. Run: ‘sudo mv ./authorized_keys ./authorized_keys.old’
  9. Run: ‘sudo cp ~/.ssh/authorized_keys .’ (<- This is the magic.  We’re copying the Public Key from the .ssh dir of the currently logged in user to the correct location on the mounted volume.)
  10. ‘cd’ back to home
  11. Run: ‘sudo umount /mnt’
  12. Detach the volume from Instance B and then attach back to Instance A as /dev/sda1 (or other original mount point as noted in step 3).
  13. Now restart Instance A and you should be able to connect with SSH.
  14. After you’ve successfully connected back to Instance A, you can Terminate Instance B.

Note:
Running through sudo and doing chown and chgrp may not be necessary if your UID’s and GID’s match between Instance A and Instance B.