React Relayについて学び始めた

React Relayについて学び始めたのでメモしていく。

https://facebook.github.io/relay/

トップページをみると、Relayとは「データドリブンなReactアプリケーションを作るためのJavaScriptフレームワーク」だそうだ。特徴として、「宣言的(Declarative)」「並列(Collocations)」「変化(Mutations)」という3つの項目が挙げられている。

他にもいくつか簡素なコード例などもあるからじっくり読んでみるか、と一瞬思ったけど、あまりこういうのを読んでちゃんと理解できたためしがない。スキップしてとにかく遊んでみよう。

 

映画『ブラックスワン』

純粋な少女が大役への不安から自分を失っていく映画。

以下ざっくりとあらすじ。

主演のナタリー・ポートマン(ニナ)はバレエ団に所属する真面目系女子だった。あるとき『白鳥の湖』の主演を務めたいと座長に直談判した際、「君は白鳥は見事に演じるだろうが、黒鳥は演じられない」と言われるも、そのとき座長に無理やりキスされたときに相手の舌を噛んだ、その激情(?)を逆に評価され主演に抜擢される。

しかし、主演への不安から、ニナは徐々に自分を失っていく。

まずは悪い友達リリーと仲良くなり、母親と喧嘩して家を出て、夜通しクラブで遊ぶ。つぶれて、翌日の練習に遅刻。そのときリリーが代役に抜擢されたことを知り、疑心暗鬼になる。そこからはひたすら全てを疑い、病気のようになる。映画は主人公の視点で描かれているので、途中から何がほんとで何が幻覚なのか、観ている方もよくわからなくなる感じ。

ニナの疑心暗鬼は本番初日にピークを迎える。白鳥の役でミスをしてしまい、黒鳥の準備をしているときにリリーが楽屋にいて、口論になりガラスで刺し殺してしまう。死体をなんとか隠し、黒鳥を演じる場面では逆にそれが良い効果を生んで拍手喝采。

ラストの準備のとき、リリーが楽屋に訪れ褒められる。死体を隠したところを見るとなにもない。実は、ガラスで刺したのは自分自信だった。物語のお姫様?のように、最後は自分自身を殺すことになった、的なオチ。

主人公はもともと自傷癖があったり、真面目な反面メンタルが少し不安定、というキャラクターだったようだが、プレッシャーのかかる役どころでは自分自身が大きな壁になってしまう、というのはおそらく誰にでもあること(プレッシャーを感じる場面がある人ならば)なので、共感しやすい部分もあった。

主人公のキャラクターと、バレエの内容をシンクロさせているのが美しいと思う。

あと、ここまで登場人物の数が少ない映画も珍しい気がする。ニナと母親、リリー、座長、ベス、あとは全員ちょい役。会話の場面ですらほとんど他にはない。映画自体も1時間40分とかなり短い部類だろう。

母親の娘に対する過度な愛情も描かれている。過保護に育てられた娘がふとしたときに歯止めを失ってしまう、というわりと典型的っぽいイメージが描かれているのが印象的。この辺じっさいどうなんだろう。男兄弟で育った身としては難しい部分だ。

あと、当時はボディダブル問題(代役のダンサーがエキストラ程度の扱いだった)とかいって結構もめたらしい。この辺、リアルタイムに観てないとほとんどわからない部分だし、定期的に映画館に足を運ぶようにしたいと思った。

gvmによるgo1.5のインストール

gvmを入れて、go1.5をインストールしようとすると、こけることがある。

$ gvm install go1.5
Installing go1.5...
 * Compiling...
ERROR: Failed to compile. Check the logs at /Users/yusukenozoe/.gvm/logs/go-go1.5-compile.log
ERROR: Failed to use installed version

https://github.com/moovweb/gvm/issues/155

上記リンクによれば、まずgvmでgo1.4をインストールし、gvm use go1.4してから、gvm install go1.5すると上手くいく。

Mac+pyenvでpython2.7.10をインストールするときのエラー

普通にpyenv install 2.7.10したら、

Downloading Python-2.7.10.tgz...
-> https://yyuu.github.io/pythons/eda8ce6eec03e74991abb5384170e7c65fcd7522e409b8e83d7e6372add0f12a
Installing Python-2.7.10...
patching file ./Lib/site.py
ERROR: The Python zlib extension was not compiled. Missing the zlib?

Please consult to the Wiki page to fix the problem.
https://github.com/yyuu/pyenv/wiki/Common-build-problems

BUILD FAILED (OS X 10.10.4 using python-build 20151006)

インストールが失敗した。

https://github.com/yyuu/pyenv/wiki/Common-build-problems

上記URLによれば、CFLAGSを前に追加する。

CFLAGS="-I$(xcrun --show-sdk-path)/usr/include" pyenv install 2.7.10

プログラマーの実証主義について

プログラマーには「実証主義」とも呼べる態度がある。何もかも実際に動かしてみて、それから判断するという考え方。

例えば、システムのパフォーマンス改善をするためにはまず、現状を計測し、ボトルネックを明確に特定しておくことが当然のプロセスである。そうしなければその改善プロセスは何を目指してるのかわからない曖昧なものになってしまう。

この考え方はおそらく、ほとんどの場合において正しい。

理論値はいつでも間違っている可能性がある。特に、日常的なシステム開発では、小さな設計や実装上の意思決定が連続して行われる。それぞれの意思決定が少なくとも実用に見合う目的を満たしているかを判断するには、実際に動いているものを計測するのが最終的には最も客観的・正確である。チームでの議論もしやすいだろう。

一方で、いつでも実証に頼ろうとするのは思考停止なのではないか?と思うことがある。

例えばあるメソッドを実装する方法(アルゴリズム)が二つある場合、どちらの方がパフォーマンス的に優れているかは、ロジックの流れを計算すればわかるはずであるが、間違った実証主義=単なる面倒臭がりに陥っていると、コードを書いて計測して比較すればいいじゃん、ということになってしまいそうだ。ある意味考える必要がないので、楽である。

今のような例はすごく小さいが、こういった姿勢が長い目で見てプログラマーの成長の限界を決めてしまう可能性があるんじゃないか。

「怠惰」はプログラマーの三大美徳の一つと言われているが、上記のような態度はどちらかというと「考えること」に対する怠惰であり、理想である「手作業を減らすために徹底的に考える」態度の真逆だ。もっと簡単に言えば、こうした態度は「実装してみないとどうなるかわかんない」「ダメだったら一から実装しなおす」という非効率なプログラミングを生み出してしまうんじゃないだろうか。

つまるところ、「形にしてみないとわからない」という状態。これがシステムを作る上でどんなに障害になるか想像するのは難しくない。システムの設計なんていうものは、「形になる前にどれだけ精緻に考え込むことができるか」によって開発上の出戻りを減らせるものだし、それができなければ大規模な開発はできないだろう。いつも「バグが出るまで問題がわからない」という態度になりかねない。

しかし、いつでも実装する前に細かいところまでしっかり考えてから手を動かせばいいかというと、問題はそう単純ではない。

例えば、成長過程のプログラマーにとっては「まずはとにかく形にしてみる」ことが何よりも大事だったりする。そして、例えば2つの実装方法に差があるのであれば、どうしてそうなったのかを考え、実験によってそれを確かめる。その繰り返しで成長していくというのが一般的な流れだと思う。

つまるところ、やはりプログラマーの実証主義は正しいのだ。最終的には実証してみないと判断ができない。しかしその一方で、「考えればわかる」ことについては怠けずにしっかり図にするなりして考えて、できるだけ手数を減らす努力をすることがすごく大事だと思う。

より具体的なアクションプランとしては、

  • 実装する前に、時間を決めた上で徹底的に考える。
  • 決めた時間が過ぎてもわからないことに関してはとにかく実装してみる
  • 実装したものに対して「なぜそうなるのか」を考え、検証を重ねる

ということになると思う。まあ要は「考え続けることをやめない」ということでしかないけど。