■
結局、Meadow3に逆戻り。
2より3のほうが手間がかからなさそう。
なんですけど、フォント設定を保存できなくて泣き。
ms-fonts-jaを入れて、mouse-set-fontでフォントを
選べるようにはなってるんですけど、その設定を
保存できないんです。
set-default-fontがそれっぽいんで：
(set-default-font "MS Gothic 12")
とかやってみたんですけど、フォントが見つからない
っていわれるんです。
どうもフォントのデータを作るより.emacsのほうを
先に読んでるっぽい。
- -
あかん。せっかく教えていただいたshell3ですけど、
Cygwinのbashで動きません。
cmd.exeでも補完できるのは1階層だけです。
やっぱりMeadow入れるしかないですか。
つか、shellモード多用する自分が珍しいんですかね。
便利なんですけどねぇ。
- -
あれ？ 消されちゃったかな。それとも自分の勘違いか。
似たようなことは何度も書いてる気がするんですけど、
気にしないで。
「技は力に宿る」っていう大山総裁の言葉がありますよね。
それはそれで非常に納得のいく話なんですけど。
でも、だからって、老いたらダメとか、老いたら成長しないとか
（変な日本語ですけど）ってのとは別の話でしょう。
老いたら老いたで枯れた芸を見せる。これは佐川先生の
言葉でしたかね。ちょっと記憶が曖昧ですけど。
武道を嗜む者であれば、結局、生涯鍛錬でしょう。
その鍛錬ってのは、決して現状維持のためにやるんじゃなくって
新しい境地を開くためにやるもんでしょう。
武道でも「師を超える」というのが１つのテーマですけど、
そのためには人に教えないといけないですよね。
師というのは人を教える人なんですから。
鍛錬というのは、そういうことも含んでるんだと自分は
思っています。
■
お、ありがとうございます。shell3、試してみます。
- -
結局さぁ、みんなさぁ、プロレセスなんて
どうだっていいって思ってんじゃないの？
いや、それが悪いってわけじゃなくって、
いや、それって悪いんだけさ、
まぁ、仕方ねぇのかなってさ。
だったらさ、無理矢理巻き込むしかねぇじゃん？
結局、プロセスなんてさ、やってみねぇと
わかんないじゃん？
だったら目の前で見せりゃいいだけの話でさ。
四の五のゴタク並べるよりさ。
でさ、ときどきポロッとウンチク垂らしてさ。
XPE2に出てるけどさ、価値判断っつーのはさ、
センスなわけ。
センスってのは理屈じゃないわけ。
パッと見て、それがいいか悪いか判断できないと
ダメなわけ。
そういうセンスってのは、まぁ、先天性の場合も
あるんだろうけど、そうじゃなかったら、
体験して身につけるしかないじゃん？
- -
でさぁ、コードの品質もさぁ、おんなじだと
思うんだよね。
いいコードっていうのを知らなきゃ
いいコードなんか書けるわけねぇじゃん。
まぁ、いいコードってのも理屈はいっぱい
あるんだけどさ。
でも、そんなことよか、やっぱ肌で知ってないと
ダメだと思うわけ。
だから、オレは写経を勧めてるわけ。
はっきりいって、コード読むだけなんてのは
退屈だしさ。だったら手を動かして、手に
覚えさせたほうがいいじゃん。
なんつーかな。どっかのプロジェクトの
コミット権限もらえるくらいじゃないと
ダメじゃん？
はっきりいって仕事で見るコードなんて、
どれもコミット権限もらえなさそうなの
ばっかしじゃん。
なんでゼニもらってるほうのコードが品質
低いんだっつーの。
■
何回か書いてますけど、XPには品質の値と
いうのは２つしかありません。
「悪い」というのはもちろん論外。
「十分」というのでも不十分。
「良い」というのでもまだまだ許せる値じゃない。
「すばらしい (excellent)」か
「とてつもなくすばらしい (insanely excellent)」
の２つしか品質の価値として認められません。
excellentあるいはexcellenceというのはXPE2でも
キーワードの１つになっています。
improvementというのがXPE2のprincipleの１つな
わけですけど、それはexcellenceに向けた努力な
わけです。それは品質に限らず、チームの存在として
excellentであるということを目指しているわけです。
- -
血圧 92-64
- -
世の中には「協力会社」という言葉があって
自分はこれを「下請けだと人聞きがわるいから」
という理由で生まれたものだと思っています。
でも、今は、ほんとに「協力」という体制を
会社という単位を超えて築かなければならない
時代なんじゃないかと思うようになりました。
今はもう総力戦の時代なんじゃないでしょうか。
そのためには、元請けも下請けも考え方を
改める必要があるんじゃないでしょうか。
ことソフトウェアということに関していえば、
元請けと下請けとで技術的な実力差は
なくなっています (高速道路理論)。
むしろ、下請けのほうが技術力を持っている
ことも多いでしょう。
そうした状況を踏まえれば、今必要なのは、
会社という単位を超えて、どれだけプロジェクトに
貢献できるかという視点です。
もちろん、元請けには元請けの、下請けには
下請けの事情というものもあるでしょう。
でも、今は総力をあげて問題に取り組まなければ
勝てない状況なのです。なぜなら、競争相手が
総力戦を仕掛けてきているからです。
オープンソース、オフショア、そういった
外部の力をどれだけプロジェクトに取り込めるかが
勝ち負けを決める重要な要因になっているんじゃ
ないでしょうか。
■
Meadow2は設定が面倒だし、Meadow3はモッサリしてるし、
というわけでxyzzy。
(require "isearch") (setq c-indent-level 4) (global-set-key '(#\C-x #\h) 'mark-whole-buffer) (global-set-key '(#\C-x #\r #\t) 'string-rectangle) (global-set-key '(#\C-x #\r #\k) 'kill-rectangle) (global-set-key '(#\C-x #\r #\y) 'yank-rectangle) (setq *eshell* "bash -i")
何か気づいたらまた書き足す予定。
■
あれはフェイントだったりしてな。
- -
見積もりのポイント。
たとえば1日2ポイントでストーリー群を見積もる。
たとえば、Aというストーリーは1ポイント (2日)、
Bというストーリーは2ポイント (4日)、
Cというストーリーは4ポイント (8日) と見積もられたとする。
これで実際に開発しはじめて、実際に1ポイントが2日に
なるかどうかは結構バクチが入る。実際には1ポイントが
1日になるかもしれないし、3日になるかもしれない。
でも、A, B, Cのストーリー間の相対的な難しさの予想は
それほど間違ってはいないことが多い。つまり
A : B : C == 2 : 4 : 8
というのが難しさの比率ということになる。ここで
もしポイントがズレて1ポイント1日になったとすると、
その日数は：
A : B : C == 1 : 2 : 4
ということになり、1ポイント3日になったとすると、
その日数は：
A : B : C == 3 : 6 : 12
となる。
このように、見積もりと計測を繰り返すことで、
プロジェクトの速度というものがわかる。
プロジェクトの速度がわかれば、計画の精度も
上がる。
- -
上に書いたことを裏返して見れば、見積もりというのは、
ごく私的なものだということがわかる。
1ポイントが何日に相当するかはプロジェクトごとに
違って当たり前ということ。
大事なのは、見積もりと計測を繰り返し続けること、
そして計画を修正し続けること。
■
jitu.org宛てのメールがエラーになる件は
鋭意調査中です・・・といいたいといところ
ですが、もうちょっと待ってもらわないと
満足に調査すらできません。
というか、メールもロクに読めないのが現状です。
