ヒビノログ

2年半ほど前、社内でTracを最初に使い始めたことから
Tracお世話人のようなものを任されていて、
新しい案件ができると、新規プロジェクトを作成して
メンバーや権限設定して、という作業をやってるんだけど、
Tracのスタートページに書く内容が固まってきた感があるので
まとめておこうと思った。

議事録、作業ログ

• 議事録や作業ログページへのリンク。
• 「次回の会議」ページも作ってアジェンダを書いてる。会議もTracの画面を見ながらやって、その場で議事録作成までやってしまう。

環境関連の情報

• サーバやクライアントのOS、ミドルウェアの種類、バージョン
• ネットワーク構成、システムに設定してるパラメータとか。

直近のTODO

• 関連するチケットの一覧をトップページに直接出してもいいし、一覧ページへのリンクでもいい。
• スクラムで言うところのスプリントバックログ、かな。

主な資料

• この欄についてはプロジェクトによってまちまちなんだけど、どんな条件でどんな操作をするとどんな結果を得るか、といったことを機能別にまとめて、そのページへのリンクを書いたりしてる。
• それとテーブル定義書とか、ER図とか
• あとは、開発環境の作り方、SVNへのコミット、テスト、デプロイ手順など開発に関するお約束へのページへのリンクなど。

プロジェクトの説明と関係者一覧

• このプロジェクトで実現することは何か、どんな意図があって、どんな想いが込められているか、といったようなことを書いておく。プロジェクトが苦しくなってきても心が折れずに済む、かもしれないｗ
• あとは関係者の名前、連絡先とか。

今朝、客先のSEさんから、cronの設定を更新しようとしたら
「デバイスの空き容量がありません」とメッセージが表示されて
更新できないと連絡あり。

調べてみると、そもそも /var 領域への書き込みができなくなってて、
ディレクトリ作成やファイル更新でもエラーになる。
ディスク容量にはまだ余裕がある。
それで、inodeの状況を調べてみたら、/var 領域の最大値までinodeが使われてた。

> df -i
Filesystem Iノード I使用 I残り I使用% マウント位置
/dev/cciss/c0d0p5 640000 640000 0 100% /var

今回不具合が起きたのは開発用のサーバで、
もともと sendmail プロセスを止めてたんだけど、
サーバに設定してたcron処理の実行結果メールがキューに
溜まりに溜まっていたようだ。63万ファイルもある･･･

/var/spool/clientmqueue 配下のファイルを
すべて削除したら 1%程度まで下がった。

設定してた cron の中には既に不要になっているのもあったので整理。
開発機だからといって何でも残しておくのは止めよう。

明日が仕事始めなので、今頭の中で考えていることをつらつらと
書いておこうと思った。

• アジャイルについて知識を深める＆社内に導入していく
• Python覚えてTracのプラグインを作ってみる
• iPhoneに機種変してアプリ作ってみる
• 外部のコミュニティや勉強会にたくさん出る
• コドモの相手とヨメのフォロー
• 最低でも月に1冊は本読む
• ライブ企画して、やる

今年もよろしくお願いします（誰となく）。

昨年、IBMのセミナーでいただいた「実践!アジャイルプロジェクト管理」を読んだ。

アジャイルとは、スクラムとは、についてざっくりと把握できて良いと思った。
読んでいく中で「じゃあ、これってどうなるの？」という内容が次の項に書かれてたりして、無理なく読み進めることができた。「スクラムマスターはプロジェクトマネージャーにあらず」と明記しているのもいいですね。
RTCの説明については斜め読みしてしまったけど、リファレンス的に使えそう。

今年の早いうちに、1つでもRTCでプロジェクト運用してみたいな。

Windows 7からTimeCapsuleのHDDへの接続についてのまとめ。と言っても特に躓くところは無いと思うけど、普通に接続できるよ、ということで。

1. Windows7のPCに、TimeCapsule本体に付属するCDでAirMacユーティリティをインストール。
2. インストール後、Apple自動アップデートで「Bonjour for Windows」の最新版が案内されるのでアップデートしておく。
3. PC再起動
4. 再起動後、TimeCapsuleの共有ディスクに「アカウント」でパスワード設定している場合は、入力画面が出るのでそこでIDとPASSを入れる。マイコンピュータを見るとTimeCapsuleのHDDが表示されるはず。

少し挙動を見てると、短時間の接続断が時々起きてるっぽい。iTunesの曲データをTimeCapsuleの方に入れてるんだけど大丈夫かなー。しばらく様子見る。

とあるお客さんが作る資料が
いわゆる「Excel方眼紙」なことが多いんですが、
割とよくできていて、
プリントアウトしても中途半端に切れたり
変なところで改行したりしないので、普通に見る分には
問題無いんですね。

ただ、扱いに苦労することが無いわけでも無くて、
そういえば前に、方眼紙について話題になってたことが
あったなーと思って、twitterで

「Excel方眼紙ってそんなにダメ？」

とPOSTしたところ、完全に業務中の時間にも関わらず
たくさんの反応がありました。

「ダメ。Excel方眼紙は、帳票作成ツールを使ってるような感覚なんだよ。ある程度の枠に詰めなければならないってのは、紙資源の節約から引きずってる発想。」
「改ページ位置の調整とか、分の折り返しとか、罫線をページ最終行につけるとか・・・キリがない！文章書くならWordにしよう。必要なところにExcelシートを埋め込めばいいでしょ？と最近思う」
「紙の方眼紙の方がなんぼかマシ」
「EXCEL本来の使い方じゃないけど、便利といえば便利なので考えどころです」
「自分もなんでダメか分からないというか、そもそもExcel方眼紙とは何かわかってないというか」
「みんな代わりに何を使ってるか知りたいなぁ。何を使ってもしっくりこない。」
「まぁ方眼紙レベルまでいかないけど帳票みたいな使い方ってのは事務仕事では多かれ少なかれやってるか。うちもそうだなぁ。あれのおかげでずいぶん手間が増えてるもんな。」
「コンテンツとデザインが分離されてないのが致命的だと思う」
「帳票作成ツールにしては印刷機能が弱すぎる」
「Excel教ならテキストボックス使えば大丈夫とか言いそう。」

不評過ぎる・・・
「罫線をページの最終行につける」っていうのは初めて聞いたなぁ。
みなさん苦労してるんですね。

確かに「方眼紙」に限らず、そもそもExcelで
文字主体のドキュメントを作るのは、
なかなか無理がある部分が多いとは思います。

かくいう自分も、テキスト中心の文書をExcelで作ろうとは思わず、
それならWordで、ということになるんだけど、WordはWordで、
意図しないところで改ページが入ったり、
図やイメージを貼るとレイアウトが崩れたり、異常に動作が重くなったり、
最悪落ちたりして、いまいちしっくりこないんだよなぁ。
Officeでない別アプリを使うとかそういう話もあるけど
資料を見る側のことを考えると、なかなか現実的じゃない。

個人的には、「上手に作れて」「用途を決めれば」Excel資料もアリかなとは思います。
Wordに比べて「よし、テキスト書くぞ」などと構えずに
下書きのような感じで書き始めることができる気もする。

結局のところは、どういう人に向けて、どういう内容を伝え、
どう使われる資料なのかによって、
WordメインにExcelとをうまく使い分けていくということに
なるんでしょうねー。ありきたりな結論だけど。

品川のコクヨホールであった「Agile Conference tokyo 2009」に行ってきました。会場は300人くらい入るホールでほぼ満席。14:00頃着いたので、Microsoft 長沢さんのスピーチから参加しました。

以下、感想など。

• MicrosoftはVisualStudio2010を中心にした説明
• Microsoftは昔からアジャイルを取り入れている。
• VisualStudioとTFSとの連携はなんだかステキに見えた。MSがこういうツールで旗振ってくれるのはいいことだと思う。機能がゴージャスで使い方覚えるのが大変そうだけども。
• 確かにExcelは嫌いじゃないです･･･
• 「Get Clean Stay Clean」っていい言葉ですね
• 発表者の長沢さんがMac＆EclipseでTFSに接続していると聞いて途端に親近感がわいた
• IBMは玉川さんの説明。前回のIBMセミナーでも拝見していて今回2度目。
• Skypeが繋がらなかったのはハラハラした
• RTCを使ったアジャイル開発のデモ、普通にアジャイル用語使ってガシガシ進めてけど付いていけてちょっと嬉しかった
• IBMにあるという「アジャイルを適用できる案件かどうかのチェックリスト」、公開してくれないかなー。
• 日立はオフショア開発にアジャイルを使ったという話
• 「WFと同等の成果が得られた」ってコトでいいのかな。毎日国内で受入確認やるとかブリッジSEを通常の3倍にするとか、そこまですればやっぱり生産性はWFと変わらなくなるよなー。
• オフショア開発メンバーには好評だったらしいけど、「コミュニケーションを密に取る」のと、スプリント前に国内チームが作成するという「補足資料」と、日次での受入確認とが効を奏してる気がした。でもそうやって意思の疎通をきちんとやるコトってアジャイルに限らず重要ですよね。
• Xiao GuoさんとのQ&Aはピンと来る回答があまり無かった印象。

基調講演は聴けなかったけどどうだったんでしょうか。

今日のいただきもの。

IBMで行われた「チーム開発の生産性を高めるプロセスを体感しよう（入門編）」に行ってきた。

内容としては、アジャイル開発（主にスクラム）の基礎的な話と、ちょっとした実践、IBM Rational Team Concertを使ったデモ。

以下、気づいたことなど。

• ウォーターフォールとアジャイルの違いを、映画と連続ドラマに例えてたのはわかりやすいと思った。映画は公開後の手直しができなくてハイリスク、連続ドラマは毎回視聴者の反応を見ながら手直しできる
• 要求仕様が前提となるのがWF、リソースと納期をベースに考えるのがアジャイル。要求は24ヶ月で25%変質する
  ⇒個人的にはパーセンテージはもう少し高い印象
• 今までの組織で管理を担当していた人は、アジャイルでは役割が「プロダクトの下支え」となる。管理職も変わらなきゃいけない。
  ⇒これは管理職だけでなく一般社員にも言えることだなー。自律的に動くという意識を忘れないようにしないと（させないと）いけない
• 業務システムの75%が寿命を全うすることなく使われなくなってる。これまで「残業するから金をくれ」と言ってきた部分もあったりしたと思うが75%のために残業するんですか？、と。
• アジャイル開発の品質やスピードはツールにも左右される。
  ⇒自分のところではここがまだ弱いので今後もツール導入をどんどん進めていきたい
• ストーリー（戦略的計画と言ってた）の粒度は数日～２週間が目安、タスクは8時間（理想は5時間）
• 5～6イテレーションごとに「リファクタリング」を入れると良い。そこで変更を吸収する
• 優先順位は顧客のビジネス的価値によって決まるが、どうしても決まらない場合はリスクと思われるところからやる
• あいまいな部分は仮説を立てて、必ず確認するように。棚上げ禁止
• ワークショップでストーリーとタスクの立て方をやったけど、正解は無くとも、こういう視点でこういう風に作りましょう、みたいなのを示して欲しいと思った。自分のチームはストーリーもタスクも粒度が荒すぎた気がするので。
• それとも無料でなくお金払ったら教えてもらえたのかしらん？（笑）
• ストーリーポイントでなく理想時間で見積もりをやったのが気になった。自分の中の理解では、最終的には時間に落とすけど、まずポイントで見積もるのがアジャイルの１つの特徴でもあると思うので。
• 個人的には”アジャイルもどきを実践で始めた”程度なので楽しめたけど、既に実践されている方にとっては、ちょっと言いたくなる、ワークショップだったかもしれない
• 講師の三井さんはパワー溢れる方だった。あの年代の方でアジャイルとか言う方はあんまりいない気がするのでがんばっていただきたいと思う
• RTCについて、普段Tracを使ってるので抵抗無く飲み込めた。EclipseやVisualStudioプラグインがあるみたいだしSVNも使えるみたいだし、単純に画面が違うことによる戸惑いはありそうだけど、うまく使えば使えるかも、という感じなので今後試してみたい。Linuxでも動くのかなぁ。

会場で何人かお見かけしたことある顔かなぁと思っていたらやはり Shibuya.trac の方々だった様子。顔とお名前が一致してなくて声を掛けそびれた。もうちょっとこの界隈で顔を売っていきたいとも思った（笑）

セミナーのお土産がこれ。Amazonのカートに入れていてポチるところだった。あぶなかったー。

Twitterで

kurikazu : TraMのタイムライン表示でエラーになるなー。なんでだろ。

とPOSTしたらTraMの作者のRyuzeeさん召喚してしまった。申し訳ない･･･orz

エラーメッセージとしては、

'ascii' codec can't encode characters in position 0-20: ordinal not in range(128)
internal: none

というもので、文字コードが ascii として処理されている。
この場合、/usr/lib/python2.4/site-packages/ ディレクトリに、sitecustomize.py というファイルを作って、

import sys
sys.setdefaultencoding("utf-8")

と書いて保存する。Apache再起動したら直った。

今までTraM以外でも前述のようなエラーが出た事があって対処しきれずにいたけど、今回の修正以降はエラー発生してない。

【参考】
http://www.ryuzee.com/contents/blog/941
http://d.hatena.ne.jp/SumiTomohiko/20070120/1169300624

svn diff でファイル名のみ抽出するコマンドについては、
いろいろ検索してみると、

svn diff /path/to/trunk /path/to/branch | grep "^\-\-\- " | sed 's/^\-\-\- //' | sed 's/\t.*$//'

のような方法が出てくるんだけど、
これだと、画像などのバイナリファイルが取得できない。

svn diff の出力、テキストファイルの場合は

--- hogehoge.txt
+++ hogehoge.txt

というような記述があって、上記のコマンドは上の行を抽出してるけど、
バイナリファイルだとそもそもこのような記述が無く、diffの出力には出てきても
grepで抜けてしまう。

なので、こうしてみた。

svn diff /path/to/trunk /path/to/branch | grep "^Index: " | sed 's/^Index: //'

これだとバイナリファイル名も取れる感じ。