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

ホーム

2007年03月31日

この、ボンバルヤロー!

本家Permlink


2007年03月30日

殺伐とした職場が好きな人もいるでしょうけど。でも、
自分は、みんなが生き生きと働いてほしいと願ってるん
です。XPだなんだいっても、結局はそれに尽きるんです。

『生き生きと』っていうのは、単純に楽しいっていうの
とはちょっと違ってて。難しい問題にぶつかったら、
みんなで悩んで、それを乗り越えたら、みんなで喜んで。
退屈な作業だったら、グチの1つでもこぼし合って。そう
いう喜怒哀楽みたいなものをみんなが感じながら仕事を
してほしいっていうことなんです。

『上からいわれたから (イヤイヤでも) やるんだ』とか、
『自分のとこだけ動きゃいいや』とか、そういう、
ロボットか何かのような働き方をしてほしくない。

生き生きと働けば、いいアイデアが生まれるんです。
生き生きと働けば、よりよく仕事をしようとするもん
なんです。人間が生きるっていうのは、そういうこと
なんですから。人間が生きるっていうのは、学習や
向上、そういったものとは切り離せないんですから。

本家Permlink


2007年03月29日2

ツッコミでも書きましたけど、昨日の例題は『プログラ
ミング言語Awk』からのものです。

昨日のデータ・ファイルをもう一度:

USSR	8649	275	Asia
Canada	3852	25	North America
China	3705	1032	Asia
USA	3615	237	North America

上のはタブ区切りのデータです。

で、Awkの本では、上のデータを見出しと合計をつけて
印字するサンプルが紹介されています:

BEGIN {
  FS = "\t"
  printf("%10s %6s %5s  %s\n\n", "COUNTRY", "AREA", "POP", "CONTINENT")
}
{
  printf("%10s %6s %5d  %s\n", $1, $2, $3, $4)
  area = area + $2
  pop = pop + $3
}
END { printf("\n%10s %6d %5d\n", "TOTAL", area, pop) }

んで、まずは見出しを印字します:

def print_head
  printf("%10s %6s %5s  %s\n\n", "COUNTRY", "AREA", "POP", "CONTINENT")
end

んで、国オブジェクトの配列を受け取って印字します:

def print_countries(countries)
  countries.each do |country|
    printf("%10s %6s %5d  %s\n",
           country.name, country.area, country.population, country.continent)
  end
end

んで、合計なんですけど、自分は最適化は嫌いですから、
1つずつ。まず面積の合計:

def calc_total_area(countries)
  result = 0
  countries.each do |country|
    result += country.area
  end
  return result
end

メソッドの名前がこれでいいかちょっと悩みますけど、
他に思いつきません。んで、次に人口:

def calc_total_population(countries)
  result = 0
  countries.each do |country|
    result += country.population
  end
  return result
end

こういうのが続くと、なんか自分がバカに思えてくるん
ですけど、幸いこれで打ち止め。で、2つの合計を印字
します:

def print_total(countries)
  area = calc_total_area(countries)
  pop = calc_total_population(countries)
  printf("\n%10s %6d %5d\n", "TOTAL", area, pop)
end

if $0 == __FILE__
  countries = read_countries(ARGV[0])
  print_head
  print_countries(countries)
  print_total(countries)
end

ここまで来ると、なんか印字するオブジェクトがいても
おかしくない気がしてきます。オブジェクトはコードに
埋まってるんですね。で、Printerというオブジェクトを
掘り出します:

class Printer
  def initialize(countries)
    @countries = countries
  end

  def print
    print_head
    print_countries
    print_total
  end
  ...
end

メソッドにいちいちcountriesを渡すのは面倒なので、
コンストラクタで渡すことにしました。全体の処理は:

if $0 == __FILE__
  countries = read_countries(ARGV[0])
  Printer.new(countries).print
end

という形になります。

最初のAwkの例だと10行で済んだんですけど、それを
自分がRubyで書き直したら70行を超えてしまいました (笑)。
(コードは下に置いときます。)

まぁ、Awkの例も、関数をいくつか切り出そうと思えば
切り出せますから、単純に7倍強ということもないで
しょうけど。でも、『オブジェクト指向ってそんなもん』
ということもできるんですよね。紙を切るのにチェーン
ソー持ち出すこともないわけで。自分は好きですから
ここまでやっちゃいますけど、多分、白い目で見るプロの
ほうが多いでしょうね (笑)。

--

そもそも自分の今のテーマが『The やりすぎ』だという
のは書きましたね。

--

ああ、inject使えるのか。

--

XP的な答えでは『良い習慣を身につけたプログラマ』が
優秀なプログラマということになりますね。でも、これは
多分、世間一般でいう『優秀なプログラマ』像とは違うん
でしょうね。

でも、やっぱりむつかしいですよね。素人と玄人とでも
判断が違うでしょうし。Wikiみたく単純な実装であり
ながら社会的に大きな影響を与えたりとか、あるわけじゃ
ないですか。そういうのは玄人は『優秀』と認めたがら
ないじゃないですか。じゃなきゃテトリスの人とか。
そういう人も自分は優秀なプログラマだと思うんですけど。
『一発屋』みたく思われちゃうんですかね (笑)。

--

そういう意味では、やっぱり結果なんですかね。

というわけで、『やりすぎ』重要 (笑)。

--

ああ、そういえば『Rubyなんか全然新しいものがないじゃ
ないか』ってエラソゲに語るヤツなんかも同じクチか。

『エラソゲに』っていうのがポイントね (笑)。

--

class Country
  def self.newByLine(line)
    name, area, population, continent = line.chomp.split(/\t/)
    return Country.new(name, area.to_i, population.to_i, continent)
  end

  def initialize(name, area, population, continent)
    @name = name
    @area = area
    @population = population
    @continent = continent
  end
  attr_reader :name, :area, :population, :continent

  def to_s
    return sprintf('Country{name=%s, area=%d, pop=%d, conti=%s}',
                   @name, @area, @population, @continent)
  end
end

def read_countries(filename)
   return File.readlines(filename).collect{|line| Country.newByLine(line)}
end

class Printer
  def initialize(countries)
    @countries = countries
  end

  def print
    print_head
    print_countries
    print_total
  end

  def print_head
    printf("%10s %6s %5s  %s\n\n", "COUNTRY", "AREA", "POP", "CONTINENT")
  end

  def print_countries
    @countries.each do |country|
      printf("%10s %6s %5d  %s\n",
             country.name, country.area, country.population, country.continent)
    end
  end

  def calc_total_area
    result = 0
    @countries.each do |country|
      result += country.area
    end
    return result
  end

  def calc_total_population
    result = 0
    @countries.each do |country|
      result += country.population
    end
    return result
  end

  def print_total
    area = calc_total_area
    pop = calc_total_population
    printf("\n%10s %6d %5d\n", "TOTAL", area, pop)
  end
end

if $0 == __FILE__
  countries = read_countries(ARGV[0])
  Printer.new(countries).print
end

本家Permlink


2007年03月29日1

だからね、P.Graham氏がLispを超えて活躍してるように、
会長にもRubyやRailsの枠を超えて活躍してほしいのよ。
高橋メソッドに留まることなくね。

世の中に会長をインジェクトしろと。KI。

--

貼りつける画像なんかはデザイナが作ったりもしますけど、
ボタンの配置とかそういうのは、大抵は、プログラマが
責任を持ってやりますよね。で、そういうのもUIの大切な
要素であって、そういうのがたくさん集まってアプリの
使い勝手というものが決まるわけで。そういうわけで、
やっぱりアプリの使い勝手っていうのは、プログラマが
どれだけ配慮するかで決まるわけです。

こういうことをいってもなかなかみんなに伝わらない。
なんか他人事としてしか受け止めないんですよね。
どうにかならんのか。

本家Permlink


2007年03月29日

だから、会長ほどの人物が、コマネズミがごとく
あくせくと働いてるのは日本にとって大きな損失だと。

筆も立つしシャベリもいけるんだから、もっと著述とか
啓蒙とか、より大勢の人に影響を与えるような活動を
中心にしていただきたい。

いや、会長は会長で抱く野望があるんなら、それはそれで
結構なことなんですが、自分勝手をいわせてもらえば、
自分は、単純に、会長の考えてることを知りたいと。
そして、それが自分以外の大勢の人のためにもなると
思う次第です。

本家Permlink


2007年03月28日1

プロマネあなたはかよわき顧客の代弁者なのか
あと何度マイルストーン延期すれば
本当のリリースにたどりつけるだろう
おーおおおおー
このプロジェクトからの卒業
デスマーチからの卒業

--

シーズンやからね。

--

USSR	8649	275	Asia
Canada	3852	25	North America
China	3705	1032	Asia
USA	3615	237	North America

みたいなファイルがあったとして、自分がまず真っ先に
思い浮かべるのは、当然として『国』という単位です。
だったら、それをそのまんまクラスにしちゃう:

class Country
  def initialize(name, area, population, continent)
    @name = name
    @area = area
    @population = population
    @continent = continent
  end
end

で、次に、1行喰わすとCountryオブジェクトを作る
ファクトリ・メソッドを作る:

class Country
  def self.newByLine(line)
    name, area, population, continent = line.chomp.split(/\t/)
    return Country.new(name, area.to_i, population.to_i, continent)
  end
  ...
end

で、あとはテキスト・ファイルを読み込むところを
書けば、インフラとしてはほぼ終わり:

def read_countries(filename)
   return File.readlines(filename).collect{|line| Country.newByLine(line)}
end

別に難しくないでしょ? ただ、オブジェクトを使うか
どうかは別にして、『国』という単位に気づくかどうか
がポイントなわけです。国という単位に気づいてたら、
別にハッシュで表現したって構わないわけです:

def line_to_country(line)
  name, area, population, continent = line.chomp.split(/\t/)
  return {
    :name => name,
    :area => area.to_i,
    :population => population.to_i,
    :continent => continent
  }
end

def read_countries(filename)
   return File.readlines(filename).collect{|line| line_to_country(line)}
end

だから、オブジェクト指向っていうのと、いわゆる手続き
指向っていうのは、そんなに距離のあるもんじゃないん
です。

オブジェクトを使ったほうが、より『Rubyらしい』と
いうことはできるかもしれませんけど (Rubyは『オブ
ジェクト指向スクリプト言語』ですから)、下のだって
別に悪くないですよね。chomp, split, to_i, readlines,
collectと、結構オブジェクトの恩恵を受けてるわけです。

--

class Country
  def self.newByLine(line)
    name, area, population, continent = line.chomp.split(/\t/)
    return Country.new(name, area.to_i, population.to_i, continent)
  end

  def initialize(name, area, population, continent)
    @name = name
    @area = area
    @population = population
    @continent = continent
  end

  def to_s
    return sprintf('Country{name=%s, area=%d, pop=%d, conti=%s}',
                   @name, @area, @population, @continent)
  end
end

def read_countries(filename)
   return File.readlines(filename).collect{|line| Country.newByLine(line)}
end

if $0 == __FILE__
  countries = read_countries(ARGV[0])
  countries.each{|country| puts(country)}
end

本家Permlink


2007年03月28日

自分らの世代でも「すぅぱぁ」にはチープな感じを
受けるのになぁ。

本家Permlink


2007年03月27日1

いや、自分の場合は、止むに止まれずというか、自分
自身が平凡でもあるし、そうすると自然と平凡な人たちと
仕事をすることになるわけで。革命を起こしたいとか、
そういう高邁な理想に燃えてるわけじゃないんです (笑)。

『Googleに勝つ』といっても、いろんな勝ち方がある
わけで。総資産じゃ明らかに勝てるはずもないし、じゃあ、
どこで勝負するかっていうのを考えようじゃないかって
話ですよね。

だから、『天才の集団』っていうのが正論なら、『組織の
力は天才を超える』っていうのも正論で。自分が目指して
るのは、後者に近いといえば近いんですけど、もっと
邪道というか。

組織の中の個の力なんですね、やっぱり。

組織というと何か『立派な指導者がいて・・・』みたいな
ことを連想しがちですけど、そうじゃない。

結局、『あなた』であり、『わたし』であると。

『わたし』が変われば『あなた』も変わる。『あなた』が
変われば『わたし』も変わる。

そういう自覚を持った平凡な人たちが、平凡な努力を
積み重ねることで、何かマジックのようなものが起こるん
じゃないかと期待してるわけです。

こんな雲をつかむような話で、自分でもバカだなぁと思い
ますけど、でも、『ナポレオンをたくさん集めよう』って
いうGoogleだって、かなりおバカでしょう。でも、Googleは
それを実際にやってるわけでね。

--

やっぱり、publicとかprotectedとかprivateとかは幻想
かもしれんなぁ。

本家Permlink


2007年03月27日

マインドマップの使い方を誤解してました。マインド
マップっていうのは、アイデアを出す手段だとばかり
思ってました。それはそれでマインドマップの効果では
あるんですけど、それだけで終わりじゃない。見える化
されたアイデア群は全体像でもあるわけで、そのアイテム
1つ1つがゴールにもなる。どこまでのアイデアが実現
できていて、何がまだ実現できていないのか。そういう
ことをチェックするためにもマインドマップは使えると
いうこと。

--

やっぱり高度を意識することは大切なんですよね。自分ら
プログラマは、低い位置で作業することが多いですから、
視線も低くなりがちなんですけど。システム全体、プロ
ジェクト全体、スケジュール全体、そういった高い位置
からの視点っていうのを常に持ってないといけない。

--

だから結局、プロジェクトを成功させるための活動の1つ
としてプログラミングがあるということなんですよね。
「自分の担当しているところが実装できたらいいや」じゃ
なくって。自分の仕事を全うするのは当然だとして、
それを超える気持ちを持ってなきゃいけない。それは
マネージャや上級職とか関係なく、プロジェクトのメンバ
みんなが持ってなきゃいけない。

本家Permlink


2007年03月26日2

オッチャンも反省した。やっぱりデバッガをうまく使い
こなせるというのは非常に重要。

『コードに聞け』とか『システムに聞け』っていうのは、
(デバッガを噛ませずに) 実際に動かして見るっていう
意味もあるんだけど、デバッガを噛ませて動きを見るって
いうのも当然『あり』なわけだ。

まぁ、言い訳をさせてもらえば、Javaにしても、Rubyに
しても、使いやすいデバッガがなかったというのがある。
もちろん、今は当時と事情が違うだろうけど。

ユニット・テストを書けばデバッガで追う必要がなく
なるというわけでもない。どちらかというとユニット・
テストとデバッガというのは相補的なもの。ユニット・
テストで問題をあぶり出してデバッガで追ったり、
デバッガで追ってユニット・テストの材料を見つけたり。

デバッガを頻繁に使うと、なんか泥縄っぽい感じがして
イヤなんだけど (笑)、それはユニット・テストで打ち
消せる。

本家Permlink


2007年03月26日1

そういう意味では、ブックマーク文化っていうのは
褒める文化なんですよね。もちろん、獲物もそうです。

--

状況が複雑化していくにもかかわらず、一定のペースを
保てているのはスゴイことなんだという話でした。

歩いてるほうからすると、一定のペースだと「遅いん
じゃないかなぁ」とか不安に駆られるもんだけど、道が
どんどん荒れてくるにもかかわらず、1日に進む距離が
変わらないっていうのは、実質歩く速度が上がってるんだ
ということ。

--

失敗を見つけるのも大変なんだよなぁ。失敗なくして
成功ないわけで。

というか、滞りなく流れているプロジェクトでは、
「なぜ滞りなく流れているか」っていうのを意識する
人は少ないわけで。それはそれでいいっちゃいいんだけど、
誰かがもし他のプロジェクトに移ったときに、その「滞り
ない流れ」っていうのを再現できなきゃいけないわけで。
そのためにも「なぜ滞りなく流れているか」っていうのを
みんなが意識する必要がある。

本家Permlink


2007年03月26日

そういやぁ、OMGってOODBにも力入れてなかったっけ?
なんか標準のクエリ言語作るだなんだいってなかった?

で、結局今、どうなんってんだよ。OODBが騒がれたころ
よりRDBがしっかり普及してて、RDB全盛といってもいい
くらいじゃねぇか。Javaが『COBOLの後継』って揶揄され
てんのは、そういう背景もあるからだろ?

結局さ、標準なんてもんは、リファレンス実装がなきゃ
ダメなんだよな。それをインターネットが証明してるん
だし、Javaもその亜流だっていえる。C++にしたって
Boostがなけりゃ、奇跡的な復活もなかったろうし。

だから、モノを作らねぇヤツらが集まって標準ごっこ
なんて、ちゃんちゃらだってこった。

--

やっぱり、RDBが選ばれるっていうのは、いろんな要因が
あるんですよね。RDBを使った開発手法がある程度確立
されているとか。RDB自体の実装方法も枯れていて、いい
ところと悪いところがよく知られているとか。人手を手配
しやすいとか。タダの実装が結構高い品質で提供されて
るとか。みんなが使ってるから安心感があるだとか。

自分は別にRDBは嫌いじゃないですよ。OODBなんて使った
ことありませんし。

本家Permlink


2007年03月25日

おっと、くわばらくわばら (笑)。

自分は資格を全面的に否定するつもりはありません。
実際、取るのは結構大変ですし。

でも、資格を取って誰が喜ぶか、誰に利するかというと、
やっぱり会社でしょう。しかも人月商売やってる会社。

これはこないだもちょっと書きましたけど、この業界でも
偽装派遣や偽装請負なんかが騒がれていますよね。で、
偽装かどうかの判断基準の1つが『技術を提供しているのか、
それとも単純労働を提供しているのか』という点です。
(現実問題としては、これはそれほど重要な判断基準では
ないようですけど。) で、資格があれば『技術を提供して
いる』と言い張ることができるという寸法です。

人月商売っていうのは、派遣とか (SES契約も含めた)
下請けですよね。だから、資格を取るっていうのは、
将来派遣や下請けやりたいといってるのと同じような
もんなんです。

下請けはともかく、派遣が悪いっていうわけじゃない
ですけどね。でも、フリーで働くとして、そのとき重視
されるのは第一に実績でしょうし、資格なんてのは二の
次、三の次でしょう。

『資格を取る』というのは旧来の業界の常識です。そんな
ものは会社に利するだけで、個人にはあんまり役に立た
ない。そんなものよりも、自分で人のつながりを広げる
ほうがよっぽど自分の利になります。

だから、技術者は外に出ないとダメなんですね。それは
現実世界でもネットでも構わないから。こういう人の
つながりっていうのは築くまで大変なんですけど、築け
たら、資格なんかよりはるかに頼りになる。

『外に出る』っていうことは、自分をさらすっていうこと。
やっぱりリスクを取らなきゃダメですよね。リスクを取ら
ない人は、誰からも信頼されませんから。それじゃぁ人の
つながりなんか築けるわけがない。

資格を取れば給料が上がるとか、そういう直接的な
メリットがあるならともかく、『なんとなく資格でも
取ってみようかなぁ』じゃダメ。資格マニアなら別です
けど。

--

そういえば、こないだ自慢気にカード見せられまして。
何かと思ったらUML検定のカード。見て、思わず笑っちゃい
ました (笑)。そのあとを取り繕うのに苦労しました。

何? OMGの今の存在価値ってこれか? これだけか?
ご立派な標準化団体様ですなぁ。テメーらはロクスポ
OOPの普及に貢献しなかったくせに。実際に普及させたのは
Javaと草の根から生まれたデザイン・パターンじゃねぇか。

--

梅田さんのページとか、はぶさんのページとかを見せたりも
するんですけど、反応が薄くってビックリしちゃいますよ。
聞いてみると『「ああ、こういう人もいるんだなぁ」と
思った』だって。

ガックリですよ。

自分は今の会社に拾われたんで、それに恩義は感じるけど、
それ以上のものは何もないんだよね。2、3年、安い給料で
働きゃぁ、それでチャラだと思ってるし。ぶっちゃけ、明日
潰れたって構わねぇんだから、こっちは。

でもさ、君らは違うだろ? ニョーボコドモもいるんだし。
だったら、もっと危機意識持ったほうがいいんじゃないの?
SIerの未来なんて明るくないぜ? 特に人月商売やってる
ようなとこは。

日々の仕事に追われて忙しいのは同情するけど、でも、
それだって自分でコントロールできるようにしなきゃ
ダメだろ? そういう努力が明日につながるんだろ?

ほんとに、ゆーだけベンチャーなんだからな。

--

いくら自分のテーマが『すべてを巻き込み、すべてに
巻き込まれる』っつっても、イヤなものはイヤ (笑)。

本家Permlink


2007年03月24日

http://hochi.yomiuri.co.jp/battle/fight/news/20070324-OHT1T00100.htm

あちゃー。

本家Permlink


2007年03月23日2

ぶっちゃけ、gonzuiってorphanなんでしょ?

ハッカーは大抵飽きっぽいからなぁ (笑)。

--

スケジュールというのはちょっと誤解を生むかな。
とりあえず時間の制約を抜きにして、どういう手順を
踏むかっていうこと。どういうコースを通って、
どういうマイルストーンを通過していくかっていう
こと。

もちろん、コースの選び方とかでスケジュールに影響は
出るんだけども。それよりも、そのコースで、その
マイルストーンで目的地にたどり着くことができるか
どうかっていうことが大切なんじゃないかな。

本家Permlink


2007年03月23日1

やっぱりさ、いわゆる分析/設計といわれる設計が
ダメなのは、時間軸が考慮されてないからなんだよな。
いってみれば、設計という活動がスケジュールと切り
離されちゃってる。それじゃあダメなんだよな。だって、
スケジュール (あるいは計画) っていうのは、設計なんか
よりも重要なんだから。予定が立つ、立たないっていう
のは、組織活動として死活問題でしょ。

だから、ゴールとしての設計図がほしいんじゃなくって、
ゴールへの地図がほしいわけだ。ゴールはある程度あや
ふやでも構わないけど、時間軸に沿ってどういう方向に
進むかっていうのは決めなきゃいけない。もちろん、
途中で方向が変わることもあるかもしれないけど。

本家Permlink


2007年03月23日

まぁ、世の中にはつまんない、ムダな会議も多いんだけど。

でも、実際、会議を面白くできないのは、自分のせい
だったりするんだな。会議に参加できてなけりゃ、そりゃ
つまんないと感じるのは当たり前だ。

なぜ参加できてないのか。それは全体が見えていないから
だろう。

『全体』っていうのは2つの意味があって、1つはプロジェ
クト全体、もう1つは会議全体。

プロジェクト全体が見えてなけりゃ、他人の話に興味が
持てない。でも、そこで全体を見ようとする努力は必要
だよな。他人の話でも、わからないことがあったら尋ねて
みるとか。

会議全体っていうのは、出席者の顔色っていうこと。
眠たそうなヤツがいたら話を振ってみるとか。グダグダ
続いてる話題をサッサと終わらせるとか。

充実した会議っていうのは、参加者の多くに益するものだ。
一人か二人くらいにしか益するものがなかったら、わざ
わざ会議を開くまでもない。だから、参加者のできるだけ
多くの人に『ためになる』話題を振ることが大切だ。

『振り』がうまければ、あとは振られた人が勝手にしゃ
べってくれる。で、その間にまた新しい『振り』を見つけ
ればいい。

プログラマの本業っていうのは、やっぱりコードを書く
ことなんだけど。でも、頭っから『会議はつまらないもの』
と決めてかかるのはどうだろう? 集団で作業してるん
だから意思疎通は必要だし、その必要性を過小評価しちゃ
いけないよな。

『会議のせいで仕事がロクに進まない』っていうのはよく
聞くセリフだけど、それってやっぱり『自分さえよければ』
って話でしょ? もちろん、ムダな会議じゃなければ、の
話だけど。だから、ムダな会議にしないためにも自分が
参加するわけ。ムダな会議だったら止めることも必要だし。

会議も仕事のうちだぜ。

--

つかさー、毎週やってるんだから、それくらい勘定に
入れろや (笑)。

--

ああ、会議の時間は見積もりには入れないんだろうな、
やっぱり。でも、スケジュールには入れなきゃいけない
わけか。見積もりはネットで、スケジュールはグロスか。

本家Permlink


2007年03月22日

http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%83%E3%83%95%E3%83%90%E3%83%AB%E3%83%88

そんなもん、「ギド」に決まってるべ。

本家Permlink


2007年03月21日

む。カルビーのオニオンリング、うまい。

--

ちょっとここ見てほしいんだけどさ:

http://www.mt-rainier-cl.com/

森永乳業がやってる『マウント・レーニャ』っていう
ブランドのサイトなんだけどさ。ここのトップ・ページがさ、
全面Flushなのね。

ほんとに、こういうページ作る業者は死ね。そして生き返るな。

仕事場で見ようとしたら『Flush入れてください』って
いわれて、『しょーがねーなー』って思いつつFlush
入れようとしたら、入れられなかったんだよね。で、Flushが
ないと全然先に進めない。あんまり詳しく調べる気にも
なれなかったから、それで見るの止めちゃったんだよね。

Webの基本はHTMLだろ! そんなのはWeb2.0だろうが3.0
だろうが変わんねぇんだよ。Flushなんて一社独占の
テクノロジーに、ITと全然関係ねぇ森永が頼ってどうすん
だよ。

隣のヤツに『最近これがお気に入りでさー』とかいって
ページ開こうとしたら全然先に進めない空しさをお前は
わかってるのか?!

となぐり書きしつつ、マウント・レーニャ・プレミア 芳醇
ラテを飲むのであった。

--

そういえば『リファクタリング入門』読んでたら、今は
@Overrideっていうアノテーションがあるんですね。
自分も、こういう機能がほしいと思ったことがあります。
なんか、Javaらしい機能ですよね。

自分がモックを使ったテストを知ったとき、悩んだことが
あって。それは『動的言語にモックは危ないんじゃない?』
ってことでした。

一般的には、動的言語のほうがモックには向いているって
いわれてます。モック・オブジェクトの型がモデル・
オブジェクトの型の制約を受けないから。でも、モックと
モデルの型が全然別物でも構わないっていうことは、下手
したらモデルにある必要なメソッドをモックが実装して
ないってこともありえるわけですよね。

まぁ、こういう心配は大抵は杞憂なんですけど。テスト
実行すればすぐわかることですから。そして、テストは
頻繁にやりますし。

ただ、『ほんとにオーバーライドできたかな?』って
心配に思うのも事実ですし、@Overrideをつけることで
ドキュメントとしての価値も上がります。

でも、まぁ、自分はそれほど使う気にはならないですね。
Javaらしいとは思いますけど。

本家Permlink


2007年03月20日1

いや、ほんっとに、C++は生い立ちが不幸すぎる。

なんでか知らないけど実行すると落ちる。よく見たら
継承のpublic抜かしてた。

どうもvirtualが決定的に重要なときがあるらしくって、
それがないとdynamic_castできないらしい。

だから、そんなことで悩みたくねぇっての (笑)。

--

そう、自分らはServiceLocatorを選んだんだ。それは
それで悪くない。マーチンもそういってるしね。DIは
自前で仕掛けを作るのは大変だし。

問題なのは、それがServiceLocatorだと気づいてなかった
ってことなんだな。ただのグローバル変数の集積場所と
してしか使ってない。

ServiceLocatorは、サービスを切り替えられるからこそ
わざわざ名前をつける価値がある。

まず、サービスがある:

class HelloService {
public:
    virtual void hello() { cout << "hello, world" << endl; }
    ...

そしてそのサービスを配るサービスロケータがいる:

class ServiceLocator {
public:
    virtual HelloService* getService() {
        if (!service) service = new HelloService();
        return service;
    }
    ...

で、自分らのアプリはCWinAppとサービスロケータという
2人の親を持つ:

class MyApp : public CWinApp, public ServiceLocator {
    ...

さて、ここで、HelloServiceのモックを使ってテスト
することにしよう。まずはサービスのモック:

class HelloMock : public HelloService {
public:
    virtual void hello() { cout << "hello, universe" << endl; }
    ...

サービスロケータもテスト用のを作る:

class MockLocator : public ServiceLocator {
    virtual HelloService* getService() {
        if (!service) service = new HelloMock();
        return service;
    }
    ...

おまけにアプリ自体もテスト用のを用意する:

class MyTest : public CWinApp, public MockLocator {
    ...

サービスを使いたい人は、グローバルな関数でアプリを
取得する。本番環境なら:

MyApp theApp;
CWinApp*
GetWinApp()
{
    return &theApp;
}

テスト環境なら:

MyTest theApp;
CWinApp*
GetWinApp()
{
    return &theApp;
}

というふうに。

さて、ここで注意したいのは、サービスを使うところで、
それが本番環境なのか、テスト環境なのかを書き分けたく
ないということ。

その答えがこれ:

    virtual void doit() {
        ServiceLocator* locator = dynamic_cast<ServiceLocator*>(GetWinApp());
        HelloService* service = locator->getService();
        service->hello();
    }

まじめにやるんならインタフェース抽出するところなんで
しょうけど、面倒だからそのまんまサブクラスにしました。
サービスを実際に使うとこでは、そのサービスロケータが
本番用なのかテスト用なのか気にしません。さらにその
ロケータからもらうサービスも、それが本番用なのかテスト
用なのか気にしません。

実際に仕事でこれやってて、何度も落ちたんです。で、
『なんか落ちるんだけど・・・』っていってC++をよく
知ってる人に見てもらったら、dynamic_castを使うんだと
教わりました。感謝。

下に全部のソースを載せます:

#include <iostream>

using namespace std;

class CWinApp {
public:
    CWinApp() {}

    virtual ~CWinApp() {}
};

class HelloService {
public:
    HelloService() {}

    virtual ~HelloService() {}

    virtual void hello() { cout << "hello, world" << endl; }
};

class ServiceLocator {
protected:
    HelloService* service;

public:
    ServiceLocator() : service(0) {}

    virtual ~ServiceLocator() { if (service) delete service; }

    virtual HelloService* getService() {
        if (!service) service = new HelloService();
        return service;
    }
};

class MyApp : public CWinApp, public ServiceLocator {
public:
    MyApp() {}

    virtual ~MyApp() {}
};

class HelloMock : public HelloService {
public:
    HelloMock() {}

    virtual ~HelloMock() {}

    virtual void hello() { cout << "hello, universe" << endl; }
};

class MockLocator : public ServiceLocator {
public:
    MockLocator() {}

    virtual ~MockLocator() {}

    virtual HelloService* getService() {
        if (!service) service = new HelloMock();
        return service;
    }
};

class MyTest : public CWinApp, public MockLocator {
public:
    MyTest() {}

    virtual ~MyTest() {}
};

// MyApp theApp;
MyTest theApp;

CWinApp*
GetWinApp()
{
    return &theApp;
}

class Client {
public:
    Client() {}

    virtual ~Client() {}

    virtual void doit() {
        ServiceLocator* locator = dynamic_cast<ServiceLocator*>(GetWinApp());
        HelloService* service = locator->getService();
        service->hello();
    }
};

int
main(int argc, char* argv[])
{
    Client client;
    client.doit();
    return 0;
}

コメント・アウトしてるtheAppのところを
入れ替えるだけで、テスト用と本番用とを
切り替えられる。

本家Permlink


2007年03月20日

いや、自分は、「女性が論理的思考に弱い」なんて、
ちっとも思ってないですよ? いや、ほんとに。

ほら、やっぱり、読者様っていうのがいるわけで。
その読者様方に楽しんでいただくための方便というか
レトリックとしてああ書いただけでね。いや、ほんとに。

--

ダジャレ評論家ならば、すべてのダジャレに愛を持って
接するべきでは?

やっぱ褒めないと (笑)。

本家Permlink


2007年03月19日1

(くどいから割愛)

まぁ、ヘッジするのも悪くないでしょうし、自分のやり方を
誰にでも勧めるわけじゃありませんけど。でも、やっぱり
生き残ってる人を見てると、全部賭けてる人が多い (笑)。
流行る/流行らないとか、そういう理由よりも、好き/
嫌いで決めてる人っていうか。面白いかどうかを重視する
っていうか。

だから、ニッチなもの、あまりにもニッチなものを好きに
なっちゃったら、あきらめるしかないんですね (笑)。
まぁ、好きで選んだんだから、あきらめもつくってもん
でしょう。

でも、Haskellの本が出るくらいですから、やっぱりどう
転ぶかわからないもんです (笑)。

--

でも、そういうなら、カッコに拒絶反応がなければLispを
拒む理由はないってことになるんですよね。実際、自分は
カッコがイヤってことはないです。でも、Lispを選ばない
のは、なんでなんでしょうね。自分でもよくわかりません (笑)。

ただ、Lispには憧れみたいなものは持ってるんですけど。
だからShiroさんとことかたまにチェックしてるわけです。

何回か書いてますけど、自分にとってLispっていうのは、
実装の対象という面が強いんですよね。使うより作って
みたいっていう。そういう気になる言語っていうのは、
LispかForthくらいのものでしょう。もちろん、立派な
処理系を作りたいとかそういうのじゃなくってね。

あと、なんとなく『歴史の重み』みたいなのもちょっと
感じますね。C言語なんかだと、もう実利一辺倒ですし、
そんなことは全然感じないんですけど。

でも、歳喰うと淡白になるっていいますし、そうなると
LispかCってことになるんですかね (笑)。そうすると、
これからのLispのターゲットは粋Zなプログラマか (笑)。
『青二才禁止!』とか (笑)。
『今日の写経〜SICPから〜』とか (笑)。

--

でも、真面目な話、シニア層は狙い目じゃないすかね。
最近のガキはゲームは買うもんだと思ってて、自分で
作るってことを知らないし。シニア層だったら、雑誌で
16進ダンプ打ち込んだりもしてたでしょう。そういう人
たちはLispに結構抵抗ないんじゃないすかね。

そのころってば、BASICが当たり前で、CやPascalに
混じってLispも結構注目されてたじゃないすか。
『青春よ再び!』みたいな感じで、Z-Lisper、どっすか?

とりあえず、Webページの文字をデカくするとこから
はじめますか (笑)。

--

もう1つの懸念事項が女性なわけですが。なんでもラブ
アンドベリーというゲームが大流行しているそうで。
やっぱりSEGAは侮れない (笑)。

上の記述と矛盾するようですが、これをきっかけに少し
でも多くの女性プログラマが育ってくれることを願わずに
いられません。

いや、ほんとに、こういうブームは侮れないのよ。
囲碁だって『ヒカルの碁』でウハウハだったんだから。

やっぱり底辺が広くないとダメなのよね。

--

しかし、このゲーム、どう見ても小中学生がターゲット
だよな。あざといっちゅーか、ロコツっちゅーか (笑)。

--

独断と偏見でいわせてもらえば、プログラマが女性に
向かないなんてことはないのだ。

独断と偏見でいわせてもらえば、女性は文字を書くのが
好きだ。それはすなわちコーディングと同じだ。

独断と偏見でいわせてもらえば、女性はチマチマ作るのが
好きだ。それはすなわちXPでいうところのBaby Stepだ。

独断と偏見でいわせてもらえば、女性は清潔好きだ。
それはすなわちバグが少ないことにつながる。

独断と偏見でいわせてもらえば、女性は勘に優れている。
それはすなわちデバッグにも優れているということだ。

独断と偏見でいわせてもらえば、女性は安定が好きだ。
それはすなわちテストが好きだということだ。

独断と偏見でいわせてもらえば、女性は気配り上手だ。
それはすなわちチーム活動を円滑に進めることにつながる。

独断と偏見でいわせてもらえば、女性は論理的思考が
苦手だ (といわれている)。それはすなわち単純に問題を
解くことにつながる。

これほど肯定的な要因があるというのに、なぜ女性の
プログラマが少ないのか。

もっと職場に女性を!

そして我々に出会いを!

--

こういうことは、けっこう意を決して書いているわけです (笑)。

本家Permlink


2007年03月19日

あのくらいのことを書くのに「意を決する」覚悟がいる
というのもヘンな気がします。そんなこといったら、
このページなんて (笑)。

まぁ、野良犬だから (笑)。

本家Permlink


2007年03月16日1

いや、finally云々はあんまり関係ないか。

結局のところ、メモリというのは資源と呼ぶには
ありふれすぎてるんじゃないか。それをスタック
だけで賄うのは無理だし、かといって人間がやる
のも面倒。

--

自分が梅田さんの記事を獲物に貼ったのは、Googlerが
どうこうじゃなくって:

  ベンチャーは「人」がすべてである。どんなベンチャーにも「勝利の方程式」
  など存在せず、日々苦しみながら軌道修正を続けていく日常では、本当に
  「人」「チーム」がすべてである。

の部分だから。で、自分は、これはベンチャーに限った
ことじゃないと思ってるんですね。特にソフトウェア
開発は、人の問題の占める割合が大きい。だって、
いってみれば脳汁を売ってるわけですよ、自分たちは。
自分たちの脳ミソから搾り出した汗を売ってるわけですよ。
そりゃあ、人の問題ってことになるでしょう。

本家Permlink


2007年03月16日

GCは例外使うときに便利か?

ただ、C++の場合、finallyがないから、それほど
でもないかも。

本家Permlink


2007年03月15日1

仕事には『引き継ぎ』というものがあります。で、当たり
前ですけど、引き継ぎの主役というのは『引き継ぐ人』
なんですね。去る人ではない。

日本では『立つ鳥あとを濁さず』とよくいわれます。去る
人の気持ちとしても、できるだけキリのいい形で去りたい
と願うものです。でも、去るまでに残されている時間は
限られています。であるならば、引き継ぐ人に現状を
ありのままに理解してもらうことのほうが大切です。
極端にいえば、引き継ぎはそれがすべてなんですね。

仕事を俯瞰して説明して、どういう手順で作業しているか
実際にやってみせて、どんな問題が残されているかを
理解してもらう。そして、相手にも実際に作業してもらって
自分はフォローに回る。積み残した問題は、自分が解決
するのではなく、後継者と一緒に解決する。その中で
引き継ぐ仕事をより理解してもらう。

うまく教えようと肩に力を入れるよりも、ありのままに
相手に理解してもらうこと。後継者が自分のリズムで
作業できるようになる手助けをするという意識を持ちま
しょう。

--

会話なんてむずかしいもんじゃないですよね。相手が
『昨日カニ食べたんですよぉ』っていってきたら、
『へぇ、おいしかった?』って相手に返せばいいん
ですから。なのにいきなり『ズワイガニより毛ガニの
ほうがうまいやね』とかいっちゃうと会話が成り立た
ないですよね。あんたの好みや自慢話を聞かせてどう
すんだよっていう。そういうバカが多いんだ、これが
また。

--

しっかし、面白いんですよ。ビルド中、2人並んで
モニタを見詰めてるんですよ、黙って。

新興宗教か何かのお祈りか?

ああ、上のカニの話じゃなくってね。ペア・プログラ
ミングの話なんですけど。いくら理系はしゃべりが
苦手っていったって限度ってもんがあるだろ (笑)。

いや、これはペアに限った話じゃなくって。ビルド中、
画面をジッと見詰めてるヤツ、結構多いんですよね。

念でデバッグでもするつもりか (笑)。

で、自分は、そういうの見ちゃうとツッコミ入れ
ちゃいたくなるタチで。『お祈りしてんの?』とか (笑)。
『ち、ちがいますよ、かんがえごとしてたんですよ』
とかいうんだ、これがまた。ウソつけっつの (笑)。

--

そういう意味では、抽象性のほつれというのは、
cohesionが低い状態ということもできる。

本家Permlink


2007年03月15日

http://radar.oreilly.com/archives/2007/03/the_other_way_t_1.html

そういえば、小林光一名誉棋聖は、対戦中に棋譜を
さかさまに見ることがしばしばあったそうです。

ひょっとすると、ソース・コードも紙に印刷して
さかさまに見たり、鏡に写して見ると、デバッグの
助けになるかもしれません。そんなの、コンピュータ
使えばすぐできそうですけど、まだ誰も実装してない
んじゃないでしょうか。

本家Permlink


2007年03月14日2

『野球小僧 4月号』。王監督をはじめ、その豪華な
インタビュー記事群に感慨にふけることしばし。

自分が読みはじめた当初は、どちらかというと脇役的な
選手へのインタビューが多かったですし、有名な人でも
すでに引退した後だったりと、そこはかとない『二流感』
みたいなものがあったものでした。このあいだの『中学
野球小僧』に井川のインタビューが載ったのにも驚き
ましたけど。

野球好きが始めた雑誌が、ようやくプロ野球界にも認め
られたということなんでしょうね。BBMのような迎合主義
でもなく、Numberのような拝金主義でもなく、それこそ
小僧のように純に野球が好きだという情熱だけの雑誌が
ようやくここまで来たか、という感じです。

まぁ、そんな話よりも巨人の伊原コーチです。この
インタビューが面白い。野球小僧には、確かこれで二度
目の登場です。今回は前回よりもさらに突っ込んだ話が
聞けます。エンピツを目の前にかざしながらテレビに
映る投球を見る話など、『そこまでやるのか』とその
執念に背筋が凍る思いです。

それと、カープファンは全員買うよね。黒田のインタ
ビューもあるんだから。まぁ、全国にどんだけカープ
ファンがいんのか知らないけど。

--

この『野球小僧』、他の業界とかでも話題になることが
あるみたいですけど、そうそうマネできないでしょう。
なんだかんだいって、やっぱり情熱を持つものが勝つし、
ネットの時代はその流れを強めることはあっても、弱める
ことはないしね。だから、デンツーとかボトルネック
商売で儲けてた連中は死んでろと。

本家Permlink


2007年03月14日1

やっぱジャニスだろ。生き様としても。

--

うーん・・・・・前日から続いてるのかな。
さて、私も事情を知らないのでなんとも言えないけど、
おもいっきりプログラミングしちゃうのも1つの方法。
それこそ何も仕事に関係ないプログラムとかで遊んだり。。
一人でいると余計によくない方向にばっかり考えるか
考え込み過ぎちゃう。ぼーっとしてるよりもコーディング
している方がいいよ♪
元気もらわなきゃ((o(^-^)o))ねw

なんてな。

本家Permlink


2007年03月14日


本家Permlink


2007年03月13日

今日、新しい人がチームに入ってきて、前やってた仕事の
話をちょっと聞いてみたんです。そうしたら、数ヶ月かけて
設計して、設計のレビューやって、設計のテストやって、
数週間かけてコーディングしたんだそうです。で、驚いた
ことに、その人が『それはとてもいいことだと思った』
っていうんですね。

いや、『驚いた』っていうのは半分ウソですけど (笑)。

まぁ、多分、『それはとてもいいこと』っていうのが
この業界の常識なんでしょうけど。でも、自分は戦い
ますよ。ゼッテー負けねぇ。クソッタレどもが。

--

児玉さんオススメの『デザインする技術』読んでるんです
けど、いろいろな読み方ができて面白いです。これを
『すっげーいい本』とは自分はいえませんけど。タイポ
多いし (笑)。

でもね、この本で示されてるとおり、ラフはどこまで
行ってもラフでしかないのね。いわゆる設計っていう
のは『ラフ』でしかないわけ。それに時間をかけ過ぎる
っていうのは、やっぱし何かおかしいでしょ。

第一、ソフトウェアはソフトであるからソフトウェアで
あってね。ラフを本物の製品に変えていくことができる
わけ。絵だったら何枚もラフを描き改めないといけない
かもしんないけど、ソフトウェアは成長させることが
できるわけ。で、ソフトウェアを正しい方向に育てる
ことも自分らは設計って呼んでるわけ。ラフだけの意味
じゃなくってね。

それにラフっていうのは:

  ラフは自分の考えをまとめる手法で
  ある以上に、他者から意見を募りやすい形でもある。

って書かれてるし。だったら、UMLなんかよりも動く
システム、それもプロトタイプより本物のほうがいいで
しょ? いや、他にいろんな手法はあるとしてもね。

  他者はイメージが未完成なほど
  建設的な意見を入れやすい。

っていうのがあるんなら、システムがヨチヨチ歩き
してるとこから見せればいいわけでしょ? それと
いつでも変えられるっていう安心感を与える努力も
怠らないでおくしね。

ドメインの知識、つまり顧客のビジネスを理解するのに
数ヶ月かかりましたってんならわかりますけど、数ヶ月
動きもしない『資料』しか作らない『設計』って、マジ
わからん。宇宙ロケットでも作ってるのか。

これも何度も書いてますけど、規模やドメインによっては、
数ヶ月下準備しなきゃいけないこともあるんでしょうけど。
でも、そんなのは例外であってね。そんなとこに『常識』を
置くのは間違ってるでしょ?

--

別にラフをラフだと思って使ってるんなら、それは
それで構わないんですよ。UIの感触をつかみたいから
紙に描いてみるとか。でも、その絵を描くことに本気に
なってどうすんの?っていう話。

本家Permlink


2007年03月12日2

こうやって改ページするのもバランスなんだな、これが。

本家Permlink


2007年03月12日1

もうちょっと話を続けますか。

大体、技術者っていうのはガンコなもんです。それが
必ずしも悪いことじゃないんですけど、まぁ、ガンコ
なんです。そういう人を相手にするんだったら、やっぱり
やってみせたほうがいい。論より証拠ですね。さすがに
証拠を見せつけられて目を背けるようじゃ技術者とは
呼べないわけで、これで問題は解決します。

それに、必ずしも考えが伝わらないこともあります。
説明が下手だっていうのもあるでしょうし、相手の経験
不足ということもあるでしょう。そんなときは、やっぱり
やってみせたほうがいい。

あと、リファクタリングみたいなものの効果っていうのは、
すぐにはわからないもんです。メソッドを切り出した、
クラスを切り出した、なんてやっても『それで?』って
返されちゃう。相手から『そんなのじゃダメでしょ』って
いわれるよりも、『それで?』って返されるのは辛いのね。

もう捨てちゃいましたけど、こないだの『Number』で
オシム監督が『もっと議論をしよう』ってなことをいって
たんです。『あなたが私の意見に賛成する必要もないし、
私もあなたの意見に賛成する必要もない。でも議論しよう』
みたいなニュアンスだったんです。自分はこれに非常に
感動したんです。でも、相手が言葉を持たなきゃ議論は
成り立たないし、納得のしようがない。

--

たとえば、表みたいな行と列で構成されるものがあって、
ある行が選択されるものとします。自分は、行が選択
されてるかどうかを行に尋ねるのが自然だと思うんです。
でも、相手は、『表が知ってればいいじゃん』っていう
わけです。こういうギャップは、埋めるのがスッゲー大変
なんです。

今『自然だ』って書きましたけど、こんなのはもちろん
主観に過ぎないわけで、その自然さを共感できない人から
したら『ハァ?』なわけです。

行自身が知ってるかどうかは、メソッドを切り出していく
うちに違いが出てきます。行自身が選択状態を知って
いれば、行以外にメソッドの引数として渡す必要はない。
でも、そうじゃなきゃ行と表の両方を渡さなきゃいけない。
これはコードから答えが出せる話です。

ひょっとすると『じゃあ、メソッドなんか切り出さなきゃ
いいんじゃね?』って返ってくるかもしれませんよね。
そうなったらもう議論は成り立たなくなる。

--

いろいろ書いてますけど、もちろんペア・プログラミングが
嫌いなわけじゃないんです。むしろ楽しいくらいでね。
でも、やっぱりむつかしいなぁと。

--

メタファとしてカメラはどうだろう?

--

そうそう、行自身が選択されていることを知っているべきか
どうかというのは、例の『場合による』ってヤツだ。ここで
バランス主義のご登場なわけだ。

自分は不自然だと感じたらやっちゃうのだ。部分だけを
見て、全体を見ないで、バランスも考えずにやっちゃうのだ。
自分が不自然だと感じていて、さらにコードがやれって
いってるんなら、迷う必要などないのだ。それでバランスが
崩れたら崩れたときの問題で、今はやっちゃうのが自分に
とってのバランスなのだ。

部分最適化なくして全体最適化なし。ボトムアップで
いいのだ。そうポール・グレアムもいってるのだ。

本家Permlink


2007年03月12日

あれって、オレ宛て?

いや、そうなんですけど。いや、やっぱり2人が
納得することは大切なんですけど、パートナーを
後押しするのももう一方のパートナーの役割の1つな
わけで。

だから、そのへんは個性の範囲なんじゃないですかね。
説得するのが得意なら説得すればいいし、論より証拠派
だったらやってみせればいいわけで。

説得っていうのは、communication, respect, humanity,
mutual benefit, diversity, flowあたりに関係するし、
やっちゃえっていうのは、courage, feedback, reflection,
opportunity, failureなんかと関係するし。それこそ、
どっちが正しいとは一概にはいえない世界。

もちろん「やっちゃえ」派だからといって、パートナーを
無視しちゃいけませんし。

でも、やっぱり自分は「やってみりゃいいじゃん」派 (笑)。

本家Permlink


2007年03月11日

話を聞いてて、いっつも思うんですよ、『やってみりゃ
いいじゃん』って。

これは無責任なようだけど、XPの原則に適ったものなのね。
つまり、opportunityであり、redundancyであり、そして
failureなわけ。

学習の機会だと思って、やってみりゃいいじゃん。
冗長かもしんないけど、やってみりゃいいじゃん。
失敗するかもしんないけど、やってみりゃいいじゃん。
ダメなら出直せばいいじゃん。

--

やっぱり行動や態度に出ないと『理解した』っていう
ことにはなんないんですよね。よくいう『頭で理解した』
っていうのじゃダメなわけで。

--

ああ、書くの忘れてた。結局、ストーリー・カードじゃ
エビデンスとして弱いっちゅーか、ストーリー・カードに
エビデンス能力持たせようとすると、ハンコだ何だと大変で、
ストーリー・カードの粒度の小ささが逆にアダになるって
感じ。

だから、accepted responsibilityが実施されてても、
ストーリー・カードをもって、それが請負作業であることを
証明することは難しいってこと。それが法律であり、
実務上の処理なんだから、ガタガタいってもしょうがない。

偽装派遣とか、偽装請負とかには、自分は断固として
ノーというんだけど。まぁ、少なくとも自分に関しては
技術を提供しているという自負を持って臨みたいと。

--

結城さんのリファクタリングの本を流し読み。ベリー・
グッド・ブック。SBPPの前にこれ読ませたほうがいいかも。

自分から1つだけいうなら、『やるならトコトンやれ!』。
結城さんの本の中で『バランスが大切』っていうのが
繰り返し説かれてますけど、この本を読むような人は
当然リファクタリングの初心者なわけで、そういう
初心者が『程』を知るのはむつかしい。だったら、トコ
トンやれと。初心者なら、やりすぎくらいがちょうどいい
『程』なんです。

何度もいいますけど、プログラムは意図を明白にする
ことが大切。意図を明白にすることと行数は無関係。
だから、意図をはっきりさせたいんならメソッドを切り
出せと。トコトン切り出してみろと。それで、メソッドの
数が増えたら、またそこで考えりゃいいじゃんかと。

将来の拡張性なんかどうでもいい。性能もどうでもいい。
今意図してるものがコードとして表現できてるかどうか
だけに集中する。そしてリファクタリングする。今を
単純にすることが、将来の拡張や最適化を容易にするん
だと、信じること。それがリファクタリングの心の1つ
なんです。

--

そういえば、一緒に届いたはぶさんの本の中で:

  しかし一方で、データベースに限りませんが、設計というのは単に知識を集めるだ
  けではなかなかうまくはいきません。スキルは経験によって養われていきます。設計
  におけるスキルもまた同様です。ですから、できるだけ多くの経験を重ねることが良
  いデータベース設計を実現する重要な要素となります。

って書かれてます。できるだけ多くの経験を重ねるには
どうすればいいか。やりすぎるしかないんです。ウジウジ
バランスがどうこう考えるヒマがあったら、とにかく
やっちゃえと。反省はあとですればいい。というか、
反省するためにやりすぎるんであって。ビビッてたら、
反省もクソもない。経験や学習の機会を逃がしてるだけ
なんです。

--

『やりすぎ』は二分探索法ということもできる。
逆に『やりすぎない』のは線形探索だ。

もし仮に解が『やりすぎ』だと思っている地点よりも
さらに『やりすぎ』だったとしても、一歩の幅が大きい
分だけ解に近づくのは速い。

--

もちろん、慎重派を否定するものではありません (笑)。
ただ、慎重派の人だったとしても、いつもよりちょっと
歩幅を大きくしてほしいというだけの話。

本家Permlink


2007年03月10日

『孤立した環境で作業できる?』って聞かれたら、誰
だって『効率は悪いだろうけど、できる』って答える
でしょう。で、この会話の結論は往々にして『孤立した
環境でも作業できる』っていう単純化されたものに
なっちゃう。

だから、そういうふうに考えるんじゃなくって、何に
価値を置くかという、基本に立ち返んなきゃいけないん
です。XPでいえば、これの問題はコミュニケーション。
『孤立した環境だとコミュニケーションが落ちるよね、
だからダメだよね』っていうとこに行き着かなきゃいけ
ない。

で、そういう考え方、価値観をみんなが共有しないと
ダメなんです。でないと今度は、『コミュニケーションが
落ちても作業はできる?』っていう質問に切り替わる
だけで、またおかしなことになる。

本家Permlink


2007年03月08日

一般的にいって、限りある資源に対して需要がたくさん
あると価格は上がるわけですよね。でもって、できる
人のところに仕事は集中しちゃうもんですよね。すると、
できる人にしてみれば、仕事の量を減らすほうが価格が
上がるってことになりますよね。つまり、残業するって
のは安売りしてることに外ならないと (笑)。

『この人に頼みたい』とか『この人じゃなきゃできない
んだ』ってなって、『この人』が忙しいんなら、頼む
ほうは待つしかない。あるいは代償を払って割り込む
しかない。

まぁ、現実にはそんなに単純な話じゃないですけど、
そういうことを考えてもいいんじゃないですかね。

やっぱり本給が上がってナンボだと思うんですよね。
残業なんかで稼ぐよりも。

--

そういえば:

$ cvs up -dP 2>/dev/null

(スマン、まだCVSなんだ。)

みたいなコマンドをやったら『その"2>/dev/null"って
何ですか?』って尋ねられてビックリした。知ってて
当然だと思ってたから。

これを書いたのは、彼を責めるためじゃなくって、逆に
褒めてるくらいなのね。こういう『何やったんすか?』
っていうのは、やった当人にしてみれば全然当然のことを
やってるわけで、わざわざ説明しないもの。だから、
疑問に思ったら、その場で聞かなきゃいけないわけ。
こっちは別に隠すつもりはないんだし。『man読め』
なんてこともいうつもりはないし。

そして、そういう疑問を見つけられるように、よく観察
してなきゃダメなわけ。観察して疑問を見つけて、聞いて
(あるいは調べて)、自分で試して身につける。そういうのを
習慣づけるわけ。これが技術を習得するサイクルなわけ
でしょ?

--

結局のところ、コードをコピペするのは、そのコードを
理解してないからなんですよね。だから、理解するまでは
コピペも止むなし。ただ、そこで立ち止まらないで、
理解しようと努力することが大切なんでしょうね。
そして、理解するための具体的な手段としてテストを書く
というのがあって、で、理解が深まったらリファクタ
リングするという。

本家Permlink


2007年03月06日3

自分はコーダーで、コードを偏愛してるっぽいし、
コードを信じてるわけです。だから、自分がいってる
ことも、コードが『そういってる』ことを代弁してる
だけで、分析がどうとか、UML的にどうとか、そういう
わけじゃないんです。

責任についても、それをコードが求めてるから移すべき
だというだけで、頭デッカチに『そうあるべきだ』と
いうのとはちょっと違うんです。

久しぶりにSBPPから引用しましょう:

I said, "we seem to be using a lot of the Part's data in
multiplyPartTimeRate:. Why don't we move this code into Part?" "But we did-
n't design Parts to do arithmetic!" "Since the code seems to be telling us to do
this, let's try it."

『銀が泣いている』なんていうセリフもありますけど、
コードはもっとわかりやすいですよね。銀はいくら見ても
自分には涙を流すようには見えませんけど、コードだった
ら、書いた人の意図とかもわかりますし、心理状態とかも
多少はわかります。

--

もちろん、これは弱点にもなるわけで。コードがないと
頭が動かない。だから、コーダーである自分は、そもそも
前払いの設計は苦手なんです。だから、その弱点をカバー
するためにも、コードを早くから書いて頭を動かせるように
するわけです。テストもそう。テスト・コードを書くことで
自分の理解を確かめる。図で理解を確かめられる人もいる
でしょうけど、それは自分には向かない。

--

くどいようだけど、『レトリック』について。

たとえばhello, worldにしても、様々な実装が考えられる
わけで:

puts 'hello, world'

っていう単純なものから:

"hello, world\n".each_byte{|c| print c.chr}

なんていうちょっと凝ったものも書けるけど、機能と
してはどれもおんなじ。多少性能に違いがあるかもしれ
ないけど、まぁ、そういうのはムシする。

で、そういった様々考えられる実装から意図を一番うまく
伝えられるように選んで書くわけ。だから『レトリック』
だっていってるわけ。

何度も書いてるけど:

int   number = 1;
char *str    = "abc";

みたいなことをレトリックといってるわけじゃない。
こんなのはレトリックとしてはマズイわけ。余計な情報を
伝えちゃってるわけで、伝えたいことをシンプルに伝えて
ない。コードは読むもので、眺めるものじゃないし、
『見た目をきれいにする』っていうのは、何か隠そうと
していることがほとんど。それは自分に自信がなかったり
とか、そういうことを隠そうとしてるわけ。そんなことを
するくらいなら、メソッドを切り出したり、他にやんなきゃ
いけないことはいくらでもある。

--

ほんとに、タカが5行程度のメソッドでも空行空けるからな。
そんなのはエディタの行間設定の話じゃないの? だったら
ワードでも一太郎でも使ってコード書け。コードにノイズを
載せるな。

本家Permlink


2007年03月06日2

Shiroさんのいう「抽象性のほころび」っていうのを
自分なりの言葉にすると、「責任の分配ミス」って
ことになるんじゃないか。責任の所在が間違ってる
から、それを使う側が苦労しなきゃいけなくなる。
いってみれば、cohesionが低い。

本家Permlink


2007年03月06日1

申し訳ないけど、このページ読んだからっていって、
ワーキング・プアから抜け出せるとか、そういうのは
ないですからね。

残酷ですけど、単純な労働で『頑張れば給料が上がる』
っていうのはあり得ないでしょう。プログラマの能力って
個人差が激しいのはよく知られてますけど、それは裏を
返せば、頑張りがそれだけ反映されやすいわけです。でも、
他の職業だったら、頑張ったって、なかなか他人の2倍も
生産性はいかないでしょう。プログラマの生産性の違いは、
10倍20倍が当たり前っていわれてるわけで。

じゃあ、プログラマやる? やれんの? 自分は好きだから
やってるけど、じゃなきゃ甘くないよ?

本家Permlink


2007年03月06日

まぁ、ぶっちゃけトークをしちゃえば、XPだなんだ
いったって、仕様には興味が持てないんだな。
それがオレが職業プログラマ失格で、二流たる所以
なんだな。

コードと集団による開発っていうものに興味があって、
何を作るかは問題じゃないっていうか。

もちろん、ビックリさせるようなクールなものとかには
興味はあるけど、まぁ、そういうのは仕事じゃ出会わ
ないし。

でも、だからっつって、ビジネスをまるっきり無視する
わけじゃないし、ビジネスが成功するためにコードを
書いてるわけだけど。まぁ、たまにはどうでもよくなる
こともあるってこと (笑)。

--

ああ、でも、仕様を理解していることと、それをどう
実現するかっていうのは別の話だから。

仕様を理解してるだけじゃ『動けばいい』になっちゃうし、
どう実現するかばっかりじゃ『使いものにならない』に
なっちゃう。

--

リファクタリングは毎日やる。それはつまり毎日設計
するということ。『あとでやる』の『あと』は常に必ず
やってくるとは限らないわけで。

昨日の理解と今日の理解とでは違うわけで、その深まった
分の理解をコードに反映させる。それが『変化に対応
する』という意味でのagileの1つでもあると。

--

『毎月が期末』という言葉があるなら、『毎日がリリース』
という言葉があってもいい。あなたが今日コミットした
コードはリリースに値するのか。コンパイルが通るだけで
いいのか。テストが通るだけでいいのか。

--

『実環境じゃなきゃ確かめられません』っていうのが
ヤなわけ。テスト中毒の自分からしたら、それは屈辱で
しかない。

テストがない機能は存在しない。

テストがやりにくいシステムは悪いシステム。

テストはなんでもあり。なんだから、モックでも何でも
作って、自動テストできるようにする。

本家Permlink


2007年03月05日

XPerは、big refactoringの機会を探すものだし、
中でもbig payback、つまり、少しの変更で劇的な
効果をあげるリファクタリングを逃してはいけない。

本家Permlink


2007年03月02日

23て、サバ読みすぎやろ。夏川純じゃあるまいし。

--

傲岸で (SKKエライ)、卑屈って、オレのことじゃない
ですよね? ね?

傲岸で自虐であるかもしれませんけど。根はいい子なん
です。

--

ほんとに『ラグビー魂 Vol.2』が出るとは思わなかった。

清宮特集。ちょっと持ち上げすぎでキモイ感じがしない
でもないけど、やっぱり面白い。

それにしても、愛読してるのが東スポなもんで、東芝が
優勝したの、知らなかったよ (笑)。

キーワードって効果あるんですねぇ。自分もここでちょく
ちょく書いたりしますけど。やっぱり『使えるフレーズ』を
たくさん知ってることはいいことだと思います。で、
それを実際に使ってみることが大切だと思います。それも
繰り返し使うほうがいい。まぁ、繰り返し使うからキー
ワードなんですけど。

それと、いい/わるいをすぐにいえること。これは結構
重要です。これはセンスの話にもなるんですけど。
センスっていうのは善悪の判断の速度だということ。
考えられる選択肢っていうのは、いくつかあるのがフツー
なんですけど、選べるのは1つしかないし、最適な解って
のも必ずあるはずだと信じていれば、まぁ、それほど
迷うこともないんじゃないですかね。そのためには自分
なりの基準ってのを持ってなきゃいけないわけで、それが
DoTheSimplestThingThatPossiblyWorkとか、そういうのに
なるわけです。

ああ、もちろん、リスクを取るっていう意味も含みますよ。
即断に誤断はつきものですから。

--

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

  We're not looking for the quickest way; we're looking for the
  simplest result. So, we first break the existing method into
  pieces. That leaves the existing test cases running. Then we modify
  (simply, now) one of the little methods to handle the next test
  case. (KB)

そうなんだよな。『単純 == 早く実現できる』ってわけじゃ
ないんだよな。そこを勘違いしてるヤツが多い。もちろん、
このオレも含めてだけど。

だから、やっぱり単純っていうのは、獲得するものなんだよな。
単純にするために、ヒーヒーいいながら設計するんだよな。

本家Permlink


2007年03月01日1

すっげーJavaのこと忘れてる。AntのこととかJUnitのこと
とか。自分でもAntの文書書いていながら、その突っ込みの
甘さに泣いてるという (笑)。

まぁ、今どき、素でbuild.xml書く人もいないんだろうし、
ましてやAntでJUnitタスク書く人もいなんだろうけど。
ちょっと書いとく。

下のは、Antのドキュメントからほぼまんまパクったもの
なんだけど、ドキュメントに書かれてないことも結構あって、
それでハマる。一番のハマリどころは、srcの下の構成が、
classesと同じじゃないといけないということ。つまり、
たとえば、コンパイルした後、classが:

  classes/
    hello/
      Hello.class
      TestHello.class

って感じになるんだったら、srcも:

  src/
    hello/
      Hello.java
      TestHello.java

になってないといけない。javacが勝手にやってくれる
からといって:

  src/
    Hello.java
    TestHello.java

みたいな構成だとエラーになる。

あと、ドキュメントでは:

  <test name="my.test.TestCase" haltonfailure="no" outfile="result">

なんて書かれてるけど、batchtestがあれば、こんなのは
いらない。

<?xml version="1.0"?>
<project name="junit" default="test" basedir=".">
  <target name="test" depends="compile">
    <mkdir dir="reports_tests"/>
    <junit printsummary="yes" haltonfailure="yes">
      <classpath>
        <pathelement location="."/>
        <pathelement path="classes"/>
      </classpath>
      <formatter type="plain"/>
      <batchtest fork="yes" todir="reports_tests">
        <fileset dir="src">
          <include name="**/*Test*.java"/>
        </fileset>
      </batchtest>
    </junit>
  </target>

  <target name="compile">
    <mkdir dir="classes"/>
    <javac srcdir="src" encoding="EUC_JP" destdir="classes" debug="on"/>
  </target>

  <target name="clean">
    <delete dir="classes"/>
    <delete dir="reports_tests"/>
  </target>
</project>

--

やっぱりCのキャストって恐い (笑)。

下のをg++でコンパイルすると、フツーにFoo#a()が
呼び出される。実際の仕事でやらかしたのはVC++ 6.0で、
これとはまた違った挙動だったんだけど、すっげー
ハマった。

こんなの、Javaだったら実行時エラーになるんだけどなぁ。

#include <iostream>

using namespace std;

class Foo {
public:
    void a() { cout << "hello, world" << endl; }
};

class Bar {
public:
    void b() { cout << "goodbye, world" << endl; }
};

int
main(int argc, char* argv[])
{
    Foo* foo = (Foo*) new Bar();
    foo->a();
    return 0;
}

--

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?InterfaceImplementationPair
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=RoleInterface&key=RoleInterface

『すべてのクラスをインタフェースとペアにするのは
嫌いだ』といいつつ、『ロールインタフェースのほうが
好みだ』というのはちょっと矛盾してるように思えたけど、
要は、本当にインタフェースを必要とするのかという
ことなんだと思う。複数の実装を1つの型の下にまとめる
必要があるかどうかということ。だから、実装が複数
なけりゃ、わざわざインタフェースという余計な層を
設ける必要はないってことか。

だから、やっぱりDoTheSimplestThingThatCouldPossiblyWork
ってことになるんだろうなぁ。

--

ああ、ちなみに、ここで『顧客』って訳されてますけど、
あんまり使いませんよね。『クライアント』で十分
通じると思います。少なくともBliki読むような人たち
なら。

本家Permlink


2007年03月01日

if文あるところに多態あり
switch文あるところにオブジェクトあり
だろ?

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails