Agile Cat — in the cloud

新世代 JavaScript の調査:静的言語に関する議論と、テック・ジャイアントたちの綱引き

Posted in On Monday, Standard by agilecat.cloud on March 16, 2015
Javascript Evolves: Tech Heavyweights Battle Over Statically Typed Javascript
March 13, 2015 – Dick Weisinger
http://formtek.com/blog/javascript-evolves-tech-heavyweights-battle-over-statically-typed-javascript/
formtek.png
Javascript was ranked as the programming language of 2014 based on the frequency of searches made on public search engines like Google, Bing, Yahoo! and Wikipedia.  While Javascript has long had detractors, the fact that it’s the standard language of the browser has enabled it to remain popular.
 
JavaScript が 2014年のプログラミング言語として最上位を占めたのは、Google/Bing/Yahoo/Wikipedia などのパブリックな検索エンジンで、用いられる頻度に応じた結果である。Javascript は、長年にわたり批判に晒されているが、ブラウザ上の標準言語だという事実により、その人気が保たれている。
 
Rather than try to introduce totally new alternative languages to Javascript that would no doubt be difficult to get universally accepted, increasingly groups are attempting to introduce improvements to the Javascript language or to introduce new languages that ultimately compile to standard Javascript.
 
JavaScript を完全に置き換える言語を導入しても、普遍的に受け入れられる可能性については、間違えなく否定されるだろう。したがって、JavaScript 言語を改善しようとするグループや、スタンダードな JavaScript へ向けてにコンパイルする、新しい言語を導入しようとするグループが増えてきている。
 
The next generation of Javascript standard, ECMAScript 6, or ES6 is in the final rounds of being finalized, now targeted for June 2015.  (ECMA stands for the European Computer Manufacturers Association).  ES6 will include enhancements like promises, the ‘let’ keyword, and iterators.  It’s taken some time to get this far and there have been a number of delays before finalizing the specification.
 
次世代 Javascript スタンダードというか、ECMAScript 6(ES6)というか、その将来を決めるための最終ラウンドが、2015年6月に迫ってきているECMA はEuropean Computer Manufacturers Association の略)。ES6 は、Promises や、キーワードの ‘Let’、そして Iterators といった拡張を取り込んでいる。それらは、いくつかの成功を成し得てきたが、最終的な仕様を決めるまでに、多大な遅延も生じている。
 
Dali_11A quicker alternative to waiting for the ECMA committee to move forward with changes to the Javascript language is to create an ‘improved’ Javascript-based language that ultimately compiles in to Javascript code and will run in today’s browsers.
 
ECMA コミッティの結論を待ちながら、迅速な代替を進めようとしているグループは、JavaScript ベースの言語を作成するために、JavaScript 言語自身の変化を促進したがっている。それは、Javascript コードへとコンパイルされ、今日のブラウザで実行されるものである。
 
One area in particular that people find lacking with standard Javascript is the fact that it isn’t a statically typed language.  Some benefits of static typing include:
 
一般的な人々が、JavaScript スタンダードで見落としがちな領域として、静的言語ではないという現実がある。静的な型付けには、以下のようなメリットがある。
 
  • Detecting program errors early on before even running the program
  • Type declarations adds a minimal amount of auto-documentation that improves the understanding of the program
  • May improve runtime efficiency of the program
  • プログラムを実行する前であっても、エラーを容易に見つけられる。
  • 型宣言は、最小限の自動ドキュメントとしても機能するための、プログラムの理解を促進する。
  • ランタイム化されたプログラムの効率がが高まると思われる。
 
While many people agree that that the benefits of statically typed languages are large, especially for projects of scale, on the flip side, some issues that people have with statically typed languages include:
 
とりわけ、大規模プロジェクトにおいて、静的言語にメリットが生じると、数多くの人々が納得している。 その反対に、静的言語には以下のような問題が含まれると、それらの人々は認識している。
 
  • Verbose
  • Hard to use for prototyping
  • Time spent compiling
  • 冗長である
  • プロトタイプへの適用が困難
  • コンパイルで時間が消費される
 
Recently, three different approaches to creating new languages that support static typing and that ultimately compile into standard Javascript include Microsoft’s TypeScript, Facebook’s Flow, and Google’s AtScript and Closure.  It appears that a new browser battle may be brewing between heavyweight tech companies.
 
このところの動向として、最終的に JavaScript スタンダードへとコンパイルする、新たな静的言語の作成において、3種類のアプローチが錯綜している。 つまり、Microsoft の TypeScript と、Facebook の Flow、そして Google の AtScript と Closure である。その結果として、ブラウザをめぐる新たな戦いが、巨大ハイテク企業の間で激化しているのである。
 
<参考>
ECMAScript – Wiki Pedia
静的型付き言語プログラマから見た動的型付き言語
動的言語vs静的言語に関する議論と深い洞察
 
ーーーー
On Monday訳してみて、この世界も大変なんだなぁと、つくづく思いました。 そして、Microsoft と Facebook と Google がしのぎを削っているようですが、クロス・プラットフォームを標榜している三社なので、当然といえば、当然の成りゆきなのでしょう。 いずれにせよ、EES 6  が妥当なかたちに収まって、デベロッパーたちによるエコシステムが活性化するとよいですね。_AC Stamp
ーーーーー
<関連>
Cloud の調査:経営者たちが考える、クラウドの3つの長所と、検討すべき3つの基準
Blockchain の調査: IoT に適用することで、とても魅惑的な未来が見えてくる
IoT の調査:英政府のレポートが、 第二のディジタル革命 と位置づけている!
SaaS の調査:B2B 形式 から B2C 形式 へと、セールス・モデルが変化している
IoT の調査: ディジタル製造業という革命は成立するのか?

Comments Off on 新世代 JavaScript の調査:静的言語に関する議論と、テック・ジャイアントたちの綱引き

Web Programming の調査:Google の Dart は Javascript をリプレースできるのか?

Posted in Google, HTML5, On Monday by Agile Cat on March 10, 2014

Google Dart: A High Performance Replacement for Javascript
http://wp.me/pwo1E-7iu
By Dick Weisinger – March 4th, 2014
http://formtek.com/blog/google-dart-a-high-performance-replacement-for-javascript/

_ formtek

Dart is an open-source Web programming language that is being developed by Google.  The goal of the Dart language is provide better performance with a more modern and cleaner design than standard Javascript.  Google’s goal for the language is “to ultimately replace JavaScript as the lingua franca of web development on the open web platform”.  Although, Google will have a hard time convincing Microsoft, Apple and Mozilla to include the language anytime soon in their browsers.

Dart とは、Google が開発した、オープンソースの Web プログラミング言語のことである。この Dart という言語の目的は、標準とされている JavaScript と比較して、よりモダンでクリーンなデザインと、優れたパフォーマンスを提供することにある。この言語における Google の目標は、「オープンな Web プラットフォーム上の共通開発語に、最終的に Dart を仕立てあげることで、JavaScript をリプレースする」ところにある。しかし、Google は、Microsoft や、Apple、そして Mozilla などを説得するのに苦労するだろう。なぜなら、彼らのブラウザに、この言語が、素早く取り込まれる必要があるからだ。

 Markus “Notch” Persson, author of the popular and complex and compute-intensive Minecraft video game, tweeted in November 2013 after the 1.0 version of the language was first released that ”I love it.  Even if it doesn’t catch on, it produces pretty fast JS”.

複雑で計算集約的だが、人気のビデオ・ゲームでもある、Minecraft の作者として有名な Markus “Notch” Persson は、この言語の Version 1.0 がリリースされた直後の 2013年11月のツイートで、「 これは良い。 たとえ、広く受け入れられないにしても、きわめて高速な JS を生成する」と述べている。

‘Dart Flight School’, Google’s PR and training arm that sponsors events to promote the Dart language,  says on their web page that “Dart helps you build modern web apps with a new language, core libraries, and tools such as a package manager, editor, and a compiler to JavaScript. Use Angular with Dart for extra jet fuel.”

‘Dart Flight School’ とは、この Dart 言語の促進を目的としたイベントを主催する、Google の PR and Training 組織であるが、その Web ページには「 Dart が支援するのは、新しい言語とコア・ライブラリを用いたモダンな Web アプリの構築であり、さらには、パッケージ・マネージャや、エディタ、JavaScript コンパイラといった、いくつかのツールも利用できる。 そして、Angular with Dart を利用すれば、さらなる加速が可能となる」と記されている。

Dart 1.1, the recent release of the language was made available in January.  This version of Dart is 25 percent faster than the first release.  But it improves performance not only on the client side, but also on the server side.  On the server side, Dart now supports the handling of very large files, file copying, process signal handlers, accessing terminal information, and the  UDP networking protocol.

この 1月からだが、最新のリリースである Dart 1.1 が利用できるようになった。この、Dart のバージョンは、以前のリリースと比べて 25% も高速化されている。そして、クライアント側だけではなく、サーバー側でも、そのパフォーマンスは向上している。そのサーバー・サイドにおいて、最新の Dart は、大容量ファイル/ファイル・コピー/プロセス・シグナル・ハンドラ/端末アクセス情報/UDP ネットワーク・プロトコルなどをサポートしている。

A new technical committee within ECMA, has been formed, TC52, to create a standard specification for the Dart language.  Anders Sandholm, Product Manager at Google, blogged that ”Dart apps can be fast when compiled to JavaScript, but an embedded Dart VM enables even better performance.  We’re thrilled to have a dedicated technical committee working on Dart. We also feel confident that Ecma—the home of standards such as JavaScript, Eiffel, and C#—is the right place to help guide the evolution of the Dart language.”

ECMA 内に構成された、新しい Technical Committee である TC52 により、Dart 言語の標準仕様が作成されていく。Google の Product Manager である Anders Sandholm は、「 JavaScript にコンパイルされた Dart アプリも高速だが、エンベッドされた Dart VM は、さらに優れたパフォーマンスを実現している。私たちは、Dart に特化した Technical Committee が立ち上がったことを、とても喜んでいる。 そして、JavaScript/Eiffel/C# といった標準を育ててきた ECMA が、Dart を進化へと導くための適切な組織であると、自信をもって言える」と、自身のブログで述べている

Dart provides two paths for running in client browsers.  The first approach is to convert Dart code into standard Javascript before deploying to the browser.  That’s an approach similar to what’s done by other languages like CoffeeScript, Red Hat’s Ceylon and Microsoft TypeScript.  The second approach is to design and build a Dart-specific virtual machine (VM) that will run in a browser that can directly execute Dart commands without first pre-compiling the code to standard Javascript.

Dart が提供する 2つのパスが、クライアントのブラウザで実行される。最初のアプローチは、ブラウザにディプロイされる前に、Dart のコードを、標準である JavaScript に変換するものである。つまり、CoffeeScriptRed Hat の CeylonMicrosoft TypeScript といった、他の言語により行われてきたアプローチに似ている。第二のアプローチは、Dart 固有の VM を設計/構築するものである。つまり、標準の JavaScript にコードをプリ・コンパイルすることなく、Dart のコマンドをダイレクトに、ブラウザ内で実行するものになる。

Lars Bak, the leader of Google’s Dart project, said that ”the next step for us is to get the Dart virtual machine into Chrome… If everything pans out the way it’s predicted, with a factor of two performance boost and a factor of ten in startup-time boost, I’m pretty sure the other browsers will be enticed with what we’re doing.”

Google の Dart Project Leader である Lars Bak は、「 私たちにの次のステップは、Chrome に Dart VM を実装することだ。もし、すべてが予想どおりに進むなら、パフォーマンスは 2倍に向上し、起動時間も 10倍ほど高速化される。他のブラウザの持ち主たちも、Chrome で実現されることに誘惑されるはずだと、私は確信している」と発言している。

ーーーーー

この Dart ですが、日本語でいうとダーツのことであり、矢のことを指す言葉になります。そして、Ver 1.0 のことだと思いますが、Gihyo.jp に「2012年のJavaScript~PCからモバイルの時代へ」という記事が、2年ほど前にポストされています。 そして、ーーー DartはJavaScriptに変換するツールも備えていますが,あくまで最終目標はJavaScriptをDartで置き換えることです。Dartは大規模開発での利用に特化した設計になっており,JavaのようにIDE上で静的に解析できるようにデザインされています。また,当然ながらJavaScriptの良い点,悪い点から学んで,シンプルかつ強力な言語となっています。 ーーー と説明されています。おそらく、HTML5 の普及に合わせて、さらに Web Programming 言語が重要になってくるのだと思われます。 この先の、動向についても、注目していきたいですね。image

ーーーーー

<関連>

だいじょうぶ マイ HTML5 : その勝利に 94% のデベロッパーが賭けている
Web と jQuery のラブラブな関係を、いくつかのデータで証明する
JavaScript が 年間 48% のペースで肥大化している
Facebook が買収した、Mobile BaaS の Parse とは?
HTML5 は Web 3.0 になるのか?

Comments Off on Web Programming の調査:Google の Dart は Javascript をリプレースできるのか?

だいじょうぶ マイ 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% のデベロッパーが賭けている

モバイル BaaS エコシステム相関図 : あの Subway Map が大幅に更新!

Posted in .Selected, BaaS, Mobile, Post-PC by Agile Cat on November 20, 2012

The Backend as a Service Ecosystem Map Update & New Trends: Migration Toward the Middle
http://wp.me/pwo1E-5eq

Written by 
Annie Bourne
http://www.kinvey.com/blog/121/the-backend-as-a-service-ecosystem-map-update-amp-new-trends-migration-toward-the-middle

image

Tuesday morning, before taxiing down the runway (the first time), my United Airlines flight ran a short video promoting a glorious future where dynamic mobile applications would let passengers book and change travel plans on the run. Two hours later, this vision blurred when the 757 returned to the gate in Boston, canceled the flight, and regurgitated several hundred people into the terminal. A single desk attendant stood nervously behind the desk, as the line snaked through the hall. Former passengers were using their mobile devices to tell people their plans had changed, but did not appear to be using UA’s existing mobile app to book new ones.

火曜日の朝のことだが、私の乗った United Airlines の飛行機が滑走路へと向かう前に、短いビデオが放映された。そして、そこには、ダイナミックなモバイル・アプリにより、旅行の計画が予約され、素早く変更されるという、輝かしい未来が映し出されていた。そして、2時間後に、757 が Boston のゲートに戻ってきたとき、そのビジョンは幻になっていた。フライトがキャンセルされ、押し戻されてしまった何百人もの旅行者により、ターミナルはごった返していたのだ。ホールを蛇行する人々の列が長くなるにつれて、デスクの後ろに立っている係員はナーバスになっていった。 私の前に並んでいた乗客はモバイル・デバイスを使って、計画が変更になったことを誰かに伝えていた。しかし、いまの UA が提供しているモバイル・アプリを使って、新たに予約しているようには見えなかった。

A lot of technology companies are working hard to enable developers to build interactive data-rich, service-rich, scalable mobile applications: telecoms; providers of Infrastructure as a Service and Platform as a A Service; Mobile Enterprise Applications Platforms; Backend as a Service providers; Mobile Services; Mobile SDKs; and Handset manufacturers. Earlier this year, Kinvey’s CEO Sravish Sridhar put it all together on the document that’s now euphemistically known in the industry as “the Subway Map”.

数多くのテクノロジー・カンパニーが、インタラクティブで、データ・リッチで、サービス・リッチで、スケーラブルなモバイル・アプリを、デベロッパーが構築できるようにと、一生懸命に取り組んでいる。 そして、それらの企業には、Telecom や、IaaS Provider、Mobile Enterprise Applications Platforms、BaaS Provider、Mobile Service、Mobile SDK、Handset Manufacturer などが含まれる。 今年の初めに、 Kinvey の CEO である Sravish Sridhar は、いまや業界の Subway Map と、婉曲的に表現されるドキュメントに、そのすべてを配置してみた。

At Kinvey, we use the Subway Map to track the ecosystem, to plan strategic partnerships and figure out the best path to make more productive the companies, developers and development teams who use Kinvey’s Backend as as a Service to easily set up and maintain backends for their mobile, web and tablet apps.

Kinvey では、エコシステムをたどり、戦略的な提携をプランニングし、より生産的な企業と、デベロッパーと、開発チームの組み合わせを明確にするために、この Subway Map を利用している。そこで選ばれた企業や人材も、自身の Mobile/Web/Tablet アプリを、容易に構成・維持するために、Kinvey の BaaS を利用している。

Six months later, some new trends have emerged, so we’ve updated the Backend as a Service Ecosystem map:

それから 6ヶ月が経ち、いくつかの新しいトレンドが登場したので、この  Backend as a Service Ecosystem マップを更新した:

大きなサイズのビットマップ(2100 × 1500)は、ココでダウンロードできます。

Based on the update, here’s what we see happening lately, and speculation about why:

このアップデイトに基づき、最近に起こった出来事と、その理由に推測していく:

1) Mobile SDK and mobile services companies are moving down the stack, embracing cloud services.

Over and over again, one hears that developers don’t want to pay for development tools. Adobe, which bought PhoneGap last year, offers PhoneGap development tools free to their development community. Mobile SDK providers look elsewhere for revenue, including to backend cloud services. Appcelerator acquired Cocoafish and released the functionality this spring as Titanium Cloud Services. Yesterday, Flurry acquired Trestle to tack on cloud services to their mobile marketing services solutions.

繰り返して何度も聞かされるのは、デバロッパーは開発ツールに対して、対価を支払いたがらないという話である。 昨年に PhoneGap を買収した Adobe は、その開発コミュニティに対して、PhoneGap 開発ツールを無償で提供する。 Mobile SDK プロバイダーたちは、たとえばバックエンド・クラウド・サービスも含めて、他のところから収入を探しだす。 Appcelerator は Cocoafish を買収に、この春には、その機能をTitanium Cloud Services としてリリースした。 そして昨日、 Flurry が Trestle を買収したのは、自身のモバイル・・マーケティング・サービス・ソリューショに、クラウド・サービスを付加するためだ。

At Kinvey, we want to make developers worldwide instantly more productive by making it easy to create a backend in minutes, not days. We think it’s essential to make the tools developers choose work seamlessly with Kinvey’s Backend as a Service. Many of them love PhoneGap, so in June we partnered with Adobe PhoneGap and integrated our JavaScript library into the PhoneGap environment, providing PhoneGap developers with a smooth end to end solution. Developers also have optimized Kinvey’s JavaScript library for Appcelerator’s Titanium to make those tools work easily with Kinvey. We look forward to many more such partnerships.

Kinvey が望むのは、バックエンドの構築を容易にし、そこに費やされる時間を Day から Minutes に短縮することで、世界中のデベロッパーの生産性を直ちに向上させることである。そして、私たちは、デベロッパーが選んだツールを、Kinvey の BaaS にスムーズにつなげることに、本質があると考えている。 数多くのデベロッパーが、PhoneGap を好んでいる。 したがって、私たちは 6月に Adobe PhoneGap とパートナーシップを締結した。 そして、PhoneGap デベロッパーにスムースな End-to-End ソリューションを提供するために、私たち のJavaScript ライブラリを PhoneGap 環境に統合した。さらに、デベロッパーたちは、Kinvey の JavaScript ライブラリを、Appcelerator の Titanium に最適化した。それにより、それらのツールも、Kinvey と容易に協調できるようになった。 このようなパートナーシップが、もっと出現してくることを、私たちは楽しみにしている。

2) Enterprise software players are moving up the stack, pursuing larger developer mindshare

Watch this space. It’s so important that we added a new category to the Subway map – the MEAPs. Mobile Enterprise Application Platforms (e.g. Sybase Unified Platform, IBM Worklight, Kony, Antenna, Verivo) offer broad software platforms to support enterprises that want to enable multiple mobile apps for multiple operating systems which access multiple sources of data. We think they belong in the Subway map of the Backend as a Service ecosystem, even though they do not offer a service, because they are a significant way enterprises address mobile infrastructure needs. Also, we see some MEAPs now working to extend their value to the large market of nimble mobile application developers.

このスペースに注目すべきだ。 とても重要なので、この Subway Map の新しいカテゴリとして追加した。 それが、MEAP である。 Mobile Enterprise Application Platforms(例:Sybase Unified Platform/IBM Worklight/Kony/Antenna/Verivo)は、マルチ・データソースにアクセスする、マルチ OS のための、マルチ・モバイル・アプリの実現を望む、エンタープライズをサポートするための、幅広いソフトウェア・プラットフォームを提供する。たとえ、それらがサービスを提供しないとしても、この BaaS エコシステムの Subway Map に属すると考えるのは、モバイル・インフラを必要とするエンタープライズが、取り組むべき重要な道筋だからであるから。 さらに、私たちは、機敏なモバイル・アプリ・デベロッパーで構成される巨大なマーケットへ向けて、いくつかの MEAP が、その価値を拡張としているの確認している。

Today, most MEAPs are traditional software stacks consisting of middleware, backend integrations and client software, that have to be purchased, deployed and supported by the enterprise. The problem, as enterprises and analysts have told us, is that these traditional software stacks pose traditional software management challenges. They do not offload maintenance and scale to the cloud; they add to the IT costs internally. A MEAP software stack requires an estimate of 2 FTEs to learn it, deploy it and manage it. Some have raised concerns about whether vendors’ outsourcing of product support will deliver the quality of support they think they may need.

現時点において、大半の MEAP は、ミドルウェア/バックエンド統合/クライアント・ソフトウェアで構成される伝統的なソフトウェア・スタックであり、また、エンタープライズによる購入/ディプロイ/サポートが必要となる。 いくつかのエンタープライズと、何人かのアナリストが聞いた話によると、これらの伝統的なソフトウェア・スタックが、伝統的なソフトウェア・マネージメントという課題を引き起こしているのが、そこでの問題である。 彼らは、メンテナンスとスケールを、クラウドへ向けてオフロードしない。 つまり、IT コストを、社内で積み上げていく。 MEAP ソフトウェア・スタックが必要とするのは、それを学んで、ディプロして、管理していく、2人の FTE(Full Time Employees)だと見積もられている。 そこで生じる懸念は、ベンダーにおけるプロダクト・サポートのアウトソーシングが、想定され必要とされるサポートの品質を充たすかどうかである。

The consolidation theme continues among MEAPs too. IBM bought Worklight at the end of January, and SAP/Sybase bought Syclo in April.

つまり、コンソリデーションというテーマは、MEAP においても、存続し続けるということだ。 そして、1月の 終わりには、IBM が Worklight と買収し、4月には、SAP/Sybase が Syclo を買収している。

So why?

Why are mobile development tool companies moving down the stack while traditional enterprise software players are moving up?

なぜ、モバイル開発ツールのベンダーやサービサーがスタックを下っているのに、伝統的なエンタープライズ・ソフトウェア・プレーヤーは上がってくるのか?

Having worked with thousands of developers and development teams building mobile, web and tablet applications on Kinvey’s Backend as a Service solution, we think we have an idea:

Kinvey の BaaS ソリューション上で、Mobile/Web/Tablet アプリを 、何千というデベロッパーと開発チームに構築してもらうためのアイデアが、私たちにはあると思っている:

Many developers, including teams at companies like United Airlines, want to free their customers to do business with them through apps they can reach from any device: mobile, web or tablet. But designing for mobile apps requires a fundamental shift in assumptions from those required to build web or enterprise applications consumed through a web console. Enterprise apps are based on design principles that tightly couple database and middleware technologies and let them be consumed through a common web browser.

たとえば United Airlines のような企業のチームも含めて、数多くのデベロッパーたちは、あらゆるデバイス(Mobile/Web/Tablet)上のアプリを介して、彼らの顧客が自由にビジネスを進められるようにしたいと望んでいる。 しかし、モバイル・アプリをデザインするためには、コンソールを介して消費されるWeb やエンタープライズ・アプリの構築から、何らかの想定される環境へむけて、根本からのシフトが要求される。エンタープライズ・アプリケーションは、データベースおよびミドルウェアのテクノロジーと緊密に接続され、また、共通の Web ブラウザを介して消費されるという、デザイン上の原則に基づいている。

But mobile app developers shatter the principle of tight coupling – and then thrive among its fragments. People consume mobile apps on devices that are flung far and wide from any server or database. Somehow, these apps must incorporate data from any source – including from third party data sources, and even from those tightly coupled database systems an IT department has invested years and millions in maintaining and protecting. Beyond data, developers want to tap into many tools and services that other clever minds have created, like those offered by Facebook, Twitter, foursquare, and Urban Airship. And development teams must deliver all of this functionality, quickly and scalably, to any device that runs on any native operating systems (iOS, Android, Windows, Blackberry) – each of which requires coding in its own, unique, language.

しかし、モバイル・アプリのデベロッパーたちは、その密結合の原則を寸断した上で、その断片の狭間で活況を呈している。 そしてユーザーたちは、広大な空間に点在する、あらゆるサーバーやデータベースから得られる情報を、それぞれのデバイス上のモバイル・アプリで消費する。 それらのアプリケーションは、いかなるソースからであっても、何らかの方法で、データを取り込まなければならない。そこに含まれるものには、もちろん、サードパーティーからのデータソースがある。そして、さらに、企業の IT 部門が、膨大なコストと時間を費やして、維持・保持してきた密結合データベース・システムでさえある。 データのレベルを超えたところでデベロッパーたちは、冴えた発想で構築されたツールやサービスへと、入り込んで行きたがる。それらは、言うまでもなく、Facebook/Twitter/foursquare/Urban Airship などが、提供するものである。そして開発チームは、あらゆるネイティブ OS(iOS/Android/Windows/Blackberry)上で動作する、あらゆるデバイスに対して、すべての機能と迅速さとスケールを提供しなければならない。 つまり、それぞれが、デバイス自身と、一意性と、言語における、コーディングを要求するのである。

Today’s mobile application developers want to harness all of these parts and services, and do so with elegance, ease and scale. They want to write the front end, client side code for their app – and use BaaS to take care of all of the backend features including user management, data and large file storage, push notifications, geoqueries, analytics, API versioning. Some developers also want to write custom server-side logic and deploy that on PaaS solutions.

いまのモバイル・アプリ・デベロッパーは、すべてのパーツとサービスを、優雅かつ容易に、そしてスケーラブルに、取りまとめたいと望んでいる。 そして、彼らのアプリの、フロントエンドとクライアント・サイドのコードを書こうと望む。 さらに言えば、ユーザー管理および、データと大容量ファイルのためのストレージ、プッシュ通知、位置情報、分析、解析、API のバージョンなどに対応するために、BaaS を使いたがる。 何人かのデベロッパーは、カスタムなサーバー・サイド・ロジックを記述し、PaaS ソリューションにディプロイしたいと考える。

Kinvey provides the leading Backend as a Service solution, the only one that enables developers to integrate with 3rd party data sources. We make developers and development teams worldwide instantly more productive by making it easy for them to set up a backend in the cloud in a matter of minutes, not days or weeks. We free them up to focus on what differentiates their app – what people see and experience on the front end, not the tedious and time-consuming and repetitive tasks of creating, scaling and maintaining the backend plumbing of a mobile, web or tablet app.

Kinvey が提供する、最先端 Backend as a Service だけが、デベロッパーによるサードパーティ・データソースのインテグレーションを実現する。私たちはクラウドにおいて、バックエンドの構築を容易にし、そこに費やされる時間を Day から Minutes に短縮することで、世界中の開発チームの生産性を直ちに向上させる。私たちは、彼らがアプリの差別化にフォーカスできるよう、厄介ごとから解き放ってあげたいと思う。なぜなら、ユーザーが参照し、経験するものは、フロントエンドに集約されているからである。そして、Mobile/Web/Tablet アプリをバックエンドで配管するための、構築/スケール/維持といった、退屈で時間のかかるタスクの繰り返しは、ユーザーとは無縁なのである。

We’ve had a lot of feedback on the Backend as a Service ecosystem map. More than a few clever people have said that the “subway” analogy doesn’t quite hold, because each line goes only north-south. But look at it closely. The players are all moving toward the middle.

この、BaaS Ecosystem Map について、たくさんのフィードバックをもらっている。 そして、かなりの数の頭脳明晰な人々から、南北にのみ走るラインは、Subway という比喩に値しないと指摘されている。 でも、しっかりと見て欲しい。 すべてのプレーヤーが、ミドルへと向かっているのだ。

ーーーーー

imageこの Kinvey の Subway Map は、とても素晴らしい! 今年の 2月にポストした 『 モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう 』 という抄訳で、このマップの Ver 1 を紹介しましたが、そのとき以来 Agile_Cat は、それを壁紙にして、ヒマな時は必ず見る・・・というふうにしてきました Smile  お陰さまで、代表的な会社の名前も、徐々にですが記憶できるようになって来ました。そして、この記事も素晴らし出来栄えで、ほんと、Kinvey さんには感謝です!image

ーーーーー

<関連>

Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
Yahoo の Mojito は、あらゆる Mobile デバイスに対応する OSS プラットフォーム
AppMobi の狙いは、Mobile + OSS + HTML5 の惑星大直列なのだ!

Comments Off on モバイル BaaS エコシステム相関図 : あの Subway Map が大幅に更新!

Web と jQuery のラブラブな関係を、いくつかのデータで証明する

Posted in .Selected, API, HTML5, Network, Research by Agile Cat on June 27, 2012

The Web loves jQuery, and here are the numbers to prove it
http://wp.me/pwo1E-4m0

Posted in
Main on June 20th, 2012 by Pingdom
http://royal.pingdom.com/2012/06/20/jquery-numbers/

_ pingdom

We’re big fans of the JavaScript library jQuery, and it appears we are far from alone. As of June this year it’s used by 54.7% of the top 10,000 websites in the world. That’s a massive endorsement by the world’s web developers. It’s also a significant step forward from two years ago, when 28% of the sites used jQuery.

私たちは、JavaScript ライブラリである jQuery の大ファンだが、だからと言って変わり者ではないようだ。 今年の 6月時点において、世界の Top-10,000 Web サイトの 54.7% で、jQuery は使われている。 それは、世界中の Web デベロッパーから、大きな支持を受けていることの証だ。 そして、2年前には 28% のサイトだけが jQuery を使っていたことを考えると、そこには大きな前進がある。

This kind of widespread adoption is rare for JavaScript libraries, perhaps unprecedented. And jQuery hasn’t been around all that long; John Resig released the first version in 2006. It’s clearly another win for the use of open source software on the Web. Even Microsoft has embraced jQuery and is one of its supporters.

JavaScript ライブラリにおいて、この種の広範囲におよぶ適用は稀であり、おそらく前例もない。 そして jQuery は、それほど昔からあるわけではない。 John Resig が最初のバージョンをリリースしたのは、2006 年のことである。 さらに、Web におけるオープンソース・ソフトウェアの利用という面でも、明らかに 1つの勝利を収めている。 たとえば、Microsoft でさえ jQuery を取り入れ、また、支援しているのである。

Analyzing jQuery usage among the top sites

While we did the research for this post, we also looked at how popular jQuery is among the top 1,000 and top 100 websites in the world, to give some added perspective.

このポストのための調査に際し、世界の Top-1000 および Top-100 サイトにおける jQuery の人気にも注目してみた。 それにより、いくつかの別の視点が開けてきた。

クリックで拡大 ⇒

The jQuery usage among the top 100 sites would probably be a bit higher if Google weren’t behind such a big portion of them. Google owns one in five of the top 100 sites, and those sites don’t use jQuery. This in all likelihood skews the number a bit.

もし Google が、一連のサイトの後ろ盾になっていなければ、Top-100 サイトにおける jQuery 利用度は、若干ではあるが上昇していると思われる。 Google は Top-100 サイトのうちの 1/5 を所有しており、それらのサイトは jQuery を使っていない。 このことが、少し数を歪めていると思える。

Big sites that use jQuery

There are literally thousands of big sites that use jQuery, but a few examples are in order. So, here is a selection of some of the world’s biggest sites, all using jQuery:

jQuery を利用する大規模サイトは、文字どおり 何千とある。 その中から、順番に並べてみたので、以下は jQuery を用いる世界の大規模サイトの一覧となる:

WordPress.com, Pinterest, Reddit, MSN.com, WordPress.org, Amazon, Yandex, Microsoft.com, GO.com, Ask.com, ESPN, Craigslist, About.com, Go Daddy, Stack Overflow, Huffington Post, Instagram, Slideshare, Fox News, The Guardian, Etsy, LiveJournal, Weather.com and many, many more.

The most popular CDN for jQuery

Both Google, Microsoft and Media Temple have generously provided CDNs (content delivery networks) that site owners can freely use when they include jQuery on their sites. Site owners can of course elect to host the script(s) themselves as well.

Google および、MicrosoftMedia Templeは、対象となるサイトが jQuery を含んでいるときには、その CDN(Content Delivery Networks)を自由に使わせている。 しかし、それらのサイトの所有者自身が、スクリプトのホストとして選出されることも、もちろん有り得る。

So which jQuery hosting option is the most popular? Some additional analysis gave us the following result.

したがって、その jQuery ホスティング・オプションが、最も人気を集めているのかが分かる。 いくつかの追加の分析を行い、以下の結果を得ることになった。

クリックで拡大 ⇒

It should be mentioned that there is a certain amount of overlap in CDN usage. Almost half of the sites that use Microsoft’s CDN also use Google’s, for example.

このデータは、CDN 利用量に対して、ある程度の重複が見られるはずである。仮に、それらの jQuery サイトの半数が Microsoft の CDN を使うなら、Google を使うケースも半分になる。

It appears that the Google Ajax API CDN is by far the most popular CDN among web developers. A full 25.4% of sites that use jQuery include the script from Google’s CDN.

しかし、Google Ajax API CDN が、他の CDN サイトとの比較において、Web デベロッパーには最も人気の CDN であるように思える。 jQuery を使用するサイトの 25.4% が、Google の CDN からスクリプト提供されている。

The other two CDNs listed on jQuery’s site don’t even come close. There are 35 times as many sites using Google’s CDN as Microsoft’s. Media Temple’s jQuery CDN doesn’t fare much better; 23 times as many sites use Google’s CDN. Google’s dominance is quite complete here.

jQuery サイト上にリストアップされた、2つの CDN は大きく引き離されている。Google の CDN を利用するサイトは、Microsoft との比較において 35倍の量となる。  Media Temple の jQuery CDN も、上手く行っているようには思えない。 Google の CDN を使うサイトは、同社の 23倍となる。  ここでの Google の優位性は、きわめて完璧なものとなる。

That said, the majority of the sites with jQuery don’t use any of these three CDNs. Either they are using a different CDN, or host it themselves (the latter being more likely for most sites).

そして、このデータが示すのは、大半の jQuery サイトが、これら 3つの CDN を使っていないことである。それらのサイトは、他の CDN を使うか、自身でスクリプトをホストしていることになる(後者のほうが多いだろう)。

Conclusion

JQuery is in excellent health. It has powerful backers and contributors and a lively developer community. The popularity of jQuery has kept growing over the years, and deservedly so. We are proud to be one of the project sponsors.

jQuery の人気は、この数年にわたり上昇し続けており、そのことは賞賛されるべきである。そして、私たちは、このプロジェクトのスポンサーの 1人であることを、誇りに思っている。

We hope to revisit this post a year or so from now. Where do you think jQuery adoption will be by then? Judging by these numbers, it certainly isn’t likely to go down anytime soon.

いまから 1年後を目処に、これと同じ視点でポストしたいと望んでいる。jQuery 適用率は、その時に、どうなっているとだろう? 一連の値から判断すると、近々に下降してしまう可能性は、きわめて低いと思われる。

Methodology: We downloaded the HTML code for the top 10k websites in the world, according to Alexa (on June 19, 2012), and scanned for any variation of jQuery script inclusion. We only tested the homepages, i.e. the initial page you get when you visit a site.

ーーーーー

TAG indexそれにしても、モテモテの jQuery さんですね。 先月に、「 JavaScript が 年間 48% のペースで肥大化している 」という抄訳をポストしましたが、その背景には jQuery の存在があるのかも知れません。 そして、jQuery と CDN の関係も興味深いですね。 いろいろな意味で、いまのテクノロジーとの親和性に、jQuery の魅力が集約されているに思えてきます。 ーーー __AC Stamp 2

ーーーーー

<関連>

クラウドを バッチリ測定する、Cloud Harmony とは?
調査: ソフトウェアのイノベーションは OSS により推進される
世界の Web サイト : Top-10000 の 75% を OSS が占める
アジアの MOBILE トラフィック比率が、この 2年間で 3倍に増大した!
OpenLogic のスキャン調査によると、オープンソースが 730% も増えているらしい

Comments Off on Web と jQuery のラブラブな関係を、いくつかのデータで証明する

JavaScript が 年間 48% のペースで肥大化している

Posted in .Selected, HTML5, Miscs, Research by Agile Cat on May 24, 2012

Imminent bloat warning: JavaScript size up 48% in one year
http://wp.me/pwo1E-4fe
May 17th, 2012 by Pingdom
http://royal.pingdom.com/2012/05/17/javascript-size-up-48-percent/

_ pingdom

Websites are getting more dynamic, and more heavily scripted. JavaScript is going through something of a renaissance. Perhaps, however, it is time to start reigning in the amount of JavaScript code that’s included on the average web page.

Web サイトは、どんどんとダイナミックになるが、そのためのスクリプトは大きくなる。 JavaScript が、ちょっとしたルネッサンス期を通過している。 平均的な Web ページに含まれる総量として、JavaScript コードが君臨し始めるときが訪れているのだろう。

This chart shows an average based on thousands of tested websites from the end of 2010 until now (HTTP Archive performs tests every month).

このチャートは、2010年の終わりから今までという期間で、何千という Web サイトをテストした結果の平均値を示す(HTTP Archive が毎月テストを行なっている)。

Stats from HTTP Archive show an alarming trend:

As you can see, a year ago the average web page included 128 kB of JavaScript. Now that number has risen to 189 kB. It’s gone up 48% in just a year.

ここで確認できるように、1年前における Web の平均値では、1ページあたりに128 kB の JavaScript が含まれていた。 しかし、いまでは、その値は 189 kB に上昇している。 つまり、たった 1年で、48% も上昇したのだ。

Another 50% increase over the coming 12 months would put us at 283 kB of JavaScript. Then add all the other stuff that’s also growing, such as image download size, and the picture for web performance enthusiasts start to get pretty bleak.

これからの 12ヶ月間にわたって、もう一度 50% の増加があると、JavaScript の平均バイト数は 283 kB に到達する。そして、イメージのダウンロード・サイズの増大がなども、この値に加えてれていくと、Web パフォーマンス優先主義者を取り巻く状況は、ますます悪化していく。

We’ve shown before how JavaScript is the fastest-growing contributor to web page size. Time to start paying more attention to this.

以前にも、JavaScript は Web ページ・サイズに対して、どれほどのコントリビュータであるかという記事をポストしている。 それについても、多くの注意を払い始めるべき、タイミングとなっている。

P.S. Yes, we’re aware this blog is an offender. One of the reasons we’re planning a revamp.

Top image via Shutterstock.

ーーーーー

TAG indexAgile_Cat で Javascript の記事というのは、初めてのことだと思います。 いつもであれば、このキーワードはパスしてしまうのですが、ものすごいペースで成長というか肥大化というか、とにかく急速にサイズアップしているようなので、見逃せませんでした。そして、さらに気になるのは、モバイルおよび HTML5 との関係です。 ちょっと探してみたら、Gihyo.jp に「2012年のJavaScript~PCからモバイルの時代へ」という記事がポストされていました。 これを読むと、いまの Javascript の立ち位置が見えてくるように思えてきます。ーーー __AC Stamp 2

ーーーーー

<関連>

HTML5 は Web 3.0 になるのか?
HTML5 vs. Flash の現実的な論点は、いったい何処にあるのだろう?
HTML 5 について、パブリッシャーが知っておくべき 5つのポイント
Chrome が IE を抜いて、世界の No.1 になったが・・・
日本と世界のインターネット・トラフィック – 2012年/4月

 

Yahoo の Mojito は、あらゆる Mobile デバイスに対応する OSS Dev プラットフォームなのだ

Posted in .Selected, BaaS, Mobile, Yahoo by Agile Cat on May 7, 2012

Yahoo open sources Mojito, a developer framework for any device
By
Ryan Lawler Apr. 2, 2012
http://gigaom.com/2012/04/02/yahoo-mojito/

Image(50)

Yahoo is taking a big step toward helping developers write code that will work well on any device, whether it be for the web, mobile web or even native iOS, Android or other smartphone operating systems. To do so, it’s decided to open source Mojito, a JavaScript-based developer framework that allows developers to leverage both client- and server-side technologies to get the best performance out of any device.

Yahoo が促進しているのは、あらゆるデバイス上で適切に動作するコードを、デベロッパーが効率良く記述していくための支援である。つまり、その対象は、Web や、Mobile Web、ネイティブの iOS および Android、そして、その他のスマートフォン OS であっても構わないことになる。 そして、それを実現するために、JavaScript ベースのデベロッパー・フレームワークである、オープンソースの Mojito が選ばれた。それにより、あらゆるデバイス型ベスト・パフォーマンスを得るための、クライアント・サイドとサーバー・サイドのテクノロジーを、デベロッパーは活用できるようになる。

Image(215)

Mojito is just one of the tools that the company has built internally as part of its Yahoo Cocktails program. But now it’s making Mojito available to all to play around with and improve upon.

Mojito とは、Yahoo Cocktails プログラムの一部として、同社がインターネルに構築したツールに過ぎない。 しかし、いまは、すべてのデバイスに Mojito が対応し、また、適切なパフォーマンスを発揮するよう改善している状況にある。

The idea behind Mojito is that developers will be able to build JavaScript-based applications that can be run on a number of devices, and adapt to the unique problems of the mobile web — that is, low-powered devices with constrained and spiky network traffic. Rather than have to choose between building for the web, mobile web or native app frameworks, developers will be able to create hybrid apps that perform well in any of those situations.

Mojito の背景となるアイデアとは、多様なデバイス上で動作する JavaScript ベースのアプリケーションを、デベロッパーが構築できるようにするものだ。そして、低電力デバイスという制約と、ネットワークにおけるピークという、モバイル Web に固有の問題に対処していく。そして、デベロッパーは、Web/Mobile Web/Native App のフレームワークを選択するというのではなく、あらゆる状況でも適切な性能を発揮する、ハイブリッド・アプリケーションの作成を可能にしていくだろう。

Image(240)

It does that by giving developers the ability to blur the lines between building for client-based processing or server-based processing. Mojito apps can run on the client, using the device’s JavaScript engine, or it can run on the server via Node.js. That makes app development a little more flexible and modular than it previously had been.

こうした開発環境は、クライアント・ベースの処理と、サーバー・ベースの処理を切り分けるラインを、デベロッパーが曖昧に取り扱えるようにすることで達成される。 Mojito アプリケーションは、デバイス上の JavaScript エンジンを用いてクライアント上で実行することが可能であり、また、Node.js を介してサーバー上でも実行できる。それにより、アプリケーショ開発は、以前よりも柔軟性を持ち、また、モジュール化も促進される。

To see the results, you can check out a number of Yahoo apps that leverage Mojito. Those include Yahoo! Livestand, a native app; Fantasy Finance, a Web site; and Fantasy Premier League Football, which is a mobile Web app. Or you can build your own, as Yahoo’s Mojito is now available on GitHub.

その成果を確認するために、Mojito を活用する数多くの Yahoo アプリケーションをチェックすることが可能だ。そこには、Yahoo 自身も含まれる! ネイティブ・アプリとしての Livestand や、Web サイトとしての Fantasy Finance、そして、Mobile Web アプリとしての Fantasy Premier League Football などがある。 あるいは、あなた自身のアプリを構築することも可能だ。 つまり、すでに GitHub 上、 Yahoo の Mojito が提供されているのだ。

Related research and analysis from GigaOM Pro:

ーーーーー

Image(216)

Image(241)以前に、Mobile BaaS(Backend-as-a-Service)マーケットについて、Appcelerator による Cocoafish 買収から探るという記事をポストしました。 その時に、いわゆる Service Provider/IaaS/PaaS といった、エコシステムの基盤として馴染みのあるプラットフォームとは、まったく違う世界から新しい勢力が勃興しているのを目の当たりにしました。 そして、今度は Yahoo までに名乗りを上げてきたわけで、デベロッパー環境が戦国時代化している様子が、お分かりいただけると思います。 ーーー Image(13)

ーーーーー

<関連>

AppMobi の狙いは、Mobile + OSS + HTML5 の惑星大直列なのだ!
Qualcomm への挑戦を、日本勢は諦めてしまったのか?
デベロッパーたちは Android に飽きてしまったのか? – IDC の調査
この世で いちばん 不公平な比較 – iPhone 4 vs. IBM PC

Comments Off on Yahoo の Mojito は、あらゆる Mobile デバイスに対応する OSS Dev プラットフォームなのだ

モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう

Posted in .Selected, Apple, BaaS, Google, Microsoft, Mobile, Post-PC by Agile Cat on February 17, 2012

Appcelerator buys mobile backend provider Cocoafish
http://wp.me/pwo1E-3Vx
By
Ryan Kim Feb. 9, 2012
http://gigaom.com/mobile/appcelerator-gobbles-up-mobile-backend-provider-cocoafish/

_ Gigaom

Appcelerator, which helps developers build native and HTML5 mobile apps, has been on an acquisition tear in the past year and has added mobile backend provider Cocoafish on Thursday to fill out its offering. The pickup, which follows Appcelerator’s purchase of Aptana and Particle Code last year, gives the company a robust cloud infrastructure provider and helps it appeal even more to its 1.6 million developers. Terms of the deal were not disclosed.

Appcelerator は、HTML5 対応のネイティブ・モバイル・アプリケーションを開発する、デベロッパーたちをサポートしている。そして、これまでの 1年間は企業買収のステージにあり、木曜日(2/9)にはモバイル・バックエンド・プロバイダである Cocoafish を、ラインナップに加える手続きを完了した。 この Appcelerator が進める買収は、昨年の Aptana と Particle Code に続くものであり、同社のクラウド・インフラストラクチャ・プロバイダを強化し、また、その 160万人のデベロッパーにアピールするものとなった。 ただし、その取引の内容は発表されていない。 

クリックで拡大 ⇒

Cocoafish, founded in 2010 in San Francisco by Michael Goff and Wei Kong, is part of an emerging class of mobile backend providers that includes Stackmob, Parse, Kinvey and others that are helping developers add cloud-based features to their apps. Cocoafish services such as push notifications, social integration, sharing, location and others will be integrated into the Titanium Platform by early in the second quarter. Appcelerator said it will also offer iOS, Android, JavaScript and REST SDKs so that these services can be accessed by all mobile app developers, regardless of what technologies they use, such as Objective-C, Java, PhoneGap, Sencha and HTML5.

Cocoafish は Michael Goff と Wei Kong により、2010年に San Francisco で設立された。同社は、Stackmob や、Parse、Kinvey などで構成される、新興モバイル・バックエンド・プロバイダの一角であり、アプリケーションにクラウド・ベースの機能を加えるデベロッパーたちを支援してきた。Cocoafish が提供する、プッシュ通知/ソーシャル統合/共有/ロケーションといったサービスは、今年の Q2 早々に、Titanium Platform に統合されるだろう。 Appcelerator の発言によると、iOS/Android/JavaScript/REST の SDK を提供することで、Objective-C /Java/PhoneGap/Sencha/HTML5 といったテクノロジーを用いる、すべてのモバイル・アプリケーション・デベロッパーが、それれらのサービスにアクセスできるようになる。

Why the acquisition makes sense

Appcelerator’s acquisition of Cocoafish is logical, as it looks to become the go-to resource for developers and companies building cross-platform apps. In its latest developer survey, Appcelerator found that 84 percent of its developers connected to cloud-based services. But almost all of them were manually adding these services themselves. That can double the time it takes to launch an app.

クロス・プラットフォーム・アプリケーションを構築するデベロッパーと企業のための、主力のリソースを目指す上で、Appcelerator による Cocoafish 買収は論理的なものとなる。 デベロッパーに対する最近の調査で、その 84 % がクラウド・ベースのサービスに接続していることに、Appcelerator は注目している。 そして、その大半が手作業により、それらのサービスを加えていることも分かった。 つまり、アプリケーションの立ち上げまでに費やす時間が、2倍になっていた可能性がある。

Now Appcelerator can offer a full suite of front-end and backend solutions for developers with Cocoafish integrated into Appcelerator’s Titanium Studio. And by opening iOS, Android, JavaScript and REST SDKs, it means that Appcelerator could also appeal to developers who don’t use its Titanium Platform. That can drum up even more business, though it pits Appcelerator against a number of competitors in the mobile development services market. But it looks like there is still a lot of business to be had. Kinvey did a survey of apps on iOS and Android in September and found that 73 percent didn’t connect to a backend.

しかし、いまでは、 Cocoafish を Appcelerator の Titanium Studio に統合することで、デベロッパーに対してフロントエンドとバックエンドの、完全なソリューション・スイートを提供できる。 そして、iOS/Android/JavaScript/REST の SDK をオープンにすることで、Titanium Platform を使っていなかったデベロッパーに対しても、Appcelerator はアピールできるようになった。それにより、さらに多くのビジネス機会が生じるが、モバイル・サービス市場における数多くのコンペティタと、Appcelerator は戦っていくことになる。 ただし、そこには、まだまだ沢山のビジネス・チャンスがあるようだ。 昨年の 9月に Kinvey が行った、iOS と Android のアプリケーションに関する調査では、73% がバックエンドに接続していない状況が明らかになっている。

クリックで拡大 ⇒

Connecting apps to cloud services can still be tough, but it usually provides more engaging features. That is increasingly important for app developers, who need to create more-dynamic apps that keep users involved. User engagement and attention is the name of the game in the mobile app world, in which users are quick to try then discard apps. The purchase of Cocoafish also raises the question of whether we will see more consolidation in this nascent market as potentially other Platform-as-a-Service offerings or other companies look to add mobile support. For Appcelerator, which raised $15 million in November, it is another sign of momentum as it capitalizes on the boom in mobile apps.

アプリケーションとクラウド・サービスとの接続は、依然として困難を伴うこともあるが、通常では、その引き替えとして、さらに魅力的な機能を提供できるようになる。 ダイナミックなアプリケーションを開発し、ユーザーを惹きつけるべきアプリケーション・デベロッパーにとって、それらの魅力的な機能に対する重要度が増している。 アプリケーションの試用と削除が簡単なモバイル・アプリケーションの世界では、ユーザーの注目を引き留めておくことが、きわめて重要なポイントとなる。 そして、Cocoafish の買収により、さらなる垂直統合が発生するかもしれない。 つまり、この黎明期のマーケットにおいて、これまでとは別種の PaaS が提供される可能性や、新規参入の可能性が生じるとも考えられる。 そこに、11月に $15 million の資金を集めた Appcelerator が、勢いに乗ってモバイル・アプリ・ブームをフル活用する、もう 1つの理由がある。

Curious about how the backend-as-a-service market fits into the larger mobile market? Take a look at this helpful chart worked up by Kinvey.

この BaaS(Bbackend-as-a-Service)マーケットが、どのようにして大規模モバイル・マーケットにフィットするのか、知りたいだろう? Kinvey が段階的に仕上げてきた、このチャートを確認して欲しい。 とても有用だと思う。

Related research and analysis from GigaOM Pro:

ーーーーー

TAG index最初は、このインフォグラフが気になって、注目し始めたポストですが、記事の内容もとても興味深いものでした。iOS や Android や Win Phone などにおいて、それぞれのアプリケーションが、プッシュ通知/ソーシャル統合/共有/ロケーションといったサービスを必要とするはずです。 それなら Mobile BaaS(Bbackend-as-a-Service)で、まとめて面倒みましょうというのが、この Appcelerator や Cocoafish のコンセプトなんですね。 そして、このインフォグラフですが、パックマンまで友情出演していて、ほんとうに面白いです。 どれくらう面白いかというと、1920 x 1200 まで引っ張って、壁紙にしてしまったくらいです 🙂 ーーー ac-stamp-25

ーーーーー

<関連>

ついに Apple は iPhone 単独で、Microsoft の全てを追い抜いてしまった!
Android アプリが 40万 タイトルに到達した!
Ray Ozzie が帰ってきた! iOS と Android を引き連れて
10億台の HTML5 フォンが、モバイル・アプリ・ビジネスを変えていく
最適な MDM(Mobile Device Management)ポリシーを構成するためには?
Carbyn の HTML5 OS は、未来を見せてくれるのか?
コンシューマ と エンタープライズ の、IT 交差点 は存在し得るのか?

Comments Off on モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう

%d bloggers like this: