Вообще интересно глядя на данный код: у нас есть блок в нем определяется переменная config - но в тебе блока она не используется.

Это кусок кода

require "active_sms" require "logger" ActiveSMS.configure do |config| c.register_backend :my_backend_name, ActiveSMS::Backend::Logger, logger: Logger.new(STDOUT), severity: :info c.default_backend = :my_backend_name end

Я пилю гем и периодически спрашиваю советы у других рубистов.

Я пилю гем и периодически спрашиваю советы у других рубистов.

Дима про то, что у тебя внутри блока переменная "c" не определена

О, благодарю

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

Наследование зло. Это уже мое имхо.

Но код выше -- rails way, так что всё норм ?

Я кстати писал ruby way

т.к гем не под рельсы а под руби. Для рельс будет обертка.

Наследование зло. Это уже мое имхо.

Смотря как с ним обращаться

Я кстати писал ruby way

Ruby way, на мой взгляд, это избегать Module.configure do |config|, но многие могут со мной не согласиться

а что с ним не так?

я думал это рубишный подход

я думал это рубишный подход

Найди в стдлиб такое, или труъ гемах -- вряд ли получится

Потому что это синглтон

это антипаттерн в 90% случаев.

а вообще твердоботам нраица: https://robots.thoughtbot.com/mygem-configure-block

а что с ним не так?

1. Классовый метод -- это функциональщина, а не ооп 2. Чаще всего, как я говорил, достаточно констант и наследования. Можно просто экземпляр класса создавать и его настраивать, если в наследование не получается 3. Не гибко

Это не гибко да.

Но тем кому нужна подобная гибкость могут накатать такое решение за один день.

Плюс так как все смс бэкенды используют один и тот же интерфейс для вызова - они могут написать свой ActiveSMS и все равно использовать уже готовые бэкенды

так что я даже им помогу (в теории)

Я ориентировался на максимальную простоту для конечного юзера. Тот гем который бы я хотел иметь для смс.

Подключил, врубил нужный бэкенд и просто юзаешь.

Кстати что такое тру гемы я так и не понял.

Наследование зло. Это уже мое имхо.

Я фреймворк накатал из чистого наследования, нет никаких классовых бефор и афтер, и это всё замечательно работает. Так что советую тебе не бояться, это всё можно о осознать и с этим работать -- удобно и красиво

Я специально пошел путем синглтона чтобы сделать гем максимально простым )

Мне не сложно сделать "наследованием" (кстати не понимаю что ты в это вкладываешь) просто гем уже будет не таким юзер френдли для нубов.

почему метод класса это функциональщина?

Кстати что такое тру гемы я так и не понял.

Сложно сказать. От авторитетных рубистов. Тот же sequel мб

Класс который хранит глобальное состояние - это синглтон, и это антипаттерн.

Я специально пошел путем синглтона чтобы сделать гем максимально простым )

Да, поэтому я не говню, просто высказываю своё мнение

Никто не спорит что это дурной тон и возникает класс проблем.

Например ActiveRecord это тоже приличное сборище антипаттернов

Но он очень удобен.

``` class MySMS < ActiveSMS BACKEND = SMS_RU end ``` Я бы поспорил насчёт удобства, не говоря уже про то, что сами бэкенды могут быть наследованы, и наследоваться уже от нужного

Я не очень понимаю как в твоей схеме я могу под одним и тем же именем использовать разные бэкенды

как можно нормально к рельсам подключить dry-types?

При чем тут рельсы?

Юзай в обычных poro и все

Я не очень понимаю как в твоей схеме я могу под одним и тем же именем использовать разные бэкенды

Зачем? Как в твоём под одним именем? Делаешь второе наследование и всё

При чем тут рельсы?

криво автолоадит

Затем что на локалке будет один класс за это отвечать, а на проде другой.

А название будет одно и тоже

к пример :main_sms_service или ченить такое.

Затем что на локалке будет один класс за это отвечать, а на проде другой.

Выносишь в конфиг YAML

Конфиг yaml для простого рубишного гема ?

очень просто и понятно ага.

Конфиг yaml для простого рубишного гема ?

Why not?

Ну потому что для рубишного гема должно быть достаточно рубикода??

очень просто и понятно ага.

Что из этого непонятно?

серьезно, зачем тут yaml?

Что из этого непонятно?

Например что ты имеешь ввиду под вторым наследованием.

серьезно, зачем тут yaml?

Конфигурирование?

Почему нельзя рубикдом сконфигурировать?

Например что ты имеешь ввиду под вторым наследованием.

class MyOtherSMS < ActiveSMS # or MyBaseSMS

Почему нельзя рубикдом сконфигурировать?

Environments

Как ты сделаешь чтобы один и тот же код использовал разный бэкенд каждый со своими настройками в разных средах?

Environments

Нет в руби environments

Затем что на локалке будет один класс за это отвечать, а на проде другой.

А "прод" -- это что по-твоему, если не окружение ?

подожди подожди. У меня есть руби скрипт рассылки

В руби нет, а вокруг есть

он прод или нет?

ERROR: S client not available

так я рубигем пишу )

он прод или нет?

Когда у тебя ямл -- тебе пофигу

Ямл я как кормить буду?

чем тяжелый yaml лучше легковесного configure?

Ямл я как кормить буду?

Ямл.лоад, как будто не знаешь

Стоп стоп

как я гему передавать этот ямл буду?

строкой? ?

чем тяжелый yaml лучше легковесного configure?

Зависит от окружения: меняешь конфигурацию без вмешательства в код

строкой? ?

Лоад_файл Бля, посмотри доки

Т.е я сначала из ямла сделаю хэшик, а потом скормлю моей реализации?

Т.е я сначала из ямла сделаю хэшик, а потом скормлю моей реализации?

Ага

Тогда причем тут yaml вообще?

если он тут не нужен?

Во вторых - кидать огромный хэшик классу это тоже круто.

Чем он отличается от моего configure правда неясно.

если он тут не нужен?

Да любой формат. Файл с данными для конфигурации, который позволяет не вмешиваться в код для изменения каких-то параметров конфигурации

Сторонняя апишка это уже не часть кода? тут разные подходы имхо.

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

Это может быть хоть БД - зависит от задачи

Лоад_файл Бля, посмотри доки

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

Если есть внешняя апишка то как правило у нее жесткий entrypoint

Нет смысла хранить ее в конфигурации потому что она никогда не изменится.

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

Храни. Но ты хочешь переключение бэкенда на проде? Это как переключение аккаунта, то есть ключа, почему бы не хранить там же именно нужный

Это не совсем так выглядит.

Суть в том что на локалке заглушка, на проде боевой сервис

и при этом ты не меняешь в коде ничего.

Т.е ты как дергал например ActiveSMS.send_sms так и дергаешь в нужном месте кода.

и при этом ты не меняешь в коде ничего.

У меня вот выбирается апи для писем в зависимости от наличия конфигов: нет ключа апи для сервиса А? Включаем сервис Б

о_О

странный у тебя конфиг

То есть я код тоже не меняю