たまにはUIデザイン関係の本でも
誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)
現在仕事でプロトタイプ設計を行っているので、参考に。
アマゾンの書評を読んだ感じですと、知らなきゃモグリ系の本みたいなので
できればじっくりと読みたいな(時間無いかもしれないけど)
懐かしい響き
http://www.nyasoku.com/archives/50473968.html
私がやっていた頃の面子も同じように社会不適合者(誉め言葉)ばかりだったね。
あのゲームには何か人の持つ狂気を引き出す魅力(名状しがたき魅力?)があったんだろうな。
デスマーチ(3)
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
交渉
初期の見積もりは、それがどの程度理に適っているかは関係なく
当然のように削減される。
よって、常に大目の値(2〜3倍?)を提示する必要がある。
見積もりに係わるパラメータは、互いに影響を与え合っているため一つの
パラメータの変化はまわりまわってもとのパラメータに影響を及ぼしうる。
つまり、納期を早めようとする行動が納期を遅らせてしまう結果になることは
よくあることだということ。
納期に関係のあるパラメータが変化したならば、別パラメータに元の変化量の2倍相当の
変化を与えるつもりが無ければショックは吸収しきれない。
交渉はゲーム
ゲームにはルールがあり勝利条件がある。
有名なゲームであれば前例付きの戦略だって色々あるものである。
交渉ゲームは昔からあるし、別にシステム開発特有のものでもないので色々と
パターンを見出しておけば適切な行動も取りやすい。
免職と辞職
会社のお偉方と交渉する際に重要なカードになるのは自らの辞職である。
会社は期限までにシステムを完成させなければクビだと叫ぶかもしれないが
実際のところ、クビにしたところでシステムは完成しないし通常は悪化するだろう。
なので、このクビにするという脅しは一人しかいない人質を殺すといっている程度の
脅威にしかならない(最も、プロジェクト終了後にクビに成るかもしれないけど)
雇用者には辞める権利があることをユメユメ忘れぬよう。
(とはいっても、そうやすやすと決めれることでも無いデスよね。
この点に関しては日本とアメリカという違いがあるのかな?)
デスマーチ(2)
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
プロジェクトと政治
技術者は概ね政治が嫌いである。
が、実際にはプロジェクトは政治と無関係にはいられない。
(ここでいう政治とは、道理に適わない決定をねじ込む何かくらいの意味だと思われる）
プロジェクトに参加している個々人がどのように政治係わっていくかはプロジェクトによって変わるが、
どんな時でも今回の政治劇の関係者とその立場を洗い出しておく必要がある。
(私の意見としては、関係者に関する情報は全員が持っているべきだと思いますが、
実際の交渉事はマネージャが一手に引き受けるべきだと思う)
政治劇の参加者
・オーナー
-特例の発令者
・顧客
-実際のユーザ
開発途中では姿をあらわさないことが多く、反協力的であることも少なくない
・出資者
-厄介な外部者
・利害関係者
-↑3つの総称
・スーパーマン
-他の参加者を黙らせることのできる超越者
オーナーがこれを担当する場合はプロジェクトの成功率は上がる
■
またPHPを弄る日が来るかも知れないのでメモ
http://d.hatena.ne.jp/katase_n/20060514
ZendFrameworkはチェックが少なめだな〜
CakePHPって自動生成系(要するにRail系)Frameworkだっけかな?
PHPの単体テストはPHPUnit+自作モックオブジェクトで何とかしていました。
一人開発だったし。
テスト対象のクラスが依存しているクラスと同じインタフェイスを
持つクラスを単体テスト用スクリプトの最初に書く.
→各テストの前にそれらの生成.
→メソッドに返り値セット.
→テスト対象のクラスにセット.
→テスト実行.
という手順で。
PHP用のモックオブジェクトライブラリってあるのかな？
TODO : 時間ができたら探す
技術とか経験とかの蓄積
http://ruriko.denpa.org/200605b.html#12
パターンが何に対するパターンを指しているのかが判らないけど、
シナリオやら世界設計やらの話に対してパターンの抽出を行うとなると
どうなんでしょう？
パターンよりは逸脱がユーザによって歓迎される(と思う)世界だと思うのですが。
リソースの割り振りやら現実的なスケジュールの立案といった点では経験の
蓄積は十分なされるのかな？
ただ、あくまでイメージで話をしているのですが、ゲーム開発となると
分割しつつ開発を行うといった戦略が取り難そう+少人数による開発のため
ボトルネックに成りうる点が多そうな事を考えるとどれほど現実的な
スケジュールが立てれるかも疑問ですね。
とまあ、他所の業界にケチをつけつつも、「プロジェクトごとにあちこちに
ぞろぞろと移動し続けたらそりゃあ知識だのノウハウだのが個人以外の何かに
蓄積されるわけないよな」ってな現実も多い業務系の世界でじっと手を見る。
AMAZONサービスの呼出し
http://www.itmedia.co.jp/enterprise/articles/0502/28/news003.html
メモ。
単にHTTPでリクエストを送ると結果のBODY部にXMLで帰ってくるから
それを適当に整形して表示すればいいだけですか。
思ったより簡単そうです。
追記
http://dozo.rgr.jp/log/eid222.html
PEARにもAMAZONサービス用ライブラリが登録されていましたか。
まだβですらない状態のようですが。
ZendFrameworkの方でもそれっぽい名前を見かけたし、そろそろ
WEBサービスも楽に使えるようになるみたいですね
