JAOO2003のチケットの手配終了。最終的には向こうが払ってくれるとはいえ、結構な額を立て替えることになる。
もっと重要人物になれば自分で苦労しなくても向こうでチケット手配してくれるようになるんだろうか。 あまり期待できそうにないな。
もうそろそろアイデンティティの話はもういいかなって気持ちになってるんだけど、 乗りかかった船なんで最後にまとめておこう。
わたしが「アイデンティティがない」という時には以下のことを意味しています。
たとえばTclのような言語は、言語機能としてアイデンティティがありません。
知人のお嬢さんがバプテスマを受けることになった。 「普段お世話になっているから是非」と按手礼の列に参加することを依頼された。
そんなにお世話した覚えはないのに、良い印象をもってもらっているようでありがたい。 よろこんで引き受ける。 お嬢さんは息子と仲良しだしな。
バプテスマ会後は、松江ワードの活動ということでそうめん流し会を開く。
竹を割って作った樋に、そうめんを流す。同じく竹で作った器で食べるとよりおいしい気がする。 冷静に考えるとただのそうめんなのだが、みな飢えたように並ぶのがおかしい。 いや、私もその一員なのだが。
あー、おいしかった。自宅で食べるよりもはるかにおいしい気がする。
今日も新見へ。今回、子供たちの機嫌が良く、よく忍耐してくれているので助かる。
とうとう高等評議員を解任された。副監督になった4月以来、実質的な活動はしていなかったのだが、 それでも正式に解任されるってことは感慨無量だ...と感じると思ったら、そうでもなかった。 やっぱ、実質的に働いてないと感動しないよな。
後で花束を頂いたりしたのだが、かえって気恥ずかしい。
うちと妹家族、弟家族と弟が揃う。結構な人数である。 下の弟(24)は友人から「隣に座って赤ちゃんを抱いてたのは奥さん？」と尋ねられていた。 実はそれは末娘を抱っこしていた長女(12)であった。後ろから見たからわかんなかったらしい。 「それって二重に犯罪だし」とか答えてた。
そういえば上の弟は私の結婚式で「こいつ、今日結婚するんだよ」とか言われてた。 「...それは兄です」とこわばった顔で返答していた当時15歳の彼。 そんな彼のところにももうすぐ2番目の子供が生まれる。
朝から電話連絡。 日曜の深夜から月曜の早朝にかけて、どなたかが教会の建物に投石したのだそうだ。 ポストがひしゃげ、窓ガラスがいくつか割れ、建物が傷つけられた。
誰がなにを思っての行動かさっぱりわからないけれども、悲しいことだ。
NaClは、会社設立当初から 「自分のPCは自分で購入する」(機種選定どころかお金も自分で払う)という かなり大胆なルールを採用している。 ほとんどの人は環境も自分で選択し、インストールも自分でやる。 で、給与と一緒に少しずつ「機器購入手当て」が支払われていて、 それを機器購入にあてる。あるいは無利子の貸し付けも用意されている。
いろんな環境があって困らないかという説もあるが、 どうせうちのプロダクトが使われる環境は様々だし、 いっそ多様性があった方がありがたいことも多い。 「誰かがやってくれるから」という甘えも減るしね。
「自分のことは自分で責任をとる」という点で、 変わっているけど、まあ、ありがたい制度であると思っていたのだが、 どうやら世間が追いついてきたらしい。
次女の自転車が調子が悪くなったので、 小学生のころから乗っていて小さくなったこともあるので 新しい自転車を購入しにいく。
三件ほどはしごしていろいろ見てみるが、 なかなか気に入らない。 結局、次女は色とか形とかが気に入ったという比較的安い自転車に決定。 父親が、こちらの方がこんな機能が、これが便利だ、とか言っても 耳を貸さない。結構頑固かも。
[つぶやき] 大規模ってなんだろう - Don'tStopMusic (2007-08-27)
ひとくちに「大規模」と言ってもいろいろある、という話。
あと、付け加えるならば「金額が大きい、責任が重い」があるかな。
個人的な印象では「嵩」、「組織」については、 ツールや手法による支援と発想の転換で、 できるだけ小さくしていくしか生き延びる方法はないと思う。
たとえばRubyやRailsは、簡潔さと複雑さをフレームワークの下に隠してしまうことで 小規模な組織でも「ちゃんとした」Webアプリケーションの開発を可能にしている (と見なされているから流行ってる)。
あるいは、IDEやリファクタリングツールなどもそういう助けになってる のかもしれない。
私はこの種の大規模対応のことを「開発のスケーラビリティ」と呼んでいる。 そのゴールはできるだけ小さなコスト(ソフトウェア規模やチーム規模)で できるだけ大きな成果(顧客満足、価格)を産み出すことだ。
間違ってもソフトウェア規模やチーム規模そのものをゴールにしてはいけない。 「大規模なソフトウェアが作れました」とか 「大人数で技術レベルがバラバラのチームをマネジメントできました」 なんて自己満足でしかない。手段と目的を混同してはいけない*1
一方、「ユーザの数」で表現されるタイプのスケーラビリティもある。 アクセス数、アクセス密度、データ量などである。 私はこれらを「実行のスケーラビリティ」と呼んでいる。
これはこれで重要な問題だが、少なくとも開発のスケーラビリティとは 異なる技術が要求される。ApacheやFastCGI、Mongrelの使い方とか、 データベースの分割・複製、マルチコア活用。
どれをとってもエキサイティングな技術である。 これからもっと重要性が増す技術だと思う。
*1 手段のためなら目的を選ばない、まつもとに言われたくはないかもしれないが。
海外(特にアメリカか)では、 わりと一般的なビジネスツールであると聞く、 カンファレンスコールを使う機会があった。 参加者の大半はアメリカ在住。
ということで、次回があるなら、もうちょっと別のツールが使いたいなあ。 SkypeチャットとかIRCとか。文字ベースの方が私にはありがたいなあ。
国際電話経由で参加したのだが、 IP電話のおかげで安くすんだ(13分で40円)。 これだったら国内で携帯電話にかけるよりはるかに安いよ。
NHK地方局の短い番組でとりあげていただけるそうで、取材を受ける。 とはいえ、業界のネタを普通の人に分かるように表現するのは 困難を極めるので、取材の人も頭を抱えてる。
聞くところによると土曜日朝の５分のコーナーなのだそうだが、 取材だけでも何時間もかけている。 この後、撮影もあるんだが、それもきっと何時間もかかるんだろうなあ。
以前、未踏の件で「クローズアップ現代」に1分くらい登場しただけでも、 撮影に半日かかったものなあ。テレビはしんどいよ。
恥ずかしいし。
すいません、片棒担ぎです。
とはいえ、私にはSmalltalkを殺してもなんのメリットもない。 Smalltalk(や、Lisp。以下同じ)の優秀さを知るからこそ、 なぜSmalltalkが大衆に人気がないのかを考察することこそ 私が興味がある点だ。
大衆は強力なパワーに関心がないのか。 言語の人気はなにで決まるのか。
先日お話した青木淳さんも「苦節25年、もうあきらめてます」とおっしゃっていた。
くらいしか理由は思いつかないんだけど。 Squeakなどオープンソース処理系が登場してずいぶん経つし、 最初のものはあまり関係なさそうだ。
とはいえ、いずれにしても
Smalltalk はかつて例を見ないほどインストールベースが増え、話題にのぼり、人々が手に触れることが出来るように＊ようやく＊なりつつある昨今だというのに！ｗ
というのは、ずいぶん世間の認知とはズレている。 そのズレを解消するのが普及と再認識の第一歩かもしれない。
Perl, Python, Rubyの簡単な紹介。
一番面白かったのはここ。
しかし、RubyもSmalltalkのようにいずれは消える運命にある。だが、筆者もいまは「分かる」ようになり、楽しいと感じている。
「Smalltalkは消えたのか」とか、 「まあ、50年経てばRubyも消えるだろうけど」とか思うけど、 他人には言われたくはない。
なかなかツッコミどころのある表現だが、 しかし、実はこれは誤訳。
原文は
I was never able to really understand Smalltalk, mostly because of its very cryptic (to my mind) syntax. Ruby, however, is like Smalltalk for mere mortals. Now, I "get" it, and it is fun.
ああ、びっくりした。mere mortalsという表現が分からなかったんだね。
追記: 現在では注釈が付いて訂正されてるみたい。
今日が〆切であった。二本応募。 もっとも一本はなかむらくんにGCネタで出してもらうんだけど。
Rubyのバグレポートがきて、 手元で直してチェックインしようとすると もう誰かが直してたりする罠。
なんか出番が少なくなったなあ。
もうちょっと言語そのもののデザインに集中しろということだろうか。