ドラマ版 ツイン・ピークス を見た

Diary

デヴィッド・リンチの作品を何か見たいな、ということで、5月から続編が始まるツイン・ピークスを見た。
ドラマの放送は自分がちょうど生まれた頃にやっていて、小学生の頃、軽部アナがめざましテレビで映画版を紹介しているのを見た記憶がぼんやりとある。何となく惹きつけられた。

ツイン・ピークス ゴールド・ボックス アンコール [DVD]

ツイン・ピークス ゴールド・ボックス アンコール [DVD]

物語は田舎町で起きた美少女の殺人事件やそれに連鎖して発生した事件を解決するために FBI 捜査官ががんばる話。登場人物のキャラの濃さ、森の不気味さ、オカルト・まじないの要素が混ざって良い塩梅で面白い。
特にカイル・マクラクラン演じるクーパー捜査官のキャラが良い。あまりに美味しそうにドーナツを食べたり、ブラックコーヒーを飲むものだから、ダイエット中なのにも関わらず、僕もドーナツを食べて、熱いブラックコーヒーで流し込みたくなる。

全体的に面白いのだけど、海外ドラマあるあるで終盤はかなりグダグダ。ラストも「えー」というかんじになる。ここらへん映画編も踏まえて、続編できれいに再構築してくれるんじゃないかな、と期待している。

Vuex でのエラーの扱いについての個人的な考え

Design JavaScript Flux Vue

最新の dex.fm — Development at Mercari US で、Redux でのエラーの扱いについての言及があって、自分は Vuex (Redux インスパイアな Vue の状態管理ライブラリ)でどうやっていたっけな、というのを文章で簡単に書いておきます。あくまで個人の考えです。

予め、Vuex の Action は、Redux の Action とは異なることを書いておきます。Vuex の Action は、純粋な State の変更を行う前の非同期や副作用が伴う処理を指し、純粋な State の変更は Mutation でおこなっています。Redux での非同期処理の扱いについて書かれた ReduxでのMiddleware不要論 - Qiita の記事の ActionDispatcher に近いものです。

Vuex でのエラーの扱いに関しては

コンポーネント内で閉じるか否かによる

この一言に尽きます。

Vuex のドキュメントでは、ひとつのコンポーネントに閉じている State について、以下のように述べています。

Vuex を使うということは、全ての状態を Vuex の中に置くべき、というわけではありません。多くの状態を Vuex に置くことで、状態の変更がさらに明示的、デバッグ可能になりますが、ときにはコードを冗長でまわりくどいものにします。状態の一部がひとつのコンポーネントだけに属している場合は、それをローカルの状態として残しておくとよいでしょう。あなたは、トレードオフを考慮した上で、あなたのアプリの開発ニーズに合った決定をすべきです。

自分もこの考え方に賛成で、Vuex に限らず Flux アークテキチャを適用した場合、ひとつのコンポーネントに閉じている State は無理に Store で管理しなくてもよいのでは、と考えています( 複数のコンポーネントに跨った State になるときに Store へ移せばよい)。

エラーに関しても、State と同様に考えます。厳密に単方向のデータフローを守り、エラーが発生した際に Action を Dispatch するか、Mutation を Commit すれば、上記のドキュメントの引用と同様の利点がありますが、エラーが画面に表示されるまでの処理がまわりくどいものになる場合もあります。

Vuex の Action でエラーが発生したことを Action を Dispatch したコンポーネントだけが知ればよい場合は、コンポーネント内でエラーハンドリングをおこなえばよいのではないでしょうか。Vuex の Action Dispatch は Promise オブジェクトを返すインターフェイスになっているので、以下のように catch メソッドでエラーをハンドリングできます。

this.$store.dispatch('fetchSomeData').catch(() => {
  // alert を出す or コンポーネントのステートを変更する
});

Action でのエラー発生を複数のコンポーネントに跨って扱う、State を変更する場合は、Action 内でエラーハンドリングして、さらに Action を Dispatch するか、Mutation を Commit する形になるでしょう。その後、変更された State を適切なコンポーネントで扱います。

おわり

デヴィッド・リンチ監督作品 マルホランド・ドライブ を見た

Movie

見た。

マルホランド・ドライブ [DVD]

マルホランド・ドライブ [DVD]

デヴィッド・リンチの映画を見たことがなくて、色々な人におすすめを聞いたら、全員が真っ先におすすめしてくれた映画がマルホランド・ドライブ。

この映画を何かに例えるならば、スルメ。最初見たとき「え？？？」となって、2回目に「こういうこと？」、3回目になって「なるほど」となっていく。見れば見るほど味が出てくる不思議な映画。最初は意味不明に感じていたシーンも2回目、3回目と何度も見ることで、その意味がみえてくる。
この映画の醍醐味は、解説の類は最大限読まずに、何度も繰り返し見て、自分なりのストーリーや解釈を生み出すことといえるだろう。解説記事を読んでしまうと、意味不明に感じていたシーン全てに明確な理由(とされているもの)があることを知ってしまい、次に見たときは退屈に感じてしまう気がする(リンチもこの手の行為を嫌っていることを後々知った)。

映画の根底にあるのは、ハリウッドの闇や劣等コンプレックスのこじらせで非常に挑戦的(だからか、アカデミー賞は取れなかった)。解説の類は最大限読むべからずと言ったばかりではあるのだけど、あえてヒントを与えるとすれば、以下の3点をあげたい。

  • おかしなこと、大げさなこと、都合がいいことが起こるのは、どこ？
  • 客観的に解釈してはいけない
  • 日本で公開されたときのキャッチコピー「わたしのあたまはどうかしている」は非常に的を得ている

最近読んだ本 2017/02

Book

大きな魚をつかまえよう―リンチ流アート・ライフ∞瞑想レッスン

大きな魚をつかまえよう―リンチ流アート・ライフ∞瞑想レッスン

レッスンというより、デヴィッド・リンチのエッセイ集というかんじだった。
瞑想中に現れたキラリと光るアイディア同士を繋げたり、音や光を駆使して昇華させていく、彼独特の映画・ドラマ作りの方法が垣間見えて面白い。
デヴィッド・リンチの作品をひとつも見たことがなかったので、ツイン・ピークスを見つつ読んだのだけど、見ているときに本で言及されている内容に意識が向きすぎてしまったから、見終わってから本を読めばよかったなぁ、と反省。

ツイン・ピークス ゴールド・ボックス アンコール [DVD]

ツイン・ピークス ゴールド・ボックス アンコール [DVD]

「無知」の技法 Not Knowing

「無知」の技法 Not Knowing

「無知」と聞くと一般的に不安・不安定といったネガティブなイメージがあるが、この本では有名なエピソードを通して「逆に知っていることの危険性」、「既知と未知の境界」、「未知との向き合い方」を紹介し、無知との正しい付き合い方を示してくれる。
エピソードとそこから得られる教訓の話が繰り返され、具体的にどのようなアクションを取るべきかを示すことはないと感じていたのだが、本の最後の APPENDIX にまとめられていた。

究極の思考術―あなたの論理思考力がアップする「二項対立」の視点15

究極の思考術―あなたの論理思考力がアップする「二項対立」の視点15

「必要性と許容性」、「形式論と実質論」のような二項対立から議論・思考する方法を紹介している。 会社の会議の場面や夫婦喧嘩が例に出てきて、単純に読み物として面白く、各対立軸をエピソードに紐付けて頭に入れることができる良さがある。
普段の日常の会議でも、議論がうまく噛み合っていないな、と感じることがあって、そう感じた時に一度整理・仕切り直しをするための道具として使えそう。 読んだらすぐに使える道具な一方、紹介されている対立軸に囚われる危険性も感じたので、自分で対立軸を作ることや、時には対立軸を外して考えることも意識したい。

Visual Studio Code で使っているプラグイン 2017/02

VSCode

バンバン入れて、後で「おれ、これなんでいれたんだっけ…?」となりがちなのでメモ。基本的にプラグインあんまり入れない派です。

Browserify が生成したファイルを webpack で扱おうとしてハマった

JavaScript Webpack

webpack で Browserify で生成されたファイル( shim library )を import して生成されたファイルを実行したら、require を呼び出しているところで実行時エラーになった。

ファイルに require が含まれていて、それを webpack がパース(依存関係を解決)しようとしたのが原因のようなので、ドキュメントの https://webpack.js.org/guides/shimming/ と https://webpack.js.org/configuration/module/#module-noparse に書かれていた module.noParse オプションでパース対象から外して解決した。

Browserify に限らず、他のモジュールバンドラで生成したファイルでも起こりそうな気がする。

WHYから始めよ! を読んだ

Book

読んだ。

ＷＨＹから始めよ！―インスパイア型リーダーはここが違う

ＷＨＹから始めよ！―インスパイア型リーダーはここが違う

Why から始め、その次に How や What を示すことの重要性を説いた本。 読んでいて気になったところを何点かメモ

  • Why → How → What の流れは、脳の内から外への思考の流れに一致している。この形で伝えると納得や共感を得られやすい
  • How や What だけを訴えかけても成功しない、アーリーアダプターに対して Why を伝えることで共感を求める
  • マイクロソフトやアップルを引き合いに出し、成功した企業には、創業者に Why と How それぞれを担う人物がいると主張する。どちらか片方だけではうまくいかない
  • 創業者が去ったり、企業が急成長し How や What に悩殺されることで Why が失われるケースが有る。Why や共感を扱う脳は言語化ができないから、それを引き継がせることが難しい