❓ Что делает паттерн Repository?

Repository инкапсулирует доступ к хранилищу и отдаёт доменные объекты, пряча SQL/ORM за интерфейсом-«коллекцией» (find, save, delete).

Доменный код зависит от интерфейса репозитория, а не от конкретной БД, реализацию можно подменить, например на in-memory для тестов.

🙂 До конца июля сохраняются две приятные вещи: специальная цена и бессрочный доступ к материалам курса. Подробнее — в посте 👇

📈 Скоро фраза «умею пользоваться AI» в резюме будет звучать так же странно, как сегодня «умею пользоваться Git»

Это просто станет частью профессии. А вот умение встроить AI в процесс разработки так, чтобы он действительно ускорял работу команды, останется конкурентным преимуществом 💡

🔜 На курсе «ИИ для разработчиков» участники работают со своими проектами и учатся делать AI частью ежедневной разработки: планировать задачи, писать код, проверять изменения, готовить PR и автоматизировать рутину.

До конца июля действует специальная цена — 59 990 ₽ вместо 79 990 ₽ 🥳 И получить бессрочный доступ ко всем материалам курса.

🔗 Посмотреть, как устроен курс

🏃‍♀️ Proglib Academy

❓ Что такое DDD?

DDD (Domain-Driven Design) — подход к проектированию, при котором структура кода отражает структуру бизнес-домена.

Основные строительные блоки:

→ Entity — объект с уникальной идентичностью. Два объекта с одним ID — один и тот же объект, даже если остальные поля разные. Пример: User, Order.

→ Value Object — объект без идентичности, определяется своими атрибутами. Иммутабелен. Пример: Money(100, 'USD'), Email('alice@example.com'). Два Money(100, 'USD') — одно и то же значение.

→ Aggregate — кластер связанных сущностей с одним корнем (Aggregate Root). Все изменения внутри агрегата — только через корень. Граница транзакции = граница агрегата. Пример: Order содержит OrderItems, но только Order — корень.

→ Domain Service — бизнес-операция, которая не принадлежит ни одной сущности. Пример: TransferService(fromAccount, toAccount, amount).

→ Repository — абстракция доступа к хранилищу для агрегатов. Один репозиторий — один агрегат.

→ Domain Event — факт, произошедший в домене. OrderPlaced, PaymentFailed.

→ Bounded Context — явная граница, внутри которой модель имеет единое значение. User в контексте Billing ≠ User в контексте Shipping.

У вас в проекте есть файл вроде utils_v2_final_FIX.py, который все боятся трогать ❓

Что делаете с таким легаси?

❤️ Не трогаю: работает — и ладно
👍 Переписываю с нуля и надеюсь на лучшее
🔥 Сначала покрываю тестами, потом рефакторю по частям
👾 У нас такого нет — честно-честно

На курсе «ИИ для разработчиков» разберём третий подход: как с помощью агента зафиксировать текущее поведение легаси-кода тестами, а затем менять его небольшими безопасными шагами — без одного огромного PR на тысячу файлов.

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

🔗 Занять место со скидкой

🏃‍♀️ Proglib Academy

❓ Отличие Docker от виртуальной машины?

Основное отличие в уровне виртуализации.

Виртуальная машина виртуализирует железо целиком: у неё есть собственная ОС со всеми компонентами, гипервизор, ядро. Это тяжеловесно — VM может весить гигабайты и стартовать минутами.

Docker виртуализирует только уровень приложения. Контейнеры используют ядро хостовой ОС, изолируясь через namespaces и cgroups. Они легковесны — образ может весить десятки мегабайт, запускается за секунды.

🔹 На практике это означает

— Docker быстрее и экономнее по ресурсам.
— VM даёт полную изоляцию и может запускать разные ОС на одном хосте.
— Для микросервисов обычно выбирают Docker, для полной изоляции окружений — VM.

❓ Что такое Idempotency в контексте HTTP и очередей? Как обеспечить?

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

HTTP методы: GET, HEAD, PUT, DELETE — идемпотентны по спецификации. POST — нет.

Для POST-запросов применяется Idempotency Key: клиент генерирует UUID и передаёт в заголовке. Сервер кэширует результат под этим ключом. При повторном запросе возвращает закэшированный ответ, не выполняя операцию повторно.

В очередях: воркер может упасть после обработки задачи, но до подтверждения (ack). Брокер переотправит задачу. Обработчик должен быть идемпотентным — повторная обработка одной и той же задачи не должна создавать дублей.

Техники обеспечения идемпотентности:

— Хранить processed_ids и проверять перед обработкой
— Использовать INSERT IGNORE / ON DUPLICATE KEY в MySQL
— Использовать upsert (INSERT ... ON CONFLICT DO NOTHING в PostgreSQL)
— Проверять состояние перед изменением ("уже оплачен — пропустить")

Идемпотентность — обязательное требование для любого обработчика в распределённой системе с at-least-once delivery.

🎯 У разработчика, DevOps-инженера и техлида разные причины задуматься о системной работе с AI-агентами

Но цель одна: перейти от случайных удачных запусков к управляемому процессу на реальном проекте — с понятными правилами, ревью, контролем расходов и безопасности ✔️

На курсе «ИИ для разработчиков» участники выстраивают такой процесс на практике: подключают инструменты, задают границы для агента и учатся понимать, где ему можно доверять работу, а где требуется проверка.

⚡️ Предзапись на осенний поток уже открыта

🏃‍♀️ Proglib Academy

❓ Использует ли Laravel Symfony?

Да, Laravel широко использует компоненты фреймворка Symfony. Laravel, популярный PHP-фреймворк, использует несколько компонентов Symfony, чтобы предоставить надежную и богатую функциями основу для создания веб-приложений. Некоторые из компонентов Symfony, используемых в Laravel, включают:

HTTP Foundation: этот компонент используется для обработки HTTP-запросов и ответов.

Консоль (Console): командный интерфейс Artisan в Laravel построен с использованием компонента консоли Symfony.

Диспетчер событий (Event Dispatcher): система обработки событий в Laravel работает на основе компонента диспетчера событий Symfony.

Файловая система (Filesystem): компонент файловой системы Symfony используется для операций с файлами.

Внедрение зависимостей (Dependency Injection): Laravel использует контейнер внедрения зависимостей Symfony для управления зависимостями.

❓ Объясни разницу между Gate и Policy в Laravel?

Оба инструмента для авторизации, но с разной областью применения.

Gate — простые одиночные проверки, не привязанные к модели:

// Определяем в AuthServiceProvider
Gate::define('access-admin-panel', function (User $user) {
    return $user->is_admin;
});

// Проверяем
if (Gate::allows('access-admin-panel')) { ... }
// или в контроллере
$this->authorize('access-admin-panel');

Policy — класс с набором правил для конкретной модели:

// php artisan make:policy PostPolicy --model=Post
class PostPolicy
{
    public function update(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }

    public function delete(User $user, Post $post): bool
    {
        return $user->id === $post->user_id || $user->is_admin;
    }
}

// Использование
$this->authorize('update', $post);

Правило выбора

— Нет модели → Gate
— Есть модель, несколько действий → Policy

👅 Самое сложное — выбрать не курс, а направление

Сегодня хочется разобраться в AI-агентах. Через пару недель появляется задача, где нужны алгоритмы. Потом понимаешь, что неплохо бы освежить Python или математику для Data Science.

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

В подписку Proglib Academy входят все основные направления — AI, ML, Python, алгоритмы, математика для DS и другие курсы, а ещё закрытый видеохаб с вебинарами практиков.

Начать можно с пробного месяца. Если решите остаться, его стоимость зачтётся при оформлении подписки 😎

🔗 Узнать подробнее

🏃‍♀️ Proglib Academy