2022-03-25

転職ドラフトで27社から指名をもらった中で、Viibar に入社した理由

文化

どうも、 id:sawarabi です。昨年の2月ごろから業務委託のエンジニアとして Viibar に JOIN し、11月に正社員として JOIN しました。

11月に転職するにあたり転職ドラフトでなんと27社から指名をもらったのですが、その中でなんで Viibar に入ったの？というところを書いていこうと思います。

3行でまとめると

価値観が合うから（ミッションビジョン、中で働く人のキャラクターなど）
人、組織の成長に投資を惜しまないから
我慢強かったから

詳しく

今回の転職活動は以下のような流れで進みました。

在職中に転職ドラフトに参加する
転職ドラフトで27社から指名をいただく
27社と（在職中の2週間で）カジュアル面談をおこなう
軸と合いそうな8社に絞って面接に進む
並行して業務委託として働いていた Viibar とも話をする
最終的に Viibar 含む3社から内定をいただく

本当はカジュアル面談のタイミングは有休消化に入っているはずだったんですが、最後にこれやってーというのを断りきれずに、終業後や昼休みを利用しての連続カジュアル面談というカオスな感じに。

最終的に幸運なことに3社から内定をいただくことができたのですが、どこもいい企業だったのでどこに入社するか、は本当に迷いました。

コピーロボットがいたら全部に入社できるのにーとか、でも本人は家でゲームかなとか、そんなことを考えたりとか。

まあ現実的に一社に絞り込まないといけないよね、というところで、以下の基準で改めて熟考。

この基準は転職活動初期からある程度考えていたものの、転職活動の中でより言語化されていい感じになったものになります。

環境：ライフワークバランス、年収、テレワークなど
軸：自分が大事にしたい価値観、今回の転職で達成したいこと
リスク：そもそも三年後に会社が残っているか、プロダクトが成功しそうか、など

比重としては、

環境：10%
軸：70%
リスク：20%

という感じ。

幸か不幸か独身で養うものは自分と猫くらいなので、あまり年収などにはこだわらず、リスクも取れるよねということで、自分の軸にマッチするかどうか、を重めにみていました。

で、その基準で考えたときに Viibar がどうだったかというと、こんな感じでした。

環境

年収はシンプルに上がる（ここは他の2社も同じ）
テレワークが「選べる」（出社してもいいし、しなくてもいい）
ワークライフバランスも良さげ（業務委託としてSlack見ていて、全体的に残業少ない印象だったり、休みが取りやすい印象だったり）

軸

ここはちょっとボリュームあるので、少し細かめに。

価値観が合うこと（ミッションビジョン、中で働く人のキャラクターなど）

この辺は、半年くらい業務委託として一緒に働いてみて、また2か月くらい MTG などに出まくって、合うなーと感じました。

印象としては、素直な人が多い、という感じ。

Biz 側、エンジニア側、ともにコミュニケーションは楽というか、変に疲れるとかはないかなーという印象でした。

人、組織の成長に投資を惜しまない

Viibar では外部からスクラムマスタを入れて、組織としてスクラムを勉強、身に付けようとしています。

スクラム導入は最近多いのですが、ちゃんとお金を払って、メンバーの時間も投資してしっかりとそこをやっていこうという企業は珍しいなーという印象でした。

また、その流れでスクラムマスタの研修受けたいといったら、あっさりOKがもらえました（自分に余裕がなくて忘れてましたが、そろそろ受けよう…）。

書籍購入制度もあります（最近どこもやってる気はするけども）。

業務委託として参加していたときに学んだスクラムやチームビルディングの話とか、Viibar での経験が既に他社の面接で活きた、ということもありました。

他社の面接で Viibar の志望度が上がるという謎現象があったり。

結構これが自分としては大きかった気がします。

プロダクト作りに関われる

開発は開発だけやっていればいい、ではなくて、Biz 側、エンジニア含めて全員でプロダクトを作っていくんだ！という意識を MTG に参加していると感じました。

実際 Viibar では、スプリントレビューで実際のお客様を巻き込んで新機能のレビューなどをおこなっていてそこにエンジニアもがっつり関わっていますし。

自分自身は開発だけしていたい、ではなくて、ビジネスにもしっかり関わっていきたいタイプなので、惹かれたポイントの一つでした。

チーム作りの本当に初期の段階から関われる

ある程度の規模の企業だと既に人が居て、その人たちとどうやっていくか、という話になります。

一方、Viibar （というか VideoTouch）ではまだ人が少ないので、どういう人が欲しいか、を考えて採用するところから関与できます。

あとチーム作りについても勉強会をやってたりとか、勉強して、かつ実践しやすい環境が整っているのもポイントでした。

（組織的に）我慢強い

副業探す際に転職ドラフトで6社からオファーもらったんですが、Viibar 以外は「いつ正社員で来れる？」とか、急かす感じが強かったんですよね。

そもそも業務委託のみで、転職は考えてないことを明記してたんですが…。

そんな中、Viibar だけがその辺の話を全くせずに話をしてくれたんですね。

また実際に週一で業務委託として働き始めてからも、Viibar からはその話（正社員云々）は出してこなかったです。

いい意味で我慢強い組織だと思いますし、ちゃんとこちらのことを考えてくれているなーというのが伝わってきたのも入社を決めた理由の一つだった気がします。

リスク

スタートアップというところもあり、当然リスクはあります。

どんなに年収があがろうと、貴重な経験ができそうであろうと、入社して１ヶ月で会社が潰れたら何にもならないですしね。

じゃあ Viibar はどうだったかというと、

スケールするかどうか

当然ですが、スケールするかどうかは賭けの部分もありますよね。

例えば自分は将来的なキャリアパスとして EM、VPoE を目指しているのですが、スケールしなかった場合マネジメント対象のメンバーが増えないので、経験も積めません。

なので、下手したら怒らせて内定がもらえないかも…、という覚悟で色々突っ込んだことも聞いたのですが、怒らずにちゃんと答えてくれました。

で、その上で自分は自分が JOIN するプロダクトである VideoTouch がスケールすると判断したので JOIN した、となります。

その際、自分は業務委託として既に半年以上 JOIN していたので結構バイアスかかってるよなーと思い、人と壁打ちしたりして極力客観的に判断できるように工夫したりしました。

30代という働き盛り真っ盛りの貴重な時間を数年分投資することになるので、なんなら今持っている全財産この会社に投資しても後悔しないか、くらいの勢いで考えた結果の判断です。

（プロダクトとして）整っていない部分が多い

スタートアップといいつつ Viibar は少し事情が違っていて、設立は2013年と既に結構長く続いている会社だったりします。

なので、スタートアップでありがちな環境がガチで整っていない、ということはなく、例えば PC の手配だったり社内システムや環境だったりは既に整っている状態となります。

一方で、VideoTouch というプロダクトでいうとまだまだ整っていない部分が多い状態です。

じゃあそれって悪いことだっけ？でいうと、自分のやりたいことと「整っていない＝これから求められること」がマッチしていたので、やりたいことができる（しかもやったら喜んでもらえる）と言う意味で、自分にとって美味しい状況だなーと思いました。

ただ整っていない部分に自分がストレスを感じたり、やりたいこととアンマッチだったりすると辛いので、そこは一つリスクかなーと思ってチェックしていました。

最後に

そんなこんなで、自分は Viibar に入社を決めました、という話になります。

当時のメモを割とそのままに書いているので自分の考えが結構ダイレクトに書いてあったりでちょっと恥ずかしかったりもしますが…。

転職の際の判断軸というところで少しでもご参考になれば幸いです。

2021-08-10

GitHubでよく使っている機能まとめ

Viibarのエンジニアの id:mstssk です。

Viibarの開発部では、発表者を持ち回りにして好き勝手なことを発表しあう社内勉強会をやっています。

発表内容は本当に好き勝手でよく、初めて発表担当が回ってきたときは延々Splatoonの話をしたりしたんですが、今回は「もっとみんなGitHub使いこなそうぜ」という内容にしました。

※この記事はZennにも投稿しています。

id:mstssk がGitHubを使うにあたって日常的に使っている機能などなどです。社内勉強会のために書き出したものをちょっとだけ清書して投稿しています。

定期的に確認するページ

ページ	URL
通知	https://github.com/notifications
レビュー依頼	https://github.com/pulls/review-requested
自分が担当のIssue,PR	https://github.com/pulls/assigned
自分へのmention	https://github.com/pulls/mentioned

ただし、仕事では特定のOrganizationだけにスコープを絞りたいので、次のようなURLをブックマークして使ってます。

https://github.com/pulls?q=is%3Aopen+user%3AViibar+assignee%3Amstssk

Pull Request の Draft 機能

PRをDraftにしておくことで作業中であることを明確にできます。 Draft機能ができる前はPRのタイトルに [WIP] と入れたりしていました。

ただし、DraftのPRでもレビュアー設定をしたら、レビュアー設定された人に通知が飛びます。不必要にノイズを飛ばさないよう、レビューできる状態になってからレビュアーは設定しましょう。

自分をアサインする

機能というか習慣です。

https://github.com/pulls/assigned のページを活用して自分が現在携わっているものを一覧しやすくするためにも、作業中のIssueやPRには基本的にちゃんと自分をアサインするべきです。

アサインするのを忘れがちなのなら、 https://github.com/apps/auto-assign のような自動でアサインするBotを使ってもいいです。

PRをレビュー依頼を出す前にrebaseする

これも習慣やお作法の類です。トピックブランチで作業している間にベースブランチが進んでいるとかはよくある話なので、動作確認してレビュー依頼出す直前にrebaseしておきましょう。

$ git fetch
$ git rebase origin/master topic
$ git push origin topic --force-with-lease

Permalink

GitHub リポジトリ上のファイルの特定の箇所を指し示す時、そのブランチの変更に関わらず一定になるPermalinkを使いましょう。

タグの場合ならこういうURL https://github.com/mstssk/rollup-plugin-cleandir/blob/v1.0.0/index.ts#L4

Blameしながら親コミットをたどる

Blameの画面で、そのコミットが適用される前のコミットに移動するリンクがあります。どういう経緯で変更が行われたのか参照するときに便利です。

ただし、コミットログが雑にされている場合もあり、どちらかというと次のコミットからPRをたどる方法の方をよく使ったりします。

コミットが所属するPRを参照する

各コミットのページには、そのコミットが含まれているブランチやタグ、PRへのリンクがあります。このリンクからPRを見に行く事で、どういう目的で手が加えられたか参照できます。私が所属するプロジェクトでは、コミットログについてはあまり口を出さないが、すくなくともPRではどういう目的の実装なのか書いていたり関連するIssue Trackerへのリンクが貼られているかもレビュー時にチェックすることで、最低限は実装の由来を将来辿れるようにしている事が多いです。

Organizationごとに別のメールアドレスに通知する

仕事用とプライベートとでGitHubアカウントを分けていない場合、仕事のOrganizationのリポジトリに関連する通知がプライベートのメールアドレスに届いても困ります。

GitHubは所属しているOrganization別に通知先メールアドレスを切り替える事ができます。仕事用のメールアドレスをGitHubアカウントに追加して、会社のOrganizationだけ仕事用のメールアドレスに切り替えておきましょう。

docs.github.com

2FAはアクセストークンをパスワード代わりにするよりSSH keyで

docs.github.com

GitHub アカウントを2FAにしておくと、リポジトリにpushする時にパスワードを求められたりしてびっくりしたりしつつアクセストークンを設定したりしたものですが、今はマシン別にSSHキーを準備して済ませています。

リポジトリをcloneするときもSSH形式で行っておくとスムーズです。

トークン使う方法でも同じくらいシンプルにできるかもしれませんが、自分はSSH keyで済ませるほうがしっくりきたので。

Security Alerts

docs.github.com

依存関係の脆弱性アラートとDependabotの自動バージョンアップPR作成は有効にしておきましょう。

依存の依存の依存パッケージに脆弱性アラートが上がったときなんかは複雑すぎてDependabotがエラーになってたりしますが。

GitHub リポジトリのwatch

特定のissue,PRだけをwatchもできる
- 使っているOSSの特定のバグを踏んだ時、その対応をしているissueをwatchしてpatchが公開されたらすぐ対応できるようにとか
カスタムwatchでリリースだけチェックするというのもあり

リポジトリ内のファイル名で検索

あれ？あそこどうなってたっけ？と思った時に手元でIDE立ち上げるより、GitHub リポジトリ上でファイル名で検索したほうが早いこともあります。

「Go to file」ボタンでもいいですが、 t でショートカット起動を覚えておくと楽です。

他のショートカットなどはこちら。

docs.github.com

Schedules reminders

https://github.com/settings/reminders/

SlackとGitHubを連携させておくと、チームのチャンネルに通知したりもできますが、個人用にスケジュールを決めたリマインダーも設定できます。

id:mstssk の場合は、毎日特定の時間にチームのチャンネルにレビュー待ちなどの通知がくるのとは別に、レビュー依頼が出されたらリアルタイムで通知してくれるようにもしています。

参考: dev.classmethod.jp

PRのレビュー時の便利機能

☑️ Viewed

レビュー対象のファイルが多い場合に特に使います。 ☑するとそのファイルが折りたたまれてくれるので、他のファイルの確認に集中できます。

Hide whitespace changes

空白のdiffを無視して表示してくれます。インデントが変わってるだけなど、不必要なdiffを無視してレビューできます。昔から隠し機能としてURLに ?w=1 を付けるとwhitespaceのignoreができたのですが、あるタイミングでちゃんと機能としてUIに搭載されました。

github.blog

Suggested changes

レビューで具体例を挙げてこう直すといいよ、と伝える場合に使える機能です。ちょっとしたtypoの指摘などにも使えます。レビュイーはそのまま取り込むことも出来ます。あくまでPRとして出されたdiffの中でしか使えないので、周辺のコードも含んだ大きめの変更指摘なんかには使えません。

docs.github.com

GitHub外の機能

Octotree https://www.octotree.io/

現在開いているリポジトリ・ブランチの内容をツリー表示してくれます。特定のファイルを見たいわけでなく、上からたどって探したいときなんかに重宝します。

2021-05-07

Yarnを使うとAzure FunctionsのGitHub ActionsからのZipデプロイが檄遅になるのを回避する

JavaScript Yarn npm Azure

Viibarのエンジニアの id:mstssk です。

先日リリースしたVideoTouchではAzureのマネージドサービスを組み合わせて開発を行っています。

videotouch.jp

Azure Functionsでのデプロイで「そんなところが影響するの！？」と罠を踏んだところがあったのを記事にしてみます。

※この記事はZennにも投稿しています。

npmとYarnでファイルのタイムスタンプの扱いが違うとかとんでもない罠だ。

問題

Azure FunctionsにJavaScript(TypeScript)のコードをGitHub ActionsでAzure/functions-actionアクションを使ってZipデプロイを行なっていました。プロジェクトは func init --typescript で生成した構成ほぼそのまま。パッケージマネージャーをnpmからYarnに変えたところ、数分で済んでいたデプロイが数十分かかるようになってしまいました。

原因

Azure/functions-actionアクションを使ってデプロイする場合、node_modulesディレクトリごとZipで固めてデプロイ先の環境に展開しなおします。ですが、毎回全ファイルをコピーしているわけではなく、タイムスタンプが更新されていなければスキップするようになっています。

Efficient file copy: Files will only be copied if their timestamps don't match what is already deployed. Generating a zip using a build process that caches outputs can result in faster deployments.

https://github.com/projectkudu/kudu/wiki/Deploying-from-a-zip-file-or-url#comparison-with-zip-api

ここで、npmとYarnの動作の違いがネックになってきます。

npm

npmはnode_modulesの下に展開されるファイルのタイムスタンプを全て 1985-10-26T08:15:00.000Z に固定しています。これは、タイムスタンプの違いによってファイルのハッシュ値が異なってしまい発生する問題を回避するためだそうです。 https://github.com/npm/npm/commit/58d2aa58d5f9c4db49f57a5f33952b3106778669

Yarn

一方、Yarnではnode_modulesの下のファイルのタイムスタンプは、単純にインストールを行なった日時、またはローカルキャッシュされた日時になります。つまり、GitHub Actions(またはその他のCI)でYarnのキャッシュを持ち回すようにしていない場合、常にCIが走った日時のタイムスタンプでZipデプロイが行われることになります。

npmでも一番最初のデプロイでは全ファイルのコピーが行われていましたが、当時は依存パッケージも少なく気にならなかったので気付いていなかっただけのようです。

解決策

npmに戻してしまうのも手段の一つです。しかし、やんごとなき理由でパッケージマネージャーをYarnにせざるを得ないこともあるので、Yarnを使う前提の回避方法が必要です。¹

キャッシュによって問題を回避する方法と、抜本的にAzure Functionsの使い方を変えてしまう方法の2種類があります。

キャッシュする

Yarnではnode_modulesの下のファイルのタイムスタンプはキャッシュに依存するので、素直にGitHub Actions上でYarnのキャッシュを保持するようにしましょう。

公式のcacheアクションのドキュメントにYarnの場合のサンプルが載っているので参考にします。

https://github.com/actions/cache/blob/main/examples.md#node---yarn

GitHub Actionsの設定ファイルは、例えば次のような形になるはずです。

# .github/workflows/deploy.yml の関係するstepsだけ抜粋
- name: Get yarn cache directory path
  id: yarn-cache-dir-path
  run: echo "::set-output name=dir::$(yarn cache dir)"
- uses: actions/cache@v2
  id: yarn-cache
  with:
    path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
    key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
    restore-keys: |
      ${{ runner.os }}-yarn-
- run: yarn install --frozen-lockfile
- run: yarn run build
- run: yarn install --frozen-lockfile --production
- name: Deploy
  uses: Azure/functions-action@v1
  id: fa-foobar
  with:
    app-name: func-foobar
    publish-profile: ${{ secrets.FOOBAR }}

Run From Package

Zipパッケージを環境上に展開するためファイルコピーに関連する問題が発生してしまっています。そこで、Zipパッケージをそのまま実行ファイルにする方法が用意されています。

https://docs.microsoft.com/ja-jp/azure/azure-functions/run-functions-from-deployment-package

むしろ今Azure Functionsを使うならRun From Packageを使うのが安牌なのですが、手が追いついてませんでした😓 既にZipデプロイをしているなら、よほど特殊な事をしていない限りはRun From Packageへの移行はすんなりいきます。

🍏はnpmでいいじゃん派です。↩

2021-04-16

jest.config.jsや.eslintrc.jsで入力補完する

Viibarのエンジニアの id:mstssk です。

つい先日、ここ1年ほど作ってきた新サービスVideoTouchを公開しました。

videotouch.jp

TypeScriptを使っている部分ではJestでテストしたり、ESLintを使っています。それらのコンフィグファイルを書いていて、もどかしかった部分を簡易的に改善する方法を知ったので記事にしてみます。

※この記事はZennにも投稿しています。

jest.config.jsや.eslintrc.jsとかを書くときに入力補完したいなー、でもそのためだけにVisual Studio Codeの拡張入れたり、ts-nodeを導入してjest.config.tsにするのはやりすぎな気がするなー、と思っていました。

調べていたら、JSDocでTypeScriptの型定義を使えるとわかったのでメモ。

サンプル

// jest.config.js
/** @type {import("@jest/types").Config.InitialOptions} */
const config = {
  preset: "foobar",
};
module.exports = config;

// .eslintrc.js
/** @type {import("@typescript-eslint/experimental-utils").TSESLint.Linter.Config} */
const config = {
  extends: ["foobar"],
};
module.exports = config;

@typescript-eslint/experimental-utilsからインポートするのは微妙だけど他に良い感じのを見つけられなかった。

注意

module.exports = {} と直接exportする書き方にすると余計なものもサジェストされてしまいます。 objectではなくコードのブロックと見なされてしまうので無関係なglobalスコープのクラス名とかまで入力候補に出てきてしまいます。一度変数に代入しましょう。

/** @type {import("@jest/types").Config.InitialOptions} */
module.exports = {
  // 👎 objectではなくコードのブロックと見なされてしまうので関係ないものもサジェストされてしまう。
};

スクリーンショット

Visual Studio Code 1.55.0 で動作確認。

入力補完中のスクリーンショット

参考

qiita.com

jsdoc.app

2021-01-06

VAddyを使用して脆弱性診断を実施した話

こんにちは。エンジニアの@daikichiです。今回は、弊社サービスにセルフ脆弱性診断ツールVAddyを導入した時の話をしたいと思います。

脆弱性診断の診断方法

大きく2パターンあります。

ツール診断
- メリット: ⾃動で効率的に膨⼤なパターンをチェックできる
- デメリット: 複雑なシステムで検知率が上げづらい
⼿動診断
- メリット: セキュリティの専⾨家が実施し、ツールでは⾒つけづらい脆弱性に対象可能
- デメリット:専⾨的な知識が必要となるため、価格が⾼く時間がかかりやすい

導入予定のサービスでは今後の開発を見込んで、継続的に診断できる方法を検討していました。その中でも、現在の環境でもっとも効率が良いと感じたのがツール診断にあたるVAddyでした。

VAddyとは

クラウド型Webアプリケーション脆弱性診断ツールでサーバのOS、ミドルウェア、開発言語に関わらず検査可能です。ツール診断を主としていますが、手動診断にも対応しています。

VAddyを選んだ理由

セキュリティに精通していないエンジニアを対象としている為操作が容易
- クローリングからスキャン、結果確認まで全て管理画面で実施可能
- 検査項目は必要最低限
- 脆弱性実施までのフローがシンプル
API連携可能（CI連携可能）
サポートのレスポンスが速い

特に驚いたのがサポートのレスポンスの速さです。もちろんその時の状況にもよると思いますが、私が何を聞いても営業担当、エンジニア担当の方からの迅速、的確なレスポンスで安心でした。これは他ツールで検証した中でも断トツで、長く利用する事を前提に考えていたので大変心強かったです。

診断項目

検査項目はプランによりますが、最大9つの検査項目が用意されています。導入サービスでは初めて脆弱性診断を実施するという事もあり、初月一番上のEnterpriseプランを契約する事にしました。 9つでは少なく感じるかもしれませんが、これでも現実の攻撃の約90%(※クラウド型WAF「Scutum」の観測から算出)をカバーしているとの事です。

「()」内はどのOWASP TOP 10 に対応しているかを記載

[Enterprise][Professional][Strater]　SQLインジェクション(A1 インジェクション)
[Enterprise][Professional][Starter]　クロスサイトスクリプティング (A1 インジェクション)
[Enterprise][Professional]　　　　リモートファイルインクルージョン(A1 インジェクション)
[Enterprise][Professional]　　　　コマンドインジェクション (A1 インジェクション)
[Enterprise][Professional]　　　　ディレクトリトラバーサル (A3 機微な情報の露出)
[Enterprise][Professional]　　　　ブラインドSQLインジェクション (A1 インジェクション)
[Enterprise]　　　　　　　　　安全でないデシリアイゼーション (A8. 安全でないデシリアライゼーション)
[Enterprise]　　　　　　　　　 XML外部実体攻撃 (A4 XML外部エンティティ参照)
[Enterprise]　　　　　　　　　　HTTPヘッダインジェクション (A1.インジェクション)

脆弱性診断実施のステップ

基本的な使い方だと4ステップで簡単に脆弱性診断ができます。スタートアップガイドに沿ってやれば問題なく実行できました。

【STEP 1】プロジェクトの作成
【STEP 2】クロール(シナリオ作成)の設定と実行
【STEP 3】スキャンの実行
【STEP 4】レポート確認

クロール時のTips

クロールするブラウザはFireFoxがよい
- → VAddyプロキシを通す必要があるので、設定が必要になりますが、Google Chorome、Edgeはブラウザだけで設定できなくて、OSのネットワーク設定でやらないとできない
外部サイトからライブラリを読み込んでいるアプリケーションはプロキシの除外設定が必要
- → VAddyのProxyサーバーは管理画面で登録されたFQDNとの通信だけを許可している為

実施所感

初期設定から1時間もかからずに診断の実施ができました。レポートの画面はシンプルで見やすいです。リクエスト、レスポンスの検査データ情報が確認できるので、あとはコードと照らし合わせて実際に脆弱性の問題があるかの確認をする流れです。

本来ならクロール(シナリオ作成)まで自動化できればよいのですが、それはまた別の機会に。

まとめ

VAddyはセキュリティに精通していない開発エンジニアでも使えるようにシンプルに設計されていて、良い
セルフVAddyの利用で100%安心というわけではなく、規模、フェーズによっては手動診断を実施するのがよい

2021-01-05

AzureのApplicationGatewayにAppServiceの証明書を使う方法

あけおめ、年末は積みゲー消化のために、対馬を救いながら、稲作していたら、終わってしまいました、id:gaoohです。近未来でサイボーグで戦いたいのに、まだ手が回らない。

本題です。年末、AzureのApplicationGatewayにAppServiceの証明書を適用するのではまったのでブログにまとめます。

手順

前提としてAppServiceの証明書は発行して利用できる状態であるとします。

まずApplicationGatewayがKeyVaultの証明書を取得できるように、証明書の参照権限をもった User Assigned Managed Identity IDを発行し紐づけます。その上でApplicationGatewayで利用する証明書を登録という手順が必要です。

1. ApplicationGateway に User Assigned Managed Identity ID を発行

f:id:gaooh:20210104221343p:plain

2. 発行した User Assigned Managed Identity ID に証明書の参照権限を付与

f:id:gaooh:20210104221237p:plain

3. ApplicationGatewayで利用する証明書を登録

これは 2020/12 月の段階ではWebUIは用意されていないのでコマンドで

az network application-gateway ssl-cert create --gateway-name "#{gateway-name}" \
  --resource-group "#{resource-group-name}" -n #{sslname} 
  --key-vault-secret-id "https://#{key-vaultname}.vault.azure.net/secrets/****"

PowerShellがお好みだったらこっちを参考 docs.microsoft.com

以上を行うとリスナー作成時の証明書の選択肢に該当の証明書が選べるようになります。

ハマったポイント

以前はこのコマンドもなかったのか、証明書を一度エクスポートしてApplicationGatewayに登録するという方法が取られていて、ぐぐるとその方法が出てくる。なんならWebコンソールだけ見ているとそれしか方法がないように思える。

f:id:gaooh:20210104221241p:plain

「そうかエクスポートするのか」と思い、うっかりこの方法で行ってしまった。

ちなみに一応できたんのだが、PowerShellで証明書をエクスポートすると中間証明書がないものがエクスポートされるので、うっかりそれを設定してしまったのです。中間証明書ってなくてもブラウザで確認するだけだと気がつかなくて、気がつくのが遅れたという二重の罠にもハマりました。

この方法だと証明書の更新の際に作業が必要なので、ApplicationGatewayの利用をしたいだけなら今は利用すべきじゃないので、当初書いた手順が正しい。

いじょ。

2020-12-17

Chrome拡張機能のminimum_chrome_versionを安易に設定してはいけない

Chrome拡張機能

最近Chrome 拡張機能を触ってる id:mstssk です。

つい先日、Chrome 拡張機能の審査でハマったのでのでそのまとめです。

3行まとめ

manifest.jsonのminimum_chrome_versionフィールドには、ちゃんと機能上必要なAPIのサポートバージョンに準じた値を設定しよう。またはいっそ設定しない。
2020年11月発表のポリシーの改定の際に、おそらく審査システムも変更され、minimum_chrome_versionが最近すぎると即審査が不承認にされるようになった。
安易に「最新のChrome 87でだけ動作確認したから"87"にしておこう。古いChromeで動かされても困るし」とかやってはいけない。

何があったか

ここしばらくChrome 拡張機能を仕事でいじっています。その中でminimum_chrome_versionを安易に指定していたためにハマりました。

minimum_chrome_versionとは

Chrome 拡張機能のメタ情報を管理するmanifest.jsonファイルにはminimum_chrome_versionというフィールドがあります。このフィールドは必須ではないですが、バージョン番号を設定しておくと「このバージョン未満では動作しないのでインストール不可」という制御が行なえます。

developer.chrome.com developer.chrome.com

そこで「動作確認してない古いChromeで動かされても困るから、とりあえず今の最新verにしておこう」と考えて、開発当時のChromeが83だったので"minimum_chrome_version": "83" とmanifest.jsonに設定しました。

しばらくは、それでChromeウェブストアの審査は何事もなく通り、ちょくちょくアップデートを上げる際も問題なく審査が通っていました。

突然の不承認の嵐

11月中旬に少し大きめの変更を審査に出したときのことです。「説明に表記されている機能を提供していない。」という理由で初めて不承認となりました。

そんなばかな！？大きめの変更とはいえUIの更新が主で機能は変わってないぞ！？

アプリストアの類で審査に落ちる事自体はよくある話なのですが、この時は変更内容と指摘事項が乖離していて混乱しました。
たまたま厳しいレビュアーにあたってしまったか、ログイン必須なものなので公の機能を提供できていないと判断されたか…など考えたものの、不承認となったのはしょうがないので怪しいところを直して再提出をしました。
UIの動線を変えたり、実装上の都合で付けていたpermissionを外して何とか代替実装にしたり、といった事をしましたが、その後3連続で不承認となりました。

サポート問い合わせと拍子抜け

提出物を詳しく調べたところ、ポリシーに準拠していることがわかりました。

サポートに異議申し立てを送信したところ、そんな内容の返信がすんなり返ってきました。
なんじゃそりゃと思いつつ、返信に従って同じものを再度審査に送信し直したら、無事審査を通過しました。 *1

たぶん審査システムが変更された？

その後もサポートとやり取りしたところ*2、審査側で「システムが"This extension requires Google Chrome version 83 or greater. Could not load manifest."というエラーで不承認にしたがその後詳細に調べたところChrome 83以降で動作することを確認した」といった返信が来ました。

そうしてやっと合点がいきました。
ちょうど不承認をくらったあたりで、Chromeウェブストアのポリシー改定が発表されており、ストアのダッシュボード上の入力項目が増えたりしていました。

blog.chromium.org

あくまで推測ですが、ポリシー改定のタイミングで審査システムも変更が入ったのではないでしょうか。それが審査システムの不具合なのか、それともある程度古いバージョンもサポートすることを念頭に置いたものだから新しめのバージョンでは不承認となってしまのか、詳しいことはわかりません。

しかし、この後minimum_chrome_versionフィールドの値を機能上必要なAPIが実装されたバージョンまで落としてから審査に出した際は、すんなり審査が通りました。

参考

Manifest - Minimum Chrome Version - Chrome Developers https://developer.chrome.com/docs/extensions/mv2/manifest/minimum_chrome_version/
Google Developers Japan: Chrome 拡張機能の透明性の高いプライバシープラクティス https://developers-jp.googleblog.com/2020/12/chrome.html
- 原文: Chromium Blog: Transparent privacy practices for Chrome Extensions https://blog.chromium.org/2020/11/transparent-privacy-practices.html

*1:実際は、再送信したらまたそれがrejectされて、また異議申し立てしたら"今度はこっちで通過させておきます"的な返事が来てやっと通ったりした。

*2:その次のリリースでまた不承認になってまた異議申し立てしたの意

3行でまとめると

詳しく

環境

軸

価値観が合うこと（ミッションビジョン、中で働く人のキャラクターなど）

人、組織の成長に投資を惜しまない

プロダクト作りに関われる

チーム作りの本当に初期の段階から関われる

（組織的に）我慢強い

リスク

スケールするかどうか

（プロダクトとして）整っていない部分が多い

最後に

定期的に確認するページ

Pull Request の Draft 機能

自分をアサインする

PRをレビュー依頼を出す前にrebaseする

Blameしながら親コミットをたどる

コミットが所属するPRを参照する

Organizationごとに別のメールアドレスに通知する

2FAはアクセストークンをパスワード代わりにするよりSSH keyで

Security Alerts

GitHubリポジトリのwatch

リポジトリ内のファイル名で検索

Schedules reminders

PRのレビュー時の便利機能

☑️ Viewed

Hide whitespace changes

Suggested changes

問題

原因

npm

Yarn

解決策

キャッシュする

Run From Package

サンプル

注意

参考

脆弱性診断の診断方法

VAddyとは

VAddyを選んだ理由

診断項目

脆弱性診断実施のステップ

クロール時のTips

実施所感

まとめ

手順

1. ApplicationGateway に User Assigned Managed Identity ID を発行

2. 発行した User Assigned Managed Identity ID に 証明書の参照権限を付与

3. ApplicationGatewayで利用する証明書を登録

ハマったポイント

3行まとめ

何があったか

minimum_chrome_versionとは

突然の不承認の嵐

サポート問い合わせと拍子抜け

たぶん審査システムが変更された？

参考

GitHub リポジトリのwatch

2. 発行した User Assigned Managed Identity ID に証明書の参照権限を付与