Объектно-ориентированный язык программирования
Kafka, в отличие от реляционных баз данных, является молодой технологией, и потому инструментарий для автоматического тестирования приложений, созданных на базе этой платформы, был доступен разработчикам с самого начала. Хотя на первый взгляд с этим инструментарием всё обстоит очень хорошо — бери и пиши тесты! — на практике приходится сталкиваться с трудностями, о которых хочу поведать в этом посте.
Примеры для двух неблокирующих библиотек доступа к SQL базам данных — Vert.X SQL и R2DBC. Примеры будут основаны на PostgreSQL и реактивных обертках Java.
Начнем с главного: JDBC — это отличный стандарт. Служил и служит верой и правдой.
Но новые веяния просят новых решений. И даже есть смысл иногда потеснить JDBC.
Я предлагаю взглянуть на две альтернативных реализации доступа к SQL базам из JVM приложений и их (реализаций) применимости.
В статье будет теоретическая часть, практические примеры и в конце немного сравнения. Кому интересна практическая часть — просто перематывайте текст, к конкретной реализации теория отношение имеет весьма посредственное.
В 2018-м году, работая в Akvelon Inc., я собеседовал одного человека. Перед интервью мне дали на проверку его тестовое задание: небольшое web-приложение по типу записной книжки или todo-списка – React\TypeScript, C# на бэке и MS SQL Server в качестве персистентного хранилища. Приложение было модное: с обилием unit-тестов на mock’ах, упакованное в docker-образ – видно, что человек старался. И у этого решения был всего один недостаток – оно не работало. Совсем. Падало при попытке сохранить новую строку в базу данных.
Этот случай мне очень хорошо запомнился, поскольку подсветил сразу несколько типовых проблем.
Первая из них – ложная уверенность от модульных тестов. Даже 100% покрытие кода тестами не гарантирует, что в нём нет ошибок.
И вторая – отсутствие функциональных тестов. Если ваше приложение работает с СУБД, то вы обязательно должны покрыть эту часть кода реальными тестами с реальной базой данных. И здесь есть очень важное условие: проверять нужно именно на той версии СУБД, которая работает у вас в production’е. Думаю, очень многие разработчики под Oracle, прогоняющие свои тесты на H2\HSQLDB, сталкивались с ситуацией, когда тесты проходят, а production не работает (boolean, group by и другие чудеса).
Сейчас я работаю в основном с PostgreSQL и мигрирую наши микросервисы с 10-й версии на 11-ую. В процессе миграции (и разработки вообще) я столкнулся с несколькими нюансами, о которых хотелось бы рассказать.
Представляю перевод статьи автора Evan Cameron, которая может помочь Java разработчикам лучше понять отличия и схожесть этих двух языков — оригинал на сайте автора. Не считая себя достаточно опытным Rust разработчиком, я вряд ли смогу аргументированно участвовать в возможных дискуссиях.
В данной статье я хочу описать свой опыт по доставке Graal Native Image конечным пользователям Mac OS и Linux в одну команду при помощи Travis CI.
Когда я столкнулся с данной задачей, я ощутил нехватку информации по этой теме, поэтому я решил описать свой опыт здесь.
Пожалуй начнем.
У меня есть:
Что хочу получить:
Сопоставление с образцом (Pattern Matching) — новая превью функция в Java 14.
Чтобы лучше понять эту новую функцию, давайте посмотрим, как работает оператор instanceof. Если вы уже знакомы с ним, не стесняйтесь переходить к следующему разделу.
Короче говоря, он проверяет, принадлежит ли данный объект заданному типу. В результате этой проверки он возвращает либо true, либо false.
if(animal instanceof Cat) {
// It is a cat! Do something
} else {
// It is not a cat, do something else
}Этот оператор возвращает true, если ваш объект имеет данный тип или его подтип. В противном случае возвращается false.
Вы можете использовать эту статью, чтобы понять, как использовать Spring MVC для создания веб-сайтов или RESTful сервисов. А также получить обзор часто задаваемых вопросов, охватывающих наиболее распространенные задачи Spring MVC.
Примечание: Статья ~ 7500 слов, вероятно, не стоит читать ее на мобильном устройстве. Добавьте ее в закладки и вернитесь позже.
Упрощает? Но как?
Всем, привет!
В статье я хотел бы рассказать об одном из подходов к логированию приложения, который сильно помогал мне и коллегам при отладке, поиске ошибок и анализе проблем производительности. Про необходимость логирования было написано множество хороших статей в том числе и на Хабре, поэтому здесь нет большого смысла повторяться. Я начинал карьеру в IT с Oracle и изучал эту БД по книгам главного эксперта — Тома Кайта. Мне запомнилась его фраза по поводу логирования из книги "Effective Oracle by Design":
Instrumentation is not overhead. Overhead is something you can remove without losing much benefit. Removing (or not having) instrumentation takes away considerable functionality. You wouldn’t need to do this if your systems never break, never need diagnostics, and never suffer from performance issues. If that is true, you don’t need to instrument your system (and send me your email address, because I have a job offer for you).
С работой над Oracle проектами всё и началось.
Здесь есть все, что вам нужно знать о различных версиях и функциях Java.
Java 8, Java 11, Java 13, Java 14 — какая разница?
Вы можете использовать это руководство, чтобы получить практическую информацию о том, как найти и установить последнюю версию Java, понять различия между дистрибутивами Java (AdoptOpenJdk, OpenJDK, OracleJDK и т.д.), А также получить обзор возможностей языка Java, включая версии Java 8-14.
Примечание переводчика
17 февраля был опубликован перевод Руководство по версиям и возможностям Java
В комментарии к нему Julegg написал
Там у Марко уже описание java-14 добавилось. Будет ли тут перевод добавлен?
Вашему вниманию предлагается обновленная версия руководства от 09 апреля 2020 г.
Однажды я работал над проектом, задачей которого было создание утилиты для экзаменации. Один пользователь создает вопросы, объединяет их в тест, устанавливает какие-то правила типа времени на исполнение, как подсчитывать баллы. А другой пользователь просто открывает и отвечает на вопросы. Кроме прочего, стояла задача реализовать возможность перемешать последовательность вопросов, но так, чтобы для определенного пользователя она была такой же, как при первом открытии.
Задача довольно простая и решили её у нас быстро. А решение было следующим: У нас есть n вопросов. Из комбинаторики мы знаем, что если у нас есть n > 1 элементов, мы, переставляя элементы местами, можем получить разные последовательности этих элементов, где максимальное число отличающихся последовательностей равно . Вот и было решено, пишем значит функцию, посчитаем там факториал, сгенерируем n-ную последовательность, а само число n сгенерируем рандомно и запишем в БД. Хренак-хренак и в продакшен отправляем тестерам. И вроде бы все нормально, но ведь не случись что-то непредвиденное, этой статьи бы не было.
Эй, как насчет интерактивной командной оболочки с автодополнением, помощью и прочим? И без заморочек да еще и на JVM?
Головной болью на работе для меня стал Postman. Хотя на словах мы все TDD и по красному огоньку Cucumber видим, что именно сломалось, но на практике приходилось мне гораздо чаще слать REST запросы в интерфейсе Postman. При начале работы надо было получить токен аутентификации (запрос на создание и запрос на валидацию, пользователи разные), а потом скакать по закладкам, править параметры и запускать уже другие запросы. Клик-клик-клик. В разном порядке. Уж я и скрипты с cURL писал, и в IDEA запросы оформлял — не удобно. Идеальный мотиватор для перехода на автоматические тесты, вот только это были запросы на получение понимания, что происходит в какой-то уникальный момент сочетания состояния сервиса, его версии, мейнфреймов за ним, погоды в доме и уж точно под регрессионное тестирование не попадали. Клик-клик-клик стал съедать слишком много времени и накручивал километраж мышки.
И тут на глаза мне попался проект Spring Shell, который запускает свой shell в консоли и выполняет команды, написанные в терминах Spring. Давно оценив преимущества командной строки, я сразу взялся за решение своей проблемы. Сказать, что результатом я остался доволен — это преуменьшение. Под катом — абстрактный проект для демонстрации возможностей shell, который навеян моим опытом. Чтобы сделать совсем красиво, я добавил плюшек с еще одним малоизвестным проектом — Spring State Machine. Может показаться, что конечные автоматы — это для седых профессоров, но реальность такова — на них, например, написаны корутины в Kotlin, а всякие Akka их несут в "массы" еще дольше. Я коснусь State Machine совсем поверхностно, только чтобы разогреть аппетит.
