1️⃣ Noel Rappin published an article about Ruby And Its Neighbors: Perl

2️⃣ Sam Ruby published an article about Testing Frozen String Literals in Production

There is actuall an updated version of running the same test Frozen String Literals Redux - A More Rigorous Test.

3️⃣ Vinay Keerthi published a new article about Ruby Blocks

4️⃣ Sid Krishnan published a new article about How does Turbo listen for Turbo Streams?

5️⃣ Avo published an article about Open Graph Image Generation in Rails

You can find more articles to read in the Short Ruby Newsletter: https://newsletter.shortruby.com/p/edition-153#more-content

Amabile, Teresa M. “A Model of Creativity and Innovation in Organizations.” Research in Organizational Behavior 10, no. 10 (January 1, 1988): 123–67. https://ci.nii.ac.jp/naid/20000708825.

Here is how someone described where they were looking for inspiration: in variations and deviations

And then talking about their work environment they hint at something that I also talked in the past: there has to be slack time (and not time on Slack) during the work to be able to thinker with things without having the pressure of always making something that is directly productive:

Ghostty introduced this section to their CONTRIBUTING.md file

And I think this part here is a normal expectation for any AI code contributed to a serious project:

I've been using git worktree for at least five years now.

Here's how I set things up at work.

Say I work on short_ruby project. 

I create a folder called short_ruby and inside I have: 

• `short_ruby/main` -> which will always remain as head main
• `short_ruby/pairing` is where I pull branches for code reviews, dig deeper into changes, or show draft code to a colleague.
• `short_ruby/feature_<id>` is a new worktree I create for each feature I work on, and I remove it when I'm done.

Why these folders:

1. I always keep a local copy of the current main branch. This helps me review changes or start something new, since I can quickly check how production works if main is what's deployed.
2. I also want to quickly access any branch I'm reviewing, while still being able to see the main branch. Having separate folders makes it easy to switch between them.
3. I keep a folder for each feature, which is similar to using branches. The difference is that I can always check main or another branch while working on a new feature.

In case you wonder what do I do with DB: 

• When using SQLite this problem is solved by default as each folder will have their own database
• When using with PostgreSQL/MySQL I keep a single database and always do: rails db:reset + rails db:migrate when I have to run migrations inside a folder. In practice it works well. 

Why do I activate Vim in any code editor I work with? 
Imagine a list of emails in a Google Sheet in a single column, one per row, and need to convert it to a Ruby array.

1️⃣ Open Vim
2️⃣ Paste the list
3️⃣ :%s/^/"/ 
4️⃣ :%s/$/",/
5️⃣ Add `[` and `]` 

Done. Enjoy coffee!

I launched a personal newsletter at newsletter.lucianghinda.com

This morning, I sent my first email. 

Why start this newsletter? I had newsletters set up in multiple places, and managing them became challenging. I want to focus on writing.

What will you find inside? 
Mostly the same content I share on social media: Ruby, Rails, Testing, Creativity, and tech-related topics that I find interesting and worth sharing.

If you enjoy my content here, you'll appreciate what you find there.

This isn't a replacement for the Short Ruby Newsletter, which will continue as usual. My personal newsletter is about my interests, passions, and writings, all related to Ruby, Rails, and tech.

In the Short Ruby Newsletter, my role is as a curator, ensuring we include what's essential for the Ruby community. In my personal newsletter, I can focus on what I personally enjoy and find intriguing, while also compiling my writings from various sources.

Here is an example of the first edition: https://newsletter.lucianghinda.com/p/welcome-to-my-personal-newsletter-a144

Whenever I create a new table or column in a web app, I aim for clarity so that anyone connecting directly to the database can easily understand it.

My heuristic involves designing the database so that direct queries yield sensible results without needing any additional information beyond the database itself. 

There are trade-offs with this approach. For example, you might sacrifice some performance, so keep that in mind.

Let me give some examples: 

1. Enums: String vs Integer
Using integer enums like priority = 0, 1, 2 can be confusing when querying directly.

Using string enums like priority = 'urgent', 'medium', 'low' makes results instantly clear when running SELECT *.

👉 Use string enums unless performance is critical.

2. Nullable vs Non-Nullable
If something is required logically, enforce NOT NULL.
Don’t leave half your schema nullable "just in case."

👉 This makes the schema self-documenting.

3. More generally any validation that can be added on the DB should be there

Eg: user_invoices might contain a unique validation on user_id + invoice_id so add a unique index on ['invoice_id', 'user_id'] on that table

4. Relationship context 

If you need to store the creator of a record, don't just add user_id. Consider a more descriptive name like creator_id or even created_by_author_id. 

Inspired by Igor Aleksandrov post on running migrations multiple times:

When you open a Ruby file who's already there?

puts self.inspect \# main
puts self.__id__ \# 16 
puts self.class.name \# Object

puts method(:inspect).owner.class \# Object

Why does inspect say main? 

This is a special case defined in the Ruby implementation:

docs.ruby-lang.org is explicit about this behavior

What other objects were instantiated before the main one? It seems only another one: Class

Here are two resources that I think are important to read when you are working with Time in Ruby.

It's About Time (Zones)

This article is a perfect base for understanding working with Time and timezones in Ruby and Ruby on Rails. 

I think the core idea of the article is always keeping in mind in Rails there are 3 timezones:

Scheduling events in user time zone

For this there are two articles that you should read: 

• A Case Study in Multiple Time Zones
• Scheduling things in user's time zone

I will add here the main idea that I extracted from both of them but you should make sure to read them as they present more ideas and options and specific recommendations when scheduling events in user timezone.

1. For recurring events that must run at a user's specific local time (e.g., "every day at 9:00 AM"), one option is to calculate and persist the event's hour relative to UTC (hour_in_utc). Another option is to use a library that knows how to compute the next occuring event and not do the calculation yourself.
2. When considering timezones, please remember that time zones are data that change over time (due to reasons that could be social or political so future DST/rules can change), and you'll need to make sure that you sync your Timezone data. 

How to create a new Rails app with Rails 8.1.0.beta1

gem install -v 8.1.0.beta1 rails

rails _8.1.0.beta1_ new mynewrails81app

You can also generate a new Rails app using the main branch. Rails has a long history of being used by major companies on the main branch, making it as safe as possible to run. While it's not an official release, any bugs that appear are likely to be resolved quickly.

rails new myrailsapp --main

The Ruby Triathlon starts this week! 

Rails World - Amsterdam, Netherlands, September 4–5

The first conference is Rails World happening in Amsterdam on 4 and 5 September. 

The tickets are sold out! So if you did not yet got your ticket, then make sure you keep an eye on it for next year :(

Friendly.rb - Bucharest, Romania, September 10–11

The next one Friendly.rb will happen next week in Bucharest, Romania on 10-11 September. Make sure you don't have plans for 12 September as we will have an outdoor day.

Tickets are still available at https://friendlyrb.com.

During the conference there will be a "Brew your own coffee corner" where you can bring your own pour overs and we will provide freshly roasted coffee beans from various roasters to delight your taste. There is also a The Friendly Gameshow a funny surprise that awaits for you part of the conference. And on Friday, we will have a Friendly trip to Sinaia, an easy outdoor trip to one of the most beautiful cities in Carpathian mountains.

Yes, I shared more details about this conference as I am one of the co-organisers - so feel free to ping me about it
I wrote 3 articles about why to join Friendly.rb this year: 

• Day 1 of why you should join Friendly.rb this year
• More Than Code: The Friendships You’ll Build at FriendlyRB
• Day 3 of why to join Friendly.rb Conference

EuRuKo - Viana do Castelo, Portugal, September 18–19

The last one, three weeks from now, will happen in Viana do Castelo, Portugal  and it is the biggest Ruby conference in Europe: EuRuKo

Tickets are still available at https://2025.euruko.org and they have on Saturday a Ruby Safari - "Guided walking tour around Viana do Castelo, exploring local gems and hidden spots".

When AI is writing tests in agentic mode, it's crucial to monitor its output. 

Sometimes, it uses tricks to pass the tests or creates unnecessary tests.

For example, consider this diff that has at least two issues: 

1. The test is unnecessary for a medium-risk, medium-impact feature. It merely checks that the counter cache in Rails functions correctly. This test was written in an earlier iteration that I haven't reviewed yet to remove it. 

1. The Category model has the following constraint:

index_categories_on_position_and_parent_id (position, parent_id) UNIQUE

Notice how it added a position: rand(1..1000) to make some tests to pass because they lacked the position?

This approach is just inviting flaky tests!

I added this to my Flakiness section: 

- Use consistent data across tests to avoid flakiness. Prefer existing fixtures instead of generating data randomly.
- Do not use `rand` or anything similar when generating data for tests.
- Use `travel_to` for all time-sensitive tests (assert time or need time to make the test work)
- Use `.sort` when the results are not guaranteed to be in a specific order.

No one will thank you for good error messages or default states, but they will feel it!
The difference between friction and flow is invisible work.

This is also true for the development process:

Sloppy names turn into messy objects and interfaces. Messy objects lead to slower teams.

The same goes for testing: Be careful about how you organise the code inside the test files because if it gets messy, it will slow down the development and debugging in the future.

It all compounds.

Details are never just details! If you are using AI to generate code, make sure it generates good names in your domain.

Curious about how I ended up with an invoice nearing $100 for conducting over 20 million Class A operations on Cloudflare R2?

I initiated several Litestream processes across a variety of side projects and forgot to set the sync interval! :) It defaults to 1s

The backup I was handling was more complex than the main production database. It included slight variations in the SQLite file because it automatically queried various external services to check the status of different entities.

In case you missed this in the last period, there are two new podcasts in #Ruby world: 

On Rails - a podcast produced by the @Rails Foundation and hosted by @robbyrussell

👇

https://onrails.buzzsprout.com

Ruby Gems Podcast produced by @rubycentralorg and hosted by David Hill and Marty Haught 

👇

https://www.buzzsprout.com/2509083

PS: Both of them are hosted https://www.buzzsprout.com/ - built also with Ruby on Rails