今回の記事は後編です。前編はこちら

ディープラーニングや機械学習というとちょっと手が出しづらいところがあり避けていた方もいると思いますが、この基調講演ではそういった迷い(?)を払拭するような解説とデモが行なわれました。

そしてもう一つ、オーグメント・リアリティやバーチャル・リアリティ、ホログラム、良い意味でも悪い意味でも「遊び」での利用しかないと思う人が殆どだと思います（私は今日までそのくらいのものだと思ってました）。いやいやどうして、数年後のビジネススタイルを定義する内容の解説とデモが行なわれました。

基調講演後半はエキスパートの佐川がお届けします。

ディープラーニングが行える「SQL Server」

患者のCTスキャンからガンである可能性をディープラーニングを使って解析している。この解析は SQL Server で実行されている。

SQL Server では ディープラーニング・ツール(TensorFlowやCNTK)を SQL として使えるようにしてる。これはストアド・プロシージャで実装され、このストアド・プロシージャの中でAIのエンジンを呼んでる。

新しいクラウドデータベース「Cosmos DB」とは何者か！？

データを分散保存し、分散された各リージョンのデータが一貫性を保って利用できるように設計されている。

Cosmos DB の特徴のひとつは何と言っても世界中に分散させてアクセスできることのようだ。そして分散されたデータについてはRDBMSと同等の一貫性を定義でき5段階から選択できるようになっている

コードを書く上でも Python や R 、 C# と言った言語でも書くことができもちろん Node.js を使っても書くことができる。

AIを活用したドローンとデープラーニングを用いた「Cosmos DB」の実例。

Mixed Reality(複合現実)で実現するビジネス

Augmented Reality(オーグメント・リアリティ)、Virtual Reality(バーチャル・リアリティ)、Hologram(ホログラム)を合わせたものが Mixed Reality(複合現実) であり、今回の de:code2017 のメインと私は思っている。

Mixed Reality のキーマン Alex Kipman がもっと感銘を受けたのが日本だという。彼によると、日本は最も Mixed Reality(複合現実) が進んでいて、コミュニティ活動や HoloLens ハッカソンが世界でも秀でているそうです。

オーグメントリアリティ、バーチャル・リアリティ、ホログラムは別々に用いる技術ではなく同時に使うものであると主張する。

実際に建設業ではホロレンズを使って模型(設計図)を作り、最後にはこれらすべての情報をホロレンズに入れて渡すことができる。

これまでとは変わったスタイルの仕事になると言ってます。ワクワク感が満載で、アニメ好きでは無くてもテンションが上がりそうだ。

コミュニケーションツールとして、

Bot とのコミュニケーションも、

遠距離にいる人ともアバターとして存在することもできるし、

Mixed Reality(複合現実)を使うとすべてのものが変わる。２年から３年先には、バーチャルもリアルも境目がなくなりは物理的にそこに居なくてもいい。ブラウザ(Microsoft Edge)でWebVRを動かしEgdeから椅子を（バーチャルに）引き出すと言ったことも可能になる。

今回の記事は後編です。前編はこちら

Web技術でアプリ開発2016特集・第4弾は、JavaScript（およびTypeScript）によるクロスプラットフォーム開発が可能ながらネイティブと同様の実行速度を得られる、Telerik社のNativeScriptを取り上げたいと思います。

NativeScriptは、Angular2とも組み合わせて使うことができる、現在注目のフレームワークです。本記事では、XMLによるUI定義を行う従来の開発手法だけではなく、Angular2（ただし、RC4という少し古いバージョン）と組み合わせてモバイルアプリを開発する方法まで網羅してご紹介します。

NativeScriptの概要

NativeScript 2.0は、JavaScriptとCSSを使用し、ネイティブのiOSとAndroidのアプリを構築するためのフレームワークです。ネイティブで実行されるパフォーマンスとUXを提供し、その結果、ネイティブプラットフォームのレンダリングエンジンを使ってUIを構築します。WebViewsでのUIレンダリングはしていません。

NativeScriptにはtns-core-modulesというコアモジュールがあり、上記に述べたJavaScriptからネイティブへの変換を行っています。NativeScriptのgithubリポジトリを見ると「0.9.0」のリリースが「5 Mar 2015」なので、約1年とちょっとの歳月が経過していることになります。現時点での最新バージョンは「2.2.1」です。

NativeScriptでAngular2を利用する場合には、まず、Angular2のテンプレート（@Component.template）に、NativeScriptで提供しているディレクティブを記述します。そして、上記で説明したtns-core-modulesとnativescript-angularを利用してNativeScriptがビルドを行い、iOSやAndroidのネイティブコードを生成します。

「NativeScript with Angular2」の最初の「v0.3.0」がリリースされたのが今年8月初旬で、最新は「v0.3.1」です。

この記事では、macOS上での開発を前提に解説をしています。

インストール

インストール手順はquick-setupにも書かれている通り、あまり複雑なところはありません。しかし、もしAndroid SDKをはじめて利用する場合には少し戸惑うと思います（私もNativeScriptのあまりやさしいとはいえないエラーメッセージにちょっと苦しみました）ので、順を追って説明します。

• ステップ1: Rubyのインストール
• ステップ2: Node.jsのインストール
• ステップ3: NativeScript CLIのインストール
• ステップ4: iOSとAndroid開発に必要なもののインストール

ステップ1: Rubyのインストール

NativeScriptをビルドするとき、Rubyを利用します。Rubyのバージョンは2.2以降が必要ですが、macOSにデフォルトでインストールされているRubyは古いため、Homebrewを使って最新バージョンをインストールします。最新のRubyが入っている方は読み飛ばして下さい。

Homebrewのインストール

HomebrewはRubyを使いインストールし、インストール後環境変数を定義します。

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ brew update
$ echo 'export PATH=/usr/local/bin:$PATH' >> .bash_profile
$ source .bash_profile

rbenvとruby-buildのインストール

brewを使ってrbenvとruby-buildをインストールします。rbenvを使ってRubyのバージョン管理を行います。ruby-buildはrbenvのプラグインで、異なるバージョンのRubyをコンパイルし、インストールするためのものです。

$ brew install rbenv ruby-build
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ source ~/.bash_profile
$ rbenv --version
$ rbenv install -l
$ rbenv install 2.2.3
$ rbrnv version
$ rbenv global 2.2.3
$ ruby -v
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin15]
$

ステップ2: Node.jsのインストール

Node.jsはv4.0.0以降を利用する必要があります。rbenvと同様にバージョン管理システムをインストールします。Node.jsのバージョン管理システムにはnodebrew, nodist, nvm, nvm-windowsなどいくつかありますが、筆者はnodebrewを好んで利用しています。

nodebrew のインストール

curlを使ってインストールを行います。インストールが完了するとパスを追加するようにメッセージが表示されますので、.bash_profile に登録してください。

$ curl -L git.io/nodebrew | perl - setup
$ echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> .bash_profile
$ source .bash_profile

Node.jsのインストール

続いて、Node.jsをインストールします。nodebrew ls-remoteコマンドを使ってバージョンを確認し、nodebrew install-binaryコマンドを使ってNode.jsのインストールを行います。利用するバージョンを動かす場合にはnodebrew useコマンドを実行します。

今回、Node.jsのバージョンとしてはv5.12.0を利用しました。

$ nodebrew ls-remote
$ nodebrew install-binary v5.12.0
$ nodebrew use v5.12.0
$ node -v
v5.12.0
$

ステップ3: NativeScript CLIのインストール

いよいよNativeScriptのインストールです。npmコマンドを使ってnativescriptをグローバルインストールします。nativescriptはスカッフォールディング（コード雛形の自動生成）を提供するモジュールで、tnsコマンドによって実行されます。

tnsコマンドを実行して、インストールが正しく行われているか確認しましょう。参考までにtnsコマンドで出力される内容はtns --helpと同じ内容です。tnsコマンドでは主に

• テンプレートからプロジェクトの生成
• プロジェクトへの生成プラットフォーム(iOS, Android)の追加
• JavaScriptからネイティブへのビルド
• エミュレータの実行

を行います

$ npm install nativescript -g
$ tns
# NativeScript
┌─────────┬─────────────────────────────────────────────────────────────────────┐
│ Usage   │ Synopsis                                                            │
│ General │ $ tns  [Command Parameters] [--command ]                            │
│ Alias   │ $ nativescript  [Command Parameters] [--command ]                   │
└─────────┴─────────────────────────────────────────────────────────────────────┘

・・・

$

ステップ4: iOSとAndroid開発に必要なもののインストール

JDKのインストール

JDKはバージョンが8以降のものをインストールしてください。インストールが完了したら、.bash_profileに設定を登録してください。

$ echo 'export JAVA_HOME=$(/usr/libexec/java_home)' >> .bash_profile
$ source .bash_profile

Android開発環境のインストール

Android SDKをHomebrewからインストールし、変数ANDROID_HOMEを定義します.

$ brew install android-sdk
$ echo 'export ANDROID_HOME=/usr/local/Cellar/android-sdk/24.4' >> .bash_profile
$ echo 'export PATH=$PATH:$ANDROID_HOME/platform-tools:$ANDROID_HOME/tools' >> .bash_profile
$ source .bash_profile

Androidエミュレータのインストール

android-sdkのインストールが終わったら、実際に利用するエミュレータを定義します。android-sdkがインストールされているディレクトリへ移動し、andorid avdを実行することで設定を行います。android-sdk以下のディレクトリ構成は次の通りです。

$ cd /usr/local/Cellar/android-sdk/24.4
$ tree -L 1
.
├── INSTALL_RECEIPT.json
├── README
├── add-ons -> ../../../var/lib/android-sdk/add-ons
├── bin
├── build-tools
├── etc
├── extras -> ../../../var/lib/android-sdk/extras
├── platform-tools
├── platforms -> ../../../var/lib/android-sdk/platforms
├── samples -> ../../../var/lib/android-sdk/samples
├── sources -> ../../../var/lib/android-sdk/sources
├── system-images -> ../../../var/lib/android-sdk/system-images
├── temp -> ../../../var/lib/android-sdk/temp
└── tools

Androidエミュレータを高速化するためのハードウェア支援環境「Intel Hardware Accelerated Execution Manager (Intel® HAXM) 」を事前にインストールします。次のスクリプトを実行してください。

$ cd /usr/local/Cellar/android-sdk/24.4/extras/intel/Hardware_Accelerated_Execution_Manager
$ sudo ./silent_install.sh

完了したら、android avdを起動し、事前にエミュレータ定義を登録します。

$ cd /usr/local/Cellar/android-sdk/24.4/tools
$ ./android avd

この設定を忘れると「Cannot read property ‘targetNum’ of undefined」というエラーが出ます。

参考までに、今回利用しているエミュレータは次のように定義しています。

よくあるトラブルとしては、Dockerを起動しているようなら終了させておくのが無難です。Dockerが利用しているポートとエミュレータが利用するポートがぶつかり、実行できないことがあります。

iOS開発環境のインストール

macOSを利用されていれば、iOSのエミュレータを利用するのは容易だと思います。

Command Line Tools for Xcode

$ sudo gem install xcodeproj
$ sudo gem install cocoapods
$ brew install xcproj

だいぶ長くなりましたが、これで開発環境の設定は完了です。尚、tnsコマンドにはtns doctorというコマンドがあります。環境設定などうまくできているかのチェックができますので、一通り終わった後に実行し、漏れがないかを確認します。

$ tns doctor
Verifying CocoaPods. This may take more than a minute, please be patient.
  ◡ Installing iOS runtime.tns-ios@2.2.1 ../../../../../../var/folders/ts/n268b_qx2j7g3ykzkqlj3jt00000gn/T/nativescript-check-cocoapods11686-1391-akcqo6/node_modules/tns-ios
  ◝ Verifying CocoaPods. This may take some time, please be patient..
Your components are up-to-date.

No issues were detected.
$

NativeScriptで作るHello World

ここではNativeScriptを使ってHello World的なアプリケーションを作成します。手順は

1. プロジェクトの作成
2. プラットフォームのインストール
3. エミュレータの実行

です。NativeScriptでのアプリケーション作成にはtnsコマンドを使います。

今、プロジェクトをMyFirstNativeScriptAppとしますので、iOSとAndroidアプリケションの両方を作成する場合にはiOSとAndroidのプラットフォーム用ライブラリをインストールしエミュレートを起動します。

$ cd ~
$ tns create MyFirstNativeScriptApp
$ cd MyFirstNativeScriptApp
$ tns platform add android
$ tns platform add ios
$ tns run android --emulator
$ tns run ios --emulator

Androidエミュレータでの実行結果

iOSエミュレータでの実行結果

tns create MyFirstNativeScriptAppで作成されたファイルを確認します。

$ tree -L 2
.
├── app
│   ├── App_Resources
│   ├── app.css
│   ├── app.js
│   ├── main-page.js
│   ├── main-page.xml
│   ├── main-view-model.js
│   ├── package.json
│   └── references.d.ts
├── node_modules
│   ├── babel-traverse
│   ├── babel-types
│   ├── babylon
│   ├── lazy
│   ├── tns-core-modules
│   └── tns-core-modules-widgets
├── package.json
└── platforms
    ├── android
    └── ios

このアプリケーションで特に重要なファイルがありますので、簡単に説明します。

• app.js
• main-page.xml
• main-page.js
• main-view-model.js

app.jsはアプリケーションが一番最初にロードするエントリーポイントで、このファイルからアプリケーションmain-page.jsの呼び出しを行っています。

// app.js
var application = require("application");
application.start({ moduleName: "main-page" });

// main-page.js
var createViewModel = require("./main-view-model").createViewModel;

function onNavigatingTo(args) {
  var page = args.object;
  page.bindingContext = createViewModel();
}
exports.onNavigatingTo = onNavigatingTo;

main-page.xmlは画面をXMLで定義し、関連する処理をmain-view-model.jsに定義してます。

<!-- main-page.xml -->
<Page xmlns="http://schemas.nativescript.org/tns.xsd" navigatingTo="onNavigatingTo">
  <StackLayout>
    <Label text="Tap the button" class="title"/>
    <Button text="TAP" tap="{{ onTap }}" />
    <Label text="{{ message }}" class="message" textWrap="true"/>
  </StackLayout>
</Page>

// main-view-model.js
var Observable = require("data/observable").Observable;

function getMessage(counter) {
  if (counter <= 0) {
    return "Hoorraaay! You unlocked the NativeScript clicker achievement!";
  } else {
    return counter + " taps left";
  }
}

function createViewModel() {
  var viewModel = new Observable();
  viewModel.counter = 42;
  viewModel.message = getMessage(viewModel.counter);

  viewModel.onTap = function() {
    this.counter--;
    this.set("message", getMessage(this.counter));
  }

  return viewModel;
}

exports.createViewModel = createViewModel;

テンプレートを使って簡単なアプリケーションを作成する

NativeScriptには、テンプレートを使ってプロジェクトを生成する機能があります。

$ tns create [Project Name] --template [Template Name]

繰り返しになりますが、テンプレートを作成した後「プラットフォームのインストール」「エミュレータの実行」を行うとエミュレートで実行確認ができます。

このテンプレートはnpmに登録されています。が、まだあまり多くのテンプレートは定義されていないようです。その中から開発時に利用できそうなものを幾つかピックアップしました。具体的なコードは各テンプレートを使ってコードを生成し確認していただけると幸いです。

タブを使ったアプリケーション

$ tns create MyNextGreatApp --template tns-template-tab-navigation

タブ切り替えのテンプレート部分はTabViewタグを使い、各タブで表示する内容はTabViewItemで定義しています。

<!-- main-page.xml -->
<Page xmlns="http://schemas.nativescript.org/tns.xsd" loaded="pageLoaded">
  <TabView>
    <TabView.items>
      <TabViewItem title="First">
        <TabViewItem.view>
          <StackLayout class="tab-content">
            <Label text="First View" class="title"/>
            <Label text="This is the content of the first tab." textWrap="true"/>
          </StackLayout>
        </TabViewItem.view>
      </TabViewItem>
      <TabViewItem title="Second">
        <TabViewItem.view>
          <StackLayout class="tab-content">
            <Label text="Second View" class="title"/>
            <Label text="This is the content of the second tab." textWrap="true"/>
          </StackLayout>
        </TabViewItem.view>
      </TabViewItem>
    </TabView.items>
  </TabView>
</Page>

Androidエミュレータでの実行結果

iOSエミュレータでの実行結果

一覧と詳細を表示するアプリケーション

$ tns create MyMasterDetailApp --template tns-template-master-detail

一覧と明細はGridLayoutを使って表示する場所を定義し、一覧部分を表示するテンプレートはListViewを使っています。

<!-- main-page.xml -->
<Page xmlns="http://schemas.nativescript.org/tns.xsd" loaded="pageLoaded">
  <GridLayout rows="auto, *">
    <Label text="Items Page" class="title" />

    <ListView items="{{ items }}" itemTap="listViewItemTap" row="1">
      <ListView.itemTemplate>
        <Label text="{{ title }}" class="listItem" />
      </ListView.itemTemplate>
    </ListView>
  </GridLayout>
</Page>

明細部分はdetails-page.xmlでレイアウトを定義していて、具体的な内容の表示にはdetails-view.xmlを使っています。

<!-- details-page.xml -->
<Page xmlns="http://schemas.nativescript.org/tns.xsd"
      xmlns:app="."
      navigatedTo="pageNavigatedTo">
  <app:details-view />
</Page>

<!-- details-view.xml -->
<StackLayout  xmlns="http://schemas.nativescript.org/tns.xsd">
  <Label text="{{ title }}" class="detail-title"/>
  <Label text="{{ info }}" class="info" textWrap="true"/>
</StackLayout>

Androidエミュレータでの実行結果

iOSエミュレータでの実行結果

サイドメニュー付きアプリケーション

$ tns create MyDrawerApp --template nativescript-template-drawer

サイドメニュー付きアプリケーションを作成する場合には、サイドメニューdrawer-content.xmlを定義し、メニューをクリックしたときの画面をそれぞれ定義しています。

<!-- drawer-content.xml -->
<grid-layout class="drawer-content">
  <stack-layout>
    <label text="Home" tap="navigate" class="{{ selectedPage == 'home' ? 'selected' : '' }}" />
    <label text="About" tap="navigate" class="{{ selectedPage == 'about' ? 'selected' : '' }}" />
    <label text="Settings" tap="navigate" class="{{ selectedPage == 'settings' ? 'selected' : '' }}" />
  </stack-layout>
</grid-layout>

Androidエミュレータでの実行結果

iOSエミュレータでの実行結果

NativeScriptとAngular2を組み合わせる

ここからが本記事の一番のポイント、「Angular2を使ったNativeScriptアプリケーション」に入ります。準備が長くて申し訳ありません！

npmにはいくつかのAngular2を利用したNativeScriptのテンプレートがありますが、今回はNativeScriptのチュートリアルを参考に、githubリポジトリーからテンプレートをcloneしたものを利用します。

NativeScript with Angular2で作るHello World

まずはリポジトリhttps://github.com/NativeScript/sample-Groceriesをcloneします。clone後、angular-startをcheckoutすると、NativeScript with Angular2で開発するための最も基本的な構成を得ることができます。

$ git clone https://github.com/NativeScript/sample-Groceries.git
$ cd sample-Groceries
$ git checkout angular-start
$ tree -L 2
├── app
│   ├── App_Resources
│   ├── app.component.ts
│   ├── app.css
│   ├── app.routes.ts
│   ├── main.ts
│   ├── package.json
│   ├── pages
│   ├── platform.android.css
│   ├── platform.ios.css
│   ├── shared
│   └── utils
├── package.json
├── platforms
│   └── ios
├── references.d.ts
└── tsconfig.json
$ tns platform add ios
$ tns platform add android
$ tns run ios --emulator
$ tns run android --emulator

Androidエミュレータでの実行結果

iOSエミュレータでの実行結果

NativeScriptではBootstrapに特別なメソッドnativeScriptBootstrapを利用します。具体的にエントリーポイントmain.tsは次のように記述されます。

// main.ts
import {nativeScriptBootstrap} from "nativescript-angular/application";
import {AppComponent} from "./app.component";

nativeScriptBootstrap(AppComponent);

Angular2では、NativeScriptのXMLを@Component.templateにディレクティブとして定義します。ただ@Component.templateではXMLをそのまま利用できないので、少し書き換える必要があります。具体的には<foo />を<foo></foo>に書き換えるといった作業です。

具体的にこのサンプルの場合、XML定義では

<Label text='hello world' />

ですが、Angular2ではコンポーネントとして定義します。

// app.component.ts
import {Component} from "@angular/core";

@Component({
  selector: "my-app",
  template: "<Label text='hello world'></Label>"
})
export class AppComponent {}

LabelはHTMLタグではなくNativeScriptで定義されたディレクティブです。NativeScriptでは幾つかのUIコンポーネントを定義していますので一覧にまとめます。

UIコンポーネントのマッピング

NativeScriptのUIコンポーネントは、iOSやAndroidのウィジェットにマッピングさせています。ビルドするとNativeScript with Angular2で定義したコンポーネントがマッピングされたiOSやAndroidのウィジェット変換されます。具体的な利用方法に関しては、Native Script UI Componentsを見ていただきたいと思います。

NativeScript + Angular2でHello World

はじめに作成した「NativeScriptで作るHello World」のAngular2版のテンプレートがあります。アプリケーションの動きはまったく同じですがAngular2で書かれています。

$ tns create MyNgNativeScriptApp --template tns-template-hello-world-ng 
$ cd MyNgNativeScriptApp
$ tns platform add android
$ tns platform add ios
$ tns run android --emulator
$ tns run ios --emulator

テンプレート部分を見比べると、XMLで書かれていたテンプレートコードがAngular2スタイルで記載されていることが理解でき、結果見通しのよいコードになっています。

<!-- app.component.html -->
<StackLayout>
  <Label text="Tap the button" class="title"></Label>
  <Button text="TAP" (tap)="onTap()"></Button>
  <Label [text]="message" class="message" textWrap="true"></Label>
</StackLayout>

// app.component.ts
import {Component} from "@angular/core";

@Component({
  selector: "my-app",
  templateUrl: "app.component.html",
})
export class AppComponent {
  public counter: number = 16;

  public get message(): string {
    if (this.counter > 0) {
      return this.counter + " taps left";
    } else {
      return "Hoorraaay! \nYou are ready to start building!";
    }
  }
    
  public onTap() {
    this.counter--;
  }
}

Todosアプリケーション

NativeScriptのサイトには、より多く機能が実装されたチュートリアルBuilding Apps with NativeScript and Angular 2を提供しています。完成したアプリケーションは先ほどと同じリポジトリhttps://github.com/NativeScript/sample-Groceriesにありますので、是非見て下さい。

$ git clone https://github.com/NativeScript/sample-Groceries.git NgTodosNative
$ cd NgTodosNative
$ tns platform add ios
$ tns platform add android
$ tns run ios --emulator
$ tns run android --emulator

Androidエミュレータでの実行結果

iOSエミュレータでの実行結果

サンプルコードを読むと、NativeScriptで利用するnativeScriptBootstrapの使い方やNativeScript用のルーティング設定が記載されていたりとAngular2の特徴を活かした実装になっています。

今回は、環境設定からはじまり、NativeScriptを使ったもの、NativeScript wit Angular2へと進め、Hello World的なアプリケーションを動かすところまでをテンプレートを使いながら簡単に説明させていただきました。

最後に

NativeScriptの事例がないかと探してみましたがNativeScript Showcasesにいくつかありました。このアプリケーションがAngular2をベースにしたものかはわかりませんが、NativeScriptを使ったものです。

NativeScriptのXMLで定義したUIコンポーネントが、コンパイル時にiOS、Androidのウィジェットにそれぞれマッピングされネイティブアプリにコンパイルされます（ちょっと古いですがXSLTを思い出しました）。Angular2の@Component.templateを利用することでNativeScriptがUIコンポーネントの定義を解釈し、ネイティブコードの生成を行っています。

ただし、NativeScript with Angular2用に作成したコンポーネントとNativeScriptを使わない通常のAngular2のコンポーネントとの相互再利用性は低いです。ですが、慣れたAngular2の構造を利用しTypeScript(もしくはJavaScript)で書けるというのは非常に興味が湧くところです。

編集部よりお詫び
2016/9/9 18:30 編集部が付けた以前のタイトルは、一部の方を不快にさせる可能性があるとの判断のもと、記事タイトルを変更いたしました。 執筆者の佐川さん、及び以前のタイトルを不快に感じた多くの方々に、深くお詫び申し上げます。

React現状確認

＠koba04氏は「React現状確認」というタイトルで、現在、Reactの取り巻く状況を様々まとめて語りました。

皆さんご存知の通り、React.jsはFacebookが開発しているJavaScriptライブラリです。まず、Reactはどのようなアプリで利用されているかということからお話します。具体的な例として、まず挙げられるのがFacebookです。ここではバリバリに利用されていますし、Instagramでは、アプリケーション全体がすべてReact.jsで作られていますので、Reactのdevtoolを使って中身を見てみるとなかなか面白いかもしれません。

Netflixではヘビーに利用されていて、テレビのレンダリング部分でも使われています。Twitter(mobile)も、React+Redux+React Routerの構成で利用されています。uberでは最近サイトをリニューアルし、そこでは先の構成にサーバサイドレンダリングなども利用しています。

どのような人がReact.jsを利用しているかというと、パフォーマンスが速いから使っているという人はあまりいない。それよりも宣言的なコンポーネント、ピュアなコンポーネントを定義するためといったことや、メンテナブルなUIを作るために使っている人が多いです。

その他、新しく実装された機能、現状議論されている多くの機能についてコメント。盛りだくさんなので具体的な内容については省略します。詳細な話については、当日の資料をご参照ください。

• Stateless Function Component
• ES2015 Classes & ES2015 Classes Components
• React.createClass
• React.PureComponent
• A pitfall of shouldComponentUpdate
• react-addons-perf
• why-did-you-update
• unstable_batchedUpdates
• ReactElement

最後に、ミーティングが毎週行われていて、ミーティングノートが１週間ごとに出しています。今後のReact.jsはライブラリとしてもっと小さくしていくことや、レンダラー部分についてどう改善していくかなど議論しています。

the-state-of-react-dot-js-2016

なぜReduxを使うのか

＠kuy氏から、最近人気上昇中のReduxについて、Reduxとはどういったものかを語りました。

Reduxが最近注目されている理由は、事例が多くなってきているのと、コミュニティが活発になってきているということが挙げられます。特に開発するための周辺ライブラリが充実し、機運が高まり、Reduxが注目され始めています。

反面、Twitter等でよく見かける投稿は、Reduxがつらい、Redux難しい、Reduxの良さがわからないという意見もあり、結果としてRedux大丈夫なのかと思わせてしまうようなことも起きています。

そこで、なぜReduxを使うのかということを整理してみます。特に、作者のDan Abramovさんいわく、「ライブラリの使い方に時間を費やすよりも背景にあるアイデアを学んで、他所に活用していこう」ということを訴えています。

Fluxは何を解決したのか

Fluxの考え方はご存知の方も多いとは思いますが、順番としてはまず、ViewからActionが投げられます。Dispatherはこの投げられたActionをStoreに投げるルーティングの役割をしています。StoreはActionを受け取ってStateを変更します。このStateの変更をViewが受け取って、Viewはその情報に従ってレンダリングを行うという流れです。

Fluxで解決したかったことは、基本的にはReact単体で構築したときに困ることを解決したかった、具体的には、バケツリレーという問題がありました。バケツリレーというのはコンポーネント階層が深くなったとき、例えば深い階層のコンポーネントへイベントを伝搬するときに、途中のコンポーネントには無関係にも関わらず、通過していくという問題がありました。

Stateをコンポーネントで持っている場合、他のコンポーネントへそのStateを渡したい場合、このコンポーネントの上位の親コンポーネントを作ねばならないという問題があった。何かするときに必ず親コンポーネントを作らないといけない。

Reduxの何がいいのか

FluxにはDispatcherが存在していましたが、ReduxではDispatcherがStoreの中に組み込まれていました。FluxでもStoreがあるが、ReduxではそのStoreを役割ごとに名前を変え、利便性を向上させたところがポイントです。

では、より具体的にReduxのどこがいいのかというと、1つの大きなStateツリーを複数のReducerで構築しています。そして、状態管理だけに特化したところです。反面、それ以外は開発者に丸投げということになりますが、よく言えば開発者の状況に応じて開発できるということを意味します。

そして、状態管理に特化したということがあるので、Reduxを素の状態で利用するのはお勧めできないし、無理してReact, Action, Creator, Reducerで実装すると後で大変な思いをするということです。専用のMiddlewareを入れるといいとのことです。

※当日の資料は以下にアップされていますので、こちらも参照してください。

nazereduxwoshi-ufalseka

Relay

＠hokaccha氏によるRelayのお話です。

RelayはクライアントにReactを利用し、サーバにGraphQLを使ったものです。仕様としてまとめたものがGraphQL Relayで実装としては、react-relayとgraphgl-relayがあります。Relayをひと言で言えば、フルスタックなフレームワークです。Angularがよくフルスタックといわれますが、Angularはクライアントだけなので、Relayはサーバまでやっていますので、本当のフルスタックということになると思います。

GraphQLとは、Facebookが開発したクエリ言語で、クライアント/サーバ間でデータのやり取りに利用されます。レイヤーとしてはREST/RPCと同じ位置付けになります。

RESTと違って、リクエストに対するレスポンスのフィールドが1:1対応しているところです。そうすると、必要なフィールドだけを選択可能となり、ネスとしたデータを一発で抽出できることや、型定義が存在するなどメリットがあります。

Relayの特徴は、そのサイトにも書いてある通り3つあります。

• DECLARATIVE
• COLOCATION
• MUTATIONS

しかし、Relayは敷居が高いと思います。例えば、GraphQLを覚えて、ちょっとしたアプリを作るにもGraphQLのサーバが必要になりいろいろと大変になる。そしてやっている人もあまりいないので、資料を探すとちょっと大変な思いをします。Relayの期待として、真のフルスタックなフレームワークになり、次世代のRailsになれる可能性があるかもしれないかもしれないです。

※当日の資料は以下にアップされていますので、こちらも参照してください。

relay-1

How to style React components

＠Quramy氏からは、コンポーネント内にあるCSSの話がありました。同氏はメインサービスとしてはAngularを使っているが、社内系ツールではReactを使っています。

UI Componentと呼ばれるものの特徴は、見た目と振る舞いがまとめて提供されていて、適度にカプセル化されているものです。そうなると再利用性が高くなり、保守しやすくなるところに期待があります。このコンポーネントは多くのJSフレームワークでサポートされています。

Style定義は、とても壊れやすいです。コンポーネントの外部から、CSSを破壊することが簡単にできるからです。つまり、React.Componentを使っただけでは、CSSが適切にカプセル化されているわけではないのです。この問題は、CSSセレクタがGlobalであることが最大の問題だと言えます。この問題解決のために、

• CSS命名規約
• Web Component(Shadow DOM)
• CSS in JS
• CSS Modules

ということが挙げられます。

CSS in JS

CSS in JSは、Christopher Chedeauが2014年に発表しました。ReactはJSXでテンプレートをJavaScriptに取り込むことに成功したので、CSSもJavaScriptに取り込めばいいのではということから始まりました。CSS class名を利用しないでinline-styleを利用することで、Styleをコンポーネントに閉じ込めることが可能になり、問題の発生がなくなります。

こうした考えは、他にもいくつかメリットがあります。デメリットとしては、擬似要素セレクタや擬似クラスセレクタなど、インラインスタイルで定義できないようなものは利用できません。

CSS Modules

Glen Maddernが2015年に定評しました。CSS in JSはJavaScriptでStyleを生成したのに対し、CSS ModulesはCSSをJavaScriptから利用するというアプローチを取っています。CSSでできることは、CSSでやろうと言ったところです。

CSSで定義された名前を論理名として扱い、JavaScriptでimportし、その定義を読み込みます。JavaScriptが実行されるときに内部的に付与した名前に書き換え、容易に破壊できないようにしています。

※当日の資料は以下にアップされていますので、こちらも参照してください。

react-css-note

Atomic Design powered by React @AbemaTV

五藤佑典氏による＠AbemaTVの事例紹介です。

＠AbemaTVはサイバーエージントとテレビ朝日が共同で展開していて、多様なコンテンツがあります。AbemaTVでは、開発の初めスマホアプリで開発は進んでいましたが、Web版はなく仕様が決まっていませんでした。しかし、リリース日は決まっているという状態でした。

このような状況では、作っていくうちに画面変更が多々入るのがわかっていたので、わかるところから作るという方針でせめて行きました。

画面仕様の変更に強いコンポーネントの粒度を、チームで明確化したいという欲求が出てきました。ATOMIC DESIGNを参考にしました。ATOMIC DESIGNとは、UIコンポーネントの要素を化学の原子論的な要素に見立て、小さいシンプルなコンポーネントを組み合わせより大きなコンポーネントを構成するデザインシステムのことです。

ATOMIC DESIGNの考え方を適用しグローバルナビ、リモコン、スライダー、アイコンなどを作っていきました。こうして作ったAbemaTVの細かな画面変更に関し粒度がある程度細かったため、変更は割とスムーズにできたというところがこのシステムを採用した良い結果だったと考えています。チーム開発において個人の感覚に依存しない形で行えたことは、プロジェクトがうまくいった要素であります。

@AbemaTVはReact+Flux+Atomic Designですが、ViewでReactとAtomic Designを利用し、StoreでImmutable.js、DespatcherでRxJSを使っています。

当日の資料は以下にアップされていますので、こちらも参照してください。

atomic-desigin-powered-by-react-abematv

最後に

このレポートではイベントが盛りだくさんだったため、内容の細かなところまでは記載できませんでした。各登壇者の資料もアップされていますので、合わせて見ていただけると幸いです。また、html5j配信班による動画もありますので、参照してください。

本イベントとは関係ありませんが、2016年のHTML5カンファレンスが9月3日（土）東京電気大学に決まりました！乞うご期待！！

5月24日、25日の二日間にわたり開催されたMicrosoftの技術者向けイベント「de:code 2016」で、日本マイクロソフト赤間信幸氏の「エンプラ系 業務Webアプリ開発に効く！実践的SPA型モダンWebアプリ開発の選択手法」というセッションを聴講しましたので、そのレポートをお届けします。

ただタイトルにもある通り、筆者的にはちょっともやもやする内容でもあったので、HTML5 Experts.jpコントリビューターの酒巻瑞穂さんと、講演の内容をベースとした軽い対談も行いました（後日、エンタープライズWebアプリのあるべきかたちについて、もっと掘り下げた内容の記事も作る予定です。乞うご期待）。

セッションレポート

SPA(Single Page Application)とは

今、Single Page Application(以降、SPAと記載する）が業務アプリケーションでも利用できないかということが話題になっています。復習になりますが、SPAとは以下の様な特徴を持つアプリケーションです。

• 単一ページで機能を提供するWebアプリケーション
  • ページをリロードせずにJavaScriptでWebAPIと通信
  • JavaScript、CSS、HTMLを組み合わせて画面を更新
  • これにより応答性が高く、使い勝手の良いWebアプリケーションを実現する
• Web上では割とSPAは一般的だが、業務アプリケーションでもSPA型の開発ニーズが高まっている

従来型のWebアプリケーションはサーバサイドが中心でした。そのほとんどの処理をWebサーバで行い、クライアントは受け取ったHTML、CSSを使ってレンダリングを行い、若干のJavaScriptを動かすというものでした。SPA型のWebアプリケーションでは、サーバはクライアントの指示に応じてデータを返し、UIの更新等はすべてクライアントで行います

SPA型Webアプリケーション開発の難しさ

このようなSPA型アプリケーション開発は相当のスキルが必要であり時にとてもむずかしいものになります。特に、SPA型Webアプリケーション開発に関するネット上の情報は、低水準からスクラッチで開発するためのものが多い。OSSなどをフル活用して作りこむ、いわばC++開発のような「職人技」の世界であり、ハードルが高いのが現実です。

エンタープライズ系業務Web開発の場合、こうした「職人的開発」はあまり向いていないように思います。

ここでエンタープライズ系開発とオープン系開発のギャップを確認してみましょう。

このような比較から、.NETのような高水準言語での開発に慣れ親しんだ開発者が、SPA開発に取り組むのはハードルが高いといえます。まとめると次の問題が挙げられます。

• 低水準開発の必要性：HTML, CSS, JavaScriptでの開発はC#, .NETでの開発に比べて低水準
• 高すぎる開発自由度：「どう作るか」は自分でゼロから決める必要がある
• ライブラリの選択の難しさ：膨大なライブラリからどれを選べばよいか分からない

そしてSPA型開発では、利用するフロントエンドライブラリによって作り方が大きく変わります。同じ「HTML5」の開発といえど、コードの互換性はほとんどありません。このためライブラリの選択には特に慎重を期す必要があるといえます。

そこで、自分のプロジェクトに合わせた適切なライブラリの選択が必要になるのですが、実際の現場ではこれが非常に難しい。Microsoftからは、クライアントライブラリは（ほぼ）提供されていませんが、世の中にライブラリは星の数ほどあります。

ライブラリを選ぶ際に考慮すべき事項

言語拡張

ここで、ライブラリを選択する際の私なりのやり方をご紹介します。ライブラリの選択では、基本言語仕様、DOM操作、通信処理、CSSに分けて考えてみます。そうすると、DOM操作・通信部分はほぼ必須になるので、jQueryを利用すればいい。基本言語仕様とCSSに関しては、スクラッチの作り込み型Webアプリケーションでは非常に重要ですが、業務Webアプリケーション開発の場合はケースバイケースです。より具体的に言うと、CSSではLess、SASS、StylusなどのCSSプリプロセッサーの選択、altJSでは、TypeScript、CoffeeScriptの選択などが挙げられます。

UIライブラリ

UIライブラリに関しては、低水準UI部品郡と高水準UI部品郡に分けて考えます。低水準UIライブラリには無償のものが多く、高水準UIライブラリは高機能ではあるが、ほとんどの場合有償製品となっています。

設計・実装方法論、フレームワーク

進化が激しくトレンドも頻繁に変わるため、注意が必要です。フレームワークを利用すれば、ロックインも発生します。特にWebフロントエンドの世界では数年と経たずにトレンドが変化します。このため頻繁に手を入れる見込みがない場合には、むやみにフレームワークに依存させるのは危険だと考えます。

各種ツール、ユーティリティ

どのような各種ツール、ユーティリティを利用するかというような考えは、初めてSPA型開発に取り組む場合には、後回しにするとよい。より高い生産性を目指す際には欠かせないツール郡ではあるが、ここまで述べてきた、言語拡張、UIライブラリ、設計・実装方法論、フレームワークなど覚えるべき要素、考えるべき要素が山ほどあります。最初はなくてもなんとかなりますので、必要性を感じたところから段階的に導入していくことをお勧めします。

ライブラリの組み合わせに関する注意

ライブラリは安易に組み合わせないように注意しましょう。ライブラリには必ず寿命がある上、複雑に依存しあっていることも多い。古いライブラリが他のライブラリのバージョンアップの足かせになることがあります。

長期的な保守が重要になる業務Webアプリケーションでは安易にライブラリを組み合わせるべきではないと考えています。

SPAフレームワークライブラリ

商用の高水準UI部品ライブラリは高価ですが、多くはオールインワンパッケージ（=SPAフレームワーク）になっていて、ライブラリの組み合わせ方で悩む必要が少なくなります。

このため、業務Webアプリケーション開発におけるクライアントライブラリの選択は、高水準UI部品の要否で大きく方針が変わります。

OSSライブラリの組み合わせ型開発では、利用できる高水準UI部品が少なめなので、メジャーなライブラリを中心に必要最小限の組み合わせを行います。。SPAフレームワークライブラリ依存型開発では、高水準UI部品が数多く利用できるので、シェア、情報量、日本語サポート、ライセンス費用などを元に選択するとよいでしょう。

サーバ側のページ構築

個人的には完全なSPA型ではなく、うまくサーバ技術を併用した方がSPA型の業務Webアプリケーションは作りやすい。特に.NET開発者の場合、複雑な業務ロジックはサーバ側でC#を使って記述した方が作りやすいことも多いでしょう。実際のSPA型アプリケーション開発では、サーバ側で組み立てなどにASP.NET MVCを併用するといいのではないでしょうか。UI処理の中心はあくまでもクライアントだが、上手に併用しましょう。

編集後記: 講演の内容について対談してみました。

レポートは以上になります。ただ、講演の結論が結局のところ「完全なSPA型じゃないほうがいい」と言っているように思え、少し違和感が残ったのも事実。そこで、同じくセッションを聴講していたコントリビュータの酒巻瑞穂さんと、疑問に感じたところを少し話し合ってみました。私も酒巻さんも、現役でエンタープライズWebに取り組んでいるエンジニアとして、これを機にエンタープライズ×SPAについて整理しておきたいと考えたからです。以下、その対談の内容を編集後記として掲載します。

SPAはつらい？

佐川：講演を聞いて、どんな感想を持ちました？

酒巻：正直、ちょっと違和感残る内容でしたね。

佐川：結論が結局、本格的なSPAは難しいからやめとこう、と言っているようにも聞こえました。

酒巻：私も、メリットが見えないものはがっつりSPAにする必要はない。何もかもSPAにすべきとは思いません。ただ例えば、モバイルの事を考えると、SPAにしていくメリットは大きいですよね。クライアントサイドでのオフライン処理を求められることも多いので、そうなるとSPAで作るほうが自然だったりする。

SPAはセッションをクライアント上で維持できるので、Server Push型のイベントが必要なアプリケーションを作る必要がある場合にも有効ですね。

佐川：SPA開発は職人技という話がありましたけど、ここはどうですか？

酒巻：職人技…かどうかはわかりませんが、開発の自由度は確かに高いですよね。アプリケーションの品質が、プログラマ個人の力量に左右される部分はまだ大きいですね。

佐川：フレームワークがそういう問題解決を担えるはずなんですが、そのフレームワークが多すぎるという(笑) 。講演でも「ライブラリ選択が多すぎる」という問題提起をしていらっしゃいましたね。

酒巻：確かにそれは同意できます。でも、「開発時の選択肢がない」というのは言い換えると「衰退する技術」のようにも思えるので、個人的にはむしろ今の状況は歓迎しています。業務エンジニアとしては社内ルールなどを作って統制する方がいいんじゃないかと。

佐川：それにライブラリの選択も、Yeomanなどのジェネレータやいろんなスターターキットを使えば、かなりの部分楽できますよね。

SPAの設計は悩ましい

酒巻：ただ、講演でも取り上げられていましたが、設計の方法論などについては確かに難しいです。ここはまだ結論がないと言うか、個人的にも難しいところですね。というのもWebの進化がまだ当分先を見てるので「今」の最善はあっても来年の最善はもう判らない。

佐川：設計方法論は、採用するフレームワークによっても大きく変わってくるところですしね。ただ、今のトレンドとしてはUIのコンポーネント化というのは間違いない方向性なので、そこからスタイルを決めていける。ただ、設計方法論を語った書物はあまり見られないのも事実で、これはWebの進化が早すぎるためではないかと。

しかしSPA設計の話って、「サーバでやるか、クライアントでやるか」って話になりがちですよね。ただ、MVC的なものをどちらかに寄せなければならないという話ではない。基本的には、UIを更新する処理はクライアントに寄せるというほうが筋が良いと思います。

この話はSPAをどうするかという話ではなく、もう少し広くWebアプリケーションをどうやって作るかの話です。SPAでもMPAでも議論としては同じで、SPAにすべきかそうすべきではないということになる。 そういう意味でも、SPAを採用すべき勘所とか、Webアプリケーション全体の中のSPAの位置付けについて、先ほどの講演でもっと聞きたかった。

酒巻：個人的には、ちょっと古い内容でしたね。「DOM操作はjQuery」と言っていたが、個人的にもうあまりやりたくない(笑)。

佐川：そうそう、個人的には4年くらい前の感覚に思えました。その頃とはWebアプリケーション開発のやり方そのものが変わっている。もちろん（Webアプリケーションではなく）Webサイトを作るときにわざわざReact.jsとかAngularを利用しなくてもいい。そういう時はjQueryでもいいと思います。こういうものは当たり前ですが、適材適所で考える必要があって、それこそマネージャやアーキテクトの腕の見せどころなのではないでしょうか。

最後に

ここのところ、確かにエンタープライズでSPAの導入が多くなってきました。 一方でまだまだ事例が少ないこと、開発経験のあるエンジニアが少ないため導入しようとしてもなかなかプロジェクトとして進められないという現状もあります。この記事が、エンタープライズWebアプリの開発に少しでも寄与できたなら幸いです。

エキスパートの佐川が、「de:code2016」のセッションレポート、日本マイクロソフトエバンジェリスト・物江修氏の「Developing on the Edge. 〜 WebプラットフォームとCordova 〜」をご紹介します。

今年の夏、MicrosoftはWindows 10の大型アップデート「Windows 10 Anniversary Update」を予定している。このアップデートで「Microsoft Edge」にも数多くのAPIが追加される。このセッションでは新しく追加されるAPIの紹介と、それらを利用したUniversal Windows Platform(以下、UWPと記載する)、Cordovaアプリケーションの開発ポイントを紹介する。

• Microsoft EdgeとWindows10のWebプラットフォーム
• EdgeHTMLの新機能とこれからの方向性
• Webプラットフォームを利用したアプリケーション開発

Microsoft EdgeとWindows10のWebプラットフォーム

初めに、Microsoft EdgeとWindows 10で「Webプラットフォーム」と呼んでいる事柄についてみていく。すでにご存じのとおり、Windows10には、2つのマイクロソフト製のブラウザが含まれている。Windows10から新しく採用された「Microsoft Edge（以降、Edgeと記載する）」と「Internet Explorer11」である。

Webブラウザが2つ入っている理由は、以下のとおり。

• Edgeは相互運用性を重視し、最新のWebコンテンツをブラウズするため
• Internet Explorer 11は過去のバージョンのIE向けに作られたコンテンツを従来どおりに見るため

この二つは物理的に完全に別なものとなっていて、レンダリングエンジンもJavaScriptエンジンも異なる。

EdgeのレンダリングエンジンとJavaScriptの組み合わせが、Windows 10用のアプリケーションを開発する際に使用されるWebプラットフォームになるが、現状、Windows 10で動作するアプリケーションのすべてがEdgeのエンジン（以降、EdgeHTMLと記載する）を利用しているわけではない。

どういう意味か。

アプリケーションとの組み合わせを見てみる。Windows 10から採用されたUWPアプリケーションは、EdgeHTMLを使用している。しかし、以前の環境で作られたWindows 8系のいわゆるWindowsストア・アプリケーションやデスクトップ・アプリケーションであるWin32アプリケーションは、以前の Tridentを使用している。

新しいSDKに含まれるWeb ViewコントロールはEdgeを使用するようになっているので、もしどちらも選択が可能である場合はEdgeHTMLを使用する。

Windows 10 Anniversary Updateまでに搭載されるEdgeの新機能

ここからは「Windows 10 Anniversary Update」までに搭載されるEdgeの新機能について紹介していく。Edgeのエンジンが、Windows 10でアプリケーションを開発する際に使用するWebプラットフォームの機能になるので、そのままアプリケーションから使用できるようになる。

Edgeの2016年の機能実装を含めた展望については、今年の2月にEdgeの開発者ブログで公開されており、その記事では優先課題とて5つ存在する。（参考までに、日本語の開発者ブログはこちらです）

1. WebテクノロジとWindowsストアによるモダン拡張機能プラットフォームを提供する
2. アクセシビリティとインクルーシブ デザインにより、Microsoft Edgeを使うすべての人の力になる
3. Microsoft Edgeの基本であるセキュリティ、パフォーマンス、効率を引き続き向上させる
4. Webの未来を見据えて開発する
5. コミュニティのフィードバックや参加を可能にするチャネルを増やす

まずは拡張機能。ネイティブ形式のアドオンとは異なるWebテクノロジを活用した、開発者になじみのある拡張機能プラットフォームを作成する。現在のInsider Previe版のEdgeでは同じくプレビュー版のアドオンを使用できるようになっている。

次にアクセシビリティ。この項目では「HTML Accessibility API Mappings」と「Core Accessibility API Mappings」への対応、「ハイコントラストのサポート」や「視覚障碍のある方にとっての読みやすさ」や、「フォーカスおよび選択の操作性の向上」などが表明されていた。

基本機能では、「JavaScript エンジンのベンチマークの向上」「さらなるセキュリティの強化」たとえばFlashを別のプロセスに分離し、不要なコンテンツ処理を保留したり、GPUレンダリングの強化などが表明されている。

Insider Preview に搭載された新機能

ここからは「Insider Preview」に搭載された新機能について紹介していく。現在、Insider Previewに実装されていて、実際に試すことができるものが約20個以上、開発中のものを含めると36個くらいあり、しかも、これは現段階のものなので、これからまだ増える可能性がある。

• Web Speech API (synthesis)
• Fetch API
• Beacon
• Web Notifications
• WebRTC
• OPUS open audio
• VP9 open video playback
• WOFF File Format 2.0
• FIDO 2.0 Password
• Canvas 2D path2D
• Ambient Light Events
• Color input type
• Element
• Default parameter (ES2015)
• Destructuring (ES2015)
• Generators (ES2015)
• SIMD (after ES2016)
• Exponentiation Operator (ES2016)
• Array.prototype.includes (ES2016)
• Async Functions (after ES2016)

Insiger Previewに新しく搭載された機能をいくつか、デモを交えながら紹介する（この記事ではデモ資料省略）。

Web Speech API

IETF標準の言語タグである「BCP 47」に対応しており、タグの指定によってさまざな言語の指定ができる。音量、音声、速度はもちろん、SSML (Speech Synthesis Markup Language) を使用して音声合成時の修飾的情報を指定したりもできる。

Fetch API

「Fetch API」は、Webサーバと通信するためのAPIで、Promise ベースで非同期処理を行える。従来の「XMLHttpRequest」の仕様のさまざまな不足分をなくし、より細かい処理ができるようになっていて、将来的に「XMLHttpRequest」は「Fetch API」に置き換わると言われている。「Fetch API」は「XMLHttpRequest」とは異なり「Service Worker」からも使用できる。参考までに「Service Worker」とは、「Progressive Web Apps」というモバイルWeb向けの新しいコンセプトだ。

Web Notifications

「Web Notifications」はユーザーへのデスクトップ通知の設定や表示のために使われるもので、EdgeではWindows 10のアクションセンターと統合される。この通知には、カスタムアイコンやタイトル、メッセージが設定可能だ。Service WorkerとPush APIを組み合わせると、サーバからのPuch通知を受け取って表示したりということが可能になるが、残念ながらこの2つはまだサポートされていない。しかし、ブラウザ上でアプリケーションが稼働状態であれば、WebSocktsやWebRTCの通知を受け取ってデスクトップ通知を表示するといったことが可能だ。

WOFF2.0フォント

WOFF2.0フォントは、従来のフォントファイルのサイズを30%以上多く減らす新しいフォーマットだ。日本語を含むアジアフォントではおよそ50%前後節減できると言われている。現在、Webページの60%以上でカスタムWebフォントが使用されていて、平均的にWebページのサイズの5.3%を占めると言われているので、これをサポートすることでページの表示速度の向上が期待できる。

WebRTC

WebRTCについて。RTCとは「Real Time Cominucation」の略で、プラグインなしでWebブラウザ間のボイスチャット、ビデオチャット、ファイル共有ができる技術がWebRTCだ。Firefox、Chromeは、Edgeに先行してWebRTC1.0をサポートしているが、EdgeはWebRTCの使い勝手を改善したORTCのみをサポートしてた。このWebRTCとORTCは互換性があるので、互いに通信を行うことができるが、さらなる相互運用性を高めるためにEdgeHTML 15では、WebRTC1.0もサポートすることになった。

RTCの相互間運用性

その他

そのほかにもオーディオ用の高い圧縮フォーマットであるOpusや動画圧縮コーデックのVP9、細かい時間の計測に使用される「High Resolution Time」のLebel2や、フォルダのドラッグ・アンド・ドロップ、Webブラウザで生体認証を行うためのFIDO(ファイド)2.0、それからBeacon、アクセシビリティ関連のエレメントなどなど多くの機能がサポートされる。

ハイブリッド・アプリケーション

説明した機能は、ハイブリッド・アプリケーション開発用の様々なフレームワークを使用することで、スマートフォンやデスクトップのアプリケーションとして利用することができる。ここからは、Webプラットフォームを利用したアプリの開発について紹介していきます。

ブラウザで動作するWebアプリケーションを、ハイブリッド・アプリケーション化するメリットは3つほどあります。

• オフライン
• アプリストアのエコシステム
• プラットフォーム/ハードウェアの機能

もう少し待っているとEdgeでもService WokerがサポートされてWebアプリケーションでもオフラインの利用が可能になるので、実際にアプリケーション化するメリットというのはアプリストアのエコシステムを使用するとか、Webブラウザでは使用できないハードウェアの機能を使用するということぐらいに差が縮まる。

このハイブリッド・アプリケーションの形式には、Packageアプリケーションと、Hotedアプリケーションがある。Packageは、オフラインで利用可能。サーバサイドのリソースががならずしも必要でない。Hostedは常に最新のコンテンツで実行でき、開発の一元化が可能だがオフラインでの使用が前提となる。ざっくり言うとコンテンツの配置場所くらいしか違いはない。

Universal Windows PlatformとCordovaを利用したHostedアプリケーション

UWPとCordovaで、どのようにHostedアプリケーションを作るか、というのを紹介する。

UWP

これがWindow 10に用意されている、アプリから使用可能なOSリソースだ。プッシュ通知や、タイルへの情報表示、予定表、アドレス帳へのアクセス、Cortana連携とWindowsランタイムを使用し、さまざまなハードウェアにもアクセスできる。作成は

1. package.appmanifestの[アプリケーション]タブで[スタート]を指定
2. [コンテンツURI]タブでWinRTへのアクセスを設定
3. 使用しないファイルを削除

Cordova

Tools for Apache Cordovaが提供する機能は

• ターゲット
• ビルド
• デバッグ
• エミュレータ
• コード補完

がありiOSアプリケーションに対するビルドにはMacが必要ではあるが、ほとんどの環境(Android系/iOS系/Windows系)で実行可能だ。CordovaにおけるHostedアプリケーションの作成は以下の３つで行っていく。

1. config.xmlの編集
2. www¥scripts¥index.jsの編集
3. index.htmlの編集

尚、Apache Cordovaを使用したホスト型Webアプリケーションの作成についてはこちらの資料を見るとよい

Visual Studioで提供されている検証環境

• Ripple
• Android
• Monaca Debugger(iOS/Android)
• Windows Phone

その他、Mac OS用、リモートエージェント、Mac in Cloud(Mac OSのホスティング)などがある。

最後に、Webプラットフォームについてということと、この夏に向けていろいろなAPIが出てくる。そして、Webではできないことができるようになると物江氏は締めくくり、Microsoft Edgeのすぐそこにある未来について熱く語ってくれた。今最も熱いブラウザは「Microsoft Edge」ではないだろうか。

この記事は、「de:code2016」のセッションレポート、日本マイクロソフトエバンジェリスト物江修氏による「モダンWeb:たった今と、ほんの少し未来のはなし」です。講演内容を再現していますが、ニュアンス等伝えきれない場合があるかもしれません。ご了承ください。

モダンWebとは

昨今、様々なところで「モダンWeb」という言葉を聞くが、その定義は曖昧で意味するところの範囲が広範囲に及んでいるためではないかと考える。多くの場合、「モダンWeb」という文脈で語られている内容は次の４つの事柄で語られている。

• モダンなWebシステム
• モダンな開発手法
• モダンな標準機能
• モダンなアプリケーション

単にモダンWebアプリケーションと言った場合にはこれらいろいろな意味に捉えることが多いが、このように四つに分けることができる。このセッションでは、アプリケーションを開発するのに必要な「モダンなWeb標準の機能」、「モダンなWebアプリケーション」に関して触れる。

なぜ「モダンWeb」が話題になっているのか

第一に挙げられることは「時代の要求」。具体的には以下の3つが挙げられる。

• Web技術の進化
• コンテンツのリッチ化
• クライアントの多様化

Web技術で作るリッチなUIは昔から存在していたが、以前はFlashなどのプラグインを利用したいわゆるRIA(Rich Internet Applications)のほうが優勢だった。その後、Ajaxでデータを取得し、そのデータを使って部分的なUIの更新が可能になり、jQuery UIなどのUIライブラリによる開発生産性の向上、そしてHTML5の登場によって、プラグインで行っていたことがWebの標準技術だけで作ることが可能になった。これがWeb技術の進化である。

そしてスマートフォンから始まったFlashの衰退が進み、今までFlashで行っていたような要求をWebコンテンツ側にやってくるようになり、コンテンツのリッチ化が始まった。

スマートフォンを始め、PCブラウザー以外の様々なものがインターネットに繋がり、クライアントが多様化した。

この「クライアントの多様化」はサーバーサイドの形態にも影響を与え、その影響が、Webブラウザー上で動くアプリケーションにも影響を与えたという状況になっている。具体的にどういうことなのか。

黎明期のWebアプリケーションは、リクエストされたページを単純にレスポンスするというもの。ちなみに一番最初のWebサーバーはティム・バーナーズ・リーが作った「CERN Httpd」で、1991年にニュースグループで公開されたが、翌年に作られた「NCSA Httpd」ではCGIがサポートされ、動的ページが作れるようになった。ご存知の通り、このサーバーサイドで処理をして、処理結果をページで返すWebアプリケーションは広く使われている。

さらに、新しいクライアントとして携帯電話が現れる。NTT Docomoから始まった携帯電話は、それまでWebのクライアントというと、PCブラウザかゲーム機くらいで、いずれも机に座って使うようなものだった。

しかし、携帯電話は持ち歩き、行動に必要な情報を得るためのツールとして機能するモビリティという考え方が生まれた。

今までとは利用用途が異なる、サーバーではデバイスに応じた専用のコンテンツを作る必要があるなどコンテンツを作っていくには困難な状況だった。

やがて、スマートフォンに代表されるスマートデバイスが現れます。これらは、PCブラウザー用のコンテンツを同じ様に処理することができたので、わざわざ専用のコンテンツを用意しなくても済む。問題は、画面サイズに応じて表示を切り替える必要があり、同時期に出てきたHTML5関連技術であるCSS3を使ったレスポンシブWebデザインで、こうした技術を吸収することができた。

さらにスマートフォンは、サーバーサイドの処理にさらに大きな変化をもたらした。

Webアプリケーションの登場です。サーバにリクエストを投げるが、必要とするのはページではなくデータでした。この影響を受け、Webサーバーに必要な技術は、データを返す「API」が重要になった。

現在では、クライアントデバイスの性能とWebブラウザーの機能も数段上がり、処理性能ではネイティブで作られたアプリケーションと同等なことができるようになった。

SPA(Single-page Application)

単一ページによるWebアプリケーションであるSPAの特徴は、以下が挙げられる。

• 画面遷移はDOM操作
• ページのリフレッシュは不要
• リッチなエクスペリエンス

SPAにするメリットもいくつかある。例えば、サーバーサイドを「サービス化」することによって、多様化していくクライアントにも対応できるようになる。つまり、サービスをどこにでも提供できポータビリティを上げることができる。

現在のようにクライアント技術の進化が劇的に早い（言い換えると、陳腐化する速度も早い）状況下でもSPAは有効だ。クライアントとサーバーのロジックを物理的に別けることで保守性を上げることができるから。さらに分業においては、サーバーサイドを開発する人間、クライアントサイドを開発する人間で、やるべきことに集中できるということが挙げられる。

プログラミングスタイルの変化

SPAの登場によつてプログラミングのスタイルも少なからず変化している。Ajaxなどの非同期処理を行う場合、処理の単位はサーバーサイドの動作と必ずしも一致せず、処理の順番やタイミングもまちまちになる。それらを適切にハンドリングして画面に描画する必要がある。

さらに、ユーザーアクションの開始が、いわゆるPull型（サーバにリクエストするという意味で）だったが、WebRTCやWebSocketsの登場にによって、突発的に開始されるPush型（サーバからクライアントに通知する）可能性もある。

非同期処理の完了であるが JavaScriptではイベント通知で行われる。また、今まではサーバーロジックで行われていた処理をクライアントで行うケースも出てくるので、1つの完結する処理を行う場合、複数回サーバーとやり取りする必要がある。よく「コールバック地獄」ということに陥る。

不規則に発生するイベントを適切にルーティングしつつ、状態を把握し、かつ処理全体を制御する仕組みが必要で、こういった制御を行うために、JavaScriptのライブラリやフレームワークが様々な機能を実装し提供している。

そして、最新のモダンブラウザーがサポートしつつあるECMA Script2015や2016にも、こうした機能が標準で用意されようとしている。つまりイベントのフロー制御方法は

• Promise(ES2015)
• async/await(ES2016)
• Generator/yield(ES2015)

Promiseは非同期処理を抽象化したオブジェクトでPromiseパターンで非同期処理を行う。async/awaitは、Promise とGeneratorの糖衣構文で、そのGenerator/yieldは、反復子 (イテレータ )の生成元で、実行環境を維持したま中断・再開が可能となる。

SPAでは画面のレンダリングも従来のサーバーサイドの処理をメインしたものとは異なる。

SPA以前のサーバーサイドでページが生成されるタイプのWebアプリケーションでは、画面データの成形もサーバーサイドで行われていましたが、SPAではその部分をクライアントサイドで行うことになる。

素直に書くなら、エレメント一つひとつのインスタンスを取得して、各々データをセットする所謂「Glue code」を書く（”グルー”とは糊のこと）ことになる。だが、これだとエレメント変更に関わるUI仕様があるたびにコードまで修正する必要がありメンテナンスが大変だし、いちいちデータを入れるためだけのコードを書くということ自体が非効率。

データバインディング

そこで出てきたのがUIへのデータバインドです。 マークアップにUIとデータの関係を記述しておくと、JavaScriptフレームワークがよしなにデータをセットしてくれるという仕組みです。 こうすることで、データと画面、いわゆる ModelとViewの関係を1:1に紐づけ、構造的には明確に分け部品化することが可能になった。

“バインド”とあるように、ModelとViewの関係を保持します。つまり、モデルもしくはビューに変更が発生した場合、その変更が一方向、あるいは双方向に反映されます。Modelの変更のみかViewに反映されるのが1Wayバインドで、双方向に変更が伝わるのが2Wayバインドです。

まとめるとモダンなWebアプリケーションとは

• SPA
• リアクティブな動作
• M-V-Whatever

少し先のWebアプリケーションの技術的コンセプト

ここからは、ここ数年提唱されているWebアプリケーションの技術的コンセプトについて紹介します。

• Web Components
• Progressive Web Apps
• WebAssembly

Web Components

まずは「Web Components」です。これはWebをコンポーネント化する仕組みで、2013年のGoogle I/Oで紹介された。実は、Webをコンポーネント化するという仕組みは、これが最初ではなく、マイクロソフトも1998年にHTMLコンポーネントというものを提案したし、Mozillaも2001年にXBLと2007年にXBL2というのを提案した。

このコンポーネント化のメリット、目的について

Webのアプリケーションは、他のソフトウェア・アプリケーションと同様に複雑になり、今ではリリース製品の開発に大勢が協力して取り組むことは珍しくなくなった。少しでも効率化を図るには、関係者やシステム間の重複が最小限になるように開発作業を分割する正しい方法を見つけることが重要になる。そのための方法としてコンポーネント化がある。複雑なシステムでも、機能を分割していけば、単純化することができる。全体をある程度の機能単位に分割する、つまりはコンポーネント化だ。

Web Componentsの目標は、HTML、CSS、JavaScriptの関連グループを分離し、単一ページのコンテキスト “内” で共通関数を実行することで、複雑さを軽減することだ。

この Web Components は、複数の API を組み合わせるか、それ単独を使用して実現する。 しかし、すべての Web ブラウザーがその API をサポートしているわけではないので、Polyfill 用のライブラリーが用意されています。

そしてこちらがWeb Componentsを構成する要素です。

• HTML Templates
• Shadow DOM
• Custom Elements
• HTML Imports

現在のサポートの状況はこのようになっています。

※ 既定では動作しない

Progressive Web Apps

これはモバイル Web アプリ向けのコンセプトで、具体的には、高性能のモバイルWebブラウザー向けにネイティブアプリケーションのようなUXを提供しようというも。去年の「Chrome Dev Summit」のキーノートで発表され話題になったものだ。今年の４月に行われた「Google Developers Summit Tokyo 2016」でも2日のテーマになっていたくらい力を入れている。

Progressive Web Appsに求められる体験をまとめると次の様なもの

• ネイティブアプリケーションのようなUX
  • オフラインサポート: Service Worker
  • プッシュ通知: Web Notifications/Push API
  • ホームスクリーンにアイコンの追加: Web App Manifest
  • バックグラウンド: Service Worker
  • 高速でなめらかなインターフェース: CSS3 Animation

Service Workerは、JavaScriptで実装されているローカルのプロキシ、あるいはApplication Cacheの改良版として利用できる。 いままで Web ブラウザーからサーバーにコンテンツをリクエストする場合、サーバーになげてそれを返していたのが、その間にカスタマイズ可能な Service Worker というのが入って バックグラウンドで動いているので、タブを閉じてもブラウザを終了しても動作しているので、プッシュ通知もうけとれるとこと。httpsでしか動作しない。

Progressive Web Appsを実現する技術のサポート状況は

WebAssenbly

WebAssenblyは、コンパイル済みのバイナリをWebブラウザ上で直接動作させる仕組で、Microsoft、Google、Mozilla、Webkitプロジェクトのメンバーで共同開発されていて足並みが揃っている。

JavaScriptよりもポータブルでロード時間や実行に対するパフォーマンスに優れたアプリケーションを作ることが可能だ。asm.jsの次のステップとしている。

2016/3/14〜16の間にMicrosoft、Google、Mozillaの3社が3DゲームAngry botでの検証結果を各ブログで公開している。

WebAssemblyの実装状況は

ハイブリッドアプリケーションとしての利用

Webアプリケーションが苦手とするところは

• ストアのエコシステムを利用しない
• Webブラウザからはどうしてもアクセスできないハードウェアリソース

そしてこれらの Web アプリケーションのは、ハイブリットアプリとしてパッケージすることにより、ターゲットとなるプラットフォームのリソースや、ブラウザーからはアクセスできないハードウェアの機能を使用できるようになる。 また、アプリストアのエコシステムを利用することができる。

Webフロントエンドの開発リソース

インタラクティブなコンテンツを作ることができるようになったので、開発は非常に大変なものになった。

• JavaScript
  • ライブラリ
  • フレームワーク
  • エンジンテンプレート
  • altJS
• CSS
  • フレームワーク
  • プリプロセッサー
• HTML
  • 軽量マークアップ
• パッケージマネージャ
• タスクランナー
• モジュール管理

Richになったことで多くのライブラリが提供された結果「Chaos」になったのか？と思いがち。そして、ライブラリ/フレームワークの選定として考える必要がある。

• ブラウザサポート
• ベンダーサポート
• 情報
  • ドキュメント
  • 書籍類
• 学習コスト
• 開発生産性
• 機能範囲
• ロックイン
• 運用コスト

特にこの中のロックインですが、ロックインは決して悪いものではなく、優秀なベンダーと一緒になってやっていくこと、コミュニティの力を借りることでむしろ良い状況も作れる。運用コストに関しては、便利なんだけどお金がかかるというものについては考えもの。

標準技術は不変

結局、Webブラウザで動作するのは、HTML、CSS、JavaScriptであり、ブラウザがサポートしていない機能は動かない。技術はあくまでも「手段」でり、そうした技術に対する勉強は大事だが、手段であって目的ではない。目的は、ユーザに対して良いプロダクトを提供すること。たとえば、YouTubeはFlashで作られていたが、HTML5に変わったことに気づいた人はいない、そういうものが良い。

そして、WebはApplicationのプラットフォームになる。どんどん低レベルなAPIを実装することになる。結果、デスクトップと同じ様なアプリケーションを作っていける。こうした変貌は「変化」ではなく「拡張」である。

編集長の白石さんに続き、エキスパートの佐川がde:codeをレポート。

「すべての人の可能性を拡げるモバイルファースト、クラウドファーストの世界」をテーマに行われたde:code基調講演は、静なる改革者 米国本社CEOのサティア ナデラ(Satya Nadella)氏の素晴らしい基調講演の後、スティーブングッゲンハイマー(Steven Guggenheimer)氏が具体的な事例とともに紹介した。 de:codeは5/24-25の2日プリンスパークタワー東京で開催された。

de:code2016では、IT技術者の多くが、昨年から始まったMicrosoftの変革を疑わなくなり、更に変貌するMicrosoftのすべてをキャッチアップできる。ただ残念なことにコンテンツが多すぎて全てを見て回ることができない！分身の術が欲しくなるほど興味深いセッションが目白押しです。それをMicrosoftも理解しているのか「de:code 2016の歩き方」もあり、すべてのIT技術者が戸惑うことなく適したコンテンツを見られるよう工夫がされています。

Microsoftが示すオープンイノベーション

初めに サティア ナデラ氏 が開発者やインフラ エンジニアの創造力を最大限に活かす方法について、世界に大きな影響力を与える日本国内の事例を交えて、そのソリューションの紹介がありました。米国本社VP(Vice President)スティーブングッゲンハイマー(Steven Guggenheimer)をはじめ、日本マイクロソフトの統括本部長 伊藤かつら氏、最高技術責任者の榊原彰氏が登壇し、オープンソース コミュニティやパートナーエコシステム、そして経済成長の機会を確実にとらえる最新のプラットフォーム イノベーションが紹介され、日本市場でこれらがどのようにビジネスやエンジニアの変革をMicrosoftとして手助けできるのかを、豊富なデモを交えて解説してくれた。

デベロッパーは何ができるのか

Microsoftがデベロッパーに対して、どういった活動をしているのかを説明してくれた。

1. Microsoftはコミュニティとデベロッパーとどういうことをしているか
2. Microsoftは何を作って、どういう需要に対応しているのか
3. テクノロジーを使って個人として何ができるのか

Microsoftは、何年も前から、モバイルファーストについて取り組んできているという話があった。そして、古い時代からデベロッパーとはビジネスを進めてきたか、今後、Microsoftはどう進めていくのか、その答えがオープンプラットフォームにあるようだ。 何を作って、どういう需要があるのかを常に考え、デベロッパーのために様々な環境を作ってきたというMicrosoftの姿勢がここにある。

プラットフォームカンパニーとしてのMicrosoft

今とこれからのMicrosoftは次のようなポジショニングを行っている。つまり、Microsoftはプラットフォームカンパニーとなった。がしかし、パーソナルコンピューティングとしてWindows10というのもまだ推し進めていく。

ここ３年間の進化として、IoT、タブレット、テレビ、ホロレンズなどバラバラで提供してきた技術が今集約され、そしてWindows10では、一気に全てを集約し、その集約できるものがWindows10であるというように考えていて、今では、すべてのデバイスを横展開できるようになったそうだ。しかし当然難しいところもあり、それぞれのデバイスに対するカスタマイズは必要ではあると言う。だがだが！中心部分はひとつのコードで動いていて、これは本当に素晴らしいことで、Windows PCを使って開発すれば、.NetやC#によりどんなプラットフォームでも動くようになるということを意味し、Microsoft上でEcosystemを構築しているように思える。

Windows10の新しい3つの機能デモ

ペン、ペンタブレットとして利用したWindows10はインクワークスペースを持っている。このインクワークスペースはペンで使える機能が充実している。例えば、付箋、スケッチパット、新しくインク用に作られた、定規もあり様々な機能が充実している。そして、これら機能は、デベロッパーが作ったアプリケーションにインクの機能を追加することができる。

Windows10ではbashコマンドが利用できる。UbuntuのバイナリをインストールしているのでLinux系のコマンドがほとんど利用可能となりvimやemacsを当然利用することができる。XWindwの機能も動くし、apt-getのコマンドなど我々が通常MACで利用しているコマンドが何のわだかまりもなく動くのは素晴らしいことだ。

ディスクトップアプリケーションをパッケージングしウィンドウズストアにアップすることができる。今回デモでは秀丸をパッケージングしローカルPCにインストールをした。これによりセキュアな形でインストール、実行できる。

UWPのアプリケーションを紹介

具体的には、ブリジストンが作っているタイヤの検査アプリケーションのデモを行っていた。

Xamarinを使って作られたアプリケーションで、日々複雑な仕事を様々なデバイスを使って業務を行っている。特徴は

• 音声により画面を切り替える
• 音声により測定（検査）をこなう
• 項目への入力も音声

XamarinによりiOA、Androidも作成可能になる。MACでは通常XCodeが必要になるが、Windowsではエミュレーションがあるので実行確認でき、Mac Bookではできないタッチ確認ができるのも特徴のひとつ

Officeというのは仕事の最前線にポジショニングされていたが、様々な接続をOfficeがサポートしています。OfficeがAzureのデータを出力することで、またはそれ以外のもののインターフェースになりOfficeがフロントエンドとしての役割を担う。アプリケーションと一緒に、スカイプを使うことも可能です。言い換えると、Officeはビジネルの共通な言語になった。

Wordクラウドによるビジュアリゼーション

文字を値で表現するWordクラウドによるビジュアリゼーションに関するデモンストレーションが行われた。

まず、Webエンジニアには馴染みのあるYEOMANを使ってジェネレートを利用してテンプレートを作成した。テンプレートにあるmanifestファイルを作成しホスティングするURLを定義する。

重要なパッケージは

• microsoft.office.js
• d3.js

ローカル上で作成したものがクラウド上のExcelに登録されビジュアリゼーションとして表現することが可能となる。ここで利用されているようなアドインはストアの中で多く展開されグラフや図などもストアに存在する。

DMM.makeのデモ

クラウド上にあるメールやデータを集めることができる

ロボット（ペッパー）のセールス・デモ

ペッパーを通し年齢、性別などを判断し的確な製品をセールスすることが可能となる。つまり、ロボットを利用し、マシンラーニングをベースにして、誰がどういう人なのかを判断することが可能となる。

クラウド

事業のライフサイクルはそれぞれ異なるがMicrosoftは’Platform as a Service’としてクラウド事業をしている。様々なところでAzureが提供できるが、まだクラウドかしていないものがある。Microsoft Cloudの特徴は

1. ハイパースケール
2. ハイブリット
3. エンタープライズカスタマー

ハイパースケールとは、世界全体で使え世界中にある。キャパシティもAmazone,Googleを合わせてもより大きい。つまりアウトソースにかかるコストが安いことを意味している。

10年以上クラウドサービスを作っているMicrosoftのハイブリットの意味するところは、クラウドに置くもの、ファイアオールに置くものをビジネスの利用局面で考える必要がありAzureスタックを柔軟に利用できることがあげられる。 Microsoftは、サポート、サービス、エバンジェリストを通じて、エンタープライズカスタマーをクラウドの利用をサポートしていく。多くの利用者がAzureに移行して行っている。

キャプションボットAPIのデモ: 機械学習、人工知能

機械学習、人口知能を通じて、より人間味のあるアプリケーションを作ることができる。

キャプションボットAPIを使ったデモが３つ行われた。写真は、プロ野球選手でピッチャーのものを利用しキャプションボットでどういう回答があるか。

人間が見れば、野球選手、投球中であることがわかるが、キャプションボットでもこれを正しく判断することができる。もっと複雑な写真のデモ。これも完璧な回答が得られた。写真の構図は、丘の上でバイオリンを弾く女性、牛も二匹いた。

さて、次のデモ。ホテルに行くと鍵をなくしたらどうなるか、マネージャが鍵を盗んだらどうなるかということを想定して欲しい。この時に生体情報を使って管理したらどうなるかというデモンストレーションを行った。

シナリオは次の通りで制度の高い認証が出来ていた。

1. Windows10を利用する
2. Face APIを使って承認済みのものを使う
3. ドアの前に立つ
4. 承認されてない人はドアを開けることができない
5. 承認済みであればドアの鍵が開く

Microsoftのオープンマインド

この基調講演を通じて感じたのは、Microsoftは今まで我々が知っているMicrosoftでは無くまるで別会社のような存在になったということかも知れない。昨年のde:codeでもこの「変わった」感は半端なかったが、いまはWindows上でbashが動き、VSCodeのようにオープン化し新しいデバイスへのチャレンジがまだまだ確信的に進んでいくのだろう。

バージョン4の変更内容はGitHub上のissueで確認することができます。この中で筆者が注目している事項は

• LESSからSASSへの変更
• アイコン（グラフィックアイコン）の削除
• IE8のサポート終了とjQuery1系からjQuery2系へ
• pxからemへの変更
• グリッドシステムに、さらに大きなブレイクポイントを追加
• ボタンのカラー指定にClass属性「default」がなくなり「secondary」を指定するようになった
• Class属性「display-*」でフォントサイズを指定可能に
• ECMAScript2015(babel)の採用
• Angularのui.bootstrapはどうなる？

現段階ではバージョン4はアルファ版ではありますが、先取りして早速レビューします。

LESSからSASS

Twitter Bootstrapはバージョン3ではLESSを用いて開発を行っていましたが、SASS版Bootstrapもあり、LESS版/SASS版の両方メンテナンスが行われていました。バージョン4からはSASSを採用することになりました。

開発者にとってこれは大きな変更です。例えば、bowerを使ってTwitter Bootstrapを利用する場合、LESS版では

$ bower install bootstrap

SASS版を利用する場合は

$ bower install bootstrap-sass-official

と、LESS版を利用するかSASS版を利用するかで呼び出すパッケージが分かれ、しかもgruntタスクやgulpタスク等のコンフィグレーションを記載する際に、それぞれの異なる記載を行っていました。こうしたことが一本化されたことは、冗長的な記述をスッキリさせてくれます。

YEOMANジェネレータにgenerator-webappというWeb開発のベーシックなジェネレータがありますが、CSS版/SASS版の切り替えのために、いたるところの分岐が書かれています。

ちなみに、bowerを使ったアルファ版のインストールは、明示的にバージョンを指定する必要があります。バージョンを指定しない場合は3系がダウンロードされます。

$ bower install bootstrap#4.0.0-alpha

アイコン（グラフィックアイコン）の削除

Twitter Bootstrapと言えば、豊富な人気のあったGlyphiconsですが、バージョン4では削除されています。

現段階では極わずかにGlyphiconsが残されているだけになっていて、入力時の警告等を表示させているだけになっています。

削除されたグラフィックアイコンですが、現状ではTwitter Bootstrapの管理外で定義されているような記述もありません。もしグラフィックアイコンを利用したい場合は、別途どこかからお気に入りグラフィックアイコンを利用する必要があります。

IE8のサポート終了とjQuery1系からjQuery2系へ

Internet Explorer8とiOS6へのサポートが終了します。Twitter BootstrapがjQueryのバージョンを1系から2系への利用変更に伴いInternet Explorer8のサポートも打ち切られました。IE8を利用する必要がある場合にはバージョン3を利用します。

さようならIE8…

pxからemへの変更

フォントサイズ等の指定がpxからem(およびCSS3で導入されたrem)に変更されました。pxはピクセル単位の指定で、環境によって変化しない絶対単位です。emは文字の高さを基準にした単位で1emは1文字を表します。特にremはCSS3で新しく定義されたroot emでroot要素（html要素）のフォントサイズを継承します。

pxの場合、ブラウザのフォントサイズを変更しても文字の大きさが変わりませんが、emではフォントサイズの大きさに合わせ表示されるフォントサイズも変わります。chromeの場合は「chrome://settings/」でフォントサイズを変更した場合に違いが確認できます。

乱暴な言い方ですが、ユーザの好みのフォントサイズに対応するというのはある意味よりレスポンシブになったと言えるのではと思います。pxが良いのかemが良いのか議論としては様々だとは思いますが、Twitter Bootstrapではemを利用します。

グリッドシステムに、さらに大きなブレイクポイントを追加

Bootstrap3超速レビュー！刷新されたグリッドシステムを理解しよう！でも記述されているグリッドシステムですが、4つ定義されていたブレークポイントがバージョン4ではブレークポイントが5つになり「Extra large」が追加されました。

具体的に、バージョン3では

バージョン4では

ブレークポイントにより大きなExtra largeが定義されましたが、実際には小さい画面に対するブレークポイントが追加されています。

比較するとわかりますが

※ 1emを16pxとした場合

visible-*(-block)というクラス属性ですが、バージョン４では実装されていません。これは特定のサイズのときに表示させるのもで、例えば

✔ Visible on small

としたときに「smサイズ」で表示されます。.visible-*(-block)が削除され変わりに.hidden-*-up or .hidden-*-down を利用する方向です。

ボタンのカラー指定にClass属性「default」がなくなり「secondary」を指定するようになった

btn-*では、defaultがなくなりsecondaryが新たに追加されました。defaultと同様の色を指定する場合はsecondaryを指定する必要があります。btn-primaryのバックグラウンドカラーも若干明るめに定義されています。

バージョン3では

バージョン4では

現在バージョン3とバージョン4で定義されている値を比較すると次の通りです：

こうしたカラーリングですが、ラベルやアラートに関しては今のところ変更がありません、ボタンのみ変更されています。

Class属性「display-*」でフォントサイズを指定可能に

小さい部分ですが、フォントサイズを指定するクラス属性にdisplay-*が追加されました。コメントには次のような記載があります:

> 見出し要素(h1,h2,…h6)はページのコンテンツのボディで最適に動作するように設計されています。より目立つような見出しが必要な場合は、より大きいスタイルを使用することを検討してください。

具体的には

として定義されています。しかし、CSSのfont-weightの定義がh1では500であるのに対し、display-*では300ですので若干ほっそりとした表示になります。

ECMAScript2015(Babel)の採用

Twitter BootstrapのJavaScript開発にはBabelが採用されています。Babelは、TypeScriptを使ってECMAScript 2015時代のJavaScriptを先取りしよう！での記載もあるように、今年6月に公式に次のECMAScriptとして仕様が公開されたECMAScript2015(今まではECMAScript6と呼ばれていました)の文法で記載することが出来ます。参考までに、ECMAScriptはECMA Internationalが策定した仕様で、この仕様に基いて実装されたものがJavaScriptです。

ECMAScript2015の特徴をいくつか上げると次の通りです。詳しくはこちらを参照ください。

• Arrows
• Classes
• Let + Const
• Iterators + For..Of
• Generators
• Modules and Module Loaders
• Map + Set + WeakMap + WeakSet
• Proxies
• Promises

Angularのui.bootstrapはどうなる？

AngularにはBootstrap Componentsをベースにしたui.bootstrapがあります。Angularを使って日頃開発を行っている方には、ui.bootstrapの動向も気になるところではないかと思います。というのも私は、ui.bootstrapのディレクティブ実装が非常に良いと思っているので、積極的に利用しています。

ui.bootstrapの対応に関しては現在issueで話が上がっています。ui.bootstrapはAngular2の対応もありますので、Twitter Bootstrapバージョン4の対応は難しい状況のようです。

まとめ

バージョン3からレスポンシブWebデザインを前提として作られたTwitter Bootstrapですが、バージョン4では現在のモバイル環境に合わせより強力に洗練されたCSSフレームワークです。

今回のレビューはまだアルファ版のため一部機能が実装されていない部分もありますが正式リリースが楽しみです。

７月4日（土）九州では3回目2年ぶり鹿児島では初となるHTML5カンファレンスが「国立大学法人鹿児島大学 郡元キャンパス共通教育棟2号館1F」で開催されます。IoTをはじめどこにでもある当たり前の技術になり、徐々に浸透してきているHTML5ですが、実際にプロダクトとして利用するにはこれからという状況でもあります。また、「Extensible Web」という考え方や「WebAssembly」からもわかるように、まだまだ発展し続けている技術でもあります。そんな魅力的なHTML5に触れられ、聞け、近づけることができるカンファレンスです。

見どころ

HTML5というキーワードがだいぶ静かになりましたが、冷静に考えるとHTML5についてどのくらい知見がありますか？意外と知らないことが多いのではないかと思います、しかもまだ発展している。Microsoftの本気モードもMAXになりその動向がきになるところですし、Firefox OSがテレビに搭載されたり、Firefox OS採用の開発ボードOpen Web Boardが存在したりと。Google I/OでもPolymer 1.0が発表されるなどまだまだ目が話せない状況です。そういった15セッションの中からあえて4つセッションを上げろと難題を出されたら、次のものを涙ながらに注目のセッションとして選びたいと思います。

注目のセッション：

Windows 10 に搭載される Web ブラウザーについて
– 日本マイクロソフト株式会社 物江修 氏

“There’s an element for that!!” Now, get ready for Polymer 1.0!!!
– NTTコミュニケーションズ 小松健作 氏

Web Audio API、 Web MIDI API を使ったWebサウンドプログラミング
– ヤマハ株式会社 河合良哉 氏

Firefox エコシステム ー Mozilla が創る Web of Things 時代の技術とプラットフォーム
– Mozilla Japan 浅井智也 氏

セッション以外にも展示ルームがあり実体験としてHTML5に触れることもできます。体感できるHTML5をお楽しみください。詳しいご案内はHTML5カンファレンス鹿児島の特設サイトがありますので、そちらをご参考にしていただきたいと思います。

http://kagoshima.html5j.org/html5conference.2015/

歩き方

HTML5カンファレンス鹿児島ですがオープニング/クローズを含む全17セッションから成り立っています。デザイナーからWebエンジニア、エンタープライズ技術者まで幅広くターゲットにしたイベントですので聞くものを選ぶのも難しいところです。そんな皆様に筆者が当日の聴講すべきセミナーをプランニングしてみました。

トップエンジニア向け

トップエンジニアであるあなた。そうです、やはり最先端技術に触れておくべきところだと思います。html5j代表でもある吉川徹氏の「いまさら聞けないHTML5概要」でまずはHTML5に脳みそを浸し、Microsoft Edge、Polymer、Web MIDI、Forfox OSとエッジな話に舌鼓されてはいかがでしょうか？

1. ルームA: いまさら聞けないHTML5概要
2. ルームB: Windows 10 に搭載される Web ブラウザーについて
3. ルームA: “There’s an element for that!!” Now, get ready for Polymer 1.0!!!
4. ルームB: Web Audio API、 Web MIDI API を使ったWebサウンドプログラミング
5. ルームA: Firefox エコシステム ー Mozilla が創る Web of Things 時代の技術とプラットフォーム

エンタープライズ向け

エンタープライズに所属しているみなさんは実用的なシステムを作る上でこれから何をすべきかを考える必要があります。WoTやCordova、Polymerなどは技術として知っておくべきところだと考えます。外してはならないのがMicrosoft Edge。そうです、エンタープライズには欠かせないMicrosoft社のブラウザーのお話です。好き嫌い関係なく必須項目のひとつです。

1. ルームB: はじめてのWeb of Things
2. ルームB: Windows 10 に搭載される Web ブラウザーについて
3. ルームA: “There’s an element for that!!” Now, get ready for Polymer 1.0!!!
4. ルームA: Cordova開発者が知っておきたいレンダリングエンジンの話
5. ルームA: Firefox エコシステム ー Mozilla が創る Web of Things 時代の技術とプラットフォーム

デザイナー向け

デザイナーはHTML5の基本事項を再確認し、その後、トップデザイナー秋葉秀樹氏の「ぼっけもんデザイナーへの道」を聞くべきです。セッション案内でもありますが、「『ぼっけもん』とはチャレンジ精神に溢れ、勇気のある人の意味を持つ鹿児島弁です」ということですので、デザイナーとしての考え方を身につられるチャンスだと思います。その後WebRTCの実例や、今後デザイナーとしても必要になるだろう「音」に対するWebの取り組み、デザイン技術のイロハを聞かれてはどうかと思います。

1. ルームA: いまさら聞けないHTML5概要
2. ルームA: ぼっけもんデザイナーへの道
3. ルームC: Webと電話を繋げよう！Twilioを使った簡単アプリの作り方 & オンラインコミュニケーションを支えるHTML5
4. ルームB: Web Audio API、 Web MIDI API を使ったWebサウンドプログラミング
5. ルームB: 入門HTML5/CSS3

初心者向け

あまりHTML5はよくわからないという初心者には、HTML5の全容を確認し、HTML5の実例を聞くというのがおすすめです。きっとHTML5の魅力に触れることができるのではないかと考えます。

1. ルームA: いまさら聞けないHTML5概要
2. ルームC: 協働現場でのHTML5
3. ルームB: はじめてのWebRTC/ORTC
4. ルームC: ファブ時代のHTML5。IoTとWoT、あとロボット。
5. ルームC: Bootstrap超入門 & フロントエンドエンジニア1年生が語る『画面設計とCSS設計のポイント』

とは言っても、なかなか選ぶのが難しいのではないでしょうか。この原稿を書きつつ、これだけのセッションが並ぶと迷うのも当たり前ではないかと思っています。是非HTML5カンファレンス鹿児島のサイトを見ていただき、十分迷ってもらえたら幸いです。

開催日時・場所

• 開催日時：2015年7月4日（土）
• 開催場所：国立大学法人鹿児島大学 郡元キャンパス共通教育棟2号館1F
• 事前登録はこちらからどうぞ！
• 入場料：無料

本イベントは懇親会も用意されていて、参加費無料です。講師陣とコミュニケーションを取るチャンスでもありますのでご参加ください（噂ですが美味しい焼酎が無料で提供されるかもしれません）。それでは当日鹿児島でお会いしましょう！

この記事は、Angularをテーマとした日本初のカンファレンス 「ng-japan」のイベントレポート（第6回目）です。ng-japan特集最後は懇親会でのQ&Aの模様をレポートします。

AngularカンファレンスQ&A

Q1. Angular 2を開発するに当たって、React.jsのアーキテクチャや考え方から影響を受けていますか？

一定の影響はありました。よく聞かれる質問としては「Virtual DOMについて」ですが、我々はこのVirtual DOMがパフォーマンスを上げるために必ずしも必要となるものではないと考えています。それよりも「unidirectional data flow」という考え方のほうが役に立つのではないかと考えています。

プレゼンテーションの中でも「Immutable Infrastructure」については触れましたが、これについてはReactのチームともディスカッションを始めているところ。この分野についてはReactチームとAngularチームのコラボで行っていけるのではないかと考えています。

Q2. GoogleのプロダクトでAngularはどのぐらい利用されていますか？

Googleプロダクトの約2,000のアプリケーションで、Angularを使っています。特にGoogleが提供するクラウドでは、ほとんどのUIがAngularで書かれています。AngularチームというのはGoogle内でもいろいろな組織が存在していますが、その中に広告のグループであるAdsのチームがあり、ここでもAngularが使われています。その他にもGoogle内部だけで使われるような、内部プロセス用のアプリケーションについてもAngularが利用されています。

すべてのアプリケーションがAngular 2に移行するとは考えていませんが、Angular 2を使った方が簡単ものもありAngular 2を使う価値があるものについては移行をします。

Q3. Angular 1系のサポートはいつまで行っていきますか？

一時期Angular 1のサポートはいつまでで、Angular 2はいつからといった区切りを設定する予定でした。例えば、Angular 1のサポートを2016年末で終わりますと言って、Angular 2が2016年末に出てきたら、まったく移行の期間がなくなります。プレゼンテーションでも様々なお話をしたようないろいろなシグナルを見て今開発をしている人は、自分の位置がどのあたりにいて、今後どうなるのかを把握する必要があります。そして移行期間が作れるように、段階的に終了していくというのが正しい方向ではないかと考えています。

そして、GoogleだけがAngularに投資を行っている企業ではなく、Googleの外にもコアなチームメンバーがいて、彼らは彼らでAngularの開発にあたっています。なので我々としてもサポートをしっかりしていくということが重要でありオープンソースにとっても重要だと考えています。とは言うもののAngular 2を魅力的なものにし、しかもマイグレーションし易いものにし、誰もがAngular 2に移行した利用したいといった素晴らしいものに創りあげたいと考えています。

Q4. Angular 2の新しい機能に対してServiceとかFilterとか変な名前を付けてないか確認したい

まだ名前の付け方が得意じゃないけど、なるべく混乱のないような名前をつけていきます。でも、もう既に新しいRouterに対して、「NewRouter」という名前を付けてしまってゴメンナサイ。

Q5. Angularで検討されている機能で「Component Helper」というのがあるようですが、Angular1.4でリリースされる予定はありますか？

他のコンポーネントとの兼ね合い、Angular 2の機能の一部をAngular1.4に入れていることもあり、もしかするとAngular1.5でリリースされるかもしれません。十分な時間をかけて検討していきたいと考えています。

このAPIというのはベストプラクティスとなっていくものです。「Component Helper」の仕様を一旦決めてしまうと後になって開発者が変えていくことは大変な労力が必要になるため、じっくり考える時間を設ける。「Component Helper」はAngular1.5に入れることを検討しています。

Q6. New RouterでControllerを指定するようになっていますが、Component Directiveのようなものを指定するようにはならないでしょうか？

我々がしようとしていることは、まさにそういったComponentを指定するということです。しかし、まだAngular 1系ではComponentを使うことはできない。いまはどうすれば、Angular 1とAngular 2とで整合性が保たれるか、Componentを導入できるかを検討しています。

Q7. Angular 2でEvent Emitterの仕組みは導入されますか？

Event Emitterの機能は、Angular 2ではありません。しかし、それに変わる別のやり方が提供されます。Angular 2では各パーツ間のコミュニケーションのやり方が変わっていきます。

その変わりに使えるものが2種類あります。

• DOM Event
• サードパティ・ライブラリ

この変更に対してどこにアドバンテージがあるのかというと、いろいろなケースを考えると今のAngularイベントを使っていった場合、さまざまなところでタイポが発生し、イベントの名前が間違ってしまうことがあります。するとイベント名が有効でなく一体何が起こったのが開発者がわからないという状況になりますので、問題を解決するために「Event Injection」を入れました。そうすることでダイレクトにイベントが伝わるようになります。

最後に（編集後記）

ng-japanの様子を余すことなく書き下ろしましたが、いかがだったでしょうか？

Angular1.4の内容やNewRouterの機能、Angular 2に関すること、Angular 1からAngular 2へのマイグレーションなど盛りだくさんの内容だったと思います。Angularはあまり大規模なアプリケーションを作るのには不適という話もありますが、Angularチームが目指すところは規模に関わらず作りやすく、よりメンテナンスビリティの良いフレームワークを目指しているのではないかと思います。

AngularはGoogle社の閉じた世界観で作られているのではなく、Google社外のコミッターとの連携やReactチームとのコラボレーションもあり健全なオープンソースの道を歩んでいるのではないかと考えてます。しかも我々がAngularと関わりたいと思えばGitHubでissueを書くこともpull requestも送ることもできます。より関わることで、Angularが我々開発者にとって良いものになるのではと思います。

そのための一歩としてまずは、Angularを「触ってみる」ということも重要だと思います。「AngularJS Japan User Group」では各地で初心者向けハンズオンや、中上級者向けのハッカソン、ナイトセミナーも実施しておりますので、機会がありましたら足を運んでいただけたら幸いです。

最後に多くの方に来場いただき、感謝するとともに、多くのスポンサー様にご協力いただききました。この場をお借りし御礼申し上げます。

セッション動画

当日のセッションはYouTubeで公開されています。是非ご覧ください！