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.json
のscripts
のとこに書くnpm run react-devtools
とterminalで打てば走る(プロジェクトフォルダにて)
使い方
- Simulatorで
Command
+D
して出てくるメニューからShow Inspector
を選択 - 要素をクリックすると、devtoolsの方で連動して表示してくれる。
まあここら辺はNuclideとあまり変わらない。 ただNuclideというかAtomが重いのでdevtoolsの方が気軽に使えそうな気がしている。
参考
Mark Zuckerberg's Commencement address at Harvard
What I thought listening to this is: “It’s not the world that gives you the meaning, the world is waiting for you to give it the meaning.”
はてなブログ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。
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はかなりの書き直しだったそうだ。システムの書き直しにチャレンジしたことがある身としては、上記の段落の葛藤がそのまますぎてグッときた。成功してよかったなぁ。