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

Сегодня мы поговорим о внедрении микросервисной архитектуры в Центре Финансовых Технологий (ЦФТ) — группе компаний, работающих в области информационных технологий для финансового сектора с 1991 года. То есть это организация, где качество продукта чрезвычайно важно, от него зависят реальные деньги.

В свою очередь, Владимир Плизга последние 6 лет погружен в разработку бэкенда интернет-банков и сопутствующих сервисов в ЦФТ, где активно топит за микросервисы и прочие модные штуки. Чтобы пообщаться с ним, я приехал прямо в офис ЦФТ, сделал сэлфи и обязательную фотку красного слона :-)

Обсуждаемые темы:

• Зачем нужны микросервисы;
• Как с ними жить (судьба REST и SOAP, statefull vs. stateless, переход от монолита к микросервисам, совместимость с legacy и многое другое);
• Микросервисные технологии (Spring Cloud Netflix, Zuul, ...), какие с ними проблемы, что нужно допиливать;
• Документация: на русском или английском? Написание и генерация документации (Swagger, SpringMVC, SpringFox). Архитектурные диаграммы — нужны ли, в чем рисовать, как хранить;
• Мониторинг, восстановление от сбоев;
• Ну и самое главное: стоит ли игра свеч?

(слева — Владимир, справа — olegchir)

В мире существует множество клёвых маленьких библиотек, которые как бы и не знаменитые, но очень полезные. Идея в том, чтобы потихоньку знакомить Хабр с такими вещами под тэгом #javalifehacker. Сегодня речь пойдёт о time-test, в котором всего 16 коммитов, но их хватает. Автор библиотеки — Никита Коваль, и это перевод его статьи, изначально написанной для блога Devexperts.

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

Вот простейший метод, считающий количество дней до конца света:

fun daysBeforeDoom() {
    return doomTime - System.currentTimeMillis()) / millisInDay
}

Конференция: JBreak 2018
Суть: Единственная Java‑конференция в Сибири
Дата: 4 марта 2018
Место: Новосибирск, Экспоцентр, Станционная ул., 104

Меньше, чем через 2 недели, состоится JBreak 2018. В этот раз я смог поучаствовать в Программном комитете и могу не просто пересказывать чужие слова, а поделиться впечатлениями.

Это будет очень круто. Этот JBreak обещает быть чуть ли не самым сбалансированным по сочетанию хардкора, практики и смузи. Причём доклады выбраны так, чтобы как можно меньше пересекаться с JPoint (она будет через месяц). Например, Никита Коваль будет и на JBreak, и на JPoint — но с двумя совершенно разными темами. Это важно, например, для тех, кто хочет побывать на JBreak вживую, а на JPoint — в онлайне.

Доклады очень разноплановые: если вам хочется погрузиться в кромешный ад внутренностей JVM, к нам приедут Крис Талингер и Фолькер Симонис — известные специалисты в этом самом. Если хочется узнать про будущее Java, об этом есть доклад замдиректора Азула, Саймона Риттера (правда, там тоже не всё так просто — придётся погрузиться в кучу JEP'ов, релизную политику, современные тренды развития платформы и так далее). Если же хочется поучаствовать в лёгком, ярком, стремительном шоу с использованием трендовых технологий типа Apache Kafka, Kafka Connect и KSQL — для этого к нам прилетит Витя gAmUssA Гамов сооснователь и лидер любимого многими программистами правильного подкаста «Разбор Полётов» (по совместительству является Solution Architect в компании Confluent).

Чтобы не верить мне на слово, под катом будут освещены основные вопросы и приведена полная программа JBreak 2018 с описанием докладов и фоточками спикеров. В самом конце статьи будет ссылка на регистрацию. Поехали!

Действуем по старой схеме: я для вас отсматриваю подряд 10 докладов, делаю краткое описание содержимого, чтобы неинтересное можно было выбросить. Кроме того, с сайтов собираю ссылки на слайды и описания. Полученное сортирую и выдаю в порядке увеличения рейтинга — то есть в самом низу будет самый крутой доклад. Оценки — это не лайки на YouTube, а собственная оценочная система, она круче лайков.

Предыдущие части: JBreak 2017, JPoint 2017 (обе конференции были про Java).

На этот раз объектом изысканий будет Heisenbug 2017 Moscow — известная конференция для тестировщиков (а также программистов и менеджеров команд, как написано на главной странице сайта).

В посте присутствует зашкаливающее количество картинок и ссылок на YouTube. Осторожно, трафик!

Disclaimer: Все описания являются моим личным мнением. Всё написанное является плодом моего больного воображения, а не искажёнными цитатами докладчиков (это предостережение написано для того, чтобы докладчики меня не побили). Если кого-то случайно обидел — пишите в личку, разберёмся. Но в целом, давайте думать так: если бы BadComedian каждый раз спрашивал у Фонда Кино, что ему стоит говорить или не говорить — снял бы он хоть один ролик?

Коротко: небольшой самодостаточный пример, иллюстрирующий SignalR для .NET Core 2 и разработку в IDE Rider. В самом конце — видео Dino Esposito с конференции DotNext на эту же тему.

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

Очевидно, есть готовые библиотеки, которые берут это на себя. В мире веб-приложений ASP.NET это SignalR, она позволяет разработчику абстрагироваться от перечисленных сложностей и использовать простую программную модель для работы с push-уведомлениями.

Ссылка для скачивания: http://jdk.java.net/10/.

                                                   

Все мы встречались со сложными ошибками на продакшне, которые сложно поймать обычными средствами мониторинга. BPF — это технология ядра Linux, которая позволяет делать быструю и безопасную динамическую отладку прямо на запущенной работающей системе, без необходимости готовиться к этому заранее. JVM сама по себе имеет множество точек мониторинга для отслеживания сборки мусора, выделения объектов, вызовов JNI, даже вызовов методов — и всё это без необходимости в дополнительном инструментировании. Когда этих точек мониторинга недостаточно, ядро Linux и всевозможные бибилиотеки позволяют отслеживать системные вызовы, сетевые пакеты, события планировщика, время потраченное на доступ к диску, и даже запросы к базам данных.

В этом хабрапосте мы сделали текстовую расшифровку доклада Sasha Goldshtein, посвященного тому, как инструменты BPF можно использовать для мониторинга JVM-приложений на GNU/Linux, и чеклисту проверки производительности с использованием классических инструментов, таких как fileslower, opensnoop, strace — но всё это с использованием неинвазивной, быстрой и безопасной технологии BPF.

После ката будет множество картинок со слайдами. Осторожно, трафик! Картинки ужаты насколько можно, но не более того. Все они действительно нужны.

На прошлой неделе друзья позвали отдохнуть на неком Cradle:Rave. Судя по названию, это могло быть всё что угодно, включая кислотную вечеринку, поэтому я решил провести некие исследования в интернетах.

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

Оказалось, всё довольно круто. Это гибридное развлечение, совмещающее хакатон и конференцию. Взяли два основных способа культурного времяпровождения, упаковали в три дня, побеспокоились о помещении и ништяках. Круто. Будет на этой неделе, 16.02-18.02.

Бесплатно, иначе говоря — на халяву, на шару, совершенно свободно. Но нужно успеть зарегистрироваться до 15-ого числа на сайте, регистрация обязательна.

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

JavaParser — это набор инструментов для парсинга, анализа, трансформации и генерации Java-кода. Иначе говоря, если нужно взять кусок джавакода и как-то его покорёжить подручными методами и без необходимости в особых знаниях, эта либа — самое то.

Где-то посреди статьи вы ВНЕЗАПНО можете осознать, какой кошмар и ужас можно сотворить этой либой, и никак не дождётесь дочитать текст и полить меня гневными комментариями. Не сдерживайтесь, не стоит — сразу скрольте до самого низу и изливайте душу :)

Все мы любим посмеяться над дремучим legacy на Java, которое якобы живёт в банках. После прочтения этой статьи у вас появится понимание другой грани этой истории. Оказывается, конкретно в Сбербанк-Технологиях есть целые большие отделы, занимающиеся прорывными технологиями и направлениями, включая Big Data и Machine Learning. Более того, скоро мы можем оказаться в мире, где Machine Learning встроен чуть ли не в каждую кофеварку. К добру или к худу, но Internet of Things, следящий за нами тысячью глаз из каждого банкомата, — куда более актуальное прочтение этой старой шутки.

Как вы, наверное, заметили, я пишу на Хабре про виртуальные машины, внутренности OpenJDK, JVM и другую системную разработку. Почему эта статья — о банковском софте? Потому что это актуально как никогда. Вот представьте, вы такой весь в белом, дважды Data Scientist и четырежды важный гуру JIT-компиляции. Что дальше? Кому всё это может быть нужно прямо здесь и сейчас? Часто слышу рассуждения на тему: «Вот сейчас ты ковыряешься в своей любимой Java, а завтра никто тебя на работу не возьмёт». Это очень забавное и опасное заблуждение. Благодаря таким товарищам, о которых пойдёт речь в этой статье, работа у нас будет всегда.

Конечно, на слово мне никто верить не должен, поэтому специально для Хабра я сорвался на самолёт в Москву, чтобы пообщаться с начальником отдела разработки спецпроектов в Сбербанк-Технологиях. Вадим Сурпин потратил на меня чуть больше часа, а в этом интервью будут только самые важные мысли из нашего разговора. Кроме того, удалось уговорить Вадима подать заявку на участие в нашей конференции JBreak. Более того, Вадим — первый человек, который показался мне достойным инвайта на Хабр: vadsu (инвайт был честно заработан статьей про хакинг ChromeDriver).

Как известно, на любом языке можно писать, как на Java, а первая любовь джависта — это написание Garbage Collectors и JIT Compilers. С этим связано множество восхитительных вопросов, например: каким образом можно из управляемого кода напрямую работать с машинным кодом и ассемблером?

Кроме того, в этой статье будет небольшой пример на C#. В какой-то момент стало понятно, что нельзя всегда изучать одну Java. Рантаймы динамических языков используют общую теорию и на практике работают в рамках похожих проблем. Самый простой способ продвинуть свою работу — посмотреть, как там у соседей, и скопировать себе что-нибудь хорошее.

Теперь про ассемблер и машинный код. Зачем это нужно — вопрос открытый. Например, вы наслушались о Meltdown и хотите написать для него красивое API :-) Ну, и не надо забывать, что Oracle — не боги, поддержку того же AVX-512 добавили только в Девятке, прямое управление аппаратной транзакционной памятью не ложится на язык, часть стандартных методов можно реализовать лучше, чем это сделали в SDK и т.п. — у нас всегда есть с чем покопаться!

В этом посте я расскажу:

• о текущем статусе конференции Heisenbug 2018 Piter;
• о том, как правильно писать периодические анонсы на Хабр;
• о небольшом лайфхаке, как рисовать картинки с прогрессивным JPEG в стиле Тёмы Лебедева.

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

Эта статья возникла из-за одной моей ошибки и двух багов — по одному в Chromium Headless и ChromeDriver. В результате пришлось собрать всё это из исходников (в статье есть подробнейшая инструкция), отладить цепочку взаимодействия Selenium<->ChromeDriver<->Chromium в отладчике IntelliJ IDEA и Microsoft Visual Studio, покопаться в Java, C++ и JS.

Статья будет интересна тем, кто хочет понять, чем им грозит переход на Selenium + Headless Chrome и как с этим жить. А также всем, кто просто хочет немного поглумиться над несчастным быдлокодером.

Под катом есть пачка скриншотов (трафик!).

Кстати, всё это можно было бы сделать скринкастом — но нельзя, потому что время компиляции C++ необычайно долгое. Вместо этого тут будут скриншоты для привлечения внимания.

Вначале напомню названия участвующих продуктов. Их три штуки:

• Chromium — это браузер. Небрендированная версия Google Chrome, без автообновлений, анальных следящих зондов, но и без несвободных компонентов типа кодеков.
• Chromium ChromeDriver — это часть Chromium, которая отвечает за управление им с помощью внешних инструментов. Это standalone фронт-сервер (отдельный exe-файл), реализует стандарт W3C WebDriver и использует в качестве бэкенда Chrome DevTools.
• Selenium и его Selenium Chrome Driver — эта штука предоставляет Java API для управления Хромиумом. Джава тут не принципиальна, на JavaScript и jWebDriver было бы то же самое (а на Puppeteer — возможно, нет, ибо он использует DevTools напрямую).

Всё вместе даёт нам в руки браузер, управляемый с помощью API на Java, JavaScript и так далее.

Вспомнили? Поехали дальше.

Аккурат к концу новогодних каникул в России, 9-го января, Microsoft выпустили обновления, исправляющие CVE-2018-0786 и CVE-2018-0764. Починили так, что кое-где ещё и сломали. В этом коротком посте мы ещё раз вспомним, что это такое и что нам теперь делать.

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

Конференция: Heisenbug 2018 Piter
Дата: 17-18 мая 2018 года
Место: Санкт-Петербург, Гостиница «Park Inn by Radisson Пулковская»

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

Анализ отзывов участников

Перед написанием этого анонса я открыл отзывы участников и просмотрел 292 ответа. Основная тема половины отзывов — необходимость (или её отсутствие) иметь доклады по мануальному тестированию. Это то, что я хотел бы обсудить с вами.

На позапрошлый Heisenbug ругались, что он превратился в какой-то Autobug. Надеюсь, никто не обидится, если я приведу один обезличенный отзыв по этой теме, как из палаты мер и весов:

«Если в двух словах — «автоматизация головного мозга». Следовало так и назвать конференцию. Была всего пара докладов про НЕ автоматизацию. Вы ведь и сами знаете, что автоматизация это всего лишь часть тестирования, и совсем не основная».

Что можно посмотреть вечером или на этих выходных? Можно смотреть какие-нибудь фильмы, а можно — наш непрекращающийся сериал под названием «Java-конференции». Единственный сериал, после просмотра которого у вас может радикально увеличиться зарплата.

Вчерашняя статья про JPoint 2017 оказалась удивительно успешной. У неё почти не было комментариев, но на данный момент — 88 закладок. То есть статья попала в цель: люди добавляют в закладки и смотрят — ура. Буквально в первый час её пришел читать сам Сатана.

Сегодня мы будем действовать по старой схеме: я для вас отсматриваю подряд 10 докладов, делаю короткое описание содержимого, чтобы неинтересное можно было выбросить. Кроме того, с сайтов собираю ссылки на слайды и описания. Полученное сортирую и выдаю в порядке увеличения рейтинга — то есть в самом низу будет самый крутой доклад. Оценки — это не лайки на YouTube, а наша собственная оценочная система, она круче лайков.

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

Идея проста: надо взять наиболее популярные доклады с JPoint 2017, кратенько пересказать, о чём там речь, почему это круто и зачем нужно лично мне. Каждый из этих докладов заслуживает отдельного разбора, но вначале — краткий обзор первой десятки. Поехали!

Все мы давно хотим перелезть на .NET Core, но постоянно что-то мешает. Например, ничего не поделаешь, когда не хватает важных API. В версии 2.0 процесс упростили благодаря .NET Standard 2.0, но это ещё не всё. Ну что ж, Microsoft-боги вняли нашим молитвам и завезли 20 000 API, доступных в виде одного-единственного пакета в NuGet!

Привет, Хабр! Помоги выбрать веб-фреймворк? Требования: модный, молодежный, популярный, качественный фреймворк для соло-технономада.

Надо ли нам каждый месяц читать очередной пост про это?

Несколько лет участия в проектах на границе энтерпрайза и системщины окончательно отбили нюх. Чтобы разобраться в вопросе, я заглянул в топ гугла и обнаружил там кучу однобоких рейтингов. Наверное, самым лучшим оказался Java Web Frameworks Index от ZeroTurnaround.

Каждый, кто сталкивался с трехмерной графикой, рано или поздно открывал документацию на методы отрисовки, которые предполагают несколько проходов рендерера. Такие методы позволяют дополнить картинку красивыми эффектами, вроде свечения ярких пятен (Glow), Ambient occlusion, эффекта глубины резкости.

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

Чтобы разобраться, как правильно готовить WebGL, мы обратились к специалистам компании Align Technology. Они решили создать специальный менеджер для управления всем этим зоопарком из разных текстур, которым было бы удобно пользоваться. Что из этого получилось — будет под катом. Важно, что неподготовленного читателя, который никогда до этого не сталкивался с необходимостью организации многопроходного рендеринга, статья может показаться непонятной. Задача довольно специфическая, но и безумно интересная.