読み込み中...
Recent content in Posts on repl.info
通知を受け取るには、ホーム画面に追加してから購読してください。
まとめ PRごとにプレビュー環境を構築する仕組みをEKSで実装した プレビュー環境のコンテナイメージにはアプリケーションのソースコードを含めず、コンテナ起動時にGitHubからクローンするようにした コンテナの起動後は定期的にブランチをポーリングし、 git pull するようにした。 pnpn dev のホットリロードと組み合わせることでブランチにプッシュしてから30秒程度でプレビュー環境に反映されるようにした プレビュー環境をどう構築するか PRごとのプレビュー環境構築の仕組みは様々なチームがそれぞれ実装している。mirage-ecs のようにOSS化している事例もある。僕が今所属しているフライルでもプレビュー環境がほしくなり、最初はECSベースで実装した。 ECSベースの初代プレビュー環境はCDKとecspressoを組み合わせたものである。GitHub Actionsからシェルスク…
よく参照するAWS上のリソースをパパッと確認できるようにTUIツールを作った。 https://github.com/takaishi/aws-tui github.com こういうツールはたぶん山のようにあるんだろうけど、自分が使う分を自分が使いやすいように作っておこうや、ってことで。
もちろん全く見ないわけではなく、例えばレシピ動画を単発で見たりはするのだが、空き時間に延々とスワイプしてしまうような状態ではなくなった。無価値な時間だな〜と自覚はもちつつも、ついやってしまっていたので見なくなって本当によかったと思う。 結論としては、Youtubeアプリの時間管理機能を使ってショートフィードの上限を0分にしたことで見ることを止められた。自分の場合はTikTokやInstagramのようなYoutube以外のプラットフォームでショート動画を見ることがなかったので、Youtubeアプリさえ対策できれば見る導線を潰すことができた。 ショートフィードの上限を0分にすると、1つショート動画を見た後スワイプしようとすると上限に到達した旨が表示される。無視して見続けることもできるのだけど、もともと見ないようにしたいと思っていたので防波堤になってくれて、すっかり見なくなった。 ショート動画…
もちろん全く見ないわけではなく、例えばレシピ動画を単発で見たりはするのだが、空き時間に延々とスワイプしてしまうような状態ではなくなった。無価値な時間だな〜と自覚はもちつつも、ついやってしまっていたので見なくなって本当によかったと思う。 結論としては、Youtubeアプリの時間管理機能を使ってショートフィードの上限を0分にしたことで見ることを止められた。自分の場合はTikTokやInstagramのようなYoutube以外のプラットフォームでショート動画を見ることがなかったので、Youtubeアプリさえ対策できれば見る導線を潰すことができた。 ショートフィードの上限を0分にすると、1つショート動画を見た後スワイプしようとすると上限に到達した旨が表示される。無視して見続けることもできるのだけど、もともと見ないようにしたいと思っていたので防波堤になってくれて、すっかり見なくなった。 ショート動画を見なくなったからといって無価値な時間を過ごすことがなくなったかというと別にそんなことはないのだが、止めたいな〜と思っていたことを止められたという点ではいい経験になった。これからもショート動画からは距離をとって生活したい。
AWS上で動かすアプリケーションを開発していると、どうしてもアプリケーションが利用するAWSのAPIを利用する権限を付与し忘れ、動かしてみたら権限エラーになることがある。単純に付与し忘れていることもあるし、権限が必要と認識しておらず思わぬエラーで気づくこともある。常々どうにかならないだろうかと思っていたが、GitHub Actions Workflowでチェックする仕組み iam-policy-checker を作ったので紹介する。 iam-policy-checkerはTypeScriptで実装した内製ツールで、ECSタスク定義の設定ファイルからエントリーポイントを検出し、コードを静的解析して呼び出されるAWSのAPIを取得し、AWS上のIAMロールでそのAPIがアクションとして許可されているかをチェックするもの。チェックできていない場合は不足アクションとして出力し、PullReques…
AWS上で動かすアプリケーションを開発していると、どうしてもアプリケーションが利用するAWSのAPIを利用する権限を付与し忘れ、動かしてみたら権限エラーになることがある。単純に付与し忘れていることもあるし、権限が必要と認識しておらず思わぬエラーで気づくこともある。常々どうにかならないだろうかと思っていたが、GitHub Actions Workflowでチェックする仕組み iam-policy-checker を作ったので紹介する。 iam-policy-checkerはTypeScriptで実装した内製ツールで、ECSタスク定義の設定ファイルからエントリーポイントを検出し、コードを静的解析して呼び出されるAWSのAPIを取得し、AWS上のIAMロールでそのAPIがアクションとして許可されているかをチェックするもの。チェックできていない場合は不足アクションとして出力し、PullRequestのチェックを落とすようになっている。これにより、デプロイ前に少なくともアクションを許可できているかどうかを確認できるというわけである。また、実際には呼び出していない権限のチェックも可能にして過剰分・不足分の両方検出できるようにした。 特徴 主要な特徴を3つ紹介する。 可能な限り呼び出されるコードをたどることで高い精度を実現する AWS Service Referenceを使ってAPI呼び出しから許可すべきIAMのアクションを解決する AWS Service Referenceからはわからない暗黙の依存を管理可能にする 1. 可能な限り呼び出されるコードをたどることで高い精度を実現する tree-sitterや自前のパーサーを使うのではなく、TypeScriptの型チェッカーを使うようにしたり、動的dispatchを追跡可能にしたり、SDKの実装内部も追跡したり、NodeJSのワーカースレッドも追跡したりとできる限り呼び出されるコードを追跡することで呼び出す可能性のあるAPIの網羅度を上げることができた。解析対象となるECSタスク定義も自動取得することで検査漏れがないようにしてある。 2. AWS Service Referenceを使ってAPI呼び出しから許可すべきIAMのアクションを解決する SDKの利用からIAMポリシーで許可するアクションをどう解決すればいいか最初悩んだが、AWS Service Referenceというものが公開されており、これを使うことで解決できることがわかった。定期的に更新する仕組みも作ることで、今後の変更にも追従できるようになった。 https://docs.aws.amazon.com/ja_jp/service-authorization/latest/reference/service-reference.html 3. AWS Service Referenceからはわからない暗黙の依存を管理可能にする 運用を始めて少ししてから気づいたのだが、AWS Service Referenceで解決できない暗黙の依存関係も存在していることがわかった。 aws-marketplace:Subscribe と aws-marketplace:ViewSubscriptions がそれで、AWS Marketplace経由で配信されるサードパーティのモデルを初めて実行する際にBedrockが裏側で必要としているアクション。これはAWS Service Referenceには記載されていないため、AWS Service Referenceとは別口で管理して検出可能にした。こういう例外パターンに素早く対応できるのは内製ツールの強みだと思う。 デメリット・制約 いくつかデメリットや制約といえることもある。 言語やSDKが固定である リソースレベルの検出ができない 検出パターンなど、ハードコードしている箇所がいくつかある 言語やSDKが固定である NodeJS x TypeScript x AWS SDK v3に特化した作りなので、例えばGoで書いたツールを同じリポジトリで管理する場合は使えない。 リソースレベルの検出ができない どのようなリソースに対してアクションを許可するか、までは検出できない。例えばS3バケットへのアクセスについては、バケット名がコード上に存在していないためIAM ポリシーを書く際にちゃんと許可する必要がある。 検出パターンなど、ハードコードしている箇所がいくつかある ワーカー実行や aws-marketplace:Subscribe の依存関係など、例外的な処理がいくつかある。少しやり方が変わったり、ハードコードされていない依存関係があった場合はデプロイしてみて初めてエラーに気づく可能性がある。とはいえ、Staging環境でのテストで気づけるはずなので大きな問題とは思っていない。 iam-policy-autopilotじゃだめか 実装時には存在に気づいていなかったが、iam-policy-autopilotという目的が似ているツールがある。このツールを使うとコードからIAMポリシーを生成できるので、生成したポリシーの自動適用まで可能かもしれない。TypeScript以外をサポートしているという点から、別言語で似たような需要が生じた場合は試してみたい。 まとめ 今回、アプリケーションが利用するAWS APIの権限付与漏れを事前検知する仕組みを作った。結構作業のブロッカーになることが多いし、時間がない時に権限エラーが発生すると非常にストレスなので事前に気づけるようにできたのはいい改善だと思う。皆さんも是非仕組みを作ってみてください。 筆者が所属する株式会社フライルではソフトウェアエンジニアを募集しています。このような改善活動に関心がある方はご連絡ください。 SREやクラウドインフラ、プラットフォームエンジニアリングをやるポジションはこちら： ソフトウェアエンジニア（SRE/インフラ/プラットフォーム） - 株式会社フライル 株式会社フライルでは現在ソフトウェアエンジニア（SRE/インフラ/プラットフォーム）を募集しています。 株式会社フライル .ogp-card { display: flex; border: 1px solid var(--border-color, #e1e4e8); border-radius: 8px; overflow: hidden; text-decoration: none; color: inherit; margin: 1.5em 0; transition: box-shadow 0.2s ease, transform 0.2s ease; } .ogp-card:hover { box-shadow: 0 2px 8px rgba(0, 0, 0, 0.12); transform: translateY(-1px); } .ogp-card-thumbnail { flex: 0 0 200px; max-width: 200px; overflow: hidden; } .ogp-card-thumbnail img { width: 100%; height: 100%; object-fit: contain; background: #f6f8fa; display: block; margin: 0; } .ogp-card-body { flex: 1; padding: 12px 16px; min-width: 0; display: flex; flex-direction: column; justify-content: center; } .ogp-card-title { font-weight: 600; font-size: 0.95em; overflow: hidden; text-overflow: ellipsis; display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; } .ogp-card-description { font-size: 0.85em; opacity: 0.75; margin-top: 4px; overflow: hidden; text-overflow: ellipsis; display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; } .ogp-card-url { font-size: 0.75em; opacity: 0.6; margin-top: 8px; } @media (max-width: 480px) { .ogp-card { flex-direction: column; } .ogp-card-thumbnail { flex: none; max-width: 100%; height: 160px; } } Webアプリケーションをフルサイクルで開発したいポジションはこちら：
Claude CodeやCodex、その他様々なコーディングエージェントがしのぎを削る今日この頃、みなさんはソフトウェアを作っていますでしょうか。僕はこれまでの人生の中で、仕事でだけではなくプライベートでも一番作っているように思います。世は正に大ソフトウェアDIY時代。 とはいえ別にソフトウェアをDIYするというのはコーディングエージェント普及後に生まれた概念ではありません。昔から自分で使うソフトウェアを自分で作っている人たちは大勢いたし、それを配布する人もしない人もいたでしょう。自分も数えるほどですが自分で作ったソフトウェアをGitHubで公開していました。それでもコーディングエージェントによってハードルが下がったのは確かです。 特に、不慣れな領域での開発は格段にやりやすくなりました。自分の場合は例えばmacOSのネイティブアプリケーションをちょこちょこ作っていて、自分だけがローカルで使…
Claude CodeやCodex、その他様々なコーディングエージェントがしのぎを削る今日この頃、みなさんはソフトウェアを作っていますでしょうか。僕はこれまでの人生の中で、仕事でだけではなくプライベートでも一番作っているように思います。世は正に大ソフトウェアDIY時代。 とはいえ別にソフトウェアをDIYするというのはコーディングエージェント普及後に生まれた概念ではありません。昔から自分で使うソフトウェアを自分で作っている人たちは大勢いたし、それを配布する人もしない人もいたでしょう。自分も数えるほどですが自分で作ったソフトウェアをGitHubで公開していました。それでもコーディングエージェントによってハードルが下がったのは確かです。 特に、不慣れな領域での開発は格段にやりやすくなりました。自分の場合は例えばmacOSのネイティブアプリケーションをちょこちょこ作っていて、自分だけがローカルで使うだけのアプリケーションを作っています。ネイティブアプリケーションの作法も知らないし、Swiftも全く書けません。いわゆるバイブコーディングで作っていますが、自分が使う分には十分実用的なものが作れるようになってきました。 知らない領域でバイブコーディングしてみて思ったのは、ある程度作ることはできても細部を詰めて品質を上げるのは結構難しいということです。例えば、僕はPodcastの編集アプリケーションを作っています。これまでは別のアプリケーションで編集していたのでそれをイメージして作ってみているのですが、音に関する知識やネイティブアプリのUI・UXに関する知識がないと難しい。編集時には音声に対していろいろなエフェクトをかけるのですが、正しくエフェクトがかけられているのかを判断するにはそのエフェクトについての知識が必要です。 また、UIやUXについても適切に実装するには最低でも名称を知っている必要がある。さらに、これまで使ってきたアプリケーションが当たり前に備えていた機能についても一つ一つ実装する必要があります。例えば右クリック時のメニューやドラッグ＆ドロップ。これも全部指示する必要があります。商用のアプリケーションはすごい、と感じました。指示の仕方が悪いのかもしれませんが、逆にどう指示すれば短期間で高品質なネイティブアプリが作れるのかまだ分かりません。SKILLなどでカバーすれば可能かもしれませんが、今は知識がある方が効率的でしょう。 もう一つは、自分が欲しいものを具体的に言葉にすることも結構難しいなということです。人によるでしょうが、僕はどちらかというとソフトウェアエンジニアの中でも苦手な方じゃないかと思っています。バイブコーディングでソフトウェアを作るとしても、まず自分が困っていることや欲しいアプリがあることを認識し、それを解決するにはどういうものがあるといいのかを言葉にできないといけないでしょう。少なくとも2026年7月時点では。それでも、言葉にできるならそこから先はAIのサポートを受けることができるのでとてもいい時代だと思います。メタ認知力と言語化力が高い人はかなりエージェンティックコーディングを活用できているんじゃないでしょうか。 ここまで話したことはソフトウェアに限らず、物理的なDIYでも同じだなと感じています。普段生活していて、家の中をこう変えたらちょっと暮らしが良くなるんじゃないかという発想がなければDIYに進めないし、DIYするにも道具の使い方は多少分かっていないといけない。ホームセンターや100均でちょっとしたアイテムを買うことがツールやアプリを買って暮らしを改善することに相当するとすれば、自分用のソフトウェアを作ることはまさにソフトウェアのDIYだなと思います。物理DIYでも強度や安全性などを考慮すると学ぶことはたくさんあるだろうし、それはソフトウェアでも同様です。コーディングエージェントがその敷居を下げて様々な人がソフトウェア作りに挑戦し楽しめるようになったのはとてもいいなと思います。 1年後ソフトウェア開発がどうなっているかわかりませんが、2026年7月時点の自分の状況を記録する意味も込めて書いてみました。皆さんはどうですか？
Terraformのプラクティスの一つに、stateを分割するというものがある。分割の粒度についてもいろいろあるが、分割することでライフサイクルや責務を分けたり、planの時間を短縮できる効果がある。しかし、state分割には一つ困ることがある。それが data "terraform_remote_state" である。 data "terraform_remote_state" を使うと他stateのoutputを参照し、利用することができる。例えば、別stateでネットワーク系のリソースを管理している際にvpc idやsubnet idなどを参照することは比較的多いだろう。しかし、このような別stateを参照する変更において、state Aとstate Bを同時に変更しないといけないような場合、いくつかの問題が生じることがある。 新しくコンポーネントを作る際、stateも他とは分離して新規作成する。そして、別コンポーネントから新規作成するstateを参照することがある。これらの変更を1つのPullRequestで行おうとすると、コード上は問題ないように見えるがplanやapplyはうまく動かない。これは参照先のremote stateがplan時にはまだ存在しないためである。 remote stateは既にあるが、参照したい値がoutputとして存在しないこともあるだろう。outputの追加と参照を1つのPullRequestで行おうとすると、コード上は問題ないように見えるがplanやapplyがうまく動かないことがある。 outputがない場合ダミーの値を使うことでplanを通すことはできるが、apply時にエラーになるケースもある。これはapply時にplanファイルを利用する場合にのみ発生する（はず）。ダミーの値を使ったりした場合、planファイルではダミーの値が使われてCIが見た目上は通過する。しかしapply時には正しい値ではないため失敗してしまう、というわけだ。 このような問題を避けるにはPullRequestを分け、依存先PRを先にapplyする必要がある。とはいえルールとして設定しても覚えていられないし、うっかりマージすることもある。できればCIで検知してPullRequestの分割を強制したい。ということでチェック機構を作った。 Terraformの静的検査ツールとしてはtflintやcheckovなどいくつかのものが利用できる。もちろんこれらのツールも使っているが、今回検証したいのはクロスディレクトリの整合性である。また、S3上のstateを参照したりもするため、tflintなどとは相性が悪いだろうと判断し、単独ツールとして実装した。 ツールは https://github.com/takaishi/tfstateref-lint として公開してある。remote state関係で困っている人はぜひ試してみてほしい。 GitHub - takaishi/tfstateref-lint Contribute to takaishi/tfstateref-lint development by creating an account on GitHub. GitHub .ogp-card { display: flex; border: 1px solid var(--border-color, #e1e4e8); border-radius: 8px; overflow: hidden; text-decoration: none; color: inherit; margin: 1.5em 0; transition: box-shadow 0.2s ease, transform 0.2s ease; } .ogp-card:hover { box-shadow: 0 2px 8px rgba(0, 0, 0, 0.12); transform: translateY(-1px); } .ogp-card-thumbnail { flex: 0 0 200px; max-width: 200px; overflow: hidden; } .ogp-card-thumbnail img { width: 100%; height: 100%; object-fit: contain; background: #f6f8fa; display: block; margin: 0; } .ogp-card-body { flex: 1; padding: 12px 16px; min-width: 0; display: flex; flex-direction: column; justify-content: center; } .ogp-card-title { font-weight: 600; font-size: 0.95em; overflow: hidden; text-overflow: ellipsis; display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; } .ogp-card-description { font-size: 0.85em; opacity: 0.75; margin-top: 4px; overflow: hidden; text-overflow: ellipsis; display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; } .ogp-card-url { font-size: 0.75em; opacity: 0.6; margin-top: 8px; } @media (max-width: 480px) { .ogp-card { flex-direction: column; } .ogp-card-thumbnail { flex: none; max-width: 100%; height: 160px; } } 筆者が所属する株式会社フライルではソフトウェアエンジニアを募集しています。
Terraformのプラクティスの一つに、stateを分割するというものがある。分割の粒度についてもいろいろあるが、分割することでライフサイクルや責務を分けたり、planの時間を短縮できる効果がある。しかし、state分割には一つ困ることがある。それが data "terraform_remote_state" である。 data "terraform_remote_state" を使うと他stateのoutputを参照し、利用することができる。例えば、別stateでネットワーク系のリソースを管理している際にvpc idやsubnet idなどを参照することは比較的多いだろう。しかし、このような別stateを参照する変更において、state Aとstate Bを同時に変更しないといけないような場合、いくつかの問題が生じることがある。 新しくコンポーネントを作る際、stateも他とは分離して…
