Agile Cat — in the cloud

Microsoft Graph とは、人間に寄り添ってくれる、とても優しいテクノロジーのことなのだ!

Posted in .Selected, Microsoft, Open Graph, Strategy by agilecat.cloud on February 2, 2016
Microsoft Graph promises open developer access to Office 365 data
Mikey Campbell – November 18, 2015
http://appleinsider.com/articles/15/11/18/microsoft-graph-promises-open-developer-access-to-office-365-data
 
Apple Insider
 
Microsoft at its Connect (); conference on Wednesday flipped the switch on Microsoft Graph, née Office 365 Unified API, a set of APIs that let developers integrate, manage and tap into vast expanses of data stored in the Office 365 cloud.
 
Microsoft は 11月18日に開催された Connect () カンファレンスにおいて、これまで Office 365 Unified API と読んでいたものを、Microsoft Graph と改名した。この API セットは、Office 365 クラウドにストアされたデータに関する、デベロッパーによる統合/管理/関連付けを、促進するものである。
 
Network TheoryClick to Youtube >>>
 
For Microsoft it’s all about unification. In the hands of developers, the graph’s unified API promises not just an endpoint for building in Office 365 and other software integrations, but a starting point for new intelligent interactions.
 
それは、Microsoft にとって、すべての統合を司るものとなる。つまり、この Graph の Unified API は、デベロッパーの手による、Office 365 を含むソフトウェア統合の構築を、推進するためのエンド・ポイントを約束するだけではなく、最新の知的インタラクションのためのスタート・ポイントにもなっていく。
 
According to Microsoft GM of Office Extensibility Rob Lefferts, the graph represents a gateway to intelligence and insight capable of harnessing user data to solve everyday problems. From common queries like “what files do I need for this meeting,” to more complex requests dealing with user trends and customized insights, developers can tailor their app or service as they see fit without jumping through hoops.
 
Microsoft の GM of Office Extensibility である Rob Lefferts によると、この Graph が表現するゲートウェイは、ユーザー・データを活用することで日常の問題を解決するための、知能と洞察という側面を提供するものとなる。たとえば、「このミーティングで必要なファイルは?」といった一般的なクエリーから、「ユーザーの動向」や「カスタムな洞察」を取り扱うような複雑なクエリーにいたるまで、デベロッパーたちのアプリやサービスは対応が可能になるが、そのための、難しい処理を要求されることはない。
 
“It would be our reimagining of what it means to be productive in a modern world,” Lefferts says, referring to solutions mobile, cross-platform and cloud-integrated solutions. “The way that people work has changed, it’s much more connected, people are more collaborative.”
 
Lefferts は、「最先端の世界で生産的であることは、何を意味するのかという、私たちの観点を再構成するものになるだろう」と発言している。つまり、モバイル/クロス・プラットフォーム/クラウド・インテグレーションといった、ソリューションを視野に入れたものになるのだろう。そして、彼は、「人々が働くときの、発想が変化している。 具体的に言うと、これまで以上に結びつきが重視され、より協調的になってきている」と続けている。
 
Graph-l
 
Microsoft’s data pool is deep. Lefferts says some 500 petabytes of information already live in Microsoft’s cloud, with Office 365 users generating 4 trillion emails and creating 850 million meetings every month. The number of data points is bound to increase once currently siloed Office 365 information is offloaded to the graph. The company is even looking into Skype integration.
 
Microsoft のデータ・プールは、かなりの深層にまで展開されている。Lefferts が言うには、500 Peta Byte 程度の情報が、すでに Microsoft クラウドに蓄積されているが、Office365 ユーザーが生成する4兆の電子メールと、8.5億のミーティング・スケジュールが、毎月のように、そこに追加されていくようだ。それらのデータ・ポイントの数は、サイロ化される Office 365 関連情報に応じて、一時的に増大していくが、その後に Graph へとオフロードされる。
 
Access to rich data is the bedrock of intelligent analytics, where another prong of Microsoft Graph comes in. The Redmond software giant uses advanced machine learning algorithms fed by data and user behavior to dish out query responses in a format familiar to developers. Secure access to client activities — documents, contacts, meetings, etc. — is authorized through a single token, meaning apps don’t have to fetch multiple authorizations for different services.
 
リッチ・データへのアクセスは、インテリジェントな分析の基盤であり、そこに Microsoft Graph が絡んでくる。この、Redmond のソフトウェア・ジャイアントは、デベロッパーたちが慣れ親しんでいる形式でクエリー・レスポンスを配信するために、データとユーザーの動きを機械学習する、高度なアルゴリズムを用いている。ドキュメント/コンタクト/ミーティングといった、クライアントのアクティビティに対して安全にアクセスするために、シングル・トークンを介した許可が用いられる。つまり、それぞれのアプリが複数の認証を取得し、個々のサービスに接続するという必要性がなくなるのだ。
Graph-2-l
 
Lefferts stressed the idea of an open graph, something easily accessible by coders of any ilk. To that end, Microsoft built out client libraries and SDKs for iOS, Android and .Net for the graph’s launch, with work on other platforms like Node.js, Python, Java, Ruby currently underway.
 
Lefferts は、イーブンな関係にあるプログラマー同士が、相互にアクセス可能な、Open Graph という発想を強調している。そのために Microsoft は、この Graph の立ちあげに際して、クライアント・ライブラリを構築し、また、iOS/Android/.NET のための SDK を構築する。そして、さらに、Node.js/Python/Java/Ruby といったプラットフォームに関しても、すでに作業に取り掛かっている。
 
“We’ll handle the authentication, we’ll handle the common queries, we know how to interpret the responses,” he says. “The real pitch there is all about making sure that developers can start coding in five minutes.”
 
Lefferts は、「認証の処理方式と、コモン・クエリーに取り組んでいく。 私たちは、それらのレスポンスを、どのように解釈すべきかを知っている。ほんとうの意味での競争は、すべてのデベロッパーが、5分以内でコーディングに取り掛かれる状況を、約束できるか否かにかかっている」と述べている。
 
Prior to the graph’s public release, Microsoft collaborated with select service partners like SkyHigh Networks, Uber, Smartsheet and Zendesk to refine its backend implementation, an exercise that resulted in interesting integrations.
 
Microsoft は、この Graph のパブリック・リリースに先立ち、SkyHigh Networks/Uber/Smartsheet/Zendesk といった選ばれたパートナーとのコラボレーションを推進し、洗練されたインテグレーションを実現するために、そのバックエンドの実装を進化させてきた。
 
For example, in a quest to make meetings more productive, Do.com pulled data from Outlook and Exchange, documents in OneDrive and other assets directly from the graph to provide deep insights into meeting planning, agenda strategy, post-meeting follow-ups and more. Everything was integrated into Outlook, ensuring users had a seamless data-driven experience.
 
Do.com のケースで言うと、より生産的なミーティングを実現するために、Outlook と Exchange からのデータ、および、OneDrive 内のドキュメント、Graph などからの情報を引き出し、ミーティングの計画/アジェンダの戦略/ミーティング後のフォローアップなどに、より深い洞察を提供するようになった。そして、ユーザーは、すべてが Outlook に統合された、シームレスなデータ駆動型のエクスペリエンスを得るようになった。
 
The main thrust, Lefferts says, is to get data out of silos and into the hands of developers, who can “offer more in terms of being seamless, being smart and being effective.”
 
Lefferts が言うには、主な推進力は、データをサイロから取り出し、デベロッパーに手渡すことに集約される。 そうすれば、彼らは、「よりシームレスで、よりスマートで、より効果的な観点で、その先の処理を考えてくれる」と述べている。
 
Data privacy is a hot-button topic and Microsoft is making security a high priority with the graph. The system is designed not only to protect raw data from prying eyes, but also any insights Microsoft Graph’s intelligence engine gleans from that data.
 
データに関するプライバシーは、最もホットなトピックであり、この Graph におけるセキュリティは、Microsoftにとって優先度の事項となっている。このシステムは、詮索好きな目から、生データを保護するようにデザインされているが、それらのデータから Microsoft Graph が拾い集める、あらゆる洞察についても、同様の保護機能が提供されている。
 
“It’s built into the business model,” Lefferts says about privacy. “There are parts of Microsoft that are driven by advertising, but Office 365 is very much organization-facing. […] And that means that we have to make sure we’re not misusing the information for anything inappropriate, we’re not sharing information with people who shouldn’t see it, whether that’s outside the organization or other people inside the organization.”
 
Lefferts はプライバシーについて、「それはビジネス・モデルに組み込まれるものだ。Microsoft のビジネスには、広告という側面もあるが、Office 365 が向き合うのは多様な組織である。そして、私たちは、それらの情報を、不適切なかたちで悪用していないことを、あらためて確認する必要がある。その対象が、組織内の人物であっても、組織外の人物であっても、情報を参照してはならない人と、共有することはない」と述べている。
 
Developers interested in taking Microsoft Graph for a test spin can visit graph.microsoft.com for more information.
 
Microsoft Graph を試したいと思うデベロッパーは、graph.microsoft.com を訪れて、詳細な情報を取得して欲しい。
 
ーーーーー
Open Graph言うまでもなく、いまのコンピュータのアーキテクチャは、ファイルとツリーという概念に、大きく依存しています。OS を構成するモジュールも、ミュージック・プレイヤーで楽しむ MP3 も、すべてファイルであり、それらがツリー上の所定の場所に置かれていることで、コンピュータは動くわけです。しかし、このファイルとツリーは、コンピュータにとって便利なものであっても、人間の曖昧な記憶との相性は最悪であり、「アレはどこだ?」とか「コレが見つからない!」とかいう、人類に共通するフラストレーションを、世界中で生み出しているのです。そんなことから、Agile Cat は「ファイルを作らない」をモットーにしていますが、その現実はというと、大量のファイルを生み出してしまう毎日なのです。
 
そこで Microsoft Graph なのですが、文中のチャートが示すように、人間から見て都合の良い場所に、Office 365 のファイルを配置してくれるという、とても優しいテクノロジーだと評価したいです。Microsoft Graph の概要というドキュメントを眺めてみると、自分というノードと他者というノードを、各種の関係というエッジで結びつけるための、Graph API を用いたクエリが示されています。 なんか Facebook に似ている、、、という思う方も多いかと思いますが、あのソーシャルでは、一人一人のユーザーがノードとしてハンドリングされ、「トモダチ」や「イイネ」といったアクションは、そのすべてがエッジとして機能しているはずです。それが、Social Graph から Open Graph へと発展した、Facebook のコア・アーキテクチャなのです。Google も、Knowledge Graph を活用しているはずであり、たとえば検索クエリの意味を判別/読解して、もっとも適切と思われる答えを導き出すというのも、その一例だと思われます。その点では、Google Now も同じなのでしょう。
 
Facebook や Google だけではなく、Microsoft もグラフに取り組んでくれるというのは、とても嬉しいことです。前述の、Microsoft Graph の概要には、「自分の周囲を流れているファイルの取得」というクエリがあるのですが、なんか、イイ感じですよね! 2011年8月にポストした、「クラウドへ行ったら、もう ファイルなんか触らないぞ!」という抄訳は、Agile Cat にとって忘れられないコンテントなのですが、そんな世界が実現しそうでワクワクしています:) それにしても、この記事、なんで Apple Insider なのでしょうかね? _AC Stamp
ーーーーー
<関連>
Facebook の Graph API がアップデートされ、AD API も強化されたようだ!
Facebook が Open Graph の デベロッパー・コレクションを停止した:とても残念!
Google の 音楽ナレッジ・グラフが、YouTube や Google Now と連動し始めた!
Google の検索アルゴリズムが大幅に変更 : そして、誰も気づかなかった
Facebook の Open Graph とは? その歴史から説明しよう
 

Comments Off on Microsoft Graph とは、人間に寄り添ってくれる、とても優しいテクノロジーのことなのだ!

だいじょうぶ マイ HTML5 : その勝利に 94% のデベロッパーが賭けている

Posted in .Selected, Apple, Google, HTML5, Mobile by Agile Cat on November 22, 2012

Mobile app development: 94% of software developers betting on HTML5 winning
http://wp.me/pwo1E-5fc

November 7, 2012 – John Koetsier
http://venturebeat.com/2012/11/07/mobile-app-development-94-of-software-developers-betting-on-html5-winning/

_ VB Dev

photo credit:
codepo8 via photopin cc

A few months ago when Facebook admitted defeat and went native with its iOS app, some thought it was a death-knell for HTML5. But most of the 4,034 developers in a recent survey disagree — vehemently.

数カ月前のことだが、Facebook が失敗を認め、Facebook for iOS アプリをネイティブに切り替えてしまったとき、HTML5 が終わってしまったと、考えた人もいるだろう。 しかし、最近の調査で、4,034 人デベロッパーのうち、大多数が、その説を強く否定している状況が分かった。

In fact, according to a recent survey by mobile app tools vendor Kendo, 94 percent of developers are either using HTML5, or plan to start using it this year, leaving only a minuscule six percent who have no plans to develop with HTML5 before 2013 rolls around in just two short months.

実際のところ、モバイル・アプリ・ツール・ベンダー である Kendo が実施した最新の調査によると、デベロッパーの 94% が HTML5 を使っている、もしくは、今年から使い始めると回答している。 つまり、2013 年より以前の、HTML5 による開発を計画していないデベロッパーは僅か 6% に過ぎず、それ以外の大多数がモチベーションを持ったまま、今年も暮れていくことになる。

クリックで拡大 ⇒

That’s the kind of stat that is sometimes easy to manipulate when there’s a larger percentage in the wishy-washier “planning” segment, but not in this case, with a full 63 percent of developers using HTML5 today.

たくさんの、優柔不断な「プランニング」が存在している場合には、この種の数字は容易に操作できてしまうが、この場合は違う。 なぜなら、全デベロッパーの 63% が、現時点で HTML5 を使っているからだ。

That’s impressive.

HTML5 is an updated version of the old-school hyper-text markup language that makes up much of the web today. It enables developers to build on their existing knowledge of web technologies such as HTML, Javascript, and cascading style sheets to create mobile apps through frameworks such as Adobe’s PhoneGap, rather than having to learn Objective-C to write full-native iPhone/iPad apps, or Java to write Android apps. Probably even more importantly, by using cross-platform technologies like PhoneGap, HTML5 enables developers to write their apps once, and deploy on all major mobile platforms.

HTML5 とは、いまの Web の多く構成する、旧式ハイパー・テキスト・マークアップ言語を、アップデートしたバージョンのことである。 モバイル・アプリに取り組むデベロッパーは、Adobe の PhoneGap などのフレームワークを介して、HTML/Javascript/CSS といった、既存の Web テクノロジー上での開発を実現していく。つまり、フル・ネイティブ iPhone/iPad アプリのための Objective-C や、Android アプリのための Java を、学習する必要がなくなる。 ただし、それよりも重要だと思われるのは、PhoneGap などのクロス・プラットフォーム・テクノロジーにより、HTML5 で書いたアプリケーションであれば、それに手を加えること無く、すべての主要モバイル・プラットフォームにディプロイできる点である。

Given the numbers who are already using HTML5, it’s no shock that 82 percent of developers also say that the technology will be important to their jobs in the next year, and a further 12 percent believe it will be become important within the next two years.

すでに HTML5 を使用している、デベロッパーの数を前提にするなら、このテクノロジーについてディベロッパーの 82% が、彼らの作業において来年は重要な役割を果たす発言していることも、驚くべきことではないだろう。さらに言えば、残りの中の 12% は、これからの 2年間で重要になるとしている。

クリックで拡大 ⇒

Developers’ rationale for using and preferring HTML5 is no shock to anyone who’s ever developed native apps for multiple mobile platforms. 62 percent said that HTML5′s ability to enable cross-platform support was an important factor in choosing the technology, with another third saying that the availability of tools and code libraries make it appealing.

HTML5 を使いたがり、それを好むというデベロッパーたちの論拠は、これまでにマルチ・モバイル・プラットフォームのために、ネイティブ・アプリを開発してきた、あらゆる人々にとっても驚きではない。 このテクノロジーを選択するうえで、クロス・プラットフォームが最も重要な要素だと、62% が発言している。さらに、1/3 のデベロッパーが、ツールとコード・ライブラリの存在が、HTML5 を魅力的にすると発言している。

But the biggest reason developers like HTML5?

Familiarity. Almost three-quarters of developers said that HTML, Javascript, and CSS were familiar languages which enabled easy access to mobile app markets.

そこには、精通しているテクノロジーの組合せがある。 デベロッパーの 約 3/4 が、HTML/Javascript/CSS について、モバイル・アプリ市場へのアクセスを容易にする言語だとしている。

And what about Facebook’s move away from HTML5. Apparently, that hasn’t shaken developers’ belief in the technology — half of them weren’t even aware of the move. Of those who did, however, while 17 percent had less faith in HTML5 after the news, 18 percent had more faith.

そして、HTML5 から離れてしまった Facebook の動向を、どのように捉えれば良いのか。 見たところ、それにより、このテクノロジーに対するデベロッパーたちの信頼が、揺らいでいるということはない。言い換えれば、そのことを知らなかった人々が、半数もいたのだ。 そして、このニュースの前に、HTML5 を信条していた人々が 17% だったのに対して、その後は 18% に上昇したのだ。

That jives with what I’ve heard from people like Andi Gutmans, key developer of the PHP programming language and current CEO of Zend, who is pushing what he calls cloud-connected mobile apps and just released a version of Zend Studio which enables developers to build native mobile apps with familiar web technologies.

それと符合するのは、PHP プログラム言語の主要デベロッパであり、Zend の CEO を務めている Andi Gutmans のような人々から、これまでに聞いていたことである。彼の場合は、クラウド・コネクト・モバイル・アプリという考え方をプッシュしており、また、Zend Studio の新バージョンをリリースしたばかりであるが、そこでは、親しみ慣れた Web テクノロジーにより、デベロッパーはネイティブ・モバイル・アプリを構築していける。

Which frankly, just makes sense if you don’t want to build the same app three times for iOS, Android, and Windows Phone … and if your app is not the most computationally intensive app in the world and absolutely needs to be fully native for performance reasons.

もう少し簡単に言うと、iOS/Android/Windows Phone のために、同じアプリを 3回も構築したくないなら、そこに意味が生じる。そして、あなたのアプリがコンピュート・セントリックの世界にいないのなら、さらに、完全なネイティブがパフォーマンスのために必要というわけでないなら、この考え方が役に立つ。

ーーーーー

image複雑でパフォーマンスの要求される、たとえば Facebook for iOSAndroid といったアプリが、ネイティブへと走るのは分かりますし、それだけのマーケット規模のあるアプリなら、それが最良の選択肢となるのでしょう。 しかし、世の中、そればかりではありません。その意味で、Facebook アプリなどが、早く HTML5 に戻ってくると良いですね。 image

ーーーーー

<関連>

HTML5 は Web 3.0 になるのか?
HTML5 : ネイティブ・アプリを追い越せるのか?
HTML5 の普及には、センタライズされたフリーミアムが不可欠?
HTML5 vs. Flash の現実的な論点は、いったい何処にあるのだろう?
HTML 5 について、パブリッシャーが知っておくべき 5つのポイント

Comments Off on だいじょうぶ マイ HTML5 : その勝利に 94% のデベロッパーが賭けている

Java と Android をめぐる Oracle と Google の争い : API の適正な用法とは?

Posted in .Selected, API, Google, Oracle, Patent by Agile Cat on June 4, 2012

Judge Sides With Google Over Oracle: APIs Were “Fair Use”
http://wp.me/pwo1E-4hd

By
Dan Rowinski / May 31, 2012
http://www.readwriteweb.com/mobile/2012/05/judge-sides-with-google-over-oracle-apis-were-fair-use.php

_ Read Write

Oracle has been dealt a final blow in its court case over the use of Java in Android. U.S. District Judge William Alsup dismissed Oracle’s copyright infringement claim, bringing to an end a dramatic court case that saw Google win in nearly every single important aspect. Oracle has said it will appeal.

Android の Java 利用に関する法廷では、結局のところ Oracle が打撃を受けるという結果に落ち着いた。 U.S. District Judge である William Alsup は、 Oracle からの著作権侵害に関するクレームを却下し、ほとんど全ての重要な局面で、Google 勝利を収めたように見えるというドラマチックな結末で、その法廷の幕を閉じた。しかし、Oracleは控訴するだろうと発言している。

The ruling over whether Google violated the structure, sequence and organization (SSO) of 37 copyrighted APIs fell to the hands of Judge Alsup after the jury came to an impasse during the copyright phase of the trial. The jury was asked to determine several questions concerning whether Google had copied code copyrighted by Oracle after it had acquired the Java programming language when it bought Sun Microsystems in 2010. The jury did not return a complete verdict, ruling that Google had copied the SSO of the 37 APIs but could not decide whether or not that was considered fair use.

この裁判の著作権に関する局面で、陪審員たちが手詰まりとなった後に、著作権が存在する 37 のAPI について、Google が SSO(structure, sequence and organization)に違反しているかという裁定が、Judge である Alsup の手に委ねられた。 陪審員たちが尋ねられたのは、2010年に Oracle が Sun Microsystems し買収し、Java プログラミング言語を取得した後に、その著作権つきのコードを、Google が模倣したかどうかという点である。 陪審員たちは、Google は 37 API の SSO をコピーしているとしたが、用法に関する正当性の有無は判断できないとして、完全な判決を下さなかった。

When viewed as a whole, Oracle lost every significant aspect of the case. The jury found that Google had not infringed on any of Oracle’s patents and was innocent on copyright violations except for nine lines of specific code out of the 15 million lines that constitute the Android mobile operating system. Oracle, which was rumored to be seeking billions of dollars from Google, will now likely only be awarded between $150,000 and $300,000 in statutory copyright damages.

その全体を俯瞰すると、この状況における全ての重要な局面を、Oracle が失っていることが分かる。 そして、陪審員の判断は、Google は Oracle のいずれの特許も侵害せず、また、Android モバイル OS構成する 1500ラインのコードの中の、特定された 9ラインのコード以外に、著作権上の違反がなかったと判定した。 Google から $Billions を取ろうとしていると、噂されていた Oracle であるが、今回に関しては法令に定められる著作権損害の規定により、$150,000 ~ $300,000 を得るだけであろう。

“The court’s decision upholds the principle that open and interoperable computer languages form an essential basis for software development. It’s a good day for collaboration and innovation,” Google said in an emailed statement to the Los Angeles Times.

「オープンでインターオペラブルなコンピュータ言語が、ソフトウェア開発における本質的な基底を形成するという原理を、この法廷は支持した。 それは、コラボレーションとイノベーションにとって、GOOD DAY である」と、Google は Los Angeles Times に対して、電子メールでステートメントを配信した

Oracle’s stance on the ruling is profound. While many have viewed the database company’s efforts as a pure money grab, Oracle is trying to present itself and the Java community as victims of what it implies is unabashed theft by Google. As a programming language, Java was created by Sun Microsystems in the 1990s as a way to “write once, run every” and designed to supersede the closed system created by Microsoft Windows. Oracle alleges that Google has violated the promise of Java and betrayed the entire development ecosystem that relies on the code.

この裁定については、Oracle のスタンスにも深みがある。このデータベース会社金のために頑張っていると、多くの人々がみなしているが、Oracle は自身の立場を明確にし、また、Google の恥知らずな盗みにより、Java コミュニティが犠牲になっていることを示したいだけだ。 プログラム言語としての Java が、「Write Once, Run Every」 というコンセプトのもとに、1990年代に Sun Microsystems により作成されたが、それは、Microsoft Windows のクローズドなシステムに取って代わためにデザインされている。 Oracle が主張したいのは、Google が Java の約束を破り、また、コードに根ざす開発エコシステムのすべてを裏切ったことである。

image“Oracle is committed to the protection of Java as both a valuable development platform and a valuable intellectual property asset. It will vigorously pursue an appeal of this decision in order to maintain that protection and to continue to support the broader Java community of over 9 million developers and countless law abiding enterprises. Google’s implementation of the accused APIs is not a free pass, since a license has always been required for an implementation of the Java Specification,” Oracle stated in am email to technology publication The Verge. “And the court’s reliance on ‘interoperability’ ignores the undisputed fact that Google deliberately eliminated interoperability between Android and all other Java platforms. Google’s implementation intentionally fragmented Java and broke the “write once, run anywhere” promise. This ruling, if permitted to stand, would undermine the protection for innovation and invention in the United States and make it far more difficult to defend intellectual property rights against companies anywhere in the world that simply takes them as their own.”

「Oracle は、貴重な開発プラットフォームとしての Java と、貴重な知的財産権として Java という、2つの側面での保護に忠実である。 今回の件は、900万人以上のデベロッパーと、法を遵守する無数の企業により構成される、広範囲におよぶ Java コミュニティを保護し、また、継続的にサポートしていくための、格好の判断材料を提供するだろう。 Google が責任を問われる API の実装は、無料のパスではない。 なぜなら、Java Specification を実装するには、常にライセンスが必要取れさるからだ。 Oracle は、テクニカル系出版社である The Verge に、メールで立場を伝えてある。 「そして、当法廷のインターオペラビリティへの依存は、Android と他の Java プラットフォームの間に存在すべきインターオペラビリティを、Google が意図的に削除したという、動かしがたい事実を無視している。 Google の実装は故意に Java を断片化するものであり、また、Write Once, Run Anywhere の約束を破るものである。 この裁定がまかり通るなら、アメリカにおける革新と発明の保護に、傷がつくことになるだろう。そして世界のいたるところで、自身のものとしてシンプルに、知的財産権を守ろうとしている企業の立場を、難しいものにしていくだろう」。

While Google’s victory in the case is a big win for the company and its Android platform, the legal proceedings are by no means over. Oracle’s eventual appeal will have legs based on both Judge Alsup’s ruling on the fair use aspect and the jury’s split decision over the most important copyright issues.

今回のケースで Google が勝ち得たものは、同社と Android プラットフォームにとって大きな勝利となるが、訴訟の手続きが終了したわけではない。 Oracle による最終控訴が、最も重要とされる著作権の問題に関して、Judge である Alsup が公正な用法であると裁決したこと、そして、陪審員の判断が割れたことに対して、何らかの巻き返しをもたらすかもしれない。

ーーーーー

TAG index昨年の今頃は、Android の特許をめぐる報道が花ざかりで、それこそ毎日のように Android 特許関連のニュースが飛び交っていました。 そして、以下の<関連>にあるように、Note および Motorola の買収で沈静化したように思われましたが、一連の訴訟と一線を隔てるのが、この Java の根本に関わる Oracle からの訴訟でした。 「 モバイル特許の相関図は 込み入っていて、まるで地下鉄マップのようだ! 」というポストでも、「現実の Google を見ると、法的に厳しい状況に追い込まれているのは、モバイル領域における Java の利用について、Oracle から告訴されているところだけとなる」 と紹介されていました。 Oracle は控訴するようですので、今後も目を離せませんね。 ーーー __AC Stamp 2

ーーーーー

<関連>

Google は $1 billion 近い金額を、破産申請中の Nortel 特許権に投入
Android 特急は、パテント攻撃により脱線してしまうのか?
Nortel 特許の売却 – アメリカとカナダの法廷が 6社連合に承認
Google は IBM から、1030 個の特許を取得する!
Google が Motorola Mobility を $12.5B で買収 – Forbes 速報

Comments Off on Java と Android をめぐる Oracle と Google の争い : API の適正な用法とは?

Google App Engine:ついに Search API が登場!

Posted in .Selected, API, Google by Agile Cat on May 21, 2012

Google App Engine Finally Debuts the Search API
http://wp.me/pwo1E-4ex
Romin Irani, May 10th, 2012
http://blog.programmableweb.com/2012/05/10/google-app-engine-finally-debuts-the-search-api/

_ ProgrammableWeb

The Google App Engine team has been consistently rolling out a new release every month recently. They have become so consistent in doing so, that new releases probably do not make that much of a splash. However, the team has pleasantly surprised everyone by delivering on one of the most requested features that developers had asked from their PaaS platform: Search. Yes, you read that right.

Google App Engineチームは、この数カ月にわたって、継続的にニュー・リリースを提供してきた。 彼らは一貫してリリースし続けてきたが、おそらく、それほどの反応を得ることはなかったと思われる。 しかし、このチームは、最もリクエストが多かった機能をリリースすることで、すべての GAE デベロッパーを驚かさせた。それは、彼らの PaaS プラットフォームからの問い合わせを実現する、Search API である。 あなたも、その価値を認めるだろう。  

imageThe feature was first requested 4 years back and support for the Search API on Google App Engine was announced a few days back, though in an experimental mode for now. The Search API at a high level leverages the Google Infrastructure to add full text search to your application. The API packs quite a punch and not only includes basic searching for fields and ranges but also scoring and snippeting.

Search APIon Google App Engine に関するリクエストは 4年前にさかのぼるが、つい先日に、この機能の実験モードとしての提供がアナウンスされたのだ。この、ハイ・レベルな Search API により、あなたのアプリケーションに全文検索を加えるために、Google Infrastructure にテコ入れが行なわれているはずだ。 この API は、フィールドとレンジに対する基本的な検索だけではなく、Scoring と Snippeting をも含むというふうに、なかなかのパンチを持っている。

To help developers understand integrating Search in their application, there is a Sample application, that you will need to setup and try out. The team is requested developers to report issues as they use it and it is good to see that some issues reported are currently even being worked on.

アプリケーションと Search の統合について、デベロッパーの理解を促進するために、設定と試用で必要となる情報が、Sample アプリケーションで提供される。 このチームは、それを使いながら問題を報告し、いくつかの問題が存在することを確認していくことを要求される、開発者により構成される。

The Search API is currently available in Experimental mode Python and Java. If you are an App Engine developer, what are your thoughts on the Search API? What kind of benefits do you see as compared to your home grown solutions?

この Search API は、現時点において、PythonJava でによるExperimental モードとして提供されている。 あなたが App Engine デベロッパーなら、この Search API について、何を思うだろうか? これまで、自身で生み出してきたソリューションと比較して、どのようなメリットを発見するだろうか?

ーーーーー

TAG indexへぇ~~~ Google は Search API を出していなかったのですね。昨年の夏に、Google App Engine が本格運用に入るという記事をポストしました。 そこでは価格体系が見直されるだけではなく、Python 2.7 のサポートや、MapReduce フレームワークのリリースなども行なわれていました。 そして今回は、切り札とも言える Search API が提供されるわけですが、Google の考える PaaS は、どのようなカタチになるのでしょうかね? とても、楽しみです。 ーーー __AC Stamp 2

ーーーーー

<関連>

Google App Engine が本格運用に入るが、これまでと何が変わるのか?
Twitter の Trend API は、XML から JSON-Only へと移行する
5 つのエクセレントな、クラウド開発コミュニティ
Twitter の 圧倒的な API 消費量は、Facebook や Google の 3倍に達する
USA Today が提供する、アメリカ国勢調査の分析 API

Comments Off on Google App Engine:ついに Search API が登場!

Google が IBM からの特許取得を拡大 – Oracle への反撃は?

Posted in Google, Oracle, Patent by Agile Cat on January 6, 2012

Google Goes On The Offensive In Oracle Fight
http://wp.me/pwo1E-3Mn
Matt Rosoff | Jan. 4, 2012
http://www.businessinsider.com/google-just-got-some-new-ammo-in-its-legal-fight-with-oracle-2012-1

_ Business Insider

Google just picked up a bunch of patents from IBM to help it fight a multibillion dollar lawsuit from Oracle.

Google が IBM から手に入れたばかりの一群の特許は、Oracle から仕掛けられている 数10億ドル訴訟において、その戦いを支援するものとなる。

At the end of 2011, the US Patent Office recorded that Google bought more than 200 patents from IBM, as first noticed by blog SEO By The Sea. It’s the third deal between the two companies in the last year, accounting for more than 2,000 patents.

SEO By The Sea というブログが指摘するように、2011年の終わりに Google が IBM から、200 項目以上の特許を購入したことを、US Patent Office は記録している。 それは、この両社間で行われた、昨年における 3回目の取引であり、その結果として、2,000項目以上の特許が、Google にも利用できるようになった。

clip_image001But the latest batch is particularly interesting because the bulk of them have nothing to do with the mobile business, but instead relate to database technology — Oracle’s core business.

しかし、この直近における取引には、モバイル・ビジネスに関連するものが含まれず、その代わりに、Oracle のコア・ビジネスである、データベース・テクノロジーに集約されている点が興味深い。

Like #5937406, "File System Interface To A Database." Or #7117385, "Method and Apparatus for Recovery of Partitions in a Logical Partitioned Data Processing System." In all, the word "data" appears more than 40 times in the filings. The word "mobile", only six times.

たとえば、#5937406 である "File System Interface To A Database" や、 #7117385 の "Method and Apparatus for Recovery of Partitions in a Logical Partitioned Data Processing System" などが主体となっている。 それら全体において、単語「 data 」は、出願書類に 40 回以上も現われる。 しかし、「 mobile」は、たった 6回しか登場しない。

Oracle sued Google for copyright infringement over Android last year, and is seeking damages of several billion dollars, which is more than Android has earned for Google in its entire lifetime. Now Google is getting a little more offensive in its fight back.

Oracle は昨年、Android が著作権を侵害したとして、Google に対して訴訟を起こしている。そして、数10億ドルの損害賠償金を求めているが、これまでに Android が Google にもたらした金額より、多額なものとなっている。 そして、いま、Google の反撃は、これまで以上に攻撃的なものとなってきている。

Please follow SAI on Twitter and Facebook.
Follow Matt Rosoff on
Twitter.

ーーーーー

TAG indexGoogle は 昨年、Motorola を買収する直前の 6月に、IBM から 1000 項目以上の特許を購入しています。 それが、この両社間における最初の取引であり、その後にも、二度目の取引が行こなわれたようですね。8月にポストした [ モバイル特許の相関図は 込み入っていて、まるで地下鉄マップのようだ! ] では、「現実の Google を見ると、法的に厳しい状況に追い込まれているのは、モバイル領域における Java の利用について、Oracle から告訴されているところだけとなる」という指摘もありました。 基本的に Oracle による SUN Microsystems の買収に、端を発しているわけですが、この訴訟が、どのような決着を見るのか、とても興味深いですね。 それと、以下の <関連> も、ぜひ ご利用くだださい  ーーー __AC Stamp 2

ーーーーー

<関連>

Google は IBM から、1030 個の特許を取得する!
Google が Motorola Mobility を $12.5B で買収 – Forbes 速報
モバイル特許の相関図は 込み入っていて、まるで地下鉄マップのようだ!

Comments Off on Google が IBM からの特許取得を拡大 – Oracle への反撃は?

Google App Engine が本格運用に入るが、これまでと何が変わるのか?

Posted in .Selected, API, Google by Agile Cat on November 15, 2011

Google App Engine Goes Out of Preview, Means Serious Business
Romin Irani, November 8th, 2011
http://blog.programmableweb.com/2011/11/08/google-app-engine-moves-out-of-preview-means-serious-business/

_ ProgrammableWeb

Google App Engine has logged an important milestone in its history by moving out of preview and has now become a fully supported Google Product. The last few months have not been the easiest for the platform-as-a-service after App Engine price increases. But the team listened to the developers, was focussed on the tasks and with regular releases kept the momentum going. The latest release is not just out of preview but packed with enhancements.

Google App Engine は、そのプレビューを終えることで重要なマイルストーンに到達し、また、Google Product として完全にサポートされるようになった。 App Engine の価格が引き上げられてからというもの、この Google の PaaS にとって、すべてが順調とは言えない時期が続いた。 しかし、このチームは、デベロッパーたちの声に耳をかたむけて、また、抱えているタスクに焦点を合わせ、予定されたリリース時期を守ることで、その勢いを維持してきた。 最新のリリースは、プレビューで提供されたものに加えて、いくつかの拡張を取り入れている。

imageThe announcement at the App Engine blog not just mentioned the graduation to a fully supported Google Product but also underlined the fact that App Engine continues to remain a popular platform with more than 100 billion+ monthly hits.

App Engine ブログは、完全な Google Product としてのサポートを発表するだけではなく、100 billion 以上のヒットを有する人気のプラットフォームとして、 App Engine が維持されているという事実を強調している。

As of November 7, the new pricing structure will be in effect. Also updated are the terms of service and acceptable use policy. If you have a paid application on the High Replication Datastore, you are also covered by the 99.95% SLA.

11月7日の時点で、App Engine の新しい価格体系が適用されている。 さらに、サービスにおける条件と、利用許諾のポリシーも更新されている。 High Replication Datastore 上のアプリケーションに対して、あなたが対価を支払っているなら、99.95% の SLA という保証もカバーされる。

There is good news for Python devs in this release. Python 2.7 is supported and a full MapReduce framework in experimental mode has been released. Java developers have various enhancements made to the Memcache API, Datastore callback support and in Capability Testing. For full list of changes, refer to the Python and Java Release Notes.

そして、このリリースは、Python デベロッパーにとっても良いニュースである。 Python 2.7 がサポートされ、また、MapReduce フレームワークの実験的なモードもリリースされる。 Java デベロッパーに対しても、Memcache API や、Datastore コールバック・サポート、Capability Testing などに対する拡張が提供される。 この変更の詳細リストに関しては、PythonJavaの Release Notes を参照して欲しい。

While some developers remain critical of the changes that Google has made to its pricing, we are beginning to see encouraging posts from developers who have adapted their application and brought down their pricing significantly. A post from Greg Tracy, whose $75 / year app we covered earlier, has put in a fairly detailed report of the changes that he made to bring down the pricing of his application from $6/7 per day to $0/day.

一部のデベロッパーは、Google が実施した価格変更に対して、依然として批判的な立場にいる。その一方では、アプリケーションを改変し、自身の価格設定を大幅に引き下げたデベロッパーからの、Google を支持するポストも、いくつか確認できるようになった。以前に紹介したように、$75 / year のアプリケーションを提供する Greg Tracy が、その変更における詳細なレポートを提供している。 彼のアプリケーションは、$6/7(日)から $0(日)へと、その価格を引き下げたのだ。

It has been a terrific 3+ years for Google App Engine and it has been one of the key platforms that developers have used to move their applications to the cloud. Now that it is out for preview and with new terms of service, SLA, it remains to be seen if more enterprises now consider it as a viable option.

これまでの、3年間を超える期間は、Google App Engine にとって素晴らしいものであった。 そして、デベロッパーたちのアプリケーションをクラウド上で実行する、主要なプラットフォームの 1つとして認識されてきた。 そして、プレビューが終わり、新しいサービスの条件と SLA が提示されたが、数多くのエンタープライズが Google App Engine を、発展し得る選択して見なすのかどうかを、確認していく必要性が残されている。

ーーーーー

TAG index10月7日付の Google Developer Blog には、「App Engine に寄せられるリクエストとして最も多かったものは、従来からのデータベース駆動型のアプリケーションを開発するための、シンプルな方式を提供して欲しいというものだった。 そのフィードバックに応えるために、私たちは Google Cloud SQL の限定プレビューを、喜びと伴に発表する 」 というふうに書かれていますが、これが 文中の High Replication Datastore の事なのでしょうか? まぁ、いずれにしても、今度こそ本気の Google App Engine ということで、これまでの改善における成果が期待されますね! ーーー __AC Stamp 2

ーーーーー

<関連>

Gmail の新機能を、1分半の Youtube で簡単にチェック!
Google の アジア・データセンター戦略とは?
Wikileaks ボランティアの Gmail データが、Google から 米政府に開示された
Chrome の Remote Desktop ベータ版が出たらしい
Google Cloud SQL は、MySQL ライクな UI と、DC 間同期をサポートする

 

Comments Off on Google App Engine が本格運用に入るが、これまでと何が変わるのか?

GW プチ特集 – Twitter の 2011年 1月~4月

Posted in Twitter by Agile Cat on April 30, 2011

最近は クジラ さんにお目にかかれませんが ・・・

_ Twitter

なんというか、磐石の体制で突き進む Facebook と比べてしまうと、やれ金がないだとか、API で貧乏サードパーティから金を絞りとるとか、ある意味で親近感を抱かせてくれる Twitter です。 Agile_Cat の最近の悩みは、WordPress から Twitter への API が機能しないことがあるという点ですが、API の場合はダメであってもクジラが出ないのが不満です。 う~ん、やはり Twitter は API が悩みどころだし、そこにブレークスルーがあるのでしょうね。 ーーー __AC Stamp 2

ーーーーー

February 3 : TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!

February 12 : Web メールの時代は 終わってしまうのか?

February 15 : TweetDeck の 140文字以上のツイートって、OK なの? NG なの?

February 17 : バルセロナの MWC での買収話を、あらためて否定する Twitter

March 17 : ありがとう Twitter! 災害時に発揮されたキミの実力をチャートで検証する

March 21 : Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する

March 22 : Happy Birthday Twitter – 5 歳になりました!

April 1 : Twitter が、新しいデータセンターへの移行を完了

April 2 : 日本の大震災で証明された Twitter と Facebook の SOS パワー

April 13: Twitter における、Ruby から Java への回帰とは?

April 14 : Twitter サーチを 3倍速にする新アーキテクチャとは? _1

April 15 : Twitter サーチを 3倍速にする新アーキテクチャとは? _2

April 17 : Twitter サーチを 3倍速にする新アーキテクチャとは? _3

April 17 : Twitter と Facebook の、人間関係すったもんだ

April 21 : Twitter API の利用が落ち込んでいる – 心配だ!

ーーーーー

どこかに身売りって言うのだけはやめてねと、せつに願ってしまう Twitter さんです。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter 2010 総集編 Agile_Cat 版

 

Comments Off on GW プチ特集 – Twitter の 2011年 1月~4月

Twitter サーチを 3倍速にする新アーキテクチャとは? _3

Posted in Big Data, Twitter by Agile Cat on April 17, 2011

Twitter Search is Now 3x Faster
Wednesday, April 6, 2011
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

ーーーーー

これは、三部作の最終回です。初めての方は、1 と 2 をお先に ど~ぞ。

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーー __AC Stamp 2

ーーーーー

MULTIPLEXING INCOMING REQUESTS

Because workflows are mapped to Netty pipelines in Blender, we needed to route incoming client requests to the appropriate pipeline. For this, we built a proxy layer that multiplexes and routes client requests to pipelines as follows:

このワークフローは、Brender における Netty パイプラインにマップされるため、Incoming リクエストを、適切なパイプラインに送る必要があった。 そのため、以下のようなマルチプレックスのプロキシー・レイヤを構築し、パイプラインにクライアント・リクエストをルーティングしている:

  • When a remote Thrift client opens a persistent connection to Blender, the proxy layer creates a map of local clients, one for each of the local workflow servers. Note that all local workflow servers are running inside Blender’s JVM process and are instantiated when the Blender process starts.
  • When the request arrives at the socket, the proxy layer reads it, figures out which workflow is requested, and routes it to the appropriate workflow server.
  • Similarly, when the response arrives from the local workflow server, the proxy reads it and writes the response back to the remote client.
  • リモート Thrift クライアントから Blender に、永続的なコネクションをオープンするときに、このプロキシー・レイヤがローカル・クライアントを作成し、それぞれのローカル・ワークフロー・サーバーにマップしていく。 注意すべきことは、すべてのローカル・ワークフロー・サーバーが、Bernder の JVM プロセス内で実行され、また、Brender プロセスがスタートするときにインスタンス化される点である。
  • それらのリクエストがソケットに到着するとき、プロキシー・レイヤによる読み込みが行われ、求められるワークフローの種類が理解され、適切なワークフロー・サーバーへのルーティングが行われる。
  • それと同様に、それらのローカル・ワークフロー・サーバーからレスポンスが戻ったとき、対象となるプロキシーによる読み込みが行われ、リモート・クライアントへのレスポンスの書込みが完了する。

We made use of Netty’s event-driven model to accomplish all the above tasks asynchronously so that no thread waits on I/O.

それら全てのタスクを非同期化するために、Netty のイベント駆動型モデルを利用することで、I/O の待ち時間が排除された。

imageDISPATCHING BACK-END REQUESTS

Once the query arrives at a workflow pipeline, it passes through the sequence of service handlers as defined by the workflow. Each service handler constructs the appropriate back-end request for that query and issues it to the remote server. For example, the real-time service handler constructs a realtime search request and issues it to one or more realtime index servers asynchronously. We are using the twitter commons library (recently open-sourced!) to provide connection-pool management, load-balancing, and dead host detection.

ワークフロー・パイプラインに到着したクエリーは、対象となるワークフローで定義さたとおりに、サービス・ハンドラーのシーケンスを通過していく。 続いて、それぞれのサービス・ハンドラーが、対象となるクエリーに適したバックエンド・リクエストを構成し、リモート・サーバーへ向けて送り出す。 たとえば、リアルタイム・サービス・ハンドラーは、リアルタイム・サーチ・リクエストを構成し、複数のリアルタイム・インデックス・サーバーへ向けて、そのリクエストを非同期で発行する。私たちは、コネクション・プール管理および、ロード・バランシング、デッド・ホスト検出を提供するために、 Twitter コモン・ライブラリ(最近オープンソース化された!)を使用している。

The I/O thread that is processing the query is freed when all the back-end requests have been dispatched. A timer thread checks every few milliseconds to see if any of the back-end responses have returned from remote servers and sets a flag indicating if the request succeeded, timed out, or failed. We maintain one object over the lifetime of the search query to manage this type of data.

すべてのバックエンド・リクエストがディスパッチされると、そのクエリーを処理している I/O スレッドが解放される。 タイマー・スレッドは、数ミリ秒ごとにチェックを行い、リモート・サーバーから返されたバックエンド・レスポンスを確認し、トリガーとなったリクエストに対して、succeeded/timed out/failed といったフラグをセットしていく。 私たちのシステムでは、この種のデータを管理するために、サーチ・クエリーのライフタイムをカバーするよう、そのオブジェクトを保持している。

Successful responses are aggregated and passed to the next batch of service handlers in the workflow pipeline. When all responses from the first batch have arrived, the second batch of asynchronous requests are made. This process is repeated until we have completed the workflow or the workflow’s timeout has elapsed.

成功したレスポンスはアグリゲートされ、そのワークフロー・パイプライン内におけるサービス・ハンドラーの、次のバッチに受け渡される。 最初のバッチからの、すべてのレスポンスが到着したとき、非同時性のリクエストにおける 2番目のバッチが作成される。 そのワークフローが完了するまで、あるいは、ワークフローのタイムアウトが経過するまで、このプロセスは繰り返される。

As you can see, throughout the execution of a workflow, no thread busy-waits on I/O. This allows us to efficiently use the CPU on our Blender machines and handle a large number of concurrent requests. We also save on latency as we can execute most requests to back-end services in parallel.

ここまでに確認してきたように、ワークフローの実行を通じて、 I/O 上のスレッド・ビジー待ちは発生しない。つまり、Blender マシン上での CPU 利用および、大量のコンカレント・リクエスト処理において、効率化が実現される。 そして、並列化されたバックエンド・サービスで、大半のリクエストを処理するときには、レイテンシーを抑えることができる。

BLENDER DEPLOYMENT AND FUTURE WORK

To ensure a high quality of service while introducing Blender into our system, we are using the old Ruby on Rails front-end servers as proxies for routing thrift requests to our Blender cluster. Using the old front-end servers as proxies allows us to provide a consistent user experience while making significant changes to the underlying technology. In the next phase of our deploy, we will eliminate Ruby on Rails entirely from the search stack, connecting users directly to Blender and potentially reducing latencies even further.

このシステムに Blender を導入するのと並行して、高品質のサービスを保証するために、従来からの Ruby on Rails フロントエンド・サーバーをプロキシーとして利用し、Blender クラスタへ向けて Thtift リクエストを送っている。 フロントエンド・サーバーをプロキシーとして使用することで、基礎をなすテクノロジーに相当量の変更を施す間も、一貫したユーザー・エクスペリエンスの提供が実現される。 私たちの、次のディプロイ・フェーズでは、このサーチ・スタックから Ruby on Rails を完全に取り除き、ユーザーと Blender のダイレクトな接続を実現し、また、さらなるレイテンシーの低減を目指すだろう。

—@twittersearch

ACKNOWLEDGEMENTS

The following Twitter engineers worked on Blender: Abhi Khune, Aneesh Sharma, Brian Larson, Frost Li, Gilad Mishne, Krishna Gade, Michael Busch, Mike Hayes, Patrick Lok, Raghavendra Prabhu, Sam Luckenbill, Tian Wang, Yi Zhuang, Zhenghua Li.

ーーーーー

いやぁ~~~ 面白かったです。 このポストに関しては、いろいろな方から Twitter でコメントいただきました。 おかげさまで、とても多くの方が注目するアーキテクチャなのだと、実感することができました。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3
ーーーーー
Blenderに近いアーキテクチャになっているMessage Pack RPCのJava版の実装
Talk about Scala – SlideShare ( @yasushia さんより)
Twitter における、Ruby から Java への回帰とは?
ーーーーー
Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

Comments Off on Twitter サーチを 3倍速にする新アーキテクチャとは? _3

%d bloggers like this: