Dive into gomock
Room A
みなさまは、interfaceに依存するコンポーネントのテストを書いていますか？ また、テストで使うinterfaceの実装はどうやって用意していますか？ interfaceにメソッドが追加されたらどうしますか？ 意図したメソッドが呼び出されていなかったら？ メソッドに渡される引数の比較方法を柔軟にしたくなったら？ interfaceのモックを用いたテストを簡単に記述するためのフレームワークの1つに、gomock[^1]があります。 gomockを使ったモック実装を使ってテストすることで、interfaceのメソッド呼び出しが適切に行われていることを検査し、意図しないメソッド呼び出しがあればテストを失敗させることができます。 また、gomockを使ったモック実装を生成するためのツールとしてmockgenが用意されています。mockgenを使うことで、interfaceの定義が変わってもgo generateコマンドで簡単にモック実装を修正することができます。 本セッションでは、gomockがどのようにinterfaceのメソッド呼び出しを検査しているのか解説します。 主に以下のトピックについて取り上げる予定です。 - mockgenが生成するコードの内容 - 期待するメソッド呼び出しを記述し、記録する - 期待するメソッド呼び出しがなければテストを失敗させる - 引数の比較方法をカスタマイズする このセッションが、Goのinterfaceモックを用いたテストの仕組みへの理解を深める一助となれば幸いです。 [^1]: https://github.com/uber-go/mock
Kiki Utagawa
Web Application Engineer at Hatena inc.
イテレータによってGoはどう変わるのか
Room A
みなさんは、Go1.18でジェネリクス（型パラメタ）が登場したとき、どのようにそのエコシステムが発展していくか想像しましたか？ もっと遡れば、Go Modulesの登場からGo1.21の後方互換性の強化[#57001]、そしてfor文のループ変数に関する変更[#57969]を互換性を崩さないように導入する流れを予想できたでしょうか？ ※ [#XXXX]は関連するGoのissue番号を表しています。 Goは毎日徐々に進化しています。Goチームやコントリビューターは日々議論を重ね、後方互換やその後のエコシステムの発展を考えながら機能を追加していっています。その進化は驚くほど滑らかに我々の開発体験を壊さずに、そしてジェネリクス（型パラメタ）のような大きな機能も取り入れられながら行われています。 本セッションは、ほぼ毎日Goのissueの一覧を眺め、毎週木曜日前後に公開されるプロポーザルレビューミーティングの結果を確認することで得られた知見を基に次の大きな機能であるイテレータに関する話題を扱います。 Go1.23では、for range文において関数経由で任意のデータ構造をイテレーションする仕組み（イテレータ）が導入されます[#61405]。mapsパッケージでは、ついにKeys関数がイテレータを返す関数として導入され[#61900]、slicesパッケージ[#61899]やstringsパッケージ[#61901]、regexpパッケージでもイテレータを使った関数が導入されるでしょう[#61902]。Map関数やFilter関数など、イテレータに作用する関数についても導入が議論されています[#61898]。 イテレータは、任意のデータ構造やデータストリームを1つのシーケンシャルなデータ列として提供する仕組みとして捉えることができます。実際、Go1.23で導入されるイテレータは、iterパッケージとしてSeq[V]型やSeq2[K, V]型として提供されます[#61897]。これはGoが提供しているio.Writer型やio.Reader型、そしてfs.FS型で提供している高度な抽象化に通づるものがあります。さまざまなデータ、データの流れ、処理がイテレータで表現されるようになるでしょう。 本セッションでは、Goにおけるイテレータという概念がどのように生まれ[#47203]、どういう機能として提供される予定なのかコミュニティのディスカッションを追いながら解説します。そして、イテレータが生み出すであろうエコシステムについてコミュニティでの議論を振り返りながらまとめ、Goの未来がどのように変わっていくのかサンプルコードを示しながら次のような予想を展開します。 ■ 予想1：エラーを伴う処理への応用 各プロポーザルでGoogleのGoチームが予想しているように、イテレータはデータ構造をイテレーションするための機能に留まらず、(*sql.DB).Scan関数や(*bytes.Scanner).Scan関数のようなエラー処理を伴うリソースの読み込みなどにも使用されていくでしょう[#65236]。 ■ 予想2：sync.WaitGroupやerrgroup.Groupへの応用 Go1.22でリリースされたmath/rand/v2パッケージ[#61716]やGopherCon 2023でも発表が行われ、その動向が注目を浴びているencoding/json/v2パッケージ[#63397]など、標準ライブラリのv2が盛んに議論されています。また、sync/v2パッケージを期待する声もあり、その中でsync.WaitGroupが改善される可能性も考えられます。予想ではありますが、golang.org/x/sync/errgroupパッケージがsync/v2パッケージに含まれるようになれば、ゴルーチンの処理をWaitメソッドで待ったり、github.com/sourcegraph/conc/poolパッケージのResultContextPool型のようにスライスで処理結果を取得するのではなく、イテレータによって処理の結果を取得するようになるかもしれません。 本セッションを通して、イテレータの基礎だけに留まらず、それが普及した後のエコシステム、そして今後のGoの進化について考える機会を提供できたらと思います。 ● 関連するissue [#57001]: https://go.dev/issues/57001 [#57969]: https://go.dev/issues/57969 [#33502]: https://go.dev/issues/33502 [#61405]: https://go.dev/issues/61405 [#61900]: https://go.dev/issues/61900 [#61899]: https://go.dev/issues/61899 [#61901]: https://go.dev/issues/61901 [#61902]: https://go.dev/issues/61902 [#61898]: https://go.dev/issues/61898 [#61897]: https://go.dev/issues/61897 [#47203]: https://go.dev/issues/47203#discussioncomment-1034432 [#65236]: https://go.dev/issues/65236#issuecomment-1906793427 [#61716]: https://go.dev/issues/61716 [#63397]: https://go.dev/issues/63397
Takuya Ueda
Knowledge Work Inc.
Cleanup handling in Go
Room A
Goはgoroutineによる並行処理を容易に実現できます。しかし、その並行処理の終了処理は開発者に委ねられています。 処理をただ停止するだけでは済まない場合も多く、適切な終了処理、つまり「クリーンアップ」が必要です。 クリーンアップには、例えば次のようなものがあります。 - トランザクション処理: 中途停止するとデータ整合性が失われるため、最後まで完了させる必要がある。 - 外部リソースとの接続: 正常に終了させて、リソース解放や接続解除を行う必要がある。 - 一時ファイルやデータ: 処理終了後に不要になるため、削除する必要がある。 いわゆる「グレースフルシャットダウン」と「通常のシャットダウン」の違いは、クリーンアップ処理の有無にあると考えています。 本発表では、まず「クリーンアップ」をユースケースの1つに持つ標準パッケージの機能の `testing.T.Cleanup` 、 `context.AfterFunc` 、 `http.Server.RegisterOnShutdown` などを改めてみていきます。 さらに、より複雑なコードベースを持つアプリケーションにおけるクリーンアップ処理について考察します。 必要な要件をあげ、そしてその要件を満たす具体的な実装を提案します。 本発表を通じて、開発者の方々にクリーンアップ処理について改めて考えてもらい、各開発現場にあるであろうクリーンアップ処理についてGoコミュニティで会話がされることを期待しています。
Ken'ichiro Oyama
GMOペパボ株式会社 技術部技術基盤チーム プリンシパルエンジニア
Custom logging with slog: Making Logging Fun Again!
Room B
## Abstract: In Go 1.21, "slog" has emerged as a logging library. This talk aims to spotlight the slog, guiding attendees from its fundamental concepts to customized logging. We'll explore the slog by implementing custom slog handlers. We also cover performance tips to avoid slowing down our code. Let’s make logging more than just an afterthought! ## Outline: (20 min talk) 1. Introduction (3 minutes) 2. Fundamental of slog (6 minutes) - Key features and advantages of using the slog. - A quick tour of slog's APIs. 3. Making Custom Handlers (10 minutes) - Demonstrating custom handlers in `slog` to integrate with several cases. - Making custom handlers with code samples. - Optimization for efficient log without compromising performance. 4. Conclusion (1 minute) ## Target Audience: This talk is designed for Go developers of all levels interested in slog and improving their application's logging. Whether you're new to the slog or looking for ways to leverage it more effectively. ## Takeaways: Attendees will leave with a comprehensive understanding of slog and how to customize slog with taking care of performance.
Miki Masumoto
UPSIDER Inc.
Data Race Detection In Go From Beginners Eye
Room A
Do you know what is Data Race in concurrent programming and what is inside it's hood ? - Background Recently, I faced a problem in my code a data race issue that caused our service to crash after we mistakenly deployed it without checking for race conditions . I didn't know how to fix and prevent the data race issue at first , so I searched online to learn more about data races and the Go Race Detector. Curiosity led me to explore how to prevent Data Races, and I'm excited to share my story of understanding the inner workings of the Go Data Race Detector. In the realm of concurrent programming, the occurrence of Data Race conditions can be frequent and challenging to manage. If I put it in simple words , when two or more goroutines access shared memory data concurrently and one goroutine is a write , Data Race conditions may arise, leading to unpredictable failures which we can not detect long after the code has been deployed to production. This session focuses on exploring the Go Race Detector, which is built upon the C/C++ ThreadSanitizer runtime library. Originally designed to identify errors in Google's internal codebase and Chromium, The Race Detector is a powerful and proven tool for detecting data race bugs. Given that we wanted to write multithreaded programs, how can we protect our systems from the unknown consequences of difficult to track down data race bugs in a manner that is reliable and scalable . Go Race Detector follows " Pure Happens Before Race Detection" using Vector Clocks so let's understand the concepts. - Expected effect on audience This session aims to provide attendees, especially beginners, with a comprehensive understanding of Data Races in concurrent programming. Participants will gain insights into detecting and addressing these issues effectively using the Go Race Detector and also the attendies will learn about the backend technolgy behind Data Race Detector .
Vaibhav Gupta
Backend Engineer | Golang Developer
Go1.21から導入されたGo Toolchainの仕組みをまるっと解説
Room B
Go Toolchainが導入されることになった背景を紹介します。 go1.21より前まではgo.modのgo行に多くの人が期待していた動きと実際の動きが異なることを説明します。 Go1.21からGo Toolchainの導入により、go.mod/go.workファイルのgo行の意味が変わり、さらにtoolchain行が追加されました。 それにより、どう変わって、どう便利になったのかを紹介します。 このセッションを聞いて資料を参照することで、go行とtoolchain行を理解し活用できるようになります。 go1.21よりも前を使っている方にも、その段階での仕様を把握できるので正確に自分とチームの環境を整理できるようになります。
Takahito Yamatoya
株式会社メルコイン, VP of Engineering
Goにconst型修飾を期待しなくてよい理由
Room A
Goにはconst型修飾がありません。 言い換えると、型によって変数の不変性を担保できません。 そのため、時には安全でないチープな言語とみなされ、技術選定や習得する上で言語の抵抗感につながることがあります。 しかし、なぜGo言語に不変性を担保する機能がないのでしょうか？ 実はGoのメンテナは10年以上前から様々な機能を議論しています。 そして、Go言語に合った解決を見つけられていないのが現状です。 結果として不変性についての機能がない代わりに、言語の互換性や自由度を維持しています。 本記事(セッション)は、既存の議論を交えながら不変性についてのトレードオフを説明することで、言語の抵抗感を払拭し、Go言語を生産的な言語として捉える考え方を紹介します。
Kazuhiro Sakurayama
LINEヤフー株式会社
GoのLanguage Server Protocol実装、「gopls」の自動補完の仕組みを学ぶ
Room B
Language Server Protocol（以下、LSP）は、型やシンボルの自動補完、定義参照、修正案の提示といったコーディング支援機能をエディタやIDEに提供するプロトコルです。 Go言語では、公式にサポートされているLSPの実装として「gopls」があります。goplsは、成長するGoのエコシステムに対応し、大規模なコードベースでも高速かつリソース効率的に開発者を支援するよう進化してきました。 その結果、goplsは現在、多くのエディタやIDEのデフォルトのLSPバックエンドとなっています。参加者の皆さんも、気づかないうちにgoplsを使用している可能性があります。 しかし、多くの開発者がgoplsを使用しているにもかかわらず、goplsの内部メカニズムを詳しく解説した記事は少ないです。私自身も、「敷居が高い」という印象を持っていました。 このセッションでは、goplsが提供する多くの機能の中から、自動補完に焦点を絞り、その仕組みを紹介します。 goplsの自動補完機能は、スマートに、かつ適切な候補を提案してくれます。その裏側で動く、泥臭く堅実な処理について学ぶことで、goplsをより身近なツールとして捉えることができるでしょう。 まず、LSPの基本的な仕様と、goplsのアーキテクチャの概要を紹介します。これにより、参加者ご自身でgoplsの仕組みを調査する際の基礎知識を提供します。 その後、主題である自動補完の仕組みについて詳しく説明します。あるGoのコードに変更を加えた場合、どのように適切な補完候補が提案されるのか、簡単な具体的な例を用いて説明します。 本セッションを通じて、参加者の皆さんがgoplsの自動補完の仕組みを理解し、その他の機能についても興味を持って学ぶきっかけとなることを期待しています。
Shoki Hata
株式会社カンム
Guide to Profile-Guided Optimization: inlining, devirtualining, and profiling
Room A
Goの公式コンパイラは様々な最適化を提供しており､その中で関数のインライン展開と脱仮想化が挙げられます｡ 関数のインライン展開は､関数呼び出しをその関数の本体で直接置き換え､関数呼び出しのオーバーヘッドを抑えます｡ またGoの脱仮想化は､インターフェースを通じたメソッド呼び出しの実行時コストを削減するために､コンパイル時に具体的な実装を特定する最適化手法です｡ この2つの最適化の適用範囲を広げられる最適化手法として､Go1.20でPGO(Profile-Guided Optimization)が追加されました｡ 本セッションでは､インライン展開､脱仮想化と､PGOがこの2つの最適化にどういった影響を及ぼすかについて解説します｡ まず､Goコンパイラにおける関数のインライン展開と脱仮想化の基礎的な部分を説明します｡ インライン展開では､どのような条件でインライン展開がおこなわれるのかについて掘り下げ､関連するコマンドラインオプションを紹介します｡ 脱仮想化の説明では､その仕組みを他の言語処理系と比較して解説し､Goコンパイラの設計思想に触れていきます｡ 次に､PGOによってインライン展開と脱仮想化の適用範囲が広がる仕組みを解説します｡ 最後に､弊社でのPGOを活用した実際のアプリケーションのパフォーマンス改善に向けた取り組みを共有します｡ このセッションを通じて､参加者の方はGoにおける先進的な最適化技術の仕組みを理解し､自身のプロジェクトに応用するための知識を得ることができます｡ PGOのプラクティカルな事例を共有することで､サービスのパフォーマンスを更に引き上げたい方に有益なセッションとなることを目指しています｡
Satoru Kawahara
株式会社カンム
Mapのパフォーマンス向上のために検討されているSwissTableを理解する
Room A
現在GoではMapの内部実装をSwissTableを使用したものに置き換えることでパフォーマンスを向上させる案が議論[1]されています。SwissTableはRust[2]やabseil(Googleが公開したC++のライブラリ)[3]で使用されている実装です。 本セッションでは、SwissTableの概要と利点の紹介に留まらず、Map内部実装を変更するという影響範囲が広い変更について、Go Teamがどのような考慮をしているかやどんな議論がされているかを紹介します。 このセッションを通じて、Goの内部実装が変更される可能性に伴う議論を紹介することで、この提案の議論からGoの開発においてGo Teamが考慮している点や姿勢について学んだことを共有できればと思っています。 加えて、SwissTableへの理解を深めることで、変更がGo本体に採用されなかった場合にも、アルゴリズムの特性がみなさんが作成しているサービスに適しているかどうか判断できるようになり、必要な場合にはSwissTableを独自実装したりサードパーティ実装を使用したりすることで、Mapを伴う処理の高速化が必要になった時の手助けができればと幸いです。 [1] https://github.com/golang/go/issues/54766 [2] https://github.com/rust-lang/hashbrown [3] https://abseil.io/
Natsumi Kojima
ANDPAD Inc.
Unified Diff 形式の差分から Go AST を構築して feature flag を自動計装する
Room B
開発スピードの高速化とデプロイまでの時間短縮を可能にするトランクベース開発では、main branch を常に Production リリース可能な状態に保つ必要があります。開発段階であるがゆえに Production への反映を避けたい場合や、修正内容を Staging 環境で QAテストすることが必要な場合は、feature flag を用いた実装が必要です。feature flag とは、コードを変更せずにシステムの振る舞いを変更可能にする仕組みであり、主に環境変数やステータスを管理する外部サービスを通じて有効/無効を切り替えることができます。具体的には、flagの値に応じた分岐をあらかじめ実装することで、外部から入力されたfeature flagの値によってシステムの振る舞いを変えることができるようにします。 トランクベース開発での迅速な開発進行と同時にシステム品質を保証するためには、細かなQAプロセスが不可欠です。CIによるシステム的なチェックは必須ですが、それに加えて Staging 環境での QA も同様に非常に重要になってきます。これを実現するためには、適宜 feature flag を組み込んだ実装が必要になります。しかし feature flag の実装はコードを複雑化させるため、トランクベース開発においては長期間にわたる存在や同時に多数存在することは推奨されていません。したがって、QA で品質を保証しつつコードの複雑化を最小限に抑えるには、feature flag の迅速な組み込みと削除が必要です。しかし QA の品質を高めるためには頻繁に feature flag を組み込む必要があり、管理コストが増大するという課題があります。 この課題を解決するために、git diff で出力される Unified Diff 形式の差分情報から Go の抽象構文木（以下、AST） を構築し、AST の差分を利用して feature flag の自動計装を試みました。本セッションでは uber-go のリファクタリングツールである「gopatch」の内部実装を参考に、Unified Diffから有効なGoコードへの変換とASTの構築プロセスを通じて、適切なfeature flagの自動挿入方法を紹介します。参加者はこのセッションを通じて、Unified Diffを活用したツール作成のアイデアやfeature flagの効果的な活用方法を学ぶことができます。さらに、自動計装ツールの開発にこの知見を応用することが可能になります。
Shota Iwami
CyberAgent, Inc.
バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方
Room A
このセッションの対象者: - メッセージエンコーディングの仕様に興味がある方 - gob encoding の適切なユースケースが気になる方 - バイナリリーディングに興味がある方 セッションを聞くことで得られるもの: - gob encoding の仕様と性質がわかる - メッセージエンコーディング選定にあたって評価すべき観点の一部を知れる - バイナリエンコーディングを読み解くプロセスがわかる - gob encoding を利用すべき適切なユースケースがわかる 概要: Go は標準パッケージに encoding/gob という独自のメッセージエンコーディング実装を持っています。 gob はバイナリエンコーディングであり、ストリームでの利用を念頭にデザインされています。 しかしながら、 human readable でない点や、言語固有のエンコーディングである点などから、性質を正しく理解することや、性質に合った適切なユースケースを選択することが難しいと考えています。 そこで本セッションでは、 Go が固有のメッセージエンコーディングをデザインするに至った背景について整理しながら、実際のバイナリを眺めて gob の仕様や性質への理解を深めることを目指します。 バイナリを眺めて仕様を理解する過程で、一般的なメッセージエンコーディングとしての性質(サイズ, メッセージ互換性, エコシステム, self-describingかどうか, etc..)について gob を評価し、gobを利用すべき適切なユースケースについても提案します。 実用的な知識を共有しつつ、バイナリエンコーディングを読み解く面白さや、メッセージエンコーディングを比較する際の観点の一部もお伝えできればと考えています。
Yuya Okumura
株式会社LayerX
試してわかるGo ModulesとMinimal Version Selection
Room B
Goはmoduleという単位で依存性を管理するシステムを公式に提供しています。そのシステムの中でも特に重要で特徴的なのが、依存モジュールのバージョンを決定する方法・アルゴリズムです。このアルゴリズムは、Minimal Version Selectionと呼ばれています。知っていても知らなくても、GoのほとんどのユーザーはこのMinimal Version Selectionを利用しています。あなたがgo getコマンドを実行するときには、Minimal Version Selectionが走っているのです。 しかし、Minimal Version Selectionについて良くわかっているGoユーザーはそれほど多くないのではないでしょうか。その理由としては「よく分かっていなくても開発ができるから」という理由ももちろんあるでしょう。しかしそれだけではなく、「手を動かして学ぶことが大変だから」という理由も大きいと思います。モジュールシステムを実際に手で動かして学ぶためには、自分が知りたい疑問に答えられるような複数のモジュールの複数のバージョンを作って公開し、それを使うメインモジュールを自分で作らなければいけないからです。 このセッションでは、それをオーディエンスに代わって実演します。それにより、このセッションを見終わった人は、次のような問いかけに対してすっきり答えられるようになるでしょう。 - 私のモジュールには、requireしているバージョンより新しいバージョンが使われている依存モジュールがあります。これはなぜ起きるのでしょうか？ - 同一のgo.modで時間をおいて2回go buildしたとき、依存モジュールのバージョンが変わることはありますか？ - go.sumは「lockファイル」ですか？（ネタバレ: 違います） - go.sumがバージョンの決定と関係ないのなら、go.sumはなんのためにあるのですか？ - 依存モジュールの公開されている全てのバージョンをexcludeしたらどうなるのですか？ [セッションの予定アウトライン] - 依存性管理とはどのような課題か - Goのmoduleとは何か - Minimal Version Selectionとは何か - go getしたときに何が起きるのか - Semantic VersioningとSemantic Import Versioning - Minimal Version Selectionは何が嬉しいのか - excludeとは何か - go.sumは何に使われるのか - 練習問題コーナー
Nobishii N/A
Software engineer
詳解 "Fixing For Loops in Go 1.22" / 自作linterをgolangci-lintへコントリビュートした話
Room B
Go1.22から(プレビューはGo1.21から)ループ変数のメモリ共有問題が解消されたことは皆様よくご存知かと思います。 cf. [Fixing For Loops in Go 1.22](https://go.dev/blog/loopvar-preview) それではもう1歩踏み込んで、ループ変数がイテレーション毎に異なるインスタンスになるのはどのような時でしょうか？以下2つの出力が異なる理由をどう説明できるでしょうか？ ```go for i := range 3 { fmt.Print(&i) // [0x14000112018, 0x14000112030, 0x14000112038] // 異なるアドレス } for i := range 3 { print(&i) // [0x1400010af18, 0x1400010af18, 0x1400010af18] // 同じアドレス } ``` 新しいループとそれを取り巻くツールの実装は、既存コードでバグを生み出さない・パフォーマンスを落とさない工夫がされています。 本セッションでは、loopvarパッケージのコードリーディングを通して、これら変更の背後にある内部動作を解説します。 さらに、デザインドキュメントやコミュニティでの議論、周辺ツールを併せて確認することで、セマンティクス変更への理解をより深めたいと思います。 また、Go1.22から不要になったループ変数のコピーを検出する自作linter [copyloopvar](https://golangci-lint.run/usage/linters/#copyloopvar) をgolangci-lintにコントリビュートした話もお伝えします。 このlinterが何をどのように検知するかを紹介する中で、Goにおける静的解析ツールの作成方法も解説します。 linterの自作やOSS貢献に一歩踏み出す際、本セッションがご参考になれば幸いです。
Ryosei Karaki
CyberAgent, Inc.
deadcode超解剖
Room A
2023年末にGo公式が「Finding unreachable functions with deadcode」（ https://go.dev/blog/deadcode ）というブログを通して、使用されていない関数を見つけ出すためのdeadcodeというツールを紹介しました。 このブログでdeadcodeが紹介されたことをきっかけに、複数のlinterを同時に設定することができるツールであるgolangci-lint( https://github.com/golangci/golangci-lint )に対して、Go公式のものであるdeadcodeを採用するのはどうかというissueが複数挙げられました。 しかし、golangci-lintはこのdeadcodeを採用せず、代わりにunusedという類似の機能を持つlinterと比較してこの提案を棄却しました。その理由と2つのlinterの違いについて深ぼることで、それぞれのlinterの特徴と使い分けが理解できると思っています。 また、私自身deadcodeを使用し、あるOSSのコードをリファクタリングするPRを送りました。ただ、そのPRが不要なリファクタリングという指摘を受け、deadcodeで検知して削除するべきではないinterfaceの中のメソッドの役割を学びました。 そこで、その経験を通して、現段階のdeadcodeを使う際の注意点についてもお伝えしたいと思っています。 具体的にはこのセッションで以下の項目についてお話しします。 1. deadcodeの概要と内部の仕組み 2. golangci-lintのissueを通したdeadcodeとunusedの比較 3. 現段階でdeadcodeを使用する際の注意 このセッションは、Goで使用されていない関数をlintしたい方や、Goのlint自体に興味がある方に対して特にお話ししたい内容です。
Naoki Kuroda
株式会社サイバーエージェント
go get で考慮しているファイルシステムの挙動について
Room A
Goでのアプリケーション開発で外部の公開されているライブラリを使用したい場合は go get を使用してパッケージをダウンロードします。 このときダウンロードされるライブラリは $GOPATH/pkg/mod 配下にフォルダが作成されGoのファイルが保存されます。 例を挙げる `go get golang.org/x/sync` を実行すると `$GOPATH/pkg/mod/golang.org/x/sync` の形で保存されます。 このときにフォルダやファイルが保存されるということは保存先のOSのファイルシステムの挙動を考慮する必要があります。代表なOSだとmacOSやWindowsだと大文字と小文字を区別しない設定が可能です。[1][2] 一方で、Goのライブラリを公開できるGitHubではユーザ名とリポジトリ名には大文字を使用することができます。 このような場合、大文字と小文字だけの違いがあるライブラリをダウンロードできない可能性があります。 この発表では go get で実行されるコードを紹介しつつ、この問題をどのように解消しているのかを紹介したいと思います。 これに加えて発表の中では実際にどのように処理の流れを理解したのかもお伝えすることで Go 自体のコードを読むことのハードルの低さを少しでもお伝えしたいと考えています。 発表スライドの章立ては以下を考えています。 1. 自己紹介 2. go get の仕組みを簡単に紹介 2.1. ファイルシステムの大文字/小文字の区別にも言及 3. ファイルシステムの考慮をどのように行っているコードを示しつつ紹介 4. どのように処理の流れを追って理解していったのか 参考文献 [1] https://learn.microsoft.com/ja-jp/windows/wsl/case-sensitivity [2] https://support.apple.com/ja-jp/guide/disk-utility/dsku19ed921c/mac
Shinnosuke Kishida
SO Technologies株式会社,バックエンドエンジニア
golang/goのbuiltin packageを覗いてみる
Room A
github.com/golang/goにはコンパイラやgofmtをはじめとする各種ツール、標準ライブラリなどが含まれています。その中から、builtin package (src/builtin/) を紹介します。Goを実装している際、エディタやIDEの機能で組み込み型の定義を開いたことがある方は少なくないと思います。そのときにたどり着くのがこのpackageです。 builtin packageは、predeclared identifiers (直訳すると事前に宣言された識別子) が定義されたpackageです。bool, uint8, float64, stringといった組み込み型や、append, lenといった組み込み関数が定義されていますが、その実装はこのpackageには含まれていません。本LTでは、これらの定義がpackage内でどのように書かれているか紹介し、このpackageが存在する理由を簡単に説明します。
Koki Senda
Voicy, Inc.
Making Sense of How Rangefunc Works: Just 1 Tip in 5 Minutes
Room A
Go 1.22 contains a preliminary implementation of Rangefunc. The Go team is considering adding this feature for a future Go release, so it's a good idea to start getting the hang of it now. However, its behavior does not seem to be straightforward. In this lightning talk, I'll introduce just one tip that can serve as a key to understanding, all in five minutes. Go 1.22にはRangefuncの仮実装が含まれます。Go チームは将来の Go リリースにこの機能を追加することを検討しているため、今のうちから使いこなす準備をしておきたいところです。しかし、その動作は決して分かりやすいものではないように感じます。そこで、理解の糸口となる1つのコツを5分で紹介します。
Yuki Bobier Koshimizu
Software Engineer at ZOZO
Table-driven testing に縛られないGoのテストパターン
Room A
本LTでは、Table-driven testingに縛られないGoのテストパターンを紹介します。 Table-driven testingはGoでしばしば利用されるパターンで、 シンプルな入出力が期待されるテストでは扱いやすく効果的です。 一方で、データベースの状態に依存するテストやモックを活用したテストを書きたい場合、 工夫をこらす必要があり、場合によっては認知負荷の高いコードになってしまうことがあります。 Arrange-Act-Assertパターンなど、Table-driven testingに縛られないパターンをGoで採用することを考察し、 その使い分けのベストプラクティスを紹介します。
Kotaro Abe
株式会社MICIN ソフトウェアエンジニア
自作HTTPルーターから新しいServeMuxへ
Room A
Go1.22からnet/httpにおけるServeMuxのルーティングが大きく進化を遂げました。 これまでのServeMuxとGo1.22のServeMuxで何が変わったのか？を踏まえ、自作HTTPルーターとのパフォーマンス比較検証を行ってみます。おまけで他のメジャーなHTTPルーターとの比較結果もシェアします。 このトークでは、 ・Go1.22から追加された便利なルーティング機能 ・ServeMuxと自作HTTPルーターを比較した結果から得られた学び ・これからのHTTPルーター選定方針についての私見 を5分でみっちりお話したいと思います。
Kenta Takeuchi
ソフトウェアエンジニア
自動生成されたhttpエンドポイントごとにカスタムミドルウェアを挿入したい話
Room A
### 目的 OpenAPI に準拠したファイルから生成された REST API サーバにて、生成ファイルを編集せずに、http エンドポイントごとに任意のカスタムミドルウェア相当の処理を挿入したい人へ向けた Tips を共有したいです。 ### 詳細 Go では OpenAPI 準拠のスキーマファイルから、ボイラープレートコードを生成する oapi-codegen という OSS が提供されています。 2024/06 時点では、生成された http エンドポイントごとに、任意のミドルウェアを割り当てる仕組みがありません。 この問題は issue で報告されており、独自の実装が PR で上がっていますが、正式な機能の提供は先送りになっています。 https://github.com/deepmap/oapi-codegen/issues/518 LT では、以下の項目に絞って説明しようと思います。 1. OpenAPI に準拠したファイルから REST API サーバを自動生成できる oapi-codegen を紹介 2. issue で報告されている問題について - oapi-codegen によって生成された http エンドポイントごとに、任意のミドルウェアを割り当てられない 3. 独自の解決案を紹介 - http ルーティングエンジンは Echo を使います - ミドルウェアで echo.Context をラップして、各コントローラーにてミドルウェア相当の処理を実行する仕組みの説明 - 参考: https://codehex.hateblo.jp/entry/echo-context ### Appendix oapi-codegen: https://github.com/deepmap/oapi-codegen
Reo Uehara
株式会社Finatext
通信の不安定さに悩んでいたらシュッとプロキシを書けて改善できちゃった話
Room A
自分たちでは手を入れられないHTTPのある通信先において、同時に複数のリクエストを送ると一部が失敗する問題に頭を悩ませていました。 「Goでプロキシを作ってそれを介せば、通信並列度を抑えたりリトライの仕組みを入れられるのでは？」と思いつき、調べつつやってみたところ着想から2日程度で動くものができてしまい、"一つのことをうまくやるツール"をシュッと作れる言語だなとあらためて感じました。 ソースコードはこちらにあります。 https://github.com/bellwood4486/flow-limit-proxy LTでは主に以下を話す予定です。 * 悩んでいた状況(概要)とアイディアの説明 * 次を組み合わせるだけで簡単に並列抑制を実現できた仕組みの紹介(実装のスニペットを見せつつ、ポイントを絞りながら) * "http.RoundTripper" * "golang.org/x/sync/semaphore"
Yoshiharu Suzuki
株式会社HRBrain
DELISH KITCHENにおけるマスタデータのキャッシュ戦略とその歴史的変遷
Room A
DELISH KITCHENで扱うデータには、大別してレシピデータなどの主に入稿によってしか変動しないものと、お気に入りなどユーザの行動によって変動するものとが存在しています。 両者を比較すると、マスタデータの方は変動性が低い傾向があるため、キャッシュについても異なる戦略が必要となります。 DELISH KITCHENのリリース当初から現在に至るまでのキャッシュ戦略の変遷や、その際どのような試行錯誤を経てきたか、また今後の展望について、Goの実装を交えてお話します。
Akira Uchihara
株式会社エブリー開発本部 TIMELINE開発部部長, DELISH KITCHEN開発部副部長