なぜ 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)
Big Sky :: unsafe.StringData、unsafe.String、unsafe.SliceData が入った。
Go ではバイト列と文字列は異なる内部データとして扱っています。[]byte から string へ変換したり、またその逆を行う際にはキャストが必要になります。ですので string はイミュータブルになります。 しかしイミュータブルなのは理解しつつもバイト列を文字列にする為に無駄なアロケートをしたくない場合もあります。これまで Go ではドキュメントに明文化していなかった為に色々な作法が生まれてしまっていました。その代表的な物が以下です。 s := *(*string)(unsafe.Pointer(&b)) 本来は、Go のバイト列の内部は SliceHeader という構造体により管理されています。 type SliceHeader struct { Data uintptr Len int Cap int } また string は以下の StringHeader で管理されて
Go Secure Coding Practice の日本語翻訳を公開します - Techtouch Developers Blog
はじめに Go Secure Coding Practice とは コンテンツ一覧 良かったところ 注意すべきところ 最後に はじめに こんにちは。SRE の izzii です。 テックタッチのエンジニア規模もそれなりに拡大し、若手の採用も進んできたため、セキュアコーディングを徹底していきたいという思いがあり、まずは意識改革ということで勉強会を実施しました。セキュアコーディングを目的とした場合には教育だけでなく Static application security testing (SAST) の導入といった方法もあるのですが、まずは自分を含めた開発メンバーにノウハウをインストールすることにしました。セキュアコーディングへの意識が高まれば、いづれ SAST の導入の際に抵抗感も少ないだろうと考えています。いきなり SAST を導入しても、誤検知が煩くて浸透しないリスクもありうると考えてい
Big Sky :: Go の struct は小さくできる(fieldalignment のススメ)
動的型付けプログラミング言語や、class を持つようなプログラミング言語を使う場合、そのフィールドメンバの定義順などを意識する事は少ないかもしれません。 Go は struct という、C言語が持っている構造体と同じ様にメモリ配置され、構造体そのものをレシーバとして、メソッドを定義しつつプログラミングを行います。struct はデータ構造そのものを示し、それが大きくなるにつれ、当然ながらメモリ使用量も多くなります。 さて、例えば以下のコードを実行すると、struct 100 個分のサイズは幾らになるでしょうか。 package main import ( "fmt" "unsafe" ) type Account struct { TimeZone struct { Name string `json:"name"` UtcOffset int `json:"utc_
nil == nil でないとき（または Go プログラマは息をするように依存を注入する）
今回も小ネタ。 Go でコードを書く人にはお馴染みの話題であるが，たまたま見つけたので。 お題はこのコード： package main import "fmt" func main() { var a *string = nil var b interface{} = a fmt.Println("a == nil:", a == nil) // true fmt.Println("b == nil:", b == nil) // false fmt.Println("a == b: ", a == b) // true } 実際の実行結果はこちら。 Go における nil はポインタ値のある状態を示すもので，いわゆる「null 参照」を指している。それだけだったら b == nil は true になりそうなものだが， interface 型が絡むと少し複雑になる。 実は interfa
Go コンパイラのコードを読んでみよう - kosui
はじめに 本記事は、 DeNA Advent Calendar 2020 の 11 日目の記事です。 突然ですが、「コンパイラのコードを読んでみよう」なんて言われても、「どうせ巨大で難解で複雑なロジックを理解しないと読めないんでしょ？」と思いませんか。 コンパイラの構造を理解しようとしても聞いたことのないような専門用語がずらりと並び、コードを読もうとしたらそれらをすべて完全に理解してないと一行も理解できないんじゃないか...。Go のコンパイラ gc のソースコードを読むまでは、私もそう思っていました。 しかし、あまりにも暇な休日のある日、思い立って gc のコードを読んでみました。すると、「コンパイル」という難解な響きの処理も、一つひとつを小さなタスクに分解することで、少しずつ読み進めることができると分かったのです！ 何よりも感動したことは、 gc そのものが全て Go で書かれていて、
Big Sky :: Go 言語で変数のシャドウイングを避けたいなら shadow を使おう。
var hoge *Hoge if condition != nil { hoge, err := https://t.co/3dOQ15DCmc(ctx, hoge_key) if err != nil { return nil, err } fmt.Printf("%v", *hoge) } else { hoge = nil } こんな感じのコードで死んでたんですが、うっかりhogeがnil担っちゃうの防ぐにはどうしたら・・・（文字数 — chidakiyo (@chidakiyo) February 26, 2020 こういった場合に便利なのがオフィシャルが提供している解析コマンド shadow です。(相変わらずググらび...) インストールは以下を実行します。 $ go get golang.org/x/tools/go/analysis/passes/shadow/cmd/s
Go + echo + Docker + VSCode + Remote Containers で開発環境の構築 (ホットリロードとステップ実行対応) - Qiita
Go + echo + Docker + VSCode + Remote Containers で開発環境の構築 (ホットリロードとステップ実行対応)GoDockerdocker-composeVSCoderealize 背景 Go + echo で api サーバーを実装するにあたり開発環境を構築した際のメモ。 Docker で動かしたい。 VSCode の Remote Containers を試したい。 ホットリロード欲しい。 ステップ実行したい。 成果物 https://github.com/f-sugar/golang-docker ホスト Docker 19.03.1 docker-compose 1.24.1 VSCode 1.42.0 ms-vscode-remote.remote-containers 0.101.0 コンテナ内 go 1.13.7 realize 2.1
ファイルをエディターで一括リネームするツールをGo言語で作った！ ― 機能を増やさない信念と、OSSとの付き合い方 - プログラムモグモグ
ファイルを一括でリネームしたいことはありませんか。私はあります。ということで作りました。 インストールはHomebrew brew install itchyny/tap/mmv または以下のコマンドでできます。 go get github.com/itchyny/mmv/cmd/mmv スクリーンショットではvimが起動していますが、 $EDITOR が設定されていればそれを使って編集することができます。 エディターでファイル名を編集して一括でリネームするというのは、新しい発想ではありません。 実際、多くのソフトウェア (特にファイラー) がこの機能を実装しています。 massren vimv qmv Vim plugin vimfiler Defx Vaffle fila.vim Emacs Dired 私はvimfilerの一括リネーム機能をよく使っていました。 特に不満はないのです
go-mode + eglotを使ってEmacsのGolang開発環境を整える - A Day In The Life
普段 Golang でサーバコードを書くときはもっぱら Emacs を使っています。Go Modules に移行してから gocode が動作しなくなったので最近はやりの LSP(Language Server Protocol) を導入することにしました。Go の Language Server は gopls 、Emacs のLSPクライアントは eglot を使います 動作確認バージョン Emacs 26系 Golang 1.12.x Emacsは25以上、Golangは1.11以上なら問題なく動作するはずです。 gopls のインストール Go の Language Server は3種類あります。一番下の gopls が Golang の公式 Language Server です。 go-langserver bingo gopls 一長一短あるようですが公式が安心そうなので g
Go による機械学習 推論フレームワークの最新動向 2019 - Qiita
Golang で推論 昨今では「機械学習と言えば Python」「Python と言えば機械学習」と思われがちなのですが、推論用途であれば学習済みモデルを利用して色々なプログラミング言語から扱えます。Go から扱える機械学習ライブラリの内、学習済みモデルが利用できる物としてはおおよそ以下の3つに絞られます。 TensorFlow TensorFlow Lite ONNX Golang で TensorFlow Golang で TensorFlow を利用する場合はオフィシャルから Go の binding が提供されているので Go の import 文で GitHub リポジトリを指して利用します。Jetson や Raspberry Pi での動作実績もあります。TensorFlow 自体が色々な CPU 命令の最適化まで行っているので Python とそん色ないパフォーマンスで動作
TinyGoで始める組み込みプログラミング - スイッチサイエンス 開発者ブログ
144labの入江田です。 今回TinyGoという素敵なプロダクトを試してみました。 TinyGoとは TinyGoは本家Go言語の組み込み向けのサブセット版。 本家Go言語はPOSIX-OSに対する機能依存が大きく、リッチなランタイムを持っています。その為、本来はOSを持たない組み込み用途には不向きでした。 TinyGoはPOSIX-OSに依存する機能を簡易的な実装で代用しつつLLVM（コンパイラを作る為のフレームワーク）を使って組み込み向けアーキテクチャをサポートするGo言語のコンパイラです。 つまりサポートするCPUアーキテクチャはLLVMがサポートするものを前提にしています。 リポジトリ https://github.com/tinygo-org/tinygo ドキュメント https://tinygo.org/ サポートアーキテクチャ ARMのCortex-M0系 WebAsse
楽ができるGolangのライブラリ達 - Qiita
ライブラリ探すなら基本awesome go見とけばいいけど、いろいろ楽するためという観点で、思い出した順に適当に追記していく。気が向いたらサンプルも書く gojson https://github.com/ChimeraCoder/gojson jsonのデータを渡すとそれに対応するstructを生成してくれる。JSON APIを利用するときに楽ができる。既存APIのリプレイスをGoでやるときとかも良い。 goquery https://github.com/PuerkitoBio/goquery JQueryっぽくhtmlをパースしたり検索したりして楽ができる。自前でhtmlのパースなんか書いてられない。 goreq https://github.com/franela/goreq net/httpパッケージで、httpリクエストを飛ばすのは結構面倒だったりいろんな書き方があったりしてヘ
技術選択編 - #golang で CLI 作るときにいつもつかうやつ - Qiita
続編 ボイラプレート編 - #golang で CLI 作るときにいつもつかうやつ - Qiita grapi・gex・ery など，今年に CLI を作りまくって見えてきたベストプラクティス集（技術選択編）． 基本便利パッケージ Cobra - spf13/cobra フラグ処理やサブコマンド・ヘルプメッセージ・補完など，CLI ツールに必要なことはだいたいいい感じにやってくれるライブラリ．有名どころだと docker や kubectl, hugo の実装に利用されている． 使い方イメージ: // cmd/foobar/main.go //---------------------------------------------------------------- func main() { if err := run(); err != nil { fmt.Fprintln(os.
Goでサーバー開発するときのMakefileを晒してみる - Qiita
はじめに この記事は、Go3 Advent Calendar の4日目の記事です。 Goで開発する際にはテストの実行やlintの実施といった細々としたコマンドを Makefile にまとめることが多いと思います。 これにはコマンド入力の手間を省くのももちろんですが、チーム内でコマンド実行の方法を統一するという意味もあります。「手元でのテストはReadmeに書いてある通りに実行してね」と伝えるよりも、Makefileにまとまってる方が親切です。 ということで、何番煎じか分かりませんが今回は業務で使っている Makefile を晒してみたいと思います。 ちなみに主に以下のツールを利用しています。 パッケージ管理: dep 自動リロード: realize DB migration管理: goose setup: go get -u github.com/golang/dep/cmd/dep go
Go言語のイケてない部分 - ぐるぐる～
最近色々あって仕事でGo言語を使っています。 色々割り切っている言語なので、こんなこと言ってもしゃーないんですが、言語設計はミスってるんじゃなかなぁ、と思わざるを得ない点が多々あります。 使い始めて1か月くらいなので間違ったことを書いているかもしれませんので、何かあれば指摘していただけるとありがたいです。 本文ではネガばかり羅列していますが、ランタイムとツール周りは気に入っています。 Goのランタイムを使う、もっと洗練されたAlt Go的なものがあるといいのに(もしくはジェネリクスのったGo2を早くリリースしてほしい)、と思う日々です。 追記: なんか意図とは違った受け取られ方をしている方もいるので追記します。 この記事はあくまで、「Go言語を学ぶにあたって躓いた点」を列挙し、まとめ、理由を考えてみる(教えてもらう)ために書いたものです。 Go言語自体はDisってますが、Go言語ユーザーを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mr-karan/doggo: :dog: Command-line DNS Client for Humans. Written in Golang
エラー評価のいろいろ｜Go のエラーハンドリング
ソースコードを堪能せよ
Go and License
