プロセスの同期の「セマフォ」の項にあるサンプルを実行したのだが、カウントアップ中（セマフォ所持中）に×ボタンでプロセスを殺すと、その分は元に戻らない。
つまり、セマフォはリソース管理方法としてはまったく使えないということだ。
参考までににMutexは、所持しているスレッドが死ねば自動的に解放されるし、開いているハンドルも自動的に閉じられる。

他のプラットフォーム上ではどうなんだろ。

２つのドメインtrick-with.netとtrick-and.net(仮称)を僕が持っていて、value-domainのDNSでどちらも同じxrea上のサーバにAレコードを向けてある。

この状態で、trick-with.netへ来たメールをgmailのアカウントに転送していたのだが、一定の確率で転送を蹴られるという困難な問題が発生していた。

(more…)

SmartPointerクラスが、管理下のポインタをdeleteすることなくその管理を終えるときに呼ぶ関数名はなんとしたらよいか。
SmartPointerがpointerを保持している、という実装上の事実からすればrelease()等が妥当だが、pointerそのものと同様に扱えるというのがSmartPointerの本来の設計思想であるので、release()とするとpointer自体を開放してしまいそうで紛らわしい。

などという話をしていたときに当時の同僚だったtxgが提案したのが leak() だった。

素晴らしくね？
とても気に入っていて、今でも愛用している。
流行らないかなあ。SmartPointer自体が時代遅れだからもうダメかな。

前提：
1. Wikipedia上の編集はすべて履歴が残る。
2. 途中の版だけを削除することは出来ず、ある版を削除した場合、それ以降全ての編集が消えることになる。
3. ある版で無断引用等の問題が発覚した場合、それ以降の全ての版を削除する以外に対応法は無い。

事件：
「初版で問題発生」

対応：
→初版以降を削除＝項目自体を削除。
もちろん、同名の項目をまた作ればよいだけの話なのだが、「項目削除」という言葉になぜか勝手にインパクトを感じた人たちが祭り状態。

横道：
開発元から引用許可の話があったが、「引用元を明記せずに引用できるのはGFDL配下の文書のみ」というWikipedia側のルールを開発元が理解していない恐れがあり、実際、商用サイトがGFDLに従うことは現実的ではないため、権利者の許可といえども保留。

いまここ。

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

遅延ロード

アプリケーションが外部モジュールを使用する際、後々必要になるモジュールは起動時に全て読み込んでしまうというのが一般的であった。対して、軽量なまま起動を済ませ、追加モジュールは必要になったぎりぎりの時点で初めて読み込むという手法。

遅延生成

データベース管理された日記をHTMLで公開する場合、アクセスされる度にビューを生成するとサーバに負荷がかかるため、その日の記事を書き終えた時点でビューを生成するというアプローチが取られることがあった。対して、データ入力完了時ではなく、最初の閲覧者がそのページを見ようとしたときにビューを生成する、という手法。（”キャッシュ”は、哲学は違うがやってることは多分一緒。）

遅延宣言

コーディング時に、使用する変数のリストを関数の最初ですべて宣言するのではなく、使用する箇所の直前で宣言、初期化する手法。古いC言語では文法的に認められていなかった。僕はこの発展で遅延include(実際にそれを使用する関数の直前でクラスやパッケージのヘッダをincludeする)を多用していたところ、前の会社の同僚と議論になった。

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

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

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

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

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

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

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

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

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

申し込みフォームを本気で作った： 世界のマジックショー！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とか使っちゃう

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

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

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

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

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

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

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

DLLには暗黙的リンクと明示的リンクの2種類の利用方法がある。
コーディングの立場からすると暗黙的リンクが断然楽なのだが、リンクの遅延が出来ないために明示的リンクを利用せざるを得ないことが多い。

明示的リンクを利用する場合、::GetProcAddress() によって関数ポインタを取得し、それをあらかじめtypedefしておいた関数ポインタ型のポインタ変数に代入して使用するのが一般的である。
(more…)