nDiki : 仕様

製品レポート Perl WiKicker メール デザイン 開発 文法 日本語 API XML HTML ミッション プロジェクト立ち上げフェーズ 開発プロセスメモ 弁当 Wiki 研究 ThinkPad X31 Naney 見積もり LaTeX Java ソフトウェア プロジェクト憲章 ヨドバシカメラ ノート PC HTTP インストール URL コミュニケーション

■ GRAPH GEAR セミハードタイプ デジタルカメラケース DGB-016BK / DGB-016GY

Skype グッズ(マイクとか)が増えて NEW MEGALOPOLIS の中がごちゃごちゃしてきた。 マイクやらメモリカードリーダやらも、一緒くたに袋につめてバッグに放り込んでいるが、やはりものによっては圧力がかかったりしないか心配。 それから普段カバンに入れっぱなしの TC-1 も潰されないか気になっていたところ。

ということでよさそうなのがないか昨日ちょっと探してみた。 近所の無印良品には無し。

@ act CREATORS BOX

と、アトレ大井町の act CREATORS BOX で GRAPH GEAR なるセミハードケースを発見。 大きさもちょうどいい感じだ。 思わず買ってしまおうかと思ったが、内寸が TC-1 その他とあうか不明なので保留。 展示品はいっぱいあるけれど、パッケージに入ったやつがなさそうというのもあったし。

@ エレコム製か

うちに帰って調査。 どっかのしゃれたグッズかと思ったら、何のことはない ELECOM製。 去年のブロードバンドルータでの失態(セキュリティ脆弱性や GNU GPL 違反に対する対応のまずさ)以来、不買としていたわけだが。 この間も会社でヘッドセットを買ってきてくれるという時に「エレコム製以外で」と言い放ってしまっているし。

ま、いっか。

@ ということで今日購入

昼休みに秋葉原に書いにいく。昨日の act ばっちり定価で高すぎ。 量販店などだと手頃な価格だ。

シリーズでサイズが何種類かあるが、TC-1 や CM-DS6 の事を考えて DGB-016 にした。

ブラックを2つ買おうと思っていたのだが、1つしかなかったのでもう一つはグレーを。 グレーの方が格好良いがすぐ汚なくなりそうだ。

バッグに入れっぱなしにするつもりだしカラビナはいらないかなぁ。 まあさっと手にとる時には便利なので、つけたままにしておくか。

仕様の内寸から考えていたよりは余裕がある感じ。TC-1 もばっちり納まる(ちょっと広いかな)。 大きく口が開くので、出し入れも楽。

一方はTC-1、他方はPC関連グッズ用として活躍しそうだ。

• ELECOM DGB-016BK グラフギア デジタルカメラケース(ブラック)
• ELECOM DGB-016GY グラフギア デジタルカメラケース(グレー)

[ 製品レポート ]

• 300円で Skype 用ハンドセット DP-101Y (2005-02-14)
• 万年筆用に GIORGIO FEDON 1919 のペンケース シングル (2005-12-12)
• コンデンサーマイクロホン壊れてた (2005-01-29)
• Skype の音量調整 (2005-02-02)
• ヘッドセット インナーイヤータイプ HST401-MT - アーベル (2005-02-03)

■ AN HTTPD 1.42n も PATH_INFO が シフト JIS に

Windows 用 Apache 2.0 では PATH_INFO がシフト JIS になるという仕様により WiKicker がうまく動かないのだが、AN HTTPD どうかと思い確認してみた。

結果は×。

AN HTTPD も PATH_INFO はシフト JIS になってしまう。

• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• [ WiKicker ] destination anchor を打てるように (2005-09-13)
• Perl v5.8.8 の CGI.pm の PATH_INFO 処理の問... (2006-07-08)
• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• WiKicker でドメイン名なしの URL でセッションがはれなかった理由 (2006-11-10)

■ xDピクチャーカード対応 USBリーダ/ライタ MAUSB-100

FinePix F10で撮影した画像は、ちまたで評判の悪い付属のマルチコネクターアダプターを使用してPCにUSB接続している。

個人的には別にあのアダプターはそれほど悪くないと感じている。 ACパワーアダプターとUSBケーブルをつなぎっぱなしにしておけば、画像吸い出しの時に充電しておけるし (1日10枚程度の撮影であれば、充電もあっという間に終わる)。

しかしFinePix F10側のマルチコネクターアダプター端子がやわそうなので、つけたり外したりを繰り返すのはちょっと心許ない感じがするのも確かだ。

ということで、結局xDピクチャーカード用のリーダを購入することにした。 ノート PC にケーブル無しでプスッっと挿せるタイプが便利で好きなので、オリンパスの MAUSB-100 を選択。

xDピクチャーカードを挿入したまま全体を保護するキャップがついているので、先日届いたキャンペーンの128MB xDピクチャーカードを挿しっぱなしにしておいて、USB メモリ的な使い方をするのにも便利そうだ。 ただし 仕様では読み出し約3.5MB/s、書き込み約0.5MB/s と、最近のUSB メモリに比べて遅いので、それほど期待はできないが。

ちなみに MAUSB-100 の後に出た、xDピクチャーカードとのセット品、MAUSB-200 は読み出し・書き込みとも 約0.5MB/sらしい。

どちらも実測したわけではないので実際のところは不明。

それから特徴的なのは、ライトプロテクトスイッチがついている点。 リーダ/ライタでこれがついているのは珍しいのでは?

信用おけない Windows に挿す時にライトプロテクトできるのは嬉しい。

会社でDELLのPCを買った時におまけてついてきた、バッファーローのUSB メモリ ClipDrive を使う時もよくライトプロテクトスイッチを利用していたし。 しかしながらこいつスイッチがチャチくて、ある日ポロッっともげた。 ライトプロテクトオフの状態でもげたのがせめてもの救い。

MAUSB-100 も基板の上に固定されている小さなスイッチなので強度には不安が残る。

そういえば MAUSB-100 にはxDピクチャーカードのためのホールドスイッチもついているのだが、この立て付けがよろしくない。ホールドを解除すると斜めになる。

まあとりあえず例によって USB マスストレージクラスで Linux からも問題なく読めるしそれなりに便利に使えそうである。

[ 製品レポート ]

• 1インチポータブル HDD HDMC-U12 インプレッション (2006-12-28)
• PEG-TJ25購入 (2004-03-05)
• 今日のさえずり - Amazon.co.jp でママレモン売ってる (2008-10-16)
• Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
• PIXUS MP980 の写真用紙は光沢 ゴールドで (2008-11-08)

■ Inline::Pdlpp で 手軽に PDL::PP のコードを書く

PDL を使用しているプログラムの高速化のため、再び PDL::PP でコードを書こうとマニュアルを見直したりしている。

PDL::PP にも Inline 系の Inline::Pdlpp モジュールが用意されているのか。 PDL::PP の仕様は結構わかりにくくて(かなり)慣れないと大変。 何度も書いてはテストしてみることになるので、そういった意味でも Inline できるのはすごい便利。

Inline::pdlpp で関数ができあがったら 整理して PDL::Core::Dev のサポートのもとで Makefile.PL を書くようにすれば、いっちょあがり。

• [ Perl ] PDL::PP で C extension を書く (2004-02-19)
• PDL と 疎行列 (2004-06-14)
• 続 PAR 化 (2004-08-25)
• WiKicker の Makefile.PL を Module::Inst... (2006-02-10)
• GRAPH GEAR セミハードタイプ デジタルカメラケース DGB-01... (2005-02-07)

■ [ WiKicker ] destination anchor を打てるように

WiKicker には終点アンカー(HTML だと name and/or id属性付きA要素)をページ中に書く機能がない。

• 直観的ではない。この機能を知らない人が WikiPage を編集しようしたときに、ソーステキスト中にこれがあるのはよろしくない。HTMLを知っている人なら問題ないかもしれないが、そうでない人にはわかりにくい。
• アンカー名の一意性の保証が面倒
• 終点アンカーを書いて、他からご丁寧にリンクしても Wiki の正確上誰かが編集してすぐ無くなっちゃうかもしれない (そういってしまえばページそのものもそうであるが)。

等の(自分なりの)正当な理由で追加していなかったのだが、まぁ必要になったのであっさり追加することにした。 アンカーテキストに WiKicker のインライン要素を書けるようにするかどうか迷ったが、HTMLでレンダリングする際にA要素のネストを避けたりするのが大変なので書けない仕様にすることにした。

 [[anchor:anchor_name]]
 or
 [[anchor:anchor_name][anchor_text]]

という表記 (WRN scheme)を追加。 アンカー名の一意性の保証はまだ未実装。 やっぱやらんといかんかな。

• [ WiKicker ] form/list の paragraph から... (2003-05-03)
• [ WiKicker ] 憧れのサイドバー (2004-01-23)
• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• [ WiKicker ] If-Modified-Since: 関連作業ほぼ済 (2003-09-19)

■ ナノパーセント日

ミーティングで、あるプロジェクトのスケジュール遅れが議題になった(参加していないプロジェクト)。

リクエスト側と開発側で、仕様の誤解による手戻りが大きな原因のようである。

• リクエスト側と開発側が物理的に離れていたため、顔を合わせたキックオフミーティングを行わなかった。
• その後のコミュニケーションも不足であった。

あたりが問題か。 物理的な距離の壁はデカイ。

それから、β版リリース日がナノパーセント日(あるいはそれよりも前)であった可能性も高いように思えるが、その点はどうか。

(Naney注:リスク図の)曲線の左側が水平になる地点が、「確率がゼロではない最初の日」である。しかし、限りなくゼロに近い。この日までに完成する確率は1ナノパーセント程度なので、この地点をN(ナノパーセント日)と呼ぶ。-- 熊とワルツを, p.65

自分も「これどれぐらいでできる?」と言われると、つい奇跡的最短期間を口にしがちである。 気をつけねば (もっとも、見積もりとは関係なく期日がセットされていて内容で調整ということも多いが)。

[ ソフトウェアプロジェクトマネジメント ]

• Joel on Software - 必読書 (2008-08-14)
• 開発スタッフ怪我をして入院 (2004-10-26)
• スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスク... (2008-06-14)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)

■ 定型書式で内容を記述していくのに便利な形式は?

今要求仕様書を LaTeX で書いている。 要求と仕様の組をまとめて longtable で記述しているのだが、 LaTeX らしい繁雑さがあってちょっと効率が悪い。 マクロを定義すればある程度書きやすくなると思うが、それでもそこそこまでな気がする。

文書の中にレコードの並びが書けて、レコードの並びの中に文章が書きやすいそんなフォーマットはないものかなぁ。

• LaTeX + マクロ
  • 整形は綺麗。
  • 記述が繁雑になりがち。\マクロ名とか {} とか。
• DocBook
  • 仕様デカスギ
  • 以前使ってみたことがあるが、手で書くのにはしんどい。
• XML
  • 構造的な情報の表現には良いのだが、手で書くのはしんどい。開きタグも閉じタグも。
  • 普通の章節や、マークアップのルールを考えなければならない(定義するか借りてくるか)。
  • LaTeX等へのコンバータを書く必要あり。
• YAML
  • レコードの並びだけだったら良いが、文書の他の要素を一緒に書くのには適さない。
  • ある程度の構造やボリュームがあると、思ったほど手書きしやすくない。
  • YAML Perl モジュールで痛い目にあっている。

Wiki に慣れきっている自分にとっては Wiki 文法のような感じで記述できて、一部に定型レコードの並びが書けて、そこの整形ルールだけ定義してあげれば LaTeX に変換できるとかそういった感じがのものが欲しい。 定型レコードの部分は RFC822 のヘッダみたいな感じで良くで、値の部分に長めの文章を複数行で書けるものがいい。

構造化テキスト用フォーマット、あるいはWiki フォーマットをアレンジするのがいいかもしれないな。 このあたりのフォーマットは、ソーステキストのままでも充分読み易いことを意識して定義されているので書くのは楽。

• reStructuredText
  • いいらしい。
  • HTML、LaTeX、XML へのコンバータがある。
  • 拡張性も考慮されているらしい。
  • でも Python。
• Markdown
  • reStructuredText よりもソーステキストが読み易いらしい。
  • Perl
  • HTMLへの変換しかない。
• WiKicker (Wiki)
  • かなり書き慣れている。
  • レコードの並びの書き方を考える必要あり。
  • 複数行にまたがる処理を書くのが面倒。
  • 自分で書いているシステムなので中身は何でも知っている。
  • マイナー。

レコード部分とは関係ないけれど reStructuredText や Markdown の「アンダーラインのあるテキストを見出しとする」っていうのはいいな。 普段メールやプレーンテキストでちょっと文書を打つときに使っているスタイルと一緒だ。

要求仕様書用に使うかどうかは別として、要チェック。

• 早速 reStructuredText から LaTeX へのコンバータを書く (2005-11-24)
• Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
• reStructuredText いいんじゃない? (2005-11-22)
• 私的10大ニュース2005 [ comp ] (2005-12-31)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)

■ 早速 reStructuredText から LaTeX へのコンバータを書く

要求仕様書を書くのに reStructuredText を使ってみることにしる。 reStructuredText の文法の上で、あるルールに従って書いた特定のセクションやフィールドリストを要求レコードや要求仕様レコードとし、自前でコンバータを書いて LaTeX へ変換する形。

まずは最初のアイデア通り rst2xml で XML に変換してから、Perl スクリプトで読み込んで処理することにする。

Perl 側の処理は XML::LibXML で (何となく XML::DOM より好き)。 しかし毎度ながら DOM 面倒くさい。 とりあえず、今必要な要素のみ変換コードを書く。 reStructuredText を XML へ変換した時の DTD があるので、おいおいこれを見ながらきちんと埋めていかねば。

最低限のものができて、早速コンバート。

これで生 LaTeX で書くより随分楽になった。よし。

• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
• JavaScript でのプログラミングやっぱり面倒くさい (2006-07-23)
• reStructuredText いいんじゃない? (2005-11-22)
• Progect -> XML -> text, HTML (2004-04-16)

■ UPS 選択用にワットチェッカーで消費電力を測定しよう

会社のサーバ用のUPSがどうも死にかけているようだ。 結構古いし、最近はサーバ構成もかわってきたのでこれを機にUPSをリプレースしたい。

どのUPSを買うかを考えるにあたっては各機器の消費電力を調べなければならないが、最近のPCの仕様には消費電力が書かれているものがかなり少ない。 販売時のCPUその他の構成によって消費電力がまちまちだったり、稼働時も負荷によって消費電力が上下するから一概に書けないのかもしれないが、これが結構困る。 展示会出展などで、使用する電力を問われても答えることができなかったりするし。

ということで、今回はワットチェッカーを購入して測定してみることにした。

• SANWA SUPPLY TAP-TST5 ワットチェッカー

使い方は簡単。ワットチェッカーをコンセントにさした後、測定したい機器をワットチェッカーにさすだけ。 通電と同時に測定がはじまり、1秒毎に測定結果が液晶に表示される。 同時に積算が始まるので、長時間接続しておいて後で平均を求めるのにも便利。

手軽でグッド。

ちなみに自分の ThinkPad X31 (2672-PHJ)、 Pentium M 1.60GHz を積んでいて普段は cpufreqd で 600MHz で動作させているののだが、この状態で 約 16W。 DELL PowerEdge 2600 (Xeon 2.80GHz x 2) はアイドル状態で 150W ぐらいのようである。

できれば自宅にも1つ用意していろいろ調べてみたい。 一通り調べ終わると飽きちゃいそうな予感もあるが。

[ 製品レポート ]

• ThinkPad X31 + Debian で Google Earth ... (2006-12-09)
• ThinkPad X31 と Linux kernel 2.6 (2006-02-22)
• 私的10大ニュース2003 (2003-12-31)
• WiKicker リリースに向けてテスト追加・バグ修正 (2005-04-16)
• PEG-TJ25購入 (2004-03-05)

■ ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

@ ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

@ issue tracking

開発中に発生する

• モジュール間のインタフェースの問題点(あるいは不明点・疑問点)などの確認/議論の必要なもの
• ライセンス関連の問題など意思決定を要するもの

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

@ インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

1. インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
2. しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。

@ 止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

• 30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

• ソフトウェアかんばん (2005-10-28)
• すごいKPT事後評価セッション (2005-10-07)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• 京大式カード (2005-10-26)
• ビジネスメールガイドライン案 (2006-05-05)