ルートラボの遊び方を思いついたよ!

都知事選ですね。

スポーツ観戦が大好きな僕は、
やはりオリンピックが気になるわけです。

夏季と冬季の違いはあるけれでも、
各候補者が、都知事選の日はソチオリンピック開催中だということに、
どれだけの配慮をするかなぁということも
注目していたりします。

僕は東京が世界一安全で、
数々の見所が密集している素晴らしい都市だと思うので、
フルマラソンを日没直前のスタートの、
ナイトレースにできないかなぁと思う。
夜に外出しても安全なのと、東京の見所をアピールするのの、
両方ができるのではないかと。

観たい映像は、夜(もしくは日没前後)の時間の、
レインボーブリッジのアップダウンで勝負が決まるレースだ。
そんな映像なかなかないと思うので、
歴史に残るレースになるんじゃないかなぁ。

国立競技場をスタートして、
渋谷のスクランブル交差点を通り、
六本木交差点、銀座を抜けてお台場へ、
レインボーブリッジを通って戻ってくるコース。
そんなのできないかなぁと思って、
ルートラボで試作してみた。

http://latlonglab.yahoo.co.jp/route/watch?id=bd4036567aaa1783c4305eeca3cb408e

40km弱に納まっているので、
これに丁度おさまるようにどこかで距離調整すると、
いいコースになるんじゃないかと。

世界に東京をアピールするために、
みんなでルート作って遊んでみない?

サービス開発の考え方

Ruby on Railsのように、
MVCモデルでの開発をしていると、

「MVCとしてこうあるべきだ」

という議論が出たり、
セオリーから外れたことをすると
悪人のような扱いを受けたりする。

僕はどちらかというと悪人らしい。

システム開発のセオリーの一つに、
同じような処理を何度も書いたりするのを嫌う、
Don’t Repeat Yourself.
いわゆるDRY原則というものがある。

以前は僕もDRY信者で、
汎用的な共通処理をいかにまとめるか、
ということに一生懸命だったこともあるし、
いわゆるMVC的な書き方みたいなものが
ベターだと思っていたこともある。

これはシステムを効率良く保守していくことを
主軸に置いた考え方じゃないかと思う。

僕は若い頃から特殊な現場に入れてもらうことが多く、
例えば自分が担当しておらず、担当者がすでに退職した案件の
サーバーのリプレイス(古いソフトのバージョン上げながら)
をいきなり頼まれるなど、結構シビアな運用を経験させてもらってきた。

なので、最近はシステムを効率よく保守するというより、
いつでもリファクタリングして移行しやすいようにと、
システムを効率良く壊すことを主軸において考えている。

ハードウエアの老朽化や、
使用ソフトのバージョンが古くてサポートが切れるくらい、
数年間の運用が進んだ後だと、
当然システムにも問題が出てくる。

当初の設計の意図と違う用件の継ぎ足し開発など、
コードの保守が大変になってきているので、
そういうのも直した方がいい、となってくる。
そこでリファクタリングが必要になるのだが、
システムを止める時間を短くリファクタリングをするのは、
相当の時間と神経を使う仕事だ。

一つのシステムで複数のものが動いていたりするとカオスだ。
共通クラスという名の下に、全ての案件がそのクラスを使っていたり…。
段階を分けて部分的に移植のような戦略を立てるのが大変になる。

こういう経験をしてくると、
必要なRepeat Yourselfもあるんじゃないかと。

各処理ごと、ツールごとの依存関係をなくしておくと、
リファクタリングが非常に楽になる。
また、何かトラブルが起きても、影響範囲が小さくなる。

同じシステムを保守していく考え方と、
いつでも壊せるようにする考え方では、
同じツールでも使い方変わってくるなーと。
いわゆる「セオリー」と言われていることは、
正解なことがほとんどだけど、時々当てはまらないこともある。
なので、これはセオリーだからと思考停止しないように、
「考える」習慣をつけた方がいいと思う。

僕の師匠の教えは二つ。

「システムには寿命がある」
「フレームワークは人の思考を停止させる」

こういう考え方もあるんだよと。

ST_TransformのエラーとProj.4のお話

最近自分が何している人かわからなくなっていますが、
僕も一応ジオメディアのプログラマーだったりします。

昨日データセンターにてサーバーを搬入、セットアップをした。
社員が作業をしない夜中の内に一部のDBを新しいサーバーに移行しておいて、
朝出社したら何事もないように動いているけど、
DBサーバーだけ変更になっている…。
なんてことをやろうとしたところ、ちょっとトラブルが。

古いバージョンで使っていたpostgisなどを、
今回は新しいものにしようとセットアップをしたが、
どうも挙動がおかしい。

ST_Transform関数でのメルカトル図法への変換の時に、
EPSG:32653から遠く外れた座標のものが、
エラーになってしまうようだ。
transform: couldn’t project point (○○ ○○ 0): latitude or longitude exceeded limits (-14)
のように。

そりゃ正しい動作だよ、と言われると思うのだが、
大量の位置情報を扱っていると、ごく稀に不正確なデータがある。
このごく稀なデータのせいで、
ST_DWithin(ST_Transform(geom1, 32653), ST_Transform(geom2,32653), 1000)
のような検索が全てエラーになってしまう。

こんな変換しなければいいと思われそうだが、
これは今はもうない某有名ブログの記事に書かれていたもので、
indexが有効になるので、パフォーマンスが全然違う。

もちろん、球体計算をしていないものなので、
正確な距離が必要な時には使えないが、
普通の位置情報サービスで近いものを抽出するのなどは、
精密さよりも速度の方が大事になってくる。

…で、どうしても別のSQLにするとかはしたくなかったので、
どうにかできないかと色々探ってみたところ、
どうもProj.4ライブラリの4.8.0だとエラーを出すようだ。
4.6.0ではこんなエラーが出ていなかったのだが…。
(間のバージョンは調査してない)

調べてみると、4.8.0のsrc/PJ_tmerc.cの中で、
90度以上外れているものはエラーを帰す仕様になっていた。
(35行目と175行目)

ここをコメントアウトすると動くには動くのだけど、
変換後の座標が変な値になってしまっているようだ。

遠いデータはそもそも間違っているものなので、
4.8.0のエラーをコメントアウトして利用すべきか、
今まで通りの安心の4.6.0にするか…ちょっと悩んだけど、
座標の値が変になるのが気持ち悪いので、
今回は4.6.0のままにしようかなー。

昨晩から今朝までと、今日の昼からずっとはまっていたのだけど、
4.6.0と4.8.0で/usr/local/lib以下に配置される
ライブラリのファイル名が違うので、
4.8.0の後に4.6.0をインストールする場合、
ファイルを消しておかないと4.8.0の方の
ライブラリが残って、そっちを見ちゃうんだね…。

まぁなんというか、普通の人はあまりやらないようなことやっているので、
誰の得にもならなさそうな文章になっちゃったけど、
自分用の備忘録として。

Maker’s Markがサントリー傘下に

サントリーがビーム社を買収だそうだ。

ビーム社のお酒について調べていると、
ちょうど知りたかったことが書かれている記事が出ていた。

Jim BeamだけでなくMaker’s Markなどもビーム社なんだね。
そしてFour Rosesは日本のキリン傘下、
Wild Turkeyはイタリアのカンパリ傘下だそうだ。

ケンタッキー州の会社が保持し続けているのは、
Early TimesのBrown-Forman Corp.や、
Heaven Hill Distilleries Inc.などだそう。

Heaven Hillというと、原酒を数多くのブランドに
提供していることで有名だ。
原酒が同じでも、作り方によって味が変わるんだ。

バーボンのボトルを眺めつつ、
いろいろ思いを巡らせてみるのもいいかもね。

九段 斑鳩

昨日、手土産の鉄板というリンクをシェアして、
赤坂しろたえのレアチーズケーキに言及したところ、
色々な方からコメントいただいた。
みんな好きなんだなぁ。

手土産みたいなものは、
なるべく多くの人に喜ばれるような、
最大公約数的なものがいいよねーと。

僕はそこまで食べるものにうるさくはないのだが、
30min.というサービスを運営していると、
オススメのお店を聞かれることが多かったりする。
せっかく期待していただいているので、
頑張って探して紹介してみるわけだ。

仮に食べ物や飲み物が好みでなくても楽しめるように、
入口が非常に分かりにくいお店や、内装が特殊なお店、
そこでしか食べられないものがあるお店などがあれば、
こういう時の鉄板だ。

でも、この最大公約数的なお店が難しいのがラーメンだ。
美味しいラーメン屋を教えてというのは悩ましい。
人によって好みが違う上に、濃いのが好きな人からダメな人まで、
両極端に振れる食べ物である。
勧める側としては、仮に好みと違っても、
「好みと違ったけど、勧められた理由わかるよね」
と言ってもらえるものにしたい。

…こういう時におススメしているのが、
九段下にある有名店、九段 斑鳩の特製ラーメンだ。

ikaruga

魚介豚骨なんだけどしつこくなくて、和っぽい味になっている。
好みは割れると思うのだえど、なるほどなーと思ってもらえるんじゃないかな?

今日たまたま飯田橋の方に用事があったので、
久しぶりに伺ってきたけど、美味しかったなぁ。

…えっ?そういう最大公約数的なのじゃなくて、
僕が本当によく通っているラーメンが知りたい?
実はぶぶかというお店の油厚切りチャーシューそばというのが…以下自粛(激しく好みが分かれそうなので…)。

そろそろWebページのUUを○○人って呼ぶのやめた方がいいんじゃない?

僕は数字には割とうるさいというか、
理詰めで面倒くさいタイプだと思うけど…。

会員登録が必須のサービスとか、
アプリなどのようにダウンロード数とか、
アクセスされるデバイスの識別ができるものはいいのだけど。
WebページのUU(ユニークユーザー)って定義は人数ではないよね。

会員登録をしないで閲覧ができるWebページなどだと、
Cookieベースでカウントしているので、
UUはアクセスしているブラウザの数だ。

会社のPC、スマートフォン、家のPC、タブレットなど、
一人でいくつものデバイスでWebを見るので、
「人数」はユニークユーザー数よりも少ないよね。

元々統計としてリピート回数や頻度などの傾向を見るための数値だと思うのだけど、
営業担当者などが間違って使っていることが多いような。

自社の数字を大きく見せたい気持ちはわからないでもないけど、
より正確な内容を伝える方が誠実で、
信頼もされるんじゃないかなぁ。

○○人というよりも、ユニークユーザー数は○なので、
実際に利用している人数はこの6~8割くらいと推測される。
(サービスの質によって割合変わるのだろうけど)
くらいでいいのかと。

野々村さんについて調べてみた

あけましておめでとうございます。

昨年ライブドアブログで、○○.blog.jpのように、
blog.jpのサブドメインが早い者勝ちで解放されたので、
nonomuraを押さえようと思いながらも、
その必要がないことに気がついて興醒めしたのがこちらです。

nonomura.jpは大学時代の友人がクレジットカード会社に就職し、
カード契約のノルマに追われている時に契約したカードで、
最初に買い物をしたものだった記憶が。
2001年の6月28日から保持している。

…なぜドメインの話に話になったかというと、
1月7日のリフォーム産業新聞にバイヤーズエージェント仲介を掲載していただいて、
掲載紙を拝見していたところ、隣の紙面にもうお一方野々村さんがいらっしゃった。
桃栗柿屋さんという、滋賀県のリフォーム業者さんらしい。

野々村というと、元々は織田信長の家来だったのがルーツなのかな?
実は信長の野望の戦国群雄伝で織田信長を隠居させて、
家臣の野々村三十郎を大名にして全国統一をしたことがある。
あまりにマイナー武将だったらしく、
それ以降のシリーズには出て来なかったような気がするが、
世の中には不思議な人がいて、野々村三十郎について詳細に調べたサイトがあった。
「野々村三十郎正体解明プロジェクトチーム」なるものもあるそうなので、
機会があれば参加してみたいなぁ。

…なんてことを書いてみているが、実は僕は野々村さんとは血の繋がりはないらしい。
祖父が野々村洋品店に婿養子として入ったのだけど、
奥さんが早くに亡くなったらしく、僕の親族は皆後妻として入った祖母の子供からだ。
実は祖父の旧姓は徳森だそうで、瀬戸内海の島のみかん農家だったそうだ。

まぁ出自がどうであれ、あまり細かいことは気にしない方なので、
今年もnonomura.jpをよろしくお願いいたします。