Firefox でタブ開きまくって Thunderbird をビルドしたらメモリ食いつくしたのかハードウェア不調かわからないがハングして30分くらい戻ってこないので仕方なく強制電源断
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
Firefox でタブ開きまくって Thunderbird をビルドしたらメモリ食いつくしたのかハードウェア不調かわからないがハングして30分くらい戻ってこないので仕方なく強制電源断
やっぱメモリは 64 GB いるな……
今のメインのデスクトップﾏｯｽｨｰﾝをサーバに転用するかなと思い始めています (というのもハードウェア不調 <https://mastodon.cardina1.red/@lo48576/109540665105977682> は discrete GPU がないと鳴りを潜めるため)
ところで: 未開封の Ryzen 9 7950X が自宅に転がっているのですが……
デスクトップ機 (atri) と未開封 7950X を chuable に投入して5台クラスタとして 9950X あたりでデスクトップ機を組み直すのがプラン1、デスクトップ (atri) と Xeon (未購入) を chuable に投入して余った 7950X で新しくデスクトップ機を組むのがプラン2
クラッシュしなけりゃ当面耐えられるんだがなぁ。結局原因がわからんのだ (メモリでエラーを検出できて GPU でエラーを消せて CPU 設定で状況を安定させたため、メモリ/CPU/GPU/マザーボードのどれが原因の可能性も否定できない)
https://mastodon.cardina1.red/@lo48576/113153702113671541
ちなみに OOM Killer がちゃんと機能していると、なんだかんだでしばらく (数分ですまないこともあるが) 待っていると firefox あたりが殺されて制御が戻ってくる
サーバ用にログ収集サービスを立ててデスクトップ機からも systemd-journal を流すべきなのかもしれん……
https://youtube.com/watch?v=1bbEgTnqogI&t=4830s
大昔に Portal with RTX をひととおり触ってみて改悪を全編愚痴りまくってた動画を見ているが、今見ても着眼点と感想が100%の同意しかなくて共感の化け物になってしまった
そして音量バランスがゴミなので発言の4割くらいは聞き取れない、なぜなら自分用の録画で音量確認をしていないため (でもどうせ共感で何言ってるかわからなくても言いたいことはなんとなくわかる)
We’ve made the hard decision to end our experiment with Mozilla.social and will shut down the Mastodon instance on December 17, 2024. Thank you for being part of the Mozilla.social community and providing feedback during our closed beta. You can continue to use Mozilla.social until December 17. Before that date, you can download your data here (https://mozilla.social/settings/export), and migrate your account to another instance following these instructions (https://support.mozilla.org/en-US/kb/mozilla-social-faq).
Mozilla Social FAQ | Firefox Help
https://support.mozilla.org/en-US/kb/mozilla-social-faq
https://mozilla.social/@mozilla/113153943609185249
2024-12-17 に mozilla.social サ終、まじか
This account is not set to public on notestock.
HDD も高くなったよなぁ……あと2玉くらい12TBのが欲しかったけどさすがに当面無理だわ
無理すれば出せるが他に優先したいことが多すぎる
This account is not set to public on notestock.
Apple Music、音量バーをクリックした瞬間にAirPlayのアイコンが生えてきてバーが左にずれるせいで音量のつまみが相対的に右に移動して音量100%になるのやめてくれ
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
外は暑いし午前起床はできないし眠りは浅いし夜は降るらしいし
帰ったときの室温を想像するだけで今から憂鬱ですよ
帰宅時点での弊宅のメインデスクにおける室温の予想
米国、エレベータで知らん人に話しかけられて雑談したのびっくりした。本当に沈黙の文化じゃないんだなと実感した
しかのこ、3話までは観たがノリが合わずリタイア。 OP 曲だけ聴いていればいいやとなった (?)
そんな尖ったアニメを試金石にしなくてもという気持ちはなくもない (いやある意味ではスタンダードといえばそうなのかもしれんが)
herschel@raptol.net
This account is not set to public on notestock.
私的かつ統合された高度な通知、どのチャネルでやるか悩んでいる。
matrix 自前鯖とか立ててそこでやるか、自前 mattermost サーバとかでやるか、 Mastodon に bot 立てて集約するか、なにかもっと軽量な自前 ActivityPub 鯖を用意するか、 ntfy でいくか……
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
まず前提としてシリアルな番号などでなく乱数を使えば確率的な重複の可能性はあるので「良心的なベンダーによる MAC address の重複がありうる」は真だし、そのうえで「だからといって恒常的にユーザの手元で競合が起きるリスクを気にしないベンダーは邪悪」も同時に真
乱数を使うことを正当化できるかはまた別の話だが、たとえば MAC address から製品のシリアル番号を推測できる可能性があるとセキュリティリスクになったりユーザの不利にはたらく可能性はあるだろうし、個人的には正当化できると思う
ハードウェア製品でなく仮想化プラットフォームの仮想 NIC とかだとマジの乱数使ってたりするし、まあそりゃ現実的には競合リスクあるので規格としてはそのリスクは認めざるを得ないだろうなぁという感想
MACアドレス、一旦ベンダー部とかを無視してMACアドレスが必要な全世界の端末に00:00:00:00:00:01から振っていったとして、256の6乗で足りるのかな、足りんのではないか？ (まあ現実的にはLAN内で被ってなければいいのでそんな困らんだろうが)
48ビットなぁ、ざっと3×10^14くらい？
帰宅時点での弊宅のメインデスクにおける室温の予想
誕生日のパラドックス、たしか N が十分大きいとき N 個の ID から n 個選んで50%の確率で衝突する個数は n = √N とかだっけ (うろおぼえ)
No.325 - 高校数学で理解する誕生日のパラドックス
https://hypertree.blog.ss-blog.jp/2021-11-27
> n 通りのパターンがあるものを 約 1.177√n 個集めると、一致するペアが存在する確率が 50% を越える
近似だけど、なるほど
> n 通りのパターンがあるものを約2.146√n 個集めると、一致するペアが存在する確率が 90% を越える。
>
> 「一致するペアが存在する確率が 50% を越える個数」の約1.8倍の個数を集めると、確率は 90% を超えて、ほぼ確実に一致するペアが存在する。
超ざっくり完全ランダムだとしても 1 万台ぐらいネットワーク機器を集めたら MAC アドレスがかぶる確率が 9 割ぐらいいくのか
This account is not set to public on notestock.
まあ 24bit 完全ランダムの仮定だから実際には同じベンダーから大量に仕入れてるとかならもっと小さい規模で全然起きそうではある
ローカルでやるとドライバかカーネルに拒否されそう (あるいは狂うか)
社のﾏｯｽｨｰﾝのロック画面を xkcd#303 にしているのでいつも笑顔になる
This account is not set to public on notestock.
Slack のアイコンを気紛れで 
にしていたのだが、「新入社員とか顔と名前一致しないだろうし、強制ではないけど顔写真にしてくれると嬉しいな」的なアナウンスがあり笑ってしまった (いやべつにいいけど)
労役でキモ・アイコン使ってんじゃねえよ、それはそう
This account is not set to public on notestock.
さすがに洒落にならないし原理的には任意のドメインで発生しうる事案なので笑えない
フェディバースっていうカタカナ表記、実際に日本でFediverse使ってる人はあんまり使わないんじゃないかな。メディアとかは使いそうだけど。
日本語圏のMastodonやMisskeyなどFediverse使ってる人に質問。
Fediverseのことをどう書く？
ﾍﾃﾞﾊﾞｰｽなどと書くこともある (?)
なんか主観と客観という観点 (あるいは言葉) をこの話題で持ち出すのはしっくり来ない。結局コードの文脈での価値観の差異は重視するものの優先度と比重の問題に帰着しそうな気がするので
優先度と比重は上から明確に降ってくることもあればぼんやりしたものだけが降ってくることもあるし、あるいは単にぼんやり共有されていたり共有すらされていなかったりもするけど、それはチームとプロジェクトの性質次第
[このスレッドは単なる思考ログ]
まず「良いコード」を論ずるうえで「動的な良さ」と「静的な良さ」があるような気がする。
前者は「時間をかけて開発を進める (コードを維持・改変する) 行為の体験の良さ」に貢献し、後者は「ある時点における特定のコードを把握・理解する体験の良さ」に貢献する。
別の表現をすると、前者はプロジェクトやコンポーネントへのメンバーによる継続的な貢献を助け、後者はメンバーのプロジェクトやコンポーネントへの新規貢献を助ける。
で、私はこれらは対等でなく非対称性があると思っている。前者は硬直した文脈を継承して更に硬直が進むフィードバックがはたらきやすく、そして後者はしばしば前者を代替しうる。
「動的な良さ」はコード自体の更新を助けるにも拘らずワークフローなどメタなレベルでの更新を妨げる性質を持ちやすく、逆に「静的な良さ」は継続的に貢献しているメンバーによるさらなる貢献を助けることができる。
具体例を書くべきだがその余裕が今ないので続きは後で。
再び2週間完全ひきこもり生活の準備をした。週1未満外出を目指します
「静的な良さ」には特殊な状況を想定せず一般論として言われているものが概ね該当すると思われ、たとえばコメントに why not を書けとか関数を動詞で命名しろとかテストは確認したい性質ごとに細かく作れとか異なる意味を持つオブジェクトの型は互換性をなくせとか、そういうやつ
一方「動的な良さ」は開発プロセスで遭遇した具体的な問題へのワークアラウンドとして評価されるもので、たとえばファイル先頭にコメントで変更履歴を入れろとかコンパイルが遅くなるから多態を使うなとか変数名やフィールド名を日本語にしろとか特定のフレームワークを使えとか、そういうやつ
帰宅時点での弊宅のメインデスクにおける室温の予想
https://mastodon.cardina1.red/@lo48576/113156583292709441
予想的中！ 35.0℃ 55% でした
こうして説明してみると、動的/静的というよりは「文脈依存な良さ」「文脈自由な良さ」と表現すべきだったかもしれんな。以後そう呼びます
「とにかく今使えること」みたいなのも、無理のある期限までに一定の成果が必要というある種の特殊な文脈のもとでのみ評価される「良さ」なので、文脈依存の良さにカテゴライズできる
で、どの (或いはどちらのカテゴリの) 良さに比重をおいて評価するかはもちろん文脈によりけりなのだが、個人としてのプログラミングの学習で習得を人におすすめするなら、やっぱり「文脈自由な良さ」になると思う。
「文脈依存な良さ」の生産への適合は「文脈自由な良さ」への十分な理解の上でトレードオフに納得して行われるべきだし、なんなら文脈はプロジェクトやチームに固有なことが多いので事前学習の効率が悪い。
そして何より、文脈は変化しやすいのに「文脈依存の良さ」の規定は硬直しやすい。
というわけで、人に (あるいは特に初学者に) 良いコードとは何かを問われたなら、まず2種類のカテゴリの「良さ」があることを踏まえて、基礎として文脈自由な良さを学ぶのが望ましいとしたうえで、ではそれは具体的に何なのかということを説明するかな。私なら。
……ここまでが抽象論で、具体的に文脈自由な良さとはどのようなことなのかを書かないといけない。
個人的な信念として、良いコードを書くというのは概ね「情報を受け取りやすいように伝える」と「誤りにくくする」の二点が本質であると思っている。
具体的には前者は「どのような結果を期待するかわかりやすい」と「そのような方法でそのような結果を求める意図がわかりやすい」に分解され、後者は「読み取るときに勘違いしづらい」と「編集するとき/したあと誤りに気付きやすい (可能なら『確実に気付ける』)」に分解される。
「どのような結果を期待するかわかりやすい」というのは、たとえば以下のようなもの。
* 適切な (一貫した明快な) 命名
* 何をしているのか理解できるコメント
* データの流れや処理の流れが読み取りやすい制御構造
* 何が正常で何が異常なのかを読み取りやすい制御構造 (early return や monadic な操作など)
* ロジックの本質に関与しない項目の一般化
* 値の性質や役割に応じた型の分離と使い分け
「そのような方法でそのような結果を求める意図がわかりやすい」というのは、たとえば以下のようなもの。
* 読み取れる「何をしているか」の粒度を揃えるための、抽象化による細部の隠蔽
* 常に満たされることを期待する制約の assert による表明
* 制約を常に満たすための、より特化した制御構造の利用
* 「何故他の方法にしなかったのか」を説明するコメント
「読み取るときに勘違いしづらい」というのは、たとえば以下のようなもの。
* 適切な (一貫した明快な) 命名
* 何が起きるべきか、何を期待しているか理解できるコメントやドキュメント
* 関数や型やモジュールの、適切な大きさと揃った粒度での分割
「編集するとき/したあと誤りに気付きやすい (可能なら『確実に気付ける』)」というのは、たとえば以下のようなもの。
* 変更されない変数の const 化
* 値の性質や役割に応じた型の分離と使い分け
* 常に満たされることを期待する制約の assert による表明
* 制約を常に満たすための、より特化した制御構造の利用
* lint の利用や警告の解消
* 機械可読な形でのメタデータの付与 (必ずしも実行時の動作に影響する必要はない)
もうちょっと具体例を挙げると、
【データの流れや処理の流れが読み取りやすい制御構造】
goto でスパゲッティにするな。
一時変数を作りまくって放置せず、こまめにスコープを切って “生きている” 変数を少なくしたり、メソッドチェーンでデータの流れを固定して処理の列に注目しやすくしろ。
仕事が済んだらさっさと return しろ。なが〜い else if を挟んだりして return を後回しにしたりするな。
【何が正常で何が異常なのかを読み取りやすい制御構造】
不正な入力や条件を扱っているのか、正当ではあるが適切に処理できない場合を扱っているのか、正当で主目的を遂行できる場合を扱っているのかを読み取りやすくしろ。特に、主目的を遂行している場合のコードを関数の主役にすること。主目的を遂行できない場合のハンドリングは if(だめな条件) で early return したり .and_then(さらに適用する関数) したりなどの書き方で関数や処理列の主流から早々に外すこと。
【ロジックの本質に関与しない項目の一般化】
「int のスタック」と「float のスタック」と「string のスタック」みたいなのを個別に実装せず「型パラメータTのスタック」を用意しろ。
(そうして内部実装を共通化したうえで、次の段階として同じ文字列のスタックでも役割が違うようなものは互換性のないような wrapper 型を用意するなどすると更に良いが、それはまた別の項目。)
【値の性質や役割に応じた型の分離と使い分け】
時間感覚と距離と質量をぜんぶ float で扱おうとするのをやめてそれぞれに型を定義しろ。というか primitive obsession をやめろ。
時計上で表示されるようなタイムゾーンを明示しない「時刻」と、特定の時点を指すためのタイムゾーンと暦が紐付いた「時刻」とを、ちゃんと区別して別の型にしろ。というか片方しか使わないとしても、その「時刻」がどれなのかはっきりわかるようにしろ。
変化しない値をちゃんと const にしろ。
【常に満たされることを期待する制約の assert による表明】
「こうなっているはず」をコメントや内心で済まさず assert を書け。そもそも assert をたくさん書きやすいような述語や変数や制御構造を整えろ。
【制約を常に満たすための、より特化した制御構造の利用】
「同じようなコードを繰り返す」ためには、 goto よりも for や while が望ましい。なぜなら goto は異なるコードの実行に使えるが for や while はそのように使いづらいから。
「リストやストリーム中の要素を絞り込む」ためには、 for や while によるループよりも .remove_if() や .filter() のような専用メソッドだったりイテレータ用関数を使うことが望ましい。なぜなら for や while では要素数を増やすことができるが remove_if や filter ではそれができないから。
リソースの破棄には、 goto や後始末の直書きよりもデストラクタとスコープを使った方法が望ましい。なぜなら(以下略)
(<https://mastodon.cardina1.red/@lo48576/104076550802534677>)
あくまで条件の具体例の、その実践のさらなる具体例の一部なんだけど、たとえばこういったことです
https://mastodon.cardina1.red/@lo48576/113158870472561226
で、何の話だったかというと「情報を受け取りやすいように伝える」と「誤りにくくする」とはどういうことなのかという話だったんだけど、つまり私は「文脈自由な良さ」の本質であるこの二点をできるだけよく満たすようなコードが、一般的にあるいはある程度普遍的に “良いコード” である、と評価しますということです
一方で、プロジェクトやチームの都合でしばしばこういった「文脈自由な良さ」に逆行するものを良しとする/せねばならない場合があり、たとえば以下のような例が考えられる。
* 開発インフラが (相対的に) 貧弱なので多態を利用した抽象化をできるだけ避けるべし
* 実行環境が貧弱なので必ず成功するはずの検査は省くべし
* 時間がないのでコメントは省くべし
* メンバーが貧弱なので特化した制御構造の利用を避けるべし
* メンバーが貧弱なので抽象化を避けるべし
* メンバーの適合コストを支払えないのでマルチパラダイム的な記述を避けるべし
* 既存のコードが破綻気味で改善する余裕もなく、 lint はまともに利用できないので避けるべし
こういう「文脈依存の良さ」は特定の状況においては正当化できることもあるけど、あくまでそれは「特定状況における運用上の都合で楽になるようにルールを設定した」だけであって一般に実践すべきではないといえるものが多いと思われる……が、それはそれとして適合が必要になることはある。現実は汚く人々は常にリソースに飢えているからね。
で、最終的に「良いコード」はどんなコードですかという問に対して私なら「『情報を受け取りやすいように伝える』コードで、また読解や編集を『誤りにくくする』コードである」 <https://mastodon.cardina1.red/@lo48576/113158870472561226> と考えているし、これ以外の「他人が “良いコード” だと言っているが私としては特定の文脈への固定なしに同意しかねるような性質」は <https://mastodon.cardina1.red/@lo48576/113159085569557674> にカテゴライズされていわゆる二級市民の “良さ” と見做します (ので必要になってからでいいし常時実践はおすすめしません)、というのが答えです。
おしまい。
なあ、ワイが一度でもロシア語をまともに読み書きできるかのような発言をしたことがあったかね。記憶にないならなんでわざわざロシア語でメンションしてくるねん
中身もわからないものをメンションで注意を引いて私にリソースを払わせながら解読させようとするのは随分と傲慢じゃないかね。しかもよくわからんリンク付きときた。そもそもあんた誰だよ、信用もできないのにそんなにコスト払うと思うか？
べつにそれが普遍的な悪行だと言うつもりは全くないが、私にとって十分に目障りなのでブロックです
@omasanori
/ || :ヽ
┌|（⌒ヽ :|| ..:⌒: |┐ ／￣￣￣￣￣￣￣
|::|::ヽ.__:）:||（___ノ ::|::| │
|:|: .. :|| .. |:| │
:|: .. || ..|| ＜ @omasanori 日本語でおｋ
:＼ ［_￣］ /::| │
:: |＼|_|_|_|_／:::| ＼＿＿＿＿＿＿＿＿
＿＿| | / / :|＿＿＿
