Приложение нативное, на джаве. Оффлайн режим свой, изменения кладутся в очередь до следующей синхронизации, потом отправляются на сервер пачкой. Сервер разрешает конфликты, затем отправляет новое состояние в ответ, и приложение обновляет данные у себя. Этого пока достаточно.

Да я не про вас, это аргумент dhh :)

Про duration я ничего уже не помню, но проблема при дебаге была в том, что квакание там было неподходящим, is_a? и .class тоже не работали, выдавая Fixnum, на самом деле им не являясь. Конечно, если там поразбираться, наверняка была проблема в некорректном обращении с типами в руби, но вот разбираться с такими вещами тяжеловато.

5.days может сломать, я разбирался с такой проблемой, когда Duration притворялся числом, его нельзя было распознать никак, кроме как вызвать метод parts, который внезапно оказывался/не оказывался у объекта, так можно было отличить целое число от Duration. Это было в рельсах 3.2, с тех пор этот момент улучшили, но я лично потратил час или два на разбирательства с той проблемой, какой-нибудь новичок, по-моему просто погиб бы. Но это я в качестве примера, на самом деле я согласен, что патчинг бывает разный, но беда в том, что вместе в рельсами вы получаете все и сразу, нет способа отказаться. А когда вы на это жалуетесь, вам рекомендуют использовать другой язык программирования под предлогом того, что вы не умеете в руби, такие дела.

Кхм. Ну, допустим. Хотя избавляться от неймспесинга и внедренных зависимостей можно и поизящнее, не разламывая в щепы pry, которая не ожидает от объектов такой подлости, как отсутствие `puts`. Делегировать пару методов из `Kernel` уж точно можно было бы. Впрочем, я в целом не понимаю, в чем прелесть `BasicObject` именно там, кроме демонстрации «идеологии».

Я все же настаиваю на обсуждении этого на гитхабе, там более подходящее место. Но насчет пробрасывания методов из Kernel идея хорошая.

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

Странно, что вы отказываете мне в наличии собственного мнения. В любом случае, я имел в первую очередь позицию core team.

BasicObject создан для использования в качестве контекста для DSL, так он и используется, разве нет? Ну, конечно, если что-то не так с этим подходом, и вы знаете об этом, нет смысла держать в себе, откройте тикет, где это можно будет обсудить в «рабочем порядке» :) Равно как и про «остальные смешные вещи».

refinements не взлетели потому что они на самом деле не решают основную проблему — отсутствие абстракций. Ну, я не исключаю, что если бы они работали как-то по-другому, то это позволило бы хотя бы снять вопрос об изменении рантайма.

Ерунда. Открытые классы — мощнейший инструмент, который позволяет сделать очень много, если делать это по уму. Если же делать что-нибудь не по уму, то даже в насквозь казалось бы безопасном Delphi в 1994 году мне удалось наступить на грабли с левой библиотекой, которая обращалась к приватным полям чужих объектов по смещению. В любом языке можно отравить жизнь всем своим пользователям, и проблема не в манкипатчинге.

Это пример ложной дилеммы.

Проблема манки-патчинга не в том, что после его использования у вас сразу выпадут волосы и зубы, а в том, что манки-патчинг по своей сути это слабо управляемый инструмент. Его не стоит сравнивать с ножом, скорее с топором, которым вы пытаетесь разрезать торт. Цели своей вы добъетесь, но выглядеть это будет диковато, даже если топор наточен очень остро. Но допустим, что руби это такой странный мир людей, предпочитающих такие методы решения проблем.
Манки-патчинг это большая головная боль для разработчиков гемов, потому что получается, что кто угодно может непредсказуемо поменять рантайм языка, в итоге выйдет, что какие-то гемы окажутся несовместимыми. Это вовсе не мифы, чем дольше руби развивается, тем больше таких проблем происходит. Вот пример с переполнением стека из-за переопределения базовых классов: https://github.com/txus/kleisli/pull/17. Хочу заметить, что ошибки с переполнением стека очень неудобно отлаживать, буквально на днях такая ошибка уронила у меня интерпретатор с ошибкой адресации, никакого руби-стека я не увидел вообще.
Дальше — больше. Есть рельсы, которые построены на activesupport. Если какое-то из поведений в AS ломает ваш гем, то вам ничего не остается, кроме как поменять вашу библиотеку для совместимости с AS, потому что иначе никто не будет ей пользоваться. Это уже не ножи, это пики из задачи двух стульев.
Стоит присмотреться повнимательнее какую же проблему на самом деле решает манки-патчинг. На деле это оказывается банальное отсутствие нужных абстракций или инструментов, вместо создания которых, люди патчат рантайм. Точка зрения dry-rb-коммьюнити заключается в том, что так быть не должно. Нужно разрабатывать библиотеки и подходы, которые будут удобны и функциональны без необходимости изменять поведение стандартных классов, для этого в руби есть все необходимое. Мы неоднократно видели, как продуманный подход преподносил много приятных сюрпризов впоследствии, что еще больше усилило нашу уверенность в правильности выбранного пути. Простите, если это звучит слишком пафосно :)

Ответ на поверхности — объекты без состояния. Создаете объект один раз, у него есть только один метод, который принимает аргументы и возвращает результат. Вот, почитайте: https://habrahabr.ru/company/latera/blog/301338/

К сожалению, комментариями в интернетах вы этого не добьетесь, ложитесь спать :)

Вы правда думаете, что кто-то всерьез примется вас учить? Вы серьезно? Могу вас заверить, ни у какого специалиста после прочтения таких призывов такого желания не возникнет. Если вам это нужно, то дерзайте, если нет, то к чему это все?

К счастью, здесь этим не пахнет. У этих библиотек нету и не будет таких целей, хотя некоторые опасаются, начинают пугать джавой, в глаза ее не видев, и так далее. Ключ-значение + небольшая обертка, вот и все. dry-component только чуть посложнее с логической точки зрения, потому что берет на себя логику по загрузке приложения.

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

Те, кто заплатил вовремя, не пострадали :)

Тут просто заголовок некорректно переведен, в оригинале было: «My time with Rails is up», что можно грубо перевести как «Хватит с меня рельсов». И тогда все встанет на свои места — автор статьи написал много гемов и его достало поддерживать совместимость с рельсами, а кроме рельсов ничего толком не появилось, вот весь сказ. Вот если вы начнете писать свои гемы (к чему Петр открыто призывал в твитере), тогда может распрощаетесь с рельсами с такой же статьей :)

Ну а Clojure — это правильно, не забудьте посмотреть выступления Рича Хикки.

Не будьте обмануты идеей, что быстро разрабатывать приложения можно только на рельсах, это не так. Да, у рельс сейчас есть несомненные преимущества в документации, сообщества и всех других важных для опенсорсных проектов вещей. Но это не означает, что с технической стороны там происходит что-то такое, что нельзя сделать по-другому. Можно, даже нужно — вот об этом статья. Но для того, чтобы выстроить грамотную, хорошую архитектуру, нужно много сил, а соответственно много людей. И с этим есть большие проблемы, об этом тоже сказано. Я какое-то время следил за ромом, все ждал, когда он повзрослеет для промышленного применения, но в конце концов просто стал контрибьютором и нисколько не жалею.

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

У вас сложилось неверное впечатление, но в данном случае виноват автор, не разъяснив свою позицию в статье, но он сделал это позже на реддите. Петр уважает высокоуровневые абстракции, но при условии, что они строятся на продуманном основании. В этом основная претензия к рельсам и особенно к ActiveSupport, потому что решения, реализованные там не имеют под собой почвы. Вы привели очень хороший пример — метод try. Какую проблему он позволяет вам решить? Очень часто люди используют его при работе со вводом из-за отсутствия продуманных средств валидации данных. Вот цитата Петра о новом операторе &. из чата hanami, который упоминался в статье (давность — пара часов):

Piotr Solnica
@solnic
21:30
ie in upcoming hanami-validations you'll be able to do filled(:str?, include?: ".")
that's why I was sad to see this new feature in ruby, as people may not think about proper input validation, if you can make sure that input is in the expected state then lots of complexity in your code won't be needed

Но полбеды само неправильное или неуместное использование, для реализации этого метода AS патчит класс Object, от которого наследуются почти все объекты в руби. Что может пойти не так?

http://rom-rb.org/
http://dry-rb.org/
https://github.com/solnic/transproc

Речь идет о написании библиотек, которые могли бы пригодиться большому количеству людей. Вам нужно их продвигать, чтобы они действительно стали общепринятым решением. Вам может быть это непонятно, если вы не писали их, но у меня есть пример под рукой: гем dry-types, который занимается приведением типов. Это абсолютно общая и при этом конкретная задача. Но он из коробки не работает с рельсами из-за горячей перезагрузки кода, а если вы захотите подружить его с ActiveSupport, то вас ждет веселый вечер (если вы опытный руби-разработчик, иначе шансов ноль), результатом которого будет запутанное и ненадежное решение.

Это не так. Основная претензия к ActiveSupport, которые делает большое количество безответственных вещей. ActiveRecord — это просто ограниченный паттерн ОРМ, в который напихано много откровенно дурных вещей, которые постоянно используются некорректно. ActiveRecord можно удалить, а ActiveSupport — нет.

AutoInject.[] на самом деле генерирует анонимный модуль, который добавляется к классу. Но я написал такой враппер:

module Imprint
  Import = Dry::AutoInject(Container)
  KwargsImport = Import.kwargs

  class << self
    def inject(target)
      -> *values { target.send(:include, KwargsImport[*values]) }
    end
  end

  module Mixin
    def inject
      Imprint.inject(self)
    end
  end
end

И потом использую так

module Operations
  class Operation
    extend Imprint::Mixin
  end

  class AcceptPayment < Operation

    inject['repo.account_repo',
           'repo.bill_repo']

    def call(...)
      # ...
    end
  end
end

Надо пробовать. Я думаю, что зависимости стоит использовать в том файле, где они подключаются, иначе действительно непонятно откуда они взялись. Но в любом случае здесь не больше проблем, чем в обычном руби, тем более, что оба гема (dry-container и dry-auto_inject) очень небольшие. Вот dry-component пока сыроват как мне кажется.

Аналог interactor — dry-transaction, это следующая ступень.