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

Изучая задачу, мы выяснили, что материалов об автоматизации бизнес-процессов в Camunda немного, особенно на русском языке. Поделимся своим опытом реализации проекта на Camunda, Java и Spring Boot.

Материал будет полезен в первую очередь тем, кто начинает новый процесс на Camunda, а также тем, кто находится в поиске свежего взгляда на реализацию процессов в условиях кластера с микросервисами. Планируем далее продолжить эту тему и рассказать о тестировании моделей процессов. Продолжение здесь.

Мы продолжаем делиться полезными материалами и сегодня поговорим о Selenium – инструменте тестирования web-приложений. Изучая его особенности, мы обнаружили в комьюнити ряд сообщений о различных ошибках: например, разработчики сталкивались с падением тестов, связанных с Shadow DOM, и получали ошибки в значениях root для Selenium. Однако, существует мнение, что такие сбои тестов могут оказаться не багом, а фичей. О своем подходе к работе с теневым DOM рассказал Титус Фортнер – core contributor в Selenium и автор материалов о тестировании. С разрешения автора переводим его статью, дополнив наблюдениями из нашей практики. Материал может быть полезен всем, кто занимается автоматизацией UI-тестирования с помощью Selenium.

Проводя автотесты для скорости и надежности тестирования, в разработке и процессах CI/CD зачастую используют следующий стек технологий – Jenkins, Selenoid и Allure. Можно выделить несколько их преимуществ: у Jenkins это бесплатный доступ, большое количество возможностей и плагинов для расширения; у Selenoid – независимость окружений, каждый браузер запускается в отдельном контейнере; Allure, в свою очередь, в последние годы стал популярным инструментом для построения отчетов по результатам автотестов (подробнее об этом мы писали в прошлой статье). При этом информации о том, как эти инструменты можно сочетать, до сих пор достаточно мало, и мы хотим поделиться своим примером.

Для того чтобы ускорить тестирование крупных приложений, как правило, проверки вручную сочетают с автотестами. После их прогона SDET-специалисты разбирают успешные и «упавшие» тесты – их нужно проверить вручную и зафиксировать результаты, например, в Confluence.

Рассмотрим на примере, как можно ускорить экспорт этих данных, если вы работаете с некоммерческой версией Allure Framework. При использовании Allure-EE такие доработки не нужны – информацию по ручному прохождению кейсов можно хранить в самих отчетах. 

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

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

В статье мы рассмотрим:

- что изменилось в воркфлоу сбора требований;

- в чем для аналитика плюсы и минусы онлайн-коммуникаций;

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

От корректного функционирования базы данных (БД) может зависеть не только скорость, но и надежность приложения. Для глубокого погружения в задачи специалисту, как правило, нужно освоить работу с транзакциями – об этом и пойдет речь ниже. Рассмотрим виды и свойства транзакций, а также постараемся понять, как устроен этот механизм. Надеемся, что статья может быть полезна начинающим разработчикам и всем, кто хочет лучше разобраться в теме.

Архитектура приложения — это его технологическая база, которая учитывает риски проекта, бюджет, требования и ограничения, потребности в масштабировании. 

Помимо разработки архитектуры, на старте требуется приблизительно оценить объем и стоимость проекта. Для этого мы в своей практике используем одну из проверенных методологий создания архитектуры ПО — Attribute-Driven Design (ADD). При этом мы опираемся на атрибуты качества того или иного IT-продукта. На их основе мы на этапе оценки (пресейла) создаём архитектурную концепцию системы. 

Рассмотрим этапы работы с архитектурной концепцией, возможные сложности и решения, исходя из опыта нашего Архитектурного комитета. Мы надеемся, что статья будет полезна архитекторам и разработчикам, желающим освоить методологию ADD, и может быть интересна смежным специалистам.

При написании требований к информационной системе (ИС), если она предназначена для госсектора или отдельных крупных предприятий, от подрядчика ожидают соблюдения ГОСТ 34 или 19. 

Даже частные компании могут требовать документацию по ГОСТу, считая, что следование стандартам гарантирует качество ПО. Однако, хотя такой подход обоснован в производстве мороженого и многих других продуктов, в IT-индустрии у него есть определенные минусы — и в статье мы рассмотрим их подробнее. 

Попробуем разобраться, почему вокруг ГОСТов сложилась такая ситуация и как можно выстроить работу с ними без ущерба для эффективности процессов. 

Автоматизация тестирования – неотъемлемая часть процесса обеспечения качества. Мы в нашей практике чаще всего разрабатываем тесты для веб-, мобильных приложений и API, но сегодня хотим рассказать о более редком направлении – тестировании десктоп-приложений.

Кратко рассмотрим подходы, инструменты, технологии и «грабли», на которые можно наступить при выполнении этой задачи. Статья будет полезна специалистам, которые хотят попробовать автоматизировать ежедневную монотонную работу, а также коллегам по цеху в сфере автоматизации gui-тестирования – как начинающим, так и разработчикам с опытом.

Нейронные сети и глубокое обучение (deep learning) у всех на слуху, но нейросети – это лишь  подобласть такого обширного предмета, как машинное обучение (machine learning). Существует несколько сотен других алгоритмов, которые способны быстро и эффективно решать задачи искусственного интеллекта и в большинстве случаев являются более интерпретируемыми для человека. В этой статье рассмотрим алгоритмы классического машинного обучения, принцип работы нейросетей, подготовку данных для обучения моделей и задачи, которые решают с помощью искусственного интеллекта.

Фиксация различных нарушений, контроль доступа, розыск и отслеживание автомобилей – лишь часть задач, для которых требуется по фотографии определить номер автомобиля (государственный регистрационный знак или ГРЗ). 

В этой статье мы рассмотрим создание модели для распознавания с помощью Catalyst – одного из самых популярных высокоуровневых фреймворков для Pytorch. Он позволяет избавиться от большого количества повторяющегося из проекта в проект кода – цикла обучения, расчёта метрик, создания чекпоинтов моделей и другого – и сосредоточиться непосредственно на эксперименте.

Сделать модель для распознавания можно с помощью разных подходов, например, путем поиска и определения отдельных символов, или в виде задачи image-to-text. Мы рассмотрим модель с несколькими выходами (multihead-модель). В качестве датасета возьмём датасет с российскими номерами от проекта Nomeroff Net. Примеры изображений из датасета представлены на рис. 1.

Как изменилась «удаленка» в 2021 году, после поправок в Трудовом кодексе – делимся нашим опытом. Как и многие в отрасли, мы остаемся на удаленке – для этого адаптировали к онлайну все процессы и взаимодействия в команде из 1000+ специалистов. Параллельно перестраиваем IT-офисы, вносим много изменений для будущей совместной работы. Рассмотрим правовой аспект и ответим на частые вопросы в статье, подготовленной нашей юридической службой.

Как и многие мобильные разработчики, мы с нетерпением ждали презентации Flutter и теперь хотим поделиться с читателями Хабра переводом статьи Tadas Petra о том, как можно выстроить свое обучение, если вы хотите познакомиться с Flutter и кроссплатформенными приложениями в 2021 году. Кстати, мы подключились к созданию курса Flutter, и об этом тоже расскажем в конце статьи. Приглашаем прочитать или посмотреть видеоверсию!

2021 год обещает быть очень важным для Flutter. Комьюнити разработчиков продолжает стремительно расти, а 3 марта 2021 года состоялась презентация Flutter Engage. Это делает потенциал Flutter поистине огромным.

Однако, чем более популярным становится фреймворк, тем больше людей хотят его “пощупать” и иногда не знают, с чего же, собственно, начать? В данной статье автор постарался создать roadmap и описать несколько ресурсов, которые могут быть полезны для вас. 

Бывают ситуации, когда компании-заказчику нужно рассчитать сроки реализации IT-проекта как можно быстрее – например, на старте переговоров с инвесторами. Однако, даже быстрая оценка должна содержать все предстоящие трудозатраты: на разработку, тестирование, управление и возможные риски – рисковый резерв. В этой статье мы рассмотрим процесс оценки на примере веб- и мобильных проектов. 

Ранее мы уже писали о том, когда бывает нужна автоматизация тестирования и какие проверки при этом используют. Сегодня предлагаем обсудить использование инструментов на практике и оценить их производительность. С разрешения Giovanni Rago – автора серии полезных материалов о тестировании – мы перевели его статью «Puppeteer vs Selenium vs Playwright: сравнение скорости» (Puppeteer vs Selenium vs Playwright, a speed comparison). Статья будет интересна тем, кто задумывается о выборе подходящего инструмента автоматизации в своих проектах.

Анализ тональности текста (или сентимент-анализ) – одна из задач, с которыми работают специалисты Data Science. С помощью такого анализа можно изучить массив сообщений и иных данных и определить, как они эмоционально окрашены – позитивно, негативно или нейтрально.

Рассмотрим, как это работает – проанализируем ряд статей на основании датасета Linis Crowd. Предлагаем определить, какие модели наиболее перспективны, например, для разработки всевозможных сервисов мониторинга. В качестве предметной области выберем статьи технического характера (например, на Хабре), что может быть полезно для реализации автоматического сбора мнений.