登壇のために Google Chrome 上で開いているタブをすべて閉じて片付けたいが後で一発で戻したい。そんなときに ⌘+shift+d
が使える
support.google.com で見つけた。
単純に閉じて再起動すれば? => Google Slides で発表するのでブラウザを立ち上げたままにしたい
登壇のために 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 にも記事を書いた
第4回 Roppongi.js に参加し、『貢献できるOSSの見つけ方 -How to find "Good First Issues"-』というタイトルでLTをしました。
リンク付きの原稿はこちら https://ohbarye.github.io/slides/2018/roppongi.js-4/
全体的に尖ったLTが多かったので初心者向けとも見える自分の発表が近づくにつれて「滑るのでは〜」という不安がありました。
しかし終わってみれば何名かに声をかけていただき、概ね好評いただきありがたい限りです。懇親会で「今日のベストトークは?」という話をしているとき、ふらっと会話に参加された方に自分が登壇者だと気づかないまま「最後からの2番目のOSSのやつが良かったですね」と仰っていて心拍数が上がりました。
そこそこ好評いただけたので面倒くさがっていたGUIもちゃんと作ろうという気持ちになった。バックエンドはfirebaseとかでドーンとやればバーンとできるやろ!!
— 広島の粗大ゴミ (@ohbarye) June 26, 2018
やっていったうえで次回の Roppongi.js で『続・貢献できるOSSの見つけ方』という話ができると良い
LT内でも触れた、弊社で行うイベントはこちらです。7/19(木)は渋谷集合!!
Cybozu Meetup で聞いた採用文脈でのブログ運用の話と、Quipper のブログ再開の話です。*1
所属する Quipper でも最近プロダクトチームのブログを再開しました。
自分も早速記事を書き、本日公開されました。
目的は中長期的な採用活動の活性化です。具体的には、中高生向け教育事業という性質柄「Quipper が何をやっているか」が候補者(エンジニア)にとって分かり辛いという課題の解消と、エンジニアブランディングイメージの構築を目指します。
再開するにあたってどのように運用するのが望ましいかを社内で議論し、おおむね以下のような方針を定めました。
過去に更新が止まってしまった最大の理由は「当時の採用計画を達成したから」でした。もともと採用目的で開始し、長期的に続ける算段も元よりなかったのでそこに一種の潔さはありました。
しかしこのたび採用活動を再開するにあたり、ブログ等を通じてエンジニア界の耳目を再び弊社に集めていくのはなかなか短期決戦とはいかなさそうだという感触があります。それなりの"存在感-プレゼンス-"を保つには、やはり続けていかないといけない。続けるためには"善意-ボランティア-"ベースではなく継続的に運用できる仕組みづくりが重要だと考えました。
そこで比較的ブログの"存在感"があり、さらにはブログ運用が採用にも繋がっているという各社の話を聞いてみると、どうやらこの方針に関してはほとんど一致しているようで追認された心持ちです。
以下は Cybozu Meetup で聞いた採用文脈でのブログ運用の話のまとめメモです。登壇者が壇上で語っていた内容なのでオフレコなものは無いと思いますが聞き間違い、誤った内容があれば訂正させていただきます。
CA社のブログの話はあまり聞けなかった
*1:書き終えたあとに会社ブログに書く内容かも?と自問したものの、前者に関しては完全に個人的なメモを載せているだけなので個人ブログが良いと判断