ぷーたんの日記

たまに書く。

frontrend 行ってきた。

こちら。初めて行くけどfinalとのこと。
こういうの聞きに行くと勉強不足が身に染みるんですが、モチベーションが上がるので老体に鞭打って参加して来ました。
jsセッションとcssセッションとあってjsだけ見てきたのでそれらをまとめます。
たまに話を飛ばすのはバグではありません、私の仕様です。



基調講演 by 斉藤 祐也

スライド

どんな人が書いても、一人で書いたようになるべき

js, css, html のスタイルガイドやツール、ガイドラインを公開している企業など。

実際に見えるもの、動くものに対しての意見は言いやすい

だからプロトタイプで見せよう。

  • tools

変化に寛容に

  • Progressive Enhancement
    • エスカレーターって、壊れて動かなくなっても階段として機能する（これな）
  • Cut The Mustard
    • jsで特定のobjectの有無で判定するあれ
  • コンポーネント単体でぷろぐれっしぶ

優秀なエンジニアの共通点

  • 哲学を持っている
  • 概念を形にできる
  • ディテールにこだわる
  • でも前提条件が変わればそれも捨てられる

どこが正しいかじゃなく、流れを感じて変化を読み取るのが大事。
好奇心は猫を殺すかもしれないが，フロントエンドエンジニアは救うかもしれない。

Be Expart

  • できないと言わない、オプションを提示する
  • 割れ窓の中で仕事しない
  • 「十分」がいつなのか知る
  • 知識を増やすための時間を定常的に設ける
  • コミュ力

専門性を発揮できる人は自分以外の領域についてもよく知っている

未来に先回りして点と点を繋げて見ることはできない、君たちにできるのは過去を振り返って繋げることだけなんだ。だからこそバラバラの点であっても将来それが何らかのかたちで必ず繋がっていくと信じなくてはならない。 -- Steve Jobs

eny keywords

  • isomorphic javascript
  • Webは絶えず変化し続ける

感想

よくわからなかったのも多いから徐々に調べて勉強しよ




Reactive Programming in JavaScript by 佐藤 歩

スライド

what is

イベントや値の関係性に注目したパラダイム
RPはデータフローの関係性を宣言する

  • Actor Model
    • 非同期な並列処理をいいカンジに説明するモデル
  • Functional Reactive (FRP)
  • The Reactive Manifesto
    • Reactiveなアプリケーションの特性をまとめたやつ
  • Reactive Streams
    • 非同期ストリーム処理を標準化しようというもの

Reactive in Frontend JavaScript

FRP

  • Reactive Extensions（RxJS）
    • FRPなライブラリシリーズ（js以外もあるよ）
    • 全ての値や入力を非同期データストリームとして見なす
    • 絶望するほどの数のインターフェイスがある
      • 要点を絞ればなんとか使える
        • transforming.map 流れてきた値を変換する
        • filtering.filter 流れてきた値でOKなものだけ通す
        • comvinaing.merge ２つの流れをマージ
        • transforming.flatmap 変換して流す
        • catch エラーをつかんだら新しい値を返す
  • 他にもあるよ
    • Beacon.js
    • Kefir.js
    • Meteor
    • Elm

おすすめ文書

感想

シーケンス図的な形でロジックを組み立てるものっぽい。
ブラウザの動きを当てはめやすい -> 形にしやすい -> 読みやすくメンテしやすいコードが書ける、といった具合？

あとライブコーディング的動画が良かった！




Introduction to React by 外村 和仁

スライド

react.js

fbが作ったライブラリ（フレームワークじゃない）

特徴

ステートレス

  • jQuery
    • 状態がDOMにしか無い。拡張性がないしメンテしにくい。
  • Backbone.JS
    • Viewをコンポーネントに分けて、データやロジックをModelに持つので少しましになる。
    • が、相互作用関係を全部手で書く必要があって管理しきれなくなる。
  • angular
    • コンポーネント（ディアクティブ）ごとに状態を保つと辛くなる。
    • アプリケーションが複雑になると辛くなる。
  • react だと
    • ステートレスコンポーネント（コンポーネントがデータを極力持たない）
    • これで、テスト、メンテ、再利用がしやすくなる
    • 一番親だけに状態を持たせる、親からの情報をもとに子が処理をする

virtual dom

途中の処理は仮想DOMで、最後に必要な部分（差分）だけをレンダリングするようにして速度を速くする

server side rendering

  • jsを解釈できないマシンから読めない（SEO的な）
  • 初期表示だけサーバーでやって、更新をjsにわたす
    処理を重複させないように、初期表示もjsを使ってサーバーでやる

flux

  • 設計手法（考え方）の一つ
  • 末端のDOMのイベントがルートのステートを変更するという話をしたが、そこで使うのがFlux。

flow

  • すごい高機能なlint
  • babelのほうがいいかも

まとめ

  • scalableだよ
  • でも小規模速攻型じゃないよ（めんどくさい、大規模向け）
  • これみて勉強したらいいよ

感想

statelessの考え方は良さそうだった。RPじゃなくても使えそう。
flexについては別途調べる。




Introduction to ServiceWorker by 泉水 翔吾

スライド
モバイル化してきてるから、通信量抑えたり、オフラインでもいけないとね

オフラインファースト

オフライン前提のwebapp

  • ○
    • ネットワークより高速（キャッシュだから）
    • ネットワーク、サーバー側を圧迫しない
    • オフラインやネットに繋がりにくいところ（地下鉄とか）でも使える
  • ×
    • リアルタイム性は弱い

実現する技術

  • navigator.online
    • オンラインの判定、イベント
  • filesystem
    • 大きなファイル保存、非同期型、chromeだけ
  • webstrage
    • key-value、少量データ保存の同期型API（〜5MB）
  • indexedDB
    • key-value、少量データ保存の非同期型API（〜5MB）
  • Application Cache
    • マニフェストファイルでキャッシュを定義する
    • 動的ページは苦手、いろいろ制約がある
  • service worker
    • やっと主役

service worker

高機能なローカルプロキシ

  • httpリクエストの検知と改竄
    • httpリクエストを勝手に返せる
  • fetch API
    • xhrより低レベルのリソース取得API
    • サーバーからデータを取ってきたりする
  • Cache API
  • Background Sync
    • オンラインの時だけイベント発生する
  • Web Push API
  • httpsが必須
  • chromeとff、androidなら使えるよ

感想

リアルタイム性が求められないところではどんどん取り入れていったほうがよさそう。 対応ブラウザが狭いから業務では使えないかな。。。




JavaScriptテストの疑問、お答えします。 by 吾郷 協

スライド

  • テストは必須、どこを、どこまで、自動化するかを考える

Q: どこまでやればいいの？UI以外？
A: 不安ベースでやる。不安なところは書く。UIのテストはいけない訳ではなくコストが高いだけ。

Q: どこからはじめれば？
A: E2Eテストの自動化からが入りやすい。Unitテストはコードの品質に依存して難易度があがるため。

目的を持ってテストを書くべし

オススメの目的

  • 自分の不安
    • 安心できるところまで、自己満にならないように。
  • 他人の不安
    • 信頼感が大事
  • 手動の自動化
    • テスト準備の自動化でもいい、効果も説明しやすい。
  • 勉強、趣味、見栄
  • 複数環境
  • リグレッションテスト
    • バグが出た時だけテストを書く
  • ドキュメントの代わり
    • 主なAPIだけ、細かく書き過ぎない。他のテストとは分離する。
  • 知識の共有として
  • 設計として（TDD的）

目的にあったテストをしよう（目的を明確化させる）
手法はどうあれ、目的を達せられれば勝ち。

テストを書く文化

  • 技術より文化がない方が導入が大変
  • 最初は不安の可視化から

事始め

  • assertから
  • よく止まるところはあぶない -> 切り出してテスト

無理しない

  • 少しずつやる
  • 無理だったら引き返してもOK（基盤は残す）
  • 費用対効果もちゃんと見る

ツール

  • mocha or jasmin 合わなければ QUnit
  • powerAssert
  • E2EはProtractorが強い、testiumにも期待
  • ランナーはtestem、大きければkarma
  • Isomorphicなコードはテストしやすい

テスト振り返り

  • そのテストは本当に役にたったか？

コードカバレッジ

  • ただカバレッジを出すのはニセの安心感でごまかすモチベーションになりうる
  • 未テスト部分の把握にはいい

感想

現実的な視点でのテスト導入についてが語られてて良かった。 どういった不安を解消するためにやるのか、ちゃんと考えたい。



体力的に限界を迎えたのでここで帰宅しました。。。

話題のReactについても聞けたし、他のも大変興味深かったです。
勉強せねばー