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