Зачем вы меня тут все хором учите, как вывернуться и убедить себя, что виноваты обстоятельства? Я не кисейная барышня, мне это без нужды. Меня тогда и не распяли на рее, в принципе.
Да, генштаб — это прекрасно. Кто спикер — тоже не важно. Подписываюсь под каждым словом.
Дальше-то что? Напоминаю: разговор начался с «факапа ведущего разработчика». Не каждая команда (да и не каждая страна, даже) может себе позволить содержать генштаб. В любом генштабе всегда есть тот, кто больше знает, и ярче говорит.
Вот только если убрать всю эту смузи-казуистику, это факап ведущего инженера, предложившего и отстоявшего неправильного вендора. В его голове, — и с точки зрения вселенной, энтропии и высшей правды.
При чем тут вообще бас-фактор? При чем тут какие-то суперстары?
Ну снимите свои розовые очки и предложите вариант, при котором менеджмент предотвращает ситуацию «выбран неправильный вендор». В реальном мире, ну, а не в том, в котором феи на понях и единороги.
У меня нет привычки оправдывать свои ошибки перекладыванием ответственности на «организацию процесса» и «синклит».
Я тут самый компетентный, я называюсь Principal Engineer, у меня богатая грамотная речь — конечно я смогу убедить окружающих, тоже мне, бином Ньютона. Ни в каком наидеальнейшем мире это не будет ошибкой «всех вокруг». Всегда есть самый компетентный, и если он не боится принимать решения — то ему не до́лжно бояться и признавать ошибки. Иначе грош ему цена.
Факап — это же не «понавыкатывал багов в прод», ну что за детский сад, причем тут вообще тестирование и планирование?
Факап (мой личный, да) — это смог убедить всех в 2014, что Riak — лучшее решение для распределенного KV-store в наших условиях (стек, типы задач, итп). А Basho взяли и разорились, причем, оставив Riak в полуподвешенном состоянии.
я вас кажется понял - по-вашему любая стейт машина, в которой можно вернуться в предыдущее состояние (даже через кучу переходов) - это уже сага
Нет.
Я настаиваю на «определенных условиях». А именно, на доказанном существовании компенсационного запроса. В обычной транзакции такого требования нет: заморозили мир, попробовали ряд последовательных действий, получилось — ура, нет — откатились. Никаких дополнительных ограничений.
У саги эти ограничения есть, и они крайне важны (но про них редко вспоминают, даже в документации разного рода). И если для каждой потенциальной саги проверять (доказывать) наличие компенсационных запросов, примениых на всем множестве возможных данных — с сагами проблем не будет.
Да, конечно, на выходных напишу на elixirforum, мне хотелось понять по реакции аудитории, что подсветить, что — наоборот — затенить, и главное — что переделать. А то ко мне там относятся слишком уж уважительно, и конструктивную критику я услышу вряд ли.
Давайте принесём в этот разговор аксиоматику, для начала, а то скоро начнутся аргументы «моя сага длиннее».
Вот тут впервые было дано определение, поэтому нет никаких причин его не использовать (тем более, что все современные ссылки дают его же):
A Long Lived Transaction (LLT) is a saga if it can be written as a sequence of transactions that can be interleaved with other transactions. The database management system guarantees that either all the transactions in a saga are successfully completed or compensating transactions are run to amend a partial execution.
Вместо «database management system» в общем случае нужно, конечно, читать «saga management system», это не обязательно база, но чуваки старались генерализовать по-минимуму.
Итак. Тут прямым текстом сказано, что существование компенсирующих транзакций — обязательное условие. Если нельзя определить компенсируюшую транзакцию на всем множестве значений — саге не бывать. Поэтому:
реально списали бабки со счета в базе → обломались на бронировании товара → откатили списание в базе
— это действительно сага, потому что компенсирующая транзакция определена всегда. А вот:
перевели деньги Иванову на счет → Иванов закупился на всё лотерейными билетами → откатили изначальный перевод
— уже нет. Понятно, потому что реверсивная транзакция для перевода не определена в данном случае. Зато:
перевели деньги Иванову на счет → Иванов закупился на всё лотерейными билетами → откатили закупку лотерейных билетов → откатили изначальный перевод
— снова да.
В общем,
Откат — это не переход по стейт машине, это как раз откат перехода.
Это реверсивная транзакция, если она определена — все в порядке. В этой стейт машине должен быть определен переход назад (я зря не сказал, конечно, что это не любой конечный автомат в вакууме, а такой специальный, у которого всем исходящим стрелочкам соответствуют парные входящие).
На кой черт в event-driven примешивать саги — мне решительно не понятно.
Опять же, для наведения порядка, для поверки, так сказать, алгеброй гармонии ивентдрайвинга (-драйва). Если есть валидированная сага, значит можно вызвать «undo» и не париться, а не городить специальную функцию обработки «вот такой ивент вот в такой ситуации». Хоть на аспектах этот «undo» впилить — и voilà.
Что не так? — Да буквально всё. Если в конторе нет возможности вырасти по деньгам до приемлемых величин (сравнимых с руководителями крупных отделов, хотя бы), без необходимости иметь подчиненных — шанс нанять крутого разработчика как бы отрицательный (или придется врать на собеседовании).
Principal Engineer это дальнейший рост для лида, а не для сеньора.
Да ну? А что делать с людьми, которые не хотят становиться лидами, а хотят писать код, и действительно умеют это делать? Выгонять на мороз?
У меня был случай, чтобы не ссориться с эйчарами, бухгалтерией и прочими бюрократами из-за выплат, у нас была создана «Aleksei’s team», но подчиненных там все равно никаких, конечно, не было.
Я оставлю тут ссылку: https://element.io/
Ладно. Исправляйте бизнес.
Для протокола: я никогда и близко не предлагал исправлять инженера.
Такое ощущение, что я с чатжпт разговариваю. Теория — прекрасная штука, занимательная и такая вся красивая.
Конечно, есть второй вендор. Но переход на запасной вариант сто́ит бизнесу денег, прикиньте.
Зачем вы меня тут все хором учите, как вывернуться и убедить себя, что виноваты обстоятельства? Я не кисейная барышня, мне это без нужды. Меня тогда и не распяли на рее, в принципе.
Да, генштаб — это прекрасно. Кто спикер — тоже не важно. Подписываюсь под каждым словом.
Дальше-то что? Напоминаю: разговор начался с «факапа ведущего разработчика». Не каждая команда (да и не каждая страна, даже) может себе позволить содержать генштаб. В любом генштабе всегда есть тот, кто больше знает, и ярче говорит.
Вот только если убрать всю эту смузи-казуистику, это факап ведущего инженера, предложившего и отстоявшего неправильного вендора. В его голове, — и с точки зрения вселенной, энтропии и высшей правды.
Я же не говорю, что его надо наказать за это, ну.
При чем тут вообще бас-фактор? При чем тут какие-то суперстары?
Ну снимите свои розовые очки и предложите вариант, при котором менеджмент предотвращает ситуацию «выбран неправильный вендор». В реальном мире, ну, а не в том, в котором феи на понях и единороги.
А хотя, чего выходных-то ждать?
https://elixirforum.com/t/ragex-hybrid-retrieval-augmented-generation-for-multi-language-codebases/73864
Доступа к чему? К зашифрованному p2p потоку?
У меня нет привычки оправдывать свои ошибки перекладыванием ответственности на «организацию процесса» и «синклит».
Я тут самый компетентный, я называюсь Principal Engineer, у меня богатая грамотная речь — конечно я смогу убедить окружающих, тоже мне, бином Ньютона. Ни в каком наидеальнейшем мире это не будет ошибкой «всех вокруг». Всегда есть самый компетентный, и если он не боится принимать решения — то ему не до́лжно бояться и признавать ошибки. Иначе грош ему цена.
А сервер крутится на Linux + собственные наработки поверх?
Факап — это же не «понавыкатывал багов в прод», ну что за детский сад, причем тут вообще тестирование и планирование?
Факап (мой личный, да) — это смог убедить всех в 2014, что Riak — лучшее решение для распределенного KV-store в наших условиях (стек, типы задач, итп). А Basho взяли и разорились, причем, оставив Riak в полуподвешенном состоянии.
Нет.
Я настаиваю на «определенных условиях». А именно, на доказанном существовании компенсационного запроса. В обычной транзакции такого требования нет: заморозили мир, попробовали ряд последовательных действий, получилось — ура, нет — откатились. Никаких дополнительных ограничений.
У саги эти ограничения есть, и они крайне важны (но про них редко вспоминают, даже в документации разного рода). И если для каждой потенциальной саги проверять (доказывать) наличие компенсационных запросов, примениых на всем множестве возможных данных — с сагами проблем не будет.
Да, конечно, на выходных напишу на elixirforum, мне хотелось понять по реакции аудитории, что подсветить, что — наоборот — затенить, и главное — что переделать. А то ко мне там относятся слишком уж уважительно, и конструктивную критику я услышу вряд ли.
Если бы мне втемяшилось создать дубля, я бы его точно сделал не таким унылым.
Давайте принесём в этот разговор аксиоматику, для начала, а то скоро начнутся аргументы «моя сага длиннее».
Вот тут впервые было дано определение, поэтому нет никаких причин его не использовать (тем более, что все современные ссылки дают его же):
Вместо «database management system» в общем случае нужно, конечно, читать «saga management system», это не обязательно база, но чуваки старались генерализовать по-минимуму.
Итак. Тут прямым текстом сказано, что существование компенсирующих транзакций — обязательное условие. Если нельзя определить компенсируюшую транзакцию на всем множестве значений — саге не бывать. Поэтому:
— это действительно сага, потому что компенсирующая транзакция определена всегда. А вот:
— уже нет. Понятно, потому что реверсивная транзакция для перевода не определена в данном случае. Зато:
— снова да.
В общем,
Это реверсивная транзакция, если она определена — все в порядке. В этой стейт машине должен быть определен переход назад (я зря не сказал, конечно, что это не любой конечный автомат в вакууме, а такой специальный, у которого всем исходящим стрелочкам соответствуют парные входящие).
Опять же, для наведения порядка, для поверки, так сказать, алгеброй гармонии ивентдрайвинга (-драйва). Если есть валидированная сага, значит можно вызвать «undo» и не париться, а не городить специальную функцию обработки «вот такой ивент вот в такой ситуации». Хоть на аспектах этот «undo» впилить — и voilà.
Если бы мне требовался совет, как лучше начинать тексты, я бы спросил умного человека, а не тупого хабрахомяка с претензией.
Чё?
Библиотеки, фреймворки, алгоритмику, и т. п.
Быстро и пуленепробиваемо.
У такого разработчика зона ответственности не меньше, а часто — больше, ибо от его факапов может пострадать весь бизнес.
Архитектор обязан писать код 60–80% своего вреени, иначе он полностью оторвётся от корней и начнет придумывать ковры-самолеты для полета на Марс.
Что не так? — Да буквально всё. Если в конторе нет возможности вырасти по деньгам до приемлемых величин (сравнимых с руководителями крупных отделов, хотя бы), без необходимости иметь подчиненных — шанс нанять крутого разработчика как бы отрицательный (или придется врать на собеседовании).
Так себе план найма, хотя для галер сойдёт.
Да ну? А что делать с людьми, которые не хотят становиться лидами, а хотят писать код, и действительно умеют это делать? Выгонять на мороз?
У меня был случай, чтобы не ссориться с эйчарами, бухгалтерией и прочими бюрократами из-за выплат, у нас была создана «Aleksei’s team», но подчиненных там все равно никаких, конечно, не было.
Неужели? Жаль только, что они все написаны людьми, которые мало что понимают в том, зачем акторная модель вообще нужна.