{希哲16年3月3日}{『希哲日記』}{輪郭整備}{気ままに}{臨時半休}{気が休まらない}{全休}{気楽に}{過ごせた}{多くなった}...=}(38)

{希哲16年3月3日の日記 K#F85E/A-E74C-74B3}

予定通り臨時休業にした。久しぶりに気楽に過ごせた

ここのところ半休にすることが多かったが,のように過熱しがちな時期には全休有効なようだ。半休では進捗が出るまで気が休まらないし,進捗が出だすと熱中して止まらなくなる

そもそもなぜ半休多くなったのかといえば,脳過熱定休日前に臨時半休にすることが増え,その代わり定休日半休にして……と調整していたからだ。

臨時半休仕方ないとして,今後定休日常に全休とすることにした。


休日の過ごし方として,気ままに輪郭整備をするのはやはり良い娯楽のようなものでもあり,頭の整理にも献典整備にもなる。

=}
{進捗記録}{導入する}{文字装飾記法}{下線記法}{斜体記法}{太字記法}{打ち消し線記法}{希哲16年1月23日16歩}{微妙な要求}{たまにあった}...=}(94)

{希哲16年1月23日12歩 K#F85E/A-E74C-5AE3}

進捗時限記録中略

3歩きっかけ久しぶりに実装予定文字装飾記法について見直し,以下のように基本的方針整理した

<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~

下線記法については,_下線_有効にすることも考えていたが,適当に書いた時の誤解釈増える懸念もあり見送ることにした。文字装飾記法2個以上記号統一した方が綺麗にまとまる簡潔な記法追加するより削除する方がずっと難しいので,使用頻度考えてもいまあえて導入する動機に乏しい

……ここまで考えて昨年6月23日10歩でも同じ結論を出していたことに気付いたが,再確認出来た。


太字記法については,昨年6月23日9歩では ++太字++検討しているものの,最近 ++行内埋め込み記法利用することを考えているためこれは避けたい。そもそも「強調ではない太字」という微妙な要求のための記法であり,廃案脳裏をよぎった

分かりやすい代替記法がありうるのかと思ったが,意外と ##太字##悪くない。「くっきりした」という意味シャープにもかかっているし,見た目濃さ丁度良い後述文字サイズ記法同様,記号の数濃さ調整出来ても面白い


ついでに<<大きい文字>>>>小さい文字<< という文字サイズ記法思いついた大きさ小ささ記号の数調整出来てもいい。直感性申し分ない

あまり文字を大きくしたい思ったことはないが,小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあったので良い拾い物だった。


斜体記法打ち消し記法については特に変更無し


上線記法検討していたが,ここまでで HTML の要素相当するものはい,軽標記言語としての表現力十二分なので,いったんここで一区切りとすることにした。

{場筋}{`grub-mkfont`}{GRUB の設定}{Unifont}{pf2 フォント}{`GRUB_FONT`}{`GRUB_GFXMODE`}{`gfxterm`}{`GRUB_TERMINAL`}{`GRUB_BACKGROUND`}...=}(23)

{GRUB 背景画像の設定 K#F85E/A-E74C-706C}

/etc/default/grubGRUB_TERMINALgfxterm出放りに,GRUB_GFXMODE適当にして,画像場筋パスGRUB_BACKGROUND設定する。

gfxterm有効にするために GRUB_FONT設定する必要があるgrub.cfg に,フォント読み込みを見てから gfxterm設定をする箇所がある)原パッケージには入っていないため,pf2 フォントgrub-mkfont で作る。フォントによっては罫線などが乱れたりするが,Unifont なら日本語でも無難に表示する。

$ sudo grub-mkfont --output=/boot/grub/fonts/unifont.pf2 --size=24 unifont.ttf

/etc/default/grub の例:

GRUB_GFXMODE=auto
GRUB_GFXPAYLOAD_LINUX=keep
GRUB_BACKGROUND="/boot/grub/bg.png"
GRUB_FONT="/boot/grub/fonts/unifont.pf2"
=}
{希哲館}{希哲館事業}{『希哲日記』}{デライト}{ネット環境整備}{綺麗な展開}{公式に}{政治的独立性}{拭えない}{誤解の余地}...=}(133)

{希哲15年10月31日の日記 K#F85E/A-E74C-BA88}

今日までに途中まとめ作業片付けてから明日希哲館創立14周年迎えようと思っていたが,順調に改善している生活律動のため,無理せず来月持ち越すことにした。雑多な考え事頭が一杯だったところに,たまたま被った第49回衆議院議員総選挙のせいでまた一つ重い考え事が出来てしまった。

新生デライト開発の再開とともに朝の日課再開するつもりだったので,ネット環境整備ドメイン名完全集約についてのまとめ月記穴埋めは,朝の輪郭整備少しずつでも片付けていくことにした。

結局金風希哲館事業14年目最後を飾ることになった。15年目デライト収益目標達成せば,それはそれで綺麗な展開だ。


今回の総選挙では,記憶にある限り初めて白票を投じてきた。

私の政治思想明快既成政治勢力一線を画しているが,これは選挙権得た20歳の頃には概ね固まっていた。従って,既成政党政治家積極的に支持することはない,という立場一貫している。ただ,この立場正しく投票行動反映させるのは難しいとも感じていた

これまでの選挙振り返ると,ほぼ野党への消極的投票消極的野党支持棄権のどちらかだった。黙って投票するなら白票よりは消極的野党支持の方が有効だろうと思っていたし,希哲館事業成り行きの方が日本にとって重大な政治問題であるという考えで,寸刻を惜しむような時期には堂々と棄権してきた。

今回白票を投じることになった理由としては,デライト上で投票記録を取ることを考えるようになっていたことが大きい。これまでは,投票に行ったとしても適当な野党野党候補に入れるだけだったため,投票先に関しては記録もしていなければほとんど覚えてもいなかった。

しかし,希哲館執務長としての投票行動公式に記録公開することを考えると,消極的支持とはいえ特定政党や特定候補者名前を出すことは誤解を招きかねず,極力避けたい棄権にも政治参加否定するような別の誤解を招く可能性がある。となると,白票を投じるしかないことになる。

こう考えて投票を終えた後で,第25回参議院議員通常選挙時のように具体的な投票先を明かさない消極的野党支持という選択肢もあることに気付いたが,それにしても誤解の余地はあり,不透明感拭えない。結局,白票一番潔い。「希哲党」と書きたい気持ちもあったが,今は迷惑行為にしかならないだろう。

公開前提とするなら,白票にも希哲館政治的独立性表明する手段としての意義見出せなくもない。希哲党結党実現するまでは,この「白票原則」を採用することにした。長年すっきりしない問題だったので,これはこれで大きな収穫だった。

=}
{進捗記録}{Slackware 時代}{ネット環境整備}{希哲15年10月26日の開発}{希哲15年10月26日の整清}{内部配線}{試していない}{良い復習}{弄っていなかった}{変わらなかった}...=}(70)

{希哲15年10月26日9歩 K#F85E/A-E74C-A67B}

ネット環境整備配線整理過程SLFS における USB 3.0 ポート認識不良についての調査始めたものの,未解決保留

主力機には筐体前面背面にそれぞれ2つずつ USB 3.0 ポートがあるが,Linux では Slackware 時代からいまいち使えた試しがない。それもそのはずで,どうも USB 3.0 ホストコントローラー認識されていない最初から Windows仮想機でしか入れていないので,Linux 固有問題かもしれない。

lspci では Etron TechnologyEJ168 が見えるがドライバ表示がなく lsusb では表示されない。

怪しいのは UEFI核脳構配起動応付あたりだが,今のところよく分かっていない。UEFI 設定見直した明らかおかしい所は見つからなかった

核脳構配では,そもそも USB 3.0有効にしていなかったので CONFIG_USB_XHCI_HCD=yCONFIG_USB_XHCI_PCI=y加えて核脳再構築をしたが,相変わらず。更に CONFIG_USB_XHCI_PLATFORM=y を加えても変わらなかった

これまで使っていた Linux 核脳 vmlinuz-4.9.9-slfs-t2希哲11年6月28日備立したもので,しばらく弄っていなかったので,良い復習にはなった。今回の備立は一応 vmlinuz-4.9.9-slfs-t3 としておいた。今後何かと調整しやすくなるだろう。

起動応付変更はまだ試していないが,急ぐことでもないので今日はこの辺でやめておいた。

内部配線問題もありそうな気がしてきたので,今度の主力機清掃時に確認してみる。

{一日一文}{Google 検索}{分かる}{デライト}{希哲15年5月の一日一文}{Qt: デライトは見出しが無くても困らない}{検索品質}{気に入った}{全てを知る}{名付けた}...=}(114)

{全知検索について K#F85E/A-E74C-4287}

個人知識管理(PKM)サービスを「知能増幅(IA)サービス」に発展させ,まずは Google に代表される検索演心エンジンと,Facebook に代表される SNS からいわゆる GAFAM切り崩す……これがデライトの成長戦略だ。

既存の SNS に対する「KNS(knowledge networking service)という概念については比較的よく語ってきたが,既存の検索演心に対する「全知検索(full-knowledge search)については十分に語ってこなかった。デライトを使い始めた人がまず戸惑う部分でもあるので,考え方だけ簡単説明しておきたい。

全知検索というのは,各輪郭に付けられる知名輪郭名対象とする検索のことだ。一般に「ページ名」などと呼ばれる部分を主な検索対象とするわけで,一見不便なようにも思えるだろう。

ただ,輪郭同士の関連付け柔軟性利用することで,慣れてしまえばさほど問題なく,面白い検索体験が出来るようになっている。検索語から繋がる情報手作りしているような感覚とでも言えばいいのか,これは開発者である私にとっても意外なことだった。


実は,デライト基礎になっているデルンという CMS実用化した当初,当たり前のように全文検索(full-text search)基本にしていた。しかし,使い込んでいるうちに,これはこれで問題があることに気付いた

デルンは,これまでに無い手軽さ大量情報を相互に結び付けられるように設計された。頭の中にある情報を,輪郭同士の立体的入れ子関係で表現する。その関係をひたすら作っていくことが使い方基本だ。

ある言葉について検索した時,その言葉について何を考え,それが何と結び付いているのか,これがまずデルンの検索で得たい情報になる。ところが,全文検索では余計な情報が引っかかり過ぎてしまう。少し言及しただけの輪郭も引っかかるので,それを一覧でざっと見てからその検索語について新しく描出投稿するかどうか考える必要がある。これは,デルンの使い方を考えると明らかに遅かった

そこで,いったん知名だけを対象にしてみた。すると,最初にイメージした検索語を打ち込んで,それが有るのか無いのか,瞬時分かるようになった。その知名を持つ輪郭に関連する輪郭を関連付けていく,というデルンにとって本質的作業と非常に相性が良いことにも気付いた。

これを用者ユーザー認知に基いた全く新しい検索手法として「全知検索」と名付けたわけだ。「全てを知る」と見せかけて,実は無知自覚させるという「無知の知」的な皮肉を感じさせるところも気に入った

全文検索は本文にある情報検索出来るが,逆に言うと,本文に無い情報は検索出来ない。

例えば,画像のようにそもそも文字情報を持たない献典コンテンツのようにあえて直接的表現を避けた文章,内容を書き換えたくないがこの検索語で引かっかって欲しいという古い文章……こういったものにも,全知検索であれば検索の道筋を作ることが出来る。

Google 検索ですら長年解決していない検索ノイズ問題にも有効手段となりうる。

これまでの検索というと,機械が抽出した情報から,人間が要らないものを指定していくという,いわば「ブラック リスト検索」だった。全知検索では,最初から人間が結び付けたい情報を指定しておく。いわば「ホワイト リスト検索」だ。


……全知検索の考え方は大体こんなものだ。

ただ,デライトでも全文検索実装しないと決めているわけではない。補助的にあれば便利なのは間違いないので,何らかの手段で全文検索も出来るようにはするつもりだが,あまり優先順位は高くない。

結局,慣れてしまうと全知検索でも十分引っかかりやすいように書くようになるし,現状,誰よりもデライトを使い込んでいる開発者があまり必要を感じていないのだ。

全文検索に無い利点がある上,全文検索と比べてはるかに低負荷で動き,慣れてしまえば全文検索が無くても困らない実用性がある。これはもう検索においてページランク級の一大発明と言っていいのではないかと思っている。

ウェブ検索という分野では,Google ですらページランク以上の革新を生み出せず,継ぎ接ぎ対策検索品質を保っているのが現状だ。

全知検索には,かつてページランクがそうしたように,ウェブ検索を原理からひっくり返す可能性がある。

{一日一文}{第三次宣伝攻勢}{第二次宣伝攻勢}{第一次宣伝攻勢}{宣伝攻勢}{開発}{デライト}{14ヶ月}{半年以上}{3度目}...=}(60)

{デライト第三次宣伝攻勢開始に思うこと K#F85E/A-E74C-69D3}

今日24日デライトは「第三次宣伝攻勢」を開始した。簡単に言えば,3度目積極的な宣伝活動を始めたということであり,裏を返せば,デライトには積極的に宣伝活動をしていない時期があるということだ。

デライトは,昨年2月13日に一応の正式離立リリースを果した。ただ,品質上の問題が多々あったため,しばらくの間はほとんど宣伝しなかった。

本格的な宣伝活動を開始したのは,半年以上経った9月8日だった。それも16日にはいったん停止した。これが「第一次宣伝攻勢」だ。「第二次宣伝攻勢」はその約一ヶ月後,10月20日から今年1月29日まで続いた。

つまり,正式離立から14ヶ月余りのうち,積極的な宣伝活動をしていた時期は,合わせて4ヶ月にも満たない。これは改めて計算してみて自分で驚いた短さだ。もう半年くらいにはなると思っていた。それだけ濃い日々だったのだろう。


デライト宣伝にこうした緩急があるのは,その時に最善時間配分を考えた結果だ。限られた時間有効に使おうと思えば,「時間対効果最大化」を常に意識する必要がある。

当然ながら,私は開発経営デライトに関する全てのことを自分でしているので,宣伝活動だけに時間を使うわけにはいかない。ひたすら宣伝して人を集めたはいいが肝心の製品に十分な魅力が無い,というのでは意味も無い。

これは宣伝に限ったことではない。デライトには問題山積している。あってしかるべき機能は色々欠けている,不具合はあちこちにある,文書もろくに更新していない……だが,全てを最初から整えられる人間はいない。限られた時間の中で,優先順位を付けて一つずつ片付けていくしかない。

そして,時間対効果の最大化を考えると,宣伝にもある程度「溜め」が必要であることに気付く。同じだけの時間を使うのであれば,より品質の良い状態で製品を知ってもらった方が良いわけだ。

ひっそり開発を進め,ある程度品質自信が出来たところで宣伝攻勢をかける。その反応次第でまた開発中心の時期に入り,課題が概ね解決出来たところで宣伝攻勢をかける……最初からこういう計画だったわけではないが,結果的にこの繰り返しデライト自体は順調に来ている。一定の合理性はあったということなのだろう。

柔品ソフトウェア開発における風林火山といったところか。

{有効}

{}