Big Sky

var hoge *Hoge
if condition != nil {
hoge, err := https://t.co/3dOQ15DCmc(ctx, hoge_key)
if err != nil {
return nil, err
}
fmt.Printf("%v", *hoge)
} else {
hoge = nil
}

こんな感じのコードで死んでたんですが、うっかりhogeがnil担っちゃうの防ぐにはどうしたら・・・（文字数

— chidakiyo (@chidakiyo) February 26, 2020

こういった場合に便利なのがオフィシャルが提供している解析コマンド shadow です。(相変わらずググらび...)

インストールは以下を実行します。

$ go get golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow


ツイートされておられる以下のコードで実行してみます。

package main

import (
    "fmt"
)

var condition = true

func main() {

    var hoge *string
    if condition {
        hoge, err := do("word")
        if err != nil {
            return
        }
        fmt.Printf("checkpoint: %v\n", *hoge)
    } else {
        hoge = nil
    }

    fmt.Printf("RESUT: %v\n", hoge)

}

func do(v string) (*string, error) {
    return &v, nil
}
.../main.go:13:3: declaration of "hoge" shadows declaration at line 11


便利。

執筆者様に Twitter でお声掛け頂き、発売前ながら献本頂く事になりました。執筆された森下様、送付頂いた技術評論社様、ありがとうございました。

Visual Studio Code は登場から色々な機能を取り込みつつ着実にユーザを増やし、統合開発環境としては今や飛ぶ鳥を落とす勢いになった言って良いでしょう。以下は 2019 年の Stackoverflow Survey で公開された有名な開発環境の調査結果です。

僕は普段は Vim というテキストエディタを使っていますが、実は僕は色々なテキストエディタを試します。Emacs も人並み程度使えますし、Visual Studio Code も拡張を自分で書いた事がある程度には使っています。

Search results - mattn | Visual Studio Code , Visual Studio Marketplace

...

https://marketplace.visualstudio.com/search?term=mattn&target=VSCode&category=All%20categories&sortBy=Relevance

正直に言うと、Visual Studio Code が登場後しばらく経ってから端末表示機能を実装した時に、少しだけ悔しくて同時期に Vim の作者 Bram Moolenaar 氏が「端末機能を足そう」と言い出した時には誰よりも早く、そして Bram Moolenaar 氏による UNIX の実装よりも早く Windows のパッチを送った事を覚えています。そして個人的には今も尚、Visual Studio Code は良い目標の1つだと思っています。

本書は Visual Studio Code を知らない開発者が Visual Studio Code を使いこなせる様になるまでに、机の片隅に置いておくと便利な一冊となるでしょう。各ツールバーやコマンドパレット、Visual Studio Code での Git の扱い方、デバッガの使い方、拡張のインストールや拡張の作り方、Visual Studio Code を使った TypeScript 開発の実例を交えた説明、Go 開発の実例を交えた説明、多くの方がマッチしそうな内容になっています。本書を片手に写経しながら読み進めたならば、おそらく Visual Studio Code をあまり触った事が無かった方でも読み終わる頃には使いこなせる様になっているのではないかと思います。

僕は Visual Studio Code が登場した当初から Visual Studio Code を使っていますが、それでも知らない内容が沢山書かれていました。Visual Studio Code には自分が扱う言語拡張しかインストールしていなかったので、Visual Studio Code が扱えるデバッガ多さを紹介した画面キャプチャには驚きました。またデバッガの設定情報が書かれている launch.json で console や useWSL といった項目があり、それらを使ってもっと便利にデバッグできる事も知りました。とても勉強になりました。

一番の収穫は、特定のワークスペースでのみ拡張を有効にする為の設定でした。この辺りを知りたい方は、ぜひ購読してみるのが良いと思います。

本書で1点、惜しいなと思う事をあえて言うとすれば索引が若干少ない所だと思います。400ページを超えるこれだけのボリュームで内容も程よく濃いので、後から読み返したくなる事は間違いなくあると思います。そんな時に索引から読みたい箇所に戻れるととても便利だろうなと思いました。個人的に特に良かったなと思ったのが Visual Studio Code を使っての todo アプリ開発を TypeScript と Go の両方で実践している章でした。これらはこれから実務で統一的に Visual Studio Code を使って行こうとされておられる企業の方々には良い教科書になりえると思いました。

ところで最近、Vim の Language Server 事情も少し変化があり、vim-lsp-settings という、Language Server Client である vim-lsp のサポートを行うプラグインを作っています。多くの Language Server を Visual Studio Code 並みに簡単にインストールする事ができる様になっています(coc よりも多いです)。直近では Visual Studio Code の様にプロジェクト専用設定を行う事もできる様になったので、ワークスペース専用にデータベース接続先を設定する事も可能です。lighttiger2505 さんが開発しておられる SQL の Language Server、sqls も簡単にインストールする事ができます。さらに efm-langserver という汎用の Language Server との連携も便利です。tsuyoshicho さんが作ってくれている vim-efm-langserver-settings を入れるとインストールされているツール類を linter として多くのフォーマットのエラーをチェックする事が出来る様になっています。こういった Language Server に関するアイデアはエディタの垣根を越えて共有される、とてもフェアな良い技術の進歩であり僕もやっていて楽しいです。これからも Visual Studio Code に追いつける様に頑張っていきたいと思います。

今後も、Visual Studio Code と気持ちよい技術的な競争ができるといいなと本書を読んで改めて思いました。

Go 言語は struct のレシーバがポインタの場合は実体であってもポインタの場合であっても呼び出せるので、もし struct が参照カウントに従い動作する様な場合は実体でコピーされてしまっては困る場合があります。例えば以下の様なインタフェースを考えます。

package main

import (
    "fmt"
    "sync/atomic"
    "time"
)

type foo struct {
    n int64
    q chan struct{}
}

func (f *foo) Add() {
    if atomic.AddInt64(&f.n, 1) == 1 {
        f.q = make(chan struct{})
    }
}

func (f *foo) Done() {
    if atomic.AddInt64(&f.n, -1) == 0 {
        f.q <- struct{}{}
    }
}

func (f *foo) Watch() {
    <-f.q
}

func main() {
    var f foo

    f.Add()
    f.Add()
    f.Add()
    go func() {
        fmt.Println("いーち！")
        time.Sleep(time.Second)
        f.Done()
        fmt.Println("にー！")
        time.Sleep(time.Second)
        f.Done()
        fmt.Println("さーん！")
        time.Sleep(time.Second)
        f.Done()
    }()

    f.Watch()
    fmt.Println("ダーッ！")
}


このコードは main の中だけで動く場合には機嫌良く動きます。次にこの処理を分散してみたい考えてみます。関数 doSomething1 と doSomething2 に foo を引数で渡します。

func doSomething1(f foo) {
    time.Sleep(2 * time.Second)
    fmt.Println("さーん！")
    time.Sleep(time.Second)
    f.Done()
}

func doSomething2(f foo) {
    fmt.Println("いーち！")
    time.Sleep(time.Second)
    f.Done()
    fmt.Println("にー！")
    time.Sleep(time.Second)
    f.Done()
}

func main() {
    var f foo

    f.Add()
    f.Add()
    f.Add()
    go doSomething1(f)
    go doSomething2(f)

    f.Watch()
    fmt.Println("ダーッ！")
}


この処理は一見うまく行きそうに見えます。しかし実行するとデッドロックが起きます。

いーち！
にー！
さーん！
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
main.(*foo).Watch(...)
    C:/Users/mattn/go/src/github.com/mattn/misc/inoki_app/main.go:27
main.main()
    C:/Users/mattn/go/src/github.com/mattn/misc/inoki_app/main.go:55 +0xfd


「しっかり atomic.AddInt64 を使っているのにおかしい」と思うかもしれません。しかし実際は doSomething1 や doSomething2 の引数として foo の実体を渡した際にはコピーが発生してしまいます。参照カウンタである foo.n は両方の関数に 3 が渡り、foo.n が 0 になる事はありません。もちろんこれは引数をポインタにする事で回避できます。

func doSomething1(f *foo) {
    time.Sleep(2 * time.Second)
    fmt.Println("さーん！")
    time.Sleep(time.Second)
    f.Done()
}

func doSomething2(f *foo) {
    fmt.Println("いーち！")
    time.Sleep(time.Second)
    f.Done()
    fmt.Println("にー！")
    time.Sleep(time.Second)
    f.Done()
}

func main() {
    var f foo

    f.Add()
    f.Add()
    f.Add()
    go doSomething1(&f)
    go doSomething2(&f)

    f.Watch()
    fmt.Println("ダーッ！")
}


こういった struct をライブラリとして提供したい場合、使い手側に「ポインタで使って欲しい」と示す事ができないと、いくらでもバグが発生してしまいます。そこで使うテクニックが noCopy です。Go 言語を知っていてここまで読んだ方であれば、これが何かに似ていると気付いたはずです。そう sync.WaitGroup です。sync.WaitGroup も実体で引数に渡すとデッドロックが発生します。sync.WaitGroup の場合は以下のテクニックを使っています。

type WaitGroup struct {
    noCopy noCopy

    // 64-bit value: high 32 bits are counter, low 32 bits are waiter count.
    // 64-bit atomic operations require 64-bit alignment, but 32-bit
    // compilers do not ensure it. So we allocate 12 bytes and then use
    // the aligned 8 bytes in them as state, and the other 4 as storage
    // for the sema.
    state1 [3]uint32
}

type noCopy struct{}
func (*noCopy) Lock()   {}
func (*noCopy) Unlock() {}


go vet は Go 言語でのお作法の良くない書き方を検出してくれるツールですが、この Lock() と Unlock() を持ったインタフェースを実体でコピーしようとすると go vet の copylocks というチェック機能により警告がでる仕組みになっています。

# github.com/mattn/misc/inoki_app
.\main.go:5:21: doSomething passes lock by value: sync.WaitGroup contains sync.noCopy
.\main.go:11:14: call of doSomething copies lock value: sync.WaitGroup contains sync.noCopy


実際に組み込んでみましょう。

package inoki

import (
    "sync/atomic"
)

type noCopy struct{}

func (*noCopy) Lock()   {}
func (*noCopy) Unlock() {}

type Toukon struct {
    noCopy noCopy

    n int64
    q chan struct{}
}

func (f *Toukon) Add() {
    if atomic.AddInt64(&f.n, 1) == 1 {
        f.q = make(chan struct{})
    }
}

func (f *Toukon) Done() {
    if atomic.AddInt64(&f.n, -1) == 0 {
        f.q <- struct{}{}
    }
}

func (f *Toukon) Watch() {
    <-f.q
}


言語仕様上、禁止する事はできないのでコンパイルは出来てしまいますが、go vet を使う IDE 等ではちゃんと警告がでる様になっています。

便利なテクニックなので使ってみてみるといいと思います。