• Системе контроля версий Git исполнилось 15 лет.
  
• Testcontainers исполнилось целых пять лет! Testcontainers — это Java-библиотека, позволяющая делать легкие одноразовые экземпляры популярных баз данных, веб-браузеров Selenium, или чего угодно ещё, что можно запустить в Docker-контейнере.
  
• Вышел долгожданный Spring Graal Native 0.6.0. Вот здесь на GitHub есть огромное количество примеров использования вместе с разными технологиями, например, Kotlin и Netty.
  

Добрый день!

Не так давно вышла новая Java 14. Среди многих интересных фич меня заинтересовала одна, а именно упаковщик jpackage (пока в инкубаторе).

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

Описание, как пользоваться инструментом, есть в статье.

Поиграв с упаковщиком, мне захотелось попробовать внедрить его на своем pet-проекте.

Всем привет!

Я сделал перевод и набил субтитры на знаменитый доклад Рича Хикки — Simple Made Easy (Простое сделать лёгким). Впервые на русском языке.

Доклад впервые был представлен в 2011 году на конференции Strange Loop.

Всем привет! Про Cucumber есть много статей на Хабре и в интернете, но хочется вставить свои пять копеек.

В прошлом году наши эксперты, занимающиеся автотестами под Android, объединились с коллегами из других компаний и создали фреймворк для автотестирования Kaspresso. В сентябре они представили его на «Хабре» (пост, в котором они объясняют, что сделали и зачем). За полгода существования Kaspresso воспользовались тысячи людей, и у многих возникали те или иные вопросы про фреймворк и инфраструктуру в целом. Мы заметили, что часто эти вопросы повторяются, и подумали, что на них хорошо бы ответить централизовано.

Привет, Habr! Я учусь на программиста в Питерском Политехе. Одно из моих заданий в курсовой работе было написание консольной утилиты. Решил поделиться своим небольшим опытом.

Для начала представлю вам саму формулировку задания, которое мне необходимо было выполнить:

Реализовать сжатие RLE (run-length encoding). Продумать алгоритм сжатия и формат файла, при котором сжатие «неудачных» данных не приводит к большому увеличению размера файла.

Command Line: pack-rle [-z|-u] [-out outputname.txt] inputname.txt

Упаковывает -z или распаковывает -u указанный в аргументе командной строки текстовый файл. Выходной файл указывается как -out outputname.txt, по умолчанию имя формируется из входного файла с добавлением расширения.

Кроме самой программы, следует написать автоматические тесты к ней.

Сам алгоритм:

Кодирование длин серий (англ. run-length encoding, RLE) или кодирование повторов — алгоритм сжатия данных, заменяющий повторяющиеся символы (серии) на один символ и число его повторов. Серией называется последовательность, состоящая из нескольких одинаковых символов. При кодировании (упаковке, сжатии) строка одинаковых символов, составляющих серию, заменяется строкой, содержащей сам повторяющийся символ и количество его повторов.

Строка: WWWWWWWWWBBBWWWWWWWWWWWWWWWWWWWWWWWBWWWW
Превращается в строку: 9W3B24W1B4W
Однако я чуть улучшил алгоритм, убрав добавление 1 перед одиночным символом, чтобы избежать ситуации, когда сжатая строка длиннее исходной. («TBTB» -> «1T1B1T1B» «TBTB»)

Очень часто за свой 15летний опыт работы разработчиком ПО и тимлидом я сталкиваюсь с одним и тем же. Программирование превращается в религию — редко кто пытается внедрять технологии на основе разумного выбора, аргументированно, с учетом ограничений, возможностей переносимости, оценки степени привязки к вендору, реальной цены, перспектив технологии и свободы лицензий. Разработчики ходят на конференции или читают посты — заводятся на хайповость, а их ИТ директоров и менеджеров кормят не только сказками о светлом аджайл будущем на мероприятиях различные визионеры, сейлы и консалтеры. И получается что технологии оказались в проекте не с учетом удобства разработки и внедрения, нефункциональных требований проекта, а потому что это хайпово и google у себя использует, amazon рекомендует(хотя их вакансии говорят что сами не часто используют) или принято высочайшее решение руководства компании внедрять «это».


Но особое веселье — это выбор базы данных. Чем больше объемы хранимой информации, сложнее структуры данных в проекте и их изменения/эволюция, выше требования ко времени отклика или производительности тем дороже стоит ошибка выбора в начале на поздних стадиях проекта.

Данная статья будет полезной тем, кто только начал знакомиться с микросервисной архитектурой и с сервисом Apache Kafka. Материал не претендует на подробный туториал, но поможет быстро начать работу с данной технологией. Я расскажу о том, как установить и настроить Kafka на Windows 10. Также мы создадим проект, используя Intellij IDEA и Spring Boot.

И снова здравствуйте. Несколько дней назад началось обучение в новой группе по курсу «Архитектор ПО», а сегодня мы хотели бы поделиться статьей, которую написал один из студентов курса — Плешаков Антон (руководитель направления разработки в компании «Программная логистика» и co-founder в Clusterra).

---

В настоящее время распределенные микросервисные системы стали фактически промышленным стандартом, причем не только в мире энтерпрайза. Преимущества использования распределенных систем описывались и обсуждались уже неоднократно. Плюсы микросервисов всем давно известны: технологии под задачу, composability, scalability, масштабирование разработки, снижение TTM и так далее. Очевидно что разработка распределенных приложений дает больше опций для своевременной реакции на растущие запросы бизнеса и цифровизацию всего вокруг.

Важно также отметить, что на текущий момент очень важным фактором, влияющим на выбор стратегии разработки в пользу микросервисов, является — наличие всевозможных готовых инфраструктурных решений, берущих на себя решение проблем, связанных с дополнительными издержками на эксплуатацию распределенной системы. Речь идет о системах контейнерной оркестрации, service mash, средствах распределенной трассировки, мониторинга, логирования и прочее прочее. Можно смело утверждать что большинство факторов, ранее упоминавшихся как минусы микросервисного подхода, на сегодняшний день не имеют такого большого влияния, как пару лет назад.

Недавно я наткнулся на статью о проблеме c Java-сериализацией объектов в Kotlin. Автор предложил решать её добавлением метода readResolve к каждому объекту, который наследуется от java.io.Serializable.

Этот способ выглядит абсолютно правильным, однако его поддержка может оказаться слишком проблематичной. С учетом того, что в нашем проекте эта проблема возникала только при использовании объектов внутри Bundle, мы решили использовать проверку через is для каждой ветки when-выражений в случае sealed классов.

Тем не менее, размышляя об этом, я никак не мог понять, почему Kotlin не генерирует readResolve в компиляторе, поддерживая singleton-свойства объектов. Мне казалось, что это работа для инструментов, а не для человека. Но раз Kotlin не добавляет эту функцию сам, мы можем ему помочь! Этим мы сейчас и займёмся.

Всем привет. На связи Владислав Родин. В настоящее время я являюсь руководителем курса «Архитектор высоких нагрузок» в OTUS, а также преподаю на курсах, посвященных архитектуре ПО.

Помимо преподавания, как вы могли заметить, я занимаюсь написанием авторского материала для блога OTUS на хабре и сегодняшнюю статью хочу посвятить запуску нового потока курса «Алгоритмы для разработчиков».

---

Введение

Хеш-таблицы (HashMap) наравне с динамическими массивами являются самыми популярными структурами данных, применяемыми в production'е. Очень часто можно услышать вопросы на собеседованиях касаемо их предназначения, особенностей их внутреннего устройства, а также связанных с ними алгоритмов. Данная структура данных является классической и встречается не только в Java, но и во многих других языках программирования.

Обзор

Здравствуйте! В этой статье я хочу описать программу валидации XML с помощью Spring Framework. Наиболее очевидная область применения такой валидации — это программирование web-сервисов.

Валидация производится через преобразование XML-Java (unmarshalling) по соответствующей XSD-схеме. XML-файл считается прошедшим проверку, если преобразование XML в объект Java прошло успешно.

Проект компилируется в jar файл и запускается в командной строке. Для красоты прикручен Apache ANSI Printer, в котором можно задавать шрифт, цвет и выделение текста в cmd.

Исходный код доступен в GitHub по ссылке XmlProcessor.

Всем привет! С вами второй пост из нашей серии по Quarkus – сегодня поговорим о нативной компиляции. (Кстати, смотрите наш вебинар «Это Quarkus – Kubernetes native Java фреймворк». Покажем, как начать «с нуля» или перенести готовые решения)



В предыдущем – первом – посте из серии про сверхбыструю субатомную Java мы рассказали о том, как этот фреймворк объединяет модели императивного и реактивного программирования на базе единого реактивного ядра.

Quarkus – это Java-стек, заточенный под Kubernetes. И хотя здесь, конечно, многое еще предстоит сделать, мы хорошо проработали массу аспектов, включая оптимизацию JVM и целого ряда фреймворков. Одной из особенностей Quarkus, вызвавшей повышенный интерес со стороны разработчиков, стал комплексный бесшовный подход к превращению Java-кода в исполняемые файлы для конкретной операционной системы (так называемая «нативная компиляция») по аналогии с C и C ++, где такая компиляция обычно происходит в конце цикла, состоящего из сборки, тестирования и развертывания.

В данном посте будет рассказано, как реализовать сортировку на Java c использованием ExecutorService. Общая суть сортировки в следующем:

1. Массив разбивается на части
2. Каждая часть массива сортируется
3. Идем по упорядоченным массивам, сливаем их в один

Здесь применяются идеи сортировки слиянием, но массив разбивается только на две части (рекурсия не используется).

Для слияния можно использовать следующую функцию:

Решение задач с анаграммами натолкнуло на мысль:

Сколько останется слов, если удалить все анаграммы и сабанграммы из словаря русского языка

В найденном словаре больше 1,5 млн слов в различных формах

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

Но есть ли решение получше?

Привет, Хабр!

Представим, что у нас есть задача построить новую дорогу. Можно построить магистраль с двумя полосами в каждую сторону, но что, если этого будет недостаточно? Или, наоборот, окажется, что хватило бы и одной полосы, но для реализации проекта пришлось выкупать множество земельных участков? В обоих случаях принятое решение будет неэффективным. Чтобы минимизировать подобные риски, транспортные планировщики обращаются за помощью к компьютерному моделированию. Эта статья – краткий экскурс в мир мультиагентного моделирования.

Снова здравствуйте. В преддверии старта курса «Разработчик Java» подготовили перевод еще одного небольшого материала.

---

Недавно у одного из пользователей Plumbr APM возникла странная проблема с аварийной остановкой docker-контейнера с кодом 137. Конфигурация была простейшая с несколькими вложенными контейнерами и виртуальными машинами, похожая на матрешку:

• свой железный сервер с Ubuntu;
• множество docker-контейнеров с Ubuntu внутри;
• Java Virtual Machine внутри docker-контейнеров.

Статья об использовании реактивного доступа к базам данных из корутин. Spring все упрощает, но это плохо сказывается на понимании реальных процессов работы приложения. Для демонстрации был выбран фреймворк KTor (просто потому, что мне нравится смотреть на то, что делает JetBrains), который интенсивно использует корутины — чтобы задача сочетания Reactive Streams и этих самых корутин добавила интереса. В процессе работы пришло понимание, что происходящее — явный пример преобразования непонятного многим реактивного потока в понятное императивное программирование, на котором мы собаку съели. Я люблю реактивные цепочки, но почему бы не порадовать тех, кто любит армейский порядок?

Реактивные приложения завоевали сердца и посадили нервы многих разработчиков, причем эти множества заметно пересекаются. Посадили бы еще больше, если бы не усилия сообществ, адаптирующих чистый поток разума от создателей спецификаций в удобоваримые библиотеки. Так произошло со спецификацией R2DBC и фреймворком Spring (Boot) — разработчику виден уже привычный Spring Data API с уже привычными реактивными типами данных. Однако есть причины не использовать Spring: не хочется Spring и хочется чего-то нового. Ну, есть еще унаследованный код, но в этом случае вряд ли придется столкнуться с реактивным доступом к данным.

В этом случае придется посмотреть на R2DBC без прикрас. И он будет ожидаемо сильно отличаться от того, что нам предлагают в готовом фреймворке — так же, как JDBC отличается от Spring Data JPA. Плюс реактивность. И реактивность по спецификации Reactive Streams. А у нас на слуху корутины. Которые вроде как будущее и все равно под них переписывать.

Вступление

Название поста действительно «холиварное», но на мой взгляд и у Java, и у популярной библиотеки Guava есть ряд архитектурных проблем, которые в перспективе приводят к двусмысленностям и разногласиям в команде.