Matzにっき

_ [車]タイヤ交換

雪。寒い中だるまのように服を着込んでタイヤ交換。前回のようなバカな真似はしないぞ。 でもあんまり寒いんで前輪交換だけで挫折。後輪は後で換えよう。

_ [家族]クリスマス

近隣に住む妹家族と弟家族とともに米子の実家に集合。総勢14名。 ほんとに全員集まるとさらに5人追加。一族と呼ぶにふさわしくなってきてるな。 となると親父は族長(patriarch)か。冗談のような本当の話。

クリスマスの歌やプレゼント交換などが行われる。 料理がまったくクリスマス的なメニューでないのは、 日本的クリスマスという伝統が生まれつつあるのか。 違うような気もするが。

宣教師として働いている弟へのメッセージをテープに吹き込む。

_ IPAヒアリング

今日はIPAの方から人が来て、昨年度の「オープンソフトウェア活用基盤整備事業」*1についてヒアリング。

IPAは今年から独立行政法人になったので、今まで以上に投資が有効活用されているかチェックする必要があるので、改善点があるか、無駄はないかなどをチェックする調査を行うことになったのだそうだ。わざわざ松江までいらっしゃるというのは本気である。

で、つらつらと普段から考えていることなどをお話しした。 IPAの事業はオープンソースソフトウェアのスタートアップを直接支援する数少ない事業なので、 ぜひ継続していただきたいと考えている。 「スタートアップを支援するだけでよいのか」という声があることは承知しているが、 企業系オープンソースソフトウェアで一番の難関は始めるためのリソースの配分であるのは事実なので、 それを支援することは有意義であると考える。「継続を支援する必要があるか」については、 別のところで今後書くことにしよう。

また、IPAは私の知っている「お役所系」の中ではもっとも対応が良い。 毎回いろんなチャレンジを行い、毎年改善されている。 現在残っている不満といえば、2点だけ。

• 応募時にどのくらいの規模のプロジェクトになるのかを人月ベースで見積もる必要があるのだが、 詳細な見積もりを行うためにはあらかじめ相当突っ込んだ設計を行う必要がある。 しかし、採択されるか分からないものをそんなにコストをかけて設計・見積もりするのは難しい。 これが普通のビジネスなら顧客が「そのプロジェクトの成果でどれだけの価値を創造するか」という点からキャップをかけるのだが、ほとんどの場合IPAは成果物のfirst userではない。
• 事業開始時に「実施計画メモ」というのを作成するのだが、 これが開発内容の詳細を記述したものであるので、 プロジェクト開始時に開発成果物のほぼ完全な具体像が必要。 Exploratory Developmentは難しい。

まあ、国民の税金を無駄づかいさせるわけにはいかんので、 正しく使われたことを担保することが必要なのは分かるし、 そのために我々がきちんとレポートするのはやぶさかではないのだが、 開発に制約が付くのはあまり嬉しくない。

アイディアとしては、「300万コース」、「1000万コース」、「3000万コース」など複数のコースを設け、 「社会に対するプロジェクトの価値」を外部の有識者(PM)に評価してもらう。 応募の中から「プロジェクト(or アイディア)が応募したコースに見合う社会的価値があるかどうか」を判断基準にする、 というはどうだろう。

あまり欲を出して高いコースに申し込んじゃうとアイディアは良くても落ちちゃう。 あるいは「もうちょっと金額の低いコースに申し込みませんか」とか勧めるとか。 もちろん、最終的に無駄づかいしてないかのチェックはきっちりやるとして。

ああ、でも単年度主義が障害になるかもしれないな。 「あなた3000万コースだったけど、使わなかったから実際には1500万ね」とかやっちゃったら、 予算が余っちゃうものな。来年に回すというわけにはいかないのが日本の行政のようだから。

参考:

「経産省の2005年度オープンソース関連予算は2004年度の1.5倍」 − NikkepBP ITpro

追記

あ、今思い出した。私の立場から、オープンソースを支援することが意味があるのは確かなんだけど、 それだけじゃなくて、 支援の成果物をオープンソースにすることで、成果物が埋もれてしまう(＝支援が無駄になってしまう)ことを避けることができるのは、税金の無駄づかいを避けるという立場からも有意義だと思う、というような話もした。

_ [Ruby] Ruby2について考える

先日、「もし、まつもとさんがバスにはねられたらRubyはどうなる」と質問された。

答えは「1.8はそのままバグフィックスしながら継続。現在のRubyは十分に良いから。1.9は自然消滅するかも」である。

ま、自分でも「十分に良い」と思っているRubyだが、改善の余地がないわけではない。

で、改善したい点はいくつもあるのだが、一番気になるのがスコープ問題。 具体的には

• 変数をブロックの外で使いたいために、宣言としての無駄な代入が必要になる
• 後置ifなどモディファイヤーの中で代入された変数が、前に登場する本体部で使えない
• 変数がどこまで使えるのかわかりにくい

そこで、以下のようなルールにしてはどうだろうかと考えている

• ローカル変数の有効範囲は代入が行われたスコープ(メソッド本体、クラス定義本体など)全体。現状は代入が行われた地点から、スコープの末尾まで
• だから初出の代入がブロック内でも、前方宣言は不要
• ただし、ブロック内しか登場しない変数の扱いは、現状のままブロックローカル
• 「eval "foo"」のスコープ的な意味は「lambda{foo}.call」と同等。よってevalによって導入される新しい変数はevalの外に影響を与えない。
• ブロックローカル変数宣言が行われた場合は、明示的な宣言があるので有効範囲はブロック内のみ
• ブロックパラメータにローカル変数が登場した場合、その変数の扱いについてはまだ決めていない。ブロックローカルにするのも面白いし、他の変数と同様の扱いにするのも便利な局面はあるだろう。完全にローカルスコープにしたければ、無名関数式を使えばよいのだし。

他にも「多重代入の明確化」、「メソッドコンビネーション」、「セレクターネームスペース」などなどあるのだが、なかなか決めきれない。

_ [Ruby] The departure of the hyper-enthusiasts

『Thinking in Java』などの著者であるBruce Eckelによる「Javaに飛びついてた連中が今度はRailsのおかげでRubyに移行しているようだ。でも、Pythonに比べてRubyのどこがいいの？」という問いかけ。マジに質問したいのか、「Pythonのがいいじゃん」の婉曲な表現なのか区別はつかない。ただ、彼は前にもRubyに対して同じ問いかけをしているわけで、つまり要するに「Rubyは彼の趣味にはあわないぞ」ということだけなのかな。

で、私はPythonエキスパートではないので、彼の問いかけの対象ではないのだが、 私がPythonで嫌いな点は、実はインデントによるブロック構造ではなく(間接的に関係はしているのだが)、式と文が明確に区別されている点だ。

これのせいで、

• evalとexecを使い分けなくちゃいけない
• lambdaで一つの式しかかけない、ので本来不要な局所関数を導入しなくちゃいけない
• ifなどを式にできない、ので本来不要な一時変数を導入しなくちゃいけない

などなどの弊害がある。いや、これでなにかができなくなるわけじゃないし、 別にたいして困りはしないんだけど、なんかすっきりしないというか、 不要な思考を強制されるというか。

とかいうことを、ruby-talkに書こうとしたら、マシンがハングした。 呪われている。

_ [Ruby] tech addict - ruby gotchas and caveats

Rubyの落とし穴。

1. strings aren't auto converted into numbers or strings
2. false and nil are the only valid false values, anything else is true
3. && and || are the high priority AND/OR constructs, and and or are low priority versions
4. Exceptions and raise vs catch
5. no class/module unloading
6. no native unicode (ruby < 2.0)
7. private never truely private
8. 1/2 != 0.5 unless require 'mathn' (this is the default in many languages anyway, sometimes integer math is your friend). With mathn 1/2 becomes a different type (Rational) than 0.5 (Float)
9. class variables and their inheritance semantics
10. singleton class modification for the class objects isn't good or really allowed
11. assignment methods always return the assigned value, not the return value of the assignment function
12. local variable scoping is tricky and can hide other variables and methods (this is slated for a change in ruby 2.0)
13. You might think that class_eval would provide access to the class's context and variables, apparently not so much.

実例を見ないとわからないものもあるが、まあ、おおむね妥当であろう(ただし、6は誤解。1,2,3,4,7,8,11,12は慣れの問題。9,10,13はもうちょっと考えてみよう)。

追記

コメントにもあるように5も誤解。クラス名である定数が削除され、 サブクラスが存在せず、インスタンスがすべて回収されれば、 クラスやモジュールもGCの対象になる。 ライブラリ全体をunloadする機能はないが、ある言語の方が珍しいと思う。

9は1.9では解決されている(クラス変数は継承しない)。

10はsingleton methodはクラス変数の場所を変更しない(囲んでいるclass文だけで決まる) ことを理解すれば問題なし。慣れの問題。

13はあまり使いやすくない仕様なので、将来の1.9では変更しよう。 手元ではもう直した。

どう変更したかと言うと、以下の通り

• クラス変数の格納場所はもっとも内側のclass文またはmodule文が定義しているクラス(またはモジュール) [これは以前から]
• 特異メソッド定義は「格納場所」を変えない [以前から]
• 特異クラスも「格納場所」の対象になる [新規]
• よって特異クラス定義は「格納場所」を変更する [新規]
• トップレベルにはそれを囲むclass文もmodule文もないから、警告が出る [以前から]
• トップレベルでのクラス変数の「格納場所」はObject [以前から]

これもeigenclass化への一歩かもしれない。

_ [言語] Guido van Rossum on the Python 3000 process

Python 3000について、抽象的な話が多くて、 具体的な実装などについて語る人はあんまりいないという話。

Pythonくらい大所帯だといろいろ大変なんだろうなあ。 Rubyでは抽象的な話をしたがる人もあまりいないから。 まあ、それは私がすき勝手できるということでもあるのだけれど。

• Python 3000は2007年前半リリース希望
• UnicodeとStringの統一(Bytesの新設)
• IOの再実装
• keys, items, values()のイテレータ化戻り値の変更

また、Python 3000の先、Python 4000の話を始めてくれて結構、とのこと。 Python 3000が具体的になりそうになって、新たな「遠くの目標(aka 燃料)」が必要になった とも言えるかもしれない。

_ 呪われたThinkpad X31

ACアダプタの調子が悪い。

今、ふたつ持っているのだが、ふたつともコネクタ周辺の接触が 悪いようでケーブルの角度によって充電できなかったりする。

ので、ホテルから(末広町の)オフィスに向かう途中で 秋月によってThinkpad用ACアダプタを購入する。 もう買い替えが決まっているので、中古で(980円)。

そしたら、オフィスについたらこんどは画面が写らない。 どうもバックライトが切れたらしい。 フレキケーブルの接触不良か。 今朝ホテルで使っている時にはまったく異状の気配はなかったのだが。

しかたがないので、ディスプレイを借りて操作してるんだが、 結構使いにくい。

25日のリリース、危うし。

HDDといい、ACアダプタといい、バックライトといい 呪われているようだ。 購入後3年も経っているからというのもあるのだが、 それにしても集中するものだ。

やっぱ、買い替えの注文を察知してすねてるんだろうか。

馬鹿だなあ、君が一番に決まってるじゃないか(新しいのが来るまでは)