« 2010年5月 | トップページ | 2010年7月 »

2010/06/27

しょぼいバグを見つけた

EBt for Windows にしょぼいバグを見つけてしまった。

…すぐに治ったけど、なかなかみっともない。

まぁ、Visual Studio 2010 に開発環境を移行したことだし、今の時点で正式リリースしても良いかな。

もちょっと考えますけど。

| | コメント (0) | トラックバック (0)

2010/06/17

ちなみに、Android版EBtの移植状況

何せ作業時間がとれないのであんまり進んでおりません。

既にクラス数は10をらくらく突破。うち、コーディングがすんでいるのは3~5ぐらい。Windows に依存したコードがいっぱいあるので、これをどうしたものか悩みつつ、移植はぼちぼち進行中。

現在移植しているEBtのコア部分の実装さえ出来れば、移植の先が見えてくるんだけど。

ていうか、結局コア部分フル移植している自分に反省中。使う可能性の低い先読みキャッシュとか、実装止めた方が良かったかな…Android はメモリ負荷とか下げないといけないから、先読みは移植しても使わない可能性の方が高いし。

ぼちぼち行くか。

| | コメント (0) | トラックバック (0)

2010/06/03

今日のEBt。テーマ「データは小さく」

思いつきで書いている今日のEBt。今日はデータサイズのお話。

EBt は、使うと何となく気がつくと思いますが、1メモあたりのデータサイズは小さいという事が、なんとなく前提としてあります。もちろん、長いメモを保存しても良いのですが、EBt が本領を発揮するのは、小さいメモをリンクしていくような使い方です。

なので、データの整理とかの方法も自ずと変わってきます。大きいメモの場合は、相対的にファイル数が少なくなるので、データの整理とかは割と簡単です。まぁ、メモ内の構成とかは気にしないといけませんけど。

小さいメモの場合、逆にファイル数が大きくなる傾向があります。そのため、たくさんあるメモをいかにして管理するかが重要になります。

実は、EBt を作り始めたとき、リンクという管理方法が、データ数が増えたときに対応しうるのか、少々疑問でした。自信がなかったと言えばいいのかもしれません。もちろん、個人的には「これ!」と思ってはいましたが、実証していたわけではありませんので。でも、今は大丈夫だと思っています。私のEBtは、既にメモ数が8000を越えているし、まだ破綻していない。ということは、多分大丈夫なんでしょう。

小さいメモにする事の利点は何か?というと、データがシンプルになるという事に尽きるかなと思います。シンプルはEBtのキーワードですね。とにかくシンプル。メモもシンプルにします。

シンプルなメモはどういうもの?個人的な基準は、1メモに複数の事を書かない。別の項目は別のメモに書く。それがシンプルなメモの簡単な考え方だと思います。ウィキペディア見ると、一つのページに複数の項目が書かれていますよね。こういう書き方は EBt ではあんまりおすすめしません。EBt 風だと、ウィキペディアの細かい項目ごとに別のメモになります。階層は当然複数の階層になるイメージ。こうやって考えると、データの管理方法がかなり異なりますね。

ちなみに、1メモあたりの情報量が少なくなるので、個々の見通しは良くなります。ただ、全体を見渡すのはちょっとやりにくくなります。どっちが良いのかはよくわかりませんね。

なんにせよ、データは小さく、これはEBtを使う上でのポイントになります。小さくすれば、自ずとメモに複数の事を書かなくなりますしね。

EBt 使うときに、ちょっとこのことを気にすると良いかもしれません。

| | コメント (5) | トラックバック (0)

2010/06/02

ちょっと調べて思ったこと

あぁ、この値段設定だと、Windows Azure 使って EBt サーバー作った方が安上がりだね。

どうしようかなぁ。Visual Studio 2010 買うと、ちょっとだけ無料で Windows Azure が使えるしなぁ。

ここで EBt Server 動かして、一人あたり 500円/年とか徴収して運営費に充てた方がハッピーになれるのかも知れない。

てな独り言をつぶやくのでした。

| | コメント (0) | トラックバック (0)

« 2010年5月 | トップページ | 2010年7月 »