30歳になりました日記
僕は予算の消化が大嫌い。
相談した人が2桁多い額を消化していてびっくり。 あ、でも年度末に残ったお金と年間で消費したお金を比較するのはおかしいか。
とりあえず見積もり。 微妙に予算が残ってしまったら、例の付箋を買おう。 例の付箋ってなんだっけ。 「西尾 泰和 付箋 サイズ」で検索。
ST-MN3という3Mの付箋を買ってきました。決め手はサイズで、100mm×69mmと普通のメモ用付箋より微妙に狭く、長いものです。これ実はA4 用紙を8つ折りにしたスペース105mm×74mm(つまりA7)にちょうどはみ出さずに収まるサイズなので、A4の四つ折りサイズである超整理手帳の1 ページにちょうど2枚ぴったり貼ることができるわけなのです。そうなのです。 最初付箋に厚紙のカバーが付いているのは邪魔に感じたのですけど、 カバンに入れておいてもめくれてぐちゃぐちゃにならないし、 さっと取り出したい分はあらかじめ手帳に張っておけばいいだけ。 超整理手帳との相性は抜群。
ただし超整理手帳自体は全然使っていない(ぇー)
スケジュールの密度の問題だと思う。 いろいろなスケジュールの管理方法とかがあるけど、 管理すべきデータの量によって適切な管理の方法が変わるのは当たり前。 僕のケースでは付箋で十分。
ただ、済んだ作業の記録は残らずにどんどん廃棄されている。 それでいいような気もするけど。 あとから「あー、あれなんだっけー」となるような情報は取っておく方がいいんだろうなぁ。 でも、それを紙の形で取っておくと検索性が低いから、 必要な情報だけhowmに転記とかがいいのかもなぁ。
公開しても問題ない情報なら上のように日記に書いておいてGoogleで検索するし。
そして必要を感じて検索した情報はこうやって転載することで次の時により見つけやすくする。
= うはー！ 体年齢が30歳の誕生日を迎えました！orz
1ヶ月前は27と28を行き来するくらいだったのに、 数日前に29になり、今日はとうとう30歳に。
チョコパイがいけないんだ。
= Haskellしたくなるのを我慢。 Jython本の原稿を書かなきゃ。
= 普段、文字列を音として認識する習慣がないので、 原稿を読んでみると意外な所に時間が取られる。 Pythonの作者Guido van Rossumってどう発音するんだ。 「ぐいどー」と呼んでいる人が多いけど、 本人のページ( Guido's Personal Home Page )には「アメリカ人はイタリア風の発音で呼ぶことが多いけどね」と書いてあり、 Wiktionaryによればイタリア風の発音こそ「ぐぅぃーどー」だ。 Guido - Wiktionary。
発音は「Scottish "loch"」のchに似ている、って言われてもね。 IPAの発音記号で言うと「x」。もしかしてTeXのXか。
オランダ語 - WikipediaによるとGという文字の発音は[x]か[?](yみたいなの)で、 両方とも軟口蓋摩擦音。有声軟口蓋摩擦音 - Wikipedia。
もろもろの情報から考えると、やっぱりTeXのXの発音で、仮名表記するならハ行。
そしてつづく「ui」の発音は、発音記号で書くと[oey]。読めない…。 まぁ「アイ」のような「エイ」のような「オイ」のような音らしい。
まぁ、あえて仮名表記すれば「ホイド=ファン=ロスム」かなぁ。 名前のほとんどの字が「日本語や英語で表現しにくい発音」なので かなり無意味だけど。 「ヴァン」か「ファン」か、とか、「ロスム」か「ロシュム」か、 という議論はほぼ無意味。どちらも正確ではない。
と、こんなくだらないことを調べて時間を費やしてしまう。 そんなことより原稿を…。 うーん。
= 「言語融合の時代」 を整理して書き直し。 第三の時代は単なる言語融合の時代になった。 前回の文章で言語融合とセットにした「コンポーネント化の流れ」は 設計思想の変化なのだ。混ざっているとわかりにくいと思ったので削った。 プレゼンの時も削ったしね。
あえていうならば、 機械語の時代にジャンプと命令の羅列だったものが、 第一の時代にwhileやifなどの構造と関数になり、 第二の時代にクラスや継承になった、と。 でも継承は答えではないことに気がついた。 だからSWTは継承を禁止した。 だからDIが流行った。 DIコンテナって「XMLで記述された『部品をどう組み合わせるか』というコード」を読んで、 実行するインタプリタじゃん。 これも実は「複数の言語でプログラミングをする」の一礼じゃん。 ということなのだ。
Java風にいえばインターフェイスだが、 ようするにあるオブジェクトXがオブジェクトYと関係を持つときに、 オブジェクトYが「なんらかの条件」を満たしていることを保証してほしい、ということ。 ある種の契約なんだ。 これからはある種の言語でコンポーネントを作り、 別の種類の言語でコンポーネント同士の関係、契約、などなどを記述する形になるだろう。 そういう方向の進化を考えた場合、 現状のJavaも現状のPythonも多少力不足だと思う。 Javaでコンポーネントを作っても、 「XがYを呼び出す」なんて処理はJavaの中で完結してしまっていて、Pythonの側でフックしにくい。 もちろんできなくはないが。 そうではなくて、ちょこっと宣言を書くだけでその呼び出しの処理の前に何かの関数を挟んだり、 引数をそのまま渡さずに指定した関数を通して変化させてから渡したり、といった処理ができるような、 そんな言語が現れるだろうと思う。あと5～10年くらいで。 で、その言語がデファクトスタンダードになるまで10年かかって、 その頃には言語を問わないCPANのような物ができていて、 C#やJavaで書かれたコンポーネントがMaven的な方法で自動的にダウンロードできて、 あとはそのコンポーネントのつなぎ合わせを書くだけ。
= やばい、疲れが出てきたのに、 ローズマリーのアロマが強すぎて脳が止まらない。 クールダウンしないと。
= クールダウンした。 西尾泰和のブログ: HaskellによるKEMURIインタプリタ。
