Lazuli

らずり

React を使ってみた感想

最近、個人でウェブサービスを作ってる。まだ全然出来ていないけど。
どうせだし新しい技術を試す機会にしようと React を使ってみることにした。

facebook.github.io

近年の JavaScript フレームワークは Angular, Backbone, Vue と乱立しててぐへえとなるしかない状況でまるで触る気が起きなかった。しかし React はそれらのフレームワークとはアプローチが違ってエポックメイキングなフレームワークになる、と思う。いやもう博打に近い感覚だが。

Virtual DOM

React の話をする上でよく言われるのは仮想 DOM (Virtual DOM) という機構で React の内部で DOM ツリー構造のような仮想のツリー構造体を保持し、イベントの発生など DOM を書き換える場面になったら新しい仮想 DOM と既存の仮想 DOM との差分を導き生の DOM として生成して書き換える、という役割を持っている。たぶん。
実際にユーザが React を触る際に仮想 DOM がいまこうなってるはずだから〜などいちいち考える必要はなく、 React 内部に隠蔽されいるため特に意識する必要はない。意識する必要はないんだけど、DOM の書き換えは前述のとおり仮想 DOM の機構ですべて行うようになるため今までのように jQuery 使って DOM をグリグリいじくり回すとのはご法度になる。外部から DOM をいじってしまうと 仮想 DOM の diff が壊れてしまい正しく動かない。なので今まで培ってきた jQuery の DOM 操作プラクティスは使えないということになる。ただ、逆に言えば DOM さえ触らなければ良くて、 $.ajax 使うとかそういうのは問題ない。Ajax 使うために jQuery を選ぶというのはちょっともにょるが。

と、ここまで仮想 DOM について書いたけど個人的にそれほどすげえなと思ったわけではなくて、フロントエンド詳しくないし、は?JSX?なにそれ謎と言った感想が次々と湧いてきてようやくそういうことねと分かってきた感じ。bower とかいうのも初めて使ったけどやはりどの言語でもパッケージツールは便利やで…

コンポーネントの書き方

React 良いなと思ったのはコンポーネントの書き方だった。Angular とか使ってないからそこら辺のフレームワークがどうなってるか知らないけど jQuery でぐりぐりいじってた頃と比べると格段にイベントの管理がしやすい。
jQuery だとこの DOM のイベントはどこにあって、いつ書き換えられるのか、いまどういう状態なのかというのが全然分からない。ソース読めば分かるんだけど全体を読まないと分からないというか、イベントが飛び散ってるんだよな。それが React だとコンポーネントの中にイベントを書くしかなくて探す必要がなくなる。DOM の状態も仮想 DOM が吸収してよしなにしてくれるから気にする必要もない。このコンポーネントの動きが知りたいと思ったらコンポーネントのソースだけを見れば動きがすぐ分かるという感じ。見通しが良くてこれには琴線に触れるものがあった。
ここでひとつ、実際に見やすさをソースとして示しておきたいところだが、React の知識が多少ないとソースは読めないと思うし、知識がある人がソース見ても既に知ってることだからなんら感動を得ないと思う。自分で調べるとよろしい。

Flux について

React が採用してる新しいアーキテクチャMVC を破壊する!という話を聞いたけどまだ実態がよく分かってない。
これから理解していきたいですねー。

学び方

とりあえず React を学びたいのであればこのアドベントカレンダーを読むのは欠かせないと思う。

qiita.com

まだ途中までしか読んでいないけど、丁寧に親切に分かりやすく書いてある。この一人で布教する熱量たるや、やはり React 来るで…と思わせるものがある(本当か?)
まあそんな感じでReact 触るの面白いからもう少し勉強してみようと思う。実務で使う可能性は限りなくゼロに近いが。

外天楼を読んだ

一冊完結の漫画。Kindle 版買って Nexus7 で読んだ。
どっかのまとめで面白いと聞いて気になってたやつ。

外天楼

外天楼

前情報通り、面白かった。ミステリーというのかね、これは。
基本的に一話完結で終わる短篇集になっている。タイトルは仰々しい感じにだけどしょっぱなから少年らがどうやったらエロ本を手に入れることが出来るのか作戦を練って実行していくとかくだらない話から始まる。そこから話が広がっていく。
読んだ後に Amazon のレビューを見たらネタバレ感ある書き方が多くて読む前にレビュー見てなくて良かった。本の内容を調べずに読んだほうが楽しめると思う。

サクッと読めるから、暇な時にでも是非。

Clean Coder を読んだ

副題は「プロフェッショナルプログラマへの道」となっていて、プログラマ向けのビジネス書といった内容になっている。プロとはどういったプログラマか、プロとしてどう振る舞うべきかが書かれている。

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

本で例に上がっているような問題がうまくこなせたらプロだと思うけれども、そういったことが上手くコントロール出来るような環境って大概ホワイトな企業だし、ブラック真っ盛りな企業だとプロとしての責任とかそういうのも意味を持たない世界だから、心底ブラック企業は滅びればいいと思いながら読んだ。
マネージャと気持ちよくやりとりして、必要であれば新しい技術を案件に使い、プロの開発者に囲まれて刺激を受けながらプログラムが書けたらどれだけ最高か。いや、いまの環境が超絶ブラックという意味ではないが、そういう環境にプログラマはだれしも憧れると思う。
良い本だった。

次回予告

今度こそ継続的デリバリー読む。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

vimrc を設定しなおした

付け焼き刃的に使っていた vimrc を全面的に変えた。といってもゆるよろさんの dotfiles をフォークして自分用に書き換えただけなんだけど。

github.com

一応、vimrc 全部に目を通してわからんとこはググったりなんだとした。人の vimrc 読むと知らないプラグインがあってほほうとなる。

次は zshrc に手を入れたい。

Ansible Vault で Aws キーなどを暗号化する

About Ansible


Ansible is Simple IT Automation

最近は Ansible を使っている。Chef や Puppet に並ぶプロビジョニングツールのひとつ。
Ansible の立ち位置は明確で、Chef の難解さに絶望あるいは嫌気を差した者たちが使うツールとなっている。Ruby の素養もいらず Yaml で書けること、さらにはプロビジョニング時、Chef は対象のサーバ側にも Chef がインストールされていなければならないが、Ansible の場合は手元にだけあれば良いという点もあって徐々に人気が出てきている。

How to use Ansible

面倒くさいので省略する。
エコシステムも確立されつつあって、Google 先生も Ansible についてだいぶ詳しくなってきた。先生に聞いたほうが早いと思う。

How to use Ansible Vault

Ansible でプロビジョニングする際に困るのはコード上に記したくない値の扱いだろう。たとえば Aws のアクセスキーや WebAPI のアクセストークンなどなど。そういったものたちは Ansible Vault という機能を使って値を暗号化することによって安全にプロビジョニングをすることが可能だ。
Ansible の変数ファイルを利用して実行する。Playbook に下記のように vars_files プロパティで変数ファイルを指定をする。

# playbook.yml
- hosts: localhost
  vars_files:
    - vars/private.yml

private.yml には好きな変数名に必要な情報を与えておく。

# private.yml
aws_access_key: hoge
aws_srcret_key: bar

ansible-vault コマンドを使ってファイルを暗号化する。
その際に任意の暗号化パスワードを入力する。

$ ansible-vault encrypt vars/private.yml
ault password:
Confirm Vault password:
Encryption successful

これで暗号化できている。
中身を見てみると…

$ cat vars/private.yml
ANSIBLE_VAULT;1.1;AES256
34393238393235356164353265386163393564306637666563376666366636343937666131626239
3932616239376439313566383230633235633765663531650a343362306137306632656432646136
62613934393030643261366364386263653264303736396537313038346233636636333637303237
3061376562393364630a363162633330323364373761313866363634613331626162383938376636
35316365326632306534623531633464633461383961666336393830326165646361613637613335
6566303836613434303066383165666335656231306634656231


これを使って Ansible を実行すればコード上にキーの値などを記載しなくて済む。ただ、後々さあメンテナンスしようとなったときに暗号化されたファイルを見ても何が書いてあるのか分からないのが。まあ暗号化してるんだから当たり前なんだけど。

実際に復号化して Ansible を動かすには下記のようにすればいい。
実行時に暗号化した際に決めたパスワードが問われる。

$ ansible-playbook playbook.yml --ask-vault-pass
Vault password:

毎回入力が面倒ならパスワードが書かれたファイルをどっかに置いておいて、

$ ansible-playbook private.yml --vault-password-file=/path/to/password_file

とやってもよい。
しかし、こんなやり方だと本末転倒な感じがある。


Ansible、ドキュメントも豊富で敷居も低いので Chef にげんなりした人は使ってみるとうまく運用に乗せられるかもしれない。
良いツールだから使おう。

UNIXという考え方を読んだ

よく耳にする UNIX 哲学について説明してる本。100頁ちょっとしかない。

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

UNIX がいかに素晴らしいシステムであるかが記されているわけだが、Apple 信者のそれと同じようにこれは言いすぎだろー的な過剰な部分もある。
それでも内容は勉強になるものがたくさんあったので評判通り良い本だった。

次回予告

継続的デリバリー読む。500頁くらいある。
表紙のコピーがイケハヤを連想させる。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化