kitak blog

Kみたいなエンジニアになりたいブログ

デヴィッド・リンチ監督作品 ストレイト・ストーリー を観た

観た。脳卒中で倒れた兄に会いにトラクターで560kmを移動したアルヴィン・ストレイトというおじいさんの実話を基に作られた映画。

ストレイト・ストーリー リストア版 [Blu-ray]

ストレイト・ストーリー リストア版 [Blu-ray]

アルヴィンを演じるリチャード・ファーンズワースの輝きに満ちた目、透明感のある声で発される演技は、まるで本人が演じているのではないか、と思えるぐらい役にハマっている。
道行く先々で出会った人々との交流で、アルヴィンの頑固な性格が出てくるのだけど、「あぁ、こういう頑固なおじいさんいるよね! でも、こういう頑固さ、嫌いじゃない。真っ直ぐだ」という気持ちになる。

音楽はデヴィッド・リンチと多くの作品でタッグを組んでいるアンジェロ・バダラメンティ。全体を通して、アルヴィンを表現しているような清廉な音楽が流れていて、これがとても素晴らしい。サウンド・トラックを買いたい。

兄のライルを演じるのは、TWIN PEAKS Fire Walk With Me でも印象的な演技をしていたハリー・ディーン・スタントン。兄と再会するシーンは最後の数分でセリフもほとんどないのだけど、このシーンのアルヴィンとライルの顔の表情や息遣い、声の出し方、そのひとつひとつから目が離せない。
ライルは、弟のトラクターに目線をやった後、徐々に目に光るものが溜まっていく。言葉は少ないけれども「遠いところからあんなものでわざわざ俺に会いに来てくれたんだなぁ。あぁ、泣きそうだ。だが、弟の前で泣くのはみっともない、我慢だ」という心の声が顔の表情だけで伝わってくる。
アルヴィンも数十年確執のあった兄との再会で、確執のあった人物と邂逅するときに誰もがそうなりそうな、少し居心地が悪そうな、目線を兄の顔からさりげなく外した絶妙な演技をしている。 その後、ふたりが目線を上に移した後、星いっぱいの夜空に映像が切り替わり、ふたりがこれからどんな話をするのか観ている人間に想像を膨らませてのエンディングロールとなる。

全体的に話の進み方はゆっくりで、正直途中でダレそうにもなるのだけど、観終わった後になんとも言えない余韻が残る。この余韻を楽しむために、定期的に観ることになりそうだ。

雪花の虎 を読んだ

読んだ。

上杉謙信が女性だったら、そんな大胆な仮説に基いて書かれた漫画。登場する資料だけでは、実際に女性だったとする根拠としては薄いけれど、漫画の設定としては面白い。

浦沢直樹の漫勉の東村アキコ回( 東村アキコ | 浦沢直樹の漫勉 | NHK )では、この作品を扱っているので、見た後に読むと「あー、あのとき描き直していたやつだ」「あのとき一発描きしていたやつだ」みたいな楽しみ方ができるのも良かった。

RxJS を使って、Vuex のようなものを書いた

散歩していたときにふと思いついたので書いてみた。

Vuex のゲッター、Vue の算出プロパティの実装は Observer パターンが適用されているので、Observer パターンが根底にある Rx で上手く実装できるんじゃないかな、という思いつきだったんですが、思いの外、簡単にできました。 ステート、算出プロパティ(ゲッター)、アクション、ミューテーションを一通り実装していますが、アイディアの検証レベルで書いたものなので、算出プロパティの依存関係を明示的に指定しないといけなかったり等、細かいところは色々違っています。

const Rx = require('rx-lite')

class ReactiveProperty {
    constructor(state, name, initialValue) {
        this.subject = new Rx.BehaviorSubject(initialValue);
        this.changed = this.subject.skip(1);

        Object.defineProperty(state, name, {
            get: () => {
                return this.subject.getValue();
            },
            set: (val) => {
                this.subject.onNext(val);
            }
        });
    }
}

class ComputedProperty {
    constructor(store, name, dependencies, getter) {
        this.subject = new Rx.BehaviorSubject(getter(store));
        this.changed = this.subject.skip(1);

        Rx.Observable.combineLatest.apply(null, dependencies.map(function (dep) {
            return dep.changed;
        })).subscribe(() => {
            this.subject.onNext(getter(store.state));
        });

        Object.defineProperty(store.computed, name, {
            get: () => {
                return this.subject.getValue();
            }
        });
    }
}

class Store {
    constructor(options) {
        this.state = {};
        this.computed = {};
        this._actions = options.actions;
        this._mutations = options.mutations;

        this._properties = {};

        for (let name in options.state) {
            this._properties[name] = new ReactiveProperty(this.state, name, options.state[name]);
        }

        for (let name in options.computed) {
            let computed = options.computed[name];
            let dependencies = computed.slice(0, computed.length - 1).map((name) => {
                return this._properties[name];
            });
            let getter = computed[computed.length - 1];
            this._properties[name] = new ComputedProperty(this, name, dependencies, getter);
        }
    }
    dispatch(action, payload) {
        return new Promise(() => {
            return this._actions[action].call(this, {
                commit: this.commit.bind(this),
                state: this.state
            }, payload)
        });
    }
    commit(mutation, payload) {
        return this._mutations[mutation].call(this, this.state, payload);
    }
    watch(name, callback) {
        return this._properties[name].changed.subscribe(callback);
    }
}

const store = new Store({
    state: {
        firstName: 'John',
        lastName: 'Smith',
        amount: 10
    },
    computed: {
        fullName: ['firstName', 'lastName', function (state) {
            return state.firstName + ' ' + state.lastName;
        }]
    },
    actions: {
        increment: function (context) {
            return new Promise(function (resolve) {
                setTimeout(function () {
                    context.commit('increment');
                    resolve();
                }, 1000);
            });
        }
    },
    mutations: {
        increment: function (state) {
            state.amount += 1;
        }
    },
});

store.watch('firstName', function (name) {
    console.log('firstName changed:', name);
});

console.log(store.computed.fullName); // John Smith
store.state.firstName = 'Bob';
console.log(store.computed.fullName); // Bob Smith

console.log(store.state.amount); // 10
store.commit('increment');
console.log(store.state.amount); // 11

process.on('exit', () => {
    console.log(store.state.amount); // 12
});

store.dispatch('increment');

最近の仕事では Vue や Vuex を選択することが多く、今のところはある程度うまくいっていると感じているんですが、プロジェクトの数年先を考えて、Vue や Vuex が担っていることを因数分解して、他の何かで置き換えることができないか、といった思考実験や検証をちょいちょいおこなっています。 今回は(RxJS に依存してはいるんですが)Vuex を何か他のものに置き換えることはできるか、というところで上のようなコードを書いてみました。

かくかくしかじか を読んだ

読んだ。

東京タラレバ娘海月姫東村アキコの伝記的な漫画。高校時代から始まり、漫画家としてデビューするまでの絵の「先生」との交流を描く。

作者の中身を全て曝け出すような心理描写と「先生」が繰り返し発する「描け」というメッセージに心が揺さぶられた。

Vue.js のリストレンダリング( Virtual DOM 実装 )と相性の悪いデータの変更

この間、現場で直面したやつの個人的なメモです。対象のバージョンはこの記事を書いている時の最新バージョン v2.3.0。

以下のようなリストレンダリングをおこなうコンポーネントがあるとして、

<script>
export default {
  name: 'list',
  data() {
    return {
      items: [1, 2, 3, 4, 5]
    };
  }
}
</script>

<template>
  <ul v-for="item in items" :key="item">
    <li>{{ item }}</li>
  </ul>
</template>

items のサイズの上限を 5 として、新しいデータを追加したい場合は古いデータを削除することとする。
例えば、items [1, 2, 3, 4, 5] に 6 と 7 を追加する場合、items は [3, 4, 5, 6, 7] になるが、Vue.js の Virtual DOM 実装は以下のような diff/patch を適用する。

  • 新しい vdom の先頭の 3 が古い vdom にないか探し、見つかったので 3 のアイテムの DOM 要素をリストの先頭に移動させる(ここで key 属性の指定が効いている)。4, 5 も同様。
  • 6 は無いので、新しく DOM 要素を生成して追加する。7 も同様。
  • ここまでで 3, 4, 5, 6, 7, 1, 2 と要素が並んでいる。1 の要素は不要なので削除する。2 も同様。

以上で、新しいデータが Real DOM に反映された。このロジックは updateChildren 関数 (vue/patch.js at v2.3.0 · vuejs/vue · GitHub) に書かれている。上から下に読んでいくと分かりづらいので、上記のようなサンプルを用意し、DOM に Breakpoint を設定して実際にコードを動かしながら処理を追っていくと読みやすい。
本来であれば、1, 2 をそれぞれ変更して末尾に移動させるのが最も効率が良いはずだが、リストの最大サイズ + 変更のあった件数分 の DOM 操作が必要になる。リストの最大サイズが増えれば増えるほど、時間がかかる。

自分の場合は、最大サイズがそれなりに多かったのと、データの更新頻度が多く、Script の処理が増えて、fps がかなり低下してしまった(Timeline で調べたら、updateChildren 関数が Script 処理の 80% 以上を占めていた)。結局、この部分は直接 DOM 操作をおこなうことにした。Virtual DOM は、大体のケースである程度うまくいくが、このように極端なケースではうまくいかない。

ちなみに、フォームで何かを入力してボタンを押したらデータを1件追加する、あるいはリストから1件アイテムを削除するといったよくあるケースの場合は DOM 操作が 1 回で済むようになっている。

ウェブアプリのパフォーマンスに対する共通の捉え方を持つ

最近、一緒に仕事をしている企画者に「ブラウザAでページBを開いたら重かったです」と言われたことがあって、そのときに思ったこと。

「重かったです」と言ってくるということは何か良からぬことが起きている気がするけれど、それだけだと何が起きているのか、何が問題なのかがよく分からないので、以下のような質問で原因で探っていく。

  • ページの表示が遅いのか
  • 操作(スクロールやクリック)の反応が悪いのか
  • アニメーションが滑らかでないのか

このような質問をしていて思ったのは、ウェブアプリのパフォーマンスに対する捉え方を啓蒙したり、互いに共通の捉え方を持つといいのかもしれない、ということ。例えば、上記の質問は、自分が知っている RAIL というパフォーマンスモデルに基いて行った質問だった。RAIL はウェブアプリのパフォーマンスをユーザーの体験から4つの側面で捉えたモデルで具体的な内容は RAIL モデルでパフォーマンスを計測する  |  Web  |  Google Developers の解説が詳しい。

一度、こういったパフォーマンスモデルを共有しておけば、以後は冒頭のようなやりとりがスムーズにおこなうことができる。また、エンジニア同士でも「とりあえず改善しました」系の PullRequest がなくなり、RAIL のどの側面でコードを具体的にどのように修正したかが明らかになる。それにより、コードレビューが行いやすくなったり、なんとなくな改善を手当たり次第におこなうことが無くなるのではないだろうか。

date-fns に乗り換えて、スクリプトのファイルサイズを削減した

題の通り。

Browserify を使ったプロジェクトでファイルサイズを大きくしているライブラリを探す - kitak.blog で moment がけっこうな割合を占めているということを書いたのだけど、少し前に moment から date-fns に乗り換えて、ファイルサイズを削減できた。

moment がオブジェクトから日付操作などの様々なメソッドを呼び出すことができるのに対し、date-fns は 日付に関係するユーティリティ関数が集まったライブラリといえる。

例えば、date-fns でふたつの日付が同じ週か調べる場合は以下のようになる。

import isSameWeek from 'date-fns/is_same_week'

const result = isSameWeek(
  new Date(2014, 7, 31),
  new Date(2014, 8, 4)
)

日付操作の関数を必要に応じてインポートするので、Browserify, Rollup, Webpack のようなモジュールバンドラを利用した場合に、ブラウザの JavaScript エンジンで実行される(本当に必要な)コードだけバンドルされる。 自分が担当しているプロジェクトだと moment をバンドルした場合と比べて、900k 程度削減することができた。

もし、moment を使っていて、ほんの一部のメソッドしか使用していない、かつファイルサイズを削減することに意義のあるプロジェクトなのであれば、date-fns への乗り換えを考えてみてもいいかもしれない。

また、自分でライブラリを作る際に、(moment のようにオブジェクトのI/Fにする方が適切なケースもあるかもしれないが) date-fns を参考にして、モジュールバンドラフレンドリーなライブラリにできないか考えてみてもいいかもしれない。関数毎にファイルを分割したり、Tree Shaking が効くように ES2015 の Named export でモジュールを定義する、等など。