I've known for a long time that who am i prints info about the current user. Today I learned it's synonymous with who -m, though not synonymous with whoami.

I also learned that the two words after the who can be any non-option arguments. The Linux man page says:

If ARG1 ARG2 given, -m presumed: 'am i' or 'mom likes' are usual.

For example:

$ who -m
alee     ttys019  Jan 28 21:58 

$ who am i
alee     ttys019  Jan 28 21:58 

$ who mom likes
alee     ttys019  Jan 28 21:58 

$ who fred wilma
alee     ttys019  Jan 28 21:58 

This works on the Mac too, even though the Mac's man page only mentions am i and not that you can use any two words.

So of course I've now added an alias whom so that I can type whom Mom likes. I actually pride myself on not being a grammar pedant. I make an exception in this case because it amuses me.

This year I'm using Swift as much as I can for Advent of Code. After fiddling with a few different coding environments, I settled on Xcode. I have a "Command Line Tool" project that I reset everyday to contain some minimal boilerplate code. Starting with that, I code my solution for the day's AoC puzzle.

This might seem like the obvious choice — what else would one use for writing Swift code? — but I actually started out with CodeRunner, a great tool that I used last year as well. I switched to Xcode after a few days because I was having trouble getting Swift breakpoints to work in CodeRunner.

On top of that I realized how helpful the other goodies in Xcode are, even for one-off exercises like AoC. By using Xcode I get integration with the documentation, automatic "fix-its" for common syntax errors, and "Edit All in Scope". That last feature is handy because when I catch myself agonizing over a name I can stop, use anything quick that comes to mind, and move on. It'll be trivial to change the name when a better one comes to me, usually while I'm on some other part of the code. I don't need the full "Refactor" feature, which is a bit slower to use, because all my code is almost always in one file.

I do keep CodeRunner on my Dock and use it all the time to try out bits of syntax in various languages. It's much easier to open a new file and start coding, and possibly never even save the file, than to set up a full-blown project directory. I have used Swift, Python, Java, and Objective-C to code AoC solutions, all in CodeRunner, and usually the integration with the respective language's symbolic debugger worked fine.

You might think a Swift playground would be just the thing for AoC, but I have not found that to be the case. For one thing, as far as I can tell there is no support for symbolic debugging. For another thing, AoC puzzles sometimes involve loops with millions of iterations, and it is prohibitively slow to have the results pane updated on every iteration. As far as I know there is no way to turn that off.

Out of curiosity I took a quick look at AppCode and VSCode. Both are highly un-Mac-like and required more of an investment than I was willing to make at this time.

An approach I might try when I'm feeling my hacker oats is to do my Swift coding in Terminal, with vim in one window and lldb in another. The oats aren't quite there yet, though. Maybe next year.

[UPDATE: Wow, Rich Siegel of Bare Bones replied to my email within a few hours — on Thanksgiving morning! See the updates below.]

Issues in BBEdit 12.0.1:

• If I change the default font using BBEdit > Preferences… > Editor Defaults > Default font: > Select…, the display of currently open documents doesn't change. They keep using the old font, even if I resize the window to force the text layout to update. (This "nudging" used to be needed in older versions of BBEdit to get font changes to get applied to open documents.) Newly opened files do use the new font preference.

  • Workaround: either relaunch BBEdit or close documents and reopen them.
  • UPDATE: This is fixed in 12.0.2. I thought I had reproduced the bug in the beta of 12.0.2 but was mistaken.

• If I open the Font Panel with ⌘T (View > Text Display > Show Fonts) instead of through Preferences, I can modify the font of the currently open document — but only that document. Same Font Panel, different effect. Furthermore, that particular document is stuck with that font across launches, because the association between font and file is remembered in ~/Library/BBEdit/Document State.plist. As far as I can tell there's no UI for telling that file to revert to the default font preference.

  • Workaround: quit BBEdit, delete Document State.plist, and relaunch.
  • UPDATE: Persistent per-document fonts are actually a feature. The UI I had missed was the Edit > Normalize Options… menu item, which changes the document back to using your Preferences settings.

I've reported these to Bare Bones. They've always been responsive to my issue reports. If I'm missing something they'll let me know, presumably after the Thanksgiving holiday.

These kids are practicing tomoe nage, one of the many judo techniques I never got the hang of:

[Facebook post by Miki Simoyama]

Watching this, I realized there's a relevance here to my life as a computer programmer: judo is inherently a "pairing" activity. You work with a partner for all the most important stuff. As my Sensei says: "Good for me, good for you."

It's important to learn how to be a good judo partner, which includes adjusting for the different types of people you partner with: different skill levels, different goals, different sizes, shapes, and so on. In a drill like the one these girls are doing, both parties should participate mindfully — not just the person practicing the technique (tori) but the person it's being practiced on (uke).

Anybody can be a good uke. If you are less advanced than tori, you can still do the basics correctly like not being too stiff or too limp, adjusting your movements per their requests, and knowing how to do a proper breakfall if needed. Meanwhile, you can pay attention to what tori is doing and learn what it is they are practicing to accomplish, how they are trying to disrupt your balance. It is valuable to learn this from uke's perspective, to engage mentally and not be a passive practice dummy. You shouldn't think too hard — "think" is probably the wrong word anyway — you just have to stay aware and open and you'll learn a lot by osmosis. At least that's my theory. Think of that quote about Ginger Rogers: she did everything Fred Astaire did, except backwards and in high heels. When you are a mindful uke you are sort of practicing judo backwards and in high heels.

If you are more advanced than tori, and understand what they are practicing well enough, you might provide verbal reminders and cues — "Pull the sleeve," "Don't bend over," "Hips need to be lower," and so on. Sometimes, though, silence is better and it's more important to let tori keep trying what they're trying. You can also adjust your own movements to help tori with the intricacies of the technique they're practicing. For example, if tori is working on the timing of a foot sweep it's uke's job to move naturally while knowingly being vulnerable. It takes practice to do this, because you must pretend, over and over, that you have zero anticipation that your balance is about to be disrupted. Any anticipation will come through as tension in your body that tori will be able to sense, and this will be counterproductive. To use another movie analogy, think of that blooper in North by Northwest when a kid covers his ears because he knows there's about to be a loud bang. Being able to relax that anticipation can be tricky; it's hard not to be that kid. The feeling of being tripped is quite unsettling, and here you are helping tori get better at doing that to you.

Back when I was playing judo I think I was pretty decent at "pairing" in terms of adjusting to the person, being aware of safety for both parties, and so on. As a programmer I think my "pairing" abilities could use improvement, which will only happen if I practice as diligently as these two little girls.

[Cross-posted from my judo blog.]

Last year when I switched to a low-carb diet I wished I had something like Instruments for my body, where I could observe changes in various parameters throughout the day. Later I learned that's basically what a continuous glucose monitor is. It's like an Instrument that measures one parameter — blood glucose — and lets you graph it over time. To use one, you need a prescription for it, you need have to have it embedded under your skin, and it has to be replaced every so often. Kind of a hassle, not something I feel like doing.

There are rumors that Apple has secretly been developing a non-invasive CGM. It would be amazing and an absolute game-changer if this is true and Apple has it working well enough to be useful, i.e., accurate enough to inform day-to-day decisions about diet and medication. This would mean they've solved technical challenges that other companies have been trying to solve for years — which is not impossible, but I'm not going to hold my breath or jump to any conclusions. I'm just going to wait and see.

If Apple plans to attack the world's diabetes problem, I wonder if a more likely scenario is that they'll announce a partnership with Virta. Purely fanciful speculation on my part, in the fine tradition of pre-WWDC baseless rumor-mongering. I make the connection in my mind because Virta takes a technology-based approach, because it is an ambitious startup that aspires to attack diabetes at scale, and because Peter Attia, an advisor to Virta, is an obsessive self-measurer and wears a CGM even though he is not diabetic.