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

見た。

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

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

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

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

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

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

最近読んだ本 2017/02

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

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

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


「無知」の技法 Not Knowing

「無知」の技法 Not Knowing

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


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

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

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

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

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

Browserify が生成したファイルを 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から始めよ! を読んだ

読んだ。

WHYから始めよ!―インスパイア型リーダーはここが違う

WHYから始めよ!―インスパイア型リーダーはここが違う

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

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

VISA デビットカードを使ったら口座残高が通知されるようにした

VISA デビットカードを使ったら口座残高が通知されるようにしたので、個人の技術的な備忘録。

三菱東京UFJダイレクトのページの操作を自動化して、口座残高を調べる - kitak.blog の続きにあたります。ざっくりこんなかんじです。

(あらかじめ、VISA デビッドカードを使ったら Gmail のアドレスにメールが来るようにしておく。これは三菱東京UFJダイレクトのページで設定できる)

  1. IFTTT の Applet で Gmail で指定のアドレスからメールが届いたら、VPS のウェブサーバーに HTTP リクエストを送るようにする
  2. ウェブサーバーでは、前回の記事で紹介した Python スクリプトを実行して、口座残高を取得する(スクレイピングに時間がかかってタイムアウトすることがあるのでジョブキューに投げる)
  3. LINE Notify で残高を通知する

IFTTT

Gmail のアドレスにメールが届いたことを検知するには、Push Notifications  |  Gmail API  |  Google Developers に書かれている方法でできそうだったけれども、Cloud Pub/Sub API とか諸々のお膳立てが面倒なかんじだった。
他に何か良い方法は無いかと考えていたら、IFTTTGmail の Trigger があったのを思い出したので、調べたら、ついでに Maker Channel (https://ifttt.com/maker) というものがあるのを知った。HTTP リクエストを Trigger にしたり、Action で HTTP リクエストを実行してくれる。名前から分かるように、Arduino とか Raspberry Pi みたいなデバイスと連携するためにできた機能っぽいんだけど、既存のウェブサービスと自作ウェブサービスの連携が捗る神機能な気がする。けっこう前からあるようだけど、大昔に TwitterEvernote の連携をして以来 IFTTT を使っていなかったので知らなかった。

LINE Notify

取得した口座残高は LINE Notify ( https://notify-bot.line.me/ja/ ) で通知させることにした。LINE 版 ikachan。
HTTP リクエストを実行すれば、LINE のグループに通知を送れる。シークレットトークンの発行も簡単。

自作ウェブサービス周り

  • VPSVultr の東京リージョンを借りた
  • IFTTT からのリクエストを受け付けるサーバーは Flask で書いた。Flask を使うにあたって Home · yoshiya0503/Flask-Best-Practices Wiki · GitHub とか GitHub - be-hase/ghe-line-notify: LINE Notify Gateway for Github Enterprise. を参考にした
  • 口座残高の取得にけっこう時間がかかるので、ジョブキューに投げることにした。使ったジョブキューのモジュールはシンプルそうな RQ
  • 教養ぐらいのつもりで Docker (Docker Compose) を使って動かすことにした
  • 手元で作った Docker image を EC2 Container Registry に push して、VPS で pull して使う。ECS 使わんの? と思われそうだけど、あれも使いたいこれも使いたいとなって AWS 沼に嵌っていきそうな気がしたのでやめた。あと、リハビリとして、VPS いじりをしたい気持ちだった
  • 手元で開発を行っている環境と同じ環境を簡単に構築できるので、Deploy はすんなりいった。ただ初めてやることが多かったので、Deploy までのお膳立てがけっこう大変だった
  • (自分しか使わないサービスだから別にいいんだけど) Container の監視どうしようかな、と思って、色々調べたら、Datadog を使うのが楽そうだった。Docker integration で 走っている Container の数を監視して、減ったら通知するようにした。通知は Webhook integration で、口座残高と同じく LINE Notify を使った

というかんじで、口座残高が通知されるようになった。ブラウザで動く JavaScript ばかりしばらく書いてて、色々アレになっている部分があるので、今年はこういう個人のお金まわりのウェブアプリを書いてリハビリをする予定。

MPEG-2 TS の PCR のメモ

MPEG-2 TS パケットのヘッダーをパースするプログラムを読んでいたら、PCR というキーワードがでてきたので調べた。個人的なメモ。

PCR の説明は デジタル映像の「アーカイブ&デリバリー」に関する技術情報サイト|mpeg.co.jp > VIDEO-ITを取り巻く市場と技術 が分かりやすかった。PCR は Program Clock Reference の略で、送信機と受信機の時刻を同期するための基準となる時刻。

それを基準に PTS (Presentation Time Stamp) と DTS (Decode Time Stamp) を計算する。前者は再生する時刻で後者は復号する時刻。

以前、仕事で特定の動画を再生したままにして数十分ぐらい放置するとパツンと止まることがよく起きていたのだけど、仙石浩明の日記: 地デジ MPEG-2 TS の PCR/PTS/DTS ラップアラウンド (PCR Wrap-around) 問題を回避して ffmpeg で PS 変換できるようにしてみた に書かれているように PCR の値がおかしくなっているのを疑ってみるとよさそうな気がした。