Илья Голец

Тут важный вопрос. Общие части системы можно редактировать, или нет?

Если нет — можно вынести их в отдельные репы, собирать из них nuget модули и публиковать в частном nuget репозитории.

Если нужно редактировать и хочется заморочиться, то можно сделать следующее:

1. Сделать репозитории для небольших подсистем
   
2. Для каждого проекта сделать по репозиторию, составить список подсистем, которые в нём используются и
   
3. В репозиторий проекта добавить подсистемы через https://git-scm.com/book/en/v2/Git-Tools-Submodules
   
4. Добавить код, уникальный для проекта в виде отдельных папок в репозитории проекта.
   
5. Постараться не запутаться во всём этом великолепии и не сломать друг другу работу.
   

Ещё есть вариант отказаться от монолита, удариться в микросервисы. Тогда каждый кусок проекта будет независимым и можно будет его вынести в отдельную репу. Но тут может быть много работы по распилу монолита.

1. Да, в iOs есть такая функция, но её можно отключить для своей сети WiFi. В свойствах сети можно снять галочку "Частный адрес WiFi".
2. У меня как минимум на двух маршрутизаторах после подключения макадрес не меняется и whitelist прекрасно работает и без отключения этой галки.
3. Из обходных решений — на iOs есть "Команды", там можно настроить автоматический макрос, который будет срабатывать при подключении к домашней WiFi сети, можно создать автоматизацию, которая будет что-то дергать в системе умного дома. Логика получится немного размазанной, но с высокой гарантией.

Полагаю, что на Андроид тоже должно что-то похожее быть.

Плагин whitelist пробовали?

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

1. На C# написать прикладное ПО, которое взаимодействует с пользователем/БД/(нужное дописать)
   
2. Через (например) USB/Serial port подключить плату с микроконтроллером
   
3. На микроконтроллере (у него частота известна) запустить программу, которая, манипулируя NOPами, обеспечивает необходимые задержки. Точность, очевидно, будет очень высокая — половина такта процессора микроконтроллера (с учетом погрешности тактового генератора)
   
4. Приложение на C# в нужные моменты посылает сигнал плате с микроконтроллером.
   

В этом случае будут неизбежные задержки отправки сигнала плате из приложения на C# (по причинам, указанным выше), но сама плата будет выдавать гарантированную частоту. Человек задержки на стороне C# не заметит, а оборудование, которому шлёт сигналы микроконтроллер, будет получать комфортную частоту сигнала.

Плату с микроконтроллером можно заменить на что-то, на чём запущена Realtime OS. Суть не сильно поменяется.

1. Хорошо бы иметь базовое образование — знать, что такое алгоритмы и структуры данных. Знание другого языка программирования подойдет.
   
2. На счёт книг — они по определению не бесплатны, кто-то вложил в них труд. Бесплатно — это либо читать документацию на сайте Microsoft, либо брать книгу у друзей/работодателя, или скачать украденное. Тут я рекламировать не буду, в принципе, для знакомства подойдет любая книга. Ещё есть ресурс https://docs.microsoft.com/ru-ru/learn/ (подробнее на https://habr.com/ru/company/microsoft/blog/426919/)
   
3. Дальше нужно определиться с направлением работы (для чего нужен C#). Это может быть десктоп программирование, или веб, Azure и т.д. Тут могут потребоваться более специфичная литература. Я бы порекомендовал зайти на сайт https://docs.microsoft.com/en-us/certifications/browse/, выбрать интересующие направления и поискать (хотя бы и украденные) книжки по выбранным экзаменам, или MS Learn. Я как-то через сертификацию проходил, её преимущество в том, что дается довольно целостный и полный объем знаний. В том числе придется освоить темы, которые обычно пропускаешь, но которые могут быть важны для профессиональной разработки. Например, вопросы безопасности.
   

На счёт «как эта область называется, и в какую сторону копать» — наиболее близкие по смыслу — это «Service oriented architecture» и «Event driven architecture». Подробно раскрывать не буду, почитайте на досуге.

Очереди сообщений (те самые MQ из RabbitMQ) тут как раз могут быть полезны и будут помогать с масштабированием. В идеале, чтобы избежать ненужных ожиданий, хорошо бы разрешить внешним серверам работать с очередями (как минимум, писать в них задачи на обработку).

Касательно масштабирования — не очень понятно, какую часть вы пытаетесь масштабировать. Мое предположение — скорее скрытые сервера, которые, как я понял, делают какую-то нагруженную обработку. При наличии очереди сообщений вы можете делать произвольное количество серверов, которые вынимают задачу из очереди, обрабатывают и помечают задание как выполненное. Более того, если разворачивать решение на облачной платформе (любой), можно создать метрику, которая анализирует длину этой очереди и при её росте автоматически запускает новые инстансы (сервера) в «скрытой» зоне. А при уменьшении очереди так же автоматически их тушит, чтобы не тратить деньги.

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

А если говорить о том, как делаются «промышленные» (не самопальные) системы такого рода, то тут будут следующие слои начиная от пользователя:

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

Веб-приложения могут добавляться в пул по метрикам загрузки процессора и времени ответа.
Сервера фоновой обработки могут добавляться в пул по метрикам длины очереди.

1. Deel
   
2. Тут, вроде, точка недавно опубликовала инфу, что они сделали промокашку для UpWork
   

Как я обычно с таким борюсь.

1. Сделать (или взять у поставщика XML данных) файл со схемой XSD

2. Из XSD сделать файл C# командами:

xsd SourceFormat.xsd /c /n:NameSpace /o:tmp
cd tmp
ren SourceFormat.cs     SourceFormat.designer.cs
move /y SourceFormat.designer.cs ..
cd ..
rd /s/q tmp

(кратко что тут происходит — создается .cs файл в каталоге tmp, чтобы при ошибках не затереть исходник, потом .cs переименовываем в .designer.cs и помещаем в основной каталог)

3. Оба файла (xsd и .designer.cs) можно добавить в проект, красиво отобразить второй как вложенный в первый

4. Использовать упомянутый XmlSerializer для записи

var serializer = new XmlSerializer ( typeof ( nmaprun ) );
                using ( var writer = new StreamWriter ( xmlFileName ) ) )
                {
                    serializer.Serialize ( writer, item );
                    writer.Close ();
                }

и для чтения

using ( var temp = new StringReader ( xmlText ) )
                    {
                        var tmp = serializer.Deserialize ( temp );
                        return ( nmaprun ) tmp;
                    }

Привет. По-хорошему, лучше сделать два проекта, запустить их в параллели и каким-то образом (через модный MessageBus, или каким-нибудь RESTful запросом) дергать второй процесс из первого.

Но если очень хочется влоб, то могу посоветовать разве что покопать вот эту штуку: https://docs.microsoft.com/ru-ru/dotnet/api/system...
Ещё важно будет учесть, что тут загружаемая ассембли грузится в домен приложения. Если в этом домене уже загружена та же ассембли другой версии могут быть накладки. Поэтому хорошо бы ещё поизучать тему доменов, вот тут, например https://docs.microsoft.com/ru-ru/dotnet/framework/...
Я сам тему предметно не копал, изучал только в ходе подготовки к экзамену, но как я это понял, суть будет почти та же, что и первый вариант — по сути, из основного кода запускается второй поток в другом домене. Разница только в том, что можно попробовать сделать одно приложение, которое в себе содержит второе и умеет его запускать.

Боюсь, придется сбегать в БД и получить объекты БД для тех тэгов, которые уже есть в базе. Либо сохранять через хранимку и в ней уже проверять, есть такой тэг в базе, или нет.

1. Хорошо бы код, который работает с оборудованием (читает данные) вынести в отдельный класс и сделать под него интерфейс. Для чего нужно — если нужно будет разделить работу "железячника" и программиста интерфейса, второму можно будет дать возможность запускать программу с "заглушкой", чтобы он пилил интерфейс без доступа к железу. Ну, или для демонстрации программы запустить без доступа к железу.
   
2. Соответственно, По событию на форме (старт/стоп) вызываются некие методы класса работы с железом и происходит получение/накопление данных. В зависимости от логики этого класса вызываются события (по получении байта, или полного пакета)
   
3. По событию (код формы навесил обработчики событий при инициализации кода, работающего с железом) форма уже обращается к экземпляру класса, который работает с железом и получает от него данные (скорее всего, в сыром бинарном виде) и что-то с ними делает. Например, преобразует в класс-модельку, которая добавляется в биндингсорс (List), который используется как DataSource для ListView
   
4. Код трансляции бинарных данных в модельку лучше тоже в отдельный класс вынести. Могу предположить, что могут быть разные формы представления данных.
   

Вкратце так.

Ну, а код класса имитации будет имитировать работу настоящего класса, вызывать нужные события и отдавать заранее записанные данные, или генерить по какому-то алгоритму. Переключение между заглушкой и настоящим классом реализуется, например, при помощи Dependency Injection, для C# можно использовать что-то типа https://habr.com/ru/post/50845/. В конфиг-файле прописывается, какой класс используется и всё, один и тот же код в рантайме использует разные классы. Лично я, например, так реализую работу с Фискальными аппаратами и терминалами оплаты пластиковыми картами.

Недавно Яндекс выкатил интересное демо своей технологии TTS (https://yandex.ru/promo/browser/video_translation/m/03), мне озвучка очень понравилась. Планирую в отпуске поиграться, попробовать озвучивать книги.

Для .Net я бы посоветовал OWIN — https://docs.microsoft.com/en-us/aspnet/core/funda...

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

Кстати, ASP.NET шаблоны сейчас активно используют owin.

В диалоге паблиша на вкладке Settings указать "Target runtime = Portable" - не оно?