It took me a while to figure out the correct collection of magical incantations required to make RuboCop run in a GitHub workflow, but ONLY on the files that were changed within the PR. This is a useful configuration if you have a codebase that has not yet been modified to satisfy all your “Cops”. I’ve also included a version of the same file that you can use when you’re ready to have RuboCop run on all non-excluded files.
One of my coworkers was trying to understand the differences between libraries, frameworks, and DSLs and asked me
…how do I know what i’m using when all these things are
interacting and being used within each other, etc
To some degree, you don’t, and it doesn’t matter, but that’s not a very helpful answer. So let me step back and talk about what each of these are.
Libraries are the simplest. A library is just a collection of code intended to be reused. They’re typically packaged using a package manager, but it doesn’t need to be “packaged”. It could be just some file of useful code that you load into your code like any other source file.
You can tell weather or not someone really “gets” unit testing by asking them one simple question, “Do you use mock objects?” Almost invariably, they will say “no”. Even people who have totally gotten the testing religion. It’s like watching someone pray to a statue of Jesus; totally oblivious to the fact that Jesus himself is standing four feet away reading a book.
This is partially due to the fact that most geeks don’t actually know what a unit test is. They think that testing the methods of a specific class constitutes a unit test, but that’s only part of the story. A unit test test is when you test the methods of a specific class in isolation, and the difference is critical. You know how some people call us “computer scientists”. Yeah, well this is the science part.
I keep thinking back to a short comment at BarCamp Manchester in the Unit Testing talk. When asked if anyone had written an app with 100% code coverage the guy beside me raised his hand. Now I’ve been advocating for a while now that it’s essentially wasted time to bother testing your getters and setters, and when I mentioned something to this effect he said, “How do you know you haven’t made a typo in a variable name?”
Back in January of 2006 Ezra Zygmuntowicz came up with an exceptionally cool Rails plugin that, IMNSHO, should be in rails core. It’s called ez_where and it’s svn repo is here.
What’s so cool about ez_where? Well, the to really understand it’s beauty you have to step back to one of core concepts that’s at the heart of frameworks like Rails: Database Abstraction and Object Relational Mappings. Before these concepts really came into their own we were all writing raw SQL commands in our apps. Now we interact with a layer of abstraction that lets us work with the objects we’re actually programming with instead of database structures. Except, that’s not quite true with Rails. With rails you end up writing things that are possibly more complex than the SQL statements we’ve been trying to avoid. Here’s a particularly egregious example from a ticket system I’ve been working on:
