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

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

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

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

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


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

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

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

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

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


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

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

=}
{文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}{検討していた}...=}(94)

{希哲16年1月19日1歩 K#F85E/E74C-5396}

デライト装体調整URL 装体調整終了

直書き URL<a.URI>font-size: 0.9em等幅フォントにしたURL 装体調整前後字間無し昨年6月30日の開発からだが維持する。

直書き URL のある描写読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズ小さくしていない」ことに気付いた

昨年6月30日の開発字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由したりもしている。この時になぜ文字サイズ小さくするという発想がなかったのか不思議だ。他にも問題山積していて思考時間割けず灯台の下まで目が行かなかったか。

今回<kbd><code>装体について考えていたところだったので,その関連気付けたのだろう。

文字サイズはやはり0.9em丁度良い0.8emにすると長い URL はともかく短い URL提示する時に今度は目立たな過ぎる


これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず,デライト上文書の傾向からいっても,「ちょっと長い」程度の URL省略したくない。URL全体情報として有用場合しばしばある。このあたりはマイクロブログなどとは事情が異なる

では,どこで省略すべきかという問題になるが,長い URL許容すればするほど比較的短い URL読みにくさ解消されないというジレンマがあった。これは装体の調整解決した。

そもそも輪結記法[ ... ]もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法導入してもいい。

ただ,パーセント符号化復号はしたい。これは昨年3月22日2歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{一日一文}{ラテン文字}{英語}{英単語}{印迫}{デライト}{希哲15年5月の一日一文}{あれ}{輪郭を描く}{アメーバブログ}...=}(59)

{「デルン」の由来 K#F85E/E74C-A0EA}

先日「希哲館」の由来について書いたので,命名に関する思い出話ついでに,今度は「デルン(deln)由来について書いてみよう。

デライト採用している CMS としてしばしば言及するこのデルンだが,「ブログ」や「ウィキ」に相当するものだと思ってもらうのが一番分かりやすいだろう。例えば,Wikipedia がウィキを利用していたり,アメーバブログブログを利用しているように,デライトはデルンを利用しているわけだ。

これだけで,デライトの独自性常軌を逸していることはお分かりだと思う。長年インターネットで広く使われてきたブログでもなくウィキでもなく,全く新しい CMS の形態から考案し,サービス化したのがデライトだ。ちなみに,「デライト」(Delite)の由来は「ライト(簡易)版デルン(Deln Lite)だ。


そのデルンの名は,基礎理論である「輪郭法」に由来している。輪郭法は英語デリノグラフィー(delinography)という。デリノグラフィーはデリニエーションdelineationという英単語に由来している。輪郭を描くこと,描写,などを意味する言葉だ。こう辿っていくとややこしい話だが,それだけ長い文脈があるということだ。

さて,デリノグラフィーを縮めたのがデルンだが,この名前を考えたのは希哲6(2012)頃で,デルンの実用化直前だったのでさほど詳しい記録も残っていない。

ただ,当時はブログやウィキの代替を強く意識し,名前もそれらの特徴を踏まえようとしていたことはよく覚えている。つまり,ラテン文字4文字カタカナ3文字,一見不思議呪文のような響きだが,由来はちゃんと説明出来るという名前だ。ブログ(blog),ウィキ(wiki),デルン(deln)と並べてみれば分かりやすい。

特にデルンという言葉の何とも言えない響きには,命名から9年ほど経った今でもまだ慣れない。何度口にしてもすっきりしない。もっと良い名前があるんじゃないかと,何度思ったか分からない。

ただ,この微妙な語感こそ記憶に残りやすい言葉の特徴で,ブログやウィキが普及した理由も実はここにあるのではないかと思っている。何かよく分からない言葉を最近よく聞くなと思えば,それについて知ってみたくなるのが人の性だ。


一方で,「デライト」はごく簡単に,すっきり飲み込みやすい名前にすることを意識した。よく使われるカタカナ英語なので,それ自体に印迫インパクトは無い。この対照的な「デルン」と「デライト」を上手く使い分けて市場活動マーケティングに活かしたいところだ。

=}
{用者}{第三次宣伝攻勢}{HTML}{進捗記録}{領当て}{<iframe>}{希哲15年2月28日の開発}{実装方針}{allow-scripts}{ブラウザ対応状況}...=}(59)

{希哲15年2月28日2歩 K#F85E/E74C-D345}

少し忘れていたが,第三次宣伝攻勢を始める前にもう一つやっておくべきこととして,HTML タグ切り替えがあったため再検討この描出を見て必要性再認識した。

考えてみれば,HTML タグを使うつもりがなくても引用で入ってしまう可能性がある。誤った HTML放置されていれば用者にとってはもちろん SEO 上の障害にもなる。

基本的な方針はデライト公式で書いた通りだが,実装にあたっては若干の課題も残っていた。

他輪郭描写原則として HTML タグ無効化するとして,有効化した際にスクリプトだけ無効化するというのは意外に難しい

script 要素禁止するだけでは十分でなく,on- 属性iframe 要素等の抜け道も塞がなくてはならない。

on- 属性 に関しては,on で始まる属性を一律削除するか non- にでも置換してしまうことを考えたが,そもそも on- が HTML において予約接頭子なのかよく分からない。

いずれにせよ,HTML拡張性や近年の仕様変更の激しさを考えると,ブラックリスト的な検査は避けたい。

ここで iframe 要素sandbox 属性が使えることに気付いた。これならスクリプト禁止意図明示出来る。ブラウザ対応状況も悪くない。

スクリプトのみならず,iframe なら誤った HTML によってページ全体の領当てが影響を受けることも簡単に避けられる。自輪郭では allow-scripts を加えるだけでスクリプトを許可出来る。

いっそのこと全ての描写部砂房にして原則タグ有効に出来れば話は簡単だが,iframe 要素は色々な意味で重くSEO にも向かない。タグを悪用した迷惑行為フィッシング等の可能性が完全になくなるわけでもなく,iframe 以前にタグの処理は重いのでやはり原則無効化,有効化時のみ iframe に置換するというのが現実解だろう。

これで実装方針は固まった。実装自体は半日もあれば出来るだろう。

{仮想頭脳}{描写}{頭脳}{デルン}{宇田川の用語}=}(5)

{描写頭脳 K#F85E/AB3C}

「描写頭脳(delineated brain)」は宇田川の造語。「写脳(しゃのう)」と略す。非公式に,「情報頭脳」等と表現する事もある。

描出(#F85E/A-50B3)によって,あたかも一つの頭脳が写し取られたような情報のまとまりを指す。

通信網の上に公開されたものは特に公開頭脳(#F85E/A-15BA)と呼ぶ。

頭脳検索(#F85E/A-AE43)等の技術にも関連する。

{描写}

{}