ルービックキューブを揃えるまでの時間を測りたい！手元にシェルしかない！そんなときはこう
$ time read
real 0m2.951s
user 0m0.000s
sys 0m0.000s
read コマンドで入力を待ち受けていた時間が出てくれる。これで計測開始 (コマンド開始) と 計測終了 (read に入力) の両方を Enter キーでできるのでわかりやすくて便利。
↑は bash で試したけど、 zsh では $ time (read) とするとよいようだった ($ time read だと何も出ない。ビルトインのコマンドは(カレントのシェルで実行されるので)計測されないので、括弧をつけてサブシェルで実行させると計測できる、とのことだった zsh - `time echo` got no output - Unix & Linux Stack Exchange)。
annotation といっているのはこれ (画像) *1 。この画像の場合、 Node.js 16 を使う actions は非推奨なので Node.js 20 を使うものに更新してね、具体的には actions/checkout@v3 と actions/setup-node@v3 だよ、と言われている。
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, actions/setup-node@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.
書かれていることに沿って更新したらいいのだけど、こういうのっていろんな workflow にそれぞれ書いていて (特に actions/checkout とか)、それぞれ annotation がついている。どれで何が出ているかの一覧ができないので、結構不便。
一覧するためのツールとして、 gh コマンドの拡張機能という先行研究がある。最近の workflow の実行を取ってきて annotation を一覧するというもの。これはかなり便利で見やすくて、小さいリポジトリならこれで戦える。
swfz.hatenablog.com
問題は workflow がたくさんある大きいリポジトリで、最近の実行だけ見ていると間に合わない。ので、リポジトリにある workflow それぞれについて、最も最近の実行の annotation を取ってきたい。
という動機で書いたのが今回のシェルスクリプト。
github.com
gh コマンドを叩きまくって、 workflow 一覧 → それぞれの check suite の最新の run 一覧 → それぞれの annotation 一覧 という順番で取ってくる。 GitHub Actions は登場人物が多くて難しい (理解してないだけでもっと簡単な方法があったりするのかも……)。
シェルスクリプトなので、 git clone でもコピペでもいいので手元に持ってきて、素朴にこう実行したら動く (gh とか jq とかは必要なので適宜入れてください)。
$ ./list-workflow-annotation-for-repo.sh owner/repo > annotations.md
実行すると markdown で出力される (標準出力に出すので↑みたいにするのがおすすめ)。改行とかはあんまり頑張ってないので見づらいかもだけど、例えば GitHub issue に貼るとこういう感じで見れる。各見出しは、該当の annotation が出ている workflow やその実行の画面へのリンクになっている。
## [CodeQL](https://github.com/hogashi/twitterOpenOriginalImage/blob/master/.github/workflows/codeql-analysis.yml) Latest run: [https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468391494](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468391494) ### [Analyze (javascript)](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468391494/job/26084641757) ## [git-issue-release](https://github.com/hogashi/twitterOpenOriginalImage/blob/master/.github/workflows/git-issue-release.yml) Latest run: [https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468384396](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468384396) ### [action](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468384396/job/26084617386) ``` Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: kouki-dan/git-issue-release@v1. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/. ``` ``` The following actions uses node12 which is deprecated and will be forced to run on node16: kouki-dan/git-issue-release@v1. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/ ``` ## [Node.js CI](https://github.com/hogashi/twitterOpenOriginalImage/blob/master/.github/workflows/nodejs.yml) Latest run: [https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9471522972](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9471522972) ### [check](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9471522972/job/26094921517) ``` Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, actions/setup-node@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/. ```
これを見ながら、順番にバージョンを上げたりしていったらよい。
これ書いてて気付いたんだけど、 actions の更新は Renovate がやってくれる。なので、いっこ annotation を見かけたら、 Renovate の Dependency Dashboard issue を見に行って、チェックをつけたら終了できる。便利ですね〜
今回書いたシェルスクリプトの存在意義を頑張ってこじつけると、 annotation というのは ("使ってる actions が古いよ"だけではなく) エラーや警告全般が存在するので、何かエラーや警告が出ているかどうかを見て回る、というのに使える。
例えば、 typo しているとエラーになるわけだけど、そういうときはこういう annotation がつく。エラーだと当然実行が失敗するので気付けるけど、警告系だと気付かないことも多そうだし、まあまあ使えることもあるかも。
The workflow is not valid. .github/workflows/nodejs.yml (Line: 9, Col: 5): Unexpected value 'runs-o' .github/workflows/nodejs.yml (Line: 9, Col: 5): Required property is missing: runs-on
docker-compose.yml でトップレベルの version 要素を指定していると、 WARN[0000] (...)/docker-compose.yml: `version` is obsolete と表示される。インターネットを見ていくと version は指定しなくて良い、消したらいい、という記事がたくさん出てくるし、たしかに公式のドキュメントにも obsolete と書かれている Version and name top-level elements | Docker Docs。
Version top-level element (obsolete)
https://docs.docker.com/compose/compose-file/04-version-and-name/
The top-levelversionproperty is defined by the Compose Specification for backward compatibility. It is only informative and you'll receive a warning message that it is obsolete if used.
しかし昔は必要だった記憶があって、気になって issue/p-r を見ていったら、 2020年あたりにはすでに optional になっていたようだった。
version を書くのをやめよう、という issue はこれ Validate compose file on supported API, not version · Issue #7201 · docker/compose 。
大まかに書くと「Docker エンジンの API バージョンと docker-compose.yml のバージョンの食い違いによるエラーや、妙に古い記述から version をコピペしていて yml のパースに失敗するなど、色々問題が起きている。 docker-compose.yml の version の記述をやめ、とにかく Docker エンジンの API バージョンを参照して判断することにすれば、解決できるはずだ」という提案。結局実行するときにはエンジン側で対応している API しか使えないのだから、そっちのバージョンだけを真として扱うのが良いだろう、というのはわかりやすいし確かに感がある*1。
この内容が Compose Spec community という場所で議論され Don't require version · Issue #13 · compose-spec/compose-spec 、話し合いの結果 (2020/6/4 に) 受理されている。議論のすべてが issue 上に載っているわけではなさそうに見える (激論中に突然受理されているみたいになっている) けど、「破壊的変更をしたくなることは未来永劫ないのか」「逆にどの機能が使えるのかわかりづらくないか」みたいなことが議論されていそう。
この結果、仕様が変更され Make `version` optional and define strict/standard/loose parsing mode by ndeloof · Pull Request #82 · compose-spec/compose-spec 、 version は後方互換性のために書けるが、単に付記する情報くらいの扱い (この値を使って何かするわけではない) 、ということになっている。
## Version top-level element - A top-level version property is required by the specification. Version MUST be 3.x or later, legacy docker-compose 1.x and 2.x are not included as part of this specification. Implementations MAY accept such legacy formats for compatibility purposes. + Top-level `version` property is defined by the specification for backward compatibility but is only informative.https://github.com/compose-spec/compose-spec/pull/82/files#diff-bc6661da34ecae62fbe724bb93fd69b91a7f81143f2683a81163231de7e3b545
docker-compose の実装のほうで version を optional にするのはこの p-r でやっていて Merge V2 - V3 compose file formats (optional version field) by aiordache · Pull Request #7588 · docker/compose v2, v3 の docker-compose.yml のスキーマを一緒にしようという趣旨になっている。 master ブランチにマージされたのは 2020/7/27 。
version に書かれたバージョンの値ごとにスキーマを確認するのではなく、とにかくひとつのスキーマを真とするようになったので、 compose/config/config_schema_v2.0.json, compose/config/config_schema_v2.1.json, ... みたいなファイルが全部消えて compose/config/config_schema_compose_spec.json に統一されているのが感動的 (v2 と v3 もまとめられていることがわかる)。
この変更は (1.27.0-rc1 を経て) Release 1.27.0 · docker/compose で 2020/9/7 にリリースされている (リリースノートの 1.27.0 の内容にも同じことが書かれている)。以来 version は書かなくてよい状態だったのか……。
https://github.com/docker/compose/releases/tag/1.27.0
- Merge 2.x and 3.x compose formats and align with COMPOSE_SPEC schema
しかしいつから `version` is obsolete の warn が出ていたのかはよくわからなかった。 2020年ごろにこの warn を見た覚えがないけど、本当に出てなかったのか単に warn を見過ごしていたかあんまり自信がない。インターネットを見るとなんとなく 2024年の情報が多いので、最近のどこかのバージョンでちゃんと warn が出るようになったのかな……。
docker-compose.yml と書き続けてきたけど、実は今は設定ファイル (Compose file) のファイル名は compose.yaml が推奨されている *2。 拡張子は yml でも大丈夫で、 docker-compose.yaml (.yml) も後方互換性のために動くようになっている。公式のドキュメントはこれ https://docs.docker.com/compose/compose-application-model/#the-compose-file 。
The default path for a Compose file is
https://docs.docker.com/compose/compose-application-model/#the-compose-filecompose.yaml(preferred) orcompose.ymlthat is placed in the working directory. Compose also supportsdocker-compose.yamlanddocker-compose.ymlfor backwards compatibility of earlier versions. If both files exist, Compose prefers the canonicalcompose.yaml.
*1:一応 1.x 系では version の記述を使っていた、とは付記されていそうで、 2.x 以降になってから不要にできるようになった、と書かれていそう？ だけどこのあたりはあまり読み取れなかった
*2:p-r でいうとこのあたり Update README.md to use standard `compose.yaml` file name by johnthagen · Pull Request #11233 · docker/compose
拡張機能「twitter画像原寸ボタン」の v7.0.0 を公開しました (申請中なので、それが通り次第自然と更新されます)。 x.com mobile.x.com pro.x.com でも動作するように対象ドメインを追加したので、"権限エラー"みたいな表示が出るかもしれませんが、新規ドメインでも動作することを許可すれば使えます。
追記 (2024/5/17 23:15): 更新されていたので画像を撮りました。
motemen/furoshiki2 が Python 3.12 で brew install 失敗するようになっていて、 
id:motemen に助けを求めたところ、 📝2023-07-20 PyYAMLの5.4.1がChefBuildErrorでインストールできない - Minerva という話があるので PyYAML のバージョン上げると直ったり？ と教えてもらった。
ついでに homebrew のレシピが GitHub - motemen/homebrew-furoshiki2 にあるのも教わって、直す p-r をつくって出した (Update PyYAML to 6.0.1 to fix installation on Python 3.10 and after by hogashi · Pull Request #4 · motemen/homebrew-furoshiki2)。さきほどマージしてもらったのでインストールできるようになったはず (Python 3.10 以降で失敗するようになっていた？ っぽい)。
今回これをやったので、 brew のレシピがどこにあるのかは brew info furoshiki2 で見られることがわかった。 From: https://github.com/motemen/homebrew-furoshiki2/blob/HEAD/furoshiki2.rb がそれ。
$ brew info furoshiki2 ==> motemen/furoshiki2/furoshiki2: HEAD https://github.com/motemen/furoshiki2 Installed /opt/homebrew/Cellar/furoshiki2/HEAD-9c97d4c (42 files, 456.6KB) * Built from source on 2024-05-09 at 15:58:27 From: https://github.com/motemen/homebrew-furoshiki2/blob/HEAD/furoshiki2.rb ==> Dependencies Required: python3 ✔ ==> Options --HEAD Install HEAD version
あとこれも教わったことだけど、 brew edit furoshiki2 するとエディタが開いて、レシピを手元でいじれる。今回はそれを使って、 PyYAML 6.0.1 を使うように直してインストールできるか試した(できた)。
ワイワイあらすじ: blog.hog.as
以来この木の椅子だけで生活していました。特に直近で買い直すつもりはなかったけど、この間の Amazon ブラックフライデーで
ストレスレストーキョー、Amazonのやつよく見たら白色だけ半額になっててすごい
— r7kamura (@r7kamura) 2023年12月1日
白だけ半額になっていたこの椅子を買いました。
ストレスレストーキョーという名前の椅子で、上にツイート(便宜上の単語)を貼った r7kamura さんの記事を読んでいいな〜と思いつつ、
ただ、 Amazon で見ると 25万円とかで、おまけに結構大きいので、今の家に置くのは流石にシュッと購入はできないなと踏みとどまりつつ、広い部屋に引っ越したりできたら買う候補かな、くらいの気持ちで暮らしていました。
そんな中、 Amazon ブラックフライデーで半額の 13万円くらいで買える状態になっていたわけです。買いました。
ブラックフライデーは期間/個数限定なので、この時点では「ちゃんとしたオフィスチェアの相場を思うと、オフィスチェアよりは自分の体への合い方がよいだろう」という予想だけで買っています。これが金曜日(黒)。
流石に体に合うかどうか座ってみてから買いたいので、 (もし合わなかったらキャンセルできると信じて) 翌日に座りに行くことに。かねてよりちょこちょこ検索して京都にもストレスレスの椅子を置いているのは知っていたので昼過ぎに向かい、探すとトーキョーが無い。聞くと、ここには無い、大阪のショールームにある、と言われて、急ぎ電車で大阪駅に到着。馴染みのないでかい駅を歩きまくりショールームでめでたく座ってみることができました。
座った感じ違和感はないし、むしろよく安定していて楽かもという印象で、そのままキャンセルもせず受け取ることに決めました。色々質問させてもらって、ところで革製品なんですがお手入れは……と聞くと一応公式が"相性がよい"と認めたお手入れセットがあるということで、買いたいです→ここでは買えなくてなんばの高島屋さんにあるんです、という会話をし、なんばへ。
突然来て質問もなくお手入れセットだけ自信ありげに買っていく人が現れても、ちゃんと対応していただけて、軽く説明してもらって購入。ようやく帰路につきます。結局 Google Maps では土曜日の細長いタイムラインが爆誕。
あとショールームで「廊下 74cm とかしかないけど搬入できます……？」って聞いたら 65cm くらいはあれば大丈夫だと思うとのことだった (実際搬入できた) ので今後買う人は参考まで。 74cm くらいの場合は普通には入らないので、最大までリクライニングした状態で下の調整ネジを固定して横倒しで入れることになります。
横幅が広くゆったり座れて楽です。キャスターがないし、回転も重めかつ静止摩擦がそれなりにあるのでふらふらしないので酔うような感じもしない。今のところは快適に使えています。リクライニングはレバー操作とかなく常に姿勢に応じて起きるので、は～と後ろに倒れると勝手に倒れていくけど、これも重めなのであまりつらくなく、プラスひと操作で水平まで倒れられるので、椅子で寝るのが捗ります。困った。
あと買ったやつはオットマンなしのしかなかったので、オットマンは別途どこかで見繕おうと思っています。夏は暑いかもしれないなと思いつつ、どうなるかわくわくしています。なんとかメンテしていきたい。
whywaita Advent Calendar 2023 - Adventar 16日目の記事でした (少し遅れてすみません！)。それでは良いお年を～🎍
拡張機能「twitter画像原寸ボタン」 v5.4.0, v6.0.0 を公開しました。
![EKORNES [正規品]ストレスレス®トーキョー スター バニラ/マットブラック チェアのみ mサイズ](https://m.media-amazon.com/images/I/41Qd2QWwd5L._SL500_.jpg "EKORNES [正規品]ストレスレス®トーキョー スター バニラ/マットブラック チェアのみ mサイズ")
pro.twitter.com に変わったので、そこでも動作するようにしました (v5.4.0)
なんか動かないなと思ったらドメインが変わっていたのでなるほど感があった。ドメインの追加自体はすぐできたので出したら数分で通ってすごい (差分で確認されている？)。
Original ボタンのテキストを変えられるようにしたい、という要望はずいぶん前にもらっていて、なかなか手をつけられなかったものの、少し勢いが出たのでやったらできた。おまたせしてしまったものの、昨今の画像下の要素は混雑していて、需要はまだあるものと思うので、使ってもらえたら嬉しい (混雑しているので本当はもうちょっと違う場所に出せたりするといいのかもしれないけど、しっくりくる場所を考えるのが大変)。
ついでに Material UI が v5 になってよくわからなくなってしまったので、 Tailwind CSS を試すことにした。最近の潮流を追えていないので、最初は導入が全くわからなかった (
Framework Guides - Tailwind CSS に Webpack がなくて困った*1 ) ものの、 npm scripts で tailwindcss -i ... -o ... する形に落ち着いた。素朴に CLI が用意されていてビルドできて、 html ファイルで普通に link タグを書いたらよい、というのは便利。 CSS プロパティと値に対応する class 名があって、書くと勝手にスタイルが当たる、という感じで、見てほしい tsx ファイルとかを tailwind.config.js に指定しておくと勝手にビルド結果の css ファイルに含めてくれるのが賢い。あとサイズが小さくて、 zip が半分くらいになった (React コンポーネントとかもないし……)。
当然 class 名がわからないので、スタイルを微調整ドキュメントを margin とか font-size とかで検索しまくって class 名に入れていく作業だった。よく使うものは覚えられそうな命名規則だけど、ミスってないかは結構気をつかうし、細かい (px 単位とか) 指定はあまりないので、フレームワークにしっかり乗るか、 style 属性を当てていく気力は必要 (カスタマイズとかもできるっぽいけど今回はそこまでやっていない)。典型的なもののテンプレート集があって、そこからコピペで作れるというのは面白い (Tailwind CSS Components - Tailwind UI とか)。
class 名をいろんな場所で再利用する、とかはできないけど、逆に、いい class 名たちがすでに書かれている React コンポーネント*2のほうを再利用する、という書き方に勝手に寄っていく？と思うと、変に class 名を予定外のところで使われてしまうおそれが減ったりして便利なのかも。でも微妙に違う用途のために、微妙に違うコンポーネントがたくさんできたり、コンポーネント内で条件分岐が生まれまくったりすると、それはそれで大変そう。
