{デラング}{進捗記録}{希哲16年2月14日の開発}{損われる}{本質的ではない}{記述しやすい}{珍しくない}{大規模サイト}{迷惑行為対策}{運営上の都合}...=}(65)

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

越化エスケープ周りの客体表現化考えるついでに文字参照の越化について再検討して終了

HTML 越化仕様決めた昨年5月20日12歩以来越化目的使う可能性がある文字参照のみを許容していたが,これは修正し,いったん全ての文字参照許容することにした。

4日21歩でも再検討したが,越化記法同様デラングにおける特殊文字白表方式管理するのは無理がある損われる保守性に対して利点乏しい

当初制危というより迷惑行為対策など運営上の都合必要になるのではないかと思っていたが,Wikipedia はじめ大規模サイト開放されている珍しくなく,少なくともデライト言語仕様にするほど必要制限とは言えない。文字参照制危上致命的な問題があればそれは舞覧問題だろう。迷惑行為対策としてもあまり本質的ではない

何か問題があれば制限する,で十分なはずなので,実装都合制限してもいいことにする。

文字参照には,表示入力難がある文字記述しやすいという有用性一応ある。

=}
{文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い 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歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{デライト開発}{進捗記録}{場筋}{知番譜類}{知番}{.oln}{希哲15年12月19日の開発}{統合せず}{無理に}{.d 接尾子}...=}(102)

{希哲15年12月19日1歩 K#F85E/E74C-00D9}

分割格納方式への移行作業前に,知番譜類における拡張子扱いについて検討して終了

従来通り無接尾子知番譜台許容することにした。

これまでの自我台録/kn/K#F85E/には無接尾子譜台いくつかあるが,譜類添付機能合わせ,これを全て拡張子付き練名することを考えていた

そもそも知番譜類は,知番譜類名にしてデルン上管理する譜類管理手法として始まり,デライト開発本格化してからこの経験を元に拡張子毎添付譜類という概念固まった

当初一貫性観点からむしろ無拡張子基本考えていたため,初期知番譜類には無拡張子実体拡張子付き疎輪結置いているものがある。ただこれは煩雑な上に,Windows 仮想機上手く扱えない問題があったため次第にやらなくなった。以後,普通に拡張子付けることが多くなった

いっそのこと,全て拡張子付きにして譜類添付機能との整合を取るかと考えたわけだが,全ての譜類適当な拡張子があるわけではなく,必ず指定するとなると煩雑化恐れがある。適当な拡張子がなければ .unk のような特殊な拡張子を使う,台録なら .d 接尾子を使うなど仕様複雑化する。

仮に無拡張子知番譜台空けたところで,その使い道があまり無いという問題もある。本来輪郭情報を置くのが適当なところだが,エクスポート機能等では閲覧編集都合から .oln を使うことを決めている分割格納方式採用したことで利便性いずれにせよ知機駒手補うしかなくなっているので,実体場筋利便性持たせる必要もなくなった。

譜類添付機能エクスポート機能はあくまでも知番譜台応用として,無理に統合せず一定相互運用性確保しておくに留めるのが最善結論付けた

ただ,拡張子用の疎輪結だけは問題なので普通の拡張子付き練名しておくことにした。

=}
{隠し}{『希哲日記』}{デライト}{希哲15年9月の月記}{KNEST 隠し実装}{空想的な}{時間を充てる}{本格的に}{変えていなかった}{間違える}...=}(137)

{希哲15年9月15日の日記 K#F85E/E74C-6D50}

昨日KNEST 隠し実装の再開決めたのが寝る頃で,消化不良だったため,今月中間まとめ兼ねて頭の整理をしておくことにした。再開によってデライト収益目標達成展望急に明るくなったような気がしたが,それが何故なのか理解出来ていなかった

そもそも今月に入ってから,新生デライト開発はまたもや不思議な軌道を描いていた。機能整備進めようという意識とは裏腹に,実際には高速化開発環境整備知機駒手整備手定め環境整備デバッグ環境整備多くの時間を割いた。また脱線しつつあるなと感じてはいたが,収穫大きかったので成り行き任せにしていた。これが KNEST 隠し実装の再開繋がったのは,単なる偶然ではなさそうだ。

いま思えば,8月頃からデライト収益目標達成に向けた具体的な道筋がこれまでにない鮮明さで見えてきて,具体的な数字掴めてくるにつれ,一つの不安浮上していた。それは,デライトにおける性能面の課題だった。現実装では,収益目標達成に必要握接量捌けないのは明らかだった。

ただ,これまでの自分なら,そんなことは気にせず問題が起きたらその時に乗り越えればいい,という感覚突き進んでいただろうし,意識の上ではまだそのつもりだった。無意識下でそれに反するような行動をしていたのは,日に日に増していくデライトの成功に対する現実感のせいでもあっただろう。空想的な見通しの甘さ許容出来なくなっていた。

今のデライトは,デライト高速化着実進展によって性能面でも健闘しているが,それは低負荷状態の0.1秒単位でのページ表示速度を上げていくようなもので,握接集中対策への突破口は見えていなかった。

その明らかな理由KNEST 隠し実装停滞であるということと,いまその再開最良の時期訪れていることに気付いた。この時,一気に展望明るくなったように感じた。これまでの不可解軌跡も,ここに導かれていたのだと思えた

現在,高速化機能整備文書整備同時進行させることにしているが,KNEST 隠し実装中断した5月から急速に発展展望が開けていた機能整備文書整備に対し,切り札を失ったままでいたのが高速化だった。ここでそれが復活したわけだ。

KNEST 隠し実装中断したのは,実装方針への迷いからだった。隠し初期設計間違える足枷になりやすく,早まった最適化になりかねない。しかし,7月から8月にかけて新生デライト像が固まったことで実装見通し劇的に改善している。これから機能整備文書整備を進めて集客本格化させようというところで,性能問題での機会損失極力避けたい確かに再開するとしたらこれ以上ない時期だ。


10月中のデライト収益目標達成に向けて組計調整することを決めたのは7日だったが,まだ月内達成可能性も見ていたため,ここまではあえて態勢変えていなかったKNEST 隠し実装の再開という大義名分も出来たところで,本格的に頭を切り替えることにした。

今月後半雑務処理をしっかりこなしたいので外出も多くなる見通しだが,とりあえず,中旬一杯は KNEST 隠し実装開発時間充て様子を見る

16日振り返り日記

{進捗記録}{Markdown}{HTML – 旧輪郭}{見出し記法実装}{希哲15年5月14日の進捗時限}{希哲15年5月14日の進捗}{希哲15年5月14日}{見出し階層}{気付いた}{デラング整備}...=}(19)
{用者}{進捗記録}{デライト}{上信}{デライト高速化}{希哲15年3月11日の開発}{保存方式}{譜類添付機能}{希哲15年3月11日の進捗時限}{希哲15年3月11日の進捗}...=}(40)

{希哲15年3月11日11歩 K#F85E/E74C-8A64}

デライトではこれまで意図的に避けてきた譜類添付機能について検討

1MB未満程度の比較的小さな譜類であれば許容してもいいかもしれない。

自我アイコン設定機能実装を通して libxtd はある程度整えてあり,拡張子を利用した保存方式は個人的にも使い慣れ,捌き手の対応も出来ている。

後は,kn sync で実現している上信フォームで出来るようにすれば良いだけで,実装自体はすぐにでも出来る。

残る問題は,用合い運用だ。用合いはどうとでもなるとして,特に運用上の問題を解消しておきたい。

そもそも現状,描出自体はいくらでも出来るので,用者毎に制限をかける必要は特にない。

描出公開原則があることと無料であること,デライト高速化が視野に入っていることも大きい。倉庫のような使い方はされにくいだろうし,契約ではないので,手に負えなくなればその時点で無効化するなり出来る。

出与え URI のようなものを使われるくらいなら,上信してもらった方が効率的でもある。

それによって良い献典になるのであれば積極的に使ってもらった方がいいくらいかもしれない。

1輪郭につき1MB未満,拡張子制限付きで検討しておく。

{進捗記録}{知番}{輪符}{希哲15年2月14日の開発}{空輪郭}{希哲15年2月14日の進捗時限}{希哲15年2月14日の進捗}{希哲15年2月14日}{空欄削除}{打ち消し線}...=}(36)

{希哲15年2月14日2歩 K#F85E/E74C-979B}

輪郭削除に関しては空欄削除の方向で固まっているが,すでに出場側での対応は出来ており,細かい調整だけで実装可能な状況にあるため,作業方針を練る。

知番のみの輪郭にも利用価値はあるため,空欄削除はあくまでも用合い上の手続きとして,知名描写をもたない輪郭の存在は許容することにした。また,これを「空輪郭」と呼ぶことにした。

削除直後の表示についても概ね方針が出来た。

中景部輪郭線を細くし,輪符のみの形にし,知名には「削除済み」を表示して知番には打ち消し線,「削除済み」の右肩に疑問符を付けて使い方該当箇所への輪結にする。これで十分だろう。

=}
{許容}

{}