昨年は Developer Day の一部として ハッカソン(Hackathon:Hack と Marathon を合成した造語、昨年はコードラボと記していました)を開催しましたが今年は Google Developer Day 2009 Japan 開催の直後、6 月 10 日と 6 月 11 日に開催いたします。これは、昨年の参加者やサポーターの方からの「ハッカソン に参加すると他のセッションに参加できないのが残念」というご要望に応えたためです。

ハッカソン 開催日程
テーマ: Geo
 ハッカソン: 6 月 10 日(水)/富士ソフト アキバプラザ
 事前ミーティング: 6 月 1 日(月)/Google オフィス(渋谷)

テーマ: Android
 ハッカソン: 6月 10 日(水)/富士ソフト アキバプラザ
 事前ミーティング: 6 月 2 日(火)/Google オフィス(渋谷)

テーマ:OpenSocial
 ハッカソン: 6 月 11 日(木)/富士ソフト アキバプラザ
 事前ミーティング: 6 月 3 日(水)/Google オフィス(渋谷)

テーマ: Google App Engine
 ハッカソン: 6 月 11 日(木)/富士ソフト アキバプラザ
 事前ミーティング: 6 月 4 日(木)/Google オフィス(渋谷)
ハッカソンはいずれの日も 10 時から 18 時、事前ミーティングはいずれも 19 時から 21 時となっています。

ハッカソンへの応募は以下で受け付けています。ハッカソン には Google Developer Day のために来日した米国の Google エンジニアも参加しますので、奮ってご参加ください。
Google Developer Day 2009 Japan ハッカソン 応募受付

アイデアソン のご紹介

さて、ハッカソン に参加される方には、ハッカソン のおよそ 1 週間前におよそ 2 時間開催される「事前ミーティング」への参加も強くお勧めしています。毎回異なるメンバーが集まる ハッカソン にとって、事前ミーティングはとても重要なミーティングとなります。今回は「事前ミーティング」とそのプログラムの 1 つである「アイデアソン」の魅力と詳細について、2 月に京都で開催された OpenSocial ハッカソン の「事前ミーティング」を例にご紹介しましょう。「事前ミーティング」の詳細は ハッカソン を自ら開催されるデベロッパーの方にも大いに参考となるはずです。

事前ミーティングのアジェンダは主に 3 つに分けられます。
  • 諸連絡
    • ハッカソン を効率よく行うためのツールや環境設定の紹介
    • コードを共有するためのリポジトリサーバの説明
    • Tips
    ハッカソン のテーマによって連絡すべきツールや環境設定は異なりますが、登録や設定に時間がかかるものについては事前ミーティングでの説明が必須となります。 OpenSocial は検証のために SNS の Sandbox の登録を必要としますが、その登録に 2 ~ 3 日かかる場合があります。そのため、ハッカソン 当日に登録ができていないと 1 日が無駄になってしまいかねません。こうした事態を回避するために、事前ミーティングでの連絡が必要となるのです。

    またグループで開発をするには、コードをシェアし、バージョン管理を行うためのリポジトリを用意し、その使い方を全員が理解しておく必要があります。リポジトリを用意すれば、ハッカソン の終了後も開発を続けることができます。前回の ハッカソン では code.google.com のプロジェクトホスティングを利用しました。このプロジェクトホスティングにはコードの共有以外にも利点があります。プロジェクトホスティングにアップロードしたファイルには固定URLでアクセスすることができるため、SNS などにアプリケーションを登録する際に、プロジェクトホスティングの URL を利用できるのです。

    時間があれば、ハッカソン 初心者のために Tips を紹介することも有効です。今回の ハッカソン では Tips に従い、ペンタブレットを持参している参加者もいました。 3D CG のゲームを作成するために大活躍していたようです。


  • グループ分け
    ハッカソン ではグループに分かれてコーディングを行います。グループ分けは ハッカソン 当日でも可能です。しかし、グループ分けとその後の自己紹介で時間を費やすため、これを避けるためには、事前ミーティングでグループ分けを行うことが望ましいでしょう(事前ミーティングに参加できなかった人は ハッカソン 当日にグループ分けを行うことになります)。なお、グループは 6 人以下が適切です。それ以上の人数ならば、グループを分割するべきでしょう。

    グループ分けのポイントは主催者側であらかじめグループを設定しておくことです。今回の ハッカソン では参加申し込み時に開発したいアプリケーションのアイデアを記入していただき、それを参考にグループを設定しました。

  • Ideathon
    アイデアソン は聞きなれない言葉でしょうが、ハッカソン と同じく Idea と Marathon を合わせた造語です。同じグループのメンバー同士が打ち解ける機会でもあり、事前ミーティングにあわせて 1 時間程度の アイデアソンを行います(通常、アイデアソン は ハッカソン と同様に1日を費やすことが多いのですが、事前ミーティングでは時間の都合上 1 時間としています)。

    アイデアソン ではグループごとに、ハッカソン のテーマとなった技術についてのブレインストーミングと発表を行います。単なるブレインストーミングとは異なり、発表のためにアイデアをまとめる必要があります。短時間でブレインストーミングを行い、その中で提示されたアイデアを評価および統合し、簡易で魅力的なプレゼン方法の検討が必要となります。これらを1時間で行うのですから、雰囲気としては短距離走に近い集中力が求められます。



    発表方法は特に決まっていません。アイデアをまとめるために用意したスケッチブックや模造紙を用いても良いですし、口頭での発表でもかまいません。今回、投票でもっとも優れたアイデアと評価されたグループは模造紙による発表でした。



    アイデアソン は密度の濃いコミュニケーションとなるため、自然とグループは打ち解けつつ、お互いの技術的力量を把握することもできます。また、グループで開発するアプリケーションは アイデアソン で発表したアイデアに沿ったものとなることが多いようです。この場合、ハッカソン 当日に何を開発するかを検討する時間が節約できることになりますし、ハッカソン 当日までにグループで連絡を取り合い ハッカソン 当日に向けて十分に準備することも可能となります。



このように「事前ミーティング」を行うことにより、ハッカソン 当日を限りなくコーディングだけに費やすことができるようになります。
Google Developer Day に併せて開催されるハッカソンに参加を希望される方は、ぜひ「事前ミーティング」への参加も検討いただけるようお願いします。

本日、日本のモバイル市場のリーダーであり、世界的にも新技術、新サービス開発のリーダーである NTT ドコモから、 Android 搭載携帯「HT-03A」が発表されたことを、大変うれしく思っています。

Android はインターネット世代における初めての完全にオープンで無償の携帯プラットフォームです。世界中の開発者によるアプリケーションがいつでもダウンロードでき、ユーザーの皆さんは自分の端末を自分好みにカスタマイズして使うことが可能です。

本日発表した、HT-03A も、フルブラウザ搭載により、モバイルでもインターネットを PC と変わらず利用することができます。また、タッチスクリーンとトラックボールでその操作も快適です。
さらに、Google 検索、Google マップ、Gmail、YouTube など、Google モバイルのサービスへもワンタッチでアクセス。PC でもモバイルでも Google のサービスをシームレスに活用していただくことができます。

今回の発表は、Open Handset Alliance にとっても、より良いユーザー体験を提供する上での意義ある第一歩となります。Open Handset Allianceは、Android プラットフォームを奨励し、携帯電話のイノベーション促進に取り組む、47 以上のテクノロジー / 携帯業界のリーダーから成るグループで、日本のキャリアや端末メーカーも多数参加しています。

Google は、日本はもちろん、世界中のユーザーの皆さんに、すばらしいモバイルインターネット体験を提供できるよう、今後もパートナー、開発コミュニティ、そしてユーザーの皆さんとともに、イノベーションに注力していきます。
ご期待ください!
Share on Twitter Share on Facebook

2009年5月18日
村井説人 / ストラテジック パートナー ディベロップメント マネージャー
根来香里 / プロダクトマーケティングマネージャー

先週記者会見でも紹介させていただきましたが、この度Google マップでは、施設の運営者の方から直接申し込みいただくことで、施設内をストリートビューで公開できるパートナープログラムを開始しました。これにより、お寺や動物園・大学など今までは実際に訪問しなければ見ることができなかった施設内の様子(公道以外の場所)をストリートビューで見ることが出来るようになります。このサービスを使えば、例えば、「受験先の大学キャンパスを一度見ておきたい」などの受験生に対する要望にこたえることが出来るようになります。「わが施設を撮影してほしい」という施設運営者の方がいらっしゃいましたら、是非パートナープログラムへお申し込みください。

尚、このパートナープログラムを運営するに当たり、Google では「車」撮影のほか、新たに「自転車(通称Trike)」を用意させていただきました。
車では通れないような小道もこの自転車なら撮影することができるようになります。




現在Google では、既に二つの施設を撮影させていただいきました。
ご協力いただいたパートナー様から、ご意見をいただいておりますので、以下ご紹介します。

1) 京都府京都市 高台寺: 
咲き誇るしだれ桜の下、歴史ある高台寺の境内を散策する。

「Google マップという形で、世界中の皆さんに高台寺の画像を地図上でご覧いただけるということを非常に嬉しく思います。本プロジェクトに高台寺を選んでいただいたことを感謝するとともに、これを機会にぜひたくさんの方に高台寺にいらしていただきたいと考えております」

高台寺 執事長 川本 博明 氏



2) 北海道旭川市 旭山動物園
旭山動物園の動物の配置を訪問前に事前に確認する。

「うちの動物園は階層構造になっていて、配置が複雑だったりするんですが、そのあたりもストリートビューだとわかりやすいですね。また、園内は混み合うことも多いので、事前に園内の配置を把握できると便利だと思います。それに何と言っても、地図からグーッと入っていくのはすごく楽しいし、ワクワクしますね。そういう臨場感が伝わって、さらには、そこから動物をしっかり見てもらうことにつながっていったらいいなと思います。」

旭山動物園 園長 坂東 元 氏

以上が、パートナー様からの声になります。
尚、ご紹介させていただいた高台寺、旭山動物園のストリートビュー画像は近日公開する予定です。撮影も順調に行き、とても魅力的なストリートビューになると思います。公開まで、今しばらくおまちくださいね。

パートナープログラムへのお申し込みは、こちらのフォームからお願いします。皆様のご参加、心よりお待ちしております。

※追伸
まことに恐縮ですが、現在たくさんのお申し込みをいただいております。
すべてのお申し込みにお応えすることができませんことを予めご了承くださいませ。
Share on Twitter Share on Facebook

2009年 5月 13日
Posted by 河合 敬一 / プロダクトマネージャー

日ごろからGoogle マップをお使いいただき、本当にありがとうございます。
本日は、ストリートビューのサービスにいくつか変更がありますので、ご報告いたします。

去年8月のサービス公開以来、おかげさまでたくさんの方にGoogle マップのストリートビューをお使いいただいています。これもひとえに、ユーザーの皆様あってのことだと、スタッフ一同、心より感謝しております。

私たちは、ストリートビューを、地図の進化へのひとつの試みとして考えています。これまでの「上から見て横向きで使う」地図から、「横から見て横向きで使う」地図へ。これまでになかった新しい地図が、多くの方の日々の生活に、きっとお役に立てるに違いない、そういった思いから、サービスの提供まで、多くのスタッフとともに努力を重ねてきました。

公開以来、この新しい地図が役に立っているというユーザーのみなさんの声が、私たちの支えになってきました。例えば、目的地の周辺を事前に見ておくことで、道に迷いにくくなった、という声。また、ハンディキャップのある方が、外出前にスロープがあるか、周囲の状況を確認するといった利用ケース。引越しや不動産探しでの活用。あるいは、教育現場におけるストリートビューの活用も進んできているようです。(詳細は本日公開したストリートビュー、活用例のページをご参照ください。)

一方、このサービスに対する懸念の声があったことも確かです。日本へサービスを展開するにあたり、日本特有の事情をあまり考慮しなかったのではないか。プライバシーの問題を軽視しているのではないか。Google では、本サービス公開以来いただいたご意見を真摯に受け止め、このサービスを続けていくにあたって、より安心してお使いいただけるにはどのようにしたらいいか、議論を重ねてきました。

そして本日、サービスの向上および改善のための方策として、以下の4つの変更を発表いたします。
  1. これまで公開してきた日本のストリートビューのデータ全てについて、ナンバープレートの不鮮明処理(ぼかし処理)を施しました。
    本日、現在公開されているすべての画像に対し、ナンバープレートに不鮮明処理を施しました。はじめから高解像度のカメラで撮影を行っていたヨーロッパではナンバープレートにぼかしを入れておりましたが、サービス開始時期が他国よりも早い米国および日本では、解像度の低い旧式のカメラを使っていたため、この処理を行っていませんでした。このたび、日本においては、道路特有の事情や、皆様のご意見を考慮して、ぼかし処理を行うことといたしました。
    現在の技術でできる限りの処理を施しましたが、自動認識による不鮮明化技術は残念ながら完全ではありません。万が一漏れを発見された場合は、画像中「問題の報告」リンクよりご指摘ください。手動にて修正させていただきます。皆様のご協力を賜れれば幸いです。
  2. カメラの高さを下げ、再撮影します。
    カメラの高さを 40cm 下げ、これまで公開済みのエリアも含め、すべてのエリアにおいて再撮影を行います。当初は、駐車中のトラックが並んでも正面を撮影できる高さといった要因を考慮し、カメラ位置を設定しましたが、道路幅や日本の住宅事情にあわせ、今回の変更を行いました。
    なお、未公開のエリアでも、既に前の高さのカメラで撮影済のものがあります。こちらについては撮影済みの画像をまず適応させていただき、順次再撮影した映像に切り替えさせていただきます。

    また、すでに公開停止のご依頼をいただいた部分に関しては、再度撮影した場合でも、画像が復活することはありませんので、再度ご依頼いただく必要はありません。

    <参考資料>



    [ 変更前の高さ ]

    [ 変更後の高さ ]
  3. ストリートビュー専用ダイヤルを設けました。

    インターネットをご利用にならない方でも、画像の公開停止についてご依頼いただけるよう、ストリートビュー専用ダイヤルを設けました。本日より受付いたします。

    お問い合わせ先は、下記の通りです。

    0120-585614 (携帯電話、PHS、海外からは 03-6837-2341) ※番号が変わりました。
    ナビダイヤル 0570-01-0041 (携帯電話、PHS、海外からは 03-6384-9900)

    ・ 受付時間: 9:00 ~ 12:00 / 13:00 ~ 18:00 (月曜~金曜)
    ・ 通話料金はお住まいの市内通話料金でご利用いただけます。
    ・ 年末年始および土日祝日はお休みとさせていただきます。
    ・ より迅速で確実な、パソコンや携帯電話からのご依頼方法もご活用ください。
  4. 表札のぼかし処理のリクエストにお応えします。

    表札を指定してぼかしのご依頼を入れられるようになりました。該当する画像左下にある「問題を報告」をクリックし、「表札」を選択して、ぼかしを加えたい表札を選んで送信を押してください。ご本人の意思を尊重させていただくため、ご自宅を申請された場合のみの対応とさせていただきます。


ご懸念の声を真摯に伺いつつも、たくさんの方々がストリートビューを役立てていらっしゃる、というお話を伺うにつれ、このサービスを続けていくことも、Google が社会のなかで役割を果たすことにつながるのではないかと、私たちは改めて考えるようになりました。ただ、継続にあたっては、この新しいサービスを社会に受け入れていただくために、さまざまな方との対話を続け、その対話を通じて改善を積み重ねていくことが、私たちに課された責務であるということも、重く受け止めています。

今回の変更が、ストリートビューに関する皆様のご心配をすこしでも和らげ、安心してお使いいただけるきっかけとなれば幸いです。サービス向上のために率直なご意見をいただいた利用者の皆様、ネットコミュニティの方々に改めて篤く御礼を申し上げます。これからも、皆様のご意見を頂戴し、より安心して、より便利にお使いいただけるよう、改善を続けてまいりますので、Google マップおよびストリートビューに、皆様の暖かいお力添えをいただければと思います。今後ともどうぞよろしくお願い申し上げます。
Share on Twitter Share on Facebook


C や C++ でプログラムの書いたことのある多くの人は、「プログラムを高速化したいけれど、どこが一番のボトルネックか分からない」とか、「メモリリークがあるようだけれど、どこで発生しているか分からない」といった問題で苦しめられた経験が一度くらいはあると思います。もちろん、こうした問題の解決策として、アドホックにプログラムをチューニングしたり、目でプログラムを追ってメモリリークの発生箇所を突き詰めることも可能ですが、時間がかかってしまうことが多々ありますし、あまり楽しい作業でもないと思います。

そんなときに役に立つのが、Performance tools です。具体的には、このソフトウェアは以下の 4 つのツールで構成されています。

これらのツールを使って、プログラムの高速化やバグの検出などを行なうことができます。例えば、Heap Profiler を使えば、プログラム中のどこでどれだけメモリが使用されているかを、簡単に把握することができます。下の図のような、ノードが各関数の中で確保されているメモリの量を、エッジが関数の呼び出し関係を表す有向グラフとして、メモリの使用状況を可視化することができます。



同様に、CPU Profiler を使えば以下のような重みつきコールグラフを出力することができます。このグラフを見ながらプログラム中のボトルネックを特定するといったこともできるでしょう。



Performance toolsの使い方

使い方は簡単です。基本的には、どのツールもTCMalloc のライブラリをリンクするだけで使用する事ができ、 ソースコードの変更は必要はありません。例えば gcc を使ってプログラムをコンパイルしている場合でしたら、"-ltcmalloc" をコンパイルオプションに付け加えるだけで、 TCMalloc の提供する malloc/free がプログラム中で呼ばれるようになります。例えば、

gcc [...] -ltcmalloc

とするだけです。また、Heap Profiler であれば、

gcc [...] -o myprogram -ltcmalloc
HEAPPROFILE=/tmp/profile ./myprogram


と実行することで、メモリの使用状況のログを取ることができます。この場合ですと、定期的に(例えば 1 GB メモリが割り当てられる度に)、/tmp 以下に profile.0001.heap、...、profile.0100.heapといったログファイルが生成されます。このログファイルを以下のように pprof に与えると、先に述べたようなグラフが表示されます。

pprof --gv myprogram profile.0100.heap

TCMalloc

以上に述べたツールの中で、ここでは特に、TCMalloc (Thread-Caching Malloc) について少し詳しく解説します。これは高速な malloc の実装で、例えば glibc 2.3 malloc (ptmalloc2) との比較で、ptmalloc2 で(サイズの小さなオブジェクトの)malloc/free に約 300 ナノ秒かかったところ、TCMalloc では約 50 ナノ秒しかかからなかったという実験結果があります(2.8 GHz の P4 上での測定)。

TCMalloc は、大きく言って 2 つの特長を持ちます。1 つは、マルチスレッドプログラムにおけるロックの競合を削減しているという点です。サイズの小さなオブジェクト (<= 32K) の malloc/free においては、ロックの競合はほとんど発生せず、大きなオブジェクトにおいても、細粒度で効率的な spin lock を用いるようにしています。もう 1 つの特長は、サイズの小さなオブジェクトをメモリ効率の良い方法で表現するということです。単純な malloc/free の実装だと、各オブジェクトごとに(例えば 4 バイトの)ヘッダを用意し、そこにオブジェクトのサイズなどの情報を格納しておく必要があります。これは、オブジェクト解放時に、そのオブジェクトのアドレスから解放すべきメモリサイズを計算するためです。それに対してTCMalloc では、例えば 8 バイトのオブジェクトを N 個確保するのに約 8N * 1.01 バイトしか必要としません。

それでは、TCMalloc がどう実装されているかについて、簡単に説明します。TCMalloc によって管理されるメモリは、各スレッドごとに用意された「スレッドキャッシュ」と、全スレッドによって共有される「中央ヒープ」から成ります。基本的には、サイズが 32K 以下のオブジェクトはスレッドキャッシュ上に確保され、それより大きなオブジェクトは中央ヒープに確保されます。スレッドキャッシュ上ではロックを必要とせずにオブジェクトを確保することができるため、高速化が図れます。



スレッドキャッシュは、各オブジェクトをそのサイズに応じて「クラス」に分類することによって、効率的なメモリ管理を実現しています。例えば、サイズが 1 バイトから 8 バイトのオブジェクトはクラス 0 に、サイズが 9 バイトから 16 バイトのオブジェクトはクラス 1 に分類されます。そして、このクラスごとに、空きオブジェクトを管理するための連結リストが用意されています。



例えば、サイズが 14 バイトのオブジェクトを確保する際には、クラス 1 の空きリストから先頭の要素を取り出して、それを使うようにします。また、オブジェクトを解放する際には、そのオブジェクトのアドレス(ページ番号)から、クラスを計算できるようにしておきます。こうすることで、各オブジェクトごとにヘッダを用意して、サイズを記憶しておく必要がなくなります。

まとめ

Google が公開している Performance tools、特に TCMalloc について説明しました。もし少しでも興味を持った方は、是非使ってみてください。より詳しい情報を知りたい方は、Wiki(英語)ソースコードなどを参照して下さい。
Share on Twitter Share on Facebook