実験工房の「実験」という名称に「科学の効用が、きわめてわかりやすいかたちで表れている」とながら、「実験は、結果が予測できないことから、おのずと何がしかの前衛性を伴う」とかいいだして、えっ科学の実験はふつう結果が予測可能になるためにやるでしょ、とか。
まあ、これはくだらない箇所だからどうでもいいんだけど、そんなことより、戦争(敗戦)の理解がひどすぎる。ふつうに歴史くらい勉強しろよ、ネトウヨなみの歴史観だぞこれ。
まあ、これはくだらない箇所だからどうでもいいんだけど、そんなことより、戦争(敗戦)の理解がひどすぎる。ふつうに歴史くらい勉強しろよ、ネトウヨなみの歴史観だぞこれ。
Why Frank Lloyd Wright Designed a Gas Station in Minnesota (1958)
ハイパーメディアによるコントロールは、ユーザビリティの向上にとっても必要な一方で、サービス提供者がユーザーをコントロールする技術にもなりうる、みたいな両価性があって、あらゆる技術がそういう両価性があるのかどうか
これたぶん「技術は中立的」みたいなことではなくて、ベンヤミンが映画技術を資本家が占有するか労働者が占有するかという両価性について考えていた、みたいな話がある
これたぶん「技術は中立的」みたいなことではなくて、ベンヤミンが映画技術を資本家が占有するか労働者が占有するかという両価性について考えていた、みたいな話がある
ここでいう「オペレーション」はマノヴィッチの独自用語だけど、カット&ペーストだとかデータの合成だとか、そういうUI上で一連の語彙として成立した行為のことで、こういった語彙の背後にあるのはあきらかにオブジェクト指向界隈が発達させてきた一連のパターンで、基本形としてはオブジェクトの選択→行為(マノヴィッチの言うオペレーション)になっている。「オペレーションとメディア・データの分離」と彼が呼ぶものは「メッセージとオブジェクトの関係」と見てよい。
管理画面で頻出するパターンなんかはとくに rails/rest 向きで、graphql は向かないと感じる。ユースケースの多くがそれぞれ固有の制約を抱えており、ユースケース固有の遷移・意味・操作などがあるけど、そういうのは graphql でみんなどうしてるんだろ。
デザインにせよプログラムにせよ、課題はつねに秩序が形成できるかどうかであって、RESTはこの秩序を形成するための規約だけど、GraphQLにはそういうものがない。RESTを前提にした場合にはいくつか有益なパターンが明確にあり、Rails などはあきらかにそれを取り入れている。
やっぱりフロントからみるとGraphQLってどうしてもデータベースになってしまうわけで、操作の体系的な意味もフロント側にあることになるけど、そうするとバリデーションとかみんなどうしてんの?サーバーサイドでコントロールしないと厳しくない?
UIを作るのって結果的にはつねに操作を定義することになるけど、GraphQLがもたらしたのって操作とデータの分離で、このギャップをどこかで埋める必要がでてくるわけだが、そのギャップをユーザーにおしつけるか、プログラマーが頑張ってデータと意味の変換層をつくるか
mutation が結局「データを操作する」になりがちで、それに直接対応したUIを想定すると、脳内でデータの意味を構築して操作の手順を組み合わせる必要があるようなUIになる。それで、では mutation の基本的な構造とUIは別だということになるのであれば、プログラマの立場からはUIとデータモデルを別な仕様として定義する必要があることになり、不当に仕事量が多く見える。
自分の感じていることとしては、GraphQLは操作の単位で切りだすことが困難だということ(できないわけではない)。
自分の感じていることとしては、GraphQLは操作の単位で切りだすことが困難だということ(できないわけではない)。
たとえば article の公開という操作があるとき、rest であれば `publish` という意味付けられた操作を定義して、 /article/{id}/publish みたいなエンポイントに引数なしで put するけど(非公開の場合は close とか unpublish とか)、GraphQLでは article の mutation に published フラグを true で渡すとか、そういうのをよくみる気がする(いやこれはrest でもやる人はいるけど)。ただ、`articlePublish` という mutation をつくって article の id を渡す、とすれば上記と似ているけど、GraphQL ではほぼ article id をURLに埋めこむことができなくて、それは決定的に REST とは違う。
これ9月発売だった気がするけど、まだこないな
https://getsuyosha.jp/20220711-2/
https://getsuyosha.jp/20220711-2/