cles::blog

千葉先生の新刊ということでちょっと買ってみました。なんというか、AOPについて基本的な部分は理解している（と思っている）ので、楽しく読めました。

ぱっと見で、ほとんどが対話形式とソースコード^*1なので、少なくともJavaのプログラムがそれなりにできる人のためのの入門書といった感じなんでしょうか。手順どおりに手取り足取り教えてほしいという人には向かないと思います。

• ^*1: ソースコードは断片の場合もあってそのままでは実行できなかったりする

最近、週末になると頭が痛かったりしていて、「疲れがたまっているのかなぁ」なんて思っているわけですが、その不摂生のカバーに少しでもなればとL-カルニチンとアルファリポ酸のサプリを飲み始めてみることにしました。

アイエフメディカルのビューティーデザインというやつです。サイトを見てみるとSHIHOとか、押切もえも使っているサプリという触れ込みのようです。

ちなみに僕が美しくなってもしょうがないというツッコミは勘弁してください。ヒアルロン酸も入っているようなので、僕のドライアイにもちょっとは効かないかなぁ。

カウンタがいつの間にか800000を突破していました。
ありがとうございます。

† 次の目標は１００万？

60万は９月のはじめだったので、約３ヶ月で20万ヒットあったことになります。このままのペースで推移するならば、ちょうど２周年のあたりで１００万ヒットが達成できそうですね。

「生真面目で阿呆ネタスキー。食寝遊のうち食に特化してる。」とみしろさんにいわれてしまった人間性バトンに挑戦。

悔しいが当たってるよソレ。

とりあえずNP_CommnetContorol + NP_Blacklistの環境を、NP_SpamCheck + NP_Moderate + NP_MultiRBLに載せ変えてみることにしました。

† 結局、とりやめ

結論を先に書いておきますが、僕は現在のところ移行は取りやめることにしました。機能的にもまだNP_CommentControl + NP_BlacklistのほうがNP_SpamCheck+その他よりも優れているみたいなので。

以下が導入の手順と感じたことです。

リファラーに本家のフォーラムからのURLがあったので、覗いてみたら「Blacklist plugin - developments」というトピックで僕が勝手に改造したNP_Blacklistが話題になっていました。

ちょっと英語ダメなので発言できないでいるのですが、このスレッドで本家のフォーラムサイドではSPAM対策についてどんな考えでやっているのか大体わかりました。

† 結論自体も悪くはないのかな・・・でも・・・

機能的なアプローチとしては間違っていないと思うんですよね。ただユーザビリティ的にはちょっといただけないんですよね。ただでも面倒くさいspam対策のために細々たくさんプラグインを入れないといけないことになるので。

プラグイン作者としてはNP_Trackbackとか、NP_Moblogもそれにあわせて書き換えないといけないし。。。。。

先週から仕事はすっかりテストになっているわけなんですが、なかなかでかいバグが見つかりません。作った人が優秀なのはわかっているのですが、細かい挙動までよく考慮されていてこちらになかなか付け入る隙を与えてくれません。何か見透かされているようでちょっと悔しいのです。

† バグが見つからない怖さ

「プログラムにはバグがない」ということを真実であるととらえるのであれば、バグが見つからないということ当たり前ということになり、それは一見喜ばしいことかもしれません。

みんな作っているようなので僕も便乗。
Google Help : Add to Google buttonから作ることができます。

ATOMとかRSSってロボットが定期的に巡回してくるからなんでしょうけど、意外とアクセスが多い^*1んですよね。下手するとトップページなんかよりもずっとアクセスがあります。

• ^*1: 「feedが収集されること」=「人が見ること」ではないのでPVとは言えませんが。

今日は土曜日なので夕方から大学のミーティングに参加してきました。
woさんはすっかりインデアンカレーマスターになっているわ、sさんはカンボジアから帰ってきて白髪になっているわで賑わっていました。

† 以下、自分用のメモ

論文が進んでいないので肩身の狭い思いをしているわけですが・・・・・とりあえず現在取り掛かっているテーマについては、得られたデータをどのように考察するべきかの目処も立って来たのでぼちぼち執筆に取り掛かっていこうと思います。

久しぶりに人の作ったシステムのテストをするという仕事をしています。テストを実行すること自体は単純作業なのですが、その作業項目を決めるテスト設計は何度やっても難しい作業だということを毎回実感させられます。だから、仕事でテストは結構好きなんですよね^*1。

今回の仕事では機能単体レベルのテストに加えて、プロダクトがユースケースに要求に準拠しているかどうかについても確認してほしい依頼されています。つまり、verification^*2だけでなく、validation^*3もやってほしいという高度な要求を突きつけられているわけです。

これまでもテストはいろいろやってきましたが、今回はそういうわけで一筋縄ではいかないのです。プロダクトが最終的にサービスのどのような位置を占めるのかとか、この機能はどのような形態になっていればビジネス的に価値があるのかというようなビジネス的なことも常に頭に置きながら進めないといけません。おそらく自分がプログラム開発する時以上に神経を使っていると思います。

• ^*1: 本当にテストの実施だけに借り出されるのは嫌い。クリエイティビティのない単純仕事は苦手なのです
• ^*2: ベリフィケーション。「検証」と訳される
• ^*3: バリデーション。「妥当性確認」と訳される