CRuby 2.4から整数がIntegerに統合されるとともにその子クラスであるFixnumとBignumが廃止されたが、下記のようなコードを使えばそれを手軽に判定できる。
if 1.class.name == "Integer" # 統合後の処理 else # 統合前の処理 end
このようにバージョン番号を使わずに判定することで、JRubyなどの別実装で同様の変更がかかっても同じコードで対応できる。
ちなみにdefined?(Fixnum)でも同じ判定ができるんだろうけど、
class Fixnum < Integer; endしてるとかといったあたりが気になるので、今回のような判定方法のほうが個人的には好き。
lestrrat-go/server-starterというホットデプロイしてくれるものがある。
これをAlpine LinuxなDockerコンテナ上で使おうとしたら下記のようなエラーが出た。
standard_init_linux.go:190: exec user process caused "no such file or directory"
結論から書くと、原因は依存ライブラリがdynamic linkされた実行ファイルを使っているのが原因だった。どうやらReleasesに置かれている実行ファイルはlibcなどが環境にある前提のものらしく、Alpine Linuxにはそのようなものはないので上記のようなエラーが出てしまっていた。
というわけでgolangで書いたアプリケーションのstatic link化を参考に手元でstatic linkしたものをビルドして使ったら上記のようなエラーは出なくなった。
cd $GOPATH/src/github.com/lestrrat-go/server-starter/cmd/start_server GOOS=linux GOARCH=amd64 go build -a -tags netgo -installsuffix netgo --ldflags '-extldflags "-static"'
しかしここで指定してるnetgoとは何なんだろう :thinking:
Swagger書きたくない…！というところからProtocol Buffersのサービスとメッセージ定義をもとに似たようなことができないかと考えていたところ、yuguiさんのprotocプラグインの書き方を見てできそうな気がしたので試してみた。
そうして上記記事と同じことをprotobuf gemを使って実装してみたのがこちら。
ここでは大したことはできてないけど、plugin.pb.rbやdescriptor.pb.rbを見る限りprotoファイルに記述されている内容はすべて取れそうなので、がんばれはできなくはなさそう。
ただ結局やりたいことって更新されたprotoファイルから継続的にスケルトンのコードを上手いこと生成、挿入することだったりするので、一ファイルを毎回上書きするようなprotocの使い方には合致しないのではという気がしている。もしかしたらCodeGeneratorResponse::Fileのinsertion_pointがそこら辺を上手いこと面倒見てくれるのかもしれないけど、要調査。
ちなみにProtocol Buffersを扱うgemとしてはgoogle-protobuf gemもあるが、現状こちらだけを使ってprotocプラグインを書くことはできない。なぜならこちらには前述のplugin.pb.rbとdescriptor.pb.rbに相当するメッセージの定義が無いためオリジナルのprotoファイルから生成する必要があるのだが、オリジナルがproto2で記述されているため、proto3しか扱えないprotocのrubyの処理系では現状生成することができないからだ。 両gemでインターフェースやクラスツリーは統一されているだろうからprotobuf gemのplugin.pb.rbとdescriptor.pb.rbだけrequireしてgoogle-protobuf gemで処理を実装することもできるかもしれないけど、あまりメリットはなさそう。
作った。
npmだと.envを読み込むdotenvというライブラリはあるんだけど、それをもってコマンドを実行するコマンドは提供していなかった。Ruby版のdotenvに含まれるdotenvコマンドみたいなやつ。なので同じようにdotenvというコマンドを実装した。名前は変えた方がよかったんだろうか :thinking:
実装するにはKernel.execのようにexec(3)ができるメソッドが必要だけど、nodeでそれをやるにはkexecというnpmを使う必要があった。child_process.execなどは結果をコールバックで受ける形になっていてプロセスは切り替わらない。で、このkexecがgypを使っていてインストールをするにはコンパイルが必要になり、ピュアJavascriptなdotenvに追加するのはすでに導入している人がアップデートするときには辛そうだなーと思ったので別のパッケージとした。
引数の処理がナイーブな感じがしているので、また変更を入れるかもしれない。
もともとhubotを起動するためにhubot-dotenvを使っていて、わざわざ.envファイルを読み込むためだけに別のnpmを入れるのもなんかな…と思ったのがこの開発の動機だった。でもよくよく考えればhubotの場合はbin/hubotというシェルスクリプト経由で起動できるようになっているので、ここに.envを読み込むシェルスクリプトを組み込めばnpmを増やす必要はないということに気づいた。生成されたコマンドを書き換えることにはなるので好き好きではあるけど、備忘録として。
作った。
ゲームのマスターデータをTSVファイルで管理していると、内容自体は衝突していないのに同時に同じ箇所に書き足したということで衝突してしまうことがある。あとはエディタの設定で末尾の空白スペークが消えてしまったとか。そういった単純なコンフリクトをこのコマンドは自動で解決してくれる。
使い方は二つあって、一つ目は
fix_tsv_conflict <目的のTSVファイル>
とするとどこを解決したか、もしくは解決できなかったかを標準エラーに書き出し、最終的な結果を標準出力に書き出す。もう一つは、-oオプションをつけることで標準出力に書き出さず直接ファイルを書き換える。
fix_tsv_conflict -o <目的のTSVファイル>
このコマンドが使える前提として、行の先頭に整数値を使ったidカラムがあることがあるので要注意。
コンフリクトの解決方針としては次のようにしている。
ruby gemなので、gem installして使う。
gem install fix_tsv_conflict
今回初めてRefinementsを使ったけど、Travisで複数のRubyバージョンをまわしていたらバージョン間のRefinementsの対応の違いによってちょこちょこ落ちることがあった。新しいバージョンほど適用できる範囲が増えているので着実に進化しているのだなと感じた。
あと今回、データは標準出力に、通知は標準エラーにというのを意識して実装した。このコマンド自体は実際は-oオプションで直接上書きするのであまり関係ないかもしれないけど、他のツールをパイプして使ったりログを記録したりとかやっているとどちらに出力するかで自動化やモニタリングのしやすさが変わるのを最近感じている。
