by shigemk2

当面は技術的なことしか書かない

Pragmatic Front-end Developer: From Artisan to Expert #frontrend

フロントエンドエンジニアとして生きていくための戦略

@cssradar

Frontend Weekly | Facebook

リッチメディア アイディアと情熱で夢を叶える

コラボレーション

メンテナンスは欠かせない要素。

HTML CSS JavaScriptは言語の仕様的にもメンテしやすい言語ではない。

Learnablity(専門的な知識がなくても書けてしまう手軽さ)

シンプルさと寛容さが重要。

メンテナンス性ではなくどのようにコラボレーションをするかが重要。

問題は人と人の間にある。

code style guideline

最終的に一人の人間がコードを書いたように見えるべき。 Rick Waldron

(あまり新しいものではない)

rwaldron/idiomatic.js · GitHub

airbnb/javascript · GitHub

CSS Guidelines (2.2.2) – High-level advice and guidelines for writing sane, manageable, scalable CSS

JavaScript Style Guide | Contribute to jQuery

Code Guide by @mdo

いろいろなガイドラインを参考に自分のガイドラインを作るべき。

でも、ガイドラインを順守するにはツールが必要。

ツール

EditorConfig

jscs-dev/node-jscs · GitHub

CSScomb: Makes your code beautiful

CSS Lint

自動チェックって重要ですよね。大事なのはどういうコードを書いたかではなくなぜそのコードを書いたのか議論できるようにすること。

スタイルガイド

スタイルガイド - Wikipedia

  • GitHub
  • スタバ
  • MAILCHIMP

Website Style Guide Resources

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

(一度でもドキュメントを書いた人なら共感できる)

で、それを回避するためにはやっぱりツールが必要。マークダウンとかスニペットとか。

KSS · Knyle Style Sheets

kss-node/kss-node · GitHub

trulia/hologram · GitHub

スタイルガイドの中でも特にホットなツールたち。

ゴール

プロトタイプの作成を加速させる。

プロトタイプ

Build a prototype as soon as possible. (実際に動くもの、見えるものに対しての意見は言いやすい)

ツール

BrowserSync - Time-saving synchronised browser testing

JS Bin - Collaborative JavaScript Debugging

Chrome ブラウザ

  • ツールやワークフローの重要性を再認識できる。
  • コラボレーションにフォーカスする

progressive enhancement

変化と対応力 エレベーターは壊れたらタダの箱だが、エスカレーターは壊れても階段になる。

プラットフォーム ON/OFF

ウェブは変化をし続けて、柔軟性が高い。

あやふやな連続性

  • ブラウザ
  • デバイス
  • ネットワーク

たよりなく感じることは多いが、時代の変化に対応してきた。WebそのものがProgressive Enhancement。そしてフロントエンドが一番変化に対応しやすい。

戦略

  • cut the mustard

(エンハンスメントを受けられる最低限のテクニック)

cut the mustard の意味は?: ぼけ防止英単語・イディオム記録

コンポーネント単体における体験を定義する(インテグレーションテスト)

世界はどんどん変わっていく

優秀なエンジニアには共通してある特徴

  • プログラミングの哲学を持っている
  • 哲学を具体的なものに落としこむ
  • ディテールにこだわりを持つ
  • 前提条件が変わったら潔くそれを捨て去る

Webは常に変化し続ける

Web利用者の多くは単純にWebを消費するだけ。

Instead of trying to point yourself in the right direction, admit you have no idea what the right direction is, and try instead to be super sensitive to the winds of change.

Paul Graham

アプリケーションは1つの技術だけでは作れない。 どのフレームワークか、どの言語か、などを選ぶ必要がある。

→開発者の利便性に重きがおかれがち

ツールはツールごとに解決しなければならない問題が存在している。

Document & Education

  • プロダクトを継続し続ける能力も重要。
  • Webのなかでもフロントエンドは一番変化が激しいところ。
  • 可能な限り多くの環境に対応する
  • Progressive Enhancement(必要に応じた機能追加だけではなく、機能堅牢なプロダクトを作り、その堅牢さにしつこいくらい疑問を持つこと)
  • 多くの環境を持つ本当の意味(エンジニアにとっては作る力だけではなく、思いやりも重要。)

パフォーマンス

  • パフォーマンスを向上させることは義務 サーバサイド クライアントサイド

Researching the Performance costs of JavaScript MVC Frameworks | Filament Group, Inc., Boston, MA

3Gではファーストレンダータイムが1000MSの壁を超えられない。

Ember.js - Inside FastBoot: The Road to Server-Side Rendering

Isomorphic JavaScript - The future of web app development

読み込みのパフォーマンス レンダリングのパフォーマンス

reactjs/react-art · GitHub

(パフォーマンスを優先しすぎて文字の描画が出来ない)

アクセシビリティ

重要なこと

  • できないと言わず、オプションを提示する
  • 壊れ窓の中で仕事をしない(割れ窓理論)
  • 「十分」がいつなのかを知る(終わりはあるのでタイミングを知る)
  • 知識を増やすための時間を定常的に設ける
  • コミュニケーション

最後に

  • フロントエンドはこれからもWebに必要とされるのか→Yes
  • 今と同じことをしつづける必要はない(フルスタックエンジニアではないが)
  • チーム

  • コラボレーション

  • 変化対応
  • 責任
  • エキスパート
  • 思いやり(優れたアプリは技術を惜しみなく注ぎ込んだ結果)

You can't connect the dots looking forward you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something: your gut, destiny, life, karma, whatever. Because believing that the dots will connect down the road will give you the confidence to follow your heart, even when it leads you off the well worn path.

Reactive Programming in JavaScript #frontrend

@ahomu

Reactive Programming in JavaScript

CAのひと

  • What is Reactive Programming?
  • Reactive in Frontend JavaScript
  • FRP with Reactive Extensions

What is Reactive Programming?

  • プログラミングパラダイムのひとつ
  • イベントや値の関係性について着目する

手続きの記述→関係性の宣言

宣言的なデータフローをちゃんと示しているか 実装はコーディングやライブラリに依存する。

RP界隈はノイズが多い

広義や狭義が曖昧

  1. Actor Model(並列処理 分散システムの数学モデル)

アクターモデル - Wikipedia

  1. Functional Reactive

  2. もとはHaskellのライブラリ

  3. 関数型のパラダイムをとりこんだRP

  4. Reactive Manifesto

The Reactive Manifesto

  1. Reactive Streams

http://www.reactive-streams.org/

ここまではすごくふんわりしている。具体的なコードもないし。

JSでUIを操作する

APIからデータを受け取ってHTMLに反映する

だるいからライブラリを使う→Reactiveな仕組みが自然と求められる

これまでのJavaScriptのなかに見るReactive

  • Observerパターンは初歩的な解決の一つ
  • 宣言→より隠蔽して抽象化したもの
  • データバインディングは局所的なReactive(ViewとModelを宣言的に結びつける)

  • React with FluxはReactiveなデータフロー

  • 一方向のアレを実現している

Don't React - webbisauna 14

  1. コールバックヘルを避ける
  2. UIでどうにかする

  3. PromiseはClickのような離散的なイベントは扱えない

  4. Data BindingsはViewとModelを結びつける局所的なもの

非同期とか木にせずにすべて同じように扱ってなんでもReactiveに宣言したい(そのモデルは5年前からある)

→FRP

  • 関数型プログラミング+リアクティブプログラミング
  • FRPのGUI的な代表格がReactive Extensions

  • RxAndroid

  • ReactiveCocoa
  • RxJS

Rxはどんなライブラリなのか

  • すべての値や入力を非同期データストリームとしてみなす
  • 入力にmapやfilterをつかう
  • 非同期データストリームを中心につながりと処理を記述する

クライアントの処理は時間軸に沿って動く

Promise Array

非同期に複数の値がやってくる

Events as List

Promise

Array

ストリームをリストとみなすことで、関数型のイディオムを活かせるようになった。

Reactive-Extensions/RxJS · GitHub

f:id:shigemk2:20150221135649p:plain

Rx.Observable のインターフェースが中心になる

絶望の数(Observable Instance Methods)

変換処理がかかった次

f:id:shigemk2:20150221135931p:plain

(このあたりはHaskellとかScalaとかとおんなじような感じで、filterとかmapとかmergeとか)

promiseでいうチェーン

Maybe型のエラーハンドリングではなく、catchでエラーハンドリングしてる。

Rx.Observable.of(1, 2, 3)
  .map(function (x) {
    if (x === 2) throw new Error();
    return x;
  })
  .onErrorResumeNext(Rx.Observable.of(4, 5, 6))
  .subscribe(function(value) {
    console.log(value);
  });

// => 1
// => 4
// => 5
// => 6

他にもretry(やり直し)もある。

フローコントロールの用途でAsync.js と読み替える例

メソッド多いけども。

各 FRP ライブラリの概観

  • RxJS は ReactiveExtension 由来の正統派
  • Bacon.js は RxJS を参考にした独自コンセプト
  • Kefir.js は Bacon.js に似たAPIの軽量化版
  • Meteor は Tracker.js を中心にサバクラで共有できる Reactive
  • Elm は Haskell っぽいのから HTML/CSS/JS を生成する

hot observables と cold observables

See the Pen Draw Canvas (RxJS) by Ayumu Sato (@ahomu) on CodePen.

f:id:shigemk2:20150221141108p:plain

ahomu/demo-react-bacon · GitHub

See the Pen Draw Canvas (RxJS) by Ayumu Sato (@ahomu) on CodePen.

ahomu/hn-react-rxjs · GitHub

Reactive Programming in JavaScript

@ahomu / 2015.02.21 - Frontrend Final Conference

// カウンター値の保持 var current = 0;

// click されたら... plusEl.addEventListener('click', function(e) { // current を加算/減算して... current++; // innerHTML を更新する counterEl.innerHTML = current; });

minusEl.addEventListener('click', function(e) { current--; counterEl.innerHTML = current; });

// click で 1/-1 が流れるストリーム var plus = getClickStream(plusEl).map(1); var minus = getClickStream(minusEl).map(-1);

// 1/-1 のストリームをひとつにマージ var source = plus.merge(minus);

// ストリームから値が来ると現在値(current)を計算 var current = source.scan(0, function(acc, v) { return acc + v; });

// current の変更を subscribe して innerHTML を更新 current.subscribe(function(v) { counterEl.innerHTML = v; });

佐藤 歩 Ayumu Sato

Web Frontend Android Engineer
http://aho.mu
HTML5 Experts 幽霊部員

今日のアジェンダ

What is Reactive Programming?
Reactive in Frontend JavaScript
FRP with Reactive Extensions

What is Reactive Programming? イベントや値の関係性に 注目したパラダイム

イベントや値の関係性 = データフロー
データフローの宣言を元に変更を自動的に伝播させる
c = a + b なら c が示す値は a, b と共に変わって欲しい

current = accumulate(merge(plus, minus))

var plus = getClickStream(plusEl).map(1); var minus = getClickStream(minusEl).map(-1); var source = plus.merge(minus);

var current = source.scan(0, function(acc, v) { return acc + v; });

手続きの記述 → 関係性の宣言

データがどのような関係なのかに集中する Reactive なコードは 宣言的なデータフローを示す

実装はコーディング時の考え方とライブラリに依存する
OOP な言語やデザインパターンでも実現はできる
Reactive っぽい = データの関係性を宣言的に表しているか

RP 界隈はノイズが多い

いわゆる「広義」と「狭義」すら境界が曖昧
Reactive っぽさ (特に自動伝播) の手段は色々ある
各手段が Reactive を自称したりしなかったりする
ref. Reactive Porn - steps to phantasien

① Actor Model

Erlang Actor
Akka(Scala) Actor
並列・分散な処理システムにおける数学モデル
非同期な並列処理をいいカンジにする(乱暴)

② Functional Reactive

Haskell FRP Libraries
Microsoft Reactive Extensions
関数型のパラダイムを取り込んだ RP
GUI 開発で主流なのはこっち方面

③ The Reactive Manifesto

Reactive な Application の特性を述べた文書
Responsive - 反応性
Resilient - 障害耐性
Elastic - 柔軟性
Message Driven - メッセージ駆動
並列システム寄りとかインフラ向けで
フロントエンド的にはスルーしてもよさげ

④ Reactive Streams

Actor と Reactive Extensions の交差点が Reactive Streams
Node の Stream は似てるけど今の所は関係なさそう
ref. 2014 akka-streams-tokyo-japanese
ref. 非同期ストリーム処理の標準化を目指す "Reactive Streams"

Reactive in Frontend JavaScript JavaScript で UI を操作する

API からデータを受け取って HTML に反映
ユーザー入力を受け取って HTML に反映
イベントを受け取って HTML に反映

API からデータを受け取って HTML に反映

$.getJSON('http://example.com/api', function(res) { var html = ''; res.list.forEach(function(item) { html += '

  • ' + item.title + '
  • ' }); listEl.innerHTML = html; });

    ユーザー入力を受け取って HTML に反映

    buttonEl.addEventListener('click', function() { targetEl.innerHTML = 'clicked!'; }, false)

    イベントを受け取って HTML に反映

    bbView.listenTo(bbModel,'change',function(model) { view.render(model); });

    非同期で変化する状態を管理して 都度 UI に反映するコードを 書くのはダルいこと

    すごくダルい、本当にダルい Reactive な仕組みが 自然と求められる

    Reactive = 片方の変化を他方に自動で伝播する仕組み これまでの JavaScript の 中にみる Reactive Observer パターンは 初歩的な解決のひとつ

    プログラムとして動いている仕組みは同じ
    Reactive 的には Observer パターンを隠蔽して宣言したい
    かつては Reactive な在り方のひとつだったのかも(?)
    

    データバインディングは 局所的な Reactive

    何らかの仕組みで View と Model を宣言的に結びつける
    局所的だが GUI におけるリアクティブ要素のひとつ
    ref. データバインディングとリアクティブプログラミング
    

    React with Flux は Reactive なデータフロー

    データを DOM へ効率よく伝播させるのはRPっぽい
    1方向データバインディングを実現する手段の一種
    細かい異論はある: ref. Don't React - webbisauna 14
    

    人類によるこれまでの抵抗

    コールバックを避けた非同期処理の抽象化
        Promise 一族, Async.js などで平たくなるよう努める
    UI への反映を容易にする抽象化
        Data Bindings や Templating (vdom含) で雑にする
    

    Promise による非同期処理の抽象化

    // single promise.then(function(res) { andDo(res); });

    // parallel and chain Promise .all([ promiseFn1(), promiseFn2(), promiseFn3() ]) .then(function(results) { return promiseFn4(results); }) .then(function(result) { andDo(result); });

    データバインディングによる抽象化

    Search: Sort by:

    • {{phone.name}}

      {{phone.snippet}}

    しかし

    Promise (などの Flow Control)
        Click のように離散的なイベントは扱えない
    Data Bindings
        View と Model を結びつけるための局所的 Reactive
    

    非同期とか気にせず すべて同じように扱って 何でも Reactive に宣言したい

    そんな夢を叶えるモデルが、5年以上前からあります FRP with Reactive Extensions 関数型プログラミング + リアクティブプログラミング

    略して FRP (Functional Reactive Programming)
    RP が関数型プログラミングを取り入れたもの
    Event と Behavior という概念があったり (割愛)
    

    FRP の GUI 的な代表格が Reactive Extensions

    略して Rx ・ Microsoft .NET 方面の生まれ
    Haskell 方面にある元祖? FRP と C# の LINQ の子供
    JavaScript の主要な FRP ライブラリはこれの系統
    

    Reactive Extensions シリーズ

    ReactiveX/RxAndroid
    ReactiveCocoa/ReactiveCocoa
    Reactive-Extensions/RxJS
    neuecc/UniRx
    いずれも Reactive Extensions インスパイア系
    

    どのようなライブラリなのか?

    全ての値や入力を非同期データストリームとして見なす
    入力に map や filter などの高階関数で処理を適用する
    非同期データストリームを中心に、その繋がりと処理を記述する
    

    クライアントサイドの処理は 時間軸の変化に依存する

    ユーザー入力イベント
    ディスク I/O
    ネットワーク I/O
    タイマー処理
    

    ref. Functional Reactive Programming with Bacon.js 非同期データストリーム ( すべてを時間軸に沿って要素が連続するリストにする )

    Fig

    ref. Functional Reactive Programming with RxJS Events as List

    Error, Complete

    Single Value

    From Array

    Async Value

    ストリームをリストと見なすことで 関数型のイディオムを 活かせるようになった

    JavaScript は first-class function なので尚のこと RxJS

    Reactive Extensions 謹製 JavaScript 実装 セッション冒頭の RxJS サンプルをおさらい

    データストリーム (Observable) をどう扱っているか

    /* +---------------+ | click.map(1) |---> +------+--------+

              +------+--------+
              | click.map(-1) |--->
              +---------------+
    

    */ var plus = Rx.Observable .fromEvent(el, 'click').map(1); var minus = Rx.Observable .fromEvent(el, 'click').map(-1);

    / +--------------+ | click.map(1) | +------+-------+ | +----------> | +------+--------+ | click.map(-1) | +---------------+ / var both = plus.merge(minus);

    @type {Rx.Observable} curtValue

    / +--------------+ | click.map(1) | +------+-------+ | +------------+ +---------->|scan(0, add)|---> | +------------+ +------+--------+ | click.map(-1) | +---------------+ / var curtValue = both.scan(0, function(acc, v) { return acc + v; });

    @type {Rx.Observer} htmlSet

    / +-------------+ --->|innerHTML = v| +-------------+ / var htmlSet = Rx.Observer.create(function(v) { element.innerHTML = v; });

    / +--------------+ | click.map(1) | +------+-------+ | +------------+ +-------------+ +-------->|scan(0, add)|--->|innerHTML = v| | +------------+ +-------------+ +------+--------+ | click.map(-1) | +---------------+ / var subscription = curtValue.subscribe(htmlSet);

    Rx.Observable の インターフェースが中心になる

    Observable = 非同期データストリーム 絶望の数 (Observable Instance Methods)

    amb, and, asObservable, average, buffer, bufferWithCount, bufferWithTime, bufferWithTimeOrCount, catch | catchError, combineLatest, concat, concatAll, concatMap, concatMapObserver, connect, includes, controlled, count, debounce, debounceWithSelector, defaultIfEmpty, delay, delayWithSelector, dematerialize, distinct, distinctUntilChanged, do, doOnNext, doOnError, doOnCompleted, doWhile, elementAt, elementAtOrDefault, every, expand, filter, finally | ensure, find, findIndex, first, firstOrDefault, flatMap, flatMapObserver, flatMapLatest, forkJoin, groupBy, groupByUntil, groupJoin, ignoreElements, indexOf, isEmpty, join, jortSort, jortSortUntil, last, lastOrDefault, let | letBind, manySelect, map, max, maxBy, merge, mergeAll, min, minBy, multicast, observeOn, onErrorResumeNext, pairwise, partition, pausable, pausableBuffered, pluck, publish, publishLast, publishValue, share, shareReplay, shareValue, refCount, reduce, repeat, replay, retry, retryWhen, sample, scan, select, selectConcat, selectConcatObserver, selectMany, selectManyObserver, selectSwitch, sequenceEqual, single, singleOrDefault, skip, skipLast, skipLastWithTime, skipUntil, skipUntilWithTime, skipWhile, some, startWith, subscribe, subscribeOnNext, subscribeOnError, subscribeOnCompleted, subscribeOn, sum, switch | switchLatest, switchMap, take, takeLast, takeLastBuffer, takeLastBufferWithTime, takeLastWithTime, takeUntil, takeUntilWithTime, takeWhile, tap, tapOnNext, tapOnError, tapOnCompleted, throttleFirst, throttleWithTimeout, timeInterval, timeout, timeoutWithSelector, timestamp, toArray, toMap, toSet, transduce, where, window, windowWithCount, windowWithTime, windowWithTimeOrCount, withLatestFrom, zip

    via. RxJS/observable.md at master · Reactive-Extensions/RxJS

    Transforming.Map

    via. ReactiveX - Map operator

    Rx.Observable.of(1, 2, 3) .map(function(x) { return x * x; }) .subscribe(function(value) { console.log(value); });

    // => 1 // => 4 // => 9

    Filtering.Filter

    via. ReactiveX - Filter operator

    Rx.Observable.range(1, 7) .filter(function (x) { return x % 2 === 0; }) .subscribe(function(value) { console.log(value); });

    // => 2 // => 4 // => 6

    Combining.Merge

    via. ReactiveX - Merge operator

    var a = Rx.Observable .fromEvent(el,'click').map('a'); var b = Rx.Observable .fromEvent(el,'click').map('b');

    a.merge(b).subscribe(function(value) { console.log('From merged: ' + value); });

    // => From merged a // => From merged b // => From merged b

    Transforming.FlatMap

    via. ReactiveX - FlatMap operator

    Rx.Observable.of(1, 2, 3) .flatMap(function (x) { return Rx.Observable.of(x, x*x); }) .subscribe(function(value) { console.log(value); });

    // => 1 // => 1 // => 2 // => 4 // => 3 // => 9

    ErrorHandling.Catch

    via. ReactiveX - Catch operator

    Rx.Observable.of(1, 2, 3) .map(function (x) { if (x === 2) throw new Error(); return x; }) .catch(function (e) { return Rx.Observable .return(e instanceof Error); }) .subscribe(function(value) { console.log(value); });

    // => 1 // => true

    Rx.Observable.of(1, 2, 3) .map(function (x) { if (x === 2) throw new Error(); return x; }) .onErrorResumeNext(Rx.Observable.of(4, 5, 6)) .subscribe(function(value) { console.log(value); });

    // => 1 // => 4 // => 5 // => 6

    フローコントロールの用途で Async.js と読み替える例

    RxJS/comparing.md at master · Reactive-Extensions/RxJS
    これを参考にすると、フローコントロール的には分かりやすい
    

    各 FRP ライブラリの概観

    RxJS は ReactiveExtension 由来の正統派
    Bacon.js は RxJS を参考にした独自コンセプト
    Kefir.js は Bacon.js に似たAPIの軽量化版
    Meteor は Tracker.js を中心にサバクラで共有できる Reactive
    Elm は Haskell っぽいのから HTML/CSS/JS を生成する
    

    Bacon.js

    One of the main motivators for reactive-bacon has been the weirdness of RX with regard to "hot" and "cold" observables. In reactive-bacon, there are no such things. The EventStream is always consistent with respect to time, so there will be no WTFs from that direction.
    

    via. raimohanska/reactive-bacon よくわからない人もいると思うので デモを見てみましょう! Demo 1 (RxJS)

    Canvas にドラッグ操作で線を描画する RxJS でリライトしてみる

    Draw Canvas (VanillaJS) ↓ Draw Canvas (RxJS) Demo 2 (React + Bacon.js)

    ReactとBacon.jsを組み合わせて簡単なUIを作ってみる

    スライドを送れなくなったひとは、ココを click してから操作してね ahomu/demo-react-bacon

    https://github.com/ahomu/demo-react-bacon

    スライドを送れなくなったひとは、ココを click してから操作してね ahomu/hn-react-rxjs

    https://github.com/ahomu/hn-react-rxjs

    実際に書いてみた感想

    • Observable と Observer ごとにモジュール化するカンジ?
    • React + Flux の Store 周りにはいらない気がする
    • 割り切って UI コントロール用途で使うほうが幸せかも
    • Bacon.js 系のほうが昨今のフロントエンドには混ぜやすそう
    • ストリームの入出力をドキュメントで明示しないと大変
    • 高階関数の命名規則を考えたほうが可読性上がりそう

    まとめ

    • RP はデータフローの関係性を宣言する
    • FRP は非同期データストリームを扱うモデル
    • RxJS は Observable を制すれば勝てる
    • (自分は Bacon.js の EventStream/Property が好き)
    • クセはあるけど触れてみると発見があって面白い

    FRP を知るオススメ文書

    • Reactive Porn ( 最初に読むのを本当におすすめしたい )
    • なぜリアクティブプログラミングは重要か。
    • 【翻訳】あなたが求めていたリアクティブプログラミング入門
    • Functional Reactive Programming (よくまとまってる)

    Introduction to React #frontrend

    @hokaccha

    アジェンダ

    1. React.js
    2. Virtual DOM
    3. JSX
    4. Server Side Rendering
    5. Flux
    6. Flow

    React.js

    A JavaScript library for building user interfaces | React

    事例

    • FB
    • Instagram
    • Yahoo
    • Atom

    React.jsの特徴

    • ステートレスなコンポーネント設計
    • VirtualDOM
    • JSXシンタックス

    いままでだと

    • 状態がDOMにしかない
    • 拡張しづらい
    • 管理しづらい
    • テストしづらい

    backboneだと

    • Viewはコンポーネントに分けて
    • データやロジックはModelに持とう

    • 変更の適用を手で書くつらさ

    • イベント地獄
    • 薄いフレームワーク(自由度の高さは利点だけど、そのぶん実装がつらくなる)

    Angular Vue

    • 表示はすべてViewModelにもとに構築しよう
    • データが変わったら勝手に表示も変われ
    • UIが変わったらデーtあも勝手に変われ

    • コンポーネントごとに状態を持つつらさ

    • アプリケーションが複雑になるとつらい

    React

    (いろいろな問題点をどうやってReactで解決するのか)

    • データが変わったら表示も勝手に変われ

    Stateless Component

    TODO LIST

    • ステートは持っていたほうが自由度が高い
    • でもステートを持つと大規模開発になるとつらい
    • 状態を持たせないことである程度管理しやすくなる

    • テスト可能

    • メンテナンス可能
    • 再利用可能

    Statefull Stateless

    • 一番上の親のみに状態をもたせる(親からもらったデータをもとにレンダリングする)
    • 親のデータを更新して、子に反映させる

    • データを元にViewを構築

    • ユーザーのアクション

    サーバーサイドと同じ考え方。でも速度とのジレンマが存在する。親からデータを再構築するから遅い。

    →VirtualDOM

    • JavaScriptのオブジェクトとしてDOMのような構造
    • データに変更があるとどの部分を変更しないといけないか計算
    • 必要な部分だけ実際のDOMに適用する

    React.jsって早いんでしょ?

    半分正しい。

    • データの変更→更新分だけDOMに反映
    • データの変更→DOMツリーごとまるごと更新
    • データの変更→差分計算→更新分だけDOMを更新

    変更があったら書き換えるけどDOMには反映しない。

    ベンチマークを取ると、Reactが一番早い。(それがうまみ)

    Reactは設計と速度が両立できる。(簡単に設計できるのに早い)

    Virtual DOM実装

    Matt-Esch/virtual-dom · GitHub

    segmentio/deku · GitHub

    JSX

    JSX - a faster, safer, easier JavaScript

    独自シンタックス

    変換ツール

    • react-tools
    • babel

    JSX · Babel

    シンタックスシュガー実装するためだけにオレオレ実装を追加すると面倒。

    • ES6も一緒に変換するので変換コストはない
    • エディタの設定すれば恩恵が受けられる。

    Server Side Rendering

    • JSを解釈できない
    • マシンから読めない

    検索エンジンからJSって読めないよね。SEO的につらい。

    BromBone | SEO for your AngularJS, EmberJS, or BackboneJS website.

    こういうのを使うのもいいけどちょっとオーバースペックぽい

    初期表示だけサーバーでやる→クライアントとサーバでコードが重複する問題

    rendrjs/rendr · GitHub

    Rendr→からReactへの乗り換え

    Server Side Rendering

    サーバークライアントでコードを共通化できる

    reactjs/react-rails · GitHub

    Flux

    facebook/flux · GitHub

    Flux | Application Architecture for Building User Interfaces

    考え方なので実装はさまざま、

    Flux実装

    facebook/flux · GitHub

    Flow

    静的なチェッカー

    Flow, a new static type checker for JavaScript | Engineering Blog | Facebook Code | Facebook

    JSXもサポート

    コンパイル

    まとめ

    • React
    • Flux(設計手法)
    • Flow(Lintツール)

    Scalableなのが嬉しい

    小規模なものを素早く作るためのツールではない(AngularはAPIを通してごにょごにょだが、Reactは結構実装が面倒だが、そのめんどくささ(制約)を超えた嬉しさがある)

    技術選択は適切に(backbone.jsやangular.jsが適している場合もあるしjQueryが適している場合もあるので、その場にあった技術を適切に使うことが肝要。jQueryで30分で出来ることが変なフレームワークを使ったら1日かかったってなると結構つらい)

    LT #frontrend

    フィジカルコンピューティング

    フィジカルコンピューティングとは - はてなキーワード

    ドラPepper

    HTML5 - フィジカルWebアプリ「ち〜ん」をすべて公開 (WIP) - Qiita

    MIDIを使って時間ごとに音を制御

    web socket

    Componentization with Gilgamesh

    UIコンポーネント

    RIOT

    選択肢がいろいろあって迷う

    クライアントのいろいろな要求でUIを変えないといけないとき、attributeがすごいことになっている。

    →汎用性は重要だけどどこまで必要かは予測が難しい

    予期できなかったライブラリをサポートする

    sskyy/Gilgamesh · GitHub

    コンポーネントにかえる

    API Test with Service Worker

    ユースケースをやれば生き残れる

    Service WorkerとHTTP/2が切り開く新しいWeb Pushの世界 - ぼちぼち日記

    UI

    Angular.js

    新卒がGulpを現場にぶちこんだ

    なまらjQueryのバージョンが多い

    • フロントエンドの環境づくり
    • 手をかけずともクオリティを担保する
    • 木を使わずとも品質を管理する

    gulp.js - the streaming build system

    • 環境を作るのがベター
    • gulpのタスクは多いのでメンテ時間がもったいない

    Introduction to Service Worker #frontrend

    Webを取り巻く環境の変化

    ネットワークとハードウェア

    マシンスペックもすごい向上した。(PCもモバイルも)

    ネットワークはLTEと3Gで二分されている。

    ネットワークはハードウェアほど安定はしていない。

    負荷をかけるべきはネットワークではなくハードウェア。

    モバイルデバイスの普及やWeb技術の進化とともにパフォーマンスが問われる。

    High Performance Browser Networking

    オフライン時は画面が真っ白。

    1. オフラインファースト
    2. オフラインWebを実現する技術
    3. Service Worker is coming!

    オフラインファースト

    オフラインを前提にWebアプリをつくること

    2014年にはWebアプリの「オフラインファースト」が流行するのではないか? - Publickey

    そのメリット

    • オフラインでもアクセスできる
    • 積極的にキャッシュを参照するので高速
    • ネットワーク帯域も節約可能

    • 辺境や地下鉄のような環境に対しても対応できるようにする

    ネイティブの振る舞いに近づく

    • インストール時に描画リソースを確保する
    • オフライン時にも画面が真っ白にならない
    • 通信できなかったことを意識させない設計

    オフラインは機能のひとつ

    • リアルタイム性を要求されるようなアプリには不向き
    • 読む中心 即効性が不要な編集
    • アプリケーションの機能のひとつにすぎない

    →オフライン化は正義ではないが、検討は出来る。

    関連するブラウザAPI

    navigator.onLine

    window.navigator.onLine - Web API インターフェイス | MDN

    FileSystem(たぶんChromeだけ対応)

    FileSystem API について知る - HTML5 Rocks

    WebStorage

    Web Storage-HTML5のAPI、および、関連仕様

    indexedDB

    IndexedDB | MDN

    Application Cache

    アプリケーション キャッシュ初心者ガイド - HTML5 Rocks

    諸々の仕様上、設計が強制される

    onlineAPI + StorageAPI

    Service Worker

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

    JavaScript Workerのひとつ

    Service Worker の紹介: Service Worker の使い方 - HTML5 Rocks

    HTTPリクエストの検知と改ざん

    FetchAPIを使ったリソースの取得

    Fetch API 解説、または Web において "Fetch する" とは何か? - Block Rockin’ Codes

    CacheAPI

    Cache API - MoodleDocs

    なんでもかんでもpromise

    coonsta/cache-polyfill · GitHub

    バックグラウンド同期

    サーバープッシュの受信(web push api)

    Service Worker

    • 高機能ゆえHTTPSが必須(開発はローカルホストで)
    • オフラインWebのためだけ?ではない。Service Workerの元で、WebPushやバックグランド同期を実現する。

    todo

    オフラインという新たなパラダイムを受け入れよう

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

    テストしていますか?

    手動テストも含めれば基本的に何らかのテストはやるだろう

    目視でざっと見るのもテストですし。

    テストって本当に必要なの?

    当然必要だが、自動テストが必要かは場合による。

    テストとは自動テストだけではない。

    手動テストもテストとしてカウントできる。

    テスト自動化の功罪

    • 手動テストに価値がある
    • 必要以上に主導テストがdisられていないか
    • 自動化は必要だが常に良いわけではない
    • 費用対効果の検討は必要

    常に自動化がよいとは限らない(ただ、手動テストはあまり語ることはない)

    あまり意味がある気がしないんだけど

    割に合わないならやらないほうがいいが、改善は必要

    テストを特別視しすぎ

    • 開発手法やフレームワークのように費用対効果の検討を
    • 仕事でやるなら予測が必要
    • 使ったことのない手法の費用対効果を予測するのは困難(やったことがないならやめましょうは当然の判断だと思われる)

    • 最初は捨てる前提で簡単な部分から

    • 自動テストは個人でも簡単に実践できる
    • 費用、効果は開発者の技術力、経験によって違う

    • 改善していけばコストは低くなる

    • ただし、テスト技術はテストしないと身につかない

    どこまでやればいいの

    • できるところまで(ざっくりとした解答だが)
    • テストは個人のスキルに大きく依存する
    • 見極めができないならできるところまで

    UIのテストはやらないっていうけどJSはほとんどUIだよね

    • 不安がやるならUIもやるべき
    • 不安をどう乗りこなすか
    • テストとは不安と向き合うための方法である

    • UIはやらない=UIのテストは費用対効果的に難しい

    • 最近はUIのテストもコストが低くなりつつある

    今テストを書いていないところにテストを書くには

    • テストを考慮していないコードに対してユニットテストを書くのは難易度が高い
    • E2Eテストは比較的ターゲットコードの品質に依存しない

    エンドツーエンドとは 【 end to end 】 【 E2E 】 - 意味/解説/説明/定義 : IT用語辞典

    • テストの文化が根付いていない環境でテストをする困難もある
    • テストが難しい部分の修正にテストがいる問題

    JSのテストは大変

    • サーバサイドも昔は大変だった
    • UIがなくなってAPIベースになった部分も大きい

    テストの目的

    • なぜテストをするのか
    • 目的がなければやってはいけない(テストがあったほうがいいですよねじゃ解答にならないが、とりあえずこんなもんかなっていう)
    • 見栄、不安の解消

    自分の不安の解消

    • 非常に健全な理由
    • 安心できるまでやる
    • 自己満足にならないように

    他人の不安の解消

    • 繰り返していることの省力化
    • 技術ではなく信頼感
    • 便利屋にならないように
    • ただし、技術がわからない人には見えづらい

    自動テストの自動化

    • 今やっている手動テストを自動化する
    • 手順を省略したい
    • 効果を周囲に説明しやすい
    • はじめよう

    複数環境懸賞

    • さらっと流すだけでも安心感高い

    リグレっしょんテスト

    • バグが出た時だけテストを書く
    • 難易度は高い
    • 周囲の理解は得やすい
    • テスト文化の呼び水
    • 場当たり的になりがち

    ドキュメント代わり

    • 主なAPIだけ
    • 他のテストとは分離を

    知識の共有

    • チームに対する情報共有
    • ペアプロ的にやる(片方さぼっているならテストをやっていたらそれぽくみえる)
    • 知識の共有が進みやすい

    設計

    • TDD的な意味で
    • 最初は目指さないほうがいい
    • なれるまでは気にしない

    目的に注力したテスト

    • テストの目的は豊富
    • 目的にあった内容
    • みんなテストの認識が違いすぎる
    • やればやるほどよいってわけではない
    • なぜなんのためにテストをするのか
    • 他人の不安の解消のためにテストを書いても意味がない

    一般的じゃない きれいじゃない

    • 目的を達成できれば勝ち

    テストを書く文化

    • 技術的な問題より文化的な問題のほうが対応が難しい
    • すでに文化があるなら導入は難しくない
    • テスト以外にも方法がある
    • 不安の可視化
    • 不安がわからないなら周りに聞く(そもそも不安がないならテストしなくてよいのでは)
    • 本来の意味での「杞憂」を解消するためにテストをする必要はない

    テスト、事始め

    • 最初からユニットテストはおすすめしない
    • ユニットテストは自動化しやすいけど難易度がたかい
    • Assertionからはじめる
    • assertでよく止まる箇所は複雑な可能性が高い
    • 切り出してテストする
    • 出力が気になるならconsole.assertを殺す

    どこからやっていいか分からない

    • テストを書く技術を伝えることは難しくない
    • どこが不安かを認識する技術を伝えることは非常に難しい(それだけで高い技術を求められる)
    • 一般的な不安点は切り出されている
    • 残るのはどこが不安かよくわからないビジネスロジック

    無理だったら引き返してみる

    • 社内ハッカソンや勉強時間に業務コードを捨てる前提のテストを書いてみては

    テスト書いたけどなんか違う

    • テストは銀の弾丸ではない
    • テストの費用対効果は悪いことがある
    • 足を引っ張っていると思ったらすてる
    • 部分的、基盤ぶぶんを捨てないように

    そもそもの話

    • テストを書かなくていい環境はある意味ただしい
    • 複雑なところはフレームワークが隠蔽
    • フレームワークに乗っかるとテストの必要性、不安ポイントが分からない
    • 不安点を集中させてそこをテストでカバーする

    実践

    ツール

    • ユニットテストはMochaやJasmineが主流(QUnitもあり)
    • SinonJSはアレ
    • Promiseのテストパターン
    • PowerAssertの一般化
    • E2EテストはProtractorが強い
    • testiumにも期待
    • テストランナーはtestemでもいいけど規模が大きくなるならkarmaがおすすめ
    • Ismorphicな利点
    • モジュール分割してロジック分離
    • テストを別言語で書くかどうかは微妙(testだけcoffeeみたいなやりかた)

    テストと数値

    • バグの発生曲線的な
    • 難しい問題(コードカバレッジを数値として扱うのは否定的)
    • 可視化するほどでかいのをやったことない

    テストの振り返り

    • そのテストは本当に訳に立ったのか

    コードカバレッジどうする

    • 誰の不安がどういうふうに改善されるかよくわからないから微妙。
    • 数字は簡単に増やすことは出来る
    • 単純に数値が増えることで偽の安心感を得てしまわないか
    • 今このタイミングでカバーしていない部分を把握したい、という目的ならアリ。
    • でもカバレッジを増やせば品質向上につながるわけではないからCIとグラフで連携さすのは悪手だと思う

    テスト技術は重要なのか

    • テストの技術だけあってもテストは出来ない
    • 問題領域の知識は重要

    ++を使って変数に代入する話

    TypeScriptをごにょごにょしていたら、当たり前のように++に遭遇したので。TypeScriptでも++や--はJSと同じ挙動になる。

    enum_x.js

    JavaScriptプログラマと銘打っているだけあって、JSを全く知らない人を軽く門前払いしている感がある内容なのでブログにとどめておく。

    インクリメントしてるんだからyは2だと思うじゃん。思わないかもしれないけど思うじゃん。そうではないですよね。

    この本見たけどこのことは載っていないんだよね。

    こちらには書いてありました。

    演算子が変数の前にある場合、値は式が評価される前に変更されます。 演算子が変数の後ろにある場合、値は式が評価された後で変更されます。 つまり、j = ++k; である場合、j の値は k の初期値に 1 を加えたものです。j = k++; である場合は、j は j に割り当てられた後で増加する k の初期値です。

    つまり、y = x++は値が式を評価したあとで変更するんですね。以上、初歩でした。

    JavaScriptで使う演算子 - JavaScript超初心者によるJavaScript入門講座

    インクリメント演算子 (++)、デクリメント演算子 (--) (JavaScript)