というのは確かにその通りだと思います。もっとも、
という対策で満足できる人も多かろうとは思いますが。
さっそく、原稿に取り込もう。ありがとうございました。(_ _)
初等協会の活動として、子供たちを連れて教会とその隣の宣教師のアパートの周辺の草とりをする。 かなり生えてた雑草を片付けて気持ちよくなった。 で、すっかり疲れてしまったりすると、普段の運動不足を実感したりする。
「blog」と「にっき」を区別しない などと書いたものの、数日間日記をつけてみると、やはりこれは違うものだと感じるようになった。
blogは、〆切や分量などの制約はゆるいものの、 やはり雑誌の記事やコラムなどに近いものが本来のあり方なのだろう。 新聞や雑誌の記事で「今日は子供と草刈りをした」なんて個人的な話題を読まされたら、 あまり気分は良くないように、ある程度読み手もなにかテーマに沿った一貫性のある記述を期待しそうだ。 ただ、既存のメディアとは違い、blogは個人に所属しているので、 パーソナルな記述が現れるのはむしろ当然で、それが日記との区別を難しくしているのだと思う。 また、パーソナルな記述があるがゆえに既存のblogのメディアより面白いという点もあると思う。
一方、日記のあり方はまったく逆だ。 一貫したテーマに対する「記事」にパーソナルな記述が入り込んでいるblogに対して、 日記は基本的に日記なので、自分の生活に起こったことも、その時に考えたことも、なんでもありだ。 紙の日記と違って、不特定多数の目にとまる可能性のあるWeb日記でも、原則は同じだろう。 極端にパーソナルな誰が読むかわからないから書けないことはある けど、日記ではパーソナルな記述こそ主体である。
まあ、blogと日記はあくまでも便宜的な分類で、blogのような日記も、日記のようなblogもあり、 またその中間にも連続的に存在している(だろう)ことが話をややこしくしている。もっとも、 読者にとっては、重要なのは「読んで面白いかどうか」で、blogらしいとか日記らしいとかは、 面白さとはまったく関係ないのだろうとは思う。
で、今後私はどうするかというと、やはり、たあいのない日常の当たり障りのない記述と、 折々の興味あるネタに関する長めの考察の入り交じった「日記」を書き続けるのではないだろうか。 少なくとも書くことに飽きるまで。
4834030326 ここのところ息子が誕生日に買ってもらった4834030326を 毎晩１章ずつ読んで聞かせてやっている。 今はちょうど4834000354のまん中あたりだ。 全三巻のこの話、すごく有名なのに子供のとき読んだことなかった。
息子は保育園でなんども読んでもらったことがあるらしく、先の展開までぜんぶ知っているのだが、 知っていることそのものが嬉しいらしく、かえって喜んでいる。 そういえば彼はいつも読んだことがある絵本を借りてくるのだ。 安心感があるのか？
4834000109 しかし、最近の白眉はやはり4834000109だろう。 これまた子供のときに読んでなくて、子供に読んでやったのがはじめてだったのだが、 日常的な風景がいつのまにかファンタジーになってしまっている様子が心に残った。 積み木の船がごく自然に大海原に出帆してくじらをつかまえて帰ってくる話とか。 しかし、息子にとっては当然のようであまり感動していなかった。 そうか、彼にとってはこれこそが今生きている世界なのだな。 私も昔そうだったのだな。
同じようにファンタジーに迷いこむ絵本としては、 4834000508や 4834008738がある。 「てぶくろにクマがはいるかっ」とか「おふろにクジラがはいるかっ」とツッコミたくなるのだが、 そこが良いのだ。どちらも(私も子供たちも)大好きな絵本だ。
新VAIO Uが登場した。 「VAIO Type U」という名前だそうだ。 最近ノートの調子が悪いので、魅力的に見える。 実際U101もあまりキーボードは使ってなかったし。
が、800x600はちょっと狭い気がするのと、VAIOシリーズはLinuxでの動作に不安がある。 やっぱ、次、買うならThinkpad X31(かその後継機)くらいかなあ。 X40も新しいのは悪くないんだが、大きさよりもパワーが欲しい気がする。
最近、私の行ってる教会のスタッフは全員PCが使えるようになった。 そこで、情報共有をWebで行おうと思うのだが、問題が。
というようなことに。だれかこんなソフトウェア知りませんか。 HikiやInstikiとかはグローバルな「更新者」と「参照者」は設定で可能だけど、 上記のような階層構造のある認証とかはないみたい。
Railsかなにかで作るしかないのかなあ。私にやらせるとフレームワーク辺りから作りはじめて いつまでたっても終わらないから、出来合いのものがある方が嬉しいんだけどなあ。
どうしても見つからないようなら、その辺のWikiに認証をつけて運用して、 外部からの参照にはページのコピーか、明示的にメールで送りつけることで対応するか。
でも、そういうソフトウェアがあったら、世のCMSがやってるようなことの一部は代替できそうな。 Wiki以上、CMS未満、というところか。
とりあえず名前を決めなきゃな(まず、そこか)。
ゆうぞうさん講師により淡々と進む。
RadRailsかっこいい。 IDE好きな人がいるのも分かる気がする。
事前に漠然と想像していたのとは違う進み方をしたり、 今後に向けてテキストを若干修正した方が良いと感じるところもあった。 しかし、心配していたほど進度の違いによるトラブルは起きなかった。 先に進んだ人も、AWDwRを読んだり、いろいろ手元で試したりしてたみたい。
講習会会場に戻り、懇親会へ。
いろいろな人がいて楽しい。 講習会における懇親会は心の壁を薄くするのに役立つので 効果的だったように思う。
当所最終日に行おうという話だったが、 最終日終わったら帰りたい人もいるだろうと2日目夜に変更した。 でも、今考えると、お互いによく知り合った方が学習効果が高くなりそうだし、 初日の夜のほうがよかったかなあ。次回はそのように提案しよう。
Martin Fowlerによる「仕事にRubyってどうよ」という話。 bliki_jaによる和訳あり
言語として好き、趣味のプログラミングにRuby、ってのはもう珍しい話ではなくなったが、 じゃあ、仕事にも使おうというのは、新し物好きのアメリカでも障害はある。 で、最近のトレンドでRubyを改めて評価してみると...。
MartinがRubyファンであることを割り引いても、一読の価値はあると思う。
ビジネスユーザとコミュニティをサポートでつなごうという試み。
うまく行くといいなあ。 「なんとかExchange」とか、軌道に乗らなかった試みは多いから。 結局、今まではコミュニティをドライブする力に欠けたんだと思うんだよね。 コミュニティの求心力とか、コネクションの強さとかに関係するんだろうか。
長野県松本市でプレゼンする。 「国産技術」などと言われると恥ずかしい気もするが、 まあ、あまり気にしないことにする。
家族にこの話をした時に、家族全員が「松本のキーホルダーを買ってきて」とのことであった。
わかりました。
Charles Nutterのインタビュー。 YARVより速いとか言ってるよ。
処理速度のチューニングも進んでいる。JRubyは高速実行を目指したYARVと、「ほぼ同等か、テスト項目によってはやや遅い程度の速度」（エネボー氏）といい、本家のRubyよりは確実に速いとしている。
ふむ。でも、たしか、JRubyって1.8.6よりちょっと速いくらいじゃなかったっけ。 プリコンパイルしたのかな。
昨日、Skypeビデオで苦労したので、Ekigaも試してみようかなあ。 とりあえず、ビデオテストで自分の顔が見えるところまではできた。
ノーブランドのカメラはあっさり動いたが、 ElecomのカメラはLinuxでは使えないみたい。
弊社でも採用基準には悩んでいるのであった。 参考にしたい。
「PHPは言語としてはダメだが、どこにでもあるし、知見も蓄積されていることがキラーだ」 という話。納得できる。
前にも書いたが、システム構築における言語の比重ってのは高くないんだよね。 言語デザイナーとしては残念な話だけど。
「素晴らしいデザイン」はあまりにも簡単に見えるので、 あたかも労なくして作られたように見なされてしまう、という皮肉。
The Elegance Paradox is this: to create elegance requires entirely inelegant preparation, but nobody should be able to see that.
確かに「自然なデザイン」というのは難しいものだ。 ほとんどの場合、「自然」は未定義語だから、 「感性」、「本能」、「勘」などを頼りに試行錯誤を繰り返す必要がある。 その苦労は他の人には見えないんだよね。
職人魂。ちょっと方向性を間違っちゃった、かな。
おひさしぶり。
GC sweep時間はわりと短縮できそうなので(authorNariくんがLazySweepパッチを書いてくれたし)、 このところGC mark時間を短縮するアイディアはないか、考えている。 今のRubyに入れたいので、制約として、
というものがある。
しばらく前にTwitterで、「いくつかのオブジェクトをまとめて、その単位でマークする」というアイディアを披露してみたが、すぐに三浦さんから「トラバースのコストが減らないから効果ないんじゃない」との指摘が。ちょっと考えてみたら、確かにその通り。かっくり。
まあ、50年間、いろんな人が考えてきたGCで、画期的なアイディアを思いつくのは難しいよね。
まあ、そういう「誰も知らない系」ではなくて、mark時間短縮に効果のありそうなアイディアは、私の思いつく限り3つ。
ひとつはビットマップマーキング。GC markをオブジェクトヘッダ内ではなく、外に用意したビットマップに置く。 マークチェックにメモリ中オブジェクトにアクセスしなくて済むこと、それによりワーキングセットが小さくなることと、仮想記憶のページを汚さないことがメリット。
もうひとつはGC markフェーズの並列化。スレッドを活用する。markは相互依存が少ないので、マルチコアマシンでは効果的。ただし、ビットマップ操作はアトミックではないので前日のビットマップマーキングとは相性が悪い。ビットマップのチェックや更新のたびにロックをかけてちゃコストが高すぎる。 大概のCPUはバイト単位の操作ならアトミックに行うことができるので、 ビットマップじゃなくて、1オブジェクトあたり1バイト使う、バイトマップにすることでロックは回避可能だと思う(だよね)。 バイトマップにするとメモリ消費量が8倍になっちゃうけど、この領域は他の最適化に使えるかも。
最後はGC mark対象のオブジェクトそのものを減らしちゃうこと。たとえば、ノードやメソッド、組み込みクラスなどをmark対象から外しちゃう。あとはオブジェクトのimmediate化。ある意味、もっとも正統的なアプローチ。1.9.2ではだいぶ外したから、後は組み込みクラスかな。
組み込みクラスを別扱いすると、ユーザー定義クラスだけ一気に消去のようなことが可能になって、mod_rubyのようなタイプがうれしいかも。あと、MVMで組み込みクラスを共有できて、初期化コストが下がるとか。これらを直接書き換えないようにしないといけないけど、それは隠しクラスで実現できそう。