hogashi.*

日記から何から

Docker Compose 1.27.0以降ではdocker-compose.ymlにversionを書く必要がなくなっていた

あらすじ

 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)
The top-level version property 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.

https://docs.docker.com/compose/compose-file/04-version-and-name/

 しかし昔は必要だった記憶があって、気になって 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 は書かなくてよい状態だったのか……。

  • Merge 2.x and 3.x compose formats and align with COMPOSE_SPEC schema
https://github.com/docker/compose/releases/tag/1.27.0

 しかしいつから `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 compose.yaml (preferred) or compose.yml that is placed in the working directory. Compose also supports docker-compose.yaml and docker-compose.yml for backwards compatibility of earlier versions. If both files exist, Compose prefers the canonical compose.yaml.

https://docs.docker.com/compose/compose-application-model/#the-compose-file

*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公開

 拡張機能twitter画像原寸ボタン」の v7.0.0 を公開しました (申請中なので、それが通り次第自然と更新されます)。 x.com mobile.x.com pro.x.com でも動作するように対象ドメインを追加したので、"権限エラー"みたいな表示が出るかもしれませんが、新規ドメインでも動作することを許可すれば使えます。

 追記 (2024/5/17 23:15): 更新されていたので画像を撮りました。

  • 右上に"エラー"と出るので、クリック
  • "twitter画像原寸ボタン が無効になりました" をクリック
  • 書かれている内容を読み、許可できる場合は "権限を許可" をクリック
    • 注記しておくと、この拡張機能は外部にデータを送信していません

Google Chrome 版:
chromewebstore.google.com

Microsoft Edge 版:
microsoftedge.microsoft.com

Python 3.12の環境でbrew install furoshiki2できなくなってたのでp-r出した

 motemen/furoshiki2Python 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 を使うように直してインストールできるか試した(できた)。

ワイワイ椅子2023

 ワイワイあらすじ: blog.hog.as

 以来この木の椅子だけで生活していました。特に直近で買い直すつもりはなかったけど、この間の Amazon ブラックフライデー

白だけ半額になっていたこの椅子を買いました。

ワイワイ
これは何

 ストレスレストーキョーという名前の椅子で、上にツイート(便宜上の単語)を貼った r7kamura さんの記事を読んでいいな〜と思いつつ、

r7kamura.com

ただ、 Amazon で見ると 25万円とかで、おまけに結構大きいので、今の家に置くのは流石にシュッと購入はできないなと踏みとどまりつつ、広い部屋に引っ越したりできたら買う候補かな、くらいの気持ちで暮らしていました。

激動の週末

 そんな中、 Amazon ブラックフライデーで半額の 13万円くらいで買える状態になっていたわけです。買いました。
 ブラックフライデーは期間/個数限定なので、この時点では「ちゃんとしたオフィスチェアの相場を思うと、オフィスチェアよりは自分の体への合い方がよいだろう」という予想だけで買っています。これが金曜日(黒)。

 流石に体に合うかどうか座ってみてから買いたいので、 (もし合わなかったらキャンセルできると信じて) 翌日に座りに行くことに。かねてよりちょこちょこ検索して京都にもストレスレスの椅子を置いているのは知っていたので昼過ぎに向かい、探すとトーキョーが無い。聞くと、ここには無い、大阪のショールームにある、と言われて、急ぎ電車で大阪駅に到着。馴染みのないでかい駅を歩きまくりショールームでめでたく座ってみることができました。

www.stressless.com

 座った感じ違和感はないし、むしろよく安定していて楽かもという印象で、そのままキャンセルもせず受け取ることに決めました。色々質問させてもらって、ところで革製品なんですがお手入れは……と聞くと一応公式が"相性がよい"と認めたお手入れセットがあるということで、買いたいです→ここでは買えなくてなんばの高島屋さんにあるんです、という会話をし、なんばへ。

 突然来て質問もなくお手入れセットだけ自信ありげに買っていく人が現れても、ちゃんと対応していただけて、軽く説明してもらって購入。ようやく帰路につきます。結局 Google Maps では土曜日の細長いタイムラインが爆誕

激往復

 あとショールームで「廊下 74cm とかしかないけど搬入できます……?」って聞いたら 65cm くらいはあれば大丈夫だと思うとのことだった (実際搬入できた) ので今後買う人は参考まで。 74cm くらいの場合は普通には入らないので、最大までリクライニングした状態で下の調整ネジを固定して横倒しで入れることになります。

使ってみて

 横幅が広くゆったり座れて楽です。キャスターがないし、回転も重めかつ静止摩擦がそれなりにあるのでふらふらしないので酔うような感じもしない。今のところは快適に使えています。リクライニングはレバー操作とかなく常に姿勢に応じて起きるので、は~と後ろに倒れると勝手に倒れていくけど、これも重めなのであまりつらくなく、プラスひと操作で水平まで倒れられるので、椅子で寝るのが捗ります。困った。
 あと買ったやつはオットマンなしのしかなかったので、オットマンは別途どこかで見繕おうと思っています。夏は暑いかもしれないなと思いつつ、どうなるかわくわくしています。なんとかメンテしていきたい。

 whywaita Advent Calendar 2023 - Adventar 16日目の記事でした (少し遅れてすみません!)。それでは良いお年を~🎍

拡張機能「twitter画像原寸ボタン」v5.4.0, v6.0.0公開

 拡張機能twitter画像原寸ボタン」 v5.4.0, v6.0.0 を公開しました。

変更点
  • TweetDeck の URL が pro.twitter.com に変わったので、そこでも動作するようにしました (v5.4.0)
    • Chrome であれば右上で「エラー」のような表示が出て拡張機能が止まっているはずで、 pro.twitter.com での動作を許可するとまた動きます (Edge も同じ感じだと思うけど試してないです)
  • Original ボタンのテキストを設定できるようにしました (v6.0.0)
    • 設定ポップアップに好きな文字列を入れて保存すると、ボタンのテキストとして使われます
Original ボタンが門松になっている様子
公開状態

 Chrome 版は v6.0.0 まで公開済みで、 Edge 版はどちらもまだ公開待ちです。

 インストールはこちらから:

日記

 なんか動かないなと思ったらドメインが変わっていたのでなるほど感があった。ドメインの追加自体はすぐできたので出したら数分で通ってすごい (差分で確認されている?)。
 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 名を予定外のところで使われてしまうおそれが減ったりして便利なのかも。でも微妙に違う用途のために、微妙に違うコンポーネントがたくさんできたり、コンポーネント内で条件分岐が生まれまくったりすると、それはそれで大変そう。

Tailwind CSSを使ってスタイルをあてた設定ポップアップ

*1:今思うと html ファイルも含めてまとめて扱うようなものでしか嬉しくない?ならそれはそうか

*2:任意のテンプレートの概念でもよい

GitHubのissueやpull reqのラベルはキーボード操作でも付けられる

 GitHub の issue とか pull request では、 L キーを押すとラベルのモーダルを開ける。検索語を入れたりしつつ、十字キー上下でラベルを選んで、 Enter キーかスペースキーでチェックをつけたり外したりしてから、 Escape キーでモーダルを閉じると、チェックをつけたラベルが付く。

操作の様子

 GitHub のショートカット一覧を見るとめちゃくちゃ色々ある。

docs.github.com

 余談だけど、日本語でこのドキュメントを見ると、ショートカット一覧の表が (GitHub のドキュメントの独自のテンプレートの記述のせい?で) 崩れている箇所があって、何かして直せないのかな〜と思ったけど、すでに issue が立って閉じられていた (内部でやってる処理だから報告しとくねと書かれているけど、その後まだそのままになっていそう)。 Keyboard shortcuts : broken table in translations · Issue #24021 · github/docs · GitHub

 CSS だけでダークモードとそうじゃないモード(ライトモード?)を切り替えられるような仕組みはできないのかな〜と考えていて、 details タグをボタンと見なして open 属性の有無で切り替えるというのは :has で書けるな、と思ったのだけど、自分のブログに置こうとすると、ページ遷移ごとにもとに戻ってしまうので、あんまり便利ではなさそうだった。ページ遷移をまたいで何かするなら localStorage とかを使うことになりそうだし、それだったら details タグとか使わずに最初から JavaScript を書いたらよさそう、となってしまった。何かうまい方法があったりするんだろうか……。