新しいものを表示
orange さんがブースト

適切な英語調べるのめんどいのでわざと馬鹿っぽい日本語で例示するなら、
例えば、どこかに gazou_support_keisiki_override.rbみたいなファイルを用意してあって、そこのコメント解除してファイル形式のリストを一度そこで書き換えれば、次からはそこさえ弄ってなければサポート形式が変更されないとか><

orange さんがブースト

こういうスクリプト言語でのセキュリティ上問題ない使い方はよくわかんないので、セキュリティ面は謎だけど、
こういうの設定ファイル自体がjsonとかxmlじゃなくRubyのソースコードにしておいて、そこの画像サポート形式のリストを作る所だけ書き換えて置けば、アップデート後でもそこさえ書き換えて無ければ対応形式も変わらないように作れそうだけどどうなんだろう?><

orange さんがブースト

ていうか、Matz氏って極端なDRY原則支持者じゃん?><(Matz流のDRY原則が元の意味に沿ってるか細かい定義論わからないけど><)
という事は(と言うかRuby関連の色々な記事を読むと)、Ruby好きな人ってDRY原則大好きじゃん?><
マストドンの画像形式サポート部分って明らかにハードコーディング的でありなおかつDRY原則的では無いコードじゃん?><(見かたによってはシンプルと言えなくもないけど)
マストドンのコードに貢献してるRuby使いの方々は「うぉぉぉ、そんな書き方しないで・・・」ってならないの?><;

orange さんがブースト

マストドンのwebp追加のコード読んでて思ったけど、ローカライズ部分はまああれだけど、なんであらかじめサポートするファイル形式のMIMEタイプと拡張子を一ヶ所書いておけばサポートする形式を変更できるコードになってないのか?><;
Rubyが悪いのかオイゲン氏が悪いのか知らないけどなんでこんなハードコーディングなコードなの?>< 涙ぐましい高速化?><;

orange さんがブースト

Add WebP support by acid-chicken · Pull Request #9879 · mastodon/mastodon · GitHub github.com/mastodon/mastodon/p

読み方わかんないけど、パッと見では数行書き換えてMIMEタイプ追加しただけっぽさ><

ていうか、オレンジが実験コードって言ってるものがロジックだけ考えてとりあえず試験的に動く部分を書く段階で、それに基づいてインタフェースを考えて本番コードを書いていく感じかも><

orange さんがブースト

まぁ,誰しもインターフェースからトップダウンで作り始められるものじゃないし,リファクタリングで整理していくしかないのかなと思う

orange さんがブースト

放言するなら「ロジックを先に考えるから滅茶苦茶になるんだろ、インターフェースを丁寧に設計しろ」という感じなんだが、これはたぶん流儀の違いみたいなところが大きくて大いに反発を受けそうなので、大声で言えるかというとちょっと……静かに暮らしたいので……

orange さんがブースト

独立したコードであるべきか、同じものとして抽象化すべきか、そういうのはコードやモジュールに負わせる責任を見て決めるべきなのであって、コードが文字列的にどれくらい近しいかで決めるべきではない

スレッドを表示
orange さんがブースト

はっきり言って DRY とかいう原則が雑すぎるので素直に従うべきか疑わしい場面がとても多い

orange さんがブースト
orange さんがブースト

ジャバの統合開発環境ってやつ、近年の language server 系のあれこれでマシになってたりするんですかね。というかジャバで実装するのやめるだけでメモリ消費軽くなったりしない? (まああの界隈みんなジャバで実装したがるだろうけど)

スレッドを表示
orange さんがブースト

それUNIX野郎どもは「エディタごときがメモリを何GBも食ってんじゃねえよJava頭が」と思ってるよ

あと「機能追加していくと巨大なクラスになる」って、むしろリファクタリングすれば巨大なクラスがより小さなクラスの集合になりつつ、手っ取り早く同じようなコードを複数回書いちゃってた部分もDRY原則な感じにまとまっていくじゃん?><
むしろちゃんとした設計前の最初の検討用に書く実験コードが(手抜きするので)一番巨大なクラスになるじゃん?><

継承はなんでダメ? - まめめも mametter.hatenablog.com/entry/

この事例なら、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
electronics.stackexchange.com/

orange さんがブースト

そういえばアレどういうピン配置なんだ?

Type-Cに普通のイヤホンをつなぐ変換ケーブルじゃなく、その逆の(DAC無しの)Type-Cコネクタ接続のイヤホンを普通のステレオミニプラグで使うアダプタケーブルって無いのかな?><
あったら本来の目的じゃなく、ボリューム付きオーディオ延長ケーブルとか自作する時に、ケーブル交換可能で薄型のを作るのに使えるかもって思った><

古いものを表示
:realtek:

思考の /dev/null