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

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

Работа в тихом городке

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

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

Буквально за пару недель я обзавёлся первыми клиентами небольшими компаниями-мелкооптовиками. В штате 10-50 работников, главбух на аутсорсе, сервер с 1С и одним общим для всех каталогом. Почту используют бесплатную, вопросами ИБ заморачиваются по минимуму. В-общем, достаточно типичный для нашей страны мелкий бизнес.

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

Токены головная боль

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

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

Всё действительно сложно

Сначала задача показалась мне простой. Технология USB over IP существует достаточно давно все токены подключены к одному устройству, а сотрудники работают с ними, как с локальными. Ничего не теряется, поскольку не покидает пределов офиса.

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

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

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

Поскольку айтишников на фултайме ни в одной конторе не было, самодельные и софтовые решения исключались. Делать, настраивать и чинить некому.

По масштабированию прекрасно подходят облака. Но цены у них откровенно кусаются. Например, сервис FlexiHub обойдётся заказчику более 10 тыс. рублей в месяц за 5 ключей, не считая стоимости хаба. И это без гарантий совместимости.

Но самое главное сервисы требуют регулярной своевременной оплаты. У небольшой компании с этим могут быть проблемы. У неё не всегда есть возможность даже зарплаты сотрудникам заплатить вовремя. Задержка в неделю-другую дело обыкновенное.

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

Если ориентироваться на мировые бренды, то надо брать Digi AnywhereUSB. За 2 USB-порта больше 20 тыс. рублей, за 14 портов в районе 150 тыс. рублей. Для небольших компаний это явно дорого.

Конечная остановка USB over IP концентратор

Перебирая варианты я пришёл к отечественному аппаратно-программному решению DistKontrolUSB. На нём и остановился. Причин этому несколько.

Прежде всего цена. За концентратор на 4 порта мой мелкий клиент заплатит 26 тыс. рублей с хвостиком, а более крупным придётся выложить около 69 тыс. рублей, но за 16 портов. Дешевле западного аналога в два раза.

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

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

Что касается управления питанием портов, то при их небольшом количестве функция лишена смысла. Проще перезагрузить концентратор полностью. Или руками перевоткнуть зависший USB-ключ.

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

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

Допустим, по соображением безопасности требуется ограничить доступ к порту по IP-адресу, а к ключу по логину и паролю. Через панель управления это делается мгновенно, причём в одном модуле. Надо всего два раза сдвинуть соответствующие ползунки и нажать на кнопу Сохранить. Изменения сразу вступят в силу.

Проблема нахождения концов актуальна не только для очень крупных организаций, но и для моих клиентов. При помощи системного журнала в WEB-интерфейсе Управляемого USB over IP концентратора решение этой задачи облегчается. В журнале хранится вся информация о подключениях и отключениях, включая логин пользователя и IP-адрес, с которого было осуществлено подключение. Кстати, пару раз пригодилось.

Раз уж дело дошло до практики, то вот ещё один пример. Хоть правило уходя гасите свет существует, но выполняется не всегда. Один мой заказчик опасался, что в ночное время какой-нибудь хакер взломает концентратор и наделает делов.

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

Итоги

Проект по оптимизации работы с токенами я начал в январе этого года. Из семи предприятий, с которыми я работаю, три уже приобрели и успешно используют USB over IP концентраторы. В одной организации это запланировано на лето. Думаю, что и оставшиеся три до конца года примут положительное решение.

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

Например, дневная задержка в оплате счёта на один миллион стоит от 100 до 1000 рублей в зависимости от договора. С отчётностью ещё хуже 5% от суммы налога. А это уже несколько тысяч даже для небольшой фирмочки. Причём, только прямого ущерба о каких-то сорвавшихся сделках я даже не говорю.

Сумму убытков из-за подобных задержек владелец компании знает. Стоимость USB over IP концентратора тоже. Срок окупаемости вычисляется без всякой высшей математики.

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

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

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

Предисловие

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

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

Первые попытки

Что делает разработчик, когда сталкивается с проблемой? Идет гуглить. Это было первое, что я сделал. Как оказалось, проблема медленного рендера таблицы Vuetify встречается с куда меньшим числом элементов, чем у меня. Что советуют:

• Рендерить элементы по частям через setInterval

• Ставить условие, чтобы не рендерить элементы, пока не сработает хук жизненного цикла mounted()

• Использовать v-lazy для последовательной отрисовки

При этом было предложение использовать компонент Virtual Scroller, позволяющий отрисовывать элементы по мере скролла, а предыдущие разрендеривать. Но этот компонент Vuetify не работает с таблицами Vuetify -_-

С "радостью" прочитав, что в Vuetify 3 (релиз через ~полгода) производительность улучшится на 50%, я стал пробовать решения. Рендер элементов по частям ничего не дал, так как на условном тысячном элементе отрисовка начинала лагать, а к семи тысячам снова всё висло. Рендер элементов на mounted не дал вообще ничего, всё зависало, но зато после того, как страница загрузится (эээ, ура?). v-lazy хоть и рендерился быстрее, но рендерить 14 тысяч компонентов (Vuetify и Transition от Vue) тоже грустное занятие.

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

Решение 1. Intersection Observer

Итак, что мы имеем. v-lazy отрисовывать невозможно, это 14 тысяч компонентов. Vuetify Virtual Scroller не поддерживается в Vuetify Data Table из-за его структуры. Выходит, нужно писать свою реализацию. Кто умеет определять, докрутил ли пользователь до элемента? Intersection Observer. Internet Explorer нам не нужен, так что можем приступать.

Первая логичная попытка: использовать директиву v-intersect от самого Vuetify. И 7 тысяч директив также привели к длительному рендеру страницы =(. Значит, выбора нет и придется работать руками.

mounted() {  //Цепляем его на таблицу с overflow: auto  //Требуемая видимость элемента для триггера: 10%this.observer = new IntersectionObserver(this.handleObserve, { root: this.$refs.table as any, threshold: 0.1 });//Почему нельзя повесить observe на все нужные элементы? Ну ладноfor (const element of Array.from(document.querySelectorAll('#intersectionElement'))) {this.observer.observe(element);}},

Теперь взглянем на сам handleObserve:

async handleObserve(entries: IntersectionObserverEntry[]) {const parsedEntries = entries.map(entry => {const target = entry.target as HTMLElement;  //Предварительно задали data-атрибутыconst project = +(target.dataset.projectId || '0');const speciality = +(target.dataset.specialityId || '0');return {          isIntersecting: entry.isIntersecting,          project,          speciality,};    });//Чтобы точно было реактивно    this.$set(this, 'observing', [      //Не добавляем дубликаты      ...parsedEntries.filter(x => x.isIntersecting && !this.observing.some(y => y.project === x.project && y.speciality === x.speciality)),      //Убираем пропавшие      ...this.observing.filter(entry => !parsedEntries.some(x => !x.isIntersecting && x.project === entry.project && x.speciality === entry.speciality)),     ]);//Иначе функция стриггерится несколько раз     Array.from(document.querySelectorAll('#intersectionElement')).forEach((target) => this.observer?.unobserve(target));     //Даем Vuetify перерендериться await this.$nextTick(); //Ждем 300мс, чтобы не триггернуть лишний раз, отрисовка тоже грузит браузер     await new Promise((resolve) => setTimeout(resolve, 500));     //Вновь обсервим элементы     Array.from(document.querySelectorAll('#intersectionElement'))          .forEach((target) => this.observer?.observe(target));},

Итак, мы имеем 7 тысяч элементов, на которых смотрит наш Intersection Observer. Есть переменная observing, в которой содержатся все элементы с projectId и specialityId, по которым мы можем определять, нужно ли показывать нужный элемент в таблице. Осталось всего-лишь повесить v-if на нужный нам элемент и отрисовывать вместо него какую-нибудь заглушку. Ура!

 <template #[`item.speciality-${speciality.id}`]="{item, headers}" v-for="speciality in getSpecialities()"><div id="intersectionElement" :data-project-id="item.id" :data-speciality-id="speciality.id"><ranking-projects-table-itemv-if="observing.some(x => x.project === item.id && x.speciality === speciality.id)":speciality="speciality":project="item"/><template v-else>Загрузка...</template></div></template>

А на саму таблицу вешаем v-once. Таблице будет запрещено менять свой рендер без $forceUpdate. Не очень красивое решение, но Vuetify непонятно чем занимается при скролле, запретим ему это делать.

<v-data-table v-bind="getTableSettings()"   v-once   :items="projects"   @update:expanded="$forceUpdate()">

Итоги:

• Рендер занимает около секунды

• Элементы разрендериваются вне их зоны видимости

• Идет ререндер на каждое действие внутри таблицы

Но при этом работать с большой таблицей невыносимо. 7 тысяч событий на каждой клетке таблицы, бесконечный набор сообщений "Загрузка...". Таблица была создана, чтобы выполнять действия быстро, и с этим решением мы релизнулись.

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

Не переписывать же мне их таблицу и создавать свой аналог?

Решение 2. Переписать таблицу и создать свой аналог

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

Что мы поняли из первого решения:

1. Таблицы Vuetify лагучий отстой

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

3. Нужно как-то сократить время на первичную отрисовку, чтобы пользователь не видел бесконечную "Загрузку"

4. Можно заставить Intersection Observer реагировать чаще, чтобы рендерить элементы по мере скролла, а не когда скролл остановится или среагирует событие (300мс задержка)

Возвращаемся к Virtual Scroller. Он не работает в таблице Vuetify, так? А что если мы напишем свою таблицу с блекджеком и display: grid? Зачем-то же его придумали.

Что нужно для Virtual Scroller? Фиксированная высота каждого элемента. Что нужно для Grid'ов? Фиксированная ширина каждого элемента и информация о количестве элементов. Бахнем CSS-переменные для последующего использования в CSS:

<div class="ranking-table" :style="{    '--projects-count': getSettings().projectsCount,    '--specialities-count': getSettings().specialitiesCount,    '--first-column-width': `${getSettings().firstColumnWidth}px`,    '--others-columns-width': `${getSettings().othersColumnsWidth}px`,    '--cell-width': `${getSettings().firstColumnWidth + getSettings().othersColumnsWidth * getSettings().specialitiesCount}px`,    '--item-height': `${getSettings().itemHeight}px`  }">

Потом пишем гриды по типу аля

display: grid;grid-template-columns:var(--first-column-width)repeat(var(--specialities-count), var(--others-columns-width));

И так далее для элементов внутри. Класс! А еще мы, зная ширину и количество элементов, можем задать ширину нашему Virtual Scroller (он сам по умолчанию туповат), а заодно и всем нашим элементам, чтобы не дай боже кто-то вышел за доступные ему границы

.ranking-table_v2__scroll::v-deep {.v-virtual-scroll {&__container, &__item, .ranking-table_v2__project {    width: var(--cell-width);}}}

Примечание: если вы сделаете просто <style>без scoped и решите, что будет хорошей идеей редактировать глобальные стили вне окружения компонента, то у меня для вас плохие новости: лучше так не делать вне каких-то App.vue, и стоит ознакомиться с тем, что это за v-deep.

Поехали: добавляем Virtual Scroller, пихаем в него проекты, после чего выводим последние. Сразу скажу: поддержки Expandable Items у нас тут нет, я вынес информацию о проекте во всплывающее окно. Жаль, конечно, что нельзя это отображать прямо в таблице, как делал Vuetify, но тогда придется помучаться с их скроллером, а он и так не особо хорошо работает. В общем, к делу:

<v-virtual-scroll   class="ranking-table_v2__scroll"   :height="getSettings().commonHeight":item-height="getSettings().itemHeight":items="projects"><template #default="{item}"><div class="ranking-table_v2__project" :key="item.id"><!-- ... -->

Итого: на страницу, допустим, помещается 6 проектов (высота же у всех максимальная по факту), итого рендерится 6 строк + шапка. Колонок 50. Итого рендерится около 300 сложных компонентов. А вот это уже задача не уровня мстителей, 300 мы рендерить умеем.

Вспоминаем про лучший инструмент всех времен и народов v-lazy: он позволяет отрендерить элемент один раз и потом не перерендеривать его. Раньше мы пытались отрендерить 14 тысяч компонентов, сейчас 600 простых. Ну и оборачиваем все наши колонки (кроме шапки) в v-lazy. При горизонтальном скролле элементы подгружаются, и остаются отрендеренными до тех пор, пока сама строка таблицы не пропадет из области видимости и не разрендерится.

 <v-lazy class="ranking-table_v2__item ranking-table_v2__item--speciality"v-for="(speciality, index) in specialities":key="speciality.id">   <!-- Колонка в строке таблицы --></v-lazy>

Видео с разницей, можно сравнить:

Плюсы такого решения:

• Элементы перестали скакать как ненормальные

• Нет нужды писать свою реализацию логики рендера/отрендера

• Можем отказаться от v-once и всяких принудительных ререндеров аля $forceUpdate

• Куда больше гибкости при верстке таблицы

Минусы:

• Если используются выпадающие элементы (expand), нужно писать свою реализацию

• Нужно верстать таблицу самому, без инструментов движка

• Нет средств сортировки/группировки и прочего (мне было не нужно)

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

• Чтобы отображать таблицу в нужном мне проценте от высоты страницы, мне пришлось смотреть на window.innerHeight и применять его в CSS переменных и в значении высоты у VirtualScroll

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

Заключение

Я привел 2 варианта решения проблем с производительностью отрисовки таблиц в Vuetify. Оба решения достаточно сложные, просто сложные в разных аспектах. Оба так или иначе помогли мне решить мою проблему, и у обоих есть свои ограничения. Например, второй вариант мне нравится больше, но отсутствие средств Vuetify (сортировка/группировка и пр.) может оттолкнуть тех, кому это позарез нужно.

Зачем я это пишу? Я перегуглил половину интернета и не нашел простых решений своей проблемы. Наверное, как раз таки потому, что этих решений нет. Эти таблицы не предназначались для сложной логики, даже в условных гугловских таблицах элементов отрисовывается меньше, потому что там буквально один инпут, изредка с каким-то контентом, здесь же - гигантская куча логики.

И да: я пользовался дебагером производительности от Vue и смотрел, кто её потребляет. Зачастую там был буквально один-два компонента, и, заменив их на какой-то другой с похожей логикой, проблема не решалась - дело в их количестве, а не сложности (не считая таблицу Vuetify - там передается множество props'ов из компонента в компонент).

Надеюсь, что приведенные мной варианты натолкнут кого-то на решение его проблемы, а кто-то просто узнает что-то новое =). Будем вместе ждать стабильный Vue 3 со всей его экосистемой, как минимум Nuxt 3. Что-то обещают множество улучшений, может, часть костылей из этой статьи даже пропадет.

В богатой экосистеме Тинькофф есть лайфстайл-сервисы. Купить билеты на различные мероприятия - в кино, театры, на концерты, спортивные события можно на https://www.tinkoff.ru/entertainment/, а также в мобильном приложении.

Меня зовут Вадим и я расскажу вам, как мы это делали в команде Развлечений в Тинькофф Банке.

Что нужно, чтобы купить билет в кино?

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

Мы придумали три варианта реализации такой схемы.

1. Сделать все на старом добром HTML

Плюсы:

• Удобно стилизовать.

• Удобно работать в React.

• Все доступно (A11Y).

Минусы:

• Растет количество DOM-нод и глубина DOM-дерева (пример на изображении выше).

• Проблемы с производительностью при взаимодействии с пользователем (перемещение схемы).

2. Использовать SVG

Плюсы и минусы примерно такие же, как и с HTML.

3. Canvas

Плюсы:

• Удобно стилизовать (можно нарисовать что угодно).

• Меньше проблем с производительностью.

Минусы:

• Не получится совместить с Server Side Rendering.

• Проблемы с A11Y (нет из коробки).

Мы решили делать схему на canvas, потому что нам важно, чтобы все было красиво и с приятным UX для пользователя. Также с технической стороны у нас пропадают проблемы с глубиной DOM-дерева и количеством нод в нем. Тем более что canvas без проблем работает даже в Internet Explorer 11.

Конечно, на наше решение повлияло и то, что использовать canvas намного интереснее, чем просто работать с SVG- и HTML-решениями.

Экосистема вокруг canvas

Итак, мы отправились выбирать библиотеку для более удобной работы с canvas. Как оказалось, их существует достаточно большое количество, из самых популярных Konva, PixiJS, Fabric.js и Phaser.

Из этого многообразия мы выбрали PixiJS. Ключевые особенности Pixi: он быстрый, гибкий и производительный. Также наши коллеги активно рекомендовали использовать именно его.

Простой код на PixiJS. Мы инстанцируем Pixi.Appс заданным конфигом (например, ширину, высоту, цвет фона, разрешение). Добавляем объекты на сцену (Stage в терминологии Pixi), пишем простой цикл и получаем сетку 5 5 из кроликов, которые вращаются вокруг своей оси пример с официального сайта Pixi

Структура и читаемость

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

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

Вписываем в React

Кроме сложности понимания кода возникает другой вопрос: как это вписать в парадигму React?

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

Одно из решений, которое понравилось нам, библиотека react-pixi-fiber. Ее плюс в том, что мы пишем привычный нам JSX, а под капотом происходит взаимодействие с Pixi и мы получаем наш canvas.

В этой библиотеке у нас уже есть обертки для всех нативных объектов Pixi. К примеру, вместо инстанцирования класса Pixi.Textмы используем react-элемент <Text />.

Также есть удобное АПИ для создания своих объектов CustomPIXIComponent

Приблизительно так теперь выглядит код для нашей схемы выбора мест. Здесь уже нет никаких инстансов Pixi, у нас обычный JSX: компоненты Stage, Container, посадочные места, привычный маппинг данных на react-компоненты.

А вот как выглядит создание своего компонента. Он немного отличается от привычных react-компонентов, но, если разобраться, по сути тут все то же самое. У нас есть ссылка на отображаемый компонент graphics и привычное слово props. Также почти привычным образом мы можем использовать обработчики событий, например ховер, клик и так далее.

Применяем все на практике

Какие у нас были вводные для отрисовки кресел?

У нас была информация в виде массива объектов. В каждом данные, необходимые для отрисовки сиденья: размеры, координаты, номер места и ряда.

Наша задача сделать так, чтобы в любых сочетаниях кресла смотрелись красиво.

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

Вариант с загрузкой кресла как простой текстуры мы сразу отбросили: были проблемы с отображением на retina-экранах и в целом с изменением размеров без визуальной деформации. А с SVG в то время были проблемы у PixiJS: некорректно работала подгрузка ассетов в SVG.

Поэтому мы решили сами рисовать каждое кресло.

Рисуем кресло на PixiJS

Для удобства мы разделили кресло на сектора:

A полукруглые края подлокотников.
B подлокотник.
C кривая от подлокотников до спинки кресла.
D спинка кресла.
E верхняя часть кресла.
F средняя часть кресла.
G нижняя часть кресла.

Ширина одной клетки width / 22.
Высота одной клетки height / 16.
Кресло в макете у нас имеет размер 22 пикселя на 16, таким образом, каждая черточка или буковка это пиксель в сетке.

Затем мы разделили эту сетку на зоны: подлокотники, спинка и так далее. И отрисовали все по частям, используя PixiJS и CustomPIXIComponent.

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

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

Схемы секторов

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

От наших партнеров приходила такая схема секторов.
Собственно массив секторов в поле sectors с информацией о каждом секторе, название площадки, а также строка hallScheme, которая занимает почти 236 килобайт.

Как оказалось, это схема секторов площадки в SVG и закодирована в base64.

Что же нам с этим делать?

Первым нашим решением было парсить этот SVG и как-то перевести на PixiJS.

Второй вариант просто вставить это как HTML, повесить обработчики через стандартные методы.

Рассмотрев эти варианты и взвесив плюсы и минусы, мы решили пойти дальше и сделать третий вариант парсить эту SVG и превращать ее в react-элементы.

Выбором для парсера стал html-react-parser. Эта библиотека парсит любой валидный HTML в react-элементы. Работает как на стороне Node.js, так и на стороне браузера. Но решающим стало то, что любой элемент из оригинальной разметки можно заменить на что угодно.

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

Здесь уже опять привычный нам JSX и полный контроль над всем, что нужно: обработчики событий, стилизация и так далее.

Поговорим об оптимизации

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

Используя инструменты разработчика, мы видим, что даже при простое приблизительно каждые 16 мс вызывается одна и та же таска. Сразу видно некий Ticker_tick

В замечательной документации по Pixi можно найти упоминание об этом тикере. Как понятно из описания, это некий цикл, который выполняет что-то за некий интервал времени, в нашем случае приблизительно каждые 16 мс.

Но почему именно 16 миллисекунд?

Вспомним понятие 60 кадров в секунду - это нужно, чтобы обеспечить плавность анимации и перемещений. Также, новые фильмы снимают в 60 кадров в секунду, что дает более плавную картинку.

Чтобы получить такую частоту обновления, нужно каждую секунду обновлять изображение 60 раз: 1000 мс 60 = 16,6666 мс.

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

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

Как видно, вся работа с Pixi происходит внутри компонента Stage от react-pixi-library. К сожалению, официальных способов от создателей react-pixi-library по работе с Ticker нет.

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

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

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

Пока мы все это изучали, обнаружили, что у Pixi на Github есть целая wiki, где очень много интересной информации:

• Gotchas

• Cоветы по улучшению производительности

• Различные трюки

Забавно, что на оффициальном сайте Pixi ссылку на эту wiki не найти.

Главный совет по оптимизации заключается в том, что инстансы объектов Pixi.Graphics стоят дорого и не кэшируются, в отличие от текстур, спрайтов и так далее. А наши кресла, как сложные объекты, как раз и являются инстансами Pixi.Graphics.

Выводы

Какие выводы из этого всего можно сделать?

1. Чем меньше оберток тем более гибко мы можем оптимизировать приложение.

2. Работа с canvas отличается от обычных рутинных задач.

3. Pixi заточен под более интерактивные вещи, например игры.

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

Нормализация. От нее мы или страдаем или пишем собственное решение с множеством проверок на существование сущности в общем хранилище. Попробуем разобраться и решить эту проблему!

Описание проблемы

Представим себе такую последовательность:

1. Клиентское приложение запрашивает список пользователей запросом к /users и получается пользователей с id от 1 до 10

2. Пользователь с id 3 меняет свое имя

3. Клиентское приложение запрашивает пользователя с id 3 с помощью запроса к /user/3

Вопрос:Какое имя пользователя с id 3 будет в приложении?
Ответ:Зависит от компонента, который запросил данные. В компоненте, который использует данные из запроса к /users, будет отображаться старое имя. В компоненте, который использует данные из запроса к /user/3, будет отображаться новое имя.

Вывод: В таком случае в системе существует несколько одинаковых по смыслу сущностей с разным набором данных.

Вопрос:Почему это плохо?
Ответ:В лучшем случае пользователь увидит разные имена одного человека в разных разделах сайта, в худшем переведет деньги на старые банковские реквизиты.

Варианты решения

В настоящее время существуют следующие варианты решения этой проблемы:

• Не обращать внимание

• Нормализовать данные собственноручно

• Использовать клиент graphql (apollo или relay)

Не обращать внимание

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

Нормализовать данные собственноручно

Примером собственноручной реализации может послужить код для mobx:

class Store {  users = new Map();  async getUsers() {    const users = await fetch(`/users`);    users.forEach((user) => this.users.set(user.id, user));  }  async getUser(id) {    const user = await fetch(`/user/${id}`);    this.users.set(user.id, user);  }}

И если пример с mobx выглядит приемлемо, то нормализация в redux простоужасает. Работать с таким кодом становится сложнее по мере его увеличения и совсем неинтересно

Использовать клиент graphql (apollo или relay)

Apollo и relay это библиотеки, которые из коробки умеют нормализовать данные. Однако такое решение заставляет нас использовать graphql и apollo, которые, по моему мнению, имеют множество недостатков.

Нормализация

Что такое нормализация и как она позволяет graphql клиентам бороться с указанной проблемой? Разберемся на примере apollo! Так apollo описывает свои действия с данными:

...normalizesquery response objects before it saves them to its internal data store.

Что включает в себя указанноеnormalize?

Normalization involves the following steps:

1. The cache generates a unique ID for every identifiable object included in the response.
2. The cache stores the objects by ID in a flat lookup table.

То есть apollo формирует уникальный идентификатор для каждой сущности, для которой возможно его сформировать. Apollo использует его как ключ в хранилище всех сущностей. Вот как примерно выглядит формирование идентификатора и его хранение:

const store = new Map();const user = {  id: '0',  type: 'user',  name: 'alex',  age: 24,};const id = `${user.type}:${user.id}`;store.set(id, user);

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

Получение уникального идентификатора

Apollo достигает указанного эффекта, запрашивая при каждом запросе внутреннее поле __typename, а как достигнуть похожего эффекта без graphql?

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

• сделать поле id или аналогичное поле глобально уникальным

• добавить информацию о типах сущности в данные

  • добавить типы на сервере

  • добавить типы на клиенте

Сделать поле глобально уникальным

В таком случае хранение сущностей будет выглядеть вот так:

const store = new Map();const user = {  id: '0',};const comment = {  id: '1',};store.set(user.id, user);store.set(comment.id, comment);// ...store.get('0'); // userstore.get('1'); // comment

Решение выглядит достаточно удобным в использовании, однако реализация глобально уникальных полей id будет затруднительна. Как правило, сущности хранятся в базе данных и имеют id уникальный только внутри коллекции/таблицы (или другими словами какого-то типа). А значит, чтобы сделать id глобально уникальным, нужно приложить много усилий.

Добавить информацию о типах

В таком случае хранение сущностей выглядеть вот так:

const store = new Map();const user = {  id: '0',  type: 'user', // <-- new field};const comment = {  id: '1',  type: 'comment', // <-- new field};function getStoreId(entity) {  return `${entity.type}:${entity.id}`;}store.set(getStoreId(user), user);store.set(getStoreId(comment), comment);// ...store.get('user:0'); // userstore.get('comment:1'); // comment

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

Где добавлять типы в данные?

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

• На сервере, при отдаче данных:

app.get('/users', (req, res) => {  const users = db.get('users');  const typedUsers = users.map((user) => ({    ...user,    type: 'user',  }));  res.json(typedUsers);});

• На клиенте, при получении данных:

function getUsers() {  const users = fetch('/users');  const typedUsers = users.map((user) => ({    ...user,    type: 'user',  }));  return typedUsers;}

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

Теперь разберемся как все это автоматизировать.

iresine

iresineэто библиотека созданная для нормализации данных и оповещении об их изменении.

В данный момент iresine состоит из следующих модулей:

• @iresine/core

• @iresine/react-query

Так iresine работает с react-query:

@iresine/core

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

const iresine = new Iresine();const oldRequest = {  users: [oldUser],  comments: {    0: oldComment,  },};// new request data have new structure, but it is OK to iresineconst newRequest = {  users: {    0: newUser,  },  comments: [newComment],};iresine.parse(oldRequest);iresine.parse(newRequest);iresine.get('user:0' /*identifier for old and new user*/) === newRequest.users['0']; // trueiresine.get('comment:0' /*identifier for old and new comment*/) === newRequest.comments['0']; // true

Как видим из идентификаторов, по которым мы получаем сущности из хранилища, @iresine/core использует следующую схему для создания идентификаторов:

entityType + ':' + entityId;

По умолчанию @iresine/core берет тип из поляtype, а id из поляid. Это поведение можно изменить, передав собственные функции. Например попробуем использовать такой же идентификатор как в apollo:

const iresine = new Iresine({  getId: (entity) => {    if (!entity) {      return null;    }    if (!entity.id) {      return null;    }    if (!entity.__typename) {      return null;    }    return `${entity.__typename}:${entity.id}`;  },});

Так же мы можем обрабатывать и глобально уникальное поле id:

const iresine = new Iresine({  getId: (entity) => {    if (!entity) {      return null;    }    if (!entity.id) {      return null;    }    return entity.id;  },});

А что @iresine/core делает с сущностями, где идентификатор не обнаружен? Например такими:

const user = {  id: '0',  type: 'user',  jobs: [    {      name: 'milkman',      salary: '1$',    },    {      name: 'woodcutter',      salary: '2$',    },  ],};

user имеет своей идентификатор в хранилище, а как быть с jobs? У них нет ни поля type ни поля id! @iresine/core следует простому правилу: если у сущности нет идентификатора, то она становится частью ближайшей родительской сущности с идентификатором.

@iresine/core являет универсальной библиотекой, которая знает о том как распарсить данные и точечно уведомлять подписчиков. Но использовать ее напрямую довольно нудно и утомительно! Посмотрим как сделать этот процесс удобнее.

@iresine/react-query

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

@iresine/react-query это плагин для react-query. Он позволяет использовать функцию нормализации и обновления данных @iresine/core на данных хранилища react-query. Вся работа по нормализации происходит автоматически и клиент работает с react-query так, как бы работал без iresine.

import Iresine from '@iresine/core';import IresineReactQuery from '@iresone/react-query';import {QueryClient} from 'react-query';const iresineStore = new IresineStore();const queryClient = new QueryClient();new IresineReactQueryWrapper(iresineStore, queryClient);// now any updates in react-query store will be consumbed by @iresine/core

Схема взаимодействия выглядит так(была приведена выше):

Итог

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

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

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

Задача

Допустим, у нас есть матрица A порядка 2000x2000. Нужно посчитать обратную ей матрицу по простому модулю N. Другими словами, надо найти такую матрицу A^-1, что AA^-1 mod N = E.

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

Этот пост посвящён оптимизации метода Гаусса под данный конкретный случай. В реальном проекте вычисление обратной матрицы происходит в отдельном WebWorker, в данном примере обойдёмся главным потоком.

Вспомогательные функции

Для работы программы нам потребуется четыре вспомогательные функции. Первая вычисление (1 / x) mod N по расширенному алгоритму Евклида:

function invModGcdEx(x, domain){    if(x === 1)    {        return 1;    }    else    {        //В случае 0 или делителя нуля возвращается 0, означающий некий "некорректный результат"        if(x === 0 || domain % x === 0)        {            return 0;        }        else        {            //Расширенный алгоритм Евклида, вычисляющий такое число tCurr, что tCurr * x + rCurr * N = 1            //Другими словами, существует такое число rCurr, при котором tCurr * x mod N = 1            let tCurr = 0;            let rCurr = domain;            let tNext = 1;            let rNext = x;            while(rNext !== 0)            {                let quotR = Math.floor(rCurr / rNext);                let tPrev = tCurr;                let rPrev = rCurr;                tCurr = tNext;                rCurr = rNext;                tNext = Math.floor(tPrev - quotR * tCurr);                rNext = Math.floor(rPrev - quotR * rCurr);            }            tCurr = (tCurr + domain) % domain;            return tCurr;        }    }}

Вторая корректное целочисленное деление по модулю. Наивное вычисление c = a % b во всех языках программирования не будет давать математически верный результат, если a отрицательное число. Поэтому заведём функцию, которая будет делить правильно:

function wholeMod(x, domain){    return ((x % domain) + domain) % domain;}

Последние две функции относятся к операциям над строками матрицы. Первая вычитание из строки матрицы домноженной на число другой:

function mulSubRow(rowLeft, rowRight, mulValue, domain){    for(let i = 0; i < rowLeft.length; i++)    {        rowLeft[i] = wholeMod(rowLeft[i] - mulValue * rowRight[i], domain);    }}

Последняя нужная нам функция умножение строки матрицы на число:

function mulRow(row, mulValue, domain){    for(let i = 0; i < row.length; i++)    {        row[i] = (row[i] * mulValue) % domain;    }}

Обращение матрицы

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

function invertMatrix(matrix, domain){    let matrixSize = matrix.length;    //Инициализируем обратную матрицу единичной    let invMatrix = [];    for(let i = 0; i < matrixSize; i++)    {        let matrixRow = new Uint8Array(matrixSize);        matrixRow.fill(0);        matrixRow[i] = 1;        invMatrix.push(matrixRow);    }    //Прямой ход: приведение матрицы к ступенчатому виду    for(let i = 0; i < matrixSize; i++)    {        let thisRowFirst = matrix[i][i];        if(thisRowFirst === 0 || (thisRowFirst !== 1 && domain % thisRowFirst === 0)) //Первый элемент строки 0 или делитель нуля, меняем строку местами со следующей строкой, у которой первый элемент не 0        {            for(let j = i + 1; j < matrixSize; j++)            {                let otherRowFirst = matrix[j][i];                if(otherRowFirst !== 0 && (otherRowFirst === 1 || domain % otherRowFirst !== 0)) //Нашли строку с ненулевым первым элементом                {                    thisRowFirst = otherRowFirst;                                        let tmpMatrixRow = matrix[i];                    matrix[i]        = matrix[j];                    matrix[j]        = tmpMatrixRow;                    let tmpInvMatrixRow = invMatrix[i];                    invMatrix[i]        = invMatrix[j];                    invMatrix[j]        = tmpInvMatrixRow;                    break;                }            }        }        //Обнуляем первые элементы всех строк после первой, отнимая от них (otherRowFirst / thisRowFirst) * x mod N        let invThisRowFirst = invModGcdEx(thisRowFirst, domain);        for(let j = i + 1; j < matrixSize; j++)        {            let otherRowFirst = matrix[j][i];            let mulValue      = invThisRowFirst * otherRowFirst;            if(otherRowFirst !== 0 && (otherRowFirst === 1 || domain % otherRowFirst !== 0))            {                mulSubRow(matrix[j],    matrix[i],    mulValue, domain);                mulSubRow(invMatrix[j], invMatrix[i], mulValue, domain);            }        }    }    //Обратный ход - обнуление всех элементов выше главной диагонали    let matrixRank = matrixSize;    for(let i = matrixSize - 1; i >= 0; i--)    {        let thisRowLast    = matrix[i][i];        let invThisRowLast = invModGcdEx(thisRowLast, domain);        for(let j = i - 1; j >= 0; j--)        {            let otherRowLast = matrix[j][i];            let mulValue     = invThisRowLast * otherRowLast;            if(otherRowLast !== 0 && (otherRowLast === 1 || domain % otherRowLast !== 0))            {                mulSubRow(matrix[j],    matrix[i],    mulValue, domain);                mulSubRow(invMatrix[j], invMatrix[i], mulValue, domain);            }        }        if(thisRowLast !== 0 && domain % thisRowLast !== 0)        {            mulRow(matrix[i],    invThisRowLast, domain);            mulRow(invMatrix[i], invThisRowLast, domain);        }        if(matrix[i].every(val => val === 0))        {            matrixRank -= 1;        }    }    return {inverse: invMatrix, rank: matrixRank};}

Проверим скорость на матрице 500 x 500, заполненной случайными значениями из поля Z / 29. После 5 испытаний получаем среднее время выполнения в ~9.4с. Можем ли мы сделать лучше?

Первое, что мы можем заметить в поле Z / N не больше N обратных элементов. Чтобы избежать многократного вызова алгоритма Евклида, мы можем вычислить все обратные значения один раз и при надобности брать уже готовые. Изменим функцию соответствующим образом:

function invertMatrixCachedInverses(matrix, domain){    let matrixSize = matrix.length;    //Инициализируем обратную матрицу единичной    let invMatrix = [];    for(let i = 0; i < matrixSize; i++)    {        let matrixRow = new Uint8Array(matrixSize);        matrixRow.fill(0);        matrixRow[i] = 1;        invMatrix.push(matrixRow);    }    //Вычисляем все обратные элементы заранее    let domainInvs = [];    for(let d = 0; d < domain; d++)    {        domainInvs.push(invModGcdEx(d, domain));    }    //Прямой ход: приведение матрицы к ступенчатому виду    for(let i = 0; i < matrixSize; i++)    {        let thisRowFirst = matrix[i][i];        if(domainInvs[thisRowFirst] === 0) // <--- Первый элемент строки 0 или делитель нуля, меняем строку местами со следующей строкой, у которой первый элемент не 0        {            for(let j = i + 1; j < matrixSize; j++)            {                let otherRowFirst = matrix[j][i];                if(domainInvs[otherRowFirst] !== 0) // <--- Нашли строку с ненулевым первым элементом                {                    thisRowFirst = otherRowFirst;                                        let tmpMatrixRow = matrix[i];                    matrix[i]        = matrix[j];                    matrix[j]        = tmpMatrixRow;                    let tmpInvMatrixRow = invMatrix[i];                    invMatrix[i]        = invMatrix[j];                    invMatrix[j]        = tmpInvMatrixRow;                    break;                }            }        }        //Обнуляем первые элементы всех строк после первой, отнимая от них (otherRowFirst / thisRowFirst) * x mod N        let invThisRowFirst = domainInvs[thisRowFirst]; // <---        for(let j = i + 1; j < matrixSize; j++)        {            let otherRowFirst = matrix[j][i];            let mulValue      = invThisRowFirst * otherRowFirst;            if(domainInvs[otherRowFirst] !== 0) // <---            {                mulSubRow(matrix[j],    matrix[i],    mulValue, domain);                mulSubRow(invMatrix[j], invMatrix[i], mulValue, domain);            }        }    }    //Обратный ход - обнуление всех элементов выше главной диагонали    let matrixRank = matrixSize;    for(let i = matrixSize - 1; i >= 0; i--)    {        let thisRowLast    = matrix[i][i];        let invThisRowLast = domainInvs[thisRowLast]; // <---        for(let j = i - 1; j >= 0; j--)        {            let otherRowLast = matrix[j][i];            let mulValue     = invThisRowLast * otherRowLast;            if(domainInvs[otherRowLast] !== 0) // <---            {                mulSubRow(matrix[j],    matrix[i],    mulValue, domain);                mulSubRow(invMatrix[j], invMatrix[i], mulValue, domain);            }        }        if(domainInvs[thisRowLast] !== 0) // <---        {            mulRow(matrix[i],    invThisRowLast, domain);            mulRow(invMatrix[i], invThisRowLast, domain);        }        if(matrix[i].every(val => val === 0))        {            matrixRank -= 1;        }    }    return {inverse: invMatrix, rank: matrixRank};}

Замерим на тех же условиях и получаем результат в те же ~9.4с. Прироста нет, потому что даже при относительно долгом вычислении алгоритма Евклида он вычисляется всего один раз для каждой строки матрицы и особого вклада во время не приносит. Замерим производительность и посмотрим, что ещё можно улучшить.

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

...Или всё же возможно?

Если деление по модулю занимает столько времени, может, все возможные результаты тоже стоит сохранить в кэш? Даже если это не поможет, попытаться всё равно стоит при текущем времени выполнения функция неюзабельна.

Итак, используется wholeMod()только в функции mulSubRow():

rowLeft[i] = wholeMod(rowLeft[i] - mulValue * rowRight[i], domain);

Нам нужно для всех возможных значений x = a - b * c в поле Z / N сохранить результат выражения x mod N. Воспользоваться периодичностью мы не сможем, потому что тогда для вычисления индекса снова придётся использовать деление по модулю. В итоге при 0 <= a, b, c < N получаем N + (N - 1)^2 возможных значений. Много, но деваться некуда.

Из этих значений (N - 1)^2 значений меньше 0. Поскольку отрицательные индексы невозможны, при индексировании значением a - b * c к нему нужно прибавить (N - 1)^2. Тогда функция для сложения строк модифицируется:

function mulSubRowCached(rowLeft, rowRight, mulValue, wholeModCache, cacheIndexOffset){    for(let i = 0; i < rowLeft.length; i++)    {        rowLeft[i] = wholeModCache[rowLeft[i] - mulValue * rowRight[i] + cacheIndexOffset];    }}

Заметим, что эта функция накладывает ограничение на mulValue его значение не может быть больше domain и перед вызовом функции его тоже надо привести в наше поле Z / N. Кроме этого, обычное деление по модулю используется в функции mulRow().

Помимо wholeMod в вычитании строк матриц, используется . Кроме того, появилась вышеуказанная проблема с ограничением mulValue. Во всех этих случаях деление описывается формулой x = (a * b) mod N. Зная, что кэш хранит значения x = (c - a * b) mod N, мы можем вычислить (a * b) mod N, взяв значение кэша при c = 0 и вычтя его из N. Тогда функция для умножения строки на число модифицируется следующим образом:

function mulRowCached(row, mulValue, domain, wholeModCache, cacheIndexOffset){    for(let i = 0; i < row.length; i++)    {        row[i] = domain - wholeModCache[cacheIndexOffset - row[i] * mulValue];    }}

И получаем новое обращение матрицы:

function invertMatrix(matrix, domain){    let matrixSize = matrix.length;    //Инициализируем обратную матрицу единичной    let invMatrix = [];    for(let i = 0; i < matrixSize; i++)    {        let matrixRow = new Uint8Array(matrixSize);        matrixRow.fill(0);        matrixRow[i] = 1;        invMatrix.push(matrixRow);    }    //Вычисляем все обратные элементы заранее    let domainInvs = [];    for(let d = 0; d < domain; d++)    {        domainInvs.push(invModGcdEx(d, domain));    }    //Вычисляем кэш деления по модулю    const сacheIndexOffset = (domain - 1) * (domain - 1);    let wholeModCache = new Uint8Array((domain - 1) * (domain - 1) + domain);     for(let i = 0; i < wholeModCache.length; i++)    {        let divisor      = i - сacheIndexOffset;      //[-domainSizeCacheOffset, domainSize - 1]        wholeModCache[i] = wholeMod(divisor, domain); //Whole mod    }    //Прямой ход: приведение матрицы к ступенчатому виду    for(let i = 0; i < matrixSize; i++)    {        let thisRowFirst = matrix[i][i];        if(domainInvs[thisRowFirst] === 0) //Первый элемент строки 0 или делитель нуля, меняем строку местами со следующей строкой, у которой первый элемент не 0        {            for(let j = i + 1; j < matrixSize; j++)            {                let otherRowFirst = matrix[j][i];                if(domainInvs[thisRowFirst] !== 0) //Нашли строку с ненулевым первым элементом                {                    thisRowFirst = otherRowFirst;                                            //Меняем строки местами                    let tmpMatrixRow = matrix[i];                    matrix[i]        = matrix[j];                    matrix[j]        = tmpMatrixRow;                    let tmpInvMatrixRow = invMatrix[i];                    invMatrix[i]        = invMatrix[j];                    invMatrix[j]        = tmpInvMatrixRow;                    break;                }            }        }        //Обнуляем первые элементы всех строк после первой, отнимая от них (otherRowFirst / thisRowFirst) * x mod N        let invThisRowFirst = domainInvs[thisRowFirst]; // <---        for(let j = i + 1; j < matrixSize; j++)        {            let otherRowFirst = matrix[j][j];            if(domainInvs[otherRowFirst] !== 0)            {                let mulValue = domain - wholeModCache[сacheIndexOffset - otherRowFirst * invThisRowFirst]; // <---                mulSubRowCached(matrix[j],    matrix[i],    mulValue, wholeModCache, сacheIndexOffset); // <---                mulSubRowCached(invMatrix[j], invMatrix[i], mulValue, wholeModCache, сacheIndexOffset); // <---            }        }    }    //Обратный ход - обнуление всех элементов выше главной диагонали    let matrixRank = matrixSize;    for(let i = matrixSize - 1; i >= 0; i--)    {        let thisRowLast    = matrix[i][i];        let invThisRowLast = domainInvs[thisRowLast];        for(let j = i - 1; j >= 0; j--)        {            let otherRowLast = matrix[j][i];            if(domainInvs[otherRowLast] !== 0)            {                let mulValue = domain - wholeModCache[сacheIndexOffset - otherRowLast * invThisRowLast]; // <---                mulSubRowCached(matrix[j],    matrix[i],    mulValue, wholeModCache, сacheIndexOffset); // <---                mulSubRowCached(invMatrix[j], invMatrix[i], mulValue, wholeModCache, сacheIndexOffset); // <---            }        }        if(domainInvs[thisRowLast] !== 0)        {            mulRowCached(matrix[i],    invThisRowLast, domain, wholeModCache, сacheIndexOffset); // <---            mulRowCached(invMatrix[i], invThisRowLast, domain, wholeModCache, сacheIndexOffset); // <---        }        if(matrix[i].every(val => val === 0))        {            matrixRank -= 1;        }    }    return {inverse: invMatrix, rank: matrixRank};}

Замерим производительность. На той же матрице 500x500 по модулю 29 получаем время выполнения в ~5.4с.

Простите, что?

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

Да, использование JavaScript создаёт определённый оверхед. Но JIT его нивелирует. Видимо, либо он нивелирует его недостаточно, либо не всё, чему нас учат про cache-friendly код правда.

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

В реальном проекте, где был применён этот метод, матрицы не рандомные и прирост ещё заметнее.

Заключение

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

Полный код я выложил на Pastebin.

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

Первые шаги

Использовать WhatsApp в Novakid начали в середине 2018 года, примерно через полгода после запуска стартапа. Количество учеников на платформе выросло с 0 до 1000 и появилась необходимость оперативной связи с клиентами. Практика показала, что это наиболее удобный и оперативный инструмент коммуникации. С помощью приложения сотрудники онлайн-школы не только напоминают о занятиях, но собирают обратную связь и комментарии о работе платформы.

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

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

Цена общения

Череда ошибок на этапе запуска WhatsApp API для работы с клиентами привела нас к необходимости выбрать из списка официальных провайдеров бизнес-платформы мессенджера. После сравнения и анализа мы выбрали Gupshup.

Главными критериями выбора для нас были доступность API документации, наличие песочницы (тестового сервера) и стоимость. Если по первым двум пунктам предложения были плюс/минус похожи, то цены были очень разные

Расходы на официальное использование WhatsApp API для бизнеса складываются из нескольких элементов:

• Комиссия по умолчанию, составляющая $0.048 за сообщения рассылки;

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

Мы провели анализ и поняли, что для нашей модели бизнеса выгоднее платить по факту и без всяких абонентских плат. Плата за каждое сообщение составляет около $0.049 и по $0.001 за сообщения в сессии.

Плюсы WhatsApp

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

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

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

И минусы

При работе с платформой провайдера WhatsApp есть свои недостатки, которые не могут быть видны клиентам. Так, например, не указывается причина отклонения заявок.

Однажды нам отклонили все шаблоны сообщений рассылки на турецком языке. Но, как стало известно, позднее, это формат работы WhatsApp INC., и провайдеры никак не могут на это повлиять, рассказывает сотрудница службы поддержки Novakid.

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

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

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

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

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

Что можно с помощью неё делать?
Лично я автоматизировал работу с 1С, SAP, сайтами, тем же Excel, публикации в социальных сетях. Так же можно запрограммировать действия в играх, реакцию на происходящее на экране, набор текста, буквально что угодно.

познакомимся с интерфейсом программы:

Он минималистичен и тем хорош. Создадим свой первый скрипт и попробуем написать какой-нибудь простой скрипт, своего рода Hello world от мира автокликинга.

Нажимаем на кнопку создания скрипта (1) и кнопку редактора (3).

Интерфейс редактора

Нажимаем на сохранить как (4) выбираем место, где он будет храниться (желательно оставить его в папке с программой) и имя сценария.

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

https://cs14.pikabu.ru/video/2021/04/11/1618089701287548721_1920x1080.webm

Мы используем несколько команд:

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

LCLICK- Кликает левой кнопкой мыши по указанным в скобках координатам, необходимости прописывать их в ручную нет, просто наводите мышь туда, куда хотите кликнуть и нажимаете комбинациюALT + Q. Команда с координатами вставляется в скрипт автоматически. Либо если хотите вручную их поправить, опять же наводим мышь на желаемое расположение и смотрим сюда:

RCLICK- Соответственно всё тоже самое, только правой кнопкой мыши, вызывается тем же набором клавиш, просто нужно заменить в скрипте L на R.

Шаблоныкопирования и вставки (CTRL + C, CTRL +V) они уже есть в разделе шаблоны, нет необходимости их прописывать самому, просто выбираем подходящий.

KEYPRESS- В том случае, если нам нужно нажать какую либо кнопку, выбираем эту команду, кстати чтобы не прописывать в ручную, эту команду тоже можно выбрать из списка команд:

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

Введение

На сегодняшний день Python является одним из самых популярных языков программирования, но даже это не помогает ему покрыть все потребности программистов. Самый очевидный минус чистого CPython - это его скорость, поэтому некоторые программисты выбирают для своих задач другие языки программирования, а кто-то просто реализует узкие места на C/C++ и подключает их к Python.

Однако бывают случаи, когда есть некая база кода, написанного на C#, а возможности быстро переписать всё на Python/C/C++ нет. Тогда встает вопрос как подключить C# к Python?. Для этого была разработана библиотека pythonnet. В этой статье разберем: как запустить C# код из Python и что из этого может получиться.

Реализация

Для сравнения скорости выполнения C# и Python я буду ссылаться на одну из прошлых статей.

Библиотека pythonnet работает с .dll файлами, поэтому весь код необходимо будет преобразовывать в динамически подключаемые библиотеки. Чтобы создать .dll файл из C# необходимо установить visual studio и при создании проекта указать, что проект будет создан для библиотеки классов (я дал название проекту: MyTestCS, в будущем dll файл будет носить такое же название как и проект):

В качестве примера будем использовать магазин из прошлой статьи, который оптимизировали силами самого питона и других языков. Создадим структуру для одного товара на C#:

public struct DataGoods    {        public string name;        public int price;        public string unit;        public DataGoods(string name, int price, string unit)        {            this.name = name;            this.price = price;            this.unit = unit;        }    }

Теперь реализуем класс самого магазина. В нем создадим метод для заполнения магазина товарами:

public class ShopClass    {        public string name;        public List<DataGoods> listGoods;        public ShopClass(string name)        {            this.name = name;this.listGoods = new List<DataGoods>();        }        /// <summary>        /// Метод для создания товаров в магазине        /// </summary>        /// <param name="numberGoods"> Количество объектов в магазине </param>        public void createShopClass(int numberGoods) {            List<DataGoods> lGoods = new List<DataGoods>();            for (int i = 0; i < numberGoods; i++) {                lGoods.Add(new DataGoods("телефон", 20000, "RUB"));                lGoods.Add(new DataGoods("телевизор", 45000, "RUB"));                lGoods.Add(new DataGoods("тостер", 2000, "RUB"));            }            this.listGoods = lGoods;        }   }

После того, как класс был создан, приступим к подключению C# кода к Python проекту. Сначала создадим .dll файл из C# проекта (достаточно нажать команду ctrl+shift+B). В папке bin->debug->netstandart2.0 проекта (путь зависит от того, какие конфигурации среды стоят у вас) появится файл с названием проекта и расширением .dll (именно этот файл будет подключаться к программе на Python).

Далее разберемся с проектом на Python. Необходимо установить библиотеку pythonnet, выполнив команду:

pip install pythonnet

В проекте создадим файл main.py, а также поместим библиотеку MyTestCS.dll в папку с проектом:

Теперь можно подключать библиотеку в main.py, для этого сначала импортируем clr (clr позволяет рассматривать пространства имен CLR как пакеты Python):

import clr

Укажем путь до нашего .dll файла:

pathDLL = os.getcwd() + "\\MyTestCS.dll"

Чтобы подгрузить нужную нам библиотеку необходимо прописать следующий код:

clr.AddReference(pathDLL)

После чего можно импортировать модуль и всё, что в нем содержится. Если напрямую сделать импорт MyTestCS:

import MyTestCSprint(MyTestCS)>>> <module 'MyTestCS'>

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

Создадим экземпляр класса ShopClass и DataGoods через Python и обратимся к полям этих классов.

from MyTestCS import ShopClass, DataGoodsshop = ShopClass("Тест магазин")shop.createShopClass(1)goods = DataGoods("чехол для телефона", 500, "RUB")print(shop.name)>>> Тест магазинprint(shop.listGoods)>>> [<MyTestCS.DataGoods object at 0x000001D04C3FE3C8>, <MyTestCS.DataGoods object at 0x000001D04C3FE438>, <MyTestCS.DataGoods object at 0x000001D04C3FE400>]print(shop.listGoods[1].name, shop.listGoods[1].price, shop.listGoods[1].unit)>>> телевизор 45000 RUBprint(goods.name, goods.price, goods.unit)>>> чехол для телефона 500 RUB

Как итог, получилось вызвать код C# из Python и поработать с классами. Теперь протестируем производительность создания 200*100000 товаров через метод createShopClass:

shop = ShopClass("Тест магазин")s = time.time()shop.createShopClass(200 * 100000)print("СОЗДАНИЕ ТОВАРОВ НА C#:", time.time() - s)>>> СОЗДАНИЕ ТОВАРОВ НА C#: 2.9043374061584473

В прошлой статье время создания такого количества товаров заняло примерно 44 секунды. Использование C# вместо Python позволило ускорить этот процесс примерно в 15 раз, что является очень хорошим результатом.

Проблемы

Однако не может же быть всё настолько хорошо, чтобы броситься переписывать куски кода Python на C#. И это так. Попробуем из Python вручную дополнить товарами магазин:

shop = ShopClass("Тест магазин 1")s = time.time()shop.createShopClass(500000)print("СОЗДАЛИ ТОВАР ЧЕРЕЗ C#:", time.time()-s)>>> СОЗДАЛИ ТОВАР ЧЕРЕЗ C#: 0.07325911521911621shop = ShopClass("Тест магазин 2")s = time.time()for _ in range(500000):        goods1 = DataGoods("телефон", 20000, "RUB")        goods2 = DataGoods("телевизор", 45000, "RUB")        goods3 = DataGoods("тостер", 2000, "RUB")        shop.listGoods.extend([goods1, goods2, goods3])print("СОЗДАЛИ ТОВАР ЧЕРЕЗ PYTHON:", time.time()-s)>>> СОЗДАЛИ ТОВАР ЧЕРЕЗ PYTHON: 5.2899720668792725

И проверим аналогичный код, написанный на Python:

istGoods = []class DataGoods2:        def __init__(self, name, price, unit):            self.name = name            self.price = price            self.unit = units = time.time()for _ in range(500000):        goods1 = DataGoods2("телефон", 20000, "RUB")        goods2 = DataGoods2("телевизор", 45000, "RUB")        goods3 = DataGoods2("тостер", 2000, "RUB")        listGoods.extend([goods1, goods2, goods3])print("СОЗДАЛИ PYTHON ОБЪЕКТ:", time.time()-s)>>> СОЗДАЛИ PYTHON ОБЪЕКТ: 1.2972710132598877

Код чистого питона работает быстрее, чем дополнение объекта, созданного из модуля C#. Это связано с тем, что доступ к объектам, написанным на C#, занимает довольно много времени. Чтобы избежать таких проблем, необходимо писать всю логику работы с классом внутри C# кода, и не выносить эту логику в Python. Изменение скорости выполнения кода будет заметно при подсчете суммы всех товаров. Реализуем функцию подсчета суммы товаров на C# (внутри класса ShopClass):

public long getSumGoods() {    long sumGoods = 0;    foreach (DataGoods goods in this.listGoods) {      sumGoods += goods.price;    }    return sumGoods;}

А также на Python:

shop = ShopClass("Магазин 3")shop.createShopClass(1000000)s = time.time()shop.getSumGoods()print("ВРЕМЯ НА СУММУ ТОВАРОВ C#:", time.time()-s)>>> ВРЕМЯ НА СУММУ ТОВАРОВ C#: 0.0419771671295166sumGoods = 0for goods in shop.listGoods:     sumGoods += goods.priceprint("ВРЕМЯ НА СУММУ ТОВАРОВ PYTHON:", time.time()-s)>>> ВРЕМЯ НА СУММУ ТОВАРОВ PYTHON: 6.205681085586548

Python код выполняется гораздо медленнее, чем внутренние методы C#.

Многопоточность

Так как в C# отсутствует GIL, то мне стало интересно протестировать работу многопоточности в C# и попробовать запустить потоки в C# через Python. Для начала протестируем протестируем создание 3х классов ShopClass последовательно и заполним их 3.000.000 товаров:

public class testShop    {        public void testSpeedNoThread(int count)        {            testShopClass(count);            testShopClass(count);            testShopClass(count);        }        public static void testShopClass(int count)        {            ShopClass shop = new ShopClass("Магазин");            shop.createShopClass(count);        }}

Python код для запуска:

tshop = testShop()s = time.time()tshop.testSpeedNoThread(3000000)print("СОЗДАЕМ ПОСЛЕДОВАТЕЛЬНО 3 МАГАЗИНА:", time.time()-s)>>> СОЗДАЕМ ПОСЛЕДОВАТЕЛЬНО 3 МАГАЗИНА: 2.1849117279052734

Дополним класс testShop для работы с потоками новым методом:

public static void testThread(){    ExThread obj = new ExThread();    Thread thr = new Thread(new ThreadStart(obj.mythread1));    Thread thr2 = new Thread(new ThreadStart(obj.mythread1));    Thread thr3 = new Thread(new ThreadStart(obj.mythread1));    thr.Start();    thr2.Start();    thr3.Start();    thr.Join();    thr2.Join();    thr3.Join();}

И создадим новый вспомогательный класс:

public class ExThread{   public void mythread1()     {         ShopClass shop = new ShopClass("Магазин");         shop.createShopClass(3000000);     }}

Запустим Python код для проверки работы потоков:

s = time.time()tshopThread = testShop()tshopThread.testThread()print("СОЗДАЕМ 3 ПОТОКА C# ДЛЯ 3х МАГАЗИНОВ:", time.time()-s)>>> СОЗДАЕМ 3 ПОТОКА C# ДЛЯ 3х МАГАЗИНОВ: 0.6765928268432617

Вывод

Использование частей кода, написанных на C# в Python возможно, но при таком подходе есть и свои минусы, например, скорость доступа к объектам. Использование pythonnet целесообразно, если имеются какие-то части кода, которые нет возможности переписать на Python, но они требуют подключения к основному проекту на Python.

P.S. есть и другие способы ускорить python, например, написать библиотеку на C/C++ или переписать часть кода на Cython с меньшими проблемами. В данной статье лишь представлена возможность использования C# и Python вместе. Также существует реализация Python для платформы Microsoft.NET под названием IronPython.

Это пилотная статья. Будем благодарны за обратную связь. Если тема вызовет интерес, мы возможно примем решение выложить на GitHub наши исходники (python) и входные data-setы.

В марте 2021 г. случилось мне поучаствовать в хакатоне с задачей на комбинаторику и оптимизацию. Команду решил собрать свежую, из одиночек, дрейфующих в пуле самого хака. Довольно быстро нашлись front и back, и втроем мы принялись старательно думать, как потратим деньги, когда выиграемJ Так как сам кейс показался нам по началу не сложным. Надо сказать, что в хаках я не так давно, но уже успел поучаствовать и в ЛЦТ(Лидеры Цифровой Трансформации), и в Цифровом Прорыве. В последнем даже удалось занять бронзу в финале. Роль всегда у меня была project+product+ppt (хотя опыт в программировании у меня также имеется). Не редко в хакатонских кейсах проблемы немного надуманы, решения этих проблем немного фееричны и не несут практического смысла, а побеждает профессиональная преза и поставленный питч. Так вот этот мартовский хакатон меня заинтересовал живостью и насущностью бизнес проблем, которые там решались. Опытные хакатонщики, читающие эти строки, поймут. Но полно про хакатоны и про то, какие они бывают, а то собьемся с курса.

В этам хаке преза и даже front мало интересовали кейсодержателей. Это был натуральный бизнес хакатон с абсолютно живыми дата сетами и с натуральной бизнес болью. Кстати на хакатоне ни одна из команд не предоставила решение. Вроде одни ребята "нарисовали" в своей презе оптимизацию в минус 1 агент, но демонстрацию на защите они не представили. Наша команда не стала исключением и заняла скромное третье место (всего до защиты дошло 5 команд). Теперь наконец к условию:

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

Также предоставлена матрица 204х204 с расстояниями между точками (см. Табл.1 ниже ). Матрица не симметричная, т.к. при составлении учитывались знаки ПДД (одностороннее движение и пр.). Видимо она была получена через API Яндекс.Карт по адресам ТТ. Требовалось найти оптимальное расписание для торговых агентов (мерчендайзеров), улучшив показатели текущего AS IS (оно тоже предоставлено). Важные ограничения: каждая ТТ должна быть закреплена за определенным мерчендайзером (торговым агентом). Другими словами, если торговый агент (далее агент) посещает Магнит на улице Ленина в понедельник, то этот же Магнит в другие дни недели должен посещать именно он. Время работы каждого агента не должно превышать 9,5 часов в день с учетом работы в ТТ и перемещению между ними.

Таблица 1. Матрица расстояний между точками

Предоставленное расписании AS IS распределено на 14 агентов. И как вы уже догадались, решение должно было предложить альтернативное расписание, сократив по возможности количество агентов и их время в пути.

Спустя какое-то время после хакатона наш back(python) призвал на помощь коллегу с курсов по deep learning. Парни погуглили, поискали готовый алгоритм, почитали про метод отжига, муравьев, генетику и пришли еще раз к выводу, что подходящего метода и примеров кода именно для этой задачи, куда можно было бы взять и вставить матрицу расстояний, как входной параметр на просторах интернета - нет. Если кто знает где есть поделитесь, будем благодарны.

Позднее, и даже в параллель я сам начал изучать тему Задачи коммивояжера и эвристические методы, зарекомендовавшие себя для ее решения. Но ни хабр, ни youtube, ни Википедия не давали готового ответа именно для этого частного случая. Останавливаться все равно не хотелось. Наоборот, по мере продвижения вперед интерес подогревался. Мотивации добавило то, что классическая задача коммивояжера относится к NP полным задачам. Если решать задачу полным перебором (brutal force), то уже при 66 торговых точках нужно несколько миллиардов лет и компьютер размером с Землю. Согласитесь, мощь трансвычислительных задач завораживает! И действительно, для решения классической задачи TSP (Travelling salesman problem ) существуют различные эвристические методы, такие как Метод Имитации Отжига, Муравьиный алгоритм, Генетический метод и др. Оставалось решить один вопрос: как применить что-то из этой эвристики к сквозному недельному расписанию нескольких торговых агентов с ограничением по времени. Возможно толковый математик, который кожей чувствует физический смысл дифференцирования, логарифмов, пределов, силу числа e и т.д., справился бы с этой задачей. Но я не такой математик. Формулы счастья по-прежнему в интернете не находилось. Я даже изучил основы нейросетей, но когда я начинал проектировать свою нейросеть для решения - вырастала непреодолимая стена.

И все-таки решение родилось! Ну во-первых я обратился за помощью к своему коллеге, Черкасову Евгению @eny01. Он как раз недавно прошел курсы по data science и python, и рвался в бой, чтобы применить все приобретённые навыки. К слову сказать, бОльшую часть алгоритма именно он и разработал. Себе я взял часть, отвечающую за рекурсивный метод ветвей и границ. Но об этом позже. Вдвоем мы разработали следующий план.

1. Мы декомпозировали задачу до каждого агента. Набираем ТТ сначала для одного агента до предела по очереди для всех дней недели, затем для второго и т.д.;

2. Процесс набора ТТ происходит с помощью жадного алгоритма (метод ближайшего соседа);

3. В случае, когда набор подходит к пределу (9,5 часов) - применяем оптимизацию и считаем, что для данного агента в этот день недели оптимальное расписание составлено. Переходим к следующему дню;

Алгоритм набора расписания для каждого агента более подробно можно увидеть на блок-схеме ниже:

Теперь чуть подробнее про основные моменты:

1. Ближайшие сосед:

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

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

Когда в одном из дней достигается предел рабочего времени (>=9,5 ч.), система сбрасывает точку приведшую к переполнению и пробует добрать следующую ближайшую. Кстати, мы пробовали вставлять сюда вместо оптимизации "первой точки" и ближайшего соседа полный перебор с ветвями и границами. И результат, !внимание!, получался в итоге тот же. Но времени на перебор с ветвями и границами потребовалось гораздо больше. Около 3,5 часов против 5 минут для всех 204 точек. Таким образом полный перебор был абсолютно избыточен и неэффективен при частом применении. Вследствие чего в этом месте было решено от перебора с ветвями и границами отказаться, но добавить его в финальную оптимизацию составленного расписания.

2. Метод ветвей и границ:

Ну тут все относительно просто. Утвержденное недельное расписание мы прогоняем через полный перебор, используя метод ветвей и границ. Реализация этой функции потребовала применения рекурсии. Причем если сравнивать работу полного перебора через библиотеку itertools (python), то время на перебор 8 точек составило 21 сек, в то время как наша рекурсия с ветвями и границами отрабатывала за 0.4 с. Что не может не радовать! Цель применения ветвей и границ - оптимизация уже готовых расписаний. Привязка ТТ и агентов уже не меняется, но оптимизируется время в пути (решаем классическую задачу коммивояжера).

Результаты:

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

Время работы алгоритма для всех агентов на всех днях недели составило 8 минут на домашнем ПК.

И в качестве финального аккорда мы позволили себе выкрутить лимит с 9 часов 30 минут до 9 часов 38 минут. И получили сокращение до 12 агентов с небольшой погрешностью. Из 60 дневных расписаний 14 уходят в переработки от 1 до 8 минут (51 минута в сумме).

Ждем ваших комментариев, замечаний и предложений! Ответим на все вопросы. Пишите, как бы вы решали эту задачу. Особенно ценны для нас будут мнения практиков. Как математиков, так и data science'ов. Возможно кто-то предложит существующие библиотеки python для решения задачи. Мы, как я уже сказал, подходящих библиотек не нашли. Всем спасибо, что дочитали до конца!

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

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

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

СОДЕРЖАНИЕ

Введение

Правительство Её Величества и его Web

Состав

Сайты

Структура и дизайн

Полный Flat

Код, софт, Performance

Палитра

Содержание по-прежнему Queen

Семантика

Atomic дизайн

Информационное сопровождение

Выводы

ПРЕДУПРЕЖДЕНИЕ: немного лонгрид, вынужден сразу предупредить. Но материал задуман и предназначен для других целей, так что короче никак. Поэтому, кому не интересно, не тратьте время, а кому интересно, наберитесь чуточку терпения.

Введение

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

Говоря о хроническом недоюзе социальных сетей российскими органами власти и его последствиях для нас, я вскользь, но намеренно упомянул стандарты доступности сайтов с твердым намерением вернуться к этой темe. ( II )

По большому счету, с учетом 30-летней истории развития Всемирной паутины и всего, что с ней связано, наблюдаемые в России в отношении социальных сетей недоверие, высокомерие, неумение пользоваться, непонимание назначения это лишь малая часть куда более существенной и системной проблемы, а именно все еще первобытного состояния Рувеба и его хронического отставания от наилучших практик и общепринятых стандартов. ( III )

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

Однако, после некоторого размышления разговоры о доступности и, о как более общем подходе, об ориентированности дизайна веб-сайтов и приложений на пользователя (user-centred design) ( IV ) я решил предварить разговором о дизайне в целом; прежде всего, в ключе его UX/UI составляющей. В конце концов, не будь пользователь изначально поставлен в центр этой инженерной задачи, предваряющей любую разработку, все разговоры о доступности отпадут сами собой.

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

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

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

Правительство и Web Её величества Today

Состав

Согласно сайту gov.uk на начало апреля 2021 года правительство Соединенного Королевства и имеющие к нему отношение организации, это:

• офис премьер-министра;

• 23 министерства;

• 20 департаментов, не являющихся министерствами;

• 411 агентств и прочих госструктур;

• 105 значимые профильные организации;

• 13 госкорпораций;

• и 3 автономные администрации.

Итого: 576 ед.

Сайты

Сайты далеко не всех перечисленных на этой странице 576 entities заведены под зонтик gov.uk, многие организации имеют сайты в собственных доменах. Однако, забегая вперед, скажем, что это не освобождает их владельцев от необходимости соблюдения общих требований. Требований же таких немало, и прописаны они на удивление детально и, что тем более немаловажно, исключительно доступным языком. ( V )

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

Все вместе правительственные сайты в домене gov.uk это полмиллиона страниц, множество документов и услуг и в среднем примерно 5,1 млн посещений ежедневно, не считая тех, кто отказался от приема cookies. ( VI )

Хозяйство, как видите, вполне себе имперских масштабов, анархии и вольнодумства не терпящее.

Структура и дизайн

Полный Flat

Над вопросом с чего начинается Родина в случае с веб-империей правительства Её величества голову ломать совершенно не приходится. Набираете в адресной строке gov.uk, и вы дома.

Первое впечатление от посещения: лаконичность, строгость, функциональность. В реализованной концепции все уплощено до предела, ни тени в прямом и переносном смысле, ни на намека на реализм. Можно сказать, gov.uk это квинтэссенция плоского (Flat) дизайна.

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

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

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

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

Код, софт и Performance

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

Согласно Wappalyzer, правительственные сайты, находящиеся в кусте gov.uk, очень неприхотливы в используемых технологиях. За основу взят Ruby on Rails, веб-сервер и обратные прокси поставлены на Nginx, Varnish для кэширования, из JS-библиотек jQuery (1.12.4) и три собственных UI-фреймворка GOV.UK Toolkit, GOV.UK Template и GOV.UK Front-End, и, как говорят англичане, thats it.

Такой инструментальный минимализм освобождает веб-страницы от массы ненужного кода, а пользовательские браузеры и правительственные веб-серверы от массы ненужной работы. Всего пара скриптов перед закрывающим </body>-тегом вот и весь JavaScript.

Но все же за все приходится платить. Задействовав jOuery, сайты поплатились малость безопасностью (D в тесте на WebPageTest за безопасность прилетело именно из-за нее; см. рисунки ниже), что совсем не на руку обширному веб-хозяйству gov.uk, так как используемые технологии касаются всех сайтов в домене. Но если говорить о производительности, то тут нетребовательность англичан окупается сторицей. А пользователи, как мы знаем, больше любят сайты быстрые, чем безопасные. ( IX )

И на этом разговор о технических характеристиках gov.uk можно, пожалуй, закончить. Кто понимает, о чем идет речь, да поймет.

Цветовая палитра

В продолжение разговора о плоском дизайне Выбором инструментов разработки сайта дело не ограничивается. Общий аскетично-анемичный крайне благоприятный для посетителей настрой сайта не был бы таковым вовсе, не найди он продолжение в выборе цветовой гаммы.

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

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

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

Традиционно голубой цвет считается одним из наиболее любимых у детей. И хотя дети не являются ключевой аудиторией правительственных сайтов, возможно, он также благотворно действует на людей с теми или иными формами аутизма, который, как известно, сопровождает людей на протяжении всей жизни. Как бы там ни было, думаю, большинство согласится, что встань, скажем так, неуравновешенный человек перед выбором (на основе внешнего вида веб-сайта), с кем ему идти в разведку с правительством Великобритании или с ЦРУ (см. новый дизайн сайта ЦРУ), он бы выбрал первое.

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

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

Содержание все еще Queen

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

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

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

Содержание (информация, за которой приходят на сайты люди) по-прежнему король (применительно ко времени и месту все же королева, пожалуй), и, как заверяет нас Forbes, останется таковым навсегда. Поэтому пора посмотреть, из чего же, из чего же сделаны эти страницы на gov.uk?

Первым делом, первым делом человек!

Хедер

В самом верху в левой части белым по черному размещен логотип стилизованная корона и надпись GOV.UK. Под логотипом также на черном фоне через голубую полосу размещены две ссылки на темы коронавирус и Brexit, с которыми, судя по акценту, да простится мне ирония, по мнению правительства каждый британец должен отходить ко сну и начинать свой день . (На двух изображениях ниже рамки желтым даны в иллюстративных целях, в оригинале они отсутствуют.)

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

И это все. Никаких изображений индивидуальных оптических приборов, разновеликих букв, которые людям с плохим зрением ни большие, ни маленькие все равно не видны; никаких перетычек на другой язык (в самом деле, зачем вам другой, кроме английского, если вы хотите иметь дело с правительством Соединенного королевства?!); ( X ) наконец никаких привычных глазу в каком бы то ни было виде меню и прочих элементов, коими у нас, да и не только принято обильно забивать шапку сайта, словно это, выражаясь словами одного ну о-очень известного англичанина пустой чердак, куда можно набить все, что угодно.

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

Тело

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

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

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

(Тем более, в самом деле, трафик госсайтам не нужен; кто пришел за услугой и информацией, без нее не уйдет, так не лучше ли сделать так, чтобы на входе скапливалось как можно меньше народа? сделать наоборот, примерно то же самое, как перед входом на эскалаторы метро в Рождество устраивать распродажи).

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

Следом идет блок ссылок (и все это еще до сгиба!), детализирующий задачи и функции, осуществляемые правительством. Они сгруппированы в 16 разделов, в частности: занятость, гражданство и проживание в UK, преступность и правосудие, деньги и налоги, образование, визы и иммиграция и т.д.

Таким образом, если посетителя интересует получение водительских прав, ему не приходится гадать, к ведению какого ведомства отнесена данная услуга. Логика предоставления информации исходит из принципа не важно, кто (окажет услугу), важно, что (в чем заключается потребность конкретного человека) и как.

Следующий раздел всего пять ссылок в трех абзацах по две строчки каждый представляет посетителю несколько другой информационный ракурс. Здесь он может узнать, что собой представляет правительство, сколько в нем каких подразделений, как они называются, как попасть на их сайты (см. Рисунок 1). Что примечательно, никаких промежуточных визитных карточек не предусмотрено; нажав на ссылку, вы сразу переходите на интересующий вас сайт.

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

Несколько метрик используется для оценки эффективности предоставления госуслуг, в частности: стоимость трансакции, процент людей, успешно воспользовавшихся той или иной услугой, уровень удовлетворенности пользователей (по оценке самих же пользователей, методом опроса) и доля пользователей, воспользовавшихся цифровой услугой в сравнении с другими доступными вариантами ее предоставления. Там же ссылки на подробные методики составления и использования этих метрик и на сервисные панели (всего 777 ( XI ) + еще 15).

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

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

Футер

Футер последний элемент на который непременно следует обратить внимание. Условно футер правительственных сайтов состоит из двух версий минимальной и полной.

Полная в своей верхней части практически полностью повторяет информационный блок с главной страницы, который идет сразу после хедера и приветствия с поисковой строкой. К нему лишь добавлены третьей колонкой еще ряд важных по мнению архитекторов портала ссылок. Это очень удачный ход: оставить посетителю напоминание о главной странице и не заставлять его при необходимости каждый раз бегать туда-сюда-обратно. А так, где бы он ни был, главная страница всегда с ним. С другой стороны, на сайте какого бы ведомства пользователь ни был, если он нажмет на логотип в самом верху хедера, он попадет именно на главную страницу портала gov.uk.

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

Полная версия используется на всех официальных правительственных сайтах в домене gov.uk; минимальную можно встретить на прочих сайтах, относящихся к правительству, но не являющихся сайтами правительственных структур. В частности, это блоги, которые размещены в домене третьего уровня blog.gov.uk в виде отдельных сайтов четвертого уровня (например, accessibility.blog.gov.uk); сервисная информация, предоставляемая на сайте третьего уровня data.gov.uk и т.п.

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

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

Это тем более имеет смысл, так как раздел контактов у многих правительственных организаций может оказаться очень обширным. Британские ведомства, в отличие от многих наших, не стесняются предоставлять своим посетителям как можно больше вариантов и возможностей для связи с ними. За примером сходите на сайт Форин Офис (FCDO) видели?.. сами можете себе представить, каким должен быть футер, чтобы вместить в себя всю эту информацию.

Что еще столь привычное глазу серфера российских сайтов отсутствует в британском футере, не догадываетесь? Ну, конечно же! Баннеры бесчисленных датчиков, счетчиков, виджетов и прочей дребедени, столь любимой российскими разработчиками. Представляете, от скольких тысяч тонн словесной кодовой руды (простите, Владимир Владимирович!) разом удалось избавиться британцам, выметя весь этот <script>-сор из избы? Представляете ту одышку, которая неизбежно ждала их сайты, дай они им обрасти всем этим паразитным балластом?

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

Структура отдельных сайтов

Этот раздел не займет много места. По большому счету, мы уже все обсудили. Но взглянуть на устройство индивидуальных сайтов все же стоит.

В качестве примера можно взять любой. Например, сайт GDS (Government Digital Service), организации, ответственной за все это веб-хозяйство (ссылка на ее сайт в футере). Выбор абсолютно не принципиален, поскольку, какой бы сайт вы из этого массива ни вытащили, все они будут иметь одну и ту же структуру (см. рисунок 13).

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

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

Еще один момент, на который непременно стоит обратить внимание. Это элемент, предваряющий футер.

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

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

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

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

Atomic дизайн

Туго пришлось бы британским госдизайнером, скорее всего не случилось бы им создать свое веб-чудо, не будь они знакомы с концепцией atomic ( XII ) дизайна от Брэда Фроста. ( XIII ) Она позволила добиться той лаконичности и содержательности одновременно, которые иным UX/UI дизайнерам не снятся даже в самых смелых фантазиях. Пойди они проторенной дорожкой, и обрекли бы себя на поистине сизифов труд. Не помогли бы ни минимализм, ни собственные фреймворки.

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

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

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

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

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

We Want Information, Information, Information

Блоги

We Want Information, Information, Information, такими словами начинается композиция The Prisoner из альбома The Number of the Beast группы Iron Maiden (британской, конечно же!). И, знаете, власти совсем не против: Хотите информацию? Пожалуйста!

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

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

Их ведут университеты и их подразделения, исследовательские организации, библиотеки и think tanks, международные организации (World Bank, IMF) и ТНК (CISCO, Microsoft).

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

Всего их у него на сегодняшний день не удивляйтесь, в хорошем хозяйстве все посчитано 137. Собраны все блоги под своим, так скажем, подзонтиком в домене https://www.blog.gov.uk/. Не все из них активны, некоторые переведены в архив, но доступ к ним при этом сохраняется в полном объеме.

Исходя из их количества, можно догадаться, что не все ведомства и службы имеют собственные блоги, зато у некоторых их даже не по одному. Так, у офиса премьер-министра три, у министерства юстиции два, ( XIV ) а у GDS (Government Digital Service), в ведении которой и находятся все правительственные сайты, блогов аж девять.

Но блогами этой службы темы функциональности интересующих нас сайтов и их доступности отнюдь не исчерпываются. Например, Civil Service ведет блог Accessibility in government, а Home Office Home Office Digital, Data and Technology. Следует признать, цифровая тема очень плотно пронизывает неформальную информационную повестку британских государственных служащих. 25 блогов из 137 так или иначе связаны с темой цифровизации. Наберите на главной странице блогов в левой части в раскрывающемся списке ключевое слово digital, и вы сами все увидите.

Руководства и нормативно-правовая база

Для доведения своей официальной позиции по тому или иному вопросу у правительства Великобритании предусмотрены другие каналы. Законодательство собрано на сайте https://www.legislation.gov.uk/, а для различных руководств и разного рода наставлений есть раздел Guidance and regulation. Это на случай, если кто-то уже ухватился за мысль, что блоги это единственный способ общения правительства с гражданами и собственным персоналом.

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

Выводы

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

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

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

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

(I) Говорят, что это был Рене Декарт.

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

(III) Можно, конечно, продолжать их не замечать, но дальновидно ли это?

(IV) Приводится в английском варианте написания.

(V) Использование доступного среднестатистическому пользователю языка один из главных принципов UCD (user-centered design). И не только в продукте, если он подразумевает его [языка] использование, но и в сопроводительной документации к нему. GDPR, например, требует соблюдения этого принципа и в части правовой информации, размещаемой на сайтах и предназначенной для конечных пользователей. Поэтому, когда наталкиваешься на подобные документы российских ведомств (https://digital.gov.ru/ru/documents/4820/), начинаешь понимать актуальность таких требований, и что возникают они не на пустом месте.

(VI) Теперь в цивилизованных странах с этим строго: не хочешь cookies, не ешь.

(VII) Зайдите на сайт Рослесхоза, и вы увидите, до какого абсурда можно довести идею с hero-изображениями и каруселями. Представьте, вам каждое утро приносят газету, у которой первая страница до сгиба пустая? Сайт Рослесхоза именно такая газета.

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

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

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

(XI) 777, Карл! Ты не поверишь!

(XII) Сказать атомарный, как подается в переводах, просто язык не поворачивается. Это из той же области, что и аккаунт, кешбэк или транзакция.

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

(XIV) Это очень демократично и прогрессивно по сравнению с российским минюстом, который даже соцсетями пользоваться не удосуживается, https://github.com/shydata/govnets/blob/main/govnetsreport-2020-alexshy-FULLREPORT.pdf.

Robotic Process Automation, или сокращенно RPA, набирает все больше оборотов на рынке СНГ и Казахстана, в частности. Участники рынка обеспокоились непрерывностью своей деятельности, эффективностью и, конечно, экономией. Пандемия указала нам на дыры, которые имеются в процессах, на то, как это опасно подвязывать процессы на людях и что полная диджитализация это не будущее, это сейчас.

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

Почему я могу об этом вещать? И кем выступает моя компания?

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

Для начала давайте поймем, что такое бизнес-процесс

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

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

Видимость начала и конца процесса должно быть в рамках 1 дня, даже 1 часа.

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

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

Итого, процесс должен быть цифровым, рутинным и повторяющимся.

Сколько мне нужно роботов?

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

Робот это, по сути, виртуальный сотрудник. У него в запасе 24 часа. Все что вы сможете уместить в 24 часа робот исполнит. Если процесс масштабный и в день вы совершаете таких операций 10 тысяч штук, где каждая операция занимает 1 минуту, то арифметика проста и ее поймет первоклассник. 10 тысяч штук делим на 1440 минут (столько минут в сутках) = 6.9.

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

И так по каждому процессу.

Количество операций по процессу как 10 тысяч штук в день, это конечно очень много. И на нашем рынке может встретиться разве что в Ритейле.

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

Сколько будет стоить проект?

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

Из опыта могу сказать, что основная статья расходов это конечно же сами роботы (более 75% чека).

Почему так дорого?

Многие клиенты почему-то ожидают что роботизация всего их отдела в 10 человек должна обойтись им примерно в 1000 баксов XD

Основные поставщики роботов приходят к нам из США. Где стоимость человекочасов достаточно высока. Один робот, который стоит примерно 8-10K USD, что ничтожно в сравнении с годовой заработной платой.

Конечно, для рынка, где средняя заработная плата 500 USD в месяц это может показаться крайне нерентабельно. Но, так ли это на самом деле? Стоит ли нам теперь отказывать себе в удовольствии на роботизацию? Нет. И вот почему.

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

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

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

Расчет эффективности не всегда имеет положительный знак для отдельно взятого процесса

Были и остаются кейсы, когда среди 10 процессов клиента, 1 или 2 могут показать отрицательный знак в расчете эффективности роботизации, но в общей совокупности всех процессов выходить в плюс. С чем это обычно связано? С тем, что происходит реинжиниринг процессов. Люди могут реально делать сверку документа быстрее чем человек если, к примеру нужно прочесть только 1 строку в документе. А для робота, ее еще нужно отсканировать и внести в папку чтобы он мог ее оттуда брать. Но, возвращаясь к пункту 4 вспомним, что количество таких быстрых операций человеком, это непременно ведет к ошибкам и процесс будет совершаться еще раз, а может не один. То есть, отрицателен он как правило при расчете с учетом только видимых расходов.

Ваш робот ломается, вы плохие ребята

Процесс работает в продуктовой среде, он уже приносит свои плоды, а владельцы бизнес-процессов могут пойти пить чай. Но не все так просто. В процессе роботизации есть несколько степов. Один из финальных степов это стабилизация. Это когда начинают всплывать исключения, которые не были учтены в начале роботизации данного процесса. Вы забыли, что из 1000 файлов в формате docx, у вас все-таки бывают иногда и GPEG-ы, но это о как редко. Все это требует проработки со стороны интегратора и относится к данной стадии нужно с пониманием. Это не робот сломался, это обязательная часть процесса роботизации бизнес-процессов.

Конфликт интересов и саботаж

В самом начале роботизации руководство должно понять: кто имеет в роботизации самый главный интерес, чего мы хотим достичь и как всех объединить. Также, нужно дать понять людям, что станет с ними после того, как часть их работы отдадут цифровому сотруднику. Уволят? Или перенаправят на другую позицию? Если диалог ранее не состоялся между сотрудниками, чья позиция уйдет под роботизацию, и теми, кто в ней заинтересован, то ждать саботажа не придется.

Саботаж может быть как на стороне роботизируемого отдела, так и на стороне IT. Имеет место быть синдром Not invented here, что означает избегание использования или покупки продуктов, исследований, стандартов или знаний из внешних источников, сильное предубеждение против идей извне.

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

Я не знаю с чего мне начать, как создать Roadmap?

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

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

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

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

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

Я найму свою команду, и мы будем делать сами

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

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

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

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

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