Василий Банников

Такая Headers?.UserAgent запись - это Null Propagation - если Headers == null выражение вернет null (без ? было бы NRE)
value ?? string.Empty это сравнение значения с null - если value != null, то вернет value, в противном случае вернет string.Empty

0 и более подряд символов л, <пробел> или ".

А вообще: изучите регэкспы, на таком примитивном уровне - это совсем не сложно.
Штука незаменимая для работы с любым текстом.

Что вы понимаете под "создавать переменные"? Если вы имеете в виду объявление переменных, то это не просто нормальное явление, а рекомендация - если переменная нужна вам только в цикле (а за пределами цикла её видно не будет, т.к. у цикла будет свой scope), то намного лучше, если вы в цикле её и объявите.

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

Тут вопрос требований к проекту. Если в ТЗ четкое указание использовать Bootstrap, то куда вы от этого денетесь. Придется изучать. Главное понять его принцип, тогда ничего муторного не будет. Есть классы с интуитивно понятными именами, добавляя которые в html код вы используете уже написанные заготовки css из bootstrap.

Если требование к проекту не регламентируют обязательное использование Bootstrap, то тут конечно проще и быстрее (хотя это субъективно) написать свой код. У своего кода неоспоримое преимущество в том, что его будет значительно меньше и можно использовать легкие и быстрые технологии , такие как css grid. Все это позитивно скажется на проекте в плане чистоты кода и скорости загрузки, так как не надо тянуть весь фреймворк если вам требуется всего 10% его возможностей. Или использовать длиннющий стек классов в html тегах.

То есть, вопрос ставить так - "что проще?" - не корректно. Проще то что вы лучше знаете. Есть люди которые слабо знают css и зазубрили классы bootstrap, есть те, которые отлично знают css но слабо ориентируются в классах Bootstrap. И нивелируют все эти метания требования ТЗ. ))

Удобной практикой является использование полностью своего CSS в связке с JS компонентами Bootstrap. Компоненты - это то чем стоит пользоваться. Зачем писать свой JS если всё уже написано или если нет навыков JS, тем более можно подключить только то, что нужно.

на любом

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

поэтому пишешь свои скрипты по редактированию исходных файлов проекта и запуску сборки по запросу с веб сервера

public string Name
{
   get
   {
       return this.name;
   }
}

Да вроде все правильно. Скорее всего опечатка в задании где-то. Так бывает. Или где-то может быть сказано, что углы должны быть в градусах а не радианах. Тогда выражение под синусом/косиносом надо домножать на 180/pi.

Язык - инструмент, нужный для решения задач. Вам некомфортно с C# или go не потому, что лень, а потому, что Ваши задачи гораздо лучше решаются JavaScript. Судя по тому, что освоить синтаксис других языков Вы смогли, не думаю, что при появлении интересной задачи, которая не решается на JavaScript, Вы спасуете, скорее всего быстро разберетесь. А изучать просто ради изучения неэффективно. Так что вряд ли это может негативно повлиять на будущее.

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

значит узкое место почти наверняка диск.

Пальцем в небо, файловая система на которой таблеспейсы лежат какая? случайно не cow (btrfs/zfs/xfs)? с ними отвратительно работают базы данных, так как частые записи в файл генерируют сильную фрагментацию. В этом случае перед тяжелой обработкой хотя бы дефрагментируй файлы базы и отключи cow фичу на таблеспейсах

неплохим тюнингом может оказаться (на выбор):
* разместить базу в ram диске (буквально, залить на сервер в облаке, обработать данные, залить назад, работая напрямую с таблеспейсами, но версия софта должна совпадать до последней цифры)
* разместить базу целиком на ssd (даже если это будет потребительский и дешевый)
* добавить в систему ssd кеш для hdd с помощью например bcache (включенный на запись), правда для линейной обработки базы это может дать мало пользы, но вообще это неплохой способ на порядок поднять производительность за дешево (в одном месте я использовал фичу virtualbox со снапшотами в файл, есть и у kvm, когда последующие записи шли не на исходный образ а на другой диск, и он ssd)
* разместить таблеспейс для индексов (а может и каждую таблицу отдельно) на другом физическом устройстве (hdd, ssd или даже в ram), требования к размеру тут обычно низкие, ключевое слово - исключить последовательные чтения/записи на одно устройство.
* разместить журнал (например ext4) на ssd диск (хватит пары гигабайт) или по хардкору даже отключить его (очень опасно, можно получить кашу из данных при сбое питания, но как временное решение пока идет долгая операция, при наличии всех бакапов, оправдано) - наименьшая оптимизация, но при частых мелких записях это заметно

int a, b, dob =0;
...
dob *= i;

Умножать на 0 можете хоть до посинения, все равно будет 0. Математика младшей школы...

Ну потому что как-бы вы говорите компьютеру пойди туда, не знаю куда, делай то, не знаю что.

Он офигивает и падает.

Не нужен, в Go есть полноценный веб сервер.

Nginx есть смысл использовать в случае если есть необходимость обслуживать больше одного домена на одном и том же IP:Port, ну и для раздачи статики (изображений, CSS, Javascript и т.д.)

Еще есть смысл использовать Nginx когда у вас большая нагрузка и ваш сервис на Go работает на нескольких серверах - Nginx'ом можно балансировать нагрузку между этими серверами.