goのモジュール名についての備忘録

先日、お仕事のGoリポジトリで、staticcheckによるDeprecated警告が効かない、という事象が発生しました。 諸々調査していくと、どうやらstaticcheckではGoの標準パッケージに対する警告をスキップする処理がされており、条件が合致してしまったため上述の事象が発生していたことがわかりました。 staticcheckは、モジュール名に "." が含まれていれば標準パッケージをみなし、警告を抑制するという方法論で標準パッケージを判定しているようです。

対処法としては、「Goのモジュール名は "." を含める」になります。

staticcheck 2023.1.3 (v0.4.3) https://github.com/dominikh/go-tools/blob/master/staticcheck/lint.go#L3072

react-scriptsの雑感

気軽にreactを使ったWebサイトを作るとき、create-react-appを使ってreact-scriptsを前提とした構成を作ることはあるのだけど。 じゃあ本格的に開発しましょう、ってなるタイミングで、どうしてもwebpack.config.jsをいじくり倒したいときとか、設定を細々チューニングしたいことは多い。 そうなると、react-scripts ejectして現行の設定ファイルをベタ管理にするか、react-app-rewiredで差分管理する感じになると思う。

react-create-appで作成したTypeScriptのプロジェクトのwebpack.configを上書きする | I am mitsuruog

ただ1つのWebサイトに腰すえて開発していきましょうってタイミングでもなければ、設定は使う分だけ最小限で済ませたい。 なので、結局のところ自分が使う最小限の設定雛形をメンテしつつ、開発タイミングで雛形から構成を起こすほうがユースケースに合っているのかなぁと感じる今日この頃。

goen v0.0.10について

以下の不具合を修正しました:

  • foreign_key:"col1,col2" のように、 foreign_key に複数カラムを指定したときに生成されるIncludeLoaderがうまく動かない

これは結構根が深い問題でした。 goenではIncludeLoaderの動作時に、ScopeCacheというものを引き渡すことで、IncludeLoaderによる参照エンティティのロードが無限ループに落ちないようにしています。 ScopeCacheでは、PKやFKに対しロード済みのエンティティをマッピングして保持します。 そしてScopeCacheに保持されたエンティティを、IncludeLoader側で引き出して使っています。

今回の不具合では、IncludeLoaderがScopeCacheからエンティティを取得するとき、期待通りにScopeCacheに保持されていないエンティティの処理をスキップしていたことが原因で、ScopeCache.GetObjectからエンティティが取得できないことがありました。 修正のために、ScopeCacheに非互換な修正を入れましたが、ScopeCacheは基本的にgoen内部で使っている用途がほとんどなので、影響はないだろう、という見込みです。

コード生成用のテンプレートを修正したため、goenの更新後にgo generateを実施する必要がありす。 ご注意ください。

小さなvimrcを複数用意しておくと便利ですよ、というお話

本記事は Vim Advent Calendar 2019 - Qiita の18日目の記事です。

nginxの設定ファイルを編集するシチュエーションを題材にして、小さなvimrcを取り回すvimの使い方について紹介しようと思います。

さて、nginxの設定ファイルを編集した後に、 nginx -t を実行することで、設定ファイルの文法チェックが行えます。 また変更した設定ファイルをnginxプロセスに反映させるとき、 systemctl reload nginx などとします。 最近だと、dockerで動かすこともあるため、 docker exec "${container}" nginx -t であったり、 docker restart "${container}" であったりと細かいコマンドは変わるでしょうが、今回はそういうことは無視します。

ということで、通常ではnginx設定ファイルを編集するにあたり、以下のような手順で実施することになります。

  1. vim /etc/nginx/nginx.conf
  2. nginx -t
  3. systemctl reload nginx
  4. 動作確認

もし、ローカルマシンのみで網羅的な動作確認ができるような設定であれば、ローカルマシン上に自分好みの環境を用意すれば事足ります。 ですが、例えば開発用の共有環境に(nginxだけではない)フルセットの構成が用意されており、網羅的な確認作業は共有環境上で実施するようなケースが割と多いです。 共有環境では、nginxの稼動サーバにsshし、素のvimは入っているけれどvimrcやpluginでのカスタマイズはできない、などの制約があったりします。

そういうときに使うために、私は↓のようなコピペ用のコードを用意しており、一時的なvimrcを用意して vim -u tmp-vimrc とかで編集作業をします。

set nocompatible

augroup gyokuro
  autocmd!
augroup END

function! s:reload_nginx() abort
  let res = system('nginx -t')
  if v:shell_error != 0
    echo res
    return
  endif
  let res = system('systemctl reload nginx')
  if v:shell_error != 0
    echo res
    return
  endif
endfunction

autocmd gyokuro BufWritePost /etc/nginx/* call s:reload_nginx()

やっていることは単純で、nginxの設定ファイルを編集したとき、自動で nginx -t で文法チェックかけて、問題ないようなら systemctl reload nginx を実行しているだけです。 単純ではありますが、あるのとないのとでは、面倒さが結構違ってきます。

紹介したスニペットはnginxに閉じていますが、素vimに対して、ワンポイントでかつコピペ程度の手間で使える機能(スニペット)を作っておくと、取り回しが良いです。 個人的には、pluginでモリモリするよりも、色々な環境で素vim使って作業していくことを想定して、こういう工夫をしています。

人により好みはあるかと思いますが、結構便利なので、試してみてください。 そしてもっと良い方法あるよっていう方がいましたら、是非教えてください。

以上です。

golangでビルドされたバイナリに含まれるパス情報を消す

goでビルドしたバイナリには、通常はビルドに使われたgo等のフルパス情報が含まれている。 例えば /home/kamichidu/local/opt/go/default/bin/go みたいな。

気になるようなら、消すためにはbuild flagsに -trimpath を指定する。 go buildgo install 等でもbuild flagsが渡せるので、同じで考えて良い。

go generateであったりの外部ツールを利用する場合、 -trimpath では対応できない。 (当然と言えば当然だけど。)

個人的には、そこまで気にする必要性は滅多にないと思う。 以上、備忘録。