Size: a a a

2021 March 13

NM

Natalia Maximenko in pro.elixir
Dmitry Ponyatov
а существует ли таториал с разбором Phoenix "по косточкам" — внутрянка, архитектура, обзор отдельных либ которые он использует?
Поход по файлам репы на гитхабе?)
источник

MG

Max Gorin in pro.elixir
Aleksey @cheatex
Не очень понятно какая проблема решается. Если остановка штатная то зачем что-то сохранять а не дать процессу доработать? Если нештатная то всё равно потеряются данные.
спасибо за вопросы, они мне прояснили, что действительно не понятно, какая проблема решается. Изначально я думал о задаче, чтобы пре деплойменте не терялся стейт игр, которые ведутся на сайте (и в этом случае дать процессам доработать - не вариант). Но с другой стороны, если я останавливаю игру до перезапуска процесса, то... это неправильно). Игра должна продолжать идти на дополнительном node, а значит, эти ноды должны все равно шарить стейт, и какой-нибудь редис (или что-то подобное) в этом случае, в который стейт обновляется незамедлительно - единственный способ не прерывать игру. Так что моя идея оказывается все же неработающей (или как-минимум с более ограниченным применением, чем я подумал изначально).
источник

MG

Max Gorin in pro.elixir
Dmitry Ponyatov
а существует ли таториал с разбором Phoenix "по косточкам" — внутрянка, архитектура, обзор отдельных либ которые он использует?
очень понравилось вот это выступление на эту тему: https://www.youtube.com/watch?v=Z0Z4wu4CPgQ
источник

AK

Andy Krasnov in pro.elixir
V
А старого куда дели?
Съели😂
источник

DF

Denis Fakhrtdinov in pro.elixir
Max Gorin
Еще такой вопрос: натыкался ли кто-нибудь на DSL для написания stateful bots - например, телеграм-бота, который принимает заказ и оплату на него. Другими словами, есть ли удобный способ конвертировать обычный web browser wizard в бота.
Dialogflow?
источник

MG

Max Gorin in pro.elixir
🚀🙌💯 не знал о таком, спасибо!
источник

DF

Denis Fakhrtdinov in pro.elixir
Я его не ковырял серьезно, так, поиграться только. Так что какие там камни внутри — без понятия.
источник

MG

Max Gorin in pro.elixir
Да, непонятно пока, насколько просто в него засовывать свою бизнес-логику, но как минимум посмотреть, как гугл делает конфигурируемых ботов - интересно для идей. Сразу же подключил к телеграм-боту его, развлекаюсь.
источник

DF

Denis Fakhrtdinov in pro.elixir
Там есть предефайнд smalltalk — прикольная штука :)
источник

MG

Max Gorin in pro.elixir
Denis Fakhrtdinov
Там есть предефайнд smalltalk — прикольная штука :)
Посмотрел несколько видео по Dialogflow CX - там много прикольных штук, включая подключение ML, integration tests и т.д. Но стоит это все в результате... 20 центов за каждый разговор с ботом :) Я пока решил продолжать писать свою архитектуру для ботов на Эликсире с нуля (основа оказалась не такой сложной, как я думал), но для вдохновения, выбора терминологии, и идей по дальнейшему развитию - оч интересный проект 🙏
источник

IK

Ihor Katkov in pro.elixir
Max Gorin
спасибо за вопросы, они мне прояснили, что действительно не понятно, какая проблема решается. Изначально я думал о задаче, чтобы пре деплойменте не терялся стейт игр, которые ведутся на сайте (и в этом случае дать процессам доработать - не вариант). Но с другой стороны, если я останавливаю игру до перезапуска процесса, то... это неправильно). Игра должна продолжать идти на дополнительном node, а значит, эти ноды должны все равно шарить стейт, и какой-нибудь редис (или что-то подобное) в этом случае, в который стейт обновляется незамедлительно - единственный способ не прерывать игру. Так что моя идея оказывается все же неработающей (или как-минимум с более ограниченным применением, чем я подумал изначально).
Я думаю это просто blue green deployment решается
источник

IK

Ihor Katkov in pro.elixir
В кейсе с игрой. В кейсе с ботом - сложнее. Тебе самому нужно следить, что бы каждый следующий деплой был обратно совместим, по идее
источник

AB

Alex Bubnov in pro.elixir
Ihor Katkov
Я думаю это просто blue green deployment решается
Это не blue-green называется, а rolling
источник

AB

Alex Bubnov in pro.elixir
Впрочем, разница не так велика
источник

AB

Alex Bubnov in pro.elixir
Max Gorin
спасибо за вопросы, они мне прояснили, что действительно не понятно, какая проблема решается. Изначально я думал о задаче, чтобы пре деплойменте не терялся стейт игр, которые ведутся на сайте (и в этом случае дать процессам доработать - не вариант). Но с другой стороны, если я останавливаю игру до перезапуска процесса, то... это неправильно). Игра должна продолжать идти на дополнительном node, а значит, эти ноды должны все равно шарить стейт, и какой-нибудь редис (или что-то подобное) в этом случае, в который стейт обновляется незамедлительно - единственный способ не прерывать игру. Так что моя идея оказывается все же неработающей (или как-минимум с более ограниченным применением, чем я подумал изначально).
Вообще, я могу тебя поздравить и поприветствовать в увлекательном мире персистентных акторов. Дисклеймер - мы делаем процессинг платежей, поэтому я могу немного серьезнее воспринимать тему, чем это осмысленно для тебя.

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

К библиотечным решениям(gen-server, gen-statem, Agent) привязываться я не рекомендую, они работают только в самых простых случаях, по мере усложнения кода начинают ставить палки в колёса, и сверх этого делают твой сервис stateful, а это сразу превращает горизонтальное масштабирование в изысканное развлечение для тонких ценителей. Мой последний подход к снаряду выглядит как очень минималистичная версия gen_statem, где и за персистенс, и за таймеры, и за выставление меты логгера отвечает общий код, а бизнесовый просто отдаёт ему команды на каждом шаге. В такой реализации сильно проще тестить бизнес-логику, потому что можно подсунуть фейковый интерпретатор. Особенно это хорошо, когда в логике начинается работа с таймерами - в версии с таймерами gen_statem до сих пор иногда валятся тесты из-за race conditions.

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

ML

Maksim Lapshin in pro.elixir
Alex Bubnov
Вообще, я могу тебя поздравить и поприветствовать в увлекательном мире персистентных акторов. Дисклеймер - мы делаем процессинг платежей, поэтому я могу немного серьезнее воспринимать тему, чем это осмысленно для тебя.

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

К библиотечным решениям(gen-server, gen-statem, Agent) привязываться я не рекомендую, они работают только в самых простых случаях, по мере усложнения кода начинают ставить палки в колёса, и сверх этого делают твой сервис stateful, а это сразу превращает горизонтальное масштабирование в изысканное развлечение для тонких ценителей. Мой последний подход к снаряду выглядит как очень минималистичная версия gen_statem, где и за персистенс, и за таймеры, и за выставление меты логгера отвечает общий код, а бизнесовый просто отдаёт ему команды на каждом шаге. В такой реализации сильно проще тестить бизнес-логику, потому что можно подсунуть фейковый интерпретатор. Особенно это хорошо, когда в логике начинается работа с таймерами - в версии с таймерами gen_statem до сих пор иногда валятся тесты из-за race conditions.

Когда дойдёт до масштабирования, шардинг лучше делать по внешнему идентификаторы актора(типа, id чата, в котором идёт игра) и неплохо бы реализовывать на уровне роутинга входящих сообщений и внешними средствами, когда есть такая возможность. Отдельная очередь событий на каждый шард, и внутренние события, типа таймеров, должны так же проходить через неё, иначе можно попасть в грустную ситуацию.
у нас кстати часто рождается дизайн вида:

* один модуль умеет слать сообщения, ставить таймеры, принимать сообщения и делать что-то грязное, но он не имеет права принимать решения
* второй модуль имеет такое апи:  f(InputCommand, State) -> {OutputCommands, State1} и он полностью pure, причем State условно json-ифицируем (по возможности).
источник

AB

Alex Bubnov in pro.elixir
Maksim Lapshin
у нас кстати часто рождается дизайн вида:

* один модуль умеет слать сообщения, ставить таймеры, принимать сообщения и делать что-то грязное, но он не имеет права принимать решения
* второй модуль имеет такое апи:  f(InputCommand, State) -> {OutputCommands, State1} и он полностью pure, причем State условно json-ифицируем (по возможности).
Да, оно самое)
источник

ML

Maksim Lapshin in pro.elixir
ну как тестировать и дебажить начинаешь, быстро такое рождается
источник
2021 March 14

MG

Max Gorin in pro.elixir
Maksim Lapshin
у нас кстати часто рождается дизайн вида:

* один модуль умеет слать сообщения, ставить таймеры, принимать сообщения и делать что-то грязное, но он не имеет права принимать решения
* второй модуль имеет такое апи:  f(InputCommand, State) -> {OutputCommands, State1} и он полностью pure, причем State условно json-ифицируем (по возможности).
да, на днях Sasa Juric в Thinking Elixir рассказывал про то, что он всегда делает похожее деление на interface и core. JSON, кстати, часто удобно заменить на :erlang.term_to_binary -- тогда, ценой читаемости, снимаются ограничения по структуре и добавляется скорость
источник

MG

Max Gorin in pro.elixir
источник