はてなブックマーク

「AIは増幅器である」とよく言われます。着想や判断の材料を渡すと、拡張し、構造化し、言語化して返してくれます。 増幅された出力は流暢で、自信に満ちていることが多く、そのまま受け取るのは楽です。ただ、その楽さの先で、考えの主導権を渡してしまうと、大切な意思と意図が失われていく感覚を持っています。 このテーマを自分でも整理したくなったきっかけは、及川卓也さんの記事でした。認知的降伏と相互増幅について、実感に近い形で書かれていて強く感銘を受けました。 takoratta.hatenablog.com さらに調べていくと、概念の芯は、Addy Osmani の Cognitive Surrender で語られていました。この記事もとてつもなく良かったです。以下は、それを踏まえて「増幅器で終わらせない」とは何かを自分なりにまとめてみたものです。 addyosmani.com 外部委託と降伏は違う 特

『Good Code, Bad Code』はコード品質や設計の基礎を学べる書籍です。AIによってコード生成が容易になった現在でも、設計・モジュール分割・エラーハンドリングといった考え方は依然として重要です。本記事では特にAI時代でも価値が残る内容を紹介します。 Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考 作者:Tom Long秀和システムAmazon はじめに 最初にこの本を読んだのはもう2年半前、、、早い、、、。当時も紹介ブログを書いています。 paper2.hatenablog.com 最近AIがかなり色々できるようになったとはいえ、最終的に作っているものはソフトウェアであり、それを運用・拡張・維持していくにはそれなりの専門知識が必要です。 例えばエラーハンドリングは良い例だと思います。初学者は「システムがエラーにならないように作れば良

GitHub Actions OpenTelemetryというGitHub Actionを作っています。GitHub Actionsのワークフロー実行データをOpenTelemetryのトレースとメトリクスとして出力するActionです。 このActionにE2Eテストを入れたので、そのテスト設計について書きます。やっていることは単純で、ActionがOTLPエンドポイントに送ったトレースとメトリクスのJSONをまるっとキャプチャして、期待値と比較しています。 ユニットテストだけだと何が怖いか E2Eテストの全体設計 JSONで丸ごと比較する Collectorでデータをキャプチャする jqで動的な値を正規化する 期待値JSONをgitで管理する まとめ ユニットテストだけだと何が怖いか このActionはGitHub APIからワークフローの実行データを取ってきて、そこからトレースとメト

「最強のエンジニアになるための話し方の教科書」を読み、過去の経験も踏まえてコミュニケーションについて改めて考える良い機会になりました。 本記事では、書籍の内容を引用しつつ、論理的な正しさだけでは仕事がうまく進まない場面で私が感じたことを整理してみます。 特に過去の私のように「論理的で正しいことが全て」と考えがちな方にとって、何かしらの気付きにつながれば幸いです。 最強のエンジニアになるための話し方の教科書 作者:亀山 雅司マネジメント社Amazon はじめに 会話の目的は「勝つこと」ではない 「敵」から「仲間」へ - 共に解決を目指す姿勢 信頼を築く「自爆」の姿勢 まとめ はじめに これからの時代、技術力だけでエンジニアは生きていけるのでしょうか。 いいえ、「技術の価値を伝える」ことができなければ、エンジニアは技術で収入を得て生きていくことはできません。 ソフトウェア業界でも生成AIの進化

KiroはAmazonが提供する仕様駆動型開発をAIで支援するIDEです。 生成AIに適切なコンテキストを渡す仕組みを作りたいけど、あまり手を出せていない人は多いのではないでしょうか。私もその一人で、そんな私にとってKiroはかなり衝撃的なプロダクトでした。 色々学ばせてもらった感謝の気持ちを込めて、Kiroの良いところをお伝えしたいと思います。 Kiroが提供するコアソリューション 構造化されたドキュメント管理 高速な試行サイクルの実現 良かった体験 実装時の設計変更提案 専用タブによる効率的なドキュメント参照 タスク管理と変更履歴の追跡 開発プロセスの可視化 コンテキスト管理の最適化 現時点での制約 雑感 料金モデル コアソリューションを他のサービスに実現される可能性 まとめ Kiroが提供するコアソリューション 仕様駆動開発（spec-driven development）はKiro

GitHub Actionsはワークフロー全体の実行時間や各ステップの詳細な可視化、変更による効果測定を行うには工夫が必要となります。この記事では、OpenTelemetryを活用してGitHub Actionsの実行結果をトレースとメトリクスの形で収集するGitHub Actions OpenTelemetryを紹介します。どのステップに時間がかかっているのか、改善施策の効果がどの程度あったのかを把握しやすくなるため、ワークフローの継続的な改善を目指す方に役立ちます。 Trace Sample (Jaeger) 1. GitHub Actionsにおける課題 1-1. ワークフローの詳細を可視化する方法が提供されていない 1-2. ワークフローの変更による影響を分析しづらい 2. GitHub Actions OpenTelemetryとは 2-1. 概要と主な機能 2-2. OpenT

google-github-actions/authとは Direct Workload Identity Federationとは 利用方法 Workload Identity Poolを作成する Workload Identity ProviderをPool内に作成する 検証用のシークレットを作成する Workload Identity Poolに権限を付与する ワークフローを作成する まとめ google-github-actions/authとは Google Cloudの認証を実施するGitHub Actionsとしてgoogle-github-actions/authが提供されています。Actions上でgcloudコマンドなどを利用する前に認証で利用します。 このActionsではGoogle Cloud Service Account Key JSONによる認証とWorkl

Cloud Runで新しいツールなどを検証する際に修正してはデプロイを待ち、再検証というループを回したことはあると思います。 Kubernetesのkubectl execコマンドやdebugコマンドでコンテナ上で直接作業したいな〜と思うことありますよね。 そこでCloud Run上でシェルを実行し、検証などをしやすくする方法を紹介します。上記のexecやdebugコマンドほど便利ではないので定常運用には向かないと思いますが、Cloud Run上で色々検証したい時に役立つと思います。リポジトリはこちらです。 github.com 仕組み SSHのようにこちらからCloud Runに向けて接続をすることができないので、netcat（nc）を用いてCloud Runからこちら側に向けて接続をしてもらいます。netcatはネットワーク管理およびデバッグのための多目的ツールです。特定のポートで接続

SREのプラクティス導入による文化面の変化などを踏まえ、「火消し」「門番」「パートナー」「触媒」の4フェーズを紹介します。自チームの現状把握と今後の方向性を検討する上での材料になったら幸いです。*1 火消しフェーズ 火消しフェーズ 初期段階では開発チームが機能開発のタスク（Feature Task）に注力し、サービスに必要な信頼性に関するタスク（Reliability Task）が対応領域に含まれないことがあります。このフェーズではSREチームが火消し部隊としてReliability Taskを巻き取り、信頼性の向上に努めます。コラボレーションなどは考慮されず、火消しが最優先となります。そのため、Reliability TaskはSREチームだけが処理するものとなっていき、後の門番フェーズに突入します。 門番フェーズ 門番フェーズ 信頼性に関するタスクの大部分をSREチームが対応しているフ