😱 Знакомо? Лимит уже закончился, а задача всё ещё не готова. Часть токенов могла уйти на повторное чтение файлов, лишний контекст и неудачные попытки.

⚡️ Этому посвящён отдельный блок курса «ИИ для разработчиков». Вы разберёте расходы на собственных проектах, сравните подходы и найдёте места, где агент выполняет лишнюю работу.

В итоге станет понятнее, сколько ресурсов выделять на запуск, когда его останавливать и в какой момент лучше изменить подход 🔍

До 31 июля курс можно купить со скидкой, а все материалы останутся в бессрочном доступе.

🔗 Узнать подробности о курсе

🏃‍♀️ Proglib Academy

👀 Хуки свойств в PHP

В PHP 8.4 появилась долгожданная возможность — хуки свойств.

Это встроенная логика чтения и записи значения прямо в объявлении свойства. Без отдельных методов, без шаблонных getSomething() и setSomething(). Код становится компактнее, выразительнее и проще для сопровождения.

🔹 В чём была проблема

До этого было всего два варианта:

— классический подход с приватными полями и методами доступа;
— promoted-properties из конструктора — удобно, но без логики.

У обоих подходов есть ряд минусов:

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

🔹 Что изменилось с хуками

Теперь PHP позволяет перехватывать:

→ момент чтения свойства;
→ момент записи значения.

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

🔹 Виртуальные свойства

PHP 8.4 позволяет создавать свойства без собственного хранилища.

Такие свойства:

→ не занимают память;
→ вычисляются при каждом обращении;
→ выступают как интерфейс к другим данным объекта.

Полезно для: объединённых представлений данных, вычисляемых значений, и упрощения публичного API модели.

⚠️ Важные ограничения

— хуки несовместимы с readonly-свойствами;
— изменение по ссылке может обойти логику записи;
— не все внутренние функции PHP вызывают хуки одинаково.

🔗 Хабр

Библиотека пхпшника

🎯 Сжатие и минификация CSS/JS через Node или PHP

Команда (Node.js + Terser для JS):

npx terser src/app.js -o dist/app.min.js -c -m

💡 Минифицирует ваш JavaScript, сокращает код и уменьшает размер файлов, используя Terser.

Команда (Node.js + CleanCSS для CSS):

npx clean-css-cli -o dist/style.min.css src/style.css

💡 Минифицирует CSS, удаляя пробелы, комментарии и упрощая записи, что ускоряет загрузку страницы.

❓ Зачем это нужно?

🔹 Ускорение загрузки страниц: Меньший размер JS и CSS сокращает время передачи данных.

🔹 Оптимизация производительности: Минифицированный код обрабатывается браузером быстрее.

🔹 Чистый продакшн: Убираются ненужные пробелы и комментарии, что делает код компактным.

⚙️ Дополнительные опции Terser:

-c или --compress: Сжимает код, удаляя лишние конструкции.
-m или --mangle: Переименовывает переменные и функции, уменьшая размер.
--source-map: Генерирует source map для удобного дебага минифицированного кода.
Пример с source map:

npx terser src/app.js -o dist/app.min.js -c -m --source-map

⚙️ Дополнительные опции CleanCSS:

--compatibility — задаёт совместимость с браузерами.
--level — уровень оптимизации (1 или 2).

Пример:

npx clean-css-cli -o dist/style.min.css src/style.css --level 2

Библиотека пхпшника

PHP 8.6 вышла на финишную прямую 🚀

Июль оказался насыщенным для PHP 8.6: команда выпустила сразу три тестовые версии — Alpha 1, Alpha 2 и Alpha 3. Следующий этап — Beta 1, которая запланирована на 13 августа.

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

Финальный релиз PHP 8.6 ожидается 19 ноября 2026 года.

💡 Если вы поддерживаете библиотеку, фреймворк или крупное приложение, сейчас хорошее время добавить PHP 8.6 в CI отдельной задачей и прогнать тесты. Найти несовместимость за несколько месяцев до релиза намного проще, чем после выхода стабильной версии.

Библиотека пхпшника

🧑‍💻 Меньше параметров в дочернем методе? Да, если используется variadic

Не все знают, что начиная с PHP 8.0 дочерний метод может объявлять меньше именованных параметров, чем родительский. Это возможно, если несколько совместимых параметров заменяются одним variadic-параметром.

🅰️ Например:

class X
{
    public function foo(int $a, string $c, string ...$b): void {}
}

class Y extends X
{
    public function foo(int $a, string ...$b): void {}
}

Такой код полностью корректен. Значение, которое в родительском методе попадало в $c, в дочернем станет первым элементом $b.

➡️ Почему это работает? Потому что дочерний метод по-прежнему принимает все вызовы, допустимые для родительского:

$x->foo(1, 'A');
$x->foo(1, 'A', 'B', 'C');
А вот так уже нельзя:
class Y extends X
{
    public function foo(int $a, int ...$b): void {}
}

или

class Y extends X
{
    public function foo(int $a, string $c, string $d, string ...$b): void {}
}

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

💡 Главное правило простое: при переопределении метод должен принимать как минимум все вызовы, которые были допустимы для метода родительского класса.

Библиотека пхпшника

💡 Хорошая шпаргалка по PHP с основными конструкциями языка: синтаксис, функции, массивы, строки, ООП, работа с файлами, обработка ошибок и многое другое.

Некоторые примеры относятся к версиям PHP до 8+, но в целом материал остаётся полезным.

Библиотека пхпшника

🚀 Pipe-оператор в PHP 8.5: конец «пирамиде смерти»

Одна из самых ожидаемых возможностей PHP 8.5 — pipe-оператор (|>). Он передаёт результат выражения слева первым аргументом вызываемой функции справа, позволяя строить цепочки преобразований, которые читаются сверху вниз.

// Было
$result = strlen(htmlspecialchars(trim($input)));

// Стало
$result = $input
    |> trim(...)
    |> htmlspecialchars(...)
    |> strlen(…);

Запись ... — это first-class callable. Такой код проще читать, отлаживать и постепенно расширять: каждый этап преобразования явно отделён от предыдущего.

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

🔗 Источник

Библиотека пхпшника

Совет по Laravel💡: Встроенная валидация

Хотя Laravel предлагает множество правил валидации, иногда возникает необходимость в использовании пользовательских правил.

Обычно они записываются в пользовательском классе.

Но знаете ли вы, что можно выполнять и валидацию в строке? 🚀

Библиотека пхпшника

🤔 У большинства разработчиков уже есть подписки на IDE, GitHub Copilot, Claude, ChatGPT или облачные сервисы.

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

Такой формат недавно появился и в Proglib Academy. Вместо одного курса — доступ сразу ко всей библиотеке и новым материалам, которые появляются в подписке 😎

🔗 Подробнее

🏃‍♀️ Proglib Academy

😧 Почему strtr() иногда лучше, чем str_replace()

Если нужно заменить сразу несколько строк, многие используют str_replace(). Но есть нюанс: замены выполняются последовательно, поэтому результат одной замены может попасть под следующую.

🔴 Например:

$map = [
    'foo'    => 'bar',
    'foobar' => 'foo',
];

$input = 'foobar and foo';

echo str_replace(
    array_keys($map),
    array_values($map),
    $input
);
// bar bar and bar

Сначала "foo" превращается в "bar", поэтому "foobar" становится "barbar" и до второй замены уже не доходит.

🔴 strtr() работает иначе:

echo strtr($input, $map);
// foo and bar

Функция выполняет один проход по строке и всегда выбирает самое длинное совпадение. Уже заменённые части строки повторно не обрабатываются.

Благодаря этому:

— не нужно сортировать шаблоны по длине;

— замены не влияют друг на друга;

— результат получается более предсказуемым.

Если требуется заменить несколько независимых подстрок по словарю вида "что" => "на что", strtr() часто оказывается более удачным выбором.

Библиотека пхпшника

💡 Laravel-совет

Директива @env_required() позволяет проверять, что переменная среды установлена и имеет значение, отличное от null. Она может быть полезна для обеспечения того, чтобы приложение работало правильно только при наличии определенных переменных среды.

В нашем примере директива @env_required() используется для проверки переменной среды APP_KEY. Если переменная не установлена, будет выброшено исключение.

Библиотека пхпшника

📈 Почему память в PHP-воркерах только растёт — и это нормально

Если вы переходите с PHP-FPM на RoadRunner, Laravel Queue или Symfony Messenger — вы увидите один и тот же эффект:

Память растёт ступеньками и никогда не падает.

40 → 200 → 350 МБ… и так до перезапуска.
Unset, GC, collect_cycles() — не помогают.

Это не утечка. Это архитектура PHP.

🔵 Почему так происходит

PHP использует Zend Memory Manager: он выделяет память крупными чанками (2–4 МБ) и не отдаёт их ОС назад, даже если внутри всё освобождено.

Каждый пик — новый baseline. Обработали 100k записей → память выросла → процесс будет держать этот объём до конца жизни.

🔥 Что вызывает «разбухание»

ORM ->all() или ->get() на десятки тысяч записей

большой файл в file_get_contents()

накопление массивов

сложные eager-loading графы ORM

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

— Стриминг вместо коллекций:

User::lazy()->each(fn($u) => processUser($u));

или:

Record::chunk(100, function ($rows) {
    foreach ($rows as $r) processRecord($r);
});
✔️ Doctrine:
foreach ($q->toIterable() as $u) {
    process($u);
    $em->detach($u);
}

— Изоляция тяжёлых операций в функцию — память освобождается при выходе из scope.

— Ротация воркеров — обязательна:

Laravel:
php artisan queue:work --max-jobs=1000
RoadRunner:
pool:
  max_jobs: 1000
Messenger:
messenger:consume --limit=1000

Библиотека пхпшника

🤔 Вопрос с собеседования

Планируется ли внедрение нативных дженериков в PHP в ближайшем будущем?

Например:

class Box<T>
{
    public function __construct(public T $value) {}
}

👇 Правильный ответ (нажми, чтобы прочитать):

Пока — нет подтверждённого релиза.

В 2026 году появился новый RFC Bound-Erased Generic Types, который предлагал добавить дженерики для классов, интерфейсов, трейтов, функций и методов. В июне предложение вынесли на голосование, но RFC был отклонён.

🈂️ Поэтому на август 2026 года нативных дженериков в PHP нет и конкретной версии, в которой они появятся, тоже нет. На практике generics по-прежнему реализуют через PHPDoc и статические анализаторы вроде PHPStan и Psalm:

/**
* @template T
*/
class Box
{
/** @param T $value */
public function __construct(public mixed $value) {}
}

👍 — знал/а
🔥 — стало понятнее

🐸 Библиотека пхпшника

🔥 В Laravel 13 прокачали локальную разработку

Теперь для запуска основного dev-окружения достаточно:

php artisan dev

➡️ Команда собирает в одном терминале сразу несколько процессов:

php artisan dev
       │
       ├── server → php artisan serve
       ├── queue  → queue worker
       ├── logs   → Laravel Pail
       └── vite   → frontend dev server

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

Свои процессы тоже можно зарегистрировать — например, Reverb или listener для Stripe. Меньше отдельных терминалов и ручного запуска сервисов при каждом старте проекта ✅

🔗 Источник

🐸 Библиотека пхпшника