Дмитрий

Конвертирование в число

StackOverflow

Видеокарта точно потянет.
hdmi 1.4 потянет 4K, но только на 30hz
Насчет того, что там из type-c с переходником удасться выжать - надо эксперементировать (могут быть проблемы как с переходником, т.к. не все они одинаковы, так и с самим разъемом).

Ну и если говорить об играх - мобильная 3050 в 4К разрешении в современных AAA не выдаст 60fps точно.

echo implode(
	', ',
	array_filter(
		array_keys($arr),
		fn($key) => in_array($person, $arr[$key]),
	),
);

У команды init достаточно большой перечень опций, так что можно в саму команду прописать все дефолтные значения, и каждый последующий проект инициализировать ею:

composer init --name='gordinskiy/new_package' \
    --description='Project description' \
    --type='library' \
    --author='Dmitriy Gordinskiy' \
    --license='MIT' \
    --require='php:>=8.2' \
    --require='webmozart/assert:^1.11' \
    --require-dev='phpunit/phpunit:^10.3' \
    --require-dev='vimeo/psalm:^5.11' \
    --require-dev='phpstan/phpstan:^1.10'

Не дублирование, а symlink. Примерно как ярлык. В avaliable храним конфигурацию хоста, в enabled кидаем симлинк, чтобы включить его. Nginx считывает конфиги из enabled. Если хотим выключить, удаляем симлинк, а файл конфигурации остается лежать.

Самый лучший способ - посмотреть в QVL матери и выбрать быструю память из списка.
Память не из QVL тоже может завестись с XMP профилем, а может заработает только на частоте без разгона, ну или какой-то промежуточный вариант возможен.
В XMP профиль обычно зашита максимальная частота (т.е. 4000 в вашем случае).

Предлагаю такой план:
1. Устанавливаете XMP профиль, пробуете.
2. Если не заработало, не включилось или работает с ошибками - устанавливаете XMP профиль, но снижаете частоту до 3200.
3. Если не помогло - устанавливайте по дефолту и пробуйте разгонять.

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

Если невероятным интеллектуальным усилием правильно атрибутировать свою проблему, и сообразить, что она не имеет ни малейшего отношения к РНР, то её вполне можно задать мировому разуму: tar исключить директорию

$ man tar
...
       --exclude=PATTERN
              Exclude files matching PATTERN, a glob(3)-style wildcard pattern.

= ≢ ==

- if($block_level = 1){
+ if ($block_level == 1) {
- }elseif($block_level = 2){
+ } elseif ($block_level == 2) {
- }elseif($block_level = 3){
+ } elseif ($block_level == 3) {

php отправляет заголовок браузеру что нужно установить куку, а не ставит ее. Бесполезно проверять ее наличие сразу после отправки заголовка. В следующем запросе эта кука вернется браузером на сервер.

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

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

Единственный разумный выход - если producer создает специальное сообщение-терминатор
которое как-бы сигнализирует что все дескыть конец.

Ты забыл третий вариант, самый быстрый и наиболее предпочтительный если общее количество опций не велико (сотни, например у mysql лимит 1024 колонок максимум) - каждая опция это своя колонка, пустое (null) значение будет значить отсутствие опции у записи.

Недостаток подхода - если у объекта может быть несколько опций с одним именем, то такой подход не работает (но судя по всему это не твой случай).

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

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

p.s. если говорить про твои варианты:
* для 1 используй json сериализацию (опция=значение) в mysql для работы с такими данными есть соответствующие методы
* для 2 постарайся вместо текстовых наименований опций использовать числовые идентификаторы, заведя соответствующий классификатор либо в базе в отдельной таблице либо в виде констант в коде.

p.p.s. Ну и еще вариант, если тип значений опций - boolean (либо ограничен небольшим количеством значений, например цвет светофора 4 - выключен, красный, желтый, зеленый) то так же заводи для этих значений числовой эквивалент. В этом случае у тебя появляется еще бонус, упаковывать битовые значения (где количество вариантов 2^x и x это количество бит) и хранить в целочисленном поле сразу несколько (правда не все базы позволяют индексировать операции с битами).

1. Если в разрабатываемой системе нет потребности производить нечеткий поиск, получать сверхбыстрый ответ на запрос в реальном времени (не более пары миллисекунд), производить аналитику данных в самых разных разрезах. У вас в потоках данных определены сущности с четкими реквизитами и сущности имеют высокую связность, то в 99% случаях вы даже не повернете голову в сторону нереляционных СУБД, будете использовать реляционные.
2. На самом деле, просто зависит от того, как сложно администрировать СУБД в том масштабе, в которой развилась база данных. Сначала берут первую попавшуюся, или с тем, с чем освоились более-менее, а потом смотрят с течением времени, как сложно нанять нужного специалиста на администрирование, удобно ли масштабировать экземпляры баз данных при возросшей нагрузке, удобно подымать экземпляры из небытия, держать непрерывный аптайм. Вот тут уже выясняется специфика работы предметной области и необходимость переезжать на подходящее окружение.