はてなブックマーク

internal/lsp/source/options.goのdefaultAnalyzers()が返すmapに自作のAnalyzerを追加してgo installすれば使えるようになる*1。 用途としてはチームのコーディング規約をtextDocument/diagnosticでチェックしたり、チェックに引っかかったコードの修正や一部だけ実装したコードの続きを生成するtextDocument/codeActionを実行したりなど。 今まではCIで独自Analyzerとreviewdog + action-suggesterを用いてチェックやコード修正を行っていたものを、goplsに組み込むことによってより早いコーディングのタイミングで行えるようになった。 もちろん補完やコードジャンプ、コード生成(textDocument/codeLens)などをカスタマイズしてさらに便利にすることもできる

特に問題なければ go get -u ./... で全て更新してしまうのが楽ですが、更新できないモジュールがある場合は個別に更新する必要があります。 go list -m -u all で全モジュールとその更新有無を確認できるため、 -f でgo getコマンドを出力するようにし、必要なものだけ実行すると楽です。 例えばgoplsはそのまま実行すると以下のようになりますが、 $ go list -m -u all golang.org/x/tools/gopls github.com/BurntSushi/toml v0.4.1 github.com/davecgh/go-spew v1.1.1 github.com/google/go-cmp v0.5.6 github.com/google/safehtml v0.0.2 github.com/jba/templatecheck v0.

テストでaws-sdk-go-v2を使う場合はドキュメントにある通り、Clientのモックを用意するのが一般的な手法かと思います。 ただテストのためだけにinterfaceを書きたくないので、aws-sdk-go-v2が提供するClientをそのまま使える形にしたいです。 幸いaws-sdk-go-v2はClientをカスタマイズするためのオプションがあるため、大別して以下の2つの方法で実現可能です。 1つ目はAPIリクエストの送信先を変更する方法です。 こちらはWithEndpointResolverやWithHTTPClientを用いることで、リクエストをhttptestで立ち上げたサーバーなど、任意の宛先に送信できます。 2つ目はClientの処理に任意の処理を割り込ませる方法です。 各Clientは下図のStackが実装されており、WithAPIOptionsで任意の処理を追加でき

Webアプリケーションサーバーに何か大きな変更をしたいけど、既存のテストだと心許なかったので各エンドポイントにHandlerからのテストを追加することにした。 ただ全部のテストを自分1人で作っていくのはボリューム的に現実的ではなかったので、どうしたらチーム全員が書きやすいテストになるか考えて色々と整備してみた。 テストの書き方がある程度決まっている 期待する結果(want)を全て書かなくても良い テストの前後で必要な処理がわかる 具体例 テストの書き方がある程度決まっている エンドポイントごとにスタイルがバラバラだと都度どう書くか考えなければいけなくなってしまうため、基本的にはリクエストとレスポンスだけテーブルに指定するスタイルが良さそうだと考えた。 簡略化すると以下のような形式。 func TestFoo_Get(t *testing.T) { tests := []struct { n

構造体のフィールドにContextを持たせる Contextの中に参照を入れておいて任意の場所で更新する 似ている処理を匿名の構造体でまとめる 構造体のフィールドにContextを持たせる ほとんどの場合、各メソッドの引数にいちいちctxを渡すのが面倒だという理由だけで以下のようにしている印象がある。 type S struct { ctx context.Context } func (s *S) A() { // s.ctxを使う } func (s *S) B() { // s.ctxを使う } func (s *S) C() { // s.ctxを使う } ちょっとくらいタイプ数を減らすよりも素直に引数で渡すようにした方がシンプルだし、将来的に変にContextを共有するようなコードになってしまうのも防げる。 func (s *S) A() { value := getValue(

この記事はVim Advent Calendar 2020の3日目の記事です。 昨日は@mira010さんのvim pluginsをインストールしてみましょうでした。 みなさんquickfixを使っていますか？ Vimのquickfix機能はgrepやmakeなどの結果を保持する専用のバッファと、それを扱うための各種コマンドからなります。 IDEには当たり前のようにあるような機能ですが、Vimの場合は他の機能と組み合わせることで編集操作を格段に効率化できます。 :grepも:makeも、 外部コマンドを指定した引数で実行し、 ファイル名や行番号、メッセージなどの出力を解析し、 ジャンプのために使えるリストを作ってくれる のは共通です。 このリストはquickfixリストと呼ばれるもので、:copenで専用のウィンドウが開きます。 そして<Enter>キーやダブルクリックで該当行にジャンプし

goplsは更新頻度が高く、何ができるのかをちゃんと把握できていなかったので、LSPのメソッドベースで今の時点(v0.4.0)の機能をざっと調べてみることにしました。 補完(textDocument/completion) ジャンプ系 textDocument/definition textDocument/typeDefinition textDocument/implementation textDocument/references textDocument/documentSymbol workspace/symbol その他 Diagnostic textDocument/codeAction textDocument/codeLens textDocument/hover textDocument/signatureHelp textDocument/documentHighl

この記事はVim Advent Calendar 2019の6日目の記事です。 今年の4月にv8.1.1228でtagfuncという機能が追加されました。 こちらは:tagや:tselectなどのタグ系コマンド*1を実行した時、tagsファイルを検索する代わりに呼ばれる関数を設定するためのオプションです。 設定する関数の形式としては次のようなものです。 " pattern: タグ検索中に使用されたタグ識別子 " flags: 関数の挙動を制御するためのフラグのリスト " 'c' -> ノーマルモードのコマンドで呼び出された " 'i' -> インサートモードのタグ補完で呼び出された " info: 以下の情報を持つ辞書 " { " 'buf_ffname': 'フルファイル名', " 'user_data': 'カスタムデータ文字列', " } function! MyTagFunc(pa

Goにはtimeパッケージをmockする仕組みが用意されていない。 そのため、time.Nowを以下のようにして使っているコードを見かけることがある。 var Now = func() time.Time { return time.Now() } たしかにこうすることでNow()が返す値を自由に設定でき、単体テストが書きやすくなる。 ただ、関数を変数に入れるということは「その関数を処理の中で書き換えるため」という意味を持たせることになり、それをテストでしか書き換えないのであれば読み手に無用な混乱を与えてしまいそうで個人的にはあまり好きではない。 その辺りの意識が開発者の間で統一されていればそれで良いのかもしれないが、新しく入った人なんかはそうもいかないはず。 さすがに意図せず書き換えてトラブってしまうことはまず無いだろうが、自分がよく使いそうな用途でこのような使い方を避けられないか考えて

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を返すというHT

この記事はVim Advent Calendar 2018の13日目の記事です。 先月に開催されたVimConf 2018で、Migrating plugins to standard featuresというタイトルで発表してコマンドの結果をバッファに表示する方法を紹介しました。 その中で解説しきれなかったテクニックとして、以下のようなコマンドを定義しておくとL <コマンド>*1のようにして簡単に任意のコマンドの結果をバッファに表示することが出来るようになります。 command! -bar ToScratch \ setlocal buftype=nofile bufhidden=hide noswapfile command! -nargs=1 -complete=command L \ <mods> new | ToScratch | \ call setline(1, split(

VimConf 2018に行ってきました。 今年は@mattn_jpさんだけじゃなく、Vim作者のBramさんも発表するという超豪華Keynoteでした。 また、今年は去年以上に国際色高まるカンファレンスだったんじゃないかなと思います。 運営のみなさま、とても大変だったと思いますがすごく楽しい1日を過ごすことができました。 本当にありがとうございます。 以下セッションの一言感想です。 What is the next feature? by Yasuhiro Matsumoto vim-jpについてのエモい話。 自分もVimにパッチを送る時、vim-jpにはとてもお世話になりました。 それにしても(ある程度形になった)パッチを用意してプレゼンに臨むのは流石です。 Vim: From hjkl to a platform for plugins by Bram Moolenaar Vimの新

この記事はVim Advent Calendar 2017の2日目の記事です。 Vimのカバレッジはcoveralls.ioやcodecov.io上で見ることができますが、手元で見たくなることもあると思います。 そんな時はMakefileに書いてある通り、次のようにしてカバレッジを計測し、生成されたhtmlから見ることができます。 # Vimのリポジトリ直下に移動 # 各種フラグに--coverageをつけてビルド、他はお好みで CFLAGS=--coverage LDFLAGS=--coverage ./configure --with-features=huge && make cd ./src # まずはゼロカバレッジの初期データを作る lcov -c -i -b . -d objects -o objects/coverage_base.info # テストを走らせてカバレッジ情報

VimConf 2017 - An international Vim Conferenceで speakerdeck.com という発表をしてきました。 最初は25分も話すことなんてあるかな?なんて思ってたら意外と良い感じの時間になりました。 少し足りなかったところを少し補足しておくと、 gitコマンド v8.0.0512の調査で使ったgit bisect # <bad> <good>の順番で指定する git bisect start v8.0.0104 v8.0.0000 あとは都度makeし、手動で補完させてgoodかbadを判定していきました。 ※コマンドからの補完だと再現しなかったため 活動時間帯について 不具合の発見〜1次調査・応急処置 職場 2次調査〜パッチ作成 自宅・Meguro.vim patchを送った後について 質問とかツッコミは無かったの? 全く無かった パッチが小

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 @

「君のスキルはウチの新人と同レベルだけど、そんなんでやっていけるの？」と言われて今の会社に入社することを決めたのはもう4年半ほど前のこと。 前職はテスターでコードは全然書けなかったしデータベースとかも触ったことなかったけど好き勝手やらせてもらった結果、それなりのエンジニアに成長することができたと思う。 それも今月いっぱいで退職なのでちょうど良い機会だし自分じゃないとできなかった(やらなかった)ようなことを中心にざっくり振り返ってみる。 ※イマイチだったことは全部書いていくとキリがないので省略 Perl(CGI + 生DBI)製Webシステムの改善 Template-toolkitをwrapするPerlモジュールを作った HTMLがscriptタグも含めて1行ずつ丁寧にprintされていたのでメンテナンスが辛かった SQLも文字列連結で組み立てられていたり、無理矢理1行に詰め込まれていたりし

この記事はVim Advent Calendar 2016の4日目の記事です。 Vimでファイルを開くのに Unite.vim Denite.nvim ctrlp.vim など のプラグインを使っている人はたくさんいると思います。 これらのプラグインは大変便利なインターフェースを提供してくれているのですが、 依存しすぎてしまうと標準機能でファイルを開く方法を忘れてしまうかもしれません。 ...さすがにそんなVimmerはいないと思いますが、ファイルを開く コマンド キーマッピング をおさらいしてみましょう。 コマンドで開く 以下のコマンド*1の引数としてファイル名を指定します。 コマンド 説明 :e[dit] 現在のバッファでファイルを開く :sp[lit] 水平分割してファイルを開く :vs[plit] 垂直分割してファイルを開く :tabe[dit] 新しいタブページを作成してファイル

半年ほど使っていなかったのでvimrcを整理するタイミングで完全に消すことにした。 ただ長年ツートップだったプラグインなので消すに至った経緯を軽くメモっておく。 neocomplete 今の自分にはVim標準の補完機能(ins-completion)で十分だった。 自動補完が発動するとVimが固まって使い物にならなくなることがある 特定の環境でたまにしか発生しないけど発生するとすごくストレス 自動補完されないと補完自体ができないと思ってしまう そんなことはなく、基本的には常に手動補完可能 そもそも自動補完の対象になっていない補完機能もある if_luaが必須 どうせ有効化するけどプラグインのためだけにluaを入れたくはなかった 昔は自動補完が必須だと思っていたけどVimの熟練度が上がったからか、 「補完したくなったらその時にCTRL-X(or N,P)押せばいいじゃん」 と思うようになった

2ヶ月以上経ってるけど一応前回の続き。 ~/.vim/pack/bundle/opt/配下にインストールされているプラグインを更新するには、 ls -d ~/.vim/pack/bundle/opt/* | xargs -I{} git -C {} pull --ff --ff-only でやってしまうのが手っ取り早いんだけど、あえてvimでやってみた。 以下のようにjob機能を使うことでvimをブロックせず、結果をバッファに出力するといった処理が簡単に実現できた。 let s:plugins = [ \ 'vim-quickrun', \ ] "プラグインを更新したくなったら :call UpdatePackPlugins() を実行する function! UpdatePackPlugins() " 結果を表示するためのバッファを作成 topleft split edit `='[up

最近vimに追加されたpackages、timerを使ってvimが起動した後にプラグインの読み込みができたらどうだろう? と思ったのでやってみました。 以下のような設定をvimrcに追加してvimを起動するとvimが立ち上がってからプラグインが読み込まれます。 " vim起動後に~/.vim/pack/bundle/opt/vim-quickrunを読み込む例 let s:plugins = [ \ 'vim-quickrun', \ ] let s:idx = 0 function! PackAddHandler(timer) execute 'packadd ' . s:plugins[s:idx] let s:idx += 1 endfunction autocmd VimEnter * call timer_start(1, 'PackAddHandler', {'repeat':

この記事はVim Advent Calendar 2015の5日目の記事です。 Vimで補完といえばShougoさんのプラグインneocompleteが有名ですが、プラグインを使わなくてもCTRL-X サブモードで補完を行うことが可能です。 この機能はブログや書籍などでたびたび紹介されてはいますが、文字だけではイメージがつきにくいところもあるのでGIFアニメで紹介してみたいと思います。 行(全体)補完: CTRL-X CTRL-L if から始まる行と l から始まる行を補完(go) 検索対象はcompleteオプションで設定可能 局所キーワード補完: CTRL-X CTRL-N / CTRL-X CTRL-P 現在のファイルから T で始まるキーワードを補完(perl) 辞書補完: CTRL-X CTRL-K dictionaryオプションで設定したファイルから twist で始まる単語

vim 7.4.774で追加された v:completed_item をmacvim-kaoriyaで使いたくなったけど今日の時点だとまだバージョン7.4.769なので使えない... Homebrewからインストールできるらしいけど手元の環境ではエラーが出たのでコンソールからビルドしてみる。 2015/08/26追記 エラーの原因は古いrecipeを参照しているせいでした。 brew tap splhack/homebrew-splhack brew install --HEAD splhack/splhack/macvim-kaoriya でHomebrewからインストールできたので以下は通常用途では使う必要なさそう。 vim本体のソースを変更したい if_*を/usr/local以外のバージョンで使いたい 時くらいか。。。 ソースのダウンロード macvim-kaoriya git c

Goで外部リクエストが関わる処理をテストする - Qiita のfetch(url string)と違って引数でURLを取れないような関数をテストする場合、 http.DefaultTransport.(*http.Transport).Proxyを書き換えるとテストサーバにリクエストを飛ばせる。 main.go package main import ( "fmt" "io/ioutil" "log" "net/http" ) func fetch() []byte { res, err := http.Get("http://localhost:8000/test") if err != nil { log.Fatal(err) } defer res.Body.Close() body, err := ioutil.ReadAll(res.Body) if err != nil {

Vim Advent Calendar 2014の7日目の記事です。 昨日は@katono123さんのVim script + Lua で rogue.vim を作った話でした。 以前unite-notmuchというメールを閲覧するプラグインを作ったのですが、 メールを送信する機能がないため、これと組み合わせて使うメール送信プラグインが欲しいと思っていました。 探してみると postmail.vim sendmail.vim などが見つかりましたが、これらは単体で使用するためのプラグインなので他のプラグインと組み合わせて使うには向いていないようです。 やはりVimでメールを送りたいという人がいないからなのか、これといったものが見つからなかったので自作してみることにしました。 他のプラグインと組み合わせて使うというと真っ先に思いつくのがvital.vimです。 少し前から気にはなっていたので

というわけでLet's translategoogle.vim! このプラグインをインストールすると以下のコマンドが使えるようになります。 :TranslateGoogle :TranslateGoogleCmd :TranslateGoogleを実行すると翻訳用のバッファが開き、 beforeバッファに入力した内容が翻訳されます。 beforeバッファで:TranslateGoogleEnableRetranslateを実行すると 翻訳後のバッファが再翻訳されます。 デフォルトでは英語から日本語への翻訳になっているので 変更する場合はvimrcに以下の設定を追加しておきます。 let g:translategoogle_default_sl = 'ja' let g:translategoogle_default_tl = 'en' コマンドから翻訳する場合は以下のように実行します。 :

Vim Advent Calendar 2013の8日目の記事です。 昨日は@mattn_jpさんのVim script は人々の生活を豊かにしなければならないッ！でした。 以下のような開発環境で作業をするとき、ちょっとした編集なら特に困ることもないのですが、 バリバリとコードを書くとなるとさすがに素のVimは不便で困っていました。 最初はvimrcだけ転送したりとか、特定のプラグインだけを転送して使っていましたが、 色々と面倒になってしまったので、もうVim環境をまるごと転送してしまうことにしました。 Vim環境を作るのに用意したのは開発環境と同じOSの仮想マシンです。 この仮想マシンで Vimのビルド vimrcのアップデート プラグインのアップデート をしたら.tar.gzとかで固めてまるっと開発環境にばらまきます。 ただ、毎回手作業をするとなるとそのうちやらなくなってしまうので F

昨日(11/16)はVimConf2013に参加してきました 発表内容 How to suggest new features for Vim(by @kaoriya) Vimは単なるテキストエディタなので新機能を取り込んでもらうにはストーリー作りが大事 Evil is Justice.(by @esehara) Emacsの機能を使いたいけどVim風に編集したい時にはEvilが便利 How to use Git from Vim(by @c0hama) プラグインがあってもなくてもVimからGitを使うのは便利 vital.ProcessManager(by @ujm) 外部プロセスとの連携にif_xxx + スレッドは危険だけどProcessManagerを使うと簡単で安全 Do You Know About Vim Builtin Runtime Files?(by @Linda_p

ちょっと前にVim7.3のパチラッシュとプラグインのif_lua化に対応するために ゴニョゴニョしたのを(もう忘れてるかもしれないけど)忘れないうちにメモっておく。 (後半はそのうちchefとかansibleあたりでやってみたい) まずは WindowsでのVagrant環境構築 とか veeweeを使ってVagrant用のboxを自分で作る方法 を参考に必要なソフト類をインストール VirtualBox ここからダウンロードしてインストール Vagrant ここからダウンロードしてインストール Ruby ここから2.0.0(x64版)とDevKit(mingw64-64)をダウンロードしてインストール DevKitはC:\Ruby200-x64\dkに展開し、 > gem install bundler でbundlerを入れる veewee githubから持ってきてインストール >