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
12
2019
1
2
3
4
5
6
7
8
9
10
11
12
2020
1
2
3
4
5
6
7
8
9
10
11
12
2021
1
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