nDiki : 2005年10月上旬

mixipress でコミュニティ掲示板もチェック

この週末 mixi で遊びのついでに mixipress も試してみることにした。

mixipress はPerlで書かれたCGI プログラムで、アクセスするとmixi にログインして「最新のマイミクシィの日記・参加しているコミュニティのBBSへの投稿・以前コメントした日記・日記へのコメント・メッセージ・足あとのダイジェスト」を含むRSSを返してくれる。

ローカルの Apache に mixipress 0.31 をインストール。 0.31 が出た後、 mixi 側で URL の変更があったのでそれに対応するように一部正規表現を修正。

で Sage でアクセス。 ふむふむ、これだと面倒で見ていなかった掲示板のチェックも楽だ。

• mixipress

[ Naney と mixi ]

遅ればせながら Greasemonkey。mixi の未読・既読の色分けなど。

閲覧するWebページの書き換えは今まで Privoxy でやっていたのだが、たまに落ちてしまうことがあった。

先日の Debian 再インストールでいったん Privoxy が無い状態になったし、今回は Firefox 拡張機能 Greasemonkey でやることにした。

mixi の既読・既読の色分け

鷹の島で公開されている Mixi Organizer 7月19日版で。

自分の場合足あとの踏み返しも色分けしたいので、

 --- MixiOrganizer.user.js.original     2005-07-19 11:49:10.000000000 +0000
 +++ mixiorganizer.user.js      2005-10-01 13:31:54.000000000 +0000
 @@ -34,10 +34,14 @@
                 var val  = Anchor[i].firstChild.data
                 if(val.match(/\((\d+)\)(\n)*$/))
                    Anchor[i].href = href + '#' + RegExp.$1;
 +            } else if (href.match(/show_friend.pl\?id/)) {
 +              var text = Anchor[i].previousSibling.data;
 +              if (text.match(/(\d\d\d\d).*(\d\d).*(\d\d).*(\d\d):(\d\d)/)) {
 +                Anchor[i].href = href + '&date=' + RegExp.$1 + RegExp.$2 + RegExp.$3 + RegExp.$4 + RegExp.$5;
 +               }
              }
           }
        }
     }

  })();
 -

と書き換え処理を追加。

• Mixi Organizer

[ Naney と mixi ]

次の週末に来客有り

滅多に人がこない我が家に、次の週末お客様が来る予定。 ということで、窓を拭いたり物を片付けたり(隠したり)。

先送りに立ち向かう

GTDの次の行動リストにいつまでも完了しないタスクがある。 どれもやりたい/やらなければならないモノだからリストの登録されている筈なのだが、なぜかいつまでもそこにある。

なぜ先送りしてしまうのか。タスクを見てみる。

1. 後回しにしても大丈夫そうなタスク。後でやればいいやといつも思ってしまうタスク。
2. エネルギーが沢山いりそうなタスク。時間がかかりそうなタスク。面倒なタスク。
3. 着手すると、新たなタスクがさらに増えて困ることになりそうなタスク。
4. リストをチェックした時に限って実行できないタスク(タスクが実行可能な時にはリストをチェックしないので、忘れてしまっている)
5. 実行不可能なタスク (本来「次の行動」として適切ではないもの)
6. 依存関係ですぐに実行できないタスク。
7. 具体的ではなくて、すぐに行動に移せないタスク。
8. 他人と調整しないと着手できないタスク。
9. 苦手な相手が関係するタスク。

どのタイプかにもよるが、それぞれのタスクについて勇気をもって向きあわねばらない。

次の行動として適切でなかったものについては、

• (GTDにおける)プロジェクトにして、小タスクに分割しなおす。
• いつか/もしかしたらリスト行き
• ゴミ

など整理しなおすべきか。

心理的障壁によるものについてはどうするべき? より心理的障壁の低いものにコンバートするのがいいのかな?

参考

• シゴタノ！ - タスクリストの“常連さん”をやっつけろ！
• シゴタノ！ - 続・タスクリストの“常連さん”をやっつけろ！
• シゴタノ！ - 仕事をサクサク進めるための１２のコツ

義兄入籍

義兄が本日入籍された。

おめでとうございます。

コードサイニング証明書が切れてもタイムスタンプを設定して署名すればOK

VeriSign の Authenticode対応Digital ID の所有者は VeriSign のタイムスタンピングサービスを利用してタイムスタンプを設定して署名することができて、この場合コードサイニング証明書自体の有効期限が切れても、新しい証明書で署名しなおす必要がない。

……知りませんでした。

WiKicker 0.27 リリース

機能的にちょっと区切りをつける必要がでたので、WiKikcker の新しいバージョンをリリース。 2005年5月10日より、約5カ月ぶり。

バグ修正の他、

• 若干のHTML構造変更(メイン部分を <div class="main">でくくるようにしたり、SearchPageの検索フォームを一部修正したり)。
• 新しいスキーマ anchor、1-area-map-image、1-area-map-limage、1-area-map-rimage を追加。
• HTMLタグ付けブロック文法を追加(オプション)。

など。

HTMLタグ付けブロック文法におけるHTMLのサニタイズについては、HTML 4.01 仕様書を見て主に

• HEAD の中で使うものなどは除外
• フォーム関係、フレーム、スクリプト、オブジェクト関係は除外
• %Script; な属性は除外
• %URI; な属性はスクリプトかどうかチェック

といった風にフィルタリングするようにした。 結構許したので、そのまま有効にする場合には組織内利用とか個人利用向けにした方が良い。

必要に応じてルールを変更できるように、サニタイズするモジュールは設定で変更できるようにしておいた。適宜お好みで。HTMLタグ付けブロック自体はデメリットも多いのであまり使わない方が良いと思うけれど。

雑誌のおまけ万年筆「ミニ檸檬」

ラピタ11月号の付録はオリジナル万年筆「ミニ檸檬」。 もちろん1冊買っておく。

まだカートリッジを入れていないから書き具合はわからないけれど、持った時の重さ加減はなかなかいい感じだ。

Lapita

• Lapita

目次ページによると

【おことわり】この雑誌は、40歳以下の読者を想定しておりません。 ゆえに、しばしば若者には意味不明な言葉や、見たこともないモノが登場します。 とくに説明などいたしませんので、そのつもりでお読みください。 -- Lapita 2005年11月号

だそうで。

雑誌の方は万年筆の特集はそれほど多くなくて残念。

---

• 梶井基次郎全集 全1巻 もちろん「檸檬」も収録。

---

[ 読書ノート ]

WiKicker 0.28 リリース - バグ修正版

WiKicker には「RFC821」といった文字列のようにマークアップすることなく認識されて処理される SWRN という識別子というものがあるのだが、これを処理するモジュールでバグを発見。'use' していないパッケージを使用しようとしてエラーになる。

以前高速化のため、無駄な 'use' 文を削除した際に消しすぎてしまっていたようだ。

表示がエラーになるという意味では重大なので速やかに修正版をリリース。

すごいKPT事後評価セッション

先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。

招待状

参加者には、以下の事前準備をメールでリクエストしておいた。

• 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
• 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」)
  • スコープ、スケジュール、リソース、欠陥レベル
  • プロジェクト運営
  • コラボレーション (スタッフ間)
  • 個人・チームとして学習した点
  • その他 (開発手法など)
• 問題点については「どのようにすれば〜(だろうか)」のかたちに書き換えてください。(すごい会議流)
• 良かった点のうち Keep のものがあるかご検討ください (KPT法流)。
• 問題点は Problem です。(KPT法流)
• 問題点について「次にやってみたいもの(Try)」が思い浮かんだらメモしておいてください。(KPT法流)
• 問題点に関係なく Try してみたいものがあれば、メモしておいてください。(KPT法流)
• 注意点 (「適応型ソフトウェア開発流」)
  • 良かった点を必ず書いてください。(すごい会議にも通じる)
  • 成功点、失敗点については3つ以上でも構いません (その際は、成功点と失敗点が同数程度に)
  • 特定の個人を批評はいけません。
• 事前に考えたメモを K・P・T 別にA5〜A4用紙各1枚程度ずつにまとめてプリントアウトして持参してください (発表時間短縮のため)。

セッション

メンバは4人。 ホワイトボードをK(Keep)・P(Problem)・T(Try)の3領域に分割。

それぞれ用意してきたプリントをマグネットや、テープでホワイトボードに貼りつける。4人分ぐらいならホワイトボードに貼れたし、前に集って座れば字もだいたい読むことができた。

【Keep】まず最初に成功点について各自発表。「うまくいっている」ことから開始するのはすごい会議流で。 次のプロジェクトで Keep しておきたい点について確認しておく。

【Problem】どのようにすれば〜でそれぞれ発表(すごい会議流)。この形式で表現することで、アイデアが浮かびやすくなる。アイデアが出れば ホワイトボードの Try の領域に書き込んでいく。

【Try】あらかじめ考えてあった Try をそれぞれ発表。

KPTの発表が終わったら、今度は Try をコミットメント化していく。 「担当」と「期日」を明確に設定 (すごい会議流)。

完了

合計90分。ほぼ予定時間とぴったり。 事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

今までの事後評価セッションに比べて次のアクションが明確になり、コミットメント化した事で実行する可能性が高まった。 成功点・問題点をそれぞれ発表して確認しあう段階までだった過去の事後評価セッションよりパワーアップ。

見せ書棚

妻の前の職場の同僚がうちに遊びに来た。 遅めのランチをとりつつ、午後はゆっくりおしゃべり。 同僚と妻の間での一緒に働いていた職場の話が中心だったので、こちらも気楽に耳を傾けていられた。

見せ書棚として、ギリシャの写真集やレザークラフトの本を並べておいたのはうまくヒット(逆に向こうが気をきかせたのかもしれないけれど)。

久しぶりの来客だったので、1カ月ぐらい(?)前から家の整理をちょっとずつしたりと大変だったけれど、帰ってしまった後はちょっとした寂しさを感じたり。

月に1回ぐらいのペースなら、お客さんを招待した方が良いかもしれないな。それより短い間隔だと忙がしくなるし、逆に長いと部屋が整理されている状態を維持できないし。

ずっといってみたいと思っていた銭函のお店

18歳ぐらいのころに雑誌で素敵なお店を知った。 北海道にあるユーラシア404というお店で暗闇が売りらしい。 とても気になってそのページをスクラップしておいた。

松井オーナーと話しこむうちに、目の下を銀河鉄道の電車が通りすぎた。

「さあ最終電車が行きました。悲しさと闇のクライマックスは、この最終電車を見送ることなんですよ。わか店最高の売りものをお出ししたわけですから、これで閉店になります」と、オーナー。 -- マガジンハウス BRUTUS 1990年4月15日号 p.143

部屋を整理するたびにそのスクラップを見て思い出していた。 今日また目にしたそれはかなり黄色くなっていた。 今回はきちんとチェックしてみようと Web で検索してみた。

……2003年春に閉店してしまったらしい。

かなり落胆。ショック。

スクラップしたのがいつだったのかもついでに調べてみたら、マガジンハウスのBRUTUS 1990年4月15日号 pp.142-143 の 「ビジネス裏極意　第11回　魔法の店の闇　北海道・銭函 荒俣宏 (写真 樋口直也)」だったようだ。 もう15年か。

思い立ったが吉日。

• ビジネス裏極意

TrackPoint のキャップをへびいちごに交換

TrackPoint のキャップがつるつるになって、操作感が悪くなったので交換。 久しぶりにクラシック・ドーム・キャップ(通称へびいちご)に。 今まで使っていたソフト・リム・キャップ、意外に良かったな。

好みとしては

1. ソフト・リム・キャップ
2. クラッシック・ドーム・キャップ
3. ソフト・ドーム・キャップ

の順。

[ WiKicker ] WRI まわりの整理

WRIに関して、private method、protected method がごちゃごちゃしてわかりにくくなってきたので整理。

今まではプライベートメソッドも、プロテクトメソッドも

 _private_method

のようにアンダースコアをつけていたのだがこれだと区別しにくい。 プライベートメソッドについては、

 __private_method

のように、__ を前置するようにした。 区別は容易になるが、コードが繁雑になるのが問題。

---

[ 命名規則 ]

体育の日 雨一時曇

今年はちょうど10月10日だったのだが、雨。 10月10日は「晴れの特異日」なのに年によって体育の日をハッピーマンデーで動かしやがってと思っていたが、調べてみると晴れの特異日ではないらしい。