カテゴリー ‘ essay

社会人ならパテック・フィリップくらい知らないと。

知らなかったのでさらっと調べた。

で、「ジュネーブシール」なんだが、これのどこが品質保証なのかよくわからない。

ジュネーブシール規準 No.10
ムーブメントは耐震機構を備えていてもよい。

全体的に、何かを守るために必死だった、みたいな印象。

昔のことだからね。

壁面mac mini

mac mini on wall
いまここ。

笑って酷いことを言う

人を軽く揶揄するのに使われる表現である。
しかしながら、そう悪いものでもない、と僕は考えている。

長い付き合いをしてゆく仲間同士にあっては、時には「酷いこと」を口にしなければならないシーンがあるだろう。
例えば、もらったプレゼントが気に入らないとき。黙って喜んだフリをついついしてしまうが、また同じ人物からプレゼントをもらう機会があるなら、評価は正確に返してあげたほうがお互いの為だ。
あるいは、他人なら目を瞑るような悪い癖だとか。友人だからこそ指摘してあげようということもあるだろう。

重たい言葉を伝えようとすると、ついつい意気込んで、改まった静かな場をわざわざ用意してみたり、畏まった書面に書き連ねたりしてしまいがちだ。しかし実際は、そういった空気を作ったが故に重たくなってしまうのであって、過剰な重みはしばしば意思疎通の障壁になってしまう。

むしろ重たい言葉こそ、軽く伝えるべきだ。特に、人を動かす立場の人間はその能力が問われる。

みんなもっと遅延しようよ

ソフトウェア・エンジニアリングにおいて、「遅延」とは、最適化のための重要な概念である。英語では “delay”.

遅延ロード
アプリケーションが外部モジュールを使用する際、後々必要になるモジュールは起動時に全て読み込んでしまうというのが一般的であった。対して、軽量なまま起動を済ませ、追加モジュールは必要になったぎりぎりの時点で初めて読み込むという手法。
遅延生成
データベース管理された日記をHTMLで公開する場合、アクセスされる度にビューを生成するとサーバに負荷がかかるため、その日の記事を書き終えた時点でビューを生成するというアプローチが取られることがあった。対して、データ入力完了時ではなく、最初の閲覧者がそのページを見ようとしたときにビューを生成する、という手法。(”キャッシュ”は、哲学は違うがやってることは多分一緒。)
遅延宣言
コーディング時に、使用する変数のリストを関数の最初ですべて宣言するのではなく、使用する箇所の直前で宣言、初期化する手法。古いC言語では文法的に認められていなかった。僕はこの発展で遅延include(実際にそれを使用する関数の直前でクラスやパッケージのヘッダをincludeする)を多用していたところ、前の会社の同僚と議論になった。

もちろんそれぞれメリットデメリットはあるが、近年は特に、大抵において歓迎される。
これが、「遅延」である。

さて、話を日常生活に戻そう。
「遅延」は、忌むべき行為であり、「前倒し」が常に奨励される。
「もっと遅延しろ!」などと言われることは決して無い。
ともすれば「怠惰」に直結するくらい、ネガティブな語感をふんだんに含んだ言葉だ。

このギャップはどうしたことだろう?
(揶揄してるのかなんだか知らないが、”delay” の代わりに “lazy” を使うこともある。)

僕はいま現実に、週末のイベントの準備でてんやわんやしていて、遅延させないため、遅延を取り戻すために戦っている最中。終わると大抵、「もっと前倒しで準備するべきだった」みたいな反省が当然出てくるのであるが、そこには本質的な見落としがあって、だからまた遅延を繰り返している。

「歓迎されるdelay」をもう少し突き詰めて考えると、そこにヒントがあるかも、と漠然と思いつつ、仕事に戻ります。

#来週、続きを書くかも。遅延ダイアリィ。

時間の余裕が無いモード

学生時代は、「躊躇無くカフェに入る」が、切羽詰ったインジケータだった。
当時は、数百円でコーヒー一杯飲んだら、1時間以上は居座らないともったいない、という感覚だった。
切羽詰ると、ほんの10分PCに向かう時間を得るためにその数百円を払うようになる。

それが、ちょっと大人になって、「躊躇無くタクシィに乗る」になった。
といっても、1000円くらいの範囲だけれど。
それ以上の距離になると、経路や時間帯によっては電車のほうが早いし安いということも多々ある。
地下鉄の経路が無いときにショートカットとして一部利用するという使い方だ。

これがもっと大人になってタクシィが常用になったとすると、次は時間を節約するために何をするだろうか。
・躊躇無く買い占める
・躊躇無く借り切る
・日雇い
・外注
ここから先はもう、ヘリとかジェットとかしか思いつかない。
とりあえずメーヴェ欲しい。

説明をキットします。

Microsoftの機械翻訳ドキュメントは役に立ったことが無い。意味不明すぎて結局英語を見る。
自動翻訳の実用化はまだまだ先か~。

思わず笑った翻訳。
Mac SDK: ソフトウェア開発は、説明をキットします。

きっと、してくれるよね。いつか。説明を。
僕はその日を待つよ。

安い親切

例えば以下のようなシーン。

15:00に待ち合わせていた友人から、14:50に電話が来た。
「実は遅刻しそうなんだ。今すぐタクシーに乗ればぎりぎり間に合うけれど、10分待ってくれるならタクシー代¥2000を君にあげるよ。」
ここで、¥2000なんかいらないからとにかく約束通りに来い、と言うか、¥2000で10分余分に待つか。
あるいは¥5000?あるいは¥10000?

お金で買えないモノ、というのは多々あるが、上記のように適当なシチュエーションを想定すれば大抵はお金に換算することができる。
別にお金でなくても良いのだけれど、とにかくいろんなことを同じ物差しの上で比較してみよう、という話。

何が嬉しいか、何を嫌がるか、何が楽か、何が苦痛か。これは人によってまちまちである。
自分にとって喜ばしいことが、相手にとっても同様であるとは限らない。というより、程度の差まで考慮すれば、一致することのほうが稀であると言っても良い。

自分にとって楽な行為が相手に大きな幸せを届けるとしたらこれは好都合である。
これは、国家間の貿易と様相が似ている。自国で安く生産出来る「親切」を輸出して、「人徳」を貯蓄する。
別に悪いことでは無いと思う。
お菓子を作るのが好きな人は、わざわざ菓子嫌いな人にそれをプレゼントすることは無いだろうし、むしろより多く喜んでくれる人を優先するだろう。ごく普通のことである。

同じ相手、同じ親切でも、時期によって受け取られ方が変わることもある。
大抵の人間の感情には波があって、落ち込んでいる時期には些細な親切でも嬉しいし、逆に、十分に恵まれている時期には往々にして感謝というものを忘れがちである。(そういう人が多い、という話。)
これは、株の売買と様相が似ている。安いときに恩を売っておくと、高くなったときに配当が見込める。

こんな風に損得を計算しながら親切を行使するのは「偽善」だ、と言う人がいるだろう。
偽善でもなんでも、現実に他人の役に立ったなら、何もしなかった人間より立派だと僕は思う。

ちょっと本気でWeb2.0風に

申し込みフォームを本気で作った: 世界のマジックショー!2007

ポイント:

  • いくつか調べた中でいちばんよさげなjQuery.jsを採用
  • formの送信はもちろんajax動作
  • JavaScript offの環境下でも、レガシィに動作
  • よって、Validationはcgi側のみに実装
  • でも、ajax動作の時はエラー項目の色がちゃんと変わる
  • ケータイでもそのまま使えるように、Shift-JISを採用
  • CGIは、ajax動作時はutf8、レガシィ時はShift-JISに自動的に切り替わって出力
  • CGI側も、Perl5.8の標準モジュールを出来るだけ使用
  • ところがCGI.pmにutf8のバグがあるようなのでCGI::Liteを持ってきて使用
  • ついでにデザインもCSSEZとか使っちゃう

ふーん、なんだこれ、っていじってくれる人は「ご氏名」を「テスト」にしてくれれば無視します。
(でもメールアドレスとかきっちり残るのでちゅうい)
もちろん、本当に申し込んでくれるのもアリ。

エスプレッソ・メモリィ

いつぞや応募したコーヒーストーリーの、2作品目として書きかけていたものを、Kuboon27周年記念に仕上げてみたので公開。フィクションです。
続きを読む

文字という通信手段

「ある数字を二乗したら、9になりました。ある数字はいくつ?」という問題と、
「x^2=9のとき、xを求めよ」という問題は、まったく同じ内容を単に言い換えただけである。
後者の言い回しに抵抗の無い人間にとっては前者の表現は単に冗長で、むしろ理解を遅らせる。

ところで、問いの答えが「3」と思っている人は不正解。正解はもう少し後で書く。

AさんがBさんに何かを言った、とする。(言った、と書いたが、ここでは表情や声調を別にした、チャットやメールのような純粋な文字コミュニケーションを想定しよう。)
AはBに何かを伝えようとして言葉を発するのであるが、これは、
1. Aが、伝えたい内容を文章化する
2. 文章化した言葉をBに送る
3. Bが、その文章を解釈する
という3つの段階を経る。1をエンコード、3をデコードと呼ぶ。
理想的には、Aによるエンコード前の「伝えたい内容」と、Bによるデコード後の「伝わった内容」が完全に一致することが望ましいのであるが、現実には、必然的に食い違う。
文章化というエンコード処理によって、脳内のもやもやとした不安定な何かは、文字という確固とした記号に変換される。その時点で膨大な情報量が失われ、要約だけが残る。これは「非可逆圧縮」と呼ばれる。
一方、受け取り手のBは、そのあまりに質素で漠然とした要約情報を、それまでの会話の流れやAとの過去の共通の記憶などを総動員して補い、もともとAが送ろうとしていたのと同じくらいの体積に膨らます。
「誤解」とは、このデコード処理の失敗のことである。

現実にはほとんどの人間が、「答えを1つ得るとそれで満足してしまう」という習性を持っている。
冒頭の問いの答えは、3とマイナス3。2つとも答えてくれないと、数学的には不正解。
マイナス3を思いつかなかったということが即ち、デコード処理の失敗であって、「誤解」である。

日常の言語のやりとりにおいても、このように「解を網羅する」努力が重要であると思われる。

参考:MORILOG 6/4 なんでも自分でやりたい

return top