{希哲16年8月の開発}{_dg}{調査する}{特有の問題}{根本的な解決}{無理そう}{負荷抑制}{選択肢が増える}{高負荷求頼}{見られなかった}...=}(102)

{希哲16年8月20日の開発 K#F85E/E74C-1175}

応答速度異常に遅い輪郭についての不具合調査から求頼改良出場改良アイデアまとまり,一気に実装した

_dg_dg_oln結合しないと揃え出来ず揃え極端に遅くなる場合があることは認識していたが,時印追加することは正規化観点から避けてきた

公開設定機能導入必要性が低くなった揃え用時印廃案にすることを最近考えていたが,これに近い役割持たせた ts_fgts_bg追加することを思い付き,急速にまとまった単なる複製ならやはり避けたかったが,より抽象的な時印_dg持っていることは不自然ではなく,同期引き入れ再描出処理行うだけでいい。

手定めしてみると,低負荷求頼では索引使われず有意差見られなかったものの,高負荷求頼では数倍から十倍程度までの高速化見られた求頼最適化選択肢が増えることでサービス全体負荷抑制見込める

領下での実装手定め終えたが,稼動させながらの _dg修正無理そうなので明日早朝出振るいすることにした。


これにより応答速度異常に遅い輪郭についても改善見られたが,異常であることは変わらず根本的な解決にはならなかった。

当初輪括膨大な輪郭特有の問題だろうと思っていたが,一見何でもなさそうな輪郭でも発生している

これは別途調査することにした。


ここで,検討していた揃え用時印ts)は正式に廃案とすることにした。

簡単な時印更新可能になり,公開設定機能目立たせない再描出可能になったので必要性感じなくなった。となると実装用合い複雑化懸念大き過ぎる

{}{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{Aejs_DG_rev}{長期的視野に立って}...=}(225)

{希哲16年5月23日の開発 K#F85E/E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

=}
{進捗記録}{希哲16年2月15日10歩}{検討を続ける}{閉じタグ}{区切り記号}{スペース区切り}{希哲16年2月15日の開発}{希哲16年2月15日の進捗}{希哲16年2月15日の進捗時限}{希哲16年2月15日}...=}(40)

{希哲16年2月15日12歩 K#F85E/E74C-3C2C}

進捗時限記録中略

10歩検討関連して,タグ記法略記法前景色背景色をどう書き分けるかについて少し検討して終了

廃案となった色記法では,順序はともかく)%%black white%% のようにスペース区切りがいいかと思っていたが,これだとどちらか一方だけを指定したい時に困る。どちらを省略したか分かりやすい区切り記号欲しい

<{black:white}> では直感的にどちらがどちらだか分かりにくい。単純に一つだけ指定した場合は前景色にしたいことを考えると,<{前景色/背景色}> がいいかもしれない(ただ,後で考えると閉じタグ記号紛らわしいか)

<{前景色<背景色}> のように <> を使えれば関係性分かりやす順序にも自由度持たせられるが,そもそもタグ記法で使う記号なので美しくはない

もう少し検討を続ける

=}
{用者}{HTML}{HTML5}{デラング}{進捗記録}{高い}{あれ}{役割を持たせる}{役割を持つ}{緩衝的}...=}(248)

{希哲16年2月15日10歩 K#F85E/E74C-2CA8}

進捗時限記録中略

昨日寝る直前にまた脳爆発があり,今朝にかけて文字装飾記法タグ記法周りの概念整理仕様整理急速に進んだ

文字装飾記法は,「文字装飾を伴う慣用表現」のための記法位置付けることにした。太字記法##斜体記法//下線記法__打ち消し線記法~~翌日のまとめで「打ち消し記法」から改称4記法基本とし,それぞれ所定装体スタイルを伴う <b><i><u><s> HTML 要素対応する

@ を使った文字サイズ記法% を使った色記法検討していたが,タグ記法概念が出来たことで中途半端なものになるため,これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つ検討方針

実装自体は容易部類で,記法概ね固まっていたにもかかわらず文字装飾記法実装踏み切れなかった理由として意味論的な問題があり,これが思いのほか難題だった。実装方針3通り考えられる

  1. 完全に意味論的な記法にする
  2. 完全に装飾的な記法にする
  3. 意味論装飾重ね合わせた記法にする

記法趣旨からしても,軽量標記マークアップ言語特性を考えても,1つ目に無理があるのは明らかだ。対応する HTML<b><i><u><s> は,私が何度解説を読んでもややこし感じる代物だ。それを多くの人正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系捨てることになるが,代替案があるわけでもない。

かといって,2つ目ももったいない。要は <span>装体指定だけにするということだが,例えば,太字にはしたいが <b> にはしたくない場合打ち消し線引きたい<s> にはしたくない場合がどれだけあるのかと考えると,無難通り越して臆病過ぎる失う可接性アクセシビリティ応用可能性釣り合わない

最終的に採用することになった3つ目も,全く考えなかったわけではないが,柔軟性に欠け,前の2つの悪い所組み合わされる気もして,有力案にはなっていなかった。

タグ記法による書き分け

この膠着状態変えたのは,前日概念としてまとまったばかりのタグ記法だった。

これまで,デラングにおける HTML は,どうしてもデラング出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで,積極的に使うことを想定していなかった。実際個人的にはほとんど使っておらず放置している不具合多い部分だった。

デラングタグ記法として間接的に HTML使うことで,略記法導入可能になり,HTML 側の仕様変更に対しても一定の緩衝帯設けることが出来る。ここに来て初めて文字装飾記法でも「書き分け」が考えられるようになった文字装飾記法対応しうるのが全て1文字要素だったことも幸いした

昨日寝る直前に,##太字的な表現##<{font-weight:bold}>太字</> のように書き分けるよりも,##太字##<b>太字的な表現</b> のように書き分ける方がマシであることに気付いて,1つ目の実装方針完全に潰せた

これにより一時的に2つ目の実装方針再浮上したが,標準的に使う記法として標準的な用途最適化不足なのはやはり否めなかった

決着

最終的に,「文字装飾を伴う慣用表現」という用者自然に理解出来る範囲での意味論的位置付け与え逸脱する用途ならタグ記法書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針洗練させた格好になる。

例えば##太字## は「太字装体<b>」に対応する装体邪魔なら <b>太字的な表現</b>書けるし,意味邪魔なら <{font-weight:bold}>太字</>略記法検討段階のように書けるが,これらの場合稀少なのは明らかで,記述量上手く釣り合うワープロならともかく,軽量標記言語手書きしようという人にとって難しい使い分けではないだろう。

そもそも<b><i><u><s> は,古くからある視覚的要素HTML5慣用的な用途引き継いで意味論化されたものなので,「文字装飾を伴う慣用表現」と非常に相性が良い相互変換にも全く問題ない

何より,直感的に入力すれば構造的に出力されるというデラングの理想適っている

文字サイズ記法色記法廃案

文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで,慣用表現を持たない文字サイズ記法色記法仲間外れになるが,タグ記法によって出る幕がなくなった感があるので,ここで廃案にすることとした。

第一に,タグ記法略記法整備した方が一貫性応用可能性高い特定プロパティ省略出来るようにし,<{white}>白い文字</> のように書ければ,%white%白い文字%% と書くのと記述量大差ない

もともとパラメーター必要とする記法異質感はあり,文字装飾記法統一感損うかという懸念はあったので丁度良かった

波及的検討

波及的に,いくつかこまごまとした検討進んだ

組み合わせは「」ではなく「入れ子」へ

これまで,複数文字装飾記法組み合わせ#/太字と斜体/# のように,「記号を1つずつ逆さにした終了記号挟む」といったややこしい説明考えていたが,##//太字と斜体//## のような「入れ子」を #/太字と斜体/#短縮出来るという考え方にした方が分かりやすいため改めることにした。

タグ記法発展

今回検討で,タグ記法早くも実践的な役割を持つことになり,デラングにおける存在感一気に増した

タグ記法HTML仕様変更対する緩衝的役割を持たせること,要素名省略<span> にすることを考え始めた

{進捗記録}{導入する}{文字装飾記法}{下線記法}{斜体記法}{太字記法}{打ち消し線記法}{希哲16年1月23日16歩}{微妙な要求}{たまにあった}...=}(94)

{希哲16年1月23日12歩 K#F85E/E74C-5AE3}

進捗時限記録中略

3歩きっかけ久しぶりに実装予定文字装飾記法について見直し,以下のように基本的方針整理した

<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~

下線記法については,_下線_有効にすることも考えていたが,適当に書いた時の誤解釈増える懸念もあり見送ることにした。文字装飾記法2個以上記号統一した方が綺麗にまとまる簡潔な記法追加するより削除する方がずっと難しいので,使用頻度考えてもいまあえて導入する動機に乏しい

……ここまで考えて昨年6月23日10歩でも同じ結論を出していたことに気付いたが,再確認出来た。


太字記法については,昨年6月23日9歩では ++太字++検討しているものの,最近 ++行内埋め込み記法利用することを考えているためこれは避けたい。そもそも「強調ではない太字」という微妙な要求のための記法であり,廃案脳裏をよぎった

分かりやすい代替記法がありうるのかと思ったが,意外と ##太字##悪くない。「くっきりした」という意味シャープにもかかっているし,見た目濃さ丁度良い後述文字サイズ記法同様,記号の数濃さ調整出来ても面白い


ついでに<<大きい文字>>>>小さい文字<< という文字サイズ記法思いついた大きさ小ささ記号の数調整出来てもいい。直感性申し分ない

あまり文字を大きくしたい思ったことはないが,小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあったので良い拾い物だった。


斜体記法打ち消し記法については特に変更無し


上線記法検討していたが,ここまでで HTML の要素相当するものはい,軽標記言語としての表現力十二分なので,いったんここで一区切りとすることにした。

{進捗記録}{AsciiDoc}{特殊な例}{生じていた}{再確定}{ボタン記法}{希哲16年1月23日の進捗時限}{希哲16年1月23日の進捗}{希哲16年1月23日}{行内埋め込み記法}...=}(55)

{希哲16年1月23日4歩 K#F85E/E74C-6C79}

キーボード記法についての再検討終了

キーボード記法に関しては,改めて [_X_] 記法中心にしていく方針再確定した。また,[_X_] + [_Y_] を一つの記法として扱うことも明確化した。


[_X_] 記法導入して一件落着かと思ったキーボード記法だが,その後,少し迷い生じていた

この記法ボタンらしく見え過ぎるせいで,ウィジェットボタンにも応用出来る「ボタン記法」のようなものも可能なのではないかというが出てしまっていたAsciiDoc にはボタンメニュー表現出来るマクロがある)。それが可能なら,[_X_]キーボード記法とすべきではないかもしれない,という気がした

ただ,[_X_]キーボード記法一般化した「ボタン記法」にしようかと考えてみたところで,そもそも千差万別外観を持つウィジェットボタン抽象的表現出来る装体存在しないことに気付いて廃案となった。確かに記号としてみるとボタンらしいのだが,ボタンらしい装体を付けようとすると全くイメージと違うものになってしまう。これではあまり意味が無い。あくまでも言語的に扱うか,視覚的に扱いたければ画像素材行内埋め込み記法挿入するのが適切だろう。

そう考えると,キーボードキーに使う装体キー記号としてちゃんと機能するのは特殊な例だ。

=}
{デライト}{用者}{開発}{開発記録}{領当て}{手定め}{Android}{iOS}{共有ボタンを追加しました!}{タッチ端末}...=}(71)

{希哲15年3月27日の開発 K#F85E/E74C-1FE0}

主に共有ボタン実装

想像以上に確認調整しなければならないことが多く手間取ったが,それでも OGP 対応作業開始からわずか2日納得出来る形になった。



予定通り,採用サービスは FacebookTwitterLINEはてなブックマークPocket日本国内利用者数の多いサービスをより共有ボタンに近付ける形で配置した。

Web Share API に対応していれば省略記号(...)が表示され,それを押すと端末ネイティブ共有機能利用出来る。省略記号の画像には全知検索ページャーに使っている ell.x2.png がそのまま使えた。AndroidiOS動作確認済み

当初,不揃いな各ボタンを整然と並べるために四分円を使い,横長の Twitter と Facebook,正方形の LINE とはてブ,最後に Pocket,と三段で構成することを考えた扇形共有ボタン部区が,これは廃案とした。試してみると意外と悪目立ちしたため別の領当てを模索していたところ,二段目の余った左余白に Pocket と省略記号を並べれば綺麗にまとまることに気付いた。

例えば同じ形状モノクロにするなど,よくあるアレンジを加えようかとも思ったが,各サービスの利用規約に抵触する可能性がある上,用者にとっては一見して分かりにくいものになりがちなので,公式のものをそのまま利用することにした。

各サービスの徹案依存する格好にはなるものの,TwitterFacebook に合わせているのだろうし,LINE正方形ボタンを変える理由もなく,はてブは柔軟性があるのでそれなりに安定して使える領当てではないかと思う。

用合いとしては,共有ボタンへのマウスオーバー小窓を開き,小窓からのマウスアウトで閉じるようにした上で,タッチ端末向けにクリックタップ)での開閉も出来るようにした。触り心地良好だ。

でもデライト語体の右下に置いておくことにした(デライト扉の様子・共有ボタン実装後)。

ソーシャル ボタンは,徹案の上でも処理の上でも雑然としたものになりがちなので,単純性重視しているデライトでの採用は見送り続けてきた。普段は邪魔にならず,かといって手間にもならず,用者にとっては分かりやすく,そこそこ美しくも見える……と,限りなく理想形に近いものが出来たと思う。

LINEPocket は使ったことがなかったため,本機能の手定めのためにアカウントを取った。



エクスポート機能仕様検討も進んだ(9歩)。

{開発}{開発記録}{領当て}{希哲14年7月30日8歩}{輪括内検索}{希哲14年7月30日}{吊るし検索}{仕様検討}{全知検索窓}{位置付け}...=}(16)

{希哲14年7月30日の開発 K#F85E/5B28-3893}

主に仕様検討など。

特に,懸案だった全知検索窓機能領当て方針がまとまった(8歩)。

吊るし検索でしばらく考えていた,検索窓を最上部・吹き描き内2箇所に表示する案はいったん廃案とし,輪括内検索位置付け整理優先順位を下げた。結局,最も単純な形で落ち着いた。

{廃案}

{}