薄いので電車の中で読了。
読みやすい。

これはでもメモはいらないな。
巻末に載っている天使の助言を見れば事足りる。

大事なのは技術じゃなくて習慣なのね。
だからこそ定期的に天使の助言を見て思い出す必要がある。

そして一番心に残ったのはこの助言

正しいことをしましょう
誠実に、勇気を出して真実を伝えなさい。
時にはそれが難しいこともあるでしょう。
だからこそ勇気が必要なのです。

これに対する悪魔のささやきは

人のコードに問題を見つけても、自分の胸のうちにしまっとくんだ。
当人の気分を害したり、もめ事を引き起こすのは嫌だろ。
そいつがもしお前の上司だったらなおさらだ。
言われたことにだけおとなしく従っておけ。

こんな状況はよくあって、やっぱり言うのはめんどくさいんだよね。
言ったところでいい顔されないことが多いし。
俺になんの得があるんだ。
なんて思っちゃうことが多い。
でもそれじゃあ長期的に見て良くないし。
自分が正しいと思ったら少なくとも2回は押さないとダメだなぁって今思った。
1回だと理解されない事が多い。
なので様子（ころあい）を見てもう1回言う。
3回はちょっと言い過ぎかも。
それは独りよがりかもしれない。

ともかくそんな感じで腐ることなく押すときは押して引くときは引いてバランスよくやっていけたらいいなと思いました。

PHP拡張勉強会を考えてみる - おぎろぐはてな

Sara本を持っているけど、英語超苦手、C言語苦手だもんでサンプルコード少しだけ読んで放置している自分としては超興味そそられます。

ほんとに対象者があれくらいでよいのなら是非参加してみたい。

今年から読書メモを残すことにする。

まずは、去年から読み続けているCode Craft。
とりあえず今読んでいる第8章から書いてみる。
ブログよりはwikiの方が書きやすいのでtracのwikiに書く。
読書メモ:Code Craft

しっかし、慣れてないのですごく時間がかかる。
それにただの引用になったりしてる気が。

現状で全然テストの自動化ができていないし、テストがしづらいのでモチベーションがあがらずにどうしたものかと思っているので、なにか参考にならないかと思いながら読んでいるのだが、なかなか難しそうだ。

今後新規にコードを書くときの参考にしよう。

やっぱり実際の業務にいかに適用していくかだよなぁ。
理想を追い求めてるだけなのかもしれないけど
実際うまいことwebアプリでテストを自動化できてるプロジェクトを見てみたい。
Railsなんかは標準でfixtureとかあるのでDB絡んだテストとか楽そうだけど、実際のところどうなんだろうとか。

仕様が固まっていない上に基本設計も曖昧
↓
実装
↓
バグ（or仕様変更）
↓
修正
↓
バグ（or仕様変更）
↓
修正（この間一切のリファクタリングなしなのでソースがスパゲティ化）
↓
完成
↓
そしてこのソースから仕様を拾い上げたドキュメント作成

ソースがまとまっておらずツギハギだらけで無駄な処理満載なのをそのまま日本語にしただけなので超読みづらい。

プログラマの仕事ってなんだろう。

誰も何を作ったらいいかわからないのだ。
誰も最終的な形なんてわからないのだ。

エンドユーザもしくは上流の人が仕様や要求を固め、
プログラマはその仕様や要求をメールなど証拠の残る媒体を使い詰めていき実装する。
もちろんおかしい点は指摘するし、それでも最終的な判断はプログラマにはない。

そうしてできた結果が美味しくないのだ。
誰も食えないのだ。

でもこっちは言われたとおりのものを作りました。
証拠もメールで残ってますよ。
とやったところで、一体誰が嬉しいんだろう。
二流どまりの仕事としてはそれでいいのかもしれない。

でもそんなの楽しくないし、空しいだけ。
だからアジャイルになるしかないんだと、最近特に思う。

そして、ここらへんの話は以下のドキュメントに通じるものだし
新しいソフトウエア開発手法
ソフトウェア工学とは何か

以下のエントリなんかにも通じる話だと思う。
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
仙石浩明の日記: 「ソフトウェア開発」は「モノ作り」ではない

結局そうなるべきだ、という結論に至るはずなんだけど。
何故だか業界的にこれは当たり前になっていない。
何故だろう。何故かしら。

masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針



このプレゼンは超同意しまくりで、プログラマ脳の人にとってはすごく理想的でプラグマティックな進め方だと思う。
自分が今の会社で悶々としていることはこのスライドのとおりやればほぼ解決されると思う。

でも今の自分の立場に置き換えて考えた場合、これはこのままでは絶対に無理だ。

そもそもmasuidriveさんのブログを好んで読んでいるような人たちとならあえてこのようにプレゼンしなくともうまくいく気がする。

トラックバック先で仕様書をどうやってsubversion管理するかと悩まれている方がいた。
そうwordやexcelは差分の確認ができないのだ。

それに対しmasauidriveさんはexcelは使わない方向らしいのだが
少なくともプログラマ以外の人にこれを強制するのはかなり厳しいと思う。
個人的にはtracやtwikiなどの変更履歴がすべて保持できるようなwikiで設計書を書くのが好きだが
若い世代はともかく（wiki慣れしているしこれから覚える世代なので）、非技術職の人や職業プログラマの人はほぼ納得してくれない。

やはりxdocdiffを試してみるべきか。

上記のようなことはmasuidriveさんも重々承知しているようで
masuidrive on rails » Blog Archive » 続masuidrive的プロジェクトの方針
において

この文章自体の前提が普通の会社の組織じゃないので、そのまま参考にはちょっとならないかもしれません。ただ自分の考えをプレゼンにするというのが、すこしでも普及してくれると嬉しいなと思ってます。プレゼン資料を作りつつ、脳内プレゼンをしていると、意外に抜けている自分に気がつくので。

　この対象のプロジェクトメンバーは波長の合う人を社内公募などで募って、そもそもこれを受け入れて一緒にやっていける人を前提に考えています。なのでかなり上段から見たような文章になっていますw ウチの会社自体は、とがった会社ではないので他部署で適用することは、あまり考えてません。

　私が個人でやってきた方法論が、どこまで組織で通用するのか、どこで行き詰まるのかを自分で楽しみにしてます。それを糧にもう少し一般化した方法論が書けないかなとも思っています。

と言うことらしい。

僕としてもどこで行き詰るのか、果たして行き詰らないのか、どうやったらそれなりの組織でも適用できるのか、などなどものすごく気になることだらけなので
これからも参考に追っていきたいと思った。

masuidrive on rails » Blog Archive » プロジェクトの始まりはTracから
なんかは実践的ですごく参考になる。
個人的におおっと思ったのは↓ここ

次にコンポーネントを変更します。

trac-admin ./ component rename component1 コード
trac-admin ./ component rename component2 仕様書
trac-admin ./ component add 会議 somebody

コンポーネントはうまく活用すればかなり色々対応できるんだなぁと思った。
あとはフローのカスタマイズがどれくらいできるかだなぁ。

ぼくとコンピュータ
を書こうと思ったきっかけになった記事がある。

世界が認める頭脳が集結したガレージ--検索エンジンのPFI - CNET Venture View

東京大学本郷キャンパスからわずか300m。とあるごく普通のアパートに、21〜24歳の若者6人が昼夜を問わず集う一室がある。外観からは全く想像もつかないが、約10畳分の広さしかないこの部屋こそ、2006年3月に設立された、有限会社プリファードインフラストラクチャーのオフィスなのだ。

　彼らは皆、東大・京大、および同大大学院の現役学生、もしくは卒業生。得意分野はさまざまながら、それぞれがコンピューターに関するきわめて高度な専門知識と技術を有する、ひとかどの開発者である。

　2002年度未踏ソフトウェア創造事業（IPA「独立行政法人情報処理推進機構」が、IT人材の発掘と育成を目的として、一般の開発者を支援する事業）で採択、絶賛された、フリーの仮名漢字変換エンジン「Anthy」の開発者もいる。まさに、頭脳集団という表現がぴったりだ。

ものすごく要約すると頭のいい人たちが作ったベンチャー企業の紹介記事なんだけど、この記事の最後の方にこうあって、

それぞれのメンバーのコンピュータとの出会いは「小学5年生の頃、親戚からMSX（1983年発売）の本体をもらったのですが、ソフトが何もなくて。遊ぶには自分でプログラムを書くしかないので、中学時代のすべての時間を、BASICに費やしました」「小学生のときに始めたパソコン通信です」「iアプリ」がきっかけで、プログラミングにのめり込みました」などそれぞれだ。

そう。コンピュータとの出会いは俺とあんまり変わらないのね。
でも

何この差！？

みたいな。

テクノなんか作ってる暇あったらコード書いてりゃよかったよ！！！




なんてことは全然思わないんだけど。
それでもなんか俺中途半端だなぁとは思う。
中学生の時に宅八郎になりそうとか言われて
ショック受けてる場合じゃなかった。
もっと突き抜けていけばよかった。

なんつってそれはただの言い訳です。

小学校5年生のときだったかな。
信長の野望というゲームがやりたくてやりたくて。
親には勉強になるから、
とかそんな理由で
MSX
正確にはMSX2+を買ってもらったのがきっかけ。

ほとんどゲームばかりにしか使っていなかったけど
MSX-BASICなる言語がついていたので
ローレル指数を測るだけのプログラムと呼ぶにはあまりにも稚拙なものを作ったりしていた。

中学校も2年か3年になって
金持ちなんだけどちょっと変な友達がパソコンを買い換えるってことで一緒に秋葉原まで行った時のこと。
アウトレットのコーナーで見かけたグレーのパソコンに一目ぼれした。
FM TOWNS
今でこそいろんなカラーバリエーションがあるけど当時はパソコンなんて白っていうかクリーム色しかなかった中、このパソコンはすごい珍しかったのを覚えている。

当時どうやって親を説得したかあまり覚えていないけれどもなんとかかんとか買ってもらったのだった。

相変わらずゲームもしてたんだけど、
TownsGEARというプログラミングなしで紙芝居的なゲームが作れるソフトが付いていたのでこれを使って遊んでいた。
脚本、絵、声、音楽、全部自分。みたいな。
すげーくだらない話だったけど友達にはそこそこ受けてたと思う。

ほいで、この頃にMMLというものに出会って音楽を作り始めるようになる。

高校1年でバイトしてシンセを買って電気やケンイシイに出会い、テクノに傾倒していく。

ヤマハのコンテストの最終選考に残ったり、雑誌に送ったデモテープが褒められたりして
『俺はいけるんじゃないか？！』
と勘違いしていた時期がこの頃。

インターネットに繋がるようになったのが
18,9くらいなの時かな？
もちろんwebサイト作りにはまる。
flashで少し遊んだりする。
htmlとかcssとかもろもろ学ぶ。

そうこうしているうちに何の因果かソフトウェア業界へ。
このとき24歳。
VBとかをいじっていました。

そして2年前にweb業界へ。


ということでプログラミング暦はまだ4年弱ですが
コンピュータで何かを作る暦は17年くらい？
とそこそこ長いのです。