Почему Windows XP из 2001 года работает быстрее, чем Windows 11, на одинаковом железе

мне было бы интересно смотреть такой же тест для linux дистрибутивов (не в сравнении с windows, а чисто между linux), а так же сравнение разных рабочих столов. Когда то я пытался найти информацию сколько сейчас ubuntu(например на gnome) потребляет памяти после старта системы, но не смог

Мне вообще никто не нужен, сам себе погрею ужин. Самодостаточная Data

Есть пакет spatie/laravel-data реализует в принципе тоже самое.

Про Vim — Neovim (Lua) PHP IDE

Treesitter нужно ставить обязательно с markdown и markdown_inline, это необходимо чтоб корректно отображались подсказки документации по методам, аргументам и тд. Для того чтоб показывались подсказки в режиме ввода можно использовать ray-x/lsp_signature.nvim

Intelephense умеет в автоматическое форматирование php файлов и в исправление форматирования, можно сделать например так:

function PhpFormatting()
    if &ft == 'php'
        lua vim.lsp.buf.format()
    endif
endfunction

autocmd BufWritePre *.php call PhpFormatting()

Для приятно работы с references и implementations можно использовать dnlhc/glance.nvim ну это субъективно.

Помощником с проектами на php может стать ta-tikoma/php.easy.nvim : создание классов с учетом области имен из composer.json и упрощение работы с удалением\копированием\добавлением методов\свойств\констант.

И в финале: пригодится L3MON4D3/LuaSnip для ускорения написания кода через снипеты.

Persistent-request библиотека для надежных запросов

у http клиента от laravel есть метод retry который позволяет повторить запрос сколько угодно раз, а так же обрабатывать ошибку по необходимости, я думаю это подошло бы на случай когда "моргнула сеть"

PHP. Как увеличить потребление памяти в 3 и более раз при работе с массивами

выглядит, как ситуация доступная для статического анализа, нет ли инструментов для его проведения?

Уменьшение трафика за счёт сжатия изображений. На примере Laravel

use Illuminate\Filesystem\FilesystemAdapter;
use Illuminate\Support\Facades\Route;
use Illuminate\Support\Facades\Storage;
use Intervention\Image\Facades\Image;

Route::get('/image/{width}/{height}/{filename}', function (int $width, int $height, string $filename) {
    /** @var FilesystemAdapter $disk */
    $disk = Storage::disk('public');

    $filename = basename($filename);
    $path = "image/{$width}/{$height}/{$filename}";

    if (!$disk->exists($path)) {
        Image::make($disk->path("image/base/{$filename}"))
            ->resize($width, $height)
            ->save($disk->path($path));
    }

    return $disk->download($path);
});

можно ещё проверять является ли файл изображением, ну думаю "и так сойдёт"

Контракты. Что это и с чем едят. Часть 1

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

Архитектурное тестирование

Целью статьи как раз является введение в данную тематику, чтоб составить общее представление и были средства "с чего начать".

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

Архитектурное тестирование

В превью статьи есть краткое описание о чем она.

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

Модульная архитектура Symfony приложения

Из пояснений не ясно какого размера у вас модули, есть какой либо критерий по объёму когда один модуль следует разбить на два?

Я использую схожую идею разделения на модули, но в проектах на laravel. Для себя выделил следующие правила:

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

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

Яндекс, ты свернул не туда

Из 17-ого года : https://habr.com/ru/post/320114/ ничего не поменялось

Wildberries сообщила о росте платежей через российские сервисы после введения 2% комиссии на оплату Visa и Mastercard

С какого то момента wildberries заселили всевозможные мелкие поставщики причём загрузка товаров прошла без всякой валидации в итоге когда ищешь одежду у тебя в фильтре "хлопок", "хопок", "холопок", "хлоппокпок" ... . С тех пор сервисом стало просто не приятно пользоваться, благо в нашем захолустье открыли пункт ozon.

PHP 8.1: до и после

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

А если бы внутри вводилась бы какая то псевдо типизация то как бы хорошо это отразилось на активрекорд, когда мы сейчас пишем свойство так:

$moo->where('foo', 1)

Можно было писать:

$moo->where(Moo::class->>foo, 1)

А внутри была бы проверка псевдотипа:

public function where(Moo::property, $value)

PHP 8.1: до и после

Интересно как иде будет чувствовать себя с

[$obj, 'doIt']

Почему бы не ввести сразу какой то синтаксический сахар для имени метода объекта (а за одно и свойства) типа:

echo $obj->>doIt;
// doIt

PHP 8.1: до и после

Указание свойств в конструкторе мне тоже не по душе (потому что для меня это выглядит не очевидным что это объявлены свойства объекта).

Скажу в защиту readonly, на сколько я понимаю, ключевое слово постулирует о том что php будет проверять что свойство было заполнено единожды и более изменяться не будет. В то время как в вашем варианте "неродивый" разработчик мог добавить в ваши объекты публичный сеттерт то с readonly это ему не поможет.

Валидация в приложении на PHP (часть 1 — валидация доменного слоя)

Статья интересная, хотел бы предложить на ваше рассмотрение два своих подхода:

Проверка данных в методе

Предлагаю не проверять внутри метода возможность его совершения. Рассмотрим предложенный вами пример с заказом. Выдачей сущностей у нас заведует репозиторий и я предлагаю в зависимости от статуса выдавать разные сущности унаследованные от одной основной, с той разницей что у DeliveredOrder не будет иметь метода cancel. То есть мы уже на уровне типизации защитимся от этого невозможного вызова.

Проверка данных в конструкторе

Я бы все же предложил переложить валидацию данных на билдер для конкретного класса. Например Собака не содержит в себе информацию о том как проверить набор веществ для своего создания, это в её "создателе" (да это тоже Собака, но ссылка на другой объект) произошла проверка что вещества подходят ли и в нужном ли количестве для создания Собака. А она уже содержит набор правил по взаимодействую с миром к тому что она ходит, а не летает например (ну это уже относится к первому пункту).

Декомпозиция Form Request в Laravel

Проблему повторения группы правил, как писал выше - создайте UpdateEmailRequest extends FromRequest и используйте его для проверки email

Декомпозиция Form Request в Laravel

Я понял почему не сделали разбиение на UpdateNameRequest, UpdateEmailRequest, UpdateAgeRequest унаследованных от FormRequest

PHP-Дайджест № 169 (26 ноября – 9 декабря 2019)

почти правы, но уже скоро месяц использую его на работе паралельно с другим редактором

PHP-Дайджест № 169 (26 ноября – 9 декабря 2019)

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

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