{デライト}{OFFSET}{減らせる}{付けたかった}{ts_upd}{利用しやすくなった}{実装しておいた}{一覧部分}{整備した}{隠し効率}...=}(210)

{希哲16年6月30日の開発 K#F85E/E74C-A106}

デライト高速化における KNEST 隠し実装一段落した。18日作業方針検討のみで20日から,休日除いてちょうど10日間での達成だった。出振るい済み

全体としては大成功だった。

必要以上に固め過ぎるのも良くないため,隠し化現時点最低限必要範囲留めたが,期待以上安定性期待通り高速化得られた次の施策出来たので,まだまだ高速化出来るKNEST 隠しDex匹敵するデライト武器になるだろう。

交度整理しっかり進めたこともあり最初の輪数取得改良想定以上に長引いたものの,ここで KNEST 隠し共通の問題ほとんど解決したため,自我隠し輪郭隠し半日ほどで終わった。この交度整理収穫として大きかった輪郭操作系の kn の外充て函数整備したことで関連交度一気に整理された

影響範囲確率的に大きな問題はないだろうと見て排他制御甘い部分あえて残して出振るい急いだが,出振るい直後壊衝多発して少し焦ったすぐに論軸的問題気付修正し,その後むしろ想定以上に安定して動いている。この判断結果として正解だった。

輪数取得改良

輪数隠しに関しては,第二次知番改良中に固まった輪数取得改良」として,輪数取得仕組み全体的に改良した

これまでデルンではいちいち厳密な輪数表示をしていたが,これが大きな低速化要因になっていた。デライト以前まで,count()遅さ対する認識が甘かったデライト以後そもそも出場における件数計算原理的に遅いもの,と気付いてページ付けOFFSET上限設けるなどの対策はしていた希哲13年10月14日の開発記録が,輪数一筋縄ではいかない部分があり放置してきた

厳密な同期必要性隠し効率から,次のように整理することにした。

この通りに実装終え上手く動いている

また,この過程で各輪郭操作での輪数更新必要になったため,ほとんど未実装だった輪郭操作系の外充て函数整備した

自我隠し輪郭隠しから次の施策

自我隠しに関しては昨年4月中途半端な実装をしていたため,これを整理した輪郭隠しは,現時点一覧部分には適用出来ないものの一応実装しておいた

自我隠し出来たことで自我情報利用しやすくなったため,自我アイコンts_upd使った隠し破り付けたかったが,自我情報取得部分がまだ非効率なので見送った

輪郭情報求頼分割し過ぎているので,これを統合することを考えているうちに,次の施策まとまった

輪郭一覧については,まず知番のみで中景輪取得し,輪郭隠し照合してから三景輪郭情報同時に取得することにした。これで輪郭隠し効率的に利用出来求頼大幅に減らせる予定していた検索属性もここで盛り込む

{需要がある}{地味ながら}{厳密に考える}{見分けが付く}{開いている時}{実装出来た}{現仕様}{万能ではない}{resize: vertical}{高過ぎず}...=}(116)

{希哲16年3月30日の開発 K#F85E/E74C-7061}

描写欄高さ問題きっかけ自動リサイズ機能字数計実装出来た。ほか装体調整など。

出振るい済み

自動リサイズ機能

旧輪郭選り手では,描写欄出放り高さ新規描出フォーム10em再描出フォーム15emとしていたが,新輪郭選り手ではたまたま15em統一されていた画面撮り10emでは長文書きにくいのでこれはこれでいいかと思ったが,やはり新規描出フォーム一言だけや知名だけの描出使うことも多いためこの高さでは邪魔臭い

ここで,予てからぼんやり検討していた自動リサイズ機能導入考えた一応 resize: vertical設定してあるが,万能ではない10emから20em程度までの範囲で,改行毎に自動リサイズさせる。導入予定字数計では字数情報必要になるため,一緒に行数保持させることにした。

実際に試してみると,1em刻みでも2em刻みでも違和感があったため,10emから19emまで1.5em刻みリサイズするようにした画面撮り初期状態最大自動リサイズ19emだと個人機でも低過ぎず高過ぎずスマートフォン縦向き柔品キーボード表示させてもちょうど収まる程度の高さになる。折り返し多い1行もありうるため,厳密にするなら字数考えるべきだが,とりあえずはこれで様子を見ることにした。

再描出フォームに関しては,さほど目立つものでもなく,描写部高さ合わせて描写欄開くようになっている現仕様悪くないので,現状維持様子見しておく。

字数計

字数行数保持出来たことで字数計難無く実装出来た描出ボタン時印左側邪魔にならないように表示させてみた字数計の様子

下見字数分けようかと思っていたが,下見開いている時下見字数置換すれば十分であることに気付いた一応見分けが付くようにに「」を付けるようにした。

これも,厳密に考える特殊な文字符号などを考慮する必要があるが,キリがないのでとりあえず .length による概算でよしとしておく。

字数計は,地味ながら意外に需要があることを市場調査通して知った自分でもたまに欲しくなることがあった。

{副日記}{デラング}{今の}{十分高い}{損はしない}{どう転んでも}{顕著に}{パンくず記法実装}{大きな狙い}{月別}...=}(132)

{希哲16年3月5日の日記 K#F85E/E74C-6986}

一昨日から始めていた輪郭整備目下課題だったまとめ作業統合し,「大輪郭整備」として継続することにした。この上旬中に,昨年から引きずっている全てのまとめ作業片付けることを目指す

この期間開発作業必要性時間対効果十分高い部分限って行うことにした。大輪郭整備没頭するため,すぐ片付けられるこまごまとした問題明日まとめて片付けることにした。


昨日いったんまとめ作業集中することにしたが,この時点では前次記法実装をした先月24日からのまとめ作業想定していた

しかし,一昨日輪郭整備手応え思いのほかく,昨日止まらなかったこの勢いで,昨年から引きずっているまとめ作業片付くのではないか,と考え始めたのが昨晩就寝直前だった。

数週間ならともかく,数ヶ月範囲になると局所的なまとめ作業」では埒が明かない。その上,連日新たな収穫がある。というわけで24日以前のまとめ作業諦めかけていたが,輪郭整備という形で外堀を埋めるようにまとめていくのが意外と近道かもしれないと思えた

最近出来たパンくず記法前次記法効用がやはり大きい主たる上位階層パンくず記法で,下位階層強調輪符交えつつ箇条書き記法で,前次関係前次記法で,と基本的な輪郭間関係書き込みやすくなり,これまでになっていた無数の輪郭描写急速に充実してきている

一昨日からは関連の輪郭整備本格化し,これがまとめ作業効率化繋がりうることに気付いたこれまで日記にせよ副日記にせよ,年別月別には整理されていなかったずっとやりたいとは思っていたものの,時間対効果疑問があった。当然書き込む手間多少増すが,今のデラングなら閲覧性操作性改善がそれよりずっと大きい終わらないまとめ作業十分に成熟したデラングやるなら最良の時期だろう。

当然現状課題当努整理にも,献典整備にもなるが,もう一つの大きな狙いとして SEO がある。パンくず記法実装をした1月14日頃から顕著に検索演心からの評価上がり,検索流入増えているどう転んでも損はしない作業になるだろう。


6日振り返り日記

=}
{用者}{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> にすることを考え始めた

{デラング}{進捗記録}{まとまりそう}{設計の中心}{留めたい}{加えていく}{開いて欲しい}{煩雑過ぎる}{現実的に}{調整する}...=}(96)

{希哲16年2月2日12歩 K#F85E/E74C-6AB3}

進捗時限記録中略

コンマ駒手について考えたついでに,描写選り手についての再確認再検討終了

現状開閉式選り手は,やはり気に入っている部分でもあり維持するしかなさそうだ。閲覧編集にはそれぞれ最適な用合いがある。

そして,この描写選り手はやはり <textarea>近い単純なものが良いWYSIWYG 選り手多機能化すればするほど挙動好き嫌いも出てくるし,多様な入力環境対応出来ない場合も出てくる。高い実装コストの割に失うもの大きい

そもそもデラングのような軽標記言語役割普文読み書きしやすくすることであり,そこはデラング頼っていい

換配後編集支援部品単位編集という考え方出来てから基本的にはこの方針だが,最近下見機能も含めて輪郭選り手全体像はっきりしてきたこともあり,現状単なる <textarea>描写選り手加えるべき機能見えてきた

中途半端になる懸念から,全く機能加えないという選択肢もあった。ただ,これは問題の方が大きくなりそうだ。例えば,無番輪符書いてから下見完了して輪郭小窓調整するというのは,現実的に考える煩雑過ぎる。やはり,その場で輪郭小窓開いて欲しい

ただ,昔から考えてきた輪符折り畳みといった機能加えない。こういった部分は,せいぜい色付け輪結化留めたい。このあたりは部品単位編集との使い分け考えながら,あくまでも単純性保守性損なわない範囲で,デラング編集支援としての機能加えていくことにした。

部品単位編集も含めて,デラング設計の中心据えることで上手くまとまりそうだ。ここでもデラング整備大きな意味を持ってくる。

=}
{範囲}

{}