Java *

Гитхаб экшены, как я познавал ci/cd

   Всем Алоха. Все слышали про ci/cd, про то что он должен быть в каждой компании и то что он упрощает нам жизнь. У всех свой ci/cd. 

   Кто-то предпочитает Jenkins. Особенно если у вас куча микросервисов, команд и процессов, то при помощи Дженкинса можно достаточно гибко настроить ci/cd в компании. Кто-то использует GitLab actions и для каждого репозитория настраивает свои пайплайны и процессы. Достаточно удобно и просто настраиваемый механизм сборки и доставки артефактов на стенды. Не чуть не хуже GitHub actions. Это было открытием для меня что в GitHub появился такой функционал, о котором мы поговорим позже. Ну и конечно всеми «любимый» скриптовый ci/cd. Пачка скриптов, которые нужно выполнить в определенной последовательности чтобы собрать и задеплоить артефакты. Есть ещё так сказать хэнд мэнуал ci/cd. Но это особый вид извращения, с которым не пожелаю столкнуться никому. В котором нужно собрать артефакты у себя на машине и по какому нить ридми выполнять команды в терминале, лазить по ssh смотреть, что все копировалось, перезапускать сервисы и другие развлечения. 

    Передо мной стояла задача спроектировать и написать новый сервер для проекта. Изначально я закидывал джарники на сервак руками, чтобы проверить работоспособность и настроить сервер. Хэнд мэнуал деплой. В какой то момент меня это начало бесить и я задумался об автоматизации этого процесса. Как вы понимаете девопса или того кто шарит в этом у меня под рукой в компании не оказалось. Очень круто, если у вас есть такой человек. У меня был выбор сделать скрипт деплой, чего я искренне не хотел, потому что в целом не любитель копаться в терминале и скриптах, когда этого можно избежать. Поднять дженкинс и настроить там джобы и пайплайны. Вариант оч классный для большой компании, а мне нужен деплой лишь одного сервера, а не тысячи микросервисов. Да и чего таить, знаний как настраивать дженкинс с нуля у меня было чуть меньше чем ноль. 

Создайте архетип из существующего проекта и сгенерируйте новые клоны с минимальными усилиями. Прекратите копи-паст проектов и создайте архетип!

Если вы создаете облако микросервисов или находитесь в среде, где вам нужно сгенерировать несколько проектов или модулей maven, очень полезно создавать архетипы для разработки этих новых модулей/проектов.

Некоторые ошибки трудно воспроизвести на вашем персональном компьютере, но их легко воспроизвести на производственных или тестовых машинах. Это обычная ситуация, с которой часто сталкиваются профессиональные Java-разработчики. Для отладки таких проблем OpenJDK предоставляет два инструмента: remote debugging и jdb. Эта статья посвящена jdb.

Для приложений Java типичными производственными и тестовыми машинами являются серверы Linux без графического интерфейса, поэтому доступны только инструменты командной строки. И мы не можем использовать профессиональные IDE, такие как IntelliJ IDEA, Eclipse или Apache NetBeans IDE.

В таких сценариях мы можем использовать jdb. jdb - это отладчик командной строки, входящий в состав OpenJDK.

Это перевод руководства для начинающих. Очевидно эксперты все это знают и им не стоит тратит время на его чтение...

Тайна ошибки комментария и другие истории...

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

В качестве прикладного дополнения к рассуждениям мы разработали несколько Proof of Concept, сопроводили их разработку краткими пояснениями и приложили исходный код PoC.

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

Цель этой статьи — описать способы создания самодостаточных исполняемых (self-contained executable) JAR, также известных как uber-JAR или fat JAR.

А чем Single отличается от Observable ?

чем вызваны такие изменения ?

пффф, ну и что? А я буду использовать всегда Obsevable, пусть в нем будет только один элемент.

• Если вы знаете, что вы будете работать только с одним элементом, то в использовании Observable нет нужды или, как говорят, overkill;
• Также нужно понимать, что Observable более тяжеловесный, чем Single (а поговаривают, что Single даже быстрее);

Говоришь Single, хм...

• одно значение
• exception

Хотя IntelliJ IDEA является полноценной IDE (Интегрированная среда разработки), вы наверняка захотите ее персонализировать. В JetBrains Marketplace есть множество плагинов с полезными функциями, которые могут удовлетворить ваши личные или деловые потребности.

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

Напоминаем, что все плагины можно установить через Настройки/Параметры | Плагины или на вкладке Плагины на экране приветствия.

Привет. Сегодня я расскажу о работе с геоданными в PostgreSQL и немного о том, как это сделать в своем Java/Kotlin-приложении.

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

Всем привет!

Статья посвящена тем, кто только врывается в увлекательный мир программирования на Java и ищет применения своим знаниям. Классно, что вы теперь знаете, как создавать переменные, методы и массивы, но, конечно, хочется писать "полезные" для человечества программы, а не выполнять многочисленные мелкие упражнения и задачи, хотя без этого тоже никуда. В общем, будем дополнять теорию практикой. Поехали!

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

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

Я уверен, что вы уже видели примеры, как с помощью записей превратить обычный POJO ...

Elasticsearch - мощный поисковый движок и распределенная система хранения документов. При правильной конфигурации, всю магию поиска выполняет именно он, а клиентскому приложению остается лишь сгенерировать запрос в виде Query DSL и подождать ответа.

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

Если вам интересно узнать, как это можно сделать, то добро пожаловать под кат!

Паша Финкельштейн — разработчик, серийный спикер, автор и ведущий нескольких подкастов. На конференции Java Meeting Point он сделает доклад «Spark: let's touch it», на котором познакомит участников с миром больших данных. 

В этом интервью Паша рассказал, что ждет участников конференции, как он начал заниматься DevRel-активностями и что, по его мнению, должно быть в хорошем докладе. 

Давайте представим, что вы параноик, и параноик вдвойне, когда дело касается многопоточности. Предположим, что вы делаете backend некого функционала приложения, а приложение переодически дергает на вашем серверы какие-то методы. Все вроде хорошо, но есть одно но. Что если ваш функционал напрямую зависит от каких-либо других данных, того же банального профиля например? Встает вопрос, как гарантировать то, что сценарий отработает именно так, как вы планировали и не будет каких-либо сюрпризов? Транзакции? Да это можно использовать, но что если Вы фантастический параноик и уже представляете как к вам на сервер летит 10 запросов к одному методу от разных клиентов и все строго в одно время. А в этот момент бизнес-логика данного метода завязана на 100500 разных данных. Как всем этим управлять? Можно просто синхронизировать метод и все. Но что если летят еще и те запросы, держать которые нет смысла? Тут уже начинаются костыли. Я пару раз уже задавался подобным вопросом, и были интересно, ведь задача до абсурда простая и повседневная (если вы заботитесь о том, чтобы не было логических багов конечно же ). Сегодня решил подумать, как это можно очень просто и без костылей реализовать. И решение вышло буквально на 100 строк кода.

Немного наглядного примера

Давайте предположим, что есть водитель и есть пассажир. Водитель не может менять машину до тех пор, пока клиент, например подтверждает поездку. Это что получается, клиент соглашался на поездку с одними характеристиками машины, а по факту у водителя другая машина? Не дела! Можно организовать что-то подобное:

Реактор сегодня - это стильно, модно, молодежно. Почему многие из нас практикуют реактивное программирование? Мало кто может ответить однозначно на этот вопрос. Но эта статья рассказывает не об этом, а о проблемах, которые реактор может создать даже опытному программисту и о методах их решений. Берем под контроль количество одновременно выполняемых задач, правильно распределяем задачи в пуле и достигаем отличных результатов с параллельной обработкой в reactor.

В этой статье мы рассмотрим кросс-браузерное тестирование. Это тип тестирования, который проверяет, работает ли приложение так, как ожидается, в нескольких браузерах, операционных системах и устройствах. Мы можем проводить кросс-браузерное тестирование с помощью автоматизации и без нее. Сценарии автоматизированного тестирования могут быть написаны или созданы с помощью таких программ, как TestProject и Selenium.

К концу этой статьи вы узнаете об определении кросс-браузерного тестирования, его преимуществах и работе с ним в Selenium и TestProject.

Примечание: Код из этой статьи находится на GitHub здесь.

В современном мире ООП стало неотъемлимой частью разработки. Многие популярные языки, такие как Pyhon, Jaba, Hachkell, GOO и C== поддерживают данную парадигму. В этой статье я постараюсь раскрыть смысл таких архитектурных конструкций, как абстрактный синглтон и фабрика абстрактных синглтонов.

Spring Boot Actuator помогает нам отслеживать и управлять нашими приложениями в производственной среде. Он предоставляет конечные точки, которые публикуются показатели работоспособности и другая информация о запущенном приложении. Мы также можем использовать его для изменения уровня ведения журнала приложения, создания дампа потока и т. д. - короче говоря, возможностей, которые упрощают работу в производственной среде.

Хотя Actuator в основном используется в производственной среде, он также может помочь нам во время разработки и сопровождения. Мы можем использовать его для изучения и анализа нового приложения Spring Boot.

В этой статье мы увидим, как использовать некоторые из его конечных точек для изучения нового приложения, с которым мы не знакомы. Мы будем работать в командной строке и использовать curlи jq, с изящным и мощным JSON процессором командной строки.