Goバックエンド標準化プロジェクトの取り組み
QualiArtsでは、2019年頃からGoをバックエンドのメインの言語として採用しており、これまでに複数のプロジェクトをGoで開発してきました。その中で、Goにおけるノウハウが溜まり、開発基盤やツールにおいて実装方法が成熟した部分が出てきていました。 一方で、ゲーム開発に限った話ではありませんが、基盤自体に手を入れるのは一定開発が進んだ段階では難しくなります。基盤の修正を行いたくても影響が広いため手を付けづらく、ゲーム自体の機能開発も行う必要があるため、おのずと優先度は下がってしまいます。 また、ゲーム運用のための管理ツールは、マスタデータの更新やユーザーデータの調査等、必要となる機能数も多く、0から作ると最低でも半年（6人月）程度は必要となります。ですが、管理ツールの開発はゲーム自体の開発の合間で行われることが多く、ある程度開発の後半に差し掛かっても、管理ツール機能の追加や改善が必要に
詳解 "Fixing For Loops in Go 1.22" 自作linterをgolangci-lintへコントリビュートした話
Go1.22から(プレビューはGo1.21から)ループ変数のメモリ共有問題が解消されたことは皆様よくご存知かと思います。 cf. Fixing For Loops in Go 1.22 それではもう1歩踏み込んで、ループ変数がイテレーション毎に異なるインスタンスになるのはどのような時でしょうか？以下2つの出力が異なる理由をどう説明できるでしょうか？ for i := range 3 { fmt.Print(&i) // [0x14000112018, 0x14000112030, 0x14000112038] // 異なるアドレス } for i := range 3 { print(&i) // [0x1400010af18, 0x1400010af18, 0x1400010af18] // 同じアドレス } 新しいループとそれを取り巻くツールの実装は、既存コードでバグを生み出さない・パ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
