Станислав Макаров

Почему при использовании переменной в методе, выдает ошибку

class Test
{
  static std::string question;

Потому что статическое поле класса нужно определить, его упоминание в определении класса -- это не определение. Определить его можно например так в .cpp вне всех функций:
std::string Test::question;

View - это не всегда то, что видит пользователь.
Под View также вполне подпадает json-объект, который возвращает контроллер в случае апишки.

Или для чистого API есть более подходящие архитектуры?

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

PS: Не нужно придумывать красивое название для архитектуры, чтобы писать нормально.

А так вообще для вдохновения посмотри на:
- Hexagonal architecture
- Onion architecture
- Clean architecture
- Ports and adapters
- N-tier architecture
- Vertical slice architecture

C C# 11 ты можешь использовать ключевое слово required.

public interface ICultureNode
{
        public string Ru_RU { get; init; }
        public string En_US { get; init; }
}
public class SimpleCultureNode : ICultureNode 
{
        public required string Ru_RU {get; init;}
        public required string En_US {get;init;}
}

Если забудешь инициализировать, то получишь ошибку компиляции CS9035

Ещё вариант - использовать конструкторы. Ведь они давно на то и существуют, чтобы обязывать тебя инициализировать всё.

Есть несоклько системных АПИ.

Например, DirectShow или MediaFoundation.

MediaFoundation поновее, побыстрее, поэффективнее и чуть поудобнее. Но криворукие разработчики драйверов его не всегда хорошо поддерживают. Всякие, особенно интегированные в лаптопах, камеры с ним глючат или не работают вообще. Плюс всякие виртуальные камеры, типа OBS не видны через MediaFoundation, потому что разработчикам влом по-нормальному реализовывать виртуальную камеру. Ну и оно только с windows 7 доступно.

Если вы не планируете открывать камеру, а вам надо только информацию о ней собрать, или вы работаете с определенным устройством, то MediaFoundation вам подойдет лучше.

Иначе смотрите DirectShow.

Можно найти много примеров кода в интернете.

return 0;
    menu_for(v);

Казалось бы, что могло бы пойти не так, попробуйте поменять местами return и menu_for

git - это система контроля версий.
Это не "локальное хранилище" и не нечто, что можно "приделать" сбоку.

Предположу, что под словом "приделать" вы имеете в виду использование git для доставки обновлений на продуктивный сервер.
Моё мнение - так делать не стоит.
Серверу совершенно не нужно хранить у себя всю историю версий.

А вот локально да - лучше вести разработку в git.
Ещё по хорошему следует хранить копию репозитория на каком-нибудь ещё сервере, например в собственном экземпляре gitlab и синхронизировать её с локальной при помощи git pull/push.

Ну и помни, что не надо все файлы в git запихивать. В git должны храниться только исходные файлы. Всякие картинки - в git-lfs.
Пароли - в каком-то другом хранилище.
Артефакты, которые создаёт компилятор или препроцессор - в .gitignore

Но когда доходит дело до пароля Я просто не могу туда ничего вводить не цифры не русские буквы не английские

Это нормально. Ты на самом деле вводишь пароль, но чтобы со стороны нельзя было сказать даже какой длины у тебя пароль - ничего в консоль не выводится.
Но вроде как в GH так аутентифицироваться нельзя - должно работать окошко с oauth.

Для надёжности советую настроить SSH-ключи, чтобы не тратить время на http-аутентификацию

После нажатия «Войти через браузер» должен открыться собственно браузер со страницей гитхаба, где вы должны нажать кнопочку «Разрешить».
Если вы не разрешили или что-то пошло не так, то только тогда вылезет предложение ввести пароль в терминале. Но там вместо пароля нужно вводить не ваш гитхабовский пароль, а текст токена, который вы должны были заранее создать. Токен вам покажут только один раз, поэтому скопируйте его в буфер и сохраните где-нибудь.
И вставляйте его в терминале тоже через буфер обмена, чтобы не ошибиться. При вводе паролей с терминале их никогда не видно, не пугайтесь и просто жмите Enter после ввода.

Есть опция PublishSingleFile - как раз склеит DLL и exe.

self-contained можно отключить

dotnet publish -c Release -r win-x64 -o ./pub -p:PublishSingleFile=true --self-contained false

Да, всё верно поняли. Дизайнер XAML не совсем "дружит" с кодом - он ищет только те, которые уже скомпилированы. Видимо, дизайнер ищет классы стандартным способом - через тип Type (и т.п.), а тот ищет среди сборок (exe/dll) проекта.

Нужно сразу скомпилировать новый тип, даже просто пустой class Test {} - и всё, будет работать. Лучше делать это пораньше - до того, как пытаетесь связать его в xaml, иначе билд не срабатывает, и приходится выпиливать его из xaml-а.

Реализуй вот это
Задача
Доработка сканера серийных номеров с этикеток.
Цель: доработать существующий сканер этикеток.
1. Система должна давать возможность нахождения и распознавания серийного номера независимо от иного текста, цвета фона, кол-ва символов S/N.
2.Скорость - не менее 1,5 сек на объект
3.Точность распознавания - не менее 96%
4. Динамический выбор области сканирования с помощью татч-скрина
5. Системные требования IOS, Android.

Это конечно перебор для вас в области 4,5
Но просто сделай на основе фото.
Как заготовку сможешь использовать это, баркоды пакеты
ZXing.Net
ZXing.Net.Bindings.CoreCompat.System.Drawing

Серийный номер Tesseract

https://github.com/vkorotenko/VueRecaptcha

Прокидывай секреты через переменные среды. Благо по умолчанию IConfiguration умеет работать со слоёными конфигами, где по порядку применяются следующие слои:
1. appsettings.json
2. appsettings.Environment.json
3. переменные среды
4. аргументы командной строки

Соответственно никакие трансформации не нужны - можно спокойно пушить конфиг в репозиторий, заменяя секреты какими-нибудь заглушками (например мы туда кладём строки, которые похожи на тот секрет, который должен быть)

Локально (на машине разработчика) переменные среды можно хранить в .env файлах, либо можно продолжать иметь дополнительные appsettings - это тоже ок.

При разворачивании образа, повторюсь, прокидывай секреты в переменные среды.

Так делают почти все, и все оркестраторы умеют с этим работать и прокидывать в переменные среды контейнера значения из каких-нибудь файлов или даже из хранилища секретов типа vault.

Push отправляет во внешний репозиторий origin ваши новые коммиты, которых там ещё нет. А указатель ветки origin/master просто передвинется на новую вершину цепочки коммитов (fast-forward). Никакого коммита слияния при этом не создаётся и конфликтам возникнуть в принципе неоткуда.
Кто с кем должен конфликтовать по вашему мнению?

Если тебе нужна библиотека классов, в которой есть только метод, который вычисляет площадь треугольника, то лучше сделать статический класс со статическим методом:

public static Triangle {
  public static double CalculateArea(double length0, double length1, double length2) {
    // Весь код по вычислению площади
  }
}

Функция Print тебе в библиотеке совершенно не нужна.

Сегодня существует ровно два базовых направления разработки конкретного коммерческого проекта.
Способ первый: купить лицензию или подписку на уже готовый инструмент разработки и заняться непосредственно разработкой своей игры.
Способ второй: иметь в своем штате команду разработчиков собственного инструмента, на базе которого можно заняться разработкой своей игры.

Первый способ популяризирует публичные универсальные инструменты разработки.
Второй способ эксплуатирует проприетарные инструменты.

Первый способ отдает разработку и поддержку движка на аутсорс непосредственно разработчикам инструмента, часто за отдельную плату, часто сопровождаясь или длительным ожиданием, или отсутствием гарантий внедрения требуемых решений.
Второй способ позволяет быть на короткой руке непосредственно с разработчиками инструмента, но требует от разработчиков экспертности знаний в требуемых для разработки областях. С одной стороны таких людей очень сложно найти, с другой стороны таким людям надо очень много платить.

DirectX, Vulkan и OpenGL, равно как Metal и ряд проприетарных GAPI некоторых закрытых платформ, не являются графическими библиотеками. Это все - Graphics Application Programming Interface - GAPI.
Это - низкоуровневые интерфейсы драйвера GPU, позволяющие эксплуатировать ресурсы видеокарты в своих целях. Не только для рисования чего-то, а для ИИ, ML, сложных статистических вычислений, предсказаний и прочих расчетов на больших объемах данных.
Под капотом любого инструмента, будь-то проприетарный или публичный, в его графическом слое используется один или несколько GAPI. Без этого никак.
OpenGL, как и DirectX 11, нисколько не устарели, поскольку предоставляют упрощенный интерфейс управления ресурсами GPU. Они используются тогда, когда разработчикам не нужны самые тонкие механизмы управления ресурсами GPU, которые предоставляют DirectX 12 или Vulkan. Потому что последние, помимо прочего, требуют от разработчиков более глубокой экспертизы и больше ресурсов на разработку всего того же, что на OpenGL и DirectX 11 реализуется меньшими силами и за меньшее время.

И нет, одним только инструментом, на базе которого ведется разработка игрового проекта, не обойтись. Все ресурсы разрабатываются в других инструментах: графических редакторах, звуковых редакторах, редакторах анимаций, редакторах баз данных. Пайплайны производства ресурсов являются очень сложными, могут насчитывать десятки инструментов для производства одного только типа ресурсов и требуют от артистов экспертизы в использовании этих инструментов. И часть таких инструментов обязательно будет проприетарными, созданными или под конкретный проект, или внутри конкретной компании. И иногда такие инструменты удобнее создавать с применением других, более мелких или лучше заточенных под задачу, движков. Игровой движок не всегда используется для создания игр.
Отдельно стоит в этом вопросе код игровой логики и шейдеров. Для этого тоже нужны специалисты и инструменты.

Информации по каждой отдельной области разработки игр хоть отбавляй. Ее настолько много, что одному человеку за жизнь не усвоить. Поэтому от современного специалиста сегодня требуется спрофилироваться, т.е. определиться со своим профилем работы и стать экспертом.
Я больше 15 лет занимаюсь разработкой игровых движков и медиаферймворков. Более 10 лет занимаюсь коммерческой разработкой кросслпатформенных инструментов. Я начинал свое обучение по книгам и документации для всех интересующих меня областей еще 20 лет назад. Я самостоятельно освоил множество API, включая графические, сетевые, звуковые и API целевых платформ, используя книги и документацию. Экспертные знания C++ и прочих языков я получил тоже через изучение документации, стандартов и книг.
Я могу сказать что обучаться по книгам и документации можно и самостоятельно. Еще можно заплатить деньги и получить более точечные знания через их интерпретацию на распространенных сегодня онлайн-курсах. Такие знания не всегда бывают лучше полученных самостоятельно, но времени на освоение того же объема знаний на курсах уйдет меньше чем при самостоятельном изучении. Иными словами, занятия на онлайн-курсах не отменяют важности самостоятельного изучения основных источников информации.
По открытым видеоурокам на ютубе и прочих видеохостингах обучаться нечему. Цель этих видео - чтобы зритель посмотрел рекламу и этим принес доход автору.