The shortest pitch to business for using Ruby on Rails
I think the best short pitch to business why use Ruby on Rails is this one:
Engineering was no longer the bottleneck

I think the best short pitch to business why use Ruby on Rails is this one:
Engineering was no longer the bottleneck
Once you agreed to a set of tests: either written by you or written by AIs but guided by you, don't let the AIs to refactor/change the tests while they are trying to implement a feature.
If your tests are there as specifications, then the implementation should be constrained by them. Therefore, they should not be changed unless you direct them to do so.
When using LLMs to write tests, you should remain in control of choosing the test cases or at least review them.
Here is an example of prompting Claude Code to identify test cases for my review before asking it to proceed with implementing the test cases.
I am looking at various personal websites mostly focused on researching personal websites of technical people mostly programmers because I want to redo my own personal website - which is old and due for a redesign.
And one thing that I noticed as a reader is that sometimes when I click on the about section the name is not written there.
I will use my website as an example:
website URL: ghinda.com
the main page is the about: https://ghinda.com
But if you read that page or use search you will notice that not even once I do write there my name: "Lucian Ghinda"
San Francisco Ruby scene is heating up
Already two events planned for this year:
1. SF Ruby AI
Hackathon - 19 July - https://lu.ma/znhcct7v?tk=17VJ2z
2. San Francisco Ruby Conference - 19-20 November - https://sfruby.com
And of course let's not forget about Monthly Ruby Meetups -> https://lu.ma/sfrub, next one being on 4th June.
Huge props to Irina Nazarova and the team there.
They are doing
fantastic work to build up the Ruby scene in San Francisco!
This is your reminder that if you run #Ruby 3.2, now would be a good time to start planning an update.
It will be EOL in about 10 months - March 2026. I know that 2026 seems far away but it is not that far in terms of dependencies and upgrades.
If you are running Ruby on Rails 7.1.x then now would be a good time to
schedule upgrade.
Security support will end on 1st October 2025 -
this year.
I used https://endoflife.date for these nice images.
For Ruby you can get the same information about maintenance at: https://www.ruby-lang.org/en/downloads/branches/
For Rails you can get the same information about maintenance at:
https://rubyonrails.org/maintenance
Why choose #Ruby on #Rails?
I read this article from
Reinteractive: https://reinteractive.com/articles/rails-8-modern-web-framework
But let’s be honest, sometimes you just want a framework that’s reliable, efficient, and doesn’t leave you wrestling with configuration files until 3 AM
I also liked this part:
Rails 8 empowers developers to build features rapidly with its convention-over-configuration approach and a vast library of gems.
I happen to agree a lot with Amanda Brooke Perino here
That’s why I almost always comment on Hacker News or any forum
where I see people still spreading old narratives about Ruby and Rails.
I think we should not just accept them and move on but reply to them and
show why the narrative is wrong. Maybe not with the purpose of
convincing the author who is spreading that narrative but for other
people who might read that without knowing Ruby and Rails. If no one
refutes these statements, people from outside our community could take
them as truth.
I believe it’s important to engage with empathy and try to have a
dialogue with those spreading this myth. We should try to understand
where they heard about it, when they last checked the status of Ruby on
Rails, and how much they know about our ecosystem.
Work at a Startup and
Bookface, two YCombinator
projects are using Rails + React + PostgreSQL
Source:
Update:
Here is a video from YCombinator where they explain the
choice for Rails:
https://youtu.be/BJjsfNO5JTo?t=801
The one with several Ruby releases: 3.4.3, 3.5.0-preview1, and JRuby 10, where Marco Roth announces herb tools and Matz suggests that Ruby 4.0 may be released this Christmas.
🚀 Launches
📅 Events:
👉 All about Code and Ruby
There are a lot of great news this week:
Here are some highlights from Code Samples:
Inside 📐 Thinking about Code Design you will find:
Read the replies around these themes to get more context and maybe get inspiration about how to approach new solutions.
Inside ❤️ Why Choose Ruby and Rails read Irina Nazarova thread that starts with powerful quote highlighting Rails as a secret superpower, revealing how successful companies have been consistently building their products with Ruby on Rails
🇯🇵 RubyKaigi 2025
In this edition, we added a section dedicated to RubyKaigi 2025. There were a lot of things shared online and until the videos will be available here is what you can find out:
🧰 Gems, Libraries, Tools and Updates
As always, we have more links to newsletters, videos, podcasts, and articles.
Read the full newsletter for free at https://newsletter.shortruby.com/p/edition-132
An example of an 1B$ exterior renovation business using #Ruby and Ruby on #Rails sharing why they think Ruby is a good choice for a business.
> “We strongly believe no other language can keep the same quick pace
that Ruby can when it comes to delivering business value"
Source:
RubyCentral
article
Remember to read ️ 📐Thinking about Code where Carmine Paolino shared that by making the transition from Puma, SolidQueue, SolidCable to another stack like Falcon, AsyncCable, AsyncJobAdapter dramatically improved LLM response speeds, Gavin Morrice shared insights on encapsulation, arguing attr_accessor exposes internals and suggests custom methods that validate input, protect state, and separate interface from implementation and much more interesting discussions.
Inside 💡Around code section read about Ruby Central announcing that the RubyGems team is strengthening the platform's foundations with new safety, reliability, and governance policies and Robby Russell asked his community about the wildest use cases of Ruby on Rails they've encountered over the years and got some very interesting and inspiring responses. You should check them out!
You will also find updates on their projects or libraries like Rubocop, solargraph and httparty.
As always, we have more links to newsletters, videos, podcasts, and articles.
Read the full newsletter for free at https://newsletter.shortruby.com/p/edition-129
I used Claude Code to refactor a series of tests from Minitest::Mock to the Mocha library this early morning.
The main reason is that I had certain parts of the tests using Mocha and others utilizing Minitest::Mock. Since other projects I work on use RSpec, I find Mocha to be closer toons in RSpec, which minimizes the context change for me overall.
I started with a simple example and provided this prompt:
Go in the test/services/bluesky/save_thread_test.rb and redo the test 'empty result when client returns empty array' to use mocha instead of simple Minitest mock
Here is what Claude Code proposed as a change. It added the line with instance_variable_set (it is not marked here as a diff because I chose 'No' when it asked me to apply, and I'm not sure why it isn't marked).
What is true is that the SaveThread object is not handling dependency injection properly: it instantiates a Bluesky::Client, but it does not accept it during initialization.
So I followed up with:
Instead of doing instance_variable_set wouldnt it be better to do depedency injection in the SaveThread object?
And I got the following answer:
It’s an interesting solution, but I don't like it for obvious reasons: the object I want to test is also the object that is altered by the test (which goes against the fundamental principles of testing).
Thus, I asked:
I prefer to change the SaveThread object itself
Notice that it included the client in the initializer, added an attr_reader for it, and also kept the previous memoized method.
In my opinion, this type of behavior reinforces the notion that you need to know how you want your code to be structured (which I refer to as code design).
It also seems more important than ever to be able to read a diff and understand the proposed changes. LLMs may improve over time, but at least for now, it appears to me that to ensure good code quality, one must first have enough experience to recognize what good quality is and be able to determine which changes to accept or reject.
This edition was sponsored by Judoscale and was created with the help of Vladut Cosmin
🚀 Launches
📅 Events:
👉 All about Code and Ruby
There a lot of code samples included;
here are just some of them:
Remember to read ️ 📐Thinking about Code, where Nate Berkopec shared advice on optimizing ActiveRecord database connections by using external poolers and a large pool setting, and Xavier Noria raised a question about Ruby's flat_map method, suggesting map_flat as a more intuitive alternative name. You can also discovere what Errol Schmidt shared their top 5 good and bad findings from Ruby on Rails app reviews based on production applications and many other interesting conversations.
Inside 💡Around code section Donn Felker shared an interesting business opportunity as he is searching for a co-founder for one of his projects, Remi Mercier asked about questions that people have when starting to work with Minitest, Sourav shared his experience learning Ruby on Rails from a React/Next.js background, posting.
🧰 Gems, Libraries, Tools and Updates
You will also find updates on their projects or libraries like Trix, activeagents.ai, Rubocop, Roda, Sitepress, standard, ruby-openai, Rubygems.
As always, we have more links to newsletters, videos, podcasts,
and articles.
Read the full newsletter for free at https://newsletter.shortruby.com/p/edition-127
I am very close to putting this "vibe coding" phrase into ignore lists. But someone saying that Ruby is not fit for vibe coding made me look into what this term is.
Andrej Karpathy introduced this in a post on social media:
But it seems to have evolved into something that is now described more close to the following definition (source: Wikipedia)
> an inexperienced person describes a problem in a few
sentences as a prompt to a large language model (LLM) tuned for coding.
Now let's take a look back at what Andrej wrote and try to add two
contexts to this:
Here are some questions I would like to ask myself:
This might be an expert blind spot for him and us, as we haven’t considered how much his expertise makes things seem simple.
I am not saying this cannot happen, but seeing this vibe coding suddenly
everywhere triggered my skepticism inside.
It is just a thought; I
am not saying this is not working or is not real. We might be in the
beginning of something great.