JavaScriptのためのパッケージマネージャnpmが$8Mを調達、企業向け有料サーバとプライベートモジュールをローンチ

4772680734_489299f43f_o

JavaScriptデベロッパには、 Isaac Schlueterが作ったパッケージマネージャnpmのことをよく知ってる人が多い。でもnpmが、npmプロジェクトをサポートする会社の名前でもあり、Schlueterがそこの協同ファウンダであることは、あまり知られていない。今日(米国時間4/14)同社は、2月のTrue Ventures率いるラウンドによる260万ドルのシード資金に加えて、新たに800万ドルの資金を調達したことを発表した。

今回のリード投資家はBessemer Venturesで、BessemerのパートナーEthan Kurzweilがnpmの取締役会に加わった。

Schlueterは、Node.jsのファウンダRyan Dhalが2012年に辞めて以降、2014年までNode.jsプロジェクトの管理も務めた。そしてその間、多くの投資家たちに、npmへの投資を打診してきた。その際、投資家たちにはNode.jsとnpmについて一から説明しなければならなかったが、Bessemerだけは前からNodeへの投資に関心があり、その流れでnpmへの投資にも乗った。

シード資金を獲得してから最初にnpmがローンチした、初めての有料ツールがnpm Enterpriseだった。それは企業がファイヤーウォールの背後でパッケージマネージャを動かし、セキュアにJavaScriptのモジュールを共有できる、ユーザ一人あたり月額20ドルのサービスだ。

今日同社は、npmモジュールをプライベートに保ちたいデベロッパのための類似のホスティングサービスを立ち上げた。そのコンセプトは、GitHubが企業向け以外からサービスの収益化を図ろうとしているやり方に似ている。GitHubの場合と同じく、npmのリポジトリ内のプロジェクトはデフォルトではパブリック(一般公開)だ。しかし月額7ドルでデベロッパは自分のモジュールをプライベートにでき、同じく有料のユーザとのみアクセスをシェアできる。ファイヤーウォールを使わない小企業などでは、これにより容易にnpmを利用でき、複数のプロジェクト間でコードを再利用できる。

Schlueterによると、プライベートなレジストリはnpmのユーザからいちばん要望の多い機能だったが、複数のユーザのプロジェクトが同社のサーバ上にある場合のセキュリティ、とくにデータの保護の実装にかなりの時間を要した。

今回の新たな資金は、npmのプロダクトロードマップを前進させるための社員増に充てられる(現在は11名)。Schlueterは、デベロッパの生産性について、こう考えている: “うちのレジストリを240万人のユーザが毎日のように使っているのだから、確実な信頼性が必要であり、それを担保するためには人が要る。少ない社員を酷使するよりは、‘持続可能な’形の会社にした方がよい”。

そこでnpmの求人サイトにも、“初期段階のスタートアップにありがちな‘仕事も徹夜/遊びも徹夜’タイプは要らない”、と書かれている。“成功に向かうための最良の道は、自分と家族とユーザと、そしてお互いをたいせつにすることから始まる”、のだと。残念ながら今のスタートアップがこんな家訓を守るのは難しいが、でもSchlueterは、それこそが成功の基盤だと信じている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Googleは”モアベターなJavaScript”をねらったDart言語をChromeでサポートしないことに決定

DartはChromeに来ない、とGoogleは今日(米国時間3/25)発表した

Webの標準語はJavaScriptだが、DartはGoogleがそのJavaScriptをリプレースするためにローンチした言語だ。Googleによると、Dartには静的型付け(static typing)をはじめ、デベロッパに歓迎される高度な機能が揃っている。

最初は、GoogleだけでなくそのほかのブラウザにもDartをサポートしてもらうつもりだったが、現状はGoogleのChromeすら、特別のビルドがやっとサポートしているぐらいだ。

“Google Chromeに限定されず、ユーザとWebにとってのベストを求めるなら、DartをJavaScriptへコンパイルする道を選ぶべきだ”、Dartの協同ファウンダLars BakとKasper Lundが今日そう書いている。“そこで、Dart VMをChromeに統合しないことに決めた”。

DartではDartで書いたコードをJavaScriptへコンパイルできるから、今後何か新しいことが起きるわけではない。でもこれまでは、遅かれ早かれGoogleがDartを直接ブラウザに持ち込む、という期待があった。BakとLundによれば、“Dartのためにより明確な戦略を採る”、ということのようだ。

Googleの内部では、さまざまなチームがおよそ100万行ものDartのコードをメンテしているから、Googleがこの言語を放棄することは当面ありえない。BakとLundによると、とくにGoogle Adsのチームがこの言語に継続的にコミットしている。

Adsの技術担当VP Scott Silverは今日の声明の中でこう書いている: “われわれは今、次世代のWebアプリケーションをDartで書くことに注力している。そして、Dartから最良のJavaScriptを生成することに今日あらためて焦点が当てられたことは、Dartユーザであるわれわれが、現代的ブラウザを使うすべての人たちに、最良のアプリケーションを提供できることを意味する。Dartによってわれわれの部門の技術者たちの生産性が大幅に向上し、繰り返される開発と立ち上げのサイクルを早めることができた”。

とは言うものの、今日の発表はこの言語の未来に関して、不安を感じさせる。今日のHacker Newsでは多くのコメントが、DartはJavaScriptの最新バージョンの開発に大きな影響を与えた点では成功と言えるが、明らかにGoogleはこの言語に関して、もっと大きなプランを持っていたのだ、と指摘している。

そのほかのブラウザベンダ、とりわけMozillaは、Dartを採用していないし、またデベロッパは、一つのブラウザでしか動かない言語でアプリケーションを書きたくはない。今後のDartは、CoffeeScriptやTypeKitなどと並んで、“JavaScriptへコンパイルされる言語”の仲間入りをするのだろう。

関連記事。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa


Angular 2フレームワークとTypeScript言語でMicrosoftとGoogleが協働

宿敵と思われているMicrosoftとGoogleが、実は意外にも、JavaScriptでWebアプリケーションを書くためのGoogleのMVCフレームワークAngularJS(略称“Angular”)の、(反対意見少なからある)次期バージョンAngular 2で互いに協力している。

Angularはかなり前から、MicrosoftのTypeScriptのスーパーセットAtScriptを使っている。TypeScriptはJavaScriptを拡張しようとするMicrosoftの試みで、タイプアノテーションやジェネリック、モジュールなどの機能がある。いずれ、この二つの言語は一本化するのだろう。Angular 2はTypeScriptで書かれ、デベロッパはAngular 2のアプリケーションをこの言語で書くこともできる。

AtScriptが言語としてデビューしたのは昨年の10月だが、今後はAtScriptという名前は消えて、TypeScriptに統一されるようだ。

Angularは、最初JavaScriptで書かれ、その後はGoogleのDart言語やAtScriptで書かれたりした(Angular 1.xのDartバージョンやJavaScriptバージョンは今でも現存する)。AtScriptはTypeScriptに、イントロスペクション(introspection)やフィールドアノテーション、メタデータアノテーションなどの機能を加えている(上述)。で、今度はTypeScriptが、次の1.5からこれらの機能を取り入れる。そのベータのローンチは数週間後だ。

Microsoftのデベロッパ担当VP S. “Soma” Somasegarが、今日(米国時間3/5)の発表声明の中で次のように書いている:

“Angularのようなリッチなライブラリと密接に協働することにより、TypeScriptの言語機能も充実し、エンドツーエンドのアプリケーション開発がより容易になった。たとえばクラスの宣言にメタデータを加えるアノテーションを、依存性注入(dependency injection, DI)やコンパイラディレクティブのために利用できる。両者はこれからもTypeScriptとJavaScriptを将来的に一本化するための努力を続け、いずれは型付言語としてのJavaScriptのスタンダードとしてECMAScriptが採用するよう、働きかけていきたい”。

Angular 2はAngularの旧バージョンとの互換性が完全でないので、デベロッパコミュニティからの批判がとても多い。Microsoftが作った言語を使うことも、一部の人たちは気に食わないようだ。でもこれは明らかにTypeScriptの勝利であり、しかもそれは、昨年1.0がリリースされて以来、着実にユーザ数が増えているのだ。

この発表は、今日ユタ州ソルトレイクシティで行われたAngularカンファレンスng-confで行われた。そのときのビデオをご覧いただこう(TypeScriptの説明は20:00あたりから):

[原文へ]
(翻訳:iwatani(a.k.a. hiwa


GoogleがJavaScriptベンチマークOctaneをアップデート, asm.jsとTypeScriptもテスト対象に

Googleが同社のJavaScriptベンチマークスイートOctaneのバージョン2.0をリリースした。Octaneは17のテストにより、ブラウザが実装しているJavaScriptランタイムの実行速度を計測する。

最初のバージョンが出たのは1年あまり前だが、今度のバージョンではレイテンシの計測にとくに力が入れられた。また、JavaScriptの新しい技術の数々もテストされる。また2.0では、MozillaによるJavaScriptのサブセットasm.jsで書かれコンパイルされたコードへの、ブラウザの対応もテストできる。また、MicrosoftのコンパイラTypeScriptのテストも加わり、実行速度、コードパーサの性能、ブラウザのメモリサブシステムなどを測定する。

Googleがasm.jsをサポートしたことは、興味深い。このプロジェクトは、ブラウザ内のJavaScriptのパフォーマンスをネイティブコードのそれに近づけるMozillaの試みで、これをバージョン22以降搭載したFirefoxは、JavaScriptの実行速度でChromeを上回った(2012年のMacbook Airの上で2.5倍)。

Googleはasm.jsのパフォーマンスを測定するために、MozillaのテストスイートEmscripten用のサンプルコードzlibを使用している。Google自身はasm.jsの公式サポートに関心を示さず、すべてのJavaScriptをできるかぎり高速に走らす、という姿勢を固持している。そのGoogleが自社のベンチマークにasm.jsを加えたということは、このプロジェクトを相当意識している証拠だ。Chromeにおける‘できるかぎり高速に走らす’の対象に、いずれasm.jsも含まれるのかもしれない。

これらのほかに、Googleの技術者たちと“レイテンシ退治屋”Hannes Payerによると、既存のベンチマークにも多くの手を加え、“それらが意図したとおりの測定を行う”ために改良した。既存のベンチマークとは、GameBoyエミュレータ、正規表現テスト、OctaneのCodeLoad、DelataBlue、NavierStokesテストなどだ。テストの全容とそれらの説明を、ここで見られる。

ぼくのMacbook Airの上で非公式に試してみたところ、Firefox 25とSafari 7.0では得点が10000強、対してChrome 30では14000強だった。またSurface Pro + Internet Explorer 11では約8500点、Chrome 30はやはり14000点となった。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


ブラウザ内のJavaScriptからAWSにアクセスできるSDKをAmazonがローンチ…サーバサイドのコードはいっさい不要

Amazonが今日(米国時間10/31)、AWS SDK for JavaScriptのデベロッパプレビューをローンチした。これによりデベロッパは、ブラウザからAWSのサービスにアクセスするダイナミック(動的)なJavaScriptアプリケーションを容易に作れるようになり、しかもその際、サーバサイドのコードを書いたり、アプリケーションサーバのホスティングのための構成を、いっさいする必要がない。

Amazonは前にもSDK for Node.jsをローンチしているので、JavaScriptをサポートするのは今回が初めてではない。というより実は、この新しいSDKもブラウザ内およびサーバサイドのNode.jsコードにおける、同じプログラミングモデルを使用している。

このSDKを使うとデベロッパは、AmazonのS3ストレージサービスを直接呼び出したり、メッセージキューSQSにリード/ライトしたり、SNSでモバイルの通知を生成処理、NoSQLデータベースDynamoDBにアクセス、などなどのことができる。Amazonの従来からあるデータベースサービスへのアクセスは、当面サポートされない。いずれにしてもデベロッパは、人気の高いS3ストレージのバケットを作ったり、DynamoDBのテーブルをクェリしたりするJavaScriptアプリケーションを、サーバサイドのコードを使わずに作ることができる。

SDKの使い方は、AmazonのJavaScriptライブラリを指定するタグを付けたコードを書くだけだ。このSDKはAmazonのWebアイデンティティフェデレーション機能(Web identity federation feature, Web ID連携)をサポートするので、HTMLやJavaScriptのコード内にAWSの認証情報を書く必要はない。したがってFacebookやGoogle、そしてもちろんAmazon自身など、本人性証明を一般に公開しているサイトの認証を利用できる。

例によってAmazonの新機能はセットアップがやや面倒だが、でも豊富なチュートリアルがすでに用意されているので、とっつきは悪くないと思う。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


物のインターネットをJavaScriptで動かせるDIYボードEspruinoがKickstarterで資金募集中

Arduinoはすばらしいけど、初心者が手を出すには少々難しい。Espruinoは、“世界で初めてのプロアマ両用のJavaScriptマイコン”としてここ2年ほど一部のマニアたちに人気があったが、イギリスのケンブリッジに住む作者のGordon Williamsは、これをさらに磨き上げるためにこのたびKickstarterに登場させた。

Kickstarterで資金募集を開始したWilliamsの目的は、このオープンソースのハードウェアのためのソースコードを完成させて、正規のオープンソースコードとしてリリースすることだ。EspruinoプロジェクトのページでWilliamsは、Kickstarterに‘上場’したもう一つの目的は、Espruinoのソフトウェアをプレインストールしたボードを発売して、買った人がすぐにプログラミングを開始できるようにすること、と言っている。

このような、“物のためのJavaScript”というコンセプトは、デバイスが実際に目的どおりに動くようになるまでの過程を大幅に単純化するから、ハードウェアハッカーにとっては大歓迎だ。Williamsは、LEDを点滅させるだけ、という簡単な例で、EspruinoとArduinoを比較している。後者は、こんな簡単なものでもコードはかなり複雑になる。EspruinoのJavaScriptは、Web開発をちょっと経験した者には親しみやすいだけでなく、変更も拡張も容易にできる。Arduinoでは、同じことをやるために大量の作業が必要だ。

Williamsはソフトウェアデベロッパで、過去にAlteraやMicrosoft、Nokia Collbaoraなどで仕事をした経験がある。そして今は自分の会社で、音楽を3Dで視覚化するソフトMorphyreを作ってている。彼はケンブリッジ大学のコンピュータ科学出身だが、ハードウェアDIYのマニアでもある。彼がEspruinoを作ったのも、イベント駆動型のプログラミングにより、彼と同じ楽しみを分かち合える人びとを増やしたいからだ。

これを欲しい出資者は19ポンド以上を出す。発売予定は2014年の1月だ。Williamsは、ハードウェアの製作では経験豊富なので詳細な生産計画もすでに作ってある。出資額の多い人には、低電力消費の無線ラジオや多色LEDライトなども提供される。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


MozillaとEpic GamesがUnreal Engine 3をWeb化, Web 3DゲームのFlash不要化へ

2011年にEpicは、好評なUnreal Engine 3の技術をFlashにポートして、ブラウザでもかなり高度な3Dゲームができることを示した。しかし2013年の今では、Flashはもう人気のプラットホームではない。そこで、現代的なブラウザではプラグイン不要でどれだけのことができるかをゲームデベロッパたちに示すために、MozillaとEpicが協力してUnreal Engine 3をWebにポートした。Flashプラグイン全盛の2011年には、考えられなかったことだ。

Mozillaの技術部長でWebGLの発明者でもあるVladimir Vukicevicが今週の初めに語ったところによると、MozillaはWebを現代的なゲームにとって十分有効なプラットホームにしたいと考えている。約半年前にMozillaは、そのemscriptenコンパイラを使ってCやC++のコードをJavaScriptのサブセットであるasm.jsにポートすることができるようになった。それによってJavaScriptのコードはネイティブコードの約2倍近い速さになり、この方法による最適化はFirefox Nightlyの最新バージョンがサポートしている。現代のゲームとゲームエンジンは複雑だから、ネイティブに近い速度をWeb上でも実現できることは、たとえばEpicの有名なデモCitadelやUnreal Tournamentを動かすことに欠かせない。今日行われたGame Developers ConferenceでMozillaは、Unreal Tournamentをブラウザ内でネイティブに動かして見せた。

Unreal 3 Engineの全体をWebに移植するのにEpicは4日を要し、その後小さな調整作業も行った、とVukicevicは述べている。Epicが同社のゲームエンジンをWebに持ち込むのはこれが初めてではないが、それにしても上々の結果だった。デモは数週間後にお目見えする。それまでは、最新のFirefox Nightlyの上でMozilla作のBananaBreadデモを見て我慢しよう。Web用のUnreal Engine 3をEpicが商用製品として提供するのか否かについては、まだ不明だ。

Mozillaのゲームプラットホーム担当Martin Bestによると、今回の作業の結果はすべて、MozillaのAndroid用モバイルブラウザと、そしてもちろんFirefox OSに実装される。モバイルでもゲームはネイティブの2倍近い速さで動くとMozillaは予想しており、それを示す社内的なデモもすでにある。一般公開は、まだ先のようだが。

これらの技術を使った商用製品を作っていくことに関してBestは、MozillaはすでにDisneyやElectronic Arts、ZeptLabなどと共同で作業を進めている、と言った。ZeptLabはすでに、Microsoftとの協働によりCut The RopeのHTML5バージョンを作ってWeb上に持ち込んでいる。Bestによると、このような協働案件を打診すると最初はどの企業も疑心暗鬼であるが、“一週間もするととても熱心なパートナーになってしまう”そうだ。

Googleも、ブラウザをネイティブの速さに近づけることに、Native Clientを通じて努力している。これは、デベロッパが作ったWebアプリケーションがコンパイルされたネイティブコードをブラウザ内で実行できる、という技術だ。GoogleのChrome Web Storeには、そのようなゲームがすでにかなりある。しかしMozillaのCTOでJavaScriptの作者でもあるBrendan Eichの言では、Firefoxがそのような技術をサポートすることは短期的にはない。むしろ彼の考えではJavaScriptの今後の進化でネイティブに近いパフォーマンスが達成されるだろう、という。Eichの見方では、Native Clientは“Webとは別のもの”だ。APIも、WebのAPIとは言えない。だからそれは、Mozillaが志向しているものとは違う。Mozillaは、Webそのものを前進させることにのみ、関心がある。

Asm.jsのコードの良いところは、それがあくまでもJavaScriptであることだ。だからどのブラウザでもそれは動く。しかしAsm.js向けに最適化されたブラウザなら、相当に速い。Eichによると、いずれはどのベンダも〔Googleも?〕、遅かれ早かれ、その最適化を実装するだろう、とのことだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


JavaScriptは今, 豚から豹に変身中: 最先端の言語改良努力をMLOC.jsカンファレンスに見る

[筆者: Péter Halácsy]

編集者注記: Péter HalácsyはPreziの協同ファウンダでCTOだ。Twitterで彼をフォローするには、@halacsyで。

スタートアップはJavaScriptが好きだ。あなたが駆け出しの若造なら、ダイナミックであることが必要だ*。柔軟性も必要だ。とりあえず動くプロトタイプを素早く作れることも必要だし、コードをコンパイルせずにその場で書き換えられる能力も必要だ。JavaScriptはかつて、ブラウザ戦国時代のスタートアップだった。やがてJavaやFlashを圧倒してしまったが、それはスタートアップが市場をディスラプトして既製勢力を追ん出したのと同じ理由からだ。すなわち、アジリティ(敏速性)と柔軟性。〔*: ここでのdynamicとは、コードを書いたらそれが即動くという言語…インタープリタ言語やJIT言語…の使用の意。〕

今日、JavaScriptはもはやスタートアップではなく、またそれを使っているのはもはやスタートアップだけではない。あらゆるサイズの企業が、Webアプリケーションを作る腕前の上手下手を問わず、どこでも/誰もがJavaScriptでアプリを作っている。かつてはC/C++やJavaのような言語に殺到した需要が、今ではJavaScriptに集まり、そして需要のこのようなシフトは言語の限界を露呈している: パフォーマンスとメンテナンス性だ。

最新世代のJavaScriptエンジンはパフォーマンスがすごく向上しているが、でもまだ十分ではない。YouTubeやHuluのようなサイト、それにFacebookやEAのゲームプラットホームを見てみよう。高いパフォーマンスを要求されるマルチメディアのアプリケーションでは、いまだにFlashが使われている。Steve Jobsのご神託がFlashの命運を告げても、JavaScriptのパフォーマンスが劣るかぎりは、使い続けざるをえない。〔PreziはFlashベース。〕

あなたのコードベースが数十万行のオーダーに達し、しかもそれがすべて、JavaScriptのようなダイナミック言語で書かれていたら、開発のペースは牛歩する。コードベースのどこかを書きかえたとき、それが別のところにバグを導入していないか、それは実際にアプリケーションを動かしてみないと分からない。事前の試験には限界がある。ありとあらゆる、予期せぬ事態が起こりえる。バグが累積し、納期は延びる。

誰かがこれらの限界や制約を解決して、Webアプリケーションのこれからのイノベーションを導く必要がある。誰が、どうやって、それをやるのか?

JavaScriptは自分が作った鉄の三角形に囚われている。

PreziとLogMeInとUstreamが、JavaScriptをどうやってスケールするかをテーマとするカンファレンスMLOC.jsを開催した。GoogleやFacebookやMozillaやGrouponなどで毎日のように、問題解決に苦闘している連中が三日間、ブダペストの会場に集まり、JavaScriptの限界/制約対策について話し合った。彼らの努力で、JavaScriptは未来の言語として生き残るだけでなく、Webアプリケーションの書き方も今とは違ったものになるだろう。

今のぼくの見方はこうだ: JavaScriptは自分が作った鉄の三角形に囚われている。ぼくらはJavaScriptの柔軟性と自由に慣れてしまって、それを捨てたくない。しかし同時に、それは爆速であったほしい。JavaScriptは、コードが何百万行にもなると、その柔軟性ゆえにメンテナンスが困難になる。柔軟性とパフォーマンスとメンテナンス性、この三つは互いに入り組んでいる。一つを進歩させたら、他の二つのどちらか、あるいは両方が苦しむ。

たぶん特効薬は一つではなく、複数の組み合わせだろう。JavaScriptはダイナミック言語として、Webのための優れた糊だ。そのことは、変わるべきでない。

コード以前に、ビジネスロジックが正しくないとだめだ。またDartやTypeScriptなどの静的分析ツールは、アプリケーションのいちばん難しい部分が…今後のアップデートにもめげず…正しく動くために欠かせない。静的分析ツールは、もっと進化してもいい、とぼくは感じている。ただしその技術を幅広く、ブラウザがネイティブでサポートするのは、まだまだ先の話だろう。

ブラウザが新しい言語をネイティブでサポートすることは、必ずしも必要ではない。MozillaのAlon Zakaiが紹介したASM.jsはJavaScriptのサブセットで、現代的なブラウザの上で何も変更せずにものすごく高速に動く。スピードが重要なら、ASM.jsで書こう。Cで書いてコンパイラがASM.jsを作りだす方式でもよい。このテクニックは、パフォーマンス以外のほかの方面にも応用できそうだ。デベロッパたちはすでにそれをやっているし、彼らの努力はatl.jsにまとめて載っている。

さて、メンテナンス性の良いコードを書く最良の方法は、なるべく少なく書くことだ。bacon.jsのようなライブラリやElm言語は、複雑なデータ依存性を簡潔に表現し、デベロッパがデータの形をライブラリに合わせる努力をなくす。その結果、コードの量が少なくなり、メンテナンス性の良い高品質なアプリケーションになる。

JavaScriptは、消えてなくなりはしないが、今、変身中だ。デベロッパたちはこの言語の変種や、表現力の豊かなライブラリを作って、特定のユースケースをより扱いやすくしている。パフォーマンスへの要求も含めて。ツールと静的分析も、進歩している。これらのトレンドが全部合わさって、Webアプリケーションの書き方を変えつつある。MLOC.jsが終わったら、いよいよ本格的に始動する。

JavaScriptを毎日のように書いている大企業のみなさまもぜひ、この言語の柔軟性とパフォーマンスとスケーラビリティを大きく増すために、貢献していただきたいと思う。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))