{『希哲日記』}{知名の付け方}{希哲15年}{希哲13年}{}{方向}{一助}{日記}{十分}{}(193)

{希哲16年12月14日の日記 K#F85E/E74C-B161}

ちょっとした用事片付け第二次快調期からまともに出来なくなっていた書類整理少し進め,あとは大輪郭整備考え事をして過ごした


考え事での大きな収穫として,文書整備かかわるデライト用語体系方針まとまった

デライト用語体系関しては従来の輪郭法新用語体系基礎に,初心者向け分かりやすい代替用語導入などを検討していたが,これはやめ基本的に新用語体系そのまま踏襲し,説明体系洗練させていくことにした。

例えば知名を「輪郭名」,知番を「輪郭番号」などと説明することを考えていたが,元々技術としての固有性独立性高い知番関しては早々に断念していた。「輪郭名」などを補助的に導入するかどうかで最後まで迷っていたのが知名だった。この問題考える上で,「知名」という用語妥当性についても再考する必要があった。

知名」の必然性について直感的な確信はあったものの,言語化意外と難しかった。それを象徴するかのように,いつからか輪郭知名」の選り手開きっぱなしで,再描出下書き抜控一覧実装した頃から常に表示されている唯一の輪郭になっている。

知名単なる記事名」でも「題名」でもなく,森羅万象付けることが出来る認知上名前であり,その性質既成語では表現出来ない更に,「輪郭の名前」として輪郭従属するものではなく,あくまでも知の名前」として理解される必要がある。そうでなければ,そもそも輪郭目的として扱っているのか分からなくなってしまうし,自己目的化しかねない。ここに知名という用語必然性がある。輪郭とは,知の名前知の番号そのもの具現化するものだ。

この方向説明体系洗練させていけば,代替用語複雑化招くだけのものになる。「急がば回れ」で,多少時間はかかってもデライト正しく理解出来る説明をしていくべきだろう。この点において,特に輪郭」「知名」「知番」「描写」といった基礎用語には動かしがたい正しさ”があり,それは十分わかりやすく説明出来るようやくその確信持てた

読み込み中...
{デラング}{進捗記録}{十分}{進捗}{デライト}{reverse()}{交度}{whr_kw()}{希哲15年8月23日の開発}{検索語変換}(70)

{希哲15年8月23日7歩 K#F85E/E74C-ECC6}

全知検索整備についての検討終了

全文検索にはとりあえず pg_bigm採用しておくことにした。知名検索でも中間一致検索性能課題だったので,これも解決出来そうだ。後方一致検索に関しては,PostgreSQL 9.1 から reverse()組み込み函数として提供されるようになっているので問題ないだろう。

後縁実装どうとでもなるが,難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので,まずは検索演算子として各種機能実装したい。これに関しても,だいぶまとまってきた

カンマAND 検索に使うという構想があったが,& ボタンとの兼ね合いもあるので,まずは無難&AND で AND 検索,|OROR 検索対応することにした。除外検索条件次第- を使えるようにしてもいいだろう。

部分一致検索については,省略記号 ...ダッシュ記法応用した ---対応する。

描写検索については,基本的には昨年7月27日3歩方針踏襲し,末尾に ?? を加える形で対応することにした。デラングとの兼ね合い検索寸片をどうするかという課題は残るが,デライトではそれほど多用するものではないので,まずは普通に引っかかるだけで十分だろう。

一つの可能性として,検索ボタンダブルクリックダブルクリック検索対象切り替える機能があってもいいかもしれない。

いずれにせよ,まずは既存の検索語変換交度whr_kw()まとめる作業から始めることになるだろう。

{進捗記録}{進捗}{希哲15年5月12日の開発}{DBG()}{出力形式}{標準違了出力}{def_dbg.h}{ERR()}{DBG_DEX()}{希哲15年5月12日の進捗時限}(24)

{希哲15年5月12日10歩 K#F85E/E74C-A568}

def_dbg.h調整

途中で終了。

標準違了出力共通の ERR()追加,これを利用し DBG()再定義DBG_DEX() を追加した。

これまで,DBG() では長いこと以下のような出力形式採用していた。これも少し再検討したが,直感性視認性を上手く両立させており,ごちゃごちゃした出力の中でも分かりやすいので基本的には踏襲することにした。

!? main.u:123 << hello debug

今回,これに加え,マクロ名を加えることにした。

!? DBG;main.u:123 << hello debug
!? DBG_DEX;main.u:123 << hello Dex debug
{デラング}{進捗記録}{nofollow}{進捗}{用者}{PWA}{希哲15年2月26日7歩}{希哲15年2月25日の開発}{ugc}{rel="noopener nofollow ugc"}(45)

{希哲15年2月25日4歩 K#F85E/E74C-3DFA}

PWA 版デライトアドレスバー問題調査続き。

いったん終了。

これ自体はやはり Chromeバグという気がするが,scope を設定していようと target="_blank" などではない外部輪結は同じで開くというのが一般的な実装らしいため,これを機に外部輪結の扱いを見直し

これまでなんとなく可使性可接性観点から新窓で開くかどうかは用者に委ねるべきという考え方踏襲してきたが,不具合に関係なく外部輪結を同じ窓で開くというのは独立した相振りらしい挙動ではない。

使い勝手に関しては大部分が慣れの問題で,一貫性の方が重要だろう。

PWA とそれ以外で挙動を変えることも考えたが,PWA 以外でもそれほど不都合なことはないはずなので,仕様複雑化を避けるためにも外部輪結は一律新窓で開くようにして様子見することにした。

まだスクリプト制御するほどのこともないため,デラングの処理時に target="_blank"rel="noopener nofollow ugc" を付けておくことにした。

nofollowugc に関しては本件以前に検討していたので丁度よかった。

{開発}{開発記録}{Aejs}{廃止}{中画面}{非対応ブラウザ}{外部譜類}{HTTP/2}{希哲14年9月24日}{スプライト化}(30)

{希哲14年9月24日の開発 K#F85E/5B28-FA5A}

デライト用合い改良

これまで先送りにしていた課題最善の時期にまとめて解決出来た感がある。

画像など外部譜類の扱い方について再検討した結果,HTTP/2移行し,ドメイン シャーディングはいったん廃止スプライト化も見送ることにした。将来的に余裕があれば非対応ブラウザ対策のため追加することはあるかもしれないが,今やるべきことではないと判断した。

HTTP/2 への移行は同日中に完了。

アイコン等の画像については,Aejssrcset 属性追加マウスオーバー時の切り替えを行うことにした(画像が主になる場合)。

下装書画面等級毎の分割は廃止することにした。ただし,中画面ii)を中心に据えることは踏襲する。

{開発}{開発記録}{<spn>}{握接}{道手}{輪符}{指示型}{IP アドレス露出不具合}{希哲14年8月21日}{美しくない}(44)

{希哲14年8月21日の開発 K#F85E/5B28-699C}

半休にして一昨日からのまとめをしていたため,作業は出来なかったが,いくつか仕様検討が進んだ。

まず,先の不具合反省から,指示型p_)や如零許容型iffy_)で安全間接参照する方法について検討

最初は間接参照演算子上積みすることを考えたが,伝統的記法極力踏襲したいこと,非如零であることが自明な時にオーバーヘッドを避けて握接する手段も残したいため,別途val() のような道手を持たせる方向で検討を続けることにした。

以前から何とかしたかったマウスオーバー時の輪符展開動き付けについても,展開したい部分を spn 要素で囲っておけば,下装書animation 等を使って十分表現出来ることに気付いた。以前,滑らかに展開させるためにスクリプト側で文字列操作をしようとしたが,明らかに美しくない方法なので断念していた。

{進捗記録}{}{知番}{進捗}{dg_kno}{手定め}{希哲14年8月16日の開発}{新括体採番法}{旧括体採番法}{新採番法}(37)

{希哲14年8月16日14歩 K#F85E/5B28-01D5}

知番新採番法について概ね方針が固まる。

括体採番法有用であるため踏襲し,内部実装のみ改良する。これまでの知番予約による方式を「旧括体採番法」とし,「新括体採番法」に移行する。

これまでのように個々の知番_dg_kno に保持するのではなく,知番節の有効範囲を保持するだけの定表を作り,外部結合により空き知番抽出する。

簡単な手定めを行い,問題のない速度が出ることを確認。この時,定表を作らず generate_series()動的生成することも出来るが,流石に数倍の速度差があり現実的ではない。

_dg_kno は構造をそのままにとなる知番節探索するために使う。

{進捗記録}{右吹き描き}{}{知名}{進捗}{デライト}{領当て}{希哲15年4月10日3歩}{輪括}{吹き描き}(74)

{希哲14年7月18日8歩 K#F85E/5B28-D190}

朝から前後景輪一覧領当てについて本格的な検討を始め,およそ6歩分かけて昼過ぎには概ね方向性が定まった。これで,デライト用合い設計にも死角がほぼ無くなった。

まず,6月30日の開発で検討していた,吹き描き前後景部の所定件数越えを「...」で表現し,そこから一覧に飛ばすという案は,一旦白紙とすることにした。一覧ではなく,知名だけざっと確認したいという場合が考えられるためだ。動的にただ追加するのではなく,所定件数以内で表示範囲を切り替えていく,というのであれば領当てを壊すこともない。

輪郭一覧ページ付け動的追加を検討してきたが,かえって重くなったりする懸念もあるため,いったん画面遷移で実現することにした。表示は一覧の左上と右下に ...上下矢印,ページ番号を組み合わせる形を検討。現状,録落ちボタンを使っているため紛らわしいが,これはすでに利用者情報ページに移動することを決めていたため無視していい。細かいことは実装しながら試行錯誤していく。

前景一覧については,4月14日7歩考案した逆さ吹き描き踏襲するが,最上部だけでなく一覧の各吹き描きも逆さにしてみることにした。

引き入れボタン引き外しボタン実装する上で,引き入れ状態をどう表現するかという問題もあったが,これも一応の目処が付いた。結局,くぐった輪郭と輪括関係にない輪郭線点線に変え,中景部と上にくる前後景部白煙色を入れ替えるとそれなりに見えることが分かった。この時,全て白煙色にしてしまうとぼやけ過ぎて視点が定まらないため,注目させるべき前後景部のみ白にする。これに加え,ボタンの状態が変わっていれば十分区別出来る。

他の案として,左右反転も脳裏をよぎったが,やはりこれは自他の区別に使うべきとして廃案。横にずらすなども,横幅に余裕のないスマートフォン等の端末を考えれば普遍性が無い。吹き描きはその輪郭を認識するために必要な情報が凝縮されているため,何らかの省略表示を取ることも出来ない。というわけで,表示位置・表示形式は変えず,輪郭線色彩ボタンの3要素に特徴を持たせることで輪括関係を表現するのが最良という結論になった。

引き入れボタン引き外しボタンは現状ですでに表示されている =} 形のボタン活用し,可能な限り単純性を保つ。

ついでに,輪郭をくぐった状態での検索挙動についても整理。現在,吹き描き内部の検索窓は全体検索になっているが,これは本来輪括関係のあるものに限定して検索するのが直感にかなっている。そこで,くぐっていない状態で最上部に表示されている検索窓をくぐった状態でも表示し,そこを全体検索として使い分けることにした。画面遷移時にページ内輪結で隠せば,必要な時だけ出てくるように出来る。最初は検索窓を画面に2つ表示するのは美しくない気がしたが,かといってチェックボックス検索語の特殊記法を導入するのが美しいとも思えない。これが一番直感には適っているだろう。

ここで,自他の区別に使うことを想定していた左右吹き描きもその方針確定した。

これを機に,4種の吹き描きに厳密用語を与えておくことにした。現状の左眼形を「左吹き描き」とし,左右反転させたものを「右吹き描き」,両者を併せて「左右吹き描き」と呼ぶ。さらにこれを上下反転させたものを「逆さ左吹き描き」「逆さ右吹き描き」と呼び,併せて「逆さ吹き描き」と呼ぶことにした。

{踏襲}

{}