DSL (Domain-Specific Language) — это язык программирования, который спроектирован и оптимизирован для решения задач в конкретной области или для определенного класса задач. DSL build.gradle предоставляет разработчикам удобный способ определения настроек проекта и управления ими, используя специфический синтаксис, который Gradle понимает и обрабатывает. Этот DSL позволяет создавать мощные и гибкие сценарии сборки, которые могут быть легко настраиваемы для разных проектов и задач.

С Android Studio Giraffe Kotlin DSL становится новым стандартом для Gradle-скриптов в разработке Android. Когда вы создаете новые проекты, используя встроенные шаблоны IDE, вам будут предоставлены файлы Kotlin DSL вместо файлов Gradle на основе Groovy.

Это предстоящее изменение обеспечило возможность  переноса конфигураций Gradle на основе Groovy DSL на Kotlin DSL. Перевод файлов Gradle с Groovy на Kotlin DSL может значительно улучшить рабочий процесс разработки для Android. Особенно, если вы уже знакомы с Kotlin. Такой переход на единый знакомый язык не только повышает вашу производительность, но и устраняет необходимость переключаться между двумя языками для выполнения задач разработки и настройки. Надежность и интуитивность Kotlin DSL дает уверенность в создании пользовательских задач Gradle без необходимости прибегать к зачастую нечеткому синтаксису Groovy.

Статья задумана, как руководство, которое поможет вам на этапе перехода на Kotlin DSL. Материал написан с акцентом на проекты Android, но обсуждаемые моменты могут быть применимы и к другим проектам на основе Gradle, таким как приложение Spring Boot.

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

Если вы когда-нибудь сталкивались с продажами, то наверняка знаете про такое понятие как "боль клиента". Означает оно, что у каждого клиента есть потребности, определив которые, ему можно продать товар либо услугу для решения его задач.

Данная статья и родилась вследствие того, что на текущем проекте в нашей команде разработки есть боль: когда на беке вливают МР в ветку develop, то стенд падает на время деплоя. Основные участники, испытывающие эту боль — фронтенд разработчики и аналитики, которым чаще всего приходится взаимодействовать с бекендом. И во время недоступности стенда непонятно, деплой идёт или стенд упал из-за ошибки.

Нет, конечно, можно зайти в Gitlab, проверить, идёт ли сейчас деплой или посмотреть логи контейнера. Но для этого нужно быть в курсе, из-за деплоя каких конкретно микросервисов (естественно мы говорим о микросервисной архитектуре) стенд может быть временно недоступен. Ну и плох тот программист, который не хотел бы упростить жизнь себе и коллегам, автоматизировав при этом чаво-нибудь! :)

Привет, Хабр!

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

Привет, Хабр!

Несмотря на вроде бы прошедший пик громких историй, связанный с криптолокерами (ransomware), сам этот сектор «теневой экономики» продолжает генерировать различные неприятные сюжеты.

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

Интереснее другое — что дальше? С учетом того, что различные мировые игроки пытаются продавить идею о том, что шифрование это уже не просто киберкриминал, а настоящий терроризм, возникает закономерный вопрос — должны ли с ними бороться жертвы атак, то есть коммерческие компании, или же силовые госструктуры?

Или же какую-то роль на себя возьмет само сообщество хакеров?

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

И все это играет на руку создателям локеров, поскольку в этом хаосе единственный выход для тех, кто стал их целью — это платить.

Привет, Хабр!

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

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

Привет, Хабр! Сегодня мы бы хотели обсудить такую щекотливую тему как вредоносный ИИ.

TL;DR;

История провала со счастливым концом о том, как команда узнала о трассировке запросов, AOP, а потом сломала API.

ВВедение Благие намерения Невинное начало

Каждый проект содержит логирование. Наш проект использовал Lombok и его @Slf4j аннотацию. Мы логировали выполнение бизнес операций, но нам не хватало контекста.

Логи содержали что-то типа такого:

Мы хотели реализовать пагинацию и для этого нам пришлось форкнуть диалект для Hibernate.

1. Уведомление вендора
2. Подтверждение и исправление найденной уязвимости
3. Публичное раскрытие информации