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

Не нужно делать бложик на микросервисах, что для учебных целей, что для боевых.
Всё что вы описали о бложике - комменты, юзеры, посты - это всё достаточно сильно связанные данные, и их нет смысла обрабатывать в разных сервисах. В том решении, что вы предложили всё будет отлично, если заменить "микросервис" на "контроллер" (который из MVC), будет классическое решение учебной задачи.

Нужно придумать задачу, где сервисы будут более независимы друг от друга. Тогда и не будете мучаться чтобы понять, как сделать сервисы более автономными. В идеале любой сервис может продолжить свою работу, и реализовывать все или часть своих функций, если другие сервисы лежат. Хорошо например, если между сервисами А и Б взаимодействие реализовано через очередь сообщений - тогда упавший сервис Б после поднятия разгребёт эту очередь и выполнит всё то, что успел попросить у него сервис А пока Б лежал.

Об аутентификации можно тоже говорить много и долго, обычно чтобы жить некоторое время без сервиса аутентификации её делают по токенам (JWT например). Тогда целевой сервис сам может проверить, авторизован человек или нет.

Если уж так хочется бложик, то я бы оставил его в покое в виде самостоятельного сервиса, а в качестве других сервисов сделал бы:
- уведомления о новых комментариях/постах в мессенджер/почту (как раз хорошо будет через MQ общаться с основным сервисом);
- какую-нибудь аналитику элементарную, которая независимо собирается, например по посетителям, телеметрию короче;
- сервис автопостов - заказываешь пост с нужным содержимым на указанную дату и время, этот сервис пользуется API основного сервиса бложика и постит что-либо без вашего участия.

Вот уже что-то будет интересное. Обратите внимание, что пожалуй все из этих трёх сервисов могут работать без основного, и наоборот - основной сервис может класть сообщения в очередь для других сервисов (1-го и 2-го), и сервисы будут разгребать эту очередь пока работают.

В установщике 2017-й Студии в Individual Components установите "Windows Universal C Runtime".

Как посчитать координаты для дерева?

std::vector<std::vector<int>> vector_of_vectors;
vector_of_vectors.push_back({ 1,1,1,1,1 });
std::cout << vector_of_vectors << std::endl; // [[1,1,1,1,1]]
vector_of_vectors.push_back({ 1,1,1,1,2 });
std::cout << vector_of_vectors << std::endl; // [[1,1,1,1,1],[1,1,1,1,2]]

https://ideone.com/GIV9dW

Разработчики объясняют это тем, что они используют TypeScript, и он находится в папке src, поэтому вот так все собирается

Логично, нормальное решение.

Не нравится идея копировать dist и все вложенные папки

А в чём проблема? В dist не должно быть лишнего хлама, .git и прочего добра, по сути это готовая сборка приложения для деплоя, почему бы её не скопировать?

Не рекомендуют запускать npm install заново на сервере, так как по их мнению могут подтянуться совсем другие версии

А нехрен позволять npm-у ставить нефриженную версию в package.json. Нам вот уже настохорошело что проект ломается сам по себе из-за выхода новых версий библиотек, и мы зафризили все пакеты. Это нормальная ситуация, если у вас не библиотека, а конечное приложение. package-lock.json пытались использовать, но потом отказались - в версиях NPM 5.0-5.2 он работал отвратительно, сейчас уже может получше, не знаю.

Ваш getNode будет работать некорректно, т.к. каждый раз будет перезаписываться в прототипе при создании нового объекта. Т.е. при вызове getNode для любого объекта Timer всегда будет извлекаться значение одной и той же переменной - захваченной при последнем создании объекта.

Более правильная реализация:
https://developer.mozilla.org/en-US/docs/Web/JavaS... , Emulating private methods with closures

проблема у такого подхода - всё это делается ценой рантайма - на каждый объект будут свои инстансы методов. Хотите нормальную инкапсуляцию? Берите TypeScript.

проверка "правильности/соответсвия" возвращаемых данных определенными функциями

Это есть модульное тестирование, см. Catch.

проверка на используемую память(сколько используется, было использованно за весь цикл существования приложения)

Погуглите "memory profiler" (например, valgrind.org/docs/manual/ms-manual.html ). Я обычно в Студии профайлю, с автоматизацией этого процесса пока не сталкивался, но думаю возможно.

проверка правильности порядка записи в бд

проверка того что в сеть уходят данные которые ожидаются от программы

Тут вам нужно замокать клиента к бд и сетевой сокет/поток (в зависимости от того как это всё реализовано, без подробностей сложно советовать), и вместо реальной отправки данных/записи в базу делать нужные вам проверки.

Нет, прежде всего потому что дженерики в шарпе - это не шаблоны, и работают они не на уровне AST, как в плюсах.

Вы не можете вызвать "функции одного потока в другом". Каждый поток должен сам вызвать то, что ему нужно.

Чтобы это реализовать, вы можете, к примеру, организовать циклы обработки сообщений и обмениваться сообщениями между потоками.

Более конкретно ответить можно только зная какими библиотеками и API вы пользуетесь в вашем проекте.

У вас стоит тэг Windows - поэтому конечно RDP, о чём тут можно говорить-то. Зачем вообще в локальной сети задумываться о TeamViewer и аналогах. Этот TeamViewer я смотрю хорошо заходит - все уже и забывают про "родные" протоколы.

А разве в вашей таблице "Личности фильма" первичный ключ не появляется естественным образом? Зачем ещё нужен суррогатный?

Допустим есть команда профессиональных, финансово-неограниченных, C/C++ программистов, которые предпочитают писать на C++, но были вынуждены выбрать язык C для решения следующих задач....что это за задачи и почему?

1. Низкоуровневые задачи, где нужно иметь минимум абстракции от оборудования. Я лично хоть и не разделяю анти-C++ настроений Линуса, вполне согласен с тем что ядру полезно быть написанным на Си. В C++ есть довольно много абстракций, влияющих на исполнение кода, есть некоторые вещи "под капотом", которые могут быть недопустимы в низкоуровенвом коде.

2. Большие проекты, где сложно форсировать code-style. С++ - это такой язык... Он настолько разнообразен, что прежде чем некая команда сядет писать код, она должна выбрать некоторое ПОДМНОЖЕСТВО языка, и использовать его. Иными словами, Плюсы - это большой ящик с инструментами, и вовсе не обязательно (даже вредно) использовать сразу все. Важно отказываться от каких-либо возможностей или практик, особенно устаревших (а таких в C++ немало, "идиоматический" код на C++03 и C++17 - очень разный). Кто не хочет со всем этим заморачиваться (вспомним опять таки Линух - огромный проект с огромным числом участников) - вполне могут выбрать Си. Ведь можно считать, что выбор языка Си - это выбор только необходимого инструментария из того что предлагается в C++ (только помните что сейчас это всё-таки разные языки).

3. Программирование в сильных ресурсных ограничениях. Например под микроконтроллеры. Хоть в С++ программист "не платит за то чем не пользуется", иногда стандартные реализации различных механизмов недопустимо тяжелы или неэффективны. Например, если у вас очень медленный чип или мало памяти, возможно вы заходите свою собственную реализацию полиморфизма. Какой тогда смысл говорить что вы пишете на C++, если не сможете использовать его механизмы и то, что предлагает компилятор.

Вместо searchWindow.searchType.employByRoom
нужно Search.searchType.employByRoom

И дайте уже всем нормальные имена.