VoidVolker

• Бэк
  
• Фронт
  
• Мобилка
  
• Либа проекта 1
  
• Либа проекта ...
  
• Либа проекта N
  

Фронт так же можно сделать поддеревом/подмодулем бэка. Зачем выносить общий код в отдельные репозитории? Дык декомпозиция же. Удобнее работать с кучкой маленьких, законченных и более-менее автономными модулями/пакетами, чем размазывать одинаковый код по куче разных репозиториев и потом гадать что новее, старее, совместимее, оптимальнее и прочее. Да, можно сделать один общий репозиторий и держать там миллион разных модулей и прочего (ну или один большой и толстый). А потом копать кротовые норы с красными глазами в этой горе непонятно чего в поисках ошибок и нужного кода.

В виртуалке ARM сборка работает шустро и вполне юзабельна. х86 - только для тестирования/отладки/экспериментов. Разница в производительности ARM/x86 - х10, в пользу арма есстественно. Для виртуализации использую UTM. В докере ситуация примерно такая же - но замеров не делал, так как нет смысла, ибо везде будет примерно одинаково ввиду отсутствия железной поддержки виртуализации в м1. Еще есть бета билд виртуалбокса для м1 - я его пока еще не смотрел. И да, кто-то там пилит сборку для нативной установки линукса на м1 и какой-то результат там есть. Вот только половина железа там не работает, т.к. нужны драйверы, а их взять неоткуда. Да и будет ли оно вообще когда-нибудь никто не знает. Так что можно просто забыть.

1. Кодировка: учитывайте кодировку, в которой находится символ стрелочки в переменной и в той же кодировке он должен быть в браузере либо должен быть конвертирован в правильную кодировку
   
2. Шрифт - в IDE и браузере они могут отличаться: в разных шрифтах стрелочка може быть, может не быть, может быть не стрелочкой
   

1. Проверить, что разделы занимают весь диск, а не его часть. Например средством управления диском или любым менеджером разделов.
   
2. Проверить маркировку диска - та ли это модель или не совсем.
   

Например PDF Creator - юзал, отлично решение, куча фич. Только что наткнулся на IronPDF - как я понял то-ли обертка, то ли выжимка/форк PDF Creator в виде nuget пакета. Там же еще есть PDF Architect - это уже полноценный настольный редактор для PDF.

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

Потому что есть несколько вариантов использования оператора инкрементации с разным поведением, что отлично описано в мануале:
Reference -> Operators -> Increment

#if DEBUG
        server = "test";
#else
        server = "prod";
#endif

1. Открыть документацию:
   • Array
   • Classes
2. Прочитать документацию
   
3. Выполнить пример из документации
   
4. Использовать изученный пример в реальной практике
   

WindowsForms использует очень древний и устаревший GDI+ - сегодня его использовать имеет смысл только если нужна поддержка Windows XP (либо еще каких-то окаменелостей). Во всех остальных случая лучше использовать WPF или MAUI - там нет лагов и тормозов. Если же хочется ускорить формы, то ищите по теме "speedup/boostup gdi windowsforms" - там надо добавить несколько дополнительных флагов при создании окна и, ЕМНИМ, включить двойную буферизацию. На SO есть все решения. Но, некоторые тормоза все же будут. Если хочется красиво запустить приложение, то при запуске надо создавать окно в скрытом виде, затем ждать пока инициализируются остальные компоненты и только потом уже показывать само окно. Если нужна производительная сложная анимация - то про формы лучше забыть и сразу перекатываться в WPF/MAUI. В крайнем случае можно создать компонент на WPF и использовать его в формах: я так делал или наоборот, когда надо было использовать древнее легаси WinAPI, но в современной красивой обертке с нужными фичами. На счет интеграции MAUI и форм не подскажу.