ルミネの新しいCMが話題になっている。

ルミネのCMの件ですが、開始1〜2秒に流れる奇妙な地形がどうなってるのかを考えながら見ると話に集中できずに怒らないで見ることができます。 pic.twitter.com/ZSPlMkMIF7

— 浦島もよ (@monoprixgourmet) 2015, 3月 19

浦島さんの言う通り、奥に見える地形は確かに妙だ。真ん中の女性の顔のすぐ後ろに車があることからも分かるように、車道は急に高くなっているのに左側の歩道は同じレベルのままだ。

そして、この道には見覚えがある。印刷博物館の前の、神田川沿いの道だ。昔から大曲と呼ばれるあたり。

車道だけが高くなっている理由は、右から伸びてくる水色の橋にある。実は対岸のほうが2メートルほど高いので、こちら側の橋の根元の地面を盛り上げてレベルを合わせているのだ。

橋は、上の図（東京地形地図のキャプチャー）の真ん中の白い線のようにかかっている。視線は赤い矢印の向き。色が濃いほど標高が高いので、こちら側が低いというより向こう岸が高くなっているのが分かる。

別の場所から対岸を見たところ。ちょっと分かりにくいけど、向こう岸がずいぶん高いところに見えるのが分かる。じゃあ、ここらへんの岸はぜんぶそうかというと、そうでもない。たとえば隣の橋は両岸とも同じレベルにある。

ほらね。普通だ。

そうすると気になるのは、こんなふうに両岸で高さが極端に違うのはどんなときかってことだ。一つ思いつくのは、この場所が「大曲」と呼ばれていたように、神田川がぐぐっと屈曲している現場だってこと。川が曲がっている部分の内側を削り残す、みたいなことがあるんだろうか？

そう思って神田川やその支流の曲がっている部分を見てみると、確かにそう思えなくもない箇所はある。

赤く点を打った場所は、川が大きくカーブする内側の標高がずいぶん高い（色が濃い）。ただ、これと逆に外側のほうが高いような場所もふつうにある。

これは神田川の上流だけど、ここだと赤く点を打った外側のほうが高くなってる。だから必ず内側が高いということはないようだ。ただし、眺めてる限り、大きく曲がるようなところで両岸の標高に差があるということは割合あるように思える。因果関係としては、急に高い崖にぶつかったから大きく曲がるっていうこともあるかもしれない。

ここらへんのことは地理とか地形を勉強した人なら基本的な知識だと思うので、お前もうちょっと勉強しろってことだとは思うんだけど。

印刷博物館の前のあの道路は、以前からちょっと妙だなとは思っていた。だからこそルミネのCMを見たときにあそこかなと思えたんだけど、浦島さんに改めて「奇妙な地形」と言われるまでその理由はあまり考えたことがなかった。ルミネの新CMと浦島さんの指摘に感謝したいと思います。

「新しいGoogleマイマップ」で作った地図をブログとかに埋め込もうとしたとき、旧マイマップみたいに大きさや位置、縮尺を自由に決められなくて不便！と思ったことはありませんか。

実は「デフォルトビューを設定」の機能でマイマップ1つにつき1つの視点は設定できるんだけど、複数の場所に埋め込もうと思ったら依然として不便だ。

そんなときのために「Googleマイマップ埋め込みヘルパー」というのを作りました。

Googleマイマップ埋め込みヘルパー

使い方は簡単！まずは、作ったマイマップのURL、

これをコピーして、埋め込みヘルパーのここ

ここにペーストして、「地図を表示する」ボタンを押す。すると、下に地図が表示されるので、

これを動かしたり縮尺変えたり、大きさを変えたりする。すると、

その下に埋め込みURLが書かれているので、これをコピペしてブログとかに埋め込む。これだけ！

ぜひ使ってくだせー。

「新・都市論TOKYO（集英社新書）」という本を読んでたら、森ビルの歴史が面白そうだなーと思ったので、調べてまとめてみました。

森ビルは六本木ヒルズのような大規模再開発を手がけるデベロッパーですが、その歴史は西新橋の小さな貸しビル業から始まったそうです。

時代ごとに、どんな場所で、どんな規模の開発をしてきたかを知るために、森ビルが手がけたビルやプロジェクトを年代ごとに色分けした地図を作りました。日曜日の朝からNHKの将棋中継も見ないでまとめました。

■1960年代   ■1970年代   ■1980年代   ■1990年代   ■2000年代   ■2010年代

古いほど青く、新しいほど赤くなるように色分けしています。データは森ビルのサイトからひっぱってきましたが、もう建ってないビルは載っていないので残念ながら全部ではありません。ただ傾向は分かるんじゃないかと思います。

都心についてはこれがだいたい全体図ですが、小さすぎてよく分からないので時代ごとにズームしながら見てみます。

1960〜1970年代

■1960年代   ■1970年代   ■1980年代   ■1990年代   ■2000年代   ■2010年代

右上の「西新橋」の文字の近くの青緑色の四角が、森ビルが1956年に最初に建てた「西新橋2森ビル」です。

後から竣工した「西新橋1森ビル」もすぐ近くの外堀通り沿いにありましたが、今は取り壊されてしまいました。

その後、1960年代から1970年代にかけては虎ノ門付近に多くビルを建てたようです。青と紫の四角がよく見えます。この時代のビルには「虎ノ門35森ビル」のように名前に数字がふられていたため、ナンバービルと呼ばれたとのこと。

1978年のラフォーレ原宿は、初めての商業施設であり、初めて港区の外でおこなった開発でもあったようです。この頃からちょっと手を広げ始めた感じですね。

 1980〜1990年代

■1960年代   ■1970年代   ■1980年代   ■1990年代   ■2000年代   ■2010年代

この時代の大きな成果は、左にある紫の大きな領域、1986年のアークヒルズです。

アークヒルズは、赤瀬川原平の「超芸術トマソン」で「ビルに沈む街」としてまさに開発中の様子が取り上げられた場所でもあります。有名な煙突写真が撮られたのとほとんど同じ場所に、アークヒルズの煙突が建っているのは偶然と思えない、ということが本にも書かれていますね。

このアークヒルズが、単一のビルにとどまらない面的な開発の足がかりとなりました。

次の大きな開発は1999年のお台場ヴィーナスフォートでだいぶ間が開くんですが、別にさぼってたわけじゃなくてずーっと次の準備をしていたようです。

2000年代以降

■1960年代   ■1970年代   ■1980年代   ■1990年代   ■2000年代   ■2010年代

地図左下、2003年の六本木ヒルズは、森ビルとして最大の開発になりました。計画開始は1986年だそうで、まさにアークヒルズ竣工の年なんですね。それから17年間も、ずーっと六本木ヒルズの準備をしていたと。

何百人もいる地権者を説得してすこしづつ買い上げたりとか、森ビルのプロジェクトはこんなふうに長い時間をかけてようやく実を結ぶということがあるらしいです。

2006年には表参道ヒルズの再開発もありましたが、こういう派手な開発ばかりじゃなく、2009年には芝三田森ビルという小さなかわいいビルを建てたりもしていて、なかなか好感度アップです。

2014年の虎ノ門ヒルズは、森ビルがこれまで虎ノ門周辺で手がけた小さなビルに囲まれた、少なくとも場所的には原点回帰の開発となったんですね。地図を描いてよく分かりました。

丸の内をどかんと払い下げられた三菱と違って、森ビルは何もないところから少しづつ自力で港区を開拓していった。一案件に17年もかけたりして。なんとなく悪者のイメージありましたけど、そういうところはすごいなーと思います。

全体の地図はここから見られます：「森ビル開発史マップ」
間違いなどあればご指摘ください。

参考：森ビル公式サイト「ビル一覧」

追記：

フォトグラファー／ライターの大山顕さんが、森ビル開発史マップを年代ごとにアニメーション化したものを作られました。

『故郷に錦を飾った森ビル | 「住宅都市整理公団」別棟』

森ビルの開発の場所や規模がどう移り変わってきたかが、アニメにすることでとても分かりやすく表現されていてすごいです。ぜひ見てみてください。

ISUCON というのはITエンジニア向けのコンテストで、課題となるウェブアプリケーションをチューニングしまくって、出来る限り多くのアクセスをさばけるようにしようというものです。

第4回めとなる今回は、主催がLINE、出題はクックパッド、インフラはテコラスさんという贅沢なものでした。参加者は3人1組のチームで、今年は185組が予選に参加、そのうち上位28組がLINE本社で開かれる本戦に参加することができます。

同僚の @h_nakamura、@kawataso とともに「ナイスカロリー」とういい加減なチーム名で予選に参加したところ、主に同僚二人の活躍でなんと予選突破、11月8日(土)にLINE本社で開かれる本戦に参加できることになりました。

 

LINE本社といえば渋谷ヒカリエです。こんな環境で予選突破した猛者たちと本戦を戦うことになり、当日はたいへん浮足立っておりました。

会場はこんな感じのおしゃれな場所です。

 

さっそく窓際のよさそうな場所を確保しました。真ん中に写ってるのが同じチームの二人です。

11時にコンテストが開始されると、レギュレーション、つまりルールが公開されます。これをちゃんと読んでおかないと、後になって「そんなルールがあったの？」ということになって時間を大量にムダにするので、とにかく熟読しました。実装言語はいくつか選択できるのですが、慣れているPHPにしました。

課題となるウェブアプリケーションの見た目はこんなでした。

 

動画広告配信のウェブアプリです。まずこれがどんなアプリなのかを把握しないといけません。おおよそ次のようでした。

• 広告主は、広告の表示場所（スロット）と、クリックされた後のリダイレクト先URLを指定して、動画を入稿する
• 広告を掲載するサイトは、スロットに登録された動画から1つを選んで表示する。
• ユーザーが広告をクリックすると、リダイレクト先へジャンプする。
• 広告主は、広告が表示された回数、クリックされた回数のレポートを閲覧できる。

動画についてはサンプルが用意されているのですが、出題チームががんばってつくったなーという感じの伝わるほのぼの映像となっていました。

どんなアプリなのかがだいたい分かったので、つぎは計測します。チューニングの鉄則として有名な言葉が「推測するな、計測せよ」です。どこにボトルネックがあるのかコードから推測するのは効率が悪いし、はずれることも多い。とにかく計測が大事です。

ボトルネックを計測するために予選のときから準備したのは、

• ウェブサーバーのアクセスログに応答時間を追加し、LTSVで出力する
• LTSVを処理し、一回のベンチマークでアクセスされたURLごとの処理時間の合計を出す

ということです。URLごとの合計時間は、PHPの初期実装では次のようでした。

POST /initialize HTTP/1.1 0.082
GET /me/final_report HTTP/1.1 0.32
POST /slots/*/ads 29.944
GET /me/report HTTP/1.1 40.462
GET /slots/*/ads/* 50.821
GET /slots/*/ad 52.249
GET /slots/*/ads/*/redirect 53.722
POST /slots/*/ads/*/count 59.053
GET /slots/*/ads/*/asset 380.54

右端の数字は、合計の処理時間のマイクロ秒です。これを見ると最後の GET /slots/*ads/*/asset にもっとも時間がかかっていることが分かります。

レギュレーションを読むと、どこに何点の配点があるかということが分かるので、それをもとにもっともスコアに効いてくるボトルネックを順につぶしていくということをひたすら繰り返すことになります。

本戦ではサーバーが3台ありました。動画をとにかく数多く配信することがスコアアップにつながるようでしたので、キャッシュサーバーを前に2台を置いて1台をアプリサーバーとするというようなチューニングをしていたところ、5位以内くらいに浮上するようになりました。

 

コンテストのあいだは、こういうランキングが随時更新されるのです。「ナイスカロリー」が僕らです。

いろいろやっていたのですが、どんなチームもまだ1万点を超えないという状況の中、「チームフリー素材」というチームがいきなり30万点を出して衝撃が走りました。その後その点数は消えてしまったので、ベンチマークのバグかな―とおもってやりすごしてしまったのですが、本当はバグじゃなかったようです。後で分かるのですが、実はそこがポイントでした。

コンテストの終了間際になり、ぼくらのチームはベンチマークのスコアが安定しない、というよりベンチマークの出す原因不明のエラーにより0点になるという状況がずっと続きました。その状況が改善しないまま19時に競技終了。これはもうだめか、最下位か・・と思いながら発表を待っていると、なんとちゃんとスコアがつき、しかも14448点で、4位でした！

ぼくらのチームです。写真はISUCON公式ブログからお借りしました。

しかし、1位のチームはなんと61万点。ぼくらの40倍です。じつはベンチマークプログラムが賢くて、Cache-Control ヘッダを適切にかえしていれば、次から同じ広告は取得しに来ないので、結果的に広告をたくさん配信できた、ということだったようです。33万点というスコアを見てその可能性に気づいたのはトップのチームだけだったようですから、ぼくたち参加者は出題者に完敗したような気分です。

ともあれ、たくさんの参加者の中に身をおいて、純粋にエンジニアとして競争するというのはいままでにない経験で、得るものが多かったです。優秀なのはチームの他の二人でぼく自身はあんまり何もしてなかったとはいえ。

最後になりますが、LINEの主催チーム、クックパッドの出題チーム、テコラスのインフラ提供チームのみなさんには感謝の言葉しかありません。傍から見ていても本当に大変そうでした。特に出題チームの3人は、前日から徹夜したうえで、当日もベンチマークの不具合対応などで終始忙しそうでした。次回も開催されるようですが、ぜひ主催側に無理のない形やスケジュールで開催していただければと思っています。ありがとうございました。

Io っていうプログラミング言語の if then else の実現方法がむちゃくちゃかっこよかったのでメモ。

まず if then elseの見ためはこんな感じ。

if( 4 % 2 == 0 ) then( "偶数" print ) else( "奇数" print )

この場合は、4を2で割った余りが0なら「偶数」と表示され、そうでないなら「奇数」と表示される。この if then else はこういう構文があるわけじゃなくて、メソッドチェインで実現されてる。そこがかっこいい！

具体的には上のコードはこんなふうに評価される。まず先頭の if( 4 % 2 == 0 ) は実は if メソッドを引数「4 % 2 == 0」で呼び出すという意味で、4 % 2 == 0 は真なので true オブジェクトが返る。なのでこうなる。

true then( "偶数" print ) else( "奇数" print )

つぎに true then( ”偶数” print ) が評価される。これは true オブジェクトのthenメソッドを引数「”偶数” print」で呼び出すという意味だ。これは引数を評価したうえで nil を返す。まず、引数の「”偶数” print」は「偶数」という文字列のprintメソッドを呼び出すという意味なので、「偶数」という文字が表示される。そのうえで nilが返るからこうなる。

nil else( "奇数" print )

これまで同様、これは nilオブジェクトに対する elseメソッドの呼び出しになるんだけど、nilはelseメソッドに対してなにもしないので、「奇数」という文字は表示されない。これで if then else がみごとメソッドチェインで実現されたことになる！

なお、ふつうの言語なら上の例で elseメソッドに引数「”奇数” print」が与えられたら、まず引数を評価してから elseメソッドの本体に渡すので、「奇数」はどうしても表示されちゃう。Io の場合は引数の評価が遅延されるのでこういううまいことができる。

ちなみに else と then を逆に書いても問題なくうごく。つまり、

if( 4 % 2 == 0 ) else( "奇数" print ) then("偶数" print )

と書いても大丈夫！具体的に評価を追って行くと、さっきと同じように冒頭の if がまず true になる。

true else( "奇数" print ) then("偶数" print )

trueオブジェクトにelseを呼ぶと、引数を無視して単にtrueオブジェクトを返すから、

true then("偶数" print )

こうなる。これはさっきもやったとおり “偶数” と表示されるので、これで終わり。なるほどーって感じだ。

if then else が制御構造じゃなくてメソッドだっていうのはどうやら Smalltalk に由来していて、それっぽい ifTrue() とか ifFalse() っていう書き方も別にあるようなんだけど、ぜったいこっちの if() then() else() のほうがかっこいいと思う。

駅で電車を待ってたら、目の前の看板で冨永愛さんが片桐はいりさんになっていた。

これは違う。片桐はいりさんはこんなエラじゃなかったはずだ。と思ったら、左隣では本物の片桐はいりさんが寺島しのぶさんということになっていた。

なるほど、これはキャプションがずれてるんだ。

キャプションのずれはちょうど赤線のようになっていた。一番右の松尾スズキさん辺りでは合ってるのに、左に行くに従ってずれてる。なんでこんなふうになっちゃったんだろう？

よく見ると、一番左に「大森南朋」と名前だけがあって写真がない。これがカギだ。もっというと、これはキャプションじゃなくて、写真とは独立に役者名を並べたテキストが、偶然キャプションに見えていただけなのだ。

じゃあ大森南朋さんの写真はどこにある。

なるほど。すべては主役の写真だけを別枠にしたせいだったのか。

今日、気づいたこと。

主役のせいでキャプションがずれる。