痺れを切らして、普段 GAE/Jな私が、Python版のbulkloaderを使ってみました。

普段GAE/Jなので、スタートガイド Python 開発環境 / Google codeを参考に、環境作りからはじめます。

Pythonをインストール

Download – Pythonから手繰り、私の場合はWindows (未だにXPデス)なので、Windows x86 MSI Installer なんをインストールします。最新は2.7.2の様です。
Macなら最初から入っていますし、Linuxも大概のディストリビューションで最初から入っています。

Google App Engine SDK for Python をインストール

GAE/JなヒトでもPython版SDKを既に入れている方もいるかもしれませんが、入れてないヒトは入れましょう。

Google App Engine SDK のダウンロードから、Google App Engine SDK for Pythonをインストールします。最新は1.5.2でした。

とりあえずCドライブ直下に置きました。
インストールディレクトリは c:\appengine-python-sdk-1.5.2 となりました。
これを環境変数PATHに追加しときます。

GAE/J側の準備

既存プロジェクトの web.xmlを編集し、GAE/J側のRemoteApiServletを有効化？します。

	<servlet>
		<servlet-name>remoteapi</servlet-name>
		<servlet-class>com.google.apphosting.utils.remoteapi.RemoteApiServlet</servlet-class>
	</servlet>
	<servlet-mapping>
		<servlet-name>remoteapi</servlet-name>
		<url-pattern>/remote_api</url-pattern>
	</servlet-mapping>

勿論この後デプロイします。

設定ファイル (yaml) を作成

cmd.exe を起動し、appcfg.py で create_bulkloader_config を実行します。

cd c:\appengine-python-sdk-1.5.2
appcfg.py create_bulkloader_config --url=http://{appId}.appspot.com/remote_api --application={appId} --filename=config.yml

High Replicationの場合は、–application の引数のアタマに s~ をつけないといけないみたいです。
こんな風に。

cd c:\appengine-python-sdk-1.5.2
appcfg.py create_bulkloader_config --url=http://{appId}.appspot.com/remote_api --application=s~{appId} --filename=config.yml

自動生成されたconfig.yml には、そのとき appengine側に存在する kind のスキーマを反映したものになっているようです。

アップロード/ダウンロードするkindが限定されている場合などは、このymlファイルを編集して対象kindだけのymlファイルを作っても良い。

自動生成されたymlファイルは、TODO: の記述がいくつかあり、ココを適宜修正する必要があります。
最低でもconnector (と connector_options )を編集します。

  connector: # TODO: Choose a connector here: csv, simplexml, etc...
  connector_options:
    # TODO: Add connector options here--these are specific to each connector.
↓
  connector: csv
  connector_options:
    encoding: utf-8

CSVアップロード

ダウンロードするには、こんな感じ。

appcfg.py download_data --filename=test2.csv --config_file=test.yml --url=http://{appId}.appspot.com/remote_api --application=s~{appId} --kind={ClassNameOfKind} -v

アップロードはこんな感じ。

appcfg.py upload_data --filename=test.csv --config_file=test.yml --url=http://{appId}.appspot.com/remote_api --application=s~{appId} --kind={ClassNameOfKind} -v

参考にさせて頂いた先人の知恵

pomu0325: [GAE] bulkloaderをGAE/Jで使う

Javaプログラマの為のGAE/py bulkloader – GAE/py環境設定 – - 高卒文系プログラマの日常 by zetta1985

きのふよりけふ、けふよりあした　 未分類

CSVファイルのデータをアップロードする方法 – 気楽に開発メモ

Using the bulkloader with Java App Engine – Ikai Lan says

レンタルサーバでいいじゃん的な案件でも、独自SSL欲しいとかイロイロわがまま言い出すと数千円/月~高いので1万円前後します。それでいて、自由度が少ない。JavaServlet 動かすなんて無理。

VPSならそりゃVM(仮想サーバ)のrootが貰えるんで、ミドルウェア構築するのが苦じゃない場合はそっちの方がメリット大きいです。でも、格安VPSってパフォーマンス悪そうですね。

そんな訳で全く期待値が低い状態で、さくらのVPSを使ってみたんですが、コレがまた結構サクサクじゃないですか。手元にあるHPのML115と比較しても、Apacheとかのコンパイルが早い。下手したら半分位かも。
CentOSなんですけどどうやら64bit版らしいです。64bit版はじめてだったんですけど、多少./configure のオプションで勝手が違いますが、それ以外は特に不都合ないですね。

時間帯とかイロイロな変数が影響するんでしょうが、 サーバのスペックに加えレイテンシも含めて考慮すると素の北米の Amazon Web Services の Smallインスタンスよりもコッチの方が快適です。それでいて 980円/月 なんだから、こりゃいいな、と。

いや、嬉しい誤算です。

ついでに ｊｐドメインもさくらで取ったんですが、コレは1日強待たされましたが、DNSモドキもついて4000円強なんで、個人的にお気に入りの格安レジストラVALUE-DOMAINを使う理由が1つ減りました。

試用期間2週間は無料で使えるんで、是非お試しを。
※さくらの回し者じゃないですよ。

IaaSプロバイダはどうやってマーケットを広げるのか？ PaaSレイヤを提供するのは簡単だが、そうすると顧客にはロックインされるという懸念が持ち上がる。顧客が管理の主導権を持てるというIaaSの利点でを維持したまま、どうやってPaaSの利点である、熟練を要する運用業務を顧客から不要にする、ということを提供できるだろうか

その答えは運用を容易にするツールの提供だ。それはIaaS上に用意された、優れた（ベストプラクティスな）インフラで、可用性とスケールを実現するものだ。

これがまさにAWS Elastic BeanstalkがTomcatを用いて行ったことである。

IaaSとPaaSの違いはなくなろうとしている － Publickey

個人的にはベンダロックインよりも、運用がどれだけ容易になるかが最大の関心事だったりする。
運用にもスケールするかどうかが含まれていると考えています。

昨今のWEBサービス開発は、php等のスクリプト言語で作るのがあたりまえです。
初期の開発者の単価が抑えられ、ホスティングサービス等を利用しやすいから。

で、幸運にもWEBサービスが流行ったら、フロントエンドのWEBアプリケーションも色々と性能改善をしつつ機能追加とかするのも大事ですけれど、ある程度の規模を超えるとストレージのレイヤ（データベース側）でがんばってスケールさせる必要が出てくる訳で、ミドルウェア含むインフラ層にもエンジニアを惜しみなく投入して、あの手この手で分散化する必要が出てきます。

最近は知りませんが少なくとも私の知る限り、php は Apache等のhttpデーモン のプロセスまたはスレッドにくっついて動く訳でして、永続的接続とかいう仕組みは有っても、アプリケーション全体でDBコネクションの数を制御したり、プーリングしたり、使いまわしたり、データベースアクセス専門のオブジェクト(DAO)をこさえて使いまわす、なんて事が簡単には出来ない訳でして、そこはもう Java Servlet の方が1階層タンデムな分そこのへんの作りこみが楽だから、ある程度の規模までならデータベースアクセスの観点からパフォーマンス面で有利だと思う訳でして、私がWEBアプリケーションとしてはマイナーな Java を選ぶ理由の1つです。

TCP/IPのコネクションを張るのはそこそこリソースを消費する訳だから、php でApacheのプロセス（スレッド）上減数に合せてコネクションを貼りっぱなし、なんて構成を最初はとったりする訳ですが、RDBMSサーバ側のリソースも結構ふんだんに用意する必要がありますし、規模が大きくなってくると、最近は安くなったとはいえスケールアップさせるのはソコソコ金がかかるんで、水平に垂直に分割したりレプリケートさせたりキャッシュしたりインフラ層でイロイロやらないといけないんで、安定させて性能を出すにはそれなりのコツというか、DBAなんていう職業が成立してしまう位イロイロな匠の技がある訳ですし、24時間365日運用するには、やはり訓練もドキュメンテーションもそれなりに必要になってきます。

で、最初の「運用がどれだけ容易になるか」の話ですが、こういう「インフラ系エンジニア」の下働きは、それなりに優秀な人材を集めなければいけないしコストがかかります。WEBサービスもマネタイズできないと単なるボランティアですからやはり収益性は大事な訳です。

誤解を恐れずに言うならば、インフラ系エンジニアは「システムの能力を最大限に引き出し（必要に応じて向上させて）たり、セキュリティ含むITをとりまくあらゆるリスクを軽減する為にイロイロとがんばる」訳ですが、それで収入が増えるとか言う事は無い、と考えられる事が多いわけです。特に経営層に。

これらはだんだんとコモディティ化してきているから、もし外注できるなら、どうせ金かけるなら優秀なソフトウェアエンジニアを中に雇いたい訳です。サービスをより良くするスピードこそ、競争力であり、収入を増やす為に必要だからです。

こういう事を書くと世の中のインフラ系のエンジニアの方を敵に回しそうなんで一応書いておきますが、価値を生むとか生まんとか以前に情報システムは運用してナンボ、作るだけじゃダメな訳で、運用管理も誰でも簡単に出来る訳じゃないです。Salesforceの様に、運用こそ差別化の最大要因だと言い切ってしまいたい所です。

さらにさまざまな問題を回避する事で、問題が発生した場合に損失しうる企業価値を損なわずにすむという面もありますんで、一概に要らないと言っている訳では無くて、AmazonやGoogleとかが、規模の原理を活かして、自社の優秀なエンジニアと運用のベストプラクティスを、IaaSやPaaSで提供しはじめている訳ですから、少なくともWEBサービスにおいては、ストレージ層も含めて「スケールする」インフラがセットで提供されはじめた今、「事業」として考えた場合、「外注」されやすい分野である事は間違いないでしょう。

要るとか要らないとか言う以前に、土俵というか、世の中のルールというかが変わって来たぞ、と。

そういう観点で、Google App Engine と AWS Elastic Beanstalk を比べると、App Engineの方が楽そうなんだよなぁ。
でも、既存システムの移行の難易度で言うと、格段にBeanstalkの方が楽そうだなぁ。
App Engineの方がスケールしそうだしなぁ。でもAWSの方が自由度高いしなぁ。

と、これからは、クラウドをコーディネートする力が求められそうですね。
纏まりなくてすいません。

SEOとデザインは今後より密接になる理由 : could

良い記事。
WEBサイトもSEOもコンテンツありき、ですね。
そしてソーシャルメディアの場合は、コンテンツ≒人 ですね。

サイト（コンテンツ）を作る前に考えるべきこと

• Webサイトにおけるビジネスゴールは何か？
• なぜ Web サイトが必要なのか？
• 誰に向けてコンテンツを配信したいか？
• 利用者に提供したいコンテンツは何か？
• 利用者が欲していると感じるコンテンツは何か？
• どのように利用者のもつ問題を解決するのか？

ゆっくりと確実に変化するWeb制作のルール | 住 太陽のブログ

言っちゃった。
WEBサービスがコモディティ化してるのに、それでも独自ドメインでイチからWEBサイトを製作するのは不誠実だ、と。

私が受託開発に未来は無いと思った一番の理由が、「ソフトウェアエンジニアは、車輪を再開発したがる」でした。
少し業務要件を変えてでも、パッケージとかオープンソースとか有りものを活用した方がイイと判っていても、工数ほしいからイチから作っちゃう。
今はウェブサービスを活用した方がクライアントの為だと本心では思っても、自分達が食べる為にはオーダーメードのシステムを作り続けないといけない。
その構造と一緒ですね。

今は無料or格安でブログを立ち上げられるし、Twitter と Facebook がある。
極端な話、大手のWEBサービスを使わないとしても、その3つで事足りてしまう気がする。
今年あたり、Facebookファンページ上にECサイトを作る、という案件が急増しそうな予感。

X. プロモーションする対象のサービス

A. 最大限のマーケットの大きさ。つまりは全体でターゲットになるユーザが何人いるか。
B. Xをしらないユーザ
C. Xをしっているユーザ
D. Xをしっていて興味をもたなかったユーザ

当然ながら、A=B+C+Dとなる。そして僕はプロモーションをするときにB,C,Dの比率がそれによってどう変化するかを考える。

特に長期的な戦略を考える場合には重要視するモデルだ。

このモデルのパラメータに実際にユーザになった数がはいっていないのも、僕的には重要なポイントだが、まあいい。あとで説明する。

で、この場合のプロモーションでベストな基本戦略は以下のとおりだ。

戦略１．　Bはできるだけ減らさない。

戦略２．　Bが減った分、CとDが増えるが、できるだけCを増やして、Dは増えないようにする。

↑これが効果のないプロモーションはマイナスのプロモーションになる理由だ。

マイナスのプロモーション – はてなポイント３万を使い切るまで死なない日記

すごく良い記事。
プロモーションに関して言えば、「やらないよりやった方がマシ」では無く、「やらない方がマシ」が存在すると言う話。

IANAによるIPv4アドレスの配布が事実上終了 － Publickey

Geekなぺーじ : IPv4アドレス枯渇。その意味と恐らくこれから起きること

ついにきた。

私がまだネットワークエンジニアのつもりだった頃IPv6を学んだのはもう10年以上前の様な気がする。KAME projectで踊るカメが見えたとか見えなかったとか。
その当時は数年もすれば国策としてのIPv6が普及してIPv4は消えていくんだろうと思ってたけど、IPv4はNAPTを駆使してしぶとく生き残ってきた。

JPNICで枯渇するのも時間の問題です。
いよいよ悠長な事言ってられなくなってきた訳です。
新規でWEBサービス立ち上げるハードルが上がっちゃうじゃねーかコンチクショー！な人もいるかも知れませんが、そこはクラウドがあるじゃないですか。

あのテレビCMを見てGALAPAGOS（ガラパゴス）に飛びつく程度に、ITに詳しくない人たちが、果たして自宅の無線LAN構築から、GALAPAGOS（ガラパゴス）をWiFi端末として認識させるところまで、すんなりとできるだろうか。
SHARP、GALAPAGOS（ガラパゴス）の哀れをもよおすテレビCM: 愛と苦悩の日記

GALAPAGOSに関する至極最もな疑問。
誰に売るのか？この製品は誰を喜ばすものなのか？
一見、GALAPAGOSの戦略にはグランドデザインが欠如している様にも思えるけど、GALAPAGOSメディアタブレットには明確な意思が込められている気がする。

キャリアに依存しない収益構造の模索、だ。
模索してるから、製品設計のコンセプトもプロモーションもなんか的を射てなかったり、ブレてる。
そう考えると、生暖かい目で見守る気にもなってくる。

私はiPadユーザだけど日本人だから、建設的な意見も述べてみます。
GALAPAGOS は ePub3 がスタンダードになる前に、つまり2011年中に、利用者にとってXMDFが如何に優れているか徹底的にプロモーションし、端末をディスカウントしてでもシェアを伸ばすべきだ。今はそれ以外、無い。
1万円台だったら、私も買います。

ブラウザでChromeを使ってる人はCtrl+Shift+Jを押せばHttpヘッダー情報見れます
Google App EngineではAdmin権限でリクエストするとCPU使用率と1リクエストあたりの課金額がわかる – あおうさ＠日記

知らなかった！

Ctrl + Shift + J でDevelopper Tools起動 -> [Resources]タブ選択 -> 左ペイン[RESOURCES]からHTML本体をクリック -> 右で[Headers]タブ選択

でHTTP Responseヘッダが見られます。

	X-AppEngine-Estimated-CPM-US-Dollars:
	X-AppEngine-Resource-Usage:

がソレです。便利。

Amazonクラウド、Oracle 11gのデータベースサービスを発表。パッチ適用やバックアップなど運用は全部クラウドにおまかせ － Publickey

AWS Elastic Beanstalkもそうだけど、いよいよエンタープライズ分野を攻略する気マンマンなAmazon様が、Oracleも用意して下さる。
これは良いニュースだ。
ORACLEマスター涙目。

サイトに設置した「いいね!」の押され具合をデータで解析する方法 | Web担当者Forum

自サイトに設置したFacebook「イイね！」ボタンがどれ位押されたかを見るには、Facebookインサイトを使えば出来る。Facebook用のタグが正しく記述されているかはURLリンターを使う。

昨年度の電波利用料収入は642億円。これは一般会計だが、実質的にはすべて総務省が使える隠れ特別会計になっている。来年度の総務省のICT予算が約1200億円だから、その半分以上の隠し財源を持っているのだ。
池田信夫 blog : 電波利用料という「隠れ特別会計」 – ライブドアブログ

総務省が周波数オークションを見送った理由は電波利用料が隠し財源になっているから、だそうです。
いやぁ、許せませんな。

Androidスマートフォンのシェアが全世界1位に、iPhoneもSymbian OSも抜き去る – GIGAZINE

全世界でAndroidスマホのシェアが1位になったそうです。
日本は？

キングジムのEvernote対応メモ（ショットノート）がもうすぐ出ますよ | goryugo, addicted to Evernote

これは・・・
iPhoneに取り込む為の紙。
iPhoneアプリと組み合わせると、その紙のタイトル欄と日付欄がOCRで読み込まれるみたい。
そしてEvernoteに投稿できるらしい。

Salesforce chatter.com 日本

早速登録してみました。すこぶる簡単です。
会社で1番です。でも2番は居ないかもしれません。
Salesforce.comのアカウントとか不要です。必要なのは会社のメルアドだけ。

中小企業とかこれを使わない手は無いんじゃないかな。

企業内コラボレーションツールがTwitter化、今度は企業向けSNSの様にはならない？

セールスフォース、誰でも無料で使える企業内ツイッター「Chatter.com」公開。日本語対応で利用者数上限なし － Publickey

[salesforce]Chatter.comがはじまった | ウフル技術ブログ

Amazonクラウドから、1時間あたり約1.8円（Linux/Unixの場合＄0.02、Windowsで$0.03、1ドル90円で計算）、24時間で約43円、1カ月で約1300円という低価格のインスタンス「Micro Instance」（マイクロインスタンス）が発表されました。
…
マイクロインスタンスで提供される仮想マシンの性能は、613MBメモリ、一時的に最大2EC2 Compute Unitsとなっており、通常の性能としては「少しのCPUリソースが提供される」という表現にとどまっています（英語版のMicro Instancesの解説より）。

つまり、ふだんは大した性能を提供しないけど、負荷が高まったら少しの間だけ大目に見ましょう。という感じのインスタンスのようです。
Amazonクラウドから「1円クラウド」（自称）登場。Amazonクラウドの値下げが続く － Publickey

格安ホスティング業界にはなかなかのインパクトがある話だと思いますが、それを利用したり代理店をしたりする事が多いWEB製作業にとっては良い話じゃないですかね。

ミドルウェアを構築しなければいけないとか、何も考えずインスタンスを落としちゃうとデータが消えるとか、非技術系のWEB製作会社とかにはまだまだ敷居が高いですが、構築された仮想サーバを流用するなり、一度作ってしまうなりすればWEBサーバ環境が量産できるわけだし、静的なHTMLだけならデータが消えてもデプロイしなおせばよいだけだし。

セキュアに運用するコツさえつかめれば、小規模なWEBサーバのホスティングでもAmazon EC2が有力な選択肢になるんじゃないでしょうか。

ほらね。今は、新しいサービスを作るには、絶好のチャンスなんですよ。わたしもトライするし、いろんな人にトライしてもらいたいなぁと思います。

こんなこと書いて、お前になんの得があるんだと思われる方、あるいは、どうしてそんなに必死なんだと思われる方もいるかと思いますが、理由は簡単。私が新たなサービスを立ち上げて仮に成功したとしても、その効果はたかがしれています(自分の周りだけ)。

行動力なある人がどんどん、次の成長分野に挑戦して成功するとで、日本も成長路線に戻れるかもしれません。ほっとくと日本は衰退するからね。

グローバルな社会なんだから、日本が貧乏になろうが、金のあるところから取ればいいだろうと思う方もいると思いますが、日本人である以上そこまでドライには考えられないのが、実際のところ。

だからこそ、次の成長分野に一緒に挑戦しようよということです。

新しいサービスを作るのになぜ今が絶好のチャンスなのか – ひがやすを blog

（´；ω；｀）ﾌﾞﾜﾜｯ
感涙。

トライしましょう。
Google App Engine と slim3 に感謝しつつ。
そして恩返しの為にもブレイクしたいものです。

さて、ひがやすをさんも言われる様に、WEBサービスを立ち上げるにあたって、クラウド、HTML5、スマートフォンと、天の時は今な訳です。

slim3やGAEやHTML5が書ける方は勿論、コードを書く意欲と能力があるなら、兎に角行動する事が可能です。

ただ、打率を上げる為には、UIとかのデザインとか企画とかコンテンツとか、自分にないものを補える仲間がいた方がいいと言う意味では、人の和が一番重要です。

それはさておいて、地の利について。

資金があるとか、人脈があるとか、一芸に秀でているとか、一部の優秀な人は除き、そうでない普通の人(私の様に)は、会社をやめて起業してWEBサービスを始めるというのはリスクが大きいです。

参入障壁が少ないとしても、新規WEBサービスなんてものは10個やって1個あたれば儲けモノ位に考えたほうがいいです。

覚悟を決めて打席に立つ事をしないとヒットは打てませんが、何度でも打席に立てるように自分のポジションをもっていくなどの工夫が重要です。

なので週末起業でも良いと思うんです。

それも難しいなら、今いる会社で稟議起案してみてはどうでしょう。

それも無理なら・・・転職もアリです。

WEBサービスを立ち上げたい、と思っていても、人材がなかなか見つからない中小企業も沢山有るはずです。

以前も書きましたが、エンジニアは中小のエンドユーザ企業にいた方が、資金、経営、プロモーション、法務などの色々なリソースを活用できて、得意分野に集中できるってモンです。

ただ、所詮雇われ、意思決定のスピードとかはスポイルされます。

勿論、勝算のあるビジネスモデルとサービスのアイディアの有る方は、起業してチャレンジして頂きたい。そして無力な僕を雇ってください。

インターネットイニシアティブ（IIJ）のマーケティング本部 GIOマーケティング部 副部長 小川晋平氏は、月額4000円、日割り課金で1日約133円のホスティングサービス「IIJ GIO」のブロガーミーティングでこう語りました（参考：AmazonクラウドのSmallインスタンスは1時間あたり0.085ドル。24時間で2.04ドル）。
…
プラットフォームサービスとして提供されるホスティングとして、仮想サーバとCentOS、インターネット接続だけの「ベーシックプラン」、もしくはこれに加えてApacheとvsftpdによるWebサーバ／ftpサーバ機能が利用可能な「Webプラン」が月額4000円から利用可能。料金は日割りで計算されるため、最小で1日あたり約133円からとなります。
…
利用者がGIOのコントロールパネルから設定すれば、すぐに（実際には20分程度）サーバのインスタンスが立ち上がってくるのはAmazonクラウドと同様です。数百台といったインスタンスを次々に立ち上げることができます。

ただし法人利用が前提となっているため、AmazonクラウドのようにクレジットカードがあればWebからサインアップというわけにはいきません。まずIIJと法人取引契約を結んだあとで、コントロールパネルのIDを発行してもらい、そこからGIOを利用するということになります。

新規契約から利用開始までは約2週間かかるそうですし、課金は月額ベースですから、IIJ GIOを「クラウド」と呼ぶべきなのかどうかは議論が分かれるところでしょう。僕自身もIIJ GIOはクラウドというより、企業向けの柔軟なホスティングサービスと表現するのが妥当ではないかと思います。
クラウドの価格競争で「いずれIaaSは1日100円を切る」と予想するIIJが、Amazonクラウドに対抗する理由 － Publickey

IIJがあえて儲からないIaaSに参入しかつグローバルで競争（Amazonと価格競争）する理由は、「運用などの付加価値サービスは儲かるから」。

ホスティングサービスの内容はAmazon Web Services と似たものの様に見えますが、IIJ GIOは主に企業向けをターゲットとしたホスティングサービスの位置づけの様です。

さくらInternetによる石狩データセンターによるVPSの取り組みや、ニフティのクラウドサービスもそうですが、来年あたりには国産IaaSの選択肢が増えそうで、実に喜ばしい事です。

但しそうこうしている間に海外では、クラウドの主戦場はPaaSになっていってる訳です。

Spring Frameworkを買収したVM Ware社が良い感じに台風の目となり、世界で600万人いるというJava開発者（ほんまかいな）を取り込むべく各クラウドベンダは動いています。「VM Force」然り、「Google App Engine for Business」然り。

なんか2010年末以降は慌しくなりそうです。

「いままで企業内のコラボレーションといえば、メッセージング、スケジュール管理、電子掲示板、ドキュメント共有といった機能を備えるグループウェアが主役でした。しかし、いまそれが大きく変わろうとしています。
いま開発中の企業内コラボレーションツールの多くが、TwitterやFacebookのように、つぶやきとタイムラインを中心としたマイクロブログ的なユーザーインターフェイスを備えているのです。画面を並べてみましょう。」

企業内コラボレーションのTwitter化 － Publickey

以下の企業向けコラボレーションツール（サービス）の画面が比較されています。

・セールスフォース・ドットコムの「Salesforce Chatter」（現在β公開中）

・IBMが開発中と伝えられている「Project Vulcan」

・マイクロソフトの「Office Talk」（開発中）

・シスコの「Cisco Quad」

・SAPが開発中の「SalesOnDemand」

企業向けSNSはイマイチ浸透しなかったけど、今度はソーシャル機能単体じゃ無くて、ビジネス支援のアプリケーション又はサービス群と協調するTwitterライクなミニブログ、という位置づけである事が大きな違いでしょうか。

企業向けSNSがイマイチ浸透していない理由の一つに、既存システムとの親和性があると思います。既にOpenIDでSSO（シングルサインオン）を実現してます、とかいう先進的な企業は、あまり聞いたことがありません。

最も企業内で普及している認証サービスは、多分Microsoft社のActive Directoryでしょう。
ただActive DirectoryはWEBサービスとの連携という意味ではイマイチです。

殆どの企業は、グループウェアを導入していたらそのアカウントは別に持っているんじゃないでしょうか。そこに仮に後付けでSNSをポンと立てても、アカウントを覚える数が増えるので面倒くさくなって使わなくなってしまうんじゃ無いでしょうか。

そういう意味では、Salesforce.comのChatterにはちょっと期待しています。