最新 追記

Matzにっき


2007年12月14日 [長年日記]

_ [OSS] 日本の技術者によるOSSの貢献が少ない理由 - WebStudio

「忙しすぎるから」。

確かに、私が大学卒業して最初に就職した会社では、 夜の3時を過ぎると徹夜勤になって次の日が休みになってしまうから、 その直前にタイムカードを押す、という同僚がいたよなあ。

あと、一ヶ月の超過勤務が200時間とか。 普通に1ヶ月勤務が(8時間×20日働いて)160時間なのに、 残業の方が多いとはどういうことかと。

そこまでして仕事しないといけない状態では 確かにオープンソースソフトウェアに貢献なんて考えられない。 っていうか、仕事以外の私生活は存在できないんじゃないだろうか。

オープンソースへの貢献がどうこういう前に 「生活の質」を向上させる方がずっと先のような気がしてきた。

私は帰る時には帰ってしまうし、 有給消化も積極的なヒトだったので、 あんまり長時間勤務というのは経験がない。

その辺もRubyを作れた原因のひとつかもしれない。

運がよかったというよりも、当然の権利を主張しただけだと 思ってるけど。

_ [Ruby] 福山

講演会の依頼で福山へ。 松江駅から岡山経由で。

駅を出たら目の前が福山城でびっくりした。 こんなに駅に近い城は他にないのではないか。

その後、1時間半ほど講演する。

出席した人は70人ほどか。 思ったよりもスーツ率が高く、 ちょっと内容が技術よりすぎたか。

質疑も少なく、もしかしたら外したかもしれない。


2007年12月11日 [長年日記]

_ MORI LOG ACADEMY: なんとなく節目かも

森博嗣が5年後に引退するという話。

なんか期限を決めて引退とか、あんまり想像できないな。 どういう感覚なんだろう。

小説家とプログラマは、元手がほとんど要らない点や、 ひとつの世界をゼロから創り出すという点で よく類似しているような扱いを受けるし、 私も類似点はあるのだろうなと思う。

しかし、こうしてみると相違点もあるかもしれない(私は小説家の実体はわからないけれども)。

「作品」としての小説とソフトウェアの最大の違いは、 やはりその手離れの良さだろう。 普通、小説は一定期間で完成し、一度完成したらほとんど手を入れることはない。 出版後に小説に手を入れることは、それほど多くはない(ようだ)。 たとえば、井伏鱒二が「山椒魚」の末尾を削除しちゃった話は有名だけど。

小説も改版のときに少々直しを入れることはあるらしいけど、 ソフトウェアほどではないだろう。

一方のソフトウェアは、手離れが悪い。 私がRubyの開発を14年も続けているのなんてその最たる例だろう。 公開しながら14年間もほぼ毎日手を入れるような例が小説にあるとは思えない。

また、結果のコントロールしやすさという点でも、 小説とソフトウェアは異なる。 小説を読んだ結果というのは、読んだ人がどう感じるかというのが 一番重要なことだと思うが、同じ本を読んでも感じ方は一人一人違う。

一方、ソフトウェアは結果を「再現」するものは 再現性の非常に高いコンピュータである。 基本的にソフトウェアは作者の意図通りに動くはずだ。 バグがなければ。そしてバグがないことは滅多にないけれども。

というわけで、小説とソフトウェアは作品としての性質は結構違うという話。

でも、世界を創る「万能感」が動機になってるところとかは、 「小説家」と「プログラマ」はやっぱり結構似てるかもしれないけどね。


2007年12月10日 [長年日記]

_ Thinkpad

もう、ほぼ落ち着いたのだが、やや不満がある。

  1. eth1になったこと。znzさんのご指摘通り、 /etc/udev/rules.d/z25_persistent-net.rulesを書き換えたら直ったけど。 なんでここが書き換わったんだろう。
  2. サスペンドからの復帰にたまに失敗する。X31のACPIのできが悪いせいかも
  3. サスペンドから復帰するとネットワークが切れる。gnome-power-managerが 悪さしているのか。それともpowersavedか。簡単な設定では直らないみたい。
  4. sessionでアプリが自動起動するのは良いけど、ウィンドウサイズや位置を覚えててくれない。
  5. sessionでFirefoxが自動起動しない

まあ、4と5は以前の環境ではできていなかったので、贅沢なんだけど。

2はKernel起動時にAPMを指定することで解決。 ACPIの方が温度とかたくさん情報がとれるので(メーター好きには)嬉しいんだけどな。

3はpowsersavedをアンインストールしてみるか。

追記

powersavedが正解。apmdを代わりにインストールしたら、 ネットワークが切れなくなった。gnome-power-managerは APMだとバッテリ状態がわからないみたい。

バッテリアプレットがちゃんと動くからメーターとしては問題ないんだけど。

_ [OSS] OSCARアライアンスが解散へ - ITmedia エンタープライズ

発展的解消というプレスリリースだが、 まあ、結局はいろいろうまく行かなかったんだろうなあ。

やはりアプリケーションレイヤーでオープンソースというのはチャレンジが大きいのと 関係があるんだろうか。いや、オープンソースじゃなくてもチャレンジは大きいのだが。

アプリケーションレイヤーのように直接のユーザに近ければ近いほど、 いろいろな「注文」を一手に引き受けることになる。 日本のような「出来合いシステム」になじみのない環境では、 「ソフトに自分を合わせる」ということを要求するやり方は 受け入れられるためにかなり強い動機づけが必要になる。

それに比べたら、直接のユーザインタフェースを伴わない ミドルウェア、開発ツール、言語、OSはよっぽど簡単だ。 オープンソースソフトウェアの成功例がこのような分野に多いのは偶然ではないと思う。

とはいえ、アプリケーションレイヤーでの成功例もこれからどんどん出てきてほしいのだが。

(隠れた成功例: ORCA)

_ 安物買いの銭失い...開発をアウトソースしてはいけないという事例 - masayangの日記(ピスト通勤他

ボーイングが787の100億ドルの開発費を削減するために 積極的にアウトソーシングを押し進め、結果として20億ドル余計にかかった という話。

やはりコアな部分はアウトソースしてはいけない、ということだ。

ソフトウェア開発という多くの企業にとってそれなりに重要な部分を 受託開発という形で請け負っている会社の従業員としては 複雑な気持ちである。

が、みんながみんな結局はコア技術は自分のところで開発した方が良い ということに気がついちゃったら(実践できたら)、日本のIT業界は 完全にひっくり返るだろうな。

それでいいのか。いいのか。

_ 【IT Service Forum 2007】「摺り合わせ文化など日本には日本の良さがある」,国内SIベンダーの強みを力説:ITpro

で、思い出したのがしばらく前のこの記事。

いや、言ってることが間違いだとは思わない。

「日本には摺り合わせ文化があり,日本独自の文化と商習慣がある。社会基盤が異なる国で生まれた標準をそのまま適用するべきではない」(阿部氏)。

「システム開発において日本のSIベンダーはインドのSEと戦えるのか」という問いに対して「(顧客企業の業務ノウハウに強いなど)日本独自の世界でなら,日本がインドに負けるわけがない」と断言。「シリコン・バレーと同じことをしていたら,日本は他国に勝てるわけがない。逆に,日本独自の世界でなら,他国に負けるわけがない」

それは確かにそうなんだけど、それって「日本的な環境がこれからも維持されたら」とか 「日本だけで十分な市場規模が維持できたら」とか、 「日本の独自文化を維持するためのコストが正当化されるなら」というような、 今となってはいつまで続くかわからない暗黙の前提があるのではないか。 特に最後のが一番怪しい。

幕末期に「近接戦闘なら武士が負けるはずがない」と 言ってるようなもので、明治維新で武士という身分そのものがなくなってしまうような 前提条件がひっくり返りそうな気配が見える時に、 トップがそんな危機感のなさを公言してしまうのは、こちらが空恐ろしさを覚える。


2007年12月07日 [長年日記]

_ [Ruby] ナレッジエース - autocomplpop.vimがバージョンアップしてRubyのオムニ補完とファイル名補完に対応

Vimの補完機能であるオムニ補完のRuby対応について。

なんだかとっても賢い補完をしているように見えるんだけど、 実際にはどうやっているんだろう。

どうも変数に格納しているデータの型まで見ているみたい。 スクリーンショットにあるのは「代入された時の右辺がリテラルだったら、その変数の型を決定する」という挙動で説明できるけど、それだけだと、日常的には嬉しくはないよね。 ローカル変数ってのはリテラルで初期化されるものばかりじゃないし。

いずれにしても、コンテキストを考慮する補完というのは すばらしいことだし、それを実現しているVimについては賞賛しておきたい。

_ The Programmer Dress Code

プログラマの外見。 なぜか私も載っていたりする(ひげのせい?)。

しかし、「恐い」とか「子供を食べちゃいそう」とかひどいコメントが多いな。

_ [言語] i c e d ( j a v a ): The Evolution of Java

Javaの進化(イメージ)。

Java 7の評価がめちゃ低い。 新しいものを導入する時には「変化の痛み」があるせいか、 大抵、評価は低いよね。

私は自分自身でJava 7を使うことはないと思うので、 私の知っている範囲内ではそんなに悪くない(むしろもっとやれ)という感じなんだけど。

_ [言語] VanPyZ Presentations - Pythonと他言語の比較

Pythonと他言語の比較。比較対照は

  • Erlang and Processing, Dethe Elza
  • Ruby, Paul Prescod
  • Icon and TCL, Brett Cannon

なかなか面白い。しかし、ErlangとProcessingとか、IconとTCLってのは あんまり関連のある組み合わせじゃないよなあ。

_ Michael’s Random Thoughts >> Every open system develops towards the unusable

あらゆるシステムは使い物にならなくなるまで進化する、という話。

  • ナイス。これもできるといいんだけどな
  • これらもできると嬉しいんだけど(機能は増え続ける)
  • すごいっ
  • サイコーっ
  • (ユーザーの満足度、頂点)
  • マニュアル見ないとわからないな...
  • ○○機能はどこにあるんだ
  • 基本的なことさえできないじゃないか
  • もうだめだ...

くわばら、くわばら。

_ [言語] jaql.org

JSONオブジェクトデータに対する問い合わせ言語。

なぜかHadoopで検索する機能もついているようだ。 まだ中身を見ていないけれども。

_ [Ruby] @Ruby City Matsue : Java/JRuby for Shimane Univ. and OSS community

Sunの下道さんに(島大の講義のついでに)、オープンソースサロンでも講演していただいた。 JRubyとの比較や歴史を含めて非常に面白かった。

おまけの「Matzをさがせ」も楽しんでいただきたい(楽しくないって?)


2007年12月06日 [長年日記]

_ 取材

笹田くんとふたりで某ウェブマガジンの取材を受ける。

リリース間近の1.9の話題ということだが、 止められないので、あちこちに寄り道しながら適当に話をする。 途中で1.9の仕様議論が始まったりして。

取材終了後、昼食も一緒に食べ、 大変楽しい時間を過ごさせてもらったが、 うっかり時間を忘れてしまって、 飛行機に乗り遅れた(またかよ)。

最終便でなくて本当によかった。

_ 2007-12-04(火) - 丸い地球と静かな月、蒼ざめる太陽

梅田さんとの対談に関連して、 筑波大学評が面白かった。

筑波大学は微妙なランクづけの大学です。

(中略)

というわけで、筑波大の男性と女性は、おのずと仲良く暮らして共存するしか道はなく、身近にいる、自分と同じくらいのレベルの身なりの田舎の学生である同級生や先輩・後輩などと健全におつきあいするのでした。

そうして、全体的にのんびりとした人格形成がなされ、

遊ぶ場所もないからひたすらに好きなことに没頭して、

(まつもと氏の場合はプログラミングだったのかも。

純粋培養の中で、おひとよしで、利害関係にもうとい、でも専門分野にはやけに強い人間がつくりあげられてゆくのでした。

私の人格に筑波大学らしさが反映されているかどうか、 自分ではよくわからないんだけど、 「おひとよしで、利害関係にもうとい、でも専門分野にはやけに強い人間」 というのは当たってると思う。

いや、私は高校時代からそうだったような気がするけど、 そうだとしても自分にふさわしい大学を選んだのだと思う。

でも、そういうのって、日本だと東京とかの一部の都会を除くと ごく当たり前なんだと思うけど。

それはともかく、 東京の雑踏とかに立つと、 なんとなく「激しい生存競争」を連想させて げんなりする。「私はここにいるべきじゃない」と強く感じて 田舎に帰りたくなる。

シリコンバレーに行っても、ほかの誰かみたいに「こここそ天国」とは 感じなかったのは、アメリカに付き物の「生存競争の臭い」がしたからかも。

_ 私のような仕事につく方法

Aaron Swartzの講演録。 一番印象に残ったのはここ。

みんな自分のやっていることがわかっていないと仮定すること。多くの人は何かを試みることを避けるが、それはそのことについて十分に知らないと感じるためか、自分の考えつくようなことは誰かがすでに試しているだろうと思うためだ。物事を正しくやる方法について何かアイデアを持っている人というのはごくわずかで、新しいことを実際試みる人となるとさらに少ない。だから何かについて最善の努力をするなら、 結構うまくいくものなのだ。

そう、ほとんどの人は自分がなにをやってるか分かってない。 自分の行為の結果を予想できない。 できても、それは大抵はずれる。

にもかかわらず、分かっていると思いこむことに問題があるのだ。

しかし、逆に考えてみよう。他の人がほとんど現実を認めることができていないのだとすると、 現実を認めるだけで、あなたはまわりの人よりも 大きな一歩を踏み出していることになる。

Aaronの言いたかったことはそういうことなんだと思う。


最新 追記