名刺 
キングジムからデジタルの名刺ホルダが発売されるみたいです。
名刺整理といえばローロデックスを初めとした物理的なホルダーに始まって、デジタル化方面ではScanSnapのようなスキャナをつかってOCRするとか、最近だとEvernoteを使ってウェブで管理するというのが流行だったりすると思いますが、そこにもうひとつ選択肢が増えることになりますね。
キングジム：9999枚の名刺を記録するデジタル名刺ホルダ--液晶メモも販売 - CNET Japan
ピットレックでは、内蔵カメラで名刺を撮影して、画像データとして保存される。文字認識機能（OCR）によりテキスト化された名刺の内容は、会社名や氏名、閲覧履歴、登録日、マイリストといった方法で検索できる。保存可能な画像データ数は、本体に同梱された2GバイトのmicroSDカードで名刺約1800～2000枚分。別売りのmicroSDHCカード16Gバイトを使えば約9999枚分の名刺が保存できる。
デジタル化では閲覧用の端末とスキャナが別になっているのがちょっと不便だと思っていましたが、小型のカメラを使ってそれをひとつにまとめてしまったというのは面白いアイディアですね。OCRの出来が気になりますが、単体で完結しているというのは魅力的です。
c setjmp()*1とlongjmp()*2については大昔にちょっと聞いたくらいなのでどのような機能なのかすっかり忘れてしまっていたのでちょっと復習していたのでメモ。そもそも個人的に一番C言語の勉強に活用したと思うqmailにはsetjmp()もlongjmp()もでてこないので、なじみが無くても仕方がなかったりするわけですが。
とりあえずそれぞれの関数のプロトタイプはこんな感じ。
setjmp()を呼び出すと、jmpにコンテキストが記録される（戻り値は0）。コンテキストは主にレジスタの状態が記録された構造体（当然、保存される情報にはプログラムカウンタやスタックポインタが含まれている）。
後でjmpをlongjmp()に渡すとレジスタがjmpを呼んだ時点のものに書き換えられるので、プログラムの実行は強制的にsetjmp()を呼んだ部分から再開される（CPUにとっては現在の実行行はプログラムカウンタの値に過ぎないから）。
単に戻ってくるだけだと、記録するためのsetjmp()なのか、longjmp()によって実行が戻されてsetjmp()が呼ばれたように見えるのかが区別できなくて困るので、longjmpの第２引数にretを渡すとsetjmp()の戻り値がretになるようになっている。よって、retには0ではない数を指定する必要がある。
という風に理解しました。
樋口さんのブログの個別エントリのページに関連記事や関連リンク、Twitterなんかのまとめが入っているのでこれはなんだろうと思っていたら、Six Apartのzenbackというサービスみたいです。とりあえずβテスター募集中らしいので、トップページの欄から申し込んでみました。
シックス・アパートが、ブログ／メディア向けの ソーシャルメディア相互連携ツール「zenback」を発表 - Six Apart
「zenback」は、ブログやメディアと、外部のソーシャルメディアとの間で関連記事を簡単に相互表示する機能を提供します。「zenback」を導入することで、ブログやメディアの過去記事への参照や訪問ページ数が増加するほか、外部サイトから共通の興味を持つユーザーのトラフィック流入が増加する、といった様々なメリットが期待できます。
主に個人向けの無償版と、カスタマイズ機能を追加した有償版を提供します。無償版は2010年6月28日よりパブリックベータ版の申し込みを開始し、8月2日より正式版の提供を開始します。有償版については、後日提供を開始する予定です。
はてなとか入ってるので、これはグローバル展開ではない日本独自のサービスということなんですかね。zenbackのウェブには「※ zenbackは、現在 blogs.com で稼働中です。」とあるのですが、http://jp.blogs.com/のページには確かに導入されているのですが、http://blogs.com/のページには入っていないようです。
networking 
ちょっとこのバッファローのPortable Wi-Fi が気になってます。
別にDoCoMoの3Gには興味があるというわけでもなくて、これくらいのサイズで暗号化方式やESS-ID異なる Wi-Fi to Wi-Fi のルーティングができる製品が欲しいのですが、それだけのために買うにはこれはちょっと高すぎる感じですね。すぐに欲しいというわけではないのと、このセグメントはまだ発展の余地がありそうなので、類似の製品でもっと廉価なものが出てくるのを待つのが得策かなぁ。
server sakura customersupport systemdown 帰り道でケータイに監視サーバからSSHタイムアウトのアラートが入ったので、どうせ個人サーバだし、よくある*1一時的な障害だろうとたかをくくって、家に帰ってPCの電源を入れてアクセスしてみたら、本当にサーバが落ちていて焦りました。
Pingは帰ってくるものの、HTTP、SSH、SMTP、IMAPなどのアプリは全滅。Pingに遅延はないし、さくらのMRTGにも異常はないので、これらを見る限りトラフィック過多とかではなさそう。気になるのはSSHのコネクション自体はいったん開く（Connectiontimed outではなく、Connectionclosedといわれる。）という不思議な症状であること。つまり、つながるが一方的に切られる状態であり、まったく応答がないわけではない。もし、プロセスが死んでいたら、そもそもコネクションは開かないはず。これはむしろすっぱり落ちているよりも嫌な予感がする。
以下、障害対応メモ。
[rejecting I/O to offline device が出ていますと言われた日 の続きを読む] icann dns エロサイト向けのドメインができるみたいです。
ほとんどの会社や組織で真っ先にTLDレベルで規制対象になると思いますが、それで商売になるんでしょうかね。
ICANN、ポルノサイト用ドメイン「.xxx」を承認へ - CNET Japan
ポルノサイトが間もなく、「.xxx」アドレスを持てるようになるかもしれない。ICANNがようやく、この新たなドメイン名の承認に向けて動き出したためだ。ICANN（Internet Corporation for Assigned Names and Numbers）は長年にわたり、.xxxをトップレベルドメイン（TLD）に加えるよう求める提案を何度も拒否してきたが、米国時間6月25日、ついに態度を軟化させ、この新ドメインを条件付きで承認した。
そういえば.xxｘというドメインを見て思い出したのは、英語圏の人と初めて仕事をしていたときに、みんな資料の伏字###と書くので、XXXと書いたらダメなのかと聞いたら、XXXと書くとエロの隠語だから卑猥な感じがするんだという話を聞いてカルチャーショックを受けたことを思い出しました。隠語はだれも教えてくれないですからねぇ。
c cpp 先日、malloc() の返り値は void* なので、ずっと明示的にキャストしないといけないと思ってた（というか、そう教わったからそういうものだと思ってた）けど、実はそうではないらしい*1ということが分かったので忘れないうちにメモ。
test.c
実際に上記のようなプログラムを書いてコンパイルしてみると、Cのときは特にエラーも出なくて、C++にするとコンパイラが怒るのがわかります。
クセとしてはいつでもキャストするように覚えておいたほうが都合いいから、教える方がそうしていたということなんでしょうか。ただ、C でも void* を間接参照して値を格納しようとするとエラーになるので、型チェックの仕様はちょっと謎。もともと方言が多い処理系だからあまり深くつっこんじゃいけない部分なのかもしれませんが。
networking 
ゴールデンウィークのときに実家に無線LANルータを寄付してしまったので、家には無線LAN環境がないままで不便だったのですが、発売されたときから目をつけていたWR8700Nが１万円切ったら買う！と心に決めてずっと我慢していました。
さっき不意に一万円を切っているお店を発見してしまったので、反射神経的にそのままポチってしまいました。久しぶりに届くのが楽しみな機械です。
† 2010/07/04追記
数日使っていますが、設定も簡単でした。うちの場合は上流がADSLなので普段はECOモード（100M固定・無線オフ）で使って、ノートパソコン使うときだけECOモードを解除するようにすると消費電力も少なくて良さそうです。11nでの無線通信速度は思っていたよりもずっと早くて驚きました。
c C 言語についていろいろ調べていて、わざとダブルフリーするようなプログラムを書くと glibc がスタックトレースを吐いて ABORT することに気づきました。バリバリ C を使う人にとっては当たり前の挙動なのかもしれませんが、プログラミングの道には最初から Java で入ってしまったので、メモリ管理を自分でやる言語をほとんどメインで使ったことがない自分にとっては興味深い挙動でした。
test.c
例えば上記のようなプログラムを実行すると下記のような出力になるようです。
ちなみにこの挙動についてはMALLOC_CHECK_で調整できるようです。
[glibcのdouble free検知 の続きを読む] twitter W杯の日本対デンマーク戦は仕事の関係もあって熟睡していましたが、へんな時間だったにもかかわらずTwitterでの秒間Tweet数が過去最高の3283TPSを記録したようです。TPSはTweets-Per-Secondの略のようですが、コンピュータの世界にはTPSといえばTransaction Per Secondという立派な単位がすでにあって、こちらでも十分意味が通じるので別の単位を再定義するのはちょっとなぁという感じがしなくもないです。
ところが、日本対デンマーク戦(日本が3-1で勝利!)での試合終了直後の数字は、NBA優勝決定戦でロサンゼルス・レイカーズがボストン・セルティックスを破った時よりも、上回りました！審判が日本対デンマーク戦の試合終了のホイッスルを吹いた瞬間、最高記録を更新し、秒間ツイート数3,283を記録しました（同時刻に開催されていたオランダ対カメルーン戦は、日本対デンマーク戦よりも6分早く終了していました）。
それはそうと、この3,283TPSという数字はなかなかにすごいですね。Twitterのサービス自身は機能的にはそれほど難しくないですが、これだけの更新トランザクションを捌きつつ、それ以上に入ってくる参照トランザクションの処理も同時にやってのけなければならない性能要求はなかなかにシビアです。2007年時点のTwitterの負荷対策の資料には600 requests per secondと記載されているので、３年足らずでトランザクション数が5倍以上になっているんですね。今となってはアーキテクチャもだいぶ変わっていると思いますが、くじらを出しつつも良く耐えていると思います。
