valid,invalid

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

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

Roppongi.jsで『エンジニアも気にしたい色のアクセシビリティ』についてLTをしてきました

第3回 Roppongi.js に参加し、『エンジニアも気にしたい色のアクセシビリティ』というタイトルでLTをしました。

スライドのタイトルを575にしたかったものの「エンジニア アクセシビリティ 気にしよう」のような駄作しか生まれなかったために断念しました。

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

スライド

今回は reveal.js を初めて使ってみたので「ワイは"東京者-オシャレ-"や〜!!」という気持ちで臨んだものの、"同じタイプのスライド使い"がいっぱいいて椅子から転げ落ちそうになりました。

やっぱり"東京-Roppongi-"ってすげぇ…っ…!!

所感

このへんは自分の意識の低さもあるが、これまでで厳密にアクセシビリティにこだわるプロダクトを開発した経験がないのでどうにかしたいと思うところ。

染色体

時間の都合で言及できなかった、男性の色覚障害者の割合が多い理由です。

Roppongi.js

初参加でした。

  • テーマが多岐にわたっていて面白かった
  • 自分のようなサーバサイドエンジニアでも楽しめた
  • 一方、もはや JavaScript というくくりだけでは共通認識を持った集団を形成するのは難しそうだなと感じた
  • 懇親会
    • GraphQL 実戦投入話などをして"波"の高まりを感じた
    • Web を拡張する次の一手としての VR としての面白さについて語れてよかった
    • ピザがおいしかった

また参加したいと思います(月並み)

Rails のフロントエンドのレベル上げ

第15回 Meguro.rb に参加し、『フロントエンドのレベル上げ 〜Rails エンジニアが Webpacker を使う場合〜』というタイトルでLTをしました。

お気付きの通りスライドと本記事のタイトルが違いますが、スライドのタイトルを575にし忘れるという痛恨のミスがあり、せめてこの記事はと思い575にしました。

リンク付きの原稿はこちら slides/2018/meguro.rb-15 at master · ohbarye/slides · GitHub

言い足りないことと反省

スライド中で触れている業務で取り組んだフロントエンド改善の取り組みには半年近く要しており、これを10分にまとめるのはなかなか難しいと感じつつ資料を作成していた。

あまり触れなかったけど話そうと思えば話せるトピックはざっと考えただけでこれだけ↓ある。包括的に語るには30分枠かそれ以上になってしまう…ので機会があれば長枠でもう一度話してみたい。

  • プロダクトの特性
  • 負債返却に取り組む時間をどのように捻出するか (技術的負債を抱えながら突っ走る -日々15分の改善活動- - valid,invalid)
  • 新しい技術を導入する際にチームでどのように合意を得ていくか
  • 巨大な変更を入れるときのレビューのやり方 (レビュー会のすすめ - valid,invalid)
  • Webpacker を使う際の具体的な tips や注意点、またはステップバイステップで使う方法の詳細
  • webpack-dev-server もシュッと立ち上がる開発環境
  • Partial single page application パターンで実装するときに気をつけること
    • なんでも盛り込むと bundle size のコスパが悪くなる
    • webpack-bundle-analyzer でのチューニングした話
    • preact などの軽量ライブラリに切り替えるか検証したがやめた話
    • polyfill
  • form 用ライブラリ formikyup について
    • redux-form との比較
  • フロントエンド周りの OSS 探索を楽しんでいる話
  • 得た知識で node.js, yarn などにコントリビュートするまでの話

各々、プレゼンテーションの中で少しずつ触れたものの、全体としてはまとまりを欠いてしまったかもしれない。実際に時間オーバーしてしまったのも反省。10分枠ではせめて1つか2つぐらいのトピックにフォーカスしないといけない。


Meguro.rb

初参加でした。

  • アットホーム。リブセンス社の会場がちょうどよい感じだった
  • 大学生が来ていて感心した(おっさんくさくなってしまった)
  • 料理がおいしかった

また参加したいと思います(月並み)