VimConf 2019に行ってきた

vim

今年もVimConf 2019に行ってきました。

今回はテーマが “how to be more productive with Vim?” ということもあったのか、比較的Vim暦が浅い人の登壇が多かったような気もしますが、その割には発表内容が素晴らしいものばかりだったので、やっぱりVimを使う人は(良い意味で)ヤバい人ばっかりだなと思いました。

毎年のことですが、運営のみなさま大変お疲れ様でした。本当にありがとうございます。
おかげでとても楽しく過ごすことができました。

発表メモ

Vim Renaissance by Prabir Shrestha

愛用しているvim-lspの作者によるキーノート。
色々なエディタ・IDE・プログラミング言語があった状況からLSPが登場し、そして未来への革命へ、的な。
乱立していると辛いとか、選択肢を広げるようにしているところとか、わかる部分もあれば自分の英語力だとちゃんと理解できているのか不安になるところもあったり...
多くの人が使えるようにするのは大事なことですけど、そこにもトレードオフがあったりするので難しいところですよね。

We can have nice things by Justin M. Keyes

2つ目のセッションはneovim作者によるキーノート。
neovimはあんまり使っていないんですが、その思想とか実装を直接聞くことができてすごく興味深かったです。
UI周りに関する作り込みとかもそうですけど、特に「Legacy paradox」の「表面化にある価値のあるモノ」についてはなるほどなーと思いました。

Your Vim is Only for You by mopp

午後の最初のセッション。
自分のVimを改善していくフローは今までそうしてきたことも多々あるし、今後もそうありたいと思っていることなのでとても共感できました。

Grown up from Vim User to Vim plugin developer side by IK

Vimを使い始めてからvim-jpに参加するまでの流れ。
課題を自分が直すしかない！みたいなところは思い当たることがあったり...
最後の「The next OSS contributer is YOU!!!」はとてもやる気が湧き起こる言葉ですね。

Usage and manipulation of the tag stack by daisuzu

こちらを発表してきました。 speakerdeck.com

make test by m-nishi

Vim本体のテストについて。
ターミナルが小さくてfailするのはやったことありますw
自分が以前blogに書いたことを見てくれていたりして、そういったことがこの発表に繋がっているのかなと思うとなんだか嬉しいです。

My Vim life by gorilla0513

1年前にVimを使い初めてやってきたことの軌跡。
ゴリラ.vimとか本とか、近くで関わっていて良く知ってる事もありますけど、ゴリラさんの情熱と行動力は本当にスゴいし尊敬しています！

Using Vim at Work! by Danish Prakash

心理学 + Vimといったとても興味深い発表でした。
UIについては(自分が思うように使えれば良いや、とか思ったりして)あんまり深く考えなかったりもしたけど、

キーボードよりマウスの方が効率的な事がある
テキストよりもビジュアル情報の方が6万倍速い

と言われると確かになーとなりました。

Let's Play with Vanilla Vim by Hezby Muhammad

プラグインを使わないVanilla Vimの話。
Vimを使いこなすと基本機能だけでもなんとかなってしまう事も多々あるんですよね。 :find とか補完とかタグジャンプとか。
1つ前の発表でも少し出てきましたが、まさか他の発表でタグジャンプがあるとは思っていませんでした。
そして :normal で I とか A とか使うやり方はやった事なかったです。

13 Vim plugins I use every day by Tatsuhiro Ujihisa

毎日使っているプラグインの紹介。
ライブコーディングでサーバをパパッと作っていましたが、流れるようなVim捌きが本当に凄かったです！

My dark plugins development history ~ over 10 years ~ by Shougo

shougo wareの開発の歴史。
最近は使わなくなってしまいましたが...第二世代くらいまではすごくお世話になっていました！
今回で最後の登壇になるかもしれないというのがちょっと信じられません。
来年でなくてもまたいつか発表していただければなと思います。

2019-10-09

Cloud Datastore用キャッシュパッケージの検討

GCP AppEngine Go gRPC

現在App Engine(Standard Environment) + Go1.11環境*1でgoonというパッケージを利用し、Datastoreのデータをキャッシュしています。
goonはバックエンドとしてApp Engineのmemcache*2を使用しており、こちらがGo1.12から使えなくなってしまうので他のパッケージに移行しなければなりません。

App Engineのmemcacheに依存しない既存パッケージとしては、

などがありますが、どちらも独自のクライアントを作成するものとなっています。

goonを使っていて気になったのが、独自クライアント方式はGoogleが提供するパッケージには無い便利な機能があるというメリットがあるものの、本家の機能が全て使えなかったり、そもそもパッケージとしての使い方が異なっているため、Go1.11以降で推奨されているcloud.google.com/go/datastoreへの移行はもちろん、元になっているgoogle.golang.org/appengine/datastoreに戻すことすら手間がかかってしまうという点です。

機能面で困ることなく、ずっと使い続けることができるのであれば特に気にするところではないのかもしれませんが、goonの場合は更新があまり活発ではなく、移行時に大幅にコードを書き直さないといけないことがわかっているため、次のようなパッケージを検討することにしました。

cloud.google.com/go/datastoreのClientをそのまま使うことができる
使い方が大きく変わるような付加機能は提供しない
キャッシュのバックエンドを自由に選択できる

上記を実現するのに使用するのがgRPCのUnaryClientInterceptorというAPIです。
UnaryClientInterceptorはリモート呼び出しの代わりに呼ばれる関数となっています。 DatastoreはgRPCで各種オペレーションを実行するため、NewClientのoptsにUnaryClientInterceptorを渡すことでキャッシュ処理を差し込むことが可能です。

使用例:

// optを渡さなければキャッシュを無効にできる
opt := option.WithGRPCDialOption(
    grpc.WithUnaryInterceptor(MemoryInterceptor),
    // grpc.WithUnaryInterceptor(MemcacheInterceptor),
    // grpc.WithUnaryInterceptor(RedisInterceptor),
)

ただし、UnaryClientInterceptorに渡されるmethodやreq、replyといった引数はDatastoreのClientの各メソッドと1:1で対応しているわけではないため、どのメソッドがどのgRPC呼び出しになるのかを把握した上でキャッシュ戦略に応じた実装をしていく必要があります。

Client	gRPC
Get	/google.datastore.v1.Datastore/Lookup
GetMulti	/google.datastore.v1.Datastore/Lookup
Put	/google.datastore.v1.Datastore/Commit
PutMulti	/google.datastore.v1.Datastore/Commit
Delete	/google.datastore.v1.Datastore/Commit
DeleteMulti	/google.datastore.v1.Datastore/Commit
Mutate	/google.datastore.v1.Datastore/Commit
Run	/google.datastore.v1.Datastore/RunQuery
Count	/google.datastore.v1.Datastore/RunQuery
GetAll	/google.datastore.v1.Datastore/RunQuery
RunInTransaction	`NewTransaction`後、`Commit`または`Rollback`
NewTransaction	/google.datastore.v1.Datastore/BeginTransaction
Transaction.Get	/google.datastore.v1.Datastore/Lookup
Transaction.GetMulti	/google.datastore.v1.Datastore/Lookup
Transaction.Put	`Transaction.Commit`にまとめられる
Transaction.PutMulti	`Transaction.Commit`にまとめられる
Transaction.Delete	`Transaction.Commit`にまとめられる
Transaction.DeleteMulti	`Transaction.Commit`にまとめられる
Transaction.Mutate	`Transaction.Commit`にまとめられる
Transaction.Commit	/google.datastore.v1.Datastore/Commit
Transaction.Rollback	/google.datastore.v1.Datastore/Rollback

goonに合わせたキャッシュ戦略とする場合、

非トランザクションでキー指定のデータ取得時にキャッシュの参照や保存を行い、
- Get
- GetMulti
データ変更時にキャッシュの削除を行う
- Put/Transaction.Put
- PutMulti/Transaction.PutMulti
- Delete/Transaction.Delete
- DeleteMulti/Transaction.DeleteMulti
- Mutation/Transaction.Mutation

ので、LookupとCommitの2つのRPCをインターセプトすることになります。

func(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
    switch method {
    case "/google.datastore.v1.Datastore/Lookup":
        // キャッシュの参照や保存
        return nil
    case "/google.datastore.v1.Datastore/Commit":
        // キャッシュの削除
        return nil
    }
    return invoker(ctx, method, req, reply, cc, opts...)
}

/google.datastore.v1.Datastore/Lookup (キャッシュの参照や保存)

LookupはreqとしてLookupRequestを受け取り、結果はreplyにLookupResponseを設定します。

実装する処理としては次のような流れです。

1. reqのread_optionsをチェックし、トランザクション内だった場合はinvokerを呼び出してreturnする
2. reqのkeysを使ってキャッシュを参照する
   *  全てのデータが取得できればreplyのfoundに設定してreturnする
3. reqのkeysを2で取得できなかったキーのみにしてinvokerを呼び出す
4. replyのfoundに2で取得したデータを追加する
5. 3で取得したデータをキャッシュに書き込む

データが見つからなかった場合のハンドリングはClientのGetやGetMulti内で行われるため、UnaryClientInterceptorの中で特殊な処理をする必要はありません。

/google.datastore.v1.Datastore/Commit (キャッシュの削除)

CommitはreqとしてCommitRequestを受け取り、結果はreplyにCommitResponseを設定します。

実装する処理としては次のような流れです。

1. invokerを呼び出す
   * エラーだった場合はreturnする
2. reqのmutationsにupdate、upsert、deleteがあれば対応するキーのキャッシュデータを削除する
   * 削除に失敗した場合はエラーを返す

キャッシュの削除に失敗すると古いデータが残り続けてしまうため、

トランザクションをロールバックして変更を取り消す
成功するまでClientのメソッドを再実行する
別の方法でキャッシュを削除する

のいずれかを行わないとデータに不整合が生じてしまいます。

これについて、特に困っているのがRunInTransactionの場合、キャッシュ削除の失敗はロールバックの対象にならず、個別にロールバックを呼び出すこともできないというところです。
そのため、

キャッシュのバックエンドにリトライ処理を入れる
- 無限にリトライしてしまう可能性もある...
キャッシュに有効期限を持たせる
- 一定時間は不整合を許容できるのであれば...
キャッシュを削除してからDatastoreを更新する
- キャッシュ削除〜Datastore更新の間に別の処理が入ると結局不整合になる
- それならキャッシュ戦略を変更した方が...
いっそのことRunInTransactionを使わないようにする

などなど、このあたりはもう少し検討をしなければいけない状況です。
ただ実際に動かしてみないとわからないところもあると思うので、近いうちに実装して色々と試してみようと思っています。

*1:https://cloud.google.com/appengine/docs/standard/go111/

*2:https://cloud.google.com/appengine/docs/standard/go/memcache/

2019-08-26

Stackdriverの設定をterraformで管理する

terraform Stackdriver GCP

今までアラートポリシーやカスタム指標などのStackdriverの設定をyamlやテキストで保存し、自作ツールで適用するようにしていましたが、自作ツールのメンテナンスが面倒になってきたのでterraformに移行することにしました。

移行にあたって、既存の設定ファイルは破棄し、terraformerを使って以下のように再作成しました。

1. 既存設定のインポート

PROJECT_ID="プロジェクトID"
BUCKET="gs://バケット名"
OUT="出力先ディレクトリ"
terraformer import google --resources=monitoring -o $OUT -p '{output}' --state=bucket --bucket=$BUCKET --projects=$PROJECT_ID

※terraformer v0.7.8の場合、terraform v0.12への対応ができていない部分があるので以下を行う必要があります

bucket.tfを修正
terraform 0.12upgrade を実行

※slack通知はauth_tokenがマスクされた状態だったので設定を削除し、terraform state rmで管理から外しました

2. カスタム指標の作成

terraformer v0.7.8はカスタム指標に対応していないため、gcloudコマンドで取得した内容を .tf に変換しました。

gcloud --project=$PROJECT_ID logging metrics list --format=json

このままだとterraform apply時に新規作成しようとしてエラーになってしまうため、terraform importでterraformの管理下に追加します。

3. 設定の適用

手元に一通りの設定が揃ったら適用します。

terraform fmt
terraform validate
terraform plan
terraform apply

※必須フィールドが無い場合はterraform apply時にエラーになるので個別に対応します

2019-07-27

Datastore Emulatorのエンドポイント

GCP

Cloud Datastore エミュレータは起動した後、gcloudコマンドではなくREST APIを使って操作するらしい。
が、そのあたりの情報が全然まとまっていなかったので本体の中をチラ見して必要そうなところを調べてみた。

cloud-datastore-emulator 2.1.0

Method	Path	Description
GET	/	OKを返すだけ
POST	/reset	データをリセットする*1
POST	/persist	データを永続化する*2
POST	/shutdown	datastore emulatorを落とす
POST	/_ah/admin/datastore	`/reset` と同じ
POST	/_ah/admin/quit	`/shutdownと同じ`

ユニットテストで使う際は--no-store-on-diskをつけて起動し、

テストケースごとに POST /reset
テストが終わったらPOST /shutdown

すると良さそう。

*1:--store-on-diskの場合はヌルポ

*2:--no-store-on-diskの場合はnot supportedが返ってくる

2019-06-14

素のVimでGoを書く時のテクニック

vim Go

gorillavim.connpass.com

にて、

外部ネットワークに繋がらない環境でvimとgoしか使えない

という縛りでライブコーディングをしてきました。

実際にそういう環境があるのか?という話はさておき、そのような状況でも以下を駆使してそこそこコードが書けます。

:%!gofmtでコードを整形できる
:r! go docの結果を適当なバッファに出力する
- Vim内でドキュメントが読める
- ドキュメントの内容をCTRL-NやCTRL-Pで補完できる
:set path+=$GOROOT/srcで標準パッケージを検索できるようにする
- :findなどで標準パッケージのディレクトリやファイルを開ける
- :grep*1 で色々と探せる
- 開いたファイルはただ見るだけではなく、補完の対象にもできる

作ったものはGET /fizzbuzz/:numberにアクセスするとFizzBuzzを返すというHTTPサーバです。

package main

import (
    "net/http"
    "strconv"
    "strings"
)

func fizzbuzz(w http.ResponseWriter, r *http.Request) {
    p := strings.TrimPrefix(r.URL.Path, "/fizzbuzz/")
    if p == "" {
        http.NotFound(w, r)
        return
    }

    n, _ := strconv.Atoi(p)
    if n < 1 {
        http.NotFound(w, r)
        return
    }

    switch {
    case n%5 == 0 && n%3 == 0:
        w.Write([]byte("FizzBuzz"))
    case n%5 == 0:
        w.Write([]byte("Buzz"))
    case n%3 == 0:
        w.Write([]byte("Fizz"))
    default:
        w.Write([]byte(p))
    }
    w.Write([]byte("\n"))
}

func main() {
    http.HandleFunc("/fizzbuzz/", fizzbuzz)
    http.ListenAndServe(":8080", nil)
}

ただ当日は1.のgofmtしか使いませんでした。
というのもスパルタンなVimmerに憧れており、元から自動補完は使っておらず、オムニ補完にもそこまで依存しないようにしていたので、このくらいのものであれば無くても特に困らなかったからです。

まあ常に役立つものではありませんが、覚えておくと何かの時に便利かもしれません。

*1:grepコマンドがない場合は:vimgrep

2019-05-18

App Engineのgo111用ディレクトリ構成

Go AppEngine

App Engine Standard EnvironmentでGo1.9を使う時は以下のように、リポジトリのルートをGOPATHとして設定し、appcfg.pyを使ってデプロイをしていました。

.
├── app.yaml
└── src
    └── app
        ├── glide.lock
        ├── glide.yaml
        ├── app.go
        ├── handler
        ├── ...
        └── vendor

app.go

package app

import (
        "net/http"

        "app/handler"
)

func init() {
        http.Handle("/", handler.New())
}

これがgo111のランタイムになると、main関数が必須になり、デプロイコマンドもgcloud app deployに変わります。*1

そのため、以下の条件を満たしつつ、どのようなディレクトリ構成にするのが良いのか考えてみました。

app.yamlのパスは変更しない
GOPATHをリポジトリごとに変更しなくても良いようにする
- src/appはpkgに変更
- app.goはpkg.goに変更
依存関係の管理にgo.modを使う
- リポジトリのルートに配置

1) ./main.goを作成する

.
├── app.yaml
├── go.mod
├── go.sum
├── main.go
└── pkg
    ├── handler
    ├── ...
    └── pkg.go

2) ./cmd/app/main.goを作成し、app.yamlのmainでパスを指定する

.
├── app.yaml
├── cmd
│  └── app
│      └── main.go
├── go.mod
├── go.sum
└── pkg
    ├── handler
    ├── ...
    └── pkg.go

この時、プライベートなパッケージ*2を使っているとCloud Buildで依存関係を解決できません。
対策としては、代わりにvendorを使う、もしくはgo.modのreplaceディレクティブを使う、のどちらかです。

しかし、vendorを使う場合にはgo.modを.gcloudignoreに追加し、GO111MODULEをoffにしないといけません。
また、go.modを使うにはGO111MODULEをonにしないといけません。
GO111MODULEはリポジトリをGOPATHの配下に置くか、外に置かでautoの時の値が変わるため*3、組み合わせが非常に複雑です。

まとめると次のようになります。

依存管理	リポジトリの場所	GO111MODULE	デプロイ可否
go.mod	GOPATH配下	auto(=off)	offだと使用不可
go.mod	GOPATH配下	on	OK
go.mod	GOPATH外	auto(=on)	OK
go.mod	GOPATH外	off	offにできない
vendor	GOPATH配下	auto(=off)	1)はOK、2)はNG
vendor	GOPATH配下	on	NG
vendor	GOPATH外	auto(=on)	NG
vendor	GOPATH外	off	offにできない

※確認する際にCloud Buildで使われたイメージはgcr.io/gae-runtimes/go111_app_builder:go111_20190503_1_11_9_RC00です

正しくgo.modを使えば問題なくデプロイできるため、replace対象のパッケージが管理できるのであればこちらを使うのが良さそうです。
ただ、replace対象のパッケージはgitのsubmodulesやsubtreeで管理することになり、それが煩雑になってしまう可能性があります。

そういった場合、現段階だと1)をGOPATH配下に置くのが無難です。
app.yamlでmainを指定することができませんが、今のプロジェクトでは必要なかったので以下のディレクトリ構成にすることにしました。

.
├── app.yaml
├── go.mod  // デプロイしない
├── go.sum  // デプロイしない
├── main.go
├── pkg
│  ├── handler
│  ├── ...
│  └── pkg.go
└── vendor  // `GO111MODULE=on go mod vendor` で作成

*1:https://cloud.google.com/appengine/docs/standard/go111/go-differences 参照

*2:GitHub Enterprise含む

*3:GOPATH配下: off、GOPATH外: on

2019-04-13

MojaveでGDB 8.3を使う

Mac gdb

1. インストール

brew install gdb --HEAD

2019/04/13時点でインストールされるバージョンは8.3.50。
2019/05/14以降は--HEAD不要。

echo "set startup-with-shell off" >> ~/.gdbinit

を実行するようにと表示されるが、ファイルの場所は$HOME/.config/gdb/initでも良い。

2. 証明書の作成

キーチェーンアクセスを起動し、メニューから

キーチェーンアクセス > 証明書アシスタント > 証明書を作成...

を選択。

以下を入力したら他はデフォルトのまま(期限は伸ばしておいても良い)ひたすら「続ける」を押していく。

名前: gdb-cert
証明書のタイプ: コード署名
✅: デフォルトを無効化

「ログイン」に作成されたgdb-certを「システム」にドラッグ&ドロップし、
証明書の情報を開いて「信頼」の「コード署名」を「常に信頼」に変更。

3. コード署名

gdb-entitlement.xmlを作成する。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.debugger</key>
    <true/>
</dict>
</plist>

署名する。

codesign --entitlements gdb-entitlement.xml -fs gdb-cert $(which gdb)

4. 設定を反映させる

sudo pkill taskgated