Facebook が Open Graph API を遮断 ： 外れてしまった Yandex の狙い
Wonder No More. Yandex Pulls Social Discovery App After Facebook Closes Door On Graph API Use + Says It’s A Competing Search Engine
http://wp.me/pwo1E-5QI
Ingrid Lunden – January 30th, 2013
http://techcrunch.com/2013/01/30/wonder-no-more-yandex-says-facebook-has-given-a-final-no-on-graph-api-usage-will-pull-its-social-app/
Some closure on the story of how Yandex — the Russian search giant — built a social discovery app that relied on Facebook interconnection to gather data, and then found Facebook blocking its service within hours of launching.
ロシアのサーチ･ジャイアントである Yandex だが、これまでに開発してきた、ソーシャル･ディスカバリー･アプリの廃止に追い込まれている。それは、Facebook が集めるデータとの接続に依存するものだが、ローンチから数時後に、そのサービスを Facebook がブロックしていることが判明した。
Today Yandex said that after discussions with the social network, Facebook has finally, terminally said that the app violates its Platform Policies, specifically on the point of Wonder being a competing search engine. Facebook will not reinstate the ability to use Facebook’s Graph API, so as a result, Yandex is planning to pulll the app from the app store and put it on hold for now.
今日（1/30）のことだが、Yandex は、このソーシャル･ネットワークと議論した後に、Wonder が Platform Policies に違反し、さらには、競合するサーチ･エンジンになっているという、Facebook の発言を引用している。Facebook は、その Graph API を、Yandex に対してブロックし続けるだろう。 それを踏まえて、このアプリをアップ･ストアから引き下げ、保留にすることを、Yandex は計画している。
The full statement from Yandex:
以下は、Yandex からのフル･ステートメントである:
“We discussed the issue with Facebook and it was confirmed that Facebook views the application Wonder as something that violates the Facebook Platform Policies (section I.12) and that the access to Facebook’s Graph API will not be restored.
“According to Section I.12, no data obtained from Facebook can be used in any search engine or directory without the company’s written permission. The reason behind Facebook’s decision to revoke our access to their data appears to be that they do consider Wonder to be a search engine, while our understanding of what it is differs from this view.
“Wonder’s functioning, in its current state, as well as the quality of user experience it provides, largely depends on the access to Facebook’s Graph API. Since this access was revoked, we decided to put our application on hold for the time being. We will be considering partnership opportunities with other social networks and services to offer our users a richer internet experience via Wonder.”
この問題について、私たちは Facebook と議論した。そして Facebook が、この Wonder アプリに対して、Platform Policies（Section I.12）だと見なし、また、Graph API へのアクセスが復活しないことが確認された。
Section I.12 によると、Facebook から得られる、あらゆるデータは、同社による書面での許可を受けることなく、いかなるサーチ･エンジンおよびディレクトリで、利用することができないとされている。彼らのデータに対するアクセスが取り消された背景には、Facebook が Wonder を サーチ･エンジンであると認識しているのに対して、私たちは異なるものだと認識しているという、考え方の相違があると思われる。
現時点における Wonder の機能は、提供されるユーザー･エクスペリエンスの質的な向上であるが、それと並行して、Facebook の Graph API アクセスに大きく依存している。 そのアクセスが無効とされたことで、このアプリについては、保留にすると決定した。 したがって、私たちは、他のソーシャル･ネットワークおよびサービスとパートナーシップを構築し、Wonder を介したリッチなインターネット･エクスペリエンスを提供していくことになるだろう。
The emergence of Wonder, and a week before the blockage of Voxer, has kicked off a new level of scrutiny about how Facebook allows other apps to appropriate its data: in effect, the company has said that it is not sharing with apps that don’t share back, or that replicate core functionality without permission.
Wonder の出現と、その1週間前に起こった Voxer の出来事は、他のアプリケーションが Facebook のデータを利用する適切な方式という、新しいレベルにおける調査の始まりでもあった。 そして、その結果において同社は、共有した結果を戻さないアプリや、コアとなる機能を許可なく複製するアプリとは、共有していかないと発言している。
The Wonder app, which was nearly a year in the making, was put together by Yandex Labs, which is based in Palo Alto, CA. I actually met the three leads on the project, Maxim Grinev, Maria Grineva and Sergey Fayfer, for the first time in person yesterday, as I’m in town for the week.
約 1年をかけて開発されてきた、この Wonder アプリは、Palo Alto, CA をベースとする、Yandex Labs によりまとめ上げられた。 昨日（1/29）のことだが、その街を訪れた私は、このプロジェクトの 3人のリーダーである、Maxim Grinev および、Maria Grineva、Sergey Fayfer と会ってきた。
They told me about how the idea germinated from their own move to the Bay Area a year ago, when they were trying to figure out what to do and where to go when they arrived, because, in their collective mind, there wasn’t a good enough social app out there to provide that kind of recommended viewpoint.
彼らは、何処へ行って何をすれば良いのかを 1年前に理解し、Bay Area に引っ越してきたことで、このアイデアが生じたと、話してくれた。なぜなら、この種のリコメンデーションの視点を、充分なかたちで提供するソーシャル･アプリは存在しないという認識が、彼らの中で共有されていたからである。
The app then went on to be built using a number of different features — including Nuance-powered voice recognition, API feeds from various other social networks like Foursquare, and new algorithms for how to digest and cancel out repetitive news in favor of more up to date information — but without the core dataset provided via Facebook’s Graph API, the carpet was effectively pulled from under Wonder.
そして、このアプリは、数多くの機能を用いることで構築されていった。そこに含まれるものとしては、Nuance がパワーを提供する音声認識や、Foursquare などのソーシャル･ネットワークフィードされる多様な API、そして、人々が好む最新情報を抜き出し、また、重複を排除していくための、新しいアルゴリズムなどが挙げられる。しかし、Facebook の Graph API たら提供される、コアとなるデータセットに依存することなく、そのカーペットを効果的に、 Wonder の足元まで持ってくることは不可能だ。
Considering that Facebook flat-out thinks of Wonder as a search engine, and one that competes against Facebook itself, makes one speculate about what else Facebook has planned for its own, new Graph Search feature in the future.
Facebook が率直に、Wonder をサーチ･エンジンとみなし、また、自身と競合するものと認識したことで、現時点で計画されている範囲を超えて、これからも新しい Graph Search 機能が登場してくると、推測することが可能になる。
And if there are more apps — or would-be apps in development — that might find themselves blocked in future, will we see companies begin to look for alternative solutions? Is there room for another social data aggregator like Facebook in the market?
そして、もし、それら以外のアプリが、また、これから開発されるアプリが、将来においてブロックされると認識されるなら、それらの企業は代替えのソリューションを探し始めるのだろうか？ そして、このマーケットには、Facebook のような、別のソーシャル･データ･アグリゲータのための空間が存在するのだろうか？
Equally, it’s worth wondering whether we will see some of the smart technology that went into Wonder appearing elsewhere — something Yandex had already said it would consider even when it first launched its Wonder “experiment.” It was potentially a route for Yandex to build its profile and dataset for U.S. consumers, and English-language users, so it’s clear that these markets remain in the company’s sights.
それと同様に、Wonder が示したような領域へ、新たに飛び込んでいくスマートなテクノロジ－について、考える価値も生じていくる。 それは、Yandex が Wonder に「実験」を開始した当初から、すでに考えていたであろう、何かである。また、それは、アメリカのユーザーと、英語圏のユーザーのための、プロファイルとデータセットを構築するという、Yandex のための潜在的なルートでもあった。 したがって、このマーケットが、同社の視界の中に留まり続けることは明確である。
ーーーーー
Crunchbase
Company: Yandex
Website: yandex.ru
Launch Date: September 23, 1997
IPO: NASDAQ:YNDX
Yandex is an internet technologies company that operates in Russia, CIS and Turkey. It is the largest Russian and fifth-largest world internet search engine. Yandex is an acronym for the phrase Yet Another Indexer. As of December 2011, Yandex had 60.9% of the Russian search market (source: LiveInternet.ru). Yandex’s mission is to give the answer to the user anytime and anywhere. Company provides its services for desktop and mobile users and develops embedded solutions as well. The company specializes on highly-targeted sophisticated…
Yandex は、Russia／CIS／Turkey で運用される、インターネット･テクノロジー企業である。 それは、Russia で最大であり、世界でも 5番目に大きな、インターネット･サーチ･エンジンである。 Yandex は、Yet Another Indexer から頭文字を抜き出した名称である。 2011年12月の時点おいて、Yandex は Russia のサーチ･マーケットの 60.9％ を有している（情報源： LiveInternet.ru）。 Yandex のミッションは、Anytime and Anywhere で、ユーザーに答えを提供することである。 同社は、デスクトップとモバイルのユーザーに対して、また、エンベッド･ソリューションにおいて、そのサービスを提供している。 そして、きわめて洗練された、高度な目標に対して、特化されている・・・
ーーーーー
先日に、『 Yandex の Wonder は、ロシアからアメリカへ向けた観測気球なのか？ 』というタイトルの抄訳をポストしましたが、この Yandex の狙いは外されてしまったようですね。Facebook に蓄積した情報であれば、（その持ち主が同意するなら）何でも引き出せる Open Graph は、これからの IT を構成する、きわめて重要なテクノロジーになるはずです。 しかし、この Wonder のケースのように、外部からの API を介した検索は NG というのが、Facebook の基本スタンスのようです。この話は、あくまでも Facebook と Yandex の取り決めという、限定された範囲にフォーカスするものですが、プライバシーと利便性とリテラシーについて、より本質的なところで、議論していく必要があるのだろうと思います。Open Graph からは、目が離せませんね。
ーーーーー
＜関連＞
Facebook の Open Graph ： すでに 4000 億回 の インタラクションを達成
Facebook の Graph Search について、簡単だが説明したい ： GigaOM
Google の Knowledge Graph は、スタートレックを目指す！
Yandex が Bing を追い越した ： 検索マーケットの４番手に踊り出る
Yandex と CERN がコラボ！ 機械学習と物理学は 共鳴するのか？
BaaS で自由になる？ それとも便利になる？ そして DoCoMo の i-Concier は？
Mobile Backend-as-a-Service (MBaaS): Give me Liberty or give me… Convenience?
http://wp.me/pwo1E-5li
Guest Author, November 29th, 2012
http://blog.programmableweb.com/2012/11/29/mobile-backend-as-a-service-mbaas-give-me-liberty-or-give-me-convenience/
This guest post comes from Miko Matsumura, Senior Vice President of Platform Marketing and Developer Relations for Kii Corporation. Miko main role at Kii is evangelizing the Kii Cloud Mobile Backend-as-a-Service (MBaaS).
What’s good about MBaaS?
MBaaS provides mobile developers with LIBERTY and CONVENIENCE. LIBERTY in the sense of self-determination, control and an independent destiny–they can communicate with, manage, understand and serve their users without being beholden to external influences. An app developer who doesn’t control their users has no independent future. CONVENIENCE is a simple matter of reducing time-to-market, risk and cost of development.
LIBERTY は、自身による判断と制御、そして独立した運命の意味を持つ。つまり、外部からの影響を受けることなく、ユーザーに対するコミュニケーションとサービスを実現し、その関係を理解し、管理していく。自身のユーザーをコントロールしないアプリ･デベロッパは、独立した未来を持ち得ない。 CONVENIENCE は、ビジネスを立ち上げる時間と、開発におけるリスクとコストを低減するという、シンプルな論点である。
MBaaS is only one of several options for cloud backend:
MBaaS は、クラウド･バックエンドにおける、いくつかの選択肢の 1つに過ぎない：
Why not just roll-your-own backend?
Now I’m sure the web-programming gurus here at ProgrammableWeb are all wondering why its not more convenient for mobile developers to write their own backends?
そして、ProgrammableWeb 上において、Web プログラミング接着剤だと確信できるものが、自身のバックエンドを書こうとするモバイル･デベロッパーにとって、さらに便利なものになるなら、それがなんで悪いのか？
Reasons vary, but in our experience, these factors are pretty common among mobile app developers, particularly independent app store developers who are often just one person (and in some cases someone who has a full time job doing something else).
さまざまな理由があるが、私たちのエクスペリエンスにおいて、以下の要因は、モバイル･アプリ･デベロッパーに共通するものである。そして、大半のケースにおいて、1人で作業を行う、独立したアップ･ストア･デベロッパーにおいて顕著なものとなる（そして、何らかのテーマに、フル･タイムで取り組むデベロッパーにも共通する）。
- Pace: especially when competing in major app stores, the pace of mobile app development demands at least bi-weekly updates, patches and bug fixes. There’s no time to architect scalable back-end services.
- Learning Curve: some mobile developers can double as server programmers, some can’t–but more importantly, the pace is fast enough on the client that they can’t afford to context switch.
- Stack Risk: stacks can be confusing? MongoDB? Couch? Cassandra? MySQL? Postgres? Ruby? Python? PHP? Node? For some this is simple, but not for all. The consequences of picking the wrong combinations can be severe.
- ペース：特に、メジャーなアップ･ストア内で競争するとき。 モバイル･アップの開発ペースは、少なくとも隔週のアップデート／パッチ／バグ･フィックスを要求する。 そして、スケーラブルなバックエンド･サービスを、デザインする時間がない。
- 学習曲線：サーバー･プログラマーを兼任できる、モバイル･デベロッパーもいいれば、それが難しいこともある。しかし、それよりも重要なことは、容易なコンテキ･ストスイッチが不能なクライアント上で、十分に速い学習のペースが得られるところにある。
- スタックは、混乱するだろうか？ MongoDB? Couch? Cassandra? MySQL? Postgres? Ruby? Python? PHP? Node? いくつかはシンプルであるが、すべてではない。 不適切なコンビネーションの選択は、厳しい結果を生じるだろう。
Turns out it’s a full time job to keep users happy and release new versions of apps in the ragingly competitive app stores.
分かったことは、熾烈に競い合うアップ･ストア内で、ユーザーを満足させ、また、新バージョンのアプリをリリースしていくには、フル･タイムの作業が必要ということである。
So MBaaS fills in the sweet spot in this chart by giving mobile app developers liberty over their own users, their own data and other such benefits, but with relative convenience–not requiring them to invest large amounts of time and effort in building and scaling back-end services.
したがって、MBaaS は、モバイル･アプリ･デベロッパーに自由を与え、彼らのユーザー／データ／メリットなどをカバーする点において、上記のチャートで及第点を得ている。しかし、相対的な利便性については、バックエンド･サービスの構築とスケーリングにおいて、彼らに大量の時間と労力を投じるようには要求しない。
Liberty is more important than convenience
To paraphrase Ben Franklin, those who would give up liberty for the sake of a little convenience deserve neither liberty nor convenience.
Ben Franklin の言葉を、ちょっとした便利さのために自由を諦める人々は、自由も便利さも手にすることができない、と言い換えられるだろう。
This is the biggest mistake of mobile developers when selecting a mobile backend strategy. Now another way of looking at it is that many developers marry their MBaaS for “love” (features) rather than “money” (business reasons). Many developers are in such a hurry to ship the next feature or version of their product that they just fall in love with whichever tool comes in handy. Or even more commonly they fall in love with the tools that are the most elegantly designed or have the coolest feature set. One issue can be that once you select, it can be hard to switch.
それが、モバイル･バックエンド戦略を選択するときに、モバイル･デベロッパーが犯しやすい最大の誤りである。 そして、数多くのデベロッパーが、 “money” (business reasons) よりも “love” (features) のために、MBaaS に依存し続けるという、別の道筋が見えてくる。 数多くのデベロッパーが、そのプロダクトに新機能や次期バージョンを矢継ぎ早に送り込もうとするのは、どんどんと便利になってくるツールとの、恋に堕ちるからである。 それよりも一般的なケースは、最もエレガントにデザインされ、クールな機能のセットを取り込んだ、ツール自体に惚れ込んでしまうことだ。 一度、決めてしまったことが、その後の変更を、とても難しくすることもあり得るのだ。
A longer term and more business-oriented view of this decision may save a lot of trouble down the road. When selecting an MBaaS partner (and there are many) it’s probably worthwhile to consider whether the provider is going to be in business a year from now or even 6 months from now. Startups get acquired (or worse, acqui-hired) or even run out of business. Be sure to understand whether your supplier has sufficient history of operation and a stable financial base.
そのための判断において、よりビジネス的で長期的な視野を持てば、これからの道筋に潜んでいる、数多くのトラブルを回避できるだろう。 MBaaS パートナー（数多く存在する）を選ぶときに、対象となるプロバイダーが 1年後に、あるいは 6カ月後に、ビジネスを展開しているのかどうかを考えることに、おそらく価値が生じる。 スタートアップには、買収される可能性がある（最悪は人材だけを買われてしまうケース）。 さらには、ビジネスから脱落することもある。 あなたにとってのサプライヤが、充分な実績を持ち、財政的にも安定していることを、確認すべきである。
Backend case study: NTT DoCoMo i-Concier
To understand what it takes to provide reliable service, we can take a look at the Kii Cloud MBaaS currently deployed by the largest carrier in Japan to millions of paying subscribers of the i-Concier™ mobile sync service. Historically, this kind of reliability, elasticity and scalability was only available to the largest carriers in the world, however, Kii has opened this service up to the developers of the world.
信頼性の高いサービスを提供する際に、必要となるものを理解するために、Kii Cloud MBaaS に注目してみる。それは、Japan で最大のキャリアにより、i-Concier モバイル同期サービスの何百万という有償サブスクライバーに対して、現時点で提供されているものである。 歴史的にみて、この種の安定性／柔軟性／スケーラビリティは、世界での最大級のキャリアだけが提供できるものであったが、このサービスは Kii により、世界のデベロッパーへ向けて開放されているのだ。
Isn’t MBaaS part of the weird closed mobile bubble-world?
One of the greatest things about the Programmable Web is the glorious freedom of connecting services from anywhere to anything–and the ethos is supported by web standards like REST. It’s all so open and free (as in free beer).
Programmable Web において最も素晴らしいことは、あらゆる場所から、あらゆる事象にいたるまで、サービスの接続に対して輝かしい自由度を提供する点にある。 そして、この理念は、REST などの Web スタンダードによりサポートされる。 さらに言えば、その、すべてが、オープンでフリーなのだ（無料のビールのようなもの）。
This makes mobile development paradigms like HTML5 seem most attractive as these solutions are not fenced behind app stores and paywalls. I think theres plenty of room for this and environments like Node.js provide common language across client and server. Commenting on this is outside the scope of this post, but the short perspective on this is that there should be room for everyone in mobile.
それにより、HTML5 のように、最も魅力的だと思われる、モバイル開発のパラダイムがもたらされる。そして、それらのソリューションは、アップ･ストアや課金のカベに囲まれるものではない。 そこには、たくさんの考え方があると思う。そして、Node.js のような環境が、クライアントとサーバーにまたがる、共通の言語を提供している。 それについて意見を述べることは、このポストのスコープ外のことであるが、モバイルにおいては、それぞれの人々のための考え方があるというのが、私の簡潔な展望となる。
For those who do choose native mobile client programming, they do have to put up with ugly app store approval processes, app store “taxes” and a much more “closed” mindset around their technology stacks. But in exchange for being part of this world, developers gain access to monetization and professionalization and can build sustainable businesses with exponential growth properties. There’s room for everyone.
ネイティブのモバイル･クライアント･プログラミングを選ぶ人々は、面倒なアップ･ストアの承認プロセスと「税」に耐え、自身のテクノロジー･スタックに「閉じ込められた」固定観念を引きずらざるを得ない。しかし、この世界の一部になるこという交換条件により、デベロッパーたちはマネタイズとパーソナライズに取り組み、自身の特質を活用した、持続可能なビジネスを構築できる。 そこには、みんなのための方式がある。
ーーーーー
このところ、すっかりと BaaS にハマっている Agile_Cat ですが、例の Kinvey Subway Map に入っていないため、この Kii を見逃していました。 そして、先日、このところご無沙汰だった ProgrammableWeb に行ってみたところ、このような重要な記事を見つけたというわけです。最近の Agile_Cat の悩みは、この新たに作った BaaS カテゴリに、これまでの API カテゴリを統合すべきなのかというものです。 う～ん、どうしたものでしょうかね？
ーーーーー
＜関連＞
AWS イベントでの Parse が スゴそう – BaaS の勢いが加速する？
Ray Ozzie の Talko も、$4M の資金で BaaS に参戦！
Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
Bloomberg 金融アップストアがオープン ： Apple みたいに 30% をイタダキ！
モバイル BaaS って何だ？ Appcelerator による Cocoafish 買収から探ってみよう
Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
Kinvey Service Fixes Crack In Facebook’s Open Graph Back-End
http://wp.me/pwo1E-5xM
Dan Rowinski – November 12th, 2012
http://readwrite.com/2012/11/12/kinvey-service-fixes-crack-in-facebooks-open-graph-backend
Facebook’s Native Mobile Problem With Open Graph
In 2010, Facebook attempted to redefine the meaning of "verbs" in the Web Era. The company’s Open Graph turned users actions (such “Jon ran” or “Susie listened”) into status updates, tied to Web apps. The Open Graph opened up a new world of data to Facebook and its developer community. But there was a hitch and, like many of Facebook’s recent issues, the source was mobile. In the Mobile Era, Facebook’s Web-centric approach has caused it many problems, from monetization to user experience in its mobile app on iOS and Android.
Facebook は 2010年に、Web Era における「Verb」の意味を再定義しようと試みた。同社の Open Graph は、ユーザー･アクションを、Web アプリケーションに結びつけられたステータス･アップデートに置き換えた（ たとえば、“Jon ran”、“Susie listened” など）。 この Open Graph は、Facebook とベロッパー･コミュニティへに対して、新しいデータの世界へのドアを開けた。 しかし、Facebook における最近の問題のように、モバイルからのソースを、接続する必要があった。 そして Mobile Era になり、この Facebook の Web セントリックなアプローチは、iOS や Android といったモバイル･アプリにおける、マネタイズからユーザー･エクスペリエンスにいたるまで、数多くの問題をもたらしてきた。
クリックで拡大 ⇒
On the other hand, Facebook’s biggest strength is its ability to make connections between its users’ friends, what they “like” and what they do. The more threads that Facebook can tie to a user, the better able it is to sell advertising to them. That makes Open Graph the biggest single innovation Facebook has introduced in the last few years.
その一方で、Facebook の最大の強みは、Like などのアクションに関して、ユーザーのフレンドたちの間で、コネクションを作る能力にある。 そして、Facebook がユーザーたちを結びつけるスレッドには、広告を販売していく能力まであるのだ。それこそが、この数年において、Facebook が Open Graph に導入してきた、最も大きなシングル･イノベーションなのである。
Integrating Open Graph has been a problem since the it was announced in 2010 and expanded in late 2011 to include the new Timeline profile. Apps with Web-based back ends, such as Spotify, have been easily able to use Open Graph but the option for most native developers was beyond their means. But developers with “native” mobile apps had to go through extraordinary lengths to tie the Open Graph to their applications and only a handful of well-funded startups (such as Instagram or RunKeeper) with big development teams have been able to pull it off. The problem was that the backend systems for native mobile apps are difficult to optimize to Open Graph.
2010年の発表から、Timeline プロファイルを取り込んだ 2011年後半の拡張に至るまで、Open Graph の統合は問題をかけ続けてきた。Spotify のような、 Web ベース･バックエンドを持つアプリケーションは、Open Graph を容易に使うことができたが、大半のネイティブ･デベロッパーのための選択肢は、彼らの手段を超えたところにあった。 しかし、Native のモバイル･アプリを取り扱うデベロッパーは、自身のアプリと Open Graph を結び付けるために、並外れた長さのパスを通り抜けなければならなかった。そして、大規模な開発チームと資金力を持つ、ほんのひと握りのスタートアップ（Instagram や RunKeeper などの）だけが、それをやり遂げることができた。つまり、ネイティブ･モバイル･アプリのためのバックエンド･システムを、Open Graph に最適化することが難しいという、問題が存在していた。
Kinvey’s Middle Point
A startup in Boston is aiming to fix that. Kinvey, a “Backend-as-a-Service” provider for mobile application development, has created a simple way for native developers to connect their apps to Open Graph and allow users to use easily use more "verbs" on their timelines from their smartphones and tablets.
ある Boston のスタートアップが、その問題を FIX しようとしている。 モバイル･アプリ開発のための Backend-as-a-Service であるKinvey は、ネイティブ･デベロッパーのアプリと Open Graph を接続するための、容易な方法を作り上げている。そして、ユーザーたちは、スマートフォンとタブレットから、自身の Timeline 上で、さらに多様な Verb を利用できる。
クリックで拡大 ⇒
Open Graph functions by pulling in data from Web endpoints by connecting the action (verbs like "run," "cook," "listen" etc.) with metadata from the Web app. So, if I am baking cookies, I can hit the “I baked cookies” button on some webpage and Facebook will crawl for the metadata associated with that action and post it to Timeline. This works only because the webpage has metadata, stored on the Web, that Facebook can crawl. Mobile apps do not often have this type of metadata available to be searched, nor any backend system or URL that Facebook can crawl.
Open Graph の機能は、Web アプリからのメタデータと、アクション（ run、cook、listen など）を結び付けることで、Web エンド･ポイントからデータを引き出す。したがって、私がクッキーを焼いているなら、いくつかの Web ページ上で、「私はクッキーを焼いた」ボタンをクリックできる。そして Facebook は、そのアクションと結び付けられるメタデータを探し出し、Timeline にポストしてくれる。 この機能は、Web ページがメタデータを持ち、それが Web ページにストアされ、さらに Facebook がクロールできるときにのみ、上手く処理される。 しかし、大半のモバイル･アプリは、この種のサーチに対応するメタデータを持っていない。 さらに言えば、Facebook がクロールできる、バックエンド･システムも URL も同様である。
Kinvey has a simple solution. It takes the metadata (known as the “object”) from a mobile app and hosts it on its own servers. It then takes that data and creates its own Web endpoints for Facebook to crawl. It is a clever bit of integration. Kinvey is not changing the basic nature of Open Graph nor doing anything extraordinarily technical, rather it is creating a new middle point between a developers’ apps and the Open Graph – with an interface that lets them push or retrieve data. Kinvey sets up the entire system on its own and handles the data flow for the developers.
Kinvey には、シンプルなソリューションがある。 それは、モバイル･アプリからメタデータ（ ojeect のこの）を受け取り、自身のサーバー上にホストする。 続いて、そのデータを取得し、Facebook からクロールできる、自身の Web エンドポイントを生成する。 それは、インテくグレーションのための、利口なやり方である。 Kinvey は、Open Graph の基本的な特性を変えることもなく、また、テクノロジーに走りすぎることもない。どちらかと言えば、データを Push/Get するためのインタフェースを用いて、デベロッパーのアプリと Open Graph の間に、ミドル･ポイントを作るだけである。Kinvey は、自身の環境にシステム全体を設定し、デベロッパーのためにデータ･フローを処理する。
Good For Everyone?
The benefit for mobile developers is clear: they can extend native apps actions to Facebook’s entire population and make them accessible on Timeline without creating an entirely new structure.
モバイル･デベロッパーにとって、明らかなメリットが生じる。 つまり、ネイティブ･アプリのアクションを、Facebook の全ユーザーへ向けて拡張できる。そして、まったく新しい構造を作ることなく、Timeline へのアクセスを実現していく。
Facebook benefits because it does not have to completely reconfigure Open Graph to serve the large native mobile developer environment. Plus, it gets previously unavailable data from smartphone and tablet users. This could significantly help Facebook spread through the app ecosytem just as it has already done with Web pages.
Facebook にも、メリットが生じる。なぜなら、巨大なネイティブ･モバイル･デベロッパー環境をサポートするために、Open Graph を再定義する必要がなくなるからだ。 さらに、以前には対応できなかった、スマートフォンとタブレットのユーザから、データを受けとることが可能になる。 それにより、すでに Web ページで完了しているように、Facebook の大規模な拡散を、アプリ･エコシステムを介して促進できる。
Users get the benefits of Open Graph on the Web extended to mobile applications.
そして、ユーザーは、Web 上での Open Graph のメリットを、モバイル･アプリにも拡張できる。
ーーーーー
BaaS にも、いろいろなタイプがあるはずなので、一概には言えませんが、このように、エンド･ポイント間のミドル･ポイントとして機能するというのは、とても分かりやすい話ですね。
なんというか、Agile_Cat にとっては、OpenGraph も BaaS も、茫洋として、掴みどころがなかったのですが、この記事は、双方に対する理解を、一度に進めてくれる、とても素晴らしい内容だと思います。 嬉しいです！ 
ーーーーー
＜関連＞
Facebook – Open Graph Beta の概説
Facebook が Open Graph アクションをアップデート
モバイル BaaS って何だ？ Appcelerator による Cocoafish 買収から探ってみよう
Yahoo の Mojito は、Mobile デバイスに対応する OSS Dev プラットフォームなのだ
AppMobi の狙いは、Mobile + OSS + HTML5 の惑星大直列なのだ！
Bloomberg 金融アップストアがオープン ： Apple みたいに 30% をイタダキ！
Bloomberg launches financial app store, offers Angry Bonds
http://wp.me/pwo1E-5b4
By Jeff John Roberts – Nov 13, 2012
http://paidcontent.org/2012/11/13/bloomberg-launches-financial-app-store-offers-angry-bonds/
Financial giant Bloomberg has opened an app store in which it will take 30 percent of revenue. The move is significant because it is the first time the tightly-controlled company is opening up its rich pools of data to outside developers.
金融大手 Bloomberg がアップストアをオープンし、そこから 30% の収入を得ていくという。 このトレンドが重要なのは、タイトに制御された企業が外部のデベロッパーに対して、リッチなデータ･プールを開放するという点で、初めての試みだからである。
It’s not exactly Angry Birds or Call of Duty but, well, this is Wall Street. Financial giant Bloomberg this morning launched an app store with offerings like Trade Navigator, Market Grader and, yes, Angry Bonds.
これは Angry Birds や Call of Duty ではないが、まあ、Wall Street である。今朝のことだが、 金融大手 Bloomberg がアップストアをローンチした。 そして、Trade Navigator や Market Grader、そして、なんと Angry Bonds などを販売していくという。
Alas, Angry Bonds is not about disgruntled 007 agents. Instead, it is one of more than 45 apps in the Bloomberg App Portal that perform tasks like risk analysis and client management. The company didn’t disclose specific prices for the apps, which are free to preview, but it’s a safe bet they cost more than 99 cents. The Financial Times reports that Bloomberg will, like Apple, take a 30 percent cut.
なんというか、Angry Bonds は、しかめっ面の 007 のエージェントに文句を言うものではない。 それに代えて、この Bloomberg App Portal にストアされた 45本以上のアプリには、リスク分析とクライアント管理といった、仕事をこなすものが含まれる。 同社は無料でプレビューできるアプリ群について、それぞれの価格を明らかにしていないが、99セント以上の費用が発生すると思ったほうがよいだろう。 Financial Times のレポートによると、Bloomberg は Apple のように、30% を取り分にするようだ。
The launch is significant because Bloomberg has now opened up its vast pool of financial data to outside developers who can then craft new products to help traders and analysts. Until now, the company founded by New York City mayor Mike Bloomberg has closely guarded its proprietary system, which costs around $20,000 a year for a license.
今回のローンチが重要なのは、Bloomberg の巨大な金融データ･プールを、外部のデベロッパーにオープンされたからである。そして、デベロッパーたちは、トレーダとアナリストを支援するために、新しいプロダクトを仕上げていくだろう。 New York City 市長でもある Mike Bloomberg により設立された同社は、そのプロプライエタリ･システムをしっかりとガードし、これまでは、年間で約 $20,000 のライセンス費用を請求してきた。
The app store comes at a time that Bloomberg is adopting its famous financial terminal for the mobile environment through tools like Bloomberg Anywhere and selling a new edition of its core product, Bloomberg Next. The company and its main competitor Thomson Reuters were hard hit by the economic meltdown in 2009 that decimated many of their financial clients.
このアップストアは、モバイル環境における同社の金融ターミナルが、Bloomberg Anywhere などのツールを介して適用される、タイミングに合わせて登場する。そして、Bloomberg Next などのコア･プロダクトの、新しいバージョンが販売されていく。 同社および、その最大の競合相手である Thomson Reuters は、2009年の 経済崩壊により大きな打撃を被り、数多くの金融クライアントを失っている。
Here are some more screenshots of the apps (don’t have too much fun…)
以下に、金融アプリのスクリーンショットを掲載する（それほど面白いものではないね・・・）
↓ クリックで拡大 ↓
 |
 |
ーーーーー
この Bloomberg のアップストアは面白そうですね。 いま訳している、Kinvey の興味深い記事では、『 何らかの方法で、それらのアプリケーションは、いかなるソースからであっても、データを取り込まなければならない。そこに含まれるものには、もちろん、サードパーティーからのデータソースがある。そして、さらに、企業の IT 部門が、膨大なコストと時間を費やして、維持・保持してきた密結合データベース･システムでさえある 』というふうに、BaaS について説明されています。文中にもあるように、ココが、重要なポイントなのだと思います。 
ーーーーー
＜関連＞
iOS／Android デバイスでカード決済 ： Bank of America
NY の地下鉄では、スマホ･チケットの試みが始まるらしい
Apigee は、テレコムのための SDN を考える
エンタープライズ･ソーシャルって、どう捉えたら良いの？
単純／安価／高速 ： .NET から Node + Heroku に乗り換えた Playtomic
iOS／Android デバイスでカード決済 ： Bank of America
Bank of America releases a mobile payment service to compete with Square
http://wp.me/pwo1E-5aV
November 13, 2012 – Tom Cheredar
http://venturebeat.com/2012/11/13/bank-of-america-releases-a-mobile-payment-service-to-compete-with-square/
The latest company to plunge into the world of mobile payment services is Bank of America, which announced it new Mobile Pay on Demand dongle today.
モバイル･ペイメント･サービスの世界に、新規参入者として飛び込んできたのは Bank of America であり、今日のアナウンスメントで、Mobile Pay on Demandドングルを披露した。
The new dongle allows people to process credit and debit card payments from an iPhone, iPad, or Android device. Money from each transaction goes into a Bank of America account, and there’s a 2.7 percent fee for each swiped transaction (3.5 percent for non-swiped/keyed in transactions).
この新しいドングルにより、iPhone／iPad／Android といったデバイス上で、クレジットとデビットカードによる支払いが処理させる。 それぞれのトランザクションからの送金は、Bank of America のアカウントに集められるが、カードを利用した場合の、トランザクションごとの手数料は 2.7% となる（キーインの場合は 3.5%）。
The dongle/service is targeted at small business owners who are likely to find it attractive due to its convenience and the fact that it charges a lower transaction fee than most credit card services. And that fee is also slightly lower than Square’s, which is 2.75 percent.
このドングル／サービスは、簡単な手続きに利便性を見出し、また、大半のカード･サービスより少ない手数料を望む、中小企業のオーナーをターゲットにしている。 そして、その手数料は、Square の 2.75% よりも、少しだけ低く抑えられている。
Bank of America’s Mobile Pay service is hardly the only mobile transaction service available these days. In addition to industry leader Square, Bank of America Mobile Pay will face competition from Intuit, PayPal Here, LevelUp, and a new service from Groupon.
Bank of America の Mobile Pay サービスは、現時点で利用できる唯一のモバイル･トランザクション･サービスというわけではない。 業界のリーダーである Square のほかに、Intuit／PayPal Here／LevelUp／Groupon（参入予定）などのコンペティタと、Bank of America Mobile Pay は戦っていくことになる。
ーーーーー
今朝は、どのメディアを見ても、Sinofsky の話題であふれていて、あまり爽やかな目覚めではありませんでしたが、Mobile BaaS の到来を実感させる面白いトピックが 2つほど見つかり、なかなかゴキゲンな Agile_Cat です 
Bank of America のような金融機関が、簡単にモバイル･ペイメントに参入できるのも、Mobile BaaS のエコシステムがあってこそと思うのです。 このあと、Bloomberg の金融 App Store の話題も、続けてポストしていきます。
ーーーーー
＜関連＞
モバイル BaaS って何だ？ Appcelerator による Cocoafish 買収から探ってみよう
NASDAQ の FinQloud は、AWS ベースの金融サービス･プラットフォームだ
Amazon AWS 上の Data as a Service を、粛々と進めてきた NASDAQ の戦略
NYSE と EMC と VMware が、ウォール･ストリートに浮かべるクラウドとは？
Amazon AWS が Equinix に、ハイブリッド用のダイレクト接続を提供
アメリカの キャリア･エクスチェンジについて DCN が概説する
単純／安価／高速 ： .NET から Node + Heroku に乗り換えた Playtomic
Simpler, Cheaper, Faster: Playtomic’s Move from .NET to Node and Heroku
http://wp.me/pwo1E-54r
Monday, October 15, 2012 at 9:15AM
http://highscalability.com/blog/2012/10/15/simpler-cheaper-faster-playtomics-move-from-net-to-node-and.html
This is a guest post by Ben Lowry, CEO of Playtomic. Playtomic is a game analytics service implemented in about 8000 mobile, web and downloadable games played by approximately 20 million people daily. Here’s a good summary quote by Ben Lowry on Hacker News:
Playtomic が提供する分析サービスは、2000万の人々が毎日のようにプレーする、モバイル／Web／ダウンロードを前提とした、約 8000 種類のゲームにインストールされたものである。以下は、Ben Lowry が Hacker News で発言した、きわめて明快な概要である：
Just over 20,000,000 people hit my API yesterday 700,749,252 times, playing the ~8,000 games my analytics platform is integrated in for a bit under 600 years in total play time. That’s just yesterday. There are lots of different bottlenecks waiting for people operating at scale. Heroku and NodeJS, for my use case, eventually alleviated a whole bunch of them very cheaply.
20,000,000人以上の人々が、昨日は 700,749,252回も、私の API にアクセスした。その解析プラットフォーム上の、8000弱のゲームをプレーすることは、600年分の時間を費やすに等しくなる。 ただし、それは、昨日の利用だけに過ぎない。 大規模スケールに取り組む人々にとって、それぞれのボトルネックが、たくさんの位置に存在している。 私のユース･ケースにおいては、最終的に Heroku と NodeJS が、きわめて低コストで、その多くを緩和している。
Playtomic began with an almost exclusively Microsoft.NET and Windows architecture which held up for 3 years before being replaced with a complete rewrite using NodeJS. During its lifetime the entire platform grew from shared space on a single server to a full dedicated, then spread to second dedicated, then the API server was offloaded to a VPS provider and 4 – 6 fairly large VPSs. Eventually the API server settled on 8 dedicated servers at Hivelocity, each a quad core with hyperthreading + 8gb of ram + dual 500gb disks running 3 or 4 instances of the API stack.
NodeJS を用いて完全に書き換えられる以前の Playtomic は、Microsoft の .NET と Windows のアーキテクチャを、ほとんど排他的な形式で、3年も採用してきた。この プラットフォーム全体は、専用のシングル･サーバー上の共有スペースから、専用の分散サーバーへと成長してきた。 そして、さらに、API サーバーは、4～6 社の大手 VPS 上へと、均等にオフロードされた。 最終的に、この API サーバーは、Hivelocity が提供する 8台の専用サーバー上に落ち着いたが。 しかし、その API スタックでは、Quad-Core のハイパー・スレッディング ＋ 8GB の RAM ＋ 二重化された 500 GB により、3 ～ 4 個のインスタンスを走らせるという状況であった。
These servers routinely serviced 30,000 to 60,000 concurrent game players and received up to 1500 requests per second, with load balancing done via DNS round robin.
これらのサーバーは、DNS ラウンド･ロビンを介したロードバランシングを用いて、30,000 ～ 60,000人のゲームプレイヤーに対して、コンカレントなサービスをルーチンとして提供し、また、1秒あたり 1500 のリクエストを受けている。
In July the entire fleet of servers was replaced with a NodeJS rewrite hosted at Heroku for a significant saving.
そして、この 7月には、全体的なサーバーの構成を、Heroku 上にホストされる NodeJS で、書き換え、また、リプレイスすることになった。 そして、大幅なコストの削減が実現されたのだ。
Scaling Playtomic with NodeJS
There were two parts to the migration:
Dedicated to PaaS: Advantages include price, convenience, leveraging their load balancing and reducing overall complexity. Disadvantages include no New Relic for NodeJS, very inelegant crashes, and a generally immature platform.
Dedicated to PaaS: アドバンテージとしては、価格／利便性／ロードバランシングの活用／全体的な複雑さの低減などが挙げられる。 ディス･アドバンテージとしては、NodeJS 用の New Relic の不在／とてもエレガントとは言えないクラッシュ／全般的に見て未熟なプラットフォームなどが挙げられる。
.NET to NodeJS: Switching architecture from ASP.NET / C# with local MongoDB instances and a service preprocessing event data locally and sending it to centralized server to be completed; to NodeJS on Heroku + Redis and preprocessing on SoftLayer (see Catalyst program).
.NET to NodeJS: ASP.NET / C# からローカルな MongoDB インスタンスへの、アーキテクチャの置き換え。 そして、ローカルでのイベント･データの処理と、処理を完了されるための、センタライズされたサーバーへの送信。具体的には、NodeJS on Heroku ＋ Redis と、SoftLayer 上でのプリ･プロセシング（ Catalyst プログラムを参照）。
ーーーーー
.NET と NodeJS の比較ということですが、この Playtomic のアプリケーション･モデルとビジネス･モデルにおいては、NodeJS の方が適しているという事なのでしょうね。 そして、このようなアプリケーション･モデルが、ものすごい勢いで増えてきているのだと思います。さまざまなサービスが、API という形式で提供され、さらに、それらを分析するためのプラットフォームが加わっていくわけです。こういう記事を読むと、理想的なコンピューティングが具体化しているのだと感じられますね。 
ーーーーー
＜関連＞
NY の地下鉄では、スマホ･チケットの試みが始まるらしい
エンタープライズ･ソーシャルって、どう捉えたら良いの？
Apigee は、テレコムのための SDN を考える
分散オブジェクト･ストアの Basho が CloudStack に参加
次世代ビジネスとして、Data as a Platform に注目する _1
エンタープライズ･ソーシャルって、どう捉えたら良いの？
What’s Coming Up in Social Business, CoIT, Open APIs, and More
http://wp.me/pwo1E-52S
January 11, 2012
http://dionhinchcliffe.com/2012/01/11/whats-coming-up-in-social-business-coit-open-apis-and-more/
ちょっと古いブログ･ポストですが、調べ物の最中に見つけた良記事です・・・ 
ーーーーー
While 2011 was a busy year, I’m expecting 2012 to be a breakout year for a number of key subject areas that I work with closely. The run up of social business over the last five years has been phenomenal but there’s a general sense now that it’s about to go truly mainstream. That’s not to say it hasn’t already happened nearly everywhere already, except for a significant part of the business word. This now appears to be changing as the latest adoption data shows that with few people left on the consumer side, the growth of enterprise social media is about to start closing the steady gap that it’s held behind the world of social media over the years.
2011年は忙しい年であったが、2012年について予測すれば、私が密に取り組んでいる重要なエリアにとって、ブレイクアウトの年になるはずだ。これまでの 5年にわたるソーシャル･ビジネスの急成長は、まさに目を見張るものであったが、それが本物の主流になるにつれて、いまでは誰もが、普通の感覚で捉えられるようになってきた。 そして、すでに、あらゆる局面でソーシャル･ビジネスが生じていることを、誰もが否定できない状況になっている。 ただし、ビジネスにおけるコアとなる分野は、最後に残されたデータの適用領域でもあり、これから変化を遂げていくと思われる。コンシューマ･サイドにおいて、ソーシャル･メディアの流れに取り残されている人々は稀であるが、この数年の間に、エンタープライス･サイドとの間で生じたギャップを、エンタープライズ･ソーシャル･メディアの成長が、着実に埋め始めている。
Perhaps more than anything else these days I’m getting this increasingly urgent question at an senior executive level: What specifically are the business benefits of social media? While I’ve covered that in detail many times, this new-found interest on exact outcomes shows that the business leaders are increasingly feeling compelled to wrap their mind around the inevitable changes facing their organization. To help with this I’ve recently distilled it into the chart you see below, based on the McKinsey data they collect every year from large organizations. These double digits performance improvements then, embody the social business imperative:
このところの私の緊急課題は、おそらく、他の何ものにも増して、「ソーシャル･メディアにおけるビジネス上のメリットは、具体的にいって何処にあるのか？」という、経営の責任者が考えるべき問となっている。 それについて、私は何度も詳細まで追いかけてみたが、正直なところ、自身の組織が直面する避けることのできない変化に対して、ビジネス･リーダーたちが自身の考えを包み隠すよう、強制されていると感じていることが、新たに見つかった論点となる。つい先日のことだが、この結果について、以下のようなチャートを用いて整理してみた。 それは、McKinsey が毎年、大手企業から集めてくるデータに基づいたものとなる。
↓ クリックで拡大 ↓
Then there is the whole consumerization story that’s unfolding at the moment. This has been a seismic event for many organizations as smart mobile devices, enterprise app stores, and software-as-a-service from the Web all combine to make adoption of the latest apps and IT solutions is just a mouse click or tap on a touch screen. At the same time, there is a growing sense that the classic line dividing IT and business is blurring, just like there is so much blur in many key business boundaries today. The lesson: Everyone can and should be be involved with making these changes happen constructively and effectively for their organization, whether it’s social media, information technology adoption, transformation to new digital business models, etc. Many of you know tat I’ve started to call this confluence of IT trends “CoIT” and it’s something I’ll be researching and speaking about extensively this year because I believe IT is about to change — no, is changing — in a substantial and irreversible way. The changes themselves are largely good but it will certainly leave some ‘creative destruction’ behind, to use the popular euphemism for what happens when innovation cuts through an organization in an unplanned way.
続いて、現時点において、コンシュマライゼーションのストーリーが、全体的に広まってきている。 それは、数多くの組織にとって、地震のような事象である。つまり、スマートなモバイル･デバイスと、エンタープライズ･アップストア、そして Web から得られる SaaS を結び付けることで、 最新のアプリケーションが適用され、また、IT ソリューションを単なるマウス･クリックとスクリーン･タップに置き換えてしまうのだ。 それと同時に、IT とビジネスを切り分けてきた従来からの境界性も、曖昧になってきたという感覚がある。 この現象は、いまの企業を分類する境界線が、ますます曖昧になっていることに似ている。レッスン：それがソーシャル･メディアや、IT の適用、そして新しいデジタル･ビジネス･モデルへの移行であろうがなかろうが、組織を建設的かつ効率的に変化させる動きには、誰もが巻き込まれるはずである。こうした IT トレンドの集合を、私が「CoIT」と呼び始めたことを多くの人々が知っている。それは、今年の私が、広範囲にわたって調べあげ、また、説明してきた「何か」である。 なぜなら、まさに IT は、その根本から、元に戻れない方向へ変化しようとしていると（まだ変化しているわけではない）、私は信じるからである。この変化は、基本的に歓迎すべきものであるが、いくつかの「創造的な破壊」が、負の部分として残されるだろう。一般的で婉曲的に表現するなら、コントロールできない方式で、イノベーションが組織を横断していくときに起こる現象となる。そして、このようなケタ違いのパフォーマンス改善がなされるとき、ソーシャル･ビジネスの必然性が具体化していく：
Now that the basic platforms for social business have matured to the point that they’re ready for most organizations — and by this I mean both internally and externally for most common business functions like operations, CRM, marketing, product development, etc. — we’re moving into more sophisticated and higher-order capabilities. Capabilities like social business intelligence, enabled by the rise of both older and radically advanced new technologies now known as Big Data, are making it possible for us to actually make sense of the huge knowledge flows moving around us. I’ll also be closely following analytics, machine learning, natural language processing, metrics, and much more, both in terms of technologies as well as how to best embody them in operational business processes.
いまや、ソーシャル･ビジネスの基本的なプラットフォームは、大半の組織で運用できるレベルまで準備が整っており（最も一般的なビジネス機能である、オペレーション／CRM／マーケティング／製品開発などを、組織の内外で利用できる）、さらに洗練された高次元の能力をもたらしている。いまや Big Data と呼ばれる、古くて新しいテクノロジーの進化により、ソーシャル･ビジネス･インテリジェンスのような機能が実現されている。それにより、私たちの現実世界を取り囲む巨大な知識流れを、意味のあるものに置き換えていく。 さらに、私は、分析能力や、機械学習、自然言語処理、数値指標などについて、それらをテクノロジーの観点からだけではなく、ビジネス･プロセスに効果的に取り入れる方式も追いかけていく。
2012 is also shaping up to be the year of open supply chains, or as people on the Web call them, open APIs. The number of products and services that are now open to be remixed into other companies’ offerings has exploded in the last year. See this terrific visualization of API growth on ProgrammableWeb to get a sense that something big is indeed happening here. I’m now seeing sustained interest beyond the Internet community by traditional companies that are starting to see how much value they missed by looking at their businesses through like silos, disconnected from the digital rivers of commerce, ideas, engagement, and so on. Open APIs are now officially on the radar of big company CIOs. They are seeing how it will be a significant competitive advantage to offer a compelling API in an industry that does not have strong uptake yet. 2013/14 will start looking bleak for those firms that don’t yet have them, or at least have developed competency in both the technology and business models. In the meantime, the tools, techniques, and business models for making APIs work for a wide range of industry has greatly evolved and will be important to watch.
2012年はオープンなサプライ･チェーンの年であり、また、人々が Open API と呼ぶもので、かたちが構成されていく年でもある。 昨年（2011）は、オープンなプロダクツとサービスが、他の企業が提供するサービスに取り込まれ、ミックスされるという流れが、飛躍的に増大した年でもある。 API の成長を表現するために ProgrammableWeb から提供される、この素晴らしいビジュアライゼーションを見て欲しい。 そして、大きなトレンドが、ここで実際に生じていることを感じで欲しい。 いま、私は、インターネット･コミュニティの向こう側で、従来からの企業が持ち続ける興味に注目している。 逆説的に言えば、コマース／アイデア／エンゲージメントといった、デジタル･リバーの流れから切り離された状況において、それらの企業が失ってきたメリットを検証し始めたことになる。 いまや Open API は、大企業の CIO たちがオフィシャルに検知すべきものとなっている。 彼らが注目しているものは、依然として大きな変化に曝されていない産業において、説得力のある API を提供することが、どれくらいの競争力を有するのかという点である。 それに取り組んでいない企業にとって、2013～2014 年は、見通しの立たない期間になるだろう。 したがって、少なくとも、テクノロジーとビジネス･モデルの両面において、その期間に競争力を確保していく必要がある。 つまり、2013～2014 年には、広範囲におよぶ産業で API を機能させていく、ツール／テクノロジー／ビジネス･モデルが大幅に進化し、また、そこに注目していくことが重要になっていく。
There’s plenty more I’ll be tracking this year; there’s really no shortage of topics that will be vital for all of us to watch including augmented reality, new mobile technologies like NFC, the rise of HTML5 and its coming battle with iOS and Android, gamification of just about everything, location-based social networking, enterprise OpenSocial, and much more.
今年（2012）、トラッキングしていくべき、数多くのテーマがある。 実際に、私たちが注目すべき事柄において、トピックが不足するということは、有り得ないだろう。そこには、NFC や HTML5 といった新しいモバイル･テクノロジーや、iOS と Android の戦い、すべてを覆うゲーム感覚の UI、ロケーション･ベースのソーシャル･ネットワーク、そして、エンタープライズ OpenSocial といった、膨大なリアリティが含まれている。
ーーーーー
Cloud & Post-PC 時代のプロダクティビティ･ツールって、どう考えたら良いの？ ・・・ という、良記事だと思います。 もちろん、ワープロや表計算が消えてしまうという話ではありませんが、ナレッジ･ワーキングを突き詰めていけば、さらなるゴールが見えてくると、この記事は語っているように思えます。 Agile_Cat の仕事仲間には、BYOD を実験しているような立場の方が多いので、Facebook や Evernote で情報やナレッジを共有していくケースが多々あります。 たとえば、このドキュメントも Evernote で共有していますし、PDF が必要であれば MS Word をフォーマッターとして利用し、ブログにポストするなら Live Writer を使うといった具合です。 つまり、これまでのプロダクティビティ･ツールとは異なる次元に、別のプロダクティビティ･ツールのレイヤが構築されようとしているのです。 そして、それが、エンタープライズ･ソーシャルであり、また Co-IT 環境なのだと思えるのです。
ーーーーー
＜関連＞
クラウドは未知の世界：そこを生き抜く企業のための５つの鉄則
BYOD 十策 ： モバイル･エンタープライズのために
クラウドの成長により、すべてのベンダーは崩壊し、また、再生していく
激動の Post-PC シフトを、21枚のチャートで確認
赤いオペラと 緑のエバノ ： まとめページ
Apigee は、テレコムのための SDN を考える
Apigee launches product as telcos prep software defined networks
http://wp.me/pwo1E-4Wu
By Stacey Higginbotham Sep 25, 2012 – 6:00AM PT
http://gigaom.com/cloud/apigee-launches-product-as-telcos-prep-software-defined-networks/
Many interested in deploying software defined networks are eager for the agility and programmability they can provide. But the fear of breaking their network means IT is leery of deploying SDNs. Apigee has updated its API management products to work on SDNs to alleviate those fears.
SDN（ software defined networks ）のディプロイに興味を持つ人々の多くが、それを実現するためのアジリティとプログラミング能力に対して、熱心に取り組んでいる。 しかし、ネットワークを破壊してしまうことへの恐れが、IT 部門による SDN のディプロイを慎重にさせる。 こうした恐れを軽減するために Apigee は、各種の SDN 上で機能する API マネージメント･プロダクツをアップデートした。
ーーーーー
Apigee, a company that helps customers manage application programming interfaces that developers use to build services, is introducing a product specifically for software-defined networks that will help its telco customers manage their APIs based on the state of the network and policies already in place for specific users.
Apigee は、デベロッパーがサービス構築に使用する API を、管理する立場にある顧客を支援しているわけだが、 今回は SDN に特化したプロダクトを、テレコム･カスタマに対して提供し始めたことになる。それにより、特定ユーザーに提供されているネットワークとポリシーのステートに基づく API を、それらの顧客が管理していくことになる。
Apigee, which counts customers such as Walgreens, Telefonica and AT&T, is adding software that can be deployed on controllers such as those offered by Nicira, BigSwitch, IBM and others as well as a platform that will help apply analytics to the network to determine when to take specific actions based on polices or the network’s health.
Apigee には、Walgreens／Telefonica／AT&T といった顧客がいるが、今回は Nicira／BigSwitch／IBM が提供する SDN コントローラー上にディプロイが可能なソフトウェアを、そのラインナップに加えたことになる。そして、このソフトウェアが提供するプラットフォームは、ポリシーやネットワークの健康状態に基づく特定のアクションが引き起こされたときに、そのネットワークを解析するための支援も可能にする。
Software defined networks, where the intelligence needed to operate and manage the flow of traffic is no longer housed in expensive gear but in commodity servers running software, are of growing interest to both telcos and data center operators. The benefit of such networks is that the gear is less pricey, but also that such networks are programmable and agile. On the telco side, the hope is that SDNs can help reduce the complexity of moving data across networks and help carriers and ISPs lower their costs.
ネットワークのトラフィックやフローを管理するために必要とされる SDN は、もはや高価なアプライアンスに収められるものではない。そして、テレコムとデータセンターで増大している関心事を、ソフトウェアを実行するコモディティ･サーバー上からサポートしていく。 こうしたネットワークは、装置に対する投資を抑えるだけではなく、プログラミングへの対応とアジリティというメリットも提供する。 テレコム側からは、ネットワークを横断するデータ転送の複雑さを低減し、キャリアと ISP におけるコストを削減するという、SDN への期待がある。
Sam Ramji, VP of strategy at Apigee, says telcos are trying to deploy SDNs to help monitor certain types of traffic across their network and enforce policies imposed by the subscriber’s billing plan in real time. It’s one of many possible use cases for SDNs, and Apigee hopes that by adding the SDN functionality it can become one of several firms that will help make the holy grail of network-aware applications possible.
Apigee の VP of Strategy である Sam Ramji が言うには、ネットワーク全体を横断する特定トラフィック･タイプのモニタリングを支援するために、また、サブスクライバーの支払いプランに応じたポリシー設定をリアルタイムで実施していくために、テレコムは SDN のディプロイを試みているようだ。それは、SDN におけるユース･ケースの 1つである。 そして Apigee は、その SDN の機能を加えることで、ネットワーク認識型アプリケーションという聖杯を、テレコムも手にすることになると期待している。
Subscriber Content
- Infrastructure Q3: OpenStack and flash step into the spotlight
- The future of mobile: a segment analysis by GigaOM Pro
- Infrastructure Q2: Big data and PaaS gain more momentum
ーーーーー
以前に、『 2011 年の クラウド API について、5 つのポイントを予想する 』という抄訳で Apigee について触れたときには、「エンタープライズ API マネージメント･テクノロジーおよび、無料のデベロッパー･ツールを提供する Apigee では、API マーケットびが成長だけではなく、その多角化が 2010年の特徴として確認された」と、いうふうに紹介されていました。 その時から、2年近くが経ちましたが、その API 管理と SDN が結びついたわけです。 SDN に関する、とても具体的なユースケースでもあり、興味シンシンですね！ 
ーーーーー
＜関連＞
NY の地下鉄では、スマホ･チケットの試みが始まるらしい
次世代ビジネスとして、Data as a Platform に注目する _1
Web と jQuery のラブラブな関係を、いくつかのデータで証明する
ヨーダのように語ってくれる Yoda-Speak API とは？
Java と Android をめぐる Oracle と Google の争い ： API の適正な用法とは？
leave a comment