| linters-settings: # 設定のデフォルト値は、https://github.com/golangci/golangci-lint/blob/master/.golangci.example.yml で確認できる | |
| depguard: # packagesに宣言されているモジュールの取り扱いに関するルール。ブラックリスト形式で使っているので、列挙したものを使うとエラーになる。 | |
| list-type: blacklist | |
| packages: | |
| - golang.org/x/xerrors # go 1.13で必要な機能はすべてerrorsに取り込まれたので使わない | |
| - github.com/rs/zerolog # ログ出力用のライブラリはプロジェクト内部に作ったファクトリ関数経由で使うため | |
| packages-with-error-message: | |
| - golang.org/x/xerrors: "エラー処理は標準のerrorsを使って下さい。スタックトレースが必要な場合のみpkg/errorsを使って下さい" | |
| - github.com/rs/zerolog: "ログ出力は example.com/myproject/logger#Newから利用して下さい" | |
| dupl: # コードのコピペを検出するルール。 閾値のトークン数を越えるものをエラーにする |
インスタンスの起動スクリプトとかを書いてるときによく欲しいと思うやつです。
例えば、 service nginx start が実行されたあとに curl -i localhost | grep "200 OK" とかをすると、サービスがそれなりに動いていることが確認できてよかったりするのですが、あまりにも直後だとサーバの起動が間に合わず、curl が失敗してしまいます。nginxだとまだましだけど、アプリケーションサーバだとそれなりに時間がかかったりする。
古典的な解決方法は、 sleep 30 です。簡単だけど、アプリケーションが巨大になってくると30秒では起動しないこともある。じゃぁ sleep 60 が妥当か？でも、サーバインスタンスの起動スクリプト全体はできるだけ早く立ち上がってほしい。困った。
なので、curlが成功するまで叩き続ける、みたいなスクリプトに仕上げたくなるわけです。
これを読んでる。
この本の中で「トランザクティブ・メモリー」という話がでてきた。概要は以下のコラムに書いてる。
| import java.io.IOException; | |
| import java.rmi.activation.ActivationException; | |
| class Hoge { | |
| static interface Function<T, E extends Throwable> { | |
| public void apply(T hoge) throws E; | |
| } | |
class Foo {
type L[A] = Either[String, A]
foo[L](bar)
}↓
| @if (0) == (0) echo off | |
| cscript //nologo /E:JScript "%~f0" %* | |
| exit /b %ERRORLEVEL% | |
| @end | |
| var args = WScript.Arguments | |
| if( args.length < 2 ){ | |
| WScript.Echo("Usage: cscript ln.js [-s] FILENAME TARGET"); | |
| WScript.Quit(1); | |
| } |
2015/01/15時点の情報です。
v0.1.3が計画されてるけど、initial releaseのv0.1.0からはbugfixや細かな修正がほとんどで、大きな進化はしてない。 コミットもあまり活発ではない。 もしかしたら、Facebook社内でprivateブランチを育てていてまとまったところで出してくるのかも。 （JS等に比べて）開発者人口の少ないOCaml実装というのも、プルリクが集まりにくくOSS的な加速的進化が起きにくい原因かもしれない。
