文章を書くときにずっと気になっていたことがあって、和文と欧文が混在する文章（組版用語では和欧混植というらしい）で適宜空白を入れるべきか否かということ。
たとえば 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 からのメッセージを見逃さないことが大事。
時流に乗って（乗れてないけど）、手元の Git リポジトリの master ブランチを改名することにした。
ただざっと調べたところでは（GitHub とかでなく）独自のリモートリポジトリを使っているケースの情報が見当たらなかったので、せっかくなのでまとめておく。
ちなみに、このテキストを改名後の main ブランチに push することで publish されるので、何かミスってたらこのテキストは世に出ないことになる。
リモートのブランチ名を変える
ローカルの master ブランチを main に改名する。
$ git checkout master
$ git branch -m master main
改名した main をリモートに push し、同時に upstream を設定する。
$ git push --set-upstream origin main
次にリモートの master を削除する。
が、リモートの HEAD が master を向いたままだと削除できないので main に向け直す。
GitHub で言うところの「デフォルトブランチの変更」に相当する。
ここだけはリモートリポジトリを直接触る必要がある。
remote$ git symbolic-ref HEAD refs/heads/main
リモートの master を削除する。
$ git push origin --delete master
remotes/origin/HEAD が消えてしまうので再設定する。
$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
他の clone で追いかける
ローカルの master ブランチを main に改名する。
$ git checkout master
$ git branch -m master main
fetch して upstream を再設定する。
$ git fetch
$ git branch --unset-upstream
$ git branch --set-upstream-to=origin/main
remotes/origin/HEAD が origin/master を向いたままなので、再設定する。
$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
残っているリモートトラッキングブランチ origin/master を削除する。
$ git branch --remotes --delete origin/master
おまけ
次にリポジトリを新規作成する場合に備えて、デフォルトブランチの名前を変えておく。
$ git config --global init.defaultBranch main
参考