{希哲17年1月29日の開発}{希哲17年1月29日の進捗}{希哲17年1月29日}{利用しつつ}{新しい観点}{他当努}{側面支援}{希哲17年1月29日の進捗時限}{希哲17年1月12日17歩}{装体整理兼ダークテーマ実装}...=}(35)

{希哲17年1月29日5歩 K#F85E/E74C-93F6}

ここでダークテーマ実装に入る。

12日17歩で「装体整理兼ダークテーマ実装」の可能性に気付いてから，それまで単純なコストと見ていた実装作業に他当努の側面支援という役割が期待出来るようになっている。

まずは非公開機能として使えるようにし，ダークテーマという新しい観点を利用しつつ装体整理を進めていく。実用水準に達したところで公開すればいい。

途中で終了。

=}
{希哲17年1月28日の開発}{希哲17年1月28日の進捗}{希哲17年1月28日}{こうして}{追加せず}{余力が無い}{著作権上}{濫用される}{対応済み}{「複写失敗：描写が空ではありません」}...=}(158)

{希哲17年1月28日21歩 K#F85E/E74C-46A3}

（進捗時限記録中略）

また新生デライトの要件外ではあるが，ついさっき，急に実装イメージがまとまってしまった輪郭複製機能実装で終了。出振るい・手定め済み。

描写欄が空の状態の新規描出フォームで，自輪郭の輪符を知名欄に貼り付けるかドロップすると輪符から知名・描写が複写される。

複写に成功すると「複写完了」と表示，「複写失敗：自分の輪郭ではありません」と「複写失敗：描写が空ではありません」の違了表示も付け，自我知番の省略にも対応済み。使い勝手は非常に良好。

これまで通り「輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが，眠気で考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが，「輪郭複製のための機能」という意味ではそこまで間違っていない。

輪郭複製機能については，昨年5月18日の開発で「知名・描写を複製して新規描出フォームに移動するボタン」として実装することを考えたが，その後の用合い改良を経て，抵抗感が募っていた。

輪郭を直接複製するような機能はやはり避けたい。手軽にし過ぎると誤操作や濫用の可能性が高まる。適切な手間という点で，新規描出フォームへの複写というアイデアは悪くなかった。ただ，現状の輪郭選り手が理想的にまとまっているので，極力ボタンのような要素を追加したくないと思うようになった。

さっきふと，「知名欄への輪符貼り付け」という案について考えていたら，これが急速にまとまってしまった。過去にも何度か脳裏をよぎった案だが，その時はいまいち気乗りしなかった。

貼り付け方式の最初の懸念は誤入力だった。復元ボタンだけでは心許ないので，知名が空であることを条件にしようとしたが，空の知名で書き始めることは少なくないので中途半端だ。複製したい輪郭を検索してから写し取り，貼り付けという流れを考えると，知名欄をいちいち空にしなければならないのは煩雑過ぎる。

間もなく，描写欄が空という条件なら全く問題ないことに気付いた。誤操作の懸念がなくなったので，ドラッグ＆ドロップにも対応することにした。

もう一つ，自輪郭のみという制限を付けることにした。描写内の自我知番の省略に Aejs で対応するのが難しいという問題もあるが，濫用され著作権上の手溢れが増えることが予想される。他人の描写の扱いは慎重に，という意味でもこれくらいが適切だろう。

こうしてするする実装イメージがまとまり，一通りの機能を付けた実装も難なく完了した。余計な視覚要素を追加せず，それでいて直感的という，理想的な輪郭複製機能があっという間に出来てしまった。

=}
{希哲17年1月21日の開発}{希哲17年1月21日の進捗}{希哲17年1月20日の開発}{希哲17年1月21日}{やや冗長}{〈chemical equation〉}{化学記法実装}{数学記法}{化学式記法}{化学記法}...=}(47)

{希哲17年1月21日14歩 K#F85E/E74C-4311}

（進捗時限記録中略）

急遽化学記法実装で終了。

数式記法の \[\ce{ ... }\] に対応する \ce[ ... \]，\(\ce{ ... }\) に対応する \ce( ... \) を追加した。

バックスラッシュ後の文字列は，chem では冗長，c では誤認・衝突の可能性があるため，mhchem との関連が分かりやすい ce にしておいた。〈chemical equation〉の略だそうだ。

名称は「化学式記法」を考えていたが，正確ではない上にやや冗長なので，とりあえず「化学記法」としておいた。それだと数式記法も「数学記法」にしたくなるが，これは考えておく。

交度埋め込み記法で mhchem に対応してほしいという要望をもらった時，そこまでするなら化学記法を作ってしまった方がすっきりするなとは思ったが，数式記法すらさほど使われていない現状では時期尚早の感が強かった。

昨日の開発記録をまとめたりしているうちに実装イメージがあっさり出来てしまった。

手定め済み・未出振るい。

=}
{希哲17年1月16日の副日記}{この手の}{埋め込み献典}{検討しておく}{発生しうる}{客体変数}{無駄な通信}{タグ削除}{通信時間}{従来の方式}...=}(242)

{希哲17年1月16日の開発 K#F85E/E74C-6ADB}

作業方針検討（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 的なことを考えていたことはあるので，その辺の都合だったのだろうと思ったが，現状，そこまで最適化する必要も時間も無い。出来たとして，隠しを有効利用出来る握接パターンは限られている。いずれにせよ，この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで，いったん，埋め込み処理は前縁に移すことにした。

読み込み中...
=}(7){希哲17年1月16日13歩}{希哲17年1月16日10歩}{希哲17年1月16日9歩}{希哲17年1月16日8歩}{希哲17年1月16日7歩}{希哲17年1月16日5歩}{希哲17年1月16日4歩}
{希哲17年1月14日の開発}{復活させたい}{思い入れが無い}{忘れた場合}{希哲17年1月14日の進捗}{希哲17年1月14日}{暗証語再発行用メールアドレス}{検討を進めている}{外充て函数化}{認証機能}...=}(146)

{希哲17年1月14日10歩 K#F85E/E74C-1CAF}

（進捗時限記録中略）

認証周りの全体的な検討を進めて終了。

暗証語再発行機能については，いくつかの仕様が明確になった。

暗証語再発行機能

再発行用メールアドレス

再発行用メールアドレスは同じものを複数の自我で登録可能とすることにした。

出場上での重複を禁じた場合，過去に適当に登録して忘れているせいでメールアドレスが使えなくなることが考えられる。登録時には確認用 URL への握接を要求するので他人のメールアドレスを登録することは出来ないが，自分でも忘れるのはネットではよくあることだ。

この場合，メールアドレスから自我が一意に特定出来なくなるが，これは問題ないだろう。どのみち暗証語再発行手続きでは，メールアドレスから引き出せる情報は最小限にしたい。多用するものでもないので，自我知番は都度入力してもらえばいい。

自我知番を忘れた場合も想定していたものの，そこまで思い入れが無い自我を復活させたいという人も稀だろう。

読み込み中...
=}
{希哲17年1月12日の開発}{希哲17年1月12日の進捗}{希哲17年1月12日}{装体整理兼ダークテーマ実装}{効率的な作業}{画像素材調整}{何でもない}{ここまでは}{付け外し}{設定輪結}...=}(83)

{希哲17年1月12日17歩 K#F85E/E74C-66E2}

（進捗時限記録中略）

ダークテーマ実装も新生全知検索整備に戻る前に進めておくことにした。ただし，実用水準に達するまでは非公開機能としておく。方針をまとめ終了。

用合いや実装方法は昨年には固まっていた。

未録入りの場合はメニューの設定輪結の部分に，録入り中の場合は設定ページの右上あたりにテーマ切り替えボタンを置き，クッキーを使い後縁から <body> に .drk を付け外しする。

ここまでは何でもない作業だが，問題は装体調整と画像素材調整の手間暇だった。ある程度機能追加などが落ち着かないと効率的な作業は出来なかった。

6日7歩で hue-rotate() が意外と使えることに気付き，従来の @img による画像補完の段階的置換を考えていたことで，画像素材調整の手間はだいぶ省けることに気付いた。外観に大きく影響するような機能追加もほとんど終わっているので，機が熟した感がある。

もう少し装体整理してからとも思っていたが，こればかりはキリがない。実験くらいは始めておいていいだろう。

ここまで書いて「装体整理兼ダークテーマ実装」の可能性に気付いた。

=}(3){希哲17年1月29日5歩}{希哲17年1月14日6歩}{希哲17年1月12日の開発}
{暗証語再発行用メールアドレス}{希哲17年1月12日の開発}{希哲17年1月12日の進捗}{希哲17年1月12日}{現在の暗証語}{入力する}{新しい暗証語}{再設定時}{autocomplete="current-password"}{autocomplete="new-password"}...=}(138)

{希哲17年1月12日13歩 K#F85E/E74C-1D2C}

（進捗時限記録中略）

暗証語再設定機能も新生全知検索整備に戻る前に実装してしまうことにし，方針をまとめて終了。

これまで一緒に考えることが多かった暗証語再発行機能とは切り離す。また，同時に暗証語表示機能も実装することにした。

昨日，デラングで埋め込み記法の拡充をしているついでに TwEgaku 対応を思いつき，TwEgaku の手定めをした。その時，暗証語表示機能があるのを見たのがきっかけで，なんとなくデライトでの実装を考え始めた。

そして今日，再設定機能の早期実装を思いついたが，これは表示機能について考えていたことと関係がありそうだ。

必要性が高く実装コストの低い再設定機能実装をここまで遅らせてきたのは，デライトでは特に誤設定の危険性が高いからだ。十分に基礎実装の信頼性が高まり，再発行機能のような保険が無ければ，かえって深刻な問題を招きかねない。しかし，再発行機能実装は SMTP 関連の実装や設定の整理も必要で，なかなか時間対効果と優先順位を上げられなかった。

デライトの信頼性も再設定機能の必要性も十分に高まったこの時期に，誤設定の可能性を多少軽減する表示機能が背中を押してくれた気がする。暗証語の「見えない怖さ」がデライトでは思いのほか大きかったことにも気付かされた。

読み込み中...
=}(1){希哲17年1月12日の開発}
{希哲17年1月6日の副日記}{考えなくてはならない}{高くなる}{誤編集}{起きてくる}{横断する}{様子を見ていた}{意図したこと}{それ以前}{細かい不具合}...=}(93)

{希哲17年1月6日の開発 K#F85E/E74C-4249}

深刻な不具合修正とボタン周りの挙動改良，輪郭削除ボタンでのみ輪郭削除が機能するように仕様を明確化・実装修正し装体調整（7歩）。これまでも輪郭削除ボタンを押下するのが輪郭削除の公式手順だったが，実装上は知名・描写を空にして送信すれば機能した。

不具合修正と輪郭削除ボタンの装体調整がきっかけで，やりたかった輪郭選り手の変更有無を表現する閉じるボタン（×ボタン）の装体イメージもまとまった。

検討中に新規描出フォームの細かい不具合も見つけたのでまとめて調整することにした。

第二次用合い改良でそれ以前にあった「知名欄にマウスオーバーすると自動的に捕活・全選択する」という機能が消えていたが，これを復活させるか検討。

特に意図したことではなく，当初は単に交度整理後の再実装を後回しにしていただけなのだが，これはこれで悪くないかもしれないと様子を見ていた。やはり写し取りに不都合を感じることが多く，全知検索窓との挙動の整合性もあるので復活に傾きかけていたものの，もう少し様子を見ることにした。

マウスカーソルが頻繁に横断する部分なので，捕活がころころ移ると別の問題が色々起きてくるだろう。これをやると描写欄にもマウスオーバーで捕活させたくなるが，そうなると誤編集の可能性も高くなる。その他，スクロールとの干渉など，相互作用を色々考えなくてはならない。

=}(4){希哲17年1月7日の開発}{希哲17年1月7日の日記}{希哲17年1月7日20歩}{希哲17年1月7日12歩}
{希哲17年1月6日の進捗}{便利だった}{lightpink}{pink}{誤認しやすかった}{同じ装体}{輪郭削除ボタンの様子・装体調整後}{輪郭削除ボタンの様子・装体調整前}{完了ボタンの様子}{配灯時}...=}(116)

{希哲17年1月6日7歩 K#F85E/E74C-4A35}

（進捗時限記録中略）

スマホから連続タップで輪郭が削除されてしまったという深刻な不具合報告を受け，修正作業と輪郭削除ボタンの装体調整。

不具合については，描き直しボタンの連打で読み込み中に送信が発生し，知名・描写が空の状態なので輪郭削除と認識してしまう，という可能性が濃厚だったため，以下の修正を行った。

b_cfm_udrw のような求頼変数を付けて後縁でも確認させることを検討したが，現時点では過剰と判断し見送った。どの道，前縁が間違った出与えを送れば危険性は大して変わらない。むしろ，上書きされるより輪郭削除が間違って動作してくれた方が取り返しがつく。

読み込み中...
=}(2){希哲17年1月12日17歩}{希哲17年1月6日の開発}
{希哲16年12月25日}{間をあけている}{3ヶ月近く}{高まってきた}{くらくらする}{希哲16年12月24日}{希哲16年12月の日記}{振り返り日記}{日記}{希哲17年2月13日}...=}(25)

{希哲16年12月24日の日記 K#F85E/E74C-9E24}

くらくらするような急展開と脳爆発で，頭の整理に一日のほとんどを費した。

デライト3周年（2月13日）までの完全な成功の可能性が十分に高まってきたため，明日からまた律動的集中生活に入ることにした。3ヶ月近く間をあけているので問題ないだろう。

（25日の振り返り日記）

=}(1){希哲16年12月24日の副日記}
{可能性}

{}