Всем привет, данная статья является, своего рода моей первой, но все же постараюсь максимально просто рассказать вам о том, как создать бота, прикрутив к нему все обещанные выше свистелки-тарахтелки.
Статьи будут разделены на 2 части, первая часть - создание основного бота с оправкой логов (Kafka Producer) и записью их в БД, вторая часть - обработка всех логов (Kafka Consumer).
На сегодняшний день это один из, или же самый известный способ автоматического анализа кода и его ревью. Популярностью он обязан тому, что этот сервис бесплатен и доступен, а так же для его установки не требуется много усилий. Интерфейс выглядит современно и понятно. Sonarqube, хоть и написан на java, не ест много ресурсов :)
Система сборки проектов Gradle стала значительной вехой в эволюции инструментов подготовки артефактов и заменила во многих проектах ранее популярный Maven (который ранее стал заменой для make и ant). Де-факто Gradle является стандартом для сборки проектов для Android, но в действительности он может использоваться и для других целевых платформ и технологий разработки, отличных от JVM. Подобно maven в gradle используются устанавливаемые дополнения, которые могут добавлять свои цели и элементы конфигурации, а также встраиваться в существующие цели и добавлять операции как и исходными текстами (например, форматирование), так и с вспомогательными объектами (как пример можно привести кодогенерацию), а также вызов внешних команд или объектов классов (например, компилятора kotlin или инструментов сборки ресурсов для android).
В этой статье мы пошагово создадим и протестируем простой plugin трансформации текстовых файлов для gradle (при разработке будем в основном использовать API, который поддерживается версиями 6.0+, но отдельно отметим, какие функции поддерживаются только в Gradle 7.0 и более новых).
Сначала начнем с определения контекста. Сборка любого проекта состоит из последовательности действий (actions), которые в конечном счете приводят к появлению целевого состояния (task). Конфигурация сборки описывается в виде gradle-сценария, который может взаимодействовать с методами, импортированными из plugin'ов или входящих в gradle-core, либо с версии Gradle 4.0 с использованием Kotlin Scripting (.kts) с возможностью использования объектов стандартной библиотеки Kotlin и импортируемых библиотек.
Это такое приятное чувство, когда ты закончил какую-то задачу. А особенно когда твой проект уже готов к релизу. Остался лишь последний шаг.
Публикация проекта в Maven Central, имеено об этом я расскажу в этой статье. Как настроить Gradle, чтобы потом без труда настроить CI.
Когда я писал свой первый gradle-плагин, я проверял его работоспособность следующим образом:
1. Опубликовал версию n в plugins.gradle.org
2. Проверил опубликованный плагин вручную на тестовом проекте
3. Нашел ошибку/доработал, увеличил версию n=n+1, затем снова пункт 1
Такой вот PDD (Publish Driven Development). Сегодня поговорим о том, как писать эффективные тесты на собственные gradle плагины.
Gradle — один из нескольких инструментов разработки Java, представленных во всеобщем руководстве разработчика Java от Stackify, но это не единственный инструмент автоматизации сборки, который следует рассмотреть. Maven — более старая и часто используемая альтернатива, но какая система сборки лучше всего подходит для вашего проекта? Поскольку другие инструменты, такие как Spring, позволяют разработчикам выбирать между этими двумя системами, в сочетании с растущим числом интеграций для обеих, решение в значительной степени зависит от вас.
Размер вашего проекта, потребность в кастомизации и некоторые другие переменные могут помочь вам сделать выбор. Давайте посмотрим.
Недавно у меня появилось желание попробовать создать свою собственную Android библиотеку и выложить ее на Maven Central репозиторий.
Это оказалось не так просто, как я думал. В интернете полно непонятных статей на эту тему, в которых легко запутаться.
Я решил поделиться процессом публикации моей библиотеки Awesome-Buttons.
Ну что ж, приступим.
Приветствую, Gradle-адепт! В статье тебя ждёт авторский тур по Gradle Task. В маршрут включено хождение по граблям, изучение секретных практик buildscript-тасок, проведение раскопок по deprecated API, а ближе к концу зарядимся силой Custom Gradle Task, попрактикуемся в строительстве билд-кеша и узнаем, кто такой Worker API.
Доброго времени, читатель! В предыдущей статье мы рассмотрели, как эффективно использовать стандартные инструменты Gradle в проектах для решения повседневных задач и немного коснулись подкапотного пространства.
Под катом статьи проведём тур по Gradle-плагинам, разберёмся, для чего вы можете писать кастомные плагины уже сейчас, проникнемся процессом разработки на примере реализации плагина для Kotlin-кодогенерации и научимся обходить некоторые Gradle-грабли.
В первой части статьи проведём небольшой теоретический экскурс и рассмотрим способы реализации плагинов, а во второй части двинемся к практической задаче и проникнемся разработкой плагина для Kotlin-кодогенерации. Заваривайте ваш любимый напиток и поехали.
Всем привет! Меня зовут Владимир, я Android-разработчик в компании Альфа-Капитал. Наверно каждое мобильное приложение с развитием сталкивается с потребностью гибкой настройки какой-то текстовой информации за счет серверной части. В данной статье представлены предпосылки и проблемы нашей компании, а также решение, которое понравилось как разработчикам, так и бизнесу. А в дополнение представлен пример генерации кода с помощью gradle скрипта, который сильно упростил жизнь android команде.
Привет! Меня зовут Ксения Кайшева, я пишу приложения под Android в компании 65apps. Сегодня расскажу о новой возможности, которая позволяет централизованно описывать зависимости на проектах с системой сборки Gradle.
В оставшейся части этого руководства мы будем писать тесты для базы данных видеоигр (Video Game Database). Это приложение представляет собой, как вы наверное догадались, выдуманную базу данных видеоигр. Оно может похвастаться простым API, задокументированным с помощью Swagger, которое покрывает все HTTP-команды (Get, Put, Update, Delete) и поддерживает XML и JSON пейлоады.
Я рекомендую вам клонировать базу данных видеоигр и запускать ее локально. Для этого сначала клонируйте (или загрузите) репозиторий и откройте терминал в том месте, где вы сохранили его на своем компьютере. Оттуда вы можете запустить приложение с помощью:
Эта статья представляет собой полное, подробное и исчерпывающее руководство по эффективному использованию Gatling для нагрузочного тестирования.
Если вам нужно провести нагрузочное тестирование вашего сервера HTTP-приложений, то Gatling - идеальный инструмент для этой задачи! Эта серия статей будет представлять собой подробное практическое руководство по нагрузочному тестировании на Gatling. К концу этого руководства у вас появится хорошее представление об использовании Gatling, которое вы сможете применить в ваших последующих проектах по нагрузочному тестированию.
Всем привет! Меня зовут Виталий, я разработчик в компании Web3Tech. В этом посте я представлю основные концепции и конструкции платформы Spring Cloud Stream для поддержки и работы с брокерами сообщений Kafka, с полным циклом их контекстного unit-тестирования. Мы используем такую схему в своем проекте всероссийского электронного голосования на блокчейн-платформе Waves Enterprise.
Являясь частью группы проектов Spring Cloud, Spring Cloud Stream основан на Spring Boot и использует Spring Integration для обеспечения связи с брокерами сообщений. При этом он легко интегрируется с различными брокерами сообщений и требует минимальной конфигурацией для создания event-driven или message-driven микросервисов.
В некоторых проектах сборке отводится роль Золушки. Основные усилия команда сосредоточивает на разработке кода. А самой сборкой могут заниматься люди, далёкие от разработки (например, отвечающие за эксплуатацию, либо за развёртывание). Если сборка хоть как-то работает, то её предпочитают не трогать, и речь об оптимизации не заходит. Вместе с тем в больших гетерогенных проектах сборка оказывается достаточно сложной и к ней вполне можно подходить как к самостоятельному проекту. Если же относиться к сборке как к второстепенному проекту, то в результате будет получен неудобоваримый императивный скрипт, поддержка которого будет в значительной степени затруднена.
В предыдущей заметке мы рассмотрели, по каким критериям мы выбирали инструментарий, и почему остановились на gradle/kotlin, а в этой заметке рассмотрим, каким образом используем gradle/kotlin для автоматизации сборки не-JVM проектов. (Есть также перевод на английский.)
Gradle для JVM-проектов является общепризнанным инструментом и не нуждается в дополнительных рекомендациях. Для проектов за пределами JVM он также используется. Например, в официальной документации описаны сценарии использования для C++ и Swift проектов. Мы используем gradle для автоматизации сборки, тестирования и развёртывания гетерогенного проекта, включающего модули на node.js, go, terraform.
В некоторых проектах сборке отводится роль Золушки. Основные усилия команда сосредоточивает на разработке кода. А самой сборкой могут заниматься люди, далёкие от разработки (например, отвечающие за эксплуатацию, либо за развёртывание). Если сборка хоть как-то работает, то её предпочитают не трогать, и речь об оптимизации не заходит. Вместе с тем в больших гетерогенных проектах сборка оказывается достаточно сложной и к ней вполне можно подходить как к самостоятельному проекту. Если же относиться к сборке как к второстепенному проекту, то в результате будет получен неудобоваримый императивный скрипт, поддержка которого будет в значительной степени затруднена.
В этой заметке мы рассмотрим, по каким критериям мы выбирали инструментарий, а в следующей — каким образом этот инструментарий используем. (Есть также перевод на английский.)
Хотите узнать, как использовать Gatling через Gradle? Тогда вы по адресу. В последнее время я достаточно часто использую инструмент стресс-тестирования Gatling. Он стал одним из моих излюбленных инструментов для тестирования производительности. На сайте Gatling есть неплохая документация по началу работы. Но она подразумевает загрузку zip-файла, а затем запуск BAT или SH скрипта для запуска Gatling. А затем вам нужно выбрать из списка тест, который вы хотите запустить.
Так что да, было бы намного приятнее делать все вышеперечисленное через Gradle. И естественно, намного удобнее. В частности, если вы хотите запускать Gatling-тесты как часть вашего Continuous Integration. Одним из наибольших преимуществ этого подхода является то, что Gatling может зафейлить вашу CI-сборку, если будет нарушен определенный порог производительности (например, слишком много ошибок или слишком большое среднее время отклика и т. д.).
Если вы хотите запускать Gatling через Gradle, вам понадобится плагин Gatling Gradle.
Это руководство проведет вас через настройку плагина Gradle для нового Gatling-проекта.
Чтобы сделать это руководство еще более удобным для новичков, мы будем производить настройку в IDE (Intellij). После завершения работы по настройке вы можете переключиться на запуск исключительно через командную строку, если вам угодно.
Предупрежу вас с самого начала — я не буду вдаваться в подробности о Gatling в этой статье. Если вы хотите всесторонне познакомиться с Gatling, ознакомьтесь с другой моей статьей «Нагрузочное тестирование с Gatling — Полное руководство».
Всем привет! Я пишу приложения под Android, в мире которого система сборки Gradle является стандартом де-факто. Я решил поделиться некоторыми советами по работе с системой с теми, у кого нет чёткого понимания, как правильно структурировать свои проекты и писать build-скрипты.
Доброго дня, читатель! Меня зовут Стручков Михаил и я Android-разработчик в команде мобильного оператора Yota.
В последнее время особенности нашего приложения способствуют частой и кропотливой работе с Gradle. В своем опыте работы с ним я успел пройти через стадию поломанных сборок, отчаяния в попытках понять причину очередного фейла при билде, и неподдельной радости после успешной реализации собственных задумок.
Предлагаю вам упростить тернистый путь к пониманию сборки Gradle-приложений, разобрать основные этапы и их особенности, и попробовать совместно сократить трафик stackoverflow на тему Gradle. В качестве бонуса немного коснемся Gradle-плагинов и разберемся, как к ним подходить.
Для разработчиков не секрет, что создание нового сервиса влечет за собой немало рутиной настройки: билд скрипты, зависимости, тесты, docker, k8s дескрипторы. Раз мы выполняем эту работу, значит текущих шаблонов IDE недосточно. Под катом мои попытки автоматизировать все до одной кроссплатформенной кнопки "сделать хорошо" сопровождаемые кодом, примерами и финальным результатом.
Если перспективы создания сервисов в один клик с последующим автоматическим деплоем в Digital Ocean звучат заманчиво, значит эта статья для вас.
