valid,invalid

関心を持てる事柄について

⌘+shift+d で"開いているすべてのタブをブックマークとして新しいフォルダに保存する" on Google Chrome

登壇のために Google Chrome 上で開いているタブをすべて閉じて片付けたいが後で一発で戻したい。そんなときに ⌘+shift+d が使える

support.google.com で見つけた。


単純に閉じて再起動すれば? => Google Slides で発表するのでブラウザを立ち上げたままにしたい

Safari などの別ブラウザ使えば? => 普段使いが Chrome なので登壇時も慣れているブラウザを使いたい

「Quipperが実践する、定量データに基づく意思決定と開発」という話を Rails Developer Meetup 2018 Day 3 extreme でしてきました

してきました。

techplay.jp

スライド

データ周りや意思決定の話は専門ではないのであまり主語を大きくして叩かれないようにわりと渋めのタイトルにしました。ちょっと局所的すぎたかもしれません。

トーク

20分のトークは初めてだったので勝手がわからず86枚もスライドを作ってしまいました。直前の脳内練習では18分に収まったものの本番では20分30秒ぐらいになってしまったので練習が足りんなぁ〜と思いました。

質問も ama でいただけていたのに時間内で回答できなかった…ので先ほど web で回答しました。

このように非同期で質問に回答できる仕組みもすばらしい!!

RailsDMについて

実は今回が初参加でした。

とにかく言いたいのが、あれだけのすごいイベントに無料で参加できてしまって本当に良いんですか〜〜

トークが豪華なのは言うまでもなく、ランチもコーヒーもディナーも付いてきて長丁場でも参加できる優しさがありました。オンライン配信とか別会場で同時開催とか、個人の頑張りでできる域を超えている〜〜

来週の StudySapuri Product Meetup も規模はぜんぜん違いますが来場者に満足いただけるよう負けずに頑張ります。

techplay.jp

monorepo 構成の Git repository の sub directory を Netlify にデプロイする

以下のように 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 も記述しない。

f:id:ohbarye:20180708160355p:plain


いま趣味で作っている Good First Issues を探す web application のフロントエンドはこの方式でデプロイしている。

https://goofi.netlify.com/

github.com

monorepo 構成の Git repository の sub directory を heroku にデプロイする

(追記) 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 を使う

git subtree split で切り出して push する。

$ git push --force heroku `git subtree split --prefix backend HEAD`:master

--force しているしあまり良くなさそう。もっと良いやり方が あると思う あったがとりあえずメモを残しておく

いま趣味で作っている Good First Issues を探す web application のバックエンドはこの方式でデプロイしてい る。 たが、heroku-buildpack-monorepo を使うやり方に切り替えた。

https://goofi.netlify.com/

github.com

(以下、追記)

buildpack を使うやり方

heroku-buildpack-select-subdir

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 

Procfile の書き方

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

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 

Procfile の書き方

heroku-buildpack-select-subdir と異なり cd backend のようなディレクトリ移動は必要ない。

web: bundle exec rails server -p $PORT

これは heroku-buildpack-monorepoAPP_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

最近の構成 (backend: Rails + PostgreSQL, frontend: React + TypeScript) を docker-compose で立ち上げる boilerplate 作った

TL;DR

github.com

Motivation

最近は "Backend developer" と名乗ろうが "Frontend developer" と名乗ろうが、web application を開発するエンジニアとして求められる知識は広範囲にわたることを、改めて実感しなおしている。

自分の経験でいえば、ここ数年は Rails エンジニアとしてやっているのだが、最近は React.js と TypeScript による SPA (Single Page Application) の開発にフル注力するプロジェクトをやっている。

その SPA はもちろんバックエンドにAPI、今回で言えば Rails がおり、Rails は DB に接続する。登場人物が増えるにつき同じく立ち上げるプロセスが増えていく。ローカル開発がきついので必要なアプリケーションとミドルウェアをいっぺんに立ち上げるのに docker-compose を使っている。

こうした技術要素をそれぞれ学ぶのは苦ではないのだけれど、余暇でいっぺんに学ぼうとすると近似した環境を手元で作るだけで疲れてしまう。

Rails-React-TypeScript-Docker Example

というわけで作ったのがこれ

https://github.com/ohbarye/rails-react-typescript-docker-example

名前が長過ぎる

Usage

$ 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 にも記事を書いた

dev.to

Roppongi.jsで『貢献できるOSSの見つけ方 -How to find "Good First Issues"-』についてLTをしてきました

第4回 Roppongi.js に参加し、『貢献できるOSSの見つけ方 -How to find "Good First Issues"-』というタイトルでLTをしました。

リンク付きの原稿はこちら https://ohbarye.github.io/slides/2018/roppongi.js-4/

紹介したスクリプト

github.com

Good first issues list

docs.google.com

発表に関して所感

全体的に尖ったLTが多かったので初心者向けとも見える自分の発表が近づくにつれて「滑るのでは〜」という不安がありました。

しかし終わってみれば何名かに声をかけていただき、概ね好評いただきありがたい限りです。懇親会で「今日のベストトークは?」という話をしているとき、ふらっと会話に参加された方に自分が登壇者だと気づかないまま「最後からの2番目のOSSのやつが良かったですね」と仰っていて心拍数が上がりました。

やっていったうえで次回の Roppongi.js で『続・貢献できるOSSの見つけ方』という話ができると良い

告知

LT内でも触れた、弊社で行うイベントはこちらです。7/19(木)は渋谷集合!!

techplay.jp

Cybozu Meetup で聞いた各社の技術ブログ運用の話と、Quipper のブログ再開について

Cybozu Meetup で聞いた採用文脈でのブログ運用の話と、Quipper のブログ再開の話です。*1

Quipper のブログ再開

所属する Quipper でも最近プロダクトチームのブログを再開しました。

quipper.hatenablog.com

自分も早速記事を書き、本日公開されました。

quipper.hatenablog.com

目的は中長期的な採用活動の活性化

目的は中長期的な採用活動の活性化です。具体的には、中高生向け教育事業という性質柄「Quipper が何をやっているか」が候補者(エンジニア)にとって分かり辛いという課題の解消と、エンジニアブランディングイメージの構築を目指します。

続けていくための方針

再開するにあたってどのように運用するのが望ましいかを社内で議論し、おおむね以下のような方針を定めました。

  • blog は当番制で書く
  • blog 書くのは必ず業務の範囲として行う
  • blog 書いたことをチームやマネージャがきちんと評価する
  • blog の内容チェックは GitHub の pull request や google documents などで行う
  • 可能な限り定量的に効果測定する
  • 半永久的に続けていく
    • 死んだブログを見ると悲しい
    • 死んだブログを見ると「この会社大丈夫かな?」と思う
  • エンジニア主導で行う、広報や人事主導で行わない

過去に更新が止まってしまった最大の理由は「当時の採用計画を達成したから」でした。もともと採用目的で開始し、長期的に続ける算段も元よりなかったのでそこに一種の潔さはありました。

しかしこのたび採用活動を再開するにあたり、ブログ等を通じてエンジニア界の耳目を再び弊社に集めていくのはなかなか短期決戦とはいかなさそうだという感触があります。それなりの"存在感-プレゼンス-"を保つには、やはり続けていかないといけない。続けるためには"善意-ボランティア-"ベースではなく継続的に運用できる仕組みづくりが重要だと考えました。

そこで比較的ブログの"存在感"があり、さらにはブログ運用が採用にも繋がっているという各社の話を聞いてみると、どうやらこの方針に関してはほとんど一致しているようで追認された心持ちです。

各社の取り組み

以下は Cybozu Meetup で聞いた採用文脈でのブログ運用の話のまとめメモです。登壇者が壇上で語っていた内容なのでオフレコなものは無いと思いますが聞き間違い、誤った内容があれば訂正させていただきます。

Cookpad Developer's Blog

  • エンジニア外村さんが中心になって回している?(運用の中心が誰かはわからず)
  • blog は採用効果あり、と断言。理由は応募のキッカケとして blog を挙げる人の割合の多さ (OSS への言及と並ぶ)
  • blog は AIDCA メンタルモデルの AID あたりに効いてくる (以下の図は Cybozu Meetup // Speaker Deck より引用) image
  • 1人あたり1エントリ/年かく。アウトプット・情報共有の良い機会になる。1年仕事をしていて blog に書くことがない、というのは危機感にも繋がる
  • blog は当番制でないと回らない
    • いっぱい書きたい人・ネタの鮮度を気にする人などが当番制に反対したが、当時のCTOの判断で当番制に押し切る
    • 実際、任意にすると書く人が偏る。記事も書く人の興味ある分野に偏る
    • 当番制にした2014年から記事の数が爆増した。立候補制では絶対届かない数字
    • 書きたい人はいくらでも書けばいい
  • (エンジニアに限定したくない、デザイナーやプロダクトマネージャも参加させたいから「Developer's Blog」にしたと言っていた気がする…?)

Cybozu Inside Out

  • 「コネクト支援部」というエンジニアと人事の混合組織が運用
  • もともと当番制で回していた
  • いっぱい書きたい人・ネタの鮮度を気にする人が当番制に反対し、当番制をやめてしまった
  • 結果、イベントレポートが多めになってしまった
    • 実際イベントをいっぱい開催しているのでそのアピールにはなっているが、技術力あるというブランディングになっていないのが課題

Recruit Technologies メンバーズブログ

  • blog は採用活動としてはうまく活用できていない
  • 立候補制
  • 書く人が少なくて困っている?
  • 広報の人が運用を担当している?
    • 広報の人は技術の記事を書けないので、イベントレポートが多くなりがち
    • 技術記事書いてください!という依頼が古川さんに集中してしまう

Cyber Agent Developer's Blog

  • キラキラしている
  • blog のデザインも実装も社内でやっている?

CA社のブログの話はあまり聞けなかった


*1:書き終えたあとに会社ブログに書く内容かも?と自問したものの、前者に関しては完全に個人的なメモを載せているだけなので個人ブログが良いと判断