nDiki : 仕様

製品レポート WiKicker Perl 開発 文法 HTML XML メール プロジェクト立ち上げフェーズ UTF-8 開発プロセスメモ 研究 コミュニケーション ThinkPad X31 Wiki ミッション Java ソフトウェア プロジェクト憲章 見積もり HTTP Web 日本語 API LaTeX ミーティング Naney 在庫 Javadoc Pod

■ でかカール チーズ味 おまけつき - 誕生日プレゼント

ぐらさんに合わせて松下君より、1日はやめの誕生日プレゼントを頂いた。 感謝。

こちらはビッグ。 金ピカ百式仕様の、でかカールだ。

カールはウチではハグソ菓子と呼んでいるカテゴリの菓子だ*1。

次の日に開封して食べてみたんだけれど、これがデカい。 1個で口いっぱいだ。 食べがいがあって、普通のカールより美味いぞ。

カールおじさんランチクロスのおまけ付き。 「どうやら愛妻弁当をこれで包んでくるよね? 絶対」ということらしい。

• 今日のさえずり - 除虫菊を栽培していただきます (2008-08-05)
• 銀座 甘楽のいちご大福は絶品 (2007-03-31)
• クリスマスプレゼントに「はらぺこあおむし」のペンスタンドをいただいた (2006-12-25)
• 今度は動くぞ。はらぺこあおむし - 誕生日プレゼント (2007-05-07)
• tkh夫妻を囲む会 (2004-01-11)

■ WiKicker における PageName 最長文字数

WiKicker では PageName を エンコードした文字列を URI に埋め込んだり、サーバで保存する際のファイル名にしたりしている。 このため、PageName の最長文字数はそれらの最長文字数に依存しているはずである。

今まで確認を後回しにしていたのだが、新しい機能の追加の際に確認しておく必要があるので調査してみた。

@ WiKicker の実装

WiKicker の実装がらみとして最長を決める要素としては

• PageName の UTF-8 表現を URI エスケープしてページ URI に含めている。→ URI、HTTP、HTML、Web サーバ、Web ブラウザの実装による最長の制約
• PageName を base64 にエンコードしてファイル名にしている。→ ファイルシステムのファイル名、パス名の最長の制約

がある。

@ 各仕様等による制約

• HTTP では URI の長さには制限なし (RFC2616 3.2.1)
• Web サーバは Request-URI が長いと 414 Request-URI Too Long を返す (RFC2616 10.4.15)。Apache は LimitRequestLine ディレクティブにより、URI を含むリクエスト行のサイズを制限することができる(配布時には 8190)。
• Internet Explorer が扱える URL の長さは 2083文字。
• ext2 はファイル名は 255文字まで(増やすこともできる)。
• 手元の Linux 2.6.15 で試したところ、パス名は 4095文字まで。

@ WiKicker で問題が出ない PageName 最長文字数

上記の中ではファイル名による制約が一番大きい。

WiKicker 内部でファイル名として base64 (の亜種) でエンコードしたものを使っているので、元の文字列はは最長 189バイトまでなければならない。base64 だと3バイトで4文字になるため、189バイトで 252文字となる。

WiKicker ではここでさらにファイル名に ',v'、'-lock' をつける事があるので、実際には元の文字列は最長 186 バイトまでとなる。

PageName が 186 バイトまでだとすると、URL エスケープしたとして558バイト。 WikiEngine のスクリプトの URL や他のパラメータとあわせても、これぐらいなら大丈夫のはずである。

ということで WiKicker では Linux 上だと通常 PageName は 186 バイトが最長と言ってよさそうだ。 日本語の文字はだいたい UTF-8 で3バイトになるので、62 文字までということになる。

そのうち、WiKicker に制約チェックを入れることにしよう。 そのうち。

• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• 最後がピリオド(.)で終わるファイル名をつけられない (2005-04-19)
• WiKicker 実装 (2002-10-20)
• WiKicker 0.35 リリース - 添付機能の修正など (2006-06-20)
• ケータイ用にプライベート Wiki を設置 (2008-01-07)

■ 上向き筆記可能なヘビデューティ仕様のボールペン XPA

ここ最近熱心に進めていた身の回りのボールペンのハイテックC化であるが、

と各利用シーンで使える環境が揃い一段落である。

@ 上向き筆記

そんな中自分の中で必要と感じはじめたのが、横向き・上向き筆記用のボールペン。 通常のボールペンは上向きにするとインクが出なくなり、また空気が入ることで逆流の原因ともなるためよろしくない。

しかし電車で立ってメモを取る時や、布団に入っている時にメモを取りたくなった時など、横向き・上向きで書きたいシーンがあるのである。

@ 加圧式ボールペン

上向きで書けるボールペンとしては加圧式のフィッシャーのスペースペンが有名だ。

また国内では三菱鉛筆が同様に加圧式であるユニ パワータンクシリーズを出している。 ちなみに商品説明で

上向きにも書ける! 加圧ボールペンのメリットは、何と言っても筆記方向の自由さ。寝転がっても逆立ちしても、インクの逆流が無く常に快適な筆記性能を持続します。

とあるが、逆立ちして書く時はペンは下を向くと思う。

そんな中で注目なのがトンボ鉛筆の XPA 用の加圧リフィル BR-VMP。 4C 互換リフィルなので様々なボールペンで利用することができる。

エスプリムーブやペンポッドをこれにしてみたい。

でいろいろ見ているうちに XPA 自身も欲しくなってしまった。

ということで銀座の伊東屋に行って XPA と BR-VMP を購入。

@ XPA

評価の高いトンボ デザインコレクション (TOMBOW Design Collections) の一つであるヘビーデューティ仕様の伸縮モデル。 先に書いた通りガス加圧タイプで、水に濡れた紙面や上向きでの筆記も可能なのが特徴である。リフィル自体は 4C 互換なので、普通の油性ボールペンやハイテックCスリムス用のリフィルを使うこともできる。

軸の尾端を押し込むと同時にペン先が収納される形になっておりコンパクト。 軸の出し入れ時の「プシュッ」っという空気の流れる感じがたまらない。

クリップはないので手帳やメモ帳カバーにつけておくには向かない。 やはり「ぶら下げる」のが似合うスタイルだ。

ジーンズの時には腰にペンポッドを下げているので、今使うとしたらスーツの時かなぁ。

@ BR-VMP

加圧式のリフィルの方は1本315円。 中字の黒である。

XPA が最初書けなくてちょっと意気消沈。 手に持った RHODIA 上ではなくて、テーブルの上に置いた1枚切りとった紙の上で書いたらインクが出始めて一安心。

替え芯として買った BR-VMP はボール周辺からインクが染み出し固まっているし(お店にあった在庫はどれもそんあ感じだった)、ちょっと一癖あるかもしれない。

@ スペースペン

妻に「普通のボールペンが上向き筆記に向かない」こととスペースペンの話をしたら「(宇宙では)鉛筆使えばいいんじゃない?」と言われた。

一方ロシアは鉛筆を使った。

というジョーク/都市伝説は聞いたことがなかったって。

@ XPA 仕様

[ 製品レポート ]

• ハイテックC のリフィルは買いだめすべし (2006-10-07)
• RHODIA No.11 にぴったりなロットリングのボールペン (2006-04-20)
• ロットリングのミニボールペンをハイテックC化 (2006-06-03)
• 常に持ち歩くアイテム用に PORTER SMOKEY バッグ - 誕生日プ... (2007-04-27)
• 伊東屋でSTAEDTLERの黒ボールペンリフィルを買ったり (2005-03-20)

■ WiKicker でドメイン名なしの URL でセッションがはれなかった理由

 http://example/wiki

のように、ホスト部がドメイン名を含まないホスト名のみの URL でアクセスした場合、WiKicker では cookie ベースのセッション管理がうまく動かなかった。

cookie の仕様では、cookie の domain 属性で指定できる文字列はピリオドをいくつか含まなければならないことになっている。

しかし、ホスト名だけでアクセスしたサーバへは Web ブラウザは cookie を送らないというのは誤解。 domain 属性が省略されている cookie の場合は (アクセスするサーバの名前に含まれているピリオドの数が条件を満たしていなくても)ちゃんと cookie を発行したサーバへリクエストと一緒に送ってくれる。

WiKicker で何で駄目か確認したら、configuration オブジェクトの「cookie の domain 属性を決めるメソッド」で、「cookie.domain というプロパティ設定があればそれを」、「無ければ HTTP_HOST 環境変数の値を」 domain 属性で使う値として返すようになっていたから(って書いたのは昔の自分)。

次回のリリースで修正。

• WiKicker における PageName 最長文字数 (2006-06-10)
• [ WiKicker ] キャッシュまわりにバグ (2004-06-05)
• ケータイ用にプライベート Wiki を設置 (2008-01-07)
• FoxyProxy と autossh で社内 Web ページを閲覧 (2006-06-03)
• ノート PC で Apache Virtual Host (2004-12-15)

■ ほんわりあたたか充電式カイロ eneloop kairo

製品発表以来、気になっていたサンヨーの充電式カイロ eneloop kairo K1R-S1 が12月1日に発売になった。 発売日の朝、ヨドバシカメラにいってみたけれどまだ入荷していないとのことだったので、2つ注文。 4日の夜に入荷したとの連絡がはいり、昨日購入してきた。

@ デザイン

思ったよりも薄型で驚き。光沢感のある白い卵型はなかなかいいデザインである。 カイロの状態を表示するための光る表示部があり、電源を入れるとゆっくり点滅する。

@ 充電

買ってきてまずは充電。充電中は発光表示部が緑色に点灯する。 充電が進むと緑色の発光が強弱するのだが、それについては説明書に書かれていないので最初とまどった。充電が完了すると消灯する。

エネループの名がついているのでニッケル水素電池を使っているのだと思っていたが、実際にはリチウムイオン電池 (3.7V 1800mAh) であった。 同じ eneloop でもこの商品は eneloop universe ブランドの方らしい。

ニッケル水素電池なら、もしかしたらバッテリがへたっても交換できるのかと思っていたが、リチウムイオン電池だと難しいかもしれない。

@ あたたかさはソコソコ

早速、今日往復の通勤の際に持ち歩いてみた。

仕様では温度スイッチ「強」で平均43℃とある。 付属の専用ケースにいれた状態で、フリースジャケットのポケットに放り込んでみたが、これだと体があたたまるとまではいかない。 シャツのポケットなどもう少し肌に近いところに入れれば「おっ温かい」感じられる。

発熱するのは裏側の温熱部のみ。 このため手をポケットにつっこんで表側を握っても温かくないという点では、使い捨てカイロに負けるところだ。

プラチナの触媒反応を利用しているハクキンカイロの強力な発熱を知ってしまうと、かなりヌルい印象ではある。

しかしながら「スイッチでON/OFF ができる」「臭いもでない」「繰り返し使える」「燃料不用」など利便性は非常に良い。 朝は電源を入れてポケットにいれ、家に帰ったらオフにして AC アダプタを挿しておくだけというのはやっぱり手軽。

日常のタウンユースでは結構便利に使えそうだ。 普段は eneloop kairo、寒空のもと外出する時間が多い時は Zippo ハンディウォーマーと使い分けるのがよさそうだ。

• Zippo ハンディウォーマー

[ 製品レポート ]

• 今ごろカイロのバーナー発見 (2006-04-15)
• Zippo ハンディウォーマーデビュー (2004-12-29)
• ホームネットワークカメラ BL-C10 買っちゃった (2005-01-18)
• Zippo ハンディウォーマー (HANDY WARMER) ZHW2F (2004-07-15)
• 外出先でも FOMA 端末を充電できるバッテリ - FOMA 補助充電アダ... (2007-09-13)

■ ThinkPad X31 + Debian で Google Earth が見られるようになった

今年の8月に ATI fglrx ドライバを試してみたのだが、その際はうまく放っておいた X.Org X server の DRI / GLcore 対応をしてみた。

最初は fglrx をいじっていたけれど、fglrx Kernel モジュールをロードするとサスペンドできなくなってしまって NG。 いろいろ調べたところ、普通に radeon ドライバでもいけそうだということでその線で設定してみた。

環境:

• Debian GNU/Linux sid
• ThinkPad X31 2672-PHJ
• xserver-xorg 7.1.0-7

lspci:

 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY

HOWTO: 3D Acceleration in ATI Mobility Radeon M6 LY (and possibly others) を参考に、最終的に以下の /etc/X11/xorg.conf でいけた:

 Section "Module"
         Load    "bitmap"
         Load    "dbe"
         Load    "ddc"
         Load    "dri"
         Load    "extmod"
         Load    "freetype"
         Load    "glx"
         Load    "int10"
         Load    "record"
         Load    "type1"
         Load    "v4l"
         Load    "vbe"

         Load    "GLcore"
 EndSection

 Section "Device"
         Identifier      "ATI Technologies Inc Radeon Mobility M6 LY"
         Driver          "radeon"
 #       Driver          "ati"
         BusID           "PCI:1:0:0"

         Option          "BusType" "PCI"
         Option          "AGPMode" "4"
         Option          "AGPSize" "32" # default: 8
         Option          "AGPFastWrite" "false" # More stable this way.
         Option          "SWcursor" "true" # More stable this way.
         Option          "EnablePageFlip" "true" # Faster.
         Option          "EnableDepthMoves" "false" # More stable this way.
         Option          "RenderAccel" "false" # More stable this way
         Option          "AccelMethod" "XAA" # or XAA, EXA, XAA more stable
         Option          "DDCMode"
         Option          "SubPixelOrder" "NONE"
         Option          "ColorTiling" "false" # More stable this way.
         Option          "DynamicClocks" "true"
         Option          "bioshotkeys"   "True"
         Option          "XAANoOffscreenPixmaps" "true" # More stable this way.
         VideoRam 16384
 EndSection

 Section "DRI"
         Mode    0666
 EndSection

glxinfo で

 direct rendering: Yes

となっていることを確認。

設定途中 GLcore をロードするように設定すると、glxinfo の実行で必ずフリーズしてしまい困っていたのだが、これについては VideoRam 16384 を設定することで動くようになった。

ThinkPad X31 2672-PHJ の仕様を見るとビデオメモリについて「16MB ※ ビデオRAMとして使用されるメイン・メモリーの容量は、BIOS等で設定変更することはできません。」とあるので、この辺りが関係しているのかもしれない。

これで以前試した時は表示がおかしかった Google Earth が (動作的にはまだ重いけれど)動くようになった。

glxgears -printfps は

 1311 frames in 5.0 seconds = 262.094 FPS
 1303 frames in 5.0 seconds = 260.458 FPS
 1289 frames in 5.0 seconds = 257.793 FPS
 1315 frames in 5.0 seconds = 263.000 FPS
 1317 frames in 5.0 seconds = 263.344 FPS

といったところ。 xorg.conf の設定が Web サイトを参考に安全側にふってあるので、いじればもう少し速くなるかもしれない。

• X.Org X server 6.9.0 の ATI ドライバは駄目? (2006-01-11)
• ThinkPad X31 と Linux kernel 2.6 (2006-02-22)
• Debian Linux kernel 2.6.23 をビルドする。 (2007-12-23)
• [ Debian ] resume 時に /etc/apm/event.d... (2003-12-10)
• Debian に RSS リーダ「フレッシュリーダー」をインストール (2006-03-06)

■ SUNNTO の腕時計のベルト交換にヨドバシカメラ大苦戦

昨日購入した Sunnto Observer TT 用のストラップとバッテリーキットでそれぞれ腕時計のパーツを交換してもらうおうと、9:30 のオープンと同時にヨドバシカメラ マルチメディアAkiba に入店。 昨日と同じ時計コーナーで、交換を依頼した。

@ 1回目

店員がさらりと受付してくれて、その場でベルトの交換を始めてくれた。 ……のはいいのだが、どうも苦戦している様子。 まずもって今ついているベルトを15分経っても外せないでいる。

今日は 10:00 からミーティングが控えていて遅れるわけにもいかない。 店員が「あと5分ぐらいでできると思いますが……」と言っていたが、絶対終わりそうにないので預けて昼休みにまた来ることにした。

スントオブザーバー TT、他のメーカーのチタン製時計と比べて、傷つきやすいチタンなのであの手つき非常に心配。

@ 2回目

でお昼休みに再度ヨドバシカメラへ。 ベルトの交換は完了済み。長さの調整がまだだったので、対応してくれた店員に前のと同じ長さにカットしてもらうように依頼。

ほどなくしてでき上がってきたのだが、どうもバックルがおかしい。 オブザーバーは腕に巻いた後に、バックルの大小2つの金具を止めるというタイプなのだが、先に止める小さい金具の方が異様に固く、逆に後に止める大きい金具の方は全然カチッと止まらずロックできない。 明らかに普通ではない。

店員にその旨を伝えるものの店員も困った様子。 前に使っていたバックルと見比べながら首をかしげている。 私が見た感じではロック金具が最初から開いてしまっているように見える。

他の店員に聞いてきて「ベルトのウレタンの場所にあたる関係ではまりずらくなっている」と説明してくれたが、同じ長さで今まで使ってきた私が変だと感じているのにそんな話では困る。

片側は固くて外せず、一方は全く留まらないでは使いものにならない。 作業中に歪ませたか元々不良品だったのかのどちらかだが、時計もストラップも安くもないのできちんとして欲しい。

「ストラップの在庫がもうないようなので、お取り寄せになってしまいますが」と言うので「明日使う予定だったんですが」一言(実際にそのつもりだった)。 そうしたら「確認してみます」といってまたひっこんでしばらく待たされた。

「時計についているものと(バックルを)交換してみました。これでどうですか?」と戻ってきた。 別の商品から外して交換してくれたらしい。 腕につけてみると、こちらは普通に留めることができた。 よく見ると今まで使っていたものとはピンの形状等が異なっており、微妙に仕様変更があるようだ。 このため若干の感蝕の違いはあるけれど、これなら普通に使える品質だ。

ということで一件落着。

で交換してもらった前の部品を受け取って帰ろうと思ったら、電池蓋が欠品している。 捨てちゃったのかなとも思いつつ、ここはきちんとして欲しいので探してもらった。 すると交換した店員が不在とのことで、すぐにみつからないという。 ここまでで既に30分以上経っており、もう昼休みが終わるので(昼食抜きは確定)見つかったら電話をもらうように頼んで退店。

@ 3回目

夕方に電話がかかってきて「きちんとありました」とのこと(そうでなければ困る)。 夜帰りに寄っていくと伝えたところ、昼に担当してくれたその人はいないかもしれないが、きちんと申し送りしておくとのこと。

で会社帰りに寄ったところ、別の店員がしばらく探した後に「これですね」とそっけなく突き出してきておしまい。

何度も来店させたことを詫びる訳でもなく、手提げ袋に入れますかの一言もなく。 これがきちんとした申し送りなのか。

交換等については誠意はあったものの、技術力と連絡体制の酷さを感じてがっかりとした1日であった。

時計コーナー要注意。

• SUUNTO のバッテリーキット購入(ついでにストラップも) (2007-03-28)
• Suunto Observer TT (2004-12-23)
• 腕時計のベルトが錆びていて大ショック (2006-03-21)
• パワリレー交換で帰ってきた ONKYO のコンポ (2006-10-01)
• 今日のさえずり - 電話番号が「ニイサン イロジロ」の食事処 (2008-07-03)

■ 今日のさえずり - え? ラミヤータ閉店なの?

• 11:36 え? ラミヤータ閉店なの?
• 12:12 セブン-イレブンの豚焼肉弁当、肉がパスタで底上げされているのに気がつかないで買ってきた。 *Tw*
• 13:49 Firefox 2.0.0.8 にしたので keyconfig 入れなおした。 *Tw*
• 16:04 XML-RPC で struct->member->name 値を可変値とする(連想配列的に使う)仕様だと、言語によっては面倒だということに今頃気がつく。 *Tw*
• 18:11 「るるぶ品川区」まずは立ち読みしてみたい。 *Tw*

• 今日のさえずり - 除虫菊を栽培していただきます (2008-08-05)
• 今日のさえずり - 紳士服屋の完全閉店は信用ならない (2008-06-14)
• DVD ミカンせいじんチルドレン (2006-01-19)
• 今日のさえずり - 本心はベランダへの上げ下げが面倒だから (2008-09-07)
• でかカール チーズ味 おまけつき - 誕生日プレゼント (2006-04-26)

■ Twitter ベイジアンフィルタプロキシ

Twitter で following が増えてくるにつれて、タイムラインに目を通すのが大変になってきた(という程きちんと見ている訳ではないが)。 さっとタイムラインをなめて面白そうな情報をピックアップしたい時は、「おはよう」とか「風呂入った」とか「トイレ」とかは除外して読みたい(そういう書き込み自体は嫌いじゃないのだが、人生はあまりにも短い)。

Twit や P3:PeraPeraPrv では NG ワード指定ができて、それらを含むステータスは表示しないようにできるのだが、Twitter の書き込みは揺らぎが激しすぎて指定しきれないという弱点がる。

ということでベイジアンフィルタでフィルタリングしてみることにした。

自前で Twitter クライアントを作る気はないので、proxy の形でさっと実装してみた。

 #!/usr/bin/perl

 use strict;
 use warnings;

 use HTTP::Proxy;
 use HTTP::Proxy::BodyFilter::complete;

 my $proxy = HTTP::Proxy->new(port => 8088);
 $proxy->push_filter(response => HTTP::Proxy::BodyFilter::complete->new,
                     mime     => 'application/xml');
 $proxy->push_filter(response => Bsfilter->new,
                     mime     => 'application/xml');
 $proxy->start;

 {

   package Bsfilter;

   use File::Temp qw/tempfile/;
   use XML::XPath;
   use base qw(HTTP::Proxy::BodyFilter);

   sub filter {
     my ($self, $dataref, $message, $protocol, $buffer) = @_;
     return unless defined($$dataref) && $$dataref ne '';
     eval {
       my $xml = XML::XPath->new(xml => $$dataref);
       my @nodes = $xml->findnodes('/statuses/status/text/text()');
       return unless @nodes;
       for my $node (@nodes) {
         my $text = $node->getNodeValue;
         if (is_NG($text)) {
           $node->setNodeValue("[NG] $text");
         }
       }
       $$dataref = qq(<?xml version="1.0" encoding="UTF-8"?>\n);
       $$dataref .= $xml->get_context->toString;
       utf8::encode($$dataref);
     };
     if ($@) {
       warn $@;
     }
   }

   sub will_modify { 1 }

   sub is_NG {
     my ($text) = @_;

     my ($fh, $filename) = tempfile();
     utf8::encode($text);
     print $fh $text;
     close($fh);
     my $result
       = system(
       "bsfilter --homedir ~/.twitter-bsfilter --ignore-header --auto-update $filename"
       );
     unlink($filename);

     return !$result;
   }
 }

@ HTTP proxy の作成

Perl で HTTP proxy を作ろうとして真っ先に思い浮かんだのは POE だけれど、ちょっとヘビーなので今回は HTTP::Proxy をチョイス。 もともとフィルタリング HTTP proxy を作ることを念頭に置いた Perl モジュールなので今回の目的にぴったり。

1つはまった点といえば、filter の呼び出しがレスポンス全てを取得してからではなく一部分ずつの呼び出しになるところ。その仕様に気がつくのにちょっと時間がかかってしまった。 例えば XML 形式のレスポンスをフィルタしようとしても、普通に HTTP::Proxy を使うと XML の一部ずつがフィルタに渡されるため、XML のパースがうまくいかない。

これについては HTTP::Proxy::BodyFilter::complete を使うことで、まとめてフィルタに渡せるようになった。

@ レスポンスの処理

Twitter のタイムライン取得については P3:PeraPeraPrv が XML 形式で取得しているので、そのタイプのレスポンスをフィルタするようにした。

XML::XPath でステータス部分を抜き出して NG 判定し、NG であれば先頭に [NG] を追加する。 これで Twitter クライアント側で [NG] を NG ワード指定すれば、表示されないようにすることができる。

@ bsfilter による NG 判定

NG 判定は普段メールの spam フィルタとして使っている bsfilter を使った。 単純に system 関数で呼び出して結果を取得するだけ。

今回は対象がメールではないので --ignore-header を指定。また自動的に学習するように --auto-update を指定。 それと普段メールのフィルタリングに使っているのとは bsfilter のデータベースを別にしたいので、--homedir も指定しておく。

@ NG と非 NG の学習。

NG ワードを twitter-NG.txt に、非 NG ワードを twitter-clean.txt に書いて以下のコマンドを実行。

 bsfilter --add-clean --ignore-header --homedir ~/.twitter-bsfilter twitter-clean.txt
 bsfilter --add-spam --ignore-header --homedir ~/.twitter-bsfilter twitter-NG.txt
 bsfilter --update --homedir ~/.twitter-bsfilter

自分の環境 (Debian GNU/Linux sid)では、UTF-8 で書いておいて問題なかった。

@ フィルタリングしてみる

あとは先の proxy を起動し、P3:PeraPeraPrv でプロキシとして localhost:8088 を指定すれば OK。

タイムラインを取得するたびに bsfilter が動いて NG なステータスには [NG] が挿入される。

@ フィルタリングの精度

これについては、まだまだチューンの必要ありかな。

• 事前の学習データが少ない。
• --auto-update していることもあり、最初に NG 判定が多いとそちら側に強化されすぎる。
• 毎回 bsfilter を呼んでいるため、同じステータスが何度も学習される。

まだ使える精度まで上がってないけれど、教師データを増やせばそれなりにいけるかもしれない。

proxy の枠組ができたので、(@～は抜いてから bsfilter に渡すとか、前後の文脈も含めるとか)いろいろ試して遊べそうではある。 別に bsfilter にこだわらず、正規表現による判定などをしてもよいし。

この辺り P3 は Java で書かれているので、プラグインを書いて拡張できるよう将来になると面白いなと思ってみたり。

• Template Toolkit のテンプレート上で対話的入力 (2004-10-16)
• 今日のさえずり - それ多分 Gmail spam フォルダの中 (2007-12-27)
• 今日のさえずり - 鳩三郎が会社にきた (2008-09-25)
• 今日のさえずり - 100g 減る前にアタック買いだめ (2008-05-28)
• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)

■ Joel on Software - 必読書

「スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。」で参照したのがきっかけで、ジョエルテストで有名な Joel on Software を読んだ。

• Joen on Software

ソフトウェアプロジェクトマネージャ・ソフトウェア開発者必読書の1つだね。

扱っているテーマは幅広くどれも気になる記事ばかり。 ここではメモがてら興味深かった主要な記事をピックアップ。

@ 3章 ジョエルテスト

3分でできるソフトウェアチームの良さを評価する有名なテスト。

@ 5章 やさしい機能仕様 パート1: なぜわざわざ書く必要があるのか?

仕様書の最も重要な役割はプログラムをデザインすることだ。p.51

仕様書についての章が何章か続く。仕様書について実践的なことが書かれているのでとても参考になる。

@ 6章 やさしい機能仕様 パート2: 仕様書とはどんなものか?

サンプル仕様書が用意されている。 何をどのように書くべきかについて参考になる。

@ 8章 やさしい機能仕様 パート4: ヒント

そしてなぜ誰も読まないかといえば、仕様書があまりに退屈でつまらないからだ。p.79

これを読んでからできるだけ話を具体的に書くように心掛けている。 適当に外国人の名前をつけてシナリオを書くとなぜか皆喜んだ(同僚も外注も社長も)。

ルール5: テンプレートは有害である p.86

@ 9章 やさしいソフトウェアスケジュール

ソフトウェアプロジェクトマネジメントでうまくいかない事が多い筆頭がスケジュール。

「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」「タスクの粒度を細かくすること (それによって、その機能をデザインすることを強いられる)」「スケジュールにデバッグ・結合・バッファ・休暇・祝日その他のことのための項目を入れる」「決してマネージャにプログラマの見積もりを減らさせない」

あたりが参考になる。なおこの記事は Web でアップデートされている。

@ 12章 5つの世界

開発するソフトウェアの種類によって使える開発方法論が異なるのだから、自分のプロジェクトで適用できるかよく考えること。

@ 14章 アーキテクチャ宇宙飛行士たちに脅かされるな

抽象化ばかり考えて意味のないところまでいかないこと。

@ 21章 報奨金有害論

つい最近うちの会社でも表彰式があったばかりなんだけれども……。

マネージャは賞与の提案を上位に送り、それは完全に無視され、ほとんどランダムに賞与が支給される。p.188

多くの人は、自分が非常に良い仕事をしていると思っている (実際はそうでない場合でも)。p.189

@ 23章 人のタスク切り替えは有害であると考えられる

一つのプロジェクトに専念したいね。

人々に同時に1つより多くの作業をさせるべきではない。p.202

@ 24章 あなたが絶対すべきでないこと PART I

→ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

@ 25章 氷山の秘密、明らかに

顧客は自分が何が欲しいか分かっていない。顧客が自分で何が欲しいか分かっていると期待するのはやめることだ。p.210

これを理解していないと何でも言うなりにソフトウェア化しようとして失敗する。

@ 31章 下っ端でも何かを成し遂げる方法

多くの人は自分が下っ端だと思ってモンモンとしている。

• 戦略1 実行あるのみ
• 戦略2 じわじわ広めていく
• 戦略3 優れた人間を作り出す
• 戦略4 間抜けを無力化する
• 戦略5 邪魔を避ける
• 戦略6 かげがえのない存在になる

まずは不満を持つだけでなくて、個人ででも実行しようということ。

[ 書評 ] [ お薦めの本 ] [ ソフトウェアプロジェクトマネジメント ]

• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• ソフトウェアかんばん (2005-10-28)
• 仕事のヒント (2005-11-26)
• どうみても、そのままでは失敗しそうなプロジェクト (2005-05-16)
• ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)