Статья построена на ошибочном предположении, что именно чат гпт уменьшил число вакансий ручных тестировщиков. Это не так (как минимум это не единственная причина).
Когда в проект / продукт внедряют тестирование - почти сразу становится очевидно:
Чтобы обеспечить качество - надо много тестов, есть некая критическая масса, когда они реально начинают помогать
Ручное тестирование - крайне нудная штука и на это уходит очень много времени
Поэтому почти сразу приходит мысль, что это надо автоматизировать.
А все остальное, в том числе и чат гпт - это инструменты, которые позволяют организовать и оптимизировать эту основную идею.
В разделе про Read Model довольно поверхностно - можно чуть более подробно?
в application layer, в обработчике события, вызываю фабричный метод и сохраняю транзакцию
А это к сожалению не раскрывает сути вашего решения - все складывают это в какую-то фабрику или фабричные метод или еще куда-нибудь, но это не решение проблемы. По умолчанию любая сущность имеет приватные сеттеры, чтобы сохранить свои инварианты. И тогда каким образом внутри фабричного метода вы создаете сущность, если у вас нет доступа к сеттерам?
Так то не поможет, напоминаю, что любая сущность по умолчанию имеет приватные сеттеры, чтобы сохранить свои инварианты. И то, что сделали новую сущность - совершенно никак не решает проблему. В новой сущности все так же надо делать 100500 полей в конструкторе или ... А вот на какой компромисс идете конкретно вы?
А я как-то встречал что 120% плана - это РОПу сливали теплых клиентов на регулярной основе, забирая у других. И когда вскрылась махинация - народ поувольняли.
У них senior - это в первую очередь менеджер и тим-лид, во вторую экспертные знания самого продукта, и только в третью чувак, который способен эффективно решить неоднозначную проблему
I own and deliver semi-annual/annual goals for my team
I define technical solutions or efficient operational processes that level up my team
I am a strong leader for my team with my impact beginning to extend outside my team
А чтобы управлять командой - нужны рычаги влияния. Но там нигде не написано, что senior может увольнять.
И еще не понятно - когда все это успевать. Пока ты бухаешь с начальством за понимание стратегических целей компании, составляешь и контролируешь планы для команды, собеседуешь людей, оптимизируешь процессы - теряешь техническую экспертизу для соответствия разделу Craft.
Пожалуй есть один выход - это когда работаешь лет 10 в компании, успел много чего поделать и на полугодовом ассасменте говоришь такой "ну я вон 5 лет назад делал вот эту хрень из уровня IC4-5-6, так что я достоин". Не уверен правда - сработает это или нет. Ведь один раз за 5 лет - это далеко от экспертизы.
По warehouse_id да, если заранее был выбран конкретный склад (например по сроку или стоимости доставки до конечного клиента и в том числе по остаткам). По category_id не думаю. Можно закодить машрутизатор на уровне приложения - который будет работать в несколько потоков, но класть заказы с пересекающимися товарами в один поток. Но зачем, если это сложнее, а пессимистичная или оптимистичная блокировка по сути делают то же самое. Можно просто вывести кол-во потоков в конфигурацию и экспериментальным образом подобрать нужное значение.
И есть как минимум три категории систем - на стороне продаж, на стороне склада (WMS) и OMS (order management system), которые скачивают заказы из первых, выбирают оптимальный склад и отправляют в WMS. И у всех трех есть свои особенности. Сложнее всего, пожалуй с OMS - когда они делают резерв, это еще не значит, что этот резерв реально создан для конкретного склада в WMS.
Чуть измененный вариант - построить на пессимистичной блокировке - добавить версию строки и обновлять. Если не совпадает - откат транзакции и retry.
Второй концептуальный способ - зная, что там в один поток, это сделать очередь (не важно на чем - кафка, раббит, таблица в бд, редис) и разбирать ее в один поток. С этого момента основной целью станет - выжать максимум из железа и субд. Так как мы уже знаем, что будет один поток, то блокировки не нужны, и можно что-нибудь придумать, например снизить уровень изоляции или даже вообще отказаться от транзакций. Из минусов - ордера с разными товарами, которые могли бы обработаться параллельно - не будут.
Резерв товара это по сути и есть конкуренция за товар. Все равно где-то в конце будет в один поток.
Один из способов - это построчная блокировка каждого товара. В my sql например есть select for update. Тогда заказы с разным набором товаров не будут друг другу мешать. Там будет всякие deadlock, они будут по тайм-ауту отваливаться. И в итоге окажется, что два заказа отвалились, но один из них смог бы обработаться, если повторно запустить. Поэтому просто сверху полируем retry policy и в целом все начинает работать. И чем больше линий в заказе тем он проблемней.
Аффтар пеши исчо, тема
сисекиспользования llm в hr не раскрыта - статья короткая.И кнопка turbo, которая замедляла 😅
Обман в резюме все равно не отменяет жопы с ценами что в России, что в Канаде.
Статья построена на ошибочном предположении, что именно чат гпт уменьшил число вакансий ручных тестировщиков. Это не так (как минимум это не единственная причина).
Когда в проект / продукт внедряют тестирование - почти сразу становится очевидно:
Чтобы обеспечить качество - надо много тестов, есть некая критическая масса, когда они реально начинают помогать
Ручное тестирование - крайне нудная штука и на это уходит очень много времени
Поэтому почти сразу приходит мысль, что это надо автоматизировать.
А все остальное, в том числе и чат гпт - это инструменты, которые позволяют организовать и оптимизировать эту основную идею.
Ну тогда может это и не сущность? Хотя чего гадать, подождем ответа
В разделе про Read Model довольно поверхностно - можно чуть более подробно?
А это к сожалению не раскрывает сути вашего решения - все складывают это в какую-то фабрику или фабричные метод или еще куда-нибудь, но это не решение проблемы. По умолчанию любая сущность имеет приватные сеттеры, чтобы сохранить свои инварианты. И тогда каким образом внутри фабричного метода вы создаете сущность, если у вас нет доступа к сеттерам?
Критиковать все могут, код покажите 😅
Так то не поможет, напоминаю, что любая сущность по умолчанию имеет приватные сеттеры, чтобы сохранить свои инварианты. И то, что сделали новую сущность - совершенно никак не решает проблему. В новой сущности все так же надо делать 100500 полей в конструкторе или ... А вот на какой компромисс идете конкретно вы?
А я как-то встречал что 120% плана - это РОПу сливали теплых клиентов на регулярной основе, забирая у других. И когда вскрылась махинация - народ поувольняли.
Dropboх тоже лукавит.
У них senior - это в первую очередь менеджер и тим-лид, во вторую экспертные знания самого продукта, и только в третью чувак, который способен эффективно решить неоднозначную проблему
А чтобы управлять командой - нужны рычаги влияния. Но там нигде не написано, что senior может увольнять.
И еще не понятно - когда все это успевать. Пока ты бухаешь с начальством за понимание стратегических целей компании, составляешь и контролируешь планы для команды, собеседуешь людей, оптимизируешь процессы - теряешь техническую экспертизу для соответствия разделу Craft.
Пожалуй есть один выход - это когда работаешь лет 10 в компании, успел много чего поделать и на полугодовом ассасменте говоришь такой "ну я вон 5 лет назад делал вот эту хрень из уровня IC4-5-6, так что я достоин". Не уверен правда - сработает это или нет. Ведь один раз за 5 лет - это далеко от экспертизы.
Побольше бы примеров кода и структуры солюшена.
Например что такое QueryHandlers в Application слое и чем они отличаются от DbQueryHandlers в инфраструктуре?
А что за Application Services и чем отличаются от domain сервисов? Что скажите насчет UseCase и UserStory?
А чем это отличается от спецификации? От перекладывания кода из одно места в другое - суть же не меняется.
Как вы создаете сущность из DTO, которое пришло из контроллера? Вот тут мой коммент где я уже собрал несколько вариантов https://habr.com/ru/articles/931866/comments/#comment_28640604
O_O, ништяк, оказывается есть шрифты, которые лучше показывают разницу между ! и i - а то я привык уже писать, чтоб глаз на замыливался
вместо
По warehouse_id да, если заранее был выбран конкретный склад (например по сроку или стоимости доставки до конечного клиента и в том числе по остаткам). По category_id не думаю. Можно закодить машрутизатор на уровне приложения - который будет работать в несколько потоков, но класть заказы с пересекающимися товарами в один поток. Но зачем, если это сложнее, а пессимистичная или оптимистичная блокировка по сути делают то же самое. Можно просто вывести кол-во потоков в конфигурацию и экспериментальным образом подобрать нужное значение.
И есть как минимум три категории систем - на стороне продаж, на стороне склада (WMS) и OMS (order management system), которые скачивают заказы из первых, выбирают оптимальный склад и отправляют в WMS. И у всех трех есть свои особенности. Сложнее всего, пожалуй с OMS - когда они делают резерв, это еще не значит, что этот резерв реально создан для конкретного склада в WMS.
Попутал немного - вариант 1а это пессимистичная блокировка, вариант 1б оптимистичная
$4-5k это для удаленки. Это уже лет 10 как минимум.
Прикольный сайт, на злобу дня и противопоставление levels.fyi 😅
Подскажите какие промты вы добавили в чат гпт, чтобы он стал более адекватным?
А они еще не спрашивают почему иконка сохранения - дискета?))
Чуть измененный вариант - построить на пессимистичной блокировке - добавить версию строки и обновлять. Если не совпадает - откат транзакции и retry.
Второй концептуальный способ - зная, что там в один поток, это сделать очередь (не важно на чем - кафка, раббит, таблица в бд, редис) и разбирать ее в один поток. С этого момента основной целью станет - выжать максимум из железа и субд. Так как мы уже знаем, что будет один поток, то блокировки не нужны, и можно что-нибудь придумать, например снизить уровень изоляции или даже вообще отказаться от транзакций. Из минусов - ордера с разными товарами, которые могли бы обработаться параллельно - не будут.
Резерв товара это по сути и есть конкуренция за товар. Все равно где-то в конце будет в один поток.
Один из способов - это построчная блокировка каждого товара. В my sql например есть select for update. Тогда заказы с разным набором товаров не будут друг другу мешать. Там будет всякие deadlock, они будут по тайм-ауту отваливаться. И в итоге окажется, что два заказа отвалились, но один из них смог бы обработаться, если повторно запустить. Поэтому просто сверху полируем retry policy и в целом все начинает работать. И чем больше линий в заказе тем он проблемней.
Потрясно! Да и сама идея закодить что-нибудь пиксельартовое под дос в современно мире!