Node.js | SEO-LPO.net

Googleがモバイルコンテンツ高速化技術AMPをOpenJS Foundationに持ち込む

モバイルのウェブをスピードアップするGoogle（グーグル）のプロジェクトであるAMPは、やや批判もあったが、一貫してオープンソースであるにもかかわらずGoogleの影がつきまとっていた。しかし米国時間10月10日にGoogleは、AMPフレームワークがOpenJS Foundationに加わると発表した。このLinux Foundation傘下のグループは昨年、Node.jsとJSの両ファウンデーションの合併により誕生した。OpenJS Foundationは現在、jQuery、Node.js、webpackなどの本拠地で、AMPはこのファウンデーションのインキュベータ事業に加わる。

Googleのような大企業は、安定に達したオープンソースのプロジェクトをファウンデーションに寄贈する傾向がある。今年で4歳になるAMPプロジェクトもまさにそのケースに相当し、Googleによると今ではそれは、3000万以上のドメインで数十億のページの制作に使われている。昨年GoogleはAMPの開発を監督するTechnical Steering Committee（技術的方向性委員会）を立ち上げたが、その委員会はプロジェクトをOpenJS Foundationに持ち込むことで合意していた。

そのTechnical Steering CommitteeのメンバーMalte Ubl（マルテ・ウブル）氏が本日の発表声明で次のように述べている。「今年で4年になるAMTがその旅路の次のステップに進むことは極めて喜ばしい。このところ私たちは、AMPに最良の家を与えることを考えていた。OpenJS Foundationに決めたのは、当委員会の多様なメンバーのお世話をするために最適の場所だからだ。このステップは、オープンな統治に向かうこの前のステップの次の一歩であり、これにより透明性とオープン性に一層フォーカスできるようになる」。

Googleによると、JavaScriptとその関連技術の振興を目標とするOpenJS Foundationは、「ウェブのコンテンツにユーザーファーストのフォーマットを提供する」AMPのミッションと相性がいい。また同社によると「同ファウンデーションではプロジェクトのアイデンティティと技術的フォーカスを維持でき、またAMPの統治モデルはすでにJS FoundationとNode.js Foundationからの影響でできたことを強調したい」という。

Googleは今、OpenJS Foundationの最上位の会員種別であるプラチナ会員であり、AMPプロジェクトのサポートを継続するとともに、AMPにフルタイムで関わるエンジニアを数名起用する。

画像クレジット: Google

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

Node.jsとJSが合併の意向を共同発表――JavaScriptコミュニティーの統合を図る

現在、JavaScriptの有力なオープンソース団体は2つある。2016年設立のJS Foundationと2015年設立のNode.js Foundationだ。JS Foundationの目的はJavaScriptを中心とするエコシステム全般の育成にあるのに対して、Node.jsは名称からも明らかなようにNode.jsテクノロジーを中心としてGoogleのV8エンジンなどの助けを借りながらサーバーサイドでJavaScript言語を活用していこうとするものだ。この2つの団体は合併を検討していることを明らかにした。

合併はまだ確定したわけではなく、両組織はそれぞれのコミュニティーからのフィードバックを得ようとしている。まずはNode+JS Interactiveカンファレンスで直接に、またオンラインでもQ&Aセッションを設けて、多くの質問に答えていく計画だという。今日（米国時間10/4）の共同声明には次のように述べられている。

合併は両組織の技術的独立性や自治に変更を与えるものではない。Node.jsやAppium、ESLint、jQueryを始めとするJS Foundationの28のプロジェクトはすべてこれまでどおり運営される。JavaScriptは柔軟なプログラミング言語であり、ウェブのバックボーンという当初の役割をはるかに超えて発展している。新しい分野にはIoT、各種ネイティブ・アプリ、DevOps、各種プロトコルなどがある。JavaScriptのエコシステムはブラウザからサーバーへ、デスクトップから組み込みデバイスへと現在も拡大中だ。こうした中でエコシステムの健全な発展を助けるためにメンバーが共同作業する重要性はさらに高まっている。

エコシステム全体を通じて共同作業の重要性が増していることがこの合併のそもそもの動機だろう。Linux Foundationの戦略的プログラム担当バイスプレジデント、Mike Dolanは声明で「JavaScript 団体のリーダー、重要な知的財産を保有する企業など、コミュニティーがさらに緊密に活動していくくとが団体の活動分野を広げると同時にNode.jsと各種のJavaScriptプロジェクトを一層助けることになると革新している」と述べている。

合併の最終目標は「運営の優秀性をさら強化することによってJavaScriptエコシステム全体の協調性を増し、あらゆるJavaScriptプロジェクトの本拠となれるような単一組織を立ち上げる」ことだという。

コミュニティーの賛成が得られるのであれば、両組織がLinux Foundationの傘下にあることは合併を推進し組織の統合を図る上でなにかと有利だろう。両方の組織に加盟しているメンバーもいるが、その数は予想より少ない。たとえばIBMは両組織のプラチナ会員だが、,GoogleはNode.JSのプラチナ会員でJS Foundation.のスポンサーにはなっていない。逆にSamsungはJS Foundationのトップレベル・スポンサーだがNode.JS Foundationsのリストには載っていない。そういうわけで統合の目的のひとつが「メンバーのコミュニティーへの参加を合理化する」ことにあるのは驚くに当たらない。

画像：imArbaev / Getty Images

〔原文へ〕

（滑川海彦@Facebook Google+

開発フレームワークElectronのエクスプロイトでWebとモバイルの人気アプリが危険

広く使われているクロスプラットホームな開発フレームワークElectronのセキュリティチェックをバイパスするエクスプロイトが登場した。Trustwaveがポストしたそのエクスプロイトはすでにパッチされたので、デベロッパーは自分のアプリケーションを早急にアップデートすべきである。

そのエクスプロイトは一部のアプリケーションでnodeIntegrationの設定によりクロスサイトスクリプティングを可能にする。このメソッドでアプリケーションは自分のモジュールに接続できるだけでなく、Node.jsのモジュールにも接続できるようになる。

発表から引用しよう:

Electronのアプリケーションは基本的にWebアプリケーションであり、したがってユーザーの入力を正しく無害化できなかった場合にはクロスサイトスクリプティング(XSS)攻撃に対し無防備になる。Electronのデフォルトのアプリケーションは自分のAPIだけでなくNode.jsのすべての内蔵モジュールへのアクセスを含んでいる。そのためXSSの危険性は大きく、犯人のペイロードはchild_processモジュールにおけるrequireなどの悪質なことができるようになり、クライアントサイドでシステムコマンドを実行する。Atomには少し前からまさにそれをするXSS脆弱性があった。アプリケーションのwebPreferencesにnodeIntegration: falseを渡すことにより、Node.jsへのアクセスを削除できる。

Discord, Signal, Visual Studio Code, それにGithubなど、多くの人気アプリケーションがElectronを使っている。Slackも、そのアプリケーションにElectronを使っている。

そのエクスプロイトはnodeIntegrationの設定と新しいウィンドウを開くプロセスに依存している。多くの場合nodeIntegrationはfalseに設定されているが、たまたまnodeIntegrationをtrueに設定すれば、child_processモジュールを呼び出すなどの悪質なスクリプトを通してしまい、そいつはspawnのようなシステムコールにより、オペレーティングシステムのコマンドを実行できるようになる。

ElectronのWebサイトがここにあり、アップデートに関するブログ記事はここだ。このプラットホームを最近の数週間以内にアップグレードしていれば、多くのアプリケーションが無事だろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Node.jsインフラストラクチャの監視ツールKeymetricsが200万ドルを調達

フランスのスタートアップKeymetricsは、Node.jsのインフラストラクチャのための最高の監視ツールを構築するために、Alven CapitalとRuna Capitalから200万ドルを調達した。同スタートアップの創業者兼CEOのAlexandre Strzelewiczは、人気の高いオープンソースのNode.jsプロセスマネージャPM2を作成した人物だ。

どうすれば人気のあるオープンソースプロジェクトを、成功するスタートアップへと転換できるだろうか？この問には沢山の異なる回答があり得る。最初から正しい答を探すことは難しく、Keymetricsにとってもそれは例外ではなかった。

数年前のこと、当時上海に住んでいたStrzelewiczがPM2を開発したときには、彼はただ既存のソリューションに欠けている、Node.jsのためのより良いプロセスマネージャーを作ろうとしていただけだった。彼は、そのオープンソースリリースがHacker Newsで取り上げられて、Googleや、ブラジルや日本に住む人たちからの貢献を引きつけることになるとは予想していなかったのだ。

PM2を使えば、Node.jsサービスがいつでも運用されているようにすることができる、何故ならPM2はアプリのクラッシュを検知してそれを再起動することができるからだ。PM2はまたアプリケーションのリプリケーションを行い、大きなトラフィックピークがやってきたときには、これらのアプリケーションの間でクエリーのバランスをとる働きをする。

もし開発者でなければ、上で述べたことは少々複雑に聞こえるかもしれないが、既に何千人ものNode.js開発者がGithub上のリポジトリをフォローして、合計でPM2は2000万回以上もダウンロードされている。Node.js自身も、最近はますます人気を得るようになって来ている。Keymetricsは、PM2のダウンロードをリアルタイムに視覚化する綺麗なマップもローンチした。この記事のトップに埋め込まれたGIFのライブバージョンだ。

こうしてStrzelewiczは何かを掘り当てたことに気が付き、Keymetricsを開発した。もしインフラのためにPM2を利用しているいるのなら、Keymetricsは完璧な補完サービスだ。複数のサーバーに跨るアプリを、リアルタイムダッシュボードを使って、モニタし管理を行うことができる。ダッシュボード自身、セットアップの手間はほとんどかからない。

アプリケーション・デモ

「Keymetricsは、1つまたは複数のPM2インスタンスに直接接続するSaaS（サービスとしてのソフトウェア）ダッシュボードです」とStrzelewiczは私に語った。「PM2管理下のアプリケーションの、パフォーマンスメトリクスを収集することを可能にします。そして、アプリケーションがクラッシュしたり、コンピューター資源が枯渇したりした場合に通知が行われます」。

2015年の初め、KeymetricsはTechstars NYCに出展し、首尾は上々かと思われた。しかし、欠けている機能が1つあった。同社はまだ支払いオプションを提供していなかったのだ。このため、TechstarsのあとKeymetricsは資金を調達できず、Strzelewiczは全員を解雇せざるを得なかった。

ゆっくりと、しかし着実に、Strzelewiczはゼロから会社を再建した。彼はまず、支払いオプションを実装し、最初のクライアントを獲得した。パリの公式ウェブサイトだ。

既に、NewRelic、Appdynamics、そしてとDynatraceのような、多くのアプリケーションパフォーマンス管理ソリューションが存在している。しかし既にPM2を実行している場合には、Keymetricsは間違いなく最良の選択肢だ。

Keymetricsは毎秒メトリクスを追跡するので、まるでリアルタイムダッシュボードのように感じられる。そして、アラートを即時に受け取ることができる。そして、現在のコードベースとインフラストラクチャに関する、レポートと洞察を取り出すことができる。

これまでのところ、Keymetricsはおよそ100顧客を抱えているが、今回の資金調達を使って次のレベルへ進むことを計画している。顧客は平均で月額約90ドルを支払う。

資金調達の発表に目を眩まされるのは簡単だ。そしてもちろん、ハイテクジャーナリストも「資金調達チアリーディング問題」の一部である。しかし、騙されないで欲しい。

スタートアップを始めることは、信じられない位困難なことだ。何ヶ月も1人で、それが報われることを願いながら、働き続けなければならないこともある。この苦労は一夜の成功のようにセクシーではない。しかし、一夜の成功など神話に過ぎない。

ハイテク起業家が早期に苦労すると、次に来るものに素早く対応できるようになる傾向がある。Keymetricsもこのパターンに従っているかどうかを見守ろう。

[ 原文へ ]
（翻訳：Sako）

Facebook、JavaScriptの新パッケージマネージャ、Yarnをリリース―Google他が協力

OAKLAND, CA - NOVEMBER 30: A FedEx worker sorts packages being uloaded from a truck on a conveyor belt at the FedEx Oakland Airport sort facility November 30, 2005 in Oakland, California. FedEx and UPS are beginning to feel large volumes of packages as the holiday shipping season gets underway with a high level of online shopping. (Photo by Justin Sullivan/Getty Images)

今日（米国時間10/11）、FacebookはJavaScriptの新しいパッケージマネージャーのYarnをローンチした。読者が日頃JavaScriptとNode.jsを使っているなら、既存のコードを探して再利用する（あるいは自分で開発したライブラリを公開する）ためにnpmパッケージマネージャを利用している可能性が高い。

しかしnpmはFacebookのような巨大な規模の企業の業務を処理するには能力が足りなかった。そこでFacebookは社内のデベロッパーの意見に従って独自のパッケージマネージャを部内用に開発した。その後開発チームはGoogle、Exponent、Tildeなどの外部のエンジニアの協力も得るようになった。

こうして開発されたのがYarnだが、特に重要なポイントは以下の点だ。つまりYarnはFacebookのような巨大企業以外のデベロッパーにも画期的な効率アップを約束するものの、あくまでnpmレジストリを利用しているユーザーが対象であり、npmクライアントをドロップインで代替するプロダクトだという点だ。

Facebookのソフトウェア・エンジニアのSebastian McKenzie、エンジニアリング担当マネージャーのTom Occhinoが私に語ったところによれば、Facebookは社内でnpmを中心として多くのインフラを構築してきたという。McKenzieによれば、「しかし時間が経つうちに、npmに新しい機能やツールを次々に付け加えていくやり方ではうまくいかなくなってきた。そこでnpmの能力の限界をハッキングして拡張しようとする代わりに、Facebookは新しいパッケージマネージャをゼロから作ろうと決めた」という。

数百万人のデベロッパーのところでnpmが役に立っているのに、なぜFacebookでは問題が起きたのだろうか？　 Facebookの開発チームの話によれば、同社のワークフローに適合しない根本的な問題がいくつかあったのだという。ひとつはパフォーマンスが低すぎたことで、Yarnはローカルに保存されたファイルを得るのが効率化されている。つまりネットワークへのアクセス回数を従来よりずっと減らし、負荷をかけずにすむようになった。Yarnはまたいくつかの作業を平行化することができ、新しいモジュールのインストールが高速になった。

Facebookのワークフローでは常時新しいモジュールが統合されている。npmはこのプロセスのネックとなり、スピードをダウンさせていた。当初、Facebookのエンジニアはマニュアルでnpm installコマンドを入力していたが、これはサンドボックスやセキュリティーや信頼性への配慮からネットワークから孤立した環境でのモジュール統合では作動しなかった。レポジトリにあるすべてのモジュールをチェックする仕組みも、どんなわずかな変更でも巨大なコミットを引き起こすことになったので非効率だった。たとえばReact Nativeモジュールには68の依存関係があり、依存先もまた独自に依存関係があり、合計すると12万1358個のファイルになる。これらをすべて引き出してくるのは効率的とはいえない。

Facebookが直面したもうひとつの問題は、npmは本質的にノン・デターミニスティック（非決定性）のデザインだという点だった。FacebookのエンジニアはDevOpsのワークフローで一貫性と信頼性のあるシステムを必要としている。npmの場合、すでにインストールされたモジュールとの依存関係によって、あらゆるプロジェクトに存在するにもかかわらず、node_modulesのディレクトリはマシンごとに全く違った見え方となる。Yarnではロックファイルとデターミニスティックなインストール・アルゴリズムを用いることにより、すべてのマシンを通じて統一的なファイルを構造を得ることができるという。

またnpmはデフォールトでデベロッパーがインストールの過程で必要になれば他の場所にあるコードを参照して実行できるようパッケージを書くことができる。これはセキュリティー上の問題を引き起こす原因になるため、Yarnではこの機能は削除された。

McKenzieが私に話したところによると、開発チームは当初npmのこうした問題の「修正」を試みたという。だが努力を重ねるうちに、既存のnpmクライアントの機能にFacebookのワークフローで作動しないものが多数あるのはバグではなく、そういう仕様であることが分かってきた。Occhinoは「それにFacebookが必要とする機能の多くはnpmのコミュニティーに受け入れられない可能性があった」と付け加えた。

npmプロジェクトを支える商業組織であるNpmはもちろんFacebookが新しいパッケージマネージャを開発中であることを知っていた。しかしNpmのビジネスモデルはクライアントよりレジストリを中心としており、一般に想像されるよりも相互の競合ははるかに少なかったという。

YarnはすでにGitHubから利用可能だ。Facebook以外の多くの企業が協力したことをふまえ、開発チームはFacebook独自のレポジトリを利用することを避けた。ただしYarnの今後の管理体制がどのようなものになるのかについてはまだ不明な点が多い。「これまで開発に協力してくれた企業が引き続き将来の管理についても助けてくれるというのがわれわれの希望だ」とOcchinoは述べた。

画像： Justin Sullivan/Getty Images

[原文へ]

（翻訳：滑川海彦@Facebook Google+）

バックエンドとフロントエンドとが仲良くなって十分納期に間に合うためのツールBrightWork、立ち上げ前から300名が待ち行列

フロントエンドの連中とバックエンドの連中は、意思疎通ができない。バックエンドの連中が“Node.js”と言うと、フロントエンドの連中は“ノード何？”と聞き返し、やがて喧嘩になり、水かけ論になり、最後は大混乱になる。シカゴ生まれでTechStarsで育ったBrightWorkに、そんなときのためのソリューションがある。

TwilioのエンジニアだったJosh Carterと、NikeのデベロッパーだったPhil Taylorが創った同社は、これまで20万ドルを調達して、バックエンドのデプロイを単純化しようとしている。

Carterは説明する: “Philもぼくも、同じ問題で悪戦苦闘していた。DisneyやTaco BellやPabst Blue Ribbonなんかのアプリケーションを作っていたんだけど、どんな場合でも、バックエンドとマイクロサービスの構築で納期の大半を食ってしまうんだ。Phisも同じ問題を抱えていて、彼はクライアントのためのソリューションやインフラストラクチャをもっとアジャイルに作れるための、ベストの方法を探していた。二人で共感を共有できたから、Brightworkのようなものを創ろう、ということになった。”

Brightworkはいわば、昔のCpanelのような、一連のスクリプトの集まりだ。ここにはこんなAPIやサービスがほしい、と思ったら、ボタンを押すだけでコードが完成する。そしてそのコード片の回りに、それを管理するためのインタフェイスをくっつければ、フロントエンドが完成する。なんとなく、気の抜けたビールのようなやり方だが、でも、使える。

同社の立ち上げ前から300名のユーザーが立ち上げを待っていた。

“しかし最初は一部の人たちにだけ使ってもらって、彼らから重要なフィードバックをもらった。でももちろん、成長するためにはオーディエンスを広げなければいけないことも、わかっていた”、とCarterは語る。

バックエンドはフロントエンドほどセクシーではないが、中身のクリームと外側のチョコレーtの両方が揃わないと、おいしいケーキはできない。両者の合体を支援するBrightworkは、だからすばらしいだろう。もう、お互いに喧嘩する必要はないね。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Node.js用パッケージマネージャnpmが法人化してシード資金$2.6Mを調達

学びやすくてしかもスケーラビリティが良いため、Node.jsはアプリケーションを開発するための非常に人気の高いプラットホームになっている。そしてNode.jsで書いたプログラムのインストールと公開と管理を助けるパッケージマネージャnpmが、True Venturesのリードにより260万ドルのシード資金を調達した。この投資ラウンドには、GoInstant.comの協同ファウンダJevon MacDonaldやGavin Uhma、Charles Beeler、それにNode Summitの主催団体Asynch Mediaも参加した。True VenturesのパートナーPuneet Agarwalが、npmの取締役会に加わる。

npmは現在、デベロッパに、60000近いモジュールへのアクセスを提供している。Node.jsのデベロッパはモジュールやパッケージを使って新しい機能を自分たちのアプリケーションに迅速に加えることができ、大幅な時間節約を達成する。

npmの利用規模は、今では相当大きい。1月にはダウンロード回数が2億回近くに達し、提供しているNode.jsのパッケージは総行数が10億行を超えている。C++とJSの部分のコードの総行数は、テストも含めて12万行を超えている。

このオープンソースのプロジェクトが作られたのは3年前のことだが、需要が盛況なため、サポートの充実を目指してnpm, Inc.という名前で法人化を図った。法人の立ち上げは昨年12月で、今回シード資金が得られたため、サポートサービスなどの一層の充実が期待される。

ファウンダでCEOのIsaac Schlueterは、それまでJoyentで同社のNode.jsをプロジェクト指揮していた。その前は、Yahooに在籍した。協同ファウンダのLaurie Vossは CTO、Rod BoothbyはCOOを務めている。

GoogleのJavaScriptランタイムV8を使用するNode.jsは、今ではGEやWalmart、Yahoo、Microsoft、LinkedIn、PayPal、Joyentなど、有名大企業も利用している。

とりわけJoyentは、その初期からNode.jsの最大の支援者で、Node.jsアプリケーションのためのデバッグやパフォーマンス分析ツールなどを商用のサポートサービスとして提供している。Joyentの協同ファウンダJason Hoffmanは、この、クラウドコンピューティングサービスのパイオニア的企業のCTOの座を昨年秋に去り、今ではnpmの取締役になっている。

画像: Flickr/Karunakar Rayker, CC BY 2.0のライセンスによる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

コードを読めない/書けない人でもプログラミングの理解と参加ができるヴィジュアルツールNoFlo

NoFloという会社が、1970年代にIBMが提唱した“フローベースのプログラミング”*というコンセプトに基づく、オープンソースのヴィジュアルプログラミングツールを作り、多くのプログラミング言語に対応する本格的な開発環境に仕上げるための資金10万ドルを、Kickstarterで募金している。〔*: flow-based programming, プログラムの構造を処理の流れ(flow)で表す（下図）。〕

一見するとNoFloは、簡単なWeb開発ではなくもっと高度なプログラミングのためのWYSIWYGエディタみたいだ。いろんな部位をドラッグ＆ドロップで並べて、求める計算処理を完成させる。しかし実際にはそれは、コードを書いたり読んだりした経験のない人たちでもプログラム/プログラミングを理解できるための、ヴィジュアルな仕掛けだ。今では企業の役員でも管理職でも一般社員でも、プログラミングの経験や知識があることが求められる。これからは誰もが、デベロッパたちがやってることを見て何をしているのか理解でき、プログラミングや開発の過程に何らかの形で関われなければならない。NoFloは、そういう時代要請に即したツールだ。

同社によれば、“それは新しいタイプのフローベース開発環境であり、中でもとくに、どこを新しくしたいかというと、もっとコラボレーション型の環境にしたいのだ”、という。つまり、“企業やチームの人たちに、彼らのソフトウェアがどのように動くのかを示すマップを提供したい。たとえばそのソフトウェアがインターネットに接続されたら、いろんなものが流れて（flowして）いく。プログラムを流れ(flow)でとらえて表現する方法は70年代に発明されたが、うちはそれを、インターネットやクラウドAPIなんかがある現代の環境向けにリニューアルしたいのだ”、ということ。

これと似たプロプライエタリなツール*は前からすでに、大型のプログラミングプロジェクトで使われていたし、映画Lord of the Ringsなど大衆的なメディアに登場したことがある。それらではこのソフトウェア開発プラットホームが、特殊効果のデザインや開発フロー用に使われていた。NoFloはそれらと同じツールを、一般的なオープンソースコミュニティに初めて持ち込むことになる。Kickstarterで資金募集に成功したら。〔*: もしかして、フローチャート(flow chart)のことか？〕

Kickstarterに出た目的は、関心を集めることと、今JavaScriptしかサポートしていないこのツールを、さらにJavaやObjective C対応にするための資金集めだ。つまり、iOSアプリやAndroidアプリを作れるようにしたいのだ。同社によるとそれはScrabbleをLegoに変えるようなもので、基本的に、一般の人には全然分からないもの（プログラム/プログラミング）を、誰にでも分かり会話にも参加できるものに変えるのだ。

NoFloがKickstarterのページで述べているように、Webサイトの場合は、デザイナーがヴィジュアルの仕事をしたら、あとは完全にプログラマの仕事になり、言語を理解できない者には口出しすらできないものになってしまう。NoFloが望むのは、デザイナーが全工程に参加して、本格的なプログラミング教育を受けなくてもプログラミングに参加できることだ。肩越しからプログラマの仕事をちょっと覗くのではなく、正規にチームの一員として会話に参加できること。

出資約束95ドル以上で、プライベートなプロジェクトライセンスが得られる。つまり、コミュニティでオープンに共有されるプロジェクトにはこのツールが提供される。金額が多いとライセンスの期間が長くなり、特典も増える。ソフトウェアでしかも消費者製品でないものに、目標額10万ドルは厳しいが、NoFloのねらい自体はきわめて社会的に重要であり、とくに、技術部門と管理部門とクリエイティブ部門、この三者のコミュニケーションを建設的に円滑にしたいと願っているデザインスタジオやデベロッパショップからは、支持を得られそうだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

コードを読めない/書けない人でもプログラミングの理解と参加ができるヴィジュアルツールNoFlo

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）

Amazon Web Services(AWS)がNode.jsによるSDK/オブジェクトライブラリを提供

Node.jsは今や、アプリケーションを開発するとき誰もが使っている。それはサーバサイドのJavaScriptだ。比較的おぼえやすいので、とても人気がある。今回はAmazon Web Services(AWS)が、Node.jsによるSDKをリリースし一般公開した。

あるブログ記事によると、AWSは12月のプレビューリリース以降、さらに機能を増強した。新しい機能は、バウンドパラメータ、ストリーム、EC2インスタンスのIAM roles、バージョンロッキング、プロキシなどだ。AWSによると、このSDKはAWSのサービス(Amazon S3, Amazon EC2, DynamoDB, Amazon SWF)のJavaScriptオブジェクトを提供して、デベロッパのコーディングを単純化することが目的だ。

Node.jsはその、イベント駆動型のノンブロッキングI/Oにより、アプリケーションのスケーラビリティを支え、しかも、スレッドやタイムアウトのポーリング、イベントループなどをプログラマは扱わずにすむ。だからこそ、大きな人気を獲得した。とくにゲームデベロッパに愛好者が多く、AmazonのCTO Wener Vogelsは、3月にAWSがElastic BeanstalkでNode.jsを提供したときに書いた記事の中で、そのことを説明している。Vogelsによると、Elastic BeanstalkはElastic Load Balancing、Auto Scaling、EC2などのAWSリソースのプロビジョニングとモニタリングと構成を自動化する”。彼によると、デベロッパたちはNode.jsの機能を利用することによって、レイテンシ（ネットワーキング待ち時間）の低い複数の並列的接続を実現している。UberやVoxer、それにDataheroのようなエンタプライズ向けスタートアップはすべて、サーバの実装にNode.jsを使っている。

Node.jsのサポートを提供しているクラウドプロバイダはAWSだけではない。Joyentはこのプラットホームを企業向けサービスの一環として提供している。Windows Azureもビッグなサポーターだ。Rackspaceもサポートしている。3月にMicrosoftは、Windows Azure Service Busを使うオープンソースの寄与貢献物を提供した。それは、Node.jsによるリアルタイムアプリケーションのためのスケールアウトをサポートするライブラリだ。

AWSが今回Node.jsによるSDKを一般公開したことは、デベロッパ界隈における、Node.jsというプラットホームの実力を物語るエピソードの一つだ。つまり、デベロッパを相手にするビジネスでは、もはやNode.jsを無視できない。これで、AWSをベースに開発〜プログラミングをするデベロッパが今後増えることは、ほぼ確実だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）