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

ホーム

2007年02月28日3

そういう意味じゃ、健康なシステムは寡黙なわけだ。
だから、普通だったら見過す『寡黙さ』を、プログラマは
感じ取らなきゃいけないわけだ。『動いて当たり前』を
実現してるのは、『当たり前でない努力』でしかないと
いうことをよく知ってほしい。

--

どういうシチュエーションかによりますけど、攻撃的に
なるのはわるいとばかりはいえないですよね。『ご冗談
でしょう、ファインマンさん』でも、ファインマンさんが
専門の話になると誰彼見境なく反論する (しかも口汚く)
という話が出てましたよね。

はっきりいってスルー力は悪ですから! そんなバズワードに
惑わされちゃダメです (笑)。

本家Permlink


2007年02月28日2

だからさ、ファイルを1ついじっただけで、バーッと
たくさんのファイルのコンパイルが走るわけじゃん?
オレには、それがコードが悲鳴上げてるとしか思え
ないわけ。それでもって、そうした悲鳴に耳をふさぐ
ことができないわけ。プログラミングっていうのは、
そういう感情を大事にするものなの。ただの理屈じゃ
ないの。

本家Permlink


2007年02月28日1

オレは、今の環境で、下請けの、一介のプログラマで
あることに特に不満はねぇんだよな。別に給料なんて
安くたってかまわねぇし。

オレに不満があるとすれば、今目の前にあるコードが
汚いことだけといってもいい。でも、それはオレに
とってはエサみたいなもんで、それがなくなったら、
それこそオレの居場所じゃないってことになる。

だから、こっちは好きで野良犬とかハイエナとか
やってるわけで。ほっとけや。

--

前にも書いたけど、飼い主ばっかりが飼い犬を評価
すると思ったら大間違いだっつの。飼い犬だって
飼い主を評価してるもんだぜ。その視線は結構冷てぇぜ。

本家Permlink


2007年02月28日

これからしばらくの自分のテーマは『The やりすぎ』。

やりすぎとは、つまりはextremeということ。

『お前、それ、やりすぎだろ』といわれるところくらい
までやる。そして、なおかつ、いわれても、なるたけ
つっぱる。

線を越える。

--

ちなみに、『The やりすぎ』は『かほり』(神原則夫作)
より。

--

大雑把にいえば、データの集合があって、それに対する
演算を考えるっていうのが数学的な『抽象化』なんですかね?
で、データの集合に名前をつければ、それは『型』になると。

だとしたら、オブジェクト指向的な、というか、自分の
知ってる『抽象化』とあんまり違いはないんでしょうね。

もちろん、こんなところで違ってたら大変ですけど。

自分が最近よく書いてる『構造で解く』っていうのも、
大体、そんな感じのことをいってるんだと思います。

ただ、自分の場合、数字が生き生きと輝いた存在には
見えないんで (笑)。こればっかりはしょうがないですよね。
だから、オブジェクトのほうが好きなんです。

もちろん、これは『数学的な考え方がダメだ』って
いってるわけじゃないんで、誤解のないように。

で、自分が『問題をオブジェクトで解く』っていわない
のは、『オブジェクトって何?』って返ってくるのを
避けたいから。『構造』だと、なんとなくCの構造体とか
連想してくれそうだし、一般的な意味としても設計の
臭いを感じさせるから。

ああ、そういわれれば、自分の場合、数学的な考え方って
いうと、アルゴリズムのほうに意識が行っちゃう気が
しますね。数学と抽象化が頭の中で結びついていないって
いうか。こないだ書いた『使えない人』っていうのも、
抽象化が下手な人なのかもしれません。このへんは、
こないだ書いた『高度』の話もからんでくるんですけど。

--

でも、数学的な抽象化をプログラミングに活かすって、
やっぱむつかしくないですか? 設計として『層を分ける』
っていうのがよくありますけど、そういうのも数学的な
考え方にはあると思うんですけど、そういうのを実際に
プログラミングで活かすには、やっぱりそれなりに訓練
しないとダメなんじゃないですかね。

--

だって、『わけいっても わけいっても クズの山』じゃ
どうしようもないでしょ?

だから、『わけいっても わけいっても オブジェクト』に
するためにやりすぎるわけ。

本家Permlink


2007年02月26日

失敗を恐れるっていうか、誰かに怒られるんじゃないか
とか、そういうマウンテン・ピーポーなことを考えちゃ
ダメ。

オレたちはフォレスト・ピーポー、森の人、つまりオラ
ンウータンなんだから。ビクビクせず、いいと思った
ことはやろう。悪いことを見過すのが一番よくない。

--

オランウータンは笑うところであって、他意はない。

本家Permlink


2007年02月25日

『Kamipro 108号』に高阪剛氏 (世界のティーケーね、ちなみにほんとはハシ
ゴダカ) がUFCでの体験を語ってるんですけど、それが面白い。

  なんでも事前に決めておく、役割分担がはっきりしている、それで融通が利
  かないってのはアメリカ人の特徴ですね。最初はいちいち腹が立ってたんで
  すけど、慣れてしまうとラクですよ。まかせちゃえばいいわけですから。

  (中略)

  こっちは呼ばれたところに行って、言われたことをやってればいい。そうす
  ると試合だけに集中できるんですね。アメリカ式の細かい役割分担は、そう
  いう面で凄くいいんじゃないですか。アメリカ人っていうのはルールを決め
  て、その枠の中からは出ないんです。でも、そのルールに幅があって、その
  幅の中でいろいろ工夫したり、楽しんだりするのが得意な人たちなんですね。

  日本人はその逆じゃないですか。ルールの幅は狭いんだけど、その隙間とか、
  グレーゾーンみたいなところを見つけだしていく。いい悪いじゃなくて、そ
  の違いがあるだけでしょう。

んで、最後に結論として:

  日本人選手がアメリカで試合をすると、とまどうことも多いと思うんですよ。
  そうならないために大事なのは「何も決めておかないこと」でしょうね。

  (中略) 「会場にバナナくらい用意してあるだろ」と思ったらなかったとか
  ね。そういうことは本当によくあるんで、自分で「こうだろう」って決めな
  いほうがいい。

  (中略) だから、常に起こったことに対してリアクションするだけでいい。
  まかせておけば悪いようにはされませんから。周りのことは気にせず、選手
  は試合だけに集中しておくのが一番ですよ。

--

ベテランのLispプログラマとかけてホームレスと解く。その心は

カッコを気にしません。

本家Permlink


2007年02月24日1

野球選手だって当たり前のように『道具を大切にしろ』
っていうわけじゃん? いや、野球選手に限らず、道具を
使うスポーツ選手なら、誰だって『道具を大切にしろ』
って教わるわけだ。

ただ、プログラマの場合、『道具を大切にしろ』って
いっても、意味に幅がある。『道具の手入れ』という意味
じゃ簡単だ。新しいバージョンにしておけばいい。でも、
『道具をよく知る』という意味だと大変だ。

たとえばプログラミング言語だったら、細かな仕様や
落とし穴といったことや、ライブラリ、あるいは処理系
固有の知識も仕入れとかなきゃいけない。それに、
たとえばgccなんかは、実際にはMakefile書かなきゃ使え
ないし、そうやってイモヅル式に他の道具のことを学ぶ
ハメになる。

だから『道具を大切にする』っていうのは大変なんだけど、
でも、やんなきゃいけないんだな。というか、喜んで
やるくらいの人じゃないと、なかなか勤まらないのかも
しれない。

--

  道具を大切にする気持ちを持つこと。自分の道具は自分で管理して、道具に
  対するこだわりを持ってください。

                      広島東洋カープ・梵英心 (2006年セ・リーグ新人王)
                                     『中学野球小僧 2007年3月号』より

本家Permlink


2007年02月24日

だったら教科書とかなら信じていいのか? だから結局は
正確性みたいなのは相対的なものでしかないし、修正でき
るかどうかが大事だってことじゃないの?

--

Wikiページ、書いてる? 前にも書いたけど、商業サイト
じゃないと書く気になれないとか、ネゴトいってんなよ?
身内にすら読んでもらえるものも書けないで、なんで
外向けに読んでもらえるもんが書けるんだよ。

仕事やっててハマったりするわけじゃん? そしたら原因
調べるわけじゃん? で、なんか解決するじゃん。それで
終わりなの? Wikiがあるのに? 調べてわかったことを
みんなに知ってもらわなきゃダメじゃん?

つまりだ、『5回のなぜ』+ 『1ページ』なわけだ。わかる?
根本原因を追求して、対策を打って、最後にやんなきゃ
いけないのが啓蒙だろ? 啓蒙しなきゃ、おんなし間違いを
他の人がまたやらかしちゃうでしょ?

--

しかしまぁ、このページはwetかつopinionだらけだな (笑)。

本家Permlink


2007年02月23日1

http://d.hatena.ne.jp/habuakihiro/20070223#1172213267
http://d.hatena.ne.jp/tokuhirom/20070223/1172200680

もっともコメントがほしいと思ってた人からコメントが
もらえるというこの喜びこそが、このページを書き続けて
いる原動力の1つです (笑)。

--

昨日上げそこねてたヤツを下に。

--

でも、現場レベルでいえば、スライシングも知らない
連中がC++使ってるんだぜ? そりゃストラップ先生も
あきれちゃうよな。でも、オレにはカイシャの方針も
痛いほどわかる。だって、C++しかねーんだもんな。
で、結局はMSがワルモノだってわけさ。

まぁ、だから、GC参照みたいなヘンテコリンも、ありゃぁ
あれでヨシとするしかないよな。MSも反省したってこと
だろ。オレは使いたくないけど。

--

まぁ、たとえが悪いが兵隊アリと働きアリがいるわけさ。
で、兵隊アリさんのための道具を選ぶか、それとも働き
アリさんのための道具を選ぶかってことになるわけさ。
兵隊アリさんと働きアリさんとで別々の道具を用意でき
ればいいんだけど、さすがにそうもいってらんない。
だから、兵隊アリさんも働きアリさんもおんなじ道具を
使わなきゃいけない。

兵隊アリさんの好みは切れ味の鋭いブツ。働きアリさんの
好みは、切れ味は鈍くっても、みんなが使ってるような
ブツ。でも、選べるのは1つだけ。

こんなとき、まぁ、大抵は働きアリさんの好みで道具を
選んだりするわけさ。でも、そうすると、兵隊アリさんが
がんばんないといけなくなる。『ああ、あのブツが使えれば、
こんなのチョロイのに・・・』とかブツブツいうわけだ。

逆に、兵隊アリさんの好みで道具を選ぶと、今度は働き
アリさんが泣きを見る。『こんなの使えねーよ、チクショー』
とかって。

もちろん、こうした話に正解があるわけじゃない。

で、オレはキリギリスで、兵隊アリと働きアリがケンカ
してるのを笑って見てるだけっていうな。

--

http://fukumori.org/diary/20051113.html

前にも見たんですけど、たまたまググって引っかかって、
いつのまにかコメントが増えてて興味深かったです。

インタフェースが大切だというのは、そのとおりで
しょうね。TDDでよくいわれるのが『インタフェースに
集中する』ってことですから。

http://c2.com/cgi/wiki?TestDrivenDevelopment
http://c2.com/cgi/wiki?CodeUnitTestFirst

インタフェースについて考えるっていうことは、
コンテキストを含むんですよね。どういう使われ方を
するのか考えなきゃいけないですから。で、そうなると、
他者との関係ですから、ちょっと視野を広げないといけ
ないわけです。視野を広げる、あるいは高度を上げるって
いうのは、つまりは設計ということになるわけです。

--

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

当然、自分もM.Fowler氏を支持しますよ。CFooとか、
わけわからん。

--

いいか? 全員で勝つことが重要なんだ。

一人がたくさん勝つよりも、少しでもいいから全員で勝つ。

落伍者を出さない。遅れているヤツがいたら、たとえ
自分が立ち止まってでも手を差し延べる。

それがオレたちのやり方なんだ。

--

以上までが昨日分。

--

またおんなじ話するけど、たとえば出版業界なんかは、
『現在の生産性は1920年代のころと変わってない』
なんて話は出てこないんじゃないの? 製本技術は格段に
進歩してるだろうけど、本の作り方とかが劇的に変わった
わけじゃないでしょ? なんでソフトウェア開発だけが
そんなに生産性に血眼になんなきゃいけないの?

本作ってる人に聞いてみなよ。『いい本作るにはどう
すればいいですか?』って。そんなもん、正解なんて
ないに決まってるじゃん。ただの紙切れ売るんなら、
新聞屋にでもなればいいじゃん。ニッケーみたく。
そうすりゃ輪転機の性能上げれば生産性も上げられるし、
話は簡単だよな。

--

ああ、毎日のほうが紙切れ商売か。

本家Permlink


2007年02月23日

あれ? 新しいのあげといたんだけどな。

--

だから、開発初期に設計したテーブルがショボいことで
大変な目に遭うなんていうのは、「RDBは仕事じゃ使え
ません」っていってるようなもんでしょ?

開発期間全体を通じてテーブルを作り変えることが
できなきゃダメじゃん? オブジェクトは日々変化するのに、
テーブルは不可侵なのかよ、神棚に飾っとくだけかよ。

変化に対応できないんだったらそんなテクノロジーは
死んでしまえ!

--

なんだよ、結局agilerの敵はSQLerだったのかよ。
ガッカリだよ。クソッタレどもめ。

本家Permlink


2007年02月22日1

でもさー、数学にコンプレックス持ってるヤツって
使えなくない? なんか問題を小手先で解こうとするって
いうか。もっと素直に考えよーぜっていいたくなる。

で、オレはソフトウェア工学にコンプレックスを
持ってるってわけだ。あははは。

でもさー、やっぱし設計とかって、プログラミングの
中でしか学べなくない? 少なくとも高校レベルの
数学で型がどうのこうのって、あんましなかったように
思うし。行列とかがそうなの? いや、『問題を小問題に
切り分けましょう』とか習ったかもしんないけど、
だったらプログラミングで教えたほうが早いじゃん?

とか書きつつも、もっと数学やっとけばよかったと
後悔してるんだな、これが。あははは。

--

まぁ、でも、まつもとさんも、Rubyが当たったから
よかったけど、外れてたら、フツーどころか、ダメ
スレスレだったでしょうね。草むしりするのにナタ
持ち出すなよっていう (笑)。まぁ、それは働く場所
間違えてたってことなんだけど。

--

まぁ、あれだよね。もう誰かがいってるだろうけど、
関数型言語が流行らないのは『関数』っていうのが
入ってるからだよね、名前に。
世の中の99%の人は数学嫌いだから『関数』って
聞いただけでヒいちゃうでしょ。

まぁ、『オブジェクト指向』にもそのケがあったん
だけど、最近はそれも薄れたし。

だから、流行らせたかったら、もっと他の名前考え
ないと。『スクリプト言語をLLと呼ぼう』みたいな。

個人的にはカタカナ表記にするだけでもいいと思う
んだけど。カンスー言語。ガタは抜けちゃってるけどね。

ガタを抜きたくないんなら、カン・スー・ガタ言語とかね。
キャンディーズっぽくてウケそう。

数学のプライドを捨てきれないっていうんなら
ピタゴラ型言語なんてどう? 流行ってるみたいだし。

--

あー、数学を使いこなしてる人は尊敬しますよー。

とフォローを入れておこう。

本家Permlink


2007年02月22日

http://www.aoky.net/articles/kathy_sierra/its_not_too_lat.htm

獲物でもよかったけど、やっぱりこっちのほうが
見てる人が多いし、たくさんの人に読んでほしいから。

本家Permlink


2007年02月20日

前にも書きましたけど、Teach Learning同様、
Learn Teachingも重要ですし、それはTeach Teachingを
導き出します。

--

だってXMLなんてロクに見なくない? 手書きでXMLなんて
キチガイしかやらないでしょ? って、Antのときは書き
まくってましたけど (笑)。

--

まぁ、容れ物が好きなのは、メモリ管理が楽だからなんで
しょうね。だから、JavaとかRubyでいうplainなオブジェクト
っていうのと、C++のplainなオブジェクトっていうのは、
かなり感触が違いますよね。

本家Permlink


2007年02月19日2

忘れないうちに、先にこっちを書いておこう。

オブジェクトを信じ、オブジェクトの力を感じる。

オブジェクトを使うとプログラミングが複雑になると
考えている人が多いようだが、実際は逆だ。シンプルに
プログラミングするためにオブジェクトはある。

switch文でこのケース、あのケースと思い悩むより、
ケースをオブジェクトにし、問題を切り分ける。
オブジェクトにした情報は隠されているのだから、他の
問題とは無関係になる。そうすれば、切り出した問題に
集中できる。バカはswitch文が苦手なのだ。

そうやってオブジェクトを切り出していると、よく似た
コードを持つオブジェクトが見つかる。似ているのだから、
まとめられないか考えてみる。そこでクラス階層という
ものが生まれる。『似ている』というのは見ればわかる。
図など描く必要はない。バカは図を描くのが苦手なのだ。

オブジェクトはバカの味方だ。

--

いたるところにモデルがあり、いたるところにビューが
ある。モデルはフレームワークと切り離されているから
こそモデルと呼べる。

--

http://blog.goo.ne.jp/ikkoan/e/36f948c5ee275f62b9c1100cfe8f3aee

あとでかく。

と書いたものの、特に自分が付け足すようなこともなく、
しごくまっとうな意見です。

自分も今、ごく少数の優れた人と、その他大勢のフツーの
人という状況で仕事をしています。もちろん、自分は、
フツーの部類に入ります。そうした状況に身を置いて
感じるのは、餌を待つ人が多いということです。指示を
受ければ勤勉に働くけど、それ以上のことはしないと
いう人たちです。

どこかで一線を越えることをためらっているのでしょうね。
自分なんかは野良犬ですから、クビになってもいいやと
いう感じでやってますけど、フツーの人はそうもいかない
のかもしれません。

でも、善意に解釈すれば、そういう人たちは、やり方を
知らないだけともいえるんでしょうね。設計のやり方を
しらない。agileなやり方を知らない。組織を良くする
やり方を知らない。だったら、何が良くて何が悪いかを
教えればいいだけのことです。教えるといっても、上から
目線じゃなくって、自分の知ってることを伝えればいい
だけです。そういうきっかけがあれば、人は少しずつでも
変わっていくものと自分は信じています。

--

いや、正直いって、昼休み寝るヤツがいるのが信じられないんだけど (笑)
深夜バイトでもやってるのか (笑)

--

そういう点で、総じて自動化の意識が薄い。プログラマと
いうのは、自分のありとあらゆる作業をコンピュータに
やらせることができないか考えないといけないのに、
いわゆる仕事のコードにしか興味がない。しかも、その
仕事についてさえ、たとえばMakefileひとつとっても
『誰かが書いてくれる』ものだと思ってる節がある。

すべてが他人任せのシステムは、早晩腐るのは明らか。
システムを良くするのはあなたしかない。組織を良くする
のはあなたかしかない。

本家Permlink


2007年02月19日1

ダメ。プログラマは、何もなくても常に最適化しようと
する生き物なんだから、逆に最適化しすぎないように
気をつけるべき。リニアサーチ上等。

プログラミングっていうのは、プログラマの意図を明らかに
するもので、機械の都合は後回し。速度は非常に深刻な
問題になりやすいんだけど、そのためにも意図をはっきり
させることを最優先する。意図をはっきりさせておけば、
間違った最適化をしないで済む。

それと、コード・レビューとかやってると、速度って
いうのはツッコまれやすいんだけど、はっきりいって
最適化のためにコード・レビューをやってるんじゃなかったら
そんなもんに時間を割いちゃダメ。軽く流して済ませる。

速度が重要なら、開発の初期段階からそれを考えに入れて
おくべきで。そのためにもシステムを早くから独り立ち
させることが大切。速度は現実の環境で問題になるん
だから。

他の6個は問題ないし、XPにも沿うものなんだけど。

--

フフ。でも、そういうジェラスィは重要だって、okujiさんも
いってましたよ。目標を持つのはわるいことじゃないですし。

本家Permlink


2007年02月19日

さえない。

本家Permlink


2007年02月18日

『世界樹の迷宮』だけどさ、さんざんいわれてるんだろ
うけど、ハガレンの人は噛んでないんでしょ? ちょっと
気になる。グラフィックだけならまだしも、ストーリーも
なんとなくハガレンっぽい。自分、ハガレンの悲劇的な
ストーリーが好きになれなくって読むの止めちゃったん
だけど、それと同じ臭いがする。

いいわるいは別にして、好みとしては、能天気なほうが
好きなんだよなぁ。だから、ファイアーエムブレムも
悲劇的なのはあんまり好きじゃなかったりする。

--

これもさんざんいわれてるんだろうけど、ポケモンが
子どもに人気なのは、モンスターを殺さないっていうのも
理由の1つにあるんだろうなぁ。まぁ、友だちどうしで
バトルとかはするんだろうけど。でも、捕まえるのと
殺すのとじゃ、えらい違うよな。

永劫の玄王とかさ、最初わけわかんなくって殺しちゃった
けど、あれなんか、何もしなけりゃおとなしい生き物じゃん?
ノロノロしか動かないし。でも、殺さないと図鑑が完成
しないんだな、これがまた。

こういうのを気にするようじゃ、RPGなんてできないんだ
けど。

本家Permlink


2007年02月16日2

http://kakutani.com/20070215.html#p01

相変わらず素晴らしい内容。

--

SEGAの人であるとか全然知らなくって、記事が面白いから
読んでただけなんですけど。radiumさんもそう。どこの
人とか全然気にしないで読んでました。

やっぱりゲームやってる人は面白い人が多いんだよなぁ。
まぁ、ゲームやってる人って、プロセスとか敵視してる
ことが多いし、プロセスやってる人はほとんどがSIer
みたいな感じだし、なかなか交わらないんだけど、自分
としては、やってることは変わらないと思ってて、少なく
とももっとゲームの人側からの発言があったほうがいい。

自分はバーチャに直撃されたクチですから (笑)。

--

「紛い物の知性」といったらそれまでですけど、PragProgの
いう「触媒」というのは、そういうものだと思うんですけど。

たとえば、自分らプログラマというのは、大抵の場合、
ドメインの知識に乏しいものです。それでも、顧客の協力を
得ながら、価値あるシステムを作らなきゃいけない。じゃあ、
自分らプログラマは紛い物なのか?ということです。

本家Permlink


2007年02月16日1


本家Permlink


2007年02月16日

Googleは研究所みたいなもんかもしれませんけど、
でも、研究所持ってるからっていって、そこが技術の
会社と決まるわけじゃないですよね。結局はアウトプットで
決まるわけでしょう。自分で得た技術をどう外に出すか
っていう話で。研究所だっていっても、外に出しにくいん
だったら、意味がないでしょう。だから、自分で技術を
得る努力をして、なおかつ得た技術を外に出す努力も
するっていうのが技術の会社の本分なわけです。そういう
のは会社の規模には関係のない、会社としての姿勢な
わけで。Googleみたくカネ集めなきゃできないなんて
話をしてるわけじゃないんです。

--

だから、アウトソーシングとかばっかりやってるんじゃ、
看板がどうあれ、それも口入れ屋と大して変わらないで
しょう。アウトソーシングは、外に種をまくためだったら
意味ありますけど、安く上がるとかは、まぁ、意味なくは
ないけど、つまんない話で。outseedingのほうが面白そう
でしょ?

本家Permlink


2007年02月15日

http://www.atmarkit.co.jp/news/200702/13/cyx.html

こういう言葉にしちゃうとチンプな感じがしちゃうんだ
よな。そこらへんがむつかしいところなんだけど。

だから、やっぱり、ソフトウェア開発に他の産業の
メタファを当てはめようとするのは危険なんだろうな。

たとえば:

  現代のソフト開発の生産性は1920年代の自動車産業並

みたいな言葉だけが独り歩きしちゃうと、「じゃあ、
現在の自動車産業並にしよう」みたいな話になっちゃう
じゃん? そうじゃないじゃん? 自分らが作ってるのは
工場そのものであって、工場で作られる製造物を作って
るわけじゃないじゃん?

--

話を聞くレベルだけならGoogleとかはてなとかスタロジ
とかありますけど、まぁ、実際に見たわけじゃないので
何ともいえません。少なくとも自分がこれまで関係した
ところでは皆無でしたけど。

本家Permlink


2007年02月14日

自分が問うのは、会社という組織の技術に対する姿勢。

たとえば、資格取得を奨励するだけじゃ、それは他人
任せといわれても仕方ない。顧客の要望に合わせて
言語を選ぶようでは仕方ない。組織としてどのような
技術を指向し、それをどう組織のメンバに習得させて
いくかを考えるということ。

だから、組織のメンバ個々の契約形態はそれほど問題
じゃない。でも、組織的な対応がなくて、SES契約ばっかり
とか、受注ばっかりやってるとしたら、その会社は技術の
会社じゃなくって単なる口入れ屋だ。

本家Permlink


2007年02月13日

自分は、受難思想っていうか、試練思想っていうか、
そういうのを持ってるんです。「これは」と決めた道を
歩いていると、しばらくして必ず困難に出会うと。
「退くか、それともそのまま進むか」っていう。まぁ、
「天に試されている」っていうか。だから、そういう
ときは踏ん張りどこでもあるんです。

--

ああ、もちろん、試練といっても、常識の中での
話で。肉体の限界とか、そういうのはプログラマの
世界の話じゃないんで。

--

ああ、こないだのアリアドネの糸の話は、「世界樹の
迷宮」をやる前に書きましたからね。一応念のため。

アマゾンに注文したら2週間くらい待たされるしな。
金曜の夜届いて、おかげで連休は世界樹漬けですよ。

本家Permlink


2007年02月09日

自分は「Accelerated C++」は勧めません、というのは
以前にも書いたことがありますが。

入門書というからにはプログラミング・スタイルも良い
ものを学べるべきですが、あれはダメ。絶対的なコード
量が少いし、非常に前払い的なスタイル。

何もTDDばかりがいいとはいいません。でも、インクリ
メンタルなプログラミング・スタイルというのは、K&Rの
ころからある伝統的かつ良いプログラミング・スタイル
の1つです。

本家Permlink


2007年02月08日2

プラグマティック・プログラマズ・ジョーク

家に帰ったら身重のワイフが飛びついてきて、こういったきたのさ

  あなた、喜んで! 双子よ!

そこでオレはこういってやったのさ

  おいおい、そりゃDRY違反だぜ

ってね。

--

関数型プログラマズ・ジョーク

こないだのカンファレンスで講演やったんだけど
舞台に立つときにアガらないようにって
手の平に『人』って字を書いて飲み込むってのをやってみたんだ
でも、間違って『λ』って書いちゃって余計アガっちゃったよ
これぞほんとの後悔関数

--

これまで何回かマリーシアのことを書いたけど、でも、
誠実さが技術者のメイン・ウェポンなのね。ただ、人との
出会いばっかりは運だから。誠実なだけじゃやられる
ばっかりっていうときもあるでしょ。そんなときに
マリーシアなわけ。年がら年中ずる賢くやれっていうん
じゃないから。

本家Permlink


2007年02月08日1

今回も当たり前のことを書こう。

ソフトウェア開発というのは芸術的側面と手工業的側面を
持つ。どちらに重きを置くかはビジネスによって決まる。
Googleのようなところでは芸術的側面に重きが置かれる。
しかし、一般には、手工業的側面に重きが置かれる。

手工業的側面で重要になるのは予測可能性。作業がいつ
ごろまでに終わりそうか、予測の立てやすいことが重要視
される。

話をちょっと変えよう。人生にトラブルはつきもの。
であるなら、ソフトウェア開発にもまたトラブルは
つきものといえる。

トラブルが起これば、作業が遅れる。遅れた時間を取り
戻すことはできるだろうか? 大抵の場合、遅れた時間を
取り戻すことはできない。また、取り戻そうと躍起に
なれば、悪循環にはまる。

取り戻すべきはリズム、あるいはペース。

ここで話を戻そう。予測可能性とは、リズムがあってこそ
予測できる。瞬間的な速度があっても、波があるのでは
予測しにくい。多少遅くても、波のないほうが予測し
やすい。また、リズムを取り戻そうにも、そのリズムを
知らなければ、取り戻しようがない。

だから、リズムを意識することが大切になる。

--

遅れを取り戻す場合、個人の力ではどうにもならない
ことのほうが圧倒的に多い。そうした場合に必要に
なるのは組織としての対応。

組織としての対応で、もっとも単純な対応策としては
増員があげられる。期日を重要視するなら機能を減らす
ことも考えられる。設備にお金をかけることで直接的、
間接的に対応することも考えられる。

いずれにしても、遅れを取り戻す場合には、個人の
力よりも組織の力のほうが効果的。となると、やはり
個人のレベルでできることといえば、リズムを取り戻す
ことくらいしかない。

--

熱くなるのもいいけど、『穏やか』の大切さも知ってほしい。

本家Permlink


2007年02月08日

ビットの中にはゼニが埋まっとるんじゃ!

本家Permlink


2007年02月07日1

『テストしにくいコードは設計がまずい』ということは
何度か書いています。これも、昨日と同じように逆手に
取れば、テストしやすいコードになるように考えることで
良い設計が得られるということになります。

極端な話、大きな一枚岩のモジュールをテストするよりも、
小さくて独立したモジュールのほうがテストしやすいです。
そして、もちろん、小さくて独立したモジュールという
のは、良い設計の目安です。

一方、テストをするためには、内部状態を外に晒さなければ
なりません。そうすると情報隠蔽を壊すことになります。
単純な例でいえば、アクセサが増えるということになり
ます。情報隠蔽を壊すのは、もちろん悪い設計の兆候です。

けれども、自分は、これをそれほど深刻な問題とは思い
ません。小さくて独立したモジュールならば、多少
内部状態が過度に晒されても問題になることは少ないです。

また、内部状態を晒さないために、モックを使うという
やり方もあります。モックを使うと、プログラミング・
スタイルがガラッと変わります。パラメータ・オブジェクトを
多用するようになります。そうすると、オブジェクトが
インスタンス変数を持たなくなります。インスタンス
変数の少ないオブジェクトは良い設計の兆候です。ただし、
モックは、プログラミング言語によっては高価な選択に
なります。

本家Permlink


2007年02月07日

あれ、おかしいよな。書きたければ、書かなきゃ
いけないんだったら書けばいいだけのことじゃん?
何も技術系の商業サイトじゃなきゃ書く意味がない
なんてことはねぇだろ? それって結局、宣伝したい
っていってるのと同じじゃん? だったら最初っから
そう言え。

--

集団で作業するなら、当然並列でできるものはそうした
ほうが効率がいい。でも、落とし穴がある。それが結合。

結合のコストを低く見積もるというは、まずい管理者が
よくやること。結合を先延ばしにして、いざ結合すると
いう段になって、結合のコストの高さに気づく。

XPでは、そうした事態を避けるために、結合を頻繁に
やる。開発初期であれば、たとえ小さくても独り立ち
できるシステムを目指し、それ以降はシステムを常時
結合された状態にする。

本家Permlink


2007年02月06日

テストは、テストされる機能の存在を証明するためにやる。これを逆手に取る
のがユニット・テストを伴うリファクタリング。ユニット・テストによって機
能の存在が証明されている限り、モデル・コードをいくら変えようが構わない。
これを後の先のテストと呼ぼう。

また、テストが通れば機能の存在を証明できるということもできる。だから、
まずテストを先に用意して、それに通るようなモデル・コードを書いていく。
これがテスト・ファーストであり、先の先のテストと呼ぼう。

テストは従来は受け身でやるものだったが、上のように、後の先あるいは先の
先という攻め手として利用することもできる。

--

『一通り実装が終わったので、これからコードを整理するつもりです』ではダ
メ。整理されていないコードとは、つまり設計のまずいコード。設計のまずい
コードは借金といわれる。借金は常に少ないほうがいい。

--

仕事でのプログラミングは、時間のプレッシャーとの戦いでもある。ただし、
時間のプレッシャーを強く感じすぎてはよくない。強すぎる時間のプレッシャー
は、悪循環の最初の一歩。時間のプレッシャーを強く感じると、仕事がやっつ
けになる。やっつけだからバグは減らない。バグが減らないと帰りが遅くなる。
帰りが遅くなれば体調を崩す。体調を崩せば仕事を休むことになり、時間のプ
レッシャーがさらにきつくなる。

ただし、時間のプレッシャーは現場のプログラマではどうにもならないことも
ある。そうなると、仕事を辞めるか死ぬかの二択しかない。

--

エラソーなことを書いてると思われるかもしれないけど、自戒を込めてという
のももちろんある。プログラマの能力としては、自分は平凡以下といったほう
が正しい。だから、腹が立つなら読まないほうがいいし、軽く読み流す程度で
も構わない。

本家Permlink


2007年02月05日1

Wardは『分類の支持者ではない』といいつつ、CategoryName
による分類は絶賛してるんだよね? (正確にいうと、
そういう慣習が自然と生まれた活発なコミュニティを
絶賛してるんだろうけど。) 

classifyがダメでcategorizeがいいのかと思って混乱
したよ。ここではどっちも『分類』でいいはず。

本家Permlink


2007年02月05日

O社? 岡本理研?

本家Permlink


2007年02月04日3

http://jscheme.sourceforge.net/jscheme/doc/whatsnew.html

JSchemeって面白そうと思ってサイトを漁ってたら、上の
ページを見つけてビックリ。どっかで読んだ話だと思ったら、
やっぱり新山さんのとこで読んでた:

http://tabesugi.net/memo/2005/13.html#241545

改めてご冥福を祈ります。

で、JSchemeで面白いと思ったのは、Javadot notationと
呼ばれる表記法。

http://jscheme.sourceforge.net/jscheme/doc/javadot.html

いかに手軽にJavaのライブラリを使えるようにするかっ
ていうのが、こうした処理系の腕の見せどころだと思うん
ですけど、これはなかなかよさそう。

これで正規表現がfirst-class objectだったら、ぜひとも
試したいところなんですけど。

--

結局のところ、GUIと正規表現が手軽に使えれば、そこそこ
便利な言語になるんじゃないか仮説。

--

http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Lisp%3aS%e5%bc%8f%e3%81%ae%e7%90%86%e7%94%b1

一番下に追加されたShiroさんのコメント:

  Lisp設計者は、自分より言語ユーザの方が、そして現在のユーザより未来の
  ユーザの方が、賢いと考えている

これは、Lisp設計者に限らず、設計する者すべてにとって
大事な態度の1つだと思います。その態度がどういう形で
具体的に現れるかはともかく (笑)。

XPでは、『明日のための設計はしない』といったことを
いいますね。『明日のために』と思って設計しても、その
『明日』が来ないかもしれない。あるいは、その『明日』
までにもっといいやり方を学ぶかもしれない。それなら、
今日のために設計しよう。今日の問題を十分に解決できる
程度に単純に設計しよう。そして、もしついに『明日』が
来たとしても、設計はすでに単純になっているのだから、
変化に対応するのも容易だと。もちろん、他にもユニット・
テストとか、そうした態度を支える仕組みもあるんです
けどね。

--

ああ、Schemeに転向するとか、そういうのは今のところは
ありません。

本家Permlink


2007年02月04日2

ああ、クラスを切り出そうとしない心理っていうのは、
多分、Wikiページを切り出そうとしない心理と似てるん
だな。それがいかに愚かなことであると、どうすれば
わかってもらえるのだろうか。

Wikiでいえば、検索のしやすさがページの命だ。検索した
ときに引っかからないのでは、そのページは存在しないに
等しい。その著者はページの場所 (つまりWikiName) を
知っていても、他は誰も知らないのだから。他の人が
知らないんだから、他の人がまた同じことを書くハメに
なる。情報が蓄積されない。

よくありがちなのが『誰々さんのページ』ってヤツだ。
もちろん、自分もやってるけど。でも、そんなページに
雑然と情報が並んでたって検索しやすさが上がるわけが
ない。検索結果っていうのはWikiNameが並ぶわけで、
そこに『誰々さんのページ』なんていう文字列よりも
『何々について』っていう文字列があったほうが
うれしいのは当たり前じゃないか。

考えればすぐわかることなのに考えない、それを愚かと
いわずして、何を愚かというのか。

クラスとかWikiページに『もったいない』みたいな感覚を
持つのは止せ。

本家Permlink


2007年02月04日1

http://www.artima.com/intv/wiki.html
http://www.artima.com/intv/ownership.html
http://www.artima.com/intv/clay.html
http://www.artima.com/intv/extreme.html
http://www.artima.com/intv/simplest.html

それぞれが3〜4ページあって読むの大変なんだけど。

あと、上のURLを削ると:

http://www.artima.com/intv/

っていうページもあって、こっちもおいしそう。
読むの大変だけど。

本家Permlink


2007年02月04日

日本人は型が好きなんだろう。ここでいう型はプログラ
ミングとは関係ない。武道なんかでいう型のことだ。

型と聞いて、ほとんどの日本人が思い浮かべるのは、
この武道的な型のほうだろう。たとえば相撲では、
『この関取は自分の型を持っていますからねぇ』などと
よくいわれる。そして、ほとんどの人は、その解説を
聞いても『カタってナニ?』と疑問には思わず、『ああ、
そうか』と納得できる。

多分、欧米で型、つまりパターンというと、模様のことを
真っ先に思い浮かべるんじゃないだろうか。

そもそも、こんなことを考えたのは、sheepmanさん経由で
オタ芸のビデオを見てしまったからなんだが。この
没個性的な踊りにしか見えない身体動作にしても、それが
1つの型であると思えば、なんだか日本人らしい振る舞いに
思えてくる。自分でやりたいとは思わないが。

ただ、型とマニュアルは違うということはいえるだろう。
型は、いってみれば基本のことだ。型を守れば勝てる
わけではない。場面に適した型を取捨選択し、さらには
そこで新しい型を生み出してこそ、型というものが活きて
くる。

--

本来、『治具』というメタファは不要だったはずなのだ。
なぜならプログラミングには『ツールボックス』という
メタファが存在していたからだ。だから、問題なのは、
この『ツールボックス』というメタファが、プログラミ
ングから失われてしまったことにある。

ツールボックスのメタファは、いうまでもなくUnixの
伝統だ。また、スクリプト言語は、ツールボックスに
入れる道具を作成するための言語だった。

なぜツールボックスが失われてしまったか。もちろん、
Unixの没落は大きい。それ以外には、プログラミングを
大げさなものと捉える風潮が出てきたのではないか。
スクリプト言語を知らない人にとって、プログラミング
とはIDEで作業することなのだ。

しかし、それほど悲観する必要はなくなっているのかも
しれない。1つはオープン・ソースの隆盛。ソースが
あれば、目的に合わせてツールを改造することができる。
2つ目が、スクリプト言語が再び盛り上がりを見せている
こと。3つ目が、自動化に注目が集まっていること。

プログラマとは、プログラムを書く人のことであり、
プログラム化される対象は、そのプログラマのすべての
活動に広げられなければならない。いわゆる納品物だけ
でなく、プロジェクトを円滑に進めるための道具、
あるいは、プログラマ個人の作業を円滑に進めるための
道具、そういったプログラムを書くこともプログラマの
仕事なのだ。

--

しょぼい例で申し訳ないが:

http://www.jitu.org/~tko/cxx/clipath/

これは、コマンド行引数をクリップボードにコピーする
ためだけのアプリケーションだ。

これを作ろうと思ったのは、Windowsでファイル・
オープン・ダイアログを開いたときに、クソ長いパスを
一々入力するのが面倒だったから。

スタート・メニューにこのためのフォルダを作り、.exeを
置く。さらにそのフォルダの中で.exeへのショートカットを
作る。そのショートカットでコマンド行引数を指定して
おく。もちろん、ショートカットの名前もわかりやすい
ものに変えておく。

こんなものをわざわざここで紹介することもないのだが、
ツールボックスの一例として取り上げてみた。似たような
アプリはすでに存在しているのだろうが、そんなことは
気にならない。探すより作ったほうが早いのだから。

本家Permlink


2007年02月03日1

チームで一番ページを起こす男 (推定、ただしストーリーは
除く) からすると、あのRecentChangesは不便極まりない。
だって、出てくるのはほとんどストーリーで、オレから
したら、そんなのはどうでもいい (DDE) からだ。いや、
どうでもよくはないけど、RecentChangesで見たいのは
ストーリーじゃないってことだ。Wikiを日記代わりに
してる人もいて、チームで一番の日記マニアな男から
すると、そういうページこそが見たいし、そのための
RecentChangesであるべきだ。

本家Permlink


2007年02月03日

いや、Python知らないから間違ってるかもしれないけど、
あれ、なんでこう書かないの?

def getit1(x):
  return 0

def getit2(x):
  return 0

def getit3(x):
  return 1

def func(a):
  return 2

def lookup(x):
  a = getit1(x)
  if a:
    return func(a)
  a = getit2(x)
  if a:
    return func(a)
  a = getit3(x)
  if not a: raise KeyError(x)
  return func(a)

print lookup(0)

--

ワロタ。

でも、レーザーがそんなに電気喰うなんて知りませんで
した。ブラザーは、ずいぶん前に、sheepmanさんが
『イイ!』って書いてて、ずっと気になってたんですけど。

--

tgifを使わないみねろうさんなんてララ〜ラ〜ララララ〜

本家Permlink


2007年02月02日

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

なんかLisperが喜びそうな・・・

--

http://radar.oreilly.com/archives/2007/02/data_is_the_int.html

ちょっとショック。

自分みたいな古い人間の感覚からすると、たとえば
tokuhiromさんとか、wotaさんがRDBの話するのは信じられ
ないのね。OODBならまだしも、RDBなんだから。

RDBって、どっちかっていうと傍流だったのね。
もちろん、ビジネスの現場では主流だったんだろうけど。
でも、上に書いたみたいな人たちが扱う話じゃなかったのね。
自分らの世代でも、どっちかっていうとレガシーっぽさが
漂ってたし、それが自分よりも若い世代のバリバリの
人がやってるってんだから。

まぁ、RDBの人からいわせりゃ『ザマーミサラセ!』って
感じなんだろうね (笑)。

もちろん、こういう現象が起きているのは、RDB自体の
お陰じゃなくって、Webのお陰なんだけど。ちょっと前で
いえば、できる人はCGやってたような気がする (笑)。
で、たまに『コンパイラ作ってます』みたいな人がいたり。
そういう人たちは、どこ行っちゃったんだろう。

すっごいアヤフヤな印象なんで、信用されても困っちゃう
けど (笑)。

--

不思議に思うんだけど、どうもクラスを切り出すことに
抵抗があるみたいなんだな。クラスが増えることが、
さも混乱の原因になると思ってるかのようだ。

逆だ。混乱を避けるためにクラスを切り出す。

XPのように、設計を前払いしない場合、コーディングし
ながら構造を見つけることが大切なんだ。構造というのを
型と言い替えてもいい。そして、型っていうのは、
つまりはクラスのことだ。見つけた構造をクラスとして
切り出すことで混乱を避けるんだ。

コードの中から構造、つまりはクラスを見つけるのは
そんなに難しい話じゃない。たとえば、たくさんの
メソッドを持つクラスがあったとしても、そのメソッド
群は、いくつかのグループで構成されているのがフツーだ。
そういうメソッドのグループを1つのクラスとして切り出せば
いい。切り出したメソッドの間で、共有すべきデータが
あれば、それをインスタンス変数にすればいい。もっと
難しい話もあるし、デザイン・パターンみたく、最初っから
切り出されたクラス群を導入することもあるけど、基本は
こういうこと。

それと、シンプルに考えること。設計っていうのは、
何もコードをギューギュー詰め込むことじゃない。
設計っていうのは、シンプルさの追求なんだ。
シンプルなものとシンプルなものを組み合わせることで
複雑な機能を実現する。一見すると難しいことのように
思えるかもしれないけど、それを可能にするためにやる
のが設計という活動なんだ。

多分、『シンプルさの追求が大切だ』っていうことには、
みんな同意してくれるだろうけど、でも、ほんとにその
ことがわかってるのかな?

上で書いたように、シンプルさとコードの行数は全然関係
ない。シンプルに書けば行数が増えることだってある。
にもかかわらず、ただ行数が増えるからという理由だけで、
シンプルさの追求とは反対のことをしちゃうんじゃないかな?

あるいは、シンプルに書くと、他人からバカにされるん
じゃないかと心配になる。そこで、ちょっとひねろうと
すれば、もうそれはシンプルさの追求じゃなくなって
しまう。

最近、『ベタに書く』って度々書いてるけど、それは
つまり『シンプルに書く』ってことでもある。シンプルに
書くからこそ、構造が見つけやすくなるんだ。ひねって
複雑に書くのは、いってみれば局所最適化で、よけいに
複雑を招くだけ。シンプルに書いて、構造を見つけて、
ガッとコードをわしづかみにする。そういうところに
設計の醍醐味を感じてほしい。

本家Permlink


2007年02月01日

『Number』、自分が嫌いだといってはばからない雑誌
ですけど、やっぱりオシム監督となると読まざるを
得ません。

前にも書きましたけど、働くことは、働くこと自体に
価値があるというのが、日本人の考え方のはずです。
『働きがい』イコール『生きがい』という考え方です。

そして、日本人が働くことが好きならば、その方向に
何事も進んでいかないと意味がありません。それが
多様性というものです。そして、その方向を進む手助けを
するためにITを活かしたい。

古い人間と思われようが、大勢の人と仕事をしてみて、
『もしこの人たちから仕事を取り上げたら、この人たちは
楽しい人生を送れるだろうか?』と思ってしまいます。

--

自分の場合、散文的に考えてるようです。いや、『ようです』
っていうくらいだから、ほんとはなんにも考えてない
のかもしれません (笑)。ただ、(ネットワーク図みたいな)
グラフとか図形みたいなものが頭に浮かぶことはあんまり
ないように思います。自分は図は描かないタチだという
ことは何度も書いてますけど。

散文的に考えるもんだから『プログラミングはレトリックが
重要だ』ということを書くのでしょうね。

--

でも、散文的に考えてる人は多いように思います。
散文的というより『パッチ的』といったほうが正しいん
ですけど。パッチ的プログラミングっていうのは、
ツギハギでプログラミングするやり方です。言い替える
なら『書いてから考える』プログラミングといった感じ
でしょうか。

とりあえず書いてみる。そしてデバッガ上で動かして
みる。そこではじめて自分が何を考えていたかを知り、
デバッグしはじめる。

だから、常にデバッガが走りっぱなしで、コンパイル
するときはEdit/Continue。『こりゃLisperもビックリ
だね』って感じです。こんなやり方、昔は対話型
インタプリタじゃなきゃできませんでしたから。

そういうのを見ちゃうと、TDDは『事前に考える機会を
与えるやり方なんだ』と思いますね。この『事前に
考える』っていうのは、多分、大事なことなんじゃないで
すかね。

--

そう、自分がフツーであると知れば、フツーを語るには
十分なんだ (ニヤリ)。

--

『「働く」イコール「食っていく」ではなくなる』という
意味では、そうなるかもしれない。

昨日の話じゃないけど、『働く』の他の選択肢は『遊ぶ』
以外にもあるということ。

--

仕事には分担があるし、『オレの仕事じゃねぇ』とボヤく
気持ちもわかる。でも、そこで立ち止まってしまって
いいのだろうか。

結局、カイゼンっていうのは、他人事に口を挟むことじゃ
ないんだろうか。

まぁ、自分もそこまで熱心でもなければバカでもないから、
相手を見て話をするけど。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails