Я выше писал, что это работа ради работы. Создать почтовую службу которая будет дергать SMTP сервер - это не сложно. Есть в конце концов org.apache.commons.mail никакого спринг бута совсем не надо.
Я указывал на две проблемы. Первая: затраты на развертывание и администрирование VPS превышают пользу от него. Вторая: организовать отправку писем правильно, это еще на вскидку +90% к той работе, которая была выполнена в рамках статьи.
В тоже время сторонние почтовые службы уже решили все эти проблемы, поддерживают очереди отправки, повторные отправки в случае сетевых ошибок и тп и тд. Использовать свой почтовый сервер целесообразно как правило только в рамках отправки почты внутри своего домена. Как то так если коротенько.
Полный набор причин для бана не раскрывается обычно, но как правило это 1. низкое доверие к домену 2. рассылка однотипных по содержанию писем 3. частота и плотность рассылки, все это выбивается обычно из нормальной модели поведения
плюс некоторые недовольные клиенты будут постить репорты, по некоторым базам, на основании которых потом составляются черные списки, насколько я помню, достаточно 10 репортов чтобы попасть в их список.
С учетом того, что созданный мейл-сервер с высокой вероятностью очень скоро окажется в блеклистах основных почтовых служб, проще использовать готовые почтовые службы с их готовыми api, и думаю, что это будет не дороже оплаты VPS. Ну и теми строками кода вы не отделаетесь. Надо делать очередь отправки, вводить лимиты на отправку, проверять на дубли, проверять на спам, проверять на сетевые ошибки, повторять отправку, чистить очередь если превышен предел повторных отправок, кучу кучу всего придется доделывать/дописывать.
В курилке постоянно мозговые штурмы были. И бредовую идею можно было озвучить. То есть передача опыта какая-никакая была постоянно. А на удаленке народ варится в собственном соку. Да еще и время есть подумать "а может бросить все и уйти к другому". И когда ты в офисе, хоть появляется ощущение (да даже если иллюзия), что не ты один тащишь всю эту лямку
ну я как бы тоже в теме парсинга плотно. используйте строки для полей данных, а если структура пришла иная - ругайтесь матом в консольке, а как иначе то? "типизация или нетипизация" проблему разных структур не особо решит
По опыту это становится миной замедленного действия если потом проект начинает жить и развиваться. Но что-то одноразовое быстрое, конечно да, это проще и быстрее.
У горутин бывает интересное поведение в зависимости от их кол-ва. Была в свое время классная статья с анимашками, по ней можно было грубо прикидывать сколько и как запускать для достижения нужного результата не в ущерб производительности. https://divan.dev/posts/go_concurrency_visualize/
Это вброс? Ну добавьте тогда еще Мавроди в список. Для вишенки. А еще лучше прочитайте книгу "100 топ форбс в России" (как то так называется, издавалась приблизительно в 2016..2018 году помоему), там есть биографии многих талантливых и удачливых бизнесменов, у 95% которых обычно есть строчки в карьере в виде перехода из секретаря комсомольской ячейки завода/фабрики -> контролирующий акционер завода/фабрики...
QR код надо получить наверное, с указанием маршрута, кол-ва пассажиров, целей поездки /сарказм конец
Вода все равно попадает. Он конечно расчитан на работу во влажной среде, но не постоянно и кол-во воды больше чем во время дождя.
Подшипники вентилятора радиатора убьете быстро так.
Сегодня видел видео как китаец зашел в лифт с большой литиевой батарейкой. Двери лифта закрылись, батарейка вспыхнула через секунду. Ужасная смерть.
Вы представляете какие там токи идут? Мокрым полотенцем такое охлаждать - это нобелевка, не меньше
Я выше писал, что это работа ради работы. Создать почтовую службу которая будет дергать SMTP сервер - это не сложно. Есть в конце концов org.apache.commons.mail никакого спринг бута совсем не надо.
Я указывал на две проблемы. Первая: затраты на развертывание и администрирование VPS превышают пользу от него. Вторая: организовать отправку писем правильно, это еще на вскидку +90% к той работе, которая была выполнена в рамках статьи.
В тоже время сторонние почтовые службы уже решили все эти проблемы, поддерживают очереди отправки, повторные отправки в случае сетевых ошибок и тп и тд. Использовать свой почтовый сервер целесообразно как правило только в рамках отправки почты внутри своего домена. Как то так если коротенько.
Полный набор причин для бана не раскрывается обычно, но как правило это
1. низкое доверие к домену
2. рассылка однотипных по содержанию писем
3. частота и плотность рассылки, все это выбивается обычно из нормальной модели поведения
плюс некоторые недовольные клиенты будут постить репорты, по некоторым базам, на основании которых потом составляются черные списки, насколько я помню, достаточно 10 репортов чтобы попасть в их список.
С учетом того, что созданный мейл-сервер с высокой вероятностью очень скоро окажется в блеклистах основных почтовых служб, проще использовать готовые почтовые службы с их готовыми api, и думаю, что это будет не дороже оплаты VPS.
Ну и теми строками кода вы не отделаетесь. Надо делать очередь отправки, вводить лимиты на отправку, проверять на дубли, проверять на спам, проверять на сетевые ошибки, повторять отправку, чистить очередь если превышен предел повторных отправок, кучу кучу всего придется доделывать/дописывать.
В курилке постоянно мозговые штурмы были. И бредовую идею можно было озвучить. То есть передача опыта какая-никакая была постоянно. А на удаленке народ варится в собственном соку. Да еще и время есть подумать "а может бросить все и уйти к другому". И когда ты в офисе, хоть появляется ощущение (да даже если иллюзия), что не ты один тащишь всю эту лямку
ну я как бы тоже в теме парсинга плотно. используйте строки для полей данных, а если структура пришла иная - ругайтесь матом в консольке, а как иначе то? "типизация или нетипизация" проблему разных структур не особо решит
По опыту это становится миной замедленного действия если потом проект начинает жить и развиваться. Но что-то одноразовое быстрое, конечно да, это проще и быстрее.
У горутин бывает интересное поведение в зависимости от их кол-ва. Была в свое время классная статья с анимашками, по ней можно было грубо прикидывать сколько и как запускать для достижения нужного результата не в ущерб производительности. https://divan.dev/posts/go_concurrency_visualize/
Тогда не обижайтесь если работодатель сменит вас на другого, который в пешей доступности живет.
а еще у go есть https://github.com/valyala/fasthttp
Я понимаю, докеры и все такое. Но бинарник на go это и вебсервер сразу.
И операционной системе хватило сокетов?
На одной и той же машине?
10000 rps 40мс со вставкой в бд и чтением на коленке? А чем нагружали?
Что-то тут нечисто. 10т реквестов на одной машине уже нетривиально сгенерить. Хочется посмотреть как это делалось.
... и не начинал
Кстати, а убер сейчас стал прибыльным или все еще сжигает год за годом деньги?
Это вброс? Ну добавьте тогда еще Мавроди в список. Для вишенки. А еще лучше прочитайте книгу "100 топ форбс в России" (как то так называется, издавалась приблизительно в 2016..2018 году помоему), там есть биографии многих талантливых и удачливых бизнесменов, у 95% которых обычно есть строчки в карьере в виде перехода из секретаря комсомольской ячейки завода/фабрики -> контролирующий акционер завода/фабрики...