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



Введение

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

Ключевые возможности системы:

— встроенные инструменты управления для быстрого разворачивания больших сетей;

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

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

— полное портфолио решений от одного вендора, которое обеспечивает хорошую совместимость компонентов сети;

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

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

Сетевая архитектура

Nebula предоставляет архитектуру для создания и управления сетями через интернет по модели Software as a Service (SaaS). То есть, она избавляет от необходимости физического построения локальных систем для управления сетью. Все устройства Nebula управляются из облака через безопасное TLS-соединение. Таким образом можно управлять сотнями устройств из любой точки, где есть интернет и вносить изменения в политики и настройки сети через центральную панель управления.

Nebula использует инфраструктуру и сервисы построенные на базе Amazon Web Service (AWS), поэтому защита данных и трафика осуществляется службой AWS Cloud Security. Поступающие от устройств данные разделяются надвое — служебная информация (например, конфигурация, данные мониторинга, статистика и т. д.) передаются в облако при помощи защищенного соединения с использованием специализированного протокола NETCONF (о нем дальше), а пользовательский трафик (например, во время веб-серфинга или использования приложений) отправляется сразу к целевому серверу, не проходя через облако.

Стандарт NETCONF

Nebula — это первое в отрасли решение, которое использует протокол NETCONF для безопасности изменений настроек сети через облако. При передаче данных с помощью этого протокола используется протокол TLS, что гарантирует безопасность данных. До внедрения NETCONF использовались скрипты интерфейса командной строки и протокол SNMP. У этих решений есть некоторые недостатки, например, нет управления транзакциями и надежных механизмов безопасности. Протокол NETCONF как раз и был разработан для устранения этих недостатков. Он поддерживает TCP для преодоления барьера NAT и считается более надежным, чем вышеуказанные протоколы. Он также использует меньше трафика, что важно при управлении сетью через облако. Таким образом это сейчас оптимальное решение для Nebula.

Nebula Control Center

Центр управления Nebula Control Center (NCC) предоставляет пользователю обширный инструментарий для работы с сетью и четкое видение происходящих в ней процессов. Через веб-интерфейс, который доступен на компьютерах, смартфонах и планшетах, можно сразу увидеть анализ производительности сети, статус устройств, и общее состояние сети. Информация поступает в Nebula Control Center в автоматическом режиме, все, что нужно сделать администратору, это просто зайти в него. В Nebula Control Center также есть ряд инструментов обеспечения безопасности, которые обеспечивают защиту устройств и пользователей, а также предоставляют необходимую информацию для повышения уровня безопасности всей сети. Далее опишем основные возможности, которые предоставляет NCC.

Управление на базе ролей

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

Мониторинг в режиме реального времени

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

Инструменты управления структурой сети

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

Настройка предупреждений

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

Защита от неправильной настройки

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

Аудит входа в систему

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

Поддержка SSL

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

Закрытие соединения после тайм-аута

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

Мобильное приложение Nebula

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



Семейство продуктов

Беспроводные точки доступа

Беспроводные точки доступа Nebula предназначены для установки в офисах, школах, больницах, магазинах, ресторанах и других публичных местах, а также на предприятиях. Они поддерживают новейший стандарт 802.11ac и такие технологии, как MIMO, Smart Antenna, DCS, Load Balancing, Smart Client Steering и другие. Все это позволяет выстроить продуктивную Wi-Fi сеть и организовать надежное покрытие сигнала. Все они управляются через облако и имеют функцию автоматической настройки, что существенно облегчает разворачивание и обслуживание беспроводной сети. Ниже вы можете ознакомиться с характеристиками фирменных точек доступа Nebula.

Особенности:

• Точка доступа MIMO 2x2 802.11ac AP поддерживает скорость до 1.2 Gbps (NAP102);
• Точка доступа MIMO 3x3 802.11ac AP поддерживает скорость до 1.75 Gbps (NAP203, NAP303, NAP353);
• Антенна с двойной оптимизацией (NAP203);
• Смарт-антенна (NAP303);
• Корпус, обеспечивающий всепогодную защиту по IP66 (NAP353);
• Самоконфигурирование, автоматическое развертывание (zero-touch);
• Безопасность корпоративного классаи оптимизация радиосвязи;
• DCS, балансировка нагрузки и smart client steering;
• Поддержка регистрации в системе с учетной записью Facebook;



Коммутаторы

Сетевые коммутаторы Nebula с поддержкой обработки трафика уровня 2 — это хорошее решение для развертывания в филиалах с последующем управлением ими через облако. Nebula Control Center позволяет удаленно производить мониторинг и настройку всех доступных портов, а также настраивать несколько коммутаторов за пару щелчков мышки просто используя один шаблон. Также доступен ряд облачных преимуществ: упрощенное конфигурирование и управление, отображение состояния всей сети и контроль в реальном времени, что существенно ускоряет развертывание филиальной сети. Такие расширенныенастройки, как ACL, VLAN-based QoS и расписание PoE, существенно улучшают эффективность управления сетью. Ниже вы можете ознакомиться с характеристиками фирменных сетевых коммутаторов Nebula.

Особенности:

• Гигабитные коммутаторы L2 с 8/24-портами с поддержкой PoE и без PoE;
• Наличие 10GE uplink портов для подключения к высокоскоростной сети (NSW200-28P);
• Удобное конфигурирование ACL и VLAN;
• Поддержка DHCP Server Guard и IGMP snooping;
• Поддержка технологии PoE с бюджетом мощности 375 Ватт (NSW200-28P, NSW100-28P) / 180 Ватт (NSW100-10P);
• Зеркалирование портов для мониторинга сетевого трафика;
• Интеллектуальная технология PoE и сетевая топология;
• Аутентификация по RADIUS или 802.1X, static MAC forwarding;



Шлюзы безопасности

Сетевые шлюзы безопасности Nebula обеспечивают для организаций надежную защиту сети. В них используются функции Next-Gen Firewall, например, IDP (система обнаружения вторжений), что обеспечивает высокий уровень защиты для предприятий малого и среднего бизнеса. Шлюзы безопасности Nebula разработаны в расчете на управление из облака и могут автоматически получать свои настройки, настраивать site-to-site VPN, автоматически получать через интернет обновления ПО и сигнатур безопасности. С помощью облачного интерфейса Nebula администраторы могут задавать политики безопасности для всей сети и легко контролировать сети во всех филиалах. Ниже вы можете ознакомиться с характеристиками фирменных сетевых шлюзов безопасности Nebula.

Особенности:

• Полный контроль из облака над сетью, безопасностью и приложениями;
• Легкая настройка site-to-site VPN
• Безопасность сети обеспечивают Next-Generation Firewall, IDP и Application Patrol;
• Встроенные функции DHCP, NAT, QoS и управления VLAN;
• Поддержка статической маршрутизации и сервисов DynDNS;
• Правила безопасности и управление приложениями;
• Поддержка аутентификации в облаке Nebula.



Лицензирование

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

Кредитное лицензирование

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

Ограниченная пожизненная лицензия на сервисы Nebula Control Center

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

Лицензия Nebula Security Service License

Для уменьшения первоначальных затрат на покупку лицензии, упрощения регистрации и активизации шлюзов безопасности Nebula Security Gateway (NSG), каждый NSG поставляется с лицензией IDP and Application Patrol Nebula Security Service license (NSSIDP) на 1 год. Лицензию NSS-IDP нужно приобретать в дополнение к лицензии на Центр управления. Если в компании используется несколько NSG, то сроки окончания действия их лицензий также можно синхронизировать, но их нельзя синхронизировать с лицензиями на сервис Центр управления Nebula.

Синхронное окончание срока действия лицензий

Центр управления Zyxel Nebula автоматически подстраивает даты окончания всех лицензий на один и тот же день. Когда компания закупает дополнительные лицензии на оборудование, то сроки действия старых лицензий и новых пересчитываются и корректируются так, чтобы у всех лицензий была одна и та же дата окончания действия, и в результате у компании все лицензии действуют до одной и той же даты. Обратите внимание, что использование сервиса Zyxel Nebula Service определяется условиями License Co-termination.

В сухом остатке

Zyxel Nebula — это экосистема аппаратных и программных средств, которые позволяют централизованно построить на их базе сеть и осуществлять управление из одного места при помощи простых инструментов. Семейство Zyxel Nebula включает в себя беспроводные точки доступа, коммутаторы и шлюзы безопасности, а также облачный центр управления. Построенная сеть предназначена для использования в предприятиях малого и среднего бизнеса, которые имеют несколько филиалов, а также в публичных местах (ресторанах, школах и т. д.). Для фирм, которые постоянно расширяются, очень удобно увеличивать размер сети благодаря простоте в установке новых устройств и их настройки — фактически, конфигурация оборудования происходит автоматически, что позволяет экономить как на обслуживании сети, так и на содержании ИТ-персонала. Также Zyxel предлагает гибкие модели лицензирования, а также гарантирует работоспособность базовых функций сети даже после окончания срока действия подписки. Все это делает Nebula очень привлекательной для предприятий категории SMB (small and medium business).

Original source: habrahabr.ru (comments, light).

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

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

Первый курс

Обучение в таком заведении стандартное. Есть учебный план, есть преподаватели, которые обязаны следовать ему, сессия, курсовая, следующий курс. Первый курс нашего колледжа заключается в 10-11 классе с усиленной математикой и информатикой. Но уже на первом курсе я начал удивляться. На парах информатики нас заставляли писать, конспекты о клавиатуре. Заставляли делать лабораторные работы на тему «Регистрация почты в сервисе yandex». Подумал это первый курс, нормальное явление, не все такие умные, всем нужно получить азы пользования компьютера. И со спокойной душой перешёл на следующий курс.

Второй курс

Вот оно! Новые предметы, преподаватели, высшая математика и менеджмент. Первые недели все было не плохо, а дальше всё превратилось в полную ахинею. Математику нам преподавали в виде: «Вот формулы производных, сюда, туда, ответ». Хорошо, решать я их научился, а зачем они мне нужны, не объяснили. Каждая новая страница учебника именно так и преподносилась. Как можно заинтересовать студентов новой темой, просто преподнося новые формулы для новых примеров? Иногда путаешься, чем они отличаются от предыдущих, если бы учитель показал применение производных в жизни и показал их важность, было бы намного интересней изучать материал, да и отложилось бы на долгое время.

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

Третий курс

Кончилась математика, добавились другие профильные предметы. Теория осталась прежней, лабораторные работы по html и basic весь ГОД. Конспектировали о периферийных устройствах или про текстовый процессор блокнот. Согласитесь, наверное, не ожидаешь на предпоследнем курсе, что тебя будут учить печатать в блокноте.

Появился интересный предмет «Сопровождение программного обеспечения». На нём, мы проходили 1С. Ура! Что-то нужное. Как я ошибался, ведь нам просто скинули на компьютеры инструкцию с примерами и сказали выполнить за целый год. Мало того, что инструкция не подходит по версии программы, так преподаватели сами не понимали программу. В итоге целый год вводили данные в 1С.



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

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

Что я хочу этим сказать?

Сейчас я нахожусь на последнем курсе моего учебного заведения. Все осталось прежним, разве что добавился Lazarus и написание дипломной работы. Я хочу сказать, что меня ничему не научили. Всё чему я научился — последствие психов, от того что меня ничему не учат. От такого и правда появляется мотивация к самообразованию. Хоть спасибо есть за что сказать.

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



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

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

Конечно, какие-то полезные знания они дали, но по эффективности знания/время — в глубоком дне.

— понравившийся комментарий.

Не стоит искать образование в колледжах. Тут Вы найдёте основы основ. Женщин лет 50, которые преподают предмет «Архитектура ЭВМ» и с ней Вы будете составлять кроссворд в excel. А на другом предмете, вы будете писать электронную тетрадь в word, где нужно вставить из интернета определение информатики. Если откажитесь писать определение информатики на компьютере — заставят писать в тетрадке.

Что мне делать дальше?

Сейчас после окончания, меня отправят служить родине. После службы наступает момент выбора дальнейшего пути ниндзя. Пойти работать верстальщиком, уйти в фриланс? А может поступить в ВУЗ?

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

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

Original source: habrahabr.ru (comments, light).

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

Едва успела выйти новая версия MacOS (недели не прошло), как исследователь из Synack Патрик Уордл опубликовал шикарный пост о High Sierra. Оказывается, что Keychain – защищенный контейнер для учетных данных, PIN-кодов, номеров банковских карт и прочих важных данных – на самом деле уже версии три как ничего не защищает. То есть по факту Keychain это такое место, откуда можно разом украсть вот это вот все.

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

Сразу после публикации Патрику насовали комментов в духе «что ж ты такой гад, не в Apple сообщил, а в блоге публикуешь», и что ему просто не хватает внимания окружающих. Но бедняга на самом деле сообщил в контору, и даже эксплойт готовый послал, просто контора от него отмахнулась! Мотивировали знатно – мол, нечего ставить софт из безнадежных источников, а ставьте только из MacAppStore, и читайте предупреждения безопасности от macOS. То есть в принципе это шаблонный ответ для сообщения обо всех локально-эксплуатируемых уязвимостях. Кто ставит левый софт – тот сам виноват. Кстати, программа вознаграждения за уязвимости в продуктах Apple не распространяется на MacOS.

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

По словам исследователя, он протестировал уязвимость на версиях High Sierra и Sierra, и не видит причин, почему бы ей не быть и на El Capitan. Защититься от этого можно ценой небольшой толики удобства – достаточно установить блокировку Keychain, чтобы при попытке доступа к нему запрашивался пароль. Ну и да, по возможности избегайте установки приложения из левых источников.

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

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

Соответственно, мобильных приложений для трейдинга выпущено очень много. Понятно, что их вендоры должны тщательно выстраивать систему безопасности, даже в ущерб удобству – деньги на кону большие. Но вот на поверку все оказалось не так. Исследователи из IOActive взяли 21 приложение из топа (как для iOS, так и для Android) и нашли там много веселых дыр. Очень много. Вплоть до хранения паролей открытым текстом и передачи данных по HTTP.

И в этот раз исследователи продемонстрировали ответственный подход к раскрытию уязвимостей и обратились к 13 брокерским компаниям, поставляющим эти приложения. Таки что бы вы думали? Ответили только две. Им некогда – торговать надо, а тут пристают с уязвимостями. Алехандро Эрнандез из IOActive вот так выразил свою реакцию на произошедшее: «Господа, я кажется, фрустрирован! Я работал аудитором и знаю, как жестко регулируется финансовый сектор. И очень странно, что мы столкнулись с такими проблемами».

Deloitte уверяет, что кибератака затронула лишь несколько клиентов

Новость. «Большая четверка» аудиторов всегда считалась примером оптимальных бизнес-практик и политик. Понятно, что в кибербезопасности трудно подстелить солому везде, где есть вероятность упасть, но и в этой области есть правила, которые не стоит нарушать, если не хочешь подставить своих клиентов. И вот на тебе! Отличился Deloitte, один из столпов бизнес-сообщества.

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

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

Древности

«ZipEater-1984»

Использует «стелс»-функцию при вызове функций DOS FindFirst и FindNext. Очень опасен – иногда уничтожает файлы, у которых сумма символов расширения имени (т.е., например, у .COM-файлов: ‘C’ + ‘O’ + ‘M’) в ASCII-кодировке равна 100h, D6h, F3h, E2h или DFh. К таким файлам относятся .TXT, .STY, .BAS, .DOC,. ZIP, .EXE и .COM-файлы.

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 36.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Original source: habrahabr.ru (comments, light).

Изображение: Wikimedia commons

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

Всеобщее безумие

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



Динамика индекса фьючерсных (зелёным) и опционных (красным) цен на луковицы в 1635—1637 годы по Томпсону. Изображение: Wikimedia Commons

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

Есть только небольшой нюанс: эта история — неправда.

Чтобы понять правду, нужно разобраться в истории

Что же происходило на самом деле и как получилось, что история спекуляции тюльпанов в Голландии была настолько искажена? Энн Голдгар, профессор ранней современной истории Королевского колледжа Лондона, обнаружила правду, когда изучала архивы, для создания книги «Тюльпаномания: Деньги, честь и знания в Голландии Золотого Века».

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

Прежде чем ставить «тюльпанную лихорадку» в один ряд с пузырём Южного Моря, который случился в 1700-х годах в Англии, с железнодорожным пузырём XIX века, с пузырями доткомов и биткойнов, стоит изучить несколько доводов профессора Голдгара и понять, что происходило в голландском обществе на рубеже XVII века.

Стоит начать с того, что страна пережила крупный демографический сдвиг, во время войны за независимость с Испанией. В этот период купцы прибыли в крупные портовые города: Амстердам, Гарлем, Делфт и начали торговлю, в том числе знаменитую Голландскую Ост-Индийскую компанию. Это принесло огромный доход Голландии, даже несмотря на военное положение в стране. Во главе новой независимой нации стала городская олигархия, состоящая из богатых купцов, в отличие от других европейских стран той эпохи, которые контролировались дворянством. В результате новые лица, идеи и деньги помогли революционизировать голландскую экономику в конце 16 века.

Так как экономика изменилась, изменились социальные взаимодействия и культурные ценности. Растущий интерес к естественной истории и любовь к экзотике среди купечества вызвали рост цен на товары с востока, в том числе из Османской империи. Людям всех социальных классов пришлось развиваться в новых направлениях, которые появились с притоком новых товаров. Например, рыбный аукционер создал рукопись «Книга Китов» и эта работа позволила ему встретиться с президентом Голландии. Голландский ботаник Клузиус создал ботанический сад в Лейденском университете в 1590 году и тюльпан быстро поднялся на почётном месте.

«Дикорастущие тюльпаны, найденные в долинах Тянь-Шаня, начали разводить в Стамбуле в 1055 году, а в XV веке они уже стали символами османов. Например, у султана Мехмеда II было 12 садов с тюльпанами, на содержание которых требовалось 920 садоводов» — пишет в книге «Тюльпаны» Анна Паворд, корреспондент по садоводству интернет-издания The Independent.

Голландцы вывели, что тюльпаны могут быть выращены из семян и отростков материнской луковицы. Чтобы из семечки выросла луковица и цветок зацвёл, требуется от 7 до 12 лет. А уже созревшая луковица может стать тюльпаном через год. Особый интерес для ботаника Клузиуса и «тюльпановых спекулянтов» представляли «разбитые луковицы». Лепестки у тюльпанов, которые вырастали из этих луковиц, были не однотонными, а разноцветными. Предугадать, как будет выглядеть будущий цветок было невозможно. Натуралисты придумывали способы, как воспроизвести такие луковицы и бутоны, так как спрос на этот редкий вид постоянно рос. Как выяснилось позже, такой эффект получался из-за того, что луковицы болели. Они были хилыми и редко давали цветы.

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



Печатный отчёт об итогах аукциона в Алкмаре 5 февраля 1637 года. Изображение: Wikimedia commons

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

Начало легенды

Вот, где миф вступает в игру. Согласно популярной легенде, «тюльпаномания» охватила все уровни голландского общества в 1630 году. «Стремление голландцами обладать редкими луковицами было настолько большим, что обычная промышленность была заброшена, а население, вплоть до самых низших слоёв, стало торговать тюльпанами» — пишет шотландский журналист Чарльз Маккей в популярной работе 1841 года «Чрезвычайно популярные заблуждения и безумие толпы». Согласно этой работе, все, от самых богатейших купцов, до беднейших трубочистов, скупали луковицы тюльпанов и перепродавали их по более высокой цене. Больше всего компаний по продаже тюльпанов было в конце 1636 года, а в феврале рынок начал трещать по швам. Всё больше и больше людей разорялись, в надежде купить заветные луковицы, и всё больше торговцев, оставшись в долгу, становились банкротами. По крайней мере, так всегда считалось.

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

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

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

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

Кто распространил миф?

Если «тюльпаномания» не была таким бедствием, зачем же её выставили в этом свете? Можно предположить, что в этом виноваты обиженные христианские моралисты. С большим богатством приходит волна социального беспокойства. «Невероятный уровень успеха вскружил им головы. Все невероятные истории, подтверждающие экономическую разруху: про моряка, брошенного в тюрьму и про трубочистов, пытающихся разбогатеть, пришли из пропагандистских брошюр. Их распространили голландские кальвинисты, боявшиеся, что тюльпановый бум приведёт к социальному гниению. Их убеждение, что это богатство было ужасным, дошло и до наших дней» — пишет историк Саймон Шам, в книге «Конфуз богатства: Интерпритация голландской культуры в Золотом Веке».

«Некоторые идеи неискоренимы, например та, что Бог не любит хитрецов и насылает на них чуму. Вот что могли сказать люди в 1630 году, — говорит Энн Голдгар, — идея, что хитрость — грех дожила до современного общества. Гордыня предшествует падению».

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

Полезные ссылки и материалы для изучения фондового рынка

• Образовательные ресурсы ITinvest
• Аналитика и обзоры рынка
• Топ-10 книг для понимания устройства фондового рынка
• Фьючерсы, индексы и IPO: как на самом деле устроены биржи и зачем они нужны
• Инфраструктура российского рынка ценных бумаг (краткий ликбез)
• How-to: роботы и API брокерской торговой системы

Original source: habrahabr.ru (comments, light).

Задумал я сделать интернет у себя на даче, в глуши. И наконец возможность срослась с желанием! Проблем в моей глуши две: дураки частые перебои с электроэнергией (в зависимости от погоды может ещё отключиться АТС) и плохая мобильная связь. Сигнал ловится не везде, а где ловится, там нестабилен. Добавляет сложности и оцинкованная крыша дома, экранирующая радиоволны. Возможности современного оборудования и корректировка запросов сужали и улучшали подходящие свойства, что привело меня к мысли создать максимально работоспособный узел сети. Я расскажу о том, как пытался поймать LTE-сигнал, с описанием оборудования и возможными проблемами.

Подготовка и сбор информации о местности

В моей глуши нормально ловится только МТС, в связи с чем был выбран именно этот оператор. Качество покрытия я определял с помощью https://4g-faq.ru/karty-pokrytiya/. На этой карте удобно выбирать режимы сети, а также хорошо видно ориентировочное расположение вышек стандартов 3G и LTE.

Направление установки антенн выбиралось примерно так:

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

Интересующие и важные характеристики

Для начала необходимо понять, какой режим сети вас интересует. Диапазон частот у 3G и LTE разный, и, чтобы принимать их сигналы, необходимо выбрать антенны или облучатели, в зависимости от конфигурации, с соответствующей частотностью. Конечно, можно взять антенны с частотным диапазоном, который захватывает оба стандарта, но в таком случае выходной сигнал будет немного хуже (опять же, в зависимости от количества переходников, длины кабелей и их свойств; эти характеристики влияют на все конфигурации данной системы, в том числе это касается и затухания сигнала).

Необходимо заранее проверить на площадке уровни сигналов мобильных сетей. Как уже говорил, я выбрал МТС, потому что здесь он ловится всегда и у МТС довольно много вышек (по сравнению с другими операторами) с разными режимами сетей, в том числе и LTE, который, надеюсь, в будущем проапгрейдят до 5G. Так что своё оборудование я подобрал «на вырост».

Выбор и настройка оборудования

Лишний раз переплачивать мне не хотелось. И система с легко заменяемыми компонентами выходила дешевле, чем спутниковый интернет и предложения от фирм, которые делают готовые наборы. Вариант со «свистком» отпал на первый день подбора оборудования: такая система крайне нестабильна. Ещё я планировал поставить систему на долгосрочную работу, но этот вариант тоже не подходил, поскольку компоненты корпуса при длительной работе перегревались и выводили «свисток» из строя до его остывания. В большинстве случаев данная проблема решалась пришаманенным кулером, но нестабильность подключения и потери пакетов не склонили меня к этому варианту. По той же причине я отказался от мысли о тандеме «свисток» + роутер (с поддержкой «свистка»).

Изначально я планировал использовать «восьмёрку», она же антенна Харченко, но, учитывая зону покрытия и расстояние до ближайших населённых пунктов, есть возможность успешно ловить 3G-LTE на дистанциях, превышающих возможности «восьмёрки». Такой диапазон частот соответствует этим сетям и взят на случай непогоды, когда осадки существенно ухудшают качество сигнала. Меня удивил тот факт, что 4G-LTE работают в трёх диапазонах: около 800, около 1600 и около 2500.

Частотные диапазоны LTE-сетей у различных провайдеров:

Здесь разобраны частотные диапазоны 3G-сетей:

Причины выбора канала относительно офсета

Офсет, как мне кажется, гораздо лучше, так что я сделал неправильный выбор, особенно учитывая свои возможности: но LTE я ловил на «волнушку», и проблема заключается в высоте. Для начала я долго и усердно выбирал оборудование и возможные связки, в том числе и различные типы антенн. В итоге мне понравились два варианта:

1. Офсетный рефлектор диаметром 0,9 м или более с облучателем на частотные диапазоны от 1700 до 2700 МГц и с поддержкой технологии MIMO.
2. Сдвоенный волновой канал с такой же частотностью.

Коэффициент усиления у обоих наборов — от 24 до 28 dbi. Остановился я на втором: у него гораздо меньше проблем с ловлей сигнала от телефонных вышек. Кабель взял с пониженными потерями и затуханиями, чтобы сигнал на приём был стабильнее.

На месте я выставлял антенну с помощью Google Maps и программы MDMA. Настольная версия MDMA позволяет проверить уровень сигнала на принимающем устройстве (модуль модема в роутере). С этой программой обращаться не так просто, но если вы разобрались с Netmonitor, то у вас она вряд ли вызовет затруднения. В конце концов, есть очень неплохие рекомендации и понятные инструкции. Обратите внимание, что нужно подключение через USB «папа-папа».

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

MDMA:

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

• Huawei E5172
• Huawei B315S (есть альтернативы у провайдеров и операторов связи)
• Skylink V-FL500
• TP-LINK TL-MR6400
• ZTE MF283 (есть альтернативы у провайдеров и операторов связи)
• Huawei B310

Разброс цен — от 4 до 9 тысяч рублей за единицу. Я выбрал Huawei B315S из-за дешевизны и возможности создания IP-телефонии и подключения до 32 устройств. А ещё он может ловить LTE.

Конфигурация моего оборудования

Роутер B315s-22:

Huawei B315S изначально был привязан к Yota, но я выполнил отвязку

Поскольку, кроме МТС, у меня ничего не ловилось, то и смысла усиливать то, что не ловится, не было. Но ситуация сложилась так, что мне пришлось купить роутер Yota, привязанный к сим-картам одноименного оператора (другие не подходили, проверял). Для отвязки каждого роутера свой способ, информацию легко найти в интернете, в том числе и на 4pda.ru. Полное название модели по классификации — Huawei LTE CPE B315s-22, так что, если вам необходимы технические характеристики, ищите по названию в интернете.

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

Две антенны работают в тандеме по технологии MIMO, волновой канал с 24—28 dbi. Два кабеля с пониженными потерями длиной 10 метров, стандарт 5D-FB. Соответственно, придётся либо заказать переходники, либо заменить разъёмы подходящими, с одной стороны — для антенн, с другой — для подключения роутера.

Результат трудов:

Проблемы, с которыми я столкнулся (раздел о боли, унижениях и страданиях)

Сразу хочу дать рекомендации на основании своего опыта:

1. Если собираетесь повторять такое далеко от городов-миллионников, то стоит заранее озаботиться покупкой оборудования в большом городе.
2. Выбирайте тип и вид антенны в зависимости от ландшафта и расстояния до населённых пунктов.
3. Обратите внимание на растительность, постройки и дистанцию между точками.
4. Подбирайте оборудование, максимально подходящее под ваши требования.
5. Не покупайте оборудование у оператора связи, если только не планируете пользоваться его услугами или не выигрываете сильно в цене.
6. Используйте минимум переходников и оборудования на открытом воздухе.
7. USB «папа-папа», он же USB AM — USB AM, пригодится на любой стадии работы или настройки, поэтому всегда держите его под рукой. Я в магазинах не нашёл, так что пришлось собирать на коленке из старых запчастей.
8. Отвязка роутера от оператора — это боль. На некоторых роутерах и прошивках невозможно сделать отвязку без нарушения целостности корпуса, что приводит, в свою очередь, к потере гарантии. Ознакомьтесь с ассортиментом, всегда можно найти отвязанный вариант (или ваш выбор — AliExpress).
9. Если всё-таки решились на привязанный, то озаботьтесь прошиванием в городе со стабильным интернетом. То есть подготовьте оборудование к работе до отъезда на площадку.
10. Выбор тарифного плана и возможности безлимита. По большому счёту можно добиться безлимитного интернета через SIM-карту, однако для этого необходимо изменить конфигурацию модуля модема в роутере.
11. Подготовьте подходящий модем-расходник для использования его IMEI, чтобы упростить себе задачу. Можно взять любой подходящий по конфигурации и поддерживаемым сетям.
12. Если собираетесь использовать сети выше LTE, то подбирайте роутер с двумя антеннами. Это связано с поддержкой протокола MIMO.
13. Проверяйте у магазинов рабочий диапазон частот выбранной вами антенны. Велика вероятность, что вас попробуют обмануть.

Заключение

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

Тем, кто пойдёт по моим стопам, рекомендую сразу брать безлимитный тариф, потому что у меня всего 30 Гб трафика. Сети 4G хоть и ловятся оборудованием, но очень плохо. Гипотез две: либо я не принял в расчёт рельеф, либо нашёл антенны, которые не подходят по диапазону рабочих частот. Полагаю, что виноваты антенны: продавец заявляет, что на них написан ошибочный частотный диапазон, но, скорее всего, это ложь, потому что сети 3G ловятся идеально, а именно их диапазон указан на антеннах.

Original source: habrahabr.ru (comments, light).

Пару слов для начала

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

1. Apache JMeter – инструмент для нагрузочного тестирования, который способен проводить тесты для JDBC-соединений, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP и TCP из коробки и еще множество других протоколов и решений, используя различные плагины.
2. Yandex.Tank – это облачный инструмент для нагрузочного тестирования, использует различные генераторы нагрузки, в том числе и JMeter.
3. Yandex.OverLoad – сервис для удобного мониторинга и анализа серверов под нагрузкой.

Установка и настройка

Залогом успеха для правильной установки JMeter является правильная установка java. На данном этапе стоит сказать о том, что все манипуляции дальше будут происходить под ОС Linux. На официальном сайте хорошие мануалы со всеми нюансами:

1. Установка 32-разрядную версию Java.
2. Установка 64-разрядной версии Java.

С Java разобрались для контрольной проверки сделайте java -version в консоле, ответ должен быть примерно таким:

Теперь переходим к Apache JMeter. Ставить можно любую версию JMeter, но если встречаются проблемы типа “Error in NonGUIDriver” то, скорее всего, нужен танк свежей версии или можно без проблем перейти на точно рабочую 2.13. Вернемся к установке — она аналогична для всех версий:
Скачиваем клиент:

wget https://archive.apache.org/dist/jmeter/binaries/apache-jmeter-2.13.tgz

Распаковываем:

tar -zxvf apache-jmeter-2.13.tgz

JMeter установлен и уже будет работать. Для первичной настройки достаточно будет внести только одно изменение. Идем по пути apache-jmeter-2.13/bin открываем для правки файл jmeter без расширения:

cd apache-jmeter-2.13/bin nano jmeter

Находим строку, как на скриншоте ниже. Выставляем значения heap size в соответствии с характеристиками используемого сервера. Первое значение HEAP Xms — объем оперативной памяти выделяемый процессу при его старте, а второе Xmx — максимальное значение оперативной памяти, которое будет доступно процессу.

Если сервер без GUI и доступ к нему удаленный, как в большинстве случаев, лучше поставить JMeter локально для отладки и записи скриптов. В идеале версии должны совпадать, но в большинстве случаев JMeter понимает скрипты соседних или младших версий. Конечно, на локальной машине тоже должна стоять Java и сам JMeter.
Переходим к установке и настройке Yandex.Tank, для этого достаточным должно оказаться выполнение этих действий:

sudo apt-get install python-pip build-essential python-dev libffi-dev gfortran libssl-dev sudo -H pip install --upgrade pip sudo -H pip install --upgrade setuptools sudo -H pip install https://api.github.com/repos/yandex/yandex-tank/tarball/master

Дальше следует рассказать нашему орудию куда стрелять и чем. Для этого создадим рабочую директорию на машине с танком с конфигурационным файлом load.ini:

mkdir test cd test nano load.ini
Содержимое конфигурационного файла является руководством к действиям танка, в нем необходимо отразить все ключевые моменты теста. Вот пример load.ini для теста с использованием JMeter:

Думаю, в блоке [tank] все понятно, если возникают вопросы есть описание каждого поля и блока от самих танкистов. Все самое интересное в блоке [jmeter].
Параметр jmx содержит путь непосредственно к скрипту, jmeter_path — это путь до исполнительного файла JMeter, ну и для того, чтобы танк не делал лишних движений, нужно указать версию JMeter'а в параметр jmeter_ver.

Разработка скрипта

    Пришло время написать первый тест. Для этого открываем клиент JMeter - большинство Windows систем требуют запуск от имени администратора. Про то как начать осваивать JMeter, а заодно разобраться в его GUI хорошо написано в этой статье. У нас же пример с базой данных, что немного отличается от обычных http запросов. Первое отличие в том, что PostgreSQL не поддерживается в JMeter из коробки, поэтому нужно скачать драйвер нужной версии. После чего нужно подложить скаченный .jar в директорию /lib в папке с JMeter. Этот же .jar нужно подложить по аналогичному пути на машине с танком. С драйвером разобрались переходим к скрипту.

Первое, что нужно сделать это настроить подключение к БД, для этого правой кнопкой жмем на Test Plan -> Add -> Config Element -> JDBC Connection Configuration. Дерево теста пополнится конфигурационным элементом, как на скриншоте:

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



Здесь важно заполнить поле Variable Name. Это имя будет использоваться в JDBC Request (Sampler) для доступа к пулу сессий. Еще стоит обратить внимание на Max Number Of Connections, этот параметр лимитирует количество одновременных подключений к БД. Остальное в этом блоке можно оставить так как есть, если нет особых требований к таймаутам и жизненному циклу коннекта.



Переходим к блоку на скриншоте выше, тут от нас потребуется ввести данные для подключения к базе. Шаблон такой:

• Database URL: jdbc:postgresql://IPAddress:PortNo/DatabaseName?autoReconnect=true;
• JDBC Driver class: org.postgresql.Driver;
• Username: username of database;
• Password: password of database.

Приступаем к дальнейшему наполнению дерева теста. Опять нажимаем Test Plan -> Add -> Threads (Users) -> Thread Group.

Перед нами панель управления стрельбой, именно тут вводим какое количество пользователей — Number of Threads, за какое время будет достигнуто — Ramp-Up Period и с какой интенсивностью каждый новый пользователь вместе с предыдущим будет повторять действия.Если нам необходимо максимально часто отправлять запросы ставим галочку “forever” напротив Loop Count. Для первого теста можно выставить значение в пару пользователей, с небольшим количеством повторений. Теперь переходим непосредственно к запросам в БД.



Для добавления в тест план семплера JDBC запроса нажимаем правой кнопкой на нужный нам Thread Group -> Add -> Sampler ->JDBC Request. Нас первоначально интересует поле Variable Name, оно должно совпадать с аналогичным параметром из JBDC Connection Configuration. После этого смотрим на выпадающий список Query Type, в зависимости от вашего запроса тут должно стоять соответствующее значение, например, для SELECT запроса в БД, нужно выбрать Select Statement, а для INSERT, COPY и UPDATE — Update Statement, как в нашем примере. В заключении работы с данным семплером нам необходимо задать тело запроса, которое должно соответствовать валидному SQL запросу.

В целом скрипт готов, но нам необходимо его отладить, делается это так:

• в нужный Thread Group после JDBC Request добавляем Debug Sampler. В нем будет отображаться ответ полученный после запроса к БД. Добавляется аналогично предыдущим элементам Thread Group -> Add -> Sampler -> Debug Sampler;
• для того, чтобы увидеть результаты работы того или иного семплера, в конце тест плана нам нужен мониторинг результатов — добавляется он так: Test Plan -> Add — > Listener -> View Results Tree. При запуске скрипта там будет детализация по всем выполненным запроса.

Пришло время тестового запуска пока из самого JMeter — для этого достаточно нажать

и нажать на View Results Tree. После отработки скрипта я получил следующие результаты:

Отладка скрипта

Видим, что первый отработал успешно и смотрим на поле Response message, оно говорит о том, что поле должно быть уникальным. Значит переходим к параметризации. Есть много способов как это сделать, наиболее уникальным из них является параметризация с помощью BeanShell PreProcessor. Для этого нам нужно вставить перед нашим JDBC Request указанный выше препроцессор - Thread Group -> Add -> Pre Processors -> BeanShell PreProcessor. О препроцессорах можно почитать тут или на сайте JMeter. BeanShell PreProcessor не рекомендуется использовать при больших нагрузках, как стабильный и быстрый вариант используйте JSR223 PreProcessor + Groovy. 

Тут никаких изысков — пишем на java, импортируем необходимый класс, объявляем переменную, присваиваем в нее в нее рандомную переменную нужного формата. Для того, чтобы положить полученную переменную в переменную JMeter используйте vars.put(). Теперь переходим в наш JDBC Request и добавляем вместо значения в уникальном поле переменную в формате ${needUUID}, пример на скриншоте ниже:



Конечная структура нашего тест плана выглядит следующим образом:



Делаем еще один запуск из JMeter, сразу смотрим на View Results Tree, выбираем Debug Sampler и встаем на вкладку Response Data:



Тут можем убедиться, что наша переменная успешно сгенерировалась и для всех запросов она разная. Когда тест отлажен и готов к запуску нам необходимо убрать из него отладочные элементы, а именно Debug Sampler и View Results Tree. Делается это простым нажатием правой кнопки на элемент и выбором пункта Remove. На всякий случай прикладываю вид теста после этого:



Теперь сохраняем тест и переносим на машину с танком. Вносим его в параметр “jmx” в файле load.ini и сохраняем. Используется абсолютная адресация. У меня выглядит так:



Пришло время первого запуска, чтобы понять, что на этом этапе все работает. Перед этим нам нужно проконтролировать добавление строк в БД. Для этого можно использовать инструмент pgAdmin или просто зайти на сервер с базой и сделать count строк до и после отработки скрипта. Коннект к базе выполняется подобной командой:

psql -h IpAddress -d dbName -U UserName

Сам count делаем так:

select count(*) from alert;

Возвращаемся на машину с танком, переходим в директорию где находится load.ini и вводим команду для запуска танка:

yandex-tank

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

Мониторинг

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

• регистрация на Overload;
• получаем токен путем нажатия на иконку профиля в Overload и выбором “my api token”;
• создаем token.txt в той же папке, что и load.ini на машине с танком;
• заносим полученный токен в token.txt и сохраняем;
• добавляем блок [overload] в load.ini — описание от танкистов;

Получаем примерно следующее содержимое load.ini:

Теперь после запуска теста у нас профиле Overload будет отображаться текущий тест и все прошедшие со многочисленными полезными графиками:



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

Напоследок хорошо было бы сказать о том, что с недавних пор, а именно, начиная с версии 3.2 у JMeter появились встроенное решение на базе infux для мониторинга, но там, в отличие от Overload, придется все настраивать самостоятельно.

На этом все. Всем хороших стрельб!

Original source: habrahabr.ru (comments, light).

Зачем нужны заголовки и какие теги для них использовать?

Этот вопрос нам задают чаще всего.

Когда много лет назад придумали HTML, мир был совсем другим. Авторы спецификации вдохновлялись текстовыми документами, где в одном потоке подряд шли абзацы, списки, таблицы, картинки и, конечно, заголовки. Прямо как в ваших рефератах и курсовых: самый большой заголовок — название, заголовки поменьше — части или главы.

В HTML с тех пор шесть уровней заголовков: от

до

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

Еда
  
Фрукты
  
Классные
    
Яблоки
    
Вообще

Но секции лучше задавать явно с помощью элемента

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

Еда

  
Фрукты
  
Классные
  

    
Яблоки
    
Вообще
  

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

Ладно! Раз у нас есть явные секции, то по вложенности легко определить отношение частей. Так может браузеры сами догадаются какого уровня заголовки нужны? А то считать:

,

, аш… сбился. Так было бы удобнее менять части кода местами.

Такая же идея пришла в голову авторам HTML5 и они описали в спецификации алгоритм аутлайна. Он разрешает использовать на странице только

, а важность обозначать вложенностью структурных элементов вроде

и

.

Еда

  
Фрукты
  

    
Яблоки
  

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

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

Нет, погоди. Я ставлю класс на

и все сразу видят — это самый большой заголовок, ставлю другой класс — заголовок становится меньше, видно же. Зачем тогда эта ерунда с расчётом уровней, если есть CSS?

  Фрукты бесплатно


  Только за деньги

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

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

— чтобы найти на странице самое важное, они ищут

. Это читалки и роботы. С роботами всё понятно: это поисковики, которым нужно помогать понимать ваши страницы.

Читалками или скринридерами пользуются люди, которые плохо или совсем не видят ваши интерфейсы, или не могут управлять браузером привычным образом. VoiceOver, NVDA, JAWS читают содержимое вслух и ориентируются только по значимым тегам. Элементы div и span не значат ни-че-го, какие бы классы и стили вы не накрутили. Такой сайт — как газета без заголовков, просто месиво текста.

Да какая газета! Очнись, 2017 на дворе, я изоморфное одностраничное приложение делаю, а не стенгазету. У меня тут стейты компонентов — нафига семантика там, где нет текста? Очень хороший вопрос.

Все читалки идут по странице тег за тегом, от первого к последнему. И читают подряд всё, что внутри. Крайне неэффективно: каждая страница начинается с шапки и пока её пройдёшь, забудешь за чем шёл. Поэтому у читалок есть специальные режимы, показывающие только важные части страницы. Структурные элементы header, nav, main и другие, все ссылки, все заголовки.

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

- Инстаграм
  - Лента
    - Закат
    - Латте
  - Настройки
  - Профиль

Но бывает, что в дизайне нет заголовков для важных частей. Дизайнер рисует, ему всё ясно: меню с котлетой, поиск с полем и так далее. Но это не должно мешает вам делать доступные интерфейсы. Расставьте нужные заголовки, а потом доступно их спрячьте. Как? Только не display: none, его читалки игнорируют. Есть такой паттерн visually hidden, подробнее в описании к видео.

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

Видеоверсия

Вопросы можно задавать здесь.

Original source: habrahabr.ru (comments, light).

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

Введение

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

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

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

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

Покажем преобразования ди- и би-координат — изменение базиса. В дистанционных координатах смена базовых вершин одновременно означает определение новых дистанций между точками пространства. Такой процесс имеет прикладное значение, например, в задачах локализации сенсоров (определения их координат на основе некоторых базисных).

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

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

Поехали!

Дистанционная матрица

Пусть у нас есть множество, состоящее из n элементов. Элементами могут быть геометрическая точка в пространстве, узел графа, буква, слово, документ, человек и т.д., — практически любой объект. Допустим далее, что известна степень близости элементов набора. Для точек в пространстве степенью близости является квадрат расстояния между ними. Для электрической цепи сопротивлений степень близости равна эффективному сопротивлению между узлами сети. В физике мера близости между двумя событиями именуется интервалом. Мы объединим все эти термины под общим названием — дистанция, которую обозначим как $$ — это дистанция между элементами $$ и $$.

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

$$

Верхним индексом обозначен номер компоненты.

Набор точек с известными дистанциями между ними будем называть симплексом. На рисунке показан прямоугольный треугольник (2-мерный симплекс) с катетами 3, 4 и гипотенузой 5. Его дистанционная матрица имеет вид:
\begin{array}{c | c c c}
D_{ABC} & A & B & C \\
\hline
A & 0 & 9 & 16 \\
B & 9 & 0 & 25 \\
C & 16 & 25 & 0 \\
\end{array}
Точно такая же матрица будет описывать сопротивление между узлами электрической цепи из двух последовательно соединенных резисторов (показаны на рисунке). В теории графов ее принято называть матрицей сопротивлений (resistance distance matrix).

Очевидно, что симплекс в трехмерном пространстве определяется 4-мя вершинами (тетраэдр), в двумерном — 3-мя и т.д., — мерность пространства симплекса на 1 меньше количества его вершин.

Векторное окаймление матриц

Дистанционная матрица симплекса $$ не подходит для роли метрического тензора хотя бы потому, что ее определитель не связан с объемом симплекса (в примере — с площадью треугольника). Однако еще в 19-м веке A.Cayley (Кэли) обнаружил, что если расширить (окаймить) дистанционную матрицу вектором из единиц, то определитель полученной матрицы будет пропорционален квадрату объема симплекса. Полученную таким образом матрицу называют матрицей Кэли-Менгера.

Определим операцию окаймления $$ симметричных матриц $$ вектором $$ и скаляром $$:

$$

Если матрица $$ является окаймлением матрицы $$, то $$ является подматрицей $$ и называется главным (угловым) минором $$.

Дистанционный метрический тензор (ДМТ)

Математики (J.C.Gower) также заметили, что удобнее оперировать не с самими дистанциями между точками, а с отрицательными полудистанциями $$:

$$

Знак минус нужен, чтобы избавиться в выражениях от множителей типа $$, а множитель «1/2» позволяет избавиться от степеней двойки.

Дистанционный метрический тензор $$ определяется как окаймление вектором из единиц полудистанционной матрицы $$:

$$

Для нашего симплекса из трех точек (прямоугольного треугольника) дистанционный метрический тензор будет иметь вид:
\begin{array}{c | c c c c}
Dm & * & A & B & C \\
\hline
* & 0 & 1 & 1 & 1 \\
A & 1 & 0 & -4.5 & -8 \\
B & 1 & -4.5 & 0 & -12.5 \\
C & 1 & -8 & -12.5 & 0 \\
\end{array}
В тензорной форме записи дистанционный тензор будем обозначать нижними индексами:

$$

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

Геометрические свойства ДМТ

Как отмечено выше, определитель метрического тензора $$ связан с объемом симплекса $$. Точная формула:

$$

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

Другая полезная характеристика, содержащаяся в ДМТ, — это (внезапно) значение квадрата радиуса описанной сферы вокруг вершин симплекса. Данная n-мерная сфера играет важную роль в системах координат на точках. Для краткости квадрат радиуса будем называть просто радиусом и обозначим как $$. Радиус описанной сферы равен отношению определителей углового минора ДМТ (полудистанционной матрицы) и самого ДМТ:

$$

В нашем треугольнике радиус сферы будет равен: $$.

Лапласовский метрический тензор (ЛМТ)

Известно, что метрические тензоры ходят парами. То есть для заданной метрики всегда есть взаимная, а метрические тензоры взаимных метрик обратны по отношению к друг другу. Обращение дистанционного метрического тензора дает лапласовский метрический тензор (ЛМТ): $$. Связь тензоров:

в матричной форме $$

и в тензорной $$

Почему обратный дистанционный метрический тензор стал лапласовским? Потому что его главным угловым минором (подматрицей) является лапласиан $$. Та самая матрица, которой описывают узлы и связи в графе, ее называют также матрицей Кирхгофа. Формула (1.8) связывает свойства симплексов и графов. Можно утверждать, что каждому невырожденному симплексу соответствует какой-либо граф и наоборот. Такая взаимность позволяет сопоставлять геометрические характеристики симплексов с инвариантами графов.

Структура ЛМТ

Важно то, что лапласовский метрический тензор — это не просто лапласиан, а его векторное окаймление. В структуру ЛМТ входят скаляр и вектор — характеристики описанной сферы вокруг вершин симплекса:

$$

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

Барицентрические координаты — это весовые координаты точки относительно базовых (реперов). Базовыми здесь служат вершины симплекса (или графа). Сумма весов равна единице — условие нормировки барицентрических векторов.

Связь параметров ДМТ и ЛМТ

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

$$

Здесь $$ — полудистанционная матрица, $$ — единичная матрица. Пришли к 4-м основным тождествам.

Сумма компонент барицентрического вектора центра сферы равна 1:

$$

Сумма строк (и столбцов) лапласиана равна 0. Или более абстрактно — вектор единиц ($$) является для лапласиана нулевым:

$$:

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

$$, откуда $$

Связь полудистанционной матрицы и лапласиана через $$-вектор:

$$

Построение дистанционной матрицы по лапласиану

Если мы имеем дело с графом, то для построения дистанционной матрицы на основании матрицы смежности $$ можно использовать следующий алгоритм. Для матрицы смежности считаем лапласиан:

$$

.
Здесь $$ — оператор преобразования вектора в диагональную матрицу.
Определитель лапласиана равен нулю, поэтом его нельзя просто обратить. Надо либо удалить из него какой-то узел, либо дополнить (окаймить) каким-либо вектором.
Здесь рассмотрим второй способ — окаймляем лапласиан вектором из единиц и обращаем полученную матрицу. Главным минором (подматрицей) результата обращения будет матрица Грина $$.

$$

Матрица Грина относится к грамианам $$. Из любого грамиана можно построить дистанционную матрицу по формуле (преобразование дистанции):

$$

где вектор $$ — это диагональ грамиана $$.

Геометрия лапласиана

Сопоставим геометрические параметры симплекса с инвариантами и характеристиками графа.

Объем симплекса и потенциал лапласиана

Матричная теорема о деревьях связывает количество остовных деревьев графа с определителем минора лапласиана. В предыдущих статьях мы называли данную величину скалярным потенциалом лапласиана $$:

$$

Здесь через $$ обозначен псевдодетерминант, то есть детерминант от минора лапласиана (поскольку сам лапласиан — вырожденная матрица).

Видим, что чем меньше количество остовных деревьев графа (проще его структура), тем больше объем соответствующего ему симплекса.

Элементы лапласиана

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

Приведем вид лапласиана для нашего примера:

$$

Здесь проводимость (вес связи) между узлами A и B равна 16/144, между узлами A и C 9/144, а между узлами B и C связи вообще нет.

Теперь посмотрим на лапласиан симплекса. Каждой вершине симплекса можно сопоставить соответствующую противоположную грань. Под противоположной понимается грань симплекса, которая не касается заданного узла. Очевидно, что в общем случае такая грань является n-мерной. В нашем треугольнике — это сторона (отрезок), противоположная вершине. В тетраэдре — треугольник. Опуская из заданной вершины перпендикуляр на противоположную грань, получаем высоту вершины симплекса. Значение высоты вершины $$ выражается через площадь грани $$, противоположной вершине, объем симплекса $$ и мерность его пространства $$:

$$

Здесь $$ — площадь грани, противоположной i-ой вершине симплекса. Элементы лапласиана симплекса можно теперь выразить через высоты вершин. Диагональные элементы лапласиана обратно пропорциональны высотам вершин:

$$

Чем больше высота вершины симплекса — тем меньше проводимость соответствующего узла графа. Недиагональные элементы пропорциональны косинусу угла между гранями симплекса $$:

$$

Прямой угол между гранями симплекса эквивалентен отсутствию связи между соответствующими узлами в графе.

Описанная сфера и связность графа

Радиус описанной сферы $$ является естественной характеристикой симплекса. Соответственно, данный параметр должен иметь отражение в инвариантах графа.

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

$$

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


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

Индекс симметричности

Еще один интересный параметр, которым можно характеризовать граф (и симплекс) — это индекс симметричности. Его можно также сформулировать в геометрической терминологии — отношение средней дистанции $$ симплекса к радиусу его сферы $$:

$$

где $$.

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

Индекс симметричности можно выразить через дистанцию от центроида симплекса до центра сферы $$:

$$

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

Пример расчета параметров

В заключение рассчитаем параметры популярного в Википедии графа.



Данный граф эквивалентен 6-вершинному симплексу в 5-мерном пространстве. Кружки с цифрами — это пронумерованные узлы графа. Силу связи между узлами (значение веса ребер) принимаем за единицу.

Геометрическая связность данного графа равна 1.663 — это средняя связность на один узел. Можно сравнить ее с максимальной (6.25) и минимальной (0.8) связностью для графа из 6 узлов. Индекс симметричности — 0.773.

Вектор удаленности узлов (барицентрический вектор центра сферы): [0.364, 0.045, 0.273, -0.227, 0.045, 0.500]. Видим, что чем больше узел имеет связей, тем меньше значение его удаленности и наоборот. Интересно отрицательное значение удаленности 4-го узла. Это единственной узел графа, при удалении которого граф распадается на две несвязанные компоненты. Возможно, что отрицательную удаленность имеют ключевые узлы графа.

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

Original source: habrahabr.ru (comments, light).

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

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

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

Как выяснилось на генераторе установлен контроллер, который поддерживает протокол обмена Modbus RTU, это значит, что можно проложить кабель витую пару и подключиться по RS-485.
После изучения адресной таблицы, решили сами сделать простенькую программу.
В результате получилась ScadaPy.

Modbus TCP

Интерфейс обмена. Сперва подключаем modbus библиотеку.

import modbus_tk
import modbus_tk.defines as cst
import modbus_tk.modbus_tcp as modbus_tcp

Создаем ссылку на объект куда подключаемся и указываем:

host=«IP адрес устройства, с которым устанавливаем связь»
port=«порт устройства, к которому подключаемся»

master = modbus_tcp.TcpMaster(host=slaveIP, port=int(slavePort))
master.set_timeout(1.0)

Теперь пробуем получить данные от устройства, в данном случае начиная с адреса регистра 0, получаем 10 регистров дискретных сигналов (ТС).

getDI=master.execute(1, cst.READ_DISCRETE_INPUTS, 0, 10)

Для других видов регистров необходимо указать другие наименования.

master.execute(1,сst.READ_COILS, 0, 10) 
master.execute(1,cst.READ_INPUT_REGISTERS, 100, 3) 
master.execute(1,cst.READ_HOLDING_REGISTERS, 100, 12)

Теперь если сделать:

print getDi

Мы получим массив данных от устройства с адреса 0 по адрес 9.

(0,1,0,1,0,0,0,0,0)

Если что-то подобное появится, то значит устройство на связи. Получение данных от других видов регистров происходит аналогично.

Формирование окна программы

Подключаем библиотеку.

from Tkinter import *

Создаем ссылку на объект (окно).

root = Tk()

Устанавливаем картинку фона окна.

im = PhotoImage(file=backGroundPath) 

Создаем объект canvas.

canv = Canvas(root,width=1900,height=950,bg="black",bd=0, highlightthickness=0, relief='ridge')

Помещаем в окне.

canv.place(x=0, y=25)

Выводим фон.

canv.create_image(1, 1,anchor=NW, image=im)

Запускаем цикл.

root.mainloop()

Функция опроса

Для того, чтобы осуществлять постоянный опрос устройств по протоколу modbusTCP в tkinter существуют методы after и mainloop, но сначала необходимо создать процедуру jobModbusTCP.

def jobModbusTCP():
    getDI=master.execute(1, cst.READ_DISCRETE_INPUTS, 0, 10)
    if(int(getDI[0]) == 1): 
        canv.itemconfig(diFig1,fill='red') 
    if(int(getDI[0]) == 0): 
        canv.itemconfig(diFig1,fill='green') 
    if(int(getDI[1]) == 1): 
        canv.itemconfig(diFig2,fill='red') 
    if(int(getDI[1]) == 0): 
        canv.itemconfig(diFig2,fill='green') 
    root.after(1000, jobModbusTCP) 

Код программы

Ниже приведен код программы, который отображает состояние регистров [0] и [1], если логическое состояние регистра равно 0 квадрат на canvas будет зеленого цвета, если логическое состояние равно 1 — красного.

from Tkinter import * 
import modbus_tk
import modbus_tk.defines as cst
import modbus_tk.modbus_tcp as modbus_tcp
import math 
def jobModbusTCP():
    getDI=master.execute(1, cst.READ_DISCRETE_INPUTS, 0, 10)

    if(int(getDI[0]) == 1): 
        canv.itemconfig(diFig1,fill='red') 
    if(int(getDI[0]) == 0): 
        canv.itemconfig(diFig1,fill='green') 
    if(int(getDI[1]) == 1): 
        canv.itemconfig(diFig2,fill='red') 
    if(int(getDI[1]) == 0): 
        canv.itemconfig(diFig2,fill='green') 
    root.after(1000, jobModbusTCP)


master = modbus_tcp.TcpMaster(host='192.168.0.1', port=502)
master.set_timeout(1.0)

root = Tk() 
im = PhotoImage(file='bg.gif') 
canv = Canvas(root,width=1900,height=950,bg="black",bd=0, highlightthickness=0, relief='ridge')
canv.place(x=0, y=25) 
canv.create_image(1, 1,anchor=NW, image=im) 
diFig1=canv.create_rectangle(10,10,30,30,fill='gray', outline='black')
diFig2=canv.create_oval(50,50,80,80,fill='gray', outline='black')
root.after(1, jobModbusTCP)
root.mainloop()

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

Больше примеров можно посмотреть здесь.

Original source: habrahabr.ru (comments, light).

Полезные лайфхаки: отвечаем на самые популярные вопросы (Часть 2)

Что ж, долгожданное продолжение статьи habrahabr.ru/company/huawei/blog/313156 о полезных инструментах, которые призваны помочь пользователям оборудования Huawei, наконец увидело свет. В прошлой статье было рассказано о ряде полезных офлайн-инструментов, в этот раз большая часть материала будет посвящена онлайн-помощникам на сайте Huawei.

Онлайн-лайфхак номер один: конфигуратор Huawei

У любого производителя есть инструмент для создания спецификаций оборудования, в случае Huawei этот инструмент называется Unistar SCT и представляет собой функциональный web-конфигуратор, позволяющий не только готовить простые квотации, но и вести полный цикл работ по комплексным проектам с гибкими возможностями по объединению/ разделению спецификаций, передаче спецификаций коллегам и менеджерам Huawei на проверку, выгрузке в различных форматах, отправке заказов дистрибьюторам и выполнять многие другие задачи. Основная часть этого функционала доступно партнерам компании, однако и в гостевом режиме им можно пользоваться для создания простейших конфигураций оборудования.
huawei.com/sct — ссылка на конфигуратор


Рисунок 1. Страница входа Unistar SCT

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


Рисунок 2. Пример отображения одного из продуктов — CE12808S

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


Рисунок 3. Окно создания конфигурации и отображаемых подсказок

После окончания конфигурации полученную спецификацию можно выгрузить в виде таблицы Excel и посмотреть оценочные массогабаритные характеристики и энергопотребление.
В полнофункциональном режиме для партнеров доступно множество дополнительных опций. Среди них — создание мультипродуктовых спецификаций, одновременное редактирование нескольких однотипных продуктов. На случай, если для десятка сайтов вам нужно добавить по 2 трансивера и по стек-плате, это довольно сильно экономит время и параллельно позволяет сравнить конфигурации разных объектов. Еще один плюс полного функционала — более гибкие инструменты экспорта с различными группировками по регионам/ сайтам/ моделям (помимо выгрузки группировка по сайтам удобна для последующего размещения заказа, т.к. на производстве оборудование группируется по этому параметру и на каждой коробке/ в пакинг-листе можно найти данные об объекте предназначения). Это значительно облегчает сортировку оборудования на стадии доставки.

Онлайн-лайфхак номер два: кладезь инструментов

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

Для навигации по всему многообразию вспомогательных инструментов существует специальный раздел на сайте — Huawei Network Document Tools. Ниже описание наиболее популярных инструментов.


Рисунок 4. Пример навигатора по инструментам для коммутаторов

Нужно найти информацию по отдельным комплектующим, авариям, логам, командам, лицензиям для интересующего устройства? Тогда вам сюда — Info-Finder.


Рисунок 5. Пример выборки по поддерживаемым QSFP28-модулям для CE12800

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


Рисунок 6. Навигатор по протоколам


Рисунок 7. Пример информационной страницы по формату пакетов протокола BFD

Нужно понять, какое будет энергопотребление устройства с выбранными платами и как оно будет выглядеть в целевой комплектации? Незаменимым помощником станет Hardware Configuration Tool, который позволит выбрать компонент для каждого из доступных слотов и сгенерирует картинку внешнего вида устройства с выбранными платами. А заодно посчитает энергопотребление такого комплекта.


Рисунок 8. Пример работы Hardware Configuration Tool

Не знаете, какие фабрики коммутации выбрать для используемых в проекте интерфейсных карт? Оцените в пару кликов с Forwarding Performance Evaluation Tool! Просто выберите пункт «Интерфейсные карты» и получите рекомендацию, как конфигурировать фабрики коммутации. Если хотите скорректировать вручную – выберите желаемые фабрики и узнайте, будет ли при их использовании переподписка в работе выбранных интерфейсных модулей, и какая.


Рисунок 9. Пример работы Forwarding Performance Evaluation Tool

Нужно собрать стек коммутаторов, но есть сомнения, какие устройства могут работать друг с другом в стеке, какие порты и кабели необходимо использовать для стекирования? Тогда следующий компонент сэкономит вам массу времени – стек и SVF ассистент. Поможет быстро настроить стек из любых коммутаторов Huawei.

Рисунок 10. Стек-ассистент для модульных кампусных шасси.

Онлайн-лайфхак номер три: фото и 3D-модели

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

1. Network Product Image Portal – коллекция качественных фотографий продуктов Huawei

Рисунок 11. Внешний вид Network Product Image Portal

2. Network Product 3D Multimedia Portal – портал интерактивных 3D-моделей оборудования, где вы можете взаимодействовать с моделями сетевых устройств и посмотреть, как выглядят интерфейсные модули, в том числе с мобильных платформ. Попробуйте!

Онлайн-лайфхак номер четыре: просто полезные ссылки

Хотите просматривать анонсы EOS или уточнить, снято ли оборудование с производства? Официальная платформа таких анонсов расположена тут.
Не уверены, действует ли гарантия на оборудование или сервисный пакет? Просто введите серийный номер, используя «Поиск».

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

Автор: Владимир Горенышев, менеджер по продуктам и решениям сетей передачи данных Huawei Enterprise Business Group в России. Фото во вложении, так как оно не очень профессиональное и не очень высокого качества, прошу не делать его большим.

Original source: habrahabr.ru (comments, light).

26 октября 2017 года «Рэйдикс» и партнеры проведут очередной форум ПРОSTOR —технологическую конференцию по вопросам хранения и обработки данных. Первая конференция состоялась в Москве в 2015, в этому году ПРОSTOR пройдет в технопарке «Сколково». Ожидается насыщенная техническая программа и самый широкий диапазон участников – министр связи Н.А. Никифоров, эксперты из Broadcom, HGST (Western Digital), Mellanox, Panasonic, SanDisk (Western Digital), инновационные стартапы и многие другие.

Что такое ПРОSTOR?

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

В чем особенности?

Мы хотим немного заглянуть в будущее и определить ту самую Next Big Thing, о которой пишут западные евангелисты, но основываясь на реальном материале. На ПРОSTOR’е 2017 будет представлено как «железо» (накопители, средства сетевого соединения), так и подходы к организации хранения (кодирование, репликация).



Докладчики будут рассказывать о memory-centric архитектуре, NVDIMM, NVMe Over Fabrics, новых интерфейсах хранения, распределенных системах хранения данных и многом другом. На ПРОSTOR’е можно будет не только послушать интересные доклады, но и «пощупать» различные системы в рамках демозоны.

Для кого мероприятие будет полезным?

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



Аудиторию ПРОSTOR’а составляют системные интеграторы и сборщики оборудования, поставщики комплексных ИТ-решений, конечные корпоративные заказчики, медиагруппы, телеком-операторы, крупные исследовательские кластеры и все компании, заинтересованные в эффективном хранении данных.

Каждый найдет на ПРОSTOR’e что-то свое!

Как строится программа ПРОSTOR’а 2017

Поговорим о докладах, точнее, о тематических блоках, которые были выбраны для данного мероприятия.



В этом году программа будет разделена на пять треков:

1. Твердотельные накопители. Flash и память класса хранения. NVMe
2. Как хранить петабайты?
3. Сетевые решения. Fibre Channel vs. Ethernet, NVMf
4. Управление СХД в рамках ЦОД
5. Сравнение архитектур СХД.

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

Трек 1. Твердотельные накопители. Flash и память класса хранения. NVMe

Долгое время мы рассматривали полупроводниковую память как расширение системы хранения. В данный момент мы наблюдаем постепенный переход к новой парадигме, что неизбежно влечет за собой новый подход к хранению. Характерные черты этой новой парадигмы – Memory-Centric архитектуры, программно-определяемое хранение и программно-определяемая память, фокус на горизонтально-масштабируемых архитектурах, 3D NAND высокой плотности, новые форм-факторы, NVMe, «умные» хранилища и накопители.

Обо всем этом расскажут эксперты из SanDisk (Western Digital Brand), Micron и ScaleMP.

Трек 2. Как хранить петабайты?

Растущий объем мультимедийных данных увеличивает потребность в емкостях. Судя по отчетам IDC, объемы накопителей ежегодно растут на 40%. Где же предел увеличения объемов? Где обещанный HAMR (он же «термомагнитная запись»)? Жесткие диски, использующие эту технологию, должны были появиться на рынке в 2010—2013 годах, а воз и ныне там. Появятся ли SSD на 100ТБ, если да, то когда?

Эксперты из HGST (Western Digital Brand), Е8 и «Рэйдикс» проведут обзор новых накопителей, аппаратных и программных технологий для хранения петабайтов и экзабайтов данных в современных инфраструктурах.

Трек 3. Сетевые решения. Fibre Channel vs. Ethernet, NVMf

Про NVMf говорят все современные вендоры СХД. Бытует мнение, что существующие протоколы не смогут обслуживать СХД завтрашнего дня. Если мы переключаемся на новые протоколы, то где поддержка в мейнстриме? Где инициатор для MS Windows и VMware? Для памяти же необходим иной тип сетки!

О новых интерфейсах и технологиях соединения расскажут эксперты из Mellanox и Broadcom.

Трек 4. Управление СХД в рамках ЦОД

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

Обо всем этом расскажут специалисты из SNIA, Mellanox и «Рэйдикс».

Трек 5. Сравнение архитектур СХД

На Западе и в России основной тренд развития СХД – это создание архитектуры, которая позволит бизнесу быстро адаптироваться к росту числа сотрудников, клиентской базы и обрабатываемых данных. Ключевыми факторами в этом случае становятся высокая масштабируемость, оптимизация использования дискового пространства, обработка данных «на лету».



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

Драйвером индустрии становятся большие данные, которые используются не только мировыми корпорациями, но и в профессиональных отраслях, например, в медицине. Как хранить большие данные? Устоит ли классическая блочная СХД или не выдержит испытания Big Data?

Свое мнение по этим вопросам выскажут эксперты из Elastifile и Doc+.

Как попасть на мероприятие?

Участие в мероприятие бесплатное по предварительной регистрации для профильных специалистов. Заполните форму на сайте http://prostor.raidix.ru/, и мы рассмотрим вашу заявку!

Original source: habrahabr.ru (comments, light).

Класс 3D-модели

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


Не будем тянуть кота за хвост – ознакомимся со структурой класса Model:

class Model 
{
    public:
        /*  Методы   */
        Model(char *path)
        {
            loadModel(path);
        }
        void Draw(Shader shader);	
    private:
        /*  Данные модели  */
        vector meshes;
        string directory;
        /*  Методы   */
        void loadModel(string path);
        void processNode(aiNode *node, const aiScene *scene);
        Mesh processMesh(aiMesh *mesh, const aiScene *scene);
        vector loadMaterialTextures(aiMaterial *mat, aiTextureType type, string typeName);
};

Как видно, класс содержит вектор объектов типа Mesh и требует указания пути к файлу модели в конструкторе. Загрузка и происходит непосредственно в конструкторе и использует вспомогательный метод loadModel. Все приватные методы ответственны за работу с какой-то частью процесса импорта данных Assimp и мы рассмотрим их подробнее чуть ниже.
Метод Draw тривиален: здесь осуществляется итерация по списку полигональных сеток и вызов их методов Draw.

void Draw(Shader shader)
{
    for(unsigned int i = 0; i < meshes.size(); i++)
        meshes[i].Draw(shader);
}

Импорт 3D модели в OpenGL

Для начала включим требуемые Assimp заголовочные файлы:

#include Importer.hpp>
#include scene.h>
#include postprocess.h>

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

Замечательное свойство API Assimp – его абстрагирование от частностей и технических деталей загрузки различных форматов. Вся загрузка идет в один вызов:

Assimp::Importer importer;
const aiScene *scene = importer.ReadFile(path, aiProcess_Triangulate | aiProcess_FlipUVs); 

Сначала создается экземпляр класса Importer, затем идет вызов ReadFile с параметрами пути к файлу модели и списком флагов для пост-обработки. Кроме простой загрузки данных API позволяет указать некоторые флаги, заставляющие Assimp проделать некоторую дополнительную обработку над импортируемыми данными. Установка aiProcess_Triangulate указывает, что при наличии в модели объектов, составленных не из треугольников, библиотека проведет преобразования таких объектов в сетку треугольников. Флаг aiProcess_FlipUVs активирует инверсию текстурных координат по оси oY там, где это необходимо (как вы узнали из урока по текстурированию — в OpenGL практически все изображения были перевернуты по оси oY, так что данный флаг помогает скорректировать все как надо). Есть еще несколько полезных опций:

• aiProcess_GenNormals: вычисляет нормали для вершин, если таковые отсутствуют в исходных данных;
• aiProcess_SplitLargeMeshes: разделяет большие полигональные сетки на меньшие, что полезно, если ваш рендер имеет ограничение на количество обрабатываемых величин;
• aiProcess_OptimizeMeshes: проводит обратное действие – пытается сшить множество сеток в одну большую для оптимизации количества вызовов на отрисовку.

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

Полный листинг метода loadModel:

void loadModel(string path)
{
    Assimp::Importer import;
    const aiScene *scene = import.ReadFile(path, aiProcess_Triangulate | aiProcess_FlipUVs);	
	
    if(!scene || scene->mFlags & AI_SCENE_FLAGS_INCOMPLETE || !scene->mRootNode) 
    {
        cout << "ERROR::ASSIMP::" << import.GetErrorString() << endl;
        return;
    }
    directory = path.substr(0, path.find_last_of('/'));

    processNode(scene->mRootNode, scene);
}  

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

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

Как вы помните, структура данных Assimp предполагает, что каждый узел хранит набор индексов полигональных сеток, которые фактически хранятся в объекте сцены. Соответственно, для каждого узла и его потомков мы должны совершить выборку данных полигональных сеток с использованием списка индексов сеток, хранящихся в узле. Листинг метода processNode приведен ниже:

void processNode(aiNode *node, const aiScene *scene)
{
    // обработать все полигональные сетки в узле(если есть)
    for(unsigned int i = 0; i < node->mNumMeshes; i++)
    {
        aiMesh *mesh = scene->mMeshes[node->mMeshes[i]]; 
        meshes.push_back(processMesh(mesh, scene));			
    }
    // выполнить ту же обработку и для каждого потомка узла
    for(unsigned int i = 0; i < node->mNumChildren; i++)
    {
        processNode(node->mChildren[i], scene);
    }
}  

В начале мы получаем указатель на объект полигональной сетки Assimp выборкой из массива mMeshes объекта сцены, используя индексы текущего узла. Далее объект aiMesh преобразуется с помощью метода processMesh в экземпляр нашего класса Mesh и сохраняется в списке meshes.

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

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

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

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

Преобразование Assimp в Mesh

Непосредственное преобразование объекта типа aiMesh в наш внутренний формат не слишком обременительно. Достаточно считать необходимые нам атрибуты объекта полигональной сетки и сохранить в объекте типа Mesh. Скелет метода processMesh приведен ниже:

Mesh processMesh(aiMesh *mesh, const aiScene *scene)
{
    vector vertices;
    vector indices;
    vector textures;

    for(unsigned int i = 0; i < mesh->mNumVertices; i++)
    {
        Vertex vertex;
        // обработка координат, нормалей и текстурных координат вершин
        ...
        vertices.push_back(vertex);
    }
    // орбаботка индексов
    ...
    // обработка материала
    if(mesh->mMaterialIndex >= 0)
    {
        ...
    }

    return Mesh(vertices, indices, textures);
}  

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

Получение вершинных данных тривиально: мы объявляем структуру Vertex, экземпляр которой мы добавляем в массив vertices на каждом шаге обработки. Цикл выполняется пока не кончатся хранимые данные вершин (определяется значением mesh->mNumVertices). В теле цикла мы заполняем поля структуры актуальными данными, например, для положения вершины:

glm::vec3 vector; 
vector.x = mesh->mVertices[i].x;
vector.y = mesh->mVertices[i].y;
vector.z = mesh->mVertices[i].z; 
vertex.Position = vector;

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

Массив положений вершин в Assimp назван просто mVertices, что несколько неинтуитивно.

Для нормалей процесс схож:

vector.x = mesh->mNormals[i].x;
vector.y = mesh->mNormals[i].y;
vector.z = mesh->mNormals[i].z;
vertex.Normal = vector;  

Уже догадались, как выглядит считывание текстурных координат? Не тут то было: в Assimp предполагается возможность вершины иметь до 8 наборов текстурных координат. У нас нет нужды в таком богатстве, достаточно получить данные первого набора. И, заодно, неплохо бы проверять – есть ли у рассматриваемой сетки текстурные координаты в принципе:

if(mesh->mTextureCoords[0]) // сетка обладает набором текстурных координат?
{
    glm::vec2 vec;
    vec.x = mesh->mTextureCoords[0][i].x; 
    vec.y = mesh->mTextureCoords[0][i].y;
    vertex.TexCoords = vec;
}
else
    vertex.TexCoords = glm::vec2(0.0f, 0.0f);  

Экземпляр структуры Vertex к этому моменту полностью укомплектован требуемыми атрибутами вершин и может быть отправлен на хранение в массив vertices. Данный процесс повторится по количеству вершин в полигональной сетке.

Индексы

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

for(unsigned int i = 0; i < mesh->mNumFaces; i++)
{
    aiFace face = mesh->mFaces[i];
    for(unsigned int j = 0; j < face.mNumIndices; j++)
        indices.push_back(face.mIndices[j]);
}  

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

Материал

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

if(mesh->mMaterialIndex >= 0)
{
    aiMaterial *material = scene->mMaterials[mesh->mMaterialIndex];
    vector diffuseMaps = loadMaterialTextures(material, 
                                        aiTextureType_DIFFUSE, "texture_diffuse");
    textures.insert(textures.end(), diffuseMaps.begin(), diffuseMaps.end());
    vector specularMaps = loadMaterialTextures(material, 
                                        aiTextureType_SPECULAR, "texture_specular");
    textures.insert(textures.end(), specularMaps.begin(), specularMaps.end());
}  

Сперва получим указатель на объект aiMaterial из массива mMaterials объекта всены. Далее, мы загружаем диффузные текстуры и/или текстуры зеркального блеска. Объект материала содержит массив путей к текстурам каждого типа. Каждый тип текстуры имеет собственный идентификатор с префиксом aiTextureType_. Вспомогательный метод loadMaterialTextures возвращает вектор объектов Texture, содержащий текстуры соответствующего типа, извлеченные из объекта материала. Данные этих векторов сохраняются в общем массиве textures объекта модели.

Сама функция loadMaterialTextures в цикле проходит по всем текстурам указанного типа, считывает пути к файлам, загружает и генерирует текстуры формата OpenGL, сохраняя нужную информацию в экземпляр структуры Texture:

vector loadMaterialTextures(aiMaterial *mat, aiTextureType type, string typeName)
{
    vector textures;
    for(unsigned int i = 0; i < mat->GetTextureCount(type); i++)
    {
        aiString str;
        mat->GetTexture(type, i, &str);
        Texture texture;
        texture.id = TextureFromFile(str.C_Str(), directory);
        texture.type = typeName;
        texture.path = str;
        textures.push_back(texture);
    }
    return textures;
}  

Сперва проверяется количество текстур с помощью вызова GetTextureCount, которой передается интересующий тип текстуры. Далее считывается путь к файлу текстуры с помощью метода GetTexture, возвращающего результат в виде строки типа aiString. Еще одна вспомогательная функция TextureFromFile осуществляет непосредственную загрузку файла и генерацию текстуры (используя библиотеку SOIL) с возвращением её идентификатора. Если вы не уверены в том, как конкретно должна выглядеть эта функция, то её полный текст можно подглядеть в полном коде программы, приведенном в конце статьи.

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

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

Ну вот, кажется, и все, что касается импорта модели, используя Assimp?

Значительная оптимизация

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

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

struct Texture {
    unsigned int id;
    string type;
    aiString path;  // храним путь к текстуре для нужд сравнения объектов текстур
};

Сам же список уже загруженных текстур оформим в виде вектора, объявленного как закрытая переменная класса Model:

vector textures_loaded; 

И в методе loadMaterialTextures будем искать вхождение пути загружаемой текстуры в этом векторе и при наличии копии – пропускать загрузку, подставляя в массив текстур текущей полигональной сетки идентификатор уже загруженной текстуры:

vector loadMaterialTextures(aiMaterial *mat, aiTextureType type, string typeName)
{
    vector textures;
    for(unsigned int i = 0; i < mat->GetTextureCount(type); i++)
    {
        aiString str;
        mat->GetTexture(type, i, &str);
        bool skip = false;
        for(unsigned int j = 0; j < textures_loaded.size(); j++)
        {
            if(std::strcmp(textures_loaded[j].path.C_Str(), str.C_Str()) == 0)
            {
                textures.push_back(textures_loaded[j]);
                skip = true; 
                break;
            }
        }
        if(!skip)
        {   // если текстура не была загружена – сделаем это
            Texture texture;
            texture.id = TextureFromFile(str.C_Str(), directory);
            texture.type = typeName;
            texture.path = str;
            textures.push_back(texture);
// занесем текстуру в список уже загруженных
            textures_loaded.push_back(texture);
        }
    }
    return textures;
}  

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

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

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

Контейнеры – долой!

Что ж, пора испытать в бою нашу систему, скормив ей самую настоящую модель, разработанную профессиональным 3D-художником, а не состряпанное сетевым Кулибиным на колене чудо-юдо (хотя признайте, те контейнеры были одними из самых прекрасных представителей кубов, которые вам доводилось видеть). Не желая стяжать всю славу в одиночку здесь я обращусь к чужому творчеству: подопытной будет модель нанотехнологичного костюма из шутера Crysis от Crytek (в данном случае — скачанная с tf3dm.com, сгодится и любая другая модель). Модель подготовлена в виде .obj файла и вспомогательного .mtl, который содержит данные о диффузных, зеркальных текстурах и картах нормалей). Можете скачать модельку здесь (немного модифицированную). Напомню также, что все текстуры должны лежать в папке с моделью.

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

В коде мы объявляем экземпляр Model и передаем путь к файлу модели в конструктор. При успешной загрузке модель будет выведена на экран с помощью вызова ее метода Draw в основном цикле программы. Собственно, все! Никакой мороки с выделением буферов, назначением указателей на вершинные атрибуты и вызов отрисовки через процедуры OpenGL – теперь достаточно одной строчки. Остается только создать простой комплект шейдеров, где фрагментный будет выдавать только цвет диффузной текстуры модели. Результат будет примерно таким:



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



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

Прим. пер. — извиняюсь за ссылку на оригинал, прогнанную через ук(о)ротитель ссылок. Хабропарсер отказался признавать в изначальном URL нормальную ссылку.

Original source: habrahabr.ru (comments, light).

Толчок к написанию статьи. Давайте растопим лед

Август 2017. И вот опять из окна иллюминатора виднеется эта бескрайняя, кажущаяся непреодолимой и опасной, но в то же время загадочной и волнующей, пустыня Австралии.
Хочу заметить, что мой полет проходит не через одну, а через несколько пустынь Австралии, а также и через Алис-Спрингс — центр региона Центральная Австралия, который почти равно удалён от городов Аделаида на юге и Дарвин на севере. Вообще земля Австралии меня увлекает, и наверное, я могла бы еще Вам много чего рассказать, но это тема уже совершенно другой статьи.

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

В этот раз я держу путь в Сидней.

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

Мы еще встретимся с достойными примерами, дополняющие перечисленные, они ждут Вас в продолжении этой статьи.

А пока представлюсь и немножко расскажу о себе.

Уже 3 года я живу и работаю в международной компании Mindvalley, которая базируется в столице Малайзии, Куала-Лумпур, имеет филиал в Эстонии, Таллин, однако зарегистрирована в Америке, Невада. Моя профессиональная область исследования — это UX/UI .

Я нахожусь на позиции Senior UX/UI Designer и Front-end разработчик.

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

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

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

Вот и я повстречалась на конференции с большим количеством экспертов в области UX/UI со всех уголков мира. В их числе руководитель и пара проектировщиков из отдела по проведению UX исследований компании Google в Сиднее, контент менеджеры и специалисты из команды Instagram и Facebook, XD стратег/автор статей на тему юзабилити/заслуженный спикер из Далласа, США, CX/UX специалист из Мельбурна (очень понравилась ее конференция по работе над улучшением UX окружающей физической среды, улиц, ж/д вокзала и метро), UX специалист по визуализации данных и статистики из Канзаса, США и много много еще других талантливых специалистов.

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

Лекции проводились в нескольких залах и хотелось успеть посетить все! Только и перелетала из одной аудитории в другую.



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

И вот, что получилось:

Виза: 500 RM/ 150AUD / 120 USD
Биометрические данные: 121 RM / 37 AUD / 30 USD
Авиабилет: 1600 RM / 473 AUD / 375 USD
Проживание: 1060 RM / 314 AUD / 250 USD
Питание:150 +AUD / 120 + USD
Конференция: (студенческая цена) 1200 MYR / 350 AUD / 280 USD
Практический мастеркласс: 2030 MYR / 600 AUD / 480 USD

В Итоге: нужно рассчитывать на инвестиции в сумме 1700 — 2000 USD как минимум.

Ну а лучше попросить Вашего босса профинансировать данное мероприятие.

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

Пришло время начать.

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

Вуаля, мистер UX

Многие ошибочно думают, что UX/UI — это новое направление, внезапно появившееся в списках самых востребованных вакансий на волне развития новых IT технологий.

Эта деятельность действительно набирает обороты в настоящее время. Все больше компаний и стартапов нанимают в штат проектировщиков интерфейсов и UX дизайнеров/разработчиков.

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

Почему же вокруг данного направления столько альтернативных определений?
А все потому, что UX или опыт пользовательского взаимодействия — это некий многогранник, включающий в себя одновременно множество дисциплин: это психология и анализ, сконцентрированные на изучении поведения пользователя; это и информационная архитектура; методы/техники исследования и проведения юзабилити тестов, направленных на решение какой-либо проблемы и повышения степени удобства, легкости и дружелюбия процесса взаимодействия с экраном digital/цифрового продукта или напрямую с физическим продуктом, пространством или услугой; это поиск, исследование и нахождение целевой пользовательской аудитории; подбор и ведение участников (респондентов) тестирования; визуальный дизайн; контекстуальный дизайн; создание контента и его стратегия; графический дизайн; прототипирование (wireframing and prototyping); аналитика и построение бизнес процессов; проектировка и программирование; интерактивный дизайн; составление customer journey maps (CJM) карт путешествия потребителя и далее, далее в глубь.

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

И все же, все еще остаются вопросы:

• Почему же UX вбирает в себя столько ресурсов, времени и внимания?
• Как и откуда появилось данное направление, что оно привносит в жизнь, какова его польза?
• И все-таки, какова причина того, что данный термин зазвучал лишь 5-7 лет назад, а то и меньше, получив популярность с появлением и разработкой именно цифровых технологий и продуктов?

UX на языке метафор — моя интерпретация

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



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

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

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

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

Все легко,
Сцена — это площадка, лаборатория, шахматная доска с фигурками, отражение нашей реальности;
Герои — это персонажы (персоны с их мотивами поведения, целями и поступками);
В свою очередь Действия и перипетия на сцене — это user stores, user journeys (истории наших персонажей или даже конкретный список их последовательных шагов (сценарий возможных действий);
Сценарий всей картины — это список потоков (flows);
Чувство гладкости и дружелюбия самого процесса — это так называемое юзабилити и так далее.

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

UX преследует повсюду! Поговорим о UX в контексте ежедневной жизненной рутины

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

Очень часто приходится встречаться с ситуациями и обстоятельствами в жизни, в которых на собственном опыте чувствуешь и понимаешь промахи и недоработки в UX. Часто проектировщики не учитывают и не просматривают все возможные варианты, разнообразие и разнотипность пользователей, которые будут взаимодействовать с объектом (продукт/услуга/окружение) в рамках этого UX. Многие компании вообще не заморачиваются по этому поводу.
Но, как говорится, какая причина, такое и следствие! В таких ситуациях я люблю использовать понятие «SUX» — SOME User Experience — это UX, не учитывающий всего спектра пользователей, с их набором обстоятельств, личных возможностей и ограничений.
Отмечу, что это довольно серьезная проблема и, довольно часто встречаемая, когда опыт пользовательского взаимодействия не только что не продумывается соответствующим образом даже для рядового (обычного) пользователя, но и, как часто бывает, вообще не берет во внимание людей с ограниченными возможностями. И это нужно проговаривать обязательно во время процесса проектировки!

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

Вечер

Представьте, что аккумулятор Вашего автомобиля за ночь разрядился, только потому, что вечером после работы, во время парковки, Ваш ребенок на заднем сиденье отвлек внимание и сказал, что на следующий день занятия в школе отменены по определенной причине. Так как Вы опоздали в школу из-за ситуации в метро (недоразумения, о котором расскажу ниже), данная новость стала известна только сейчас и от ребенка, а не от преподавателя. Ну а причина вообще осталась скрыта “за семью замками”, так как ребенок не был внимательным и главное, что он уловил — это то, что завтра не надо в школу. Ура! Вы, понимая, что с ребенком кто-то должен завтра посидеть, незамедлительно набираете бабушку, чтобы поскорей с ней договориться. Ребенок в это время теряет свой телефон в машине и включает свет в салоне. Вы не обращаете внимание, заняты разговором. Ребенок находит телефон и забывает отключить свет. А освещение в салоне не предусмотрено к автоматическому отключению через определенный промежуток времени, также нет звука, дающего Вам понять, что что-то не до конца выключено. После удачной парковки, Вы выходите из машины, тут же звонит Ваша жена и просит купить молока и хлеба. Ребенок отвлекает и балуется рядом. Перед тем, как выйти, Вы выключаете ближний свет и поворачиваете ключи, вытаскиваете их из зажигания, но как оказалось, не доворачиваете до конца механический элемент отвечающий за свет фар, так как переключатель не предусмотрен таким образом, чтобы понять, что Вы действительно повернули в положение off (выключено). Вы же довернули до состояния, когда светят габаритные огни. Из-за яркого света на парковке свет габаритов уже не заметен явным образом. Вы закрываете машину и бежите скорее в магазин, все еще общаясь по телефону. Внутренний свет остался включенным. За ночь батарея села.

Под конец рабочего дня, после работы

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

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

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

Как обычно, дежурного рядом не оказывается в нужный момент, и Вам приходится возвращаться к месту, где все покупают билеты, чтобы убедится, что баланс положительный и с картой все в порядке. Вы теряете время, ждете в очереди, психуете. Ведь Вы опаздываете за ребенком в школу. И вот дождавшись Вашей очереди, Вы убеждаетесь, что все так как и предполагалось, карта рабочая, бюджет достаточный. Вы возвращаетесь, пробуете и опять. Уже переходите в стадию отчаяния и тут видите дежурного, который тоже замечает Ваше недовольство по выражению лица. Он объясняет что Вы делаете не так и находит решение проблемы очень быстро, оказывается Вам нужно держать карту немного дольше, чем у обыкновенного турникета — более 5 секунд. К сожалению, эта информация нигде не фигурирует за неимением продуманного UX. И это факт.

На работе

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

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

Утро

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

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

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

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

Экскурс в историю UX. Разгоним туман

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

Можно вспомнить предложение Дмитрия Менделеева, датированное еще 1863 годом, когда он предложил на бакинских нефтяных приисках доставлять нефть от мест добычи до морского порта не в бочках, а по трубам. Это первые идеи трубопроводного транспорта. Предложение Менделеева не было принято, а спустя два года первый трубопровод построили американцы в Пенсильвании. Как всегда, когда что-то делается за границей, это начинают делать и в России. Или по крайней мере выделять деньги. В итоге Шухов в 1878 году построил первый в России нефтепровод, доказав удобство и практичность трубопроводного транспорта. 

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

Этот знаменитый в историй, так называемый “универсальный человек” взялся за работу и разработал конвейерные ленты для транспортировки продуктов питания к поварам. Данный случай считается первым примером использования технологий (сотни лет до промышленной революции).

Однако уже здесь мы можем проследить первые отголоски современной проблемы проектирования и поиска лучшего, оптимального опыта взаимодействия с различными системами, дружественными к людям, которые непосредственно нуждаются в них.
С приходом промышленной революции, интерес привлекли исследования, направленные на процесс разработки инструментов производства для более эффективного их использования на предприятиях. И в 1857 году Войцех Ястшембовский придумал такой термин в науке как “Эргономика”. В то же время другие ученые изучали то, как люди думают, как происходит процесс познания, и то, что мотивирует людей.

Вильгельм Вундт основал первую лабораторию психологии в 1879 году.

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

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

Ведь только в 1990-х годах Дон Норман популяризировал термин «пользовательский опыт», работая в Apple, до этого такие компании, как Xerox проводили официальные исследования по взаимодействию компьютера и человека. А в 1995 году Якоб Нильсен написал свои знаменитые 10 практических правил  юзабилити, которыми все пользуются до сих пор.

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

Методы, подходы и основные принципы в проведении исследований — UX проектирование

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

Любое исследование имеет смысл если оно:
— истинно/обосновано/вещественно
— надежно
— результативно

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

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

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

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



График 1: Можно отметить явное расхождение и несогласованность при сборе данных. Каждый раз значения разнятся и не совпадают. Нельзя сделать однозначный вывод или заключение из полученных результатов.

График 2: Все еще видна большая хаотичность, однако уже начинает вырисовываться постепенная собранность результатов в главном центре. Сбор и измерение данных идет в правильном направлении, но все же нет даже 80% вероятности в качестве данных и их правильного сбора, поэтому и нет требуемой согласованности в значениях.

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

График 4: 100% вероятность успеха в подходе к исследованию, выбран подходящий метод исследования и верные данные взяты в ходе измерений.

Конечно же мы все хорошо понимаем, что еще далеко не все компании, по-настоящему, готовы к серьезным инвестициям и временным затратам на проведение качественных исследований по проектированию опыта пользовательского взаимодействия. Везде на все есть свои deadlines/сроки. А исследования — это процесс продолжительный, всегда есть место новым открытиям, предположениям, инновациям и усовершенствованию прежде существующего. Даже в самых продвинутых компаниях не всегда достаточно времени на долгосрочные исследовательские работы. Однако, могу также заметить и большой положительный скачок в этом направлении за последнее время. Вырисовывается все большее стремление среди предпринимателей и владельцев бизнеса к развитию продукта в равномерном темпе и стратегическом порядке, вместо быстрых и необдуманных прыжков «на авось» со своим количеством проб и ошибок. И это радует. Именно поэтому UX площадка завоевывает все больше внимания и открывает новые темы для дискуссий, воспитывая хороший тон в разработке, развитии новых востребованных продуктов и технологий.

Исследуем с толком!

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

1. Установка целей и вопросов исследования

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

Обрисовать проблему: В чем суть проблемы, на что необходимо обратить внимание?

Заинтересованные лица: Кто является инвестором исследования, лица, вовлеченные в процесс?

Основная цель: Проговариваем задачи и цели исследования, выстраиваем приоритеты.

Формируем вопросы: Составляем список актуальных вопросов. На какие специфические вопросы должны найтись ответы в ходе исследования?

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

Пример 1:
Цель — Определить как люди используют их электронные планшеты в настоящее время?

Список вопросов к исследованию по планшетам :

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

Пример 2:
Цель — Определить насколько удобен в использовании файловый менеджер в Google Drive?

Список вопросов к исследованию по файловому менеджеру:

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

Обратим внимание на типы вопросов, относящихся к usability/юзабилити:
Если стоит задача узнать насколько удобен тот или иной продукт, его практичность и пользовательская характеристика, то обращаются к списку специфических вопросов.
Эти вопросы имеют универсальный характер, главная их задача — рассмотреть реакцию пользователя при взаимодействии с продуктом и выявить его слабые стороны, устранить недостатки. Ведь удобство в использовании позволяет ускорить взаимодействие пользователя с продуктом и экономить драгоценное время.

Рассмотрим эти вопросы (к пользователю) повнимательнее:

• Они вообще понимают как это работает? [Восприятие и понимание продукта/услуги/окружения]

• Могут ли они найти это, какова вероятность? [Осведомленность, очевидность того или иного элемента продукта]

• Будут ли они оперировать с этим (элемент, функция), насколько очевидно, как могут воспользоваться? [Выполнение поставленной задачи]

• Как им это нравится, довольны ли, удовлетворены ли все мотивы? [Удовлетворенность пользователя, чувства после взаимодействия с продуктом]

• Насколько это полезно, лояльность пользователей? [Полезность, практичность, потребность и необходимость в использовании]

Буквально еще один пример и двигаемся дальше.

Пример 2:
Цель — Определить способы передвижения людей в окрестностях города Красноярска и установить какие устройства/инструменты/приложения чаще всего используются при этом?

Список вопросов к исследованию логистики перемещения в городе Красноярск (моем родном городе):

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

2. Детальное изучение сферы к которой обращено наше исследование. Обзор прошлых актуальных наработок в этом же направлении

В этот шаг входят следующие действия:

• Обзор и анализ похожих по смыслу старых и новых проектов/продуктов, имеющих прямое отношение к интересующей нас теме
• Чтение литературы, относящейся к области исследования
• Поиск возможностей повседневного общения с целевой пользовательской аудиторией
• Оперирование технологиями и инструментами актуальными нашей специфике исследования на своем собственном опыте
• Обзор демографической и технологической статистики предполагаемой целевой аудитории, например, немаловажным является определение таких данных, как возраст, стиль жизни, используемые тех. платформы, операционные системы и прочие предпочтения, уровень компьютерной грамотности, собственником какого устройства является и т.д. (приведу примеры систем — источников вышеупомянутой информации: Gartner, Pew Internet, Statista, Gfk, Business Insider)

Приведу краткий пример:
Мужчина в возрасте 65+, зарабатывающий меньше чем $13 000 в год (около $1000 в месяц) имеет меньшую вероятность быть собственником iphone 7, чем человек в возрасте 45+, зарабатывающий $20 000 годовых. Этой информации конечно же недостаточно, чтобы утверждать об этом, однако кое-какие данные уже позволяют выстраивать те или иные предположения, что уже не мало.

— Литературный обзор. Поиск информации из текстов научных публикаций, библиотек, печатных изданий всех форматов(Google Scholar). Например, ресурс Google Scholar выполняет поиск не только по статьям, доступным онлайн, но и по статьям, доступным только в библиотеках или за деньги. «Научные» результаты поиска генерируются с использованием ссылок из «полнотекстовых журнальных статей, технических отчётов, препринтов, диссертаций, книг и других документов, в том числе выбранных веб-страниц, которые считаются научными.

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


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

3. Выбор подходящего(их) метода(ов) исследования

Существует 3 основных аспекта, на которые необходимо обратить внимание при подборе наиболее оптимального подхода к процессу исследования:

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

Выкладываем методы на плоскость!

Задача проектировщика — подобрать способы исследования, которые лучше всего подойдут для проекта.

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

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

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

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

Методология предпочтений/отношения и методология поведения в UX-исследованиях

Количественная и Качественная методологии в UX-исследованиях

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

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


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

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



Перед тем как дать подробное описание каждого из методов, приведенных выше, объединю их по группам…

1. Группа: Контекстное интервью и наблюдения
2. Группа: Понимание и отслеживание процесса использования
3. Группа: Удобство использования (Юзабилити) и оценка концепции
4. Группа: Измерение восприятия и отношения (когнитивные исследования)

Шкатулка с исследовательскими методами (поговорим подробно)

1. Контекстное интервью и наблюдения
   
   • Контекстное интервью
     
     
     
     
     Это очень эффективный способ получения информации от клиента, так как тот не догадывается о факте проведения исследования (опроса) и, находясь в естественной ситуации (в идеальном случае) получения услуги или после нее (например, во время произведения расчета за товар/услугу, в ходе примерки, во время процедуры или заполнения документов) готов открыто отвечать на вопросы.
     
     Однако, возможно также заранее назначить встречу с пользователем и время, чтобы взять у него интервью независимо от обстановки и обстоятельств. В таком случае нужно подготовить список вопросов и определить, какие критические данные необходимо запросить у пользователя (информация об устройстве, четкие ответы на специфические/узкоспециализированные вопросы), также продумать в какой форме их собрать (заметки, видео/аудио, фотографии) во время проведения интервью.
   • Контекстное наблюдение/мониторинг поведения и действий потенциальных пользователей, в неофициальной обстановке я люблю называть этот метод («заделаться под бабульку на лавочке»)
     
     
     
     
     Этот метод основан на наблюдении (без коммуникации с объектом изучения) за теми или иными событиями/действиями или поведением, связанными с конкретным человеком или группой людей. Данные могут быть собраны с использованием структурированных (предварительное определение пользовательского поведения/реакции и последующей их проверкой во время наблюдения) или неструктурированных (записывающих поведение/поступки/манеры по мере их возникновения/выявления), в дополнение к другим методам.
     
   • Феноменологический метод или Запрос полного контекста (ч/з интервью и наблюдения)
     
     
     
     
     Феноменологическое исследование объединяет в себе несколько методов, таких, как проведение интервью, чтение документов, просмотр видео, или посещение каких-то событий. Для понимания мотивации, вы полагаетесь на собственные взгляды участников.
     
     В основном это попытка объединить два процесса — наблюдение и интервью. Мы наблюдаем, что делает пользователь, просим его комментировать свои действия, задаем уточняющие вопросы и вместе с ним максимально подробно описываем его повседневность. Так метод реализуют на практике. Данные могут аккумулироваться разными способами и в разном формате (аудио и видео записи, заметки, фотографии, информация предоставленная участником эксперимента).
     
   
   
2. Понимание и отслеживание процесса использования
   
   • Ведение заметок/дневников/текстовых записей
     
     
     
     
     Испытуемым выдается инструмент (дневник/блокнот) для записи и описания аспектов их жизни, которые либо релевантны продукту/ресурсу, либо являются общими для большинства представителей его целевой аудитории. Запись и конспектирование проводится, как правило, в определенные промежутки времени. Хороший путь для сбора поведенческих данных.
     Дневники обычно используются для долгосрочных исследований и подходят для сбора только той информации, которую респонденты могут предоставить без затруднений.
     
   • Ведение дневников/фото-отчет
     
     
     
     
     Очень похоже на вышеупомянутый метод, но в данном варианте упор делается на визуальную информацию, картинки, фотографии.
   • Ведение дневников/видео-отчет
     
     
     
     
     Очень похоже на ведение текстовых и фото отчетов, но в данном варианте упор осуществляется на видеозапись. Большим плюсом этого метода является тот факт, что он позволяет собирать количественные данные с пользователей на удаленном расстоянии. Участники с легкостью могут записывать на видео все ответы на интересующие вопросы, легче собирать информацию о поведении пользователя и использовании им того или иного устройства.
   • Эмпирическая выборка (ESM)
     
     
     
     
     В то время, как ведение дневников и записей заставляют пользователя обращаться и описывать тот или иной случай/действие, которое произошло в прошлом, то ESM метод останавливает участника в заранее определенный промежуток времени (во время использования приложения, во время прибытия на место назначения, после регистрации на сайте и т.д.).
     
   • Автоматическое сохранение и анализ логов, компьютерное программирование
     
     
     
     
     В этом методе получение информации происходит при помощи обработки/анализа логов (файлов текстового формата или таблиц БД, в которые заносятся все необходимые данные о всех действиях пользователей).
     Данные в лог-файле представляют из себя довольно непонятную информацию для неподготовленного новичка, но для системных администраторов это вполне понятный и осмысленный текст, который может служить основанием для проведения каких-либо действий, исследований или даже уголовного преследования клиента (конечно, в случае, неправомерного акта, например, хакерского взлома, повлекшего за собой увод с сервера хранящейся там базы данных с данными банковских карт клиентов компании).
     
     Но при анализе файлов журнала событий (лог-файлов) системным и сетевым администраторам следует учитывать, что полученные данные все же не являются на 100% реальными, отклонение в них обычно составляет 5-10% в силу различных технических и технологических особенностей используемого оборудования и его настроек.
     
     Для получения сводных отчетов и статистики по лог-файлам используется специальное программное обеспечение, которое называется «Анализаторы лог-файлов».
   
   
3. Удобство использования (Юзабилити) и оценка концепции
   
   
   • Эвристическая методология/оценка экспертов
     Этот метод не акцентирует внимание на отношение к продукту с точки зрения конечных пользователей. Здесь в большей степени работа направлена на тщательный анализ продукта (конкурента), чтобы найти и выявить его достоинства и недостатки, слабые и сильные аспекты, опираясь на принципы дизайна взаимодействия в качестве руководящих принципов. Конкурентные обзоры также могут дать хорошее представление о существующих функциональных характеристиках и возможностях.
     
     Вспомним определение понятия «Эвристика». Под эвристикой понимают совокупность приемов и методов, облегчающих и упрощающих решение познавательных, конструктивных, практических задач. Эвристика связана с психологией, физиологией высшей нервной деятельности человека, кибернетикой. Как наука эвристика развивается на стыке философии, психологии, теории «искусств, интеллекта», структурной лингвистики, теории информации, математики и физики.
     Тут же приведем 10 эвристик Якоба Нильсена (Вы можете ознакомиться с ними более подробно позже):
     
     
     — Информированность о состоянии системы
     — Схожесть системы с реальным миром
     — Свобода действий
     — Единообразие и стандарты
     — Предотвращение ошибок
     — На виду, а не в памяти
     — Гибкость и эффективность
     — Эстетичный и минималистичный дизайн
     — Понимание проблем и их решение
     — Справочные материалы и документация
      
      
     
   • Когнитивный пошаговый процесс исследования
     
     
     Когнитивное пошаговое исследование — это быстрый способ получить обратную связь и начальные впечатления о пользовательских интерфейсах и правильности их навигационного потока непосредственно от экспертов области изучения.
   • Тестирование концепции
     
     
     Это метод, в котором акцент направлен на проведение концептуальных тестов с отобранным числом участников, чтобы определить, соответствует ли концепция потребностям пользователя или является ли она решением какой-либо проблемы. Данный метод позволяет проверить и удостовериться в правильном восприятии пользователем навигационного потока (реальной навигации по продукту в процессе тестирования пользовательских сценариев), а также убедиться в последовательности выполнения действий на пути решения поставленных задач, в правильной коммуникации главных целей и намерений, эффективном подходе к построению и стратегии информационной архитектуры.
   • Прототипирование итерациями с последующей оценкой
     
     
     
     
     Метод проектирования начинается с дизайна грубых прототипов или прототипов низкой четкости (набор скетчей на бумажках). Грубые прототипы используются на ранних стадиях проектирования, чтобы собрать начальные отзывы участников и правильно определить дизайн потоки.
     
     Прототипы высокой четкости, с хорошей детализацией обычно оцениваются на более поздних стадиях проектирования чтобы протестировать все уровни взаимодействия и довести прототип до «конечного продукта», тогда и происходит финальное тестирование всех интеракций пользователей с объектом.
   • Партизанское тестирование/UX-спецназ
     
     
     
     
     Обычно такой метод чаще всего проводится в кафе с постепенным вылавливанием участников интервью. Поэтому его еще называют «партизанское исследование в кафе». Участники, как бы, находятся на лету (бар, общественный транспорт). Это помогает получить более справедливую оценку без эффекта обучения респондента, то есть мы видим реальную реакцию на продукт в неподготовленной ситуации. Процесс обычно занимает не более 10 минут на участника и цена проведения не выходит за рамки.
     
     Партизанское исследование — это своего рода не смертельная формой партизанской тактики. Как известно, в партизанской войне малые мобильные силы сражаются с врагом, применяя тактику засад и скоротечных боев. Кого в данном случае считать «врагом», спросите вы? Вероятно, главными врагами вашей команды станут время, деньги и ресурсы; если у вас кончится что-то из этого, может оказаться, что вы создали инновационный, но нежизнеспособный цифровой продукт. Для заказчиков, не располагающих временем или бюджетом, традиционное исследование пользователей (например, этнографическое) занимает слишком много времени, а тестирование юзабилити просто не в состоянии показать, насколько хорошо предлагаемая ценность соответствует аудитории или предоставляют ли ключевые аспекты взаимодействия инновацию ценности. Здесь-то на помощь приходит партизанское исследование пользователей — эта экономичная и мобильная тактика должна помочь быстро получить ответы на необходимые вопросы.
   • Исследование в юзабилити-лабораториях
     
     
     
     
     Каждый из группы респондентов индивидуально или непосредственно в команде встречается с исследователем в специальной лаборатории, где выполняет ряд заданий по пользованию продуктом/сервисом, следуя определенному сценарию. Чаще всего участникам предоставляется возможность работать и тестировать прототип. Плюс заключается в том, что этот метод позволяет руководителю тестирования устанавливать и организовывать место/пространство. таким образом, каким это необходимо для более эффективного результата. Сюда входит установка видео-наблюдения, аудио записи и т.д.
     
   • Исследования на удаленном расстоянии
     
     
     
     
     Дистанционное исследование юзабилити, проводящееся при помощи программ для разделения экрана и совместного управления девайсом.
   • Немодерируемое исследование пользовательского опыта
     
     
     
     
     Группа обученных пользователей (панель), на девайсах которых установлены программы для видеозаписи и сбора данных, в голос высказывают свои мысли в процессе использования объекта исследования. Исследователь либо анализирует полученную от респондентов информацию, либо координирует их действия. Место проведения в любом удобном для пользователя месте.
   • Полевое исследование или исследование в реальном окружении, в естественных условиях, соответствующих предмету изучения
     
     
     
     
     Исследования проводятся в привычной для респондентов среде — в местах, где, скорее всего, будет использоваться тестируемый объект.
   • Сплит-тесты/AB
     
     
     
     
     Исследование эффективности различных вариантов дизайна, отличающихся друг от друга 1 параметром, основанное на анализе их воздействия на поведение случайных групп пользователей.
   
   
4. Измерение восприятия и отношения к объекту/продукту/устройству
   
   • Фокус-группы
     
     
     
     
     Группа из 3-12 респондентов выражает свое мнение по ряду определенных тем после выполнения заданий или в процессе обсуждения.
   • Опросы
     
     
     
     
     Пользователям предлагается пройти опрос в процессе интеракции с ресурсом.
     Участники отвечают на специально подготовленные вопросы. Опросы, как правило, помогают получить представление об отношении пользователя к ресурсу, осведомленности о его существовании, демографической статистике, менее затрагивая поведенческую сторону пользователя.
   • Анализ логов
     
     Мы уже ознакомились с этим методом выше, так как он также фигурирует в другой группе по отслеживанию процесса использования продукта. С помощью этого подхода можно мониторить и контролировать насколько быстро и легко пользователь срастается с продуктом и его внешней оболочкой.
   
   
5. Глубокое погружение в область изучения
   
   Это еще один интересный подход, который, как Вы уже догадались по названию, вынуждает организовывать серьезный тандем экспертов в той или иной области изучения, использовать более широкий спектр технологий и инструментов, собирать большее количество участников и выстраивать площадку с реалистичным окружением для проведения экспериментальных работ. Такой подход позволяет задействовать больше специалистов и требует серьезных ресурсов. Коммуницируя друг с другом, обмениваясь знаниями и полученным опытом, они способны выявлять существующие ограничения в том или ином аспекте, находить сильные и слабые стороны на ранних стадиях разработки, вносить корректировки в концепцию, давать эффективную оценку.
   

Давайте закругляться

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

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

4. Подбор и рекрутинг участников тестирования

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

Каждый испытуемый должен представлять ту или иную группу пользователей (подмножество).

О