Moar #RuboCop bug-fixes for everyone! https://github.com/rubocop/rubocop/releases/tag/v1.84.1
Enjoy!
I also realized we skipped RuboCop 1.83 due to an issue in the release script... Oh, well...
Moar #RuboCop bug-fixes for everyone! https://github.com/rubocop/rubocop/releases/tag/v1.84.1
Enjoy!
I also realized we skipped RuboCop 1.83 due to an issue in the release script... Oh, well...
연속성 2026/05: 열정적인 노력
Hanami 생태계는 `cli`, `router`, `view`와 같은 핵심 컴포넌트에 `repo-sync` 및 `release-machine`을 확장하여 저장소 관리 및 배포 워크플로우를 중앙 집중화함으로써 유지보수 오버헤드를 크게 줄이고 있습니다.
#hanami #jruby #rubocop
https://ruby-news.kr/articles/continuations-202605-fit-of-passion
LLM 에이전트에 결정론적 가드레일 적용하기
LLM이 생성한 코드가 유지보수 불가능한 스파게티 코드로 전락하는 것을 막기 위해, 정적 분석 및 린터와 같은 결정론적 가드레일은 자동화되고 객관적인 피드백 루프를 제공하여 필수적입니다.
#rubocop
https://ruby-news.kr/articles/Use-Deterministic-Guardrails-for-your-LLM-Agents
A new version of #RuboCop is out with many fixes and improvements! (https://github.com/rubocop/rubocop/releases/tag/v1.84.0)
Enjoy!
Almost 15k lines of #Ruby, bodily dragged into the present, catching up on ~6 years of updates.
Test coverage increased from "uhh basically nothing" to 65%.
And, thanks mostly to #Rubocop, the code is way neater and more maintainable now.
We even accidentally fixed some longstanding bugs!
Hugely excited for the next major dev task: moving away from "Amazon" "Web" "Services" for file hosting.
Should I use `private_constant`? I'm lazy and define constants in `private` sections so they are near to the private methods which use them and don't care if developers can access them manually. But apparently rubocop cares, so maybe I should? Or should I just disable the `Lint/UselessConstantScoping` rule?
#RuboCop 1.82 is out with many small improvements and bug-fixes! See the release notes for all the details https://github.com/rubocop/rubocop/releases/tag/v1.82.0
Enjoy the new release and have a happy holiday season in style!
If I'm working on projects which uses script languages, I want to have at least linting set up and covered in CI. However if the project didn't do any linting before you don't want to fix hundreds of issues at once destroying git history.
The right way to do this is to only lint the git diff of changes and make sure only new or modified code is linted. Developers on the project prefer such an approach.
I needed something for #ruby so I hacked rubocop-git: https://gitlab.com/routenbuch/routenbuch/-/commit/a2b763de1b77c9d4a7811302ef659bbc02d5fafc
Running rubocop for an old repository
https://dev.to/lcsm0n/adding-a-rubocop-config-to-an-old-repository-step-by-step-guide-49db
#ruby #rubocop
Glug (https://github.com/systemed/glug) by @richardf is a ruby DSL for writing MapLibre styles. But it's still #Ruby, so tools like #RuboCop work. They just need some tweaking, because what you want for a procedural programming language is different than what you want for a map design language.
I added rubocop checks to the Street Spirit style: https://github.com/pnorman/spirit/blob/main/.rubocop.yml
Like always, it's easier to add this to a new project than add it an existing one.
Is there any benefit to packaging up common rubocop configuration into a gem (aka inherited_gem) vs. just bundling said gem from git?
Examples:
https://github.com/ronin-rb/rubocop-ronin
https://github.com/Shopify/ruby-style-guide#readme
If you got #rubocop failing on EmptyInterpolation linter in the recent version (v1.76.0), there is good news for you. The issue got fixed - https://github.com/rubocop/rubocop/pull/14245
You might have noticed a record-breaking 7th consecutive bugfix release for #RuboCop (see https://github.com/rubocop/rubocop/releases/tag/v1.75.7). I just wanted to say that's not because the quality of RuboCop dropped, but because I've decided to focus on bug-fixing and polish for a while.
We have plenty of features already! 😁
I added a new configuration option to the `Naming/PredicateName` RuboCop rule: `UseSorbetSigs`. And it’s now released.
If set, it will take into account Sorbet sigs. So it will only complain if the method doesn’t start/end with the right things (like is_, has_, question mark) if there’s a `returns(T::Boolean)` sig.
Setting this option has reduced the number of TODOs for this rule in the `github/github` codebase by over 50%.