Pronto を Github Action で実行する - アクトインディ開発者ブログ
morishitaです。 rubocop や brakeman などの静的コード解析ツールを Prontoで実行するとPull Request にコメントで指摘されるので便利です。というのは、以前、キエンが紹介しました。 tech.actindi.net このときは、AWSの Lambda と CodeBuild で実行していたのですが、次の理由からGithub Actionに移行しました。 複数のAWSのサービスで構成しており仕組みが少々複雑 時間を短縮したい（CodeBuild のプロビジョニングとソースコード取得だけで3分ほどかかっていた） コスト削減可能では？（今の Github Action の利用量なら無料枠で収まるはず） 最初は公開Actionの利用を検討 上記の理由が最初にあったわけではなく、 きっかけはPronto Ruby を見つけたことでした。 これを使えば Gith
Rubocop Performanceを測ってみた。後編 - アクトインディ開発者ブログ
morishitaです。 前々回、前回から続くrubocop-performanceの指摘事項について盲従せずに確認してみるシリーズの最終回です。 前編、中編はこちらです。 tech.actindi.net tech.actindi.net 計測について 計測には BenchmarkDriver を利用しました。 Rubocopのドキュメントに bad と good の例が掲載されていますが、基本的にはそれをBenchmarkDriverで計測してみて比較しました。 例をなるべく変更せずに計測する方針で行いましたが、文字列、配列、ハッシュなどは定数にして使い回すようにしています。 各 Cop が論点にしているポイントだけをなるべく計測するため、これらの生成コストを計測に含めないようにするためです。 計測に利用したコードはこのエントリにも掲載しますが、次のリポジトリにも置いておきます。 ru
Rubocop Performanceを測ってみた。中編 - アクトインディ開発者ブログ
morishitaです。 前回のエントリーの続き、rubocop-performanceの指摘事項について盲従せずに確認してみるシリーズの２回目です。 前編はこちら。 tech.actindi.net 計測について 計測には BenchmarkDriver を利用しました。 Rubocopのドキュメントに bad と good の例が掲載されていますが、基本的にはそれをBenchmarkDriverで計測してみて比較しました。 例をなるべく変更せずに計測する方針で行いましたが、文字列、配列、ハッシュなどは定数にして使い回すようにしています。 各 Cop が論点にしているポイントだけをなるべく計測するため、これらの生成コストを計測に含めないようにするためです。 計測に利用したコードはこのエントリにも掲載しますが、次のリポジトリにも置いておきます。 rubocop-performance-me
Rubocop Performanceを測ってみた。前編 - アクトインディ開発者ブログ
morishitaです。 以前、弊社のWebエンジニアキエンが次のエントリで紹介した prontoによる自動レビューですが、今ではほかのRailsアプリケーションにも導入して使っています。 tech.actindi.net うっかりしたコードを書くと容赦のない指摘コメントが付きます。 その多くはコードフォーマットに関するものなのですが、時々rubocop-performanceにより「遅いかもしれないので書き直しましょう」という指摘をされます。 へーそうなのかーと素直に修正してきたのですが、ツールを活用するのはいいのだけど、盲従するのは良くないぁと心に引っかかるものを感じていました。 JuanitoFatas/fast-rubyにも測定結果があるのですが、ざっと見て古すぎるRubyバージョン（2.2など）での結果が更新されていないものが結構あるなぁと思いました。 また、Rubyのバージョン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
