One year with the Truly Ergonomic keyboard

In late 2013 I started thinking about switching to an ergonomic keyboard. I did not have wrist pain or other health issues – although preventing them is a good reason as well, I mainly wanted to improve my productivity.

The key layouts on typical keyboards are vastly suboptimal: the alphanumeric keys are staggered (a carryover from mechanical typewriters), and important keys (modifiers, Backspace, Return, arrow keys) are too hard to reach. Although this is often worked around in software (e.g. hjkl movement keys in vi, Colemak remapping Caps Lock as Backspace), it is much more effective to fix the keyboard instead.

I was looking at three options:

I ruled out TypeMatrix due to keylock (I think lack of NKRO is not acceptable for a high-end keyboard), and the Kinesis struck me as overly bulky – I wanted something I could take with my laptop (the TECK’s hand rest is removable).

Truly Ergonomic’s customization choices basically boil down to whether you want one big button (Model 227) or two small ones (Model 229) on the bottom corners of the keyboard, whether you want blue, brown or clear Cherry MX switches, and whether you want blank or QWERTY keycaps. My selection was Model 229 with brown switches and blank keycaps (using Dvorak for a decade, and I planned to reprogram the keyboard anyway). I ordered it on 2014-02-02 from The Keyboard Company and received it on 2014-02-06.

Model 229 TECK with blank caps.

I’m writing this on 2015-05-25, so it’s been about 16 months. Here are my notes so far: Continue reading

The amazing template that does nothing

I’ve recently started using a new pattern more often in new D code, namely use of the Identity template.

The Identity template (available in std.traits, although undocumented), is declared as follows:

alias Identity(alias X) = X;

This is a short-form of a template declaration, and is synonymous with the explicit form:

template Identity(alias X)
    alias Identity = X;

As this is an eponymous template, the instantiation is replaced with X (the only template parameter). Thus, Identity!(anything) is aliased away to anything.

So, what use is a template which does nothing?

I’ve found a number of interesting uses for it: Continue reading

Very Sleepy CS is now Very Sleepy

I am delighted to announce that my fork of the Very Sleepy profiler, Very Sleepy CS, has been blessed as the official repository by Richard Mitton (Very Sleepy maintainer). As such, the Very Sleepy homepage has been updated to point to the GitHub repository and list the forked releases since Richard’s last release. You can also read Richard’s announcement on his blog.

I have already reverted the name change in the source code, though the currently-newest release (v0.90) is still labeled with the old name. The next release will call itself Very Sleepy again.


ae.utils.funopt is a std.getopt enhancer:

import std.stdio, ae.utils.funopt;

int run(bool verbose, string input, string output)
	// ...
	return 0;

int main(string[] args)
		return funopt!run(args);
	catch (Exception e)
		stderr.writeln("Error: ", e.msg);
		return 1;

Running program --verbose input.txt output.txt will cause run to be called with the appropriate arguments. Continue reading

Splicing git repositories

Some projects eventually get split up into multiple source repositories for whatever reason. Sometimes, it is useful however to present the project as a single repository – it’s more difficult to examine a project’s development history when it is scattered among several repositories. Specifically, git bisect will not be very helpful if there is strong inter-dependency between the repositories, such as with the reference D programming language implementation. Or you may just not like the layout, which pushes you into using a complicated build process you may not want to use, which was the case for me with the new DerelictOrg repositories. Continue reading

Functional image processing in D

I’ve recently completed an overhaul of the graphics package of my D library. The goals for the overhaul were inspired by D’s std.algorithm and std.range modules:

  • Present everything as small, composable components
  • Avoid implicit copying and prefer lazy evaluation
  • Use templates for efficient code

From its first iteration, all components of the image processing package were templated by the color type. This is not a conventional way to implement graphics libraries – most libraries abstract away the exact color type the image uses behind an OOP interface, or they simply convert all images to a single in-memory pixel format. However, for most cases, this is wasteful and inefficient – usually, the programmer already knows the exact format that an image will be in, with notable exceptions being applications in which the image data comes from user input (e.g. image editors). Instead, this library declares all image types as templates, with the type indicating the image’s color being a template parameter.

I’m rather pleased with the result of this overhaul, so I’d like to share some highlights in this article. Continue reading

Low-overhead components

My personal dream of an ideal programming language is one that allows defining flexible, configurable components that can be coupled together with very little overhead, producing in the end code that, if reverse-engineered, would appear to be hand-written and optimized for the specific task at hand. Preconfigured component configurations / presets would be available for common use, favoring safety and feature-completeness, but for performance-critical cases, the programmer could break them down and strip out unneeded features to reduce overhead, or customize by injecting their own components into the mix. Continue reading