I invited you here from various places where I had some newsletter options (allaboutcoding.ghinda.com, learn.shortruby.com, goodenoughtesting.com).

I will stop sending individual newsletters from all the places mentioned above. Managing four different places for regular writing isn't sustainable, so merging them into one is the best course of action now. I want to focus more on writing and have a single place to send my work.

Just to clarify: The Short Ruby Newsletter goes on as before. This is a personal newsletter where I share my own content and or insights from other people.

What will you find here? The kind of content that I usually post on social media about: Ruby, Testing, Workshops, Creativity, Tech News.

If you'd like to unsubscribe for any reason, you can do so using the button below:

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

Here I posted about why I think they are important.

This week, I found three resources that might help involving real files. If you need to provide a PNG, PDF, or any type of file in your test, it's best to choose the smallest one that is still a valid format.

I saved three ideas at The smallest files of any type to be used in automated testing

Here is how you can create a new Ruby on Rails app running 8.1.0-beta1

Wrote a short post about it at How to create a new Rails app with Rails 8.1.0.beta1

If you just run a simple ruby file, what objects are already there? Who is main?

self.inspect prints main because this is a special case where when running a file the initial context is a special instance of Object and CRuby defines inspect as being actually to_s and then makes in special context to_s to print “main” .

I explored a bit more details about this trying to understand the C code and how it works in a small article called In Ruby who's already there in main?

I got very good feedback about all sessions I run so far and this new version is improved upon feedback received in the first 8 sessions. Planning to start soon working on the video course and launch a second workshop about Reliable test case generation with AI.

Until then you can join the next live session at Good Enough Testing Website. The next workshop will take place on 10th October at 15:00 UTC.

Design your database so direct queries make sense on their own. When you run a SELECT on any table, the results should be understandable without extra context. This approach trades a bit of performance for clarity, but it pays off.

Your schema becomes self-documenting, and anyone running queries can immediately understand the data.

Wrote a bit more here with some examples: Designing Database Schemas for Clarity

In the past 15 years, many companies shifted QA duties to developers, prioritizing automation and code coverage. Developers excel at writing automated tests and moreso at writing tools. That’s why today we see great tooling, CI pipelines, and high code coverage.

But more tests don’t always mean better quality. You can hit 100% line coverage and still miss the scenarios your users care about most. The solution for this is test design: choosing what to test based on risk and context, not just lines of code. This is part of the knowhow lost along with QA teams that we have to rediscover.

I expanded this into a full article about What We Lost When QA Teams Disappeared

Looking back I wrote quite a lot this week and I also had bookmarked some nice posts or articles but I think this is getting pretty long so far.

Lucian

P.S. Let me know what do you think about this newsletter. Hit reply if you have any feedback