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
11
12
2018
1
2
3
4
5
6
7
8
9
10
11
http://youtube.com/watch?v=_pbhxB7cGbw ラリー・グラハムの教則ビデオ。なんだけど、グラハム セントラル、スライストーンの名曲を弾き語ってる。 もちろんチョッパー。しかもノリノリで、声もバリバリ 出てる。 -- サンボマスターがCurtis Mayfieldの影響受けてるとか いうけど、ほんとか？ メガネしか似てねーじゃん (笑)。
http://shinh.skr.jp/dat_dir/golf_prosym.pdf http://golf.shinh.org/ まぁ、今さら自分が取り上げるまでもなく有名になった みたい。 「shinhさんのゴルフの話を読んでみたいなぁ (Ruby magazineで)」と思ってたらドキュメントが公開されて しまった。 -- 寺田光男？ 長州力のこと？ そういえば、レジェンド軍とか、冴えてないよな〜。 そういえばといえばそういえば、kamiproで「ゴッチの 息子」、木戸さんのインタビューがあって驚いた。
ウカイえも〜ん！ マカーにLinuxをバカにされたよ〜！ http://blogger.ukai.org/2007/09/macosx-emone-modem.html ・・・ ウカイよ、お前もか！？
http://www.hyuki.com/yukiwiki/wiki.cgi?HowToWriteAnEffectiveDesignDocument 最初に断わっとくけど、総論として否定するわけじゃない のね。『まぁ、こういうのもアリかな』と思う程度だけど。 でも、自分だったらやらないね。 で、一番最後のとこなんだけど、設計と計画は違うでしょう。 設計は手順と違うんだから。 で、この手順っていうのが、往々にして軽んじられるのが 気になってるわけ、自分は。 あと、リスク云々を設計の文書に含めるのもどうかなと 思う。リスクは見えるようにする、あるいは衆知する ことが大切なわけで。それを設計文書の中に埋没させるのは どうかと思う。 -- 上みたいなこと書くとまた誤解されるんだろうけど。 コーディングに入る前に、設計の方針とか、リスクとか 考えるのは大切なことなのね。それも、できるだけ深く 考えて、抜けのないようにする。 とはいっても、ストーリー単位でやってるんだから、 それでもそんなに時間はかからないわけ。まぁ、ある 程度開き直りも必要だし。実装してみなきゃわかんない っていうことも多い。たとえばパフォーマンスとかは、 概算することはできても、それが『使用感』といった 実感できるものにはなかなかなんない。 本質的には、問題をどれだけ理解できてるか、さらに、 どれだけ多くの人間が理解できてるかが重要なわけで しょう。文書を書くのは、そうした理解を得るための 1つの手段に過ぎないわけでね。 たとえば、XPではCRCカードのセッションがよく話になるし。 自分とこではやってないけどね。フツーにミーティングで 済ましてる。もちろん、ホワイトボードとかは使うし。 -- ああ、朝会やイテレーション・ミーティングだけが ミーティングじゃないしね。必要なときに必要な人間が 集まって設計の話し合いをしたりとか。 だからね、やっぱり生身の人間同士の交流をイヤがっちゃ ダメなんですよ。
厳罰どころか、あまりのスルーっぷりに笑うしかない。 newsplusですら「メディアのソースがない」を理由にスレが立たなくなった。 http://www.gamenews.ne.jp/archives/2007/09/post_2678.html 日テレの倫理観はおかしいし、抗議しない自民党やタイゾーもおかしい。 21世紀はまだまだこれからだというのに世も末とは。
日テロ、やっちまったな。 これで処分が軽いようだと、日本の民主主義もヤバイね。
#!/usr/bin/env ruby
`ps axw`.to_a.each do |line|
cols = line.strip.split(/\s+/, 5)
next if /\Aruby\s/ !~ cols[-1]
next unless cols[-1].index(ARGV[0])
system("kill -KILL #{cols[0]}")
end
--
ああ、書き忘れましたけど、ここで何度も書いてるように、
プロトタイプを重視するようなやり方はagileじゃありません。
プロトタイプはお金にならないでしょう。お金にならない
ものに手間をかけるのは、ビジネスに成功するというagileの
目標から外れます。
『お金にならない』という直截的な書き方をしましたけど、
要は『価値のない』という意味です。システムというのは、
使われてはじめて価値を生むものです。使われることが
目的ではないプロトタイプに価値はありません。あると
すれば学習効果ですが、それはビジネスの価値と比べたら
非常に小さいです。
--
本物のシステムをいじることがagileの本道であって、
そこにagileの難しさみたいなものがあります。
システムを壊さずに、どうやって進化させるか。だから
こそリファクタリングが重要視されるわけです。
PHPカンファレンスに350人しか集まらなかったの？ なんか少なくない？ Rubyカンファレンス2006でさえ300人越えたっていうのに？ ユーザ数からいったら、PHPは、Rubyの比じゃないだろ？ 運用上の都合で参加人数を大幅に制限してるとか？ 告知が十分されてなかったとか？ PHPユーザはロイヤリティ低いとか？ PHPは実は落ち目だとか？ -- 日本の動向って全然わかんないんだよねぇ。米国だったら、 最近はO'Reilly氏の分析があるけど。 だから、オライリー・ジャパンでもレーダーやれって 前から書いてるんだけど。全然ダメだねぇ。いつまで 経っても、ただの出版社のサイトのままじゃん。 -- ソースコードも、囲碁や将棋のような観戦記をつければ、 それなりに楽しめると思うんだが。
http://d.hatena.ne.jp/kinneko/20070922/p1 できたプログラムを使う人の立場や、使われる状況、フィットする市場、マー ケ上必要な虚飾、そしてQA可能かどうか、市場性とかけられるコスト、そう いうものをトータルに考えながらアジャイルってできるのだろうか？ ソフトウェア開発をビジネスとして捉えようというのが アジャイルの根本にあります。こういう発想そのものが これまでの開発方法論には希薄だったんですね。ビジネスと 切り離してソフトウェア開発を論じようとしていた。 だから、『そういうものをトータルに考えながら アジャイルってできるのだろうか？』っていう疑問に 答えるとしたら、『できる』とはいえないまでも『できる ことが目標』ということはできます。それが目標でなければ ビジネスとして失敗するわけで、それはビジネスとして成功 するというアジャイルの目標と矛盾します。 逆に、『できる』と言い切れるような方法論はないでしょう。 あるとしたら、かなり眉ツバです。 QA (品質保証) という意味では、ユニット・テストばかりが テストではありません。受け入れ試験もやります。これは、 顧客がテスト仕様なりを書くべきものです。 なおかつ、XPでは、ストーリーに対する受け入れ試験を 早い段階で書くことが推奨されています。受け入れ試験を 書くためには、仕様が明確になってないと書けません。 そういう意味で、『アジャイルでは仕様が曖昧でも構わない』 というのは誤解です。 プログラマが要件定義を嫌がるっていうことはないんじゃ ないでしょうか。そんな人間がいるとしたら、それは プログラマとは呼べないんじゃないでしょうか。 じゃあ、プログラマは何をするの？っていう話になり ますよね。誰かが定義した要件から、誰かが仕様を出して、 それをコーディングする？ そんな仕事は、プログラマとは いえませんよ。悪い意味でのコーダーですよ。 -- 『まんがくらぶオリジナル 11月号』、『佐川芳枝の お寿司屋さんにいらしゃ〜い』より： 油がしみこんだ鍋に、玉子の汁を入れると、じゅうっ と景気のいい音と、お菓子を焼いているような甘い香りが 流れて、 (あ、いいギョクが焼けるわ) 毎日のことなのに顔がほころびます。 『毎日コード書いてて楽しいの？』といわれるかも しれませんが。楽しいんですよ。 このおかみさんも30年以上ギョクを焼いていて、それでも なお毎日のように楽しくギョクを焼いてるわけです。 自分もいつまでできるかわかりませんけど、50を過ぎても、 いくつになっても、微笑みながらコーディングしたいと 思うんですよ。
http://d.hatena.ne.jp/atsushieno/20070508/p1
つまり、アップロードする人間が『この動画はパブリック・
ドメインだ』というつもりでアップロードしても、ニコ
ニコ動画じゃそれはムリだって話なのだな。つまり、ニコ
ニコ動画で公開された動画を加工したりして他の場所で
公開したら、訴えられて敗ける可能性は十分にあると
いうこと。
いや、アップロードした動画の作者であっても、その
作品の著作権すべてをニコ動に譲渡したことになるわけで、
作者自身も、もうその作品から派生する作品をニコ動
以外に公開することは許されなくなるんじゃないか？
たとえば、オリジナルの楽曲をニコ動にアップロードした
としよう。そうすると、その作品の作詞、作曲、演奏と
いった著作権はすべてニコ動に移ってしまうんじゃないか？
これは常識的ではないだろうけど。でも、そういうふうに
ニコ動は主張してるんじゃないか？
--
caseのendとifのendじゃ扱いが違うのか？
a=%w(zero one two three four five six seven eight nine)
puts *a
puts"ten
eleven
twelve
thirteen
fourteen
fifteen
sixteen
seventeen
eighteen
nineteen
"
20.upto(99){|n|
print case n/10
when 2
:twenty
when 3
:thirty
when 4
:forty
when 5
:fifty
when 6
:sixty
when 7
:seventy
when 8
:eighty
when 9
:ninety
end.to_s
puts case n%10
when 0
""
else
print" "
a[n%10]
end}
puts"one hundred"
caseだと、最後のとこで "end}" って書ける。
でも、これをifで置き換えると：
puts if n%10==0
""
else
print" "
a[n%10]
end}
これはエラーになる。だから：
puts(if n%10==0
""
else
print" "
a[n%10]
end)}
って書かないといけない。
ちなみに、ifを使ったほうが短くって、375 B。
ゴルフとしては全然ダメなレベル (笑)。
今の段階だと：
puts *a=%w(zero one two three four five six seven eight nine)
puts"ten
eleven
twelve
thirteen
fourteen
fifteen
sixteen
seventeen
eighteen
nineteen
"
20.upto(99){|n|puts begin
case n/10
when 2
:twen
when 3
:thir
when 4
:for
when 5
:fif
when 6
:six
when 7
:seven
when 8
:eigh
when 9
:nine
end.to_s+'ty'+if n%10==0
""else" "+a[n%10]end
end}
puts"one hundred"
これで356 B。これが限界 (笑)。
つか、1行目の：
puts *a=%w(zero one two three four five six seven eight nine)
これはおかしいだろ (笑)。ツボって笑いが止まんない。
ん〜、楽しさって教えてもらうもんじゃないからねぇ。 たとえばマラソン。あれなんか自分には苦行にしか思え ないんだけど。でも、好きな人は好きだよね。好きな人は、 もちろん、マラソンを楽しんでるわけで。 「こうやったら楽しくなる!」とかあるかもしんないけど。 でも、やっぱり根っこは、自分の感性ってことになるん じゃないの？
『東洋経済』のトヨタ特集を読んで思ったんだけど、 やっぱり内製できなきゃダメなんじゃないか。 トヨタがやってることはアウトソーシングとは真逆だよね。 もちろん、下請けもたくさん使ってるんだろうけど、それ でも内製にはかなりこだわってる。 前に、『アウトソースじゃダメで、アウトシードじゃなきゃ ダメだ』みたいなことを書いたけど。それもトヨタは 実際にやってるよね。世界各地に工場を作って、それと 同時にトヨタ生産方式といわれるトヨタ文化の種をまいて る。ハコを用意するだけじゃなくって、人も育てようと してる。 -- http://www.rubyist.net/~matz/20070908.html#c いろいろ勉強になります。 HyperCard待望論っていうのもたまに見るんですけど。 自分はこれは望み薄だと思いますよ。HyperCardはなくなった けど、SuperCardはまだ残ってるんですよ。他にもRevolution っていうのもあって。でも、どれもそれほど成功してる 印象はないし。いや、今でもこういうので商売できてる っていう意味じゃスゴイことなんでしょうけど。 それと、あのビジネスに敏いSteve Jobsが捨てたって いうのが大きい (笑)。
『東洋経済』、トヨタ特集。 組み立て工程で人間とパートナー・ロボットとの共同作業が 導入されているという。 自動車を作るということよりも、自動車を生み出すための 工場を作ることが非常に重要になってきているのだと 感じた。これはソフトウェアと似た構図だ。 -- ん？ SchemeにあってRubyにない強力な抽象化の技法なんて ある？ マクロ？ マクロは爺さんの遺言で禁じられてる しなぁ。 というか、マクロを抽象化技法の一種にまで高めるには S式入れるとか、そういう話になるんじゃないの？ S式が これまた爺さんの遺言で禁じられてるしなぁ。 いや、いくらなんでも、そんな安易な理由でデスマーチには 陥らないよ。個人が未熟であることでプロジェクトがデス マーチに陥ることなんて絶対にない。それは安心していい。 いい？ 世間で「デスマーチ」といったら、集団開発での 話だし、徹夜が何日も続くとか、人がバタバタ倒れるとか、 そういう悲惨な状況のことを指すんであって。個人の やる気のなさを指して「デスマーチ」と呼ぶのは勘違いも 甚しい。 -- 個人的なことをいえば、職業プログラマたるもの、与え られた道具でやるしかない。それで結果を出してこそ プロというものだし、結果が出ないうちに「道具を変えて くれ」っていっても筋が通ってないだろう。 もちろん、イヤなものはイヤだ。でも、だからといって アベちゃんみたいに、途中で投げ出すのはプロとして恥と 思わないといけない。 やり抜くしかないんだよ。 -- 社会主義国で見られた「計画経済」から連想したんで しょうね。硬直した計画という意味で。まぁ、どっちに しても、もうちょっと考えて名前は選んだほうがいい ですよね。
順序付きのマップがほしいならArray#assocで十分じゃん？ 順序付きってことは、速度を犠牲にしてもいいってことと 同じなんだし (いくらバカな自分でもそれくらいは知ってる)。 それに、assocで使う配列の配列はリテラルとしても、それほど 不自然な書き方じゃないし (タイプは増えるけど)。 だいたい、順序付きっていっても、こないだ書いたみたいに、 単にキーがソートされてりゃいいってことも多いわけでしょ？ つか、もうこの話題、下火になってるっぽいし、今さら書いても、 みたいなねぇ。 -- http://www.rubyist.net/~matz/20070908.html#c01 勉強になりました。 でも、「RubyのWindowsサポートを手厚く」っていうのは、 どうでしょうか。これをまつもとさんにいってもしょうが ないような。 C++標準化委員会かなんかに「C++のWindowsサポートを 手厚く」なんていうヤツはいないわけでしょう。もちろん、 MSも標準化委員会に人は送ってるでしょうし、自分とこの OSに有利になるように働きかけてはいるでしょうけど。
現実問題、モチベーションなんだよなぁ。
たとえそれが良薬だとしても苦いものは苦いわけで。
アセンブラやりたい？
--
def sorted_each(hash)
hash.keys.sort.each do |key|
yield key, hash[key]
end
end
def sorted_each2(hash, fn)
hash.keys.sort{|a, b| fn.call(a, b)}.each do |key|
yield key, hash[key]
end
end
hash = {3=>?c, 2=>?b, 1=>?a}
sorted_each(hash) do |key, value|
p [key, value]
end
sorted_each2(hash, proc{|a, b| (a > b) ? -1 : 1}) do |key, value|
p [key, value]
end
--
yieldは予約語だぜ？ これ豆知識な。
だから自分はカッコつけない派。
コマンド・プロンプトの色を変えるなんて、わざわざ いわなくてもいいような基本中の基本だと思うんだけど。 コマンドを実行して大量のメッセージが出るようなときに、 最初のほうのメッセージが見たい。たとえば、コンパイルの ときとかね。そんなとき、プロンプトの色が変ってれば、 先頭までコロコロとかで戻るのもすぐ。 プロンプトの色が変わってないと、リターン・キーを 何度も押して切れ目を強調したりするわけだけど。そんな ムダなことをしたくない。 -- これも基本のことなんだけど、目でgrepしたり、目で diff取ったりするのはバカのやること。いうまでもない。 でも、それがわかっていながら、目でgrepしたり、目で diff取ったり仕向けるツールを書いちゃう。これもバカの やること。 たとえば、内部状態をダンプするツール。そういうのは 標準出力にそのまま垂れ流すのが一番いい。なのに、気を 利かせたつもりか、moreみたくページャのようなインタラクティブな ツールにしちゃう。そうなればgrepもdiffも使えない。 標準出力に垂れ流すように作れば、moreも使えるし、 grepもdiffも、あるいはファイルに落としてエディタで 使うこともできる。 -- いうまでもなく、いうまでもなくだ、コードがもっとも 重要なドキュメントだ。 -- コードには歴史がある。でも、だからといって、それが 今目の前にあるコードが汚くていい理由にはならない。 悪い因習は断たなくちゃいけない。 -- コードの書き方にはクセがある。でも、悪いクセは治さ ないといけない。そのためには自分の悪いクセを認識 しないといけない。悪いクセを個人のスタイルだと思って るようじゃダメだ。 -- たった数行の関数のどこに空行を入れる余地があると いうのか。その空行には、ただの改行以上の意味があると いうのか。 -- 処理のまとまりの間には空行を入れろという迷信がある。 繰り返すけど、それは迷信だ。まとまった処理ならば、 それを関数として切り出さなきゃいけない。 切り出せないなら、切り出せるように変えなきゃいけない。 そういうことを考えるのが設計というものだ。
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001147 いかにもリクルートらしく、NTTデータらしい話だねぇ。 コード以外のものを捨てるという方向には行かないんだ よな。 いや、別にSEとかSIerとかは滅んでいいんだよ。 オレはプログラマだから。どんなに自動化が進もうと、 プログラムのネタが尽きることはない。
どっか引っかかるんですよ。まつもとさんは大規模開発に 未来はないという。一方で、日本の製造業を見習えという。 でも、日本の製造業って、大規模開発でしょう。そこには 雇用問題とか負の面もあるけど、たくさんの人間が協力 して大きな仕事を成し遂げている現実もあるわけでしょう。 もちろん、ソフトウェア開発っていうのは特殊といえば 特殊なんだけど。でも、思ってるほど特殊じゃないかも しれない。 いや、別に大規模開発を擁護するわけじゃないけど。 -- http://www.hyuki.com/yukiwiki/wiki.cgi?SituatedSoftware 獲物に貼ったけど、こっちにも。非常に示唆に富む文書。 これは学校での話だけど、こういうことがフツーの会社 でも起きていくんだと思う。
『On Lisp』を読んで、改めて自分がバカだとわかった。 ので、『ANSI Common Lisp』から出直す。 p.20に面白い記述があった： 関数プログラミングの最も重要なメリットは、対話的テストができることで ある。純粋に関数的なコードでは、関数を書きながら1つずつテストしてゆ けばよい。期待した値が返ってくれば、関数の正しさが確信できる。この確 信の蓄積は、全体として大きな違いを生む。 この記述は、XPでのユニット・テストを思い起こさせる。 ここで何度か書いたことがあるが、ユニット・テストの 最大の効果は自信が得られることだ。その自信とは、 もちろん、『品質が高い』という自信だ。 『品質が高い』ということと、『品質が高いと自信を 持っていえる』ということを混同してはいけない。品質が 高いという『事象』を、ある程度客観的に証明でき、その 品質を自信という『感情』に昇華できなければ、ユニット・ テストの意義は薄れる。 自信を持つことがなぜ大切なのか。自信は速度に反映される。 不安を抱えたままでは速度は上がらない。不安を無視して 速度を上げるのは無謀というものだ。 感情的な面をさらに突っ込むと、自信は誇りへとつながる。 自信の持てないコード、誇りの持てないコードを書くのは、 己をすり減らす。
最近、消した記事にリンク張られることが多い気がする (笑)。 http://www.kt.rim.or.jp/%7ekbk/zakkicho/07/zakkicho0709a.html#D20070908-1 勉強になりました。 -- ん〜、評価とか考えたことはないねぇ。 防衛的プログラミングって当たり前じゃん？ それは品質を 上げるためであって、自分は品質の高いプログラムを書く ことが使命であって、自分とか会社とかがどう評価される とか全然関係ない。 まぁ、自分の今やってる仕事が安全性に注意しなきゃ いけないっていうのもあるけど。そういうのを抜きに しても、仕様、設計、実装のどこにいようとも、『抜け』が ないかどうか注意してなきゃダメでしょう。 こういうことは『評価』なんてもんと全然関係ない。 ましてや下請けだ元請けだなんてこととも関係ない。 オレのプライドだ。 -- ちょっとコンテキストが違うのかもしれないけど： 「ひとりひとりが気をつけましょう」というのは 小学校の学級会 でも、そうとしかいいようのないことはあるでしょう。 で、こういうときにテクノロジーや規則で問題を解決 しようとする人が多いけど。そうできないから学級会な わけで。結局、教育っていうことになるでしょう。 一人一人の意識を変えようとせずに、テクノロジーや 規則に頼るのって、長い目で見て成功しないと思うよ。 だから、教育のための枠組みを作るっていうのはアリ なわけ。たとえば会長のとこなんか、会社の時間で読書会 やってたりするわけでしょう。あるいは、日本の製造業 お得意のQC活動だってそう。 こういうのは結局は「ひとりひとりが気をつけましょう」 っていうことを繰り返しやってるわけでしょう。そういう のをバカで幼稚なことなんていってるうちは、多分日本の ソフトウェア産業はダメだろうねぇ。 -- 最近、開発っていうのは民主主義じゃなきゃいけないって 強く思うんですよ。一人一人が責任を持って、一人一人が 納得して、一人一人が行動してソフトウェア開発を作って かなきゃ、いいもんなんか作れないっていう。 規則にしても、それはみんなに受け入れられるものじゃ なきゃいけない。提案するのは誰か頭のいい人間かも しんないけど、でも、それが受け入れられるためには、 その規則にどういうメリットがあるかをきちんと説明 しなきゃいけない。そこで議論は起こるだろうけど、そう やってみんなが納得して提案を受け入れるっていう。 民主主義が成立するためには教育も大切だし、手間が かかることかもしんないけど。でも、こういうことを やってかないと。
http://www.google.co.jp/search?q=%E5%AE%87%E5%A4%9A%E7%94%B0%E3%83%92%E3%82%AB%E3%83%AB%E3%80%80%E9%9A%A0%E3%82%8C%E5%B7%A8%E4%B9%B3&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox ナニいってんの？ ウタダはその筋じゃ有名よ？ つか、たつをさんに身長だけじゃなくって、スリーサイズの ページも作ってほしいなぁ。 『顔チェキ』っていうのが流行ってるらしいじゃん？ やっぱ、そういうのはイケるんだよなぁ。 -- ん〜？ (語尾上げ) 整理するほど必要なコミットは何か 間違ってんじゃないの？ オッチョコチョイっていうなら、それこそBaby Stepsで 小さい単位でコミットするほうがいいでしょう。 だから、そのためには手順を変える必要もあるんだけど。 * 作業をコミットできる単位に切らなきゃいけない。 * かつ、細かいコミットで迷子にならないように、自分が どこにいて次にどこに行くのかがはっきりしてなきゃ いけない。 この2つは計画に関する部分で、コミット・ログとかで 済ませる問題じゃない。ストーリーやTODOリストで管理 しなきゃダメ。 * コミットしてもシステムが動くように作んなきゃいけない。 * かつ、コミットしたものは価値を生むものじゃなきゃいけ ない。 これはContinuous Integrationだし、Evolutional Designの 話でもあって核心となる部分。Spikeもこの話にからんで くるし。 コミットのスタイルっていうのは習慣だから、なかなか 変えらんないかもしんないけど。でも、変えなきゃダメだよ。 結局、ルールに例外を作らないことが大切なんだよね。 『コミットのときはBaby Stepsを適用しません』って なったら、そりゃ例外なわけでしょう。そういうとこ から規律というものが崩れていくわけですよ。 -- まつもとさんの真意がどのへんにあるかがちょっと わからないんですけど。もし仮に、それがトヨタ生産 方式といったものを指してるとして。だとしたら、 すでにagile方面に影響は強く現れていますよね。 -- 全然話が違うんですけど、最近よくいわれる、『大企業に おける2:8の法則』の話なんですけど。これ、自分はマユツバ じゃないかと疑ってるんですよね。 なんか、ああいう話を読むと、残りの8割は役立たず みたいないわれ方されてるじゃないですか。でも、 そんなわけないでしょう。やっぱり直接的に利益を あげてるのは8割のほうなわけで。 その8割に目を向けないで2割のほうにどうやって入り 込もうとか、そういう話でいいのかなって思います けどね。 -- でね、一方の極がトヨタ生産方式だとして、で、反対の 極がハッカー生産方式だとして。その間には共通する もの、あるいは共通して有効なものが結構あるんじゃ ないかとも思うんですよね。 結局ね、どっちも主体は『作る人』にあるわけですよ。 品質を上げるのも、管理者みたいな人間じゃなくって、 現場で作ってる人間が主体となってやるわけですよ。 で、その主体性っていうのは規模とは関係ないんですよ。 大規模の話になると、とかく人間が無機質な部品っぽく 扱われるんですけど。そんなことはなくってね。 -- でも、製造業っていってもピンキリだからねぇ。
へー、あのフキダシってテーブルと画像で出来てたのか。 ビックリ。手書きなの？ 手書きだとしたら愛がありすぐる。 -- へー、ニコニコ動画はニワンゴっていうとこがやってて、 そこに出資してるのが未来検索ブラジルなわけか。
オブジェクト指向っていうのは、デザイン・パターン とかのためじゃなくって、まさに今目の前にあるグチャ グチャなコードを解きほぐするためにあるもんじゃないの？ 少なくとも原点の1つはそこにあるんだと思うよ。
http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3a%e5%88%9d%e5%bf%83%e8%80%85%e3%81%ae%e8%b3%aa%e5%95%8f%e7%ae%b1
Shiroさんが『Schemeのような関数型言語とC/C++のような
手続き型言語におけるデバッグの違い』について答えて
くださいました。ありがとうございます。
やはり両者の違いの鍵になるのは『状態』ということ
なんですね。副作用を避けることの大切さは関数型言語で
よくいわれることですが、それも状態を減らすためなんで
しょうね。
関数単位でちょこちょこ入力を与えて出力を見るって
いうふうに進めることが多いですね。
多分、これは対話型インタプリタで実験する、あるいは
ちょっとしたテストをやることを意味してるんでしょう。
これが可能なのも、状態が少ないからなんでしょうね。
状態っていうのは前提条件みたいなのも含みますから。
ある関数を調べるときに、前提条件をそろえてあげないと
動かせないというのでは、こうしたスタイルは取りづらい
でしょう。
それと、これは関数型に限らないのかもしれませんけど、
やっぱり関数は短いほうがいいんでしょうね。長いと、
どうしても変数を使ったりして状態が増えますから。
--
こうしてみると、デバッグでもボトムアップ・プログラミングが
からんでくるんだなぁと。
--
以前ここで、『Lispの処理系にはまともなステッパーが
1つもねぇ！』ってキレたことがありましたけど (笑)。
こうした事情があることも、なんとなく予想はしてたん
ですけど。
『ステッパーはそんなに使わないよ』
『だからステッパーは充実してないよ』
っていう話なんですよねぇ。
話をどんどん逸らしますけど。でも、ステッパーを使わ
ないスタイルが広く受け入れられるかなぁ？とも思うん
ですよね。最初っから関数型で育つ人なら話は簡単です
けど。
Erlangの大規模システムの話あったじゃないですか？
あれなんか、自分で話題にしてても半信半疑ですからね (笑)。
Erlangのことはよく知りませんけど、でも、ステッパーが
充実してるとも思えないし (笑)。
ただ、あの話でポイントなのは教育なんじゃないかと
思ったんですよね。Erlangの関数型プログラミングを
キッチリ教えてるからこそ、ああした大規模開発が
できたんじゃないかって。だから、結局人の問題なの
かなって。例によって我田引水なんですけど (笑)。
--
http://practical-scheme.net/wiliki/wiliki.cgi?Shiro
Shiroさんつながりでこれも張っとこう。(2007/09/05
21:24:33 PDT)の記事ね。
P.Graham氏の記事へのリンクじゃなくって、わざわざ
Shiroさんのコメントに張るのは、そのコメントに意味が
あるから。
もちろん、P.Graham氏の記事も面白い。で、こないだ
すぐ消しちゃった話あったじゃないですか。で、その
中で、『P.Graham氏は意識的に「職業プログラマ」と
いう視点を排除してる』って書いたんですけど。
ここでいう『職業プログラマ』っていうのは、世間一般で
いわれるSEとかSIerのことなんだけど。まぁ、もちろん、
自分みたいなしがないコード書きも含めてだけど。
そういう職業プログラマ的な世界を意識的に排除してる
のがハッキリわかるのね、このP.Grahamの記事からは。
で、消した記事の中でも書いたけど、自分はそれが悪い
とかは全然思ってないのね。『ハッカーの創造によって
支えられる社会』があってもいいと思ってるし。それが
氏の信念なんだし、それを実現するために氏は実際に
動いてるわけだし、それを否定するつもりは全然ない。
--
ただ、一方で、自分は職業プログラマだっていう現実が
あるしね。この現実は現実としてそれほど嫌いなわけじゃ
ないし。
スタートアップがジェットコースターなら、自分らは
トロッコ (笑)。トロッコにはトロッコのよさがある (笑)。
--
発想を変えればよかったんだな。
こないだ書いたのは：
(defun make-pairs (lst)
(let ((copy (copy-sequence lst))
(results '()))
(while (not (null copy))
(let* ((first (pop copy))
(second (pop copy)))
(push (cons first second) results)))
(reverse results)))
だったわけだけど、そうじゃなくって：
(defun each-pair (lst fn)
(if (null lst)
nil
(let ((first (car lst))
(rest (cdr lst)))
(if (null rest)
(funcall fn first nil)
(progn
(funcall fn first (car rest))
(each-pair (cdr rest) fn))))))
にすればいいんだ。
こういうのはフツーの発想なんだろうけど、自分にとっては
結構な『飛躍』なんだなぁ。なんでこれをヒラメイタか
自分でも不思議。なんとなく再帰使ってみたくなったって
いうのがきっかけだったんだけど。
--
ちなみにprognはbegin-endだぜ？
irb(main):001:0> var = begin 1; 2; 3 end
=> 3
irb(main):002:0> var
=> 3
これ豆知識な。
Lightweightの反対側はHeavyweightじゃない。 Hardなんだ。 柔らかいのがいつもいいとは限らない。 ガチガチでビンビンがいいときだってあるだろ？
『On Lisp』に『抽象化への投資』という話があります。 こういう『投資』の話はXPE 1stにもありました。 こういう投資をするときは、それがペイするかどうかを 見極めることが大切です。K.Beck氏は、それを金融で いうところの『オプション』で説明していました。が、 正直、自分にはわかりにくかったです。 結局のところ、こうした投資も『占い』、あるいは『賭け』に なることが多いんじゃないでしょうか。こういう占いは、 当たれば印象に残りますけど、外れても気のつかない ものじゃないでしょうか。失われた時間は返ってこない のに。 だから、やっぱり目の前に利益があるならやるという 態度でいいんじゃないかと思うんですよね。たとえ、 それが『スッキリしたい』といった感情を満たすための ものだけでも。 もちろん、感情を満たすためだにコードをいじるのは、 これはこれで失敗のレシピなんですけど。でも、『だから どうした？』ってヤツです。反省すべきは反省して、 そうじゃなきゃ開き直るくらいの度胸も必要でしょう。 それと、コードを砕くだけならためらう必要はないです よね。だって、コードを砕くこと自体に価値があると 決めたわけですから。『たくさんの小さなカケラ』は、 『単純さ』と同じくらい価値があることだと自分たちは 決めたわけです。 『オレはその「自分たち」には入ってなんかねーぞ！』 っていう人も当然いるでしょうし。それはそれでしょうが ない。やり方は1つじゃないでしょうしね。 -- なんか言い訳くせーから消しとくわ。 -- 8月31日の彼にこの曲を捧げたい： http://youtube.com/watch?v=zLyDrZ16tWk 人間とは、人間とは、どんな生き方をしてようとも、 それだけで美しいものじゃないだろうか。
バッファに：
2007-09-04 Tue 08:09:06
2007-09-04 Tue 08:25:41
みたいな行があって、その先頭でマークして終わり (の次の
行) でM-x insert-difftime。すると：
2007-09-04 Tue 08:09:06
2007-09-04 Tue 08:25:41
00:16:35
となるシロモノ。なんだけど、listからalistの作り方
(make-pairs) がダッセー気がする。
(defun insert-date-and-time ()
"Insert the current date and time."
(interactive "*")
(let* ((time (current-time))
(dow (week-abbrev time))
(fmt (concat "%Y-%m-%d " dow " %H:%M:%S")))
(insert (format-time-string fmt time))))
(defun date-and-time-to-seconds (date-and-time)
"date-and-time format: 2007-09-04 Tue 08:59:10"
(let* ((strs (split-string date-and-time))
(normalized (concat (car strs) " " (nth 2 strs))))
(float-time (date-to-time normalized))))
(defun difftime (old-date-and-time new-date-and-time)
(let ((oldsec (date-and-time-to-seconds old-date-and-time))
(newsec (date-and-time-to-seconds new-date-and-time)))
(truncate (- newsec oldsec))))
(defun difftime-string (old-date-and-time new-date-and-time)
(let ((diff (difftime old-date-and-time new-date-and-time)))
(let ((s (% diff 60))
(m (% (/ diff 60) 60))
(h (/ (/ diff 60) 60)))
(format "%02d:%02d:%02d" h m s))))
(defun range-lines (start end)
(let ((text (buffer-substring start end)))
(split-string text "\n")))
(defun make-pairs (lst)
(let ((copy (copy-sequence lst))
(results '()))
(while (not (null copy))
(let* ((first (pop copy))
(second (pop copy)))
(push (cons first second) results)))
(reverse results)))
(defun insert-difftime (start end)
(interactive "r")
(let* ((lines (range-lines start end))
(line-pairs (make-pairs lines)))
(dolist (pair line-pairs)
(if (not (string= (car pair) ""))
(insert (difftime-string (car pair) (cdr pair)))))))
結局、怠惰の文化っていうのは、L.Wall氏がいうように、
ラクをするために汗をかくのを厭わないということ。そう
した矛盾を矛盾と感じずにやってしまう人が、この世界で
生き残っていくんじゃないでしょうか。
--
h = {:a => 1, :b => 2, :c => 3}
a, b = h
なんていう多重代入文はどうだろう？
でも、そういうのは一種のコピペと変わんなくって。 なら、Javaが格別ひどいっていう話じゃないんじゃない ですかね。 PHPだったらPEARだし、PerlだったらCPANだし。Rubyは たまたまそういうのがないっていうだけで (笑)。 自分は再発明大好きな人間ですから。でも、こういう 人間は、仕事っていうコンテキストの中だと「酔狂」に 分類されちゃうんだと思うんですよね、イマドキは。 doukaku.orgとかゴルフとか流行ってるじゃないですか。 ああいうふうに、「手ごろな問題」に燃えちゃう人間って いうのは、結構珍しいんだと思いますよ、セケンイッパン には。 だから、コピペはコピペで勤勉な文化で、そういうのを 好きか嫌いかとか、善しとするか不可とするかとか、 そういう話じゃないかと思うんですよね、自分は。
いつもいつも同じ心の状態でコードが書けるわけじゃ
ないし。だから、コードに揺らぎというか、感情が込もって
しまうのはしょうがないというか。むしろ自分は、そう
いうことを積極的に肯定したい。
衝動に突き動かされて、勢いのままにまかせてコードを
書いたっていいじゃないかっていうね。グダグダなときは
グダグダなコードでいいじゃないかっていうね。
もちろん仕事だと一人よがりなコードって書けるもんじゃ
ないけど。だから、いつかは心を落ち着けて反省するときが
来る。そういうときは真摯な態度で臨まないといけない。
--
『On Lisp』のp.34からはじまる話で：
(defun imp (x)
(let (y sqr)
(setq y (car x))
(setq sqr (expt y 2))
(list 'a sqr)))
っていうのと：
(defun imp (x)
(list 'a (expt (car x) 2)))
っていうのを比べて、あとのほうが短くて、理解も容易
だっていってんだけど。短いのはともかく、理解しやすく
なったかどうかは微妙じゃないの？ いや、自分で書くと
してもあとの書き方で書くかもしんないけど。
理解のしやすさっていうのは個人差がある話だから。
こういうのを『容易だ』って自信満々で言い切るのが
P.Graham氏の、よくいえば『言葉のマジック』、悪くいえば
『引っかけ』なんだよな。まぁ、それが魅力の1つでも
あるんだけど。
--
P.Graham氏のいうボトムアップ・プログラミング、あるいは
関数型プログラミングの特徴の1つは、lots of little
piecesにあるようだ。そこに至るまでの過程は、他のやり方と
違うかもしれないけど。でも、最終的にlots of little
piecesな状態になるということ。
ただ、Lisp系の文化なのか、名前を節約したがる傾向が
ある点に留意する必要はある。
参考：http://c2.com/cgi/wiki?SeparateTheWhatFromTheHow
自分でも結論は出てないんだけど。 最終的な目標はonce and only onceにある。でも、だから といって、すぐ目の前にある重複を取り除いていいかどうか。 小さな重複の除去が悪手になる可能性は結構高いんじゃ ないだろうか。小さな重複をなくすことで、より大きな 重複が隠されちゃうといったような。 一方で、コードを砕くことが悪手になることはまずない。 ここでの『コードを砕く』というのは、メソッドを切り 出すこと。 だから、まずコードをできるだけ砕く。そして、砕くことで 露わになった重複を取り除く。重複を取り除くときは、 できるだけ大きな視点でやるほうが効果的だから。 コードを砕くという意味では、クラスを切り出すことも 考えられる。でも、メソッドを切り出すのに比べると、 クラスを切り出すのはずっとむずかしい。クラスを切り 出すのと、重複を取り除くのと、どっちを先にやったほうが いいか、ちょっとわからない。『場合による』ってヤツか。 目の前にある重複を取り除くことと、コードを砕くことを 同時にやりながら進めることもできるんだろうけど。それが 効果的かどうかがわからない。 -- いや、みんな大規模開発のことを誤解してるというか。 実態を知らないんじゃないかと思う。 コード量の面からいっても、人数の面からいっても、 大規模開発っていうのは保守の面がものすごく強い。 新規機能を追加するときでも、既存のコードと擦り合わせる 必要がある。ぶっちゃけ、誰が書いたかわからないコードを いじったり読んだりすることが多いということ。 だから、大規模開発に参加する人間にとって重要なのは、 システムを理解すること、つまり、既存のコードを理解 することになる。 この『システムを理解する』という点においては、 『コンパイラのための型』という意味での静的型という のは、そんなに有効じゃない。理解するのは人間なんだ から当たり前。 いい？ 型を否定してるわけじゃないのよ？ Rubyにだって 型はあるんだから。ここでいってる型っていうのは、 ソース・コードに現れる型のこと。Rubyでいえばクラス 定義だよね。 人間がシステムを理解する上では、型というのは非常に 有効なわけ。でも、それとコンパイラのための静的型とは 決してイコールじゃない。 -- http://d.hatena.ne.jp/hyoshiok/20070831 ここからリンクされてる記事群でhyoshiokさんが書かれて るのは、結局は『大規模システムを理解するやり方』な わけでしょう。で、自分は、そのやり方は言語によって そうそう変わるもんじゃぁないと思ってるわけ。 コードを読んだり、デバッガで追ったり、テストしたり、 そういうのは言語が変わったくらいじゃ変わらない、基本的な ことでしょう。 で、上でも書いたように、大規模では『システムを理解 する』ことが重要なわけ。だから、言語を変えたくらいで 大規模問題が目覚ましく解決するとか、著しく損なわれる とかは絶対にないって思ってるわけ。 C言語で大規模開発できるのに、なんでRubyでは不可能だと 言い切れるの？ そっちのほうが不思議だわ。C言語なんて、 Haskellerあたりにいわせりゃ静的型言語じゃねぇだろ？ -- だから、デバッガのない言語とかはダメよ？ そんなんは 絶対大規模開発には使えない。そういう点を突いて 『Rubyは大規模じゃ使えない』っていうんなら自分も 強く否定できない。rdbがそんなに使いやすいとは思え ないからね。でも、そうじゃないでしょ？ 型がどうこう とか、そういうとこを突っついてもねぇ。現実的じゃ ないのよね、話が、全然。 -- 規模にかかわらず、過去のしがらみに縛られず、新しい コード起こせるっていうのは、すっげー気楽なのね。 そういうんだったら、別にデバッガのない言語とかでも 全然オッケー。ユニット・テストだけでもかなり違う。 -- まぁ、でも、現実的になれば、Rubyだって大規模やるのは 難しいわな。だって、Rubyプログラマ、100人も集められるか って話になっちまうから。
BUBKA、いましろたかし氏のインタビューが面白い。 この人の作品、読んだことないけど。
Copyright © 1905 tko at jitu.org