Изменения в одном микросервисе тоже легко могут поломать другой. Так что мотивация для распила монолита так себе. А вот существенное усложнение системы налицо. Если оно окупается, то гут.
С практической точки зрения - конечно оверинженеринг. Но с точки зрения потрогать технологии в действии - вполне годно. Да и показать в качестве портфолио можно
Был у них на гошном митапе в Лимассоле. Отличное мероприятие получилось. Один из докладчиков был создатель сервиса для рассылки уведомлений через различные транспорты Centrifugo. В ещё поразил технически грамотный Engineering Manager.
Тоже интересно понять, как в Go базу тестировать. В PHP, к примеру, для тестов поднимается тестовая база, которая наполняется данными. Весьма удобно. Подобный подход делаем и в гошном сервисе.
Года 4-е назад на одном проекте был соблазн использовать Pulimni именно из-за поддержки в нем обычных языков программирования. Но потом все же выбор был сделан в пользу Terraform из-за его понятности и близости DevOps инженерам. С Pulimni, к сожалению, все намного сложнее было. Не скажу, как сейчас обстоят дела. Но в компании, где работаю, тоже Terraform. Да и в объявлениях о работе Pulumni упоминается нечасто.
У нас прямо в правилах коммуникации прописано, что никаких приватов с ожиданием ответа в Slack. Пишешь все, что хочешь сказать сразу. И, желательно, одним сообщением. Но даже это не всегда помогает
ИМХО если платеж делается клиентом в режиме реального времени, то решение о повторном запросе лучше предоставить ему самому.
Другое дело, если речь идёт о каких-то повторяющихся платежах. То да, повтор нужно делать. Причем при любом раскладе. Не хватает денег на счету, отправляется уведомление клиенту и повтор через несколько часов или на следующий день.
Ну и ID транзакции слать всегда, о чем автор собирается написать.
Последний метод — Clone, который позволяет забрать что-то из арены обратно в heap даже после удаления. Ведь если обратиться к памяти арены после ее освобождения, данные будут битыми и все сломается.
Имеется ввиду, что забрать в хип можно до освобождения арены и эти данные будут доступны после освобождения арены, так?
Изменения в одном микросервисе тоже легко могут поломать другой. Так что мотивация для распила монолита так себе. А вот существенное усложнение системы налицо. Если оно окупается, то гут.
С практической точки зрения - конечно оверинженеринг. Но с точки зрения потрогать технологии в действии - вполне годно. Да и показать в качестве портфолио можно
Был у них на гошном митапе в Лимассоле. Отличное мероприятие получилось. Один из докладчиков был создатель сервиса для рассылки уведомлений через различные транспорты Centrifugo. В ещё поразил технически грамотный Engineering Manager.
В Китае, кстати, Wise работает, а Revolut нет
Тоже интересно понять, как в Go базу тестировать. В PHP, к примеру, для тестов поднимается тестовая база, которая наполняется данными. Весьма удобно. Подобный подход делаем и в гошном сервисе.
Конкурентность и параллелизм не одно и тоже! Каналы это инструмент для контроля конкурентности, в не параллелизма.
Можно все название?
Года 4-е назад на одном проекте был соблазн использовать Pulimni именно из-за поддержки в нем обычных языков программирования. Но потом все же выбор был сделан в пользу Terraform из-за его понятности и близости DevOps инженерам. С Pulimni, к сожалению, все намного сложнее было. Не скажу, как сейчас обстоят дела. Но в компании, где работаю, тоже Terraform. Да и в объявлениях о работе Pulumni упоминается нечасто.
Чтобы увидеть микроменеджмент данном конкретном случае не нужно было столько времени тратить. В первые пару недель уже должно быть понятно.
Вопрос возникает, почему держат такого начальника при том, что сроки все время срываются и текучка опытных инженеров большая.
То, что намешано - это печально. Очень трудно успевать и там, и там. Так как знания и умения из разных областей. Как уже указывали в комментарии выше
У нас прямо в правилах коммуникации прописано, что никаких приватов с ожиданием ответа в Slack. Пишешь все, что хочешь сказать сразу. И, желательно, одним сообщением. Но даже это не всегда помогает
ИМХО если платеж делается клиентом в режиме реального времени, то решение о повторном запросе лучше предоставить ему самому.
Другое дело, если речь идёт о каких-то повторяющихся платежах. То да, повтор нужно делать. Причем при любом раскладе. Не хватает денег на счету, отправляется уведомление клиенту и повтор через несколько часов или на следующий день.
Ну и ID транзакции слать всегда, о чем автор собирается написать.
В одной крупной известной компании раз в полгода надо проходить Полиграф. И это не оборона или разведка.
Если использовать мультистейжевую сборку, то на последнем этапе, где запускается собранный сервис, слои, созданные на этапе сборки не будут доступны.
Как раз ИИ должен думать и проявлять чувства. То, что сейчас выдаётся за ИИ им ещё не является. Но кто знает, как оно повернется в ближайшем будущем.
Было бы интересно узнать, как сломали Слак Диснея. Убер сломали украденными кредами сотрудника. Сам Слак тут явно не причем
Спасибо за интересную статью!
А можно по-подробнее насчет сжатия?
А что насчёт полного vacuum? Он все также лочит таблицы?
Спасибо за интересную и познавательную статью!
Имеется ввиду, что забрать в хип можно до освобождения арены и эти данные будут доступны после освобождения арены, так?
Отличное выступление на эту тему - https://youtu.be/0UmUgaJwEr0. Там ещё аналогия классная с засыпанием приведена.