taiki-t's diary

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

Lylicaというサービスをリリースした。

Lylica

Lylica (りりか) というサービスをリリースした。iOSアプリで。

f:id:taiki-t:20170621160719p:plain:w500

Lylica - 街のおすすめが分かるSNSを App Store で

「世界をもっとダイナミックにしたい」

そう思って作ってきた。きっかけは、昨年(2016)に翻訳書1を出版したことに遡る。

昼間は会社、夜は翻訳、週末も翻訳。そういう生活を1年半近く過ごしてきて実感したのは、 息抜きにどこかに出かけたいけど調べる時間もない、ということだった。

何かをやるには調べる必要があって、調べるにはスキルと知識2が必要で、そして時間も必要で。 僕はその余裕がなかったので、結局いつも決まったカフェにいくルーティーンで日常は終わった。

けれど世の中というのは自分の知らないところでも回っていて。 あの時近くでこれがやってたと後から知ったり、偶然通りがかった時にお祭りをやってることを発見したりだとか、 そういうことを多々経験した。その時に思ったことはいつも

「近所のことぐらいすぐ手元でわかったらいいのに」

だった。

「世界をダイナミックにする。」その答えの一つは、そのような人の人生により多くの選択肢をその場で提供することにある。 そうすれば、調べる時間がなくても、調べる言葉が思いつかなくても、その人はもっと色々なものに参加できるようになるかもしれない。 つまり、その人の人生はもっと豊かに、ダイナミックになるかもしれない。

そういうことを、実現したい。

f:id:taiki-t:20170621163109j:plain:w620

偶然通りかかったお祭りにて -- 2016/08/20 18:47

Lylicaでできることは今のところ主に次の2つとなっている。

  • その場のできごとを写真にとってシェアする
  • 付近の投稿を閲覧する3

世界をダイナミックにする、それだけだったら別の方法もあると思う。 それをなぜこういう機能にしたのかというと、他に実現したいことが2つあるからだ。

  • 「人と場所、人とできごとを繋げる」
  • 「人のその場所での営みを残す」

世界をダイナミックにすると同時に、これらのことも実現したい。

僕の両親は自営業だった。いわゆる個人商店。幼い時からずっと見てきた光景の一つが、人集めの苦労だ。 僕は、そのように個人で物事をやる人たちの手元に助けとなるツールを提供したい。4 低コストで、かつ簡単に地域の人たちに情報を届けられるツールを。

人と場所、人とできごとを繋げれることができれば、世界をダイナミックにできると同時にそのツールを提供できる。

そして、

実家は福島にある。2011年、震災を経験した。いろんなことが変わった。景色、生活、習慣。 それは失われたと言っていいのか、新しいものを得たと言えばいいのかわからないけど、僕が経験したのは喪失感だった。 それは今でも変わらない。

無くしたものを数えてもしょうがないんだけど、でもそれはこれからに向けて対策を取らないこととは異なる。

人がその土地で営んだ記憶、記録を残したいと思ったのはそれからだ5。 Googleの使命が世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすることならば、 Lylicaの使命の一つは、人々がその土地で営んだ記録を残し、整理しアクセスできるようにすることだろう。

そうすれば、僕が失ったものの半分は失われずに済むような気がしている。

そういうわけで、Lylicaは簡素ながらも、

  • 「世界をもっとダイナミックにする」
  • 「人と場所、人とできごとを繋げる」
  • 「人のその場所での営みを残す」

の3つの目標を全て実現できる可能性を秘めたプロダクトとして生まれた。 この3つが実現できるかはこれからの運用にかかっている。機能の追加は、その3つの目標の元に行われていく6。

なにか思うところがあった人はなんでも連絡をしてもらえると嬉しい。TwitterのDMにでも。この記事は特にそんな人のために書いている。

そして何より、インストールして使って、フィードバックをいただけたらと思う。

ダウンロードはこちららから: Lylica - 街のおすすめが分かるSNSを App Store で

始まったばかりのサービスですが、何卒よろしくお願いします。

f:id:taiki-t:20170621173917j:plain:w620

少し曇りだったけど変わらずきれいな三春の滝桜 -- 2017/04/22 05:59

  1. オブジェクト指向設計実践ガイド 「日本のITエンジニアの生産性をあげる」という個人プロジェクトの一環で取り組んだ。↩

  2. 例えば乗馬ができる土地に立ち寄ったとして、そこで乗馬ができることを知らないのにどうして「乗馬体験 地名」というような検索ワードをGoogleなりに打ち込むことができるのだろうか。何かを知るためにはそもそも知っていなければならないというパラドックスがある。知識ゼロでその土地に降り立ったとしても人は自分の選択肢を知ることができなければならない。↩

  3. こういう機能、地域SNSっぽいけどコミュニティ構築をしようとは思っていない。個人的には、向かい合って手を取り合うような属し方は不得意。そういう文脈で言えば実現したいのは「街の映画館で映画を見てて、ふと笑ったら隣の人も同じところで笑ってた」感。そういう空気感がある地域は、いざという時にも強そう。↩

  4. toBに関しては、以前のチームであるMisocaで取り組んできた。個人で物事を行う人たちの時間を節約するということは、僕のような子供が両親と過ごす時間が増えるということだ。それはよいことだと思っている。↩

  5. 被災地においては、歩いて行けるぐらいの距離の違いでも物資配給の列の長さが全く異なるという光景を目にした。そういうのも解決できたらと思う。↩

  6. 間近の目標としては、2020年には誰もが1ブロック先の情報を気軽に把握できるようにしていたい。このままじゃそうなっていない未来がきてしまう。↩

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

React Native つぶやき

https://github.com/wix/detox

これ使えそうと思ったけど、Permission用Alert周りの処理で詰んだ。 工夫すればできそうだけどまた後ほどtryする。 導入自体はすごく簡単だった。

このIssueがcloseする頃にはそこらへんいい感じになってるのではと期待:

github.com

react-devtoolsをReact Nativeで使う

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の方が気軽に使えそうな気がしている。

参考

github.com blog.expo.io

GraphQL Mutation

Relay GraphQL つぶやき

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

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

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

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

雑記 css

つけたかったので

#container {
 width: 1200px;
}

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

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

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

メモ: 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