2017年11月15日 (水) 表示は HTML+CSSが一番よく知っていて使いやすい。A4に印刷できるし、印刷しなければリンクをクリックもできる。TABLEタグのグループ(table/thead/tfoot/tbody)がパジネイション(※カタカナではわからん。ヘッダ・フッタがページ分割に対応してるってこと)にも対応していて使いやすい。■悩むのがデータソース。永続データではなく表示のための中間データ。XMLをソースにするなら XSLTが使えるが、XMLはファイルに保存するには冗長だし、XSLTはちょっと遅い。IE(※互換モードでも可能だが10まで)+TDCなら TSVファイルをソースにできるが、古いバージョンの IEにロックインされてしまう。Webブラウザがインターネットへの窓口だからか HTMLはローカルのリソースからきっちり切り離されていてデータをつっこみにくい。それだけのためにサーバーは立てない。SCRIPTタグで読み込める JSONは XMLと同様に冗長。その冗長さが無用の可変性を持ち込むことに耐えられない。SQLの INSERT文はテーブル名とオプションの列名を記したあとは、値の組をいくつも羅列できて冗長さがない。というわけでよそから引っ張ってきた生データを最初は XMLファイルに保存していたが今は INSERT文として SQLファイルに保存している。XML+XSLが担っていたデータソース＋表示のための加工を SQLでやってる。■で、本当に悩んでるのが SQLiteから HTML+CSSへの橋渡し。sqlite3.exeがいろいろな出力モードを持っていて、HTMLの表にしたり、CSVにしたり、ちょっと工夫して JSONにしたりはできるんだけど、凝った表示をしたくなれば HTMLは HTMLファイルに書きたいわけで、sqlite3.exeが受け取る、SQLがメインのバッチファイルに HTML片を埋め込むのがつらくなってきた。なんなら HTMLを通して表示したいものを指定するパラメータを渡したりもしたいわけで、HTMLからどうやって可変性のある SQLをつついてその出力を埋め込むのか、その方法を考えてる。XSLTだとブラウザ(※Firefoxと IE)がローカルのデータソースへのアクセスとパラメータの受け渡し手段(XSLTProcessor/ActiveXObject("MSXML2.FreeThreadedDOMDocument.6.0")/XMLHttpRequest)を JavaScriptに対して提供していた。でも今は XMLより SQLをソースに使いたい気分。JSON+Template Literalsが落し所かなあと決まりかけてるんだけど(20171114)、JSONへの不満はもう書いたし、HTMLを JavaScriptの文字列として扱うことにも不満がある。こういう不満ですよ>「非表示の div要素の内容として JSON形式で全ページの HTMLが入っている。(20170906)」 なんでもできるよりそれしかできないの方がよっぽど価値がある。E4X(※今はもう亡い)をテンプレートにできなかったのかな。■なんだかんだ HTMLは孤立していて使えないし、IEはそれを補完して使えるやつだったし(TDCもそうだし src属性を持つ xmlタグもそう)、Firefoxも使える。Google Chromeはローカルリソースがまったく読み込めなくて使い道がない。Headless Chromeは Webブラウジングの、内部からではなく外部からの自動化に役立つかとちょっと調べてみた。アクセスに URLではなくクリックを要求してくる無駄に作り込まれたサイトに対処するために。内部からっていうのは、最初に(主にテスト目的の)アドオンを内通者としてインストールするとか、ユーザーが実行をトリガーするかしないといけないことを指す。ブラウザが認証情報を持ってるのがネックなんだろうけど、プライベートブラウジングモードでもダメなのか。■■■@2017-11-20「Shadow DOM (www.tohoho-web.com)」 template要素と slot要素。データアイランド(ただし可視)に Shadow DOMを関連づけてその配下にテンプレートのコピーを appendすると slot要素と slot属性が結びついているように見える。まず Firefoxが対応していないし、スクリプトでの逐次操作が必要そうだし、すでに完成していて新しいプログラミングパラダイムを見せてくれる XSLTの方がよっぽど使えるという印象。MDNのサンプルではユーザー定義要素とそのコンストラクタで forループを解消してるけど、そこまで要求するならサーバーサイドで動かすことしか考えてないのかな。Shadow DOMにおける slot要素は別々のものを必要に迫られたからなのだろうけどアドホックに雑ぜ雑ぜ(「混ぜ混ぜ」とは変換できなかった)してみただけに見えて、頭の中でモデルをイメージできない。それが自身の知識の不足ゆえであれば問題ないが、高次の構造の欠如によるのであれば使えない技術ってことになる。アドホックというのは演繹が働かず発展性がないということとほとんど同じ意味。■MS用語なのだろうか「XML データアイランド (msdn.microsoft.com)」 必要に応えて問題に対処する手段を提供していたマイクロソフトと、選択肢を奪った不可避の Windows Updateで問題を生み出し足を引っ張る現在のマイクロソフト(20170422, 20171117)。■■■@2017-12-26「ブラウザのしくみ: データ構造とアルゴリズムと雰囲気で理解する DOM と Shadow DOM — hayato.io」 slot要素は出てこない。ツリーのツリーをひとつのツリーに均す(flatten)過程に現れるのだと思うがそこは「魔法」の一言で片付けられた。「ツリーのツリー」は普通の木構造だろうか。ツリーを構成するノード(サブツリーのルート)の背後にまた別のツリー(Shadow Tree)があるのをなんと表現するか。■多重化されたツリーの図が Shadow DOM の本質なのだろうか。だとしたらデータバインディングに使うのは効率が悪い。データ(Shadow Tree)にも表示用テンプレート(Light Tree Node)にも定型が与えられない(=柔軟性がありすぎる)のだから。■「Shadow DOM (w3c.github.io)」 あ、反対だ。表示用テンプレート(Shadow Tree)とデータ(Light Tree Node)の組み合わせが正しい。Shadow Treeに多様性が不要なときに template要素をクローンして使えばいいのか。しかし HTML要素とその slot属性で与えられるデータが不定形だし視覚要素が全く無駄だし、そこにデータを置きたくないし。Shadow DOM ってビジュアルをアタッチする手段なのか？ 俺はデータをアタッチしたい。■「コンテンツはドキュメントに、見た目は Shadow DOM にあります。(www.html5rocks.com)」 HTMLを XMLだと思えばいいだけなのかな、かな？ それでは「すでに完成していて新しいプログラミングパラダイムを見せてくれる XSLTの方がよっぽど使える」という感想が覆らないなあ、自分の用途では。
ツッコミを入れる
2017年11月14日 (火) [javascript]「Template literals - JavaScript | MDN」■データとテンプレートを別々に用意して、好きなタイミングで任意のデータに基づいてテンプレートを評価するには？ Answer「I assume the best way to do this is quite obvious, simply reverse the situation given by the question. You just need to wrap the template literals in a function, and then you will delay evaluation until you pass in the desired params. It's that simple.」 残念なのは関数が JSON形式で持ち運びできないことか。
2017年11月10日 (金)
最終更新: 2017-11-22T15:17+0900
♪ 面白かったのでつい。この状態で送られてきた、シャツが。アイロンかけよ、って言われそう。
９年前に初めて自分で買ったシャツを気に入って(あたりまえ)、襟がすり切れても着ていたのだけど、この前、肩胛骨のあたりが縦に15cmほど裂けているのに気が付いた。その代わりがこれ。同じものが手に入るなら同じものを買っていた。サイズは既知だし気に入ることもわかってる、リスクゼロの選択なのだから。
これはダメな思考の典型らしいけど、服を選ぶのに TPOや組み合わせなどなく、ただ１番２番３番の順序だけがある。１番の服があるのに２番の服を着る必要ある？ ない。２番の服があるときに３番の服の出番がある？ ない。１番の服がまた着られるようになってるのに４番の服を着る機会が存在する？ ない。極論すれば１番の服が３着あればいい。テツの黒シャツ。実際はレイヤーとパターンごとに２から３着。年中半そで１枚ではいられない。
裂けたものはアイロン接着の補修布で手当てしたので(しつこい)、結局シャツが１枚増えただけ。経年劣化だとすぐに、とくに補修した周辺がまた裂けそうだけど、そのときまでは。
2017年11月09日 (木)
読んだ。「TATEditor Advent Calendar 2016 - Qiita」■「傘連判」と「ファイストス円盤(※予定)」にピンときたら TATEditor一択！■ツリー構造のアンドゥ・リドゥ履歴とか行の範囲を限ったアンドゥ・リドゥ(※全体の履歴が前後で維持される)とか、面白いことやってる。実際アンドゥして履歴をさかのぼってるときって、今編集してしまうともう最新の状態には戻れない、って緊張して閲覧(なんならクリップボードにコピー)するだけにとどめてるからね。■タイトルのせいでうっかり読み飛ばしてしまったけど、「メタマークアップ (仮) ― 現状のTATEditorでは以下の表示をマークアップで指定できます。＊ルビ ＊傍点 ＊上付き ＊下付き ＊縦中横 ＊割注 ＊ブロックインデント。これを指定するマークアップ方式そのものはプログラムには含まれていません。
」というのも、そういうアプローチになるよねって感じで興味がある。印象では静的フォーマットだとエディタ側に最適化の余地が大きくて、実行可能なフォーマット(スクリプトがエディタを操作する)は強力で自由度が高いみたいなところがあって、お互いの長所がトレードオフの関係にあって、そのさじ加減に。
2017年11月05日 (日) [Vista] パソコンに初めて音声入力デバイスをつないでみた。限られた数のコマンドの中から似ているものを選び出すのと、まったく自由に五十音を聞き取るのではわけが違うのだけど(※音声認識のトレーニングとして読み上げさせられた情報)、でも Windows が声に応えて動作するというだけでちょっとした感動を覚える。Siriも Cortanaもしゃべってコンシェルも何も身近に試せるものがないもんな。そんでこれ、11年前にリリースされた OSの標準機能。■スタートメニューに「Sakura Editor (Unicode)」というショートカットがあるんだけど、これを「サクラエディタ」と発音して起動できるのが不思議ですごい。■サクラエディタにフォーカスして「改行」って言うとツールバーの入力改行コード指定アイコン３種がハイライトされてクリックするものを選ぶよう促してくるの、本当にどういう仕組みなんだろう(改行文字の入力はまだできない)。
最終更新: 2017-11-23T22:14+0900
♪ [COSMOS] FIFINE K669B
安定を求めた結果の倒立姿勢。仰角調整つまみ(※写真では陰になってる)は、バラせば右手の位置にも左手の位置にも持ってこられる。色は無印K669のフューシャっぽい色が断然好みなんだけど、約４割・1000円増しとあれば考えてしまう。マイクを物色していて最初に惚れたのは実はこれ。
かわいいよね。値段が７倍違うので使い倒す確信なくしては手が出せない。口が退化しそうなほどに喋らない人間には、もちろん確実に無用の長物。スペック的には、FIFINE K669Bには電源ボタン、ミュートボタン、イヤフォン端子、インジケータが欠けている。Windowsを経由して特定の入力と出力を繋げる方法があるだろうか。Windows 7 ではマイクのプロパティからイヤフォンに出力する設定が可能らしいんだけど、Vistaにそのプロパティシートはなかった。電源ボタンやミュートボタンがないのは、スイッチ付きUSBハブに代わりをさせる。
反応速度やスイッチの耐久性を考えると、ミュートボタンはやはり欲しい。トグルボタンではなくトランシーバーのように押している間だけ音声を拾うようなボタンであるとなお良い。なぜか。声を出すとなるとどうしても咳払いが多くなる。のどを使用したからというのも理由だし、声を出してはいけない(誤ってコマンドとして認識されてしまう)という状況がそうさせるというのもある。つまりそういうこと。
値段なりの仕上げってことなんかな。ボリュームの位置を示す溝からバリが出てるから、摘んで回すときに引っかかる。