Привет, хабровчане! В EastBanc Technologies ведётся большое количество проектов, связанных с мобильной разработкой. В связи с чем необходим целый зоопарк устройств для тестирования на всех этапах. И, что характерно, каждый отдельный девайс постоянно оказывается нужен самым разным людям, а найти его даже в одном отделе мобильной разработки из нескольких десятков человек — это целая история. Не говоря уже о том, что есть тестировщики, дизайнеры, PM’ы, в конце концов!

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

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

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

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

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

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

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

«Плохие графики везде. В моей работе я постоянно встречаю крайне сомнительные визуализации данных. Никто не делает плохие графики намеренно. Но это происходит. Опять и опять. В каждой компании во всех отраслях экономики сотрудниками всех уровней. Это происходит в СМИ. Это происходит там, где вы ожидаете, что люди должны уметь визуализировать данные». (с) автор книги

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



Название книги «Storytelling with Data» звучало убедительно. Выбрал её для вечернего чтения и не пожалел. В книге нет формул, хитрых и необычных графиков, сложных кейсов. Понятный английский. Качественная печать. Читается как художественная литература. Книга будет полезна всем, кому приходится делать презентации на основе данных. Думаю, что особенную пользу она принесёт тем, кто занимается аналитикой данных.

Этот обзор очень неформальный: вперемешку идут мысли автора книги, мои мысли, ситуации из моей работы, а также шпаргалки по matplotlib по ссылкам. Будет много картинок. Почти все иллюстрации перерисованы из книги на Python.

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

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

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

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


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

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

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

Всем привет!

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

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

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

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

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

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



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

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

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

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

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

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



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

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

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

В наших решениях мы используем интеграцию и с помощью Kafka, и с помощью gRPC, и с помощью RabbitMQ.

В этой статье мы поделимся нашим опытом кластеризации RabbitMQ, ноды которого размещены в Kubernetes.



До RabbitMQ версии 3.7 его кластеризация в K8S была не очень тривиальной задачей, со множеством хаков и не очень красивых решений. В версии 3.6 использовался autocluster плагин из RabbitMQ Community. А в 3.7 появился Kubernetes Peer Discovery Backend. Он встроен плагином в базовую поставку RabbitMQ и не требует отдельной сборки и установки.

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

Всем привет!

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

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

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

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

В статье мы расскажем о применении свёрточных нейронных сетей для решения практической бизнес-задачи восстановления реалограммы по фотографии полок с товарами. С помощью Tensorflow Object Detection API мы натренируем модель поиска/локализации. Улучшим качество поиска мелких товаров на фотографиях с большим разрешением с помощью плавающего окна и алгоритма подавления немаксимумов. На Keras реализуем классификатор товаров по брендам. Параллельно будем сравнивать подходы и результаты с решениями 4 летней давности. Все данные, использованные в статье, доступны для скачивания, а полностью рабочий код есть на GitHub и оформлен в виде tutorial.
 

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

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

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

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

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

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

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

• Нам понравился доклад Vyng про профайлинг. Артур Бадретдинов сделал обзор инструментов, которые можно использовать для оптимизация отображения данных и анимации. Например, Gfxinfo показывает статистику кадров, а Hierarchy Viewer – иерархию и скорость отображения компонентов экрана. Были и другие инструменты. Идея доклада в том, что нужно всегда замерять, сколько времени что занимает, и какая у тебя иерархия. Если ты всё протоколируешь, то сможешь быстро найти ошибку. Ещё раз о пользе оптимизации UI.

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

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

Есть нюанс: наш заказчик — S7 Airlines, и сама услуга — перелёт — растянута во времени. В принципе, авиаперелет в этом плане услуга совсем не уникальная. Любая перевозка, путешествие, доставка также состоят из нескольких этапов, происходящих друг за другом. И в каждой из этих ситуаций нельзя надеяться, что клиент запомнит все детали и сможет постфактум развернуто о них рассказать. Нужно что-то простое и в моменте, пока человек ещё не забыл.



Так появилось наше приложение для пассажиров S7 Airlines под iOS и Android, которые хотят помочь авиакомпании стать лучше. Для этого достаточно скачать приложение на смартфон и пройти все опросы, которые там появятся. Ниже расскажем подробнее, как мы определяем, кого, когда и в какой момент спрашивать.

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

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



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

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

Сегодня расскажем, как переводили на микросервисы монолитное решение. Через наше приложение круглосуточно проходит от 20 до 120 тысяч транзакций в сутки. Пользователи работают в 12 часовых поясах. В то же время функционал добавлялся много и часто, что довольно сложно делать на монолите. Вот почему системе требовались устойчивая работа в режиме 24/7, то есть HighLoad, High Availability и Fault Tolerance.

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

Проблематика

Мы делаем рабочие инструменты для корпоративных пользователей. Делаем их хорошо. Красивыми и понятными.

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

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

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

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

Нас смущали три момента:

1. Sharepoint, от которого мы уходим в тех местах, где он не нужен.
2. Потребность в участии администратора. Нам не хотелось отвлекать квалифицированного специалиста на подобные рутинные и частые операции.
3. Мы присылали пароль прямо в письме, что не очень-то безопасно. Такой пароль можно прочесть с экрана. Появляется много вариантов, как он может утечь.

И ещё был психологический момент: система создавала такие сложные пароли, что их было сложновато запомнить, оставалось только где-то записать.Тоже небезопасно. Зато такой пароль очень просто забыть. Можем предположить, что это обстоятельство тоже влияло на количество заявок на смену пароля.

Итак, стало понятно, что механику смены пароля пора изменить.