Компания Nautilus Data Technologies в прошлом году практически закончила создание полноценного коммерческого дата-центра. В этом не было бы ничего особенного, если бы не одно «но» — дата-центр, по замыслу разработчиков, должен плавать. Причем не в каком-то специализированном водоеме, он будет в буквальном смысле слова бороздить просторы морей и океанов. Назвали этот дата-центр Eli M, его вместимость — вплоть до 800 стоек. По словам представителей компании, создавшей этот ЦОД, он будет использоваться для предоставления услуги колокейшн. Разработчики считают, что это один из наиболее сбалансированных в плане потребления ресурсов дата-центров в мире. Конечно, посреди океана он не сможет выполнять работу, для которой предназначен — ведь для этого нужно подключение к сетевой инфраструктуре. Но в порту крупного города, где есть вся необходимая инфраструктура — вполне. В первую очередь, такой ЦОД будет использоваться в регионах, где строительство полноценных ЦОД затруднено по разным причинам. Это может быть банальное отсутствие места для застройки или же слишком высокая цена земли. Развернуть полноценный плавучий ДЦ в любой точке мира можно будет всего за полгода, при условии наличия достаточного количества воды. Положительной стороной проекта является то, что для этого ДЦ не нужно строить отдельный трубопровод и подводить воду. Все работает прямо на месте: система набирает воду прямо из океана или моря и после самой грубой очистки использует ее для охлаждения оборудования. Использованная вода отправляется туда же, откуда была взята — в океан или море. Нагрев будет минимальным, по мнению специалистов, оценивавших проект, экосистеме региона такой ДЦ не повредит. Вот так выглядит основа для ЦОД нового типа Расчетная мощность дата-центра составляет примерно 8 МВт (при вместимости в 800 серверных стоек, о чем говорилось выше). Основой для него служит военная баржа, восстановленная на верфи. Срок службы ДЦ, при условии своевременной модернизации оборудования и инфраструктуры, может быть очень большим — десятки лет. Системы охлаждения размещаются под палубой, а сетевое оборудование и вся остальная периферия — на палубе, в специальной надстройке. В результате того, что воду не нужно будет качать откуда-то издалека, а затем еще и выводить, энергопотребление дата-центра тоже будет ниже, чем в стандартном ЦОД. Это возможно еще и благодаря созданию специализированной программной платформы, которая предназначена, в первую очередь, для плавучих ЦОД. Eli M — первый плавучий ЦОД, его можно назвать пилотным проектом. Если все пойдет хорошо, то в скором будущем будет выпущено на воду еще 9 таких «кораблей». 7 планируется использовать для предоставления услуг колокейшн, а три готовятся под нужды конкретных клиентов. Сейчас свою заинтересованность в работе с такими ЦОД выказали более 30 крупных клиентов, 20 уже подписали контракт с компанией. Запустить в работу Eli M планировалось еще в прошлом году, но работы несколько затянулись, поэтому функционировать ЦОД начнет уже в новом, 2017 году. Коллеги, мы, компания Kingservers, сейчас ищем ИТ-авторов для технических сайтов (не Хабрахабр и не Geektimes, сторонние русскоязычные и англоязычные ресурсы). Условие — человек, который пишет статью (она должна быть грамотной и технической), должен еще иметь и возможность опубликовать ее на таком ресурсе. Если вы — такой автор, пишите в личку.

При проектировании системы важно понять, каким угрозам эта система может подвергаться, и разработать соответствующие меры защиты при проектировании и построении её архитектуры. Особенно важно с самого начала учитывать требования безопасности при проектировании продукта. Если вы понимаете, каким образом злоумышленники могут скомпрометировать вашу систему, то это поможет еще до начала работы принять соответствующие меры по снижению рисков. Цикл статей «Безопасность в IoT» 1. Azure IoT Suite для тех, кто начинает с нуля. 2. Стратегия всесторонней защиты. 3. Архитектура системы безопасности. 4. Обеспечение безопасности развертывания IoT. В основе безопасности лежит моделирование рисков Задача моделирования рисков заключается в том, чтобы понять, как именно злоумышленники могли бы скомпрометировать систему, а затем — принять соответствующие меры для снижения риска. Благодаря моделированию рисков группа разработчиков может предусмотреть меры по снижению рисков ещё на этапе проектирования системы, а не после её развертывания. Это крайне важно, поскольку модернизация систем безопасности на бесконечном количестве устройств, работающих за пределами компании, технически неосуществима. К тому же такой подход чреват появлением ошибок и оставляет клиентов без защиты от всевозможных рисков. Разработчики активно трудятся над определением и документированием функциональных требований к системе, которые сделают взаимодействие пользователей с ней ещё удобнее и эффективнее. Тем не менее выявление неочевидных способов, которыми злоумышленники могли бы скомпрометировать систему, — гораздо более сложная задача. Моделирование рисков позволяет разработчикам понять, какие именно действия могут предпринять злоумышленники и с какой целью. В ходе этого структурированного процесса обсуждаются решения по проектированию системы безопасности, а также изменения, внесенные в проект на этапе реализации, которые могут повлиять на безопасность системы. Модель рисков — это просто документ. Однако он представляет собой идеальный способ обеспечивать непрерывную передачу знаний и сохранять наработанный опыт, чтобы дать новым специалистам возможность мгновенно сориентироваться в новой среде. И наконец, благодаря моделированию рисков вы сможете учитывать также и другие аспекты безопасности. Например, определить тот уровень безопасности, который вы готовы предоставить своим клиентам. Этот задокументированный уровень вкупе с моделью рисков предоставляет данные, которые требуются для тестирования вашего решения IoT. Время создания Моделирование рисков гарантирует ряд серьезных преимуществ, если выполнять его непосредственно на этапе проектирования. В процессе проектирования вы сможете вносить любые изменения, чтобы устранить угрозы. Устранение рисков еще на этапе проектирования — вот тот результат, к которому нужно стремиться. Это гораздо проще и эффективнее, чем впоследствии внедрять и тестировать меры по снижению рисков и постоянно поддерживать их актуальность, что не всегда возможно. Устранить риски на более позднем этапе, когда продукт уже почти готов, гораздо сложнее. Для этого потребуется больший объем работ, и придется пожертвовать определенными преимуществами. Моделирование рисков на ранних этапах позволяет этого избежать. Объекты для изучения Необходимо создать модель рисков для всего решения, уделив особое внимание следующим областям: Инструменты обеспечения безопасности и защиты конфиденциальности. Функции, работоспособность которых зависит от безопасности. Функции, которые на схеме соприкасаются с границей доверия. Как моделировать риски Моделирование рисков — такой же процесс, как и любой другой. Рекомендуется обрабатывать и проверять модель рисков, как и любой другой компонент решения. Разработчики активно трудятся над определением и документированием функциональных требований к системе, которые сделают взаимодействие пользователей с ней еще удобнее и эффективнее. Тем не менее выявление неочевидных способов, которыми злоумышленники могли бы скомпрометировать систему, — гораздо более сложная задача. Моделирование рисков позволяет разработчикам понять, какие именно действия могут предпринять злоумышленники и с какой целью. Ключевые этапы Процесс моделирования рисков состоит из четырех этапов: Моделирование приложения. Перечисление рисков. Снижение рисков. Проверка мер по снижению риска. Шаги моделирования При построении модели рисков следует помнить о трёх проверенных шагах: Создать схему на основе эталонной архитектуры. Начать поиск в ширину. Просмотреть результаты и постараться оценить систему в целом, не углубляясь пока в детали. Таким образом, вы сможете правильно выбрать направление для глубинного анализа. Управляйте процессом, но не позволяйте процессу управлять вами. Однако если вы обнаружили проблему на стадии моделирования и хотите её изучить — сделайте это. Не стоит скрупулезно следовать абсолютно всем рекомендациям. Основные угрозы Четыре ключевых элемента модели рисков: Процессы (веб-службы, службы Win32, управляющие программы *nix и так далее). Обратите внимание, что некоторые сложные объекты (например, полевые шлюзы и датчики) можно абстрактно воспринимать как процессы, если технически невозможно проанализировать подробно эти области. Хранилища данных (любое место, где хранятся данные, например, файл конфигурации или база данных). Поток данных (маршрут перемещения данных между другими элементами приложения). Внешние объекты (все объекты, которые взаимодействуют с системой, но не контролируются приложением, например, пользователи и спутниковые каналы). Все элементы на схеме архитектуры в той или иной степени подвержены различным угрозам. Мы используем следующее мнемоническое правило: STRIDE. Различные элементы на схеме приложения подвержены различным угрозам STRIDE: Процессы подвержены угрозам STRIDE. Потоки данных подвержены угрозам TID. Хранилища данных подвержены угрозам TID и иногда — угрозам R, если они представляют собой файлы журналов. Внешние объекты подвержены угрозам SRD. Безопасность в среде IoT Подключенные специализированные устройства содержат множество точек потенциального взаимодействия, которые необходимо учесть при разработке адекватной системы защиты цифрового доступа к этим устройствам. Термином «цифровой доступ» обозначаются все операции, выполняемые путем прямого взаимодействия с устройством, если безопасность обеспечивается с помощью физического контроля доступа. Например, можно поместить устройство в помещение, закрывающееся на замок. Хотя физический доступ нельзя запретить программными и аппаратными средствами, все равно можно принять определенные меры, чтобы предотвратить проникновение в систему путем физического доступа. При изучении различных механизмов взаимодействия мы должны в равной степени уделять внимание управлению устройством и данным на устройстве. Управление устройством можно понимать как любую информацию, которая предоставляется устройству любым участником обмена данными с целью повлиять на поведение устройства таким образом, чтобы изменить его состояние или состояние его среды. Данные на устройстве — это информация, которую создает само устройство и предоставляет другому участнику обмена данными. Это сведения о состоянии устройства и зарегистрированное состояние его среды. Чтобы обеспечить более высокий уровень безопасности, рекомендуется в рамках этого упражнения по моделированию рисков разделить стандартную архитектуру IoT на несколько компонентов (зон). К ним относятся: Устройство. Полевой шлюз. Облачные шлюзы. Службы. Разделение на зоны представляет собой универсальный способ сегментирования решения. Каждая из зон зачастую содержит собственные данные, а также предъявляет отдельные требования к проверке подлинности и авторизации. Разделение на зоны можно использовать, чтобы локализовать ущерб и ограничить влияние зон с низким доверием на зоны с более высоким доверием. Каждая зона отделяется границей доверия, которая на схеме внизу обозначена красным пунктиром. Она представляет переход данных (информации) из одного источника в другой. Во время такого перехода данные (информация) могут стать объектом подделки (S — Spoofing), незаконного изменения (T — Tampering), искажение смысла (R — Repudiation), раскрытия информации (I — Information Disclosure), отказа в обслуживании (D — Denial of Service) и повышения привилегий (E — Elevation of Privilege). Все эти угрозы в совокупности мы называем по первым буквам английских слов аббревиатурой «STRIDE». Компоненты, обозначенные в пределах каждой из границ, также подвержены угрозам STRIDE, что позволяет полностью, во всех деталях, смоделировать риски для конкретного решения. Разделы ниже описывают каждый из этих компонентов и конкретные проблемы безопасности, а также рекомендуемые решения. Зона устройства Среда устройства представляет собой физическое пространство, непосредственно окружающее устройство. В среде устройства осуществляется физический доступ к устройству и (или) одноранговый цифровой доступ по локальной сети. Локальная сеть — сеть, отделенная и обособленная от общедоступной сети Интернет (но с возможностью подключения к ней посредством мостового соединения). К таким сетям относятся беспроводные радиосети малого радиуса действия, посредством которых устанавливается одноранговое соединение между устройствами. К таким сетям не относятся ни виртуализованные сети, которые создают иллюзию локальной сети, ни общедоступные сети операторов, в рамках которых предполагается, что два устройства обмениваются данными в общедоступном сетевом пространстве для установки однорангового соединения. Зона полевого шлюза Полевой шлюз — это устройство, программное обеспечение или серверное программное обеспечение общего назначения, которое служит средством реализации обмена данными, а также, по возможности, системой управления устройствами и центром обработки данных, получаемых от устройств. В зону полевого шлюза входит сам полевой шлюз, а также все подключенные к нему устройства. Как явствует из названия, полевые шлюзы работают за пределами специализированных центров обработки данных. Обычно они ограничены местонахождением, могут стать объектом физического вторжения и обладают ограниченным запасом рабочей мощности. Таким образом, полевой шлюз представляет собой некое устройство, которое можно физически вывести из строя, если знать, какие функции оно выполняет. В отличие от простого маршрутизатора трафика, полевой шлюз играет важную роль в управлении доступом и потоковой обработке информации. То есть это объект, к которому обращается приложение, сетевое соединение или терминал сеанса. Устройство NAT и межсетевой экран, напротив, не являются полевым шлюзом, поскольку сами по себе не функционируют как терминалы соединения или сеанса, но являются соединениями или сеансами маршрута (блока). Полевой шлюз содержит две отдельные контактные зоны. Одна из них взаимодействует с подключенными устройствами (внутренняя часть), а вторая — с внешними участниками обмена данных, представляя собой по сути переход зоны. Зона облачного шлюза Облачный шлюз представляет собой систему для удалённого обмена данными между различными устройствами и полевыми шлюзами. Данные, как правило, поступают от различных сайтов в общедоступной сети в облачную систему анализа и контроля данных, являющейся федерацией таких систем. В ряде случаев облачный шлюз может предоставлять прямой доступ к специализированным устройствам с таких терминалов, как планшетные ПК и телефоны. В рамках этой статьи термином «облако» обозначается специализированная система обработки данных, которая не привязана к тому же сайту, что и подключенные устройства или полевые шлюзы. В зоне облака также можно реализовать оперативные меры по предотвращению намеренного физического доступа. Эта зона может не предоставляться в рамках инфраструктуры общедоступного облака. Облачный шлюз можно сопоставить с наложением виртуализации сети, чтобы изолировать облачный шлюз и все подключенные к нему устройства или полевые шлюзы от любого сетевого трафика. Сам по себе облачный шлюз не является ни системой управления устройством, ни системой обработки или хранения данных устройства, однако шлюз взаимодействует со всеми указанными системами. Зона облачного шлюза содержит сам облачный шлюз, а также все полевые шлюзы и устройства, которые напрямую или опосредованно подключены к нему. Переход зоны представляет собой четко обозначенную контактную зону, посредством которой осуществляется взаимодействие со всеми внешними участниками обмена данными. Зона служб Служба определяется в контексте этой статьи как любой программный компонент или модуль, который взаимодействует с устройствами посредством полевого или облачного шлюза, выполняя сбор и анализ данных, а также осуществляя контроль и отправку команд. Службы выполняют роль медиаторов. Используя собственное удостоверение, службы взаимодействуют со шлюзами и другими подсистемами, осуществляют хранение и анализ данных, автономную отправку команд на устройства с учетом оперативных данных или расписаний, а также предоставляют авторизованным конечным пользователям требуемую информацию и инструменты контроля. Сравнение информационных и специализированных устройств Компьютеры, телефоны и планшетные ПК в основном относятся к интерактивным информационным устройствам. Телефоны и планшетные ПК оптимизированы для максимально продолжительной автономной работы от аккумулятора. На таких устройствах возможно частичное отключение функций на тот период, пока пользователь не использует устройство для воспроизведения музыки, GPS-навигации и т. д. С точки зрения системы, такие информационные устройства выполняют роль прокси при взаимодействии с пользователями. Это «привод пользователя», если речь идет о действиях, и «датчик пользователя», если мы говорим о сборе входных данных. К специализированным относится множество различных устройств — от обычных температурных датчиков до сложнейших заводских производственных линий, состоящих из тысяч самых разных компонентов. Эти устройства ориентированы на более широкое применения. И даже если для них предусмотрен пользовательский интерфейс, они все равно выполняют широкий спектр функций взаимодействия или интеграции с ресурсами в физическом мире. Они анализируют состояние окружающей среды и создают соответствующие отчеты, включают и отключают клапаны, управляют серводвигателями, активируют звуковые оповещения, включают и отключают свет, а также выполняют еще массу различных задач. Они помогают выполнять ту работу, для которой спектр задач информационных устройств слишком универсален, либо такие устройства слишком дороги, имеют слишком большой размер или недостаточно прочны. Техническая конструкция устройства определяется непосредственно конкретной задачей, а также доступным бюджетом, выделенным для производства, и запланированным сроком эксплуатации. Сочетание этих двух факторов ограничивает бюджет, выделяемый на энергоснабжение в процессе эксплуатации. Ограничиваются также физическое воздействие и доступные ресурсы хранения, вычисления и безопасности. Если что-то случается с автоматизированными или удаленно управляемыми устройствами, например, физическая поломка или неполадки в логике управления, это может привести к преднамеренному несанкционированному вторжению и мошенническим действиям. Производственная партия может быть уничтожена, здание может быть ограблено или сожжено дотла, люди могут пострадать или даже погибнуть. Это, конечно, совершенно другая категория ущерба, которая значительно отличается от банального опустошения украденной кредитной карты. К устройствам, которые приводят в движение вещи и предметы, а также к данным датчиков, которые впоследствии преобразуются в команды, приводящие в движение различные вещи и предметы, должны предъявляться более высокие требования безопасности, чем к любым коммерческим или банковским системам. Управление устройством и взаимодействие с данными на устройстве Подключенные специализированные устройства содержат множество точек потенциального взаимодействия, которые необходимо учесть при разработке адекватной системы защиты цифрового доступа к этим устройствам. Термином «цифровой доступ» обозначаются все операции, выполняемые путем прямого взаимодействия с устройством, если безопасность обеспечивается с помощью физического контроля доступа. Например, можно поместить устройство в помещение, закрывающееся на замок. Хотя физический доступ нельзя запретить программными и аппаратными средствами, все равно можно принять определенные меры, чтобы предотвратить проникновение в систему путем физического доступа. При изучении различных механизмов взаимодействия мы должны в равной степени уделять внимание управлению устройством и данным на устройстве. Управление устройством можно понимать как любую информацию, которая предоставляется устройству любым участником обмена данными с целью повлиять на поведение устройства таким образом, чтобы изменить его состояние или состояние его среды. Данные на устройстве — это информация, которую создает само устройство и предоставляет другому участнику обмена данными. Это сведения о состоянии устройства и зарегистрированное состояние его среды. Эталонная архитектура Azure IoT: моделирование рисков Microsoft использует описанную выше концепцию для моделирования рисков в Azure IoT. В следующем разделе мы приведем конкретный пример эталонной архитектуры Azure IoT, чтобы продемонстрировать принципы моделирования рисков в среде IoT и устранить обнаруженные угрозы. В данном случае мы выделим четыре основных области: Устройства и источники данных. Транспортировка данных. Устройства и обработка событий. Представление. На следующей схеме упрощенно представлена референсная архитектура IoT от Microsoft. Для демонстрации мы используем модель схемы потока данных, которая также используется инструментом моделирования рисков Microsoft. Важно понимать, что в пределах архитектуры функциональные возможности устройства и шлюза отличаются. Таким образом, пользователь сможет эффективно использовать более надежные и безопасные шлюзы. Шлюзы поддерживают обмен данными с облачным шлюзом посредством защищенных протоколов; для этого обычно требуется больший объем обработки служебных данных, чем может предоставить собственное устройство (например, термостат). Предполагается, что в зоне служб Azure роль облачного шлюза выполняет служба Azure IoT Hub. Устройства и источники данных/транспортировка данных В этом разделе рассматривается описанная выше архитектура в контексте моделирования рисков, а также представлены решения различных сопутствующих проблем. Мы подробно рассмотрим ряд ключевых элементов модели рисков: Процессы (управляемые пользователем, а также внешние элементы). Обмен данными (так называемый поток данных). Хранение (так называемые хранилища данных). Процессы В каждой из категорий, выделенных в архитектуре Azure IoT, мы стараемся снизить различные риски на разных этапах существования данных (информации): процесс, обмен данными и хранение. Далее представлен обзор наиболее распространенных рисков для категории «процесс». Затем мы расскажем о том, как можно снизить эти риски. Подделка (Spoofing). Злоумышленник может извлечь из устройства материал криптографического ключа (на программном или аппаратном уровне) и получить доступ к системе с другого физического или виртуального устройства, используя удостоверение того устройства, из которого извлечен этот материал. Самым ярким примером можно считать пульт дистанционного управления, с помощью которого можно включить любой телевизор, — им часто пользуются любители розыгрышей. Отказ в обслуживании (Denial of Service). Устройство может быть выведено из строя или исключено из процесса передачи данных из-за радиопомех или простым перерезанием проводов. Например, камера системы видеонаблюдения, намеренно отключенная от питания и от сети, не будет передавать никаких данных Незаконное изменение (Tampering). Злоумышленник может полностью или частично заменить программное обеспечение, работающее на устройстве. При этом ПО, установленное вместо исходного, сможет использовать подлинное удостоверение устройства при наличии доступа к материалу ключа или криптографическим данным, содержащим материал ключа. Например, злоумышленник может использовать извлеченный материал ключа для перехвата и блокировки данных, поступающих от устройства по коммуникационному пути, и заменять их ложными данными, для которых выполняется проверка подлинности с использованием украденного материала ключа. Раскрытие информации (Information Disclosure). Если на устройстве установлено мошенническое ПО, это может стать причиной утечки данных и их передачи неавторизованным пользователям. Например, злоумышленник может использовать полученный материал ключа, чтобы проникнуть в коммуникационный путь между устройствами и контроллером или полевым/облачным шлюзом и начать вывод данных. Повышение привилегий (Elevation of Privilege). Устройство, выполняющее конкретную функцию, можно принудительно заставить выполнять какие-то другие действия. Например, клапан, запрограммированный на открытие на 180 градусов, можно нелегитимно настроить для полного открытия. Компонент Угроза Снижение рисков Риск Реализация Устройство Spoofing Назначение удостоверений и проверка подлинности устройств Полная или частичная замена устройства другим устройством Как определить легитимность устройства? Проверка подлинности устройства с использованием протоколов TLS или IPSec. Инфраструктура должна поддерживать использование общего ключа на тех устройствах, где обработка асимметричного шифрования не поддерживается. Использование Azure AD, OAuth TRID Можно применить на устройстве механизмы защиты от незаконного изменения, чтобы осложнить получение ключей и другого криптографического материала или сделать это полностью невозможным Однако существует риск физического незаконного изменения устройства. Каким образом можно защитить устройство от незаконного изменения? Самый эффективный способ снизить риск такой угрозы — использовать доверенный платформенный модуль, который позволяет хранить ключи в специальной встроенной микросхеме. Данные на такой схеме невозможно считать, однако их можно использовать для операций шифрования, которые задействуют ключ, не раскрывая его. Шифрование памяти устройства. Управление ключами на устройстве. Подписывание кода Elevation of Privilege Получение контроля за доступом к устройству. Схема авторизации Если для устройства разрешено выполнение отдельных действий в соответствии с командами, полученными из внешнего источника или даже от скомпрометированных датчиков, то это позволит злоумышленникам выполнять операции, которые в ином случае были бы недоступны Получение схемы авторизации для устройства Полевой шлюз Spoofing Проверка подлинности полевого шлюза при взаимодействии с облачным шлюзом (на основе сертификата, общего ключа, утверждения и так далее) Если злоумышленнику удастся незаконно изменить полевой шлюз, он сможет выдать себя за любое устройство TLS RSA/общий ключ, IPSe, RFC 4279. Рекомендации по хранению ключей и аттестации остаются теми же — в целях поддержки беспроводных сенсорных сетей (WSN) рекомендуется использовать расширение TPM. 6LowPAN для IPSec TRID Защитить полевой шлюз от незаконного изменения (доверенный платформенный модуль)? Атаки с применением подделки данных, в результате которых облачный шлюз ошибочно считает, что осуществляет обмен данными с полевым шлюзом, приводят к раскрытию информации и незаконному изменению данных Шифрование памяти, доверенные платформенные модули, проверка подлинности Elevation of Privilege Механизм управления доступом к полевому шлюзу Далее мы приведем несколько примеров угроз, относящихся к этой категории. Подделка. Злоумышленник может извлечь из устройства материал криптографического ключа (на программном или аппаратном уровне) и получить доступ к системе с другого физического или виртуального устройства, используя удостоверение того устройства, из которого извлечен этот материал. Отказ в обслуживании. Устройство может быть выведено из строя или исключено из процесса передачи данных из-за радиопомех или простым перерезанием проводов. Например, камера системы видеонаблюдения, намеренно отключенная от питания и от сети, не будет передавать никаких данных. Незаконное изменение. Злоумышленник может полностью или частично заменить программное обеспечение, работающее на устройстве. При этом ПО, установленное вместо исходного, сможет использовать подлинное удостоверение устройства при наличии доступа к материалу ключа или криптографическим данным, содержащим материал ключа. Незаконное изменение. Камера видеонаблюдения, которая транслирует в видимом спектре изображение пустого вестибюля, может на самом деле показывать просто статичную фотографию этого вестибюля. Датчик дыма или пожарный извещатель может сработать, если кто-то просто поднесет к нему зажженную спичку. В любом случае, устройство может быть физически полностью надежным, но при этом сообщать системе ложную информацию, отправленную мошенниками. Незаконное изменение. Например, злоумышленник может использовать извлеченный материал ключа для перехвата и блокировки данных, поступающих от устройства по коммуникационному пути, и заменять их ложными данными, для которых выполняется проверка подлинности с использованием украденного материала ключа. Незаконное изменение. Злоумышленник может полностью или частично заменить программное обеспечение, работающее на устройстве. При этом ПО, установленное вместо исходного, сможет использовать подлинное удостоверение устройства при наличии доступа к материалу ключа или криптографическим данным, содержащим материал ключа. Раскрытие информации. Если на устройстве установлено мошенническое ПО, это может стать причиной утечки данных и их передачи неавторизованным пользователям. Раскрытие информации. Например, злоумышленник может использовать извлеченный материал ключа, чтобы проникнуть в коммуникационный путь между устройствами и контроллером или полевым/облачным шлюзом и начать вывод данных. Отказ в обслуживании. Устройство можно выключить или перевести в режим, в котором обмен данными невозможен (это специально делается на многих производственных установках). Незаконное изменение. Конфигурацию устройства можно изменить, чтобы присвоить ему состояние, неизвестное системе управления (вне диапазона известных параметров калибровки). Таким образом, с устройства могут поступать данные, которые будут интерпретированы неверно. Повышение привилегий. Устройство, выполняющее конкретную функцию, можно принудительно заставить выполнять какие-то другие действия. Например, клапан, запрограммированный на открытие на 180 градусов, можно нелегитимно настроить для полного открытия. Отказ в обслуживании. Устройство можно перевести в состояние, при котором обмен данными невозможен. Незаконное изменение. Конфигурацию устройства можно изменить, чтобы присвоить ему состояние, неизвестное системе управления (вне диапазона известных параметров калибровки). Таким образом, с устройства могут поступать данные, которые будут интерпретированы неверно. Подделка/незаконное изменение/искажение смысла. Если устройство не защищено (например, для пультов дистанционного управления редко используется какая-либо защита), то злоумышленник сможет анонимно изменять состояние устройства. Самым ярким примером можно считать пульт дистанционного управления, с помощью которого можно включить любой телевизор — им часто пользуются любители розыгрышей. Обмен данными Угрозы, связанные с коммуникационным путем передачи данных между различными устройствами, между устройствами и полевыми шлюзами, а также между устройствами и облачным шлюзом. В следующей таблице представлены рекомендации по настройке открытых сокетов на устройстве/VPN. Компонент Угроза Снижение рисков Риск Реализация Служба IoT Hub на устройстве TID (D)TLS (общий ключ/RSA) для шифрования трафика Прослушивание или вмешательство в обмен данными между устройством и шлюзом Безопасность на уровне протокола. Если используются настраиваемые протоколы, то для них необходимо настроить оптимальный способ защиты. В большинстве случаев обмен данными осуществляется в направлении от устройства к службе IoT Hub (соединение инициируется устройством) Устройство // Устройство TID (D)TLS (общий ключ/RSA) для шифрования трафика Чтение данных в процессе передачи между устройствами. Незаконное изменение данных. Перегрузка устройства новыми соединениями Безопасность на уровне протокола (HTTP(S)/AMQP/MQTT/CoAP). Если используются настраиваемые протоколы, то для них необходимо настроить оптимальный способ защиты. Чтобы снизить риск DOS-атаки, можно настроить одноранговую связь для устройств, используя облачный или полевой шлюз, который сконфигурирован только как клиент в сети. В этом случае между одноранговыми устройствами может быть установлена прямая связь уже после шлюза, выступающего в роли посредника Устройство // Внешний объект TID Устойчивое связывание внешнего объекта с устройством Прослушивание соединения с устройством. Вмешательство в обмен данными с устройством Безопасное связывание внешнего объекта с устройством NFC/Bluetooth LE. Управление рабочей панелью устройства (физическое) Полевой шлюз // Облачный шлюз TID TLS (общий ключ/RSA) для шифрования трафика Прослушивание или вмешательство в обмен данными между устройством и шлюзом Безопасность на уровне протокола (HTTP(S)/AMQP/MQTT/CoAP). Если используются настраиваемые протоколы, то для них необходимо настроить оптимальный способ защиты Устройство // Облачный шлюз TID TLS (общий ключ/RSA) для шифрования трафика Прослушивание или вмешательство в обмен данными между устройством и шлюзом Безопасность на уровне протокола (HTTP(S)/AMQP/MQTT/CoAP). Если используются настраиваемые протоколы, то для них необходимо настроить оптимальный способ защиты Далее мы приведем несколько примеров угроз, относящихся к этой категории. Отказ в обслуживании. Устройства с ограничениями, как правило, подвержены риску DOS-атаки во время активного прослушивания входящих соединений или приема по сети незапрошенных датаграмм: злоумышленники могут создавать многочисленные параллельные соединения, не обслуживая их вовсе или обслуживая очень медленно. На устройство также может непрерывно отправляться огромный объем незапрошенного трафика. В обоих случаях устройство будет восприниматься сетью как нерабочее. Подделка, раскрытие информации. Устройства с ограничениями и специализированные устройства зачастую используют универсальные инструменты безопасности (например, защиту паролем или PIN-кодом) либо полностью полагаются на доверие к сети (то есть устройство предоставляет доступ к информации, если запрашивающее устройство находится в той же сети, причем сеть зачастую защищена только общим ключом). Иными словами, в момент раскрытия секретного ключа устройства или ключа сети можно перехватить управление устройством либо получить доступ к данным, отправленным с устройства. Подделка. Злоумышленники могут перехватывать и частично переопределять трансляцию данных, а также подделывать отправителя (посредника). Незаконное изменение. Злоумышленники могут перехватывать или частично переопределять трансляцию данных, а также отправлять ложную информацию. Раскрытие информации. Злоумышленники могут прослушивать трансляцию данных и получать информацию без надлежащей авторизации. Отказ в обслуживании. Злоумышленники могут препятствовать прохождению сигнала трансляции данных и блокировать рассылку информации. Хранение На всех устройствах и на полевом шлюзе предусмотрено хранилище (временное хранилище для создания очереди данных, хранения образа ОС). Компонент Угроза Снижение рисков Риск Реализация Хранилище на устройстве TRID Шифрование хранилища, подписывание журналов Чтение данных из хранилища (данные PII), незаконное изменение данных телеметрии. Незаконное изменение управляющих данных команд, помещенных в очередь или кеш. При незаконном изменении конфигурации или пакетов обновления встроенного ПО во время кеширования или помещения в локальную очередь компоненты ОС и (или) системы могут быть скомпрометированы Шифрование, код проверки подлинности сообщения (MAC) или цифровая подпись. По возможности рекомендуется строго контролировать доступ с помощью списков управления доступом (ACL) или разрешений Образ ОС устройства TRID Незаконное изменение ОС/замена компонентов ОС Раздел ОС со свойством «только чтение», подписанный образ ОС, шифрование Хранилище на полевом шлюзе (создание очереди данных TRID Шифрование хранилища, подписывание журналов Чтение данных из хранилища (данные PII), незаконное изменение данных телеметрии, незаконное изменений управляющих данных команд, помещенных в очередь или в кеш. При незаконном изменении конфигурации или пакетов обновления встроенного ПО (предназначенных для устройств или полевого шлюза) во время кеширования или помещения в локальную очередь компоненты ОС и (или) системы могут быть скомпрометированы BitLocker Образ ОС полевого шлюза TRID Незаконное изменение ОС/замена компонентов ОС Раздел ОС со свойством «только чтение», подписанный образ ОС, шифрование Обработка устройств и событий/зона облачного шлюза Облачный шлюз представляет собой систему для удаленного обмена данными между различными устройствами и полевыми шлюзами. Данные, как правило, поступают от различных сайтов в общедоступной сети в облачную систему анализа и контроля данных, являющейся федерацией таких систем. В ряде случаев облачный шлюз может предоставлять прямой доступ к специализированным устройствам с таких терминалов, как планшетные ПК и телефоны. Напоминаем, что в рамках этой статьи термином «облако» обозначается специализированная система обработки данных, которая не привязана к тому же сайту, что и подключенные устройства или полевые шлюзы, и в которой реализованы оперативные меры по предотвращению намеренного физического доступа. При этом такая система может не предоставляться в рамках инфраструктуры общедоступного облака. Облачный шлюз можно сопоставить с наложением виртуализации сети, чтобы изолировать облачный шлюз и все подключенные к нему устройства или полевые шлюзы от любого сетевого трафика. Сам по себе облачный шлюз не является ни системой управления устройством, ни системой обработки или хранения данных устройства, однако шлюз взаимодействует со всеми указанными системами. Зона облачного шлюза содержит сам облачный шлюз, а также все полевые шлюзы и устройства, которые напрямую или опосредованно подключены к нему. Облачный шлюз, как правило, представляет собой настраиваемый программный элемент (например, службу с предоставленными конечными точками, к которой могут подключаться полевой шлюз и устройства). Таким образом, при проектировании следует учитывать все требования безопасности. При проектировании и конструировании этой службы рекомендуется использовать процедуру SDL. Зона служб Система управления (контроллер) — это программное решение, которое взаимодействует с устройством, полевым шлюзом или облачным шлюзом, управляя одним или несколькими устройствами и (или) осуществляя сбор, хранение либо анализ данных устройства для презентации или последующего использования для целей управления. Системы управления — единственные объекты, рассматриваемые в этой статье, которые позволяют упростить взаимодействие с пользователями. Исключением являются промежуточные контрольные поверхности на устройствах, например, переключатель, с помощью которого пользователь может выключать устройство или изменять другие его свойства, и для которого не предусмотрено функциональных эквивалентов, доступных с помощью инструментов цифрового доступа. Промежуточными физическими контрольными поверхностями называются те физические контрольные поверхности, для которых управляющая логика ограничивает удаленный запуск аналогичной функции и предотвращает конфликт входных данных с данными удаленного ввода. Эти промежуточные контрольные поверхности, по сути, подключены к локальной системе управления, использующей те же базовые функции, что и другая система удаленного управления, к которой устройство может быть подключено параллельно. Перечень самых распространенных рисков для облачных вычислений см. на странице Cloud Security Alliance (CSA). Полезные материалы 1. Обзор функций прогнозного обслуживания в предварительно настроенных решениях. 2. Azure IoT Suite: часто задаваемые вопросы. 3. Аккаунт автора материала на GitHub. Если вы увидели неточность перевода, сообщите, пожалуйста, об этом в личные сообщения.

В прошлой своей заметке я рассказал о том, как мы пытаемся приводить в порядок производственные потоки методами теории ограничений. В этот раз опишу, как мы внедряем MTA (производство для обеспечения наличия). Небольшие вводные данные: 1. Проект закрытый. Разрабатывается для себя. 2. Среда разработки не имеет значения. Алгоритмы теории ограничений – простая математика, а значит, реализуются любым доступным языком программирования. 3. Все заметки – это попытка поделиться нашей практикой с миром. Теорию ищите в интернете. Было Менеджер, смотрел сколько продукции на складе, и исходя из этого размещал в производственный план заказ на склад. Но принцип, что-то поделать, пока есть свободное время, изжил себя. Допустим на складе 10 шт некого продукта. Менеджер решает, что этого мало и говорит производству: «Надо сделать 50 шт». Пока делали 50 шт успели отгрузить половину. Снова заказ на склад. И так по кругу. Минус такой схемы работы очевиден. Все данные из «справочника Фонарёва». Мы решили, что цех, хоть и живой организм, должен работать по легко управляемым алгоритмам. Стало Менеджер выбирает позицию, за которой должна следить система. Заносит исходные данные. Достаточно только размера начального буфера и это последнее, что делает человек. Дальше автопилот. Начальный буфер (определение см. в интернете) – это то, от чего оттолкнется система для входа в автоматический режим. Примем решение о размере начального буфера на примере, представленного на скрине ниже. Период 12 месяцев. Средний запас 13 750 шт. Период оборачиваемости ~17 дней. Т.е за 17 дней мы продадим примерно 14 000 шт. Стоит отметить, что эти данные берутся из активной базы данных и на каждый момент времени они свежие. Из практики, для комфортной работы, нам нужно иметь запас примерно на 1-1,5 месяца (зависит от продукции). Получается, что нам нужно держать на складе примерно 20 000 шт. Это и есть размер начального буфера. Здесь не важна точность. Можно установить и 25 000 шт. Система через определённый промежуток времени сама откорректирует буфер исходя из текущих отгрузок и приходов на склад. Всё. Далее система начинает отслеживать выбранные нами позиции и уведомляет, что нужно разместить в план, при достижении критических точек (красная зона). Синяя – перепроизводство. Зелёная – избыток. Желтая – комфорт. Красная – опасность. Черная – дыра. В следующий раз расскажу про наш динамический буфер.
Фильтр списка ComboBox при вводе

«Лучшие программисты не чуть-чуть лучше хороших. Они на порядок лучше по любым меркам: концептуальное мышление, скорость, изобразительность и способность находить решения. » – Rendall E.Stross Наверное эта цитата хорошо отображает понятие квалифицированный программист. Но в мире не всё так прекрасно. Количество лет работы программистом не всегда прямо пропорционально наличию соответствующего опыта и знаний. Далее рассмотрим (с жизненными примерами), на что нужно обращать внимание, чтобы приблизиться к цели стать «лучшим» программистом. Думаю, многие когда-нибудь сталкивались с ситуацией, что старшие руководители обладают не достаточной компетенцией, чтобы вести проект. Кого-то назначают на руководящую должность, потому что становится вопрос об увольнении, а людей и так не хватает, поэтому создается новая должность с более высокой зарплатой. Я считаю, что, закончив институт (то есть в 22-23 года), мало кто может похвастаться достаточным опытом, соответствующим программисту уровня senior. А чтобы руководить другими людьми, нужна широкая осведомленность в техническом плане, и, конечно, нужно обладать качествами лидера. Когда попадаешь в коллектив, невольно начинаешь оценивать способности окружающих, в особенности старших коллег. Это бывает полезно, если выдастся возможность самому выбрать, в чьем проекте принять участие. Итак, получив руководящую должность (минуя этап становления хорошим разработчиком, то есть почти стазу после универа), кто-то может просто решить, что всё, от него более ничего не требуется в профессиональном росте, можно довольствоваться знаниями, полученными во время учебы в универе и опытом работы в 2 года, к тому же с неполной занятостью. Дальнейшее саморазвитие таких людей ограничивается знаниями и навыками, получаемыми по ходу необходимости для проекта и с курсов, оплачиваемых фирмой. Работать с такими людьми вообще никакого желания нет. Ведь в то время, как ты прокачиваешь свои скилы, руководитель неохотно что-то изучает, когда приходится. И это в лучшем случае, а то ведь «я руководитель», поэтому напрягу кого-нибудь другого, а мне пусть перескажут в двух словах, о чем там «Война и мир». А еще наверное почти в каждом коллективе есть люди типа «OK Google», поэтому зачем париться. Ведь мотивации для поддержания и повышения профессионального уровня почти не осталось: руководящую должность получил(а), денежной мотивации соответственно тоже нет, ну о профессиональном соответствии такие люди видимо вообще не задумываются. Да и не особо-то стремятся они обучать кого-то, что собственно является их обязанностью. Помню, когда еще училась в институте, знакомый (постарше меня ) сказал, что его повысили до начальника отдела (в его 25 лет). На вопрос, сколько человек у него в подчинении, он улыбнулся. Фактически в его отделе еще 2 человека, но они не его подчиненные. Через год у этого человека ситуация не особо изменилась. Хотелось бы обратить внимание на несколько конкретных вещей, которые упускают из вида некомпетентные старшие программисты. Нужно знать о программах, которыми пользуетесь Надеюсь, что у всех в компаниях используются системы контроля версий. Мы используем SVN. Один из печальных фактов, что многие не знают в общих чертах, как работают системы контроля версий, чем отличаются распределенные от централизованных систем. В некоторых проектах у нас задействована работа с базами данных (используется Postgres). И вот однажды слышу от одного товарища, что Postgres используется именно для хранения коммитов. Человек даже и не подозревает, что в SVN своя структура хранения информации. Вот сказали ему, что есть команды add, ignore, commit, update и checkout и всё, на этом его знакомство с продуктом окончено. Когда нужно просто выкачать какую-то конкретную версию проекта (без истории всех фиксаций), некоторые даже и не подозревают, что есть export (однажды я наткнулась на сборище из четырех человек, решающих этот вопрос). Но самая нелепая ситуация складывается, когда несколько человек изменяют одни и те же файлы. И как же теперь закоммитить !? И слышишь: «Как? ты тоже что-то менял в файле x.cpp и Y.cpp? Стой пока не коммить! Кто-то один сделает это, а недостающее другой добавит». Возникает встречный вопрос: Ну а зачем тогда создавалась возможность по разрешению конфликтов? Все равно, если кто-то сделал коммит, ты сначала выкачиваешь его, а потом вносишь свои изменения. Не надо думать, что система контроля версий – это просто свалка вносимых изменений, в которой происходит присвоение версии конкретному состоянию файла/проекта. Если при попытке сделать коммит возникает конфликтная ситуация, то это не значит, что вы сделали фиксацию и проблемные файлы сохранились в системе контроля версий. Нужно понимать, какие операции выполняются в рабочей копии, а какие в репозитории. Тупо выполнять операции и считать, что произошла «магия» не нужно. Нужно иметь представление о модели OSI/ISO Каждый хоть как-то пересекался с какими-то понятиями из сетевой модели. Вот реальная история, в которой неосведомленность и наличие не полного понимания о некоторых вещах играет злую шутку. Как-то возникла задача работы по интерфейсам RS-422. Ну а почему бы и не взяться за это, ведь работа будет с COM портом, осталось почитать об особенностях самого стандарта RS-422. И тут у меня спрашивает один из старших программистов: «Уже был опыт работы по RS422/485 ?» Отвечаю, что нет, всё равно уже работала с последовательными портами, так что разберусь. И тут я вижу удивленное лицо человека, который начинает почему-то впаривать (для ясности: у нас до этого никто не работал с RS422), что обмен будет не по последовательному порту. То есть у него вообще нет представления, что такое стандарт физического уровня и интерфейс, используемый для осуществления обмена. Возможно, не все за свою карьеру программистом работали с Bluetooth, pipe, share memory, RS-422, Ethernet и др. Но программист должен понимать, что если он умеет работать по последовательному порту, то сможет выполнить обмен и по Bluetooth, и по RS422/232. Нужно различать уровни ISO/OSI. Не нужно делать проблему, когда возникает задача написать программу для обмена по UDP, а вы раньше писали только обмен по TCP протоколу. Писать продукт без тестов плохо То, что не хватает людей, продукт сопровождается уже несколько лет, а писать модульные тесты с нуля займет много времени и что нет у нас таких людей – просто оправдания. Можно же писать тесты для новых фич. Если ты сходил(а) на какие-то курсы – ты не стал(а) хорошим специалистом по этому направлению Как уже говорилось, большую часть новых знаний fake-руководители получают из курсов, оплачиваемых предприятием. И насколько же бывают неуместны их комментарии в беседах, с которыми вроде бы пытаются блеснуть знаниями, а на самом деле не подозревают, что собеседники очень даже в теме и городить полную ересь с умным видом было не обязательно. Конечно этот список может продолжаться, а перечислять возникающие нелепые ситуации можно довольно долго, но я не об этом. Мне кажется, что очень важно быть выбранным в качестве руководителя проекта, чтобы Вас уважали как программиста и руководителя. Если выдается свободное время, не нужно по полдня тупо сидеть в телефоне/планшете, чтобы поиграть или посмотреть сериал. Всё знать нельзя, но в той или иной мере нужно быть просвещенным в технологиях, архитектуре и др. Ведь очень глупо выглядит, когда 2-3-летний опыт работы молодых заслоняет 10-летний стаж простого просиживания штанов. Я встречала разных программистов, и эта статья относится к меньшинству из них. Но тем ни менее помните, вы должны быть(или хотя бы стремиться быть) примером для более молодого поколения.

Безопасности на хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда. Информационной безопасности АСУ ТП посвящено немало статей на хабре. Функциональной безопасности авторы тоже касались, как в хабе по SCADA, так и в хабе по промышленному программированию АСУ ТП, но, как мне показалось, несколько вскользь. Поэтому я предлагаю короткую информацию об этом важном свойстве, от которого напрямую зависит, получит ли SkyNET контроль над человечеством. В статье сделаны некоторые обобщения для АСУ ТП, а также для встроенных и кибер-физических систем. Заслуживает ли внимания функциональная безопасность? Важна ли функциональная безопасность на сегодняшний день? Ведь фокус внимания в основном направлен на информационную безопасность. С одной стороны, функциональная безопасность напрямую связана с надежностью аппаратной составляющей, и здесь осталось немного нерешенных задач, электроника безотказно работает годами, а если и этого недостаточно, то всегда есть возможность резервирования. Но ведь есть еще программная составляющая, на которую как раз и возлагается управление функциями безопасности. Недавно на хабре была опубликована статья «Самые дорогие и судьбоносные ошибки в ИТ-индустрии». В ней дается описание нескольких кейсов, когда ошибка в софте систем управления космическими системами обходилась в миллионы долларов, и это далеко не все известные случаи. А еще есть системные проекты, включающие механическую, электронную и электрическую составляющие, и здесь, к сожалению, тоже есть место для ошибок. В статье «Интернет вещей (IoT) – вызовы новой реальности» проведен анализ киберугроз и методов обеспечения информационной безопасности для интернета вещей (Internet of Things, IoT). Одним из потенциальных рисков является перехват управления на уровне физических устройств. Тогда злоумышленник может заставить систему управления выполнять опасные функции. В этом случае информационная и функциональная безопасность являются двумя сторонами одного и того же явления. Свойство информационной безопасности должно обеспечить доступность, целостность и конфиденциальность данных системы управления. Свойство функциональной безопасности должно обеспечить корректное выполнение функций системы управления, а при возникновении отказов перевести объект управления в так называемое безопасное состояние. Еще одним мотивом знакомства с функциональной безопасностью является понимание процесса сертификации и лицензирования. Объекты, которыми управляют компьютерные системы, зачастую создают риски для окружающей среды и людей (химическое производство, газовая и нефтяная промышленность, медицинские устройства, атомные и другие электростанции, железнодорожный, автомобильный, авиационный транспорт и т.д.). Компьютерные системы управления такими объектами должны выполнять функции безопасности и обладать определенными характеристиками (резервирование, отказоустойчивость, самодиагностика, устойчивость к внешним экстремальным воздействиям и т.п.). Контроль за разработкой, внедрением и эксплуатацией компьютерных систем управления, важных для безопасности, осуществляется государственными органами сертификации и лицензирования. Таким образом, разработчикам систем приходится знакомиться с требованиями к функциональной безопасности. Архитектура систем управления К какому классу компьютерных систем может быть применено понятие функциональной безопасности? Очевидно, что это системы контроля и управления. Контроль или мониторинг может быть отнесен к частному случаю управления (сбор данных с выдачей управляющего воздействия только в случае обнаружения критического отказа), поэтому будем называть такие системы просто системами управления. Для обобщения взглянем на очевидную структуру идеального контура управления. В реальном мире в этом контуре имеем: управляемый процесс, датчик, контроллер и исполнительный механизм. Необязательной с точки зрения управления, но, тем не менее, неотъемлемой частью сегодняшних систем управления являются человеко-машинный интерфейс и обработчики данных, полученных в результате мониторинга. Подобная архитектура реализуется для встроенных систем (Embedded Systems), широко применяемых в промышленной автоматизации, бытовых устройствах, автомобильных системах, медицинских устройствах, коммуникационных сетях, роботах, дронах и т.п. В АСУ ТП (Industrial Control Systems) применяется более разветвленная архитектура, включающая объединенные в сеть датчики, программируемые логические контроллеры (ПЛК), исполнительные механизмы, хранилища данных, сервера и рабочие станции. Schneider Electric – Modicon Quantum PLC Наиболее сложной является типовая архитектура IoT, я вкратце о ней рассказал в статье на хабре. Управляющая система реализуется на уровне Device Layer. Ее программно-аппаратная реализация может быть аналогична встроенной системе. С точки зрения информационной безопасности критическими являются интерфейсы DL-NL & DL-AL доступа к уровню Device Layer. Таким образом, к системам управления, для которых важно рассматривать свойство функциональной безопасности, относятся АСУ ТП, встроенные системы и IoT. Стандарты, относящиеся к функциональной безопасности В области стандартизации существует такое понятие, как “umbrella standard”, т.е. основополагающий «вертикальный» стандарт верхнего уровня. Для функциональной безопасности таковым является МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems), включающий семь частей. Данный стандарт переведен на русский язык и внедрен в Российской Федерации в виде ГОСТа. Дальше я постарался кратко интерпретировать основные положения МЭК 61508. Они, скажем так, неидеальны, однако, здравый смысл в них имеется. Ниже следует авторская обработка с учетом личного опыта в сфере функциональной безопасности. Согласно положениям МЭК 61508, под функциональной безопасностью (functional safety) подразумевается корректное функционирование, как системы управления, так и управляемого ею оборудования. Таким образом, для обеспечения функциональной безопасности необходимо сначала определить функции безопасности (safety functions), необходимые для снижения риска управляемого оборудования, а также для достижения и сохранения этим оборудованием безопасного состояния (например, функции противоаварийной защиты). Далее, система управления должна обладать свойством так называемой полноты безопасности (safety integrity), под которым МЭК 61508 подразумевает вероятность того, что система будет корректно выполнять функции безопасности при всех заданных условиях в течение заданного интервала времени. При обеспечении полноты безопасности (safety integrity) учитываются два типа отказов: случайные (random failures) и систематические (systematic failures). Случайные отказы вызваны выходом из строя аппаратных компонентов и парируются такими методами, как резервирование, самодиагностика, физическое и электрическое разделение компонентов, повышение устойчивости к внешним воздействиям и т.п. Систематические отказы вызваны ошибками проектирования, в том числе, и ошибками программного обеспечения. Устранение систематических отказов возможно путем совершенствования процессов проектирования и разработки, тестирования, управления конфигурацией, проектного менеджмента и т.п. Кроме того, поскольку классическое резервирование не позволяет избежать систематических отказов, применяется так называемое диверсное (diversity) резервирование, когда резервные каналы разработаны с применением различного программного и аппаратного обеспечения. Дорого, неудобно, но иногда помогает. Положения МЭК 61508 детализированы для потенциально опасных областей. Существуют, например, следующие стандарты: IEC 61511, Functional safety – Safety instrumented systems for the process industry sector; IEC 62061, Safety of machinery – Functional safety of electrical, electronic and programmable electronic control systems; IEC 61513, Nuclear power plants – Instrumentation and control for systems important to safety; ISO 26262, Road vehicles – Functional safety; EN 50129, Railway Industry Specific – System Safety in Electronic Systems; IEC 62304, Medical Device Software; В аэрокосмической отрасли на МЭК 61508 не ссылаются, тем не менее, подход похожий: для авионики разработан стандарт RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification; в космической отрасли стандарты разрабатываются космическими агентствами, например NASA использует стандарт STD 8719.13, Software Safety Standard. Выводы В дружной, но непредсказуемой семье «безопасность», борющейся за свободу информационных технологий от неприемлемых рисков, живут себе две сестры: старшая, функциональная безопасность (safety), и младшая, информационная безопасность (security). Для управляющих систем, к которым относятся такие архитектуры, как АСУ ТП, встроенные системы и интернет вещей (Device Layer), основополагающим свойством является функциональная безопасность. Под функциональной безопасностью подразумевается корректное функционирование, как системы управления, так и управляемого ею оборудования. Информационная безопасность в таких системах носит дополнительный характер и должна предотвращать доступ злоумышленников к контролю над системой управления и управляемым оборудованием. Для объяснения основных аспектов функциональной безопасности планируется следующий цикл статей: Теория надежности и функциональная безопасность: основные термины и показатели; Методы обеспечения функциональной безопасности систем управления; Жизненный цикл безопасности для системы управления; Тестирование систем управления, важных для безопасности. Тематика может корректироваться в зависимости от полученных комментариев.

Поскольку объем данных, которыми оперируют различные компании растет, а эти данные нужно где-то хранить, крупнейшие провайдеры облачных сервисов стали предлагать своим клиентам «холодное хранение» данных. По всей видимости, cold storage сервисы могут занять какую-то часть рынка традиционных услуг хранения данных. При этом cold storage в качестве облачного сервиса может в значительной степени изменить способ работы компаний с данными, включая хранение информации и ее доставку. Amazon Web Services, Google Cloud Platform, и теперь еще и Microsoft Azure предлагают клиентам cold storage сервис. При этом у каждого из названных сервисов свои особенности. Практически все аналитики делают прогнозы о дальнейшем росте рынка облачных сервисов, причем рост этот, судя по всему, будет бурным. Аналитическое агентство Gartner недавно заявило, что в этом году затраты на облачные сервисы и услуги будут являться для компаний основной частью расходов на ИТ. Кроме того, поскольку сейчас все популярнее становятся гибридные облака, к 2017 году около половины крупных компаний воспользуются этой возможностью. Насколько большой объем данных генерируется ежегодно? По оценке Cisco глобальный трафик дата-центров уже давно превысил отметку в один зеттабайт. В 2014 году объем трафика составлял 3,4 зеттабайта, в 2019 году, по прогнозам, этот показатель вырастет до 10,4 зеттабайт. Очень быстрорастущим сегментом трафика в дата-центрах является «облачный трафик», объем которого в 2019 году составит около 8,6 зеттабайт. Понимая перспективы услуги cold storage, Google и Amazon уже довольно давно предлагают своим клиентам воспользоваться сервисами «холодного хранения» данных. Корпорация Microsoft решила присоединиться к Google с Amazon и в апреле запустила Cool Blob Storage, сервис с низкой стоимостью хранения «холодных данных». Для чего все это? Все три компании позиционируют свои cold storage сервисы как недорогую услугу хранения неактивных и маловостребованных данных, включая бекапы, медиаконтент, научные данные, архивы. В общем-то, любые данные, которые относительно редко запрашивают, можно считать «холодными». При этом время доступа к таким данным в cold storage хранилище гораздо выше времени доступа к обычной информации при работе с традиционными сервисами хранения данных. Стоимость хранения «холодных данных» ниже, чем стоимость хранения информации, к которой нужен постоянный оперативный доступ. Google Nearline: корпорация Google впервые представила свой сервис хранения архивной информации в 2015 году. Это решение быстро стало популярным по нескольким причинам. Основная — это быстрый доступ к холодным данным, всего несколько секунд. Это быстрее, чем у того же AWS Glacier. Согласно Google, Nearline немногим отличается от стандартных облачных сервисов компании. Здесь чуть ниже доступность и чуть выше задержка доступа. Время доступа к данным в среде Google Nearline составляет от 2 до 5 секунд. Это действительно неплохо. Но есть несколько проблем. Главное — это ограничение ширины канала в 4 МБ/с для каждого хранимого терабайта. Соответственно, если вам нужно скачать все и сразу — не получится, придется подождать. Правда, есть возможность ускорить процесс при помощи функции On-Demand I/O. Эта функция позволяет увеличить ширину канала с оговоренных 4 МБ/с. Но эта функция отключена по умолчанию. Стоимость хранения данных составляет около 1 цента за гигабайт в месяц. Это относительно немного, плюс время доступа к холодным данным в 3-5 секунд делает Google Nearline одним из лидеров рынка. Сервис позволяет хранить неограниченные объемы данных с доступом к ним через Google Cloud Platform Storage API. Кроме того, у Nearline есть еще и возможность запланировать импорт данных из различных локаций, включая Amazon S3, HTTP/HTTPS сайты и т.п. Все это можно автоматизировать. Amazon AWS Glacier: это одно из первых на рынке решений по хранению холодных данных. Компания позиционирует AWS Glacier как безопасный и очень недорогой сервис для хранения архивных данных и бекапов. Хранить можно крупные массивы информации, стоимость услуги не высока, и начинается от 1 цена за гигабайт в месяц. AWS Glacier можно настраивать под собственные нужды. Для некоторых типов хранимых данных можно настроить время доступа в несколько часов. Речи о нескольких секундах здесь не идет, но у Glacier свои преимущества. Так, 1 ТБ данных можно скачать часа за четыре. Пользователь Google Nearline за то же время сможет загрузить лишь 5% пакета данных объемом в 1 ТБ, с общим временем загрузки примерно 70 часов. Компания предлагает хранить здесь ИТ-медиаресурсы, данные здравоохранения, научные данные и работать с Glacier вместо носителей на магнитных пленках. В среде Glacier данные хранятся в «архивах». Храниться может любая информация, включая фото, видео или документы. Максимальный объем одного «архива» (это своеобразная единица объема хранимых данных в Glacier) составляет 40 ТБ. Загружать и хранить можно неограниченное число таких архивов. У каждого из них — уникальный ID, с присвоением времени создания. После того, как «архив» создан, обновить хранимую в нем информацию нельзя, ее можно лишь скачать, когда в этом возникнет необходимость. Чтобы отсечь пользователей, которые используют сервис не по назначению, за удаление данных ранее трёх месяцев хранения берут определенную плату. Просматривать и управлять хранимыми данными можно при помощи AWS Management Console и AWS SDK. Для любого из наборов данных применимы следующие операции: создание, удаление, просмотр содержимого, тегирование, установление набора политик и прочее. Microsoft Cool Blob Storage: служба хранилища Azure предусматривает два уровня для хранилища BLOB-объектов (хранилища объектов), чтобы данные можно было хранить наиболее эффективно в зависимости от их использования. «Горячий» уровень хранилища Azure оптимизирован для хранения часто используемых данных. «Холодный» уровень хранилища Azure оптимизирован для хранения данных, которые используют редко и долго хранят. Microsoft Cool Blob Storage — это холодный уровень, этот сервис оптимизирован для хранения данных, к которым редко осуществляется доступ, и которые должны храниться в течение долгого времени. Стоимость хранения информации — от 1 до 5 центов за гигабайт в месяц. Все зависит от региона и общего объема хранимых данных. Для сравнения, стоимость хранения «горячих» данных у Microsoft составляет от $0.0223 до $0.061 за гигабайт в месяц. По оценкам представителей компании, в ряде ситуаций хранение холодных данных примерно вдвое дешевле, чем горячих. При этом компания позволяет передавать данные из холодного сервиса хранения в горячий и обратно. Правда, эта услуга платная. В рамках одной учетной записи можно хранить 500 ТБ. Максимальное количество учетных записей хранилища на подписку — 100. Целевая пропускная способность для одного файлового ресурса — до 60 МБ в секунду. В общем-то, сервисы хранения холодных данных от Microsoft, Google, Amazon можно назвать конкурентами с определенной натяжкой. Дело в том, что они отличаются друг от друга и набором функций, и характеристиками. Лидера здесь нет, и пока что вряд ли он и появится. Зато пользователям есть из чего выбрать — для любых требований найдется свое решение. Главное — новые сервисы постепенно меняют конфигурацию рынка традиционных сервисов хранения данных, и можно быть уверенным в том, что «холодных» облачных сервисов будет появляться все больше.

Не секрет, что производители материнских плат и ноутбуков не всегда дают возможность пользователям Linux обновить UEFI/BIOS прошивку так же ненавязчиво, как это делают пользователи Windows. Тем не менее для HP EliteBook 840G1, которым я пользуюсь, сделать это немногим сложнее. Для этого дела понадобятся следующие артефакты: FAT32 EFI System Partition (ESP) WINE Переменный электрический ток FAT32 ESP Ноутбуки линейки HP EliteBook содержат 3 режима загрузки. Узнать какой из режимов выбран можно в настройках UEFI/BIOS > System Configuration > Boot Mode. Данный раздел следует читать, если только выбран последний, бескомпромиссный режим UEFI, в остальных случаях можно проскочить. Legacy UEFI Hybrid with compatibility support module (CSM) UEFI Native without CSM Если вы внимательно читали топик про Linux kernel EFI Boot Stub, то вы наверняка знаете, что и как нужно сделать, для того, чтобы создать дисковый раздел. Можно использовать gdisk, parted или KDE Disk Partition для создания ESP раздела. Вот так выглядит уже готовый раздел. Рекомендуется ESP раздел монтировать в /boot/efi, а не просто в /boot, для того чтобы можно было хранить образы ядра Linux и файлы загрузчика ОС на штатных линуксовых ФС, вместо того, чтобы все держать в FAT32 EFI System Partition. (4:549)$ grep efi /etc/fstab /dev/sda4 /boot/efi vfat rw,users,noauto 0 2 Мы уже знаем, что UEFI/BIOS будет искать \EFI\BOOT\bootx64.efi, для чего абсолютный путь к файлу должен быть /boot/efi/EFI/Boot/Bootx64.efi, иначе все пропало и UEFI/BIOS не найдет загрузчик ОС! Обновлению системной прошивки это не помешает, но для чего же тогда нужна прошивка, если нельзя загрузить операционную систему? Очень немаловажно, что по-умолчанию GRUB-2 не копирует необходимый файл и поэтому bootx64.efi надо скопировать вручную. (4:569) sudo cp /boot/grub/x86_64-efi/core.efi /boot/efi/EFI/Boot/Bootx64.efi Подготовка Берем свежую прошивку с сайта HP, выбираем Linux в выпадающем списке ОС, затем BIOS, скачиваем… и обнаруживаем исполняемый файл для Windows — sp64081.exe. Нет, глаза нас не подвели. (4:520)$ file sp64081.exe sp64081.exe: PE32 executable (GUI) Intel 80386, for MS Windows Опытные пользователи бывают готовы к подобным сюрпризам, для чего держат Windows VM либо пользуются не-эмулятором WINE или и то и другое вместе, бо случаи бывают разные. Для распаковки файла возможностей WINE вполне достаточно. Запускаем: Программа завершает работу с бестактной ошибкой, напоминая лишний раз о том, что нам подсунули не то, что мы ожидали. Однако, это не должно никого волновать, так как файлы распакованы верно а сверх этого ничего и не требовалось. Список файлов(4:529)$ ls -Rl sp64081/ sp64081/: итого 18188 drwxr-xr-x 1 root root 356 июл 30 10:52 BIOSUpdate -rw-r--r-- 1 root root 2950466 мар 4 2013 BIOSUpdateEFI.7z -rwxr-xr-x 1 root root 4838072 авг 7 2013 HPBIOSUPDREC.exe -rw-r--r-- 1 root root 883 июл 30 10:52 HPBIOSUPDREC.log -rwxr-xr-x 1 root root 2353368 сен 18 2013 HpqPswd.exe -rwxr-xr-x 1 root root 77824 фев 22 2012 Installer.exe -rw-r--r-- 1 root root 8388608 окт 9 2013 L71_0104.bin -rw-r--r-- 1 root root 1543 окт 24 2013 WSSP64081.rtf sp64081/BIOSUpdate: итого 2368 -rw-r--r-- 1 root root 259072 ноя 5 2012 CryptRSA32.efi -rw-r--r-- 1 root root 443904 ноя 5 2012 CryptRSA.efi -rw-r--r-- 1 root root 820784 июл 8 2013 HpBiosUpdate32.efi -rw-r--r-- 1 root root 256 июл 8 2013 HpBiosUpdate32.s09 -rw-r--r-- 1 root root 256 июл 8 2013 HpBiosUpdate32.s12 -rw-r--r-- 1 root root 256 июл 8 2013 HpBiosUpdate32.sig -rw-r--r-- 1 root root 16384 июл 9 2013 HpBiosUpdate.dll -rw-r--r-- 1 root root 850512 июл 8 2013 HpBiosUpdate.efi -rw-r--r-- 1 root root 256 июл 8 2013 HpBiosUpdate.s09 -rw-r--r-- 1 root root 256 июл 8 2013 HpBiosUpdate.s12 -rw-r--r-- 1 root root 256 июл 8 2013 HpBiosUpdate.sig Из этого списка нам понадобятся только 3 файла: L71_0137.bin, HpBiosUpdate.efi и HpBiosUpdate.s12 и теперь внимание: скопировать файлы нужно точно в указанные места. (4:534)$ ls -lR /boot/efi/EFI/HP/ /boot/efi/EFI/HP/: итого 8 drwxr-xr-x 3 root root 4096 сен 22 2015 BIOS drwxr-xr-x 2 root root 4096 июл 21 22:23 BIOSUpdate /boot/efi/EFI/HP/BIOS: итого 4 drwxr-xr-x 2 root root 4096 июл 21 22:05 New /boot/efi/EFI/HP/BIOS/New: итого 8192 -rwxr-xr-x 1 root root 8388608 май 23 13:57 L71_0137.bin /boot/efi/EFI/HP/BIOSUpdate: итого 840 -rwxr-xr-x 1 root root 850512 июл 8 2013 HpBiosUpdate.efi -rwxr-xr-x 1 root root 3916 июл 21 22:23 HpBiosUpdate.log -rwxr-xr-x 1 root root 256 июл 8 2013 HpBiosUpdate.s12 1291/7720MB Чтобы попасть в меню настройки UEFI/BIOS надо после включения нажать клавишу Esc или F10 а далее File > Update System BIOS. После выбора Accept, процесс обновления стартует без прочих реверансов. Видимо зная цену своим аккумуляторам, производители обновляют прошивку только при включенном электрическом питании компьютера. 2-3 минуты, и процесс благополучно завершен.

Женские вкусы — штука изменчивая. Судить можно хотя бы по популярным песням. Вспомните: «Парней так много холостых, а я люблю женатого», потом «Любите, девушки, простых романтиков, отважных лётчиков и моряков», в 90-е — «А я люблю военных, красивых, здоровенных...крутых и всяких деловых», в начале 2000-х — «Робот, робот, робот, я тебя люблю, мы так хотели…» Хотя, погодите, всё началось ещё в далёком 1965 году — тогда Алла Пугачёва пела «Неужели в две тысячи первом году нам заменят сердца на транзисторы?… Робот - это выдумка века. Я прошу, ну попробуй, стань опять человеком…» И вот настала очередь создателей роботов и приложений — программистов и инженеров. «Мой парень-программист» из мемов и забавных записок в ЖЖ превратился в социальное явление. Попробуем разобраться, почему это произошло, на что способны программисты и какой он, идеальный мужчина XXI века?

Введение Мировой рынок онлайн-рекламы находится на пороге «мобильной» революции — об этом говорят цифры исследования издания Wallblog. По его данным, доля расходов на mobile programmatic в Великобритании впервые превысила затраты на интернет-рекламу для персональных компьютеров. 5 млрд людей в мире имеют мобильные телефоны, и только 4,1 млрд людей имеют зубные щетки. — как было озвучено на конференции MobileBeat-2016. Мы проанализировали исследования зарубежных коллег и собрали данные о развитии мобильного programmatic на Российском рынке. Объем российского рынка programmatic в целом пока не достигает масштабов, аналогичных рынку в США и Великобритании, и составляет 5 млрд рублей по данным IAB Russia. В России к лидерам рынка мобильного programmatic можно отнести следующих заметных игроков: Data-Centric Alliance с ее programmatic-платформой Exebid.DCA, MADNETeX, iVengo, WapStart, Mobiads, AdWired, DYYD. Наиболее актуальным на данный момент является обзор участников мобильного рынка на карте Mobile Ad Map от IAB Russia. Несмотря на то, что мобильный programmatic занимает только 0,8% от объема всего рынка интернет-рекламы в России, на него приходится уже 15% от общего объема рынка programmatic (т.е. порядка 750-770 млн рублей) по результатам 2015 года. Для сравнения, на долю рынка мобильного programmatic в США приходится 60,5% (в денежном эквиваленте $9,33 млрд) от общего объема programmatic, рост которого в 2016 г. прогнозируется почти на 40%, до $21,55 млрд. В Великобритании, в 2016 году ожидается рост рынка programmatic на 37%, до $4,12 млрд и 58,7% рынка займет programmatic mobile. Что такое mobile programmatic? Алгоритмическое размещение рекламы (англ. Programmatic Buying) – это процесс автоматизируемой (программируемой) продажи и покупки рекламных объявлений с использованием различных алгоритмов. Наиболее часто подразумевают, что алгоритмы закупки имеют фокус на пользователей с определёнными социально-демографическими и поведенческими характеристиками (аудиторный таргетинг). Технология позволяет маркетологам максимально персонифицировать рекламное объявление и демонстрировать их для целевой аудитории продукта в автоматическом режиме. Современные пользователи куда чаще выходят в сеть со смартфонов или планшетов, чем с персонального компьютера (ПК), а мобильные устройства находятся в центре пристального внимания рекламщиков. Маркетологи осознают, что демонстрация онлайн-рекламы на подобных устройствах — это уникальная возможность привлечения поколения миллениалов (поколения Y) к покупке, однако далеко не всегда понимают, как работает новая технология. В Великобритании, в стране с развитым интернет-рынком, бизнес активно продолжает знакомство с возможностями mobile programmatic. Однако, по данным исследования английского подразделения бюро интерактивной рекламы IAB, 44% британских рекламодателей по-прежнему не знают, о том, какие возможности предоставляет технология mobile programmatic. В США же мобайл-сегмент в 2015 году достиг 60,5% объемов сегмента programmatic, что доказывает эффективность нового канала. Эксперты в России отмечают постепенную переориентацию рекламодателей на мобильные рекламные размещения. “Mobile на данный момент обладает наибольшим потенциалом. Огромные объемы инвентаря и существенно более качественный контакт делают его каналом будущего… Рекламного mobile-бума можно ждать уже в ближайшее время” — утверждает руководитель отдела исследований рекламно-коммуникационной группы Digital BBDO Екатерина Филиппова. Увеличение доли мобильных размещений в российском рекламном рынке прогнозирует и Дмитрий Кузнецов, директор по маркетингу Google в России. В целом, россияне стали чаще покупать онлайн с мобильных устройств и все крупные игроки e-commerce констатируют, что доля заказов через мобильные приложения растет. На начало 2016 г., в среднем, на заказы с мобильных устройств по разным оценкам приходится от 15% до 24% всех покупок россиян в интернете – за 2015 г. эта доля выросла более чем в 1,5 раза Мобильный сегмент продолжает расти и предпосылок для снижения популярности мобильных гаджетов нет — это один из главных трендов в области интернет-торговли. Через мобильные приложения вскоре будет осуществляться половина всех интернет-продаж, если рост проникновения технологий и изменения покупательских привычек останутся на том же уровне, считают эксперты. Преимущества mobile programmatic В мобильной рекламе следует выделять два существенных и часто не пересекающихся сегмента: размещение на мобильном трафике классических веб-сайтов (адаптированных или не адаптированных для небольших экранов) и размещение в мобильных приложениях. Последнее, по объему доступного инвентаря, составляет около 70% от общего объема мобильного траффика в России (по данным Exebid.DCA). Информации о мобильном приложении, в котором показывается рекламное объявление, гораздо больше чем информации о веб-сайте. Различные детали о приложении-площадке можно узнать, например, в самих магазинах приложений Google Play и App Store: название площадки, контентную категорию (игры, утилиты, книги, детские приложения и др.), возрастное ограничение, рейтинг площадки, количество установок, комментарии о приложении и многое другое. Сам факт присутствия приложения в магазинах Google Play и App Store свидетельствует о том, что приложение содержит лицензионный контент и отвечает жестким требованиям к его безопастности. Например, каждое приложение перед появлением в App Store проходит сложный этап проверки по множеству пунктов силами специалистов Apple, таким образом экспертизу по content-safety осуществляет третья сторона, а не площадка, агентство или programmatic-платформа. Это позволяет гарантировать рекламодателю, что его рекламные объявления не будут соседствовать с различного рода нежелательным контентом. В мобильном канале бренды получают абсолютно безопасную площадку для коммуникации с потенциальными потребителями. Указанные преимущества разбавляются существенным недостатком рекламных размещений на мобильных устройствах, который связан с устойчивым поведенческим трендом — мобильные устройства используются для ознакомления с продуктом (поиск, сравнение и выбор), но не для покупки. Пользователи предпочитают покупать на персональном компьютере, а выбирать — на мобильном устройстве. Таким образом, при анализе эффективности рекламных кампаний в мобильном сегменте может сложиться обманчивое впечатление о неэффективности данного канала, так как целевое действие совершается на другом устройстве и атрибутируется как органическое — бесплатное. Также необходимо отметить, что несмотря на то, что в интернет все чаще и чаще выходят с мобильного устройства — время сессии на сайте оказывается сильно короче, чем для трафика с ПК. Последнее приводит к тому, что некоторые классические метрики в анализе эффективности кампании оказываются неприменимыми. Эксперты полагают, что ознакомление рекламодателей с технологией будет способствовать развенчанию стереотипов и более широкому ее распространению. Маркетологи требуют максимальной прозрачности процесса закупки рекламных площадей, хотят контролировать цены рабочего инвентаря и до конца понимать выбранную рекламщиком стратегию. Мобильный programmatic предоставляет им эти возможности. Отдельная особенность мобильной рекламы состоит в иллюзии баннерной слепоты, которая массово проявляется и для дисплейных размещений. Рекламные объявления в мобильных приложениях так же страдают от баннерной слепоты, но в гораздо меньшей степени, особенно для видео и нативных форматов. Пока большая часть рынка, к сожалению, все еще полагается на традиционную рекламу и борется с баннерной слепотой, инновационные рекламщики пытаются делать такую рекламу, которая бы приносила вовлеченных пользователей мобильным рекламодателям — замечает Ана Мониз, дизайнер AppLift. Для мобильного, как и для любых других рекламных каналов, характерно использование transparent DSP-платформ, позволяющих проанализировать эффективность объявлений и понять, сколько нужно заплатить медиа ресурсу — владельцу рекламной площади. В этом отличие технологий mobile programmatic от уже устаревшей модели интернет-рекламы с «оптовой» закупкой площадей и непрозрачными моделями формирования цен на эту закупку. При этом порог входа в мобильный рекламный канал с использованием programmatic-технологий оказывается существенно ниже, по сравнению с пакетной закупкой рекламных площадей. Стоимость показа объявления в CPM для мобильного трафика существенно ниже, чем по другим каналам, но возрастает, что логично, при сужении целевой аудитории. Эффективные рекламные сообщения Чтобы сделать мобильную рекламную кампанию эффективной, в большинстве случаев нужно изменить стандартный подход к дизайну и функциональности объявлений, транслирующихся через классические рекламные каналы. Необходимо учесть размер экрана устройства, на котором пользователь будет видеть рекламное сообщение, и его функциональные возможности, адаптировать сам рекламный сайт и специальным образом настроить для него аналитику — предложить владельцу смартфона или планшета максимально привлекательную интерактивную рекламу. Нужно помнить о том, что Flash-баннеры или их частичные аналоги, так называемые Swiffy-баннеры, не подходят для мобильных размещений. В качестве функциональной альтернативы, например, компании Celtra и Crisp предоставляют рекламодателям инструменты-конструкторы для создания «высокосодержательных» мобильных объявлений по стандарту IAB MRAID1.0/2.0. Такие объявления могут замещать всю функциональность сайта и даже являться ему полноценной заменой. Объявления такого формата могут быть использованы на большинстве мобильных рекламных площадках и позволяют повышать эффективность рекламной кампании до 10 раз. Примеры таких объявлений можно опробовать в действии, например, здесь — Celtra Standard Ad. Анализ эффективности По данным Google Россия в 2014 году 62% пользователей использовали мобильные устройства для поиска информации о товарах, а 39% пользователей хотя бы раз совершали покупку со смартфона. Там же отмечено, что, например, в ритейл сегменте путь пользователя к покупке, который начинался с поиска на мобильном устройстве, заканчивался целевым действием на этом же устройстве только в 3% случаях. Для анализа performance-кампаний в мобильном канале недостаточно классических методов атрибуции целевого действия, важно использовать современные возможности систем аналитики, например, т.н. Client Id от Google Analytics, с помощью которого Analytics может связывать друг с другом действия, происходящие на разных устройствах (например, когда пользователь видит рекламу на одном устройстве, а конверсию совершает на другом). Мобильная видеореклама может быть полноценной заменой дорогостоящим размещениям в TV или дополнять их в рамках incremental reach стратегии. Более того, использование мобильного канала позволяет охватить ту аудиторию, которая часто вообще не смотрит телепередачи. При этом анализ эффективности таких охватных рекламных кампаний возможно провести с использованием методики Brand Lift в мобильном канале существенно дешевле, чем при дисплейных, TV или наружных размещениях. Работая в мобильном канале, необходимо быть готовым к высоким т.н. показателям отказов: если на ПК средний показатель отказов 42%, то для планшетов он составляет около 49%, а для телефонов - почти 60%. Это заставляет проектировщиков и разработчиков сайтов проводить целые исследования для повышения удобства сайта при использовании их на мобильном устройстве. К самым очевидным промахам, которые на порядок увеличивают показатель отказов мобильного трафика, можно отнести: использование стартовых экранов “Поверните ваше устройство в горизонтальное положение ...”, размещение на сайте различного рода полноэкранных рекламных объявлений, отсутствие адаптации форм текстового ввода. Наиболее правильный подход к оптимизации юзабилити мобильного сайта состоит в непрерывном A/B тестировании, при этом для каждой платформы iOS, Android OS или Windows, могут получаться противоречивые результаты тестов, связанные с тем, у пользователей разных операционных систем разные привычки и ожидания от интерфейсов. Заключение Вместе с проникновением гаджетов и мобильного интернета высокими темпами будет развиваться и мобильная реклама. По прогнозам различных агентств, объем рынка мобильной рекламы по итогам 2016 года достигнет 23-25 млрд рублей. Развитие мобильного рекламного канала уже серьезнейшим образом меняет медиаландшафт: снижается десктопная аудитория основных площадок, вводятся новые форматы медийного, контекстного и нативного размещений. В стихийно меняющихся условиях рекламного рынка необходимо опираться на богатый опыт иностранных коллег, в особенности на внушительную международную экспертизу в работе с мобильными пользователями. Публикация представляет расширенную версию статьи Что такое мобильный программатик.

Кириллу и Мефодию было нелегко. Они создавали русскую азбуку на основе греческого алфавита и для обозначения звуков, которых в греческом не было, им пришлось придумывать новые буквы. Некоторые из них получились странными. С тех пор алфавит прошел через многочисленные реформы, часть букв исчезла навсегда, но некоторые из изобретений Кирилла и Мефодия дожили до наших дней. Они и сейчас выделяются на фоне остальных букв и заставляют страдать русских дизайнеров. Логомашина собрала факты о самых странных буквах кириллицы. Если понравился материал, подпишись на наш паблик!
Qook: Портировать старую игрушку на Android и поделиться ей с миром

Всем привет! Этой весной в Санкт-Петербурге состоялась West Game Development Forum — международная конференция, посвящённая разработке игр и всему, что с ней связано. Участники WGDF услышали более 40 докладов о разработке, геймдизайне, маркетинге, дизайне, юзабилити и тестировании в видеоиграх класса ААА. Своим опытом и знаниями поделились эксперты из компаний с мировым именем: Wargaming, Blizzard Entertainment, Rockstar Games, Remedy Entertainment, Unity Technologies, Autodesk и др. И теперь мы бы хотели поделиться записями лучших докладов с хабровчанами. Под катом вы найдете выступления: Blending Eastern and Western Development Cultures / Thaine Lyman / WoTs PC Executive Producer, Wargaming Through the Grinder: Refining Diablo III's game systems / Wyatt Cheng / Technical Game Designer, Blizzard Entertainment Five Questions to Ask Everyday: The fun-damentals of strong game design / Alexander Brazie / Game Design Consultant Leadership Traits Your Company Should Have (and you can teach yourself!) / Keith Fuller / Leadership Consultant, Fuller Game Production Мотивация и эмоциональные потребности игроков / Надежда Иванова / IXD Researcher, Wargaming Разработка идей в условиях высокой неопределенности / Никита Денисов / Senior Game Designer, Wargaming Приятного просмотра! Blending Eastern and Western Development Cultures / Thaine Lyman / WoTs PC Executive Producer, Wargaming Тейн Лиман — ветеран индустрии видеоигр. Именно он разработал процедуру прохождения проектами этапа «гринлайт», работая в Activision в далёком 1999 году. Его карьера связана с релизами знаковых игр и франшиз, которые знакомы каждому: Call of Duty, 1, 2, 3, Black Ops, Quake, Castle Wolfenstein, Transformers и Destiny. Сейчас Тейн является исполнительным продюсером World of Tanks PC. В выступлении Тейн поделился уроками, которые он вынес, работая с разработчиками западной и восточной культур. На основании многолетнего опыта он сравнил основные тенденции и рассказал о методах, которые помогут работать эффективно с любой командой, вне зависимости от культурных особенностей. Выступление на английском: Синхронный перевод на русский Through the Grinder: Refining Diablo III's game systems / Wyatt Cheng / Technical Game Designer, Blizzard Entertainment Уайет Чен работает в Blizzard Entertainment на протяжении 13 лет. Он участвовал в разработке World of Warcraft от старта игры до дополнения Burning Crusade. Потом он присоединился к команде Diablo III. Сейчас он руководит релизной командой Diablo III. Как и все игры Blizzard, Diablo III от старта до релиза прошла через множество итераций. Выступление Уайета посвящено игровым системам, которые опробовали разработчики во время работы над игрой. Он рассказал про все плюсы и минусы каждой системы, что сработало и не сработало, как команда использовала каждую неудачу, чтобы приблизиться к успеху. Выступление на английском: Синхронный перевод на русский Five Questions to Ask Everyday: The fun-damentals of strong game design / Alexander Brazie/ Game Design Consultant Александр Брези, также известный как Xelnath, десять лет учился у ветеранов игровой индустрии, и еще десять работал над ААА-проектами. Будучи геймдизайнером League of Legends и World of Warcraft, он известен своей философией дизайна, фокусирующейся на взаимодействии с сообществами игроков. Сильный геймдизайн не случайность, это результат креативных идей, тяжелой работы, хорошей дисциплины и любви к ремеслу. В докладе Александр задал пять вопросов, которые должен задавать себе каждый разработчик, чтобы делать не просто хорошие, но великие игры. Выступление на английском: Синхронный перевод на русский Leadership Traits Your Company Should Have (and you can teach yourself!) / Keith Fuller / Leadership Consultant, Fuller Game Production Кит Фуллер — сертифицированный специалист в управлении проектами и Scrum. Сейчас он помогает руководителям студий любого размера развивать лидерские навыки и совершенствовать производственные процессы. Однако за плечами у Кита более 20 лет разработки игр и 12 AAA-проектов, в которых он был программистом, менеджером проекта или продюсером. Существует несколько основных лидерских черт, которые влияют на результат работы студии, качество проектов и эмоциональное здоровье сотрудников. На примере нескольких отраслевых исследований Кит объяснит, почему эти черты важны, и как компании могут развивать их. Выступление на английском: Синхронный перевод на русский Мотивация и эмоциональные потребности игроков / Надежда Иванова / IXD Researcher, Wargaming Надежда работает IXD-исследователем в санкт-петербургской студии разработки Wargaming с 2014 года. Ее главная задача — всестороннее исследование аудитории World of Warships, а также ее взаимодействия с продуктом (будь то игра, информационная площадка проекта или видеоролик). В докладе Надежда поделилась результатами исследования психологии игроков, их интересов, потребностей, ценностей и особенностей мотивации. Надежда рассказала о том, как отслеживаются изменения мотивации и игрового поведения аудитории WoWs, и какие есть различия в интересах, ценностях и мотивации игроков из разных регионов. Выступление на русском: Разработка идей в условиях высокой неопределенности / Никита Денисов / Senior Game Designer, Wargaming Игровая индустрия еще не обросла жесткими формулами финансового успеха, и, создавая игры, мы часто полагаемся на интуицию, ощущения и надежду внезапно вообразить гениальную и работающую структуру — все это в режиме хаотичного мозгового штурма. Но такой процесс характеризуется высокой неопределенностью и огромными рисками. Даже если исключить материальные блага, велик шанс создать игру, которая будет никому не интересна, в том числе и самим создателям. Никита рассказал историю о разработчике игр. Историю о трудностях и их преодолении; о том, как привнести толику порядка в генерацию и разработку идей; о способах развить себя и увеличить эффективность, при этом не жертвуя, а наоборот, способствуя творчеству. Выступление на русском: Записи всех выступлений WGDF вы можете найти на YouTube. Спасибо за внимание и до встречи на WGDF 2017!

Сегодня расскажем о том, как, пользуясь Java, создавать приложения для IoT, которые могут работать с удалёнными Bluetooth Low Energy-устройствами. Разработку таких приложений, благодаря проекту с открытым исходным кодом TinyB, поддерживает Intel IoT Development Kit. TinyB предоставляет разработчику простые API для C++ и Java, которые позволяют работать с BLE-устройствами. Здесь рассмотрим API TinyB для Java, а эксперименты будем проводить на Intel Edison. О совместимости и предварительных требованиях Текущая версия Bluetooth API в TinyB протестирована в среде исполнения Java 8 (OpenJDK 8). Это окружение, как и TinyB, поставляется как часть официальной сборки образа Intel IoT Development Kit для плат Intel Edison. На Linux-системах TinyB можно использовать при установленном BlueZ (версия 5.37. или выше). При этом демон bluetoothd запускается с включенными экспериментальными функциями (флаг –E). Подробнее об этом можете почитать в файле README. В нашем примере в роли Bluetooth LE-устройства выступает SensorTag от Texas Instruments. Подробности об устройстве можно найти здесь. Документация и примеры приложений Вот два варианта документации для Bluetooth API которое предоставляет TinyB. Здесь – материалы для тех, кто пользуется C++, а здесь – для Java-разработчиков. В примере HelloTinyB, который написан на Java (или в hellotinyb для C++) используется вышеупомянутый SensorTag. С него осуществляется считывание показателей об окружающей температуре и температуре объекта. Для правильной работы приложению требуется MAC-адрес SensorTag. Его надо передать в качестве первого параметра при запуске программы: ./examples/hellotinyb XX:XX:XX:XX:XX:XX java -cp examples/java/HelloTinyB.jar:/usr/lib/java/tinyb.jar HelloTinyB XX:XX:XX:XX:XX:XX IoT-приложение на Java для работы с Bluetooth LE Здесь мы воспользуемся примером HelloTinyB, который написан на Java. Его можно найти в репозитории TinyB. Мы покажем, как написать приложение, которое читает данные из службы GATT через Bluetooth LE. Для того, чтобы начать работать с SensorTag, нужно инициализировать библиотеку TinyB. Объект BluetoothManager предоставляет точку входа для использования Bluetooth-устройств. В программе может быть лишь один экземпляр этого объекта-менеджера. Ссылку на него можно получить с помощью метода getBluetoothManager(): BluetoothManager manager = BluetoothManager.getBluetoothManager(); Менеджер попытается инициализировать объект BluetoothAdapter если в системе присутствует Bluetooth-адаптер. Для того, чтобы запустить поиск других устройств, нужно вызвать метод startDiscovery(), который переведёт адаптер, используемый по умолчанию, в режим поиска: boolean discoveryStarted = manager.startDiscovery(); После выполнения этой команды можно ждать следующего отладочного вывода: The discovery started: true Address = C4:BE:84:72:2B:09 Name = CC2650 SensorTag Connected = false После запуска поиска обнаружено новое устройство. Список всех найденных устройств можно получить с помощью метода менеджера getDevices(). Этот список нужно просмотреть для того, чтобы найти устройство с MAC-адресом, заданным в качестве параметра при запуске программы. Поиск продолжается либо до тех пор, пока нужное устройство не будет найдено, либо – пока не будет предпринято 15 попыток его обнаружения (занимает это около минуты). static BluetoothDevice getDevice(String address) throws InterruptedException { BluetoothManager manager = BluetoothManager.getBluetoothManager(); BluetoothDevice sensor = null; for (int i = 0; (i < 15) && running; ++i) { List<BluetoothDevice> list = manager.getDevices(); for (BluetoothDevice device : list) { printDevice(device); /* * Здесь проверяем, совпадает ли адрес с заданным. */ if (device.getAddress().equals(address)) sensor = device; } if (sensor > После того, как нужное Bluetooth-устройство обнаружено, можно запустить процесс подключения к нему с помощью метода connect объекта, который ему соответствует. Вот как должен выглядеть тестовый вывод на данном этапе работы: Found device: Address = C4:BE:84:72:2B:09 Name = CC2650 SensorTag Connected = false Sensor with the provided address connected Устройство, к которому мы подключаемся, должно давать доступ к службе определения температуры, UUID которой можно найти в документации. Служба, которая нам нужна, имеет короткий UUID AA00. Его нужно вставить в основной UUID TI вместо XXXX: f000XXXX-0451-4000-b000-000000000000. static BluetoothGattService getService(BluetoothDevice device, String UUID) throws InterruptedException { System.out.println("Services exposed by device:"); BluetoothGattService tempService = null; List<BluetoothGattService> bluetoothServices = null; do { bluetoothServices = device.getServices(); for (BluetoothGattService service : bluetoothServices) { System.out.println("UUID: " + service.getUuid()); if (service.getUuid().equals(UUID)) tempService = service; } Thread.sleep(4000); } while (bluetoothServices > В результате работы вышеприведённого кода должно быть выведено следующее: Services exposed by device: UUID: f000aa64-0451-4000-b000-000000000000 UUID: 0000180a-0000-1000-8000-00805f9b34fb UUID: f000ccc0-0451-4000-b000-000000000000 UUID: f000ac00-0451-4000-b000-000000000000 ... Found service f000aa00-0451-4000-b000-000000000000 В первую очередь нам нужно получить характеристики службы. Таких характеристик три: значение (UUID AA01), конфигурация (AA02) и период: (AA03). Узнаем их, воспользовавшись следующим кодом: static BluetoothGattCharacteristic getCharacteristic(BluetoothGattService service, String UUID) { List<BluetoothGattCharacteristic> characteristics = service.getCharacteristics(); for (BluetoothGattCharacteristic characteristic : characteristics) { if (characteristic.getUuid().equals(UUID)) return characteristic; } return null; } BluetoothGattCharacteristic tempValue = getCharacteristic(tempService, "f000aa01-0451-4000-b000-000000000000"); BluetoothGattCharacteristic tempConfig = getCharacteristic(tempService, "f000aa02-0451-4000-b000-000000000000"); BluetoothGattCharacteristic tempPeriod = getCharacteristic(tempService, "f000aa03-0451-4000-b000-000000000000"); Теперь нужно включить службу определения температуры, записав «1» в характеристику конфигурации. Подробности об этом есть в вышеупомянутой документации. Можно изменить и интервал обновления показателей, записав нужное значение в характеристику периода, но значение по умолчанию, «1», нам подходит. byte[] config = { 0x01 }; tempConfig.writeValue(config); После настройки можно приступать к чтению с устройства сведений о температуре. Служба температуры возвращает данные в закодированном формате. Особенности работы с этим форматом данных можно найти в документации к SensorTag. Мы собираемся преобразовать полученные данные в градусы Цельсия и вывести их в консоль. Температура объекта, в соответствии с документацией, зависит от температуры окружающей среды. Здесь мы будем считать, что результаты без дополнительных преобразований нас устраивают. while (running) { byte[] tempRaw = tempValue.readValue(); System.out.print("Temp raw = {"); for (byte b : tempRaw) { System.out.print(String.format("%02x,", b)); } System.out.print("}"); int objectTempRaw = tempRaw[0] + (tempRaw[1] << 8); int ambientTempRaw = tempRaw[2] + (tempRaw[3] << 8); float objectTempCelsius = convertCelsius(objectTempRaw); float ambientTempCelsius = convertCelsius(ambientTempRaw); System.out.println(String.format(" Temp: Object = %fC, Ambient = %fC", objectTempCelsius, ambientTempCelsius)); Thread.sleep(1000); } В процессе выполнения этого цикла будут выводиться сведения о температуре, полученные с Bluetooth LE-датчика: Temp raw = {10,0b,c8,0d,} Temp: Object = 22.125000C, Ambient = 25.562500C Temp raw = {10,0b,c8,0d,} Temp: Object = 22.125000C, Ambient = 25.562500C Temp raw = {04,0b,cc,0d,} Temp: Object = 22.031250C, Ambient = 25.593750C ... Temp raw = {34,0b,cc,0d,} Temp: Object = 22.406250C, Ambient = 25.593750C Итоги Мы рассказали о том, как писать на Java приложения, которые умеют работать с Bluetooth LE-устройствами. Надо отметить, что API, использованное в рассмотренном примере, основано на TinyB v0.3. Эта версия библиотеки поддерживает лишь работу в режиме опроса устройств, но в версии 0.4. представлено упрощённое API для обнаружения устройств и служб. Надеемся, то, что вы сегодня узнали, поможет вам в разработке собственных IoT-проектов.

Петербургская JavaScript-конференция HolyJS начиналась почти как авантюра. Затевать совершенно новую конференцию, когда время на подготовку очень ограничено — смелое решение. Такой авантюризм хорошо соответствует духу самого JavaScript-мира, где всё происходит стремительно, а смелые решения зачастую необходимы. Но возможно ли в таком случае провести конференцию на высоком уровне, с интересными докладами и без организационных проблем? Что в итоге было на мероприятии? Под катом — рассказ о том, как оно прошло. Конференция была сделана совместными силами: организацией занималась JUG.ru Group, а программу готовили SPB Frontend. Логичное разделение труда: у первых — большой опыт организации других конференций, у вторых — знание JS-мира, позволяющее обеспечить должный уровень докладов. Впрочем, в открывающем кейноуте от Дениса Мишунова (Digital Garden AS) знание тонкостей JavaScript не требовалось: речь пошла не о них, а о тонкостях человеческого восприятия. Гонясь за миллисекундами и килобайтами, легко позабыть, что на фронтэнде вся эта гонка изначально нужна ради пользователя. А то, насколько будет хорошо пользователю, зависит не только от миллисекунд. В некоторых случаях может доходить до того, что «медленнее» будет означать «лучше»: например, когда у пользователя ощущение, что происходит что-то очень важное, и моментальное выполнение покажется ему «халтурой». А в других лучше будет «быстрее», но при этом пользователь будет ощущать самым быстрым не тот сервис, в пользу которого говорят бенчмарки. Доклад заканчивался отсылкой к документации Apple для разработчиков, в которой напрямую сказано: «The perception of performance is just as effective as actual performance in many cases». Мишунова на главной сцене сменил Виктор Русакович (GP Software.travel) с докладом о реактивном программировании, и всё сразу стало куда технологичнее. Описав состав RxJS как «объекты, операторы и магия», Русакович подробно прошёлся по второму пункту. Цель «расписать каждый оператор» не ставилась (их попросту слишком много), но конкретные примеры, проиллюстрированные «шариками» с сайта RxMarbles, позволяли получить хорошее общее представление. Затем Дино Эспозито говорил о распознавании устройств и различном отображении сайтов на них. Он напоминал, что, с одной стороны, user agent string доверять нельзя («как-то мы тестировали дешёвый китайский планшет, так он выдавал себя за iPad»), но с другой, определять параметры устройства и полагаться на responsive web design тоже не панацея («главная проблема в том, что он одинаково обходится с компьютерным окном браузера шириной в 480 пикселов и со смартфоном, у которого ширина экрана 480 пикселов»). Любопытно было наблюдать контраст с тем, как тот же Эспозито выступал двумя днями ранее на DotNext. В .NET-мире он крупный авторитет, и на соответствующей конференции блистал на главной сцене, как рок-звезда перед заворожёнными поклонниками. Здесь же был просто одним из докладчиков второго зала, и таким плотным потоком остроты не обрушивал. Впрочем, спутать его с кем-то другим все равно не получилось бы: такую харизму не спрячешь. Его сменил Михаил Дружинин (Luxoft) с рассказом о порталах на JavaScript: «Бывает нужно разместить на одной странице несколько разных модулей. И если они не зависят друг от друга, то в этом случае ещё повезло...». Но пока Михаил разбирал, как в этом может помочь фреймворк F2, в третьем зале Алексей Симоненко с докладом «Как я перестал верить технологиям» (и завидной бородой) критиковал беготню за новыми фреймворками и прочими инструментами. С бурным развитием JS-мира неудивительно, что в нём синдром серебряной пули особенно силён: тут чуть ли не каждый день что-то новое обещает исправить все ошибки предшественников и сделать ваш проект гораздо успешнее. Но статья «No Silver Bullet», в этом году отмечающая 30-летие, не стала с момента сочинения менее актуальной. Поэтому неудивительно и появление возражений «куда вы так несётесь, посмотрите на реальных примерах, как переход на что-то новое совершенно не избавлял от всех проблем». Симоненко оригинально построил доклад, начав с прославления нового чудодейственного средства Hype.js и лишь затем признавшись, что его не существует. Позже он привёл классическую диаграмму The Hype Cycle, напоминающую, что для любой новой технологии характерен «пик завышенных ожиданий», обычно сменяющийся болезненным разочарованием. Поэтому, пока кто-то постоянно прыгает с одной технологии на другую, уже напрыгавшийся и набивший шишек спикер советовал «работайте с тем, что знаете». В обеденном перерыве, как и накануне на Mobius, можно было услышать обсуждения задач от EPAM. Их набор частично отличался, но задача об инфицированной шахматной доске снова попала в список — и снова обращала на себя внимание. Помимо задач, стенд EPAM запомнился многим возможностью поиграть с развивающим конструктором Qubidoo, заставив шарик катиться по жёлобу. На сайте конструктора написано «от 3 лет до 140 IQ», и это ироничное определение похоже на правду: на HolyJS взрослые мужчины увлечённо возились с игрушкой, способной вызвать интерес у трёхлетнего. А после обеда Василика Климова (Artec Group) рассказывала про WebGL. Для обычного фронтэндера без опыта работы с 3D-графикой тема может показаться далёкой и пугающей, но Василика объясняла, что бояться нечего: при использовании библиотеки Three.js всё оказывается куда проще, чем можно предположить. От общих слов и эффектных демо-роликов она перешла непосредственно к тому, как пишут шейдеры, и примеры оказались вполне доступными для зрителей без WebGL-опыта: ну да, чтобы превратить цветную модель в чёрно-белую, из трёх цветов по RGB стоит выводить среднее арифметическое, логично. Помимо отмеченной многими содержательности доклада, он впечатлял ещё и в совсем другом отношении. Пока что на IT-конференциях нечасто можно увидеть, как обаятельная девушка объясняет мужчинам «зря вы боитесь, я разобралась, тут ничего страшного», и кому-то из зрителей такая картина могла рвать шаблон. Но судя по появлению мероприятий вроде Ladies Code, где среди прочих участвовала та же Василика, интерес женщин к IT растёт, и в будущем это может стать куда более привычной картиной. Затем в том же зале Кирилл Сухомлин (EPAM Systems) говорил о том, откуда берутся новые JS-фичи, и это ярко показывало отличие JS-мира от других. На конференциях DotNext и Mobius не вставал вопрос, откуда берутся новые фичи в .NET или Swift — там сразу ясно, кто всему голова. А в случае с JavaScript о роли Ecma International задумываются куда меньше. Зато в процессе его развития случаются такие же казусы, как и в других мирах. Как объяснял Кирилл, четвёртая версия ECMAScript была самой амбициозной, но в итоге оказалась заброшенной, и пятую, наоборот, можно было назвать «дуем на воду». Это заставляло вспомнить то, что Дино Эспозито на DotNext говорил о происходящем с (ASP).NET Core: Microsoft устроил революцию, но ещё не доведя её до релиза, испугался результатов и дал по тормозам. Сам Эспозито тем временем нашёл себе на конференции интересное занятие. На HolyJS, кроме него, был только один англоязычный спикер, так что слушать весь день доклады Дино не мог. Но он обнаружил подходящего собеседника, принявшись болтать с ним и фотографировать его: это был «робот Федя», легко перешедший на английский. Сложно сказать, кто из этой пары выглядел колоритнее и остроумнее. Закрывал конференцию кейноут от Вячеслава Егорова (Google), работавшего над движком V8. Получалась интересная симметрия с открывающим кейноутом: оба были о производительности, но первый о психологии и восприятии, а второй, наоборот, о технологическом хардкоре и внутренностях движков. И даже в топ-10 докладов по отзывам зрителей эти два выступления оказались на соседних позициях, уступив только неверию в технологии: 1. Алексей Симоненко — Как я перестал верить технологиям 2. Вячеслав Егоров — Производительность JavaScript через подзорную трубу 3. Денис Мишунов — В погоне за производительностью: психология пользователя 4. Виктор Грищенко — Swarm: синхронизируем рой устройств 5. Николай Рыжиков — JаvaScriрt внутри PostgreSQL 6. Алексей Охрименко — Парсеры — это Спарта 7. Василика Климова — Практическое применение WebGL 8. Роман Дворнов — CSSO: оптимизируем CSS 9. Игорь Зотов — Iskra JS: JаvaScriрt в микроконтроллере 10. Михаил Новиков — Удобные API с GraphQL Доклад Егорова перекликался с тем, что на Java-конференциях устраивает Алексей Шипилёв: глубокое знание «кишочков» сочеталось с задорным изложением, а суровые числа бенчмарков — с яркими иллюстрациями. Более того, даже в выборе иллюстраций у этих двух спикеров есть пересечения: На этом выступлении, когда конференция было уже на финишной прямой, внезапно возникла проблема с техникой, и на некоторое время зал остался без слайдов. Как заметил Егоров, прямо перед докладом Алексей 23derevo Фёдоров сказал ему «Раз за всё мероприятие ещё не произошло ни одного технического факапа, значит, на твоём что-то произойдёт, готовься». Забавно было видеть, насколько точными оказались эти слова: фраза из анекдота «стена рухнула точно по графику» получала вполне буквальное воплощение. Но затем техника ожила, и дело дошло до завершительного слайда «Спасибо». А в остальном конференция прошла удивительно беспроблемно для первого раза, и зрительские отзывы показали: если устраивать HolyJS и было авантюрой, то она явно удалась.

18 и 19 июня прошёл хакатон по PHP фреймворку Yii, состоявшийся благодаря ТАСС, конференции DevConf и лично Вадиму Крючкову. В мероприятии участвовало 18 разработчиков, которые поделились на команды и занимались сразу несколькими задачами. Помимо небольших качественных багфиксов, которые вместе с тестами практически сразу попали в master, были сделаны наработки и по довольно глобальным вопросам: очередям и обработчикам сокетов. Наработки creocoder-а по расширению очередей очень помогли, но не совсем подходили для дальнейшего развития. Устроили мозговой штурм, на второй день завершили дизайн (возможно ещё будет небольшая смена именования в интерфейсах) и начали реализовывать конкретные драйверы. Два человека из рабочей группы получили права на запись в репозиторий yii2-queue и намерены довести дело до конца. Идея сделать удобной работу с сокет-соединениями была навеяна очередным бумом чат-ботов для Telegram, Slack и других мессенджеров. Хорошо продвинулись как в техническом плане, так и в плане дизайна. Довольно сложной задачей оказалась поддержка SELECT FOR UPDATE из за разницы в реализации под поддерживаемые фреймворком СУБД и отсутствием нормального способа сделать под это юнит-тесты (если кто знает, как это можно протестировать через phpunit, делитесь). Новый сайт получил pull request, реализующий раздел расширений. Он уже попал в master с некоторыми доработками. Работает это через API packagist (команда Yii планировала реализовывать это намного более сложным и трудоёмким способов). Ещё один небольшой шаг к новому прекрасному сайту сделан. Конечно, хакатон — это не только непрерывная работа, но и интересное общение. Очень приятно было снова увидеть старых знакомых, вживую пообщаться с теми, с кем общались ранее только перепиской и познакомиться с единомышленниками. Вкусная пицца, посиделки, сувениры, экскурсия от ТАСС и знакомство с кухней столь серьёзной организации сделали эти два дня действительно прекрасными. Спасибо всем, кто участвовал и да здравствует OpenSource!
Как средствами OpenGL менять прозрачность у картинки?

В последнее время искусственная, или виртуальная, реальность (VR) все более распространяется в сфере потребительской электроники, а также в обрабатывающей промышленности, здравоохранении, образовании и т.д. Но в индустрии ЦОД данное направление практически не применяется, не взирая на то, что именно серверы отвечают за визуализацию контента, отображаемого большинством гарнитур виртуальной реальности. ЦОД характеризуется несколькими показателями и коэффициентами, значения которых и являются объектом изменения при его оптимизации. Обладая информацией о значениях данных и показателей, возможно запланировать меры, которые помогут повысить энергоэффективность дата-центра. Но подобные действия достаточно трудоемкие и опасные, ведь ошибки могут привести к сбою в работе ЦОД и даже к потере данных. Для того, чтобы поменять расположение серверных стоек также понадобится немало сил и времени. Но с помощью виртуальной реальности все эти манипуляции можно оптимизировать и сделать более надежным. Достаточно составить виртуальную модель, которая позволит определить правильность воздушных потоков и измерить необходимые показатели. Таким образом получится провести все вычислительные процессы, мониторинг и проектирование в полной безопасности по отношению к работоспособности ЦОД. У виртуальной реальности есть огромный потенциал — ее можно применять для проектирования и строительства серверных ферм. По мнению генерального директора колокейшн-провайдера Aegis Data Грега Маккалоха, именно дата-центры способны максимально эффективно использовать подобную технологию. И возможностей для этого предостаточно. В частности, VR особенно пригодится в проектировании и строительстве фактического помещения под ЦОД. Ведь с помощью виртуальной реальности получится визуализировать полезное внутреннее пространство и увидеть, как будет выглядеть само здание. Также и потенциальные клиенты смогут самостоятельно, удаленно «посещать» машзалы, в которых они собираются арендовать пространство. Это удобно, экономит время и деньги. Кроме того комплексное изучение визуализации модели ЦОД поможет принять более основательное решение в выборе площадки для хранения данных. И удаленные партнеры получат возможность просматривать систему физической безопасности дата-центра, включающую камеры видеонаблюдения, системы биометрической идентификации, тамбуры-шлюзы и многие другие элементы. Несмотря на то, что рассматриваемая технология пока еще находится на ранней стадии своего развития, Маккалох уверен, что VR-гаджеты уже являются достаточно полезными и эффективными инструментами для удовлетворения потребностей индустрии ЦОД. Они успешно используются при проектировании коммерческих зданий, поэтому ничто не мешает адаптировать их и для проектирования дата-центров. Ниже находится видеоролик от Google, который показывает использование виртуальной реальности для демонстрации ЦОД. Это — виртуальная экскурсия по дата-центру поискового гиганта в городе Даллас (штат Орегон, США). Данное видео представляет одно из самых безопасных мест на планете. С его помощью Google удалось показать свой дата-центр широкой аудитории, помогая потребителям понять, каким образом работают интернет-сервисы, вроде поисковиков и облачных хранилищ. Гаджеты виртуальной реальности могут стать весьма эффективными инструментами для продвижения коммерческих дата-центров, их проектирования и расширения инфраструктуры. Кроме того виртуальная реальность открывает новые возможности для обучения персонала серверных ферм или оптимизации взаимодействия между несколькими дата-центрами. Например, проведений совместных виртуальных конференций с участием операторов сразу нескольких ЦОД одной организации, расположенных в разных геолокациях. Но одновременно с получением выгоды, операторам ЦОД нужно осознать, что рынок виртуальной реальности будет неустанно расти. И по прогнозам, на 2016 год число проданных VR-гаджетов достигнет 9,6 млн штук. Подобная тенденция востребованности аудиовизуального медиа-контента для гаджетов виртуальной реальности рано или поздно приведет к новым вызовам для владельцев дата-центров. Они будут вынуждены наращивать число систем хранения данных и серверов, должным образом расширяя вспомогательную инфраструктуру своих корпоративных или коммерческих серверных ферм.
Что мешает развитию бизнеса Интернета вещей?

Шлюзы Intel для интернета вещей могут работать под управлением различных операционных систем. Одна из них – Windows 10 IoT. Сегодня мы поговорим о модуле для PowerShell IntelIoTGatewaySetup, который создан специально для поддержки IoT-шлюзов в среде Microsoft Windows. Официально этот модуль называется «Intel IoT Gateway Module for Microsoft Windows PowerShell». Он помогает настроить операционную систему шлюза на заданный уровень безопасности (Security SKU). Основные сведения Модуль входит в состав пакета Windows Configuration Software for Intel IoT Gateway. Пакет можно найти по вышеприведённому названию и скачать в Центре загрузки Intel. В настоящее время поддерживаются операционные системы Windows 10 IoT Enterprise и Windows 10 IoT Core. IntelIoTGatewaySetup позволяет настраивать следующие функции безопасности Windows, указанные в описании уровней безопасности. Предусмотрено три уровня безопасности. В частности, это, в порядке возрастания обеспечиваемого уровня защиты, Basic SKU, Medium SKU, и High SKU. Каждый следующий уровень расширяет возможности предыдущего. Итак, вот список настраиваемых функций. Windows Update, Windows Defender, Windows Firewall, Windows User Account Control, USB Removable Media Lockdown, Virtualization Based Security, App Locker, Code Integrity. BitLocker с поддержкой модуля TPM для Windows 10 IoT Enterprise. Хотя в определениях уровней безопасности упомянуто использование TPM и сетевой разблокировки (Network Unlock) для среднего и высокого уровней, модуль PowerShell настраивает лишь BitLocker с поддержкой TPM, так как Network Unlock требует дополнительной сетевой инфраструктуры. Хотя модуль IntelIoTGatewaySetup и настраивает множество параметров в соответствии с заданным уровнем безопасности, он не касается следующих возможностей: UEFI, Secure Boot и TPM. Всё это является частью аппаратных требований и требований к микропрограммам для шлюзов Intel. Таким образом, эти функции на шлюзе будут уже включены. Уровни привилегий учётных записей. Можно создать, в зависимости от особенностей использования системы, учётную запись с ролью администратора или обычную учётную запись со стандартным набором прав. ASLR. Эта возможность по умолчанию поддерживается и включена в ОС Windows, таким образом, в дополнительной настройке она не нуждается. Measured Boot. Эта функция реализуется благодаря прошивке UEFI, TPM и Windows. Она так же не нуждается в дополнительной настройке. Remote Attestation. Эта функция нуждается в настройке дополнительной сетевой инфраструктуры и в дополнительном программном обеспечении. BitLocker + Network Unlock. Технология Network Unlock требует настройки дополнительной сетевой инфраструктуры и возможностей DHCP-драйвера в UEFI. В результате модуль PowerShell способен настроить лишь BitLocker с поддержкой TPM. USB Filter. Для настройки этой функции в соответствии с особенностями использования шлюза, применяйте групповые политики для того, чтобы управлять USB-устройствами, основываясь на Device ID или Class ID. Keyboard Filter. Для настройки этого фильтра воспользуйтесь инструментом Windows ICD. В папке IntelIoTGatewaySetup находятся следующие основные компоненты: Readme.rtf. Обычный сопроводительный файл с инструкциями по началу работы. ModuleInstallation.ps1. Вспомогательный скрипт для установки модуля IntelIoTGatewaySetup. Папка IntelIoTGatewaySetup. Здесь содержится сам модуль. Установка модуля Если у вас имеется шлюз, оснащённый дисплеем и клавиатурой, команды PowerShell, необходимые для установки модуля, можно исполнять непосредственно на шлюзе. После установки команды PowerShell, которые предоставляет модуль, так же можно исполнять прямо на шлюзе. Мы называем это локальной установкой и локальным исполнением команд. Шлюз может быть расположен вне пределов физической досягаемости, кроме того, у него могут отсутствовать монитор и устройства ввода. В таком случае нужно воспользоваться другим компьютером, назовём его компьютером разработчика, который позволит организовать удалённое управление шлюзом и его настройку. Ниже мы будем рассматривать именно такой сценарий. Мы называем его удалённой установкой и удалённым исполнением команд. Для того, чтобы установить модуль PowerShell на шлюз с компьютера разработчика, эти две системы должны быть в одной и той же подсети. Кроме того, этот процесс включает в себя временное сопоставление сетевого диска на компьютере и шлюза. Итак, для удалённой установки модуля нужно выполнить следующие шаги. Для начала – вот список операций, которые нужно произвести на шлюзе для того, чтобы обеспечить удалённый доступ к PowerShell. Если на шлюзе установлена Windows IoT Core, то всё уже готово к работе, ничего больше делать не нужно. Если же шлюз оснащён Windows IoT Enterprise, нужно разрешить удалённое взаимодействие с PowerShell, используя эту и эту инструкции. Например, для того, чтобы включить удалённый доступ к PowerShell, воспользуйтесь нижеприведёнными командами. #Получим индекс NIC активного NIC Get-NetAdapter #$index – это полученный индекс. #Переключим целевое активное соединение в приватный режим. #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка. Set-NetConnectionProfile -InterfaceIndex $index ` -NetworkCategory Private #Включим удалённый доступ Enable-PSRemoting -Force Теперь, когда шлюз готов к работе, займёмся компьютером, выполнив следующие шаги с использованием окружения PowerShell. 1. Убедитесь в том, что две следующих учётных записи, созданные на соответствующих устройствах, имеют административные полномочия. А именно: Учётная запись для компьютера разработчика, с которой осуществлён вход в систему. Учётная запись на шлюзе, которой мы воспользуемся позже. 2. Запустите интерпретатор командной строки PowerShell от имени администратора. 3. Для того, чтобы запустить скрипт ModuleInstallation.ps1 нужно, чтобы в PowerShell использовалась политика выполнения скриптов AllSigned или RemoteSigned. Взгляните на следующие командлеты: Get-ExecutionPolicy и Set-ExecutionPolicy. Они позволяют, соответственно, узнавать и задавать политику выполнения. Например, с помощью такой команды можно задать использование политики RemoteSigned. Set-ExecutionPolicy RemoteSigned 4. Воспользуйтесь точечной нотацией при вызове скрипта ModuleInstallation.ps1. Для того, чтобы это сделать, введите символ точки «.» и пробел перед путём к запускаемому скрипту. Этот подход позволяет запустить скрипт в текущей области действия. . .\ModuleInstallation.ps1 5. Затем взгляните на справку по модулю, о котором мы здесь говорим, ознакомьтесь с примерами его использования. Для этого воспользуйтесь такой командой Get-Help Install-IntelIoTGatewaySetup –Full 6. Выполните команду Install-IntelIoTGatewaySetup для установки модуля с компьютера разработчика на шлюз. Правила использования этой команды можно найти в справочных материалах из предыдущего шага. Например, можно воспользоваться следующей последовательностью действий: #$path это путь к папке, в которой находится загруженный модуль, # например: ‘C:\IntelIoTGatewaySetup’ #$remoteip это IP-адрес удалённого шлюза, #например: ‘192.168.2.5’ #$remoteaccount это учётная запись на шлюзе, #например, ‘Tester’ или ‘Domain\Tester’ #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка. Install-IntelIoTGatewaySetup –ModuleLocalPath $path ` -RemoteGateway $remoteip ` -RemoteAccount $remoteaccount –Verbose Обратите внимание на то, что при локальной установке можно исполнить команду Install-IntelIoTGatewaySetup непосредственно на шлюзе. Для деинсталляции модуля предусмотрена команда Uninstall-IntelToTGatewaySetup. Подробности об этом можно найти в справочных материалах к модулю. 7. После установки воспользуйтесь PowerShell для выполнения команд нашего модуля на шлюзе. Об особенностях использования PowerShell на удалённых системах можно почитать здесь. Например, выполните, по порядку, нижеприведённые команды. Запустите службу WInRM, если она ещё не запущена. if ((Get-Service WinRM).Status.ToString() -ne 'Running') { # Запуск службы WinRM Write-Verbose "Start WinRM service." net start WinRM } Добавьте удалённый шлюз в список TrustedHosts. #Эта команда удалит исходный TrustedHosts и приведет к использованию $remoteip. #Кроме того, она может добавить новое значение к списку TrustedHosts. #Справку можно вызвать командой Get-Help Set-Item. #$remoteip это IP-адрес удалённого шлюза. #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка. Set-Item WSMan:\localhost\Client\TrustedHosts ` -Value $remoteip –Force Создайте удалённую сессию PowerShell на удалённом шлюзе. #$remoteip это IP-адрес удалённого шлюза. #$remoteaccount это учётная запись с административными полномочиями #на удалённом шлюзе. #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка. $s = New-PSSession -ComputerName $remoteip ` -Credential "localhost\$remoteaccount" Выполните эти команды на удалённом шлюзе. #Запустите удалённый скрипт для тестирования Invoke-Command -Session $s -ScriptBlock { #В этом блоке можете запустить желаемые команды PowerShell. #Эти команды будут запущены на удалённом шлюзе. #взглянем на сведения о нашем модуле Get-Command -Module IntelIoTGatewaySetup Get-Module IntelIoTGatewaySetup } Закройте удалённую сессию PowerShell после того, как выполните все необходимые команды. Remove-PSSession -Session $s Использование модуля Здесь мы, так же, как в предыдущем разделе, исходим из предположения, что для работы со шлюзом используется компьютер. Расскажем о том, как пользоваться модулем. Для начала, если вы этого ещё не сделали, включите использование удалённого PowerShell на шлюзе. Теперь, на компьютере разработчика, выполните следующие шаги. Воспользуйтесь той же процедурой, которая описана в п.7 предыдущего раздела. Все следующие примеры рассчитаны на то, что исполняемые на удалённом шлюзе команды будут помещены внутрь блока конструкции Invoke-Command. После установки модуля воспользуйтесь командой Get-Help с параметром –Full для того, чтобы узнать подробности о командах модуля. Например, выполните следующую команду для того, чтобы получить список всех команд, доступных в модуле: Get-Command -Module IntelIoTGatewaySetup Для настройки уровня безопасности служат команды Enable-IoTWinSecurities и Disable-IoTWinSecurities. Они, в свою очередь, вызывают другие команды модулей. Полезно будет взглянуть на справку по ним (Get-Help Enable-IoTWinSecurities –Full). Вот примеры работы с ними. Для того, чтобы включить базовый уровень безопасности («Basic» SKU) и задействовать приведённый в примере пароль восстановления BitLocker, выполните следующие команды. #$RecoveryPW это пароль восстановления для BitLocker, # который вы хотите использовать. #Например: $RecoveryPW = # '099825-222222-607607-626285-132319-115621-083204-229482' #В качестве разделителя в строке команды используется комбинация пробел + обратная галочка. Enable-IoTWinSecurities -SKU "Basic" ` -BitLockerRecoveryPW $RecoveryPW ` -AddPowerShellRemotingFirewallRule -ErrorLog –Verbose Взгляните на сообщения о результатах работы команд для того, чтобы выяснить, нет ли среди них предупреждений или сообщений об ошибках, которые касаются включаемых функций безопасности. Например, предупреждение может содержать рекомендацию о том, что сначала надо перезагрузить систему для того, чтобы завершить установку необходимых средств Windows, а потом снова выполнить команду установки. Для того, чтобы отключить / удалить настройки уровня безопасности, выполните следующую команду: Disable-IoTWinSecurities -ErrorLog -Verbose Отдельные команды, используемые в Enable-IoTWinSecurities и Disable-IoTWinSecurities, можно применять и самостоятельно, для настройки отдельных функций безопасности. Если TPM «не готов к использованию», его, сначала, нужно установить. В противном случае не получится включить BitLocker. Если AppLocker настроен в соответствии с высоким уровнем безопасности («High» SKU), пользователи не смогут использовать PowerShell для добавления новых функций Windows. В соответствии с архитектурой системы, файл DISMHOST.EXE, который используется PowerShell, находится во временной папке, в директории, соответствующей учётной записи пользователя, а этот файл окажется заблокированным. В результате пользователи не смогут использовать наши команды для включения VBS, так как эта команда попытается установить необходимую ей функцию Windows. При выполнении команды Enable-IoTWinSecurities мы сначала выполняем установку VBS. Если нужно установить функции Windows, выполните перезагрузку системы для того, чтобы завершить их установку, а затем снова запустите команду. Для функционирования системы User Mode Code Integrity нам нужно установить ключ реестра для того, чтобы разрешить размещению нашего модуля войти в режим Full Language Mode для Code Integrity Policy. В частности, рассматриваемый здесь модуль, по умолчанию, устанавливается по адресу %Program Files%\WindowsPowerShell\Module. Если это не так, соответствующий ключ реестра нужно настроить самостоятельно. Для этого нужно поместить путь, по которому установлен модуль (например, %Program Files%\WindowsPowerShell\Module) в запись типа REG_MULTI_SZ, которая называется «TestPath» и расположена в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\TRSData. Итоги Сегодня мы рассказали вам о новом средстве для настройки IoT-шлюзов Intel, которые работают под управлением Microsoft Windows. Рассмотренный здесь модуль для PowerShell, IntelIoTGatewaySetup, позволяет взаимодействовать со шлюзами как локально, так и удалённо, а собранные в нём команды помогают упростить и ускорить процедуры настройки шлюзов.

Что такое Code Contracts Code Contracts были созданы командой разработчиков из Microsoft Research в 2008 году. Задача Code Contracts описывать предположения о состоянии в коде, которые в последующем используются для проверки кода на корректность и генерации документации. Предполагалось что Code Contracts станут часть платформы .NET и получат поддержку в компиляторе, платформе и Visual Studio. К сожалению, поддержка появилась только в платформе в виде классов пространства имен System.Diagnostics.Contracts. Для остального требуются плагины и дополнительные утилиты. В данный момент проект поддерживает SergeyT и еще несколько участников. Поддержка Code Contracts в Mono Для проектов которые разрабатываются на Windows и .NET инфраструктура Code Contracts понятна и более менее развита. Есть Build Steps для MSBuild, можно переписывать/верифицировать сборки с помощью утилит, есть плагины для VS и Resharper. Но с Mono дела обстоят плачевно, есть самодельный ccrewrite, который ломается на сложном коде. Поддержки в xbuild и MonoDevelop нет и простым способом собрать проект нельзя. Причины для удаления Code Contracts из проекта — Внешняя зависимость проекта от утилит Code Contracts, без которых проект не собрать — Скорость компиляции ниже, из за дополнительного шага в виде перезаписи сборки — Отсутствие поддержки в Mono — Неудобств стало больше чем пользы Удаление Code Contracts из исходного кода Благодаря проекту Roslyn от Microsoft анализ и обработка исходного кода на C#/VB.NET стало довольно тривиальной задачей. И я выбрал этот путь для удаления Code Contracts из исходного кода. Само решение довольно простое и состоит из CSharpSyntaxRewriter, который пробегает по коду и заменяет проверки Code Contracts на их эквивалент вне Code Contracts. Сам удалитель Code Contract'ов оформлен в виде пакета Nuget и доступен как утилита и работает под Mono. Install-Package CodeContractsRemover И команда на перезапись всех исходников в директории проекта: # code_contracts_remover.exe <Convert|Remove> <directoryPath> > Если вы не хотите попрощаться с контрактами навсегда, то вы можете использовать данную утилиту как шаг сборки на вашем билд сервере. Ссылки Проект на GitHub Nuget пакет
Уникальный ЦОД Finger Lakes Technologies Group внутри ядерного хранилища

Три чукотских мудреца Твердят, твердят мне без конца, Мол, PoSh не принесет плода, Игра не стоит свеч, А результат — труда. Но я сажаю powershell'овские огрурцы, а-а-а, На DotNet'овском поле... Те, кто довольно часто общается с WinDbg, знают о команде !vadump, отображающей весь диапазон виртуальной памяти процесса с соответствующими уровнями защиты, — более подробную информацию можно почерпнуть в руководстве WinDbg. В сущности данное расширение всего лишь обертка над апишной функцией VirtualQueryEx, которая в свою очередь задействует Native API, а именно NtQueryVirtualMemory — и так далее. Впрочем, если не лезть в дебри, а также учитывая опыт использования рефлексии в купе с обобщенными делегатами, можно вполне написать !vadump на PowerShell самостоятельно. И если кто-то сейчас захотел открыть свой васистдас и сказать, дескать, на кол оно нужно, то для начала задайтесь вопросом: а для чего, собственно, вообще все делается? Что нам понадобится? GetSystemInfo, OpenProcess, VirtualQueryEx, — это что касается WinAPI. CloseHandle для OpenProcess не нужен, так как возвращаемый тип вызываемой рефлекторно OpenProcess — SafeProcessHandle, следовательно, Dispose и Close нам в руки. Для начала получим указатель на так называемый старший адрес памяти, доступный приложениям и dll'кам. $GetSystemInfo = [Object].Assembly.GetType( 'Microsoft.Win32.Win32Native' ).GetMethod( 'GetSystemInfo', [Reflection.BindingFlags]40 ) $si = [Activator]::CreateInstance([Object].Assembly.GetType( ($GetSystemInfo.GetParameters() | ForEach-Object { $_.ParameterType.FullName.Trim('&') }) )) $si — это структура SYSTEM_INFO. $GetSystemInfo.Invoke($null, ($par = [Object[]]@($si))) $max = $par[0].GetType().GetField( 'lpMaximumApplicationAddress', [Reflection.BindingFlags]36 ).GetValue($par[0]) $max — это и есть искомый указатель. Получаем хэндл процесса (относительно ID): $OpenProcess = [Regex].Assembly.GetType( 'Microsoft.Win32.NativeMethods' ).GetMethod('OpenProcess') if (($sph = $OpenProcess.Invoke($null, @(0x400, $false, $Id))).IsInvalid) { break } $ptr = $sph.DangerousGetHandle() VirtualQueryEx вызываем посредством обобщенного делегата Func: $VirtualQueryEx = Set-Delegate kernel32 VirtualQueryEx ` '[Func[IntPtr, IntPtr, [Byte[]], UInt32, Int32]]' $mbi = New-Object Byte[] 28 #MEMORY_BASIC_INFORMATION if ($VirtualQueryEx.Invoke($ptr, [IntPtr]::Zero, $mbi, $mbi.Length)) ForEach-Object $$ = [BitConverter]::ToUint32($bytes[8..11], 0){ if (($$ -band $MEM_PROTECT[$_]) -eq $MEM_PROTECT[$_]) {$_} }) -join ', ' ) RegionSize = [BitConverter]::ToUInt32($bytes[12..15], 0) State = ( ($MEM_STATE.Keys | ForEach-Object { $$ = [BitConverter]::ToUInt32($bytes[16..19], 0) }{ if (($$ -band $MEM_STATE[$_]) -eq $MEM_STATE[$_]) {$_} }) -join ', ' ) Protect = ( ($MEM_PROTECT.Keys | ForEach-Object { $$ = [BitConverter]::ToUInt32($bytes[20..23], 0) }{ if (($$ -band $MEM_PROTECT[$_]) -eq $MEM_PROTECT[$_]) {$_} }) -join ', ' ) Type = ( ($MEM_TYPE.Keys | ForEach-Object { $$ = [BitConverter]::ToUInt32($bytes[24..27], 0) }{ if (($$ -band $MEM_TYPE[$_]) -eq $MEM_TYPE[$_]) {$_} }) -join ', ' ) } | Select-Object 0x{0:X8}' -f $_.BaseAddress }}, 0x{0:X8}' -f $_.AllocationBase }}, AllocationProtect, 0x{0:X8}' -f $_.RegionSize }}, State, Protect, Type } Где $MEM_PROTECT, $MEM_STATE и $MEM_TYPE: $MEM_PROTECT = @{ PAGE_NOACCESS = 0x00000001 PAGE_READONLY = 0x00000002 PAGE_READWRITE = 0x00000004 PAGE_WRITECOPY = 0x00000008 PAGE_EXECUTE = 0x00000010 PAGE_EXECUTE_READ = 0x00000020 PAGE_EXECUTE_READWRITE = 0x00000040 PAGE_EXECUTE_WRITECOPY = 0x00000080 PAGE_GUARD = 0x00000100 PAGE_NOCACHE = 0x00000200 PAGE_WRITECOMBINE = 0x00000400 } $MEM_STATE = @{ MEM_COMMIT = 0x00001000 MEM_RESERVE = 0x00002000 MEM_FREE = 0x00010000 } $MEM_TYPE = @{ MEM_PRIVATE = 0x00020000 MEM_MAPPED = 0x00040000 MEM_IMAGE = 0x01000000 } Пример того, как будет выглядеть вывод для некоторого процесса: BaseAddress AllocationBase AllocationProtect RegionSize State Protect Type ----------- -------------- ----------------- ---------- ----- ------- ---- 0x00000000 0x00000000 0x00010000 MEM_FREE PAGE_NOACCESS 0x00010000 0x00010000 PAGE_READWRITE 0x00001000 MEM_COMMIT PAGE_READWRITE MEM_PRIVATE 0x00011000 0x00000000 0x0000F000 MEM_FREE PAGE_NOACCESS 0x00020000 0x00020000 PAGE_READWRITE 0x00001000 MEM_COMMIT PAGE_READWRITE MEM_PRIVATE 0x00021000 0x00000000 0x0000F000 MEM_FREE PAGE_NOACCESS 0x00030000 0x00030000 PAGE_READWRITE 0x000F2000 MEM_RESERVE MEM_PRIVATE 0x00122000 0x00030000 PAGE_READWRITE 0x00001000 MEM_COMMIT PAGE_READWRITE, PAGE_GUARD MEM_PRIVATE 0x00123000 0x00030000 PAGE_READWRITE 0x0000D000 MEM_COMMIT PAGE_READWRITE MEM_PRIVATE ... Если не пихать предварительно данные в итоговый массив для последующего форматирования, сценарий будет работать, понятное дело, быстрее. Еще быстрее — если написать командлет целиком на C#, чай, отправная точка есть, так что дело за малым.
[Из песочницы] Relinx — ещё одна реализация .NET LINQ методов на C++, с поддержкой «ленивых вычислений»