🐳 Работа с Docker CLI

Собрали образ и он весит 2 ГБ, а вы не понимаете, откуда столько? docker history покажет размер каждого слоя — сразу видно, какая инструкция в Dockerfile раздула образ.

🔹 Зачем это нужно

— Каждая инструкция в Dockerfile создаёт слой, и docker history показывает размер каждого.
— Сразу видно, если COPY затянул 800 МБ зависимостей.
— Помогает оптимизировать порядок слоёв для лучшего кэширования.

🔹 Как использовать

— Посмотреть слои: docker history my-image
— Без обрезки команд: docker history --no-trunc my-image
— Только размеры в human-readable: docker history --format "{{.Size}}\t{{.CreatedBy}}" my-image
— Сравнить два образа: запустите history для обоих и сравните слои.

💡 Если видите большой слой от COPY . . — значит, в контекст сборки попали модули, .git или логи. Проверьте dockerignore, это обычно экономит сотни мегабайт.

🛠 Rector — апгрейды и рефакторинг, которые делает машина

Когда нужно перевести проект с PHP 8.1 на 8.3, заменить устаревшие конструкции по всей кодовой базе или прогнать сотню файлов через единый стиль руками → это недели и неизбежные пропуски.

Rector работает на уровне AST: понимает структуру кода, а не текст. Накатываешь набор правил (rule sets), апгрейд версии языка, миграция мажорной версии фреймворка, переход на новый синтаксис, и он переписывает код безопасно и единообразно.

🔹 Где особенно окупается:

— Массовые апгрейды версии PHP/Laravel/Symfony
— Выпиливание задепрекейченного API одним прогоном
— Кодстайл-преобразования, которые линтер только подсвечивает, но не чинит
— Подготовка легаси к строгой типизации

⚠️ Прогонять только под контролем VCS и с тестами. Rector мощный, и именно поэтому его изменения нужно ревьюить, а не вливать вслепую.

🔗 GitHub

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

🧱 Не тащи string $email по всему приложению

Примитив не защищает свои инварианты. string $email может быть пустым, может быть «не email», и каждый метод, который его принимает, обязан валидировать заново или молча доверять.

// ❌ валидность email — на совести каждого вызывающего
public function register(string $email, string $phone): void { ... }
// где-то проверили, где-то забыли, где-то проверили по-другому

Value Object переносит правило внутрь типа: невозможно создать невалидный объект.

final class Email
{
    private function __construct(public readonly string $value) {}

    public static function fromString(string $raw): self
    {
        $email = filter_var($raw, FILTER_VALIDATE_EMAIL);
        if ($email === false) {
            throw new InvalidArgumentException("Невалидный email: $raw");
        }
        return new self(strtolower($email));
    }
}

// теперь сигнатура — это контракт
public function register(Email $email, Phone $phone): void { ... }

🔵 Что ты получаешь

→ Если в метод пришёл Email, он точно валиден, проверять больше негде и незачем.
→ Нормализация (нижний регистр, тримминг) в одном месте, а не в пятнадцати.
→ readonly гарантирует, что после создания значение не мутирует.
→ Тип говорит за себя: register(Email, Phone) читается без документации.

Value Object уместен везде, где у значения есть правила: деньги, email, телефон, координаты, проценты, диапазоны дат. Везде, где ты ловил баг «а сюда пришла пустая строка», там просился VO.

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

⌨️ Топ-вакансий по PHP за неделю

PHP-разработчик — офис (Екатеринбург) — Ракета

Senior PHP Developer (Streaming Team) — от 4 000 € — удалёнка — Wisebits

PHP Team Lead — 350 000 —‍ 380 000 ₽ — удалёнка — GGSel

➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

🫡 Один и тот же запрос к AI можно выполнить двумя способами — и получить совершенно разный результат.

1️⃣ способ — просто попросить написать код. Модель может сгенерировать рабочее решение, но именно на этапе проверки часто всплывают пропущенные edge case’ы, ошибки обработки или проблемы с тестами.

2️⃣ способ — дать агенту цикл Think → Act → Observe. Он не останавливается после первой попытки: планирует действия, проверяет результат и, если находит ошибку, исправляет её и пробует снова.

Самое интересное, что разница здесь не столько в модели ❕ Claude, GPT или другая LLM могут быть одинаковыми. Разницу создаёт инженерная система вокруг них.

📅 Именно это разберём 23 июля в 19:00 (МСК) на бесплатном вебинаре с Алексеем Жиряковым (Executive Director в Сбере, GenAI Data Platform, ex-CTO Stream и KION).

На живом демо покажем, как один и тот же запрос работает без агентной системы и с ней 🔥

🔗 Регистрация

🏃‍♀️ Proglib Academy

💡 Не передавай Request вглубь приложения

// ❌
class OrderService {
    public function create(Request $request): Order {
        return Order::create([
            'user_id' => $request->user()->id,
            'amount'  => $request->amount,
        ]);
    }
}

// ✅
class OrderService {
    public function create(int $userId, float $amount): Order {
        return Order::create([
            'user_id' => $userId,
            'amount'  => $amount,
        ]);
    }
}

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

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

#vardump

📍 Курс — это не только темы и домашние задания

Во многом его ценность определяет опыт тех, кто его разрабатывает и ведёт.

Об этом как раз новый пост Proglib Academy 🔥

🧑‍💻 Учиться агентной разработке — у тех, кто уже внедряет её в бигтехе

Курс «ИИ для разработчиков» ведут практики из ведущих российских IT-компаний 🔥

🔵 Они прошли путь от первых экспериментов с AI до рабочих процессов, в которых агенты помогают команде писать код, готовить PR и быстрее доводить задачи до продакшена.

В ближайшее время познакомим вас с каждым преподавателем. Программа курса — по ссылке 🎹

🏃‍♀️ Proglib Academy

✏️ Если вы уже работаете с Claude Code, Cursor или Copilot, этот вебинар будет особенно полезен.

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

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

Для человека это естественная часть работы. У Claude Code этого контекста по умолчанию нет — только задача и инструкции, которые ему дали.

Поэтому в большой команде недостаточно просто выбрать хорошую модель.

❗️ Нужно ещё объяснить ей, как у вас устроена разработка: какие подходы приняты, что обязательно проверять и по каким правилам принимать решения.

🗓 23 июля в 19:00 МСК поговорим об этом на бесплатном вебинаре с Алексеем Жиряковым — он Executive Director в Сбере, руководит
GenAI Data Platform, и с этой проблемой сталкивался не раз 🔥

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

🔗 Занять место на вебинаре

🏃‍♀️ Proglib Academy

ℹ️ Полезные команды Composer

Composer — это основной инструмент для управления зависимостями в PHP. Если вы работаете с Laravel, то уже знакомы с такими командами, как composer install и composer update. Однако у Composer есть менее известные, но очень полезные команды, которые могут значительно упростить вашу работу над проектом.

1️⃣ composer outdated

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

2️⃣ composer show

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

composer show backpack/crud

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

3️⃣ composer why

Если вы хотите понять, почему определённый пакет установлен в проекте, используйте команду composer why. Она покажет, какие зависимости требуют установки данного пакета. Это особенно полезно для анализа сложной цепочки зависимостей.

4️⃣ composer licenses

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

5️⃣ composer check-platform-reqs

При работе на разных платформах может возникнуть необходимость убедиться, что все необходимые расширения PHP установлены. Команда composer check-platform-reqs проверяет, соответствует ли ваша система требованиям, указанным в composer.json. Она также проверяет версию PHP и расширения.

❓ Как правильно определять границы сервисов в микросервисах?

Один из недооценённых скиллов в разработке — это умение провести правильную границу между сервисами. Большинство «распределённых монолитов», которые мы встречаем в продакшене, рождаются именно здесь.

Разобрали тему — держи шпаргалку 👇

🔹 Что такое Service Boundary

Это контракт на три вещи:

— за что сервис отвечает;
— какими данными он владеет;
— как он общается с соседями.

Пример: в компании HR не лезет в финансы, а склад не занимается зарплатами. Так же должны работать твои сервисы.

🔹 4 принципа, которые работают

1. Business Capability First

Режь по бизнес-функциям, а не по техническим слоям. OrderService, PaymentService, UserService — потому что именно так бизнес думает о системе.

2. Single Responsibility

Один сервис — одна ответственность. Если в описании сервиса есть союз «и», это уже тревожный звоночек 🚨

3. Data Ownership

У каждого сервиса своя БД. Без исключений. Shared database = shared pain.

4. Loose Coupling

Только API, никакого прямого доступа к чужим таблицам.

🔹 Классический антипаттерн

// ❌ Бизнес-логика смешана в одном сервисе
class BadOrderService
{
    public function processOrderAndPayment(int $id): string
    {
        $order = $this->orderRepository->findById($id)
            ?? 'Order not found';

        $paymentStatus = 'Payment Successful'; // 🚨 чужая ответственность

        return $order . ' | ' . $paymentStatus;
    }
}

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

🔹 Советы из практики

→ Начни с монолита. Не дроби систему заранее. Сначала пойми домен, потом режь по швам.
→ Следи за chatty communication. Если сервис делает 10 вызовов к соседям на каждый запрос — граница явно проведена не там.
→ Изучи DDD. Bounded Context из Domain-Driven Design — лучший инструмент для поиска правильных границ. Инвестиция окупается быстро.