Google Developers Japan: 3月 2011

Android Market でアプリ内課金サービスを開始しました

2011年3月30日水曜日

Posted by 山崎富美 / Developer Relations Team
[本記事は、Android Developers Blog にて、Google の Android Developer Ecosystem チームの Eric Chu が執筆した In-app Billing Launched on Android Market を翻訳・再構成したものです-山崎]こちらTap Tap RevengeComicsGun BrosDeer Hunter Challenge HDWSOP3Dungeon Defenders: FW Deluxe

詳しいドキュメントサンプルアプリケーションサービスの実装プロダクトリストのセットアップテストの方法セキュリティガイドライ

Hack For Japan Hackathon を開催しました

2011年3月25日金曜日

Posted by 山崎富美 / Developer Relations Teamこんなサービスを作ってほしい何か役に立ちたいけど、どんなサービスが求められているのかわからないアイディアはあるけど、インプリについて有志で議論したいサービスを作ろうと思っているけれど、クラウドってお金がかかるよねGoogle Moderator （1 日目, 2 日目, 3 日目）いくつかのプロジェクト賛同企業 15 社／賛同者 549 人Google Moderator 565 人258 個のアイデア5,447 個の投票Google Wave 1,279 個のコメント（1 日目, 2 日目, 3 日目）Twitter での議論のまとめこちら英語での Google Wave こちら京都会場（62 人が参加）こちらこちらこちら福岡会場（7人が参加）岡山会場（10人が参加）こちら徳島会場（4人が参加）

[京都会場での集合写真]

Google Moderator Google Map上に避難所を表示し、そこに避難所の情報（避難している人数、足りないものなど）を紐付ける。避難所へのルートも確認できるようにし、支援物資の輸送の手助けとする。とにかく情報が分かりやすく確認できるものが必要だと思います。避難民受け入れマップ：非被災地の自治体で被災地地域住民の受け入れを表明している情報を一覧可視化、空き情報などをアップデート、ネットや通信環境が充分でない人のために斡旋仲介をできる体制など。支援物資の避難所までの経路を中継地点ごとにビジュアルで表示し、支援物資の需要と供給を一元管理できるような仕組み。 各避難所からは必要物資と数量を書き込め、各避難所に近い中継地点にもそれらの数値が反映される。また各中継地点には、中継可能地点や全国からの送付受付可能かどうかなどの情報や現時点の在庫、必要数、倉庫のキャパシティなどの情報が表示される。避難所はもちろん近隣や隣県で倉庫を持っている人などは中継地点としての登録もできるようにする。各避難所に泊まっている人数や、家がなくなってしまって探している人の人数、問題を抱えている人の人数がタイムラインになっていて、日々の改善状況が一目でわかるシステム。改善されていない避難所を知るために必要だと思います。被災各地での技術者マッチングシステム。医療関係者からボランティアまで、「どの場所にどういった人材が不足しているか」を被災者または現地訪問者がアップロード、支援者(または現地で活動可能な方)とのマッチングを行う。またその際「今すぐ必要or1週間以内」「作業従事者or資格保持者or 資格なしでも可能」「機材として○○希望」などのタグを設け、適切に必要な人材が手配できるようにする。復興期においては、同プラットフォームを人材募集にも活用できると良いか。

震災では、今後、中長期的に、こころのケアがとても重要になってくると思います。東京都福祉保健局によりこのようなPDFファイルが作成され配られていますが、この11ページや12ページの質問項目を使って、スクリーニングツールを作成したり、携帯端末でこの資料にあるような内容を一般向けに分かりやすく伝えるツールを作成したりすることはどうでしょうか？

リアルタイム電力消費メータ。東電さんからはデータを提供していただく。都民は、そのリアルタイム電力消費メータを確認して、随時節電を敢行。

現在の交通の復旧状況を前提とした経路検索。既にリリースされているGoogleとホンダのマッシュアップ地図を利用。主に東北エリアを対象とするが、首都圏版では駅の混雑状況共有もできるとよい。

震災後に「飲み水を確保する方法」、「食べも物を確保する方法」、「SOSをあげる方法」、「寒さ、暑さをしのぐ方法」、「応急処置の方法」が辞典になってるアプリケーションが欲しい。WEBサービスでなくってアプリケーションで欲しい。なぜなら通信のインフラもつぶれてるかも知れないから。

電波・通信の通信・復興状況を Google maps に反映させる仕組み。 「ここまでは電波が届いているが、ここから先は届いていない」が視覚的に分かるもの。 http://togetter.com/li/111197　の情報などを上手く地図に反映できないだろうか？避難所の地図と連携させることで、情報孤立している避難所もわかってくる。

こちらさて、こうして提案されたアイディアから、実際に自分がやってみたいプロジェクトを提案するというのが Project list です。完成して公開済のプロジェクトは 2 個、アクティブ／作業中な物は 13 個（うち引き続きメンバー募集中の物が 3 個）、メンバー募集中の物は 3 個あります。
ハッカソン

[ハッカソン京都会場の様子]●京都会場デマだったー炊きだしたん5Goods地域ツイートわん！クリックで救助検はてな震災情報ペットファインダー●福岡会場どねったーどねーと牧場（仮）とりあえずAPI●岡山会場被災地マップ（仮）Act4LIVES- action for world lives -●徳島会場ReTweetPlus調査プロジェクト及川卓也松本直人さん近藤淳也さん田中邦裕さん講評

[Hack For Japan 京都会場より。 HFJ の文字が読めますか？]

Hack For Japan は、開発者の皆様の力が求められている「今」、皆様が使えるツールを提供したり、自分が足りないスキルを補ってくれる仲間を捜したり、求められているサービスを知ることで開発者が活躍できる場を提供する為のプロジェクトです。ご協力頂いた皆様に感謝するとともに、Hack For Japan の真価はこれらの場やツールを開発者の皆様がどれだけ利用して、よいサービスを作ってくださるかにかかっています。引き続きどうぞよろしくお願いします。

なお、オフライン会場の手配は全て各地の GTUG (Google Technology User Group)の皆様が行ってくださいました。また、開催にあたって Google API Expert の皆様からたくさんのアドバイスを頂きました。改めて御礼申し上げます。

クリエイティブコモンズ

“Hack For Japan” 開催のお知らせ

2011年3月19日土曜日

Posted by 山崎富美 / Developer Relations Team●背景と目的Google 災害情報ページ（Crisis Response page）sinsai.infoYahoo! JAPAN - 地震・津波災害に関する情報●会場はオンラインがメイン●使える技術こちら●使えるデータ●ご登録フォーム●3 月 19 日-20 日の ideathon について●開発プロジェクトと成果物のリスティング

【開催概要】

■日時: 3 月 19-20 日（ideathon）、3 月 21 日（hackathon）
■場所:

オンライン（Google Wave + Google Moderator）
京都会場　（定員 100 名）京都リサーチパーク 4 号館 2F ルーム 2　（アクセス）
福岡会場　（定員 20 名）　AiP カフェ　（アクセス）
岡山会場　（定員 30 名）　岡山りぶらホールB（アクセス）
徳島会場　（定員未定）　　月見ヶ丘海浜公園研修室（アクセス）

■Twitter のハッシュタグ: #hack4jp

■アイディアソン会場:（Hackathonの最中にももちろん使えます。）

■公式サイト: ”Hack For Japan”
■その他: 利用できる技術の一覧

●賛同人@takoratta@fumi@dmikurube@hayatoito@tmatsuo@vicfryzel@hyoshiok@KenTamagawa@shot6@waki@shin135@tomohn@satonaoki@yoikawa@miurahr@hal_sk@dddaisuke@shikajiro@jkondo@stanaka@kawanet@togachi@kohsei@yoichiro@hokayan@ttyokoyama

Google Person Finder API のドキュメンテーションの翻訳について 2

2011年3月15日火曜日

Posted by 山崎富美 / Developer Relations Team[先日「Google Person Finder API のドキュメンテーションの翻訳について」というブログ記事を公開しましたが、引き続きデータモデルの各フィールドの説明を中心に、ソフトウェアエンジニアの花岡俊行が翻訳をしてくれました。なお、正式版の翻訳については code site に掲載されるのをお待ちください-山崎]Data ModelPERSON records■メタ情報person_record_id (string):
あるレコードに対するユニーク 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"):
この record がホームレポジトリ内で作成された UTC 時刻（情報元の投稿日）。
source_url (string):
この record のホームレポジトリにおける URL（情報元の URL ）。
■識別情報first_name (string):
探している人、見つかった人のファーストネーム。スペースに続けてミドルネームも追加できる。
last_name (string):
探している人、見つかった人のラストネーム。
home_city (string, city name):
探している人、見つかった人の市。
home_state (string):
探している人、見つかった人の都道府県。
国の行政区域を大文字 ISO 3166-2 形式で表現します。
訳注： http://ja.wikipedia.org/wiki/ISO_3166-2:JP を参照
home_neighborhood (string):
探している人、見つかった人の近隣の場所。
home_street (string):
探している人、見つかった人の町名。
home_postal_code (integer):
探している人、見つかった人の郵便番号。
photo_url (string):
探している人、見つかった人を識別する写真への URL。
other (large string):
自由形式のテキストデータで、他の 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 つで指定されます。性別不明の場合はこのフィールドを省略してください。
date_of_birth (string):
探している人、見つかった人の正確な生年月日(YYYY-MM-DD)またはだいたいの生年月日(YYYY, YYYY-MM)。
age (string):
探している人、見つかった人のだいたいの年齢。source_date 時点での、生年月日からの年数。このフィールドの値はひとつの 10 進数整数か、2 つの 10 進整数をハイフンでわけた包含範囲を取る。source_date が指定されていない場合、このフィールドは定義されません。（訳注： 27 歳→ "27", 25 から 30 歳→"25-30"）
home_country (string):
探している人、見つかった人の母国。大文字 2 文字の ISO 3166-1 country code で指定されます。
NOTE recordssource_datenote_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 フィールドはどのように所在地が決定されたか述べるべきです。
text (large string):
自由形式の文字列であり、人物の状態や状況、最後に目撃された所在地の詳細の説明です。他の情報の訂正であることもあるでしょう。
status (string):
探している人、見つかった人の状態で次の 5 つの文字列のうちの 1 つを取ります。

information_sought

情報提供者は対象の person の情報を探しています。

is_note_author

情報提供者は対象の person 自身です。

believed_alive

情報提供者は対象の person が生きているという情報を入手しました。

believed_missing

情報提供者には対象の person が行方不明と判断した理由があります。

believed_dead

情報提供者は対象の person が亡くなっているという情報を入手しました。

person_record_id (string):
この 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 フィールドに重複だと判断するにいたった理由を付加します。
Notesperson_record_idperson_record_idperson_record_idnote_record_idperson_record_id

Google Person Finder API のドキュメンテーションの翻訳について

2011年3月13日日曜日

Posted by 山崎富美 / Developer Relations Team[先日「東北地方太平洋沖地震を受けて」というブログ記事でご紹介した Google Person Finder ですが、API のドキュメンテーションを翻訳して欲しいとのご要望を頂いたのを受けて、ソフトウェアエンジニアの花岡俊行が翻訳をしてくれました。なお、正式版の翻訳については code site に掲載されるのをお待ちください-山崎]●Google Person Finder Data API documentationHow to download or upload data using the Person Finder API.Person Finder API を使ったデータのダウンロード・アップロード方法Person Finder アプリケーションはレコードを People Finder Interchange Format (PFIF) で保存、エクスポートします。PFIF は XML ベースのフォーマットです。PFIF に関するドキュメントは以下より参照できます。PFIF 1.2 specificationPFIF 1.2 example documentPFIF FAQ and implementation guidelines●Downloading data from Person FinderPerson Finder からデータをダウンロードする方法Person Finder からデータをダウンロードするには、authorization token が必要です。authorization token はこちらのフォームから申し込むことができます。PFIF 1.2 person feed と note feed はここからアクセスできます。
https://subdomain.person-finder.appspot.com/feeds/person?key=auth_token
https://subdomain.person-finder.appspot.com/feeds/note?key=auth_tokenデフォルトでは、これらの feed は最も最近に追加された person レコードや note レコードを日付順に新しいものから返します。以下の query パラメータがサポートされています。

max_results: Return up to the specified number of results (maximum 200).

max_results: 指定された数を上限として結果を返します。(指定できる上限は 200)

skip: Skip the specified number of records before returning the next max_results results.

skip: 次の|max_results|個の結果を返す前に、指定された数の結果をスキップします。

min_entry_date: Return only results with an entry_date greater than or equal to the specified timestamp, which should be in UTC in yyyy-mm-ddThh:mm:ssZ format. If this parameter is specified, results will be returned in forward chronological order.

min_entry_date:指定された日付以降のタイムスタンプの entry_gate を持つ結果のみを返します。タイムスタンプは UTC で yyyy-mm-ddThh:mm:ssZ のフォーマットで指定します。このパラメータが指定された場合、結果は日付順に古いものから返します。

person_record_id: Return only notes for this person record. This parameter is only valid for the note feed.

person_record_id: note feed のみで有効なパラメータです。指定された person record に対する notes のみ返します。

person_record_id パラメータは特定の人に対する note feed を subscribe するのに使えます。Google Person Finder データベースと同期した他のデータベースが必要な場合、min_entry_date と skip パラメータを使って更新の増加分をダウンロードすることができます。最後に Google Person Finder から受け取った entry_date を、最初のリクエストの min_entry_date として用いてください。そしてそのリクエストの結果得られた中で最新の entry_date を、さらに次のリクエストの min_entry_date に用います。skip パラメータは既に得られた、同じ entry_date を持つ record をスキップするのに使うことができます。このアルゴリズムは tools/download_feed.py で実装されています。特定の人の PFIF person_record_id がわかっている場合、notes 付きの単一の PFIF person record を次の URL から得ることができます。
https://subdomain.person-finder.appspot.com/api/read?key=auth_token&id=person_record_id●Using the Person Finder Search APIPerson Finder Search API を使う方法Person Finder Search API を使うには、authorization token が必要です。authorization token はこのフォームより申し込むことができます。search API はここからアクセスできます：
https://person-finder.appspot.com/api/search?key=auth_token&subdomain=subdomain&q=your query ●Uploading data into Person FinderPerson Finder にデータをアップロードする方法
ひとつまたは複数の PFIF record を Person Finder にアップロードすることができます。アップロードは次の URL に XML ファイルを post することによって行えます。https://subdomain.person-finder.appspot.com/api/write?key=auth_token
PFIF 1.1, 1.2 の両方が受理されます。auth_token を得るには、pf-authkey@google.com に連絡してください。どの PFIF source domain に対して authorization token を使うかを明記する必要があります。authorization token は、その domain を prefix にもつ person_record_id の person record のアップロードのみに使うことができます。XML ファイルが用意できたら、次のコマンドでアップロードすることができます。curl -X POST -H 'Content-type: application/xml' --data-binary @your_file.xml \ https://subdomain.person-finder.appspot.com/api/write?key=auth_token
elements with nested elements. To understand the proper XML format, see the PFIF example document. We recommend that you upload a single record or a small number of records as a test, retrieve the records using the Individual Person Record API (/api/read), and view the records on the site to verify that the results are what you expected. Pay careful attention to the handling of accented letters, note text, source URLs, and photo URLs (if you have them).XML ドキュメントは、ネストされた 要素を持つことができます。厳密な XML フォーマットについての詳細は、PFIF example document を参照してください。まずテストとして、単一か少数の record をアップロードし、その結果を individual Person Record API (/api/read) を使って record を検索し、結果が予想通りになっているかどうかを確かめてみることをお勧めします。アクセント付き文字、note 文字列、source URL、photo URL を使っている場合は、特に注意を払ってください。
Due to the size limitation on POST requests, you should split up files into batches of 100 elements. If you encounter an error, or need to correct problems in a previous upload, it is safe to upload the same records again. Records will replace existing records with the sameperson_record_id or note_record_id.
POST リクエストのサイズ制限により、ファイルを 100 要素ごとに分割する必要があります。エラーが発生した場合、または以前のアップロードを訂正する必要がある場合、同じ record をもう一度送っても問題ありません。同一の person_record_id か note_record_id を持つ record は上書きされます。

The response will be an XML document like this:
response は次のような XML document になるでしょう：
<?xml version="1.0"?> <status:status> <status:write> <status:record_type>pfif:person</status:record_type> <status:parsed>1</status:parsed> <status:written>1</status:written> <status:skipped> </status:skipped> </status:write> <status:write> <status:record_type>pfif:note</status:record_type> <status:parsed>1</status:parsed> <status:written>1</status:written> <status:skipped> </status:skipped> </status:write> </status:status>それぞれの <status:write> 要素はひとつの書き込みバッチ操作を表しています。<status:record_type> はバッチ操作の種類です。<status:parsed> はいくつの XML record が正しくパースできたかを記述しています。<status:written> はいくつの record がデータストアに書き込まれたか記述しています。上の例では 1 つの person と 1 つの note が正しく書き込まれました。問題が起こったときは次のようになるでしょう。<?xml version="1.0"?> <status:status> <status:write> <status:record_type>pfif:person</status:record_type> <status:parsed>1</status:parsed> <status:written>0</status:written> <status:skipped> <pfif:person_record_id>google.com/person.4040</pfif:person_record_id> <status:error>not in authorized domain: u'google.com/person.4040'</status:error> </status:skipped> </status:write> <status:write> <status:record_type>pfif:note</status:record_type> <status:parsed>1</status:parsed> <status:written>0</status:written> <status:skipped> <pfif:note_record_id>zesty.ca/note.53</pfif:note_record_id> <status:error>ValueError: bad datetime: u'xyz'</status:error> </status:skipped> </status:write> </status:status> entry describes the reason why a particular record was skipped, and includes the record ID if one was given.
それぞれのエントリはあるレコードがなぜスキップされたか記述しており、record ID が指定されていればそれを含みます。
When you upload person or note records, you will be replacing any existing records with the same record ID. It should be safe to upload the same data multiple times while you fix formatting problems.
person record や note record をアップロードした場合、同一の record ID をもつ record はすべて上書きされます。フォーマット問題を修正するために同一のデータを複数回アップロードすることは安全に行えます。

東日本大震災（東北地方太平洋沖地震）を受けて

2011年3月13日日曜日

Posted by 山崎富美 / Developer Relations TeamGoogle Crisis Response 東日本大震災（東北地方太平洋沖地震）特設サイト

Google Person Finder http://goo.gl/sagas●Google Person Finder をサイトに組み込める embed コードを提供しています。

以下の HTML コードをコピーして貼り付けてください。<iframe src="http://japan.person-finder.appspot.com/?small=yes&lang=ja" width=400 height=300 frameborder=0 style="border: dashed 2px #77c"></iframe>
特設サイトPerson Finder携帯電話からも使えますトップページhttp://goo.gl/REFVG

YouTube の TBS News-i チャンネル地震関連ニュースをライブストリーミング避難所情報

鉄道の遅延情報Japan Earthquake Photos震災地の写真を見ることができるようになりましたKML ファイルGoogle EarthGoogle MapsPicasa album

[地震と津波の前後の写真]
●「地震」というキーワードでの検索結果には、地震速報や緊急用ダイヤルの使い方などの関連情報を掲載しています。

オンラインアイデンティティについて

2011年3月10日木曜日

Posted by 山崎富美 / Developer Relations Team
[本記事は、Google Public Policy Blog にGoogle の Director of Privacy, Product and Engineering である Alma Whitten が投稿した The freedom to be who you want to be...と Google Social Web Blog に Product Manager の Greg Marra が投稿した Decide what the world sees when it searches for you を翻訳・再構成したものです-山崎]
「インターネット上では、誰もあなたが犬だとは思わないだろう」というピータースタイナーの風刺画は冗談で描かれたものかもしれません。しかし、中東や北アフリカ地域での最近の出来事が示すように、彼の指摘したことはとても重大なことでした。ウェブが発展し、ユーザーはどこにいてもブログ記事を投稿したり、友人や家族と写真を共有したり、目にした出来事をオンラインで放送したりすることができるようになりました。そんな中、アイデンティティの問題がますます重要になってきたのです。
Google のサービスを利用するとき、ユーザーの皆さんがどのように名乗るか（あるいは名乗らないか）、その色々な方法について Google は考えてきました。本人証明が役に立つサービスもあれば、本人証明が必要とされる場合もありますし、逆に本人証明が任意でもよかったり、不要だったりもします。属性(attribution)はとても重要です。しかし、仮名や匿名という手段も文化の一部を担っており、それにはきちんとした理由があるのです。
Google のサービスでは無記名、仮名、記名の 3 つに対応しています。各々のモードには、各々のユーザーベネフィットがあります。
無記名: 自分の実名や仮名に結びつけることなく、オンラインの活動をしたい時がときどきあるでしょう。たとえば、医療関係について調べるときや、特別な方への素敵なプレゼントを探すときなどです。このようなときは、Google Account にログインしなくても（あるいはサインアップすらしたことがなくても）、Google のサービスを利用することができます。サービスを提供する上で、IP アドレスやクッキーのような情報は必要になりますが、ログアウトしている場合はそれらの情報を個人のアカウントにリンクすることはありません。
仮名（ハンドルネーム）: 仮名のおかげで人々はネット上で自由に自己表現を行うことができるようになったことからもわかる通り、仮名はインターネットの大きな利点の 1 つです。仮名を使う人は、物理的に危険な状態にあるのかもしれませんし、何かの助けを求めているのかもしれません。また、自分について知られたくない状況にある場合もあるでしょう。そんな事情がある場合、一貫したアイデンティティをもつことは必要かもしれませんが、オフラインの本人とは結びつかないものである必要があるでしょう。YouTube への動画のアップロードや、Blogger への投稿は仮名を使うことができます。
記名: 人と情報を共有するときに、相手に自分が何者なのかを知ってもらいたいということはよくあると思います。 Google Checkout などのいくつかの製品が、このような身元確認に依存しており、サービスを利用するためには、利用者自身が身元を明らかにすることが必要です。身元を明らかにすることが、しないことに比べてより望ましい場合もあるでしょう。たとえば、あなたが地域社会活動のプロジェクトに参加したいと思ったとき「オンラインで見たこの人達が、本当にコミュニティのメンバーであるとどうやって知ればよいのだろう？」と考えることがあるかもしれません。
なりたい自分になれる（オンラインアイデンティティをコントロールできる）という自由をユーザーに提供するのと同じぐらい重要なのは、Google のサービスを利用する時に自分がどのモードにいるのかを正確に知ることができるようにすることです。そこで最近、Google では多くのサービスで、これを明確に示すために、ページの一番上にあるナビゲーションバーを変更しました。各サービスを使うときに、ページの右上に、どのアカウントでログインしているか（もしくはしていないか）を見ることができます。

Google Profiles

より速く、シンプルで安全に : Chrome 10 安定版をリリースしました

2011年3月9日水曜日

Posted by 北村英志 / Developer Relations Team[この記事はソフトウェアエンジニアの Tim Steele が Google Chrome Blog に投稿した Speedier, simpler and safer: Chrome’s basics get even better という記事を元にデベロッパーアドボケイトの北村英志が翻訳・作成しています。 -山崎]ブックマークのインポートデフォルトのトップページ設定秘密のフレーズで暗号化同期を開始ダウンロード

Google Public Data Explorer を使ってデータを視覚的に表示しましょう

2011年3月9日水曜日

Posted by 山崎富美 / Developer Relations Team[本記事は、The Official Google Blog にて、Google Public Data Team の Omar Benjelloun が投稿した Visualize your own data in the Google Public Data Explorer を翻訳したものです]失業率や人口統計世界開発指標（世界銀行）Public Data Explorer ツール27 のデータセット労働生産性インターネットの速度議会の男女比率政府の債務レベル地方自治体別の人口密度皆さんのData Publishing Language（DSPL）アップロードするPublic Data Explorer ディレクトリこちら

Google Code Jam Japan 2011 の開催について

2011年3月3日木曜日

Posted by 山崎富美 / Developer Relations Team
Google Code Jam Japan 2011

山崎yukoc山崎yuizumi山崎ykonishi山崎dmikurube山崎pascalクイックスタートガイド過去問TopCoder例山崎ykonishi/frank

（Code Jam Japan 2011 の準備風景）山崎nya山崎●開催概要●
3 月 19 日（土）3 月 26 日（土）こちらhttp://code.google.com/codejam/japan

Google API Expert ミーティング 2月を開催しました

2011年3月3日木曜日

Posted by 山崎富美 / Developer Relations TeamGoogle API Expert【準公式コミュニティと API Expert の一覧】http://sites.google.com/site/devreljp/Home/api-expertそれでは、2 月 24 日に開催された API Expert ミーティングの内容から、いくつかハイライトをお伝えします。

【新 API Expert のお知らせ】

Google App Engine の新しい API Expert として、小川信一さんに就任して頂くことになりました。オープンソースのフレームワーク Slim3 の開発メンバーの一人であり、また、appengine ja night 等のコミュニティで積極的な活動を行われています。小川さん、よろしくお願いします！

小川さんのブログ: 「404 shin1のつぶやきないわー Not Found」
小川さんの著書: 「オープンソース徹底活用 Slim3 on Google App Engine for Java」（秀和システム）

【Chrome API Developers JP】

前回の API Expert ミーティングで承認された「Chrome API Developers JP」が活動を開始しました。このコミュニティをリードしてくださる太田昌吾さん、よろしくお願いします！なお、「Chrome API Developers JP」の始動にあわせて、「Chromium Extensions Japan」は、2 月 18 日をもって活動を休止することになりました。Chrome に関心のあるデベロッパーの皆さんは新しいコミュニティにぜひご登録をお願いします。

【リリース情報】

【イベントのお知らせ】

Geo Tech Talk （3 月 7 日（東京）、3 月 8 日（京都））

【出版のお知らせ】
API Expert が執筆された最新書籍をご紹介します。

小松健作さん（HTML5 API Expert）と古籏一浩さん（Maps API Expert）他共著の書籍「JavaScriptコーディングベストプラクティス高速かつ堅牢なコードを効率よく書くために」（MdN）

JavaScript の高速化と開発効率をアップするベストプラクティスをまとめたもので、スマートフォン、HTML5、CSS3など最新の話題にも言及した、JavaScript上級者向けの書籍です。
なお、今回私は出張のため Google シドニーオフィスから参加しました。下記はシドニーオフィスのエントランスの様子です。

Google Maps Data API が deprecated になりました

2011年3月1日火曜日

Posted by 山崎富美 / Developer Relations Team[この記事は、2010年11月に Google Geo Developers Blog に投稿された Maps Data API deprecation announcement (Maps API Product Manager の Thor Mitchell が執筆)を元に作成したものです]Maps Data APIFusion Tablesローンチ空間クエリ大幅に増加データ解放ツールFAQMaps Data API フォーラム

Japan