Да, я так и сделал пока что. Написал коммент и заюзал to_prepare
Меня слегка напрягает, что у меня много таких маленьких классов c dry-configurable и надо везде, получается, такой коммент написать

Интересно, а народ тут вообще как делает свои классы с конфигом?
С помощью библиотек или просто делают cattr_accessor? или просто ENV['FOOBAR'] внутри класса?

мне нравится gem 'config'. Можно хранить иерархические структуры в yaml-файлах (settings.yml),  можно передавать через переменные окружения, есть разделение на разные окружения (dev/test/prod), можно перекрыть своим файлом settings.local.yml, и доступ через Settings.foo.bar.baz

можно просто парсить .yml и через method_missing брать оттуда

Это не совсем то, что я имел в виду.
Я про кейс, когда надо написать свой класс, которому нужно передать настройки.
Например, если он ходит куда-то http и ему нужно передавать адрес и какой-то ключ для аутентификации.

Есть много вариантов, как сделать.

А на счет самого гема: он возмужал с тех пор, как я его видел много лет назад. Схема/валидации через dry - круто.
Надо будет попробовать выкинуть свой велосипед )

google:
  url: https://www.google.com
  password: notsosecret

c

lass MyGoogle
  def initialize
    @url = Settings.google.url
    @password = Settings.google.password
  end
end

У нас обычно примерно вот так везде сделано. Потому как пароли меняются только между окружениями (т.е. пароль на проде будет другой, а урл может совпадать)

Я так делаю: https://evilmartians.com/chronicles/anyway-config-keep-your-ruby-configuration-sane

так это же опять о том, как конфиг хранить/читать

И про классы) вопрос же про них был

вопрос был про них. надо было кидать ссылку сразу на ридми (там понятнее) :)

У меня смешанные чувства от anyway config. С одной стороны очень круто все сделано, мэджик )
А с другой, кажется, что too much )

Уж не помню с какого года. Предположу, что с 2011 gem 'config' мною воспринимался, как стандартное средство. В плане конечного использования, я думаю, он и по сей день не поменялся.

Если нужна конигурация чего-либо, этот гем первое что нужно попробовать

Пляски с ENV это отдельная история, для определенного типа/размера приложений.

у меня вчера  на github action внезапно сломались feature spec (которые с хромом), кто нибудь сталкивался?

У нас ломались на другом CI и почти всегда причина была в том, что за ночь вышла новая версия хрома, которая что-нибудь ломалала изменяла. А качали мы хром руками каждый билд, а не юзали тот, что уже есть в CI.

поломался node-sass, сбросил node кеш, помогло

Продолжение бывалого треда о пути к архитектору, есть статейка

https://architectelevator.com/architecture/architect-path/

Добрый вечер. Поделитесь, пожалуйста, у кого какая ситуация с архитектурой в рельсовом проекте? Rails way? Rails way, но с папочками app/services, app/decorators и тп? DDD? Clean Architecture? Hexagonal architecture? Что-то иное?

Просто во всех рельсовых проектах, в которых я работал, не были ничего и близко к тому, о чем пишут в книгах по DDD или говорят на конфах по архитектурам. И это были большие проекты, которые пилились много лет многими командами.

В текущем проекте (относительно новом) хочется сразу делать норм архитектуру, чтобы легко вносить изменения и тп, потому что, как показывает опыт, потом уже будет очень сложно что-то изменить, не будет времени и тд.

P.S. Микросервисы не предлагать 😄