僕はGo言語が好きだ。そのGoがもたらす恩恵のひとつとして、例外周りのセマンティクスがある。Goでは例外はerrorという型の値に抽象化され関数の返り値として記述することが多いというのはご存知だと思う。 func GetUser(id int) (*User,error) { // do some thing ... iferr != nil { return nil,err } return user, nil } 上記の例のように、複数の返り値を設定できる言語機能を利用して、 第一にその関数に期待する主要な出力のデータ、第二に関数内で発生した例外(error型の値)を伝播させるのが一般的な記述だ。 この iferr != nil {returnerr} を毎回書くのが(たとえコピペでも) 「めんどくさい」、「冗長だ」という意見を持つプログラマもスクなくはない。 個人的には気
作ってるツールをどのようにgithub の release に乗せればよいか調べていたところ、goreleaser-action なるgithub actions 用の action があることを知り、github actions の勉強がてら使い方を調べてみたgithub.comプロジェクトの構造はこんな感じで、ルートにあるパッケージを cj というディレクトリーにあるメインプログラムから参照する . ├── .github/workflows │ ├── release.yml │ └── test.yml ├── .goreleaser.yml ├── Makefile ├── README.md ├── call.go ├── call_test.go ├── cj │ ├──go.mod │ ├──go.sum │ └── main.go ├──go.mod └

golangで書いたプログラムをDockerで動かしOOMが発生した際になるべく情報を残して殺される方法を紹介します。 2020/08/16追記: この記事の内容はgolangに関してはやや現実的ではなくなってしまいました。 詳しくは続編を参照してください。 TL;DRgolang製のプログラムは仮想メモリ(VSZ)の確保に失敗するとgoroutineのダンプを吐いて死ぬDockerのOOMはRSSベースで検出時にSIGKILLを投げてくるDocker利用時にVSZで制限をかけるスクリプトを書いたgolang製のプログラムはlinux-amd64において最低でも101MBのVSZを要求する VSZの制限がそれより小さいと当然起動できない 実際のRSSは3MB程度で起動する Background コンテナ内で動いているプロダクション上のgolang製のプログラムが時々OOMに殺されて
golangでテストのためだけにinterfaceを書くのが死ぬほど嫌だったので編み出した技を紹介します。 TL;DR テスト(=mock)のためだけにinterfaceは切りたくない 型エイリアスとビルドタグを組み合わせるとinterfaceがなくてもモックが作れる この手法に必要なモックを自動生成するプログラムを作った interfaceは本当に必要なシーンで使うべき Background 現在モックを使った単体テストは一般的です。Javaでの例を挙げると、モックしたいコンポーネントについて予めinterfaceを定義しておき、モックではそのインターフェースを実装するのが定石です。 しかしgolangのinterfaceはJavaなどのそれとは若干性質が異なるため、テスト=モックのためだけにinterfaceを書くのはオーバーワーク気味です。 そうテストのためだけにinterface
はじめに この文章は、普段からVim を使い、仕事でも趣味でもGo 言語を書いている僕が、最近どの様な環境で書いているかを説明した文章です。ベストプラクティスではありません。vim-go と僕 元々、Go 言語はリポジトリの misc/vim にVim でGo 言語を書くための syntax やコマンドを持っていました。今でもそれらはGoogle のリポジトリに置かれています。ミュージアム的な物なので、実用的ではないと思います。GitHub -google/vim-ft-go A rudimentaryGo filetype plugin. Provides syntax files and basic settings forgo files. This is a f... https://github.com/google/vim-ft-go これを Fatih A

Background AtGopherCon 2017, Russ Cox officially started the thought process on the next big version ofGo with his talk The Future ofGo (blog post). We have called this future language informallyGo 2, even though we understand now thatit will arrive in incremental steps rather than with a bigbang and a single major release. Still,Go 2 is a useful moniker, if only to have a way to talk about

↓のようなリポジトリごとにその直下をGOPATHにする環境でGoを書く時、 . ├──github.com/daisuzu/bar │ ├── bin │ ├── pkg │ └── src │ └── bar │ └── main.go └──github.com/daisuzu/foo ├── bin ├── pkg └── src └── foo └── main.go 両方のリポジトリのファイルを同時に開いて行ったり来たりするのを少し楽にするためにvim-goの設定を切り替える関数を作ることにした。 function!SwitchRepo() lettoplevel = trim(system('git rev-parse --show-toplevel')) iftoplevel =~# '^fatal' return endif "GOPATHをリポジトリ直下
サーバ間で分散処理を行う際の相互通信におけるボトルネックを解消するため,smux(Socket multiplexer)を開発している. サーバ間の相互通信におけるボトルネックとその解決策 一対のサーバ間で多数のリクエストとレスポンスが送受信され,信頼性の高い通信としてTCPを利用する場合,コネクション確立のオーバーヘッドを排除するために接続の再利用が行われる.しかしながら,クライアントは送信に対する受信を待つ必要があるため,レスポンスまでに幾許かの処理時間を要する状況では送信のキューがたまってしまう.そこで複数の接続を利用することでこれを解消する方法が取られるが,追加の接続はリソース使用に関するオーバーヘッドを発生させてしまう.なにより各接続におけるレスポンス待ち時間は依然として解決しておらず,接続の利用面から見て非効率である.そこで,単一の接続において,仮想的に並行送受信を行う方法が提

One of the oft-touted benefits ofGo is that applications written init are easily deployed because they are statically complied. A lot of this benefitgoes away if you need to manage the location and permissions on abunch of files needed to run a web application. The solution is to compile anynecessary files into the application binaryitself. This can be done inGo by using a byte slice litera
Photo by Sandrachile . on UnsplashIf you actually want to use the memory on your computer withGo — really useit, with gigabytes ofit allocated — then you may pay a big penalty for theGo garbage collector (GC). But there are things you can do aboutit. TheGo GC checks what parts of the memory you have allocated are still in use.It does this by looking at all the memory for references to other
Goを書いていて、実際のユースケースに遭遇するまでメリットが実感できないものとして、reflectパッケージが挙げられると思います。 実際のところ、reflectパッケージで取れる情報についてはいろんな記事でまとまっているものの、じゃあそれを使って何ができるんだ、実益があるのかという点を体感する機会は人によりけりです。 よくある説明と違和感「メタプロ的なことができるぜ」「構造体の情報を取得してあれこれできるぜ」という説明を受けることがありました。 ただ、僕的にはいまいちイメージが掴めずにいました。おまけにパフォーマンスに負の影響があるから基本的には使わないものとして認識している方が多いと思います。 lestrratさんの少し前の資料とかを見て、そんな感じのイメージでいました。Goを学習した時に、goroutineとかは利用場面に比較的に早くから遭遇できる一方、reflectパッケージはい

GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changingit is not allowed. Preamble The GNU General Public License is a free, copyleft license for software and other kinds of works. The licenses for most software and other practical wor
golang のhtml/template について書かれたブログ等を色々見ていると、みんなレイアウトとコンテンツの分離に苦労している感があったのでどうやるか書いておきます。 t.ExecuteTemplate(w, "content", data)Go のhtml/template はテンプレートの名称を指定して ExecuteTemplate を実行します。しかしhtml/template には、その content を囲う layout テンプレートを指定する方法がありません。特に以下の様に ParseGlob を使った場合、各html で同じ content という名前で define する事は出来ません。template.ParseGlob("public/views/*.html") やりたいのは layout というテンプレートの中から content という名称

Googleが中心となってオープンソースで開発されているGo言語は、WindowsやmacOS、Linux、FreeBSD、iOS、Androidなど、さまざまなOSやCPUに対応したバイナリを生成できることが特長の1つとなっています。 そのGo言語のコンパイラが生成するバイナリにWebAssemblyが追加されました。WebAssemblyは、Webブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマットです。WebAssemblyのサポートは昨年2月から検討がはじまり、先月末に最初のコードがコミットされた状態で、現在も開発が進んでいます。GOの今後のバージョンアップで正式にWebAssemblyがサポートされる見通しです。Go言語はサポートするOSやCPUの種類をそれぞれ「GOOS」と「GOARCH」の値で示しています。例えばWindowsのGOOS値は「

Go Conference 2018 Spring

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く