2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2006年09月30日

http://itpro.nikkeibp.co.jp/article/OPINION/20060113/227252/

偽装請負で問題になるパターンは、いわゆる『SES契約』の
場合なんでしょうね。SES契約っていうのは:

http://www.ki-ra-ra.jp/corporaterisk/04/special02.php

に書いてあるように、実際の形態は派遣に近いんですけど、
法律上は請負に分類されるはずです (このページでは
『準委託』という言葉が使われてます)。

なんでこんなことを書いてるかというと、やっぱりXP
がらみです。XPでSES契約やったら違法なの?っていう
疑問です。

上の日経のページで紹介されている東京労働局のページ:

http://www.roudoukyoku.go.jp/campaign/guide/checklist.html

いくつか条件があがってますけど、勤怠管理とかそう
いうのは会社がきちんとやればいいだけの話なんで、
あんまり興味がありません。で、話の都合上、一番下に
あるのから取り上げますけど:

  4 単に受託者が肉体的な労働力を提供するものとはなっていないこと。

これは、ソフトウェア開発ならほとんど問題にならない
でしょうね。それこそ写経並みにコードを書き写すような
ことでもしない限り、肉体的な労働ということにはならない
んじゃないでしょうか。

で、一番最初の条件に戻って:

  1 作業に従事する労働者を受託者が指揮監督するものであること。

    (1) 労働者に対する業務の遂行方法に関する指示その他の管理を受託者が
        自ら行っている。

とあって、そのチェック項目として気になるのをあげると:

  * 発注者からの業務依頼に対し諾否の自由があり、業務遂行の過程における
    裁量が認められていることを発注者及び受託者、双方の責任者及び業務に
    従事する労働者が認識している。

というのと:

  * 受託者は仕様書等に基づき自らの判断で業務を処理している。

この2つ。まず、『諾否の自由』ですけど、これは
Accepted Responsibilityで解決できているはずです。
まぁ、お客さんにいわれたら、そうそう断れるものじゃ
ありませんけど。でも、ストーリーが出されるときに、
そのストーリーの実現可能性について意見をいうことは
できるはずです。

で、下の『仕様書云々』というヤツ。これはストーリー・
カードが仕様書ということになるでしょうね。で、その
ストーリーの実現方法まで発注者が詳細に指示してたら
ヤバい。まぁ、XPではそういうことは滅多にないでしょう。
というか、そこまでやってたらXPという皮をかぶった
別物でしょう。

また順番が前後しますけど、ちょっと気になるのが:

  * 作業スケジュールの作成や調整は、受託者自らが行い労働者に指示をして
    いる。

これもまた、見積もりはプログラマが出すことに
なってますからOK。もちろん、プロジェクト全体の
スケジュール (たとえばサービスインの日付) というのは
発注者が決めるわけですけど、それは完全な (客先常駐
しない) 請負でも同じことです。

ここまでは話を単純にするために孫請けなんかは考えないで
書いてきました。これに孫請けがからんでくると、かなり
グレーかもしれません。孫請けの労働者が朝会に出るのは
『発注者が直接指示を出す』ことに当たらないのか?
とか、結構ややこしそうです。

XPという形を取っていても、法を犯すことはできます。
だからこそ、XPの精神を大切にしないといけないわけです。
それがHumanityであったり、Mutual Benefitであったり
するわけです。XPの精神というのは非常に常識的です。
だから、『それが法律だから』という価値判断で動くのでは
なく、『それがXPの精神だから』という価値判断で動いて
ほしいものです。

--

というようなことを考えさせられる方法論がかつて
あったか? それをもってしても、やはりソフトウェア
開発はXPによって新しい局面に突入したといわざるを
えない。

本家Permlink


2006年09月29日

tokuhiromさんが:

http://d.hatena.ne.jp/tokuhirom/20060929/1159497567

  自動化テストを書かずに、手でテストしてしまうほど
  勤勉で (あって) はならない。

って書いてて、『ああ、そうか』と思ったんですよね。

それまでは『勤勉』のニュアンスがイマイチわからなかった
んですけど。

結局のところ、『勤勉』の反対が『怠惰』であって、
それはいわゆる『プログラマの三大美徳』のことを
指しているのであって、とどのつまり『勤勉』って
いうのは『非/反ハッカー的なもの/人』ってことなんで
しょうね。

でも、C++とか見てると、とても勤勉な人のための
言語には思えませんけどね。それから、Java程度で強い
静的型言語とかいわれても。Genericsが導入されたのは
つい最近の話で、それまではダウンキャストが当たり前の
ように使われてましたからね。前からいってますけど、
Genericsにしても、型推論がないと手間がかかりすぎます。

Javaが勤勉の人でも使えるようになったのは、GCの
おかげでしょう。GCの効果はJoel氏もいってますよね。
それと、C++に比べて制限が多いこともあります。これは、
会長がPHPについて評してるのと同じ理由です。となると、
やっぱり静的型の効果って、文法チェックくらいしか
ないんじゃないの?っていう疑問が湧いてきます。

最近ちょっと思うのが、『大規模のために!』とか
いわれてる静的型言語ですけど、規模が大きくなるほど
動的に評価せざる得ない部分が増えてくわけで、それって
矛盾してるよなぁと。

これは当たり前の話で、規模が大きくなれば、それだけ
越えなきゃいけない境界が増えるわけで、境界を越えれば、
その言語が想定している型観が崩れちゃうわけです。
ネットワーク、DB、XML、どれ1つとっても、型を保証
するものなどないですよね。誰かが泥をかぶって
幻想を見せているに過ぎません。まぁ、それをいって
しまえばOOPそのものも幻想ってことになっちゃいます
けど。

--

あと、DBに詳しい人ほどDBを静的なものと考えてる
みたいですね。つまり、一回作ったらもう作り直せない
ものとしてDBを捉えているようです。

O/Rマッピングにしても、それで手に負えなくなったら、
別のやり方に変えればいいじゃんって自分は思うんです
けどね。

早すぎる最適化はダメだってことは、みんな知ってる
はずなのに。

初期投資をデカくするのもダメだってことは、みんな
知ってるでしょう。知ってて、知らないフリしてる
んでしょう。

なんかおかしいですよね。前にも書きましたけど、
もし今のDBが静的なら、そんなものを使ってビジネス
するほうがおかしいですよ。これだけ変化の速い
世の中で、DBだけが安穏と変化から守られていいはずが
ない。

--

えーっと、話を戻しますけど、Rubyの場合、『品のいい
eval』が数多く用意されてますよね。誰かの日記に
コメントしたんですけど、文字列からクラスを起こす
ときも:

  class Foo; end
  Kernel.const_get("Foo").new

みたいにしたら、生のevalよりずいぶん安全です。
(他にもっといいやり方があるかもしれません。)

だから、結局は教育とか学習の話になっちゃうんじゃ
ないかと。__send__を見つけるなら、それだけじゃなく
って、他のやり方も見つけてほしいですよね。それが
本当の『勤勉』であり、それが行く行くは『怠惰』に
つながるわけですから。

--

う〜ん、商業ベースというか、商業サイト並みの品質と
いうか、集客力というか、そいうのを求めてるんなら、
止めるしかないでしょうね。ムリですから。

自分も、『会長のお言葉』とHotLinksくらいしか目を
通さないんですけど (笑)。でも、このどっちとも、
今のるびまでなきゃあり得ないものですよね。絶対に
商業ベースじゃ読むことのできない類のものです。
ニッチといわれれば、それまでですけど。

雑誌は壊滅状態なので、Webサイトに限定しますけど、
それでも1つの言語に特化したサイトって、いくつも
ありませんよね。www.javaworld.comとwww.perl.com
くらい? ``C/C++ User Journal''でさえ:

  http://www.ddj.com/dept/cpp/cuj.jhtml

に書かれているようにDDJに吸収されて、しかもその
DDJでさえ紙から撤退した代物です。

--

Ruby学会でも作りますか。

どういう条件があれば学会を作れるか知りませんけど。

学会だったら事務を代行してくれるとこはいっぱい
あるんでしょう? 会費も集めやすくなるでしょうし。

学会によっては民間人も参加できましたよね?

本家Permlink


2006年09月28日

しかし、松本ぷりっつのブレイクぶりは『一体何が
起こったの?』ってくらいビックリ。

保育園の4コマも嫌いじゃないし、ヲタ兄と妹のもわりと
好きなんだけど、やっぱり3姉妹のほうが面白い (笑)。

いや、松本ぷりっつじゃないんですよ、書きたかったのは。

つげです。柘植文の『ノンストップ おヨメ道』です。
これがないんだ、近所の本屋に。もう仕方ないから
Amazonですよ。

ああ、子育てものなら宇仁田 ゆみの『よにんぐらし』も
わりといい。っていうか、最近面白くなってきた気が
する。前まではお母さんが主役だったんだけど、それが
子どものほうが主役になってきて、特に長男のアホ顔が
すばらしい。まぁ、自分の場合、コミック買うほど
好きってわけじゃないけど。

それから『ハルコビヨリ』、新しいの出てるから。

--

前にちょっと書いたことありますけど、『べりえ』は
『ベリエ』。正しくは『ベリ工』。つまり、Berryz工房
のこと。

http://ja.wikipedia.org/wiki/Berryz%E5%B7%A5%E6%88%BF

『べりえ』っていうのは自分が勝手に呼んでるだけです。

なんか『べりえ』っていうのと『どうて』(笑)
ってのがいるらしいですけど、違いはよくわかりません。

Railsの話には結構ツッコミがあるのに、べりえのときに
ツッコミがついたのを見たことがない。いわゆる
ドンビキ (笑)。

ちなみに自分はヲタの言動を読むのが好きです。ダテに
BUBKA読んでません。最近、掟ポルシェの出番が少なく
なってとってもさみしいです (笑)。

本家Permlink


2006年09月26日

タイムスタンプを手動で押すのはメンドイ。忘れる。
だったら、ファイルを開いたときとファイルを閉じた
ときの時間を記録すればいいんや。これやったら、
作業が終わったときにファイルを閉じればいいだけ
やんか。

でも、それが難しいんやな (笑)。ワテの場合、Emacsは
立ち上げっぱなしやさかい、ファイルも開きっぱなしの
ことが多いわけや。まあ、ちょっとは努力せなアカンと
いうこっちゃ。

;; record find-find and kill-buffer

(defvar tko-buffer-db (expand-file-name "~/.buffer-db"))

(add-hook 'find-file-hooks 'tko-record-find-file)
(defun tko-record-find-file ()
  (tko-record-buffer-file "open"))

(add-hook 'kill-buffer-hook 'tko-record-kill-buffer)
(defun tko-record-kill-buffer ()
  (tko-record-buffer-file "close"))

(defun tko-record-buffer-file (open-or-close)
  (let ((filename (buffer-file-name))
	(database (find-file-noselect tko-buffer-db)))
    (if (and filename (not (string= tko-buffer-db filename)))
	(save-current-buffer
	  (set-buffer database)
	  (end-of-buffer)
	  (insert (format "%s %s %s\n" open-or-close filename
			  (tko-date-and-time-string)))
	  (save-buffer)))))

(defun tko-date-and-time-string ()
  (let* ((time (current-time))
	 (dow (week-abbrev time))
	 (fmt (concat "%Y-%m-%d " dow " %H:%M:%S")))
    (format-time-string fmt time)))

.buffer-dbとかいうバッファが常駐することになる
んやけど、それはカンニンやで。

あ、でも、これ、Emacsがいくつも立ち上がってたら
うまくいかんとちゃう?

考えすぎ。こういうときは:

(defun tko-record-buffer-file (open-or-close)
  (let ((filename (buffer-file-name)))
    (if filename
	(shell-command (format "echo %s %s %s >>%s" open-or-close filename
			       (tko-date-and-time-string) tko-buffer-db)))))

で十分。logger使えばタイムスタンプすら必要ないけど。

--

loggerで出力先ファイルを指定できるみたいなんだけど、
使い方がよくわからん。

--

しかし、上みたいに『結局echoかよ!』っていう
ときは、すっげぇ惨敗感があるよな (笑)。
だからElisp嫌いなんだよ。

本家Permlink


2006年09月25日

ひっさしぶりにアッタマ来た。

『やっぱりぐ〜ぐるすごいよね〜』って、バカか?

そいつがチキンなだけだろ。

こっちだってなぁ、学歴低いしバカだから、いっつも
周りは頭のいい人ばっかりだよ。

失うものが大きい? バカいうな。こっちは今の仕事
なくなったら野垂れ死だよ。そっちはおフランスに
帰ったらいくらでも仕事あるんだろ? 学歴社会で
高学歴者様なんだからよ。

オレはよぉ、こういうヘタレなんかよか、家族抱えながらも、
転職しようかどうかで悩んでる人を応援するよ、断然。
そして、そんな人は世の中いっぱいいるだろ。

そんなにビビってんなら国帰れ。帰って退屈にまみれて
死ね。

Googleを崇め奉るにもホドがある。

--

前田日明はUWF設立のとき『選ばれし者の恍惚と不安、
二つながら我にあり』といった。

アントニオ猪木は『戦う前から負けることを考えるヤツが
いるかよ』といった。

イビチャ・オシムは『リスクを取るという価値観を
共有したい』といった。

松坂大輔は『今日で自信から確信に変わりました』と
いった。

野茂あるいはイチローがメジャーに行くとき、不安は
なかったのだろうか? いや、そんなはずはない。しかし、
彼らはその不安に勝った。勝ったからこそ活躍したのだ。

本家Permlink


2006年09月24日

う〜ん、困った。
g++ + Emacsとかで開発してる人たちって、どうやって
ビルドしてるんですかね?

Makefile書くのタルいっすよね。Rakeでもそれは
変わんないし。要は*.cppと*.hとの依存関係を書くのが
メンドイんですよね。

候補をあげればEclipse CDTですか。

http://wiki.eclipse.org/index.php/CDT

まあ、これでもいいんですけど。もうちょっと調べて
みると:

http://www.a-a-p.org/index.html

なんてのもあります。こっちはPython。

上のところに:

http://www.a-a-p.org/tools_build.html

なんていうページがって、ビルド・ツールの一覧が
コメント付きで載ってます。

他にはTrollteckのtmake, qmakeあたりですか。

MozillaとかOOoの人たちはどうしてるんですかね。

AAPでも試してみますか。

--

AAP、Debianだとsidのですらちょっと古い感じ。1.072。
最新のは1.088なんだけど。

でも、この感じだと、あんまり活発な活動じゃないみたい。
1.072でさえ2004だし。

やっぱEclipse CDTですかねえ。

今回は.debで入れてみますか。

--

はあ?

『阪神優勝』のことをこの人はご存知ないらしい (w
弁理士なのに (w

東スポなめんなよ。

--

http://d.hatena.ne.jp/ksh/20060920/1158763911

デスマーチっていうのは、士気が著しく低下した状態な
わけですよね。だから、そこから抜け出すには士気を
高めるしかないわけです。一般的にいって、それは非常に
難しいことなんですけど。

士気を高めるためには相互にコミュニケーションを図る
というのが1つ。それと、誰かがリーダーシップを発揮
するというのも1つ。他にもあるでしょうけどね。

ただ、繰り返しますけど、士気を高めるっていうのは
非常に難しいし、時間がかかります。だから、大抵は
タイムリミットが来ちゃいますよね。プロジェクトを
中止するか、少なくともメンバを総取っ替えするか。

ガラクタを納品して形だけでも整えることはできる
でしょうけど、それって詐欺でしょう。

だから、結局はデスマーチにならないことが最善にして
唯一の対策ってことになります。デスマーチから抜け
出せる確立はそれほど低い。

--

いや、自分がいってるのは、なんでWebデザイナと
呼ばれている人たちがコードを書いちゃいけないのか?
ってことなんです。

少なくともプログラマはHTMLやCSSのことは知ってるし、
無難なページならなら書けるわけですよね。だったら、
Webデザイナだって、無難なコードなら書けるでしょう。

だったら何もわざわざ使いにくいToy Languageなんか
使わなきゃいいでしょう。双方にとってメリットなんか
ないですよ。

人がいない? そんなもん、そういう仕事を発注して
ないだけでしょ。

ああ、Javaで書けっていうのはさすがにナシかも (笑)。
心理的抵抗が高そうですし。でも、PHPとかなら今どきの
Webデザイナは書けるでしょうし、JavaScriptだって
必須の知識でしょう。で、JavaScriptと他の言語、
たとえばRubyとかPythonとかと何が違うの? 何も違わない
でしょう。

--

今、essaさんのを読みはじめました。

だからいってるじゃん。Webデザイナもコード書けって。

--

自分はDBの重要性っていうのをよく知らない、別の言い方を
すれば、コードの設計と同程度に重要だと思ってるし、
それと同じように、DBも、コード同様、リファクタリング
できるもんだと思ってるんですよね。

それから、もし業務が複雑すぎてコードが複雑すぎる
ようであれば、やっぱり業務を単純化できないか考え
ないとダメですし、それと同じことがDBにもいえると
思うんですよね。そこまで踏み込むのがXP2でしょう。

--

あははは、そんなことで怒りませんよ。マリーシア重要
ですから。agileを導入るときの方便なんて何いっても
いいです。

ただ、TDDを品質を上げるためにやるって本気で思ってる
人がいるなら、ちょっと考えを改めてほしいですけどね。

TDDは、ボトムアップとかトップダウンとかと同じような
プログラミングの考え方であると同時に精神安定剤
みたいなものです。品質が上がるのはそのオマケみたいな
もんですね。ダメなテストはいくらでも書けますから。

もちろん、agile自体も製品の品質を上げるためだけに
あるのじゃなしに、組織そのものの品質を上げるために
あるものだと。だって、極端な話、製品の品質が悪くっ
たって、利益が上がればいいわけですから。もちろん、
ほとんどの場合、品質と利益は強く結びついてますけど。

--

ここで語られている像と違うかもしれませんけど、
勤勉なプログラマの話。

なんかヘンなんですよね。独特のコーディング・スタイルを
カッチリ守ってたり。『おまえそれやりすぎ!』って
くらい高度に抽象化されたコード書いてる割には、
ローカル変数の初期化を忘れてたり。

まぁ、全部が全部同じ人が書いてるわけじゃないので、
レベルに違いがあるのは当たり前ですけど。それにしても
ヘン。

なんなんですかね、ああいうのって。

宇宙飛行士症候群っていっちゃえばそれまでなんですけど。
でも、ちょっと違う気もします。勝手に想像すると、
コーディングが楽しくなかったんじゃないかと思う
んですよね。

『コーディングは下等生物のやることだ』みたいな
教育を受けてたのかもしれません。あるいは、仕様を
ポンと渡されるだけで、自分の創造性を発揮できない
現場だったのかもしれません。

まぁ、でも、彼らには仕事をやり通すだけの勤勉さは
あったわけです。だから、出来上がったものはダメって
わけじゃないんです。そのあたりがまたビミョーで。
動いちゃってるわけです、現実に。

あと、自分がこういうことを書くのもアレですけど、
視野が狭いのかなぁと。他の言語とか興味なさそう。
勤勉だから、自分の仕事で使う言語しか興味がない。

--

いやぁ、自分、読み返さないんですよ (笑)。前は書き
捨ててたくらいですし。今でも読み返すことは滅多に
ありません。

それにしても、みんなessaさんのとこ、よく読んでるなぁ。
オレなんかむつかしい話になったり、量があったりすると
すぐ読み飛ばしちゃうから (笑)。だから、インタビューも
後半は頭に入ってない (笑)。

--

つか、べりえのときにもツッコミ入れろよな、おまえら (笑)。

本家Permlink


2006年09月21日

変化は必ず起こるものならば、その変化にどう対応するかが
重要な問題になる。そして、変化は、ある程度の傾向は
あるにしても、そのときの状況ごとに違うから変化で
あって、だとすれば、その変化への対応も、そのときの
状況ごとに違ってくる。

ここでいう変化への対応というのは、具体的にいえば
実践ということになるわけだが、大切なのは変化に対応
することであって、実践を実践することではない。見当
違いの実践を選んでしまっては、結局は変化に対応
できていないことになる。

変化は無限にあるから変化であり、したがって、その
変化への対応である実践も必然的に無限個必要になる。
ただし、開発という限られた範囲内での変化ではあるので、
無限といっても自ずと傾向はあり、ゆえに、1つの実践で
多くの変化に対応できることもある。逆に、典型的な
実践では対応できない変化もあるだろう。

かといって、未熟なうちに無手勝流で変化に挑むわけにも
いくまい。未熟なうちには型が指針となり、その型と
いえるものが典型的な実践ということになる。

典型的な実践を経験し、自分で工夫を加え、そして
実践を忘れ、万の変化に自然と対応する。それが守破離
ということになるだろう。

本家Permlink


2006年09月19日

http://kameda3.seesaa.net/article/23137658.html

--

コードは動かすものだ。

なぜなら責任の分配が設計の主な目的の1つだからだ。

そのためにはコードは細切れになってなきゃいけない。

だから、たとえ一回しか実行されないコードの塊でも
メソッドに切り出す。

メソッドに切り出すことで責任を明らかにする。そして、
その責任が今そこにあるべきなのかを疑う。

本家Permlink


2006年09月18日1

自分、お菓子はやってたんですよ。効果があるのも
知ってます。それでもああいうことを書いてるんです。

お菓子をやるときに気をつけないといけないことを
ちょっと書いておきます。

1つは費用の問題。誰かがお金のことで文句をいうようなら
止めたほうがいい。お菓子は気持ちの問題が大きい
ですから。もしあなたがお菓子を始めようとしているなら、
あなたが負担しないといけない。特定個人が負担するほうが
みんなで出し合ったりとか、会社が出すより効果があると
自分は信じています。そのうち、他の人も買ってくる
ようになります。

グリコとかの置き菓子っていうの? あんなの全然楽しくない。
定番っていうのはあるんですけど、そればっかりじゃ
つまんないし、会話が弾まない。新製品が出たらとりあえず
買ってみて、『どうよ?』くらいのネタにしたほうが
楽しいじゃないですか。

それと、女性に多いんですけど、お菓子を自分の机に
もってっちゃう。ペアを組んでればまた別なんですけど、
そうでないとこういう現象が起きます。それでも効果が
ないわけじゃないんですけど、やっぱりちょっと
落ちますよね。何のためのお菓子なのかをもう一度
考える必要があります。

仕事柄、手が汚れるのもできるだけ避けます。ポテチとか (笑)。
ちなみに、自分の定番はソフトサラダと歌舞伎揚げでした。

何度も書きますけど、お菓子程度だったら、同じ重要度の
実践はいくつもあるでしょう。shared meal、水の入った
ビン、手を叩くための定規とか。ペアのとき、手持ち
無沙汰を紛らわせるための扇子とか (笑)。1つのことに
こだわらず、何でも試してみたほうがいいでしょう。

本家Permlink


2006年09月18日

予兆みたいなのはあったんだけどさ。
日曜だっていうのに東スポ売ってたし。
なんか車もまばらだなぁって思ったんだ。
駅にも人少ないしね。

本家Permlink


2006年09月17日

JBのビデオは結構あるんだけど。たとえば:

http://www.youtube.com/watch?v=G45u17vaUCM

とか。でも、見たかったのはJB'sなんだよね:

http://www.youtube.com/watch?v=VUMmd_fTEIA
http://www.youtube.com/watch?v=znWWriNzZnE

やっぱ、もうちょっと前の、全盛期のころのが見たいなぁ。

http://www.youtube.com/watch?v=ctYOU4U62v4

しかし、Bootsy (笑)。

本家Permlink


2006年09月16日

http://www.youtube.com/results?search_query=%E9%AB%98%E6%A9%8B%E3%83%8A%E3%82%AA%E3%83%88+vs+%E3%83%9E%E3%83%BC%E3%82%AF%E5%A0%80%E8%B6%8A&search=Search

亀田とは比べものにならんくらい『ボクシング』
してるよな。まぁ、比べるほうがおかしいんだけど。

http://www.youtube.com/watch?v=uMrYmshl82Y

これを見ても、タイソンは上半身のディフェンスが
抜群だったというのがわかる。両腕で頭をカバーして、
ノッシノッシと相手に近づいて・・・なんてのが
通用するほど世界は甘くないだろう。って、それが
通用しちゃったんだけど (笑)。

本家Permlink


2006年09月15日

前にもおんなじことをおんなじ口調で書いたような
気がするので消す。

テクノロジがプロセス、さらにはビジネスを直接的に
支援するという動きはRailsだけのものじゃない。MSの
ソフトウェア・ファクトリもそうだし、Eclipseにも
そういう流れがあるはずだ。

しっかし、単純な機能の比較はJ2EEでコりたんじゃ
なかったのかねぇ。

本家Permlink


2006年09月12日1

そりゃないよ、でおじゃる。

--

なんでそのエントリにそのコメントがつくんだ?
『XPは実践よりも心が大切なんだ』と書いてるのに
『お菓子重要』ってなんなんだ?

お菓子って処方箋だろう。まぁ、実践なんてぜんぶ
処方箋なんだろうけど、お菓子はその中でもそれほど
重要じゃない。なぜって、XPE2じゃPrimaryでも
Corollaryでもないじゃないか。

効くかもしれないし効かないかもしれない。その
程度のものだろう。それにお菓子って、健康面から
見れば必ずしもいいことばかりじゃないだろう。
それってEnergized Workに矛盾するじゃないか。

脳の栄養? バカいうな。アスリートじゃあるまいし。
棋士みたく朝から晩までヘドが出るほど考えるって
いうんならまだしも。

メンバに糖尿の人がいたらどうすんだ? イスラム圏の
人がいて断食してたらどうすんだ? それでも『お菓子
ジューヨー』なんてノンキなこといえるのか?
これは極端な例に思えるかもしれないけど、こうやって
考えるのがSelf-Similarityだろう。

やるなとはいわない。でも、なぜやるのかを真剣に
考えないとダメだ。お菓子はきっかけに過ぎない。
お菓子で改善されるんなら、事態が悪化してたわけで、
なぜ悪化してたかを考えなきゃダメだ。

バグレゴにしてもそうなんだけど、角谷さんが
素晴らしいのは自分で工夫しているところだろう。
ぶっちゃけいって、バグレゴを他所でやったって
効果が上がるとは思えない。そこに角谷さんという
情熱を持つ人間がいなきゃすぐゴミ箱行きだろう。
実践ってそういうもんじゃないか。1つの実践よりも
1人の情熱を持った人間のほうが勝るんだ。

いつまでXP1に留まってるつもりなんだ?

--

実践から入るのも悪くないでしょう。そのほうが
入りやすいですから。開発者の立場からすると、
そのほうが入りやすいでしょう。ぶっちゃけいって、
価値がどうこうとかはXPを知らない開発者にとっては
ネムタイ話でしょう。だったら、型にハメった
実践やって、多少なりとも効果を実感したほうが、
身を入れてXPを知ろうと思うはずです。

管理者の人はどうすればいいか? 何もやらなくって
いいんじゃないでしょうか。やるとしても『XPって
知ってる?』とか『XPでやってみない?』とか、その
程度の働きかけしかできないでしょう。強制しても
逆効果です。

ただ、とはいえ、やっぱり管理者の人は、XPをやったら
何が起こるかを知っていてほしいですね。それは実践と
いう表面的なことでなく、どんなsocial changeが
起こるかということを知っておいてほしい。たとえば、
開発者がビジネスについて発言することもあるでしょうし、
契約の形態も変わるかもしれません。劇的な変化に
驚かないでほしい。といっても、日々ちょっとずつ
変わっていくので、それほど驚くことはないでしょうけど。

本家Permlink


2006年09月12日

処方箋というべきものがある。病が治ったら、処方箋は
必要ない。

効果のなくなった実践は止めなきゃいけない。

--

何度も同じこと書いてますけど。

プロジェクトに価値をもたらす人間に上も、下も、内も、
外もない。

プロパーはよりビジネスに近く、下請けはビジネスから
より遠い。しかし、その距離というものは厳密なものじゃ
ない。どこからどこまでがプロパーで、どこからどこまでが
下請けという厳密な境界があるわけじゃない。

もし境界があるなら、それはあなたの心の中にしかない。

本家Permlink


2006年09月11日

見える化というのは大切なんだろうけど、それよりも
自分は見えないものを見ることのほうが大切だと思う。

たとえば、日々同じ職場にいて、相手の気持ちを察して
あげられなようじゃどうしようもない。シールを貼った
ときになって『え? 今日は調子悪かったの?!』と
驚くようではどうしようもない。

記録することは別に悪いことじゃない。でも、それを
何のために記録するかを考えることは大切だ。

変化は見えないところで起こってる。

本家Permlink


2006年09月10日


本家Permlink


2006年09月08日

http://www.sra.co.jp/people/aoki/SmalltalkIdioms/index.htm

お、公開されてますね。

--

確か新山さんも頭痛持ちとか書いてましたよね。
そういう自分も頭痛持ちなんです。
しかも群発頭痛という、一番タチの悪いヤツ。

毎年夏に入ろうかというころに発生するんです。そりゃ
もう、ひどいもんです。夜中に頭痛で起きることがある
くらい。そう、群発頭痛は定期的に発生するんで、
毎晩頭痛で起こされちゃうわけです (笑)。いや、
笑い事じゃないんですけど。

薬を飲めば、10分か20分か耐えてれば引くことも
あるんですけど、引かないこともあります。そんな
ときはもう耐え忍ぶしかない。何もできないですから。
眠ることすらできない。ほんとにジッと痛みが引くのを
待つしかない。

でも、一昨年、昨年、そして今年と、それほどひどい
目には遭っていません。多少重く感じることはあっても、
眠りを妨げられることはありません。

思い当たることといえば、暑さしのぎに使いだした
冷えピタ。クーラーが嫌いなもので、でも異常に暑い
ときもあって、そんな夜に冷えピタを貼って寝るように
なりました。それで気づいてみたら、夜中に起きる
ほどひどい頭痛には遭ってなかったという次第。

もちろん、冷えピタが群発頭痛に絶対効くと限った
もんじゃないでしょうけどね。それと、多分、痛みが
ひどくなる前に貼っといたほうがいいでしょうね。

自分の場合、付き合いが長いですから、なんとなく
危ないのがわかるんですよね。肩に来て、首筋に来て、
目の奥に来るっていう。群発頭痛で自殺しちゃう人が
いるっていいますけど、わからなくはないです。

ちなみに今年は熱さまシートを使ってるんですけど、
効果はあるみたいです。冷えピタのハーブが効いてる
のかなとちょっとだけ思ってたんですけど。やっぱり
冷たけりゃいいみたい。
冷えピタ売ってねぇんですよ、近所のどこにも (笑)。

--

ああ、今年は環境が変わったってのもあって、その
せいで頭痛が出てないのかも。だから、ほんとに冷えピタに
効果があるかどうかはわかんないですよ。
ま、気休め程度に考えてください。

--

ちなみに、冷えピタはケロロ軍曹も愛用してます。(笑)

--

そういえば、今日はじめて、Subversionがリビジョン
番号を単なる数にしたのが正解だったと気づいた。

CVSに突っ込んであるファイルの特定のリビジョン同士を
diffしたかったんだけど、それが

1.6.2.3.5.9.1.3.9.3

みたいなヤツで笑った。いや、Emacs VC使ってるから
気づいてたけど、まさかそれが問題になるなんて
思わなかった。

--

逆をいえば、己が変わらなければ周りも変わらないわけだな。
当然ながら。

すすんで明かりをつけましょうってヤツだ。

--

バグを過大評価、っていうのもアレですけど、
結構ユーザも増えてきましたし、深刻なバグが
長い間見つからないといったことはもうないんじゃ
ないでしょうか。

つまり、バグが出たとしても軽微なものであると。
まぁ、楽観すぎるかもしれませんけど。でも、XPって
そんな感じでしょう。XPの場合、ユニット・テストや
受け入れテストで品質を維持するわけですけど、
そればっかりじゃなくって、ちょっとずつ変えてる
んだから、大きなバグは入りにくいっていう事情も
ありますよね。

プログラミング言語の場合、ユニット・テストが
やりにくいっていう面はあります。テストケースが
膨大になりやすいですから。それと、オープン・ソース
ですから受け入れテストというのもなかなか難しい。
となると頼れるのはユーザでしょう。つまり、ユーザに
テスタになってもらうという、オープン・ソースの
王道に戻るわけです。

--

ちょっと上の話とも関連するんですけど、
Windowsの人たちの文化なんでしょうけど、リリースと
デバッグでビルドを分けるんですよね。

そんなムダなこと止めなさい。

PragProgは『アサートはオンにしたまま出荷しろ』と
いってます。つまり、デバッグ・オプションつけたまま
出荷しろってことです。

オープン・ソースでリリースとビルドを分けてる
なんて聞いたことがない。

$ ./configure && make && make test && make install

でしょ、ほとんど。

リリースとデバッグを分けると様々な弊害があります。
1つはリリースで何かあったときに、バグを追いにくく
なる。もう1つはリリースとデバッグとでインクルード・
パスやライブラリのリンクを変えるのに手間がかかる。
最後に、余計なビルドのおかげで貴重な時間が浪費される。

それで得られるものといえば、多少のディスクスペースの
節約と最適化によるスピードアップ。ディスクスペースは
今じゃほとんど問題になりません。そして最適化ですけど、
どうでしょう? それほど効果ありますか?
まぁ、あるんでしょうけど。

でも、自分は、リリースとデバッグとを分けるエネルギーを
もっと別のことに使いたい。開発サイクルを早くする
ことで、1つでも多く、少しでも早くユーザに新しい
機能やサービスを提供したい。何かあったら少しでも
早く善処したい。いや、そもそもその『何か』を
起こさないようにしたい。だから、いらんことにエネルギーを
使いたくない。

最適化をかけるのもユーザにとってうれしいこと
なんでしょうけど、今上であげたことだってユーザに
とってうれしいことじゃないですか。どっちを取るかって
話じゃないですか。そもそも最適化とかコンパイラ任せで
品質を上げるなんて安易な発想すぎるでしょ。それで
コードはコピペの嵐って、『バカ?』って感じ。

本家Permlink


2006年09月07日

『へ? social changeなんて書いてあったっけ?』
などと思ってしまいました (笑)。

今grepしたら、やっぱり冒頭にありました。

  Extreme Programming (XP) is about social change. It is about letting
  go of habits and patterns that were adaptive in the past, but now get in
  the way of us doing our best work. It is about giving up the defenses
  that protect us but interfere with our productivity. It may leave us feel-
  ing exposed.

読書メモにも『社会的な変化』って書いちゃってますね (笑)。

このときは、どうもrelationshipのほうに目がいった
みたい。さすがにrelationshipは人間関係を指してる
ってことはわかったみたい。それから全体としては、
やっぱりより人間指向になっているとメモってますね。

上で引用したののすぐあとに:

  Prepare for success. Don't protect yourself from success by holding
  back. Do your best and then deal with the consequences. That's
  extreme. You leave yourself exposed. For some people that is incredi-
  bly scary, for others it's daily life. That is why there are such polarized
  reactions to XP.

っていうのがあって。これを読むとsocialが具体的に何を
いわんとしているかがわかりますよね。ここで度々
取り上げている『隅に隠れるのは止めた』という話にも
つながってます。

ここで書いた話でsocialがらみのがあったか調べて
みたいんですけどこれとかこれくらい。

前者は『社交的』としてますけど、後者は
『社会的』と書いちゃってます。内容のほうも、ちょっと
外している感じ。

  プロジェクトの重要な歴史を殺さないためにsocialな仕組みに信頼を置く。

これはCorollary Practiceの1つである``Code and Tests''
についての記述です。だとすると、この『歴史』について
の記述では、『ドキュメントの代わりにsocialな仕組みを
選ぶ』ということになるんだと思います。

じゃあ、その『socialな仕組み』って何なのよ?という
疑問の答えは、残念ながら書かれてません。まだ自分が
読んでないとこに書いてあるのかもしれません。
まぁ、『生き字引』もアリなのかもしれませんけど、
ちょっと話が突飛すぎるかな (笑)。

なんとなくわからなくもないんですけど。なんていう
んですかね。伝えたい気持ちの込もったものなら何でも
いいような気がするんですよね。だから、仕組みだけに
こだわっちゃうと失敗しちゃう。ドキュメントだって
仕組みの1つといえるわけで。Wikiだってそう。

そういえば、『みんなWiki書いてくれねぇ』って嘆いてる
人、多いみたいですけど (笑)。Wikiだって書き方次第で
クソタイクツなドキュメントとおんなじになっちゃう
んですよね。だって、どっちも結局はテキストですから。
Wordで書くのがダメで、Wikiならいいのかっつったら、
そりゃ違うでしょう。

ドキュメントもWikiも楽しく書かなきゃダメ。書いて
楽しく、読んで楽しく。それがJoelの教えてくれたこと。
でなきゃ書かないほうがマシ。

そう、結局、socialっていうのは、楽しく仕事をしたい
ってことなんですよね。まぁ、コードとニラメッコ
してるのもいいですけど、やっぱりみんなと楽しみながら
仕事したいじゃん? 楽しみながら仕事をすることこそ、
生産性向上の最大のカギでしょ。それはLinus氏みたいに
個人の話じゃなくって、チーム全体の話として、ね。

本家Permlink


2006年09月06日

どうもオレはプログラマとして本質的に何かが欠けて
いるんじゃないか。

なぜプログラミングするかといえば、プログラムを
作ることが目的じゃなくって、そのプログラムがもたらす
『何か』を得るためにプログラミングするものだ。

ところがオレは、プログラミング自体を、いや、より
正確にいえば、コードを書いてひねくり回すことを
楽しんでいる。結局のところ、『何か』なんてどうだって
いいんだ、オレにとっては。

これはコーディングに対する偏愛、偏執といってもいい。
だから:

  if(value){

みたいなコードを見ると異常に腹が立つ。そうじゃねぇ
だろ:

  if (value) {

だろと。

あるいは、スペースだけで埋まってる行や行末の空白にも
一々目くじらを立てて:

M-x replace-regexp RET [ 	]+$ RET RET

なんてやるんだ。ちなみに[]の中はスペースとタブね。

もしオレがもうちょっと『何か』を大切に思ってるなら、
ヘンチクリンなフォーマッティングに気を揉むことも
ないのだろう。

--

ああ、Emacsの影響が強すぎるってのはあるかもなぁ。

--

レゴはムリ (笑)。

大体、自分、オモチャ置かないんですよ。フィギュアとか。

書くのもねぇ。キーボードからだったらいくらでも
書くんですけど、筆記は全然ダメ。字ぃ汚いし。
今朝なんかタイムカード置いてあるとこでマジマジと
見たんですけど、自分の字が一番汚かった。Wardと
タメ張れる (笑)。

--

Antは重くねっすか? あれは結構致命的だと思うんすけど。
つか、コンパイル言語の人にとっては、それが当たり前
なのかも。まぁ、規模が大きくなっちゃえばmakeもantも
変わんないでしょうけど。

--

やっぱオープン・ソースだからこそ、定期的なリリースに
したほうがいいんじゃないですかね。

仕事だったらリリースって結構融通利いちゃうんですね (笑)。
でも、やっぱり仕事だからイヤでもその日はやってくる
わけで。

でも、オープン・ソースには締切がないっちゃない。
出さなきゃ出さないでいいわけです。でも、それじゃあ、
あんまりです。どうする? もとより締切がないんだから、
だったら定期的にしちゃってもいいんじゃないですか?
3ヶ月ごとは厳しいとしても、6ヶ月とか1年とか。

締切は絶大な効果を発揮することはよく知られている
ところです。滅多に『白いページ』は見ませんからね (笑)。

ややもするとダラダラしがちなプロジェクトに喝を
入れるために、定期的なリリースを検討してはいかが
でしょうか。

本家Permlink


2006年09月05日1

いい例を見つけるっていうのは、XPのメタファーに
限らず、とても大切なことです。

今日こそは、まともな例を持ち出すようにしたいです。

GUIプログラミングで、コンポーネントの位置を計算で
決めたいことがありますよね。

class MyButton < Button
  def show
    x = parent.width / 2
    y = parent.height / 2
    super(x, y)
  end
end

みたいな。さんざん『GUIコンポーネントからサブクラス
作るな』って書いてるんですけど (笑)。またダメな
例かも。ま、それは置いといて。

で、他のボタンはまた別の計算で決めるみたいな:

class YourButton < Button
  def show
    x = parent.width / 3
    y = parent.height / 3
    super(x, y)
  end
end

うわ、またダメな例になってきた。ま、実際はもう
ちょっとマシな計算をしてると思ってください。

んで、こういうコードはにおうわけです。重複のにおいが。

パッと思いつくのはTemplate Methodですよね:

class OurButton < Button
  def show
    raise 'subclass responsibility'
  end
end

class MyButton < OurButton
  def show
    x = parent.width / 2
    y = parent.height / 2
    super(x, y)
  end
end

class YourButton < OurButton
  def show
    x = parent.width / 3
    y = parent.height / 3
    super(x, y)
  end
end

くどいようですが、あくまでも例ということで。
こういうことを強調しないといけないのが
ダメな例の証拠。泣ける。

でも、こないだ、『Template Methodは嫌いだ』って
書きましたよね。Template Methodは確かに手軽だし、
さほど不自然さは感じません。でも、それって、単に
慣れちゃっただけじゃないでしょうか。

代替案はいくつもありますが、Strategyが有力でしょう:

class OurButton < Button
  def initialize(strategy)
    @strategy = strategy
  end

  def show
    x, y = @strategy.compute(self)
   super(x, y)
  end
end

class ShowMyButton
  def compute(button)
    x = button.parent.width / 2
    y = button.parent.height / 2
    return [x, y]
  end
end

class ShowYourButton
  def compute(button)
    x = button.parent.width / 3
    y = button.parent.height / 3
    return [x, y]
  end
end

とか。

ただ、Strategyにも難点があります。導入するのが
Template Methodより大変なんですよね。それもかなり。
で、その大変さに見合う恩恵が得られるかっていう
話なんですけど。

個人的には『100%得られる』っていいたいですね。
変更が小さければ、Template MethodもStrategyも
そんなに手間は変わらないでしょう。1日とか2日とか
そういうレベルの差でしょう。で、大規模ならどうか?

実は大規模になればなるほどStrategyのほうがいい。
変更は大変になりますけど。

特に静的型言語の場合、ファイルの依存関係が格段に
変わってきます。Template Methodだと、スーパークラスを
変えると、たとえばC++でいえばprivateメンバ関数を
追加しただけでも、そのサブクラスすべてが影響を受けます。

一方、Strategyなら、静的型言語だったらインタフェースを
使いますから、変更を閉じ込めることができます。

動的言語の場合でも、Strategyのほうがより『らしい』と
思います。@strategyには今話題のProcを使っても
いいでしょうし、Rubyならブロックだって考えられる
でしょう。@strategyは別に型にこだわらず、DuckTypingでも
いいですしね。

いつものようにダメダメな例でしたけど、わかって
もらえたでしょうか。

本家Permlink


2006年09月05日

ニシノコンドコソ (笑)

アストンマーチャン (笑)

--

昨晩の例、おかしかった。いわんとしてることは
わかってもらえたと思うけど。

本家Permlink


2006年09月04日

ぐえ、売り切れかよ。予約なんて全然してなかったよ。
つか、もっと全然先の話だと思ってたよ。つか、売り
切れるほど人気が出るとは思ってもみなかったよ。
買うとか書いといて買えないのはちょっと恥ずかしいよ。
というわけで、増刷希望ですよ。

--

最近の人はLispとかに興味ないのかな?

自分らの世代は・・・って書くと誤解を生んじゃうけど、
少なくとも自分は言語を作ることに興味があって、
そんな自分みたいな素人が真っ先に候補に上がるのが
Lispなわけで (その次がForth)。

だから、関数型云々っていうのは別にして、Lispって
いうのは結構身近な言語なんですよね。

まぁ、それとLispを使いこなすのとは別の話なんですけど。
でも、そういうのがあるだけでも、たとえばEmacs
使ってみたりとか、他にも、エーっと・・・
ま、いろいろメリットというか、少なくともLispに
抵抗感はなくなります。

Lispの処理系は、それほど腐るほどありますけど:

http://www.okisoft.co.jp/esc/go.html

とか。

あと、TinySchemeのベースとなったMiniSchemeだとか。
今ググると引っかかったのが:

http://www.geocities.jp/bneck44/hS.htm

一応Lispを名乗る以上、どれもlambdaは持ってるはず。

だから、たかがProc、つまりlambdaごときで大騒ぎ
するほどじゃないっていうのが自分の感想。Lispから
lambda取ったら (もちろん) Lispじゃないし、lambdaが
あるからっていってLispがスッゲー難しくなってる
わけでもないし。『混乱する人が出るだろう』って、
『あんたバカ?』って感じですよ。lambdaなんざ
Emacsのキーバインディングでも使うもんじゃん?
フツーに使えばフツーに使えるっていうだけ。むしろ
Javaのほうが型とかコンテキストがしっかりしてるから
Lispよか安全に使えるんじゃないの? 安全と利便性の
トレードオフはもちろんあるだろうけど。

--

『たかがlambdaごとき』と書いちゃいましたけど、
ま、そのあたりのニュアンスは汲んでもらえると
思います。あれほど有益な仕組み、概念が実に単純に
実装できるという意味で『たかが』を使ったまでです。

--

チラっとサングラスの男が見えた (笑)。

Whatの話ですけど、『どうなってほしいか』、違う
言い方をすると『有様』を書きます。

たとえば、テキスト・フィールドに文字列を挿入する
メソッドがあったとして:

def insert_string(str)
  @text_field.text = str
end

そのテストは:

def test_insert_string
  target.text_field.text = 'hello, world'
  assert_equal('hello, world', text_field.text)
end

ってなります。簡単すぎる例ですけど。

このとき、ひょっとしたらモデル・コードのほうは:

def insert_string(str)
  @text_field = %w[h e l l o , w o r l d].join.sub(/,/, ', ')
end

ってなってるかもしれません。でも、テストを書くときは、
そういうことを気にしません。いや、気にしなきゃ
いけないんなら、そういうふうにモデル・コードなり
テスト・コードなりを書かなきゃいけません。

だからHowじゃなくってWhat、有様だという話です。

もちろん、テストを先に書くわけです。そうすることで、
よりWhatに集中しようという狙いもあるわけです。

--

'nil'に賛成するわけじゃないですけど、もし'nil'に
なるんなら使いますよ。

だって、p trueより短いんだもん。

p trueはprintfデバッグの基本です (自分の中で)。

--

前からいってますけど、リリースはビジネスの領域。

ビジネスならば、ビジネスのサイクルというものがあって、
それは3ヶ月を単位とするのがフツーです。ビジネス側
からすれば、そのサイクルに合わせてリリースしてくれた
ほうがいい。期初というのは場所によっても違いますが、
それでも3ヶ月単位のサイクルならば、ビジネス側も
対応しやすいでしょう。

スリップは御法度。これも何度も書いてます。スリップ
させるくらいなら、スコープを狭めててでもリリース
すべきです。そして計画を見直します。というか、
リリース間際にそういう事態に陥らないように、
頻繁に計画を見直す必要があります。

当然、Mutual Benefitがあります。まず、プロジェクトに
一定のリズムが生まれるということ。リズムが生まれれば
開発に速度がついてきます。次に、計画性です。これは
ビジネス側にとってだけでなく、開発側にとっても
大切なことです。明確な計画を共有することで、チームの
士気が上がります。

以上はXPの話ですけど、XPでなくっても、たとえば
オープン・ソース・プロジェクト、そう、たとえば
Ruby (笑) にも適用できる話でしょう。

本家Permlink


2006年09月03日

http://www.fdma.go.jp/neuter/topics/fieldList4_2.html

自分は未踏にそれほど強く賛同はしませんけど、あっても
いいと思ってます。インターネットがその手の資金で
実用化された事実もあります。それと、特に日本の場合、
軍事面での資金を大っぴらに期待できないだけに、経産省
あたりが資金を出すというのは国策としてもアリでしょう。

あれ? 上の資料の最新のを見たけど、ロボカップ関連の
ネタがないね。だいじょぶ?

--

ゲームとかアニメとか、本気で国が支援したいっていうなら、
税制面を優遇してやるしかないんじゃないの? そういう
ことを避けて、やれ人材育成だなんて、虫がよすぎる。

--

まぁ防災ということで:

http://www.e-college.fdma.go.jp/top.html

本家Permlink


2006年09月02日

『日本でお買い物しましょう!』って、そんなもん
大きなお世話だっつの。

本家Permlink


2006年09月01日1

http://c2.com/cgi/wiki?WhatsaControllerAnyway

あははは。やっぱみんなコントローラに引っかかるんだよな。

Cocoaのドキュメントだけど、MVCの解説としてはしっかり
書けてるのかも:

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_4.html

まぁ、自分はMVCはあんまし好きじゃないんですけど。

--

オレは『し〜ぷら』派!

さすがに『ぷらぷら』は恥ずかしくてクチにできない。
『しー』して『ぷらぷら』ってトイレかよ。『一歩前へ』かよ。

--

http://www.google.co.jp/search?q=%E5%8F%B3%E3%81%AE%E4%B9%B3%E3%82%92%E6%8F%89%E3%81%BE%E3%82%8C%E3%81%9F%E3%82%89%E5%B7%A6%E3%81%AE%E4%B9%B3%E3%82%82&start=0&hl=ja&lr=lang_ja&ie=utf-8&oe=utf-8&client=firefox&rls=org.mozilla:ja:official

本家Permlink


2006年09月01日

http://sugi.nemui.org/diary/20060831.html#p02
http://www.kt.rim.or.jp/~kbk/zakkicho/zakkicho14.html#D20060831-4

勉強になりました。

ファイルを空にするのって、あんまりないんですけど、
ログ・ファイルを空にしたいってときがごくたまに
あったりするんですよね。まぁ、ファイル消しちゃっても
いいんですけど。

でも、空ファイル作るのって、ずっとtouch使ってました。
それより短いやり方がったとは。

--

今日、はじめて『電話デバッグ』の効果を痛感しました。

そのときのコードはこんな感じでした:

for (int i = 0; i < size; ++i) {
   char* s = (char*) calloc(10, sizeof(char));
   ...
   free(s);
}

このコードを見て、なぜか自分はメモリ・リークが起きてると思い込んじゃっ
たんですね。だから:

vector<char*> vec;
for (int i = 0; i < size; ++i) {
   vec.push_back((char*) calloc(10, sizeof(char)));
   ...
}
for (vector<char*>::iterator it = vec.begin(); it != vec.end(); ++i) {
  free(*it);
}

ってやんなきゃダメだと。

で、ペア・プログラミングのパートナーが隣に座ったときに、それを説明しだ
した途端、メモリ・リークなんて起こんないことに気づきました。ループの1 
回ごとにメモリの割り当てと解放をやってて、callocが失敗したとしても、メ
モリ・リークは起きません。ループが何回か回っていたとしても、それまでに
callocしたのはきちんとfreeされてるはずです。もちろん"..."でエラーが起
きてreturnしてるとかいう場合なら話は違いますけどね。

やっぱり話してみるもんだなと。W.Cunningham氏も『ペア・プログラミングの
ときは黙ってやっちゃダメだよ』っていってましたけど、まさにそのとおりで
すね。前にも書きましたけど、しゃべるっていうのはMutual Benefitなんです
よね。しゃべる側にとっては、しゃべることで自分の考えがはっきりします。
一方、話を聞くほうは、相手の考えていることを理解できます。このMutual
Benefitがあるからこそ、2人で1つのことをやっても生産性が極端に落ちるこ
とはないし、ときには1+1が3にも4にもなるでしょう。

ああ、それにしても、ちょっとレベルの低い勘違いでした。

--

なにそれ。帯域広げる改造した受信機なんか、昔っから売ってるじゃん。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails