最近Golangでメール送信処理を書くことがあったのだけど、あまり事情を知らなかったのでまとめた。 golang+SMTPでメールを送る Goには標準ライブラリでnet/smtpというのがある。 smtp package - net/smtp - Go Packages これは名前の通りGoからSMTPでメールを送信するためのライブラリなのだけど、例えばヘッダとボディの間には空行を一行自分で挟まないといけないとか、素朴すぎて結構辛い。 さすがに2023年にもなってさすがにそういうことはやりたくないので、もう少しいいやつないかなと探して、今回は以下のライブラリを使った。 github.com これはそこそこ高機能だと思う。少なくとも自分でヘッダ部とボディの間に空行を入れる、みたいなことをしなくてもいい。middlewareを差し込めるようになっていて、middlewareによって挙動を少し変
Golangの標準パッケージであるnet/httpを使ってHTTPルーターを自作する話です。 表紙は新書メーカーさんで作成しました。 https://yubais.net/tools/paperback-maker/ 追記: 要約版をqiitaに書いてあります。手短に知りたい場合はこちらが良いかもしれません。 https://qiita.com/bmf_san/items/312fac5b3132d8bee4ca 自作ルーターがawesome-goにリストアップされました :D https://github.com/avelino/awesome-go#routers 追記: コードのハイライトを修正しました。 追記: Go Conference 2021 Autumnで"net/httpでつくるHTTPルーター自作入門"というタイトルで発表しました。 https://speakerdec
This repository contains the codes of the Backend Master Class course by TECH SCHOOL. You can also find it on Udemy at this link. And don't hesitate to join Tech School's Discord group to chat directly with me and other students. In this course, you will learn step-by-step how to design, develop and deploy a backend web service from scratch. I believe the best way to learn programming is to build
Goが公式で出していたGolintがdeprecated/frozenしました。 メンテがされていない 2018年から実質的な変更が加わってない Issueも放置されているものが多い golang orgに存在するlinterなのでGoが公式として推奨しているlinterに見える Go が実際には保守されていないプログラムを公式として推奨しているように見えてしまう 開発者は合理的に異なるスタイルを採用したい場合がある Golint単体で特定の警告を無視したりするなどの機能を持っていない ということからattractive nuisance(魅力的な迷惑者)になっているというProposalでした。 Issueの議論を見てもdeprecate/frozenすることに対して否定的な意見は少なく、一年ほど前にapproveされました。(なので「非推奨にしよう」なったの自体は少し前の話です) そし
Note: this article is available as an ebook and as a printed book for easier reading Introduction What is this? When I was first learning Go, I already knew several other programming languages. But after reading an introductory book and the language specification I felt like I really didn’t know enough about Go to use it for real world work. I felt I’d probably need to fall into many traps before
Go 1.16リリース記念連載の最終回はsignal.NotifyContext()です。 ご存知のように、Go 1.7でcontext.Contextが入ってから、少しずついろいろなAPIがContext対応になりました。 1.7 netのDialerがDialContext()メソッドを追加 net/httpのhttp.RequestがContext()とWithContext()メソッドを追加。 os/execがCommandContextを追加 1.8 database/sqlが大幅にcontext.Context対応を追加 net/httpのhttp.ServerがShutdown()を追加 netにcontext.Contextに対応したリゾルバーを追加 1.13 net/httpのNewRequestWithContextと、Request.Clone()が追加 外部へのネッ
概要 Docker上で動作するGo製Webアプリケーションをデバッグする方法を解説します。 2020-05-03 追記 以前は oxequa/realize を利用していましたが、 2020年5月3日現在 oxequa/realize はメンテナンスが止まっています。 例えば 去年私が追加したissue は閉じられていませんし、その他のPRもマージされていません。 その為 cosmtrek/air を使った形に記事を大幅に書き換えました。 cosmtrek/air はメンテナンスが継続されており、GoModuleにも対応しているので、oxequa/realize の代わりは十分に果たせると思っています。 環境 ホストOS(macOS Catalina バージョン 10.15.4) GoLand 2020.1.1 Docker Desktop for Mac(Docker version 1
よく知られる良さ ネイティブコード出力で実行効率が良い コードの可読性を重視している 開発でよく使うツールがバンドル クロスビルドが簡単にできる コンパイルが遅くない(LLライクにrunできる) 並行処理の抽象化を組み込み言語仕様にもつ メモリ安全である 上記の一部に解説を加えつつあまり言及されない良さを以下にまとめます。 依存解決が最小限で決定的 ここにも書きましたが、Goの依存解決は常に 最小限のダウンロード 最小の範囲でのみビルドを実行 だけが走ります。これを一度体験すると、従来のパッケージ依存管理が冗長で余計なものをビルドしすぎることに気づくでしょう。これらに相当の時間を奪われているのです。 また、Goモジュール機構によりそのバージョン選択は決定的に安定動作するバージョンに決められます。このことのメリットは数ヶ月後のリビルドで安定してビルドできることで実感できるでしょう。 開発環境
こんにちわ 最近NeoVimに乗り換えて、vim-goプラグインを使用しています。 vimmerとgopherにとって素晴らしいプラグインなので、 共有と自分用メモという意味で記事を書いています。 各項目をクリックすると詳細説明に飛びます。 tutorialの日本語訳も合わせて読むと良いと思います。 目次 コマンド集 定義へ移動 移動から戻る 画面分割して定義へ移動 インターフェイス実装一覧 定義参照一覧 タグ生成 タグの削除 キーなしの構造体定義にキーを追加 構造体のキー初期値を追加 if err != nilを追加 構文チェック 実行 テスト実行 テスト個別実行 カバレッジを見る カバレッジをブラウザで見る 関数と型宣言一覧 インターフェイスのメソッド雛形生成 リネーム テキストオブジェクト 設定 スニペット 保存時自動Import 保存時チェック GoRunやGoTest時の画面分割
The Gopher character is based on the Go mascot designed by Renée French. はじめにTIG DXユニット 1の真野です。 コードレビューについては3,4年ほど前に、コードレビューにおけるレビュアー側のアンチパターン って記事を書いたりもしました。当時はレビュアーの伝え方って大事だよなって話をしてました。いつしかレビュイーからレビュアーに比重が変わることが増えてきました。相互レビューは当たり前にしていますがが、比較的こうしたらもっと良くなるんじゃないかな? と提案される回数より、自分が提案する回数の方が増えてくるタイミングってありますよね? そういうわけで、最近Goで主にバックエンドのWeb APIや、AWS Lambdaで動くETLアプリ、たまにCLIツールを開発する時に、2回以上同じ指摘したコメントをまとめてます。Go
There are a lot of good tutorials which talk about Go's sql.DB type and how to use it to execute SQL database queries and statements. But most of them gloss over the SetMaxOpenConns(), SetMaxIdleConns() and SetConnMaxLifetime() methods — which you can use to configure the behavior of sql.DB and alter its performance. In this post I'd like to explain exactly what these settings do and demonstrate t
Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く