譜類添付機能の PDF 画像化では,最初 WebP 変換せず実験していたため pdftoppm
の JPEG 出力(-jpeg
)を使っているが,WebP 変換しているなら PNG 出力(-png
)の方がいいのではないかと思い軽く実験してみた。
結果,微小な画質の向上は見られたが譜類サイズが7倍程度に増えたため現状維持とした。PNG からの WebP 変換でも十分軽いが,JPEG からの方がサイズ対画質が圧倒的に良い。
pdftoppm
}{希哲17年4月6日の開発}{希哲17年4月6日の進捗}{譜類添付機能}{希哲17年4月6日}{7倍}(38)-
}{進捗}{希哲17年1月27日の開発}{希哲17年1月27日の進捗}{希哲17年1月27日}(156)Aejs の交度整理も進めつつ,前後景輪数増減表示を前後景部同期処理に組み込んだ(様子)。いったん出振るい・手定め済み。
これにより,動的な輪括操作では,操作の結果として生じた前後景輪数の増減値を +
と -
で,増減が無い場合は ±0
で,読み込み中は ±?
で表示するようになった。
増減表示は太字にし,元の数字との間に半角スペースを入れた。最初は太字だけで十分かと思ったが,意外と視認しにくかった上に,-
で 2-1
のように表示すると一見意味が分からない。
小さな変化で実装も単純ながら輪括操作の感触が非常に良くなった。
ついでに,前後景輪数表示も3桁カンマ区切りにしておいた。ページャーなどでは3桁カンマ区切りだったが,ここだけ単純な数字列で微妙な不統一感があった。
これまでは単純に最新の状態に置換するだけの同期処理だったため,操作の効果が分かりにくいという問題があった。
特に,引き入れ・引き外しされる輪郭の時印が古く前後景部に表示されていない場合と,何らかの問題で同期に時間がかかっている場合は無反応に見えてしまっていた。複雑な輪括操作をしていると,どの輪郭に何をしていたか分からなくなってしまう問題もあった。
問題はデライト最初期から認識していたものの,もっと派手で複雑な表示を考えていたせいでなかなか実装イメージがまとまらなかった。輪括数も高が知れている初心者の場合は見た目の変化が大きいため分からなくはないし,慣れた用者も表示輪数の変化で分からなくはないので放置してきてしまった。
例えば,最後に引き入れした輪郭を分かりやすく表示しておくという案があったが,様々な場面で直感的かつ邪魔にならないようにするには実装コストが無駄に高くつく。特に,引き入れ欄の複数知番対応以後は現実的ではなくなっていた。
他方,昨年8月21日の前後景時印導入以後,前後景輪数が極端に多い輪郭の前後景部同期にやたら時間がかかる問題が発生していた。これ自体は例外的な輪郭でのみ起こることで仕方ない面もあり,捌き手増強で対応することを考えているが,読み込み中くらいの表示は欲しかった。そこで,前述案などを補助するものとして考えていた増減表示に読み込み中表示を兼ねさせて一時凌ぎすることを考え始めた。だんだんこれだけで十分な気がしてきて,9日の開発で増減表示を中心とした引き入れ用合い改良案がまとまった。
KNEST::req_I::b_bot_ad()
}{広告用クローラー}{希哲17年1月27日の進捗時限}{KNEST::req_I::b_bot()
}(39)テーマ切り替えボタンの用合い検討(4歩),新規描出フォームへの移動機能として吹き描き外背景のダブルクリック用合いの復活(10歩),全知検索ページャー周りの調整(16歩),こまごまとした領当て・装体調整(17歩)といった雑多ながら充実した作業を片付け,ついに描写後略機能を一段落させた(21歩)。出振るい・手定め済み。
描写後略機能により,デライト最初期から吹き描きの構造的問題だった「不必要な出与え読み込みの多さ」という問題が解消した。表示速度向上,通信量削減,SEO 強化,迷惑行為対策など多大な効果が見込める。
昨年末の壊衝不具合修正以後,デライトは速度・安定性ともにウェブ相振りとして十分な水準に達していたが,今回の高速化を経て,明らかにもう一つ壁を越えた感がある。体感として,「ウェブ相振りなら特に不満のない速さ」から「単動相振りと比べても遜色のない速さ」になった。
一昨年4月9日に掲げた「全ページ0.3秒以内表示」という目標は埋め込み利素を考えると現実的ではない気がしてきたものの,軽いページでは200ms台,重いページでも概ね300ms台で応答出来るようになっている。実感として欲しかった速度は手に入れられたし,最適化余地はまだまだ残しているので「埋め込み利素を除いてほぼ全てのページで0.3秒以内表示」なら十分手が届く。いよいよ本格的に,速さがデライトの武器になってきた。
ここで新生デライト開発におけるデライト高速化は一段落とし,今後は機能追加やトラフィックに応じた微調整に留め,別の機能整備に集中することにした。
その先のデライト高速化については,大きなところでは CDN 導入,KNEST による水平拡大,請い手の隠し機能整備,描写 HTML 隠し以外の HTML 隠し実装,そして中途半端な状態で放置しているページ付け求頼改良があるが,どれも現時点での優先順位は低い。
垂直拡大の余地も十分にあるので,当面は捌き手増強で対応出来るだろう。
23日の開発から始まった一連の高速化で終えた作業は,描写 HTML 隠し実装,KNEST 隠しのクローラー対策,描写後略機能実装の3つ。
全体として,実装コストは最小限に抑えつつ効果は最大化するような落とし所を見つけられた。
これまで Dex_T
には完成した HTML を返す道手しか無かったため隠し化出来なかったが,共通バッファを返す道手(Dex_T::buf()
)とそれを閲覧条件によって仕上げる函数(Dex::fin()
)に分離し,外部で共通バッファを共有出来るようにした上で KNEST 隠し化した。
実装は oln_T
に描写 HTML を持たせることも検討したが肥大化の懸念が大きいため,分離して専用の KNEST 隠し客体を用意した。
これにより,切り分けが難しく進まなかった HTML 隠し実装が部分的にではあるが初めて実現した。デラング処理は特に大きな部分なので,その他 HTML 隠し実装の優先順位が下がった。
24日の開発で出振るい・手定め済み。長大な描写が含まれるページでは体感速度向上が見られた。
KNEST 隠しは一定の成果を上げてきたが,足枷となっていた問題として,ボット,主にクローラーに反応してしまうというものがあった。特に輪郭隠しではほとんど活用出来ない隠しに記憶領域が圧迫され,無駄な設定処理とロックが発生していた。当然,描写 HTML 隠しでも問題になる。
そこで,ボット判定用の KNEST::req_I::b_bot()
を追加し,隠し設定用の函数群(輪数隠し以外)がボットと判定された握接で機能しないようにした。これにより,原則としてボットは KNEST 隠しを取得出来るが設定出来ないようになった。
ただし,ボット判定対象はとりあえず現時点で必要性の高い Googlebot, bingbot, Applebot のみ。迷惑クローラーの類は元々 nginx で弾くようにしているため問題ではない。適宜調整していく。
描写 HTML 隠しとともに24日の開発で出振るい・手定め済み。
昨年5月30日の開発までに実装イメージが概ねまとまっていた描写後略機能だが,描写 HTML 隠しのために共通バッファと仕上げ処理を分離するという方針から,切り分けが容易になり,一気に実装コストが下がった。
これまで,Dex_T
内部でデラング処理を中断・再開する機能としてイメージしていたため,複雑化の懸念が拭えなかった。複雑化は保守性の低下を招き,結果的に高速化にもならないということも考えられたが,Dex_T
では適当な間隔で区切り文字を挿入するだけに留め,仕上げ処理(Dex::fin()
)で切り出すという方式に単純化出来ることに気付いた。
Dex_T
が全体の行数・現在の行番号を設定する。Dex::bl_fdn_T
が部区間の境界で20行以上かつ残り行数10行以上の場合に越化参照 &_omt;
を挿入する。Dex::fin()
では全体・&_omt;
前後の3種類で出力を切り替える。div.omt
を検知し追加読み込みを行う。当初想像していたよりずっと単純化出来た上に,導入前後で使い勝手が全くと言っていいほど変わらなかったのは嬉しい結果だった。もう少し用者が意識するものになるかと思ったが,よく観察しないと気付かないほど透過的に導入出来た。輪郭小窓でも問題なく機能している。
高速化効果は言うまでもなく,長大な描写が多いページでは飛躍的に表示速度が改善した。
当初のデラング処理中断・再開機能はいったん断念し,請い手の負荷軽減を重視した格好だが,実際には捌き手側の負荷軽減もそれなりに見込めることが分かり,万々歳の結果となった。描写 HTML 隠しが活用出来る場面が想定以上に多かったこと,閲覧条件による置換処理の範囲を限定出来ることが効いている。
強いて描写後略機能の課題を挙げれば,ページ内検索の直感性を損うこと,スクロールバーで内容量が分かりにくくなることがあるが,いずれもそこまで気にする人は少ないだろうし,対策は出来る。
ページ内検索については, Ctrl + F に強制追加読み込みの省割キーを兼ねさせることが考えられる。内容量の目安としてのスクロールバーは厳密さよりも少なそうか多そうかがざっくり分かることが重要なので,例えば実際の内容量よりも少なく見えないように後略条件なり下余白を調整すれば実用上の問題は無いだろう。
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歩)ので,当時の記憶からある程度の見当は付いた。
まず,当時の検討で Zenburn の次点だった Gruvbox Dark を見直してみると,バリエーションの Base16 / Gruvbox Dark Pale が悪くなさそうだった(様子)。当時一種類しか収録されていなかった Gruvbox Dark では明るい赤の多用が気になって不採用だったが,こちらは比較的落ち着いた雰囲気になっている。ただ,全体的にセピア調のような色合いで,微妙に野暮ったい。
デモページでカラーテーマを一通り眺めて,Base16 / Gruvbox Dark Pale に近い Base16 / Tomorrow Night を見つけた(様子)。こちらの方が癖が無く垢抜けて見える。Tomorrow は Gruvbox 以上に人気があるようなので,その点も申し分ない。早速採用しかけたが,実際に試してみると #include
などの色が視認しにくい。
Base16 ではない Tomorrow Night Blue と Tomorrow Night Bright もあり,比較的視認性が高い。これの背景色を調整すれば良い感じになるのではないかと試してみた。Blue は紺色背景なので黒系に変えると微妙に違和感があるが,Bright の方は悪くなかった(調整前・調整後)。しかし,何か引っかかりを感じた。
そもそも赤系の色を多用することに抵抗がある。色の役割を考えると,赤は強く強調すべき箇所に使うもので,knu-mode
では,鍵語は原則青,例えば delete
演算子のようなものは赤と使い分けている。何度見返しても,そういう合理性を感じるカラーテーマがほとんど無い。全体的な雰囲気は悪くないが,一つ見にくい色使いがあるとか,そんなものばかりだ。
このあたりで,Zenburn の優秀さを再評価し始めた。散々他のテーマを見た後で見直してみると,これほど落ち着いた配色で特別見にくいところも癖も無いテーマが他に無い(様子)。強いて言えば,#3F3F3F
という背景色が僅かに明るいので #333333
に調整しているくらいだ。
どうも highlight.js 11 になった時に旧 Zenburn が Base16 / Zenburn に置き換えられたらしいので,10.7.3 の最終版を利用することにした。一応中身を見比べてみたが,新しい分類名に対応していないだけで基本は同じだった。ある程度カスタマイズされることは想定しているはずなので,いきなり使えなくなることはないだろう。
現状維持にやたら時間をかけてしまったが,過去の自分の選択の正しさを確認出来たことで良しとする。
知名欄・描写欄の捕活に関する仕様検討の結果,ともに「マウスオーバーで捕活する」仕様を確定・実装した。出振るい・手定め済み。
仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活・全選択,描写欄では捕活,という方針だった。これは,実用上の都合というのも大きく,こうでなければ単純に描出効率が悪かった。
昨年9月までの第二次用合い改良中の交度整理で,知名欄の捕活・全選択は機能しなくなっていた。これは確か,中景輪符の事象を改良したことで干渉の懸念があり,再実装を後回しにしたという経緯だった気がする。もっと地味な描写欄の捕活は過去に何度か再実装した記憶があるものの,どの時点で機能しなくなっていたのかは曖昧だが,いずれにせよ,第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた。
もしかしたら,これはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率が重要な作業になると,クリックでの捕活はやはりまどろっこしく,鈍重に感じる。そこで最近はかつての挙動を復活させる機会を窺っていた。
懸念は,他要素・他機能との干渉や誤操作だったが,これは昨日の検討から急速に氷解した。今のデライトで,マウスオーバーで捕活が移動すること自体は前提のようなところがあるので用者体験に大きな悪影響はないだろうということ,むしろほとんどの要素がマウスオーバーに反応するのに知名欄・描写欄が無反応なことが直感性を損ねているとも言えること,スクロールとの干渉も実際の舞覧では生じないこと,誤編集の問題については,そもそも閲覧・編集用合いを切り分けていることが一定の保護機能になっており,更に取り消しボタンで変更有無が分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した。
そこでまず,知名欄の全選択も含めてマウスオーバーでの捕活機能を復活させてみた。ところが,知名欄の全選択については数十分で廃止を決定することになった。実装上の問題としては,選択状態がやはり周辺要素と干渉する。干渉しないようにマウスアウトで解除すると,今度は選択状態が意図せず解除されやすくなる。もっと問題なのは,誤入力で上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態が好都合だが,知名欄での利点は写し取りが素早く行えることくらいでさほど大きくない。
これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても,熟練用者向け過ぎて採用出来ない。
次に,知名欄の全選択機能を外し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら,編集の軽快感は明らかに向上している。捕活さえしてくれれば Ctrl + A で写し取りも十分効率的に行える。今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時に発生するスクロールは意図しない場合が多く考えられるため抑止する。
どこまで普遍的な現象か分からないが,常用している Linux の Firefox では,<textarea>
の選択状態を残して捕活解除すると,再選択のつもりが(未捕活状態のせいで)意図しない文字列ドラッグが発生しやすいため,これがなくなったのは個人的に嬉しかった。近頃多用している複数輪符の引き入れ欄への写し貼りで障害になっていた。
とにかく,第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった。
いったん出振るいを終え,他自我内検索用合い改良兼自我ページ整備が一段落した。
開発時間が確保しにくい時期だったことや交度整理に時間をかけたことで12月22日に着手してから日数はかかったが,総合的に満足出来る結果となった。
特に,実装時期の予測すら出来なかった自我ページ整備が出来たことが大きい。これで新生デライト像が完全なものになった。自我ページ整備自体の作業時間は正味2日間程度で,時間対効果も非常に高かった。
今後はまず新生全知検索整備に戻り,輪郭整備兼文書整備と並行させ新生デライトの成立を目指すことになる。
12月19日の検討通り,他自我内検索時に自我アイコンを並べ,自我ページではこれをプロフィール風に見せることにした(整備後1,整備後2)。
見ただけではまずやり方が分からなかった他自我内検索が整合的かつ直感的に行えるようになり,自我知番による検索結果に過ぎず一見意味の分からない自我ページ(整備前)も一応プロフィールページらしくなった。
自我ページは,デライトにおける自己表現の入り口となる部分であり,初めてデライトに触れた人がまず覗いてみる部分でもあるので,直感的に理解出来るようになったことは大きな進歩と言える。最低限の又情報も設定したので多少の SEO 効果も望める。あとは風船輪郭が出来れば,デライトのプロフィールページとしては無駄なく十分なものになるだろう。
一時,前縁で十全な切り替え機能を実装しようとして交度の肥大化に陥いりかけたが,自我の切り替え時にはページ遷移させて後縁の処理結果を利用することにした(2日)。
これにより,非常にすっきりした交度でまとめることに成功した。
少し迷ったのが,録入り中に自自我ページを表示したり自自我知番で検索したりした時にどうするかということだったが,これは単純にそのまま表示することにした(整備後3)。自自我アイコンが2つ並ぶのはどうかと思ったが,自分で自分を観ているのだから間違った表現ではないし,一貫性はある。
当初,自我アイコンに関しては通常の自輪郭検索と同じようにするつもりだったが,これはこれでぱっと見で状態が判別しにくいという問題がある。自我ページだけなら自我アイコン下の文言やメニューなどの非表示で分からなくもないが,分かりやすくはない。
通常の自輪郭検索との差別化のため,通常は省略している吹き描きの自我名や自我アイコンを表示させる機能を持たせても良さそうだ。
別案として,右側の自我アイコンを左右反転して鏡映しのようにするというのがあったものの,アイコンの同一性から生じる機能性を損うこと,他者からの見え方をイメージしやすくするプロフィールページとしての役割を損うこと,恐らくほとんど意図が伝わらないことといった理由で没にした。不具合か自我ページの仕様と誤解する人が一定数出てくるだろう。
@DG.sch
を中心とした交度整理の進展も本当努における大きな成果だった。
輪郭一覧動的更新対応で前縁の全知検索関連機能を @DG.sch
に集約したはいいが,整理している余裕はなかったので乱雑だった。ここも本当努を通じてすっきり整理出来た。検索語提案機能実装でも活かせるだろう。
比較的深刻なのは,輪郭一覧動的更新後の「戻る」先が求頼文字列のない自我ページや輪郭ページだった場合に正しくページを復元出来ない問題だった。
また,輪郭一覧動的更新で対応を忘れ全輪郭検索用背景・自輪郭検索用背景が切り替わらなくなっていた問題を修正すると同時に,他自我内検索も含めた自我内検索一般に無地の黒背景を適用することにした。自輪郭検索とそれ以外で分けるかで少し迷った。元々,竜胆蛍の入った背景は賑わいを表現したものだったので,これの方が本来の意図に適うだろう。
その他,例えば & ボタンのキーボード入力時に検索語が空になっても削除ボタンが消えないといった軽微な不具合や,交度の未整理による細かい挙動・装体の不整合といった問題が解消されている。