Discover more from Short Ruby Newsletter
Issue #3 - 25 - 31 July 2022
Thank you for subscribing to this newsletter.
You can read this newsletter online here. It might be too long for some email clients.
If you like it and have suggestions of people working with Ruby and sharing exciting stuff on social media, please find me on Twitter @lucianghinda and tell me about them.
This is a good advice. If your code is tested, no surprises related to Zeitwerk are going to be found. Zeitwerk succeeds and fails consistently (it eager loads autoloading!). However, there might be application code that depends on load order at top-level, better exercise it.
While also adding that
Does DRYing it up let me remove a test(s) without decreasing my confidence? If so, lean towards DRY. If not lean towards keep.
DRY isn't intended for code, it's meant to not repeat business logic. If the code repeats business logic then it needs to moved
Always exceptions, but generally if the abstraction or outcome is unclear, prefer to keep the duplication. And if changing something requires me to remember changing it in a bunch of other areas, that’s an indication to DRY things up.
My hesitation to DRY has increased over the years. I much prefer to duplicate and add comments referencing where the duplication is (both sides). I usually only DRY when it becomes painful to manage the duplication.
I think if the abstraction still makes sense to someone with waaay less contextual knowledge (aka me in a year), then DRY it up. If not, just keep the duplication.
Read the whole thread. It has some interesting takes on this.
Here are just some of the interesting replies:
It's a good thing tho ;) Hard-to-use mocks promote a design where mocks are not necessary, which is almost always a better design. RSpec mocking is too easy and people do it without understanding the consequences.
In my observation very few shops are aware of, let alone respect, rule #1 - only mock what you own. Resuling in suites where 90% of the mocks should be ripped out. And by "should" I mean "they are only obstructing code changes, not providing meaningful regression tests."
This started a nice conversation (if you read tweet replies) where the most common advice is to not use default_scope. Andy Croll shared a good article he wrote in one of the replies about why not to use default scopes.
In the thread, you can find the common recommendations (sidekiq, devise, rspec, standardrb, simplecov, factorybot, bundler audit, brakeman, faker, …) but also some good advice on not adding too many gems from the beginning or keeping it as close to the framework as possible.
Last week Shopify laid off a 10% of their workforce, and among people that were let go there were also some great devs.
The responses are split between staging env and environment variables:
If you want to receive this newsletter weekly by email, use the button to subscribe in case you did not:
Articles and Videos
Cody Norman published an excellent and fun article about using Ruby to build an ester egg into phone systems by using Twilio.
GoRails published a new tutorial about customising the HTML output when using Rails Action Text.
Brandon Weaver shared an old (2021) article about productivity for someone that has both ADHD and ASD. On the same topic about dealing with mental health, Andrea Fomera wrote a very open article about her struggle with being bipolar.
Janko Marohnic shared a video he created about Multifactor Authentication via Recovery Codes with Rodauth.
CJ Avilla created a new video about integrating the Stripe new embeddable pricing table with Rails. SaaS FTW!
New libraries or updates
Rubocop with server mode
Bozhidar Batsov announced a new release of Rubocop that now includes a server to make the linter run faster. You should read the announcement article that explains more about this. There is a benchmark that was shared in the Github issue where they merged the Rubocop-daemon gem into Rubocop:
Pay 4.0.2 release
Avo for Ruby on Rails - coming soon
Avo 2.12 is coming out tomorrow with 23 merged PRs. It features a hideable sidebar on the desktop, protocols to text fields, resource controls on the left side, and a fantastic way of extending your forms through resource tools. That will enable developers to create nested forms and pass custom data to their records through the create and edit views.
Version 2.12 release notes are here.
Thank you for reading this. If you have any suggestions of people/tweets to include please reach out to me @lucianghinda or at email@example.com