Datastore Emulatorのエンドポイント
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
すると良さそう。
素のVimでGoを書く時のテクニック
にて、
外部ネットワークに繋がらない環境で
vim
とgo
しか使えない
という縛りでライブコーディングをしてきました。
実際にそういう環境があるのか?という話はさておき、そのような状況でも以下を駆使してそこそこコードが書けます。
:%!gofmt
でコードを整形できる:r! go doc
の結果を適当なバッファに出力する- Vim内でドキュメントが読める
- ドキュメントの内容を
CTRL-N
やCTRL-P
で補完できる
:set path+=$GOROOT/src
で標準パッケージを検索できるようにする
作ったものは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に憧れており、元から自動補完は使っておらず、オムニ補完にもそこまで依存しないようにしていたので、このくらいのものであれば無くても特に困らなかったからです。
まあ常に役立つものではありませんが、覚えておくと何かの時に便利かもしれません。
App Engineのgo111用ディレクトリ構成
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 参照
*3:GOPATH配下: off、GOPATH外: on
MojaveでGDB 8.3を使う
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. コード署名
<?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
goonのクエリをチューニングした時のメモ
App Engine(Go 1.9)でDatastoreからデータを取得するのにgoonのGoon.Runを使っていたが、プロパティを追加する改修*1をした後、
latencyが遅くなり、DatastoreでDeadline exceeded
が頻繁に発生するようになってしまった。
とりあえず該当するリクエストをStackdriver Traceで見てみるとdatastore_v3.Nextが7回ほど呼ばれていることがわかった。
まずはこの呼び出し回数を減らせば速くなるだろうと思い、Query.BatchSizeを設定してみたが、呼び出し回数に変化は無く、全く効果がなかった。
それも変だなと思い、試しにデバッグログを仕込んで1回の呼び出しでどれくらいのデータを取得できているのか見てみたところ、なんと90件くらいしか取得できていなかった。
ここまで改修前の状態を確認していなかったので念のため調べてみると、datastore_v3.Next
の呼び出し回数は5回、1回あたりのデータ取得件数は約120件だった。
このことから、原因はプロパティを追加したことでデータのサイズが増え、一度に取得できる件数が減ったことによるDatastoreへのアクセス増ということがわかった。
ということで次はMemcacheを使ってDatastoreへのアクセスを減らすようにしてみた。
方法としては今までのクエリにQuery.KeysOnlyを設定してキーだけを取得するようにし、本体はGoon.GetMultiで取ってくるというシンプルなもの。
しかし、これだと1000件のデータを取得しようとするとGoon.GetMulti
がMemcacheにデータを格納する際に大量のメモリを消費してしまうため、エラーになったり、インスタンスが落ちるようになってしまった。
そこでGoon.GetMulti
の呼び出しが100件ずつになるようにしてみたところ、エラーは解消されたように見えたが、どうやらMemcacheにデータが乗っておらず、常にDatastoreにアクセスしてしまっていた。
仕方なく50件まで減らしたら安定してキャッシュが効くようになり、ようやく速度が改善されるようになった。
そもそもデータ構造がイマイチっぽいので本来はそこから手を入れるのが良さそうだが、今からそれをやるのもなかなかに厳しい状況なので当分はこれでしのぐことになりそう。
*1:後で確認したらデータサイズが80%ほど増加していた...
第1回 ゴリラ.vimが開催されました
2/18(月)にゴリラ.vim #1が開催され、スタッフ兼発表者として参加してきました。
スタッフになったのはvim-jpのslackでゴリラさんこと@gorilla0513さんがVimの勉強会をやろうとしているのを見かけ、これは前々から思っていた渋谷でVim勉強会をするチャンスなのでは!?と会場提供を申し出たのがきっかけです。
そして当初は発表するネタが思い浮かばなかったのでスタッフに専念するつもりでいたのですが、少し経っても発表者枠が空いており、かつメンバーがVimConf 2018のスピーカーばかりという状態だったため、これは自分も何か話した方が良いんじゃないかと考え、ここ最近使ったgotypeとgo-treeを基にVimと外部コマンドという発表をしてきました。
ちなみに発表・デモは@thincaさんのshowtimeとquickrunを使いました。
全体の発表内容としては、短い時間ながらも初心者向けから上級者向けまであり、とても充実したものとなっていました。
特に前半の発表は自分にもそういう時期があったんだよなぁ、と非常に懐かしい気持ちになりました。
その後、一通り発表が終わった後は懇親会となり、各々がVimトークでとても盛り上がっていました。
渋谷ヒカリエ 弊社セミナールームにて ゴリラ.Vimが開催されました。懇親会では神々によるvimrcの設定サポートなど、とても和気あいあいとした勉強会でした。開催に協力することができて大変光栄です :)#gorillavim #denatechstudio pic.twitter.com/8u6mFUjACM
— DeNA Tech (@DeNAxTech) 2019年2月18日
開催前からこのイベントは盛り上がる...という予感はありましたが、予想以上に盛り上がり、スタッフとしても発表者としても参加者としても、嬉しい限りです。
トレンド入り!!!!!
— ゴリラ (@gorilla0513) February 18, 2019
#gorillavim pic.twitter.com/UTUbpFpGXv
ということで、今回ご参加いただいた皆様、ありがとうございました。
次回も是非よろしくお願いします。
(#2は少し枠が増えています!)
Vimの折畳に対応したtreeコマンド
golang.tokyo #21のDevQuizはGoでtreeコマンドを作成するというものでした。
treeコマンドといえば、以前Vimでファイル一覧をツリー表示するためのtree.vimというプラグインを作る時に使いました。
このプラグインはディレクトリにマーカーをつけることでサブディレクトリを階層ごとに折り畳んで表示します。
当時、マーカーを(Go製の)自作コマンドでつけることも検討しましたが、実装が非常に面倒くさそうだったのでVim scriptでtreeコマンドの結果をパースすることにしました。
そんな事情があったため、せっかくなのでDevQuizをやりつつ、追加機能としてVimの折畳に対応した出力形式も実装してしまおう!と思って作ったのがgo-treeです。*1
こちらはコマンドラインフラグに-V
をつけると以下のような出力になります。
$ go-tree -V github.com/daisuzu/tree.vim github.com/daisuzu/tree.vim/../ github.com/daisuzu/tree.vim/./ github.com/daisuzu/tree.vim/README.md github.com/daisuzu/tree.vim/autoload/{{{ github.com/daisuzu/tree.vim/autoload/tree.vim}}} github.com/daisuzu/tree.vim/ftplugin/{{{ github.com/daisuzu/tree.vim/ftplugin/tree.vim}}} github.com/daisuzu/tree.vim/plugin/{{{ github.com/daisuzu/tree.vim/plugin/tree.vim}}} github.com/daisuzu/tree.vim/syntax/{{{ github.com/daisuzu/tree.vim/syntax/tree.vim}}}
コマンド自体はVimから実行しても良いし、
:r! go-tree -V [DIR]
シェルで実行した結果をVimに流し込んでもOKです。
# -cでfoldmethod(fdm)をmarkerにする go-tree -V [DIR] | vim - -R -c 'setl fdm=marker' # モードラインでfoldmethod(fdm)をmarkerにする echo -e "vim: fdm=marker\n$(go-tree -V [DIR])" | vim - -R
そうするとgithub.com/daisuzu/tree.vim
はVimで以下のように表示されます。
github.com/daisuzu/tree.vim/../ github.com/daisuzu/tree.vim/./ github.com/daisuzu/tree.vim/README.md +-- 2 lines: github.com/daisuzu/tree.vim/autoload/----------------------------- +-- 2 lines: github.com/daisuzu/tree.vim/ftplugin/----------------------------- +-- 2 lines: github.com/daisuzu/tree.vim/plugin/------------------------------- +-- 2 lines: github.com/daisuzu/tree.vim/syntax/------------------------------- ~ ~ ~ ~
さらに、コマンド単体で動作するのでjob機能を使った非同期実行も簡単です。
:vnew | setl fdm=marker | call job_start('go-tree -V', {'out_io': 'buffer', 'out_buf': bufnr('%')})
このように、github.com
配下に大量のファイルがあるような場合でもVimをブロックすることなく操作を継続することができます。
現在はvimrcにAtree
コマンドを定義してgo-treeを常用しています。
filetypeをtree.vim
のものにすることで、そのまま表示するよりも少し見栄えが良くなっています。
command! -nargs=? -complete=dir -count -bang -bar ATree \ call s:async_tree(<q-args>, <count>, <bang>0, <q-mods>) function! s:async_tree(dir, depth, bang, mods) abort let cmd = 'go-tree -V ' . g:tree_options if a:bang " コマンドに!をつけたら隠しファイルも表示する let cmd .= ' -a' endif if a:depth > 0 let cmd .= ' -L ' . a:depth endif " cd後もgfできるようにディレクトリ名を絶対パスにする let cmd .= ' ' . fnamemodify(a:dir != '' ? a:dir : '.', ':p:h') execute a:mods . ' new' setfiletype tree let bufnr = bufnr('%') call job_start(cmd, { \ 'out_io': 'buffer', \ 'out_buf': bufnr, \ 'exit_cb': {channel, msg -> s:goto_first(bufnr)}, \ }) endfunction " オリジナル版はカーソル位置が先頭行になるので同じ挙動にする function! s:goto_first(bufnr) if bufnr('%') != a:bufnr " バッファを移動していたら何もしない return endif if line('.') != line('$') " 行を移動していたら何もしない return endif normal gg endfunction
予想通り実装は面倒でしたが、Vimをより快適に使えるようになりました!
*1:人が見ることはあまり考えてませんでした...