あーありがち

過去の日記 2019-12 2019-11 2019-10 2019-09 2019-08 2019-07 2019-06 2019-05 2019-04 2019-03 2019-02 2019-01 2018-12 2018-11 2018-10 2018-09 2018-08 2018-07 2018-06 2018-05 2018-04 2018-03 2018-02 2018-01 2017-12 2017-08 2017-07 2017-06 2017-05 2017-04 2017-02 2017-01 2016-12 2016-10 2016-09 2016-08 2016-07 2016-06 2016-05 2016-03 2016-02 2016-01 2015-12 2015-10 2015-09 2015-04 2014-10 2014-07 2014-06 2014-05 2014-02 2014-01 2013-12 2013-10 2013-09 2013-08 2013-07 2013-06 2013-05 2013-04 2013-03 2013-02 2013-01 2012-12 2012-10 2012-09 2012-08 2012-07 2012-06 2012-05 2012-04 2012-03 2012-02 2012-01 2011-12 2011-11 2011-10 2011-09 2011-08 2011-07 2011-06 2011-05 2011-04 2011-03 2011-02 2011-01 2010-12 2010-11 2010-10 2010-09 2010-08 2010-07 2010-06 2010-05 2010-04 2010-03 2010-02 2010-01 2009-12 2009-11 2009-10 2009-09 2009-08 2009-07 2009-06 2009-05 2009-04 2009-03 2009-02 2009-01 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ GCPのサービスアカウントの鍵を作って持ち出す必要がなくなった

背景

去年触っていた時は

Key Management Serviceについて勘違いしていたこと - あーありがち(2018-10-21)

こんな感じで、

• GCPの中にコードを送り込むことを自動化する際にサービスアカウントを使うので、そのアカウントの鍵が必要
• pkgcloud が keyFilename がないと激おこ

という理由で鍵をどう管理するかを考えていたのだけど、事情が変わって鍵の管理を全部不要にできたので、これをまとめておく。

まとめ

• pkgcloud が 2019-04 時点で依存 npm を gcloud から @google-cloud に乗り換えたおかげで client library の挙動が正しくなった
  • 動作時のサービスアカウントの default credentials と permissions を取得できる
• Cloud Source Repositories & Cloud Build を使うことで Google Cloud の外から中へ入れる必要がなくなった

結果、サービスアカウントの鍵を Google Cloud 外に持ち出す必要はなくなった。

なくせたこと

これまでサービスアカウントの鍵を外に持ち出しつつリポジトリの中に鍵を納めないようにするため、

• あちこちの環境変数に鍵の中身をぶちまける
• 必要に応じてこの環境変数の中身を鍵ファイルとして書き出し、その鍵ファイルのありかをコードに教える
  • 例えば deploy 時、例えば実行時

という作業とコードの準備をしていたのだが、これらが一切不要になった。めでたい。

ではこれを可能にしたサービスを紹介する。

Cloud Source Repositories

Cloud Source Repositories  |  Google Cloud

• Cloud Source Repositories は GitHub と Bitbucket に対して同期する機能を持っている
• 同期の際の認証は OAuth

この時点で Google Cloud の外から中へ持ち込むという課題はクリアしている。外から中へ持ち込むのではなく中から外へ取得しにいく形になる。

なお、次の Cloud Build の関係で、リポジトリはプロジェクト単位で作ることになる。Google Cloud は staging 環境用にもう一つプロジェクトを作ることを推奨しているので、production 用と staging 用のプロジェクト別にリポジトリを持つ形になる。

Cloud Build

Cloud Build - 継続的インテグレーションのためのビルドの自動化  |  Cloud Build  |  Google Cloud

• 設定は cloudbuild.yaml か Dockerfile で行う
• 各ステップ用に Docker コンテナが用意してあってそれらに YAML ファイルから指示を出す

これだけ読むと最近よく見るクソ面倒くさい CI/CD のように見えるが、少なくとも deploy に限ってはかなり簡単。理由は以下の通り。

1. Cloud Build が動き始めている段階で「目的のプロジェクトに属している状態で、かつその Project ID は環境変数として持っている
2. gcloud コマンドのインストールは不要（それ用のコンテナがある）
3. サービスアカウントの activation も不要（そもそもコンテナが Cloud Build 用のアカウントで動いている）
4. build の動く条件は cloudbuild.yaml 内ではなく trigger の方に指定する。cloudbuild.yaml 内に面倒な分岐は書く必要がない
   • 1 の関係で deploy 先のプロジェクトは分かっているのでこれの切り替えも不要

少なくとも Google Cloud 外の CI から deploy するのに比べるとマジで何倍も楽。マジ。

Cloud Build もうちょっと早く出会いたかったぜ…。

参考

• GAEアプリの開発フローにCloud BuildでのCI/CDをいい感じに組み込む - Sansan Builders Box
• GCP Cloud Build の基礎からの説明 & CI/CD 実践 | クラウドサービス徹底比較・徹底解説 (2019年版)

_ 富山Ruby会議01に参加してきた

富山Ruby会議01

Ruby会議に参加するのは Final 以来なので、実に8年ぶりなのです。

• The Final RubyKaigiに途中参加してきた - あーありがち(2011-07-19)
• 日本Ruby会議2011(7月16日〜18日)

The Final RubyKaigi は Kanazawa.rb をやろうと思った大きなきっかけの一つになった「アンチぼっちランチ」のあったイベントです*1。

あの頃はずっと悩んでいた。あれから8年、懇親会で、進行から外れてゆっくりあちこちのテーブルを楽しむ @kakutani さんと「いつぶりでしたっけ？」「Finalです」「えー？ いつ？ 10年前？」みたいな話ができたのは富山Ruby会議01のおかげです。ありがとう。

今回はほとんど地元みたいな富山で、喋る側になって参加したので、前回と感じることはずいぶん変わっていました。

若い子が増えた

自分が歳をとったのだからある意味当たり前なのだけど、いや、それって Ruby コミュニティがまだ代謝してるってことだからね？ これはやはり大きいですよ。金沢ではなかなか感じることができないんだけど、まだ Ruby コミュニティはちゃんと代謝していました。すごい。*2

地域エンジニアコミュニティの「広がり」の難しさ

今回、01 ということで、Ruby はそんなにあぶなっかしくも怖くないし、Rubyist はあたたかく迎え入れてくれるよというメッセージが（特に前半は）多かったのですが、これは裏を返すとまだまだ地方ではそういうメッセージが必要なのかな？ という風に受け取ることもできます。まーそらそうかもしんない。もう自分にとっては当たり前になって久しいことも丁寧に説明されている様子を見て、こういう基礎的な部分も定期的に必要なのかもしれないなーと思うことができました。

懇親会では 02 どうしよう、今後どうしていきたいか悩んでいるという話の流れの中で「実は Hokuriku.rb ってあったんだよ」という話もできました。「規模を追わずにコンパクトにしつつ、裾野を広げるために、何より自分たちが楽しむために内容は絞らない」という Kanazawa.rb の選択は、kanazawa.js や Hokuriku.rb という先輩がいたから導出できたものなのです。これを伝えることができて本当によかった。Hokuriku.rb も富山生まれなんだぜ。

ハードコア部隊はやはりよいね

Final RubyKaigi の時、理解できるか分からないけど飛び込んだセッションを思い出しました。

• RubyVM の話
• Ruby AST の話
• mruby parser/generator の話

こういう楽しみ方もいいよねー。

ライブコーディングは鬼門だけど(笑)

_ chokidar-cliとパイプを使って本当に変更のあったファイルだけ何かしたい

kimmobrunfeldt/chokidar-cli: Fast cross-platform cli utility to watch file system changes

chokidar <files> -c '<command> <files>' 方式は無駄が多いかも

chokidar を使った処理でよく見るのは以下のような方法だと思う。

chokidar '**/*.js' -c '<command> **/*.js'

この方法だと監視対象のいずれかのファイルに何らかのイベントが発生した場合に、対象ファイル群すべてに対してコマンドを実行してしまう。すべてを対象にトランスパイルして bundle ファイルを生成するような処理なら仕方ないが、一つ一つの処理が独立していてお互いに関係せず、かつそこそこ負荷が高い場合には別々に実行したい。

chokidarはコマンド実行だけはなくイベントのstream outputもできる

chokidar は対象ファイル群を watch し始めたら、検知したイベントとファイル名を

イベント:ファイル名

の形で stdout に出力する機能を持っている。

この出力を受け取って何らかの処理をするコマンドを作れば、上のような無駄を防げる。

ただし、注意が必要

愚直にパイプで繋いで

chokidar <files> | <command>

ってやってしまうと、以下のような無駄な出力も受け取ってしまう

1. yarn run コマンドの出力 ( yarn run <version> )
2. chokidar コマンドを起動した文字列そのまま
3. unlink したファイル

1 と 2 は単純に chokidar の出力が始まる前のものなので、そもそも必要な情報が入っていない。unlink イベントは chokidar の反応なのだが、unlink されているファイルに対して何らかの処理をするコマンドを叩いてもエラーにしかならないので、これも除外する必要がある。

本当に欲しかったもの

総合すると必要なものは

chokidar <files> | <filter> | <command>

のような形。

実装例

実際やったのは PlantUML の render で、以下のような感じ。

chokidar "**/*.plantuml" | awk -F : "
  !/unlink|run|\*/ {
    print \$0
    system(\"plantuml -headless -tsvg \" \$2)
  }
"

これで処理対象の PlantUML のファイルが増えても最小のコストで re-render できる。

chokidar なんか名前が好きじゃなくて敬遠してたんだけど、この機能はよい。とてもよいぞ。好きになった（簡単）。

_ PlantUML始めました

最近いろいろ新しいものを試せているのは Emacs の環境が新しくなってパッケージ管理と設定に悩まなくなったからだなぁ。というわけで前々から VS Code では書けたけど Emacs で書けるようになったのでおさらい。

基本

シンプルなテキストファイルで UML が書ける、オープンソースのツール

PlantUML は UML をテキストで書くための文法であり処理系の名前でもある。UML については割愛。

ねらい

• 画像エディタと画像ファイルと共同管理の組み合わせで発生する種々様々な課題を避けたい

必要なもの

PlantUML の処理系は以下に依存している

• Java
  • https://www.java.com/ja/
  • AdoptOpenJDK - Open source, prebuilt OpenJDK binaries
• Graphviz
  • Graphviz - Graph Visualization Software

Java の話はまた後日。

VS Codeで

以下の extension を入れる。

PlantUML - Visual Studio Marketplace

動作確認しているのは 2.12.2

以前は plantuml.com のサーバにデータを投げる仕様だったのかな？ 最新版では plantuml.server の設定はデフォルトではなくなったよ、と書かれている。

• 文法のパーサを持っている
• plantuml.jar が同梱されている

ので、あとは Java と Graphviz だけ。PATH の通っている場所に java or jar コマンドと dot コマンドがあればたぶん何も設定しなくても動く。

Preview ペインを持っていて、一度これを開いておくとファイルの保存を待たずに適当なタイミングで rerender が走るのでカジュアルに始めるのにオススメ。ただ、どうも内部で一回一回コマンドを叩いてゼロから JVM が起動しているようで、preview と言う割にそこそこ重くて逆に気になるかもしれない。

Emacsで

plantuml-mode - MELPA

これも構成としては VS Code の場合と一緒。ただし、plantuml-mode は plantuml.jar を同梱していないのでその設定から行う必要がある。

plantuml-mode は 20191019.1309 の時点でデフォルトで plantuml.com のサーバに繋ぎにいくので注意が必要。

また、一度その動作をしないと M-x customize で設定項目が出てこない。この現象は以下のバージョンで確認済み。

• Emacs 26.2
• 20191019.1309

一度、何も内容のない UML で preview を叩いてみると plantuml.com に繋ぎに行くので、そこでキャンセルして

M-x customize

と叩くと設定できるようになっている。ここで

Plantuml Default Exec Mode

を

jar

にしておくとサーバに繋ぎに行かなくなる。あとは Java の設定やら Jar の設定やら必要かもしれないので頑張る。

plantuml を brew などなんらかのパッケージ管理ツールで入れている場合はその辺の設定の参考になると思う。

コマンドで

Homebrew を利用している場合は brew install plantuml すると plantuml コマンドというか sh script ができるのでこれを利用する。

この中身を見ると

• 同じく brew で入れた dot
• brew で入れた plantuml.jar

のパスが直書きされているのが分かる。

Emacs の plantuml-mode の設定の際にこれが必要になるかも。逆に plantuml-mode の設定を見ていると plantuml -help では分からない設定があって、それが

-headless

オプション。これがないと一瞬 Dock に Duke が現れて今使いたいアプリからフォーカスを奪って逃げていく。すごく腹がたつので絶対に設定しておきたい。

出力形式とビュワー

• デフォルトは PNG を生成するので適当な画像ビュワーで開ける
• 書き込みが細かくなってくるとベクター画像が欲しくなってくるが、そうなるといろいろ挙動があやしい。とりあえずでやってみたら PDF は生成できなかった。EPS と SVG はイケた。
  • ベクター画像が欲しければ SVG を生成してブラウザで開く、くらいがお手軽かも

本当は dot ファイルそのものが出力できるといいんじゃないかと思ったんだけど、どうやら PlantUML にそういう出力オプションを作るのは難しいらしい。（request はちょくちょく上がっている模様。）

SVG はブラウザが対応してるので各種 Web サービスに上がっていてもそのまま表示できるわけで、まぁまぁよさげ。ちょっと確認したところ OmniGraffle も draw.io も対応してるし、なんかいろいろ大丈夫じゃないかな。