{Dex 改良}{Dex 行処理仕様}{希哲15年5月19日の開発}{特殊文字列}{現在行}{部区個体}{デラングの不具合}{end()}{bgn()}{不明確}...=}(64)

{希哲15年5月19日13歩 K#F85E/A-E74C-E14D}

デラング整備Dex 改良

途中で終了。

ここで Dex 実装Dex_Tにおける行処理仕様確定させておくことにした。

確定仕様

次行への移行は Dex::bl_T 個体Ctn() で自身を指す指示体を返すか,指示体を通して現在行変数に特殊文字列(現在は仮に"&&skip;"を設定した場合のみとし,それ以外は原則として現在行を維持する。

経緯

これまで,とにかく動くことを優先させて不明確な部分だったが,流石にそれで保守性維持するのは難しい規模になっていた。

10日の開発デラング不具合修正から Dex 設計見直し記法実装へと移行してきたが,これも仕様方向性を決めるためだった。一昨日の開発リスト記法実装途中で,ある程度こうあって欲しいという仕様が見えてきて,昨日の開発で入ったのが「Dex 改良」だ。

これまでのデラングの不具合で多かったのが部区切り替え失敗することだが,これも行処理の仕様が曖昧だったことが大きな原因としてある。

単純に入力を行毎に読み込み,それを部区個体スタックで処理していくという実装だったため,「現在行が勝手に進んでしまう」という問題があった。これへの対応を部区実装毎にやろうとすると複雑化してしまう。

意図

そこで,新しい部区や上位部区への移行時には現在行を維持し,同一部区での処理を継続する場合にのみ行を進めることにした。部区移行時にも明示的に次行に進める手段として,現在行を特殊文字列に置換する方法を使う。これは部分的に実装して好感触を得ていたため,部区毎ではなく共通処理化する。

bgn()Ctn(),Ctn() と end() の間でも現在行を維持することにした。後者は従来通りだが,前者では次行に進んでしまっていたため,混乱することがあった。これは少し悩んだが,bgn() と Ctn() は共通処理が多くなるため,この仕様の方が単純化する場面が多いだろうと判断した。

要するに,特定条件でなければ現在行が動かないようにすることで挙動把握しやすくする,というのが本仕様の意図だ。

課題

本仕様で概ね問題ないと思われるが,しいて言えば,各部区個体Ctn() 実装を厳密にしないと,容易に無限循環に陥いる。これまでのように行処理が勝手に進んで勝手に終わってくれないためだ。

ただ,無意味な循環を検知するような対策は難しくないので,大きな問題ではないだろう。

{デラング}{正規表現}{希哲15年3月7日の開発}{自動適用}{機能不足}{希哲15年3月7日の進捗時限}{希哲15年3月7日の進捗}{希哲15年3月7日}{KaTeX 導入実験}{デラング整備}...=}(29)

{希哲15年3月7日14歩 K#F85E/A-E74C-350D}

KaTeX 導入実験をしながらデラング整備方向性が見えてきたので軽く考え整理して終了。

構文解析導入はまだ時期尚早なので,現状の正規表現処理を上手く構造化しながら近いうちに機能不足を一通り補う作業に入りたい。

版存管理に関しては日付を使い,輪郭時印を元に自動適用する方向検討する。

これなら積極的変更を加えられる。

{デラング}{希哲15年3月3日の開発}{希哲15年3月3日の進捗時限}{希哲15年3月3日の進捗}{希哲15年3月3日}{デラング整備}{デライト文書整備}{使いやすい}{描写記法}{検討}...=}(34)

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

今後のデラング方向性について検討して終了

そろそろ本格的デラング整備必要時期だと感じているが,ここで位置付けが明確ではなかった「デラング」を正式名称として採用積極的に使っていくことにした。

個人的には使いやすいのでよく使うようになったが,公式文書などでは「描写記法」を主に使う方針だった。

デライト文書整備にあたって,Markdown のような一つの標記言語として認識しやすいこと,「デライト」から連想しやすいことなどの利点重視した。

将来的には Markdown よりも普及させたい。

=}
{希哲14年9月29日の開発}{大きな収穫}{1001px以上}{641px以上}{1000px以下}{640px以下}{1280px以下}{480px以上}{標準領当て}{幅広領当て}...=}(57)

{希哲14年9月29日6歩 K#F85E/A-5B28-F3DF}

デライト用合い改良媒体求頼切り替え点についてまとめて終了。

従来,媒体求頼切り替え点@xpd_ss()定義していた640px以下641px以上1000px以下1001px以上。昔月庭のために適当設定したものをそのまま引き継いでいた。

端末に合わせるのはキリがないため,デライト機能最大限に活かせる画面幅向けの領当てを「標準領当て」とし,それより狭過ぎる場合を「幅狭領当て」,広過ぎる場合を「幅広領当て」と呼ぶことにした。

標準領当てにおける画面幅下限上限見極めるため,細かく画面幅を変えながら検証してみると,480px以上1280px以下標準領当て維持出来ることが分かった。

例えばデライトの扉改行を挟まずに自然に見えるのが480pxあたりからであり,横に広がり過ぎて文章が読みにくくなるのが1280pxあたりまでになる。結果的に画面広さとしてはキリがよく,一般的な切り替え点にも近いものになった。

もともとデライト画面幅依存するような要素を極力削っており,例外的画面幅に対して微調整を入れる,という考え方媒体求頼を使っていたが,この方向性確信が持てた。

長い間もやもやしていたことに解決道筋が見えたことは大きな収穫だった。

=}
{デライト運営記録}{新規用者}{デライト設定画面の様子}{内部設計}{希哲14年9月14日}{デライト初描出の見本}{利用者設定}{自我名}{公式アカウント}{月庭改装}...=}(42)

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

月庭改装までの暫定的措置について検討4歩)。

接渉まわりの実装点検,取り急ぎの修正5歩)。

検索窓挙動改良8歩9歩)。

一通り気になることを片付けたため,利用者設定自我設定)実装に戻る。取り急ぎ自我名だけ設定出来るようにして終了(デライト設定画面の様子)。

簡単なようで内部設計から徹案まであちこち調整必要時間がかかったが,それなりに方向性は定まって良かった。

最近,ちょくちょく新規用者からの描出があるが,絡んでいいものかどうか少し悩む性格にもよるだろうが,いちいち開発者運営者反応されるのは気持ち悪いと思う人もいるだろう。

特に K#F85E で絡むのは困惑させる気がするため,デライト初描出の見本で使った K#9-C7C6 を暫定的公式アカウントとして,よほど困っていそうな場合のみこれで対応することにした。あとは用者に任せておくべきだろう。

開発そのものではないが,日記に書くには瑣末な,こうした運営上の問題も今後増えてきそうなので,新たにデライト運営記録を付けることを考え始めた。

{デライト市場戦略}{デライト宣伝}{希哲14年9月10日の日記}{朝昼晩}{頂帯}{自由業}{需要層}{ネット利用}{希哲14年9月10日の進捗時限}{希哲14年9月10日の進捗}...=}(53)

{希哲14年9月10日2歩 K#F85E/A-5B28-5B5B}

デライト市場戦略デライト宣伝見直し

平日は,ネット利用に関する各種調査でそれぞれ朝昼晩頂帯ピークタイム)とされる7時12時21時前後にデライト宣伝集約することにした。その間に開発を進める。

これまでデライト関心層需要層見極めかねていたこともあり,宣伝昼夜を問わず行っていた。

デライトは見かけこそ軽常だが,正体は極めて高度知能増幅技術であり,例えば研究者自由業など,必ずしも一般的な生活律動ではない関心層想定していた。

ただ,これまでの経験上,明確にそうした少数派からの反応が良いわけではないし,玄人受けを狙っても Roam Research のように伸び悩みは見えている。デライトはあくまでも多数派を取り込む必要がある。結局,ここでデライト市場戦略デライト宣伝方向性一致したことになる。

Twitter などであれば,その時ネットを見ている人はいつでも掴めるが,人がたくさんいる時にまとめて収集するより効率が悪い。なにより,常時ネットを観察していると集中力が削がれるという問題がある。限られた時間の中でメリハリをつけて効果的に宣伝することを考えれば,時間帯絞り込む必要がある。

自分自身の生活律動のためにもなり一石二鳥だ。

=}
{デライトの数式対応}{KaTeX}{latex2png}{希哲14年8月28日}{希哲14年8月28日のツイスト}{通類}{模動}{捌き手}{デルンの実用化}{ツイスト}...=}(26)

{あれ K#F85E/A-5B28-0D01}

昔,デルンの実用化2012年)をする前に使っていた Org-Mode という Emacs模動モード)で,LaTeX 数式を書くと PNG に変換した画像に置き換えてくれる,という機能がありました。実は,当初からデルンにも似たような機能を付けたいと思っていたのですが,先延ばしにしてきてしまいました。

Org-Mode での実装は,確か latex2png のような変換通類を使って画像を生成するというだけの単純なものだったと思うので,捌き手側で K#9-EDD2 さんが見つけてくれたような画像変換機能を作るのは難しくないはずです。

KaTeX というのは初耳でした。だいぶこのあたりの最新事情に疎くなってしまったようです。今ならもっと選択肢が色々ありそうなので,勉強して早めに方向性を決めようと思います。

{方向性}
{}