祖父はなぜか1番と4番だけ歌ってて、実際に体験した戦場の状況がだいたいこの歌の通りって言ってた＞＜
祖父はなぜか1番と4番だけ歌ってて、実際に体験した戦場の状況がだいたいこの歌の通りって言ってた＞＜
各国の軍歌が紹介される中、日本の軍歌がなにかおかしいと話題に - Togetter https://togetter.com/li/2311310
オレンジの祖父も酔っぱらうとそういう方向性の軍歌をいくつか歌ってたけど、いま考えると、たしかにネガティブな歌詞の軍歌って(効果が)意味不明かもって思って祖父が歌ってた軍歌をググったら
戦友 (軍歌) - Wikipedia https://ja.wikipedia.org/wiki/%E6%88%A6%E5%8F%8B_(%E8%BB%8D%E6%AD%8C)
"...「この軍歌は厭戦的である」として人々が歌うことが禁じられ、陸軍も将兵がこの歌を歌う事を禁止した。..."
"...太平洋戦争中「戦友」は禁歌だったが、下士官・古参兵は「今回で戦友を歌うのをやめる、最後の別れに唱和を行う。」と度々行い、それを士官・上官によって黙認された場合もあり、兵隊ソングとして認知されていた。..."
本当は戦地で歌ったらダメな歌だったのか！＞＜；
重くないゲームをフルHDで30fps程度で遊ぶならこれっで十分遊べそう＞＜
[B! PC] 【本日みつけたお買い得品】Ryzen 5 5560U搭載ミニPCがN100の価格に迫る？3万9,840円に https://b.hatena.ne.jp/entry/s/pc.watch.impress.co.jp/docs/news/todays_sales/1567674.html
べつに DRY 原則が雑だからといって重複が正義とは誰も言ってなくないですか……
新型コロナの接触どうのアプリのコードも、DRY原則に反しまくりまくってる典型的な事例っぽすぎてオレンジがビックリした事例＞＜
https://mstdn.nere9.help/@orange_in_space/104370427853816677
型を明示的に書く事ですらDRY原則に反すると主張してる人が作った言語のユーザーが「安全の為にはある程度冗長さが必要！＞＜ 明示的な記述は素晴らしい！＞＜ スイスチーズモデル！＞＜」って人(→＞＜)に「これ、DRY原則に反してるんでは？＞＜；」って言われるコードを書くの、世の中不思議＞＜(？)
実験用コードはオレンジもハードコーディングだらけのガバガバコードで書くので恥ずかしくて人に見せられないけど、本番のコードは最初からちゃんと設計して書いて欲しい＞＜；
こういう書き方って、webp云々に限らず変更に強くするってこういう事じゃないの？＞＜
RubyとかPythonとかの型がガバガバな言語が好きな人々って、変更に強くするのが好き(「だから動的型付け環境は強力だ」って主張)だったんじゃないの？＞＜；
適切な英語調べるのめんどいのでわざと馬鹿っぽい日本語で例示するなら、
例えば、どこかに gazou_support_keisiki_override.rbみたいなファイルを用意してあって、そこのコメント解除してファイル形式のリストを一度そこで書き換えれば、次からはそこさえ弄ってなければサポート形式が変更されないとか＞＜
こういうスクリプト言語でのセキュリティ上問題ない使い方はよくわかんないので、セキュリティ面は謎だけど、
こういうの設定ファイル自体がjsonとかxmlじゃなくRubyのソースコードにしておいて、そこの画像サポート形式のリストを作る所だけ書き換えて置けば、アップデート後でもそこさえ書き換えて無ければ対応形式も変わらないように作れそうだけどどうなんだろう？＞＜
ていうか、Matz氏って極端なDRY原則支持者じゃん？＞＜(Matz流のDRY原則が元の意味に沿ってるか細かい定義論わからないけど＞＜)
という事は(と言うかRuby関連の色々な記事を読むと)、Ruby好きな人ってDRY原則大好きじゃん？＞＜
マストドンの画像形式サポート部分って明らかにハードコーディング的でありなおかつDRY原則的では無いコードじゃん？＞＜(見かたによってはシンプルと言えなくもないけど)
マストドンのコードに貢献してるRuby使いの方々は「うぉぉぉ、そんな書き方しないで・・・」ってならないの？＞＜；
マストドンのwebp追加のコード読んでて思ったけど、ローカライズ部分はまああれだけど、なんであらかじめサポートするファイル形式のMIMEタイプと拡張子を一ヶ所書いておけばサポートする形式を変更できるコードになってないのか？＞＜；
Rubyが悪いのかオイゲン氏が悪いのか知らないけどなんでこんなハードコーディングなコードなの？＞＜ 涙ぐましい高速化？＞＜；
Add WebP support by acid-chicken · Pull Request #9879 · mastodon/mastodon · GitHub https://github.com/mastodon/mastodon/pull/9879
読み方わかんないけど、パッと見では数行書き換えてMIMEタイプ追加しただけっぽさ＞＜
ていうか、オレンジが実験コードって言ってるものがロジックだけ考えてとりあえず試験的に動く部分を書く段階で、それに基づいてインタフェースを考えて本番コードを書いていく感じかも＞＜
このアカウントは、notestockで公開設定になっていません。
放言するなら「ロジックを先に考えるから滅茶苦茶になるんだろ、インターフェースを丁寧に設計しろ」という感じなんだが、これはたぶん流儀の違いみたいなところが大きくて大いに反発を受けそうなので、大声で言えるかというとちょっと……静かに暮らしたいので……
独立したコードであるべきか、同じものとして抽象化すべきか、そういうのはコードやモジュールに負わせる責任を見て決めるべきなのであって、コードが文字列的にどれくらい近しいかで決めるべきではない
はっきり言って DRY とかいう原則が雑すぎるので素直に従うべきか疑わしい場面がとても多い
このアカウントは、notestockで公開設定になっていません。
ｼﾞｬﾊﾞの統合開発環境ってやつ、近年の language server 系のあれこれでマシになってたりするんですかね。というかｼﾞｬﾊﾞで実装するのやめるだけでメモリ消費軽くなったりしない？ (まああの界隈みんなｼﾞｬﾊﾞで実装したがるだろうけど)
それUNIX野郎どもは「エディタごときがメモリを何GBも食ってんじゃねえよJava頭が」と思ってるよ
あと「機能追加していくと巨大なクラスになる」って、むしろリファクタリングすれば巨大なクラスがより小さなクラスの集合になりつつ、手っ取り早く同じようなコードを複数回書いちゃってた部分もDRY原則な感じにまとまっていくじゃん？＞＜
むしろちゃんとした設計前の最初の検討用に書く実験コードが(手抜きするので)一番巨大なクラスになるじゃん？＞＜
継承はなんでダメ？ - まめめも https://mametter.hatenablog.com/entry/2024/02/10/120527
この事例なら、Clockクラスを非推奨にした上で
ClockBase→AnalogClock→Clock(非推奨)
ClockBase→DigitalClock
みたいな構造にするかも＞＜
ていうか、「継承が使われてると実装がどこに書いてあるかわかりにくい」なんて、「ショボいエディタを使うからそんな事になるんだろ、まともなIDEを使えやUNIX野郎どもめ＞＜」って思う＞＜(素直な感想)
こうらしい・・・＞＜
usb c - USB-C How to detect an Audio Accessory with Charge Through - Electrical Engineering Stack Exchange
https://electronics.stackexchange.com/questions/348952/usb-c-how-to-detect-an-audio-accessory-with-charge-through
