Chording Keyers

I’m considering buying a chording keyer. A keyer is a 1-handed text input device. Chording means that you can hit more than 1 key at a time. I’ve been interested in these for a long time actually. They’ve been popular in the wearable computing (“cyborg”) field, but never caught on anywhere else. I’ve always thought that 1-handed chording keyer would be a great input device to use with a cell phone. It’d be even better with a heads-up display like the Google Glass.

There are quite a few chording keyers available. It doesn’t appear that any will meet exactly what I’m really looking for, but I might take the leap anyway. It should be a hand-held device. I really want a Bluetooth device, so I can use it with a computer, phone, or tablet. Below are the ones I’m considering.


The Twiddler has been around quite a while, as probably the main commercially available keyer for wearable computing. There was a time that it was unavailable, but there’s a new version available from HandyKey now. It’s $200 ($220 Canadian), and comes in only USB.

The Twiddler looks like a small TV remote. The current version (2.1) has 4 thumb keys, a thumb joystick (for mouse), and 12 small finger keys. It has good community support, including an alternate chord layout.

In10did Decatxt

In10did has been trying to bring out a few variations of their devices. The Decatxt looks like a pack of cigarettes, with 8 keys on the front and 2 thumb keys. It can be used with 1 or 2 hands. All letters can be typed with 1 finger or 1 thumb and 1 finger.

The Decatxt has USB and Bluetooth models, but I’m unable to find pricing or a way to buy one. It looks like there have been no updates for over a year, so I’m concerned that this is going to be vaporware.


The CyKey is based on the Microwriter, which goes back to the early 1980s. The Microwriter was a desktop-based device, but it looks like the CyKey might be able to be used as a hand-held device. It has 9 buttons on the face, arranged in 3 groups of 3 buttons.

The CyKey is $125 (£75) and works over InfraRed connected to USB. A Bluetooth model is supposedly in the works.


The EkaPad is like a cross between the Decatxt and the Twiddler. It has 12 buttons on the face, but no thumb keys. It’s got a nice well-thought-out design that looks quite ergonomic.

The EkaPad is $150, available in USB only. A desktop holder is available to hold it upright, or it can be used hand-held.


The FrogPad is meant to be used on a flat surface only. It looks kind of like a third of a laptop keyboard. It’s got 15 regular keys and 5 modifier keys. Only 1 key and 1 modifier can be chorded. Right-handed and left-handed models are available, with USB connectivity.

The FrogPad2 was recently announced, replacing the original FrogPad. It switches to standard desktop-style keys, and adds some more keys along the top. It supports USB On-the-Go and Bluetooth. I’m not really interested in this model with its regular keys, but it doesn’t appear that the original version is being made any longer. The new models are priced at $200. I believe the old models were $150.


The Chordite looks the most promising, but it’s only a concept with some DIY prototypes. It’s a hand-held device, with 2 buttons on each of the 4 fingers — one activated by the distal phalanx and the other by the middle phalanx. This initially sounds like it would be difficult to press 2 different buttons with 1 finger, but I think the way they’re positioned would make it actually work really well.

Septambic Keyer

The septambic keyer is another DIY concept, hand-built and used by wearable computing folks. It’s fitted to your palm, and you squeeze your fingers toward a fist to activate the buttons. There’s one button for each of the 4 fingers, and 3 for the thumb.

Clove 2

The Clove 2 is a Bluetooth-enabled glove with 5 buttons — 1 for each finger. It’s another do-it-yourself project.

Software Options

I found an interesting project called ASETNIOP that allows chording on a standard Qwerty keyboard. (Assuming the keyboard supports multi-key roll-over well enough. Most keyboards should work.) It’s got a really nice online interactive tutorial. You basically chord with the 8 home-row keys, plus the spacebar.

For Android, a program called GKOS for Android uses multi-touch with 1 or 2 button presses. The buttons are different sizes, depending on their frequency. I like this concept, but I don’t think the implementation is quite ready for production.

I also found an app for iOS called Nintype that is a combination between Swype and a chording keyer.


I think I’m going to try the Twiddler. If I find the concept to be a good one, hopefully I’ll build myself a Chordite (or have someone build one for me).

I’m also going to play with implementing some of the ideas from ASETNIOP, using KeyRemap4MacBook.

Includable ActiveRecord

I created a Ruby gem recently, called includable-activerecord. It’s pretty small, but I thought I might explain why I created it, and discuss its implementation.

Classical Inheritance

When you use ActiveRecord, you normally include it in your model like this:

class User < ActiveRecord::Base
  # ...

Your User class is inheriting from the ActiveRecord::Base class. This is class-based inheritance, also called “classical” inheritance. (That’s “classical” as in “class”, not as a synonym for “traditional”.) Class-based inheritance represents an “is-a” relationship. So we’re saying that a user is an ActiveRecord base. Another way to say this is that User is a subclass of ActiveRecord::Base.

There are a few problems with this. First, what is a “base”? The name was chosen because it’s a base class. But just like we don’t give factory classes names like UserFactory (at least not in Ruby), we shouldn’t name base classes Base.

I suppose that we’re trying to say that this is an ActiveRecord model. That sounds fine at first glance — this is our model for users. But what if we also want to say that a user is a person? Ruby doesn’t allow inheriting from multiple classes. Now we have to choose whether to inherit from ActiveRecord::Base or Person. Person makes more sense, because it fills the “is-a” rule better. Class inheritance is intended for a hierarchical “is-a” relationship, such as “a user is a person”, or “a circle is a shape”. But since ActiveRecord::Base is a base class, we have to use it as our base class.

We could work around this problem by subclassing Person from ActiveRecord::Base and then subclassing User from Person. That’s fine if Person is also a model that we store in the database. But if that’s not the case, then we have a problem.


Ruby provides another way of implementing inheritance — mixins. We often don’t think of this as an inheritance model, but it really is. When we include a module, that module gets added to the class’s ancestor chain. We can mix in as many modules as we want.

Mixins indicate more of an “acts like” relationship than an “is-a” relationship. It’s for shared behavior between classes that don’t have a hierarchical relationship. For example, when we mix in the Enumerable module, we’re saying that we want our class to act like other classes that include Enumerable. That sounds more like what we want ActiveRecord to be. We want our user model to behave like other ActiveRecord models, in the way that they can persist to a database.

But ActiveRecord doesn’t support that. Almost all the other Ruby ORMs do; as we’ve shown above, this is for good reasons.


So I decided to see if I could implement the equivalent of the ActiveRecord::Base class as a module that could be mixed into model classes. I decided to call my mixin module ActiveRecord::Model, because classes that mix it in will behave as ActiveRecord models.

It turns out that ActiveRecord::Base is a pretty complex class. It includes and extends a lot of other modules. Luckily, as of ActiveRecord 4.0, that’s all the code it includes.

The module only defines a single class method, included. This is one of Ruby’s many hook methods. It gets called when the module in question gets included in another module, and receives that other model as its argument. All we need to have this method do is to include everything that ActiveRecord::Base includes, and extend everything that ActiveRecord::Base extends. Ruby provides a method that’s defined on all classes, called included_modules, which we can use to get the list of everything that’s included in ActiveRecord::Base. Unfortunately, there’s no equivalent list of extended_modules. But a quick search on Stack Overflow found an implementation of extended_modules that we could use.

So with a bit of magic (i.e. hooks and meta-programming), we can get the lists of constituent modules from the ActiveRecord::Base class, and include them in our ActiveRecord::Model module.

So with all that, we can now include the includable-activerecord gem and mix it in, with all the advantages that provides:

class User
  include ActiveRecord::Model
  # ...

It was exciting to be able to make this work. Since I wrote it as a proof of concept, I haven’t written any tests yet. But it seems to be working just fine. The main thing I really need to look into is making sure that plugins that extend ActiveRecord::Base from their own code will still work. I’m pretty sure this will work out of the box, because the ActiveRecord::Model.included doesn’t run until the model class is loaded, and that happens after those plugins have initialized themselves.


I facilitated our team retrospective this morning. I felt like we made a little forward progress, but not as much as I would have liked. But it really brought one thing to the forefront of my thoughts today — empathy gained through communication.

We have a pretty large team by Agile standards — we had 20 people in our retro: 16 developers, 3 QA folks, and 1 manager. Out of those, only about 5 or 6 speak up regularly. I recently sent out a survey to the team, trying to get feedback on how we could improve our retros. A couple of the questions tried to get a feel for why people aren’t speaking up more. Only about half the people responded, and the answers didn’t really answer my question as well as I had hoped.

So on Amos‘s suggestion, we did the Safety Check exercise. We got a good set of answers to why people don’t feel safe. About half of the answers were about the fear of looking stupid in front of other people. About half of those mentioned the manager — they’re worried they might get in trouble for what they say. We talked some about fear and how it’s more often than not misplaced. And that the worst consequences are usually not as bad as you might think. But then we got to the crux of the problem — there’s not enough trust amongst the team, and especially between the team members and the manager.

About half of our team is new (within the past 6 months) — including the manager. While the developers have made some good progress building trust amongst each other, we haven’t had as much time with the manager to build trust between him and the rest of the team. So the lack of trust isn’t at all surprising.

Honestly, I already knew we had trust issues, and wanted to address them, but needed a way to lead the team to that same realization. With this exercise driving out the issue, we were then able to have a conversation about trust. The conversation was pretty good. We got more voices to contribute than probably any other topic we’d previously covered. (I was disappointed that the manager kept quiet though. I later found that he was trying to mitigate people’s fears by keeping quiet, but I urged him to contribute more in the future.)

But one point really stood out in my mind — a point of view that I hadn’t previously thought much about. Lauren, one of our QA analysts, pointed out that most human communication is non-verbal. We give tons of cues via body language, facial expressions, eye contact, tone of voice, even posture. I don’t recall if Lauren said it explicitly, but she pointed out that these cues build empathy between the speakers. She encouraged us to use more voice chat and video chat, as opposed to IRC text chat, because it would create more empathy between the people communicating, which would lead to more trust.

I spent most of the rest of the day talking to people on the phone or via Google Hangouts voice. And every single time, I consciously noticed that I was gaining empathy for the person I was speaking with. I assume (and hope) that that’s working both ways. I suppose that it’s always been happening, but I never really noticed it.

I’ve heard a lot of talk about empathy among Agile practitioners lately. It’s been mentioned on the Ruby Rogues podcast, and Angela Harms has been preaching it for years. I already understood how important it is. But until today, I didn’t really feel it happening.

So if you’re looking to build trust with someone, spend some time talking with them. Preferably in person, but if that’s not possible, seriously consider video or voice modes of communication, instead of sending an email or an instant message.


What I Want in a Blog Engine

I’m considering moving away from WordPress, for a couple reasons:

  • Security. There have been several vulnerabilities over the past few years, and I’ve never really had a high level of confidence that it’s secure. In addition, I now find the whole PHP model — every web app running as a single user, instead of leveraging UNIX permissions — to be broken.
  • Speed. I started to realize a couple years ago that a blog engine should generate static pages. The static pages should be updated whenever new content is added. There’s really no reason to re-generate the page every time someone wants to read it. At the very least, Server-Side Includes (SSI) or Edge-Side Includes (ESI) should be used.

Now that I’m starting to actually blog consistently, it makes sense to change. But before I move to something different, I want to be sure that I find all the features that I need. This post is my thought process about what I want.


  • Self hosted. I like to run my own servers. Partly so I can keep full control, and partly because I enjoy doing some system admin stuff (as long as it doesn’t take too much time).
  • Generation of static pages. Almost everything should be a static page by the time a user requests a page. Obviously, submitting comments would hit a dynamic page, and comment approval would likely be done through a dynamic part of the site. But publishing a blog post or comments should generate static files to be served by Apache or nginx.
  • Categories (or maybe tags). I want readers to be able to find other things that I’ve written that might interest them. A list of categories in a sidebar would help them find what interests them.
  • Site map. Especially an XML sitemap, so Google can index better. I also like the idea of readers being able to see everything in one place.
  • Archives. This is another way of letting readers see everything I’ve written, organized by publication date.
  • RSS and/or Atom. I want readers to be able to subscribe to my blog.
  • Media. I don’t think I necessarily need a media manager, just a simple way to add pictures to blog posts.
  • Comments. I want to allow comments, but I don’t want to use anything like Disqus. I want the comments to be in my own database, so they won’t disappear. I also dislike requiring JavaScript just to see comments. And I’ve worked at places where Disqus wouldn’t work, due to web proxy servers. Comments should be moderated by the site admin, editor, or author. Readers should not have to log in to post a comment, but it would be nice to allow users to log into Twitter or some other social network to provide their info.
  • Pingbacks and Tweetbacks. I’d like to be able to see who’s referring to my articles.

Nice to Have

  • Free. I almost consider this to be a requirement, but I’d be willing to entertain a 1-time payment for something that meets my needs really well. I need to try to counteract my DIY-at-all-non-monetary-costs mentality.
  • Open Source. I think Open Source is likely to provide a more useful product, especially in this space. An Open Source option is more likely to improve over time.
  • Not PHP. I’ve got several problems with PHP. First, the whole PHP model of running in the same context as Apache (or nginx) breaks UNIX conventions. A security issue in a PHP program exposes more than just the program itself — it exposes Apache and every other PHP program. Under the UNIX model, each program runs in a different user context, isolating bugs to that program only. PHP is also a “hacky” language. PHP programmers tend to not be as rigorous (in many ways), leading to more vulnerabilities. Finally, the PHP language itself has had several misfeatures that have lead to security issues — much more than Ruby or Java.
  • Not MySQL. I’d like to be able to remove MySQL from my servers. PostgreSQL would be much preferred. Storing everything in git would be fine too — maybe even preferred. I’d even be fine with MongoDB or some other simple NoSQL database.
  • Admin console. I can’t imagine approving comments without this, but I’m not closed to that possibility.
  • Edit history. I want to be able to update posts, but see what the previous versions looked like. (Not sure if I care whether the public can or cannot see the various revisions.)
  • WYSIWYG. I’d be willing to settle for Markdown. In fact, I’d prefer (extended) Markdown as the canonical form behind the WYSIWYG.
  • Code highlighting. A lot of my blog posts (will) include code in various languages. I’d like the blogging software to be able to handle that well. Syntax highlighting would be great. Any other related features would also be nice.
  • Through-the-web editing. I’d like to be able to edit a page from any device from anywhere that has Internet access.
  • Reader-submitted edits. This is probably going to be the hardest thing to find, but I’d like a really easy way for readers to let me know of typos and such by simply submitting a fix for them. The author or editor of the post would have to approve the edits, obviously.
  • Import from WordPress. I don’t have a ton of content in WordPress, or else this would probably be a more firm requirement.
  • Community. Community helps software thrive, adding improvements and ensuring security.
  • Plugins. It would be nice for the blog engine to be extensible.
  • Unpublished drafts and previews. I’d really like to be able to see by blog posts before I release them to the world.
  • CMS abilities. I’d really like the ability to edit non-blog web pages the same way as blog entries.
  • Themes. It would be nice to have decently looking themes, so I could have other people help me make the site look nice.
  • Posting my tweets in a sidebar area. I’d be OK with this being done in client-side JavaScript. I’d also be OK with periodic polling of my Twitter feed, and updating the static content when appropriate.


I’ve been playing with Jekyll lately, using it to generate a simple static site that can be updated easily. It’s pretty nice, and pretty easy to use. Something based on Jekyll would work well. The trickiest part will be figuring out how to manage comments. Or maybe I’ll just have to learn to live more minimally.

Octopress is the obvious candidate. It fits most of my needs and wants. Most likely I’ll write my own commenting engine and add it to my Octopress template.

The only other candidate that I’ve found is Ghost. It’s written in JavaScript and runs on Node. I don’t find Node to be that compelling, but the templates look great, and it’s designed for coding blogs.

I’ll probably take a quick look at Droplets, too. It’s written in PHP, but seems to fit my other requirements.

Unfortunately, that seems to be all there is in this space. Maybe I need to investigate more. Or maybe Octopress just has the static blog generation marked cornered. Either way, I’ll probably change my blogging software in the next month or two. Wish me luck!