PythonとJavaScript向けの新パフォーマンス監視ソフト「Performance Monitoring」

米VCのAccelやNew Enterprise Associatesの支援を受け、アプリ開発者向けのバグ監視ソフトウェアを開発しているSentryは、米国時間7月14日に最新製品を発表(Sentryブログ)した。Performance Monitoringと名付けられたこの製品は、PythonとJavascript用のフロントエンド・パフォーマンス監視ソフトウェアだ。

同社によると、Performance Monitoringではパフォーマンスの低いAPIコールやその他のエラーをソースにさかのぼって追跡することで、エラー修正に要する時間を数分に短縮できるという。

パフォーマンスの低いアプリは収益を圧迫する可能性がある。例えばオンラインショッピングカートの読み込みに時間がかかりすぎている場合、フラストレーションを感じた顧客は諦めて競合するアプリやウェブサイトに乗り換える可能性があるため、エラーを迅速に修正することが重要だ。同社はまた、問題の追跡やバグの修正に関連する作業にかかる企業のコストは年間約460万ドル(4億9000万円)だと試算している。

Sentryはこれまでに6650万ドル(約71億円)の資金を調達しており、現在では6万の組織で利用されているという。CEOのMilin Desai(ミリン・デサイ)氏はTechCrunchに対し、新型コロナウイルスのパンデミックの影響で仕事や教育、Eコマースアプリの利用が増加したことで、過去4カ月間にあらゆる業種のSentryの顧客が同社のツールを利用するようになったと語った。

新しいパフォーマンス監視ツールでは、開発者が「ウォールボード上のスパイクを解読しようとするのではなく、パフォーマンスの悪いAPIコールや遅いデータベースクエリにロード時間の遅さをリアルタイムで追跡できる」ことを意味する。「企業が大規模な運用上の変更を余儀なくされている一方、Sentryは新たな需要に対応できるようにしており、パフォーマンスの高いソフトウェアを出荷する上でミッションクリティカルであることを認識している」。

原文へ

(翻訳:塚本直樹 Twitter

好きなプログラミング言語でIaCできるPulumiがサポート言語と構成対象を拡張

シアトルのPulumiは、モダンなプラットホームとしての名声を早くも確立した。それは、同社のサービスを利用すると、コードを書いてインフラストラクチャを指定するときYAMLではなく自分の好きなプログラミング言語を使えるからだ。最近ローンチしたPulumi 2.0では、最初にサポートされていたPythonに加えて、JavaScript、TypeScript、Go、そして.NETが使えるようになった。また、インフラストラクチャの構成に加えてポリシーの強制やコードの試験なども指定できる。

今日(米国時間4/21)の同社の発表によると、現在のユーザー数は10000、そして有料ユーザーが100あまりだ。これらは、前年同期比で10倍の増加になるが、必ずしも正確な数字ではないようだ。現在の顧客にはCockroach LabsやMercedes-Benz、Tableauなどがいる。

同社がローンチしたばかりのころは、コンテナとサーバーレス関連のサービスを強調していた。でもPulumiの創業者でCEOのJoe Duffy氏によると現在の同社は、各企業で技術者のためのプラットホームを構築しているインフラストラクチャのチームと直接組んで仕事をすることが多い。

Pulumi 2.0についてDuffy氏はこう言う: 「Pulumiの最初のビジョンは、お好きな言語でインフラストラクチャーアズコード(Infrastructure as Code, IaC)を、だったけど、2.0ではそれを大幅に拡張して今やスーパーパワーと呼んでいる」。つまり、インフラのプロビジョニングだけでなく、その周辺の問題領域にまで機能を拡張した、という意味だ。それには継続的デリバリーも含まれるが、さらにポリシーアズコード(policy-as-code)と呼べる機能もある。2.0からのPulumiは単なるインフラストラクチャの構成定義を超えて、インフラ関連のさまざまなポリシーまでコードで指定できるようになったのだ。

もう一つの拡張領域が、試験だ。Pulumiでは「本物の」プログラミング言語を使えるから、アプリケーション開発でコードの試験に使ってるのと同じ試験のテクニックをインフラストラクチャの構築に使って、プロダクションに行く前に間違いを捉える。しかもデベロッパーは、言語が同じだから、コードを書くために使っているツールをそのまま使って、そのコードが動くインフラストラクチャを定義できる。

Duffy氏は曰く、「基本的な考え方は、プログラミング言語について自分たちがよく知ってることや好きなことをそのまま生かして、クラウドのインフラストラクチャを定義しよう、ということなんだ。インフラストラクチャには、担当のチームづくりやセキュリティの確保など、アプリケーションのプログラミングとは違う課題が山ほどあるが、なじみの言語をそのまま使えるなら、それらも怖くない。それにより、企業全体を高い生産性でまとめて行けるだろう。つまり2.0で重要なのは、インフラストラクチャのプロビジョニングから、組織全体のサポートへ、という移行だ」。

Duffy氏は、同社の大企業ユーザーの多くがPulumiを使って彼らの内部的なアーキテクチャもコードで書き表し、それらを全社的に展開していることを強調した。

氏は曰く、「今までのそれぞれのクラウドの特長は尊重している。AWSもAzureもGoogle CloudもKubernetesも、それぞれの持ち味がある。だからそれら全体を抽象化するPaaSを提供する気はない。われわれはただ、コードによってチーム全体に矛盾や衝突のないすっきりとしたワークフローを実現し、彼らがモダンなアプローチを採用できるようにするだけだ」。

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

GitHubがJavaScriptのパッケージマネージャー「npm」を買収

Microsoft(マイクロソフト)が保有するデベロッパーリポジトリーGitHubは、米国時間3月16日に独自の契約によりJavaScriptのパッケージベンダーnpmを買収した。買収額は公表されていない。

GitHubのCEOであるNat Friedman(ナット・フリードマン)氏は、この買収を発表するブログ記事で、npmはJavaScriptのコミュニティにおける大きな存在だとしている。同社はNode.js上のパッケージマネージャーであるnpm Registryやnpm CLIなどのツールを開発し提供している。Node Package Managerの頭字語がnpmになる。

「npmはJavaScriptの世界で重要な。npmのチームによるこれまで10年間の仕事と、何十万人ものオープンソースの開発者とメンテナーの貢献により、npmは130万あまりのパッケージのホームになり、それらは1カ月に750億ダウンロードされている」とフリードマン氏はいう。

オーナーが変わることによる開発者の不安を打ち消すかのようにフリードマン氏は、ユーザーはその違いに気づかないだろうと語っている。「npmの公開レジストリを毎日使っている数百万の開発者にとってnpmはいつでも使えてmいつでも無料であり続ける」と氏は記している。

彼はまた、このツールを支えているインフラをアップデートしてユーザー体験を改善し、npmのコミュニティとの関係を維持すると約束している。フリードマン氏によると、npmの技術をGitHubのプラットフォームに一体化する。すなわち「将来的にGitHubとnpmを統合して、オープンソースソフトウェアのサプライチェーンのセキュリティを改善し、GitHubのプルリクエストから、セキュリティの改良などnpmのパッケージのバージョンの変化をトレースできるようにしたい」とのことだ。

npmの創業者でCEOのIsaac Schlueter(アイザック・シュリューター)氏は同社のブログで、買収は良い方向への変化だとしている。「npmのユーザー体験が改善される素晴らしい機会だ。それによりJSデベロッパーの毎日が大小様々な面で有意義に改良されるだろう。そして私たちのツールが信頼性を増し、より便利になり、お互いに依存し合っているJavaScriptの広大なエコシステムの誰とでも結びつけるようになる」という。

もちろんそれは、無料バージョンだけの話ではない。有料顧客のコアグループもあり、フリードマン氏によると、GitHubはその人たちのサポートも継続する。

彼によると、レジストリがさらにGitHubへと統合される2020年後半には、有料顧客は自分たちのプライベートなnpmパッケージをGitHubのパッケージに変換できるようになる。

PitchBookのデータによると、2014年に創業されたnpmはこれまで、4800万ドル(約51億円)の投資前評価額により1900万ドル(約21億2000万円)近くを調達している。「スタートアップとして6年間苦労したが夢は大きかった。次の章に入った今は、その夢を実現できるチャンスだ」とシュリューター氏は書いている。

関連記事: Microsoft has acquired GitHub for $7.5B in stock…Microsoftが75億ドルでGitHubを買収(未訳)

画像クレジット: Bloomberg / Getty Images

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

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にフルタイムで関わるエンジニアを数名起用する。

関連記事:Node.jsとJSが合併の意向を共同発表、JavaScriptコミュニティーの統合を図る

画像クレジット: Google

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

GitHubがパッケージレジストリを提供、主要なパッケージマネージャーと互換性あり

GitHubは米国時間5月10日、GitHub Package Registryを非公開ベータでローンチした。このパッケージ管理サービスによりデベロッパーは、ソースコードと並んでパッケージをパブリックまたはプライベートで発行できる。

ただしそれはnpmやRubyGemsなどのツールと競合するものではない。GitHubのパッケージレジストリサービスはこれらのツールと互換性があり、デベロッパーは自分のパッケージを、コードのときと同じGitHubのインターフェイスを使って発行したり見つけたりできる。このサービスは現在、JavaScript(npm)、Java(Maven)、Ruby(RubyGems)、.NET(NuGet)、およびDockerイメージと互換性があり、他の言語やツールも今後サポートされる。

GitHubのプロダクト管理部長Simina Pasat氏はこう語る。「GitHub Package Registryは広く使われているさまざまなパッケージ管理クライアントと互換性があるので、自分が選んだツールでパッケージを発行できる。タイプの異なる複数のパッケージを、ひとつのレポジトリーに収めることもできる。そしてウェブフックやGitHub Actionsを利用すれば、パッケージの発行と発行後のワークフローを完全にカスタマイズできる」。

企業は社員たちに単一の認証情報を提供して、彼らのコードとパッケージの両方を管理させられる。そしてこの新しい機能により、承認済みのパッケージセットを容易に作れる。また、利用統計をダウンロードでき、GitHub上のパッケージ操作の完全な履歴にもアクセスできる。

オープンソースのパッケージの多くが、すでにGitHubを使ってコードを開発し、その後それをパブリックなレジストリへ発行している。GitHubの主張によると、そんなデベロッパーたちもこれからはGitHub Package Registryを使って、リリース前のバージョンを発表できる。

また、すでにGitHubを利用してプライベートなリポジトリをホストしているデベロッパーも少なくない。要するに、パッケージとコードは同じ場所にあったほうが便利だ。GitHubが今回行ったことは、そのような慣行を公式化してひとつのプロダクトに仕立てたものとも言える。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

FacebookがChromeブラウザのAPIに初めて貢献

Facebookは米国時間4月22日、GoogleのChromeブラウザのAPIに対して、初めて大きな貢献を果たしたことを発表した。

Facebookのチームは、Googleと共同で、ブラウザにコードを提供するためのAPIプロポーザルを作成した。これはFacebookとしては初めてのこと。このコードは、ウェブ上のツールや標準に関するFacebookの他の多くの仕事と同様に、ユーザー体験をスムーズかつ高速にすることを目指したもの。このAPIの場合、ユーザーがクリック、またはキーを操作してから、ブラウザが応答するまでの時間を短縮する。

この新しいシステムの最初の試験的な実装はChrome 74とともにリリースされる予定だ。

一般的に、ブラウザのJavaScriptエンジンは、コードの実行を制御している。そして、応答しなければならない入力が保留になっていないかどうかを確認するため、一瞬コードの実行を停止することもある。マルチコアのマシンで動作する最新のJavaScriptエンジンも、基本的にはシングルスレッドで動作する。そのため、実際にはエンジンは1度に1つのことしか実行できない。そこで、入力イベントを確認しつつ、コードの実行をどのように組み合わせるかということがカギとなる。

「他の多くのサイトと同様に、私たちもJavaScriptを小さなブロックに分割することでこの問題に対処しています。ページがロードされている間も、若干のJavaScriptを実行し、その後にブラウザに制御を戻すのです」と、Facebookチームは発表の中で説明している。「ブラウザは、そこで入力イベントのキューをチェックして、ページに通知する必要のあるものがあるかどうかを確認できます。その後ブラウザは、JavaScriptのブロックが読み込まれる都度、それらを実行する動作に戻ります」。

ブラウザがこのようなサイクルで動作している際に、新しいイベントをチェックして、その処理に入ると、わずかながら余計な時間がかかる。それが何度も積み重なると、ページのロードが遅くなる。とはいえ、入力のチェックのインターバルを長くすると、こんどはブラウザの応答が鈍くなるので、ユーザー体験が劣化してしまう。

これを解決するため、FacebookのエンジニアはisInputPendingというAPIを作成した。これにより、上のようなトレードオフをする必要がなくなる。Facebookは、このAPIを、W3Cのウェブパフォーマンスのワーキンググループにも提案した。これを利用すれば、デベロッパーは保留中の入力があるかどうかを、コードの実行中に確認できる。

これにより、コードは応答すべきものがあるかどうかを自分でチェックできるようになる。ブラウザに完全に制御を戻さなくてもよく、さらにそこからJavaScriptエンジンに入力を引き渡す必要もない。

現時点ではこれはまだ試験的なもの。デベロッパーは、このAPIを自分のコードに組み込む必要があるため、Chrome 74のリリース後に、自動的にブラウザの動作が速くなるというわけではない。この試行が成功すれば、もちろんデベロッパーはこのAPIを利用するようになるだろうし(もちろんFacebookは自ら利用するだろう)、他のブラウザベンダーもそれぞれのエンジンにこのAPIを実装するようになるはずだ。

「ChromeにisInputPendingを導入するプロセスは、Facebookにおいてウェブ標準を開発する新しい方法を象徴するものです」とチームは言う。「私たちは今後も新しいAPIに取り組み続け、オープンソースのウェブブラウザへの貢献を増強したいと考えています。将来的には、このAPIをReactのコンカレントモードに直接組み込むことも可能となるでしょう。そうすれば、デベロッパーはこのAPIのメリットを、自動的に享受できるようになります。さらに、isInputPendingは、スケジューリングに関するプリミティブをウェブに導入するという大きな流れの一環なのです」。

画像クレジット:Getty Images上のAlexander Koerner/Getty Images

原文へ

(翻訳:Fumihiko Shibata)

Rendertron によるダイナミック レンダリング

多くのフロントエンド フレームワークは、コンテンツの表示に JavaScript を使用しています。そのため、Google がコンテンツをインデックスに登録したり、インデックスに登録されたコンテンツの更新に時間がかかる場合があります。

昨年の Google I/O では、この問題の回避策としてダイナミック レンダリングが議論されました。ダイナミック レンダリングの実装方法はいくつかあります。このブログでは、Rendertron を使用したダイナミック レンダリングの実装例を紹介します。Rendertron は headless Chromium をベースとしたオープンソース ソリューションです。

ダイナミック レンダリングを検討すべきサイト

あなたのサイトにアクセスする検索エンジンやソーシャル メディア ボットが、すべて JavaScript を実行できるわけではありません。Googlebot が JavaScript を実行するのには時間がかかり、こちらに示すようにいくつかの制限が存在します。

ダイナミック レンダリングは、変更頻度が高く、表示に JavaScript を必要とするコンテンツに対して有用です。

また、ハイブリッド レンダリング(Angular Universal など)を検討することで、あなたのサイトのユーザー エクスペリエンス(特に first meaningful paint までの時間)を向上できる可能性があります。

ダイナミック レンダリングの仕組み

ダイナミック レンダリングとは、特定のユーザー エージェントに応じて、クライアント側でレンダリングされるコンテンツとプリレンダリングしたコンテンツを切り替えることを指します。

JavaScript を実行して静的 HTML を生成するにはレンダラが必要になります。Rendertron はオープンソース プロジェクトであり、headless Chromium を使用してレンダリングを行います。シングルページ アプリでは、頻繁にバックグラウンドでデータを読み込んだり、コンテンツをレンダリングするための作業で遅延が発生したりすることがあります。Rendertron には、ウェブサイトでレンダリングが完了したタイミングを判定するメカニズムがあります。Rendertron は、すべてのネットワーク リクエストが完了し、未処理の作業がなくなるまで待機します。

このブログ投稿で扱う内容

  1. サンプルのウェブアプリを確認する
  2. 小規模の express.js サーバーを設定して、ウェブアプリを配信する
  3. ダイナミック レンダリング用のミドルウェアとして Rendertron をインストールして構成する

サンプルのウェブアプリ

「kitten corner」ウェブアプリは JavaScript を使用して、さまざまな猫の画像を API から読み込み、グリッド形式で表示します。

グリッド形式で猫の画像が表示され、ボタンでさらに画像を表示できます。可愛いと思いませんか?

以下がこのウェブアプリの JavaScript です。

  const apiUrl = 'https://api.thecatapi.com/v1/images/search?limit=50';
  const tpl = document.querySelector('template').content;
  const container = document.querySelector('ul');

  function init () {
    fetch(apiUrl)
    .then(response => response.json())
    .then(cats => {
      container.innerHTML = '';
      cats
        .map(cat => {
          const li = document.importNode(tpl, true);
          li.querySelector('img').src = cat.url;
          return li;
        }).forEach(li => container.appendChild(li));
    })
  }

  init();

  document.querySelector('button').addEventListener('click', init);

このウェブアプリでは、Googlebot でまだサポートされていない最新の JavaScript(ES6)が使用されています。Googlebot がコンテンツを認識できるかは、モバイル フレンドリー テストを使用することで確認できます。

モバイル フレンドリー テストより、このページがモバイル フレンドリーであることがわかりますが、スクリーンショットには猫が一切見当たりません。見出しとボタンは表示されていますが、猫の画像がまったく表示されていません。

この問題は簡単に修正できます。こうした修正は、ダイナミック レンダリングを設定する方法を学習するための良い練習となるでしょう。ダイナミック レンダリングにより、ウェブアプリのコードを変更せずに Googlebot に猫の画像を認識させることができます。

サーバーの設定

ウェブアプリを配信するために、node.js ライブラリの express を使用してウェブサーバーを構築します。

サーバーのコードは以下のようになります(プロジェクトの完全なソースコードはこちらをご覧ください)。

const express = require('express');
const app = express();

const DIST_FOLDER = process.cwd() + '/docs';
const PORT = process.env.PORT || 8080;

// Serve static assets (images, css, etc.)
app.get('*.*', express.static(DIST_FOLDER));

// Point all other URLs to index.html for our single page app
app.get('*', (req, res) => {
 res.sendFile(DIST_FOLDER + '/index.html');
});

// Start Express Server
app.listen(PORT, () => {
 console.log(`Node Express server listening on http://localhost:${PORT} from ${DIST_FOLDER}`);
});

こちらで実際の例を試すことができます。最新のブラウザを使用しているのであれば、複数の猫の画像が表示されるはずです。パソコンからプロジェクトを実行するには、node.js で次のコマンドを実行する必要があります。

npm install express rendertron-middleware
node server.js

次に、使用しているブラウザで http://localhost:8080 を指定します。ここからはダイナミック レンダリングを設定します。

Rendertron インスタンスのデプロイ

Rendertron は、URL を取得して、headless Chromium によってその URL の静的 HTML を返すサーバーを実行します。Rendertron プロジェクトの推奨事項に沿って、Google Cloud Platform を使用します。

新しい Google Cloud Platform プロジェクトを作成するためのフォーム

新しい Google Cloud Platform プロジェクトを作成するためのフォームに関しては、無料枠でプロジェクトを作成できる点に注意してください。また、この設定を本番環境で使用すると、Google Cloud Platform の料金体系に応じた課金が発生する点にも注意してください。

  1. Google Cloud Console で新しいプロジェクトを作成します。入力フィールドにある「プロジェクト ID」をメモします。
  2. Google Cloud SDK をドキュメントに説明されているとおりにインストールしてログインします。
  3. 以下のコマンドで、GitHub にある Rendertron リポジトリのクローンを作成します。
      git clone https://github.com/GoogleChrome/rendertron.git
      cd rendertron
  4. 次のコマンドを実行して依存関係をインストールし、パソコンに Rendertron を構築します。
      npm install && npm run build
  5. 次の内容の config.json という新しいファイルを rendertron ディレクトリに作成して、Rendertron キャッシュを有効化します。
      { "datastoreCache": true }
  6. rendertron ディレクトリから次のコマンドを実行します。「YOUR_PROJECT_ID」は、手順 1 でメモしたプロジェクト ID に置き換えます。
      gcloud app deploy app.yaml --project EURE_PROJEKT_ID
  7. 任意のリージョンを選択して、デプロイを確定します。デプロイが完了するまで待ちます。
  8. YOUR_PROJECT_ID.appspot.com(「YOUR_PROJECT_ID」は、手順 1 でメモしたプロジェクト ID に置き換えます)をブラウザに入力します。入力フィールドといくつかのボタンがある Rendertron のインターフェースが表示されるはずです。
Google Cloud Platform に導入した後の Rendertron の UI

Rendertron のウェブ インターフェースが表示されたら、Rendertron インスタンスが正常にデプロイされたことを意味します。次の手順で必要になるため、プロジェクトの URL(YOUR_PROJECT_ID.appspot.com)をメモします。

サーバーへの Rendertron の追加

ウェブサーバーは express.js を使用しており、Rendertron には express.js ミドルウェアがあります。server.js ファイルのディレクトリで、次のコマンドを実行します。

npm install --save rendertron-middleware

このコマンドにより、npm から rendertron-middleware がインストールされます。これで、rendertron-middleware をサーバーに追加できます。

const express = require('express');
const app = express();
const rendertron = require('rendertron-middleware');

bot リストの構成

Rendertron は、ユーザー エージェントの HTTP ヘッダーを使用して、リクエストが bot からのものなのか、ユーザーのブラウザからのものなのかを判断します。Rendertron には、比較に使用できる、適切に整理された bot ユーザー エージェントのリストがあります。Googlebot は JavaScript を実行できるため、デフォルトではこのリストに Googlebot は含まれません。Rendertron に Googlebot リクエストもレンダリングさせるには、ユーザー エージェントのリストに Googlebot を追加します。

const BOTS = rendertron.botUserAgents.concat('googlebot');
const BOT_UA_PATTERN = new RegExp(BOTS.join('|'), 'i');

Rendertron は後でこの正規表現とユーザー エージェントのヘッダーを比較します。

ミドルウェアの追加

bot リクエストを Rendertron インスタンスに送信するには、express.js サーバーにミドルウェアを追加する必要があります。ミドルウェアはリクエストしているユーザー エージェントを確認し、既知のボットからのリクエストを Rendertron インスタンスに転送します。次のコードを server.js に追加します。必ず「YOUR_PROJECT_ID」を Google Cloud Platform プロジェクト ID に置き換えてください。

app.use(rendertron.makeMiddleware({
 proxyUrl: 'https://YOUR_PROJECT_ID.appspot.com/render',
 userAgentPattern: BOT_UA_PATTERN
}));

サンプル ウェブサイトをリクエストする bot は Rendertron から静的 HTML を受け取るので、コンテンツを表示するために JavaScript を実行する必要がありません。

設定のテスト

Rendertron の設定に成功したかどうかをテストするには、もう一度モバイル フレンドリー テストを実行します。

最初のテストとは違い、猫の画像が表示されます。HTML タブには、JavaScript コードが生成したすべての HTML が表示され、コンテンツを表示するための JavaScript が Rendertron によって不要になったことがわかります。

まとめ

ウェブアプリに変更を加えずに、ダイナミック レンダリングを設定しました。このような設定により、ウェブアプリの静的バージョンの HTML をクローラに提供できます。

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+

GoogleがChromeのエクステンションを安全にするために来年から制限を厳しくする

Googleが今日(米国時間10/1)、Chrome側からのエクステンションの扱い方がいくつか変わったことを発表した。中でもとくに、多くのパーミッションを要求するエクステンションへの対応が変わり、さらに、デベロッパーがChrome Web Storeで公開するエクステンションには、新たな要求が加わった。

今や公然の事実として、どんなブラウザーでも、ユーザーデータにアクセスするための仕掛けを悪者のデベロッパーが仕込むのは、エクステンションの上であることが多い。Googleは長年、ストアに並ぶ前に悪意あるエクステンションを自動的に検出する努力を積み重ねてきた。またブラウザー本体にもいくつか改良を加え、エクステンションがいたずらできないようにしてきた。今回は、これらの努力をさらに数歩前進させる。

Chrome 70からは、ユーザーが制限サイトのリストを作り、それらのサイトにはホストアクセスができないようになる。デフォルトでは、ほとんどのエクステンションが、ユーザーが訪ねるどんなWebサイトでも見たり操作したりできるから、この制限は重要だ。ホワイトリスト(無害者のリスト)はメンテナンスが困難だから、エクステンションがクリック後の現在ページにのみアクセスできるようにも指定できる。

Googleはこう説明している: “ホストのパーミッションにより、何千もの強力でクリエイティブなエクステンションのユースケースが可能になったが、それらはさまざまな誤用に導きがちだ。それらの中には、悪意的なものもあれば、意図せざるものもある。それらのエクステンションは、Webサイト上のデータを自動的に読んだり変えたりするものが多いからだ”。

Googleが“強力なパーミッション”と呼ぶものをリクエストするエクステンションはどれも、今後はより詳細なレビュープロセスを経なければならない。さらにGoogleは、リモートでホストされているコードを使うエクステンションを仔細に調べる。そのコードが、いつ変えられたか、それとも変えられてないか、分からないからだ。

パーミッションに関してGoogleは2019年に新しい仕組みを導入し、より狭いスコープのAPIにより広いパーミッションの必要性を減らし、またエクステンションに対するユーザーのコントロールを大きくして、エクステンションに対するアクセスの許可をより厳しくできるようにする。2019年からGoogleは、Chrome Web Storeのデベロッパーアカウントへのアクセスに、二要素認証を必須にする。悪者がデベロッパーのアカウントを乗っ取って、ハックされたエクステンションをストア上に公開したりできないようにする。

これらの変更はまだ数か月先だが、今日(米国時間10/1)からデベロッパーは、難読化コード(obfuscated code)の公開ができなくなる。難読化コードだから悪い、とは言えないが、デベロッパーがJavaScriptのソースコードをわかりにくくするために利用することもあり、そうするとレビューする側にとって、そのコードが一体何をしているのかわかりづらくなる。そして悪役エクステンションの70%は、難読化コードでGoogleの目をかいくぐろうとしている。Googleは、既存のエクステンションでも、難読化コードで書かれているものは90日以内にすべて削除する。

ただし、ホワイトスペースやコメントや改行を省いてコードを小さくするのは、許される。

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

開発フレームワーク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

F8:Facebook、React Fiberを発表―JavaScriptのUIフレームワークを完全リニューアル

Facebookはユーザー・インターフェイスを書くために利用されているJavaScriptライブラリ、Reactを根本的にリニューアルしたことをF8デベロッパー・カンファレンスで発表した。これまでFacebookからまったく発表がなかったが、React Fiber(これが新しいReactのプロジェクト名)はしばらく前からFacebookのインターフェイスを動かしていた。Fiberについての噂は昨年から流れていたが、今回FacebookはFiberについて公に語ることができる段階に来たと判断したようだ。

Facebookによれば、この後React16がリリースされればデベロッパーもFiberベースのインターフェイス・ライブラリを利用できるようになるという。すでにFacebook.comで作動しているということは、新しいライブラリはサードパーティーに公開できるレベルに達しているとFacebookでは判断しているはずだ。

これに関連してFacebookではデータ量の大きいアプリケーションを書くためのRelayフレームワークもリニューアルした。

React Fiber

Facebookにインタビューしたところによれば、まずReact Fiberは完全に後方互換性を保っており、現行Reacで書かれたアプリケーションを作動させることができるという。その上でReactをリリースして以来の経験を取り入れて新しいフレームワークを作ったという。Facebookによれば、React Fiberは今後のReactの発展、改良の基礎をなすという。

特に力が注がれたのが、Reactの反応性を高めることだった。私は今週、FacebookのエンジニアでReactのコア・チームの一人、Ben Alpertにインタビューした。AplertによればFacebookのチームは「Reactを開発するときいつも心がけているのはデベロッパーができるだけ素早くアプリを開発できる環境を作ることだ。アプリを開発労力を軽減すると同時にパフォーマンスと反応性を改善できるよう努力している」という。【略】

しかしなぜReactをゼロから書き直したのか?  Alpertは「現行のコード・ベースに問題があったわけではない。しかし将来の拡張を考えると全く新しいコード・ベースに切り替えるのがよいと考えた」と語った。つまり新しいReactは拡張性に優れているということなのだろう。

Alpertは Fiberが基本的に後方互換だとしたが、同時にこれまでのReactのメジャー・アップデートでもそうだったが、現行システムと互換性がない新しい機能がいくつか含まれることも強調した。ただしチームはこれがデベロッパーにとって問題をもたらすことはないだろうと考えている。

Relay Modern

今日、FacebookはFiberに加えて新しいRelayも発表した。これはデータ・ドリブンのアプリを書くためのJavaScriptフレームワークで、Fiberの場合と同様、アップデートの中心は反応時間の短縮などパフォーマンスの改善と拡張性の強化に置かれている。デベロッパーはFacebookのソーシャルグラフ、GraphQLに対してRelayとReactを組み合わせて検索を行っている。

今回発表されたRelay Modernを利用することによってパフォーマンスが改善されるだけでなく現行Relayのいくつかの制限が取り除かれるという。今日の発表で開発チームは「Relay Modernは現行Relayの良い点、つまりコロケーションされたデータやデータ定義を簡単に参照でき、デクララティブなデータのフェッチが可能だという点を維持しながら、APIの使い勝手を改善し、新機能を追加した。さらにパフォーマンスを改善し、フレームワーク自体のサイズも小さくした」と述べた。多くの改善の中で、特に重要なものはスタティック・クエリーと事前のオプティマイゼーションをサポートしたことだという。

スタティック・クエリーというのは簡単にいえば、ランタイムの条件によって結果がそのつど変化しないような検索を意味する。こうした検索は事前に準備してFacebookのサーバーに作動を任せることができる。つまりローカル・アプリで構成された複雑な検索条件をネットワークを介してFacebookに送る必要がなくなる。アプリはクエリー名の文字列を送信するだけ多くの変数を含む複雑な検索結果を素早く得ることができる。これと関連して、事前オプティマイゼーションはRelayのコンパイラがクエリーの構造を事前に知ることができるため、あらかじめ最適化を行いサーバに格納された検索を高速に実行できるようにする。つまりユーザーは検索結果をこれまでより速く得ることができる。この他React Modernにはビルトインのガーベージ・コレクションなどの機能が追加されている。

古いRelayを利用していたデベロッパーにはRelay Modernに移行するための互換性APIが提供される。

Facebookによれば、AndroidアプリのMarketplaceタブを現行Relayから新しいRelay Modernに置き換えたところ、反応時間が平均して900ms短縮されたという。それだけ聞けばたいした改善ではないように思うかもしれないが、モバイル環境では1秒1秒がものをいう。0.9秒の短縮はユーザーがアプリの反応性が良くなったことに十分気づくレベルだろう。

[原文へ]

(翻訳:滑川海彦@Facebook Google+


【以上】

2016年のプログラミングのトレンドを振り返る

Aerial view of container terminal

編集部:この記事はCrunch Networkのメンバー、 Martin Puryearの投稿。Puryearは14週間でフルスタックエンジニアを養成するブートキャンプ、 Coding Dojoのカリキュラムとテクノロジーの責任者。

今年の1月、私はTechCrunchへの寄稿で2016年の主なプログラミング上のトレンドを予測した。

ソフトウェアの開発というのは非常に変化の速い分野だ。ぴかぴかの新しい開発言語、フレームワーク、ツールについての議論は賑やかだが、上位レベルのプログラミングのトレンドを正確に予測するのはたいへん難しい。まず私の2016年の予測がどの程度当たったおさらいしてみよう。

最新のJavaScriptが急成長する

JavaScript/ECMAScript version 6(通常ECMAScript 2015あるいはES6)は2015年の6月にリリースされた。私は2016年にはこの言語が広く採用され、デベロッパーが新しいバージョンに慣れるにしたがって新たサポートされた機能がウェブに普及するだろうと予測した。この予測は概ね当たった。

主要なブラウザすべてとNode.js(オープンソースのJavaScriptランタイム)の90%はES6準拠となった。この頃では、ES6は実験的、実験的な小さなシステムや内部利用に限られるツールに埋め込まれているだけでなく、さまざまな製品や主要顧客が直接触れるようなインターフェイスにも採用されている。既存のプログラミング遺産に縛られないユーザー、AirbnbGoogleなどはES6のシンタックスを社内のプログラミングのスタイルガイドとして利用している。

ただしES6は普遍的、全面的に採用されたわけではない。一部のシステムは旧バージョンのJavaScriptをレガシーとしてサポートし続ける必要がある。デベロッパーはの多くはES6の記法を使いたくても、レガシー・ブラウザを使うユーザーを置き去りにするわけにはいかない。そのためtranspilerpolyfillsといった新しいES6で書かれたコードを古いJavaScript向けにコンバートするツールが利用されている。

ただしES6の新しい機能をすべてのJavaScript環境がサポートするには至っていない。たとえば多くの環境で末尾呼び出し最適化がサポートされていない(Safari 10と iOS 10はありがたいことに例外だ)。この表はどのコンパイラやブラウザがES6のどのシンタックスをサポートしているかの一覧でたいへん便利だ。JavaScriptの旧バージョンは一夜にして消えはしない。しかし2016年を通してES6は急速に普及を続けた。新年にリニューアルされたサイトはほとんどがES6互換の環境に移行しているだろうと予想する。というわけでES6に関する予想は十分正確だったと思う。

BaaS―バックエンド・アズ・ア・サービス

BaaSつまりBackend as a serviceも予測どおり2016年のシステム開発の主要なトレンドになった。BaaSはクラウドストレージやノーティフィケーションなどプロジェクトの中で繰り返し行われる定型的処理の実行にサードパーティーのサービスを使う手法だ。BaaSを利用することによってデベロッパーは自分の得意分野に開発、運用の努力を集中することができる。バックエンドAPIの利用が盛んになっているのはフロントエンドのフレームワークがこうしたBaaSに接続しやすい形に変化してきたからだ。

デベロッパーはコンポジションと呼ばれるテクニックを多用するようになってきた。コンポジション方式の場合、システムいくつかの小さな部品(アプリケーション)から組み立てられる。このような構成の場合、小さな部品は容易にサードパーティーから入手できる。

私は特に今後ブログラミングのパラダイムがどう変化するかに興味を持っている

注意:前回の投稿で私は人気のあるBaaSの例としてParseを挙げた。記事が発表されたすぐ後にParseの所有者のFacebookはBaaSとしてのParseの運用を近く中止すると発表した。Parseを使い続けるつもりなら、ユーザーはそれぞれ独自にParseサーバーを構築し、 2017年1月28までにそちらに移行する必要がある。

イメージ管理と配布管理

2016年にはDockerPackerなどが予想どおりデベロッパーの主要なツールとなった。 これらのサービスは デベロッパーはコンテナと呼ばれるマシン・イメージを簡単かつ素早く生成ないし複製することがができる。コンテナはソフトウェア、そのランタイム、システム・ツール、言語ライブラリーなどがバンドルされどんなプラットフォーム上であれ実行するのに必要な要素をすべて備えている。デベロッパーは軽快なバーチャルマシンの上で素早くプロトタイプを作ることができる。ここにはバージョン管理機能がビルトインされているので、複数のサーバー環境であっても矛盾のないアップデートが可能だ。マニュアルでサーバーのプロビジョニングをするというのは本質的に時間がかかり間違いが起きやすい作業となる。そこでこうした面倒な作業を自動化するBaaSが急速に普及したのは当然だろう。

これに関連してVagrant(開発環境の設定の自動化)、 PuppetChefAnsible(コンフィグレーション管理)などのツールにも人気が出た。コンテナ・ベースの開発はますますデベロッパーにとってますます標準的なものとなりつつある。この傾向が今後原則するとは考えられない。

関数型プログラミング言語への依存が強まる

Haskell、Clojure、Scalaのような関数型プログラミング言語は2016年を通して普及を続けた。こうしたサーバーサイド言語を採用するプロジェクトが増えたのはスマートフォンやIoTデバイスの爆発的な増大によるものだ。コンピューター、タブレット、スマートフォン、IoTガジェットの数が増え、ますます強力になるにつれてサーバーの処理能力がシステムのボトルネックとなってきた。大量の「つながったデバイス」からのリクエストを処理するためにはサーバーの能力をアップする必要がある。処理能力の不足は反応の遅れをもたらし、ユーザー体験を著しく下げる。

関数型プログラミング・モデルは基本的にステートレスだ。 ソフトウェアの各部分を複雑な同期処理なしに多数の異なるCPUないしマシン上で効率的かつ容易に並行動作させることができるようになる。オブジェクト志向言語に比べて関数型言語のパラダイムが本質的に優位なのはウェブからのリクエストのような並列処理の場合だ。

マテリアル・デザインと共通パターンへのシフト

2016年にはビジュアル・デザインの分野でも興味ある進展があった。 予期されたことだが、Googleはすべての分野でビジュアル要素としてマテリアル・デザインを採用したプロダクトの数を増やしている。システム(ChromeOS、Android)、アプリケーション(Chrome、Drive、Google Play Music)、ウェブサイト(YouTube,、AdSense)、それにウェブ検索もマテリアル・デザインになった。サードパーティーのAndroidアプリ、Slack、Twitter、Spotify、Airbnb、Wikipediaがマテリアル・デザインを採用しており、AsanaからGeekbenchに至る多数のウェブサイトもビジュアルをマテリアル・デザインに準拠している。

ただし他のプラットフォーム((iOS、Tizen、Windows、MacOSなど)ではマテリアル・デザイン採用の動きは見られない(Ubuntuには多少の影響がある)。他のプラットフォームのデベロッパーは独自のデザイン・ポリシーを推進している。

デザイン分野での私の予測が当たったのは一部に限られるようだ。改めて2017年を予測するなら、サービスやアプリケーションにおける伝統的な視覚的デザインの役割は減少し、非視覚的なインターフェイス(Amazon Alexa、Siri、Cortana、Google Home)や別の視覚的要素(仮想現実、拡張現実)を利用したインターフェイスが普及期を迎えると思う。

結論

2016年のソフツには数々の興味ある進展があった。2017年にはさらなる発展が期待される。これにはコンテナや関数型言語の一層の普及、JavaScriptがアプリ開発に占める役割のさらなる増大などが含まれるだろう。私は特に今後ブログラミングのパラダイムがどう変化するかに興味を持っている。デベロッパー諸氏の考えを聞きたいところだ。

画像: Bernhard Lang/The Image Bank/Getty Images

[原文へ]

(翻訳:滑川海彦@Facebook Google+

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+

TumblrでApple Live Photoの再生が可能に、ライブラリもオープンソースで公開

screen-shot-2016-09-20-at-4-05-27-pm

Tumblrは本日、ウェブ上でAppleのLive Photosのサポートを開始した。同時に他のウェブ開発者が同じことを行なえるツールも公開している。同社は、任意のウェブサイトでLive Photosの公開を可能にするオープンソースのJavaScriptライブラリ「Laphs」 ‐ 正式名称「Live Anywhere Photos」 ‐ をリリースした。ウェブ上のLive Photoを実際に動かすには、クリックしてそのまま押し続ければ良い。モバイルでも同様だ。

AppleのLivePhotosは、iPhone6sと6s Plusから導入されたファイルフォーマットだ。静止画と短い動画を組み合わせたもので、ユニークな再生体験を生み出している。ウェブ上でこの効果を再生するために、TumblrはユーザーがiOSデバイスからLive Photoを投稿した際に、静止画(,jpeg)と動画(.mov)の両方のコピーを受け取る。そして、すべてのブラウザで正常に再生できるように、.movファイルを.mp4ファイルに変換するのだ。

その後Tumblrは、そのLaphsソリューションを用いて、.jpegと.mp4ファイルを組み合わせてLive Photoの効果を再構成し、Live PhotoをTumblerのウェブ上で再生する。

実はTumblrは既に、Live Photosを初期のうちから取り込んでいた。iPhoneの3Dタッチ対応スクリーンを使用して、押すと動く静止画を表示していたのだ。そして押せば画像は動き出して、あなたの写真にハリーポッターのような感覚を与えてくれる。

Live Photosは、Tumblrで絶大な人気があるGIFに似ているため、モバイル上での新しいフォーマットのサポートに素早く動いたのだ。実際、それはそれを実現した最初のサードパーティサービスとなった – 結局Facebookには数週間Google Photosには数ヶ月先行することになったのだ。またそれは、モバイル上のGIF Maker機能を用いて、Live PhotoをGIFに変換することもサポートしていた。。

Screen Shot 2016-08-25 at 1.53.58 PM

今やLaphsを使って、TumblrはLive Photosの更なる利用を自身のサイトを超えて推進して行くことが可能になった。そして、同社はAndroidにもLive Photoを持ち込むと言っている。

Tumblrのサイト上のLive Photoは、おなじみの同心円のLive Photoのアイコンが表示される。これは、当該画像の左上に表示される。

たとえば、このTumblrの新機能についてのアナウンス記事の中でLive Photoの例を見ることができる。動きのあるLive Photoを表示するには、ただマウスでクリックしてそのまま押し続けていれば良い。

[ 原文へ ]
(翻訳:Sako)

Microsoftが行ったブラウザーテストではEdgeがエネルギー効率最良、ラップトップを長時間使える

browser_comparison_energy

かつては、ブラウザーの性能は速度で評価され、各製品がJavaScriptのベンチマークの成績を競った。しかし、スピードは今でも重視されるが、デベロッパーの関心はエネルギー効率の方が上位になっている。今は、ラップトップでWebを閲覧する人が多いからだ。でもMicrosoftが以前、同社のEdgeブラウザーは競合製品のChromeやFirefoxやOperaよりもエネルギー効率が良い、と発表したときには、おもしろい議論が湧き起こった。

そのMicrosoftが今日(米国時間9/15)は、Windows Anniversaryリリースにおける最新版のEdgeの数字を引っさげて、再びリングに戻ってきた。今回もやはり勝者はEdgeで、独自の省エネモードをonにしたOperaよりも成績が良い。Microsoftによれば、Edgeのニューバージョンは、同社のWeb閲覧シミュレーションで行ったブラウザーのテストではページのレンダリングが旧バージョンより12%効率が良い。そのほかのブラウザーも今回のテストでは性能がアップしており、やはり、ブラウザーのテストはときどきやるべきだな、と思わせる。

browser_energy_2

今回のMicrosoftの結果では、Edgeはラップトップ上で他のブラウザーよりも23%から69%、電池寿命が長い。最近大量の、エネルギー効率関連のアップデートを行ったChromeも、FirefoxやOperaに比べると相当良い(上図)。ビデオをストリーミングした場合のテストでは、ラップトップの電池の保(も)ちがFirefoxを62%上回った。

Microsoftのテストスイートのソースコードは、GitHubで入手できる。テストはもっぱらWindows 10の上だけだから、Safariのデータはない。でもAppleは、OS X上のブラウザーの中ではエネルギー効率はSafariが最高、と主張したいだろう。

この記事が出たらOperaやMozilla、それにGoogleからきっと反論が来るだろう。そのときは、この記事をアップデートしよう。

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

Facebookが新しいオープンソースプロジェクトでReactの敷居を低くする

BERLIN, GERMANY - FEBRUARY 24:  The Facebook logo is displayed at the Facebook Innovation Hub on February 24, 2016 in Berlin, Germany. The Facebook Innovation Hub is a temporary exhibition space where the company is showcasing some of its newest technologies and projects.  (Photo by Sean Gallup/Getty Images)

FacebookのReactは、JavaScriptで手早くアプリケーションとそのユーザーインタフェイスを作りたいときのための、オープンソースのライブラリだ。ただし、実際の話はこれほど単純ではない。Reactでアプリケーションを作るためには、JavaScriptのほかにも、いろんなツールを勉強しなければならないのだ。

FacebookはReact用の自社のツールについて語っているが、でも個人のデベロッパーやスタートアップの多くは、Facebookのような企業が持ってるリソースがない。

そこで、もっと多くの人がReactで仕事ができるために、同社は今日(米国時間7/22)、新しいオープンソースプロジェクト”Create React App”(Reactアプリケーションを作ろう)を立ちあげた。それは、あるハッカソンから生まれたプロジェクトで、Reactでアプリケーション開発を始めるために必要なツール集合を、たった一つのコマンドラインツールにまとめたものだ。

[Marcはあとちょっとで彼のReactの”hello world”アプリケーションを実装できるところだった]〔実際には複雑すぎてできなかった〕

FacebookのDan Abramovが今日の発表声明で次のように述べている: “従来、このようなプロジェクトはうまく行かないことが多かった。しかし先日、Christopher [Chedeau]がぼくに、複数の’React CLI’(Reactコマンドラインインタフェイス)を作り始めたけど、Facebookには無視された、と言った。コミュニティにも、同じような目標のツールが存在している。でも今のところは、それほど人気がない”。

Create React App(すごい分かりやすい名前だ!)の場合は、構成ファイルというものがない。環境のセットアップは、自動的に行われる。しかも、デベロッパーが手にするのは単一のツールだ。だから依存性も単一だ。しかし内部的には、JavaScriptやReactのエコシステムの既存のツールをたくさん利用している(Webpack, Babel, ESLint, などなど)。

このツールがユーザーをロックインしないことも、強調されている。この種のサービスでは、よくあることだが。ユーザーはつねに単一のコマンドを発行し、それが基本的にやるのは、ユーザーの構成を‘イジェクト’して、依存性を新しいプロジェクトへ構築することだが、プロジェクトはCreate React Appには依存しない。

Abramovはこう書いている: “‘イジェクト’によっていつでもCreate React Appの居心地の良いセットアップを去ることができる。コマンドを一つ発行するだけで、ビルドのすべての依存性、構成、そしてスクリプトがユーザーのプロジェクトへ移動する。その時点でユーザーは必要なものを何でもカスタマイズできるが、しかしそれはわれわれの構成をフォークして自分の道を進むことだ”。

これによって初心者がReactを使い始めるのが容易になるが、しかし経験豊富なデベロッパーでも、この新しいツールをは試してみたくなるだろう。

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

「Cola」は開発者が地図やフライト確認などのアプリを自由に付け足せるメッセージアプリ

4d2f871f-6ce6-4823-83d8-704ca4d8a79e

チャットにアプリを埋め込めるメッセージングアプリのColaは誰でも新しいアプリケーションを組み込めるようにするための開発者キットを公開した。

本日更新されたバージョンには、メッセージングアプリの中で動作する12個の「バブル」と呼ばれる実質的なアプリケーションが含まれている。ユーザーは中で使われる個別のツールのアカウントを作ることなく、天候やフライト情報、GIF、その他の情報を共有することができる。同社が優先するのは他人と基本的なタスクを行う際の壁の高さを下げることである。メッセージアプリを離れることなく2人が共有ToDoリストをチェックする場合を考えてみると良いだろう。

Cola自身が提供する新しいバブルに加えて、開発者はバブル開発キットを用いてメッセンジャーのために新しい機能を作成することが可能だ。AppleのApp Storeと同様に、Colaはユーザーを保護するための承認プロセスを用意している。

10人のチームが、2014年以来Colaを開発していて、ユーザーは今年の3月からアプリケーションを使うことができるようになっている。昨年末に、Naval Ravikantは130万ドルのシードラウンドを主導した。この時はRavikantのAngelListシンジケートも参加しているが、その中にはAOLの創設者スティーブ・ケースも含まれている。

メッセージングクライアントのプラットフォーム化を決意した企業はColaが最初ではない。Heymarketはビルトインされたアプリのようなテンプレートを使用して中小企業が顧客と連携するためのメッセージングプラットフォームを開発しているし、AtlassianのHipChatは、Slackに類似したチームのためのメッセージング機能を提供していて、Dropbox、Github、Trello、BlueJeansそしてUberまでもが統合されている。

市場の空白を探す努力の結果、Colaは消費者をターゲットにしている。そのサービスはユニークではあるものの、それはまだ基本的にFacebookのメッセンジャー、AppleのiMessage、GroupMe、WeChatなどと競合するものだ。

Colaの制限の1つは、コンテンツを発見し送るためにはアプリの中から行わなければならないということだ。例えばGIF画像を送信したいときに、Giphyでそれを開くことはできない。Colaのユーザーがそれを送信するためにはGiphyバブルを使う必要がある。また、統合のメリットを最大限に活用するためには、送信者と受信者の両方がColaをダウンロードしておく必要がある。

アプリのUIは非常に基本的なものだ。とはいえ加えられたシンプルさは欠点を上回っている。私たちが馴染んでいるマテリアルデザインではないが、きちんと動作しわかりにくいものでもない。

エンジニアリングの観点から言えば、各バブルは独自のサンドボックス内で実行されるので、失敗したメッセージがアプリケーション全体を巻き込んでダウンさせてしまうことを心配する必要はない。Colaはそのサービスがスムースに運用されることを狙って、Facebookによって主導されているオープンソース技術のReact Nativeを活用している。開発者はネイティブ「バブル」アプリケーションをJavascriptを使って開発する。

Colaのバブル(泡)は便利だが、クリティカルマスに達するユーザーを引き込むには、何らかのキラーフィーチャーが必要だろう。開発を外部へ公開することによって、利用者が単に欲しいと思うだけではなく本当に必要とする機能をColaが提供できる可能性は高まるだろう。

[ 原文へ ]
(翻訳:Sako)

GoogleのAngular 2フレームワークがいよいよベータへ…今やES5よりもTypeScriptが人気

angular2

モバイルアプリとWebアプリケーションをHTMLとJavaScriptで作るためのGoogle製のフレームワークAngular 2が、ベータに入った。

GoogleがAngular 2を最初に発表したのは2014年の9月で、そのときはAngular 1と激しく違うことが論争になった。それから、アルファとデベロッパプレビューを経過した。Angular 2に‘ベータ’のラベルが付いたことは、そろそろ本格的なアプリケーション開発に使える、という意味だろう。Google自身はすでに、AdWordsやGoogle Fiber、社内的なCRMシステムGreenTeaなどのプロジェクトでAngular 2を使っている。

angular-2-code

Angular 2は今でもメインの用途はWebアプリケーションの開発だが、しかしNativeScriptとReact Nativeにより、AndroidとiOSのクロスプラットホームなネイティブアプリも作れる。

もうひとつGoogleが力を入れたのが、スピードだ。Googleによると、Webページのアップデートの表示はAngular 1の7倍速い。

本番リリースまでに、まだやるべきことが二つある、とGoogleは言っている。ひとつは、このフレームワークのバイナリサイズを縮小すること。もうひとつは国際化のサポートを改善しアノテーションをサポートすることだ。これらのほかにも、ドキュメンテーションや、起動時およびランタイムのパフォーマンス、Material Designのコンポーネント、などの部分でも今後さらに改良や充実化が行われる。

担当ディレクターのBrad Greenによると、ベータ以前の段階でも小さな変更がいろいろ加えられた。“最近の大きな変化としては、ケバブケースの成分名をキャメルケースに統一し、JavaScriptと同じ名前を使えるようにしたことだ”、と彼は述べる。“また、最近のJavaScriptはいろいろなツールやプロセスを使うので遅くなりがち、ということも学んだ…トランスパイラ(transpiler, ソースコード変換)、ビルドツール、ミニファイヤ(minifier, 圧縮)、継続的インテグレーションのスクリプト、デプロイメント、最小限でもこんだけあるね”。

Greenによると、Angular 2をMicrosoft作のTypeScriptで書くという決定はデベロッパたちに歓迎されたし、今ではAngular 2によるアプリケーションをTypeScriptで書くデベロッパが増えているようだ。“まだES5で仕事を続けたいデベロッパが多いはず、とわれわれは想定した。だからTypeScript派が多いことは、意外だった”。

彼のチームは最近、いろんなツールをコマンドラインから使えるためのAngular CLIというプロジェクトを立ち上げたそうだ。

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

RePhoneはどんな物でも携帯電話に変えられるキット

bed9a210e0c6dbe777aee0dceb8f7e88_original1

携帯電話を作るのは簡単だ。鉱山へ行って鉱石を掘り出して様々な金属を抽出し、別の鉱山から作った部品を追加する。次にFCCの認可を取ってリチウムイオン電池を作る。最後に、Snakeゲームを書く必要がある。これができない人は、RePhoneを試してみよう。

このプロジェクトは小さな回路基板にSIMスロットとオプションの画面を付けたものだ。Bluetoothにも対応している。49ドルでKit Createという腕時計風のシステムを買えば小さなケースと必要なモジュールが付いてくる。まるでアンロックされた携帯電話が50ドル以下で手に入るようなものだ。

これは明らかに実験用基板だが、一週間前に私が試したところかなりよく動いた。Arduino IDE、Lua、およびJavascriptのプログラミングライブラリーあり、携帯電話をウェブやIFTTTにも接続できる。

これは小さくて楽しいプロジェクトでちゃんと使える。配線に使う金を自分で発掘したりチップの製造を学ぶ体験は得られないが、すばやく簡単に携帯電話を作れることは、われわれ採掘権を持たないホビースト全員にとって最高の贈り物だ。

fbf28c6b3bf4ed2682e488662708b638_original

[原文へ]

(翻訳:Nob Takahashi / facebook

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