🧊

Frontrend Conference！ #frontrend

いってきたメモシリーズ。
聞いたのは以下のセッション。

  • Pragmatic Front-end Developer: From Artisan to Expert
  • Reactive Programming in JavaScript [js]
  • Introduction to React [js]
  • Lightning Talks [css]
  • Introduction to ServiceWorker [js]
  • Evaluating CSS [css]
  • Styling Atom (Editor)

そんなにメモってないですが一応。

Pragmatic Front-end Developer: From Artisan to Expert

敷居の低い技術だからこそ

Every line of code should appear to be written by a single person, no matter the number of contributors.

というわけで、

などなど使っていくべき。

技術よりも、いかに人がコラボレーションしていくかを考えるべき。

Be (an) EXPART

できないと言わない(オプションを示す)

エンジニアができないと言うと、まわりは信じるしかない。
そこにつけこまないように。

壊れ窓の中で仕事をしない

目に見えるバグや、すぐ手の届く不具合はすぐに直すように。

「十分」がいつなのかを知る

永遠にバグはなくならない。
そのタイミングや割り切りの間隔を養うように。

知識を増やすための時間を定常的に設ける

現状に甘んじることなく。

がんばらねば。

Reactive Programming in JavaScript [js]

Reactive Programming in JavaScript

Reactiveとは

イベントや値の関係性をデータフローとみなし、
そのデータフローの宣言を元に変更を自動的に伝播させていくパラダイム。

曖昧な概念で、まぎらわしいものも多いので注意とのこと。

RxJS

スライドのサンプルコードの考え方がわかりやすかった。
Observableなストリームを宣言して、Observerでsubscribeして処理する。

アホほどメソッドがあるのが流行らない理由の一つらしいｗ
デモのコードはすぐ理解できるくらいの簡単なものなんやけど、その先がってことなんやろな・・・。

いかんせん概念からかなり理解しておかないとシッチャカメッチャカなコードしか生まれてこなさそうで、そういう意味でこの手のものは使うの難しそうやなーと思った。

ちなみに、ReactiveにやるならBacon.jsってのがオススメらしい。

Bacon.js - Functional Reactive Programming library for JavaScript

Introduction to React [js]

Introduction To React // Speaker Deck

React.js

ステートレスなコンポーネント設計ができるのが一番の利点。

  • jQueryではもちろん無理で
  • Backbone系ではある程度できるが手動になる
  • Angular/Vueなら双方向だが、規模が大きくなるとスケールしない
  • そしてReactにたどり着く

速いけど、最速ではない

例えばとある配列を元に表示してるリストがあって、各アイテムを追加/削除/変更するようなシーン。

  • [1] Backboneでそれぞれイベント貼って対応
  • [2] Backboneでまとめてイベント貼って対応
  • [3] Reactでまとめてイベント貼って対応(だが更新はVirtualDOMで差分だけ)

って場合、最速なのは[1]、次点で[2]。
というように、差分を再計算する分だけもちろん遅くなるので、
コードの煩雑さと、速さのバランスを見極めた上で選択するべきもの。

つまるところ、技術選択は適切に。

Lightning Talks [css]

CSS3 プロパティを使ってなにか作ります

CSS3のfilterを組み合わせたサービスの話。
PCでは割と使えて、便利よねfilter。

CSS Polyfill Preprocessor

segmentio/myth

どせいさんめっちゃ背高かったw

position: fixed;を上手に飼う方法

ちゃんと挙動知った上で使っても、環境によって変な動きするので、
注意深く使おうねっていう内容。

全くその通りやー。

5分でわかるflexbox

  • 擬似要素もFlexItemとして扱われるので注意
  • テキストノードしか持たないFlexContainerに注意

あの記事の人や！

flexboxの旧仕様、改定仕様、現行仕様の一覧 « LINE Engineers' Blog

Yet Another CSS Preprocessor

morishitter/YACP

ほーって思ったけど、使うの難しそう。

Introduction to ServiceWorker [js]

ユーザー環境

  • ハードウェアは順調に進化
  • ネットワークはあと一歩足りてない

負荷をかけるならハードウェアのほうが、パフォーマンスにつながるのでは。

オフライン向けAPIたち

  • Navigator.onLine: ほぼ使える
  • FileSystem: Chromeでしか実装されてな・・
  • WebStorage: 同期型のKVSで、5MBまでの少量向け
  • indexedDB: 非同期型のKVSで、5MBまでの少量向けだが、トランザクションやバージョニングなど
  • ApplicationCache: 割愛

ServiceWorker

  • サーバーに代わってレスポンスを返したり
  • クライアントに代わってリクエストしたり
  • Fetch API
  • Cache API
  • Background Sync
  • Web Push API

Service WorkerとHTTP/2が切り開く新しいWeb Pushの世界 - ぼちぼち日記

ただ実装状況が今んトコまだまだ・・。

TODO: 時間の配分的にこのへんの内容は薄かったので、後で調べること。

Evaluating CSS [css]

CSSをEvaluateする

定期的にリファクタしても、じわじわ容量は増えていくもので、
ファイル容量を継続的に監視するとわかりやすい。

効率的なCSSが書きたいなら、デザインからやらないとダメ。
つまるところシステムをデザインしていくべき。

StyleStats

t32k/stylestats

他にもいろいろあるけど、定量的にCSSを評価できるのでぜひ参考にしたいところ。
知らん間にネスト深くなってたりするもんね。

こういうのを定期的にプロットしていくためのサービスとかもあるそうな。

kaelig/moniteur

他にも色々思う所あり、今日一番のセッションだったなーと思います。
同じような悩みを持ってる人がいるもんなんやなーとちょっと安心しました。

Styling Atom (Editor)

Atomはプレゼンアプリでした。
というのはさておき、Atomの中でどうHTML/CSS/JavaScriptが組まれてるかを、実際にさわりながら説明してくセッション。

  • ファイルの配置構造とか
  • 変数名とか
  • hslでテーマ作れば値ひとつで明暗まとめて処理できるとか
  • クラスのカスケードの考え方とか
  • コンポーネントのマークアップとか
  • なんでBEMとか使ってないかとか

細かいとこが意外に参考になりました。

肝心のAtomは、Vimに慣れきってしまった今すぐに移行したいほどのものではないかなー。

おわりに

無料Coffee/紅茶にすごい質/量なプレゼンに感服する一日でした。
もちろん某社だけではないけど、
あれだけの人数があれだけの次元でWebのコト考えられる会社すげーなー。

ちがう某社にも頑張っていただきたいところやー。

めも: ランチの予定いれるの忘れないようにする