Hatena::ブログ(Diary)

comuttの日記 このページをアンテナに追加 RSSフィード

2009-10-31

DevLOVE 97本読書会#1 に行って来た

| 04:31 |  DevLOVE 97本読書会#1 に行って来たを含むブックマーク

少し前になりますが、10/27(木) に開催された、DevLOVE 97本読書会#1 に行って来ました。

その感想などを書いてみます。

初めての読書会 & Extreme Reading

読書会自体が初体験で、当然 Extreme Reading も初体験でした。なので、どんな感じになるのか楽しみでもありました。

おおまかな流れは、

  1. 5、6人のグループに分かれる。
  2. 決めたエッセイ *1 を読む。
  3. 読後、グループ内で、各個人が気になったところなどを出し合う。
  4. まとめながら、「どうしたらいいか」などを意見を出し合う。
  5. 全体に、まとめた内容を誰かが代表して発表する。

という感じでした。

最初のエッセイ「83. 設計した通りにはならない」

最初ということで、各グループごとに読みたいエッセイを挙げて、どれか1つの同じエッセイを、全グループで読むことになりました。

選ばれたのは「83. 設計した通りにはならない」。

まず、このエッセイを勝手に要約 *2 すると、

  • 設計に非常に長い時間をかけても、その通りに実装できることはない。
  • 設計と実装が乖離する原因はいくらでもある。
  • 小さな設計変更は積み重なって、やがて大きなものとなる。
  • 設計は発見的プロセス。設計中に新しい情報を発見するのは当たり前のことなので、設計は柔軟で継続的なプロセスでなければならない。

というような内容です。

自分のグループでは、

  • うんうん、内容はその通りですね。
  • 内容は分かったけど、「設計した通りにはならない」問題にはどう対処したら良いの?

という流れになり、次のような意見が出されました。

  1. イテレーション開発でプロトタイプをどんどん作って、フィードバックを得て、設計と実装の違いや、設計の問題点を早期に洗い出す。
    • プロトタイプという成果物を作ることにより、まわりにも実装が見えるようになる。
  2. そもそも、設計した通りにはならないということを受け入れる必要がある。
    • プログラマは完璧に作ろうとしてしまうことがあるので、それが無いようにしなければならない。(完璧には作れない)
  3. 仕様は生物なので、変わることは当然ある。ということを、認識する必要がある。
  4. 仕様が変わることを受け入れるなら、仕様を差し引く勇気も必要。
  5. アーキテクチャの幹の部分と、枝葉の部分というのがある。幹の部分は変わることは、非常にコストがかかるので、出来る限り避けなければならない。逆に、枝葉の部分は変わることを受け入れなければならない。
    • どこが幹で、どこが枝葉なのか、ということを見分けることが重要。

というような意見が出されました。

自分は、まだプロジェクトの最初から関わったことが無いので、全体を通して「きっとそうだろうな、うんうん」という感じです。

1. は動くもの、見えるものを、イテレーション開発で作り、早くフィードバックを得る、というアジャイル開発そのものだと言えるでしょうし、

2. は、完成度 80%、90% のものを作るコストに対して、90% から 100% までのものを作るコストが非常に大きいし、結局完璧(100%)には作れないのでその分のコストが無駄になるということでしょう。

3. は、仕様はお客様との話し合いを続けながら決まるもので、当然変わることもあるでしょうから、そのことを受けれ入れなければ柔軟な設計・開発はできないでしょう。

4. は、自分が出した意見です。3. に関連するものですが、仕様を詰めていく過程で、コストや納期と折り合いが付かないなら、お客様との合意の上で仕様をトリアージする勇気が必要だと思います。折り合いがつかないまま開発するのでは、win-win の関係になれないでしょう。

5. は、家で言うなら幹が基礎や柱で、枝葉が建物内部の設備や内装になるでしょう。幹を変えることは、枝葉の部分に甚大な影響を及ぼすものだと思います。



2つめのエッセイ「巻末11. 説明責任を果たす」

2つめのエッセイは、各グループで異なるエッセイを読むことになりました。自分のグループでは、「巻末11. 説明責任を果たす」を読むことに。

またこれを要約してみますと、

というような内容です。

このエッセイについてもやはり、

  • うんうん、そのとおりだよね。
  • ドキュメントを書くにあたって、どうしなければいけないだろう?

という流れになり、

  1. やはり、エッセイにもあるように、誰に向けて書いてるのか、ということを明確に意識することが必要
    • お客様やPMに対する説明責任。 開発者向けとは別のドキュメントが必要。
  2. ドキュメントはメンテナンスをするのが難しい。だからといって、メンテナンスをしなければアーキテクチャやコードと相違が出てしまい、ドキュメントが腐ってしまう。
    • ドキュメントは1度書いて終わりではなく、継続してメンテナンスすることが重要。
    • 仕様変更などにドキュメントが追従していない場合がる。その結果、コードを見ても、ドキュメントを見ても、「なぜ、(現在)こうなっているのか」がさっぱり分からない、ということになることがある。
      • BTS を有効活用して、仕様変更をチケットで切る。うまく運用すれば、現在の仕様と、その経緯が分かりやすい。
  3. 全員(設計T、開発T、保守運用Tなど)が共通で理解できるコンセプト・フレーズで書かれたドキュメントが必要。
    • 細かい部分(各Tごとなど)のドキュメントは、当然派生しても良い。

というように意見が出されました。

1. は、伝えたい人が読んでもわからないドキュメントが価値が無いので、当たり前のことですがターゲットを意識して書かなければならないという重要なことだと思います。

2. は、ドキュメントはどうしてもメンテナンスされずに、現状との相違が出やすいという問題です。これは、ドキュメントのメンテナンス工数も必要だということだと思います。また、後から開発に参画する人間が、経緯を知ることができる手段として、BTS の有効活用が良いというのはなるほどな、と思いました。

3. についても、プロジェクト全体で幹の部分を理解するためのドキュメントが用意されていなければならないというのは、その通りだと思いました。

読書会 & Extreme Reading を体験して

上記のように、意見を交わすことで、本に書かれている文章を、より深く理解することが出来るのが Extreme Reading の良いところだと実感しました。自分1人で読んでいては、ここまで考えるには至らないでしょう。

また、参加している各人が、各々に異なるバックグラウンドがあるので、その視点での意見が聞けるのが面白いところです。

前半の部では、複数のグループで、1つのエッセイを同時に読みましたが、当然、各グループで異なる意見が出ます。この異なる意見を聞けるもの良いところです。

また、実際に参加してみて、PCがあると、まとめやすいし、意見の聞きこぼしも少ないなと感じました。特に自分の場合、文字を書くのがあまり速くないので、電子媒体でまとめたほうが楽です。

読書会から帰ってきて、メモを見返して、また理解が深まることもあるので、聞きこぼしがあるともったいないですね。

さらに、実際にやってみると、1時間があっという間に過ぎ去ります。

2時間で2エッセイというのが、数としては少ないと感じられるかもしれませんが、意見の出し合いがなかなかアツいです。

この調子だと、読み終わるのにかなりの回数が必要 *3 ですが、内容の理解が深まるリターンが大きいので、ありだと思います :)

97本について

実際に読んでみて、1つ1つが、だいたいA5判 1.0〜1.5ページなので、読みやすいですね。読書会の題材としても適していると思います。

朝に1エッセイとか、お昼休みに1エッセイとか、そういう読み方ができる読み物です。自分も、毎日1エッセイずつ読んでみようと、今思いました。

最後に

読書会を開催して頂いた @papanda さん、運営の皆さんと、ご参加された皆様のおかげで有意義な読書会になったことを感謝いたします。ありがとうございました。

ソフトウェアアーキテクトが知るべき97のこと

ソフトウェアアーキテクトが知るべき97のこと

*197本は、全部で97+11エッセイあります。ので、そのうちの1つを選びました。

*2:といっても、そもそもA5判 1枚分しか無いので、要約するほどでも無かったり。

*3:仮に、1回の読書会で2エッセイとすれば、97+11エッセイを読むのに54回読書会を開催する必要があります。

2009-10-05

DevLOVE新陰流ユーザビリティ勉強会行ってきた

| 07:15 |  DevLOVE新陰流ユーザビリティ勉強会行ってきたを含むブックマーク

第一部『新陰流のユーザビリティ』 柳生大介さん

何故新陰流なのか?を、説明を受けてもよく分からず(ぉ

ぐーぐるさんにお伺いして意味を理解しました。

内容はユーザビリティアクセシビリティと、その向上方法や検証について。

ユーザビリティを向上させるには、実際にエンドユーザさんを巻き込むのが一番ですよ。具体的な方法として、

  • グループインタビューでユーザの意見・ニーズを集約して潜在的ニーズを抽出
  • ユーザビリティテスティングで問題点を抽出

というのがありますよ、と。

アクセシビリティについては、ツールが豊富で、富士通さんがすごいので、どんどん頼ろうというお話。

WebInspector : 富士通

ColorDoctor : 富士通

ColorSelector : 富士通

HAREL <- これはNTTデータさん

また、アクセシビリティ指針が分かりやすいそう。

富士通ウェブ・アクセシビリティ指針 : 富士通

ユーザビリティアクセシビリティを向上させるにあたっての課題として、

  • いかにしてエンドユーザを巻き込むか
  • 費用対効果を明確にしなければならない
  • 開発者を意識向上(なぜユーザビリティ/アクセシビリティを向上させなければならないのか)させること

がありますね、ということでした。

大変勉強になりました。

第二部『ワールド・ユーザビリティ・カフェ』

5人1グループで、ユーザビリティの悪いものをどうしたら向上できるか、ということをディスカッションしました。

自分が入ったグループは、カーナビについてディスカッションしました。

自分はカーナビを使ったことがないので、さて大丈夫かな、とも思いましたが、やってみるとすごく楽しかったです。

ディスカッションルールは、

  • 発言する人はアイテム(ボールなど)を持つ
    • 発言者を常に1人にして、グループの中で複数の議論を発生させない
  • 発言者の意見に対して、「それ良いね!」と声に出して賛同する
    • 発言者がより多く発言するように促進する
  • 実装方法は問わない
    • 難しいことは考えない

だいたいこんな感じでした。

特に、最後の実装方法を考えないことは面白いですね。おかげで、当グループでは以下のような意見が出ました。

  • 嫁さんがカーナビにいつも文句を言って怒っているので、その姿を車載カメラで撮影して分析したら、きっとユーザビリティ向上に役立つ!
  • カーナビ自体も通信端末にしてしまって、ぐるなび的なものと連動してリコメンドしてくれたらいい
    • じゃ、携帯をダッシュボードに置けばカーナビになるようにすればいいんじゃ?
  • デバイスそのものより、中身のソフトウェアを上手く作らないとユーザビリティは上がらないよきっと
  • カーナビの画面を、拡張現実的にウィンドウにオーバーラップすれば、脇見もしないし行き過ぎることも無いし安全!
  • てかそもそもカーナビに運転させてしまえば楽チン!

などなど。

初対面の人と5人であんなに楽しく議論できるのかと驚きでした。

グループの皆様、ありがとうございました。

最後に

運営の皆様、ありがとうございました!

2009-10-04

CentOS 5.3 に checkinstall を入れるの巻き

| 21:43 |  CentOS 5.3 に checkinstall を入れるの巻きを含むブックマーク

git で最新版を取得してみる

http://asic-linux.com.mx/~izto/checkinstall/checkinstall.git/

を見て、仰せの通りに取得

$ git clone http://checkinstall.izto.org/checkinstall.git

コンパイル&インストール。が・・・

INSTALL を見て、これまた(ほぼ)仰せの通りに。

$ make
$ sudo make install
$ sudo /usr/local/sbin/checkinstall

checkinstall すると、以下を聞かれた。特に特別なことはしなかった。

使用するパッケージ方式を選んでください。
Slackwareなら[S], RPMなら[R], Debianなら[D]を入力

入力 ===> R

変更するものの番号を入力してください。Enterで続行します:

入力 ===> Return

**********************************************************************

 Done. The new package has been saved to

 /usr/src/redhat/RPMS/i386/checkinstall-20091004-1.i386.rpm
 You can install it in your system anytime using:

      rpm -i checkinstall-20091004-1.i386.rpm

**********************************************************************

と言われたので、正直に

skomatsu@brazill ~/checkinstall-current/checkinstall
$ cd /usr/src/redhat/RPMS/i386/

skomatsu@brazill /usr/src/redhat/RPMS/i386
$ ls -la
合計 152
drwxr-xr-x 2 root root   4096 10月  4 19:59 .
drwxr-xr-x 9 root root   4096 10月  4 19:52 ..
-rw-r--r-- 1 root root 129911 10月  4 19:59 checkinstall-20091004-1.i386.rpm

skomatsu@brazill /usr/src/redhat/RPMS/i386
$ sudo rpm -ivh checkinstall-20091004-1.i386.rpm
準備中...                ########################################### [100%]
   1:checkinstall           ########################################### [100%]
エラー: アーカイブの伸長に失敗: ファイル /selinux/context;4ac88039: cpio: open失敗 - 許可がありません

しょぼーん(´・ω・)

回避策

で、ぐーぐるさんにお伺いしたところ、以下のメーリングリストの投稿を発見。

http://checkinstall.izto.org/cklist/msg00776.html

On Mon, 29 Aug 2005, Paul Smith wrote:

On 8/29/05, honey@xxxxxxxxx <honey@xxxxxxxxx> wrote:

I am using checkinstall 1.6.0 on Fedora Core 4, which creates my rpms

without any problems. However, when I go to install the rpm, I get the

following message:

# rpm -i mypackage-1.6.1-1.i386.rpm

error: unpacking of archive failed on file /selinux/context;43132312:

cpio: open failed - Permission denied

#

Any advice?

--exclude=/selinux

What for, Honey, is the line above?

Use the following command line in FC4:

checkinstall --fstrans=no --exclude=/selinux

ので、--fstrans=noは付けずに以下を実行。

skomatsu@brazill ~/checkinstall-current/checkinstall
$ sudo /usr/local/sbin/checkinstall --exclude=/selinux

skomatsu@brazill ~/checkinstall-current/checkinstall
$ cd /usr/src/redhat/RPMS/i386/

skomatsu@brazill /usr/src/redhat/RPMS/i386
$ sudo rpm -ivh checkinstall-20091004-1.i386.rpm
Preparing...                ########################################### [100%]
   1:checkinstall           ########################################### [100%]

出来た!

補足

なお、--fstrans=noを付けると、

Some of the files created by the installation are inside the home directory: /home

You probably don't want them to be included in the package.
Do you want me to list them?  [n]: 

と言われてしまった。

対象のファイル達は、

/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-de.mo
/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-es.mo
/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-id.mo
/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-it.mo
/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-ja.mo
/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-no.mo
/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-pt_BR.mo
/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-ru.mo
/home/skomatsu/checkinstall-current/checkinstall/locale/checkinstall-zh_CN.mo

だった。

単純に n と答えればよいのかなとも思ったけど、

なんか良くなさそうだったので、--fstrans=no は外した。

ちなみに、--fstrans自体は

--fstrans=<yes|no>             Enable/disable the filesystem translation code

ということで、ファイルシステム(パス?)を変換する/しない、ということみたい。

2009-09-20 XP祭り2009行って来た

XP祭り2009

17:40 |  XP祭り2009を含むブックマーク

昨日 9/19 に、XPJUG主催の、XP祭り2009に行ってきました。

あまりうまい感想や考察を書けそうにないので、素直に感じたことを書いてみます。

LT

皆さんスライドの気合の入り具合が半端無い!とまず思いました(笑)

そして、内容も非常に面白かったです。

鉄人28号は傑作でした。

講演、ワークショップ

講演の内容も大変興味深かったです。

今回はワークショップが一番印象に残りました。

突然知らない人(お隣さん)と2人ペアでワークショップをやることになったので、

最初は結構どきどきでしたが、楽しくペアワークショップをすることができました。

中にはたくさんのワークショップで少し疲れてしまった方もいらっしゃったようですが、

実際に手を動かして学ぶのは楽しいですし、講演内容への理解が深まるので、自分は大歓迎でした。

退屈しない、というのはすごい大事なことだと思います。

本のプレゼント

XPJUG初参加で、何も知らなかったので、

あの後ろに並んでいた本がプレゼント(抽選)されるものだとは思いにもよりませんでした。

運良く、「RailsによるアジャイルWebアプリケーション開発」を頂きました。大変感謝です。


懇親会

最初参加するかどうか迷っていましたが、参加して良かったと思いました。

当然知らない人ばかりなので、戸惑いながらも、気さくに話しかけて下さる方のおかげで楽しく時間を過ごせました。

そのほか

アージャイルは宗教、理解しました

おわび

「勉強会初参加です!」と胸を張って言ってしまいましたが、

よくよく考えると、かなり語弊があることが分かりました orz

実は、社会人になる前に、

はこだてIKA - IT Knowledge Association でえせスタッフとして活動しておりました。

# 大したことはしていませんが。

ので、「あ、嘘言っちゃった!??」と帰ってきてから焦ってしまったのですが、

attendee としては初めてなのは間違い無いと思うので、

どうかお許し下さいませ m(_ _;)m

2009-01-06

メタボなFirefoxのために、MetaboFixを入れてみた。

| 20:49 | メタボなFirefoxのために、MetaboFixを入れてみた。を含むブックマーク

最近、Firefoxさんのメモリ喰い具合が気になっていました。

で、調べてみたら、Firefox が使用しているメモリを定期的に開放する MetaboFixなる便利そうなものを今更ながら見付けました。

で、入れてみました。


f:id:comutt:20090106204119j:image

MetaboFix導入前。比較的長く起動してはいるものの、タブ数はほぼ最小限という図。

f:id:comutt:20090106204120j:image

MetaboFix導入後。かなり減りました。

f:id:comutt:20090106204121j:image

MetaboFix本体のメモリの消費量。

これは良い感じです。満足。