Вы берете какой-то простой кейс (одна таблица, одно уведомление, и всех устраивает что запись в таблице есть, а уведомление может произойти через час или день. Это eventually transactional какой-то кейс учебный.
Берем реальный боевой пример: обновление таблиц в двух разных базах (кассандра и мсскл), уведомление внутреннего и внешнего сервисов, отправка письма пользователю. Все должно быть не eventually, а реальной транзакцией. Расскажите как вы это реализуете с outbox таблицей.
Это уже ньюансы, можно при желании реализовать graceful shutdown где ждать завершения всех потоков. Да, при аварийном завершении все будет плохо. Но зато у нас нет дополнительных таблиц и сервисов, которые тоже могут упасть, все относительно..
Не совсем понятно как именно гарантируется согласованность - за счет чего? Со всеми подводными камнями - система может пребывать в неконсистентном состоянии неограниченное время, как и в случае без outbox. Фактически с outbox-ом мы просто можем делать много попыток доставки, через любые интервалы, надеясь что рано или поздно сообщение дойдет (если повезет). Что нам мешает делать то же самое из главного обработчика? Результат можно вернуть сразу, а фоновым потоком делать попытки доставки, записывая ошибки в лог.
Пришел к такому выводу относительно написания юнит тестов - CPU-bound методы обычно идеально подходят под юнит тесты. Пример: хмл парсер с кучей corner-cases внутри. Генерим разные xml на входе, проверяем правильность объектов на выходе. Любые функции, которые хитро что-то высчитывают, регулярки там всякие. Такого кода обычно очень мало в большом проекте. Писать такие тесты даже где-то приятно. IO-bound ETL функции - аля "прочитай из базы - передай дальше в другой микросервис" (99% функционала в больших e-com компаниях) превращаются в бесполезные "the code I wrote is the code I wrote" проверки, которые просто дублируют всю логику. Такие тесты изматывают и угнетают, я их пишу исключительно для прохождения барьера по покрытию (в больших компаниях иначе не задеплоить свой код). Кстати, с появлением AI помощников появилась надежда, что наконец-то написание этих ваших тестов для IO ETL методов можно спихнуть на AI бота. Но пока чето не очень, именно такие тривиальные, казалось бы, методы chatgpt почему-то очень плохо пока умеет и получается корявенько.
Обожаю когда выбирают модную технологию (с непонятными подчеркиваниями в простейшем коде), тратят кучу времени на отключение основных фич типа GC, и в итоге счастливы, что избавились от С++
Как именно выбирается "самый быстрый" клиент для соединения? Например, если в графе сотни клиентов, и появляется новый клиент К, как ему подключиться к самому близкому для него (по rtt) клиенту в этом графе?
С rust-ом возникает другая проблема - большую часть времени тратишь на изучение "правильного обхода" ограничений, которые понатыканы буквально везде (а обходить их придется, если писать что-то более сложное чем hello world)
Для справки следовало бы указать, что в клауд гейминге используется исключительно WebRTC, и описать захват кадров из X11 доступными способами для передачи в любой поток.
Хотелось бы услышать мнение специалиста. Но насколько я знаю в аналоговых схемах с несколькими источниками питания, контур не обязан замыкаться на одном генераторе-источнике, контур образуется и между разными генераторами
Хотя если есть несколько электростанций и все они заземлены у вас во дворе, то получается что значение будет иметь и напряжение на каждой станции, выбрана будет та, у которой наибольшая разность потенциалов с вашей фазой
Хороший вопрос! Специалист больше расскажет здесь, но я предполагаю что на тот, к которому меньше сопротивление, т.е. физически ближайший заземленный провод ЛЭП.
Мы говорим про контур, а не про физическое местоположение электронов. Контур начинается и заканчивается на электростанции, ни в какую землю ток уходить не может, а возвращается через ближайшее заземление обратно на генератор.
Вы берете какой-то простой кейс (одна таблица, одно уведомление, и всех устраивает что запись в таблице есть, а уведомление может произойти через час или день. Это eventually transactional какой-то кейс учебный.
Берем реальный боевой пример: обновление таблиц в двух разных базах (кассандра и мсскл), уведомление внутреннего и внешнего сервисов, отправка письма пользователю. Все должно быть не eventually, а реальной транзакцией. Расскажите как вы это реализуете с outbox таблицей.
Это уже ньюансы, можно при желании реализовать graceful shutdown где ждать завершения всех потоков. Да, при аварийном завершении все будет плохо. Но зато у нас нет дополнительных таблиц и сервисов, которые тоже могут упасть, все относительно..
Не совсем понятно как именно гарантируется согласованность - за счет чего? Со всеми подводными камнями - система может пребывать в неконсистентном состоянии неограниченное время, как и в случае без outbox. Фактически с outbox-ом мы просто можем делать много попыток доставки, через любые интервалы, надеясь что рано или поздно сообщение дойдет (если повезет). Что нам мешает делать то же самое из главного обработчика? Результат можно вернуть сразу, а фоновым потоком делать попытки доставки, записывая ошибки в лог.
Пришел к такому выводу относительно написания юнит тестов - CPU-bound методы обычно идеально подходят под юнит тесты. Пример: хмл парсер с кучей corner-cases внутри. Генерим разные xml на входе, проверяем правильность объектов на выходе. Любые функции, которые хитро что-то высчитывают, регулярки там всякие. Такого кода обычно очень мало в большом проекте. Писать такие тесты даже где-то приятно.
IO-bound ETL функции - аля "прочитай из базы - передай дальше в другой микросервис" (99% функционала в больших e-com компаниях) превращаются в бесполезные "the code I wrote is the code I wrote" проверки, которые просто дублируют всю логику. Такие тесты изматывают и угнетают, я их пишу исключительно для прохождения барьера по покрытию (в больших компаниях иначе не задеплоить свой код).
Кстати, с появлением AI помощников появилась надежда, что наконец-то написание этих ваших тестов для IO ETL методов можно спихнуть на AI бота. Но пока чето не очень, именно такие тривиальные, казалось бы, методы chatgpt почему-то очень плохо пока умеет и получается корявенько.
&Dog::name;
У вас потерялся static?
Почему-то вспомнился миф про "640k ought to be enough for anybody"..
Обожаю когда выбирают модную технологию (с непонятными подчеркиваниями в простейшем коде), тратят кучу времени на отключение основных фич типа GC, и в итоге счастливы, что избавились от С++
Как именно выбирается "самый быстрый" клиент для соединения? Например, если в графе сотни клиентов, и появляется новый клиент К, как ему подключиться к самому близкому для него (по rtt) клиенту в этом графе?
Не соответствуют ли полученные графики характеристикам конденсаторов, установленных в цепочках питания памяти?
С rust-ом возникает другая проблема - большую часть времени тратишь на изучение "правильного обхода" ограничений, которые понатыканы буквально везде (а обходить их придется, если писать что-то более сложное чем hello world)
Для справки следовало бы указать, что в клауд гейминге используется исключительно WebRTC, и описать захват кадров из X11 доступными способами для передачи в любой поток.
Так куда все-таки уходит ток через заземление?
Может ли возникнуть замкнутый контур между разными генераторами тока?
Хотелось бы услышать мнение специалиста. Но насколько я знаю в аналоговых схемах с несколькими источниками питания, контур не обязан замыкаться на одном генераторе-источнике, контур образуется и между разными генераторами
Хотя если есть несколько электростанций и все они заземлены у вас во дворе, то получается что значение будет иметь и напряжение на каждой станции, выбрана будет та, у которой наибольшая разность потенциалов с вашей фазой
Хороший вопрос! Специалист больше расскажет здесь, но я предполагаю что на тот, к которому меньше сопротивление, т.е. физически ближайший заземленный провод ЛЭП.
Ну если передатчик вне пределов планеты не "заземлен" то и ток не потечет через "землю", заземлять принимающий контур бессмысленно в такой схеме
Мы говорим про контур, а не про физическое местоположение электронов. Контур начинается и заканчивается на электростанции, ни в какую землю ток уходить не может, а возвращается через ближайшее заземление обратно на генератор.
А куда они по вашему денутся?
Да нет же, земля просто играет роль проводника, а разность потенциалов возникает на источнике где-то на электростанции.