Python と Node.js ほんま嫌い！！！！！
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
Python と Node.js ほんま嫌い！！！！！
なんで14行弄るだけのパッチを書くためにいくつもコマンド打ってセットアップして無限に周辺ツールをゴテゴテ入れにゃならんのか
ﾊﾟｲｿｮﾝで書かれたコードのパッチを書いているが、今月いい気分になったこと全部帳消しになるのではというくらいの勢いでストレスが溜まってきている
言語がつらいのもそうだが、問題のモデリング自体をミスっているロジックを (書き直すのではなく) 修正するというのが実につらい
無限に呪詛が出てきて本当に健康に悪い、平気な顔をしてこれを読み書きできる連中は一体どこで修行してきたんだ
これだから自分の使うソフトウェアの実装言語にはこだわらないといけないんですよ
表現力がｶｽだから if の列挙になっているのに PLR0912 Too many branches とか言うて lint 弾かれてコミットを拒絶されています
そもそもプロジェクトのポリシーがわからんのでﾊﾟｲｿｮﾝのバージョンは不明です、 /match .*:/ で検索したけど match 文を使っていそうな部分はなかった
仕方ないから foo = bar if cond else baz で書いたら今度は E501 Line too long とかほざきやがる
それで改行入れて許されるならプレーンな if で代入1行だけ用意してあるのと本質的に同じじゃねえか！！
lint と type annotation で粘る前にもっとやることがあるだろ、根本的に
無駄な書類仕事を増やして仕事した気になるエアプ上層部みたいな言語だ
python - Putting an if-elif-else statement on one line? - Stack Overflow
https://stackoverflow.com/a/40743606
> ```
> x = {i<0: -1, i==0: 0, i>0: 1}[True]
> ```
技巧で遊べるのはわかったので、二度と実用言語を名乗らないでほしい
match に書き換えるか関数を分割するかしかない (まあ関数が分割しづらいのは言語よりもコード側のせいな部分はあるだろうが)
念の為 if を elif に置き換えてみたが branch カウントは誤魔化せなかった
requires-python = ">=3.8" で厳しい顔になった そうか……
https://github.com/beancount/fava/blob/main/pyproject.toml
match statement は 3.10 かららしいですね……
match 相当の if だけで既に branches 数の予算ほぼ使い切ってる
too many branches 回避でカスの可読性になったが仕方ない、言語と linter 設定がカスなのが悪い
コード見た感じまあまあカジュアルに linter 黙らせてるっぽいし too many branches だけ黙らせて愚直に並べてもいいような気がするわね
ともあれ、これで燻っていた積みタスクが解消されたので枕を高くして眠れるというもの
Cloudflare Status - DNS Update Delays
https://www.cloudflarestatus.com/incidents/byhy098jxck6
あれまあ
知的単純作業って呼んでるが、単純ではあるがコンピューターでの完全な代替が難しいものはあるよな、アノテーションとか…
ｴｰｱｲブームは知的単純作業の需要を増大させるだろうが、そもそもｴｰｱｲに仕事を奪われる〜！ とか言ってる人々のうちそれなりの割合は「何であれ人間は労働すべきで、ヒトに課せられた義務としての労働をすることが生存の条件」くらいに思ってる気がするから、そういう人々に知的単純作業を仕事として割り当てたら喜ばれたりしないか？ という悪い考えは結構ある
このアカウントは、notestockで公開設定になっていません。
ちなみに補足ですが、弊宅はこの冬まだ一度も暖房器具をつけていません (サーバラックを暖房と呼ばないのであれば、だが)
あー、他者のコミットとまとめてsquash mergeすることを前提とすると確かに差分とVCSの履歴における氏名表示の対応が崩れるし、そのあたりとしてどうなるのだろう
QT: https://fedibird.com/@tesaguri/111927819696683699 [参照]
複数の作者を持つコミットを作成する - GitHub Docs
https://docs.github.com/ja/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors
Co-authored-by の出番？
`Co-authored-by`のような表示を付けるのは大前提として、それでも単一のコミットに一人の作者が一対一対応する代わりに複数の作者が対応することで、どの差分が誰によるものなのかについての特定性のようなものが下がるのではないか……的な感じの気持ちですね（法律がそういうことを気にするのかは知らないけど）
たしかに個々の著者の具体的な変更を特定できなくなったら、コミットが含む範囲全体について列挙された著者全員がフルの権利を持っていると仮定して同意を取りにいくなり著者リストを管理するしかなさそう
AMD製CPUに複数の脆弱性 ～任意コード実行の恐れ - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1568658.html
> 深刻度はいずれも「High」と評価されている。同社は対策版のファームウェアへ更新するよう呼び掛けている（ただし、一部は未リリース。2024年3月を目標に準備中）。
あれまあ
このアカウントは、notestockで公開設定になっていません。
ISO ｲﾐｯｼﾞ化して少しずつ実家に移動している (ので、実家の自室の本棚が大変なことになってきている)
