Объектно-ориентированный язык программирования
Публикую продолжение сборника вопросов-ответов с собеседований на Backend-Java-разработчика. В первой части мы прошлись по Java и Spring. А в этой поговрим о Hibernate, базах данных, паттернах и практиках разработки, об одной популярной библиотеке, поддержке и сопровождении наших приложений, а также посмотрим на альтернативные шпаргалки и подведём итоги.
Когда-то я проходил серию собеседований на Backend-Java-разработчика и записывал вопросы себе на будущее, чтобы потом можно было пробежаться и освежить память. Подумалось, что, вероятно, данный сборник будет полезен не только мне, поэтому сдул с него пыль, набросал ответов и делюсь с сообществом. На оригинальность и исключительность не претендую: подобные статьи уже были и на Хабре, и много где ещё — в конце (во второй части) приведу список ссылок, чтобы шпаргалка была максимально полной.
Точно установить сложность всех вопросов не берусь — на разном уровне их потребуется раскрыть с различной степенью подробности. Я написал ответы где-то на плюс-минус middle, щедро приправив ссылками для дальнейших изысканий. На самые популярные вопросы сразу перенаправляю в источники с готовыми ответами. Заодно посмотрим по ссылкам в статье, насколько Хабр может помочь в подготовке к собесам.
Текста получилось много, поэтому пришлось разбить на две части. В первой поговорим про Java и Spring, а обо всём остальном — во второй. Вторая часть тут
Helidon – по гречески ласточка (Χελιδόνι), это такая маленькая птичка из отряда воробьиных с длинными острыми крыльями и характерным двойным хвостом.
Уверен, каждый из нас восхищается полетом и грацией этой птички, а то, как она живет в стаях, чем-то напоминает мир микросервисов.
Helidon для нас, программистов, это набор библиотек прежде всего для разработки микросервисов, и является представителем семейства, назовем его, MicroProfile based средств разработки. Является полностью Open Source проектом, лежит на GitHub, и распространяется под лицензией Apache 2.0.
Перевод подготовлен специально для будущих студентов курса "Разработчик на Spring Framework".
Эта статья о динамическом создании бинов за пять лет стала самой популярной в моем блоге (более 9300 просмотров). Пришло время ее обновить. Также я добавил пример на Github.
Для анализа потоковых данных необходимы источники этих данных. Так же важна сама информация, которая предоставляется источниками. А источники с текстовой информацией, к примеру, еще и редки.
Из интересных источников можно выделить следующие: twitter, vk. Но эти источники подходят не под все задачи.
Есть источники с нужными данными, но эти источники не потоковые. Здесь можно привести следующее ссылки: public-apis.
При решении задач, связанных с потоковыми данными, можно воспользоваться старым способом.
Скачать данные и отправить в поток.
Для примера можно воспользоваться следующим источником: imdb.
Следует отметить, что imdb предоставляет данные самостоятельно. См. IMDb Datasets. Но можно принять, что данные собранные напрямую содержат более актуальную информацию.
Язык: Java 1.8.
Библиотеки: kafka 2.6.0, jsoup 1.13.1.
Когда мы создаем программное обеспечение, мы хотим создавать «-способности»: понятность, ремонтопригодность, расширяемость и - в тренде сейчас - декомпозицию (чтобы мы могли разложить монолит на микросервисы, если возникнет необходимость). Добавьте в этот список свою любимую «способность».
Большинство - возможно, даже все - из этих «возможностей» идут рука об руку с чистыми зависимостями между компонентами.
Если компонент зависит от всех других компонентов, мы не знаем, какие побочные эффекты будет иметь изменение одного компонента, что затрудняет поддержку кодовой базы и еще более затрудняет ее расширение и разложение.
Со временем границы компонентов в кодовой базе имеют тенденцию ухудшаться. Плохие зависимости закрадываются и усложняют работу с кодом. Это имеет всевозможные плохие последствия. В частности, разработка замедляется.
Это тем более важно, если мы работаем над монолитной кодовой базой, охватывающей множество различных областей бизнеса или «ограниченных контекстов», если использовать жаргон Domain-Driven Design.
Как мы можем защитить нашу кодовую базу от нежелательных зависимостей? С тщательным проектированием ограниченных контекстов и постоянным соблюдением границ компонентов. В этой статье показан набор практик, которые помогают в обоих случаях при работе со Spring Boot.
Часто на практике возникает необходимость централизованной обработки исключений в рамках контроллера или даже всего приложения. В данной статье разберём основные возможности, которые предоставляет Spring Framework для решения этой задачи и на простых примерах посмотрим как всё работает. Кому интересна данная тема — добро пожаловать под кат!
Время летит. Не успеваешь моргнуть глазом, а уже вышел очередной релиз Java. В соответствии с графиком (по релизу каждые полгода) комьюнити получило в свое распоряжение Java 15, судьба которой — стать фундаментом для Java 17 LTS (выйдет через год).
В Java постоянно вносятся улучшения, многие из которых были реализованы под влиянием других языков JVM и функционального программирования. Сюда можно отнести такие возможности, как лямбды, ограниченный вывод типов локальных переменных (тип var) и switch-выражения. Scala — особенно богатый источник идей, благодаря инновационному сочетанию в ней объектно-ориентированного и функционального программирования.
Предлагаю рассмотреть, как представленные в новом релизе Java 15 (пока в статусе превью финальной версии) возможности соотносятся с конструкциями в Scala. Мы сосредоточимся на особенностях языка, пропустим улучшения в JVM и доработку стандартной библиотеки. Кроме того, нужно отметить, что некоторые из описанных компонентов уже были доступны в более ранних версиях Java (в виде предварительной или бета-версии).
Всем привет! В своей статье я поделюсь опытом разработки одного из финансовых приложений на Java в ТехЦентре Дойче Банка, расскажу про стек технологий, который мы используем, и каких результатов достигаем
При создании программного обеспечения команды разработчиков обычно определяют набор руководящих принципов и соглашений по разработке кода, которые считаются лучшими практиками.
Это методы, которые обычно документируются и доводятся до сведения всей команды разработчиков, которая их приняла. Однако во время разработки разработчики могут нарушить эти рекомендации, которые обнаруживаются во время ревью кода или с помощью инструментов проверки качества кода.
Поэтому важным аспектом является автоматизация этих директив в максимально возможной степени по всей архитектуре проекта, позволяющая оптимизировать проверки.
Мы можем реализовать эти рекомендации как проверяемые JUnit тесты с помощью ArchUnit. Это гарантирует, что сборка версии программного обеспечения будет прекращена в случае нарушения архитектуры.
Существуют различные способы для написания тестов с использованием Apache Kafka. К примеру, можно использовать TestContainers и EmbeddedKafka. Об этом можно почитать, к примеру, вот здесь: Подводные камни тестирования Kafka Streams. Но существует и вариант для написания тестов с использованием KafkaServer.
Задача интеграции сервисов и различных систем является чуть ли не одной из основных проблем современного IT. На сегодняшний день самым популярным архитектурным стилем для проектирования распределенных систем является REST. Но, как известно, единого стандарта для RESTful сервисов нет, а у кажущейся простоты и свободы есть обратная сторона медали. Не менее важной является задача интеграции систем разными командами или даже компаниями, с которой приходит вопрос об актуальности документации на протяжении жизни всего проекта, и удобного способа передачи потребителю.
Эту проблему отчасти удалось решить при помощи спецификации OpenAPI (OAS 3.0)[1], но все равно часто встает вопрос о правильном применении и подводных камнях кодогенерации, например на языке Java. И можно ли полностью предоставить аналитикам написание функциональных требований, документации и моделей в yml форме для OpenAPI, а разработчикам предоставить возможность только написание бизнес-логики?
Отказ от ответственности (aka disclaimer): все персонажи являются вымышленными, и любое совпадение с реально живущими или когда-либо жившими людьми случайно.
При создании программного обеспечения все мы, как команда, соглашаемся следовать набору рекомендаций, которые обычно считаются лучшими практиками. Но во время разработки разработчики могут нарушить эти правила по незнанию или нежеланию. Обычно мы полагаемся на ревью кода или инструменты проверки качества кода, такие как SonarQube , PMD и т.д. для проверки таких нарушений. Но некоторые из рекомендаций могут быть решениями, которые нельзя автоматизировать с помощью SonarQube, PMD и т.д.
Например, обычно я хочу следовать приведенным ниже рекомендациям для моих приложений на основе Java:
1. Следуйте трехуровневой структуре (уровни веб, сервис, репозиторий), где любой уровень может взаимодействовать только с непосредственным нижним уровнем, а нижний уровень не должен взаимодействовать с верхним уровнем. т.е. веб-уровень может взаимодействовать с уровнем сервиса, уровень сервиса может взаимодействовать с уровнем репозитория. Но уровень репозитория не может взаимодействовать с сервисным или веб-уровнем, сервисный уровень не может взаимодействовать с веб-уровнем.
2. Если приложение большое, мы могли бы захотеть следовать структуре Package-By-Feature, где только компоненты Web и Service являются public, а остальные компоненты должны быть package-private.
3. При использовании внедрения зависимостей Spring не используйте внедрение на основе поля и предпочитайте внедрение на основе конструктора.
Таким образом, может быть много правил, которым мы хотим следовать. Хорошая новость заключается в том, что мы можем проконтролировать выполнение этих рекомендаций с помощью JUnit тестов с использованием ArchUnit.
Сегодня поговорим об секьюрити в web (да, наверное, и не только) приложениях. Прежде чем описывать подходы и фреймворки расскажу небольшую предысторию.
За много лет работы в IT приходилось сталкиваться с проектами в самых разных сферах. У каждого проекта были свои требования к безопасности. Если в части аутентификации все было более-менее одинаково с точки зрения требований, то способы реализации механизма авторизации получались довольно разными от проекта к проекту. Каждый раз авторизацию приходилось писать практически с нуля под конкретные цели проекта, разрабатывать архитектурное решение, потом дорабатывать с изменением требований, тестировать, и т.д. — все это обычный процесс, которого не избежать в разработке. С каждой реализацией очередного такого архитектурного подхода все больше складывалось ощущение, что можно придумать какой-то общий подход, который будет покрывать основные цели авторизации и который можно будет использовать повторно в других приложениях. В данной статье будет рассмотрен обобщенный архитектурный подход к авторизации на примере разработанного фреймворка.
Как обычно, прежде чем разрабатывать что-то новое нужно определиться с тем, какие проблемы будут решаться, чем фреймворк будет удобен и полезен и, возможно, уже есть готовое решение (об этом поговорим после).
Всем известны два стиля написания кода — императивный и декларативный. Императивный стиль описывает то, как получить результат, декларативный — что требуется получить в результате.
Spring Mock-MVC может быть отличным способом протестировать Spring Boot REST API. Mock-MVC позволяет нам тестировать обработку запросов Spring-MVC без запуска реального сервера.
Я использовал тесты Mock-MVC в различных проектах, и по моему опыту они часто бывают довольно многословными. Это не должно быть плохо. Однако это часто приводит к копированию / вставке фрагментов кода в тестовые классы. В этом посте мы рассмотрим несколько способов очистки тестов Spring Mock-MVC.