今日はInside Frontend #1に参加してきた。
一般枠の抽選に当たる気がせず「ブログ絶対書く人枠」で参加したので、後回しになる前にちゃんとブログを書いておく。※受付の時、スタッフの方に「ブログ絶対書くマンですね!」と言われて変な声が出た
- イベント自体の感想
- 印象に残ったセッションの話
が主です。途中休憩してて、聞けなかったAMA(Ask Me Anything)とかもあったので満遍なく書いたりはしません。
イベント自体の感想
普通に最高でした!!
セッションの内容も良かったのだが、AMAのブースが特に楽しめた。 「GitHubのIssueに登壇者の方への質問を事前に挙げておき、それに順番に答えてくれる」という流れで話が進むのだが、参加者側にとってはイベントに参加している感覚が増すので、非常に新鮮だった。登壇者の方との距離感が近かったのも、良かった。
issueはここから見れる。今回は質問を投稿出来なかったので、次回があればその時は積極的に質問を投げてみようと考えている。
イベント本編とは話が逸れるが、トイレの設備が充実していたのが地味にありがたかった。尿意を堪えながら個室前に並ぶ・・といった苦行をせずに済んだのは、精神衛生上良かった。
印象に残ったセッションの話
今回は以下のセッションを聴いた。
セッション
- 「Web over ServiceWorker」
- 「Web フロントエンドにおけるコンポーネント化のアプローチ」
- 「アメブロ2016: 実録、アメブロフロントリニューアル275日」
- 「データビジュアライゼーションの作り方」
ServiceWorkerの話が個人的にツボだったので、そこ多めの感想文になります。
Web over ServiceWorker
普段からブログを参考にさせて頂いてるJxckさんの話をきくことに。資料はこちら。
Webがモバイルネイティブに対して、どういうアプローチをしていけるかという話から始まり、ServiceWorkerがどういった役割を果たしていくのかという流れの内容だった。箇条書きで纏めたメモを以下に載せる。
Web VS moblie
- スマホを見ている時間が圧倒的に長いが、いつもブラウザを見ているわけではない。
- アプローチするために出来ることが、まだ足りない。アプリとWebは、元々用途が違うので当然といえば当然の話。
- ネイティブに勝てない部分はあるし、何でもかんでも出来るわけでもないし。
- 動作の基本がJSなので、演算能力も低い。
- メモリやファイルに好き勝手アクセスできるわけではない。セキュリティとかあるし。
- Webはネットワークにつながってナンボ。
- APIを安全にSandbox化していけば、もっと出来ることが増えるんじゃないか?
- ローレベルなAPIを、ブラウザから叩けるようにしようという流れが2015年くらいから出来てきた。
現在では、色々な事が出来るようになってきて、アーキテクチャの整備も進んできた。 (「色んな事」は資料に載っていました)
ServiceWorker初期のモチベーションは、mozaic.fmを聴こう。 mozaic.fm かな?
OFFLINE
- ServiceWorkerはオフライン対応をするための手段、という雰囲気が初めはあった。
今では、Webが出来ていない部分を埋める物になりつつあるらしい。
cacheAPI
- cacheAPI経由で取得しておいたキャッシュがあれば、ネットワークにリクエストを飛ばさずにコンテンツを返す。
- キャッシュの設計はなかなか難しいらしい。
PUSH通知。ブラウザの右上に出てくるアレ
TaskManager
- タスクの同期を、オフライン⇒オンラインになったタイミングで同期してくれる。(onSync)
- 空気を呼んでくれるイベントだが、「闇雲にsyncする」のは良くない。
proxyによるリクエストの効率化を図り、SPAと同じようなユーザー体験を実現
- proxyのライフサイクル
- Androidのadd home screen(ホーム画面に追加) でのapk化
- Navigation Preload
リクエストを投げた後に、ServiceWorkerの起動を待つ機能。レスポンスが遅くなるのを割けるための施策。 ⇒Facebookが追加した機能。
とりあえず、ServiceWorkerの中級者向けのチュートリアルをやって感覚を掴もうと思う。
Web フロントエンドにおけるコンポーネント化のアプローチ
資料はこちら。資料に説明があるので、僕が感じた感想だけ書きます。
個人的にはスタイルガイドを作る意味はあまり無いんじゃないかと最近思ってます。スタイルガイドを作って保守するコストはやはり高いので、それに見合う価値や、解決したい課題がなければやらなくていいのではないかと。
今関わっている事業ではデザイナーさんは画面のデザインに集中、フロント開発者側は設計と運用を担保する感じになっている。CSS in JSを使っているから上手くやれている気もするが。
アメブロ2016: 実録、アメブロフロントリニューアル275日
資料はこちら。
React + Redux + Node.jsという、今の自分と近しい感じのアーキテクチャだった事もあり、開発ブログは以前から読ませてもらっていた。パフォーマンス改善のための計測や改善を地道に続けていく姿勢には、頭が下がる。
プロダクトリニューアルをする場合の教科書的な立ち位置にしても良いんじゃないだろうかと、個人的には思う。
データビジュアライゼーションの作り方
資料はこちら
日経Visual Dataの開発者の方のお話でした。D3.jsの本質とか、バッドノウハウ等を色々聞けたので、メモを載せておく。
D3.jsについて
- Data-Driven Document
- チャートライブラリではない。
- 学習コストが高いと言われているが、そもそもの誤解がある。
D3の公式ライブラリのサンプルは色々凝りすぎているので忘れてしまおう。あんな凄いものをサクッと作れるわけがない。
実装の際にはSVGを使うことが多い。
D3が肩代わりしてくれること
- エレメントやデータのリレーション管理
- トランジション
- 様々な計算
データを元にエレメントを操作する機能と、トランジションや計算処理など最低限の機能のみを提供してくれる。データが膨大になっても、問題無く使える。
しかし、ブラウザ間の動作差異を埋めてくれる機能は元々ないので、開発者側が意識する必要がある。
z-index
svgにはz-indexが無いので、重なり順の制御が出来ない。
折り返さない問題
HTMLと違い、SVGには折り返しという機能が無い。 ⇒レスポンシブに対応するためには、リサイズの度に再計算が必要になる。
- textはtspanで括る。
- scale()やviewBoxを上手く使う。 ↑で対応が可能な場合もある。
SVGをPNGに変換する
「画像としてDLしたい」要望が結構あったので実装する必要があった。 「SVGをラスタライズ」など、方法はいくつか考えられるが、何でもフロントエンド側でやろうとしない方が良い。
まとめ
データビジュアライゼーションは、地味で泥臭い作業が非常に重要になってくる。
D3は数学的な処理を肩代わりしてくれるだけで、ロジック部分はちゃんと考えないといけないし、マルチブラウザ対応も自力で頑張らないといけないしで大変そうな印象を受けた。
業務で必要な場面が今のところ無いから、触るのはまだ先になりそうな予感。
反省点
やっぱり、AMAに質問を書けば良かったなーと反省。せっかくの機会だったので、もっと挑戦的になるべきだった。 AMA部分の話もメモっているんですが、殴り書き過ぎたので、別のエントリーで纏めるかもしれません。
スタッフの方々、本当にお疲れ様でした。ありがとうございました。