Предлагаемое ограничение в 200 строк на компонент, как раз таки основано на обеспечении удобства отладки: нейронка сможет внушительное количество раз полностью переписывать код на основании замечаний автора приложения.
Перепробовал около 10-и автоматических систем по проверке орфографии. Ни одна не смогла поправить опечатку в слове "Была" (верно "Было") в тексте ниже.
Уважаемые коллеги! Была получено письмо, подтверждающее тот факт, что отчет...
Предположим цена у консервы из примера и правда поменялась из-за инвентаризации.
Произошло событие изменения цены, товары очутились в моей балансовой системе.
Я же не переносил остатки. Они сами перенеслись из-за того, что я ловлю события, выявляю положения товара, которое следует из события и сравниваю его с предыдущим.
Таким образом вам не нужно переносить остатки при внедрении такового сервиса.
Как очень подробно описано в статье, ничего не делаем.
С момента начала использования "новой" системы, мы относительно быстро доставим товар получателю или вернем продавцу или констатируем что он потерялся.
Таким образом сравнительно быстро товара у нас не станет физически, и его отсутствие у нас физически будет равно отсутствию его на балансе.
Правильно, но в случае, если у вашего объекта учета очень длинный жизненный цикл, можно придумать новое событие, которое может посавить ваш объект на баланс.
Например, в том случае, если в продуктовом консерва лежала до запуска сервиса, и еще долго будет лежать, можно поймать момент, когда у нее меняется цена (в больших сетях цены меняются приблизительно раз в неделю).
Учитывая систему "Подумай дважды", можно узнать текущее состояние на балансе Ozon, без суммирования со старой системой. Нужно лишь подождать пока новый сервис немного поработает.
По "Текущим состоянием" понимается количество товаров в Ozon на данный момент.
Если не считать копипаст из документации, в моем промте - 110 сток.
Предлагаемое ограничение в 200 строк на компонент, как раз таки основано на обеспечении удобства отладки: нейронка сможет внушительное количество раз полностью переписывать код на основании замечаний автора приложения.
Описывать алгоритм структурировано придумал наверное Аристотель, а никакие не зумеры)
Тогда может на языке 1С писать? Он очень похож на псевдокод и сразу можно скомпилировать.
Промт все таки значительно короче, чем программный код (если конечно не считать копипаста из документации), таким образом ты меньше печатаешь
Твоя писанина будет понятна не только тем, кто знает какой-то конкретный язык программирования.
С помощью нейронок этот промт можно перевести на много разных языков программирования, не зная их.
Нет, ваши программисты на словесных языках программирования никогда не заменят программиста на языке ассемблера.
Обучать нейронку через задания соискателям - это невероятно долгий и дорогой способ.
Вероятно что-то другое пошло не так.
Не очень она русский код понимает
https://zest-joggers-ebf.notion.site/a45216774a9741899cba3f2b380b77fd
У вас примеры таблиц в 6НФ на самом деле не в ней, так как в поле "Время" не соблюдается правила атомарности, применяемое к первой нормальной форме.
Перепробовал около 10-и автоматических систем по проверке орфографии. Ни одна не смогла поправить опечатку в слове "Была" (верно "Было") в тексте ниже.
Уважаемые коллеги!
Была получено письмо, подтверждающее тот факт, что отчет...
А как открыть "ресурсы" готовой игры, чтобы, например, перевести в ней тексты на русский?
Рекомендую от расчетов на доске перейти к расчетам в Maple
Немного обидно, что методы PATCH были обделены вниманием автора.
Реекспорт с физическим увеличением пути товара можно не делать.
Достаточно сформировать цепочку документов, показывающую реекспорт.
Лучше бы Sony наладила производство PlayStation 5 до той степени, чтобы консоли появились в магазинах.
Предположим цена у консервы из примера и правда поменялась из-за инвентаризации.
Произошло событие изменения цены, товары очутились в моей балансовой системе.
Я же не переносил остатки. Они сами перенеслись из-за того, что я ловлю события, выявляю положения товара, которое следует из события и сравниваю его с предыдущим.
Таким образом вам не нужно переносить остатки при внедрении такового сервиса.
Как очень подробно описано в статье, ничего не делаем.
С момента начала использования "новой" системы, мы относительно быстро доставим товар получателю или вернем продавцу или констатируем что он потерялся.
Таким образом сравнительно быстро товара у нас не станет физически, и его отсутствие у нас физически будет равно отсутствию его на балансе.
Правильно, но в случае, если у вашего объекта учета очень длинный жизненный цикл, можно придумать новое событие, которое может посавить ваш объект на баланс.
Например, в том случае, если в продуктовом консерва лежала до запуска сервиса, и еще долго будет лежать, можно поймать момент, когда у нее меняется цена (в больших сетях цены меняются приблизительно раз в неделю).
Учитывая систему "Подумай дважды", можно узнать текущее состояние на балансе Ozon, без суммирования со старой системой. Нужно лишь подождать пока новый сервис немного поработает.
По "Текущим состоянием" понимается количество товаров в Ozon на данный момент.
А где вы увидили их перенос?
В конце объясняется почему при данном подходе к разработке их можно не переносить.