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

運がいいとか悪いとか

よく運気をあげるとかいう話を聞く。運をよくすれば物事がうまくいくとか。ただそれだけを聞くと眉唾というか実態のない怪しいものを崇めるような雰囲気が漂う。

運気をあげるために日頃の行いをよくしなさい、的な。

これ、運気っていうとよくわからないけど、「人に声をかけてもらえるかどうか」ってことに換言すると、そうだなと思う。

良い話を回してもらえるかどうかというのは、結構その人の人柄にかかっていると思う。というか、良い話をわざわざ嫌な奴に話す人はそういないだろう。

で、その人柄ってのは日頃の行いの積み重ねだ。

そういう意味で、運をよくするために行動を改めるというのは理にかなっていると思う。 どこで誰が何を見ているかはわからない。人の悪口やポイ捨てなどがたまたま見られていて「あ、こいつに話すのはやだな」って思われたら運気が下がる。 つまり人に良い話を持ってきてもらえなくなる。 *1

運も実力のうちとはそういうことだ。*2

けっして壺を買うとかそういうことじゃない。短絡的に壺買えば運気が上がるなんてのは絶対に信じてはいけない。*3

---

*1:かのリチャード・ブランソンが、自殺相談だかの電話に親身に対応していたおかげで、忘れた頃に有益な情報を教えてもらって助かったとかいうエピソードがあった気がする (アフィリンク: ヴァージン―僕は世界を変えていく) 。 それを幸運と呼ぶならば、そういう幸運に恵まれるかは自分次第だ。 途方に暮れた時に人に手を差し伸べてもらえるかとか、そういうもそう。

*2:わかっていはいるけれどそういう意味で僕は実力がない。不親切で無礼だ。結構損してきたと思う。でもこういう内容をかけるぐらいには声をかけてもらってきた。ありがたい。

*3:壺買って運気が上がる人は一部いるだろう。つまり「こんな壺を持ってるということは、信用できる」と思考するような、力のある人が周りにいるかどうかだ。 あいにく僕の周りには骨董好きもいないし、そんな壺を選ぶ審美眼も自分は持ち合わせていない。壺がメタファーだとすればもう少し範囲は広がる。適当な美術品その他に置き換えてもいい。例えばいい美術品を持っていれば、レオナルド・ディカプリオに自宅に招待してもらえるなんて「ラッキー」も起こるかもしれないね。この場合のラッキーとは、自分の想定外、あるいはコントロール外にある「自分にとっての良いこと」が自分に降りかかって来ることかな。そういうものが思いがけず自分の手元に飛び込んできたら、嬉しくて自然と自分はついてると思えるものね。

Sketch3 グラデーションでぼかす

かなり前にこんな記事を書いた

taiki-t.hatenablog.com

グラデーションでぼかす方法はまた今度紹介するなどと言いつつずっと書いてなかったので手軽に手順だけまとめておこうと思う。

1. 四角を二つ重ねてかく。一つ書いて⌘ + Dすれば楽だろうか。
2. その二つの四角を選択してMaskを選択
3. 上のメニュー Layer からMask Mode > Alpha Maskを選択
4. 上に重なる四角には、横のメニューからBackground Blurを選択
5. 下に重なる四角には、横のメニューからFillを選択し塗りつぶす
   1. このとき、上は透明、下は白とかでグラデーションで塗りつぶす
   2. これでグラデーションのかかる範囲を調整
6. 適宜Background BlurのAmountを調整

西日暮里.rb 36回目「Electronではじめるアプリ開発」発売記念 LT 大会!」の記録

nishinipporirb.doorkeeper.jp

参加してきた。というか主催者の一人w

今回はオーガナイザーの一人であるじょうさん (@joe_re) が本↓を執筆したので記念LT会をした。

gihyo.jp

テーマは自由。けれど本がElectronということもあり、かなーりfrontよりのLT会だった

今日の西日暮里.rb、JavaScriptコミュニティにいるような感覚だ #ninirb

— じょう (@joe_re) 2017年4月24日

まぁRubyistsといえど技術好きの集まりには違いないし、これからもどんどん楽しそうなことやっていきたい。

やったこと

LT大会というとばーっと話しておわりだけど、今回は（も）フィードバック込みでやった。 Lightning Talk & Lightning Feedback（LTLF）という形式で、 以前から何度か試している。これはオーガナイザーの一人であるまつしまさん（@mtsmfm）の発案で始めた試みで、 場がかなり濃くなるので良い。楽しい。

具体的には、

1. LT中に聴衆がそれぞれ思ったことや疑問などを付箋に書く
2. LTが終わったら壁に集まって順番に付箋を貼りつつ
3. その内容について話す、LT発表者が答える

という形式。発表者の一方通行で終わらないので、普通にやるよりは学びが多いと思う。 人数が多い時はどうしたらいいんだろう、って問題もあるけど、そん時はTrelloなりにバーっと書いて非同期でフィードバックするというのが良いのだろうか。

発表内容

基調講演はもちろんじょうさんだった

あとはスライド探しきれていないけれど、ざっと内容を書くと:

• ElectronでOpalの話 @mtsmfm
• でかいPRとどう向き合うかの話 @HKDnet
• fastlaneのmatchの話 @color_box
• Electronで動かす音声認識、音声合成の話 @iidaapp
• React Native + Relay + Redux + Railsでアプリ作った話 @taiki__t

という感じだった。一文でまとめたので雑。Opalのすごいコードみたというのと、fastlaneのmatchがスタックしてるとき裏でパスワードをきいているという話がとても印象に残っている。

自分の発表のスライドはこれ:

近々リリースするアプリの技術的側面について話した。 デプロイゲートにてテスト版配布しているので、(iOSのみ): https://dply.me/435uls 気軽に試してフィードバックをもらえると嬉しい。

最後に

西日暮里.rbではまた6月にもLT大会を予定しているので、ぜひご参加ください。

西日暮里.rb | Doorkeeper

上記ページより「コミュニティに参加」をすると次回開催のお知らせがくると思います。