https://gkzz.dev/ Recent content on gkzz.dev Hugo -- gohugo.io en Tue, 19 Nov 2024 21:58:48 +0900 https://gkzz.dev/posts/graduated-from-university-through-distance-learning/ Tue, 19 Nov 2024 21:58:48 +0900 https://gkzz.dev/posts/graduated-from-university-through-distance-learning/ これは 社会人学生 Advent Calendar 2024 3 日目の記事です。 足るを知り、足らざるを知りました。ありがとうございました。お花屋さんにご報告したところ、ぼくの好きなかすみ草の花束を作っていただきました。これからもできることを増やしてがんばります。よろしくお願いします！ pic.twitter.com/as9v7EsONQ — gkzz / Gakuji Tamaki (@gkzvoice) September 29, 2024 ぼくは 2021 年春へ帝京大学理工学部(通信教育課程)へ編入していたのですが、2024 年夏に卒業しました。 入学してよかったか 編入学当初は 腰を据えて勉強したい と意気揚々と二足の草鞋に励んでいましたが、とんでもなくたいへんでした、、。勉強すればするほどかえって自分の無知さを思い知る日々が続き、いつしか卒業することが目的となったというのはここだけの話です笑。 一方で 足るを知り、足らざるを知る という考えを持つことができたことはポジティブなことでした。結局は自分の現状を認めなくちゃしんどいなと。 これから 仕事はもちろんですが、これまで存分に楽しめなかった旅行や登山などなどやっていきたいです。編入学当初に思い描いていた景色とは違うものとはなりましたが、Connecting the dots という言葉のとおり、これまでのすべての選択が次の選択の糧となるようにがんばります。 網笠山の山頂からの一枚 :) 3-4 年目に取得した科目 最後に、後述するブログでは触れていない、3-4 年次に取得した科目を列挙します。なお、現在は履修できなかったり、履修方法が異なる科目があるかもしれません。ご注意ください。 Web アプリケーション オートマトンと計算理論 情報科学演習 3 情報科学演習 4 情報技術者演習 オペレーティングシステム コンピュータアーキテクチャ 画像情報処理 応用数学 情報システム 情報システムデザイン 情報社会論 情報理論 情報セキュリティ オペレーションズリサーチ ディジタル通信 英語コミュニケーション ディジタル信号処理１ 自動制御論 論理回路 以下は単位認定 コンピュータグラフィックス 電波法および電気通信法 通信方式 参考) 編入学当初や在学時代のふりかえり いろいろ悩んで帝京大学理工学部（通信教育課程）の社会人大学生になった 帝京大学理工学部（通信教育課程）の社会人大学生 1 年目をふりかえる ｜ gkzz. https://gkzz.dev/posts/specify-app-file-when-magicpod-batch-run/ Sun, 16 Apr 2023 22:55:43 +0900 https://gkzz.dev/posts/specify-app-file-when-magicpod-batch-run/ ※ 結論だけ知りたい方は、4.結論 をご覧ください 🙏 1.前提とこの記事で解決したい課題 1-1.前提 最近は MagicPod という E2E テスト自動化ツールを触ることが多い。 MagicPod では、複数のテストシナリオを実行（MagicPod ではこれを テスト一括実行/一括テスト実行 と称している。）することができる。また、テスト対象のアプリケーションのアーカイブ（App ファイル）には、MagicPod 上でユニークな連番である、app_file_number を割り当てられ、テスト一括実行 の際にはこの app_file_number を指定することで、任意の App ファイルを指定することもできる。 app_file_number のいちばんカンタンな取得方法は、App ファイルを MagicPod 側にアップロードする際のレスポンスから取得することである。 $ app_file_number=$(./magicpod-api-client upload-app -a <path to app/ipa/apk>) $ ./magicpod-api-client batch-run \ -t "${token}" -o "${organization}" -p "${project}" -S "${test_settings_number}" \ -s "{\"app_file_number\":\"${app_file_number}\"}" 参考: https://github.com/Magic-Pod/magicpod-api-client#upload-app-run-batch-test-for-the-app-wait-until-the-batch-run-is-finished-and-delete-the-app-if-the-test-passed 1-2.この記事で解決したい課題 しかし、App ファイルを MagicPod 上にアップロードするジョブとテスト一括実行のジョブが独立しているとしたらどうだろうか。App ファイルのアップロードのレスポンスから取得した app_file_number をテスト一括実行の引数として渡すことができない。そのため、指定したい App ファイルの app_file_number の取得方法を新たに用意しなければならない。 あるいは、App ファイルに test など任意の文字列が含まれさえしなければ、最新のもの指定したい場合もあるだろう。この場合はどうやって指定すればよいだろうか。 この記事では、そのような課題に対する解決策のひとつを書き留めたい。 https://gkzz.dev/posts/junior-voice/ Sun, 12 Mar 2023 23:10:41 +0900 https://gkzz.dev/posts/junior-voice/ 1.この記事で達成したいこと 以下 4 点の内容を書き留め、次年度の履修登録の参考にしたい 単位取得状況 授業を受講してから自分に起きた変化 今年度の履修戦略と次年度に向けて 授業のひとこと感想 2.前提 2021 年 4 月に大学 2 年生に編入学し、まもなく 2 年目を終えようとしている。 今年度も昨年度同様、コロナ情勢を踏まえて　リモート環境での受講 となっている。 次年度の募集要項によると、この体制が続く模様だが、前例のないことなのでいつまで続くのかは定かではない cf. 2023 年度 理工学部情報科学科 通信教育課程 募集要項 | 帝京大学 他は昨年度と同じなので割愛 cf. 帝京大学理工学部（通信教育課程）の社会人大学生 1 年目をふりかえる ｜ gkzz.dev 3.単位取得状況 サマリー 総取得単位数は80 内訳 今年度取得単位数は 18 (= 2 単位/授業 * 9 つの授業) 落とした単位 (落単) は 0 、見送り単位数は 8 (= 2 単位/授業 * 4 つの授業) 昨年度取得単位数は 30 編入時の認定単位数は 32 科目別(受講した時期) 単位取得確定 情報科学演習 1(1Q) 情報科学演習 2(2Q) 電磁気学 1(3Q) 電気回路 1(3Q) 電磁気学 2(4Q) 電気回路 2(4Q) 論理数学(秋期のスクーリング) 数理統計学(2Q は不合格、4Q で合格) 応用数学(4Q) 落単は無し(試験未受験) 見送り オペレーティングシステム(1Q or 3Q) コンピュータアーキテクチャ(1Q or 3Q) 情報技術者演習(2Q or 4Q) オートマトンと計算理論(2Q or 4Q) 4. https://gkzz.dev/posts/tokisaka-pass/ Sat, 18 Feb 2023 20:49:42 +0900 https://gkzz.dev/posts/tokisaka-pass/ 1.はじめに 2023 年 2 月中旬にロードバイクで時坂峠の一本松まで行ってきた。 実は、昨年夏にいちどチャレンジしているのだけれども、体力不足と道が分からず、一本松の少し手前の見晴らしのいい景色で引き返してしまい、一本松からの景色を拝むことができなかった。 先週後半に関東では大雪に見舞われたこともあり、路面凍結を心配していたが、スケジュールと天候どちらも恵まれたという絶好の機会がなく、今回意を決して再チャレンジすることにした。 2. どうだったか？ 無事、一本松を拝むことができた。 #時坂峠 リベンジ果たしました！#ロードバイク https://t.co/tlG3zb2gOq pic.twitter.com/IQbAs76nzr — gkzz / Gakuji Tamaki (@gkzvoice) February 18, 2023 道路のコンディションも時坂峠を迎えるまでは雪もなく、クルマや自転車もそんなに多くなく快適。時坂峠に入ってからは道路脇に雪が残っていたが、自転車やクルマが問題なく通れるぐらい溶けていた。 2-1. 天候もよかった 天候にはほんとうに恵まれ、自転車に乗っている間は街中では暑くて一番上に着ていた上着を脱ぐほど。林道に入ってからは上着を着るとちょうどよく、日差しが心地よかった。 雨は終日見舞われることがなかった。(当日の檜原村の天気予報は晴れ、最高気温 12°、最低気温-1° だった記憶。) Instagram や Twitter などでここ最近の「時坂峠」のキーワードを含む投稿の写真では、雪が残っている様子が見受けられた。それだけに今回無事に帰路に就くことができ、かつ一本松からの景色も堪能出来て最高だった。 2-2. 感想 景色を言い表そうと思えば「一本松の凛とした立ち振る舞い」、「木々が青々と茂っている」など思いつくが、陳腐に感じてしまう。言葉では形容しがたいものがあった。写真はたくさん撮ったが、それ以上にそのパノラマを目に焼きつけようと長居してしまった。山登りの際には初回に続き、今回も足をつってしまったが、ストレッチしながら粘って一本松を目指した。一本松の姿とそこに広がるパノラマを目にしたら、全身の疲労は吹き飛んだ。ほんとうに来てよかった。いいところだった。 そういうわけなので、今回の道順をかんたんに残しておき、再訪する際の助けとしたい。 3.大まかな道順を写真とともに 目標地点を時坂峠の一本松とし、以下のルートで向かった。 3-1. スタート地点（自宅）(朝早め) 3-2. 五日市駅を正面に左折 3-3. たちばなやさんの駐車場を正面に右折 ここから少し登り気味 少し進むと整備された林道に入っていく 3-4. ちとせ屋さん正面左手の登り道から時坂峠へ入る 3-5. 林道の様子 いくつか、工事中のところがあるも、問題なく通行できた 3-6. 見晴らしのいい景色 前回はこの近辺で体力と道順が分からなくなり撤退 これまで通ってきたところも写真には映っていないだけで雪が残っていたが、このあたりは特に雪が残っていた 景色がよすぎるので前のめりになって転落しないように要注意 3-7. 道なりに進むとしばらく林道が続く 整備されていないところもあり注意 3-8. 個人的にハマりポイントだった T 字路 一本松を目指すのであれば、左手の浅間嶺・上川バス停 が正解 ※ 「時坂峠」と右手に書いてあるものだから右手に進もうとすると、通行止めとなっているがここで引き返してはいけない！ 3-9. 左手(写真では直進)に進むとこんなかんじ 3-10. https://gkzz.dev/posts/renovate-regex-manager/ Tue, 02 Aug 2022 11:29:07 +0900 https://gkzz.dev/posts/renovate-regex-manager/ 1. この記事を書こうと思った背景 パッケージのバージョン管理をするとなったときに真っ先に思い浮かぶツールは Renovate だが、なんと .tool-versions のマネージャーが提供されていなかった。 Managers - Renovate Docs で挙げられている dockerfile などはマネージャーが提供されており、たとえば、Dockerfile の場合、デフォルトで以下の書式の Dockerfile に書かれたコンテナイメージのバージョン管理が major を除いてできる。1 (^|/|.)Dockerfile$ (^|/)Dockerfile[^/]*$ さて、マネージャーが提供されていない .tool-versions に書かれた言語やツールのバージョン管理をどうすればよいだろうか？ 結論から言うと、Regex Manager で .tool-versions から更新管理したいものを指定（キャプチャ）すればよかった。 この記事では、具体的にどうやったか？その設定をするためにどう調べたか？書いていきたい。 2. 前提 2-1. 2022/08/01 時点でのワークアラウンドな方法であること 以下の issue で議論されているように、以前から .tool-versions をサポートしてほしいという声はあがっている。そのため、この記事で書かれていることは、あくまでも 2022/08/01 時点でのワークアラウンドな方法であることとしたい。 Upgrade versions in .tool-versions #4051 2-2. .tool-versions で管理しているもの .tool-versions で管理しているものは、Terraform と Node.js $ cat .tool-versions terraform 1.0.0 nodejs 16.15.0 3. 環境情報 Renovate の実行環境は GitHub App 4. renovate.json5 の設定内容抜粋 regexManagers で . https://gkzz.dev/posts/mathematical-essay-writing-fundamentals/ Mon, 20 Jun 2022 13:10:12 +0900 https://gkzz.dev/posts/mathematical-essay-writing-fundamentals/ 1.この記事を書こうと思った背景 ぼくはリモートワークで仕事をすることがほとんどだ。リモートワーク下において仕事でのコミュニケーションの大半は テキストベース だが、文章で自分の考えを伝える ことのむずかしさを感じることが多々あった。そうした背景がありつつ、以前読んで読みやすいと感じた『プログラマの数学第2版』や数学ガールシリーズの著者が 『数学文章作法 基礎編 （ちくま学芸文庫）』(以下、本書)を出版しているということで手に取った。本書から学んだことを、ここに書き留めておく。 2.目次 第1章　読者 第2章　基本 第3章　順序と階層 第4章　数式と命題 第5章　例 第6章　問いと答え 第7章　目次と索引 第8章　たったひとつの伝えたいこと 3.本書を通しての学び よい文章を書くことはむずかしいと改めて感じる一方で、じゃあ、どうすればいいか？そのヒントを得ることが出来た。そのヒントを章ごとに挙げていく。 「第1章　読者」より 読みやすい文章を書く 著者は読みやすい文章を書く原則とは、読者のことを考える ことだという たしかに文章を読もうと手にとってもらわなければどんなにいい文章でも意味がない では、読者のことを考える とは何について考えればよいのか？というと、著者は以下の3点を挙げている 読者の知識 読者の意欲 読者の目的 書こうとしている文章は読者の知識レベルに配慮して書かれているか。文章を読み進めようという意欲を掻き立てるものか。読むことで自分の目的は満たされると思ってもらえるか。どれも抜け落ちていた視点だったので、本書を読み進めようという強いモチベーションに駆られた。（しばらく読み進めて、なるほど。これが読みやすい文章かとなった。） また、本書では述べられていなかったが、会社やコミュニティなど書き手と読み手が共通のコンテキストを有する場合には、過去に積み上げられてきたドキュメントから文章の書き方や、そこで使われているローカルルールを押さえておくと、読者にとって読みやすい文章を書く助けとなるだろうとも感じた。 「第2章　基本」より 文は短く これは、何を主張している文か と自問自答 逆説ではない「が」を使い、冗長的になっていないか？ 「ちなみに」と、本筋からはずれているとはいえ、理解の助けとなる話題を提示しているか？ 「第3章　順序と階層」より 書き直しの重要性 書き直しをすることを想定して書き始めるべき 接続詞は使わず、箇条書きで書くことはせずとも、キーフレーズを書き並べるところから始めるだけでもいいかもしれない 「第4章　数式と命題」より あいまいさをなくす ひとつの文章ではひとつのことを伝える 「第5章　例」より 例のファーストチョイスは、典型的なもの その次に極端な例や、あてはまらない例、一般的な例などが続く 例を挙げる際にも、読者の知識レベルやバッググラウンドに配慮すること OSS やクラウドベンダーのドキュメントでよく出てくる Getting Started は典型的な例にあてはまるのだろう。 4.なぜ、よい文章を書くことはむずかしいのか よい文章を書くことはどうしてむずかしいのか。本書を読みながらこの理由について考えていた。 ひとつ挙げるとすれば、やはり書き手と読み手の知識レベルやバッググラウンドにギャップがあることではないだろうか。 だからこそ、読者のことを考える 、つまり、読み手の知識、意欲、目的に関心を持つこと がよい文章を書くうえで、もっともだいじなのではないか。よい文章を書くということは一朝一夕にできるものではないけれどコツコツと続けてモノにしたい。 https://gkzz.dev/posts/terraform-heredoc-style/ Tue, 14 Jun 2022 17:39:30 +0900 https://gkzz.dev/posts/terraform-heredoc-style/ 1.この記事を書こうと思った背景 Terraform の description に複数行書きたいとなったので調べた。また、p.s. に description について分からなかったことも書き留めておく。 2.やりかた Heredoc Strings | Strings and Templates - Configuration Language | Terraform by HashiCorp を読むと、ヒアドキュメント を使うとよさそうだ。 variable の description に使ってみる。 variable "instance_types" { description = <<-EOT 検証用なのでできるだけお金をかけないようにしている。 大きいサイズは、t3.xlarge などがある。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#AvailableInstanceTypes EOT default = ["t2.small", "t3.small", "t2.medium"] #default = ["t3.xlarge", "t3.2xlarge"] } 3.小ネタ)EOT としているワケ Terraform のドキュメントのサンプルコードにおいて、EOT としているのは、end of text の意味を込めているからだという。 In the above example, EOT is the identifier selected. Any identifier is allowed, but conventionally this identifier is in all-uppercase and begins with EO, meaning “end of”. https://gkzz.dev/posts/mathematics-for-programmers/ Sun, 12 Jun 2022 11:48:53 +0900 https://gkzz.dev/posts/mathematics-for-programmers/ 1.この記事を書こうと思った背景 『プログラマの数学 第2版｜結城浩』(以下、本書)を読んだ。本書から学んだことを、ここに書き留めておく。 2.目次 はじめに 第1章 ゼロの物語 ―― 「ない」ものが「ある」ことの意味 第2章 論理 ―― trueとfalseの2分割 第3章 剰余 ―― 周期性とグループ分け 第4章 数学的帰納法 ―― 無数のドミノを倒すには 第5章 順列・組み合わせ ―― 数えないための法則 第6章 再帰 ―― 自分で自分を定義する 第7章 指数的な爆発 ―― 困難な問題との戦い 第8章 計算不可能な問題 ―― 数えられない数、プログラムできないプログラム 第9章 プログラマの数学とは ―― まとめにかえて 付録1：機械学習への第一歩 付録2：読書案内 3.本書全体を通しての学びや感想 ものごとの構造を見抜き、一般化する 本書は 「ものごとの構造を見抜き、一般化する」 ことについて、その大切さと方法論について事例を交えて紹介されている。 そのアプローチの一例としては、たとえばものごとを小さくみること、あるいは2分割や再帰性を見出すことなど。 読みやすい印象を抱いたこととそのワケを考える また、とても読みやすい印象を持った。 なぜ、このような印象を抱いたのか？ それは、独自の見解を提示する前に既知の話題や身近な関連事例を提示しているからではないか？と思う。本書は、話し手がもっとも言いたい独自の主張を読み手に伝えるためのエッセンス集であるともいえるかもしれない。 さて、章ごとの読書メモを書いていたのでそちらも共有しよう。(ただし、7章以降を除く。) 4.章ごとの読書メモ 「第1章 ゼロの物語 ―― 「ない」ものが「ある」ことの意味」 「ない」ことを表現する難しさと大切さ。 e.g. 位取り cf. 意外と知らない「ゼロ」の持つ意味と概念―あなたも「ゼロ」という数字から、知的探求、始めてみませんか？－　|ニッセイ基礎研究所 「第2章 論理 ―― trueとfalseの2分割」 物事の論理は、章の副題にも挙げられている 2分割 を意識すること。また、複雑な表現は論理式の考え方を使うとシンプルになることがあるということ。 https://gkzz.dev/posts/renovate-getting-started/ Wed, 08 Jun 2022 16:35:41 +0900 https://gkzz.dev/posts/renovate-getting-started/ 1.この記事を書こうと思った背景 今更感満載だけれど、パッケージの依存関係の更新ツールである Renovate について理解が浅いと感じることがあった。とりわけ、Presets や Config の書き方については見様見真似でやってしまっている感が否めなかった。 そこで、表題のとおり、Renovate を個人リポジトリで小さく始めながら 、Renovate を触っていく上で押さえておきたい点について、この記事に書き留めていきたい。 2.前提と環境情報 Renovate の platform は https://github.com とし、GitHub App で運用する。Renovate の導入手順は Installing & Onboarding - Renovate Docs を参考にした。 また、Renovate で指定する更新方法のことを Config と書いておく。というのも 設定 と日本語で書いてしまうと一般的な「設定」と、Config のうち、どちらを指して書いているのか、区別することが難しいためである。 3.スタート地点としての [“config:base”] Renovate の Config は 設定ファイルに書いていくのだが、公開されている Presets(Config Presets) を使うこともできる。 たとえば、Shareable Config Presets - Renovate Docs | Renovate Docs で紹介されている、extends: [“config:base”] を指定するだけでも Renovate を使うことができる。 $ cat renovate.json5 { extends: ["config:base"], timezone: "Asia/Tokyo" } ※ renovate.json5 はコメントが書ける renovate. https://gkzz.dev/posts/alternative-terraform-graph/ Wed, 01 Jun 2022 21:29:41 +0900 https://gkzz.dev/posts/alternative-terraform-graph/ 0.この記事の結論 pcasteran/terraform-graph-beautifier: Terraform graph beautifier が個人的にはおすすめ！やはり、Terraform にビルトインされた terraform graph を input 値としているせいか、安定している印象を受けた。 im2nguyen/rover: Interactive Terraform visualization. State and configuration explorer. もとくにビジュアル面でよかった。ただし、Docker で扱う場合、Docker ホスト側の Terraform のバージョンによってはうまく動かないことがあったので、2番目におすすめとしたい。 1.この記事を書こうと思った背景 terraform graph という Terraform のリソース可視化ツールがある。これは Terraform にビルトインされたコマンドのひとつであり、Terraform で表現するインフラリソースの可視化ツールのひとつである。 詳細な使い方は以下の Terraform のドキュメントを参照してほしい。 Command: graph | Terraform by HashiCorp そんな terraform graph だが、リソースが多いと見にくいという欠点がある。そこで、表題のとおり、terraform graph よりビジュアライズな Terraform のインフラリソース可視化ツールを探すことにした。 1-1.可視化する Terarform のサンプルコード 今回、可視化する Terarform のサンプルコードは、以下の「7.サンプルコード」で書いているものとする。 7.サンプルコード | 複数の AWS Lambda のエラーを CloudWatch Alarms で検知できるように Terraform で定義する | gkzz.dev https://gkzz.dev/posts/metric-alarms-by-multiple-dimensions/ Mon, 30 May 2022 06:41:56 +0900 https://gkzz.dev/posts/metric-alarms-by-multiple-dimensions/ 1.この記事を書こうと思った背景 複数の AWS Lambda に CloudWatch Alarms で監視しよう！ということがあったので、 Terraform で以下のように dimensions で監視したい Lambda を列挙するだけだろ！と思いきや、ダメだった。 apply すると、最後に書いた FunctionName のみがCloudWatch Alarms に適用されてしまった。(以下の場合、my_lambda_function2 ) resource "aws_cloudwatch_metric_alarm" "this" { metric_name = "Errors" namespace = "AWS/Lambda" dimensions = { "FunctionName" = "my_lambda_function1", "FunctionName" = "my_lambda_function2" } #略 } ※ FunctionName に * をつけても「*_lambda_function」などとベタ書きとして認識されてしまってダメ。正規表現っぽく指定することは出来なかった。 dimensions = { "FunctionName" = "*_lambda_function", } さて、じゃあどうしようか？と調べたことを書き留めておく。 なお、上記の dimensions は以下を参考に指定した。 Choose a dimension. By Function Name (FunctionName) – View aggregate metrics for all versions and aliases of a function. https://gkzz.dev/posts/github-actions-tips/ Tue, 24 May 2022 18:58:37 +0900 https://gkzz.dev/posts/github-actions-tips/ 1.この記事の立ち位置 自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ 2-1.Step と Job と Workflow の違いの一行まとめ Step < Job < Workflow 2-2.Step と Job と Workflow の違いの三行まとめ Step はGitHub Actions Workflow の最小単位であり、run や uses で指定するもの Job はコンテナや VM のことを指し、runs-on で指定するものであり、ひとつないしは複数の Step を抱えている Workflow はひとつ以上の Job を束ねている これらについて端的にまとめた図が公式ドキュメントで掲載されているのでそちらもぜひ。 Understanding GitHub Actions - GitHub Docs 2-3.Step と Job と Workflow それぞれの分け方・分割の基準 Step を分けるときは、run 、 uses 、 name が異なるとき 以下のように書けば、ひとつの Step に複数のコマンドを始めとする処理を書くことができる - name: Install Dependencies run: | npm ci npm run build - name: Run test run: npm run test Job を分けるときは runs-on が異なるときや、needs で Job 単位で実行制御をしたいとき cf. https://gkzz.dev/posts/helmwave-getting-started/ Fri, 13 May 2022 23:23:40 +0900 https://gkzz.dev/posts/helmwave-getting-started/ 1.この記事を書こうと思った背景 Helmwave なるものを Twitter で見かけた。 Helmwave is a release manager for #Kubernetes, akin to Helmfile and Helmsman: https://t.co/hxa5sYmHgp — Kubernetes Tools & Utils (@kubectrl) May 4, 2022 Helmwave の README.md にはこのように書かれている。 Helmwave is helm3-native tool for deploy your Helm Charts. HelmWave is like docker-compose for helm. Helmwaveは、Helmチャートを展開するためのhelm3ネイティブツールです。 HelmWaveはdocker-composeのようなものですhelm用に作成します。 出所：helmwave/helmwave: 🌊 Helmwave is true release manager (邦訳はGoogle翻訳より) よさそうなので、公式ドキュメントの Getting Started などを参考に Helmwave に入門する。 2.前提 2-1.ところで、Helm とは？ ぼくは、Helm 及び Helm Charts の理解も浅いのでこの場で深めておく。まず、Helm については公式ドキュメント にこのように書かれている。 https://gkzz.dev/posts/force-delete-a-kubernetes-namespace/ Sat, 07 May 2022 02:22:40 +0900 https://gkzz.dev/posts/force-delete-a-kubernetes-namespace/ 1.この記事を書こうと思った背景 Amazon EKS 上で作成した Namespace を kubetcl delete namespace <namespace> と削除しようとしても削除できないことがあった。(ここで削除したい Namespace は argocd) $ kubectl get ns argocd NAME STATUS AGE argocd Terminating 50m $ kubectl get namespace argocd -o json { "apiVersion": "v1", "kind": "Namespace", "metadata": { "creationTimestamp": "2022-05-06T15:36:43Z", "deletionTimestamp": "2022-05-06T16:15:02Z", "labels": { "kubernetes.io/metadata.name": "argocd" }, "name": "argocd", "resourceVersion": "16545", "uid": "7e29177f-2c2c-4583-b027-49946160bf2b" }, "spec": { "finalizers": [ "kubernetes" ] }, "status": { "conditions": [ { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All resources successfully discovered", "reason": "ResourcesDiscovered", "status": "False", "type": "NamespaceDeletionDiscoveryFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All legacy kube types successfully parsed", "reason": "ParsedGroupVersions", "status": "False", "type": "NamespaceDeletionGroupVersionParsingFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "All content successfully deleted, may be waiting on finalization", "reason": "ContentDeleted", "status": "False", "type": "NamespaceDeletionContentFailure" }, { "lastTransitionTime": "2022-05-06T16:15:09Z", "message": "Some resources are remaining: applications. https://gkzz.dev/posts/learn-from-amazon-technology-platform/ Fri, 29 Apr 2022 18:48:19 +0900 https://gkzz.dev/posts/learn-from-amazon-technology-platform/ 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. https://gkzz.dev/posts/add-favicon-with-hugo-papermod/ Fri, 29 Apr 2022 17:53:17 +0900 https://gkzz.dev/posts/add-favicon-with-hugo-papermod/ 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 ". https://gkzz.dev/posts/pass-aws-certified-solutions-architect-professional-exam/ Tue, 26 Apr 2022 12:19:43 +0900 https://gkzz.dev/posts/pass-aws-certified-solutions-architect-professional-exam/ 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ヶ月前。模擬試験の演習の手応えを感じたためというより、これ以上後ろにずらすことができなかったため受験日を決めた。 https://gkzz.dev/posts/devopsdaystokyo-2022/ Fri, 22 Apr 2022 14:15:25 +0900 https://gkzz.dev/posts/devopsdaystokyo-2022/ 1.はじめに 2022/04/21(木)と22(金)に開催された、DevOpsDays Tokyo 2022にリモート参加したので参加レポートを書いた。現地参加もできたのだけど開催場所から自宅までが結構遠いのでZoom + Discord で参加した。何分不自由なく参加できたけど、強いて言えば、今半弁当を食べることができなかったのは悔やまれますね笑 https://devopsdays.org/events/2022-tokyo メールにセッション視聴URLが送られてきていたのでそちらから視聴中#DevOpsDaysTokyo — gkzz / Gakuji Tamaki (@gkzvoice) April 21, 2022 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. https://gkzz.dev/posts/changes-to-s3-bucket-drift-detection-with-aws-provider-v4/ Sat, 09 Apr 2022 14:32:30 +0900 https://gkzz.dev/posts/changes-to-s3-bucket-drift-detection-with-aws-provider-v4/ 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. https://gkzz.dev/posts/secretlint-via-docker-on-github-actions/ Thu, 24 Mar 2022 23:04:29 +0900 https://gkzz.dev/posts/secretlint-via-docker-on-github-actions/ 1.この記事を書こうと思った背景 昨今のニュースを眺めていると、クレデンシャル情報(シークレット情報/機密情報)漏洩対策の一環として、ガードレール的なツールを使いたい、またそういったツールを継続的に利用したいというお気持ちが一層強くなる。 そういうわけで Secretlint をはじめとするガードレール的なツールを使おうと思うのだが、SecretlintをCIパイプラインでお手軽に使う方法をひらめいたのでここに書き残しておく。なお、今回の導入対象のCIパイプラインは、GitHub Actionsとしている。というのも https://github.com/secretlint にSecretlintをNode.jsのライブラリとしてGitHub Actions上で扱うサンプルコードが公開されていることから検証のハードルが低いと感じたためである。 secretlint/secretlint-github-actions-example さて、この記事では、SecretlintをCIパイプラインでお手軽に使う方法の他に、誤検知対策としてカンタンにルールを追加する方法についても触れたい。この手のツールは誤検知が大量に作動してしまえば、そのツールはオオカミ少年と認識されてしまいかねない。それだけにSecretlintでは簡易的とはいえ誤検知対策ができるという点は、かゆいところに手が届いているといえるのではないだろうか。 2.解決したい課題とその解決策 まず、具体的な方法論について話す前に前提となる解決したい課題と、ここで提案する解決策について述べておきたい。 2-1.解決したい課題 SecretlintをGitHub Actionsのワークフローでお手軽に使いたい Secretlintを使うためにはDockerかNode.jsが必要である戦う つまり、GitHub ActionsのワークフローのなかでDockerかNode.jsのいずれかを使えるようにセットアップするJobが必要 Node.jsでSecretlintを使う場合、Secretlintのインストールが必要とやや手間 $ npm install secretlint @secretlint/secretlint-rule-preset-recommend --save-dev ルールの追加もお手軽にしたい Secretlintではビルトインのルールが提供されていないが、専用の設定ファイルの .secretlintrc.{yml,yaml,js} (以下、.secretlintrc.json) でルールを利用者側で導入する必要がある Dockerコンテナイメージの場合、推奨ルールセットである、@secretlint/-rule-preset-recommend が同梱されており、イメージをbuildするだけでok https://github.com/secretlint/secretlint#using-docker @secretlint/-rule-preset-recommend Node.jsの場合、上述した @secretlint/-rule-preset-recommend などを.secretlintrc.json で指定し、secretlintコマンドを実行するディレクトリに配置しておかなければならない https://github.com/secretlint/secretlint#using-nodejs # Dockerコンテナイメージを使う場合、Secretlintのインストールは不要 # `.secretlintrc.json　もイメージに同梱されている # ルールを追加したい場合、自分で用意する必要があり、その方法は後述 $ docker run -v `pwd`:`pwd` -w `pwd` --rm -it secretlint/secretlint secretlint "**/*" # Node.jsの場合、以下のコマンドで .secretlintrc.json を生成する必要がある $ npx secretlint --init # .secretlintrc.json はsecretlintコマンドを実行するディレクトリに配置する必要がある $ cat <<EOF > . https://gkzz.dev/posts/github-actions-schedule-cron-expression/ Fri, 11 Mar 2022 15:08:54 +0900 https://gkzz.dev/posts/github-actions-schedule-cron-expression/ 1.この記事を書こうと思った背景 Github Actionsでは、schedule ( schedule イベントやスケジュール実行ともいうがここでは、 schedule とする。)というイベントが用意されている https://docs.github.com/ja/actions/using-workflows/events-that-trigger-workflows#schedule 他のイベントとしては、push や workflow_dispatch などがある scheduleは、POSIX 規格の crontab の構文 で表記するのだが、日時の条件指定と曜日の指定はAND判定されるかと思いきや、OR判定されるようだと分かり、Github feedback や Support などで問い合わせた 問い合わせた結果、丁寧に教えていただいたので共有したい [bug] Schedule event’s multiple conditions are judged by OR conditions, not AND conditions #12804 日時の条件指定と曜日の指定のAND判定というのは、たとえば、第1月曜日の午前2:00に schedule を実行したい場合、下記のような書き方を指している(ただし、この書き方ではAND判定とならないので要注意！) on: schedule: - cron: '0 17 1-7 * 1' 2.長いので結論を書く Github Actions の cron で採用されている POSIX 規格の crontab の構文 では日時と曜日が指定されている場合、日時と曜日のOR判定となることが正しい if either the month or day of month is specified as an element or list, and the day of week is also specified as an element or list, then any day matching either the month and day of month, or the day of week, shall be matched. https://gkzz.dev/posts/github-parameter-to-disable-markdown-rendering/ Wed, 02 Mar 2022 18:23:58 +0900 https://gkzz.dev/posts/github-parameter-to-disable-markdown-rendering/ 1.markdown/マークダウンファイルをそのまま平文で表示するデモ 百聞は一見に如かず。ということでその様子をGIFで用意した。 2.どんなときに役に立つのか？ markdownファイルをそのまま表示したいときってどんなときか？ たとえば、こんなときに使えるのではないだろうか。 ソースコードのある箇所を行単位でハイライトをつけるようにmarkdownファイルでも強調したい。 書きっぷりをmarkdown形式で確認したい e.g.いいかんじのMermaid記法を見つけたけどこれどうやって書いてんだ！？ 3.どうやるのか？ Github上でmarkdownファイルを開いてからURLの末尾に以下を追加するだけ！ ?plain=1 すると、冒頭のGIF動画のようにmarkdownのまま表示される。 やってみよう！ 対象のmarkdownファイルのURL https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md markdownファイルのURLの末尾に "?plain=1" をつけると、、できた！！ https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md?plain=1 一般的なファイルのように行単位でハイライトをつけることもできるぞ！ https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md?plain=1#L5:L11 4.おまけ 記事を公開してまもなく、今回ご紹介したマークダウンファイルをマークダウン形式のまま表示する方法ですが、rawとも違うのねとコメントいただきました。 なるほど、raw ともまた違うのですね https://t.co/EZaXLIjiLm — よこち (@akira6592) March 3, 2022 たしかにちがうぞ！！（言われて気がついた。rawの場合、プレーンテキストとして出力しているかんじ。） 2022/03/07更新 GithubのGUIからでもできるよ！と教えていただいた。丸で囲んだボタンを押すと、この記事で紹介している ?plain=1 と同じようにマークダウンをマークダウンのまま表示できる。 5.参考 Parameter to disable markdown rendering | GitHub Changelog https://gkzz.dev/posts/receive-aws-budget-alerts-in-serverless-framework-slack/ Thu, 24 Feb 2022 22:08:59 +0900 https://gkzz.dev/posts/receive-aws-budget-alerts-in-serverless-framework-slack/ 1.この記事を書こうと思った背景 AWSの利用料金が想定以上に高くてびっくりしたことがあった AWSの利用料金が想定より高くなったら検知するようにしようと決意したい ↓こういったことが起きないためにも、、 AWSでやらかして3桁万円請求された話 - Qiita 無事できたので、この記事でどうやったか？またいくつか検知する方法があるなかでどういった選定基準を持ったか？書いていきたい ※ サンプルコードはこちら https://github.com/gkzz/serverless-aws-budget-alerts-to-slack 2.前提 AWSの利用料金が想定より高くなったら検知する方法は2022/02/24時点で3種類あり、この記事ではbudget alertsを使った方法を採用している。ただし、各サービスの仕様変更やアップデートなどにより今後は他2つの方法を採用した方がいいということも。 3.環境情報 Serverless Frameworkのバージョンは3.2 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ sls --version Framework Core: 3.2.0 Plugin: 6.0.0 SDK: 4.3.1 $ npm --version 6.14.16 $ nodejs --version v10.19.0 Serverless Frameworkでは環境変数としてAWSのRegionとSlackのincoming webhook urlを使っている 環境変数の使い方や適用方法については以前書いたのでそちらを参照してほしい Serverless Framework 3.xでserverless-dotenv-pluginを使った環境変数の読み込みができなかったのでserverless.ymlを修正した | gkzz.dev　# .env # .envはserverless.ymlと同じディレクトリに配置 # AWS REGION="***" # slack incoming webhook SLACK_WEBHOOK_URL="https://hooks.slack.com/services/***" serverless.ymlを配置したディレクトリをルートディレクトリとみたときのディレクトリ構造 serverless.ymlにLambdaの実行ファイルのパスなどを書くので、treeコマンドの結果を貼っておく treeコマンドの結果からnode_modulesディレクトリは見やすさを考慮して除外した $ tree -L 3 -I node_modules . https://gkzz.dev/posts/serverless-dotenv-plugin-not-working-on-serverless-framework-version-3/ Mon, 14 Feb 2022 17:28:03 +0900 https://gkzz.dev/posts/serverless-dotenv-plugin-not-working-on-serverless-framework-version-3/ 1.この記事を書こうと思った背景と書いていきたいこと 1-1.背景 先日、Serverless Frameworkがv3にメジャーアップデートされたことは記憶に新しい Serverless Framework V3 Is Live! そんなServerless Frameworkを2系から3系に引き上げてserverless-dotenv-pluginを使って環境変数が読み込もうとしたところ、以下のようなエラーを引いてしまった $ sls deploy Environment: linux, node 14.19.0, framework 3.2.0, plugin 6.0.0, SDK 4.3.1 Docs: docs.serverless.com Support: forum.serverless.com Bugs: github.com/serverless/serverless/issues Error: Cannot resolve serverless.yml: Variables resolution errored with: - Cannot resolve variable at "custom.REGION": Value not found at "env" source, - Cannot resolve variable at "custom.FAVORITE": Value not found at "env" source このエラーはserverless.ymlと同じ階層のdotenvファイルに書かれた環境が読み込めないというもの 書き方はのドキュメントに詳しく書かれているのでそちらを参照してほしい。ただし、2系で使える書き方であり、3系に対応した書き方はこれから紹介する書き方を採用する必要がある。 Serverless Framework: Plugins エラーを引いたときに使ったserverless.yml frameworkVersionを2から3に修正しただけ service: src frameworkVersion: '3' #frameworkVersion: '2' custom: dotenv: basePath: . https://gkzz.dev/posts/repository-dispatch-vs-workflow-dispatch-in-github-actions/ Mon, 31 Jan 2022 17:59:18 +0900 https://gkzz.dev/posts/repository-dispatch-vs-workflow-dispatch-in-github-actions/ 1.この記事で達成したいこと repository_dispatchとworkflow_dispatch の使い分けや書き方の違い、共通点や相違点を整理したい 結局どっちを使うのがいいのか？判断基準を見つけたい そもそもrepository_dispatchとworkflow_dispatchはどういうときに使うのか？ アプリケーションリポジトリでイメージをレジストリにpushした後、マニフェストリポジトリでそのイメージタグをマニフェストに反映させたい 使いまわしているWorkflowを呼びたい このようなときに使えるのがGitHub Actionsでは2つ提供されている。それが冒頭に書いた、repository_dispatchとworkflow_dispatchである。 この記事の結論 長くなってしまったので、冒頭で結論を書く。 repository_dispatchとworkflow_dispatchの使い分けの判断基準の一つは、実行時に参照するWorkflowのブランチをデフォルトブランチ以外としたいケースがあるかどうか？ デフォルトブランチ以外のWorkflowのファイルを参照してWorkflowを実行したい場合は、workflow_dispatchを選ぶしかない 2.サンプルコードで使っているリポジトリ https://github.com/gkzz/actions-playground 起点となるWorkflow(実行トリガーはpush)のリポジトリ https://github.com/gkzz/actions-dispatch-playground 起点となるWorkflowからkickされるWorkflow(実行トリガーはrepository_dispatch)のリポジトリ 3.環境情報 ローカル始めバージョンを書いておく必要があるものはない 使うActionのバージョンについては後述するWorkflowを参照してほしい 4.repository_dispatchとworkflow_dispatchの共通点や相違点 共通点 どちらも以下の権限を有する Personal Access Token が必要 repo:write 相違点 workflow_dispatchのみ、GUIから実行できる 実行場所はGithubの実行先のリポジトリのActionタブ pushしたWorkflowからdispatchする際のパラメーターの渡し方が違う(詳細は4-1参照) パラメーターの受け取り方が違う(詳細は5-1及び5-2参照) repository_dispatchのみ、event-typeを使ってWorkflowを実行するか制御できる repository_dispatchはevent-typeに応じて実行するかどうか決めることができる workflow_dispatchの場合、Workflowをkickされたら実行されてしまうのでkickしたWorkflowから渡されるパラメータの値によってjobを実行するように制御することはできる repository_dispatchのみ、Workflowはデフォルトブランチを参照して実行する 4-1.pushしたWorkflowからdispatchする際のパラメーターの渡し方 ここでは、curlコマンドでrepository_dispatchとworkflow_dispatchのWorkflowを実行しながらパラメータの渡し方の違いを確認しよう。 とりわけ、POSTする接続先URLと -d (--data)オプションで渡しているPOSTする値の書式はおさえておきたい。 repository_dispatch 接続先URLは https://api.github.com/repos/<REPOSITORY_OWNER>//dispatches $ curl -X POST \ -H "Accespt: application/vnd.github.v3+json" \ -H "Authorization: token <PAT_REPOSITORY_DISPATCH>" \ https://api.github.com/repos/gkzz/actions-dispatch-playground/dispatches \ -d '{"event_type": "sample-event", "client_payload": {"hoge": "hogevalue"}}' https://docs.github.com/en/rest/reference/repos#create-a-repository-dispatch-event workflow_dispatch 接続先URLは https://api. https://gkzz.dev/posts/update-manifest-with-yq-github-actions/ Sun, 30 Jan 2022 20:49:26 +0900 https://gkzz.dev/posts/update-manifest-with-yq-github-actions/ 1.この記事で達成したいこと GitHub Actionsでyqのコンテナイメージを使ってマニフェストを更新したい yqはPythonのパッケージマネージャのpipでも扱うことが出来るけどコンテナイメージで扱うほうが都合がよさそうなのでコンテナイメージでがんばりたい コンテナイメージで扱うというのは、docker runコマンドでyqのイメージをスポットで使う感じ yqの使い方についてはjqのyaml版と思って大丈夫。詳細は以前書いた記事を参考にしてほしい。 yqコマンド(jq wrapper for YAML)使い方備忘録 $ docker run --rm -v "$PWD:$PWD" -w="$PWD" \ --entrypoint yq linuxserver/yq \ <yqコマンド> GitHub Actions上でDockerコンテナイメージを扱う方法と注意点 やることは addnab/docker-run-action を使うだけ 基本的な使い方はaddnab/docker-run-actionの上記のリンクにサンプルコードを添えて書かれている しかし、docker runコマンドのときのように同アクションを使おうとすると、ホストとコンテナ間でマニフェストが置かれたディレクトリをマウントするところでつまずいた そこで、この記事では特に同アクションを使う際のホストとコンテナ間でディレクトリをマウント方法する方法について、yqのコンテナイメージを使って解説していきたい 2.前提 addnab/docker-run-actionの検証リポジトリはpublic public/private問わず、同Actionsを使う際の注意点は同じはずだけど念のため書いておく yqは以下のとおり2種類あるが、ここでは https://hub.docker.com/r/linuxserver/yq を扱う ↓この記事で使うyq Github https://github.com/kislyuk/yq https://github.com/mikefarah/yq Docker Image https://hub.docker.com/r/linuxserver/yq https://hub.docker.com/r/mikefarah/yq 3.環境情報 ローカル始めバージョンを書いておく必要があるものはない 使うActionやyqのイメージのバージョンについては後述するWorkflowを参照してほしい 4.この記事で扱うサンプルコード(つまずいたところは解決済) yqのコンテナイメージで更新対象のマニフェスト(manifests/deployment.yml.tmpl) 書き換え箇所はマニフェストのごく一部なので抜粋する --- apiVersion: apps/v1 kind: Deployment metadata: # 略 spec: replicas: 3 selector: matchLabels: app: sampleapp template: metadata: labels: app: sampleapp spec: affinity: # 略 containers: - name: sampleapp image: <REGISTRY>/<CONTAINER_IMAGE>:<IMAGE_TAG> ports: - containerPort: 80 yqのコンテナイメージを使うWorkflow(. https://gkzz.dev/posts/asdf-and-plugins/ Thu, 13 Jan 2022 10:31:18 +0900 https://gkzz.dev/posts/asdf-and-plugins/ 1.この記事で達成したいこと asdfとそのプラグインを設定する方法が頭の中でごちゃごちゃしていた。たとえば、、。 asdf plugin-addとasdf installはどっちからコマンド実行するの？ 既にプラグインはをインストールしているか？確認するのはどうやるの？ そこで実際に以下のasdfのプラグインを使いながら、その設定方法を理解したい kubectl asdf-community/asdf-kubectl: Kubectl plugin for the asdf version manager 2.はじめに そもそもasdfとはなにか？という説明は公式ドキュメントに譲りたいが、ひとことでいえば バージョン管理ツール である バージョン管理の類似ツールを挙げるとすれば、pythonのvirtualenvはそのひとつであろう。相違点はバージョン管理の対象がひとつだけか複数か。（virtualenvの場合はpythonのみのひとつだけ。） asdfでバージョンを管理するためには、asdf自体のインストールすることに加えて、バージョン管理したいツールに対応したプラグインもインストールする必要 がある 3.環境情報 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ asdf --version v0.10.0-0f99d0a 4.asdf自体のインストール asdfのドキュメントに従って進めればよいが、そのインストール方法はいくつかある 今回採用した方法はasdfのリポジトリのブランチを指定してクローンするという方法 指定したリリースブランチは、release-v0.10.0 $ git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch release-v0.10.0 $ tail ~/.bashrc 略 . $HOME/.asdf/asdf.sh . $HOME/.asdf/completions/asdf.bash これでasdfのインストールは終わった。いよいよプラグインのインストールに移るが、ややこしく感じたので大まかな流れをおさえておきたい。 5.バージョン管理したいプラグインのインストールと設定の大まかな流れ 必要になったプラグインあるいはそのバージョンが既にあるか確認 $ asdf plugin list | grep <プラグイン> プラグインがなければ追加 $ asdf plugin-add <プラグイン> <リポジトリ> 任意のバージョンをインストール $ asdf install <プラグイン> <バージョン> asdf global/localで導入 $ asdf local <プラグイン> <バージョン> 導入したプラグインとそのバージョンが書かれていることを確認 $ asdf current $ cat . https://gkzz.dev/posts/specify-aws-config-profile-with-direnv/ Wed, 12 Jan 2022 18:34:47 +0900 https://gkzz.dev/posts/specify-aws-config-profile-with-direnv/ 1.この記事で達成したいこと $HOME/.aws/configに書かれた名前付きプロファイルをイイ感じに使いたい ディレクトリごとに指定できるようにしたい AWS_DEFAULT_PROFILEを都度exportするのは面倒なので避けたい $ export AWS_DEFAULT_PROFILE=user1 2.前提/環境情報 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ direnv --version 2.21.2 3. どうやるか？ direnvを使う direnvとは、ディレクトリに移動した際、自動で記載されている環境変数を読み込んでくれるもの direnvを使うことでできること ディレクトリ/環境に適したAWS_PROFILEを指定すること 前提として、$HOME/.aws/configに以下のように書かれていること [default] region=us-west-2 output=json [profile user1] region=us-east-1 output=text 出所：名前付きプロファイル - AWS Command Line Interface 4.使い方 aptでdirenvをインストール ※Installation | direnv では紹介されていなかった。。 Setup | direnv に従って ~/.bashrc を編集 $ apt search direnv | tail WARNING: apt does not have a stable CLI interface. Use with caution in scripts. https://gkzz.dev/posts/display-sensitive-value-with-terraform-output/ Fri, 07 Jan 2022 10:35:00 +0900 https://gkzz.dev/posts/display-sensitive-value-with-terraform-output/ 1.この記事で達成したいこと sensitve=trueな値をterraform outputで確認したい 1-1.お悩みポイント そもそもsensitve=trueとしている理由は、terraform applyやterraform outputする際にはCLI(ターミナル)上では出力させたくないから なので、terraform applyやterraform outputする際には表示されないのが正しい！ とはいえ、確認したいときはある。さて、どうするか、、？？？ $ terraform output aws_iam_smtp_password_v4 = <sensitive> sensitive=trueの技術的仕様はterraform.tfstateに記載されている値のうち、出力させないそれらを指定するというもの なので以下のように確認することはできるが、チョット煩わしい。シュッとやりたい。 $ cat terraform.tfstate | jq -r .outputs { "aws_iam_smtp_password_v4": { "value": "xxxxxxxxxxxxxxxxxxxxxx", "type": "string", "sensitive": true } } このような都合のいい、「ワガママ」な事情をよしなに汲み取ってterraform outputで確認するというのが本記事の目的 2.前提 Terraformのインストール方法を始めとする初期設定は終えているものとして話を進める 今回出力したくないセキュアな値は ses_smtp_password_v4 とする サンプルコードは以下のとおり $ cat main.tf resource "aws_iam_user" "dummy" { name = "dummy" path = "/dummy/" } resource "aws_iam_access_key" "dummy" { user = aws_iam_user.dummy.name } output "aws_iam_smtp_password_v4" { value = aws_iam_access_key. https://gkzz.dev/posts/aws-security-group-same-permission-must-not-appear/ Tue, 04 Jan 2022 21:39:35 +0900 https://gkzz.dev/posts/aws-security-group-same-permission-must-not-appear/ 1.この記事で達成したいこと aws_security_groupリソースを使って複数のインバウンドルールを追加しようとして引いたエラーを解決する $ terraform apply 略 │ Error: error updating Security Group (sg-000000000000): error authorizing Security Group (ingress) rules: InvalidParameterValue: The same permission must not appear multiple times │ status code: 400, request id: 000000000000000000 │ │ with aws_security_group.dummy-sg, │ on main.tf line 23, in resource "aws_security_group" "dummy-sg": │ 23: resource "aws_security_group" "dummy-sg" { エラーメッセージが指す23行目付近で書いていること $ view main.tf 略 23 resource "aws_security_group" "dummy-sg" { 24 name = "dummy-sg" 25 description = "dummy security group" 26 vpc_id = aws_vpc. https://gkzz.dev/posts/what-i-talk-about-when-talking-about-running-review/ Thu, 30 Dec 2021 20:28:31 +0900 https://gkzz.dev/posts/what-i-talk-about-when-talking-about-running-review/ 1.この記事で達成したいこと 以下の本を読んだので感想や学びを残す 走ることについて語るときに僕の語ること (文春文庫) | 村上 春樹 納めるために書ききれていないネタを昇華させるか、、 っ 【読書メモ】「走ることについて語るときに僕の語ること」 — gkzz / Gakuji Tamaki (@gkzvoice) December 30, 2021 2.本書の内容を三行で 優れた小説家には才能があるが、自分にはそういったものはなく、凡人といっていい では、凡人がどうやって小説を書き続けようか？（そもそもなぜ書くことになったのか？も触れている） それは小説を書き続ける集中力とそれを支える体力を養おうと考え、試行錯誤していく、、 3.感想 本書は、特に秀でたわけではないが続けなければならないこととの付き合い方 という普遍的な問いに対して示唆を与えてくれる。自分は先天的な才能を持ち合わせていないという境遇が分かったとしても、集中力や持続力は後天的に身につけることができる。また集中力や持続力は肉体的な衰えと抗うためにも必要だという。そういった集中力や持続力を獲得するためになんとかランニングを始め、トレーニングを続けているが、その難しさと続けるコツ、考え方のヒントが本書では散りばめられている。ぼくにとって胸に響いた箇所は以下の2箇所だ。 Pain is inevitable, Suffering is optional. それが彼のマントラだった。正確なニュアンスは日本語に訳しにくいのだが、あえてごく簡単に訳せば、「痛みは避けがたいが、苦しみはオプショナル（こちら次第）」ということになる。 たとえば走っていて「ああ、きつい、もう駄目だ」と思ったとして、「きつい」というのは避けようのない事実だが、「もう駄目」かどうかはあくまで本人の裁量に委ねられていることである。 走り続けるための理由はほんの少ししかないけれど、走るのをやめるための理由なら大型トラックいっぱいぶんはあるからだ。 僕らにできるのは、その「ほんの少しの理由」をひとつひとつ大事に磨き続けることだけだ。 また、本書は継続する勇気と活力を与えてくれる。文体はみずみずしく、景色が目に浮かぶよう。自己啓発書というより小説を読んでいるかのような気持ちになる。それで何かを続ける難しさと大切さを自身の経験談になぞらえて語られている。ぼくはいわゆるソフトウェア・エンジニアとしてお仕事しているのだけど、本書を読み進めていくうちに、走って、自分をシステムに見立ててパフォーマンスチューニングしたい気持ちに駆られる。（実際やったがなかなか続かない笑。） このようにぼくは本書から何かを続けること、とりわけ自分がそこまで得意ではないことを粘り強く続けることのエッセンスを学んだと思っている。とはいえ、これだけが本書から学ぶことができることではないはず。なんども読み返したい一冊である。 https://gkzz.dev/posts/challenges-working-students-encounter-in-daily-life/ Mon, 20 Dec 2021 21:36:09 +0900 https://gkzz.dev/posts/challenges-working-students-encounter-in-daily-life/ こんにちは。gkzz (@gkzvoice) / Twitterです。本記事は社会人学生 Advent Calendar 2021の24日目の記事です。 実は先日、学生生活のふりかえり記事を書いています笑。 帝京大学理工学部(通信教育課程)の社会人大学生1年目をふりかえる | gkzz.dev せっかくなので自分の社会人学生生活について改めて向き合うこととし、表題のとおり「ほんとうに社会人学生になってよかったのか？」と批判的に捉え直すことにしました。多くの社会人学生のふりかえり記事では、社会人学生になることに対して大変など苦労する声を聞くことはありますが、結論としてはポジティブな内容が多いです。ところが、ぼくの場合はそんなことはなくて悩みながら勉強しているというのが正直なところです。社会人学生生活のネガティブな一面にもっとフォーカスした記事を読んで自分の考えを反芻させようとするも、そのような記事はなかなか見つかりません。そこで現時点での考えを後々思い出すことが出来るように、自分のために「結局自分は何を決めかねているのか？」書き留めておくことにしました。 想定読者 本記事の想定読者として以下の2点を挙げている。 社会人学生になろうと入学書類を集めている、社会人学生になる前の自分 晴れて大学を卒業した、社会人学生を終えた後の（、大学での学びを活かす決断をするときの）自分 というのも、「そうだ、社会人学生になろう！」と準備を進めているころに読んでいたらまた違った展開になっていたかもしれない。また「卒業してから何をするか？」について少しでも今の考えを書き留めておくことで実際にそうなったときに考える助けになるように思うからである。 後者については、後述するハッカー飯さんというWebサービスをきっかけにいただいたフィードバックであり、かつなくてはならない観点だった。他にもたくさんの方からご指摘いただいたので改めて感謝の気持をお伝えしたい。ありがとうございました！ さて、はじめに本記事を書いているぼくの背景について軽く触れておきたい。というのも、ここで取り上げる話題に対する考え方は読者によって千差万別だと思うし、またそうあるべきだと思うので、あくまでもぼく個人の場合という前置きをおくためにも書いておきたい。 自己紹介 もともと経済学部卒、営業寄りの仕事をしていたが、プログラミングをする機会があり、エンジニアに転職してはや4年。 先日サイボウズに転職。 今年2021年12月、帝京大学理工学部の通信教育課程の2学年に編入学。 予想はしていたが、仕事と勉強の両立はたいへん。 またそれとは別に「ほんとうに社会人学生になってよかったのか？」とやや考えがゆらいでいる。（今回の主題はココ！） 「大事なことは卒業することではなく、卒業してから何をするか？そのために今後の自分の人生に置いてどこに専門性を置くか？決めて進むこと」であるが、それが決まらない。 卒業するという手段が目的化している。 どうして悩んでいるのか？ 仕事と勉強でてんやわんや。 このままでは単位を取るだけで終わってしまうという危機感は募る。 とはいえ、微々たるではあるが、できなかったことができるようになっていく感覚はある。 「ほんとうに社会人学生になってよかったのか？」と問われるとなってよかった 「わざわざ学生にならなくても勉強はできるけれども、どうして学生をするのか？」それは勉強そのものが好きだからというのと、学歴をゲットして第三者に勉強した結果を評価してもらいたかったから。 社会人学生になって迷いはあるけど社会人学生にならなかったらまた別の迷いが出てきそう、、。 で、答えは出ていないけど「卒業してから何をするか？そのために今後の自分の人生に置いてどこに専門性を置くか？」決めるためのヒントはみつかった > 今後も、二兎を追っていたはずが最終的にはそれが一兎だったとわかるまで、研究を続けていきたい 理転文転を繰り返した結果、どちらも諦められずに情報系研究員をしながら人文社会系の研究室で社会人博士を始めた話｜Yuri Nakao @nkwyri #note https://t.co/LVJ1OBamED — gkzz / Gakuji Tamaki (@gkzvoice) December 17, 2021 これまで選んできた選択が実は関連性があった。 Steve Jobs’ 2005 Stanford Commencement Address もともと経済学部に在籍していたせいか、株式投資、企業価値評価は興味がある。 理転した、しないは関係ないという見方もできるのか 「古きは潔く捨てよ」“アンラーニング”がベテランエンジニアの価値を左右する【GMOペパボ・栗林健太郎】 - エンジニアtype | 転職type 入学する前の自分に伝えたいことを五月雨に 一般の技術書や記事、YouTubeの動画など学習教材は玉石混交ではあるがあふれており、学習の機会はいくらでもある。 単位駆動でインプットが進む。 時間の使い方に制約が入ると集中できるというか集中せざるを得ない環境に追い込まれる。 関心の対象が広がった。 単位を取るために食わず嫌い精神を捨てて勉強するため、以前まで興味がなかったことに対しても関心を持つことが出来るようになり、自分の可能性を広げることができた。 勉強も学校にとらわれることなくやりたい。 勉強以外の活動もしてもいい。 たとえば、[【読書メモ】『HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント』 | gkzz. https://gkzz.dev/posts/devops-handbook-review/ Fri, 10 Dec 2021 11:08:33 +0900 https://gkzz.dev/posts/devops-handbook-review/ 1.この記事で達成したいこと 以下の本を読んだので感想や学びを残す The DevOps ハンドブック 理論・原則・実践のすべて : ジーン・キム, ジェズ・ハンブル, パトリック・ボア, ジョン・ウィリス, 榊原 彰, 長尾 高弘: Japanese Books 2.前提 本題に入る前に、前提として僕のDevOps周りの背景知識について触れようと思う。 2-1.僕のDevOps周りの背景知識 これまで以下の経験をしており、多少なりともDevOpsとはなんぞやという点は抑えているつもりだった。。 toBのWebサービスの運用と開発 Gitlab RunnerとArgo CDを使ったGitOpsなパイプラインの設計と構築 Django制の社内システムの開発 以下のpodcastを聞いたことがあり、Circle CIはまさにDevOpsを体現していると思っている 7. CI/CDとか、CircleCI自体の設計・開発プロセスとか | fukabori.fm ※ 本書を読み進めるまでは、DevOpsとは開発と運用が手を取り合っておこなうこと、あるいは一手に引き受けることだと思っていた しかし、本書を読み進めていくうちに、DevOpsを推し進めるには、それだけで足りないと考えを改めることになる 3.目次 第1部 3つの道 第1章 アジャイル、継続的デリバリー、そして3つの道 第2章 第1の道:フローの原則　ほか 第2部 スタートのための糸口 第5章 最初に手を付けるバリューストリームの選択方法 第6章 バリューストリーム内の作業を理解し、それを可視化して、組織全体に広げる　ほか 第3部 第1の道:フロー改善の技術的実践 第9章 デプロイパイプラインの基礎の構築 第10章 高速で信頼性の高い自動テストの実現　ほか 第4部 第2の道:フィードバックの技術的実践 第14章 問題の可視化と解決のための基礎となる遠隔測定データを作り出す 第15章 遠隔測定データを分析して問題の予測と目標の達成に活かす　ほか 第5部 第3の道:継続的な学習と実験の技術的実践 第19章 日常業務での学習の実現と日常業務への学習の注入 第20章 一部門の発見を全社的な進歩につなげる　ほか 第6部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践 第22章 すべてのエンジニアの毎日の職務として情報セキュリティを位置づける 第23章 デプロイパイプラインを防御する 4. https://gkzz.dev/posts/thx-apc-hello-cybozu/ Mon, 29 Nov 2021 19:23:23 +0900 https://gkzz.dev/posts/thx-apc-hello-cybozu/ 本日2021年12月01日(水)、サイボウズ株式会社（Cybozu, Inc.） に入社 しました。ポジションは 生産性向上エンジニア です。これに伴い、株式会社エーピーコミュニケーションズ（以下、APC）を先月11月30日付で退職しました。 ※ 写真は近くのお花屋さんで買った観葉植物を撮影したもの。寒々とした今年の冬を乗り越えようと古い葉っぱを落として新しい葉っぱが代わりに台頭している。 これまでやってきたこと お仕事 toBサービスの運用やCI/CDパイプラインの設計・構築などいろいろ プライベート 社会人大学生として情報系の勉強をしている 帝京大学理工学部(通信教育課程)の社会人大学生1年目をふりかえる | gkzz.dev それまでは読書会を毎週開催したりしていた #技術書を英語で読む会 という自分が参加したかった読書会を半年ほど開催したからふりかえる | by gkzz | Medium ブログでも書いているのでご参照ください！ https://gkzz.dev https://zenn.dev/gkz https://qiita.com/gkzz 生産性向上エンジニアとしてやっていきたいこと 採用ページに書いてあるとおり、横串に自動化/効率化施策を推し進めていくと伺っています。あまり扱っていく技術や取り組んでいく業務内容にこだわりはなく、むしろチームにとって必要だけど手が回っていない 「落ちているタスク」 を拾い上げてきたので、これからも選り好みせず地道にやっていこうとおもいます。 業務内容 チームを横断した開発効率を高める基盤の整備 開発チームの業務の自動化や効率化の支援 など 過去の活動事例はこちら https://blog.cybozu.io/archive/category/生産性向上チーム https://tech.cybozu.io/slides/tags/生産性向上チーム/ 主に使っている技術要素 言語: Go, TypeScript バージョン管理: GitHub (Enterprise Cloud / Enterprise Server) CI: GitHub Actions, CircleCI, Jenkins アプリケーション監視: Datadog パブリッククラウド: AWS, GCP 仮想化技術: Docker, Kubernetes Infrastructure as Code: Terraform, Serverless Framework 参考：キャリア採用 生産性向上エンジニア | サイボウズ 採用情報（新卒・キャリア） https://gkzz.dev/posts/high-output-management-review/ Tue, 02 Nov 2021 20:00:37 +0900 https://gkzz.dev/posts/high-output-management-review/ 1.この記事で達成したいこと 以下の本を読んだので感想や学びを書き残す 『HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント : アンドリュー・S・グローブ, ベン・ホロウィッツ, 小林 薫』 また、そのような感想を抱くことになった背景として、僕自身のマネージャー業務との関わり方や関心度合いも書き留めておく 2.本書を読んだ当時の僕自身のマネージャー業務との関わり方や関心度合い マネージャー業務はやっていない。 ソフトウェアエンジニアへ転職する以前は業務提携先との窓口、工数管理などマネージャー業務チックなことも多少やっていたので、「マネージャー業務とはなんたるか」触り程度は理解しているはず マネージャー業務に関心・興味がないわけではなく、むしろチャレンジしてみたいなというお気持ち 興味が湧いたきっかけは以下のポッドキャストを聞いたこと 42. 良いマネジメントとは？良いミーティングとは？ w/ konifar | fukabori.fm 3.目次 第1部　朝食工場ー生産の基本原理 1章　生産の基本 2章　朝食工場を動かす 第2部　経営管理はチーム・ゲームである 3章　経営管理のテコ作用 4章　ミーティング 5章　決断、決断、また決断 6章　計画化 第3部　チームの中のチーム 7章　朝食工場の全国展開へ 8章　ハイブリッド組織 9章　二重所属制度 10章　コントロール方式 第4部　選手たち 11章　スポーツとの対比 12章　タスク習熟度 13章　人事考課 14章　二つの難しい仕事 15章　タスク関連フィードバックとしての報酬 16章　なぜ教育訓練が上司の仕事なのか 4.感想や学び グローバル化と情報革命はビジネスのライフサイクルを早め、意思決定に残された時間は限られていき、今後も一層その傾向は強まっていく そこで中間管理職が経営陣と社員との間の潤滑油となり、また社員の生産性を引き上げるために1on1もがんばれｗと 例）朝食工場、ミーティング、とりわけ1on1 cf. 「壺の中には大きな石から先に入れなければならない。大きな石から先に壺へ入れない限り、それが入る余地はその後二度とない。」 1on1 時間は少なくとも1時間。部下は1ON1でおさまる程度のトピックしか持ち出さない。解決しなければならない問題は15分程度で片付くものではない。 場所は部下の仕事場。部下の仕事の雰囲気を目にすることができる。 準備は"部下が"しているか。 部下が提示した問いに対して回答ではなく、深堀のための質問をし、部下に思考を促し、コーチングする 1on1中に事前に用意したアウトライン、メモ帳に書き込んでいき、1on1後の行動を確約させる 緊急ではないトピックは"保留"扱いとし、“バッチ処理"をおこなう。(割り込みタスクの未然防止 ※ 「4章 ミーティング」までしか読んでいない。 https://gkzz.dev/posts/intro-to-graph-theory/ Fri, 15 Oct 2021 19:48:59 +0900 https://gkzz.dev/posts/intro-to-graph-theory/ 0.はじめに 大学でグラフ理論を勉強する機会があったので学んだことを書きなぐっていきます。グラフ理論は情報工学界隈に限らず、広く一般的に使われている学問領域です。また今回取り上げる内容は表題のとおり、入門中の入門ということで聞いたことがあるという方もいらっしゃることかもしれません。とはいえ、グラフ理論を勉強していくうちにその魅力にとりつかれ、しっかり学んで血となり肉としたいと思い、自分のために勉強したことを書き残していきます。 cf. 帝京大学理工学部(通信教育課程)の社会人大学生1年目をふりかえる | gkzz.dev 1.前提 グラフ理論を勉強する難しさをあげるとしたら、書籍やウェブサイトなど資料によって、「同じことを言っているが、使っている用語が異なる」、さらには「用語のスコープが異なる」こと e.g. ノードと同じ意味：節点、頂点、点 e.g. エッジと同じ意味：枝、辺、線 そこで、本ページではいわゆる用語の定義は参考資料を掲載する程度としたい 本書の位置づけは、「グラフ理論を勉強するとどういった用語を目にすることになるのか？」という、グラフ理論入門の入門とする 2.「グラフ理論」でいわれている「グラフ」とは？ ノードの集合とエッジの集合を用いて様々な現象をモデル化したもの ノードは節点、頂点、点ともいう エッジは枝、辺、線ともいう 株価チャートのようなものではない 数字が連続的ではなく、「飛び飛び（離散的）」 2-1.「グラフ」を使って抽象化された一例 電車の乗換案内アプリ 電車の乗換案内アプリを使う目的は、現在地から目的地までの最短経路を知ること ただし、「コスト（グラフ理論的には『重み』）」をキョリ、交通費、交通機関の乗り換え回数などどれにするか？ によって答えは変わる！ 2-2.グラフの構成要素であるノードやエッジは電車の乗換案内アプリでは、どれに該当するか ノード：駅 エッジ：線路や駅と駅を結ぶ道路 重み：移動コスト（キョリ、交通費、交通機関の乗り換え回数など） 参考: 例題で学ぶグラフ理論 | 安藤 清, 土屋 守正, 松井 泰子 |本 | 通販 | Amazon グラフ (離散数学) - Wikipedia 離散数学とは - コトバンク 3.「グラフ理論」を勉強するとなにがうれしいか 検討対象が膨れ上がってしまうような 「組み合わせ爆発」が起きてしまう問題に対する「向き合い方」 をおさえておくことができる！ 後述するオイラーグラフ、ハミルトングラフなど典型的なグラフ構造は、離散的アプローチをするうえでの武器となる いわゆる「一筆書きできるかどうか」の判断も、ルートをしらみつぶしに調べ上げることなくできる 4.「グラフ」の基本的な考え方 ※ 用語説明は以下の書籍と動画に譲りたい。ここではグラフに対する基本的な考え方、見方を挙げていく。 離散数学入門#6: オイラーグラフと郵便配達員問題 - 00:06:41 歩道(walk)、 小道(trail)、道(path)、閉路(cycle)の類似点と相違点について図を用いて分かりやすく解説されていて、おすすめ 例題で学ぶグラフ理論 | 安藤 清, 土屋 守正, 松井 泰子 |本 | 通販 | Amazon 上記の講義動画シリーズで推薦されていた書籍の一つ。他の書籍より自分にはこれが合っていた。 離散数学入門#0: グラフ理論へのイントロダクション，授業ガイダンス・基本的な用語の準備 * 歩道(walk): 頂点から始まり、頂点と辺が交互に結び、頂点で終わる列（頂点や辺の重複があってもよい） * 小道(trail): 辺の重複がない歩道(頂点の重複があってもよい) * 道(path): 辺の重複がない歩道のうち、頂点の重複がないもの * 閉路(cycle): 辺の重複がない歩道のうち、「始点と終点以外」頂点の重複がないもの（始点と終点は重複している） * 回路(circuit): 閉じた小道。辺の重複がない歩道のうち「始点と終点が重複」しているもの ※ 図は離散数学入門#6: オイラーグラフと郵便配達員問題 - 00:06:41を参考に筆者作成 https://gkzz.dev/posts/fav-nosh-menu/ Wed, 13 Oct 2021 23:55:06 +0900 https://gkzz.dev/posts/fav-nosh-menu/ はじめに noshという宅食サービス。聞いたことがありますか？ こんにちは😊 noshは温めてそのまま食べていただくと、洗い物が省けて時短になりますが、盛り付けると豪華な食卓に早変わり〜🍁🌰✨ ぜひチャレンジしてみてくださいね！#いただきナッシュ pic.twitter.com/8cXHRDYRfO — 『nosh（ナッシュ）』美味しく栄養管理ができる😋 (@nosh_fresh) October 9, 2021 ホームページにはnoshの特徴としてこのように紹介されています。 ヘルシー 糖質が控えめ 塩分も控えめ シェフと管理栄養士がつくっている 片付けも簡単便利 容器は燃えるゴミ 容器が小さく折り畳められる！！！！ ちょっとリッチなスーパーでもヘルシー弁当はあるけどnoshの容器と違い、ゴミとして捨てる際、かさばってしまうので、容器が折り畳める点はうれしい！！ 今月からはじめているのですが、予想以上においしく、もう届けてもらった10食分全て食べてしまい、2回目の発送を急遽お願いしているところです。 そんなnoshですがメニューも多いので自分の備忘録として頼んだメニューのなかで「特に美味しかった」メニューを書いていこうと思います。 ※ ここで取り上げているメニューは2021年10月中に注文したものです。noshではメニューの入れ替わりがあるので、食べようと思ったときにはメニューにないかもしれません。ご注意ください。 noshで美味しかったメニュー【2021/10版】 【1位】ロールキャベツのチーズデミ ロールキャベツの上にとろとろチーズがたっぷり！ 他にも美味しいメニューばかりだけどロールキャベツが好きというのもあり、余計美味しく感じた 【2位】旨だれペッパーチキン 鶏肉料理ではぶっちぎりといってもいい。ご飯が欲しくなる。 【3位】豚の生姜焼き おいしくないわけがない！ 【4位】チリハンバーグステーキ 「おいしい」とブログやTwitterはじめ、あちこちで聞くだけあっておいしい。 【5位】牛肉の麻婆ごまだれ 鶏肉、豚肉を中心に選ぶことが多いなかで貴重な牛肉を使ったメニュー！ 【6位】クリームコロッケグラタン クリームコロッケの周りを囲むグラタン？、チーズ？がおいしい 【7位】タンドリーチキン チキンと一緒に添えてあるオムレツ？もおいしい 【8位】焼鳥の柚子胡椒 ゆずが効いていてサッパリ！ ※ 随時更新していきます。 合計￥6,000OFFクーポン（申し込んだあなたとわたしで3,000円ずつクーポンが発行されます！） 最後にヘルシーな宅食サービスnosh(ナッシュ)のクーポンのリンクを貼っておきます。 ※個人情報は双方伝わらないのでぜひご賞味あれ。 ※広告で流れてくるクーポンは300円程度しか割り引かれないのでオトクのはず、、！ https://nosh.jp/share/friend-202103/x56oj https://gkzz.dev/posts/find-my-strength/ Sat, 25 Sep 2021 00:48:28 +0900 https://gkzz.dev/posts/find-my-strength/ 自分の強みを見つける。 カンタンなようで難しくないですか？それとなく考えて「ワタシの強みはこれだ！」などと決めつけてしまうこともあるのではないでしょうか？ 今日はそんな見つけることが難しいとされる自分の強みをふとしたことで見つけたので、どうやって見つけたか？書き残そうと思います。 さて、僕が見つけることができた方法をお話する前に、下記の任天堂の岩田社長のインタビュー記事についてご紹介したいと思います。読んだ方もいらっしゃるかもしれません。 任天堂・岩田氏をゲストに送る「ゲーマーはもっと経営者を目指すべき！」最終回――経営とは「コトとヒト」の両方について考える「最適化ゲーム」 自分の強みを見つけることは難しい 岩田社長は、自分の強みを見つける難しさについてこのようにお話しています。 岩田氏： 自分の労力の割に周りの人がすごくありがたがってくれたり，喜んでくれたりすることってあるじゃないですか。要するにね，「それがその人の得意な仕事なんだ」って話で。逆に，自分的にはすごい努力して，達成感もたっぷりあるのに，周りからは「はあ？」みたいに思われるこ> ともあって。それはね，本人が好きだったとしても，実は不得意なことかもしれないんですよ。 4Gamer： なるほど。 岩田氏： この話はですね，私は毎年，会社説明会で学生さんにお話しているんです。よく「自分の強みを見つけろ！」みたいな話を学校で言われると> 思うんですけど，普通は，学生時代に「何が自分の強みなのか」なんて，なかなか簡単には分かんないわけじゃないですか。 出所：任天堂・岩田氏をゲストに送る「ゲーマーはもっと経営者を目指すべき！」最終回――経営とは「コトとヒト」の両方について考える「最適化ゲーム」 では、どうやって見つければいいのか？岩田社長は次のように説明します。 岩田氏： だから，「 “労力の割に周りが認めてくれること” が，きっとあなたに向いてること。それが“自分の強み”を見つける分かりやすい方法だ よ！」って，いつも学生さんに喋ってるんですね。「さっさと得意なことが分かった方が，人生はいいぞ！」って話なんですが（笑） 出所：同上 自分は周りが思っているほど苦労しているとは思えないことを見つければいい。岩田社長のアドバイスを頼りに、自分の得意なことを探したけど見つけることができませんでした。では、どうやって見つけることができたのでしょうか？いよいよ本丸です。 （余談：ところでどうして見つけることができなかったのでしょうか？それは 「これはたいしたことではない。できてあたりまえだ」と目にもくれないからではないか？ と考えています。つまり、探そうにも目に入らないので取りこぼしている のではないかと。。） じゃあ、どうやって見つけたの？ 友人の一言が決め手でした。（なんでこう言われたのか忘れましたが。すみません。） 気軽に質問できる姿勢はマジで見習いたい 聞いたときは言わんとしていることが分かりませんでしたが、前述した岩田社長の記事を共有していただいて腑に落ちました。岩田社長の記事を友人から紹介される以前から、“労力の割に周りが認めてくれること” を探すことが自分の得意なことを見つける方法だということを知っていましたが、それでも友人の考えを理解することが難しく感じてしまいました。 自分の強みについて考える 質問する姿勢 せっかくなのでなんで質問しようと思うのか？考えてみました。自分では大したことではないと思ってしまっているのでなかなかその行動の動機を導き出せなかったのですが、ふたつ答えが出てきました。 自分が知らないことは知りたいから 自分ができないことをできるようになるために質問することが必要だから ※ もちろん、質問に答えていただく方の手間や時間には気をつけて、「質問内容やそれを質問しようと思った背景、自分の質問に対する答えとそれに対して抱く疑問点や懸念点」など質問に対してどう回答すればよいか？考えやすいように配慮はしているつもりです。 結論 友達や家族は大切にしよう。 自分の価値に自分で気がつくことは難しい。 Tさん、ありがとうございました。これからもよろしくおねがいします。 p.s. 飲み会がもたらした効果は偉大なのかもしれない。ずいぶんご無沙汰だけど。 2021/12/02更新 貴重な他己評価をいただいたので読み返せるようにしておく。よこちさん、いつもありがとうございます。 お疲れさまでした！ 探究心がすごかったり、質問力があったり、AP Tech Talk ってイベントの企画によく乗ってくれたり、同じチームになったことないけどお世話になる場面がよくありました。新天地でもご活躍されることを祈っています！ https://t.co/2VOgB4kvq4 — よこち (@akira6592) December 1, 2021 https://gkzz.dev/posts/system-performance-shoeisha/ Sun, 12 Sep 2021 22:26:29 +0900 https://gkzz.dev/posts/system-performance-shoeisha/ 1.この記事で達成したいこと 以下の本を読んだので感想や学びを書き残す 「絵で見てわかるシステムパフォーマンスの仕組み | 小田 圭二, 榑松 谷仁, 平山 毅, 岡田 憲昌」 また、そのような感想を抱くことになった自分の担当業務内容や役割も書いたほうが改めて本書を手に取る際にて助けになるだろうと思い、書いていく 2.本書を読んだ当時の担当業務や役割 主な担当業務はtoBのWebサービスの運用兼開発と問い合わせ対応 そのなかで「xxx機能がうまくできないんだけど〜」というお問い合わせを受けてログを追うことがある ここで肝となるのが、問い合わせの背後に見え隠れする「見るべきログのアタリ」をどれだけ早く見つけることが出来るか？また、そこから何を読み取り、次の一手を決めるか？ （回答する？さらなる調査をする？機能改修？etc…） ※ いわゆる「パフォーマンスチューニング」はやっていないが、興味はある（技術検証の一環で見様見真似でパフォーマンス測定なるものはやったことはあるけど。。） アルゴリズムやネットワーク、データベースといった大学の学部レベルでのコンピュータ・サイエンスを勉強する社会人学生でもある 本書はいわゆるパフォーマンス測定でご飯を食べるインフラエンジニアだけではなく、僕のような学生やWebアプリケーション開発エンジニアも学びがある一冊だと思う 名著とされる「詳解 システム・パフォーマンス | Brendan Gregg, 西脇 靖紘, 長尾 高弘」は読み進めることが難しく感じた 一方で、本書は文字どおり多くの図やイラストを用いて、システムパフォーマンスについて解説されていると感じた。 3.感想や学び 本書は、「情報科学を学ぶことの大事さ」 というコラムを設けて情報科学を学ぶことの重要性について説いており、大学での勉強をがんばろうと思えた パフォーマンス測定の基本について、"はさみうち" という言葉で表現していたことが印象的 そもそも"はさみうち"とは はさみうちの原理 - Wikipedia パフォーマンス測定について端的に表していると感じたが、大学の極限の授業で"はさみうち"について学んでいたという点も印象に残った理由かなと e.g. サーバーAのログの該当箇所のタイムスタンプとサーバーBの該当箇所のタイムスタンプだけずいぶん開きがあるようにみえるな、、、。 <クライアントPC> <--> <サーバーA> <- ??? -> <サーバーB> <--> <サーバーC> パフォーマンスを取得するコマンドが出力する情報にはいくつか種類がある サマリ形式 一定期間の情報を合計もしくは平均で表示 「調査の最初に概況を押さえたい」ときに効果的 e.g. sarやvmstat イベント形式 個々のイベントを表示 「いつ、どこで何が起きたか？詳細に知りたい」ときに効果的 e.g. パケットキャプチャやシステムコール ※ データが莫大になり、負荷も大きいため、本番環境で常に取得するようなツールではない。サマリ形式のコマンドでアタリを付けた後、使うのがよさそう。 スナップショット形式 その瞬間瞬間の状況を記録する。 e.g. psやtop 4. https://gkzz.dev/posts/sophomore-voice/ Sun, 12 Sep 2021 22:25:45 +0900 https://gkzz.dev/posts/sophomore-voice/ 1.この記事で達成したいこと 以下 4 点の内容を書き留め、次年度の履修登録の参考にしたい 単位取得状況 授業を受講してから自分に起きた変化 今年度の履修戦略と次年度に向けて 授業のひとこと感想 また、学割ネタも箇条書き程度だけど書いておきたい 公開後に出てきたネタ 2.前提 2021 年 4 月に大学 2 年生に編入学 今年度はコロナ情勢を踏まえて　リモート環境での受講 となっている。次年度以降もこの体制が続くか不透明。 そもそも通信制といえども全ての授業をフルリモート、オンラインで完結できるわけではない。スクーリングというキャンパスに足を運んで受講する授業もある。 cf. スクーリング - Wikipedia 働き方もほぼフルリモート、在宅勤務とスキマ時間を大学の勉強に充てることができている。これは仕事と学業の両立にかなり大きく貢献しているはず。 また授業ではどんなことを扱うのか？教科書は何を使っているのか？といったことは以下のページにシラバスとしてあがっている Web Syllabus（講義概要） 2021 年度 理工学部 情報科学科（通信課程） | 帝京大学 宇都宮キャンパス なぜ大学で勉強しようと思ったか？ なぜ大学で勉強しようと思ったか？それは以下の 2 点が大きい。 腰を据えて体系的に学びたい 好きな「学ぶこと」で名をあげたい cf. いろいろ悩んで帝京大学理工学部(通信教育課程)の社会人大学生になった もちろん、勉強しようと思った理由として、「CS の学位を取ることで求職活動においてグッと選択肢が広がるから」というのもあるが、これは卒業してしまえば誰にでも言えることであり、僕個人に限った話ではなかったので省いた。僕にとって進学するという決断をするうえで決定的な要因となったのは上記の 2 点だと思っている。 また、外資への転職が進学のモチベーションだということもいらっしゃると思うので参考文献だけ紹介しておきたい。 エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド | 竜 盛博 |本 | 通販 | Amazon 3.単位取得状況 サマリー 総取得単位数は62 内、2022 年度の編入時に認定された単位数は 32 授業と試験やレポートを突破して取得した単位数は 30 なお、落とした単位は 4 であり、履修単位数は 30+4=34 科目別(受講した時期) 単位取得確定 物理学 1(1Q) 基礎数学(1Q) 幾何学(1Q) プログラミング 1(1Q) プログラミング 2(1Q) Web 技術基礎(2Q) 技術者倫理(2Q) プログラミング 3(2Q) プログラミング 4(2Q) 情報技術基礎(3Q) コンピュータネットワーク(3Q) データ構造とアルゴリズム(3Q) グラフ理論(3Q) 離散数学(4Q) データベース論(4Q) 落単 論理数学(2Q) 数理統計学(4Q) 補足 僕が今年度履修している授業の数は 17 個であり、また今回履修した授業は全て取得できる単位は 2 単位 1Qあたりに履修している授業の数は4個程度 また試験は 1Q は 7 月頭、2Q は 9 月頭、3Q は 12 月頭、4Q は 2 月頭となっており、試験のおよそひと月前程度までに授業ごとに課せられているレポートや中間試験、ミニテスト（以後、事前課題とする）などをこなす必要がある。そのため、1Qだけ他の期より時間に余裕があることになる。 4. https://gkzz.dev/posts/mariadb-galera-cluster-docker-compose/ Sun, 12 Sep 2021 22:22:21 +0900 https://gkzz.dev/posts/mariadb-galera-cluster-docker-compose/ 1.この記事で達成したいこと Mariadb Galera ClusterをDocker Composeで構築したい 複数DBコンテナを立ち上げたい ※ Docker HubにあがっているDocker ComposeのサンプルコードではDB1台構成となっている。。。 bitnami/mariadb-galera - Docker Image | Docker Hub 無事立ち上げることができました〜 gkzz/mariadb-galera-cluster: MariaDB Galera Cluster on docker-compose 2.前提 Maria DBコンテナ4台構成とする $ make ps docker-compose ps Name Command State Ports -------------------------------------------------------------------------------------------------------------------------------------------------- db00 docker-entrypoint.sh --wsr ... Up 0.0.0.0:3306->3306/tcp, 0.0.0.0:4444->4444/tcp, 0.0.0.0:4567->4567/tcp, 0.0.0.0:4568->4568/tcp db01 docker-entrypoint.sh mysqld Up 0.0.0.0:13306->3306/tcp, 0.0.0.0:14444->4444/tcp, 0.0.0.0:14567->4567/tcp, 0.0.0.0:14568->4568/tcp db02 docker-entrypoint.sh mysqld Up 0.0.0.0:23306->3306/tcp, 0.0.0.0:24444->4444/tcp, 0.0.0.0:24567->4567/tcp, 0.0.0.0:24568->4568/tcp db03 docker-entrypoint.sh mysqld Up 0.0.0.0:33306->3306/tcp, 0.0.0.0:34444->4444/tcp, 0.0.0.0:34567->4567/tcp, 0.0.0.0:34568->4568/tcp $ 3. https://gkzz.dev/posts/accordion-menu-hugo/ Sun, 12 Sep 2021 20:16:10 +0900 https://gkzz.dev/posts/accordion-menu-hugo/ 1.この記事で達成したいこと アコーディオンメニューをHugoで作ったこのブログ(gkzz.dev)で使いたい アコーディオンとは、長い説明やサンプルコードを折りたたむようにすることで、見たいときだけクリックして見ることができるナビゲーションメニューのひとつ 参考：アコーディオンメニュー（accordion menu）とは - IT用語辞典 e-Words アコーディオンの一例 青空文庫から「こころ」の冒頭を抜粋します。 私わたくしはその人を常に先生と呼んでいた。だからここでもただ先生と書くだけで本名は打ち明けない。これは世間を憚はばかる遠慮というよりも、その方が私にとって自然だからである。私はその人の記憶を呼び起すごとに、すぐ「先生」といいたくなる。筆を執とっても心持は同じ事である。よそよそしい頭文字かしらもじなどはとても使う気にならない。 私が先生と知り合いになったのは鎌倉かまくらである。その時私はまだ若々しい書生であった。暑中休暇を利用して海水浴に行った友達からぜひ来いという端書はがきを受け取ったので、私は多少の金を工面くめんして、出掛ける事にした。私は金の工面に二に、三日さんちを費やした。 出所：https://www.aozora.gr.jp/cards/000148/files/773_14560.html 2.方針 アコーディオン（アコーディオンメニュー）をHTMLのdetailsタグとsummaryタグを使って実装する c.f. https://developer.mozilla.org/ja/docs/Web/HTML/Element/details 3.環境情報 $ grep VERSION /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" VERSION_ID="20.04" VERSION_CODENAME=focal ※ アコーディオンをHugoで使う上で求められる技術はHTML/CSSです。Hugoの推奨バージョンはドキュメントを読むかぎり、記載されていおりませんでした。私の環境では以下の2つのバージョンで動作確認をしております。ご参考までに。 $ hugo version hugo v0.88.1-5BC54738+extended linux/amd64 BuildDate=2021-09-04T09:39:19Z VendorInfo=gohugoio $ $ hugo version hugo v0.88.1-5BC54738 linux/amd64 BuildDate=2021-09-04T09:39:19Z VendorInfo=gohugoio $ 4.アコーディオンの設定方法 Hugoのテーマを使っていない場合、layouts/shortcodes/accordion.htmlを作成 e.g.：layouts/shortcodes/accordion.html `※ Markdownでアコーディオンを使う場合、layouts/shortcodes/配下に作ったアコーディオンの設定ファイル名(accordion.html)をMarkdownで指定する Hugoのテーマを使っている場合、themes//layouts/shortcodes/accordion.htmlを作成 Hugoのテーマはsubmoduleとして扱っていれば、themes/*/layouts/shortcodes配下にファイルを置いてもHugoプロジェクト（自分のブログ）のリポジトリにpushすることが難しいです。 $ vi layouts/shortcodes/accordion.html <details> <summary>{{ .Get "title" | default "e.g." }}</summary> {{ .Inner | markdownify }} </details> 設定は完了したので、Markdownから使ってみる アコーディオンの中括弧( { } )は二重で囲ってください！ 下記はMarkdownで書いてもアコーディオンが有効とならないように、あえて中括弧をひとつで囲っています。 {< accordion title="ここをクリックしてみて" >} 青空文庫から「こころ」の冒頭を抜粋します。 > 私わたくしはその人を常に先生と呼んでいた。だからここでもただ先生と書くだけで本名は打ち明けない。これは世間を憚はばかる遠慮というよりも、その方が私にとって自然だからである。私はその人の記憶を呼び起すごとに、すぐ「先生」といいたくなる。筆を執とっても心持は同じ事である。よそよそしい頭文字かしらもじなどはとても使う気にならない。 >　私が先生と知り合いになったのは鎌倉かまくらである。その時私はまだ若々しい書生であった。暑中休暇を利用して海水浴に行った友達からぜひ来いという端書はがきを受け取ったので、私は多少の金を工面くめんして、出掛ける事にした。私は金の工面に二に、三日さんちを費やした。 出所：https://www. https://gkzz.dev/posts/google-analytics-v4-implementation-in-hugo/ Sun, 22 Aug 2021 13:45:46 +0900 https://gkzz.dev/posts/google-analytics-v4-implementation-in-hugo/ 1.この記事で達成したいこと Google Analytics 4から採用された　Measurement ID(e.g. G-00000XXXXX) の設定をHugoでしたい Tracking ID(e.g. UA-000000-2)を使ってGoogle Analyticsの設定をする方法は多く紹介されている Measurement IDの解説記事はあっても修正するファイルのパスが間違っていたりしていたので書こうと思った ※Google Analytics v4を使っている場合でも、Measurement IDとTracking ID(e.g. UA-000000-2)を併用することはできる。 ※詳細は「おまけ.Google Search Consoleを使うためにTracking IDも設定する」で書いているので最後まで読んでほしい。 2.前提 Measurement IDの取得方法については解説せず、以下の記事に譲りたい What happened to my Tracking ID? - Analytics Help　3.設定方法 以下を参考に進める Installation · adityatelange/hugo-PaperMod Wiki Google Analytics 4 Implementation in Hugo config.ymlを修正 パスは/path/to/${BLOG_DIR}/config.yml params: # Hugoにおける"production"の意味合いは、Hugoで立ち上げているウェブサイトがググって見つけることができるぐらいのニュアンス # 余談だが、ローカルで"Hugo server -D"を実行した場合のenvは"development" env: production googleAnalyticsID: <G-00000XXXXX> analytics-gtag.htmlを以下のパスに新たに作成 /path/to/${BLOG_DIR}/layouts/partials/analytics-gtag.html $ mkdir -p layouts/partials $ touch layouts/partials/analytics-gtag.html <! https://gkzz.dev/posts/add-custom-domain-firebase-hosting/ Fri, 20 Aug 2021 20:50:15 +0900 https://gkzz.dev/posts/add-custom-domain-firebase-hosting/ この記事で達成したいこと 購入した独自ドメインのサブドメインをFirebase Hostingで使いたい 前提 カスタムドメインはgkzz.devとし、購入先はGoogle Domains Firebase Hostingではgkzz.devのサブドメインであるblogs.gkzz.devを指定する 設定がうまくできず、Firebase Hostingではgkzz.devを指定するように変更 blog.gkzz.devにアクセスが飛んできた場合はgkzz.devへリダイレクトするようにした 以下のFirebaseのドキュメントを参考に進める。 Connect a custom domain | Firebase Firebase Hostingの画面でカスタムドメインを登録 https://console.firebase.google.com からFirebaseのコンソール画面へログイン Firebase Hostingで使うプロジェクトを選択するか、新規に作成 ここでは既存のプロジェクトを選択している 画面左の Hosting をクリック Add custom domain をクリックするとポップアップ画面が表示される ポップアップ画面から Qucik setup 、 Aレコード を選択したら、デプロイ先となるカスタムドメイン名を入力し、IPアドレス をコピーしておく https://domains.google.com の画面左側の DNS をクリック Custom recordsにて左からデプロイしたい カスタムドメイン名 、A 、先ほどコピーした IPアドレス を入力していく 以上で、Firebase HostingとGoogle Domainで購入したカスタムドメインとの設定は完了した。 ※接続が確認できた画面は、自分のブログの画面しか確認できていない。Firebase HostingとGoogle Domainで購入したカスタムドメインとの設定のみした場合、どういう画面になるのかサンプルの資料はない。。 P.S. TXTレコードはGoogle Domainsで登録することなく終わったけど。。 TXTレコードはGoogle Domainsで登録することなく、Firebase HostingとGoogle Domainsで購入したカスタムドメインとの設定が終わってしまった。 Firebase Hosting では、ドメインの所有者であることを証明し、サイトの SSL 証明書の割り当てと更新を Firebase で承認するために、この TXT レコードを常に DNS 設定で保持する必要があります。 https://gkzz.dev/posts/deploy-hugo-on-firebase-hosting-via-github-actions/ Fri, 20 Aug 2021 18:36:16 +0900 https://gkzz.dev/posts/deploy-hugo-on-firebase-hosting-via-github-actions/ 1.この記事で達成したいこと 独自ドメインのHugoプロジェクトのブログを作ってみたい そのブログがこれ！ –> https://gkzz.dev ブログはHugo + Firebase Hostingで構成し、デプロイはGithub Actionsで自動化したい これまでローカルからデプロイという運用対処としていた、、 ※Hugoのインストール手順はこちらに書いてあるのでどうぞ。 最新のHugoをインストールする方法とHugoの設定ファイルをtomlフォーマット以外にする方法 | gkzz.dev 2.前提 HugoのテーマはPaperMod Firebase HostingとGoogle Domainsで購入したカスタムドメインを接続する方法は以下のとおり実施している Firebase HostingとGoogle Domainsで購入したカスタムドメインを接続する | gkzz.dev ドメインはgkzz.devとする 3.環境情報 $ grep Ubuntu /etc/os-release NAME="Ubuntu" PRETTY_NAME="Ubuntu 20.04.2 LTS" $ hugo version hugo v0.87.0-B0C541E4 linux/amd64 BuildDate=2021-08-03T10:57:28Z VendorInfo=gohugoio $ 4.PaperModの導入 以下のPaperModのインストール手順を参考に進める https://github.com/adityatelange/hugo-PaperMod/wiki/Installation#method-2 ※ https://github.com/adityatelange/hugo-PaperMod をサブモジュールとする点がミソ！ 「6.GitHub Actionsの設定ファイル(.github/workflows/*.yml)を用意」で活きてくる！ $ hugo new site ${BLOG_DIR} -f yml $ cd ${BLOG_DIR} $ git init $ git submodule add --depth=1 https://github. https://gkzz.dev/posts/hugo-installation-on-ubuntu/ Fri, 20 Aug 2021 01:37:00 +0900 https://gkzz.dev/posts/hugo-installation-on-ubuntu/ この記事で解決したい課題 Ubuntu上で最新のHugoをインストールしたい Hugoの設定ファイルをtomlフォーマット以外にしたい 環境情報 $ grep Ubuntu /etc/os-release NAME="Ubuntu" PRETTY_NAME="Ubuntu 20.04.2 LTS" $ hugo version hugo v0.87.0-B0C541E4 linux/amd64 BuildDate=2021-08-03T10:57:28Z VendorInfo=gohugoio $ 課題1. Ubuntu上で最新のHugoをインストールしたい 以下のHugoの初期設定手順に従ってapt-getでインストールをおこなうと、最新版ではないHugoがインストールされてしまう https://gohugo.io/getting-started/installing#debian-and-ubuntu apt-getでインストールしたHugoのバージョン $ hugo version Hugo Static Site Generator v0.68.3/extended linux/amd64 BuildDate: 2020-03-25T06:15:45Z どうやったか？ 以下のHugoのリリースページからHugoのパッケージをダウンロードし、dpkgコマンドでインストール https://github.com/gohugoio/hugo/releases 今回は現時点で最新のv0.87.0をインストールする unameコマンドで64bitか32bitか確認もしておく $ sudo uname -m x86_64 $ wget https://github.com/gohugoio/hugo/releases/download/v0.87.0/hugo_0.87.0_Linux-64bit.deb $ sudo dpkg -i hugo_0.87.0_Linux-64bit.deb Hugoのバージョンはv0.87.0であることが確認できた $ hugo version hugo v0.87.0-B0C541E4 linux/amd64 BuildDate=2021-08-03T10:57:28Z VendorInfo=gohugoio Hugoのバージョンアップグレード方法 引き上げたいバージョンのパッケージをwgetで取ってきてからdpkgコマンドでインストールするだけ！ $ wget https://github.com/gohugoio/hugo/releases/download/v0.88.1/hugo_extended_0.88.1_Linux-64bit.deb $ sudo dpkg -i hugo_extended_0. https://gkzz.dev/posts/my-first-post/ Thu, 19 Aug 2021 15:01:29 +0900 https://gkzz.dev/posts/my-first-post/ こちらでもブログを頑張ってみようと思います:) https://gkzz.dev/policy/ Mon, 01 Jan 0001 00:00:00 +0000 https://gkzz.dev/policy/ Our Policy https://gkzz.dev/profile/ Mon, 01 Jan 0001 00:00:00 +0000 https://gkzz.dev/profile/ Profile