Adamos

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

По делу без брюзжания:
Писать под винду моветон - лицензии дорогие
Вин формс зачем? - делайте веб апи с фронтом на вью/реакте/ангуляре. Нужна кроссплатформенность, чтобы хоть с телефона можно было зайти и нажать нужную кнопку в системе.
Апи нужно, потому что будет много интеграций с другими системами, загрузка/выгрузка в 1с, не дай бог будете телефонию подключать
Внутренняя сеть решается с помощью впн сервера.
Помимо функциональных требований существуют еще технические, должен быть мониторинг, вы должны всегда знать сколько ресурсов потребляет ваш сервер, сколько данных занимает на дисках, логи и трейсы - гуглится по слову Observability, обычно не закладывается в смету, но к этим вопросам приходят рано или поздно
Что еще, ну, по функционалу тут проще, открываете презентации в популярных CRMках, смотрите, что они могут, выписываете списком и идете к заказчику, чтобы он указал галочками, что будете делать, что не будете
потом прикидываете по трудозатратам и озвучиваете сроки из которых можно понять примерную стоимость проекта. Часто одно маленькое предложение, типа того же "выгрузить данные в 1с" грозит несколькими десяткми часов работы, потому что другой отдел, с ними нужно договориться и сделать интеграцию. Или "должен быть отчет такой-то", а там как начнешь разбираться, еще 5 раз посовещаться сначала надо ))

Ок, исходя из того что это виртуалбокс и ip он получает видимо из своей отдельной NAT подсетки. Варианта реализации 2:
Первый пробросить еще один интерфейс как бридж и разрешить ему форвардить пакеты из сети 10.0.2.0 в вашу подсеть, после чего прописать маршруты на обеих(двоих?) сторонах и пробовать снова.
Второй просто удалить стандартный NAT интерфейс в virtualbox и добавить вместо него bridge чтоб ловил адрес в вашей сети. После чего перенастроить nginx и апач на новый ip полученый из вашей сети.
Есть третий, но это еще больший костыль чем первый вариант: поднять впн и пушить вашу машину по нему.

Получается, магическим образом, самопроизвольно, между включениями VulkanTexture.h и VulkanglTFModel.h был объявлен define.

А на самом деле где этот define определяется и как это место относится ко всем этим заголовочным файлам?

Разве препроцессор не последователен и может включать файлы в том порядке, в каком ему заблагорассудится, а не как я написал?

Нет, не может, но возможно ты не вполне понимаешь сам, в каком порядке ты написал их подключение. Так, например, Helpers/VulkanTexture.h и VulkanTexture.h -- это один и тот же файл, или разные? Если один и тот же, то из-за #pragma once в нём он не подключается в VulkanglTFModel.h, а если разные -- то подключается.

Понять, что фактичиски куда подключается можно выполнив вместо шага компиляции только препроцессирование (например, для gcc заменив в команде компиляции ключ -c на -E). В выводе препроцессора не видно дефайнов, но видно когда подключается тот или иной файл и видно весь исходный код не относящийся к препроцессору.

В чистом ФП будет примерно так:

releaseSocket(releaseConnection(releaseRouter(json(get('/users',prepareRequest(createRouter(routerParams,connect(createSocket('TCP'),ip, port)))),users))))

Некоторые приёмы использовать стоит, но не самая лучшая идея - писать в функциональном стиле такие программы.

Никак.
Лицензия получается XOR'ом ключа с вычисляемой (на самом деле, фиксированной) гаммой.
Зная только часть лицензии можно получить только соответствующую часть ключа.
Если знать все части лицензии, то достаточно записать их через '|', проXORить с вычисленной гамой и закодировать в BASE64.

jquery
native js

Правила сервиса

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

Видео нужно тогда, когда ты прочёл книгу, вроде всё понял, но куда тыкать пока не понял. В видео можно посмотреть чисто практические приемы работы с IDE, с консолью, с системой. То, что слабо отражено в книгах. Чтоб не тыкаться как кутёнок в незнакомый интерфейс.
А собственно язык лучше по хорошей книге и затем кодить, кодить, читать исходники других проектов, вникать, дебажить.

Самое главное - понять, что язык программирования - это как лопата у агронома. Лопатой надо владеть? Надо. Достаточно ли агроному лопаты? Нет. Ему надо знать и уметь много чего - сорта, почвы, технологии, химию, а лопатой он делает только некоторую часть операций.
Программисту надо знать в той или иной степени информатику, алгоритмы, структуры данных, языки программирования, базовые библиотеки, БД и СУБД, API, ООП, фреймворки, сети, протоколы, ИБ, тестирование (в части, касающейся программеров), да много чего. Язык там не на первом месте.

Видосиками это не изучишь, как ни старайся.

Из более-менее полезного видео поищи «алгоритмы и структуры на Python» от МФТИ, там десятка полтора лекций Хирьянова. Но это лучше после книги «Изучаем Python» М.Лутца.