{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{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内容見ても交度見返しても心当たりがない

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

=}
{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{多段化}{進めて}{後縁の対応}{追加取得}{フラグ化}{確定出来る}{余計な検索}{目に見えている}...=}(109)

{希哲16年4月7日10歩 K#F85E/E74C-B300}

進捗時限記録中略

全知検索整備方針検討終了

2月23日頃から検索結果改良について本格的に考え始めていたが,「検索属性」を導入し,検索結果多段化進めていくことにした。

現状例えば括弧類自動付加した検索は出来るが,その出来ない括弧付き描出したい場合括弧無し検索して既存輪郭無いことを確認した後,括弧を付け再検索するということがく,とりあえずこの手間無くしたかった全知検索演算子制御任意の括弧類使える好都合ということもあった。

文字数昇順揃えてそれなりの結果になっているのでこれを降順にすればいいかと思ったが,上手く行かない場面多々あるので一時凌ぎ域を出ない

将来的な拡張性考える検索結果多段化好ましい風船輪郭輪括内検索にも応用出来る希哲14年7月30日8歩から輪括内検索輪括内のみにすると使いにくいという理由中途半端な状態になっていたが,優先表示解決出来ることに気付いた

整数値揃え兼ねた役割を与え,これを「検索属性」として利用出来るようにする。

ここまでは良いが,効率的な実装難しい単純に全ての検索パターンUNION結合すればひどいことになるのは目に見えている外充て函数余計な検索省くようにする,挿入更新時に確定出来る情報フラグ化しておくといったことに加えて後縁での出力最低限にして前縁追加取得するといった工夫必要になるかもしれない。

いずれにせよ後縁の対応進めて問題ないだろう。設計方針さえ固まれば最適化どうとでもなる

{出振るい}{Aejs 整備}{第四次宣伝攻勢}{省けた}{小さくなかった}{設計面}{第四次生活習慣改善の再開}{暖かくなってきた}{大事を取っていた}{生活習慣の乱れ}...=}(156)

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

12日脳爆発引きずってまだ脳疲労感残っていた一ヶ月分にも相当するであろう収穫だったのだから仕方ないと,気分転換兼ねて半年ほど放置していた Aejs 整備再開してみることにした。

まずは交度見直し軽く違了修正程度出来ればいい始めたものの,驚くべきことに,作業の続きよく捗った。これだけ間があくと,作業方針思い出すのと再整理時間がかかるのではないかと思っていたが,むしろ中断前より捗った気がする。この半年間での環境整備設計方針洗練知見の蓄積がそれだけ大きかったのだろう。当時は,ゆとりがなく混沌とした状況でもあった。

金風中断してからなかなか再開出来ず中途半端な状態出振るい出来ず前縁周り作業非常に進めにくい状況ではあったが,この間の収穫考えれば仕方ない思っていた設計面仕様面での変化小さくなかったので,再修正手間省けた唯一懸念だった作業再開にかかる負担全くと言っていいほど無かったのだから,仕方ないどころか大正解だったと言うべきだろう。

Aejs 整備中断経緯について記録振り返っている内に,もう一つの放置課題だった KNEST 隠し実装についても再整理急速に進んだ

輪郭選り手抜控機能整備がなかなか進まなかったことで Aejs 整備入ったのが昨年9月9日だった。14日11歩最後にそれも止まり,代わりに HTML 隠し実装からの KNEST 隠し実装重点を移すことにした。頭の整理をしているうちに18日になり,金風起きた以後は何度か再開試みている継続出来ず,そのまま第二次快調期突入した。

金風があまりに大きい出来事だったので,このあたりで記憶分断されている感覚ずっとあった特に Aejs 整備KNEST 隠し実装は,第二次快調期でも置き去りになっていた部分心残りだった。第四次宣伝攻勢向けて新生デライト開発佳境というところで二つ強力な武器上手く取り戻せた言うまでもなく極めて大きな収穫だ。

ただ,結局どっちを向いても脳爆発で,脳疲労癒えなかった


今日疲労回復のため休みにしたが,次回陶練からランニング再開することにした。

これも第二次快調期からほとんど出来なくなっていた忙しさもあったが,生活習慣の乱れ寒さ重なり,1月には風邪を引いたりもしていたため,大事を取っていた最近は少しずつ生活習慣改善再開出来,暖かくなってきたので大丈夫だろう。

最近の生活習慣改善を「第四次生活習慣改善」とするかと考えたところで,すでに金風以後生活習慣改善して使っていたことを思い出した用語として考えた12月9日から間もなく第二次快調期入ったので,目まぐるしさ忘れていたのだろう。とりあえず第四次生活習慣改善の再開」としておくことにした。


16日振り返り日記

{副日記}{デラング}{今の}{十分高い}{損はしない}{どう転んでも}{顕著に}{パンくず記法実装}{大きな狙い}{月別}...=}(132)

{希哲16年3月5日の日記 K#F85E/E74C-6986}

一昨日から始めていた輪郭整備目下課題だったまとめ作業統合し,「大輪郭整備」として継続することにした。この上旬中に,昨年から引きずっている全てのまとめ作業片付けることを目指す

この期間開発作業必要性時間対効果十分高い部分限って行うことにした。大輪郭整備没頭するため,すぐ片付けられるこまごまとした問題明日まとめて片付けることにした。


昨日いったんまとめ作業集中することにしたが,この時点では前次記法実装をした先月24日からのまとめ作業想定していた

しかし,一昨日輪郭整備手応え思いのほかく,昨日止まらなかったこの勢いで,昨年から引きずっているまとめ作業片付くのではないか,と考え始めたのが昨晩就寝直前だった。

数週間ならともかく,数ヶ月範囲になると局所的なまとめ作業」では埒が明かない。その上,連日新たな収穫がある。というわけで24日以前のまとめ作業諦めかけていたが,輪郭整備という形で外堀を埋めるようにまとめていくのが意外と近道かもしれないと思えた

最近出来たパンくず記法前次記法効用がやはり大きい主たる上位階層パンくず記法で,下位階層強調輪符交えつつ箇条書き記法で,前次関係前次記法で,と基本的な輪郭間関係書き込みやすくなり,これまでになっていた無数の輪郭描写急速に充実してきている

一昨日からは関連の輪郭整備本格化し,これがまとめ作業効率化繋がりうることに気付いたこれまで日記にせよ副日記にせよ,年別月別には整理されていなかったずっとやりたいとは思っていたものの,時間対効果疑問があった。当然書き込む手間多少増すが,今のデラングなら閲覧性操作性改善がそれよりずっと大きい終わらないまとめ作業十分に成熟したデラングやるなら最良の時期だろう。

当然現状課題当努整理にも,献典整備にもなるが,もう一つの大きな狙いとして SEO がある。パンくず記法実装をした1月14日頃から顕著に検索演心からの評価上がり,検索流入増えているどう転んでも損はしない作業になるだろう。


6日振り返り日記

=}
{デライト}{用者}{デライト開発}{『希哲日記』}{25時}{日中}{越えて}{高い}{希哲15年9月の月記}{関心を持っている}...=}(122)

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

昨日休まず深夜まで開発作業を続けた上の寝不足で,日中流石に疲労感覚えた

疲れの中で,デライト取り巻く状況などについてぼんやり考え事をしていた。

最近デライトの外デライト言及されているのを見かけることがちょくちょくある。自分が思っている以上に,デライトに興味を持ち,デライトについて考えてくれている人が多いことに,嬉しいような,申し訳ないような気持ちになる。「面白そう」と関心を示してくれる人の多さはもともとだが,いまだに,ほとんどの人がを感じているようだ。

登録用者数検索流入デライト宣伝への反応などを総合して推定するに,「個人知識管理強い関心を持つ」におけるデライトの認知度はすでに高い換言すれば,いまデライトを使ってくれそうな人の多くがすでにデライトを知っている,ということだ。やはり N10K 騒動あたりからだろうが,扇情的話題だったにもかかわらず好意的反応も多かった。しかし,その大半はデライトを使わず活動用者極端に少ない

もっとも,その半分くらいは意図したところでもあった。

いまデライト開発は,「快調」を越えて怪調」とでもいうべき状態にある。半年前には想像も出来なかった水準に,想像も出来なかった道程到達している。要因は色々考えられるが,用者少数精鋭で,手間もかからなかったことは間違いなく一つだ。ここまではそれで良かったが,当然,収益目標達成のためにこのままではいけない。

ずっと遠巻き様子を見られているようなこの奇妙状況について考えているうち,久しぶりに「ダーウィンの海」という言葉白熊作戦思い出し,吉野彰氏の『「ダーウィンの海」についての一考察』読み返した「関心はあるけど買わないよ」というのは,まさにいまデライトが受けている「面白そうだけど使わないよ」という反応のことだ。もう少し早く越えられるだろうと思っていたが,結局「ごく標準的期間」という15年にも近付いている

ふと気になったのは,ここでいう「神風」だ。デライトにとっての神風とは何か。去年の今頃,9月9日の日記にも似たようなことを書いているが,Roam Research なり Notion なりが牽引する「個人知識管理ブーム」を期待していたものの,それも微妙なところに落ち着いてしまった感があった。

しかし,ここでデライト成功すれば,いまは中途半端に見える個人知識管理盛り上がり神風だったと振り返られるだろう。結局,神風デライト成功させるのではなく,デライトの成功時代の流れ神風にするのだ。これに気付いたことは収穫だった。

新生デライト開発は,いまデライト関心を持っている人達にとっての障害取り除いていく手段でもある。そのには収益目標達成十分厚みがある。やはり,新生デライトの完成急ぐよりほかはない。


夕方から疲労感も抜けてきたが,また夜更かししそうなので開発作業は早めに切り上げた

……にもかかわらず,この日記を書いていたら25時を過ぎてしまった。

=}
{デライト}{用者}{開発}{開発記録}{領当て}{手定め}{Android}{iOS}{共有ボタンを追加しました!}{タッチ端末}...=}(71)

{希哲15年3月27日の開発 K#F85E/E74C-1FE0}

主に共有ボタン実装

想像以上に確認調整しなければならないことが多く手間取ったが,それでも OGP 対応作業開始からわずか2日納得出来る形になった。




予定通り,採用サービスは FacebookTwitterLINEはてなブックマークPocket日本国内利用者数の多いサービスをより共有ボタンに近付ける形で配置した。

Web Share API に対応していれば省略記号(...)が表示され,それを押すと端末ネイティブ共有機能利用出来る。省略記号の画像には全知検索ページャーに使っている ell.x2.png がそのまま使えた。AndroidiOS動作確認済み

当初,不揃いな各ボタンを整然と並べるために四分円を使い,横長の Twitter と Facebook,正方形の LINE とはてブ,最後に Pocket,と三段で構成することを考えた扇形共有ボタン部区が,これは廃案とした。試してみると意外と悪目立ちしたため別の領当てを模索していたところ,二段目の余った左余白に Pocket と省略記号を並べれば綺麗にまとまることに気付いた。

例えば同じ形状モノクロにするなど,よくあるアレンジを加えようかとも思ったが,各サービスの利用規約に抵触する可能性がある上,用者にとっては一見して分かりにくいものになりがちなので,公式のものをそのまま利用することにした。

各サービスの徹案依存する格好にはなるものの,TwitterFacebook に合わせているのだろうし,LINE正方形ボタンを変える理由もなく,はてブは柔軟性があるのでそれなりに安定して使える領当てではないかと思う。

用合いとしては,共有ボタンへのマウスオーバー小窓を開き,小窓からのマウスアウトで閉じるようにした上で,タッチ端末向けにクリックタップ)での開閉も出来るようにした。触り心地良好だ。

でもデライト語体の右下に置いておくことにした(デライト扉の様子・共有ボタン実装後)。

ソーシャル ボタンは,徹案の上でも処理の上でも雑然としたものになりがちなので,単純性重視しているデライトでの採用は見送り続けてきた。普段は邪魔にならず,かといって手間にもならず,用者にとっては分かりやすく,そこそこ美しくも見える……と,限りなく理想形に近いものが出来たと思う。

LINEPocket は使ったことがなかったため,本機能の手定めのためにアカウントを取った。



エクスポート機能仕様検討も進んだ(9歩)。

{手間}

{}