やまろぐはてな

勉強会レポートとか技術メモとか戯言とか

HTML5 Conference 2017 行ってきたよ

events.html5j.org

去年 → HTML5 Conference 2016 行ってきたよ - やまろぐはてな

自分用まとめです。結構長くなった。

基本講演１「Internet for 2050」

村井 純

Webのことをやっているとインターネットがおろそかになる？

  • WIDE 2018年で 30周年
  • Root DNS Sever 20周年

13のRootサーバーはそれぞれ別々で管理しているけど、お金を出そうとしているけど村井先生は大反対 DNSを動かしているステークホルダー…TNSじゃなくてWebの人たちじゃねーの？

  • インターネットを国民が全部使えるようにしよう…インターネット基本法（2000年）
  • セキュリティ管理 … 2014年
  • 官と民のデータはみんなが共有する必要がでてきた 2016年 … Web関係者も

官民研究開発投資拡大プログラム …基盤技術でOSに予算をつけるぞ！となってる(26兆円)

1. 俺にとってのインターネット原理

The Internet is the Internet, not internet. フラグメントではない。グローバル標準なんだよ。

2. 全部の計算機資源はインターネットで最適利用できる！

最近のスマホは解像度がクソでかい → 昔のPCだとディスクが溢れちゃう → 今はサイズが最適利用されてストレージの心配がない。

3. 洗練された分散処理の理想の基盤であるべきだ。

Web2.0（サーバーとクライアントの分散処理）が理想

4. 計算速度と量に対する要求はムーアの法則どころじゃない。際限ない。

AIの計算量は誰が提供してんだよ。 HTMLで並列処理はできるのか？最適なCPUのプロセスをWebのレイヤーで出来るのか？

5. インターネット上のデータ量は無限に増えるべきだと考えるべき。

データを圧縮するってのはやりたくない。際限なくやるのがよい！

6.冗長性や補完性との切替判断というのがインターネットの命である

中央でコントロールするのは怖い

7.分散した協調運用が神。安定して、柔軟な運用は分散システムとしてのみ可能。

24h×7dを柔軟なオペレーションができるように協調性を持て！

8. システムを守ろう。人を守るのは社会がやる。

人の安全性を守るのは人が何をしているのかを知る必要がある。 暗号化にものすごいコストがかかる → システムが高価 → 人が使えなくなる悪循環

基本講演２「新しい技術潮流とWeb」

及川卓也

技術の発展の中でwebはどうあるべきか？

Hype Cycle

新しい技術が黎明期から安定するまでのサイクルについて Gartner Site

流行期 → 幻滅期（ここでだいたい落ちる）→ 回復期

  • AIは偏在するために何の技術が必要なのか？
  • Webの中で没入感を得ることができる技術とは？
  • デジタルプラットフォームに必要な技術とは？

７年前を振り返る

Google 10 I.O 1990から人々が使っているアプリケーションを振り返ってみよう

従来型アプリケーション →(2005年より)→ webアプリケーション

現在は「スマホアプリ」でしか体験できなことがある、つまり時代は戻ってしまっている。

Webも大きな岐路に立っているのではないだろうか？

AIはW3Cでは積極的議論じゃない。ただ、AIは普遍的な技術になりつつある。

機械学習＝充分なデータ＋コンピューティングパワー

↑ WEBの重要性はここにある？

人だけではなく機械にも優しいWEB設計しなければならない → セマンティック

Scheme.org、JSON-LDといった人間も読める、機械を読めることをつくる

FakeNewsとはCyber Warsの始まり？→機械で悪意のある情報を混入させることも可能ではないか？

「人と機械の組み合わせ」というのが最も最強だった時代 → 今は機械が強いのだけど。。。

今こそWebを再投資して再発明していこう！

Nintendo SwitchとWeb

スライド内容の写真撮影・SNSシェアが厳禁だったのでここに書いていいか分からんので抽象的なまとめ。

  • 割とWebの仕事していた
  • 普通にフレームワーク使って仕事してる
  • 意外なところでWeb（SPA）使っている
  • SwitchのeShopちゃんと作られてたんだな（Swicthの供給具合は除く）
  • 結構真面目な感じで改善とかしてたし、そこらへんのWeb屋よりは健全さを感じた

最近のwebパフォーマンス

@ahomu 佐藤歩

speakerdeck.com

パフォーマンスは重要？

よいに越したことはない。上司やクライアントへのどれくらい説得できるか？

KPI云々は弊社ブログを見ろ

パドーマンスに関する基本的な考え方

  • ページロード
    • ナビゲーションの開始からページが表示されるまで
    • Speed Curve（各種パフォーマンス指標）
  • ランタイム
    • ページが表示された後のUIの応答速度
      • FPSの最大化、反応の最適化（60fps）

Chrome Dev Tools – Perfomanceタブ 調査、改善については主にコレ

クライアント環境への多様性

スマホのスペック、電波環境、何をしようとしているか、どの年齢層なのか？（ペルソナ像）

→ 様々な環境下でも正しいパフォーマンスで提供できるようにしよう

Client, Connection, Network, Server Devツールとかで遅い環境でエミュレートしてみる

Performance - RAIL (by Google)

ランタイム ページロード
Response, Animation, Idle Load

ページロード

ナビゲーションを開始してリソースをダウンロードして評価、Webページを実行（ユーザが利用可能になる）できること

いわゆるクリティカルレンダリングパス

DOM + CSSOM = Render Tree

（改善例）javascriptの非同期ロードはパーサーブロックせずクリティカルではなくなる

クリティカルリソース（これがないとレンダリングできないもの）の数とサイズ

  • ページロードはネットワーク処理が重要なのか？
    • もちろん処理が早ければ重要ではあるが。。。
    • 下り平均20.2Mbps, モバイル15.6Mbps

最近の問題となるデカいJSについて

  • クライアントで色々できるようになった弊害
    • npmなどでカジュアルに依存関係がクソでかくなる
    • Webアプリやサイトにプラグインまみれ
    • 評価（Evaluate）で時間がかかることもある ← ここが割とコスト
    • SSR＋SPAでも安心できない（操作が始まるまでに時間が掛かる可能性がある）

Addy Osamani（Googleの中の人） javascript Performanceについて

トピック

  • HTTP/2
    • 並列性の工場、HPACK圧縮、サーバープッシュ
    • ただ入れるだけでは恩恵よりも問題が発生しちゃう
  • zoplfi, brotli
    • gzipよりも圧縮率が高い
  • ES Modules
    • ブラウザ上でもimport解釈しよう
    • Concat不要になりそう
    • PolymerはES Modulesと親和性を高めようとしている
  • Preload, Resource Hints
    • Preloadは現在のページのために優先ロード（webフォントとか）
    • Resource Hintsは以降のページのために投機的処理

計測と評価指標

  • Synthetic Monitoring
    • 特定環境からサイトにアクセスしてデータを収集
  • Real User Monitoring
    • エンドユーザの端末上で記録したデータを収集
    • 実際にユーザ体験した値を取得できる
  • Navigation Timing API, Resource Timing API

どうユーザ体験と直結するか？ということを指標にしている

  • First Meaningful Paint
  • First Interactive
  • Consistently Interactive

プロダクトによって本当に必要な指標はなんだろうか？

  • 予算の設定と定常的な計測
    • ピンポイントで早くするミッションが必要だけど
    • 日常的に数字を向き合って基準値を決めて軽減させるのが大事

ランタイム

シングルスレッドな世界と向き合って生きる

  • ブラウザはシングルスレッド、何がが長い処理すれば他は遅れる
  • アニメーションのための処理はキツい

メインスレッドを長々と専有するような処理を潰す（setTimeoutとかWebWorker）

2013のカンファ内容がまだ賞味期限ギリだったのでそちら参照

近年知っておきたいパフォーマンス関連のこと

開発者がこうしたいことをブラウザに伝えておくことでだいぶ改善できる

Intersection Observer（スクロール同期処理の救世主）

  • JSからのクライアウト情報に参照する際のコーディングリスクが減る

Passive Event Listerners（スクロールジャンクを軽減）

requestIdleCallback

処理すべきタスクがなく完全に入力待ちの時に発火するコールバック

CSS will Change

GPUアクセラレーションなど勝手にブラウザが最適化するマーキング

CSS COntainment

スタイル、レイアウト、描画の計測範囲を最適化するプロパティ

まとめ

  • でかいJSには気をつける
  • ページロードの計測指標を汁と何が早いかを分かる
  • ランタイムは色々とAPIが充実しているのでキャッチアップしとく
  • 調査や改善のケーススタディについては本が出るのでみてください♥ 11/23発売予定

これあえあれば大丈夫！Visual Studio Code徹底解説！

SakiHonma @sakkuru

www.slideshare.net

特徴

ここが便利！

  • シェルからウィンドウが開ける
    • code
  • 統合ターミナル
    • ウィンドウ内に複数のターミナルが開ける
    • shell(bash, zsh, powershell… )
  • コマンドパレット機能
  • Emmet標準対応
  • インテリセンスが効く
  • TypeScript強い
    • デバッカーがある
    • 左タブ「デバック」
      • Debugger for Chrome
      • launch.json（設定ファイル）
  • Project登録しておくとパネル内で複数管理ができる
  • Azureにデプロイするのが楽

Web技術とブラウザ -いま知っておくべきWeb最新動向 -

TomoyaAsai@dynamitter

slideshare.net/dynamis

www.slideshare.net

去年と今年あったこと

  • HTML5終了（提案）のお知らせ(2017/08)
  • 標準実装状況（2016/07）
  • サービスへの導入が広がる技術
  • 開発ツールの新機能はビデオで知ろう〜
  • Chrome Origin Trial
    • このサイトでこの新機能を使わせて欲しい！みたいなので開発できる
    • WebVR, Web Budget API, Generic Sensors

各ブラウザのアップデートについて

Chrome Update

（2017/01）

  • Web Bluetooth APIに対応
    • RaspberryPiで遊ぶのが良い
  • CSS position: sticky ヘッダの固定をCSSでブラウザ任せ

(2017/03)

  • CSS Grid Layoutに対応！
  • Media Session API
    • デバイス向けの機能も強化されている

(2017/04)

  • IndexedDB 2.0
  • フル画面アプリ(display:fullscreen)
  • CSS display: flow-root
    • clearfixハックとのおさらばできる

(2017/05)

  • Headless Browsingサポート
    • ウィンドウを開かないで自動処理、自動テストしてくれる。Firefoxも。
  • NotificationがmacOS標準UI
  • Image Capture API

（2017/07）

  • Paint Timing API
    • ファーストビュー、スクロール操作までが動くまでの時間をできる測定ができる
  • CSS font-display
  • WebAssembly正式対応！

(2017/09)

  • Javascript Module
  • Payment Request API
  • Web Share API, WebUSB
    • ネイティブ系の機能実装に積極的

Edge

  • お気に入りURLを変える、ドロップで変えられる
    • ユーザの声を真摯に受けて反映している
  • Webコミュニティへの貢献 SONAR
    • Linitingツール @sonarwhal/lint
    • Accessibility, Security …
  • MozillaのMDNの機能実装にかなりコミットしている
  • Payment Request API
  • Brotli
  • CSS Custom Properties
  • ePub Readerを内蔵
  • Sever Workerに対応
  • WebVR, RTC
  • レンダリングオフロード
  • etc…

FireFox Update

  • HTMLInputElement.webkitDirectory
  • FLAC音声コーデックに対応
  • HTTPページでパスワード入力警告
  • rel=nooperner
  • Quantum Compositor
  • etc…

Safari Update

  • PinterLock, Gamepad対応
  • nomodule非対応のWorkaround
  • Drag and Drop
  • Variable Fonts
  • etc…

まあまあ最近のCSSとつらくならないための書き方

矢倉眞隆@myakura

まあまあ最近のCSS

  • CustomProperties（variables）
  • 新しい色指定
  • UI系セレクタ（:placeholder-shownとか）
  • などなど

CSS Grid Layout

Gridの考え方

  • グリッドラインを縦横に引く
  • グリッドラインで囲まれた領域に要素をあてがう
.layout {
    display: grid;
    grid-template-columns: 50px 1fr 50px; /* 縦線 */
    grid-template-rows: 30px 1fr 150px; /* 横線*/
    grid-row-start: 1; /*横の配置が始まる*/
    grid-row-end: 2; /*横の配置が終わる*/
    grid-column: 1 / -1; /* 縦の配置領域ショートハンド */
}

新しいものを使った時にハマったこと

Gridは使えるか？

81.7%のエージェントが判定している → やってみる価値はある

しかし…難しい

マークアップし直す必要性

  • Grid配置で使えるのは指定した直下のみに反映
    • 外のレイアウトに作用してしまう
  • 各ブロックが直下になく、配置が難しい
    • block__innerというラッパーがある
  • それなりにフラットな構成が必要
  • ブロックにmarginがついていた
    • margin collapsingというのがある

コンポーネントとはなんだ？

  • 責任範囲は「それ自身と内側」のみによるもの
  • 外側にはタッチさせない
  • 外に作用させるとつらくなる
  • どこに置かれるものなのかを考えるのはよくない

コンポーネント指向で書く時の注意

コンポーネント指向なCSSを書く

  • 基本的に広がるスタイルを意識するようにする
  • marginもwidthもheightも指定しない
  • 配置は親のGridに任す
  • レイアウト変更は親のGrid

コンポーネントは流し込むようなもの

CodeGridのCSSメンテナンスについて

CodeGridの構成

codegrid-uiというコンポーネント管理ルール

  • SCSS使用
  • おおむねBEMで管理
  • PostCSSもプラグイン使用している
  • しかしメンテナンスが雑で事故が起きてしまった…

学んだこと

  • MediaQueryはつらい
    • 条件分岐ではない
    • 上書きするのが目的
    • 依存が容易に起こる
  • 慎重に扱わなければならない
    • 依存グラフが雑に慣れば見通しが悪くなる
    • とくにSCSSはブロック中にネストで書ける
    • カジュアルな依存がある
  • できるかぎり書かないようにする
  • modifierみたいな考え方にすると増やしづらい

バグ修正しましたが。。。

Gridで管理するように修正した

  • 格子状にならんでいるのがGridでハマる
  • MediaQueryでGridの定義を変更

Grid非対応の場合

  • 1Columnに並ぶだけ（現状IE11くらい）

まとめ

  • 縦横に柔軟なレイアウト
  • コンポーネントのレイアウトに向いている
  • Gridフレンドリーなものには使わないようにする
  • 何が負債なのか？ということを理解する
  • コンポーネントフレンドリーな定義をしていこう
  • 今後どうしたいか
    • Gridベースでcodegrid-uiに
    • code smellを検出できないか
    • 壊れたらそれを伝えてくれる環境をつくる
    • 速く！

見たかった講演スライドまとめ（順不同）

ウェブのための次世代決済法

docs.google.com

“モダン”ウェブアプリケーション 〜アメブロ5ヶ年計画〜

speakerdeck.com

React v16 and beyond React Fiber

speakerdeck.com

Web技術でネイティブアプリ開発

slides.com

The State of Web Components

speakerdeck.com

テクニックではなく、今、本気で取り組むべきWebパフォーマンス

speakerdeck.com

Deep Dive Into TypeScript

speakerdeck.com

多様なユーザーニーズに応えるフロントエンドデザインパターン 〜書籍「インクルーシブ HTML + CSS & JavaScript」より

HTML5 Conference 2017：多様なユーザーニーズに応えるフロントエンドデザインパターン 〜書籍「インクルーシブ HTML + CSS & JavaScript」より - Google スライド

SPAをパフォーマンス・チューニングした話（LT枠）

speakerdeck.com

他は自力で探してくれ。

前回同様なかなか面白い話が多かった。個人的には任天堂がやってきたというのが１番の目玉だったと思うし聞けてよかった。

まだまだフロントエンドの領域が広がってはいるものの去年よりかは理解なり知識なりもついてきており個人的には成長を感じる部分もあった。さっそく業務とか個人で活かしたい部分もあったのでその辺は行ってよかったなーと思う。やっぱりスライド観ても現地でしっかり話聞かないと流れわかんないのもあるし。

こちらからは以上になります。