{希哲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]URLoEmbed必要とする場合Dex では適当な分類名付与した <div>出与え属性URL埋め込んで描写 HTML返すAejs ではそれを検知し,URL/mbd転送する/mbdURL対応したサービス埋め込み交度oEmbed取得して返す,という流れになる。過剰な立求抑止するため,Aejs には簡易的な隠し持たせておいた

想像していたよりすっきり実装出来た


そもそもきっかけは,先日の SlideShare 対応だった。oEmbed必要になったので,埋め込みツイート使っていた Dex 内の oEmbed 埋め込み方法取り急ぎ使った。ただ,記法処理範枠同期通信処理組み込むというのは正気の沙汰ではないなんでこんな実装になっているのか,引っかかりはあった。

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

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

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

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

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

{暗証語再発行用メールアドレス}{希哲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 関連実装設定整理必要で,なかなか時間対効果優先順位上げられなかった

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


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

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

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


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

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


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

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

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

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

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

{可能性}

{}