This post continues a series on the testing package I started a few weeks back. You can read the previous article on writing table driven tests here. You can find the code mentioned below in the https://github.com/davecheney/fib repository. Introduction The Go testing package contains a benchmarking facility that can be used to examine the performance of your Go code. This post explains how to use
Goはgo routineを使って並行処理を容易に書くことができるが、下手に書くと色々なfunctionが相互に入り乱れて処理が追いづらいときがある。ここではGoでfunctionをトレースする方法をメモしておく。 結論から言えば、runtime.Callerを使えば良い。なお、debug.PrintStackでstack traceを出力することができるが、標準エラー出力となるのでちょっと使いづらい。しかし、ただコンソールで出力したいだけなら、debug.PrintStackのほうが簡単であるし、これ以降を読む必要は無い。 func Caller func PrintStack 簡単な使い方 runtime.Callerとは何なのかはマニュアルを参照すべきだけど、簡単に言うと、引数の数値に応じてCallerが呼び出された時点での呼び出し元の情報を提供してくれるfunctionと言える。例
Goでテーブル駆動テストを書いていると、書いているときは「すげー読みやすくテスト書けてるぞ!」と思っていても、落ち着いてから見てみると「なんだこれ...訳がわからん...」となることがあると思います。(自分はよくあります。) この記事は、このようなことを解決するのに役立つtipsについてまとめています。主にテストケースについて焦点を当てています。 テストしやすいコード設計に興味がある方は や を参考にしてください。 はじめに この記事はパーソナライズGopher道場で学んだことを元に書いています。 そして、この記事で紹介するテーブル駆動テストの書き方は主観に基づいており、 あくまでテストの1つの書き方にすぎないです。 なので、「この書き方をしないとダメ!」というものではないので、みなさんの考え方やプロダクトに合わせて、柔軟にこの記事で紹介するtipsを取り入れていただけると幸いです。 結論
In this short post, I will explain why GO111MODULE was introduced in Go 1.11, its caveats and interesting bits that you need to know when dealing with Go Modules. Table of content: From GOPATH to GO111MODULEThe GO111MODULE environment variableGO111MODULE with Go 1.11 and 1.12GO111MODULE with Go 1.13GO111MODULE with Go 1.14GO111MODULE with Go 1.15GO111MODULE with Go 1.16GO111MODULE with Go 1.17Fast
Go言語での構造体実装は、埋込や独自コンセプトのインターフェースといったGo言語独自の機能を理解して行う必要があります。 今年からGo言語を始めましたが理解が曖昧なままだと実装に迷うことが何度かありました。今回よい機会なので、Go言語での構造体実装パターンとしてまとめてみることにしました。 構造体実装パターン 実装パターンの洗い出しとして、GoFデザインパターンをGo言語で実装する手法をとりました。 その中で繰り返し現れる実装をGo言語での構造体実装パターンとしてまとめてみました。 コンストラクタ関数 エクスポートによるアクセス許可 インターフェースによるポリモフィズム 構造体によるポリモフィズム 構造体によるサブクラス・レスポンシビリティ 構造体による移譲 関数による移譲 以下、それぞれのパターンを解説していきます。 コンストラクタ関数 Go言語には構造体のコンストラクタがないため、構造
ある程度Goを書いているプログラマであれば、下記のようなコードに出くわしたことがあるのではないでしょうか。 そうそう、Mapはポインタだから、関数内で変更した内容は呼び出し元に反映されるけど、Sliceはポインタじゃないから反映されないんだよね。呼び出し元に反映させるためには、Sliceをポインタで渡してあげないといけないね。 と、今までは理解していたのですが、この理解は半分正解で半分間違いでした。今日は、この挙動の原因と、その調査過程で見つけたnilなSliceのおもしろい(?)特徴の2点について、整理したいと思います。 原因は「Sliceはポインタじゃないから」ではなかった実は、追加ではなく、単純な値の変更であれば反映されます。 Sliceの実装を見てみると、Sliceの実体(array)はポインタ型となっています。つまり、Slice自体は構造体ですが、実際の配列はポインタで参照してい
最近色々あって仕事でGo言語を使っています。 色々割り切っている言語なので、こんなこと言ってもしゃーないんですが、言語設計はミスってるんじゃなかなぁ、と思わざるを得ない点が多々あります。 使い始めて1か月くらいなので間違ったことを書いているかもしれませんので、何かあれば指摘していただけるとありがたいです。 本文ではネガばかり羅列していますが、ランタイムとツール周りは気に入っています。 Goのランタイムを使う、もっと洗練されたAlt Go的なものがあるといいのに(もしくはジェネリクスのったGo2を早くリリースしてほしい)、と思う日々です。 追記: なんか意図とは違った受け取られ方をしている方もいるので追記します。 この記事はあくまで、「Go言語を学ぶにあたって躓いた点」を列挙し、まとめ、理由を考えてみる(教えてもらう)ために書いたものです。 Go言語自体はDisってますが、Go言語ユーザーを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く