fmtパッケージにはfmt.Printfの出力を任意に変更できるインターフェースが定義されている。 各インターフェースを満たす独自型をフィールドに持つ構造体の出力がどうなるのか確認し、任意の型の出力を制御できるか確認してみた。 TL;DR fmt.Printf関数はPrint verbによって出力形式を変更できる https://golang.org/pkg/fmt/#hdr-Printing fmtパッケージのインターフェースを実装すると出力を制御できる fmt.Stringerインターフェース https://golang.org/pkg/fmt/#Stringer fmt.GoStringerインターフェース https://golang.org/pkg/fmt/#GoStringer fmt.Formatterインターフェース https://golang.org/pkg/fmt/

「詳解Go言語Webアプリケーション開発」という書籍を執筆し、2022/07/22にC&R研究所様より発売しました。 全国書店やAmazonで購入できます。本記事では本の内容の紹介や執筆経緯、執筆してみての感想など書きます。 https://www.c-r.com/book/detail/1462 本の内容について 本著は大きく分けて二部構成になっています。 第一部は次のようなテーマにまつわるトピックを中心にまとめました。 他の言語を経験していると不思議になるGoの言語仕様 最近Goを始めた方は知らない過去の経緯や歴史的背景 第二部ではGoを用いたWebアプリケーションのコードをハンズオン形式で解説しました。 テストコードを書き段階的な変更を繰り返しながらAPIサーバの実装を試みています。 Docker Composeを使ったローカル開発環境の構築 github.com/cosmtrek/

Goにはいくつかプログラムを終了させる手段が存在する。 プログラムを終了させるときにどれを選べばいいか調べてみた。結論から言うとmain関数内でdeferを使わずos.Exit関数を呼ぶ。 TL;DR Goで意図的にプログラムを終了させることができる処理は次のとおり https://golang.org/pkg/os/#Exit https://golang.org/pkg/builtin/#panic https://golang.org/pkg/runtime/#Goexit main関数内でdeferを使わずos.Exit関数を呼ぶのが一番良いと思う panic関数は終了コードを明示的に決めることができない 一方ですべてのゴルーチンを停止してくれるらしい runtime#Goexit関数をmain関数で呼ぶのは行儀が悪そう Calling Goexit from the main g

当日利用したスライドは以下になる。 Goの郷に入る前に 今回はgolang.tokyoメンバーがオススメする3年以上前に公開された記事・発売された書籍の優良情報をまとめた。 発表では各々の記事・書籍を紹介する前に、まず今回の発表の背景・Goの言語哲学について触れた。 Goらしいとは Goらしいとは一言で言うとSimplicity（簡潔性）だ。後述するRob Pike氏の「Simplicity is Complecated」と言う発表タイトルが一言で表している。 より詳細な解説については、私の言葉より@songmuさんの次の記事を読むといいだろう。 また、このSimplicityが何を目的としているかはBrand bookのGoが達成したいMissionやValueを確認することでわかる。 Go Brand Book https://storage.googleapis.com/golang

「Goらしさ」や「Goに入ってはGoに従え」というけれど、「Goらしい」って一体なんだろう？と考えてみる。 TL;DR 後半は完全に私見の域を出ない&&身も蓋もない結論なので、最初に参考情報だけまとめておく。 「Goらしさ」が何を目指しているのか、何を目指す考えが「Goらしさ」なのか知りたいならば、まず言語思想・設計思想を知るべきだろう。 言語思想についてまとめられている文書は次の情報だ。 Go’s New Brand | The Go Blog Go at Google: Language Design in the Service of Software Engineering https://talks.golang.org/2012/splash.slide#1 https://talks.golang.org/2012/splash.article 一言でいうと「Goらしさ」とは

Goではメソッドや関数の引数にcontext.Contextが含められていると何かと便利だ。 とはいえ、最初からアプリケーションがcontext.Contextを考慮していない場合もある。 アプリケーションを漸進的にcontext.Contextに対応させる方法を書いておく。 TL;DR キャンセル通知や透過的な情報をやりとりするための仕組みがcontext.Context ある操作のキャンセルを親gorotuineから伝える リクエストIDなどをネストしたメソッドに伝える（透過的な情報しか含めてはいけない！） 運用状態のアプリケーションの各メソッドを全てcontext.Contextに対応させるのは大変 context.TODO()を使って少しずつ始めよう https://golang.org/pkg/context/#TODO contextパッケージの思想を知るにはThe Go Bl

2019/01現在Public BataのGitHub ActionsでCircleCIのbranches only相当の処理を出来ないか調査した。 GitHub Actions https://github.com/features/actions/ TL;DR 特定のブランチ名のときだけ動くGitHub Actionsを定義したい Workflowに対する設定はないが、Actionで設定することができる actions/bin/filterを使う https://github.com/actions/bin/tree/master/filter サンプルブランチは以下。 budougumi0617/actions-filter-branch https://github.com/budougumi0617/actions-filter-branch なお、この記事は2019/01/11

TL;DR Go Modules(vgo)はGo1.11から導入され始めたGoの新しいバージョン管理 Go1.12ではまだ有効にはなっていない(Go1.13からはデフォルトで有効になる） Go Modulesの概要とTipsなどを簡単にまとめた Go1.12のModules関連の変更をDockerを動かして確認してみた GOPATHi外でgo.modがなくてもgo run可能 replaceディレクティブで依存パッケージをローカルのコードを使って解決 etc… 確認に利用したDockerfileやスクリプトは以下のリポジトリにある。 https://github.com/budougumi0617/gomodules-explore vgo発表前のGoのバージョン管理は以下のような手法が取られていた。 go getでgo1タグ・ブランチもしくは最新のmasterブランチを取得する go g