RuboCopをRuby 3.1で試したら意図しない挙動が顕れたので、取り急ぎIssueを出した。
そんなに詳しく調べてないけど、多分重複したIssueは無いはず…
作業配信をやると運動不足気味になるはずなので、配信中に何か1つ運動をする、という習慣を取り入れてみることにした。腕立て伏せ1回 (本当に1回)、とかでOK。
前述のRuboCopのIssueにPull Requestで対応してくれた人がいて良かった。
auto-correctがsafeかunsafeかを判定する機能を付けて、safeなやつだけpickする機能を付けたい
auto-correctがsafeかunsafeかを判定する機能を付けて、safeなやつだけpickする機能を付けたい
最近の .rubocop_todo.yml だとコメントに記述してくれるので、それをパースすれば良さそう。古いやつはどうなんだろう、ソースコードを見に行けばわかるか？
pickだけでなく、correctのときにも --auto-correct を使うか --auto-correct-all を使うか、という選択がある。
ソースコードを奥深くまで辿っていかないと分からない。外部コマンドでRubyを動かして辿らせることもできるが、.rubocop_todo.ymlのコメントを参照する程度に留めておく方が手軽で良いだろうと思う。
デフォルトではsafeなcopだけを対象にし、only_safe: false というオプションが指定できるようにした。
https://github.com/r7kamura/rubocop-todo-corrector
r7kamura/gialogにRSS配信機能を付けると良いのではとは前から思ってはいるが、r7kamura/diaryのような使い方を考えると、単純にIssueのdescription部分だけを、Issueがつくられたタイミングで配信しても意味が無い。
そこで、前日分までの直近20件程度の記事について (前日分ということはつまり日記や日報としての利用を想定しているのでgialogには付けられない)、IssueとIssueCommentのdescriptionを (hr要素か何かで区切りつつ) 全て繋ぎ合わせたものを配信する、ということを考えた。これであれば、前日分のその人の日記や作業ログ的なものをまとめて読めて、新聞的な感じで楽しく読めるし、書いた人も昨日の振り返りが出来て嬉しいはず。
ただ、この仕組みを入れると定期的にビルドするようにスケジューリングか必要になる。このように作業ログ用ツールとして特化させていくと、豪華になっていくので、r7kamura/nippoみたいなテンプレートリポジトリを更につくって、そこに機能を足していく方がいいかもしれない。
これを何とかしないとNext.jsでRSS吐くのがいつまで経ってもだるいままだ。
Generate non-HTML files on next export · Discussion #36640 · vercel/next.js
GitHubのコメント欄にフォーカスするためだけのGoogle Chorme拡張、をつくるか悩んでいて今日はつくらなかった。GitHubにキーボードショートカットを増やす拡張、であればつくってもいいと思う一方で他にGitHubで使いたいキーボードショートカットがそんなにないのでそこが逆に難しい。あと5個ぐらい思い付いたらつくってもいいと思う。