AWS Lambdaのイベントトリガを使いやすくしてWebサイトの開発方法を改革するNetlify

Webプロジェクトの継続的なデプロイメントを支援するサービスNetlifyのビジョンは、Webサイトの作り方を変えることだ。とくに、フロントエンドのデザインとバックエンドで実行されるサービスとの結合を、もっとシンプルにしたい。今日同社は、そのビジョンの実現に向かう次の一歩として、NetlifyのサービスにAWS Lambdaのファンクションを導入した。

同社のねらいは、Web開発に伴う多くの複雑性を、できるだけ減らすことだ。たとえば、ユーザーがHTMLとJavaScriptでフロントエンドをデザインすると、Netlifyはそれをさまざまなサービスに結びつける。決済ならStripe、メールによるニューズレターの管理ならMailChimp、というように。このやり方でNetlifyは、Webサーバーという概念を抽象化(実体のないものに)してしまう。デプロイが遅くてセキュリティもスケーリングも困難なあのあれが、消えてなくなる。そして、一枚岩的なWebサイトから、スタティックなフロントエンドとバックエンドのマイクロサービスという組み合わせへ移行し、それによりセキュリティとスケーリングの問題を解決、そしてサイトを従来よりも相当早くユーザーに渡せるようになる(デリバリが早い)、と同社は信じている。

ユーザーは、サイトの構築に何を使ってもよい。ユーザーが作った設計/デザインを渡されたNetlifyは、バックエンドのコーディングのすべてをエッジに置き、コードはエッジで実行される。その意味で同社のサービスは、半分はContent Delivery Network(CDN)、残る半分はデベロッパーの自動化エンジンだ。

この、より動的なWebサイトをより早く作るというNetlifyの能力がAndreessen HorowitzのパートナーPeter Levineの目に留まり、昨年8月に同社の1200万ドルのシリーズを彼がリードした。Levineは曰く、“彼らの、マイクロサービスとAPIsを活用して柔軟性に富む動的な(ダイナミックな)Webサイトを作る、という考え方はすばらしいアイデアだ。しかも、エッジへデプロイすることによって、さらにハイパフォーマンスなユーザー体験を作れるし、GitHubを統合することによってアプリケーションを容易に作成し管理できる”。

今日の発表は、同社のサービスのそんなアプローチをさらに一歩前進させる。Lambdは、AWSのいわゆるサーバーレス・ツールだ。デベロッパーはファンクションを作り、それが特定のイベントにトリガされて実行される。デベロッパー側には、サーバーを24/7動かし管理しメンテナンスする苦労がない。これは、NetlifyのWeb開発アプローチとぴったり相性が良い。つまりそれは、AWS Lambdaと同じく、WebのパブリシングプロセスからWebサーバーを取り除くから。

そしてNetlifyは、Lambdaのファンクションを、もっと容易に実行できるようにした。同社によると、Webデベロッパーは確かにイベントトリガーという考え方を気に入っているけど、AWSのワークフローは複雑すぎる。イベントトリガーをデベロッパーのアイデンティティで容易に作れるようになれば、Lambdaをもっと気軽に利用できるだろう。

同社の協同ファウンダーChristian Bachは、こう説明する: “Lambdaが良いことは自明だが、それを軸とするワークフローがないために、使いづらい。われわれにはフロントエンドをパブリシングするワークフローがあるので、サーバーレスもそれと同じようにしたい、と考えた”。

“Lambdaのトリガのひとつひとつが小さなマイクロサービスになり、ブラウザーからそれらにアクセスできる”、と彼は述べる。たとえばStripeを使って決済をする場合なら、Stripeの秘密の認証情報のコードで決済のゲートウェイに入る。“従来なら、この小さな呼び出しのために、どこかでサーバーを動かす必要がある。この小さな機能だけのために、Railsのアプリケーションを作るだろう”、Bachはそう述べる。

しかしNetlifyのやり方では、認証情報を数行のコードでタイプし、それからLambdaのトリガとNetlifyの糊的なコードを少々使うだけだ。これにより、そのコードをどこに置くか、それをどうやって管理するか、という問題が解決する、とBachは言う。

かねてからエッジコンピューティングをテクノロジーの大きな駆動因として見ているLevineがNetlifyのシリーズAをリードし、同社の取締役会に加わったたのは、たぶん偶然ではない。

Levineは曰く、“かなり前からエッジコンピューティングには注目しているし、Netlifyは、エッジにおけるサービスという大きなトレンドの一部だ。同社は、現代的なWebサイトを構築しデプロイする方法を開発した”。

同社は、2015年に創業され、これまでに1410万ドルを調達している。

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

WebRTCアプリの分析サービスCallstats.ioが$3Mを調達、データ提供企業から問題解決企業への成長を目指す

(GERMANY OUT) Altes  Telefon mit Waehlscheibe aus der DDR  (Photo by Leber/ullstein bild via Getty Images)

WebRTCは、Webの比較的新しいスタンダードで、これを使えばプラグインを使わずブラウザー上で直接、音声やビデオによる通話ができる。しかし、これを採用する企業や製品が増えるとともに、これらの通信のパフォーマンスに関するインサイト(たとえば‘落ちる’理由)を得たいというニーズも増加している。Callstats.ioはWebRTCの接続をモニタするスタートアップで、集めたデータをもとに、顧客の接続の改善を支援している。

同社が今日、True VenturesがリードするシリーズAのラウンドで300万ドルを調達したことを発表した 。これにより同社は、製品開発をさらに継続できる。これで、Callstats.ioの資金調達総額は350万ドルになった。

True VentureのパートナーOm Malikが、Callstats.ioの取締役会に加わる。Malikは、声明文の中で次のように述べている: “他との摩擦の少ないWebRTCには、通信とWebに革命をもたらす可能性がある。Callstats.ioが開発しているような高度なモニタリングと診断は、この新しい形の通信がもたらす機会を、さらに改良し強化していく”。

同社の協同ファウンダーでCEOのVarun Singhによると、同社のサービスの最初のプロトタイプが書かれたのは2013年で、当時はWebRTCが徐々に注目され始めていた時代だった。2014年の夏に同社は小額のシード資金を獲得し、最初の顧客と契約した。その後は製品の拡張と改良に努め、2015年には新しい顧客も増えた。また同社はさまざまなSDKプロバイダーたちと協働することにより、そのサービスをTwilioやJitsiなどなどに統合している。

Singhによると、Callstats.ioには来年の初めごろまでの必要資金はあるが、今なら好条件で調達できるので新たな資金調達を決断した。

今後Callstats.ioがとくに力を入れたいのが、診断サービスだ。Singh曰く、“私たちの仕事は問題の発見と修復の実施だ、といつも言ってきた。今日では、問題の20~30%は確実に修復できるが、新たな技術投資により問題の50%をフィックスできるようにしたい”。

それが、Callstats.ioという企業の現状だ。同社は人びとにモニタリングデータを提供するが、データに対する有効なアクションとなると、また別の能力だ。たとえば、あるネットワーク上のユーザーへの呼び出しが頻繁に落ちる、という問題があるなら、Callstats.ioは、通話は始まったらほかの帯域利用を自動的に抑えるなどにより、落ちないための対策を提供できるべきだ。Singhによると、デベロッパーは高度な設定をコードとして書いてしまいがちだが、しかしネットワークがそれに対応できないときもある。だから本当は、最初から設定を多様化しておく必要がある。“うちは顧客にデータを提供する企業だが、今後は通信企業にもなりたい”、とSinghは語る。

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

JavaScript開発フレームワークMeteorが女子高生のプログラミング特訓に奨学金制度を立ち上げ

22359007740_b6c033c237_k

JavaScriptの開発フレームワークMeteorが、プログラミング特訓学校Flatiron Schoolとパートナーして奨学金制度を立ち上げた。マイノリティなど恵まれていない層の女子高生に、コンピュータ科学を教えることが目的だ。並行して両社は、12週間のWeb開発/デザインコースに15名の生徒を無料で受講させる。その‘定価’1500ドルのコースでは、HTML5とCSS3、JavaScript、そしてUX/UIのデザインを学ぶ。コースの開始は2016年の2月、ニューヨークに住む13〜18歳の女の子が対象だ。

Meteorの協同ファウンダでCEOのGeoff Schmidtはこう語る: “今では世の中の動きや人間関係のかなりの部分に、ソフトウェアが深く関与している。だからこれからの世界では、どんな出自の人たちであれ、ソフトウェアを書く能力と、その使われ方を決めていく能力を持つべきだ”。

Flatiron Schoolがチャリティ的なコースを提供するのは、今回のMeteorの企画が初めてではない。今年の初めには、同校はWorkforce Development Corporationとパートナーして、大学を出ていないニューヨーク市民に22週の特設コースを無料で提供した。また、モデルのKarlie Klossとパートナーして若い女性にプログラミングを教えたこともある。

Flatiron Schoolのコースに対するMeteorの奨学制度に関心のある方は、ここで申し込める。締め切りは2016年1月20日だ。なお、2011年に創業されたMeteorは、これまで3120万ドルの資金を調達している。

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

Firefoxのエクステンション(アドオン)開発がChromeと同じ技術になる

5284754010_bf98043365_o

Mozillaが今日、Firefoxのアドオンの今後の実装が大きく変わることを発表した。中でもいちばん重要なのは、ChromeやOperaのようなBlinkベースのブラウザとほとんど互換性のある、新しいエクステンションAPIを採用することだ。このWebExtensions APIにより、デベロッパはChrome/Operaのエクステンションにわずかな変更を加えるだけで、Firefoxでも動くようにできる。

MozillaのKev Needhamが今日の発表声明で次のように述べている:

“アドオンの開発を、Webの開発のようにしたい。つまり一定のスタンダードに従って書かれることにより、同じコードが複数のブラウザで動くようにしたい。そのことにより、ドキュメンテーションの充実も図りたい”。

Firefoxのエクステンションを書くことは、同じ機能をChrome用に書くことに比べて、かなり面倒だった。それは、FirefoxがXPCOMXUL(ユーザインタフェイス)のような独自の技術を使っていたからだ。それによりブラウザ本体をほとんどJavaScriptだけで書くことができ、エクステンションのデベロッパはFirefoxの内部的な機能の多くにアクセスできたが、そのため相当複雑な開発技術になっていた。

しかしこの、デベロッパがブラウザの実装の内部に自由にアクセスできる開発モデル(“permissive model”…寛容モデル)は終わりを迎える。そしてXULやXPCOMに依存し寛容なアドオンモデルに立脚するアドオンは、12〜18ヶ月後には非推奨になる。

ただしこの変更は、新しいJetpack SDKを使ってエクステンションを書いているデベロッパには適用されない(彼らがJetpackの枠内にとどまり、低レベルのAPIに手を出さないかぎり)。

Firefox 42からは、デベロッパが提出したエクステンションをすべてMozillaが検定し、合格したものだけをデプロイできる。Needhamは書いている:

“検定の作業はほとんど人間による手作業なので、合否の決定が出るまでに数週間から数か月かかることもありえる”。

ただしMozillaの想定では、WebExtensions APIへの移行によってアドオンのレビューが従来よりも相当速くなるだろう、という。またレビュー過程の一部を自動化することによって、レビューに要する時間を5日ぐらいに短縮したい、とも言っている。

Mozzilaはアドオンだけでなく、Firefox本体にも大きな変更を加えようとしている。そのElectrolysisプロジェクトにより、ブラウザのタブとユーザインタフェイス本体が別プロセスになり、タブのクラッシュによりブラウザ全体がダウンすることが、解消される。

この機能は今、Firefoxのデベロッパチャネルにプレビューが登場しているが、デフォルトで有効になるのはFirefox 43の最初のベータからだ。Electrolysisと相性の悪いアドオンもありえるから、デベロッパは事前にコードをテストせよ、とMozillaは勧奨している。

WebExtensionsのサポートはすでに、Firefox NightlyチャネルDeveloper Editionで有効である。

これでFirefoxのアドオンが大きく変わるわけだけれども、これまでFirefoxはすごく大きくて濃密なアドオン開発のエコシステムを育ててきたし、独自の技術であるだけに、そのアドオンには、Chromeなどそのほかのブラウザにはできないことができた(ユーザインタフェイスの変更など)。

今度の変更が、Firefoxのそんなアドオンエコシステムにどんな影響を与えるだろうか? コードを一つだけ書けば、それが(わずかな変更だけで)FirefoxとChromeの両方で動く未来は、基本的にはデベロッパとユーザの両方にとってwin-winだとは思うが。

しかしMozillaにとっては、これによってFirefoxの独自性が失われていくリスクもある。

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

ZappyLabは、科学研究のGitHubを目指す


科学者は大変だ。人類を別次元の巨大モンスターから守る(パシフィック・リムのクローバーフィールドを見よ)だけでなく、実験室の中で、再現可能な実験や技術を創造しなくてはならない。そこで、 ZappyLabの登場である。

TechCrunch Radioのピッチオフで優勝したZappyLabは、初めての製品Protocols.ioで、研究者たちが実験の「レシピ」を共有する手助けしようとしている。

「[共同ファウンダーの]Alexei Stoliartchoukは2012年1月7日に私に電話をかけ、生物学者のためのアプリを作れないかと尋ねた」と共同ファウンダーのLenny Teytelmanは言った。「そこでレシピのチェックリストのアイデアが浮かんだ。3週間後、彼に電話してこう尋ねた、『科学者に〈シェア〉ボタンを渡したら、クラウドソースによる保管庫が作れるだろうか』。あれが決定的瞬間だった」。

チームは、実験生物学、ウェブ開発、およびマネジメントの経験を持つ。自己資金10万ドルとシード資金80万ドルで会社は立ち上げられた。彼らはKickstarterキャンペーンでも5万ドル以上を集めた。

「科学者のために、ウェブだけでなくiOSとAndroidのネイティブアプリも本気で開発しているのは、われわれくらいだ。作りたいのはGitHubライクな科学コミュニケーションのためのリソース ― クラウドソースのオープンで常に最新な、科学的手法の貯蔵庫」とTeytelmanは言った。

しくみは? Teytelmanの説明によると、このサービスを使うと研究プロトコルや技術を協業的に共有することができる。例えば、Teytelmanは論文誌を読んでいて実験手順が抜けていたり、不正確に書かれているのを見ることがよくあると言う。オンラインで共有することによって、研究者同志で実験を再現したり、協業したりが、よりタイムリーに行えるようになる。

チームは、彼の大きな目標にとても興奮していた。

ワクチン、気候変動、老化、がん ― あらゆる人と物に影響を与えるもの ― の研究は、われわれのサービスがあれば、今よりはるかに早く進むだろう」とTeytelmanは語った。

[原文へ]

(翻訳:Nob Takahashi / facebook