https://gotalk.connpass.com/event/331992/
https://gotalk.connpass.com/event/331992/
これまで何度か HTTP Server の Graceful Shutdown について記事を書きました。 Go 言語で Graceful Restart をする Go 言語で Graceful Restart をするときに取りこぼしを少なくする Go1.8 の Graceful Shutdown と go-gracedown の対応 最終的に Go 1.8 で Server.Shutdown が導入され、この件は解決を見ました。 しかし、最近「あれ?本当に正しく Server.Shutdown 使えている?」と疑問に思い、少し考えてみました。 というか ↑ の記事もまだ考慮が足りない気がする。 ぼくのかんがえたさいきょうの Go HTTP サーバー起動方法 とりあえず完成形のコード。 package main import ( "context" "log" "net/http" "os
A common question developers new to Go have is “How do I organize my Go project?”, in terms of the layout of files and folders. The goal of this document is to provide some guidelines that will help answer this question. To make the most of this document, make sure you’re familiar with the basics of Go modules by reading the tutorial and managing module source. Go projects can include packages, co
概要 zero 識別子が追加されることが決まったので該当プロポーザルの spec: add untyped builtin zero · Issue #61372 · golang/go を読んで気になったことや実際の導入予定のzero識別子の仕様についてまとめました。1 提案時の仕様 spec: add untyped builtin zero · Issue #61372 · golang/go zero 識別子を追加する zero はどの型に対しても代入可能な zero value を表す (なので、ポインタ型と値型にも同じように代入可能で*x = zero と x = zero が許容される) 0, "", nil と比較できないような型Tの値であっても、zero と比較して zero value であるかを判定できる。Tがanyの場合も含む。 この zero 識別子を追加する提案
Russ Cox 14 August 2023 Go 1.21 includes new features to improve compatibility. Before you stop reading, I know that sounds boring. But boring can be good. Back in the early days of Go 1, Go was exciting and full of surprises. Each week we cut a new snapshot release and everyone got to roll the dice to see what we’d changed and how their programs would break. We released Go 1 and its compatibility
はじめに 2023年5月10日に開催されたEnablement Workshop for Gophersで「並行処理の基礎を学ぼう」というタイトルで講義を行ないました。 Enablement Workshop for Gophersは、ナレッジワークが学生向けに提供する手を動かしながら基礎を学ぶ"Enablement"の機会です。 今回のテーマは2023年6月21日〜23日に行われるEnablement Internship for Gophersに合わせて『並行処理』です。 具体的には主に以下のような並行処理の基礎や最近または今後のアップデートについてお話しました。 ゴールーチンとチャネル syncパッケージ コンテキスト 講義の様子はYouTubeで公開されています。 ゴールーチンとチャネル Goの有名な特徴の1つとしてゴールーチンとチャネルを用いた並行処理があります。 講義では、ゴー
I’m sure we’re all in favour of “clean code”, but it’s one of those motherhood-and-apple-pie things that no one can reasonably disagree with. Who wants to write dirty code, unless maybe it’s for a porn site? The problem, of course, is that few of us can agree on what “clean code” means, and how to get there. A rule like “methods should only do one thing”, looks great on a T-shirt, but it’s not so
この記事は MICIN Advent Calendar 2022 の24日目の記事です。 前回は熊沢さんの2つの新規事業立ち上げで経験したタイプ別MVP検証の進め方でした。 はじめに 本記事では、業務アプリケーションのバックエンドとしてGoを採用することによるメリットを、実際の業務経験を振り返りつつ考察してみます。 近年では多くの企業でGoが採用されています。その採用理由は、「並行処理をたくさん行いたいから」「学習コストが低いから」「フットプリントが小さくコンテナベースのプラットフォームに向いてるから」「Googleが使ってるから」「高速だから」といったところが挙げられるんじゃないでしょうか。 一方で、単なるモノリスなAPIとしてGoを選ぶ必要はないんじゃないのか、といった声もよく聞きます。「初期フェーズはスピード重視でRuby on Railsが最強だ」「枯れた技術であるJava + S
Go Goのインターフェース抽象度を美しく保つ為の思考 Goで抽象化を適切に、そして美しく保つ為の自分の考えやTipsを紹介します。 Overview とある場面でGoのinterfaceが持つ振る舞いの抽象度について議論があり、今回はそれをアウトプットしておきます。Go初心者でinterfaceを使った設計に苦手意識を持つ人向けです。 目次 今回の目次です!下記について自分の考えをお話しします! 振る舞いの抽象化の度合いを意識する 抽象度をどこまであげるか 引数や返り値から発生する「抽象化の漏れ」 抽象度をあげる為の統合 Getter/Setterと抽象度 それではいってみましょう! 振る舞いの抽象化の度合いを意識する 振る舞いをinterfaceとして定義していくのがGoの抽象化ですが、そもそも 抽象化は度合いのある概念です 。この度合いを意識しないと適切なinterfaceの設計は困
CLIツールをテストする難しさ ターミナルなどで動作するCLI(コマンドラインインタフェース)ツールは、パッケージを公開して利用してもらうライブラリと比べてテストがしにくいと感じる読者も多いでしょう。 CLIツールは、ファイル/標準入力からの入力や、ファイル/標準出力/標準エラー出力への出力があることが多いです。また、コマンドライン引数やオプション(フラグ)によって変わる挙動のパターンが多いため、網羅的なテストが大変です。 入出力についても単一のファイルを読み書きするだけではなく、ディレクトリごと作成したり、特定のディレクトリ以下を再帰的に読み込むような処理もよくあります。 main関数にすべての処理をすべて書くような作りのCLIツールだと、実際にビルドしてテストスクリプトなどから動かしてテストするしかありません。しかし、せっかくCLIツールをGoで書いているのであれば、テストもGoで書き
Go vulnerability database The Go vulnerability database (https://vuln.go.dev) is a comprehensive source of information about known vulnerabilities in importable packages in public Go modules. Vulnerability data comes from existing sources (such as CVEs and GHSAs) and direct reports from Go package maintainers. This information is then reviewed by the Go security team and added to the database. We
Goのソースコードをきれいに描画する目的で作られた「Goフォント」があるのをご存じでしょうか。周囲に聞いたところ、あまり知られていなかったので、紹介の意味も込めてインストール方法を書きます。 Goフォント Goフォントは、2016年に以下の記事で公開されたもので、単体で配布されたものではなく、golang.org/x/exp/shinyパッケージの一部として配布されています。 go.dev コミットログを見る限りでは、2016年にv2.004、2017年にv2.008がリリースされた後しばらく更新されていませんでしたが、2022年6月17日にv2.010がgolang-nutsで告知されました。 groups.google.com フォントの画像は上のブログ記事にもありますし、Goのコードを書きながらAcmeエディタの基本を覚えるチュートリアルの途中からはGoフォントでGoのコードを書いて
Goの利点を使って実装するコツやノウハウを書くことがコミュニティにとってプラスになると思っているのでそれに専念したいという考えはありますが、Goの苦手な領域にGoを採用してしまってヘイトを溜め込んでしまう事例を見かけたりします。 こういう悲劇の起こる可能性を少しでも減らせたらという思いで、Goの現状の苦手な領域について解説しようと思います。Goを学び始めにこれらの領域に手を出すのは避けましょう。 Cgo is not Go GoはCGO連携でC/C++資産を利用することができますが、メモリアロケータの異なる処理系を繋ぐ関係上、お互いに呼び合う際のパラメータや戻り値はほとんどのケースでコピーが必要になります(Cの型でメモリ確保しCの型のまま受け渡しする場合はOK)。なので高頻度に呼び合うような用途には不向きであるというのはSWIGなどのような複数の処理系を連携させる仕組みと同様です。 また、
Goが公式で出していたGolintがdeprecated/frozenしました。 メンテがされていない 2018年から実質的な変更が加わってない Issueも放置されているものが多い golang orgに存在するlinterなのでGoが公式として推奨しているlinterに見える Go が実際には保守されていないプログラムを公式として推奨しているように見えてしまう 開発者は合理的に異なるスタイルを採用したい場合がある Golint単体で特定の警告を無視したりするなどの機能を持っていない ということからattractive nuisance(魅力的な迷惑者)になっているというProposalでした。 Issueの議論を見てもdeprecate/frozenすることに対して否定的な意見は少なく、一年ほど前にapproveされました。(なので「非推奨にしよう」なったの自体は少し前の話です) そし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く