2017-05-05

grpc-web-clientをjsで試してみた

Go gRPC JavaScript

gRPC-Web: Moving past REST+JSON towards type-safe Web APIs - Improbableを見て、grpcwebを使えばgoogle.golang.org/grpc製の既存gRPCサーバがブラウザからも叩けるようになるとのことなので試してみた。

github.com

サーバ側の変更点

DOC.mdにも書いてあるように

grpc.Serverをgrpcweb.WrappedGrpcServerに変換して
http.ServerからServeするようにする

の2点を行うだけ。

diff --git a/backend/main.go b/backend/main.go
index 0f230c4..f261ab9 100644
--- a/backend/main.go
+++ b/backend/main.go
@@ -2,8 +2,9 @@ package main
 
 import (
    "log"
-  "net"
+   "net/http"
 
+   "github.com/improbable-eng/grpc-web/go/grpcweb"
    "golang.org/x/net/context"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials"
@@ -30,11 +31,15 @@ func main() {
    gs := grpc.NewServer(opts...)
    pb.RegisterEchoServer(gs, &server{})
 
-  l, err := net.Listen("tcp", addr)
-  if err != nil {
-      log.Fatal(err)
+   ws := grpcweb.WrapServer(gs)
+
+   mux := http.NewServeMux()
+   mux.Handle("/", http.HandlerFunc(ws.ServeHttp))
+   hs := &http.Server{
+       Addr:    addr,
+       Handler: mux,
    }
 
-  log.Println("Starting server on", l.Addr())
-  log.Println(gs.Serve(l))
+   log.Println("Starting server on", hs.Addr)
+   log.Println(hs.ListenAndServeTLS("./certs/cert.pem", "./certs/key.pem"))
 }

ブラウザ側の実装

サンプルはTypeScriptだけど、JavaScriptでも書けるみたいなのでES6でやってみた。

1. まずはprotocのプラグイン、ts-protoc-genをインストールする

npm install --save-dev ts-protoc-gen

これで以下のように.protoからJavaScriptの定義ファイルが生成できるようになる。

protoc --plugin=protoc-gen-js_service=./node_modules/.bin/protoc-gen-js_service \
--js_out=import_style=commonjs,binary:. \
--js_service_out=. \
pb/*.proto

js_outで生成されるのが.protoのmessage、
js_service_outで生成されるのが.protoのserviceになっていた。

2. 次にクライアントライブラリのgrpc-web-clientをインストールする

npm install --save google-protobuf @types/google-protobuf grpc-web-client

使い方はgrpc-web-clientのinvoke()に第1引数としてjs_service_outのrpc、第2引数としてリクエスト、接続先、各種コールバック関数をオブジェクトで渡す形になる。

import {grpc} from "grpc-web-client";

import {Echo} from "../pb/echo_pb_service.js";
import {Request} from "../pb/echo_pb.js";

function EchoCall(value) {
  const req = new Request();
  req.setValue(value);

  grpc.invoke(Echo.Call, {
    request: req,
    host: "https://localhost:9090",
    onMessage: (message) => {
      console.log("onMessage", message.toObject());
      alert(message.getValue());
    },
    onEnd: (code, msg, trailers) => {
      console.log("onEnd", code, msg, trailers);
    }
  });
}

// ちゃんと動けば引数の文字列がダイアログに出てくる
EchoCall("Hello grpc-web-client");

リクエストやレスポンスなどの各フィールドには基本的にgetterとsetterを通してアクセスすることになるみたい。

既存クライアントへの影響

気になるのは既存クライアントがどうなるのかというところ。
grpc.DialOptionの認証情報の有無で見てみると次のような結果になった。

grpc.WithInsecure()

メソッド \ サーバオプション	無し	grpc.Creds()
ListenAndServe()	X	X
ListenAndServeTLS()	X	X

grpc.WithTransportCredentials()

メソッド \ サーバオプション	無し	grpc.Creds()
ListenAndServe()	X	X
ListenAndServeTLS()	O	O

つまりクライアントはgrpc.WithTransportCredentials()が必須になり、grpc.Serverのオプションに関わらずListenAndServeTLS()を使えば良いということになる。
(grpc.WithInsecure()を使っていたらクライアントを直すなりサーバを分けるなりしないといけない)

まとめ

サーバ側はけっこう簡単にブラウザ対応できるし、
grpc-gatewayと比べると

proxyサーバ
.protoのREST定義

が不要になるので管理するものが減って少し楽になりそう。

けど証明書が必要になるのはローカルでの動作確認とかがちょっと面倒になるかも…

まあフロントエンド的にはswaggerで生成するかprotocで生成するかの違いなので実際どっちでも良かったりするのかな?

2017-04-09

今更だけどLGL22をIIJmioで使い始めた

Android IIJmio

LGL22はそこそこ古い機種で、もう3年くらい使っているけど
色々とあって未だにこれを使っている。 www.lg.com

理由の1つとしてIIJmioのタイプAを待っていたっていうのもあるんだけど、
タイプAはVoLTE対応機じゃないと使えないので非対応のLGL22はアウツ…

なので結局タイプDにすることにした。

流れとしては、

1. MNP予約番号の取得

0077-75470 に電話してMNP予約番号を発行してもらう。
電話で伝えてもらえるけど後からSMSも送られてくるのでメモとか無くても大丈夫。

3. IIJmioの申し込み

普通にWebから申し込む。
SIMカードのサイズはnanoSIMを選択。

4. 回線の切り替え

実際にSIMが届いたのは申し込みから3日後だった。
「IIJmioオンデマンド開通センター」に電話して回線を切り替える。
時間が19:00までなのに気づいたのが18:56だったけどなんとか間に合った。

その後は

3845*#22# -> KDDI Only -> Network Setting -> Network Mode Change

からLTE/CDMA/GSM/WCDMAを選択して、

設定 -> テザリングとネットワーク -> モバイルネットワーク -> アクセスポイント名 -> 手動設定

からAPNを設定する。
いつ切り替わったか覚えていないけど10分後には使えるようになっていた。
電話の発着信も問題無し。

2週間ちょい使ってみて

Band1 Onlyなのが少し不安だったけど都内で生活する分には全然問題無かった。
クーポンOFFだと使い物にならない時もあるけど今の所そこまで困っていない。

2017-03-27

エンジニアにジョブチェンジしてやってきたこと

「君のスキルはウチの新人と同レベルだけど、そんなんでやっていけるの？」と言われて今の会社に入社することを決めたのはもう4年半ほど前のこと。
前職はテスターでコードは全然書けなかったしデータベースとかも触ったことなかったけど好き勝手やらせてもらった結果、それなりのエンジニアに成長することができたと思う。
それも今月いっぱいで退職なのでちょうど良い機会だし自分じゃないとできなかった(やらなかった)ようなことを中心にざっくり振り返ってみる。
※イマイチだったことは全部書いていくとキリがないので省略

Perl(CGI + 生DBI)製Webシステムの改善

Template-toolkitをwrapするPerlモジュールを作った

HTMLがscriptタグも含めて1行ずつ丁寧にprintされていたのでメンテナンスが辛かった
SQLも文字列連結で組み立てられていたり、無理矢理1行に詰め込まれていたりしたのでメンテナンスが辛かった
Perlのバージョンが古くて(たしか5.8)フレームワークの導入も難しい状況だったのでとりあえずTemplate Toolkitで凌ぐことにした
- HTMLは標準出力に吐き出してテンプレート化
- SQLはVim scriptで.cgiから抽出してテンプレート化
Perlモジュールにしたのは各.cgiで統一的なコードが書けるようにしたかったから

DBアクセス用のPerlモジュールを作った

DBIの初期化を各.cgiでやっていたのでPerlモジュールに切り出した
よく使われていた処理もまとめてPerlモジュールに持っていった
引数でテストモードを指定するとTest::mysqldに繋がるようにした
- テストコードが一切無かったのでテストを書く布石にしたかった

単体テストを書くようにした

↑の通り、テストが無かったのでTest::Moreでテストを書くようにした
- その前に.cgiは関数化されていなかったので関数化するところから始めた
- strictをつけると動かなくなるコードもたくさんあったので合わせて直していった
DB関連のテストには↑のモジュールとTest::Fixture::DBIを使った

新しい言語・フレームワークの導入

Python(Flask + SQLAlchemy)

Perlで各自が好き勝手にコードを書いているとメンテナンスが辛くなるというのがチームの共通認識だった
- 当時はコードレビューをするという文化も無かったし…
チーム内でPythonに興味を持っている人が多かったので新規システムを作るタイミングで思い切って導入してみた
DjangoやPyramidを使わなかった理由としては、
- 今までがcgiオンリーだったので重量級フレームワークに慣れている人がいなかった
- ロックインされたくなかった
- といったところ
py.testでテストし、pep8とpyflakesでコードのチェックをするようにした
今まではテーブルの管理を一切していなかったのでalembicやFlask-Migrateで管理するようにした

Go

↑でPythonを導入したはいいけどほとんどがCentOS6上の2.6で動いているのでなんとかしたくなった
- 最初は2.7や3系への移行を検討したけど、OSのデフォルトではないバージョンを使うのに反対する人が多かった
  - そうこうしているうちに2.7も終わりが見えてきてしまったし…
- パッケージの管理が不十分でリリース後にImportErrorで落ちることが多々あった
  - pipではなく、yumを推奨しているチームもあったのでバージョン違いでうまくいかなかったりすることも…
- テストやコードチェックを実施しない人が増えてきた
  - 理由としてはパッケージのインストールができないとかIDEが対応していないとか…
    - リリース後のトラブルは明らかに増えていたけど気にする人は少なかった
ということで、ある時期から新規システムを作るときはGoを使うようにしてみた
フレームワークは
- 標準のnet/http
- goji
- go-swagger
- grpc-go + grpc-gateway
- など
外部パッケージはgit subtreeでvendoringするようにした

ログ・監視

fluentdでログ収集とアラート検知をするようにした

今まではアプリケーションコード内でアラートの処理を行なっていた
- アラートの実装が漏れたり後回しにされることがあった
- アラート処理自体に問題があってシステムが落ちてしまうこともあった
アプリケーション側は適切なログレベルでログを出力するだけにし、その後の処理は全てfluentdに任せるようにした

リポジトリ

Trac(svn)からGitHub Enterpriseに移行した

積極的に移行したいという人は自分しかいなかったけど反対意見はあまり気にせず移行することにした
- 自分にとっては複数人で開発するのにsvnだと厳しかった
- 反対意見としては
  - Tracでも困らないとか
  - Tracでgitを使えば良いとか
  - gitを覚えたくないとか
    - こういう人にはなんとか覚えてもらうことにした
移行後はPull Requestでコードレビューをする文化も少しずつだけど作っていった

drone.ioの導入

GitHub Enterpriseに移行したリポジトリでは以下のようなことをdrone.ioで実行するようにした
- Lint
- 単体テスト
  - Goは自作ツールでテストを回した
    - vendorはテストから除外
    - カバレッジを集約してレポートを作成
    - カバレッジのバッジを生成
- バイナリのビルド
- ドキュメント(Sphinx)のビルド
- Pull Requestの自動レビュー

デプロイ

fabricの導入

当初は全てwikiなどに記載された手順書を頼りにコマンドを1つずつ打ち込んでいた
- 設定ファイルの変更はvi /etc/my.cnfのような手順になっていることもあった
最初に担当したシステムで耐えられなくなったのでfabric + shell scriptでデプロイをするようにした
- ansibleを使わなかったのは間にPython2.5のホストがあって使えなかったから
- chefを使わなかったのは
  - 対象ホストにインストールできないと思っていたから
  - ローカルにあるファイルを対象ホストに転送する方法がわからなかったから

chef-soloの導入

fabricだと共通処理も含めて毎回コピペして設定を作っていたのでBerkshelfが使いたくなった
実はホストの手配をした際にchefがインストールされているということを知った
ファイル転送はfabricを使いつつ、ホストの設定にはchef-soloを使うようにした

自作デプロイツールの導入

最初の頃に比べたらデプロイがだいぶ楽にはなったけどいくつか問題が出てきた
- 踏み台ホストを経由するのでファイル転送に時間がかかる
- rootになれる人しか使えないので特定の人に負荷が集中してしまうことがあった
  - 制限していたのはホストの状態を誰も把握できなくなってしまうと困るから
そこで対象ホストで実行するタイプのツールを新たに作成し
- ファイル転送は対象ホストから直接gitで取得するようにした
  - 合わせてビルド済みのバイナリやDockerのイメージもダウンロードする
- チームのメンバなら誰でも実行できるようにし、オペレーションを全自動で行うようにした
  - 開発時はアプリケーションコードだけでなく、オペレーションも含めてレビューをする
  - タグがついた最新のバージョンのみがデプロイされるようにしたので
    - 同じバージョンは1回しかデプロイされないし巻き戻ることはない
    - バージョンがわかればホストの状態も把握できる

こうしてみると改善系の活動を結構やってきたんだけど、それが偉い人にはあまり評価されなかったのは残念といえば残念。
というか2つ上の職位に要求されることが出来ていないからといって評価を下げられたのは正直根に持ってる。あとは実際の新人に入社時の自分と同じレベルのことを求めたら何度か怒られてしまったことがあるのも今となっては良い思い出かな?

2016-12-04

Vimでファイルを開く方法(基本編)

vim

この記事はVim Advent Calendar 2016の4日目の記事です。

Vimでファイルを開くのに

のプラグインを使っている人はたくさんいると思います。
これらのプラグインは大変便利なインターフェースを提供してくれているのですが、依存しすぎてしまうと標準機能でファイルを開く方法を忘れてしまうかもしれません。

...さすがにそんなVimmerはいないと思いますが、ファイルを開く

コマンド
キーマッピング

をおさらいしてみましょう。

コマンドで開く

以下のコマンド*1の引数としてファイル名を指定します。

コマンド	説明
:e[dit]	現在のバッファでファイルを開く
:sp[lit]	水平分割してファイルを開く
:vs[plit]	垂直分割してファイルを開く
:tabe[dit]	新しいタブページを作成してファイルを開く

このとき、

<Tab>(または<CTRL-I>)でファイル名の補完
- 動作はwildmode(:help wildmode)で変更可能
<CTRL-D>で入力にマッチするファイル名の一覧表示

をすることができます。

また、対象のファイル名を探すのに

*や**などのワイルドカード(:help wildcard)
:pや:hなどのファイル名修飾子(:help filename-modifiers)

を用いることもできます。

例

カレントディレクトリから1つ下のディレクトリにあるindexを探す

" <CTRL-D>で一覧を表示し、
:e */index<CTRL-D>
public/index.html  src/index.css      src/index.js

" <Tab>を押すと最初の候補が選択される
:e */index<Tab>
:e public/index.html

" もう1度<Tab>を押すと次の候補が選択される
:e public/index.html<Tab>
:e src/index.css

/usr/lib/golang/src/配下のreader.goを探す

:e /usr/lib/golang/src/**/reader.go<CTRL-D>
/usr/lib/golang/src/archive/tar/reader.go
/usr/lib/golang/src/archive/zip/reader.go
/usr/lib/golang/src/bytes/reader.go
/usr/lib/golang/src/compress/lzw/reader.go
/usr/lib/golang/src/compress/zlib/reader.go
/usr/lib/golang/src/debug/elf/reader.go
/usr/lib/golang/src/encoding/csv/reader.go
/usr/lib/golang/src/go/doc/reader.go
/usr/lib/golang/src/image/gif/reader.go
/usr/lib/golang/src/image/jpeg/reader.go
/usr/lib/golang/src/image/png/reader.go
/usr/lib/golang/src/mime/quotedprintable/reader.go
/usr/lib/golang/src/net/textproto/reader.go
/usr/lib/golang/src/strings/reader.go
/usr/lib/golang/src/testing/iotest/reader.go

現在開いているファイルの1つ上のディレクトリからpom.xmlを検索

" カレントディレクトリが/rootの状態で
:pwd
/root

" swagger-codegen/samples/server/petstore/go-api-server/main.goを開いている時
:echo expand('%:p')
/root/swagger-codegen/samples/server/petstore/go-api-server/main.go

" 最初の:hで"/main.go"、次の:hで"/go-api-server"が除去される
:e %:h:h/**/pom.xml<CTRL-D>
swagger-codegen/samples/server/petstore/java-inflector/pom.xml
swagger-codegen/samples/server/petstore/java-msf4j/pom.xml
swagger-codegen/samples/server/petstore/jaxrs/jersey1/pom.xml
swagger-codegen/samples/server/petstore/jaxrs/jersey2/pom.xml
swagger-codegen/samples/server/petstore/jaxrs-cxf/pom.xml
swagger-codegen/samples/server/petstore/jaxrs-cxf-cdi/pom.xml
swagger-codegen/samples/server/petstore/jaxrs-resteasy/default/pom.xml
swagger-codegen/samples/server/petstore/jaxrs-resteasy/joda/pom.xml
swagger-codegen/samples/server/petstore/jaxrs-spec/pom.xml
swagger-codegen/samples/server/petstore/scalatra/pom.xml
swagger-codegen/samples/server/petstore/spring-mvc/pom.xml
swagger-codegen/samples/server/petstore/spring-mvc-j8-async/pom.xml
swagger-codegen/samples/server/petstore/springboot/pom.xml
swagger-codegen/samples/server/petstore/undertow/pom.xml

キーマッピングで開く

ファイル名がある場所にカーソルを移動し、以下のキー*2を入力します。

キー	説明
`gf`	現在のバッファでファイルを開く
`CTRL-W f`	水平分割してファイルを開く
`CTRL-W CTRL-F`	水平分割してファイルを開く
`CTRL-W gf`	新しいタブページを作成してファイルを開く

現在開いているバッファにファイル名があれば良いですが、無い場合は:r!と ls、findなどの外部コマンドを用いてファイル一覧を作成してしまいましょう。

" 新しいバッファにカレントディレクトリのファイル一覧を作成
:new | r! ls

なお、:newでバッファを作成した場合、デフォルトではgfでファイルを開く際にエラー(E37)になってしまいます。
その場合、

set hidden ... ウィンドウ内に表示されなくなる際にバッファを隠す
- 全てのバッファが対象
- Vim終了時に未保存バッファが残っているとエラーになる
set bufhidden=hide ... ウィンドウ内に表示されなくなる際にバッファを隠す
- カレントバッファのみが対象
- Vim終了時に当該バッファが未保存だとエラーになる
set buftype=nofile ... バッファを書き込まれる予定のないバッファにする
- カレントバッファのみが対象
- Vim終了時に当該バッファが未保存でもエラーにならない

などの設定でバッファを保存せずに切り替えられるようにしてあげる必要があります。

また、ファイル一覧に大量のファイルが表示されてしまった場合

/{pattern}で検索したり、
:g/{pattern}/dでフィルタしてあげると

目的のファイルが探しやすくなります。

例

カレントディレクトリ配下のファイル一覧を作成

:new | r! find . -type f
" Windowsの場合
:new | r! dir . /b /s /a-d

現在開いているファイルがあるディレクトリ配下のファイル一覧を作成

" findの引数は実行前に<Tab>で展開しておく
:new | r! find %:p:h<Tab> -type f
" Windowsの場合
:new | r! dir %:p:h<Tab> /b /s /a-d

ファイル一覧を作成するユーザコマンドの定義

上記のコマンドを毎回入力するのが面倒な場合、.vimrcに以下のようなコマンドを追加しておくと便利です。

" 新しいscratchバッファ(:help special-buffers 参照)を作成する
command! -bar NewScratch new | setlocal buftype=nofile bufhidden=hide noswapfile

" :NewScratchで作成したバッファにfindコマンドの出力内容を挿入する
" FIX: <args>は""で囲まないとスペースの入ったパスが正しく処理できない(derisさん、ありがとうございます)
command! -nargs=1 -complete=dir Files NewScratch | r! find "<args>" -type f
" Windowsの場合
" FIX: <args>は""で囲まないとスペースの入ったパスが正しく処理できない(derisさん、ありがとうございます)
" command! -nargs=1 -complete=dir Files NewScratch | r! dir "<args>" /b /a-d /s

" %:p:hを引数として:Filesを実行する(<args>には%:p:hが展開された状態で渡される)
command! FilesBuffer Files %:p:h

" .を引数として:Filesを実行する
command! FilesCurrent Files .

まとめ

Vimの標準の機能でファイルを開く方法を紹介しました。

単にファイルを開くだけなら十分ですが、インタラクティブ性や非同期性が必要な場面になると物足りないところがあるかもしれません。
そういった時には組み込み関数と合わせて使ってみたり、プラグインを活用すると良いと思います。

*1:詳細は :help edit-a-file, :help opening-window, :help tab-page-commands 参照

*2:詳細は :help window-tag 参照

2016-12-03

builderscon tokyo 2016 に行ってきた

builderscon

「知らなかった、を聞く」がテーマの builderscon tokyo 2016 に行ってきました。

あのmattnさんが発表するセッションがあるということで気になっていたイベント。
チケット販売日はたまたま代休を取っていて、たまたま販売開始のアナウンスを見たのでとりあえずポチっておいたところ、なんと販売開始から3時間で売り切れてしまったようです。
普通に出社していたらチケットが残っているうちに気づくことはなかったはずなので休日出勤をしていたのが本当にラッキーでした。

参加したセッション

OSS は Windows で動いてこそ楽しい(トラックA)
動け！Golang 〜圧倒的IoTツール開発へようこそ〜(トラックB)
Automatic Smile Camera を作った話 - 親バカハックノススメ -(トラックB)
人工知能によってプログラムを有機化する(トラックA)
Highly available and scalable Kubernetes on AWS(トラックA)
CSSを破綻させない(トラックB)
Docker swarm mode などで作る PaaS モドキとその悲しみ(トラックB)
世の中の困り事はだいたいGoのコード自動生成で解決する(トラックB)
Bluetooth キーボードの作りかた(トラックA)

感想

最初のセッションの後、mattnさんにご挨拶することができた時点で満足度は100%。

他にも

mattnさんのプレゼンは内容だけでなく、テクニックにも「おおっ」となったり
- 拡大鏡を使う
- スライド上に時間、ページ数を表示する
- デモのために予め電源オプションを設定しておく
全くの専門外だけどゲームAIの進化の歴史とその裏事情!?がとても面白かったです
- 知識や思考をどのようにしてアーキテクチャへと落とし込んでいったのか
- ハードの制約やゲームバランスがあるので何でもやれば良いというわけではない
- ゲーム本体の方ではなく、開発やQAにAIを適用する

また、イベント全体に関しては、

セッションがほぼ時間通りで進行がとてもしっかりしていた
- 今まで参加したイベントは大体が後半になると時間が押してしまっていたので...
Red Bull飲み放題がヤバかった
- 会場の制約的につい飲み過ぎてしまう...
プロジェクタが低かった
- 席によっては前の人の頭でスライドがとても見づらい
注意事項などを完全に見逃していた
- ちゃんとページを見ておけば良かったんだろうけどトップページにもリンクが欲しかった

といったところ。

まあとても楽しかったので次回もすごく楽しみです。

2016-11-06

VimConf 2016 に行ってきた

vim

VimConf 2016に行ってきた。

発表メモ

Introduction to Vim 8.0 by Ken Takata

最近Vimに入った機能の中でjob, timer, packagesは使ったけど *1 *2 Partial, lambda, closureはまだ触っていないので試してみたい
日本人VimmerがVim本体に多くのパッチを送っているのは知っていたけど改めて数字で見てみると予想以上にすごかった
Vimのテストが充実してきたおかげで新機能の使用例としても参考にできてありがたい

Vim as the MAIN text editor by bird_nitryn

自分もVimに乗り換えた時は同じようにメインエディタにして使いまくった
最近はVimmerを育てる機会の方が多いので参考にしたい

Denite.nvim ~The next generation of unite~ by Shougo

unite.vimを使っていてパフォーマンス的な不満は特になかったけどデモに触発されてMacVimでDenite.nvimを試してみたらすごく速かった
Decoupled UIはちょっと気になるのでそのうち試してみたい

Go、C、Pythonのためのdeoplete.nvimのソースの紹介と、Neovim専用にpure Goでvim-goをスクラッチした話 by zchee

neovimに全然興味なかったけど発表を聞いてとりあえずインストールしてみることにした
nvim-goの作りが気になるのでソースを見てみる

エディタの壁を越えるGoの開発ツールの文化と作成法 by tenntenn

自分の近くでは「Goやったことある方」でほとんどの人が手を挙げていた
gofmt(ごーふむと)、GOOS(ぐーす)、GOARCH(ごーち)
ファイルを生成するツール *3 は作ったから次はファイルを書き換えるツールと思っていたのでgorenameのところがとても参考になった

vim-mode-plus for Atom editor by t9md

vim-mode-plusのアーキテクチャとそこに到るまでの考え方がただただすごかった
- Vimでテキストを編集するということへの捉え方
- モーションやオペレータの表現
persistence-selectionはVimにも欲しい

Vimの日本語ドキュメント by MURAOKA Taro

「翻訳作業に手と目と知恵を貸してくれる人募集中」
- リファレンス&ユーザー・マニュアル
- メッセージ
- メニュー
- など
脱線しかけたのはAho-Corasick法(文字列探索アルゴリズム)
技術者はSPOFは排除したいはず

Vim script parser written in Go by haya14busa

Fixer、Formatterに期待!
stacktrace便利そう
- これがあればthemisでカバレッジ取れる!?
Vim8とV8(node)は紛らわしい?

僕の友達を紹介するよ by aiya000

aref-web.vim使ってみる

Best practices for building Vim plugins by thinca

:help design-goalsは知らなかった
シャイで有名なthincaさんがハイテンションで発表に懸ける強い想いが感じられた

感想

「Vimハラスメント」に気をつけようと思った
- (自分としてはネタのつもりだけど)職場でよく「Vimを使おう」と言っているので...
  - 開発関連のやるべき事をやってくれていれば何も言わないけどできていない
  - Vimだったらそのためにどうすれば良いかはいくらでもサポートできる
  - というのが言い訳
今回はチームのメンバ(2名)に参加してもらう事に成功した
- 楽しんでもらえたようで良かった

終わりに

発表者のみなさま、スタッフのみなさま、会場を提供してくださったミクシィさん、
ありがとうございました。
来年も是非参加したいです。

*1:vim pluginのbackground loading

*2:vimのjob機能を使ってプラグインを更新する

*3:grpc-bench-generator

2016-09-23

gRPCサーバのベンチマーククライアントを生成する

Go gRPC

google.golang.org/grpcでサーバ書いたのでそろそろベンチマークしてみようと思ったらgoogle.golang.org/grpc/benchmarkという便利そうなパッケージを発見した。

早速clientをビルドしてみたけどgrpc_testingパッケージ専用だったので中のmain.goをテンプレート化して任意のパッケージで使えるようにするツールを作ってみた。
※今のところstreaming RPCには非対応