はてなブックマーク

本記事公開時点のMCPサーバー（v0.1.0）から、早速破壊的変更を適用したv0.2.0をリリースしています。もしご利用頂いた方がいらっしゃればアップデートをお願いします。（2025.06.18追記） 本記事の要旨 Claude Code などの LLM を活用したコーディングエージェント(以下、エージェントと呼びます)の利用が急速に進んでいますね。私も機会があるごとに利用してみてはいますが、エージェントが学習データに引っ張られて、新しい言語機能や標準パッケージを使ってくれないことがあるという挙動には歯痒い思いをしていました。（そして結局自分で書き直す） こちらのスライドにもあるように、エージェントには最新知識をインプットしてあげることが必要ですね。 あるいは静的解析からのLint&Formatが市民権を得ている言語の場合は、古い言語機能や標準パッケージの利用を検出して警告することも有用で

この記事は何 ローカル環境でAWSサービスをエミュレートできるLocalStack、便利ですよね。 本当のAWS環境を使わないようにすることで、セキュリティの担保(詳細は後述)やうっかりとした事故の防止を実現しつつ、アプリケーションのコード内で無用なモックを用意する必要もなくなります。 LocalStackの活用方法の様々な記事がありますが、Go言語での開発において、1:ローカル開発環境用途、2:テスト時の使い捨て用途の両方をまとめて整理した記事は見かけませんでした。本記事では両者を整理して、スッとLocalStackを活用できることを目的とします。 具体的に取り扱う内容は以下の通りです。 ローカル開発環境：Go言語で書いたアプリケーションが動くアプリコンテナと、LocalStackコンテナ間で通信する環境を構築します。 テスト：testcontainers-goを使ってLocalStac

この記事は何 Go1.23から正式に導入されるrange over func、Go1.22で実験的に導入された頃から数えると、結構な時間が経ちましたね。既に慣れ親しんでいる方も多くいらっしゃると思いますが、恥ずかしながら私はまだです…。 お作法を理解できていないのが原因かと思います。 これではいけない！と、最近、一念発起してrange over funcに向き合ってみたので、私と同じようになかなか慣れられない方向けに記事を書きたいと思います。 この記事で扱うこと、扱わないこと range over funcの導入に至る背景や解決したい課題に関する説明は行いません。 range over funcを使ってみよう！と意気込めるように、最低限押さえておきたいポイントを筆者の主観ベースでまとめた内容を紹介します。本機能の設計意図や言語仕様などを完璧に汲んだ説明は目指しておらず、あくまで「使い始める

本記事の概要 Zennで読むことのできるGoの日時の扱いについては、@hsaki さんの記事が大変分かりやすいですよね。 こちらでも解説されてはいるのですが、混乱しやすいポイントだけに焦点を当てた記事も需要があるかな？と思い、私の頭の整理もかねて記事を書きます。 本記事で着目するのは、「Parseする日時文字列にタイムゾーン名だけ(例：JST)がある時、得られるtime.Time型の時間オフセットはどうなるか？」という点です。同じようにハマったことがある人は多いかな、と思うので、「あーあるある」ぐらいで読んでいただければと思います。 本記事の対象読者 Goの基本的な日時の扱い方は知っている 本記事の結論 タイムゾーン名だけでは時間オフセットは適切に設定されない。実行環境のタイムゾーンへの依存がある。 解決策は環境変数TZの設定かParseInLocationを使うことだが、実行環境に必要な

23/9/21追記：この記事を読む前に ついにGoチームから、プロジェクト構成に関するガイドが公開されました！ 本記事を読んでくださることも大変嬉しいですが、ぜひこちらのガイドもご一読ください！ この記事は何 Go言語を書いたことがある方も、興味はあるけど触ったことがない方もこんにちは。 Goに限った話ではないと思いますが、ガリガリコードを書いていて、あるタイミングで気になるのがプロジェクト構成（ここではディレクトリ構成の意図）ではないでしょうか？ それを裏付けるかのように、Go界隈では以下のリポジトリが話題に上がることがあります。Star数すごいですね😇 リポジトリ名から公式感が漂いますが、そういう訳ではないのがミソです。 こちらのリポジトリ冒頭にも記載されていますが、次の点に留意する必要があるでしょう。 これは、Goアプリケーションプロジェクトの基本的なレイアウトです。これは、コアと