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

ホーム

2009年04月30日

前にも書いたけど、オブジェクト指向を否定するような
人でも、モジュール化を否定する人はいないんだよね。

で、オレは、オブジェクト指向っていうのは、モジュール化の
1つの技法だと捉えてるんだよね。だから:

http://ja.wikipedia.org/wiki/%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB

にある『モジュールとクラス』の説明は間違ってると思う
わけだ。だって、上の捉え方からすると、クラスっていう
のは、モジュールの1つのインスタンスなわけだよな。

『モジュール』っていう概念をどうやって実現するか?
っていう問いがあって、それの答えが『クラスを使って
実現します』っていうわけだから。だから、モジュールと
クラスの違いは、概念とその実装という意味での違いで
しかない。

もちろん、モジュールの実現方法は、クラス以外にもあるよ。
そもそも、モジュールの最小単位が関数や手続きだと考える
ことだってできるんだから。そうでなくっても、C言語の
ような、クラスのない言語でもモジュールを提供することは
できる。

で、C言語とかでもモジュールを提供できるんだけど。でも、
その仕組みって、C言語に閉じちゃうじゃんか。ファイル
単位のstaticな要素とか。でも、クラスとかだったら、
大雑把でも、言語の壁を超えて議論ができるわけだよな。
デザイン・パターンみたく。

--

まぁ、でも、SQLが目のカタキにされて、正規表現はそう
じゃないっていうのもおかしな話か (笑)。

まぁ、最近じゃ、正規表現も攻撃されることが増えてきた
けど。

自分はSQL使った経験が少ないんで。だから、SQLには
否定的な感情は持ってない、はず (笑)。

もしあるとしたら、『未知なものへの恐怖』といったほうが
正しいんだろうね。

--

先々週の『東洋経済』で、キヤノンとニコンとを対比した
記事が面白かった。生産拠点を日本国内に絞ったキヤノン。
タイに生産拠点を広げたニコン。品質がガタ落ちしたキヤノン。
いずれタイでプロ向け機種も出せそうなニコン。

まぁ、キヤノンのことはほっといて。ニコン。で、その
タイで作られたカメラ。これって自分的にはやっぱり
『メードインジャパン』なんだよね。

だから、やっぱり日本は加工業なんだよね。昔は製品の材料を
輸入して、それを加工して輸出してたんだけど。でも、今は、
人を輸入して、それを加工して輸出するんだと。

そういうのはトヨタなんかもやってて。世界各地の工場から
人を『マザー工場』に呼んで、研修させて、自国に帰って
品質の高い製品を作ってもらうと。

水平分業だなんだと騒いでるけど、そんなもんじゃないん
じゃないの? っていうのがあるんだよね。

--

でも、キヤノンの話は身に詰まされたわ。

本家Permlink


2009年04月28日

製品においては、機能を実現できてるかどうかが重要で
あってね。そういう意味でいうと、設計っていうのは、
それほど重要じゃない。

もちろん、機能を実現するために設計をするわけだけど、
でも、ある機能を実現するために取り得る設計っていうのは
いくつもある。

そういう意味でいうと、設計っていうのはプログラマの
「主張」に過ぎないんだね。保守性とか、拡張性とか、
尺度はいろいろあってもね。そもそも、そういう「尺度」
というのも、厳密に数値化できるものじゃないしね。

だから、そういう尺度がある程度満たされていれば、設計の
違いっていうのは、極端にいえば「好み」の違いでしかない。

たとえば、将棋の定跡というのは1つの設計ということも
できるだろうけど。でも、矢倉と穴熊、どっちが「優れた
設計」なのかは、プロでもなかなか判断できないでしょうよ。

それでも矢倉を選ぶのは「矢倉で一番指してやろう」って
いう「主張」なわけだよね。

それと、設計っていうのは``emergent''なものなんだよね。
ドメインに対する理解、システムに対する理解が深まって
いくごとに設計っていうのは変わっていく、洗練されて
いくものなんだよ。

で、理解がまだ不十分なときにやった設計が間違いかって
いうと、そんなことはないと思うんだよね。そのときの
自分の精一杯の「主張」ができてれば、それはそれで1つの
設計だと思うんだよね。もちろん、機能が実現できてれば、
の話だけど。

もし、唯一絶対の「設計」があるとしたら、唯一絶対の
プログラミング言語がなきゃおかしいし、唯一絶対の
コーディング規約がなきゃおかしいし、唯一絶対の
プロセスがなきゃおかしいし。でも、そんなわきゃないん
だから、自分なりの最善の設計を主張することしかできない
んだよね。あとは、その主張を他の人が認めてくれるか
どうかなんだよね。

本家Permlink


2009年04月24日

だから、「偽りの完成」が一番恐いんだよね。

未完成のものなら「出荷しない」っていう選択肢が残される。
でも、完成したとされたものは、出荷しちゃうんだよね。

テストをぜんぶパスしたとなれば、それは完成したと
見なされちゃうわけだ。でも、テストそのものが手抜きの
テストだったら、未完成品を出荷すんのとおんなじなん
だよね。

まぁ、そんなこといったら、世の中の不具合はぜんぶ
「偽りの完成」が引き起こしたものといえなくもない
気がするけど (笑)。

それでも、やっぱり完成してないんなら、正直に「完成
してません」っていわなきゃダメだし。テストも、十分な
テストケースをカバーしてるか考えなきゃダメだし。

何度も書いてるけど、不具合っていうのは「過去の亡霊」
なんだよね。過去にやっちゃった不具合のおかげで現在の
スケジュールが狂っちゃうわけだから。

本家Permlink


2009年04月17日

こないだのはマズかったかなぁ。いや、後悔してるわけ
じゃないけど。

えーと、現行のルールで対処できない問題については、
価値観と原則が行動の指針になる、というのが結論。

でもって、この価値観と原則は明文化できるし、
したほうがいい。

XPE2で取り上げられている価値観と原則は、次のページに
まとめてある:

http://www.jitu.org/~tko/doc-jp/xpe2.html

--

まぁ、ここであげられてるように、コミュニケーション
っていうのは、価値を高めなきゃいけないものの中では
筆頭なわけだな。まぁ、respectは別格だけど。

で、コミュニケーションの重要性っていうのは、このテの
本の古典である「人月の神話」のころからいわれてる
わけだな。つまり、コミュニケーションっていうのは、
XPに限った話じゃなくって、ソフトウェア開発っていう
枠で見たときも重要なわけだ。

って、そんなことはもう教わってるよな?

じゃあ、なんで挨拶せんの?

挨拶はコミュニケーションの基本!

つまり、挨拶はソフトウェア開発の基本!

なわけだよな。そんなことはもうわかってんだよな?

じゃあ、なんで挨拶しねーんだよ?

いいか? 挨拶と声かけはコミュニケーションの基本だろ?

なんか、ソフトウェア開発っていう仕事を間違って
理解してるよな。ソフトウェア開発で相手しなきゃ
いけないのは、機械じゃなくって、人間なんだぜ?

挨拶されたら喜ぶようにできてんだよ、人間ってのは。
声かけたら喜ぶようになってんだよ、人間の心ってのは。
もうちょっと人間ってもんに目を向けろ。お金を出して
くれんのは機械じゃなくって人間なんだしな。

--

そうそう、朝会でさぁ、ボソボソ聞き取りにくい声で
しゃべんなよ?

なんのためにみんなが同じ時間に、同じ場所に集まってるか、
わかってんのか?

テメーの進捗を司会者に報告するだけだったら、なにも
みんなで集まる必要なんかねぇだろ? 司会者が一人一人に
聞いて回ったほうがいいだろ? そのほうが生産性上がるだろ?

みんなが集まるのは、みんなにツッコんでもらうためだろ?

だったら、もっと声出せや。

みんなの時間を犠牲にしてるってのがわかってねぇんだよな。
気配りも足んなきゃ、生産性への意識も低い。
ダメだこりゃってレベルじゃねーか。

本家Permlink


2009年04月15日

まぁ、でも、アレだよな。不思議なことに、Appleのことを
『ガラパゴスな会社』っていう人はいないんだよな。

結局、勝てば官軍なんだよ。それだけなんだよ。

独自技術だとか、クローズドだとか関係ねぇんだよ。
人が買いたいと思うようなモノを作れてねぇんだよ。
人が買いたいと思うように仕向けることができてねぇ
んだよ。それだけなんだよ。

--

いや、やっぱり、芸術だろうが商売だろうが、お金を
出してくれる人の意見は大切じゃねぇのかな。

本家Permlink


2009年04月14日

自分はデズニーは嫌いなんですけど (笑)、それを抜きに
しても、自分はunwritten ruleということを意識したことは
ないですね。

unwritten ruleって、自分はそんなにいいイメージ持って
ないんですけど。有名なのに大リーグのヤツがありますよね。
大差で勝ってるときにロコツに点を取ろうとしちゃいけない
とか:

http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%B8%E3%83%A3%E3%83%BC%E3%83%AA%E3%83%BC%E3%82%B0%E3%81%AE%E4%B8%8D%E6%96%87%E5%BE%8B

「ルール」っていうからには「守らないと罰」がある
っていうのがフツーなわけで。そういう「ルールなんだから
守んなきゃ」みたいなことを自分は意識したことはないん
ですよね。

隣の席に座ってる人が咳をしたら「風邪ひいたの?」って
声をかけるのは、ルールだからじゃないですよね。
心配してるからですよね。

進捗が遅れてる人に「大丈夫なの?」って声をかけるのは、
ルールだからじゃないですよね。プロジェクトのことも
もちろんあるけど、本人が何か悩んじゃいないか心配
だからですよね。

そういう、お互いが相手のことを気づかう、こういう、
見える化できない力 (ちから) っていうのを自分は
大切にしたいんですよね。それが自分が「見えないカ
(みえないか)」って呼んでるものです。

--

ああ、「みえないか」っていうのは今作りました (笑)。

本家Permlink


2009年04月10日

プログラミング言語なんて、ポップスでいいじゃん。

クラシックが好きな人もいるけど、やっぱりお金に
なるのはポップスだしね。

本家Permlink


2009年04月09日

http://blog.toolshed.com/2009/04/broken-windows-proved-in-the-netherlands.html

たとえば、この「割れ窓」理論にしても、それを工学と
呼んでいいかどうかはビミョーかもしれんが、そんな
ことと関係なく、自分ら現場の人間にとっては非常に
重要な理論であることに変わりはない。

だから、現場では、それを工学と呼ぶべきかどうかとは
関係なく、4S (整理・整頓・清掃・清潔) というものを
重要視しなきゃいけない。

本家Permlink


2009年04月08日

ああ、「聖誕祭」を使うようになったのか。前は
「生誕祭」って書いてて違和感覚えたんだけど。

--

いや、プログラマとかSEとか、投資効率は決してよく
ないでしょ?

もっと稼げる仕事、他にあるでしょ?

たとえば不動産とか。あれなんか、今はすっごいことに
なってっけど、その前にバブルが一回弾けてるわけで。
それでまた雨後の筍のようにマンションデベロッパー
とか、証券化ファンドとかいうのが出てきたわけでしょ。
つまり、サブプライム危機の前までは稼げてたってこと
でしょ。そのころガッツリ稼いで、そいでもって頃合い
見て手を引いてたら、今ごろユーユーとした生活送れて
るでしょ。

ノンバンクとかもそうでしょ? いや、グレーゾン廃止に
なって、こっちも大変だけど。でも、SFCG、旧商工ファンドの
会長とか、確かバブルが弾けたときに国会に呼ばれたと
思うけど、今だに会長でビックリしたんだけど。つまり、
それだけ儲かってたってことじゃないの?

大体、楽しく仕事して何が悪いの? 仕事は必ず苦行じゃ
なきゃいけないの? 仕事を楽しくしようとか、やっちゃ
いけないの? だから、楽しいっていうのはヘラヘラ
しながらできるっていうことじゃないから。時には
バグで真っ青になったり、時には納期に追われたり、
そういうのをひっくるめての楽しさだから。

新人なんかの場合は、仕事の楽しさっていうのを知らない
ことがあるしね。だから、仕事の楽しさを伝えるのも
先輩の勤めなんだわな。

--

なんつーの? 感情を思考に変えないとダメだよ?

ネコが毛玉にじゃれるようなね、そういう考え方を
してちゃ、自分らの仕事は前に進めないのね。

前に進む、gainする、押す、自分はいろんな言い方を
してるけど。

たとえば、「このコード怪しい!」とか思ったりする
じゃん? これって感情じゃん? で、そこで「うわー」
とか思ってるだけじゃダメじゃん? パニクってるだけ
じゃん?

そうじゃなくって、その感情をきっかけにして、どう
やったらその感情を解消できるか考えなきゃダメじゃん。

観察が必要なら、その観察のポイントみたいなものが
あるわけじゃん? だったら、そういうのを書き出す
わけだよ。で、その観察結果をもとに作戦を立てたり
するわけだよ。

感情をきっかけにして、いきなりコード書きはじめちゃう
のは失敗するからね。まず失敗する。だから、観察して
作戦を立てる。

何度も書いてるけど、作戦っていうのは、手順なわけだな。
Aをやって、Bをやって、Cをやって、Cまで到達できたら
作戦成功なわけだ。そういうチェックポイントを作って、
「前に進む」感触っつーもんをつかむわけだな。

--

手が早いとか、手を動かすとか、そういうのは思考
するのとは別に矛盾しないから。TODOリスト書き出せば
手を動かすことになるし、考えてからのほうが迷いが
ないから手を早く動かすことができる。

逆に、手を動かしてても考えてないってことがあるからね。
そうなっちゃうとダメだよな。

--

だから、いつでも、自分がどこから来て、今どこにいて、
そしてどこに向かうのかっていうのを説明できないと
いけないんだよな。それをアカウンタビリティとかと
いうわけだ。

--

作る側の人間がイノベーション願望にかられちゃダメだよ。

自分ら作る側の人間は、少しずつしか前に進めないんだから。

どんな偉大な発明でも、その発明が生まれるまでに試行
錯誤というものがあったろうし、それを無視して結果
だけ見るのは、作る側の人間としてはあり得ない話。

本家Permlink


2009年04月07日

誰でも知ってるヒザの話というと:

http://www.google.co.jp/search?q=%E3%81%B2%E3%81%96+%E3%81%B2%E3%81%98+%E3%83%94%E3%82%B6&lr=lang_ja&ie=utf-8&oe=utf-8

だと思うんだけどなぁ (笑)。

--

いや、今さらこんなこと書くのもメンドーなんだけど。

C/C++で論理演算子を混ぜて使うときはカッコを使うこと。

int main()
{
    int n = 0;
    cin >> n;
    if (n != 0 && n != 1 && n != 2 || n != 3)
        cout << "true" << endl;
    return 0;
}

こういうコードがあったとして、「nが3のとき"true"が
印字されるか?」と尋ねられて、少なくとも自分は即答
できない。

    if ((n != 0 && n != 1 && n != 2) || n != 3)
        cout << "true" << endl;

カッコをつけたところで大して変わんないけど、それでも、
||の左側が成立したらそれで"true"が印字されるという
のはわかるわけで、ちょっと考えれば答えることができる。

「条件式の中にはなんでもカッコを使え」という流儀が
あることは知ってるけど。でも、正しくは「複数の論理
演算子を使うときにはカッコを使え」であって。たとえば:

    if ((n != 0) && (n != 1) && (n != 2) || (n != 3))
        cout << "true" << endl;

では意味がない。

もちろん、ベストなのは、条件式を関数でくくり出すこと。
で、それでも複雑なら、またそれを関数に分解すること。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails