{希哲16年3月22日の開発}{希哲16年3月22日の進捗}{タブ式}{`#BBEEBB`}{使わずに}{縦に並べる}{下見表示}{目障りにならない}{右端}{最小限の変更}...=}(76)

{希哲16年3月22日9歩 K#F85E/A-E74C-3F9D}

{コマンド プロンプト}{駒手記法}{進捗記録}{場筋}{採用しにくい}{`\>`}{ドライブレター}{`C:\>`}{`:>`}{`PS>`}...=}(37)

{希哲16年1月23日21歩 K#F85E/A-E74C-9337}

進捗時限記録中略

駒手記法コマンド プロンプトPowerShell 対応について検討して終了

以下のような形で実装していくことにした。

:> [コマンド プロンプトの駒手]
C:\> [〃]
PS> [PowerShell の駒手]
PS C:\> [〃]

以前から対応については考えていたが,Windows 系の駒手欄特徴をどう掴むかが難しかった

PowerShellPS> でいいとして,コマンド プロンプトC:\> では明らかに冗長だ。ドライブレター場筋情報必要ないことの方が多いだろう。越化記法との兼ね合い考える\>採用しにくい。となったら,:> しかないだろうということになった。ドライブレター場筋任意付加出来ることにする。

{進捗記録}{希哲15年9月6日の開発}{急がない}{希哲15年9月7日}{まとめて}{やりやすくなった}{5時前起床}{5時台}{6時台}{早朝出振るい}...=}(46)

{希哲15年9月6日4歩 K#F85E/A-E74C-F11E}

出振るい作業についての検討終了

最近,断帯を伴う出振るいタイミング迷うことがく,結果的にまとめて行うことも多くなっていた。今後,急がない出振るいについては意識的まとめて行うことにした。

保守作業中ページへの切り替え機能再整備違了処理整備輪郭選り手抜控機能整備を経て出振るい作業もずいぶんやりやすくなったが,機会損失に繋がる断帯最小化したい。

時間帯も,深夜にまとめようかと思ったが,生活律動との兼ね合いがあるため5時台の「早朝出振るい」を心がけることにした。朝のデライト宣伝6時台最適考えてきたため,流れとして丁度良いだろう。

これに伴い,明日から5時前起床目指すことにした。最近,夜更かし目立つようになってきたためこれも丁度良い

=}
{デラング}{進捗記録}{交度}{デライト}{`whr_kw()`}{希哲15年8月23日の開発}{検索語変換}{どうとでもなる}{条件次第}{OR 検索}...=}(70)

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

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

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

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

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

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

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

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

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

=}
{`silver`}{進捗記録}{`WhiteSmoke`}{`gray`}{下線記法}{引用部区}{デライト}{希哲15年6月21日の開発}{希哲15年6月20日の日記}{:only-child}...=}(160)

{希哲15年6月21日9歩 K#F85E/A-E74C-A945}

強調輪符輪結装体リンクスタイルについてのまとめ

これまで輪符輪結装体1px #999破下線にしていたが,通常の線のlightgray引用部区ブロックなど WhiteSmoke 背景の上では silver と,かなり薄くした強調記法単独で囲まれた輪符に関しては,silver一本下線にし,少し目立つようにした。

これにより,輪結リンク重要性に応じてメリハリが付くようになり,重要性変調さりげなく示唆したいような場合は軽い強調はっきり強調したい場合は重い強調というように,強調記法と組み合わせた「強調輪符」の記法確立した。

輪符自体を強調するのではなく,参照名を強調したいのであれば内側に強調記法を置くことも出来る(例:軽い強調重い強調)。

経緯

長い歴史

輪符表示をどうするかという問題は,デルン最初期からの課題だった。

最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが,いずれ文中輪符が増えてくれば,重要性によって表示し分ける必要が出てくる,というのは当初から想定していた。元々,入力道手メソッド機能自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。

実際,デライト以後,私自身の慣れデライトの品質向上によって自然と文中に輪符が増えてきた。現在,私の描出ではほとんどの輪符であり,輪結になっている。こうなると,閲覧者にとっては,どこが重要な輪結なのか分からない上に,中途半端に目立つ輪結だらけで見にくいという問題が出てくる。

もう一つ,輪符に関する問題があった。輪符知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが,これまでそれを表現する良い手段が無かった。

どちらの問題も,少し前までは自動的解決出来るのではないかと考えていた。例えば,前景輪にある輪符自動的強調表示したり,知名と異なる名前で参照された輪符斜体にするなどということを考えていた

ただ,これは描出経験を積むにつれ無理がある感じるようになった。

まず,時として膨大になる前景輪に一致する輪符をいちいち見つけるのは現実的ではない。見えている10輪限定するのも不自然見え方になるだろう。輪符参照名をいちいち照合するのも軽い処理ではない。

描写隠し文字列でも埋め込めば負荷軽減にはなるだろうが,依然として無視出来ないコストではある。何より,出与え一貫性保守性深刻な影響を及ぼすことは目に見えている。

それ以前に,自動装体スタイリング適用すべきではない場合が多々あることも分かってきた。全知検索との兼ね合いも考えると,文中目立たせたい輪符引き入れたい輪郭はむしろ一致しないことの方が多い。

知名に関しても,例えば,「知る」という輪郭を「って」のように語形を変えて参照することも増えてきた。明らかに自動装体にすべきではない,瑣末な場合が多々ある。

最近では,デラング整備進展もあり,これは手動装体,つまり何らかの記法対応すべきなのではないか,と考えるようになっていた。

今日の進展

こうした問題解決に向けて本格的に考え始めたのは,まさに今日,昨日の日記を付けていた時に,「希哲15年6月20日の開発」という輪郭を「開発では」として参照した時だった。この「開発」が,一般的な意味での開発なのか,特定の日の開発を指しているのか,一見して分からない。これは以前からずっと気になっていた問題だが,そろそろ何とかしたいと思った。

重い強調を使ってみたりもしたが,重過ぎる。そこで軽い強調を使ってみることにしたが,軽い強調は欧文向けで,斜体伊体依存した装体は避けたかった。ここで,強調輪符下線調整することを考え始めた。

強調輪符をいかに目立たせるか,ということを考えているうちに,そもそも輪符輪結全般が目立ち過ぎていることに気付いた。というより,これまではこの輪結装体軽い参照重い参照表現していたので,気付いてもどうしようもなかった。ここで,通常の輪符と強調輪符でメリハリを付けることを考え始めた。

破線は太くすると環境によって全体的に大きくなり短いでは破線らしく見えなかったりするため,一本下線にすることを考えた。もともと点下線破下線一本下線輪結の強さ表現した装体で,一本下線は前景輪のために取っておいたが,前述の理由で未使用だった。ここで,輪結装体に関する問題全般と繋ってきた。

通常の輪符に関しては,いっそのこと下線類を無くしてもいいかと思ったが,流石に文字色だけでは心許無い視線の流れを遮ることなく,視線を止めれば容易に輪結と視認出来る按配理想として,破下線を極力薄くすることにし,白背景なら lightgray引用部区など WhiteSmoke 背景の上では silver最適結論付けた

Firefox調整していたためもう一段濃い silver と darkgray の組み合せで決めかけたが,他の環境では破線密度の差でまだ濃過ぎるように見えたため,まとめ中に修正)

強調輪符一本下線に関しては,薄い色では弱いように思え gray を試したが,明示的下線を引きたい場合のために下線記法導入することも考えているため,兼ね合いであえて silver にしておくことにした。

まずは CSS のみでの出振るいonly-child で複数の輪符には効果が跨らないようにしてあるが,テキストノードは含まれうる。本来は一つの輪符のみを強調した時の効果であるべきだが,とりあえずは十分だろう。

総括

開発記録に書いておく。

{進捗記録}{非録入り状態}{デライト語体}{希哲15年3月4日の進捗時限}{希哲15年3月4日の進捗}{希哲15年3月4日}{×輪結}{デライト文書構造最適化}{共有ボタン}{自我アイコン}...=}(43)

{希哲15年3月4日4歩 K#F85E/A-E74C-27F9}

デライト文書構造最適化中景部微調整

途中で終了。

輪郭ページくぐり検索同様中景部右上に表示していた×輪結削除し,非録入り状態ではデライト語体を表示しへの輪結とすることにした。ここに置く予定の共有ボタン未実装なため,録入り中は何も表示されないことになる。

検索流入急増してきている今,この動線が無いのは問題だった。

これまで輪郭ページは単なるくぐり検索転用だったため,検索演心等から来た訪問者が何のサイトなのか分からないという問題はずっと認識していたが,意外に難しかった。

非録入り状態×輪結を扉への輪結に置換するという考えは以前からあったものだが,くぐり検索輪郭ページ未分化だったため,検索上の便宜との兼ね合いで見送っていた。

代替案として全知検索窓左部分にデライト語体を表示するというのもあったが,やはり自我アイコンの表示部分という役割が分からなくなるのでこれも使えなかった。

最近,輪郭ページ閲覧共有向けという役割明確になってきたこともあり,昨日,寝る前に×輪結自体が輪郭ページでは不要なのではないかと気付いた。

これで最低限処置は出来ただろう。

=}
{進捗記録}{廃止}{デライト}{希哲14年8月15日の開発}{統計情報}{保存期間}{用者心理}{運営事務}{管理体制}{流出リスク}...=}(66)

{希哲14年8月15日5歩 K#F85E/A-5B28-78BD}

個人情報保護方針について再検討。いったん終了。

現状,デライトでも IP アドレス出場保存しているが,これは廃止も含めて検討を続ける。

デライトは高い匿名性を持つ一方で,投稿による個人情報蓄積も多くなる。不正利用への対応能力個人情報保護兼ね合い難しい。とはいえ現状,悪質用者がいるわけでもなく特に何にも利用していない。必要になるかもしれない,でこの種の情報蓄積していくのは好ましくない。

ウェブサービス運営する上で IP アドレスを全く記録しないということは考えにくいが,出場保存してしまうと流出経路も増え,永続性が高まり,他の出与えとの関連付け容易になる。

ウェブ捌き側である程度の握接制御は出来るし,出場側には日時さえ保存しておけば追跡必要になった時に握接録照合すればいい。握接録は保存期間を定めておき,統計情報を取ってから削除する。

暫定的措置として,出場への IP アドレスの保存は切り替え式にしておき,原則として保存しないことにする。これにより,流出リスク相対的低減させつつ,十分な管理体制が出来,かつ運営事務の観点からどうしても必要になった時に期間限定有効にする,といったことが可能になる。

また,透明性重視し保存状況は期間とともに公表する。

用者心理の観点からも,監視的な要素は少ないに越したことはない。

{進捗記録}{省割}{希哲14年7月30日の開発}{輪括内外検索}{輪括内検索}{検索範囲}{希哲14年7月30日の進捗時限}{希哲14年7月30日の進捗}{希哲14年7月30日}{吊るし輪郭}...=}(31)

{希哲14年7月30日6歩 K#F85E/A-5B28-B480}

前後景一覧整備続き。

途中で終了。

全知検索窓について,迷いがある状態作業を進めるのは良くないので方針明確にしておくことにした。

やはり,検索範囲の表現方法として検索窓位置以上に直感的なものはなさそうなので,最上部の全知検索窓輪括内外検索に,吹き描き内の検索窓輪括内検索に使うことは確定としておく。見た目の問題は見せ方でどうとでもなる。

これらの機能引き入れ欄検索機能との兼ね合いについては今後の課題としておく。

どちらかといえば,吊るし輪郭がある時に隠したいのは最上部の全知検索窓なので,省割として現状の機能を維持するのも悪くはない。

{兼ね合い}

{}