I was recently made aware of a group buy for a “Southpaw Full-Size” keyboard that has its numeric keypad section moved to the left-side of the keyboard:

As a southpaw myself, I… just don’t get it.

I mean, sure, as a keyboard nerd, I get it – it’s a cool looking keyboard, it’s customized to someone’s needs, and, in the mechanical keyboard community, more form-factors are always welcome.

I just don’t get it that it’s marketed at left-handed people – or at least marketed as a “left-handed” keyboard. If anything, it should actually get marketed at right-handed people. See, most right-handed people prefer “tenkeyless” designs, since it keeps their mouse (which is on the right of the keyboard) closer to the the main part of the keyboard. This means they don’t have to move their right hand too much between typing and moving the cursor.

Now, left-handed people don’t get this problem – if we consider the proper left-handed people who put their mouse on the left instead of living a lie¹. So getting a keyboard that puts the numeric keypad on the left does nothing much besides bringing a right-handed people problem to left-handed people! For
right-handed people who are conflicted about standalone numeric keypads, however, this might be a good option to consider.

Either way, if you’re interested in this so-called “left-handed” keyboard, for whatever reason, head over to the group buy page, you still have a week or so to order.

This article on urban development by Devon Zuegel is a good primer on why prioritizing walkability over vehicle traffic is important in urban development. It reminded me how I really appreciate that downtown Vancouver has a wonderful waterfront made of beaches, bike lanes, and an almost endless promenade¹, while, say, downtown Seattle has a highway instead.

We could have had highways instead too, back in the late 1960s when the city had plans for several of them going through downtown. The plans included the partial destruction of the Vancouverite Chinatown, so of course the local residents revolted. Less than two decades since the repeal of the Chinese Exclusion Act, these Chinese immigrants were actually joined by many other residents elsewhere around the city and, together, managed to cancel the project entirely…. although the project’s cancellation may have also been greatly helped by the federal government’s refusal to invest any money in it. But hey, either way, I’m happy.

Devon’s article also had this interesting video-game-related tidbit:

Fun fact: SimCity was forced to pretend that all parking lots were underground, because the game would be “really boring if it was proportional in terms of parking lots”. SimCity’s lead designer explained, “I was blown away by how much more space was parking lot rather than actual store. That was kind of a problem, because we were originally just going to model real cities … We had to do the best we could do and still make the game look attractive.”

News of movie or TV adaptations come and go all the time but today my io9 RSS
feed brought me a trio of titles that are directly related to my tastes:

• News that the Vampire Chronicles’s TV show seems to be coming for real
  via Hulu (I’m just sad Bryan Fuller isn’t involved anymore but
  apparently he’s good friends with the showrunner so it might still turn out
  pretty).

• Netflix announcing that they’re adapting a whole bunch of Millarverse
  titles (more here) in various formats.

• Amazon surprisingly picking up Tales from the Loop, the
  art-book-turned-RPG (more here), as a TV show.

Not only are those 3 opportunities for me to say things like “I liked it before
it was cool” and “the original material is better”, but it’s also 3 things
that will bring some additional cash (hopefully) to the original authors whose
work I enjoyed.

These days, adaptations can often bring, at best, a lot of geek backlash, but
I find that even if I don’t like the adaptation, I’m happy that it’s bringing
attention to the original material, and money to the original authors. It’s
almost always good news in my book, except for the uncommon case where those
original authors get fucked for some reason.

I recently came across Josef Sipek’s series of articles on setting up
a “modern Mercurial”. In the first post, he realizes that he was missing
out on a lot of the new features that had been added to our beloved hg
along the years, due to the maintainers’ policy of not changing the default CLI
behaviour.

I realized I had the opposite problem – my .hgrc is a loose collection of
snippets I gathered from all around the web, at various times, and as such it
has accumulated several layers of Mercurial history.

Extensions

The main thing to clean up was my list of extensions. I had 14 built-in
extensions enabled, several of which had been deprecated in favour of something
better, or incorporated in the core. Now I’m down to 8:

• color: self-explanatory… make it pretty.

• extdiff: lets you specify an external diff/merge tool.

• histedit: lets you shoot yourself in the foot, a.k.a editing history with
  a workflow similar to git rebase --interactive.

• pager: lets you specify a custom “pager”, i.e. the thing that stops the
  text from scrolling off the top of the screen, and lets you “paginate”
  a command’s long output, like hg log. This mostly saves you from always
  having to do hg whatever | less or similar.

• purge: adds a command for removing all untracked files. Useful sometimes to
  clean up temp files, .orig files, etc.

• rebase: this is a basic operation for DVCSes so go figure why this isn’t
  enabled by default, especially now that we have phases.

• schemes: super useful for making aliases of hosting providers like Github,
  Bitbucket, and even your own private domains.

• shelve: I used to use that, along with MQ, to manage my works-in-progress,
  but now that I’m using evolve (see below), I don’t really use it anymore…
  still, I prefer to keep it around.

I also have a few third-party extensions:

• hg-git: required for mirroring Mercurial repositories to Github.

• hg-onsub: run a command on all sub-repositories. I don’t use sub-repositories
  much anymore, since I figured they are a pain to work with, but it’s still
  occasionally handy to batch-pull/update sub-repos.

• hg-allpaths: run hg pushall and push to all paths in one go.

• evolve: enables the changeset evolution features that are inactive by
  default in the Mercurial core. This is totally awesome, and quite mind-blowing
  sometimes.

• terse-status: when you have a directory with lots of untracked files and
  nothing else, make hg status show you just the directory… not 3 pages of
  untracked filenames.

Logging

Nothing fancy here, really… I’ve cloned Steve Losh’s templates a long
time ago and never looked back.

Multi-plaform

One cool thing that .hgrc files have is support for including other config
files that may or may not exist, and support for environment variable expansion.

My .hgrc is actually generated by my Dotfiles’ install
script, but it includes the “real” hgrc (which you can see
here). At the end, I can include further configuration files, like
a “local” file that could contain secret or temporary stuff, and a platform
specific configuration file:

# OS-specific settings
%include hgrc-${OS}

# Local settings (if any)
%include hgrc-local

That’s how I keep things working between Mac, Linux, and Windows between home
and work.

I recently read this post by Nicolas Douillet about CPU caches and performance. I recommend it! Apart from being a nice, fairly easily digestable recap of how CPUs work when it comes to memory, it also taught me the existence of something I totally didn’t know about until now: the Translation Lookaside
Buffer.

It’s used to cache recently used mappings between physical and virtual memory. I had no idea that this stuff was cached, and that it therefore could have some important effect on performance.