EmberFest 2018 参加レポート day 2

2018年10月にアムステルダムで行われた EmberFest の二日目の参加レポートです。 f:id:tricknotes:20181011180358j:plain

一日目のレポートはこちら。

tricknotes.hateblo.jp

今回も印象に残ったトークをまとめています。

Honey, I shrunk your Ember app by Simon Ihmig - @simonihmig

話者の開発しているプロダクト(The Local Water)で、いかにアプリケーションのサイズを小さくするかという工夫の話でした。 低速な回線を利用するユーザーを対象とする場合、ファイルサイズは直接ユーザー体験に影響を与えます。 そのため、話者はファイルサイズを小さくして快適に表示できるようにすることで、使い心地のよいアプリケーション開発に注力しているとのことでした。

サイズを小さくするにあたって大事な原則は、Measure -> Analyze -> Optimize のサイクルだそうです。 これらについて、具体的に見てきましょう。

Measure

  • production 用に uglify & gzip したあとのサイズで計測する
  • ember-cli-bundlesize を使うと計測が楽である
  • CI で計測して、サイズを計測し続ける

Analyze

  • broccori-concat-analyzer を使って、どのライブラリのどのコンポーネントが割合を占めているのかを可視化する
  • Ember アプリの場合、ember-cli-bundle-analyzer を使うと可視化しやすい

Optimize

  • 依存の多い Addon は外す前提で考える
    • 例えば ember-lodash, ember-moment, liquid-fire
    • とくに話者の場合はこれらのライブラリが提供する機能に対して、ごく一部しか使っていなかった
  • そもそもサイズの大きなライブラリは外す
    • bootstrap , jQuery*1 (ただし、Addon の中には jQuery に依存している可能性があるので注意)
  • サポート対象外のブラウザのためのトランスパイルが含まれていないか確認する
    • とくに IE11 を対象にするとファイルサイズが大きくなりがち
    • 同様に、babel-polyfill の読み込みを外す
  • gzip 互換なよりよい圧縮が利用できないか検討する(ただし、非対応のCDNは多い)
    • Zopfli
    • Brotli (こちらの方が圧縮性能はよいが、IE11, iOS11 は非対応)
    • ember-cli-deploy-gzip を使うと圧縮ファイルを生成できる

話者はこれらすべてをひとつひとつプロダクトに適用した結果、アプリサイズ500KBから300KBに削減できたそうです。

感想

大変実践的な内容で、ファイルサイズを小さくするにあたってのガイドラインとなりそうな発表内容でした。

Mastering the Art of Forms by Danielle Adams - @danielleadams

Heroku でエンジニアをしている Danielle Adams 氏による、Ember でフォームの作るためのテクニックの話でした。 発表資料はこちらから確認できます。

Composable Elements

コンポーネントを組み合わせ可能な単位で定義することで、ユーザーから見えるひとくくりの部品に名前を与えます。 例えば、ラベルとテキストフィールドの組み合わせに対して FormTextInput というコンポーネントを定義します。

これによってアプリ内で UI が標準化され、実装面・利用面どちらからも統一感のあるものにできます。 結果として、再利用可能になるため UI の変更を行いやすくなります。

Manageable & Performant Data

例えばセレクトボックスの中身のようなマスタデータについては、Route で解決するのではなくコンポーネント自身がデータ取得を行います。 これによって、画面の表示完了を阻害しなくなりますし、コンポーネントがテスト可能になります。*2

また、Ember のモデル層(Ember Data や Ember Model)を永続化層のデータ管理としてだけではなく、一時的なユーザー入力の保存場所として利用することで入力値を管理しやすく入力値チェックを行いやすくなります。*3
例えば、会員登録フォームに対して models/sign-up というモデルを割り当て、入力値に対応する属性を定義します。 入力値に問題があれば ember-cp-validations などのライブラリを利用して、ユーザーにすぐにフィードバックを行えます。

Accessibility

サブミットした瞬間ではなく、入力値に問題があればフォーカスが外れたタイミングでユーザーにフィードバックを返します。 こちらについては、具体的なアプローチは語られていませんでした。

感想

ユーザーのための UI 設計と実装上のテクニックの橋渡しをするようなトーク内容がとても印象的でした。

The Future Of Templating In Ember by Chad Hietala - @chadhietala

Ember のコアチームで Glimmer を担当している Chad Hietala 氏による、Glimmer の将来像についての話でした。 話者の別のカンファレンスでの発表内容はこちらです

まずは Glimmer の設計の原則の話で、以前の Ember は Easy に使えるようなテンプレートのデザインでしたが 現在は Simple を目指しているとのことです。 以下、 Ember のテンプレートにおける Easy と Simple の一例です。

  • Easy
{{name}}
{{#each posts}}
  {{title}} <!-- 暗黙的変数のコンテキストが切り替わり、post の title が参照される -->
  {{name}} <!-- posts の外のスコープで定義された name が参照できなくなる :< -->
{{/each}}
  • Simple
{{name}}
{{#each posts as |post|}}
  {{post.title}} <!-- 明示的に変数を指定して値を参照する -->
  {{name}} <!--コンテキストが切り替わらないので、posts の外のスコープで定義された変数を参照できる -->
{{/each}}

また、すでに実装されたもの・これから取り組んでいくものの RFC が紹介されました。

Required this

コンポーネントから渡ってくるプロパティについては、必ず this 経由でアクセスすることを強制するという機能です。 これによって、プロパティの定義元が自明のものとなります。

Arguments

Easy / Simple の例でも紹介しましたが、as キーワードで引数を受け取れるという機能です。 each ヘルパーのみならず、任意のヘルパー・コンポーネントでも(実装側がサポートしていれば)任意のオブジェクトを引数として受け取ることができます。 こちらは数年前から実装されていますが、Ember 1.0 では提供されていませんでした。

Angle Brackets

Ember 3.4 の目玉機能です。 コンポーネントを template 中に直接記述でき、コンポーネントへの引数と HTML への引数が区別できるようになりました。 github.com

Named Blocks

ひとつの Component に対して、ヘッダとサイドバーなど複数の部品を呼び出し側から差し込むための機能です。 github.com


最終的に、これら RFC がすべて実装されたあとの Ember のテンプレートはこういった世界になるということです。

また、ここで紹介された未来像については、こちらの issue にて議論が進められています。 github.com

感想

将来的なビジョンを定めて、互換性を大事にしつつも着実に進めていく Ember コミュニティの様子には驚かされるばかりです。 これまで「Ember について知っている必要があること」が数多くありました。ただ、これらは初学者にとってのハードルが高くなっていたと言わざると得ません。
今回紹介された Glimmer の改善によって、"ふつうの HTML / JS" の流儀の上で Ember が存在するような世界が実現されるように感じられ今後がとても楽しみです。

全体のまとめ

去年は Glimmer のパフォーマンス改善の話が衝撃的でしたが、今年はユーザー側に向けた地道な改善の話と利用事例・設計の工夫の話が多かったように感じました。 今回のレポートでは取り上げませんでしたが、GraphQLCordova での事例もお話された方がいらっしゃいました。

つい先日最新の LTS である Ember.js 3.4 がリリースされ、ここからしばらくは deprecated になっていた機能の削除と新しい機能追加が行われていくことでしょう。
今回の EmberFest では実際に Ember を本番利用している開発者が多く参加しており、EU 圏での盛り上がりを感じられとても有意義でした。

まだ来年の EmberFest の場所は決まっていません(EU圏のどこかのはずです)が、来年も多くの変化があることを楽しみに参加したいと思います。 もしこの記事を読んで興味持たれた方がいらっしゃれば、来年はぜひ一緒に行きましょう!*4

当日の様子(おまけ)

参考までに、当日の様子を写真でふりかえります。

入り口の立て看板 f:id:tricknotes:20181012022020j:plain

朝ごはんを用意してくれているので、早めに会場に行くと食べながら他の参加者とダラダラしゃべれます。 f:id:tricknotes:20181018000516j:plain

カフェでは好きな飲み物を注文できます。(料金はチケット代に含まれています) f:id:tricknotes:20181018003713j:plain

会場の外はこんな感じアムステルダムの大きな通り沿いにある多目的ホール(?)です。 f:id:tricknotes:20181018000902j:plain

お昼の風景。会場に用意してくれているので、発表を聞き終えたらそのまま好きにとって食べる感じでした。 f:id:tricknotes:20181017195003j:plain

こんな感じ。 f:id:tricknotes:20181017194958j:plain

*1:Ember.js 3.4 ではついに jQuery への依存を外すことができるようになりました

*2:サーバサイドの経験が豊富な開発者だと Route でデータ取得を行いたくなるかもしれませんが、コンポーネントで独立させたほうがテストしやすくなるそうです。

*3:Railsなどのサーバサイドフレームワークでは、フォームオブジェクトとして知られるテクニックとよく似たアイディアです。

*4:いるのかな…

EmberFest 2018 参加レポート day 1

去年に引き続き、今年のEmberFest参加レポートです。 残念ながら日本では Ember.js の話を聞く機会は少ないので、ここぞとばかりにアムステルダムでのカンファレンスに参加してきました。

f:id:tricknotes:20181012022004j:plain

今回のカンファレンスで、自分がとくに印象に残ったトークをまとめました。

Opening Keynote by Tom Dale - @tomdale

Ember.js のコアコミッタであり、Yehuda Katz氏とともに Ember.js の開発をリードする Tom Dale 氏の基調講演からのスタートです。 2019 年の Ember の姿についてのお話でした。

Angle Bracket

Ember 3.4 では Angle Bracket の導入に伴い Component の API が整理されました。 これによって、ユーザーからは Component への引数と HTML への引数が区別されて((これまで HTML 要素の更新しようとすると、Compoonent の attributesBingins という Ember 独自の属性を設定する必要があり、初学者にとってわかりづらいのが悩みのタネでした))、より直感的に Component を使うことができるようになりました。

github.com

Glimmer

Glimmer の進化によって、いままでの実装の都合による制限が取り除かれました:

  • ルート要素に id="ember...class="ember-view" が付与されなくなりました
  • ルート要素として <div> が生成されなくなりました
    • その結果、template が複数のルート要素を持てるようになりました
  • tagName, className, elementId など、Ember が独自に提供していた HTML 操作用の属性を使うことなく HTML の属性を直接指定できるようになりました

今後はいままで直感的ではなかった Computed Property の定義を改善予定とのことです。

Ember Octane

生産性とパフォーマンスの向上を目的とした取り組みを新しいコードネーム(Ember Octane)の元で開始するとのことです。

github.com

Emberは古くから開発されているフレームワークだということもあり、これまでレガシーな仕組みが多々ありました。*1
すでに getter / setter、ES5 用のポリフィルなどの古い機能は削除されましたが、まだまだレガシーな仕組みは残っています。
今後はそれらを徐々に廃止し、ES 標準の classes、 decorators や async / await といった機能で置き換えていくことを目的としています。

感想

Ember は古くから開発されているフレームワークですが、互換性を保ったままモダンなフレームワークとして生まれ変わりつつあります。
これから新しく Ember.js を始めるユーザーにとって、今どきの ES の記述で違和感なく開発できるのはすばらしいことですね。

From the Browser to the Home Screen: PWAing Your Ember App by Kevin Pfefferle - @kpfefferle

PWA開発にあたって話者が実践している取り組みの紹介でした。 こちらは、話者がデモ用に用意したEmberFestのスケジュールアプリです。

なお、話者はPWAのパフォーマンス計測にLighthouseを使っているそうです。

また、Emberアプリのために次のAddonを使っているとのことです。

これらの取り組みとひとつひとつ適用することで、Lighthouseでの計測結果は100点になったそうです。

感想

PWAのための具体的な取り組みを聞くことができました。 これからEmberでPWA開発を始めようという方にはとても参考になりそうな発表でした。

ELS - the Ember Language Server byTobias Bieniek - @turbo87

Ember コミッタでもあり、Ember CLI チームとしても活躍されている Tobias Bieniek 氏による発表です。 Ember アプリを開発するにあたって、エディタによる気の利いた補完は生産性を高める上で非常に重要なものとなります。 とくに Ember は CoC に則ることで高い生産性を提供するフレームワークなので、JavaScript動的言語…とは言えある程度は規約に対して静的解析できるはずです*2

そこで、話者が着目したのが Language Server です。 このプロトコルに沿って API を実装すると、対応しているクライアント(主にエディタを想定しています)からはコード補完などエディタを便利にする機能を提供する余地が生まれます。
話者が現在鋭意実装中なのが Ember Language Server です。

今回の発表では、Ember Language Serverを実装する上でに工夫をお話されました。

  • Handlebars のテンプレートは、Glimmer が提供する機能を使えば AST に変換できるので、現在のカーソル位置でなのを補完するべきか(HTML タグなのかコンポーネントなのかヘルパーなのか)が定まる
    • ただし、テンプレートを記述している途中など文法エラーになる場合はまだうまく対応できていない
  • ユーザー定義のヘルパーは、app/helpers の下のファイルを探索することで変換候補に追加できる
  • Ember.js コアやアドオンも含めて、定義元を開く機能も提供できる

一方、Language Server Protocol で未サポートのため、今はまだ追加できない機能もあるとのことでした。

  • model / controller / template など、ファイルの種類に応じたアイコンの出し分け
  • 関連ファイルの提案
    • model / route / template など、「定義元」の候補が複数想定される場合にそのすべてをユーザーに提示する

感想

発表中に話者から、利用しているエディタについての質問がありました。
VimEmacs が同程度に少なく、VS Code ユーザーが大半だったのが印象深いです。 Ember アプリの場合エディタがサポートする機能が増えると覚えておく必要があることが減り、新規で開発を始める開発者に優しくなると感じています。 これからの進捗がとても楽しみですね。

Going Realtime with Ember by Michael Lange - @DingoEatingFuzz

マイクロサービス間でのデータ同期・バッチ処理・通知を目的としたクラスタスケジューラであるNomadの紹介でした。 現在は話者の所属企業で開発が進められています。

感想

デモがよくできていて、nomad コマンドを経由してジョブの実行を行うことで、瞬時にEmberアプリにデータが同期され画面に通知が表示される様子は感慨深いものがありました。
ユーザーひとつだけで完結しないEmberアプリを開発する場合には、なんらかのタイミングでのデータ同期が必要でこれを自前で構築するという場面は多々あるかと思います。
Nomad によってこの基盤が汎用的に使えるようになると、開発がとても捗るのではないでしょうか。

Ember Meetup

この日の夜は、アムステルダムの Ember コミュニティによって Ember Meetup が開催されました。

とくになにかに取り組んだというわけではないですが、地元のコワーキングスペース(?)でみんな思い思いにビール片手に喋っていました。


以上、一日目の参加レポートでした。 二日目の様子はこちらをご覧ください。

tricknotes.hateblo.jp

*1:ES3 の時代から存在しているため、いまでは言語がサポートしている機能をフレームワーク側でサポートする必要がありました

*2:Ember.js 本体は TypeScript への移行が進んでいますが、アドオンやユーザーについては TypeScript で書くことを強制していません。

Rails Developers Meetup 2018: Day 2 で「リモートなチーム開発」というタイトルでお話しました

リモートワーク…というよりかは、リモートが前提となっている状態で自分がどういうことを考えながら(また、実践しながら)チーム開発と付き合っているかというお話でした。

speakerdeck.com

"リモートワーク"という言葉が指す範囲がすごく広くなってきている(し、ひとによっても違う)ので、ちょっと紐解いてみると上手くやるためのヒントが見つかるかもしれません。

イベントページの概要がよくまとまっているので、転記しておきます。

ここ数年でリモートワークを導入している会社はだんだんと増えてきましたし、その良さと難しさについては各所で語られるようになってきました。

わたしはここ七年間、リモートワークという働き方で多くのチーム多くのプロダクト開発に関わってきました。
その経験を通してわかったことは、リモートワークとは個人の働き方ではなくチームのあり方だということです。

リモートワークをしたいモチベーションはひとによって様々でしょう。
しかしチームが違えば価値観が違うように、チームに合うリモートワークのやり方も違ってきます。

この発表では、わたしのいままでの経験から見えてきたリモートなチーム開発をよい感じにするための心がけをお話しいたします。
これからリモートワークを始めようとしているチームにとってなにかのヒントになれば幸いです。

techplay.jp


また、今回登壇のお声をかけてくださった平野さん(@yoshi_hirano)たいへんありがとうございました!素晴らしいイベントでお話する機会をいただいて感謝するばかりです。

EmberFest 2017 参加レポート day 2

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

f:id:tricknotes:20171024024436j:plain

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

The Revolution will Not Be Centralized

  • 話者 : Edward Faulkner - @ef4

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

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

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

Adopting better Ember patterns

話者は 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

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

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

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

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

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

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

  • Ember でフロントエンドを開発するにあたっては多くの仕事が必要となる
    • DB / ORM にスキーマと定義する
    • そのモデルをフロントに渡すための REST API をサーバサイドに作成する
    • バックエンドのモデル構造を Ember の世界にも複製する
    • そのモデルに対応するフォームを作成する
    • フォームにレイアウトを設定する
  • これらの仕事の大半は重複であり、自動生成することで解決可能になるのでは

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

Hybrid Apps with Ember/Glimmer

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

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

  • 話者について
  • 非同期のテスト
    • 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 を使うともっとよく書ける

?

?

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

@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 お酒が入ると、まぁふつうの懇親会になりますね。 窓の外の景色がゆるやかに変わるのと、たまに花火が見えたりするのがよい感じでした。


  1. Ember.js のキャッチフレーズである “A framework for creating ambitious web applications.” より

  2. 公式サイトによると、"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.“ とのこと

  3. https://github.com/cardstack/cardstack#project-wide-policy-and-community-governance 参照

  4. Closing Keynote でも語られていますが、Ember.js はコミュニティベースの OSS であるため、特定の企業に非依存であることはひとつの価値だ、とみなされることが多いです。

  5. もちろん、メリット・デメリットはあるのですが…

  6. http://wiki.c2.com/?TestDataBuilder

  7. これは Ruby のデータ生成ライブラリである factory_bot (factory_girl からリネームされました) インスパイアのライブラリです

  8. 参考: https://ja.wikipedia.org/wiki/Rapid_Application_Development

EmberFest 2017 参加レポート day 1

EmberFest 一日目のまとめです。 EU 圏では Ember ユーザーが比較的多く、プロダクション投入している企業も多いようです。 今回の EmberFest では地域コミュニティだけでなくコアコミッターも多数参加しているということだったので、実際にお話してみたいなと思って参加してきました。

f:id:tricknotes:20171017214224j:plain

参加できなかったけど、ぜひ内容知りたい!という方のためにまとめます。

Opening Keynote — Ember.js in the year 2020

ここ最近、Ember core / CLI からドキュメントまで幅広い守備範囲をカバーしていくれている @locks の発表。 2020年(というよりかは少し先の未来)に向けた Ember のやっていきの話でした。

バージョンアップに伴う API の変更を、ユーザー / ライブラリ開発者にとっても極力影響の小さいものにしつつ、着実に進化しているんだなぁというのがよくわかる発表でした。 ここ最近は目に見えてインパクトのある機能は追加されていないように見えますが、内部構造は大きく改善されているというのがよくわかる内容でした。 Glimmer については、後述の"Compile-time optimizations for you and me"で踏み込んで解説されているのでご参照ください。

Designing Immutable data flows in Ember

例えば React のような不変なデータ構造を Ember に導入するとどういう状態になるか、というパターン実装の話。 Ember のアプリケーションステートは得てして複雑になりがちで、そこに不変データ構造を持ち込むとどれくらいシンプルになるかという思考実験。(と言いつつ、彼はおそらくプロダクションでも使っていると思われる)

  • Ember.Object (Ember Data を含む) は大変ステートフルだよね、という前提がある。
    • Ember は observer パターンで DOM 変更の要・不要を検知しているので、基本的にはオブジェクトのプロパティの変化に興味がある。
  • そこで、immutable data flow を導入してはどうか、というご提案
    • data tracking が簡単になる
    • 状態管理がシンプルになる
    • 2 way binding とか、結構大変…
  • 例えば、this.set('name', newName) する代わりに、this.set('user', newUser) するのだとどうか1
  • Immutable Component のコンセプト
    • 引数のプロパティを更新したくなるような場合、コンポーネント生成時に受け取った引数と同じ型のデータを生成して親のアクションを呼び出す
    • データの生成は Object.assign や Spread object properties を使う
    • このコンセプトは、composition が深い場合もうまくいく
    • "data down actions up"
  • これを徹底すると、データフローがわかりやすくなるだけではなくコードもシンプルになる
    • ネストの下層のものだけ監視したいようなコードを書く場合、とても上手く機能する すべての状態が更新されるので、トップレベルのオブジェクトだけ監視するので十分になる
    • 例: @computed('user.{firstName,lastName}') -> @computed('user')
    • そしてこれは、Ember だけではなく Glimmer の場合も上手く機能する

Ember の CoC から少々逸れているように思われたのが気になりましたが、内容としてはとても理にかなっていると思いました。 原理主義的なアプローチ…というだけでもなく、状態管理+コードが実際にシンプルになる点は興味深かったです。 いまだとコーディング規約と思想で実現するしかないので、もう少し具体的な何か(例えば Lint ?)がライブラリとして提供されるようになる採用しやすくなるのかもしれません。

Treeshaking in Ember CLI

  • 話者 : Alex Navasardyan - @twokul

Ember CLI チームでとてもアクティブなコアメンバーである @twokul の発表。 長年の課題であった Tree-shaking のご提案。(参考: https://dockyard.com/blog/2014/11/28/ember-wish-list)

  • ビルド後の最終成果物に、利用されていないコードを含めないようにするためのアプローチについて。
    • 現状は、すべてのコードがビルド後の JS に含まれている。たとえアプリケーションから使われていないコードがあっても。
    • 実はこれはなかなか根が深い問題で、Ember の本体が DI によって動的にモジュール解決する仕組みを導入することに起因している。
      • Ember 自体は古くから開発されていることもあり、いまとなっては Legacy だと思われる部分のひとつである
    • しかし、これは module API によって解決可能となる2
  • いまは最初の実装を試している、という段階

多くの部分を聞き逃した可能性がある(ほんとはもっと喋っていた)ので、資料が公開されたらもう少し深掘りして内容を更新したいと思います。

How to start loving Acceptance Tests in Ember.JS

Acceptance test の重要性と、いかにそれを上手く書くかというテクニックの話。

  • SPA ではユーザーの入力を起点に複数のコンポーネントが状態を変更する。
    • もちろん、Unit test が大事だということを否定はしないが、コンポーネント間のつながりの部分のテストが漏れがちなので、Acceptance test を書きましょう。
  • いくつかのポイントを紹介する
    • Mirage + faker を使って、テストデータの定義を管理する
      • 最近の Mirage は Ember Data のモデルを勝手に見つけてくれて便利(以前は、Mirage と Ember Data のモデルの対応を表現するクラスをいちいち作る必要があった)
    • ページオブジェクト(ember-cli-page-object) を使って、シナリオ中の CSS セレクタへの参照をカプセル化する3
    • CSS セレクタの重複が省けるし、テストシナリオの可読性もよくなる
    • andThen はネストさせる必要はないので、テストがシンプルに保てる
  • メンテナンス可能で可読性の高い Acceptance test を書いていきましょう

Ember の開発でいまどきのスタンダードと考えられているテストの書き方を紹介してくれていたのかなという感じでした。 目新しい話ではなかったけど、introduction としてはたいへんよくできたチュートリアルだと感じました。

そういえば、Acceptance test の抽象度を上げるという観点だと Cucumber を利用するのもアリなのかな…という気がするのですが、その利用例はあまり聞いたことがないですね…。

スポンサートーク

  • Simplabs
    • Ember.js + Phoenix をメインのツールとして採用している
    • ソフトウェア開発(受託) / コンサル / トレーニングをやっている
    • 興味あれば、あとで話しかけて!

Ember @ Netflix

Ember を積極採用して、これまでに20個程度のアプリをプロダクション投入した Netflix の実例について。 Netflix ならではの技術スタック・パターンをご紹介。

  • Authentication
    • BOLT UI -> Meechum -> JWT
  • Mixin の生成パターン
    • Ember の Mixin 生成をラップした簡単なコードがある
    • これを使うと、動的な Mixin 生成が簡単に書ける4
  • Query params
    • 素の Query params だと controller と route に似たようなコードを書くことになるので、alt 実装を作った
    • これを使うと、ユーザのテキスト入力の変化の度に検索クエリを発行するような UI がきれいに書ける
  • テストデータ
    • 安定の Mirage を使っている
  • Data Table
    • 大量のデータを扱うグリッドレイアウトを実現したかったので、専用のライブラリ(?)を作った
    • "Ember X Table" 5

20 個も Ember アプリを本番リリースすると、いろいろとパターンが見出されてくるんですね…! これも資料の内容がわかりやすかったので、公開されたらもう少し深掘りします。

Building the Progressive Web App for HackerNews.io in Ember

https://hackernews.ioProgressive Web App (以下、PWA) として作った話。

  • いくつかのポイントとその実装について
    • Service Workers + Metadata でオフラインでも使える
    • Postcss + BrowserTargets でクロスブラウザ対応してる
    • Ember Route で、任意の画面をエントリポイントにできるように URL をサポートしている
    • モデルの適切なマッピング
    • 初期ロードのパフォーマンスを改善するためにいくつか工夫をした
      • 素の状態だとファイルサイズがめちゃくちゃ大きく表示に時間がかかるので、せめて React と同等程度のパフォーマンスを出したい
        • 特にモバイルで影響が大きい
      • まずは jQeury を dependency から外す
      • つぎは vendor.js + app.js で concat して async でロードする
      • rel=dns-prefetch / rel=preconnect / rel=preload meta link を CSS の読み込みに使うと、ダウンロード開始までの時間を短縮できる
      • とくに初期表示に必要な CSS を inline 化する -> - ember-cli-critical
      • CDN を使う
      • ここまでやって、画面表示に必要な時間が 12s -> 4s (話者の環境で、React と同等)になった

とても実践的な話しでした。 "PWA" とはなにかを話者自身がしっかり定義してその実装を工夫した話で、すぐに使えるテクニック集という観点でも参考になりました。

Promoting Ember's best practices by linting code

Ember アプリへの lint 導入の話。

  • Link の種類と Ember でのアプローチ
  • また、Lint の実行タイミングについても、いろいろあるので各自工夫してほしい
    • CLI
    • text editor
    • Git hooks
    • CI
  • Ember の blueprint には ESLint の設定が含まれているので、テスト実行時に ESLint が一緒に実行される
  • また、もし lint がチームで上手く機能していない(毎回 disable にしたり、修正に使う時間がかかりすぎていたり…)場合には lint をやめるということを考えてもよいかもしれない

いくつかのツールは話者が開発したということもあり、話者の Lint への愛を感じました。 JS は曖昧な書き方ができてしまいそれが混乱の原因になりうることが多いので、Lint を強化するというアプローチには正しいように感じられます。

Deep Dive on Ember Events

Ember での Events の仕組みを理解しよう、という話。

  • 前置き
    • 実は Ember の世界では、DOM Events をフレームワークが受け取ったあと、各 Component にディスパッチするというイベントモデルと採用している
    • DOM Event -> Ember Event の順番で、それぞれ子から親にイベントが伝搬していく
      • どこかで propergation を止めることができるが、そうすると以降にイベントは伝搬しない
  • イベントハンドラの書き方と、DOM / Ember Event の対応について6
  • 続いてパフォーマンスの話
    • DOM Event は要素に対してハンドラが生成されるので、ハンドラの設定数に比例してレンダリング速度が像以下する
    • 一方、Ember Event はバブリングを利用しているのでレンダリング速度は一定
    • 実行速度はどちらもあんまりかわらない7
    • また、アプリの書き方によっては DOM Event でも Ember Event でもハンドルすることができる
  • 次は、条件によってハンドラの内容が変わる場合
    • 書き方によっては意図通りに動いたり動かなかったりする8
  • いろいろなイベントハンドラの定義方法があるけど、仕組みを理解したうえでイベントハンドラ使ってね

たしかに Ember の Event の仕組みは概要を理解していないと難しいと感じることがあります。 資料ではとてもわかりやすくハンドラの違いが説明されていたので、ハマったときには読み返してみたい発表内容でした。

Compile-time optimizations for you and me

Glimmer 最適化のアプローチの話。

  • Glimmer を最適化することによって、ビルド時間・実行時間をもっと高速にできる
  • "Flexibility and Optimizability are oppsites"
    • テンプレーティングの柔軟さと最適化可能度は相対する概念である
    • (Less Power) << Ember / Vue / Angular / React+Webpack >> (More power)
    • Ember のテンプレートである Handlebnars が制約が強いため、コンパイル時に最適化が効かせやすい
  • Glimmer VM でのいくつかのアプローチ9
    • 例えば div とか href といったよく使われる文字列(HTML の文字列だけでなく、アプリケーション固有の文字列も含む)を事前に定数表として組み立てておいて、VM ではその表への参照を使う方法
    • 現在はテキストベースの命令を採用しているが、これをバイナリに圧縮するという方法
      • VM がバイナリのまま実行できるようになると、ファイルサイズを圧縮できる
    • 変数のインライン展開
      • コンポーネントへの引数として固定値が渡されそれをテンプレートで参照しているような場合、コンパイル時に引数を定数として置き換える方法
  • Glimmer 単体だとこれらのアプローチは上手くいくことが期待できるが、実は Ember だとまだ課題がある
    • 例えば、Computed Property にはロジックを置けるので、その部分については Glimmer VM では手が出せない
    • もし Handlebars で表現されていれば Glimmer VM で最適化できるが、これについてはもう少し検討が必要

他のライブラリではあまり聞いたことがないアプローチでとても興味深かったです。 もしこれがよいアイディアだと認知されたらきっと他のライブラリでも実装が進むことになると思うので、Ember だけでなく他のライブラリも良くなることが期待されます。


以上、ざっくりとしたまとめでした。 なお今回のレポートは、日本では数少ない Ember コミュニティである Ember.Sapporo のメンバーの協力の元作成されました。

二日目の発表内容についてもまとめ次第公開予定です。


  1. このあたり、スライドがあるととてもわかりやすいので、公開され次第追記予定

  2. コンセプトと API は見通しが立ったので、あとは実装を頑張ればよい、という状態なはず

  3. Ruby の Capybara でも page object を実装したライブラリがあるので、これがアイディアの起源と思われる。 https://github.com/natritmeyer/site_prism

  4. 資料が公開されたら追記予定

  5. 詳細が不明なので、わかり次第追記予定。資料を見た感じだと、@ebryn(Ember のコアコミッター)も参加しているようだったので、かなり力をいれた何かだと思われる

  6. コードを見るととてもわかりやすいので資料を参照のこと

  7. 発表資料中ではグラフで比較されていてわかりやすかった

  8. 資料中にクイズ形式で例がでてくるので参照のこと

  9. Glimmer はテンプレートの描画に独自実装の VM を導入している https://github.com/glimmerjs/glimmer-vm

株式会社えにしテックを卒業してフリーランスになることにしました

昨日、2016年12月22日を最終出社日として株式会社えにしテックを退職することになりました。
有給消化の期間があるので実際の退職はもう少し先ですが、年明けからフリーランスとして活動する予定です。

本当はお世話になった方々みなさんに直接ご挨拶に伺いたいのですが、この場でのご報告になってしまうことをご容赦ください。

2011年4月にえにしテックに入社した当時は魚の取り方すらろくに知らないという体たらくだった私ですが、 ご縁があったお客さま方とあちこちのコミュニティ・そして頼もしい弊社メンバーのおかげでどうにかプログラミングでお仕事をさせていただけるようになったと思います。
そんな中、魚の取り方のもうちょっと手前の魚を探しに行くみたいなところを問題領域に近いひとたちと一緒に考えていけるような仕事の仕方を自分で模索したくなったのでフリーランスという道を選ぶことにしました。
同僚から見るとまだまだ頼りない部分が多いわたしですが、快く送り出してくださったこと心から感謝してます。

ありがたいことに1月からいくつかお仕事の引き合いも頂いておりまして、ひとまずお話を聞かせてもらう所から始めたいなと考えています。
ここを読んでくださっている方々とはまたどこかの現場でお会いするかもしれませんし、できることならそれが実現してほしいと思っています。

ではでは、みなさま今後ともどうぞよろしくお願いいたします!

実践入門 Ember.js の第4回が公開されました

第4回 ユーザのインタラクション(Controller, Component):実践入門 Ember.js|gihyo.jp … 技術評論社

今回で Ember.js の連載は折り返し地点となります。 ここまで Computed Property の説明が出てこなかったのが驚きですね。*1

次回からはもうちょっと手の込んだアプリケーションを取り上げていく予定です。 読んでくれている方々にとって、もっと楽しめるものになりますように。

*1:一昔前の紹介記事だと、この Computed Property を一番最初に説明するのが通例でした