Это третья и последняя статья из цикла о миграции из Grails в Micronaut. Обратите внимание: ваше приложение должно быть создано в Grails 4.x или более поздней версии.
В этой статье поговорим о сервисах, контроллерах, приложении Micronaut, Micronaut Data.
Первую статью (о многомодульных проектах, конфигурации и статической компиляции) можно прочитать здесь.
Вторую статью (о датасетах, маршалинге и классах предметной области) можно прочитать тут.
Это вторая статья из цикла о миграции из Grails в Micronaut. Обратите внимание: ваше приложение должно быть создано в Grails 4.x или более поздней версии.
Всего в цикле публикаций о миграции из Grails в Micronaut 10 частей:
Многомодульный проект
Конфигурация
Статическая компиляция
Датасеты
Маршалинг
Классы предметной области
Сервисы
Контроллеры
Приложение Micronaut
Micronaut Data
В этой статье поговорим о датасетах, маршалинге и классах предметной области.
Первую статью (о многомодульных проектах, конфигурации и статической компиляции) можно прочитать здесь.
Всего в цикле публикаций о миграции из Grails в Micronaut будет 10 частей:
Многомодульный проект
Конфигурация
Статическая компиляция
Датасеты
Маршалинг
Классы предметной области
Сервисы
Контроллеры
Приложение Micronaut
Micronaut Data
Обратите внимание: ваше приложение должно быть создано в Grails 4.x или более поздней версии.
Приветствую, Gradle-адепт! В статье тебя ждёт авторский тур по Gradle Task. В маршрут включено хождение по граблям, изучение секретных практик buildscript-тасок, проведение раскопок по deprecated API, а ближе к концу зарядимся силой Custom Gradle Task, попрактикуемся в строительстве билд-кеша и узнаем, кто такой Worker API.
В предыдущей статье "Несколько примеров успешного изобретения велосипеда" мы поделились рядом решений, полученных путем комбинирования наших плагинов для Atlassian, таких как MyGroovy, JSIncluder и MyCalendar. На этот раз мы рассмотрим еще один плагин из нашей коллекции — Custom Select List.
Доброго времени, читатель! В предыдущей статье мы рассмотрели, как эффективно использовать стандартные инструменты Gradle в проектах для решения повседневных задач и немного коснулись подкапотного пространства.
Под катом статьи проведём тур по Gradle-плагинам, разберёмся, для чего вы можете писать кастомные плагины уже сейчас, проникнемся процессом разработки на примере реализации плагина для Kotlin-кодогенерации и научимся обходить некоторые Gradle-грабли.
В первой части статьи проведём небольшой теоретический экскурс и рассмотрим способы реализации плагинов, а во второй части двинемся к практической задаче и проникнемся разработкой плагина для Kotlin-кодогенерации. Заваривайте ваш любимый напиток и поехали.
Доброго дня, читатель! Меня зовут Стручков Михаил и я Android-разработчик в команде мобильного оператора Yota.
В последнее время особенности нашего приложения способствуют частой и кропотливой работе с Gradle. В своем опыте работы с ним я успел пройти через стадию поломанных сборок, отчаяния в попытках понять причину очередного фейла при билде, и неподдельной радости после успешной реализации собственных задумок.
Предлагаю вам упростить тернистый путь к пониманию сборки Gradle-приложений, разобрать основные этапы и их особенности, и попробовать совместно сократить трафик stackoverflow на тему Gradle. В качестве бонуса немного коснемся Gradle-плагинов и разберемся, как к ним подходить.
Всем привет! В интернете довольно много статей, связанных с Declarative Jenkins pipeline, и совсем немного о Jenkins Scripting Pipeline, хотелось бы восполнить этот пробел.
Привет, Товарищи!
Что будет, если в приложении Spring Boot выставить logging.level.root=TRACE?
Все логи будут записаны в один файл, в котором будет куча-мала из классов.
- Псст, тут есть кто-нибудь?
- Это хаб Groovy.
- Теперь вообще не нужно писать код логирования! Он добавляется автоматически!
- Круто, это сэкономит кучу времени и сил!Привет!
В предыдущих статьях мы поговорили о логировании и о мета-программировании.
Теперь поговорим о мета-логировании.
Или о семантическом логировании — кому как нравится.
Логгер "Бобина" — это были цветочки. А вот и ягодки: Чёрный ящик.
Приветствую, Дорогие Друзья.
Продолжаем цикл статей, освещающий деятельность (бурную) нашей некоммерческой организации.
Как и обещал — переходим от простого (логирование) к более сложному: метапрограммирование.
Приветствую!
Прошлый год выдался крайне продуктивным для нашей некоммерческой организации, и эта статья является лишь началом цикла публикаций, освещающих нашу деятельность. А там есть о чём рассказать, ведь несколько наших продуктов оказались в центре больших банковских проектов — и о да — они не подвели!
Но начнём с чего-то простого и более понятного — и при этом, близкого всем нам без исключения — темы логирования.
Так получилось, что на моем текущем месте работы мне пришлось познакомиться с данной технологией. Начну с небольшой предыстории. На очередном митинге, нашей команде сказали, что нужно создать интеграцию с известной системой. Под интеграцией подразумевалось, что эта известная система будет нам слать запросы через HTTP на определенный ендпоинт, а мы, как это ни странно, слать обратно ответы в виде SOAP сообщения. Вроде все просто и тривиально. Из этого следует что нужно…
Сегодня, команда Micronaut в Object Computing Inc (OCI) представила Predator, новый проект с открытым исходным кодом, цель которого — значительно улучшить время выполнения и производительность (по памяти) доступа к данным для микросервисов и serverless-приложений, при этом не потеряв в продуктивности по сравнению с такими инструментами, как GORM и Spring Data.
От переводчика: При разработке CUBA Platform мы заложили в этот фреймворк возможность исполнения пользовательских скриптов для более гибкой настройки бизнес-логики приложений. О том, хороша или плоха эта возможность (и мы говорим не только о CUBA), ведутся долгие споры, но то, что контроль исполнения пользовательских сценариев необходим — это ни у кого не вызывает вопросов. Одна из полезных возможностей Groovy для управления исполнением пользовательских скриптов представлена в этом переводе статьи Cédric Champeau. Несмотря на то, что он недавно покинул команду разработки Groovy, сообщество программистов, по видимому, еще долгое время будем пользоваться плодами его трудов.
Один из наиболее часто используемых способов использования Groovy — это скриптинг, поскольку Groovy позволяет легко исполнять код динамически, в рантайме. В зависимости от приложения, скрипты могут находиться в различных местах: файловой системе, БД, удаленных сервисах… но самое важное — разработчик приложения, исполняющего скрипты, не обязательно сам их пишет. Более того, скрипты могут работать в ограниченном окружении (ограниченный объем памяти, лимит на количество дескрипторов файлов, время исполнения…), или вы можете захотеть запретить пользователю использовать все возможности языка в скрипте.
Этот пост вам расскажет
SecureASTCustomizer
Spock предоставляет 3 мощных (но разных по сути) инструмента, упрощающих написание тестов: Mock, Stub и Spy.
Довольно часто коду, который нужно протестировать, требуется взаимодействовать с внешними модулями, называющимися зависимостями (в оригинальной статье используется термин collaborators, который не очень распространён в русскоязычной среде).
Модульные тесты чаще всего разрабатываются для тестирования одного изолированного класса при помощи различных вариантов моков: Mock, Stub и Spy. Так тесты будут надёжнее и будут реже ломаться по мере того, как код зависимостей эволюционирует.
Такие изолированные тесты менее подвержены проблемам при изменении внутренних деталей реализации зависимостей.
От переводчика: каждый раз, когда я использую Spock Framework для написания тестов, я чувствую, что могу ошибиться при выборе способа подмены зависимостей. В этой статье есть максимально краткая шпаргалка по выбору механизма для создания моков.
Всем привет! Я хотел бы рассказать историю о страшных конфигах и как их удалось причесать и сделать вменяемыми. Я работаю над довольно большим и относительно старым проектом, который постоянно допиливается и разрастается. Конфигурация задается с помощью маппинга xml-файлов на java-бины. Не самое лучшее решение, но оно имеет свои плюсы — например, при создании сервиса можно передать ему бин с конфигурацией, отвечающий за его раздел. Однако, есть и минусы. Самый существенный из них — нет нормального наследования профилей конфигурации. В какой-то момент я осознал, что для того, чтобы поменять одну настройку, я должен отредактировать около 30 xml-файлов, по одному для каждого из профилей. Так больше продолжаться не могло, и было принято волевое решение все переписать.
mongodb.directory.host не хотелось, использовать map-ы из map-ов тоже.Хотелось бы, чтобы конфиг выглядел примерно так:
name = "MyTest"
description = "Apache Tomcat"
http {
port = 80
secure = false
}
https {
port = 443
secure = true
}
mappings = [
{
url = "/"
active = true
},
{
url = "/login"
active = false
}
]Как я этого добился — под катом.