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年05月30日

当たり前の話だけど、言語で働き場所を選んじゃダメ
だよね。

まぁ、探すときは、まず言語でフィルタかけちゃうもん
なんだけど。でも、まぁ、知らない言語でも、結構
どうにかなるもんだし。

前に「自分は人で動く」みたいなこと書いたことが
あったけど。そのためには、やっぱりある程度人の
見極めっていうのができなきゃいけないんだよね。
それも、第一感ができるだけ正しくないといけない。
そんなに生で会話する機会はないわけだし。

これは獲物で取り上げたけど:

http://pitecan.com/blog/2008/05/knuth.html

これ読んで「さすがKnuth先生!」って思ったのは、
増井さんがパターンの抽出を説明したときに即座に:

  「へー。でも“bbaabbaa”みたいなときはどうするの?」

って返してきたこと。こういうのって、こういう人たちに
とっては当たり前のことなんだろうけど、即座に 「際
(きわ)」を返してくるっていうのは、「できる!」って
判断しちゃうわけ、自分は。それがKnuth先生じゃなく
ってもね。こういう人となら一緒に働いてもいい、
働きたいって思うわけ。

本家Permlink


2008年05月29日1

なんか説得力を感じないんですよね。自分が日本人で、
イチオー農耕民族だからもしれませんけど。

「小さい会社のほうがいい」っていう主張は、確かに
自分も共感するんですけど。でも、話の持っていき方と
して、狩猟民族や野生動物の話を持ってくるのはどう
なんですかね。

何が引っかかっているかというと、自分のテーマである
「ソフトウェア開発と民主主義」に引っかかるんです
よね。

人数が増えれば代議員制にならざるを得ないわけで。
代議員制は、直接制に比べたら、そりゃいろいろある
わけですけど。でも、今のところ、大人数の場合は、
代議員制を超えるシステムっていうのはできてないわけで。

リバタリアン?とか、アナーキストとか、そういうんじゃ
なきゃハッカーになれないってこともないと思うんです
けどね。もちろん、P.Graham氏も本の中でいってるとおり、
ハッカーが反社会的な特質を持ってるものだとしても。
それでも彼らが作用する対象となるのは現実社会なわけで。
つまりは、彼らもまた民主主義の一員なわけですよね。

なんか、とりとめのない話になっちゃいましたね。

本家Permlink


2008年05月29日

Dellで注文。結局11万弱。

そういえば、Dellって前はLinuxから注文できなかった
んだよね。ブラウザが対応していませんとかマヌケな
こといってた。今回はUbuntuのFirefoxから。

本家Permlink


2008年05月27日1

accountabilityが高くないとダメ。アカウンタビリティ、
説明責任、あるいはその能力。

別にペラペラしゃべれっていうわけじゃなくってね。
何をやってるかとか、何が問題なのかとか、そういう
ことをわかりやすく説明できなきゃいけないし。相手が
納得できるまで粘り強く説明できなきゃいけない。

ゴールは何なのか。そのゴールまでどういう筋道で
たどり着くのか。

バグの現象はどんなものなのか。原因は何なのか。バグを
取るためにはどうすればいいのか。

こういうことをコードじゃなく、クチで説明できなきゃ
いけない。面倒だと思うかもしれないけど、これは
とっても大切なこと。

むずかしい言葉は使う必要はない。っていうか、使っちゃ
ダメ。むずかしそうな言葉を使ってミョーな満足感に
ひたるようじゃダメ。この手のヤツが多いんだよな、
この業界。

まぁ、accountabilityもそうかもしんないけど (笑)。

『押下』とかな。こういう『開発文語』みたいなの、
あるじゃん? 普段使いもしない言葉を使うなと。

--

個人的には『弊社』とか『御社』も嫌いなんだけど。
聞いてて空々しいんだよな。『わたくしども』とか、
『そちら(様)』とか、フツーの言い方があるだろ。
なんかミョーに人間味を消そうとしてる、その意図は
何なの? 自分に責任はないといいたいのか、今目の
前にいる人じゃ話にならないといいたいのか。

まぁ、同じように『思われる』も好きじゃない。
責任の所在をボカそうとしてる意図が感じられる。
自信がないのはしょうがないんだから、それをゴマ
かしてもしょうがないだろ。

--

テストの記述。簡単な例をあげよう:

Q: ウィンドウ上部の[File]メニューから[Open...]を選ぶ。
A: ファイル・ダイアログが開かれる。

これで十分だろう。それなのに:

Q: ウィンドウ上部の[File]メニューから[Open...]を選択する。
A: ファイル・ダイアログが開かれること。

みたいに書くヤツが多い。まぁ、『せんたく』っていう
のは結構クチにすることも多いんだけどね。

単純さっていうものにもっと敏感になんなきゃダメじゃん。
単純さが価値だって普段からいってるわけだし。

本家Permlink


2008年05月27日

あの写真、写ってないけど、実は下から持ち上げてるんでしょ。わかります。

パラボラ → △
       BMW → ○=○
              ┗○┛ <早く撮れって!
                │
            《┌─┐》プルプル
              ┴  ┴

本家Permlink


2008年05月26日

ダイヤモンド見てないからアレだけど。

別に成果主義が悪いってわけじゃないよね。

若手の育成に回ったら、そりゃお金が減ることもあるでしょう。監督やコーチ
が選手よりもらうものが少ないなんてよくあること。

人気のタイトルに人が集まるんなら、そこには競争があって、自然と優秀な人
が残るということもありえるでしょう。だからこそ、人気を維持できるともい
えるわけです。

それと、やっぱり売れないものを作ってちゃダメでしょう。売れないでいいと
なると違うビジネスになっちゃう。

確かに、いわゆるデバッガとかはお金は少ないかもしれないですけど、そりゃ
しょうがないでしょう。結局、代替が利くかっていうのがお金の基本なんだか
ら。

チーム云々もどうかなぁ。チームのメンバだったら均等に山分けしなきゃいけ
ないなんてこともないと思うけど。それはそれで潔いとは思うけど。でも、やっ
ぱり、周りから見ても力のあるヤツっていうのはハッキリしてることも多いし。
それでもドングリの背比べになっちゃうっていうんなら、そこに創造の危機が
あるような気もしないでもない。

成果主義自体が悪いんじゃなくって、評価システムだとか、気の持ちようとか
のほうが問題なんじゃないの? 評価が気になっていいゲームが作れないなん
ていうのは、もともとゲーム作りに向いてない人間なんでしょう。

まぁ、日本全体が成果主義というものにまだ慣れてないっていうことなのか
なぁ。成果主義がダメなら海外とかどうなっちゃうの?って感じだよね。まぁ、
そっちの事情は全然知らないんでアレだけど。

--

大体、2:8の法則っていうくらいだから、できるヤツがオレの4倍くらいもらっ
てても、オレは全然腹は立たないんだよね。いや、別にもっともらっててもい
い。お金がほしいっていうのはオレの事情から来るもので、誰かと比較してど
うこうじゃないからね。オレの場合は。だから、くれるんだったら1億でも10
億でももらうけど、『アイツがいくらでオレがこれっぽっちじゃ納得いかん』
とかはない。

本家Permlink


2008年05月25日

寝床のWindows PCが突然動かなくなって。どうも電源が
イっちゃったみたい。

で、次のを考えてるんだけど。DellかHPかなぁ。今これ
書いてんのはHPのヤツなんだけど。

DellはWinXP選べるんだよねぇ (笑)。それで10万切る。
Core2 Duoでも。

値段だけでいえば、HPのほうが安いんだけど、AMDのが
シングル・コアなんだよね。DellのはAMDでもデュアル
のしか売ってない。

というわけで、ここのペースが多少落ちるかも。

本家Permlink


2008年05月23日1

ああ、Ruby会議でエアジョブスやったらウケるんだろうなぁ。
できないけど。

本家Permlink


2008年05月23日

確かに『Code Complete 第2版』はいい本なんだろうけど、
網羅的すぎて、オレたちには合わない、古典的なやり方も
数多く紹介されている。

たとえば、p.118、『5.3.6 変更の可能性が高い領域の
特定』。こういうギャンブルは、オレたちはやらない。
可能性というからには、予想がハズれることがあるわけだ。
予想が当たれば万々歳だが、ハズれたらどうする?

どんなものでも、コードを書くにはコストがかかる。
予想がハズれたら、そのコストは回収できない。

p.91にタコマ海峡橋の話が紹介されている。それを
アナロジーとすれば、オーバー・エンジニアリングも
許されるということになってしまう。けれども、
オレたちはソフトウェアを作っているんだ。橋は一度
作ってしまえば、それが壊れない限り、作り直すことは
難しい。補強するという手段は残されてはいる。それでも、
ソフトウェアほどラディカルに作り変えることはできない
だろう。

オレたちはギャンブルはやらない。現状を良くするだけだ。
その良くするための指針が、繰り返しになるが:

* lots of little pieces
* once and only once
* low coupling, high cohesion
* rate of changes

ということになる。これらの指針は、可能性のためでは
なく、今現在のシステムを良くするためのものだ。

そしてなぜか、この指針を守ると変更に強くなる。
理由は単純で、この方針は結局モジュール化を促して
いるに外ならないからだ。

結局、『変更の可能性が高い領域の特定』なんかやる
必要はなく、この指針を守るだけでいいっていうことに
なる。それが基本や原則の持つ強みだ。

--

蛇足だけど、rate of changesは可能性じゃなく、現実の
話。実際に手が入ることの多いところは切り分けましょう
っていうこと。『なんとなくこのへんは変更されそうだ』
という曖昧な想像の話ではない。

本家Permlink


2008年05月21日

http://www.chunichi.co.jp/article/feature/yui_no_kokoro/list/200805/CK2008051802012309.html

『トヨタの足元』の次は『カローラの魂』なのか。

本家Permlink


2008年05月20日1

コードじゃ埋まらない心の穴もある、だろ?

--

理系でもなく、文系でもなく、バカ系ということで。

--

結局、バカなんだよね。いつまでたっても。何度
生まれ変わっても。おんなじバカやりそうな気がする。

本家Permlink


2008年05月20日

架空のGUIライブラリを使うんだけど、GUIを作るときに:

@ok_button = Button.new
@cancel_button = Button.new
@ok_button.set_text('OK')
@cancel_button.set_text('Cancel')
@ok_button.move(RECT_OK)
@cancel.button.move(RECT_CANCEL)
@ok_button.add_callback(proc{puts true})
@cancel_button.add_callback(proc{puts false})

みたいな書き方ね。ヘンだと思うでしょ? こういう順番に
なってるとき、メソッドを切り出すとなると:

def new_buttons
  @ok_button = Button.new
  @cancel_button = Button.new
end

def set_text_buttons
  @ok_button.set_text('OK')
  @cancel_button.set_text('Cancel')
end

def move_buttons
  @ok_button.move(RECT_OK)
  @cancel.button.move(RECT_CANCEL)
end

def add_callback_buttons
  @ok_button.add_callback(proc{puts true})
  @cancel_button.add_callback(proc{puts false})
end

みたいになるわけ。こういうのはダメな設計なのね。

lots of little piecesは満たされてるんだけどね。
こないだ``low coupling, high cohesion''っていうのも
書いたでしょ。上のはこのhigh cohesionが満たされて
ないわけ。

high cohesionの1つの形としてself-containedっていう
のがあるのね。自己完結って訳されるのかな。ここでは、
そのメソッドが、そのメソッドだけで1つの完全な機能を
提供するっていう意味なんだけど。

GUIなわけでしょう。で、ボタンなわけでしょう。で、
ボタンを作るわけだよね。だったら、最初の書き方も:

@ok_button = Button.new
@ok_button.set_text('OK')
@ok_button.move(RECT_OK)
@ok_button.add_callback(proc{puts true})
@cancel_button = Button.new
@cancel_button.set_text('Cancel')
@cancel.button.move(RECT_CANCEL)
@cancel_button.add_callback(proc{puts false})

ってなるでしょ。さらにここからメソッドを切り出すと:

def new_button_ok
  @ok_button = Button.new
  @ok_button.set_text('OK')
  @ok_button.move(RECT_OK)
  @ok_button.add_callback(proc{puts true})
end

def new_button_cancel
  @cancel_button = Button.new
  @cancel_button.set_text('Cancel')
  @cancel.button.move(RECT_CANCEL)
  @cancel_button.add_callback(proc{puts false})
end

みたいになるわけね。メソッドが「1つのボタンを作る」
っていう機能で自己完結してるでしょ。こうしたほうが
コードも動かしやすい。自己完結してるからね。でもって、
さらにonce and only onceできそうな感じもしてくるでしょ。

リズムっていう視点もあるよね。後者のほうがなんとなく
リズムがいいように感じるでしょ。ああ、こういうときは
「なんとなく」を使うんだけど (笑)。

こういう小さいレベルの設計っていうのもあるわけね。
それは無意識に近いレベルでやってるんだけど。でも、
こういう小さい設計の積み重ねがないと、大きなシステム
だってダメになっちゃうんだよね。だって、low coupling,
high cohesionっていう同じ設計原則が大きなレベルでも
使われるんだから。

本家Permlink


2008年05月19日1

東スポ、サザンのスクープ、来たね。まぁ、解散じゃ
なかったけど。

みんなに『東スポのこういうネタは当たるんだよ!』
っていってた手前もあって、ホッとした (笑)。

東スポっていうと『本当のことは日付だけ』とかいわれ
まくってるんだけど (笑)。でも、他紙じゃ書かない、
書けないネタが多いのも事実なんだよね。

たとえば、今日の社会面の記事なんかも東スポ独特の
切り口。『東京調布不発弾処理ルポ』っていう記事なんだ
けど。もういきなり『ルポ』だからね (笑)。

で、見出しにもあるように、話の中心はなぜか引きこもりの
人たち:

  調布市はベッドタウンで、都心に比べて実家暮らしの
  ニート青年や、引きこもり青年が多いようだ。
  (中略)
  数年ぶりに日中を出た引きこもりの若者たち。不発弾
  処理という思わぬ理由で強制的に外出させられたのを
  機に、気持ちが外に向けばいいのだが・・・。

調布、不発弾、引きこもりって、あんた、三題噺か!?
っていうね (笑)。

ドラゴンズの落合監督、もうガンダムオヤジでかなり
知られてると思うけど。東スポはフクシとツーカー (笑)
だから、濃い記事が入ってくる。5/13から:

  実は今、大のガンダムファンである落合監督と福嗣
  さんの間では「ガンダムシリーズに出てくるセリフを
  使って会話する」ということがブームになっており、
  親子間の意思疎通は``ガンダム語録しばり''で行われて
  いるのだ。

  たとえば、落合監督が外出先から家に戻ってきた時には
  「そんな道理、私の無理でこじあける!」と言いながら
  玄関の鍵を開け (以下略)

これ読んだときは絶句したね (笑)。

--

さすがにP.Graham氏に``Be Good''なんていわれると自分
だってビビるわけです。

でも、話の中に出てくるOctpartの人たちだって、最初は
『研究をしていて出くわした問題を解決したかっただけ』で、
社会人類に貢献しようとは思ってなかったはず。

それに、P.Graham氏は最初に『人のほしがるものを作れ』
っていってます。これはまた微妙に、というか非常に、
というか、センスのいい言葉で。漠然とした『社会人類に
貢献する』なんていうのよりもよっぽどわかりやすい。
自分がほしいものなら、少なくとも一人の『ほしがるもの』
は満たせるわけで。

--

で、surviveっていうと、『必死だな』みたいな感じに
受け取られるかもしれませんけど、そうじゃなくって。

surviveはsustainableじゃないとダメですよね。だって、
ずーっと続けてくことだから。sustainableが一番
surviveできるわけです。

本家Permlink


2008年05月19日

いやね、もっとsurviveっていうのを真剣に捉えないと
いけないよね。

surviveできなくなるっていうのは、このご時世、そんなに
遠いところの話じゃないよね。仕事がなくなるとかね。
心身を壊すとかね。ほんとに、今日明日起きてもおかしく
ない状況なわけでしょう。

だから、「競争に勝つ」とかね。そういうんじゃなしに。
もっと、ほんとに身近なね。生命というものの話なわけ
ですよ。今日明日を生き抜くっていうね。

surviveっていうのがあって、そのためにsuccessだとか、
learnだとか、be happyとかがあるわけです。successだとか、
learnだとか、be happyとかも大切なんだけど、それって
結局、surviveのためだったり、surviveのあり方だったり
するわけです。

だから、そこを間違えちゃうと、つまり、successだとか、
learnだとか、be happyだとかが目的になっちゃうと、
やっぱりsurviveの力っていうのが弱くなるよね。

successできなくっても、learnできなくっても、be happy
できなくっても、surviveだけはできなきゃいけない。

本家Permlink


2008年05月18日

いやぁ、最近は『綾鷹』ばっかだね。昔はgreentea
名乗ってたくらいで、もともと緑茶は好きなんだけど。
ようやく自販機でもマトモな緑茶が出たって感じ。

--

『OOPは大規模に効果的』なんてことをいわれてた時期も
あって。自分もそれをマに受けて、人前でそう話した
こともあるんだけど。

もちろん、ここでいってる『大規模』っていうのは、
人の頭数なわけで。で、今の自分からしたら、この手の
大規模にはOOPはそんなに効果がないと思ってる。

人の頭数という意味での規模っていうのは、やっぱり
人の問題として扱わないとどうにもなんない。そこに
OOPが貢献できる余地は、なくはないかもしんないけど、
あったとしてもかなり小さい。

もちろん、OOPが個人の生産性を高めるっていうのは、
自分の実感として持ってるのね。でも、だからっていって、
それが集団にもいえるかっていうと、話が違うよね。
人間っていうのは、そんなに単純なパラメータじゃない
から。

それが5人、10人のチームであっても、どの言語を選ぶか
よりも、どんなサイクルでプロジェクトを回してくのか
とか、どうやってみんなのレベルを底上げするかとか、
そういったことのほうが重要になる。

--

だから、プロジェクトが長くなると、どうしたって
チームのレベルを底上げする必要が出てくる。ドメインを
よりよく理解する。システムをよりよく理解する。技術を
よりよく理解する。こういう学習が繰り返されないと、
やっぱりダメになるよね。

だから、プロジェクトを成功させるカギの1つは、こういう
学習をいかに仕事に自然に組み込むかなんだよね。

定期的に勉強会開いたりとか。定期的にレビューやったり
とか。何か問題が起きたときは、すぐその問題をみんなで
共有して解決するとか。

--

仕事の中で学べることもあるんだけどね。でも、たとえば、
残業1時間やるよりは、勉強会1時間やるほうが効果的だと
自分は思ってるのね。若い人がいるときは特にね。

まぁ、フツー、勉強会っていうと、週1回2時間くらい?

で、これは、結構切羽詰まってるときでさえ変わらないと
思ってるのね。納期が一ヶ月後とかだったら、全然余裕で
勉強会やったほうがいい。というか、そんぐらい強い
気持ちを持ってないと、すぐ続かなくなる (笑)。

勉強会の効果っていうのは、たとえば本読んだりして
知識を蓄えるわけだけど。そればっかりじゃなくってね。
本に書かれてる話を取っかかりに、今やってるプロジェクトに
ついてザックバランな話が出たりもするんだよね。
それで、『ああ、この人はこんなことを考えてたのか』
とか、『ああ、この人はこんなことで悩んでたのか』
とか出てくるわけ。で、解決できるなら解決して、共有
できるなら共有して、相互にレベルアップするわけ。

自分は呑まないし、呑む席で仕事の話してもしょうがないと
思ってるし。そうなると、ちょっと距離を置いて仕事の
話をする機会っていうのは、案外貴重だと思うわけです。

本家Permlink


2008年05月17日

でも、作りたいものが見つかることって、あんまないん
ですよね。ぶっちゃけね。

そうすっと勢い、身近なものになっちゃうじゃないですか。
それが言語だったり、OSだったり、エディタだったりな
わけでしょう。でも、そういうのって、『どうしても作り
たい』っていうもんじゃないでしょ? だって、今もう
誰かが作ったのがあるわけだから。

それに、身近なものほど奥が深いっていうか、実現すんのが
大変になるでしょう。もちろん、オモチャのレベルで
いいっていうんなら話は別ですけど。たとえばブラウザ
にしても、IEのコンポーネントとか使うんだったら別
ですけど、スクラッチでやろうとしたら大変なことに
なりますよね。

だから、一番いいのは:

1. まだ誰も作ってなくって
2. 簡単に作れる

ものなわけですよね。まぁ、そんなウマイ話はそうそう
転がってるわきゃないんで (笑)。

こういう、いってみれば『創造の苦しみ』みたいなものが
あるから、自分は、言語をまず先に選んでから『さて、
何を作ろうか?』っていうアホなやり方も否定できない
んですよね。プログラミング自体が楽しいっていうことも
あるわけですし。

本家Permlink


2008年05月16日

「プログラマーとプログラマーでない人との掛け橋」って、
結局プログラマじゃないってことじゃね? SEとか?

まぁ、DDIか。

--

う〜ん、女性のPHPプログラマって、たくさんいると思う
んだけど。だから、自分は、ギークになんか憧れない、
文系出身のフツーの女性プログラマを応援しますよ。

(と高感度を上げる作戦)

--

http://www.rakuten.co.jp/kutsukoubou/463183/463159/463161/

履きやすいし、安いし、脱ぎやすいので、最近ずっとこれ。

黒ね。

爪先が広いのがいい。

ただし、「すべりにくいゴム底」って書いてあるけど、
塗れたマンホールの上とかツルツルすべる (笑)。

あと、底が減りやすい。まぁ、安いからいいんだけど。

歩くのには全然不向きだけど、そんなに歩かないしね。
もちろん、見た目は最悪 (笑)。安いのがモロバレ。

--

靴の脱ぎやすさっていうのは重要で、サンダル禁止な
もんで、靴脱ぐわけで。

自分が長年観察した結果、デキるヤツは靴を脱ぐ (笑)。
いや、これほんと。

本家Permlink


2008年05月15日

いろいろ書いたけどどうでもよくなった。

オレもバカならアイツもソイツもバカばっかりって
こったな (笑)。

--

『誰がそれをやるべきなの?』の変種に『どうしてお前が
ソイツのこと知らなきゃいけないの?』っていうのがある。
『恥ずかしがりやのオブジェクト』を反対から見た形だね。

使われる側のオブジェクトにしたら、できるだけ内側は
見せなほうがいいわけだ。で、使う側のオブジェクトに
したら、知る必要もないものは知らないで済ませたほうが
いいわけだ。

だから、オブジェクトっていうのは、恥ずかしがりやの
ほうがいいし、世間知らずのほうがいいってわけだ (笑)。

本家Permlink


2008年05月13日1

6,000人のヤツ。あーだこーだ騒いでってけど、オレに
いわせりゃ上出来だよ。皮肉じゃなくね。

そりゃ、何のトラブルもなく済んだほうがよかったさ。
でも、そんなわけにはいかねぇし、そんな中であの
程度で済んだんだからほんとに上出来だよ。ご苦労様
でしたといいたいね。まだまだプロジェクトは続く
みたいだけどね。身体に気をつけてやり遂げてほしいよ。

--

でだ、早速トラブルの原因が発表された:

http://www.itmedia.co.jp/enterprise/articles/0805/12/news080.html

で、諸君らは、こういうトラブルも静的型で防ぐことが
できるというのかね。

バカも休み休みいえ。

このあいだも書いたが、バグを修正する手間と、その
バグによって被る損害とは関係が薄い。カタカナと
漢字を間違って処理するという、極めて初歩的なミスで、
被った損害は、国から対応を求められるといった諸々を
含めれば、数億は下らないだろう。そうした莫大な
損害を、静的型を使うだけで防げたというのか、君たちは。

genericsは大規模に有効だといったよな? 覚えてるぜ、
オレは。そんなにgenericsが大規模に効くってんなら、
今から糖蜜に掛け合ったらどうだ? 高く雇ってくれるん
じゃねぇか?

--

価値観は人それぞれだけど、オレには『プロジェクトは
失敗したけど、技術的には成功した』なんていうのは
何の意味もない。何の意味もねぇんだよ。

プロジェクトが成功する、チームのメンバが生き残る
こと以外に、自分の仕事の目的は存在しない。その
目的を達成するために自分の技術を活かす。それだけ
なんだよ。

オレの仕事はエンジニアリングじゃなくソフトウェア開発だ。

本家Permlink


2008年05月13日

違う業界で違う仕事をやってると思わざるを得ないな。

まぁ、自分がオールドタイマーだとしても。

まぁ、これだけ業界の裾野が広がってれば、オールド
タイマーでも喰ってくことはできるだろ。

--

genericsがパラダイムシフトとは思えんけどな。それが
パラダイムの1つとはいえてもだ。

本家Permlink


2008年05月12日1

まぁ、自分がこんなんだから、何いっても説得力ないっ
つーのはわかってっけど (笑)。マジな話をしてるときも
あるんだよ。マジな話、マジバナな。

その日のコードはその日のうちにコミットするとかな。
『リスが冬眠するんじゃないんだからコードを大事に
取っととくな』とかいうからダメなのかね (笑)。

でもな。その日のうちにコードをコミットするってことは、
実は大変なことなんだよ。だって、コミットしてブっ壊し
ちゃったらダメなんだから。だから、やり方が変わっちゃう
わけよ。ここでいっつもいってる手順っちゅーのが大切に
なってくるわけだ。

あと『キリ』ってのもそう。よく『キリのいいとこまで
やってから帰るっス』っていってるヤツいっけど。まぁ、
気持ちはわからんでもないけど。けど、キリなんてのは、
簡単につけられるんだぜ? 今書きかけのコード捨てちまえば、
それでケリがつくだろ? これもマジバナでいってんだぜ?
そんな、いつ終わるかわかんねぇキリなんてもんに
こだわってるくれぇなら、明日やんなきゃいけねぇことを
整理しておいたほうがよかねぇか? それが準備ってもん
じゃねぇのか? それにクールダウンも大切だぜ?

だから、キリなんていうのは時間で切っちゃっていいと
思うんだけどね。6時なら6時、7時なら7時で決めちゃえば。
そこまでにコミットできなかったコードは捨てる。で、
クールダウンを兼ねて明日の準備をする。それでいいじゃん。

まぁ、自分なんかgdgdだし、バカばっかいってっけど。
『東スポの一面、またUFOだったよ!』とかな。でも、
そうじゃないときもあんだよ。わかった?

--

まぁ、プロジェクトには山場っていうのがあるもんだけど。
でも、終わらないからっていってダラダラと山場を続ける
わけにはいかねぇじゃん? だから、山場は期限決めとか
ないとダメなんよ。でないとデスマーチになっちゃうだろ?

--

って、こういう話をみんな書かないよね? なんでだろうね。

こういうことを考えることのほうが、言語とかフレームワーク
なんかよりよっぽど大切で、よっぽど生産性が上がると思うん
だけど。

本家Permlink


2008年05月12日

まぁ、オープン・ソースに限らず、プロプライエタリも
含めて、おしなべて品質が悪いっていうことじゃないです
かね。

でも、そもそも、ソースが見れないと品質はわからない
わけで。もちろん、ここでいう品質っていうのは、中から
見たときの品質ですけど。

使う側からしたら、コードがどう書かれてようが知った
こっちゃないんですけど。バグが出なけりゃ、それは
品質がいいといえるわけです。(もっと贅沢な要求もある
にはありますけど。最近よくいわれるユーザ体験とか。)

でも、大抵のプログラムは、寿命が結構長くって、追加や
修正や変更といったものが繰り返しやられるわけです。
そうなると、やっぱり中から見た品質っていうのも大切に
なってくる。

本家Permlink


2008年05月11日

昔のノートをgrepしたんですけど。当時、自分は、あの
本を『クラス指向』の本だと書いてますね。1998-06-05:

  現在のオブジェクト指向方法論 (OOA/OOD) に違和感を持っている人もいる
  ようです。私は、OMTをちょっと読んだだけでしたが、ずいぶんと違和感を
  持ちました。そして、今、『憂鬱なプログラマのためのオブジェクト指向開
  発講座』(Tucker!著、翔泳社)を読んでいるのですが、やはり違和感を覚え
  ます。

  その違和感を自分なりに探ってみると、『オブジェクト指向=クラス指向』
  という図式にブチ当たりました。

  上の2冊では、最初に要求を固めた後、分析の最初の作業としてクラスを探
  し出すことから始めます。そして、いきなりクラス図を描き、以降の設計/
  実装を通して使われていくことになります。ゆえに、『オブジェクト指向=
  クラス指向』というわけです。

  私は、ロクすぽ分析/設計もしませんが、それでも、『オブジェクト指向=
  クラス指向』には違和感を覚えます。

  最初に仕様を見て、思い描くのは何か? そう自省すると、クラスではなく、
  やっぱりオブジェクトなのです。もちろん、ここでいうオブジェクトという
  のは、インスタンスと同じ意味ではありません。インスタンスはクラスがな
  ければ成り立たないですが、オブジェクトは、それ1つで存在します。また、
  このオブジェクトは、クラスとも異なります。クラスは『分類されるもの』
  というニュアンスが強いですが、オブジェクトは『認識されるもの』という
  ニュアンスが強いのです。

  私の感覚では、クラスという概念が登場した時点で、すでに設計段階に入っ
  ています。つまり、上の2冊で紹介している分析/設計は、すべて設計に感
  じるのです。

ちなみに、非公開のノートなのに『ですます調』を
使ってるのは当時から今も変わりません。

で、これよりも前に連載中に言及してるところもあって、
それは1997-08-25。自分がJavaをやりはじめたのは
1996年の前半 (まだMacだった)。1997年の頭には
Libretto 30にLinuxをインストールしたことが書かれて
ます。まぁ、そういう時代だったと。

実際、今でも自分は『クラス指向』という言葉を皮肉
として使ったりもするんですけど。改めて考えると、
よくわかんない言葉なんですよね、『クラス指向』って (笑)。

だから、自分が『クラス指向』っていってるものって、
結局、プロセスに対する違和感だと思うんですよね。
クラス指向っていうと、『クラスを見つければ終わり』
みたいなイメージが浮かぶわけです。それは当時の
OOA/OODも大体そんな感じで。

でも、実際のプログラミングっていうのは、OOPも含めて、
もっとヒューリスティックなものでしょう。heuristic、
『発見的手法』ね。覚えた言葉はすぐ使わないと忘れ
ちゃうから (笑)。

オブジェクトが見つかるタイミングっていうのは、
分析や設計のときに限らず、コーディングしてるときにも
見つかるわけです。というか、agileやってれば、むしろ、
そっちのほうが多いくらいで。

で、そういうのがあって『設計=コーディング』って
いう認識が生まれつつ、XPなんかでそれが決定的な
ものになったと。

大きなものを作るときは、それなりに準備は必要です。
でも、agileだったら極端に大きなものは作っちゃ
いけないし。小さなものからはじめて育てていく。
それと、いわゆるOOA/OODでは時間の概念がないって
いうのは何回も指摘してますけど。段階を踏んで作り
上げるためには、OOA/OODとは違った準備が必要です。

--

パッチはいかんよね。

バグを直すときは、直接的な個所を直したくなるもの
だけど。でも、ちょっと立ち止まって、それが設計を
見直すいい機会にならないか考えてみる必要がある。

大体、コードっていうのは似通ったとろがあるもんだし。
だから、ある場所のバグっていうのは、他の似通った
場所にも潜んでる可能性が高いもんだしね。

そうやってバグを根本的に潰してかないと、モグラ叩きに
なっちゃうしね。

--

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

Wardがエンジニアリングについて書いてる。むずかしい
英語で、半分も理解できないんだけど。

--

自分、UFJも使ってるんだけど、今日、コンビニで預金
できなかった。もうはじまってるんだね、6,000人のヤツ。

2ch読む限り、大きな障害は出なさそうだね。
まぁ、何よりです。

っていうか、年内はATM、土日ダメってマジ? それは
ちょっとカンベンしてほしいんだけど。

--

http://shop.nisiyoko.com/i-shop/category_l.pasp?cm_large_cd=5&to=cl

ん〜、ニッチ。

あ、使ったことないんで、オススメとかじゃないです。
単なるネタです。

本家Permlink


2008年05月09日

『一度コンパイルを通せば動くだろ』か。そういう
セリフ、前にも聞いたことがある。『分析や設計を
キッチリやれば実装なんて簡単だろ』ってヤツ。

いってることはおんなじだよ。結局銀の弾丸だ。

かつての『工学派』がこういう形で生き長らえてるとは
思いもよらなかった。

実行時じゃなきゃわかんないバグなんていくらでもあるし、
しかも厄介なのは、バグを修正する手間と、それによって
被る被害が全然無関係なことがあるということ。金額の
桁を間違えただけで訴訟沙汰だよ。

こないだ、genericsやメタプログラミングは個の力を
強めるって書いたけど。それって、ある意味、大規模とは
全然逆の方向を向いてるんだよね。その根底にあるのは
『人手を介したら負け』っていうことなんだから。

自分はgenericsやメタプログラミングは全然否定しない。
ただ、それを大規模と結びつけんのはおかしいだろって
いってるだけで。

6,000人の話のときも書いたけど、もう世間の関心は、
頭数っていう意味での大規模にはない。この業界で
大規模っていったら、伝統的にはこれだったんだけど。

--

『エンジニアリング』という言葉で思い出したのがこれ:

http://d.hatena.ne.jp/squeaker/20070123

まぁ、ぶっちゃけ、これ読んでもエンジニアリングって
何かよくわかんなかったんだけど (笑)。でも、これも
個の力を強めるというか、P.Graham流にいうなら『テコ』の
話をしてるのはわかる。

自分が『工学派』と呼ぶものについてはこれが近いか:

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

--

http://news.livedoor.com/article/detail/3600822/

アハハ。年収でもオレがプログラマであることが裏付け
されるわけか。SE様のいうことが正しい (笑)。

本家Permlink


2008年05月08日

今日の出来事。若いのが『メモリ・リークしてるんです
けど、どこから漏れてるかわかんないんです』みたいな
話を持ってきて。リークしてんのは、ある描画メソッド
だっていうアタリはついてんだけど。けど、そのメソッドが
またクソ長くって。

で、自分の場合、こういうのを見たとき、リーク云々じゃ
なしに、とりあえずextract methodすることを考える。
で、そのつもりでそのクソ長いメソッド見てたら、何も
してないコードが見つかって。で、とりあえずそこを
コメントアウトしてみた。んで実際に動かしてみて、
別に描画がおかしくなることもないから、『ここ、
いらないよね』って声をかけて。そしたら、その若いのが
タスクマネージャを見ながら操作して、『あ、メモリも
増えなくなりましたね』って。

まぁ、こんなにうまく行く話は滅多にないんだけど。でも、
漠然とコードを読むよりも、どこを切り出そうかとか
考えながらコードを読むほうが、いろんなことに気づき
やすいというのはいえる。

どこか切り出して別のバグを入れちゃうこともありがち
なんだけど。でも、もともとがクソなんだし、バージョン
管理もやってるし、そんなに恐がることもない。

メソッドが十分に短ければ、バグがあるかないかも
わかりやすい。メソッドの前のほうでSelectObjectして
んのに、あとでDeleteObjectしてないじゃん!とか。

--

やっぱり責任の分配というのが大切。責任の分配と
いうのは、結局のところ、『それは誰がやるべきなの?』
という疑問の答えを見つけること。

たとえばダイアログが太りすぎてたら、モデルかコントロールに
仕事を移してやる。ウィンドウが表示されてるかどうかを
知るのに、フラグでは持たずに、直接ウィンドウに尋ねる。

--

やっぱり『バランスを図る』っていうのは、言い方として
曖昧だよね。バランスって、結局、個人個人の感じ方で
違うし。

たとえば、責任の分配にしても、それを『責任のバランスを
考える』っていう言い方もできるだろうけど。でも、
バランスっていう言葉を使っちゃうと、無意識にも、
五分五分をイメージしちゃうでしょ。そうじゃないわけ
でしょ。責任を持つべきものが持つのであって、それを
ムリヤリ五分五分で分配したら、責任の分配ミスって
ことになる。

もしバランスということで意味があるとしたら、それは
多分早さだよね。バランス感覚って、早さだから。

前にも『センスは早さ』って書いたことがあるけど。
だから、『バランスを考えましょう』なんて書いて
あっても、それは実質、『センスを磨きましょう』って
いってんのとあんまし変わんなくって。まぁ、もっともな
言い分ではあるけど、大して役に立つアドバイスじゃない
っていう (笑)。

本家Permlink


2008年05月07日1


本家Permlink


2008年05月07日

もう大規模の話とかどうでもいいって何度も書いてる
んだけど、つい乗っちゃうんだよな、オレも (笑)。

genericsが大規模開発で役立つって、何か夢でも見てん
じゃないの? C++見てみなよ。ATLにしても、あれが
どんだけ大規模開発に役立ってるかなんて誰にもわかりっこ
ない。オマケにWTLはMSからほぼ見捨てられてる。STLは
どうか? まぁ、よく使われてはいるけど、今だにearly C++
使ってる連中もたくさんいる。それにSTLで役立ってる
ところといえばコンテナ周りがほとんどで、コンテナだけで
大規模の問題が解決できるわけもない。

何度も書いてるけど、規模の問題っていうのは、人の
問題だ。generics理解できる連中を100人集められるか
っつったらムリだろ。全然現実的じゃない。「使うだけ
ならgenericsを理解する必要はない」って? そういう
官僚的な、あるいは貴族的な発想こそ、大規模開発を
失敗させる要因の1つだろう。

ほんとにダイキボダイキボ騒ぐ連中っていうのは、
全然現実的じゃないよな。「大規模っていっときゃ
カッコイイだろ?」みたいな感じで。ほんとに大規模
云々するんなら、実際に大規模開発で実績出してから
いえ。

--

だから、6,000人の話とか、結構キツイこと書いてっけど、
全然期待してないわけじゃないんだよね。成功するにしろ、
失敗するにしろ、何かしらアウトプット出してくれる
ことは期待してるんだよね。さすがにそういうとこから
出された資料なら、自分だって参考にせざるを得ないし。

--

だから、genericsにしても、Lispのマクロにしても、
そういうメタプログラミングっていうのは個の力を
強めるのが目的であって、規模とかは全然意識して
ないだろ。もちろん、ここでいってる規模っていうのは
人の頭数のこと。


本家Permlink


2008年05月06日

ふふ。まぁ、それがそのころの一般的な風潮だったわけ
ですよ。だから自分はXPに魅かれてったんですよ。

--

技術力の低さを顧客のせいにしちゃいけないよね。
技術力と値付けは別問題だし。

--

ebanさんがラノベに興味を持たれたようです。

本家Permlink


2008年05月05日1

ん? ロベールさんは仕事でC++でしょ? 面識ないけどね。

--

素人だからこそ『本物のプログラミング言語』に憧れる
っていう部分はあるよね。実際、オレがそうだったし。
あと、インタプリタはイヤだっていうのもあった。

まぁ、そういう、ヘンなこだわりみたいなのは段々
薄らいでいったんだけど。

今は『本物のプログラミング言語』だけでも星の数ほど
あるし、インタプリタが一番好きだし。

C言語っていうのは、職業プログラマだったら必須なん
だけど、そうじゃなかったら話は変わるしね。たとえば
VBAで十分だっていう人もいるだろうし。昔と違って、
今は入口もたくさんあるから。

だから、アドバイスするなら、常識的だけど、どの言語を
選ぶかよりも、何をやりたいかを先に決めないと。それが
ないとワケワカラン話になりがち。

でも、逆に、C言語やりたいんならやればいいと思うよ。
本人が満足するのが一番であって。それで挫折したら、
そんときまた考えればいい。もちろん、その挫折で
プログラミングそのものを嫌いになられると困っちゃう
けど。

本家Permlink


2008年05月05日

『ソフトウェア開発者採用ガイド』(J.Spolsky、翔泳社)

まぁ、なんだ。あんまり役に立たない本 (笑)。

だって、自分はsmartっていうわけじゃないし、この本に
書いてあるような採用方法だったら、100%不採用になる
自信があるし、当分は雇う側に回る予定もないし。

内容的にも『Joel on Software』とそう変わらない気が
する。あの中の1つか2つの話を取り出して肉付けした
感じ?

何度か書いたことがあるかもしれないけど、やっぱり
Joel氏とP.Graham氏は似てるよね。で、どちらも人気が
あるんだけど。書かれてることは、自分に当てはめたら
相当厳しいことになるはずなんだけど。不思議だよね。
Joel氏の熱心なファンだからといってFog Creekで働ける
わけじゃないし、PGの熱心なファンだからといって
ハッカーになれるわけじゃない。まぁ、本というのは
そういうものかもしれない。

印象に残ってる話でいうと『最適でないチームを直す』の
中の『違ったタイプの貢献者たち』がある。前に自分は
『数値化しにくいところで勝負したい』みたいな話を
書いたけど。やっぱりsmart and gets things doneでは
ない、best and brightestでもない、自分のような
gdgdileはこれを狙うしかない (笑)。

しかし、こういう本で索引があるのも珍しいね。

本家Permlink


2008年05月04日

たとえRailsを使ってようが、フレームワークって
いうのは自前で作り上げなきゃいけないんじゃないの?
だって、ビジネス・ドメインのフレームワークじゃ
ないんだから。

何か? じゃあ、Railsといったフレームワーク以外の
ところはグチャグチャで構わないってか?

んなわきゃねぇだろ。

そりゃ、既存のフレームワークに乗っかってチャチャッと
作れる場合もあるだろう。でも、それじゃ商売になんねぇ
だろ?

カネになるのは、ビジネス・ドメインにあるんだから。
で、そのビジネス・ドメインっていうのは、もちろん
過去にはなかった、あるいは他者 (他社) にはなかった
部分なわけだろ。だから、自分で作ることでカネになる
わけだろ。

だったら、カネになるところで創意工夫っていうもんを
するのが当たり前だろ。それがフレームワークっていう
もんだろ。フレームワークができてはじめて、その
ドメインの知識をコードという形で蓄積できたといえる
わけだろ。でなきゃ毎回毎回コピペの連続だ。

フレームワークというもんを表層的に理解するんじゃ
ないよ。それは単なる再利用可能なライブラリじゃなくって、
人間の知識を系統的にコードで表現したものなんだから。
それがわかってないってことは、結局は自分の仕事である
ソフトウェア開発っていうもんを理解してないってことに
なるだろ。

ほんとにエセアーキテクトが多いな。
アーキテクト (笑) だよ。

--

『S6でロスト』って、そんな言い回しがあんのか (笑)。

本家Permlink


2008年05月03日

『プログラミング Gauche』(Kahuaプロジェクト、オライリー・ジャパン)

9章あたりからようやく面白くなってくるけど、
それまでが退屈すぎ。レアな構文は、どっかうしろの
ほうにチャチャッとまとめるだけでいいんでは?

Gaucheって、現実的な問題、言い替えると、身近な問題を
解決するための処理系でしょう。だったら、その解説本も、
身近な問題を解決する例をたくさん取り上げたほうが
いくないですか。

これは自分だけじゃなくって、みんなが思ってる疑問
だと思うんですけど、結局、『Schemeで何ができんの?』
っていうのを知りたいわけですよ。『Schemeとは何か?』
っていうのは、実はどうでもよくってね。

で、その『Schemeで何ができんの?』への答がGaucheだと
自分は思ってるわけです。実際、Gaucheが生まれた
きっかけって、Shiroさんが『Lisperである自分がなぜ
Perlを使わなきゃいけないんだ?』っていう疑問だった
わけじゃないですか。だったら、『それ、Perlでもできる
じゃん』っていわれる部分を恐れず突いて、その上で
Schemeならではの色を出せばいいんであって。R5RSとか
どうでもいい話じゃないですか。

まだ9章読みはじめたばっかですけど、今んとこ、Schemeを
使う面白さだとか楽しさとかは伝わってこないんですよね。
新しい言語を学ぶのに、なんでそこまでストイックに
なんなきゃいけないのか。

--

やっぱり、ソフトウェア開発では、ムリ・ムラ・ムダって
いうのは、設計にこそ用いられるべき言葉なんだな。

ムリ:責任の過剰な集中
ムラ:重複、あるいは過大な粒度
ムダ:過度な冗長性、抽象化

--

ゴールデンウィークだっていうのに、なんでこんなん
ばっか書いてるんだろう。

--

しかも、おくじさんに男としてダメ出しされる始末。

本家Permlink


2008年05月02日1

いや、やっぱり消そう。何回もおんなじこと書いてるもんな。

--

SBPPに『プロジェクトが良い状態』であるときの特徴が
次のようにあげられています:

* once and only one (一度、ただ一度だけ)

* lots of little pieces (たくさんの小さなカケラ)

* replacing objects (オブジェクトを置き換えられる)

* moving objects (オブジェクトを移せる)

* rate of change (変更頻度)

『プロジェクトが良い状態』というのは、『設計が良い
状態』と言い替えることができます。

once and only onceとlots of little picesについては、
もう説明する必要もありません。

replacing objectsというのは、pluggableということも
できるでしょう。オブジェクトを差し替えることで新しい
機能を実現する。

moving objectsは、再利用ということですね。ある
オブジェクトを別のコンテキストに移しても動くように
する。

rate of changeについてはまたあとで書きます。

で、自分なりに上のを言い替えると:

* lots of little pieces

* once and only once

* low coupling, high cohesion

* rate of change

ということになります。まぁ、大して変わってないん
ですけど。

lots of little piecesがまず最初にやらなきゃいけない
こと。

でも、lots of little piecesでやると、細切れのカケラが
たくさんできちゃう。とりあえず重複するものはなくす。
それがonce and only once。

でも、まだカケラが無秩序に散らばってる状態。で、
関係のないものは切り離して、関係するものはまとめる。
それがlow coupling, high cohesion。

でも、関係するかどうかっていうのは、結構判断しにくい
こともある。だから、その目安としてrate of changeを
使う。頻繁に変更されるところと、そうでないところとを
分ける。

『Code Complete』には、他にも拡張性だとか再利用性だ
とかfan-inだとかfan-outだとかいろいろ書いてあるけど。
そういうのは気にしなくっていい。そういうのは上の
4つの特徴でぜんぶカバーされるから。

--

なんか、once and only onceを軽んじてるような書き方
ですけど、そうじゃないんです。手順として考えたら
こうなるっていうだけで。once and only onceが達成
できたら、それだけで良い設計といえるほどだっていう
のは変わりません。

--

やっぱり、こうやって書くと、設計とコーディングを
切り離すことはできないとわかりますね。lots of little
piecesにしても、once and only onceにしても、rate of
changeにしても、コード上の話なわけで。

必ずしも設計とコーディングがイコールというわけじゃ
ないですけど。でも、設計の一部としてコーディングが
あると。設計っていうのは、結構広い活動だから。

本家Permlink


2008年05月02日

CliCliSokyoの話。いわゆる設計という意味でいえば、
『誰がダイアログを出すべきか?』をちょっと考え
ました。

最初に考えたのは、CChildViewがクリックされたら
ダイアログが出るんだから、CChildViewが出せばいいと。

  +----------+      +------------+
  |CChildView| +--- |CSokyoDialog|
  +----------+      +------------+

で、実際そういうふうにコードを書きだしたんですけど、
ちょっと引っかかりました。『それじゃあViewの仕事が
大きすぎないか?』と疑問に思ったんですね。

で、Viewがクリックされたら、それをCCliCliSokyoAppに
知らせて、そのAppがダイアログを出したほうがいいと
思ったんです:

  +----------+      +---------------+      +------------+
  |CChildView| ---- |CCliCliSokyoApp| +--- |CSokyoDialog|
  +----------+      +---------------+      +------------+

Viewが直接ダイアログを出すより、App経由で出すほうが
手間がかかるんですけど。でも、やっぱり『責任の分配』
ということで見たら、App経由のほうがいいと思ったんです。

あるいは、『距離の計算は誰がやるべきか?』っていう
見方もできます。Viewが直接ダイアログを出すなら、
距離の計算はViewかDialogがやることになります。でも、
それじゃヘンだと自分は思うわけです。そういう『ロジック』
っぽいのは、GUIコンポーネントとは別のところでやりたい。
ロジックっぽいとこっていうのは、アプリの核心なわけで、
だったらやっぱりAppでやるのがいいだろうと。

--

最初は自分で作ろうとは思ってませんでした。Vectorで
探して見つけたのが:

http://www.vector.co.jp/soft/win95/art/se261666.html

結局これは『Google Mapで距離を測る』っていう自分の
目的に合うものじゃなかったんですけど、でも、これで
『半透明』っていう大きなヒントをもらいました。

で、他を探してもほしいのがなかったので自分で作る
ことにしました。もともとgdgdな人間なんで、計画
らしい計画を立てるわけでもなく。ただ、この時点で
どんなものがほしいかは大体わかってました。半透明の
ウィンドウ上で二カ所をクリックして、その間の距離を
出す、というものです。

まず、技術的に難しいと思われる『半透明ウィンドウの
実現方法』について調べました。このときはまだMFCで
やるか、Javaでやるか決めてなくって、Javaのほうは
ダメだということで、MFCに決めました。MFCを選んだ
のは特に理由はありません。というか、これしかWinのは
知らないから。

で、MFCを使って、半透明ウィンドウを実現するための
プロトタイプを作りました。何日もかかる大きな
プロトタイプを作るのはやっちゃダメですけど、こういう
ちょっとした実験のためのプロトタイプはよく作ります。

半透明ウィンドウを実現するやり方がわかったところで、
本番に入ることにしました。まずは半透明ウィンドウを
出すところまで。で、次に、距離をTRACEで出すところ
まで。このとき、Webで『二点間の距離を求める公式』
を調べたり、C/C++には``**''がないんだぁと知ったり (笑)、
sqrtなんて使った覚えねぇwww、とか。で、最後に
ダイアログ。

その間にも『ダイアログ出したくないんだけど、ウィンドウ
全体が半透明になっちゃうからダイアログ出すしかない』
とか、『最初にクリックされたらダイアログ出せば
いいんじゃね?』とか、『スライダーで半透明の濃さを
調節できるようにしたいけど、CSliderCtrlメンドクセー』
とか、いろいろな決定をしてるわけです。

本家Permlink


2008年05月01日

みなさんは、Google Mapとかで距離を測りたいと思った
ことはありませんか?

私はあります。

何回も。

あの左下の定規。動かないことを何度うらんだことか。

でも、もう私は泣きません。

なぜならクリクリソッキョがあるから

CliCliSokyo

クリックしてクリックして距離を測る、だからクリクリ
ソッキョ。

ブラウザの上にこの半透明なアプリをかぶせてクリクリ
すれば、2点間の距離がピクセル単位で求まります。
もう一回クリックすれば、その分が加算されます。

親切にも、左下の定規の距離を覚えておくための
メモ・エディット付き (笑)。

まぁ、割り算しなきゃなんないんだけどな、結局は。

--

Javaでやろうかなぁとも思ったんですけど、どうも
半透明は擬似的にしか実現できないみたいでヤメ。

まぁ、マカーの人にも喜んでもらおうかと思ったんだ
けどねぇ。残念だなぁ。

--

やっぱ、こういうチマチマしたのが好きなんだよなぁ。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails