裸眼立体視？＞＜　は、真ん中に紙かなにかで反対側が見えないようにすると見やすいかも＞＜

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

家のなかで木を育てて、木こりMOD無しの時は、家の内側の梯子とかで木の上に登って、上から掘り下げて(？)回収してる＞＜

めちゃくちゃ太い木を作る方式だと密度が高いから、家の天井の高さをちょっと高くしておけば、家の中でかなりの量の材木確保が出来るという利点も＞＜

オレンジハウスにある高い木？＞＜は、並べたんじゃなく、ジャングルの木(高く育つ種類)を普通に育てたあとに、木の上に土をおいてさらに苗木を植えて・・・って3本分くらい接ぎ木(？)した木＞＜

そうじゃなくオレンジが木材確保する時は、高い木じゃなくめちゃくちゃ太い木として育てる感じ＞＜

オレンジ方式のマインクラフトの林業(？)は、苗木を密集して植えて、とんでもない巨木を作って一気に伐採というかほぼ採掘？＞＜；　ってしてる・・・＞＜

マインクラフトでのオレンジの木材確保は木こりプラグイン使わない方式になれてるけど、いったことある鯖どこでも伐採場(？)方式で作られてる(？)からそこの木を借りることに・・・＞＜

内容は(全部読んだけど)ノータッチで、それよりもオレンジよりも長文の人がいることに驚いた・・・・＞＜；

このアカウントは、notestockで公開設定になっていません。

ちくわとかはんぺんってカレーのライス代用にならないのかな・・・？＞＜

建物じゃなく石碑・・・？＞＜

後ろの建物も気になる・・・＞＜

このアカウントは、notestockで公開設定になっていません。

ていうかこの村、洞窟みたいな部分をわきつぶししないとすぐに壊滅しそう＞＜

地形とほぼ無関係にバイオームのみで出来るんだったかも＞＜ 砂漠の断崖絶壁の村とか結構多いかも＞＜

オレンジが作ったトンネルに他の人の地下鉄が衝突してオレンジトンネルが縦方向に回避した事も＞＜；(その時は先に作ってたオレンジトンネルが突然塞がれてて「？？？＞＜；」って思ったけど文句言わずにオレンジが避けた＞＜)

あまり他の人の工事現場に近すぎると、しょんぼりして遠くに引っ越す人が発生しちゃう＞＜

マインクラフト、一応、他の人がなにか作ろうとしている場所ではないのか？は、地中でもある程度は気にした方がいいかも＞＜ 微妙な場所なら声かけるとか＞＜(地中だってもしかしたら誰かが工事してる地下鉄の予定経路かもしれない＞＜)

オレンジも最初から完璧はいくらなんでも無茶だと思うけど、例えばお約束のザッカーバーグのあの画像を見るとザッカーバーグをぶん殴りたくなる＞＜；

worse is better的発想であるUNIXを邪悪な敵と見なしてるカトラー(出典「闘うプログラマー」だけど細かい表現忘れた)は、最初から完璧に書くべき主義者かも＞＜
(さっきのRubyのWindowsで動かないってmatzが文句言った話も歴史を遡るとカトラー絡みの話だったりする＞＜(NTでは無くVMSの時だけど))
オレンジはカトラー好き＞＜；

このアカウントは、notestockで公開設定になっていません。

・・・・・・＞＜

超はしょると、将来楽ができるように勝手に将来の事まで条件に追加してしまうのがプログラマらしい人　では無いの？＞＜という疑問をずっと持ってる＞＜
(これだけ読んで意味不明だった人はひとつ前に長文を読んでほしい＞＜)

あることをする時に「これは今回だけにしか役にたたないんでは？＞＜」って疑問に対しての考えの対立でもあるかも＞＜ 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

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

このアカウントは、notestockで公開設定になっていません。

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

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

x括弧無いの
o括弧内の

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

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

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

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

このアカウントは、notestockで公開設定になっていません。

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

このアカウントは、notestockで公開設定になっていません。

実際にファイルを投げる前に「必ず蹴られるファイルであるか？」くらい知りたいのっておかしな発想では無いはず・・・＞＜(その上で「だいじょうぶかと思ったけどやっぱダメだった」はしょうがない＞＜)

画像のリサイズの話をしてけど、たぶん気づかれてない・・・・・＞＜

https://mstdn.nere9.help/@orange_in_space/98842164469513762 が先で
https://mstdn.nere9.help/@orange_in_space/98842155107064456
が後の方がよかったかも＞＜；

つまり上の図 かつ 下の図でなければ矛盾するし、複数の下層を意識するなら互換の為の層なり規格なりが必要かも＞＜

「下のプロトコルに依存していい」と「下の何らかの仕様には依存すべきではない」は矛盾する意見だし、共通化の為に仕様を下の層で整える事を要求すべきと言ったら、matzがWindowsがUNIXになればいいって言ってたのと同じかも＞＜

例えで言うなら(層はちがうけど)UUCPとか伝書鳩でもいいけど＞＜

少し強引だけど、下の図のAndroidとiOSの部分に代わりに例えばhttpとftpとか入れてみてほしい＞＜ オレンジが「下の層に依存するな」っていってるのはそういう意味＞＜

これの事ね＞＜ -- 「マイクロソフトを嫌っていたのではない、われわれが嫌われていたのだ」――Rubyまつもとゆきひろ氏が語る、MSの壁 - ITmedia NEWS http://www.itmedia.co.jp/news/spv/1606/08/news138.html

ていうかそういう意味でも、最初の方に例として出したRubyの(の実装の)UNIX依存問題って典型例かも＞＜ 依存しないものを作りたいのかそうじゃないのかさっぱりわからない＞＜ Matzは「WindowsがUNIXでは無いのが悪い」としかとれない事を言ってたけど＞＜
(じゃあマルチプラットフォームじゃなくてUNIX依存環境なんじゃんって＞＜)

おささんがマストドンに依存させたくないピラミッドを描いてるのはわかる＞＜(ファイルの許容範囲のやり取りはマストドンに限った話では無いので汎用的な仕様になるべきでしょ？＞＜(でもそれをhttpにというのはおかしいし、実際歴史的な色々で難しいんでしょ？＞＜))

より抽象化されるのは上の層であって下の層に降りる(依存する)事ではない＞＜

「マストドンのクライアントはメガドラの素晴らしいアーキテクチャに依存したメガドラ専用の物にすればいいと思うし全ての計算機はメガドラになるべき」みたいなめちゃくちゃな提案してない？＞＜っていってる＞＜

それは突き詰めると全ての計算機のアーキテクチャは統一されるべきという話じゃないの？＞＜
より抽象化されるべきとは逆だよね？＞＜
雑に言うとRubyとかJavaとか .NETなんてものは使わず、もっと下の層、究極にはハードウェアが直接仕様を持ちそこに依存すべきだって話になるよね？＞＜

それでいうところの例えばメガドラしか考えてない仕様ってどうなの？＞＜って話をさっきから・・・＞＜

実装の依存は、まぁ・・・うんって議論の余地はとても大きいかもだけど、仕様での依存はとてもマズいかも＞＜(発想がむしろ使い捨て的かも＞＜)

よくわかんないけど、「下の層に依存して解決出来ちゃうなら依存しちゃおう どうせその上で使う人ばかりでしょ」だと、例えばWindowsでしか動かないとかx86でしか動かないとかって話と変わらないし、プラットフォーム非依存の環境をも否定する事になるかも・・・＞＜

この「別のレイヤに依存させるべきではない」の部分、Rubyのプロセス管理がUNIX依存で酷いという話にも微妙に似てる気がしなくもない＞＜

@osapon それは例えば、httpのヘッダに詳細な受け入れ可能なファイルの情報を書く仕様を足すべきみたいな話？＞＜
それはそれで必要かもしれないけど、今回の話で必要なレイヤとは違うレイヤの話だと思うし、別のレイヤに依存させるのはあまりいいデザインとは思えないかも＞＜

マストドンの鯖が、受け入れられるファイルの仕様(設定)をしゃべるべきでは？＞＜ って話になんでhttpレベルの話が出てくるの？＞＜

ウェブの話ならそうだろうけど、Androidのマストドンクライアントアプリの話だよねこれ？＞＜；

よくわかんないけど、全くスマートではなく単なるバッドノウハウの塊にしか見えないかも＞＜

LCXじゃなくても、無線LANってアンテナケーブルで直結して使えないのかな？＞＜

このアカウントは、notestockで公開設定になっていません。

マストドンがかなり独特な構造してるって話を書こうと思ったけど、こっちの話題が片付いてから(？)にしよう・・・＞＜

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

一方で、リサイズしないとアップロードできないのに、そのアップロードできないファイルを受け入れて、リサイズもされなくてアップロードに失敗するのはバグというか正しく無いデザインと言えると思うし、リサイズ機能は内蔵されるべきであろうし、欠陥かも＞＜
(アプリの欠陥かマストドンの欠陥かはわかんないけど＞＜(例えば許容されるサイズを返すAPIがあるのであれば、アプリの欠陥かも＞＜))

リサイズに使ってるアプリが謎だけど、Androidの設計思想的には必要な機能は単機能アプリとして実装されるべきみたいな面がある＞＜

参考＞＜
iPhoneユーザが目の色を変えるAndroidの機能紹介(1) - インテント - ただのにっき(2010-06-08) http://sho.tdiary.net/20100608.html

オレンジはこの記事を読んでAndroidを(モバイル向けだからではなく設計思想が気に入って)使おうと思った＞＜

このアカウントは、notestockで公開設定になっていません。

数日ぶりに普通にねむい＞＜(趣旨・・・＞＜)