Android 版の開発と並行して

EBt Server の構想もほぼ固まりました。

とりあえず PC版だけ、先に進みます。具体的には、EBt Server をどこかに1台立ち上げておくと、ネットワークを監視し、定期的に同期をかけるようになります。これで、複数台のPCを使っていても、どのPCでも、常に最新のEBtが使えるようになります。EBt Server をインターネット側から見えるようにすると、クラウドっぽいことが出来るようになります。（個人的には、これをクラウドというのに抵抗がある）

で、サーバーとの同期は Android にも、そのうちに実装します。

すると、別に同期操作とかしなくても、いつでどこでも最新のEBtデータが見える。

EBt for Android には、カメラ機能も実装するつもりなので、出かけた先では Android で適当にカメラとか使ってデータ収集、家に帰ったら、そのデータをPCで確認・編集というのが、特別な操作なしで（ほぼ）可能。

なーんてのを構想しています。

家でサーバー立ち上げるのが嫌な人向けには、私がサーバーを立てて公開しようかと考えています。ただ、無償でサーバーまで立ち上げると私の財布が悲鳴を上げるので、サーバー利用に関しては多少寄付をもらいたいけど（200～300円/年程度)。しかし、この金額だと、送金の方がお金がかかってしまう不条理。どうしたもんだろうかね。

なお、お金取るけどこんな金額なので、あまり期待はしないように。サーバーは、とりあえず現在休眠中のSizkaORIONぐらいしかないし。HDDもRAIDじゃないから不安だし。お金が集まったら、RAIDのシステムが組めるかもだけど、多分、寄付金でそれがまかなえるとは思えない（まず間違いなく無理）。

ちなみに、これだけのものを休みの日に作るのはどれだけかかるんだろうね。1年じゃすまんな。

時間が欲しい。

今日のEBt。テーマ「知識の共有に関する考察」

EBtをマルチユーザー化したいという事は、一時期真剣に考えた事がある。普通に、WebでEBtデータを共有して、みんなで色々とリンクを張ったり、修正したりすると、きっと良いものができるはず…なんて思っていた。

で、実際に検討を始めると、そんなに簡単ではないという事がわかってきた。問題点を端的に書くとこんな感じ。

●自分と他人で、リンクを作るときの視点が違う。

これは根の深い問題。メモAとメモBの間にリンクを張る人と張らない人が同じEBtデータを共用する可能性がある。これは、データ管理上、致命的な問題になり得る。なにせ、これはEBtのリンクという根幹に関わる問題なので、これを解決しないと、とてもEBtのデータを多人数で共有するなんて事はできない。

で、色々考えたりした。

解決策１）リンクに可視性を付与する。

自分にしか見えないリンクを作れば解決するんじゃないかと思った。でも、リンクを作るという方向しかない。邪魔なリンクが消せないのでこれは却下。

解決策２）リンク情報以外に、アンリンク情報を持つ。

自分の気に入らないリンクは消せるようにする。但し、それはリンクを外すのではなく、人単位のアンリンク情報として持つ。一見良いアイデアのような気もしたが、ここまで考えてふと気がついた。

…秩序を乱す人（意識的にせよ、無意識にせよ）がいたら、どのみち、EBtのデータは崩壊する。

この辺が、EBtの限界なんだろう。

メモはともかく、リンクもEBtのデータ構造としてはとても重要。リンクには間違いなく意味がある。但し、その意味はリンクを作る人がわかっているだけ。それを明文化していない。だから、ある人にとってはリンクは意味があるが、ある人にとってはリンクは意味がない。意味がない人にとってはそのリンクは邪魔以外の何者でもない。間違いなく知識の衝突が起きる。

知識の衝突が起きたときにどうするか。それはとても難しい。もしかしたら、各個人が自分の知識領域を持ち、他人は自分の目元他人のメモの間にしかリンクが張れない…なんて事にしたらいいのかもしれない。でも、これは知識の共有手段としてはいまいち。でも、どこかに線を引かないと、確実に崩壊する。

知識の共有は、個人的にはとても大きなテーマだったりする。ただ、間違いなく難しい。多分、メモとリンク以外に何か新しい概念を考えないといけないんだろうと思う。属性をつけるだけで解決する話なのかもしれないけど、EBtの基本的な発想…シンプルというものに反する。

もしかしたら、知識の共有そのものが実は無理なのかもしれない。何らかの枷をはめる事は、知識の共有を行い場合には必須なのかもしれない。

知識の共有については、しばらくは未解決の課題として残ると思う。

今日のEBt。テーマ「知識と記憶」

まぁ、言いたい放題言いますよ、ここでは。というわけで、今回のテーマ。知識と記憶。

EBt のデータ構造、昔は知識をあらわそうと思って作っていました。でも、何となく、最近、その方向性が揺らいできています。

有り体に言うと、知識がわからなくなってきました。

EBt に自分の知識を吐き出そうとしているんだけど、見るたびに思うのは、自分の知識と言うよりは、記憶を保存する先になっているなぁ…ということ。まぁ、知識と記憶はどちらも似たようなものだという気がしないでもないが、気持ち的には体型だった「知識」というよりは、混沌とした「記憶」の方が、何となくEBtのデータ構造にマッチしている。そんな風に思い始めています。

知識というと、何となく整理されている物を思い浮かべてしまうんですよね、どうしても。で、そもそも私自身がいい加減な人間なので、そもそもEBtに登録したデータを整理する気があんまりないんですよ。私の何となくやりたいことは、何でもかんでも放り込むことが出来る、柔軟なデータ置き場。これって、知識じゃなくって、記憶という言葉の方がしっくるくる。そんな気がします。もちろん、記憶もどこか適当なタイミングで整頓しなければいけません。そのときに、いかに記憶がうまいこと引き出せるか、それがデータを蓄える時点で考えなければいけないこと、そう思うわけです。

記憶を知識に格上げするのに何が必要なのか。それは、まだわかりません。そもそも、格上げ…混沌とした記憶の整頓が必要なのか。なんか、データを蓄えれば蓄えるほど要らないような気がしているのですよ。

なんか、整頓しても、しきれないと思うんですよね。だったら、やめちまえ、そう思ったりするわけです。

知識を整頓しようとすると、どうしても、意味とか、考え始めるんですよ。もちろん、そういうことを考えることはとても重要だし、それによって新しいひらめきとか発見もあるので、積極的にやるべきだと思う。

で、前にも書いたんですが、意味って、難しいんですよ。そして、知識のネットワークって、どんなにがんばっても EBt なんかでは表現できないと思うんですよ。

EBtのメモ数は蓄えたデータ量を知る上でとても役に立ちますが、リンク数も気にすると色々面白いと思います。リンク数は、そのまま蓄えたデータのネットワークの質に影響している、そう思うわけです。全メモに相互リンクを張るのはあまりにも無意味ですが、リンクの少ないメモばかりだと、ネットワークが出来ていないという意味で、またもったいないですね。私の場合、1メモあたり平均8～9個のリンクがあります。無意味なリンクもいっぱいあると思いますが、参考までに。

てなわけで、私の今の使い方では、ひたすら記憶に相当するメモを書くようにしています。それだけでも、ものすごく便利ですしね。所詮EBtに書くことはメモなんですから、堅く考えちゃいかんのですよ、きっと。

今日のEBt。テーマ「方向の意味」。

とりあえず、ネタが尽きるまでに多様なことを書き続けるぞ。というわけで、今日のテーマ。方向の意味。

EBtはデータとデータの関連性はリンクで表現します。で、リンクには基本的に方向はありません。ラベルを使うとちょっとだけ方向という概念が出てきますが、基本的にはオプション。EBtでは、方向なしのつながりが基準です。

私は基本的には頭の中のデータのつながりは方向つきだと思っています。但し、頭の中には縦横無尽につながりが張り巡らされているため、実質的には意味付きの方向付きのリンクが無数に張られており、方向無しリンクと同等のネットワークが構成されている…そう思っています。

で、一つ忘れてはいけないのは、頭の中で考えていることを何らかの形に吐き出すのは非常に難しいということ。頭の中の方向付きネットワークをすべて吐き出すのは、多分無理。そもそも、頭の中を何らかの形で外に吐き出した時点で、情報は劣化します。ならば、劣化することを前提に、データのモデルを作った方が良い。

EBtは、方向なしのリンクを使うことで、ある意味、考えることを一つ放棄しています。そして、リンクの意味をあえて曖昧にしています。方向無しであるが故に、リンクに意味づけすることも難しくなっています。EBt の基本思想は、シンプル。意味づけはあまりにも難しく、EBtのレベルでは対応することなんか無理。だったら、止めてしまえと言うことです。

ちなみに、方向付きリンクを使うだけでは、意味の表現手段としては不十分だ…と私は感じています。方向に意味はあるかも知れないが、二つの情報の間の意味を表現するには不十分。なぜなら、任意の二つの情報の間にある意味を、たかが矢印一つで表現できるわけないじゃないと思うからです。EBt はラベルを実装していますが、そんな物を使ったって、リンクの意味なんて表現できません。結局、現存するどんな手段を使っても、意味を表現するなんてことは出来ない筈なんですよ。もし、表現できていると思うなら、それが本当に意味をすべて表現しているかどうか考えた方が良い。部分的な意味を表現しているに過ぎないはずです。

もちろん、単純化した意味を表現することも、十分に意義があるだろうと思います。そこは正直トレードオフです。ただ、経験則で語らせてもらえば、多くの意味を表現しようとすると、データは複雑になります。そして、複雑なデータを作ろうとすればするほど、確実にパワーが必要になります。そして、パワーが必要なことは、人間やらなくなります。

ここで、EBtの目指すところなのですが、結局、手軽にデータを溜めていきたいのですよ。手軽と言うのが一番のキーワードで、手間がかかるのであれば、たとえそれに意味があってもEBtでは採用を控える方向で考えます。Zaurus 時代は、まだ自分の方向性がはっきりしておらず、何でもかんでも詰め込む方向で開発していましたが。というわけで、昔とはちょっと考え方が変わってきていますが、最近の考え方はこうです。

リンクには、基本何らかの意味があります。意味があるからこそリンクを張る。ただ、EBtでは、そのリンクの意味を定義しない。考え方としては、しっくりこない人の方が多いでしょうね。ただ、意味を表現することによる利点だけに目が行ってしまっていないか、そこは使う人に考えてもらいたいのです。意味を付けることが、常にプラスであるとは、私にはとても思えないのです。

なんか、方向だけじゃ無くって、意味そのものまで否定し始めたのでそろそろ方向を元に戻しましょう。

私の意見をまとめるとこんな感じ。

意味表現の手段として、方向付きのリンクを使っても、実はあまり嬉しくない。ならば、いっそ方向なしにして、シンプルにしてしまえ。

リンクを方向ありにして、それに意味を持たせることは、一見良いアイデアのように見えます。世の中の多くの仕組みもそうなっています。htmlのリンクなんかも、文字列にリンクを当てはめることで何となく方向付きのデータの関連づけを行っていますしね。

だから、EBt がリンクの意味づけをある意味否定しているからと言って、リンクの意味づけが駄目だということは全くありません。EBt のモデルがベストだとは思わないし。

うん、やっぱりEBtは私の妙な思想が入り込んでいますね。まぁ、唯我独尊なシステムですね。わかりにくいという声はよく聞くし。こんなひねたシステムだから、取っつきにくいわな。でも、わかりやすくすることは、EBtのコンセプトそのものを否定することになるから、きっとやらないだろうな。

今日のEBt。テーマ「リンク」。

今日もEBtについて語ります。今日はリンク。

リンクを、何のために使うか？ということは、EBt を使う時に一番最初に越えなければいけないハードルだったりします。

で、これについて私が言いたいことは一つ。「深く考えるな」。

どうやら、小さい時から訓練されている影響なんじゃないかと思いますが、分類というのがどうしても頭の中に浮かんでしまう人が多いように思います。もちろん、リンクを使って分類することも出来ますが、分類を必要以上に意識する必要はありません。

EBtのリンク構造は、分類するためだけのものではありません。リンク構造は、単純なつながりを表現するものだと思って下さい。分類をしようと思うと、その時点でまた発想が阻害されます。

単純に、関連するものをつなぐだけで良いんですよ。EBtは。もちろん、分類したければすればいい。でも、分類するだけだったら、EBtを使う必然性はあんまり無い。もちょっと先を狙いましょう。狙う先は、分類では表現できない情報のつながりです。

たとえば、私のEBtでの作業は、主に「今日のメモ」を中心としています。今日起きたことは、すべて「今日のメモ」にリンクします。買い物メモ、出来事、思いついたこと、などなど。全部、今日のメモにリンクしています。これはつまり、後日、「その日」をキーワードにして「その日に起きたこと」を連想出来れば、EBtのリンクの目標はほぼ達成できています。

もちろん、「買い物メモ」には、更に色々リンクが張られますよ。たとえば文庫本を買ったとしたら、「本（文庫）」という分類的なメモにもリンクを張るし、「作家名」メモにもリンクを張る。すると、それだけで、買った本のデータベースや、作家からたどることが出来る本のデータベースができあがる。後日、本の感想などもリンクを張るだろうし、リンクはどんどん広がっていきます。

私は、いわゆる普通のDBが嫌いです。テーブルを定義して、SQLで呼び出して…というのが、DB管理において確立された手法であることは重々承知しています。でも、私は嫌いなのです。

何故嫌いか？それは、DBを定義するのが嫌なのです。だって、これからどんなデータが入ってくるかわからないものをあらかじめ定義なんてできっこないし、したくもない。DBを定義するのは、これからの思考を型にはめてしまうことだと思います。だから、定義なんてことはしたくない。

更に個人的な主張が続きますが、システムの都合を、さも当然の制限のように受け入れる風潮があるように思うんですよ、私は。私がDB嫌いっていっても、「でも、DBってそういうものでしょ？」といわれると、私はとても残念な気持ちになります。そういう発想をしている間は、新しいアイデアなんか浮かばない。そう思うわけです。

私はファイル名なんてものも嫌いなんですよ。何で同じファイル名があっちゃいけないの？そんなのシステムの都合でしょ？何でユーザーに押しつけるの？なんて思います。以前、こんな話をしたら「同じファイルが複数あったら区別が出来ない」といわれたことがありますが、これ、完全にシステムよりの発言なんですよね。ファイル名をユニークIDとして扱うのは、完全にシステム側の都合なんですよ。そんなものは、システムの奥に隠蔽してしまうべき物で、ユーザーにユニークIDを見せるシステムは駄目だろうと思う訳です。

だから、EBtは、メモの名前のユニーク性は一切求めません。ファイル名はシステムの後ろに隠蔽しました。ユーザーには、ファイル名は見えないし、意識する必要もありません。

実世界だって、同じデータが複数あるなんてことはざらですよね。何でコンピューターで扱い始めたとたんに特別扱いになるんだか。

話がそれたので元に戻しましょう。

リンクは結局何？という話なのですが、「情報のつながり」以外の何者でもありません。つながりに特別な意味を持たせると「分類」になったりするわけですが、気持ちはこんな感じです。

「情報のつながり」⊃「分類」

もちろん、慣れていない人は分類から入ってみるのも悪くありません。しかし、分類しかしないんだったら、もったいないなぁ…と思います。

結局は、頭の中で何を考えているかなんですよ。私は、ツリー状の分類に違和感を感じずにはいられない。あえていうならば、頭の中では分類をしているかも知れないが、それは1種類の分類ではあり得ないと思います。数え切れないほどの分類が頭の中の記憶を縦横無尽につないでいる、そう思います。つまり、これはネットワークであり、リンクになります。

知識をどうやって表現するか？という問題は奥が深くて、私にはとても立ち入ることは出来ません。そもそも知識とは何だ？とか考え出すと、そこには出口の見えない迷宮が広がっているように思うわけです。

EBt のリンクは、知識に関するごく簡単なモデル化をした物です。シンプルであるが故に、色々切り捨てています。切り捨てた分は、使う人が補わないといけないのが辛いんだろうな、なんて思うこともあります。

特化と汎化をここで使うことが正しいかどうかわかりませんが、EBtのリンク構造は、汎化した先にあると思っています。で、通常のアプリケーションは、特化した物が多い。特化した物は、色々具体的になっているので使いやすいが、汎化した物は、自分で概念を構築しないといけないから難しい。なんて思います。

EBt のリンク構造が、知識のモデル化がうまくできているか、実はあまり自信はありません。他にもいいモデル化があると思いますが、私の頭では思いつかないですね。でも、EBtのモデル化は、私の頭の中を表現するにはちょうど良い作りになっています。EBt がそこそこ使われているというのは、この構造がそんなに大外しではない…と思っても良いのかな、と思います。

というわけで、今日はリンクについて話しました。基本、私の話はよく脱線します。今日も豪快に脱線しましたが、まぁ、こんなもんです。

今日からしばらくEBtについて語ります。今回のテーマ。基本概念。

いや、なんかね。Piggydb というソフトのページで軽くEBtのことが話題になっているので、そこの助けになればいいかなと思いまして。でも、そこに土足で入り込む気合いがないので、このblogで適当に語ろうと思います。

てなわけで、今回のテーマ。基本概念。

EBt のデータ構造は、メモ＋リンクだけです。メモには、テキストだったり画像だったり URL だったりとかありますが、これらをすべてひっくるめてメモと言います。リンクは、メモとメモをつなぐひもです。ひもには特に方向がありません。一応、ラベルなんていう方向付きの概念もあるのですが、これはあくまでもリンクに従属する情報であり、オプション的なものです。なので、リンクは双方向。ここがスタート地点です。

これだけ書いて、いきなり歴史の話になりますが、ここに至った経緯ぐらい書かないといけないかなーと思ったので書きます。

さて。昔から使っている人は EBt の元アイデアが BTRON にあるということは薄ぼんやりとわかっていると思います。もちろん、それはある程度正しいのですが、他にもAIの世界での知識表現の世界(is-a, とか、has-aとか)もベースになっていたりします。自分の中では、BTRONとAIに接したのはほぼ同時だったので、どっちが先というものでもありません。ただ、どちらにも共通なのは、リンクは単方向ということです。

で、勉強し始めた時、リンクには方向があるものだと教えられたし、それが自然だと思っていました。だから、そんな構造がシステムとして素直に表現できる BTRON も、「当然そうだよね」と感じて使っていました。BTRONは超漢字になる前（Bright/Vでしたっけ？）の頃から使い始めました。が、色々と使っていて不自由を感じていました。確かに、リンクを使った知識表現方法は強力だ。すごく便利だ。しかし、なんかしっくりこない。多分、自分が慣れていないんだろうと思ってかなりがんばったのですが、やっぱりなじめませんでした。

このとき、自分のデータを見て、気がついたこと。

・よく使うデータは、双方向にリンクを張っている。
・単方向のリンクは、データをよく見失う。そして、袋小路に入ってしまう。
・この知識がどこで使われているのかわからない。

まぁ、色々不満があったけど、BTRONをがんばって使っていました。とはいえ、この「がんばる」というのが結構辛い。がんばってBTRONにデータを構築していったのですが、データの蓄積がとても辛い。そして、そのうちに BTRON そのものを使わなくなりました。結構投資したんですけどね…

ちなみに、同時期に WZ Editor もガンガン使っていました。これの WZ memo もなかなか良かったのですが、これはこれで色々制限が多く、使いにくかった…

あと、忘れてはいけないのが Zaurus。PI, MI, SL と世代が変わっていきましたが、ここにデータを保存して持ち歩きたいという欲求がどんどん膨らんでいきました。SL-Zaurus を見た時、「ここでBTRON動かないかなぁ～」なんて思っていました。ですが、そんな事があるわけもなく、MI ザウルスとか PI ザウルスに比べて使いにくくなったなぁ…などと思いながら、がんばって SL-Zaurus を使い続けていました。

この頃、自分の頭の中で、どんなソフトが欲しいかは大体決まっていました。

・テキストデータが保存できればいい（ここは贅沢は言わない）
・リンクは逆方向にたどれないといけない（まだ双方向とは思っていない）

んで、Ruby, Ruby/Qte を見つけ、「これを使えば、そんなに時間をかけなくても作れるかも」と思い、作ったのが EBt （初代）です。

ちなみに、初代はこんな特徴があります。

・リンクは方向付き（但し、逆方向にもたどれる）

で、使った結果、やっぱり双方向にリンクを張りたくなるんですね。あと、リンクの方向がメモを管理する上で非常にうざい。リンクの方向に縛られて、思考が阻害される。なので、さくっとリンクを双方向にしました。

てな感じで EBt の骨格ができあがりました。あとは、Web でたどれますね。いろいろと機能は追加していますが、本質は変わっていません。メモとリンク。これだけ。

概念としては、これが基本だと思うんですよ。これ以外の概念は、オプション。リンクは単方向と双方向とどっちが基本かは議論がありますが、私は双方向が基本。単方向はオプションとしました。

理由は簡単。Aに従属するBを考える時、AからBを連想することもあるし、BからAを連想することもあるんですよね。単方向の知識って、無いんですよ。少なくとも私の認識では。だから、双方向を基本的な概念に据えたんです。

もちろん、日常の発想は方向付きなのは重々承知の上。知識は、「リンク」＋「リンクの意味」で出来ていると思う。だけど、正直、「リンクの意味」はテキスト化できない。リンクの意味をテキスト化できるほど私の脳は洗練されていないしね。あと、メモからメモを見ると、意外とリンクの意味は「想像できる」。AとBを見比べると、「あぁ、なるほど。確かにつながっているね。」と思う。でも、つなげた理由は、色々あり難しい。この意味を考えないとリンクが作れないなんてことになったら、私はメモを作らなくなる。

色々能書きをたれましたが。

メモとリンクは知識の表現のエッセンスである、というのが、私の結論。

ちなみに、あるえらい人の言葉。誰だったかは忘れたけど。しかもうろ覚えだけど。
「難しいことを難しくいうことは誰だって出来る。難しいことを簡単に説明することが出来るようになれ。」

この人の教えに、EBt が従えているかはわかりませんが、これは大事なことだと思っています。

EBt はまだまだ難しいんですけどね。シンプル化しすぎたか…。

EBt for Windows (EBtWin) Version 0.0.5-1 snapshot-6 を公開しました

なんか、ばたばたしてます。

今度こそ大丈夫なはず。

ダウンロード EBtWin-0.0.5-1-snapshot-6.zip (83.5K)

EBt for Windows (EBtWin) Version 0.0.5-1 snapshot-5 を公開しました

致命的なエラーがあった orz...

というわけで、EBt for Windows Version 0.0.5-1 snapshot-5 を公開します。

※一度全体を出力するようにすると、次からダイアログが開かなくなる…

てなわけで、こちら↓をお使い下さいませ。

ダウンロード EBtWin-0.0.5-1-snapshot-5.zip (83.5K)

あぁ、Android の開発環境作らないと…

EBt for Windows (EBtWin) Version 0.0.5-1 snapshot-4 を公開しました

急ぎ公開です。EBt for Windows の snapshot-4。

とりあえず前回の snapshot と比べて…

１）階層テキスト（WZとかで使っている形式ね）の出力追加
２）べたテキストの出力追加
３）ファイル出力機能のエラー情報採取プログラムの追加

をしました。機能追加はともかく、どうやら html 出力で謎のエラーが起きるケースがあるみたいなので、それの情報収集機能のリリースがメインだったりします。

ファイル出力中に問題が発生するとダイアログが開くようになっていますので、そこに表示された情報を添えてエラー情報をいただけると、問題解決がしやすくなるのではないかと思います。

で、ここからは業務連絡なのですが。

この snapshot-4 の公開後、Android 版の開発に注力したいと思います。致命的なバグなどを見つけたら直しますが、基本 Android 版の開発にパワーを注ぎますので、当面はあんまり期待しないで下さい。Android 版が一区切りつくまでは、Win版はほぼ開発停止状態だと思って下さい。

なにせ、開発にかけられる時間が週に4～5時間しかないので、両方同時進行はほぼ無理です。

なお、過度の期待は禁物です。まぁ、何とかなると思いますが。Android 版のEBtはサブセットになる見込み。機能をたくさん配置したくても、User I/F の都合上、やりにくいので…。

それはともかく。

バグを見つけた場合は、教えていただければそのうちに対処します（原因が見つかれば…）。見つけたら、コメント下さいませ。

ダウンロードはこちら↓からどうぞ
ダウンロード EBtWin-0.0.5-1-snapshot-4.zip (83.4K)

エラートレースルーチン作成中

EBt for Windows の html 出力のエラーですが…エラー原因が特定できないので、調査コードを仕込みました。

今週末ぐらいに公開しますので、エラーが出る人は、これで実行して、表示されたエラーについて報告してもらえると非常に助かります。

なんか、データが壊れているんじゃないかという気がしないでもないんだけど、壊れたデータがあるとダウンするというのも問題だし。

やっぱり、ちゃんとエラートラップ作るしかないか…今までサボっていたのもいかんかったが。

やっぱり作らんといかんなぁ…

うーん、Xperia で Evernote を使ってみての感想は前にちょっと書いたのですが。

なんか、Android 版の EBt を急いでつくらにゃあならんような気になってきた。うーん、なんか、データ管理の考え方が根本的に違うので、ぜんぜん使う気にならない。まぁ、ちょっとしたメモを持ち歩く時にちょっと便利かも…って感じではあるが、どうなんだろう。

多分、データが多くなった時の問題の解決策の根本が違うんですよね。だから、私はなじめない。頭が EBt 的な志向に固まってしまったからかも知れないけど。

検索という力業というか物量戦に頼る方法も悪くはない。適切なインデックスが作られれば、検索をベースにしたデータ活用が強力なのは google を見れば明らか。Evernote も同じ方向性を持っているように思う。

EBt は、そっちの方向で戦う気が今のところない。もちろん、裏でインデックスをざくざく作っていき、バックグラウンドでリンクをガンガン張っていくということも出来ないわけではない。しかし、基本双方向リンクのEBt でそんな事をやるとリンクのネットワークが崩壊する。EBt は、人力でリンクを張ることで、適度なリンク量に無意識の間に留めている…と思うがいかがだろうか。

ここからは、私の主観ですが。

Evernot の本質はデータをため込むことなんですよ。いろいろな端末からデータをため込む、これが Evernote のメインテーマ。

EBt の本質は、データの整理なんですよ。リンクという手段を使って、いかに知識を EBt に吐き出すか、これが EBt のメインテーマ。

比較しちゃいかんのだよな、これはきっと。そもそも向いている方向が違うから。

なので、EBt for Windows の snapshot を作りかけなのですが、区切りを付けたら早々に Android の開発に移行したいと思います。幸い、今の EBt for Windows は大規模な修正はしていないので、作業に区切りを付けるのは簡単そうです。

移植っていってもなぁ、C# から Java だからまただいぶ変わるんだよなぁ。コアの部分が。もちろん、GUI関連のところは作り直しですよ。これもまぁ、しょうがない。

ま、ぼちぼちとやりますよ。

EBt for Windows (EBtWin) Version 0.0.5-1 snapshot-3 を公開しました

なんというか、snapshot 版は公開前のテストとか準備が少なくて良いですね。

てなわけで、EBt for Windows Version 0.0.5-1 snapshot-3 を公開しました。

今回の修正点
・細かいバグ修正（細かすぎて覚えていない）
・html 出力の修正（別スレッド化等）

ちなみに、html 出力は、今のところEBtのデータ全体を出力することしかできません。本当は、階層指定して出力範囲を制限とかしたいのですが、それ作っているとまたちょっとかかるので、現状での公開です。

html 出力の時、ファイルの中身が変わっていなかったら書き込まない機能を追加しました。これで、Dropbox とか ZumoDrive を使った時に変にバージョンが上がってしまう問題が無くなるはずです。あと、Xperia を USB 接続して直接 html を書き込む時、不要な書き込みをしないのでちょっと速くなります。

ちなみに、android に ZumoDrive インストールして、html データの持ち運びが出来るか試してみたけど、ZumoDrive からブラウザが起動できないし色々制限が大きくて断念。うーん、やっぱり android 版 ZumoDrive は機能が少なくて駄目だね…。

あと、ちょっとスタイルシートをいじったので、少々メニューがでかくなりました。しかし、メニュー押しにくいな。やっぱり、指で指示するインターフェースを考えると、もっと大きくしないと駄目なのか。これ以上大きくするのはきついが。

html 出力は、今のところ android の標準ブラウザのみをターゲットにしています。だから、実は Firefox だとうまく表示できない。そのうちに、Java Script もちょっと書き換えて、せめて IE と Firefox には対応させたいなぁ。次か、更にその次の snapshot で対応できたらいいかなーぐらい。

あと、snapshot のお約束。

・動かなくても怒らない広い心
・バグを見つけたら極力フィードバック

ちなみに、色々実装しないと正式版には出来ないので、しばらくは snapshot の公開が続きます。

ダウンロードは↓からどうぞ。
EBtWin-0.0.5-1-snapshot-3.zip をダウンロードする

html 出力デバッグ＋修正ほぼ完了

EBt の html 出力のデバッグ＋マルチスレッド化などなど。

一応、ほぼ終了しました。「一応」と「ほぼ」ってどれぐらい曖昧な書き方だ？という気がしないでもないが、そこはあえて気にしない。

今日さっさと公開しても良いんだけど、一応1日ぐらいは寝かして明日に公開かな。もしかしたら致命的なバグを見つけるかもしれないし。

ちなみに、フォント設定をちょっといじったら Xperia で表示がほんの少し微妙になった。どうしたもんだろうね、これ…この辺はブラウザのせいなのだが、困ったもんだな…