新しいものを表示

64bit版RIFFのようなもの、基本的な型とかも規格化したら気持ち良さそうだし、本当に汎用的に(それこそバイナリ版のJSONのように)使える部分とは別に、将来公式な規格の例えば画像とかのフォーマットとして使う時に衝突しないように予約しておいたら、将来性もいい感じかも><

テキストでのデータフォーマットは色々あれだけどバイナリの汎用フォーマットみたいなのが現れないのがアレ><(64bit版RIFFみたいなのが規格化したら便利だと思うんだけど><)

C# わりとあちこちDelphi><(?)

DelphiのVCLもわりと全部入り><(の上に標準では静的リンクさせて単一バイナリに!って方針だったのでバイナリがデカかった・・・><)

orange さんがブースト

(.netは標準ライブラリが充実しすぎでは)

C# のライブラリが依存地獄にあんまりなら無いの、.NET Framework&Windows(の標準コンポーネント?)が多機能だからだけなのかも?><

ていうか、C# 辺りの便利なライブラリのうちオレンジが使うような分野のもの、便利なライブラリ自身は標準ライブラリしか使ってないのが多いかも>< (JSONが関わるとNewtonSoft Json.NET?><;が出てくるとかあるけど><;)

orange さんがブースト

教訓を引き出すなら

・標準ライブラリを使え
・標準にある機能を敢えて外部に頼りたいならオプトインにしろ
・必要性を確認せず雑に機能や依存を増やすな

という感じになると思うんだけど……

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

あとさっきの POSTD の記事、まとめが強調のためか雑過ぎてアカン

OSSなもののドキュメントの著作権(あえてライセンスとは書かない)、わりと書く側も適当だと思う(想像)し、適当でいいんじゃないのかなって気がしなくもない><

"別の文脈で"の方の文脈はこういうの><
依存関係をなくそう : Rubyアプリ・Gemの開発者への提言 | POSTD postd.cc/kill-your-dependencie

ソフトウェアのガラクタの寄せ集め云々のオレンジの文脈、依存するソフトウェアを複数手動でインストールさせるのであれば、ガラクタの寄せ集めって言っていいと思う><
(あと、別の文脈で、依存ソフトウェア(/ライブラリ)が依存するソフトウェアが依存(以下略)みたいに依存構造がものすごく誇大化してスパゲティなやつもガラクタの寄せ集めと言えるかも><)

なんだかよくわからないLED制御チップとか、なんだかよくわからないオルゴールICとか、なんだかよくわからない表示デバイスとか><

ソフトウェアは微妙だけど、電子部品は技術資料が中国語しかないやつって結構ちらほらあるかも?><(あれ偶然にも英語圏の人よりも漢字文化圏である日本人の方が有利だよね><)

オレンジはなに語でも読めないので気にしないで使ってる><(?><)

マジレスすると、Google翻訳で英訳(&ググって辞書ひく)して読める言語のならあんまり気にしないで使ってる><(Google翻訳、日本語に翻訳はめちゃくちゃ過ぎて使い物になら無いから英訳><;)

orange さんがブースト

べつに一次ソースが読めないものを使うのも好きにすればいいんだけど、それがリスクであることは意識しておくべきなんだよね

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

たとえば気になるソフトウェアでドキュメントの非公式日本語訳や日本語解説があったとしても、 README その他諸々が公式でアラビア語(ここはあなたの読めない言語)しか用意されていなかったとして、私はそれを使う気になれませんね

スレッドを表示

ていうか、変化しまくりというか、現状ガラクタの寄せ集めであってちゃんとひとつのソフトウェアと言えるようになってないのが何より悪いし、そういうの当たり前だと思ってるUNIXの文化が悪い><(開発者からのみのシンプル志向主義のせい><)

orange さんがブースト

変化が早すぎてブログ記事じゃ追いつかないからディスコードとか公式ドキュメントとか頼みにならざるを得ないというやつなので日本語訳は更新してゆくの大事だと思う(どこまでサポートできるかはやる気次第みたいな

古いものを表示
:realtek:

思考の /dev/null