Modifier keys are named all wrong

17 January 2020

333 words

The option key in macOS should be called alt like on Windows, because it is used to type alternative characters, or to run alternative commands when used in conjunction with the command key. On Windows, the alt key should be called command because you use it to move focus to the menus to execute commands. The alt gr key on Windows should become the alt key because that’s what you use to type alternative characters. The shift key should be called caps because nobody has used a typewriter in decades, and nothing is being shifted anymore. (The name isn’t perfect because you also use that key to type alternative symbols on the number row, but we already have an alt key. Maybe we could use our new alt key to type all the symbols from the number row and the number keys can produce old-style figures without caps and lining figures with – though that would require changes to unicode, so that might be out of scope for this project.) The caps lock key should be dropped entirely and replaced with an escape key that functions as ctrl or command when held down, according to user preferences. On keyboards that have one, the fn key should be renamed to something like alt-ctrl because it’s usually like a ctrl or command key, but it does different things. Maybe special would work, as a nod to the old “Special” menu in Classic Mac OS.

And while we’re renaming keys, the tab key should be renamed to shift because we make tables using the “Insert table” command, not by pressing the tab key. The tab key is used to shift text to the right, or to shift focus to the next input element. (On the other hand, ctrl + tab is used to navigate between browser tabs, but that’s one bit of elegance we can probably do without. (You can still say you’re “shifting” focus to the next browser tab, so it all works out in the end.))

Muscle memory

3 September 2019

542 words

Fun things I discovered about my muscle memory.

1. Other people’s computers

For the last 5–10 years, I’ve been using the Dvorak keyboard layout for typing.¹ At this point, I’m pretty fast and usually don’t make a ton of mistakes. Since I almost never² use a QWERTY layout,³ I’ve gotten really slow with it. So, when I’m helping a coworker with a problem, I’ll sometimes switch their keyboard to a Dvorak layout and try to type normally. But my hands will often think, this keyboard feels different; it must be another person’s keyboard; other people use the QWERTY layout, and so I keep typing words as though I were using a QWERTY layout, resulting in a big jumble of random letters. Or maybe it’s not necessarily that the keyboard feels different, and more that I know I’m using another person’s computer. Because when I plug a new keyboard into my own computer, I can usually use Dvorak without a problem.

2. Proprioception⁴

I have two mechanical keyboards. At work, I use a keyboard with an ergonomic split-layout. At home, I use a tiny keyboard with slightly more traditional key layout. I can type reasonably fast on either of them. However, when I bring my home-keyboard into the office, my hands will just feel a mechanical keyboard, and since I am in the office, they assume I’m using the split keyboard, and keep trying to use it as such. When I tell my hands to insert a new line, suddenly my thumb will press the “Upper layer” button, because that’s where the enter key is on the split keyboard. This does not happen when I use the tiny keyboard at home, so, somehow, my hands can figure out whether I’m in the office or not.

Are rails partials actually slow?

4 March 2018

271 words

At my previous job, we were told not to use partials to clean up our view code, because each rendering of a partial would add around 10ms to the overall response time. After I was told this I did a quick test in my dev environment, but I’d never actually tested the claim on production … until today!

The setup

I created a new rails project and generated a scaffold I called things. On the index page, underneath the auto-generated table, I put the following:

<% if params[:manypartials].present? %>
  <p>Many partials:</p>
  <% 1000.times do %>
    <%= render "simplepartial", iterations: 1 %>
  <% end %>
<% else %>
  <p>One big partial:</p>
  <%= render "simplepartial", iterations: 1000 %>
<% end %>

I then created the partial simplepartial and added this code:

<% iterations.times do %>
  <p>This is a simple partial. Hello from the partial!</p>
<% end %>

Results

I launched the dev server with rails s and the production server with rails s -e production. I ran

time curl "http://0.0.0.0:3000/things?manypartials=true" > /dev/null

and

time curl "http://0.0.0.0:3000/things" > /dev/null

to make the requests. (The pipe to /dev/null is to reduce the time spent printing stuff to the terminal.)

So it seems that rendering 1000 partials will cause around 100–200ms of extra rendering time. That’s certainly not great, but it may not be too high a price to pay for HTML templates not growing to thousands of lines.

DPI-dependent CSS in Atom and everywhere else too

4 December 2017

139 words

When programming on low-resolution screens, I like to use 10pt Monaco with antialiasing turned off. But when switching to my MacBook’s retina display, I want antialiasing turned back on. Until now, I would manually comment/uncomment some CSS in Atom’s styles.less file to change this.

Turns out, you can define CSS rules based on the current screen resolution. By adding the following to styles.less, Atom automatically switches the font and antialiasing settings as soon as you move the window from one screen to the other:

atom-text-editor {
  @media (-webkit-max-device-pixel-ratio: 1), (max-resolution: 150dpi) {
    .line {
      -webkit-font-smoothing: none;
      font-family: Monaco;
      font-size: 10;
      transform: translateX(1px);
      font-style: normal !important;
      * {
        font-style: normal !important;
      }
    }
  }
}

The transform line is there because Atom will sometimes cut off the first column of pixels when antialiasing is turned off.

Smooth cursor motion in Atom

8 October 2017

Modified: 25 November 2024

78 words

I’m currently trying out Atom as the main tool for my computer job and I wanted to make it more fun, so I added some CSS to make the cursor move smoothly and give the text-selection rounded corners. To try it yourself, click on Stylesheet in the Atom menu and paste this code:

atom-text-editor .cursor {
  transition: all 80ms;
}

atom-text-editor .selection {
  border-radius: 4px;
  transition: all 20ms;
}

Now everything is nice and smooth. Yay!