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 11 12

ホーム

2009年09月30日

ソフトウェア開発には3つの知識が必要だということは
前に述べた。

* 問題領域の知識
* テクノロジーの知識
* ソフトウェア開発そのものの知識

これらひとつひとつに性格づけをする。

問題領域の知識、「ドメインの知識」や「ビジネス・
ドメインの知識」といわれることもあるが、これは、
儲けるための知識だ。これを知っているのが一番お金が
稼げる。

テクノロジーの知識は食うための知識だ。プログラミング
言語やフレームワークといったものをよく知っていれば、
食いっぱぐれることはない。

ソフトウェア開発そのものの知識というのは、この仕事を
長く続けるための知識だ。この仕事は、問題領域も
変われば、テクノロジーも変わる。けれども、開発の
やり方が劇的に変わるということはない。

新人諸君は、まずテクノロジーの知識をしっかり積む
こと。ドメインや開発の知識は、先輩たちのマネを
すればいい。

--

先輩たちのやり方が気にいらないということもあるかも
しれない。でも、そこはガマンだ。そのやり方には実績や
歴史があるということをよくよく考えないといけない。

善くする気持ちは大切だが、すべてを一気に善くするのは
ムリというものだ。

--

木を切るときは木目をよく見てから切る。割とよく
いわれることだが忘れがちでもある。

システムが大きくなれば、木目も細く、からみ合って
いるものだ。だから、動きをデバッガで追い、コードを
よく読み、木目を見極めてから切ること。

そういう意味では、上の話も同じだ。人の気持ちを
考えずに、独り善がりで「善くしよう」と思えば、
必ず失敗する。人をよく見て、木目を探すこと。

本家Permlink


2009年09月29日

メーカーとか大手SIerとかが国の金でクラウド用のデータ
センター作りたいだけなんちゃうの?

--

残るのは官公庁の仕事くらいじゃない? ああいうとこは
自前で作るわけにはいかないだろうから。でも、そういう
仕事は大手に抑えられちゃってるわけでしょ?

--

MtFだったのか。逆かと思ってた。

本家Permlink


2009年09月28日

流動性が高い労働市場において、その労働者たちが作る
製品の品質が高くなるには、市場における十分な数の
労働者たちに教育が施せるかどうかにかかっている。

当たり前の話だけど。組織単位ではなく、市場全体の
底上げが必要というのがミソなわけで。経営者側が
いくら労働者を教育しても、その人たちが出ていったら
どうしようもない。

本家Permlink


2009年09月26日

ウォーターフォールでやるんなら、ぜんぶ作り終わって
からお金をもらうよりは、工事進行基準のほうが健全
なのかなぁ。

まぁ、自分がこの前書いた『マヤカシ』というほどひどい
もんじゃないかもしれない (笑)。

でも、結局、この問題は、『各工程 (要件定義・設計・
実装・検収) を独立して行うことができるか』っていう
話に行き着くんだよな。

もし独立してできるんなら、それこそ建築業界の形態が
ぴったりハマるっていうことになる。設計事務所と
施工会社といった関係。

そういう形態なら、各工程ごとの選択肢も増えるし、
工程間の透明性も高まるし、そんなに悪いことじゃ
ないだろう。

もちろん、自分は、各工程を独立してやるのは事実上
ムリだと思ってるわけだけど。

『事実上ムリ』っていうのは、『不可能じゃないんだけど、
コストがかかり過ぎる』っていう意味で。

--

似たような話で、『水平分業』っていうのがあるよね。
でも、ソフトウェアって水平分業で成功できるのかな。

Microsoftにしても、Appleにしても、Googleにしても、
任天堂にしても、ソフトウェアは自前で作ってるんじゃ
なかったっけ?

ゲームがあるか。ゲーム業界は、パブリッシャーと
デベロッパーに分かれてることが多い。でも、じゃあ、
ゲーム開発を工事進行基準でやるの?

  http://www.atmarkit.co.jp/aig/04biz/pcm.html

  工事進行基準適用の要件とは「工事収益総額」「工事
  原価総額」「決算日における進捗度」の3つが信頼性を
  もって見積もれることである。

まぁ、ムリじゃないの? でも、ムリだったら、じゃあ、
自分らの仕事は、工事進行基準を適用できるほど、ゲーム
よりも正確に見積もれるの?っていう話になる。

本家Permlink


2009年09月25日

SIそのものが斜陽産業で、その斜陽化の要因のひとつが
オープン・ソースなのに、SI+オープン・ソースで
儲けようとしても無理筋じゃない?

--

動かないコードの価値は、ゼロどころかマイナスだ。

コードを書くために使われた費用、ビジネス的なコスト
ということも、もちろんある。でも、それだけじゃない。

コード量が増えれば、システム全体の複雑さは否が応でも
上がる。その複雑さのコストというものもある。

ぶっちゃけ、ビジネス的なコストっていうのは、自分ら
プログラマが勝手に決められるものじゃない。でも、
複雑さのコストは違う。自分らが努力すれば、その
コストは抑えることができる。言い替えれば、コードは、
その複雑さのコストをペイできるほどには価値がなきゃ
いけないっていうこと。

--

たとえば:

int
main(int argc, char *argv[])
{
    /* Added by tko 2009-09-25 */
    puts("hello, world");
    /* Added End */

    return 0;
}

みたいなコメント。こういうのを見れば、このコードが
正しくリビジョン管理されてないことがわかる。

「いつ、だれが、なんのためにそのコードを書いたか」
っていうのは、トレーサビリティの話だ。そして、
トレーサビリティはリビジョン管理の話でもある。

そして、こうしたコメントを入れるっていうことは、
リビジョン管理ツールが使われていないか、正しい
使い方を知らないことを物語っている。つまりは、
トレーサビリティが十分に確保できていないことが、
このコメントからわかる。

そして、トレーサビリティが確保されていないっていう
ことは、品質改善の手がかりに乏しいことを意味する。
つまり、彼らは、品質について無頓着であるという
ことまで、このコメントからわかってしまう。

本家Permlink


2009年09月24日2

リファクタリングには終わりがないほうがフツウだ。

いや、いつまでもリファクタリングし続けることを納期が
許さないといったほうが正しい。

たとえば:

static int
see_more(void)
{
    int c;

    printf("\033[7m more? \033[m");  /* reverse on a vt100 */
    while ((c = getchar()) != EOF) {
        if (c == 'q')
            return 0;
        if (c == ' ')
            return PAGELEN;
        if (c == '\n')
            return 1;
    }
    return 0;
}

という関数。最初のprintfはプロンプトを出すための
ものだ。ならば、その意図を関数にする:

static void
show_prompt(void)
{
    printf("\033[7m more? \033[m");  /* reverse on a vt100 */
}

さて、printfに渡す引数のやっていることは何か?
端末上に文字を反転表示させることだ。ならば、その
意図を関数にする:

/**
 * reverse on a vt100
 */
static void
print_reverse(const char *text)
{
    printf("\033[7m %s \033[m", text);
}

static void
show_prompt(void)
{
    print_reverse("more?");
}

さらに、print_reverseのコメントも関数にする
ことで消す:

static void
reverse_on_vt100(const char *text)
{
    printf("\033[7m %s \033[m", text);
}

static void
print_reverse(const char *text)
{
    reverse_on_vt100(text);
}

さらに、これがC++だとして:

class ReversePrint {
public:
    virtual void print_reverse(const char *text) = 0;
};

class ReversePrintVT100 : public ReversePrint {
public:
    virtual void print_reverse(const char *text) {
        printf("\033[7m %s \033[m", text);
    }
};

といったことも考えられる。

--

まぁ、実際問題、ここまでやるかといったら、なかなか
やるヒマはない。でも、ここまでやれば、コメントは
思ってるほど必要ではないということがわかってもらえる
だろう。

リファクタリングをいつ止めればいいかはむずかしい
問題だ。だが、一方で、簡単な問題でもある。冒頭で
書いたように、納期というものがあるからだ。

agileならば、ストーリーを引き受けたときに見積もりを
出すはずだ。それがまず第一の納期ということになる。
それでも続けたければ、みんなから同意を得ないと
いけない。そのプレッシャーに勝てるなら続ければいい。

本家Permlink


2009年09月24日1

やっぱり、『コードをどう書くか』っていうことにまで
踏み込んで議論できないと、なかなか品質は上がらない
んじゃないか。

まぁ、ズバリいっちゃうと、コードを読めない人間が
品質管理なるものをやってもサルマネにしかならないん
じゃないか。

バグの量の統計を取って『バグを減らしましょう』って
いうのも、まぁ、管理のひとつではある。でも、『じゃあ、
どうやって減らすのよ?』っていう問いに具体的に答えを
出せないといけない。

ここでいってる『具体的な答え』っていうのは、『自動
テストをやりましょう』とか、そういう話じゃない。
そういう教育とか啓蒙とかの話じゃない。

もっと、具体的に、まさにバグの起きたコードをどう
書けば改善できるのかっていうことを指摘できないと
いけないっていう話。システム全体の設計を踏まえた
上での改善策を提案できないといけないっていうこと。

改善策っていうのはひとつじゃない。作り直しから
ツギハギまで幅があるほうがフツウだ。そうした幅の
中で、納期や将来的なコスト、さらには開発要員の
実力といったものを考慮して最善なものを選ぶ。あるいは、
いくつか改善策を選んで議論する。そういうことをやれる
人でないと、なかなか品質管理を品質向上に結びつける
ことはできないんじゃないか。

本家Permlink


2009年09月24日

サンダーバグ、作っちゃったよ (笑)。

激昂ラージャン、弓で。

こないだ『太刀で角を折りたい』って書いたけど、よく
考えると、てか、よく考えるまでもなく、角折りたいん
なら弓(またはボウガン)なんだよね。

45分過ぎにシビレ罠張ってるときに地中ブレス(笑)で
2死目して、急いで現場に戻ったらまだ罠が生きてて、
それでなんとか捕獲できた。

角だったら、金色とか黒子とか作るのがフツーかも
しんないけど。ランスだとそんなにほしい防具でも
ないんだよね。それだったら、性能ビミョーでも
穴3つあるサンダーバグのほうが魅力的。まぁ、でも、
ぶっちゃけ、この性能でラージャンの角がいるって
いうのは納得いかないけど。


本家Permlink


2009年09月22日

『Unix/Linuxプログラミング 理論と実践』、B.Molay、アスキーより。

原始的なmoreの例が載っている。これをいじる。

/* more01.c  - version 0.1 of more
 *	read and print 24 lines then pause for a few special commands
 */

#include	<stdio.h>

#define	PAGELEN	24
#define	LINELEN	512

void do_more(FILE *);
int  see_more();

int main( int ac , char *av[] )
{
	FILE	*fp;

	if ( ac == 1 )
		do_more( stdin );
	else
		while ( --ac )
			if ( (fp = fopen( *++av , "r" )) != NULL )
			{
				do_more( fp ) ; 
				fclose( fp );
			}
			else
				exit(1);
	return 0;
}

void do_more( FILE *fp )
/*
 *  read PAGELEN lines, then call see_more() for further instructions
 */
{
	char	line[LINELEN];
	int	num_of_lines = 0;
	int	see_more(), reply;

	while ( fgets( line, LINELEN, fp ) ){		/* more input	*/
		if ( num_of_lines == PAGELEN ) {	/* full screen?	*/
			reply = see_more();		/* y: ask user  */
			if ( reply == 0 )		/*    n: done   */
				break;
			num_of_lines -= reply;		/* reset count	*/
		}
		if ( fputs( line, stdout )  == EOF )	/* show line	*/
			exit(1);			/* or die	*/
		num_of_lines++;				/* count it	*/
	}
}

int see_more()
/*
 *	print message, wait for response, return # of lines to advance
 *	q means no, space means yes, CR means one line
 */
{
	int	c;

	printf("\033[7m more? \033[m");		/* reverse on a vt100	*/
	while( (c=getchar()) != EOF )			/* get response	*/
	{
		if ( c == 'q' )			/* q -> N		*/
			return 0;
		if ( c == ' ' )			/* ' ' => next page	*/
			return PAGELEN;		/* how many to show	*/
		if ( c == '\n' )		/* Enter key => 1 line	*/
			return 1;		
	}
	return 0;
}

まず、いじる前、イの一番にやることはバージョン管理システムに登録するこ
と。自分の場合はRCS。

次にやるのは、自分のフォーマッティングにすること。と同時に、不要なコメ
ントも消す。コンパイル時の警告も出さないようにする。清掃重要。

/**
 * more01.c  - version 0.1 of more
 * read and print 24 lines then pause for a few special commands
 */

#include <stdio.h>
#include <stdlib.h>

#define PAGELEN 24
#define LINELEN 512

/**
 * print message, wait for response, return # of lines to advance
 * q means no, space means yes, CR means one line
 */
static int
see_more(void)
{
    int c;

    printf("\033[7m more? \033[m");  /* reverse on a vt100 */
    while ((c = getchar()) != EOF) {
        if (c == 'q')
            return 0;
        if (c == ' ')
            return PAGELEN;
        if (c == '\n')
            return 1;
    }
    return 0;
}

/**
 * read PAGELEN lines, then call see_more() for further instructions
 */
static void
do_more(FILE *fp)
{
    char line[LINELEN];
    int num_of_lines = 0;
    int reply;

    while (fgets(line, LINELEN, fp)) {
        if (num_of_lines == PAGELEN) {
            reply = see_more();
            if (reply == 0)
                break;
            num_of_lines -= reply;
        }
        if (fputs(line, stdout) == EOF)
            exit(1);
        num_of_lines++;
    }
}

int
main(int ac , char *av[])
{
    FILE *fp;

    if (ac == 1) {
        do_more(stdin);
    } else {
        while (--ac) {
            if ((fp = fopen(*++av , "r")) != NULL) {
                do_more(fp);
                fclose(fp);
            } else {
                exit(1);
            }
        }
    }
    return 0;
}

コミットしたあと、目につくのがmain。まず、mainの引数の名前を標準的なも
のに変えたあと、whileの部分を切り出す。

static void
do_more_files(int argc, char *argv[])
{
    FILE *fp;

    while (--argc) {
        if ((fp = fopen(*++argv , "r")) != NULL) {
            do_more(fp);
            fclose(fp);
        } else {
            exit(1);
        }
    }
}

int
main(int argc , char *argv[])
{
    if (argc == 1)
        do_more(stdin);
    else
        do_more_files(argc, argv);
    return 0;
}

しかし、このdo_more_filesのインターフェイスはわかりにくい。なので、わ
かりやすいものに変える。

static void
do_more_files(char *filenames[], int size)
{
    int i;

    for (i = 0; i < size; ++i) {
        FILE *fp;

        fp = fopen(filenames[i] , "r");
        if (!fp)
            exit(1);
        do_more(fp);
        fclose(fp);
    }
}

int
main(int argc , char *argv[])
{
    if (argc == 1)
        do_more(stdin);
    else
        do_more_files(argv + 1, argc - 1);
    return 0;
}

do_moreとsee_moreには問題があると感じる。

see_moreは仕事が多すぎる。see_moreは、ユーザからの入力をスクロール量に
変換するという仕事をしている。しかし、ユーザからの入力は、実際には『コ
マンド』であり、スクロール量ではない。そもそも、see_moreはUI層に位置す
るものであり、一方で、スクロール量はロジックやモデルと呼ばれる部分が決
めるべきもの。

ひとまず、see_moreからは『概念的に』コマンドを返すように変える。

enum Command {
    CMD_QUIT = 0,
    CMD_LINE = 1,
    CMD_PAGE = PAGELEN
};

/**
 * print message, wait for response, return # of lines to advance
 * q means no, space means yes, CR means one line
 */
static enum Command
see_more(void)
{
    int c;

    printf("\033[7m more? \033[m");  /* reverse on a vt100 */
    while ((c = getchar()) != EOF) {
        if (c == 'q')
            return CMD_QUIT;
        if (c == ' ')
            return CMD_PAGE;
        if (c == '\n')
            return CMD_LINE;
    }
    return CMD_QUIT;
}

次に、do_moreのほうでは、コマンドをスクロール量に変換する。

/**
 * read PAGELEN lines, then call see_more() for further instructions
 */
static void
do_more(FILE *fp)
{
    char line[LINELEN];
    int num_of_lines = 0;

    while (fgets(line, LINELEN, fp)) {
        if (num_of_lines == PAGELEN) {
            enum Command reply;

            reply = see_more();
            if (reply == CMD_LINE)
                num_of_lines -= 1;
            else if (reply == CMD_PAGE)
                num_of_lines -= PAGELEN;
            else
                break;
        }
        if (fputs(line, stdout) == EOF)
            exit(1);
        num_of_lines++;
    }
}

しかし、これでもdo_moreにはスッキリしない感じが残る。『指定された行数
だけファイルを読み込んで印字する』という関数があればよさそうだ。

static bool
show_text(FILE *fp, int num_of_lines)
{
    int i;

    for (i = 0; i < num_of_lines; ++i) {
        char line[LINELEN];

        if (!fgets(line, LINELEN, fp))
            return false;
        if (fputs(line, stdout) == EOF)
            exit(1);
    }
    return true;
}

#include <stdbool.h>を忘れずに。さて、このshow_textを使って、do_moreを
書き換える。

/**
 * read PAGELEN lines, then call see_more() for further instructions
 */
static void
do_more(FILE *fp)
{
    int num_of_lines = PAGELEN;

    for (;;) {
        int reply;

        if (!show_text(fp, num_of_lines))
            return;
        reply = see_more();
        switch (reply) {
          case CMD_LINE:
            num_of_lines = 1;
            break;
          case CMD_PAGE:
            num_of_lines = PAGELEN;
            break;
          case CMD_QUIT:
          default:
            return;
        }
    }
}

最後にすべてのコードを載せておく。細かいことだが、#defineを消している。
LINELENをリテラルに替えた。

/**
 * more01.c  - version 0.1 of more
 * read and print 24 lines then pause for a few special commands
 */

#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>

enum Command {
    CMD_QUIT,
    CMD_LINE,
    CMD_PAGE
};

/**
 * print message, wait for response, return # of lines to advance
 * q means no, space means yes, CR means one line
 */
static enum Command
see_more(void)
{
    int c;

    printf("\033[7m more? \033[m");  /* reverse on a vt100 */
    while ((c = getchar()) != EOF) {
        if (c == 'q')
            return CMD_QUIT;
        if (c == ' ')
            return CMD_PAGE;
        if (c == '\n')
            return CMD_LINE;
    }
    return CMD_QUIT;
}

static bool
show_text(FILE *fp, int num_of_lines)
{
    int i;

    for (i = 0; i < num_of_lines; ++i) {
        char line[512];

        if (!fgets(line, sizeof(line), fp))
            return false;
        if (fputs(line, stdout) == EOF)
            exit(1);
    }
    return true;
}

/**
 * read PAGELEN lines, then call see_more() for further instructions
 */
static void
do_more(FILE *fp)
{
    const int PAGELEN = 24;
    int num_of_lines = PAGELEN;

    for (;;) {
        enum Command reply;

        if (!show_text(fp, num_of_lines))
            return;
        reply = see_more();
        switch (reply) {
          case CMD_LINE:
            num_of_lines = 1;
            break;
          case CMD_PAGE:
            num_of_lines = PAGELEN;
            break;
          case CMD_QUIT:
          default:
            return;
        }
    }
}

static void
do_more_files(char *filenames[], int size)
{
    int i;

    for (i = 0; i < size; ++i) {
        FILE *fp;

        fp = fopen(filenames[i] , "r");
        if (!fp)
            exit(1);
        do_more(fp);
        fclose(fp);
    }
}

int
main(int argc , char *argv[])
{
    if (argc == 1)
        do_more(stdin);
    else
        do_more_files(argv + 1, argc - 1);
    return 0;
}

--

上のような作業を『リファクタリング』と呼んだりもする。

個人的には『コードを整理する』という言葉を使うほうが
好みではある。

さて、既存の、すでに十分に機能しているコードを、
壊す可能性がありながら、なぜいじくり回すのか。

若者の言葉でいえば『誰得?』というヤツだ。

上のような作業を単純な『コーディング』という見方を
していたら、ただの自己マンで終わってしまう。

いじる前と、いじった後では機能は変わらない。変わった
のは設計だ。つまり、コードをいじるという行為と設計を
よくするという行為が一体となったものがリファクタリングと
呼ばれるものなのだ。

設計という行為と、コーディングという行為がハッキリと
分かれている段階もある。しかし、ある程度コードを
書き進めていくと、新しい発見があり、よりよい設計に
気づくことがある。いや、そのほうがフツウだ。その
『気づき』を無視して、過去の設計にとらわれていると
自縄自縛に陥り、最後に行き着くのは『セカンド・システム
症候群』だ。『新しくゼロから作り直したい』という
衝動を我慢できなくなる。

システムが動いている限り、4S、整理・整頓・清掃・
清潔はいつまでも続くものなのだ。4Sを続けることで、
バグの入り込む余地が減り、修正や変更に強い、
健康なシステムになっていくのだ。

本家Permlink


2009年09月18日

自分みたいなのよりエライ人が説明したほうがいいと
思うんだけど。

cohesionは、関連する機能が一ヶ所にまとめられている
こという。Stringクラスには文字列を扱うための機能が
まとめられているといったのが一例。

cohesionとよく対比されるのがcoupling。これは依存
関係。リーマンショックのとき、「今は国と国との
de-coupling (デカップリング) が進んでいるから危機は
大きくならない」っていう説があった。それは真っ赤な
ウソだったわけで、グローバリズムの進展で、国と国とが
より密接に依存し合っていることが露になった。

設計の世界では、high cohesion, low couplingと
いわれる。cohesionは、個人的には凝集性と訳すのを
好む。ゆえに、高凝集・低依存ということが設計の要諦の
1つということになる。

cohesionとcouplingは、どちらも「結びつき」の様子を
示すもの。だから、「結合」という言葉だと、それが
cohesionなのかcouplingなのかわかりにくいということが
ある。

本家Permlink


2009年09月16日

今日の東スポ、13面を開いてくれ。

そこに『のりピー親衛隊』という見出しでデカデカと
写真が出てるだろ? そのキコ隊長の顔をよ〜っく
見てくれ。

え? カ、カクタニしゃん?

--

だから、デバッグっていうのは、修正する量が問題じゃ
ないんだよね。いや、そりゃ、量が多けりゃ手間がかかる
わけだから、まったく問題ないわけじゃないけど。

でも、たとえば、NULLポインタで落ちる場所があったと
して。そこで単純にNULLチェックして済ますのと、その
落ちる場所を通るパスをぜんぶ調べて、それでやっぱり
NULLチェックが有効なんだと確信を持って修正するのとじゃ
雲泥の差があるわけ。

修正する量が多かろうが少なかろうが、直ったと確信を
持てること、誰かから『こんなときはどうなの?』って
いうツッコミに『大丈夫です』っていえることが大切な
わけ。

--

だから、自分らは継続的な統合、進化的な設計をやってる
わけで。それで一番恐いのは作り壊し、直し壊しなわけね。

新しい機能を追加したら古い機能を壊しちゃったとか。
ある機能のバグを潰したら、別の機能がバグっちゃったとか。

だから、既存のコードをよく理解しないとダメなのね。

デバッガで動きを追うのも『コードを読む』うちに入ると
自分は思ってるけど。でも、だからっていって、grepが
いらなくなるってことはないわけ。

ある箇所がバグってたら、別の似たような箇所もバグっ
てる可能性が高い。そういうのはデバッガじゃ追えない
んだよね。パスが違うんだから当たり前だよね。

小手先のデバッグっていうのはモグラ叩きみたいに
なっちゃうのね。表面的な事象ばかりじゃなくって、
そいつらの根っこに何があるのかっていうのを見ようと
しないと。そういうのを見つけることが『システムを
理解する』ということのひとつで、そういう根っこの
問題を解決するには『設計』が必要になるわけね。

--

自分は当たり前のことしか書いてないんだけど。でも、
そういう当たり前を言葉にして話せるっていうのは
とっても大切なことなんだよ。

自分の周りは若いヤツばっかりっていうのもあるんだけど。
こういう話をあんまりしないわけね。前は、恥ずかしい
とか照れとかのせいかと思ってたけど。でも、違うんだよね。
言葉を知らないんだよね。

言葉を知らないっていうことは、何に価値があるかって
いうことを知らないっていうことなんだよ。何に価値が
あるか知らないっていうことは、どうすれば開発っていう
仕事がうまくいくかっていうことを知らないっていう
ことなんだよ。

言葉を知らないっていうことは、仕事について考えてない
っていうことでもある。それはプロとして非常に恥ずかしい
ことなんだよ。

--

安いものが安いままであるのには理由がある。

人はイヤでも学習する。つまり、人は時間が経てば自然と
価値が上がる。まぁ、ぶっちゃけ人件費が高くなる。

それをイヤでも抑えるにはどうするか。価値が上がった
人間を切って、価値の低い人間、たとえば新人を連れて
くればいい。

まぁ、これはオフショアに限ったことでもないだろうけど。

でも、安いところで安定してるんなら、品質も低いところで
安定すると思うほうがフツーだよな。

本家Permlink


2009年09月15日1

バグの潰し方にもいろいろあって。いい潰し方もあれば、
悪い潰し方もある。

いい潰し方の典型は、コードを削って問題が解決する
こと。呼ぶ必要のない処理を何度も呼んで、その副作用で
イカれてたとか。

悪い潰し方の典型は、1つのバグを潰して新たなバグを
生んでしまうこと。これは、全体を見ずに部分だけで
解決しようとするときによく起きる。

--

状態遷移で解決すべき問題なのに、ヘンな変数 (フラグ
というヤツ) を使って安易なif文で済まそうとしたり。

納期が迫ってれば小手先のデバッグも仕方ない。でも、
それは、いつか返さないといけない借金なんだと。

でも、こういうのは忘れ去られるのが常だから。やっぱり、
時間がかかっても、根本から直したほうがいい。

--

さらにいえば、『借金を返そう』、『借金を返したい』
とプログラマ側からいわないとダメなんだよね。そうで
ないと、なかなか返せないもんだし。

本家Permlink


2009年09月15日

「東洋経済」に角川の話が載ってんだけど、
いわれてるほどハルヒ一辺倒じゃないね。

ハルヒにしても、角川の戦略の例として取り上げてる
感じ。この内容なら、別に手抜きアニメのことを
話題にする必要もない。

--

いや、「リーマン前まで回復」って、そっちのほうが
ありえねーだろ。だって、リーマン前っつったら
バブルだったわけだろ?

--

http://www.futabasha.co.jp/booksdb/book/bookfind/?type=t&word=%E3%81%93%E3%81%A9%E3%82%82%E3%81%AE%E3%81%98%E3%81%8B%E3%82%93&btnG=%E6%A4%9C%E7%B4%A2

私屋カヲル、なにやってんだwww

つか、こっちが地なのか?

本家Permlink


2009年09月14日

メタルギアソリッドは話を作り込みすぎてるよな。
ゲームやってんだか、ムービー見てんだかわかんねぇ (笑)。

と実況を見てて思った。

本家Permlink


2009年09月10日

「コードを読む」といった場合、空白も読まなきゃ
いけない。

「コードを読んだ」というのは、そのコードを自分で
いじるときに、そのコードのフォーマッティングに
合わせて新しいコードを書き足せるということ。

int
main(int argc, char *argv[])
{
    if (argc > 1)
        puts(argv[1]);
    return 0;
}

こういう「標準的な」フォーマットで書かれているにも
かかわらず:

int main(int argc, char **argv) {
    if( argc>1 )
        puts (argv[1]);

    return 0;
}

みたいなフォーマッティングで新しいコードを書き足しちゃ
いけないということ。

「空白を読む」というのは、文字どおり、空白を読む
ということ。それがスペースなのかタブなのかを読み
取らなきゃいけない。

--

こういうことを「くだらないこと」という人もいるよう
だけど。そんなわけがない。ビジネス文書で乱れた
フォーマッティングで書けば叱責されるのは当たり前。
読む人に配慮するのはビジネスなら当たり前の話。

--

「コードを読む」といった場合は、設計についても
読み取らなきゃいけない。責任がどう分配れているか
ということを見なきゃいけない。

責任の分配に無頓着だと、極端な話、グローバル変数を
使うとか、そういう話になる。

OOPLならば、そのオブジェクトの所有者は誰か、その
オブジェクトの寿命はどうなっているのか、スーパー
クラスは誰か、そういうったことを知るということが、
責任の分配を見るということ。

本家Permlink


2009年09月07日

しかし、独善的な意見が多いな。まぁ、他人のことをどうこういえた身じゃな
いけど (笑)。

Awkはスクリプト言語という分野を確立した言語。POSIXにも採用されている由
緒正しいLLであり、今でも広く使われている。

これだけじゃAwkの魅力として不足なの?

一方、Ruby。一体何に腹を立てているか非常にわかりにくい。実装方法のこと
なのか、設計思想のことなのか、ドキュメント不足のことか。まぁ、そのぜん
ぶなのかな (笑)。

このへんはPerlと似てる。実際、Perlのことを嫌う人も多い。でも、Perlを好
きな人もたくさんいるんだな。まぁ、Perlもユーザに媚びてるってことなんだ
ろう (笑)。

でも、Rubyにしても、Perlにしても、言語としての正しさというものにそれほ
ど興味がないんだよね。そういう生き方を選んでるんだから、そういうヤツに
「お前はちっとも正しくない!」なんていっても「で?」って言い返されるの
がオチだろ (笑)。

--

Gaucheが評価されないのは、それがSchemeであることによる。一般人からした
らSchemeなんてドマイナーな言語だし、実装もいくらでもあるし、わざわざ今
さら取り上げる価値はない。

今振り返ってみると、GaucheはShiroさんのプロモーション・ツールだったとい
うのがマトモな評価じゃないか。Shiroさんを売り出せたのがGaucheの最大の功
績といっていい。

--

こういう言い方もできるな。「お前のやってるプロセスは全然正しくない!」

もちろん、こっちは「で?」って言い返すしかない (笑)。

プロセスの正しさよりも、今日このバグを1つ潰すことに、明日リリースする
ことに、お客さんが喜んでくれることに注力する。それは泥縄に見えるかもし
れないが、価値観や原理原則というものがブレてなければ問題ない。

--

しかし、なんでRubyみたいなマイナーな言語にカリカリすんのか、よくわから
ない (笑)。Rubyで回ってる仕事なんて、そうそうないだろう。

toRubyなんかも、ほとんどがRuby初心者だし。

ほんとに、Rubyで仕事してる人がいたら話が聞きたいわ!

というわけで、とちぎRuby会議02、「儲かるRuby」、よろしくお願いします!

http://rubykaigi.tdiary.net/20090904.html

本家Permlink


2009年09月06日

『ナンバー 736』(文藝春秋)、『野村克也「書くことで人は伸びる」』から。

p.34、野村監督所有の「ノムラの考え 2006〜」より:

                       【成長と進歩について】

  目一杯の幸せも不幸もないはずだ。腹八分目の幸せや不幸であるべきだ。あ
  との二分が成長のエネルギーになっていると考えるべきだ。

  〔成長について〕

  成長とは

  (1) 自分の間違いに気付き、それを正していくこと
  (2) 判断基準のレベルを高めること

  1. 人間的成長なくして、技術の進歩はあり得ない。選手はいずれ引退する
     ときが必ずきます。そのときに、「選手−野球=0」とならないために
     日々どう過ごしていくかを真剣に考えて、取り組んでいくべきです。野
     球をはずしたら「ただの人」にならないよう、今日一日を大事に積み重
     ねていくべきです。

  2. 現代の時代背景は「明るい」「楽しい」「わかりやすい」「おもしろい」
     が主流となっていますが、果たして人間社会にとってそれが「正しい」
     のかどうかは疑問です。人間的成長と能力の発達を根本的理念として進
     むべきです。どの分野においても真のプロフェッショナルと言われる本
     物や職人が減少してきている現実が淋しく感じられます。重い・深い時
     代から浅い・軽い時代へ移行!!

  3. 「教育」と「躾」は最も重要で、その基本は「礼」と「義」と「恥の意
     識」を身に付けることなのです。「礼」とは“おかげさまで”という謝
     意・敬意と挨拶・作法のこと。「義」とは生きていくための正しい道、
     条理・道理のこと。「恥の意識」をもつことは、人間らしくプロらしく
     成長していくためのカギとなるのです。“人間は礼に始まって礼に終わ
     る”といいます。挨拶とは「ひらく」「せまる」と読みます。即ち、
     「心を開いて相手にせまる」という意味合いのことで、コミュニケーショ
     ンの第一歩なのです。人間は「恥の意識」をもつことで、人間らしくな
     り始めるものなのです。

  4. 仕事は成長していくための手段であるから、「男一生の仕事」という観
     念で、人生観と照らし合わせ、納得できる仕事であるべきなのです

  (以降、野村監督の手がジャマで読めない (笑))

同じくp.36より。

                         【人生観と仕事観】

  野球を仕事としていく以上、野球だけに考え取り組んでいては、全く社会人
  として、職業人として失格です。仕事は当然、人生や社会や組織(企業)と連
  動しているのです。広い視野をもって取り組むべきです。現役生活は短い。
  引退後の人生の方がはるかに長いことを念頭に入れておくべきです。

  人生とは、幸せな人生を目指し努力していくものですが、満足な幸せもなく、
  またどうしようもない不幸もありません。幸も不幸も、自分自身がつくって
  いくのです。

  年に一度くらいはいろんな角度から野球(仕事)を考え、見据えて取り組むべ
  きです。いずれにしても、最低限「経験」と「知識」と「鋭い感性」は仕事
  において不可欠な要素です。

  “思考が人生を決定する”と言い切る人もいるくらい、“考え方”というの
  は生きていく上で大変重要なことです。その“しっかりした考え方”をして
  いくために、知識量を増やし、修羅場の経験を踏む必要があるのです。“思
  考”のためのエキスを大いに増やしていくべきです。

  1. 人生観を確立しない限り意義深い仕事はできない。

     充実した日々、幸福感に満ちた人生を送ることが目標であり、仕事はそ
     の目標を叶えるための最も重要な武器である以上、切り離して考えるこ
     とは不可能です。

     まず、一度や二度は「人間は何故生まれてくるか?」を考えるべきです。
     「人生」という字は「人として生まれる」「人として生きる」「人を生
     かす」「人を生む」と読むことができます。その読み方一つ一つに大き
     な意味を含んでいると思えるのです。各々が「人生をどう生きたいのか?」
     「どういう人間になりたいのか?」という根本目標をはっきりと胸の中
     に秘めて、こつこつ地道に努力していくのです。そして「幸福とは何か?」
     も同時に考えるべきで、幸福とは決して地位や財を得るだけではないは
     ずです。

     人間は思考(考え方)と感情の二大要素をもっています。すべては“考え
     方”次第であり“感じ方”次第なのです。一言でいうならば「頼れる自
     分づくり」に励むことに尽きます。

  2. 人間は「存在するため」と「生きるため」という二つの使命を背負って
     生まれてくるのです。

     即ち、「存在感」と「価値観」が問われ、評価の対象として生き続ける
     のです。もう少し詳しく言うと、「人間性の評価」と「仕事の評価」と
     言っていいと思います。人間性は、顕著に仕事ぶりに現われるものなの
     です。“人間は評価に始まって評価に終わる”と言えます。評価は、他
     人からの評価が正しいのです。自分で自分を評価すると、どうしても甘
     くなります。“評価”こそ生きていく糧である。

  3. 「希望」を抱け!!

     強い希望が自分を好循環にしてくれるのです。「人生をどう生きたいの
     か」「どういう人間になりたいのか」という強い希望を抱くことが大事
     なのです。

同じく、『「野村ノート」の正体。』から。

p.39、広澤克実氏の談話:

  「野村監督の基本的な考えは目に見えないもの、形にならないものをどう捉
  えるかということなんです。速い玉を投げる、打球を遠くに飛ばすといった
  目に見える能力は才能で限界が決まる。どんなにがんばってもイチローみた
  いにボールを捉えることはできない。でも野球はイチローがそろえば勝てる
  というものでもない。弱いチーム、才能で劣る選手が集まったチームが強い
  チームを倒すためになにをするか。駆け引き、データの活用、心理を読んだ
  攻め、そうした無形の力を駆使して有形の力で上回るチームに勝つ。それが
  野村野球の根本にある考えで、自分が教わってきた野球というものの考え方
  にはまったくないものでしたね。」

p.40、遠山奨志阪神タイガース育成コーチが所有する「ノムラの考え」より:

                          はじめに(心構え)

  世のため人のために役立っていない仕事は、まず存在しない。我々は「野球」
  という職業を選択した事実に基づき、人生の基礎や生きていくための原理原
  則を学びながら、日々を過ごしていくのである。そして「プロ野球」は、ファ
  ンなくして存続していかないという現実を直視するところから「生きる」
  「働く」「暮らす」の一組を根本として行動していくのである。「幸せな人
  生」を送ることが、永遠のテーマなのである。

  我々の仕事も、青少年に夢と希望を与え、文化に、娯楽に、街の活性化に、
  スポーツ界などに、大いに大衆娯楽として貢献しているのであるから、胸を
  張って誇りをもって、行動すべきである。

  プロ野球の原点は、当然ファンである・・・ということは、人気稼業である
  わけだから、我々の価値基準は「球場に、どれだけのお客さんを集めたか」
  にあり、そのための貢献度が我々の価値観として、決定づけられるのである。

  我々の向ける目(方向性)は、「お客さんがどれだけ感動し、満足し、グラン
  ドから去っていかれるか」というところに、常に向いていることなのだ。

  グランドと観客席との空間にこそ“生き甲斐”が存在する。ファンはエキサ
  イティングな野球を望んでいるのだ!!

  「楽しい」「おもしろい」「明るい」「わかりやすい」ということが、もて
  はやされる時代背景の中でのプロ野球だが、時代の波に押されることなく、
  厳しい実力社会・勝負の世界を生き抜いて行くべきと考える。

  要は意思の統一を計り、戦力を集中させてグランドに出れば“勝つ”ことの
  一点に全力を尽くせばよいのである。

      “優勝は強いか弱いかよりも「ふさわしい」かどうかで決まること
        が多いのだ”

p.41、楽天イーグルスの嶋基宏選手がノートに書き留めた野村監督の言葉:

  <変化に適応するには>

  (1) 物事を簡潔に捉え、柔軟な能応ですばやく動くこと。特に問題を複雑化
      しないことである。

  (2) 失敗することばかり考えて、自分を見失なってはいけない。

  (3) 小さな変化に気づくこと
      (変化には早く適応すること。遅れると適応が難しくなる)
      現実は中々そうにはいかないのが常である。
      気づくという行為が重要なポイントとなる。

※ 『能応』は本文ママです。多分『対応』のこと。

本家Permlink


2009年09月04日

  あやまちは 繰り返さない 見逃さない

先日toRubyがあったんだけど。場所はいつもの西那須野
公民館。上の標語は、そこで見つけたもの。

上の標語は獲物のほうでも紹介したけど:

http://www.moj.go.jp/HOGO/hogo06-58kai-2.html

「第59回“社会を明るくする運動”標語一般募集」
というので最優秀賞を取ったもの。このページにある
ように、この運動の主催は法務省で、更生保護法人日本
更生保護協会が後援になってる。まぁ、ぶっちゃけいうと、
犯罪者の更正を支援するということだね。

なんでそんな標語が公民館に張ってあるかというと、
土地の事情があるから。西那須野は那須塩原市にあって。
その隣の大田原市には黒羽刑務所がある:

http://ja.wikipedia.org/wiki/%E9%BB%92%E7%BE%BD%E5%88%91%E5%8B%99%E6%89%80

まぁ、ウンチクはこのへんにしといて。上の標語、ここ最近
書いてる「共有地の悲劇」にはピッタリだよね。

「繰り返さない」っていうのは、語感からすると、
「あやまちを犯した人間が誓う」っていうふうに捉え
ちゃうけど。でも、それだけじゃないと思うんだよね。
やっぱり、あやまちが繰り返されるのをみんなで防がないと
ダメだと思うんだよね。

ダメなコードがコミットされた。それを誰がコミットしたかは
簡単に調べられるし、そいつを吊るし上げることも簡単だし。
でも、そういうんじゃ、あやまちが繰り返される恐れが
あるでしょ。何がどうダメで、どうすればいいかっていう
ことをわからせないといけない。指導して、更正した姿を
見届けなきゃいけない。

まぁ、もちろん、手間かかって面倒だけど、原則的には
そういうことになる。

あやまちが見逃さられるっていうのにはいくつかパターン
みたいなのがあるけど。自分がよく書く「他人事」なんてのも
その1つだけど。同じ他人事でも、組織の枠とか、遠慮とか、
そういう事情が隠されてたりするんだよね。そういう、
組織の枠だとか、遠慮とかは、常識的には必要なものだと
思われてるんだよね。だから厄介なんだけど。

だから、そういう「常識の縛り」を断ち切って、いい
製品を作るにはどうしなきゃいけないかっていうことを
考えなきゃいけない。そのためにはマリーシアでも
寝技でも何でも使ってね。

本家Permlink


2009年09月02日1

すみません。いいすぎました。

本家Permlink


2009年09月02日

あ、リスポンてrespawnのことか。

イモスナはわからんかった。いわゆる『待ち』なスナイパーの
ことだったんね。

まぁ、FPSはやんないけどねぇ。

--

コードを共有するっていうことは、責任を共有するっていう
ことでもある。つまり、バグを埋め込んだヤツがいても、
そいつだけの責任じゃないってことなんだな。99%そいつの
責任だとしても、100%じゃない。

だから、ダメなところはお互いに善くしなきゃいけない。
それが責任ある態度っていうもんだろう。

逆に、ダメなところを見つけても黙ってたり、放っておいたり
するのは無責任な態度っていうことになる。そういう態度が
結局は『共有地の悲劇』を生むことになる。

--

共有地の悲劇を防ぐのは大変なんだよな。組織や文化の
枠を超えなきゃいけないんだから。波風も立つし、軋轢も
生まれる。

それでもやんなきゃいけないんだよ。自分らはプログラマ
なんだから。

まぁ、そのへんは腹くくるしかない。

--

Linusにしても、Theoにしても、クチは悪いんだけど、
それは共有地の悲劇を本能的に知ってるからだと、
好意的に解釈したい (笑)。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails