gkzz.dev

"A Conversation with Werner Vogels - ACM Queue"を読んだ

1.この記事を書こうと思った背景チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計 (通称、ちいとぽ本）を読み進めていくうちに、以下の疑問を抱くようになった。 Amazon社のピザ２枚ルール、チーム間のコミュニケーションは、インターフェイスを通して行うことというルールは実際にどんなかんじにされているのか？気になる。 Teams must communicate with each other through these interfaces. 出所：AmazonのAPI設計方針 (The Bezos Mandate) - Qiita 明確な答えを導き出したわけではないけれども、考えを深めることができたターニングポイントとなったのが、タイトルで触れているインタビュー記事、A Conversation with Werner Vogels - ACM Queue を読んだことだった。また、先にお伝えしておくと新たな疑問も抱くようになったので、インタビュー記事を読んで学んだことと新たな疑問について書き留めておきたい。インタビュー記事を知ったきっかけ左記のインタビュー記事を知ったきっかけは、Team Topologies(by Manuel Pais)のキーポイントを読んだことである。この記事は書評記事ではないが、同書の趣旨を理解する上でも大きな助けとなった。“A Conversation with Werner Vogels"をご紹介いただき、ありがとうございました！ 2.“A Conversation with Werner Vogels - ACM Queue"を読んで学んだこと各サービスの構成メンバーは利用ユーザーの目的やニーズに応えることにフォーカスするべきだということ ↓の例だと、デベロッパーの関心事はアプリケーションを開発することであり、アプリケーションを開発するために内部的に生成されているURLがどうやって構成されるのか？には関心がないということ。責任共有モデルが各サービス間で徹底されているということ。 Do we see that customers who develop applications using AWS care about REST or SOAP? Absolutely not! A small group of REST evangelists continue to use the Amazon Web Services numbers to drive that distinction, but we find that developers really just want to build their applications using the easiest toolkit they can find. They are not interested in what goes on the wire or how request URLs get constructed; they just want to build their applications. ...

Hugo の Papermod テーマを使っているブログに favicon の設定をする

1.この記事を書こうと思った背景 favicon の設定方法はドキュメントにも記載があるけどそれだけでは足りず、手間取ってしまったのでここに備忘録として書き留めておく。 https://adityatelange.github.io/hugo-PaperMod/posts/papermod/papermod-faq/#adding-custom-favicons 2.やりかた config.yml に以下のとおり追加 params: assets: favicon: "<link / absolute url>" # e.g. "/favicon.ico" favicon16x16: "<link / absolute url>" # e.g. "/img/favicon-16x16.png" favicon32x32: "<link / absolute url>" # e.g. "/img/favicon-32x32.png" apple_touch_icon: "<link / absolute url>" # e.g. "/img/apple-touch-icon.png" ※ favicon のパスはプロジェクトのルートディレクトリに配置した ./static/ ディレクトリ内をルートとしたときの相対パスで指定 $ tree ./static/ ./static/ ├── favicon.ico └── img ├── apple-touch-icon.png ├── favicon-16x16.png └── favicon-32x32.png ./themes/PaperMod/layouts/partials/head.html をコピーし、./layouts/partials/head.html を追加 $ cp ./themes/PaperMod/layouts/partials/head.html ./layouts/partials/ $ find ./ -type f -regex ".*/partials/head.html" ./themes/PaperMod/layouts/partials/head.html ./layouts/partials/head.html layouts/_default/baseof.html に追加した ./layouts/partials/head.html を読み込むように修正 <head>  {{ if .Site.Params.Assets.Favicon }} {{ partial "head.html" . }} {{ end }} </head> 3.小話 favicon 自体は用意できるところがいろいろあるのでラクチンだった e.g. https://favicon.io/ Papermod の wiki に誤りがあったので報告している。（現在は修正済） https://github.com/adityatelange/hugo-PaperMod/issues/898

AWS Certified Solutions Architect Professional Exam(SAP-C01)の合格体験記(自宅受験/英語受験)

1.この記事を書こうと思った背景 AWS Certified Solutions Architect Professional Exam(SAP-C01 / AWS認定ソリューションアーキテクトプロフェッショナル, 以下SAP試験とする)を自宅で受験して合格した。スコアは773と、合格点が750なのでギリギリだった。なお、模擬試験の問題集の相性の兼ね合いやドキュメントの多さを考慮して英語で受験している。 2.受験しようと思った動機 SAP試験を受けようと思ったモチベーションは、AWS に関して体系的な知識を身につけ、いざググろうとなったときの助けとなるインデックスを脳内に貼っておきかったからだ。たとえば、弊社のAWS環境においてAWSリソースにアクセスする仕組みを理解するためには AssumeRole という AWS が提供する権限付与の IAM の機能に関する知識が求められる。ここで業務に取り掛かる際に AssumeRole がなんたるか？の一般的な知識がアタマに入っていれば、だいぶラクなんだろうな〜と歯がゆい思いをすることがあった。目的のAWSアカウントにはAssumeRoleを利用して切り替えます。認証用AWSアカウントに誰がどのアカウントに切り替えてよいかを定義しておき、それに基づいて切り替え可否を制御しています。出所：AWS + Azure ADによるSingle Sign-Onと複数AWSアカウント切り替えのしくみ作り - Cybozu Inside Out | サイボウズエンジニアのブログもちろん試験に合格してもすぐ役に立つということはないのだろうけど、受験がインプットしてのわかりやすいターニングポイントとなってくれたことは間違いないと感じる。 3.試験対策の検討方法について日本語受験の方は、「AWS SAP 合格」などでググるのがいいと思う。英語受験の方は、reddit で aws sap などでググるとアドバイスが見つかるのでおすすめ! https://www.reddit.com/search/?q=aws%20sap 4.試験当日までの勉強方法受験日の4ヶ月前に受験を決意してから3ヶ月くらい前まで試験ガイド(AWS Certified Solutions Architect - Professional Exam Guide)を一読 AWS Certified Solutions Architect - Professional Certification | AWS Certification | AWS 以下の参考書を1周 AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル : 山下光洋以下の Udemy の講座で配布されるPDF資料を一読しながら1問1答だけやる Ultimate AWS Certified Solutions Architect Professional 2022 | Udemy 以下の Udemy の模擬試験4回セットのうち1回を解き、難しさに絶望し、長期戦を覚悟する（1ヶ月もあれば終わるだろうと思っていたらとんでもなかった） AWS Certified Solutions Architect Professional Practice Exam | Udemy 3ヶ月くらい前から当日まで Redditで評判がよさそうだった、以下の模擬試験セットのうち、4回分と分野別の問題集をひととおりやる AWS Certified Solutions Architect Professional | whizlabs 模擬試験としては全5回だけど、準備期間が足りず4回しかできずただし、ふりかえると模擬試験を一周するより、既に解いた問題の解き直し、解説や自分でまとめたメモの見直しなど復習に時間をかけたのが今回の合格の決め手になった感じはする ↑の問題集を解いて復習していくのと併せて、Udemyの模擬試験2回分も解いていく Udemy の模擬試験は全4回だが準備期間が足りず、1回分解いていないが、こちらも復習を優先した。当日が近づくにつれ、これまで解いた模擬試験やAWSが提供するサンプル問題や模擬試験の問題と解説、自分でまとめたメモの読み直しの時間を増やした 1週間前に AWSからサンプル問題と模擬試験が無料で配布されていることに気が付き、急いでやる AWS Certified Solutions Architect - Professional Certification | AWS Certification | AWSでサンプル問題と模擬試験が配布されているサンプル問題：AWS Certified Solutions Architect - Professional Sample Questions 模擬試験：AWS Certified Solutions Architect - Professional Official Practice Question Set ※ 受験日を決めたのは1ヶ月前。模擬試験の演習の手応えを感じたためというより、これ以上後ろにずらすことができなかったため受験日を決めた。 ...

[参加レポート]DevOpsDays Tokyo 2022にリモート参加しました

1.はじめに 2022/04/21(木)と 22(金)に開催された、DevOpsDays Tokyo 2022 にリモート参加したので参加レポートを書いた。現地参加もできたのだけど開催場所から自宅までが結構遠いので Zoom + Discord で参加した。何分不自由なく参加できたけど、強いて言えば、今半弁当を食べることができなかったのは悔やまれますね笑 https://devopsdays.org/events/2022-tokyo 2.聞いたセッション Day1 (2022/04/21(木)) 10:30 (KEYNOTE) | 価値あるソフトウェアをすばやく届けるために僕らがやってきたこと〜経営者による組織とカルチャー作り〜 13:00 | ファクトから始めるカイゼンアプローチ～「Lean と DevOps の科学」を実践して～ 14:00 | 作る人から作りながら運用する人になっていく資料のリンク 15:00 | コンプライアンス対応をチームの力に ~ 監査人が考える今後の DevOps 16:00 | レガシーなシステムをリプレースした後に起きた開発組織の変化について資料のリンク 17:00 | CI/CD パイプラインに E2E テストを統合する資料のリンク Day2 (2022/04/22(金)) 11:00 (KEYNOTE) | Chris Lucian: Interview with Q&A 13:00 | Flaky test 対策の最新動向 14:00 | 食べログのソフトウェアテスト自動化デザインパターン資料のリンク 15:00 | デプロイ頻度を高めるために私達にできることは一体何があるだろうか？ 16:00 | PagerDuty でシステムノイズを削減し、インシデントの解決を自動化する方法 17:30 (KEYNOTE) | Matthew Skelton / Alex Papadimoulis - Matthew Skelton: Interview with Q&A 3.印象に残ったフレーズや一言感想 3-1.価値あるソフトウェアをすばやく届けるために僕らがやってきたこと〜経営者による組織とカルチャー作り〜印象に残ったフレーズ文化は北極星暗黙知から明文化目的のない雑談ジョイ・インク好きなことをとことんやる How to start a movement| TED 一言感想印象に残ったフレーズが多々あるけれど、感想として自分の考えも残すとしたら、「評価と査定の分離」の話ブログを書くことは評価にはつながらず、ブログを書くことで結果的に仕事もできるようになり、巡り巡って評価につながる。日の目を見ない期間が多い印象はたしかにある。ブログにかぎらず、日々の活動のモチベーションの厳選をおカネや評価にといった外発的なものではなく内発的にできるかどうか？が大事だと感じた。 3-2.ファクトから始めるカイゼンアプローチ～「Lean と DevOps の科学」を実践して～一言感想「software process improvement (SPI) / ソフトウェアプロセス改善」という言葉を初めて知った登壇者様曰く、ソフトウェア界の料理研究家といえるとか参考文献を挙げていただいた。注意点としてそのまま使うのではなく、自社の現状に合わせて手を加えていったとのこと。 Accelerate DevOps capabilities | Google Cloud 2021 Accelerate State of DevOps report addresses burnout, team performance The DevOps Handbook 調査結果をもとに不足している capabilities を見つけるうえで参考になった cf. 3 つの道、バリューストリーム 3-3.作る人から作りながら運用する人になっていく一言感想 How SRE Relates to DevOps テストピラミッドとコンシューマ駆動契約という考え方を知った改めてセッションをふりかえると、開発主体から開発も運用もというスタンスの移行の建前として、組織全体で知見を獲得したいといった「取り組みの成否にかぎらない」大義が用意されていると、比較的新しい取り組みの一歩を踏み出しやすいのかもしれないと感じた。また、実行部隊の規模が大きくなるとそういった大義を掲げることも難しいはずとも。 3-4.コンプライアンス対応をチームの力に ~ 監査人が考える今後の DevOps 一言感想監査チームのような、開発、運用業務をしているとあまり接点がすくなりがちな方々と日頃から意見を交わすことは大事。とはいえ、意見交換しようとなるのも難しく感じてしまう笑 ChatOps いいね！という監査の方から見た意見が印象的。「このチャンネルを見れば余計なことはしていないとわかるんです。」と言えるのが ChatOps のいいところとのこと。他に印象に残ったところは、デプロイメントパイプラインの権限整理とコンプラ対応を設計する上で競合他社を反面教師とするというところ 3-5.レガシーなシステムをリプレースした後に起きた開発組織の変化について印象に残ったフレーズお伺いマラソンこのセッションは、お伺いマラソンに形容される、相互依存でありモノリシックなレガシーアーキテクチャの移行前、移行前夜、移行後と時系列に分かれてお話されていて、とてもわかりやすかった。一言感想 Python2 系で作っていて、GCP が日本に展開する前からローンチしていたところからの移行。これだけでヤバそうということはわかる。ビザスクでは、2012 年創業以来、GCP(GAE) + Python2 の構成で、ナレッジプラットフォームという概念を広めるために様々な試行錯誤を繰り返しながら、サービスを拡大していきました。 ...

[Changes to S3 Bucket Drift Detection] Terraform AWS Provider 4.9の aws_s3_bucket リソースにおけるアップデート内容

1.この記事を書こうと思った背景これまで、Terraform AWS Provider のバージョンを3.7系から4.x系に引き上げようとすると以下のissueで取り上げられているような、 aws_s3_bucket resourceでエラーとなっていた。 S3 bucket issue: Can’t configure a value for “versioning” #23125 このエラーは、Terraformの以下のガイドに記載されているとおり、aws_s3_bucket resourceの大規模な仕様変更が入ったことに起因する。 Version 4.0.0 of the AWS Provider introduces significant changes to the aws_s3_bucket resource. See S3 Bucket Refactor for more details. 出所：Terraform AWS Provider Version 4 Upgrade Guide ところが、AWS Provider 4.9に引き上げるとエラー判定とされなくなっていた、、！？ v4.0のリリース内容もびっくりだが、これもびっくりなので筆を執ることにした。 AWS Provivder 4.9.0の CHANGELOG 2.AWS Provider 4.9に引き上げるとエラー判定ではなくWARNING判定となるこれまでの4.x系では aws_s3_bucket resource で3.7系までの書きっぷりをすると、エラーとしてきた一方、4.9系ではWARNINGは出れどresourceは作ってくれた。それと明示的に修正が必要な箇所を指摘してくれる！！ ※ WARNINGが出ていて大丈夫なんですか？という点については分かっていない。Terraform が指摘してくれた箇所の修正をしたほうがいいことは間違いないだろう。(今後のアップグレードによっては、またエラー扱いとなるというこもありうる) 修正方法はこれまでの4.x系への引き上げ時におこなわれている方法と同じであり、自分の場合の修正箇所を書いておく。 3.AWS Provider 4.9へバージョンを引き上げるまでのエラー対応(自分の場合) 冒頭で取り上げたエラーや4.9で確認された WARNING を回避するためには、左記の issue のコメントに記載されているとおり、aws_s3_bucket resource にすべて詰め込むのではなく、設定したい内容に応じて別に resource を定義する必要がある。 ...