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

「東洋経済」の記事から:

  (ステート・ストリート・コーポレーションの) 主要業務の1つは、機関投資
  家や保険会社を含む金融機関、法人・個人投資家の株券や債券などの資産を
  保管管理する、いわゆるカストディ。資産規模は約1475兆円 (以下略)

SSCのCEO、ロナルド・E・ローグ氏の話を抜粋:

  われわれにとって、ITは極めて極めて重要な要素です。

  IT投資こそ、まさに成長の燃料だと私は思っています。

  皆さんに説明する際、実はわれわれはITの会社であって、たまたま銀行業を
  営んでいる、と言うことがあります。

まぁ、シロートの自分にはファンドとカストディの違いが
よくわかんないんですけど。

だから、外に作らせるようなものは、誰が作ろうと構わ
ないし、安けりゃ安いほどいいのは当たり前ですよね。

でも、ほんとにほしいものは自前で作るしかない。ソフト
ウェア化できる知識がどんどん高度に専門化されてきて、
外の人間に任すことができなくなってきたら、そりゃ
自前でプログラマを雇うしかない。これも当たり前の
理屈ですよね。

自分は楽観的に『プログラマが足りてない』っていってる
わけじゃないのね。前よりもドメインの知識が求められる
だろうし、OSSを中心とした汎用品の知識も求められる
だろうし。だから、この『足りてないプログラマ』の像、
これから求められるプログラマ像っていうのは、これ
までの像とは違うかもしれない。その像に合わない人
たちは、インドやどこかの人に置き換わっちゃうかも
しれない。

--

それはそれとして、ちょっと風向きが変わってきたのを
感じてます。前は『(自分で) 作るな、(誰かに) 作らせろ』
みたいな風潮があったんですけど、そういうのが減り
つつあると。

本家Permlink


2007年06月29日

確かに、オープンソースがプログラマ自身の首を絞めてる
側面はあるかもしれません。でも、こうした流れは避け
られないっていうか。ソフトウェアでそれが顕著に目立って
いるだけで、他の分野でもそうなっていくことは十分
考えられますよね。

たとえばサッカーにしても、最初のころは英国、そして
欧州しか競争相手がいなかったけど、それが今じゃ南米や
アフリカといったところも強くなっている。これは
サッカーがコモディティ化したから起きた競争ともいえる
わけです。そうした物事の広まり方が、昔と比べると
格段に早くなってるわけで。それはソフトウェアだけの
話じゃないわけでしょう。

だから結局、ソフトウェアだけの話じゃなくって、競争を
避けるか、それとも負けを覚悟して競争するかしかないん
ですよね。

それと、前からいってるとおり、プログラマの数はまだ
足りてないっていうのが自分の意見です。これまでは
ソフトウェア開発を専門にやってるとこが多くのプロ
グラマを雇ってたわけですけど、そういうとこじゃない、
いわゆる「ユーザ企業」といわれてたとこでもプログラマを
どんどん採用するようになってきていると。そういう
とこはソフトウェアを売るのが主目的じゃないわけで、
オープンソースをうまく使いつつ、自分の本業で利益を
上げればいいわけです。

--

自分は金融のシロートなんで、これははなはだ怪しい話
ですけど。21世紀になって「メガマネー」ともいえる
時代になってきてると。ファンドと呼ばれる民間企業が
数兆円を超える規模のお金を動かしてるわけです。
そういう莫大なお金の流れを支えてるのは間違いなく
ITなわけです。で、そういうとこは自前でソフトウェアを
開発してるとこが多いはずです。こないだの「東洋経済」
でもそんなことが書かれてましたよね。自分の頭脳や心臓
であるシステムを外に作らせるなんてことはしないはずです。

最近、社保庁の話がよくされてますけど。あそこの公的
年金システムの著作権はNTTデータがもってるという話。

http://it.nikkei.co.jp/business/news/busi_gyoukai.aspx?n=NN003Y034%2027062007

ソフトウェアを外に作らせるっていうのは、常にこう
いう危険性があるということ。

--

まぁ、でも、競争を避けるっていうのは、公務員にでも
ならないかぎりむずかしい。

本家Permlink


2007年06月27日

少なくとも自分にとってリファクタリングはフォームの
一部です。フォームの中でリファクタリングは省いちゃ
いけない部分なんですけど、省いちゃいけないのは他にも
あります。たとえばテスト・ファーストだとか。

だから、みんなが『リファクタリングしたい』って
いってるのはちょっと不思議なんですよ。だって、今じゃ
自分は、リファクタリングしないと作れないんですから。
それがフォームの一部だっていうことで、リファクタリング
なしのスイングっていうのは今の自分には考えられない。

もちろん、仕事という実戦では他人が書いたコードも
いじらなきゃいけないし、そんなときにリファクタリング
ばっかりやってるわけにはいきません。テスト・ファースト
にしてもそう。だから、実戦ではフォームを守ること
よりも、結果を出すことに重点を置くわけです。

でも、崩れたままのフォームでいいわけないから、
フォームを矯正するために、こないだ書いたような
『実戦的な練習』っていうのを考えたわけです。

それぞれの人にそれぞれのフォームやスイングがあって
いいんですけど。でも、リファクタリングはユニット・
テストとは切り離せないし、ユニット・テストやるん
だったらTDDまでやれよっていうのが自分なのね。

--

こういう書き方はよくないから消した。反省。

本家Permlink


2007年06月26日1

何度も書いてるけど、管理者と技術者っていうのは別の
職能なのね。だから、管理者やりたけりゃ、最初っから
管理者の勉強したほうがいいわけ。それこそコードなんか
書かずにね。

そりゃプレーヤーが監督やって成功する例もたくさん
あるよ。でも、失敗する例はそれ以上にたくさんある。

それに、プレーヤーが監督よりカネ稼ぐっていうのは
そんなに珍しいわけじゃない。特にプロスポーツの
世界じゃね。

上流っていうのは客に近いとこにいて、下流っていう
のは製品に近いとこにいるっていうだけでね。どっちが
カネが稼げるかっていったら、その人の腕によるとしか
いえない。

でも、プログラマっていうのは、上流から下流まで
できなきゃダメなのね、本来は。要求を分析して、仕様に
して、設計して、コード書いて、テストして、それが全部
できなきゃダメなのね。それをやらないのは規模が大きい
とか、時間がないとか、そういう理由があるからなのね。

誰が作ったって同じようなものしかできないこともある。
でも、そんなもん作っても面白くもなんともないし。
作って面白いもんを作るから技術者をやってるんであって。

上流とか下流とか、そんな陳腐な言葉に惑わされちゃ
ダメだよ。ましてやAregeを標榜するハッカーがだよ、
鵜飼さんっていうハッカーを慕う人間がだよ、バカな
リクルーターの言葉に躍らされてどうするよ?

本家Permlink


2007年06月26日

え? 名古屋って東日本に入んないの?
じゃあ西日本なの?
それとも名古屋日本?

--

http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Shiro

(2007/06/21 13:21:54 PDT Startup life)の記事。

Shiroさんは「自分のプロジェクトでこんなふうに仕事が
出来るのはかなり理想的」って書いてますけど。自分は
ここまで入れ込むことはできないなぁ。まぁ、それは
自分が二流だからでしょうけど。

でも、こういうのができるのは若いうち、っていうか
独身の間だけじゃない? かわいいラム太の顔を見るのは
寝顔だけ・・・なんていう生活が理想かといわれたら、
多分そうじゃないでしょう。

まぁ、「プロジェクト」っていうのは、限定された期間
ってことなんでしょうけど。

--

最近Yendotの質が落ちてるっていうのは度々指摘して
るんだけど。

http://jibun.atmarkit.co.jp/lcareer01/rensai/wakare31/wakare01.html

だから、こういうのを貼るなっていうの。こんなのただの
宣伝じゃん。誰かが転職することでお金が落ちてくるん
だから、転職を勧めるのは当たり前だし。

こういう外の人間がヘーキなツラして上流だ下流だって
ぬかすのはほんっとに腹が立つ。こういうバカがいる
限り、業界は良くなんねーし、こういう記事をYendotに
貼るバカも同じ穴のムジナだっつの。News for Aregesの
謳い文句が泣くぜって。

本家Permlink


2007年06月25日

というわけで、早速朝練やってみたわけだけど。題材は
K&Rのwc。で、やってみてはじめて知ったんだけど、
mswin32の$stdinはデフォルトでテキスト・モードなのね。
Cygwinのwcと比べないと見つからないバグだった。それで
ハマって見積もりオーバー。う〜ん、実戦的!

def wc
  $stdin.binmode
  nc = 0
  while (c = $stdin.getc)
    nc += 1
  end
  puts(nc)
end

if $0 == __FILE__
  wc
end

--

オラー! たつをさんも崇拝するビリー隊長も:

  エクサザイズは心がないとダメ。どうしてすぐに
  あきらめるんだ? 自分の力は自分の手の中にある。
  笑い事じゃない。真剣だ!!

っていってるぞ。ソフトウェア開発も心がないと
ダメ。根性だ! 集中だ! 心の底から頑張れ!!

本家Permlink


2007年06月23日1

メモ魔・タカハシによると:

  ロディアはダメ。パッと開けないでしょ。

メモ魔・セキによると:

  それは使い方が違うんじゃないの。だって、書いた
  紙は切り取っちゃうから。

--

GTD大嫌い・タカハシによると:

  そりゃ仕事じゃTo Doリスト書きますよ。仕事と
  プライベートは別です。

--

arton曰く:

  ゲッターロボみたいな『オチ』のあるヤツは、常連には
  ウケても、買われない。笑われてそれでオシマイ。
  それよりも、シベリウスみたいな、いかにも検索で
  来たようなものが買われる。

--

練習っていうのは実戦に即したものじゃないとダメって
いうのが結論。でも、実戦そのものじゃダメ。実戦って
いうのは結果を出す場だし、フォームが崩されても結果が
出たならそれでオーケーだから。でも、練習では、理想
的なフォームを追求すべきだし、またそうでないと実戦で
力を出せない。

では、実戦的な練習って何だろう。もっとも実戦的な
練習といえばミニゲームだろう。つまり、実戦の規模を
小さくしたものだ。

規模を小さくするというのは、プロセスを省くという
ことじゃない。だから:

1. 問題が出される。
2. 問題の解き方を考える。
3. 作業にどのくらい時間がかかるか見積もる。
4. 問題を実際に解く。
5. 答えが正しいか確かめる。
6. 見積もりと実績を比較するといった考察を行う。

というすべてのプロセスを経なければ実戦的とはいえない。

問題はやさしいほうがいい。問題を解くというのは、この
練習の部分的なプロセスに過ぎない。6つのプロセスを
きっちり経ることが大切。

こないだ話題になったFizzBuzzは、こうした練習に最適な
大きさじゃないか。実はFizzBuzzにはワナがあって、
あまりにも簡単な問題だから、テストを書かなかったり、
リファクタリングしなかったりする。もし、テストを
書いたり、リファクタリングをするとなったら、多分
2〜3分では終わらないだろう。第一感で10〜15分といった
ところか。

実際にやってみたところ、10分ちょっといったところ。
このぐらいの問題ならば、朝のルーチンとして取り入れる
こともできるんじゃないだろうか。

--

上の話は『落合博満の超野球学 1,2』を読んで思ったわけ
ですけど。その中で印象に残った言葉の1つに、『基本に
帰るということは、人間の基本に帰るということで、
それはよく眠り、よく食べるということ』というのが
あります。

これは何もスポーツ選手に限った話じゃないと思うんです
よね。一時、ライフハックとかいって睡眠時間を削るって
いうのが流行りましたけど。そんなん邪道でしょう。

--

朝のルーチンとしてrubyのソースを書き写すっていうのを
一時やってました。まぁ、それはそれで準備運動には
なったのかなと思うんですけど (笑)。

--

# fizzbuzz.rb
def fizzbuzz(n)
  if n % 3 == 0 && n % 5 == 0
    return 'FizzBuzz'
  elsif n % 3 == 0
    return 'Fizz'
  elsif n % 5 == 0
    return 'Buzz'
  else
    return ''
  end
end

def print_fizzbuzz(n)
  printf("%d:%s\n", n, fizzbuzz(n))
end

if $0 == __FILE__
  1.upto(100){|i| print_fizzbuzz(i)}
end

# fizzbuzz.t.rb
require 'test/unit'
require 'fizzbuzz'
require 'stringio'

class FizzBuzzTest < Test::Unit::TestCase
  def test_fizzbuzz
    assert_equal('FizzBuzz', fizzbuzz(0))
    assert_equal('', fizzbuzz(1))
    assert_equal('Fizz', fizzbuzz(3))
    assert_equal('Buzz', fizzbuzz(5))
    assert_equal('FizzBuzz', fizzbuzz(15))
  end

  def test_print_fizzbuzz
    $stdout = StringIO.new('', 'w')
    begin
      print_fizzbuzz(1)
      print_fizzbuzz(3)
      print_fizzbuzz(5)
      print_fizzbuzz(15)
      assert_equal("1:\n" <<
                     "3:Fizz\n" <<
                     "5:Buzz\n" <<
                     "15:FizzBuzz\n", $stdout.string)
    ensure
      $stdout.close
      $stdio = STDOUT
    end
  end
end

本家Permlink


2007年06月23日

プログラミングには基本的な考え方っていうのがたくさん
あるわけですけど。正しい表現じゃないかもしれませんけど、
『アトミックな処理はアトミックに処理する』っていうのも、
そうした基本の1つです。

たとえば、自家製のボタンを考えてみます。クリック
されたら何かを計算するようなボタンです:

class MyButton
  def on_click
    someone.calc
  end
end

で、わざわざ自家製にしたのは、クリックされたときに
ボタンを明るくしたいからです。そして、もう一度クリック
されたら暗い状態に戻します:

  def on_click
    @on = !@on
    if @on
      someone.calc
      light_on
    else
      light_off
    end
  end

非常に素直に書いたつもりです。ところが、実際には
こう書かれていました:

  def on_click
    someone.calc
  end

で、誰がボタンを明るくするかというと:

class Someone
  def calc
    if @button.on
      @button.light_off
    else
      ...
      @button.light_on
    end
  end
end

こういう書き方を自分は『アトミックではない』と呼び
ます。『クリックされた』という事象と『ボタンが明るく
なる』という事象は、必ずワンセットで生じるべきこと
です。不可分な処理、だからアトミックな処理というわけ
です。本来不可分であるはずの処理を離して書いてしまうと、
それだけバグが入りやすくなります。

この問題をさらに一般化すれば、やっぱり責任の分配
ミスということになります。ただ、それだと曖昧に感じる
ことも多いので、こういうケースでは『アトミックになって
ない』という表現を使うわけです。

--

前払いの設計に慣れてる人の場合、agileの『日常設計』
に戸惑うことがあるようです。agileだと、システム全体を
十分に把握して、主なオブジェクトの役割を理解するための
時間的な余裕はありません。どこに何があるかもわからない
うちにコードをいじりはじめないといけない。それを不安に
感じるようです。

これは正常な不安ということもできます。『システム
全体を理解できていなくてもなんとかなるだろう』と
いった、ある意味開き直った境地にはなかなかなれない
ものでしょう。

でも、自分は、そういう不安を感じてる人たちにいいたい。
あなたは一人で作業しているのではないと。

だから、不安を隠すのが一番よくない。わからない、
あるいは知らないことは恥でもなんでもない。

自分はあなたに少しでも早くシステムを理解してほしいと
思っているし、そのための協力は惜しまない。短期的に
見れば、協力することで自分の生産性が落ちるかもしれ
ない。でも、長期的には協力するほうが全体としての
生産性は必ず上がると信じている。

そりゃぁ『C++の書き方がわかりません』とかいわれたら
頭突くけど (笑)。

本家Permlink


2007年06月22日

状態は少なければ少ないほうがいいっていうのも、基本
的な考え方の1つ。

グローバル変数はよくないっていうのは誰でも知ってる。
でも、ならインスタンス変数ならいいかというと、そんな
ことはない。やっぱりインスタンス変数も少ないほうが
いい。

よくありがちなのが「なんとなく」な理由でキャッシュを
作ってしまうこと。キャッシュっていうのは1つの状態な
わけで、無闇に使うもんじゃない。これの亜流が、ある
オブジェクトの一部のインスタンス変数だけを抜き出して
キャッシュするようなヤツ。ちょっとわかりにくいだろう
けど:

class StartEnd {
private:
   bool used;
   int start;
   int end;
   ...
};

みたいなクラスがあって、それを処理するために別の
場所で:

class ModifyStartEnd {
private:
  int start;
  int end;
  ...
};

みたいに、一部だけをキャッシュしちゃうパターン。
こんなのは:

class ModifyStartEnd {
private:
  StartEnd startend;
  ...
};

みたいに対象となるオブジェクトを丸ごと抱えるもん。
たとえムダなフィールド (上の例でいえばused) が
あったとしても、そんなもんは気にしない。

というか、そもそも、一部だろうが全部だろうが、対象を
抱えるべきじゃないのかもしれない。対象はすでに別の
場所に存在するんだから、それに直接働きかければいい。
キャッシュを作る必要はないということ:

class ModifyStartEnd {
public:
  void doit() {
    getStartEndFromSomewhere().setStart(100);
    ...
  }
};

--

話は変わるけど、privateメソッドが少ないオブジェクトは
怪しい。ある程度重要な登場人物なら、privateメソッドは
いくつか持ってるもん。それがないってことは、メソッドが
十分に切り出されてないってことだし、ひょっとしたら
責任を持ちすぎてる可能性がある。

--

自分が職業プログラマに向いてないと思うのは、こういう
のを見ると我慢できなくなる点。ぶっちゃけいって、
こういうのはほっといてもいいわけ。機能は実現できてる
んだから。でも、自分はスルー力が皆無なもんだから、
度々こういうとこで引っかかる。

ただ、最近はTo Doリスト書くようにしてるし、こういう
のはリストに載せて後回しにするようにしてる。それでも
フラフラっとやっちゃうときがあるんだけど (笑)。

だから、自分の生産性を上げるには、みんながきれいな
コードを書いてくれるのが一番 (笑)。

だから:

  if( value ){
    doit() ;

みたいなコードを書くなと (笑)。こっからはじまるからね、
自分の場合は。

  if (value) {
    doit();

こんなのやってたら時間がいくらあっても足りやしない (笑)。
K&Rのカドに頭ぶつけて死んじまえと思う (笑)。

本家Permlink


2007年06月20日

もう1つわかんねーのが改行使わねーこと。

テスト処理大好きな自分からしたら、ここでいうテキスト
処理っていうのはUNIXカルチャーのテキスト処理っていう
意味だけど、改行を使わないテキスト処理なんて考え
らんない。

最近じゃテキストの可搬性が重要視されてて、テキスト・
データだからっつって必ずしも目視を目的としていない
ことも多い。でも、やっぱり基本は目視のためのテキスト
であって、そのときに改行があるのは大きい。行によって
一塊のデータを視覚的に訴えることができる。

もう1つ改行を使う理由としては、改行を扱うAPIがある
っていうこと。Rubyなら:

while (line = gets)
   puts(line)
end

なんていうのがパターンだし、これはRubyに限らず、
他の言語でのプログラミングに通用するといってもいい
くらいのパターン。だから、行に意味を持たせて、「1行
ずつ読み込んでいって処理する」っていうのがプログラミングの
黄金パターンの1つなわけ。そういうパターンにしたがって
書けば、書くのもラクだし、読むのもラクなわけ。

--

ちなみに、今は1行ずつチマチマ読み込むなんてことは
しちゃいけない。1行ずつ処理したい場合でも:

readlines.each do |line|
  puts(line)
end

あたりが順当。

--

いや、「柔軟にカスタマイズできる」なんていったら、
たいていのものはそうなんじゃない? (笑)

たとえばLispとかね (笑)。

だから、カスタマイズするのに熟練がいるんだったら、
それは何か違うっていうか。少なくとも、RUPの謳い文句
とは違うんじゃないの? (笑)

本家Permlink


2007年06月18日1

わかんねーなー。たとえば、こういうコードがある:

bool used[5];
int start[5];
int end[5];

で、こういうのをチマチマ初期化してるわけ:

for (int i = 0; i < 5; ++i) {
  used[i] = false;
  start[i] = 0;
  end[i] = 0;
}

なんでこういうことをすんのか、ほんとにわかんねー。

こんなの出てきたら、自分だったらもうソッコーで:

class StartEnd {
public:
  bool used;
  int start;
  int end;
};

みたいな型を切り出しちゃうわけ。直接的なメリットと
しては、初期化をコンストラクタで済ますことができる
っていうのがある:

StartEnd::StartEnd()
: used(false), start(0), end(0)
{}

こうすりゃ初期化なんてする必要がない:

StartEnd start_ends[5];

ってやりゃ、それで初期化は終わってる。

これはCでもおんなじわけ。Cだからコンストラクタは
使えないけど、初期化する関数は用意できるわけでしょ:

void
clear_start_end(struct StartEnd *start_end)
{
  start_end->used = 0;
  start_end->start = 0;
  start_end->end = 0;
}

いい? 型を切り出して、それに対する演算を考えるって
いうのはプログラミングの基本なわけ。これはOOPだろうが、
FPだろうが、変わんないわけ。こういう型っていうのは、
これからの開発のヒントになるわけ。その型に足りない
データは何か、足りない演算は何かを考えるっていうことが
大切なわけ。また逆に、誰かが書いたコードを読むときにも
ヒントになるわけ。データの群を一塊にしてるんだから、
そこには意図があって、しかも名前までつけられてる。

--

だからね、効率云々いう前に、もっと基本的なことが
できてないわけでしょ。だから、最適化を忘れろって
いってるわけ。privateだろうが何だろうが自分は
virtualをつけるけど。それはC++ではvirtualが一番自然
だと考えてるからだし、最適化と決別する意思表示でも
ある。

本家Permlink


2007年06月18日

将棋好きでも必死と必至を間違えることがあるんだなぁ。

--

ミスドはメタボの一里塚。

--

いや、特殊なケースを助けてくれないのは、どんな
フレームワークでもいっしょじゃないすか?

そういうところで言語の柔軟性っていうのが試される
ってことじゃないすか?

--

ああ、自分もドリルとかは軽く読み飛ばしましたよ。
前にも書きましたけど、自分はゴルフやりませんから。

ちょっと思ったのは、TDDっていうのはルーチンであると
同時に、開発を楽しく進めるための1つの仕掛けであると。

進むべき道が見えてないまま歩きだすのは不安だし、
楽しくない。だからTo Doリストやテストを書く。今まで
歩いてきた道が間違ってなかったかどうかを確かめるために
テストを通す。歩きだしてしばらく経ってから間違った
方向へ歩いていたことに気づくなんて目には遭いたくない。
それと、テストが通ればうれしいし、TDDならその
「うれしい」が頻繁に起こるわけで、必然楽しくなる。

まぁ、このへんは、自分も「TDDは品質を得るためじゃ
なく、自信を得るためにやる」って書いてきたわけです
けど。

--

会長もコメントしてるように、やっぱり「感情を管理する」
っていうのはヤバゲですよね。でも、上みたく、楽しくなる
仕掛けを考えるっていう方向ならオケなんでしょうね。

これまでは「楽しく仕事をする」とかいうと理念とかに行き
がちだったんですけど(「ユクヮイなる工場」とか)、それを
プロセスの一部として具体的にどうやって実現するかを考える
っていうか。

--

グエ。Realforceの小さいヤツ、シフト・キーが長くなってる
じゃん! 最初っからそれで出せっつの。

--

米国じゃ「リアリティ・ショー」というのが流行ってる
らしい。UFCでも、ボクシングでも、RSが大人気なんだ
そうな。

RSっていうのは、ぶっちゃけいえば「ガチンコ・ファイト
クラブ」みたいなヤツ。素人が (元) 一流選手の指導を
受けてプロデビューするって感じ。あ、米国のRSがヤラセか
どうかまでは知らない。

で、まぁ、聞いたときは「ふ〜ん」程度だったんだけど。
聞き捨てできなかったのが「RSで女性ファンが増えた」
という話。

結局、「がんばってる若い男」が見れりゃいいわけだ。
だったら話は簡単。プログラミングでもRSやりゃぁいい。

お題を出して、出場者が解いて、時間や品質の優劣を競う。
これを週一くらいのペースでシリーズ化すりゃいいんだよ。
で、出場者をどっかに缶詰めにしてカメラ回す。できれば
チーム対抗のほうがいい。一人でモクモクとキーボード
叩いてるんじゃ間が持たないから。

LLの「君ならどう書く?」なんかも、もっとバトル要素を
全面に出したら面白い。優劣は審査員か観客に決めさせ
ればいい。

本家Permlink


2007年06月16日

スポーツ選手と違って、プログラマには試合というものが
ありません。言い方を替えれば、プログラマは毎日が
試合のようなものです。ゴルフでいうなら、毎日が18
ホールなわけです。ならば、18ホールを回ったあと、
つまり1日の仕事が終わるときには、Good, Better, Howの
振り返りをやってもいいんじゃないでしょうか。

Good, Better, Howは『ビジョン54』で紹介されていた
振り返りのやり方です。まぁ、KPTみたいなものです。

この振り返りはチームでやるのではなく、個人個人が
やればいい。

あ、そういえば、会長が書いたことでブームになりそうな
『感情』というテーマですけど。『ビジョン54』の中でも
感情は重要視されていました。

  感情を持って何かを経験することが結びつくことであり、
  何かを経験するときに感情を排除することは断ち切る
  ことになる。良いこととは結びつき、悪いことは断ち
  切る習慣を身につければ、ゴルフは時とともに格段に
  上達する。

本家Permlink


2007年06月14日1

でもさぁ、『ヒモを引け』っていわれても、むつかしい
んだよね、実際は。

きっかけってもんがあるわけだけど。でも、1つの現象を
見ても、それをきっかけと見なす人もあれば、何かヘン
だと思いつつも見逃す人もいるわけで。

そういうのを見分けるのって本能に近いもんがあるからね。
どうやってそういう能力を鍛えればいいか、自分には
ちょっとわかんないね。

--

誰かと何かを一緒にやるときは、相手の不安を取り除く
ことが大切。相手が何かに不安を覚えていないか感じ
取って、その不安が何かを探って、見つけた不安を取り
除く。何も占い師になれというわけじゃなくって、相手と
一緒に不安を突き止めて取り除くのでもいい。

でも、大抵の場合、人というのは『〜が不安だ』とはっきり
口に出すことはない。だから、相手の不安を感じ取る
必要はある。

前にも書いたけど、respectの日本語訳は『思いやり』。
『尊敬』っていうのは上下関係がつきまとうけど、思い
やりにはそういうのはない。不安を取り除くには思い
やりが欠かせない。

本家Permlink


2007年06月14日

でもさぁ、世界中の人たちが今日も動的言語で仕事を
してることを思えば、「動的言語で大規模システムは
ムリ」なんて、どこにも根拠はないよな。

たとえばPHPだったとして、そのユーザは数十万いるって
いわれてるんだっけ? その人たちはPHPっていう動的言語、
それはライブラリも含めた実行環境であるわけど、それを
使って仕事してるわけじゃん。つまり、PHPっていう1つの
動的なシステムを数十万っていう人たちが使ってるわけ
じゃん? それって十分大規模だと思うけど? で、その人
たちが毎日のようにDuck Typingのコンフリクトに悩まされて
るとか、ライブラリの使い方を間違えてるとか、そういう
ことがあるわけ? そんなんだったら今のWebサイトなんて、
どこも破綻してるっつの。

一体、そのいわれのない迷信はどっから来るの? 科学的、
統計的な根拠あんの? もし動的言語の大規模プロジェクトの
失敗例があったとして、それは静的言語の失敗率と比べて
極端に低いの? あるいは、失敗は言語だけのせいなの?
そういう迷信を信じるのが「工学」ってヤツなの?

いいよ、別に、大規模なんかで使われなくっても。
バカらしい。

本家Permlink


2007年06月13日1

Forthも可変長引数のワード、作れるんじゃないすか?
つか、Forthのワードの引数って、紳士協定みたいな
もんですし。PEEKすればスタック覗けますし。

Toy LanguageとしてならForthも面白いと思うんですけど
ねぇ。ああ、これはForthをくさしてるんじゃなくって、
手軽に作れるという意味です。そういう意味ではLispも
一緒。

--

質問の意図がよくわかんないんですけど。

  「大規模プロジェクトでメソッド名がコンフリクトしてDuck Typingが破綻
  する」という可能性はあるでしょうか?

あるかないかの二択だったら、あるとしか答えられない
でしょう。そういう意味じゃなくって? もちろん、
この可能性っていうのは、規模が大きくなればなるほど
高くなるでしょうし、かといって小さくても皆無とは
いいきれないでしょう。今は動いていても、将来の変更で
ヘクることがないなんてことは誰にもいえないですから。
そういう意味じゃなくって?

Shiroさんも:

http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Lisp%3a%e3%82%88%e3%81%8f%e3%81%82%e3%82%8b%e6%ad%a3%e8%a7%a3

の中で:

  滅多に実行されないコードパスに潜んだバグが実行時型エラーとして報告さ
  れる、これはLisperにとっての悪夢です。

って書いてます。

でも、何回も書いてますけど、なんでそんなに大規模を
問題にするかがよくわかんないんですよね。大規模って
いっても、小規模の集まりじゃなきゃ管理できないし、
大きくなればなるほど人間のほうが問題になって、言語で
解決できる領域は小さくなるでしょ。

pragmaticでない問題に拘泥しても得るものは少ないんじゃ
ないすか?

本家Permlink


2007年06月13日

アンドンっていうのは飾りじゃないし、何かの象徴でも
ない。そのヒモが引かれ、灯りがつくからこそ存在意義が
ある。いいかえると、アンドンはヒモが引かれるのを
待っている。

ヒモを引くのは誰か? そのヒモを引くのは人間だ。
何かの仕組みで自動的にアンドンをつけることができると
しても、人間がヒモを引かなきゃいけない場面は数多く
残される。つまり、あなたがヒモを引くべきときに気づき、
あなたがヒモを引かなければならない機会がたくさんある。

灯りがついたらラインが止まる。そして、ヒモが引かれる
原因となった問題をみんなで解決する。灯りがついたら、
あなたは今の作業を放り出して、現場に駆けつけなきゃ
いけない。

もちろん、アンドンというのは、フツーの開発現場では
比喩ということになる。それでも、あなたは声をあげる
ことはできるし、それをやらなきゃいけない。現場で
判断できない問題だったら、上の人間を呼んでこなきゃ
いけない。

問題を早く解決するなら、騒ぎを大きくするのも1つの
手だ。それはつまり『三人寄れば文殊の知恵』という
こと。

ちなみに、『文殊』というのは知恵を司る菩薩のこと
らしい。

--

ヒモを引くかどうか迷うくらいなら引け。

--

つまり道徳であり、教えであり、それを『道』と表現
することもできる。そういうことなんじゃないですかね。

そういうことを語るのは宗教臭い? ダサイ? 工学的じゃ
ない?

まぁ、そうかもしれない。

本家Permlink


2007年06月12日

棋士には二度のピークがあるっていう話は誰がしたん
でしたっけ? たとえば趙治勲は20台後半と40台前半と
で二度の大三冠を成し遂げてます。

趙治勲は50歳 (もうすぐ51歳) の今もタイトル保持者
ですけど。

http://ja.wikipedia.org/wiki/%E8%B6%99%E6%B2%BB%E5%8B%B2

ゴルフのことは全然詳しくないけど、たとえば
ジャック・ニクラウスなんかにしても:

http://ja.wikipedia.org/wiki/%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AF%E3%83%BB%E3%83%8B%E3%82%AF%E3%83%A9%E3%82%A6%E3%82%B9

40歳のときにメジャー2勝してるし、46歳でマスターズに
勝ってるし。

だからノビシロなんてぬかしてるうちはコゾーだって
ことですよ。

--

えっ? mputさん、メガネやめた? やめちゃった?

本家Permlink


2007年06月11日1

結局、自分にできること、それは自分がやるべきこと
でもあるんだけど、それっていうのは、立ち止まって
いる人を見つけることと、その人のそばにいって『何か
あったの?』と声をかけることなんだよな。それが
すべてといっていい。

その人が立ち止まってしまった原因を取り除くのは自分
でなくってもいいし、その人自身が取り除けるのがベスト
だし、あるいは他の誰かでもいい。

だから、その人がまた歩けるようになったら自分の役目は
終わり。

でも、こういうことは、わざわざ書くようなことでも
ないんだよなぁ。こういう『心がけ』っていうのは、
チームの誰もが持ってなきゃいけないもんだし。

ただ、これも勇気がいるんだよな。自分の時間を差し出さ
なきゃいけないから。でも、これをやんなきゃチームの
生産性なんて上がるわきゃないしね。

--

みんな結構シーケンス図好きみたいだけど、あれだったら
CRCカードのほうがいくない?

本家Permlink


2007年06月11日

そもそもパーティションなんているの? いると
したら、それは全然別チームとの壁としてであって、
中途半端な高さのパーティションにどんな効果が
あるかさっぱりわかんない。

つか、なんでそんなにパーティションにこだわるかが
わかんないよね。そんなんだったら会社なんかに来なきゃ
いいのに。さらにいえば、会社なんかに勤めなきゃいい
のに。自分一人で喰ってけって。

なんかさぁ、プログラミングが知的生産だなんて
勘違いしてるんじゃないの? つか、知的生産という
ものを誤解してるんだろうな。なんか、一人靜かに瞑想に
耽るみたいな? んなわきゃない。知的生産だからこそ
みんなで知恵を寄せ合わないといけないし、そのため
にはパーティションはジャマにしかなんないのに。
瞑想してーなら禅寺行け。

--

それっておかしくねーかな? まぁ、自分が年喰ってる
から反発したくなるんだけど。

若いときは知らなきゃいけないことがたくさんあるって
だけじゃないの? そりゃぁ、基本的なことの学習だったら
時間はあんまりかかんねーんじゃねーかな? それは伸び
シロとは違うだろ?

だから、自分の場合、伸びシロなんてーもんが最初っ
からなかったってことだな (笑)。

つかさー、マジでスポーツ選手じゃねーんだからさ。
もうちょっと希望持とうや。何度も書いてるけど、囲碁
じゃ50過ぎてタイトル取る人もいるんだしさ。老人だって
全員が全員ボケて死ぬわけじゃねーだろ?

本家Permlink


2007年06月10日1

規模が大きくなれば、それだけ念入りに準備が必要だ
っていうのは納得できる話ですよね。でも、だからと
いって、走ってる最中に考えるのを止めちゃダメでしょ。

あと、いきなり大きなチームで始めることもできない
でしょうね。それは失敗のレシピの1つでしょう。

だから、結局のところ、開発の確実性に合わせてビジネスを
変えるしかないんじゃないですかね。

--

http://d.hatena.ne.jp/tomatsu/

戸松さんじゃん! って思ったら全っ然更新されてなくって
ガックリ。

本家Permlink


2007年06月10日

いやいやいや、自分は結構読者を楽しませる努力はして
ますよ? でも、記事の背景とかグダグダ書いてもせん
ないでしょ? 大体、ここで選んでる元ネタなんて、ここ
読んでる人だったら知ってるのばっかりでしょ?

たとえば:

/~tko/cgi-bin/bakagaiku.rb?bakaid=20070528

の下にある句なんて、結構自信作なわけだけど。こんなん、
背景説明せんでもわかるでしょ? 『鬼』といえば当然、
『鬼車』なわけですよ、ね? 『松のもと』っていうのは、
もちろん、まつもとさん、ね? さすがにここまで書けば、
いくら鈍いご仁でもピンと来るでしょ? つまり、この
一句の意味を国語の問題風で解説するなら:

  夏に向けて青さを増す松のように、まつもとさんも
  段々世間に知られるようになったなあ。でも、その
  影で (小迫さんのように) 泣く人もいるのは悲しい
  ことだよ。

ってなるわけですよ、ね? ここ読んでる人で、こないだの
騒動知らない人なんていないわけでしょ? だったら、
『鬼』と来て、『松のもと』って来たら、『ハハ〜ン、
あれか』ってなるわけでしょ?

んで、句を書かないで上の解説をそのまんま書くって
のは芸がないでしょ? かといって、句と一緒に解説まで
書いちゃうと台無しになっちゃうでしょ?、作品として。
つまり、書かないことが読者のためなわけ。わかって
くれる?

あと、こないだ、『楽天にはいい印象持ってない』って
書いたこと、あったでしょ?

/~tko/cgi-bin/bakagaiku.rb?bakaid=200706041

で、そこで放りっぱなしでもよかったんだけど、たまたま
2chで目についた記事があったわけ。それがあのスレ
だったわけ:

http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=20070608

顧客満足度の調査で楽天がトヨタに次いで2位になった
っていう記事なんだけど。実はその調査会社である
シナジーマーケティングっていう会社が楽天から出資
されてたっていうオチ。こんなん、スルーしてもよかった
んだけど、ついこないだ楽天の話書いたばっかだから、
いちおーフォローでもしとこうかと思ったわけ。読者の
ために (笑)。

だいたい、アップしても、つまんないと思った記事は
消すこともあるしね。だいたい、ここも、『アジャイル
以外のこと書かなきゃいいのに』っていわれてるらしいし (笑)。
いや、ずいぶん前の評判だから今はどうか知んないけど。
って、ほっとけや!

本家Permlink


2007年06月08日

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

2007年6月6日の記事。そういえば、東洋経済でなんか
書いてあった気がする。

とりあえず自分的には「デ通サ」といったらNTTデータ
なんだけど (笑)。

自分はデ通サにはそれほど否定的じゃないんだけど。
少なくとも名目上はpay per useだから。ただ、早期に
サービスを解約するとお金を払わなきゃいけないのが
いただけないけど。まぁ、こういうのはケータイとか
でもよくある契約形態なんだけど。客をバカにしてる
契約形態だわな。

あー、でも、この某企業の話、国会で追求してくれねーかな (笑)。

--

http://news21.2ch.net/test/read.cgi/bizplus/1181204268/18

どんだけ〜 (笑)

本家Permlink


2007年06月06日1

『新しいPC買う!』って書きましたけど、マッタ!

実際注文までして、代引のお金も引き出したんですけど、
新モデル発売の予定があるという情報がショップから。

ぶっちゃけ、EPIAのファンレス + シリコンディスクで
DVIっていうのなんだけど。このDVIっていうのがポイント。

液晶の19インチで使うから、EPIAといえどもDVIじゃないと
不安なんですよね。発色とかはどうでもいいけど、プロ
グラミングにしても、文章を書くにしても、文字ばっかり
扱うことになるからボケるのだけはカンベン。

まぁ、リモート・ログインすることも多いんですけどね。

--

Jabberwockyっていうのがあるんですけど、これ、
死亡フラグ立ってる? 2年近く更新されてない。

--

いや、よくよく考えりゃ、怪しいんだよな。
まつもとさんも一時期ヒゲメガネだったしな。

筋書はこうだ。ある日突然一通の手紙が送られてくる。
そこには:

  前略。貴兄のヒゲメガネには感服いたしました。もし
  これからもヒゲメガネを続けるようであれば、些少
  ながらご援助いたします。

                                    ヒゲメガネ連盟

なんて書いてあるわけだ。あの豊富な資金を考えれば、
考えられなくはない話だろ。そういうのが全国に何百人か
何千人かいるだろ、こりゃ。

でもな、そんなんで浮かれてると、留守の間に家に
トンネル掘られるぞ。銀行までのトンネルを。

本家Permlink


2007年06月06日

そうそう、市況1板も見れねぇんだ (笑)。

つか、復旧なんかどうでもいいから、サバ立ち上げて
ほしい。

本家Permlink


2007年06月05日1

ダメだこりゃ。apt-get upgradeすると落ちる。これの
とき落ちると後がメンドーで閉口しすぎる。いいかげん
頭来て、新しいPC買うことにした。この不安定なマシンは
etch amd64にしちゃる。

本家Permlink


2007年06月05日

でも、デバッグのやり方なんて、フツー教わらないよ?
そこらへんに転がってる入門書でデバッグのことを
しっかり教えてるのなんてある?

--

ああ、もちろん、ヒゲメガネは特定の人物を指している
のであり、ゴチャマンといるヒゲメガネ諸兄を指している
わけではありません。

--

まぁ、自分の話でいえば、会社を良くしようとは思って
ないんですね。拾われた形だけど、そこまで恩義も感じて
ないし、お金ももらってないし。それと自分のチームを
良くするのとは話が違う、というのが自分の中にあるん
です。都合いいですけど (笑)。

お金云々よりも、「会社」みたいな顔の見えないものだと
気合が入んないんですよね。それよりも、一緒に仕事してる
仲間だとか、そういうのがあると気合も入るし。だから、
人に恵まれるっていうのは、自分にとってとっても大切
なんですけど。

本家Permlink


2007年06月04日1

まぁ、自分も公言してるけど、ヒゲメガネはダメだね。
なんでみんながあんなにありがたがるのかわかんない (w
Gauche Nightで呼んだ理由もわからないし (w

--

ついでにいうと、というか全然関係ないけど、自分は
楽天にはそれほどいい印象を持ってない。まぁ、それほど
悪いわけでもないけど。

ただなぁ、楽天の件は別だとしても、まつもとさん、結構
ホイホイ名前貸しちゃうからなー。ほんと、「殿、御身
お大切に」って感じ。

本家Permlink


2007年06月04日


本家Permlink


2007年06月02日

http://www.itmedia.co.jp/news/articles/0706/01/news026.html

これをきっかけにアチコチと。

http://ja.wikipedia.org/wiki/TI-89_%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA
http://ja.wikipedia.org/wiki/TI-92_%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA

TI-89の上位機がVoyage200。一回ここでも取り上げた覚えが
あるんだけど。で、日本でも売ってるらしい:

http://www.naoco.com/price.htm

それにしても、今じゃなかなか見られなくなったサイト
デザイン (笑)。

でも、よく考えたら、このVoyage200が$170だっていうから、
OLPCのって、これより安いんだよな。確か$150だったよね?
で、Linuxが使えるわけだし。

とはいえ、やっぱりVoyage200の雰囲気も捨てがたい。
ポケコンぽいのって、今じゃこれくらいしかないんじゃ
ないの?

--

http://youtube.com/watch?v=Kb1wuBFfALs

速弾きヤローはいろいろいれど、やっぱりエディーは
スペシャルだって!

--

http://youtube.com/watch?v=1xPGqWt3L7A

ジミヘンが歯で弾いたっていうのはあったけど・・・
でも、これ、曲もいいんだよな・・・

本家Permlink


2007年06月01日2

勘違いしてる人が多いのかな? 天才が書くコードは
必ずしもきれいとは限らない。天才が天才と呼ばれる
のは、彼が実現した機能やサービスに対してであり、
コードのきれいさとかは関係ない。

それと、品質はツールじゃ解決できない。それも当たり前。

結局、製品の品質っていうのは、それを作る組織の品質が
反映されるもの。だから、一人でがんばるよりも二人で、
さらにはグループで、さらには組織全体でがんばるしか
ないし、それは理想論でもなんでもなくって、組織として
当たり前のこと。

本家Permlink


2007年06月01日1

http://www.asahi.com/national/update/0531/TKY200705310308.html

  「ITに頼って便利になったが、光と影があり、影の部分の恐ろしさを十分
  認識した」

ありえんだろ、こんなマヌケなセリフ。

http://www.nikkeibp.co.jp/archives/237/237977.html

本家Permlink


2007年06月01日

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

不勉強で申し訳ないんですけど、よく理解してません。
ただ、実際にこの問題にぶつかったので、これからちょっと
読もうかなと。

JavaなんかのほうがわかりやすいんでJavaで書きますけど、
極端な例でいえば:

class Parent {
}

class Child extends Parent {
  public void doit() { ... }
}

みたいな関係のとき、このリスコフ置換原則が崩れて
いるというんじゃないですかね。つまり、サブクラスの
ほうに (スーパークラスにはない) 固有なメソッドが
あって、なおかつそれがpublicという状態。これがなぜ
マズイかというと、このメソッドを使うときには、当然
ながらサブクラスのほうで受けないといけなくなるから:

void call(Child child) {
  child.doit();
}

これを:

void call(Parent parent) {
  parent.doit();
}

とは書けませんよね。当たり前ですけど。

他の原則として、受けるときは抽象度の高い型で受けて、
返すときは抽象度の低い型で返すっていうのがあります。
たとえば:

<T> ArrayList<T> copy(List<T> list) {
    ArrayList<T> copy = new ArrayList<T>();
    for (T elt : list)
        copy.add(elt);
    return copy;
}

みたいな感じ。これを:

<T> ArrayList<T> copy2(ArrayList<T> list) ...

とか:

<T> List<T> copy2(List<T> list) ...

とかは書かないわけです、原則としてね。

で、最初にあげた例は、この原則を破る方向に圧力が
かかりやすいわけです。抽象度の低い型で受けないと
いけないんですから。

自分が実際に出会った問題っていうのは、モックがらみ
でした。モックの実装ってやり方はいくつかありますけど、
モデルとモックで共通するインタフェースをくくり出すって
いうのもあります:

interface Interface {
  public doit();
}

class Model implements Interface {
  public doit() { ... }
}

class Mock implements Interface {
  public doit() { ... }
}

で、このとき、当然ですけど、モデルのほうにだけ存在
するメソッドっていうのは、テストできないわけです:

class Model implements Interface {
  public dothat() { ... }
  ...
}

だから、このメソッドをインタフェースのほうにも引き
上げなきゃいけない:

interface Interface {
  public dothat();
}

もちろん、モックでも実装します:

class Mock impelements Interface {
  public dothat() { ... }
}

まぁ、これだけの話なんですけど、実際にはdynamic_cast
なんかもからんでて、変更が広範囲に及んでいて、結構
手間でした (AfxGetAppの値をモデルにキャストしてた)。

でも、リスコフ置換原則を厳密に守ろうとすると、
ぜんぶのメソッドをObjectに集めなきゃいけなくなるん
ですよね。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails