Можно быть скромнее и браться за менее амбициозные задачи :) Я не настаиваю на абсолюте, в бизнесе всегда приходится балансировать. Но вот так по-человечески, как творческой единице, лучше сначала придумать. Можно упростить немного. Не начинать задач с открытым финалом.
Так она сама по себе архитектурно так устроена, что все действия оформляются документами, которые при "проведении" меняют состояние регистров (остатки запасов, состояния и прочее). Сама платформа так устроена. Журнал документов это "event store", регистры это "query storage". Документы легко переносятся из системы управленческого учета, в систему бух. учета и при проведении там, формируют другую базу для запросов. Собственно она и используется и для логистики и для финансов и вообще для любого бизнеса.
В 7.7 версии был единый журнал для всех событий, что оказалось плохой идеей, так как транзакция записи одного документа, блокировала запись любых остальных.
Это само ничего не закрасит, это создаст для каждой точки список соседей такого же цвета. Далее вы начинаете из любой точки внутри области и обходите по этому графу все точки внутри этой области.
"Особенности национального ИТ" =)) Нужен сюжет с медведем, коровой и талантливыми доярками, смекающими про неверный алгоритм сортировки и утешающих тощего сирого аспиранта. Авось выживет, коли Бог даст.
Победили "скрипты", которые замечательно живут на неизменяемых готовых библиотеках классов. Сам процесс создания класса, должен заставить человека задуматься, что он творит и во что лезет. Это сотни-тысячи часов проектирования, реализации и тестирования, которые до него уже тысячи раз были потрачены.
И я очень надеюсь, что ChatGPT и т.п, наконец избавят человечество от этого обезьяньего труда, делать что-то только потому, что не можешь найти готовую реализацию.
Ну перестали же повсеместно писать свои ДОС и браузеры.
Призвать увеличивать связанность кода для облегчения поддержки ... Ну такое. Поэтому у вас и бывают задачи "перезаписать все функции", вы все не так проектируете.
В данном примере, для уменьшения связанности нужен интерфейс по сериализации и десериализации данных объекта, которые будут передавать в БД, микросервисы, разное.
В каждом слое объект выглядит не так, как в других. Это касается отображения, поведения, хранения и у каждого слоя несколько вариантов и сам он делится на еще несколько.
А так, отправили объект в очередь, оттуда он разлетелся в БД, сайт, прочим партнерам. И вот это уже можно не просто поддерживать, но и развивать и масштабировать.
И мы же позволяем его вызывать только классам произведенным от абстрактного экскаватора. Потому, что копают экскаваторы одинаково, а копается земля везде по-разному.
Каждый объект хранится в БД при этом поддерживается несколько СУБД. Но из всех прелестей ООП остается только инкапсуляция и околополиморфизм =). Т.е. нельзя изменить существующие абстракции никак, потому что нет наследования, как такового.
И управляется это все скриптовым языком.
Наверное можно найти аналогию с Питоном, который можно использовать как скрипт управления набором готовых неизменяемых классов.
Ну такой постООП. Мне кажется на текущий момент уже невозможно написать свой уникальный класс и даже набор абстракций. Берется готовый набор (фреймворк) и связывается процедурными языками, скриптами, разным.
"В этом контексте я точно буду использовать что-то вроде третьего примера, потому что первый пример слишком неоднозначен для требований нашего проекта."
Чет мне кажется, что в большинстве контор за такой метод сразу уволят.
Мне кажется ваша "депрессия" также отличается от настоящей, как боль в животе от воспаления аппендицита. На болезнь нельзя просто посмотреть по-другому.
Как мне кажется, у Вас довольно простая проблема - как получить новое, не бросая старое. Хочется резкого улучшения, без резких движений. Так не бывает. Может Вы просто инфантильны? Все надеетесь на волшебника в голубом вертолете или типа того? Застрял бизнес - продай и начни новый.
Я своего оффера, который, как мне кажется, справедлив, ждал несколько лет и все это время развивался. Потому что я человек в возрасте и единственное мое преимущество - опыт, который рождается в работе и обучении. Это не какая-то секретная дорога.
А при депрессии одинаково безразличен и успех и неудачи.
Вся штука в том, что изначально коэффициенты должны быть расставлены в точности, как сказано в задаче. Надо не напороть с генератором и надо не напорот с инициализацией. Нужен аккуратный и понятный код. И когда на питоне часть алгоритма выглядит вот так:
cost = -1 / m * (np.dot(Y, np.log(Y_hat).T) + np.dot(1 - Y, np.log(1 - Y_hat).T))
то поищи, где ошибся =) (мораль простая, нечего лезть в питон без опыта :) )
А вообще Codingame это в первую очередь соревнование. В итоге все упирается в MCTS, генетический алгоритм и т.п. Последний контест шел 20+ дней. Прототип решения на C# у меня 1000 строк, который я так и не довел до ума, а там довольно простенький генетический алгоритм + A*. По сути единственная проблема именно в том, чтобы не утонуть в грязном коде. Банальные магические константы могут на пол дня в аут отправить.
А на C++ там вообще страшно. Случайно вылез за границы массива (или просто использовал указатель в нитуда) и получаешь сообщение "Time out", иди ищи где что случилось. Здорово дисциплинирует.
Может я такого мнения, потому что в основном на codingame зависаю. А там хорошее решение обычно и хорошее приложение в полном смысле. От архитектуры в целом, до оптимизации частностей.
И потом, если у вас уровень высокий, то конечно вы можете писать код любого вида. А новичок на грязном коде далеко не уедет, закопается.
P.S. Олимпиады это хорошо, но многодневные контесты лучше.
Я не предлагаю делить N. Вы из Питера чтоль?
Можно быть скромнее и браться за менее амбициозные задачи :) Я не настаиваю на абсолюте, в бизнесе всегда приходится балансировать. Но вот так по-человечески, как творческой единице, лучше сначала придумать. Можно упростить немного. Не начинать задач с открытым финалом.
Не стоит приступать к реализации того, что не придумано до конца.
Сначала сделай как изначально придумал.
В проекте должна быть цифра N. Любая задача, предполагающая больше времени, чем N, должна быть разбита на подзадачи.
Собеседование позволяет просто проверить, что заявленное в резюме верно. Больше, чем из резюме, не узнаете.
Краткие ежедневные митинги по делу и профессионально - хорошее начало дня.
Так она сама по себе архитектурно так устроена, что все действия оформляются документами, которые при "проведении" меняют состояние регистров (остатки запасов, состояния и прочее). Сама платформа так устроена. Журнал документов это "event store", регистры это "query storage". Документы легко переносятся из системы управленческого учета, в систему бух. учета и при проведении там, формируют другую базу для запросов. Собственно она и используется и для логистики и для финансов и вообще для любого бизнеса.
В 7.7 версии был единый журнал для всех событий, что оказалось плохой идеей, так как транзакция записи одного документа, блокировала запись любых остальных.
Решений действительно мало, всё сожрала 1С.
Это само ничего не закрасит, это создаст для каждой точки список соседей такого же цвета. Далее вы начинаете из любой точки внутри области и обходите по этому графу все точки внутри этой области.
"Особенности национального ИТ" =)) Нужен сюжет с медведем, коровой и талантливыми доярками, смекающими про неверный алгоритм сортировки и утешающих тощего сирого аспиранта. Авось выживет, коли Бог даст.
Победили "скрипты", которые замечательно живут на неизменяемых готовых библиотеках классов. Сам процесс создания класса, должен заставить человека задуматься, что он творит и во что лезет. Это сотни-тысячи часов проектирования, реализации и тестирования, которые до него уже тысячи раз были потрачены.
И я очень надеюсь, что ChatGPT и т.п, наконец избавят человечество от этого обезьяньего труда, делать что-то только потому, что не можешь найти готовую реализацию.
Ну перестали же повсеместно писать свои ДОС и браузеры.
Да, невнимательно прочитал.
Но Вы настаиваете на тоталитарной и беспощадной связанности кода, а это путь прямиком в Ад.
В моем понимание все БЛ должны иметь общий интерфейс совместимый с общим интерфейсом БД и тогда с этим можно работать.
Призвать увеличивать связанность кода для облегчения поддержки ... Ну такое.
Поэтому у вас и бывают задачи "перезаписать все функции", вы все не так проектируете.
В данном примере, для уменьшения связанности нужен интерфейс по сериализации и десериализации данных объекта, которые будут передавать в БД, микросервисы, разное.
В каждом слое объект выглядит не так, как в других. Это касается отображения, поведения, хранения и у каждого слоя несколько вариантов и сам он делится на еще несколько.
А так, отправили объект в очередь, оттуда он разлетелся в БД, сайт, прочим партнерам. И вот это уже можно не просто поддерживать, но и развивать и масштабировать.
И мы же позволяем его вызывать только классам произведенным от абстрактного экскаватора. Потому, что копают экскаваторы одинаково, а копается земля везде по-разному.
Каждый объект хранится в БД при этом поддерживается несколько СУБД. Но из всех прелестей ООП остается только инкапсуляция и околополиморфизм =). Т.е. нельзя изменить существующие абстракции никак, потому что нет наследования, как такового.
И управляется это все скриптовым языком.
Наверное можно найти аналогию с Питоном, который можно использовать как скрипт управления набором готовых неизменяемых классов.
Ну такой постООП. Мне кажется на текущий момент уже невозможно написать свой уникальный класс и даже набор абстракций. Берется готовый набор (фреймворк) и связывается процедурными языками, скриптами, разным.
graph = {(y, x): [] for y in range(height) for x in range(width) if f[y,x]!=COLOR}
далее очевидно
Осталось пару шагов и придумаете 1С
"В этом контексте я точно буду использовать что-то вроде третьего примера, потому что первый пример слишком неоднозначен для требований нашего проекта."
Чет мне кажется, что в большинстве контор за такой метод сразу уволят.
По этой теме порекомендую вот такую статью
Let’s code a Neural Network in plain NumPy | by Piotr Skalski | Towards Data Science
Мне кажется ваша "депрессия" также отличается от настоящей, как боль в животе от воспаления аппендицита. На болезнь нельзя просто посмотреть по-другому.
Как мне кажется, у Вас довольно простая проблема - как получить новое, не бросая старое. Хочется резкого улучшения, без резких движений. Так не бывает. Может Вы просто инфантильны? Все надеетесь на волшебника в голубом вертолете или типа того? Застрял бизнес - продай и начни новый.
Я своего оффера, который, как мне кажется, справедлив, ждал несколько лет и все это время развивался. Потому что я человек в возрасте и единственное мое преимущество - опыт, который рождается в работе и обучении. Это не какая-то секретная дорога.
А при депрессии одинаково безразличен и успех и неудачи.
Для начала приведу в пример вот такую задачку
Coding Games and Programming Challenges to Code Better (codingame.com)
Вся штука в том, что изначально коэффициенты должны быть расставлены в точности, как сказано в задаче. Надо не напороть с генератором и надо не напорот с инициализацией. Нужен аккуратный и понятный код. И когда на питоне часть алгоритма выглядит вот так:
cost = -1 / m * (np.dot(Y, np.log(Y_hat).T) + np.dot(1 - Y, np.log(1 - Y_hat).T))
то поищи, где ошибся =) (мораль простая, нечего лезть в питон без опыта :) )
А вообще Codingame это в первую очередь соревнование. В итоге все упирается в MCTS, генетический алгоритм и т.п. Последний контест шел 20+ дней. Прототип решения на C# у меня 1000 строк, который я так и не довел до ума, а там довольно простенький генетический алгоритм + A*. По сути единственная проблема именно в том, чтобы не утонуть в грязном коде. Банальные магические константы могут на пол дня в аут отправить.
А на C++ там вообще страшно. Случайно вылез за границы массива (или просто использовал указатель в нитуда) и получаешь сообщение "Time out", иди ищи где что случилось. Здорово дисциплинирует.
Может я такого мнения, потому что в основном на codingame зависаю. А там хорошее решение обычно и хорошее приложение в полном смысле. От архитектуры в целом, до оптимизации частностей.
И потом, если у вас уровень высокий, то конечно вы можете писать код любого вида. А новичок на грязном коде далеко не уедет, закопается.
P.S. Олимпиады это хорошо, но многодневные контесты лучше.
Вы это чего, придумали N-значную систему счисления? =) Ну так и берите вес как n^i.