以前紹介した北澤八幡神社　氏子崇敬会発足記念会（昭和の日　祝賀）、無事やり終えてまいりました。

今回新しい試みとして、舞台の動画をネット公開してみることにしました。
７番演したうち、オフィシャルで撮影している定置ビデオがアナログのためまだ映像入手できていなかったり、舞台上で失敗があって出演者に公開OKもらえなかったりとかがあったので、とりあえず私の個人ビデオで撮った内許可もらえた2番について、うちの「太郎冠者」Webサイト内で公開しています。

というか、動画共有サイトにアップしたもののflv貼り付けなので、この記事にも貼ってしまいましょう。

魚説経

胸突 

特に後の胸突は、プロの木村正雄師、及びキャリア15年近くになるセミプロのお弟子さんとの競演です。
プロの狂言舞台をネット上で見られるのは珍しいのではないかと思うので、ぜひ見ていただいて狂言の面白さを知っていただければ幸いです。

今後も動画コンテンツの数を増やしていきたいと考えていますので、「太郎冠者」サイトをよろしくお願いいたします。

顔ちぇき、やってみました。

とりあえず自分の顔2種類でやってみましたが、

1回目：

三村マサカズ：55%
上田晋也：53%
児玉清：53%

2回目：

田村正和：51%
上田晋也：46%
藤井隆：46%

「三村マサカズ」「田村正和」ってそれ名前で選んでるだけちゃうんかと、小一時間（ｒｙ
とりあえず、「上田晋也」はガチなようです。言われたことないけど。

家内と息子でもやってみました。

家内：

沢尻エリカ：25%
菊川怜：25%
児玉清：24%

なんか誰にも似なさすぎです。相当独特な顔なのでしょうか。
児玉清24%は惜しかった。後1%欲しかった。アタックチャーンス。

息子：

しずちゃん：42%
チェジウ：42%
矢口真里：38%

やっぱり子供で顔立ちが優しいからか、複合検索にすると女性ばかりひっかかります。

ちなみに狂言の後輩は、1位「要潤」になっていたのですが、みんなに「個々のパーツはいいんだけどねえ...」「やっぱ全体のバランスと言うのが大事だよなあ...」見たいな事を好き勝手言われておりました。

セカンドライフは、インタフェースが使いにくいし3D画像に酔ってしまうしで、あっという間に遊ぶのを止めましたが、

3Dインターフェースは主流にはならないだろうなあ -たつをの ChangeLog-

「FPN-IT技術者は超保守的、セカンドライフへの無関心が持つ意味」
(http://www.future-planning.net/x/modules/news/article.php?storyid=2281)
という記事にて、

ビジネスウイーク誌を読まなくても、１０年たてば3Dのインターフェース
が主流になるでしょう。

との主張がなされていました。しかし私は懐疑的です。

　　　.........

というわけで「3Dのインターフェースが主流になる」ことはないでしょう。
本当は3Dが良いんだけど2Dに甘んじていた分野が置き換わるだけかと。

完全同意。

というか、3Dインタフェースが使いにくいのは、結局入力側デバイスがついてきていない為ではないでしょうか。
出力側がいくら綺麗な3D化しても、入力側のデバイスが、マウスやトラックボールといった2次元平面をトレースする事しか考えられていないのでは、使いにくいのは当たり前ではないかと思います。
たとえば空間的な位置変異も測定してくれるVRグローブのようなデバイス、3Dインタフェースの入力装置としてそれが最適かはよく判らないですけど、そういうものが出てくればまた話は変わってくるのかなと。

それまでは、3Dインタフェースはきわめて限られた分野でしか成功しないのではないかと思います。
たとえば、複数方向から商品の見栄えを確かめたいので商品の3D画像をクルクル回すとか、そういう特定の操作（「視点を変える」）だけに可能操作を絞っての3D化。
或いは、マピオンラボの3D地図なんかも、あれは3D化したといっても基本的には「地面に沿って移動する」という2Dのフリースクロール操作を、視線だけ現実の生活における視線に置き換えて、地図の俯瞰的な表記だと位置を掴みにくい人でも自分の位置を判りやすくしたというだけで、基本は2D操作の域を出ていません。
このようなところでは、たつをさんが書かれていた「本当は3Dが良いんだけど2Dに甘んじていた分野が置き換わる」ことが発生するかもしれませんが、それ以外ではまず3Dインタフェースが主流になることはないかなあと、そう感じます。

みんなでつくる駅前コミュニティ「Ranoty（ラノティ）」

駅を中心としてつながるSNSコミュニティサイトです。
無料で簡単にSNSが作れるコミュニティサービス基盤、「nanoty」のシステムをベースにして作られているみたいです。

機能としては、各駅のポータルを中心に、投稿写真や口コミ情報、関連ブログ、伝言板、グルメ情報等を共有できる他、nanotyの機能を利用して各駅に付随する子SNSみたいなものも、作成したりできるみたい。
携帯にも対応しているのでので、その場で共有したい情報を即座に最寄の駅コミュニティに投稿したりもできます。

位置情報コミュニティとして、駅等の交通のクロスロードを単位とするのはすごく有効な手です。
生の位置情報ベースだと、情報の存在が連続的になるため情報共有は行えてもその上でのコミュニティは成立しにくい。
「駅」という利用者単位で区切られる不連続体をコアに持つことで、それを中心としたコミュニティの形成を促進しやすくなりますね。

似た発想のサイトとしては、もう4-5年近く前からの老舗個人サイトになりますが、最寄り駅リンクKAMOTOWNというサイトもあります。
KAMOTOWNを改めて見返してみると、駅にまつわる話題の場所やサイトや口コミの共有等、4-5年も前からこんなサイトがあったのかと、発想の先進性に驚かされます。

Location Based Systemは今後どんどん重要になりますが、位置情報というのは生では扱いにくいのも事実で、適度な扱い易い範囲で取り扱えるようにするための基盤、Station Based Systemみたいなのも今後重要度を増すかもしれません。
経緯度や住所から近くの駅を検出して整理し易くするAPIとか、駅ベースで周辺情報を取り出すAPIとか。
いや、実は単にこの一節は、タグをつけようとして「station」と書くところを間違って「location」と打ってしまったために、思いついて何となく付け加えただけだったりしますが。

ゴールデンウィークは韓国に行きます。
いや別に行っても何したいとか特にないのですが（というかどうせ行くならソウルより地方巡りたいのですが、期間も短いし家内が田舎嫌いなもので）。
まあまた街ブラブラするだけかなあと。

でもまあ情報集めとくかと、韓国地図リンク集でリンクされていた韓国国内地図サイトの、Congnamulというところ開いてみたらビックリ。
以前、韓国の地図サイトをレポートして、ActiveXバリバリで使えんところばかりと書きましたが、普通にFirefoxでも開ける、Ajaxサイトでした。
やはり以前書いたVistaショックで、韓国のWeb業界も大分変わってきたのかもしれません。
また地図だけでなく、距離計測や面積計測等、便利機能もいろいろあって楽しい感じ。
位置情報付き口コミ情報も投稿できる等、CGM的要素も持っているみたいです。

▲ 徳寿宮の面積は62,650平方m、周囲をジョギングしたら1.1kmというのもすぐ分かる。 ▲
口コミ情報によると、ソウル広場は、冬はスケート場になるんだってさ。

自動車向けの経路検索や、歩行者向けの乗り換え検索等も充実してて、Googleトランジットで話題になった「場所から場所」への乗り換えにも対応、バスにも対応してた（というか韓国じゃバスに対応してないと話にならんが）。
ただ、経路検索は全国行けるみたいだけど、乗り換えはソウル→地方とかは結果が出ないみたい。
学生時代に行った「ソウル→春川」のバスルートを出そうとしたけど出なかった。
乗り合いじゃない高速バスとかは未対応なのかな？

▲ 光化門から今回泊まるCoExまでのバスルート表示。 ▲
最近の韓国のバスは、バス会社を問わずこのルート色と同じ一色で塗られ番号も大きく出ているので超便利。
ちなみに色は市街循環（黄）、幹線（青）、支線（緑）、広域（赤）というふうに分かれています。
しかし、我ながらソウルの土地勘むちゃくちゃあるな...スクロール地図でほとんどすぐ目的場所が出せる。

残念なのは、表示している地図面へのPermalinkが作れないこと。
中心位置の地図へのリンクは作れるのだが、なんか貼り付け用の簡易地図へのリンクになってしまって、自分が今見ているその画面へのリンクが作れない。
ちなみにその簡易リンクというのはこんな感じ（今回泊まるホテルの場所）。

いろいろ調べてみると、衛星地図の表示機能や、なんと日本語版（地図面まで日本語化されてる）もあるみたいなのだが、そっちの方はまだ手が回ってないのかActiveX版みたい。
Ajax化の予定があるのかは分からないけど、今後に期待。

ちなみに、Congnamulというのは、韓国語でもやしのおひたしのこと。
韓国料理でよくにんじんや大根や蕨、もやしなんかがごま油味付けのおひたしになって出てくると思うけど、それがナムルで、そのうちのもやしのナムルが「コンナムル」ですな。

寝ながらダラダラ考えていたら、表記の方法を思いついたので書いてみる。
もしかしたらよく知られている方法かもしれないけど、俺は知らなかったしググっても見つからなかったので。

といっても、1からではなくてベースはあるんだけど。
よく知られたライフハックに、紙を3等分する方法として、

• 紙を半分に折る（半分に折った折線をAとする）。
• 元の紙の対角線Bと、半分に折ってできた小さな長方形の対角線のうちBと交わるものCにおいて、BとCの交点を通りAに平行な線が紙を3等分する線D。
• Dに沿って紙を折った後、同じ大きさでもう一度折ると3等分の出来上がり。

▲ よく知られたと書きつつ、これもググってみたけど見つからなかったのでわざわざ作図しまつた ▲

というのがある。

なんでこれで3等分になるんだろう？と考えてたんだけど、考えれば当たり前で（というか当たり前だから正しく3等分されるので、というか何を書いているのか俺は）、

のようになり、3等分できるという原理。

ここで、最初の式を

と一般化すれば、

のようになり、紙をn等分及びm等分さえできれば、n+m等分することは定規なしで可能、ということになる。

m = 1とした上で n = 1、n = k + 1と考えてやれば帰納法であらゆる等分が定規なしでできることが証明されるし、実際にやる場合はn = 1からコツコツ折っていては紙がぐちゃぐちゃになるので、望む等分 = n + mを実現する適当なn、mを選びながら、手順が少なくなるよう折り進んでやればいい。

以上、一応念のため書いておくと、原理的にできることを書いただけで、この方法で折っていった結果、むちゃくちゃでっかい数等分しようとして折り過ぎで紙がよれよれになって使えなくなったとか、n等分する最初の1ヶ所の折り目は判るけど、後を同じ大きさに折っていくのが容易ではないので使えないとか、そういう突っ込みは勘弁してください。
もっと実用的なやり方で、任意のn等分する方法を知っている方おられたら、私も知りたいのでぜひ教えてください。

Googleトランジット（http://www.google.co.jp/transit）で、無茶な歩き方を指示される例をピックアップしてください。

これは酷い。
最寄り駅までの経路が適当に示されるのはご愛嬌かと思っていたが、確かに道路データを持っておらずに最寄（まさに自然障害など考えない距離的「最寄」）の路線データノードとの距離だけでルートを決めていたら、間に海等の自然障害が含まれるか、等の判定は無理なわけだからこうもなりますよね。
当たり前といっちゃあ当たり前。

というか、なんでGoogleは道路データと最短経路検索エンジンをサービスに組み込まなかったんだろう？
道路データも、別にZENRINの全国地図を買って無償でばら撒くような剛毅なGoogleさんにとっては、そんなたいした買い物ではないように思うのだが。
というかそもそも、歩道や一方通行やといったメタデータを持たない道路のネットワークデータだけなら、地図画像自体がZENRINからラスタ画像データではなくてベクタのシェープファイルデータでもらっているはずなので、道路のネットワークデータは抜き出そうと思えば抜き出せるはず。
メタデータがなければ変な経路検索結果になるかもしれないので、そのままでは結果として出せないかもしれないが、少なくとも裏でそれをするだけでも、海の上には道路データなんて存在しないので経路が引けず、海を渡るような無茶苦茶な結果を出すことはなくなるはずなのに。
契約上そんな使い方はできないということなのだろうか。

とはいえ、今はこんな感じだけど、どんどん改善してすごくなっていくんだろうな。
Google Mapsにしたって出た当初は、AjaxのグリグリUIは最初からすごかったけど、地図・GISサービスとしては俺みたいな素人（今は素人とは逃げられないが、当時）ですらあちこち突っ込めるくらい酷いもんだった。
それが今や、押しも押されぬWeb-GISの先駆者状態。
Googleトランジットも、今は酷いけどそのうちどこのサービスにも負けないようなレベルになっていくのだろう。

というわけで俺もGoogleトランジットを応援していきたいと思うのだけど、でも今のスナップショットだけを取り出せば、

Googleトランジットのはてブ

Google Mapsの時も書いたけど、なんかこのGoogleがやったからすごいに違いない、みたいなマンセーぶりは気持ち悪い。
お前ら比較できるほど普段乗換え検索使ってきたのかと。
駅⇔駅でなく、住所やスポット名で地点⇔地点の経路検索ができるサイトは別に今までだって複数あるし、そういうサイトは大抵最寄り駅から地点までの徒歩経路も検索できる。
海の上を歩けなんて結果は、間違っても出ない。
そしてそんな中では今のところ、（うちの会社もその手の1サービスやってるので、残念ながら、になるが）夜中に都内で中距離検索すれば「歩く」ことをリコメンドするような、コンテクスト解析までロジックに含まれているNAVITIMEが一番よいに決まってる。
今のGoogleトランジットなんか足元にも及ばない。

Googleを応援するのはいいし俺も応援してるけど、それと盲目的に何でもGoogleが一番、というのとは違うと思うけどなあ。

１枚の紙からミニ地図帳を作るALPSLAB printを公開

これはいいですね。
既にはてブもお祭り状態ですが。

こういうリアルを絡めたUIはすばらしいと思います。
以前のマッシュアップアワードでも、自分たちの作品はおいておいて、ブログ記事に取り上げたりしたのは「ケータイで位置情報」といううちのサイトど真ん中のdoodleとかが中心でしたが、リアルで友達とかと話した際に一番話題にしたのは、CALTA Projectの「MashMax -セールスガジェッツ-」の、「名刺切れ回避ガジェット」（名刺の持ち合わせがない時に、簡易の名刺をその場で作成してセブンイレブンのネットプリントで印刷するサービス）だったりした。
単に自分が名刺忘れること大杉、なだけかもしれませんが。

PCで調べた地図を持ち出すというとどうしてもPC版地図サイトでの検索結果をモバイル版サイトへ転送、とか考えてしまいがちですが、果たして既に判っている情報に対して、小さな携帯画面で見るのが便利なのかどうか。 目標が判っている情報については、やはり紙の方が使い勝手があるように思います。

もちろんその場での追加情報検索等はモバイルに軍配があがりますが、それも別に紙の片隅にその位置に合わせたモバイルサイトにアクセスできるQRコード印刷しておけば済む話です。

さらに言えば、モバイル版サイトの方からも、セブンイレブン/富士ゼロックスのネットプリントサービスAPI（上記セールスガジェッツが使っているもの）を通じて、セブンイレブン店頭から自由に今モバイルで検索しているエリアのオリジナル地図帳を印刷できる、というような展開も考えられるかも。

会社で部署に報奨金が出たので、それを原資にすき焼き宴会をやって参りました。
とりあえずこんな機会なので、報奨金だけでなく自腹を加えてでも、いい肉食おうと、超有名肉料理店の特上すき焼きを注文しました。
しかも「他の食いもんなんてどうでもいいから、とにかく肉、肉！」ということで、コースも頼まず単品すき焼コース。

正直言って、食べてみるまで個人的にはあんまり興味はなかった、というかあんまりグルメとか何とか好きになれないのでタカを括っていたのですが、食べてみて本当に「うおっ、これは違う」と思いました。
確かにむちゃくちゃおいしい、グルメレポーターの表現そのままでアレですが、ほんまに、口に入れると下の上でとろけます。
焼けば固くなる普通のすき焼きとは全然違う、全く別の食べ物。
確かにこれは、いっぺん味わってみるに越したことはないです。
感動した！

とはいえしかしまあ、一度経験しておくのは新しい世界を知れてよかったし、家内や息子にも機会があれば体験させてやりたい、とかは思うのだけど、高い金払って自分がもう1回食べたいか？と聞かれるとうーん、という感じ。
同じ類の食べ物で上質になっているというのならば、できればおいしいのを食べたいとは思うけど、食感も何もあまりに違いすぎて別の食べ物になってしまっているだけに、これはこれでおいしいけど普段の肉だってあれはあれで別の食べ物としておいしいし、特に特上肉でなければダメか？と言われればそんな事は全然ない。
中国行った時に蠍食ったりしたけど、ああいうのと同じで一度経験しとけばいいというような。まあ、蠍はまずかったのに対しこっちはうまかったけど。

もちろん誰か金出してくれて食べられるとでもいうなら喜んでいくけど、いっぺん経験した上で次同じ自分の金出すなら、俺なら陳麻家の激辛陳麻飯に山椒とラー油とガーリックチップ山盛りかけて食すのを、腹いっぱい何度も食う方がいいや。

あ、ちなみにぐるなびとか見てこの店行く人は気をつけて。
さすがに高級店だけあって、ぐるなびページ上では載っていない（か、載っていてもどこに書かれているのかよく判らない）部屋代（うちの場合今回は6,000円だった）やお通し代（1人350円）が、ぐるなびに書かれている値段以外にかかります。
うちの場合聞いてなかったので余裕で予算オーバーしたので困っていたら、説明不足だったということで部屋代は負けていただきましたが...。

携帯サイトのSEO対策やってまして、挙動を追っているいくつかのクローラのうち、1つを除いては順調にクローリングされて順位にも反映が出ているのですけども。

1つだけ、某クローラだけが、うまくクローリングしてくれない。
そもそもサイトへの訪問頻度が極端に少なく、1ヶ月に1、2回しか来てくれないのもどうなのよ、と思うのだけど。
先日久しぶりに来てくれて、さあ今度こそ、対策万全のディレクトリをクローリングしてくれるか！とｗｋｔｋしていたら、またディレクトリを無視して去っていく。
何やねんそら！

さすがにおかしいと思い詳細にログを調べてみたら、クローラの変な特性が判った。
URLの末尾がindex.htmlだった場合、そのクローラはそれを削除したURLにアクセスするようになってるみたい。
例えば、

http://foo.example.com/bar/index.html

の場合、クローラは

http://foo.example.com/bar/

にアクセスしてくる。

普通の構成なら問題ないんだけど、うちの一部ディレクトリの場合、実際には動的ページにも関わらずmod_rewriteでindex.htmlに見せかけていたので、それを外すとNot foundになってしまい、結局全くクロールされない、という状況になっていたのだ。

気付いたので対策できるものの、訪れてくれるのを待ち続けたこの1ヶ月近くはどうしてくれるのか。
ウザい、ウザすぎる仕様だ。
とりあえず名指しすると色んな方面でヤヴァい気がするので、「某クローラ」に止めておくけど、自分たちのサイトの深いところを某クローラが来てくれないよう、ということで悩んでいる人がいれば、一度チェックしてみた方がいいかもしれない。

ちなみにこの公式クローラ、もう一つ面白い？性質があるみたいで、普通アンカータグでのリンクではなくFORMでのリンク先なんか検索エンジンはこないよ、と思うんだけど、テキストボックスみたいな不確定要素のFORMではなく、SELECTタグのような確定された複数要素のみのFORMでかつGETの場合は、辿ってくるみたい。
これも別に来るんなら来れば？とか思うけど、そんなとこ来るとは思っておらずSEO対策もしてないので、それはそれでまたウザかったりもする。

OpenID をブロガー向けに分かりやすく説明すると？ -Goodpic-

判りやすいし、面白かった。
でも個人的に面白かったのが、

僕は、Goodpic.com というブログを書いている本人です」ということを証明できたら、ネット上の色々なサービスを登録しないでも使えるようになるってこと？ 今流行のブロガー優待(wみたいな感じ？

要するに「自分がこのサイトの作者だよ、ということを自分のIDとして使う」という発送を、たくさんの人が違和感なく受け入れている、ということ。

OpenID自体は、http上のやり取りだけで分散によるID認証システムを設計する上での必然、というか必要悪としてURLをIDとして採用しているのだと思う。
できることなら設計している人達もメールアドレスとかをIDとする形でやりたかったんじゃないかと思うし、実際OpenIDのMLとかでも、OpenID推進者の人達が近くの友達にOpenIDを紹介したところ、「私というアイデンティティは、Webサイトなどに投射される物ではない」といった形で批判的な反応を返された、といった話が、一度でなく数度話題に上った記憶がある。
やはり一般ユーザにとっては、ネットワーク上で自分のアイデンティティを代表する物は、Webサイトアドレスではなくメールアドレスであると考える傾向があるみたい。
Webアドレスにしろメールアドレスにしろ、所詮ネットワーク上でのノードを表現する一形態に過ぎないのだけど、やはりWebサイトアドレスは、自身のアイデンティティの投射として考えた場合に

• 全ての人が持つわけではないノード
• ブログでのコメント等もあるにせよ、基本的に不特定多数への情報発信オンリーのノード
• ノードが一意でなく多様となる問題。例えば、Bobさんのアイデンティティの投射と考えるべきノードはhttp://bob.example.com/なのかhttp://bob.example.com/profile.htmlなのか、とか。

といった問題があるのに対し、メールは

• 基本的にネット上の住人なら、まず持っているとみなしてよいノード
• 公開情報から秘匿情報まで、情報の受信にも発信にも利用できる終端ノード
• 基本的に一意なノード

といったよりアイデンティティと重ねあわせやすい特性があるので、普通はやっぱりメールアドレスなんかの方をアイデンティティの拠り所として考えるんだろうなと思う。

ところが、はてブを使いこなしたりしているはてなコミュニティの人なんかから見ると、大半の人が自分のブログも持っているのだろうし、ブログを通しての他者とのコミュニケーションにも当たり前になれていて、というふうにどっぷりブログ文化に染まっているために、自分のアイデンティティの拠り所としてブログのURL、という発想も、普通に受け入れられるのだろう。
ここらへん、OpenIDで採用されているIDとしてURL、という部分を、すんなり受け入れられるか否かで、ネット社会上での一つのディバイドがあるんじゃないかな、とか思ったりする。

そんなこんなで、どの程度取り組まれているのかわからないけど、OpenIDのMLなんかでも、メールアドレス的なuserid@ドメイン、形式のIDが使えないか検討している人がたまに出てきたりもしているみたいだけど。

でもまあ、個人的な印象では、日常生活でも、アイデンティティの証明って言うのは、運転免許証やパスポートとか、そういったもんでやりますよね。
それは、別に「私は運転免許証です」「私はパスポートです」等といったことを証明しようとしているわけでは当然なくて、その上に記載されている氏名や生年月日みたいなアイデンティティ属性を証明するための、言わばアイデンティティの箱舟みたいな感じで用いられているわけですよね。
それと同じで、OpenIDでのログインも、単に機能がログインだけだとそのURLが自分のアイデンティティを投射したもの、という感じだけど、そうではなくて、そのURLでログインすることでログイン者の氏名等の属性を認証されたデータとしてログイン先に送る、運転免許証やパスポートと同様のアイデンティティの箱舟の役割を果たすようになれば、また人々の受け止め方も違ってくるのかな、という気もする。
実際、OpenIDでも、そんなアイデンティティ属性交換の仕様は定められている。

たとえば、普通のログインシステムでは、同じ名前は2つ存在できないわけだけど（bobというアカウントは既にあるので、bob34910にしてください、とか）、OpenIDだと、自分の使いたいハンドルネームというのが交換される属性としてあるとして、http://bobsmith.example.com/でログインするbobと、http://bobking.example.com/でログインするbobが、同じシステム内で同じハンドルネームで共存できるとか。
そんなふうになれば、飽くまでアイデンティティはログインすることによって交換される愛称「bob」であって、http://bobsmith.example.com/自身がアイデンティティではないということになり、一般人にも受け入れられやすくなるかもしれない。

そう言えば、マッシュアップアワードで作った禁煙レストランですけど、俺の作った携帯版の方、当初はDoCoMoのiエリアからの検索アクセスがあった場合は、iエリア毎のランディングページ作って、そのiエリア内に属するHotPepperのエリア一覧を出して、検索したいエリアをユーザに選んでもらって検索結果を表示する、という形にしようと思っていたんですよ。
iエリアみたいなエリア情報に対して、地図を出して中心からの近隣店舗検索だと使いにくいですからね。
結局、時間なくて、iエリアからでも広域地図に落とす形にしてしまいましたけど。

で、それをやろうとしたのはいいものの、DoCoMoのiエリアとHotPepperのエリアの対照表なんてどこにも用意されてないし、手作業でなんかやってられねえ世界なので、どうしようかと考えた挙句、HoｔPepperのAPIを回して各HotPepperエリアの先頭100店舗とかを得たうえで、それぞれの店舗がどのiエリアに属するかを算出し、その相関関係で大まかなDoCoMoのiエリアとHotPepperのエリアの対照を作ろうと考えた。
なので、そういう目的で、一度HotPepperの全国全エリアを舐めて、店舗を100件ずつ取得したことがある。

それで気付いたのが、APIの仕様書で、HotPepperが提供している地域エリアは全国にまたがっているのだけれど、店舗検索してみたら1件も店の登録されていないエリアが、田舎を中心としてかなりのエリア存在する。
これには驚いた。
天下のリクルートのサービスだし、そして実際に日本中のエリア分けが提供されているのだから、コンテンツも全国そろっている物だと思っていたら、意外にも揃っていなかったのだ。

これに気付いた経験で、Web-APIの提供というのも諸刃の剣だなあ、という思いを抱いた。
Web-APIを提供することで、いろんな人にマッシュアップしてもらい結果自サイトへの導線を増やすという利点も間違いなくあるのだけど。
でも一方で、自分たちの持つコンテンツへの簡単なアクセス方法を提供してしまうことで、自分たちのコンテンツの弱い部分等の情報についても容易に外部から判る形になってしまうという、危険性もある。
もちろん、別にAPIで提供していなくても対人Webで公開しているだけでも、調べる人が調べれば弱点解析とかは可能なわけだけど、そのアクセシビリティが全然違う。

API、特に機能ではなくコンテンツ開放系のAPIを作ろうとされているところは、その辺も意識された方がいいのではないか、と思いました。

Googleトランジット

さっそく遊んでみました。

出発点・到着点は住所等文字列からしか選べず、せっかく地図があるのにその上からは選べないっぽいのですが、面白いのは似た地名があった場合、出発点・到着点間の距離を見て、より近い地点間の経路を出しているっぽいこと。

例：

西神田⇔福岡：下関市の西神田が選ばれる。

西神田⇔五反田：千代田区の西神田が選ばれる。

これはなかなか面白いです。
おせっかいというか、便利かどうかというと微妙かもしれませんが、そういう発想はなかった。

面白いというと、徒歩ルートと乗換えを含むルートを出す場合、徒歩ルートの表示がやたら投げやりなのに比べて、鉄道に乗ってからの経路が、乗車駅から終着駅まで全部鉄道に沿ってラインが引かれるし、途中駅内の乗り換え経路も含めやたら細かい。

▲ やたら投げやりな徒歩ルート部分 ▲

▲ 駅内経路までやたら細かい ▲

一緒に見てた同僚あたりは、位置情報サービスを長くやってきたプロな人だったりするのですが、普通徒歩の方のルートをしっかり書いて、乗ってしまえば終わりの鉄道経路なんてすっ飛ばすのが普通なのに、真逆で面白いねえ、等と言っていました。

しかし、ジオコーダが相変わらずの「Google様がココといったらココなんだ」調。
上で検索した西神田⇔福岡でも、「福岡」といれたら福岡県と解釈されるんだけど、

福岡県

それは一体どこやねん！

まあ、ジオコーダの独特さはご愛嬌なんだけど、サービスとして致命的っぽいのは、このようにジオコーダがかなり癖があるにもかかわらず、せっかく表示される地図上でその出発・到着地点を微調整できないこと。
これで正確に自分の望む出発・到着点を指定するのは、正直厳しい。
この辺は改善していって欲しいなあ。
あとは、徒歩ルートも。是非。何卒。

最後に変な事に気付いたんだけど、乗り換え検索をした後、経路がテキストで表示される左側の画面で、出発点・到着点が表示されるブロックが、何故かマウスでドラッグできる。

別にどこにもドロップできないし、また出発・到着点以外は全く掴めないのだけど、これは何なのだろう？

---- 追記 ----

その後、さらにいろいろ遊んでみましたが、よく見るとジオコーダのマッチング結果が、プルダウンメニューで選べるようになっていましたね。
「西神田」も、デフォルトで選ばれるのは一番近いところですが、プルダウンを見るとちゃんとマッチするところ全部選べるようになってましたし、「福岡」も、福岡県はやっぱり「どこやねん」という感じなのですが、「福岡県福岡市」「福岡県北九州市」等がプルダウンで選べるようになっていました。

これならば、これはこれで十分使えそうですね。
せっかく優秀なGoogle Mapsインタフェースがあるのだから、やっぱり地図で微調整できた方が嬉しいけど。

今週じゃなくて先週の話題なんですが、家族で大江戸温泉物語というところへ行ってきました。

お台場で、東京テレポートから無料バスでまだちょっと行った先という、ちょっと遠いところなんですが、なかなか楽しめるところでした。

まず雰囲気作りがいい。
着替え場が2箇所あるんですが、まず入館すると綺麗な浴衣を渡され、最初の着替え場で服を脱ぎ荷物をおいて、浴衣に着替えます。
この際、私は2つ悩んだことがあって、

• 子供の浴衣姿とか写したいんだけど、カメラ持って入っていいの？
• 中にはパビリオンがあると聞いてるけど、財布は持っていく必要があるの？

というあたりでしたが、結論を書くと

• カメラは全然OK。中の人に頼めば撮ってくれるし。
• 財布は全くいらない。通行手形に付いているバーコードスキャンで最後に一括清算。プリクラすら通行手形で専用コイン払い出して使う。

という状況でした。

浴衣を着て中に入ると、江戸の街の雰囲気を模したパビリオン群が並びます。
射的屋やあてもん屋、食べ物ではあんみつ屋やそば屋、すし屋等、いろんなパビリオンで江戸情緒が楽しめました。
イベントもいろいろあり、メンコやベーゴマの体験、大道芸、お菓子・おもちゃの袋詰め放題等、企画物なのでいつもやっているかは判りませんが、子供も楽しめるイベントが30分から1時間に1つは行われていて、なかなか楽しめます。

▲ メンコ体験 ▲
俺の地元では「パッチン」と呼んでたなあ。

▲ ベーゴマ体験 ▲
もともとこの手の勘がない上に、次のイベントまで残り15分くらいのところで飛び込んだものだから1度も回せず。

肝心のお風呂ですが、家族みんなで楽しめるお風呂として、浴衣のままで入る屋外の足湯があります。
メインのお風呂はさすがに混浴ではなく男女別で、ここでもう一つの着替え場があり、浴衣を脱いでタオルのセットをもらい、湯に入ります。
湯はメインの温泉、薬効みたいなのを溶け込ませた湯、ジェットバス、サウナ、水風呂、露天などメジャーどころは揃えている他、面白いところでは絹湯という、湯は普通の温泉湯なのですがマイクロナノバブルを発生させているために牛乳みたいに白濁してて、中に入ると石鹸等使わなくても皮膚の汚れが落ちる、というのがありました。
やっぱり子供にはこれが面白かったみたいで、息子は家内と女湯に入ったのですが、やっぱり子供はみんな集まって絹湯周りで遊んでいた、という事でした。

そんな感じで、湯に入って上がってゆっくり楽しんで、で2時間くらいいたのですが、湯を上がった後子供がいろいろ遊ぶのに付き合っていたらさすがに疲れてきて、もう一度湯に入りたい気分になりました。
無料バスの時間があったため出てきましたが、本当は最後にもう一風呂あびて、3時間コースくらいで楽しむのがいいかもしれません。
あ、そうそう、結構金もかかります...家族3人で入場だけで7,000円強、中で食事もしておらず、ジュース飲んでアイス食べて、遊び体験3つほどとプリクラやっただけですが、それでも3,000円弱、あわせて10,000円ほどで、2時間でもちょっとした近場の日帰り旅行くらいの額はかかります。
ディズニーランドとか行く事に比べれば全然アレですが...。

不満と言うか、温泉系に家族で行けば当たり前なんですが、男女に分かれるので子供はどちらかにしか付いて行けず、せっかく家族で楽しい体験に来ているのに、子供が面白いことをした、可愛いことをした、とか言っても、片親しかそれを見ることができず一方は伝聞にならざるを得ないことですね。
かといって家族風呂みたいなところでは（大江戸温泉でも、泊まりになりますがそういうところはあるみたいです）、狭くてせっかく温泉の気分が味わえない。
以外と、家族でみんなで広々と温泉を楽しむ、という視点で、混浴温泉というのにニーズがあったりもするかなあ、とか思ったりもしました。

歩行者が持っているGPS携帯電話とカーナビの持っている双方の位置情報を把握し、事故になりそうな状況で警告を発するシステムのようです。

へえー。面白いこと考えますねー。

今のGPS携帯電話の測位精度だと、誤差が大きくてなかなか難しいと思うのですが、精度アップで対応するのか、現行の精度のままで違ったアイデアがあるのか気になる所です。

今のGPS精度では無理でしょうね。
測定に時間がかかりすぎるのと、精度が道路の車道にいるのか、歩道にいるのかも区別できない程度の精度ですから。

ですが、GPS精度向上のための技術も、いろいろ開発されつつあります。
よく知られているのでは準天頂衛星から、あまり知られていないですけど個人的に超有望かなと思うのでは、北日本放送等が実験をしている、ワンセグ電波の空きデータ領域にGPS補正電波を載せる、という技術もあります。
この技術をGPSに適用すると、10m近くはあるGPSの誤差を1m以内の誤差に押さえることができるので、道のどちらの歩道をあるいているか、というようなレベルでも判定できるようになるので、最初の記事のような事故防止の用途にも使えるのではないかと思います。
この技術開発、知人が一部絡んでいて、その知人から聞いただけの話でネットとかで検索しても裏付け情報がないので真偽のほどは判らないのですが、なんでもこの技術を使った、無人の田植え実験機みたいなものも作られていて、実験で数cmの誤差しか許されないような田植えの自動化も実用化可能であることが示された、というようなことも聞きました。

また、今のケータイにはGPSだけでなくワンセグの受信装置も普及しつつあるので、その意味でもファームウェアの書き換えだけでおそらくワンセグ補正技術にもたいおうできるだろうということで、有望な技術と言えます。

もっとも、個人的考えでは、やっぱりGPSは測位に時間がかかるし（それを速くしようと思えば高いCPUパワーが必要となりデバイスが高価になる）、いかに正確になったといってもその時その時の揺らぎは存在します。
現在の歩行者ITS研究等では電子タグが主流なのは、やっぱり電子タグの情報伝達速度と情報のスタティックさが買われているのではないかと思います。
しかし、問題はやっぱり位置情報が付与された電子タグインフラの整備・維持ではないかと思います。

そこで、個人のアイデアとしては、ユーザにすばやく正確な位置を通達する役目はITタグに譲りつつも、そのITタグ自身に正しい位置を教え込ませる手段として、高精度化GPSは使えないかなと思います。
位置を覚えさせたICタグを維持・管理するのは大変ですが（間違ったところに設置とかできないし）、例えば点字ブロック等の路上に配置する地物に、ICタグ機能だけでなく自分でGPS及びワンセグ補正電波を受けて自分の位置を算出するチップを搭載しておき、その地物を管理する必要はなくただ配置すればさえ、自分の配置された場所を自動で覚えて後はそれをICタグから発信する、という形にすれば、インフラ管理の手間が大幅に削減されると思います。
別にすばやく位置を算出する必要はなく、配置された後たっぷりある時間を使ってゆっくり計算すればいいのですから、CPUパワーもそんなにいらないし、ずっと一箇所で測位を続けて時々の揺らぎも平均化させることもできますから、高精度GPSでの誤差をさらに小さくすることもできる。
自分で勝手に位置を覚えてくれるので、管理の必要もなく、大量生産したものを何も考えずに配置できるし、一度配置した地物を別の場所に再配置することだってできる。
電力はそもそもずっと情報を発信するICタグを配置するのでしたらどこかで供給する方法を検討するでしょうから、そっちはそちらの検討に任せておけばいい。
また利用するデバイス側も、直接高精度GPSを受信するデバイスより遥かに簡単で安価な技術で実現可能になるので、例えば視力障碍者の杖等にも簡単に組み込めるようになる。

というわけで、高精度GPSは、位置情報インフラとして直接使うことにも可能性はありますが、もっと高速で安価なインフラに効率的に位置情報を付与するための、メタ位置情報インフラとして使える可能性があるんじゃないかなとか、今考えています。

数ヶ月前にようやく補助輪を外して練習していたのですが、３回目の練習で乗れるようになりました。一度も転けずに乗れるようになるとはちょっと意外でした。

おおー！
おめでとうございます！

奇しくも、うちの子も今日、乗れるようになりました！
と言っても、親に押してもらわなくてもキックスタートできるようになったのと、公園半周くらいはなんとかこけずに乗れるようになったくらいで、そちらの動画の最後での滑らかな乗り方を見る限り、同じレベルで乗れてるとは言い難いのですが、せっかくなのでとりあえず同じ日に祝っておきます。

▲ 動画を張らずに動画切り出し画像なのは、▲
カメラワークがヘタクソで乗れているところの画像がほとんど首上映ってないのと、
品のない親父が「気合入れて乗らんかー」等と口汚くどなる声が入ってるから。
支えハンドルにゴミ袋、下げるなよ...

ちなみに、うちもいきなり自転車だったりします。

三輪車パスして いきなり自転車II マンゴー&ホワイト posted with amazlet on 07.04.23 ピープル 売り上げランキング: 31844 Amazon.co.jp で詳細を見る

しかし、やっぱこういうのも得意不得意が出るようで、うちの子はだいたい4回目か5回目くらいで乗れるようになったのですが、先日公園で一緒になった息子の同級生の男の子は、息子の自転車を貸してやったら、コマなし自転車乗るのは初めてと言っていたのに、数分で一回目で乗れるようになりました。

というか、うちの子体動かすの嫌いすぎ...（いや俺が言えるアレじゃないが）。
今日も、自転車とサッカーボール持って出たんだけど、自転車の後はサッカーボールには興味を示さず、えんえんと砂場遊び。
その間親は、所在無いサッカーボールに興味を持った近所の小学生に狩り出されて、1時間半ひたすらパス練習...疲れた...
なんかほとんど毎回よその子と遊んでて、サッカーボールでうちの子と遊んだ記憶がほとんどないぞ...。

ホリエモンとかもやってたみたいだけど、よく聞く「辞書や事典を通読する」というヤツ、あれやっぱ効果あるみたいですね。

うちの家では、大したレベルではないですが、まあ教養系というか雑学というか、その手のことでは家内より俺の方が（我が家内比）詳しくて、平成教育委員会とか見ててもたいてい俺の方が家内より先に答えられていたんですが。

この1年半ほど、家内が言語学のコーパス作りのバイトに出てまして、岩波、新潮、広辞苑、国語大辞典の4冊を紙媒体でも電子媒体でも、日々最初から最後まで読み返しては単語を洗い出す、ということを仕事にしていたんです。
そしたら、ここ最近、漢字や国語系の問題は完全に適わなくなってしまいまして。
というか、答える速度で適う適わない以前に、あちらさん完全に百問百答状態なので手も足も出ない状態。
なんで急に詳しくなったの？と聞いてみたら、先のバイトのせいで毎日言葉を見続けてたら、嫌でも覚えるという話。

自分の性質として、目的達成に必要な最低限の知識を効率よく、という典型的勉強嫌いの怠け者体質なもので、趣味や好きなもの以外は通読とかそういうのはほとんどした事がないのですが。
自分の性質としてやれない以前に、そもそも目的の存在しない努力にそれほどの効果があるのか、というあたりに疑問を感じていたりもしていたのですが、その点に関しては本当に効果があるらしいことを家内が証明してくれました。

ちなみに、こちらが家内のバイトの成果物の模様。
当然、バイトなので著作権者には載ってませんが。

無医地区の、無医地区たる理由は、診療所の個人経営が成り立たない地域だからでは無く、医師の子弟の教育が困難なわけでも有りません。そこの地域住民が悪い、殊に、自分が有力者だと思い込んでいる首長、議員、町内会長、大地主、資産家等が、馬鹿な要求や他所者扱いや三流医師扱いをするから、医師が嫌がって地区を出て行くだけの事なのです。　本質的には、その地区出身の若者がいなくなるのと全く同じ理由なのです。

なのだそうです。

部外者なので真偽のほどは判りませんし、というかもしそうだとしても一律全部どこでも同じではないだろうとは思いますが、とりあえず真偽判断は読まれた方に任せるとして、いろんな人が一度目を通した方がいい文章かなと思ったのでリンクします。

しかし、なぜそれでは普通のブラウザーで見てもリダイレクトされないのだろうか。Amazonは User Agent をきちんと見ているのである。
　　　.........
Amazonにbot認定されているUser Agentはリダイレクトされる。デフォルトではリダイレクトなしだが、botのみリダイレクトするホワイトリスト方式である。

ぶっ飛んだ。

検索クローラと一般アクセスとの間で振る舞いを変えるのは、SEOの封じ手というか反則技なんじゃないの？
どこで情報集めても、そういうのはスパムSEO対策としてサーチエンジンから八分にされる可能性もあるとなってるんだけど。
そのせいで、ヘルプページとかのクローリングさせたくないページとかで、動的に対応変えてよいのならリンク切っちゃえば済むだけのことを、動的なんでrobot.txtも使えないし、メタタグやマイクロフォーマットのnofollow,noindexはどこまで対応しているのか判らないし、とかで頭悩ませたりしてるのに。
（等と偉そうに言えるほど、「インデックスされない」ための対策はあまりマジメにガチガチにはしてないけど...ごめんなさいごめんなさい）

上記エントリのはてブ

クローキングも内容が違うとかじゃなきゃOKなんだろうな。どのアドレスも公開されているわけだし。筋の通らない話ではないからなぁ。

あ、そうそう、クローキングとかいうんだっけ。
怖いのはクローリングのロジックはブラックボックスなので、Amazonがやっているからとこれを信じて同じ対策をした結果八分にされても、誰も責められないことだ。
内容が同じと言ったって、実際に振る舞いを変えている以上、全て同じかなんて誰も証明できないのだから難癖つけられる可能性は否定できないし、一旦難癖つけられたら主導権はサーチエンジン側にあるので、苦情が受け入れてもらえるとは思えない。
だから最悪八分にされても悔しい程度で済む個人サイトとかならともかく、業務としてSEOやってたら、絶対に真似できない（誰かが責任持ってOKと保証してくれたらするけど）。

というか、Amazonもこんなグレーなことするくらいなら、内容が同じだと言うなら対人でも一律リダイレクトさせればいいのに。

会社でいろいろ解析していて思ったこと。
瞬ワードみたいなのやってみたい。すげえ面白い。

というか同じこと思ってるのは俺だけじゃないので、後は目的とゴールを固めさえすれば実現可能だろう。
テクノロジーセントリックな会社なら、とか何とか言ってる暇があれば形にしちゃうのだろうけど。

一昨日、恥を晒したおかげでいろいろ有益なことを教えてもらったので、調子に乗ってもう1件。

sendmailしか、しかもWeb-UI経由でしか触ったことのないスクリプトキディなんですが。
基本的に、9年間の社会人生活中、現場の技術者だったことは3年ほど前に1年半弱しかないので、いろいろ自分が余暇でやりたくてやってきたことに必要な技術以外はスクリプトキディの域を出ていません。

もうすぐ新しいサーバに移るのでそっちの環境構築をしてるのですが、弾さんのこの記事を読んで、をを面白そう、せっかく乗り換えるんならこの際qpsmtpdとSPFも導入してみるか、とか思いました。
Mattさんのチュートリアル見ても簡単そうだったし、いっちょやってやるか!と試してみたんですが...。
うまくいきません。しかもすごくたくさんのトラップにひっかかってるっぽい。

状況を書く前にまずやりたい事を整理すると、qpsmtpdを使って、

最低限やりたい事：

• うちのISP（so-net.ne.jp）からのメールは受け取って、後は中継しないsmtpサーバが立てたい
• 送信、及び受け取るメールのドメインは、私が管理しているkokogiko.net、saesparam.com、tarokaja.com、yadis.jpの4つ

できればやりたい事：

• SPF対応
• プログラムへのメール転送（正規表現等で転送対象メールを指定できるとなおよい）

ができれば嬉しいのですが。

状況１：

まず、Mattさんのチュートリアルを見ると、ダウンロードしてきて

./qpsmtpd-forkserver -u $USER

さえすれば、2525ポートで起動するよ、と書いているのですが、まずこれができない。
-uオプションでユーザを指定してやっても、なんかSpoolフォルダとかいうのを「コマンドを実行したユーザ」のホームディレクトリの下にtmpという名前で作ろうとするので、パーミッションに引っかかって落ちてしまう。
仕方ないので、-uで指定したのと同じユーザ（smtpd）でログインした上で、実行してやるとなんとか起動はする。

状況２：

2525ポートでは起動できたということで、ポート25で起動しようとすると、smtpdユーザだと「0.0.0.0の25ポートにBindできません」とエラーが出て起動できない。
これはqpsmtpdというよりサーバ側の何かの設定の問題っぽいなと思いはするけど、よく判らない。
仕方なく、rootになって、

./qpsmtpd-forkserver -u root -p 25 -d

としてとりあえず立ち上げてみる。
これだと25番ポートでも問題なく起動。

状況３：

とりあえず家のPCから接続しようとしても、リジェクトされまくる。
これに関しては、relayclientsの設定に、今の家のルータにISPから提供されているIPアドレスを書き込むことで、とりあえずリジェクトされないようにはなったけど、ISPからのIPアドレスって固定じゃないし、いちいちIPが変わるたびに追加なんてしてられない。
どのような範囲でIPアドレスが割り振られるか、ISPに問い合わせないといけないのか。
sendmailみたいに、ドメイン単位で中継の許可/不許可を設定できないものか。

状況４：

とりあえず、今移転先の準備中サーバには、kokogiko.net以外の管理ドメインの1つ（yadis.jp）を割り当てて設定しているのだが、最終的にはkokogiko.netになるので、meやdefaultdomainの設定ではkokogiko.netを設定している。
でも、他のドメインでも使うので、plusdomainやlocalsといった設定には全ドメイン名を設定しているのだけど...。
にも関わらず、配送テストをしようとしてyadis.jp上のメールアドレスを送信元にすると、「Unresolved yadis.jp」とか何とかいうようなエラーが返って、送信リクエストが受け付けられない。

状況５：

kokogiko.net上のメールアドレスを送信元にすると、とりあえず受け付けてくれ、メールクライアント上でも「無事送信しました」みたいな返答が返ってくる。
ところが、送信を受け付けてくれたにも関わらず、gmailに送っても携帯アドレスに送っても、待てど暮らせど届く様子がない。

というわけで、全くのお手上げ状態。
もうsendmailでいいか、とも思ったけれど、判る人がみれば何かアドバイスももらえるかなあとか思って、とりあえず状況を晒してみた。

ドラマ開始後のエントリとなったが、マンガの方。
といっても今頃書くくらいだから初めて読んだのはドラマ開始直前だけど。

これ面白い。
カイジやDEATH NOTE以来の、あの手の方向のおもしろさ。

特にすごいなと思わせるのが、伏線の細かさ。
カイジにしろDEATH NOTEにしろ、細かいところを気にするとそれはご都合主義だろうとツッコミを入れたくなるところは結構あるけれど、それらと比較してLIAR GAMEはツッコミどころがずば抜けて少ない気がする。
そんなご都合主義的な...とか、矛盾してるとか思うところも、後で読み返してみると自分が読み飛ばしてたり読んでても意識から消してしまってたりしただけで、読み返すと大抵ちゃんと説明がなされてたり、伏線が張ってあったりする。
構成がすごく緻密。

あと、争うゲーム構成が、きちんとした囚人のジレンマ的に、全員が協力すれば全員が生き残る、といった形のゲームになっているのがいい。
このゲーム構成だからこそ、最後に勝ちを収めた後自分の考えを貫こうとする、カンザキナオのバカ正直さが生きてくる。
でもそのバカ正直さを貫くのも、まずは勝たなければ糞の役にも立たない、という展開も、非常に示唆的だ。
まさに力なき正義は無力、正義なき力は暴力といったところ。

やたらと心理描写を引っ張るカイジなんかと違い、展開が速いのも非常に好感。
1つのゲームがほぼ単行本1巻で終わり、それでいてストーリー展開に心理描写等含め無理がない。
読んでいて爽快だ。

この手の心理ゲームものが好きな人には、お勧めの一冊。

LIAR GAME 1 (1) posted with amazlet on 07.04.19 甲斐谷 忍 集英社 (2005/09/16) 売り上げランキング: 194 おすすめ度の平均: うーん。。。 騙して勝つ！本格心理ゲームの真骨頂 ONE　OUTSの次は Amazon.co.jp で詳細を見る

愛読中ブログの記事から。

人の頭のカビを嗤ふ前に自分の頭を除菌したまへ。-女性専用車両を頑なに利用しない埼京線の女性客の姿に「痴漢は単なる都市伝説なんだなあ」と日々痛感する?犀淨庵鬱日記-

当該規定をそのやうな文脈で理解することは、「カビの生えた保守層」とやらの頭にあるのと同一のカビが自分の頭に巣食つてゐることに他ならない。書き飛ばす前に立ち読みでもいいから家族法の本の該当箇所を読むべきではなかつたか*1。
　　　......
*1：「嫡出推定　意義」とぐぐるだけでも随分違つたものが書けただらう。

嫡出推定というのの意義は知らなかったので、ググってみたら

嫡出推定の意義 -Cases and Materials-

1　生殖医療に関する問題
2　事実上の養子に関する問題
　　......
大雑把な言い方をすれば，嫡出推定の規定は，子の「父」の欄が空欄になることを可能な限り防止して，扶養や相続に関する子の権利を守るための規定なのです。

なるほど、現行規定の意義は判った。

でも、その意義で語られているようなのは、（保護されるべき係争が発生する事態になるところまでを想定すると、）極めてレアケースだと思うんですよね。
レアケースを救う必要はないと言うのではなくて、そのレアケースを掬う規定のために別のレアケースが不利益を蒙っているのならば、それを掬うために規定の見直しや柔軟運用はされてしかるべきだと思うんですよ。

高田・向井夫妻のケースなんか、上の嫡出推定の意義で書かれたケース（遺伝子他人、出産本人）の真逆のパターン（遺伝子本人、出産他人）の生殖医療レアケースなわけですし、前者が掬われて後者が切り捨てられる必然性は全くないと思うんですよ。
離婚後300日規定の話にしたって、実際に暴力絡みとかで前夫と別れたために非協力的で、子供が戸籍を取れず（父の欄が空欄になるどころの騒ぎではない）、乳児医療制度すら受けられないケースもあるわけですよね。
全く子の権利を守る方向で考えられているとは思えません。

不利益な立場に立たされた者を守るために規定があるというのならば、その規定のために別の不利益に立たされた者が生じたならば見直されるのが意義・理念上は当然なわけで、それを見直さない、ましてやその理由を語る言葉の中に「貞操」とかなんとかその規定の元の意義・理念と関係ない言葉を潜り込ませてくるような政治家は、やっぱり頭にカビが生えていると見られても仕方ない気がします。

YAPC懇親会でにぽたんがゲットした事で有名なHigher-order Perlですが、著者の方のプレゼンが面白くまたパーサにも興味があったので、高かったし積読必至ですが買ってみました。

そしたらこれ、英語がすごく読み易い！
表現が上手なんでしょうか、英語の苦手な私でもすらすら頭に入ってきます。

私が読んだ中で一番英語が読みやすかった技術本はこいつでしたが、それと比べても遥かに読み易い。

というわけで、中身はまだ一部しか読んでないし、そもそも恐れ多くも評せられるレベルにないので講評できませんが、英語が読みやすいという一点で、お薦めの一冊。

Higher-order Perl: A Guide To Program Transformation posted with amazlet on 07.04.18 Mark Jason Dominus Morgan Kaufmann Pub (2005/05/30) 売り上げランキング: 23841 Amazon.co.jp で詳細を見る

すみません、ひどく程度の低いPerlの話をします。

SEO担当相として日々アクセスログの解析をやっているのですが、解析したい条件に合うログを引っ掛けて、その内容に応じた集計をする際に、

    my %analyze = (
        qr/Pattern 1/ => 'Pattern 1',
        qr/Pattern 2/ => 'Pattern 2',
        qr/Pattern 3/ => 'Pattern 3',
            ....
        qr/Pattern N/ => 'Pattern N',
    );

    while (my $log = $logs->readline()) {
        foreach my $reg (keys %analyze) {
            if (($log->{ua}) && ($log->{ua} =~ /$reg/)) {
                my $pattern = $analyze{$reg};
                # Do hoge hoge for $pattern
                goto OUT;
            }
        }

    OUT:
    }

みたいな事をしておりました。

ですが、先日盆と正月が一緒に来たみたいな感じで複数のクローラが派手にガリガリやっていった日があって、その日のログを処理しようとしたら、3時間4時間走らせても解析が終わらない。
まあ非力な個人PCのCygwin上で走らせているので、それほどパフォーマンスは期待できないのですが、それでもかかり過ぎ。

んなもんで、やっぱり1行処理するたびにループ走らせてるとかがボトルネックなんだろうなあ、と思って、HTTP::MobileAgentのソースで見た

    my $DoCoMoRE = '^DoCoMo/\d\.\d[ /]';
    my $JPhoneRE = '^J-PHONE/\d\.\d';
    my $VodafoneRE = '^Vodafone/\d\.\d';
    my $VodafoneMotRE = '^MOT-';
    my $SoftBankRE = '^SoftBank/\d\.\d';
    my $EZwebRE  = '^(?:KDDI-[A-Z]+\d+[A-Z]? )?UP\.Browser\/';
    my $AirHRE = '^Mozilla/3\.0\((?:WILLCOM|DDIPOCKET)\;';
    $MobileAgentRE = qr/(?:($DoCoMoRE)|($JPhoneRE)|($VodafoneRE)|($VodafoneMotRE)|($SoftBankRE)|($EZwebRE)|($AirHRE))/;

    sub new {
        ....
        if ($ua =~ /$MobileAgentRE/) {
            $sub = $1 ? 'DoCoMo' : ($2 || $3 || $4 || $5) ? 'JPhone' : $6 ? 'EZweb' :  'AirHPhone';
        }
        ....
    }

を参考にして、

    my %analyze = (
        'Pattern 1' => 'Pattern 1',
        'Pattern 2' => 'Pattern 2',
        'Pattern 3' => 'Pattern 3',
            ....
        'Pattern N' => 'Pattern N',
    );

    my @analyzekey = keys %analyze;
    my @analyzeval = map { $analyze{$_} } @analyzekey;

    my $reg = "(?:(".join(")|(",@analyzekey)."))";
    $reg = qr/$reg/;

    while (my $log = $logs->readline()) {
        if (($log->{ua}) && ($log->{ua} =~ /$reg/)) {
            my ($pattern) = map { $analyzeval[$_-1] } grep { eval "\$$_" } (1..$#analyzeval+1);
            # Do hoge hoge for $pattern
        }
    }

みたいなコードにしたら、Benchmarkで3試行ほど計測した結果、平均18%ほど高速化しました。
うーん、やっぱり安易なループは、特に多重ループする際は慎まないといけませんな。
今頃そんな事悟るとはあまりにもレベル低すぎですが。

しかし晒してはみたものの、かっこ悪いコード...
特に、

    my @analyzekey = keys %analyze;
    my @analyzeval = map { $analyze{$_} } @analyzekey;
        ....
    my ($pattern) = map { $analyzeval[$_-1] } grep { eval "\$$_" } (1..$#analyzeval+1);

のあたり。
オリジナルのHTTP::MobileAgentと違って、パターンマッチの数を可変にしているので、

    $sub = $1 ? 'DoCoMo' : ($2 || $3 || $4 || $5) ? 'JPhone' : $6 ? 'EZweb' :  'AirHPhone';

みたいなやり方ができなかったのですが、なんかうまい書き方ないでしょうか...。

HTTP::MobileAgentも、個人的に各キャリア別のサブクラス割り当て判定がベースクラスに直書きされちゃっているので、キャリア単位でのメンテをベースクラスから切り離せないのが嫌で、それができるようにした私家版のHTTP::MobileAgentを作ってて、個人用途ではずっとそっちを使ってきてるんだけど。
そっちでも、キャリア判定時にやっているのは、サブクラスの数だけループを回して各サブクラスのキャリア判別メソッドを呼び出して、マッチしたサブクラスを採用する、という形にしている。
でも、HTTP::MobileAgentなんて、使うサイトでは全リクエストで最初にまず生成するオブジェクトだし、そのキャリア判定ロジックが遅ければ全体のパフォーマンスに影響すると思うので、オリジナル版と同じ判定ロジックを使いつつサブクラス側に判定ロジックを切り分けられる方法を考えなくちゃな。

----- 追記 -----

なんか添削されることを期待しつつ晒しながら、間違っているところが多かったので直しました。
OUT:ラベルの位置と、joinで正規表現をまとめるところの括弧の不足

あと、
はてなブックマーク - ここギコ！: 安易なループは慎むべきですね

loopのnestじゃなくてifの位置。foreachを消してもmapのとこが実質ループになってる件

ああそうか、最初のコードは一度判定したらいいはずのif ($log->{ua})がループの中にあるから、全行ループが走ってしまうのか。＜馬鹿すぎ
後のコードはif ($log->{ua})をまず検査した後にgrep/mapループしてるので、ループに到達する回数が減っているから早くなったということで、ループそのものがなくなったことによる高速化ではないということですね。
ループそのものが削減された場合の効果は、

私もそれ思ったので$pattern = "Dummy"としたベンチも取ったんですが、効果は18%⇒27%くらいで

となるわけか。

しかし、

• まかまかさんのコメント
• 添削その2 -jnaoyaのはてな日記-
• 404 Blog Not Found:perl - 勝手に添削^2 - loop control
• それ Regexp::Assemble -odz buffer-
• 勝手に採点 - アクセスログの解析 -ベンチャー企業のSEのひとりごと-

いやー、さすがTMTOWTDI、いろいろあるもんですね。
せっかくいろいろ教えていただいたので、追ってベンチマーク比較でもしてみようと思います。