{overflow: hidden}{進捗記録}{希哲16年3月2日の開発}{希哲16年3月2日の進捗}{希哲16年3月2日}{position: relative}{overflow: clip}{調整していく}{揃わなくなる}{縦位置}...=}(83)

{希哲16年3月2日10歩 K#F85E/E74C-FDA9}

=}
{『希哲日記』}{}{ネット環境整備}{多過ぎた}{腰を据える}{もう一息}{残した}{希哲15年10月25日}{まとめ作業}{新生デライト開発の再開}...=}(45)

{希哲15年10月25日の日記 K#F85E/E74C-CEE4}

新生デライト開発を再開する前に,中途半端ネット環境整備ドメイン名完全集約についてのまとめ作業終わらせようとネット環境整備の方から着手した。

ネット環境整備に関しては安定性若干課題残したまま一段落としたが,折角ここまで整備したのに惜し思えてきたもう一息なので,この不安定性早めに解消してしまうことにした。

もう25日なので,デライト収益目標に関しては今月中の達成断念し,11月腰を据え取り組むことにした。

新生デライト開発没頭出来るよう,今のうちに月記穴埋めもしておきたいと考えると,今月整理整備まとめ割り切るべきかもしれない。むしろその方が希哲館創立14周年気持ち良く迎えられる気がする。それでも収穫多過ぎたくらいだ。

=}
{進捗記録}{希哲15年7月9日の開発}{編集用注釈コメントを入れる}{編集者注}{備忘注}{隠し注}{覚え注}{非技術者}{込め注}{編集用注釈}...=}(36)

{希哲15年7月9日16歩 K#F85E/E74C-0200}

デラング整備文書整備

編集用注釈コメントを入れる」をざっとまとめて終了。

非技術者向けに「コメント」という概念をどう説明するかんだ結果,「編集用注釈」略して「編注」という翻訳語暫定的採用することにした。「コメント」は簡易マークアップ言語用語としては紛らわしい場合が多々ある。

込め言」の応用で「込め注」を採用しかけたが,見出しを見ただけでは意味が分かりにくく,結局「編集用注釈」と説明せざるをえない,というところで断念した。

「編注」は辞典にこそ見当たらないが一般に「編集者注」の意で使われている。見せるか見せないかの差はあるものの,その一種とは言えるので理解はしやすいかもしれない。

裏注隠し注覚え注備忘注……などいくつか他の翻訳語も考えたが,まだ決め手に欠ける。

=}
{開発}{デラング}{開発記録}{letter-spacing}{Android}{iOS}{倍角ダッシュ}{倍角ダッシュ問題}{希哲15年6月19日の日記}{複数段落引用記法}...=}(72)

{希哲15年6月19日の開発 K#F85E/E74C-A3FD}

デラング整備

とりあえず細かい記法実装から済ませてしまうことにし,かねてから考えていたダッシュ記法出典記法実装,概ね満足出来るものになった。当初はそれほど期待していなかったが,想像以上表現の幅が広がりそうだ(公式解説)。

ダッシュ記法

ダッシュ記法は,特に扱いにくい倍角ダッシュが簡単に扱えるようになったのが想像以上に大きい。

この問題は,昔,『道草録』記事名に使おうとしてから認識していた(「Org-Mode の機能、組み込み LaTeX — その1」)が,いまだにこれといった解決策が無く,日本語電子文書課題になっているので,それなりの宣伝効果もありそうだ。

最初,エムダッシュU+2014を2つ繋げて,CSS で何とか調整しようと考えたが,フォントによって太さ長さ統一感がなく,負の letter-spacing で間が開かないようにすると短過ぎて倍角ダッシュに見えなかったりした。しかも,環境によっては重なった部分が濃く見えて結局綺麗な倍角ダッシュにならないという問題に気付き,これは断念した。

最終的に,罫線素片U+2500を使うことにした。罫線を作るための文字である性質上,letter-spacing が 0 であれば隙間が出来ないことはほぼ保証されている。SLFSAndroidWindowsmacOSiOS確認した。

罫線素片による倍角ダッシュの表現はよく見られるものだが,同時によく指摘される問題点として,これがダッシュであるという意図表現出来ないというものがある。例えば,縦書き表示した時に横棒のままになってしまうことがある。

これを踏まえて最初にエムダッシュを利用しようとしたのだが,よく考えると,デラングであれば,ダッシュ記法という仕様によって意図保存しつつ,表示上最適化に徹することが出来る。

出典記法

ダッシュ記法と引用記法の組み合わせとも言える出典記法も実装出来た。

複数段落引用記法の終了記号との兼ね合いをどうするかと思っていたが,これは単純に,出典記法を終了記号としても扱うことで上手く解決した。

ここも意外に他の軽標記言語では面倒だったりするので,デラングの小さな売りになりそうだ。

その他

成果想像以上だったが,これらを実装するのに想像以上に多くの障害があった。

特に,正規表現周りで躓くことが多く,正規表現の扱い方について見直す良い機会にもなった。

{第二次宣伝攻勢}{進捗記録}{散歩}{領当て}{睡眠}{希哲14年10月18日の開発}{希哲14年10月18日の進捗時限}{希哲14年10月18日の進捗}{希哲14年10月18日}{描出ボタン}...=}(21)

{希哲14年10月18日1歩 K#F85E/5B28-526A}

昨日は30時までの描出ボタン実装第二次宣伝攻勢開始を目指したが,28時頃,諸場向けの領当てがある程度まとまって細部の問題を考え始めたところで急激に眠気が強くなり断念

30歩近くの進捗は数えるほどしか記憶になく,健康上危険を感じたため,睡眠を取った。

何日も家に籠りっきりだったため散歩をするなどして13時30分頃作業再開。夜の第二次宣伝攻勢開始を目指す。

途中で終了。

=}
{<img>}{進捗記録}{領当て}{希哲14年10月10日の開発}{画像補完}{nil.png}{遅延読み込み}{2x}{ダミー画像}{二重読み込み}...=}(49)

{希哲14年10月10日17歩 K#F85E/5B28-AF96}

デライト用合い改良

途中で終了。

.hl_b.x2_b を使った画像補完(今日から仮命名)について,微妙な欠陥発見試行錯誤していた。

src 属性を元に後から srcset 属性を追加するのは,いくら DOMContentLoaded でも間に合わず,二重読み込みが発生する。

src 属性省略しても事実上問題は無さそうだが,仕様上必須とされているため,どうも気持ち悪い。つまり,何らかの画像を読み込ませることは避けられない。

単純な img 要素noscript 要素で囲んでおき,スクリプト解除するという方法を思いつき,理論的には一番美しい気がしたが,レンダリング領当てが事前確保出来ないという致命的欠点があり断念。スクリプト側では noscript 要素の内容をテキストとしてしか取得出来ないのもすっきりしない。

スクリプト依存はいまさら仕方ないとして,ダミー画像を用意することにしたが,埋め込み画像保守性の観点から使いたくない。/img/nil.png あたりの名前を使うことにした。HTTP/2 も導入したことだし立求負担は軽い。

目的とする画像data-src 属性 に書いておくか,まだブラウザ解釈しやすい srcset 属性にするか少し悩んだ。2x だけを記述しておけば,場合によっては src 属性を無視してくれることも期待出来るが,記述がやや煩雑になる。遅延読み込みにも応用出来る data-src の方を使っておくことにした。

=}
{第二次宣伝攻勢}{『希哲日記』}{希哲14年9月の月記}{良い遅れ}{悪い遅れ}{希哲14年9月29日}{デライト用合い改良}{虱潰し}{経験上}{用合い}...=}(41)

{希哲14年9月29日の日記 K#F85E/5B28-EE5F}

デライト用合い改良が長引いているため,今月中の第二次宣伝攻勢開始は断念,とにかく用合い改良に専念することにした。

16日から3日間での解決を目指した用合い改良がもう2週間になるが,長年先送りにしてきた用合い上の課題虱潰しにする作業であること,途中で大きな時間調達が出来たこと,想像以上の収穫も多々あることなどから,総合的状況は悪くない。

同じ目標に対してかける時間だけが増えていくというのを「悪い遅れ」とすると,手応え収穫反映させながら増えた時間以上に高い目標を目指せるようになるのは「良い遅れ」と言える。経験上,こうした遅れは良い結果をもたらすことが多い。時間の使い方が最適化される過程でもある。

最近のでは,「新規利用者登録自我登録)からの動線整備」に感触が近い。これも散々寄り道をして当初予定より大幅に長引いたが,結果として新規利用者登録円滑化期待を越える成功を収めた。

しかし,流石にそろそろ第二次宣伝攻勢を待てない時期に来ている。

=}
{断念}

{}