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

Наш клиент — это федеральная компания-производитель. Её мерчендайзеры отвечают за наличие товаров в магазинах, представленность на полках, POSM материалы (реклама), знания продавца о продукции и др. Супервайзеры занимаются обучением, оценкой и контролем полевых сотрудников. Для этого есть корпоративные стандарты и четко регламентированный процесс.

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



Мы в True Engineering создали технологичный инструмент, который помогает супервайзерам спланировать развитие своей команды, зафиксировать результат и подвести итоги. В этой статье расскажем подробности.

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



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

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

В конце июня в Москве прошла крупная конференция о дизайне Mail.ru Design Conf × Dribbble Meetup 2019. Записи с трансляции уже в сети, поэтому мы выбрали самые интересные доклады, чтобы вам было удобно ориентироваться. Расскажем о них подробнее в статье.

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

Мы хотели бы видеть запросы нашего клиента и ответы сервиса в неизменном виде, поскольку это помогает разбирать возникающие проблемы.

В этой статье расскажем, как мы настроили выборочное логирование трафика для сервисов SOAP.

Мы в True Engineering настроили процесс непрерывной доставки обновлений на сервера заказчика и хотим поделиться этим опытом.

Для начала мы разработали онлайн систему для заказчика и развернули её в собственном кластере Kubernetes. Теперь наше высоконагруженное решение переехало на платформу заказчика, для чего мы настроили полностью автоматический процесс Continuous Deployment. Благодаря этому, мы ускорили time-to-market – доставку изменений в продуктовую среду.

В этой статье мы расскажем обо всех этапах процесса Continuous Deployment (CD) или доставки обновлений на платформу заказчика:

1. как стартует этот процесс,
2. синхронизация с Git-репозиторием заказчика,
3. сборка бекенда и фронтенда,
4. автоматическое развертывание приложения в тестовой среде,
5. автоматическое развертывание на Prod.

В процессе поделимся деталями настройки.

В Новосибирске прошла юбилейная, десятая конференция CodeFest. Программа была очень насыщенной: десять секций о разработке, тестировании, дизайне, управлении и развитии. Сотрудники True Engineering два дня конспектировали доклады, теперь хотим поделиться этой пользой с вами.

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

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

Для этого используется один API, который нужно выдать партнерам через API Gateway. Эту задачу мы и решили. В этой статье расскажем подробности.

Дано: экосистема и API-портал с интерфейсом, где пользователи зарегистрированы, получают информацию и т.п. Нам нужно сделать удобный и надежный API Gateway. В процессе нам нужно было обеспечить

• регистрацию,
• контроль подключения к API,
• мониторинг того, как пользователи используют конечную систему,
• учёт бизнес-показателей.

В статье мы расскажем о нашем опыте создания API Gateway, в ходе которого мы решали следующие задачи:

• аутентификация пользователя,
• авторизация пользователя,
• модификация исходного запроса,
• проксирование запроса,
• постобработка ответа.

Привет, хабровчане!

Мы вернулись с конференции для .NET-разработчиков DotNext и честно делимся впечатлениями про самые запомнившиеся доклады. Надеемся, наш отзыв пригодится тем, кто будет смотреть видеозаписи выступлений.

На сайте конференции опубликована часть презентаций, так что мы дополнили некоторые отзывы ссылками на них.

Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.

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

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

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

Надеемся, это поможет вам сориентироваться в видеозаписях с конференции, когда они появятся в открытом доступе. А пока мы добавили ссылки на презентации везде, где было возможно.

В чем залог успешной настройки Continuous Delivery на проектах? Слаженная работа команд разработки, тестирования и инженеров по инфраструктуре. Спасибо, кэп, как говорится :) Но как это реализовать на практике? В этой статье поделимся нашими наработками, как это всё организовать и воплотить в жизнь.

Мы обобщили базовые основы в одну шпаргалку для себя и делимся с вами:

• Какие бывают требования и чем они характеризуются,
• Типы задач и порядок их описания в Issue tracker,
• Как оформлять User story и Tech story,
• Как описывать баги,
• Настройка конвейера развертывания.

Опытные инженеры вряд ли узнают из статьи что-то новое, но надеемся, что начинающим специалистам эта информация пригодится.

Тестирование длинных web-форм в различных браузерах и в разрешениях — не только крайне необходимый, но и раз уже на третий-четвертый — исключительно нудный и требующий концентрации процесс. А значит, это именно та область, которая сама просится в автоматизацию. Этим-то мы и занялись.

В этой статье на Хабр расскажем о нашем опыте тестирования больших экранов инструментами Protractor, Zalenium и Selenium-grid. Как мы поэтапно внедряли эти инструменты автоматического UI-тестирования и через какие сложности нам пришлось пройти.

На все про все достаточно 50 чашек кофе.

Помимо обозначенного выше эмпирического правила мы публикуем краткую заметку о моментах, на которые нужно обратить пристальное внимание, чтобы на бою и в процессах ничего не сломалось. Заметку составили по горячим следам релиза мобильного сервиса, совсем мигрировавшего на .Net Сore (начало было положено тут). Нам удалось выполнить эту операцию незаметно для заказчика, почти не останавливая основной процесс разработки.

Ниже будет готовый план действий, будет очень емкий тест-лист, будет вот эта картинка для настроения:

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

Для начала достаточно ответить на два простых вопроса:

• Зачем это мне?
• Что я расскажу интересного и полезного хабраобществу?

После чего можно взять план из этой статьи (или придумать свой) и сделать это.


Есть творческие этапы и технические. В этой статье поговорим о творческих. Рассмотрим:

• Зачем писать статьи,
• Откуда взять тему для статьи,
• Где найти время, чтобы её написать,
• Основные этапы работы над текстом,
• Что делать, если статья «не идёт»,
• И с чего начать, если ты ни разу не писал на Хабр.

Надеемся, что текст пригодится и другим авторам Хабра, в том числе потенциальным.

Всем привет!

Сегодня расскажем об опыте одного из наших DevOps проектов. Мы решили реализовать новое приложение под Linux с использованием .Net Core на микросервисной архитектуре.

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

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

Поэтому использовали такие технологии:

• .Net Core для реализации микросервисов. В нашем проекте использовалась версия 2.0,
• Kubernetes для оркестрации микросервисов,
• Docker для создания образов микросервисов,
• шина интеграции Rabbit MQ и Mass Transit,
• Elasticsearch и Kibana для логирования,
• TFS для реализации конвейера CI/CD.

В этой статье поделимся подробностями нашего решения.



Это расшифровка нашего выступления на .NET-митапе, вот ссылка на видео выступления.

Мы разрабатываем рабочие инструменты для сотрудников и партнеров заказчика. Большинство созданных нами модулей содержит таблицы, реестры, карточки с детальной информацией.

Изначально основная часть модулей была заточена под веб, потому что с системами работают офисные сотрудники со стационарных компьютеров. О том, как мы проработали дизайн-систему для веба, мы писали ранее.

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

Для дизайн-проектирования это ставит нам 2 задачи:

1. Превратить большое в маленькое – перевести объемные списки в мобильное представление.



2. Разработать подход к унификации – унифицировать мобильное представление для разных списков в рамках нашей экосистемы. Чтобы пользовательский опыт был единообразным, вне зависимости от модуля, с которым работает пользователь.

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

Всем привет!

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

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

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

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

Книга рассказывает, как выстроить тестирование, чтобы не просто вылавливать баги, а избежать их появления. Она нам очень понравилась, так что мы решили на правах старожилов поддержать традицию конспектов на Хабре и выложить самые интересные тезисы.

Однажды перед нами встала задача автоматизировать различные workflow в крупной компании. Для нас это значило соединить воедино на момент старта порядка 10 систем. Причем связать всё надо было асинхронно, масштабируемо, надежно.

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

Для решения этой задачи мы решили использовать архитектуру обмена сообщениями через шину данных, и нам отлично подошел MassTransit с его Saga в связке с RabbitMQ.