京都会場では Google の及川卓也と、さくらインターネット研究所の松本直人さんによる TechTalk、はてなの近藤淳也さんとさくらインターネットの田中邦裕さんによる講評を頂きました。（リンクからすべての動画にアクセスできます。）
[Hack For Japan 京都会場より。 HFJ の文字が読めますか？]
Hack For Japan は、開発者の皆様の力が求められている「今」、皆様が使えるツールを提供したり、自分が足りないスキルを補ってくれる仲間を捜したり、求められているサービスを知ることで開発者が活躍できる場を提供する為のプロジェクトです。ご協力頂いた皆様に感謝するとともに、Hack For Japan の真価はこれらの場やツールを開発者の皆様がどれだけ利用して、よいサービスを作ってくださるかにかかっています。引き続きどうぞよろしくお願いします。
なお、オフライン会場の手配は全て各地の GTUG (Google Technology User Group)の皆様が行ってくださいました。また、開催にあたって Google API Expert の皆様からたくさんのアドバイスを頂きました。改めて御礼申し上げます。
あるレコードに対するユニーク ID であり、ドメイン名と、それにスラッシュとローカル ID が続く。ドメイン名はこのレコードに対して権限を持つホームレポジトリを示す。ローカル ID のフォーマットはホームレポジトリに任せられる。person_record_id が、そのアプリケーション自身と異なるドメインから始まっている場合、その record は他の source から得られたクローンであることを意味する。
entry_date(string in the form "yyyy-mm-ddThh:mm:ssZ"):
この record のコピーが保存された UTC 時刻。PFIF レポジトリは、record が追加時のこの値が単調増加することを保証しなければならない。それにより、クライアントは最後に受け取った entry_date 以降の entry_date をもつ record を要求することによってレポジトリのコピーを更新することができる。
author_name(string):
情報提供者のフルネーム。
author_email(string):
情報提供者のメールアドレス。
author_phone(string):
情報提供者の電話番号。
source_name(string):
この record のホームレポジトリの名前（情報元のサイト名）。
source_date(string in the form "yyyy-mm-ddThh:mm:ssZ"):
自由形式のテキストデータで、他の source から持ち込まれた静的なデータに使われます（他の source からインポートされた動的なデータは NOTE record に保存されるべきです）。短いフィールドは一行で、フィールド名、コロン、値で表現されます。長いフィールドは、フィールド名とコロンの行に続いてインデントされた文字列で表現されます。機械的な処理で他の形式から PFIF 形式に record が変換された場合は、"automated-pfif-author"フィールドが存在すべきです。このフィールドは PFIF を作成したプログラム名を表します。PFIF レポジトリから record がエクスポートされた場合には"automated-piff-author"フィールドは付加されません。人に対する自由形式テキストの説明も"description"のフィールド名でここに表されます。たとえば、自由形式文字列フィールドを持つ PFIF 以外のフォーマットから record を取得するプログラムは other フィールドを含み、それは次のようになるでしょう：
description:
Dark hair, in her late thirties.
Also goes by the names "Kate" or "Katie".
automated-pfif-author: ScrapeMatic 0.5
他のアプリケーションからインポートされたフィールドに対する名前はドメイン名とスラッシュを始めに付加されるべきです。例えば、ICRC record から生年月日がインポートされた場合は次のようになります：
（訳注：この例は PFIF 1.1 当時のもの。実際には PFIF 1.2には生年月日専用のフィールドが用意されています）
icrc.org/birthdate: 1976-02-26
sex(string):
探している人、見つかった人の身体的性別。female、male、 other の 3 つのうち 1 つで指定されます。性別不明の場合はこのフィールドを省略してください。
探している人、見つかった人の母国。大文字 2 文字の ISO 3166-1 country code で指定されます。
NOTE records
NOTE record はちょうどひとつの PERSON record に属します。ある PERSON record には任意の数の NOTE record が関連付けられます。すべての note はタイムスタンプと note の著者情報を持ちます。アプリケーションはタイムスタンプを、フィールドの最新情報を決定するのに使えます。ユーザーは著者情報をフィールドの信頼性を確かめるために使うことができます。
これらのフィールドは時間とともに変化する情報を保存します。これらのフィールドが NOTE record に現れたときは、この record はこれらのフィールドに対する新しい値を定めます。source_date フィールドは新しい値が効力を持つ日付を示します。例えば、最新の場所情報を表示したいアプリケーションは、last_known_location フィールドを持っていてるもののうち最新の source_data を持つ NOTE を参照すればいいことになります。
note_record_id(string):
この record のユニーク ID であり、ドメイン名にスラッシュ、ローカル ID が続きます。ドメイン名はこの record の権限を持つホームレポジトリの識別子です。ローカル ID のフォーマットはホームレポジトリに任されています。note_record_id がアプリケーションのドメインと異なったドメインから始まっている場合、この record は他の source からのクローンであることを意味します。
entry_date(string in the form "yyyy-mm-ddThh:mm:ssZ"):
この record のコピーが保存された UTC 時刻。PFIF レポジトリは、record が追加時のこの値が単調増加することを保証しなければなりません。それにより、クライアントは最後に受け取った entry_date 以降のentry_date をもつ record を要求することによってレポジトリのコピーを更新することができます。
author_name(string):
情報提供者のフルネーム。
author_email(string):
情報提供者の e-mail address。
author_phone(string):
情報提供者の電話番号。
source_date(string in the form "yyyy-mm-ddThh:mm:ssZ"):
この record がホームレポジトリ内で作成された時刻（情報元の投稿日）。ほとんどのケースで、note はこのフィールドでソートして表示されるべきでしょう。
found(boolean string, "true" or "false"):
行方不明者に連絡が取れた場合、会えた場合は"true", さもなくば"false"の値をとります。この note の text フィールドで、いつどこで連絡が取れたか、会えたかを説明するべきです。
email_of_found_person(string):
見つかった人の連絡先 e-mail です。このフィールドは人物が見つかった場合のみ存在します。この note の text フィールドでどのように連絡先情報が決定されたか説明するべきです。
phone_of_found_person(string):
見つかった人の連絡先電話番号です。このフィールドは人物が見つかった場合のみ存在します。この note の text フィールドでどのように連絡先情報が決定されたか説明するべきです。
last_known_location(string):
捜索されている人を最後に見かけた場所を述べた自由形式説明であり、市や都道府県など、できるだけ詳細に述べた情報です。この note の text フィールドはどのように所在地が決定されたか述べるべきです。
この NOTE record が関連づいている PERSON record の person_record_id です。
linked_person_record_id(string):
この NOTE record が、同一人物に対する重複 record であると主張している他の PERSON record のperson_record_id です。
ユーザーがある 2 つの PERSON record を重複だと示すときには、NOTE record をそれら両方の PERSON record に付加し、それぞれに linked_person_record_id フィールドを持たせ、相互に指し示します。これらの NOTE record はこれらを重複だと示した関係者を示す author_name フィールドを持ち、text フィールドに重複だと判断するにいたった理由を付加します。
Notes
String fields は non-ASCII character を含められます。
PFIF 1.2 では person 要素の外にトップレベルの note 要素を許します。正しい PFIF ドキュメントはひとつの pfif 要素からなり、それはひとつ以上の person か note 要素を持ちます。
note 要素が person 要素の外に現れる場合、note は person_record_id をもつ必要があります。それ以外の場合には person_record_id フィールドは任意ですが、存在する場合には note を含んでいる person の person_record_id と一致する必要があります。
person 要素の中では、 必須の person_record_id がはじめにくる必要があり、note 要素は最後に来る必要があります。note 要素の中では、note_record_id が最初に来る必要があり、もし存在するときには person_record_id がそれに続くべきです。残りのフィールドは任意の順番であらわれることができます。
Google のサービスを利用するとき、ユーザーの皆さんがどのように名乗るか（あるいは名乗らないか）、その色々な方法について Google は考えてきました。本人証明が役に立つサービスもあれば、本人証明が必要とされる場合もありますし、逆に本人証明が任意でもよかったり、不要だったりもします。属性(attribution)はとても重要です。しかし、仮名や匿名という手段も文化の一部を担っており、それにはきちんとした理由があるのです。
Google のサービスでは無記名、仮名、記名の 3 つに対応しています。各々のモードには、各々のユーザーベネフィットがあります。
Google では、ユーザーの皆さんに対して更に透明性を高めるため、他の方法も検討しています。Google が提供する製品の中には、そのサービスが何の為に作られたのかによって、これらの 3 つのモードのうち 1 つか 2 つのモードのみに適している物もあります。ただし、 Google はこれら 3 つのモードすべてが Google のサービスにある、と考えています。
一例ですが、先日リニューアルされた Google Profiles は、自分の名前で検索されたときに何が表示されるか、自分にとってどんな情報が重要でハイライトしたいのか、自分について何を知ってもらいたいのかを自分がコントロールすることができるサービスです。この Google Profiles はウェブ上に情報を公開し、現実の人とつながるために設計されたサービスですので、実世界でよく使っている名前を使って頂くようお願いしています。
この新しい機能によって、より多くのデータセットが Public Data Explorer の視覚化を通じて活かされ、人々が世界をもっと理解したり、より多くの情報を手に入れたり、データに基づく意思決定が可能になったりすることを願っています。新しいデータセット、視覚化の機能、DSPL の拡張など、今後も楽しみにしていてください。
山崎: Google Code Jam Japan 2011 の開催がアナウンスされましたね。改めて Google Code Jam について教えてください。
yukoc: Google Code Jam は複雑なアルゴリズムの問題を限られた時間の中で解く能力を競う個人戦のプログラミングコンテストです。世界大会は 2003 年から行われていて、世界中から参加があります。学生、社会人問わず参加ができ、世界大会の最終ラウンドには、開催国の Google のオフィスにさまざまな国からプログラマーが集まります。
Code Jam Japan は予選ラウンドと最終ラウンドともに日本時間の週末午後にオンラインで行われるので、より多くの方に参加していただけるのではと期待しています。
山崎: Code Jam Japan は Google Japan 主催、日本語での出題で、日本在住の方が対象だと伺いました。
dmikurube: はい。ルールも日本語で表記しており、大会に関する質問も日本語で受け付けます。今までの Google Code Jam では「英語を読むのが面倒くさいなあ」「難しそうだなあ」と感じていた方も、今回の Code Jam Japan は気軽に参加していただけるようになっています。
山崎: 今のうちに準備したい方のために役に立つサイトはありますか？
pascal: クイックスタートガイド や過去問 （英語） は参考になると思いますのでぜひ読んでみてください。また Google との関係はありませんが、TopCoder の Single Round Match （例）も問題の方向性としては似ていると思います。
山崎: Code Jam Japan 2011 の準備にあたっての裏話などあれば教えてください。
ykonishi/frank: Google Japan のエンジニアの中には Google 入社前に ACM ICPC や TopCoder、そしてもちろん Google Code Jam 世界大会などのプログラミングコンテストに参加していた者も多数おります。これらのコンテストは非常に楽しいものですが、日本の優秀なプログラマーの中にはこれらの大会が英語で行われているために参加しないという方が多いということも知っています。そこで、このたび Code Jam チームと共に日本語のコンテストを開催することにしたのです。世界大会と同様、日本大会は Google の社員が問題からルールまですべてを手がけました。社内のカフェで夕飯を囲みながら T シャツのデザインや参加規約について話したり、加点方式を決めるのに 2 時間議論したりしました。
Google App Engine の新しい API Expert として、小川信一さんに就任して頂くことになりました。オープンソースのフレームワーク Slim3 の開発メンバーの一人であり、また、appengine ja night 等のコミュニティで積極的な活動を行われています。小川さん、よろしくお願いします！
