以下のエントリを読んで少し気になることがありました。

Collection & Copy - 日記 2007-02-9、ブログを書くことより

「ブログに載る新しい情報も、企業の中ではもうずっと前から使っていて、あたりまえになっていることがよくある。技術を専門に研究する人たちもいて、金もある。そして、そこで生まれた知識は社内だけで共有される。」

こういう発言に嫌悪感を示すのはそれはそれでいいのですが、少し冷静に考えて見ましょう。そもそも社内の技術共有ってそんなにうまくいくのでしょうか。私は以前の会社で、上記で言うところの専門に研究する人っぽい仕事をちょこっとだけしていたことがあります。その経験上、得た知識を社内に広めようとすると、会社という枠内の活動では非常に薄まったものしか広められないという現実に突き当たったことがあります。

つまり、以下のエントリに同意です。

yosisの日記より

「確かに"技術を専門に研究する人"はいるが、"ブログに載る新しい情報"→"企業：当たり前"ではない。 　また、"そこで生まれた知識は社内だけで共有される"は嘘。社内でも共有されない。」

ブログ、勉強会、オープンコミュニティの活動では非常に濃い密度の情報交換が行われます。これだけ濃い共有が土日にできるのに、平日にはこんな薄い情報の共有しかされないのかと驚いた記憶があります。

これは、モチベーションの違い・・・ということなのでしょうか。誰かが調査してそれを社内で共有という理路整然としたプロセスに無理があるのかもしれません。

今日は PC 用に新しいスピーカーを買いました。ONKYO の GX-77M です。我が家のミニコンポの調子が悪くなって以来、PC で音楽を聴くことが多かったのですが、これまで使っていたスピーカーは、15 年くらい前の謎のもので、音質がどうとかいえるレベルのシロモノではありませんでした。

新しいスピーカーを買うといっても、私は音響に詳しいわけではないので、選択基準は、PC 用でそこそこの値段に収まって、あまり個性のでしゃばらないものにしました。とりあえず、机の上に設置したところ、音響は圧倒的に改善されました。よかったよかった。

そろそろ Ruby の勉強を本格的にしたいと感じたので、まずは動的にクラスを定義する方法を調べてみました。以下のコードでは、動的にクラスを定義して、アクセッサ（my_name）を追加しています。

# Class の定義
my_new_class = Class.new
my_new_class.class_eval("attr_accessor :my_name")

# Instance の生成
my_new_object = my_new_class.allocate

# 生成した Instance を使用する
my_new_object.my_name = "akasata"
printf "My name is %s!\n", my_new_object.my_name

ここまでは楽勝です。さすがは Ruby。（LL では大抵楽勝だと思いますが。）

最近、ラヴェル作曲「水の戯れ」を練習しています。ラヴェルらしいやや無機質で美しい響きと、夜のガスパールやクープランの墓ほどではないにせよ、技巧的な面が光る名曲です。この曲が登場するテレビ CM があるのですが、その Web サイトを発見したので、下に貼り付けておきます。

TVCM｜フォーラムエンジニアリング
http://www.forumeng.co.jp/company/tvcm.html

Delphi for PHP が出るそうです。Delphi の名を冠していながら、Delphi 言語では開発できないなかなかナイスなシロモノのようです。RAD だから、IDE だから、というか、ツールが Delphi っぽいから Delphi の名前がついたみたいですね。
# だったら Delphi 言語なんて名前にしないで Object Pascal で良かったじゃん！
## と、随分昔の話題を蒸し返してみる。

もう少し Delphi にはがんばってほしいのですが、Kylix や Delphi for Java といっていたときのような気概を感じられないのがなんとも残念です。これじゃお布施は集められないな～。

今日は、前の会社の所属の（私の）送別会に参加してきました。来てくださった皆様、ありがとうございました。チャンスに恵まれて、いろいろな人からあたたかい言葉をいただいて、とにかくがんばらないといけないことを実感。

ふー、こういうプレッシャーを自分にかけたことがあったかなー、とちょっと振り返りたくなりました。これから半年間、とにかくがんばります！

Rails勉強会＠東京第15回に参加して、Rails 1.2 に関する情報を収集できたので、Kodougu を 1.2（これまでは 1.1.6）に上げてみました。

後悔した。orz

やってみたところ、DEPRECATION WARNING が大量に出てしまいました。@header（推奨は @ を外す）とか start_form_tag（推奨は form_tag）とか修正箇所は 100 箇所近くに及びました。（コード総数は 1500 行程度だったと思います。）
# 1.2 以前に既に Deprecated になっていたものも混ざっているようでしたが・・・。

まあ、修正の絶対量はたいしたことがないのですが、困ったのは、Ajax を使った機能でレスポンスが 30 秒位たたないと返ってこないという現象が発生したことです。最初は、私のコードに根本的な問題があって、Rails 1.2 ではこのパフォーマンスしか出ないのかと勘違いして、冷や汗・・・というか恐怖すら覚えました。(^^;
結局、@header を修正したら収まって、従来どおり 0.2 秒位でレスポンスがくるようになりました。DEPRECATION WARNING が大量に出ると、処理が重くということでしょうか。

まあ、結果的にはどうということもなかったのですが、あまり心構えをしないではじめたせいで心臓に悪い作業になってしまいました。(^^;

2/16 にポジションペーパーを作りましたが、昨日（2/18）はRails勉強会＠東京第15回に参加してきました。参加したセッションは以下のとおり。
・ Rails v1.2 の変更点と REST との関係
・ Agile Model Driven Development with Rails

以下に簡単な感想を記述しておきます。

■ 勉強会の形式
オープンスペース形式で全後半のセッションがありました。自己紹介はポジションペーパーを使いましたが、ネタでアイスブレーク（かなりイタイです^^;）をしたりとか、柔軟に運用していました。

■ 参加者
この勉強会には SIer、Web 系、研究系など意外と幅広い方が参加されていました。やはり、この手の勉強会は刺激になります。こういう勉強会がないと、高いスキルを持った人と出会う機会がないですからね。
# いや、別に前の会社でそういう出会いがなかったと言うわけじゃないのですが。

■ 雰囲気
ライトニングトークスとかではないので、若干まったりした雰囲気も漂いつつ、そこそこ濃い話をし合う勉強会だったと思います。「こう書くと気持ちが良い」という議論が多いのはこの手の勉強会ならでは。Rails の勉強会は、Java をやる人が多いせいか、若干 Java 世界の香りもしました。

■ 内容
Rails のようなフレームワークを使っていると、悪い意味でのアジャイル（安い、早い、マズイ）と誤解を受けることがあります。この勉強会では Rails はどちらかというと対象としている領域に対しては、しっかりとした理論的な下地を持った「良い意味で堅いフレームワーク」ということが実感できました。
# scaffold があるからって Rails 風を名乗るなよ！
# それは単なる宣伝文句なんだ。鵜呑みにしちゃだめだ！

モデリングにもそれなりの関心が払われていることは興味深い現象でした。もちろん、UML 限定とか狭義のモデリングではなく、開発に必要な情報を集めて整理してから開発を進める必要性をちゃんと認識しているということです。

あと、勉強会で人の話を聴いていくうちに、Rails はもっとうまく使ってやらないとかわいそうだと実感しました。使い方によっては、もっともっと高い生産性を発揮できるフレームワークなんですね。
# やはり scaffold だけじゃない。

■ お礼
最後に、勉強会を運営してくださった皆様（特にドリコムの方々）は、お疲れさま＆ありがとうございました。

弾氏が面白いエントリを書いていらっしゃるので、私も思うところを書いてみます。

発端は、分裂氏がプログラマの労働条件を過酷にしているのは、プログラマが労働力のダンピングをしているからであるという議論を始めたことです。それに対して、弾氏がプログラマを労働者よりは作家や芸術家に例えています（労力と成果の関係があまりに非線形であるため※）。

※ 労働者＝労力に対して対価を受け取る人と定義しています。

404 Blog Not Found:プログラマーって本当に労働者なのか? より

百歩譲っても、プログラマーというのはメタ労働者ではあっても労働者とは言えないと思う。厳しいようだけど、労働者として扱ってもらいたかったら、プログラマーではなく別の職を選ぶべきだと思う。少なくとも、それを本職にするべきではない。

弾氏の気概を感じますね（笑）。弾氏も分裂氏もプログラマは主体的に自己の労働環境の改善をしていかなくてはならないという点では共通しています。

立石氏は少し立場を変えていて、プログラマをひとくくりにしないで、芸術家的な要素を持つプログラマ（立石氏は「開発型」と呼ぶ）とそうでないプログラマ（「生産型」「運用保守型」）を分けて考えましょうと提案しています。（後者は労働者という考え方です。）

で、私の考えです。私は「プログラマは主体的に自己の労働環境の改善をしていかなくてはならない」というメタな点では、分裂氏にも弾氏にも賛成です。ただ、立石氏のエントリにもあるように多様性を認める必要があると思います。
弾氏にせよ分裂氏にせよ、抜群に優秀なエンジニアじゃないと成り立たない議論をしているような気がします。そういう気概を持つことはすごく大切なのですが、労働者として安定して働きたい人も多いはずです。エンジニアは自分がどう働きたいのかを明確にした上でそれを発信していくことが必要なのだと思います。
# でも、会社に居たときから「エンジニアの自分自身が働く環境に対する意識の低さ」は気になっていました。

■ 議論の流れと関連エントリ
分裂勘違い君劇場 - プログラマの労働条件を過酷にしているのは、過酷な労働条件を受け入れるプログラマです
http://d.hatena.ne.jp/fromdusktildawn/20070216/1171627060

404 Blog Not Found:プログラマーって本当に労働者なのか?
http://blog.livedoor.jp/dankogai/archives/50766218.html

コンサルタントのネタモト帳＋（プラス） 人月神話：「プログラマー」は労働者？芸術家？ ～ ほぼ日刊で「経営の話題ネタ」を名古屋から発信！社労士・診断士のコンサルタント立石智工のビジネスヒント集
http://blog.goo.ne.jp/tateishi_awing/e/a71aa46b86aac6d9df78aa73a37e4dda

404 Blog Not Found:俳優と脚本家
http://blog.livedoor.jp/dankogai/archives/50766689.html

何かと難しい goo ブログとのトラックバックなどをまじめにテストしてみることにしました。

とりあえず、以下にページ作成します。（言及リンク対策。）
http://blog.goo.ne.jp/akasatarec/
http://blog.goo.ne.jp/akasatarec/e/d0ba1a2fa56aab8cb83d75153e6a438d

さて、トラックバックはうまくいくでしょうか。

■ 9:54 追記
受信成功。ただし、こちらのトラックバックは goo に受け取ってもらえず。はてなは受け取ってくれるのに。（泣）