概ね良好。
昨日食事の取り方に気を付け始めたのに,朝いきなり腹を下して驚いた。1時間ほど脱水症状のような気怠さがあったものの,その後は問題無し。
同じ物を食べた者が一昨日寝込んでいたので,単純に食中りの可能性もあるが,良い変化の過渡的な現象であると思いたい。
デライトにおける νS(JavaScript)渡配についての検討などで終了。
しばらく,ES5 への渡配をやめて様子見することにした。備立環境は調整済み。次回の前縁出振るいで本番環境にも反映されるだろう。
希哲13年8月23日の開発以来,νS では ES2015 を基礎にしているが,同時に Babel を導入し,配信スクリプトは ES5 に渡配していた。それから4年近く経ち,デライトの舞覧対応方針は洗練され,ES2015 の対応舞覧も十分な市影を有している。もはや ES5 との互換性を引きずるべきではないと判断した。
とりあえず,--presets
応付子を外して,babel --no-babelrc --minified --no-comments
だけで換配するようにしてみると,ae.js
の譜類サイズは20kB近く減った。譜類サイズ削減以上に,スクリプトの複雑化に伴うオーバーヘッド増加抑制も期待出来る。
ES2016 以上の交度がうっかり紛れ込む(紛れ込んでいる)可能性を考えると ES2015 への渡配をしておいた方がいいかと思ったが,どうもそういう考え方をする時代でもなく,Browserslist を使った手法が主流らしい。確かに,舞覧の対応状況が非常に流動的なので実態に合わせる方が合理的ではあるが,ブラックボックス化は避けたい。これまで通り,導入付徴の対応状況は個別に把握しておくことにした。デライトの能力が活かせるだろう。
いずれにせよ Babel の設定で後からいくらでも調整出来るので,いったん渡配無しで様子見する。
ついでに,変数名などの短縮などについても再検討したが,やはり外部通類への依存度を高めず保守性を維持するのは難しいため見送った。交度英語のおかげで一定の短縮性は保たれている。
今月の雑務も片付き,晴れ晴れとした気持ちで過ごせる日のはずだったが,親戚についての不吉な報せを母から聞いてしまい,気分が沈んだ。
私自身はこのまま健康ならあと五十年は粘れるが,待ってくれないものもある,という単純な事実を思い出させられた。ここ数年は一年毎くらいで似たようなことがあり,似たようなことを考えている気がする。そういう年齢なのだろう。
希哲館事業の成功を果した時には恩返しも償いも出来ないまま皆いなくなっているかもしれないと思うと背筋が凍る。雑務もなまじ楽しくなってきて良くも悪くも緩んでいた気持ちが,思いがけず引き締まった。
とはいえ,いま自分に出来ることはデライト開発を着実に進めていくことしかない。杞憂で消耗していても仕方ないので,気を取り直して平常心で作業に没頭することにした。
今月の開発では閲覧専用模動,譜類添付機能が大きな収穫だったが,新生デライトの完成は持ち越しとなった。
特に譜類添付機能は中途半端に良い出来で,先月のダークテーマ・全知検索窓固定機能のように調整作業から離れられなくなっている。早く落とし所を見つけたい。
いずれにせよ年度替わりで集客には不向きな時期なので,また黄金週間を睨んで調整していくことにした。
現時点ではやはり \ce( ... \)
と \ce[ ... \]
が最も無難な記法であると結論付けた。
昨日直感的にこの記法を思いついたが,実際に使ってみると,閉じ括弧前の \
を忘れやすいという問題に気付いた。慣れの問題もあるので欠点と結論付けるのは早いが,数式記法の \( ... \)
と比べて \ce( ... \)
は括弧の対応関係が直感的に認識しにくいというのはありそうだ。
TeX では \ce{ ... }
を数式模動の内側に書く必要は無いため,いっそのこと,これだけでもいいのではないかと思った。
しかし,これだと化学記法というよりは TeX 風記法で mhchem を使っているように見えてしまう。TeX ではバックスラッシュと波括弧が多用されるからこれが自然に見えるだけで,デライトでこれがぽつんとあっても違和感が大きい。特に波括弧はデライトにおいて特別な記号なので,濫用は避けたい。いずれにせよ行内と別行立ての書き分けが出来ず,書き分けせずに文脈で挙動を変えれば TeX 的でもなくなるので,良い案ではなかった。
「似た機能は似た形態に」という言語設計の原則に立ち返ると,やはり化学記法は数式記法に似ているべきだろう。
では,閉じ括弧前のバックスラッシュを省略可にするかと考えたが,これは実装上の問題が大きい。入れ子になりうる閉じ記号の処理は出来なくはないが一気に面倒になる。しかも,化学記法でそれをすると数式記法でもしないと整合的ではなくなる。現時点で化学記法の使い勝手のためにそこまでの実装コストを払う意義は見出せない。
10.6.0 からスクリプトは最新版の 11.7.0 へ,Zenburn の装体書は最終版の 10.7.3 へ上げた。出振るい・手定め済み。
希哲15年7月18日10歩で更新を検討したが,当時は対応言語の検証が必要と判断して見送り,以来そのままだった。約2年前の版存なので,流石に対応言語云々より弊害の方が大きいだろうと更新を決めた。
作業自体はあっという間に終わると見込んで昨日深夜に着手したが,最新版で従来の Zenburn が事実上消えていたため,カラーテーマ検討に時間を取られてしまった。散々考えた結果,Zenburn の最終版を利用して現状維持とすることにした。
最新版で Zenburn は styles/zenburn.min.css
から styles/base16/zenburn.min.css
に移動していた上に,従来とはほとんど別物になっていた(様子)。Base16 になったからなのか事情はよく分からないが,読みにく過ぎるのでいずれにせよ使い物にならない。
気になる部分は装体を上書きして調整出来なくもないが,そこまでするならデライト独自のカラーテーマを作りたくなってくる。取り急ぎ代替テーマを探すことにした。highlight.js 導入時にそれなりに時間をかけて検討した(希哲15年3月9日11歩)ので,当時の記憶からある程度の見当は付いた。
作業方針検討(4歩),閲覧専用模動実装検討(5歩),デラング整備・埋め込み記法処理改良(8歩〜13歩)。
これまで,埋め込み記法処理の中でも oEmbed を利用したものについては,Dex 内で埋め込み交度の取得を行い直接描写 HTML に埋め込んで返していたが,埋め込み交度の取得処理を専用 API /mbd
に委ね,前縁 Aejs から利用することにした。結果として,応答速度改善に成功した。
埋め込み記法(+[URL]
)の URL が oEmbed を必要とする場合,Dex では適当な分類名を付与した <div>
に出与え属性で URL を埋め込んで描写 HTMLを返す。Aejs ではそれを検知し,URL を /mbd
に転送する。/mbd
は URL に対応したサービスの埋め込み交度を oEmbed で取得して返す,という流れになる。過剰な立求を抑止するため,Aejs には簡易的な隠しも持たせておいた。
そもそものきっかけは,先日の SlideShare 対応だった。oEmbed が必要になったので,埋め込みツイートで使っていた Dex 内の oEmbed 埋め込み方法を取り急ぎ使った。ただ,記法処理範枠に同期通信処理を組み込むというのは正気の沙汰ではない。なんでこんな実装になっているのか,引っかかりはあった。
KNEST 隠しを使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状,そこまで最適化する必要も時間も無い。出来たとして,隠しを有効利用出来る握接パターンは限られている。いずれにせよ,この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで,いったん,埋め込み処理は前縁に移すことにした。
知名欄・描写欄の捕活に関する仕様検討の結果,ともに「マウスオーバーで捕活する」仕様を確定・実装した。出振るい・手定め済み。
仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活・全選択,描写欄では捕活,という方針だった。これは,実用上の都合というのも大きく,こうでなければ単純に描出効率が悪かった。
昨年9月までの第二次用合い改良中の交度整理で,知名欄の捕活・全選択は機能しなくなっていた。これは確か,中景輪符の事象を改良したことで干渉の懸念があり,再実装を後回しにしたという経緯だった気がする。もっと地味な描写欄の捕活は過去に何度か再実装した記憶があるものの,どの時点で機能しなくなっていたのかは曖昧だが,いずれにせよ,第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた。
もしかしたら,これはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率が重要な作業になると,クリックでの捕活はやはりまどろっこしく,鈍重に感じる。そこで最近はかつての挙動を復活させる機会を窺っていた。
懸念は,他要素・他機能との干渉や誤操作だったが,これは昨日の検討から急速に氷解した。今のデライトで,マウスオーバーで捕活が移動すること自体は前提のようなところがあるので用者体験に大きな悪影響はないだろうということ,むしろほとんどの要素がマウスオーバーに反応するのに知名欄・描写欄が無反応なことが直感性を損ねているとも言えること,スクロールとの干渉も実際の舞覧では生じないこと,誤編集の問題については,そもそも閲覧・編集用合いを切り分けていることが一定の保護機能になっており,更に取り消しボタンで変更有無が分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した。
そこでまず,知名欄の全選択も含めてマウスオーバーでの捕活機能を復活させてみた。ところが,知名欄の全選択については数十分で廃止を決定することになった。実装上の問題としては,選択状態がやはり周辺要素と干渉する。干渉しないようにマウスアウトで解除すると,今度は選択状態が意図せず解除されやすくなる。もっと問題なのは,誤入力で上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態が好都合だが,知名欄での利点は写し取りが素早く行えることくらいでさほど大きくない。
これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても,熟練用者向け過ぎて採用出来ない。
次に,知名欄の全選択機能を外し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら,編集の軽快感は明らかに向上している。捕活さえしてくれれば Ctrl + A で写し取りも十分効率的に行える。今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時に発生するスクロールは意図しない場合が多く考えられるため抑止する。
どこまで普遍的な現象か分からないが,常用している Linux の Firefox では,<textarea>
の選択状態を残して捕活解除すると,再選択のつもりが(未捕活状態のせいで)意図しない文字列ドラッグが発生しやすいため,これがなくなったのは個人的に嬉しかった。近頃多用している複数輪符の引き入れ欄への写し貼りで障害になっていた。
とにかく,第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった。
希哲荘の給湯器は設置から17年以上は経っているであろう古いものなので,いつ壊れてもおかしくなかった。ここ5年ほどの間か,給湯温度がやや不安定になったり,風呂場のリモコンが効かなくなったり,全てのリモコンの画面が映らなくなったり,少しずつおかしくなっていた。昨年も交換をちょっと検討したが,すでに半導体不足で入手困難という時期だったため騙し騙し使ってきた。
明日業者に来てもらうことになったが,とりあえず,給湯器を使わずに凌ぐ方法を考えておいた。一番心配だったのが入浴だが,これは足湯バケツと電気ケトルを使った「バケツ浴」で何とかなりそうだ。
ネットで見かける投げ込みヒーターが使えるかもしれないと近くの家電量販店を回ってみたが,どうも当たり前に売っているものではないらしく,見つからなかった。ネットで買うのも安全性などが怪しい上に,どれも配達日が遅い。結局,必要なさそうだ。
しばらく給湯無しで生活する覚悟が出来,寝ようと思った26時頃,ランプが点いたまま全く反応しなくなっていたリモコン電源ボタンのランプが消えていることに気付いた。試しに押してみると,あっさり起動して湯が出るようになった。
いずれにせよ交換することになりそうだが,新しい給湯器が来るまで持ってくれることを願うばかりだ。
kno
}{希哲16年9月23日}{希哲16年9月23日の開発}{希哲16年9月23日の進捗}{影響しそう}{使っておらず}{付けようとしていた}(37)