If you're writing API documentation, always specify units for duration parameters.

Not just "timeout: 30" but "timeout: 30 seconds" or better yet name the parameter if you can "timeout_in_seconds"

This is even more important inside your own codebase. Make sure that variables have proper names or descriptions or comments that specify the unit of measurements moreso in case you are working with durations. 

It matters for both developers and LLMs. 

When the unit is ambiguous, the LLM guesses. Sometimes it guesses wrong. Then developers debug code they didn't write, hunting for a bug that shouldn't exist.

Clear documentation prevents bugs before they happen.

If you are doing some planning this week, consider adding checkpoints for upgrading your #Rails app 

Specifically, if you are still running Rails 7.2T.x 

Security fixes end: August 9, 2026

Maybe it sounds like there is enough time but time flies.

Seems like Ruby is pretty well positioned as a language that is token-efficient when used with LLMs.

Source "Which programming languages are most token-efficient?" by Martin Alderson 

I was reading this article: https://www.humanlayer.dev/blog/writing-a-good-claude-md and found there the following:

Then I was curious to find out more about this system-reminder and to identify the source for this assertion.

Seems like more sources points to the following article: https://medium.com/@outsightai/peeking-under-the-hood-of-claude-code-70f5a94a9a62 which seems to identify prompts that are send along with the data read by Claude Code from Claude.md.

The Ruby namespace will be renamed to Ruby::Box.

A merge request regarding this was integrated into Ruby's master branch a couple of days ago by Satoshi Tagomori.

The renaming discussion was initiated by Xavier Noria, who shared compelling reasons for reconsidering the name.S

The accepted proposal, suggested by Satoshi Tagomori, was approved by Yukihiro Matsumoto:

But what is interesting is also that Matz hinted that this should be seen as a low-level API, with potential plans for a higher-level API in the future. This development is exciting as it could unlock new possibilities:

You can find all these and a lot more inside the Short Ruby Newsletter

Noel Rappin - Ruby And Its Neighbors: Smalltalk

Noel Rappin continues his series of writing about Ruby and languages that inspire it (if you have not read yet part 1 Ruby And Its Neighbors: Perl) and this time it is about Smalltalk. I liked very much this article as it goes into talking about the innovations that Smalltalk brings to the table, and at the end I almost felt sad that I never used Smalltalk professionally: 

Vinay Keerthi - Some Smalltalk about Ruby Loops

While Noel's article was writting from the persperctive of someone that wrote Smalltalk professionally here Vinay explores the influence of Smalltalk as someone who does not know Smalltalk. It is still refreshing to see how the influence can be identified:

I'm certain, although I haven't had the time to develop a proper data scraper to confirm, that Ruby articles are appearing more frequently on the front page of Hacker News this year.

I'm specifically referring to technical articles.

Here's the latest example: Yesterday, there were two posts:

• Joe Masilotti's article about "Ruby Already Solved My Problem" was on the front page and remained in the active list for a while.
• Bruno Sutic's article about the "Friendly Attribute Pattern" was also featured on the front page.

I encourage everyone in the #Ruby community to move beyond the mindset that "Ruby is declining." From what I observe, Ruby is growing in terms of its presence in public discourse and the resources being created.

Let's discuss Ruby more openly. Yes, there are many other languages and frameworks, both new and old.

I'm not a fan of criticizing others, so I believe we can talk about Ruby without dissing other technologies. Engage with others and share what we have.

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 IntegerUsing 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-NullableIf 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