orange @[email protected]

あることをする時に「これは今回だけにしか役にたたないんでは？＞＜」って疑問に対しての考えの対立でもあるかも＞＜ worse is betterの是非＞＜

うん＞＜； でもそれはhttpに依存するし、サイズだけを解決する手段で汎用性がないよね＞＜；
ってことで(toot読む前に)張ったworse is betterの話が＞＜

＞＜ -- The Rise of "Worse is Better" http://chasen.org/~daiti-m/text/worse-is-better-ja.html

ていうかこういう抽象化の話をする時に、こういう風にお世辞抜きに間違いなくオレンジと比べ物にならないほどに腕がいいプログラマの人と話してても、必ずオレンジが抽象化汎用性再利用性原理主義モンスターみたいなポジションになっちゃうの、前からすごく謎＞＜
(抽象化して汎用性を持たせて二度と同じ作業をしないで済むように再利用性を考える、楽をする為にはどうすればいいのかという点に対して最大の努力をする人がプログラマらしい人だと思ってるからすごくすごく謎＞＜)

審査員のえじょさんが居ない・・・・＞＜

オレンジのこの話、おもしろい部分に穴があるからそこを突いたツッコミしてくれる人が現れたらすごくおもしろい＞＜；(その穴の先はちゃんと考えがまとまって無いから、議論しながら考える事ができそう＞＜)

"アップロードの"特にサイズに限るのも状況に依存した発想で、汎用性に背を向けた、抽象化とは逆の発想かも＞＜
「マストドンのファイルのやり取りに限った話にせずに、汎用的なファイルの許容ポリシー記述規格(？)を作るべき」ならわかるけど＞＜(それはたしかに下の層ではある＞＜)

x括弧無いの
o括弧内の

・・・って括弧無いの記述を考えるとますます下のレイヤに直接実装するとぐちゃぐちゃになるしアレかも＞＜

途中で蹴った方がいいけどその上で蹴られるかを知る方法が投げるまでわからないのは、マストドンのAPIのレイヤで考えて親切ではないというかなんというかだよね＞＜
(サイズだけじゃなく、他のポリシーの情報も投げてもいいかも＞＜ アスペクト比が極端なものは受け入れないとか＞＜(勿論クライアントは必ず全てを読む必要は無くて、あんまり無駄に投げたくないと思ったら対応すればいいかも＞＜(蹴られた時の理由の統計をとるのもいいかも？＞＜)))

これっぽさ・・・＞＜ -- API to get server constants (toot length, ...) · Issue #4915 · tootsuite/mastodon · GitHub https://github.com/tootsuite/mastodon/issues/4915

よくわかんないけど、例えばどこかのうっかりさんが「gif動画をマストドンに載せよう！＞＜」って数百GBのファイルを投げつけて数時間後に鯖に「ファイルは受けとりました。でも大きすぎるのでのせられないです」って言われるのがスマートなの？＞＜
(あくまで例で、実際は限界以上流れたら切ればいいから許容する容量が通信速度に対してとても小さいのならばアレだけど＞＜)