Agile Cat — in the cloud

だいじょうぶ マイ 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つのポイント

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 速報

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

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 速報
モバイル特許の相関図は 込み入っていて、まるで地下鉄マップのようだ!

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 間同期をサポートする

 

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 版

 

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 歳になりました!

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

Posted in Big Data, Twitter by Agile Cat on April 15, 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 をお先に ど~ぞ。三部作になっています。

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

ーーー __AC Stamp 2

ーーーーー

BLENDER OVERVIEW

Blender is a Thrift and HTTP service built on Netty, a highly-scalable NIO client server library written in Java that enables the development of a variety of protocol servers and clients quickly and easily. We chose Netty over some of its other competitors, like Mina and Jetty, because it has a cleaner API, better documentation and, more importantly, because several other projects at Twitter are using this framework. To make Netty work with Thrift, we wrote a simple Thrift codec that decodes the incoming Thrift request from Netty’s channel buffer, when it is read from the socket and encodes the outgoing Thrift response, when it is written to the socket.

Blender とは、Netty 上に構築された Thrift と HTTP のサービスであり、Java で記述されたスケーラブルな NIO クライアント・サーバライブラリにより、多様なプロトコルを用いるサーバーとクライアントを、迅速かつ容易に開発していく。たとえば、Mina や Jetty なども提供されるコンペティションの中から Netty を選んだ理由としては、整理された API や、洗練されたドキュメントなどが挙げられるが、それらよりも重要なのは、Twitter ににおける他のプロジェクトが、このフレームワークを用いている点にある。 Netty と Thrift を組み合わせるために、Netty のチャネル・バッファからの incoming Thrift のリクエストをデコードする、シンプルな Thrift コーデックを記述した。それは、ソケットからの読み込みと、outgoing Thrift レスポンスをエンコードするとき、また、ソケットへの書き込みを行うときに機能する。

Netty defines a key abstraction, called a Channel, to encapsulate a connection to a network socket that provides an interface to do a set of I/O operations like read, write, connect, and bind. All channel I/O operations are asynchronous in nature. This means any I/O call returns immediately with a ChannelFuture instance that notifies whether the requested I/O operations succeed, fail, or are canceled.

Netty は、Channel と呼ばれる重要な抽象概念を定義する。それにより、read/write/connect/bind といった I/O オペレーションを設定する、インターフェイスのためのネットワーク・ソケットへの接続がカプセル化される。 すべての Channel I/O オペレーションは、本質的に非同期である。つまり、あらゆる I/O コールが、要求された I/O オペレーションが succeed/fail/canceled されたことを通知する、ChannelFuture インスタンスを直ちに返すことになる。

When a Netty server accepts a new connection, it creates a new channel pipeline to process it. A channel pipeline is nothing but a sequence of channel handlers that implements the business logic needed to process the request. In the next section, we show how Blender maps these pipelines to query processing workflows.

Netty サーバーが新しいコネクションを受け入れるとき、その処理のためお、新しいチャンネル・パイプラインが作成される。 このチャネル・パイプラインは、リクエストを処理するために必要なビジネス・ロジックを実装する、チャネル・ハンドラーのシーケンスに過ぎない。次のセクションでは、それらのパイプラインと、クエリー処理ワークフローを、Blender がマップする方式を説明する。

WORKFLOW FRAMEWORK

In Blender, a workflow is a set of back-end services with dependencies between them, which must be processed to serve an incoming request. Blender automatically resolves dependencies between services, for example, if service A depends on service B, A is queried first and its results are passed to B. It is convenient to represent workflows as directed acyclic graphs (see below).

Blender において、ワークフローとは総合に依存するバックエンド・サービスのセットのことであり、incoming リクエストを取り扱うために処理されるものとなる。 そして Blender は、それらのサービス間の依存性を自動的に解決する。 たとえば、Service A が Service B に依存している場合には、最初に A がクエリーされ、その結果が B に手渡される。このワークフローを、非環式の有向グラフを用いて表現すると解りやすい(以下を参照)。

Sample Blender Workflow with 6 Back-end Services

In the sample workflow above, we have 6 services {s1, s2, s3, s4, s5, s6} with dependencies between them. The directed edge from s3 to s1 means that s3 must be called before calling s1 because s1 needs the results from s3. Given such a workflow, the Blender framework performs a topological sort on the DAG to determine the total ordering of services, which is the order in which they must be called. The execution order of the above workflow would be {(s3, s4), (s1, s5, s6), (s2)}. This means s3 and s4 can be called in parallel in the first batch, and once their responses are returned, s1, s5, and s6 can be called in parallel in the next batch, before finally calling s2.

上記のサンプル・ワークフローには、相互に依存する 6つの Service  {s1, s2, s3, s4, s5, s6} がある。s3 から s1 へ向けられた方向性を持つエッジは、s1 をコールする前に s3 をホールする必要性を示している。 その理由は、s1 が s3 の結果を要求する点にある。 このようなワークフローを前提として、Blender フレームワークは、それぞれの Service がコールされる順番を決定するために、DAG 上でのトポロジカル・ソートを行なう。 上記のワークフローにおける実行の順序は、{(s3, s4), (s1, s5, s6), (s2)} となるはずだ。つまり、最初のバッチにより、s3 と s4 をパラレルにコールできる。続いて、それらからのリターンの後に、s1 と s5 と s6 をパラレルにバッチ処理し、最後に s2 をコールする。

Once Blender determines the execution order of a workflow, it is mapped to a Netty pipeline. This pipeline is a sequence of handlers that the request needs to pass through for processing.

Blender がワークフローの実行順序を決定した後に、Netty パイプラインとのマップが行われる。 このパイプラインは、全体的な処理を通じて、受け渡しが必要なリクエストを、処理するためのシーケンスとなる。

ーーーーー

昨日の、okachimachiorz1 ジェイムズ・ブッカー先生によりますれば、『 Blenderすか。非同期+DAG+Scalaですか。まさにクラウド型のアーキテクチャです。 要チェックですな 』 とのことです。 なる! ーーー __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 億クエリー/月 を処理する!
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
日本の大震災で証明された Twitter と Facebook の SOS パワー
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

%d bloggers like this: