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

ホーム

2007年04月29日

うわ、ワルーエフ、負けてたのか。

--

ちょっといじりました。とりあえずこれでやり残した
ことはない感じ。

一番の問題は、例のゲームをやる気力がもはやなくなった
こと (笑)。二作目出たらそのときに使えるでしょう。

Swing自体、自分はあんまり馴染がなかったんですけど、
チュートリアルのおかげでサクサク作れたんですよね。
もちろん、APIリファレンスも見るんですけど。でも、
やっぱりチュートリアルのほうが話が早い。

とはいっても、チュートリアルにのってないこともやん
なきゃいけなくなって。それがダイアログの処理。

JOptionPaneの出すダイアログってのはよくできてて、
ESCキーを押すと閉じるんです。で、これとおんなじ
ことを自前のJDialogでもやろうとしたんですけど、
チュートリアルでもリファレンスでも触れられてない。

JOptionPaneのソース調べたりとかなかなか大変なことに
なってきたとき、ActionMap, InputMapというのが怪し
そうだとアタリがついて。んで、これをキーにググって
みたら参考になるコードが見つかりました。

それで書いたのがこのコード:

    private void setCancelAction(JDialog dialog) {
        JRootPane pane = dialog.getRootPane();
        InputMap map = pane.getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW);
        Action action = new SizeCancelAction(dialog);
        map.put(KeyStroke.getKeyStroke("ESCAPE"), Action.NAME);
        pane.getActionMap().put(Action.NAME, action);
    }

ダイアログのRootPaneを引っぱってきて、それにアクション
を引っかけました。これでダイアログがアクティブなときには、
どのコンポーネントにフォーカスが当たっててもEscを拾え
るはずです。InputMapの使い方は、正直よくわかってません。
まぁ、イディオムみたいなもんなんでしょう。

アクションは次のとおり:

class SizeCancelAction extends AbstractAction {
    private JDialog dialog;

    SizeCancelAction(JDialog dialog) {
        super("Cancel");
        this.dialog = dialog;
    }

    @Override
    public void actionPerformed(ActionEvent event) {
        dialog.setVisible(false);
    }
}

このダイアログにはキャンセル・ボタンもあって、そっちは
フツーにActionListenerを使ってるんです。だから、ほんとは
キャンセル処理を1つにまとめたかったんですけど。でも、
Escから飛んでくるActionEventとボタンから飛んでくる
ActionEventとの区別をどうやってつければいいかわかん
なかったんですよね。ActionEventの区別って、フツーは
getActionCommandでやるもんなんですけど、Escから飛んで
くるのはワケワカンナイ文字列で。

本家Permlink


2007年04月28日

なんか、ゲームパッドで操作できないようなインタ
フェースはダメな気がしてきた。前からケータイの
UIを取り入れるべきだっていうのは書いてるけど。

--

M-x nslookup
M-x nslookup-host

M-xしたあとtypoしたら出てきた。なにこれ (笑)

本家Permlink


2007年04月27日


本家Permlink


2007年04月26日

結局、これからのSIerっていうのは、顧客のビジネスや
顧客の組織を変えられるかっていうのが焦点になるんで
しょうね。

システムを売ったら終わりなんていう商売は、すぐに
パッケージ製品に取って替わられちゃいます。

だから、ノウハウを売る。

言い替えれば、システムの作り方を顧客に教えちゃう
ようなもので。それで顧客が賢くなって、SIerを必要と
しなくなっちゃうかもしれないけど。でも、それをやん
なきゃしょうがない。賢くなった顧客がまた新しい仕事を
頼んでくることに賭けるしかない。

はぶさんはそれを一生懸命やろうとしてるんじゃない
ですかね。

--

銀の弾丸みたいなシステムを売ろうとするのはムリが
あるわけで。そんなの作れっこないんだから。ソフト
ウェアで解決できないんだから、人で解決するしかない。
つまり人を変えるということ。

本家Permlink


2007年04月25日

いかに駆動するかってことが大切。人間の自動化といっても
いい。

人間っていうのは面倒くさがり屋なもの。何か力がかから
ないと動こうとはしない。だから人間を駆動する仕掛けを
用意する。

テストを先に書くのもそう。ストーリーっていう細かな
単位を使うのもそう。ゴールをはっきりさせるのもそう。
そうやって人間が動くように仕向ける。

--

http://itpro.nikkeibp.co.jp/article/OPINION/20070423/269190/

前回と同じく、きわめてマットウな意見だと思います。
でも、現実には、請負が儲かんなくって派遣やSESに手を
出してるとこって多いんじゃないかと思うんですよね。
そういうとこは負の連鎖に陥っちゃってますよね。

だから、やっぱりもうSIerには期待できないんじゃないか
と思うんです。期待するなら、いわゆるユーザ企業に
期待するしかない。ユーザ企業自身が、独自のニーズを
満たすための独自のシステムの必要性を感じて、自分の
力でシステムを作る。そうした動きが起こることを期待
するほうが、今のSIerが復活するよりも望みがあるんじゃ
ないかと思うんですよね。

--

agileがいくら拙速を尊ぶといっても、しつっこく考える
ことは大切なんですよね。その境目は、例によって曖昧
なんですけど。でも、限られた時間の中で、抜けがない
ように真剣にしつっこく考える必要はあります。

んで、考えるときに大切なのが、結論を出すこと。考える
だけ考えて、結局結論出さないんじゃ意味ない。保留なら
保留っていう結論でもいいけど、じゃあ、保留じゃなく
するためにどうすればいいかっていうのを次に考えなきゃ
いけない。

--

そういう意味じゃ、BTSみたいなものをBTSとしてしか
使ってないのは駆動できていないってことになる。

なぜって、バグにしても、ストーリーにしても、人を
割り当てて、時間を割かなきゃいけないのは同じなわけで、
っていうことはビジネス上の判断が必要なのはバグも
ストーリーも同じだから。

そこでバグとストーリーを別なものとして扱ってたら、
駆動するエンジンが2つあるってことで、それで効率が
上がるんならいいけど、まぁ、フツーは混乱するだけ。

--

まぁ、当たり前の話だけど、相談するときは誰に相談
するかが大切。

んでもって、自分は誰からも相談されるような存在に
なることが大切。これはすっごくむつかしくって、単に
知識があるだけじゃダメで、人に好かれないといけない。
まぁ、自分はこっちがからっきしダメなわけで (笑)。

本家Permlink


2007年04月24日

どこのファンかと問われれば、強いてあげれば広島。

広島といえば春の椿事なんだけど、こんな椿事でどう
するよ?

小宮山に春の椿事奪われてちゃ世話ない。

--

http://www.asahi.com/komimi/TKY200704190202.html

こないだ取り上げたしね。

ちなみにオレは尾崎は嫌い。

本家Permlink


2007年04月23日

ぷらっと (w
オオカミ少年 (w

つかさー、新興で大損した人、東証とかを訴えたら
勝てるんじゃないの (w
あんまりにもヒドすぎるもん (w
これで東証とかに責任が全然ねぇとかシラ切れるのか (w

--

しっかし、ダイヤモンドもウサンクセーなぁ。
でも、そこが (以下略)

--

問題に出喰わしたときに助けを呼ぶのは恥じることじゃ
ない。まず問題を共有することに意義があるし、それに、
人が集まれば問題を早く解決できる可能性が高くなる。

使えるものは何でも使う。人でも、お金でも、道具でも。
それが全力で事に当たるということであり、Whole Team
にもつながる。

--

当然、モラルは大切だという前提においての話だけど。

本家Permlink


2007年04月22日1

しばらくデスクトップのsidをほっぽらかしにしてたら、
パッケージ・データベースが腐っちゃったみたい?
skk-uimがpurgeできない。なんかエラーが出て止まる。
dpkg-reconfigureでもダメ。

連休にUbuntuに乗り換えっかなぁ。AMD64で動くかどうか
わからんけど。

--

ダイアモンドが特集組むらしいじゃん。

なんか、こないだ自分が書いてから一気に厳しい論調が
目立ってきたように思えるのは気のせいか? (笑)。

しっかし、この業界にいてよく耳にしたとこも結構ダメ
なのな。マメゾーとかウルとか。マメゾーはまだしも、
ウルなんか二次曲線じゃねぇか。

結局、独立系のSIerって儲かんないんじゃないの? (笑)。
だったら株式公開なんかすんなっつの。テクノロジー
テクノロジーゆうたって、自分とこの株価も維持できねぇ
んじゃ意味ねぇって。

--

http://www.boj.or.jp/

うわ、日本銀行て.or.jpだったのか。

本家Permlink


2007年04月22日

世の中には『アザス』派と『アシタ』派がいます。
ちなみに自分は『アザス』。

以前から『ありがとうございます』は長すぎると思って
ました。かといって『ありがとう』では目上の人に使い
にくいです。

その点、関西の『オーキニ』は短かいですし、目上の人
にも使えるので、非常にいい言葉です。

『ありがとうございます』が長いので、そのかわりに
『すみません』という言葉がよく使われます。でも、
『すみません』という言葉は感謝ではなく、謝罪の言葉
です。『すみません』を乱発するのは、非常に日本的な
慣習です。

自分がはじめて『アザス』を知ったのは東スポでした。
『最近のプロ野球選手の言葉遣いはなっとらん!』と
ジャイアンツのOBが嘆いているという話でした。練習の
とき、選手がノックを受けて『アザーッス』と叫ぶのが
気に入らなかったようです。

ただ、このときは『ふーん』程度で流して、実際に
アザスを使おうとは思いませんでした。

次にアザスを見たのはwotaさんのとこでした。誰かから
ツッコミをもらって、それにwotaさんが『アザーーッス』
と書いて返してました。そのとき『これだ!』と思い
ました。それ以来自分はアザス派になりました。

一方で、アシタ派もいるということに気づきました。
インドの人が使っていました。より正確に書くと
『アーシタ』です。

しかし、アザスにしても、アシタにしても、実際には使う
人を選びます。自分はもともと一人称に『自分』を使う
くらいで、体育会系のノリを演出してます。『ッス』派とも
いいます。このッス派はアザス、アシタと相性がいいです。
でも、そういう演出がない人が、いきなりアザス、アシタを
使うのは無理があります。

実際にアザスを使いはじめてみると、非常に使い勝手が
いいということがわかりました。何かもらったらアザス、
何かしてもらったらアザス、何か教えてもらったらアザス。
また、アザスは『すみません』と違って、口に出しても
気分が落ちることはありません。むしろ気分は上がります。
やはり感謝の言葉だからです。

アザスのコツは、『アザス』と言い切ることです。
『ありざす』といったような中途半端な省略形は、逆に
相手に不快感を与えます。また、もともと体育会系の言葉
なので、勢いが大切です。ですから『アザーッス!』の
ように元気よく発声したほうが効果的です。

面白いことに、アザスを相手に投げたときに、アシタで
返されるときがたまにあります。アザスとアシタだけで
会話が成り立っているんですね。

--

『ォァザーッス』っていうのをどうにかしたい (笑)。
『おはようございます』なんだけど。
やっぱり『オザス』か?

--

こないだ読んだ『ドラえも』に出てきたセリフ、
『やってやんよ!』が忘れられません (笑)。

『やってやるよ』の口語体なんですけど、実際に文字で
見るとインパクトがあります。

こういうのはケロロ軍曹に結構あって、『スッゲーヤッベー
カッケー』も一度実際に使ってみたいセリフです。

そういえばこないだ自分も『ゼッテーヤンネー』を使い
ました。『絶対やらない』という意味なんですけど。

本家Permlink


2007年04月20日

いやぁ、すまんす。

何の気なしにdselectしたらetchになっちゃって (笑)。
んで、設定とか吹っ飛んじゃって。でも、dselectやってる
最中は『クソオセー』とか思ってただけで。今日になって
hsbtさんとこ読んだら、『ソース見えちゃってるし (w』
って書いてあって。アチャーって感じで。まぁ、別に
隠すほどのコードでもないんで見えちゃってもいいん
ですけど。

本家Permlink


2007年04月18日

すまん。この雨と寒さじゃムリ。

本家Permlink


2007年04月17日

String replaceAll(String regex, String replacement)

いくらなんでもムリヤリすぎじゃない? フツーにPattern
渡せばいいじゃん? Pattern.compileって書くのが
メンドーなら、正規表現リテラル導入すりゃいいじゃん?
それがスジってもんじゃないの?

つかさー、オレって、"\\Aabc\\z"とかって書くのが
大っ嫌いなのね。ただでさえ読みにくい正規表現なのに、
文字列リテラルで正規表現書くとわけわかんなくなんだ
よね。Elispが嫌いな理由の1つがこれなんだよね。

本家Permlink


2007年04月15日

Javaなんですけど、こういうの:

    void newPopup() {
        JPopupMenu menu = new JPopupMenu();
        Object[][] pairs = {
            {"red", Color.RED},
            {"green", Color.GREEN},
            {"blue", Color.BLUE}
        };
        for (Object[] pair : pairs) {
            JMenuItem item = new JMenuItem((String) pair[0]);
            item.setForeground((Color) pair[1]);
            item.addActionListener(this);
            menu.add(item);
        }
    }

って、どうにかなんないんですかね。レキシカルに型が
わかるはずなのにダウンキャストしなきゃなんないって
いうのがイヤ。

かといって:

    void newPopup() {
        JPopupMenu menu = new JPopupMenu();
        String[] names = {"red", "green", "blue"};
        Color[] colors = {Color.RED, Color.GREEN, Color.BLUE};
        assert(names.length == colors.length);
        for (int i = 0; i < names.length; ++i) {
            JMenuItem item = new JMenuItem(names[i]);
            item.setForeground(colors[i]);
            item.addActionListener(this);
            menu.add(item);
        }
    }

だとダウンキャストはいらなくなるけど、すっげーダッセー。

--

kitajさんはどういうかわかりませんけど (笑)、Javaの
GUIプログラミングは、けっこー『オレってばすげー』感が
味わえると思うんですよね。『そんなこといったらVB
だってそうじゃねぇか』っていわれそうですけど。でも、
大がかりなIDEもいらないし、それでいて『お行儀いい』
感じっていうか、OOPっぽいっていうか。それに、あん
まし『操られてる』感もないですし。

結局、大がかりな仕掛けよりも、適度な大きさの材料が
そろってるほうがうれしいんですよね。でもって、材料も
できるだけプレーンなほうがいい。材料を使うたんびに
継承しなきゃいけないとか、そういうのはうれしくない。

で、いい材料がそろってて、『どういうふうに料理するか』
っていうのが『腕の見せどころ』っていうか。そこでサク
サク料理できると『オレってばすげー』感が味わえるって
いうか。

材料から作るのはメンドーですし、かといってレトルト
みたいにチンして出来上がりだと腕のふるいようがないし、
やっぱりいい材料がそろってるかどうかなんですよね。

本家Permlink


2007年04月14日

http://finance.yahoo.com/q/bc?s=AMZN&t=my
http://finance.yahoo.com/q/bc?s=YHOO&t=my
http://finance.yahoo.com/q/bc?s=GOOG&t=5y
http://finance.yahoo.com/q/bc?s=EBAY&t=my

これらはどれも米国の超優良ベンチャーで、それと比較
するのはちょっとかわいそうな気もするけど、それに
しても日本のベンチャーは、簡単に公募価格を割りすぎ
るよな。

http://quote.yahoo.co.jp/q?s=4751.t&d=c&k=c3&a=v&p=m130,m260,s&t=ay&l=off&z=m&q=c&h=on
http://quote.yahoo.co.jp/q?s=4755.q&d=c&k=c3&a=v&p=m130,m260,s&t=ay&l=off&z=m&q=c&h=on

たとえば、この2つなんかも、公募価格を下回ってる
時期が3〜4年もあった。ご存知のとおり、ライブドアは
上場廃止だ。そりゃ上場基準や査定が甘いといわれても
しょうがねぇよな。

新興市場のくせに3〜4年も猶予を与えるっつーのはどう
なのよ? アベソーリ?

--

つかさー、VCのヤツらのブログとか読むとヘドが出るな。
馴れ合ってて。

ベンチャーなんつうもんは10のうち1成功すればいいほう
なんだろ? だったら、ダメなのはバンバン切らなきゃ
ダメじゃねぇか。だのに、なんかヨイショし合ってよ。
バカか? つか、投資家をダマくらかすことしか考えて
ねぇんだろ? え?

本家Permlink


2007年04月13日

http://www.vitanuova.com/inferno/downloads.html

Infernoって、いつからオープン・ソースになったん?

本家Permlink


2007年04月12日

岡さん、鈴木監督がバッシングされてます・・・

--

オブジェクトは生まれたときから完全なほうがいい。
だから、newしてすぐ何かをセットするようなコードは
イヤな臭いがする。

ただ、例外があって、典型的には、コンストラクタで
エラーが起きる場合。コンストラクタは、フツー、
エラー・コードを返せないから、そういうときは二段階で
オブジェクトを作ることもある。でも、そういう場合は
例外を使うことも考えられるし、あるいはC++のfstream
みたく、エラー・チェックのメソッドを用意することも
考えられる:

    ifstream in(filename);
    if (!in)
        abort();
    string line;
    while (getline(in, line)) {
        cout << line << endl;
    }

--

でもさぁ、だったら、newの返り値チェックしてる?
でなきゃnewを多重定義してる?

もししてないんだったら、メモリ管理としては片手落ち
だよね。

本家Permlink


2007年04月11日1

確かに、組織というのは、絶対といっていいほど変わら
ないものです。でも、だからといって、それを自分が
変わらない理由にしちゃいけないですよね。

10人の組織だとして、その中の『自分』が変われば、
組織の1/10が変わるわけです。もっと組織が大きくっても、
自分が変わることによって、何分の1かは変わります。

--

確かに、優秀な人っていうのは、ほっといても自分で
道を見つけるものです。でも、道は実際にはたくさん
あって、間違った方に進む道を選んじゃうことだって
ありますよね。だから、そんなときは『間違った方向に
進んでないかい?』と声をかけなきゃいけない。

--

http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A8%E3%82%BF%E7%94%9F%E7%94%A3%E6%96%B9%E5%BC%8F

『トヨタ生産方式』からたどれる:

http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%89%E3%83%B3

アンドン。これを読むと、アンドンっていうのは、自動化
とはちょっと違うんですよね。ヒモを引っぱるのは人間が
やるんですから。だから、ユニット・テストが赤くなる
という現象とは違います。

ユニット・テストが赤くなるっていうのは、いってみれば、
まだ黄色。本当に赤いランプがつくのは、誰かが声を
あげたときなんですね。トヨタがアンドンを使ってるのは、
そこが工場で声が通りにくいし、ラインという長大な
仕掛けを止めないといけないから。

結局のところ、アンドンをメタファとするならば、異常を
察知したら声をあげて、チーム全体で問題を解決する、
他の作業を中断してでもその問題を解決するということに
なるんでしょうね。

--

というわけでメモ。マージに3日もかかるのは異常。
マージに3日かかるということは、そのためにメンバが
3日間コードをコミットできないということ。それは
すなわち、チームの3日分の価値、働いた成果が野晒しに
なっているということ。

いってみれば、バージョン管理システムこそ我々の
『ライン』。ラインを止めちゃいけない。

--

クラスっていうのはテンポラリなものだから。SRAの青木
さん風にいえば『はかない存在』。

クラスというのは、その時々の状況によって生まれたり、
消えたりする。必要だから生まれて、必要なくなったら
消えていく。

プロジェクトの最初っから終わりまで長生きするクラスも
あるけど、そうでないものもあるっていうこと。

でも、消えるといっても、こつ然と消えるだけじゃなく
って、名前を変えたり、他のクラスに吸収されたりと
いった具合に、『魂』は残ることもある。魂っていうのは
コード片のこと。

--

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

確か獲物でも取り上げましたけど、このEmergentDesignと
いうのが最近心に引っかかるんです。

本家Permlink


2007年04月11日

http://pckeyboards.stores.yahoo.net/onthestick.html

正直ビミョーというか。ググっても反応が薄い。

本家Permlink


2007年04月10日

結局のところ、ストーリーというのは、ゴールがはっきり
していないと意味がない。

ストーリーを切り出したといっても、それが実際には
漠然としたゴールしか持っていなかったということは
ザラにある。そうしたストーリーは、当初の見積もり
よりももっと時間がかかったりする。そうしたときには、
よりはっきりとしたゴールを持つ、さらに小さなストー
リーに切り分ける。

ストーリーをさらに細かく分けるということは、計画を
立て直すということに外ならない。そして、計画を立て
直せるというのが、反復計画の最大の利点。前払い計画に
対する都度払い計画。

ストーリーのはっきりとしたゴールとは、もちろん、
受け入れテスト (顧客テスト)。だから、早い段階で受け
入れテストを固める。

--

ゴールがはっきりしていたほうがいいのは、何も
ストーリーに限ったわけではなく、ストーリーを実現する
ための個々の作業についても同じ (self-similarity)。

作業のはっきりとしたゴールとは、もちろん、ユニット・
テスト。だから、早い段階でユニット・テストを固める。
あるいは、ユニット・テストを先に書く (テスト・
ファースト)。

--

逆方向に話を広げれば、プロジェクトのゴールという
ものがある。これはMicrosoftの言葉ではビジョンと
いわれる。

作業 (タスク)、ストーリー、ビジョンと粒度が大きく
なるにしたがって、ゴールの具体性は薄まる。けれども、
ビジョンにしても、ビジョンの範囲でできるだけはっきり
としたものでないといけない。

--

ゴールをはっきりさせるということは、ゴールを共有
するということにもなる。

受け入れテストであれば、ストーリーのゴールを顧客と
プログラマの間で共有する。ビジョンであれば、チームの
メンバ間でプロジェクトのゴールを共有する。ユニット・
テストであれば、ペアでプロジェクトのゴールを共有する。

--

XPでは、個々の実践や原則も大切なんだけど、上のように、
それらの実践や原則がどのように関連づいてるかを考える
のも大切。

本家Permlink


2007年04月07日


本家Permlink


2007年04月06日

http://www.takaratomy.co.jp/products/babyonline/feature/0611kerotto/

あのヅラ疑惑で有名な所長の研究所って、マトモな
仕事やってたのか (笑)。

本家Permlink


2007年04月05日1

http://blog-tech.rikunabi-next.yahoo.co.jp/blog/qromaq/48

ちょっと古いけど、思い出して読み返してみたら身に
染みた (笑)。

やっぱさ、信頼されてないうちはアレコレやってもダメ
なのね。まぁ、もちろん、業務をキチンとこなすって
いうのが大前提で、それをやっとかないと信頼される
わけもないんだけど (笑)。

--

書きすぎた (笑)。

本家Permlink


2007年04月05日

でも、人の組織に2:8の法則を当てはめるのは、ちょっと
単純すぎるよな、やっぱり。

--

大企業とはいえ民間の企業と、公務員とを一緒に語っちゃ
ダメだろう。就職するほうがどこまで深く考えてるか
わかんないけど。

本家Permlink


2007年04月04日

そんなに目くじら立てるほどの記事とも思えないけど。
いきなり肩書で人を判断するのは良くない (笑)。

ただ、「agileと前払いとを融合せよ」っていうのは、
確かに世間ウケするだろうけど、自分にはタワゴトの
類。

もし今カオスの状態、つまりagileも前払いもやってない
状態にいるとしたら、二兎追うものは一兎も得ず。

で、もし今前払いやってんなら、そんなものは捨てて、
ドップリagileに漬かるべき。とはいっても、そこには
規律がすでにあるんだから、上手くagileに移行できる
可能性が高い。

agileは、そのままagileでいればいい。agileは常に
前進することを意味するんだから。

本家Permlink


2007年04月03日

あれはちょっと誤解を生む書き方でしたかね。

顧客のいうままに品質を後回しにしろっていうわけじゃ
ないんです。そうじゃなくって、縦の方向に機能をそろえ
ていけばいいんじゃないかっていうこと。機能を横並びに
ドンといっぺんにそろえるんじゃなくって、価値の高い
機能、お客さんの一番ほしい機能から先に提供してあげ
ればいいんじゃないかっていうこと。

多分、お客さんのほうも、あれこれbig pictureを描いて
ると思うんですよね。で、これまでは、それを全部叶えて
あげるのが『品質』だったんですけど、それはできないと。
予算も時間も限られてるんだし。だったら、やり方を
変えるしかないでしょう。

--

でもさぁ、『これこれこういうメンバで開発します』って、
それって原価教えてるようなもんだよな。ソフトウェア
開発なんて、人件費だけっていっていいんだから。

原価教えるって、フツー商売じゃやらんわな。

--

いや、止そう。グチになる。

本家Permlink


2007年04月02日1

あー、ヒキコモ宣言されちゃったよ。
まぁ、いいか。バカはあきらめが悪いのさ。

--

別の見方をすれば、それだけITを必要とする裾野が広がっ
たのかもしれない。これまではITに大金を出せるとこしか
なかったんだけど、小金くらいは出せるくらいのとこまで
IT化の必要に迫られていると。

まぁ、考えてみりゃ、IT化っていうのは規模じゃない。
というか、ITというのは、本来、ダビデの石であって、
ゴリアテの槍じゃない。

本家Permlink


2007年04月02日

つか、1日に何回コミットすると思ってんの?
1度や2度じゃないんだぜ?
それでバックアップだけでバージョン管理すんの?
キチガイすぎるだろ、それ。

--

前にも書いたけど、いーじゃん。実際、似てるんだし、
顔も。

違うのは唇の厚さくらいなもんだし。

「実は同一人物かも」くらいのほうが幻想がふくらむ
じゃん?

--

http://itpro.nikkeibp.co.jp/article/Watcher/20070323/266142/

ん〜、これ、お客さんは別に悪くないんじゃないですかね。

品質より納期とコストを優先してくれっていってるんだ
から、そうやるしかないでしょ。スキル云々は開発者側の
ワガママでしかないでしょ。

だから、pay-per-useなわけでしょ? あるいは、ここにも
書いてあるように、できるだけ上流から食い込むしかない。
それもまたpay-per-useという答えになる。お客さんの
ビジネスの成功と開発側の成功を同期させる。もちろん、
IT化っていうのは利益が見えにくい 場合もあるから
むずかしいけど。

これも前から書いてるけど、SIerの将来は決して明るく
ないわけで。それがいよいよ現実化してきただけっていう
見方もできるわけ。イヤダイヤダなんていってたら、
お客さん自身がプログラマを雇えばいいわけで。派遣
やってるヤツなんてゴロゴロいるんだから。

まぁ、資格が人月商売の材料にしかならないっていうことを
裏付ける記事ではある。

本家Permlink


2007年04月01日

BUBKAでさ、越中のインタビューが載ってんのよ。
これがまたいい味出してるんだわぁ。

--

囲碁や将棋といった非常に単純なルールでありながら、
その変化は無限とも感じられるゲームがある。つまり、
ある人物があるときにプレイしたゲームはユニークな
ものになる。プレーヤーが再現しようとしない限りは。

にもかかわらず、どうしたわけか、プログラムは、問題が
同じならば、誰が書いても同じコードが書かれると思われ
ているフシがある。

確かに、問題が小さければ、その解法に本質的と呼べる
ような差異はない。というか、『差異があるべきではない』
という態度は正しい。ソートはクイック・ソートが速いし、
その実装の仕方に本質的な差異は生まれないだろう。でも、
現実の問題は、もっと大きくて複雑であることがほとんどだ。
それに、問題も次から次へと新しいのがやって来る。

同じ問題が与えられたとしても、私とあなたとではまるっ
きり違う解法が得られたとしても不思議ではないし、1年
前の自分と今の自分とですら、同じ解法が得られるとも
限らない。

そういう意味でいえば、やはり『問題を解決できるか』
という点が一番重要であって、設計がどうたらとかは二の
次というか、『個性の揺れ』程度の問題に過ぎない。

ただ、集団で作業する場合、あまりにも個性に違いが
ありすぎると協調しにくいということもあり、ある程度
意識をそろえることはある。でも、それですら、その
集団の個性ともいうべきものを生むだけに過ぎない。

それでもなお私が日々ユニットテストを書いたり、リ
ファクタリングを繰り返すのは、問題に対する自分の
理解を深めるためだ。私がオブジェクトを使うのも、
それが自分にとって理解するための助けとなるからだ。

ユニットテストにしても、リファクタリングにしても、
オブジェクトにしても、それが『正しいから』という
理由でやるわけではない。それが正しいかどうかなんて、
誰にもわからない。実際、ユニットテストにしても、
リファクタリングにしても、オブジェクトにしても、
『正しくない』といわれていた時期があったわけだし。

『ユニットテストなんて書くヒマあるの?』とか、
『動いているコードをいじるなんてとんでもない』とか、
『オブジェクト指向なんて現実的じゃない』とか、
そういったように、安易な『正しさ』というのは信用
できるものではない。

結局、銀の弾丸、つまり、囲碁や将棋における『終局
までの最善手順』みたいなものは、プログラミングには
ないということだ。自分に合ったやり方で問題を解く
しかない。自分が納得できるやり方で問題を解くしか
ない。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails