Мы съездили на конференцию для мобильных разработчиков 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. Мы присылали пароль прямо в письме, что не очень-то безопасно. Такой пароль можно прочесть с экрана. Появляется много вариантов, как он может утечь.

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

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

Мы продолжаем рассказывать про миграцию мобильного сервиса в ASP.NET Core и Docker. В этой статье будет идти речь про модуль WCF-клиента, упомянутый в предыдущей статье, NTLM-авторизацию и другие проблемы при его миграции. Сейчас расскажем, почему нам пришлось немного изучить анатомию и пощупать .NET Core изнутри.

Мы продолжаем наш путь к Continuous Delivery (CD) и High Availability (HA), основанной на избыточности. В предыдущей серии мы перевели API для мобильного приложения на .NET Core. Следующий логичный шаг для достижения CD — настроить сборку в Docker-контейнер.

Сегодня поделимся нашим getting-started гайдом по настройке сборки docker-образов и деплоя в Kubernetes в TFS для разработчиков .NET.

(Предполагается, что к этому моменту вы уже мигрировали ваше ASP.NET приложение на ASP.NET Core, а если нет, читайте нашу прошлую статью).

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

Один из наших java-проектов вырос, стал совсем взрослым и сейчас занимает 4 контура:

Dev — контур для команды разработки,
Qa — контур для команды тестирования,
Stage — контур для демонстрации новых фич заказчику,
Production — боевой контур.

Каждый контур содержит два одинаковых сервера с идентичным набором компонентов окружения для нашего приложения:

linux Oracle — операционная система,
jdk — комплект приложений Java,
haproxy — proxy сервер,
nginx — веб-сервер для отдачи статики,
mysql — субд.

Перед командой эксплуатации встал резонный вопрос: как настроить управление окружением на восьми серверах и сохранить оптимистичное отношение к жизни.

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

Всем привет! Этим материалом мы открываем цикл из нескольких статей, посвященных длинной истории о том, как мы пришли с одной стороны к CD, а с другой — к high availability, основанной на избыточности.

Начнем по порядку. У нас есть API для мобильного приложения, которое находится в продуктовой среде, написанный на .NET.

И первым шагом мы переводим его на .NET Core и делимся с вами тонкостями, которые встретились нам на этом пути.

Пациент приходит к врачу и жалуется на боль в животе. «Срочно на операцию! — отвечает врач. — Сейчас мы вас разрежем, покопаемся и постараемся зашить как было».

Когда пользователи ругались на работу системы, называя программистов негодяями, мы поднимали журнал событий и смотрели, что пошло не так. А потом перешли на ELK. Теперь мы мониторим ошибки в моменте, не тормозя работу сервисов.

В этой статье мы расскажем, как адаптируем и применяем стек ELK на Java и .Net-проектах и находим ошибки в онлайн режиме без вскрытия или малоинвазивными методами. Да, мы разобрались и поняли, что не очень важно, Microsoft ли сделал это решение или Open Source — всё одинаково можно настроить под свои нужды.

Делимся подробностями, как мы сделали хороший поиск по закрытой корпоративной соцсети в условиях, когда:

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

Критерий хорошего поиска для нас звучит так: даже если пользователь ввел запрос с опечаткой или неточно указал название группы, то всё равно нашёл её.

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

Однажды мы в компании EastBanc Technologies устали бороться с теми архитектурными проблемами, которые возникают в Android-разработке и решили все исправить:). Мы хотели найти решение, которое удовлетворит всем нашим требованиям.

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

Какие проблемы решали:

• Уйти от жизненного цикла экранов, будь то Activity, Fragment или View
• Уйти от необходимости писать код для сохранения и восстановления состояния для каждого экрана
• Повысить стабильность: защититься от досадных крешей и утечек памяти
• Повысить переиспользуемость кода между телефонным UI и планшетным UI

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

Но проблема в том, что приложения позволяют отследить лишь картину конкретной тренировки, ну, максимум через какое-то время насобирать статистики и составить корявый индивидуальный план. Занятия с тренером эффективнее, и уже больше защищают от травм и перетренированности, однако, когда вы занимаетесь в команде, тренер вынужден составить средний план для сферического бегуна в вакууме со средними пульсовыми зонами. Поэтому может выйти так, что пробежка в темпе 4:00 для одного члена команды будет восстановительной, а для другого выматывающей.

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

Интернет не дает ответа на вопрос «Как собирать корпоративные новости в ИТ-компании для Business to Personal издания?». А между тем, он очень интересует пиарщиков и эйчаров. Всем очевидно: сотрудников нужно информировать о происходящем в компании, рассказывать им новости с соседних проектов, планы развития, транслировать как-то ожидания начальства насчет корпоративной культуры, целей… Но как собирать эту информацию? У кого спрашивать? Как ее преподносить?

За 5 лет мы в ИТ-компании EastBanc Technologies написали 3 108 новостей в нашем корпоративном настенном издании под названием «Сводка». Примерно 2,5 новости каждый день. В этой статье мы расскажем, как и зачем делаем это. По ходу повествования будем показывать результаты опроса, посвященного сводке, в котором поучаствовали 54% сотрудников.

Сегодня расскажем, как пришли к необходимости создания единой UI/UX-системы для разных приложений одного из наших заказчиков. О том, какие принципы в нее заложили и как технологично дизайн-экосистему упаковали.



Надеемся, наш опыт будет интересен UI/UX дизайнерам, фронтэндерам, а также бренд-менеджерам, которые на собственном опыте сталкиваются с подобными задачами.

Привет! Сегодня мы расскажем, как за минимальное количество времени добавить в свою Activity поведение Scroll-To-Dismiss. Scroll-To-Dismiss – это популярный в современном мире жест, позволяющий закрыть текущий экран и вернуться в предыдущую Activity.

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

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

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

Мы в EastВanc Technologies написали некоторое количество корпоративных мобильных приложений, и всегда вопрос с установкой и обновлением вставал остро. Среди всех вариантов один нам кажется достаточно технологичным и интересным – свой магазин приложений. В посте поделимся деталями, как мы реализовали магазин под Android для пользователей корпоративных приложений.

У нас есть традиция – каждой весной мы участвуем в Днях карьеры любимого Новосибирского госуниверситета, главной кузницы наших кадров. И каждый год мы придумываем для студентов что-нибудь любопытное. В этом году сделали мастер-класс о том, как написать чат-бота. Для регистрации на мастер-класс запустили в Telegram собственного бота «Академик» @academic_quiz_bot. Его же все вместе и собирали на мастер-классе.

Если вы еще не завели себе симпатичного бота, сейчас расскажем, как выбирать тему, и, собственно, делать бота.

Сегодня расскажем, как автоматизировать создание отчетной документации по релизу (release notes) на основе импорта данных из трекинговых систем TFS, Redmine и JIRA и из системы управления проектами Microsoft Project Server.

Статья будет интересна в первую очередь менеджерам IT-проектов.