Outlook 2010 では Twitter もサポートされるのか？

Announcing the Outlook Social Connector

http://blogs.msdn.com/outlook/archive/2009/11/18/announcing-the-outlook-social-connector.aspx

The Outlook Social Connector is a set of new features to help keep track of your friends and colleagues while enabling you to grow your professional network. The Outlook Social Connector is available now as part of the Microsoft Office 2010 Beta.

つい先ほど Twitter で拾った情報ですが、Outlook 2010 には Social Connector というものが組み込まれ、そこに各種の情報を接続できるとのことです。 つまり、Twitter や Facebook などのクライアント機能を、Outlook 2010 に集約できるというふうに解釈できます。

もちろん、デフォルトでは SharePoint と Windows Live が設定されるのでしょうが、以下の図に示されるように、Network Provider 3、４、、、 と、ビルトインのための領域が確保されている感じです。

これは、面白そうですね。 期待大です！ ーーー A.C.

日本で全米で、Windows Azure イベントが目白押し

Tech-Days 2010 と、Windows Azure Local Event

Tech Days 2010 の開催が迫ってきました。 キーノートはビデオ配信もありますので、どうしても参加できないという方も、ぜひ お見逃しなく！ 2月23日・24日の開催で、丸山先生の特別講演もあります。 

http://www.microsoft.com/japan/events/techdays/2010/keynote/keynote.aspx

セッション情報も、以下のURLで参照できます。

http://www.microsoft.com/japan/events/techdays/2010/session/session.aspx

Tech Day の見所として、Ray Ozzie の戦略を分析する記事が ITmedia に掲載されています。ーーー オールMicrosoftプロダクツという制約を取り払い、オープンソースを受け入れた新たなモデルを模索するレイ・オジーはいつの日か、尊敬の念を込めて「Azureの父」と呼ばれることになるのだろうか ーーー 本稿では、レイ・オジーの戦略を考察しながら、間もなく開催されるTech-Days 2010で注目すべき点について考える。

http://www.itmedia.co.jp/enterprise/articles/1002/17/news005.html

アメリカでも、15の都市で Windows Azure ローカル･イベントが開催されるとのことです。

Learn More About Windows Azure at A Free, Local Event Near You
http://blogs.msdn.com/windowsazure/archive/2010/02/17/learn-more-about-windows-azure-at-a-free-local-event-near-you.aspx

There’s still time to attend a free local event to learn more about cloud computing and Windows Azure! Join your local MSDN and TechNet teams at an upcoming session to take a deep dive into cloud computing, better understand Windows Azure and assess how you can leverage it in your work. Attendees will get a free thumb drive with key information and demos.

The MSDN-hosted session, "Take Your Applications Sky High with Cloud Computing and the Windows Azure Platform", provides a developer-focused overview of Windows Azure Platform and the cloud computing services that can be used either together or independently to build highly scalable applications. As the day unfolds, attendees will also explore data storage, SQL Azure, and the basics of deployment with Windows Azure.

The TechNet-hosted session, "Windows 7, Virtualization and Windows Azure", provides an IT Generalist/Implementer/Manager an overview of Windows Azure including real-world examples of how companies are using Windows Azure today, guidance in thinking about applying it for customer-facing applications, and how it can add flexibility to your computing infrastructure. This event will also touch on the future of the Windows Azure Platform.

Register today to attend a free, live session in your local area. Click here to find the event best for you.

Published Wednesday, February 17, 2010 4:58 PM by WindowsAzure

St. Louis 2-Feb ／ Dallas 4-Feb ／ Minneapolis 9-Feb ／ Chicago 10-Feb ／ Southfield, MI 11-Feb ／ Phoenix 23-Feb ／ Philadelphia 23-Feb ／ Los Angeles 25-Feb ／ Washington, DC 25-Feb ／ San Francisco 2-Mar ／ Raleigh 3-Mar ／ Seattle 4-M ／ Denver 9-Mar ／ Orlando 9-Mar ／ Ft. Lauderdale 11-Mar

ーーーーー

Windows Azure 、盛り上がってきましたね。 ーーー A.C.

＜関連＞
Windows Azure と インターオペラビリティ
Windows Azure Team Blog が、すごい勢いだ！
Windows Azure : 7月末までテストが無償！
Windows Azure CDN で Blob も OK!
こっそりリリースされてた AppFabric SDK 1.0
対訳：Windows Azure が Server & Cloud Division に移行
AppFabric とは？

Apache ZooKeeper による分散並列キューの構築 _2

Building a distributed concurrent queue with Apache ZooKeeper _2
by Henry Robinson
May 28, 2009

The ZooKeeper queue

A FIFO queue is a simple data structure where producers put items in, and consumers retrieve them in the order they were put in. There are only two operations on a basic queue: enqueue adds an item and dequeue removes it. Despite their simplicity, queues crop up very often in distributed systems – for example, in job submission systems where clients submit requests to a set of workers which serve the requests on a first-come, first-served basis.

FIFO キューは、アイテムの作成者が、それを投げ込むためのシンプルなデータ構造である。 そして消費者は、その順番にしたがってアイテムを取り出す。 このキューには、基本的に2つのオペレーションだけがある。 つまり、アイテムを加えるための enqueue と、削除するための dequeue である。このキューはシンプルであっても、分散システムではきわめて頻繁に利用される。たとえば、 first-come／first-served を原則としてサポートする、worker のセットに対してクライアントがリクエストを発行する場合の、ジョブ･サブミッション･システムなどがある。

The ZooKeeper queue is structured very simply. All items are stored as znodes under a single top-level znode which represents a queue instance. Consumers can retrieve items by getting and then deleting a child of the top-level znode. The code creates a queue by calling a single create command. If the queue already exists, the Python module will throw an exception which we catch. This is a design decision that is still in review – future versions of the bindings might return integer error codes, and rely on the user to throw an exception if required.

ZooKeeper キューは、きわめてシンプルな構造を持つ。 すべてのアイテムは、キュー･インスタンスを表現するトップレベルの znode の下で、znodes としてストアされる。 トップレベルの znode の子供を取得し削除することで、利用側はアイテムを検索する。以下のコードは、ひとつの create コマンドを呼び出すことでキューを生成する。 すでにキューが存在する場合には、キャッチが可能な exception を Python モジュールはスローする。 これはレビューにあるデザイン上の決定だ。このバインディングにおける将来のバージョンは、整数のエラーコードを返し、また、必要に応じてユーザーに exception をスローするだろう。

zookeeper.create(self.handle,self.queuename,"queue top level", [ZOO_OPEN_ACL_UNSAFE],0)

The first two arguments to this call identify the connection to the ZooKeeper service and the name of the znode. The third is the data the znode contains. We won’t be accessing the data so we write some placeholder text.

最初の2つの引数は、ZooKeeper サービスへの接続と znode の名前を識別する。 第3の引数は、znode が含むデータとなる。実際にはデータにアクセスしていないため、いくつかのプレイス･フォルダー･テキストを書いてある。

The fourth argument is an access control list of permissions that controls who can access the znode in the future. ZooKeeper provides fairly fine-grained control over access, but the subject is beyond the scope of this post. What we have done here is to create the queue znode so that any client can read or write to it.

第4の引数は、この後に znode にアクセスする人の権限を制御するための、パーミションのアクセス制御リストだ。 ZooKeeper が提供するアクセスの制御は、かなり粒度の細かいものとなるが、そのこと自体は、このポストのスコープ外となる。 このポストで行うべきことは、キュー としての znode を作成し、あらゆるクライアントからの read/write を実現することである。

Adding and deleting items from the queue

Although I explained how consumers retrieve items from the queue, I said nothing about how they make sure they are retrieving items in FIFO order. What we would like is a way of naming each item such that later items are ordered lexicographically after earlier ones. If we can retrieve items in the same order, we’ll have our queue. Thankfully, ZooKeeper provides a very handy flag for the create call that helps us out. Specifying the zookeeper.CREATE_SEQUENCE flag appends each znode name with an sequence number suffix that increases monotonically with each new znode that is created. ZooKeeper ensures that the sequence numbers are applied in order and are not reused.

キューからアイテムを取り出す利用方法は説明したが、それらのアイテムが FIFO オーダーになっていることを、確認するための方式については何も言及していない。私たちが欲しいものは、辞書編集的にアイテム間の前後関係が整理されるような、命名規則である。 同じ順番でアイテムを取り出せることが、有益なキューの条件となる。感謝すべきことに ZooKeeper は、私たちを支援する役割を創り出すための、きわめて有用なフラグを提供する。シーケンス番号サフィックスを用いた znode 名を、指定された zookeeper.CREATE_SEQUENCE フラグにアペンドし、新しい znode が作られるごとに、それを規則的にインクリメントする。 そのシーケンスナンバを順番に適用し、再利用しないことを、ZooKeeper は保証する。

Enqueuing an item is therefore a simple one liner. We don’t have to take out any locks to ensure that access to the queue znode is serialised. Items may be queued concurrently, and ZooKeeper takes care of assigning sequence numbers to them in the order they were received.

したがって、アイテムの Enqueuing が、リニアに単純化される。キューとしての znode へのアクセスがシリアライズされることを保証するために、キーを取り出す必要がなくなる。アイテムが同時にキューに入るかもしれないが、それらが受け付けられた順番で、シーケンス番号が割り当てられるように、ZooKeeper が注意を払う。

Dequeuing an item is also straightforward, but a bit more involved. First we retrieve a list of all the items waiting to be queued from ZooKeeper with the get_children procedure call. Then, after sorting the list of items on the client, we get the contents of the znode (i.e. the item’s data) and then try to delete it.

アイテムのを Dequeuing も簡単だが、もう少し複雑になる。 最初に、get_children プロシージャを用いて、ZooKeeper からキューに入れられる、すべてのアイテムの待ちリストを取り出す。続いて、クライアント上でアイテムのリストをソートした後に、znode のコンテンツ（アイテムのデータ）を受け取り、その削除を試みる。

It is possible that this deletion will fail because some other consumer has managed to successfully retrieve the item beforehand. We could ensure that this would never happen by organising for a queue-wide lock – this is easily implemented in ZooKeeper (although left as an exercise for the reader). However, this would severely impact performance by only allowing a single consumer to access the queue at one time. Instead, the client simply deals with the failed delete – again, indicated via an exception – and moves on to the next child znode in the list. If the client reaches the end of the list without successfully deleting an item, it should issue another get_children call to make sure that no items were added while the original list was being scanned. Once the get_children call returns an empty list, the dequeue procedure gives up and returns None.

他の利用者が先行してアイテムの取り出しに成功していると、この削除が失敗する可能性もある。しかし、ZooKeeper がキュー･レベルのロックを構成することで、こうした問題が発生しないことを保証する。読者に対するエクササイズが残されているが、ZooKeeper への実装は容易である。 とは言え、単一の利用者だけがキューにアクセスする場合には、ひどくパフォーマンスが劣化する。そのための代案として、クライアントは exception を介して示される、削除の失敗をシンプルに取り扱い、続いて、リスト上の次の子供 znode へと移り進む。もしクライアントが、何らかのアイテム削除に失敗したままで、リストのエンドに到達した場合には、オリジナルのリストがスキャンされる間に、アイテムが追加されないことを保証するために、別の get_children コールを発行すべきだ。その get_children コールが空リストを返した後に、dequeue プロシージャは停止され、None が返される。

＜続く＞

ーーーーー

キューの Producer を作成者、Consumer を利用者と、とりあえず訳していますが、適切な用語はなんでしょうかね？ ーーー A.C.

ーーーーー

＜関連＞
Apache ZooKeeper による分散並列キューの構築 _1
Apache ZooKeeper による分散並列キューの構築 _2
Apache ZooKeeper による分散並列キューの構築 _3
Apache ZooKeeper による分散並列キューの構築 _4
Observers と ZooKeeper _1
Observers と ZooKeeper _2

総務省 スマート･クラウドに対するパブコメと議論 on Twitter （まとめ） [ #scloud ]

私なんぞがまとめる立場ではないのは、重々 判っておりますが。。。

総務省トップ > 広報・報道 > 報道資料一覧 >
スマート・クラウド研究会中間取りまとめ（案）
スマート・クラウド戦略に対する意見の募集
平成22年2月10日
http://www.soumu.go.jp/menu_news/s-news/02ryutsu02_000023.html

1 経緯

総務省では、クラウド技術の発達を踏まえた様々な課題について包括的に検討するとともに、次世代のクラウド技術の方向性を明らかにすることを目的として、平成21年7月29日から「スマート・クラウド研究会」を開催してきたところです（本研究会の構成員は別紙1、同開催状況は別紙2のとおりです。）。

つきましては、本研究会における「中間取りまとめ（案）－スマート・クラウド戦略－」（別紙3）について、以下の要領で意見を募集します。

2 意見募集要領

意見募集対象：
「スマート・クラウド研究会中間取りまとめ（案）－スマート・クラウド戦略－」（別紙3）
参考資料（別紙4）
意見募集締切り：平成22年3月9日（火）17:00（必着）
（郵送の場合は、平成22年3月9日（火）必着。）
詳細は意見募集要領（別紙5）を御覧ください。

なお、準備が整い次第、電子政府の総合窓口〔e-Gov〕（http://www.e-gov.go.jp）の「パブリックコメント」欄に掲載するとともに、連絡先において配布します。

3 今後の予定

提出されたご意見を踏まえ、引き続きスマート・クラウド研究会において検討を進め、本年6月を目途に報告書を取りまとめる予定です。

スマート・クラウド研究会 構成員名簿（敬称略、五十音順）

飯泉 嘉門 徳島県知事
石田 一雄 富士通株式会社 執行役員上席常務
宇治 則孝 日本電信電話株式会社 代表取締役副社長
大歳 卓麻 日本アイ・ビー・エム株式会社 会長
角 泰志 日本ユニシス株式会社 常務執行役員
重木 昭信 株式会社ＮＴＴデータ 顧問
嶋谷 吉治 ＫＤＤＩ株式会社 取締役執行役員常務
鈴木 幸一 株式会社インターネットイニシアティブ 代表取締役社長
髙橋 直也 株式会社日立製作所 代表執行役 執行役副社長
広崎 膨太郎 日本電気株式会社 代表取締役 執行役員副社長
堀部 政男 一橋大学名誉教授
宮原 秀夫 大阪大学名誉教授【座長】
宗像 義恵 インテル株式会社 取締役 副社長
村上 輝康 株式会社野村総合研究所 シニア・フェロー
村田 正幸 大阪大学大学院情報科学研究科教授【座長代理】

－－－－－－－－－－－－－－－－－－－－

2月13日に、Twitter に以下のハッシュタグが作られ、上記の意見募集に対するパブリック･コメントが寄せられました。 ヒマな Agile_Cat もチョコチョコっと参加させて頂いたのですが、とても面白い意見がありましたので、以下のようにまとめてみました。

ただし、なるべくフラットにとは思っても、そこには必ず Agile_Cat 的なバイアスがかかってしまいますので、その前提で ご覧頂ければと思います。基本的に時系列で、興味深いコメントを抽出し、関連するものをブロックにまとめるという手法で整理してみました。

2010/2/13 －－－－－－－－－－－－－

クラウド研究会関連はこのハッシュタグで議論して参りましょう。 #scloud

暗号鍵を日本に置きつつクラウド上のデータを透過的に管理する技術とかアツそう。
確かに制度面やグローバル論はさておき、本技術の検討や試行はアツイ。
クラウドのような分散環境のKVSやRDBでデータを暗号化したい場合には、課題が多い。
RDBでも、まだ暗号化やその復旧ではコストが高い。
例えば、愛国者法でデータを丸ごと押収されて… と言う様なことに対する対応も要検討。

政策決定過程が身近になるのは素敵だ。ネット選挙活動もこんな感じになるのかな。
日本独自の指針、ガイドライン、契約約款、認定制度、監査制度ができるんだろう。
電気通信事業法、消防法、建築基準法の緩和、フェアユースと間接侵害の問題。
電力料金の優遇策に触れられていないのは残念
コストとフレキシビリティのバランスの問題だと思う。
官民においてクラウドを進める上での強いリーダーシップ（そして啓蒙）は欠かせない。

ユーティリティ化し、通信費用とHWリソースの使った分だけ請求するモデルもありうる。
ITの利活用の幅を同時に相当広げていかないと市場が縮んでしまうことが懸念される。
クラウドは効率的な活用を促進するが、IT機器販売、運用・保守の人員を減少させる。
クラウドに関する資料としては良くまとまっているが、それ以上のものは見当たらない。
Hadoopの話を筆頭に分散処理技術に大きくFocusしている点が興味を引く。
教育分野のクラウドはおもしろそう。
霞ヶ関の情報で欲しいのは各種統計調査情報。

クラウドは新しいものでなく、「知識・情報の集積・共有」と「リアル・サイバー連携」。
クラウドはハードと利用の形態を、物量的に見直した結果。

アメリカに全世界のデータが集められデータの解析、統計を勝手にとられて。。。
アメリカ得意の物量作戦とすると、日本は安全・信頼性の高いクラウド技術の開発目指す？
日本のクラウドに未来はある。関連企業はBtoBやプライベートクラウドを先行すべき。

信頼性の高い高価なハードが一台よりも、安価なハードが二台走っている方が安全。
規模の経済の利と、データのセキュリティのトレードオフを十分考慮すべき。

農業、物流、気候、環境などのリモートセンシングとの組み合わせという想定が良い。

クラウド技術単体ではなく、業界全体としてのビジネスサイクルが確立されることが重要。
クラウドで勝負するのであれば、世界を相手にしたビジネスを描かないと意味がない
スマートクラウドという言葉に込められた、技術そのものではなく社会的システムの構築。

知財という視点で、行政のクラウドはオープンソース（ 国民の資産）になるべき。
オープンソースで機密性を保てるか？
機密性って100%は保てないのでどこまでかという線引きが難しい。
既存行政システムのknow-how非公開が業者固定に繋っている。
行政レベルのオープンソース化は、色々な人が拘るので、何となく大変そう。
中間報告でSLAの多様性を見極めた上でとなっているが、十分に考えられるオプション。

税金で作ったのだから国民の共有財産という考え方。
受注側のベンダーがOpen化を飲めない可能性がありそう。
Eucalyptusじゃない純国産IaaS型クラウドインフラ用ソフトウェアを作っている。
オープンソースがあるのに、なぜ独自実装にこだわるのか？
行政サービスのOSS化。発注するときにOSS化を条件にすればいいのでは？

海外の事例なども、研究する価値がある？
iPhone アプリをサポートしていく米政府のポータル。
オバマ政権は、オープンソース化を模索している。
ApacheとかMysqlとかまで一足飛びにはいけない。

国民にとって行政システムのソースコードを非公開にすることのメリットはなにか？
目的が、行政サービスの向上なのか、国内産業の育成なのか？
利活用促進の先にある目的がもう少し見えるとフォーカスするエリアがもう少しさだまる。

OSS化にメリットがあるかどうかは、長崎などの前例を評価する必要がある。
コードを使い回しながら一品モノとして納品してきたベンダーは困る。
有償で官民に外販できる可能性が減ってしまう。

OSSした場合、重複投資が減る。コストが下がる。安全性が高まる。
皆我儘だからSIで金とるのは変わらないのでは？
行政クラウドを丸々オープンソースにするというのは興味深い提案。
1700以上ある市町村の行政サービスを市町村ごとに独自に実装するメリットはない。

要素技術の話ではなくそれによって実装されるサービスのOSS化のこと。
コード公開で増える工数・外販の機会費用と、節約されるコストの、定量的評価が必要。
自治体クラウドの外販は既に始まっている。
「推測するな。計測しろ」という格言。
行政のシステムで、本当のEAが実現されていない。PMO補佐官の人達もあきれていた。
予算処置が、基本ワンオフで、その後のメンテナンスについてまで盛り込めない。
現場や意思決定のレベルにリテラシーの高い方がいない。業者が荒している様に感じる。

ソース公開で重複投資が避けられるなんて技術屋の妄想。
自治体間で業務手順が共通化されていない点。
ベンダーロックインから抜け出す契機にもなるかも。運用・保守の検討が重要。

プロビジョニングとディプロイの簡素化も重要。
エコポイントでセールスフォースが採用され、プロビジョニング・デプロイの迅速性が問われる。
エコポイントのシステム構築はクラウドが典型的にハマるパターン。
アジリティの必要なものには何でも有効に当てはまると思う。
プロビジョニングとディプロイを含むライフサイクルのあり方という視点が、欠落している。
全面的な作り直しにならないような漸進的なシステム構築という視点が、欠落している。

コード公開を求めると、そこの独占販売権を与えない点で確実に値上がりする。
成果物のオープンソース化は実用システムよりは学術分野から進んできた。
Hadoop では RedHat をモデルにして、大手のユーザーが Cloudera を推進している。
オープンソースは、いずれもクローンで発明者の厚意に依存している。
クローンという視点は、多かれ少なかれ、商用プロダクトについても言える。

アイデンティティが、参考資料のOASISの取り組みくらいしか出てこないのは残念。
アイデンティティはオーストリアやエストニアといった東欧諸国・韓国が進んでいる。
人口の少ない国はラク。エストニアは130万人。日本だったら一地方都市のレベル。

パブリックや、プライベートに出せる部分、オンプレミスに置く部分についての議論は不要？
これはかなり本質。これから本格化してくるのでは？
パブリック・プライベートの間に様々なグラデーションがあり、二元論は不適切。
パブリック＝シェアードと解釈するとスッキリしないか？
クラウドの定義は NIST の定義をきちんと参考に。 > http://bit.ly/1eZy5p
こうした定義が、この中間取りまとめ案にも必須。
NISTの方がこなれているかも 。

日本はシステム系の技術で大きく遅れているが、個人に目を向ければ職人的技術は豊富。
開発費・運用費を押さえる知恵も必要。税で構築するとその観点が抜けることが多い。
大量データ処理技術はBigTableやMapReduce、Hadoopなどの米国勢の独壇場。
分散ファイルシステムは歴史的に長いけど、HDFSかどうかはまだ懐疑的。

アメリカ企業は顧客データを世界中から預かっているという、スタートラインの違いに注意 。
OpenCirrusのような取り組みの中に、なぜ、日本の企業や大学は参画しない？
公的個人認証サービス普及拡大検討会は、昨年７月から活動していないようだ。

日本の大企業のクラウドは信頼性が違うので、単純比較できないし価格競争には乗らない。
大手メーカーの言い分は皆さんこうなので、囲い込めるユーザはどんどん減っていく。

クラウドの真の意義は、未踏のスケーラブルなアプリ登場への期待。
外字の問題。料金可変な調達の問題。当初データ移行の問題。データの置き場所の問題。
ネットワーク接続可用性の問題。業務プロセス標準化の問題。
インタフェース完全標準化の問題。ID管理の問題。大量印刷の問題。

ーーーーーーーーーーーー 2010/2/16 7:30AM

Twitter のハッシュタグ #scloud に全てのコメントがありますので、ブロガーの方々や、メディアの方々が、それぞれの視点でまとめていただけると、それらを比較することで、よりフェアな解釈が進んでいくと思います。

なお、すでに終わってしまったというものではありませんので、コメントのある方は、ドンドンと書かれたら良いと思います。 ーーー A.C.

＜関連＞
Open Governmentについて
経産省の Twitter に掲載された、とても真摯なメッセージ [ #openmeti #scloud ]

O’Reilly の忠告に、知らねぇよと Google 言い、Buzz 大炎上！

祇園精舎の鐘の声、諸行無常の響きあり、沙羅双樹の花の色、盛者必衰の理をあわらす～～～

昨年11月18日の、Web 2.0 Expo キーノートでの Tim O’Reilly の話を覚えていますか？ このカンファレンスは、その名のとおり、オープンなインターネットを標榜して、アメリカやヨーロッパなどで開催されているもので、昨秋の開催地はニューヨークでしたね。。。

Microsoft の影響力が及ばなくなってきたインターネットの世界で、Google が覇権を握る可能性を持っていると、皆さんも感じていますよね。 その Google に対して O’Reilly は、覇権の構造から生じる無益な競合の非生産性を説き、そのような方向へ Google が走らないようにと、このキーノートで強くけん制したのです。言い方を換えれば、覇権に走っても、いずれは必ず失うことになると諭していたのです。 独自の社是として「悪にならない」を掲げる Google ですが、たとえば Google Voice を拒絶する iPhoneに対して、Google Map の新機能を Andriod だけに限定するなど、オープン性をないがしろにするような戦略が目立ち始めていたからです。

O’Reilly は Google の力を認めた上で、Amazon や、Apple、Twitter、Facebook の市場を取りに行くべきでなはないと提言していました。 そして、そのようなことをすれば、いずれ Google は力を失うとも指摘していました。

ところが、やらかしてしまったのです、Google は。Twitter なんて放っておけば、いいじゃぁありませんかぁ。でも、我慢できなかったのでしょうね。 Google の検索能力に依存ぜずに、つまり、Google の力が及ばないところで、Twitter が注目を浴びて、勢力を拡大していることが。。。 以下は、ITmedia のニュースからの引用です：

Google Buzz で本名や居場所がばれる？ ネットで騒動に – ITmedia より

Google Buzzは、Twitterのようにひとことメッセージを投稿したり、フォローしている友人のメッセージをリアルタイムで閲覧してコメントを付けたりできるサービスで、Gmailのメニューから利用できる（Googleも“なう”、GmailにTwitter風機能「Google Buzz」）。

Google Buzzの投稿画面。デフォルトだとGmailの差出人が投稿者名として表示され、ユーザー全体に公開される 表示される投稿者名は「Googleプロフィール」の氏名で、デフォルトだとGmailの送信者名と同じ。投稿内容は全ユーザーに公開される「一般公開」がデフォルトになっている。Gmail送信者名に本名を設定し、デフォルトのまま利用すると、自分の行動などを本名で公開することになる。

iPhoneやAndroid携帯からGoogle Buzzを利用すると、投稿時に自動的に位置情報が付く。Gmailの差出人に本名を設定し、Googleプロフィールをデフォルトのまま「自宅なう」「会社なう」など投稿した場合、本名付きで自宅や会社の場所を公開してしまうことになる。

この問題はTwitterなどで話題になっており、「意図せず本名や居場所を公開してしまっていた」と投稿を削除したり設定を変えたことを報告するユーザーも多い。

Google日本法人はブログで、投稿者名の変更方法や、iPhoneからの位置情報送信を止める方法などを説明している。

結果は大炎上。 嫉妬や、チョッカイや、強欲は、身を滅ぼすものです。付け焼刃で、Twitter の力を封じようとしても、そんなの上手くいくわけありません。 さっそく、パッチを提供するハメになったとか。 以下は、アメリカの各メディアからの引用です。 スゴイ集中砲火ぶりです：

Google Buzz Gets Privacy Patch – Information Week
By Thomas Claburn February 12, 2010 03:10 PM
On Thursday, Todd Jackson, product manager for Buzz, acknowledged that Google had heard from concerned users who believed their contacts were being made public without their knowledge and who were upset that they had too little control over who could follow them. Jackson said that in response to feedback, Google has made the option to not display follower information on public profiles more visible. The company has also made it possible to block followers who have not created a Google Profile and has made information about followers more clear.

Google Buzz may force government to act on Privacy concerns – ZDNet
Posted by Doug Hanchard @ February 13, 2010 @ 10:32 AM
The U.S. Federal government may have no choice but begin an investigation on its process and policies concerning privacy and how it manages data sharing. Several agencies are likely to be involved and will review Google including the Department of Justice (DOJ), Federal Trade Commission (FTC) and the Federal Communications Commission (FCC). It will start with preliminary investigations and requests for information based on complaints submitted to each agency and upon review snowball into full scale Congressional Hearings and legal proceedings. From there it will spread to Canada, Europe and beyond.

Google Buzz Privacy Update Has Users Seeing Stars – TechCrunch
Jason Kincaid @February 13, 2010; 9:43 AM
Google Buzz launched with more than its fair share of privacy issues, leading to a significant backlash from some users. Fortunately the Buzz team is fixing these issues at a brisk pace. Today, they’ve rolled out a fix to a bug that would let users inadvertently expose their friends’ private email addresses using Buzz’s @reply system.

Google Buzz: More Social Clutter or Less? – PC Magagine
by Dan Costa @02.12.10
No, Google knows we are all spending a huge amount of time using social networking applications and that we are using them for everything from sharing baby pictures to making sales contacts. If Google wants to stay in the business of selling our eyeballs (i.e. advertising), it has to keep us on their sites. The surprising thing for me is that Google genuinely believes Buzz will make social networking simpler. Not bloody likely.

Google tweaks Buzz to address privacy concerns – Computerworld
By Sharon Gaudin @February 12, 2010 11:36 AM ET
Google last night disclosed in a blog post that the quick updates makes it easier for users to block access to their pages and eases the path to finding two privacy features. "We’ve had plenty of feature requests, and some direct feedback," wrote Todd Jackson, a product manager for Gmail and Google Buzz, in the blog post. "In particular there’s been concern from some people who thought their contacts were being made public without their knowledge.

>>> Google Buzz をググった結果

思い出してくださいな Eric Schmidt さん、O’Reilly さんの忠告を。 ちゃんと聞いておけば良かったと、後悔していてほしいものです。｢もし、あなたが、誰にも知られたくない何かを持ってしまうなら、最初から、そのような事をすべきではない｣なんてウソぶいてたけど、それじゃあ、世の中わたっていけませんよ。

そして、あなたのシンパのジャーナリストである Jeff Jarvis の言葉も思いだしてくださいな。「ベストを尽くせることを成し，それ以外は連携せよ」と言っていたじゃぁありませんか。 マードックとのケンカでは、味方になってくれた彼も、Buzz に関しては、どう言っていいか判らず、困っているようですよ。

ーーーーー

え～、この騒ぎにもかかわらず、Nicholas Carr 先生は沈黙を保っています。 つい先月に、まさにプライバシーに関する Google のスタンスについて、キツイ一発をかました直後の顛末だけに、何を言ってくれるんだか、次のポストが待ち遠しいです。 ――― A.C.

＜関連＞
Google Buzz のプライバシー対策が、明日に発表されるらしい
プライバシーとは？（Google 対 China なんて問題外） by Nicholas Carr