{希哲15年4月16日の開発}{再同期}{問題箇所}{不正知番}{希哲9年6月26日}{dg_sync_n_bg()}{dg_sync_n_fg()}{突き止め}{UPDATE 求頼}{正午前}...=}(74)

{希哲15年4月16日4歩 K#F85E/A-E74C-E7C9}

前後景輪数表示不具合修正

いったん終了。

この問題に気付いたのは今日正午前だが,昨日26時頃までは問題無かったため,この10時間ほどの間に発生したと思われる。

具体的には,_dg_oln自我知番が K#F85E の場合に限り n_fgn_bg がそれぞれ一つの数値統一されてしまっているという問題だった。この数値は _dg前景後景の自我知番を検索した時の数値に一致することを確認した。

このことから,誤った UPDATE 求頼で K#F85E の全ての輪郭更新をかけてしまった,ということは間違いない。その求頼がどのように発生したのか,ということまでは突き止め切れなかった。n_fg・n_bg を更新するのは dg_sync_n_fg()dg_sync_n_bg() くらいなので,直接的にはこれらの仕業だろう。


発見してすぐ全輪郭に対して dg_sync_n_fg()dg_sync_n_bg() をかけ,完了した13時30分頃には正常化したことを確認済み

最後に1輪だけ,修正されないまま残った輪郭があることに気付き調べてみると,知番 A- 以後が 0 の明らかに不正な輪郭だった。描出希哲9年6月26日知名は「イタリアの地方自治」だった。デルンもまだ不安定な時期だったので,こんな輪郭が紛れ込んでいてもおかしくはない。いずれにせよ存在してはいけない知番なので,当該輪郭は削除済み

一つの可能性として考えられるのは,この輪郭に誰かが握接し,不正知番dg_sync_n_fg()dg_sync_n_bg()誤作動を引き起こした,ということだ。最近,クローラー巡回激しいので,握接したのは誰であっても不思議ではない。

ただ,軽く試象してみた限り,問題箇所は見つからなかった。流石に,多少の不正知番WHERE 句致命的な狂い方をしないようにはしてある。

それほど深刻な問題ではないこと,概ね可能性が絞り込めたこと,復旧容易なことから,ここでいったん調査打ち切ることにした。今後はこの問題を頭の片隅に置いて周辺作業を進め,再現した時は再調査することにした。


元々前後景輪数表示に関しては多少狂うことがあるのを認識していたが,この復旧作業によってそれらもいったん正常化したようだ。

また,全輪郭再同期すると現状およそ1時間30分ほどかかることが分かったのも収穫だった。今後同様の対応が必要になった時の参考にする。

=}
{デライト高速化}{希哲15年4月14日の日記}{希哲15年4月14日の開発}{高度な機能}{修正回数}{重くなる}{当たり外れ}{作業分類}{機能整備}{速いデライト}...=}(174)

{デライト高速化前の現状整理 K#F85E/A-E74C-A2D0}

希哲15年4月14日本格的デライト高速化に入る前の現状整理について,ここに記録しておく。

2月後半を預っていたこともあり開発集中しにくかったが,3月の頭からデライト開発はいわば「快調期」に入った。この想定外快調でそれ以前の計画良い意味狂うことが多くなり,3月8日からは計画にとらわれず直感に従って作業を進めていくことにしていた(日記)。

この快調によって,より高い完成度での新生デライトを目指すことが出来るようになり(第三次デライト市場戦略),3月20日収益目標達成努力期限5月1日延長28日にはこれを必達期限として,同時に短期集中生活に入った(日記)。短期集中生活は今月10日に終え,やり残した待っ読ボタン実装昨日一段落した。これが「デライトこれまでのあらすじ」といったところか。

少し落ち着いたところで,次の作業に入る前に現状整理することにした。収益目標達成期限まで残すところ半月,作業の優先順位見極める必要があった。短期間にこれだけのことがあると,流石に頭の中も混乱気味だ。もやもやしたものを晴らしておきたかった。

現在のデライト開発速さ予測不可能性を考えると,やはり中途半端な計画足枷にしかならない。「黄金循環高速化」としてのデライト高速化中心に,機能追加文書整備宣伝等々,全てを臨機応変巻き込みながら片付けていく,というのが現状での最適解結論付けた。

デライトにとって最大の付徴輪郭法であって,枝葉末節機能ではない。それを磨き上げ伝わりやすくする作業でもある。


作業項目としての「デライト高速化」を意識し始めたのは2月17日の開発からだった。当初は機能追加よりも優先し,文書整備並行させることを考えていた。その後,快調期に入ってから機能追加優先順位が上がり,特に Dex によるデラング整備優先するようになっていった。

今月頭の時点での大まかな見通しは,10日までに必要な機能追加20日までに新生デライト仕上げ,文書整備を終え,21日から第三次宣伝攻勢を開始,並行してデライト高速化を進める,というものだった(1日の日記)。

ところが,@icl() 周辺整備をきっかけに入った小理腑が,1〜2日という想定よりも長引き(6日間),上旬がほぼ潰れた。更に,これが思わぬ体感表示速度向上に繋がったことで,一気に高速化への持ち辺が高まった。この頃から,どちらかといえば後回しにするつもりだった高速化を最優先にすべきではないか,と考えるようになっていた。待っ読ボタン実装を終えた昨日の時点でほぼ腹が決まっており,最終確認のためにこの現状整理をしているわけだ。この判断収益目標達成成否直結するだろう。


デライト高速化の主な意義としては,用者体験の向上,SEO負荷軽減の3つを当初から見込んでいた。

小理腑後は,これに開発効率描出効率向上という意義が加わった。手定め時間短縮にもなるし,より描出を上げを増やすことにも繋がるだろう。頭では分かっていたことだが,速いデライト体験して実感が出てきた。この「先行体験」をさせてくれた小理腑の影響が大きい。

Dex 以後,デラング活用することにした文書整備にも寄与することになる。


高速化に並ぶ大きな作業分類であるデラングを含む機能整備機能追加),文書整備と比べても,やはり高速化が優位だろう。何より,高速化は技術面でも設計面でもデライト向きであり,この中で最も「伸ばせる」ところだ。本領発揮と言ってもいい。

機能追加が訴求するかどうかは当たり外れが大きい。開発者が求めているものと用者が求めているものは異なることが多いが,用者が求めているものと必要としているものも往々にして異なる。要望に応えても,思ったより必要なかったということもある。これは用者が馬鹿だからではない。開発者ですら,思ったより要らなかった,要らないと思っていたが意外と便利だった,ということは多々ある。人間そんなものだ。それでも,十分な時間があれば「数撃ちゃ当たる」で成功確率を高めることは出来るが,今はそうではない。

そもそも,現状デライト活動用者極端に少なく,動向分析する標本にもならない。まずは入り口の手前にいる人達を呼び込む必要がある。そのためには,一部の用者しか使わない高度な機能よりも第一印象重要であり,これに寄与するのは高速化だ。

また,機能追加には程度の差こそあれ通信処理上の負荷が伴なう。予定している機能を現状のデライトに全て詰め込めば明らかに重くなるのは目に見えている。


文書整備に関しては,ある程度機能整備が済んだところか,少なくとも機能整備と並行させなければ作業効率上の問題がある。これだけ仕様変更機能追加が激しい状況でなまじ文書を追随させても修正回数が増えるだけだ。先の理由で機能整備を後回しにするなら文書整備も後回しにするほかない。

現状,「使い方」などの文書は離立補完を最後にほとんど更新しておらず,実装との乖離が激しくなっているが,逆に言えば,無駄な修正作業が省けたということだ。新生デライトが熟れるまで放っておくのも一つの手だろう。

宣伝においても体験重視するようになる中で,相対的な重要性が低下していたということもある。「良い文書のある悪い体験」よりは「悪い文書しかない良い体験」の方がマシだ。


黄金循環」は,1月から再認識し,2月までよく言及していたが,3月からは快調期目まぐるしさ横に置いていた。

振り返ってみると,2月20日の日記高速化との結合予期するようなことを書いている。ただ,それほど強く両者の結合意識していたわけではなく,黄金循環高速化手段明確ではなかった。「全知検索の改良」と言っても,基本的な部分で問題の多かった希哲13年頃に比べ,今では範囲が広過ぎる。

快調期以後,計画ではなく直感に従うという戦法難局を上手く切り抜けてきたが,「次の作業」を意識するようになった短期集中生活終盤あたりから,作業になるものが欠けていると感じていた。

ここで高速化黄金循環結合してそのとして機能し始めるのだから,劇的な展開と言うほかない。ここまでの経験が全て一つに繋がったことになる。

{練り直す}{希哲15年4月11日}{短期集中生活}{生活律動矯正}{組計}{『希哲日記』}{半休}{開発作業}{心身}{作業}...=}(14)
{一日一文}{涙ぐむ}{途方もない}{呼吸を整える}{小休養}{ぶっきら棒}{希哲15年4月6日}{思い付いた}{凝り過ぎ}{興奮気味}...=}(67)

{希哲15年4月6日の日記 K#F85E/A-E74C-8087}

少し気持ち落ち着いてきたため,利楽しながら作業を進めた。それでも程度の進捗ぶりではあった。

短期集中生活とはいえ小休養必要は感じながらも,連日興奮気味でまともに睡眠も取れないということが続いていた。ここで少し呼吸を整えたい。


一日一文準備も進めた。

一日一文の歴史を遡っていて,久しぶりにブログ『道草録』思い出した希哲館事業最初期から WordPress運営していたブログで,ある面でデルン前身と言えなくもない。この「道草」という言葉は,希哲館事業途方もない大きさを前に全てが手探りだった当時心境をよく表している。色々な想い出が蘇えり,少し涙ぐんでしまった。

題名も気に入っていたので,希哲8年頃に私の随筆集として『道草録』再始動させようと考えたこともあったが,何となく立ち消えになっていた。一日一章を始めて間もない頃だったので,いずれ関連させようとは思っていたのだろう。

ここで,一日一文『道草録』素材にすることを思い付いた。これも一つの希哲館累新だ。

考えてみれば,月庭・デライト転送の開始以後,kitetu.com から窓口になるような献典が無くなっていた。ほぼ毎日書いている文章といえば『希哲日記』だが,これは当時の心境事実記録することに主眼を置いたもので,人に読ませることを意識したものではない。『希哲日記』に書き切れないことを書いておく所としても『道草録』という題名好ましい

読み手意識した文章として,メリハリを付けるためにも一日一文には敬体を使おうかと思ったが,気を使い過ぎて書きにくくなってしまう恐れがある。多少ぶっきら棒なくらいが良さそうなので,まずは常体で書き始めることにした。

続けるのが難しかった最大の理由は,書き始めるとついつい凝り過ぎてしまうということにあった。1時間以内で書こうと思っていても,結局数時間かけてしまうことが多かった。それが普通になると書き始めるのにも気力が必要になってしまう。

{希哲15年4月5日の開発}{希哲15年4月5日の進捗時限}{希哲15年4月5日}{希哲15年4月5日の進捗}{進捗記録}{進捗時限記録}{進捗時限}{テンプレート}{月庭}{作業}...=}(14)
{垢を落とす}{デライト小理腑}{希哲15年4月3日}{デライト一日一文}{意味管理}{希哲13年}{KitHub}{『希哲日記』}{考え事}{大理腑}...=}(19)

{希哲15年4月3日の日記 K#F85E/A-E74C-BC50}

開発では,そろそろ必要だろうと考えていた「デライト小理腑」に入った。希哲13年大理腑ほどの時間は取れないが,ここ数日で出来るだけ垢を落としておきたい。

デライト一日一文準備も始めた。その過程で色々な考え事もした。

特に,虎哲開発版存管理関係デルンによる意味管理有用性等についてよく考えた。すでにデライトが「KitHub」みたいなものなのかもしれない。

{希哲15年4月3日の開発}{描画乱れ}{デライト小理腑}{希哲15年4月3日の進捗}{希哲15年4月3日}{希哲15年4月3日の進捗時限}{装体書整理}{理腑}{@icl()}{大理腑}...=}(19)
{希哲15年3月30日の開発}{見出し階層}{文字の太さ}{見出し装体素案}{見出し装体}{希哲15年3月30日の進捗時限}{希哲15年3月30日の進捗}{希哲15年3月30日}{文字の大きさ}{見出し記法}...=}(30)

{希哲15年3月30日9歩 K#F85E/A-E74C-2DB4}

見出し装体検討

いったん終了。

結局,下図のような形式で進めることにした。



文字の大きさ太さ下線などで見出し階層表現するのは限度があるため,見出し記法アスタリスクを活用した徹案にする。

階層が一目で分かりやすく,記法も理解しやすい。

通常,デライトでそこまで深い階層が必要になるとは考えにくいが,例えば他所で書いたものを貼り付ける際に欲しいことがないともいえない。実際,むかし Org-Mode で書いたものをデルンにそのまま貼り付けたりしたことはあった。

アスタリスク徹案には竜胆蛍応用してもいいだろう。

{希哲15年3月24日の開発}{輪郭指示体}{希哲15年3月24日の進捗時限}{希哲15年3月24日の進捗}{希哲15年3月24日}{Dex 実装作業}{譜類添付機能}{Dex_T}{デラング整備}{輪結装体}...=}(21)
{希哲15年3月23日の開発}{ややこしい}{見え方ボタン}{閉じるボタン}{最有力候補}{難しかった}{ボタンラベル}{大きな理由}{多機能化}{描き方ボタン}...=}(72)

{希哲15年3月23日7歩 K#F85E/A-E74C-66D7}

デラング整備,「描き方ボタン」について仕様をまとめて終了。

デラング多機能化に伴い,学習宣伝等の観点から,他輪郭描写素文をもっと閲覧しやすくする必要が出てきた。

現状,Ctrl + ダブルクリックで閲覧することは出来るものの,ボタン自輪郭描き直しボタンのみ表示しているため,説明されなければどのように素文を見るのか初心者には分からない。

描き直しボタン追加時からしばらく全ての輪郭でそのまま表示していたが,紛らわしく,用合いもずっとごちゃごちゃしている時期だったため他輪郭では非表示にするようになった。

調整して復活させることは度々考えてきた。そのたび見送っていた大きな理由に,良い表現が見つからないということがあった。特にボタンラベル等に使う文言難しかった

簡潔かつ直感的ということで最有力候補は「覗く」だったが,漢字を使うと少し印象が硬い,平仮名で「のぞく」では「除く」と紛らわしい,語感もあまり良くない,そもそも何を覗くのか初見分かりやすいとも言えない,と一番マシな案が難点だらけだった。

今回の再考で,「描き方」が使えることに気付いた

描き直しボタンアイコン領当てはそのままに,ボタンラベルは「描き方」に変える。機能描写部Ctrl + ダブルクリックした時同様,描写欄のみ開く。

知名欄でも一部デラング記法を使えるようにする予定はあるが,利用頻度を考えると余計に感じることが多いだろう。従って,描写部が無い他輪郭では引き続き非表示とする。見る手段がないわけではないので困ることは少ないはずだ。

描き方ボタンで開いた場合,完了ボタンはもう少し自然に閉じるボタンにする。「見え方ボタン」にするのも面白いかと思ったが,かえってややこしいかもしれない。

「〜で描き直す」「〜で完了」から変えていなかった通注も「〜で描き方を見る」「〜で閉じる」とする。

=}