mayton2019

Напоминает игру "Сапер".

Возможно в WinForms не эффективно реализован поиск компонентов по имени
Controls.Find("checkBox" + i, true)
Да и вообще 256 элементов - для рантайма тяжело. Наверное они слишком громоздкие
и интеллектуальные чтоб делать из них сетку объектов. Тоесть это не те WindowsGDI объекты.
Это дотнетовские объексты со своей обвязкой. С очередями сообщений и прочее.

Попробуй создать Graphics и на нем нарисовать сетку чек-боксиков. Как сапере.
И мышко-клик обрабатывай. Я думаю это решит проблему.

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

Путей много. Можно завести 2 таблички. Одна для новых машин. Другая - для подержанных. Со
своими наборами пропертей. Тогда и индексы строить удобно.
И с точки зрения типизации этот подход верный. Если язык разработки (Python/PHP) различает
типы машин - то для каждого типа нужна отдельная табличка. Это в духе ORM.
Недостаток - надо делать union all двух таблиц если мы хотим делать поиск по общим пропертям.

Можно завести 1 табличку с полем типа JSON и свалить туда все проперти которые могут быть
опциональны для новых машин и для Б/У. Это делает схему более компактной. И поиск по основным
полям работает универсально. Для кастомных полей надо искать описание в MySQL языков работающих
с JSON (JSonPath) для того чтоб выбирать и фильтровать и индексировать их.

Можно поступить как в BigData. Свалить все проперти что есть в одну большую таблицу. Будет в ней
допустим 500 колонок. И большая часть из них - пустая. Заполняется null. Такая модель тоже работоспособна.
Но для человека наблюдающего глазами таблицу будет неудобно с ней работать. Особенно когда нужное
тебе поле находится где-то на 400х колонках и надо скроллить грид мышкой вправо чтоб хотя-бы прочитать
глазами значения. И эволюция такой схемы проходит тяжелее. Т.к. alter table обычно блокирует таблицу
от транзакций DML и нужен регламент что добавлять новую колонку.

Если отбросить англоицизмы, то на нормальном языке роадмап - это план обучения.
Планы обычно пишут преподаватели.

Нам здесь в хабре трудно оценить их эффективность. Это - примерно тоже самое
что оценивать программу обучения ВУЗа.

С моей субъективной точки зрения план - хороший. Если-бы я решил что он плохой
то мне надо было-бы срочно предложить свой собственный план. У меня такого нет.

А учитывая что ты плаваешь в понимании нужности Django и сокетов - то ты тем более
не в состоянии даже критиковать этот план. Поэтому бери его. Учи. И скажи спасибо
что хотя-бы такое есть.

Он скорее всего работает. Просто консоль так быстро появляетя и исчезает что ты не успеваешь разглядеть.
Там сразу после печати Hello идет return.

Добавь туда cin >> для того чтоб было какое-то ожидание от пользователя.

Надо сменить тип данных с TEXT на NUMBER. Тогда суммирование будет точнее. По крайней мере я проверил вот так.

sqlite> create table test(n number(2,3))
   ...> ;
sqlite> insert into test values(16.30);
sqlite>
sqlite> select typeof(n) from test;
real
sqlite>
sqlite> insert into test values(19.11);
sqlite>
sqlite> select total(n) from test;
35.41
sqlite> select sum(n) from test;
35.41

С точки зрения Java language, аннотации ничего не делают. Они - как каменты в коде. Но они могут быть подсказками для фреймворков которые в compile time, classloader или runtime могут что-то выполнить над кодом. 99%
это какие-то ORM/JSon подказки которые разъясняют фреймворку что делать. Например @Table(name="emp")
подсказка JPA то класс относится к таблице emp.

Ваш вопрос про либы Java/Kotlin слишком общий. Ничего конкретного нельзя сказать. Но по отношению к
Serializable, можно предположить что это гарантия что класс можно сериализовать во внешнюю память
(оперативная или диск) и это не нарушит никакой бизнес логики. Например это DTO которая полностью
самодостаточная. Не все сущности вообще реально сохранить. Некоторые сущности - как орграф опутывают
всю память Java и сохранять их накладно. Как корневой объект хипа. Дешевле дампнуть всю память чем
сохранять такие объекты поштучно. Некоторые - имеют связи с внешними ресурсами Files/Sockets и вне контекста они не имеют смысла. Есть ключевые слова языка (transient) которые запрещают сериализацию для полей.
Есть также проблема версионности для Serializable. Сохраненная структура не трекает ваши изменения
по коду уже после того как вы что-то сохранили. Грубо говоря это не JSON. Если вставили новое поле - можете
старый файл и не прочитать. В качестве маркера проблемы там заводят специальное поле типа versionId или
что-то такое. Просто для детектирования.

Если вы хотите иметь тотальный контроль над сохранением - то определяйте Externalizable и там будут 2
метода в которых вы контролируете Output/Input streams и сами пишете что сохранять и читать. А еще
лучше брать библиотеки Kryo/Protobuf/Avro e.t.c. У них еще и есть оптимизации по скорости и по сжатию.
Вы к этому придете эволюционным путем если будете писать систему где сохранение во вне - важно.

Сериализация во внешнюю память это огромная проблема когда мы пытаемся подружить разные
технологии (32-64 бит целые числа или разный порядок байт в машинном слове). Даже простое
сохранение даты или строки может быть ошибочным если вы сохранили в Java а пытаетесь читать в C++.
Нужна 100% бинарная совместимость всех структур. Вот библиотеки Протобуф и Авро
как раз для этого создавались.