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 を一番最初に説明するのが通例でした

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

第2回 URLと画面表示(RoutingとTemplates):実践入門 Ember.js|gihyo.jp … 技術評論社

がんばります。

Crevo 開発チームの勉強会で gem の探し方についてお話しました

ここ 1年半くらい Crevo の開発チームにお世話になっているのですが、先月から週イチで勉強会をすることになりました。 ここでは持ち回りで何かしらの発表をすることになっていて、今日はぼくが当番の日でした。

ということで、自分が gem を探す時のやりかたをお話させてもらいました。

こう、しれっと自分のプロダクト紹介するのはじわじわきて楽しいですね。