検索条件
全4件
(1/1ページ)
2008/07/27(日)SDカード速度比較１
2008/07/27 24:45
ということで、SDカードにその原因を探るべく速度測定をしてみた。
めんどくさいので測定は一度のみ。FDBench 1.02使用。
いずれもBuffalo MCR-A30H/U2の直差しで測定。このカードリーダは若干世代は古くなるが、SDHCが読めて転送速度にはそこそこ定評がある。
１つめのkingston のmicro SDが現在使ってる奴で、２つめのはデジカメに刺さってる奴を参考までに引っ張ってきた。
さて結果。
[kingston 1GB / Micro SD(あきばおー)]
kingston_1GB.jpg
[ADATA 4GB class6 / SDHC(パソコンハウス東映)]
adata_4GB.jpg
げっ。ここまで差があるのか。
kingston 1GBの方ではwriteに時間がかかるのは当たり前だなこりゃ。
規格の差や使用時間に差があるとはいえ、選べばもっと速いカードはありそう。ちょっと捜索してみよう。
2008/07/19(土)SpamPalの可能性
2008/07/19 14:57
以前はspamassassinをサーバに入れてスパム対策をかけていたのだが、spamassassinの動きが時折不審であったことと、重いこと、それに加えカスタマイズが結構めんどくさいので自宅サーバではもうやめてしまった。あれからspamassassinもApacheに入ったので今とは状況が違うとは思うがおそらくベースの使い勝手は変わっていないと思う。
今はデスクトップ機の方がリソースに余裕があるし、クライアントマシンに入れた方がカスタマイズしやすい。POPFILEの存在は認識していたのだが、重さと振り分けの動作がいまいち所望と違う。そうこうしてるうちにSpamPalに巡り会った。
SpamPalはURIBLや発信国振り分けに重きを置いたスパムフィルタである。売りとしては初期から使えるBLの豊富さと、スパムフィルタとしては比較的動作が軽快であること。プラグインでベイジアンフィルタも含め機能追加に対応できるところなどだ。
スパムメール対策といえば、
* 発信国判定
* ブラックリスト、ホワイトリスト
* キーワードでの除外、ハム化
* 逆引き一致
* メールアドレス判定
* ベイジアンフィルタ
などが多く使われている。網羅しているわけではないが、スタンダードなところだとこのあたりだろう。
一般的に１つ２つを使うだけでは対策としては不十分で、複数のフィルタを組み合わせたり、あるいは点数付けによってスパム/ハムを振り分ける。
やっかいなことではあるが、実感としては取り扱うメールの量によってどの対策が有効であるかが大きく変わるようだ。
導入コストや動作コストの問題もあるが、受信あるいは通過するメールの量が相当多くないとベイジアンフィルタは今ひとつ効果が薄い。
特に個人ユースでデスクトップに入れる場合には、thunderbirdの例を引くまでもなくベイジアンフィルタの効用を実感できないことが多い。理由は明らかで初見のスパムが多いからである。
またベイジアンフィルタの動作は一般的に重いこともあげておこう。ちなみにspamassassinが重いのはベイジアンフィルタというよりたぶん生Perlが１通ごとに大量の正規表現検索をかけるからである。
spamassassinをいじったときの実感としては、対策方法の中で一番効くのはURIBLなどblacklistだった。細かい正規表現・キーワード判定は確かに精度を上げるが大勢には影響を与えない。逆引きはどうしても癌で、正規のプロバイダメールを落としてしまうことがある。
そういった経験則からSpamPalはどうも使えそうだという見込みがあった。
現在はまだ使いはじめの段階だが、特に英文のメールに対する精度は非常に高くほぼ100%の除去率を誇っている。逆に日本語は今ひとつで、結構な割合ですり抜けてくる。またハムをスパムと判定するいわゆるフォールスポジティブは、特定の個人からのメール２件で起こっているだけとなっている。
様子を見ながら調整してみるつもり。
2008/07/19(土)serene bach -> adiaryへの乗り換え
2008/07/19 14:00
* serene bach
o 記事－記事リンクがめんどくさい
o プレビューできない
o wiki記法(sbtext)の使い辛さ（記法が独自で少な目）
o ソース張りのあたりで若干いじらないと表示がうまくいかない
o ちょっと遅い
o 微妙に更新がめんどくさい
o 一部設計が不可解（インポート時の連番とか）
o 記事編集にいちいち管理ボタンから入る必要がある
* adiary
o 記事－記事リンクが書きやすい
o プレビューはできないが動作が軽快なので何とか
o wiki記法は比較的互換性が高く使いやすい
o ソース張りOK
o 動作軽快
o 多機能
o ログインすれば各記事に編集ボタン表示
o 実行ファイルは１ファイルなので更新容易
さて、まずは人によっていろいろ意見が分かれるのを前提で、自分の意見としてはこうであるということを宣言しておく。
日記・あるいは記事作成システムとして、「機能の有無」だけで判断するなら選択肢はいくらでもある。
自分の欲しい機能はせいぜい、
* 日付やタイトルの位置・表示方式カスタマイズ
* ２階層掘れるカテゴリ
* 記事内リンクのやりやすさ
* リスト表示
* 簡易検索
* あればうれしいアクセス解析
等々で、当然のごとくMTもtDiaryもプラグインで対応可、あるいはハックでどうにかなるようなものばかりだ。
一方で、日記に使うようなシステムでプラグイン方式を徹底化されるとどうも煩わしさが先に立つ。
複雑化しやすく、人によって求める機能が違うようなシステム－－
そういうシステムでは本体機能を最小限に抑え、プラグインで機能の追加を実現するようにした方がスマートだ。それは間違いない。
しかし、事件は突如「プラグイン同士の相互関係」という現場で起こる。
さすがに衝突は回避されることがほとんどだ。しかし、あるプラグインがデザインを変更し、あるプラグインが遷移状態を追加したとする。そうすると追加された遷移先でデザインが崩れる、といったことが起きる。。
それに加えて、各プラグインのバージョンアップ、当然本体のバージョンアップもあるから事態は混迷の一途をたどる。オプションの追加、パラメータのオプション化あたりで匙を投げたくなってくる。
ここら辺はコミュニティの人数にも関わってくるし、自分の使い方が大勢と異なっていればいるほど煩わしさが増すという苦難も伴う。あーめんどくさい。
自分で作る？ もちろんそれもよい。あなたに相応の時間とセキュリティの知識があるのならば。
そんなわけで本体機能のみでリッチなシステムを求めたくなる。KShikiもserene bachもそういう発想で導入したCGIだった。そして今回adiaryに乗り換えた。
もちろん乗り換えたんだから過去の両システムともに不満はあった。ただそもそも不満が発生するのは当然「本体機能のみでリッチなシステム」を求めた自分が悪いわけでこれらが悪いものであるといっているわけではない。
当然後発組の方が出来がよいという実態もある。
adiaryのよい点はまさに単独でリッチ。本体のみでhatenaもどき＋wikiもどきを実装できていること。おおまか自分の求める機能を備えていること。さらに動作の軽さも特筆すべき点としてあげてよいと思う。
2008/07/05(土)Memo移行しました
2008/07/05 15:42
新アドレスは、
http://www.dt8.jp/cgi-bin/adiary/
(ここ)になります。
なお、当面旧版は残しておきます。
mod_rewriteしてリダイレクトっぽくしようと思ったら、sb側の記事番が日付順になってなかったので諦めました。本当は301 Moved Permanentlyとかも処置すべきなんでしょうが、そうアクセスがあるページでもないし、記事番リダイレクトもできないようではということで特にやってません。
入れ替えの理由は次の記事にでも書きます。
あー、それにしても書きやすくなりましたね。