Unit Test好きにはたまらない!Conftestで設定ファイルのテストをしてみた
KubeConでOpen Policy Agent関連の発表を追っていたところ、面白そうなプレゼンを発見しました!
Unit Testing Your Kubernetes Configuration with Open Policy Agent
僕はUnit Test大好き人間なのでUnit Testと聞くだけで興奮するのですが、それにさらにOpen Policy Agentが関わっているときたら放っておけません!
もしOpen Policy Agentについて初めて聞いたという方は以下の記事でも紹介しているので興味があればぜひ!
Conftest
ConftestはYAMLあるいはJSONで定義された設定ファイルに対してテストを書けるというツールです。
面白いのは、テストに使うのがOpen Policy AgentのRegoというポリシー用の言語だという点です。上に紹介した記事にも書いていますが、さらに気になる人は公式サイトでもRegoについて詳しく書かれているのでぜひ読んでみてください。
インストール
Macにインストール。僕はbrewを使いましたが、様々な方法でインストールできますので、READMEをチェックしましょう!
brew tap instrumenta/instrumenta brew install conftest
インストールはこれで完了です!
テストを書く
ではテストを書いてみましょう!KubernetesのYAMLがテストできるってところがハイライトされがちですけどYAML, JSONならなんでもOKです!
ということでせっかくなのでチュートリアルには無いCircleCIのYAMLを対象にしました!
テストを書くにあたって重要なのはRegoという言語を使うということです。
Regoはポリシーに特化した言語で、ちょっとトリッキーなところもありますが、宣言的で読みやすい言語だと思います。
例えばCircleCIの以下のようなconfigがあったとします。
version: 2.0 jobs: build: docker: - image: circleci/buildpack-deps steps: - checkout test: docker: - image: kenfdev/golang:1.12 steps: - checkout workflows: version: 2 build_and_test: jobs: - build - test
これを.circleci/config.yml
に置きます。
conftest
を導入すると何ができるかというと、このYAMLの記述内容に対してポリシーを書くことができます。
具体的にはこんなポリシーを割り当てることができます
version: 2.1
以上しか使っちゃいけない- CircleCI純正のイメージしか使っちゃいけない
- コンテナのイメージに
latest
を使っちゃいけない
などなどです。
実際にこのポリシーを適用したテストを順番に書いてみます。
conftest
はデフォルトでpolicy
ディレクトリ配下の.rego
ファイルを見てくれる様なので、circleci.rego
というファイルを作ります。
touch policy/circleci.rego
この中にルールを書いていきます。
package
を指定
Regoのpackage
はデフォルトでmain
が使われます。これは--namespace
オプションで変更可能とのこと。
なので、package
はmain
にしましょう。
package main
version: 2.1
以上しか使っちゃいけない
「CircleCIのOrbs機能を使いたいから、Versionを必ず2.1以上にしたい」というポリシーがあるかもしれません。その場合に書けるポリシーは以下のとおり。
deny[msg] { input.version < 2.1 msg = "Use version 2.1 or higher" }
deny
になる条件を探すので、「どうなっているとルール違反か?」というマインドが必要です。input
というのはRegoで特別な変数で、conftest
の場合ここにテスト対象のYAMLあるいはJSONが入っています。なのでinput.version
でversion
にアクセスできます。
conftest
を実行してみます!
$ conftest test config.yml config.yml Use version 2.1 or higher
2.0
をconfig.yml
に指定しているので怒られてますね!
CircleCI純正のイメージしか使っちゃいけない
こんなユースケースがあるかどうかはさておき、使うコンテナのimage
にポリシーを設けたい場合の例になります。
必ずimage
がcircleci/
から始まっているかどうかをチェックしてみます!
deny[msg] { docker_images := input.jobs[_].docker[_].image not startswith(docker_images, "circleci/") msg = "Only use official CircleCI images" }
Regoのちょっとトリッキーな書き方をさっそく取り入れてみました。
docker_images := input.jobs[_].docker[_].image
これを言語化すると「jobs
の中に含まれる複数のキー(build
, test
)の中にあるdocker
という配列の中のimage
キーの値」になります。
こうやって書くことでOPAがよしなに順番に拾ってくれます。そして、それらがcircleci/
で始まってなかったらアウトにします。
not startswith(docker_images, "circleci/")
ここで使っているstartswith
はRegoに予め組み込まれているビルトイン関数です。OPAのドキュメントにも載っているので、どういうものがあるかチェックしておくといざとなったら使えて便利です!
「circleci/
で始まっていないもの」を探すので、先頭にnot
をつけている点もお忘れなく!
実行してみます!
$ conftest test config.yml config.yml Only use official CircleCI images Use version 2.1 or higher
kenfdev/golang:1.12
を使っているので怒られていますね!
コンテナのイメージにlatest
を使っちゃいけない
またまたimage
に関連するポリシーです。安定したCIを回すためにimage
に必ずタグを指定するというポリシーが必要になるかもしれません。latest
を使っていたらルール違反にしましょう。
deny[msg] { docker_images := input.jobs[_].docker[_].image tag_is_latest(split(docker_images, ":")) msg = "Do not use `latest` container image tags" } # helpers tag_is_latest(images) { count(images) < 2 } tag_is_latest([_, tag]) { tag == "latest" }
docker_images
はさっきと同じですが、2行目がまたちょっとトリッキーです。latest
を検知する方法は以下の2つの観点にしています。
:
で分割した場合に要素が2個より小さい:
で分割して末端側(tag側)の値がlatest
になっている
いずれかにヒットしたらルール違反にします!ここでポイントなのは、「いずれか」ということ。つまりOR条件になります。Regoのルール内の行は全てANDになり、同じルール名のルール(この場合tag_is_latest
)を並べるとORになるという特性があります。これはIncremental Definitionsと言って公式ドキュメントでも説明があるので要チェックです。
また、僕が以前書いた記事にもANDとOR、そしてルール内から別のルールを呼び出すことについて触れていますので興味があればぜひ参考にしてみてください!
上のやり方ではtag_is_latest
というルールを別途2つ作って、それぞれの判定条件を書きました。
:
で分割した場合に要素が2個より小さい
tag_is_latest(images) { count(images) < 2 }
images
にはsplit(docker_images, ":")
で分割された値が入ってきます。今回の例であれば下のようになります。
["circleci/buildpack-deps"] # 要素数は1つ ["kenfdev/golang", "1.12"] # 要素数は2つ
タグが無い場合のデフォルトがlatest
になるので、分割された要素の数が2より小さいかどうかをチェックします。
:
で分割して末端側(tag側)の値がlatest
になっている
tag_is_latest([_, tag]) { tag == "latest" }
また新たな記法が引数の場所([_, tag]
)に登場しました。これは、いい感じに配列の値を分割代入させる書き方です。
例えば下のように書くとイメージしやすいと思います。
[name, tag] = ["circleci/buildpack-deps", "latest"]
name
にはcircleci/buildpack-deps
が対応し、tag
にはlatest
が対応して代入されるようなイメージです。でも、name
には今回は特に興味がないので、上の例では[_, tag]
と書いています。そして、ルール内ではtag == "latest"
というように評価することで、tag
がlatest
かどうかチェックすることができます。
それでは、テストを実行してみましょう!
$ conftest test config.yml config.yml Only use official CircleCI images Do not use `latest` container image tags Use version 2.1 or higher
image: circleci/buildpack-deps
がタグを指定していないので、ちゃんと怒られていますね!ちなみにimage: circleci/buildpack-deps:latest
としてもちゃんと怒られます。
conftest
でテストができました!念の為ポリシーの全体像も載せておきます。
# .circleci/policy/circleci.rego package main deny[msg] { input.version < 2.1 msg = "Use version 2.1 or higher" } deny[msg] { docker_images := input.jobs[_].docker[_].image not startswith(docker_images, "circleci/") msg = "Only use official CircleCI images" } deny[msg] { docker_images := input.jobs[_].docker[_].image tag_is_latest(split(docker_images, ":")) msg = "Do not use `latest` container image tags" } # helpers tag_is_latest(images) { count(images) < 2 } tag_is_latest([_, tag]) { tag == "latest" }
config.ymlの修正
怒られっぱなしなのもちょっと悲しいので、config.yml
を直しましょう!
全てのポリシーを満たすために下のように修正しました。
version: 2.1 # 2.1に変更 jobs: build: docker: - image: circleci/buildpack-deps:jessie # latest使うのやめた steps: - checkout test: docker: - image: circleci/golang:1.12 # circleciのイメージに変更した steps: - checkout workflows: version: 2 build_and_test: jobs: - build - test
それではテスト実行です!
$ conftest test config.yml
config.yml
ちょっとわかりづらいんですけど、何も怒られなくなりましたね!
いい感じにconftest
で設定ファイルに対してテストが書けることがわかりました。Regoへの慣れは必要ですが、今後Open Policy Agentも様々な場所で使われていくことになりそうなので、Regoは学んでおいて損は無いんじゃないかなと思っています。
今回のコードは以下のリポジトリに置いてます。
まとめ
- YAML, JSONの設定ファイルに対してテストが書ける
conftest
を試した conftest
は宣言的にOpen Policy AgentのRegoを使ってテストを書ける- どこがルール違反になっているか、場所も教えてくれるとさらにうれしい
- 全部ポリシーをパスしてたらもうちょっとうれしい出力がほしい(笑)
- 今後に期待したい!!!
参考
Conftestを使ったテストの例 github.com
Open Policy Agentのチュートリアル www.openpolicyagent.org
セルフマネジメントについて考える / 『管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう』を読んで②
「管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう」という本を読み終えました!
管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう
- 作者: 倉貫義人
- 出版社/メーカー: 技術評論社
- 発売日: 2019/01/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
この本の中でも特に「生産的に働く」ことについては以下の記事で書評を書いたので、興味がある方はぜひ!
この記事では、第2部で紹介されている「セルフマネジメントのレベル」と「師匠が背中を見せる」ことについて注目した書評を書きます。
目次
- はじめに
- 第1部 生産的に働く ~楽に成果をあげるために“見直す”
- やり方を見直す ~「ふりかえり」で抜本的に生産性を改善する
- 生産性を見直す ~「時間対効果」の高い仕事をする
- タスクを見直す ~「タスクばらし」で小口化する
- やる気を見直す ~無理に上げない、なくさない状況をつくる
- 信頼関係を見直す ~「心理的安全性」を生み出す環境
- 会議を見直す ~口を動かすだけでなく、いっしょに手を動かす
- 雑談を見直す ~ホウレンソウから「ザッソウ」へ
- 社内業務を見直す ~人手に頼らない「業務ハック」で改善を続ける
- 価値を見直す ~受託脳よりも提案脳で考える
- 第2部 自律的に働く ~人を支配しているものを“なくす”
- 管理をなくす ~セルフマネジメントで働くチームをつくる
- 階層をなくす ~「ホラクラシー」組織を実現する仕組み
- 評価をなくす ~個人の成長と会社の貢献の「すりあわせ」をする
- 数字をなくす ~組織のビジョンよりも自分のためならがんばれる
- 組織の壁をなくす ~信頼しあえる企業文化の育て方
- 急募をなくす ~仕事があっても、いい人がいなければ採用しない
- 教育をなくす ~自分の頭で考える社員の育て方
- 制度をなくす ~本質ありきで考える「そもそも思考」
- 通勤をなくす ~働く場所に縛られない「リモートチーム」
- 第3部 独創的に働く ~常識や慣習に従うことを“やめる”
- おわりに
セルフマネジメントの3つのレベル
本書では「管理をなくす」にあたって、セルフマネジメントについて紹介されています。「仕事」、「組織」、「自分」という3つの観点で、それぞれレベルを3つに分けて定義しています。
観点 | Lv1 | Lv2 | Lv3 |
---|---|---|---|
仕事 | タスクを管理する | リソースを管理する | 価値を生み出す |
組織 | 周囲に伝える | 周囲と協調する | 周囲を活かす |
自分 | 休憩をとる | 安定して働く | 将来を考える |
何ができていると、どこのレベルにいるかというのが述べられています。「自分はそれぞれの観点でどこのレベルにいるのか?」というのを確認できて面白いですし、何ができればレベルが上がるのかというのも参考にすることができます。
「休憩をとる」ということ
セルフマネジメントのレベルの中でも注目したいのは「自分」の観点の中のLv1に入っている「休憩をとる」ことです。
休憩が習慣化していない人にとっては「いつ休憩をとるのか?」というのが難しいと感じそうですが、僕はポモドーロ・テクニックがここにフィットすると感じました。
何度か僕のブログで紹介していますが、ポモドーロ・テクニックについては僕のブログメンターでもあるカックさん( @kakakakakku )の以下の記事がおすすめです!
ポモドーロ・テクニックを使って「25分間は超絶に集中し、その後は5分間休憩をとる」というサイクルを繰り返していくと休憩も1つのタスクのように感じられるようになり、自然と習慣化もしていきます。
だれかが管理しないと休めないようでは、マネジメントする側の負担は大きいままです。
と、本書でも述べられています。休憩を自らとれるかとれないかは、自分だけの問題ではないということに気づく必要があります。休憩の習慣化は小さく見えてセルフマネジメントにおいては大きな一歩だと感じました。
師匠が背中を見せる
本書には「教育をなくす」という章があり、「教育する」のではなく「仕事の中で育てる」方法について紹介しています。
これには以下3つのポイントが述べられています。
- やってみせる
- やらせてみる
- フィードバックする
本書では育てる側を「師匠」、育てられる側を「弟子」と呼んでいて、1点目の「やってみせる」というのは「師匠が弟子に背中を見せる」ということです。ポイントとなるのは、いかにして師匠は弟子に自分の技術を盗ませるかです。そのためにまずは「やってみせる」ことが大事だと述べられています。個人的にふりかえってみても、物理的に離れていた新人に仕事をやってみてもらったときよりも、隣に座って一緒に仕事をしていた新人の方が圧倒的に成長のスピードが早かったのが記憶に残っています。これは、自然と自分の仕事を「やってみせる」ことができていたのではないかと思います。
気になった点としては、最初から物理的に離れている者同士(リモート)の場合、「やってみせる」にはどうしたら良いかということです。フルリモートをしている身としては今後の課題として追求していきたいです。
まとめ
- 『管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう』を読んだ
- セルフマネジメントに悩んでいるor興味がある人にオススメできる
- セルフマネジメントできる人を増やしたい人にもオススメできる
- フルリモートにおける師弟関係について追求していきたい
管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう
- 作者: 倉貫義人
- 出版社/メーカー: 技術評論社
- 発売日: 2019/01/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
生産的に働くことについて考える / 『管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう』を読んで①
ふとFacebookのタイムラインから流れてきた「管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう」という本。今まで技術書ばかり読んできていて組織や人に関する本には手をつけていなかったのですが、最近は積極的に読むようにしています。この本を読みながら改めて気付かされる点が非常に多かったため、自分のためにも書評を書きます!
管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう
- 作者: 倉貫義人
- 出版社/メーカー: 技術評論社
- 発売日: 2019/01/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
目次
以下が目次となっていて、この記事では太文字の「第1部 生産的に働く ~楽に成果をあげるために“見直す”」に注目します。
- はじめに
- 第1部 生産的に働く ~楽に成果をあげるために“見直す”
- やり方を見直す ~「ふりかえり」で抜本的に生産性を改善する
- 生産性を見直す ~「時間対効果」の高い仕事をする
- タスクを見直す ~「タスクばらし」で小口化する
- やる気を見直す ~無理に上げない、なくさない状況をつくる
- 信頼関係を見直す ~「心理的安全性」を生み出す環境
- 会議を見直す ~口を動かすだけでなく、いっしょに手を動かす
- 雑談を見直す ~ホウレンソウから「ザッソウ」へ
- 社内業務を見直す ~人手に頼らない「業務ハック」で改善を続ける
- 価値を見直す ~受託脳よりも提案脳で考える
- 第2部 自律的に働く ~人を支配しているものを“なくす”
- 管理をなくす ~セルフマネジメントで働くチームをつくる
- 階層をなくす ~「ホラクラシー」組織を実現する仕組み
- 評価をなくす ~個人の成長と会社の貢献の「すりあわせ」をする
- 数字をなくす ~組織のビジョンよりも自分のためならがんばれる
- 組織の壁をなくす ~信頼しあえる企業文化の育て方
- 急募をなくす ~仕事があっても、いい人がいなければ採用しない
- 教育をなくす ~自分の頭で考える社員の育て方
- 制度をなくす ~本質ありきで考える「そもそも思考」
- 通勤をなくす ~働く場所に縛られない「リモートチーム」
- 第3部 独創的に働く ~常識や慣習に従うことを“やめる”
- おわりに
「精神論」でふりかえりをしてはいけない
「やり方を見直す」方法として「ふりかえり」の大切さが述べられています。
ふりかえりの4つのポイント
- KPT(Keep・Problem・Try)でふりかえりをする
- とにかく全員で出し切ることを優先する
- 精神論ではなく、具体的なアクションに落とし込む
- 週に一度、1時間のふりかえりから始める
特に3番目は多くの人が陥る問題だと思います。何か問題(Problem)があって、それを改善するための試み(Try)を考えた場合、どうしても「次はこうならないように気をつける」と精神論を言ってしまいがちです。
そういった精神論ではなく、以下のように具体的なアクションに落とし込むことが大事だと述べられています。
Problem「2日連続で寝坊してしまった」 ↓ 【NG】Try「早起きするように気をつける」 【OK】Try「目覚まし時計を買う」
僕もついつい「がんばる」や「気をつける」と言ってしまいがちですが、常にこの点は意識していきたいです。
100%の品質と完成度は目指さない
80%の完成度には2割の時間でよくて、残り20%を高めるためには8割の時間がかかる
というパレートの法則の引用を用いて、完璧を目指してはいけないという点が紹介されています。
完璧を目指そうとすると考え込むことが多くなり、ひたすら時間だけが過ぎていくことが多くなります。また、そもそも完璧の定義自体が自分で決めたものなので、完璧かどうかなんてわかりません。
80%であってもリリースをしてみて、「もっとこうしてほしい」点や「これは必要ない」点について早い段階で見つけて改善していくことが大事だと述べられています。
最後にFacebook創業者のマーク・ザッカーバーグの引用も紹介されています。
Done is better than perfect.
この考え方は最近読んだ「エンジニアの心を整える技術」でも紹介されていて、非常に大事だと感じています。
作業じゃなくて仕事をまかせる
本書では「仕事」と「作業」は違うものだと述べられています。
- 作業
- 事前に定められた手続きに従っておこなう活動
- 手を動かすことに価値がある
- わかりやすい結果や指標がある
- 進め方に創意工夫の余地がない
- 仕事
- だれかに価値を届けるための活動
- 「価値とは何か」をそもそも考えなければいけない
- わかりやすい結果や指標がない
- 進め方に創意工夫の余地がある
作業の進め方に「創意工夫の余地がない」かどうかは議論の余地がありそうですが、僕自身も作業を依頼していることが今まで多かったかなと感じます。
作業には事前に定められた手続きが必要になるので、依頼する側の負担が大きいです。さらに、「依頼」をされると、された側は自分の仕事として考えるのが難しいと本書では述べられています。
仕事には「わかりやすい結果や指標がない」かわりに「進め方に創意工夫の余地がある」ことで、仕事をする側は 主体性をもって取り組む ことができます。
主体性をもつ→自律的に成長する→モチベーションが上がる→生産性も上がる
というような好循環が生まれる。上の表現だけでは単純に見えますが実際には「仕事の全体像や目的の伝え方」、「コミュニケーションの方法」、「フィードバック」について気をつけるべき点があり、本書では別途詳しく紹介されています。
社会人になって2、3年もすれば後輩ができたり、チームメンバーの入れ替えなどがあってコラボレーションを主体的に行っていく必要性が増していきます。そのときには作業ではなく、仕事をまかせることが大事なんだと改めて考えさせられました。
「ホウ・レン・ソウ」から「ザッ・ソウ」
本書ではホウ(報告)・レン(連絡)・ソウ(相談)の大切さについて述べられつつも、より大事なのはザッ(雑談)・ソウ(相談)だと述べられています。「雑談が大事」なのは既に知っている人も多いと思いますが、問題はどうやったら雑談を増やせるか?という点です。雑談は「よし、雑談をしよう!」と言ってなかなかできるものでは無いですし、信頼関係など前提条件が揃っている必要があります。
そこで本書では「雑談をうまくするポイント」が3つ紹介されています。
- 雑談と仕事の場所をツールで分けない
- 社内で起きている雑談の様子を見える化する
- 定期的に雑談する機会をつくる
雑談と仕事の場所をツールで分けない
この点についてはハッとさせられました。確かに、例えばSlackのチャンネルに「#雑談」というチャンネルがあったとしたら、そのチャンネルに投稿するということは「よし、今から雑談するぞ!」という気持ちが先に発生する人が多いと思います。もちろん人によってこれは変わるのでしょうけど、雑談をする前に「雑談 or NOT 雑談?」というオーバーヘッドが生まれるのがあまり良くないというのには納得させれました。流れるように自然に雑談ができる環境がベストですよね。
社内で起きている雑談の様子を見える化する
この点については前提として社内全体の高い信頼関係が必要だとは感じます。それが無い状態ではどうしても前節にも述べられているように、発言の前に「こんな内容(雑談)を投稿していいだろうか?」というマインドが発生してしまうからです。
また、もう一つ注意する点については、(これは雑談に限った話ではないですが)公開される情報が多くなるということはSlackのようなツールの場合にそれだけ「通知」も多くなります。これによって気になることが多くなり、生産性が落ちてしまう可能性も含まれていると思います。
そこで僕が追加で紹介したいのはポモドーロ・テクニックです。
「25分間はとにかく決めたタスクに集中し、5分間休憩を挟む」ということを1セットとして繰り返すテクニックのことです。この25分間の間、通知が来たとしても無視します。無視するというのは、Slackであれば「離席中」にして通知が来ないようにするレベルです。
この記事では詳しくは述べませんが、以下の記事がとてもよくまとまっているのでポモドーロ・テクニックに馴染みの無い人はぜひ読むことをお薦めします!
話が少し逸れましたが、「雑談の見える化」は見ようと思えば誰でも見えるような状態にしておくことが一つのポイントなのかなと僕は解釈しています。これもSlackの例えになりますが、可能な限りチャンネルはすべてPublicにしておくことがその手法の一つかと考えています。「他のチームの様子はどんな感じだろ?」となったときに「チラッ」と覗けたり、チャンネルにJoinできたりする環境が大事だと思います。
この点についてはSlackのJulia Graceさんによる「Building Engineering Teams Under Pressure(英語)」という公演でも述べられていて、合わせて視聴することをお薦めします。
まとめ
「管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう」の「第1部 生産的に働く ~楽に成果をあげるために“見直す”」を読みました!個人的には「ふりかえり」することと「雑談」することが2つの大きなポイントだと感じました。「生産的に働くこと」については常に意識しつつ今後も仕事に取り組んでいきたいと思います!
また、セルフマネジメントについては、以下の記事で書きました!
おまけ
生産的に働くこととDeveloper Happinessも強く関連していると思います。この点については以前書いた下の記事で「Developer HappinessとEmployee Retention」というトピックでも紹介していますので興味があればぜひ読んでみてください!
Algolia Searchの速さに鳥肌が立った話
「Algolia Community Party in 京都 - 2019年5月10日」に参加し、LTしてきました!
発表資料
ストーリー
業務でAlgoliaのスパイクをうつ機会があったので、そのときに経験した 圧倒的な爆速っぷり について完全なる自己満でそのときの気持ちを伝えました!
SPA(Single Page Application)の入門チュートリアルで「検索バーでフィルタリング」する簡単なアプリを作った記憶は無いでしょうか?
下のCodePenのような簡単なフィルタリングアプリです。
ここで検索バーに文字を入力すると、リアルタイムにフィルタリングが適用されます。 とても速いのですが、Amazon、楽天市場、価格.comで使うような「大量のデータから検索」する機能で同じようなUXを実現しようとすると かなり難しい です。
なぜなら、上のフィルタリングアプリは 最初から ブラウザがインメモリに持っている情報に対してフィルタリングしているのに対して、「大量のデータから検索」する場合には外部のAPIにリクエストして、さらにそのAPIが外部のデータベース内のデータを取得しにいったりするからです。これをどうにか高速化するにはインデックスを頑張ったり、キャッシュを頑張ったりと、涙ぐましい努力が必要になります。そしてその努力をしたとしても、上のフィルタリングアプリのようなスピードを実現するのはかなり難しいと思います。
なので、大量のデータから検索するときに、 ちょっと時間がかかる っていうのは「ある程度は仕方ないかな」と妥協することが多いはずです。
ただし! 外部にデータがあったとしても爆速で検索できてしまうのがAlgoliaなんです!
下のデモサイトで体験ができるのでぜひ体感してみてください。
今まで様々な技術スパイクをうってきましたが、隣の同僚にまで「これ、やばいっすよ」って感動を伝えたのはAlgoliaが初めてです。
13万件のサンプルデータを入れてみて、多少パフォーマンスが変わるかと思いきや検索には 3ms しかかかりませんでした!(ただし、ネットワークの時間を含めると20~40ms)
イベントレポート
下のイベントレポートが両者とも非常にわかりやすくまとまっています!
Algoliaの @shinodogg さんのイベントレポート
@silver_birder さん のイベントレポート
silverbirder180.hatenablog.com
まとめ
まだAlgoliaのさわりの部分しか使えていないので
- Query Rules(「cheap camera」って検索したら「cheap」が「< 10,000」に変換できて、10,000円以内のカメラに絞れたりする)
- Personalization(検索で行った行動などから、ユーザー毎にサジェストをパーソナライズできたりする)
- Internationalization(多言語に対する検索インデックスの管理方法)
- Multi-tenancy(マルチテナントなデータの管理方法)
あたりのトピックを今後は深掘りしていきたいです!
幸運な巡り合わせのおかげで突如3日前に参加&LTが決まったイベントでしたが、Algoliaの中のEiji Shinohara( @shinodogg )さんやフランスからかけつけて下さったMichaël Sokol( @_ms123 )さんともお話できて本当によかったです!
「誰」が「何」をできるかをOPAのレスポンスで返す
OPA(Open Policy Agent)で「○○をやっていいですか?」に対して「Allow/Deny」の返答がくるパターンについていくつか記事にしました。
今回は、 「誰」が「何」をしていいか
をOPAからのレスポンスで知る方法について検証したので共有します。
どういった場面でこれを知りたくなるかと言うと、
例えばSPA(Single Page Application)で、 ログイン中のユーザー
が「何」をして良いか知りたいときが考えられます。
この情報があることによって、
- 新規作成ボタンを表示する
- 編集ボタンを表示する
- 削除ボタンを表示する
- 特定のメニューを表示する
などの判断をSPA側で行うことができるようになります。
今回の記事で作成するPolicyもOPAのSlackでやりとりがされていた内容をちょっとカスタマイズさせてもらったものになります。
ドキュメントには登場しないようなユースケースがコアメンバーによってPlaygroundでシェアされていたりするので、OPAに興味がある方はぜひSlackに参加することをおすすめします!
権限の定義
今回の例では以下のような状況があると仮定します。
article
というリソースがあるalice
はarticle
をread
できるしwrite
もできる権限があるbob
はarticle
をread
する権限しかもっていない
これをOPAのRegoで表現すると次のようになります。
package foo.bar permission["alice"] = [ { "resources": ["article"], "actions": ["read", "write"] } ] permission["bob"] = [ { "resources": ["article"], "actions": ["read"]} ]
実際はこの permission
をハードコードすることは無く、データベースなりどこかに保持されているところからOPAに読みこませることになりますが、Playground上で表現するために直でデータを書いておきます。
指定したユーザーの権限を取得
では、データが用意されたのでここから aliceの権限を取得
したいとなったらどうすれば良いか。
欲しいのは以下の情報です。
[ { "resources": ["article"], "actions": ["read", "write"] } ]
OPAでは「Allow/Deny」な答えを返すことが多いのですが、オブジェクトを返すこともできます。 これがドキュメントにも書かれている「Generating Objects」をする方法です。
OPAへのリクエストの input
を { "user": "alice" }
とした場合に、 alice
の権限が返ってくるようにするには次のようなルールを定義します。
user_permission = perm { perm := permission[input.user] }
ここでポイントとなる点は user_permission = perm
の、 = perm
の部分です。
普通のルールの場合は key
だけ指定して value
側を指定することはありません。
value
側を指定(ここで言う perm
)し、その値をルールの中身で用意することでレスポンスとして返すことができます。
実際に試してみましょう!下図はPlayground実行している様子です。
PlaygroundにはちょっとしたTipsがあって、図のように、選択した部分のルールのみを実行してOutputを確認することができます。
下記リンクからPlaygroundが実行できるので、ぜひ試してみてください!
Inputを
{ "user": "alice" }
としたことで、 user_permission
のみを実行した結果が
[ { "actions": [ "read", "write" ], "resources": [ "article" ] } ]
となり、 alice
の権限がレスポンスとしてオブジェクトで返ってきているのがわかります。
また、 bob
であれば以下のように、 article
に対して read
しか許可されていないのがわかります。
[ { "actions": [ "read" ], "resources": [ "article" ] } ]
このように、「Allow/Deny」のレスポンス以外にも、オブジェクトでレスポンスを返すことができるということもわかりました!
そして、例えばこのレスポンスを使ってUI側では
write
があるから新規作成、編集、削除ボタンを表示する
という処理が書けて、ログインしているユーザーの権限に応じて画面の見た目を変えることができます。
やっていいかどうかの判断
「誰」が「何」をしていいか
を確認する方法についてはこれでOKですが、実際に「やっていいかどうか」の判断も必要になります。
具体的には以下の質問への答えが必要になります。
alice
はarticle
にwrite
できますか?bob
はarticle
にwrite
できますか?
この質問をするときのInputはきっとこんなJSONになると思います。
{ "user": "alice", "action": "write", "resource": "article" }
そしてこの質問に対して、「Allow/Deny」の答えを出すためのRuleはRegoで以下のように表現することができます。
default allow = false allow { permission[input.user][i].resources[_] == input.resource permission[input.user][i].actions[_] == input.action }
permission["alice"]
の中のデータを順番にチェック- i番目の情報の
resources
にarticle
が含まれるかチェック - i番目の情報の
actions
にwrite
が含まれるかチェック
結果として、 alice
は { "resources": ["article"], "actions": ["read", "write"] }
という permission
を持っているので、すべて true
となるので、結果も true
です!
逆に bob
の情報を下のように渡してみるとどうなるでしょう?
{ "user": "bob", "action": "write", "resource": "article" }
bob
には { "resources": ["article"], "actions": ["read"]}
という permission
しか定義されていないので、 write
できるかという質問に対しては false
になります。
よって、このリクエストの結果は false
になります。
まとめ
- OPAは「Allow/Deny」以外にもオブジェクトをレスポンスとして返すことができる
- 「誰」が「何」をできるか、を返すことでUIでその情報を使うことができる(ボタンの表示・非表示など)
『JSJ 358: Pickle.js, Tooling, and Developer Happiness with Anatoliy Zaslavskiy』を聴いて
僕のお気に入りのPodcastの一つにJavaScript Jabberというものがあります。
「JavaScript」とPodcastのタイトルには書いてありますが、ゴリッとJavaScriptのテクニカルな話をするわけではないです(昔はそうだったかも)。 どちらかと言うとJavaScript界隈に何かしら関わりのある人物をゲストに呼んで、その人と一つのテーマについて1時間ほどトークをするという流れです。 ホストは Charles Max Wood氏 です。Ruby Rogues, Adventures in Angularなど様々なPodcastを配信している方です。
なんとなーくジョギングなりしながら聴いているのですが、先日聴いたエピソードが結構面白かったので紹介したいと思います。英語ですが、トピックに興味がある方はぜひ聴いてください!
Pickle.js, Tooling, and Developer Happiness
今回のゲストはAnatoliy Zaslavskiy氏というHover Inc.所属のSenior JavaScript R&D Developerでした。
当初のテーマはきっとAnatoliy氏が作ったPickle.jsと自動テストに関する話だったと思うのですが、途中からDeveloper Happinessに話が逸れ(?)ます。
このDeveloper Happinessに関する議論が特に興味深かったです。
目次
- [00:00] イントロ(Pickle.jsの紹介)
- [11:38] テスト文化にまつわるよくある問題
- [17:30] 自動テストの意義
- [28:24] Employee Retention(従業員をどう定着させるか)
- [38:24] なぜSeniorよりJunior Developerを雇うほうがスケールするのか
- [47:10] ツールやライブラリを作っていく上で注意すること
- [54:15] Picks
時間は、Podcast内でトピックが話されているだいたいの時間を示してます。Picksとは、毎回Podcastの最後に参加者が全員何かしら記事だったり技術ネタだったり、視聴者にシェアしたい内容を紹介するコーナーです。
Pickle.js
ゲストのAnatoliy氏が作っているPickle.jsというのはe2eテストフレームワークです。
僕もまだ触れていないので、このPodcastと公式サイトから得た情報をまとめると
- Cucumber っぽく(Gherkin Syntaxで)ノンプログラマーでもテストを書ける
- 既存のテストフレームワーク(執筆時点ではCypressだけ)を拡張して実装しているので、理論上はテストフレームワークを変えてもテストが動く
- ページ内の要素を選択するためのセレクターは一箇所にKey Valueで定義し、そのKeyをテストの文章内で使用できる
ポイントは以下のスライドでも簡潔に紹介されています。
僕の中ではpython製の Robot Framework に似てるのかなという印象があります。
自動テストがなぜ必要か?
なぜ自動テストが必要なのかというトピックについて、「自動テストの無い大企業でのプロジェクトの問題」が例に出されています。
- プロジェクトに多数のエンジニア(数100)が関わっている
- ある機能を開発者が実装する
- QAがその機能をテストして、1週間後にバグなどフィードバックする
- 開発者はバグを修正してQAに再び渡す
- また1週間後に、今度はさらに発生したバグなどフィードバックする
ここでの大きな問題としては開発者が、自分の実装した範囲が他にどのような影響を及ぼすのかということを知る術が無い(コード全体を熟知しない限り)。
そして、何かを壊してしまった場合に即座にフィードバックを得ることができないという点です。
流れが悪いために時間はどんどん過ぎていき、エンジニアとしてはほとんどバグを直していることしかしていないという負のスパイラルに陥ります。
自動テストを導入することで、フィードバックのスピードが劇的に早くなるため、上の問題の改善に大きく貢献するというトークをしています。
自分が行った変更が 既存の機能を壊していない ということが 一定のレベル保証される ことで、開発者も変更を加えるときに心理的安全性を保つことができるようになります。
トーク内でも「Eliminate the fear of change(変更することへの恐怖を排除する)」することで「Innovative(革新的)」になれると言っています。
この意見には僕もとても賛同しているのですが、「一定のレベル保証される」というところが、「良いテスト」を書いていることが前提になっていることを忘れちゃいけないのかなとは思います。
「良いテスト」の定義がまた難しいのと、トーク内にも特に触れられていない部分なのですが、以下の書籍の内容が僕は好きです。
The Way of the Web Tester: A Beginner's Guide to Automating Tests
- 作者: Jonathan Rasmusson
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2016/10/02
- メディア: ペーパーバック
- この商品を含むブログを見る
日本語版はこちら
- 意味のあるテストになっているか
- 壊れやすいテストを書いていないか
- 本当に意図したテストを行っているか(テスト自体がバグってないか)
などいろいろな観点がありますが、「ただテストをたくさん書けばいい」というわけではないという点がポイントです。
Developer HappinessとEmployee Retention
後半はDeveloper HappinessとEmployee Retentionに関する話題になります。ここが結構ヒートアップして前半の内容が薄れちゃいます(笑)
なぜエンジニアは会社を辞めるのか?
エンジニアが会社を辞める理由としてCharles氏は2つの観点を述べています。
- 人(People)
- プロジェクトそのもの(Project)
自分と「合わない」人と毎日仕事を続けるのはしんどいですし、そもそもプロジェクトが解決しようとしている問題に興味が無ければモチベーションも上がりません。 これには僕も同意見です。これに加えて「給料」も結構大きな理由なのではないかと思います。
同じ仕事条件で、より給料の高いオファーがあったとしたら会社を変えるのは結構自然だと思います。
ただし、「仕事条件」は僕の中では「仕事場の環境(人)」も含まれていると思うので、 単純な比較にはならない とも思います。
Anatoliy氏は「辞める」のは「Unhappy」だからであり、「Unhappiness」は「Cognitive dissonance(認知的不協和)」から来ると述べています。
- 自分がやるべきこと
- 自分が実際にやっていること
のギャップに苦しんでいるが、その「現状の状態」に慣れ過ぎちゃっているがために、どうしたら改善できるか 想像ができない状況に陥ってしまう と。
この状況に陥ったときにどうすべきかの意見がCharles氏とAnatoliy氏で異なった点が面白いです。
IT業界は今のところ人手不足なので、転職してしまうのが一番シンプルだとCharles氏は述べています。
それに対してAnatoliy氏は恋愛を例に出します。
「好きだと思った女性と付き合うが、付き合ってみたらなんか違ったので別れてまた違う女性と付き合う。」
ということを繰り返して良いのかどうかという点に注目します。
「問題は付き合っている女性側にあるのではなく、自分にあるのではないか。」
という視点の切り替えが必要なのではないかと問います。
この視点の切り替えとは「課題の分離」を行うということなのかなと僕は感じました。
- 自分の課題
- 他者の課題
を整理することで、自分の課題に気づいたり、他者の課題に踏み込んでしまっていることに気づいたりできると思います。
「課題の分離」について以下2つの書籍を最近読んで僕も「なるほどー」とうなづく点が多かったので合わせて載せておきます!
- 作者: 岸見一郎,古賀史健
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2013/12/13
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (113件) を見る
「課題の分離」を行うことで、「現状」を改善する道筋が見えてくるかもしれないというのは確かにその通りだなと感じました。
ただし、それでも尚道筋が見えない環境、抜け出した方が良い環境(Toxic Environment)もあるというのは双方で一致している意見でしたし、僕もそう思います。
補足:僕は付き合う相手を変えることについて否定的ではないです。自分に本当に合う人をそうやって見つけられるとも思います!
エンジニアのRetentionを上げる
エンジニアのRetentionを上げるポイントとして述べられているのは「エンジニアは多種多様であると理解すること」と言っています。
- いろんな感情を持っている
- 興味の対象は人それぞれ
- ワークスタイルも人それぞれ
人それぞれで異なるものをうまく組み合わせて活用(utilize)できるようにする、と述べていますがこれはとても難しいと思います。
人・組織・リーダーシップに関わってくる話だと僕は捉えていますが、まだまだ僕はこの点について勉強中で、特に以下の書籍を読んで整理したいと思っています。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー
- 作者: 和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2017/09/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2013/12/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (10件) を見る
また、 僕のブログメンターでもある カックさん の以下記事も参考になる情報満載なので要チェックです!
まとめ
Developer Happinessの議論がとても勉強になりました。「これだ!」という単純な答えが無いのが難しいんですけど、様々な人のこう言った話を聴きながら、自分の生き方も改善していきたいと強く感じました。
後半のトークが濃すぎてPickle.jsの話がだいぶ薄れた印象があります(笑)Pickle.jsのコンセプトは面白いので試してみたいです。
参考
- Testabilityという観点で画面(View)の状態をカタログのように可視化して管理できるStorybookが紹介されました
- Picksで紹介されたDevOpsの本。物語になっていて読みやすくて面白い本です。
- 作者: ジーン・キム,ケビン・ベア,ジョージ・スパッフォード,榊原彰,長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2014/08/12
- メディア: 単行本
- この商品を含むブログ (2件) を見る
OPAでANDとORの条件を組み合わせる
OPAのSlackでやりとりされている内容とかが流れていってしまうのが勿体無いので残していこうと思います。(将来的に索引にできたら良いかなと)
上図のようなパターンを考えてみましょう。文で表現すると以下のとおりです。
p1, p2, p3, additional_pがすべてtrueの場合に許可する。additional_pはp9またはp10がtrueであれば良い。
これをRegoで書くと次のようになります。
package play default allow = false # this rule says "allow is true if p1 and p2 and p3 and additional_p" allow { p1 p2 p3 additional_p } p1 { input.x == 1 } p2 { input.y == 2 } p3 { input.z == 3 } # additional_p is true if p9 or p10 additional_p { p9 } additional_p { p10 } p9 { input.a == "foo" } p10 { input.a == "bar" }
ポイントは以下のとおりかと!
- ルールから別のルールを参照できる
- ルールの中身に書いた式は暗黙的にANDとして扱われる(allowの中のp1, p2, p3, additional_p)
- 同名のルールは暗黙的にORとして扱われる(additional_p)
試してみましょう!
次のJSONをInputに入れてみます。
{ "a": "bar", "x": 1, "y": 2, "z": 3 }
そうするとOutputは次のようになります。
{ "result": { "additional_p": true, "allow": true, "p1": true, "p10": true, "p2": true, "p3": true } }
true
の結果が全部返ってくるのでちょっと見づらいですけど、 allow
が true
なのがわかります。
Inputの "a": "foo"
とした場合でも allow
は true
です!
なぜなら p9 OR p10
であれば( input.a
が foo
または bar
であれば ) additional_p
は true
だからです。
Rego Playgroundは下になりますので実際にInputを変えてみてOutputを確認してみると動きの違いを実際にみることができます!
おわりに
- PolicyのORやANDは暗黙的に行われる
- ルールの中からルールを呼び出すことでルールを整理できる