楽しくもアホっぽい日曜日

モーニングコール。最初に思った事は、おなかすいたぁ。むにゃむにゃ。
ぱぱっと着替えて外へ。

お昼ご飯を求めてぶらぶらする。行った事のないお店を探す。
注文してからなっかなか出てこないけど、おいしい蕎麦を食べる。
相当気が向かないともう行かないだろうけど、また行く気がする。
待ってる時間も楽しくて、出てきた蕎麦もおいしかったから。

カバン探し。近隣のお店に見つからず。

突然の思いつき。家族へケーキを買って帰ろう。
気になっていたケーキ屋さんに行くと、中で食べられる事を知る。
モンブランをいただく。とてもおいしい。
家族へのお土産をすっかり忘れる。

ギターのチューナー片手に自宅へ。
カポタストの事をカッポリーヌと覚えてしまった私。
師匠にご指導いただきながら、チューナーの使い方を覚える。
ハーモニクスも分かってきた。ちょっとずつ上達中。

カッポリーヌを使って師匠に演奏してもらう。
押尾コータローの木漏れ陽。正直感動した！すばらしい。
見よう見まねで一小節弾くも遠く及ばず。
練習あるのみ。楽しい。

気づけば外は暗かった。
それから横浜へカバンと靴を探しに。
ていっていっ。即決。でももう一度探索する予感。

何度も通りかかるが、入ったことないお店で夕食。
手巻き寿司がおなかを満たしてくれておいしかった。
飛露喜があったので飲むも、微妙。
保存状態が悪いのか、種類が違うのかイマイチ。

その足で松屋へ。食べすぎ。アホっぽいけど楽しく笑った。
帰りの電車。満腹感が幸せすぎて目が覚めると地元の駅。
降りようと思う前にドアが閉まる。プシュー。あちゃちゃ。

やたら楽しい１日。すごくアホっぽいけど楽しい楽しい。
いいなぁと思うくらいなら、一緒に遊びに行ってみませんか？
終わってしまう日を惜しみつつ、明日からのやる気を出す。

まったく無理のない時間はとても楽しい。

ThinkPad移行間に合わず

残念！というほど念入りに移行作業してたわけじゃないけれど、環境の移行がさっぱり終わりませんでした。今日の仕事は考え事と資料作りのはずなので今の状態でも十分仕事ができるはず。必要になったらその都度ソフトを入れることにしよう。

ほんとにキーボードが打ちやすいなぁ〜こりゃ惚れるよね。

晴れた朝

おはようございます！今日は雨の影もまったく見えなくて、暑いくらいに晴れましたね。朝のテレビじゃもう梅雨の話が出ていましたけど、鹿児島の話でした。関東が梅雨入りするのはいつですかね〜。来ないか、なるべく早く明けてくれるといいなぁ。地球にとって恵みの雨でも、私にとってはなにかとせつない気持ちにさせてくれるものなので、なるべくなら晴れた青空を見ていたいですね。

さて活気あふれる月曜日の朝。今週もはりきっていきましょー！

VSSのビューが重いのは

間違いなくアンチウィルスのせいだと思います。切るとすごい早いですもん。でも0.5秒なのか0.1秒なのかの違いくらいので気にならないっちゃ気にならないですが、ウィルスソフトのせいでマシンが遅くなってるのを感じるとスペックがもったいない気がしますね〜。

使っているのはNortonなんですけど、信頼性があって、OSに負担をかけないウィルスソフトは無いかしら？いろいろと情報はありますけど、少しでも重たいという事自体は変わりませんから。一番いいのはホストOSをLinuxにすることかなぁ。でもそうするとVSSが使えない…。マシンの体感速度を上げる欲望はつきませんね〜。

injectDependency

MLで盛り上がってる話題。読んでいるだけでも楽しい(笑)S2OpenAMFを作った時にFlash Remotingから呼び出される最初のコンポーネントにコンポーネントをインジェクションするにはどうしたらいいかなぁと思っていたんですが、これがあれば簡単ですね。

というのは、Flash側から呼び出されるクラスはdiconに書かなくても呼び出せるようにしたいと思っていて、そのクラスにコンポーネントがインジェクションされるのがいいなぁと。S2StrutsのActionとServiceの関係のように。Flashから直接呼び出されるクラスは各コンポーネントの入り口であってほしい。何を夢見るかと言えば、S2Strutsで作ったシステムのフロントをFlashに置き換えても、パラメータさえしっかりしてれば呼び出せちゃうような。

実はそういうのを実験的に趣味で作ってるアプリでやっていて、Flashで作ったほうが使い勝手が良いんだけども、HTMLによるインターフェースもあるといいなぁと。どちらにせよFlashで使われる事を意識してシステムを作らないといけないですけどね。ちゃんとビジネスロジックへの入り口が分離されていればできるはず。Actionを直接叩くのは無理だけど、S2StrutsのActionのPOJO化を使っていればとても可能だと思う。

精度の高い見積もり

後工程になればなるほど正確になるし、全てが終わった後に出すのが狂いがない。終わった後だとそりゃ見積もりじゃなくて実績ですが…。早い段階から精度の高い見積もりを出そうとすればするほど大変。何が大変って概算出すための見積もり根拠を作る事が大変。たとえ予算をオーバーしてしまう概算が出ても、根拠が納得できるものならば、機能の縮小か予算の増加が見込める。根拠のある見積もりに対して、機能を減らすか、予算を増やすか。大抵予算は増えない。機能は増える。工数も増える。それを予算と期間の内に収めるための努力をするわけだ。

見積もりってのは人月やらステップ数でポンと出るほど今のシステムは予測が簡単じゃない。そろそろCOBOL時代の見積もり方法から…。

見積

実績から予測が立てられる見積は楽なんだけど、いろんな率を計測して、そっから計算で出さなきゃいけないのがめんどくさい。全機能分やったらそりゃ結構正確に出るだろうけど…見積作ってる工数はどこに含まれるんですかぁー(笑)

実績ってのは結局、画面の項目数とイベントの重みと入力チェックの数と実際のソースコードの行数と開発期間などなどを計算して比率を出して、おのおのの画面を計測して、平均値を出して…。最後にリスクを乗せておくと結構正確になる。比率だけで計算するとまったくゆとりのない過小見積になった。前例があるから、その率が正確なのかどうかも根拠があるしね。

あんまりこういう見積もりの仕方は聞かないけど、プロジェクト初期の概算見積もりにしちゃ、大枠は捕らえているはず。これが正確かどうかなんて終わってみなけりゃ誰も分からない。こんなにしっくりこない作業だったかなぁ。っていうか、平行稼動してるサブシステムをベースに見積もりを考えるなんて初めてだ。大きくズレていたら高すぎると必ず言われるプレッシャーは…ほむぅ。