Георгий Кузнецов

Используй Pomelo.EntityFrameworkCore.MySql

информации насчёт того, как делать миграции в MySQL средствами Visual Studio

Сейчас миграции делаются не средствами студии, а средствами efcore cli - в этом плане раскатка миграций никак не отличается от любой другой СУБД.

и как, собственно настраивать проект под ASP.NET (options, builder, Swagger (не удивляйтесь, пока я именно его использую, т.к. при обкатке новой СУБД такой выбор очевиден) и прочее).

Они ортогональны и никак не зависят от СУБД.

PS: зачем тебе mysql, когда есть postgres?

Нет, если это локальная переменная, ничего делать не надо. Она выделяется на стеке и отчищается автоматически по выходу из функции.

Надо вызывать free только для тех блоков памяти, который вы сами получили через malloc.

Если я правильно понял Ваш вопрос, то это оно:
https://ru.wikipedia.org/wiki/Обратные_тригонометр...

Существует
=A2+ИНДЕКС(B:B;СЧЁТЗ(B:B)-СТРОКА(A1)+1)

Мужик, async/await - это просто сахар над Promise. Любая async функция возвращает Promise по определению, любой await этот Promise разрешает.

async function setLegalLevel(): Promise<string> {
  ...
  await axios.post
  ...
}
...
const val: string = await setLegalLevel();

см. import / export

Вопрос не специфичен для React / jsx.

JSX – JavaScript XML — синтаксический «сахар». Препроцессор jsx обёртывает все вставки HTML кода в вызовы React.createElement()

Треугольник можно составить из любых трех отрезков, пока выпонляется неравенство труегольника a+b > c, a+c > b, b+c > a. достаточно проверять только одно из них - максимальное число должно быть меньше суммы остальных. Но если не очевидно, какое из них максимальное, то можно проверять все три.

Итак, дано только A и k, так?

Чтобы как-то угол связать со сторонами надо воспользоваться теоремой косинусов:

c^2 = a^2+b^2-2*a*b*cosA.
подставив суда b=ck, получим
с^2 = a^2+k^2c^2-2*k*a*c*cosA

Это квадратное уравнение, связывающее C и A. Можно решить его относительно a (c - параметр) и вы получите а, выраженное через с.

Ну и в конце надо проверить, что a+b > c, a+c > b, b+c > a, подставив туда найденные формулы для b и a через c. В этих неравенствах будут известные cosA, sinA, k и неизвестная с. Поскольку тругольник по углу и соотношению сторон можно масшабировать, то неравнество должно выполнятся для всех c. Но на самом деле в этих неравенствах все c можно будет тупо сократить. Какие-то из них можно сразу же выкинуть, если рассмотреть 2 случая k>1 и k<=1. Ну а как их дальше решать - думайте сами.

но переходить с C# на C++ ,болезненно ,как я думаю

Если на глубоком уровне будешь понимать C#, то нетрудно будет перейти на C++.
В принципе, на слабом железе можешь работать с C# в юнити, а C++ отрабатывать на Godot и в каких-то собственных небольших играх на том же SFML.

Так ты сможешь потом при устройстве на работу опираться и на опыт работы с Unity и шарпом, и на опыт работы с C++, хоть и не в UE.

Я бы вообще разделил репы

Есть вот такой гайд https://dev.to/i5han3/git-commit-message-conventio...

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

По этому гайду получится что-то типа
feat(front): перекрасить кнопки
perf(back): убрать квадратичную сложность

Как вам удобно так и обозначайте, главное чтобы все это делали одинаково в команде и всем было понятно

Договоритесь о системе именования коммитов. К примеру:

commit -m "FRONT: какой-то комментарий к коммиту"
...
commit -m "BACK: какой-то комментарий к коммиту"

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

Функция - подпрограмма, выполняющая какие-либо операции и возвращающая значение.
Процедура - подпрограмма, которая только выполняет операции, без возврата значения.
Метод - это функция или процедура, которая принадлежит классу или экземпляру класса.

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

Для любой задачи которую без CS не решить. В предыдущих ответах часть задач уже перечислили. Но это всё касается специализированных задач. Никто не гарантирует вам, что в какой то момент у вас подобных задач не встретится на рядовом до сего времени проекте. Обычно это происходит когда проект вырастает за рамки какого-либо фреймворка, который до того покрывал все 100% таких задач. Банальный пример: было однопоточное приложение. Оно перестало справляться с нагрузкой. По совету с Хабр QA (ну или стэковерфлоу - не важно )) приняли решение переписать на параллельные вычисления. А не у кого нет даже базовых знаний какие существуют "грабли" (опять банальный пример - "состояние гонки" может и маститого профессора CS свести с ума, а, как в том анекдоте про каплю никотина, лошадь и хомяка, "голову вайтишника разрывает на куски") Поэтому пока у вас в команде есть кто-то со знаниями может пусть не всего CS, а хотя бы каких то базовых вещей, а вы просто кодите, то вам оно и не нужно. (как выше замечено - на "галерах" это не актуально. Хотя даже там вообще то такие люди обычно есть и получают они вдвое больше. Иначе какой им смысл там оставаться)

При использовании исправной техники с исправными зарядными устройствами, правильно проложенной проводкой и нормальным напряжением в сети вероятность взрыва или самовозгорания крайне низкая. Но не нулевая.
Чаще всего к самовозгоранию приводит либо физическое повреждение перегородок внутри аккумулятора (например, из-за падения устройства с аккумулятором или его сильное устаревание), либо существенное превышение напряжения питания (пробой напряжения сети на устройство).
В первом случае я знаю только одну историю, где самовозгорание было связано с браком - Galaxy Note 7. В целом чтобы так повредить аккумулятор, чтобы он загорелся, наверное, надо в него гвоздь вбить. По крайней мере ставить такое устройство на зарядку вряд ли придет в голову.
Во втором случае виной обычно являются дешевые китайские зарядные устройства без достаточной защиты между сетью и собственно USB-выходом. Тут однозначной рекомендации дать не могу, но в целом лучше пользоваться фирменными оригинальными зарядными устройствами (Apple, Samsung).
В остальных случаях вероятность самовозгорания очень низкая.

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

Но - если Вам спокойнее выключать неиспользуемую технику из розетки - хуже технике от этого не будет. И выключенная техника точно не загорится.

Computer science - все таки это наука, т.е. более область академических исследований, а не computer programming. Вики на это намекает так "Computer science is generally considered an area of academic research and distinct from computer programming".
Дело не в том, что это какое-то знание, которое нужно или не нужно. Это иная сфера работы. Т.е. если ты формируешь и обучаешь модель для бизнеса с помощью CatBoost, ты занимаешься computer programming. А если ты пишешь сам CatBoost или вообще изобретаешь градиентный бустинг, то ты занимаешься computer science.

Ну начнем с того, что computer science - это очень широкое понятие, которое включает в себя множество различных областей, как теоретических так и практических. Вопрос "нужен ли программисту computer science?" из той же оперы, что и "нужна ли программисту математика?", кому-то и арифметики хватает (а это тоже математика как не странно), а кому-то нужен углубленный бэкграунд в мат.анализе, тер.вере и мат.статистике. Так же и с computer science, кому-то хватит базового понимания, почему 0.1 + 0.2 != 0.3, а кому-то нужен углубленный бэкграунд в алгоритмы, в теорию типов и в слабые модели памяти. Все сугубо индивидуально и сильно зависит от сферы, для которой ведется разработка.
Многим совсем не обязательно знать как реализуются те или иные алгоритмы или структуры данных, вполне можно пользоваться готовыми. Но вот иметь представление, какие вообще бывают алгоритмы и структуры данных, какая у них алгоритмическая сложность - это полезно всем, просто чтобы знать что гуглить и какие вообще есть возможности решить ту или иную задачу. Так же полезно уметь считать ту самую алгоритмическую сложность из составных частей произвольного алгоритма и понимать чем отличается нотация O-большое от нотации Ω-большое. Какая от этого практическая польза? Для самого программиста - это возможность решать задачи проще и быстрее, выдавая при этом более оптимальные решения. Для бизнеса - это деньги, от банального "ускорив некое действие в N раз мы повысили конверсию в M раз", до насущного "сократив потребление ресурсов на N в прошлом месяце мы заплатили за облако на M млн. рублей меньше в этом месяце при той же нагрузке".
Та же архитектура, всем не обязательно уметь строить огромные решения с запасом прочности на десятки лет. Но понимать базовые принципы и паттерны, какие у них плюсы и минусы, где и что применять - полезно. К сожалению здесь все плохо в большинстве своем, порой доходит до того что стоимость поддержки небольшого проекта вырастает в 300-500 раз всего лишь за год поддержки. Для бизнеса это опять таки деньги, и если бизнес не планирует через год-другой либо продаться либо свернуться, как делают многие стартапы, то бизнес будет это оптимизировать. А на программистах такая оптимизация скажется на прямую, те кто умеет писать код на года будет получать выше рынка, иногда значительно. Хотя и те кто вообще в архитектуре не шарит без работы не останутся, так как работодателей с принципом "продали и забыли" просто банально больше.