しょぼいバグを見つけた
EBt for Windows にしょぼいバグを見つけてしまった。
…すぐに治ったけど、なかなかみっともない。
まぁ、Visual Studio 2010 に開発環境を移行したことだし、今の時点で正式リリースしても良いかな。
もちょっと考えますけど。
| 固定リンク
| コメント (0)
| トラックバック (0)
EBt for Windows にしょぼいバグを見つけてしまった。
…すぐに治ったけど、なかなかみっともない。
まぁ、Visual Studio 2010 に開発環境を移行したことだし、今の時点で正式リリースしても良いかな。
もちょっと考えますけど。
| 固定リンク
| コメント (0)
| トラックバック (0)
何せ作業時間がとれないのであんまり進んでおりません。
既にクラス数は10をらくらく突破。うち、コーディングがすんでいるのは3~5ぐらい。Windows に依存したコードがいっぱいあるので、これをどうしたものか悩みつつ、移植はぼちぼち進行中。
現在移植しているEBtのコア部分の実装さえ出来れば、移植の先が見えてくるんだけど。
ていうか、結局コア部分フル移植している自分に反省中。使う可能性の低い先読みキャッシュとか、実装止めた方が良かったかな…Android はメモリ負荷とか下げないといけないから、先読みは移植しても使わない可能性の方が高いし。
ぼちぼち行くか。
| 固定リンク
| コメント (0)
| トラックバック (0)
思いつきで書いている今日のEBt。今日はデータサイズのお話。
EBt は、使うと何となく気がつくと思いますが、1メモあたりのデータサイズは小さいという事が、なんとなく前提としてあります。もちろん、長いメモを保存しても良いのですが、EBt が本領を発揮するのは、小さいメモをリンクしていくような使い方です。
なので、データの整理とかの方法も自ずと変わってきます。大きいメモの場合は、相対的にファイル数が少なくなるので、データの整理とかは割と簡単です。まぁ、メモ内の構成とかは気にしないといけませんけど。
小さいメモの場合、逆にファイル数が大きくなる傾向があります。そのため、たくさんあるメモをいかにして管理するかが重要になります。
実は、EBt を作り始めたとき、リンクという管理方法が、データ数が増えたときに対応しうるのか、少々疑問でした。自信がなかったと言えばいいのかもしれません。もちろん、個人的には「これ!」と思ってはいましたが、実証していたわけではありませんので。でも、今は大丈夫だと思っています。私のEBtは、既にメモ数が8000を越えているし、まだ破綻していない。ということは、多分大丈夫なんでしょう。
小さいメモにする事の利点は何か?というと、データがシンプルになるという事に尽きるかなと思います。シンプルはEBtのキーワードですね。とにかくシンプル。メモもシンプルにします。
シンプルなメモはどういうもの?個人的な基準は、1メモに複数の事を書かない。別の項目は別のメモに書く。それがシンプルなメモの簡単な考え方だと思います。ウィキペディア見ると、一つのページに複数の項目が書かれていますよね。こういう書き方は EBt ではあんまりおすすめしません。EBt 風だと、ウィキペディアの細かい項目ごとに別のメモになります。階層は当然複数の階層になるイメージ。こうやって考えると、データの管理方法がかなり異なりますね。
ちなみに、1メモあたりの情報量が少なくなるので、個々の見通しは良くなります。ただ、全体を見渡すのはちょっとやりにくくなります。どっちが良いのかはよくわかりませんね。
なんにせよ、データは小さく、これはEBtを使う上でのポイントになります。小さくすれば、自ずとメモに複数の事を書かなくなりますしね。
EBt 使うときに、ちょっとこのことを気にすると良いかもしれません。
| 固定リンク
| コメント (5)
| トラックバック (0)
あぁ、この値段設定だと、Windows Azure 使って EBt サーバー作った方が安上がりだね。
どうしようかなぁ。Visual Studio 2010 買うと、ちょっとだけ無料で Windows Azure が使えるしなぁ。
ここで EBt Server 動かして、一人あたり 500円/年とか徴収して運営費に充てた方がハッピーになれるのかも知れない。
てな独り言をつぶやくのでした。
| 固定リンク
| コメント (0)
| トラックバック (0)
最近のコメント