Rails の view を React で書き直したときに使った脱 Slim のやり方
各種 gem を install して手元でコマンド叩いてもできるけど面倒くさい場合に使える
converter - How can I convert html.slim files to html or html.erb? - Stack Overflow この回答どおり、CodePen に Slim などを貼り付け、コンパイルされた結果を参照すれば良い
StackOverflow で記載されていることに特に付け加えることはないが…以下のやり方でコンパイルされた HTML が見られる
HTML2slim は HTML -> Slim の単一方向のみ
CodePen でなくても出来るとは思う
「○○の経験したこと無いくせに」
「○○したことないからわからないんだよ」
という言説を見聞きしたり、この論旨で「論破してやったわ」みたいなの Twitter で見るたびげんなりしてしまう。
「恋愛したこと無いくせにラブストーリーとかｗｗｗｗ」っていうのはわからんでもないがこの理論だと尾田栄一郎は元海賊だし冨樫義博は一回死んでるし宮沢賢治にいたってはNASAより先に宇宙行ってる
— まつくｳﾞｧ＠MONOつくりの会 (@matsu_kuva) January 16, 2012
こういう反論でも良いと思うけどちょっと論旨がずれそうだ。
トラブルを避けるためにちゃんと理解してもらいたいのは、相似する、もしくは全く同じ経験をした人間が自分と同じことを知ったり学んだり思ったりするわけではないということ。自分の個別的な経験・思考を、一般的な事例や法則へと置き換えてしまうのは過度な一般化だ。
学校で一斉授業をうけていたこととその結果を思い出してくれるとだいぶわかりやすいと思うのだが…自分の観測範囲では、人生にとっての一大イベントと当人が考えるような事象については驚くほど多くの人が他人に追体験を要求しがち。
...という自分の信念を補強する、それっぽい箴言を集めてみる（確証バイアス）
愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。
オットー・フォン・ビスマルク https://ja.wikiquote.org/wiki/%E3%82%AA%E3%83%83%E3%83%88%E3%83%BC%E3%83%BB%E3%83%95%E3%82%A9%E3%83%B3%E3%83%BB%E3%83%93%E3%82%B9%E3%83%9E%E3%83%AB%E3%82%AF
シーザーを理解するためにはシーザーとなる必要はない。 →「追体験できること」は、理解の明証性のために重要であるが、それは意味解明のための絶対条件ではない。
登壇のために Google Chrome 上で開いているタブをすべて閉じて片付けたいが後で一発で戻したい。そんなときに ⌘+shift+d が使える
support.google.com で見つけた。
単純に閉じて再起動すれば？ => Google Slides で発表するのでブラウザを立ち上げたままにしたい
してきました。
データ周りや意思決定の話は専門ではないのであまり主語を大きくして叩かれないようにわりと渋めのタイトルにしました。ちょっと局所的すぎたかもしれません。
20分のトークは初めてだったので勝手がわからず86枚もスライドを作ってしまいました。直前の脳内練習では18分に収まったものの本番では20分30秒ぐらいになってしまったので練習が足りんなぁ〜と思いました。
質問も ama でいただけていたのに時間内で回答できなかった…ので先ほど web で回答しました。
.@strviola いただいたご質問「BtoBのサービスで「リリース後に価値を測る」方法が知りたいです (自分がBtoBにいるので)」に回答しました！遅くなってすみません 🙏https://t.co/kmpcI6FoG0#railsdm #rdm2018b
— 広島の粗大ゴミ (@ohbarye) July 14, 2018
.@yensaki いただいたご質問「コストかけてテストを実施するというのはどうやって合意を取りましたか？」に回答しました！遅くなってすみません 🙏https://t.co/kmpcI6FoG0#railsdm #rdm2018b
— 広島の粗大ゴミ (@ohbarye) July 14, 2018
このように非同期で質問に回答できる仕組みもすばらしい！！
実は今回が初参加でした。
とにかく言いたいのが、あれだけのすごいイベントに無料で参加できてしまって本当に良いんですか〜〜
トークが豪華なのは言うまでもなく、ランチもコーヒーもディナーも付いてきて長丁場でも参加できる優しさがありました。オンライン配信とか別会場で同時開催とか、個人の頑張りでできる域を超えている〜〜
来週の StudySapuri Product Meetup も規模はぜんぜん違いますが来場者に満足いただけるよう負けずに頑張ります。
以下のように Git root directory ではなく sub directory にデプロイしたいアプリケーションが存在する場合を想定。
$ tree -L 2 . ├── .git ├── frontend │ ├── README.md │ ├── config │ ├── images.d.ts │ ├── node_modules │ ├── package.json │ ├── public │ ├── scripts │ ├── src │ ├── tsconfig.json │ ├── tsconfig.prod.json │ ├── tsconfig.test.json │ ├── tslint.json │ └── yarn.lock ├── backend └── netlify.toml
Deploy context を設定する必要があるので、Git root directory に置く netlify.toml に以下のように記述する。
[build] base = "frontend" publish = "frontend/build" command = "yarn build"
Netlify の管理画面では Build command も Publish directory も記述しない。
いま趣味で作っている Good First Issues を探す web application のフロントエンドはこの方式でデプロイしている。
(追記) sub directory をデプロイしたり、いちレポジトリで multi applications のデプロイをサポートする buildpack があると元同僚の id:kamatama41 から教えてもらったので追記しました。ありがとうございます！
以下のように Git root directory ではなく sub directory にデプロイしたいアプリケーションが存在する場合を想定。
$ tree -L 2 . ├── .git ├── backend │ ├── Gemfile │ ├── Gemfile.lock │ ├── LICENSE │ ├── README.md │ ├── Rakefile │ ├── app │ ├── bin │ ├── config │ ├── config.ru │ ├── db │ ├── lib │ ├── public │ ├── test │ └── vendor └── frontend
git subtree split で切り出して push する。
$ git push --force heroku `git subtree split --prefix backend HEAD`:master
--force しているしあまり良くなさそう。もっと良いやり方が あると思う あったがとりあえずメモを残しておく
いま趣味で作っている Good First Issues を探す web application のバックエンドはこの方式でデプロイしてい る。 たが、heroku-buildpack-monorepo を使うやり方に切り替えた。
(以下、追記)
heroku-buildpack-select-subdir を使うやり方。
Deploy Lerna Packages to Heroku | Jake Trent を参考にしてやってみた。ほとんど手順が同じなので詳述はしないが、実行したコマンドだけ載せておく。
# sub directory に移動して heroku app をつくる $ cd backend && heroku create ohbarye-monorepo-test # sub directory を build するための buildpack を設定する $ heroku buildpacks:set -a ohbarye-monorepo-test https://github.com/Pagedraw/heroku-buildpack-select-subdir # デプロイする application が使用する buildpack を指定する. 今回は Rails application で試したので heroku-buildpack-ruby $ heroku config:add BUILDPACK='backend=https://github.com/heroku/heroku-buildpack-ruby' -a ohbarye-monorepo-test # remote repository を登録 $ heroku git:remote -a ohbarye-monorepo-test # あとはいつもどおり push するだけ. root directory からでも sub directory からでも push できる $ git push heroku master # 起動確認 $ open https://ohbarye-monorepo-test.herokuapp.com
1点だけハマったのは、Procfile に書いた起動コマンドでアプリケーションの起動に失敗したこと。
web: bundle exec rails server -p $PORT
これはこのコマンドを実行するコンテキストが root directory のままだったことによる。この buildpack はそこまで面倒を見てくれない。Procfile に以下のように cd コマンドを追記することで解決できた。
web: cd backend && bundle exec rails server -p $PORT
heroku-buildpack-monorepo を使うやり方。
こちらも実行したコマンドだけ載せておく。
# sub directory に移動して heroku app をつくる $ cd backend && heroku create ohbarye-monorepo-test # sub directory を build するための buildpack を設定する $ heroku buildpacks:add -a ohbarye-monorepo-test https://github.com/lstoll/heroku-buildpack-monorepo # アプリケーションの root になる sub directory を指定する $ heroku config:add APP_BASE=backend -a ohbarye-monorepo-test # 公式 README にはないが、デプロイする application が使用する buildpack を指定する必要がある # 今回は Rails application で試したので heroku-buildpack-ruby # buildpack は2つ必要なので `set` でなく `add` を使う $ heroku buildpacks:add heroku/ruby # remote repository を登録 $ heroku git:remote -a ohbarye-monorepo-test # あとはいつもどおり push するだけ. root directory からでも sub directory からでも push できる $ git push heroku master # 起動確認 $ open https://ohbarye-monorepo-test.herokuapp.com
heroku-buildpack-select-subdir と異なり cd backend のようなディレクトリ移動は必要ない。
web: bundle exec rails server -p $PORT
これは heroku-buildpack-monorepo が APP_BASE 環境変数に指定したディレクトリをそのまま root に持ってきているからだと、 git push 時の log を見るとわかる。実際に buildpack のコードを見てもわかる（けっこう力技だ）。
$ git push heroku master Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 363 bytes | 363.00 KiB/s, done. Total 4 (delta 2), reused 0 (delta 0) remote: Compressing source files... done. remote: Building source: remote: remote: -----> Monorepo app detected remote: Copied backend to root of app successfully
現プロジェクトと近似した構成で素振り出来るよう Rails + PostgreSQL による backend と React + TypeScript による frontend を docker-compose で立ち上げる boilerplate 作ったhttps://t.co/iCqMc2TWrD
— 広島の粗大ゴミ (@ohbarye) 2018年7月7日
最近は "Backend developer" と名乗ろうが "Frontend developer" と名乗ろうが、web application を開発するエンジニアとして求められる知識は広範囲にわたることを、改めて実感しなおしている。
自分の経験でいえば、ここ数年は Rails エンジニアとしてやっているのだが、最近は React.js と TypeScript による SPA (Single Page Application) の開発にフル注力するプロジェクトをやっている。
その SPA はもちろんバックエンドにAPI、今回で言えば Rails がおり、Rails は DB に接続する。登場人物が増えるにつき同じく立ち上げるプロセスが増えていく。ローカル開発がきついので必要なアプリケーションとミドルウェアをいっぺんに立ち上げるのに docker-compose を使っている。
こうした技術要素をそれぞれ学ぶのは苦ではないのだけれど、余暇でいっぺんに学ぼうとすると近似した環境を手元で作るだけで疲れてしまう。
というわけで作ったのがこれ
https://github.com/ohbarye/rails-react-typescript-docker-example
名前が長過ぎる
$ git clone https://github.com/ohbarye/rails-react-typescript-docker-example.git && cd rails-react-typescript-docker-example # Setup $ docker-compose run frontend yarn $ docker-compose run backend rake db:create # Start $ docker-compose up -d $ open http://localhost:3000
dev.to にも記事を書いた
