🤼 Генеративно-состязательная нейросеть: ваша первая GAN-модель на PyTorch

Подробная инструкция построения генеративно-состязательных нейросетей (GAN) на примере двух моделей, реализованных с помощью фреймворка глубокого обучения PyTorch в нашей статье. 👇

🔗 Статья

У нас есть курс как для начинающих программистов, так и для тех, кто уже шарит:
🔵 Алгоритмы и структуры данных

ℹ️ Как работает 𝐠𝐑𝐏𝐂

gRPC (Google Remote Procedure Call) — это современный фреймворк с открытым исходным кодом, разработанный компанией Google для эффективной и масштабируемой коммуникации между микросервисами. Он основан на RPC (удалённый вызов процедур) и используется для построения распределённых систем и микросервисных архитектур.

Выше показана диаграмма, иллюстрирующая общий поток данных для 𝐠𝐑𝐏𝐂.

Шаг 1: Клиент отправляет REST-запрос, обычно в формате JSON.

Шаги 2 - 4: Сервис заказа (клиент gRPC) получает REST-запрос, преобразует его и делает RPC-вызов к сервису оплаты. gPRC кодирует клиентский stub в бинарный формат и отправляет на транспортный уровень.

Шаг 5: gRPC передаёт пакеты по сети через HTTP/2. Благодаря бинарному кодированию и сетевым оптимизациям gRPC работает в 5 раз быстрее, чем JSON.

Шаги 6 - 8: Сервис оплаты (сервер gRPC) получает пакеты, декодирует их и вызывает серверное приложение.

Шаги 9 - 11: Результат возвращается с серверного приложения, кодируется и передаётся на транспортный уровень.

Шаги 12 - 14: Сервис заказа получает пакеты, декодирует их и отправляет результат клиентскому приложению.

💬 Вы использовали gRPC в своём проекте?

🕯 Паттерн Цепочка обязанностей (Chain of Responsibility)

Chain of Responsibility — это поведенческий паттерн, который позволяет передавать запросы по цепочке обработчиков, пока один из них не обработает запрос. Каждый обработчик в цепочке решает, может ли он обработать запрос или передать его следующему по цепочке.

Использование:

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

Преимущества:

1️⃣ Ослабляет связанность между объектами, отправляющими запросы, и объектами, обрабатывающими их.
2️⃣ Позволяет динамически добавлять новые обработчики в цепочку.
3️⃣ Способствует соблюдению принципа единственной ответственности, позволяя каждому обработчику заниматься своей задачей.

Недостатки:

1️⃣ Может быть сложнее отслеживать, кто в конечном итоге обработал запрос, особенно при длинных цепочках.
2️⃣ Не гарантирует, что запрос будет обработан, если ни один из обработчиков не способен это сделать.
3️⃣ Может усложнить структуру программы при использовании большого числа обработчиков.

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

💥 Волшебные методы в Spring Data JPA: как создаются под капотом.

В продолжение прошлого поста, рассмотрим как этот механизм работает под капотом. Spring Data JPA позволяет создавать методы в репозиториях, которые генерируют запросы на основе имени метода. Под капотом этот механизм строится на строгой интерпретации имени метода, динамическом создании запросов и использовании JPA Criteria API или JPQL.

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

1️⃣ Парсинг имени метода: PartTree

Класс PartTree (пакет org.springframework.data.repository.query.parser) играет ключевую роль в анализе имени метода. Когда репозиторий загружается в контексте Spring, каждый метод проверяется на соответствие предопределённым шаблонам. Основной принцип парсинга — разбиение имени метода на логические части (поля сущности, операторы и ключевые слова).

Пример метода:

findByFirstNameAndLastName(String firstName, String lastName).

PartTree разбивает это имя на части: findBy (операция), FirstName (поле), And (оператор), LastName (второе поле).

В результате класс PartTree создаёт синтаксическое дерево условий, которые затем будут преобразованы в SQL.

2️⃣ Генерация SQL-запросов: QueryLookupStrategy

После того как имя метода распознано, Spring Data JPA использует стратегию поиска запроса через QueryLookupStrategy (пакет org.springframework.data.repository.query). Этот класс отвечает за выбор подходящей стратегии для преобразования метода в SQL-запрос, что делает работу с запросами гибкой и удобной. Стратегии могут быть следующими:

- CREATE: Автоматически создаются запросы на основе имени метода (например, findBy, countBy и т.д.).
- USE_DECLARED_QUERY: Использует явно объявленные запросы (например, через аннотации @Query).
- CREATE_IF_NOT_FOUND: Попытка использовать явный запрос, а если он не найден — создать запрос динамически.

Если метод соответствует заранее определённым правилам (например, начинается с findBy), Spring Data JPA создаст запрос автоматически. Методы динамического создания запросов используют API JpaQueryCreator, который формирует запросы на основе дерева условий, построенного с помощью PartTree. Это дерево представляет собой структуру, которая разбивает имя метода на логические части (поля, операторы и условия) и преобразует их в SQL-запрос.

3️⃣ Конструирование запроса через JPA Criteria API или JPQL

В зависимости от сложности запроса и доступных данных, Spring решает, использовать ли для запроса JPA Criteria API или JPQL. Более простые запросы генерируются с помощью JPQL, для более сложных выбирается Criteria API. Каждый метод в репозитории после парсинга передаётся в CriteriaBuilder, который строит запрос на основе условий.

Пример генерации запроса с использованием Criteria API:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<User> query = cb.createQuery(User.class);
Root<User> user = query.from(User.class);

Predicate firstNamePredicate = cb.equal(user.get("firstName"), firstName);
Predicate lastNamePredicate = cb.equal(user.get("lastName"), lastName);

query.where(cb.and(firstNamePredicate, lastNamePredicate));
List<User> result = entityManager.createQuery(query).getResultList();

Этот код создаёт SQL-запрос, эквивалентный:

SELECT * FROM users WHERE first_name = ? AND last_name = ?

▪️ Операторы и ключевые слова

Spring Data JPA поддерживает большое количество операторов, таких как And, Or, GreaterThan, LessThan, Between, Like и другие. Каждый оператор обрабатывается в классе QueryCreator, где он преобразуется в соответствующее условие JPA Criteria API или JPQL.

Пример обработки оператора Between:

if (part.getType() == Part.Type.BETWEEN) {
    predicates.add(cb.between(root.get(part.getProperty()), minValue, maxValue));
}

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

SELECT * FROM users WHERE age BETWEEN ? AND ?

▪️ Работа с коллекциями

Для работы с коллекциями Spring Data JPA использует оператор IN. Например, метод findByRoleIn(List<String> roles) будет преобразован в запрос с IN оператором.

Пример кода:

Predicate inPredicate = cb.in(user.get("role")).value(roles);
query.where(inPredicate);

Этот запрос эквивалентен:

SELECT * FROM users WHERE role IN (?, ?, ...)

4️⃣ Передача запроса в EntityManager

Когда запрос полностью построен, он передаётся в EntityManager, который занимается выполнением SQL-запроса и возвратом результата.

🔗 Документация: JpaRepository, PartTree, QueryLookupStrategy, JpaQueryCreator, EntityManager, Criteria API

ℹ️ Как работает Pageable в Spring?

Pageable — это мощный инструмент в Spring Data для работы с большими объемами данных, который позволяет разделить результат на страницы. Это оптимизирует память и улучшает производительность.

Вместо загрузки всех записей, например через findAll(), мы можем запросить только определенное количество данных (порции/страницы) и продолжать загружать по мере необходимости. Интерфейс Pageable создает запрос с параметрами LIMIT и OFFSET, что позволяет базе данных возвращать только нужные записи, начиная с определенного места.

🔵 Пример использования:

▪️ Репозиторий:

public interface UserRepository extends JpaRepository<User, Long> {}

▪️Сервис:

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    public Page<User> getUsersByPage(int page, int size) {
        Pageable pageable = PageRequest.of(page, size, Sort.by("name").ascending());
        return userRepository.findAll(pageable);
    }
}

Здесь PageRequest.of(page, size, Sort) создает объект Pageable, который указывает, какую страницу и сколько записей нужно получить, а также сортирует результат по имени в порядке возрастания.

▪️ Контроллер:

@RestController
public class UserController {

    @Autowired
    private UserService userService;

    @GetMapping("/users")
    public Page<User> getUsers(
        @RequestParam(defaultValue = "0") int page,
        @RequestParam(defaultValue = "20") int size) {
        return userService.getUsersByPage(page, size);
    }
}

Этот эндпоинт позволяет запрашивать данные по страницам. Например, /users?page=1&size=20 вернет вторую страницу с 20 записями.

🔵 Преимущества использования Pageable:

- Экономия памяти: Мы загружаем только небольшие порции данных.
- Легкость навигации: Можно переключаться между страницами.

🔵 Недостатки использования Pageable:

- Дополнительный запрос для подсчета записей: Spring Data выполняет запрос для получения общего числа записей.
- Ограниченная гибкость: При сложных запросах с множеством фильтраций и джоинов Pageable может быть не таким гибким, как ручные запросы с LIMIT и OFFSET.

⚠️ Важно: Пагинация удобна для больших объемов данных, но если данные постоянно обновляются, возможны проблемы с консистентностью между страницами. Записи могут дублироваться или пропадать.

🎮 API архитектурные стили

🔗 REST – популярный подход для публичных API и веб-приложений, поддерживает JSON, XML, HTML и текст.
🔗 SOAP – использует структуру сообщений с оберткой на основе XML. Применяется в платежных системах и телеком-сервисах, но имеет высокий порог входа.
🔗 GraphQL – гибкая схема и система типов, позволяет использовать JSON и подходит для сложных систем и мобильных API.
🔗 gRPC – высокопроизводительный фреймворк RPC, работает через протоколы сериализации, используется для высоконагруженных систем.
🔗 WebSocket – поддерживает двустороннюю связь, подходит для чатов и других приложений реального времени.
🔗 Webhook – асинхронный подход, применим для CI/CD процессов и платежных шлюзов.

📊 Paging vs. Segmentation

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

🔹 Пагинация:

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

Преимущества:
- Устраняет внешнюю фрагментацию.
- Облегчает работу с виртуальной памятью и перемещением страниц.
- Управление памятью становится более простым и эффективным.

🔹 Сегментация:

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

Преимущества:
- Обеспечивает логическое разделение кода и данных.
- Упрощает защиту и обмен сегментами.
- Поддерживает управление растущими структурами данных.