The yaml document from hell

TL;DR YAMLはやばいのでPython, Nixを使おう

• サーバのconfig周りの文脈で、YAMLはやばいという記事。
• 22:22 が 1342 になります、とか no は false になりますとか、分かりやすく例示されていてよかった。
  • YAMLの 22:22 のようなものはYAML1.2から取り除かれている。しかしPyYAMLなどライブラリが追従してなくてYAML1.1のこともあるので、気をつけるべき。
• この記事を書いた人はDhallやCUEよりもPythonやNixを使おうと主張している
  • CUEは発展途上だと思うため、この対決をさせるのはアンフェアな気もする
  • Dhallは触ったことないので触りたい
• Neco Weekly ではこの記事に対してk8sの文脈で欲しい機能が挙げられていてよかった。

個人的には以下のような機能を兼ね備えたツールが欲しいです😎

Helm のようなテンプレート機能
Helm install のような手軽なインストール手段
Kustomize のようなオーバーレイ機能（off-the-shelf configuration）
CUE のような型チェック機能
jsonnet のような関数やモジュールの仕組み
VSCodeやIntelliJ IDEAによるエディタサポート

個人的にこれに加えるならRust並みの親切なエラー表示も欲しい(CUEのエラー表示が辛かった印象)

• AltYAMLみたいなのができるといいのかな

How to Use Sigstore without Sigstore

TL;DR SigstoreのFulcioは取り除けるのではないかという主張

• まだちゃんと読めてない。
• Sigstoreについては PublickeyのSigstore 1.0 に関する記事 が概観掴みやすい。
• Sigstoreは署名ツールCosign, 認証局Fulcio, 改竄不可能な記録帳Rekorなどから構成される。このうちFulcioは実は不要なのでないか？という指摘。
• プレプリントなので信頼できるかという話はあるけど、暗号畑の人が実用世界のソフトウェアに関わっていくのいいですね。
• パッと読んだ感じ、認証フローを変更しているけど安全性に関する議論が見当たらなくてもう少し詳しく読みたい。

GitHub Container Registryへのdocker loginでGitHub CLIの認証情報を利用する

TL;DR ghcrへのdocker loginのCredential Helperにghコマンドを使う

• ghcrへのログインはこれまでtokenでやっていたのだけど、ghコマンド使えないかな〜と思って探したらあった。
• 記事が書かれた当時experimentalでまだissueがOpenなのでそこだけ気にする場合は注意。

大公開：ArkEdge Space のソフトウェアチームのポリシーと実現したい夢 - ArkEdge Space Blog

TL;DR ArkEdge Spaceの抱負。

• GoogleのOKRの解説 があるの知らなかった
• ポリシーは何かを強制する仕組みとして機能するので、否定することがポリシーを定める意義だよなあみたいなことを考えた。
  • Rustが動かない、開発環境が貧弱なものを強制されるマイコンボードは採用しない、とか
• スケールするとは開発成果に対してコストが劣線形になるように努めることで、定数削減ではない、というのはすごく心に刺さった。
  • 何パーセント削減しました！はスケールに対して本質ではない
  • 変化に対しどのスケールで効くのかが本質

大物からの評価 - 増井俊之

TL;DR 有名人に自分の考えを伝えても的外れだと思うような回答が返ってくることがある。だから人に感想を伝えるときは慎重に。

• 増井さんはガラケー向け入力システムとか、強いものをたくさん考案されている。
• 教訓が自分に対して向いている(自分もそう判断されるかもしれないから気をつけよう)となっているのがいいなと思った。何か不満を持った時それは同時に自分にも適用されうるという自覚を持ち続けることが大事。

お弁当箱に詰めたい - sushitecture

TL;DR コンテンツ配置デザインについての考察。タイムラインではなく、お弁当箱のような自分で詰める楽しさは良いものだという主張。

• hashrockさんや複雑GUI界隈の方々は面白い考察をされているので読んでいて楽しい。
• お弁当的なコンテンツ配置、多分制限をかけることが重要そう。MastodonやMisskeyのようなごちゃっとしたプロフィール画面僕はそんなに好きではないので、個人の世界観を限定された範囲で演出できるような上手い制限の掛け方が本質になりそうな気がした。

入門 境界づけられたコンテキスト

TL;DR 主にデータベース設計を例に、上手い設計をするためにはステークホルダーを巻き込んでメタな思考で整理をする必要があるという話。

• コンテキストは利用者の立場に応じて事情や背景を指すもの
• 近しい会話のような、具体に近い部分ではコンテキストはすぐには見つからないのでメタな思考が必要
• 実装都合を一旦無視して、利害関係者を巻き込んで情報を引き出して整理することが大事

確かになあという気持ちになった。最近こういう、インターネットで閉じない、ドメインに潜ってステークホルダーと会話しなければ現実世界でソフトウェアの価値を引き出すことはできないのではないかという思考になりがち。

その証明書、安全ですか？ | IIJ Engineers Blog

TL;DR 経路ハイジャックされたら信頼の起点である認証局もなりすませるので、HTTPSであろうと防ぐことができない。

• BGPハイジャック、まだ原理を理解していないけどそういう経路ハイジャックは日常的に起こる事実に驚いた。
• 信頼の起点を成りすませるというのが事例とともに挙げられていて分かりやすく脅威を感じられてよかった。
• 証明書の起点偽造に関しては、Linuxのディストリビューションを入れる時のインストーラに入る証明書を操作できたらLinux起動時から欺けるかも、など怖いなあと感じる。信頼は起点がある、もしくはGPGのように相互の輪をなす、の形をしているので、これを防ぐのは難しそうに見える。