Алексей Уколов

Можно сделать компонент кнопки корзины и в нем получать нужные данные
из request()->session() https://laravel.com/docs/12.x/blade#passing-data-t...

Если надо универсально, для любого кол-ва (что сомнительно):

function urlCombinations(...$arrays): array
{
    if (count($arrays) <= 1) {
        return $arrays;
    }
    $urls = [];
    foreach ($arrays[0] as $value1) {
        foreach ($arrays[1] as $value2) {
            $urls[] = "$value1/$value2";
        }
    }
    return urlCombinations($urls, ...array_slice($arrays,2));
}
var_dump(urlCombinations($array1, $array2, $array3));

Но, скорее всего так:

$urls = [];
foreach ($brands as $brand) {
    foreach ($styles as $style) {
        foreach ($colors as $color) {
            $urls[] = "$brand/$style/$color";
        }
    }
}
var_dump($urls);

На выбор, в зависимости от сценария и задач:
wget
curl
lynx ( спасибо AUser0)
openssl (что бы проверить валидность сертификата)

Сам по себе ping не может говорить о доступности ресурса (может не работать ping, а ресурс работать. И наоборот)

можно начать отталкиваться от такого:
https://codepen.io/FragsterAt/pen/Byoxaga

gpt ИИ тут никаким боком, абсолютно, даже вреден.
Эффективный размер контекстного окна топовых ии - 32к токенов (тех кто стоит баксы а не десятые цента за 'диалог'), ну а обычно это 8к токенов (даже если размер контекстного окна заявлен в сотни тысяч или миллион), и даже в этом пределе точность работы 80-90%, т.е. 20% информации может быть потеряна или искажена, что совершенно не подходит для аналитики.
https://github.com/mnismt/llms-long-context-benchm...
https://fiction.live/stories/Fiction-liveBench-Feb...

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

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

Сначала не мог понять в чем проблема, ведь у меня все работает как и раньше, но только со временем вспомнил, что джеты не так давно внедрили новый ЮИ, от которого я отказался, использую плагина Classic UI, там все работает как и раньше.

Если хотите работать на новом ЮИ, то инструкция такая:
или
Shift-Shift, type "Breakpoints over line numbers", and turn it off, и тогда по клику будет выделяться строка
или
Вместо клика теперь нужно зажать номер строки и повести мышку вниз до следующей, тогда выделится одна строка (или более, если вести мышку дальше)
или
Настроить кеймаппинг на выделение одной строки

По теме:
https://rider-support.jetbrains.com/hc/en-us/commu...
https://plugins.jetbrains.com/plugin/24468-classic-ui

Частота - это частота модуляции сигнала для работы протокола на определённой скорости. Для разных скоростей и стандартов она разная и, соответственно, разные требования к кабелю. Т.е., частота - это не характеристика самого кабеля, а максимально поддерживаемая кабелем частота, с которой может работать оборудование при использовании этого кабеля. Т.е., если вы воткнёте кабель 8 категории в 100 мегабитный порт - в кабеле будут 100 МГц (условно, есть разные стандарты), а не 2 ГГц. И наоборот, если воткнёте кабель 5 категории в 10 или 40 гигабитный порт - на требуемой скорости оно не заработает, т.к. характеристики кабеля не позволяют создать устойчивый сигнал с нужной частотой для данной скорости (может заработать на более низкой частоте и скорости - зависит от оборудования и его настроек). Есть целая группа разных стандартов Ethernet для передачи данных по разным кабелям, на разных скоростях и всякого такого прочего.
Вот парочка интересных статей:

• Физика Ethernet для самых маленьких: https://habr.com/ru/articles/158177/
  
• Эволюция сети Ethernet на витой паре: https://habr.com/ru/companies/netologyru/articles/...
  

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

Делайте так как понятно вам или команде. Главное, чтобы просто было понятно где что и не забывать эти стили применять для удобной корректировки сразу во всем проекте.
Можно делить стили цветов по группам (Blue/Base, Blue/Dark, Blue/Accent, Blue/Link и т.п.), можно делать группы наоборот - Base/Blue, Base/Green, Secondary/Blue, Secondary/Green, Links/Active, Links/Visited и т.п. Можно еще как-либо более удобно под проект. Со стилями текста, эффектов и прочего аналогично.

В сети масса материалов по дизайн-системам, в том числе, с примерами. Посмотрите как сделано у других и поймете как нравится вам.

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

Но у вас нейронные сети и маленький бюджет. Это буквально ограничивает решение одним компьютером.

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

В частых случаях можно приобрести несколько и будет vram будет суммироваться, но тут вылезает вторая проблема - pci-e, а точнее на количество линий на десктопных процессорах - 24, в принципе за материнскую плату и не дешевый процессор можно приобрести процессор с 48 линиями pci-e, это порядка 90т.р. и как раз хватит на оперативную память но не хватит на видеокарту.

Что значит мало линий pci-e, это значит видеокарты подключаются на низких скоростях pci-e 4x (вместо ожидаемых 16x) просто потому что железо не позволяет быстрее. И тут некоторые алгоритмы распараллеливания вычислений начинают сбоить и сильно понижать скорость, так как данные приходится гонять через медленную шину данных (а например генераторы видео нормально не распараллеливают на несколько карт, лучшие из открытых типа Hunyan или Wan вообще требуют 48гб за раз).


В общем в результате:
* оперативную память набирать 64gb-128gb, в идеале 196gb (тогда будут работать лучшие открытые модели на 5-10токен/сек скорости)
* видеокарту нужно приобретать с максимальным объемом vram, а это начиная с gtx 4060ti 16gb за 50т.р. или хотя бы 3060 12gb за 30т.р. (вот тут можно и две приобрести и найти материнку, поддерживающую две pci-e 8x, это не просто, так как даже если аппаратно будут видны контакты на разъемах, одновременная работа может не поддерживаться)... с такими видеокартами и на средних поиграть (они слабые, их достоинство именно объем vram за цену) и нейронки погонять с помощью ik_llama.cpp