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

2017-06-07

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

雑記 css

つけたかったので

#container {
 width: 1200px;
}

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

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

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

2017-06-04

メモ: puma on heroku, worker と thread

heroku puma thread Rails

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

2017-05-22

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

React Native

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を作ってそこでアクションを実行するとか、リロードが必要なところは全部モーダルで出すとかすればできないこともない。けど筋肉が必要。

taiki-t's diary

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

メモ：React Native で e2eテストできそうな detox

react-devtoolsをReact Nativeで使う

インストール方

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

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

yarn

npm

使い方

参考

Mark Zuckerberg's Commencement address at Harvard

GraphQL Mutation