orange
さんがブースト
普段ブラウザ (firefox / chrome) だけでメモリを 1 GB 以上食ってるから感覚が麻痺するけど、ブラウザ起動してないときの gentoo (XMonad) のメモリ使用量、少なくてビビる (10年前のマシンで動かすつもりかよというレベル)
オレンジは、同じ事をするのに過去の機種では難しくなっていくのって、何らかの必然性が無い限り正しく無いデザインの結果と考えるから、端末でも鯖でもより古いのでもよりまともなUXで動く方が正しい＞＜って考えてる＞＜
orange
さんがブースト
4年前の端末を未だに使っている私にゃ最近の事情は……
orange
さんがブースト
orange
さんがブースト
あとこれは実際どうなのか知らないけど、クライアント端末は数年周期で買い替えが入るので勝手にスペック上がっていくけど、サーバは何もしなくてもお値段据え置きでメモリ増えていくなんてことはなさそうだし、フリーランチ食べられそうなのはクライアントですよね
それはたしかに・・・＞＜
orange
さんがブースト
間違った仮定からはどのような結論も導けるので……
orange
さんがブースト
や、私も記事の主旨にはおおむね同意なんですが (join とか DB 持ってる側でやってほしいし)、それはそれとして「サーバの方がリソースあるんだから」という理由付けには考える余地があるという話です
ハンバーグ屋さんで注文を受けてから牛と戦うのは、食品の新鮮さへのこだわりとしては素晴らしいのかもしれないけど、UXとしては・・・・＞＜
全て全うに動いた時にレスポンスがUX上十分早くなるようにするにはどういう設計が必要か？みたいな趣旨で書かれた記事だと思うんだけど・・・＞＜(どうせ遅くなるならなんでもよくね？で設計しちゃったら、無限に最悪な設計でもよくね？になっちゃう＞＜；)
x複雑差 o複雑さ
＞＜；
それはその通りだけど＞＜； でもクライアントの処理が重いの面を単に処理能力の問題と見ればそうだけど、手順の複雑差による時間の大きさで見ると、操作に間に合わせるのであれば、時間がかかる処理はあらかじめしておく事が必要かも＞＜(もちろん、「単に同じ事を鯖側でやればいいんでしょ？」ってそのときに必要になってから処理しようとすれば、鯖側で動かしても十分遅すぎるけど＞＜；)
orange
さんがブースト
サーバや通信が重くて busy になるのとクライアントが重くて busy になるの、ユーザ視点でいかほどの違いがあるのかわからない……と言おうとしたけど、そうか企業はジャブジャブサーバに金を注ぎ込んで、サーバは絶対レスポンスを遅らせないという仮定を持てるんですね(ほんまか？)
開発者が嫌とか嫌じゃないって話じゃなく、それだと物理的に(？＞＜；)ユーザーの操作に追い付けないって事かも＞＜
orange
さんがブースト
何度も json 読んではリクエストを投げ、みたいなの、クライアントからすれば嫌だろうけど、ユーザ数に対して必ずスケールするクライアントとスケールさせ方が自明かつ簡単でないサーバ、どちらを複雑にするべきかと考えると……規模によるだろうけど、サーバをシンプルに保った方がよさそうじゃない？
(なお私はサーバのプロではない)
orange
さんがブースト
ネイティブアプリエンジニアが伝える、バックエンドエンジニアに認識して欲しい4つのこと | eureka tech blog
https://developers.eure.jp/tech/knowledges-for-backend-from-native
これの話。
> むしろ、サーバーサイドの方が潤沢なCPUリソースを保持しているので、処理はサーバーサイドに委譲すべきです。なので、複雑なロジックは全てサーバーサイドに吸収してもらいたいです。
気持ちはわかるけど、ここまで一般的な書き方されると疑義が出てくる
ていうか、APIとかのデザインで互換性の維持や将来性を考えない人、どういう考え方してるのか謎＞＜(オブラートに包んだ表現)
記事の鯖側でってUXの為だし、レスポンスに強く影響するあらかじめ計算しておけるものはあらかじめ計算しておいてほしいみたいなのの延長かも？＞＜
- ＠orange_in_space
2017年 4月に登録
