@jxck
これまで
主戦場
Apps: 90% Mobile: 10%
- Native/Low API
- Installable
- Performance
- Permission
- Offline
- etc
演算処理は JS だけだとキツイ
意図的に出来ることを減らしている
モバイルはネットワークに左右される
Low レベルの API をブラウザから叩ける -> 2015 年くらいの話
The Extensible Web
Sandbox 化して安全に使う
- Infra
- Streams
- Encoding
- URL
- Fetch
- Web Bluetooth
- WebUSB API
- Credential Management Level 1
- Payment App API
これらの一つに Service Worker
https://mozaic.fm/episodes/17/service-worker.html
Offline Support の為ではない
隙間を埋めるためのもの
もう一つのプラットフォームを提供するもの
- Proxy (キャッシュの保存など)
- Pusher
- TaskManage
ネットワークが回復してもバッテリーが切れるかもしれない。
あくまでもネットワークの有無だけで判断してはならない。 - Worker
onmessage
変更箇所以外はキャッシュ
それ以外は Service Worker
onfetch -> fetch() -> article (get() & merge -> Cache API) -> respondWith() (Browser Cache)
Window や Tab とはまったく違う
https://blog.jxck.io/entries/2016-04-24/service-worker-tutorial.html
一クライアントに一つしか動かないが、レスポンスにヘッダを付けるだけで、3rd Party の Service Worker が扱えるようになる
Push 用、Sync 用、Proxy 用など、サブドメインを用いることでサービスを分けることが出来る。
Build APK then Install
Web アプリが Android アプリとしてインストール出来るようになる。
manifest ファイルが必要
fetch
Service-Worker-Navigation-Preload: true
リクエスト投げて、並行して Service Worker を立ち上げて、よしなに処理をする
大きい音声ファイルをダンロードすると、Service Worker が寝ることがある。それを防げる
- A2HS
- WebAPKs
- Background Fetch
- Silent Push
- QR Code Scan
- Web Share
- Origin Trials v2
- 2F-Auth
「Platform as a ServiceWorker」
@1000ch
少し前はスタイルガイドがあったが、何を解決すれば良いのか本質的に見えてなかった
コンポーネントとは一体何なのか
Web クライアントサイドにおけるコンポーネント?
最終成果物の価値を左右し得るもの
- コンポーネントの管理手段の問題
- クライアントサイド実装の溝問題
- コンポーネントを実現する上での技術問題
HTML+CSS で作成するスタイルガイドはどうなのか
コンポーネントドリブンはデベロッパ向け
https://github.com/kmerc/sketch-import-symbols
協働のためのデザイン思考の再構築
http://www.yasuhisa.com/could/article/ddd-ooux-job/
エンジニアは部品単位で作り上げていく
デザイナーは実装を理解し、エンジニアはデザインを理解せよ
HTML+CSS にはスコープがない
CSS はスコープがなく、脆く壊れやすい言語
- 可搬性がない、これに尽きる
- CSS 設計は最低限のスパゲティ対策にすぎない
CSS は設計を工夫してもデザイン次第で破綻する
CSS ファイルを import で参照する
.style {
color: red;
}
import styles from "./style.css";
element.innerHTML = '<input class="${styles.className}">';
jss も似た様な物
- スコープの実現
- Custom Elements による要素の再定義
- コンポーネントはソフトウェアの品質に関わる
- スタイルガイドで顕在化した問題
- クライアントサイド実装に関わる人の協力が不可欠
- 職能同士の歩み寄り at 現場
- 一方通行な開発にならないための説得材料の提示
- 先人に学ぶ
- 説得材料の交換
- お互いの作業を小さく分担
- ステークホルダーとの合意形成
- デザインシステムを評価する精度
- 組織やプロジェクトのブランディング
- 現場手動の草の根活動
- 手法・フレームワークの導入
Atomic Design
http://bradfrost.com/blog/post/atomic-web-design/
@hiloki @cssradar
保守しやすく
拡張しやすい
CSS におけるリファクタリングは難しい
- UI の変更頻度と変更速度
- 影響範囲の広さ
- テストを書くことが難しい
ROI...?
常にリファクタリング
どのタイミングでリファクタリングするのか?
-> 機能実装前、バグ修正時
コメントを残す
不吉な匂い
https://csswizardry.com/2012/11/code-smells-in-css/
1, 3, _, _, _
1, 3, 5, _, _
3つぐらい待ってリファクタリングしよう
命名規則を変えるのはリファクタリングの範疇ではない
その規則に沿って居ないならリファクタリングする必要あり
継続的にリファクタリング
技術的負債の返済時
リファクタリング中はそれだけをする
問題は小さく砕いて解決する
Atomic Design
元のソースコードは消さない
リファクタリングの対象になるセレクタに対して接頭辞を付ける
例) .RF_*
[class*="RF_"] {
all: initial;
/* ... */
}
情報共有は重要
ドキュメンテーション≠スタイルガイド
技術的負債のご利用は計画的に
技術的負債≠古いコード
技術的負債≠汚いコード
戦略的で、意識的な『ショートカット』
短期的な目標だけではなく中長期的な視点を持つ
負債を明確にする設計
2013年
schame.css
by Harry Roberts
コメントを確実に、そして詳しく記載する
- コードベースの何処に関連しているのか?
- 何故必要だったのか?
- どうやって問題を解決しているのか?
- 負債返済の条件
命名規則:
._ (アンダースコア)
(ちゃんと)
コメントを残す
@kyo-ago
今回の話は、E2E テストではなく、Integration テスト
SPA のテストに WebDriver は向かない
Selenium から発展したツール
2004 年から開発
歴史ある E2E の鉄板ツール
SPA を WebDriver でテストしにくい
通常の開発ツールとは違う
JSON Wire Protocol
Node context と Browser context の分断
Driver によっては Developer Tools と競合
console.log の内容が terminal でしか確認できない
Object の中身が分からない
SPA の場合、これらのツールが使えないのは非常に難しい
WebDriver はクリックや待機などの動きを持つ
SPA では通常これらの機能は使用しない
SPA の Integration テストには karma
もともとは AngularJS のテスト用だったが、汎用的に使えるツールとなった
まだまだ開発は活発
Protractor とは違う
ブラウザ上で動く Unit テストランナー
Ver 1.0.0 で追加された機能の紹介
customContextFile
テストを指定された HTML 上で行う機能
%SCRIPTS% に karma.conf.js の File が展開される
まるでサイト上で Unit test を走らせているかのように書ける
読み込み場所がローカルホスト
実際テストしたいドメインで読み込まれるわけではない
- 通信の書き換え
Local proxy を使う
$ npm install --save-dev karma-proxy-plugin
- 通信の向け先の変更
base 要素でやればよい
- Referer を書き換えたい
- Cookie を書き換えたい
- リダイレクト先を変更したい
@yomotsu
three.js
大きなコミュニティが有り盛ん
ドキュメント、サンプルが多い
簡単な書き方
Low レベルの API にアクセス出来る
リビジョンで管理されている
gc がトリッキー
色んなレンダリングを止める
three.js のサンプルをまま動かすと、絶えずレンダリングしている
更新があるときだけレンダリングさせるのがベター
本当にレンダリングが必要かどうかをフラグ管理する
不要な draw call を止める
テクスチャをまとめる
WebGL inspector
CPU から GPU へテクスチャデータを送リ続ける
なので、テクスチャデータをまとめる
(この辺りあまり聞いてなかった)