Альтернатива callback-ам

[maovrn]

Спасибо, хорошая тема поднята. Я только не уловил, как запускаются процессы в стандартной ситуации (помимо исключительного случая запуска руками). Опять же колбэком?

[madzhuga]

Не обязательно. Процессы можно запускать откуда угодно. Можно например из контроллера — создали ресурс (ордер, например) — и для него запустили процесс.

RailsWorkflow::ProcessManager.start_process(
  process_template_id , { resource: resource }
)

[madzhuga]

Речь не об отдельном паттерне. Организуйте команды в очереди, возможность гнать их синхронно-асинхронно, пользовательские команды (пользуясь вашей терминологией), добавьте возможность конфигурировать «очереди», отслеживать «свалившиеся» очереди, экспорт-импорт очередей, поддержку версий конфигурации с учетом еще не завершенных процессов на старой версии конфигурации и т.д. В общем я не о реализации отдельно взятого паттерна а о движке на основе этой идеи.
Паттерну 20 лет — а попробуйте найти нормальный движок на рельсах — и упретесь в то что его почему-то нет. Гемов для callback-ов — всяких state machine и прочих модификациях — полно. А чего-то посложнее — почему-то нет.

[madzhuga]

Далеко не всем это нужно — согласен. Но скатываться во флуд из разряда «учат работать на колбэках и использовать по максимуму стандартный код» — не хочу. Если не нужно — значит не нужно. Кому-то DYI не нужно, а кто-то занимается. Каждому свое.

[j_wayne]

>> там учат работать на коллбэках
А там не учат, как потом поддерживать такое приложение?

[j_wayne]

Не хотел вас задеть. В коллбеках проблема, наплакались кровавыми слезами в свое время.

[j_wayne]

Рекомендую интересующимся данной темой посмотреть Architecture the Lost Years by Robert Martin
Не совсем это про коллбеки… Но в рельсах очень много таких моментов.

А также рекомендую ознакомиться с блогами Роберта Мартина:
blog.cleancoder.com
blog.8thlight.com/uncle-bob/archive.html

С DHH (автором рельсов) у них занятный спор вышел

[AnnieOmsk]

Вы сейчас открыли для себя новый чудный мир акторов, паттернов потоковой обработки и так далее :-) Сразу скажу, что эта история полностью альтернативна Rails, и вам будет очень сложно увязать одно с другим.

Это объясняет миграцию разработчиков с Rails на Erlang, Clojure, Scala и так далее. Однако сами по себе языки не панацея, интересна сама модель акторов, на которой построен принцип работы Erlang-приложений и фреймворк Akka.

Если интересно, можем пообщаться на эту тему, вам совершенно верно упомянули Роба Мартина и паттерны. DHH, к сожалению, все это отмел как «устаревшее» и в результате разработчики плачут кровавыми слезами, однако, щедро оплачиваемыми. Но эта лафа скоро может закончиться, потому что модель акторов сейчас становится модной, а это значит, что рельсы могут сдать свои позиции.

[madzhuga]

Пока что не вижу никакой сложности. Все очень спокойно ложится на рельсы. Они в общем-то никоим образом не мешают использовать паттерны. Проблема в том что большинство берет туториалы по рельсам — и как в них описано — так и пишут (пример — те же callback-и).

[AnnieOmsk]

Попробуйте написать код, который полностью удовлетворяет SOLID на рельсах :-)

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

[madzhuga]

Не совсем понятна постановка вопроса :) «Попробуйте прикрутить». Вопрос — зачем? Я исхожу из задачи — отделить бизнес логику от моделей / контроллеров, сформировать из отдельных операций какой-то ход процесса и дать возможность с процессом работать (мониторить, саппортить и т.д.).
В программировании очень много принципов, подходов и т.д. — что ж их все пробовать прикрутить? У меня есть задача, есть вариант решения. О нем и речь.

[AnnieOmsk]

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

У вас просто есть два пути. Первый — пробовать все самому, решая все усложняющиеся задачи и придя в итоге к той же модели, но через год или больше. Второй — попробовать узнать побольше, разобраться в теории и существенно сократить этот путь, повысив качество решений, которые вы сможете создавать. Выбор, безусловно, за вами :-)

[madzhuga]

По поводу модели акторов — вроде как народ изголяется — https://github.com/celluloid/celluloid. Мне сложно судить насколько это удачное / неудачное решение но тем не менее оно есть.