Goの新しい構造化ロガーを体験しよう | gihyo.jp
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
Goとエラーハンドリング慣習について
エラー返値が無用な条件 関数ないしメソッドの実装がオンメモリ操作のみで完結 将来も（メモリ以外の）I/O操作は追加されることがない 逆にいうと上記の条件のいずれかが達成できない可能性がある関数やメソッドはエラー返値を付与すべき。 返値エラー型はerrorで統一する 返すエラーがerrorインターフェース型でなければそのエラーは正常にハンドリングできません。またerrorインターフェースを満たす別の返値型で返してerrorインターフェース型で受け取るのも後述のトラブルの元です。 Goの実装方針に「インターフェースで利用するものもコンストラクター相当では構造体ポインタで返す」というものがありますがコンストラクタを呼ぶ側は元型にアクセスすることが多いのでこういう方針になっています。が、エラー値に関しては元型を意識せずに利用可能にするという役割があって、この実装方針は当てはまりません。 エラーチェ
改めて見直すGoの特徴
極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。（唯一勝てるのはプリビルドバイナリが配布されている場合くらい） また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるような変更はV1->V2というよ
個人開発でもADR （アーキテクチャデシジョンレコード）を書くことの利点 - laiso
起業なのか請負開発か趣味のプロジェクト（ペットプロジェクト）かによって状況は異なりますが「私のチームの開発者は私１人だけです」という個人開発においても、ADRは有効なツールとなりえます。 ADRとは何か？ ADR（アーキテクチャデシジョンレコード）は、ソフトウェアアーキテクチャにおける重要な設計判断とその根拠、影響、関係する検討事項などを記録した文書です。 一見、現代的な響きですが、その実態はシステム設計ドキュメントの一部です。 "ADR"で検索すると真っ先にヒットするアーキテクチャの入門書『Design It! ―プログラマーのためのアーキテクティング入門』では、ADRは「アーキテクチャ手法に対する開発者寄りのアプローチ」と説明されており、アーキテクトと開発者自身がアーキテクチャに関する意思決定を記録し、共有するための手法として位置づけられています。 アーキテクチャデシジョンレコード（A
もしもいま、Rustをイチから学び直すとしたら？ Rust入門書著者・matsu7874さんに聞く学習ロードマップ - Findy Engineer Lab
めまぐるしく変化するテックの世界。技術を身に着けるうえで学ぶべきポイントや学習環境なども年々変わっています。 そこで「もしもいまの環境で、テックのことをイチから学び直すことになったら、自分はどんな風に勉強したいか」というIFストーリーを通じて、技術との向き合い方を考え直してみる企画「テック転生」。 今回は『Rust実践プログラミング入門』共著者の松本健太郎(@matsu7874)さんに“自分だったらこう進めたい、Rustの学習ロードマップ”をご寄稿いただきました。 無理なく2ヶ月でWeb開発をRustで始めるロードマップ 株式会社estieでソフトウェアエンジニアをしているmatsu7874です。2024年8月の今、イチからRustを学び直すロードマップ（あるいはリソースガイド）を考えてみました。仕事の合間にやっていくとして数週間、長くとも2ヶ月くらいでRustで開発している会社に入っても
言語環境の管理は *env や *vm を超えて、 mise へ
mise はミーズと読みます。 mise とは *env や *vm が担っていた言語環境(コンパイラ・インタプリタ)のバージョンを管理するツールです。 rbenv や nvm のように単一言語に対するサポートではなく、標準で Go、 Node.js、 Python などの複数の言語に対応しています。 類似のソフトウェアに asdf が存在しますが、 mise はその精神的後継となっています。asdf が shell で書かれていたのに対し、 mise は rust で実装されており、起動速度も asdf と比べて格段に早くなっています。 mise は The front-end to your dev env. と自称しており、上記の言語環境のみならず、アウトオブボックスで使用できる複数の開発向けの機能を提供しているので、本稿で紹介します。 言語環境の用意 mise が提供する言語環境は
Go製のTaskでクロス環境タスクランナーを書く方法
えらく、反響があったのでちょっとまとめてみようかなと。 Taskとは？ ドキュメントホーム： リポジトリ： 特徴 タスクランナーやビルドツールとしてのGNU Makeよりもシンプルに記述 シンタックスはYAMLによる宣言的でトリッキーな記述方法を含まない インストール手順はほとんどの環境むけに整備済みで最悪GoとGitさえあれば簡単にインストールできる Makefileの代わりにTaskfile.ymlを書く Goのtext/template機能がプリプロセッサの役割を担っている どういった用途に向いている？ 主にMakefileをタスクランナー代わりに使っていた人向けです 複雑な依存を少ない行数で記述するビルドツールとしてはGNU Makeのほうが優れています GoやRustでは依存解決しつつビルドするツールを自前で持っているのでこれらのタスクランナーとして向いています（が、Rustには
新しいチームでTypeScriptに素早くキャッチアップするためにやったこと - KAKEHASHI Tech Blog
カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (id:stefafafan) です。今回は、私が TypeScript をメイン言語として採用しているチームに参加した際、言語や周辺技術のキャッチアップを行った方法について紹介します。 この記事は秋の技術特集 2024の 3 記事目です。 この記事の想定読者 私が元々持っていたスキルセット 認知負荷の増加 TypeScript 学習のためにやったこと 学習の進め方 テックリードとの 1on1 の中で壁打ちや相談 ペアプログラミング 輪読会 もくもく会 学習コンテンツ O'Reilly Online Learning を使った学習 TypeScript Deep Dive プロを目指す人のための TypeScript 入門 安全なコードの書き方から高度な型の使い方まで type-challenges 公式ドキュメ
Go言語の不満 - まめめも
ちょっとバイナリ配布したいツール↓があったので、Go言語と戯れました。 zenn.dev ほぼはじめてGoを使ったので、にわかほど語りたがる法則に従って、Go言語の感想を書きます。 新しい言語にふれたときは、できることには気づきにくく、できないことに気づきやすいので、不満が多めです。主な比較対象はRuby、C言語、JS/TS、Rustあたりです。 よかったところ ひとことで言えば「便利になったC言語」という感じでした。結構低レベルなAPIも揃っていてよかった（デーモン化が素直にできなかったこと以外）。 Rustと比べたらストレスフリーです。思った通りに書くだけでとりあえず動いてくれる。すばらしい。 見た目はあきらかに長くてダサいですが、こだわりを捨てて割り切って書けると言えなくもない。 配布しやすいシングルバイナリが作れるのはやはりよい。今回Goを選んだ理由がこれ。 細かいカプセル化がむず
【Go Dependencies コマンド】go install,go get,go mod download,go mod tidy
【Go Dependencies コマンド】go install,go get,go mod download,go mod tidy Goの開発をする際に、外部のモジュールやパッケージが必要になることが多いです。 Goにはモジュールやパッケージをダウンロード、インストールするためのコマンドが多く用意されていて、それぞれの振る舞いの違いや用途について理解するのに苦労しました。 本記事では、私が普段使うコマンドを列挙し、振る舞いや用途について言及していけたらと思います。 前提 Go Modulesに関するコマンドはGoのバージョンに大きく依存するため、バージョンには注意する必要があります 本記事はGo 1.19を対象としています go get <package-name> go getはgo.modファイルに記載された依存関係を更新し、go.modファイルを更新します この過程で、指定したパ
次なる`pkg/errors`を探して - カンムテックブログ
エンジニアの宮原です。 今回はGoでスタックトレースを取得するライブラリ選定についての記事です。 この記事は 【Gophers Talk】スポンサー4社による合同LT & カンファレンス感想戦で発表したものです。 発表スライドはこちらから確認できます。 この記事の目的 この記事ではpkg/errorsからの移行先を探すための参考情報を提供することを目的とします。 Goのエラーハンドリングのやり方等についてこの記事では触れないこととします。 pkg/errors とはなにか pkg/errorsとは、githubのREADMEを引用すると Package errors provides simple error handling primitives. とあり、直訳すると、「エラーハンドリングの基礎を提供するパッケージ」となります。 pkg/errorsを利用することで、Go本体にはないスタ
Go言語を習得するために、Goちゃんねるを作った
先週、A Tour of Go やってみた TIL というブログを書いてみた通り、Go言語を始めた。 で、ちまちま勉強をしていたのだが、つい最近たまたま ISUCON の過去問をやる機会があって Go のスコアを見たら初期値ですら、チューニング済みの他の言語のスコアを超えていて、絶対に習得するぞの気持ちにさせられた。 ちなみに私はどう言うわけかフロントエンドのソースコードをビルドしたら vite が走ってファイルハッシュが全部変わって、ベンチマークからアクセスできなくなって０点でした。対戦ありがとうございました。 なにはともあれ、本番は絶対にGoでやるぞの気持ちを新たに Go の習得に励んでいた。前のブログでは、文法が分かったから HTTPサーバー DB Connection / Migration 境界値チェックや型推論 テスト スキーマ駆動開発 コンテナデプロイ あたりをやってみたいと
なぜ Go ではロガーをコンストラクタ DI してはならないのか
問題のある実装パターン 共通実装 以下のような applog パッケージ上のロガー実装を考えましょう。ここでは Go 標準の log.Logger をラップしていますが，様々な実装に拡張できることを想定しています。 package applog import ( "fmt" "log" "os" ) type Logger interface { Info(message string) Error(message string) } func NewLogger() Logger { return &logger{ inner: log.New(os.Stdout, "", log.LstdFlags), } } var _ Logger = (*logger)(nil) type logger struct { inner *log.Logger } func (l *logger)
Makefile警察「ぐぬぬぬ…」 - Qiita
？「プロジェクトでよく使うコマンド Makefile に書いたろー」 ？「docker compose up -d --wait っと…」 👮♀「 Makefile警察 だ！」 👮♀「 Makefile は、ソフトウェアのビルドプロセスを自動化するためのファイルだ！」 👮♀「多目的なタスクランナーとして使うな！」 ？「せやったんか。誠にごめんなさい。」 Makefile は広く使われていますが、時々目的外に使われてしまうことがあります。しかし、そのような使い方にはより適した代替手段が存在します。この記事では、 Taskfile というツールについて解説します。 Makefile のつらみ Makefile は主にビルドプロセスを自動化する目的で生まれましたが、様々なコマンドをまとめて実行する便利さから多目的なタスクランナーとしてもよく使われます。しかし、次のような問題があります
Goのポインタ渡しは値渡しよりパフォーマンスが良いという誤解 - Qiita
この記事は MicroAd Advent Calendar 2022 の12日目の記事です。 「Goのポインタは８バイトだから、ちょっとした構造体を値渡しでコピーするよりポインタで渡した方が早くなる」 長らくそう思い込んでいたのですが、以下の記事でポインタ渡しには意外なデメリットが多いことを知り、誤解だと気づきました。 この記事では自分なりにポインタのデメリットをまとめつつ、ポインタ渡しで本当に良いのかを確認すべきパターンを紹介しようと思います。 ポインタが実は高価な理由 ポインタが指す値にアクセスする際にnilかどうかのチェックが必ず入る ポインタがnilの場合、Goはpanic()をおこす必要があるため ポインタは動的メモリアロケーションの原因になりがち ポインタが指す値はヒープ領域に置かれがち（絶対ではないけど一般的に多い） ヒープ領域は確保にまとまったメモリの検索、解放にGCが必要
業務アプリケーション開発にGoを採用する理由
この記事は MICIN Advent Calendar 2022 の24日目の記事です。 前回は熊沢さんの２つの新規事業立ち上げで経験したタイプ別MVP検証の進め方でした。 はじめに 本記事では、業務アプリケーションのバックエンドとしてGoを採用することによるメリットを、実際の業務経験を振り返りつつ考察してみます。 近年では多くの企業でGoが採用されています。その採用理由は、「並行処理をたくさん行いたいから」「学習コストが低いから」「フットプリントが小さくコンテナベースのプラットフォームに向いてるから」「Googleが使ってるから」「高速だから」といったところが挙げられるんじゃないでしょうか。 一方で、単なるモノリスなAPIとしてGoを選ぶ必要はないんじゃないのか、といった声もよく聞きます。「初期フェーズはスピード重視でRuby on Railsが最強だ」「枯れた技術であるJava + S
強い思想: Go を Web 開発に採用する上で
Go は Web 開発に向いているか？ 最も向いている領域は「CLI ツール」「ミドルウェア」「マイクロサービス」だと思っている。なぜならそれらはコードベースを比較的小さく抑えることを前提としているからだ。 Go は大きなコードベースを抱えやすい設計の言語になっていない。 ミドルウェアとマイクロサービスに関しては小さく作ることが正義。 CLI ツールに関しては単一責務なツールであれば小さくなるが，複数を束ねるツールであっても Web サービス開発に比べれば考えることは少なくて済む。 Web 業界における「一般的な Web 開発」，すなわちモノリスを基本とした中規模以上の開発にははっきりと 向いていない と言うべきだろう。 フラットパッケージは正義か？ 私が SNS で何度か言及した以下の記事がある。 フラットパッケージ戦略は，確かに Go の文化圏においては一定の支持を集めている。Go の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition
TailwindCSSで学ぶ技術批判の気をつけ方
もっと log/slog を使おう
