個人番号カードの電子証明書の期限が近いということで、役所の窓口まで更新手続きに行ってきた。
暗証番号を紙に書いて職員が代理入力するか、自分でタッチパネルで入力するかという選択肢を示されたので、後者を選んだ。
一応あらかじめ新しい暗証番号を用意して行ったのだけど、流れの説明も特にないまま無骨な画面を次々出される中で「さっき入力したのは本人確認用の現在の暗証番号か？それとも新しい証明書用か？」と混乱してしまい、面倒になってすべて以前と同じものにしてしまった。
カードを新規発行した時には確認のために暗証番号をそれぞれ 2 回ずつ入力させられた記憶があるけれど、今回はそれぞれ 1 回で終わってしまい、入力を間違っていないか途端に不安になった。
すべての入力が終わったあと、担当してくれていた職員が PC を操作しながら「こんなに長いの覚えていられてすごいですね」というようなことを言った、ように聞こえた。
まるで独り言のような言い方だったし想定外（つーか覚えてないし目コピだし）だったので咄嗟になにも反応できなかったのだけど、これは職員が入力された生の暗証番号を見ることができる（あるいはそもそも目視確認するフローになっている）ということなんだろうか？
いや、どうせ専用にランダム生成したものなので、必要なのであれば、暗証番号を担当職員に見られることは個人的には許容できる。
ただ、いずれにせよ人目に触れると事前にわかっていたら、わざわざ ABC 配列のタッチパネルを使って自分で入力するなんて選択はしなかった。
最後に書類を渡してくれた別の職員が「無事に通りましたので」というようなことを言った。
無事に通らないことがあるの？通らなかったら新旧の証明書はどうなるの？
みたいな疑問が浮かんだけれど、礼だけ述べて辞去した。
総じて、不安を覚える手続きだった。
セキュリティはよくよく考慮されていると言われているし、合理的で便利な方向に活用が進めばいいとは思うけれど、そもそも現場の窓口での UX がこれじゃあな、というのが正直な感想。
複雑な技術を現場にどうプレゼンテーションすべきかの悪い見本かな、なんてことも考えた。
暗証番号が間違っていないか、いざ必要になる前にどうにかして確認しておかないと。
文章を書くときにずっと気になっていたことがあって、和文と欧文が混在する文章（組版用語では和欧混植というらしい）で適宜空白を入れるべきか否かということ。
たとえば iPhone 14 を␣iPhone 14␣と書くべきか否か、といった話。
仕事のチャットやメールなんかでは適当に空白を入れることが多いものの、殊ここでは時期によって入れたり入れなかったりが続いていた。
最近はもっぱら
TeX
のソースよろしくベタ書きしていて、「近い将来 CSS でアキの制御ができるようになるのでは」と期待していたのだけど、まあ望みは薄そう。
たとえば一般社団法人・日本翻訳連盟が公開している『JTF 日本語標準スタイルガイド（翻訳用）』というガイドラインでは、「原則として、全角文字と半角文字の間にスペースを入れません」とされている。
一方で、個人的には空白が入っている方が視認性が高く感じるものの、「Web␣サイト」や「3␣ヶ月」のように違和感があるケースもある。
結局のところ、これという正解がない。
いろいろと考えた結果、どうあるべきかというより自分の中でルールを統一できていないことがもんにょりポイントだとわかったので、なにかしらルールを決めてそれに従うフローを組むべきだと思っていた。
そんな中で最近 textlint というツールを知ったので、これのお世話になることにした。
今のところ textlint-rule-preset-ja-spacing をこんなルールで適用している。
{
"rules": {
"preset-ja-spacing": {
"ja-nakaguro-or-halfwidth-space-between-katakana": true,
"ja-no-space-around-parentheses": true,
"ja-no-space-between-full-width": true,
"ja-space-between-half-and-full-width": {
"space": "always",
"exceptPunctuation": false,
"lintStyledNode": true
},
"ja-space-after-exclamation": false,
"ja-space-after-question": false,
"ja-space-around-code": {
"before": true,
"after": true
}
}
}
}
どうも exceptPunctuation が切れていない（句読点直後に空白が入らない）ケースがある気がするものの、それも含めて完全にお任せしている。
将来直るならそれはそれで。
Gentoo の運用を始めて以来、 Linux カーネルのビルドコンフィグはずっと genkernel のデフォルトを使ってきたのだけど、
そろそろカスタマイズでもしようかと思った矢先にカーネルソースのアップデートが出てきて、やるしかない状況になった。
動機はいくつかあって、哀しい哉、マシンスペックの貧しさを感じさせる理由が並ぶ。
/boot を 128MB で切ってしまったので些か心細い- ビルドに要する時間や計算資源を節約したい
- Ccache を使っていて無駄にキャッシュを埋めたくない
不要なモジュールをある程度減らすという目標のもと、
- Virtualization
- Networking support
- Device Drivers
- File systems
あたりをサクサク削ってみた結果、ローダブルモジュール数をおよそ半分にできた。
追い込むとキリがないので今回はこんなところで。
無理に追い込みすぎてカーネルパニックを起こしていた若かりし日々を思い出す。
MacBook Pro（13-inch, Late 2013）を使い続けて 8 年半。
論理的には驚くほど健在なのでこの 2 年くらいずっと買い替えを迷っていたのだけれど、 Monterey でついにサポートから外れてしまったし、バッテリーがわずかに膨張してネジ山が一箇所死んでしまったので、ようやく買い換える決意をした。
MacBook Air と少し悩んだ末に、今回は Mac mini にすることにした。
上海から直送らしく、現在納品待ち。
ちなみにコスト面から現行 MacBook Pro は選択肢になく、最近出てきた Mac Studio は眼中にすらなかった。
ここ数年で脱 macOS というか、 iOS デバイスでもできることを増やす取り組みをしてきたこともあって、自分の生活の中でコンピュータが必要なシーンは（ゼロになることはないけれど）着実に減っている。
そんな状況なので、各種アダプタの取り回しやバッテリーの経年劣化といったモバイルコンピュータ特有の煩わしさに耐え忍んでまで、携帯性を確保することに意味があるとは思えなかった。
PostgreSQL の 14 が stable になったようで、@world を update したら自動的に 14 が降ってきた。
勝手に 13 を置き換えてくれるのかと思ったらそうではなく、二つのバージョンが同時にインストールされた状態になるので、マイグレーションは自分でやる必要がある。
Portage のメッセージに導かれて Wiki を辿ると、マイグレーションの手順を用意してくれている。
基本的にこの内容に従えば、特に苦もなくマイグレーションできる。
補足としていくつか。
- うちの場合
local が trust でないので、pg_upgrade の前に pg_hba.conf の調整が必要
- サービスの自動起動設定は忘れずにケアする
- 旧バージョンは依存関係が切れているので depclean すれば消えるが、データと設定は残してくれるので好きなように
なにはともあれ、 Portage からのメッセージを見逃さないことが大事。
