花花花 SuperLaserNino 花花花

Trying to stop my glasses sliding down my face

03 May 2024

For some reason, my glasses really don’t like staying on my face. Since this is especially bad when I’m sweating, I wanted to figure out a way to improve the situation before the summer. It looks like wrapping a hair tie around each temple, just behind the place that rests on the ear, might help keep the glasses in place a bit more.

So far this seems to work for me, and it doesn’t feel like it adds too much pressure on my head. One drawback is that now my glasses sometimes come off when I take off my headphones, but that is probably overall still better than constantly fighting the glasses.

A pair of glasses with cream-colored plastic frames sitting on a white surface. Each temple has a black hair tie wrapped around it, just behind the part where it bends.

Mostly objective things to appreciate about Python

Created: 14 Dec 2023

Modified: 27 Mar 2024

I really don’t like Python1, but I have to use it for work, and so I have set myself the goal of learning to appreciate it. This is a list of mostly objective claims about Python that I appreciate. Submissions are welcome, but I’ll only add them if I agree that they’re basically objectively true.

  • Python starts up in less than 0.1s, so it can be used for short scripts.
  • I guess it is more readable than APL or Cobol.
  • You can FFI into better other languages relatively easily.
  • It has a more complete standard library than OCaml or C.
  • Package management is easier than it used to be, I think.
  • It has lots of libraries.
  • Some apps (e.g., Blender) use Python for scripting, so knowing Python will help there.
  • It has official Qt bindings, so should be one of the easier language-choices for making little GUIs.
  • Type annotations + Pyright is better than nothing.
  • This is not really an objective thing, but I appreciate the fact that the culture has agreed to import whole namespaces (e.g. import pandas as pd, import numpy as np), so you can always tell where a function or class is coming from (e.g. pd.DataFrame, etc). This also probably helps avoid using “private” APIs: if the top of my file says from whatever import _hello, a thousand lines further down, it won’t look out of place to call _hello() (“maybe it’s just a private helper function defined in this file!”). But if you do import whatever, you’ll have to write whatever._hello(), which will stick out like a marginally sore thumb.
  • zip is a built-in function.

I’ll add more points as I think of them.

  1. I have an unfinished post titled “Unhinged rant about the Python community” explaining some of my feelings. Maybe one day I’ll publish that too. 

Words that German does have and English does not

04 Sep 2023

You’ve heard me complain about how, while people will tell you that “the Germans have a word for that”, German actually has too few words, and one thing that makes English so beautiful is its rich vocabulary.

(If you haven’t heard me rant about it, all of those “the Germans have a word for that” words are just compound words that work just as well in English – German just makes things confusing by leaving out the spaces or hyphens. (E.g., “Schadenfreude” is just “damage-joy”. It sounds weird in English, but that’s just because it’s not established as a common phrase.) This compound-word game can be a lot of fun at parties, but it doesn’t help you when you realize German doesn’t really have different words for “proof” and “evidence”.)

So, after two paragraphs of preamble, here’s the list (at the time of writing, this list has only two items, but I may extend it over the years):

  1. “schmatzen” (verb). This word refers either to the act of chewing with your mouth open, or mouth sounds that sound like it. E.g., your cat might pounce on your chest and wake you up with schmatz sounds, even though he’s not actually eating at the time.
  2. “lutschen” (verb). To lick or suck on something that is predominantly or entirely in one’s mouth, e.g. a bon-bon, lollipop, or dick.

Modifier keys are named all wrong

17 Jan 2020

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

03 Sep 2019

Fun things I discovered about my muscle memory.

Continue reading →

Are rails partials actually slow?

04 Mar 2018

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!

Continue reading →

DPI-dependent CSS in Atom and everywhere else too

04 Dec 2017

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

08 Oct 2017

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 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!

Big numbers, small numbers

Created: 15 Mar 2017

Modified: 15 Mar 2017

You don’t want things to be complicated. I get it. I am here to help. Don’t worry, it’s all going to be over soon.

Continue reading →

Willpower day

08 Mar 2017


I noticed I wasn’t happy with the way I spend my time. Over the last year or so I learned to structure my work habits such that I need the least amount of willpower possible to get myself to work. I tried hard to get myself to do things without requiring willpower and, in the process, built somewhat of an aversion to do anything that seemed like it might require effort. For the most part, this was good: I learned to notice moments when I just didn’t have the mental capacity to do work, and so learned not to judge myself for sometimes not working and instead looking at comics on the internet.

Continue reading →