2009年 7月 2日
CakePHPガイドブック（最初のやつ）を見ながら作った、ヒルクライムしようぜ！は、つくづくBad cakeである。今となってはなんでか知らないけど、モデルの中にロジックを書くことは悪であるという印象を受けていたような気がする。なので、モデルを見返してみると、ほとんど空なのだ。
CakePHP1.1から1.2に移植中なのだが、色々勉強しちゃおうと思って、ユニットテストを実装しながらやってるんだけど、ユニットテストをするためには、コントローラーに書いたロジックをできるだけモデルに移しながらの作業になるので、これがまた果てしなく長い…。根気のいる作業だ。ただ、ユニットテストが実装できていると、安心感が生まれる。
一人での作業なので、
という流れでやったほうがよさそうだ。
Good cakeにして、開発効率、メンテナンス効率を上げていくのだ。
2009年 7月 1日
実践バグ管理―プロジェクトを成功に導くための |
|
 |
クジラ飛行机
ソシム 2009-03 おすすめ平均 |
チームでRedMineによるチケット駆動開発を行えるように、メールで周知しながらバグ管理・チケット駆動開発を浸透させようとしている。現在のチームは色々あって実質、開発者2名とデザイナー1名の体制なのであるが、このメンバーにおいては、俺が伝えたいことに納得してもらって作業できていると思う。ゆえに皆、協力的である。また、課題が明確になるため、お客様にもRedMineの使用に協力してもらえている。
この効果は、昔のエクセルによる機能・バグ管理表とはえらい違いである。
管理表を常に最新の状態を保つことができるので、お客様にも最新の残課題がわかるし、コミュニケーションもチケット側にログとして残るので、言った言わないということも、基本的にはあり得ない。使えるようになった人は、もう以前の体制には戻れないと思う。
次は、この体制のスピードについてこれない人への配慮が課題になる。
スピードについてこれないというよりは、RedMineの使い方がわからないという点である。わからないから、RedMineの良さを享受できず、旧体質にこだわる（しかし旧体質はSE,PGに多大な負担をかけてしまうことが多い！）。しかし、わかってもらおうと使い方を説明しても、使ってくれない人は使ってくれないし、難しいところである。SEは使いこなせているんだけど…。ミニ冊子程度の使い方マニュアルでは動いてくれないのだろうか？
RedMineの習得コストと、エクセルの作成コストを考えると、明らかにRedMineの習得コストのほうが安いのであるが…。
2009年 6月 30日
この投稿は全然Tipsでもなんでもない。
気付きがあったので、まとめておく。
Good cakeは、Modelに処理を書き、Bad cakeはControllerに処理がある。
これは、ビジネスロジックがコントローラーにあると、テストしにくいからであるという説明があったのだが、最初はピンと来てなかった。しかし、よく考えたらデータベースに関連する処理はモデル側に定義してしまったほうが、何度も再利用ができるし、何よりテストしやすい。コントローラーはモデル・コンポーネントなど、複合的な要素があるので単体でテストしたとしても、他のクラスの力を借りているわけだからユニットテストといいつつも結合テストに近いのかもしれない。
ひとまず、XAMPP環境でモデルのテストをできるところまでを行った。
モデルのテストをガンガン実装したあとに、コントローラー側を記述していくことができれば、テスト駆動開発をようやく行うことができるかなぁ～と思う。プロジェクトにテストを組み込むというのをManage It!で読んだのだが、実装とほぼ同時にユニットテストを書いておければ、そのコードの信頼性を上げつつプロジェクトを進めることができるので、バグが出にくい開発を行うことができるだろう。
テスト駆動開発をチームで使えるようにしたい。
その前に、自分が使えるようになって、他の人に教えられるレベルになっておかなければ！
2009年 6月 29日
今日から久々に昔やってた案件の追加プロジェクトに着手することになった。
この案件に関して、見積もりは私と後輩で見積もった。決して多く見積もったつもりはなかったのであるが、仕様書作成とテストの工数が多いと客先から言われたらしく、営業側で工数を削減して見積もりを通してしまった。
私は「仕様書作成とテストの工数が削減されて、コーディング自体の工数が変わらないなんてことはありえない！それはおかしい」と再三言ったのであるが、無駄だった。なぜ仕様書を作る時間が半分にされて、そのままコーディングできようか…。
1人日かけて作成する予定であった仕様書の工数は0.5人日に削減され、本日で0.75人日使ってしまった。既に足が出ている。まぁこうなるのは、開発チーム側はわかっていたことであるが、なぜこれがむこうにはわからないのか？
日数自体はあるので、デスマーチにはならないと思うが、与えられている工数を守れるか…。
| Manage It! 現場開発者のための達人式プロジェクトマネジメント |
|
 |
でびあんぐる
オーム社 2008-10-18 おすすめ平均 |
2009年 6月 28日
| ウェブはバカと暇人のもの (光文社新書) |
|
 |
中川淳一郎
光文社 2009-04-17 おすすめ平均 |
俺が思っているような感じのタイトルだったので、買って読んでみた。
ウェブ製作サイドの人間が、そんな身も蓋もないようなことを言うなという話になるのかもしれないが、俺もこのタイトル通りのことを思ってる。そしてそれは間違っていないと思う。
ウェブを上手に使っている層からすると、ウェブはまだまだ可能性を秘めていると思う。まぁ、ここにも80対20の法則みたいなものが働いているのではないだろうか？著者は、ウェブの上手に使っている20%の層の話は他の人に任せて、その他80%について話をしている。その点を勘違いしてはならない（80対20の法則は勝手に俺が引用しているだけだが）。
変な正義感から、人の揚げ足を取るようなことをして、偽善者による総攻撃でブログ炎上みたいなことをやってるのは、バカと暇人によるものだってことが書いてある。そして、そういう人たちに火を付けるようなマーケティング手法が、ネット上のマーケティング手法であり、お行儀のよい手法を取ったところでその人たちにとっては面白くないので目に止まらずに、企業の自己満足で終わってしまう。いかにB級くさいネタで彼らを煽るのかがキモだと。
さらに、バカと暇なネットユーザはテレビの影響を受けやすいので（テレビは無料（受信料の発生しない局は）、ネットも定額なので感覚的には無料）、ネットから火がつくということはなく、テレビ主体の構図はこれからも当分変わらないだろうさ～ということだ。うーん、わからなくもない。
まぁ現実問題として、インターネットに多くの時間を割いている人で、クリエイティブでない人の割合は相当なものだろうと思うし、ブログなどの普及で爆発的に無駄な情報が多くなって参るとか、ほんまに多いしね…。まあそういう俺もブログ書いてるんだけど。明日からインターネットがなくなったとしたら、暇な人は一体何をして過ごすんだろうか？
ブログを書くこと自体がリスキーになってしまっている日本では、メリットが感じられない人はブログを書かないし、書かないほうがいいっていうのはすごく理解できる意見だった。企業が情報をオープンにすることで会社のことをよく知ってもらおうとしたら、逆に揚げ足を取られて信用失墜というケースも度々あることから、そこらへんは周到に準備して、双方向性を無視したスタイルでなければ、批判攻撃を受けてしまう。
ユーザとコミュニケーションができるのがネットの利点であるっていっても、不特定多数の人間には、いい人もいれば、バカもいるので、全てに対して対応するということがそもそもが無理なのだ。そのバカをうまくスルーした例として、ダウンタウンの松ちゃんの件が出てて、「あぁ、確かに一時期ニュースになってたけど、全然騒ぎが大きくならずに済んだな～」と思ったのだが、この対応は非常に適切で、これくらいのスタンスでなければやっていられない。自分にとって有意義な意見交換ができる人だけを相手にすることが重要なんだなぁ～。
ひろゆき氏の、「２ちゃんねるはなぜ潰れないのか？」とかも併せて読むと、本当に見も蓋もなくて、面白い。ネットに幻想見てる人たちに読ませてあげたいね。ただ、技術革新があれば、幻想に一段踏み込んだところに行けるからね。それがiPhoneとかAndroidだと思ってるんだけど。でもそれを使ってるのも、基本的には上位20%の人たちが多いんだけどね…。オイラはその20%には入っていません…。iPhoneは欲しいけど。
2009年 6月 28日
プロジェクトマネジメントの重要さを理解していながらちゃんと出来ていない現場のために、勉強して、現場の技術者に布教中である。俺も現場の技術者だけどね。
わかってはいるが動かないというか、それは私の仕事ではないという感じなんだろうか？まぁそれは本人たちにしかわからないのであるが、現場がよりうまく回るためには自分たちが変わるのが一番だろう。上層部は当てにならない、と思っている。思う事は伝える。けれど、彼らは言い訳の天才で、自分自身のことで一生懸命。わかっているフリはするので、それが現場の技術者の気持ちを逆撫でするのである。
以降はうちの場合の話であるが、Manage It!を読んで思うところは、1日は8時間で計算しては駄目だということだ。7時間か、プロジェクトリーダーの場合は4時間程度にして考えないと、見積もりを誤ってしまうなと思った。現場は不確定要素で溢れかえっており、マネジメントする人が(いるけど実質)不在なので、事は予定通りには進まない。割り込みが多ければなおさらである。リーダーに対しての割り込みは半端ないため(見積り依頼や進捗報告など)、8時間がっつり働けるわけがない。そういうことを踏まえた文化作りをしていかなければ、人が潰れてしまう。
RedMineを導入してから、どれくらいの工数を使っているかを定量的に見れるようにはなったが、まだ使い方が適当なので（それでも意識改革になったと思う）、個人レベルでやっているであろう振り返りをチームとしてやるようにして、チームの結束力とチームレベルの底上げをはかる必要があると感じている。
あとは、上層部から次々とくる要求・仕様変更をコントロールすることだ。これに関しては、ボコボコ言われてもできる作業量は一定なので、いったんフェーズが動き出した時点で仕様は凍結すると伝えたが、それでも彼(ら)の妄想は止まらない。
社内のプロジェクトマネジメント基準を策定して、それに準じて作業を行えるように、そういう基準をチームで作ろうと思う。
2009年 6月 26日
CakePHP1.2を使って、ヒルクライムしようぜの焼き直し作業を始めた。
正直、CakePHP1.1と1.2では相当な違いがあるので、移行には結構時間がかかりそうであるが、これを通してCakePHPでまだモノにしていない技術とかノウハウを覚えてしまおうと思う。とりあえず、だいぶ前に移行しようとして挫折したソースを発見した。viewの拡張子を*.thtmlから、*.ctpにしたのとか、若干モデルのメソッド類を修正したりとかしてた。それをカスタマイズしていっている。
一人でやっているプロジェクトなので、時間はかかりそうであるが、RedMineを使って工数管理やバグ管理のノウハウを自分なりに蓄積していこうと思う。
話は変わるが、最近、どうにもイラつくことがある。
それは、能力が低い人が努力をしないことと、行動をしない人が口だけで偉そうなことを言うことである。こういう人たちにフォーカスを当てているとそれだけで疲弊してしまうことは知っているので、なるべくそうしないようにしているが（この人はそういう人なんだから。そういう人も世の中にはいるよね。と思うことにする）、こういう人が上司だったりすると、否応なく影響を受けざるをえない（自分が、ではなく職場が）。
こういう人は教えても行動しないし、面倒なときは教えて君になるし、タチが悪い。それでいて、語気を強めると「君はできる人だから、私らの気持ちがわからないんだよ」とか言ってくる。人の業務改善提案は黙殺し、自分の思いつきだけは通そうとする。これでは現場は崩壊するし、何を言っても無駄だと思う。理想的なビジョンと現実的な戦略を併せ持っていないと、部下はついてこないぜ！と思うのだが、如何だろうか。
今のところ、妄想的なビジョンと非現実的な戦略、もしくは戦略がないと現場では感じていると思うんだが…。
2009年 6月 24日
最近、家で作りたいと思うようなシステムを思いつかない。もしくは、思いついているのに、行動に移れていない。原因は、開発環境の整備とかしてるだけでなんか時間が過ぎてしまっていることだ。あとは、細かい点まで詰められていないことだと思う。または、思いついたシステムは既に世の中に作られていて、作る気を削がれてる。これはよくない。
会社の仕事をしていて、開発チームの会議で言ったことなのだが、Webアプリの開発には目標と戦略が必要だ。たとえ戦略を練っていたとしても、失敗するときは失敗するのだが、チームのモチベーションが違う。それは個人でやるときにしても同じ事だと思う。
で、やっぱり俺が一番やる気が出せる分野っつったら自転車とプログラムとか、健康のこととかなので、そういう分野に特化したアプリやWordPressのプラグインとかを作ってみようかと思う。自転車に関して言えば、ヒルクライムのサイトが開発途中で止まってしまっている。このサイトはCakePHP1.1で構築されているのだが、まずはこのサイトをCakePHP1.2で構築し直してみようかと思う。
2009年 6月 23日
CakePHP1.2の話。
データベースのテーブル定義を更新しようと、schema.phpを編集してcakeコマンドでスキーマの更新をかけようとしたら、失敗した。
Can't DROP 'indexes'; check that column/key exists
indexesがDROPできないから更新できないよ～！ということらしい。
Googleで検索してみたところ、Google groupのcakephpのところに答えがあった。
http://groups.google.co.jp/group/tickets-cakephp/browse_thread/thread/84cbdf3093415923
ただ、cakeのコアを編集することになるので、
Cakeのバージョンがアップしたときに対応されてないと
またバグになってしまうので注意が必要かと思う。
ITシステム開発のPMそしてそのスポンサー必読です
// CORE/cake/libs/model/schema.phpの430行目
$tables[$table]['drop']['indexes'] = $diff['drop'];
$tables[$table]['add']['indexes'] = $diff['add'];
// を下記のように編集する
// $tables[$table]['drop']['indexes'] = $diff['drop'];
// $tables[$table]['add']['indexes'] = $diff['add'];
if(!empty($diff['drop'])) {
$tables[$table]['drop']['indexes'] = $diff['drop'];
}
if(!empty($diff['add'])) {
$tables[$table]['add']['indexes'] = $diff['add'];
}
この修正後、スキーマの更新を再度行ったら、indexesが正常に更新されました。
よかったよかった。
2009年 6月 22日
MacBookにiPhone SDKをインストールしました。
ちょこっと躓いた部分があったのでメモ書き。
WindowsのiTunesで使ってる既存のAppleIDを使ってApple Developer Centerに登録しようとしたのですが、AppleIDでログインしてみると、マルチバイト文字が文字化けしている！？しかも、全て半角英数で登録してくださいと書いてある…。でも姓と名は編集不可能な状態で、??と表示されているので、参った。
変更する方法はないものかと検索してみたのだが、変更できたように見えてもトラブッた例とかがあって、それを回避するために普段用のAppleIDとADC用のAppleIDを取る人のほうが大勢を占めているっぽかったので、例にならってそうした。
AppleIDを登録するとき、company / Organizationの欄にはIndividualで登録した。
最初は個人なので何を入力すればいいのかわからなかったので、空白にしておいたのだが、入力を求められてしまった。情報を探したところ、Individualで登録したのでいいらしい。
あとは利用規約に同意してiPhone SDKのダウンロードしてインストールするのみ！でした。
コメント