Issue #3 - 25 - 31 July 2022
Hello,
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 edition was created with support from @adrianthedev from Avo for Ruby on Rails (a friendly full-featured Rails admin panel) and from @jcsrb who sent me very good recommendations to include.
Kent Beck shared a simple (as in simply outstanding) idea about how to think about software design:
Gary Bernhardt shared that Ruby on Rails is 18 years old:
Stanislav Katkov shared a simple CI instruction to check if all code is loading successfully in Rails. This is very useful to catch differences in code loading between development and production:
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
Jason Sweet asked a great question that got many interesting replies:
Brandon Duff replied with:
Does DRYing it up let me remove a test(s) without decreasing my confidence? If so, lean towards DRY. If not lean towards keep.
Johnny Winn thinks that:
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
Ari Summer shared some great points about how to identify what to DRY:
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.
Ryan Bates shared a different way to handle duplications:
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.
Melanie shared a way to see duplications/DRY by thinking about how is reading the code:
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.
Julian Rubisch shares a quick tip about a shorthand to preload associations of a collection:
Nick Schwaderer asked a great question about mocking in Ruby/Rails tests
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.
Avdi Grimm replied with:
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."
Also, Stanislav Katkov shared this week a short and useful thread about using Git:
Steve Polito shared about the default scope being applied to all queries:
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.
Joel Drapper continues to share how he builds Phlex.fun. You should read this thread as it has some nice ideas if you want to pass blocks between various components of a system:
@RailsRecruiter asked a question that we see from time to time:
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.
Cody Norman shared a tip if you are Running Rails on Render:
Alexandre Ruban explained how the configure block that we see in a lot of gems works
Tobias_Petry.sql shared how to use WITH clause to select top records
Jemma Issroff announced a new Ruby conference: RubyConf Mini, while also talking about building this conference in public:
Andrea Fomera shared an useful bash command to purge merged branches from the local machine:
Prabin Poudel shared some interesting advice about Active Record Callbacks:
Andrew Mason and Julie launched a new podcast named Ruby for All, a podcast dedicated to growing devs:
I think Emmanuel Hayford shared a great description of this podcast:
Last week Shopify laid off a 10% of their workforce, and among people that were let go there were also some great devs.
Rose W started a who’s hiring thread:
On the same topic, Nick Schwaderer shared a website created by Keir Whitaker with the purpose to help people affected by Shopify layoffs: http://weworkedatshop.com
ADHD on Rails started a hard conversation in our Ruby on Rails community:
The same ideas were also explored by David Colby, who wrote an article named “Rails is back isn’t enough” and shared it on Twitter.
The same theme was also explored on the Remote Ruby podcast by Andrew Mason, Jason Charnes with Adam Cuppy.
Another good conversation started when Kyle Fox asked about setting up a staging environment:
The responses are split between staging env and environment variables:
or
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.
Nick Schwaderer shared an old article (but still valuable) discussing when to use Array and when to use Sets
GoRails published a new tutorial about customising the HTML output when using Rails Action Text.
Alessandro De Simone shared an excellent presentation done by Avdi Grimm about how to use containers called “Reproducible Development with Containers”.
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.
Matt Swanson shared a new article he published about CSS tricks while working with Hotwire and Rails.
CJ Avilla created a new video about integrating the Stripe new embeddable pricing table with Rails. SaaS FTW!
Evil Martians shared a new video created by Vladimir Dementyev about Turbo Streams and consistency.
Joe Masilotti recommended in an article a lot of good podcasts containing good recommendations for Ruby podcasts.
Mike Perham shared a new article he wrote about Sidekiq and setting request specific context.
New libraries or updates
gvl-tracing
Ivo Anjo launched a new gem that can generate a visualization of Ruby threads. More details about what this gem does and how to use it can be found in the article Ivo wrote about this gem.
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
Chris Oliver announced the release of an update of Pay gem:
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.
Outro
Thank you for reading this. If you have any suggestions of people/tweets to include please reach out to me @lucianghinda or at ideas@ghinda.com