先週の長女に引き続き、息子が熱を出して、喉が痛いという。 熱のある小学生をひとりで置いておくのはかわいそうだが、 今日は妻は教会で用事があって抜けられないという。
しかたがないので、神権会での私の担当はビショップに任せることにする。 一応準備したメモは送っておいたのだが、早朝から電話して その内容を説明する。申し訳ない。なんらかの形で埋め合わせができるとよいのだが。
留守番している間、息子と先週レンタルした『ジョセフ物語』を見ることにする。 モーセをテーマにした『プリンス・オブ・エジプト』と、 似たような絵、似たようなテーマ。 まあ、シリーズだと考えればいいよね(同じドリームワークスだし)。
最近、家族で旧約聖書を読んでいるので、具体的なイメージが湧くのは良い。 しかし、脚色してある映画よりも、聖書の方がドラマチックなのはどういうことかと。
あと、3千年前の人のメンタリティは、現在の文化を持つ我々からは理解しにくいことが、 よーくわかった。
飛行機チケットのバーゲン時期なのだそうで、妹が子供を連れて実家に帰っている。 ということで、妻、息子、末娘を置いて、娘二人連れて実家へ。
まあ、全員集合とは行かなかったのは残念だが、 たいへん楽しく、おいしい時間を過ごした。食べ物を用意してくれた人たち、ありがとう。
しかし、父、私、弟と三人とも、子供たちがはしゃぎまわる 騒がしい中で居眠りをしてしまうというのは、 「どこでも寝れる」遺伝子恐るべし。
今日も出張。東京へ。
情報処理月間のU-20プログラミングコンテストの表彰式。 例年、表彰式は失礼していたのだが、今年は審査委員長の石田先生が 急遽出張になったということで、審査員講評を行う人(の一人)として 呼ばれたのだった。
いやあ、元気のいい若い人を見るのは気持ちがいい。
大賞を取った高橋くんを取材するため、 テレビ岩手から取材が来ている。すげー、地元のヒーローだ。 ま、ローカルニュースで取り上げられるくらいのことはしてると思うけど。
で、私も取材された。「彼はどうですか?」
当然のようにほめちぎっておいた。 「世界に通じる人材になれますよ、きっと」とか。 ホントにそう思うしね。
その後、「日経コンピュータ」の取材。 「日経コンピュータ的立ち位置からのオープンソース」に関して。
(アメリカで)「ruby」という単語を含む求人情報数がどう推移しているか、というグラフ。 伸びてる、伸びてる。
「ruby」の部分を「java」「php」「python」とかに変えても なかなか面白い。
大新聞社のインタビューを受ける。なんか取材なんて滅多に受けないのに ある時には重なるものだ。
OSSについて正直なところを話す。 が、あまりにも普通なので記者の人はちょっと不満げに見えた。 もしかしてなにか期待していらっしゃったことに応えられなかったかしら。
元ミラクルの小田切さんが会社をはじめたという話。
昨日の日経コンピュータとの取材で、自分でOSSをハックするわけにはいかない 情報システム部は「OSSを使ってなんとかできる」人たちをつかまえる必要がある(ソフトウェアはどんどんコモディティ化するから)とかいう話をして、 それの受け皿となるOSSサポート企業というのはこれからニーズの高まる分野で ビジネスチャンスがあるのではないか、という話をしたのだが、 この「オープンソース・ソリューション・テクノロジ」はそれに対応するものになる、のかもしれない。
最近、Webで公開されたYuguiさんの記事「Rubyを仕事に使うべし!」に対して、それじゃ「使うべし」をちゃんと説明したことにならんだろう、という反応。
いや、まあ、その批判は当たっていないこともない。私自身は「Rubyを仕事に使うべし」とは必ずしも思ってなかったりするんだけど。
が、(たぶんワザとだと思うんだけど)この批判そのものが「なにができるか」ということを ベースに論が構成されている。が、正直な話、言語の比較で「なにができるか」を 比べるのは不毛なんだよね。だって、大抵のことは大抵の言語で「可能」なんだもの。
最初にはっきりさせておかなければならないのは、 仕事で使う言語(というかツール)を選択する時に、 「その言語になにができるか」という基準で選ばれることはマレである。
重要なのは、教科書があるかとか、プログラマが確保できるかとか、 必要なライブラリが入手できるかとか、IDEがあるかとか、 その言語を気に入ってる上司がいるかとか、 話題になっているかとか、そんなことであって、 ある言語がどのような機能をもっているかではない。
そういう意味では「Rubyを仕事に使うべし!」というタイトルの記事は、
とかいう話題を中心にした方が効果的だったと思う。
それはそれとして、「どこまで本当か」というエントリの方は 些細な文法の違いから来る記述力を無視しすぎだと思う。
Rubyなんかよりも、もっとずっと本格的なメタプログラミングのできるCLOSとかで書くべきでしょう。
とか
この程度のわずかなシンタックスシュガーで、それほど生産性に大きな違いがでるのでしょうか?
とはいえ、おそらく「計測できる生産性」での差は出ないだろうと思う。 しかし、「計測できない生産性」では大きな違いが出るのではないだろうか。 気分とか。
そして、(たぶん不幸なことに)ほとんどの場合生産性は計測不能なのだ。
ま、それもこれも仕事に使える言語を自分で選べて初めて言えることなのだが。
追記
このエントリについて、fromdusktildawnさんから批判されちゃいました。 「ありもしない錯誤をでっちあげて批判している」のだそうです。
そう指摘されてあらためて引用部を見返すと、確かに
RubyとCLOSでは、シンタックスの違いに起因する生産性の差なんて、少ししかないよ。
と読めるように引用してますね、私。これは私の落ち度です。 原文へのリンクが あるので前後はそちらで読んでいただけるだろうという甘えがありました。
引用の仕方がまずかったことについては謝罪します。
実際には、二つの引用部は独立して引用したつもりで、前者は
(書き込み系)メタプログラミングしたいならRubyよりもCLOSだよ
後者は
RubyとC#では、シンタックスの違いに起因する生産性の差なんて、少ししかないよ。
という主張が読み取れると言いたかったのでした。
で、その主張に対して
ということが言いたかったわけですね。要するに「Rubyは間口になれる」と。
間口をくぐった後は、Rubyにとどまるもよし、SchemeやCLOSに進むもよし、 あるいはHaskellのような関数型に進むもよし。 それはユーザの自由でしょう。
間口になるためにはCLOSやSmalltalkは本格的すぎ(多くのプログラマにとって日常とのギャップが大きすぎる)、PHPでは「上」とのつながりが薄すぎて「面白くない」。これがRubyが「ウケる」理由なんじゃないかと(Perlも確かに「上」とつながっているんだけど、そこはそれ。ねぇ)。「今そこにあること」という弾さんと同じような結論になっちゃいましたね。たぶん、PythonもRubyと似たようなポジションにあるのだと思います。
思い立って、とうとうブロックパラメータについて
という修正を実現した。ずいぶん悩んでいたわりには 実際に手を動かしたら30分で実現できるというのはどうよ。
他の悩んでいることについてもそうなのかなあ。
いずれ世代は交代する。企業でも家族でも。 それについてどれだけ備えることができるか。
時として、非常に長い(数十年とか数百年とか)スパンの視点に立つ必要があるのかもしれない。 ま、聖書とか見てると数百年が一行で過ぎたりして、新鮮な気持ちを味わうことがある。
Martin Fowlerのプレゼン。しかし、英語苦手な人の立場からいうと、 この即興トークは正直勘弁して欲しい。スライドがないんで視覚情報による補足が少なく、 聞き取るのが大変。たぶん、英語がよく分かる人なら、表情とか身振り手振りとか からノンバーバルな情報を引き出せるんだろうけど。
RailsConfではPaul (Graham)もこれをやったもんだから、泣いてた日本人続出という噂だったし。
とはいえ、私の良くやる「スライド駆動」が本当によいかというと、 これもなかなか難しい。正直、英語で満足できるプレゼンできたことはないのだが(日本語でもかなり怪しい)、スライド駆動を活用することでなんとか「最低レベル」は維持できるようになってきた。もうちょっと上を目指したいものだが。
昨日に引き続き、オープンソースソフトウェアとビジネス(情報システム部門)を どうつなげるかという話題になると思う。
サービスの詳細は書いていないけれども、
MySQL 開発者から直接、MySQL の使用方法や設定方法、パフォーマンスチューニングなどのサポートを受けられる。ただし、英語でのサービスとなる。
また、サービス購入者には、認定ソフトウェアを非 GPL ライセンスで、最適化された MySQL バイナリで提供する。
さらに、ユーザーに対して、このサービスの使用方法の講習を無料で実施する。
価格は、年間1サーバーで7万4,970円から。
は顧客からどう受け入れられるだろう。将来、もしRubyのユーザ層がMySQlなみに厚くなったとして(獲らぬ狸)、同様のサービスを提供するならばその適正なサービス内容と価格はいくらくらいになるだろう?
あまり、Seasarの周辺の動きに詳しくないんだけど、 Seasarって海外ではどう受け止められているんだろう。Java界には疎いからなあ。
Rubyと違い、お金の臭いのする分野で広く受け入れられるのは大変なことだと思う。 陰ながら応援している。
世の中はどんどん複雑になっており、 それに対応するためには動的言語が良いという話。
もしかしたら、シンプルかつ柔軟性のある計算モデルが必要とされているのかもしれない。 現在よく見かける計算モデルは
とすると
Obie FernandezによるJAOOレポート。 「What Makes Ruby Roll?」というセッションが開かれたのだそうだ。行きたかったかも。
それは、それとして(我らがDave "Pragmatic" Thomasではない方の)Dave Thomasがホストする 「How will we be programming in 2016?」というパネルでの質問。
これに対するパネリストの答えは以下の通り。
まず、Kevlin Henney。
Someone will have rewritten it by then. Yes, will succeed where Smalltalk failed because it's not bound up in the smalltalk environment (you can open up Ruby files in Notepad). Also, do not underestimate how important a 'normal' if statement is. The biggest problem with Smalltalk is Smalltalkers.
誰かが(実装を?)書きなおしてるだろう。Smalltalkのように「失敗」しないだろう。Smalltalkの最大の問題はそのユーザである。
次に、Erik Meijer。
Hopefully they'll get closures right and hopefully they'll discover type inference.
クロージャをまともにしてて欲しいなあ。あと、型推論を取り込んでるといい。
Dave Thomas。
As long as the people who have big checks are running on the CLR and JVM Ruby will have to crossover to those platforms to succeed. Business and economics were the downfall of Smalltalk, not natural selection. The "arrogance of the smalltalk communities sealed the lid".
Rubyが成功するためにはCLRやJVMとうまくやらなくちゃ。お金のある連中はそこにいるから。Smalltalkの場合、ビジネスと経済が足を引っ張った。Smalltalkコミュニティの傲慢さが蓋を閉じた(成功できない理由だった)のだから。
Steve Vinoski。
A new vm is needed (for performance reasons). I don't think Ruby will look like Java in 10 years, because that's the point. I do think that type inference will make it's way in.
新しいVMが必要(性能上の理由)。その理由でRubyはJavaのようにはならないと思う。型推論が道を開くかも。
なるほどねえ。さて10年後のRubyはどうなるか、か。 10年後、私が生きてるかどうかで全然違う気もするけど。
もうちょっと考えてみたい気がする。言語そのものはあんまり変わってないような気もするけど、周辺技術やライブラリまで含めると意外な変化があるかも。
Groovyのitのようなものをmethod_missingを使って実装する。つまり
people.select { |x| x.name.length > 10 }
のようなのを
people.select(&its.name.length > 10)
と書けるように。いや、すげーよ、それ。
_ mame [Code Golf では end なんて書きませんw]
_ のんべ [ためしに1つ書いてみましたが,とても足元にも及びませんでした... でも面白いですね,これ.]
_ shinh [はじめまして。 Perl は変数プレフィクスの $ が制限になってそうな気がします。書いてみていないので想像ですが。..]
_ nh [the point とは、"Ruby does not look like Java" ですから、訳としては「10年..]
_ nh [「10年後のRubyはJavaのようにはなってないと思う。だって、JavaじゃないのがRubyなんだから」くらいかと..]
_ まつもと [なるほど、そう読むんですね。> nhさん]
_ 通りすがり ["sealed the lid"は「止めを刺した」的なニュアンスだと思います。]
_ すずきひろのぶ [むかしSmalltalkを使っていたから実感があるけど、Smalltalkがうまくいかなかったのは、初期はハードウェ..]
_ まつもと [Smalltalkの経緯などについては分かりませんが(sumimさんを召喚しちゃうかな)、Pythonと比較した組織..]
「オープンソースマガジン休刊」との情報を受ける。なんと。
雑誌は冬の時代なんだろうか。 オープンソースマガジンは売り上げはちゃんと回ってたと聞いてたけどな。 「上の方針」という奴なんだろうか。
まあ、Webでどんどん情報が入ってきちゃうしねえ。 とはいえ、紙の情報はいろんな意味で価値があるんだけど、 自腹ではあまり雑誌を買うことがなくなった私は、 そういう「文化」を保存するだけのコストを負担していないわけだから、 文句を言う権利はないのかな。
ともあれ、連載がひとつ終ってしまうというのは厳然たる事実だ。 〆切が減るのは嬉しいが、仕事が減って、収入が下がるのは嬉しくない。 書き下ろしとかなかなか書けない私にとって、雑誌は
で、ちょうど良かったんだけどな。
Linux Magazineといい、オープンソースマガジンといい、 私の連載を載せてくれるような雑誌は「大衆ウケ」は悪いのかもしれない。
「ハッカーズライフ」のようなスタイルで(そうでなくてもいいけど)、 私の連載を載せたいという雑誌編集者の方はいらっしゃいませんか。
7月頃から約束を取っては、忘れてすっぽかしたり、うっかり朝食を食べてしまったりして 受けられていなかった健康診断をやっと受ける。
視力検査、聴力検査、身長・体重計測、心電図、血液検査、胸部および胃X線。 これだけで疲れちゃうよ。
バリウムは飲みにくいという人もいるようだけど、 私はそれは苦痛ではない。でも、下から出ていく方は、ちょっと、ねえ。
米子で総大会の衛星中継を見る予定だったのだが、 妻の体調がさほど良くないということで、 どうにもほっておけなくて、松江から米子への配車だけ手配して 自宅に戻る。
残念だけど、インターネットで見ればいいや。 なかなか時間とってビデオを見るのは難しいし、 文章では伝わらないものがあるんで、見たかったんだけどな。
子守りをしたりして過ごす。 あと、大会の一部はインターネットで見たが、 途中でうとうとしてしまったりして、ちゃんと見れた時間は短かった。
Rubyの仕様をまとめるWiki。貴重な情報の集積所になるかもしれない。
JRubyのチームの人たちが中心になっているようだ。 彼らにしてみたら安定したRubyの仕様が存在するかどうかというのは まさに死活問題だものな。
「オブジェクト指向は死んだ」という扇情的なタイトルのエントリ。
なぜかというと、「副作用から離れられないから」だそうだ。 確かにオブジェクトの多くは状態を持ち、 状態を操作することで発生する副作用はプログラムの再現性を下げ、 発見しにくい問題の原因となることがある。
「それに比べて参照透過性のある関数型言語では...」などと、 半端に関数型言語をかじった人がよく言いそうなネタだが、 実際には関数型言語でさえ副作用から自由ではない。
オブジェクト指向が全然シンプルでないのは認めるが、 それはオブジェクト指向のせいではなく、 現実がシンプルでないからではないだろうか。
とはいえ、分野を限定すれば、 もうちょっと分かりやすい計算モデルがありそうなものだが。
そういえば、以前akrさんが汎用言語において SQLの扱うテーブルのようなデータ構造について考えていたな。
今日は家族全員を連れて米子へ。総大会ビデオ鑑賞。
どうせしばらくしたらDVDやら記事にまとめたものやらが入手できるから と思ってメモを取ることもしなかったんだけど、 やっぱり取った方がよかったから。取ってた方が集中力が維持できる、かも。
ベドナー長老の「あなたは周囲の状況に対する反応を選ぶことができる」という言葉が 印象的だった。トラブルに遭遇しても、2ちゃんねるで悪口を言われても、 怒るのか、改善点だけ引き出して冷静に対応するのか、 不親切に親切で返すのか、それを自分で選ぶことができる。 当たり前のことだが、なかなか自覚的にはできない。
最近は少しマシになった(と思いたい)けど、 もともとは瞬間湯沸かし器のように怒りっぽい人だものな、私は。
言わんでもいい厳しい言葉を吐いて後悔したこともたびたび...。
もっとマシな対応を選ぼう、意識して良い対応を選ぼう。
お姉ちゃんたちは試験やら、教会の若い女性の活動やらの準備があるということで、 うちにいたいとのこと。長男と末娘を連れて松江フォーゲルパークへ。
息子は最近遠足でここに来たそうなのだが、ぜひもう一度来たいとのこと。 同じことを何度も繰り返すのが好きだよね、この子は。 新しいものばかり追いかけているのよりは、良いことなのかもしれない。
結構広くてくたびれたけど、楽しかった。 フクロウのショーとかも見れたしね。
決まったらしい。笹田くんは最終日の午前中か、 聞けないかもしれないなあ。
Friday, October 20
8:30 Continental breakfast
9:15 Welcome
10:00-12:00 Session 1
Masayoshi Takahashi The History of Ruby
Evan Phoenix Sydney and Rubinius: Hardcore Ruby
12:00 Lunch
13:30-16:30 Session 2
Geoffrey Grosenbach Dynamic Graphics With Ruby
Kevin Clark Life After mkmf
Zed Shaw Iron Mongrel: Fuzzing, Auditing, Thrashing,
Risk and The Ways Of Mongrel Destruction
John Long Radiant -- Content Managment Simplified
dinner (on your own)
Yukihiro "matz" Matsumoto Roundtable
Saturday, October 21
8:30 Continental breakfast
9:00-11:30 Session 3
Nathaniel Talbott Open Classes, Open Companies
Laurent Sansonetti Leveraging Mac OS X from Ruby
Glenn Vanderburg Rinda and DRb in the Real World
12:00 Lunch
13:30-17:00 Session 4
Josh Susser More than enough rope to hang yourself
Rich Kilmer Web 2.0 Beyond the Browser
Tim Bray I18n, M17n, Unicode, and all that
Michael Granger Speak My Language: Natural Language
Processing in Ruby
18:00 Conference Dinner, sponsored by ThoughtWorks
after dinner Keynote address: Yukihiro "matz" Matsumoto
Sunday, October 22
8:30 Continental breakfast
9:00 Session 5
Justin Gehtland Streamlined: A Framework for
Data-centric Web Applications
Koichi SASADA YARV: on Rails?
John Lam You got your Ruby in my CLR!
12:00 Lunch
1:30-3:30 Google Summer of Code Student Talks
今月は新しい総理大臣のキャッチフレーズにちなんで「美しいコード」というテーマで。
コードの美しさというのは、なかなか難しいが、 (私は)どのようなコードを美しいと感じるかというような話。
次回、最終回。なんのテーマにしようかな。
今年の「日本OSS貢献者賞」の受賞者が決定。
今年は
の4名。おめでとうございます。
今年は「海外でも使われているプロジェクト」がテーマだったのかな。 吉藤さん以外は面識がある。っていうか、平林さんはついこないだ U-20の表彰式で隣の席だった。
String#charsメソッドでマルチバイト(UTF-8)対応文字列オブジェクトを返すという拡張。 私がM17Nをぐずぐずしている間に、ユーザレベルでどんどん話が進んでいる。 そのうち、どっちかっていうと私の方が取り残されちゃったりして。
とはいえ、String#charsはlinesからの類推で「文字に分轄した配列(厳密にはEnumerator)を返すメソッド」になる予定なので、違う名前にして欲しかったなあ。
佐渡さんによる佐渡さんのための私的な「OSS貢献者佐渡特別賞」。
受賞者は
まあ、さもありなん。IPAの貢献者賞では評価されにくい人を選んでいるのがにくい。
あと、
Matz氏の受賞については審査基準にある1)OSSプロジェクトの規模、普及度、2)プロジェクトでの役割と責任の大きさ、3)個人でのOSS普及への貢献度、4)個人でのOSSコミュニティへの貢献度の4項目に対し、日本人では文句なしの影響があるだろう。...
(ちなみにMatzだけが全ての審査項目をクリアするということが、日本のOSSへの最大の貢献者を意味するわけでも、日本人にはOSSへの貢献者がいないということを私が主張しているわけではない。Matz氏はRuby という大きなプロジェクトのトップで君臨し、Linuxのバザールに近いモデルを体現した人物であり、それでいてLinusなどとは違ってオープンソースという言葉、文化の普及にも熱心な希有な人物であることで偶然に貢献者賞の基準に全て該当するだけのことである。ハッカーであり、プロジェクト管理者であり、エバンジェリスト的でもあるような人物は世界にもほとんど存在しない。一昔前だとSambaのJeremy Allison、今だとASF会長、GoogleのGreg Steinあたりのごくわずかな人間ぐらいだろうか? Linus, RMS, ESR, Perens, Tiemannあたりはちょいと違う。)
という評価は、内心とても嬉しかった。ありがとう。
プログラマの経歴もある詩人が亡くなったが、 パスワードを残さなかったため遺族が情報を入手できなかった、という話。
人はいつか死ぬのだから、その時に備えておく必要があるのかもしれない。 とはいえ、私の家族は私の(プログラミング関係の)個人的なデータのほとんどに 興味はなさそうだし、現状ではあんまり問題はないのかな。
偶然にも上記と似通った話題。トラックナンバー(ここでは「バス問題」になってる)の話。
私が死んだらRubyはどうなるかというネタは以前にも書いたような気がするけど、 まあ、1.8はもう安定版だから基本的に今まで通り。 今後変更があるとしてもバグ修正とライブラリの追加程度だろう。
1.9は現状に(なんらかの形で)M17Nを入れて、YARVをマージしたら それなりに使い物になるのではないだろうか。 まだまだ入れたいものはたくさんあるけどなくても生きていける(いや、死んでるんだけど)。
YARVについては笹田くんに一任。言語仕様は...だれか後継者を育てておかないとなあ。
誰か立候補する? できれば日常のコミュニケーションが楽な日本語を話す人がいいんだけど。
人間にとってマルチタスクを行うことは効率が悪い、という話。
っていうか、人間の意識はシングルタスクなので(無意識下は並行実行らしい) コンテキストスイッチのコストが高い上に、 簡単にマルチコアにできる方法が発見されていない以上、 効率が下がるのはほぼ自明なのでは。実験で確認したという事実が重要なのかな。
もっとも、人間はわりと簡単に入手できるリソースなので、 たくさん持ってくれば効率良くマルチタスクできる...と言いたいところなのだが、 「遅れているプロジェクトに人員をつぎ込むとさらに遅れる」というルールがある通り、 マルチコアにしても問題はつきまとうのである。
これはCPUでも言えることだ。マルチコアにしても早くならない問題の方が多い。 今後のプログラミングに対する課題は、どうやってマルチコアを有効活用するかだろうな。 たぶん、人間の思考のように表層ではシングルタスク、下層ではパラレルというのが 良いのだろう。データのベクトル化とか、その辺かな。
もしかすると将来、APLのような行列指向言語が復権するかもしれない。
_ たかはし [クアッドコア、8コアも目前です。性能を稼ぐにはできるだけ大きな単位で並列化しないとあかんです。スレッドぐらいの粒度で..]
_ まつもと [最近は性能のための並列性はプロセスでいいじゃん、という気になってます。 スレッド以下はプログラミングが簡単になる(こ..]
_ たかはし [ちなみに人間CPUの方も、マルチタスクするとスループットは落ちますが、応答性はあがります。人間の仕事もスループットだ..]
_ K.Tsuchiya [負荷かけすぎるとダウンしますしね]
_ MMX [昔の超並列マシンとかトランスピュータとか再発掘になるのでしょうか? データフローマシンは無さそうです、2D言語はフロ..]
_ 凡人 [Haskellの様に、遅延評価を行って、変数の代入を禁止すると、参照透明性を保つことが出来、処理の並列化が簡単に計れ..]
_ Ken [私はADHDなので疑似マルチタスクです。]
テーマは「MVC」。MVCの説明はなかなか面倒なのだが、 簡単なテキストベースのプログラムを使うことで 比較的小さな分量での解説を試みる。
さらにRailsが採用しているMVCと古典的なMVCの違いについても言及する。 っていうか、これらって実は同じ名前でも違うものだよね。 ちゃんとそういうことを書いてくれた文章を読んだ事ないんだけど、 それは「知られざる事実」なのかなあ。それとも「常識」?
なお、今回の記事で解説するMVCは古典的なもので Pluggable MVCとか、ましてやmorphicなどはカバーしていない。
Haskellで知られている構文解析技術Parsecを Javaに移植したJParsecを さらにRubyに移植したもの。
結構面白い。実際の使い心地とか性能とかはどうなのかなあ。
日曜日に欲しいということだったが、終りきらなかった。 月曜日にようやく完成してメールで送る。 また遅れて申し訳ない。
まだまだ仕事が残ってるんだよなあ。
なんか、もうプログラマじゃないよな。ジョブチェンジしたようだ。
オープンソースコミュニティに時々出現する「困った人」への対処法。
心当たりがあることがたくさんある。
オープンソースプロジェクト運営者は必読のドキュメントだと思う。刮目。
RubyConfに向けて移動。 出雲空港から羽田空港に移動。
で、途中で忘れ物に気付いたので、 京急蒲田で降りて買い物と昼食。
あと、百円ショップでよって面白いものをいくつか。 ホントは扇子とかも買いたかったのだが、 そういうものは売ってなかった。
小さなホワイトボードとマーカー。 ちょうどデジカメにサイズがぴったりな携帯電話入れ。 歯間ブラシ、などなど。
その後、電車で成田空港へ移動。 かなり時間がかかる。 いつも思うのだが、国内空港と国際空港が2時間離れてるっていうのはどうよ。
が、災い転じて福となす。電車の中で以下の事柄についてメモをまとめる。
けっこう生産性が高かったような気がする。
2時間近くまとまった時間が(メール読みとかの中断なしで)とれるのは 実は珍しいことなのかもしれない。
成田からサンフランシスコへ。機材はB777。 UAの機内映画はオンデマンドじゃないのね。 観たのは「Scary Movie」と「Scanner Darkly」。
前者は下らなくておかしかったけど「Saw」も「Village」も観てないので 分からないところがいっぱいだった。まあ、見た映画のパロディ部分は 字幕がなくても分かるよね。まあ、考える映画じゃない。
後者は英語音声+中国語字幕という組み合わせで、 話そのものが難しい事もあってぜんぜん分からなかった。 ここまで分からないのも珍しい。 今度ビデオで見直そう。
サンフランシスコからソルトレークシティーへ。
ところで、いつも気になるんだが、 アメリカの空港のバゲッジクレーム(荷物引き取り)は、 どうして乗客でなくても誰でも入れるところで、 係員による認証もなしで行われるんだろうか。
ヨーロッパでは日本風に乗客しか入れないところだったように思うし(認証はなかった)、 中国やマレーシアでもそうだったように思うんだが。
空港でピックアップしてもらって、ソルトレークをあちこち連れ歩いてもらう。 写真をたくさん。今回に備えてCasioのZ600を新規購入したのだが、
となかなかよろしい。テンプルスクエア周辺とかだけで100枚以上撮ったような。
典型的観光客、かな。
12時頃、ホテルへお迎えがきて、昼食へ。
Happy Sumoという日本食レストランであった。 寿司とかがあったのだが、相当アメリカナイズされていて、 とんでもなく面白かった。私が頼んだものは 牛肉のマリネとカニカマの巻き寿司に衣を付けて天ぷらにしたものであった。 さらにその上にマヨネーズ!
どきどきしながら食べてみたのだが、おいしかった。意外だ。
お昼を食べてから、BYUのキャンパスツアーであちこち見学させてもらい、 その後、Colloquiumへ。
200人以上入る大教室がいっぱいになっていた。 後で聞いたら240人くらいいたそうだ。半分は学外のひとらしいとも聞いた。
で、司会が講義をスタートさせるのだが、 まず祈りから始まったのに驚いた。BYUでは別に珍しいことではないとか。
テーマは「the Power of Ruby」。 以前の英語の話いくつかを切り貼りして作ったものであったが、 今までの英語のプレゼンテーションの中では一番スムーズに進んだのでは ないだろうか。まあ、一度話したことのある内容が多くて 余裕があったというのもあるだろうけど。
スライドはこちら。
その後、地元のRuby Users Groupの人たちと話をした。 これまたわりと真剣にRubyのことを考えてくれているようで 鋭い質問が続出して、ちょっとびっくりした。 こういうのって、お義理で参加して質問があまり活発に出ないことが多いのに。
追記
この講演のオーディオがIT conversationsから、 ビデオがBYUから入手可能になっている。
しかし、あらためて自分の講演を聞くと、英語は下手くそだし、発音もめちゃめちゃだし、 しゃべりはスムーズじゃないし、テンポは悪いし。 最初の5分も聞いていられなかった。みんな良く耐えてくれたなあ。
「二十代は模索の時ブログ」では、「上手い」とか「必聴」とか「中国人の英語に近い響き(たぶん誉めてる)」とか 書いてもらってる。嬉しいけど、事実とは反する気がする。
第一特集がプログラミング言語について、ということで、 「多言語を学ぶ価値」と「コードリーディングについて」。 ただ、ここから忙しいのに本当に書けるんだろうか。
ホテルでスライドを準備したり原稿を書いたりしながら テレビを付けているわけだが、さすが通販の国。 面白そうな商品をたくさん紹介している。
でも、支払いはカードでいいとして、日本には届けてくれないだろうな。 もう少し滞在が長ければホテルに届けてもらえるんだろうか。
普段は海外に行っても観光する時間などほとんど取れない。 だいたいはカンファレンスへの出席なので、 日程期間びっちりカンファレンスに出席するのが通例だ。 例外はフランスに行ったときかな。 あの時は、3時間だけフリー時間があったので、 ルーブルを駆け足で回ったのだった。 なんだか忙しい芸術鑑賞であった。
ところが今回はまる一日オープンな日があったので 観光に時間が使えた。しかも、ガイドつき。 Keven Tew(Cardinalの人)とPat Eyler(Utah RUGなどの人)が案内してくれるのだそうだ。
おかげで
など見て回った。堪能。山ほど写真も撮った。 今回のために購入したCASIO EX-Z600は驚くほどバッテリーが持つ。 200枚取っても、バッテリー目盛りがひとつも減らない。
お昼にはPat Eylerの同僚たちとミーティング。 RubyConfのラウンドアップみたいになった。 しかし、教会の職員とこんな形でRubyについて話し合うことになるとは思わなかった。 Javaとの比較とか、Continuationについてとか、結構技術的に突っ込んだ話も多かった。
SLC空港からデンバーへ。 デンバー空港からホテルまではシャトル。$19。高い。
実際に書いているのがずいぶん遅くなった*1せいもあって、 時期を外してしまったし、 関心のある人は他の参加者のレポートで読んでしまっているだろうから、 簡単に。
Rich KilmerとChad Fowlerからご挨拶。
高橋会長による「Rubyの歴史」。
ネーティブスレッド対応をはじめ、 互換性をあまり気にしない改造RubyインタプリタSydneyを開発していたEvan(結婚で名字が変わったそうだ。Phoenixとはかっこいい)によるSydneyの総括と、新たなチャレンジであるRubiniusの紹介。
日々、「老人力」の強化が進んでいる身としては、 このパワーはうらやましい。
ただ、Ruby(インタプリタの実装)には、 「始めるのは簡単だが完成度を高めるほど継続するのは至難の業」という傾向があるので(言語仕様の完全実装が難しすぎ。ちゃんとした仕様がないことを除いても)、 今後もこの開発が継続するか、どこまで完成度が高められるかに注目したい。
RubiniusやCardinal(Ruby on Parrot)やJRuby(Ruby on JVM)、RubyCLR(Ruby on .NET)が 頑張ってくれるのはうれしいし、 速度や安定性でこれらのうちのどれかが勝つようなことがあれば、 そちらが主要な実装となるのもやぶさかではない。 私のがリファレンスインプリメンテーションとして残るなら。
という風にあまり実装にプライドを持たないでいられるのは、 要は「自分が言語設計者だ」という自己認識を持っているからなんだろうな。 本音を言えば、ちょっと悔しいのだけど、言語実装者としてあまり優秀でないのは 日々実感しているから、今さら大騒ぎするほどではない。
集中力が切れて話を聞いてなかった。ごめん。
Rubyのビルドに使われてるmkmfは複雑杉。 mkrfでRakefileを作ってrake動かすのがいいんじゃない? という話。
まあ、mkmfが過去のいろんなしがらみ(というか、段階的な開発)により 複雑化してるのは認めるけど、Rakefileというのはねえ。 RubyをコンパイルするのにRubyが必要というシチュエーションは 場合によっては問題にならないか?
まあ、実はYARVにも同じ問題があるんだけど。ただし、こちらはプラットフォームに依存しないのでコンパイル環境ではなく開発環境にRubyがあればいい。
高速HTTPサーバMongrelの開発者、Zed Shawのプレゼン。 しかし、予想に反してMongrelの話はほとんどなし
www.ruby-lang.orgに使われている (というか、そのために開発された)Radiantについて。
実はwww.netlab.jpでも使われている。
例年恒例の質疑応答タイム。
去年は「->」のこととかで盛り上がったのだが、 今年はあんまりわくわくするような質問は無かった。 まあ、新しい人が大量に流入してるので 雰囲気も毎年変わるよな。
あと、英語がわからない場面が多くて、 申し訳なし。
*1 実際に書いているのは11/09
海外にいる間は、私の時間を世間の時間に同期してくれる「家族」という存在が無いため、 寝る時間や起きる時間が狂いまくる。おまけに時差の関係でSkypeする時間が 早朝とかになるためますます狂う。なんか平均2,3時間しか寝てないような気がする。
test/unitのNathaniel Talbottによるプレゼン。 だが、寝坊して聞きそこねた。
聞くところによると、Rubyとは直接関係なくて Rubyの原則(Open Classとか)をビジネスに適用したらどうなるか(なったか) とかいうような話だった、らしい。
AppleのRuby担当者(現時点では「唯一の」らしい)である Laurent SansonettiによるOS Xプレゼン。
っていうか、会場のMac率は異常に高い。 RubyConfやOSCONではMac率は例年高いのだが、 今年はさらに高くなっているような気がする。 プレゼンする人もほとんどMacBookやPowerBookだし。 例外は数人(高橋さん、Evan、私、あともうひとりふたり)くらいじゃないか。
で、RubyからAppleScriptやCocoaを使って iTunesとかをいろいろ操作するデモが受けていた。
こういうのを見てると「RubyでOS Xで(or のために)作られたんじゃないだろうか」 と感じてしまう。実際には私自身はMacユーザだったことはないんだけど。 でも、自宅に一台くらいMacBookがあってもいいかなあ。
安いし(「10万円超は安くないです」と奥さんの声が聞こえるような気がする)。
この後、Laurentとは少し話して、興味深い話が聞けた。
なるほどぉ。
Glenn VanderburgがRindaについて熱く語る。
ここには咳さんがいるべきだったと思う。よろしく伝えてくれとのこと。
よろしく(伝わったかな)。
ここでアトリウムにメールを取りに行ったので、詳細はわからない。 けど、Rindaのことえらい誉めてたよ。
Josh Susserによる「More than enough rope to hang yourself」の予定だったが 彼が来れなくなったため、急遽、ライトニングトークに。 しかし、昨日の朝に募集して9件だったか10件だったかが あっという間に集まるというのもなかなか素敵。
しかし、昼飯時からメールの読み書きと原稿書きに追われていたのでほとんど聞けず。
Rich Kilmerが彼のFlashを使った新サービスについて。
これが本当にWeb 2.0かどうかは私にはよくわからなかったが、 Flashを使ったこれは見ていて美しい。
しかし、彼はこういう見映えがいいものが好きだねえ。
Tim BrayによるUnicodeの話。
Rubyだめじゃん、というような話かと思ってどきどきしてたのだが、 Unicodeの良いところも悪いところもちゃんとわかっていて、 それをどう取り扱うかというような話であった。
途中「大文字小文字は言語や文化と独立に定義できないからやっちゃ駄目」という発言があって、会場にどよめきが走った。プレゼン後の質疑応答でもそればっかり。
なんでも、たとえばトルコ語では「iの(一対一対応する)大文字」というものは 存在しないのだそうだ。で、どうするかというとロケールを見て、 テーブルをひいて、やたら重たい処理をしなくてはいけない、と。
でも、case insensitiveな処理とかは実際にあるわけで、 それらはどうするのかと聞いたら、
のいずれかだそうだ。他にも正規化などについて尋ねたのだけど、 「万能の解なし」ということで、ケースバイケースで最適なものを選ぶ必要がある という常識的な解答であった。
納得できたので、Stringクラスの大文字小文字を扱うメソッドのRDocに 「ASCIIの範囲だけ有効です」というただし書きを加えた。
ここでの「My Language」は英語のこと。 UnicodeやM17Nの話の直後に英語オンリーの話をもってくるのは なにかの挑戦かと思ってしまいがちだが、 別に狙ったわけではあるまい。
英文を解析してくれるライブラリ。 「Time flies like an arrow」のような曖昧文でも 複数の候補とその重みという形で教えてくれる。
ま、英語処理するときには便利かも。
明日は安息日で買い物したくないので、今日のうちにおみやげを手配。
ホテルの売店でぬいぐるみ。 近所のスーパーでルートビアエクストラクトを探すが「ない」とのこと。 隣のドラッグストアでハロウィーン用キャンディー詰め合わせ。 さらに少し行った子供服の店で末娘用のドレスを。半額セールだった。ラッキー。
デンバーは乾燥している。 唇が切れてしまったので、日本では使ったことのないリップスティックを購入。 あと、カカトもかさかさになってしまった。
CRuby(私)、YARV(笹田くん)、JRuby(Charles Nutter)、Cardinal(Kevin Tew)、 Rubinius(Evan Phoenix)、その他大勢が集まってミーティング。 なかなか興味深い話ではあったが、デザインの先端、というよりは 1.8の仕様をいかに明確化するか、とか、 1.8でCRuby以外で実装が難しいところをいかに実装依存として分離するか、とかの 話が中心。
Pat Eylerが最後に半年に一回、こうやってミーティングしよう、と wrap upしていたが、我々日本組はどうしたらいいのさ、と思ったのは内緒。 たとえ交通費を手配してもらっても、私は辛いぞ、年に二回の訪米は。
あ、笹田くんに行ってもらえばいいのか。
デザインゲームの話。 Bikeshed(自転車小屋)とは誰もが簡単に口をはさめるため、 いつまで経っても終わらない議題のこと。 が、デザインそのものは面白いネタなので、 いっそ言語デザインそのものを議論することを加速しようというような話。
後で森脇さんに指摘されたが、 もしかすると聴衆は別のタイプの話が聞きたかったのかもしれない。
まあ、いーじゃん、そういう自虐ネタしか話せないんだからさ。
今回はビデオ出力に問題は無かったが スクリプト(台本)用PCが壊れてしまった。やはり呪われている。 台本用PCはBYUの時からディスクが異音を立てていたので不安だったのだが、 案の定だ。 急遽RichのMacBookを借りたのだが、 どうにも見にくくて、大変だった。やはり台本重要。
RubyConfに参加している末日聖徒4人がホテルの一室に集まって聖餐。 これははじめての経験だ。 お互いに証を述べあう。私にとっては英語なのが辛かったが(聞く方はあまり問題なし)、 大変貴重な経験だった。
最終日。個人的にはキーノートも終わってだいぶテンションが落ちている。 それに原稿(日経ソフトウェア)の〆切も気になるし。
なんか、Railsのビュー部分を自動生成するとかいう話だったらしい。 出席できず。
なんか見たようなスライドの使いまわしもある。 AkihabaraとかOtakuとか話してるが、あまり通じてないなあ。 こちらでは「おたく」と「Rubyユーザ」では層がかなり違うみたい。 ウケないので次回からは考え直した方がよさそうだ。
後、台本も用意しよう。いや、してたみたいだけど、 「その場で読める」台本を用意したほうがいいと思うよ。
このプレゼンの主眼は
というところだったと思うのだが(前日ぎりぎりまでデバッグしてたし)、 なんかネタの提示のタイミングの問題で、前者は「ふーん」という感じ、 後者は前日のLaurentの二番煎じにしか見えなかった(事実そうなんだけど)ので、 ウケなかった。
というわけで、私の印象としては、
に比べて、伝えられたものが少なくもったいないなあ、というもの。 RubyConf 2006モースト「もったいない」賞を進呈しよう。
John LamがRubyCLRについて語る、というもの。
1.8.2との互換性を自慢していた。 実際、あまり知られていない個人プロジェクトの割に完成度は高いと思う。 後は実装についても少々。
で、後でITmedia エンタープライズで「Ruby専門家がMicrosoft入り」を読んでびっくりしたりして。 情報が遅い。もしかして私がぼーっとしている間に彼が話してたのかな。
いろいろ。印象に残ったのはSymbianでRubyを動かした話。 以前Pythonが動いていてうらやましいと思ったのだが、 Rubyも動くよ。まあ、SymbianがPOSIX互換層を用意してくれたからできたんだけど。 でも、スレッドとかいろいろ動かないそうだ。
会場で「私は中国人なんだけど、日本ではRubyを公開することで国家の情報の漏洩だ、とか言われることはない?」って聞かれた。
ブルース・リーはカンフーを西洋に紹介しちゃったせいで迫害された(そうなの? 知らなかった)んだけど、日本ではそんなことないかって。
で、「日本では国家はそんなに国民をコントロールしてないんだよ。実際、私はRubyを開発するための公的資金援助(未踏のこと)受けたことがあるしね」と答えたら、 「ああ、国家の名誉のためね」と変な納得のされかたをした。
国家のあり方は国民の発想に強く影響を与えるらしい。
ほぼ同じ時刻に飛行機に乗る日本人6名とシャトルを予約...してたら、なんとリムジンが来た。 「これ、本当にシャトル」と聞いたら、運転手が「今朝はね」と答えた。 そういうものらしい。本物のリムジンなんて初めて乗ったよ。
空港で朝ご飯。ここでサンフランシスコに向かうみんな(ANA組)とはお別れ。 私はUAでシアトル経由成田行き。
シアトルでは普通に国内便の乗り換えと同じだったので、 出国手続きはどうするのかと思ってたら、 ゲート前にある「US Visit」というATMのような機械にパスポートを読み込ませ、 指紋と顔写真を採られて出国手続き完了であった。
以前からこの「US Visit」という機械はなんであるか疑問であったのだが、 その疑問も解消された。ところで、手続きが終わると この機械からわりと大きめの二次元バーコードが印刷されるのだが、 よく見るとこれが裸眼立体視になっているような気がする。 目のピントをぼかすと(私は交差法しかできないのだけど)、 なにかよくわからない図形が浮かび上がっているような気がする。
謎だ。
そのままシアトルから成田へ。機内で日付変更。
映画は
前者はまあまあ。でも、ちょっと子供だましかなあ(注: 子供むけ映画です)。
後者はがっかり。「ポセイドンアドベンチャー」のリメークなわけだが、 なんかちゃち。というか、「ザ・グリード」みたい。 やっぱ、カート・ラッセルのせいか? と、思ったら「ザ・グリード」の方はトリート・ウィリアムズであったか。
成田につく。もう夕方である。一日損した気分。
成田で荷物を受け取って、外に出た途端くしゃみが出る。 そういえばアメリカにいる間は鼻炎の症状が無かったなあ。 花粉やホコリが飛んでないとか、日本とは種類が違うとか。
いや、それ以外の点では日本サイコー。ほんとはあんまり外国に行きたくない。
旅行中の時差ぼけと睡眠障害を取り返すためか、 ほぼ一日中寝ていた。よくこんなに寝れたものだ。
Enumerable系イテレータメソッドにブロックを渡さないとEnumeratorを返す。 が、これがまた使い道がない。
唯一うれしいのはwith_indexメソッドである。 たとえば、「map_with_indexがほしい」という話を時々聞くが、 これがあると
ary.map.with_index{|x, i|...}
とすれば出来上がりである。 しかし、それ以外のEnumeratorのメソッドはあっても役に立たないし、 そもそも使い道がよくわからない。
いっそ、Enumeratorではなく違うオブジェクトを返すべきではないかしらん。 その場合にはきっとwith_indexしかないオブジェクトなんだろう。 Enumeratorが持つby_sliceメソッドとかby_consメソッドとか追加してみたけど、 結局役に立たなかったし(で、HEADから消した)。
with_indexのようなブロック呼び出しを修飾するタイプのメソッドって 他にありえるのかなあ。
なんでそんなことをしたいのかいまいち不明だが、 Oracle自身がLinuxのサポートも行うという話。
RedHatを敵に回したいわけでもないだろうし、 自分ならRedHatよりうまくやれると思ってるわけでもないだろうし。
あと、日本ではミラクルリナックスがあるのでちょっと面倒なことになる... のかな。やや、顧客層は違いそうだけど。
それからRedHatの反論。 互換性については適切かどうかわからないけど、他は筋は通ってそう。
「Selling your future for fame in the present : Pensieri di un lunatico minore」において、Ruby 1.9 (or 2.0)からコンティニュエーションとグリーンスレッドがなくなるのは損失だ、という意見が出る。
まあ、純粋にトレードオフの問題ではあるが、Scheme系の人をはじめとして、 コンティニュエーションを惜しむ声はそれなりにあるようだ。
でも、正直あんまり良い使い道が思いつかないんだよなあ。 コンティニュエーションベースのWebアプリケーションフレームワークもあるけど、 大量に作り出すコンティニュエーションのGCに不安があるし、 それ以外ではあまり活用した経験はない。
あ、FastCGIをコンティニュエーションを使って非ループ化したことがあるか。 それくらい。
一方、これによる問題は山のように受け取っていて、 一時期akrさんからのバグレポートの大半がコンティニュエーション絡みだったこともある。 普通にコーディングしていると、コンティニュエーションで再入されることを うっかり忘れちゃうことがあまりにも多いんだよね。 私でさえそうなんだから、一般Rubyプログラムでコンティニュエーションによって 悪影響を受けるものは(SEGVはしないだろうけど)たくさんありそうな気がする。
それを思うと、簡単に復活とは言いがたいなあ。
「絶対やらない」とは言わないけど。 きちんと実装するには、私よりも頭の良い人が必要だ。
笹田くんなら大丈夫...なのかな?
二歳になった。今まで一番おしゃべりな子だが、 まだ指で2は作れない。チョキは意外に難しいようだ。
ハロウィーンというのは、万聖節(All Saintes Day)の前の日の夜 という意味で、古くからの言い伝えによると 地獄の釜の蓋が開くとか、魔女が集会を行うとか言われている。 要するにキリスト教以前の神話との融合によって発生したお祭り なのだが、おばけが多く登場するなど、 イースターやクリスマスよりも古い様相を残しているような気がする。
ま、そんなことはどうでもよくて、 ただ楽しむためだけに集まってたりする。 仮装とゲームとお菓子と歌と。
妻が責任者(の一人)だったこともあって、 準備段階からいろいろと参加したのだが、 参加した人たち(特に子供たち)が結構楽しんでくれたようなので よかった、よかった。準備に参加してくれた人たちに感謝。
ところで、ひとりめちゃめちゃ気合いの入った仮装をして、 みんなが遊んでいる間もひとりでたたずんでいる人がいたのだが、 彼女には楽しんでもらえたのかなあ。 そんなに不愉快そうではなかったが(ちょっとYuguiさんに似てた)。
今日の仮装大賞は彼女に。
プログラミング言語SNOBOLとIconの主要開発者である Ralph Griswoldがなくなったとのニュースが流れる。
そろそろ第1世代の言語設計者の訃報を聞くようになったなあ。 Kristen Nygaard (Simula)や、Konrad Zuse (Plankalkül) は既に鬼籍に入っている。
僕らはいったい第何世代くらいなんだろう? 2? 3?
二日遅れで末娘の誕生をお祝いする。
「ケーキ、ケーキ」と喜んでいたが、 実際にはそれほどでもなかったらしく、クリームをなめた後は残していた。
まあ、この2年、健康でいてくれたことと 笑いとなごやかな空気をもたらしてくれたことをありがたく思う。
RubyConfのKeynoteにあったparse.yはuglyというところに呼応して Rubyの文法図をかいてくれた人がいる。
ただ、これを見て、Rubyの文法が複雑というのは 実は当たらないと思う。これはたとえばRubyではprimaryに ifやwhileなどの他の言語で「文」のレベルにあるものが来ることができるので、 再帰がきついせいだと思う。
いや、どう言い訳してもやっぱり複雑なのは確かだけど、 だけど人間に優しい複雑さだと思うな。
そんなものが存在することを信じられない人もいるかもしれないけど。
parse.yがuglyなのは、この図で表現されている文法を yaccで素直に表現できないせいだろう。 とはいえ、yaccの制限に合わせて文法を設計したくないし。
28日に開かれたOSC2006 Tokyo/Fallのレポート。
高橋会長が日本Rubyの会の現状を報告。 とはいえ、報告するというほど組織化されていないのが実情のような気がする。 活動メンバーが固定というのも、あまりにもゆるい参加資格によって、 限定された活動メンバー以外は動機づけが弱いということではないかと。
とはいえ、あの参加資格にもそれなりに理由とメリットはあるわけだから、 やる気のある人を集めて組織化する方策というのは思いつかないんだよなあ。 動けそうな人は積極的に理事として任命しちゃう(少々の幽霊は許容)とか、 一般会員以外に賛助会員を作るとか。
うーん、すぐに効果が出る自信がないなあ。
末娘は最近お風呂で遊ぶパズルがお気に入りである。 100円ショップで買ってきたものらしい。 発泡プラスチックでできていて、海の生き物をはめこむようになっている。
名前を教えてやる。
「蟹」「かにー!」
「蛸」「たこー!」
「貝」「かいー!」
「魚」「さかなー!」
「龍の落とし子」「たつのおしごと?」
いや、ちょっと難しかったな。
_ イメージは「沸く」のか「湧く」のか [話の筋とは無関係で恐縮です]
_ まつもと [「湧く」ですよね。誤変換。]