И чтобы не потерять телефон, а четко знать, где он и с кем, мы используем онлайн-базу, которая распознает сотрудников по лицам. Сейчас расскажем, как мы к этому пришли и реализовали её.
![image](https://habrastorage.org/getpro/habr/post_images/83e/934/a48/83e934a48d88da29a8d0d95c6aca33bc.jpg)
Компания True Engineering временно не ведёт блог на Хабре
На все про все достаточно 50 чашек кофе.
Помимо обозначенного выше эмпирического правила мы публикуем краткую заметку о моментах, на которые нужно обратить пристальное внимание, чтобы на бою и в процессах ничего не сломалось. Заметку составили по горячим следам релиза мобильного сервиса, совсем мигрировавшего на .Net Сore (начало было положено тут). Нам удалось выполнить эту операцию незаметно для заказчика, почти не останавливая основной процесс разработки.
Ниже будет готовый план действий, будет очень емкий тест-лист, будет вот эта картинка для настроения:
Однажды перед нами встала задача автоматизировать различные workflow в крупной компании. Для нас это значило соединить воедино на момент старта порядка 10 систем. Причем связать всё надо было асинхронно, масштабируемо, надежно.
Упрощённо процесс можно описать как последовательность действий в разных системах, которую нельзя автоматизировать полностью, поскольку она требует человеческого участия. Например, для выбора определенных действий или элементарного согласования, которое необходимо для перехода на следующий этап процесса.
Для решения этой задачи мы решили использовать архитектуру обмена сообщениями через шину данных, и нам отлично подошел MassTransit с его Saga в связке с RabbitMQ.
Проблематика
Мы делаем рабочие инструменты для корпоративных пользователей. Делаем их хорошо. Красивыми и понятными.
Но мы не имеем доступа к самим пользователям. И зачастую бывает, что то, как наше решение пользователю преподносится, сильно портит впечатление. И вместо желания скорее пользоваться новым удобным функционалом вызывает бойкот и протест.
Нам было больно и грустно, и мы решили с этим бороться. И хотим поделиться нашими наработками, как гарантировать, что пользователям представят ваше решение достойно.
У нашего заказчика есть интернет-портал и пользователи, данные которых заведены в домене. Доступ в личный кабинет — по паролю, а где пароль, там и людская забывчивость.
У нас уже была страница смены пароля, но механизм работы был не оптимальным. Вот как всё происходило. Пользователь оставлял заявку в домене на смену пароля. В ответ система, в свою очередь, оставляла заявку, которую администратор обрабатывал вручную. Он генерировал пароль в домене, после чего приписывал его в заявке. Пользователю приходило email-уведомление: “Ваш пароль изменён на такой”.
Нас смущали три момента:
И ещё был психологический момент: система создавала такие сложные пароли, что их было сложновато запомнить, оставалось только где-то записать.Тоже небезопасно. Зато такой пароль очень просто забыть. Можем предположить, что это обстоятельство тоже влияло на количество заявок на смену пароля.
Итак, стало понятно, что механику смены пароля пора изменить.