nDiki : サンプル

■ POE で HTTP プロキシサーバ

Privoxy などのプロキシサーバを使うと閲覧するWebページの書き換えをすることができるのだが、凝ったことをするとなると無理がある。

以前から興味のあった POE で HTTP プロキシサーバを作ってみることにしよう。 といってもまずは、サンプルを動かしてみるところから。

POE Cookbook の web proxy サンプルを動かしてみる。 なるほど短く書けていいな。

これに Web ページを書き換えるコードを挿入してあげれば、簡単に希望するプロキシサーバの出来上がり。 Greasemonkey も悪くないけれど、ローカルのデータとかを利用してページを書き換えたい時はこっちの方が楽であろう。 それに Perl だし。

• Twitter ベイジアンフィルタプロキシ (2007-12-29)
• Tor で hidden service (2005-02-13)
• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• 遅ればせながら Greasemonkey。mixi の未読・既読の色分けなど。 (2005-10-01)
• HTTP/1.0 Simple-Response (2004-06-01)

■ perltidy のコマンドファイルでデフォルト設定

perltidy をいろいろいじった結果、今のところ自分好みの設定は以下:

 # Basic Options
 --maximum-line-length=78       # default is 80
 --indent-columns=2             # (!= perlstyle) default is 4
 --preserve-line-endings

 # Conde Indentation Control
 --line-up-parentheses          #
 --nooutdent-long-lines         # default is --outdent-long-lines

 # Whitespace Control
 --paren-tightness=2            # default is 1
 --square-bracket-tightness=2   # default is 1
 --brace-tightness=2            # default is 1
 --nospace-for-semicolon        # default is --space-for-semicolon

 # Line Break Control
 --vertical-tightness=2         # default is 0
 --vertical-tightness-closing=1 # default is 0
 --want-break-before="% + - * / x != == >= <= =~ !~ < > | & >= < = **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="
                                # default is ". << >> -> && ||"

 # HTML Options
 -nnn
 --nohtml-entities

一応 Perl Best Practices (は持っていないので Web で公開されているサンプルファイル)の perltidyrc や perlstyle などを参考にしつつ作成。

インデント幅その他、比較的タイトがお好き。

• PostgreSQL を使いはじめる (1999-12-17)
• POE で HTTP プロキシサーバ (2005-10-15)
• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• Perl 用の doxygen のようなツールはないのかな (2006-07-25)
• 第2回 社内 Perl 勉強会 (2006-04-28)

■ なかなかの品質なオンライン名刺プリント

妻が Web で注文していた名刺が届いた。 帰省してしまっているので、一足御先にどんな塩梅かのぞいてみた。 出てきたのはボコボコな紙に印刷されている名刺。

点字?

もしかして間違えて点字付きにしてしまったのか? 痛恨の注文ミス?

と思ったら、宣伝がてら数十枚点字付きがサンプルで入っているとの説明書きが同封されていた。あーびっくり。

肝心の品質の方であるが、恐れていたペラペラッな紙ということはなくて一安心。 ちょっと白さがないクリーム色がかった紙だけれど悪くない。

印字も綺麗だしなかなかいい感じ。 これぐらいの値段だったら、下手に自分でプリンタで印刷してミシン目感のあるチープな名刺を作るよりもずっと良い感じだ。

自分もプライベート用に作ってみたい。渡す人いないけど。

• 結婚式出席のために帰省したらプロフィール印刷が待っていた (2006-05-13)
• PIXUS MP980 で初フィルムスキャン (2008-11-08)
• ロバート・キャパの未公開カラー写真 (2005-02-19)
• ヨドバシカメラのデジカメプリントの品質に満足 (2008-03-28)
• 今日のさえずり - 合ハイじゃない? (2008-11-03)

■ 第3回 社内 Perl 勉強会

リャマ本を使用した社内 Perl 勉強会の3回目を開催。今回も前回と同じメンバで7人。

今日は「初めてのPerl 第3版」第4章が範囲で、サブルーチンがテーマ。 いや、実際にはグローバル変数とレキシカル変数の話の方がメインかもしれない。

@ 今回の反省点

課題ベースだとシンプルなプログラムなので「グローバル変数よりも、レキシカル変数を積極的に使った方が良い」という点についてうまく伝えられたという感蝕がなかった。 この辺りは自身でより大きなプログラムを書いた時に、各人が体感していくしかないのかな。

それから、今回は問題数が2問と少なめ。ある程度 Perl を使い慣れている参加者もいるので、perlfaq7 サンプルコードを抜粋するなどしてコラム的に、追加ネタを用意してみた。

グローバル変数/レキシカル変数/ダイナミック変数の話はいいレベルだったが、クロージャーとレキシカル変数のからみの話はちょっと難易度が高めだったかもと反省。

各自の宿題のレビューを終えたところで結局、1時間弱。 最後のコラムを含めて1時間15分。

• 第1回 社内 Perl 勉強会 (2006-04-21)
• 第2回 社内 Perl 勉強会 (2006-04-28)
• 第6回 社内 Perl 勉強会 (2006-06-05)
• 第10回 社内 Perl 勉強会 (2006-07-18)
• 第13回 社内 Perl 勉強会 (2006-08-07)

■ 第5回 社内 Perl 勉強会

リャマ本を使用した社内 Perl 勉強会の5回目を開催。 今回は一人病欠で6人。 今回も先週の金曜日に都合がつかなかったので、月曜日の開催。

今日は「初めてのPerl 第3版」第6章「入出力の基本」が範囲。 この章で、ダイヤモンド演算子 <> を含む標準入出力の基本がほぼおさえられる。

@ 今回の反省点

標準入出力を使うようにしておけば、リダイレクトやパイプを駆使することで簡単なプログラムを組み合わせて超便利。 その辺りを伝えたいところであるが、Windows ユーザにはちょとうまく良さを伝えきれなかった感じで反省。

今回から one liner について触れていこうと思う。 Perl のコマンドラインオプション -ne や -pe などを使いこなせるようになるとこれまた便利なので、ぜひ馴染んでいただきたい。

しかしコマンド プロンプトだとコマンドライン引数のクォートの仕方が Bash 等と違うので、環境別にサンプルを用意しなければならにのがちょっとネックである。 今回は時間の関係で Bash 上での例しか示せなかった。 次回からはもう少しきちんとサンプルを用意したい。

今回はほぼ1時間丁度ぐらい。

• 第13回 社内 Perl 勉強会 (2006-08-07)
• 第12回 社内 Perl 勉強会 (2006-07-31)
• 第4回 社内 Perl 勉強会 (2006-05-22)
• 第2回 社内 Perl 勉強会 (2006-04-28)
• 第6回 社内 Perl 勉強会 (2006-06-05)

■ 姓と名の間にカンマを入れるか?

社内のサンプルテキストファイルに私の名前が「WATANABE, Yoshimasa」と書かれていた。

修正を頼んだら海外生活経験のあるスタッフから「公文書だと……」と言われたけれど、そういえば具体的にどの国のどんな公文書だか聞かなかったな。

2000年の秋頃からローマ字表記の際は、WATANABE Yoshimasa で統一するようにしている。 「姓-名」の時に、カンマを入れる書式があることは知っているのだけれど、なんか切れている感じで格好良くないし、正順なのに間になにかを入れなければならないのもちょっと気持ち悪い。ということで普段はカンマを入れていない。

そういえば今年の春に名刺を刷り直したときにも、カンマが入っていたので抜いてもらったっけ。

「姓-名」順の時にカンマを入れて表示するソフトウェアや、クレジットカードが「名-姓」であったりすることなどに噛み付いたりはしない。 書式指定がある場合には、まあしたがってもいいかな。

しかし、普通にコンピュータで表記したりするときはこれまで通り WATANABE Yoshimasa で行くつもり。 これって変?

• My name is `WATANABE Yoshimasa'! (2000-09-30)
• 第14回産業用バーチャル リアリティ展最終日 (2006-06-23)
• 名刺の肩書が「ディヴィジョン マネジャー」に (2006-06-07)
• The roof falls in (2004-12-03)
• [ Debian ] GRUB でソフトウェアRAID1 ブート設定 (2004-01-05)

■ コンビニの味がキツくなってきた

死んだ父は東北出身で、母は良く「東北の人はカラいのが好きだ」と言っていた。 サンプル数が少なくて信じていなかったが、実際東北出身の妻も比較的濃い口であった。

しかしながら今年に入ってから、妻が健康に気をつかって努めて薄味を心がけるようにし始めた。 もともと薄味派だった自分には嬉しい限り。

薄味に口が慣れてくると、微妙な味わいを楽しめるようになる代わりに濃いのがしんどくなってくる。

コンビニ弁当の何かを誤魔化すためかのような濃い味が最近ちょっとつらい。

• 今日のさえずり - 金メダルのネックストラップには、ケータイ用のヒモが付い... (2008-08-24)
• 母の年賀状文面作成 (2004-12-12)
• 年賀状作成 (2004-12-26)
• ハンバーグお持ちしました (2006-01-02)
• 東京プリンスホテルのビラビラ (2006-09-02)

■ Linux 上で Flex 2 SDK を使った Flash コンテンツ開発を開始

Flash コンテンツ開発については以前から興味があったんだけれど、手元 (Debian GNU/Linux BOX) で開発環境が構築できないので、ほとんど手をつけていなかった。 Ming を試してみたこともあったのだが、全然使いやすくなかったし。

しかしながらここ最近では Flex 2 SDK によって、Linux 上でも Flash コンテンツを開発できるようになった。 ということで技術調査をかねて開発環境構築と、コード書きを始めてみた。

まずはエディタとコンパイラと単体テストフレームワークがあれば開発できる。 Debian GNU/Linux sid 上で用意した環境は以下。

• JDK - sun-java6-jdk (6-02-1 Debian パッケージ)
• Ant - ant (1.7.0-3、Debian パッケージ)
• Emacs 21 (Debian パッケージ)
• Flex 2 SDK (2.0.1、Adobe よりダウンロード)
• Flex Language Pack (日本語、Adobe よりダウンロード)
• Flex Ant tasks (022607、Adobe Labs よりダウンロード)
• FlexUnit (code.google.com よりダウンロード)
• Flash Player 9 スタンドアロン版

エディタは素直に Emacs で。単体テストフレームワークは、FlexUnit (.85) をチョイス。

今回はビルドツールを何にするか迷ったけれど Apache Ant にすることにした。最初は Makefile を使ってサンプルをビルドしていたりしたけれど、今後 Autotools 使うのもどうかなと思って。

ドキュメントについては Adobe から結構な量で提供されているのでこれを見ればたいがい足りそう。

ということでぽちぽちプロジェクト作成。とりあえず SWF ファイルと同じところにあるテキストファイルを読み込んで表示するだけの MXML ファイルを作成して、build.xml を構築。

ほとんどの時間は build.xml 書きと、Subversion リポジトリセットアップに費された。

後は別途ちょっとサンプルで試してみた FlexUnit をプロジェクトに組み込めば発進できそうだ。

• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• ActivePerl で Ming (2005-02-23)
• Debian GNU/Linux で Dropbox (2008-09-16)
• JAlbum で Webフォトアルバム (2004-11-14)
• Windows でも Linux でも動くタスク管理ツール Task Coach (2006-01-12)

■ Google ドキュメントでソフトウェアかんばん

ソフトウェア開発の見える化としてソフトウェアかんばんの良さは実感しているのだが、分散開発ではさすがに「情報カードで」というわけにいかず実行しにくい。

今回の分散開発プロジェクトに向けていろいろ考えた結果、Google ドキュメントのスプレッドシートを使ってソフトウェアかんばんを遠隔共有してみようと思う。

@ 他の検討候補

TRICHORD を使ってみたいのだけれど予算の問題が。 検討したのは以下。

• TRICHORD - 本命。使ってみたいが予算が。
• Firefox + Internote (light-board.com ライク) - カード感は十分。しかし共有に難。
• 影舞用に新しくソフトウェアかんばんテンプレートを作る - 影舞を使い慣れているという点では○。ただストリーカードとタスクカードをどう扱うかが課題。
• Wiki - 以前やって失敗した。
• XPlanner - インストールと学習が手間。それと開発止まっている?
• その他 Agile Project Management Tool - カードメタファで良さそうなのはあるが、予算が。
• Google ドキュメント プレゼンテーション - 矩形をカードにしようとしたが文字は別オブジェクトで書かなければならず×。文字の背景を設定するというのも試したが見栄え・操作性が良くなかった。

スプレッドシートだとカードっぽさが薄れるが、共有・同時編集という点では安心して使えるし最大行数的にも OK。 一番運用しやすそうだということでこれでいくことにした。

@ スプレッドシートの作成

以下のようにスプレッドシートを作る。

• 1シート目はインフォメーションシートにする。ソフトウェア概説・かんばんルール・通信事項などを書くのに使う。
• 2シート名以降をかんばんにする。複数ソフトウェアならシートを分けてもよいかもしれない。
• かんばんシートE列の背景を「条件をに応じて変更」で本日より前だと赤くなるように設定する。
• かんばんシートF・G・H列の背景を「条件に応じて変更」で @ と書くと背景がそれぞれ赤・黄・青くなるようにする。

• ソフトウェアかんばんサンプル rev. 1

@ カードの書き方

• 各行にはストリーカードかタスクカードを書く。
• ストーリーカード行は目立つように罫線をつける。

TODO、DOING、DONE 列は1列にまとめることもできるが、ちょっとは「かんばん」っぽくなるかと思って分けることにした。

@ 運用

• カード番号は重複しないように。
• カードの状態にあわせて @ を書き換えていく。
• DOING から TODO に移る時には、開始日と担当者名を消さないで残しておく。
• 列単位でソートしないこと。
• タスクの粒度はできるだけ揃える(例えば半日～1日にする)。

@ 課題

• カードが増えた時に使いにくくならないか? 終わったカードを別シートに分けるルールなどを考える。
• タイムボックス等にあわせて並び換える時の手間。
• カード番号が手動。
• 集計について考慮していない。

• ソフトウェアかんばん (2005-10-28)
• WiKicker でソフトウェアかんばん (2007-03-01)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 京大式カード (2005-10-26)
• 今日のさえずり - SO905iCS おそれていたほどは厚く感じなかった (2008-02-08)

■ 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-11-26)
• ソフトウェアかんばん (2005-10-28)
• ナノパーセント日 (2005-10-26)
• すごい会議 - 短期間で会社が劇的に変わる! (2005-05-27)