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年01月31日1

いや、ま、あれだよ? みんな誤解してるよ?
てゆか、『いい』の反対が『わるい』だと思ってるだろ?
いやいや、そうじゃない、そうじゃないんだよ?
『いい』といったら『ふつう』もあって、それから
『わるい』っていうのがあるんだろ? な?

ほら、それにさ、『いい』とか『ふつう』とか『わるい』
なんてのはさ? あれだよ? そう、人それぞれなんだ。
人それぞれなんだよ? わかる?

だから、まぁ、オレがさ、誰某の歌なんてイクナイって
いってもさ、その誰某の歌がいいっていう人がいても
全然おかしくないよな? そうだよな? ほら、よく
ゆーじゃん? 歌は世につれ人につれって。な?
だから、人それぞれに『いい歌』っていうのがあるんだ。
うん、あるんだよな。

--

だから、なんでオレがこんな言い訳めいたことを
書かなきゃいけないんだよ!

ほんっと、会長は世渡りが上手いよな。

電波なんだから電波でいーじゃんか。だって、ベリエが
大好きでRailsも大好きって、そりゃ十分ヘンなわけだろ?
だったら電波でいーじゃねーか。

いわせてもらえりゃ、会長だって十分ヘンなわけでしょ?
だって、赤いタンクトップ着て、赤いハチマキ巻いて
プレゼンやるんだよ? しゃべってる内容はマトモだった
けどさ。でもさ、オレはビンビン感じたね、電波を。

でもさぁ、やっぱ電波出すくらいの人間じゃないと
面白くないよな、今の世の中。実際、Rubyの上のほうに
いるのなんて、みんな電波強いもんな。まつもとさんを
はじめとして。で、それで2chなんかで叩かれてるんだろ?
でも、面白いもんなんて、そんなもんだしな。楽しんでる
連中を外から見たら、そりゃ狂人の集まりにしか見えない
だろ。でも、中にいる人間からしたら、楽しんでるだけ
でさ。まぁ、中には外に電波飛ばしたがる連中もいるんだ
けどさ。

と、フォローしておこう。

--

おいおい、上のは半分は冗談だからな? あとの半分は・・・愛情です。

--

だからさ、オレがPHP嫌いなのも、しょうがないんだよ?

本家Permlink


2007年01月31日

だからオレたちの生産性なんてタカが知れてるんだから、
生産以外の部分のロスを減らさないとどうしようもねぇ
だろ?

--

プログラマが規模の不経済の中で生きる生き物なら、
人月商売から抜け出さないといけない。人月商売は
規模の経済なんだから。

本家Permlink


2007年01月30日2

くどいようだけど、once and only onceとDRYは
ニュアンスが違います。強いていえば、once and only
onceは設計に用いたほうが効果的な言葉で、DRYは
プログラマの態度に用いたほうが効果的な言葉です。

once and only onceは、コードを重複させないという
意味とともに、あまねく意図を明白にするという意味も
あります。だから、たとえ重複してなかろうが、それに
明白な意図を持たせるべきならばそうすべきだという
こと。

よく例に出されるのが:

def highlight
   @text.font = BOLD
end

みたいなヤツ。フォントを太字にするというのと、
テキストを強調するのとでは意図が違うわけで、それを
メソッドにすることでハッキリさせます。こうすることで、
『あれ? 強調は太字だっけ? イタリックだっけ?』
みたいな混乱を避けられます。で、肝心なのは、この
highlightというメソッドがたった一カ所でしか使われなく
ってもメソッドとして切り出す価値があるということ。
コードというのは書いた人間の意図を伝えることが大切。

で、DRYっていうのは、コードを重複させないという
意味とともに、積極的に自動化する、あるいはもっと
広げて、あらゆるものについて一度に済ませる努力を
するという意味もあります。だから、プログラマの
態度に用いたほうが効果的というわけです。

たとえば、キーボードで何回も同じことをタイプしてる
なら、キーボード・マクロを使ってみるとか。同じ
コマンド・セットを何回もタイプしてるならシェル・
スクリプトを書くとか。

だから、DRYは設計とともに生産性にも関わる言葉なん
ですね。

--

めんどいからRubyで書くけど:

class SetScorer
  def initialize
    @games = [0, 0]
  end

  def gameWon(number)
    @games[number - 1] += 1
  end

  def getSetScore
    if games[0] < 6 && games[1] < 6
      if games[0] > games[1]
        return "Player1 leads " + games[0] + " - " + games[1]
      end
      if games[1] > games[0]
        return "Player2 leads " + games[1] + " - " + games[0]
      end
      return "Set is tied at " + games[1]
    end
    if games[0] == 6 && games[1] < 5
      return "Player1 wins the set " + games[0] + " - " + games[1]
    end
    if games[1] == 6 && games[0] < 5
      return "Player2 wins the set " + games[1] + " - " + games[0]
    end
    if games[0] == 6 && games[1] == 5
      return "Player1 leads 6 - 5"
    end
    if games[1] == 6 && games[0] == 5
      return "Player1 leads 6 - 5"
    end
    if games[0] == 6 && games[1] == 6
      return "Set is tied at 6 games"
    end
    if games[0] == 7
      return "Player1 wins the set 7 - " + games[1]
    end
    return "Player2 wins the set 7 - " + games[0]
  end
end

こうのは絶対的な条件判定を先に書くのが鉄則。
だから、勝利判定を真っ先にやる:

class SetScorer
  def initialize
    @games = [0, 0]
  end

  def gameWon(number)
    @games[number - 1] += 1
  end

  def getSetScore
    if games[0] == 7
      return "Player1 wins the set 7 - " + games[1]
    end
    if games[1] == 7
      return "Player2 wins the set 7 - " + games[0]
    end
    if games[0] == 6 && games[1] < 5
      return "Player1 wins the set " + games[0] + " - " + games[1]
    end
    if games[1] == 6 && games[0] < 5
      return "Player2 wins the set " + games[1] + " - " + games[0]
    end
    if games[0] < 6 && games[1] < 6
      if games[0] > games[1]
        return "Player1 leads " + games[0] + " - " + games[1]
      end
      if games[1] > games[0]
        return "Player2 leads " + games[1] + " - " + games[0]
      end
      return "Set is tied at " + games[1]
    end
    if games[0] == 6 && games[1] == 5
      return "Player1 leads 6 - 5"
    end
    if games[1] == 6 && games[0] == 5
      return "Player1 leads 6 - 5"
    end
    if games[0] == 6 && games[1] == 6
      return "Set is tied at 6 games"
    end
  end
end

んで、条件に漏れはないみたいだから、ややこしいのは
後回しにする:

class SetScorer
  def initialize
    @games = [0, 0]
  end

  def gameWon(number)
    @games[number - 1] += 1
  end

  def getSetScore
    if games[0] == 7
      return "Player1 wins the set 7 - " + games[1]
    end
    if games[1] == 7
      return "Player2 wins the set 7 - " + games[0]
    end
    if games[0] == 6 && games[1] < 5
      return "Player1 wins the set " + games[0] + " - " + games[1]
    end
    if games[1] == 6 && games[0] < 5
      return "Player2 wins the set " + games[1] + " - " + games[0]
    end
    if games[0] == 6 && games[1] == 5
      return "Player1 leads 6 - 5"
    end
    if games[1] == 6 && games[0] == 5
      return "Player1 leads 6 - 5"
    end
    if games[0] == 6 && games[1] == 6
      return "Set is tied at 6 games"
    end
    if games[0] < 6 && games[1] < 6
      if games[0] > games[1]
        return "Player1 leads " + games[0] + " - " + games[1]
      end
      if games[1] > games[0]
        return "Player2 leads " + games[1] + " - " + games[0]
      end
      return "Set is tied at " + games[1]
    end
  end
end

すると、もっと簡単に書けそうだとわかる:

class SetScorer
  def initialize
    @games = [0, 0]
  end

  def gameWon(number)
    @games[number - 1] += 1
  end

  def getSetScore
    if games[0] == 7
      return "Player1 wins the set 7 - " + games[1]
    end
    if games[1] == 7
      return "Player2 wins the set 7 - " + games[0]
    end
    if games[0] == 6 && games[1] < 5
      return "Player1 wins the set " + games[0] + " - " + games[1]
    end
    if games[1] == 6 && games[0] < 5
      return "Player2 wins the set " + games[1] + " - " + games[0]
    end
    if games[0] > games[1]
      return "Player1 leads " + games[0] + " - " + games[1]
    end
    if games[1] > games[0]
      return "Player2 leads " + games[1] + " - " + games[0]
    end
    return "Set is tied at " + games[1]
  end
end

で、まぁ、Playerを切り出すだろ、フツー:

class Player
  def initialize
    @points = 0
  end
  attr_accessor :points

  def add
    @points += 1
    @points > 7 and raise "oops!"
  end
end

class SetScorer
  def initialize
    @players = [ Player.new, Player.new]
  end

  def gameWon(number)
    @players[number - 1].add
  end

  def getSetScore
    if @players[0].points == 7
      return "Player1 wins the set 7 - " + @players[1].points
    end
    if @players[1].points == 7
      return "Player2 wins the set 7 - " + @players[0].points
    end
    if @players[0].points == 6 && @players[1].points < 5
      return "Player1 wins the set " + @players[0].points + " - " + @players[1].points
    end
    if @players[1].points == 6 && @players[0].points < 5
      return "Player2 wins the set " + @players[1].points + " - " + @players[0].points
    end
    if @players[0].points > @players[1].points
      return "Player1 leads " + @players[0].points + " - " + @players[1].points
    end
    if @players[1].points > @players[0].points
      return "Player2 leads " + @players[1].points + " - " + @players[0].points
    end
    return "Set is tied at " + @players[1].points
  end
end

で、どうも判定はPlayerにやらしてもいいんじゃないか
っていう気になってくる:

class Player
  def initialize(number)
    @id = number
    @points = 0
  end
  attr_accessor :points

  def add
    @points += 1
    @points > 7 and raise "oops!"
  end

  def scoreMessage(opponents)
    if points == 7
      return name + " wins the set 7 - " + opponents.points
    end
    if opponents.points == 7
      return opponents.name + " wins the set 7 - " + points
    end
    if points == 6 && opponents.points < 5
      return name + " wins the set " + points + " - " + opponents.points
    end
    if opponents.points == 6 && points < 5
      return opponents.name + " wins the set " + opponents.points + " - " + points
    end
    if points > opponents.points
      return name + " leads " + points + " - " + opponents.points
    end
    if opponents.points > points
      return opponents.name + " leads " + opponents.points + " - " + points
    end
    return "Set is tied at " + opponents.points
  end

  def name
    return "Player" + @id.to_s
end

class SetScorer
  def initialize
    @players = [ Player.new, Player.new]
  end

  def gameWon(number)
    @players[number - 1].add
  end

  def getSetScore
    @players[0].scoreMessage(@players[1])
  end
end

Playerから文字列を取り出すのは、『ドメインと表現の
分離』に違反するだろうけど、ちょっとしんどいので
やめとく。

ちょっと前に『ベタで書くのも悪くない』っていう話を
書いたけど、それはこういうこと。リファクタリングの
途中段階だと思えば、下手にひねって書かれてあるよりも、
単純に書かれているほうがリファクタリングしやすい。
それは、TDDで一度コードをコピーするのに似てる。

それと、コードっていうのは手間をかけないときれいには
ならない。『こんな小さなサンプルじゃなぁ』って思う人も
多いだろうけど、自分は実際にこういうことを仕事でやる。

まぁ、上のコードも途中で終わらしちゃったわけだけど、
手間をかけようと思えば、いくらでもかけられるっていう
面もある。だから『ほどほど』がいいんだけど、でも、
その『ほどほど』は、みんなが思ってるより多分
『やりすぎ』なんじゃないかな。だから、ちょっとくらい
『やりすぎだよ』っていうくらいまでやってみたらいいと
思う。

--

仕事でもよくあるんだけど、上みたいな『ルール』を
どこに持たせるかで悩む。上の例ではPlayerに持たせた
わけだけど、たとえば審判みたいなのを切り出すやり方も
考えられる。責任の分散からいうと、Player自身に関する
ルールはPlayerに持たせるほうがいいんだろう。でも、
分散は混乱と紙一重のところがあるから、審判がルール
すべてを管理するのもありだと思う。やっぱりむずかしい。

本家Permlink


2007年01月30日1

http://www.youtube.com/watch?v=Q0VH-7gdFB4

誰でもCMを作れるようになったんだよなぁ。

本家Permlink


2007年01月30日

「ソフトウェア見積り」(Steve McConnel, 日経BPソフトプレス)

  組織のプロジェクトの多くは、同じような規模であることが多い。

ということは、大規模プロジェクトは大手デベロッパに
依頼したほうがいいっていうことになる。でも、その
わりには大規模で成功したっていう話よりも、失敗した
っていう話のほうをよく聞く。風評とはそんなもんだし、
自分が無知なだけかもしれないけど。

多分、規模が大きくなるにしたがって、プロジェクト
固有の要因が増えちゃって、過去の経験が適用できなく
なるんじゃないだろうか。

だから、規模が大きくなるにしたがって、プロジェクト・
コントロールの比重が重くなるってことなんじゃないだ
ろうか。当たり前か。でも、やっぱり規模が大きくなれば
なるほど先払いは危険だと思うんだけどなぁ。

--

こないだの「東洋経済」で、公共事業の発注に関して
「明確な仕様を用意したからこそ東芝ナントカが受注できた」
って話があったけど。あれもどうかなぁ。公共事業だから
透明性の確保っていう意味では仕方ないんだけど。でも、
仕様を開発側の人間を交えずに、なおかつ前払いで策定
するっていうのは危険だと思う。やっぱりpay per useが
いいと思うんだけど、でも、具体的にどうすりゃいいの?
って聞かれたら答えられないしなぁ。

「デ通サ」だっけ? あれ、違約金払うような契約じゃ
なけりゃpay per useでいいと思ったんだけど。

まぁ、公共事業はむずかしいね。仕事ではオレには関係ないしね。

本家Permlink


2007年01月29日2

つか、顔新って出直してこなきゃいけないのはオレのほうだった。

本家Permlink


2007年01月29日1

結合を急ぐやり方でなければ、ゼロかすべてかの二択で
あり、計量的な手法で計画することすらできない。

期日が決められていて、10の機能を実現しなければならない
としても、結合を先延ばしにするやり方ならば、実現できる
機能の数はゼロかすべてかの二択になる。結合を急げば、
できるところまで機能が実現できる。

結合にはコストがかかるかもしれない。その分を後回しに
したいという気持ちもわからないでもない。しかし、
これはリスクの問題であって、リスクとはつまりは
ビジネスの問題だ。ビジネスから見れば、ゼロかすべてか
というバクチよりも、多少でもコントロールできる
リスクのほうが好ましいだろう。

--

囲碁・将棋の世界じゃ年齢なんか関係なしに、強いヤツの
意見が尊重されるのは当たり前だし、技術の世界もその傾向は
強い。技術的に間違ってれば、ジジィだろうが誰だろうが
間違いなんだし。

本家Permlink


2007年01月29日

もちろん、逆のことも考えられます。
ボトルネックに落ちていたお金が直接流れるように
なるんですから。

本家Permlink


2007年01月28日1

シレンがSFCの焼き直しだったんで、途中でやる気なくしてさ。
で、イヅナやってたんだけど。わりと楽しめた。

自分、トルネコにしても表しかやんない根性なしでさ。
で、それもあって表のストーリーが楽しめないと面白く
ないのね。だから一度やっちゃったシレンをもう一度
やる気にはなれないんだけど。

でも、イヅナはシステム的に頭打ちのような気がする。
それに、システムを変えるとどんどんトルネコに似ちゃう
かもっていうジレンマもあるし。

そういえば、トルネコみたいなのはオープン・ソースに
向いてそうな気がする。長い間基本的なシステムは変わら
ないわけだし。ハデなグラフィックスもいらないし。

--

ん〜、やっぱり人手をかけないと短期間でできないこと
っていうのもあると思うんですよね。そういうのだと、
どうしても人を集めないといけないし、そうなったら
誰かがマネジメントをやんないといけないでしょう。
だから、自分が何をやりたいかによると思うんですよね。
だから、マネジメントやってても自分のことをエンジニアだと
思ってる人もいるでしょうし、それはそれで間違いでも
なんでもないっていうか。

--

作品の持つパワーっていうのが伝わりにくかったんです
よね。作品を生で見せるしかなった。それがちょっと
ずつ伝わりやすくなってきた。でも、相変わらず、
伝達経路にはボトルネックがあった。物理的なボトル
ネックもあったし、それがまた経済的なボトルネックを
産むという結果にもなった。でも、そんなボトルネックも
少しずつ減っていってる。作品の性質にもよりますけど、
作品を世に問いたいんなら、ほぼ直接世に問うことが
できつつある。

その『世に問う』という行為は、純粋には創作活動には
含まれないんでしょう。でも、やっぱり創作者であれば
『世に問う』欲求を持ってて当然でしょうし、持つべき
じゃないでしょうか。『作りたいから作る。作品の評価
なんか勝手にしてくれ』っていうのは、非常に芸術家
らしい態度なんでしょうけど、ボトルネックもなくなって
いる今では『オナニー』としか評価されないんじゃないで
しょうか。

--

芸術活動が巨万の富を産むっていう今の状態のほうが
バブルなのかもしれないじゃないですか。それは
経路を絞ることで得られてた富なわけで。そういうのが
簡単になくなることはないと思いますけど、でも、
絶対なくならないなんて誰にもいえないんじゃない
ですか。で、なくなるのが悪いことなんてことも誰にも
いえないんじゃないですか。

--

http://www.nicovideo.jp/watch?v=utr1m0q-SqbYg

本家Permlink


2007年01月28日

ポップスな時代だから (笑)。

うん、『聴衆がいなくっても音楽は音楽だ』って
いうのは真理なんでしょうし、正しいんでしょう。
でも、それってクラシックですよね。

プログラムの価値っていうのは、それが実行されたときに
どれだけの価値を産むかで計られるべきもので、それが
大原則。だから、どんなにきれいにコーディングされて
いようと、クソゲーはクソゲー。それがポップスという
ものでしょう。

XPはまさにプログラムの価値を高めるための方法論で
あって、リファクタリングにしてもTDDにしても、
上で書いたようなプログラムの価値を高めるためにある。
どんなにリファクタリングされていようとも、使われない
システムにしかならないんなら、それはXPじゃない。

だからといって、オレが浜崎あゆみなんかを優れた
音楽だと思うことは絶対にないからな! (笑)
どんなに売れてようが、オレにとってクソゲーなら、
それはクソゲー以外の何物でもない。

--

だから、JASRACがカスラックだと騒ぐのもいいけど、
だったら自分で音楽作りゃいいじゃん。『音楽は他人様が
作ってくれるもの』っていう態度こそ、JASRACがのさばる
理由だろ。

--

だから、日本の学会はアカデミックであり、クラシック
なわけで、だからダメなんだろ。音楽にしても、技術に
しても、外に向けられたものじゃなきゃ意味がない。

本家Permlink


2007年01月27日1

http://homepage2.nifty.com/seamarine/e-ton/viper_50st/viper_50st.html

こういうのが公道走れるようになったなんて全然知らなかった。

--

なんか意識のズレがあるように感じた。

歌代さんは『エンジニアに寿命がない』っていってるん
だけど、それはつまり、エンジニアの次のステップも
またエンジニアだっていうことなわけ。つまり、下手
クソなエンジニアが上手いエンジニアになるっていう
ことをいってるわけ。

一方、インタビュアーのほうは『エンジニアの次の
ステップはマネジメントだ』って思ってるフシがある。

囲碁や将棋の棋士は、名人になりたいとか思うわけで
しょ。まぁ、これはタイトルなんだけど、強くなりたい、
ゲームの深奥を極めたいって思ってるわけだ。でも、
日本棋院や将棋連盟の役員はあんまりやりたくはないわけ。
それがエンジニアとマネジメントにもそのもまま当て
はまるわけ。

中には好んでマネジメントに転向する人もいるだろう
けど、それはステップじゃないわけ。『転向』なんだ
から、どっちかっていうと『踏み外した』っていう
ほうが正しい。

これは収入の多寡でいってるわけじゃないのね。
マネジメントに転向したほうが収入が増えることも
あるんだろうけど、だったら最初っからマネジメント
やってたほうがいいじゃん? なんのためにエンジニア
選んだか、よく考えなきゃダメ。

本家Permlink


2007年01月27日

http://www.computer.org/portal/site/ieeecs/menuitem.c5efb9b8ade9096b8a9ca0108bcd45f3/index.jsp?&pName=ieeecs_level1&path=ieeecs/publications&file=magazines.xml&xsl=generic.xsl&

もう何度も何度も書いてるんですけど、どうしてこう
日本の学会っていうのは、現実社会と乖離してるんです
かね。日本でガッカイっていうと、なんか頭の良さそうな
人間が陰でコソコソ集まって頭の悪い人間をだます相談を
してるんじゃないかっていうイメージしかない (多少誇張
しております)。

--

http://blog.japan.cnet.com/sasaki/2007/01/post_10.html

しかし、いまだに『匿名は卑怯だ』とかヌカすバカが
いるのか。しかも、情報源の秘匿を絶対とする新聞社にも。

まぁ、確かに、実名というのは手軽なフィルタにはなる。
たとえば、c2 Wikiでも、WardAndKentの署名記事を探したり
するわけだ。でも、それは肩書に対するフィルタとして
名前を使ってるんじゃなくって、過去の実績に対する
フィルタとして名前を使ってるわけだ。もし仮に今
『WardAndKentの本名はHigeAndHageだったんだ!』って
いうことになっても、ビックリはするけど驚きはしない。

そんなこといったら芸名やペンネームなんかどうすんの?
本名は明かしてるんだろうけど、積極的に明かしてる
わけじゃないよね? 少なくとも、1冊1冊の本に本名が
書かれてるわけじゃないし、出版社に問い合わせたら
答えてくれるの? くれねーじゃん? じゃあ、それって
卑怯じゃないの?

毎日はもちろん、もうスポニチも読まねーよ、コノヤロー!

  記者は名刺を出すことさえ、ためらうこともある。

うわ、最悪だな、コイツ。そんなん、当たり前じゃん。
取材されるほうだってリスクがあるのに、なんで記者だけが
ノーリスクなんだよ。バカか?

本家Permlink


2007年01月26日

Windowsプログラマを観察していて、またまた驚愕の事実が!

一般的なPCのキーボードってシフト・キーの下にCtrlが
ありますよね。で、左手の小指をCtrlに置くのは、まぁ、
よくあるといえばある。でも、その「彼」は、小指をCtrlに
「置いたまま」、薬指でシフト・キーを押す!

これがシフトとCtrlを同時押しするための一時的なものなら
そんなに驚かなかったんですけど。

いや、Windowsプログラマがみんなそうやるわけじゃない
でしょうし、このスタイルがことさら珍しいわけじゃない
かもしれませんけど。でも、自分にはかなり衝撃的でした。

Windowsプログラマっていうのは、ホーム・ポジションに
全然固執しないんですね。まずそれが信じられないんです
けど。ホーム・ポジションに固執しないのは、ファンク
ション・キーを多用し、矢印キーを多用し、かつマウスを
多用するからなんですけど。

--

計画は見直すもので、前に立てた計画 (つまり優先度) に
固執しすぎるのはよくありませんよね。「放置されてるなぁ」
と感じるタスクがあるなら、その優先度を上げるか、または
そもそもそのタスクが必要なのかを考え直すタイミングだと
いうことなんじゃないでしょうか。

--

それと、あまりにも多くの細かいタスクが目の前に積まれて
いても、気分がふさぐだけであんまりよくありませんよね。
目の前にあるのは、少数のすぐやるものだけにして、あとは
長期的なスケジュールに突っ込んでおいたほうが気が楽です。
もちろん、短期的なスケジュールも、長期的なスケジュールも、
定期的に見直す必要があります。

本家Permlink


2007年01月25日1

http://itpro.nikkeibp.co.jp/a/biz/shinzui/shinzui1122/shinzui_06_01.shtml

ストック・オプションが必ずしもいい手段ではないと
思ってるのは自分だけじゃないみたいで。

ITは重要ではないといいつつも、知識は重要だという
主張には矛盾を感じちゃいます。だって、知識っていう
のは、いつでも利用できる形にしとかないと意味がない
から。で、知識を形にするにはいろんなやり方があるん
ですけど、たとえば文章とか、でも、その中でもプロ
グラムにするのはかなり優れたやり方なんじゃないかと
思います。

確かにこれまでのIT業界っていうのは、土建屋のマネ
ゴトをして、そのイメージとは裏腹に、体質は旧態
依然としたものでした。でも、今、それが急速に変わり
つつあるんじゃないかと。これからの知識労働者の
新しい形を作っているのはIT業界なんだと、そう思って
ます。まぁ、期待半分ですけど。

--

ああ、ドラッカー氏がいいたかったのは、ITといえども、
それは企業活動の一部に過ぎないんだということなんで
しょうね。だから、ITで何をするかが重要だという
ことで、闇雲にIT, IT騒ぐもんじゃないっていう。

--

そっちの記事には、確か前にもコメントしたと思うん
ですけど、標準化っていうのは、必ずしも優れた手段
じゃないと。標準化っていうのは、差別化とは対極に
あるもので、それはすなわち価値の低下であると。
だから、その企業のノウハウをIT化することは大切
なんですけど、それが標準化できるかどうは全然問題
じゃなくって、むしろ標準化できないほうが価値の
高い知識をIT化してるんだということ。もちろん、
企業には定型的なことも多くって、そういうのは
標準に従ったほうがいいんだけど、まぁ、そんなのは
タカが知れてる。それにISOナンチャラとか、従う
だけムダな標準もあるし。

--

そう。自分なんかも企業への帰属意識よりも、職業プロ
グラマなんかのコミュニティといったものへの帰属意識の
ほうが高いんですよね。日本じゃまだ少数派なんでしょう
けど。

で、自分みたいな人間をまとめ上げて、プロジェクトを
回してかないといけないわけで、やっぱりそれはむずか
しいんでしょうね。他人ごとですけど。

--

そうそう。IDEの支援を得るのに静的な型は必須じゃ
ないんですよね、当たり前ですけど。

たとえばSmalltalkなんかでは、引数名を型で表すことが
慣習になってますよね。anIntegerとか。そういう慣習が
期待できるんであれば、その慣習を前提にIDEがサポート
すればいいわけです。『それじゃ静的型と変わんないじゃ
ないか!』って怒る人もいるでしょうけど (笑)。

だから早くRubyにもキーワード引数を導入しましょう。

--

自分も、あんまりあの本には思い入れはありません。
何しろ、誤った多重継承の典型例であるあのスタックの
実装の印象が強すぎて。それにDbCも結局理解できません
でしたし、実践しようとも思ったことはありませんし、
誰かやってるのを見たこともありません。唯一使ってた
のは『Accelerated C++』なんですけど、この本もまた
あんまり良くなかったというのは以前ここで書きましたね。

でも一応注文はしちゃいました (笑)。

本家Permlink


2007年01月25日

ミシェル・ウィーのコーチ、デービッド・レッドベター氏の
言葉:

  うまくいくと『こんなに良いことが続くはずがない』と
  自分にブレーキをかけたり、成功する自分の姿を思い
  描けず、自滅するプレーヤーは案外多いものです。
  失敗を恐れない勇気は必要ですが、プロにはもう一歩
  進んで、成功を恐れない勇気も必要。それがないと
  大成できません。

     東スポ (2007-01-25)『新・素顔の宮里藍』より

本家Permlink


2007年01月24日1

教えていただいた翻訳のページ、獲物のほうにリンクが
ありますけど、残念なことに、改訂される前のものの
ようですね。多分、話の大筋は変わってないんでしょう
けど。

古いのにすぐ気づいたので読むの止めたんですけど、
ちょっと気になったのが:

  そしてXPの世界ではテストとデザインがとても絡み合っているために、[モッ
  クオブジェクトを使ったテストは]設計と開発についての[XPとは]異なる考
  えであることを暗示している。

『XPとは』っていうのは訳注だと思うんですけど、これは
多分間違い。だって、classicistとmockistのどっちも
XPerであることに変わりはないから。というか、テスト
手法の違いだけでXPかどうかが決まるわけありませんよね。

M.Fowler氏がいってた『異なる考え』っていうのは、
『classicistとは違う』っていう意味でしょう。

多分、M.Fowler氏が記事を改訂したのも、モックその
ものの誤解もさることながら、BDDについての誤解も
解きたかったんじゃないですかね。BDDはTDDとは違う、
つまりBDDはXPではない、みたいな誤解を解きたかった
んじゃないですかね。まぁ、BDDの人からいわせれば、
『BDDはXPとは違う!』っていうのかもしれませんけど。
でも、上で書いたように、BDDっていうのは、TDDと同じ
ように、開発のごく一部を占める話題でしかないので、
BDDかTDDかでXPか否かを問われるなんてことはナンセンス
です。

--

そう。LispはLisp (によるDSL) しか産まなかったがゆえに
衰退し、Cは他の言語のアセンブラになることで繁栄した。

--

いや、衰退も何も、最初からメジャーだったことは
ないんだから。そう考えれば、微増を続けてるのかも
しれないぞ。

--

でも、そのLisperの臆病さが、あのdoを産み出したん
なら、『ちょっとカンベン』っていいたくなりますよねぇ。

『バランスが肝心だよね』なんていうチンプな結論には
持ってきたくないんですけど。でも、直交性にしても、
アトミックなAPIとしてのイテレータの話にしても、
何かの粒度を落とすことにつながるんじゃないですかね。
結局、その細かい粒度で便利になるかどうかっていう話に
なっちゃうんじゃないですかねぇ。

自分は実利主義者で、Unix信奉者で、だから2:8の法則の
信者でもあって、そういう意味で、反ミニマリストを
唱えるまつもとさんのRubyのほうが身近かなぁと。
Railsは使ってないけど、convention over configurationに
共感を覚える自分としては、静的型を疎ましく感じる自分と
しては、なんでもはっきり書かなきゃいけない言語のほうが
イヤだなぁと。

--

spikeなんかの『深さ優先』を別の言い方をすれば、
『結合を急ぐやり方』。

機能Aにサブ機能a1, a2, ... anがあり、
機能Bにサブ機能b1, b2, ... bnがあるとしよう。

このとき、a1, a2, ... anというように実装して、さらに
b1, b2, ... bnという実装の進め方をするのが幅優先。

一方、axを実装したらbxを実装し、その結合をまずやる。
次にayを実装したらbyを実装し、ayとbyを結合する。
そういう実装の進め方をするのが深さ優先。

前にも書いたと思うけど、『層』という言葉は上下関係を
連想させるんだけど、機能群には上下関係がないことも
多い。一般的にはユーザに近い方を『上の層』、より
システムの核に近いほうを『下の層』と呼んだりするん
だけど、結構曖昧なもの。あるいは、複数の機能に
またがることを『機能群を横断する』という表現も
できるし、そうすると深さ優先が連想させる『縦方向』
とは反対になっちゃう。まぁ、spikeなんかを知ってれば
問題になることはないんだけど。

--

MVCの功罪というか、罪として、『フレームワークに
従っていればドメインと表現の分離は達成できる』と
誤解されてることがあげられる。

ドメインと表現の分離っていうのは、そこら中にある
もので、何もフレームワークに従っているかどうかだけで
決まるものじゃない。

たとえば、1つのCanvasに複数のビューが描画されることも
ある。だって、Canvasに描かれる四角形や三角形は紛れも
なくビューだし、その形の頂点群はモデルだし。

class RectangleModel
  def initialize(x, y, width, height)
    ...
  end
end

class RectangleView
  def initialize(aRectangleModel)
    ...
  end

  def paint(aGraphics)
    ...
  end
end

class MyCanvas < Canvas
  def addShape(aShape)
    @shapes << aShape
  end

  def paint(aGraphics)
    @shapes.each{|aShape| aShape.paint(aGraphics)}
  end
end

あるいは、複数のGUIコンポーネントが乗っかった
ダイアログボックスなんかも、実はその裏には何か
モデルがいるのかもしれない。だって、入力の何らかの
まとまりを表現しているのがダイアログボックスなわけで、
それは、たとえば『ページ設定』モデルだったり、
『オプション』モデルだったりするのかもしれない。

--

オブジェクト指向プログラミングなんて、結局は自分の
頭がかいた汗の中にしか残らないんじゃないですかね。
本はただのきっかけに過ぎないっていうか。本読んで
『わかった!』って思っても、だまされることが多くて (笑)。
それよりも『ああ、あの本に書かれてたことは、こういう
ことだったのか!』っていうことのほうが多いもんでしょ。
その『こういうことだったのか!』に至るまでは自分の頭で
汗をかかなきゃいけない。違う?

本家Permlink


2007年01月24日

あぶねー、あやうくだまされるとこだった。

こないだ取り上げた「東洋経済」で誰かが「NTTデータの
受注が多いのは市場シェアを反映して当然のこと」って
いってたんだけど。

いや、そりゃそうだけど、でも、元国営の巨大企業だった
わけで、それは市場シェアとは全然関係なかったわけで
しょ? この資本主義の世の中で、「潰れない」っていう
状態から一気に「莫大な資本」を得た「巨大組織」っていう
のは計り知れないメリットなわけでね。そういう過去の
経緯があってこその今の市場シェアなわけでしょ?
そんなもん、他の民間企業と同じ土俵で評価するのは、
少なくとも公共事業っていう公平さが求められるケースで
どうよ?っていう。

--

すまん。いいすぎた。

--

全画面モード派っていうのは、やっぱりタスクバー隠さ
ない派なんだよな。

自分なんか、そもそも全画面モード派がいるってこと
自体、信じられないんだけど。

本家Permlink


2007年01月23日1

http://martinfowler.com/articles/mocksArentStubs.html#ChoosingBetweenTheDifferences

そのうち誰かが (BDDの大家とかが) 訳してくれるだろう
と思って、あんまし真面目に読んでません。

自分も、M.Fowler氏に近い立場ですかね。Classic TDDer
であり、Mockistに変わる必要性を感じていません。
まぁ、仕事じゃロクにTDDできてないんですけど (笑)。

仕事以外となると、自分でテスティング・フレームワーク
(のパチモン) を書くことが案外あって、そういうのも
Classicistに留まらせてる理由の1つです。自分で書く
なら単純なほうがいいですから。

とはいっても、一番の理由は慣れでしょうね。日記を
調べてみたら、2000年夏ぐらいに『リファクタリング』を
読んで、それからJUnitを使いはじめてるようです。もう
そんなに経つんですね。

--

XPEを読んだのは同じ2000年の3月。そのころの日記を
読み返すと、さすがに的外れなことも書いてますね。
でも、XPEを読み始めたきっかけとして、それまでの開発
手法論に疑問を持ってたことをあげてて、それは今でも
間違ってなかったと思ってます。そのころの手法論って
いうのは、分析と設計ができれば実装なんてチョロイぜ
っていうもので、今から考えてもキチガイのタワゴトと
しか思えません。

本家Permlink


2007年01月23日

GUIコンポーネントのサブクラスを作んなきゃいけないのは、
GUIフレームワークが悪いか、GUIフレームワークの使い方が
悪いかのどっちか、あるいはその両方が原因。

たとえば、最初のAwtはイベント処理するのに必ずサブ
クラスしなきゃいけなかったし、MFCなんかも典型的に
悪いフレームワーク。

で、Swingになってもサブクラス作るのは使い方が悪い例。

これは以前、「便利ならサブクラスしてもいいんじゃ
ない?」っていわれたんですけど、自分は今でもそうは
思ってません (笑)。

サブクラスを避ける理由はいくつかあって、1つは
「デザインパターン」でいわれてるように、動的に
コンポーネントを組み合わせることで、システムが柔軟に
なるっていうこと。もう1つは、いわゆるモデルとか
ロジックとか呼ばれるものに意識を向けやすいこと。
そのモデルとかロジックとか呼ばれるオブジェクトこそが
システムの核心であって、もっとも価値が高い部分。

もちろん、UIは重要なんだけど、そのUIにしても核心を
突いたUIと、そうでないUIとじゃ使い勝手が変わって
くるだろうし。

本家Permlink


2007年01月22日1

我ながら説得力に欠ける。

でも、ヲタクは物欲はあるけど金銭欲はないんじゃないの?
という、非常に矛盾した生き物であって、カネに釣られる
ヤツらばっかりじゃないと思う。もしカネが腐るほどあっても
それを使う暇がないんじゃ、イヤなんじゃないの? しばらく
ガマンすりゃいいっていうのは、パンピーの言い草のような
気がするし。

本家Permlink


2007年01月22日

隠れてやるからスカンク・ワークと呼べるんであって、
それを大っぴらにできたらうれしいかというと、まぁ、
大抵はうれしいんだろうけど、そうでないこともある
んじゃなかろうか。

一定の割合で仕事とは無関係な作業をしなければ
ならないというのは、ある意味、プライベートを仕事
として企業に差し出しているともいえるんじゃないか。
それはそれで健全なんだけど、健全すぎてちょっと
吐き気がしないでもない。

まぁ、でも、総じて、みんなに喜ばれるやり方なん
だろう。

--

ああ、「プライベート」っていうのはおかしいか。
でも、8時間ぜんぶ仕事してるわけじゃないし、それ
以外の時間っていう意味じゃプライベート。

仕事が忙しすぎて自分の時間が全然ないっていう人
にはうれしいし、そうでなければ逆にプレッシャーに
なるかもしれない。仕事以外のコードを書くっていう
のは、人によってはすっごい負担になる。もちろん、
そういう人はGoogleはお断りするだろうけど。

本家Permlink


2007年01月21日4

http://www.c2.com/cgi/wiki?ExtremeProgrammingForOne

自分、今、マシン・ルームみたいな場所で作業してる
んですけど。机の上にマシン置く棚があって。で、
そこにPostIt (正確にはパチモン) でタスクを貼っつけ
てぶら下げてます。まぁ、大抵はバグなんですけど。で、
メモ用紙も使ってて、そっちはさらに細かいTo Doを書いて
ます。

やっぱり紙最強っていうのはありますよね。字は汚いん
ですけど (笑)。PostItで貼りつけてると一覧できますし。

PostIt使えない環境だと、どうしたらいいですかねぇ。
モニタだとちょっとスペースが足りないかも。まぁ、
こういう工夫はその場のヒラメキですからね。

--

当たり前なんですけど、今気づきました。Rubyみたいな
言語だと、メソッドをオーバーライドするのにクラスは
必要ないんですね。

# foo.rb
def foo
  bar
end

っていうファイルがあったら:

require 'foo'
def bar
  p true
end

でもいいし:

require 'foo'
def bar
  p false
end

でもいい。

もちろん、サブクラス作るよりは柔軟性には欠けるし、
危険でもあるんですけど。でも、自分は、危険性は
それほど気にならないクチですね。

本家Permlink


2007年01月21日3

あー、書き直しの話も消したかも。

書き直すときは、今動いてるシステムの価値をちゃんと
見なきゃいけないよっていう話。刷新っていうのは、
ユーザの知識や経験も捨てちゃうことになるし、さらには、
新規開発の間は価値を生まないわけで、それに対して
旧システムは日々価値を生み続けてるわけで。さらに
さらに、新規開発が失敗するっていうリスクもあるし。
そう考えたら、おいそれと『刷新しますぅ』なんていえる
わけない。

単にコードが汚ないとか、そんな理由で書き直しちゃ
いけないよね。いくらだってリファクタリングできるん
だから。それに、M.Fowler氏のいうStranglerApplication
っていうやり方もあるし。

だから、書き直すかどうかの判断はビジネス上の判断
なんだよね。当たり前だけど。そこにプログラマの意図が
入り込む余地はあんまりない。

もちろん、オーナーがプログラマ自身である小規模な
ものは好き勝手書き直していいけど。

本家Permlink


2007年01月21日2

ああ、思い出した。もう1つのほう。

XPがソフトウェア開発にビジネスの視点を持ち込んだって
いうのは間違いない。でも、XPの理想はそこにあるわけ
じゃない。

これまでの方法論っていうのは、1つのシステム、あるいは
1つのプロジェクトの成功に焦点を絞っていた。まぁ、
絞らざるを得なかったんだけど。でも、XPっていうのは、
プロジェクトを超えて、長期間にわたって勝ち続ける
組織を作ることを目標というか理想にしている・・・気が
する。

いってみれば常勝軍団みたいなもので。だから、当然、
人を育てることも視野に入ってくるし、チームと組織
全体との関わり合いも考えなきゃいけなくなる。

だから、顧客顧客と騒ぐのもちょっと違う気がする。
まぁ、商売なんだから顧客を大事にするのは当然なんだ
けど。でも、大前提として、組織が生き残らなきゃいけ
ない。それが根っこにあって、そこから顧客重視っていう
のが生まれなきゃいけない。

商売になんないなら、別の市場に移らないといけない
わけで、それは顧客を裏切ることになるかもしれない
けど、生き残れなきゃ意味がない。

まぁ、当たり前すぎて、わざわざ書くまでもないこと
なんだけど。

結局のところ、XPを実践するならば、すべてをinvolve
しないといけないし、すべてにinvolveされないと
いけないってことなんじゃないかな。だからこそ、
カドに隠れていることは許されない。

これを消したのは、気分が乗らなかったのと、こういう
ことを書くと引く人がいるから。それと、最初っから
理想ばかり追い求めてもムリがあるし、自分だって、
普段からこういうことばっかり考えてるわけじゃない
しね。

--

だから、そういう意味で、市場を変えようとしている
任天堂は好感が持てるし、実際に市場を変えたIBMも
好感が持てる。Appleもそう。でも、Sunは? Sunは
市場の変化についていけてないように見える。
いつまで経っても本質はサーバ屋で、まぁ、いろいろと
やってるのかもしれないけど、少なくとも今のSunを
『イノベーションの旗手』だなんて、とてもとても
呼べない。

本家Permlink


2007年01月21日1

あれ? ついこないだ、『wstring使えねぇのかよ!』
って怒り狂ったんですけど、いつのまにか使えるように
なってますね。sidの話なんですけど。

#include <iostream>
#include <string>

using namespace std;

int
main(int argc, char* argv[])
{
    wstring msg = L"hello, world";
    wcout << msg << endl;
    return 0;
}

--

http://home.att.ne.jp/sigma/satoh/diary.html

2007年1月19日の記事。獲物で取り上げるだけでもよかった
んですけど、ちょっとだけコメント。

以前、artonさんがいわれたように、全体としてUI重視な
方向に流れていると感じています。ちょっと前でいえば
Flushの流行ですし、今でいえばNDSやWii。それは『見た目』
という単純なデザインではなく、それこそexperienceと
でも呼ぶ、見た目や使い勝手を合わせたユーザ満足度、
快感度といったものです。

あんまりこういうことを書きたくないんですけど、そういう
意味でも若い人は一度はMacを使ったほうがいいでしょう。
『一度は』というのは、最低1年以上日常的に使うという
意味ですけど。

センスというのは判断の速度のことで、それを鍛えるには
良いといわれているものを日常的に使うのが一番だからです。

まぁ、自分は二度とMacは使いませんけど。
Apple嫌いになったから。

--

http://www.amazon.co.jp/Institute-Co-Ltd-13306371-%E6%9B%B8%E3%81%8D%E8%BE%BC%E3%81%BF%E5%BC%8F%E3%80%8C%E8%88%AC%E8%8B%A5%E5%BF%83%E7%B5%8C%E3%80%8D%E7%B7%B4%E7%BF%92%E5%B8%B3DS/dp/B000M7N93G/sr=1-1/qid=1169347836/ref=sr_1_1/249-7871175-1125122?ie=UTF8&s=videogames

あははは!

--

ガンダムって、そんなに深いもんかぁ?

オレはコンバット世代だからな。ガッコから帰ってくると
毎日のようにやっててさ。『サンダース軍曹カッチョエエ!』
『トンプソンほっすぃ!』てなもんで。

んなもんだから、ガンダムはイマイチ。ガンダムにノれない
のは、結局、アムロのガキっぽさに尽きるんだよな。

そりゃガンプラ作ったこともあるけどさ。でも、オレが
読んでたころのホビージャパンはやっぱりミリタリーもんが
ほとんどだったしなぁ。

--

消したのは2つだったかな。

1つは『Sunがイノベーションだなんて笑わせるな』って
いうのと、あとなんだっけな。

--

つかさー、Windowsプログラマって、キーボードの使い方が
全然違うのな。手がホーム・ポジションに置かれてる時間が
全然短い。

よくあるのが左手は上 (ファンクションキー) で、右手は
マウス。ひどいときは両手とも上にあったり。で、コード書く
ときは、右手がせわしなく右に飛ぶ (矢印キーとかいろいろ)。

あとさー、端末エミュレータとか、いちいち起こすのな。
あれはよーわからん。起動する順番決めといて、これはこの
ディレクトリとか決めといたほうがラクじゃん? タスクバーで
左から何番目はこれって決めといたほうが。

ウィンドウにしてもそう。なんか、いちいち場所動かすのな。
そんなんやったら見つけにくくなるだけなのに。

--

http://d.hatena.ne.jp/thata/20070119#1169199729

やっべー。いやらすぃゲームを妄想してしまいそう。

・・・

ひ、ひらめいてしまった・・・
その名も・・・

DSおなほ〜る!

今までの卓上モニタでは不可能であった、画面を股間に
直接こすりつけるという新たなユーザ体験!
あなたの手と腰の動きに合わせてHヴォイスが!

なお、液体が飛着することによるゲーム機器の損傷に
ついては責任を負いかねますのであしからず。

--

P.Graham氏が西海岸を賞賛するのであれば、渋谷が
ビットバレーと呼ばれるほどITベンチャーが集まった
のもちょっとはうなずけるのか。ただ、渋谷はカジュアル
だけど、オタクには優しくない街だし、やっぱりそんなに
魅力的とは思わない。個人的にも渋谷は縁のない街だ。

じゃあアキバか? たぶん違うね。あそこはもうビジネスの
街になっちゃった。オタクを引き入れようとしてるけど、
それは表面だけのビジネスだし、そんなのはすぐオタク
には見抜かれる。

東京でいえば、ブクロかナカノか。個人的に縁があった
のはナカノ。でも、最近のナカノはよく知らない。ただ、
昔っから住みやすい街であることは確かだし。

ダークホースとして横浜あたりありそうな気がする。
カジュアルなイメージがあるし。東京から離れてる
ほうがいいこともあるかもしれない。

一度は関西圏で仕事をしてみたいものだとは思ってる
んだけど、さすがにもうこの歳だとチャンスはないかも
なぁ。

ああ、今すぐ移るつもりは全然ないんで。早くっても
数年後の話。

本家Permlink


2007年01月21日

glibcのinfo見ると:

     It is important to check for errors when you call `fclose' to close
     an output stream, because real, everyday errors can be detected at
     this time.  For example, when `fclose' writes the remaining
     buffered output, it might get an error because the disk is full.
     Even if you know the buffer is empty, errors can still occur when
     closing a file if you are using NFS.

って書いてあるんです。fcloseが失敗したかどうかを
チェックすることは大切だって。

だとして、実際問題、どうやって対処するかは案外
むずかしくないですか?

fcloseに限らず、資源の開放時にエラーが発生するような
場合、どういうコードを書くか。

こういうのって、大抵次みたくなるじゃないですか:

Resource rcs = getResource();
try {
  rcs.useResource();
} finally {
  rcs.releaseResource();
}

で、このとき、getResourceでも、useResourceでも、
releaseResourceでも例外が起きる可能性があるのが
普通ですよね。Cでいえば、fopen, fgets, fcloseの
どれでもエラーが起きる可能性がある。

で、上のでいえば、useResourceでエラーが起きたときにも、
releaseResourceが呼ばれるわけです。finallyですから。
で、このとき、finallyの中で失敗したら、また新しい
エラーが起きるわけです。でも、フツーに考えれば、
useResourceでエラーが起きてるんだから、releaseResourceも
失敗しておかしくない。

で、何が悪いかっていうと、上に上がってくる例外は
releaseResouceのときの例外なんです。でも、ほんとは
それより前に失敗したuseResourceの例外のほうが重要な
はずなんです。だから、useResourceで失敗したときは、
releaseResourceの失敗は無視しないといけない。

じゃあ、どうするかっていうと:

Resource rcs = getResource();
try {
  rcs.useResurce();
} catch (ResourceException e) {
  ignoresReleaseError = true;
  throw e;
} finally {
  try {
    rcs.releaseResource();
  } catch (ResourceException e) {
    if (!ignoresReleaseError) throw e;
  }
}

他にもやり方はありそうですけど、いえるのは、
結局のところ、例外を使っても、エラー処理をきれいに
まとめることのは案外むずかしいっていうこと。

まぁ、フツーはこんなこと考えないでfinallyでガガッと
資源解放しちゃっていいと思うんですけどね。

本家Permlink


2007年01月20日1

オンビンにオンビンに。

本家Permlink


2007年01月20日

XPの基本に立ち返れば、コミュニケーションが大切です。コミュニケーション
とは、意思を共有することです。意思を共有するためには、意思をはっきりさ
せなければなりません。意思を意思のまま伝えることを以心伝心といいますが、
普通の組織ではとても無理な話です。だから、意思を言葉で表現して、相手と
共有します。

計画もその1つといえます。目標を言葉で表現し、はっきりさせ、組織で共有
します。

ペア・プログラミングでは、考えていることを言葉で表現し、はっきりさせ、
相棒と共有します。

意思を言葉にし、相手に投げかければ、相手から反応が返ってきます。それが
フィードバックです。(反応が返ってこないのもまたフィードバックです。)

そもそもプログラミングという行為が、自分の意思を (プログラミング言語の) 
言葉で表現する行為です。ただし、その言葉を投げかける対象は、コンピュー
タであると同時に、我々人間でもあります。

陽気な人やおしゃべり好きな人が集まっているからコミュニケーションが豊か
になるのではなく、コミュニケーションが豊かであるからこそ、人が陽気にな
り、おしゃべり好きになっていくのです。

本家Permlink


2007年01月19日

ヤメヤメ

本家Permlink


2007年01月18日

と日記に書いておこう。

本家Permlink


2007年01月17日2

あれに特につけ加えることもないんですけど (だから
獲物に載せました)。

前にも引用したことがありますけど、王銘エン九段の
『ゾーンプレス パーク』(日本棋院) から:

  さんざん理屈をならべてきたが、「信じる」とは理屈
  ヌキで行動に出るものだ。(中略)

  君たちは狼に追われている子羊としよう。逃げ道は
  ふたつ、ひとつはくねくね道で、しばらくいくと先が
  見えない、もうひとつは霧がかかっていてすでに何も
  見えない。普通はすこしでも先が見えるほうに行きた
  がるものだが、そこで敢えて霧のかかったほうに飛び
  込めなければ、「信じている」ということにはなら
  ないのだ。

『変わる』ということは行動することから始まります。
逆をいえば、行動に出なければ、いつまでも『変わる』
ことはできません。

やることをTo Doリストにしてみるのもいいでしょう。
xUnitでユニット・テストをやってみるのもいいでしょう。
毎朝stand-up meetingをやるのもいいでしょう。いずれ
にしても、まず自分から動くことです。理屈はあとから
ついてきます。それがフィードバックというものです。

本家Permlink


2007年01月17日1

個人的には、1つの仮想機械の上に多種の言語が乗るって
いうのは、あんまり好きじゃありません。つまんない。
個人的な嗜好と、それが世間で主流になるかは、もちろん
別の話ですけど。

Swingについては何度か書いてますけど、継承を使わなく
ても使えます。新しくなったAwtでも同様。ただ、それを
みんなやらないだけで。

それと、みんな複数の言語を使い分けるようになるか
っていったら、多分それは今後もない。もちろん、正規
表現とか、SQLとか、Makefileとか、そういう意味じゃ
すでにヘテロ言語な開発にはなってますけど。でも、
たとえばJavaとPythonにしても、他の組み合わせにしても、
それほど流行るとは思えません。だったらすでにもう
そうなってるはずです。

言語の学習コストとか、心的負担とか、自分らが思ってる
以上に大きいんですね。1つの言語ですら、それほど
熱心に習熟しようとはしないくらいで。それがほとんどの
現場レベルということでしょう。

そういう「不熱心なプログラマは今後淘汰される」って
いう議論もありえるでしょうけど、ちょっとそれも考え
にくいです。

「乗り換え」っていう現象は今までもあったんですけど、
それは、あくまでも乗り換えであって、複数の言語を
同時に使いこなしてたわけじゃありませんでした。

こういう現象は、「言語の膨張」と裏表です。言語は
機能を追加させ続けるわけで、それは、他の言語を学ば
ずに済ませる結果にもつながるわけです。

実際、UNIXの世界じゃヘテロ言語がわりと一般的だった
でしょう。sh, Awk, Perl, それにTcl/Tkといった言語が
「グルー言語」としてわりと使われていました。でも、
それが今再び広まるかっていうと、ちょっと考えにくい。

--

http://opentechpress.jp/~sado/journal/430

推理正解。

--

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s04510.jsp?p=e_fair,e_fair070120&f=e_fair_top&vos=nytesdjb000000000001

兄弟?

--

まぁ、でも、ほとんどのトップをインドが占めてるわけで。

かといって、経営者レベルでいえば、いきなりマイナーな
言語を選択するわけにもいかないだろうし。

本家Permlink


2007年01月17日


本家Permlink


2007年01月16日1

せんないことをぐだぐだと。

何度も書いてますけど、テストに王道はありません。
テストするために手段を選んじゃいけません。
だから、場合によってはxUnitを捨てなきゃいけない
こともあります。そのシステムに合ったテスティング・
フレームワークを使うこと。フレームワークがなければ
自分で作る。

王道がないということは、それだけ知識の幅が求め
られるということでもあります。プログラミング言語
だけでなく、システムの開発プラットフォームである
OSやその他のインフラをも含めた知識でテストに望む
こと。

TDDでテストに求めるのは安心感、もっといえば着実感。
『ここまでやったんだ』ということを実感できること。

これも何度も書いてますけど、テスト・コードも
リファクタリングすること。しかも積極的に。テストは
命綱なのだから、命綱の手入れを怠ることは即命取りに
なる。

壊れたテストを直すのは、どんなストーリーよりも
優先されます。テストは信号。信号が赤のときは進んじゃ
ダメ。

--

COMはCOMで熱狂的なファンがいたと思うんだけど、あれ
ってVBerにはうれしかったんだろうけど、C++erには
全然うれしくないんじゃないの?

このあたりはPOJOに注目が集まったのと似てる気がする。

COMの目標の1つは、上みたいなヘテロ言語なプラット
フォームっていうので、それはうれしくなかったわけ。
で、もう1つは分散だと思うんだけど。でも、分散ゆー
ても結局はHTTPにすら勝てなかったわけだしね。いや、
『XMLに包めばいいじゃん』っていうのは、負け犬の遠吠え
っぽくない? ニッチはニッチと認めないと、Lisperを
笑えないっつーか。

何度も書いてる気がするけど、こういう昔流行った技術の
総括っつーのは全然ないのね、この業界。

結局、結論としては、ヘテロ言語なプラットフォームを
実現するには仮想機械が必要で、それは当時のCPUパワー
じゃ無理だから、COMはCOMでよくがんばったんだよ
ってことなの?

で、分散なんかは、HTTPでテキスト送って、あとは
ブラウザががんばりゃいいんだよってことなの?
当時はこれほどWebが爆発するとは思えなかったんだから、
COMはCOMでよくがんばったんだよってことなの?

--

いや、ヘンな話だけど、マジメな話、なんでみんな
Windowsで開発やってるか不思議なんだよね。いや、
一番たくさん使われてるOSだし、それが当たり前だって
わかってはいるんだけど、フと疑問に思うときがある
っていう。ここまでプログラマとのギャップが大きい
OSがなんで?っていう。

Mac OS Xは触ったことがないからわかんないけど、もう
ちょっとはギャップは少ないだろうし。だからプログラマで
乗り換える人が多いんじゃないかな。

サーバ・サイドに開発の主戦場が移ってきたのも、
そうした理由が1つにあるんじゃなかろうかと。まぁ、
サーバ・サイドでもWindows使ってるとこも多いだ
ろうけど。

--

あんまり本気にするなよ (笑)

--

今のところ、Javaの残したものといえば、仮想機械に
再び注目を集めたこと、OOPを現実的な手段として定着
させたこと、MS以外の選択肢を与えたこと、の3つくらいか。

この3つとも、どれもJava単独で成し遂げられたものじゃ
ない。仮想機械のためには十分なCPUパワーが必要だったし、
OOPはすでにデザイン・パターンやなんかで波が起き始めて
たし、MS以外のというのについてもオープン・ソースや
インターネット、特にWebの発展があった。

しかし、やはりそのインパクトは大きい。

--

Rubyについては、日本での影響が大きかった。やはり
日本人が作った世界的な言語ということで、世間の
注目を集めた。それによって寡占化が進んでいた言語
市場で新しい選択肢の1つとなった。また、人々の目を
オープン・ソースへと向けるきっかけにもなった。

国外を含めた影響を測るのは難しいが、動的言語を
再評価するきっかけの1つにはなったろう。

--

XPについては、一番大きなものは、ソフトウェア開発を
包括的に扱うという方法論を提示したことにあるんじゃ
ないか。OOA/OODといった技術的な方法論ではなく、また
incremental, iterativeという限定的な方法論でもなく、
ビジネスの中でいかに開発を成功させるかという視点。
注文されたものを作るだけではなく、作ったもので
顧客が本当にビジネスに成功できるかまでを射程に捉えて
いる。

--

細かいことをあげたらキリがない。フツーに
『リファクタリング』なんていう言葉を聞くように
なったし。自分なんか、なんか気恥ずかしくって
『リファクタリング』ってよういわれへん。『いじる』
とか『整理』程度でお茶を濁すことが多い (笑)。

本家Permlink


2007年01月16日

机を見れば、その人となりがわかるといいます (笑)。

http://image.itmedia.co.jp/enterprise/articles/0701/15/P1100865.jpg

--

どんなものを難しいとするか、いろんな基準があるわけ
ですけど、その1つとして「ユニット・テストが書き
やすいかどうか」というのもあるんですよね。

コード量は大したことなくっても、それを確かめるための
ユニット・テストを書くのが難しいっていうことも、
結構あります。そういうのを一言で「簡単だ (容易だ)」
といってしまっていいものか。もしTDDでやってるなら、
そこいらへんを含めて「難しさ」というものを評価しない
といけないんですね。

本家Permlink


2007年01月15日1

Rubyのabortはコア吐かないのか。

本家Permlink


2007年01月15日

くどいけどさらにもう一度。

結局、Googleのやり方をクライスラーが採用できるか、
そして、もし採用していたとしたらC3プロジェクトが
成功したのかってことだよな。

どっちもYESと答えるのは現実的じゃない。

C3プロジェクトはクライスラーの社運を賭けたプロジェクト
じゃないし、給料システムの一部に過ぎない。そのために
クライスラー全体の労働形態を変えるっていうほうが
バカげてる。それに、企業として、ある部門だけ特別
扱いすることはフツーはできない。

それに、C3みたく、給料システムとか、そういういって
みれば「つまんない」ソフトウェア開発っていうのは
無数にあって、よっぽどそっちのほうが多いし、そう
いうシステムのために頭のいい人は集まらないし、
企業のほうもメシをタダにするとか、そういったことは
やらない。

確かにDebianの鵜飼さんとか、Namazuのさとるさんとか、
Googleには自分も尊敬する素晴らしい人たちもいるけど、
あんなふうなバカもいるんだし、Googleの先行きが
まったくのバラ色だとはいえないんだよな。

--

いや、さっき消したのはさすがに問題発言だった。

本家Permlink


2007年01月14日1

# stdpipes.rb

class Stdpipes
  class ParentPipes
    def initialize(to_child, from_child, err_from_child)
      @to_child = to_child
      @from_child = from_child
      @err_from_child = err_from_child
    end
    attr_reader :to_child, :from_child, :err_from_child

    def close
      @to_child.closed? or @to_child.close
      @from_child.closed? or @from_child.close
      @err_from_child.closed? or @err_from_child.close
    end
  end

  class ChildPipes
    def initialize(stdin, stdout, stderr)
      @stdin = stdin
      @stdout = stdout
      @stderr = stderr
    end
    attr_reader :stdin, :stdout, :stderr

    def close
      @stdin.closed? or @stdin.close
      @stdout.closed? or @stdout.close
      @stderr.closed? or @stderr.close
    end

    def bind_streams
      $stdin.reopen(stdin)
      $stdout.reopen(stdout)
      $stderr.reopen(stderr)
    end
  end

  def initialize
    @in_pipe = IO.pipe
    @out_pipe = IO.pipe
    @err_pipe = IO.pipe
  end

  def for_parent
    @in_pipe[0].close
    @out_pipe[1].close
    @err_pipe[1].close
    result = ParentPipes.new(@in_pipe[1], @out_pipe[0], @err_pipe[0])
    @in_pipe = nil
    @out_pipe = nil
    @err_pipe = nil
    return result
  end

  def for_child
    @in_pipe[1].close
    @out_pipe[0].close
    @err_pipe[0].close
    result = ChildPipes.new(@in_pipe[0], @out_pipe[1], @err_pipe[1])
    @in_pipe = nil
    @out_pipe = nil
    @err_pipe = nil
    return result
  end
end

if $0 == __FILE__
  pipes = Stdpipes.new
  if fork
    pipes = pipes.for_parent
    pipes.to_child.puts('hello, child')
    p pipes.from_child.gets
    p pipes.err_from_child.gets
  else
    pipes = pipes.for_child
    pipes.bind_streams
    puts(gets)
    $stderr.puts('hello, parent')
  end
end

本家Permlink


2007年01月14日

もう一度書くと書いたので、ムリヤリでももう一度書く。

XPは成功を約束するものじゃない。プロジェクトを成功
させる要因はたくさんあるが、それと同じように、プロ
ジェクトを失敗させる要因もたくさんある。

XPに限らず、開発手法というのは、ソフトウェア開発と
いうビジネスにおいて、それほど強い存在ではない。
いくら開発がうまくできても、モノが売れなきゃ意味が
ない場合もあるし、たった1つのバグですべてがフッ飛ぶ
ことだってある。そういったことすべてが、プロジェクトを
キャンセルする (失敗と認める) 原因になり得るわけで、
そこに開発手法の限界というものがある。

http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System

これを読むと、C3プロジェクトがキャンセルされた理由は
2つあるようだ。1つはパフォーマンスの問題。そして、
もう1つは、クライスラーがダイムラー・ベンツに買収
されたこと。

パフォーマンスの問題は技術的な話だが、Smalltalk +
GemStoneという選択肢そのものが誤りだった可能性も
ある。とはいえ、それ以外の選択肢を選ぶとすると、
プロジェクトをキャンセルするほかないだろう。

買収については、まさに政治上の話で、ソフトウェア
開発の手法でどうにかなる問題じゃない。

いずれにしてもC3はキャンセルされたわけだが、ダイムラー・
クライスラーがあとになってXPをもう一度採用したと
ある点は銘記しておくべきだろう。さらに、まだ成功したか
どうか結論を出すのは早いかもしれないが、一番下で紹介
されているFordのVCAPSプロジェクトでもXPが採用され
ている:

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

誰も『3人でペア・プログラミングできたほうがいい』
なんていったことはない。それは悪質なウソだ。

Scrumについては自分は言及しない。知らないから。

WardAndBeckが自分たちを騙しているのか? ならば、
WardAndBeckがこれまでやってきたCRCカードやデザイン・
パターンなどもカタリだったのか。WardのWikiもそう
なのか。XPだけがカタリと考えるのか。それは現実的じゃ
ないだろう。

間抜け、間抜けと連呼しているが、自分は明らかに
間抜け側の人間であり、だからこそ規律が必要だ。
それにしても、たった一年でXPを否定できるとは、
ずいぶんと頭のいい人なんだな。

Googleが特異だということはわかる。しかし、特異だから
こそ、XPを否定することはできないだろう。XPは特異でない、
間抜けな人のためのものなのだから。

ただ、インセンティブについては、日本では伝統的に
会社への忠誠心が高い。いや、高かったというべきか。
それは何も、好き勝手わがままできるからじゃなく、
高い報酬がもらえるからでもなく、日本の社会的な
文化だ。もちろん、終身雇用も影響している。つまり、
生き生きと働くための手法論はGoogleだけがすべてじゃ
ないということだ。

ちなみに、XPチームが目指すべき究極の形態は、XPを
意識しないことだ。個人個人のすべての行動が、意識
せずに、XPの価値に沿っている状態だ。しかし、人間と
いうものは段階がある。いってみれば、Googleは、その
段階をスッ飛ばそうとしているわけだ。最初っから頭の
いい人たちを集めたり、豊富な資金をバックにした
サポートをやったりして。

しかし、そこで浮かんでくるプログラマ像というのは、
やはり子どもっぽい:

http://www.yamdas.org/column/technique/googlifej.html

XPが計画にこだわるのは、ソフトウェア開発がビジネスと
して成功しなければならないからだ。ビジネスの中の
1つとしてソフトウェア開発を捉えた場合、そのビジネスに
携る人はソフトウェア開発者だけじゃなくなる。そうした
人たちとどうやって連携していくか。計画しかないじゃ
ないか。

『課外活動』と呼ばれるものが、もしチーム全体に
影響するものならば、それはストーリーとして扱うべき
ことだ。それができないようでは、そのチームはXPでは
ない。

まぁ、結論をいえば、間抜けは間抜けなりにやってる
んだから、ほっといてくれってところか。

--

いってみれば、クソゲーはクソゲーなわけ。そのコードが
どんなにきれいに書かれていようと、納期どおりにリリース
できようと、クソゲーはクソゲーで、売れなきゃどうしようも
ない。

だから、売ろうと思えばいろんな人の協力が必要になるし、
そうなれば計画が必要ということになる。

なおかつ、ビジネスとしては早い段階で成功するかどうかの
手応えをつかみたいっていうのがある。だから、システムを
できるだけ早く独り立ちさせたい。そのためにはどこから
先に手をつけるか、そこからどう肉付けしていくかを
決めなきゃいけない。それもまた計画なわけ。

ぶっちゃけいえば、XPでは日程よりも、この手順について
こだわる。日程というのは、実際にストーリーをこなして
いく中で、統計的、経験的に決まっていく。

--

しかし、今でも自分のブチキレに真面目に反応してくださる
方がいるとは、感謝、感謝なのです。

本家Permlink


2007年01月13日

そういえば仕事先で『粋Z』の話したら、だ〜れも
知らなくって、ビックリした。

『姉ちゃんの詩集』も、だ〜れも知らなくって、
ビックリした。

最近の若いヤツらのアンテナは感度低いのか?

--

そういう意味じゃ吊り広告の効果も下がってるんだろう
なぁ。だって、みんなケータイばっか見てるもんな。
前は電車乗ったらやることなかったヤツらも多かった
けど。

まぁ、広告業界は儲けすぎだからどうでもいいけど。

--

あとで書くって、それでみんなが読んでくれりゃいい
けどさ。アンテナはそこまで賢くねぇからなぁ。

--

当然ながら、プログラマはフォントに敏感だ。毎日何
時間も見るわけだし。

オレがWindowsを嫌いな理由の1つは、あのクソダッセー
フォントにあるのは間違いない。

本家Permlink


2007年01月12日

それこそdiffが好例になるじゃないですか。Gnu diffは、
入力ファイルに改行がないとメッセージを出すわけです
けど、「ファイルが改行で終わらないときはメッセージを
出す」っていう機能のテストをテストするときには、
当然、改行で終わらないデータを用意しないといけ
ません。だから、あの記事でテスト・データのことに
ついて言及したわけです。

改行で終わらないファイルを作るのは別にEmacsでなきゃ
できないわけじゃないですけど、Emacs使いはEmacsを
常に立ち上げてますから、Emacsを使うのが一番手軽な
はずです。M-! echo -n hello >hello.outとか、
やらないでしょう。

まぁ、これは以前までのEmacsが改行を勝手に入れない
っていうのに慣れていたっていうのもありますけど。

--

結局のところ、「いわれたことをやればいい」というのと
正反対のところにあるのがカイゼンということだ。

本家Permlink


2007年01月11日2

出直してきた:

#!/usr/bin/env ruby

class Buildep
  class Srcfile
    def initialize(filename, cppflags='')
      @filename = filename
      @cppflags = cppflags
    end

    def write
      target, deps = scan_includes
      deps.map!{|dep| "'" + dep + "'"}
      printf("file '%s' => [%s]\n", target, deps.join(', '))
    end

    def scan_includes
      makeline = `cpp -M #{@cppflags} #{@filename}`
      tokens = makeline.split
      target = tokens.shift
      target.chop!
      tokens.delete_if do |dep|
        '\\' == dep or dep.index('/usr/include/') == 0 or
          dep.index('/usr/lib/') == 0
      end
      return [target, tokens]
    end
  end

  def write(cppflags='')
    filenames = Dir.entries('.').select{|e|
      /\.(c|cpp|cc|cxx|C)\z/ =~ e
    }
    srcs = filenames.map{|filename| Srcfile.new(filename, cppflags)}
    srcs.each{|src| src.write}
  end
end

if $0 == __FILE__
  Buildep.new.write
end

相変わらずカレント・ディレクトリの中だけだけど。

本家Permlink


2007年01月11日1

glibcのregex.h (多分POSIXのもそう) の/./は改行に
マッチするんですよね。Rubyとの違いに戸惑った覚えが
あります。

本家Permlink


2007年01月11日


本家Permlink


2007年01月10日1

ビルドした後、バイナリ消すのがメンドイんで、ファイル・
タスク全部消すことにしました。あんまり深く考えてない
んで、ウカツに使うと危ないかも。

require 'task/clean'

task :clear do
  filetasks = Rake.application.tasks.select{|t| t.is_a?(Rake::FileTask)}
  tasknames = filetasks.map{|t| t.to_s}
  tasknames << '*.o'
  CLEAN.include(*tasknames)
  Rake.application[:clean].invoke
end

なぜか2回消すけど気にしないように。

--

またしてもmakeの基本を知らなかったことが発覚:

foo.o: foo.c foo.h
foo.h: baz.h

こういう書き方をしても、baz.hが新しくなったときに
foo.oがビルドされることはない。

これはRakeでもおなじ。

foo.hとbaz.hとの間に依存関係を張りたいときは:

foo.o: foo.c foo.h
foo.h: baz.h
	touch $@

みたいにしないといけないみたい。

でも、ほんとか? 例のごとく、なんか勘違いしてそう。

--

だったら上のは、次みたくやったほうがよさそう:

require 'rake/clean'
CLEAN.include('*.o')

def exe(relation)
  target = relation.keys[0]
  file target => relation[target]
  CLEAN.include(target)
end

exe 'hello' => ['main.o', 'hello.o']

これの前に、こないだ書いた.exeのルールを定義して
おかなきゃいけないけど。

--

あと、ほんとに単純に#includeの依存関係を抽出する
スクリプト。こないだここに書いたと思ったんだけど、
勘違いだったらしい。

#!/usr/bin/env ruby

class Buildep
  class Srcfile
    def initialize(filename)
      @filename = filename
      @dependants = []
    end

    def read(filenames)
      text = File.read(@filename)
      scan_includes(text, filenames)
    end

    def scan_includes(text, filenames)
      text.scan(/^#include.+/) do |matchline|
        matchline.scan(/(?:"|<)([^"<>]+)(?:"|>)/) do |match|
          included = match[0]
          filenames.index(included) or next
          @dependants << included
        end
      end
    end

    def write
      @dependants.empty? and return
      if src?
        write_src
      else
        write_header
      end
    end

    def src?
      return /\.(c|cpp|cc|cxx|C)\z/ =~ @filename
    end

    def write_src
      deps = @dependants.unshift(@filename)
      quoteds = deps.map{|dep| "'" + dep + "'"}
      printf("file '%s' => [%s]\n", objname, quoteds.join(', '))
    end

    def objname
      return @filename.sub(/\.[^.]+\z/, '.o')
    end

    def write_header
      quoteds = @dependants.map{|dep| "'" + dep + "'"}
      printf("file '%s' => [%s] do |t| touch %s end\n",
             @filename, quoteds.join(', '), @filename)
    end
  end

  def write
    filenames = Dir.entries('.').select{|e|
      /\.(c|h|cpp|hpp|cc|hh|cxx|hxx|C|H)\z/ =~ e
    }
    srcs = filenames.map{|filename| Srcfile.new(filename)}
    srcs.each{|src| src.read(filenames)}
    srcs.each{|src| src.write}
  end
end

if $0 == __FILE__
  Buildep.new.write
end

--

そうなんだよなぁ。80%のがんばりでうまくいかせるには、
やっぱり慣習が大事なんだよなぁ。

まぁ、上のスクリプトなんかは全然がんばりが足りない
けど。でも、これを100%がんばろうとすると、もう時間が
いくらあっても足りない。だって、Cの構文解析とか
やんないといけないし。(だから、巷の構成ツールなんかは
cpp使って手間を省いてるらしいんだけど。) で、残りの
20%を慣習で補えるんなら、それでいいじゃんっていう。

この100%を求めないっていうのは、LLにぴったり来るしね。
100%がんばらずに当たればメッケモノだし、外れても、
まぁ、自分にとって便利ならそれでいいし。

--

ああ、今cppのinfoチラ見したんですけど、cpp -Mで
ソース・ファイル喰わせたほうが楽ですね。これだと
さっきのヘッダがヘッダをインクルードするケースも
抽出できます。

あ〜、この徒労感。でも、cppが使えるとわかったん
だから、ついてる! といっておこう。

本家Permlink


2007年01月10日

excellentなプログラマはデバッグが上手いんだよな。
デバッガを手足のように使うし。

まぁ、自分はgoodなプログラマを目指してるわけで、
バグを最初っから出さないことのほうに力を入れたい
んだけど。

本家Permlink


2007年01月09日

ん〜、Rakefileは結局Rubyなんで、できないことは
ほとんどないんですけど。

こういうのじゃないんですよね?

task :install => [:pre_install, :do_install, :post_install]

んじゃあ:

class Rake::Task
  alias_method :execute_orig, :execute

  def execute
    execute_orig
    do_post
  end

  def do_post
  end
end

task :default => :install

task :install do |t|
  puts('installing...')
end

def (Rake.application.lookup(:install)).do_post
  puts('do post')
end

はは。これだったらRakeの中の人にフック作って
もらったほうがいいですね。

--

Meadowの新しいヤツがさぁ、EOFに勝手に改行入れるん
ですよ。大きなお世話だし、カンベンしてほしい。

(setq mode-require-final-newline nil)

改行のないテキスト・ファイルなんて、典型的なテスト・
データでしょ。それすら作れないエディタなんて、プロ
グラマが使うエディタじゃない。

--

mswin32のrubyだと、systemで存在しないコマンドを
実行したときに、$?を設定してくれないんですね。
そういうときはsystemがfalseを返すのは同じなんで、
大して困りませんけど。

本家Permlink


2007年01月08日3

暫定的な決定版の改訂版 (笑)。どうもrake_requireすると
prerequisitesの振る舞いが変わっちゃう。helloタスクの
中にhello自身が含まれちゃう。

prerequisitesが長すぎるっていうのは前にも書きました
けど、rake_requireも、せめてRake.rake_requireと
書けるようにしてほしいです。

# -*- mode:Ruby -*-
# build.rake

class Rake::Task
  def preqs
    results = @prerequisites.dup
    results.delete_if{|taskname| taskname == to_s}
    return results
  end
end

require 'rake/clean'
CLEAN.include('*.o')

%w[.c .cpp .cc .cxx .C].each do |suffix|
  rule '.o' => suffix do |t|
    sh "#{$cc} #{$cflags} -c #{t.source}"
  end
end

rule '.exe' => '.o' do |t|
  sh "#{$cc} -o #{t} #{t.preqs}"
end

rule(/\A[^.]+\z/ => ['.o']) do |t|
  t.is_a?(Rake::FileTask) and sh "#{$cc} -o #{t} #{t.preqs}"
end

$cc = 'gcc'
$cflags = '-Wall -g'

# -*- mode:Ruby -*-
# Rakefile

Rake.application.rake_require 'build'

$cc = 'g++'

task :default => :all
task :all => 'hello'
file 'hello' => %w[main.o hello.o]
file 'main.o' => %w[main.cxx hello.h]
file 'hello.o' => %w[hello.cxx hello.h]

--

知りませんでした。DelphiってPersonalバージョンは
タダで配ってたんですね。今だとTurbo Delphi Explorer
ですか。いや、ず〜っと、Delphiはタダじゃ配ってない
って思い込んでました。

自分、Macだったもんで、Turbo製品触ったことないん
ですよね。ちょっと興味あります。ただ時間が・・・

--

そうなんだよなぁ。自分が最初にプログラミングに
興味を持ったのも、当然ゲームを作りたいと思ったから
で (よく覚えてないけど)、それでやっぱり挫折して。
で、なんだかんだで挫折を繰り返してたんですけど。
そうした中で、ほんとにきっかけといえるものとなると、
テキスト処理だったんですよね。『テ料理』とか
『プログラミング言語 Awk』とか。さすがにこの頃に
なると、プログラミングのイロハ、変数とか関数とかは
理解してたと思うんですけど。

テキスト処理は簡単じゃないですか。それでいて実用的で。
いや、実用的っつっても、個人で扱うデータなんてタカが
知れてるんで、気分だけの問題なんですけど。でも、
テキスト処理って、プログラミング言語とかにもつながる
じゃないですか。それと、Unixライクなものへの憧れも
醸成されるし。

ただなぁ、さすがに中高生に『テキスト処理って面白い
ぜ!』っていっても共感は得られないでしょうね (笑)。
でも、インターネットなんて、テキスト処理なんだから!
ソケットは使っても、中通ってくるのはテキストだから!

そういう意味じゃ、『ふつうのLinux』でネットワークに
焦点を当てたのは正解だったんでしょうね。

--

へ〜、意外。会長なんかはバリバリ計画人間だと思って
ました (笑)。でなきゃ、あんなにエネルギッシュに
行動できるはずはないと。

でも、自分みたく、あんまりにも無計画に生きてるのも
どうかと思いますけどね。もうオレも40近いのにさ。
ほんとに。どうする、オレ?

--

答え:どうにもしない

--

るびまのhotlinksでwotaさんを!

本家Permlink


2007年01月08日2

うお!
『ちょんまげがいっぱい』が!
『まんがくらぶ』で!
復活とな!

それにしても、ニャンニョンショー、見たいぞ。

--

あっ、あれダメだ。あれだとhelloっていうファイルと
hello.o, main.oとの依存関係が見えない。実際に
hello.exeを作るしかないのかなぁ。

とりあえず、下のを暫定的な決定版 (笑) にしたい。

# -*- mode:Ruby -*-

class Rake::Task
  def preqs
    return @prerequisites.dup
  end
end

require 'rake/clean'
CLEAN.include('*.o')

rule '.o' => '.c' do |t|
  sh "#{$cc} #{$cflags} -c #{t.source}"
end

rule '.o' => '.cpp' do |t|
  sh "#{$cc} #{$cflags} -c #{t.source}"
end

rule '.o' => '.cc' do |t|
  sh "#{$cc} #{$cflags} -c #{t.source}"
end

rule '.o' => '.cxx' do |t|
  sh "#{$cc} #{$cflags} -c #{t.source}"
end

rule '.o' => '.C' do |t|
  sh "#{$cc} #{$cflags} -c #{t.source}"
end

rule '.exe' => '.o' do |t|
  sh "#{$cc} -o #{t} #{t.preqs}"
end

rule(/\A[^.]+\z/ => ['.o']) do |t|
  t.is_a?(Rake::FileTask) and sh "#{$cc} -o #{t} #{t.preqs}"
end

$cc = 'g++'
$cflags = '-Wall -g'

task :default => :all
task :all => 'hello'
file 'hello' => %w[main.o hello.o]
file 'main.o' => %w[main.cxx hello.h]
file 'hello.o' => %w[hello.cxx hello.h]

本家Permlink


2007年01月08日1

http://ja.wikipedia.org/wiki/GNU%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%A9%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

辛口ですねぇ。でも、GCCがタダっていうのはやっぱ
大きいんですよね。LinuxでもWindowsでもタダで手に
入って、なおかつ同じように動くわけで。

自分がプライベートでVisualStudioを買ったのは、
コードの品質なんかどうでもよくって、MFCとか、そう
いうとこでですから。ぶっちゃけ、遅いとか速いとか
気にしたことがない。

コンパイラの専門家からしたらGCCはガマンならんほど
ダメなのかもしれませんんけど、オープン・ソース界隈
じゃ、ほぼ唯一絶対なコンパイラなわけで、そこを評価
しないとね。

ああ、それと、多分、gccユーザが世界最大じゃないの?
VC++も多いでしょうけど。

--

いや、どうもうこうも、ひどい勘違いしちゃってて。
makeなんですけど。ルールと依存関係をごっちゃに
しちゃってて。これでもmakeの本は読んだつもりだった
んですけど、ほんとに『読んだつもり』になっただけ
でした。

hello.h hello.c main.c

って3つのファイルがあって、hello.cとmain.cのどっちも
hello.hをインクルードしてると。そのとき、自分は:

hello: hello.o main.o

って書いて終わりにしちゃってたんですね。これが
おかしいっていうのは薄々気づいてましたけど。だって
ヘッダの依存関係が出てきませんから。

でも、いいわけさせてもらうと:

hello: hello.o main.o
hello.o: hello.c hello.h
main.o: main.c hello.h

っていうのが正しい書き方なんですけど、hello.oの
行を例に取ると、これから想像できる実行って:

gcc -c hello.c hello.h

じゃないですか! 『このhello.hってナニ?』って
なるじゃないですか!

さらに:

hello.o: hello.h

って書くと、今度はhello.oとhello.cとの間の依存関係が
なくなっちゃうじゃないですか。ルールで.oは.cから
生成されるって決まってるのに!

いや、だからルールと依存関係をごっちゃにしてたんだ
って。

さっき、Rakeのドキュメントのほうも加筆修正しとき
ました。

--

ついでにRakeの話を。

これまでリンクするときは:

def link(target)
  sh "gcc -o #{target} #{target.preq}"
end

file 'hello' => 'hello.o' do |t|
  link(t)
end

みたいにやってたんですけど、いくつも実行ファイル作る
とき、これだと一々linkを呼び出さなきゃいけないわけで。
それじゃあ、ちょっとmakeより手間です。

で、いろいろ試してみたんですけど、結局:

require 'rake/clean'
CLEAN.include('*.o', 'hello')

rule '.o' => '.c' do |t|
  sh "gcc -c #{t.source}"
end

rule '.exe' => ['.o'] do |t|
  exe = t.to_s.sub(/.exe\z/, '')
  sh "gcc -o #{exe} #{t.prerequisites}"
end

task :default => :all

task :all => 'hello.exe'

file 'hello.exe' => %w[main.o hello.o]

みたいにするのが一番マトモそう。ルールをゴチャゴチャ
いじってみたんですけど、余計なタスクまで拾っちゃう
んで、拡張子を使うのが一番手軽。

--

やっぱり最後まで作り上げることが大切なんじゃない
ですかね。

最後まで作り上げて、さらに公開までしちゃうと、
やっぱり責任感みたいなものが生まれちゃうじゃない
ですか。いってみればメンテナンスですけど。

メンテナンスっていうと面倒なんですけど。まぁ、自分
にしても、作りっぱなしも多いわけで。

でも、責任感っていうのは、プロジェクトを続ける上で
大きな動力源になります。作り上げるまでだと、イヤに
なって放り出しちゃうことが多いですよね。

これから派生させて、やっぱりシステムは早く独り立ち
させたほうがいいってことになります。オープン・ソース
にしたら、早く公開するほうがいいってことになります。
ドキュメントにしてもおんなじ。それと、だから、作り
上げられそうなものを選ぶのも大切ですよね。無理な
挑戦して途中で放り出すようじゃ、やっぱりダメ。

--

あははは。いや、ガチガチの静的型言語でもTDDは有効
ですよ。マジで。TDDっていうのは、未知なものに対する
アプローチの仕方ですから。だから自分はTDDを『プロ
グラミングの進め方』っていってるんです。だから、TDDに
対比されるのはトップダウン・プログラミングとかボトム
アップ・プログラミングであって、型云々はあんまり関係
ありません。

TDDはボトムアップに近いんですけど、もっと計画が
入ります。だからTo Doリストが重要だっていってる
んです。計画っていうのはトップダウンですよね。

実際、プログラミングっていうのは、トップダウンと
ボトムアップが入り交じらないとダメでしょう。だって、
途中でコンパイルが通ってるからっていって、最後の
最後まで実行しないなんてことは現実的じゃないでしょう。
トップダウンで計画しても、どっかでボトムまで行って
動くようにしなきゃいけない。で、ボトムまで行ったら、
新しい発見があって、そこからトップのほうが変わる
っていうのもよくあるでしょう。

本家Permlink


2007年01月08日

気づいたらEmacsのinfoがなくなってました。sidなもん
だから、いつもの (笑) パッケージング・ミスだろうと
気にしてなかったんです。でも、いつまでたってもinfoが
ないままなので、『こりゃあ何かある』と思ったら、
案の定、emacs21-common-non-dfsgっていうパッケージが
別に用意されてました。

http://packages.debian.org/unstable/editors/emacs21-common-non-dfsg

ライセンスの問題みたいですね。

自分みたいな一ユーザからしたら、ちょっと勘弁して
ほしいっていうのが本音です。でも、まぁ、フリー・
ソフトウェアもまだまだ若いってことですかね。

--

自分がこんなことを書くのもなんなんですけど。
実行速度っていうのは、すべてを引っくり返すほどの
影響力があるんですよね。どんなにきれいに設計できて
ても、ガマンならないくらい遅けりゃ話になんない。

でも、実行速度っていうくらいですから、動かしてみな
きゃわかんないんですよね。

だから、本物のシステムを少しでも早く独り立ちさせ
ないといけないわけです。

プロトタイプなんかだと、このワナにはまりやすい。
もちろん、先払いでも同じこと。

そういう点でもTDDがいい。TDDでテストをしょっちゅう
やってれば、システムの実行速度が実感できます。
逆に、早すぎる最適化を防ぐことにもなります。テストの
実行速度がガマンできるんなら、最適化なんてやる
必要はないですから。もちろん、いざ最適化するとき
にも、それまで書いてたテストがあれば安心ですしね。

本家Permlink


2007年01月06日

あははは、あれだけさんざん目にしてる文字なのに、
『くりとう』と『みうら』と読んでた (笑)。

本家Permlink


2007年01月05日

いや、プログラミング言語だけで解決しなきゃいけない
問題ばっかじゃないじゃないですか。名前の衝突にした
って、実行環境でも解決できるし (たとえば静的リンク
しちゃうとか)、開発ツールでも解決できるし (いわゆる
クラス・ブラウザみたいな感じで)。それこそ慣習で解決
することもできますよね。

でなきゃ、UNIXなんてもう破綻してますよね。いや、
『すでに破綻してるじゃないか!』って主張する人も
いるでしょうけど (笑)。

でも、ほんとに大規模開発の問題っていうのは、工学
よりも社会学の色が濃いんです。だから、言語をガチ
ガチに固めて大規模に備えるっていうのと矛盾しやすい
んですよね。極端な例でいえばC++なんかがそう。C++は
Cより大規模に強いっていわれてますけど、でも、そう
いうのはC++をきちんと使ってる人がいうことであって。
Cに毛が生えた程度にしか思ってない人たちが使っても
あんまり効果がない。そこで、『フレームワークを作る
人とそれを使う人に分けりゃいいじゃん』っていうのは、
それはそれで『社会学』になるという矛盾が出ちゃう。

言語設計者が言語のスケーラビリティを議論するのは
当然なんですけど、自分らみたいな現場の人間が、
あんまりそういうことに夢中になっても現実的じゃない
でしょう。

規模に影響するのは規模そのもので、言語はあんまし
関係ないんじゃないですかね。100人のJavaプログラマで
ソフトウェア開発する難しさと、100人のLispプログラマで
ソフトウェア開発する難しさが、そんなに違うとは思え
ないんですよね。

おっと、ここで『100人のLisperなんて集められるわけ
ないじゃないか!』とか『Lispだったら100人も必要
ない!』とかいってるようじゃ、すでに社会学と認めた
とおんなじですよ (笑)。これがHaskellでもおんなじで、
だったらLispにもHasklellにもスケーラビリティなんか
いらないでしょう (笑)。

本家Permlink


2007年01月04日1

http://www.instantiations.com/VAST/

IBMのVisualAge Smalltalkの後継らしい。

--

ああ、やっぱりBoostとVisual Studio 2005だと警告が
出るのは避けられないっぽいですね。

本家Permlink


2007年01月04日

やっぱりマニピュレータでprintfみたいなことをやろうと
するのは大変です。とはいえ、やっぱりprintfだと、
C++ライブラリとの食い合わせがあんまりよくありません。

というわけで、boost::formatを使いたいがためだけに、
Boostをインストール。sidにはもう入れてたんですけど、
Windowsにはまだ入れてませんでした。

で、bjam "-sTOOLS=vc-8_0" installとかやってる間、
youtubeでハイロウズの『青春』観てたら、いきなり
リブートするという、なんともいえない正月三が日最後の
日 (笑)。

『Visual StudioとBoostの相性はサイアク』なんていう
評判を耳にしてたんで、どんなもんかと思ってたんです
けど、全然そんなことないですね。いや、まだチョロッ
としか使ってないんでアレですけど。

確かに警告はたくさん出ますけど、それは例のMS独自の
セキュリティ拡張のせいで。いや、独自拡張が悪いって
いうんじゃなしに。それはそれで仕方ない話だと自分は
思ってます。一応、標準化への働きかけもやってるみたい
ですし。

警告ウザイですから、Boostのサイトにも説明がある
ように、マクロ定義で出さないようにしました。
プロジェクトのプロパティ開いて、``構成プロパティ:
C/C++:コマンドライン''の``追加オプション''で:

/D"_SCL_SECURE_NO_DEPRECATE"

を入れときました。いや、gccの``-D''マネて、全然
テケトーに入れたんですけど、これでよかったみたいで (笑)。

おっと、一応書いとくと、``構成プロパティ:C/C++:
全般:追加のインクルードディレクトリ''と``構成
プロパティ:リンカ:全般:追加のライブラリ
ディレクトリ''を適切に設定しとかないとコンパイル
できませんからね。念のため。

追記:Boostのページには「_SCL_SECURE_NO_DEPRECATEを
定義しろ」って書いてあるんですけど、実際に出る警告は
「_CRT_SECURE_NO_DEPRECATEを定義しろ」ってなって
ます。_SCL_*を定義しても警告はなくなりません。
だから、追加オプションとしては:

/D "_CRT_SECURE_NO_DEPRECATE"

が正解。

本家Permlink


2007年01月03日

へー、C++って、どこででも変数宣言できると思ってた
んですけど、違ったんですね:

int
main()
{
    int value = 0;
    switch (value) {
    case 0:
        int zero = 0;
        return zero;
        break;
    case 1:
        int one = 1;
        return one;
        break;
    }
    return 0;
}

$ g++ -Wall cc.cc
cc.cc: In function 'int main()':
cc.cc:10: error: jump to case label
cc.cc:7: error:   crosses initialization of 'int zero'

--

のlocaltimeで取ったstruct tmのtm_yearが
なんかおかしいんで、man見たら:

       tm_year
              The number of years since 1900.

ビミョーすぎる。

--

そういえば、ソース・デバッガって、行単位でしか
ステップの目印が動かないのがフツーみたいですけど、
あれ、どうにかなんないんですかね。

そんなんだと、デバッガをよく使う人だと:

if (value) return 0;

みたいに1行に詰め込みにくくなっちゃいますよね。

行の目印と同時に、実行しているステートメントも
ハイライトするとか、そういう工夫があってもいいんじゃ
ないですかね。

個人的には、上みたいに短いコードを:

if (value)
    return 0;

みたいに2行にわけて書くのはガマンならんのですけど。
なんでソース・デバッガの都合に合わせて、こっちが
曲げなきゃいけないのか。そういうことに腹が立っちゃう。

本家Permlink


2007年01月02日1

正規表現の文字クラスって、改行を特別扱いしないん
ですね。

text = File.read(ARGV[0])
text.scan(/[^"]+/){|m| p m}

これに次みたいなdata.txtがあって:

abc
def

その結果は:

"abc\ndef\n"

本家Permlink


2007年01月02日

コードの書き初めはJavaでした。いや、自分でも思いも
かけない展開で (笑)。

Eclipseを使ってみようかと思いまして。といっても、
Javaが本命じゃなくって。前にも書きましたけど、CDT。

それにしても、Javaの伝統なのか、簡単なものながらも、
チュートリアルがきっちり用意されてますね。CDTにも。

でも、思ってたのと違ってたかも。CDTに期待してたのは
ぶっちゃけ自動makeなわけで。Makefileを手で書きたく
ないっていう。それをやるのがManaged Makeってヤツ
なんですけど。これが・・・

ほら、自分はEmacs使うじゃないですか。だから、ほんとに
Eclipseに期待してるのは自動makeと、あとソース・
デバッガ。まぁ、デバッガはもともとそんなに使わない
んで、やっぱり自動makeなわけです。

で、Emacsでコードを書いてEclipseでビルドっていう
流れを想定してたんですけど、どうもこれがダメみたい。
簡単な.hhと.ccのペアでできたクラスで試してみたん
ですけど、ヘッダをいじってもビルドされない。makefileを
見ても、中身はほとんど空っぽ。

まぁ、Eclipseのエディタを使ってれば、オンザフライで
コンパイルされるんですけどね。

そもそも、プロジェクトに既存のファイルを追加できない
っつーのも、どうかしてる。インポートしかできない。
インポートっていうのはつまりはコピー。そんなめんどい。

これだったらVisual Studioのほうがいいっていう情けない
結論に (笑)。少なくともVSは外部でいじられたことを
感知しますから。

--

こりずに今度はBoost.Build・・・と思ったんですけど、
なんかメンドーになってきちゃいました。

いちおードキュメント読んだりしたんですけど、bjam
一発で動かなかったり (user-config.jamが$HOMEにコピー
されてなかっただけだったんですけど)、なんかいっぱい
.jamファイルがあったりで、わけわかんない。

Googleで調べてみても、『みんなBoostをビルドするの
にしか使ってないじゃん!』な状態で。わやや。

こんなんだったら、Rakefileで書いたほうがいい気が
してきちゃいました。で、チマチマと自動化するみたいな
方向で。srcの下にあるもの全部テケトーにビルドして
くれりゃあ、それでいいわけで。DebugとかReleaseとか
移植性とかどうでもいいし。仕事で使うわけじゃないし、
ファイルの量なんてタカが知れてるし。

本家Permlink


2007年01月01日

正月だっつーのに、こんなページ見て。
おせちは食べたの?

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails