12日17歩で「装体整理兼ダークテーマ実装」の可能性に気付いてから,それまで単純なコストと見ていた実装作業に他当努の側面支援という役割が期待出来るようになっている。
まずは非公開機能として使えるようにし,ダークテーマという新しい観点を利用しつつ装体整理を進めていく。実用水準に達したところで公開すればいい。
また新生デライトの要件外ではあるが,ついさっき,急に実装イメージがまとまってしまった輪郭複製機能実装で終了。出振るい・手定め済み。
描写欄が空の状態の新規描出フォームで,自輪郭の輪符を知名欄に貼り付けるかドロップすると輪符から知名・描写が複写される。
複写に成功すると「複写完了」と表示,「複写失敗:自分の輪郭ではありません」と「複写失敗:描写が空ではありません」の違了表示も付け,自我知番の省略にも対応済み。使い勝手は非常に良好。
これまで通り「輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが,眠気で考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが,「輪郭複製のための機能」という意味ではそこまで間違っていない。
輪郭複製機能については,昨年5月18日の開発で「知名・描写を複製して新規描出フォームに移動するボタン」として実装することを考えたが,その後の用合い改良を経て,抵抗感が募っていた。
輪郭を直接複製するような機能はやはり避けたい。手軽にし過ぎると誤操作や濫用の可能性が高まる。適切な手間という点で,新規描出フォームへの複写というアイデアは悪くなかった。ただ,現状の輪郭選り手が理想的にまとまっているので,極力ボタンのような要素を追加したくないと思うようになった。
さっきふと,「知名欄への輪符貼り付け」という案について考えていたら,これが急速にまとまってしまった。過去にも何度か脳裏をよぎった案だが,その時はいまいち気乗りしなかった。
貼り付け方式の最初の懸念は誤入力だった。復元ボタンだけでは心許ないので,知名が空であることを条件にしようとしたが,空の知名で書き始めることは少なくないので中途半端だ。複製したい輪郭を検索してから写し取り,貼り付けという流れを考えると,知名欄をいちいち空にしなければならないのは煩雑過ぎる。
間もなく,描写欄が空という条件なら全く問題ないことに気付いた。誤操作の懸念がなくなったので,ドラッグ&ドロップにも対応することにした。
もう一つ,自輪郭のみという制限を付けることにした。描写内の自我知番の省略に Aejs で対応するのが難しいという問題もあるが,濫用され著作権上の手溢れが増えることが予想される。他人の描写の扱いは慎重に,という意味でもこれくらいが適切だろう。
こうしてするする実装イメージがまとまり,一通りの機能を付けた実装も難なく完了した。余計な視覚要素を追加せず,それでいて直感的という,理想的な輪郭複製機能があっという間に出来てしまった。
数式記法の \[\ce{ ... }\]
に対応する \ce[ ... \]
,\(\ce{ ... }\)
に対応する \ce( ... \)
を追加した。
バックスラッシュ後の文字列は,chem
では冗長,c
では誤認・衝突の可能性があるため,mhchem との関連が分かりやすい ce
にしておいた。〈chemical equation〉の略だそうだ。
名称は「化学式記法」を考えていたが,正確ではない上にやや冗長なので,とりあえず「化学記法」としておいた。それだと数式記法も「数学記法」にしたくなるが,これは考えておく。
交度埋め込み記法で mhchem に対応してほしいという要望をもらった時,そこまでするなら化学記法を作ってしまった方がすっきりするなとは思ったが,数式記法すらさほど使われていない現状では時期尚早の感が強かった。
昨日の開発記録をまとめたりしているうちに実装イメージがあっさり出来てしまった。
作業方針検討(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 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状,そこまで最適化する必要も時間も無い。出来たとして,隠しを有効利用出来る握接パターンは限られている。いずれにせよ,この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで,いったん,埋め込み処理は前縁に移すことにした。
再発行用メールアドレスは同じものを複数の自我で登録可能とすることにした。
出場上での重複を禁じた場合,過去に適当に登録して忘れているせいでメールアドレスが使えなくなることが考えられる。登録時には確認用 URL への握接を要求するので他人のメールアドレスを登録することは出来ないが,自分でも忘れるのはネットではよくあることだ。
この場合,メールアドレスから自我が一意に特定出来なくなるが,これは問題ないだろう。どのみち暗証語再発行手続きでは,メールアドレスから引き出せる情報は最小限にしたい。多用するものでもないので,自我知番は都度入力してもらえばいい。
自我知番を忘れた場合も想定していたものの,そこまで思い入れが無い自我を復活させたいという人も稀だろう。
ダークテーマ実装も新生全知検索整備に戻る前に進めておくことにした。ただし,実用水準に達するまでは非公開機能としておく。方針をまとめ終了。
未録入りの場合はメニューの設定輪結の部分に,録入り中の場合は設定ページの右上あたりにテーマ切り替えボタンを置き,クッキーを使い後縁から <body>
に .drk
を付け外しする。
ここまでは何でもない作業だが,問題は装体調整と画像素材調整の手間暇だった。ある程度機能追加などが落ち着かないと効率的な作業は出来なかった。
6日7歩で hue-rotate()
が意外と使えることに気付き,従来の @img
による画像補完の段階的置換を考えていたことで,画像素材調整の手間はだいぶ省けることに気付いた。外観に大きく影響するような機能追加もほとんど終わっているので,機が熟した感がある。
もう少し装体整理してからとも思っていたが,こればかりはキリがない。実験くらいは始めておいていいだろう。
ここまで書いて「装体整理兼ダークテーマ実装」の可能性に気付いた。
autocomplete="current-password"
}{autocomplete="new-password"
}...暗証語再設定機能も新生全知検索整備に戻る前に実装してしまうことにし,方針をまとめて終了。
これまで一緒に考えることが多かった暗証語再発行機能とは切り離す。また,同時に暗証語表示機能も実装することにした。
昨日,デラングで埋め込み記法の拡充をしているついでに TwEgaku 対応を思いつき,TwEgaku の手定めをした。その時,暗証語表示機能があるのを見たのがきっかけで,なんとなくデライトでの実装を考え始めた。
そして今日,再設定機能の早期実装を思いついたが,これは表示機能について考えていたことと関係がありそうだ。
必要性が高く実装コストの低い再設定機能実装をここまで遅らせてきたのは,デライトでは特に誤設定の危険性が高いからだ。十分に基礎実装の信頼性が高まり,再発行機能のような保険が無ければ,かえって深刻な問題を招きかねない。しかし,再発行機能実装は SMTP 関連の実装や設定の整理も必要で,なかなか時間対効果と優先順位を上げられなかった。
デライトの信頼性も再設定機能の必要性も十分に高まったこの時期に,誤設定の可能性を多少軽減する表示機能が背中を押してくれた気がする。暗証語の「見えない怖さ」がデライトでは思いのほか大きかったことにも気付かされた。
深刻な不具合修正とボタン周りの挙動改良,輪郭削除ボタンでのみ輪郭削除が機能するように仕様を明確化・実装修正し装体調整(7歩)。これまでも輪郭削除ボタンを押下するのが輪郭削除の公式手順だったが,実装上は知名・描写を空にして送信すれば機能した。
不具合修正と輪郭削除ボタンの装体調整がきっかけで,やりたかった輪郭選り手の変更有無を表現する閉じるボタン(×ボタン)の装体イメージもまとまった。
検討中に新規描出フォームの細かい不具合も見つけたのでまとめて調整することにした。
第二次用合い改良でそれ以前にあった「知名欄にマウスオーバーすると自動的に捕活・全選択する」という機能が消えていたが,これを復活させるか検討。
特に意図したことではなく,当初は単に交度整理後の再実装を後回しにしていただけなのだが,これはこれで悪くないかもしれないと様子を見ていた。やはり写し取りに不都合を感じることが多く,全知検索窓との挙動の整合性もあるので復活に傾きかけていたものの,もう少し様子を見ることにした。
マウスカーソルが頻繁に横断する部分なので,捕活がころころ移ると別の問題が色々起きてくるだろう。これをやると描写欄にもマウスオーバーで捕活させたくなるが,そうなると誤編集の可能性も高くなる。その他,スクロールとの干渉など,相互作用を色々考えなくてはならない。
lightpink
}{pink
}{誤認しやすかった}{同じ装体}{輪郭削除ボタンの様子・装体調整後}{輪郭削除ボタンの様子・装体調整前}{完了ボタンの様子}{配灯時}...スマホから連続タップで輪郭が削除されてしまったという深刻な不具合報告を受け,修正作業と輪郭削除ボタンの装体調整。
不具合については,描き直しボタンの連打で読み込み中に送信が発生し,知名・描写が空の状態なので輪郭削除と認識してしまう,という可能性が濃厚だったため,以下の修正を行った。
b_cfm_udrw
のような求頼変数を付けて後縁でも確認させることを検討したが,現時点では過剰と判断し見送った。どの道,前縁が間違った出与えを送れば危険性は大して変わらない。むしろ,上書きされるより輪郭削除が間違って動作してくれた方が取り返しがつく。