ikasama over technology

忘れたくないことを忘れないために

GitHub の Saved replies でレビューコメントにラベルをつける

f:id:ikasamak503:20210612100539p:plain

こういう感じで GitHub のレビューコメントにラベルを付けています。

効果として、

  • レビューコメントのスタンスがレビュイーに明確に伝わる
  • 対応するべきか、そのままでもいいかレビュイーが判断しやすい

などを期待しています。 ただし、それぞれの意味や対応方針をレビュアーとレビュイーの間で合意しておく必要はあります。

簡易的には、テキストのみのラベルでも十分伝わると思います。以前はそういう運用をしていました。 しかし、画像のほうが視覚的に判別しやすいと思い、最近は画像でラベルを表現するようにしています。

しかし画像を貼り付けるのは面倒

一方で、画像やその URL をレビューコメントに毎回貼り付けるのは少々手間です。 そこで GitHub の Saved replies に定型文として登録して、入力の手間を省きます。

GitHub Saved replies

https://github.com/settings/replies からアカウントの Saved replies を設定します。

f:id:ikasamak503:20210613134813p:plain
Saved replies の設定画面

画像ラベルの作り方

画像は https://shields.io/ で生成する SVG を使います

shields.io

SVG を生成する URL のパターンは https://shields.io/ に書いてある通りで、 https://img.shields.io/badge/<LABEL>-<MESSAGE>-<COLOR> で指定します。

f:id:ikasamak503:20210613134407p:plain

たとえば、 Suggest の場合は以下の URL を使っています。色は好みのものを使いましょう。

https://img.shields.io/badge/review-suggest-success.svg

https://img.shields.io/badge/review-suggest-success.svg

あとはこれを Markdown で見れる形にして Saved replies に放り込むだけです。

![suggest](https://img.shields.io/badge/review-suggest-success.svg)

実際に Saved replies を利用して画像ラベルを挿入する様子

f:id:ikasamak503:20210613141012g:plain

おまけ

以下は、僕がレビューコメントで用いているラベルとその意味です。

must Must fix

  • 絶対直してくれというレベル
    • Request changes で投げることが多い
  • 明らかに仕様を満たしていないとか、セキュリティ的にまずい実装など
  • あるいはコードにコミットするべきでない物が混入したときなど
    • 何らかのシークレットや顧客の情報など、コードが漏洩した際に悪影響があるもの

should Should

  • 言葉通り、こうすべき、というニュアンスで使う
  • 機能仕様は満たしてるかもしれないけど、パフォーマンス上の懸念があるとき
  • フレームワークの扱い方

suggest Suggest

  • こう書いたほうがいいよ
  • 後述の In my opinion より、客観的に推奨するもの
  • たとえば、 Laravel にはこういう便利なヘルパーがあってな、とか

imo In my opinion

  • こういうふうに書いたほうがいいと思う、という意見
  • あくまでレビュアーの意見の一つでしかなく、取り入れるかはレビュイーに任せる、という扱い

nits nits

  • typo やコーディングスタイルなどの軽微なミス
  • これ直したあとでマージしてよ、くらいのノリで Approve と一緒に投げることもある

ask Ask

  • レビュイーへの質問

boyaki Boyaki

  • ぼやき、そのまんんま
  • コードスメルがありそうなところ
  • このレビューを通して修正するには問題が根深かったり、大きすぎるとき
  • いずれリファクタリングしたいねというような結論にして、 issue を切る事が多い

参考

qiita.com

Google CTF 2020 に参加した感想

f:id:ikasamak503:20200825232932p:plain
最初の問題が解けた瞬間はかなり興奮した

Google CTF 2020 に参加しました。

capturetheflag.withgoogle.com

Google CTF 2020 は日本時間で 8/22 9:00 ~ 8/24 8:59 の間、開催されました。 僕は 8/23 の夕方〜24 時ごろまでやってました。 CTF 自体は入門者ですが、会社の同僚に誘われる形で参加しました。

解いた問題

Web を 2 問解きました。 とはいえ、いずれも、最終的には CTF 経験者である同僚の力を借りてなんとか解けたという感じです。

詳しい Write-up は他の人に譲ります。 以下、ざっくりとした解説。

PASTEURIZE

  • XSS の問題
  • サーバー (Node.js/Express) とクライアント (HTML/JavaScript) のコードは提供される
  • BotXSS を踏ませるせることで、 BotCookie にある Flag を盗む
  • POST 時にサーバーサイドのコードでバリデーションをかけていない+サニタイズが弱い
  • そこにオブジェクトを突っ込むことで XSS を起こした

LOG-ME-IN

  • SQL インジェクション? の問題
  • サーバー (Node.js/Express) とクライアント (HTML/JavaScript) のコードは提供される
  • Flag を持っているユーザーで偽装ログインすることで Flag を盗む
  • ログイン時のユーザー照合 SQL はちゃんと Prepared Staatement 使ってるので、 SQL インジェクションではないと最初は思った
    • 結局これもリクエストパラメータをバリデーションしてないので、オブジェクトを突っ込むことで SQL インジェクションみたいになった
  • 他の問題用のコードが紛れていて、だいぶ惑わされた

結果

我らが Tomatosalad は 4 問解いて 163rd に落ち着きました。 600 チームくらい参加してるので、いいほうなんじゃないでしょうか?

f:id:ikasamak503:20200825234829p:plain

感想

  • CTF 初参加で問題解けてよかった
  • Web は頑張ったらもうちょいいけそう
    • Web の仕事してるしそりゃね、、、
  • 同僚に教えてもらった、BotXSS 踏ませて Cookie を抜く手順はとても参考になった
  • Write-up で解けなった問題の解説を見るのも楽しい(そしてちょっと悔しい)
  • 他の分野もいずれ挑戦してみたい

Trello で夫婦共同 ToDo List を作った

個人的には少し前から Trello で ToDo List を作っていたけど、 最近は妻 *1 にも脳のメモリをオーバーするタスクが増えてきたので、一緒に管理することにした。

f:id:ikasamak503:20200107021139p:plain
Trello ボードの様子。ボード名は 人生

ルール

運用始めて一週間も経ってないので、まだ暫定だけどこんな感じ。

1. 週に一度、その週にこなすタスクを計画する
  • weekly レーンに今週やる予定のタスクを優先度順に並べる
  • 各レーンのタスクの優先順位や来週以降のざっくりした計画を確認する
2. 完了したタスクは都度 Done レーンに移す
3. 思いついたタスクはいつでも各レーンに投入してよい
  • 優先順位も好きに並び替えて良い
4. 週に一度、その週に完了したタスクを振り返る
  • Done レーンのタスクの完了を確認してアーカイブする
  • 完了した数や完了できなかった原因を振り返って、次回の改善にネタにする

あらゆるタスクを漏れなく管理するのは息苦しいので、 ぱっと思いついたが忘れたくないものをカジュアルにメモしておいて、 忘れないようにしていくのが無理がなくていいと思う。

妻の反応

妻は Trello のようなタスク管理ツールを使ったことはあまりないと思うけど(たぶん)、 アプリもサクッとインストールしてもう使いこなし始めている様子。 運用初日で 2 つのタスクを Done レーンまで持っていっていた。えらい。

f:id:ikasamak503:20200107032707p:plain
報連相もできている。えらすぎる。

期待する効果

  • 忘れるとまずいタスクを忘れずこなせるようにする
  • お互いのタスクを見えるようにして、負荷の確認やサポートができるようにする
  • うまくできたことを褒める習慣をつくる。良いコミュニケーションのきっかけにする。 *2
  • QoL の改善

まとめ

  • 夫婦共同の ToDo List を Trello のボードとして作った
  • 毎週振り返りして改善や褒めるなどする

しばらく運用してみて、何かアップデートがあったらまた記事を書こうと思う。

*1:厳密にはまだ入籍していないので婚約者。近日入籍予定。なので ToDo List にも入籍タスクがある。

*2:僕が寡黙で家であまり喋らないので

PHP カンファレンス北海道に行ってきました

phpcon.hokkaido.jp

セッション → アンカンファレンス → スポンサー LT → LT → 懇親会 という流れで見てきました。

感想: セッション

以下のセッションを聴講しました。

speakerdeck.com

PHP だけに限定せず、 汎用的なプログラミングや、 PHP を用いたアプリケーションの作り方を含んだ学び方・考え方の話。 職業エンジニアとなるための実践的な道標だと思います。いくつかは僕も過去に通った道ですが、またどこかで改めて振り返ってみようと思いました。


speakerdeck.com

フルリニューアルの話、前職では医療系のマッチングサービスをやってて、やっぱりフルリニューアルしてたので、しきりに「わかる」と心のなかで連呼していました。*1

  • 目的を見失わない。フルリニューアルはゴールではなく、スタート。新しい価値を素早く届けるための基盤を作ること。
  • フルリニューアルを行ってマイナスのインパクトが無い、ということはない

このあたりは金言だと思います。


speakerdeck.com

ブラウザテストがあると安心できるよね、やってみよう、という話。僕もほぼ同意見です。 API サーバーなら JSON 返してくるだけなので PHPUnit の Feature Spec で十分なんですが、 HTML をサーバーサイドでレンダリングする Web アプリケーションの場合はそうはいかないのでこういうテストが欲しくなります。

Selenium の難点は若干重いこと。ここさえなんとかなれば・・・。 あと Laravel Dusk を知れたのは大きな成果でした。次の Laravel Web アプリ案件に導入する予定です。


speakerdeck.com

AWS CDK、初耳でした。 プログラミング言語からコンパイルして CloudFormation テンプレートができて、デプロイまで出来るやつ。すごい。 似たようなツールに Pulumi があるけど、コレはお金がかかるので、 AWS がサポートしていて無料で使えるのは導入しやすそう。 でも僕は Terraform をやっていきたいので CDK は一旦様子見かな……。

感想: スポンサー LT

speakerdeck.com

弊社です。 書いてあることは社内の人からするとあるある、という感じの内容なんですが、社外の人はどういう印象を持たれたのか気になります。


speakerdeck.com

ス・マイル制度がいいな〜って思いました。特にアウトプットの価値を定量化するところは、見習っていきたい。

感想: アンカンファレンス

speakerdeck.com

MySQL, PostgreSQLアーキテクチャの違いとかあまり意識したことなかったので、それを知れるきっかけができたのは良かったです。

感想: LT

LT らしい LT を聞いたのは意外と始めてでした。 内容よりも、時間きっちりで喋りきってたり、勢いがすごいな〜、という印象のほうが強かったです。 個々のスライドのリンクは以下の Qiita 記事を参照してください。ちなみに LT 以外のスライドもほぼ網羅されています。

qiita.com

感想: 全体を通して

PHP カンファレンスと銘打ってますが、それに関連する技術も幅広く取り扱っていて多彩でした。 知らない技術スタックや考え方にふれるキッカケを得られたのが、自分にとっては大きな収穫だったなと思います。

その他

いま担当している案件で一緒に仕事している札幌オフィスのメンバー数名と直接会って話ができました。 今回の PHP カンファレンス北海道の参加の裏目的として達成できたので良かったです。

勉強し放題制度

カンファレンス参加に伴う旅費や宿泊費はゆめみの勉強し放題制度を利用して経費精算できます。*2 すごいぞゆめみ! でも本当は怖い。 経費精算するためにはアウトプットが必要なので、今必死になってコレを書いています。

www.yumemi.co.jp

懇親会のメシ

f:id:ikasamak503:20191001162152j:plainf:id:ikasamak503:20191001162155j:plainf:id:ikasamak503:20191001162158j:plainf:id:ikasamak503:20191001162200j:plainf:id:ikasamak503:20191001162204j:plain
懇親会のメシの写真。めちゃくちゃウマかった。

札幌についての知見

*1:僕はフルリニューアルの途中で辞めちゃったけど。今どうなってるのかなあ(遠い目)

*2:今回は金額が約 8 万円とでかいので、レビューが入ることになっています

株式会社ゆめみに入社して 2 ヶ月が経ちました

2019 年 7 月 1 日に入社したので、ちょうど 2 ヶ月です。 1 ヶ月や 3 ヶ月で振り返ることが多い気がしますが、個人的にはこのタイミングがちょうど良かったのと、気分も少しのったので、書くことにしました。

振り返り

7 月: オンボーディング、 Laravel と AWS 認定の勉強

最初の 1 ヶ月は、会社の売上に直接貢献する仕事はありませんでした。

ゆめみでは職能ごとのチームに所属した上で、そのチームが担当しているプロジェクトに参画するのが主流です。 私が所属したチームには 7 月の当初、ちょうどいいプロジェクトがありませんでした。 なので、使用予定の技術スタック ( Laravel, Lumen ) や AWS 認定の勉強をしていました。 結果的に AWS 認定は SAA を取得できたし、Laravel や Lumen に関しては腰を据えて勉強できて良かったと思います。

ikasamak503.hatenablog.com

ちなみに、資格取得の受験費用は勉強し放題制度によって全額補助されます。

note.mu

仕事がなくなったときこそ冷静に

一方で、入社時期に関わらず、メンバーや職能によってはクライアントワークが無いという状況は度々発生しています。 例えば、

  • 新規案件の受注を見据えて稼働予定を埋めていたが、最終的に失注した
  • サーバーサイドの開発規模を縮小することになった
  • その他、やんごとなき事情

とまあ、いろいろな理由で仕事がなくなることがあります。なくなったものは仕方ないですね。 とはいえ、仕事がなくなったからおしまい、とはせず、失注や仕事がなくなった事象に対する振り返りは行われているようです。 また、クライアントワークがない時期は自己研鑽や社内用ツールの企画・開発を通して将来への投資も行っています。

オンボーディング

note.mu

ここに書いてあるように、オンボーディングはまだ試行錯誤している最中という感じです。 僕が感じた課題点としては、

  • 情報が様々なツールやサービスに分散していて検索性が悪い
  • チームごとのオンボーディングは独自形式でバラツキがある

といったところです。 ちなみに、オンボーディングの一つの目安として「会社批判ができるようになる」という目標があって、 未だに会社批判をあれこれ考えていたりします。

8 月: クライアントワーク

4 月から開発している新規案件で、既存メンバーの引き継ぎという形で参画しました。 サーバーサイドの設計・開発という立場ですが、ものはほぼ出来ているので、いまはバグ改修や内部の改善といったタスクがメインです。 意外と Docker や AWS 関連の知識がチーム内で一番長けていたので、その分野でよく手を動かしたりレビューをやっていました。

入社して 1 ヶ月だけどお盆は 1 週間有給をとりました

ゆめみのメンバーは有給取り放題です。これは入社して間もないメンバーも対象です。

note.mu

法律や就業規則としては入社して半年経ってから有給付与ですが、それまでの有給が無い期間、この制度によって有給を取得することができます。

リモートワーク

週1回程度の頻度でリモートワークを実施しています。 現時点でリモートワークは、関わるプロジェクトマネージャーに確認をとる承認制となっています。 これは、プロジェクトによっては物理オフィスに出社してもらわないと困るとうケースがあったり(あるのか?)、 オフィスワーク推奨という考え方もまだあるためです。

note.mu

個人的には、IT エンジニアが働く場所なんてどこでもいいと思っているので、オフィスワーク推奨はよくわかんないですね。 一方で、リモートワーク推奨にしようという委員会ができていたり、 直近だと来年の東京オリンピックの時期は通勤どうするんだ、リモートワークか? という議論がされていたりします。

リモートワークの工夫の話をすると、最近は札幌オフィスのメンバーがプロジェクトにジョインされたこともあって、 ミーティング時は東京オフィスに数名集まっていても、全員が離れた場所から Zoom に繋ぐということをしています。 こうすることでビデオ会議で聞こえづらくなりがちな拠点内の会話がなくなって、全員が対等にミーティングに参加できていて良いです。

他、体験したゆめみの文化・制度

ウェルカムランチ制度

ざっくりいうと新入社員とランチ行く場合は会社から補助するよ、という制度。 いろんな人とランチ行けるので、入社時の繋がりブーストとして良いと思います。

プロポーザル・レビュー・リクエス

やりたいことをを明文化して誰かにレビューしてもらう制度。 全社員 CEO なので、やりたいことがあれば誰もが何でもやれる権限を持っているんですよね。 とはいえみんなそれなりに常識人なので、最初からぶっ壊れたプロポーザルが出てくることはないようです。

Bad News Fast

ゆめみには Bad News Fast という文化があり、「悪い情報」や「リスク」を最速で共有する Slack チャネルがあります。 これには、2 つの側面があると解釈しています。

  • 重大な問題を隠さずに報告できる雰囲気を作ろう
  • 全社をあげて一緒に問題を解決しよう ( 誰かを責めるものではない )

なかなか慣れない人も多いようですが、とても良い文化だと思います。

感想

  • 仕事がないとか、そんなこともあるんだ
    • 自社サービスをやっていた頃は無限に仕事があったので逆に新鮮
    • 勉強する時間がとれたのは良かった
  • 社内制度が素早いサイクルでアップデートされていくので、全部を追うのは大変
    • AWS みたい
    • 必要なものだけウォッチしよう
  • 制度の背景にある考え方を身につければ、すぐにキャッチアップできると思う
  • 有給取り放題やリモートワークで生活に融通がきくようになってよかった
  • ( オフィスのディスプレイがでかくて良いので ) 久しぶりに出社したいという気持ちになった
    • しかし、たまに冷房が効きすぎていて体調を壊す

次の目標

次は入社半年たったあたりで振り返ります。年末か年明けになると思います。

  • 会社批判
  • AWS 認定をもう 1 つとる
  • 通勤が楽なところに引っ越す
    • まだ、なんだかんだ物理オフィスへの出社が求められてる雰囲気がある
    • 今の通勤はさすがに時間がかかってしんどい
  • ゆめみの制度を使い倒す
  • 月 2 回程度のアウトプット

We are hiring!

株式会社ゆめみでは、成長意欲が高く、会社の制度やルールのあり方を再考して変えていきたいと考えていて、 入社して1ヶ月はタダ飯食いまくりたいし、有給もとりまくりたいと思っているメンバーを募集しています!

www.yumemi.co.jp

選考に入る前にざっくばらんな話ができるカジュアル面談もあるので、話を聞いてみたいという方は何らかの手段で僕に連絡をとるか、 以下の求人一覧ページの応募フォームからご連絡ください。

hrmos.co

awswakaran.tokyo #1 に行ってきました

www.awswakaran.tokyo

↑主催の開催後記です。 スライドへのリンクとかはこちらを参照ください。

感想

あるある要件を実現したい時のハマりがちポイントとその対策がわかった

「CloudFront にだけ IP 制限かけるだけで本当に大丈夫ですか?」 by @euxn23 さん 「Universal Application にありがちな LB ガチャ問題を解消する」 by @potato4d さん

  • どちらもフロントエンド向けのインフラ話でした
  • サーバーサイド勢からすると最初は「???」という感じ
  • 最後まで聞くと、ちょっとわかった気がした
  • 弊社はフロントエンドに最適化したインフラ構成を誰が考えているんだろう?

ようわからんけど入門するときのとっかかりが知れた

AWSが分からん人に送るFargateのススメ」 by @nametaketakewo さん 「CI/CDわからん」 by @y_ohgi さん

  • Fargete はちょうど使い始めたところだったので、色々学びがあった
    • 例えば Rails + Sidekiq worker とかはそれぞれ別サービスに分けちゃって良さそう
    • migration も別サービスに分けて完了したら即死させるとか
      • ここは単なるタスクの実行でもいい気はする
  • Ci/CD 話、 migration は 1 回 / 1 デプロイ!

当日限定の非公開コンテンツ

「そんなことあるんだAWS」 by オタクさん

  • 話聞いてるだけで面白かった
  • AWS の裏側がどういう挙動をしているのか探求する物語
  • そんなことあるんだ……
  • AWS ドキュメントの正式版は英語版、翻訳はあくまで参考なので違和感を感じたら原典にあたろう!

まとめ

  • ぜんぜんわかってない AWS が少しわかった
  • S3 難しい
  • そんなこともある
  • 英語のドキュメント読もう!

AWS 認定ソリューションアーキテクト – アソシエイトとして認定されました

aws.amazon.com

これをとりました。スコアは 909/1000 でした。 公開している認定情報はこちら

AWS 認定の種類やランクについては公式のドキュメントや、他の記事に譲ります。

AWS 認定 – AWS クラウドコンピューティング認定プログラム | AWS

バックグラウンド

AWS の知識や経験は初心者を脱しているかな〜というレベルです。

  • もともと SIer でオンプレミス中心のインフラエンジニアを 3 年半程度
  • AWS の実務経験は 1 年半程度
    • AWS 上にある自社開発の Web サービスのインフラ全般をメンテナンス
    • 新たに開発したアプリケーションやテスト環境の AWS 設計と構築

試験前の対策

試験前はがっつり勉強するというより、これまでの知識と経験、ちょくちょくインプットしてきたものを振り返るような形でした。

  1. サンプル問題 *1 の確認
  2. 模擬試験 ( ¥2,000 )
    • これで 9 割程度のスコアだったので新たに知識を詰め込まなくてもいけるだろうと判断
  3. Web 上にある問題集を眺める
    • ところどころ、内容が古かったり回答が間違っているものがあり
    • 未経験者・初学者はまず公式ドキュメントや書籍から学習する方がいいと思う
    • 経験者が振り返りに使う分にはコスパがいい

準備期間は 1 週間でした。

どうやって知識や経験を得るか?

これだけでは AWS 認定の取得を目指す人の参考にはならないので、個人的にどうアプローチすればいいと思うか書いておきます。 ほとんどが継続的に取り組むものなので時間はかかりますが、この方法で得た知識や経験は認定取得に関わらず確実に役に立つと思います。 試験内容も単なる暗記ものではなく、「ある前提条件においての最適解はどれ?」というような問いがほとんどのため、試験前に暗記して突破できる類のものではないです。

知識

  • 入門者向けの座学
    • 書籍で体系的な知識、 AWS で設計するときの考え方を学ぶ
    • 有料のトレーニングを受ける
  • 既に AWS 上で稼働しているシステムの AWS 環境を参照できるなら、どういう設計になっているか見てみる
    • 各種サービスの使い方や設定の意味を調べてみる
    • 基本は AWS のドキュメントを見て、それでもわからなかったらサードパーティの解説記事を見てみる
  • 新サービスの発表やアップデートをチェック
    • 全部に目を通す必要はなく、単に気になったものや既に使ったことあるもの、これから使う予定のあるものをピックアップしよう
    • 個人で AWS のアカウントを作ると毎週 AWS から最新のお知らせがメールで届くのでオススメ
      f:id:ikasamak503:20190721023954p:plain
      AWS からの最新のお知らせ
    • イベントレポートも手軽に最新情報をチェックできるので気になるものがあれば見てみよう
  • 先輩や同僚で詳しい人に相談や質問する
  • 勉強会に参加する
  • AWS がやたらと推してくるサービスやアーキテクチャを知る
    • DynamoDB とか DynamoDB とか

書籍は知識が体系的に、かつコンパクトにまとまっているので入門としては優れていると思います。 しかし AWS のサービスはアップデートが早く、特に紙媒体の情報は陳腐化しやすいです。 したがって、継続的なウォッチと知識のアップデートは必要です。

経験

  • 何はともあれ構築してみる!
    • 個人でも無料枠 *2 があるので、ちょっとしたサービスを動かすだけなら課金されない
    • 有料サービスも大抵が従量課金なので、数時間使ったくらいなら大した額にならない
    • まずは写経! チュートリアルはインターネットに溢れている
    • インフラをコード化とか高度なことはしなくていい、まずは Web の画面からポチポチしよう
  • チュートリアルができたら自分なりの工夫を入れてみる
    • 例えば
    • パブリックサブネットにあるデータベースをプライベートサブネットに置いてみる
    • メンテナンスしやすいセキュリティグループを考えてみる
    • シングルインスタンスを Auto Scaling させてみる
    • CloudFormation ( インフラのコード化 ) でやってみる
  • 他のチュートリアル悪魔合体してみる
  • トラブルシューティングする
    • 失敗からはたくさんのことを学べます
    • 本当はトラブルは無いに越したことないけどね
  • 勉強会等で登壇する
    • 得られた経験を整理するいい機会です
    • 僕はまだできてない

本試験の本人認証における注意点

TL;DR

  • 顔写真付きの証明書は運転免許証またはパスポートが無難
  • 日本のマイナンバーカードは政府発行の証明書として認識されないようなので避けたほうがいい

本人認証の書類として顔写真付きの証明書を持参し、テスト前に機械でスキャンする必要があります。 当日はマイナンバーカードを持参しましたが、何度スキャンしても NG 判定となって先に進めませんでした。 テスト用端末ではチャットでオペレーターとコミュニケーションを取ることができ、 端末操作に関する質問や、オペレーターからの指示がきます。 何度もマイナンバーカードをスキャンしていると、オペレーターからこんな質問がきました。

「それは政府機関発行の ID ですか?」

思わず「まじか・・・」と呟いていました。

ikasama「日本の自治体が発行する個人番号を確認するカードです」
オペレーター「確認します、少々お待ちください」

といってしばらく待たされました。 しばらく待っていると遠隔操作ソフト *3 のセッションが開始し、オペレーターが画面を操作し始めました。 試験アプリケーションを閉じて Windows のデスクトップが表示されて「おおっ」となったり、管理者ユーザーっぽいものに切り替えたり。 証明書スキャナーを起動するスタンドアロンのアプリケーションを起動して、 マイナンバーカードをスキャンするように指示 *4 されたり。 最終的には顔写真を撮る用の Web カメラにマイナンバーカードを近づけて認識 *5 してもらうということに。 なんとか確認は取れたことになって、試験アプリケーションの証明書スキャナーはスキップして進みました。 これだけで約 30 分くらい費やして変に疲れました。

次は

AWS 認定を取得すると模擬試験が無料になったり、本試験の受験料が半額になる特典があります。 せっかくなので Developer Assoiate か SysOps Associate を目指そうと思います。

まとめ

  • 知識は定期的にアップデートしていこう
  • AWS の推しを理解しよう
  • マイナンバーカードはオワコン

*1:ここからダウンロードできます https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/

*2:https://aws.amazon.com/jp/free/

*3:具体的な製品名の公表ここでは控えます

*4:この間、コミュニケーションの手段がないので Windows のメモ帳で筆談しました

*5: 見えづらいとか、 2cm くらいの距離に近づけて、とか色々めんどくさかった