Rails 5.2 の Credentials を各環境でも使えるようにする gem を作りました

rails

Rails 5.2 で追加される Credentials 機能を development, test, staging などで使えるようにする gem を作ったので紹介します。

github.com

Rails 5.2 の Credentials とは？

API token やパスワードなどの情報を暗号化し、リポジトリで管理できるようにする機能です。 暗号化に使用する鍵は config/master.key もしくは RAILS_MASTER_KEY 環境変数を使います。

今までの Rails では秘匿情報を環境変数で管理するのが主流でした。 しかし、この方法では管理する環境変数が多くなってしまったり、バージョン管理できません。

5.2 で導入される Credentials の機能を使うことで、秘匿情報をリポジトリで管理することができるようになり、サーバに設定する環境変数も1つで済むようになります。

Rails 5.1 で追加された encrypted secrets に似ている？

This will eventually replace Rails.application.secrets and the encrypted secrets introduced in Rails 5.1.

引用: https://github.com/rails/rails/blob/v5.2.0.rc1/activesupport/CHANGELOG.md

encrypted secrets は忘れてください。

Credentials の不満点

DHH曰く「productionしか秘匿情報は必要ない」とのこと。

It's only in production (and derivative environments, like exposed betas) where the secret actually needs to be secret.

引用: https://github.com/rails/rails/pull/30067

いや、staging 環境で使う API token とかがあるので他環境でも使いたい...(´・ω・)ｯｽ

別の方が Environment-specific credentials という Issue を作っていますが、 Close されてるし、 Rails では対応されなそう。

各環境の秘匿情報を管理する gem を作った

そんな経緯で RailsEnvCredentials の gem を作りました。

各環境で別々の credentials.yml.enc を使うことができます。

基本的な使い方

Gemfile に gem を追加して、 bundle install してください。

group :development, :test do
  gem 'rails-env-credentials'
end

もし staging 環境で使う場合は group に :staging も追加する必要があります。

development 用の credentials を生成するには env_credentials:edit コマンドを使います。

$ rails env_credentials:edit -e development

development 環境用に credentials-development.yml.enc が生成されます。 鍵は config/master-development.key か RAILS_MASTER_KEY_DEVELOPMENT 環境変数を使います。

秘匿情報の diff を表示する

credentials.yml.enc は暗号化されているため、普通に git diff をしても差分は表示できません。

$ git diff config/credentials.yml.enc
diff --git a/config/credentials.yml.enc b/config/credentials.yml.enc
index 1a69bf0..c0517de 100644
--- a/config/credentials.yml.enc
+++ b/config/credentials.yml.enc
@@ -1 +1 @@
-SN7yXV6C2NZSdp/ij84h6Tox7iJ6VLHWgnhbY7BFe5TTsLa6V9g1D/iI1H5WMCBEECcpL/z096spDpcjXdq1aS2w3Wz9GijvuCiJNA8LaiWzqN9FMDmPB8eJjff+qebG+mN4Wdmc1/LDWV0GvYYQWAzDuYv3Kyv7jrxh/6MQjm2h9+i1AlBj7ofnzppvz9m8yiM2kyoqk/5aFdNiUqCdvzqbxIAXf0qvL/GPezKVOgbLcKL+/ytIFDvQeFc+BJ9d/RHsvOfyy1hSJxAhstJsf9I2WlI8gWYBjNip6nZzEQUCuhJpFEd+tXTzTOt3ZlWHzodQA9W3E+BScDOUgAPM7eJ9eCCDHvSQrvgI9i9KfpuxFP51OTODqYkR1+kfW7g/ZupvAhwMAM504af7zFLgHxad5Q==--UjL1q8veV48t5/oe--pUi30wtwFBJlM5PIJI0U2A==
\ No newline at end of file
+i3rH3HDSUPAwal/Mi8SsFg+UqKfyudpjTxFpYrXxElOvQYo7wsIZ9v5NRe6mew/WnMNiM/B66jJM4KIf1voMRWrTJaGfkWc4ARLjgcgLNu4rj4+LHyZZ2LkkgqZpTHObtLHEH5E/7ZNQVpHJ1CwfMR/SwGgaDPJFVbM3uF3tGSzY0Fyg3jgeyiiU6Vuk+H6CUGFMxDsjnIj1oMrpACX42vDfpy5wZquyzycG6LpmJsFqofirmb9sT1n32mDoA6k138SDLdnUiNpftNGGK8q9+SaT8e5OzZ8CMSeMLD64psRYCL+qZip+ZX0zvdVmSkUaH/y71bkHTChhMNZzHcW69FBNgfirMmWchjePUlw1+LIjrAIQL9JQD5Wv3E5Yl6RRKX0LSsrtUqEmABz9Lxbq9uGh/HEsC2OnrLOGYFvvKYs53Y1lQVF29f3NKSdk--VINiczKtUJKG4hro--oRD2+JF7lbL/wO8d3dP0Mw==
\ No newline at end of file

これは Git の設定を活用することで表示できるようになります。

まず、下記の内容で .gitattributes を作成します。

config/credentials*.yml.enc diff=env_credentials

次に Git に復号化のコマンドを設定します。

$ git config diff.env_credentials.textconv 'rails env_credentials:show --file'

この状態で git diff を実行すると、復号化した内容で差分が表示されるようになります。

$ git diff config/credentials.yml.enc
diff --git a/config/credentials.yml.enc b/config/credentials.yml.enc
index 1a69bf0..c0517de 100644
--- a/config/credentials.yml.enc
+++ b/config/credentials.yml.enc
@@ -4,3 +4,5 @@
 
 # Used as the base secret for all MessageVerifiers in Rails, including the one protecting cookies.
 secret_key_base: 358e4c7f994ffdba2a8994c00bf902303d1456d1f4d4e3d8e6c6c843628de5bc158f061fd1759b7a4a015395627ad9b34a4e8714167da0387695cb9906bbe1ba
+aws:
+  access_key_id: 123

まとめ

production 以外での秘匿情報の管理って需要ありそうだけど、Rails にプルリクを投げて英語で説得する自信は無かったので、とりあえず gem を作ってみた。

もし gem が結構使われて、需要ありそうってのが分かったらプルリクを投げるかもしれない。

2月末に株式会社groovesを退職します

2018年2月末に株式会社groovesを辞めます。

おそらく、退職エントリってやつです。

株式会社groovesでやってきたこと

Forkwellの開発を担当していました。サービスの詳細はリンク先を読んで頂くとして、私が主に関わっていたのは下記の2つです。

特にPortfolioの「エンジニアの技術力を可視化する」というコンセプトは私の提案から始まっていて、仕様の作成、設計、実装とだいたい全てを担当していました。

技術的にやってきたこと

新しい機能の実装以外で、開発環境を色々と改善してきました。

  • Werckerを導入して、ブランチ毎にテストを実行するようにした
    • Jenkinsをリストラした
  • wheneverでcronの設定をコード化した
  • RuboCopを導入して、少しずつコードを直した
  • Rails 5 のリリース日に最速アップグレードをした
  • 自動で毎日bundle updateのプルリクを作るようにした
  • 独自ログイン機構を改善して、最終的にdeviseに置き換えた
    • Email認証が実現できるようになった
    • ログイン処理のコード複雑度を激減させた
  • 稀に落ちるテスト、Slow Testをたくさん直した
    • CIの実行時間を20分から8分に高速化した
  • Serverspec を導入した
  • Terraformを導入して、インフラをコード化した
    • staging 環境のインフラをコード化し、少しずつリファクタリング中
    • production 環境のインフラはまだコード化できていない...

パッと思い出したのだけ書き出したけど、他にもたくさん開発環境を改善していたと思います。

今まで退職しなかった理由

開発環境を改善し過ぎてしまい、快適になってしまったのが１番の理由です。*1

  • Ruby/Railsはすぐ新しいバージョンに上がる
  • テストコードもあるので簡単にアップグレードできる
  • プルリクのコードが綺麗で、コミット数も少なめ
  • ちゃんとレビューしてもらえるし、キツい口調のレビューは無い
  • 新しいツールやサービスを導入することに肯定的
  • Railsで困っても弊社取締役の@amatsudaさんに質問できる

Railsエンジニアにとってはなかなか良い開発環境だと思います。

あと、エンジニア向け自社サービスなので自分達で仕様を考えることもできますし、厳しい納期もないためストレスなく開発できました。

なぜ退職するのか？

細かいのはいくつかあるのですが、主なものは下記の3つです。*2

1. 規則正しい勤務が苦手

これ完全に自分のせいなのですが、朝起きるのが苦手だったり、深夜にコードを書くのが好きだったりして、規則正しい生活がとても苦手です。 groovesの勤務時間は9:55〜18:55とそこまで出社時間は早くないのですが、それでも時々遅刻したり、タクシーで出社していました。

この件は1on1で上司に相談したところ、リモート勤務やフレックス制度などの制度が導入されました。これにより、最近は柔軟な働き方も出来つつあります。 ただ、個人的に欲しかったのは「10分遅れてもSlackで連絡すれば問題ない雰囲気」や「深夜に仕事しても良く、翌日は遅く仕事しても良い」とかで、これはまだgroovesで実現されていません。

2. 自分の技術力に不安を感じた

転職というイベントは人生に数回しかないため、転職サイトのアクセス数はあまり多くなくて、データ量も少ないです。 勉強会で他社エンジニアの「高負荷の話」や「冗長化の話」などの発表を聞くたびに自分の技術力に不安を感じていました。

もっと色々なサービスのインフラ構成やコードを見たいと思いましたが、それはgroovesにいると難しそうだと感じました。

3. 高い年収や福利厚生の充実している会社が多い

Speeeさんの「個人サーバー代補助制度」やMisocaさんの「勉強会への参加補助制度」など、エンジニア向けの福利厚生が充実している会社はいくつもあります。

groovesはそんなに福利厚生が充実していないので、こういう話を聞くと羨ましいなーと思っていました。 特にRubyKaigi 2017に自費＋有給で行ったときは話を聞くたび、「転職しようかな？」ってちょっと心揺れていました。

あと、Forkwell Jobsを見ていたら高い年収帯の求人がいくつもあって、「これ転職したら年収が上がりそう」と時々考えていました。

3月以降の予定

そんな感じで退職意欲が高まってしまったので、辞めることにしました。

ただ、3月以降の予定はまだ決まっていません。

候補1. 週4でgrooves、週1で他社のお手伝い

groovesとの音楽性の違いにより正社員は辞めますが、Forkwellの目指している世界と開発環境はとても好きなのでフリーランス週4で続けられないか打診しました。 上司からも快諾を頂けたので、おそらくフリーランスで継続になりそうです。

週1は「別の会社のお手伝い」か「OSSの活動」が出来たら良いなと思っている。

などを週1でさせて頂ける会社があれば、ご連絡頂けるとありがたいです。

候補2. 良い条件の会社に転職

groovesより良い環境、条件を提示して頂ける会社があれば、これを機に転職するのもアリかなと思っています。

  • 勤務時間にあまり厳しくない(大事)
  • モダンな開発環境が整っている
    • Pull Requestを出して、レビューする文化
    • 新しいRuby/Railsを使っている
    • インフラがコード化されている
  • そこそこコードが綺麗
    • また直し続けるのは避けたい...
  • プロダクトが面白い
  • 福利厚生が充実している

といった会社で、朝弱いダメ社会人Railsエンジニアでも話をしてみたいという採用担当者様がいればご連絡ください。

3月以降の予定まとめ

2月末に株式会社groovesの正社員を辞めて、3月以降は

  1. 何も連絡なければフリーランスになって、groovesで週4勤務
  2. 面白い話があればフリーランスになって、案件を2つくらい掛け持ち
  3. 他社から良い環境・条件を提示されたら他社に転職

のどれかになります。

さいごに

3月以降にgroovesとどのような関係になるかはまだ分かりませんが、Forkwellは良いプロダクトなので今後も何か関われたら嬉しいなぁと思っています。

開発環境・職場環境の改善に尽力されてきた上司の赤川さん、Forkwell開発メンバーやその他groovesでお世話になった皆様に感謝の意を表して、このエントリを締めたいと思います。*3

*1:ただし、インフラを除く

*2:細かいのやWeb上に書けないやつは飲み会で聞いてください

*3:まだ2月末まで1ヶ月くらいありますけどね

git-worktree を使って時間のかかる処理を別の作業ディレクトリで行う

git

時間のかかる処理の実行中、別の作業を進められるようにする方法。備忘録。

時間のかかる処理の例

  • テストの実行中
  • デプロイの実行中

など。

git-worktree を使う

簡単に作業ディレクトリを増やせる。

$ cd ~/works/app
$ git worktree add ~/works/app_deploy
$ cd ~/works/app_deploy
$ git status
On branch app_deploy
nothing to commit, working tree clean

新しく作成された app_deploy の作業ディレクトリでも普通のリポジトリと同じように作業ができる。

注意点

両方の作業ディレクトリで同じブランチを使えない

作業ディレクトリを2つに増やしても、同じブランチは使えません。 別名のブランチを作る必要があります。

リポジトリは共通

リポジトリの内容は共通なので、git remote や git config を使う時は注意が必要です。

.gitignore のファイルは複製されない

git 管理されていないので当然なのですが、初めて git worktree を使うとハマるかも。
direnv を使っている場合などはシンボリックリンクを使うと良い。

$ cd ~/works/app_deploy
$ ln -s ~/works/app/.envrc .

Git を少しでも高速、安全に使う方法を紹介

git

はてブを眺めてたら、なんか Git の記事がバズってたので、便乗して Git の話を書いてみた。

基礎知識

git-reset は危ない

git reset --hard は作業ディレクトリにコミットしていない変更があった場合、全てを吹き飛ばしてしまう可能性があります。

使う前に必ず git status を実行して、作業ディレクトリの状態を確認をした方が良いです。

git-checkout は遅い

checkout コマンドは作業ディレクトリの状態を変更します。このとき ファイルアクセスが発生するため遅い です。

git-branch -f は速くて便利

git branch -f は同じ名前のブランチがあっても無理やりブランチを作成できるコマンドです。

git-reset と異なり、任意のブランチを弄れるため非常に強力です。

少しでも高速、安全に使う事例の紹介

基礎知識を紹介したところで、いくつか事例を紹介します。

間違ってmaster ブランチで作業してしまったとき

よく紹介される方法は下記のコマンド。ちなみに @ は HEAD と同じです。

$ git branch new-branch
$ git reset --hard @~
$ git checkout new-branch

このコマンドだと2つ問題がある。

  1. reset --hard で未コミットの内容が吹き飛ぶ危険性
  2. checkout を使っていて遅い

少しだけ改善したコマンドは下記の通り。

$ git checkout -b new-branch
$ git branch -f master @~

これなら checkout のファイルアクセスも最小で、未コミットの内容があっても消えません。

master ブランチをリモートに追従したい

よくある方法はこちら。

$ git checkout master
$ git pull origin

checkout してブランチ移動すると作業が止まるし、ファイルアクセスもあって微妙ですよね。 そこで branch -f ですよ。

$ git fetch origin
$ git branch -f master origin/master

どんなに master と origin/master が離れていても一瞬で実行が終わります。

より安全に master ブランチをリモートに追従したい

branch -f や reset --hard は怖いって人にオススメのコマンドがあります。 rebase です。

$ git fetch origin
$ git rebase origin/master master

これならコミットしていない変更があれば rebase が実行できませんし、コンフリクトが起きたら git rebase --abort で元の状態に戻すことができます。

ブランチから辿れないコミットを探す方法

git reflog を使えば、だいたいなんとかなります。（使い方は適当にググって）

あと、 git reflog show <branch_name> でブランチの履歴が表示できるので、もし git branch -f でミスっても簡単に戻せます。

ブランチや reflog で辿れないオブジェクトを探す

git fsck --lost-found の使い方は昔ブログに書いてあるので、それを参考に頑張って探しましょう。

git add さえしていれば、ギリギリなんとかなる。 git add をしていない作業は諦めて。

sinsoku.hatenablog.com

まとめ

git branch -f は速いし、ミスっても git reflog show <branch_name> で簡単に復旧できるので、みんな使いましょう！

「Randomly Failing Specs」という内容でLTしました #railsdm

rails

資料は Slide Share で公開しています。

www.slideshare.net

話したかったこと

時間切れで全く話せていませんでしたが、本当は「 sleep 使わずに直しましょう」って事が伝えたかった。 資料の作り方や発表内容で完全に失敗してる。

このブログ読んだ方は是非スライドの図を見て、 Capybara のお気持ちを感じ取って欲しい。

他のLT登壇者はだいたい最後の方まで話せていて、流石だなーと思いながら聞いていました。

同人誌

電子版を BOOTH で公開してみました。*1

booth.pm

紙版を購入頂いた方には無料で電子版をお渡ししたいと思っていたので、パスワード付zipを使って用意しました。 パスワードを生成するのが面倒なのですが、他に良い方法が思い浮かびませんでした。申し訳ない。

次回の技術書典では、最初から電子版を用意したいと思います。

*1:というか、これに手間取っていてブログ公開が遅れていた

Rails クイズ: 次のコードで rollback されるのはどれでしょう？

ruby rails

先日、仕事のコードで遭遇して「なんだこの動き...」と思ったので、ブログに書いておく。

Rails クイズ: 次のコードで rollback されるのはどれでしょう？(配点10点)

常にバリデーションエラーになるモデル Bomb と no 属性によってコールバックを制御できる User クラスがあります。

# app/models/bomb.rb
class Bomb < ApplicationRecord
  belongs_to :user
  validate -> { errors.add(:base, ':bomb:') }
end

# app/models/user.rb
class User < ApplicationRecord
  has_many :bombs
  has_one :bomb

  attr_accessor :no

  before_validation -> { bombs.build }, if: -> { no.to_i == 1 }
  before_create     -> { bombs.build }, if: -> { no.to_i == 2 }
  before_validation -> { build_bomb },  if: -> { no.to_i == 3 }
  before_create     -> { build_bomb },  if: -> { no.to_i == 4 }
end

このとき、下記の 1〜4 のコードの内で「 ロールバックされて、DBに保存されない 」のはどれでしょう？ 全て挙げなさい。

User.new(no: 1).save!
User.new(no: 2).save!
User.new(no: 3).save!
User.new(no: 4).save!

解答について

解答を書くと面白くないので、気になる人は試してみましょう！

「プロを目指す人のためのRuby入門」を読んだ感想

ruby

一応、お仕事で Ruby やっているプロだけど、本の内容が気になったので買ってみました。

昨日、先行販売している紀伊國屋書展 新宿本店で購入（正式発売日は11月25日）。

ラス2だったので、結構ギリギリ。そして、一気に読んでみた。

技術書は油断するとすぐ積み本に進化するので、意識高まった時に読み切った方が良い。

私のRuby力

  • プログラマ歴は10年くらい
  • 仕事で Rails を6年くらい
  • Rails 含め gem のソースコードは普通に読む
  • メタプロやモンキーパッチは普通に使う
  • gem にプルリク投げることもある

どう見ても、Ruby入門者ではない。

本の感想

対象者について

本書はプログラミング未経験者向けの本ではない点に注意してください。 http://blog.jnito.com/entry/2017/11/20/054316

著者の @jnchito さんも自身のブログで紹介しているように、プログラミング未経験者向けではないです。 ただ、「入門書なので Ruby 上級者には役に立たない」なんて事もなかったです。

初心者と中級者は悩む必要なく買って良いと思います。 将来、プロとして Ruby のプログラミング書くなら、これだけ実践的で分かりやすい本を買っておくのは良い投資です。

gem のソースコード読んだり、メタプロ使いこなすような上級者に関しては9割知ってる内容だと思うので、ざっと目を通して Ruby 雑学*1を理解したあと、周りの初心者にオススメするのが良いです。 上級者の方々は若いエンジニアに教える機会も多いだろうし、そういう時に役立つと思います。

Windows 環境をフォロー

Web 上には動作環境の記載されていない情報が溢れているので、初心者だと問題が起きたときに調査に時間かかることが多い。

本書には Windows 環境で起こる問題への対応方法が丁寧に書かれているので、入門者でも安心して読めそうです。

エラー内容を日本語で説明

「エラーメッセージを読み、理解してからソースコードを直す」といった慣れた人にとっては当然の所作を、入門者でも分かるように手順を1つずつ説明していて、このあたり流石だなと読みながら感じました。
英語のエラーメッセージに日本語訳もつけてあるので、英語が本当に苦手な人でも本書は理解しながら読み進められると思います。

さらに「英語が苦手でも辞書片手に調べるのが大事」「Webの記事は注意して読みましょう」など、英語から逃げずにエラーメッセージをちゃんと読む姿勢についても言及されていて非常に良い。英語を読むのは本当に大事。

サンプルコードが豊富

サンプルコードは基本的にテストを先に書くようになっており、自然とTDDの基本的な考えを学べるようになっています。

Ruby は動的言語なのもあってテスト書くのがとても大事なので、「テスト書くのが普通」になるような例題の作り方は素晴らしいと思いました。

個人的に勉強になったもの

だいたい知っている内容だったのですが、個人的に「へぇー」と思ったのは下記の2つ。

  • splat展開で配列を結合する話
  • :: でメソッド呼び出しできる話

仕事で使うかは微妙だけど、Ruby 雑学として勉強になりました。 あとは「ここ数年使ってないけど、そういえば（そんな記法も）あったな」て内容がちょこちょこ紹介されていて面白い。

入門者に紹介したくなった項目

本読みながら、「ここに1行追加して入門者に紹介したい！」って事が1つあったので、ブログで紹介しておきます。

Predicate Methods / Bang Methods

英語だと?で終わるメソッドは「Predicate Methods」、!で終わるメソッドは「Bang Methods」と呼ばれています。

Web の記事を読んだり、検索する際に知っていると少し便利です。

本書の良くないところ

個人的に何かを勧めるときはデメリットも挙げておくのが好きなので、あえて書いてみる。

と Twitter にも書いたように、リーダブルじゃない記法まで紹介されていて少し気になりました。 入門書なのに、メインの章内でほぼ使わないような記法まで紹介されていて、入門者にとっては覚えること多くて少し大変かも？

とはいえ、微妙な記法には必ず「極力使わない方が良いです」と説明されていますし、「プロを目指すため」なら知っておくべきなので、紹介されている方が良い気もする。

無理やり挙げた感じのデメリットです。
というか、他に挙げるところが思い浮かばないくらいに良い本だったんですよ。

まとめ

「分かりやすく、読みやすい。そして、実践的。」

と、Ruby 入門としてはかなり良い本ではないかと思います。

あと、個人的にはサンプルコードが豊富で写経しやすい本なので、電子書籍よりは紙の方が便利かなと思いました。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで

*1:仕事で使うには読みづらく、微妙な記法だけど Ruby としては正しい構文