EmberFest 2017 参加レポート day 2 - tricknotesのぼうけんのしょ

前回に引き続いて、EmberFest の二日目のまとめです。

f:id:tricknotes:20171024024436j:plain

本記事公開時点では多くの発表資料が未公開のため、詳しい説明や具体例がほしくなる部分があるかと思いますが気持ちで補って読み進めてください。

The Revolution will Not Be Centralized

話者 : Edward Faulkner - @ef4

アニメーションライブラリのデファクトである liquid-fire の作者である @ef4 による "ambitious"¹ なアプリケーション開発のための技術スタックの発表。

前提: アプリケーション開発において、自分が書く必要があるコードは少ない方がよい
- SPA 開発の文脈だと、まずサーバサイドの実装にはかなりの労力を割く必要がある。
- 例えば、、、
  - Authentication
  - API endpoint
  - Data serialization
  - ...
- これらを毎回自分たちで実装するのはほんとうに必要なのだろうか？
そこで Cardstack
- Server Side App + Storage を置き換えることができる
- これはクライアントサイドの Ember だけでアプリ開発が完結する状況になるということ
- Cardstack のための Ember Addon があるので、自分が書かないといけないコードというのはほんとうに少なくなるはず
- Ember の領域でも、これから共通化可能なものは見出されるはずなので、みんなで共有してアプリ開発を加速させていこう

Cardstack 自体は Ember に依存するものではなく、分散型インターネットを実現するためのアーキテクチャとプロトコルだそうです。² Ember コミュニティ発³のプロジェクトということですが、特定の企業に非依存である点⁴はとても興味深かったです。⁵

Adopting better Ember patterns

話者 : Sarup Banskota - @sarupbanskota

話者は Ember を始めて一年とのこと。これまでの経験の中での学びを紹介します。

いくつかのパターンを紹介する
- Avoid CHATTY templates
  - 条件分岐が多いようなテンプレートは、ヘルパーやコンポーネントを使って読みやすくしよう
  - 同じような DOM 構造を繰り返すような場合はイテレータを使かおう
- Don't abuse services
  - ビジネスロジックやストレージに関係するようなものをなんでもサービスにするのはやめよう
- Use moar ember-data methods
  - 検索クエリのための Ajax のような処理は Ember Data のアーキテクチャにのせよう
  - 例えば、Adapter / Serializer
- Don't indulge in observer
  - なんでも observer はやめよう
  - よく考えると、computed property / lifecycle メソッドで十分な場合が多い
- Send data down & actions up
  - 子のコンポーネントの中で親からもらったデータを気軽に更新してしまうと、状態管理が複雑になる

Ember を使ったことがある開発者であれば、誰もが頷けるような内容でした。経験の浅いメンバーに対してパターンとして紹介するときに参照したい発表内容でした。

Improving the UX is the developers job

話者 : Jakub Niechciał - @jniechcial

SPA でのよい UX と、Ember でのその実現方法についての話。

SPA でのよい UX とは？
- Fast
  - Non blocking data fetching
  - Rendering on server
- Native
  - homescreen
  - Splash
  - Notification
  - Offline
- Indicate current state
- Handle errors
  - Caught and wrapped errors
Working on UX with Ember
- リソースではなく、画面で URL を組み立ましょう
- 似たような画面であっても、UI/UX の観点から別の画面なのであれば別の URL を割り当てましょう
- Ember Data のモデルとサーバサイドのモデルは 1:1 で対応するものではないので、それぞれでモデルを考えましょう
  - partial model / full model
- Fastboot で初期画面の表示を早くしましょう
- オフラインでも使えるように、Service Worker を検討するものありです
- エラー発生をユーザーにフィードバックするために、 Promise の catch を忘れないように！

本編では時間の制約もありあまり踏む込んだ具体例はなかったですが、 SPA の開発者であれは常に意識しておきたいポイントがとてもよくまとっまっていました。 SPA 開発の際にはチェックリストとして見返したい資料です。

Writing tests like a speed demon with data builder patterns

話者 : Daniel Sudol - @danielspaniel

Data Builder Pattern を用いて高速でメンテナブルなテストの書き方の話。

テストデータの準備をシンプルにしたい
- 例えば、ツリー型タブのように木構造を形成するデータのセットアップは面倒
- 参照関係を設定しつつデータを準備すると、どうしても多くのコード行数を必要としてしまい、これはテスト対象の本質ではない部分が増えてしまう
そこで Data Builder Pattern⁶
- 一連のテストデータの準備をオブジェクト化して、テストコードをシンプルに保てる
- 木構造のデータについても、参照関係を Data Builer に渡すようにすると、具体的な設定はカプセル化できる
テストフィクスチャについて
- Mirage は HTTP リクエストに対するクライアントサイドのモックなので、データを加工するのがやりづらい場合がある
- そこで、 FactoryGuys⁷
- これは Ember Data の store を直接参照するので、 Mirage の 5~7x 高速に動作する

Data Builer Pattern は今回初めて知ったのですが、古くから確立されているパターンなのですね。資料では Pattern 適用後の具体的なコードがわかりやすく解説されていたので、公開されたらご参照いただければと思います。

SDK... Ambitious... What about a RAD tool for the web?

話者 : Emmanuelle Delescolle - @nanuxbe
資料 : https://bit.ly/RAD4web

サーバサイドとクライアントサイドで似たようなコードを書かなくて済むように、SPA のための RAD tool⁸ のご提案。

Ember でフロントエンドを開発するにあたっては多くの仕事が必要となる
- DB / ORM にスキーマと定義する
- そのモデルをフロントに渡すための REST API をサーバサイドに作成する
- バックエンドのモデル構造を Ember の世界にも複製する
- そのモデルに対応するフォームを作成する
- フォームにレイアウトを設定する
これらの仕事の大半は重複であり、自動生成することで解決可能になるのでは
- 具体的なアプローチとしては、HTTP の OPTIONS を使って、データスキーマをサーバサイドからクライアントサイドに渡してモデルのスキーマを自動で定義する
- Ember の実装は ember-cli-dynamic-model
- サーバサイド(Django)の実装は DRF-schema-adapter

動作するアプリケーションをいかに早くリリースするか、という観点でとても興味深い内容でした。 REST API を重複とみるかフロントエンドのためのモデリングとみなすかは議論が分かれる点だとは思いますが、RAD tool としての話者の割り切りは一理あるなと感じました。またデモがリッチなアプリケーションだったので、資料と合わせてデモ(資料中にリンクがあります)を試してみるとより雰囲気がわかりやすいかと思います。

Hybrid Apps with Ember/Glimmer

話者 : Alex Blom - @alexblom

Ember.js/Glimmer.js を使ったハイブリッドアプリ(PWA とネイティブどちらとしても配布可能なアプリ)の実装の話。

話者が開発中の corber のご紹介
- cordova ための CLI
- 特定の JS ライブラリに依存していない
  - 現在は Ember, Vue, React/Webpack, Glimmer をサポートしている
  - 以前は ember-cordova として開発していたが、現在は corber に移行した
- PWA とネイティブアプリでの差異をきれいに分離できる
- ビルド、ライブリロード、アイコンスプラッシュなど、ハイブリッドアプリの開発で毎回必要になるであろう手間な部分をサポートしている

おぉっ、なんだかよさそう！という印象でした。ドキュメントがしっかりしているのと、積極的に開発が進められていることからも、今後にも期待できそうな感触です。

Testing against Time - Meaningful testing in Ember apps when timing matters

話者 : Jessica Jordan - @jessica-jordan

非同期のテストに立ち向かうための Tips の話。

話者について
- Simplabs 所属
- The Ember.js Times やってます
- Ember.js Berlin meetup
非同期のテスト
- Ember には組み込みのacceptance test 用のヘルパがいくつか用意されている
  - 同期・非同期のヘルパが存在するので、記述した順に実行されるとは限らない
  - 非同期のヘルパ Ember の run loop 内で実行される
  - 同期ヘルパは即時実行されるので、非同期ヘルパと組み合わせる場合は andThen 関数でラップする
    - run loop 内だと、実行順序が保証される
テストダブル
- 外部の API を呼び出すような場合は testdouble を使う
- また、async / await で書けば、ネストが深くなることはなく、可読性を保てる
Grand Testing Unification
- まだ RFC の段階だが、いままでは各レイヤごとに違ったテストでの非同期の扱いを統合していきたいという議論がなされている
- これが実装されると、Ember 本体が提供する機能でさらにシンプルなテストが書けるようになる
時間のテスト
- 時間に依存するテストは Date をモックするとよい(ember-cli-timecop)

Ember のテストはちゃんと書いたことがなかったので、なるほどという感じでした。 Grand Testing Unification が入ると、またテストの世界が変わってきそうで楽しみです。

LT

@turbo87

実装に依存しない抽象度の高いテストを書きましょう、という話

High Level ~~Abstructions~~ Assertions
DOM のアサーションだと、改行や空白文字を考慮しなくてはいけない場合が多々あるが、これはテストの本質ではない
- chai / chai-dom を使うと、よく書ける
- さらに、話者の所属する Simplab 作の qunit-dom を使うともっとよく書ける

?

Authmaker のご紹介
- https://github.com/Authmaker
- https://github.com/Authmaker/authmaker-ember-simple-auth

?

コード + トークのみで、上手く聞き取れませんでした 😵

@michalsnik

ember-content-placeholders のご紹介
- データ読み込みの間、枠だけ表示してくれる Ember Addon (話者作)
- Facebook の読み込み中の UI がイメージに近い

@bardzusny

eslint-plugin-glimmer のご紹介
- まだ作りたてなので、これからどんどん機能追加していく予定
- ⭐ してね！

Closing Keynote

話者 : Eric bryan - @ebryn

Ember のコアコミッターである @ebryn によるキーノート。コミュニティの話。

みなさん、Ember コミュニティにようこそ
有名のライブラリの多くは特定の企業がホストしているけど、Ember はコミュニティベースの OSS だ
- コミュニティベースの OSS は (JS の世界だと) 珍しい
- 特定の企業が中心にいないということは、民主主義による決断が行われるということ
"Ember is for the children"
コントリビューションはとても小さなことから始められる
- 自分の場合は fix typo だった
- コントリビューションは、フレームワークを学ぶための偉大な一歩だ
"Driving standards"
革命は Ember 本体からだけではない、コミュニティからすばらしいライブラリが生まれている
また、OSS コミュニティはコードだけというわけではない
- ミートアップ
- ドキュメント
- ニュースサイト
みなさん、ぜひぜひもっと参加してね！

今でこそコミュニティをコードでリードしている話者ですら、最初のコントリビューションが fix typo だったというのはなかなか感じ入るところがありました。たしかにここ数年で、Ember と取り巻くコミュニティは豊かになったように感じます。これからコミュニティがどんな風に進化していくか（もしくはわたしたちがどんな風に参加していくとよいか）を考えると、とても楽しみだなと思えました。

二日目の記事も、Ember.Sapporo (特に @ursm と @tmaeda) から多くのアドバイスをもらった上で作成されました。

わたしの速記の発表メモに対して、詳しく分析と解説をしてくれてとても理解が深まりました。ほんとうにありがとうございました。

EmberFest の二日間のまとめはこれで終わりです。参加しそびれて残念だった…、という方に少しでも内容をお届けできていると幸いです。

最後に、EmberFest の雰囲気をもっと感じてもらうために、当日の様子を写真で紹介してこの記事を締めくくりたいと思います。

f:id:tricknotes:20171024024541j:plain 会場の外観です。オシャレな建物ですが、ふつうの多目的施設だそうです。

f:id:tricknotes:20171024024039j:plain 休憩時間、二階からの風景です。いい感じに壇上と客席の距離が近いですね。

f:id:tricknotes:20171024024031j:plain 懇親会(?)の様子です。会場から徒歩一分の場所にあるふつうのビアバーの一画で懇親しました。各自ビールを買って着席するスタイルだったので、みんな自由に来て自由に帰っていきました。

f:id:tricknotes:20171024025202j:plain お昼ごはんは、会場にハンバーガーを売ってるワゴンショップが来てくれました。好きなメニューを注文するともらえます。代金は参加費に含まれています。

ハンバーガーを手にしたら、近くのベンチで他の参加者の方々と自由に喋ります。

f:id:tricknotes:20171024025206j:plain 休憩時間には、好きなコーヒーを好きなだけ淹れてもらえます。これも参加費に含まれています。ちなみに、この隣にはソフトドリンクが好きなだけもらえるバーカウンターもありました。

f:id:tricknotes:20171024025038j:plain Ember コミッターの ebryn, locks, ef4 と記念写真を取ってもらいました。以前から GitHub 上では交流があったのですが、オフラインでお会いするのは初めてだったので感無量でした。

f:id:tricknotes:20171024030150j:plain 懇親会への道中の様子です。滞在中は、毎日こんな感じのいい感じの夕焼けが見られて癒やされました。

f:id:tricknotes:20171024030203j:plain EmberFest 恒例(らしい)のナイトクルーズでの懇親会です。船の乗り場の周りは本当に真っ暗でちょっと怖い。

f:id:tricknotes:20171024030215j:plain お酒が入ると、まぁふつうの懇親会になりますね。窓の外の景色がゆるやかに変わるのと、たまに花火が見えたりするのがよい感じでした。

Ember.js のキャッチフレーズである “A framework for creating ambitious web applications.” より↩
公式サイトによると、"Cardstack is building an open-source software architecture and protocol, to bring the decentralized Internet to the masses by offering a Cohesive User Experience (CUE) that spans the blockchain and the cloud.“ とのこと↩
https://github.com/cardstack/cardstack#project-wide-policy-and-community-governance 参照↩
Closing Keynote でも語られていますが、Ember.js はコミュニティベースの OSS であるため、特定の企業に非依存であることはひとつの価値だ、とみなされることが多いです。↩
もちろん、メリット・デメリットはあるのですが…↩
http://wiki.c2.com/?TestDataBuilder ↩
これは Ruby のデータ生成ライブラリである factory_bot (factory_girl からリネームされました) インスパイアのライブラリです↩
参考: https://ja.wikipedia.org/wiki/Rapid_Application_Development ↩