Список статей

В статье Обработка запросов с помощью GraphQL мы рассмотрели основные вопросы, связанные с выполнением запросов в GraphQL. До этого момента мы составляли запросы вручную в формате json и напрямую кидали их на сервер. Но не всегда под рукой есть удобный инструмент для выполнения POST-запросов. Кроме того, вы можете в принципе не знать, какие поля и методы GraphQL доступны на сервере. Поэтому к GraphQL можно прикрутить один из нескольких веб-интерфесов, который позволит выполнять тестовые запросы в наглядном виде.

Подключение Playground к проекту

Для примера возьмём такой инструмент как Playground. Просто добавим ещё одну зависимость playground-spring-boot-starter в уже существующий проект, который мы создали в прошлой статье.

GraphQL - это стандарт клиент-серверного взаимодействия, который позволяет довольно гибко запрашивать данные с сервера. Основное отличие от традиционных REST-запросов состоит в том, что клиент сам выбирает, какие поля он будет запрашивать у сервера, тогда как REST предполагает заранее определённый фиксированный формат. При этом сервер будет подгружать из хранилища ровно те поля, которые необходимы и ничуть не больше.

Среди других алгоритмов сортировки «пузырьковая» является самой медленной. Однако при этом алгоритм достаточно прост для понимания. На практике вместо него используют другие алгоритмы сортировки. Про пузырьковую сортировку любят рассказывать при обучении программированию и любят спрашивать на собеседованиях.

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

Как известно, формат xml нечувствителен к отступам и пробелам между тэгами. Поэтому с целью уменьшения объема данных и без того многословный xml можно записать в одну строку. Тогда вы получите заметное уменьшение объёма, но при этом такой формат будет сложно просматривать.

Чтобы сделать его удобочитаемым, мы можем написать специальный метод, который будет считывать исходный xml, форматировать его по определённым правилам и возвращать новый xml в виде строки. Форматирование будем производить без сторонних библиотек стандартными средствами JDK.

Рассмотрим следующий пример на kotlin:

Во многих редакторах при работе с текстовым документом вы можете видеть, сколько всего строк содержится в этом файле. Строки между собой разделяются символом перевода строки, который в каждой операционной системе (Windows, Unix, Mac) свой.

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

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

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

Зачем нужно проверять вложенность скобок

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

Первое, что приходит в голову, это подсчитать количество открывающих и количество закрывающих скобок в строке и если эти числа равны, то считать, что последовательность скобок правильная. Возможно, это и будет работать в самых простых случаях, однако последовательность «(())» будет правильной, а последовательность «())(» - неправильной. При этом количество открывающих и закрывающих скобок у них одинаковы. Кроме того, скобки могут быть разных типов (круглая, фигурная, квадратная и т.п.) и скобки должны соответствовать ещё и по типу. Поэтому в основе такой проверки должна лежать работа со стеком.

Контрольная сумма от набора байт позволяет убедиться в том, что данные на клиенте, полученные от сервера, являются корректными. Для этого вместе с файлом сервер может предоставлять контрольную сумму для проверки на клиентской стороне. Существует несколько алгоритмов вычисления контрольной суммы, рассмотрим самые популярные: md5, sha-256, sha-512 и crc-32.

Вычисление md5 с помощью MessageDigest

В пакете java.security есть такой класс как MessageDigest. Он позволяет получить одну из встроенных реализаций алгоритма вычисления контрольных сумм. Поэтому сначала реализуем метод, который абстрагирован от конкретного алгоритма и работает с любым MessageDigest одинаково.

Сегодня, 16 марта 2021 года, состоялся релиз новой версии Java 16. Давайте рассмотрим новые конструкции языка, которые в предыдущих версиях находились в статусе preview, а теперь доступны «из коробки» без каких-либо дополнительных настроек.

Установка

Для установки openjdk версии 16 через apt на Ubuntu-подобные системы можно выполнить следующие команды:

Если у вас проект на maven, то для успешной сборки с новой версией Java добавьте в pom.xml следующие параметры:

Теперь можно перейти к обзору новых фич.

В статье CrudRepository на Kotlin я рассказывал о том, как Spring Data позволяет быстро создавать слой взаимодействия с БД, поддерживающий все основные операции: создание, чтение, обновление и удаление. Для получения этой стандартной функциональности вам достаточно лишь определить класс-сущность, поля которой такие же как и в целевой таблице в БД, и интерфейс самого репозитория, который можно унаследовать от стандартного интерфейса CrudRepository. Реализовывать интерфейс при этом не нужно - Spring Data всё сделает за вас.

Помимо стандартных методов вы также можете добавить в этот интерфейс свои собственные. Причём если вы будете следовать соглашениям об именовании методов, то Spring Data будет автоматически генерировать по ним sql-запросы. То есть вы определяете запросы к БД в декларативном стиле. Это, во-первых, позволяет давать методам удобочитаемые имена, а во-вторых, позволяет абстрагироваться от конкретной СУБД и специфики написания запросов к ней.

Ранее я уже писал статью CrudRepository в Spring Data, в которой рассматривался пример rest-сервиса, работающего с базой данных. Теперь хочу показать аналогичный пример, но вместо Java написать его на Kotlin, который стремительно набирает популярность. Rest-сервис состоит из трёх слоёв: слой работы с БД, сервисный слой и контроллер. Мы пойдём последовательно по слоям, начиная с нижнего.

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

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

Заготовку проекта удобно сгенерить через Spring Initializr. Там достаточно выбрать тип проекта - gradle, язык - kotlin. В качестве dependency надо добавить Spring Web (функциональность rest-контроллеров), Spring Data JPA (работа с БД), Validation (валидация входящих rest-запросов) и PostgreSQL Driver (драйвер нашей СУБД). Затем нажимаем Generate - и вы уже скачали архив с заготовкой вашего проекта. В итоге файл build.gradle.kts в секции dependencies помимо стандартных должен также содержать следующие зависимости: