smilingcheater

.grid {
  display: grid;
  grid-template-columns: repeat(8, minmax(0, 1fr));
  gap: 20px;
}

.grid > * {
  grid-column: span 3; /* по умолчанию все широкие */
}

.grid > :nth-child(9n + 3),
.grid > :nth-child(9n + 4),
.grid > :nth-child( 9n + 8) {
  grid-column: span 2; /* узкие элементы */
}

Можете ещё попробовать 14 колоночную сетку, узкие - 4 колонки, широкие - 5. Или 11 колонок (4 и 3). А вообще такие вещи нужно брать из макета или уточнять у дизайнера, какими флюидами он прочувствовал такие пропорции?

Если задача всплывает часто, освой Midnight Commander или иной двухпанельный файловый менеджер. Он запускается в терминальном режиме и прекрасно подходит для таких ситуаций.

Лучше 4к, 32" дюйма и 120 Гц, матрица - IPS или OLED, но с предварительным чтением обзоров, тестов и лучше своими глазами посмотреть. Меньше 27 дюймов брать нет смысла, больше стандартных 32 (т.е. полноформатных - 41-43) - выбор не очень большой и сложнее. Больше 43 - только изогнутый. Всякие сверхширокие, т.е. полуторная и двойная ширина - ну, тут больше дело вкуса и привычек, неплохая замена двум-трём маленьким мониторам.

это не usort. Это незнание языка

вариант 1

$order = 'price';
usort($filtered_items, function($a, $b) use ($order){
  return ($a[$order] - $b[$order]);
});

вариант 2

$order = 'price';
usort($filtered_items, fn($a, $b) => ($a[$order] - $b[$order]));

Не надо путать задержку и пропускную способность.

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

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

В сетях и на то и на другое влияет очень много факторов:
1. Количество узлов между отправителем и получателем. Больше узлов - больше задержка
2. Производительность этих узлов. Чем ниже производительность - тем выше минимальная задержка и меньше пропускная способность.
3. Нагрузка на каналы связи. При высокой нагрузке будет расти задержка, так как данные будут вставать в очередь (а может и не будут вставать в очередь - они вполне могут просто отбрасываться и тогда будет тот самый packet loss)
4. То, как эти узлы обрабатывают данные, которые через них проходят. Меньше всяких проверок - меньше задержка.
5. Физическая среда и физическая длина кабелей. Чем длиннее физический путь и чем хуже среда, тем выше задержка.
Скорость распространения сигнала в оптике, меди, и по беспроводу отличается.

Как будет влиять замедление от провайдера - сильно зависит от выбранной стратегии.
Может увеличится rtt, а может будет packet loss.

Если ноутбук и нет ограничений "только винда", то любой мак с минимум 16 гигами ОЗУ. Приоритет следующий: максимум ОЗУ, процессор, диск.
Если ПК, то в целом вот тут на 3DNews есть отличная подборка: https://3dnews.ru/1123785 - имеет смысл брать оптимальную и выше сборку. Приоритет тут чуть другой: процессор, память, диск, видеокарта.

Оптимальный вариант что-то типа такого (набросал на вскидку):

• Проц - AMD Ryzen 7 7700 +
  
• Мать - MSI PRO B860-P
  
• Диск - Samsung 9100 PRO 1+ ТБ
  
• Память - например G.Skill Ripjaws S5 [F5-6000J3636F16GX2-RS5K] 32 ГБ или G.Skill Trident Z5 [F5-6000J3238G32GX2-TZ5K] 64 ГБ, 6000 МГц
  
• Видеокарта - если не игровую, то 4060-70 вполне достаточно, что-то типа MSI/Gigabyte, если игровую - то аналогично что-то типа 5070-80-90 по вашему бюджету, только с воздушным охлаждением
  
• БП - Seasonic/FSP 850Вт+
  
• Кулеры - водянку не брать, только воздух, двухбашенный, топ - Noctua NH-D15 G2 или аналог от Bequiet/DeepCool; для корпуса - 200/230 мм, ноктуа/bequiet/bitfenix/DeepCool
  
• Корпус - любой на ваш вкус и бюджет, "всё в сетку" не брать, обязательно с воздушными фильтрами (CoolerMaster, LianLi, Deepcool и тп.)
  
• Остальное - по потребностям и бюджету (звуковая карта, картридеры и прочее).
  

Сборку доверить лучше знакомому, кто умеет или, если заказ будет всё в одном магазине - можно там, но обязательно с контролем.

Монитор - 4к, 120 герц, IPS/OLED, 32"+, например что-то типа LG UltraGear 32GR93U-B (но тут лучше смотреть обзоры и тесты сначала, посмотреть своими глазами в шоу-руме типа https://4k-monitor.ru/).

public function product($slug)
    {
        $product = Product::where('slug', $slug)->firstOrFail();

Здесь должно быть два параметра - категория и продукт.
Первым идет категория.
Вы ищете продукт, но в условие попадает слаг категории, запись не находится, и выбивает 404

То, что имя параметра метода совпадает с именем параметра в роуте, ничего вам не дает, потому что вы не используете биндинг.

Route::get('/{category:slug}/{product:slug}',[\App\Http\Controllers\ProductController::class,'product'])
    ->name('product');

public function product(Category $category, Product $product)
    {
        return view('product.index', [
            'product' => $product,
            'cat_slug' => $category->slug,
        ]);
    }

У тебя следующие задачи, которые решать придется по разному:
* детектирование включения машины
решается простой фиктивной службой systemd startup
* детектирование выключения машины
можно конечно тоже службой shutdown, но будут события только корректных выключений, а принудительные перезагрузки резетом или например ctrl+alt+shift+pause .. r (которая работает даже если модули ядра повиснут), не отловит.
Тут можно поставить скрипт, анализирующий работу машины на соседнюю в сети, вариантов тьма.
* попытки входа в систему
В общем случае это в /var/log/auth.log там будет все, и использование sudo/su, и запуск процессов cron и служб (с указанием пользователя) и ssh подключения и тьма тьмущая всего что так или иначе затрагивает авторизацию, что и является 'вход в систему', там же можно посмотреть что пишет lightdm на попытки входа в gui

Мониторить попытки входа придется скриптом, периодически читающим файл (осторожно tail -f /var/log/auth.log | my_script не отследит ротацию логов, поэтому лучше самому следить за датой последнего изменения файла и читать его с позиции, на которой остановился в прошлый раз ну или с нуля)
upd. век живи век учись, ключ tail -F корректно будет работать с ротацией логов

Если делать 'по феншую', то лучше работать с подсистемой сбора событий, в python с помощью python-systemd - journal например фильтруя по _SYSTEMD_UNIT=sshd.service и _COMM=sshd (сам я не делал, посмотрел что можно и в памяти отложил, сейчас ИИ спросил, да где то так и надо)

* отправка сообщений в telegram
можно конечно использовать какую-нибудь библиотеку, многословно, красиво... а можно отправить один http запрос по api telegram, кода минимум, наверное все так в своих скриптах делают

https://api.telegram.org/bot<TOKEN>/sendMessage?chat_id=<CHAT_ID>&text=Hello%20World

Вопрос "как обратиться через аякс к свойству класса пхпе" является заведомо бессмысленным. JS не работает со свойствами классов в РНР.
Поэтому в решении таких проблем очень помогает логика.
Если отставить в сторону "свойства", то мы получим довольно простую формулировку вопроса: "почему синхронный и асинхронный запрос к одному и тому же скрипту возвращают разные данные?". И здесь уже, рассуждая логически, можно прийти к очевидному ответу: эти запросы обращаются к разным бэкендам. То есть, чтобы решить проблему, надо либо обновить код на том сервере, к которому обращается fetch, либо делать запрос на тот сервер, который возвращает правильные данные.

Это если исходить из предоставленных данных. Вполне вероятно, что автор запутался где-то ещё. Но тут уже ему придётся разбираться самостоятельно. Но опять же, рассуждая логически, а не "Почему не получается обратиться к свойству php через асинхронный запрос?".

Почему «пропали» коммиты?

Главная ошибка — использование --amend во время rebase.
Команда git commit --amend не создает новый коммит, а перезаписывает предыдущий.

Когда вы время интерактивного rebase на каждом шаге делаете --amend, вы по сути всё время заменяете один и тот же коммит. Остальные коммиты, которые Git должен был «применить» в процессе ребейза, просто исчезают, потому что их заменили.

Как делать правильно?

Во время rebase -i вместо amend нужно:

git add <файлы> #  главное проиндексировать правки файлов
git rebase --continue # тут гит уже сам сделает git commit --no-edit

Вручную делать git commit перед continue имеет смысл только если вы хотите поменять ещё и сообщение коммита.

Как восстановить утерянные коммиты

Git не удаляет коммиты сразу. Они остаются в репозитории и доступны в reflog — журнале ссылок.

Их можно найти так: git reflog

Затем восстановить ветку: git reset --hard <хеш_из_reflog>

Вывод

Это не баг Git, а ожидаемое поведение. Просто rebase + amend — взрывоопасная смесь, особенно если не до конца понимать, что происходит.

В телефоне можно какой-то апп под андроид, который получает уведомление и орёт.

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

Возможно криминал, по коням!

Что делать?

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