From Spring Boot 2 to Spring Boot 3 with Java 22 and Jakarta EE
よいパッケージ性の測り方 結合度を計測する コードの良さを測る指標として循環的複雑度などがありますがどちらかというと単一ファイルの指標で、アーキテクチャの良さを測る指標として不足に感じました。 マイクロサービスでもモジュラーモノリスでもマルチモジュールの境界をどううまく引くかは悩みどころで、機械的なソフトウェアメトリクスである程度あたりをつけられると便利です。 Goの結合度を測るツールとしてspm-goの存在を知ったので動かしてみます。 spm-goとMattermostの準備 spm-goをインストールします。helpが出ればインストール成功。 $ go version go version go1.21.4 darwin/arm64 $ go install github.com/fdaines/spm-go@latest $ spm-go Software Package Metri
本書は、Goアプリケーションの効率やスケーリングに関する疑問に対して、実用的な答えを与えてくれる書籍です。 レイテンシー、CPU、メモリ資源についての知識、またOSやGoがそれらを抽象化している方法について、またソフトウェアの効率に関わるデータ駆動な意思決定を行う事の意味や、計算量解析の手法、最適化状況の例など、実用的なソフトウェアを開発する中での「効率」に関する知識を紹介します。 Goやその他のモダンな言語で書かれたプログラムを設計、作成、変更するソフトウェア開発者、また誰かが書いたソフトウェアを主に運用するDevOpsエンジニア、SRE、シスアド、プラットフォームチームなどの読者が、いつ、どのように効率最適化を適用するかという問いに答えるための知識を身に付けることができるでしょう。 関連ファイル 原著者による本書のサンプルリポジトリ 正誤表 ここで紹介する正誤表には、書籍発行後に気づい
Go Mistakes Book Details Go言語でありがちな間違い このページは『100 Go Mistakes』の内容をまとめたものです。一方で、コミュニティに開かれたページでもあります。「ありがちな間違い」が新たに追加されるべきだとお考えでしたら community mistake issue を作成してください。 Jobs Is your company hiring? Sponsor the Japanese version of this repository and let a significant audience of Go developers (~1k unique visitors per week) know about your opportunities in this section. 注意 現在、大幅に多くのコンテンツを追加して強化している新しい
The Go gopher was designed by Renée French. Illustrations by tottie. はじめに この記事は、ドメイン駆動設計(DDD)の中核概念である「リポジトリ」についての理解を深めることを目的としています。リポジトリの基本的な役割と重要性を確認し、Go言語での実装の例を紹介します。 前提 リレーショナルデータベースからデータを取得(更新)するアプリケーションを想定しています サンプルコードは Go 言語で書かれています リポジトリとは まずは、リポジトリの定義を確認してみましょう。 リポジトリパターンとは: リポジトリは、データベースから取得したデータを構造体にマッピングし、ドメインオブジェクトにアクセスするためのインターフェースを提供します。 これは、一般的なリポジトリの理解と相違ないですね。次に DDDの文脈で、より詳しい定義をみ
2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか?」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ
はじめに こんにちは!Google CloudでオブザーバビリティやSRE関連の担当をしているエンジニアです。この記事はGoアドベントカレンダーの22日目の記事です。 Goとオブザーバビリティ 私は業務でオブザーバビリティを中心として啓蒙活動や開発を行っているわけですが、その中で常に「改善にはまず計測が必要です」というメッセージをさまざまな方々にお伝えしています。 Goでは計測のための仕組みとして( testing.B あるいは go test -bench として知られる)ベンチマーク[1]や pprof が最初期から[2]用意されていて、パフォーマンス計測はかなり標準が充実した言語になっています。 そして近年もそれに満足せず、Goを改善するための計測の仕組みがいくつも提案されています。 たとえばruntime/metricsはdesign #37112で提案されてGo 1.16から導入
本記事は Go Advent Calendar 2019 11 日目の記事です。 Go はシンプルな言語機能・シンタックスが特徴であり、命名規則にもそのシンプルさが表れています。 本記事では、公式や著名な Go エンジニア、OSS などから見られる Go らしい命名規則を紹介します。 今更なテーマかもしれませんが、意外にも公私共々で命名規則が意識されていないコードを時折見かけるので、自戒も込めて記します。 誤った内容があれば Twitter でご指摘いただければと思います。 パッケージ名簡潔にするEffective Go では、short, concise, evocative なパッケージ名が望ましいとされます。 これはパッケージ名に限らずほとんどあらゆる命名において役立つ指針だと思います。 また、「パッケージ名は一言で何をするかを表すエレベーターピッチだ」という Dave Cheney
はじめに この記事はGo 言語 Advent Calendar 2023及びOpenTelemetry Advent Calendar 2023 8 日目の記事です。 今まで OpenTelemetry に関する記事をいくつか書いてきました(App Runner にデプロイしたアプリからトレースを X-Ray や Jaeger で可視化する記事やコンテナでデプロイした Lambda から X-Ray に OpenTelemetry でトレースを送る記事など)。今までの記事はどちらかというとインフラ観点のものが多く、アプリのサイドカーで OpenTelemetry Collector を動かしてマネージドサービスや OSS のツールにトレースを送る設定だったり、コンテナで動かして docker compose でローカルでも動かせるようにするだったりにフォーカスした内容が多かったです。一方で
はじめに 2023年8月9日(日本の場合)Go1.21がリリースされました🎉。Go1.21ではさまざまな変更点や追加機能が加わります。その中でもGo標準ライブラリに導入される構造化ロギングパッケージlog/slog(以下、slog)を楽しみにしている方は多いのではないでしょうか? 本稿では、slogを実際に触りつつ、機能の解説をしていきます。 TL;DR 本稿の概要をスライドにもまとめているので、ご参考にして下さい。 従来のlogパッケージについて slogの説明に入る前に、Go標準のlogパッケージについて簡単に紹介する。logパッケージを用いると、 io.Writer インターフェースを実装する任意の型にログメッセージを書き込むことができる。しかし以下のような制限があった。 ログレベルをサポートしていない ログレベルはほとんどのログパッケージの定番機能の一つだが、logパッケージには
logパッケージ Goには標準ライブラリとしてlogパッケージが提供されています。logパッケージで行えることはそう多くはありません。たとえば、デフォルトではログは標準エラー出力に出力されますが、log.SetOutput関数で出力先を変更できます。また、利用する関数によってログを出力した後の挙動をコントロールできます。たとえば、log.Print関数はログを出力するだけですが、log.Fatal関数はログ出力後にos.Exit(1)を呼び出します。log.Panicはログ出力後に出力したログと同じ文言を引数としてパニックを発生させます。 logパッケージでは、ログとともに関連するデータを出力したい場合は、log.Printf関数を用います。次のように、書式を指定して出力します。 log.Printf("request_url=%s request_method=%s", r.URL, r
こんにちは! 京都開発本部テクニカルアーキテクトグループの櫻(@ysakura_)です。 クラウド会計Plusの性能問題の解決を担当しています。 先日Goの開発をしていて、 context.Contextに入れる値をリクエストスコープに限るべき理由をパッと説明できない事がありました。 そこで、自分なりの意見を纏めてみました。 はじめに contextパッケージのコメントによると、Contextに入れる値はリクエストスコープなものに限るべきとされています。 // Use context Values only for request-scoped data that transits processes and // APIs, not for passing optional parameters to functions. 訳 contextの値は、プロセスやAPIを通過するリクエストス
sumirenです。 SREやSDETや技術顧問やフルスタックエンジニアをしています。 この記事は OpenTelemetry Advent Calendar 2023 3日目の記事です。 2日目の記事は @k6s4i53rx さんの OpenTelemetryとOpenObserveを使ってKubernetes監視をかじる でした。 背景 OpenTelemetryを使うと、分散システムの各サブシステムでどのように処理が進んだのか可視化することができます。 経験を積んだエンジニアの方であれば、各サブシステムとオブザーバビリティバックエンドが一体どのようなコラボレーションをしているのか気になることかと思います。実際、SDKやOpenTelemetry Collectorを使って手軽に分散トレーシングを実現できても、仕組みを理解できていないと、いざトラブルが発生したときに問題解決が難しいでし
こちらは Making and Using HTTP Middleware の日本語訳です。 HTTP Middleware の作り方と使い方 ウェブアプリケーションを構築しているときに、多くの(あるいはすべての)HTTPリクエストに対して実行したい共通機能があるかもしれません。すべてのリクエストをログに記録したり、すべてのレスポンスを gzip したり、重い処理を行う前にキャッシュをチェックしたりしたいと思うかもしれません。 このような共通機能を整理する一つの方法として、ミドルウェアを設定することがあります。Go では、HTTP リクエストの制御の流れが以下のようになるように、ServeMux とアプリケーションハンドラの間でミドルウェアを使用するのが一般的です。 ServeMux => Middleware Handler => Application Handler 今回は、このパタ
最初に断っておきますと、OpenTelemetry を良く知っていたり真面目に調査しようという人が読むべき内容はここにはありません。 公式ドキュメントなりをご参照ください。これは最近 OpenTelemetry を使いだした一般人の感想記事です。 さて、いけてる Web 開発者、特にバックエンド開発者の方はオブザーバビリティという言葉は聞き及んでいるかと思います。 なかでもオブザーバビリティ三種の神器と言われている(?)ログ、メトリクス、分散トレーシングをどう実装するか頭を悩ませているかもしれません。 頭を悩ませてきた、あるいは頭を悩ませている理由の一つは、これらを実装するときに特定の実装向けになりがちであったためです。 メトリクスであれば最近は Prometheus 向けに /metrics エンドポイントとして提供する実装が多いといった話です。しかしながら、 あらゆる人が Promet
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く