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

ホーム

2008年01月31日1

別に情報処理を学校でやってた人間を採んなくっても
いいんだけどさ。だったら、自分とこで教えなきゃダメ
じゃん?って話だよな。

知識っていうのは、やっぱり系統立ったものじゃないと
応用が利きにくいんだから。たとえば、UNIXの基本的な
仕組みを理解してれば、その知識はWindowsでもある程度
通じるわけだ。で、仕事っていうのは実戦なんだし、
実戦で得る知識っていうのは、いってみれば虫食いの
ような知識であって、系統立ったものじゃないわけだ。
だから、仕事で得る知識っていうのは応用が利きにくい。

本家Permlink


2008年01月31日

職業プログラマなら、なぜC言語を学んでおかなければ
ならないかというと、多くのインフラがCで書かれている
から。また、そのインフラを解説するのにCが使われて
いるから。

インフラの代表例がOS。職業プログラマである以上、OSに
ついての基本的な知識は持っていないといけない。そして、
代表的なOSはCで書かれている。当然、そのOSを解説すると
なると、Cコードで解説することになる。

OSを作る側から解説する書籍としてMINIX本があげられる。
また、OSを使う側から解説する書籍としてAPUEがある。
どちらの本にしても、Cを知らずに読むことはできない。

本家Permlink


2008年01月30日1

やっぱり基礎は大切というか、職業でプログラマをやって
いる以上、基礎は知ってて当たり前のレベルじゃないと
いけない。技術的な基礎知識もなしにagileとかいってても
無意味。

どこからどこまでを基礎とするかは難しい問題ではある
んだけど。

本家Permlink


2008年01月30日

なんか、今日話してたら、アレでネトゲやるとかいい
だすんですよ。

だから、XPなんかで出すから、こういうヲタが湧くんだろ
って。

そういうニッチな方へ、ニッチな方へ行っちゃうわけだよ。

そうじゃねぇだろって。

だから、ネトゲだとか、ワードとか、そういうのがやり
てぇヤツは、2スピンドルのクソ重たくって、クソデカ
くって、クソ高ぇノートPC買やぁいいんだよ。そうすりゃ
日本のメーカーだって喜ぶだろ。クソなPCしか作ってねぇ
んだから。

そうじゃねぇだろ?

オレがほしいのは、ほんとに日常的な、いつでもそばに
置いとけるような、そういうカワイらしいPCがほしいんで
あって。それはXPとか関係ない世界で、なおかつLinuxで
あるとかも意識しないような人たちが使うようなもので
あって、そういう、ほんっとにパーソナルなPCがほしい
わけだよ。それでプログラミングするのは、オレがたまたま
プログラマだからであって。

だから、仕事場で働いてるインド人にも自慢できるような、
なおかつ、それがイヤミにならない程度に廉価なもので、
それがほんっとにガキが自慢するようなものがほしいわけ
だよ。そういうグローバルで、ピープルズなPCがほしい
わけだよ。チンケなジャパナイズドのPCなんか今さら
ほしくもなんともない。

だって、考えてみろよ。PC人口なんかよかケータイ人口の
ほうがよっぽど大きいわけだろ。PCなんか、まだまだ全然
ダメなんだよ。全然パーソナルで、ピープルズのデバイスに
なんかなっちゃいねぇんだよ。なのに、なんでニッチな
方向に行くのかな。頭悪いわ、志が低いわで、泣けてくるわ。

今、日本が世界で一人負けとかいわれてるけど、この分じゃ
2008年も相当アブネーな。

--

当たり前の話ですけど、獲物で取り上げる記事は、必ず
しも自分が全肯定するものばかりじゃないです。中には
『まぁ、そういう見方もあるかな』と思う程度のものも
あります。

『日本型モノづくり』の話もそうで。面白いとは思うん
ですけど、日本型と欧米型の2つしか選択肢がないという
のも短絡的だと思うんですね。

それに、こういう記事って、お約束のように『バランスが
肝心』みたいなことが書いてあるんですけど。そんなの
誰でもわかってるというか、そういう『バランス』みたいな
話が出る時点で弱いし、負けてる。

自分は、日本の最大の欠点は、民主主義の欠如にあると
思ってるんです。議論ができないということと、合理的で
ないということの2つ。

議論ができないと、価値観の違う人と協同作業できない。
合理的でないと、ある程度人を信頼することはできない。

結局、孤立して、高コストになっちゃう。

だから、ITも、民主主義を助長する方向に使わなきゃ
いけないと思ってるんです。自分でもテキトーなことを
書いてると思うんですけど。でも、たとえばWikiは、そう
いう方向の1つですよね。

ITっていうと、なんか『中抜き』するためのもんだって
いう意見ばっかり聞くんですけど。まぁ、自動化だとかも
その部類に入っちゃうんだけど。まぁ、それはそれとしても。
もっとなんか違う方向もあるんじゃないかと思ってるんです。

--

だから、結局、民主主義と科学なんですよ。自分が欲して
るのは。

本家Permlink


2008年01月28日

http://www.amazon.co.jp/%E3%81%9F%E3%81%B3%E3%81%9F%E3%81%B3%E3%81%82%E3%81%98%E3%81%82-%E9%87%8E%E4%B8%AD%E3%81%AE%E3%81%B0%E3%82%89/dp/4812433568/ref=sr_1_1?ie=UTF8&s=gateway&qid=1201528868&sr=8-1

『たびたびあじあ』(野中のばら、竹書房)

4コママンガじゃないんだけど、4コマ雑誌に載ってた。

何度か書いてるけど、野中のばらは『奥様うでまくりっ!』
が好きなんだけど、それは残念ながらコミックになって
ない。

で、この『たびたびあじあ』なんだけど、これも連載読ん
でて、楽しめた旅エッセイマンガ。上海以外の場所のも
あった気がするんだけど (香港とか)、とりあえずこの
コミックでは上海オンリー。まぁ、オリンピック狙いの
下心がチラチラ見える (笑)。

自分、旅行なんて、海外どころか国内すら興味ないんだ
けど。でも、これ読むと、ショーロンポーが食べたくなる。

野中のばらにしても、『ねこまんが』のこいずみまりに
しても、『なんでこんなに面白体験してるわけ?』って
いうのがある。やっぱりそういう体質ってのがあるんだ
と思う。

レビュー書くの下手でスマン。

--

Kent Beck氏がRubyについて『もっと野望を持っていいと
思う』っていってたっていう話だけど、オレも『もっと
野望を持っていいと思う』って会長にいいたいね。

--

http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview04.html

ああ、やっぱりもう出てたか。

個人的にインタビュー記事読みたい人は何人かいるかな。

まず舞波さん。

それとhirashoさん。

それとCryoliteさん。

ちょっと恐い気もするけど (笑) 新山さんも。

あんまりオブジェクト指向っぽくない人選だけど。でも、
なんつーの? もうオブジェクト指向は若者の心を捕えて
ないんだよね、ぶっちゃけいって。

なんつーかな。んと、Lispっぽい感じ? 今、FPが先端っ
ぽいわけだけど、でも、その中にはLispって入ってない
感じあるじゃん? それと似た感じがオブジェクト指向
にもある。あんまりな言い方をすれば、ジジイの繰り言
みたいな? (笑)

まぁ、だからといってオブジェクト指向がダメなわけじゃ
全然ないんだけどね。Lispがダメなわけじゃないのと
おんなしで。ただ、雰囲気としてね、そういう感じが
あるということ。

--

だからね、やっぱりいろんな人のいろんな意見を知ら
ないとダメだと思うんですよ。マンセーもアンチも両方
自分なりに筋通してるもんだしね。

本家Permlink


2008年01月27日

へー、これコンパイルできないんだ。g++だけ?

class Parent {};

class ChildA : public Parent {};

class ChildB : public Parent {};

Parent*
doit(int n)
{
    return (n % 2) ? new ChildA() : new ChildB();
}

本家Permlink


2008年01月24日

短気はハッカーの美徳などといわれますが。やっぱり、
どうも、上手い人を見てると、かなりしつこいところが
あるんですよね。

デバッガでしつこくステップ実行したりだとか。

ソース・コードをしつこくgrepして追いかけたりだとか。

自分なんかは短気なもんですから、横で見てて、その
しつこさに呆れてしまいます (笑)。

そういうしつこさを見ると、『ああ、この人はプログラマに
なるべくしてなった人なんだなぁ』と思うわけです。

本家Permlink


2008年01月23日

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?PreferDesignSkills

まぁ、ここに書いてあることに自分がつけ加えるような
こともないんだけど。

だから、M.Fowler氏のいうように、システムっていうのは、
3つの知識で成り立ってるわけ。1つめはドメインの知識。
2つめはプラットフォームの知識。3つめは設計の知識。

ドメインの知識っていうのは、お客さんのビジネスに
関する知識。たとえば、株の自動取引システムだったら、
株式の知識がドメインの知識になるし。在庫管理システム
だったら、商品の知識がドメインの知識になる。ドメインの
知識がなきゃ何もはじまんない。

プラットフォームの知識っていうのは、OSとかプログラミング
言語の知識。プラットフォームの知識がなきゃ、ドメインの
知識をシステムという形にできない。

で、最後の設計の知識。ぶっちゃけいって、作りっぱなしの
システムでいいんなら、設計の知識はそんなにいらない。
でも、システムっていうのは長く使われるもんだし、長く
使われれば機能の追加や改変も出てくるし、そうなると
設計が問題なる。そもそもシステムの規模が大きくなると、
設計の知識がないと完成まで持ってくこともできなくなる。

--

まぁ、システムということであれば、上の3つでいいわけ
だけど。でも、ソフトウェア開発となると、さらにソフト
ウェア開発そのものの知識が必要になる。いってみれば、
ソフトウェア開発っていうドメイン固有の知識。だから、
ソフトウェア開発っていうのは、常に2つのドメインを扱う
ことになる。

--

で、今問題になってるのは、お客さんのドメインをシステム
化するばっかりで、自分とこのソフトウェア開発のシステム
化はどうなってんのよ?っていう話。

artonさんのソフトウェア・ファクトリの話とか、
はぶさんのソフトウェア開発のIT化とか、みんなそう。

これは非常に難しい問題で。ソフトウェア開発っていう、
知的創造の過程を、どうやってシステム化するかっていう
話。

もちろん、IT化っていうのは真っ先に考えられる。極端に
いえば、自然言語からプログラムを生成するといった話。

あるいは、組織論として考えることもできる。Googleを
1つのシステムと見なすこともできるわけ。

まぁ、現実的には、この両極の間のどこかでさまようことに
なるんだろうけど。

--

他人の感情に敏感なのは別に悪いことじゃない。でも、
それで自分の感情まで大きく揺らすようじゃダメなんだよ。

--

新しい人が来たとき、オレが学んでほしいのは、システムも
そうなんだけど、それよりもオレたちのやり方を学んで
ほしいわけ。

やり方っていっても上辺だけの話じゃなくってね。上辺
だけだったら、XPのpractices読めば済む話なわけ。そう
じゃなくって、なんでそういうやり方をやってるのかって
いう、本質的なところを理解してほしいわけ。

いい? 学ぶっていうことは、たとえばアナタが別の
場所で仕事することになったとき、ここのやり方を参考に
して、自分なりに、チームがスムーズに開発を進める
ことができるようになることなわけ。そうなってはじめて
『学んだ』っていえるわけ。

ここのやり方を繰り返せるんなら、それでもいいんだけど。
現実問題、そんなことは不可能だから。開発のやり方って
いうのは、人が変われば変わんなきゃいけないもんだし。

だから、個々の実践にとらわれないで、何が今このチームを
スムーズに動かしてるのかっていうとこを観察して、考察
してほしいわけ。

いい? 単純に『優秀な人が集まってるんだろう』みたいに
考えないでほしいんだよ。一人一人の能力的には飛び抜けて
スゴイわけじゃないんだし。いいチームになるには、いい
チームになる努力をしてるからなんだよ。いいチームは偶然
なんかでできるもんじゃないんだよ。

本家Permlink


2008年01月22日

http://mumrik2.spaces.live.com/blog/cns!51ED6D671E97A131!821.entry

ああ、前に「正解はある」みたいなことを書いたことが
ありました。そのときは、there is more than one way
to do itを引き合いに出して、「やり方はたくさんある
かもしれないけど、正解は1つしかない」みたいなことを
書いたはず。

その正解っていうのは、コンテキストによっても、人に
よっても違うかもしれない。でも、書く本人にしてみれば、
正解は1つしかないわけです。アレもある、コレもある、
いろんな選択肢がある中で、正解あるいは最善の解を
選ばなきゃいけない。

で、そういう正解を求める姿勢が大切だという話。

--

上みたく、正解が人によって違うのは、まぁ、自分は
アリだと思ってるんですけど。

でも、自分の解が唯一絶対と思い込んでると、議論になん
ないことがありますよね。それが一番よくないこと。
正解を求めることよりそっちのほうが大切だと自分は思う
んですよ。

まぁ、もちろん、議論の対象になんないものもありますよ?
「1 + 1の答えは2だ」っていうのなんか、議論したって
フツーは意味ないですから。

本家Permlink


2008年01月21日

いやぁ、笑った。

こないだ『なんとなくはダメ!』って書いたばっかだけど。
まさに『なんとなく』としかいいようのないバグに悩ま
された。ちなみに、これは自分が書いたコードじゃない
けどね。C++の話なんだけど。

デバッガで追ってると、ほんとに『いつのまにか』メモリが
書き変わってる。

最初はオブジェクトのコピーで失敗してんのかと思った。
で、とりあえずコピー・コンストラクタというか、そう
いうsetterを用意してみたんだけど。それでも変わる。
いつのまにか。

で、たまたまOnKillFocusが怪しい気がした。ちょうど
ダイアログを閉じるところで現象が起きてたから。で、
デバッガでブレイク・ポイント張っとくと、案の定、
引っかかった。MFCってマルチスレッドなの?

これでタイミングは分かったんだけど。まだ正体までは
突き止められなかった。やっぱりこっちでも露骨にメモリを
書き換えてるようなとこは見当たらない。

で、しばらくウダウダとコードを眺めてたら、生の配列で、
引数で渡されたインデックスでアクセスしてるとこが目に
入ってきた。しかも:

void setValue(int n, int value) {
    array[n - 1] = value;
}

みたいなコードになってた。引っかけてみると、やっぱり
nがゼロのときがあった。

まぁ、わかってみれば単純なミスだったわけど。こういう
のは、もう防ぎようがないっていうか。いや、防ぎようは
あるんだけど、それってプログラマ個人の心がけとか、
そういうレベルでしか防げないことだから。

たとえば、いくらvectorを使いましょうっていっても、
それを守るかどうかは本人次第なわけだし。

これはたまたまC++の話だったけど。でも、他の言語でも
おんなじだよね。それぞれの言語にはそれぞれの落とし
穴があるし。まぁ、C/C++は多いほうだけど (笑)。

だから、こういうのは自分で痛い目にあって、身に染み
こませて覚えるしかないんだよなぁ。

で、こういうのをバッドノウハウの一言で片づけるわけ
にはいかないんだと思う。結局、システムが落ちたら
ダメなんだし、システムが落ちるのはまさにこういう
ところで落ちるんだし。というか、上のみたく、落ち
なくて、不正な状態なまま動いちゃうっていう一番恐い
パターンもあるわけだから。

本家Permlink


2008年01月20日

へー、1/3って、商売じゃ結構重要な数字なのか。

--

何度か書いたことあるけど、プログラミングで『なんとなく』
はダメ。

若いヤツと仕事してると、よく『なんとなくこのへんが
おかしい気がするんですけど』っていうのを聞く。

だから、『なんとなく』じゃねぇだろって。デバッガで
追うなり、printf埋め込むなりして、なんでハッキリさせ
ねぇんだよ。

プログラムなんだから。コンピュータなんだから。おかしな
動きにはハッキリした原因があって、その原因を作ったのは
オマエなんだよ。それなのになんで『なんとなく』なんだよ。

それって結局、バグは他人事ってことか? それともあれか?
mallocにバグがあると疑ってんのか? malloc疑うなんざ
百万年はえーって。

そりゃ『勘』が必要なときもあるよ? でも、その前に
もっと合理的な考え方をしなきゃダメだろ? プログラマ
なんだから。

--

そうなんだよなぁ。1日平均でどのくらいコミットするか
だとか、ビルドが1回平均でどのくらい時間かかってるか
だとか、そういう基本的なデータすら収集してないんだ
から、生産性がどうこういっても『なんとなく』のレベル
なんだよな。我ながらバカすぎる。

本家Permlink


2008年01月18日1

大前提として、機械でできることは機械にやらせないと
ダメですよね。で、機械にできることを増やすのが自分
らの仕事なわけです。そこにagileと他のやり方とで違いは
ない。

その話とワーキングプアとかは全然関係ない。そのせいで
誰かがリストラされようがしょうがない。それがテクノロジー
ってもんだから。それがイヤなら、最初っから技術者なんか
やんなきゃいい。

--

1つは、工場というものをどう捉えるかという問題があり
ますよね。

工場を知的な生産の場と捉えることもできる。工場を建てる
ところからはじめて、ラインが流れて、プロセスをカイゼン
していくという。そういう全体的な捉え方なら、工場も
知的な生産の場ということになる。

でも、一方で、期間工が秒単位で管理されて単純作業を
するというような見方をする人も、世間的には少なくない。
そう捉えちゃうと、工場を知的な生産の場と見なすことは
できない。

--

こういう捉え方の違いが、メタファーの恐いところなわけで。

--

http://ja.wikipedia.org/wiki/%E5%B7%A5%E5%A0%B4%E5%88%B6%E6%A9%9F%E6%A2%B0%E5%B7%A5%E6%A5%AD

これなんかを読んでも、ソフトウェア開発が、家内制
手工業からはじまり工場制機械工業に至る工業の歴史的
分類のどこに当てはまるかとなると判断が難しいわけ
ですよね。

マニュファクチュアあたりが近いかなとは思うんです
けど、『技術水準は前近代的なものにとどまる』なんて
ことはないわけで。たとえば計算能力にしても、ツール
にしても、『前近代的』なんていう段階はすでに抜け出し
てるといっていいでしょう。もちろん、こればっかりは
歴史しか証明できないことですけど。

それと、よくいわれることですけど、ソフトウェアは、
開発さえできれば、あとはほぼタダで再生産ができる。
ソフトウェアそのもののコピーも廉価だし、ソフト
ウェアを使い続けたらすり減るといったこともない。
そういう点では、工場制機械工業に近い。

あるいは、家内制手工業に近いところもある。だって、
生産に必要な『資本』って、基本的にはPC1つで足りちゃう
から。もちろん、サーバ・ファームとか、そういう『資本』
を必要とすることはあるんだけど。でも、それでも、工業
なんかに比べると、資本にかかる費用はビックリするほど
低い。

で、今のソフトウェア開発を、工業の歴史になぞらえて、
せいぜいマニュファクチュアだと思ってる人は、これから
工場制機械工業に移らなきゃいけないと思ってるわけです。

--

で、自分は、ソフトウェア開発を、知的労働の先鋭化
された存在だと思ってるわけです。だから、他の産業を
メタファーに用いることに危険を感じるんです。もちろん、
他の産業のいいところを取り入れる姿勢は大切ですけど。

本家Permlink


2008年01月18日

う〜ん、『東洋経済』。まぁ、ソフトウェア開発業界、
やっぱ離職率高いんだろうなぁ。7Kだっけ? みたいな
話もあったし。女性の離職率が高いみたいなんだけど、
やっぱ問題だよなぁ。

入るほうにも問題あるんだろうし、雇う側にも問題ある
んだろうし。

入るほうにいえるのは、この業界、間口は広いんだけど、
そんなに簡単な仕事じゃないってこと。新卒で3年目なんて
コゾーだからね、はっきりいって。プログラミング言語の
入門書読んだら終わりなんていうもんじゃ全然ないから。

雇う側にいえるのは、全然育てようとしてないってこと。
OJTとかいってるけど、全然トレーニングなんかしてない。
フツーにプロジェクトに人突っ込んでるだけ。

だから、よくいうじゃん? 生産性に何十倍もの差がある
とかって。あれって、だから組織がまともな教育してない
っていうのもあるんじゃないの? 勉強するヤツとしない
ヤツとじゃ、そりゃ、そんくらい差が出てもおかしくない
もんな、やっぱり。だから、ほんとは勉強を個人任せに
してたらダメなんだよな。

本っつったってたくさんあるんだから。最低でも、その
中で仕事に必要なのはこれですよってのを示してやんない
といけない。

情報処理試験の参考書とかメールで回ってくるけど。
バカか?って感じだよな。そんなもんよりMcConnellの
見積もりの本とかのほうが、よっぽど読なまきゃいけない
本だっつの。資格で人月商売やろうとしてんのがミエミエ
だもんな。

--

上の話は、大学で情報処理とかやってる人の話じゃない
からね。わかってるだろうけど。そういう人はGoogleでも
どこでも好きなとこに就職してください。

--

ああ、あと女性の話か。何しろサンプルが少ないもん
だから、話せることないんだけど。

何しろ、この業界、慢性的に人手不足だから。だから、
やっぱり定時で帰れることって少ないんだよね。それと、
男は好きでやってるバカが多いから、好きで残業してる
っていう面がある。そんなバカはほっといて帰っていい
んだけどね。

もちろん、これも雇う側にも問題があるんだろうしね。
人手不足だっていうんなら、女性だろうが何だろうが
正当に評価して人を集めなきゃいけないんだから。

--

それと、別の現場を知るっていうのも、そんなに悪く
ないよ。だから自分も、転職を頭っから否定するわけ
じゃない。

大体、現場なんて、入ってみるまでわかんないしね。
入ったところがたまたまハズレだったら、あきらめる
しかない。『あきらめる』っていうのは、心身が壊れる
前に現場を変えるしかないっていう意味で。

本家Permlink


2008年01月16日

『東洋経済』を読んでると、どうやら経済学は、ソフト
ウェア開発に似たところがあるらしい。

一方で工学派がいて、もう一方で社会学派がいる。さらに、
工学派がバブルを生むというところも似ている。

もちろん、工学派が間違ってるっていうつもりはなくってね。

本家Permlink


2008年01月15日2

どういうわけか、モデルがある:

class Model {
  ...
}

で、どういうわけか、Dialogのサブクラスがある:

class ADialog extends Dialog {
  ...
}

で、どういうわけか、モデルがそのダイアログのことを
知っている:

class Model {
  private ADialog adialog;
  ...
}

もちろん、それがモデルの中のどこかで使われてる:

class Model {
  public void doit() {
    adialog.showResult();
  }
}

ここで、どういうわけか、ダイアログを新しくすることに
なった。多分、デザインがお気に召さないとか何かだろう。

で、どうするか?

まず、空っぽのインターフェイスを用意する:

interface ADialogIf {
}

  名前はチョーテキトーだからマネしないように (笑)。

で、それを使うようにモデルのほうを変える:

class Model {
  private ADialogIf adialog;
  ...
}

ここでコンパイルすると、もちろんエラーが出る。で、
まず、インターフェイスのほうでメソッドを宣言してやる:

interface ADialogIf {
  public void showResult();
}

ここでまたコンパイルする。2つのエラーが1つになった。
今度はダイアログのほうでインターフェイスを実装してやる:

class ADialog extends Dialog implements ADialogIf {
  ...
}

ここでまたコンパイルする。今度はコンパイルが通る。

次に新しいほうのダイアログが登場する:

class BDialog extends Dialog {
  ...
}

とりあえず、こいつでさっきのインターフェイスを実装
する:

class BDialog extends Dialog extends ADialogIf {
  ...
}

もちろん、モデルで使うことにする:

class Model {
  ADialogIf adialog;
  ADialogIf bdialog;

  Model() {
    adialog = new ADialog();
    bdialog = new BDialog();
  }
}

これでコンパイルするとエラーになる。新しいほうでは
まだインターフェイスのメソッドを実装してないから。
前のダイアログのメソッドをパクる:

class BDialog extends Dialog extends ADialogIf {
  public void showResult() {
    ...
  }
}

こういう感じでコンパイルが通るまで、古いダイアログの
メソッドを新しいほうにパクっていく。もちろん、コピペ
だけじゃ不十分だろうから、コードもよく読んでおく。

それと、これでインターフェイスは不要になった。古い
ダイアログと一緒に消してもいいし、残してもいい。

結局何がいいたいかっていうと、静的な型っていうのは、
実践的な設計の道具だっていうこと。分析にしか使わない
なんてバカげてる。未実装なメソッドでコンパイル・
エラーが出るんなら、それがそのままTO DOリストにもなる。

こういうコンパイラの使い方をすると、しょっちゅう
コンパイルすることになる。そしてそれは正しい。
まぁ、頻繁にやらないのが間違いだとはいえないけど。

--

で、少なくとも自分にしてみれば、上みたいな主張じゃ
ないと、静的型のメリットって感じられないんだよな。
typoがどうたらとか、ドキュメンテーションがどうたら
とかはどうでもいい。動的言語でも大した問題になん
ないから。

で、自分にしてみれば、上みたいな作業の進め方は、
できなきゃできないで何とかなると思ってるし、動的
言語には動的言語のやり方があると思ってる。それは
多分に気分的なもの、『気楽さ』とか『素早さ』といった
ものだけど、それだけでも静的な型を捨てる価値はあると
思ってる。

--

ヘンな言い方だけど、静的な型でも、ダイナミックに
生まれ、そして消えていくもんなんだね。ドメインの
中にある型なら長生きするだろうけど、でも、それだって
いつ消えるかわからない。必要になれば新しい型が生まれ、
いらなくなったら消えてゆく。設計っていうのは、そう
いう型の新陳代謝を促すということでもあるんじゃないかな。

本家Permlink


2008年01月15日1

いや、よく知らないことについて語るのはやめよう。

本家Permlink


2008年01月15日

自分が書くのはかなりムボーなんだけど。

自分としては、関数とオブジェクトの違いって粒度で
しかない感じ。

たとえば、Procを使えば:

def return_func
  return proc{p true}
end

だし、特異メソッドを使えば:

def return_func
  func = Object.new
  def func.call
    p true
  end
  return func
end

だし、もちろん、フツーのクラスだってあるし:

class Func
  def call
    p true
  end
end

def return_func
  return Func.new
end

どれを選ぶかは好みもあるけど、やっぱりそのコンテキストに
合った粒度というのが大きいんじゃないかな。

たくさんの小さい関数をテーブルで管理したいとかだったら
Procだろうし。2、3個のメソッドを持たせたいんなら
特異メソッドだろうし。クラスとして切り出す意味が
あるんならクラスを選ぶだろうし。

--

まぁ、FPが流行ってるのをどうこういうつもりはないん
だけど。OOPにだってそれなりに歴史はあって、それなりに
知恵は蓄積されてるよ (笑)。

本家Permlink


2008年01月14日

『野球小僧 2008年2月号』、走塁特集が面白い。特に、
本西厚博氏のインタビューがクソワロタ。タッチアップの
とき、3塁ランナーの前に立って視界を塞ぐって、それ
ただのイジワルじゃん (笑)。ランナーのほう向いて、
両手広げるっていうんだから (笑)。

--

今ごろになってDependency Injectionの話なんですけど。

あれ、やっぱ、そんなに使える場面ってないですね。
なんであんな面倒なことをやるかっていうと、設定ファイル
とかで部品を動的に組み合わせたいからなんですよね。
でも、そういう『設定ファイルで部品を組み換えたい』
っていう場面が、そもそもそんなに多くないんじゃない
かなと。

たとえば、GUIアプリで、プロダクト・コードとテスト・
コードを分けたいとしても。それって、高々2つのグループを
分けたいだけじゃないですか。だったら、設定ファイル
なんか使うまでもない。

class Assembler
  def get_component_a
    return A.new(get_component_b)
  end

  def get_component_b
    raise NotImplementedError
  end
end

class ProductAssembler < Assembler
  def get_component_b
    return B.new
  end
end

class TestAssembler < Assembler
  def get_component_b
    return MockB.new
  end
end

なんていうか難しいんですけど、設定ファイルで部品を
組み合わせるっていうのは、フレームワーク側の言い分
なわけで。それを使う側が望んでることって少ないんじゃ
ないかと思うんですよね。

使うフレームワークがDIを要求しているならともかく、
そうでなく、自前で部品組み合わせるといったときには、
上みたく素朴なやり方で十分じゃないですかね。

特にC++みたいな言語では (笑)。

--

http://home.att.ne.jp/sigma/satoh/diary.html

2008年1月11日の記事。どうも最近、大阪が引っかかって。
もちろん、財政破綻ギリギリっていうニュースがきっかけ
なんだけど。

なんで大阪 (に限ったことじゃないんだけど) が沈みっ
ぱなしなのか。なんで金融とかITとかを育てようとしない
のか。こういう不動産を必要としない、地理的不利を
受けない産業になぜ目を向けないのか。東証のイーカゲンさ
なんかを見ても、まだ全然勝ち目はあるはずなんだけど。
大阪っていうのは商いの街で、本来ものづくりじゃなく、
もの売りの街のはずなのに。シャープだかなんだかの
工場の誘致に躍起になったり。ピントずれまくってる。

本家Permlink


2008年01月13日

リファクタリングも、ユニット・テストも、リファクタリング・
ブラウザも、どれもみんなSmalltalkで生まれたんだよ。

Smalltalkって知ってる? 世界で一番最初に『オブジェクト
指向言語』を名乗った言語なんだよ。

Smalltalkって知ってる? Smalltalkは、世界で一番最初に
IDEを持った言語なんだよ。

Smalltalkって知ってる? Smalltalkは、動的言語、つまり
静的な型を持たない言語なんだよ。

それと、Smalltalkの世界では慣習として引数の名前に
型を埋め込む。たとえば:

  String at: index put: aCharacter

のように。これを:

  String at: foo put: bar

なんて書くのはキチガイしかやらない。

静的な型っていうのは、ドキュメンテーションとしての
価値ってのはそんなに高くないんだよ。でなきゃ型推論
なんて話が出てくるはずもない。

静的な型っていうのは、ドキュメンテーション云々よりも、
コンパイラにかけられて、型の正しさが保証されることが
重要なわけで。

--

カーッ、オレもしがらみ増えてきなぁ (笑)。

本家Permlink


2008年01月11日

eeePC、XPだったら買わない。一番恐れていた、かつ一番
つまんない事態。こういうことやってっから日本はいつ
まで経ってもガラパゴスなんだよ。

OLPCを気長に待つか、Androidのスマートフォンを待つ。

本家Permlink


2008年01月10日

ああ、『モンゴルの人』って聞こえてた (笑)。

『え? あんな青い目してんのにモンゴル人なのかよ?』
って。『え? 今はモンゴルで仕事してんの?』って。

どんだけ朝青龍。

--

まぁ、『技術を支える人になろう』なんて甘っちょろい
こといってるようなヤツは、インド人に仕事取られて
飢え死ねってこった。

本家Permlink


2008年01月09日

      オレ: あのさー、Rubyカイギでさー、なんかコミュニティ・
             ナンチャラっていうのがあるらしいんだわー。でさー、
             toRubyとして出てみない?

他メンバー: え? ほんと?

      オレ: だってー、会長にも理事にも来てもらってて、シカト
             するわけにもいかないじゃん?

他メンバー: ほんとに行くの?

      オレ: うん。

他メンバー: どこでやるか知ってんの?

      オレ: ・・・どこ?

他メンバー: つくばだよ?

      オレ: ・・・・・・ハア?

ほんと『ハア?』だよ『ハア?』。

つくばだぁ? どんだけ群馬ちゃんなんだよ。

ツクバエクスプレス乗りてぇだけちゃうんかと。そんなに
Rubyは鉄分高かったのかと。

あーあー、さぞかし学園都市だろうさ。さぞかし道路も
広いだろうさ。オレはクルマ持ってねぇけどな。

というわけで前向きに検討させていただきます。

--

いやー、やっぱRubyの通り名は変えるべきだよな。オブジェクト
指向スクリプト言語なんかじゃなくってさ。

その名も首都言語Ruby。

そうすりゃ東京以外でカンファレンス開けねーんじゃね?
そうすりゃみんなも『まぁ、それなら東京でしょうがないか』
ってなるんじゃね?

--

何度も書いてるけど、コンパイラは最適化の道具という
意味だけの存在じゃないし、単純なtypoを見つけるため
だけのもんでもない。

grepかけるよりコンパイラ使ったほうが早いってことも
ある。たとえば、publicのメソッドをprivateに変える
だけで、外部から呼び出してるところはわかるわけだ。

スーパークラスで空実装してるメソッドがあったら、
それを抽象メソッドに変える。そうすれば、不必要な
はずのスーパークラスの実体化をあぶり出すことができる。

だから、コンパイラは設計の道具としても使えるっていう
ことなんだよな。というか、コンパイラのモダンな使い方
っていうのは、これなんだから。

本家Permlink


2008年01月08日1

単純にやっているように見えるかもしれないけど、
それは単純にやれるようにやっているからだという
ことに気づかないといけない。

ある目的地にたどり着くまでにはいろんなルートがある。
その中で、単純で、着実なルートを選ぶ。そういうセンスを
感じ取り、また身につけるようにしないといけない。

--

つまり、職人の芸というのは、すべてそういうものだ。

本家Permlink


2008年01月08日

最終的には時間あたりのお金ということにならざるを得ない
としても、意識としては、価値を提供し、それに対する
報酬をもらうというものでないといけない。かかった時間が
報酬を決めるのではなく、生み出した価値が報酬を決めると
いう考え。

でないと不健全なビジネスになりがちだし、他の人に取って
替わられやすくなる。

本家Permlink


2008年01月07日

なんというか、コンピュータ・サイエンスの知識の大切さが
再認識される機運が高まっているようだ。いいことだと思う。

本家Permlink


2008年01月06日1

つーか、この部屋片づけるまでオレの2007年は終わんねー。

本家Permlink


2008年01月06日

あ、メッセージの色変えてくれっていう話なんですけど、
あれは、自分のせいじゃない警告が出るからで。もし
警告が出ないんなら、コンパイル・エラーのメッセージ
だけになるから、色を変える必要はないんです。その
『自分のせいじゃない警告』っていうのは、もちろん
MSのせいなんですけど (笑)。でも、こういう状況は
よくあることだから、やっぱりビルドが失敗したかどうか
一発でわかるようにしてほしいですよね。

--

フフ。

プログラマは2種類に分けられる。作る喜びを知っている
プログラマとそうでないプログラマ。

作る喜びを知っているプログラマにとって、勉強とは喜びを
得るための手段に過ぎない。

プログラマ、あるいはソフトウェア開発って、ほんとに
いろんな要素が詰まってるんですよね。仕事、金儲け、
芸術、科学、工学、社会学、他にもたくさん。できる・
できないは別にして、自分はそのどの要素も結構好きなん
です。

--

現実的であることと近視眼的であることは別だ。

--

現実的であるということは、楽観的であるということだ。
なぜなら、どんなに絶望的な状況でも、何かしら希望への
手がかりがあるはずと信じ、それを見つけようとするのが
現実的であるということなのだから。

--

なんで読書が好きなのに『自分はコミュニケーション
能力のない人間で・・・』なんていうのかな?

コミュニケーション能力ないって、相手のいうことが
聞けないってことじゃないの? 相手のいってることが
わかればそれで十分だと思うけど?

--

ああ、ちょっと誤解を招きやすかったかな。ゾーンプレスの
話。

  局面を『読み切れる場面』と『読み切れない場面』とに
  分けて考えて、『読み切れない場面』では『見た目で
  判断する』という打ち方。

これで間違いじゃないんだろうけど、『見た目で判断する』
の部分。これは『何も考えない』っていう意味じゃない。

『何も考えない』っていうと、囲碁だと『感覚で打つ』
みたいな言い方されるんだけど。ゾーンプレスは、そう
した場面でも思考することを止めないというか、読み
切れない局面を『思考する』ことによって打開しようと
する。

まぁ、『読み』も思考の1つなんだけど。だから、局面に
よって思考方法を切り替えるということ。

--

当然、ゾーンプレスのことを書くときは、頭のどっかには
ソフトウェア開発のことがあるわけで。

単純な話、実現すべきことがハッキリしてれば、もう
機械的に、というとちょっとアレだけど『読み』と同じ
ような意味で機械的に、分析やって設計やって実装やれば
いいっていうことになる。これが古典的なソフトウェア
開発のやり方。

でも、現実はそうそううまくできてるわけじゃないし、
第一自分はバカなもんだから、どうしても『読み切る』
ことができないことが多い。そうするともう、やり方を
変えるしかないのね。だって、やり方を変えなきゃ、
未知の前に立ち尽くすか、パニックになるしかないわけ
だから。

まぁ、自分も、XPとかagileとかを煽ってるわけで、
そういう意味じゃ『声のデカいバカ』なんだろうけど。
でも、自分としては、少なくとも古典的なやり方じゃ
開発はできないのね。何せ頭が悪くて読み切ることが
できないから。

それと、自分は、XPとかagileやったらお金になるとは
一言もいってないから。確かにagileはビジネス指向では
あるんだけど、そもそもビジネスが難しいんだから、
agileやったからっていって必ずしもビジネスが成功する
わけじゃない。

でも、XPやagileだと、働きがいは感じやすいとは断言
しておこう。まぁ、お金に働きがいを感じる人もいるけど、
そういう意味じゃなくってね。単純に『明日も働きたい』
って思うっていう程度の意味でね。

--

agileで金儲けできるんなら、こっちが教えてほしい
くらいだわ (笑)。

本家Permlink


2008年01月05日1

うわぁ。wingdi.hの中で:

#define ERROR 0

は止めてほしいなぁ。センスなさすぎ。

本家Permlink


2008年01月05日

ん〜。VisualStudio 2005のC++なんだけど、istringstreamで、
<string>のgetline使うとき、CRが読み飛ばされないのは
バグじゃないの? ios::binary指定してないんだけど。

まぁ、バグじゃないんだろうなぁ。

本家Permlink


2008年01月03日1

ようやくトレース出力のやり方がわかった。

NKDbgPrintfW

長すぎ。

調べ方が悪かったといえばそれまでなんだけど。
VisualStudioのヘルプで、Windows Mobile 6 SDKの
フィルタかけて、``debug''で検索すると、``Debugging
Macros''っていうのが上から4番目くらいに出てくる。
それ見ると、DEBUGMSGとかが紹介されてて、そいつらが
NKDbgPrintfWを呼び出すって書いてある。

Windows Mobile 6 SDK Documentationで見つかったけど、
eMbedded Visual C++ 4.0でも使えるみたい。少なくとも
ビルドはできた。

まぁ、相変わらずのMSらしい、わかりにくいドキュメントの
たどり方だよな。

最近笑ったのが、clipboardで検索してもそれと思しき
ヘルプが全然見つかんなくって、実はclipboardsじゃ
なきゃダメだったっていうオチ。これも Mobile 6の
ヘルプで、``Clipboards Functions''。で、実際に
それ開くと、冒頭に``clipboard functions''って書いて
ある。新年早々ブチキレですよ (笑)。

--

ああ、ヘルプの検索は、左のキーワードでやんないで、
右のデッカい検索タブでやったほうがいいのか。
キーワードだと先頭一致しかやんねぇもんな。

--

VisualStudio 2005のテキスト・エディタで、Ctrl + BS。
ワード単位でカットする。EmacsのM-BSに近い。

わかんないのが、Alt + BS。なんかUndoやってるっぽい
んだけど。

--

http://www.igoamigo.com/message/number6.html

わははは。そりゃキンゴローより素子だよな。誰がどう
見たって。やっぱ囲碁だろ!

ん〜、新井素子が年女でアイウエオ順で早かったとか
そういう理由じゃね? 東スポ。東スポはUFOとかUMAには
強いけど、SFってのとはちょっと違うしなぁ。

今引っ張り出して読んでみた。結構扱いが大きいね。
でも、なぜかホストとおんなじ枠 (笑)。

--

まだ読んでる人も少なそうだし、囲碁の話をちょっと。
もちろん、自分は全然シロートだから全然アテにならない
んだけど。

最近、日本のプロの碁界も変わってきた。力戦指向に
なってきた。

一昔前の日本の囲碁って、実利派 (たとえば趙治勲)
と厚み派 (たとえば武宮正樹) がほとんどで、それとは
別に力戦派 (たとえば淡路修三) っていう人たちがいた
んだけど。最近は、厚み派の人が減って、力戦派の人が
増えてきた。

厚み派っていうのは、実は日本の保守本流ともいえる。
厚み派が日本碁界のトップに立ったことはあんまりない
んだけど、『日本の碁らしさ』といったものを体現してた。
ちなみに、高尾紳路に期待する声が多いのも、彼が厚み派
だからという面もある。

厚み派が減ってきた理由はいくつかある。1つは6目半と
いうコミの負担が大きくなってきたこと。黒番でたくさん
勝たなきゃいけないので、あんまりオットリ打てなく
なってきた。

2つめは、三連星に代表される『模様』への信頼が薄らいで
きたこと。これは、昭和から平成の日本の碁界を代表する
趙治勲の影響が大きいんじゃないか。

3つめは、韓国と中国の影響。世界レベルで見れば、韓国と
中国のほうが実力は上。で、その韓国と中国は基本的には
力戦指向。それに対抗するためには、必然的に日本も力戦に
強くなんなきゃいけない。

一般的にはこの3つくらいなんだけど。自分はちょっと
違う要因もあるんじゃないかと思ってる。それが『未知
への対応としての力戦』ということ。

『未知への対応』といえば王銘エンのゾーンプレス。
局面を『読み切れる場面』と『読み切れない場面』とに
分けて考えて、『読み切れない場面』では『見た目で
判断する』という打ち方。実際はもっと複雑なんだろう
けど、とりあえず自分はそう理解してる。

で、力戦指向は、ゾーンプレスとはまた違った未知への
対応方法という面があるんじゃないかと思ってる。つまり、
戦う場面を増やすことで、読める機会を増やそうという
目論見があるんじゃないか。

戦いというのは、互いの石が接近してるから、基本的
には読みの世界。そこの読みの優劣で勝敗が決することも
多い。囲碁は複雑だから、部分戦で読み切れたとしても、
全局的にはダメだったってこともある。それでも、漠然と
『感覚』に頼って打つよりは『読み』で打ちたいと思う
棋士が増えてきたんじゃないだろうか。だから、できる
だけ早い時期に戦いをしかけて、そこで読み勝つという
力戦派が増えてきたんじゃないだろうか。

でも、もちろん、厚み派にしても (あるいはゾーン
プレスにしても)、読みをまったく放棄してるわけじゃ
ない。厚みは最終的には地にしないとダメだし、その
ためには攻めや取りかけができないとダメだし、その
ためには読みの力は絶対必要。違うのは、『未知』への
評価だろう。

未知だから不安に感じるのか。それとも、未知だから
可能性を感じるのか。未知を不安に思えば、実利を確保
したり、戦いを起こして読める部分を増やそうとする。
未知に可能性を感じれば、今は手厚く打って、後の攻めに
期待する。両者の違いは、碁打ちの個性といえるんだろう。

と、長々と書いてきたけど。個人的にはこういうことを
プロが書いてくれるのが一番いいんだけど。というわけで、
そういう記事を書いてくれる数少ない棋士の一人、ゾーン
プレスの王銘エンさんの記事:

http://taisen.mycom.co.jp/taisen/contents/igo/meien/meienbacknumber.htm

上で書いたこととの関連でいえば、第23話からの『部分と
全局』あたりが『合わせて読みたい』。あるいは第20話も、
メイエン節といえる面白さ。

本家Permlink


2008年01月03日

Rubyの話。やっぱりメソッド呼び出しのカッコを省ける
っていうのはいいですね。たとえば、矩形の表現って
いくつかあるわけですけど:

class Rect
  def initialize(x, y, width, height)
    @x = x
    @y = y
    @width = width
    @height = height
  end
  attr_accessor :x, :y, :width, :height
end

とか:

class Rect
  def initialize(left, top, right, bottom)
    @left = left
    @top = top
    @right = right
    @bottom = bottom
  end
  attr_accessor :left, :top, :right, :bottom
end

でも、Rubyだったら、これを分けなくっても、どれも
カッコなしでメンバにアクセスできる:

class Rect
  def initialize(x, y, width, height)
    @x = x
    @y = y
    @width = width
    @height = height
  end
  attr_accessor :x, :y, :width, :height
  alias_method :left, :x
  alias_method 'left=', 'x='
  alias_method :top, :y
  alias_method 'top=', 'y='

  def right
    return @x + @width
  end

  def right=(n)
    @width = n - @x
  end

  def bottom
    return @y + @height
  end

  def bottom=(n)
    @height = n - @y
  end
end

r=Rect.new(1,2,3,4)
print'x=';p r.x
print'y=';p r.y
print'w=';p r.width
print'h=';p r.height
print'l=';p r.left
print't=';p r.top
print'r=';p r.right
print'b=';p r.bottom

おっと、最後はちょっとゴルフ風味 (笑)。

setterはちょっと面倒ですけど (っていうか忘れてた (笑))
でも、setter自体、必要かどうか怪しいことも多いですしね。

本家Permlink


2008年01月02日

VisualStudio 2008じゃどうなってっかしんないけど。
2005でさぁ、ビルドすっと:

========== ビルド: 1 正常終了、0 失敗、0 更新、0 スキップ ==========

って出るでしょ? これ、ビルド失敗したとき、色変えて
くんねぇかな? パッと見、失敗したかどうかわかんねぇ
んだよな。

まぁ、色変えるって、あんまりいいインターフェイスじゃ
ないんだけど、ほんとは。

だいたいさぁ、これってローカライズが不十分だよな。
日本語感覚だったら『正常終了 1、失敗 0』だろ?
まぁ、MSにしたら日本なんてニッチな市場なんだろう
けどな。

--

上の例なんかは、典型的な『親切な失敗』なんだよな。
UNIX系のコマンドだったら、成功したら何もいわない
じゃん? もちろん、警告は出すけど。でも、失敗したら
失敗したって出すわけで。一番重要な情報である『ビルドの
失敗』が一発でわかる。成功したかどうかなんて実は
どうでもいいわけ。成功して当たり前なんだから。

--

うはー。『手のりおかん』でググったら、オレんとこが
一番上かよ! どんだけマイナーなんだよ。

というわけで、作者のぶろぐ:

http://blog.so-net.ne.jp/katsupiro/

本家Permlink


2008年01月01日

新年のアメリカン・プログラマズ・ジョーク。

ウチのワイフがこういったのさ。

  あなたもとうとうダンナ2.0ね

ってね。それを聞いて、ようやくワイフもオレのことを
理解してくれたんだと喜んだんだ。ところがワイフが
続けてこういうのさ。

  10点満点中の2点ってことよ

ってね。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails