Java *

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

В последнее время мы вернулись к тщательной проработке темы тестирования, а в обозримых планах у нас даже есть отличная книга по Unit Testing. При этом считаем, что в данной теме как нигде важен контекст, поэтому сегодня предлагаем перевод сразу двух публикаций (объединенных в одну), вышедших в блоге видного специалиста по Java EE Себастьяна Дашнера — а именно, 1/6 и 2/6 из серии «Thoughts on efficient enterprise testing».

Два года назад я вызвался постоять на стенде нашей компании JetBrains на последней конференции JBreak в Новосибирске. Перед конференцией мне спустили сверху вот такие карточки:

И сказали, мол, ну раздай каким-нибудь людям на конференции на своё усмотрение. Я запаниковал. Как же я буду людей-то выбирать?

Тогда я довольно плотно работал с анализом потока данных в статическом анализаторе IntelliJ IDEA для Java. Во-первых, я обкатывал новые фичи, проверяя код самой IDE. Во-вторых, разгребал входящие баг-репорты. Иногда IDEA находила удивительные проблемы, и мне приходилось долго разбираться, чтобы вообще понять, правильное ли предупреждение она выдаёт или это баг.

Пару месяцев назад в моем профиле был опубликован подробный пост по загрузке классов на JVM. После этого доклада мои коллеги задались хорошим вопросом: а какой механизм использует Spring для разбора конфигураций и как он загружает классы из контекста?

Никогда не было, и вот опять!

На очередном проекте мы решили использовать Liquibase с самого начала, чтобы избежать проблем в будущем. Как оказалось, не все молодые члены команды умеют его правильно использовать. Я провёл внутренний воркшоп, который затем решил превратить в статью.

Статья включает в себя полезные советы и описание трех самых явных ловушек, в которые можно попасть, работая с инструментами миграции реляционных баз данных, в частности Liquibase. Рассчитана на Java разработчиков уровня Junior и Middle, для более опытных разработчиков может быть интересна для структуризации и повторения того, что, скорее всего, уже известно.

Привет, Хаброжители! Потоки являются фундаментальной частью платформы Java. Многоядерные процессоры — это обыденная реальность, а эффективное использование параллелизма стало необходимым для создания любого высокопроизводительного приложения. Улучшенная виртуальная машина Java, поддержка высокопроизводительных классов и богатый набор строительных блоков для задач распараллеливания стали в свое время прорывом в разработке параллельных приложений. В «Java Concurrency на практике» сами создатели прорывной технологии объясняют не только принципы работы, но и рассказывают о паттернах проектирования. Легко создать конкурентную программу, которая вроде бы будет работать. Однако разработка, тестирование и отладка многопоточных программ доставляют много проблем. Код перестает работать именно тогда, как это важнее всего: при большой нагрузке. В «Java Concurrency на практике» вы найдете как теорию, так и конкретные методы создания надежных, масштабируемых и поддерживаемых параллельных приложений. Авторы не предлагают перечень API и механизмов параллелизма, они знакомят с правилами проектирования, паттернами и моделями, которые не зависят от версии Java и на протяжении многих лет остаются актуальными и эффективными.

В октябре в Санкт-Петербурге прошла хардкорная конференция Joker 2019, и уже много про нее написано («Joker 2019: триумф года», «Чем нам запомнилась последняя JokerConf», «Атакуем Joker 2019 полностью: как прошла самая крупная Java-конференция в России»), и фоточки уже доступны. Обратная связь собрана, итоги подведены, и самое время поудобней усесться в кресле и посмотреть десятку лучших докладов с конференции.


Ссылка на плейлист с открытыми докладами — под катом.

Привет!

4 марта (это будет среда) мы проведем наш очередной митап для любителей Java в Екатеринбурге. Как обычно, вход бесплатный, главное заранее зарегистрироваться. Будут четыре спикера от нашего банка, начинаем в 18.30 в БЦ «Высоцкий».

* Под всё имеется в виду относительно быстрое выполнение операций над единичным элементом массива.

Структур данных, которые реализуют список полно. У всех есть свои достоинства и недостатки. Например в мире Java — в зависимости от необходимых операций — можно использовать:

• add(obj), get(obj), set(index, obj): базовый набор почти всех списков, например ArrayList.
• add(index, obj): структуры в виде дерева, например TreeList из apache common-collections.
• remove(index): то же, что и выше.
• contains(obj), indexOf(obj): можно использовать связку ArrayList и HashMap.
• remove(obj): … затрудняюсь ответить. В некоторых случаях можно обойтись LinkedHashSet. Решается тривиально при наличии предыдущих двух пунктов, но какие структуры могут и то и другое быстро?

Когда мне понадобилась структура с быстрыми add(obj), get(index), remove(index) и indexOf(obj), то google не дал ответа. Ни примеров кода, ни описания подобных структур я не нашел. Возможно не там искал, пришлось выдумывать самому. Но если кто-то скинет ссылку в комментариях, то буду весьма признателен.

Возможно, кто-то догадался, что можно взять TreeList, который умеет быстро вставлять/удалять элементы в середине списка и добавить к нему HashMap из объекта в индекс в TreeList для быстрого выполнения indexOf(obj). И это будет простое, изящное, но неверное решение. Ведь при добавлении в середину или удалении из середины нужно будет пересчитать индексы, в среднем, для половины элементов. Это ухудшит производительность до O(n).

Дальше я расскажу о структуре данных, которая может всё из перечисленного выше. Которая выполняет любую операцию над одним элементом за O(log(n)) времени. Ну почти — за логарифм выполняется в том случае, когда все объекты в списке различны. Если в списке есть одинаковые объекты, то возможно проседание производительности вплоть до O(log(n) ^ 2).

Здесь есть все, что вам нужно знать о различных версиях и функциях Java.

Java 8, Java 11, Java 13 — какая разница?

Вы можете использовать это руководство, чтобы найти и установить последнюю версию Java, понять различия между дистрибутивами Java (AdoptOpenJdk, OpenJDK, OracleJDK и т.д.), А также получить обзор возможностей языка Java, включая версии Java 8-13.

Примечание переводчика
09 апреля 2020 г. Марко опубликовал новую версию Руководства, в которую добавлено описание Java 14.
Перевод новой версии Руководства предлагается Вашему вниманию.

В последнее время задача распознавания символов в прикладных программах не представляет особой сложности — можно использовать множество готовых OCR-библиотек, многие из которых доведены почти до совершенства. Но все же иногда может возникнуть задача разработать свой алгоритм распознавания без использования сторонних «навороченных» OCR-библиотек.

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

Наша команда в Сбербанке занимается разработкой сервиса сессионных данных, который организует взаимообмен единым Java-контекстом сессии между распределёнными приложениями. Наш сервис крайне нуждается в очень быстрой сериализации Java-объектов, поскольку это часть нашей mission critical задачи. Изначально нам на ум приходили: Google Protocol Buffers, Apache Thrift, Apache Avro, CBOR и др. Первая тройка из перечисленных библиотек требует для сериализации объектов описания схемы их данных. CBOR такой низкоуровневый, что умеет сериализовывать только скалярные значения и их наборы. Нам же была нужна библиотека Java-сериализации, «не задающая лишних вопросов» и не заставляющая вручную разбирать сериализуемые объекты «на атомы». Мы хотели сериализовывать произвольные Java-объекты, не зная о них практически ничего, и хотели делать это максимально быстро. Поэтому мы устроили соревнование для имеющихся Open Source решений задачи Java-сериализации.

Всем привет! Целый месяц мы изучали работы участников конкурса. И честно сказать, получили массу удовольствия в процессе, причём дважды: сначала — читая ваш код и радуясь красивым архитектурным и инженерным решениям, и потом — когда запускали решения и смотрели выкачанные картинки и видео. Иногда мемы были так хороши, что жюри в полном составе останавливало работу, чтобы отсмеяться и утереть слёзы. Особенно порадовали весёлые комментарии в коде — чувствуется, что рабочий настрой у участников был правильный!

Приветствую!

Прошлый год выдался крайне продуктивным для нашей некоммерческой организации, и эта статья является лишь началом цикла публикаций, освещающих нашу деятельность. А там есть о чём рассказать, ведь несколько наших продуктов оказались в центре больших банковских проектов — и о да — они не подвели!

Но начнём с чего-то простого и более понятного — и при этом, близкого всем нам без исключения — темы логирования.

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

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

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

Теперь следим за руками: если звук — это тоже волна, и разной частотой кодируется разная высота звука, наблюдается ли в восприятии звука тот же эффект? Можно ли разделить набор воспринимаемых частот, на те, которые снимаются одним «датчиком», и те, которые воспринимаются за счет «комбинации»?

Предупреждаю сразу, морали под катом не будет, но если интересны рассуждения по поводу опровержения вбросов…

Представим себе ситуацию: аналитики компании Foobar Inc. провели тщательное исследование конъюнктуры рынка и бизнес-процессов компании и пришли к выводу, что для оптимизации издержек и многократного увеличения прибыли Foobar кровь из носу требуется Telegram-бот компаньон, способный подбодрить сотрудников в трудную минуту.

Естественно, Foobar не может позволить, чтобы коварные конкуренты воспользовались их ноу-хау, просто добавив их бота себе в контакты. Поэтому требуется, чтобы бот разговаривал только с сотрудниками Foobar, прошедшими аутентификацию в корпоративной системе единого входа (SSO) на основе OpenId Connect.

Всем привет! Уходя на выходные делимся с вами статьей, которая была переведена в преддверии старта курса «Разработчик на Spring Framework».

---

В прошлых статьях мы создавали RESTful веб-сервис, теперь же мы поговорим о безопасности

Вступление

В предыдущем посте мы рассмотрели, как создать REST API с использованием инфраструктуры Java Spring Boot и MongoDB. API, однако, не требовал никакой аутентификации, а это значит, что он, вероятно, все еще не готов к использованию. Поэтому в этом руководстве будет рассказано, как использовать встроенную среду безопасности Spring для добавления уровня аутентификации в этот API.

2020 уже в разгаре, давайте же обсудим, какие изменения в мире Java нас ожидают в этом году. В этой статье перечислю основные тренды Java и JDK. И буду рад дополнениям от читателей в комментариях.

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

Перед вами продолжение серии статей, которую можно озаглавить «ужасы для программистов». В этот раз речь пойдёт о типовом паттерне опечаток, связанном с использованием чисел 0, 1, 2. Неважно, пишете вы на C, C++, C# или Java. Если вы используете константы 0, 1, 2, или если эти числа содержатся в именах переменных, то, скорее всего, Фредди заглянет к вам ночью в гости. Читайте и не говорите потом, что вас не предупреждали.

Хочешь сделать что-то полезное и рабочее — сделай его так, чтобы другие люди могли этим полноценно пользоваться, нормально это ревьювить, да и вообще вспоминать тебя добрым словом, а не темной стороной своего словарного запаса.

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

Так вот, о чем я сегодня. В этом посте я расскажу, почему мы в RBK.money используем Swagger, как он помогает нам в работе и какие у него есть косяки.

Глубокое погружение в мир аннотации Spring Boot @Conditional с проработанными примерами реализаций классов доступа к БД Mongo и MySQL.

В моем посте «Почему Spring Boot?» было рассмотрено создание Spring Boot приложения, из которого вы едва ли сможете понять, что происходит за кулисами. Возможно, вы хотите понять магию автоконфигурации Spring Boot.

Перед этим вы должны узнать о Spring аннотации @Conditional, от которой зависит вся магия автоконфигурации Spring Boot.