It's been months since we started having weekly gatherings with @lucian . It was inevitable that we would start some project together.
Since we both love Ruby, we've decided to write a book about our favorite programming language.
It's been months since we started having weekly gatherings with @lucian . It was inevitable that we would start some project together.
Since we both love Ruby, we've decided to write a book about our favorite programming language.
Yeat, many teams don't take full advantage of amazing linting tooling available in Ruby ecosystem. Other teams obsess over things that don't really matter that much.
There is a healthier and more productive way to use these tools. And we're going to write about that.
Interesting fact:
Term “lint” comes from the name of the first lint tool, which was developed in the early 1970s by a team of Bell Labs researchers led by Stephen C. Johnson. The original lint tool was designed to analyze C source code for potential errors and stylistic issues.
Nowadays, “linting” term is almost synonymous with “static code analysis”. A method of computer program debugging that is done by examining the code without executing the program.
I'm not a fan of this limiting synonym, but we will not go against the grain.
We'll be writing how to start eliminating thousands of possible issues from production code auto-magically. And we need your feedback to write a really useful book - because we're doing it live.
Want to join us? Subscribe https://lintingruby.com!
@timtilberg haha, would be awesome to have a public debate on every subject. But I'm not sure, that i'll be able to moderate this before everything turns into a fist fight. :)
I do agree, that most of the opinionated linters feel frustrating. And it seems that linters get a bad rap because of that...
But I feel, that there is a more balanced approach, without all the opinionated stuff, and I need to write about it.