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

6,000人の話の続き。もうリンクとか忘れちゃったから
張らないけど、あの記事の中で『何の根拠もないが、
このプロジェクトは成功すると思ってる』って書いて
あって。まぁ、それは別にいいんだけど、『願い』を
そういうふうに表現しただけだから。でも、その
あとに『成功させて、日本の力を見せつけてほしい』
みたいなことが書いてあったんだよね。

いかにもニッケー的っていうか、前世紀的な発想だよね。

大規模自慢はもう自慢になんねぇだろ。

規模が話題になるとしたら、大量のサーバであるとか、
大量の外部記憶容量であるとか、そういう、いわゆる
スケーラビリティのほうに世間の感心は移ってるだろ。

だから、6,000人のプロジェクトで成功したからって
いって、日本の技術力のアピールにはなんねぇだろ。

実際、6,000人のプロジェクトって、もう技術云々の
世界じゃないんだから。

これも『ものづくりの呪縛』なのかねぇ。重厚長大な
ものって、ソフトウェアとは相容れないもんだと思うん
だけどなぁ。ピラミッド作ってるんじゃないんだぜ?

大体、成功と失敗の定義って何なのよ?っていうのも
あんじゃん? 期日どおりにサービスインしたら成功
なの? そんなバカな話はねぇだろって。

システムっていうのは、使われてナンボなわけでしょ。
動きはじめること自体には何の価値もない。だから、
システムの価値っていうのは、もうちょっと長い目で
見ないとダメじゃん?

システムの効果をハッキリとした数字で表すことは
むずかしいとしても。でも基幹系なんだろ? だったら、
その銀行の利益なり、株価なりに直接的に影響しなきゃ
ウソだろ?

『システムは成功しましたけど、株価は落ちました』って、
それは成功とはいわないんだよ。ソフトウェア開発と
ビジネスを切り離して考えんのはもう止めよう、な?

本家Permlink


2008年04月28日1

例の6,000人のプロジェクトの話。「みんな失敗を期待
してる」なんていわれてるから書くの止めようかと
思ったんだけど。

まぁ、フツーに考えたら失敗するよね。それはどっちの
システムが優れているとか関係なく。詳しいことは
知らないんで、的外れなことを書くかもしんないけど。

だって、いきなり6,000人集めて1つのシステム作り上げる
って、フツーに考えたら失敗するでしょ。ソフトウェア
開発で一番大切なのはコミュニケーションだって、もう
みんな知ってるわけだし。6,000人がいっぺんに意思疎通
できるわけがない。

それと、6,000人も優秀な人が集められるの?っていう
のもあるし。2:8の法則だとしても、1200人優秀な人を
集めなきゃいけないわけでしょう。自分の周りを
見回しても、過去の経験からしても、そんなに優秀な
人の割合は高くない。

別に失敗を願ってるわけじゃないんだよね。でも、
これが成功したからって、どうってことないんだよね。
単なる奇蹟だから。これが成功したって、別の6,000人の
プロジェクトが上手くいくとは思えないしね。こういう
プロジェクトXみたいな話は参考にならないって何回も
書いてるけど。

本家Permlink


2008年04月28日

  企業がソフトウェア開発をコモディティ化しようとしたのは、これが初めて
  のことではない。1980年代の日本の企業は、プログラムを製造するソフトウェ
  ア工場を造ろうと試みて失敗した。彼らはたくさんのプログラマを投入する
  だけでは、革新的なソフトウェアは作れないと知ることになった。

  (『プログラマのアウトソーシングの落とし穴』(M.Bean, 『Best Software
  Writing』より)

ほんとうに私たちは『知ることになった』んでしょうか。とてもそうは思えま
せん。1990年代以降、日本が革新的なソフトウェアを作るようになったとは聞
いたことがありません。それどころか、日本もアウトソーシングに熱心なソフ
トウェア開発企業で溢れているようです。

本家Permlink


2008年04月27日

つーか、任天堂のせいにしてる時点で終わってんだよな。

大体、こないだ『本屋なんかつぶれちまえ!』って書いて、
したら会長から『いや、本屋さんだってがんばってるん
だよ』ってお叱りをいただいて。だから、自分的には
終わった話なんだよな。それを今さらっていう感じ?

大体、本っていうのは知識の塊であって、それを扱ってる
本屋がバカでどうするよ?って話じゃないの?

本家Permlink


2008年04月26日

この職業、スランプというのを感じることはあんまり
ないんですけど。でも、それでも、『オレはこのままで
いいんだろうか・・・』みたいなことを思ったりする
ことってあるわけです。そういう思いは、大抵はすぐ
消えるんですけど、でも、ときには長引くことも
あります。長引くようなら、それは一種のスランプと
いえるんじゃないでしょうか。

ドラゴンズの落合監督は:

  スランプになったら、まずは食事と睡眠を練習と同じ
  レベルで考え、体力を戻していくことから取り組む
  べきなのだ。(『落合博満の超野球学 1』)

といってます。睡眠と食事を『人間としての生活の基本』
といっています。これはスポーツ選手に限ったことでは
ないんじゃないでしょうか。プログラマだから眠らずに
いいとか、プログラマだから食事を抜いていいとか、
そういうことは絶対にないはずです。

まぁ、上の文章の他にも、技術的なスランプを抜け出す
方法も書いてあるんですけどね。そっちは打撃フォームの
話で、『崩れた打撃フォームをどうやって元に戻すか』
みたいな話で、ちょっと応用するのがむずかしい。

--

しかし、37才のオッサンCOBOLerで『将来が不安です』って、
オメデテーな。

それで、それへの回答が『瞑想法』だっていうんだから、
どっちも救いようのないバカだな、こりゃ。

こっちは40過ぎてて、国民の平均年収下回る負け組
プログラマー (しかも独身) なんだから、テメーなんか
よかよっぽど将来が不安だよ (笑)。

プログラマがプログラマを辞めなきゃいけないときってのは、
プログラムを書けなくなったときか、書くべきプログラムが
なくなったときだろう。

プログラムが書けなくなるってのは、まぁ、あんまり
考えたくない状況だし、考えたってしょうがない。

じゃあ、書くべきプログラムがなくなるのは? まぁ、
職業プログラマだったら、フツーは誰かが書くべき
プログラムを見つけてくれる。でも、それが期待
できなかったら? 自分で見つけるしかない。当たり前だ。

システム管理者を兼任してるってことだけど、じゃあ、
そのシステムっていうのは、もう手を入れる必要のない
ほど枯れてんのか? 不満を持ってるユーザは一人もいない
のか?

じゃあ、新しいシステム提案しろよ。あるいは既存の
システムで孤立してるのを連携させるとか。データベースが
あるんなら、データを可視化するとか。Wikiもあるだろう。

身近なことなら、自分の作業の中にも機械化できるものは
ないのか? プログラムっていうのは、とどのつまり、
繰り返される作業の機械化だ。

こういうのは、別にJavaとかRubyじゃなきゃできない
ことじゃないんだよ。COBOLとVBでも十分できるだろ。
カネがないんだったら、COBOLerにはちょっときついかも
しんないけどLAMPとかな。

結局、観察が足んないんだよ。自分だって、直接的な
仕事以外のネタは、結構必死で探してんだよ。

本家Permlink


2008年04月24日

http://www.amazon.co.jp/%E7%8F%A0%E7%8E%89%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E2%80%95%E6%9C%AC%E8%B3%AA%E3%82%92%E8%A6%8B%E6%8A%9C%E3%81%84%E3%81%9F%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0%E3%81%A8%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0-%E3%82%B8%E3%83%A7%E3%83%B3-%E3%83%99%E3%83%B3%E3%83%88%E3%83%AA%E3%83%BC/dp/4894712369/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1209043719&sr=8-1

『珠玉のプログラミング』(J.L.Bentley, ピアソン)

ああそうか。昨日紹介した『プログラム設計の着想』は、
今はタイトルを変えてピアソンから出てるのか。
ピアソンのは第二版ということらしい。

本家Permlink


2008年04月23日1

http://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E8%A8%AD%E8%A8%88%E3%81%AE%E7%9D%80%E6%83%B3-J-L-%E3%83%99%E3%83%B3%E3%83%88%E3%83%AA%E3%83%BC/dp/4764901587/ref=sr_1_1?ie=UTF8&s=books&qid=1208950151&sr=8-1

『プログラム設計の着想』(J.L.Bentley、近代科学社)

いや、やっぱ、開発全体の基本の話はともかく、最適化
だとか、デバッグだとかは、自分のような人間が書いちゃ
いけないんだよな。こういう本とか、Kernighan氏の本とか、
素晴らしい古典があるんだから、それを読んだほうが
よっぽどいいんだから。

それにしても、これ読むと、ほんっとに自分はエセエンジニア
だと思うね。『封筒裏の計算』とか、全然ダメなんだよねぇ。

こういう古典は、今からすると、いささか性能に話が
偏ってる気がするけど。でも、やっぱり、こういうのは
一種の『たしなみ』だと思うんだよね。プログラマとしての
たしなみ。知らなきゃ仕事できないってわけじゃないんだ
けど。でも、入門書とか解説書ばっかりだったら味気
ないでしょ。プログラミングって、もっと楽しいもの
なんだから。

本家Permlink


2008年04月23日

http://ja.wikipedia.org/wiki/%E4%B8%89%E6%B4%8B%E8%A8%BC%E5%88%B8

へー、山一證券が潰れたのって、結局は大蔵省の失敗が
きっかけだったのか。

本家Permlink


2008年04月22日1


本家Permlink


2008年04月22日

なにいってんだかなぁ。レガシー作った人だって、それ
なりに先を見通して作ったつもりだっただろうに。それを
まるで昔の人はバカだったみたいな言い方はどうかと
思うよ、ほんとに。

都市計画を例にあげてるけど、都市計画っていうのは
むずかしいんだよ。たとえば、多摩ニュータウンとかな。
下のリンクは「スプロール現象」の話だけど:

http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%97%E3%83%AD%E3%83%BC%E3%83%AB%E7%8F%BE%E8%B1%A1

それとおんなじくらい、長く使われるシステムを作るの
だってむずかしいんだよ。ただそれだけだろう。都市
計画とか関係ない。

--

トーマツがベンチャーだなんて初耳だな。

--

設計とコーディングを不可分なものとする考え方は
そんなに珍しいものではありません。もっとも有名な
ドキュメントは:

http://www.developerdotstar.com/mag/articles/reeves_design_main.html

にある``What Is Software Design?''です。日本語訳は:

http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

あるいは、たとえば「Linuxカーネルコーディング規約」の
中にも、そういう考えが見受けられます:

http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/CodingStyle.html

  さて、人によっては「8文字単位にインデントをすると、プログラムが右に
  行き過ぎて、80文字の画面では読みにくくなってしまう」と主張するでしょ
  う。こういう人達には、「3段階より多くのインデントをするような場合は、
  プログラムそのものが良くないのだから、そこを修正しなさい」と言いましょ
  う。

「8文字単位のインデント」と「80文字の画面」というのは、
コーディング上のルールです。でも、「プログラムそのものが
良くない」というのは、つまりは「設計が悪い」という
ことです。どれほど事前に図などを描いていても、コードを
書いたときに上のルールを守れないようでは、いい設計とは
いえないといってるわけですね。これは、コーディングと
設計は不可分だといってるも同然です。

--

ちなみに、「80文字の画面」はともかく、「8文字単位の
インデント」は今では一般的ではないでしょうね。4文字
単位のところが多いでしょう。というのは、APIや
フレームワークで長い名前が使われてることが多いから
です。

本家Permlink


2008年04月21日

あ、size_typeとunsignedは別の話です。

どういうわけかunsignedを使いたがる人間が多くてウザイと思ってるだけ。

size_typeはある意味しょうがないっちゃしょうがない。それがC++のやり方だ
し。

本家Permlink


2008年04月20日1

ああ、そうか。forkしても関数のアドレスは変わんない
のか。関数のコードはテキスト・セグメントに置かれて
るんだし、forkはメモリを丸ごとコピーするわけだから。

--

コードを書かずに済ますことを真剣に考える、それはもう
コンサルの仕事の範疇では (笑)。

いや、もっともな話だと思いますけど。

結局ソフトウェアを作るってことはサービスを作るって
ことでしょうし、それは結局新しいビジネス・モデルを
提供するってことでしょうし、そうするとやっぱり
コンサルみたいなこともやんなきゃいけないって話に
なるでしょうし。

やっぱりソフトウェア開発とコンサルとであんまり厳密に
線を引いても意味がないっていうか、そこで線を引いちゃうと
こっちが儲けらんなくなるんじゃないですかね (笑)。

--

『王銘エンの囲碁ミステリーツアー』(王銘エン、毎日コミュニケーションズ)

  メイ探偵「そうだった。君、二人は一人かもしれないぞ。つまり、『感覚』
  と『読み』がだ。今まで二人を別人だと思って追いかけてきたが、二人は、
  もしかしたら同じ人物なんじゃないか!? 一人だということだ!!」

一連の記事では、できるだけ特定の開発スタイルに偏らないことを書いたつも
りです。偏ってしまえば、それは基本とは呼べませんから。でも、偏らないと
いうことは、深入りしないということでもあります。あんまりそういう話は面
白くありませんし、自分が書けるようなこともありませんし。本来なら、基本
の話は、もっとエライセンセー方が書くべきことで、自分のような人間はヨタ
を書くのが精一杯です。

で、冒頭にあげた文章。例によって王銘エンさんの本です。囲碁というのは手
を読むわけです。でも、すべての手を読めるわけじゃないですから、ある程度
範囲を絞って読むわけです。それで、『どこを読めばいいか』を決めるのが
『感覚』というわけです。逆に、終盤のように、数字のハッキリ出せるときに
は、感覚の出番はありません。

このまえ、設計することとコーディングとの距離感の話を書きましたけど。
『基本編』ということなら、2つを分けて考えるのもアリなんですけどね。で
も、開発スタイルにもよるんですけど、実際に仕事してると、両者の境界って
いうのは、やっぱり曖昧なんですよね。

トップダウンからでないと、どこをコーディングすればいいか決められません。
だから、コーディングする前に設計します。でも、すでに書かれたコードから
もっといい設計が思い浮かぶこともあります。リファクタリングはほとんどこ
れです。だから、実際にプログラミングしてると、トップダウンとボトムアッ
プが混ざり合って作っていくことになります。

それと、システムを常に完成形にしておいて、徐々に発展させるという進化的
設計の場合、新しい機能を加えるために古いコードを設計し直す必要がどうし
ても出てきます。そのとき、古いコードをまるっきり無視することはできませ
んから、ここでもトップダウンとボトムアップが混ざり合うことになります。

前にもちょっと書きましたけど、計画とのからみもあります。結局、『設計す
る』っていうのは、『次に何をやるか』を決めるものなんじゃないかっていう。
大きい機能を小さい機能にバラして、それらを (机の上で) つないでっていう
のが一般的に設計っていわれる活動なんですど。でも、それだけでは『次に何
をやるか』は決められませんよね。まぁ、バラす過程である程度見えてるんで
すけど。でも、よく書くように、深さ優先か、幅優先かみたいな選択の幅はあ
りますし。やっぱりバラしただけでは『次に何をやるか』は決められません。
でも、大抵の本では、バラした後は手順が自ずと決まってるかのように話をスッ
飛ばしてます。そんなわきゃないと思うんですけどね。

本家Permlink


2008年04月20日

C++の話。どうもインスタンスを自動変数にするのを
恐がる人が多いんだよね。なぜかnewする。なんで?

newする理由って考えたことないのかな。newする一番の
理由は、インスタンスにアイデンティティを与えたいから。

2つのポインタ変数があって、そのどちらもが同じ
オブジェクトを指してるかどうかが重要な場合がある。
そんなときにnewを使う。これが基本的な考え方。

ところが、規模が大きくなってくると、メンバ変数に
インスタンスの実態を持たせたくないことも出てくる。
ヘッダをできるだけincludeしたくないから。つまり:

// Foo.h
#include "Bar.h"

class Foo {
private:
    Bar bar;
    ...
};

のように、Barのインスタンスを実態としてメンバ変数に
抱えるためには、Bar.hをincludeしなきゃいけない。

でも:

// Foo.h
class Bar;

class Foo {
private:
    Bar* bar;
    ...
};

のように、ポインタを抱えるようにすれば、Bar.hを
includeする必要はなくなる。でも、そのかわり:

// Foo.cpp
#include "Bar.h"

Foo::Foo() : bar(0) { bar = new Bar(); }

のように、newするコードを書かなきゃいけなくなる。
こう書くことで、Foo.hをincludeしたファイルが
Bar.hの変更の影響を受けなくする。これがnewする
第二の理由。

あと思い浮かぶのは多態を利用したい場合:

vector<Base*> objects;
objects.push_back(new DerivedX());
objects.push_back(new DerivedY());

といった感じ?

だから、たとえば:

void doit()
{
    Foo* foo = new Foo();
    ...
    delete foo;
}

のように、ある関数の中で閉じた寿命しか持たないような
インスタンスなら、newしなきゃなんない理由はない。
素直に:

void doit()
{
    Foo foo;
    ...
}

と書けばいい。

スタックという限られた領域にインスタンスという、
比較的大きなオブジェクトを置くことに抵抗があるん
だろうか。でも、今どき、よっぽどバカでかい
インスタンスでもない限り、インスタンスを自動変数に
したくらいでstack overflowなんて起きないでしょう。
そんなこと心配するくらいなら、newしてdelete忘れる
ことのほうがよっぽど心配。

--

#include使うなっていうのはもっともなんだけど。
でも、ほんとにいいたいのは『ヘッダで無闇に定数を
定義するな』ってことでしょ。

まず、前提として、1つのクラスにつき、1つの.hと
1つの.cppが用意されるものとして。このとき、その
.cppの中でしか使われないものは、できるだけ.hに
書かないこと。もし、どうしても.hに書かなきゃ
いけないんなら、それはクラス宣言 (あるいは名前
空間) の中に入れる。

クラス宣言の中に入れるには#defineじゃダメ。だから、
#defineは使うなということになる。

.cppの中だけで使うんなら、#defineもconstも大して
違いはない、極端にいえば。.cppをincludeするバカは
いないから。

定数だからっていって何でもヘッダに入れるのは、
C上がりの人に多い。でもって、それが間違いだとは
気づいてないどころか、正しいと思ってる。

--

そういえば、上でvector使ったけど、たとえば:

for (std::vector<std::string>::size_type i = 0; i < strings.size(); ++i)
    ...

って、どんだけタイプさせんねんって話なんだよね。
まぁ、Late C++の人はfor_eachとかバリバリ使うから
気になんないんだろうけど。

自分はもう:

for (size_t i = 0; i < strings.size(); ++i)
    ...

って書くことに決めたから。gdgdでケッコーケダラケだよ。

--

つーか、なんでみんなunsigned使いたがるかよくわかんねえんだよな、ったく。

世の中、intで回っとるんじゃ、ボケッ!

本家Permlink


2008年04月15日1

『プログラミング』という活動を『設計する』と
『コーディング』という2つに分けました。(デバッグに
ついてはこないだ書いたから割愛。)

『コーディング』がコードを書くことなら、『設計する』
というのは、『コードを書かずに考えること』と捉える
ことができるんじゃないでしょうか。

あるいは、コードとある程度距離を置いて考えることと
いってもいい。その距離というのは場合によって様々です。

関数の名前を考えるといった場合は、コードと近いところに
います。クラス間の関係を考えるといった場合は、コード
から少し離れたところにいます。RDBを選定するといった
場合は、さらにコードから離れたところにいます。でも、
どれも『設計する』というくくりに入れられる活動に
なるでしょう。

古典的なやり方だと、『設計する』と『コーディング』を
厳密に分けます。でもって、『設計する』も『概要設計』と
『詳細設計』に分けたりします。でも、自分はそっち
方面には疎いので書けません。

一方、agile、というか自分が知ってるのはXP (と自分の
経験したプロジェクト) なんですけど、そこでの『設計
する』というのは、コードに近いところでやるものです。
関数やクラスといったもので考える『距離感』ですね。
なぜそれでプロジェクトが回るかというと、話すと長く
なるから簡単にいうと、『計画から納品までを短い期間で
繰り返すことで、少しずつシステムを成長させるから』
ということにしておきます。

--

いや、あの本、そんなに悪かったかなぁ。いや、今
あえてあれを読む必要はないとは思うけど。自分も
どんなことが書いてあったか覚えてないくらいだし。
でも、多分、あれがあの時代の一般的なOOPの捉え方
だったんじゃないかな。

あのころ出てた本で今でも読めるのっていったら、
SRAの青木さんの本くらいじゃないの? そんなに
強くはすすめないけど。青木さんは文章を公開
されてるんで、肌に合うんなら読んだほうがいいと
思うけど。

http://www.sra.co.jp/people/aoki/

本家Permlink


2008年04月15日

まぁ、でも、あれ読んで「目からウロコが落ちました」
なんていわれることを期待してるわけじゃないんですよね。
「ああ、そうだよね」みたいに思ってくれればいいわけで。
だって、当たり前のことしか書いてないんだから。

でも、新人なんかが入ったときに「ソフトウェア開発って
いうのはこういうものなんだ」っていうことをいえなきゃ
いけないとは思うんですよね。新人でもプログラミングの
経験したことのある人は多いでしょうけど、それだけじゃ
ないから、ソフトウェア開発っていうのは。

本家Permlink


2008年04月14日1

『納品する』っていうのを無理矢理『テストする』に
突っ込んだわけですけど。これは『デバッグする』なんかと
違って頻度は少ないけど、ハッキリと意識しとかないと
痛い目を見る活動です。

ある程度期間のあるプロジェクトなら、中間納品という
ものを経験しておくのは価値があるといわれてます。
agileでは、それをさらに推し進めて、常にリリースできる
状態にしておくなんていうことがいわれます。

納品の過程は徹底的に自動化すべきです。1つには、こうした
ものは自動化しやすい場合が多いということ。もう1つは、
納品という切羽詰まっているときに間違いを犯さないため
です。

たとえば納品物をCDの形で納めるなら、ソースやドキュメントを
まとめてCDに焼くところまでを自動化できないか考えます。
サーバに置くものなら、パッケージにまとめてデプロイして、
サーバを再起動するまで。

もちろん、いざ納品となったときにヨッコラショと自動化を
はじめるわけにはいきません。ですから、普段から納品の
過程を意識して自動化しておくことが大切になります。

--

納品に限らず、自動化一般にいえることですが、手段を
選ばないこと。Javaで書かれたプログラムだからといって、
納品の自動化をJavaでやるバカはいませんよね? だから、
シェルやスクリプト言語、あるいはコマンド・ラインから
使うツールについての知識を備えておきましょう。

--

納期は守りましょう (笑)。いや、笑いごとじゃないん
ですよ。たとえまともには動かなくっても、それらしい形に
までは持っていって、納品という『儀式』を無理矢理にでも
済ますことが社会的、政治的に重要です。これ、ほんとの
話 (笑)。

本家Permlink


2008年04月14日

www.doblog.comってあるんだね。でさぁ、この中のブログの
1つを見ると下のほうに『Copyright (c) 2006 NTT DATA CORPORATION』
ってあるんだよね。

ってことは、なにか? doblogに書かれてるブログはみんな
NTTデータの公式見解と思っていいのか? (笑)。

著作権表示ってのはそういう意味だろ? 違うのか?

ブログの中で何か商品が紹介されてたら、それはNTTデータが
責任を持ってイチオシしてるってことだよな? 違うのか?

著作権表示ってのはそういう意味だろ? 違うのか?

本家Permlink


2008年04月13日2

『ソフトウェア開発』っていう活動の中にある『プログラミング』
っていう活動。さらにその中には:

* 設計する
* コーディング
* デバッグする

っていう3つの活動があるんだよっていう話をしました。

で、『デバッグする』っていうのをわざわざ取り上げる
べきか悩んだんですけど。てか、今でも悩んでるんです
けど。

でも、バグを出さないようにするにはソフトウェア開発
全体を見直さなきゃいけないし。出たら出たで、やっぱり
デバッグ特有のテクニックっていうのもあるじゃないですか。

まぁ、そのテクニックって、基本はそんなに数多くある
もんじゃないんですけど。このへんは最適化の話と似てる
んですよね。ただ、デバッグは、最適化と比べると頻度は
高いんですけど。

デバッグの第一原則は、バグを出さないように設計する
こと。バグを出しにくい設計といったものもありますから。
C++でいえば『資源確保は初期設定』っていう設計指針が
ありますよね。そういう類のこと。最適化と同じように、
この第一原則は、他の原則よりかなり重い。

それでも、バグが出ちゃったら。原因を特定する。これが
第二原則ですよね。どこでバグってんのか知らなきゃ手の
施しようがない。そのためにはデバッガで追ったり、ログを
仕込んだり、二分探索法で場所を特定したり。処理の流れを
誰かに説明することで気づくこともあります。そのドメインの
経験者がいれば、どこが問題になりやすいか教えてくれる
かもしれません。まぁ、あとは経験と勘ですね。

第三原則が、1つのバグをつぶすことで、新しいバグを
呼びこんではいけないっていうこと。当たり前のことなん
ですけどね。でも、そのためには回帰テスト (regression
test) みたいなのがあったほうがいいし。あるいは第一
原則に立ち戻って、設計を見直したほうがいいことも
あるでしょう。

こうやって考えてみると、やっぱり『デバッグする』って
いうのは、『プログラミング』、つまり『設計する』と
『コーディング』の組み合わせの特殊ケースに過ぎない
って気もするんですよねぇ。

--

でね、結局人間がやることなんだから。しかも集団で。

だから、複雑に考えるとダメなんですよ。人が集まれば
それだけで複雑になっちゃうんだから。

だから、基本で考えるっていうのが大切なんですよ。
単純でなければ、それは基本っていえないですよね。

あのWikipediaのページ読んで、あれが単純だとはいえ
ないでしょう。『ソフトウェア開発は複雑なものなんだ
からそれでいいのだ』っていうのは強弁に過ぎないんじゃ
ないですか。それでうまくいくんならともかく。

--

そうそう、落合監督の本でもそうだったけど。やっぱり
下半身と上半身みたいに分けて考えるところからはじまる
わけ。でも、やっぱりバッティングっていうのは下半身と
上半身が同時に動く一連の動作なわけで。つまりはスイング
だよね。トップ (あるいは始動) からフォロースルーまでの
全体的な流れ。そこに話を持っていく。

だから、個々の活動がどんなものかを知るっていうのが
まず最初にあるわけ。で、次に、それらが相互にどういう
影響を与え合うのかっていうのを知ると。個々の活動が
スムーズにつながってはじめていいリズムが生まれると。

本家Permlink


2008年04月13日1

http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E5%B7%A5%E7%A8%8B

こういうのを見ると、自分の考えが間違っているのかと
不安に思わないでもないんですけどね (笑)。でも、自分が
書いた『ソフトウェア開発の基本的な活動』っていうのは、
どう考えたってハズしてるとは思えないんですよね。それが
落合監督のいう『理屈』ってヤツです。

Wikipediaの記述を見ると、計画っていう概念がないです
よね。でも、それっておかしいじゃないですか。計画が
立てらんなかったら、ビジネスや組織として動きようが
ないんですから。じゃあ、計画立てるにはどうすりゃ
いいかっていうと、見積もるしかないですよね。見積もり
っていうのは、やんなきゃいけないことを積み上げること
でしょう。で、やんなきゃいけないことっていうのは
フツーは無関係に存在するんじゃなくって、先にやんなきゃ
いけないこと、後回しにできることっていう具合に優先
順位みたいなのがある。それを時間軸に沿って並べるのが
『線引きする』ってことです。『段取りする』といっても
いい。

計画立てずにソフトウェア開発ができるっていうんなら、
やってみろって。『計画を立てるのは当たり前だから、
わざわざ記述するまでもない』ってか? 当たり前のことを
当たり前として書くことが学問というもんだろ。そこを
ハショってどうすんの?

で、Wikipediaに書かれてるような認識が、この業界の
ジョーシキだっていうんだから、頭が痛いんだよな。
どうしてこんなことになってんのか、サッパリわかんない。

ISOとかCMMなんかクソックラエだよ、ほんと。

--

ああ、あと上の記事の中で気になったんですけど:

  アジャイルでは計画よりもフィードバックを重視する。

そんなこと誰がいったの? XPE1でいえばThe Planning
Gameっていう、そのものズバリの実践があったし、XPE2
ではWeekly Cycleっていうのがあって、それは1週間ごとに
計画を見直しましょうっていうことですよ。っていう
ことは、プロジェクトの初期の短期間しか計画活動を
やんない古典的な開発手法よりよっぽど計画っていう
もんを重視してるってことですよ。

大体、それまでのところで『計画』なんて一っ言も出て
きてないじゃん。それをいきなり『計画を重視しない』
って。じゃあ、テメーらは計画を重視してんのかよ?
だったら、それがなんで説明されてねぇんだよ?

--

たとえば、『線引きする』っていうのは、開発スタイルに
よってやり方が変わります。XPでは、『価値の高いもの
から実装する』っていう線引きの方針があります。一方、
古典的な手法では『インフラから実装する』っていう
線引きの方針があります。

自分は、XPを信奉してますから『価値の高いものから実装
する』っていう方針を支持しますけど。でも、そうじゃなく
『インフラから実装する』っていう人がいても別に構わないと
思ってるんです。どっちを選ぶかは『基本』じゃないから。
『線引きする』っていう基本が守られるんなら、その
スタイルは自分に合ったものを選べばいいと思うんです。

文書化もそう。必要ならやればいいし、そうでなければ
やんなくってもいい。ただ、これまで一度もやったことが
ないんなら、一度は経験してみるのもいいと思うんです。
『この四半期は文書化に力を入れてみよう』みたいな
感じで。そうやって、どの程度まで文書化すればいいのか
っていう線を知っておくのも悪くないでしょう。文書化の
必要性は、規模や期間、あるいは組織文化によっても左右
されますから、一概にやったほうがいいとはいえないん
ですね。だから『基本』とはいえない。

本家Permlink


2008年04月13日

こないだも『ソフトウェア開発の基本』っていうことを
書きましたけど。ちょっと考えを変えました。前のでも
そう間違ってないとは思ってるんですけど。

agileだろうが、古典的な開発スタイルだろうが、一人で
やろうが、百人でやろうが、ソフトウェア開発という活動の
中で必ず現れる活動を基本的な活動と呼ぼうという話でした
よね。

その基本的な活動と呼べるのは大きく分けて3つ:

* 計画を立てる
* プログラミング
* テストする

(前と分類が変わってます。)

最初に『計画を立てる』。『計画を立てる』という活動に
含まれる活動には:

* 要件を洗い出す
* 見積もりを出す
* 線引きをする

といったものがあります。『仕様を決める』という活動を
明示的に組み込むこともありますけど、基本的に仕様と
いうのは、要件の内容を別の言葉で言い替えるだけです。

次に『プログラミング』。『プログラミング』に含まれる
活動には:

* 設計する
* コーディング
* デバッグする

といったものがあります。プログラミングの中のこれらの
活動は、ほぼ同時に行われることもあります。

最後に『テストする』。『テストする』という活動に
含まれる活動には:

* 受け入れテストをする
* 出荷する

といったものがあります。ちょっと迷いましたが、ここに
『出荷する』を持ってきました。屁理屈をいえば、出荷
して実際に使われることこそ製品の最終的なテストだから
です。

まとめると:

* 計画を立てる
    * 要件を洗い出す
    * 見積もりを出す
    * 線引きをする

* プログラミング
    * 設計する
    * コーディング
    * デバッグする

* テストする
    * 受け入れテストをする
    * 出荷する

といったようになります。

--

活動を分類することが重要なのは、分類することで活動
全体が健全かどうか、健全でなければどこに問題があるかを
知りやすくするためです。これらの活動がきちんと行なわれて
いれば、ソフトウェア開発という活動全体が概ね健全に
行われているといえます。

一応分類はしましたけど、実際には境界が曖昧なことも
あります。また、それぞれの活動が他の活動に影響を
与えることもあります。活動の相互作用については、前と
考えは変わっていません。

?bakaid=200707301

--

以上のような基本を踏まえた上で、具体的なagileなりの
開発スタイルを取り入れていくのがいいでしょう。

agileと古典的なスタイルとの大きな違いは、それぞれの
活動が独立したものと考えるのか、それとも相互に影響を
与えるものと考えるのかという点です。

活動が相互に影響を与えるものと考えれば、それらの
境界は曖昧になっていきます。たとえば、agileでは
(自動化された) ユニット・テストがよく行なわれます。
これは、上記の分類でいえば『テストする』ということに
なると思うかもしれませんが、実際には『プログラミング』の
性質も強く持っています。

しかし、活動全体を見るときには、やはり基本的な活動が
できているかどうかで判断するほうがいいでしょう。
そして、弱いと思われる活動について手当てをする。
いきなり全体の枠組みをガラッと変えようとするのは危険
です。

本家Permlink


2008年04月11日

今日、会社の上司と面談があって、どういうわけか、
最適化についてしつこく聞かれた。テキトーに話を
はぐらかしたけど、春の基本祭りということで、ちょっと
書いておこう。

というか、こんなこと、わざわざ自分が書くまでもない。
マトモな本を読めば書いてあること。ちなみに、この
世界で最適化といったら、速度面の向上を意味する。

まず、最適化の第一原則は、最適化をしないこと。最適化の
ことなんか忘れて、よい設計をすることに注力すること。
この原則は、第一にして最後の原則といっていいくらい、
他の原則に比べて重い。

最適化の第二原則は、計測すること。現状がどのくらい
遅いのかを計測し、最適化で達成したい目標を具体的な
数値で出す。感覚的で曖昧な目標は選ばないこと。さらに、
計測することで、どこが遅いか (ボトルネック) を探し出す。
そして、そのボトルネックを集中的に最適化する。

第三の原則は、最適化の手段の選び方。もっとも効果的
なのはアルゴリズムを変えること。バブルソートよりも
クイックソートのほうが断然速いことくらいは知ってる
だろう。次に、あまり期待できないことだけど、全体の
設計を見直すことで速度を上げることができるかもしれない。
最後は、単純さと引き換えに速度を稼ぐやり方。典型例が
キャッシュ。あるいは、C言語やアセンブラで書くことなど。

第一の原則に戻るけど、よく設計されたシステムは
最適化がしやすい。関数が小さく砕かれていて、重複が
少なければ、ボトルネックを見つけやすくなる。モジュール
性が高ければ、遅いモジュールを高速なもので置き換える
ことができる。

最初に書いたとおり、最適化というは普段は忘れていい
ことなんだけど、いざ問題となったらプロジェクトの
命運を左右するくらい深刻な話になる。実際問題、遅い
という理由だけで使われなくなったシステムは腐るほど
あるだろう。だから、常にユーザにシステムを触って
もらうことが大切になる。プロトタイプで速度を計っても
あんまり意味がないことも知っておこう。

本家Permlink


2008年04月10日

行動経済学的なアプローチを採り入れることはできないか。
つまり、『やったほうがいいとわかっていることをデフォルトに
する』ということ。

TDDは、このアプローチに近いだろう。さらにもう一歩
進めることはできないか。

本家Permlink


2008年04月09日

東洋経済がニッケーの特集組んでるけど。面白くないね。

結局、『ニッケーを読む理由』ばっかり取り上げてて、
『ニッケーを読まない理由』が書かれてない。

確かに新聞はニッケーの一人勝ちかもしれないけど、新聞
自体が斜陽であることに変わりはないわけで。それに、
もう今となっては、ニッケーと東洋経済が敵対関係だって
ことがわかってないんじゃないか。昔だったら補完関係
だったかもしれないけど。だったら、『ニッケーを読む
理由』を書くのは、敵に塩を贈るようなもの。

--

プログラミングはソフトウェア開発の一部に過ぎないって
ことを書いたわけだけど。ちょっとピンと来ないかも
しんない。

自分一人で趣味でプログラムを書くのと、組織で仕事で
プログラムを書くのとの違いっていうかな。

極端に単純にいえば、途中で投げ出せないんだよね。まぁ、
プロジェクトが中止されることもないにはないけど。でも、
自分の勝手な都合で『や〜めた』っていうのはフツーは
できない。いや、辞表出すとか、夜逃げするとかはできる
けど (笑)。

途中で投げ出せないから、それなりに準備や計画や調整
っていうもんが必要になる。

途中で投げ出せないことにもからむんだけど、ソフトウェア
開発っていうと、誰かに『こういうの作ってくれ』って
いわれてプログラムを作ることがほとんど。だから、
『こういうの』が『本当はどんなのか』をハッキリさせたり
(要求定義)、作ったものが本当に『こういうの』なのかを
確かめる (テスト) 必要がある。

それと、プログラムが大きいんだよね。『こういうの』が
たくさんあるから。だから組織でやるわけだけど。
プログラムが大きくなると、やっぱりソフトウェアの設計と
いったものがそれなりに重要になる。

あと、ソフトウェア開発っていうと、プログラマ以外にも
いろんな人が関わってくる。『こういうの作ってくれ』
っていってくる人。これはフツーはお客さんて呼んでいい
んだけど、社内の別の部署ってこともある。それに、お金を
出す人が必ずしも作るソフトウェアのユーザとは限らない。
で、お客さんとお金の話をするのは営業か管理の人だろうし。
パッケージならマニュアル書く人が専任でいるかもしん
ないし。Webならページのデザインやってくれる人。
もちろん、グラフィックっていう意味でのデザイナも
いるし。ゲームだったらバグ出しする人がいたりもする。
そういう雑多な人が集まって、1つのソフトウェアを作り
上げるわけだ。

野球の試合やってて、キャッチャーがケガしたとして。
さらに悪いことに控えがいなかったら。そうしたら、
誰かがキャッチャーやんなきゃいけない。たとえ経験が
ない人でも。それとおんなじで、プログラマだって、
お金の話をしなきゃなんないときだってあるかもしん
ないし、絵を描かなきゃなんないときだってあるかも
しんない。それはソフトウェアを開発するっていうのが
一番の目的だから。まぁ、あんまり経験したくないこと
だけど。

野手だからっていってバッティングのことだけ考えてりゃ
いいわけじゃないでしょ。守備もあるし、打席に立ってる
ときだって、ゲームの流れってもんを読まなきゃいけない。
だから、プログラマだって、プログラマなりにプロジェクトを
回すことを考えなきゃいけないんだよね。

本家Permlink


2008年04月08日

ああ、あった、あった。

『落合博満の超野球学 1』(落合博満、ベースボールマガジン社)

  練習を重ねていい形を作る。それを試合で崩される。そして、またいい形に
  作り直す。バッティングとは、この流れの繰り返しであり、その中では基本
  をしっかりと体にしみ込ませておくことが絶対条件である。決して理想的な
  形にならなくても、ひたすら理想を追い求め、ゲームではどんな形であれ結
  果を残す。いい打者になるためには、このことを忘れないでほしい。

--

だから、プログラミングとかの知識っていうのは、いってみればバッティング
理論みたいなもんなんですね。実はそれって、全然基本じゃないんです。

バッティングっていうのは野球の一部ですよね。ってことは、バッティングす
るためには、野球ってもんを知ってなきゃいけない。野球のルールだとか文化
だとか、そういうものを理解してなきゃいけない。そういうことが本当の基本
なんです。

自分らはソフトウェア開発っていうゲームをやってるわけです。その中で、自
分らはプログラマっていうプレーヤーなわけです。プログラマですからプログ
ラミングの基本が大切なのは当たり前です。でも、その前に、ソフトウェア開
発っていうのがどんなものなのかっていうのを知らなきゃいけないわけです。
ところが、これを教えてくれる人は少ないんですよね。

この業界の新人は、プログラミングは知ってても、ソフトウェア開発は知らず
に入ってくることがほとんどでしょう。だから、まず、ソフトウェア開発がど
んなものかっていうのを知ってほしいんですよね。そして考えてほしい。結局、
プロとして生き残っていくには、その職業について考え抜くしかないんですか
ら。

--

たとえば、上の本の中で、落合氏は、元スワローズの八重樫選手を引き合いに
出して、オープン・スタンスについて詳細に論じている。オープン・スタンス
のメリットとデメリットを説明している。頭から『あんなスタンスではダメだ』
と否定するのではなく、自分の頭で考えて結論を出している。

仕事の中にはヒントはいっぱい転がっている。そのヒントに気づき、考えるこ
とが大切なのだ。

本家Permlink


2008年04月07日2

これ、書いたかもしんないけど、気にしない。

どの本だったか覚えてないんだけど、ドラゴンズの
落合監督が『試合では形を崩されても結果を残すことが
大切で、練習では崩された形を取り戻すことが大切』
みたいなことをいってたんですよね。

もちろん、自分らは試合と練習が厳密に区別された世界に
いるわけじゃありません。でも、監督のこの言葉は、
やっぱり意味があるんですよね。

特に納期に終われてたりすると、汚ないコードでも目を
つぶって『動きゃいいんだ』って感じになるじゃない
ですか。あるいは、ググってどっかで見っけたコードを
引っぱってくるなんてこともあるわけでしょう。そういう
ことを自分は頭っからダメだとはいわないんですよね。
そんなこと、このgdgdな自分がいえるわけがない (笑)。

でも、こういうのって、長い目で見たら、やっぱりよく
ないことなんですよね。保守性がどうたらっていう話も
あるけど、それより何より、自分が成長できない。

汚ないコードになっちゃうのは、いい設計が見つからない
からですよね。いや、いい設計が見えてても、時間に
追われて手をつけらんないってこともありますけど。
で、いい設計が見つからないんなら、やっぱりいい設計
ってのがどんなものか勉強しなきゃいけない。

ググって見つけた情報っていうのは、大抵は断片的な
もので、体系立ったものじゃない。体系立った知識じゃ
ないと、やっぱりツブシが利かない。そういうバッド
ノウハウっていうのは、いくら積み重ねてもバッドノウ
ハウに過ぎない。だから、やっぱり基本から勉強する
必要はあるわけです。

納期を守るためにはバッドノウハウも大切だけど、
もっと長い目で見たときには、基本を勉強することも
大切。そのバランスが大切なんだっていう話になっちゃう
んですけど。でも、『バランス』っていう言葉は自分は
嫌いですから (笑)。

さとるさんもいってるように、本を1日1ページ読むと
したら、1年で365ページ読めるわけです。実際、1日で
1ページだけ読むってことはないですから、2ページだと
しても700ページくらい読めるわけです。700ページって
いったら、APUEが大体そんくらい。Code Completeは
上巻が550ページくらい、下巻が450ページくらい。
まぁ、他の本にしても、大体1年あれば読破できそうです
よね。

将棋の谷川さんは『15分って結構いろんなことができる
時間ですよ』っていってます。実際、15分あれば本を
1ページ読むことはできますよね。

自分らは試合と練習の区別がないですから。だから逆に
継続することが大切になるんじゃないかと思うんですよ。
1日1ページ、1日15分でいいんだと思えば、ちょっとは
続けようって気になるんじゃないですか。

--

ちなみに、自分は『演習問題やらない派』(笑)

--

『落合博満の超野球学 2』(落合博満、ベースボールマガジン社)

  安全か危険かという判断は、確率論や経験による裏付けで考えていくべきで
  あり、そこに「なんとなく」という感覚的な要素を持ち込むべきではない。

いや、これを読んであの発言をしたかどうか覚えてない
んですけどね。

プログラムは絶対に「なんとなく」は動かないし、
「なんとなく」動かなくなることもない。

ハードのバグにブチ当たるなんて絶対にないって思って
いるほうがいいし、標準ライブラリがバグってるなんて
絶対にないって思ってるほうがいい。

本家Permlink


2008年04月07日1

XPの一番目の価値っていうのは、いうまでもなく、
communicationなわけ。

で、このcommunicationっていうのは、自分から伝えようと
しないとダメなわけ。communicationがはじまるのはいつも
自分からくらいの気持ちでないとダメなわけ。

XPの価値には他にもfeedbackっていうのがあるけど。
このfeedbackだって、inputがなきゃ返ってこないんだから。

たとえばレビューといわれるもの。レビューは非常に有効な
手段なんだけど。でも、必ずしも「これからレビュー
やります」みたいな感じで時間を設けなくっても、普段の
会話の中でレビューっていうのはできるわけ。ペア・プログラミング
なんて、常時レビューし合ってるようなもんなんだし。

どっちかっていうと、そういうinformalなレビューが大切
なのね。だって、それこそcommunicationの話になるでしょ。
informalな会話がたくさん流れてるってことは、すなわち
communicationが豊かだってことなんだから。

informalな情報をいつかはformalな形で残す必要も出て
くるんだろうけど。でも、そんな形式にとらわれること
よりも、まずcommunicationを豊かにするほうが先なわけ。

--

どうもこの業界、文書に頼ろうとする人間が多いよな。
新人なんかも、マニュアル慣れしてるせいか、そういう
文書をすぐ求めがちだよな。でも、そういう薄い人間
関係でこれから先やってくのかどうか、ちょっと考えた
ほうがいいよね。

人に聞くっていうのは面倒だけど、そういうとこから
濃い人間関係っていうのがはじまるんだし。そういう
濃い人間関係っていうのを嫌ってるようじゃ、職業
プログラマには向かないよ。

ああ、薄い、濃いっていうのは、それほど深い意味じゃ
なくって、「リアルな世界の」っていう程度の意味。
別に呑みに誘えとかそういう話じゃない。

本家Permlink


2008年04月07日

『トレセン探検隊』終わっちゃうのか。

本家Permlink


2008年04月06日

アジャイルとか、それとUMLとかもそうなんだけど、
そんな言葉を自分とこのホームページに載せんなよ。

ホームページってお客さんが見るもんだろう。お客さん
ってのはフツーはシロートだろう。シロートさん相手に
カタカナ言葉でケムに巻くようなのはもう止めろや。

トヨタのクルマ買う人が、トヨタ生産方式のことなんか
知りたがるか? 専門用語は専門家が理解できればいい
んであって、それを表に出すべきもんじゃない。

--

何が根本的な問題か。結局、自分とこの製品ややり方の
品質を短い言葉でゴマかそうとしてるんだよな。
『アジャイルだから大丈夫です!』とか、『UMLだから
大丈夫です!』とか。そんなわきゃねぇだろ。

品質っていうのをお客さんに理解してもらうには、実績
以外にないんだよ。だからブランドってもんが重宝される。

ブランドってもんは、いってみれば独自のやり方の積み
重ねなんだよな。だから、その組織独自のやり方って
もんを持たなきゃいけないんだよ。アジャイルとか、
そういうアイマイな言葉じゃなくって、自分のところの
『○○方式です』っていえなきゃいけないんだよ。

どこもかしこも『アジャイル』とかいうやり方で済むん
なら、組織分ける必要なんかどこにもない。でも、そう
じゃねぇんだろ? それぞれの組織には、それぞれの
組織に合ったやり方ってのがあるんだろ。それを
『アジャイル』の一言で済まそうってのはアタマワルイし、
全然agileを理解してないってことだよ。

本家Permlink


2008年04月04日

つか、会社員だったのかよ!

本家Permlink


2008年04月03日

今になってFXをはじめてもダメでしょ (笑)。

本家Permlink


2008年04月02日1

昼にこのページにアクセスしたら、なんかへんな内容が
表示されてアセったんだけど。どうも、アクセスした
Firefoxのほうの問題だったみたい。

本家Permlink


2008年04月02日

http://news24.2ch.net/test/read.cgi/bizplus/1206971547/

ソース記事は結構前のヤツで。いや、そんなことより、
こういう2chのスレで『アジャイル』なんていう言葉が
ポンポン飛び交う光景を見るのは、なんていうか、不思議な
気分だね。時が経ったなぁというか。

少なくとも自分がはじめて知ったころは、アジャイル、
というかXPだけど、それってかなり異端だったんだよね。
いや、実際には本読めば共感する人間も多いんだろうけど、
『業界のお仕事』的にはやっぱり異端。

それが受け入れられるようになったのは、やっぱり、
それだけ困ってる人が多かったってことなんだろうね。
結局、デカイ受注だけの世界って、実はそんなに多く
ないんだなっていうか。

ニッケーとかは、そういうデカイ受注がメインストリーム
なんだみたいな印象操作してたわけで。まぁ、そのへんは
IPAあたりもおんなじだろうけど。あそこはメーカーから
出向してる人が多いらしいし。

前からいってるけど、システムは自前で作んないとダメ
でしょ。このソース記事みたく、どんどん縛りがきつく
なるんなら、余計外で作れなくなる。変わんなきゃいけ
ないのは、業界じゃなくって、お客さんのほう。お客さんが
自分でシステム作ろうと思わないとダメ。それが結局
業界をよくすることにつながる。

本家Permlink


2008年04月01日

いや、あれはエディタじゃなくって、Lispインタプリタに
たまたまエディタがついてるだけ。

まぁ、そのLispインタプリタのデキが悪いっていうのは
あるけど。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails