У меня детская травма, связанная с игрой Ну, погоди! Как вижу картинку - сразу ее вспоминаю, каждый раз.
Мне было лет 6, летели в ил-86, в Москву из Ташкента, и там раздавали эти электронные игры по салону, мы сидели после крыльев, папа сказал - иди сбегай, попроси игру, поиграешь, ну я побежал, но не успел.
Ниче не понятно, хотя тема интересная. В статье нейрослоп перемешан с личным мнением, начинаешь прокручивать нейрослоп и теряется вообще вся суть. Можете по-нормальному переписать?
Вот да, когда началась вся эта канитель - новые странные приложения казались мне банковским скамом. Что интересно - у моего банка оригинальное приложение (я на iOS) проработало очень долго, отваливалась периодически только логин и одна-две функции внутри, ну и пуши.
Потом я все же начал ставить все эти новые приложения, старые не удалял, и пользовался всеми понемногу. И по прошествии времени заметил, что оригинальное приложение было самым удобным и интуитивно понятным. Это что типа аппловские гайды и проверки перед публикацией так влияют?
Ну а сейчас вообще оно ставиться как один большой Iframe (или даже как мини браузер) и просто тупо ведет на веб версию. Никакой апп стор не нужен и работает на полностью зарубежном айфоне в другой стране. Но что интересно - даже предлагает включить Face ID.
Кажется это очередная дичь в стиле "ИИ нас всех заменит". Почему не рассматривается вариант например, что народ начинает понимать, что ИТ сфера перенасытилась и просто перестают сюда идти?
С другой стороны - для олдовых сениоров это же хорошо. Все будут как 80-летние кобольщики и просить много денег.
Да и как бы 2031 год уже через 5 лет, бумеры даже еще работают, поколение X тоже, миллениалы тем более, массово на пенсию не собираются, помирать тем более.
Да, да, вы как бы больше боролись с графом зависимостей в NestJS и TypeScript. C# как будто бы в этом плане получше и проблема сложности перетекает на новый уровень.
И я еще забыл упомянуть один критерий в плане организации кода. Выделение каждого бизнес-метода в отдельный класс - снижает шанс на конфликты мержа в системах контроля версий. Это когда над проектом работают много людей и, допустим нескольким из них в спринте поставили задачи, которые затрагивают один большой файл - условный UserService. Чем мельче дробление, тем меньше шанс конфликта.
Насколько я понял основная идея - это выделить каждый метод из service в handler и затем как из кирпичиков строить дом. И направление зависимостей. Но, скажем так, в C#, которым я пользуюсь, у меня никогда не было проблем с циклическими зависимостями. Но проблемы все равно остаются.
External service в итоге вырождается в тот же самый бывший service, только внутри не собственно бизнес код, а вызовы хендлеров.
С тем же успехом можно было сделать так
interafce ICreateUserHandler
{
Result CreateUser();
}
interafce IGetUserByEmailHandler
{
Result GetUserByEmail();
}
interafce IUserServiceExternal : ICreateUserHandler, IGetUserByEmailHandler
{
}
class UserService : IUserServiceExternal
{
Result CreateUser()
{
...
}
Result GetUserByEmail()
{
...
}
}
И в контроллер инжектить именно IUserServiceExternal, но не плодить 100500 классов хендлеров. То есть формат размещения кода особо не влияет.
Я то в своих проектах тоже пришел к этим условным handler, и так, чтобы их можно было собирать в цепочки еще, внутри оркестраторов или внутри друг друга (это кстати отражает BMPN / IDEF0). Но по результату могу сказать, что это особо не помогло побороть сложность.
Хендлер вроде бы один, но начинают появляться условные ветки, от которых код внутри хендлера должен вести себя немного по разному. Ну например когда создаем заказ из UI и из API, там немного разные правила. Начинаешь думать, что с этим делать. И там дилемма - либо делать два хендлера, где по началу 95% одинаковое (привет дублирование и любое изменение, которое нужно в двух хендлерах - нужно не забыть делать в двух хендлерах). Либо начинать мутить и выводить общий код в новый общий хендлер, либо делать что-то вроде шаблонных методов, или цепочек декораторов. И все снова скатывается в говнокод и кучу зависимостей.
И еще я все же ждал в статье блок, посвященный транзакциями. Там это реально проблема.
Вот пример недавней новой фичи.
Мы обрабатываем заказы в фоновом режиме. У нас есть хендлер, который качает их из внешней системы, там же обернуто в транзакцию и retry policy, причем как к внешней системе, так и в момент сохранения в БД. Далее у нас есть хендлер на обработку заказа, хендлер на отмену, хендлер на удаление. Каждый из них в транзакции и обернут в retry policy. Эти бизнес-процессы были сделаны ну допустим пару лет назад.
И вот приходит запрос сделать задержку в обработке заказов. Мы его должны скачать, сохранить, обработать частично (чтобы резерв товара прошел), но не отправлять на склад. И потом просто ждать. По истечении времени, например 4 часа - нам надо заново скачать заказ из внешней системы (потому что он мог изменится за 4 часа) и снова прогнать через процессинг. Но! По другим бизнес правилам, мы не можем дублировать заказы и нам надо как-то умудрится снять резерв, не потеряв его (потому что мы пообещали уже, что у нас есть товар под первую копию заказа).
То есть нам сначала надо прогнать отмену и удаление первой копии ордера и только потом создать новый. То есть, набирая этот новый процесс существующими хендлерами - оркестратор выглядит так
1. Handler 1: Скачать новую копию заказа
a) тут внимание, некоторые внешние системы требуют отправить подтверждение,
что мы скачали заказ, но мы не можем это сейчас вызвать, потому что
мы еще не сохранили новую копию заказа, то есть нам надо вызывать этот
хендлер как бы частично
2. Handler 2: Отменить старую копию
а) Handler 2-1: Отменить отгрузки (1 .. N) [у нас на UI есть кнопка
для отмены одной конкретной отгрузки, то есть это реально еще один
вложенный самостоятельный хендлдер]
б) Handler 2-2: Отменить сам заказ [отменить заказ без отмены всех
вложенных отгрузок нельзя]
3. Handler 3: Создать заказ (он уже и так вызывается из трех мест -
UI, API, плагины/вебхуки)
4. Handler 4: Запустить обработку заказа, но без отправки отгрузкок на склад,
это фоновая операция, там у нас очередь [это еще один пример хендлера,
который тоже вызывается из 2-3 мест, но именно тут надо его вызывть
частично как бы]
5. Handler 5: На самом деле это продолжение Handler 1, потому что теперь
наконец-то мы можем подвердить внешней системе, что мы скачали новую
копию заказа
И вот теперь представьте, что каждый хендлер тут имеет свою retry policy, этот оркестратор может упасть на ЛЮБОМ этапе, но нужно обеспечить повторяемость этой сложной операции, потому что, если мы потеряем заказ - клиент придет с жалобами и нам придется заплатить штраф.
Ну и чтобы жизнь медом не казалась - DDD тут не совсем поможет, потому что в первую очередь оно начинает тормозить на постоянных операциях восстановления сущности/агрегата из хранилища и потом сохранения нового состояния. Например хендлер "отмена отгрузки" внутри вызывает хендлер "возврат резерва товара". Это работа со складом, которая может быть выполнена только в один поток (чтобы не продать больше, чем есть на складе) и надо максимально ускорить и стабилизировать этот процесс, избавившись от кучи лишних обращений по сети и длинных транзакций. И в итоге этот модуль лежит в хранимых процедурах в БД, и все операций выполняются за один сетевой вызов к БД.
Так то эта вся канитель существует уже давно, сколько я себя помню программистом. То есть найм был сломан всегда в этом плане. Просто раньше это решалось откликом на след вакансию. Сейчас вакансий мало, людей много. И обсуждать сломанный найм массово начали только в последний год-два.
У меня никогда не было проблем с тем, чтобы накопить. Как-то само копилось. Родители всегда говорили надо на черный день откладывать, видимо отложилось на подсознании. И супруга экономная оказалась 😊, хотя было так, что ее зп - это "ее", а моя - это "наше".
Ну и однажды я задумался - а куда их девать? Но прежде чем прийти к этой мысли - должно было случится несколько событий. А именно - закрыть все свои гештальты из детства, юности и молодости. Как то - купить себе тот смартфон, который всегда хотел. Или компьютер, или машину, или квартиру. Побывать в тех местах, о которых мечтал или хотя бы интересовался. А если еще дети есть - там еще целый пласт расходов. Так что 500к даже в течение лет 5-7-10 подряд может не хватить.
Таким образом, пришлось сначала обзавестись квартирой, машиной, слетать в США, Мексику, помочь родителям с жильем в столице, не говоря уже о смартфонах последней модели себе и супруге, ноутах и компьютерах.
Все это заняло определенное время. И вот в возрасте примерно 35+ лет, когда все хотелки наконец-то были удовлетворены, в голове возник философский вопрос "а что делать дальше?"
Книжек про инвестирование я не читал. Поэтому методом проб и ошибок. По итогу, чисто по-моему опыту - инвестиции это отдельная работа. И теперь краткая справка, что пробовал я или мои знакомые и что из этого вышло.
Муть:
Вложения в совместные бизнесы с друзьями - туфта, все прогорело
Всякие мутные инвестиционные схемы в банках, например через разбиение суммы вложений на части и распределение по корзинкам - это самая мутная муть, надо очень внимательно читать условия выхода мелким шрифтом со звездочкой. Я не повелся. Но это событие (меня банк заспамил) привело к тому, что я решил попробовать SP500 и о нем ниже
Управление через брокера - наверное, если брокер - это ваш друг, то будет надежней, но знакомый повелся и ничего не смог вернуть. Опять же какие-то мутные условия выхода мелким шрифтом со звездочкой.
Наверное не муть, если задним умом:
Недвижка, с вводом эскроу счетов, льготной ипотеки и пандемии - цены взлетели раза в два. Но это в долгосрок. Надо сидеть и ждать, и платить налоги и ЖКХ.
Просто тупо сидеть в валюте. Опять же это в долгосрок - тренд всегда в рост, даже с регулярными ямами. Но за все время только один раз удалось продать действительно "на хаях", когда доллар был 118.5 руб. В большинстве случаев как повезет, думаешь ну вот 80, продал, а завтра 100. Тут кстати, если бы не вкладывался в бизнесы друзей - ничего не прогорело бы и еще "заработал" бы больше.
Похоже, что не совсем муть:
Депозиты в банках - подходит для поддержания штанов, но нужна весомая сумма (от 5 миллионов) и процентная ставка 15-20%, чтобы выхлоп был не копеечный. Тогда этого хватает, чтобы покрыть ощутимую часть текущих ежемесячных расходов. Прямая работа капитала. Но все это время основная сумма медленно сгорает.
Но больше всего понравился SP500 - 20% в валюте в первый год, только если бы не 2022 год 😅
А прикиньте еще есть товарищи, которые НЕ учатся все это время и застревают. Делают одни и те же ошибки. Не меньшее мучение со стороны старших разработчиков и лидов.
Зубы жителя? 😅 /s
У меня детская травма, связанная с игрой Ну, погоди! Как вижу картинку - сразу ее вспоминаю, каждый раз.
Мне было лет 6, летели в ил-86, в Москву из Ташкента, и там раздавали эти электронные игры по салону, мы сидели после крыльев, папа сказал - иди сбегай, попроси игру, поиграешь, ну я побежал, но не успел.
Так и живем 🙃
Че то не очень понятно со string format - заменили на тормознутую конкатенацию, которую исправляли в другом месте и все залетало?
Ниче не понятно, хотя тема интересная. В статье нейрослоп перемешан с личным мнением, начинаешь прокручивать нейрослоп и теряется вообще вся суть. Можете по-нормальному переписать?
Вот да, когда началась вся эта канитель - новые странные приложения казались мне банковским скамом. Что интересно - у моего банка оригинальное приложение (я на iOS) проработало очень долго, отваливалась периодически только логин и одна-две функции внутри, ну и пуши.
Потом я все же начал ставить все эти новые приложения, старые не удалял, и пользовался всеми понемногу. И по прошествии времени заметил, что оригинальное приложение было самым удобным и интуитивно понятным. Это что типа аппловские гайды и проверки перед публикацией так влияют?
Ну а сейчас вообще оно ставиться как один большой Iframe (или даже как мини браузер) и просто тупо ведет на веб версию. Никакой апп стор не нужен и работает на полностью зарубежном айфоне в другой стране. Но что интересно - даже предлагает включить Face ID.
Тоже показалось, что банк, которым я пользуюсь - перешел на такую схему еще задолго до. Прям куски интерфейса менялись.
Кажется это очередная дичь в стиле "ИИ нас всех заменит". Почему не рассматривается вариант например, что народ начинает понимать, что ИТ сфера перенасытилась и просто перестают сюда идти?
С другой стороны - для олдовых сениоров это же хорошо. Все будут как 80-летние кобольщики и просить много денег.
Да и как бы 2031 год уже через 5 лет, бумеры даже еще работают, поколение X тоже, миллениалы тем более, массово на пенсию не собираются, помирать тем более.
Да, да, вы как бы больше боролись с графом зависимостей в NestJS и TypeScript. C# как будто бы в этом плане получше и проблема сложности перетекает на новый уровень.
И я еще забыл упомянуть один критерий в плане организации кода. Выделение каждого бизнес-метода в отдельный класс - снижает шанс на конфликты мержа в системах контроля версий. Это когда над проектом работают много людей и, допустим нескольким из них в спринте поставили задачи, которые затрагивают один большой файл - условный UserService. Чем мельче дробление, тем меньше шанс конфликта.
Вот это автора утилиты бомбануло 😅
Насколько я понял основная идея - это выделить каждый метод из service в handler и затем как из кирпичиков строить дом. И направление зависимостей. Но, скажем так, в C#, которым я пользуюсь, у меня никогда не было проблем с циклическими зависимостями. Но проблемы все равно остаются.
External service в итоге вырождается в тот же самый бывший service, только внутри не собственно бизнес код, а вызовы хендлеров.
С тем же успехом можно было сделать так
И в контроллер инжектить именно IUserServiceExternal, но не плодить 100500 классов хендлеров. То есть формат размещения кода особо не влияет.
Я то в своих проектах тоже пришел к этим условным handler, и так, чтобы их можно было собирать в цепочки еще, внутри оркестраторов или внутри друг друга (это кстати отражает BMPN / IDEF0). Но по результату могу сказать, что это особо не помогло побороть сложность.
Хендлер вроде бы один, но начинают появляться условные ветки, от которых код внутри хендлера должен вести себя немного по разному. Ну например когда создаем заказ из UI и из API, там немного разные правила. Начинаешь думать, что с этим делать. И там дилемма - либо делать два хендлера, где по началу 95% одинаковое (привет дублирование и любое изменение, которое нужно в двух хендлерах - нужно не забыть делать в двух хендлерах). Либо начинать мутить и выводить общий код в новый общий хендлер, либо делать что-то вроде шаблонных методов, или цепочек декораторов. И все снова скатывается в говнокод и кучу зависимостей.
И еще я все же ждал в статье блок, посвященный транзакциями. Там это реально проблема.
Вот пример недавней новой фичи.
Мы обрабатываем заказы в фоновом режиме. У нас есть хендлер, который качает их из внешней системы, там же обернуто в транзакцию и retry policy, причем как к внешней системе, так и в момент сохранения в БД. Далее у нас есть хендлер на обработку заказа, хендлер на отмену, хендлер на удаление. Каждый из них в транзакции и обернут в retry policy. Эти бизнес-процессы были сделаны ну допустим пару лет назад.
И вот приходит запрос сделать задержку в обработке заказов. Мы его должны скачать, сохранить, обработать частично (чтобы резерв товара прошел), но не отправлять на склад. И потом просто ждать. По истечении времени, например 4 часа - нам надо заново скачать заказ из внешней системы (потому что он мог изменится за 4 часа) и снова прогнать через процессинг. Но! По другим бизнес правилам, мы не можем дублировать заказы и нам надо как-то умудрится снять резерв, не потеряв его (потому что мы пообещали уже, что у нас есть товар под первую копию заказа).
То есть нам сначала надо прогнать отмену и удаление первой копии ордера и только потом создать новый. То есть, набирая этот новый процесс существующими хендлерами - оркестратор выглядит так
И вот теперь представьте, что каждый хендлер тут имеет свою retry policy, этот оркестратор может упасть на ЛЮБОМ этапе, но нужно обеспечить повторяемость этой сложной операции, потому что, если мы потеряем заказ - клиент придет с жалобами и нам придется заплатить штраф.
Ну и чтобы жизнь медом не казалась - DDD тут не совсем поможет, потому что в первую очередь оно начинает тормозить на постоянных операциях восстановления сущности/агрегата из хранилища и потом сохранения нового состояния. Например хендлер "отмена отгрузки" внутри вызывает хендлер "возврат резерва товара". Это работа со складом, которая может быть выполнена только в один поток (чтобы не продать больше, чем есть на складе) и надо максимально ускорить и стабилизировать этот процесс, избавившись от кучи лишних обращений по сети и длинных транзакций. И в итоге этот модуль лежит в хранимых процедурах в БД, и все операций выполняются за один сетевой вызов к БД.
Так то эта вся канитель существует уже давно, сколько я себя помню программистом. То есть найм был сломан всегда в этом плане. Просто раньше это решалось откликом на след вакансию. Сейчас вакансий мало, людей много. И обсуждать сломанный найм массово начали только в последний год-два.
Ну вот, на самом интересном месте, давайте вторую часть 🫠
Вот как надо троллить этих ИИ ботов
А что ж мемную картинку не вставили в статью?
Оо, mechwarrior на подходе 🫠
Только недавно попалась статья, что какой-то там набор castle вырос в цене на over 9000%
У меня никогда не было проблем с тем, чтобы накопить. Как-то само копилось. Родители всегда говорили надо на черный день откладывать, видимо отложилось на подсознании. И супруга экономная оказалась 😊, хотя было так, что ее зп - это "ее", а моя - это "наше".
Ну и однажды я задумался - а куда их девать? Но прежде чем прийти к этой мысли - должно было случится несколько событий. А именно - закрыть все свои гештальты из детства, юности и молодости. Как то - купить себе тот смартфон, который всегда хотел. Или компьютер, или машину, или квартиру. Побывать в тех местах, о которых мечтал или хотя бы интересовался. А если еще дети есть - там еще целый пласт расходов. Так что 500к даже в течение лет 5-7-10 подряд может не хватить.
Таким образом, пришлось сначала обзавестись квартирой, машиной, слетать в США, Мексику, помочь родителям с жильем в столице, не говоря уже о смартфонах последней модели себе и супруге, ноутах и компьютерах.
Все это заняло определенное время. И вот в возрасте примерно 35+ лет, когда все хотелки наконец-то были удовлетворены, в голове возник философский вопрос "а что делать дальше?"
Книжек про инвестирование я не читал. Поэтому методом проб и ошибок. По итогу, чисто по-моему опыту - инвестиции это отдельная работа. И теперь краткая справка, что пробовал я или мои знакомые и что из этого вышло.
Муть:
Вложения в совместные бизнесы с друзьями - туфта, все прогорело
Всякие мутные инвестиционные схемы в банках, например через разбиение суммы вложений на части и распределение по корзинкам - это самая мутная муть, надо очень внимательно читать условия выхода мелким шрифтом со звездочкой. Я не повелся. Но это событие (меня банк заспамил) привело к тому, что я решил попробовать SP500 и о нем ниже
Управление через брокера - наверное, если брокер - это ваш друг, то будет надежней, но знакомый повелся и ничего не смог вернуть. Опять же какие-то мутные условия выхода мелким шрифтом со звездочкой.
Наверное не муть, если задним умом:
Недвижка, с вводом эскроу счетов, льготной ипотеки и пандемии - цены взлетели раза в два. Но это в долгосрок. Надо сидеть и ждать, и платить налоги и ЖКХ.
Просто тупо сидеть в валюте. Опять же это в долгосрок - тренд всегда в рост, даже с регулярными ямами. Но за все время только один раз удалось продать действительно "на хаях", когда доллар был 118.5 руб. В большинстве случаев как повезет, думаешь ну вот 80, продал, а завтра 100. Тут кстати, если бы не вкладывался в бизнесы друзей - ничего не прогорело бы и еще "заработал" бы больше.
Похоже, что не совсем муть:
Депозиты в банках - подходит для поддержания штанов, но нужна весомая сумма (от 5 миллионов) и процентная ставка 15-20%, чтобы выхлоп был не копеечный. Тогда этого хватает, чтобы покрыть ощутимую часть текущих ежемесячных расходов. Прямая работа капитала. Но все это время основная сумма медленно сгорает.
Но больше всего понравился SP500 - 20% в валюте в первый год, только если бы не 2022 год 😅
Вот так и живем.
Таки вертолет же, какое НЛО
https://www.war.gov/portals/1/Interactive/2026/UFO/Slideshow/FBI-Photo-B7-.jpg
Вот кем надо быть чтоб пройти все собесы в Яндекс! И это с учетом того, что с алгоритмами там работают аналитики, а не программисты 🫠
А прикиньте еще есть товарищи, которые НЕ учатся все это время и застревают. Делают одни и те же ошибки. Не меньшее мучение со стороны старших разработчиков и лидов.