@pokarim そうですよね。これはレイアウトしやすいような文書の制約とは、という話ですよね。SGMLとオーサリングツールにギャップがあるから、それを記述の制約によって回避するというか。
@pokarim そうですよね。これはレイアウトしやすいような文書の制約とは、という話ですよね。SGMLとオーサリングツールにギャップがあるから、それを記述の制約によって回避するというか。
@nsiena php の ncurses ってあるんですが、pecl での配布なのでまさにコマンドラインツール向けにならないんですよね。 tput をいいかんじに使いこんで構造性を獲得するまでやる必要がある(ない)
http://php.adamharvey.name/manual/ja/book.ncurses.php
@nsiena @pokarim たとえば https://ja.wikipedia.org/wiki/Standard_Generalized_Markup_Language#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:OED-LEXX-Bungler.jpg こういう電子辞書のSGMLマークアップがあるとき、これをレンダラーが処理しないといけない。これを見るかぎりでは、意味とレイアウトが密結合になるかなという印象があります。その結合はレンダラーのなかにも取り込まれてしまいそうにおもいました。
@nsiena @pokarim 電子辞書のマークアップには電子辞書のためのレンダラがあって、ということになるとここに書かれている device-specific なレンダラーがあったとおもわれ、それを克服したかったのがHTMLなのかなという印象です。 https://www.w3.org/MarkUp/HTMLConstraints.html
SGMLはやたら複雑化し、その処理系もやたら高価なものになっていて、市場で広く導入するのは難しかった、らしい。
そういう点でも、シンプルなものにしなければ、という動機はあったはず。
@tenjuu99 @pokarim
名前を思い出したー。
XSLの基になったと言われる、DSSSL。他にもスタイルしてい言語はあったように思う。
<https://ja.wikipedia.org/wiki/Document_Style_Semantics_and_Specification_Language>
<https://www.jstage.jst.go.jp/article/nig1987/29/1/29_1_29/_pdf/-char/ja>
このアカウントは、notestockで公開設定になっていません。
graphQLサーバーとしてのRailsはすごく良くないぞという印象だけど、じゃあなにならGraphQLはいいの？っていうのがわからない
ふだんは多少SQLの本数増えても、CDNでキャッシュしとけばいいから気にしないでおこう、とおもうけど、GraphQLとしてはそういうことができないから、lazy load にたいする繊細な配慮が必要になって ActiveRecord にたいする恨みつらみ
mastodon のCLIクライアントあるやん
https://toot.readthedocs.io/en/latest/
このアカウントは、notestockで公開設定になっていません。
@nibushibu 左端からスワイプでメニューでてくるとおもいます。検索は上にのこっていて、いつもどこにあるかわからなくなります。
@nibushibu ああ、なるほど、そもそも設定画面にスワイプからしかいけないとおもっていたのですが、タイトルの自分のアイコンタップしたら設定画面でるのですね。スワイプが使えなくてタイトルバーがなくなるとたしかに。自分は Pixel6a ですが、アプリとのスワイプ競合がめんどくさくてOSのジェスチャーは有効にしていなかった気がします。
GraphQLは仕組み上SQLがたくさん発行しがちなのにリクエストをキャッシュする仕組みがあまりなくて厳しいな...
@NaokiTsuchiya クライアントサイドでGraphQLつかいたいという気持ちがあまりわかっていないんですよね...
@NaokiTsuchiya 仕様としてはありだとおもうんですが、RSSする対象がブログとか記事とかだと文字数が多すぎてタイムラインUIではコンテンツ展開できないとおもうのですよね。たぶんtwitterが文字数制限したものをマイクロブログと呼称した理由がちょうどそこにある気がしていて、RSSをタイムラインUIに展開するときに文字数の制約を付ければUI上に展開できるというか。