taiki-t's diary

React Native, Rails そして雑多な記録: The world is waiting for you to give it a meaning.

react-devtoolsをReact Nativeで使う

React Nativeで開発でのデバッグにはNuclideを使っていたけど、react-devtoolsも使える。

インストール方

グローバルにインストールする場合

  • npm install -g react-devtools
  • これでreact-devtoolsとterminalでやれば走る。

プロジェクトにインストールする場合

yarn

  • yarn add --dev react-devtools
  • yarn react-devtoolsとterminalで打てば走る(プロジェクトフォルダにて)

npm

  • npm install --save-dev react-devtools
  • "react-devtools": "react-devtools"package.jsonscriptsのとこに書く
  • npm run react-devtoolsとterminalで打てば走る(プロジェクトフォルダにて)

使い方

  • SimulatorでCommand + Dして出てくるメニューから Show Inspectorを選択
  • 要素をクリックすると、devtoolsの方で連動して表示してくれる。

まあここら辺はNuclideとあまり変わらない。 ただNuclideというかAtomが重いのでdevtoolsの方が気軽に使えそうな気がしている。

参考

github.com blog.expo.io

GraphQL Mutation

Relay使ってての話なんだけど

  • Mutationはできる限り単一責任にした方が、のちのユースケース変更時にコスト低そう
  • リソースに対する状態変更は、Mutation名を動詞にしてidだけ送るとクライアントとサーバー側を疎結合にできて良さそう

UpdatePostStateMutationとかで変数に{ id, status: 'visible' }とかやるんじゃなくて HidePostMutation, ShowPostMutationとか作ってidだけ送る。status: 'visible' とかの状態名ってどうしてもサーバー側の知識が漏れがちだから、idだけ渡す方が変更に強そう。

はてなブログthemeのevergreenにサイドバーをつけた

つけたかったので

#container {
 width: 1200px;
}

#container-inner {
 min-width: 1200px;
}

#main {
  float: left;
  max-width: 780px;
  margin: 0 auto;
}

こんな感じ。適当にやったらできたのでよかった。 まあ正確にはつけたというよりフッターを移動した、かな

メモ: puma on heroku, worker と thread

web serverとしてpumaを用い、Railsアプリケーションをherokuで運用するにあたり workerやthreadという話が出てきたのでメモ。

ネタ元は: Deploying Rails Applications with the Puma Web Server | Heroku Dev Center

Workers

Workerとは

pumaの文脈でいうworkerは、herokuでいうworkerとは別の概念であることに注意。 herokuのworkerはそれ用のdynoでバックグランド処理などを行うプロセス。一方、pumaのworkerは、pumaがforkする OSのプロセス。これによりRailsは並行してリクエストを処理できるようになる。

Worker processはOSレベルで独立なので、thread safeである必要はない。 自身のアプリがthread safeかどうかわからない、もしくはthread safeでない場合とりあえずworker processだけ増やせば安全にパフォーマンスの向上を図れるのだろうか。

設定

workers Integer(ENV['WEB_CONCURRENCY'] || 2)

のように環境変数でWEB_CONCURRENCYを設定する。ここら辺の詳細はProcfileの設定にて: Deploying Rails Applications with the Puma Web Server | Heroku Dev Center

Worker数について

workerはプロセスなので増やすごとにメモリ使用量が増える。なのでdyno一つにつきどれぐらいworkerを生やせるかはメモリ使用量による。 free, hobby , standard-1x dynoでは、典型的なRailsアプリだとだいたい2-4のworkerが目安らしい。個々の環境においては、dynoで利用可能なメモリの上限を超えた時に生じるR14 errorsを監視して設定する。

詳しくは: https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#workers

Threads

Pumaはそれぞれのリクエストをthreadを使い処理できる。なのでworker数がリクエストの並行処理数を決め、thread数がそのそれぞれのリクエストの並行処理数を決める感じだろうか。

MRIにおいてはGILがあるので実行されるthreadは常に1つ。しかしIOの処理時にはGILはロックされない。そしてほとんどのRailsアプリは大量のIOを伴う。そのため、thread数を増やすことでPumaは複数のthreadを処理できるようになり、その結果スループットは上がる。

Pumaはthread数の上限と下限を設定できるが、heroku的には同じ値を設定するのがお勧めとのこと。

詳しくは: https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#threads

参考リンク

Deploying Rails Applications with the Puma Web Server | Heroku Dev Center

マルチスレッド/プロセスまとめ(Ruby編) - Qiita

余談

thread safeなRailsとかそういう情報って少ない

How do I know whether my Rails app is thread-safe or not? - by Jarkko of Bear Metal

メモ: React Navigation を使い始める時に確認すると良さそうなこと (v1.0.0-beta.10時点)

Release v1.0.0-beta.10 · react-community/react-navigation · GitHub

React Navigation V1.0.0-beta.10が出た。そう、React Navigationはまだbetaが取れてない。 使い始める前に現状どんな問題があるか確認しておくと時間を節約できると思う。 どこを確認すればなんとなく検討できるかというと、GitHubレポジトリに上がっている次のIssue。

github.com

v1.0.0-stableを出すにはこれらを全て解決しようというコミュニティの意向が反映されている。 このチェックボックスがついていないものは機能として存在しないので気をつけると良さげ。 たとえば2017/5/22時点で Screen lifecycle hooks は実装されていない。つまりReduxとかを併用していればごにょごにょできるかもしれないが、React Navigation単体ではタブをユーザーがタップした時点で何かアクションを実行するというようなことはできない。*1

あとはまあ一般的なことだけど出てるIssueはざっと眺めた方が良い感。

他、一応v2へのロードマップもちょこっと出てる

v2 Roadmap · Issue #1263 · react-community/react-navigation · GitHub

Exampleをざっと動かしてみるのも良いかもしれない。

https://github.com/react-community/react-navigation/tree/master/examples


感想戦:

相変わらず全体的な印象の話になってしまうけど、機能としては存在しても細かいところまでは詰められていないことも多々ある。 機能はあるけど微妙な挙動をすることもあるので、そういうものにぶつかった時は割り切りあるいは自分で直す覚悟が求められる。

たとえば:

  • タブ内で画面遷移すると、タブの表示(画像、ラベル)も切り替えられてしまうので自分で対策する必要がある
  • 画面遷移によっては、戻ったあとにその戻る前のタイトルが一瞬表示される

などなど。

こういうことばっかり書くと使うのやめようってなるかもしれないけど、でも使ってほしい。


https://www.facebook.com/groups/react.native.community/permalink/988488134620098/

React Native Community上ではnavigation libraryの中ではReact Navigationが優勢な模様

*1:回避策としてHOCでProxyScreenを作ってそこでアクションを実行するとか、リロードが必要なところは全部モーダルで出すとかすればできないこともない。けど筋肉が必要。

Relay Modern rewriteについてのメモ

We still had that long backlog of ideas, but we knew that we were adding to the tail of the queue faster than we were shifting from the head of it. It was a scary prospect, but we came to the conclusion that it was time to burn it all down and rewrite the thing from scratch. We knew we had to unlock performance wins that would require drastic changes, and rewriting was the only way we were going to be able to do it before old age, senility and burn-out took us out of the game. A risky move — big rewrites are often warned against for a reason — but we felt like we had to take the gamble. In doing the rewrite, we knew that the risk of failure (in typical “Second System Syndrome” fashion) was real, but inaction would have led to certain failure.

Building Relay Modern · wincent.com

すげぇ


Relay Modernはかなりの書き直しだったそうだ。システムの書き直しにチャレンジしたことがある身としては、上記の段落の葛藤がそのまますぎてグッときた。成功してよかったなぁ。