Александр Ананьев

Одновременно и просто и сложно, зависит от "глубины погружения в тему"
Для различных авто немного по разному, но принцип один и тот же, по ОБД данные доступны через запросы к соответствующему модулю (MRM,ABS,ESP ....) (думаю для разных машин по разному и с различной точностью, количеством инфо) скорость поворота руля и угол поворота (если память не изменяет с точностью до десятых долей) скорость вращения каждого колеса тоже с точностью до десятой доли км/ч. Но тут встает момент, что некоторые модули ABS при таких запросах становится в диагностический режим а свыше 30-50 км/ч выходят из него и перестают отвечать на подобные запросы. Но это не отменяет возможности подслушивать эти сообщения по CAN, например в приборку прилетает постоянно скорость. Но и тут от модели авто зависит, где-то это просто скорость, а где-то 4 значения по каждому колесу.
И 2й вариант подслушивать эти сообщения на шине, когда блоки общаются между собой. И опять ньюанс, на разных машинах по разному, но например высокоскоростная шина моторного (мотор коробка абс) не флудит этим трафиком в ОБД, а на некоторых машинах наоборот все слышно по ОБД
По частоте запросов точно не скажу, тоже вариативно, но минимум 1-2 запроса в секунду должно проходить, если запрашивать у блока, а если подслушивать, тот тут все от блока зависит. Вы же понимаете, что для своих целей внутри ABS получает данные напрямую с датчика, и в состоянии определить пропущенный сегмент на задающем диске а частота опроса в милисекндундах.

Никак. Выбор инструмента - это задача тимлида и/или техлида. Т.е. ведущего/главного разработчика, отвечающего за принятие ключевых технических решений. Ваша задача, как заказчика, четко оформить требования, ограничения и сформировать начальное ТЗ и описание, что вам требуется от проекта, прототипы интерфейса, например. Без вникания в технические детали. Т.е., "хочу чтобы были фичи такие-то и работил они так-то, ограничения такие-то, требования такие-то". Далее уже задача найти разработчика/команду с большим или достаточным для данного проекта опытом. Далее из начального ТЗ формируется полноценное техническое задание: описывается весь требуемый функционал, рисуется дизайн, прописываются требования, ограничения и прочие хотелки. И на основе ТЗ, тим/тех лид уже подбирает/подбирают наиболее оптимальные и конкретные инструменты и решения, основываясь на собственном опыте и знаниях для конкретно этой задачи. Например, если человек хорошо знает несколько разных инструментов и есть достаточный опыт их использования - он может реализовать проект используя любой из них как одинаково хорошо, так и одинаково плохо. У разных ЯП и фреймворков свои плюсы и минусы. Далее из ТЗ формируется более детальное ЧТЗ и происходит разработка проекта.

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

Вот с этим проще: использовать популярные OpenSource решения, регулярно проводить тесты, нанять отдельно опытного разработчика, красноглазика и пентестера - и тратить на них деньги, пока деньги не кончатся или не будет достигнут необходимый уровень безопасности. Безопасность противоположна удобству, защита отстает на шаг от атак. Риск есть всегда и надо просто быть готовым к последствиям и иметь запасной плат хотя бы в общих чертах.

А так - уже правильно посоветовали сразу брать дот-нет, т.к. у вас требование к использованию конкретной библиотеки для дот-нета.

Это невозможно, либо отказаться от такой идеи, либо сделать окно вообще без границ и верхней панели (QtCore.Qt.FramelessWindowHint), и сделать свою верхнюю панель.

Нет, рекурсия работать не будет. Гит увидит, что внутри каталога лежит вложенный репозиторий и проигнорирует его. А в своей базе пометит этот подкаталог как поддерево (subtree), чтобы не сломать.

Вы пытаетесь соорудить какой-то жуткий костыль только лишь потому, что поленились изучить инструмент, в котором работаете. Поэтому для вас Git сейчас представляется как некая шайтан-машина, которой вы скармливаете команды, которые не понимаете, и в результате получаете ещё более непонятные «неожиданные результаты». Просто потратьте несколько дней, чтобы изучить азы. Не зубрите непонятные команды, а постарайтесь понять логику гита. А она — эта логика предельно проста и гениальна.

не является сложной задачей что-либо сломать в своем проекте

Сломать что-то в гите довольно сложно. Вам может только показаться что всё сломалось, но это лишь потому, что вы не понимаете, что делаете.

каким-то образом снес половину коммитов

Коммиты в гите — это неизменяемые сущности. Можно лишь создать новые «на замену», но старые не исчезают. Коммиты невозможно удалить без специальных команд очистки мусора.
Вам показалось что коммиты исчезли, но на самом деле они все остались в репозитории, вы просто их не видите в текущей ветке. Но всё легко откатывается назад, используя журнал Reflog.

Поэтому было бы неплохо как-либо сохранять прошлые версии Git репозитория

Reflog это и делает, по сути. Это журнал, который хранит указатели на все состояния проекта, в которых вы когда-либо находились ранее. И эти состояния сами по себе не исчезают, так что вы всегда можете откатиться назад в любое место.

Мой вам совет: Пройдите 16 коротких бесплатных уроков и полу́чите просветление.

Цифр больше 9 в десятичной системе не бывает.
А ваш код выдаёт числа от 1 до 10, как вы в нём и написали.

Быстро изучить просто.
Придумывайте любой проект и начинаете его делать.
И самое главное, вы должны делать это самостоятельно, без всяких тостеров.
Книги вам помогут любые где есть просто базовые знания, а вот всякие ютуб каналы особо не помогут, может только чуть разобраться в фреймворках, но всё равно документация рулит.
Если хотите создавать игры, то копайте движок Unity и его документацию.

Сам процесс простой.
1. Пишите как знаете проект, главное чтобы заработало как планируете, на сам код не обращайте особого внимания.
2. Начинаете переписывать проект с полученным опытом из 1 пункта с использование новых знаний из прочтения книг по всяким архитектурам и паттернам.
3. Повторяете в цикле первые 2 пункта до 11 класса каждый день тратя по 4 часа минимум.

Весь ваш прогресс заносите через git на гитхаб, пригодится, когда будете искать работу.