この記事は、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で公開されています。是非ご覧ください！

この記事は、Angularをテーマとした日本初のカンファレンス 「ng-japan」のイベントレポート（第5回目）です。

はじめに

Angular 2の発表があり、大きく様変わりするのではないかと懸念され、話題にもなりました。そして、AtScriptからTypeScriptへの変更など、話題にことかかないAngular 2ですが、彼らがなぜ、そのような変更を行っているのかが理解できるセッションとなりました。

Angular 2 – Igor Minar

Angularは、私たち開発者のWebアプリ開発の手法を変え、生産性を向上してくれました。今度は我々のニーズに合わせて、Angularが変化をする番です。このセッションでは、何が変わり、なぜそのような変更が必要なのかをお話します。

まずは、Angular 2の3つのポイントについて。

• なぜAngular 2を作ることにしたのか
• Angular 2はどういうものにあるのか
• いつ出てくるか

なぜAngular 2を作ることにしたのか

5年前にAngular 1の開発を始めたわけですが、これはWebアプリケーションの生産制を上げるために始めました。自分だちだけで閉鎖的に作るのではなく、様々な人にも見てもらいので、オープンソースにしました。その結果、多くの人に気に入ってもらえたと思います。そして気に入ったということだけではなく、実際に使い、コントリビューションしてくれました。

実際、世の中にどのくらいAngularが使われているかはよくわかりませんが、類推できる統計値はいくつかあります。例えば、今回のカンファレンスがほぼ満席になっているということが挙げられますね。とても嬉しいことです。そして毎月100万の開発者が、Angularについて学ぼうとしサイトにやってきます。

Googleの外の世界で、Angularがどう使われているのか計り知ることは難しいですが、Googleの中ではヘビーに使っています。現在Googleの中では2,000のアプリケーションが構築されています。このような数字が何をもの語っているかというと、多くの人がAngularを信頼されているということです。しかし、信頼されているということは、責任が増すとも言えます。

5年間で徐々にAngularを育ててきた中で、次の段階ではもっとよりよいものにしたいと考え、Angular 2を作ることにしました。Angular 2がどういうものになるのかが気になるところだと思いますし、指針は重要かと思います。

Angularを、よりシンプルな一貫性のあるものにしたいと考えています。なぜそれが実現できたかというと、どう使われて、どう開発されてきたかわかっているので、どう最適化すればいいのかも見えてきたからです。そしてAngularを気にいっている人からは、とても柔軟性があるからと言われています。こうした柔軟性も、Angular 2に盛り込みたいと考えています。

私たちがAngular 1で経験できていなかった部分として、パフォーマンスが挙げられます。より大きなプロジェクトを行っているうちに、パフォーマンスが重要であることに気づきました。そして、最後の要素が生産性の向上になりますが、Angular 2でも生産性の向上を行っていきます。

Angular 1とAngular 2は似たようなものにあるか？

APIとシンタックスは異なる部分は多くありますが、Angularの中に入れば基本的な概念は似たようなものが多くあります。Angular 1で好んで使ってくれたData Bindingなどは、Angular 2でも利用することができます。

Angular 2は、より使い勝手がよくシンプルにし、よりパワフルにしました。そして新しい強力な機能を追加しました。

• Viewports
• New languages
• Web Components
• New template syntax
• Unidirectional data flow
• Ultra-fast change detection

Productivity

Angular 2の中で盛り込んでいくテーマについてもいくつかありますが、その中で2つ話をします。

• 生産性向上
• パフォーマンス向上

Angular 2においては、Angular 1のさらにその先をいくことを考え、それがtoolsを活用することができるということです。いま提案された、開発が終わってない、ブラウザでも実装されていないものに対しても、コードを書くことができるということです。そして開発者にとって役に立つこととして、タイプミスを防ぐことをしています。この新しいテンプレートシステムによってエラーやタイプミスがないかを抽出することができます。TypeScriptのチームとパートナーシップを組むことでそれを進めることができました。

TypeScriptを利用する重要なことの一つは、ECMAScript 6でも使うことができるようになることです。つまりTypeScriptをオプションとして、使うことができます。異なるチームに分散した大きなプロジェクトのときに、コントラクトを表すことができます。

もう一つTypeScript 1.5に含まれることにアノテーションがあります。アノテーションのお陰でコードを書く量を減らすことができます。これらの機能を標準化しJavaScriptに入れていくことを考えています。ChromeのV8チームやTypeScriptのチーム、その他のチームと連携しています。

将来的にはこれら機能がJavaScriptの中に含まれていくと思います。そういうことになると将来的には変換ということが必要ではなくなります。もちろんこれらは長く時間がかかるものですが、時間をかけてやっていくことには意義があると思います。

Angular 2はTypeScriptが使われていますが、一般の開発者がTypeScriptを使わないといけないのかという疑問があるかと思います。答えとしては自由に選択することができます。みなさんが自由にどの言語を使って、Angularアプリケーションを書くか、ECMAScript 5やECMAScript 6などどれを使ってもいいです。ただこうしたアプリケーションのツールを使いたいときは、TypeScriptを使うのがよいと思います。

標準化

言語の拡張と標準の話をしてきました。しかし、このAngular 2の大きなテーマとしては、標準化が好きだということがあります。Angular 1を作り始めた頃は、まだ使えないようなAPIを持ってきて、Angular 2の中に盛り込みました。よい例としては、Shadow DOM、Templateエレメントなどを使っています。

パフォーマンス

Angular 1.3のときに、パフォーマンスの改善を試みたというのがわかると思います。パフォーマンスを語るときに、難しいのは速いというのはどういうことなのかという定義です。この答えとして、ツールを作りました。パフォーマンスを信頼性の高いものにするためBenchmarksというのを作りました。

一連のベンチマークテストとして、世の中でやっているいろいろなベンチマークを行いました。その一つがDeep Treeです。Deep Treeでは深く複雑にネスティングしているものをベンチマークすることができます。結果的にAngularでは複雑な画面に対して、どのくらいパフォーマンスがあるのかを知ることができます。

Angularが速いのか遅いのかを知るために、ベースマークを作りました。それにはJavaScriptをAngularを使わずに作り、様々な工夫してベースマークを作りました。ポイントは、とにかく速く走るというプログラムなので通常書くようなロジックではありません。同じベンチマークでAnguler 1を作りました。

このベンチマークでは、ベースラインと比べると8倍時間がかかります。しかし、他に出ているソリューションとでは、ほとんど変わらないものになっています。もっと改善できるというはずだということで、Angular 2で試した結果としては3倍時間になりました、もっと速くすることができると考え、結果としては改善することができました。

Angualar 2の中にはView Cacheがあり、DOMエレメントを再利用することができ、この機能を使うことでパフォーマンスを上げていくことができます。

特にナビゲーションの中で2つのViewを行ったり来たりする場合、高い効果がありました。もちろんパフォーマンスについて注目しましたが、ガベージコレクションも気になるところです。

アプリケーションの様々な操作によってメモリーに関する事象が異なりますが、モバイル・アプリケーションのようなメモリーに制限のあるものについてはいろいろと効果することがあります。パフォーマンスというのは速度だけが重要なのではなく様々な要素で出てきます。一つパフォーマンスの中で注目しているのが、変更検知を取り入れた時に、どのくらい影響があるのかに興味がありました。

幸いなことに、Angular 2では柔軟な変更検知ができます。変更不可能なデータ構造がエキサイティングなのはなぜかというと、絶対に変わることがないとわかっていますので、変更検知の中で活用していくことになります。いくつかのシナリをの中で、使っていくことができます。バーチャルスクローリングが、それにあたります。

Angular 1の場合には変更検知を行っていくための時間というのは、データのサイズに比例して増えていきました。Angular 2の場合には改善されほとんど気にする必要のないくらいの速度になります。

Angular 2

Angular 2がどういうものかご紹介します

いつAngular 2が使えるか

いまAngular 2はアルファバージョンになっていますので、大きな変更はあります。なぜ、安定してないものを紹介しているかというと、我々がどのようなな開発をしているかを示したいからです。オープンソースにし、Angular 2の初期の段階で、様々なフィードバックを受けたいという想いから公開しています。

すべてのコードはgithubに公開していますので、issueやコメントを入れてください。どういうアイデアがこれまでインプリされているかは、ドキュメントを見ていただきたいと思います。

2月にアルファを出したが、3月に行われたng-confでAngular 2のデモを行い、多くの反響をいただきました。正確にいつリリースされるか、日付は発表されてはいませんが、Googleのあるチームは5月には使いはじめ、マイグレーションを行っていきます。そして、このGoogle内部のチームからのフィードバック、コミュニティからのフィードバックでロードマップが決まってきます。

Angular 1を使う人は、angularjs.orgのサイトも使っていると思いますが、Angular 2に特化したサイトも立ち上げました。多くのAngular 2のドキュメントは、angular.ioに掲載されます。

では、Angular 1はどうなるかというと、多くの方がAngular 1を使っていると思いますので、ほとんどの方がAngular 2に移行したというまでは、Angular 1をサポートし残しておく方針です。より移行が簡単になるようAngular 2を開発していく予定です。そのマイグレーションが進む中で1.5や1.6を出していきます。

数週間前のng-confでのビデオがありますので、見ていただけたらと思います。

プレゼンテーション資料

今回取り上げたプレゼンテーションの資料は以下のとおり公開されています。合わせてご覧ください。

セッション動画

当日のセッションはyoutubeで公開されています。逐次通訳付きなので、是非ご覧ください！

この記事は、Angularをテーマとした日本初のカンファレンス 「ng-japan」のイベントレポート（第4回目）です。

はじめに

昨年秋に、Angular 2はAtScriptというaltJSで開発するといったアナウンスがありました。しかし、今年3/5に急遽、Angular 2はTypeScriptで開発するという変更がなされました。このニュースはGoogle社とMicrosoft社が手を結んだということでも大きなニュースになり、今年一番の出来事かもしれません。

そのTypeScriptとカレントバージョンであるAngular 1.3を利用した開発ポイントを、株式会社トップゲートのエンジニアであり、TypeScriptマスターでもある@vvakame氏に講演していただきました。

TypeScript+Angular 1.3 – vvakame

AtScriptからTypeScriptに移行される旨がアナウンスされたため、TypeScript自体の話を少しと、現行のAngular 1.3とTypeScriptを組み合わせて開発する方法についてお話します。

「AtScriptの近況と将来」の話をしようと思いましたが、3月頭に必要なくなったようなのでタイトルを変えました。「TypeScript+Angular 1.3」というタイトルでお話させていただきます。

Angularを取り巻く開発言語

ECMAScriptとは

ECMAScriptに関して整理します。

• JavaScriptの元となる仕様のこと
• DOMの仕様は入っていない
• 最近のブラウザはECMAScript 5をサポート
• そろそろ6の仕様が確定（現在RC2

AtScriptとは

AtScriptとは何だったのかを振り返ってみます。

• AtScript=ES6+A (A=Annotiosion, AnnotationはES6に含まれない)
• Super set of TypeScript

AngularチームがAngular 2を開発するために策定したTypeScriptより、優れているaltJSということでした。

TypeScriptとは

では、TypeScriptの特徴はどういうものかを整理します。

• TypeScriptはJavaScriptを拡張した言語
• 静的型付け
• ECMAScript6規格の文法を取り込み中
• 読みやすい変換後JavaScript
• Java, C#とかにやさしい言語仕様

TypeScriptは、Microsoftが出してきたということで当時注目されました。特徴の一つである静的型付けの特徴をまとめます。

• 静的解析で多くの整合性検証が可能
• 不整合があった場合、コンパイルエラー
• 大規模、大人数になるほど有利
• Java, C#が有名

通常のJavaScriptでは、バグに関して実際に動かしてみて初めて分かりますが、TypeScriptのような静的型付けを用いると、静的解析でより多くの整合性検査が可能です。なるべくコンパイルした段階で、エラーが出力されるところが良い点の一つです。

例えば次の文はエラーになります。

var foo: number="bar";

TypeScriptは、ECMAScript 6のスーパーセットになると考えられています。既存の資産を活用したいという要望も当然あります。そうした要望を満たすため、TypeScriptに様々なJavaScriptライブラリの型を定義した型情報を用意する必要があります。例えば、次のようなものがあります。

• jQuery
• Angular
• mocha
• etc

DefinitelyTyped

型定義ファイルというものがあります。現在は1,000個以上あります。既存JavaScriptに型を後付けというのはわかりづらいとは思います。

Angularの例を見てみます。

declare var angular: angular.IAngularStatic;

// Type definitions for Angular JS 1.3+
// Project: http://angularjs.org/
// Definitions by: Diego Vilar 
// Definitions: https://github.com/borisyankov/DefinitelyTyped


/// 

declare var angular: angular.IAngularStatic;

// Support for painless dependency injection
interface Function {
    $inject?: string[];
}

// Collapse angular into ng
import ng = angular;
// Support AMD require
declare module 'angular' {
    export = angular;
}

///////////////////////////////////////////////////////////////////////////////
// ng module (angular.js)
///////////////////////////////////////////////////////////////////////////////
declare module angular {

    // not directly implemented, but ensures that constructed class implements $get
    interface IServiceProviderClass {
        new (...args: any[]): IServiceProvider;
    }

    interface IServiceProviderFactory {
        (...args: any[]): IServiceProvider;
    }

    // All service providers extend this interface
    interface IServiceProvider {
        $get: any;
    }

実際にこれを使ってコードを見てみます。JavaScriptとあまり変わりがないので読みやすいのではないかと思います。

module App {
	"use strict";

	angular.module(
		"app",
		["ngRoute", "app.hello"],
		($routeProvider: ng.route.IRouteProvider, $locationProvider: ngILocationProvider)=> {
			$routeProvider
				.when("/sample", {
					templateUrl: "/template/sample.html"
				})
				.otherwise({
					templateUrl: "/template/main.html"
				});
			$locationProvider.html5Mode(true);
		}
	)
		.run(($rootScope: ngIRootScopeService, $routeParams: ng.route.IRouteParamsService)=> {
			false;
		})
	;

	angular.module(
		"app.hello",
		[],
		()=> {
			false;
		}
	)
		.service("sampleService", Service.SampleService)
		.controller("SampleTestController", Sample.TestController)
	;

Angular 2とTypeScript

2015年3月5日に、Angular 2はTypeScriptで作ることになるという記事が出てきました。AtScriptからTypeScriptに変えた理由がいくつかあり、AngularチームとTypeScriptチームの調整がうまくいったのではないかと考えられます。

• TypeScriptに必要な機能が入る
• Angularチームが作りたいのは、AtScriptではなくAngular本体である
• TypeScriptのスーパーセットを作るのが困難

TypeScriptのスーパーセットを作るという話でしたが、TypeScript自体の開発スピードがかなり早く、しかもその間にECMAScript 6の仕様も出て、短期間の内にAtScriptを開発するためには、人的にもコスト的にも難しい状況だと考えられます。

話をまとめると、Angularを使うという観点からも、今からTypeScriptを使う必要があると言えます。

TypeScriptのSyntax

TypeScriptの独自Syntaxはあまりなく、JavaScriptとそれほど変わるものではありません。TypeScriptですが、だいたい2日もあれば書けるようになると思われます。

Type Annotations

Type Annotationsを具体的に見てみます。

var str1:string = "string";
var str2:number = "string"; // エラー
var str3 = "string"; // 初期化子から型推論されstringを指定したのと等価
str3 = 1; //エラー

var b: boolean = true;
var n: number = 1;

var a: any = true;
a = 1; // anyは何でもOK

Classes

ECMAScript 6からは、クラスの宣言ができるようになりました。TypeScriptの例を見てみます。

class Hoge {
	name: string;
	
	constructor(name: string) {
		this.name = name;
	}
	
	hello(): string{
		return "Hello, " + this.name;
	}
}

var obj = new Hoge("world");
window.alert(obj.hello());

Interface

TypeScriptで定義したInterfaceは、実行時には消えてしまいます。型だけの定義です。

interface Hoge {
	str: string;
	num: number;
}

var obj: Hoge = {
	str: "string",
	num: 1
};

window.alert(obj.str + obj.num);
window.alert(obj.hello());

Allow Functions

Allow Functionsは、最近話題になっています。メリットとしては、functionというキーワードが必要なくなるところです。これはECMAScript 6でも標準化されますので、TypeScriptを通して今のうちから慣れるのもよいかと思います。

var hello = (word: string) => console.log("Hello, " + word);
hello("TypeScript");

// 返り値の型を明示する
var hello2 = (word: string): void => console.log("Hello, " + word);
// 参考：今まで通りの書き方 1
var hello3 = function (word: string) { console.log("Hello, " + word); };
// 参考：今まで通りの書き方 2
function hello4(word: string) { console.log("Hello, " + word); }

internal modules

今までのJavaScriptでは、モジュールの定義するというのは存在していませんでした。TypeScriptではモジュールが定義されています。今は過渡期でこうした書き方ですが、ECMAScript 6だと書き方があるので、なくなると思われます。

module app {
	export class Sample {
		hello(word = "TypeScript") {
			return `Hello, ${word}`;
		}
	}
}
var obj = new app.Sample();
console.log(obj.hello("AngularJS"));


var app;
(function (app) {
    var Sample = (function () {
        function Sample() {
        }
        Sample.prototype.hello = function (word) {
            if (word === void 0) { word = "TypeScript"; }
            return "Hello, " + word;
        };
        return Sample;
    })();
    app.Sample = Sample;
})(app || (app = {}));
var obj = new app.Sample();
console.log(obj.hello("AngularJS"));

Generics

Genericsは非常に便利です。

class Container {
    constructor(public data: T) { }
}

var a = new Container("str");
var b = new Container(1);

a.data.charAt(0);
b.data.toExponential();

はじめてみよう – Angular-typescript

@vvakameのgithubにあるので是非見ていただき、TypeScriptを始めてもらえたらと思います。

開発する際、利用するツールは次の通りです。

• node.js
• grunt
• bower
• TypeScript ** tslint ** typedoc ** dtsm (tsd)
• LESS
• unit test ** mocha ** power-assert
• karma
• protractor
• その他

Angular 1.3と組み合わせる

あまり考えなくてよく、TypeScriptと重ねることは特別なことはないです。TypeScriptはJavaScriptの延長線上にあり、JavaScriptのベストプラクティスがそのまま利用することができます。

その中で覚えなければならないのは

• 型の名前
• 使いたいメソッド（angularのドキュメントを読むより型定義ファイルを見たほうが早い）
• 使いたいDIオブジェクト名

その中で次のことに注意すれば、問題なく記述することができます。

• tsc –noImplicitAny
• 型注釈を書く

プレゼンテーション資料

今回取り上げたプレゼンテーションの資料は、以下のとおり公開されています。合わせてご覧ください。

セッション動画

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

この記事は、Angularをテーマとした日本初のカンファレンス 「ng-japan」のイベントレポート（第3回目）です。

はじめに

策定されているNew Routerは、Angular 1でもAngular 2でも利用可能で、大規模開発向けでもあるということが言われています。そのNew Routerに関する機能を見ていきたいと思います。このセッションではBrian Ford氏がNew Routerというタイトルで講演を行いました。

Angular 1 におけるNew Routerを使った大規模で維持しやすく、モジュラーなアプリケーションの作り方についてお話します。また、このRouterのAngular 2における挙動についても触れ、スムーズなアップグレードに活かす方法をお知らせします。

New Router – Brian Ford

多くの人がアプリケーションを作ったことがあり、Routingもよく知っていると思いますが、Routingのハイレベルな話をしていきたいと思います。Routingの基本的な考えは、URLとページをマッピングしていくことです。しかし、Angularの中でRoutingといった場合は、コンポーネントに対してマッピングをしていくという意味になります。つまり、URLの一部に対してUIの一部がマッピングされます。

もう一つRoutingの重要な機能として、Deep Linkingがあります。たとえば利用しているアプリケーションがURLを持っていて、それを友人にURLを送ることがあります。あるいはブックマーキングしページから離れ、戻ってきたときに同じ状態にするということがあります。

Angularの新しいルーティングは、こうした様々な過程をより簡単にするものです。

Routingの歴史

このプレゼンテーションの内容はNew Routerの話ではありますが、その前にRoutingの歴史を振り返ってみたいと思います。

• ngRoute – Very simple router with basic feature
• UI-Router – Mature, flexible router for Angular 1 that influenced the design of the New Router
• New Router – Designed with Angular 2 in mind, also works in Angular 1, and has features for migration

Angular 1がリリースされたときは、ngRouteがありました。このRoutingシステムはよかったのですが、非常にシンプルなユースケースのみサポートしていました。そうすると開発者のニーズがその範囲を越えていき、ニーズを満たすためにコミュニティの中でUI-Routeが生まれてきました。

UI-Routeはとてもよくできていて、Angular 1とよくあっていました。我々はAngular 2ともうまく機能しAngular 1ともうまくいくRoutingシステムを作りたかったのです。そしてUI-Routerを作ってきた開発者の知識を使って、Angular 2でもうまく機能するような新しいRouterを作ることになりました。結果として、Angular 1ともAngular 2ともうまく機能するRouterを作ることができました。

マイグレーションの話は後でお話しますが、Angular 1ともAngular 2ともうまく機能するRouterを作ることができましたので、マイグレーションも簡単にできるようになりました。そして、Angular1, 2とうまく連携するということと、Reusable, Composableにも優れているものになりました。

このNew Router開発者の生産性を上げていくことができます。多くのところで使えるものを作りました。その再利用性ですが、一つ簡単な例として、みなさんの会社の中で複数の場所で使えるロギングの仕組みを考えた場合がそうです。もう一つの例としては、リファクタリングしている間にこのコンポーネントを動かすことができるということです。

APIに関しても、他のRouteingを使っている開発者にとって、使い勝手のよいものにしました。あえて新しいものを発明するというよりも、いままで使っているRoutingの考えををAngularの中でも適用していく、ということにしました。Routingのプロジェクトには様々なものがありますが、新しいRoutingシステムは、特に目新しいものではありません。

以上のことを念頭に置き、新しいRouterについてどういうところで使えるかお話していきたいと思います。

Basic Use

$routeConfig

次の例は、あまりおもしろいWebアプリケーションではありません。しかし、アプリケーションのメニューの部分をクリックするとURLが変化します。

URLとしてハッシュバンを使っていますが、HTML5を使うこともできます。このアプリケーションのコードが下記になります。

angular.model('example', [
    'example.goobye',
    'example.welcame',
    'ngAnimate',
    'ngNewRouter'
])
.controller('AppController', ['$router', AppController]);

AppController.$routeConfig = [
    { path: '/',          redirectTo: '/welcome' },
    { path: '/welcame',    component: 'welcome' },
    { path: '/goodbye',    component: 'goodbye' }
];
function AppController($router) {
	this.greeting = 'Hello';
}

このコードの中で興味深いところだけをピックアップしご紹介します。

AppController.$routeConfig = [
    { path: '/',          redirectTo: '/welcome' },
    { path: '/welcame',    component: 'welcome' },
    { path: '/goodbye',    component: 'goodbye' }
];

このコードが、ルーティングをどう設定するかのコンフィグレーションになります。これは単純なJavaScriptオブジェクトですが、$routeConfigのプロパティをコントローラーに対してAttributeをつけていきます。これにより、コンポーネントに対してどうURLにマッピングするかをAngularに伝えていきます。

たとえば「/」が「/welcame」にリダイレクトするように設定しています。そして「/welcame」はコンポーネントの「/welcame」に「/goodbay」はコンポーネントの「/goodbay」にいくということになります。

ng-link

このアプリケーションに対応しているHTMLがこちらです。

<!doctype html>
<html lang="en">
<head>
  <base href="/examples/angular-1/animation/">
</head>
<body ng-app="example"
      ng-strict-di
      ng-controller="AppController as app">
  <nav>
    <ul>
      <li><a ng-link="welcame">welcame</a></li>
      <li><a ng-link="goodbye">goodbye</a></li>
    </ul>
  </nav>
  <ng-viewport></ng-viewport>

  <script src="/node_modules/angular/angular.js"></script>
  ・・・
</body>
</html>

ここでも興味深い機能をご紹介します。ng-linkのAttributeですが、値がwelcameになっていてWelcameのコンポーネントに結びついています。そして、このディレクティブは自動的にhrefタグを生成していきます。

ngViewport

もう一つ面白いのがngViewportディレクティブです。ngViewportはプレスフォルダに対しアクセルします。そしてプレスフォルダの中はコンテンツに基づいて管理されています。

Sibling Routes

今度はもう少し複雑な例を見てみます。アイデアを表した概念図はこちらになります。

このアプリケーションでは、URLに基いてパネルをリアレンジすることができます。もしURLが/post/usersになっていたらpostは左、usersは右に見せることができます。URLが逆になっていたら、パネルも逆に表示されます。この例のコードの例を見ていきます。

AppController.$routeConfig = [
  { path: '/',            redirectTo: '/users/posts' },
  { path: '/users/posts', components: { left: 'users', right: 'posts' } },
  { path: '/posts/users', components: { left: 'posts', right: 'users' } }
];

<nav>
  <a href="./users/posts">users then posts</a>
  <a href="./posts/users">posts then users</a>
</nav>
<div class="container">
  <div ng-viewport="left"></div>
  <div ng-viewport="right"></div>
</div>

ここで重要なのは、複数のコンポーネントに対して、名前で指定することができるというところです。ngViewportは、アトリビュートとしても利用することができます。このアトリビュートの値ですが、コンフィグレーションの中で使われているものと対応することができます。

Lifecycle Hooks

この機能を使うために、例を紹介します。この例ではユーザが保存しない場合、「saveしますか？」と問い合わせを出します。もしユーザが保存するという場合は、ナビゲータが出てきて指示どおりに動かくことができます。「saveしない」ということになれば、そのまま処理を行いデータを保存まま進めることもできます。ここでも重要なところを見ていきます。

angular.module('myApp', [
  'ngNewRouter',
  'myApp.index',
  'myApp.editPost',
  'myApp.saveModel'
])
.controller('AppController', ['$router', AppController])
.factory('post', postsFactory);

AppController.$routeConfig = [
  { path: '/',         component: 'index' },
  { path: '/post/:id', component: 'editPost' }
];
function AppController($router) {
  ...
}

function postsFactory() {
  return {
    '1': { title: 'First Post',  content: 'I wrote this first' },
    '2': { title: 'Second Post', content: 'I wrote this second' }
  };
}

Configuration DSLですが、ngRouteと似たものになります。

{ path: '/post/:id', component: 'editPost' }

この例ではIDを持っていて、コンポーネントに対してシリアライズされていきます。そして、「editPost」というコンポーネントにナビゲーションされます。対応するコンポーネントがこちらです。

<h1>Post Index</h1>

<ul>
  <li ng-repeat="(id, item) in index.posts">
    <a ng-link="editPost({ id: id })">
      Edit {{item.title}}
    </a>
  </li>
</ul>

Deep Linking DSLは、パラメータを使っています。

<a ng-link="editPost({ id: id })">

この場合は、特定のリンクに対してidを付与しています。今度はeditPostコンポーネントのコードを見ていきます。

angular.module('myApp.editPost', [])
.controller('EditPostController', ['$routeParams', 'posts', ...

function EditPostController($routeParams, posts, saveModal) {
  this.saveModal = saveModal;
  this.post = posts[$routeParams.id];
  this.newContent = this.post.content;
}

EditPostController.prototype.canDeactivate = function () {
  if (this.newContent === this.post.content) {
    return true;
  }
  return this.saveModel.getResponse();
}

$routeparameterがコントローラーにどう渡されていくかを見ていきます。

canDeactivateメソッドを使っていまが、これはAngularのルーティングシステムが理解できる特定のメソッドになります。URL変更やナビゲータのフックの一部として、このフックを実行してきます。ここには現れていませんが、getResponse()でポップアップを見せていくこともできます。この関数はプロミスを返します。このプロミスですがユーザがどのボタンを押したかによって、リゾルブあるいはリジェクトになっていきます。

Angularのシステムは、このプロミスの値が何になるかわかるようになります。このシステムにより、より大きなアプリケーションの中で複雑なものをコンポーズすることができます。そして、今述べたように、Routerは異なるものを組み合わせていくことができます。

ナビゲーションがスタートしたときに、既存のコンポーネントがリアクタベートされることができるか、リユースすることができるのかを決めていきます。答えが「Yes」であれば、このナビゲーションは完了していきます。

もしリアクティベートできないのであれば、アクティベートしていきます。そしてリアクティベート可能なら新しいコンポーネントのインスタンスを生成していきます。次のコンポーネントに対して、アクティベート可能か聞いていきます。新しいコンポーネントがアクティベート可能なら、古いコンポーネントに対しリアクティベートしていきます。

最後に、新しいコンポーネントにフックしてviewportのプレスフォルダーの中に入っていきます。

マイグレーション

新しいRouterは、Angular 1からAngular 2へのマイグレーションを簡単にするという話をしました。Routerというのはアプリケーションにとって最もトップクラスにあたります。マイグレーションする上でRouterの2つの重要な機能があります。

• Angular 1とAngular 2とで同じコンフィグレーションを使っていく
• 新しいRouterを使っていくことで一部はAngular 1で他の一部Angular 2で動く

上がAngular 2、下はAngular 1です。

@component({ selector: 'hello-app', ... })
@Template({ ... })
@RouteConfig([
  { path: '/'     , redirectTo: '/home' },
  { path: '/home' ,  component: 'index' }
])
class HelloComponent {
  greeting: string;
  constructor(service: GreetingService) {
    this.greeting = service.greeting;
  }
  changeGreeting() {
    this.greeting = 'howdy';
  }
}

angular.module('hello-app', [].controller( ... );

HelloController.$routeConfig = [
  { path: '/'     , redirectTo: '/home' },
  { path: '/home' ,  component: 'index' }
];

function HelloController(greetingService) {
  this.greeting = greetingService.greeting;
}

HelloController.prototype.changeGreeting = function() {
    this.greeting = 'howdy';
  }
}

見た目が違うように見えますが、ルーティングのコンフィグレーションという観点では変わりありません。

2つの目重要なこととしてAngular 1とAngular 2とで平行して動かすことができます。Angular 2が良い場合はAngular 2で、Angular 1がよければAngular 1で動かすことができます。

大きなアプリケーションを作っている場合、一度にAngular 2に移行することは難しいので使いたい部分だけ使っていけばいいです。つまり部分的にAngular 2にしていくことが可能になります。

これは、大きなアプリケーションの場合、徐々にAngular 2にしていくことが可能なことを示しています。最後にAngular 1として残った複雑なものは、すべてが終わった後にゆっくり変えていくなど、いろいろなやり方でマイグレーションしていくことができます。

Future

New Routerですが、すべてがまだ完全に終わったわけではありません。現在のカレントバージョンは0.5になっています。新しいRouterが出せるまでにもう少し作業しなければならないのですが、New Router 1.0はAngular 1.4と同時に出そうと思っています。なのでタイミングとしては来週にリリースする予定になっています。

その後New Routerのリリースに関しては、Angular 1、Angular 2とも独立したかたちでリリースしていくことになります。

New Routerに関して情報がほしい人はこちらを見てください：

• http://goo.gl/rC4xcZ
• https://github.com/angular/angular.js/issues/11015
• http://angular.github.io/router/

プレゼンテーション資料

今回取り上げたプレゼンテーションの資料は、以下で公開されています。合わせてご覧ください。

セッション動画

当日のセッションはYouTubeで公開されています。逐次通訳付きなので、ぜひご覧ください！

この記事は、Angularをテーマとした日本初のカンファレンス 「ng-japan」のイベントレポート（第2回目）です。

はじめに

HTML5ハイブリッドアプリケーションとは、内部の実装にHTML5が利用されているモバイルアプリケーションです。アプリの内部実装にHTML5を使うことでクロスプラットフォーム対応が可能になりますが、その代わり問題となるのがUIとパフォーマンスです。このセッションでは、Angularの上に構築されたUIフレームワークであるOnsen UIを紹介しながら、Angularでどうすれば高速かつ快適なUIを持つモバイルアプリを作れるかについて話します。

AngularとOnsen UIで作る最高のHTML5ハイブリッドアプリ – 久保田 光則

久保田光則氏は、アシアル株式会社でUI/UXデザイナー兼ソフトウェアエンジニアとして活動されています。今回お話するOnsen UIのリード開発者としても活動していて、専門でハイブリットアプリを開発しています。本日お話する内容はAngularの上に作られたOnsen UIというライブラリの内容になります。Onsen UIはonsen.ioというドメインで日本語版/英語版が公開されているオープンソースです。

特徴としては

• HTML5ハイブリットアプリ用のUIフレームワーク
• Angularをベースにしている
• iOS, Androidをサポートしている
• 高速な動作

今回は次のことに焦点を当てて、お話します。

• HTML5ハイブリットアプリとは
• ハイブリッドアプリ開発にどんな問題があるか？
• なぜAngularとOnsen UIが必要なのか？
• 少しだけOnsen UIの紹介

HTML5ハイブリットとはどのようなものか、ハイブリットアプリケーションを開発するときにどのような問題があるのか、AngularやOnsen UIがハイブリットアプリケーションを作成するためになぜ必要なのか、そして最後にOnsen UIのお話をしたいと思います。

HTML5ハイブリットアプリとは

HTML5ハイブリットアプリとは、ネイティブアプリとWebアプリの両方を書き合わせたアプリケーションになっています。実装の中身はHTML5で書かれています。WebViewというものがありその部分でHTMLを利用します。

HTML5ハイブリットアプリの何がよいのかというと、

• クロスプラットフォーム制
• Webの知識が活かせる
• ストアで配布できる
• ネイティブの呼び出しがJavaScriptから機能を呼び出しできる

ネイティブアプリケーションではそのプラットフォームの流儀に合わせて作る必要がありますが、HTML5の部分はプラットフォームには依存しないので、クロスプラットフォーム化しやすいというメリットがあります。

そして、Webの知識がそのままモバイル開発に活かせるということも、メリットの一つです。ネイティブ機能の呼び出しがなぜできるかというと、通常のWebViewではできず、セキュリティ的にも難しいところがありますが、Cordovaを使うことによってHTML5をアプリケーション内部でパッケージ化し、OSとのやり取りもAPIを通じて一本化できJavaScriptを通じて利用することが可能になります。

具体的には

• ファイルストレージ
• カメラ
• コンパス
• 加速度センサー
• コンタクトリスト
• ネットワーク
• Bluetooth通信
• などなど

さらにCordovaプラグインを作ることで、幅が広がっていきます。

「HTML5でモバイル・アプリが作れる」ということで、多くのフロント・エンジニアがHTML5ハイブリットアプリケーションに取り組んできました。あまりうまくいかなかったのが現実だったと思います。三年程前になりますが、Facebookは一部分の機能をHTML5で構築しましたが、結果として「HTML5に賭けたのは失敗だった」とし、ネイティブで書きなおすということが発生しました。しかし数年前に比べ、現在状況は改善してきています。

• 端末スペックの向上
• AndroidでのWebViewのChromiumの採用
• 利用できるHTML5 APIの増加
• Android2.3系のシェア低下
• CrossWalkの登場
• Android5からAndroid System WebViewの登場
• HTML5ハイブリットアプリケーションの事例増加
• BYODの一般化

最近だとRailsの作成なども昔はスペックが低かったのですが、最近はだいぶよくなってきたという認識があるようです。しかし、ネイティブに比べあまりよくないという印象があります。ではよくないというのは、何が問題なのかを考えます。

• パフォーマンスや安定性がよくない
• UIコンポーネントをいちいち作らないといけない

パフォーマンスに関しては、チューニングすればいいという話ですが。実際にはチューニングの方法に関しては、あまり興味ないという人が多いようです。特にフロントエンド開発者の多くが、HTML, CSS, JavaScriptの書き方は理解しているが、チューニング方法に関してはあまり関心がないということがあるようです。

そこでチューニングのやり方について、少しお話しようと思います。

効率的なチューニング

まず、どこがボトルネックになっているのかを調べる必要があります。これはハイブリットアプリケーションを開発する人だけではなく、一般のWebアプリケーション開発者に取っても必要になる事柄です。

• インスペクタのTimelineタブで計測
• AndroidではChrome
• iOSではSafari

実機で開発しているときにも、このインスペクタを使って測定することが可能です。インスペクタのTimelineで取れるカテゴリは4つあります。

• Loading
• Scripting
• Rendering
• Painting

このLoading, Scripting, Rendering, Paintingという流れがありますが、これを1frameと呼びます。描画が始まってから終わるまでが1frameで、この1frameを16ms以下に抑えればよいということになります。Timelineを使って測定した後、どこにボトルネックがあるかでチューニングが変わります。

Loading

Loadingは、リソースの読み込みやパースが行われます。ハイブリッドでは、Webアプリケーションよりも消費する時間は短いです。理由としては、リソースがローカルにあるからです。通常のWebアプリケーションは、リソースの取得もこのLoadingに含まれます。

Scripting

次に、Scriptingになります。これは、JavaScriptの実行時間になります。

今のJavaScriptの実行時間としては、純粋な計算は速いと考えてよく、基本的には問題ならないです。ただし、canvasへの描画などは遅くなる場合があります。チューニングに関しては、簡単で単純にでき、Profilesタブでどのコードが遅いかを確認すればよいということになります。

Rendering

ここから話が少しややこしくなります。Renderingであるレイアウト処理は、大きく2つの処理があります。

• Recalculate Style – 要素に当たるCSSルールの計算
• Layout – Render Treeの生成

Recalculate Styleがどのような計算をするかというと、個別のDOM要素に対して該当するスタイル（プロパティ）を計算します。CSSがレンダリング内部でパースされるとCSS OMという形になり参照して

DOM要素の数 × CSSルール

数分のマッチング処理が行われます。チューニングの一つとしてCSSの使ってないルールは削除するというものがありますが、この数式に由来しています。ルールが一つ減るだけでも、DOM要素の数分処理が減るということになるためです。さらに、重たいCSSの書き方を減らすということを行うと、より効果的です。

その次のLayoutというフェーズでは、すべてのDOM要素のレイアウト情報を計算します。計算された結果として、視覚的なオブジェクトツリーのことをRenderTreeと言います。そして、CSSの書き方やDOM要素の数を工夫することで、レスポンス改善することができます。

Painting

4つのうちの最後の処理ですが、さらに3つの工程があります。

• Paint – Display Listの生成
• Rasterize – Display Listを実行してピクセル化
• Composite Layers – レイヤの合成

雑多なチューニングテクニック小話

translate3d(0, 0, 0)が速いのはなぜ？

これは、GPUで描画されるので速いという話がありますが、実は半分正解で、半分は間違っています。GPUで描画され、transform CSSプロパティを変更しても、Composite Layersのみが起こるためです。同時に別処理でLayoutを引き起こしたりすると、効果が薄れます。

どのCSSプロパティを変更すると、何が起こるのかというところは不明瞭な部分が多い。ある程度パターンはあり次の区分けで分類できます。

• 要素の大きさが変わるような場合
• Layoutから処理が始まる
• transformやopacityたとComposite Layersのみ実行
• CSSプロパティによる変更では事象が異なる

CSS Triggersというサイトがあるので、ぜひ参考にして欲しいと思います。CSSプロパティを変更すると、インスペクタのTimelineで取れるカテゴリの何が実行されるかを示した表になっています。

http://csstriggers.com/ の紹介

DOMリークを防ぐ

DOM要素が誤って参照されたまま、開放されないという現象です。見た目よりも深刻で、DOM要素の参照は親要素への参照も子要素への参照も持っているので、DOMリークが起こるとすべてリークになります。detached DOMツリーとそれに参照されているリソースが、すべてリークするということがあります。その中に画像が入っているとそういった部分もリークします。

ディスクトップではあまり意識しなくてもよかったのですが、iOS, Androidだとメモリスワッピングが弱く設計されていて、アプリケーションの利用を破棄するといったことが起こります。そのためにモバイルだと、メモリーの管理を余計にしないといけなくなります。

reflowを起こさないようにする

Reflowを起こさないためには

• 画像のサイズは必ず指定
• DOMツリーから切り離して操作

画像がまだ読み込まれていない時に、サイズとして仮指定する場合があります。画像を描画し、本当のサイズにレンダリングすることになりますが、DOM要素の大きさが変わるため、Layoutの処理が再度はじめから行われるということになります。

GPUバウンド

CPUよりもGPUの方で時間がかかっている状態のことを、GPUバウンドと言います。先ほどtranslate3d(0, 0, 0)が速いという話がありましたが、これはComposite Layersだけが走っているためです。しかしこれを使いすぎると、GPUバウンドが発生します。

GPUバウンドなページを作ることは簡単で、多くな領域を持つ要素にtransform: translate3d(0, 0, 0)を当てて多く生成し、アニメーションさせれば作られます。

チューニングの罠

こういったチューニングの大部分のところは、レンダリングエンジンに依存しています。どうしてもわからないときは、レンダリングエンジンのソースを読んだりします。ただ、なぜHTML5のコードを書くのに、ここまでやる必要があるのか。なぜ単にCSS書いているだけなのに、GPUのVRAMへの転送速度を気にしなければならないのか、という疑問があります。実際にアプリケーション開発中にここまでチューニングする余裕はないはずだし、こういったチューニングをすべて把握することを、開発者に求めてよいのかということもあります。

ごく一部の人間でないと、高速なHTML5ハイブリットアプリケーションは開発できないのでしょうか。今のHTML5アプリケーションの課題としては、アプリケーションアーキテクチャの構築方法の不在ということや、チューニングされて高速に動作するUI基盤がないということが言えると思います。ネイティブだとUIフレームワークがあるが、HTML5ハイブリットアプリケーションだとUIフレームワークがないというのが現実です。

Onsen UI

そこでOnsen UIです。この目的は、開発者がアプリの開発そのものに注力できるようにすることです。

Angularをベースにして構築しています。Angularの持つ機能を利用しHTMLを拡張することで、アプリケーションを記述することができ、大規模なアプリケーションでも耐えられるアーキテクチャを作ることができます。Angularの持っているディレクティブを使うことで、UIを構築することもできる。Onsen UIでは「ons-」を使っています。そして、Adobeの超高速CSSフレームワークtopcoteを利用しテーマを開発しています。またOnsen UIでは多くのコンポーネントを用意しています。

Onsen UIが目指すものとして、誰でもHTML5で高速に動作するモバイル・アプリケーションを作ることができる世界を提供したいと考えています。さらに、UIをどうチューニングするかではなく、アプリケーションの本質的な機能の開発にフォーカスすることができる基盤も提供したい。今後は、Onsen UIはMaterial Designs、Angular2のサポートを行っていくつもりです。

プレゼンテーション資料

このセッションのプレゼンテーション資料は下記になります。合わせてご覧ください。

セッション動画

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

Angularをテーマとした日本初のカンファレンス 「ng-japan」が2015/3/21(土)サイバーエージェントで開催されました。

ng-japanは、参加者350名以上という、単独JavaScriptフレームワークをテーマにしたカンファレンスとしては、非常に多くの方が来場。日本でAngularを利用して活躍しているスピーカーや、Google Angularチームのメンバーを迎え（逐次通訳あり）、Angularの現状と未来についての学びの場となりました。

本日からそのイベントの模様を6回に渡り、あますところなくお伝えしていきます！

Angular1.4 and beyond – Chirayu Krishnappa氏

最初のセッションでは、Angular1.4の新機能の概要について紹介がありました。また、パフォーマンスの向上とAngularアプリケーションを構築する上で、維持しやすいコードを書くのためのベストプラクティスについても紹介されました。スピーカーのChirayu Krishnappa氏は、Google社でAngularやAngularDartを担当しています。

セッションは、来日されたGoogleエンジニア3人の紹介からはじまりました。一枚目のスライドは富士山をバックにした記念写真です。右からChirayu Krishnappa氏、Brian Ford氏、Igor Minar氏です。富士山に登ってみたかったということですが、時期としては閉山しているので残念だったので、絵をバックに写真を撮ったとのことです。

それでは本題にはいります。

Angularとコミュニティ

私がお話するトピックは「Angular1.4」です。まだAngular1.4はリリースされていませんが、あと一週間ほどでAngular1.4がリリースされる予定です。これは、今までリリースされたAngularの中でもっとも成熟度があり安定したリリース版となっています。オンライン上に1.4に関する様々なリソースが提示され読むことができます。

Angularのコミュニティはとても大きく様々な素晴らしい人に参加してもらっています。このグラフはコミュニティの成長過程を示していますが、実際にはAngularのソースコードが格納されているgithubリポジトリに対するビジターを数えています。

6ヶ月前の段階で、2週間の間に5万人ほどの方に訪れてもらっていました。現在時点では、2週間で10万人ほど訪れてもらっています。そして同じ2週間の間に1600ほどの新しいissueやPRが作られます。そして新しい200ほどのコントリビュータが新しいPRやissueを立てていたり、ドキュメントを修正するということを行っています。これほど大きなコミュニティに育ったことをとても嬉しく思っています。多くの方がAnglarが大好きということ、急速に採用してくれていることをとても嬉しく思います。

Angularコニュニティの成長は著しく、はじめの頃はGoogleのコア・メンバーがコミットしていましたが、現在では、Googleのコア・メンバーとコミュニティのコミットかでは、コミュニティのコミットの方が多くなっています。

Angular1.4とは

Angularのリリース・プロセスは完成されていて1週間単位でリリースができるような仕組みが構築されています。Angular1.4では35の新しい機能が入り、140のバグが修正されています。そしてパフォーマンスの点で改善が行われています。

今回はAngular1.4の機能の中で特に興味がありそうな機能をピックアップしました。

まずは、

• New Router
• Pluralization and Gender support
• ng-animate update
• ng-message update
• ng-cookies update

最初の機能のNew routeです。特に皆さんが興味ある機能ですし様々な機能が盛り込まれていますので別のセッション、ブライアンから説明します。Angularの中で複数および性別を扱ってていくことができJavaScriptでコードを書く必要がないということになります。ng-animateに関してはすぐに目に見えて役に立つというものではありませんが、将来利用していく中で活用することができると思います。そしてng-message,ng-cookiesもかなりの改善が行われています。

Pluralization and Gender support

ここでは「複数の扱い」と「性別の扱い」について見て行きたいと思います。このシンタックスはICUが出しているMessage Formatのシンタックスがベースになっています。現行Angularのinterpolationシンタックスを拡張したもので、interpolationシンタックスの中で記載することが可能になっています。これにはいくつかのアドバンテージがあり

• 宣言型になっている
• 新しい国際化に対応できる
• アトリビュートの中で使うことができる

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

例をいくつか紹介しますが、オンラインで見てもらうことでより詳細なことが分かります。

{{numMessage, plural, 
    =0 { You have no new message }
    =1 { You have one new message }
 ohter { Tou have # new message }
}}

複数扱いの簡単な例になりますが、今までAngularのコードを記載するときに行われていたダブルカーリーで記載します。ダブルカーリーの中でカンマが続きメッセージフォーマットが入ります。この書き方は、現在時点のAngularのコードと互換性があります。

つまり、後方互換性があるということを意味しています。詳細については説明しませんが簡単に読める構造なっています。最後のパラメータでは、複数のインタプリを入れることができ、変更があった場合には容易に追加することができます。性別に関するものも同様でシンプルな構造になっています。

{{friendGender, select,
     male { Invite him }
   female { Invite her }
    other { Invite them } 
}}

ng-massage update

ng-massageの変更点について説明します。大きな特徴が2つあります。

一つ目の特徴ですが、複数のインクルードを入れることができます。そしてもうひとつexpentionを入れることができます。これにより簡単にコンフォート、リファクタリングすることができます。

<input type="email" ng-model="data.email" name="myEmail"
ng-minlength="5" ng-maxlength="100" required />

<div ng-message="myForm.myEmail.$error">
  <div ng-message-exp="['minlength', 'maxlength']">
    Tour email must be between 5 and 100 characters long 
  </div>
  <div ng-message-include="required-errors.html"></div>
  <div ng-message-include="email-errors.html"></div>
</div>

ng-cookie update

いままでのAngularにおけるcookieの対応はシンプルなものでだったので、もっといろいろな機能を追加して欲しいという要望が多く上がっていました。それらリクエストには

• クッキーのドメインとパスを持ていること
• クッキーがアップデートできること
• 2年程前からあるあまり一般的でないバグについていくつか解消したこと

その他に何が機能として新しく加わったかというと

• CommonJSフレンドリーなビルド
• “unknown provider”というエラーをインジェクション使って取り扱うことができる
• jqLiteを強制的に使う、あるいは特定のjQueryバージョンを使うことができる
• ngOptionsを使ってオプションをdisableに
• limitToを使うとbeginning indexの引数を加えた
• ngModelで$setDirtyメソッドの使用
• ルートプロバイダですがアプリケーションのcase-Insensitiveなurlに対応
• ngAriaのオートアクセサビリティに関する改善
• $httpについての改善

ぜひみなさんもチェンジログを読み、どこが自分に関係するのか見てもらえるとよいかと思います。

Better Performance

さきほど言ったようにAngular1.4においてはパフォーマンス向上にフォーカスしています。その中でもダイジェストタイムの改善を行っています。ダイジェストタイムというのは、Angularで何かイベントが発生した場合、何が変わったかというのを発見するという機能で、それによりUIを変更するという機能です。これは30%程度改善されました。メモリーのfootprintですが2〜4%改善しました。ということはそれほど頻繁にガベージコレクションを考えなくていいことになります。

とは言え自動的に皆様が作ったアプリケーションのパフォーマンスが30%程度あるいは数%改善されることはありません。パフォーマンスの改善の度合いはアプリケーションの構造や作りにもよります。しかしながら、特に大きなテーブルや大量のデータを扱った場合は、直ぐにレスポンス改善されたというのがわかると思います。Angular1.4がリリースされたら何をするべきかというと、まずはUPDATEするのがよい。

そしてAngular1.4を構築するにあたって互換性に関しては注意をしました。大規模な変更がほとんどのアプリケーションで影響を及ぼすことはありません。

Angular1.3でサポートされていたブラウザはAngular1.4でサポートでされます。そうすると全員Angular1.4にバージョンアップしなければならないと思われます。その次にはAngular1.5にアップグレードしていきます。

Angular1.5

Angular1.4は一週間後にリリースされますが、そのあとAngular1.5の作業になります。

Angular1.5の策定の作業も今までの作業と同じように作業を行っていきます。Angular1.5を決めていくにあたってはgithubの意見を尊重しフィードバックする形で行われます。github上でどの機能を入れていくかを決めていきます。Angular1.5の中に入っていくものはコミュニティの意見にしたがって決めていきます。

次はAngular 2ということになりますが、new routeもあり、いろいろな新しいトピックがあります。今Angularでアプリケーションを開発するにはAngular1.4で開発するのが最もよいと思います。このリリースが最も安定しているというのは変わりありません。

リリースサイクル

リリースサイクルの期間がどんどん短くなっています。過去においてリリースサイクルはゆっくりしていた。例えばAngular1.0からAngular1.2は2年近く必要でしたが、リリースサイクルは後になればなるほど短くなっています。

どうやったらうまくリリースを出していけるか、そしてサイクルをより効率よくできるか考えていました。リリースサイクルが早くなるということは将来の姿がすぐに見えるということになります。そして、リリースサイクルが短くなるということは、一回のリリースが盛りだくさんで移行が大変になるということがなくアップデートが容易になるということが言えます。

Angularコミュニティ

少しコミュニティについても考えていきたいと思います。AngularコミュニティというのはAngularにとって欠かせないものになっています。ngJapanもそうですし2週間前に開催されたng-confもそうです。我々はコミュニティが好きだし、コミュニティの力も必要としています。新しいプルリクエストや機能、バグフィックス等をいただけることは我々にとってとてもエキサイティングなことです。しかし、そのようなリクエストが多ければ多いほど、それをカバーする時間に多くを割く必要があります。みなさんのお手伝いによって助かっていきます。

最後にその3つの分野について触れていきます。

新しい機能を追加していくとき、開発者とのスレッドを立て何をつくろうとしているのかディスカッションから始めるといいです。新しい機能を開発するときはなるべく多くの人が参加して、多くの人が考えることが重要です。どの部分でデザイン変更が必要になるのか予測できるようにするのが重要です。そういう過程を踏むことでより良いAngularになると思われます。機能のプルリクエストはなるべく絞り込んで行くことが重要で、なるべくコンパクトにしてあとでまとめていくのがいいです。そして後でプルリクエストをつなげる方が良い方法です。変更というのは後で簡単に足していけるので、初めは機能として絞り込んだものの方が必要になります。

PRを出していくにあたって重要なことがあと2つあります。

unitテストを加える事が重要です。前回のコードに対して3,000のunitテストがありましたが、unitテストがあればあるほどコードカバレッジがよいということになります。詳細についてはコントリビュートドキュメントがgithub上にあるので確認してもらえるとよいと思います。

最後はバグやissueに関する分野です。自分が期待していた通りに動かない場合、何処かにバグがあるかもしれません。実際にこのテストが失敗したという実例を入れてくれると助かります。このバグの情報をやりとりをするときに、記述の中にどこでどのようなバグがあったのかというのを伝えて行くことは、同じ英語の中でもとても伝わりにくいです。ですので、失敗したテストコードをつけてもらうことで曖昧さがなくなり、手助けになります。バグだと思っていてもリリースサイクルが短くなったことでFIXしているかもしれません。ほんとにmasterでも治っていないことなのか確認してください。

さまざまな多くのPRがでてきますので、どれを優先して解決していくのか決めていきます。みなさまにも情報を提供してもらい、古いissueによくあるのが、すでに解決しているものもいくつかあります。古いissueのリストの中に入っていて、もう重要でない問題である場合、コメントを入れていただけると助かります。

プレゼンテーション資料

今回取り上げたプレゼンテーションの資料は以下のとおり公開されています。合わせてご覧ください。

セッション動画

当日のセッションはyoutubeで公開されています。逐次通訳付きなので、是非ご覧ください！