Пользователь
Helidon отлично подходит для создания микросервисов, для простого и быстрого развертывания в проде, и демострирует действительно впечатляющую производительность!
А как насчет тестирования Helidon?
В этой статье мы рассмотрим несколько способов, как это сделать.
Идея поэкспериментировать с интеграцией Neo4j с Helidon возникла вполне естественно.
Neo4j — графовая система управления базами данных с открытым исходным кодом, реализованная на Java. По состоянию на 2015 год считается самой распространённой графовой СУБД. (Википедия, 21.10.2021)
Neo4j написана на Java и доступна из ПО, написанного на других языках с использованием языка запросов Cypher, через транзакционную конечную точку HTTP или через двоичный протокол «bolt». Neo4j в настоящее время является стандартом де-факто для графовых баз данных, используемых во многих отраслях.
Вообще, в се началось с небольшого разговора с Michael Simonis, одним из авторов Spring Data Neo4j 6 и сопровождающим Neo4j-OGM. Мы спросили Михаеля, что он думает о том, как Helidon и Neo4J могут работать вместе. Менее чем через час Михаель прислал мне ссылку на этот репозиторий с полнофункциональным примером для Helidon MP и Neo4j SDN.
Helidon – по гречески ласточка (Χελιδόνι), это такая маленькая птичка из отряда воробьиных с длинными острыми крыльями и характерным двойным хвостом.
Уверен, каждый из нас восхищается полетом и грацией этой птички, а то, как она живет в стаях, чем-то напоминает мир микросервисов.
Helidon для нас, программистов, это набор библиотек прежде всего для разработки микросервисов, и является представителем семейства, назовем его, MicroProfile based средств разработки. Является полностью Open Source проектом, лежит на GitHub, и распространяется под лицензией Apache 2.0.
→ Оригинал статьи
Автор: Мартин Кръстев
Один мой друг обратил мое внимание на интересную статью на habrahabr.ru — русский перевод статьи Дэниела Лемира Быстрое удаление пробелов из строк на процессорах ARM. Эта статья заинтриговала меня по двум причинам: во-первых, кто-то на самом деле потратил время и усилия по поиску оптимального решения общей проблемы на не-x86 архитектуре (ура!), а во-вторых, результаты автор дал в конце статьи немного озадачили меня: порядка 6-ти кратное преимущество для Intel? Автор сделал однозначный вывод, что ARM-у ну очень далеко по соотношению «эффективность на такт» до «большого железа» от Интела в этой простой задаче.
Вызов принят!
