日常

ケ・セラ・セラ

encrypted_secrets についてのメモ

v5.1.0.rc2 を使ってみていた。encrypted_secrets について確認したことをいくつかメモしておこうと思います。

まあ主に使い方はここ railties/lib/rails/commands/secrets/USAGE を見れば書かれているのですが、簡単に補足を加えつつ日本語でいきます。

encrypted secrets を使うにはまず、secrets:setup します。以下のようになります。

$ rails secrets:setup
Adding config/secrets.yml.key to store the encryption key: 40dc6a0dcf24059ce1edf48b7a242518

Save this in a password manager your team can access.

If you lose the key, no one, including you, can access any encrypted secrets.

      create  config/secrets.yml.key

Ignoring config/secrets.yml.key so it won't end up in Git history:

      append  .gitignore

Adding config/secrets.yml.enc to store secrets that needs to be encrypted.

      create  config/secrets.yml.enc

For now the file contains this but it's been encrypted with the generated key:

# See `secrets.yml` for tips on generating suitable keys.
# production:
#  external_api_key: 1466aac22e6a869134be3d09b9e89232fc2c2289…

You can edit encrypted secrets with `bin/rails secrets:edit`.
Add this to your config/environments/production.rb:
config.read_encrypted_secrets = true
$

config/secrets.yml.key に secret key が、 その key で暗号化されたファイルが config/secrets.yml.enc です。

また、secrets:setup により config/secrets.yml.key は、.gitignore に追加されています。

secrets:edit で、$EDITOR を使い secret file の編集ができます。

secret file を読み込む為には、config.read_encrypted_secrets = true します。config/environments/production.rb には最初から設定されていますね。

railties/lib/rails/secrets.rb を見ると、暗号化は default では AES-128-GCM でします。以下の p-r でそう変わっています。

https://github.com/rails/rails/pull/28139

日記です。Meguro.rb#2 2017/04/20(Thu)

Meguro.rb#2 に行きました。会場はドリコムさんです。

megurorb.connpass.com

さっちゃんさんの司会業が素晴らしくて、発表の中でも参加者およそ 30 並列の ping に pong 返すなどすごくて、とても楽しめる運びをしているのが印象的でした。

LT では Pocke さんの Ruby がむずかしい話がおもしろくて、発表の中で使っていた bacon-cannon が便利と思いました。print(% % %%%%) の出力とか分からんですよね。

前回(#1) から参加していますが、Meguro.rb は最初に良い感じに輪になって乾杯と自己紹介するのは特徴ですよね。LT の後ピザなどがデプロイされ各々良い雰囲気で話して盛り上がりました。RubyKaigi の話をしたり、偶然光の戦士を発見したり、雑談の中で I18n 知見がまた得られたりと、とても良い会でした。

日記です。渋谷.rb[:20170419]

渋谷.rb[:20170419] に行きました。会場はピクスタさんです。

shibuyarb.doorkeeper.jp

発表を聞いたり、終わっていない諸々を片付けたりした後は、mastodon と向き合って過ごしました。

tweet しつつ読んでいたところ、後半は tyabe さん、kaiba さんとそれぞれ気になるところを緩く談話しつつやっていました。良く知らないものを読んでいく作業を複数人でやると、一人でやっているよりも情報交換しながら進める分効率が良いですね。コードから入って得た学びとしては、WebFinger protocol, OStatus API, Salmon protocol 辺りを認知したことでしょうか。これらは日常生活では意識することが無かったですし。

github.com

あとは、RubyRails や Git や黒い画面のことや。人に教えるやり方について色々と話したり。4月っぽい話題もあっておもしろかったですね。

当日の様子です。

日記です。猫様に MacBook Pro Touch Bar を通って頂きました

今日は Touch Bar や Swift と自分にしては珍しいものに触れました。

同僚の Touch Bar は指紋認証以外いいことが無いという発言に完全同意でしたが、ふと猫様が歩いていたらそうでもないのではと思い、それと Swift に久しぶりに触れてみるのも良いかなという気持ちからスタートです。

Swift を書くのはおそらく 2 年(以上)ぶりでまったく全て忘れたような状態で始めて、インターネットの情報を頼りに 20 分程でできました。その前に 20 分ほど xcode の準備をしていたので全部で 40 分ほどです。

こんな様子です

今日はここまで。

日記です Shinjuku.go #1 〜大阪と中継でつないでカジュアルトーク〜

Shinjuku.go #1 〜大阪と中継でつないでカジュアルトーク〜 に参加した。会場は Aiming さんです。

https://shinjukugo.connpass.com/event/52929/shinjukugo.connpass.com

大阪と中継、良いですね。お互いやってる感が伝わるのも良いですし、運営の @yoshi_hirano さんの進行が素晴らしくて雰囲気がとても良かったです。

その場で見られたこともあって東京勢の発表が印象的でした。ライブコーディングが多いというのも特徴でしたね。ライブコーディングやる人はすごい。勇者だと思います。

@shiwano さんによる “Go でリアルタイムゲームサーバーを作っている話” では、API サーバが Rails、マッチングサーバが Go という構成でした。実例を見せて頂けるのは大変参考になりありがたいです。

質問は Issue に書く形式で行いました。 ( LT#1 - Goでリアルタイム通信ゲームサーバーを作っている話 · Issue #1 · shinjukugo/meetups · GitHub )

@voidofglans さんによる 犬でもできる!疑似生体SSH認証! は何というか発想が凄くて、動画を UP してもらえました。 わんこ。 on Twitter: "デモの動画撮りました。 撮影 @tenntenn w #shinjukugo https://t.co/s7PwfT0Q1B"

@void_of_glans さんの goパッケージで型情報を用いたソースコード検索を実現する では、静的解析の話の中で、Go は package が充実しているなということを改めて思いました。字句解析(go/scanner, go/token), 構文解析(go/parser, go/ast), 型チェック(go/types, go/constant) など。

いろいろと初の試みもある中、運営の方々ありがとうございました。とても勉強になり楽しい会でした。

様子

個人の日記です。今日はプロジェクト固有の rubocop の整理など

雑に書いていくと言ったので、今日も書きます。今日は A3! のアプリに大半を捧げ(夏組クラスタ)、キンプリアプリの告知に歓喜したり、残った時間でプロジェクト固有の rubocop の整理として project_cop な名前の gem を書きました。public にしたい所でしたが、色々仕方なしに private から始めることにしました。

README にポエムを書いたのですが、簡単には、

  • 会社で統一的な設定を用意すのは現時点では難しい(チーム固有の何かとかあるので)
  • けれど適当な単位(チームだったり、他のなにかだったり)ごとに rubocop の設定を共有できる仕組みや、public に公開できる環境であったら今よりも良いとは思う
  • 今現在、僕が一手でそこまで辿り着けそうな案がありません
  • が、こういう雑な一手がそこに近づく為の足場になる可能性はあるかなということでとりあえず push した

というようなことを考えてやっていました。引き続きやっていきましょう。

www.a3-liber.jp

prism-rush.com

その他

4月だし書いていきましょう。表参道.rb #21 ~ バックグラウンド処理 ~

久しぶりに書いています。一回止まるともうダメですね。

4月だしというにはもう7日で中途半端ではありますが、これからまた雑に書いていきたいと思います。

omotesandorb.connpass.com

自己紹介で、バックグラウンド処理でなに使っています。みたいに各自言ったりしていたのですが、その中では Sidekiq が多かったですね。僕もそうで、ジョブの実行とかには sidekiq-cron を使います。shoryuken を使われている方も多かったように見えました。SQS とあわせて知見ありがたかったです。バッチ処理デバッグとかみんなどうしてるの?とか気になりますね。

ActiveJob のリトライが、素で Sidekiq を使う場合に比べて弱いですがどうしてますか?みたいな疑問があったのですが、Rails5.1 ではその辺り改善されますよと教えてもらえたり、その後調べてみましたがこの p-r で入っていますね。

Add retry_on/discard_on for better exception handling by dhh · Pull Request #25991 · rails/rails · GitHub

後は I18n 知見が得られたり、Rails のフロント談義が出来たりとても勉強になる会でした。ありがとうございました。

次回お題はデバッグかな?ActionMailer かな?何かな?デバッグは人によって違いそうなのでおもしろそうですね。