Зачем нужны чат-боты, или история о Битрикс24

Нас очень часто спрашивают, для чего можно использовать Microsoft Bot Framework, кроме как по фану создать ботов и поболтать с ними, и существуют ли в природе реальные кейсы применения чат-ботов в проектах. Так вот, существуют. Мы попросили одного из наших партнёров — «Битрикс24», поделиться своим опытом и техническими деталями интеграции ботов в проект. Передаю слово Сергею Покоеву, разработчику системы, который расскажет про её архитектуру и использование Bot Framework для подключения к Skype.


Предыстория

Общение компании с клиентами давно трансформировалось: на смену электронным письмам и звонкам по телефону, пришли сначала социальные сети, а потом и мессенджеры. Согласитесь, сейчас намного удобней, и, самое важное, быстрее задать вопрос в поддержку в Facebook, ВКонтакте, What’s App или Telegram.

Обилие каналов не только даёт широкие возможности, но и создает некоторые проблемы:

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

Поэтому многие компании задумываются об агрегации данных в одном месте, которое легко поддаётся контролю и управлению. Для них в сервисе «Битрикс24»* как раз и существует инструмент «Открытые линии», о котором мы поговорим ниже.

Кстати, сразу ответим на вопрос, который волнует многих: «Зачем нужны чат-боты?» В нашем случае их применение зависит от задач, которые нужно решить: начиная с простых — чат-боты, способные направить запрос в один из отделов компании, до сложных — позволяющие автоматизировать поддержку клиентов.

* Справка: Сервис «Битрикс24» — это набор интернет-инструментов для организации работы компании. В него входит управление задачами и проектами, омниканальная CRM, внутренний мессенджер компании, рабочая социальная сеть, управление рабочим временем, управление документами и другая функциональность.

Как это работает: взгляд пользователя

Клиент пишет в официальный аккаунт компании в социальных сетях или в мессенджерах. Это сообщение поступает в общую для всех каналов очередь на обработку. Из неё сообщения распределяются между сотрудниками, которые отвечают на них внутри мессенджера «Битрикс24». Как вы могли понять, это автоматизированный процесс и для отвечающего нет разницы, в какой из каналов написал клиент.

Как это работает: взгляд разработчика

Интеграция с Microsoft Bot Framework

Microsoft Bot Framework — это среда, позволяющая создать интеллектуального чат-бота в облаке, с которым затем можно будет общаться по различным каналам коммуникации: от Skype и Telegram до Slack и SMS. Также его можно использовать как прокси. Это удобно, так как не нужно реализовывать интеграцию отдельно для каждого из этих каналов.

Для интеграции с Microsoft Bot Framework была использована существующая схема работы «Открытых линий» с некоторыми доработками.

Мы создали специальный сервер коннекторов. Он является связующим звеном между внешними каналами коммуникаций — соцсети, мессенджеры, онлайн-чаты, формы на сайте и так далее — и клиентскими «Битрикс24». Основные преимущества сервера:

  • обеспечивает гарантированную доставку сообщений из соцсетей и мессенджеров в «Битрикс24»;
  • работает как с облачными «Битрикс24», так и с коробочными;
  • позволяет быстро подключить официальный аккаунт компании в соцсети или мессенджере к «Битрикс24».

Обмен данными между клиентским «Битрикс24» и сервером коннекторов выполняется посредством собственного протокола. При этом сервер выполняет роль маршрутизатора, с предварительной обработкой поступающих и исходящих данных.

У него несколько иные требования к серверному окружению, чем у «Битрикс24»: PHP начиная с 5.4, MySql 5.5.3, InnoDB.

Для минимизации накладных расходов при обмене данными между клиентскими «Битрикс24» и сервером коннекторов было решено:

  • не передавать прикреплённые к сообщениям файлы из внешних каналов и с сервера. Сервер пересылает в «Битрикс24» только ссылки на файлы из внешних источников. А «Битрикс24» клиента скачивает их самостоятельно;
  • при отправке файлов из «Битрикс24» передавать только ссылки на их скачивание. Сами файлы хранятся на «Битрикс24.Диск»;
  • для часто используемых действий (получение, отправка сообщения, передача статусов доставки, прочтения сообщения и тому подобного) после отправки сообщения не ожидать ответа и закрывать соединение.

Очередь сообщений сервера коннекторов

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

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

Если подтверждение доставки не приходит на сервер, то следующая отправка на данный портал в данную «Открытую линию» произойдёт только по завершении периода блокировки. После каждой попытки длительность блокировки увеличивается. Если и последняя попытка будет неудачной, то отправка сообщений будет заблокирована на 12 часов. В совокупности получается 24 часа с момента первой попытки отправки сообщений на портал. После последней попытки все сообщения для данного портала данной «Открытой линии» удаляются, а блокировка снимается.

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

Механизм работы сервера коннекторов

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

Для работы канала нужно выполнить на портале первоначальную настройку. Её делают пользователи, а портал управляет подключением с помощью специальных методов. Настройки разных типов коннекторов существенно различаются по наборам методов. Для Microsoft Bot Framework используется простой вариант настройки. С портала вызывается удалённый метод saveSettings, в котором передаются необходимые параметры. Они сохраняются в базу и используются в работе канала в дальнейшем.

Затем портал вызывает удалённый метод коннектора testConnect, который проверяет возможность соединения с указанными данными, а также проверяет доступность подключаемого портала.

Webhook указывается при создании бота на сайте Bot Framework. Необходимый адрес мы даём при настройке пользователем.

Интерфейс настройки на стороне портала выглядит так.

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

После успешного подключения мы получаем записи в трёх структурах данных.

Запись с информацией о сайте. Важным параметром является домен портала. Сервер будет обращаться к нему в тех или иных случаях.

Запись об открытой линии/коннекторе. Она однозначно определяет:

  • тип коннектора;
  • id открытой линии на клиенте;
  • связь с сайтом;
  • специальный хэш для определения, к какой «Открытой линии» относится запрос при обращении по WebHook;
  • информацию для очереди сообщений: номер попытки отправки сообщений клиенту и время блокировки отправки.

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

Работа на сервере непосредственно с Microsoft Bot Framework

Bot Framework содержит целый набор каналов. Поэтому мы ввели понятия «реального канала» и «виртуального канала». Botframework — реальный канал, так как здесь используется одна точка контакта. Botframework.skype — виртуальный канал, который реализует работу с ботом Skype через Microsoft Bot Framework.

Для работы коннектора нужно:
1. В настройках бота указать необходимый WebHook.
2. В настройках канала в «Битрикс24» указать верные:

  • bot handle;
  • ID приложения;
  • секрет приложения.

Благодаря WebHook сервер коннекторов определяет к какой «Открытой линии» привязан данный бот. Если привязку найти не удалось, то возвращается ошибка.

Если ошибки нет, то обрабатываем пришедшие данные:

  • формируем массив данных в формате обмена между клиентом и сервером;
  • парсим текст и преобразуем все сущности в понятный мессенджеру «Битрикс24» формат. Для разных каналов эти преобразования различны;
  • преобразуем все входящие смайлы в универсальный формат Emoji. Мы постарались охватить максимум смайлов, поддерживаемых всеми каналами.

После всех преобразований сообщение добавляется в очередь сообщений.

При отправке сообщений из «Битрикс24» во внешний мессенджер выполняется обратное преобразование из одного формата в другой. Сообщение отправляется с помощью POST-метода /v3/conversations/{conversationId}/activities. Все необходимые для отправки данные приходят вместе с сообщением.

При этом бинарные данные не передаются. Все прикреплённые файлы кладутся в «Битрикс24.Диск» и отправляются в виде ссылок. Это экономит объём трафика. А при необходимости можно в любой момент закрыть доступ к файлу.

Принцип работы «Открытых линий»

Чат начинается с сообщения от пользователя социальной сети или мессенджера. Используется единая точка входа. Это единый URL, отличающийся GET-параметром, в котором содержится хэш «Открытой линии». По хэшу система определяет, куда необходимо отправить входящее сообщение.

Единственность подключения

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

Попытки повторных подключений для разных каналов определяются по-разному. В Microsoft Bot Framework проверяется наличие в системе конкретного идентификатора бота. Если текущее подключение оказывается не единственным (повторным), то оно продолжает работать в штатном режиме, а данные предыдущего подключения полностью удаляются с сервера. При этом на портал отправляется запрос, помечающий этот коннектор «Открытой линии» как «аварийный», требующий внимания администратора.

Механизм работы клиентской части «Битрикс24»

Клиентский модуль коннекторов используется для:

  • настройки подключений каналов коммуникаций;
  • получения сообщений, обработки и преобразования в формат мессенджера «Битрикс24». С последующей генерации события;
  • обработки пользователей: регистрации или обновления данных пользователя «Битрикс24», который связан с внешним пользователем;
  • загрузки файлов, приходящих с сообщениями.

Модуль «Открытые Линии» отвечает за маршрутизацию сообщений, создание очереди сообщений, направление на операторов и прочие функции.

Реализация обмена данными на клиенте

В модуле «Открытые Линии» класс Output отвечает за отправку сообщений на сервер и дополнительную обработку. Метод query непосредственно формирует исходящие пакеты на удалённый сервер и подписывает сообщения.

В классе Output используются «магические» методы, позволяющие вызывать методы удалённого сервера, как если бы они были локальными. Это имеет преимущества и недостатки.

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

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

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

Все входящие запросы обрабатывает класс Input. Он разбирает входящий пакет, проверяет подпись (что запрос действительно пришёл от сервера) и перенаправляет данные в класс Router, который маршрутизирует входящие запросы.

Виды входящих запросов:
Тестирование соединения. Этот метод вызывается удалённым сервером, когда он проверяет доступность клиента.
Входящие сообщения (всех типов). Подробнее ниже.
Статус доставки. Вместе со статусом доставки приходит внешнее ID сообщения, которое позволяет затем управлять внешними данными. Например, мы не можем удалить сообщение на удалённом сервере, не зная его внешнего ID.
Статус прочтения.
Деактивация коннектора. Вызывается при подключении данного коннектора на другом портале или «Открытой линии».

Получение сообщений клиентом «Битрикс24»

Класс input принимает входящее сообщение (массив сообщений) с портала и начинает обработку. Серверу отправляется уведомление о доставке сообщений. Он удаляет их из очереди и снимает блокировку дальнейшей отправки сообщений.

Полученные сообщения дополнительно обрабатываются. Shortname Emoji преобразуются в специальный тег icon, поддерживаемый мессенджером «Битрикс24». Так осуществляется поддержка всех доступных Emoji.

Обрабатываются все прикреплённые файлы. Они загружаются и регистрируются во внутренней системе. А в описывающем файлы массиве ссылки на них заменяются на внутренние ID.

Проверяется наличие на портале внутреннего пользователя, созданного под внешнего пользователя соцсети или мессенджера. Если его нет, он создаётся. Если пользователь есть, то проверяется хэш md5 от данных пользователя. Он сравнивается с полученными данными, и если хэши различаются, то данные пользователя обновляются. Затем они заменяются во входящем массиве на ID пользователя внутри портала «Битрикс24».

Такой преобразованный массив данных помещается в генерируемое событие OnReceivedMessage. Его «ловит» модуль «Открытых линий».

Исходящие запросы «Битрикс24»

Исходящие запросы практически не обрабатываются. Они маршрутизируются на удалённый сервер коннекторов. Для Bot Framework на клиенте сделан дополнительный обработчик.

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

При входящих сообщениях для данного коннектора вызывается метод furtherMessageProcessing, выбирающий и сохраняющий необходимую информацию. А при отправке сообщения в канал Botframework метод sendMessageProcessing подмешивает нужные данные.

Вместо выводов

На текущий момент большинство пользователей «Битрикс24» подключают канал Bot Framework для работы со своей аудиторией через Skype. На момент публикации статьи количество подключенных ботов составляет 9 тысяч.
ссылка на оригинал статьи https://habrahabr.ru/post/327258/

Опубликовано руководство пользователя ЦРУ по удалённой прослушке телевизоров Samsung


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

Поклонники научно-фантастического сериала «Доктор Кто» прекрасно помнят инопланетную расу хищников Плачущие ангелы (Weeping Angels). Это персонажи эпизода «Не моргай» — десятого эпизода третьего сезона (2007) и одного из лучших эпизодов в истории «Доктора Кто».

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

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


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

Греческая мифология и современная научная фантастика удивительным образом сочетаются в недрах секретных лабораторий ЦРУ и MI5, где разрабатывается программное обеспечение для нужд внешней разведки. Обожающие современную поп-культуру программисты ЦРУ, конечно же, смотрели «Доктора Кто», и ту серию с Плачущими ангелами. Именно поэтому они дали такое назвали закладке для телевизоров Samsung. Телевизоров, которые следят за зрителями — это такие маленькие Weeping Angels, плачущие ангелы, попробуй только моргнуть.

7 марта 2017 года сайт Wikileaks начал публикацию коллекции Vault 7 секретных документов Центрального разведывательного управления США. Первая часть коллекции Year Zero содержит 8761 файл, в том числе список разнообразных зловредов, вирусов, троянов, десятков 0day-эксплойтов и полезной нагрузки для них, систем удалённого управления и соответствующую документацию.

В опубликованной подборке была документация на эксплойт (закладку) Weeping Angel для телевизоров Samsung со встроенными микрофонами и включенной функцией распознавания речи (голосового управления). Это вредоносное ПО создано подразделением ЦРУ по разработке для встроенных систем Embedded Development Branch (EDB) совместно с британской разведкой MI5/BTSS. Программа добавляет телевизору режим ‘Fake-Off’, когда телевизор выглядит выключенным, но в то же время записывает разговоры в комнате и отправляет их на веб-сервер ЦРУ.

21 апреля 2017 году Wikileaks опубликовал новую информацию по закладке Weeping Angel — подробное руководство пользователя для агентов ЦРУ. Документ датирован 28 февраля 2014 года (pdf). В технической документации инструмент называется EXTENDING. Как пишет Wikileaks, это оригинальная версия закладки, созданная в британской разведке MI5/BTSS и усовершенствованная в ЦРУ. Коллеги из Великобритании и США координировали свою работу над этим инструментом и делились опытом, организуя Joint Development Workshops — семинары по совместной разработке.

На трёх десятках страниц руководства пользователя изложено следующее:

  • ключевые функции закладки EXTENDING;
  • конфигурация зловреда: в комплект поставки входит образ Ubuntu 12.10 ISO для создания виртуальной машины Linux, где происходит генерация зашифрованных файлов с настройками (Windows-инсталлятор Oracle VM Virtual Box позволяет установить среду для запуска этой виртуальной машины Ubuntu VM) — генерация конфигурации должна осуществляться только на защищённом, отключенном от интернета компьютере; присутствует ещё скрипт wlan.bat для конфигурации виртуального адаптера Hosted Network Virtual Adapter на ноутбуке;
  • процесс установки;
  • совместимость с моделями телевизоров Samsung;
  • процесс установки веб-сервера для получения информации с телевизора — веб-сервер устанавливается с помощью Windows-инсталлятора XAMPP, есть также Android веб-сервер PAW Server, в комплект поставки входит файл .apk и сконфигурированная папка PAW2;

  • обработка аудиоданных, записанных через встроенный микрофон, с помощью Windows-программы ECDLive.exe;
  • процедура удаления закладки с телевизора (в изначальной конфигурации задаётся «дата смерти» эксплойта);
  • тестирование и возможные проблемы эксплуатации;
  • известные проблемы и ограничения закладки;
  • расшифровка кодов ошибок (приложение А).

В документе указано, что программа предназначена для моделей Samsung F Series (прошивки 1111, 1112 и 1116), а предварительная конфигурация зловреда осуществляется на персональном компьютере под Linux. Установка на телевизор осуществляется с помощью USB-флешки. Программа может работать в трёх режимах: 1) постоянная аудиозапись; 2) аудиозапись только в режиме выключенного телевизора; 3) аудиозапись только в режиме включенного телевизора.

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

Сами файлы вредоносного ПО из архива Vault 7 обещают опубликовать после проверки и закрытия уязвимостей со стороны производителей.

P.S. Сейчас ЦРУ и ФБР ведут совместное расследование, чтобы установить сотрудника, причастного к утечке документов. Удивительно, что за 1,5 месяца вычислить его не удалось.
ссылка на оригинал статьи https://geektimes.ru/post/288514/

Internet Archive будет сканировать сайты вне зависимости от настроек robots.txt

Интернет-сайт — это обычный набор файлов и папок, который лежит на сервере. Среди этих файлов почти всегда есть один, который называется robots.txt, его размещают в корне. Он служит для инструктирования «пауков», его настраивают для того, чтобы поисковые роботы понимали, что можно сканировать, а что нет. В ряде случаев веб-мастера закрывают при помощи таких инструкций дублирующийся контент (теги, категории и т.п.) для улучшения SEO-показателей, кроме того, защищают от роботов и данные, которые не должны по какой-либо причине оказаться в сети.

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

Проблема в том, что во многих случаях домены брошенных сайтов «дропаются», то есть не продлеваются. Или просто содержимое ресурса уничтожается. Затем такие домены «паркуются» (с самой разной целью, включая получение денег за размещаемую на припаркованном домене рекламу). Файлом robots.txt веб-мастера обычно закрывают все содержимое припаркованного домена. Хуже всего то, что когда робот Internet Archive видит в файле инструкцию по закрытию директории от индексации, он удаляет уже сохраненный контент для сайта, который раньше находился на этом домене.

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

Internet Archive создает «снимки» сайтов. Если сайт существует в течение определенного количества времени, таких «снимков» может быть много. Так что историю развития различных сайтов можно отследить от самого начала до новейшей версии. Пример тому — habrahabr.ru. При блокировании доступа ботам к сайту при помощи robots.txt отследить его историю или получить хоть какую-то информацию становится невозможным.

Несколько месяцев назад сотрудники Internet Archive прекратили отслеживать инструкции в указанном файле на государственных сайтах США. Этот эксперимент прошел успешно и теперь бот Internet Archive прекратит обращать внимание на инструкции в robots.txt для любых сайтов. Если же веб-мастер захочет удалить содержимое своего ресурса из архива, он может обратиться к администрации Internet Archive по почте.

Пока что разработчики будут отслеживать поведение робота и работу самого сервиса в связи с грядущими изменениями. Если все будет хорошо, то эти изменения сохранят.
ссылка на оригинал статьи https://geektimes.ru/post/288512/

Как мы делали совершенно новый КОМПАС-3D: История в семи главах → часть 2

Продолжение Ссылка на первую часть (Осторожно, трафик!).


Продолжаем разбирать по полочкам революционный интерфейс CAD-системы КОМПАС-3D v17. В первой части наш проектировщик интерфейсов Сергей Швецов рассказал, с какими задачами столкнулась команда, с какими задачами столкнулись при разработке нового дизайна. Если вы не понимаете, откуда цитаты или не знаете спецтерминов — добро пожаловать в первую часть материала!

Осторожно, трафик!

Слон точно, как дворцовая колонна!

Глава 3. Сохраняем преемственность

Основные метафоры. Поведение.

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

Пример был в первой части статьи:

Пример для группы команд Выдавливание.


Классический вид. Группа отображалась по зажатой ЛКМ на иконке.


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

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


Классический (слева) и обновленный (справа) вид панели «Параметры» (Картинка кликабельна).

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


Компактная панель (слева) и список наборов (справа). Картинка кликабельна.

Для наглядности так выглядит список строительных наборов

Сейчас список может быть практически бесконечным, раньше он был серьезно ограничен и на компактной панели была только одна строительная панель «СПДС обозначения».

Остальные панели строительных инструментов располагались случайным образом:

– Спор пустой –
Труба, колонна… Схож сей зверь с тахтой.

Глава 4. Тотальная унификация

Команды. Значки. Контролы. Панели. Диалоги. Поведение.

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


Метафоры значков.

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


Плавающая панель «Переменные» (Картинка кликабельна).

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


Диалог «Сохранение документа» (Картинка кликабельна).


Диалог «Удалить объекты» (Картинка кликабельна).

Так диалоги выглядели в прошлых версиях

– Слон скорей всего похож на шахский трон!

Глава 5. Тотальная векторизация

Фреймворк, отсутствие хардкода, векторные значки, векторные хот-точки.

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


Общий вид интерфейса. Включен режим отображения «Полутоновое с каркасом». (Картинка кликабельна)

Концептуально интерфейс выстроен таким образом, чтобы при небольших изменениях его можно было бы адаптировать под возникающие в будущем задачи. Во главу угла поставлена адаптивность интерфейса под различные разрешения экрана. То есть весь интерфейс (за редким исключением) адаптируется под нужды пользователей. Это достигается как «правильным» интерфейсным программированием, в котором размеры интерфейсных элементов не заданы жестко в коде, а зависят от размера системного шрифта, так и практически полным отсутствием растровых изображений в интерфейсе (кроме изображений в интерфейсной справке). Реализовать такое позволяет наше ноу-хау — полностью векторные значки, как монохромные, так и цветные. Вы спросите, как это помогает пользователю? Отвечаю. На любом разрешении экрана интерфейс v17 остается предсказуемым и стабильным. Все интерфейсные элементы пропорциональны друг другу и четко отображаются. Пользователь при помощи системных настроек Windows уже сейчас может управлять размерами интерфейсных элементов и интерфейсного текста. В будущем мы планируем сделать такую поддержку внутри КОМПАС-3D. Т.е. пользователь самостоятельно сможет настроить размер интерфейсного текста и значков в зависимости от своих предпочтений.

Векторные характерные точки


Характерные точки для элемента выдавливания(синие треугольники и квадраты).

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

– Ваш слон – большая полированая пика!

Глава 6. Убираем модальность

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

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


Диалог задания размерной надписи. Классический вид (Картинка кликабельна)


Диалог задания размерной надписи. Обновленный вид (Картинка кликабельна)

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

Алифа он прямей.

Глава 7. Контрастные темы

Почему 50 оттенков серого и почему на 50 оттенков темнее.

В самом начале статьи я уже писал, что интерфейс — это зло. Но не расшифровал почему. Делаю это сейчас. Идеальный интерфейс, как ни парадоксально, — это полное отсутствие интерфейса. Если бы у инженера была возможность проектировать изделия без всякого дополнительного интерфейса, то это был бы идеальный продукт и его бы хотели все. Но исторически сложилось так, что эволюция технологий протекала через развитие и совершенствование инструментов, а любой инструмент это интерфейс. Делая инструмент более удобным и эффективным, вы как бы убираете его из своего сознания, т.е. не замечаете его, он для вас перестает существовать. Согласитесь, что во время работы вы чаще будете обращать внимание на лопату, если её черенок плохо отшлифован, и не будете вовсе обращать внимание на хорошо отполированный черенок, уделяя внимание непосредственно копке. Так и с интерфейсом. Чем меньше он заметен, тем больше вы отдаетесь своей работе, тем продуктивнее и счастливее становитесь.
Делая серый-нейтральный основным цветом для интерфейса нового КОМПАС-3D v17, мы убрали лишнюю, раздражающую составляющую старого интерфейса — беспричинное многоцветие.

Примеры беспричинного многоцветия

Различные режимы отображения нового интерфейса


Монохромные значки. Светлый режим (Картинка кликабельна).


Монохромные значки. Темный режим (Картинка кликабельна).


Цветные значки. Светлый режим (Картинка кликабельна).


Цветные значки. Темный режим (Картинка кликабельна).

Но мы не отказались полностью от цвета, как это может показаться на первый взгляд. Цвет теперь является дополнительным фактором, привлекающим внимание пользователя. Будь то цветная модель, или чертеж, или индикация состояния системы. Заметить яркий цветной огонек в сумерках гораздо легче, чем на праздничной елке с игрушками и мишурой. Не забыли мы и про контрастность. Контрастность нового интерфейса фон: текст\значки составляет 11,2:1 в светлой теме и 5,69:1 в темной. Это соответствует рекомендациям WCAG. Такой запас контрастности позволяет работать при разном освещении, не напрягая зрение.

– Как даль он согнут!

Что готово? Не готово! Стрижка только начата!

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


Включен режим отображения «Каркас» (Картинка кликабельна).


Коллаж разных режимов отображения в одном окне (Картинка кликабельна).

Сергей Швецов, дизайнер-проектировщик пользовательских интерфейсов АСКОН
ссылка на оригинал статьи https://habrahabr.ru/post/326886/

Как Google Cloud защищает свои дата-центры от киберпреступников и внутренних ошибок

Корпорация Google — поставщик сервисов для миллиардов пользователей. Понятно, что данные пользователей, которые хранятся на серверах в дата-центрах Google — лакомый кусок для киберпреступников. Для защиты данных корпорация использует несколько методов многоуровневой защиты. Сейчас речь идет об облачной платформе Google Cloud, которая рассчитана, по большей части, на представителей бизнеса.

В команде, которая обеспечивает безопасность Google Cloud, работает около 700 инженеров, включая программистов, электронщиков и представителей прочих специальностей. В святая святых дата-центров компании попадают только уполномоченные представители технической поддержки после многоуровневой проверки. Нильс Провос (Niels Provos), один из руководителей службы безопасности, раскрыл некоторые подробности своей работы.

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

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

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

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

В частности, речь идет и об аппаратных методах, включая специализированные чипы, в которые вшиты подпрограммы, разработанные Google. Один из таких чипов — Titan. Его корпорация <a

href=«blog.google/topics/google-cloud/bolstering-security-across-google-cloud»>представила в прошлом месяце, не приведя технических подробностей его работы. Известно только, что это кастомный чип безопасности, который создан для предотвращения вмешательства еще на уровне BIOS, а также отслеживает и идентифицирует сервисы и аппаратное обеспечение, которое работает в дата-центрах Google. Этот чип может отслеживать подключаемое оборудование для того, чтобы удостоввериться в его безопасности. Сейчас Titan устанавливается на серверах.

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

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

Борьба с DDoS

Инфраструктура компании рассчитана на то, чтобы поглощать слабые DDoS-атаки. Кроме того, компания установила промежуточные слои защиты для того, чтобы сделать атаки такого типа безопасными. Например, движок Google Front End (GFE) был создан специально для того, чтобы поглощать традиционные типы атак без вреда для инфраструктуры и сервисов.

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

Кроме того, Google продолжает наращивать пропускную способность своих ДЦ. Например, в последнем поколении инфраструктуры Jupiter в дата-центрах компании «ширина» каналов увеличена более, чем в 100 раз. Один канал связи Jupiter может работать со скоростью 1 петабит в секунду. Этого канала хватает для того, чтобы 100000 могли быть связаны с собой в любой момент времени и эффективно отражать DDoS-атаки.


ссылка на оригинал статьи https://habrahabr.ru/post/327260/