Date : 2015/02/24 (Tue)

Frontrend Conferenceに行って来ました。

久しぶりにHTML5やJavaScriptの事が学べて楽しかったです。

自分なりに理解がしたくまとめます、セミナー以外で聞いた内容も書いてます。

webがシーラカンス状態だったと以前セミナーで聞いたのを思い出したけど、もう4年前の事だった…

歴史の積み重ねのスピードに本当に驚く

CSSも聞きに行きたかったんですが、動くのが面倒でずっとJavaScriptの部屋にいました(‘・_・`)

Pragmatic Front-end Developer: From Artisan to Expert

• HTML,CSS,JavaScriptは、専門的な知識が無くても手軽に書けてしまう
• メンテナンスがしやすいとは言えない
• 多くの開発者が居ても1人で書いたように見えるコードを意識する
• 言語そのものが変わろうとしていて、方法論やツールも存在する

コードスタイルガイドライン

Javascript

• IDIOMATIC.JS
• JQUERY CORE
• AIRBNB

CSS

• IDOMATIC.css
• Sass GuideLine

HTML

• Code Guide

問題は人と人の間にある

運用の継続

• スタイルガイドに沿ったコードを継続させるためのツール
• EDITORCONFIG
  • エディタをまたいでフォーマットを統一(改行コード、文字コード、インデント
  • プログラムを正しく動作させることにのみ特化(補完辞書やカラーリングなどは共有しない
• JSCS
  • コードスタイルに特化したLINT
  • JQERY COREなどに対応
  • エラーチェックする内容が細かく設定でき、自社のコーディング標準に合わせたチェックも出来る
• CSS LINT
• CSS COMB
  • 整形ツール
• 大切なのはコードレビューの自動化
  • レビュー時間にコードスタイルのチェックを含めさせない
  • なぜその実装、コードを書いたのかに対しての議論に集中させる

ドキュメンテーションは嘘をつく

• ドキュメントの運用を継続させるためのツール
• スタイルガイド生成ツール
  • KSS
    • ここから色々なツールが増えて行った
  • KSS-NODE
  • HOROGRAM
• ドキュメンテーションは変化が激しくそこを補うためにツールを使う
• コードのコメントを書きそこからドキュメンテーションを生成する
• PROTOTYPE
  • ソフトウェア開発の哲学
    • プロトタイプを早く作る
    • 実際に見えるもの、動くものに対して意見は言いやすい
  • TOOL
    • BROWSERSYNC
    • 複数ブラウザに動作を反映できる
    • エミュレータも可
    • JS BIN
    • CHOROME CANARY

変化に対し寛容に

• プログレッシブエンハンスメント
  • エスカレーターは普段自動に動くが壊れて止まっても階段として機能する
  • webはプラットフォームではなく連続性がある
• CUT THE MUSTARD
  • GRADE COMPONENTS NOT BROWSERS
    • コンポーネント毎にブラウザ判定し体験レイヤーを分ける
  • コンポーネント単体における体験の定義
• PERFORMANCE
  • ISOMORPHIC JAVASCRIPT
    • isomorphic
  • REACT-CANVAS
• 壊れ窓理論
  • 壊れ窓の中で仕事をしない

Reactive Programming in JavaScript

Reactiveプログラミングとは

• オブジェクト指向、関数型などのプログラミングパラダイムの一つ
• イベントや値の関係性に注目したパラダイム
• RP界隈はノイズが多い
• ActorModel
  • 並列分散処理システムにおける数学モデル
• Functional Reacitive
  • 関数型のパラダイムを取り込んだRP
  • GUI開発で主流なのはこっち方面
• Reactive Manifesto
• Reactive Streams

Javascriptに落とし込む

• JavaScriptでUIを操作
  • 非同期で都度反映するコードを書くのは怠い
  • Reactiveな仕組みが自然と求められる
  • これまでのJavaScriptに見られるReactive
    • Reactive・・・片方の変化を他方に自動で伝播する仕組み
    • Observerパターンは初歩的な解決の一つ
      • Reactive的にはObserverを隠蔽して宣言したい
    • データバインディングは局所的なReactive
    • React with FluxはReactiveなデータフロー
  • これまでの抵抗
    • promise・・・クリックの用に離散的なイベントは扱えない
    • データバインディング・・・viewとModelを結びつけるだけの局所的Reactive
• FRP・・・すべて同じように扱いなんでもReactiveに
  • 関数型プログラミング + Reactiveプログラミング
  • Reactive-Extensionシリーズ(ライブラリ
  • RxJS
    • 全ての値や入力を非同期データストリームとして見なす
      • ストリームをリストと見なす事で関数型のイディオムを生かせるように
    • mapやfilterなどの高階関数で処理を適用
    • 非同期データストリームを中心にその繋がりと処理を記述
    • クライアントサイドの処理は時間軸の変化に依存する
• RxJSサンプルおさらい
  • ストリームの定義
  • ストリームをマージ、一つのストリームになる
  • ストリームから値がくるとcurrentを計算
  • currentの変更をsubscribeして更新
• まとめ
  • RPはデータフローの関係性を宣言
  • FRPは非同期データストリームを扱うモデル
  • RxJSはObservableを制すれば勝てる
  • Bacon.jsおすすめ
• hot,coldを理解する

Introduction to React

• React.js
  • facebook製のライブラリ
  • viewを担当するライブラリ
  • ステートレスなコンポーネント設計
  • VirtualDOMの採用
  • JSXシンタックス
• VirtualDOM
  • jQuery
    • 状態がDOMにしか存在しないのは拡張がし辛い
  • Backbonjs・・・イベント地獄
  • Angular,Vue
    • コンポーネント毎に状態をもつつらさ
  • React
    • コンポーネントに状態を持たせない
    • 親にだけステートを持たせる
    • 子には極力持たせない、全て親から貰いレンダリングさせる
    • 親が子に変更を反映させる
    • サーバーサイドと同じ考え方
      • データを基にviewを構築
      • ユーザアクション
      • まるっとデータを更新しviewを再構築
      • 速度とのジレンマ
  • VirtualDom
    • JSのオブジェクトとしてDOMのような構造をもつ
    • 差分とれ必要な部分だけ実際のDOMに適用ができる
    • Reactは設計と速度が両立できる
      • Backboneで部分的再描画 564ms
      • Backboneで全て再描画 5,877ms
      • Rect 1,837ms
• JSX
  • 仮想DOMに対応しているテンプレートエンジン
• Flux
  • 設計手法
  • データの流れが一方通行
• Flow
  • 型解釈
  • 高機能lint

Lightning Talks

• UIコンポーネント
  • Gillgamesh
    • Jsフレームワークを拡張するライブラリ
      • 予期できなかった必要な汎用性を助けてくれるライブラリ
      • Anglurが対応
• API Test with Service Worker
  • Service Worker
    • ローカルプロキシ不要でJSで完結するテストの実現

Introduction to ServiceWorker

• Webを取り巻く環境の進化
  • オフラインファーストとは
    • オフラインを前提にWebアプリを作る事
    • 環境に対してサポートできる
    • リアルタイム性を要求されるアプリには不向き
  • オフラインWEBを実現するための技術
  • ネイティブの振る舞いに近づく
• navigator.onLine
  • オンラインかどうか取得
  • online/offlineイベント
  • ブラウザサポートもほぼ完了
• FileSystem
  • 大きなサイズのファイル保存向け
• Web Storage
  • セッションストレージ、ローカルストレージ
  • 少量のデータ前提
• indexedDB
  • Key-Value形式でデータを保存
• Application Cache
  • マニフェストにキャッシュを定義
  • キャッシュを細やかにコントロールできない
• Service Worker
  • ローカルプロキシのようなもの
  • HTTPリクエストの検知と改竄
  • FetchAPIを使ったリソースの取得
  • CacheAPIを使ったキャッシュの管理
  • バックグラウンド同期(Background Sync
  • サーバープッシュ受信(Web Push API
• Fetch API
  • リソース取得の新たなAPI
• Cache API
  • キャッシュのコントロールができる
• Background Sync
  • バックグラウンド同期
• Web Push API
  • webでもpush通知可能に
  • HTTPSが必須
    • 開発はローカルホスト
    • 配信はSSL前提

JavaScriptテストの疑問、お答えします。

• 手動テストにも価値はある
• 費用対効果の検討は必要
• 不安だと思う所をテスト対象にする
• テストとは不安に対向するための手法
• テストを考慮していないコードに対してユニットテストを書くのは難易度が高い
• E2Eテストフレームワーク
  • ターゲットコードの品質に依存しないテストが可能になる
• テストを書く文化
  • 技術的な問題より文化的な問題のほうが対応が難しい
  • すでに文化があるなら導入は難しくない
  • 最初は不安の可視化から
  • その不安を解消するための対応をする
• MochaかJasmineから始める
• テストランナーはtestemで始めるのが簡単だけど、でかくならならkarmaがいい

Styling Atom (Editor)

• Atom Shell
• GitHub製のエディタ
• Atomの見た目はCSSで変更できる

まだ書き足りないところは多くあるんですが、(理解不足のところ調べたい) 一旦ここまでにします.また追記します

RxJSとRect、VirtualDomは一度実際触れておきたい