{希哲15年9月6日の開発}{急がない}{希哲15年9月7日}{まとめて}{やりやすくなった}{5時前起床}{5時台}{6時台}{早朝出振るい}{希哲15年9月6日の進捗時限}...=}(46)

{希哲15年9月6日4歩 K#F85E/A-E74C-F11E}

出振るい作業についての検討終了

最近,断帯を伴う出振るいタイミング迷うことがく,結果的にまとめて行うことも多くなっていた。今後,急がない出振るいについては意識的まとめて行うことにした。

保守作業中ページへの切り替え機能再整備違了処理整備輪郭選り手抜控機能整備を経て出振るい作業もずいぶんやりやすくなったが,機会損失に繋がる断帯最小化したい。

時間帯も,深夜にまとめようかと思ったが,生活律動との兼ね合いがあるため5時台の「早朝出振るい」を心がけることにした。朝のデライト宣伝6時台最適考えてきたため,流れとして丁度良いだろう。

これに伴い,明日から5時前起床目指すことにした。最近,夜更かし目立つようになってきたためこれも丁度良い

=}
{遠象性}{目指している}{近象性}{引き出せる}{動物の脳}{近象的}{進化生物学}{重要度}{ピクトグラム}{雑音}...=}(49)

{近象的であることについて K#F85E/A-E74C-4C23}

近象的であることが良いというよりも,現象遠近適切利用した方が良いとは言えると思います。

進化生物学的に考えれば,動物の脳は,状況に合わせて生存最適行動を取るための情報処理を担っているはずです。要は,情報優先順位を付けて,重要度の高い情報をすぐに引き出せるように出来ています。重要な情報は近くに,瑣末な情報は遠くに置いているとも言えます。この情報遠近法を形にしたのがデライト輪郭法です。

この輪郭法は希哲社の「知機」開発プロジェクト核心ですが,一部です。

例えば,今の一般的なコンピューターUI では,何かの目的に対し,ユーザーがアプリを選んで対応します。これは十分に近象的ではなく,雑音が多すぎます。「○○がしたい」という時に,「○○を実現してくれる××を使う」のではなく,「○○を使う」と考えられるのが近象的な UI です。

具体的には,統一感の無い絵柄アイコン固有名詞ではなく,ピクトグラムのように体系化されたアイコンで,目的を直接的に表現します。コモディティ化したアプリの仕様の大枠はプラットフォームが決め,サードパーティーはその実装を競作するか,実験的なアプリの提供を行い収益を得ます。

こうした試みは無かったわけではなく,Apple も方向性としてはそれに近いことをやろうとしていますが,突き詰めればこういう形になっていくと予想しています。

CLI でも似たようなことが言えます。例えば,「ファイルを全文検索したい」という時に find と何々を組み合わせて……と考えるのは近象的ではありません。grep -r も grep が固有名詞なので近象的ではありません。理想を言えば find 'foo' と書けるべきでしょう。

知機 Unix 相互運用標準」として希哲館が策定している Synx では,同じことが交度英語fnd 'foo' と書けます。一般の Unix コマンドと区別するため kn fnd 'foo' とも書けます。

要するに,ユーザーが頭に思い描いたことと,UI の言語体系との間に距離が無いことが,工学における近象性です。この点で現在の多くの UI には課題があると感じています。

今の UI は迂遠なことが多いので主に近象性が課題になりますが,もちろん,より複雑・詳細な表現に対応する遠象性も適切に扱える必要があります。

UI が理想的な近象性を実現した時,物理的接続しなくても,十分に脳とシームレスに繋がるコンピューターが実現出来ることになります。これを「知機」と呼んでいます。デライトも含めて,それこそ私が目指していることです。

{新生デライトの要件}{希哲15年7月22日の開発}{作業が捗る}{部分更新}{細かく制御}{駒手一発}{最適な窓構成}{適当な名前}{機が熟した}{上げておきたい}...=}(50)

{希哲15年7月22日10歩 K#F85E/A-E74C-D90E}

進捗時限記録中略

開発環境整備

作りかけ使っていなかった kn scr仮想画面単位での窓構成保存復元に使えるようにしていったん終了

画面番号適当な名前を付けて作業最適な窓構成駒手一発展開出来るようになった。各 xterm 用の screenrc用意し,シェル状態細かく制御出来るようになった。

これまでは主力機起動しっぱなしにしておくことが多く,窓構成模索していたためいちいち手作業調整していた。

最近,デライト開発最適窓構成が掴めてきたことと,外出が多い上に今年の夏に少し危険性感じること,そして昨日までに新生デライトの要件まとま作業効率可能な限り上げておきたかったことで機が熟した

これで臨時調整再起動部分更新などがずっとしやすくなり,作業が捗るだろう。

{希哲15年6月21日の開発}{希哲15年6月20日の日記}{:only-child}{輪符}{強調輪符}{破線密度}{視線の流れ}{薄い色}{結論付けた}{心許無い}...=}(160)

{希哲15年6月21日9歩 K#F85E/A-E74C-A945}

強調輪符輪結装体リンクスタイルについてのまとめ

これまで輪符輪結装体1px #999破下線にしていたが,通常の線のlightgray引用部区ブロックなど WhiteSmoke 背景の上では silver と,かなり薄くした強調記法単独で囲まれた輪符に関しては,silver一本下線にし,少し目立つようにした。

これにより,輪結リンク重要性に応じてメリハリが付くようになり,重要性変調さりげなく示唆したいような場合は軽い強調はっきり強調したい場合は重い強調というように,強調記法と組み合わせた「強調輪符」の記法確立した。

輪符自体を強調するのではなく,参照名を強調したいのであれば内側に強調記法を置くことも出来る(例:軽い強調重い強調)。

経緯

長い歴史

輪符表示をどうするかという問題は,デルン最初期からの課題だった。

最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが,いずれ文中輪符が増えてくれば,重要性によって表示し分ける必要が出てくる,というのは当初から想定していた。元々,入力道手メソッド機能自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。

実際,デライト以後,私自身の慣れデライトの品質向上によって自然と文中に輪符が増えてきた。現在,私の描出ではほとんどの輪符であり,輪結になっている。こうなると,閲覧者にとっては,どこが重要な輪結なのか分からない上に,中途半端に目立つ輪結だらけで見にくいという問題が出てくる。

もう一つ,輪符に関する問題があった。輪符知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが,これまでそれを表現する良い手段が無かった。

どちらの問題も,少し前までは自動的解決出来るのではないかと考えていた。例えば,前景輪にある輪符自動的強調表示したり,知名と異なる名前で参照された輪符斜体にするなどということを考えていた

ただ,これは描出経験を積むにつれ無理がある感じるようになった。

まず,時として膨大になる前景輪に一致する輪符をいちいち見つけるのは現実的ではない。見えている10輪限定するのも不自然見え方になるだろう。輪符参照名をいちいち照合するのも軽い処理ではない。

描写隠し文字列でも埋め込めば負荷軽減にはなるだろうが,依然として無視出来ないコストではある。何より,出与え一貫性保守性深刻な影響を及ぼすことは目に見えている。

それ以前に,自動装体スタイリング適用すべきではない場合が多々あることも分かってきた。全知検索との兼ね合いも考えると,文中目立たせたい輪符引き入れたい輪郭はむしろ一致しないことの方が多い。

知名に関しても,例えば,「知る」という輪郭を「って」のように語形を変えて参照することも増えてきた。明らかに自動装体にすべきではない,瑣末な場合が多々ある。

最近では,デラング整備進展もあり,これは手動装体,つまり何らかの記法対応すべきなのではないか,と考えるようになっていた。

今日の進展

こうした問題解決に向けて本格的に考え始めたのは,まさに今日,昨日の日記を付けていた時に,「希哲15年6月20日の開発」という輪郭を「開発では」として参照した時だった。この「開発」が,一般的な意味での開発なのか,特定の日の開発を指しているのか,一見して分からない。これは以前からずっと気になっていた問題だが,そろそろ何とかしたいと思った。

重い強調を使ってみたりもしたが,重過ぎる。そこで軽い強調を使ってみることにしたが,軽い強調は欧文向けで,斜体伊体依存した装体は避けたかった。ここで,強調輪符下線調整することを考え始めた。

強調輪符をいかに目立たせるか,ということを考えているうちに,そもそも輪符輪結全般が目立ち過ぎていることに気付いた。というより,これまではこの輪結装体軽い参照重い参照表現していたので,気付いてもどうしようもなかった。ここで,通常の輪符と強調輪符でメリハリを付けることを考え始めた。

破線は太くすると環境によって全体的に大きくなり短いでは破線らしく見えなかったりするため,一本下線にすることを考えた。もともと点下線破下線一本下線輪結の強さ表現した装体で,一本下線は前景輪のために取っておいたが,前述の理由で未使用だった。ここで,輪結装体に関する問題全般と繋ってきた。

通常の輪符に関しては,いっそのこと下線類を無くしてもいいかと思ったが,流石に文字色だけでは心許無い視線の流れを遮ることなく,視線を止めれば容易に輪結と視認出来る按配理想として,破下線を極力薄くすることにし,白背景なら lightgray引用部区など WhiteSmoke 背景の上では silver最適結論付けた

Firefox調整していたためもう一段濃い silver と darkgray の組み合せで決めかけたが,他の環境では破線密度の差でまだ濃過ぎるように見えたため,まとめ中に修正)

強調輪符一本下線に関しては,薄い色では弱いように思え gray を試したが,明示的下線を引きたい場合のために下線記法導入することも考えているため,兼ね合いであえて silver にしておくことにした。

まずは CSS のみでの出振るい:only-child で複数の輪符には効果が跨らないようにしてあるが,テキストノードは含まれうる。本来は一つの輪符のみを強調した時の効果であるべきだが,とりあえずは十分だろう。

総括

開発記録に書いておく。

{一日一文}{希哲15年4月の月記}{呼びかけ}{学べる}{律動感}{内容不足}{気を引き締める}{お祝い気分}{軽い風邪}{希哲15年4月19日}...=}(56)

{希哲15年4月19日の日記 K#F85E/A-E74C-0F65}

退院し,赤ん坊を連れてやってきた。今日から1週間ほど滞在する予定だ。長女も一緒のはずだったが,軽い風邪を引いていたため一旦帰った。

初めて抱く赤ん坊は言わずもがな可愛いものの,当面の共同生活がどれだけデライト開発影響するかは未知数だ。少し前から決まっていたことながら,何とも言えず組計上はあえて無視していた。今日は何かと手伝いもありお祝い気分でもあり,一日一文を書くので精一杯だった。

ここまでは短期集中生活後に十分取れていなかった休養だと思えばまだ問題ではないが,これ以上デライト開発失速させないように気を引き締める


一日一文書き方について少し考えた。

まず,一日の最後に書こうとすると気力が残っていないということがあるため,執務の中程で気分転換も兼ねて書くようにする。読まれやすい時間帯も考えると,18時前後が最適だろう。

題材選びはやはり難しい。書きたいことは山ほどあるが,1時間程度でまとめられることとなると限られてくる。大きく・重くなり過ぎたり,逆に内容不足になったりする。これは日頃ネタを溜めておくしかないか。


偶然にも昨日聞き始めた浪曲役立つかもしれない。

赤ん坊泣き声や突然の呼びかけに応えなければならない状況では楽曲より聴きやすい。ラジオのように気が散る情報は少なく,動画のように視覚を奪うこともないため,比較的集中力を保ちやすい気がする。文章律動感学べる

=}
{KNEST 隠し}{浮上式隠し}{希哲15年4月12日の開発}{実出与え}{隠し管理}{握接頻度}{希哲15年3月中旬}{見通しの良い}{隠し実装}{散歩中}...=}(59)

{希哲15年4月12日10歩 K#F85E/A-E74C-C35E}

散歩中KNEST 隠し設計方針について進展があったため,軽くまとめ。

KNEST 隠し実装2月9日再開してからまた停滞していた。デルンデライト最適見通しの良い隠し実装について少し迷いがあった。

先月中旬頃だったか,自我情報の取得が削りやすいことに気付き,自我の隠し化から着手しようとは思っていた。比較的少数で全ての輪郭に関わり,出与え量は少なく更新頻度も低いため,最も隠しとして利用しやすい。

難しいのは輪郭ページ単位での隠し化で,とにかく膨大握接分散するため,自我と異なり工夫が必要になる。

少なくとも,握接頻度で隠し全体を一定の大きさに保っておかないと破綻するのは目に見えている。

ここで,握接のたびに浮上して,一定数を越えると沈んでいるものから破棄されていくようなリスト連想配列とは別に持っておくことを考えた。効率的理積み(特に重複の削除)は別に考える必要があるが,これなら隠し管理をだいぶ単純化出来る。

各隠しには隠し化した時点の時印を持たせておくことも考えていたが,これは応付にしておく。サービスの性質上,実出与え反映時間差を持たせたくない場面も多く,一律に持たせても無駄な出与えになる可能性が高い。

{新生デライト}{気分的}{希哲15年4月下旬}{黄金週間}{年度始め}{年度末}{希哲15年3月25日}{希哲15年3月24日}{希哲15年4月中旬}{希哲15年5月1日}...=}(45)

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

気分的4月1日を一つの節目にしたいと思っていたが,考えてもみれば,世間では年度末忙しい人が多い時期だ。気持ちゆとりが無ければデライトのようなものを試せるはずもなく,宣伝攻勢には全く適していなかった。

奇しくも,デライト収益目標達成努力期限を単純に1ヶ月延期しただけの5月1日ゴールデンウィーク3日目で,開発集中することにしていた4月中旬までを過ぎれば年度始め慌しさが落ち着き始める。このことにも気付いていなかった。

4月中旬までに新生デライト完成させ,下旬までには第三次宣伝攻勢開始5月1日までには結果を出す……これが計らずも最適組計になっていたわけだ。黄金循環から黄金週間へ,というのも出来過ぎている感があるが,まあ持ち辺のために青写真は出来過ぎているくらいで良い。

寝不足気味が続いている上に昨日目まぐるしい進展があり,若干の気疲れを感じていたため,今日は今週分の休日にした。状況もよく整理出来たので,ここでいったん呼吸を整えたい。

{新生デライト}{第三次デライト市場戦略}{第二次デライト市場戦略}{使い果した}{希哲15年4月中旬}{思いも寄らない}{目が回る}{希哲15年3月19日}{ウェブ黄金時代}{希哲15年5月1日}...=}(61)

{希哲15年3月19日の日記 K#F85E/A-E74C-7CAC}

ここ数日,目が回るような思考変化神経悲鳴をあげているのが分かる。たまに車酔いしたような気分になる。今日は久しぶりにから活動を始めることが出来たが,この調子なので残りの半休にして少し心身休めた。

雑務を片付けていると思いも寄らない形で組計見通しが良くなり,4月中旬まではこのままデライト開発没頭出来る可能性が高くなった。

5月1日までの収益目標達成睨むなら,いずれにせよその頃には決定的手応えを得る必要がある。4月中に売上確実視させるだけで事実上の収益目標達成であり,出来なかったとしても立て直し容易い

より高い完成度新生デライト目指す第三次市場戦略では,品質向上にかける開発時間をどれだけ確保出来るかがであり,思いがけずその鍵を拾ってしまったことになる。第二次市場戦略からの転換結果的大正解となった。

最近よく感じていたことだが,「ウェブ黄金時代」とでもいうべきこの時代最適技術構想,そして潤沢開発時間を有していることほど柔品開発者としての幸運はない。これを無駄にしたら罰が当たりそうだ。

流石にこんな悪運使い果した気がするので,この一ヶ月で何としてでも決着を付けたい。

=}
{最適}
{}