EmberFest 2019 参加レポート day 1

毎年恒例となったこのレポートもついに3年目を迎えました 🎉
今年のEmberFestは、寒さがだんだんと厳しくなってきたコペンハーゲンにて行われました。

f:id:tricknotes:20191029221301j:plain
EmberFestのオープニングです

今年のカンファレンスでは、次のような発表が多かったように思われます。

  • 去年に引き続いての Ember Octane の進捗の発表
  • Ember に限定しない開発現場での工夫の話
  • サービス開発を行う上での Ember アプリの工夫の話

カンファレンスの参加者は200人で、去年とほぼ同じです。 主催者のアナウンスによると、これくらいの規模だとお互いに顔がわかって会話できるので、大きくしすぎることなく維持していきたいということでした。

では、各発表を簡単に紹介していきます。

Teaching Ember, Octane Edition - Opening Keynote by Godfrey Chan

Skylight のメンバーであり、Ember の開発を積極的にリードしている @chancancode による、Ember Octane についての発表でした。

Ember Octane とは、前回の EmberFest でも発表がありましたが、Ember の API の改善プロジェクトです。 とは言っても、Ember 既存のAPIを壊すものではありません。マイグレーションパスが用意されており、古いAPIに対しては警告メッセージが表示されるようになっています。

これまではロジックの多くを Ember の JS で記述する必要があり、特に DOM イベントの取得など前提知識を要求するものがあり難しさがありました。 Octane導入以降は、DOM イベントやライフサイクルhooksなどの多くをテンプレートに記述できるようになります。 これによって、テンプレートのみで完結できる部分が多くなり、開発者にとってわかりやすくなるそうです。

チュートリアル、ドキュメントも充実している*1のでぜひ読んでくださいと締めくくられていました

emberjs.com

The Future of Responsive Component Design by Chad Carbert

Heroku のメンバーであり、ember-responsive の作者である @chadian による発表でした。 Ember でレスポンシブデザインのアプリケーション開発をサポートする ember-responsive を使ったコンポーネント設計についての発表でした。

一般的に、レスポンシブデザインを扱う場合には Media Queryies と window.matchMedia を使うことになります。 しかしこれらはグローバルな設定のため、SPAとの相性はよくありません。
そこで、ember-responsiveを使うと、コンポーネントのレスポンシブを扱うための値が渡ってくるということです。

リポジトリのドキュメントに利用例が記載されており、発表でも丁寧に解説をしてくれていました。 まずはドキュメントを一読すると、雰囲気がよくわかることでしょう。

github.com

Why Pairing is Paramount by Sama Rao

Heroku でフロントエンドエンジニアとして Ember アプリの開発を行っている Sama Rao による発表でした。

ジュニアプログラマとしてキャリアをスタートさせてから、プログラミングを上達させていくためのオンボーディングプロセスの話です。 自然言語と比較したプログラミング言語の学び方という切り口の発表で、話者自身の体験に基づいた話でした。

自然言語プログラミング言語の学び方を比較したときの類似点は次のものを取り上げられていました。

  • 辞書=ドキュメントを用地いるということ
  • ネイティブスピーカーと接点を持つこと

また、シニアプログラマと密にコミュニケーションをとって学ぶことの利点として次のものがあると説明されていました。

  • ジュニアにとっては、新しい発見があり、知識を得る過程を知り、そしてフィードバックを受けられること
  • シニアにとっては、技術を伝える過程で新しい視点を得られ、ソフトスキルを熟達できること
  • 企業にとっては、ジュニアが成長することで戦力として期待できるようになること

JAM Stack for Human Beings by Chris Manson

Simplabs メンバーの @real_ate による発表でした。 JAM Stack を Ember でサポートするためのライブラリ Empress を開発中とのことです。
JAM Stack とは JavaScript, APIs, Markup の頭文字をとった名前で、Webサーバーなしで動作するサイトと動的アプリを配信する仕組みとのことです。

すでに Vue と React にはそれぞれ、 VuePressGatsby.js が存在していますが、いままで Ember にはありませんでした。
そこで話者はこの JAM Stack に対応するために、サーバサイドレンダリングのための FastBoot とプリレンダーのための prember を利用して、Empress を開発したそうです。

まだまだ API は実験中とのことでしたが、ぜひ試してみてくださいと発表を締めくくられました。

github.com

Steady State with Ember Octane by Jessica Jordan

Simplabs 所属の @jjordan_dev の発表です。彼女は、Ember Times / Ember Learn team のコアメンバーとしてもよく知られています。
今回の発表 Octane 時代のアプリケーションの状態管理の話です。

SPA 開発では複雑な状態管理と向き合うことになります。
特に、JavaScript において難しいのが変数のスコープで、そのスコープがローカルなのかグローバルなのかクロージャなのかをひと目で区別する方法はありません。

Ember についても同じ状況ではあったのですが、Octane ではテンプレート内でのスコープを区別することができるようになりました。
コンポーネントの外から渡された変数については @ を先頭につけてアクセスしますし、コンポーネントスコープのものは this 経由でアクセスします。 また、コンポーネント内では外から受け取ったオブジェクトを書き換えることは推奨されておらず、変更を親のコンポーネントにリクエストするようにします。*2 また、テンプレート内から参照するアクションをコンポーネントに定義する際は @action デコレータを利用します。

こういったやり方をフレームワークが提供できたことで、開発者が追うべき状態管理の責務をフレームワークに移譲できるとのことです。

Introducing TypeScript into a production Ember.js app by Adrian Zalewski

Customer.io の @bardzusny による発表です。
話者自身が開発している Customer.io に、TypeScript を導入した際のやり方の紹介でした。

Glimmer や Ember Data 、Ember の一部*3は TypeScript で書かれており、ライブラリの利用者に型情報を提供するという観点で、話者は TypeScript をよいものと考えているとのことです。

まず、Customer.io は Ember 製のアプリケーションですが、その歴史は古く、 2013 年に Ember 1.x で開発を始め現在では 3.x 系までアップデートされているそうです。 また規模も大きく、プロダクションコードで 60k LoC、テストコードで 120k LoC あるとのことでした。

話者が TypeScript を導入したときのアプローチとしては、次のようなものだそうです。

  • まず $ ember install ember-cli-typescript で実施し、 .js ファイルを .ts に書き換える
  • 次に、既存の JS は手を入れる際に徐々に型をつけていく
  • 新しいコードは TypeScript で書く
  • 大きなモジュールや、テストについては、一度に置き換えないという決断をすることもある
  • "any" / "unknown" 型 を許容してでも、少しづつ進めていく
  • コアモジュールやサービスなど依存箇所の多いところから手を付けていき、枝葉のモジュールについては優先度を落とす

また、制約事項としては次にようなものがあるということでした。

  • テンプレートが TypeScript 非対応である
  • 新しい概念が入るのでチームに混乱があるかも
  • コード量は増える

tinyurl.com

Make the Most of Your Problem by Chantal Broeren

Dockyard 所属の Chantal による発表でした。 話者自身が実践しているEmberアプリのデバッグ方法の紹介でした。

Chrome DevTools を利用した一般的なデバッグ方法と、Ember Inspector を使ったデバッグ方法の紹介です。

  • Chrome DevTools
    • Elements / Paint flashing を利用して、不必要な画面が書き換えが発生していないかを確認する
    • console.table() で、オブジェクト・配列の表示をわかりやすくし、 console.group() / console.groupCollapsed() でグルーピングし一覧性をよくする
    • debuggerソースコードに記述したりブレークポイントを設定して、実行中の状態を確認する
    • Live expression で、変数の値をリアルタイムに監視する
    • Pause on exceptions で、例外発生時に即座にデバッグを行う
    • Network で、http レスポンスをデバッグする
  • Ember Inspector
    • Components / Routes / Data / Container で、アプリケーションコードがどのように Ember に解釈されているかを確認する
    • Render Performance で、各コンポーネントの描画にどれくらい時間がかかっているかを確認する
  • その他
    • Ember.onerror で、例外発生時のトレースを外部のサービスに送信して確認する

さまざまなデバッグ方法で、問題点を分析し解決する方法の紹介でした。

Ember in orbit. Building apps for outer space connectivity by Miguel Camba

Dockyard 所属、かつ orbit の開発メンバーでもある @miguelcamba による発表でした。
PWAが広く認知されるようになりましたが、非常に遅延が大きいまたは頻繁に接続の失敗ような環境でも期待通りに動作するPWAの開発のために orbit を利用するという発表でした

例えば、宇宙を行き来するようなネットワーク(とても帯域が狭く、しかも頻繁に切断することがある)でも、正しく動作するPWAを意識して作れていますか、という問いかけから始まりました。
話者の開発している orbit は、JavaScript でデータの永続化層を扱うライブラリですが、なんとオフラインでデータ管理を行い、オンライン時に永続化層と同期することを視野に入れた設計がなされているそうです。

Ember とのインテグレーションライブラリである ember-orbit を使うと、いくつかの設定をアダプタを書くだけで、オフライン時の更新・削除・新規作成を取り扱える PWA を作成できるとのことです。 講演ではデモを中心に、オフライン対応のための機能を追加していく様子が説明されていました。

発表資料とソースコードが公開されているので、ご一読いただけると詳しいことがわかります。

Embefest Deck.pdf - Google ドライブ


以上、一日目の参加レポートでした。 よろしければ、二日目の様子もご覧ください。

tricknotes.hateblo.jp

*1:Ember 2.xまではドキュメントの不足が指摘されることが少なからずありました

*2:この考えは「Data down, Action up」と言われ、Reactが広めました

*3:徐々に TypeScript に置き換えている途中です

*4:"Conditional breakpoint" という機能で、頻繁に実行されるが一部条件でのみデバッグしたいときに有効です