JavaScript – HTML5Experts.jp https://html5experts.jp 日本に、もっとエキスパートを。 Sat, 07 Jul 2018 03:14:05 +0000 ja hourly 1 https://wordpress.org/?v=4.7.19 Vue.js製フレームワークNuxt.jsではじめるUniversalアプリケーション開発 /potato4d/24346/ Fri, 13 Oct 2017 01:49:45 +0000 /?p=24346 Vue.jsでUniversalなSPAを開発できるフレームワークであるNuxt.jsのバージョン 1.0のリリースがいよいよ近づいてきました。

本稿では、シングルページアプリケーション（以下 SPA）開発によって生じた問題を解決するために生まれたサーバーサイドレンダリング （以下 SSR）を中心に、Vue.jsでの開発を強力にサポートするNuxtについて、その魅力と基本的な使い方をご紹介いたします。

Nuxt.jsとは？

Nuxt.js org

Nuxt.js（ナクストと読みます）はReact.jsベースのSSR用フレームワークであるNext.jsに触発されて作成された、Vue.jsベースのフレームワークです。

特にUIの描画サポート に主眼をおき、SSRをはじめとした様々なサポートを行ってくれるものとなります。

Nuxt.jsでできること

それではそのNuxt.jsではどのようなことができるのでしょうか。

現在挙げられている主な機能一覧としては以下のようなものがあります。
（現在準備中のv1.0向け日本語訳プロジェクトから抜粋。私も一部関わっております）

  • Vueファイルで記述できること
  • コードを自動的に分割すること
  • サーバーサイドレンダリング
  • 非同期データをハンドリングするパワフルなルーティング
  • 静的ファイルの配信
  • ES6/ES7のトランスパイレーション
  • JSとCSSのバンドル及びミニファイ
  • Head要素の管理
  • 開発モードにおけるホットリローディング
  • SASS, LESS, Stylus などのプリプロセッサのサポート
  • HTTP/2 push headers ready
  • モジュール構造で拡張できること

こうして見てみると、Nuxt.jsが提供する機能は 「SSR 基盤の提供」と「コードを書きやすい環境を提供するもの」 、そして「拡張性の高い構造を提供するもの」 の3つと考えることができます。

SSR基盤としての優秀さ

Vue.jsの2系からはコアでSSRのシステムを内蔵しており、単体でもSSRを行うことは可能ですが、より円滑に、かつ柔軟なシステムをNuxt.jsでは提供しています。

単純なレンダリングだけの場合はVue.jsのものを利用しても簡単におこなうことができますが、Nuxt.jsではそれに加えルールに基づいた自動的なルーティングやプリコンパイル、

<meta>
タグの編集などが可能となっており、より効率的なSSR基盤の構築が可能となっています。

モダンなVue.jsによる開発環境の提供

Nuxt.jsでは、vue-loaderベースでのVue.jsでの標準的なコーディング環境や、 画像などのアセットのパスの解決、そしてSassなどのCSSプリプロセッサの対応など、webpackなどのビルドツールの設定を必要とするものが一通りサポートされています。

その上で、それらの基本的な構成をまとめたボイラープレートをnuxt-community/starter-templateとしてNuxt.jsコミュニティが公式で提供しており、webpackなどのモジュールバンドラやbabelなどのビルドシステムに精通していない人でも簡単にモダンな環境を構築することが可能となっています。

また、これらのテンプレートはVue.jsコミュニティ公式のスキャフォールディングツールである

vue-cli
を利用してセットアップが可能となっており、すぐに開発をはじめることが可能です。

ミドルウェアやasyncDataなどの拡張システムの提供

また、Nuxt.jsでは、ミドルウェアやasyncDataという構造・システムを利用することで、SSR結果に非同期処理（例えばAPIからのデータフェッチ）の結果を出力・その後SPA側からデータストアとして参照できるシステムがあります。

これを利用することにより、記事データを取得した上でOGPとして出力を行うことや、i18n処理の結果をHTMLとして流すなど、様々なことができるようになります。

Nuxt.jsを利用すべきシーン

メディアやSNS 、求人サイトなどをSPAとして立ち上げる場合・運用している場合

SPAとして立ち上げるサイトやWebサービスの中では、SEOやOGP、Twitter Cardを重視すべきものというのは非常に多く存在します。

メディアサイトなどであれば、そもそもWordPressなどで運用するほうが筋が良い場合も多いでしょうが、SNSや求人サイトの場合は、SPAのほうが都合が良い場合も存在します。

SNSでの事例でいえば、今のTwitter Lite（モバイル版）ではReactが使われていたり、求人サービスであるSCOUTERなどはサービス全体をVue.jsのSPAとして構築されており、個々の投稿やアカウントなどの情報をSSRしたいであろうサービスが SPA 化されていることは多くなってきました。

そういった場合のSEO、OGP生成エンジンとして、比較的一般的なディレクトリ構成がなされているNuxt.jsを採用する、Nuxt.jsへと移行するというということは選択肢として十分現実的なものです。

技術系ドキュメントの運営

技術ドキュメントの運用にも有効活用が可能です。

Nuxt.jsには、独自の機能としてnuxt generateが存在しており、このコマンドを利用すると、Nuxt.jsで作られたものを全て静的サイトとして、ルーティングをそのままに書き出すことが可能となります。

Markdownで原稿は管理を行い、Vue.jsの強力なコンポーネントシステムのもと、デザインを効率的に管理する。ということが可能です。Nuxt.jsの公式ドキュメントは、この手法にて管理されています。

いわゆる一般的なホームページ制作

驚くかもしれませんが、一般的なホームページ制作においてもNuxt.jsは大きく貢献してくれます。

Vue.jsのコンポーネントでは

Scoped CSS
を利用することが可能となっており、CSSの影響範囲についての考慮を最小限できるためコーディングのスピード化に貢献するほか、ライブリロードなどの効率的な開発基盤が既に整っているからです。

また、本稿では詳しくは紹介しませんが、Nuxt.jsはプログラムから呼び出すことも可能であるため、お問い合わせだけをExpress.jsで受けるということも実現可能です。

実際にPush7というサービスのWebサイトはi18n化をmiddlewareで、メール受け付けをExpressで実装しました。

Nuxt.jsをはじめる

それではいよいよNuxt.jsを利用して実際にアプリケーションを作成してみましょう。

まずはサンプルプロジェクトを作成した後、実際にAPIと連携するWebサイトを構築してみます。

プロジェクトのセットアップと実行

プロジェクトの初期化にはvue-cliを利用しましょう。ターミナル上で以下を実行してください。

$ npm install -g vue-cli # 既に vue-cli を導入されているかたについては不要です
$ vue init nuxt-community/starter-template nuxt_sample

これを行うことで実行したディレクトリに新たにnuxt_sampleという名前でプロジェクトが作成されます。

これで一通りのファイルはセットアップされていますので、そのまま依存関係をインストールしてサーバーを立ち上げてみます。

パッケージ管理については、Nuxt.js自体がYarnで管理されているため、個人的にはYarnを用いることを推奨します。

$ cd nuxt_sample
$ yarn
$ yarn dev

実行した段階でプリコンパイルが実行され、完了次第 http://localhost:3000/ にてアクセスが可能であることが確認できるようになっています。実際にアクセスしてみます。

Nuxt Starter 初期ページ

このように表示された時点で成功です。

Nuxt Starter 初期ページ ソースコード

ページのソースコードを見ると、きちんとSSRされて結果が出力されていることがわかります。

APIからデータを取得してSSRするページを作成する

基本的なサーバーの起動はここまでで完了したので、ここからはルーティングの追加と非同期データの取得を行っていきます。

ここでは誰でも利用できるPublicなAPIとして、GitHubのユーザー情報を参照する API を利用し、ユーザー情報を表示してみます。要件としては、以下を満たすものの開発とします。

  • https://developer.github.com/v3/ を利用したデータ取得を行う
  • /users/:id
    形式でそれぞれのユーザーにアクセスする
  • ユーザー情報からIDと名前を取得し、アイコン画像と共に表示する

ルーティングを追加する

まずはルーティングを追加してみます。

Nuxt.jsにはファイルに応じたルーティングの自動生成機能がありますので、これを有効活用して作成します。

今作ったnuxt_sampleのプロジェクトルート内の

pages/
ディレクトリ内にusersディレクトリを作成し、さらにその中に _id.vueファイルを作成します。

内容については、index.vueの中身をコピーしておくと良いでしょう。

ディレクトリ構成

完成したディレクトリ構成はこのようになります。

このようにファイルを配置することで、Nuxt.jsがルーティングを解釈し、

/users/:id
のリクエストについては全て_id.vue を参照するようになります。

さらに、アクセス時にURLパラメータのオブジェクト内にidというキー名で格納されます。

これを例えば_nickname.vueなどとした場合は、idの代わりにnicknameというキーで保存されます。

これでひとまずルーティングの作成は完了です。

ページ内でHTTPリクエストを行い、結果を取得する

次は_id.vueの中でGitHubからデータをフェッチしてみます。

まずはHTTPリクエストのためにaxiosをインストールします。

$ yarn add axios

その上で、_id.vueを以下のように記述します。

<template>
  <section class="container">
    <img :src="`https://github.com/${user.login}.png`" :alt="user.name">
    <h1>{{user.name}}</h1>
  </section>
</template>

<script>
import axios from 'axios'

export default {
  async asyncData ({ params }) {
    const { data: user } = await axios.get(`https://api.github.com/users/${params.id}`)
    return {
      user
    }
  }
}
</script>

<style>
.container {
  min-height: 100vh;
  display: flex;
  justify-content: center;
  align-items: center;
  text-align: center;
  flex-direction: column;
}

.container img{
  margin-bottom: 20px;
  border-radius: 50%;
  overflow: hidden;
}
</style>

ここでポイントとなるのはasyncDataの記述です。

通常のVue.jsでは、データの保持について、 

data(){}
形式で関数を定義し、その戻り値をデータとして利用しますが、これを 
asyncData(){}
に置き換えることで、SSR時に非同期のデータを取得した上で、SSRに流し込むことが可能となります。

また、Nuxt.jsではデフォルトでasync/awaitの変換用のbabel-presetも導入されていますので、モダンな記法でこのように取得することが可能となっております。

実際に表示をみてみる

ここまで完了した段階で、実際に表示を見てみましょう。

現在サーバーが立ち上がっているなら自動で読み込まれているためそのまま

/users/potato4d
を。

もし一度落としているなら、再度

yarn dev
を行った上で
/users/potato4d
にアクセスしてみましょう。

SSR 結果サンプル

このように表示されると成功です。

SSR 結果サンプルソースコード

ソースコードを見ると、正しくSSRされた結果が返ってきていることがわかります。

このように、asyncDataと、axiosなどのHTTPライブラリを組み合わせることによって、Web APIからの取得結果をSSRに流すことが可能となります。

これを用いることにより、例えばサービス内の投稿について、ツイートされたときにコンテンツを表示する。Twitter CardやOGPなどを正しく表示する。ということが可能となります。

最後に、このサンプルについては私のGitHub上に掲載しておりますので、お手元にすぐNuxt.jsを試す環境がない場合は適宜ご参照ください。

おわりに

ここまででNuxt.jsの基本とできること・活躍しやすいシーンをご紹介した後に、簡単なサンプルアプリケーションを作るところまでを行ってみました。

実案件で投入する際は、新規でないとディレクトリやビルドシステムの移行コストがそれなりに存在しますが、新規においては効率的な開発にも大きく貢献し、将来的なSSR要望にも先んじて対応を行うことができます。

基本的にSPAの後からのSSR対応というものは非常にコストがかかるものでもありますので、これからのSPA開発においては、Nuxt.jsの存在は、開発効率化ツールとしても、また、SSRだけではない統合開発フレームワークとしても無視できないものになってくると考えております。

Nuxt.js単体がフロントエンド開発のフレームワークとして一定以上の存在意義をもつ未来や、ほかのNode.js製のフレームワークと組み合わせてのレンダリング用フレームワークとして利用される未来も十分にあるでしょう。

近々1.0のリリースが行われることで、rcにて大量にあったBreaking Changesについてもひとまずは収まることが予想されますし、日本語ドキュメントの1.0追従も盛んに行われております。

もし活躍できるシチュエーションに遭遇した時は、Nuxt.jsを是非利用してみると良いでしょう。

参考資料

本稿の執筆にあたって参照した情報ソースとなります。

]]> JSエンジン「V8」はバージョン6で世代移行を終える ── Google I/O 2017レポート /furoshiki/23289/ Tue, 12 Sep 2017 01:00:47 +0000 /?p=23289 連載： Google I/O 2017特集 (3)

ChromeやNode.jsで利用されているJavaScriptエンジン「V8」に、8年の歴史の中でも大きな変化が訪れました。8月3日にリリースされたバージョン6.1で、数年かけて進めてきたJavaScriptコンパイラーが世代交代を終えました。詳しい話は、V8のブログでも語られていますが、ここでは大きなトピックであるコンパイラーの世代交代についてお話します。

なお、この動きについては、昨年に開かれたカンファレンス「BlinkOn 6」でも語られており、Google I/O 2017でも、Seth Thompsonによるセッション「V8, Advanced JavaScript, & the next performance frontier」によって紹介されています。本記事では、これらの発表内容を補足してご紹介します。

V8のミッションとは？

Chromeで使われているJavaScriptエンジン「V8」ですが、そのミッションはとてもシンプルです。

「Speed up real-world performance for modern JavaScript, and enable developers to build a faster future web.(実世界での要求にあわせてモダンなJavaScriptのパフォーマンスを向上させること。そして、今後の変化していくWebに早く追従し、開発者がそれらをビルドできるようにすること)」

V8のパフォーマンス改善につきまとう2つのトレードオフ

V8とはなんでしょう？JIT(just-in-time compile)で動作させることができるJavaScriptのエンジンです。ブラウザがJavaScriptを受け取ると、ブラウザはそのコードをトランスレートして実行したり。また、コードを翻訳してコンピューターが理解できるネイティブコードにコンパイルしてから実行します。

ただ、そこにはいくつかのトレードオフが存在します。

  1. コンパイルして生成されたネイティブコードは、実行されるピーク時の速度が早い一方で、コードの量が多いほど、最初に実行されるまでに遅延が発生する。一方で、トランスレーターを使った場合は、実行されるまでの遅延は小さいけど、実行時の速度が遅い。
  2. JavaScriptエンジンは、パフォーマンスを良くしようとするとメモリの消費量が多くなる。一方で、省メモリを進めようとするとパフォーマンスは悪化する。

例えば、以下のような一行のfunctionを呼び出すコードについて考えてみましょう。

このコードでは、 function foo() は一度しか呼び出されていませんよね。このケースでは、実行されるまでの速さ（Fast Startup）を重視し、実行時のパフォーマンス（Peak Perf）は重要視しません。

しかし、以下のケース。

1万回も function foo() を呼び出しています。このケースでは、Fast Startupが遅れてでも、Peak Perfを重視する必要がでてきます。 foo() はネイティブコードにコンパイルされていなくてはいけません。そしてそれがデスクトップ型のコンピューターであれば、メモリも潤沢なので、大量のメモリ消費を犠牲にネイティブコードをさらに幾度に渡り最適化させます。

ただ、これはあくまでデスクトップ型コンピューターの場合。同じ1万回 foo() を呼び出すコードであっても、モバイルの場合は同じアプローチにはなりません。Androidデバイスはモバイルなので、デスクトップと同じようにメモリを扱うことはできません。

ネイティブのコードへコンパイルはされますが、メモリの消費量は抑えられるよう最適化は制限されます。

別のパターンについても考えてみましょう。それが以下のコード。

これはNode上で実行されているコードです。一度起動されたら、ずっと利用されるわけですから、当然、Fast Startupを犠牲にしてPeak Perfを改善しようとしますね。しかし…

IoTデバイス上で動作するとなると、同じ状況とは言えません。サーバー用マシンとは異なり、メモリ消費は抑えなくてはいけません。Peak Perfを上げるようにはしますが、それはメモリ消費が少なくて済むようなアプローチで進めます。

同じ一行のfunction呼び出しであっても、その最適化方法は無数にあり、コンテキストやデバイスの状況に強く依存するのです。そしてそれは、Fast Startupなのか、あるいはPeak Perfに最適化していくのか、メモリを富豪的に扱うのか、それとも小さくなるよう努力するのか、解決しなくてはいけません。

8年前のリリース時点から全てが変わろうとしているV8

V8エンジンは、ここまでに説明したあらゆる状況で最適化できるようにしたり、また新しいパターンのJavaScript（asm.js, WebAssembly等）に対応できるよう、2〜3年かけて実行パイプラインを作り変えました。

過去の変遷を見てみると。

2008年のリリース時点の段階では、シンプルなコードジェネレーターがあって、そこからやや最適化を行ったマシンコードが生成されるだけでした。あらゆるJavaScriptのコードは、この仕組を使って実行されます。

ただ、最適化には計算が必要なため、コードを実行できる状態にするまでに多くの時間を要します。大量のJavaScriptコードを扱う場合は、Startup Time短縮するために最適化の処理をスキップすることが求められます。

2010年にコンパイラ「Crankshaft」が追加されます。計算コストの高い最適化処理を分離し、Crankshaftにその責務が委譲されました。コードの生成だけであれば、Full-codegenは最小のコストでマシンコードを吐き出すため高速なため、Startup Timeが最適化されます。そして、CrankShaftを使ってコンパイルすれば、計算コストを犠牲にPeak Perfにとって最適なマシンコードが生成されます。

実行時に、CrankShaftが吐き出したコードを、Full-codegenが吐き出したコードへ置き換えることで最適化を図ります。

2015年。Crankshaftには限界が来ます。JavaScriptの仕様そのものが大きく変化する時代になりましたが、Crankshaftはその設計上、JavaScriptの機能をサポートしきれず、また新しいパターンのJavaScript（asm.js, WebAssembly等）にも十分に対応できませんでした。当時のフロントエンドエンジニアなら、V8のECMAScript標準への対応の遅れに苛立ちを感じたはずです。

V8開発チームは、それを改善しようと新たなコンパイラ「TurboFan」を追加します。

2016年。「Ignition」と呼ばれる仕組みを追加しました。Ignitionには、ソースコードをいきなりマシンコードにするのではなく、バイトコード(マシンコードほどハードウェアに依存しない「中間コード」と呼ばれるもの)を生成するコンパイラーと、それを実行するインタプリターが内包されています。

そして、TurboFanはバイトコードを扱う形へと作り変えられました。そして現在、最新のVersionである5.9では、この2つの仕組みは既に使われていません。内部にコードこそ存在していますが、バイトコードの生成と解釈するインタープリターIgnitionと、PeakPerfを改善するための処理をするコンパイラーTurboFanだけで動作しているという状況です。

そして、これからまもなくリリースされる6.0では、コードとして完全にV8から削除されます。

「Ignition Interpreter」とは？

中間コードを生成して実行するインタプリター。メモリ消費が小さく動く、Fast Startupも最適という特徴があります。

  • モバイルなどのメモリの小さな環境で動かすのに最適。
  • Startup Timeに最適化すべきコードの実行に向いている。
  • TurboFanと組み合わせることで、実行速度を最適化できる。

「TurboFan」とは？

主として、最適化を行うことを目的としたコンパイラー。

  • 使われ方としては、拡張的な感じ。ただ、あらゆる新しいJavaScript機能に対応していき、その場合も活用される。
  • WebAssemblyのバックエンドでもある。
  • 最近はtry/catch/finallyとか、ES2015+の最適化が可能になった。

まとめ

V8について、メモリ管理向けガーベジコレクター「Orinoco」など、さまざまな技術要素が進化し、語り尽くせないほどのトピックがあるのですが、それはまた別の機会にお話しましょう。TurboFanへの完全移行、実態としてすでにほとんど終わった状況といっても過言ではありませんが、8年前とは全く異なる、Web・JavaScriptの変化に追従する大きな変化です。今後も楽しみですね。

]]> Node.jsでSlack Command Botをつくってみよう /girlie_mac/22535/ Fri, 03 Mar 2017 00:00:22 +0000 /?p=22535 こんにちは。ごぶさたしています。以前の執筆から１年ちょっとになるのですが、その当時はInternet of Things(IoT)について書いたのですが、最近では市場がある程度まで到達したからでしょうか、それとも脆弱性の問題を問われることが多くなったせいでしょうか、話題は少し落ち着いてきたかに思われます。さて今ホットな話題は何でしょうか、ということで今回はChat Botsについて書いてみようと思います。

E-Commerceから Conversational Commerceへ

ここ最近話題になることが多いAIやBotsですが、私の周りではConversational interface、Conversational UXなどという言葉が去年からたびたび使われるようになっているようです。

これはAmazon Alexaなどのデバイスや、Facebook Messengerなどチャットアプリケーションなどの対話型テクノロジーをいかに活用しその使い勝手をよくするか、ということなのですが、必ずしもアプリケーションのUIデザインそのものを述べているわけではなく、既存のサービスを延長することを指していることも多いでしょう。例えば、今まではモバイル上のアプリケーションのみで車を呼べていたUberが、Facebook Messenger のチャットからも車をを呼べるような機能を加えたり、Slack上でTaco BellからタコスをオーダーできるTacoBot、というのもが挙げられます。

Slack Botを書いてみよう

さて、というわけで何かBotを書いてみたいと思いませんか？ここはNode.jsでSlack botを作成する方法を紹介したいと思います。

このチュートリアルでは、ディベロッパー向けのHTTPステータスコードのルックアップができるスラッシュ・コマンドを作ってみます。ここでは私が５年ほど前に何気なく作って、Mashableなどで紹介され思わぬ反響を得てしまったHTTP Status Catsを使ってみます。具体的には、Slack上でユーザが、/httpstatus [code] （例えば /httpstatus 404）と入力すると、そのステータスコードの意味と猫が一緒に表示される、という簡単なbotです。

まず試してみたい方は、HTTP Status Cats command for Slackを自分がアドミン権限のあるのチャットチームにインストールしてみてください。

slack-httpstatuscats gif animation

さて、このチュートリアルは２つのパートに分けられます。

  1. スラッシュ・コマンドを書いて、自分のSlackチームにインストールする
  2. OAuthを使ってボットをSlack’s App Directoryなどで誰もがインストールできるようにする

とりあえず動くbotを書いてみたい、と思う方は１だけ試してみてで十分ですが、botをみんなにシェアしたい方は２も読んでみてください。

ソースコードと実際のボットのインストールボタンは両方GitHubにあります。では始めましょう！

1 プライベートなスラッシュコマンドボットの作成

ここで作るのは、Slackの公式な用語でいうところのCustom Integrationsというもので、自分のチャットグループ専用のプライベートなbot、もしくはいわゆるAppとして発表する前にドライ・ランを行うことを指します。アカウントを持っていない方はまずサインアップしてから始めましょう。

1.1 スラッシュコマンドの設定

ログインして、my.slack.com/services/new/slash-commandsでコマンドを選びます。ここでは/httpstatusと入力しAdd Slash Command Integrationボタンをクリックして次のステップへ進みます。

Tokenなどの欄がありますが現時点では、(1) Command、 (2) URL、 (3) Method、の３つが必要になります。

slack-config-custom-integration

(1)には、/httpstatus、(3)には、POST、そして(2)のURLは次のように設定してください。

開発中に使用するURLを取得するにはngrokを使ってみましょう。いろいろなツールがあるのですが、これは自分のローカルホストをパブリックURLとしてトンネルできるというとても便利なツールなので私のイチオシです。開発途中にデプロイすることなく、Webhookが手軽に使えます。自分のローカルホスト、たとえば http://localhost:3000/ をつかったままOAuthのテストもできるのです。（注：よく聞かれるのですが、ngrokはあくまでも開発ツールですのでプロダクションには適していません。デプロイメントに関しては最後の章を読んでください）

https://ngrok.com/から自分のマシンにngrokをインストールしたら、ターミナルで自分の使いたいポート番号（このチュートリアルでは 3000）を設定します。

$ ngrok http 3000

すると下のスクリーンショットのように、Forwardingアドレスが取得できるので、そのURL（例えばhttps://71f03962.ngrok.io/)をSlackセッティングの、上のスクリーンショットで示された(2)の欄で使います。

ngrok

すべての設定が終えたらSaveボタンを押します。”Your settings have been saved!”のメッセージが画面上部に現れるのを確認してください。

1.2 Node.js を使ってレスポンスを書く

基本的にbotは、ユーザがSlackインターフェイス上でコマンドを実行した際HTTP POST（または設定次第では GET)によって指定先のURLにメッセージが届け、プログラムでその応答をユーザに返す、という作業になります。

たとえばそのユーザが/httpstatus 302というコマンドを送信した場合、指定URLに送られるデータは次のようになります。

command=/httpstatus
text=302
response_url=https://hooks.slack.com/commands/1234/5678
…

Botは、これに対する応答をユーザに返します。この場合はユーザが尋ねているステータス302の定義とこの猫を返しましょう。

ではそのコードを書いてみましょう。

まず、Express.jsとbody-parserをインストールします。

$ npm install express body-parser --save

index.jsで、expressのインスタンスを作り、先ほどngrokで設定したポート番号、3000でサーバを始動します。

'use strict';
const express = require('express');
const bodyParser = require('body-parser');
const app = express();
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

const server = app.listen(3000, () => { 
console.log('Express server listening on port %d in %s mode', server.address().port, app.settings.env);});

次はHTTP POSTルートメソッドで、コマンドを扱います。

app.post('/', (req, res) => {
 let text = req.body.text;
 // ここでbotを書きます
});

ここでtextの値を取得します。HTTP Status botの場合、/httpstatus コマンドの値、例えば”404″が textの値になります。同時に、ユーザが数字以外を入力した際にエラーメッセージを送るなどのエラーチェックもしておきましょう。

if(! /^\d+$/.test(q.text)) { // not a digit
 res.send('Error: enter a valid status code, such as 200');   
 return;
}

このエラーは、ユーザだけにプライベートに送信されるメッセージでチャットそのものには表示されません。

エラーがない場合は、コマンドに対する応答をJSONとしてレスポンスします。

let data = {
 response_type: 'in_channel', 
 text: '302: Found',
 attachments:[{
   image_url: 'https://http.cat/302.jpg'
 }]
};
res.json(data);

response_typeをin_channelとすることで応答はチャットメンバー全員に見えるように送信されます。デフォルトはその逆のephemeralで、コマンドを送ったユーザのみに表示されます。

このコマンドと応答は次のようになります。

slack-command

このサンプルコードでは、応答をわかりやすくハードコードで示してありますが、実際はストリングなどは別のファイルに定義しています。下のスクリーンショットのように存在しないHTTPステータスに対してのエラーメッセージも定義しましょう。実際のコードはソースコードを参照してください。

slack-command-private

ディスプレイはボーダー色などのカスタマイズが可能です。詳しくはSlackドキュメンテーションのBasic message formattingを参照してください。

次のステップでは、このボットを自分のチャットグループ以外に配布するために必要な認証とコードのデプロイについてです。

2. Slack Botのディストリビューション

この「Custom Integration」をインストール可能な「App」にするには、コードのデプロイをして他のチャットにもインストールできるようにせねばならないのですが、そのためにはあといつくかのステップが必要になります。

2.1 Appセットアップ

まず、自分のAppを申請し、クライアントIDやシークレットなどのクレデンシャルを取得します。https://api.slack.com/appsでCreate an Appボタンをクリックしてください。

slack-create-app

このフォームにはいくつもの欄があり少しわかりづらいのですが、スラッシュコマンドのbotには次の3つが最低必要になります。

2.1.1 API Keyを.envファイルに保管

ここで取得したClient ID、Client secret、Verification tokenは .env ファイルに別に保管してbotのメインのコードから切り離すことを推奨します。gitを使う場合は、このファイルを .gitignore ファイルに付け加えるのを忘れずに。

SLACK_CLIENT_ID=12345XXXXX.09876XXXXX 
SLACK_CLIENT_SECRET=535d2f9....
SLACK_VERIFICATION_TOKEN=42P829U...

2.1.2 Foremanを使う

他にも手段はありますが、Herokuにデプロイするために私はNode Foremanを使っています。Foremanを使うには、npmを使ってglobalフラッグでインストールしてください。

$ npm install -g foreman

アプリケーションの Root に .procfile を作成し、この一行を加えます。

web: node index.js

index.jsを実行するには node index.jsの代わりに次のコマンドを使います。

$ nf start

2.2 ユーザの認証

Slackは認証にはOAuthを使っています。実際には自分でOAuthを実装しなくても、Slack ボタンを使えば簡単に認証できるようになっています。

公式のドキュメンテーションのダイアグラムに手を加えて、流れをわかりやすくするためにGIFアニメーションにしてみました。

slack-oauth gif animation

ここでの実際のフローは次のようになります。

  1. ウェブページを作成し、認証ボタンを置く。ユーザがボタンをクリックするとパラメータがSlackに送信される(ユーザは認証ページにリダイレクトされる)。
  2. Node appには、SlackからGETで10分だけ有効な仮のコードが送られる。
  3. アクセストークンを得るために oauth.access API使い認証コードをPOSTする。Node app側から`200 OK`を受け取り次第、このプロセスが完了。
  4. オプションとして、このトークンを使ってSlackの他のAPIにもアクセス。例えば、認証後、ユーザをhttps://team-name.slack.comにリダイレクトするなど。/

2.2.1 Slack ボタンの設定

Slackボタンを使うには、まずウェブページを作成してください。私の場合はこのNode Appとは切り離した別のHTMLページを作成し、GitHub Pagesにホストしました。

次にボタンを設定しましょう。 https://api.slack.com/docs/slack-button に行き、Add the Slack button までスクロールして下さい。

slack-generate-button

このボタン作成ツールのCommendsのチェックボックスをチェックします。

上で示したフローの４を実行したい場合は、このGETパラメータを下のように変更します。

<a href="https://slack.com/oauth/authorize?scope=commands+team%3Aread&client_id=your_client_id">

ここでscopeに着目してみてください。commandsの他にteam:read(コロンは%3Aとエスケープ)が必要になります。詳しくはOAuth scopes on the Slack API docsで。

slack-button

2.2.2 トークンの発行

さて、Nodeコードに戻りましょう。仮のコード(req.query.code)をGETで取得するためにまたExpress.jsを使います。

何でもよいのですがここでは/slack routeを使いましょう。この場合ngrokのURL は http://71f03962.ngrok.io/slack のようになります。Slack App設定ページ（https://api.slack.com/apps/YOUR_APP_ID/oauth）の、OAuth & Permissions セクションにある、Redirect URLの欄にはこのURLを設定してください。

仮のcodeを取得されたら、それを自分のAPIクレデンシャルとともにPOSTで送って、トークンと交換します。POSTするためにここではNode.jsのHTTPリクエストクライアントである、Requestを使いましょう。

$ npm install request --save

仮のcodeを取得し、それをtokenと交換するコードが下になります。

const request = require('request');

app.get('/slack', function(req, res){
 let data = {form: {
   client_id: process.env.SLACK_CLIENT_ID,
   client_secret: process.env.SLACK_CLIENT_SECRET,
   code: req.query.code
 }};

 request.post('https://slack.com/api/oauth.access', data, function (error, response, body) {
   if (!error && response.statusCode == 200) {
     // おしまい！
     // ここからはオプションでチーム情報を取得
     let token = JSON.parse(body).access_token; // Auth token
   } ...

2.2.3 オプショナル： ユーザをチームURLにダイレクトする

認証が済んだらそこで終えてもよいのですが、この画面でユーザを置き去りにするのはあまりよいUXとはいえないので、チームページにリダイレクトしてみましょう。

リダイレクトURLのサブドメインとなるチーム名はteam.infoAPIで取得できます。

このAPIを使うにはトークンが必要なので前述のコードでの、トークンにアクセスする箇所に下のコードを追加します。

...
request.post('https://slack.com/api/team.info', {form: {token: token}}, function (error, response, body) {
 if (!error && response.statusCode == 200) {
   let team = JSON.parse(body).team.domain;
   res.redirect('http://' +team+ '.slack.com');
 }
});

これで API からチーム名(team.domain)が返されました。最終的にこれを使ってチームURLにリダイレクトしてできあがり！

このチュートリアルでは簡素化したコードを使いましたが、全ソースコードはGitHubで見てみてください。

2.3 サーバにデプロイする

最後にデプロイしておしまいです。APIクレデンシャルのenv vars設定を忘れないように！私はHerokuを使っているのですが、Herokuの場合、heroku configコマンドを使います。例えば、heroku config:set API_KEY=123456というふうに設定してください。

Slackの設定で画面で指定したngrok URLを、デプロイ先のURLに変更するのもお忘れなく。

さて、プロセスが少し面倒ですが、コード自体は簡単だったと思います。もし何か面白いボットを作った際にはぜひ教えてくださいね！

slack-worked

]]> VR成功の鍵はWebVRにあり！？ ── HTML5 Conference 2016セッションレポート /edo_m18/21153/ Thu, 20 Oct 2016 00:00:07 +0000 /?p=21153 連載： HTML5 Conference 2016 特集 (3)

セッション内容を講演者自らが解説するという「HTML5 Conference 2016特集」の第三弾。今回のテーマは「Webのグラフィックス後編: WebGL2、そしてWebVR」。
すでに策定が始まっている次期バージョンWebGL2.0のお話や、WebでVRを実現する「WebVR API」を用いてVRコンテンツの実装の仕方を解説します。

VRとは？

今年、2016年はVR元年と言われ、様々なVRデバイス、VR関連ガジェット、VRコンテンツが世に生み出されています。 しかし、VR発祥は意外と古く、遡ること1960年代にVRの基礎となる理論、デバイスが発表されています。

ただ当時は個人で手が出るものではなく、体験自体はデパートのアトラクションとして登場するなど、体験は限定的でした。

352930-sensorama-1962
参考

時を戻して2016年。世界が動き出します。
2016年6月時点のGoogle検索トレンドでは、検索回数が飛躍的に伸びているのが見てとれます。

unnamed

きっとこれを読まれている方も、周りで「VR」というワードを聞くことが増えてきたのではないでしょうか。そしてこの波に乗るように、VRについてもWebでの体験を可能にする技術が公開されています。

WebVRは体験の話ではない

WebでのVR技術、それが「WebVR」です。
取りざたされているVRを手軽にWebで体験できるもの。それが「WebVR」。

…ではなく。
あくまでWebVRはイチ仕様に過ぎません。
つまり、WebVRに対応したからといって、即座にWeb上でVRコンテンツを提供できる、という類のものではないということです。

WebVRはAPIの仕様

誤解を恐れずに言えば、WebVRはセンサーからの情報を扱うためだけのAPIです。
要は、HMD（ヘッドマウントディスプレイ）からの位置、回転、視野情報など様々な、ハードウェアの情報を取り扱うAPIということです。もっと言ってしまえば、モバイルで利用しているジャイロセンサーとなんら変わることはない、ということです。

事実、WebGLの仕様と比べると格段に少ない内容の仕様となっています。（仕様はこちら）

VRコンテンツの構築

Webで手軽に体験できるVRコンテンツ、と書きましたが提供する側が同じく手軽であるとは限りません。
（とはいえ、その他のネイティブなVRコンテンツと比較すると格段に手軽だと思いますが）

WebVRはただのAPIだと書きました。
つまり、VRコンテンツ自体は別のAPI、具体的にはWebGLを利用して3Dコンテンツを制作する必要があります。事実、VRコンテンツの制作について既存の3Dコンテンツの制作と違いはほとんどありません。

WebGLコンテンツでは通常、requestAnimationFrameなどを利用して、一定時間置きに画面を更新しアニメーションやインタラクションを実現します。ジャイロセンサーを使ったコンテンツの制作を行ったことがある方であれば、どういったコンテンツが制作できるのかのイメージがわくでしょう。

そして上でも書いたように、ジャイロセンサーで行っていたような処理をWebVR APIに替えて画面を更新してやればいいのです。

ただし、（当然ではありますが）通常のWebGLコンテンツとWebVRコンテンツでは決定的に違うところがあります。それは「VR体験を作り上げる必要がある」という点です。

具体例を上げましょう。
今までの3Dコンテンツはカメラの位置は製作者側で制御可能でした。
ということはつまり、都合の悪い、カメラの後ろ側を映さないようにカメラを制御することができた、ということです。 しかし、VRコンテンツはそのカメラの操作はユーザーの視点という形で使われるため、当然、その後ろ側を見られる可能性があります。
（というより、ほとんどの場合、ユーザーはあたりを見渡すでしょう）

このように、裏側が見られてしまうということは、悪く言えば手抜き、よく言えば無駄を省いた部分までもしっかりと作り込まないとならないということを意味しています。

基本的なセットアップ方法

さて、それではざっくりとですが、WebVR APIを使ったセットアップのコードを紹介しましょう。
本コードはこちらのサイトのサンプルを引用させていただいています。

▼ HMDハードウェアの参照を取得する

navigator.getVRDisplay().then(function (displays) { if (!displays.length) { return; }

vrDisplay = displays.length[0];

}).catch(function (err) { console.error('Could not get VRDisplay', err.stack); };


▼ 描画対象として必要なサイズを取得する

var eyeParameter = vrDisplay.getEyeParameters('left'); var width = eyeParameter.renderWidth; var height = eyeParameter.renderHeight;


▼ WebGLのCanvasおよびVRモード移行のための処理を記述 var webglCanvas = document.querySelector('#webglcanvas'); var enterVRBtn = document.querySelector('#entervr');

enterVRBtn.addEventListener('click', function () { vrDisplay.requestPresent({source:webglCanvas}); }, false);

vrDisplay.exitPresent();


▼ 画面のアニメーションループを処理する var id = vrDisplay.requestAnimationFrame(onAnimationFrame);

function onAnimationFrame() { id = vrDisplay.requestAnimationFrame(onAnimationFrame); }

vrDisplay.cancelRequestAnimationFrame(id);


▼ HMDのセンサーからの値を取り出す var pose = vrDisplay.getPose();

var orientation = pose.orientation;

var position = pose.position;


▼ ハードウェアに設定された個々の設定を読み取る（瞳孔間距離など） var eyeParameters = vrDisplay.getEyeParameter('left');

var eyeOffset = eyeParameters.offset;

var eyeMatrix = makeProjectionMatrix(vrDisplay, eyeParameters);


▼ 取得した情報から、プロジェクション行列を生成する function fieldOfViewToProjectionMatrix (fov, zNear, zFar) { var upTan = Math.tan(fov.upDegrees * Math.PI / 180.0); var downTan = Math.tan(fov.downDegrees * Math.PI / 180.0); var leftTan = Math.tan(fov.leftDegrees * Math.PI / 180.0); var rightTan = Math.tan(fov.rightDegrees * Math.PI / 180.0); var xScale = 2.0 / (leftTan + rightTan); var yScale = 2.0 / (upTan + downTan);

var out = new Float32Array(16);
out[0] = xScale;
out[1] = 0.0;
out[2] = 0.0;
out[3] = 0.0;
out[4] = 0.0;
out[5] = yScale;
out[6] = 0.0;
out[7] = 0.0;
out[8] = -((leftTan - rightTan) * xScale * 0.5);
out[9] = ((upTan - downTan) * yScale * 0.5);
out[10] = -(zNear + zFar) / (zFar - zNear);
out[11] = -1.0;
out[12] = 0.0;
out[13] = 0.0;
out[14] = -(2.0 * zFar * zNear) / (zFar - zNear);
out[15] = 0.0;

return out;

}

Three.jsを使えばお手軽

WebGLといえばThree.js、というくらいデファクトスタンダードなライブラリとなったThree.js。
実はThree.jsのリポジトリにはWebVRに対応するためのプラグインがすでに存在しています。

それは VRControl.js と VREffect.js の2種類です。
これはどちらもThree.jsでVRを実現するのを手助けしてくれるプラグインです。
VRControl がHMDのセンサーの処理を、 VREffect.js がフルスクリーンモードへの移行や、VRモードの表示を手助けしてくれます。

基本的に、Three.jsを使った3Dコンテンツ制作の方法はVR化すると言っても大きな違いはありません。
その証拠に、VR化するためのコード断片は以下のようにとても短いものとなります。

var controls = new THREE.VRControls(camera); var effect = new THREE.VREffect(renderer);

// clickイベントなどのユーザ操作のタイミングで実行される関数 function toVRMode() { effect.requestPresent(); }

対応ブラウザ

対応ブラウザは、執筆時点（2016/09/28）ではまだ限定的にしか存在していません。
安定版で動作するものは今のところないのが現状です。

対応状況は以下のサイトから確認することができます。
Is WebVR Ready?

VR成功の鍵を握るのはWebVR

個人的な見解ですが、VR成功の鍵をにぎるのはWebVRにあると思っています。
その理由はいくつかあります。

一つ目が、プラットフォーム（Oculus Rift、HTC Viveなど）に依存しないこと。
つまり今までのWebアプリと同様に、モバイル、PCなどのプラットフォームに依存しないコンテンツ展開ができることです。

二つ目に、インストールが不要なこと。ネイティブアプリにしてしまうとどうしてもこの「インストール」という手順が必要になってしまいます。しかし、WebVRであればWebサイトに訪れたユーザが、VRモードの開始ボタンを押すだけでVR体験をすることが可能になります。

そして最後の三つ目として、「ちょっとだけVR」が使えること。
例えばECサイトの商品をVRで見てみる、例えば不動産サイトの部屋の感じをVRで体験してみる、などなど、VRが活用できればユーザの利便性が上がることはたくさんあります。

しかし、例えばこれらを、アプリをインストールしたのちにしか行えないとしたら大部分の人はそれを倦厭するでしょう。

またコンテンツ制作側からしても、そんなちょっとしたVRアプリだけをプラットフォームに載せて配信する、というハードルの高さも出てくるでしょう。

こうしたように、今までの「Webならではの良さ」がそのままVRにも当てはめることができると考えています。そしてこれが結局、VRとユーザの接点となり、より多くの人にVRとはなにか、VRでどんなことができるかを広める機会になると考えています。

まとめ

まとめると、

  • WebVRはAPIの名称
  • WebVR APIがやってくれるのはセンサーの値を取るなどの最低限の処理のみ
  • Three.jsを使えば手軽にVRコンテンツの制作が可能
  • とはいえまだサポートブラウザが（ほぼ）ない
  • しかし、Webでの活用はまだまだ（いい意味で）未知数

ということです。
詳細についてはカンファレンスで使用したスライドがアップされているので、そちらを参照ください。

当日の動画は下記で公開されていますので、こちらも参照してください。（編集部注：動画は3：26：10あたりから比留間さんの講演となります）

]]> Webブラウザで高速な演算を可能にする低水準言語asm.jsと、WebAssembly詳解ーasm.jsの仕組みとコーディング例 /chikoski/18980/ Mon, 25 Jul 2016 00:06:51 +0000 /?p=18980 連載： 低水準言語asm.jsとWebAssembly詳解 (2)

連載の第１回目は asm.jsの紹介と、asm.jsが導入された背景を概観しました。

Just in Timeコンパイルによって高速にJavaScriptを実行できるようになりましたが、立ち上がりが遅い、やり直しが発生する、コンパイルによって一時的に負荷が向上する、といった問題が残されています。

これを解決するためにプログラムの実行を行うより前にネイティブコードへとコンパイルするAhead of Timeコンパイルを導入したいのですが、JavaScriptは柔軟すぎて効率の良いネイティブコードを出力することが難しい、という問題がありました。

asm.jsはこの問題に一定の解をあたえるものとなります。今回はそのasm.jsがどのようなものなのか、JavaScriptの関数を asm.js化しながら解説していきます。

asm.jsがコンパイルされるまで

前述したとおりasm.jsで記述されたプログラムは、実行以前にコンパイルされます。コンパイルは下図のような過程で行われます。

asm.jsがコンパイルされるまで。意味解析とリンク時のチェックが行われ、失敗すると通常のJSとして実行される。

ソースコードが字句解析、構文解析されてAST（Abstract Syntax Tree：抽象構文木）になるところまでは一緒ですが、その後意味解析が行われます。この意味解析でそれぞれの式や変数、関数の型がチェックされます。

意味解析が終了後、プログラムはコンパイルされネイティブコードが出力されます。このネイティブコードはメモリ上に展開されたあと、プログラム中で利用しているJavaScriptの関数やasm.jsに用意されている標準ライブラリとのリンクが行われます。

意味解析とリンク、この2つに失敗する場合もあります。プログラム中に型エラーが発見された場合は前者の失敗します。 後者はメソッドの呼び出しや、JSにエキスポートできない種類のデータを引数に指定した関数呼び出しを行った場合に失敗します。

このような場合、プログラムはasm.jsとして処理されるのではなく、通常のJSとして処理されます。asm.jsがJSのサブセットであることによって、このようなフォールバックも可能になっています。

asm.jsモジュール

asm.jsで書かれたプログラムとして事前コンパイルされる際の単位は、モジュールです。ファイル単位でコンパイルが行われるわけではないので、1つのJSファイルのうち高速化が必要な部分をasm.jsで書き、それ以外の部分は通常のJSとして書くといったことが可能です。

asm.jsのモジュールは、次のようにCやC++のソースコードと似た構造となっています。

function ModuleName(stdlib, ffi, heap){
"use asm";
 // (1) 外部からインポートするシンボルの宣言
 // (2) 関数宣言
 // (3) 関数表の宣言
 // (4) モジュールのエキスポート
}

1の部分では利用する標準ライブラリや、JSの関数、定数などのシンボルを列挙します。ちょうどCのextern宣言と同じような役割です。

2の部分で、それぞれの処理を関数として定義します。asm.jsではオブジェクトやクラスの定義が許されていません。そのため処理はクラスやオブジェクトとしてではなく、あくまで関数として定義します。

3の部分では同じ型の関数をまとめた表を定義できます。ちょうどCでの関数ポインタの機能を代替するものです。関数を直接呼び出すのではなく、この表を参照する形で呼び出すことで、呼び出す関数の振る舞いを変えられるので、多態性を持った関数を定義したい場合に有用です。

とはいえ、いまいちイメージがつかめないかと思います。そこで足し算を行うモジュールをasm.js化しながら、構成を見てゆきましょう。変更するのは以下のようなモジュールです。

function AddFunctions(){
  function add1(value){
    var result;
    result = value + 1;
    return result;
  }
  return {
    add1: add1
  }
}

このモジュールは次のように利用できます。

const module = AddFunctions();
const one = module.add1(0);    // 1
const two  = module.add1(one); // 2

asm.jsディレクティブ

asm.js化の第一歩は、ディレクティブの追加です。”use strict” ディレクティブをつけると、その関数はstrict modeで解釈されるのと同様に、”use asm”ディレクティブをつけることで、処理系はその関数をasm.jsのモジュール定義として処理します。

function AddFunctions(){
  "use asm";
  function add1(value){
    var result;
    result = value + 1;
    return result;
  }
  return {
    add1: add1,
  }
}

　型アノテーション

次にAOTを行うための型アノテーションを行います。型アノテーションは、TypeScriptなどのように型を直接記述する方法が一般的かと思いますが、JavaScriptとしても解釈できなくてはいけないasm.jsでは異なります。同値となるような式を追加することで、型情報を明示します。

明示的に型アノテーションを行う対象は次の3つです。

  • 関数の引数
  • 変数
  • 関数の返り値

これらの情報を元に、関数の型や式の型が決定されます。

引数に対する型アノテーション

引数に対する型アノテーションは、関数本体の先頭で行います。次の例では、add1の引数valueの型はintであることを示す型アノテーションが加わっています。value = value | 0; が型アノテーションを行っている部分です。

function AddFunctions(){
  "use asm";
  function add1(value){
    value = value | 0;
    var result;
    result = value + 1;
    return result;
  }
  return {
    add1: add1
  }
}

引数で利用できる型はint, doubleの2つです。それぞれの型はは次の表のようにアノテーションします。

型 型アノテーション
int value = value | 0
doube value = +value
float value = f(value)

尚、外部で定義された関数呼び出しを行った場合は、floatとして解釈されます。

変数宣言

asm.jsでは、関数内で利用する変数に対しても型アノテーションを行います。これは宣言時に初期値として代入するを適切に選ぶ形で行います。整数値を代入すればintに、実数値の場合はdoubleとなります。

尚、1.0のような小数点以下の数字が0のものは実数値として扱われます。変数宣言に型アノテーションをつけると、先ほどまでのモジュールは以下のようになります。

function AddFunctions(){
  "use asm";
  function add1(value){
    value = value | 0;
    var result = 0; // intとして宣言
    result = value + 1;
    return result;
  }
  return {
    add1: add1
  }
}

返り値に対する型アノテーション

返り値に対して型アノテーションを行います。この情報と引数の型情報とを組み合わせて、関数の型が決定されます。

返り値で利用できるのはdouble, signed, float, そしてvoidの4つの型です。それぞれのアノテーション方法は以下の表の通りです。また即値を書く場合は、アノテーションは必要ありません。

型 アノテーション例 メモ
double return +result;
signed return result 0|
float return f(result) fは関数
void return;

asm.jsの型システム

これまでintやdoubleといった型を利用してきましたが、asm.jsで利用できる型を列挙し、それぞれの継承関係を示すと次の図となります。 矢印の元にある型は先の型を継承しています。

asm.js の型システム http://asmjs.org/spec/latest より引用

継承するということは、何かの制約が厳しくなっていくということです。asm.jsの型システムではnullを許容するか、実行時に割り当てられるレジスタがdoubleかintか、といった点での制約が厳しくなっていきます。

また、JavaScriptで定義されている関数に渡せる型も決まっています。背景色が薄い灰色になっているfixnum / signed / extern / double型のデータのみが許可されています。

型のキャスト

先ほどから変更しているプログラムは、意味解析に失敗します。それは次の部分に原因があります。

result = value + 1;

これはint+fixnumの計算を行い、その結果をint型の変数に代入しようとしています。型エラーの入り込む余地はなさそうに思えます。しかし、この加算の評価値の型はinterishとなっています。そのため、int型へinterish型の値を代入することになり、型エラーが起きるというわけです。

そこでキャストを行い、演算結果の型を明示します。この変更をおこないasm.jsの意味解析に成功するコードは次のようになります。

function AddFunctions(){
  "use asm";
  function add1(value){
    value = value | 0;
    var result = 0; // int として宣言
    result = (value + 1) | 0; // int へキャスト
    return result;
  }
  return {
    add1: add1
  }
}

JavaScriptとの組み込み

以上で、AddFunctionsモジュールをasm.js化することができました。これをJavaScriptのプログラムに組み込みんでいきます。

ここでは 上記で作成したAddFunctionsモジュールをJavaScript側から利用する方法と、AddFunctionsモジュール内で JavaScriptの関数を利用する方法について説明します。

JavaScriptからの利用

asm.jsのモジュールとJavaScriptのモジュールは、JavaScriptからみると区別できません。下記のようにJSのモジュールを呼ぶように利用できます。

const module = AddFunctions();
var one = module.add1(0);
var two = module.add1(one);

function add2(n){
  return module.add1(module.add1(n));
}

JavaScriptの関数をasm.jsから呼ぶには

まず、asm.jsの内部からJavaScriptで定義された関数を呼ぶことはできます。また、Mathオブジェクトの持っているいくつかのメソッドは、標準ライブラリ中の関数として提供されています。

これら関数への参照はモジュールを定義する関数の引数として与えます。例えば、AsmModuleにasm.jsモジュールが定義されている場合、次のように呼び出すことでJavaScriptの関数をasm.js内から呼び出せます。

const ffi = {
  put: n => console.log(n)
};

const module = AsmModule(window, ffi);

asm.jsで定義される関数はオブジェクトの解決ができません。そのため利用する関数はあらかじめ外部からインポートするシンボルとして宣言しておきます。

次の例では、標準ライブラリ中のMath.expとMath.log、そして自作関数であるputを外部からインポートするシンボルとして宣言しています。

function AsmModule(stdlib, ffi, heap){
  "use asm";
  var exp = std.lib.Math.exp;
  var log = std.lib.Math.log;

  var put = ffi.put;

これらの関数は、関数定義内でasm.js内部で定義された関数と同様に呼び出せます。ただ1点注意しなくてはならないのは、引数に渡すデータの型です。標準ライブラリ以外の外部関数に渡せるのはfixnum、signed、extern、doubleのいずれかです。 それ以外の値を渡すとリンクエラーとなり、通常のJSとして実行されます。演算の結果を適切にアノテーションすることで、リンクエラーを避けられます。

var value = 1;
put(value + 1); // リンクエラー
put((value + 1) | 0); // OK

ヒープの利用

asm.jsで定義される関数は、数値演算しかできません。また、オブジェクトの解決もできません。つまり、次のような関数は定義できないことになります。

function caesar(string, key){
  var result = "";
  for(let i = 0; i < string.length; i++){
    result += String.fromCharCode(a.charCodeAt(0)+key);
  }
  return result;
}

ところでC言語では文字列を数値の配列として扱います。この考えを応用すれば、asm.jsでも文字列を数値演算の範囲で扱えるようになります。

上記の関数をasm.jsに書き直すと以下のようになります。

function Caesar(stdlib, ffi, heap){
  "use asm";
  var HEAP = new stdlib.Int8Array(heap);

  function encrypt(key){
    key = key | 0;
    var i = 0;
    for(;(HEAP[i << 0 >> 0] | 0) != 0; i = i + 1 | 0){
      buffer[i << 0 >> 0] = ((buffer[i << 0 >> 0] | 0) + key) | 0;
    }
    return;
  }

文字列はHEAPというArrayBufferに格納されています。このArrayBufferはモジュールの定義時に引数として与えられます。 ArrayBufferのビューは標準ライブラリとして提供されているため、上記のようにモジュール内のHEAPを大域変数として宣言する際にビューもあわせて定義します。

HEAPの添字は、ビューの各要素の大きさに合わせてシフトする必要があります。シフトするビット数は、2を底として要素のバイトサイズのlogをとると求まります。

上記の例で利用しているInt8Arrayの場合、各要素の大きさは1バイトのため、0ビットシフトしています。ビューとシフトするビット数の対応は次の表を参照してください。

ビュー 要素のサイズ（バイト） シフトするビット数 ロード時の型 保存時の型
Uint8Array 1 0 intish intish
Int8Array 1 0 intish intish
Uint16Array 2 1 intish intish
Int16Array 2 1 intish intish
Uint32Array 4 2 intish intish
Int32Array 4 2 intish intish
Float32Array 4 2 float? floatish, double?
Float64Array 8 3 double? float?, double?

ArrayBufferを与えてモジュールの作成と関数の呼び出しを行うと、次のようなコードとなります。

気をつけなければならいのは、TypedArrayの大きさです。212 以上、224バイト未満の大きさになるようにするか、224バイトの整数倍の大きさになるようにしてください。そうしなければ、リンクに失敗してします。

これが原因でリンクに失敗した場合は、コンソールに適切なサイズが表示されます。それを参考に大きさを際設定すればようでしょう。

const heap = new Int8Array(0x10000)
const caesar = Caesar(window, {}, heap);
heap[0] = 72; heap[1] = 65; heap[2] = 76; // HALと設定
caesar.encrypt(1); // HALが1文字ずつシフトされる

まとめ

以上のように、JavaScriptと比べてasm.jsは随分と書きづらく、できることも限られています。ArrayBufferを駆使すればベクトルの計算も可能ですが、オブジェクトと平坦なArrayBufferとの相互変換を自分で実装しなくてはならず、なかなか骨が折れる作業であることは否めません。

その代わり得られる効果は絶大です。JITによって処理が重たくなることもなく、高速な実行が可能となります。またコンパイルされた結果はキャッシュされるため、2回目以降は高速に起動できるようになります。

とはいえ、手で書くのは骨が折れます。

「人間のやることではない」

「高級言語で実装したい」

そう思う方も多いでしょう。そのために用意されているツールがEmscriptenです。次回はEmscriptenを利用したC言語やC++で実装されたコードのasm.jsへの変換について解説します。

]]> カメラを使ってみよう ーWebRTC入門2016 /mganeko/19728/ Fri, 24 Jun 2016 00:00:28 +0000 /?p=19728 連載： WebRTC入門2016 (1)

こんにちは！ がねこまさしです。2014年に連載した「WebRTCを使ってみよう！」シリーズですが、内容がすっかり古くなってしまいました。そこで2016年6月の最新情報に基づき、内容をアップデートして改めてお届けしたいと思います。

WebRTCとは？

WebRTCとは”Web Real-Time Communication”の略で、Webブラウザ上でビデオ/オーディオの通信や、データ通信を行うための規格です。HTML5で新しく策定されたもので、複数の技術の連携で成り立っています。 ちなみに策定には複数の団体が絡んでいています。

  • API → W3C
  • ビデオ/オーディオのコーデック → IETF

APIの策定作業はWebRTC 1.0に向けて大詰めに入っています。またより詳細な低レベルのAPIを定義しているORTCも登場し、将来の統合に向けた動きも始まっています。

コーデックの選定では、ブラウザがサポートしなければならないビデオコーデックに、既にデファクトスタンダードともいえるH.264が加わりました。また、Googleが開発しているオープンソースのビデオコーデック「VP9」をサポートするブラウザも増えています。

WebRTCで何ができるの？

WebRTCは厳密に言うとビデオ/オーディオ/データ通信を行うための仕組みですが、他にも関連が深い技術があります。この連載では3つをまとめてWebRTC（とその仲間たち）ということで扱います。

この3兄弟に、HTML5の様々な要素を組み合わせて活用することができます。

  • JavaScript（大前提）
  • videoタグ、audioタグ
  • CSS3
  • Canvas
  • WebGL
  • Web Audio API
  • WebSocket

新しいAPIでカメラを使ってみよう

カメラやマイクと言ったデバイスにアクセスするには、従来はnavigator.getUserMedia()というAPIを使いました。2016年6月現在では、これに代わる新しいAPIが登場しています。

  • navigator.mediaDevices.getUserMedia() になった
  • ベンダープレフィックスが取れた
  • コールバックではなくPromiseベースになった

またデスクトップブラウザの場合は次のブラウザで利用することができます。

  • Firefox 47 … 利用可能
  • Chrome 51 … 利用する場合にはフラグ設定が必要
    • chrome://flagsというURLを開く
    • 「試験運用版のウェブ プラットフォームの機能 #enable-experimental-web-platform-features」を有効に
    • Chromeを再起動
  • Edge 25 … Windows 10 のEdgeでも利用可能

サンプルコード

それではカメラから映像を取得してみましょう。サンプルコードはこちらです。 

<!doctype html>
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 <title>Camera with mediaDevice</title>
</head>
<body>
  <button onclick="startVideo()">Start</button>
  <br />
  <video id="local_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>
</body>
<script type="text/javascript">
  let localVideo = document.getElementById('local_video');
  let localStream;
  
  // start local video
  function startVideo() {
    navigator.mediaDevices.getUserMedia({video: true, audio: false})
    .then(function (stream) { // success
      localStream = stream;
      localVideo.src = window.URL.createObjectURL(localStream);
    }).catch(function (error) { // error
      console.error('mediaDevice.getUserMedia() error:', error);
      return;
    });
  }
</script>
</html>

このHTMLファイルに、（Webサーバ経由で）ブラウザからアクセスしてみてください。GitHub Pagesでも公開していますので、すぐに試すことができます。

  • GitHub Pages で試す camera_new.html（※Chromeの場合は、上記のフラグ設定が必要です）
  • GitHub でソースを見る camera_new.html

ブラウザで[Start]ボタンをクリックすると、カメラへのアクセスの許可を求めるダイアログが表示されますので、許可してください。
Firefoxの場合 getusermedia_ff

Chromeの場合 getusermedia_chrome

Edgeの場合
getusermedia_edge
ウィンドウの下の部分にこのように表示されます。他のブラウザと違うので、ちょっと気が付きにくいかもしれません。

すると、このようにカメラの映像が表示されるはずです。 camera_ff

HTMLファイルの置き場所

カメラやマイクにアクセスするには、サンプルのHTMLファイルをWebサーバーに配置する必要がありますが、実はブラウザによって条件が異なります。

  • Chromeの場合 … 原則 https://～/ のみ。例外として http://localhost/～ でも利用可能
  • Firefoxの場合 … https://～/ および http://～/ の両方で利用可能。さらに file://～ でも利用可能
  • Edgeの場合 … https://～/ および http://～/ の両方で利用可能。さらに file://～ でも利用可能

FirefoxやEdgeの場合は、ローカルのHTMLファイルを直接読み込んでも、利用可能です。

トラブルシューティング

カメラのアクセスの許可を求められた際に「常に拒否」すると、そのサイトからはカメラの映像を取得することができなくなります。その場合は明示的に再許可してあげる必要があります。

Firefoxの場合getusermedia_ff_ngで「許可」または「毎回確認する」を選択

Chromeの場合getusermedia_chrome_ng「常に許可する」を選択

Edgeの場合
※いまのところ「常に拒否」することはできないようなので、このケースは発生しません。

新旧 getUserMedia() をラップしてみると

新しいAPIである navigator.mediaDevices.getUserMedia()は、まだChromeではデフォルトの状態では使えません。これは、引数で渡すオプションの指定方法が、まだ新しい書き方に沿っていないことが原因です。 

let deviceID = getSelectedIDsomehow(); // デバイスIDを指定する

// Firefoxの場合
let constraints = {
  audio: false,
  video: { 
   deviceId: {exact: deviceID}
  }
};

// Chromeの場合
let constraintsForChrome = {
  audio: false,
  video: {
    optional: [{sourceId: deviceID}]
  }
};

そのため、Chromeではしばらく新しいAPIはデフォルトでは使えない状態が続くと思われます。そこで古いAPIをPromise型にラップする例を用意してみました。（オプション指定の違いは吸収できていません） 

// --- prefix -----
  navigator.getUserMedia  = navigator.getUserMedia    || navigator.webkitGetUserMedia ||
                            navigator.mozGetUserMedia || navigator.msGetUserMedia;

  // ---- 新旧APIをPromiseでラップする ----
  function getDeviceStream(option) {
    if ('getUserMedia' in navigator.mediaDevices) {
      console.log('navigator.mediaDevices.getUserMadia');
      return navigator.mediaDevices.getUserMedia(option);
    }
    else {
      console.log('wrap navigator.getUserMadia with Promise');
      return new Promise(function(resolve, reject){    
        navigator.getUserMedia(option,
          resolve,
          reject
        );
      });      
    }
  }

  // 利用例
  function startVideo() {
    getDeviceStream({video: true, audio: false})
    .then(function (stream) { // success
      localStream = stream;
      localVideo.src = window.URL.createObjectURL(localStream);
    }).catch(function (error) { // error
      console.error('getUserMedia error:', error);
      return;
    });
  }

これを使ってカメラ映像を取得する例もご用意しました。Chrome 51でもデフォルトのままで利用できます。

様々なWebRTC関連のブラウザの違いを吸収する adapter.js が 本家のGitHubで公開されています。より便利に使いたい場合は、そちらをご利用ください。

CSS3と組み合わせてみよう

WebRTCは他の要素と組み合わせて使うことができると書きました。実際にCSS3と組み合わせてみましょう。

<!-- 通常 -->
  <video id="local_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>

  <!-- 左右反転 -->
  <video id="flip_video" autoplay style="transform: scaleX(-1); width: 320px; height: 240px; border: 1px solid black;"></video>

  <!-- 角丸 -->
  <video id="round_video" autoplay style="border-radius: 80px 80px 80px 80px; width: 320px; height: 240px; border: 1px solid black;"></video>

  <!-- セピア -->
  <video id="filter_video" autoplay style="filter: sepia(100%); -webkit-filter: sepia(100%); width: 320px; height: 240px; border: 1px solid black;"></video>

ほかにも様々なバリエーションが考えられます。ぜひ自分でもいろいろ試してみてください。

また、CSS3アニメーションを使うこともできます。例えばこんな感じです。 

<!doctype html>
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 <title>Camera with mediaDevice</title>
 <style type="text/css">
   #rotate_video
   {
    animation-duration:4s;
    animation-iteration-count:infinite;
    animation-timing-function:linear;
    animation-name:rotate360;     
   }

   #shake_video
   {
    animation-duration:0.5s;
    animation-iteration-count:infinite;
    animation-timing-function:ease-in-out;
    animation-name:shake;     
   }
   
   @keyframes rotate360
   {
    0%{transform:rotate(0deg);}
    100%{transform:rotate(360deg);}
   }

   @keyframes shake
   {
    0%{transform:rotate(-20deg);}
    50%{transform:rotate(20deg);}
    100%{transform:rotate(-20deg);}
   }
  </style> 
</head>
<body>
  Camera with mediaDevice.getUserMedia()<br />
  <button onclick="startVideo()">Start</button>
  <br />
  <!-- 通常 -->
  <video id="local_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>
  <br />

  <!-- 回転アニメーション -->
  <video id="rotate_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>

  <!-- 振動アニメーション -->
  <video id="shake_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>
  
</body>
<script type="text/javascript">
  // --- prefix -----
  navigator.getUserMedia  = navigator.getUserMedia    || navigator.webkitGetUserMedia ||
                            navigator.mozGetUserMedia || navigator.msGetUserMedia;

  let localVideo = document.getElementById('local_video');
  let localStream;
  
  // start local video
  function startVideo() {
    getDeviceStream({video: true, audio: false})
    .then(function (stream) { // success
      localStream = stream;
      localVideo.src = window.URL.createObjectURL(localStream);
	  
      document.getElementById('rotate_video').src = localVideo.src;
      document.getElementById('shake_video').src = localVideo.src;
    }).catch(function (error) { // error
      console.error('mediaDevice.getUserMedia() error:', error);
      return;
    });
  }

  // ---- 新旧APIをPromiseでラップする ----
  function getDeviceStream(option) {
    if ('getUserMedia' in navigator.mediaDevices) {
      console.log('navigator.mediaDevices.getUserMadia');
      return navigator.mediaDevices.getUserMedia(option);
    }
    else {
      console.log('wrap navigator.getUserMadia with Promise');
      return new Promise(function(resolve, reject){    
        navigator.getUserMedia(option,
          resolve,
          reject
        );
      });      
    }
  }
</script>
</html>

camera_css_animation

CSS3と組み合わせたサンプルも、GitHub Pagesでも公開していますので、試してみてください。（ラップ関数を使っているので、デフォルトのChrome 51でも利用できます）

次回は

今回は新しいAPIを使って、カメラの映像を取得してみました。次回はWebRTCによる通信を手動で接続してみます。

]]> Angular2を書くためのAngularJSの書き方 /teyosh/18806/ Fri, 27 May 2016 06:00:05 +0000 /?p=18806 Angular2のリリースが刻一刻と近づいてきました。しかし世の中のプロダクトは、まだまだ大半がAngular1.xで開発されています。Angular2はコンポーネント指向が徹底されていたり、TypeScriptが推奨の開発言語であるなど、Angular1から大きく変わっており、一見すると移行は容易ではありません。

しかしAngular1.xの最新バージョンである1.5では、Angular1から2への移行をスムーズに行うために、Angular2を見据えたコーディングが行えるようになっています。この記事ではAngular2への移行をスムーズにするための、Angular1の書き方を紹介していきます。

【編集部注】
※この記事は、2016年3月21日に開催された「ng-japan 2016」のセッション「Angular2を書くためのAngularJSの書き方」についての、講演者自身によるレポートです。講演内容に加えて、講演者自身による解説や追記によって、よりわかりやすく詳細な記事に仕上げていただきました。
※本記事では、AngularJSをAngular1、 AngularJSの2系をAngularと表記しています。

セッションの講演資料と動画はこちらになります。

講演資料

講演動画（2:03:46付近から始まります）

Angular1の歴史と背景

Angular1は、今から4年前の2012年6月に、バージョン1.0.0がリリースされました。この4年間に、Windowsなら8->10、Macで10.8->10.11、Androidで4->6、iOSで6->9という変化がありました。バージョンアップが比較的遅いとされるOSでも、4年の間にこれほど大きなバージョンアップが行われているのです。

現在のIT業界では、4年とはこれほど長い期間です。また4年前のWebを振り返ってみますと、当時はBackbone.jsなどのMVCフレームワークが全盛期でした。Angularはリリースされてから大きな人気を博し、世界中の数多くのプロジェクトで採用されました。

しかし月日は流れ、2014年にReactが発表されてからは、Angular1の人気にも陰りが訪れます。コンポーネント指向を採用したReactの優れた設計が広く支持されたこと、Angular1はパフォーマンスがあまりよくないということもあり、Reactを採用するプロジェクトも増えてきました。

そこでパフォーマンスを大きく改善し、アーキテクチャが刷新されたAngular2が今年中にリリースが予定されています。しかしAngular2は変更点が多く、普及には時間がかかることが予想されます。そのため、Angular1.xは当分サポートされることが決定しています。

Angular1とAngular2の違い

Angular1とAngular2の違いは多岐にわたります。その中でも代表的な違いを以下に挙げます。

  • 主な開発言語がJavaScriptからTypeScriptへ
  • Two-wayデータバインディングを廃し、One-wayデータバインディングへ
  • 従来のスコープに代わり、コンポーネントがUIの状態を保持する（コンポーネント指向）
  • テンプレートの文法が変更
  • 従来のng-routerからコンポーネントルーターに
  • 従来の文字列ベースのDI (Dependency Injection)から、型によるDIに

対象ブラウザに関して

Angular1.5は、残念ながらIE8以前では動作しません。IE8以前を対象とする場合は、Angular1.2を利用する必要があります。もしIE8を対象にしなくてよいのであれば、Angular1.5へのアップデートが強く推奨されます。

JavaScriptからTypeScriptへ

Angular2では、メインの開発言語がTypeScriptに変更されました。

簡単に経緯を説明しますと、もともとAngular2を開発する際、JavaScriptのスーパーセットであるAtScriptという言語を同時に開発していました。

AtScriptの実体は、アノテーション付きのTypeScriptと言ってよいものでしたが、開発は難航。2015年3月にTypeScriptが（アノテーションに近い機能である）デコレーターの実装を表明すると、Angular2はTypeScriptへと移行したという流れがあります。

実際には、Angular2にとってTypeScriptは必須ではなく、JavaScriptやDartでも開発は可能です。しかしTypeScriptを利用すると多くのメリットがあるので、TypeScriptの使用が推奨されています。

ちなみに、TypeScriptというのは以下のような特徴を持った言語です。

TypeScriptの特徴

  • 型がある
  • インターフェースがある
  • モジュールインポートがある
  • 仕様がしっかりしている
  • JavaScriptのスーパーセットである
  • TypeScriptはそのままではブラウザでは利用できないのでコンパイル（JavaScriptへの変換）が必要

BrowserifyやWebpackを使おう

皆さん、GruntやGulpと言ったタスクランナーを既に使われている方は多いと思います。Angular1.5 / 2の開発では、TypeScriptのimport文を使用してモジュール間の依存性を記述していくため、こうした依存関係を解決して実行可能なプログラムを生成できるツールが必要です。

そうしたツールにはBrowserifyやWebpack、System.jsなどがあり、import文やCommonJSのrequire()関数などを解釈し、依存関係を解決した上で、ファイルを一つにまとめる機能を持ちます。

TypeScriptからのコンパイルなどもプラグインとして提供されており、今後のAngular開発には必須のツールとなっています。

Angular1.5のコードを眺める

Angular2とAngular1の違いや開発に必要な情報が一通り揃ったところで、実際にAngular1.5のコードを眺めてみましょう。 以下は、画面に「Hello」と表示するだけのプログラムです。

import * as angular from 'angular';

angular.module('app')
.component('app', {
  template: `<div>Hello {{ $ctrl.text }}</div>`,
  controller: class App {
    public text: string;
    constructor() {}
  },
  bindings: {
    text: '@'
  }
});

<!doctype html>
<html>
<body>
  <app text="ng-japan">
    Loading...
  </app>
  <script src="./bundle.js"></script>
  <script>
    angular.bootstrap(document, ['app']);
  </script>
<body>
</html>

Angular1のコードには違いないように見えますが、これまでとは何かが違いますね。

実際上のコードはTypeScriptで書かれており、importやclass、publicなどのアクセス指定子など、素のJavaScriptでは使えない文法が多く使われています。

DirectiveからComponentへ

Angular2から、コンポーネントという概念が登場します。それに合わせて、Angular1.5でもコンポーネントが利用できるようになりました。Angular1のディレクティブに比べて、簡単に作ることができます。

DirectiveとComponentでの設定値の違い

Directiveには先述したComponentと呼ばれるDOMの生成と他にAttributeに設定する処理ng-repeatやng-showなども同じ方法で作成しています。

そのため、Componentを作るには設定が過多気味であり、Angular2へ移行する場合に必要なものと不必要なものをより分けた作成メソッドを新たに追加されました。

以下の表が元々のDirectiveメソッドと追加されたComponentメソッドとの設定の違いとなります。

Directive Component
bindings No Yes (binds to controller)
bindToController Yes (default: false) No (use bindings instead)
compile function Yes No
controller Yes Yes (default function() {})
controllerAs Yes (default: false) Yes (default: $ctrl)
link functions Yes No
multiElement Yes No
priority Yes No
require Yes Yes
restrict Yes No (restricted to elements only)
scope Yes (default: false) No (scope is always isolate)
template Yes Yes, injectable
templateNamespace Yes No
templateUrl Yes Yes, injectable
terminal Yes No
transclude Yes (default: false) Yes (default: false)

引用：https://docs.angularjs.org/guide/component

Angular1のパフォーマンス問題

Angular1のパフォーマンスが良くない理由ですが、その原因を挙げてみましょう。

  • Two-wayデータバインディングが重い
  • 状態の監視に伴うオーバーヘッド
  • dirty check
  • $digest loop

では、どうしたらよいのでしょうか？以下の様なアーキテクチャが推奨されていますが、Fluxアーキテクチャによく似ています。

one-way

では、このアーキテクチャに従ったコードのサンプルを紹介します。

まずはアプリケーションのエントリーポイントとなるHTML（index.html）です。これは、angular.bootstrap()を呼び出しているだけで、特に変わったことはしていません。ただし、list-cmpというタグを使用していることは覚えておいてください。

<!doctype html>
<html>
<body>
  <list-cmp>
    Loading...
  </list-cmp>
  <script src="./bundle.js"></script>
  <script>
    angular.bootstrap(document, ['app']);
  </script>
</body>

以下がサービスのコードです。このサービスは、アプリケーションのデータを保持しており、データの操作を行うことが可能です。

import * as angular from 'angular';

angular.module('app')
.service('StoreService', class Store{
  private datas: Array<string> = [];
  constructor(){
    this.datas = ['angular', 'javascript', 'typescript', 'angular2'];
  }
  getList() {
    return this.datas;
  }
  addData(data:string) {
    this.datas.push(data);
  }
  changeData(index:number, data:string){
    this.datas[index] = data;
  }
  deleteData(index:number){
    this.datas.splice(index, 1);
  }
})

以下は、index.htmlで使用されていたlist-cmpタグ（コンポーネント）の実装です。内部で、さらにlang-cmpというタグ（コンポーネント）を使用しています。

また、Angular1で多用されていた$scopeはもう使われておらず、代わりにコンポーネントのコントローラーの参照である$ctrlが使用されています。基本的には、$scopeはもう使用してはならないものとして考えましょう。

import * as angular from 'angular';

angular.module('app')
.component('listCmp', {
  template: `<ul><li ng-repeat="data in $ctrl.datas">
    <lang-cmp index="$index" lang-data="data"
     lang-change="$ctrl.change(index, data)"
     lang-delete="$ctrl.delete($index)"></lang-cmp>
  </li></ul>`,
  controller: class List {
    private store;
    private datas: Array<string> = [];
    constructor(StoreService) {
      this.store = StoreService;
      this.datas = StoreService.getList();
    }
    change(index: number, data: string) {
      this.store.changeData(index, data);
    }
    delete(index: number){
      this.store.deleteData(index);
    }
  }
});

最後に、lang-cmpタグの実装です。上のコードで指定されていたlang-changeやlang-deleteと言った属性が、langChangeやlangDeleteといったプロパティに対応しています。

import * as angular from 'angular';

angular.module('app')
.component('langCmp', {
  template: `<input ng-model='$ctrl.langData'>
  <button ng-click="$ctrl.change()">変更</button>
  <button ng-click="$ctrl.delete()">削除</button>`,
  controller: class Data {
    private langData:string;
    private index:number;
    private langChange;
    private langDelete;
    constructor() {}
    change() {
      console.log(this.index, this.langData);
      console.log(this.langChange);
      this.langChange({index: this.index, data: this.langData});
    }
    delete() {
      this.langDelete({index: this.index});
    }
  },
  bindings: {
    'langData': '<',
    'index': '<',
    'langChange': '&',
    'langDelete': '&'
  }
})

コンポーネント指向のディレクトリ構造

コンポーネント指向になったことから、コンポーネント単位にまとめると見通しがよくなります。

├─about
│  └─components
│          about.component.e2e.ts
│          about.component.html
│          about.component.scss
│          about.component.spec.ts
│          about.component.ts
│
├─app
│  └─components
│          app.component.e2e.ts
│          app.component.html
│          app.component.spec.ts
│          app.component.ts
│          navbar.component.html
│          navbar.component.scss
│          navbar.component.ts
│          toolbar.component.html
│          toolbar.component.scss
│          toolbar.component.ts
│
├─assets
│  │  main.scss
│  │  _colors.scss
│  │  _variables.scss
│  │
│  └─svg
│          more.svg
│
├─home
│  └─components
│          home.component.e2e.ts
│          home.component.html
│          home.component.scss
│          home.component.spec.ts
│          home.component.ts
│
└─shared
    └─services
            name-list.service.spec.ts
            name-list.service.ts

テストについて

Angular2ではテストの基本セットがJasmineとなっていますので、Jasmineだと学習コストは少なくなります。

ルーティング

Angular1ではngRouteよりもui-routerがよく使われていると思いますが、Angular2では性能と管理が簡単なComponentRouterが登場します。 Angular1.5用のComponent Routerが用意されています。

まとめ

このセッションで学んだことを最後にまとめます。

  • Angular1のプロジェクトでもTypeScriptを使おう
  • タスクランナーを利用しましょう
  • Webpackやbrowserifyを利用しましょう
  • DirectiveからComponentに変更しよう
  • controllerの廃止
  • Scopeは原則利用しないように
  • Two-way data-bindingよりOne-way data-binding
  • コンポーネント単位でファイルを整理しよう
]]> Angular1から2への移行プロセス、詳しく語ります /frontainer/18780/ Thu, 28 Apr 2016 03:05:16 +0000 /?p=18780 Angular2のリリースが近づいてきている今、Angular1で開発された資産を、どうやってAngular2に移行していけばよいのでしょうか？

この記事では、実際に移行を行う上でのプロセスを具体的に示していきます。

編集部注: この記事は、2016年3月21日に開催された「ng-japan 2016」のセッション「Angular1.4で作られた自社マイクロサービスを2へマイグレーション」についての、講演者自身によるレポートです。講演内容に加えて、講演者自身による解説や追記によって、よりわかりやすく詳細な記事に仕上げていただきました。

セッションの講演資料と動画はこちらになります。

講演資料

講演動画（4:19:52付近から始まります）

Angular1から2へ移行する前に

Angular2への移行を始める前に、Angular1の構成やソースコードを整理する必要があります。公式サイトに「UPGRADING FROM 1.X」という1からアップグレードする手順の解説があります。その手順に加え、実際のアプリケーションの構成を考慮すると以下のような流れになります。

  • 事前準備
  • ng-upgrade
  • コンポーネント(ディレクティブ)の移植
  • サービスの移植
  • ページコンポーネントの移植
  • フィルターの移植
  • ルーターの移植
  • ng1ライブラリの置き換え
  • ng-upgradeの除去

※ セッションでは上記の「サービスの移植」までの前段のみを取り上げています。

事前準備

Angular2では1とは異なる点が多く、そのままではすぐにアップグレードすることはできません。そこでまずは1で近い構成にする事前準備が必要になります。

AngularJS Style Guideに従った構成になっていること

johnpapa/angular-styleguide Angular 1 Style Guide

上記スタイルガイドのRule of 1及びFolders-by-Feature Structure、Modularityの３点には最低限合わせておきましょう。

Angular2ではコンポーネントが中心になり、ファイルの構成もこのスタイルガイドと近い構成になっていきます。あらかじめコンポーネントごとにファイルを分けて置くことで、基本的な設計もコンポーネント指向に近づけておきます。

「その使い方はもう古いかも？AngularJS老化チェック」という記事の内容が現在のコードに当てはまらないかどうかをチェックしておきましょう。当てはまったものはスタイルガイドに沿ってリファクタリングを行いましょう。

モジュールローダー（モジュールバンドラー）（Browserify/Webpackなど）を使っていること

Angular2は必要なスクリプトを読み込んでいって作ることもできますが、モジュールローダー（モジュールバンドラー）前提で話が進んでいくことがあり、導入されていないと理解が難しい状況になります。何も導入していなければBrowserifyかWebpackをおすすめします。公式サイトではSystemJSを用いていますが、Browserify/Webpackを使う場合、必ずしもSystemJSを使う必要はありません。

TypeScriptへ移行

Angular2入門のページではBabelやTypeScriptなどの利用を、とありますが、マイグレーション時においてはTypeScriptへの移行を先にすることを強くお勧めします。

例えば先ほどの「UPGRADING FROM 1.X」のページですが、JavaScript用のドキュメントは準備中となっています（2016年4月現在）。

このような状況からみて、今後の新しい機能についてもTypeScript優先で情報提供されることがあることでしょう。また、既にAngular2に取り組んでいる先人たちのノウハウ（StackOverflowなど）もTypeScriptをベースにしているものが多いので、これを機にTypeScriptを使うと良いでしょう。型などを用いることで移行時の不具合を見つける手助けにもなります。

コンポーネントディレクティブの使用

Angular1.5からコンポーネント機能が提供されました。Angular2の基本はコンポーネントで構成されます。そのため、既存のアプリケーションをコンポーネント化していくことで移行がスムーズになります。対応ブラウザに問題がなければまずはAngular1.5にアップグレードし、ディレクティブや共通部分をコンポーネント化しましょう。

Angular Developer Guide / Component

ここまでを一通り行い、Angular2への移行の準備が整います。

この時点で難しいと思われる方もいるかもしれません。しかしながら、Angular2でも準備と同様の環境が求められます。Angular2はパフォーマンス改善やコンポーネント指向など魅力的な変更があるのでぜひとも移行していきたいところなのです。いずれにしても、今後も大きなフロントエンド開発においてはこのようなモダン構成が求められることでしょうから、そうした練習としてAngular2を採用するのも良いでしょう。

Angular2の導入

Angular2の方へ入っていきたいと思います。最低限必要なものとして以下のものが必要になります。（2016/4/24時点）

  • angular2@2.0.0-beta.15
  • systemjs@0.19.26
  • refrect-metadata@0.1.2
  • rxjs@5.0.0-beta.2
  • zone.js@0.6.10
  • es6-shim@0.35.0

npm installでまとめて導入できます。

npm install angular2@2.0.0-beta.15 systemjs@0.19.26 refrect-metadata@0.1.2 rxjs@5.0.0-beta.2 zone.js@0.6.10 es6-shim@0.35.0

まずAngularの起動方法を変更します。

<body ng-app="app">...</body>

これは以下のようにangular.bootstrap関数を用いて定義するようにします。この際HTMLにng-appは不要です。

angular.bootstrap(document.body,['app'],{strictDi:true});

さらにこの部分をng-upgradeと呼ばれているangular2/upgradeのUpgradeAdapterというものを用いてAngularを起動していきます。

import {UpgradeAdapter} from 'angular2/upgrade';
export const Adapter = new UpgradeAdapter();

import {Adapter} from './adapter.ts';
Adapter.bootstrap(document.body,['app'],{strictDi:true});

このようにupgradeの中にあるUpgradeAdapterを経由して実行をします。今後1と2を混在させた状態でアプリケーションを動かすためのハブのような役割をこのAdapterが行ってくれます。今後いろいろな場面でAdapterを呼び出して使うことになるので、あらかじめ別のファイルにしておいて外部から参照できるようにしておきましょう。

続いてangular2-polyfill.jsを読み込みます。後々Observableを使う時に必要になるので、忘れないように入れておきましょう。

import 'angular2/bundles/angular2-polyfills';

// for old browsers
import 'es6-shim/es6-shim.min.js';
import 'angular2/es6/dev/src/testing/shims_for_IE';

ここでユニットテストなどでPhantomJSなどで実行しているとエラーが出ます。es6-shimを入れることで回避することができます。

karma-es6-shim

TypeScriptにもes6の型定義ファイルが必要になるので、es6-shimの型定義ファイルを入れておきましょう。

typings install es6-shim --save --ambient

以上で移行の前段はできました。ここからはAngular1で作ったものを徐々に2へと置き換えて行く作業になります。

コンポーネントを置き換え

まずは他にあまり依存しない、Directiveのrestrict:’E’で実装されていたものをAngular2へ移行していきます。大きなところからやりたくなりますが、移行は末端から順番にやるようにしましょう。

以下はAngular1のコンポーネントを使って書かれたローディングの例です。

const template = require('./loading.html');
class LoadingCtrl {
    constructor(private LoadingService) {}
}
angular.module(‘app')
    .component('globalLoading',{
        controller: LoadingCtrl,
        transclude: true,
        template: template
    });
export default LoadingCtrl;

class LoadingService {
    count:number = 0;
    loading:boolean = false;
    constructor() {}
    start() {
        ++this.count;
        this.loading = true;
    }
    stop() {
        --this.count;
        if (this.count === 0) {
            this.loading = false;
        }
    }
}
angular.module(‘app')
    .service('LoadingService',LoadingService);

<div ng-show="LoadingService.loading" class="loading">
    <div class="loading-text" ng-transclude></div>
</div>

このローディングコンポーネントをAngular2に置き換えていきます。 まずはコンポーネント部分を置き換えていきましょう。

import {Adapter} from '../../core/adapter';
import {Component} from 'angular2/core';
import {LoadingService} from './LoadingService';
const template = require('./loading.html');

@Component({
    selector: 'global-loading',
    template: template
})
export class LoadingCtrl {
    constructor(private LoadingService:LoadingService) {}
}
angular.module('app').directive('globalLoading',<angular.IDirectiveFactory>Adapter.downgradeNg2Component(LoadingCtrl));

Angular2の基本はコンポーネントになっているので、出来る限りコンポーネントに置き換えておきましょう。

Angular2で書かれたコンポーネントは1環境では呼び出すことができません。そこでディレクティブにAdapter.downgradeNg2Component()を用いて登録することで、Angular1環境下においても使うことができるようになります。

続いて、サービス部分の移植です。

import {Adapter} from '../../core/adapter';
import {Injectable} from 'angular2/core';

@Injectable()
export class LoadingService {
    count:number = 0;
    loading:boolean = false;
    constructor() {}
    start() {
        ++this.count;
        this.loading = true;
    }
    stop() {
        --this.count;
        if (this.count === 0) {
            this.loading = false;
        }
    }
}
angular.module('app').factory('LoadingService',Adapter.downgradeNg2Provider(LoadingService));
Adapter.addProvider(LoadingService);

@Injectable()をつけてInject(DI)可能であることを示します。 コンポーネント同様に、Angular2記法のServiceをAngular1からもDIできるようにAdapter.downgradeNg2Provider()を使ってダウングレードして登録しておきます。

加えて、Adapter.addProvider()で作ったサービスをProviderに登録する必要があります。これはUpgradeAdapterを使っている場合で、Angular2のコンポーネントからDIさせるために必要になります。

これを行わないと以下のようなエラーとなります。

EXCEPTION: Error: [$injector:unpr] Unknown provider: LoadingServiceProvider <- LoadingService <- LoadingInterceptor <- $http <- $templateFactory <- $view <- $state

同様にHTMLもAngular2記法に置き換えを行います。

ディレクティブではng-transcludeを使っていましたが、Angular2ではng-contentになっているのは注意が必要です。

また、細かいところですが、angular.constantsもなくなっているので、constでオブジェクトを作っておき、それをimportして使うように置き換えましょう。

ServiceのAngular2移行

さて次に、ServiceをAngular2化していきます。 基本はLoadingのときと同じですが、通信周りには変更があります。

Ajax通信を行う際は$httpを使って通信を行っていました。Angular2ではHttpでAjax通信を行うことができます。$httpはPromiseを返していましたが、HttpはObservableを返すという違いがあります。

以下はAngular2記法に置き換えたいわゆるモデルです。作りは先程のローディングの場合と殆ど変わりませんが、HttpはObservableを返すので、処理の変更箇所を減らすためにPromiseで返すようにしています。

import {Adapter} from '../../core/adapter';
import {Injectable} from 'angular2/core';
import {CONSTANTS} from '../../core/constants';
import {Http, Response} from 'angular2/http';
@Injectable()
export class AccountModel {
    constructor(protected http:Http) {}
    get() {
        return this.http.get(`${CONSTANTS.API_PATH}account`).toPromise();
    }    
}
angular.module('app').factory('AccountModel', Adapter.downgradeNg2Provider(AccountModel));
Adapter.addProvider(AccountModel);

Httpの返すObservableについてはRxJSのドキュメントを参照してください。

Reactive-Extensions/RxJS

最後にあらかじめコンポーネントにしておいたページでフォームの部分を移植してみます。 まずテンプレートをAngular2記法に置き換えます。

テンプレートの記法は以下の参考リンクを上から順番に見ていくと良いでしょう。

formの移植

続いてformの制御部分を移植します。メールアドレスの入力フォームで、バリデーションが通らないと更新ボタンが押せない（disabled）になるというよくあるものです。

<form ng-submit="$ctrl.save()">
    <label class="layout-block">メールアドレス変更</label>
    <div class="form-item">
        <div class="form-input form-fill">
            <input ng-model="$ctrl.newEmail" type=“email" name="email" placeholder="新しいメールアドレス" required>
            <span class="form-error">
                <span ng-if="!form.email.$error.email">メールアドレスを正しく入力してください</span>
                <span ng-if="!form.email.$error.required">必ず入力してください</span>
            </span>
        </div>
    </div>
    <button ng-disabled="!emailform.$valid" class="btn btn-default btn-revert">メールアドレスを変更する</button>
</form>

formの制御のために[ngFormModel]="name"を使います。（これ以外にも複数方法があります）また、inputタグにはngControl="name"を使って名前を付けます。

下記のように書きかえます。

<form [ngFormModel]="form" (submit)="save();">
	<div class="form-input">
		<input [(ngModel)]="user['lastname-phonetic']" ngControl="lastphonetic" type="text" value="" placeholder="セイ">
		<span class="form-error" *ngIf="form.controls.lastphonetic.errors">
			<span class="form-error-message">
				<div [hidden]="!form.controls.lastphonetic.errors.required">セイは必須項目です</div>
				<div [hidden]="form.controls.lastphonetic.errors.required && form.controls.lastphonetic.errors.invalidPhonetic">全角カタカナで入力してください</div>
			</span>
		</span>
	</div>
	<button [disabled]="!form.valid" class="btn btn-default btn-revert">更新</button>
</form>

フォームのエラー状況によって振り分けしたい部分は[ngFormModel]でつけた名前.controls.inputにつけたngCotrol名.errors.エラー名でエラーが発生しているかどうかを確認することができるようになりますが、スクリプトも修正が必要です。

import {FORM_DIRECTIVES,Control,ControlGroup,Validators} from 'angular2/common';

@Component({
    selector: 'profile-form',
    templateUrl: 'webroot/components/profile/profile.html',
    directives: [FORM_DIRECTIVES]
})

this.form = new ControlGroup({
	lastphonetic: new Control('',Validators.compose([
		Validators.required,
		ValidateService.phonetic
	]))
});

コンポーネント内でform関連のディレクティブを使うときには@Componentのdirectivesに配列で使うディレクティブを指定します。

先ほどngModelFormにつけた名前と同じ名称にnew ControlGroup()します。 そしてngControlにつけた名前と同じ名称でnew Control()します。 第一引数がデフォルトの値、第二引数にバリデーション関数を指定します。 複数指定する場合はValidators.componse([])を１つの場合はValidators.requiredなどを指定します。

Validatorsにはあらかじめ定義されているバリデーターがあります。

static required(control: modelModule.Control): {
	[key: string]: boolean;
};
static minLength(minLength: number): Function;
static maxLength(maxLength: number): Function;
static pattern(pattern: string): Function;
static nullValidator(c: any): {
	[key: string]: boolean;
};

Angular1ではtype=”email”でメールアドレスのチェックが行われていましたが、Angular2では上記のチェック以外は行われない点は注意してください。

今回はメールアドレスなので、カスタムバリデータを作成します。

export const ValidateService = {
	email(control:Control) {
		if (!/^[a-z0-9!#$%&'*+\/=?^_`{|}~.-]+@[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)*$/i.test(control.value)) {
			return {email: true};
		}
	}
}

returnする名称はエラーが発生した時に form.controls.lastphonetic.errors.emailで取得することができる値です。

バリデーションの正規表現についてはAngular1で使用されていたものと同じです。

Angular directive/input.js

セッションでは時間の関係で移行手順の途中までしかお話できませんでした。 移行作業は作られたアプリケーションによって異なりますが、公式サイトの手順だけではハマりどころも発生することでしょう。

今後移行手順に関してはさらに整理され情報も出てくると思いますので、事前準備をしっかりと行い、ng-upgradeを用いて少しずつ移行を進めていきましょう。

]]> TypeScriptで今すぐ使える実践的『ECMAScript 2015』 /vvakame/18057/ Fri, 15 Jan 2016 00:00:34 +0000 /?p=18057 連載： TypeScriptでECMAScript 2015時代のJavaScriptを先取りしよう！ (3)

TypeScriptを使ってECMAScript 2015時代のコードを書く 3

第一回は、「なぜTypeScriptか？」という話を書きました。前回はTypeScriptで開発する際の環境についてがテーマでした。今回は、最後の締めくくりとしてECMAScript 2015において積極的に利用するべき構文を紹介していきます。

まず、TypeScriptの近況をお伝えしておきます。TypeScriptの現在のバージョンは1.7.5で、この後もまだまだアップデート予定は詰まっています。アップデートの予定はたくさんありますが、これは必ずしも機能が十分に揃っていないということを意味しません。

第一回で触れたとおり、TypeScriptはECMAScript 2015のsuperset+型のための構文が導入された言語です。TypeScriptの今後のアップデートはTypeScript自体の使い勝手や、型の柔軟性を改善するためのものが大部分。その証左として、1.5.3より後の1.6.2、1.7.5のアップデートではECMAScript 2015の構文の追加はGeneratorsくらいのものです。つまり、TypeScriptはすでにECMAScript 2015による記述を行うためには十分成熟している、といえます。

次に挙げる機能を使う場合、多くのブラウザで動作させるために何らかの後処理が必要になります。

  • Modules
    • ECMAScript 2015としてのmoduleの仕様は決まりましたが、ブラウザ上で動かせる状態にはありません。そのため、require.jsやbrowserify、SystemJSなどのツールが必要。
    • なお、Node.js上で動作させる場合はCommonJSスタイルのJavaScriptとして出力できるためTypeScriptコンパイラによる変換だけで利用可能。
  • Generators
    • --target es6でのみ利用可である（es5で動く形式に変換できない）ため、利用したい場合はbabelによる変換が必要。

また、仕組み上es5で動く形に変換ができない（つまり、全くの新機能である）ものもいくつかあります。ブラウザなどの進歩を待ちましょう。

本稿では、すべてのサンプルコードは現代的に、つまりECMAScript 2015的に書くことにします。古くからのJavaScriptユーザとしては見慣れないかもしれない、そして別の言語に慣れている人には、比較的読みやすい記法でしょう。

これから紹介するTypeScript独自の記法ではないものは正式にJavaScriptの仕様になったものであるため、今後数年以内に徐々にすべてのJavaScriptコードが本稿で紹介されるような記法へと移行されていく…といいなぁ。

また、本稿に出てくるサンプルコードはTypeScript playgroundですぐに試せるリンクをなるべく添えています。Playground上で、変数名などにマウスカーソルをホバーさせるとどういう型として解釈されているか確認できるのでいろいろ試してみてください。Playgroundはmodule周りのサポートがすっぽり抜け落ちているので、その辺りは割愛しています。前回の記事を参考に、自分で環境を整え、試してみてください。

TypeScript独自の構文

まずは、TypeScript独自の構文について述べておきます。独自の構文といっても、型に関する部分についてなのでプログラムの動作には影響しません。プログラムの堅牢さ、分かりやすさ、保守しやすさによい影響があります。

詳しく知りたい場合は、筆者の書いた別の解説やTypeScriptの更新差分解説を参照してください。

型注釈の基本

TypeScript最大の特徴として、型の存在とそれを利用した静的なチェックがあります。

JavaScriptにももちろん型は存在しています。string, number, Date, RegExpなどなど多岐に渡りますがJavaScriptでは変数と型を結びつけるということをしませんでした。

TypeScriptでは変数に型を明示的に指定（注釈を与える）ことにより、静的なチェックやIDEによる支援を受けることができます。

変数や引数について型の指定ができる箇所は多くありますが、基本的に次の箇所だけマークしておけば多くの局面に対応できます。

  • 初期化なしの変数宣言
  • 関数の仮引数
  • 関数の戻り値の型
  • 型パラメータ

TypeScriptでは、変数や仮引数などの後に: 型名という形式で記述します。number, boolean, string, void, anyなど、組み込みの型と、DateやRegExpなど、見知ったJavaScriptのオブジェクトも存在しています。

"use strict";

// 関数の仮引数と戻り値の型
function concat(a: string, b: string): string {
    return a + b;
}

// 変数の型
let obj1: RegExp;
// 初期化子がある場合、わざわざ型注釈を明記しなくとも自動的に推論される
let obj2 = /^Hi!$/;

let array1: Array;
// array1 と全く同じ意味合い
let array2: boolean[];

Playgroundで試す

簡単ですね。型パラメータの考え方は、JavaやC#を知っている人であれば、馴染みのある記法でしょう。TypeScriptは配列だけは特別扱いをしており、Arrayなどの記法の他に、boolean[]という記法をも許しています。これも、JavaやC#を知る人であれば、見たことがある記法かもしれません。TypeScriptでは、配列についてはboolean[]の記法を使うほうが一般的です。

Interfaces

インタフェースは、あるオブジェクトについての性質を記述し、それに名前をつけることができます。JavaやC#ではあるクラスに特定の実装を強制するものとして使いますが、TypeScriptではその範囲にとどまりません。

クラス化するほどでもない、サーバから受け取るデータについて名前をちょいちょいと与える場合などに使われる場合が多いです。

"use strict";

interface Sample {
    str: string;
    func: (n: string) => number;
    methodA(): void;
}

let obj: Sample;
obj.str;
obj.func("test");
obj.methodA();

Playgroundで試す

ECMAScript 2015

さて、それではECMAScript 2015の構文の説明に入っていきます。筆者が育てている4つの個人リポジトリのソースコードを見て、実際に使っているもののみを抜粋してきました。

つまり、ここで紹介している構文は使い勝手がよく、ECMAScript 2015以前よりも改善されている構文である！といえます。

use strict

まずは、 “use strict”; について紹介しておきます。これはECMAScript 5のときからあるディレクティブです。

"use strict";

// getterのみあり setterなし
let obj = {
    get str() {
        return "Hi!";
    }
};

// エラーにしてくれる！
// Uncaught TypeError: Cannot set property str of # which has only a getter
// "use strict"; がないと、単に無視されるので値がセットされない謎のバグになり苦しみのたうつ
obj.str = "setterは存在していない";

Playgroundで試す

多くの効能があるため、ここでは詳細には解説しません。ここで解説した理由は、ECMAScript 2015の仕様上、後述のクラスやモジュールの内部は暗黙的にstrict modeになるためです。TypeScriptで書いたコードをコンパイルするとクラスやモジュールの構文も変換されてしまい、暗黙的にstrict modeではなくなってしまいます。

そのため、後々ECMAScript 2015が無変換で動く時代になった時に困らぬよう、今のうちからすべてのファイルの先頭に"use strict";を書いておき、挙動を揃えておきます。これはトイレに行った後に手を洗うというレベルのエチケットなので、tslintなどを活用して忘れないように気をつけましょう。

let, const

let, constを紹介します。JavaScriptではvarというキーワードを使って変数定義をしていました。let, constではvarに対して次の違いがあります。

  • ブロックスコープである
  • 同じ変数名を複数回定義しようとするとエラーになる
  • 変数の巻き上げは行われるが宣言前にアクセスするとエラーになる

constの場合、さらに追加があります。

  • 宣言時に初期化必須
  • 値の置き換え不可

便利ですね。varの不思議な挙動について理解しておかねばならない時代も過去のものとなりそうです。多くの場合で単純にvarをletに置き換えできるし、そうしたほうがよいでしょう。varをletに置き換えて動かなくなるようなコードは、JavaScriptの不快な仕様を利用した悪いコードだと考え、リファクタリングするべきです。

"use strict";

let objA = "Aだよ！";
// ブロックスコープだ！ varはブロックスコープではない
{
    let objA = "Aだけど2番目だよ！";
    // Aだけど2番目だよ！ と表示される
    console.log(objA);
}
// Aだよ！ と表示される
console.log(objA);

// 2重に宣言してもエラーにならない
var objB: any;
var objB: any;

// 2重に宣言するとちゃんとエラーになる（TypeScript上でもプログラム実行時でも）
let objC: any;
let objC: any;

// 定数として宣言すると値の書き換えはエラーになる（TypeScript上でもプログラム実行時でも）
const objD = "Hi!";
objD = "Bye!";

// ちなみに値のさらに中身を書き換えるのは問題ない
const objE = {
    str: "Hi!"
};
objE.str = "Bye!";
// 対策（実行時エラーになる）
const objF = Object.freeze({
    str: "Hi!"
});
objF.str = "Bye!";

Playgroundで試す

なお、TypeScriptで--target es5などでコンパイルした時はletがvarに変換されるため、実行時エラーは発生しなくなってしまいます。実用上はコンパイル時にそれと分かればとりあえずは問題ないでしょう。

Classes

オブジェクト指向な言語であればだいたい存在するクラスです。JavaScriptではECMAScript 2015から導入されました。ECMAScript 5までは、prototypeという仕組みを使ってオブジェクト指向なコードを書いていました。

prototypeにも良いところがあり、悪いモノでもないのですが、広く知られているという分かりやすさ、関連する記述がひとところにまとまっているという利点を考えると、やはりclassが使えるというのはありがたいものです。

今後、prototypeの出番は大きく減るでしょう。とはいえ、classの裏側はprototypeであるため、今まで使えたハックも利用可能ではあります。

"use strict";

class Sample {
    name: string;

    constructor(name: string, public extention = "!") {
        this.name = name;
    }

    hi(): string {
        return `Hi, ${this.name}${this.extention}`;
    }
}

let obj = new Sample("TypeScript");
// Hi, TypeScript! と表示される
console.log(obj.hi());

Playgroundで試す

JavaやC#を見慣れているユーザであれば、大変親しみやすいコードになったと思います。ぜひ、PlaygroundでどういうES5なコードに変換されるかを確認してみてください。これを手書きで書くのは、チーム内の人数が多くなれば多くなるほど辛く感じるでしょう。

また、クラスが使えるようになりましたが、だからといってなんでもかんでもクラスにしなければならないわけではありません。今までどおり、関数や普通のオブジェクトを使うのが適していると思った場合はどんどん使って構いません。無理にクラスを使おうとするほうが、意図のわかりづらい、よくないコードになってしまうでしょう。

TypeScriptのみの独自仕様として、constructorでpublic extention = "!"のように、アクセス修飾子付きで仮引数を宣言すると、自動的に自分のプロパティとしてセットされます。ECMAScript 2015の仕様に準拠したコードを書きたい場合は、nameプロパティのように、フィールドの宣言をしてからthis.name = name;のように自分で代入しましょう。

気になる場合は、tscでのコンパイル時に--target es6を指定してコンパイルし、どのようなpure ECMAScript 2015コードが生成されるかをチェックしてみるとよいでしょう。

Modules

モジュールです。ECMAScript 2015では、ついにモジュールという概念が、JavaScriptの仕様として盛り込まれました。今までのJavaScriptにはモジュールの仕様が正式にはなく、AMDやCommonJSなど、それを埋めるための（ECMAScriptではない）仕様が複数考えだされ、実装されてきました。Node.jsではCommonJSのモジュールに仕様に近いものが採用されています。

ECMAScript 2015でのモジュールの仕様は、ざっくりいうと 1ファイル=1モジュール という仕様です。1ファイル毎に名前空間が分割されていて、どの識別子を外部に公開するかを選択していきます。

モジュールの仕様は、静的に（つまり実行することなく）ソースコード間の依存関係が解決できるようになっています。そのため、今までのJavaScriptのコードとはかけ離れた、全く新しい構文をもっています。

コード例を見ていきましょう。utilA.ts, utilB.ts, main.ts という3つのコードを利用します。3ファイルあるので、モジュールが3つあることになります。

"use strict";

export default function() {
    return "Hi! from utilA";
}

"use strict";

export function hi() {
    return "Hi! from utilB";
}

"use strict";
// es6 moduleを使うと自動的に use strict した事になる。
// しかし、TypeScriptでコンパイルするとそうではなくなってしまうので明示的に指定しておく。

import utilA from "./utilA";
import {hi} from "./utilB";
import * as utilB from "./utilB";

// Hi! from utilA と表示される
console.log(utilA());
// Hi! from utilB と表示される
console.log(hi());
// Hi! from utilB と表示される
console.log(utilB.hi());

残念ながら、Playgroundで試すことができないので、お手元に環境を作って試してみてください。

exportして、importするだけの仕様ではありますが、慣れるまでは正しい記法がわかりづらく戸惑いを覚えるでしょう。TypeScriptの利点として、動作しない書き方をした場合きっちりコンパイルエラーにしてくれるので試行錯誤する手間が省けます。

Arrow functions

Arrow functions（アロー関数）です。ECMAScript 5までのJavaScriptの関数は、thisの値が他言語ユーザの期待とだいぶかけ離れた動作をしていて辛かったです。アロー関数では期待する挙動と実際の挙動の齟齬がだいぶ軽減されています。

"use strict";

// 引数なしの場合 括弧は必要
let funcA = () => {
    console.log("Hi!");
};
// Hi! と表示される
funcA();

// 引数1個の場合、括弧をつけることもできる
let funcB = (name: string) => {
    console.log(`Hi! ${name}`);
};
// Hi! TypeScript と表示される
funcB("TypeScript");

// 引数が1個の場合、括弧を省略して仮引数名のみを書くことができる
// ただし、括弧を省略する場合仮引数の型を指定することはできない
// このため、ここではfuncC変数に型を指定している
let funcC: (name: string) => void = name => {
    console.log(`Hi! ${name}`);
};
// Hi! TypeScript と表示される
funcC("TypeScript");
// 既に型がついている場合そのまま省略できる
funcC = name => {
    console.log(`Hi! ${name}`);
};
// Hi! TypeScript と表示される
funcC("TypeScript");

let funcD = (name: string, ...rest: string[]) => {
    console.log(`Hi! ${name} and ${rest.join(", ")}`);
};
// Hi! TypeScript and ECMAScript 2015, ECMAScript 2016 と表示される
funcD("TypeScript", "ECMAScript 2015", "ECMAScript 2016");

Playgroundで試す

この使い方では、EMCAScript 5の関数と大差ありませんね。タイプする文字数が減って嬉しいですが、まあ、その程度です。名前付きアロー関数は作ることができませんので、素直に変数に代入しましょう。

次の例を見てみましょう。

"use strict";

class Sample {
    constructor(public name: string) {
    }

    toString(): string {
        return `${this.name}!`;
    }

    method() {
        // ここはmethodのトップレベルです

        let funcA = () => {
            // arguments にアクセスできない
            // thisの値はmethodのトップレベルと変わらない
            console.log(`Hi, ${this}`);
        };
        let funcB = function() {
            // arguments にアクセスできる
            // thisの値は undefined
            console.log(`Hi, ${this}`);
        };

        // Hi, TypeScript! と表示される
        funcA();
        // Hi, undefined と表示される
        funcB();
    }
}

let obj = new Sample("TypeScript");
obj.method();

Playgroundで試す

アロー関数の特徴が顕著に出ていますね。

理由が明確に説明できない限り、今後はfunctionと記述する関数ではなく、アロー関数を使うべきでしょう。具体的に、今までのfunctionを使うのは名前付き関数を作りたい場合や、thisの値を変更するタイプのAPIをもつライブラリを使う場合などです。

Default parameters, Rest parameters, Spread operators

Default parameters（デフォルト値付き引数）、rest parameters（可変長引数）、Spread operators（展開演算子）について取り上げます。これらもECMAScript 2015からの導入になりますが、特にお世話になるのはデフォルト値付き引数でしょう。

"use strict";

// デフォルト値付き引数
// 当てはまる引数が渡されない場合、指定された値がデフォルト値として利用される
function hi(name = "TypeScript") {
    return `Hi! ${name}`;
}
// Hi! TypeScript と表示される
console.log(hi());
// Hi! ECMAScript 2015 と表示される
console.log(hi("ECMAScript 2015"));

// 可変長引数
function bye(...names: string[]) {
    if (names.length === 0) {
        return `Bye, JavaScript`;
    }
    return `Bye, ${names.join(", ")}`;
}
// Bye, JavaScript と表示される
console.log(bye());
// Bye, JavaScript, ECMAScript 3 と表示される
console.log(bye("JavaScript", "ECMAScript 3"));

function goodOldDays() {
    return ["JavaScript", "ECMAScript 3", "ECMAScript 5"];
}

let array = goodOldDays();
// spread（展開）される
// Bye, JavaScript, ECMAScript 3, ECMAScript 5 と表示される
console.log(bye(...array));
// 同上
console.log(bye(array[0], array[1], array[2]));

Playgroundで試す

ECMAScript 5までは、p = p || "TypeScript";のような、JavaScriptユーザ以外にはわかりにくいイディオムを取る必要がありましたがだいぶわかりやすくなりましたね。

Template string

Template stringは文字列の生成が今までより簡単にできるようになりました。これにより、文字列を結合してメッセージなどを生成するのが格段に読みやすくなります。Gruntfile.jsやgulpfile.jsでできると、設定ファイルも大変見やすく保守も簡単になります。

"use strict";

let name = "TypeScript";
// Hi! TypeScript と表示される
console.log(`Hi! ${name}`);

name = "ECMAScript 2015"
// Hi! ECMAScript 2015 と表示される
console.log(`Hi! ${name}`);

// Hi! ECMAScript 2015 と表示される
console.log("Hi! " + name);

Playgroundで試す

まさにテンプレートですね。

Tagged template stringという機能もあるのですが、あまり有効な使いみちがないのと、活用した有名なライブラリなども登場してきていないので入門レベルでは気にする必要はないでしょう。

Promises

ECMAScript 2015から、非同期処理における標準のAPIが定義されました。それがPromiseです。Promiseは「約束する」の名の示すとおり、将来的に処理結果を返すことを約束し、その予約表を先に払い出すイメージです。Promiseの結果は成功か失敗の2状態で表されます。

"use strict";

let p1 = Promise.resolve(true);
p1.then(value => {
    // true と表示される
    console.log(value);
});

let p2 = Promise.reject("何かのエラー！");
p2.then(value => {
    // rejectの場合はここに到達しない
    console.log(value);
}, err => {
    // 何かのエラー！ と表示される
    console.log(err);
});

let p3 = Promise.reject("何かのエラー！");
p3.catch(err => {
    // 何かのエラー！ と表示される
    console.log(err);
});

let p4 = new Promise((resolve, reject) => {
    let xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
        if (xhr.readyState == 4) {
            if (xhr.status == 200) {
                resolve(xhr.responseText);
            } else {
                reject(xhr);
            }
        }
    }
    xhr.open("GET", "http://www.typescriptlang.org/");
    xhr.send();
});
p4
    .then(text => {
        // 通信が成功していたらHTMLがどばー！と表示される
        console.log(text);
    })
    .catch((xhr: XMLHttpRequest) => {
        // 通信に失敗していたらステータスコードが表示される
        console.log(xhr.status);
    });

Playgroundで試す

Playgroundは--target es5で動作しているため、Promiseの型定義が存在していません。コンパイルエラーが出ていてもRunすることはできますが、できれば手元で試してみるのがよいでしょう。

Promiseは今後さまざまな標準APIの一部として使われることになります。ブラウザ上で動くコードを書いている場合でも、ServiceWorkerやfetch APIなどを使うようになると、まず間違いなく触らなければいけなくなるため、今のうちに確実にマスターしておくことをお勧めします。azuさんのPromise本が大変わかりやすいので熟読すると得るものが大きいと思います。

まとめ

いかがでしょうか。わかりやすく使いやすい変更が多いので、今すぐにでも使い始められると思います。まずは、既存コードなしの100% TypeScriptなコードから書き始め、徐々に適用範囲を広げていってみてください。

CoffeeScriptやECMAScript 5なコードからは遅かれ早かれ移行しなければならないと思いますので、本記事を参考に徐々に実践を始めてみてください！それでは良いTypeScript & ECMAScript 2015ライフを！

]]> ポエム駆動開発がエッジすぎる！白石俊平がピクシブの開発環境について、聞いてみた！ /miyuki-baba/17613/ Wed, 02 Dec 2015 00:00:03 +0000 /?p=17613 次々と登場する開発ツールや言語のバージョンアップ。開発スピードがどんどん早くなるWeb業界ですが、実際に企業の開発現場ではどのように開発環境やツール・体制などを構築しているのか──。

HTML5 Experts.jp白石俊平編集長が、根ほり葉ほり聞いちゃうシリーズ・第一弾は、ピクシブを訪問！HTML5 Experts.jpのエキスパートでもある川田寛@_furoshikiさんと片倉@geta6さんにお話を聞いてきました。

クリエイターがやんちゃして遊べる基地ピクシブ

白石：まずはピクシブのサービスや、川田さんが今どんな業務を担当しているのか聞かせてください。

川田：ピクシブでは「創作活動をもっと楽しくする」という理念を持って、いろんなサービスを提供しています。イラスト・漫画・小説が投稿できる「pixiv」以外にも、ネットショップサービス「BOOTH」やグッズ制作サービス「pixivFACTORY」といったECサービス、お絵かきアプリ「pixiv Sketch」とか、いろいろな創作活動向けのサービスを提供しています。

▲ピクシブ株式会社　エンジニア　川田寛さん

私がメインとして担当しているのは　CtoCのECサービスです。同人イベントなどであつかわれる創作物の頒布を、どうやったらネットの力で便利に変えられるのかって、いつも考えてますね。主に「BOOTH」と「pixivFACTORY」を担当しています。

白石：グッズ化したり、販売できたりするサービスですよね。ピクシブならではの強みってあります？

川田：「創作活動をしている人」にフォーカスしているところでしょうね。そういう人たちに愛されるサービスにできていると思っているし、社内の空気としても、クリエーターに対する尊敬があって、彼らをどう幸せにできるのかを考えていたりして。

たとえばBOOTHだと、普通のECサービスじゃ採算があわないという理由で蔑ろにされてもおかしくないような作品を作っている人も、ちゃんと大切にできる。例えば、マニアックすぎて日の目を見ない人たちも気軽に参加できるし、投資できるような仕組みも作っています。普通なら500円くらいでしか売れない作品でも、その価値を認めた人は1000円とか1万円というように、購入者側の評価価格で購入できるような仕組みを作ったりとか。

朝思いついたことをすぐコードで書くスピード感

白石：川田さんは入社したばかりですけど、前職との違いをどう感じてますか？

川田：前は100年以上歴史があったりとか、受託をメインとしている企業だったので、ピクシブとは何もかもが真逆ですね。社員の年代も若いし、サービスもまだできて7年くらい。開発言語一つとっても、今まではJavaがメインだったのが、RubyやPHP、Scala、Goなど、前の会社だったら絶対に手を出さなかったような言語もガンガン使っています。

開発するものについても、大規模な受託案件で、1年以上先にリリースされるようなウォーターフォール型が多かったのですが、ピクシブは自社開発で、それこそ朝に思いついた良いアイデアはその日のうちにコードを書いて形にしてリリースしたりすることもあります。ユーザーに価値を提供していく上で、とにかくスピード感が命なので、そのために多くの権限を現場に委ねているというかんじがしています。

白石：全然違うんですね。コードを書くってことは、川田さんはプログラマ寄りの仕事なんですか？

川田：UIまわりが多く、フロントエンドエンジニアをやってます。サーバーサイドも書くときは書きます。うちの会社はフロントエンジニアが3人いますが、みんな特にフロントエンドだけをやっているという感じではありませんね。iOSとかAndroidを作るアプリエンジニアもいますが、あまり境目がなくて何でもやっているというかんじがします。前職はお客様対応みたいなのが絡むので、SEという言葉がぴったりハマるような仕事だったのですが、今は完全にエンジニアです。コードを書くことで、ユーザーへの価値を発揮しています。

白石：そうなると、仕様策定は誰がやるんでしょうか。

川田：大きな機能追加とかロードマップは、ディレクターがまとめたり経営層を巻き込んだりしていますが、そうでないものは現場で考えてスピーディーにやってしまいます。

　▲ピクシブ株式会社のオフィスには、いたるところに絵師さんのイラストが描かれている。

ポエムはesa、意見交換・情報共有はidobataで

川田：うちの会社にはポエム駆動開発というのがあるんです。コードがかけるだけじゃなくて、創作をする人に対して想いが強い人が入社してくる。エンジニアにも想いが強い人がいっぱいいるので、ポエムを通じて刺激されて作る。

白石：へえ。川田さんはどんなポエムを書いたんですか？

川田：新サービスとかユーザーの声とかいろんな話が絡んでてあまりまだ公表できない話も多いのですが。作品を扱っているサービスとしては、やはり、それを求めているユーザーとうまく繋いであげないことには、出展しているクリエーターやアーティストさんにとっても良くないわけで。そこをどう改善していけばいいのか、というお話をしていました。

社内ではesaというツールを使ってポエムを語るんです。このサービスはこうやったら成功するんじゃないかって書くと、みんなが反応を示していく。そうやってどんどんプロダクトを改善したり、新しく作り出したりしていますね。

白石：現場から上がってくるボトムアップなかんじがいいですね。

川田：何を作るのかとか、どう改善するかは現場から上げていけますね。経営層も「お前らでドラスティックに変えていってくれ」って言ってくれて。

白石：チーム体制は何人くらいでやってるんですか？

川田：うちのチームだと、BOOTHとpixivFactoryであわせて10名弱くらい。両方ともRailsなど同じ道具を使って作っているので、エンジニアはどちらもみている感じですね。

白石：アジャイルで開発しているんでしたっけ。

川田：うちのチームではアジャイルと呼べるほど、そこまできっちりしていません。どちらかといえばDevOpsが自然に機能しているという印象。大きな機能リリースに向けた開発はしているけれど、それだけをメインとしてやってはいられない。いま動いているものに問題があれば、そこで対応もしなくてはいけないので。サポートチームのフィードバックであったり、エゴサーチして問題を探って、idobataで即座に共有されたり。

白石：エゴサーチを開発チームがしているのはすごい。社内のコミュニケーションツールはSlackじゃないんですね。idobataって、Slackと比べてどうなんですか？使いやすいとか。

川田：Slackとidobataを使ってはいますが、うちのチームだとidobataの方がメインになりましたね。自分たちの使っている範囲で、機能面にそこまでの違いは感じてはいません。Slackはチームごとで導入してしまっているからか、会社全体として導入しているidobataのほうがオープンに議論が交わされてて。他のチームのスレをみて気軽に意見を言ったり、挙句にプルリクを作って後方支援することもあったり。プロダクトやチームを超えて議論がされていますね。

タスク管理はカンバン。具体的なタスクはGitHub

白石：タスク管理は何を使ってます？

川田：うちのチームだと、タスク管理はカンバン。ToDoリストとしてざっくりタスクをポストイットで並べてます。トラブルがあったらそっちを優先したり、技術的な問題で遅れることもあります。タスクも今まで見てきた中ではわりと独立性が高いとおもってて、エンジニアやデザイナー、ディレクターやサポート担当者など、全員にビルド/デプロイ権限があって、自分たちが主体になってデプロイにまでもっていく。とはいえ、リーダーが責任をとるとか、デプロイした人が責任をとるとかそういうものもなく、リスクはチーム全体でうまく運用方法を改善しながらカバーしていきます。

細かい機能とかコードレベルの話はGitHubです。プライベートのリポジトリ上に、Issue立てたり、PullRequest作ってMergeして、みたいなかんじです。よくあるGitHubの普通な運用方法になるとおもいます。

想いとか、こうやったほうがいいというポエムはesa、具体的なのはGitHubです。全体像はカンバンで、普段のコミュニケーションはidobataがメインです。

白石：ほかに開発体制で面白いトピックはありますか？

川田：開発体制とは違うかもしれないんですけど、前の会社ではコミュニケーション手段がほぼメールと電話だけだったんです。それがこの会社に来てからは、メールと電話は一切使ったことがない。一度もです。ツールをしっかり固めて、コミュニケーションコストを下げると、得られる情報量が大きくなって、結果としてチームを超えていろんな情報にアクセスできるんです。ツールひとつで、ここまで組織がフラットになれるものなんですね。

ただ一方で、まずいと思うところもあって。メールや電話といったツールは、一般的なビジネスでは必須のコミュニケーションツールですよね。オーバーヘッドはとてつもなく大きいのですが、使わなくなるとそれはそれで、マナーやルールがわからなくなって社会から取り残されていく不安も感じるんです。両方のバランスが重要と感じています。

白石：社員同士のやりとりは何を使ってるんですか？

川田：一部はSkypeですが、基本はidobataでオープンにしてます。idobataのタイムライン上には、社員同士のやりとりだけじゃなく、自動的にデプロイの情報が流れてきたり、サポートの状況とかが流れてきたりで、社員同士のやりとりが発生しやすいというかんじがしています。

インフラはコンシューマ向きの超安いサーバー？

白石：開発環境はどうですか？

川田：開発環境の話だと、うちにはちょっとした特殊なインフラがありまして。初期のpixivは社長が借金をして買ってきた大量のサーバーがあるのですが。コンシューマー向けの安いマザーボードを、ラックにくくりつけて使ってるんですよ。ほんとうにむき出しのままなんです(笑)。

さすがに今は本番環境をデータセンターに預けるようにしていますが、開発環境には未だにそのマザーボードむき出しのサーバーをインフラとして使ってるんです。インフラチームの図画工作スキルは、いまだに高いようですね(笑)。

インフラの話をもう少し突っ込んですると、pixivの場合はサービスの特性上、クラウドよりオンプレのほうが向いていてそっちが中心ですね。とはいえ、ところどころにクラウドは使われていて、新しいプロジェクトだとAWSみたいなクラウドも使われています。

データベースは、基本的にはMySQL使ってます。OSはLinux。新しいプロジェクトはRails使うことが多いんですが、「Rails最強!! Railsじゃないとダメだ！」みたいな人はいなくて、ツールとして使っているという印象です。

サービスはリリースした時の最新技術で

白石：HTML5 Experts.jpはフロントエンド開発者が主な読者なので、フロントエンド開発の話も聞かせてもらえますか？

川田：私が関わるBOOTHだと、マークアップはSlim、CSSはSASSやCoffeeScriptとか。Ruby書いている人にやりやすい環境で整っています。また、開発したのが2013年なので、CoffeeScript、Backbone.js、Marionette.jsなどを使ってます。いまだとReactあたりがもっと上手く問題を解決してくれたりするんでしょうし、SPA（Single page application）ももっといいやり方があるのでしょうが、当時の技術を使っているので…。

とはいえ、2007年に作られたpixivでも、CoffeeScriptが使われていたりはします。部分的に入れ替えも進んでいます。今年の6月にリリースしたお絵かきアプリ「pixiv Sketch」は、React.jsやBabelが使われています。もろ時代の影響を受けていますね。

白石：それだけフロントエンドの流れが早いってことですね。

フロントエンドだと、そこそこエッジな事例がきけそうな、pixiv Sketchのエンジニアを呼んでみますね。

ReactとFluxでサーバーサイドレンダリング

──ということで、geta6さんにご登場いただきました。

geta6：片倉@geta6です。「pixiv Sketch」の担当エンジニアをしています。

白石：ぜひ、フレームワーク周りで面白い話を聞かせてください。

geta6：ブラウザ版のpixiv Sketchは、Node.js上で動かしています。

　　▲ピクシブ株式会社　エンジニア　片倉弘貴さん

白石：Node.jsってことは、サーバーサイドから全然違うかんじなんでしょうか。

geta6：サーバーサイドは、RailsによるAPIサーバーと、Node.jsによるレンダリングサーバーで構成されていて。前者はgrapeを使用していてviewを持たずJSONしか吐かない仕様になっていて、後者はサーバーサイドでAPIを叩いてDOMを構築するReactサーバーになっています。

白石：なるほど。最近、Universal JavaScriptととも言われているIsomorphic Javascriptですね。それでサーバーサイドレンダリングしてるって、まさに最新ですね。

geta6：フレームワークは、Yahooさんが作ったfluxibleというのを使っています。サーバーとクライアントが同じコードで動くので、キツイ面もありますけど。

白石：fluxibleって、結構ヘビーだって聞きますね。

geta6：fluxibleは一人でさくっと開発する場合とか、SPA（シングルページアプリケーション）とかには向いてないかもしれません。ただ、pixiv Sketchみたいに複数人数で開発する場合は、ある程度がっつりしたコードを書けるし、メンテナビリティがあるので魅力的です。

良いところは、二重実装をしなくていいことですね。テンプレートをslim側で書いて、Backbone.jsからもってきて、Javascriptテンプレート内にテキストテンプレートをもう一個書いて…とか面倒なことはしなくていい。同じコードベースでAPIのリクエストとかすべてのことができるので、そこが便利です。

白石：サーバーとクライアントが同じコードで動くのがキツイと言ってましたが、具体的にはどんなところが大変なんですか？

geta6：Reactは、クライアント側の世界とサーバー側の世界で、呼ばれるメソッドが違うところがあるんです。componentDidMountっていうメソッドなんですが、それはクライアント側にしか呼ばれないので、その中ではCanvasの操作やDOMの操作が書けるんです。それがわかっていればそんなにつらくないけど、React始めたばかりだと、その辺がわからないのでつらいのかもしれないです。

白石：getaさんの勉強量は相当すごそうですね。

geta6：いつもはそんなに勉強はしてないんですけど、pixiv Sketch始めるときに、Reactが流行ってるって聞いて、どうしてもやりたいって言ったら採用されたんです。React全然知らなかったのに、採用されたので一から徹底的に勉強しました(笑)。

課題はパフォーマンス改善。野望はES6への乗り換え

白石：お二人が、今課題だと思ってることってありますか。

川田：まだ入社したばかりなので、あまり深く掴めていませんが。自分の関わっているサービスのパフォーマンスが悪いことが気になっていますね。RailsとかJavaScriptとか、いろんなところに悪さするのが潜んでいますね。

もう一つは闇のコードたち。締め切り間際で、アドホックに作りこんじゃったコードとかがたくさんありまして。たとえば、BOOTHは「APOLLO(アポロ)」という同人音楽をネット上で頒布する即売会イベントを開いていて、そういうイベント対応のために作りこまれて、めったに呼ばれないメンテされにくい闇のコードが眠っているんです。ある日とつぜん爆発しそうなので、なんとか阻止したいです。すでに若干、爆発しかけていますが…

こういう、サービス固有の問題みたいなのは山程ありますが、それ以外はとくに不安を感じてはいません。テストコードも書かれているし、最新のバージョンに上げていきましょうというモチベーションもある。機能追加や改善ばかりな企画屋さんがいるチームは世の中にいっぱいいるけど、うちはコードヘルスがサービスのライフサイクルやセキュリティにどんな影響を与えるのか理解されているし、バージョンアップしておかないと大変という感覚とか、エンジニアならわかる勘所を大事にしてくれています。上手くやれている感じがしています。

白石：今後チャレンジしたいことはどうでしょう。

川田：やっぱり、早くES6にしたいです。CoffeeScriptやめたい(笑)。

白石：でも、CoffeeScriptのほうが言語的な機能は上じゃないですか？

geta6：CoffeeScriptって1週間前に書いた自分のコードが読めなくなるんですよ。言語機能が強すぎて。特殊な記法が必要だし。ES6では普通に読めるから、メンテナンス性は高いですよね。

川田：CoffeeScriptって、少し大きくなってくると、ビルドした結果を想像しながら書かなきゃいけなくなることがある。Devツールで、ちょっとこの値どうなってるんだろうとかコンソールを叩き始めると、今までCoffeeScriptのコードを読んでたはずなのに、完全にJavaScriptに戻ってたり。

geta6：CoffeeScript書いてるより、JavaScript書いてるかんじが強いんですよね。インデントが効かないのも厳しい(笑)。

川田：そうなんです。以前、私はTypeScriptを使っていたんですが、あれはビルドした結果がストレートに想像できるのがいい。あと、将来を見据えるとやっぱりES6を推しちゃいますね。

Nodeのデプロイツールに定番がほしい

白石：getaさんはどうですか？

geta6：開発環境の課題は、Node.jsのデプロイツールとプロセスマネージャーに定番がないことですね。デプロイは、信頼性をとってcapistranoを使ってるんですよ。Nodeのデプロイツールはどれも機能が貧弱で手数も多いので、定番でいいのが出てこないかなって思ってます。

白石：プロセスマネージャーは何を使ってるんですか？

geta6：プロセスマネージャーはPM2を使ってます。capistranoからシンボリックリンク設置して、currentで新しいファイルをディレクトリに送るんですが、Nodeのファイルシステムが変わってから、シンボリックリンクを追跡して、デプロイ前のファイルのところで監視しちゃうようになったんです。そこでプロセスマネージャーが生きちゃってるので、デプロイしてもファイルが新しくならないんです。そこで一回殺すというのをやってるので、ダウンタイムが若干できてしまうっていう問題点があります。

白石：そういった課題の改善に取り組んでいるんですね。次にチャレンジしたいことはありますか？

geta6：API側はバックエンドのプロセスマネージャーがUnicornなんですけど、ラインがN個しかなくて、同時に来ちゃったらつまっちゃうんです。Node側でいいかんじでリクエストをバッファリングしてうまく送れないかと。受付サーバーをNodeにしてゆっくり流すというようなことをしたいです。

白石：なかなかエッジなプロジェクトになりそうですね。

geta6：requestIdleCallBackだっけ？あれも何かやってみたい。

川田：ピクシブで「東京 Web Performance」という濃い勉強会をやったんですけど、エッジすぎて人が集まらないかなと思ったら、エッジな人が結構集まってきて(笑)。第一回は「requestIdleCallback」を味見したんですが、広告やアナリティクスに割といいかんじで使えそうだったんで、全力で攻めるんじゃないかって話をしてました。ピクシブに思いのほか、いい影響を及ぼしそうな予感がしてます。

白石：じゃあ、そこも次のチャレンジになりそうですね。今日は面白いお話を聞かせていただき、ありがとうございました。

]]>