DevMan

Да. Такие эксперименты были. Лет 5 назад когда был еще жив sql.ru, один человек продвигал
модель т.н. квинтетов. Это таблица с 5 полями которая полностью описывала любую
доменную область. Я к сожалению не могу нигде найти следов описания этой системы
но возможно это оно https://cyclowiki.org/wiki/QDM . Читайте смотрите.

Второе. В эпоху новых версий DBMS (Oracle/PG/MySQL) когда мы можем использовать
JSON/XML внутри ячейки, сама идея EAV теряет смысл. Поле атомарно? Атомарно.
Значит законы реляционной алгебры мы не нарушаем и JSON совершенно легальный
тип для реляционок. Хотя лет 30 назад его использование было-бы кощунством
в БД. Но это можно было списать на жесткую экономию ресурсов и чрезмерную
математичность моделей Бойса-Кодда. Сегодня все используют JSON и нет никаких
архитектурных доводов против. Поэтому создавайте NoSQL табличку где есть
key и есть значение в виде либерального типа документа. Как делают MongoDb, CouchDb.
И если связать их в иерархию то получится вполне себе те-же самые квинтеты.

Про EAV лучше забудьте. Их любят преподаватели SQL и теоретики. Но практически EAV
слишком медленно работает чтобы развивать его в бизнес-приложении или в промышленности.
Мир тяготеет к упрощению. И поэтому JSON - это упрощение EAV. И работает быстрее.

CLR via C# открывай и иди по порядку, если хочешь глубже знать.
Если прям минимальный минимум, то:
1. Все стандартные управляющие конструкции: условия, циклы, итд.
2. Типы: примитивные, ссылочные, значимые. Работа со строками.
3. ООП: интерфейсы, наследование. Отличия между прямым и виртуальным вызовом
4. BCL
5. Linq: query синтаксис и через методы-расширения. Linq to IEnumerable, Linq to IQueryable и различия. Лямбды, делегаты, замыкания.
6. Потоки, таски, async/await. Понимание различий между асинхронностью и многопоточностью. Синхронизация потоков.
7. Всякие кишки: IL, рефлексия, emit, как работает JIT, как работает сборщик мусора.

В принципе этого достаточно для уверенного использования

В ремонт, смотреть блок питания и, скорее всего, менять конденсаторы.

- SELECT * FROM 'photos'
+ SELECT * FROM `photos`

Ну, это совсем просто. Чтобы держать биполярный ключ открытым, надо ему в базу загонять ток, всё время. Т.е. непрерывно тратить энергию, поскольку там есть замкнутая цепь для электрического тока (открытый эмиттерно-базовый PN-переход).
С полевым ключом принципиально не так. Управляющая цепь затвора - не замкнутая, поскольку между затвором и каналом есть изолирующая прослойка. Поэтому там ток не течёт, для открытия ключа достаточно подать напряжение, для закрытия - снять его. Электроэнергия на это практически не тратится (если не считать первый момент, когда заряжается затворная ёмкость). Вот и первое преимущество - экономичность в управлении.
Второе преимущество полевика - малое проходное сопротивление (единицы миллиом, много меньше, чем у биполярного, и в некоторых случаях даже меньше, чем у замкнутых контактов). Причём чем больше управляющее напряжение на затворе, тем проходное сопротивление меньше, соответственно и меньше нагрев полевика проходящим током. Однако не надо впадать в фанатизм на этом пути - если Uупр превысит значение 15 вольт, то изоляция затвора может быть пробита, и полевой ключ (такой удобный и простой в применении) превратится в тыкву.
Есть и другие отличия, которые проявляются только на высоких частотах.

Почему скомпилированный код в pyinstaller считается вирусом?
Как заставить антивирус не реагировать на мою программу как на вирус?

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

а сами спихивают на тормознутый комп.

серьезно? у вас это считается отмазкой?

Насколько безопасно пользоваться такими инструментами при разработке софта?

На 42.

Какие меры предосторожности есть?

Шапочка из фольги.

Анализируют ли подобные инструменты код проекта

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

могут ли "стянуть" креды которые описаны в local.env к примеру

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

Ну и в общем интересуют мысли комрадов на тему кодогенерации.

Камрад пишется через "а".
AI-ассистентов нужно выдавать только опытным разработчикам, потому что они не пишут код, а уменьшают рутину. Их нельзя использовать, если вы не можете написать то же самое самостоятельно - помимо галлюцинаций там могут быть просто ошибки и разработчик должен быть способен распознать и то, и другое.
Судя по ответам тех, кто решает нафармить себе зачем-то рейтинга здесь, перезадавая вопросы ChatGPT, а так же по вопросам тех, кто не поленился, прежде чем придти сюда, сходить в тот же ChatGPT - это редкий навык.

1. При ограничении бюджета лучше собирать ПК.
2. Я бы посмотрел в сторону не очень старых б/у ноутов в этом бюджете.
Смотри, чтобы было 16, а лучше 32гб оперативки, i7 (или типа того) и дискретка хотябы на 4гб видеопамяти.
Стоит ещё уточнить, что именно ты собираешься на юнити разрабатывать.
2д под мобилки или что-то фотореалистичное в 3д - это две большие разницы, хотя обе можно реализовать на юнити.

Низкий порог вхождения для C++ и Vulkan означает продвинутый уровень владения инструментом C++, экспертные навыки обработки графики, работы с шейдерами и управления памятью GPU (да, там все иначе). Для входа в работу с Vulkan нужно быть, как минимум, Middle Graphics Engineer и уже уметь уверенно работать с DirectX11 или OpenGL4.5. Без этих знаний вулкан будет очень сложно понять, а правильно работать с ним получится только через десятки и сотни полностью неудачных итераций написать одно и то же.

Vulkan является очень низкоуровневым GAPI и требует от пользователя изначально серьезной подготовки. У этого GAPI много точек привязки к системной памяти, содержимое которой трактуется как на GPU, так и на CPU. Поэтому работать с памятью в C++ правильно нужно уметь с самого начала. Поэтому, еще до начала работы с вулканом от пользователя требуются экспертные знания языка. В противном случае вместо обучения работе с довольно сложным GAPI получится блуждание по полю граблей, где ничего не понятно.

При этом, курсов, статей и книг для обучения вулкану очень много и их очень легко найти.
Есть очень хороший цикл статей для самостоятельного обучения, есть даже перевод на наш язык.
Есть множество книг, по которым люди учатся работать с вулканом. Learning Vulkan считается самой лучшей.
Поисковиком легко ищутся разные мелкие примеры работа с вулканом.
Есть даже онлайн курсы для обучения под наблюдением инструктора.

И тем не менее, вулкан легко не дастся. Для его понимания нужна база, нужно знать устройство GPU, принципы коммуникации с ним, принципы его работы и всю теорию обработки графики. Нужно уже уметь быстро писать много стабильного и сложного кода на C++, нужно уметь безошибочно писать на GLSL или SPIR-V. Нужно уметь пользоваться графическими отладчиками, профилировщиками, разбираться в диагностике проблем при работе с графикой.
Все это приобрести можно в процессе практики с DirectX11 и OpenGL4.5.