Записи Друзья Комментарии
kopusouthb
Аватар kopusouthb

 -Поиск по дневнику

Поиск сообщений в kopusouthb

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 10.12.2014
Записей:
Комментариев:
Написано: 96

Дневник kopusouthb






Нравится

Вот тебе, бабушка, и неймспейсы
Пятница, 06 Января 2017 г. 07:38 + в цитатник
Опыт использования пространств имён в клиентском XHTML Текст Ростислава Чебыкина. Я вам посылку принёс. Только я вам её не отдам, потому что у вас документов нету. Почтальон ПечкинМы вместе с Денисом Лесновым разрабатываем аудиопроигрыватель для сайта, о котором уже рассказывали здесь в 2015 году. Сейчас на подходе обновлённая версия, которая умеет играть не только отдельные треки, но и целые плейлисты. В этой статье пойдёт речь не о самoм проигрывателе, а о неожиданных феноменах, с которыми мы столкнулись, попытавшись использовать настоящий XHTML. • Основная цель нашего проекта — получить удовольствие от совместного программирования. Поэтому мы пишем код так, как нам нравится, и используем технологии, которые нам интересны. Мне, например, был интересен XHTML ещё с тех пор, как Консорциум W3C опубликовал первые черновики этого стандарта, и многочисленные энтузиасты бросились пропагандировать обновлённый язык. Тогда многие надеялись, что весь Интернет вот-вот перейдёт на XML-совместимую разметку, и от этого наступит всеобщее счастье. На моём собственном сайте веб-страницы всегда соответствовали синтаксису XHTML и отдавались с типом application/xhtml+xml тем браузерам, которые его поддерживали. Несколько лет назад я вообще перестал отдавать text/html. К нынешнему времени шумиха вокруг XHTML улеглась, соответствующая рабочая группа Консорциума закрылась после нескольких лет прострации, а тогдашние энтузиасты переключились на другие модные концепции. Мне жаль, что многие перспективные идеи XHTML 2.0 так не внедрились в широкую практику. Например, тот стандарт предлагал, чтобы любой элемент можно было превратить в гиперссылку, присвоив ему атрибут href: <li href="/about/">О компании</li> <li href="/contacts/">Контакты</li> Увы, это не воплотилось в жизнь, так что для канонических идиом веб-интерфейсов типа «кликабельной» картинки приходится по сей день использовать отдельно элемент img и отдельно элемент a, как в начале 1990-х. • Может быть, XHTML «не взлетел» потому, что энтузиастам так и не удалось продемонстрировать его практические преимущества. На фанатских сайтах код XHTML носил чисто косметический характер и не содержал ничего такого, чего не обеспечивал бы обычный HTML. Наоборот, XHTML ограничивал разработчиков старой школы, не давая использовать любимый document.write и заставляя явно вставлять tbody в каждую таблицу. В 2016 году я наконец решил попробовать эндемичные возможности XHTML, а именно пространства имён. Мне хотелось, чтобы компоненты аудиопроигрывателя были самодельными элементами, находящимися в собственном неймспейсе: Как положено, пространство имён и его префикс объявлены в открывающем тэге html: <html xml:> Внедрение самодельных элементов в код не вызвало никаких проблем, но и пользы само по себе не принесло. Польза должна была наступить после того, как эти элементы примут внешний вид с помощью CSS и оживут благодаря JavaScript. И тут-то начались загвоздки. • Во-первых, ещё на этапе первичного тестирования идеи выяснилось, что у самодельных элементов не работает атрибут style: <p:track > Соответствующий атрибут появляется в дереве DOM, но фон элемента на странице не окрашивается в указанный цвет. Зато при подключении отдельной таблицы стилей (во внешнем файле или в элементе style) CSS успешно действует, и самодельные элементы оформляются с помощью селектора пространства имён: p|track { background: #999; } Правда, чтобы это работало, первым правилом в таблице стилей должно идти объявление @namespace: @namespace p url('http://rostislav.chebykin.ru/xmlns'); Таким образом удалось поскрасить track в нужный цвет и придать элементу playhead круглую форму. Но это ещё не обеспечивало динамики, в которой состоит суть интерфейса проигрывателя. И эта динамика завела нас в дебри. • Для работы с пространствами имён в DOM есть методы createElementNS и getElementsByTagNameNS. Их поведение местами сбивает меня с толку: например, селектор p|track действует на элемент независимо от того, указан ли префикс пространства имён во втором аргументе createElementNS: const ns = 'http://rostislav.chebykin.ru/xmlns'; document.createElementNS(ns, 'p:track'); document.createElementNS(ns, 'track'); // на этот элемент тоже действует селектор p|track А вот getElementsByTagNameNS хочет получить имя строго без префикса, независимо от того, каким из двух способов был создан элемент: document.getElementsByTagNameNS(ns, 'track'); // возвращает HTMLCollection с обоими элементами document.getElementsByTagNameNS(ns, 'p:track'); // возвращает пустой HTMLCollection Но это всё ещё не беда. Беда началась дальше, когда мы попробовали анимировать всю эту конструкцию через JS. • Двигать головку проигрывателя — казалось бы, что может быть проще? Получать нужную позицию, преобразовывать её в проценты и присваивать свойству left: playhead.style.left = pos; (Здесь переменная playhead указывает на нужный элемент в DOM, а pos — процентная строка в формате CSS, типа '12.34%'). Но нет! Оказывается, у playhead нет свойства style. Чтобы разобраться, почему так случилось, сравним цепочку прототипов playhead с цепочкой какого-нибудь стандартного элемента HTML: playhead: Element < Node < EventTarget < Object div: HTMLDivElement < HTMLElement < Element < Node < EventTarget < Object Свойство style, предоставляющее доступ к свойствам CSS того или иного элемента, определено в интерфейсе HTMLElement и отсутствует у его родителя Element. Пытаясь перенести «родной» style от HTMLElement к самодельным элементам, мы потерпели поражение. Даже если просто ввести в консоли HTMLElement.prototype.style, выпадает сообщение об ошибке, и тем более с этим свойством не получается сделать ничего содержательного. Пришлось исхитряться через CSS Object Model: динамически подключать внешний CSS, добираться до его правил, у которых есть то самое свойство style, и гвоздями прибивать этот style к соответствующим элементам: const link = document.createElement('link'); // затем присваиваем link’у нужные атрибуты // и вставляем в head playhead.style = link.sheet.cssRules.item(1).style После этого конструкции вроде playhead.style.left = pos; начали работать… везде, кроме Safari. Неожиданно выяснилось, что в этом экстравагантном браузере свойство style всё-таки есть у Element.prototype, и дескрипторы этого свойства не позволяют ничего ему присваивать. Проблема решилась переопределением style персонально для наших элементов: Object.defineProperty(playhead, 'style', { writable: true }); • Наконец, отдельной неожиданностью стало то, как с пространствами имён обходятся методы querySelector, querySelectorAll и matches, принимающие в качестве аргументов селекторы CSS, например: document.querySelectorAll('p|track'); playhead.matches('p|playhead'); Здесь каждый браузер нашёл свои собственные слова, чтобы выразить недоумение: Edge NamespaceError Chrome Uncaught DOMException: Failed to execute 'matches' on 'Element': 'p|playhead' is not a valid selector Firefox SyntaxError: An invalid or illegal string was specified Safari NamespaceError (DOM Exception 14): The operation is not allowed by Namespaces in XML Причина в том, что перечисленные методы не могут разрулить префикс p и связать его с соответствующим пространством имён. В XHTML для объявления неймспейсов есть атрибут xmlns, в CSS — @namespace, а в JavaScript — опа! — ничего нет. Что характерно, в браузерах работает метод document.createNSResolver, однако его результат никак не прикручивается к методам типа querySelectorAll. В Selectors API сказано, что «namespace prefix needs to be resolved», однако тут же приписано: «This specification does not provide support for resolving arbitrary namespace prefixes». Интересно, что в черновых версиях спецификации был интерфейс NSResolver и предлагался соответствующий аргумент в «селекторных» методах: Element querySelector(in DOMString selectors, in NSResolver nsresolver); Однако по пути к рекомендации W3C NSResolver был злодейски выпилен, и в результате спецификация ведёт себя, как почтальон Печкин: «Я вам посылку принёс, только я вам её не отдам, потому что у вас документов нету». Я не удивлюсь, если через несколько лет Консорциум объявит язык XHTML deprecated и obsolete, а браузеры откажутся от поддержки application/xhtml+xml. Надеюсь, что до этого времени нам с Денисом удастся закончить очередную версию аудиопроигрывателя, чтобы она сохранилась в Интернете хотя бы как музейный экспонат.

Метки:  
Нравится

Domain-Driven Design: тактическое проектирование. Часть 2
Среда, 07 Декабря 2016 г. 01:40 + в цитатник
Здравствуйте, уважаемые хабрапользователи! В предыдущей статье мы рассмотрели стратегическое моделирование с помощью подхода DDD. В ней было показано, как выделять концептуальные границы, в рамках которых решаются отдельные задачи предметной области – ограниченные контексты. Для реализации конкретного ограниченного контекста используется ряд более низкоуровневых тактических шаблонов, которые имеют технический характер, то есть эти шаблоны используются для решения технических задач. Такими шаблонами являются: сущность, объект-значение, службы предметной области, события, модули, агрегаты, фабрики и хранилища. Именно о них пойдет речь в этой статье. Важно понимать, что при правильном проектировании, посредством этих шаблонов выражается единый язык в явном ограниченном контексте. Модель программного обеспечения должна полностью демонстрировать богатство единого языка в контексте. Если понятие не выражается с помощью единого языка, то оно не должно быть представлено в модели. Если проектирование осуществляется с помощью тактических шаблонов, не обращая внимания на единый язык, это значит, что используется облегченный DDD-подход. Традиционно, начиная с книги Э.Эванса, первым рассматривается шаблон DDD – сущность. Сущность (Entity) Если какое-то понятие предметной области является уникальным и отличным от всех других объектов в системе, то для его моделирования используется сущность. Такие объекты-сущности могут сильно отличаться своей формой за весь цикл существования, тем не менее их всегда можно однозначно идентифицировать и найти по запросу. Для этого используются уникальные идентификаторы, создание которых необходимо продумать в первую очередь при проектировании сущности. Есть несколько стратегий создания идентификаторов: Ввод пользователем уникального значения Такой подход необходимо использовать, если идентификаторы в приложении должны быть удобочитаемыми. Тем не менее, необходимо обеспечить проверку идентификатора на правильность и уникальность в самом приложении. Часто стоимость изменений идентификатора высока, и пользователи не должны изменять их. Поэтому нужно использовать методы, которые будут гарантировать качество этого идентификатора. Идентификатор генерируется приложением Существуют быстрые и высоконадежные генераторы, которые можно использовать в приложениях для автоматического создания уникального идентификатора. Например, в среде Java существует класс java.util.UUID, который позволяет генерировать так называемый универсально уникальный идентификатор (universally unique identifier) четырьмя различными способами (time-based, DCE security, name-based, randomly generated UUIDs). Примером такого UUID является: 046b6c7f-0b8a-43b9-b35d-6489e6daee91. То есть 36 байтовая строка. Такие большие идентификаторы невыгодно хранить из-за перегрузки памяти. В зависимости от уровня доверия к уникальности отдельных сегментов шестнадцатеричного текста идентификатора UUID, можно использовать один или несколько сегментов целого идентификатора. Сокращенный идентификатор лучше защищен, если используется как локальный идентификатор сущностей в границе агрегата. Для примера можно рассмотреть такой идентификатор: APM-P-08-14-2016-046B6C7F. Здесь: АPM – отдельный контекст управления проектированием; P – проект; 08-14-2016 – дата создания; 046B6C7F- – первый сегмент UUID. Когда такие идентификаторы попадаются в различных ограниченных контекстах, разработчики сразу видят, откуда они появились. Идентификатор генерируется механизмом постоянного хранения Для создания идентификатора можно обращаться к базе данных. Таким образом можно быть уверенным, что точно вернется уникальное значение. При этом оно будет достаточно коротким и его можно будет также использовать для составного идентификатора. Недостатком такого подхода является производительность. Обращение к базе данных за каждым значением может отнять намного больше времени, чем генерирование идентификаторов в приложении. Идентификаторы, которые присваиваются другими ограниченными контекстами Возможно, что для получения идентификатора необходимо интегрировать различные ограниченные контексты (например, с помощью карт контекстов, как было показано в предыдущей статье). Чтобы найти определенный идентификатор в другом ограниченном контексте, можно для примера указать некоторое количество атрибутов (е-мейл, номер счета), которые дадут возможность определить уникальный идентификатор внешней сущности, который можно использовать в качестве локального идентификатора. Из внешней сущности в локальную сущность можно также скопировать некоторое дополнительное состояние (свойство). Для сущности, обычно, кроме основного идентификатора предметной области, используется суррогатный идентификатор. Первый подчиняется требованиям предметной области, а второй предназначен уже для самого инструмента ORM (как Hibernate). Для создания суррогатного ключа обычно создается атрибут сущности типа long или int, в базе данных создается уникальный идентификатор, и он используется как первичный ключ. Потом включается отображение этого ключа в атрибут с помощью инструментов ORM. Такой суррогатный идентификатор обычно скрывают от внешнего мира, так как он не является частью модели предметной области. Еще важно сказать, что для сохранения уникальности на протяжении существования объекта, его идентификатор необходимо защитить от модификации. Это делается в основном путем скрытия методов-установщиков идентификаторов, либо созданием проверок изменения состояния в методах-установщиках для запрещения таких изменений. Для примера можно рассмотреть ту же систему PFM, что и в предыдущей статье. Для начала необходимо выделить сущности в предметной области. Совершенно очевидно, что существует сущность BankingAccount, и для ее идентификации напрашивается использование номера счета accountNumber. Тем не менее этот номер уникальный только в отдельном банке и может повторятся в других банках. (Можно использовать номер IBAN, но этот номер в основном используется только в банках Европейского союза.) То есть помимо номера счета еще можно использовать сегмент UUID. Тогда наш идентификатор будет состоять из PFM-A-424214343245-046b6c7f, где: PFM – имя контекста A – Account 424214343245 – номер счета accountnumber 046b6c7f – часть из UUID Идентификатор можно задать как объект-значение. Необходимо детально рассмотреть этот очень важный шаблон DDD. Объект-Значение (Value Object) Если для объекта не важна индивидуальность, если он полностью определяется своими атрибутами, его следует считать объектом-значением. Чтобы выяснить, является ли какое-то понятие значением, необходимо выяснить, обладает ли оно большинством из следующих характеристик: Оно измеряет, оценивает или описывает объект предметной области; Его можно считать неизменяемым; Оно моделирует нечто концептуально целостное, объединяя связанные атрибуты в одно целое; При изменении способа измерения или описания его можно полностью заменить; Его можно сравнивать с другими объектами с помощью отношения равенства значений; Оно предоставляет связанным с ним объектам функцию без побочных эффектов. Необходимо сказать, что такого рода объекты должны встречаться намного чаще, чем кажется на первый взгляд. Их легче создавать, тестировать и поддерживать, поэтому нужно стараться использовать объекты-значения вместо сущностей, где это возможно. Очень редко объекты-значения делаются изменяемыми. Чтобы запретить доступ к полям, обычно методы установщики (setters) делают приватными, а публичным делают конструктор объекта, в который передаются все объекты, которые являются атрибутами значения. Создание объекта-значения должно быть атомарной операцией. Для объекта-значения очень важно определять операцию проверки равенства. Чтобы два объекта-значения были равны, необходимо, чтобы все типы и значения атрибутов были равны. Также очень важно сказать, что все методы объекта-значения должны быть функциями без побочных эффектов. Так как они не должны нарушать свойство неизменяемости, они могут возвращать объекты, но не могут изменять состояние объекта. Рассмотрим классический пример объекта значения денежная сумма (во многих примерах в интернете встречается этот класс): public class Money implements Serializable { private BigDecimal amount; private String currency; public Money (BigDecimal anAmount, String aCurrency) { this.setAmount(anAmount); this.setCurrency(aCurrency); } … } Методы установщики здесь делаются скрытыми, создание объекта значения – атомарная операция. Примером конкретного значения есть {50 000 долларов}. По отдельности эти атрибуты либо описывают что-то другое, либо ничего конкретного не означают. Особенно это относится к числу 50000 и в некоторой степени к долларам. То есть эти атрибуты образует концептуально целое значение, которое описывает денежную сумму. Такая целостность концепции в предметной области играет очень большую роль. Важно понимать, что именуются типы значений и сами значения в соответствии с единым языком в своем ограниченном контексте. Давайте перейдем к следующему важному шаблону тактического моделирования. Служба Предметной Области (Domain Service) Используя единый язык, существительные этого языка отражаются в объекты, а глаголы отражаются в поведения этих объектов. Очень часто существуют глаголы или какие-то действия, которые нельзя отнести к какой-то сущности или к какому-то объекту-значению. Если существует такого рода операция в предметной области, ее объявляют как служба предметной области (она отличается от прикладной службы, которая является клиентом). Есть три характеристики служб: Операция, выполняемая службой, относится к концепции предметной области, которая не принадлежит ни одной из существующих сущностей; Операция выполняется над различными объектами модели предметной области; Операция не имеет состояния. Не нужно злоупотреблять использованием служб. Это приводит к созданию анемичной модели предметной области. Бизнес логика должна быть распределена по сущностям и значениям. Только если это невозможно сделать следуя единому языку, тогда нужно использовать службу предметной области. Главное, чтобы ее интерфейс точно отражал единый язык. Для примера можно взять службу перевода денег с одного счета плательщика в счет получателя. Совершенно неясно, в каком объекте хранить метод перевода, поэтому используется служба: Событие (Domain Entity) Изучая предметную область, встречаются факты, которые имеют особую важность для экспертов в предметной области. Например от экспертов можно услышать такие ключевые фразы: «Когда… » «Если это случится… » «Сообщите мне, если… » или «уведомьте меня, если… » «В случае… » То есть, если что-то должно произойти как следствие другого отдельного действия, скорее всего необходимо моделирование определенного события предметной области. При моделировании необходимо учитывать, что событие – это то, что случилось в прошедшем времени. Поэтому имя события отражает прошлое время, при этом само имя должно присваиваться в соответствии с единым языком в ограниченном контексте. Событие очень часто проектируется неизменяемым, так же, как и объекты-значения, их функции – функции без побочных эффектов. Событие моделируется как объект, интерфейс которого выражает его предназначение, а свойства отражают его причину. Для примера можно рассмотреть событие FundsDeposited: occuredOn – это временная метка события. Далее необходимо указать важные свойства, которые несут информацию о том, что произошло. Важным свойством является идентификатор сущности или агрегата, в котором генерируется событие (accountId). Также возможно для подписчиков важными окажутся некоторые параметры перехода агрегата с одного состояния в другое. В данном случае, моделируется событие, которое происходит, когда осуществляется зачисление денежных средств на определенный счет. В результате, можно отправить СМС о зачислении, отправить почту или выполнить другую операцию. Для того, чтобы события можно было публиковать, и, чтобы их можно было обрабатывать, можно использовать шаблон наблюдатель (Observer), или издатель-подписчик. Если событие обрабатывается в рамках одного ограниченного контекста, то можно не использовать различные инфраструктурные компоненты (они не должны существовать в рамках модели предметной области), а можно добавить просто реализацию шаблона набдюдатель в модель. Таким образом, достаточно создать объект DomainEventPublisher, который будет хранить, регистрировать всех подписчиков и публиковать событие. При этом публикация для подписчиков будет идти синхронно в отдельном цикле и в одной транзакции. И каждый подписчик сможет отработать событие отдельно. Важно подчеркнуть, что событие предметной области – это концепция масштаба предметной области, а не отдельного ограниченного контекста. Поэтому можно осуществлять асинхронную пересылку событий во внешние ограниченные контексты с помощью инфраструктуры обмена сообщений. Существует много компонентов для передачи сообщений, которые относятся к классу промежуточного программного обеспечения (например, RabbitMQ, NServiceBus). Можно также сделать обмен сообщениями с помощью ресурсов REST, где автономные системы обращаются к издательской системе, требуя уведомления о событиях, которые еще не были обработаны. Подход RESTful к публикации уведомлений о событии является противоположностью публикации с помощью типичной инфраструктуры обмена сообщениями. «Издатель» не поддерживает ряд зарегистрированных «подписчиков», потому что заинтересованным сторонам ничего не рассылается. Вместо этого подход требует, чтобы клиенты REST сами запрашивали уведомления, используя ресурс URI. Важно понимать, что необходимо добиваться согласованности между тем, что публикует инфраструктура обмена сообщениями и между актуальным состоянием в модели предметной области. Необходимо гарантировать доставку события, и, чтобы это событие отражало бы истинную ситуацию в модели, в которой оно было опубликовано. Есть различные способы добиться такой согласованности. Чаще всего используют метод, при котором используется хранилище событий в рамках ограниченного контекста. Это хранилище используется моделью предметной области и при этом оно используется внешним компонентом, которое публикует неопубликованные события с помощью механизма передачи сообщений. Но при этом подходе клиентам необходимо выполнять дедубликацию входящих сообщений, для того чтобы при повторной отправке того же события клиенты правильно его обрабатывали В обоих случаях – когда подписчики используют промежуточное программное обеспечение для обмена сообщениями, или когда клиенты уведомлений используют REST – важно, чтобы отслеживание идентификационных данных обработанных сообщений фиксировались вместе с любыми изменениями в локальном состоянии модели предметной области. Давайте рассмотрим следующий шаблон DDD. Модуль (Module) Модули внутри модели являются именованными контейнерами для некоторой группы объектов предметной области, тесно связанных друг с другом. Их цель – ослабление связей между классами, которые находятся в различных модулях. Так как модули в подходе DDD – это неформальные или обобщенные разделы, их следует правильно называть. Выбор их имен является функцией единого языка. Проектировать необходимо слабосвязанные модули, что облегчает поддержку и рефакторинг концепций моделирования. Если связанность необходима, то нужно бороться за ациклические зависимости между одноранговыми модулями (одноранговыми называются модули, которые расположены на одном и том же уровне или которые имеют одинаковый вес в проекте). Модули лучше не делать статичными концепциями модели, так как они должны изменяться в зависимости от тех объектов, которые они организовывают. Есть определенные правила именования модулей. Имена модулей (во многих языках программирования) отображают их иерархическую форму организации. Иерархия имен обычно начинается с доменного имени организации, которая разрабатывает модуль (чтобы избежать конфликтов). Например: com.bankingsystems Следующий сегмент имени модуля идентифицирует ограниченный контекст. Желательно, чтобы имя этого сегмента основывалось на имени ограниченного контекста: com.bankingsystes.pfm Далее следует квалификатор, который идентифицирует модуль именно предметной области: com.bankingsystems.pfm.domain Все модули модели можно поместить именно в этом разделе domain. Вот так: com.bankingsystems.pfm.domain.account <<Entity>>BankingAccount <<ValueObject>>AccountId В известной всем многоуровневой архитектуре именование было бы таким: сom.bankingsystems.resources сom.bankingsystems.resources.view – уровень пользовательского интерфейса (хранение представлений) сom.bankingsystems.application сom.bankingsystems.application.account – прикладной уровень (подмодуль прикладных сервисов) Модули используются для агрегации связанных объектов предметной области и отделены от объектов, которые не являются связанными или являются слабо связанными. Ограниченные контексты часто охватывают несколько модулей, потому что обычно сначала объединяют все концепции в одной модели, если не существует четких границ контекстов. Агрегат (Aggregate) Агрегат является самым сложным из всех тактических инструментов DDD. Агрегатом называется кластер из объектов сущностей или значений. То есть эти объекты рассматриваются как единое целое с точки зрения изменения данных. У каждого агрегата есть корень (Aggregate Root) и граница, внутри которой всегда должны быть удовлетворены инварианты. Все обращения к агрегату должны осуществляться через его корень, который представляет собой сущность с глобально уникальным идентификатором. Все внутренние объекты агрегата имеют только локальную идентичность, они могут ссылаться друг на друга как угодно. Внешние объекты могут хранить только ссылку на корень, а не на внутренние объекты. Инвариант – это бизнес-правило, которое всегда сохраняет свою непротиворечивость. Это явление называется транзакционной согласованностью, которая является атомарной. Есть еще и итоговая согласованность. В случае инвариантов, речь идет о транзакционной согласованности. Агрегатом также можно называть границу транзакционной согласованности, внутри которой выполняются инвариантные правила, независимо от того, какие именно операции при этом выполняются. Пытаясь выявить агрегаты в ограниченном контексте, необходимо анализировать истинные инварианты модели, чтобы определить, какие именно объекты нужно объединить в агрегат. Также при проектировании агрегатов необходимо учитывать, что крупнокластерные агрегаты проигрывают небольшим агрегатам в производительности и в масштабируемости. Чтобы загрузить большой агрегат, необходимо больше памяти. Более мелкие агрегаты не только быстрее работают, но и способствуют успеху транзакций. Также важно сказать, что внутри агрегата лучше использовать внутри объекты-значения, а не сущности. Как было указано выше, их проще поддерживать, тестировать и т.д. Каждый агрегат может хранить ссылку как корни других агрегатов. При этом это не помещает этот агрегат в границы согласованности первого агрегата. Ссылка не порождает целостный агрегат. В рамках одной транзакции в ограниченном контексте должно происходить изменение только одного агрегата. Ссылки лучше делать по глобальным идентификаторам корня агрегата, а не храня прямые ссылки как объекты (или указатели). Таким образом: уменьшается память объектов; они быстрее загружаются; их легче масштабировать. Если запрос клиента влияет на несколько агрегатов, необходимо использовать принцип итоговой согласованности. Итоговую согласованность можно достичь с помощью публикаций событий предметной области. То есть, после изменения одного агрегата, он публикует событие, и далее на одном или нескольких других агрегатах выполняются действия, которые приводят к согласованности в системе. В качестве примера агрегата можно привести кредитный отчет: Каждый кредитный отчет должен содержать данные об идентификационных данных заемщика. Для этого мы сохраняем внешнюю связь по идентификатору сustomerId. Сustomer – совершенно другой агрегат, который содержит информацию о заемщике (имя, адрес, контакты). Инвариантом, допустим, будет правило пересчета кредитного рейтинга – в зависимости от данных кредитной истории. Совершенно неважно, как именно он пересчитывается, главное, – чтобы выполнялась транзакционная согласованность внутри агрегата. Например, после добавления или замены записи кредитной истории, показатель кредитного рейтинга должен сразу же пересчитаться. Это должна быть атомарная операция. Если используется база данных, должна быть отдельная транзакция. Сразу после внесения данных в объекты внутри агрегата, должны выполняться все инварианты. Inquiry – определенный запрос на кредитный отчет со стороны других организаций. Корень агрегата является сущностью. Он имеет глобальную идентичность. Если необходимо будет ссылаться на этот агрегат, можно будет использовать только идентификатор корня. При удалении агрегата отчета, должны удаляться все значения – записи об истории и запросах. Фабрика (Factory) Шаблон фабрика является более известным, чем другие. Некоторые агрегаты или сущности могут быть достаточно сложными. Сложный объект не может создавать сам себя посредством конструктора. (В книге Эрика Эванса был приведен пример: двигатель автомобиля, который собирается либо механиком, либо роботом, но он никак не должен собираться сам по себе.) Еще хуже, когда передают создание сложного объекта на клиент. Так, клиент должен знать о внутренней структуре и взаимосвязях внутри объекта. Это нарушает инкапсуляцию и привязывает клиента к определенной реализации (таким образом, при изменении объекта придется менять и реализацию клиента). Лучше выполнять создание сложных агрегатов или других объектов отдельно. Для этого используются фабрики. Фабрики – элементы программы, обязанности которого создавать другие объекты. Чаще всего фабрики проектируются как фабричный метод в корне агрегата. Фабричный метод еще выгоден тем, что с его помощью можно выразить единый язык (конструктор же не выражает это). При создании фабричного метода в корне агрегата обязательно необходимо соблюдать все инварианты агрегата, создавая его как единое целое. Этот метод должен быть един и неделим. Все данные для создания (обычно только объекты-значения) должны быть переданы за одну коммуникационную операцию. Детали конструкции скрываются. Объекты-значения и сущности создаются по-разному: так как значения неизменяемы, все атрибуты должны передаваться сразу при создании. А в сущность можно добавлять только те, которые важны для создания конкретного агрегата и его инвариантов. Хранилища (Repository) Хранилищем называется область памяти, которая предназначена для безопасного хранения помещенных в нее элементов. Именно этим является предметно-ориентированное хранилище. Хранилище используется для агрегатов. Помещая агрегат в соответствующее хранилище, а затем извлекая его оттуда, вы получаете целостный объект. Если агрегат будет изменен, то изменения будут сохранены. Если агрегат будет удален, то его уже нельзя будет извлечь. Каждый агрегат, предполагающий постоянное хранение, имеет свое хранилище. Зачастую в хранилище реализуются методы для выборки полностью сгенерированных агрегатов по каким-то критериям. Есть два типа проектов хранилищ: Ориентированные на имитацию коллекций; Ориентированные на механизм постоянного хранения. Хранилища, ориентированные на имитацию коллекций, очень точно имитируют коллекцию, моделируя по крайней мере часть ее интерфейса. Сам интерфейс хранилища, в этом случае, не выдает существования механизма постоянного хранения, тем самым представляя традиционный, исходный шаблон DDD. Представить такое хранилище можно как HashSet<ObjectId,Object>. В этой коллекции исключается повторная вставка одного и того же элемента. При этом, получая и изменяя объект, изменения фиксируются сразу. Хоть клиенту и не нужно вмешиваться в работу механизма постоянного хранения, для его правильной работы необходимо неявно отслеживать изменения в объектах. Для этого есть два способа: Неявное копирование при чтении (implicity copy-on-read) (механизм постоянного хранения копирует каждый раз объект хранения при чтении из базы данных и сравнивает закрытую копию с клиентской при фиксации транзакции); Неявное копирование при записи (механизм управляет загруженными объектами с помощью прокси-объекта). Такой механизм, как Hibernate, позволяет создавать хранилище, ориентированное на имитацию коллекции. В высокопроизводительной среде, хранение в памяти очень многих объектов может быть невыгодно из-за большой нагрузки на память и на систему выполнения. В случае с хранилищем, ориентированным на механизм постоянного хранения, не нужно отслеживать изменения в объектах, а необходимо каждый раз после изменений в агрегате фиксировать изменения методом save() или аналогичным. Например: Реализация хранилища использует методы и объекты механизма. При это реализация находится на инфраструктурном уровне, а интерфейс объявляется в домене. Здесь используется первый тип хранилища, ориентированный на имитацию коллекции. В нем необязательно реализовать метод save() или put(). Только методы коллекции. Таким образом доступ к базе данных или к другому механизму инкапсулируется в хранилище. Клиент будет очень простым и не будет зависеть от конкретной реализации хранилища. Вывод Таким образом были рассмотрены основные технические шаблоны DDD. Каждый из этих технических средств можно использовать для разработки отдельного ограниченного контекста. Для начала можно выделить самые важные сущности и объекты-значения. Потом можно их объединить в агрегаты для согласованности данных и выполнения бизнес-правил в границах агрегата. Потом надо создать фабрики и хранилища агрегатов. Для обеспечения согласованности данных в целой системе можно использовать события, которые, в свою очереди, можно использовать в целой системе, а не только в отдельном ограниченном контексте. Можно было еще рассказать о самом приложении, из каких оно уровней состоит, об архитектуре приложения, но тогда статья бы разрослась до очень больших размеров и ее было бы неудобно читать. Надеемся, что статья помогла вам продвинуться в понимании шаблонов DDD! Если есть вопросы, пишите в комментариях. С радостью ответим. И спасибо за внимание. Статью подготовили: greebn9k (Сергей Грибняк), wa1one (Владимир Ковальчук), silmarilion (Андрей Хахарев).

Метки:  
Нравится

[Из песочницы] Скрипт для тех, кому лень разбираться в Linux
Воскресенье, 11 Сентября 2016 г. 00:16 + в цитатник
Сфер применения Linux может быть очень много. Особенно, когда арендовать VPS стало можно от $1 в месяц. Кроме стандартного использования под хостинг сайтов, его используют в качестве сервера для игр (CS:GO, Terraria, Minecraft), в качестве Proxy-сервера и VPN-сервера. Под майнинг криптовалют. Под резервное хранилище бэкапов. Под домашнюю торренто-качалку. А также для тестирования, разработки и просто различных экспериментов. Именно доступность VPS на базе Linux с огромным спектром возможного его применения привела к популяризации Linux. Но желающих использовать Linux значительно больше, чем людей, которые умеют его использовать. И часто именно слабые познания администрирования Linux останавливают людей от его использования. Ну или просто усложняют таким людям жизнь — им приходится часами ковыряться в мануалах, форумах и «статьях для новичков». Да мне и самому надоело лазить по специализированным форумам, каждый раз, когда приходится сделать шаг влево или шаг вправо относительно того, что я уже научился делать. Именно поэтому, со временем, все типовые вещи я свёл в один скрипт с дружелюбным интерфейсом, который умеет делать всё сам. Начиналась всё с малого. Скрипт просто автоматизировал установку нужного мне софта. Но за полгода он превратился уже в весьма серьёзную утилиту весом 85 Кб, в которой более 2100 строк кода. Скрипт ранее нигде не выкладывался. Использовался только в личных целях мной и несколькими моими товарищами. Пришло время им поделиться с публикой. Уверен, многим людям он способен сэкономить кучу времени. Чтобы понять, что он умеет, проще всего глянуть на заглавный скриншот: Далее подробнее опишу, что и как он делает. Информация о системе Этот раздел в дружелюбной форме выводит информацию об этом сервере. Что за железо, какая ОС, какой IP-адрес. Причём, IP адрес он сначала пытается определить по интерфейсу, но т.к. бывают VPS без выделенного IP-адреса (за NAT), далее скрипт лезет в интернет и с помощью сторонних сайтов смотрит с какого IP пришли запросы и показывает реальный внешний IP-адрес (на это тратится пара секунд). Выглядит это информационное окно так: Работа с ОС В этом разделе собрано несколько как мелких утилит, типа смены пароля root, установки часового пояса, обновление ОС, добавление репозитория, установка популярных приложений (типа midinght commander), так и несколько более серьезных, на которых остановлюсь подробнее: Антивирус. Да, на Линуксе не бывает вирусов. Но бывают бэкдоры, которые через сайт открывают доступ ко всем вашим файлам злоумышленникам. Через эти же бэкдоры спамеры потом могут делать спам-рассылки используя ваш сервер. У меня в своё время за это забанили VPS. Поэтому, я предусмотрел установку антивируса. Разбираться в нём не нужно. Сам всё ставит, обновляет. Далее, не разбираясь в синтаксисе антивируса, через скрипт можно проверить весь диск или конкретную папку (например, где хостятся сайты). Firewall. Не все умеют настраивать правила Firewall (iptables). А в некоторых арендуемых VPS он преднастроен и включен, причём так, что устанавливаемые вами сервисы не будут доступны. И вам придётся копаться в настройках и открывать порты. А неправильная и необдуманная настройка firewall может вообще привести к тому, что вы после этого в принципе не сможете подключиться по SSH к своему серверу и вам придется либо переустанавливать ОС, либо как-то лезть на сервер через web-терминал, но эта функция есть не у всех хостеров. В случае использования моего скрипта такие проблемы исключены, а настройка Firewall происходит через «Помощник», где нужно просто ответить на простые вопросы. Планировщик задач (cron). Бывает, что нужно периодически выполнять какие-то типовые действия: проверка на вирусы, очистка логов, выкладывание бэкапов и т.д. Многие знают, что в Linux есть планировщик, который может выполнять задания по расписанию, но не всё умеют им пользоваться. Мой скрипт позволяет установить, включить, выключить планировщик и добавить в него задание, выбрав интервал запуска. Установка панели управления хостингом Очень часто Linux используется именно для хостинга, но руками настраивать там все сервисы типа: Apache, Nginx, PHP, MySQL, почтовый демон и так далее — совсем непросто для новичков. Большинство предпочитает установить какую-либо панель управления. Но даже её нужно сначала как-то установить. В своём скрипте я собрал пять бесплатных панелей управления сайтом (Vesta CP, Webuzo, CWP, ZPanel, Ajenti) и платную ISPmanager (которая является, пожалуй, самой распространенной панелью в России). Про каждую панель есть небольшое описание, системные требования. Выбираем нужную панель, скрипт сам её скачает с официального сайта (свежую версию) и установит. Работа с VPN В последнее время многие заводят себе VPN для того, чтобы получить преимущества пользователей других географических зон. Например, обход запретов РосКомНадзора, использование каких-то внутренних американских или европейских сервисов и так далее. Многие для этого покупают готовые VPN-сервисы. Но значительно дешевле купить себе VPS в нужной стране и поднять свой собственный VPN. Вот только не все умеют его настраивать. С помощью этого скрипта вам нужно просто отвечать на вопросы и всё. Весь нужный софт установится сам, в firewall пропишутся нужные правила. Вы сможете просматривать, добавлять и удалять пользователей, которым разрешен доступ. Причём скрипт проанализирует какая у вас ОС и сделает всё, учитывая особенности конкретно этой ОС. Работа с Proxy Некоторым привычнее использовать прокси вместо VPN. Ну и это зачастую дешевле, потому что Прокси, в отличии от VPN, можно использовать на серверах, у которых нет своего выделенного IP-адреса (которые находятся за NAT), а такие сервера стоят в несколько раз дешевле (их можно приобрести за $2 в год). Поднимать свой прокси-сервер на Линукс — тоже не самая простая задача для новичков. Но этот скрипт всё сделает за вас. Причём там очень много настроек. «Помощник» при установке спросит на каком порту нам нужен Прокси (или же предложит стандартный), спросит нужна ли авторизация по логину/паролю (или пускать всех, кто знает адрес и порт). Скрипт даже учтёт потребности тех пользователей, кто любит загонять сторонний трафик в Прокси (через программы типа Proxifier) и настроит конфиг нужным образом. Ну и, естественно, сам внесёт все нужные правила в Firewall (iptables). Настройка прокси ещё никогда не была такой простой. Руками в конфиг лазить вообще не нужно. Работа с файлами и программами В этом разделе можно установить нужную программу (пакет) или удалить. Причём самое полезное там — это именно правильное удаление. Дело в том, что при установке какой-либо программы очень часто к ней устанавливается несколько сопутствующих пакетов, необходимых для её работы. И зачастую, размер этих дополнительных пакетов превышает размер собственно той программы, которую вы устанавливали. Но вот при удалении вашей программы удалится только сама программа, а все пакеты, которые были нужны для её (и только её) работы — останутся и продолжат занимать место. В моём скрипте я предусмотрел полное удаление программы — со всем дополнительным софтом, который ставился вместе с ней. В скрипте просто указываем название программы, дальше скрипт всё сделает сам. Очистка системы В случае активного использования сервера под хостинг, часто копится огромное количества логов доступа к сайтам. Объём всего этого мусора иногда может достигать гигабайт. Не все знают где и как это удалять. В этом разделе можно почистить эти логи. Удаляются логи Apache и Nginx, как целиком, так и конкретного пользователя. Кроме этого, из этого раздела можно удалить старые установочные пакеты, которые по умолчанию остаются на диске после установки софта и продолжают занимать место. На этом, собственно, пока всё. В планах, конечно, много что ещё хочется добавить. Например, бенчмарк, для оценки производительности различных компонентов сервера. Расширить поддержку других ОС и так далее. По мере сил и времени, я собственно этим и занимаюсь. Но, уже сейчас, он выполняет довольно много функций, востребованных новичками и способен сильно упростить им жизнь. Теперь собственно, очень важный вопрос. А на каких дистрибутивах Linux всё это работает? На всех версиях CentOS. А также, на всех прочих производных от Red Hat Enterprise Linux дистрибутивах (например, Scientific Linux). Почему именно RHEL? Ну скрипт я писал для себя, а мне CentOS ближе. Ну и если говорить о целевой аудитории данного скрипта (новички), то им, как правило, без разницы на каком дистрибутиве работать. Ведь обычно они одинаково плохо знают любой из них. А RHEL весьма неплох, стабилен, нетребователен к ресурсам, ну и, самое главное, присутствует почти у каждого хостера VPS. Версию CentOS при этом можно выбрать любую (5, 6, 7), как и разрядность. Для всех действий скрипт анализирует какая версия дистрибутива и учитывает специфику именно этой версии. Я, обычно, выбираю дистрибутив CentOS 6.x (можно Minimal) с разрядностью 64 бита. Ну и самое главное. Как собственно обзавестись этим скриптом? Ниже прилагаю полный листинг кода скрипта со всеми потрохами и подробными комментариями (для тех, кто хочет что-то своё дописать): Исходный код скрипта#!/bin/bash title="Breeze Easy Shell" s/"enable": true/"enable": false/' /etc/ajenti/config.json whatismyipext echo "Выставляем наш внешний IP в конфиг" sed -i -e "s/\"host\": \"0.0.0.0\"/\"host\": \"$ipext\"/" /etc/ajenti/config.json echo "Устанавливаем русский язык по умолчанию" sed -i -e 's/ "bind": {/ "language": "ru_RU",\n "bind": {/' /etc/ajenti/config.json echo "Перезапускаем Ajenti" service ajenti restart br echo "Панель управления Ajenti и Ajenti V были установлены. Теперь можете управлять сервером из браузера." echo "Адрес: http://$ipext:8000" echo "Логин: root" echo "Пароль: admin" br wait } mtu_change() { ifconfig $1 mtu $2 wait } #Функция проверки установленного приложения, exist возвращает true если установлена и false, если нет. installed() { print $2'}` #вариант быстрый, но не всегда эффективный if [ -z $exist ] then #будем использовать оба варианта inet addr' | awk {'print $2'} | sed s/.*://` ;; 7) installed ifconfig if [ $exist inet' | sed q | awk {'print $2'}` ;; *) echo "Версия ОС неизвестна. Выходим." wait ;; esac } #определяем внешний IP через запрос whatismyipext() { installed wget if [ $exist print $1'}` } whatismyip_full() т | sed s/.*://` #centOS7 if [ $osver1 -eq 7 ]; then inet' | sed q | awk {'print $2'}`; fi echo "Ваш внешний IP: $ip?" myread_yn ans case "$ans" in y|Y) ;; n|N|т|Т) echo "Тогда введите IP вручную:" read ip ;; *) echo "Неправильный ответ. Выходим." wait sh $0 exit 0 ;; esac ;; *) echo "Неправильный ответ. Выходим." wait sh $0 exit 0 ;; esac } showinfo() awk 'print $2'` let (NR | awk '{print $4}'` let #определяем сколько RAM {print $2}'` {print $2}'` let print $4'} | sed q` let print $4'}` s/^[ \t]*//' | sed -e "s/(tm)//g" | sed -e "s/(C)//g" | sed -e "s/(R)//g"` #уберём двойные пробелы: print $2'})" print $1'}) print $3'}) else if [ "$(cat /etc/redhat-release | awk {'print $3'})" print $1'})" "$(cat /etc/redhat-release | awk {'print $2'}) print $4'}) else print $1'}` chosen=0 Укажите папку, которую нужно просканировать (введите "/", если весь сервер):' read scandir echo "Нужно ли сохранить лог сканирования в файл?" myread_yn avlog case "$avlog" in y|Y) echo 'Укажите путь для сохранения лога сканирования (начиная с "/")' read avlogdir echo "Сканируем..." br clamscan $scandir -r -i воспользовавшись разделом "Открыть порт в iptables".' wait ;; esac ;; 2) #Выключить firewall (рарешить все подключения) echo "Сейчас будут удалены все правила iptables, после чего будут разрешены все подключения. Продолжить?" myread_yn ans case "$ans" in y|Y) iptables -F iptables -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT ;; esac iptables_save br echo "Готово. Iptables продолжает работать, но в нём разрешены все подключения." wait ;; 3) #Временно выключить firewall iptables -F iptables -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT br echo "Готово. Были временно сброшены все правила для iptables. Сейчас проходят все" echo "подключения. После перезагрузки сервера или перезапуска iptables всё будет" echo "как прежде (применятся все правила, которые были до этого)." br wait ;; 4) #Перезапустить firewall if [ $osver1 -eq 7 ]; then myinstall iptables-services | tee > null fi service iptables restart br echo "Готово. " wait ;; 5) #Открыть порт в iptables echo "Укажите в какую сторону вы хотите открыть порт:" echo "1) Входящие соединения (чтобы к этому серверу можно было подключиться по заданному порту)" echo "2) Исходящие соединения (чтобы этот сервер мог подключиться к другим компьютерам по заданному порту)" myread_dig taffic_type case "$taffic_type" in 1) Панель управления "ISPManager 4"' echo 'Поддержка ОС: CentOS | RHEL | Debian | Ubuntu' echo 'Системные требования: минимальные не определены' echo 'Лицензия: Панель управления ПЛАТНАЯ! Без лицензии, активированной на ваш IP даже не установится.' echo 'Язык: Русский' echo 'Хотите установить?' myread_yn pick case "$pick" in y|Y) wget "http://download.ispsystem.com/install.4.sh" -r -N -nd sh install.4.sh rm -f install.4.sh ;; esac ;; 2) #ISPmanager 5 clear echo 'Панель управления "ISPManager 5"' echo 'Поддержка ОС: CentOS | RHEL | Debian | Ubuntu' echo 'Системные требования: минимальные не определены' echo 'Лицензия: Панель управления ПЛАТНАЯ! После установки будет Trial на 14 дней.' echo 'Язык: Русский' echo 'Хотите установить?' myread_yn pick case "$pick" in y|Y) wget http://cdn.ispsystem.com/install.sh -r -N -nd sh install.sh rm -f install.sh ;; esac ;; 3) #Vesta CP clear echo 'Панель управления "Vesta CP"' echo 'Поддержка ОС: CentOS | RHEL | Debian | Ubuntu' echo 'Системные требования: минимальные не определены' echo 'Лицензия: Панель управления полностью бесплатна.' echo 'Язык: Английский, русский' echo 'Хотите установить?' myread_yn pick case "$pick" in y|Y) if [[ $(pidof httpd) Хотите удалить его перед установкой "Vesta CP"?' myread_yn pick case "$pick" in y|Y) service httpd stop yum erase httpd -y ;; esac fi br echo 'Начинаем установку...' openport in tcp 8083 wget http://vestacp.com/pub/vst-install.sh -r -N -nd sh vst-install.sh --force rm -f vst-install.sh ;; esac ;; 4) #Webuzo clear echo 'Панель управления "Webuzo"' echo 'Поддержка ОС: CentOS 5.x, 6.x | RHEL 5.x, 6.x | Scientific Linux 5.x, 6.x | Ubuntu LTS' echo 'Системные требования: 512 MB RAM (minimum)' echo 'Лицензия: Панель управления имеет платную и бесплатную версию. Установите без лицензии для использования бесплатной версии.' echo 'Язык: Английский' echo 'Хотите установить?' myread_yn pick case "$pick" in y|Y) case "$osver1" in 5|6) webuzo_install ;; 7) echo 'У вас CentOS 7.x. Данная панель управления не поддерживает эту версию. Выходим.' wait ;; 0) echo 'нам не удалось определить Вашу ОС. Возможно, она не поддерживается Webuzo.' echo 'Хотите всё равно установить данную панель управления на свой страх и риск?' myread_yn ans case "$ans" in y|Y) webuzo_install ;; n|N|т|Т) ;; *) echo 'Неправильный выбор. Выходим.' wait ;; esac ;; esac ;; n|N|т|Т) ;; *) echo 'Неправильный выбор. Выходим.' wait ;; esac ;; 5) #CentOS Web Panel (CWP) clear echo 'Панель управления "CentOS Web Panel (CWP)"' echo 'Поддержка ОС: CentOS 6.x | RHEL 6.x | CloudLinux 6.x' echo 'Системные требования: 512 MB RAM (minimum)' echo 'Лицензия: Панель управления полностью бесплатна.' echo 'Язык: Английский' br echo "ВНИМАНИЕ! Данная панель будет устанавливаться очень долго (до 1 часа)!" br echo 'Хотите установить?' myread_yn pick case "$pick" in y|Y) case "$osver1" in 5|7) echo "У вас CentOS $osver1.x. Данная панель управления не поддерживает эту версию. Выходим." wait ;; 6) cwp_install ;; 0) echo 'нам не удалось определить Вашу ОС. Возможно, она не поддерживается Webuzo.' echo 'Хотите всё равно установить данную панель управления на свой страх и риск?' myread_yn ans case "$ans" in y|Y) cwp_install ;; n|N|т|Т) ;; *) echo 'Неправильный выбор. Выходим.' wait ;; esac ;; esac ;; n|N|т|Т) ;; *) echo 'Неправильный выбор. Выходим.' wait ;; esac ;; 6) #ZPanel CP clear echo 'Панель управления "ZPanel CP"' echo 'Поддержка ОС: CentOS 6.x | RHEL 6.x' echo 'Системные требования: не указаны разработчиком' echo 'Лицензия: Панель управления полностью бесплатна.' echo 'Язык: Английский, немецкий' br echo 'ВНИМАНИЕ! Поддержка данной панели давно прекращена, русификации нет. Устанавливайте на свой страх и риск.' br echo 'Хотите установить?' myread_yn pick case "$pick" in y|Y) case "$osver1" in 5|7) echo "У вас CentOS $osver1.x. Данная панель управления не поддерживает эту версию. Выходим." wait ;; 6) zpanel_install ;; 0) echo 'нам не удалось определить Вашу ОС. Возможно, она не поддерживается Webuzo.' echo 'Хотите всё равно установить данную панель управления на свой страх и риск?' myread_yn ans case "$ans" in y|Y) zpanel_install ;; n|N|т|Т) ;; *) echo 'Неправильный выбор. Выходим.' wait ;; esac ;; esac ;; n|N|т|Т) ;; *) echo 'Неправильный выбор. Выходим.' wait ;; esac ;; 7) #Ajenti clear echo 'Панель управления "Ajenti"' echo 'Поддержка ОС: CentOS 6, 7 | Debian 6, 7, 8 | Ubuntu | Gentoo' echo 'Системные требования: 35 Mb RAM ' echo 'Лицензия: Панель имеет как бесплатную версию, так и платную' echo 'Описание: Ajenti - это панель управления сервером, но к ней есть Addon под названием Ajenti V,' echo ' с помощью которого можно управлять хостингом.' echo 'Язык: Английский, русский и ещё 42 других языка' echo 'Хотите установить?' myread_yn pick case "$pick" in y|Y) case "$osver1" in 4|5) echo "У вас CentOS $osver1.x. Данная панель управления не поддерживает эту версию. Выходим." wait ;; 6|7) ajenti_install ;; 0) echo 'нам не удалось определить Вашу ОС. Возможно, она не поддерживается Webuzo.' echo 'Хотите всё равно установить данную панель управления на свой страх и риск?' myread_yn ans case "$ans" in y|Y) ajenti_install ;; n|N|т|Т) ;; *) echo 'Неправильный выбор. Выходим.' wait ;; esac ;; esac ;; n|N|т|Т) ;; *) echo 'Неправильный выбор. Выходим.' wait ;; esac ;; 0) /net.ipv4.ip_forward = 0/d' /etc/sysctl.conf #Удаляем строчку net.ipv4.ip_forward = 0 echo /exit 0/d' /etc/ppp/ip-up #Удаляем exit 0 в конце файла cat >> /etc/ppp/ip-up <<END ifconfig ppp0 mtu 1400 ifconfig ppp1 mtu 1400 ifconfig ppp2 mtu 1400 ifconfig ppp3 mtu 1400 ifconfig ppp4 mtu 1400 ifconfig ppp5 mtu 1400 ifconfig ppp6 mtu 1400 ifconfig ppp7 mtu 1400 ifconfig ppp8 mtu 1400 ifconfig ppp9 mtu 1400 exit 0 #возвращаем exit 0 END br echo "Перезапуск PPTP" service pptpd restart #centOS7 if [ $osver1 -eq 7 ]; then systemctl start pptpd; systemctl enable pptpd.service; fi br echo "Настройка вашего собственного VPN завершена!" echo "Ваш IP: $ip? логин и пароль:" echo "Имя пользователя (логин):$u ##### Пароль: $p" br wait ;; 2) #Добавить пользователей VPN echo "Введите имя пользователя для создания (eg. client1 or john):" read u echo "введите пароль для создаваемого пользователя:" read p # adding new user echo "$u * $p *" >> /etc/ppp/chap-secrets echo echo "Дополнительный пользователь создан!" echo "Имя пользователя (логин):$u ##### Пароль: $p" br wait ;; 3) #Открыть файл с логинами/паролями пользователей edit /etc/ppp/chap-secrets ;; 4) #Добавить правила для работы VPN в IPTables whatismyip_full iptables -I INPUT -p 47 -j ACCEPT iptables -I OUTPUT -p 47 -j ACCEPT openport in tcp 1723 openport out tcp 1723 iptables -t nat -I POSTROUTING -j SNAT --to $ip iptables -I FORWARD -s 10.1.0.0/24 -j ACCEPT iptables -I FORWARD -d 10.1.0.0/24 -j ACCEPT br echo 'Хотите, чтобы это правило сохранялось после перезагрузки?' myread_yn ans case "$ans" in y|Y) iptables_save ;; esac br wait ;; 5) #Удалить VPN-сервер clear echo "Внимание! Будет полностью удален VPN-сервер, файл с логинами/паролями и файл настроек" echo "Продолжить?" myread_yn ans case "$ans" in y|Y) uninstall -y pptpd pptp rm -f /etc/ppp/chap-secrets rm -f /etc/pptpd.conf sed -i -e '/ifconfig ppp0 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp1 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp2 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp3 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp4 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp5 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp6 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp7 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp8 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли sed -i -e '/ifconfig ppp9 mtu 1400/d' /etc/ppp/ip-up #Удаляем строки, которые добавляли echo "Готово." br wait ;; n|N) ;; *) echo "Неправильный ответ" wait ;; esac ;; 0) По умолчанию Proxy работает на порту 3128, но его можно поменять. Хотите изменить порт?' myread_yn ans Укажите порт, на котором должен работать Proxy?' read port sed -i "/http_port/d" "/etc/squid/squid.conf" #удаляем строку с настройкой порта echo "http_port $port" >> /etc/squid/squid.conf #добавляем строку с настройкой порта ;; esac br echo "Выберите вариант авторизации на Proxy:" echo "1) Свободный доступ (любой, кто знает IP и порт - может воспользоваться)" echo "2) Доступ по логину/паролю" myread_dig ans case "$ans" in 1) echo "http_access allow all" >> /etc/squid/squid.conf echo 'Был открыт доступ всем пользователям' br ;; 2) installed httpd-tools if [ $exist По умолчанию Proxy не является анонимным и можно определить Ваш IP, когда Вы им пользуетесь' echo 'Хотите сделать Ваш Proxy полностью анонимным?' myread_yn ans case "$ans" in y|Y) br echo 'Имейте ввиду, что такой Proxy-сервер нарушает правила протокола HTTP и является НЕЗАКОННЫМ.' echo 'Всю ответственность за такой сервер - несёте вы. Всё ещё хотите продолжить?' myread_yn ans case "$ans" in y|Y) cat >> /etc/squid/squid.conf <<END via off forwarded_for delete END ;; esac ;; esac br echo 'Вы хотите настроить Proxy таким образом, чтобы можно было использовать программы, типа Proxifier?' echo 'В этом случае будет разрешен проброс SSL туннеля на порт 80. Если вы не уверены, ответьте "нет"' myread_yn ans case "$ans" in y|Y) sed -i -e '/http_access deny CONNECT !SSL_ports/d' /etc/squid/squid.conf #Удаляем из конфига строчку http_access deny CONNECT !SSL_ports echo '#http_access deny CONNECT !SSL_ports' >> /etc/squid/squid.conf #возвращаем ее назад в закомментированном виде" ;; esac br echo "Добавляем Squid в автозагрузку..." chkconfig squid on br service squid restart br echo "Proxy-сервер был успешно настроен. Если подключение к нему есть, но трафик не идёт, то, возможно" echo "проблема в MTU. Вы можете его настроить в соответствующем разделе." br whatismyipext echo "Параметры вашего Proxy:" echo "IP: $ipext" echo "Порт: $port" echo "Пользователь: $login" br wait ;; 2) #Удалить Proxy (Squid) echo "Будет удален Proxy-сервер (Squid), а также файл настроек и файл" echo "с логинами/паролями пользователей. Продолжить?" myread_yn ans case "$ans" in y|Y) echo "Начинаем удаление squid..." uninstall -y squid rm -f /etc/squid/squid.conf rm -f /etc/squid/internet_users br echo 'Squid был удален' wait ;; esac ;; 3) #Поменять MTU для интерфейса echo 'На каком интерфейсе вы хотите поменять mtu?' read interface echo 'Какой mtu установить?' read mtu mtu_change $interface $mtu echo 'Для интерфейса '$interface' был успешно установлен MTU '$mtu wait ;; 4) #Открыть файл настроек Squid edit /etc/squid/squid.conf ;; 5) #Добавить пользователей Proxy br installed httpd-tools if [ $exist Готово' wait ;; 0) -----------¬' echo '¦ Терминал ¦' echo 'L-----------' echo "Здесь вы можете ввести любую команду, которую поддерживает bash." echo "Кроме этого, поддерживаются внутренние команды $title" echo 'Такие как: myinstall, uninstall, openport, changelog, updatescript, about и др.' echo 'Для выхода из терминала наберите "exit" или "quit".' br echo "Введите команду:" read cmd if [[ "$cmd" > Всё что вам нужно, чтобы его использовать — это создать файл [название].sh и засунуть в него это содержимое. После чего запустить командой «sh [название].sh». Создать его можно как на сервере, так и на своем компьютере, а потом скопировать на сервер. Я, например, закинул его себе на домашний сервер и на каждом новом VPS вбиваю команду: cd /root/ wget http://evtikhov.ru/breeze.sh -r -N -nd cat >> /root/.bashrc <<END alias END exit После этого под рутом в терминале одной командой «breeze» запускаю его. P.S. Вообще, частенько возникает вопрос доверия использования чужих скриптов и это правильно. Но прелесть скриптов на bash в том, что перед их запуском можно открыть и посмотреть его. И убедиться в том, что он не делает ничего плохого. Функцию обновления скрипта вас использовать никто не заставляет. В общем-то, вас вообще никто не заставляет его использовать. Всегда можно просто посмотреть как настраивается VPN, Proxy и прочие вещи и вручную вколотить пару десятков команд, разобравшись в них. Обилие комментариев в коде даже поможет в них разобраться.
DEV Labs 2016. JAVA. 25 июня

Метки:  
Нравится

WhatsApp собирается делиться данными своих пользователей с Facebook
Воскресенье, 28 Августа 2016 г. 02:23 + в цитатник
Мы не так давно хвалили WhatsApp в своем корпоративном блоге за внедрение в мессенджер полноценного E2E шифрования и протокола Signal. Такое решение безопасности оставило далеко позади многих конкурентов этого очень популярного мессенджера. Однако, на сей раз речь пойдет о новой его функции, которая наверняка не будет воспринята пользователями положительно. В своем новом посте в блоге, авторы мессенджера указывают на то, что теперь часть данных пользователя, например, его номер телефона будет известна Facebook. Именно для этого компания обновила свое соглашение о конфиденциальности. Данные, которые Facebook будет получать от WhatsApp, будут использоваться для показа ему более персонализированной рекламы. Однако, передаваемая информация пользователя WhatsApp не будет видна другим пользователям Facebook. Никакая информация, которой вы делитесь в WhatsApp, включая ваши сообщения, фотографии, информацию о вашем аккаунте, не будет размещаться на Facebook или любой другой компании из группы компаний Facebook, чтобы другие могли ее видеть. Это означает, что, например, хотя некоторая информация будет передана Facebook (номер телефона), данная информация не будет видимой для других людей на Facebook. Кроме того, когда вы и ваши контакты используют последнюю версию нашего приложения, ваши сообщения защищены сквозным шифрованием по умолчанию. Когда ваши сообщения защищены сквозным шифрованием, то только люди, с которыми вы обмениваетесь сообщениями, могут читать их — ни WhatsApp, ни Facebook, никто другой. Whatsapp FAQ Деактивация настройки обмена данными WhatsApp с Facebook.

Метки:  
Нравится

MirrorMoon EP — в поисках заветной планеты
Воскресенье, 07 Августа 2016 г. 12:28 + в цитатник
Осторожно, спойлеры и артхаус! Если вы в тупике и отчаянии, то эта статья должна помочь вам пройти игру. Плюс, технические подробности. Предисловие Это была самая странная, долгая и познавательная охота за ачивкой. Был изучен код игры, воссоздан API и реализован звездный навигатор для этой бесконечной космической одиссеи. Весь путь я проклинал разработчиков. Ведь, по сути, игра длится всего 10 минут. А дальше, дальше только пустота и надежда. Но как я рад теперь! Благодаря разработчикам и моему стремлению я многое узнал. Далее само прохождение. Обсерватория Перейдя на сторону B, мы начинаем путешествие. Поначалу, кажется, оно не имеет цели, но найдя первую обсерваторию, мы видим кружок. Это наша цель. В обсерватории мы наблюдаем созвездия. Выбрав ближайшие звезды, начинаем на них охоту. Если эти звезды уже открыты, то мы можем запускать навигатор и вычислять цель. Звезды Названия звезд генерируются из трех букв и двух случайных чисел. Буквы привязаны к координатам. Найдите любую звезду, где первые две буквы будут совпадать с искомой звездой. Прыгайте туда и ищите, непосредственно, нужную вам звезду. Она должна быть рядом. Пометив нужные звезды, идем в навигатор. Финал Выбираем сезон. Помечаем все нужные звезды. Находясь на планете с обсерваторией, включаем режим OBS. Просчитываем расположение звезд, перекрестие должно указывать на загадочную планету. Выходим из режима OBS. Включаем ортогональную проекцию. Теперь мы видим карту как в игре. Идем в игру и подгоняем вид. Где-то в центре мы найдем далекую звезду и прыгнем туда, в надежде.. Реализация MirrorMoon EP создан на Unity 3D. Поэтому было не сложно декомпилировать код. Алгоритм следующий. Открываем урл — http://www.santaragione.com/NTF/MMEP/notification_1_1.php. Нас интересует последняя строчка. В ней находится кол-во сезонов. Это число используется для генерации хэша. Также нам потребуется секретный ключ thankyouforhackingmysecretkey1234568. О нет, нас раскусили :) string getHash(string text) { MD5 md5Hash = MD5.Create(); byte[] data = md5Hash.ComputeHash(Encoding.UTF8.GetBytes(text)); StringBuilder sBuilder = new StringBuilder(); for (int i = 0; i < data.Length; i++) sBuilder.Append(data[i].ToString("x2")); return sBuilder.ToString(); } string availableSeasons = urlopen("http://www.santaragione.com/NTF/MMEP/notification_1_1.php").Split('\n')[6]; string hash = getHash (availableSeasons + secretKey); Теперь мы можем получить список сезонов: 1_000022,2_000077,3_000100,4_000099… Пары из номера и сида, разделенные запятыми. string baseUrl = "http://www.mirrormoongame.com/mmphp/"; string url = string.Format > Похожим образом получаем звезды в выбранном сезоне: string hash = Utils.getHash (seed + secretKey); string url = string.Format ,')) { string name = pair.Substring(16, 6).Trim(); string pos = pair.Substring(22); float x = Convert.ToSingle(pos.Substring(0, 3)); float y = Convert.ToSingle(pos.Substring(3, 3)); float z = Convert.ToSingle(pos.Substring(6)); GameObject star = Instantiate(starPrefab) as GameObject; star.GetComponent<Star>().title = name; star.transform.position = new Vector3(x, y, z); stars.Add(star); } Это пары из координат и название звезды — 000022349205629_LIAMD 349205629,000022490453661_PAX4 490453661,000022570586427_RHUMB 570586427... Пожалуй, это всё… или нет? За кулисами остался алгоритм добавления звезд. Это я оставлю истинным ценителям цифрового творчества. Не хулиганьте. P.S.: Прохождение актуально только для онлайн режима. Навигатор можно скачать здесь, исходники там же. P.P.S.: Описанные события произошли в марте 2014 года. Больше двух лет пост лежал в черновиках, потому что не было технической части в рассказе. Теперь это исправлено.

Метки:  
Нравится

Систематизация публикаций в web. Часть 2: Три шага к научной респектабельности
Воскресенье, 31 Июля 2016 г. 16:38 + в цитатник
«The future is already here — it's just not very evenly distributed.» William Gibson В первой части статьи был проведен обзор статей на тему научной работы, опубликованных на habrahabr.ru, рассмотрено понятие индекса цитирования (h-index или индекс Хирша) и сделан вывод о необходимости навыков работы с наукометрическими базами данных для всех, кто встал на путь научной карьеры. В продолжении статьи рассматриваются три инструмента управления публикациями в web: 1) Scopus; 2) Google Scholar (Академия Google); 3) Research Gate. Шаг 1-й: Что Scopus’у в имени моем? Если вы уже несколько лет пишете статьи на английском, то, несомненно, в Сети существует след от этой деятельности. Как его обнаружить? Как понять, не упустили ли вы по случайности какую-то важную публикацию? Конечно же, существуют сайты журналов и цифровые библиотеки, например, в Computer Science одними из наиболее авторитетных и прогрессивных являются цифровые библиотеки IEEE Xplore, ACM и Springler. Если у вас есть статьи в журналах или трудах конференций, индексируемых в этих цифровых библиотеках, то найти их не составит труда (например, по фамилии автора). Scopus умеет собирать и обрабатывать данные от многих цифровых библиотек. Основной функционал системы является платным, однако простой поиск, в том числе, и по имени автора, может быть выполнен без аккаунта. Заходим на сайт Scopus. В открывшемся неказистом окне кликаем по линку Author Preview. После этого попадаем на страницу поиска. Достаточно ввести имя и фамилию в соответствующих полях. Для ускорения поиска внизу при помощи флажков можно задать направление своей научной деятельности (Subject Areas: Life Sciences, Health Sciences, Physical Sciences, Social Sciences and Humanities), например, так, как это сделано ниже (ищем мои труды). Как оказалось, поиск отлично справляется с задачей. Поисковик побеждает разницу в инициалах и в разной транслитерации имен. Кроме того, если вдруг в базе обнаружилось несколько вариантов написания имени, то можно отправить заявку, и профили будут агрегированы. После этого можно кликнуть по своему имени и ознакомиться с индивидуальной карточкой. Как видим, Scopus с внимательностью «большого брата» следит за нашими публикациями, карьерой и цитированием. Из моментов, на которые стоит обратить внимание, я бы отметил Author ID (иногда его полезно знать) и h-index (или индекс Хирша), о нем было сказано в первой части публикации. Многие компоненты интерфейса недоступны, это предмет платной лицензии. В цивилизованных странах, идущих по пути научно-технического прогресса, университеты и наукоемкие компании обычно оплачивают корпоративные лицензии для своих сотрудников. Из бесплатных инструментов я нашел лишь Author feedback wizard. Зайдя по этой ссылке, вы получите возможность в несколько шагов ознакомиться с базовой информацией относительно публикаций. Можно, например, получить перечень своих публикаций в достаточно удобном виде. А потом можно просмотреть карточки публикаций. Отредактировать ничего не получится, это прерогатива Scopus. Разумеется, так можно просматривать информацию не только о своих, но и о любых интересующих вас публикациях. Таким образом, если вы публикуетесь исключительно в высокорейтинговых журналах, то даже отпадает необходимость лично вести учет своих публикаций, Scopus все сделает за вас. Шаг 2-й: Google Scholar: ждем наступления будущего Зная мастерство Google в создании эффективных бизнес моделей, следует обратить внимание на сервис Google Scholar (Академия Google), интегрированный в гугловские сервисы. Очевидно, что на сегодняшний момент этот сервис развивается, хотя существуют и альтернативные мнения. Не представляет собой труда создать профиль Google Scholar на базе общего аккаунта Google, после чего туда подтянутся все ваши индексируемые труды вместе с процитированными источниками и результатами расчета индексов цитирования. В главном меню Google Scholar присутствует шесть основных опций (Моя библиотека, Мои цитаты, Мои обновления, Оповещения, Показатели, Настройки). Пройдемся по ним. В разделе «Моя библиотека» можно найти полный перечень, как собственных индексируемых трудов, так и тех трудов, на которые у вас есть ссылки и которые также индексируются. Если под какой-либо публикацией нажать ссылку «Цитировать», то получим такое окно, в котором ссылка конвертируется согласно стилям цитирования либо же в типовой файловый формат (внизу окна). Если не вся информация, необходимая для цитирования, корректно подтянулась в базу, то ее нужно доработать вручную. Коррекция в самой библиотеке также возможна. Набор шаблонов цитирования достаточно ограниченный. Интересно, что туда попал ГОСТ, но, например, шаблона IEEE на предусмотрено, то есть, надо допиливать вручную. А вот в разделе «Мои цитаты» можно увидеть перечень собственных индексированных публикаций и статистику цитирования. Публикации можно добавлять вручную в виде записи, однако, на мой взгляд, особого смысла в этом нет. Дело в том, что Google Scholar нельзя «заставить» индексировать добавленную статью, и она будет видна только посетителям вашего профиля. Кроме того, нельзя будет добавить ссылку на web ресурс со статьей, даже, если таковой и существует. То есть, вы получите в профиле частную цитату, не более, она не добавится к общей базе. В разделе «Мои обновления» Google Scholar собирает ссылки на публикации, которые могут быть вам интересны, исходя из того, что уже собрано в личной библиотеке. Мне показалось, что здесь достигается отличная релевантность. «Оповещения», на мой взгляд, не столь важны. «Оповещения» позволяют следить за публикациями конкретных авторов (дополнено, благодаря комментарию ikashnitsky). Если зайти в «Показатели», то увидим перечень индексируемых журналов. Журналы заботливо разложены по категориями и ранжированы по индексу цитируемости. Это важно для анализа и выбора журналов для последующих публикаций. В левом нижнем углу окна видим, что индексируются не только англоязычные журналы, а, в том числе, и русскоязычные (дополнено, благодаря комментарию ikashnitsky). Русского языка пока нет. Интересно, когда там появится «великий и могучий»? «Настройки» аккаунта (также, как и имеющийся Help) достаточно простые. Замеченные странности работы Google Scholar связаны с неидеальностью алгоритмов индексирования. Например, недавно был выпущен и проиндексирован сборник статей одной из конференций. В нем было опубликовано две моих статьи, однако, Google Scholar почему-то выбрал только одну из них. Scopus «увидел» обе статьи. В принципе, заложенный функционал представляется достаточно адекватным. Я не нашел, как можно сформировать список работ. На мой взгляд, эта опция достаточно важна, причем она достаточно просто может быть реализована. Шаг 3-й: Research Gate: масштабируем личный репозиторий После знакомства с первыми двумя инструментами, возникает вопрос: а можно ли самому добавлять публикации, которые не индексируются ведущими наукометрическими базами? Для этого существуют научные социальные сети, из всего множества которых мне больше всего понравился Research Gate. Хорош Research Gate тем, что в нем есть свой поисковый движок, что позволяет создать свою собственную наукометрическую базу. Таким образом, ваш профиль формируется автоматически, даже если вы об этом и не ведаете. Кроме того, Research Gate обладает типовым функционалом социальной сети с точки зрения размещения профиля, разнообразных поисковых опций, обмена сообщениями и т.п. Есть функции размещения и поиска вакансий с соответствующей спецификой, т.е. университетских позиций. Есть функции размещения профессиональных вопросов участников сети и ответов на них. Впрочем, пусть о функционале скажет сама команда разработки. На сайте Research Gate вы найдете такое вот краткое описание. Собственно говоря, это и есть весь Help, все остальное только интуитивно. У вас есть возможность публикации научных результатов в виде статей, разделов книг, отчетов и т.п. Как вариант, именно в Research Gate есть смысл вести полный своих публикаций, а также и других работ и проектов. Опция создания и ведения проектов полезна, если есть необходимость собрать коллекцию материалов в единой рубрике. Кроме того, на сайте достаточно подробно будут измеряться ваши социальные достижения вроде количества прочтений и просмотров профиля, на базе этого будет определен персональный рейтинг по версии Research Gate, и будет посчитан h-index. Список публикаций (например, в виде таблицы) у меня сформировать не получилось. Еще одним недостатком является то, что единожды внесенную информацию по публикации откорректировать уже не удается. В случае необходимости, наиболее простым решением является удаление публикации и внесение заново. Web of Science: платная, но крутая В данной статье Web of Science (WoS) не рассматривается как рабочий инструмент, поскольку использование его является платным. Однако, неправильно было бы полностью проигнорировать Web of Science, поскольку, наряду со Scopus, WoS позиционируется, как ведущая наукометрическая база. У меня лично на данный момент нет доступа к Web of Science, просил знакомых «с доступом» выполнить поиск. Данная платформа является собственностью глобальной медиа группы Thomson Reuters. Похоже, именно эти люди формируют лицо современной наукометрии. Принципы работы похожи на принципы работы со Scopus. Моих публикаций в Web of Science получилось меньше, чем в Scopus, хотя, собственно говоря, это вопрос стратегии продвижения. Основные выводы За появлением собственных научных публикаций и их цитированием в наукометрических базах следить надо, и на то есть множество причин. Упрощенный поиск в Scopus на данный момент доступен бесплатно, а вот Web of Science признает только платные аккаунты. Google Scholar пока является не столь широко признанной, но перспективной наукометрической базой. Учитывая простоту работы, открытость, быстрое развитие и некоторую вероятность подключения в скором времени русскоязычного сегмента, Google Scholar однозначно рекомендуется к использованию. Кроме того, Google Scholar реализует конвертацию в различные форматы ссылок на цитируемые источники. С другой стороны, в данном сервисе не в полной мере решаются вопросы управления научным контентом. Тем не менее, вам может понадобиться научная социальная сеть с функциями хранения в ней личного контента, независимо от включения его в наукометрические базы. На такую роль вполне подходит Research Gate. Достоинством Research Gate является собственный поисковый движок, а недостатком – весьма скромный функционал библиографического менеджера. Существуют и другие научные социальные сети (опыт их применения другими авторами описан на «хабре», ссылки на публикации есть в первой части данной статьи), их применение является вопросом личного вкуса. Возможно, у почтенной публики есть наработки по выше обозначенной теме, поэтому, хотелось бы продолжить обсуждение в режиме диалога. Кроме того, после ознакомления с базами, я так для себя окончательно и не ответил на вопрос: какая база «круче», та, где индексируется меньше всего изданий (высокая избирательность) или та, где индексируется больше всего изданий (больше материала и перекрестных цитат)? Мной в скором времени планируется: – подтянуть перечень публикаций в соцсеть linkedin; – разобраться с функционалом сервиса ORCID; – рассмотреть возможные стратегии продвижения научного бренда на базе анализа индекса цитирования (с учетом топовых журналов, в которых есть смысл публиковаться).

Метки:  
Нравится

[Перевод] Вид и перспектива в дизайне уровней. Часть первая
Суббота, 23 Июля 2016 г. 16:47 + в цитатник
Нам, как дизайнерам уровней, часто приходится снабжать игроков большими объемами информации. Это необходимо по многим причинам. Иногда нам просто хочется блеснуть красивым гейм-артом, а иногда – направить игрока к выполнению цели, проработать историю или сюжет игры, создать или сбавить напряжение. Но прежде чем делать всё это, необходимо понять, как направлять внимание игроков туда, куда нам нужно. Подробнее об этом — в нашем переводе статьи Майка Стаута. Планета Гаспар из игры Ratchet & Clank Существует много методов, помогающих дизайнерам привлечь внимание пользователей. В некоторых играх используются видеозаставки (или пролет камеры), чтобы направить внимание игроков на важные, по задумке разработчиков, элементы. Но тем самым игроков лишают возможности управления. В других играх, наоборот, игроки могут получить доступ к важным элементам собственноручно, нажав на специальную кнопку. Так или иначе, в этой статье мы поговорим о моем любимом способе направлять внимание – создании изначально грамотной композиции уровня за счет умного использования вида и перспективы. Конечно, мне нравятся и другие методы (обычно используемые в комплексе), но лучше выполнить дизайнерскую задачу на этапе проектирования уровня, чтобы она не превратилась в проблему, которую придется решать уже на этапе разработки. Естественно, в таком случае решение (например, видеозаставка) потребует гораздо больше ресурсов и усилий. Что такое вид и перспектива? Вид – это взаиморасположение камеры и геометрии уровня, которое обеспечивает правильное построение композиции и подчеркивает важные элементы сцены. Здесь подразумевается любое место в уровне, устроенное таким образом, чтобы гарантированно обратить внимание пользователя на какую-либо важную деталь. Чаще всего для этого используется еще один особый инструмент – перспектива. Перспектива – это вид, который открывается через узкий коридор деревьев, зданий и т.д. Удачное построение вида и перспективы требует вдумчивого расположения ориентиров и акцентов игры, а также искусной расстановки камер. К примеру, в начале игры (или в любой момент после загрузки) дизайнер может разместить ориентиры и акценты в самом первом кадре, до того как игрок получит возможность управления. Но это не единственный способ их применения. Многие игры также используют узкие пространства, коридоры или другие элементы уровня, вынуждающие пользователя поворачивать камеру в определенном направлении. К примеру, если пользователь должен войти в дверь, камера, скорее всего, будет повернута в её сторону, и перспектива выстраивается через нее, по ту сторону двери. Вид и перспектива – очень мощные инструменты, особенно если использовать их в сочетании с другими упомянутыми выше средствами привлечения внимания (вроде видеозаставок). Вид на Тадж-Махал, открывающийся через узкий коридор (Diego Delso, Wikimedia Commons, License CC-BY-SA 3.0) Зачем использовать вид? 1. Чтобы продемонстрировать крутой гейм-арт Самое очевидное преимущество использования вида или перспективы – показать игрокам красивый гейм-арт: к примеру, как на этом скриншоте из Middle-earth: Shadows of Mordor. Контрольный пункт в игре Middle-earth: Shadows of Mordor Этот скриншот сделан на одном из контрольных пунктов игры, которые представлены там в виде высоких башен с колоннами (по одной колонне в каждом из четырех углов башни). Через каждую пару колонн игроку открывается шикарный вид на окружающий мир. 2. Чтобы подчеркнуть изюминку игры Если в вашей игре есть интересная особенность, неважно – в технологии, арте или геймплее, правильный вид и перспектива помогут вам сделать на ней акцент. Открывающийся вид на первую планету в игре Super Mario Galaxy Начальный открывающийся вид первой планеты в игре Super Mario Galaxy обращает внимание на её особую физику – изюминку игры. Камера расположена таким образом, чтобы округлый горизонт планеты и объекты, которые на нём появляются, акцентировали на себе внимание. 3. Чтобы направлять игрока Этот скриншот из игры Elder Scrolls: Oblivion был сделан сразу по окончании обучения в подземелье. После выхода наружу игроку открывается этот вид, причем камера располагается именно под таким углом. Прием довольно часто используется в играх серии Elder Scrolls. Он позволяет дизайнерам точно знать, куда будет направлен взгляд игрока, когда он войдет в очередную дверь. Вид при выходе из подземелья в игре Elder Scrolls: Oblivion Обратите внимание на то, как линия причала направляет ваше внимание к руинам. Руины не имеют никакого особенного значения в игре – просто разработчики Oblivion хотят научить игрока жить в открытом мире. Они побуждают его отправиться исследовать этот мир, не принуждая его делать что-либо конкретно. И такой вид прекрасно помогает донести эту идею. 4. Чтобы исследовать сюжет или историю игры Глядя на этот скриншот из игры Super Mario Galaxy, можно сделать два любопытных наблюдения: Обратите внимание, как тропинка впереди образует линию, которая подводит ваш взгляд к падающим звездам. Вспомните об этом немного позже, когда мы будем говорить об использовании линий для управления вниманием 1. Перспектива, создаваемая двумя холмами, направляет внимание игрока вдоль тропинки, которая ведет на следующий уровень. 2. Игрок видит небо в образовавшейся перспективе, а падающие звезды становятся ключом к пониманию всего сюжета игры. В начале Half-Life 2 игроку нужно как-то рассказать о том, что произошло с момента последней игры. Скриншот сделан на раннем этапе игры, когда игроку еще почти ничего не известно. На первом уровне игры часто используется перспектива для привлечения внимания игрока к видеоэкранам или диалогам неигровых персонажей. Это позволяет дизайнерам удостовериться в том, что игрок не пропустит важные моменты и будет постепенно узнавать, что происходит вокруг, не теряя при этом управление игрой. Совет: Управление камерой Дизайнеру не нужно полностью контролировать камеру, чтобы продемонстрировать игроку хорошие виды. К примеру, вид на приведенном выше скриншоте из Half-Life 2 не навязывается: персонаж просто выходит из поезда и поворачивает налево. Но поскольку ему и так нужно идти по этому узкому коридору между поездами, он гарантировано увидит такую картинку. 5. Чтобы создавать напряжение и интригу Как говорилось ранее, первый уровень в Half-Life 2 сделан таким образом, чтобы за счет правильного построения вида и перспективы дать игроку как можно больше информации через видеоэкраны и диалоги. Видеоэкраны, как правило, сообщают игроку, что происходит; диалоги между неигровыми персонажами нужны, в основном, чтобы припугнуть его. Возьмем для примера этот эпизод с пропускным пунктом охраны: Ограда выстроена в форме лабиринта с тремя параллельными секциями, образующими 3 отдельные перспективы. Из них 2 вырабатывают у игрока определенный паттерн – создают ощущение комфорта. Когда в третий раз этот паттерн нарушается, игрок чувствует диссонанс и тревогу. Проходя через первый коридор, сделанный из сетчатого ограждения, вы будете гарантировано смотреть прямо перед собой, как и было задумано. Пройдя второй коридор, вы увидите, как человек справа спокойно пересекает пропускной пункт. Когда вы уже почти прошли третий коридор, на ваших глазах второй человек так же спокойно преодолевает пропускной пункт. Вы видите, как они оба выходят через дверь в дальнем конце коридора. Наконец, дойдя до пропускного пункта, вы замечаете нарушение паттерна. Солдаты не нападают на вас, но один из них становится на пути к двери, через которую только что вышли 2 человека. Солдаты указывают вам на другую дверь, которую вы не видели, проходя через лабиринт. Нарушение паттерна сбивает вас с толку и побуждает задать себе вопрос: почему вас ведут в другую дверь? Не скрывается ли за ней какая-нибудь угроза? Начальный открывающийся вид дает игроку первое впечатление об уровне. А с использованием всех приведенных выше советов вы можете превратить его в мощное средство для создания хорошего первого впечатления.

Метки:  
Нравится

[Перевод] Оттачивайте свои навыки: значение Мультидисциплинарного дизайна
Вторник, 19 Июля 2016 г. 20:32 + в цитатник
Примечание: дизайнеры работают в самых разных областях, начиная от моды, архитектуры, заканчивая графическим дизайном для мобильных приложений и веб-сайтов. В то время, как специфика самой работы может варьироваться в зависимости от области. Работа дизайнера имеет много общих существенных признаков. В этой статье Peter Varadi делиться своими мыслями о процессе проектирования дизайнерских навыков. Дизайн везде, он повсюду окружает нас. Каждый раз, когда мы смотрим вокруг, мы проецируем наше окружение. Дизайн является важнейшей формой взаимодействия с человеком. Слово «design» появилось в XVI веке и однозначно употреблялось во всей Европе. Итальянское выражение «disegnare» означало рожденную у художника и внушенную Богом идею — концепцию произведения искусства. Оксфордский словарь 1588 года дает следующую интерпретацию этого слова: «задуманный человеком план или схема чего-то, что будет реализовано, первый набросок будущего произведения искусства». Все мы проектные практики, именно после принятия самостоятельных решений мы приобретаем огромный опыт. Например, когда мы решает какой стол купить на кухню, что приготовить сегодня на ужин или какую рубашку выбрать на свидание. Слово дизайн мы используем более сознательно на высоком профессиональном уровне, относительно процесса формирования того, что мы видим и наше взаимодействие с этим. Проектирование часто требует рассмотрения эстетических, функциональных, экономических и социально-политических аспектов объекта проектирования и самого процесса проектирования в целом. Это может потребовать значительных исследований, мыслей, моделирования, интерактивной регулировки и редизайна. С точки зрения эстетики, дизайн тесно связан с изобразительным искусством. Однако конечная цель дизайна состоит в том, чтобы обеспечить пользователю удобство (графический дизайн, пользовательские интерфейсы и т. д.). Дизайн преобразует эмоции в опыт! Также нужно отметить, что все проектные работы разделяют культурные контексты и условия в любой момент времени. В мире всегда будет влияние на дизайнеров, населяющих его. В идеале, конструкция различных дисциплин должна безупречно взаимодействовать друг с другом для формирования единого контроля. Понимание этих связей может иметь важное значение. Мой Мультидисциплинарный дизайн Для дизайнера значение дизайна настолько естественно, что большую часть времени он этого и не осознает. Если бы меня спросили: — А когда ты начал заниматься проектированием? Я думаю, не был бы уверен, что точно смог бы ответить на этот вопрос. Многие из нас начали рисовать будучи еще маленькими, представляя себя в роли дизайнера, проектировщика, архитектора и т.п. В какой-то момент, мы начинаем понимать, что в дальнейшем хотели бы изучать проектирование как профессиональную дисциплину. В начале школьного обучения, я начинал с простого редактирования изображений, экспериментировал с типографикой и веб-дизайном, хотя и на относительно низком уровне. Тоже самое и продолжалось в средней школе, но только с добавлением в это элементов иллюстрации. До этого момента, я не сильно серьезно воспринимал свое занятие и обучение в школе. И это было естественно. Кто бы мог подумать. Все изменилось, когда я начал проектировать, после получения образования. Я познал истинный процесс проектирования, важность концепции и научные исследования. Что есть бесконечные дизайнерские проблемы и несомненно нужный подход для их решения. В свое время, я познакомился с архитектурой интерьера и дизайном городской среды, а также улучшил свои типографские и графические навыки. Здесь же я узнал, что представленная конструкция может быть не так важна, как сам дизайн. И хотя я и изучал архитектуру, начиная с начала 2014 года я начал экспериментировать с графическим дизайном. Постепенно, к концу лета, получил на руки масштабные проекты дизайна айдентики, брендинг и дизайн пользовательского интерфейса. Позже, в 2015 году, я начал заниматься UX Дизайном все чаще и чаще, и закончил я это тем, что изучил UI+UX Design и регулярно использовал для своих многих проектов. Общий язык дизайна Только после того, как я начал свою профессиональную карьеру я понял, как похожи некоторые аспекты различных дисциплин. Можно развивать понимание совершенно новых дисциплин и углублять свои знания в существующих. Эти элементы включают в себя: процесс проектирования, научные исследования, концептуализация, разработка, прототипирование, переконструировка, представление и так далее. Чем больше дисциплин, которые вы пытаетесь изучить, тем лучше вы сможете понять основы дизайны в общем смысле. Только не думайте о том, что нужно гнаться за всеми зайцами одновременно. Есть также элементы, которые не могут быть связаны с какой-либо конкретной областью, но к дизайну в целом относиться они все же будут. Я говорю о таких вещах, как макет, контраст и рисунок. Эти три элемента присутствуют во всех областях дизайна и служат инструментом, подчеркивающим основные аспекты наших дизайнеров. Мы регулярно сталкивается с ними в любом творческом процессе. И так как они повсюду, мы должны хорошо понимать их. Пренебрежение или злоупотребление ими может стать для дизайнера настоящим проклятием, а при правильном использовании это может стать великой силой. Впервые я понял, как знания накапливаются, при работе в Runner Game в начале 2014 года. Получилось гораздо проще, чем я ожидал, я мог бы так же эффективно документировать свой процесс. Поскольку мой опыт в создании дизайна игр никогда не был слишком развит, я узнал много новых вещей, но опыт который я получил в Runner Game я мог бы так же использовать и в других областях. Например, в графическом дизайне, типографике, брендинге, выборе цвета или дизайне интерфейса. Мой первоначальные страхи исчезли, когда я понял, что моих знаний будет достаточно, чтобы решить дизайнерскую проблему (о дизайнерских проблемах было упомянуто выше). С этим процессом часто и кодеры сталкиваются: чтобы понять поведение и логику одного языка, начать разрабатывать перспективнее и помочь понять это другим. И хотя многие вещи между языками программирования могут быть различными, концепция в основном совпадает. Универсальный процесс проектирования Существует широкое расхождение во мнениях о том, какой должен быть идеальный процесс проектирования. Kees Dorst и Judith Dijkhuis согласились с тем, что есть куча способов описаний процессов и обсудили два основных принципиально разных способа — рациональная модель и эволюционная модель. Хотя эти модели имеют свои различия, их основная роль заключается в определении процесса разработки. Таким образом они могут быть использованы в качестве самых основных мостов между дисциплинами. Рациональная модель Модель рационального представления процесса проектирования в виде плана, последовательного прохождения отдельных этапов. Этапы конструкторской подготовки производства, конструкции в процессе производства, пост-продакшн, дизайн и редизайн — состоят из нескольких более мелких процессов. Проблема в том, что цели и потребность могут меняться. Хотя используется этот метод довольно редко, но выступает в качестве основы для создания многих процессов проектирования для всех дисциплин. Эволюционная модель В эволюционной модели более спонтанных подход к созданию процессов, состоящий из многих взаимосвязанных понятий. Модель представляется без определенной последовательности этапов — различных стадий (анализ, проектирование, реализация) все современное.Дизайнеры использую творческих подход, создавая возможности для дизайне. Никаких рамок. Сам себе творец. Поскольку этот метод не так жесток, как Рациональный, он присутствует абсолютно во всех дисциплинах.В основном это только парадигмы о том, как мы разрабатываем. Метод может быть применен в любом процессе дизайна — что делает его краеугольным камнем в изучении новых месторождений. Роль дизайнера При размышлении о том, кто такие дизайнеры, большинство людей видят их как профессионалов дизайна с сильными фактическими и процедурными знаниями. Дизайнеры также должны знать взаимосвязь между основными элементами в рамках более крупных структур(дисциплине дизайна в целом и т.д) которые позволяют работать им вместе (т.е. классификации, категории, принципы, теории, модели, структуры), также известные как концептуальные знания. Эти знания являются частью общей языковой конструкции, как большинство из области, которые она охватывает. Заключение Дизайн-мышление это как сознание человека. Мы можем исследовать и испытывать его, и он всегда будет в состоянии перестроиться и предоставить нам новые захватывающие вещи. Быть дизайнером, значит быть способным к исследованиям, адаптивности и выдуманности. Как однажды сказал Edith Widder: Разведка — двигатель инноваций! Уважаемые Хабражители! С нетерпением жду от Вас в комментариях историй о том, как вы оттачиваете свои навыки в области дизайна, можете ли вы назвать себя дизайнеров и когда вы впервые начали заниматься дизайном.

Метки:  
Нравится

Релиз интеграционной платформы Ensemble 2016.1
Понедельник, 18 Июля 2016 г. 21:22 + в цитатник
Вышла новая версия интеграционной платформы InterSystems Ensemble 2016.1. Ключевые новшества: улучшение функциональности сервисной шины предприятия (Enterprise Service Bus, ESB), мониторинга и работы с сообщениями. Подробности под катом. Реестр сервисов и улучшенные инструменты для использования Ensemble в качестве ESB Новый релиз облегчает использование InterSystems Ensemble в качестве ESB без необходимости писать собственный код. Это стало возможно благодаря следующим функциям: Реестр публичных сервисов — с REST API, предоставляющим список сервисов, доступных в ESB. Реестр внешних сервисов — предоставляет механизм для идентификации и описания серверов, реализующих сервисы. Улучшенные “сквозные” сервисы и операции — предоставляет эффективный способ маршрутизации запросов сервисов от конечного пользователя к серверам с помощью Реестра внешних сервисов. Обработка без сохранения данных синхронных "сквозных" запросов. Эти возможности облегчают разработку сервисной шины предприятия (Enterprise Service Bus), которая эффективно маршрутизирует запросы от сервисов и предоставляет среду управления для поддержки и документации шины и сервисов. С помощью “сквозных” сервисов и операций можно уменьшить накладные расходы и увеличить пропускную способность решения, используя нехранимые сообщения вместо хранимых. Больше подробностей можно найти в документации, в разделе “Using Ensemble as an ESB” Статистика и мониторинг объема активности В данный релиз включен новый пакет “Статистика и мониторинг объема активности”, предоставляющий улучшенный краткосрочный мониторинг производительности системы и долгосрочную отчетность о трафике сообщений. Основные возможности пакета: Централизованное хранилище статистики сообщений Панель DeepSee, показывающая текущую скорость сообщений и время ответа каждого интерфейса Возможность изменять степень детализации для долгосрочной и краткосрочной статистики Долгосрочное хранилище статистики сообщений (для построения отчетов) Пользовательский сбор статистики с использованием метрик, специфичных для приложения Статистика хранится компактным и эффективным способом и не требует много дискового пространства даже по истечении длительного периода сбора статистики. Встроенный монитор дает возможность просматривать текущие статистические данные в разрезе различных временных отрезков, однако статистика, хранимая в базе данных, предоставляет более богатый набор данных. SuperSessionID Некоторые большие решения, построенные на Ensemble, состоят из нескольких продукций, которые могут быть запущены на разных экземплярах Ensemble. Например, InterSystems HealthShare Information Exchange включает в себя множество экземпляров Ensemble, общающихся между собой с помощью SOAP. В предыдущих версиях не существовало механизма отслеживания сообщения, когда оно переходило из продукции одного экземпляра Ensemble в продукцию другого экземпляра. При этом внутри одной продукции отслеживать сообщение было довольно легко, так как оно имело SessionId, который сохранялся при переходе сообщения между различными бизнес-операциями, сервисами и процессами. Но как только сообщение покидало бизнес-операцию через SOAP-сообщение, продукция, которая это сообщение принимала, назначала ему новый SessionId. Данный релиз вводит новое свойство заголовка сообщений — SuperSession. Настройка SendSuperSession исходящего HTTP-адаптера контролирует использование свойства SuperSession. Если SendSuperSession включена, то исходящий HTTP-адаптер действует следующим образом: Проверяет, содержит ли свойство Ens.MessageHeaderBase.SuperSession пустое значение. Если значение пустое, то адаптер генерирует новое значение и записывает его в свойство. Сохраняет значение свойства SuperSession в приватном HTTP-заголовке InterSystems.Ensemble.SuperSession исходящего сообщения. Когда входящий HTTP-адаптер получает сообщение, он проверяет значение свойства SuperSession в заголовке и, если значение непустое, сохраняет его в свойстве Ens.MessageHeaderBase.SuperSession. Вы можете использовать значение параметра SuperSession для сопоставления сообщения из одной продукции с сообщением в другой. Внимание: в данной версии нет инструментов для автоматического отслеживания сообщений между продукциями с использованием SuperSession. Несмотря на то, что настройка SendSuperSession присутствует в конфигурации многих компонентов Ensemble, в текущей версии она используется только в EnsLib.HTTP.OutboundAdapter. Другие важные изменения Улучшение поддержки X12 В рамках предстоящей программы расширенной поддержки стандарта электронного обмена данными X12 вы можете просматривать схемы X12 HIPAA_4010 и HIPAA_5010 с помощью просмотрщика унаследованных структур. Графические редакторы Ensemble Интерфейс редактора Data Transformation Language претерпел множество мелких изменений для большего удобства пользователей. Например, если вы добавите функцию в правило, редактор покажет ее опциональные и обязательные параметры. Перезапуск продукции Управление необработанными сообщениями во время перезапуска продукции было переосмыслено. Текущая реализация существенно ускорила остановку и перезапуск продукции в случае, когда в очереди накопились сотни тысяч сообщений. Улучшения Банка сообщений В этом релизе Банк сообщений получил следующие изменения: Банк сообщений распознает, когда экземпляр Ensemble, посылающий в банк сообщения, переподключился с нового IP-адреса. Если вы активируете настройку “Ignore Client IP Changes” в компоненте Ens.Enterprise.MsgBank.TCPService, Банк сообщений распознает экземпляра Ensemble как тот же самый, даже если он переподключится с другого IP. Если эта настройка останется неактивной, Банк сообщений будет считать переподключенный экземпляр Ensemble новым источником сообщений. XML-сообщения сериализуются в поток перед отправкой в Банк сообщений. В предыдущих версиях, просмотрщик Банка сообщений отображал такие сообщения без отступов и переносов строк. В текущей версии сообщения показываются с правильным XML-форматированием. Более подробную информацию можно найти в главе “Configuring the Message Bank Service on the Server” раздела Configuring Ensemble Productions. Новый фильтр в Трассировке сообщений В этот релиз добавлен новый фильтр в Трассировку сообщений. Перед тем, как вы примените фильтр, вам необходимо выбрать сообщение, столбец (компонент конфигурации), ACK или IOLog. Затем, из выпадающего списка вы сможете выбрать значения фильтра “Хост” или “Соответствует”. Если вы выбрали сообщение, фильтр со значением “Хост” отображает сообщения, у которых источник и цель такие же, как у выбранного сообщения. Фильтр со значением “Соответствует” показывает подходящий запрос или ответ. Если вы выбрали столбец (хост), фильтр со значением “Хост” находит все сообщения, начинающиеся или заканчивающиеся в этом столбце (хосте). Если вы выбрали ACK или IOLog, фильтр со значением “Соответствует” найдет соответствующий запрос или ответ. Подробности можно найти в главе “Tracing the Path of Related Messages” раздела Monitoring Ensemble. Новая опция для перезапуска компонента продукции Теперь при двойном щелчке на активном компоненте продукции, у вас будет возможность выбрать, отключить компонент или перезапустить его. Все изменения Cache 2016.1 Ensemble 2016.1 построена на основе СУБД и сервера приложений Cache 2016.1. Это значит, что в дополнение ко всем изменениям в Ensemble 2016.1 новая версия также включает и все изменения Cache. Про изменения в Cache 2016.1 можно почитать в недавней статье на Хабре.

Метки:  
Нравится

[Из песочницы] Принцип Доверия (Trust) в HTTPS
Воскресенье, 17 Июля 2016 г. 14:49 + в цитатник
Сейчас уже, наверное, больше половины серверов перебрались с http на https протокол. Зачем? Ну, это мол круто, секъюрно. В чем же заключается эта секъюрность? На эту тему уже написана куча статей, в том числе и на Хабре. Но я бы хотел добавить еще одну. Почему решил написать Я, вообще, по специальности Android разработчик, и не особо шарю в криптографии и протоколах защиты информации. Поэтому когда мне пришлось столкнуться с этим непосредственно, я был немного в шоке от размера пропасти в моих теоретических знаниях. Я начал рыться в разных источниках, и оказалось, что в этой теме не так просто разобраться, и тут недостаточно просто прочитать пару статей на Хабре или Вики, при чем я нигде не встретил абсолютно исчерпывающего и понятного источника, чтобы сослаться и сказать — "Вот это Библия". Поэтому у меня это "немного разобраться" заняло кучу времени. Так вот, разобравшись, я решил поделиться этим, и написать статью для таких же новичков, как и я, или просто для людей, которым интересно зачем в строке URL иногда стоит https, а не http. Что значить защищенный канал связи? Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа: Доверие (Trust) — взаимная аутентификацию абонентов при установлении соединения. Шифрование (Crypting) — защита передаваемых по каналу сообщений от несанкционированного доступа. То есть, говорить и слушать во время диалога можете только вы и ваш собеседник. Обеспечение целостности — подтверждение целостности поступающих по каналу сообщений, т.е. сообщения не могут подвергаться полной или частичной замене информации. В этой статье я хотел бы рассказать подробно только о механизме Доверия. Что значить Доверие (Trust)? Вы можете доверять вашему собеседнику только если точно знаете, что он — тот, за кого себя выдает. Самый простой пример — вы знаете собеседника лично, более сложный — вы знаете кого-то кто лично знает вашего предполагаемого собеседника и этот кто-то гарантирует что собеседнику можно доверять. Жизненный пример Представим, Вы хотите купить квартиру. Для этого Вы находите Риэлтора, который занимается продажей квартир. Риэлтор говорит, что он работает с неким Застройщиком, и предлагает квартиру от этого Застройщика. Застройщик говорит, что жилье, которое он строит будет, сдано, и те кто заплатил за него деньги Риэлтору, получит его в собственность, и легальность строительства и право собственности будет обеспечена Государством. Итого у нас есть 4 субъекта Вы, Риэлтор, Застройщик, Государство. Для того чтобы сделка успешно состоялась и никто никого не обманул Государство создало законы, определяющие документы, которые гарантируют легальность сделок, и механизм печати или подписи, который гарантирует подлинность этих документов. У Вас есть примеры этих документов и печатей, вы можете их взять у Государства. Вы имеете право требовать у Риэлтора оригиналы документов на строительство. Риэлтор берет документы Застройщика, которые подкреплены документами Государства и убеждается, что квартиры можно продавать — они легальны. Застройщик же в свою очередь получает документы у Государства. Т.е. теперь вы можете смело вести диалог только с Риэлтором, основываясь на его документах, скрепленных печатями Застройщика и Государства! Доверие в HTTPS А теперь поменяем имена действующих лиц из Жизненного примера. Вы = Клиент (Client) Риэлтор = Сервер (Server) Застройщик = Промежуточный Центр Сертификации (Intermediate CA) Государство = Главный Центр Сертификации (Root CA) Главный Центр Сертификации (Root Certificate Authority, CA) — общепризнанная известная компания, которой международные организации выдали полномочия заведовать сертификатами и подписями, короче этой компании доверяют все. Она может давать некоторые полномочия Промежуточным центрам Сертификации (Intermediate CA), и они будут подписывать документы от имени Главного Центра. Перейдем к математике Были упомянуты слова: подпись, сертификат и т.д. Как это реализовать? В помощь приходит асимметричное шифрование. Чтобы не вдаваться в подробности и не объяснять дискретную математику и криптографию, уясним пару вещей: 1) Коротко и о главном об асимметричном шифровании. Есть 2 ключа — Публичный и Приватный (Public Key and Private Key). Собственно, ключи — это просто большие числа. Если сообщение шифруется Публичным, то его может расшифровать только соответствующий ему Приватный ключ. И наоборот: Если сообщение шифруется Приватным, то его может расшифровать только соответствующий ему Публичный ключ. Приватный ключ никому не дается, Публичный — собственно, публичный. 2) Цифровая подпись (Digital Signature) — это часть документа, зашифрованная Приватным ключем Подписчика (Issuer). Если ее можно расшифровать Публичным Ключем Подписчика, то можно с уверенностью утверждать, что именно Подписчик ее шифровал. 3) Сертификат (Digital Certificate) — это обычно файл, чаще всего с расширением .cer или .pem. В нем содержится: Информация о владельце (Subject) Инфомация о Подписчике (Issuer) Информация о подписи (Версия SSL, алгоритм) Хэш подписи (Certificate Fingerprints) Public Key Цифровая подпись (Signature) Срок годности (Expires) И еще много информации, в зависимости от версии, но остальное нам пока не нужно. Пример СертификатаCOMODO Certification Authority Identity: COMODO Certification Authority Verified by: COMODO Certification Authority Expires: 31.12.29 Subject Name C (Country): GB ST (State): Greater Manchester L (Locality): Salford O (Organization): COMODO CA Limited CN (Common Name): COMODO Certification Authority Issuer Name C (Country): GB ST (State): Greater Manchester L (Locality): Salford O (Organization): COMODO CA Limited CN (Common Name): COMODO Certification Authority Issued Certificate Version: 3 Serial Number: 4E 81 2D 8A 82 65 E0 0B 02 EE 3E 35 02 46 E5 3D Not Valid Before: 2006-12-01 Not Valid After: 2029-12-31 Certificate Fingerprints SHA1: 66 31 BF 9E F7 4F 9E B6 C9 D5 A6 0C BA 6A BE D1 F7 BD EF 7B MD5: 5C 48 DC F7 42 72 EC 56 94 6D 1C CC 71 35 80 75 Public Key Info Key Algorithm: RSA Key Parameters: 05 00 Key Size: 2048 Key SHA1 Fingerprint: 11 E4 91 D1 C9 E4 C0 EB 9A CE CF 73 54 5D E1 F1 A8 30 3E C3 Public Key: 30 82 01 0A 02 82 01 01 00 D0 40 8B 8B 72 E3 91 1B F7 51 C1 1B 54 04 98 D3 A9 BF C1 E6 8A 5D 3B 87 FB BB 88 CE 0D E3 2F 3F 06 96 F0 A2 29 50 99 AE DB 3B A1 57 B0 74 51 71 CD ED 42 91 4D 41 FE A9 C8 D8 6A 86 77 44 BB 59 66 97 50 5E B4 D4 2C 70 44 CF DA 37 95 42 69 3C 30 C4 71 B3 52 F0 21 4D A1 D8 BA 39 7C 1C 9E A3 24 9D F2 83 16 98 AA 16 7C 43 9B 15 5B B7 AE 34 91 FE D4 62 26 18 46 9A 3F EB C1 F9 F1 90 57 EB AC 7A 0D 8B DB 72 30 6A 66 D5 E0 46 A3 70 DC 68 D9 FF 04 48 89 77 DE B5 E9 FB 67 6D 41 E9 BC 39 BD 32 D9 62 02 F1 B1 A8 3D 6E 37 9C E2 2F E2 D3 A2 26 8B C6 B8 55 43 88 E1 23 3E A5 D2 24 39 6A 47 AB 00 D4 A1 B3 A9 25 FE 0D 3F A7 1D BA D3 51 C1 0B A4 DA AC 38 EF 55 50 24 05 65 46 93 34 4F 2D 8D AD C6 D4 21 19 D2 8E CA 05 61 71 07 73 47 E5 8A 19 12 BD 04 4D CE 4E 9C A5 48 AC BB 26 F7 02 03 01 00 01 Subject Key Identifier Key Identifier: 0B 58 E5 8B C6 4C 15 37 A4 40 A9 30 A9 21 BE 47 36 5A 56 FF Critical: No Key Usage Usages: Digital signature Critical: Yes Basic Constraints Certificate Authority: Yes Max Path Length: Unlimited Critical: Yes Extension Identifier: 2.5.29.31 Value: 30 40 30 3E A0 3C A0 3A 86 38 68 74 74 70 3A 2F 2F 63 72 6C 2E 63 6F 6D 6F 64 6F 63 61 2E 63 6F 6D 2F 43 4F 4D 4F 44 4F 43 65 72 74 69 66 69 63 61 74 69 6F 6E 41 75 74 68 6F 72 69 74 79 2E 63 72 6C Critical: No Signature Signature Algorithm: SHA1 with RSA Signature Parameters: 05 00 Signature: 3E 98 9E 9B F6 1B E9 D7 39 B7 78 AE 1D 72 18 49 D3 87 E4 43 82 EB 3F C9 AA F5 A8 B5 EF 55 7C 21 52 65 F9 D5 0D E1 6C F4 3E 8C 93 73 91 2E 02 C4 4E 07 71 6F C0 8F 38 61 08 A8 1E 81 0A C0 2F 20 2F 41 8B 91 DC 48 45 BC F1 C6 DE BA 76 6B 33 C8 00 2D 31 46 4C ED E7 9D CF 88 94 FF 33 C0 56 E8 24 86 26 B8 D8 38 38 DF 2A 6B DD 12 CC C7 3F 47 17 4C A2 C2 06 96 09 D6 DB FE 3F 3C 46 41 DF 58 E2 56 0F 3C 3B C1 1C 93 35 D9 38 52 AC EE C8 EC 2E 30 4E 94 35 B4 24 1F 4B 78 69 DA F2 02 38 CC 95 52 93 F0 70 25 59 9C 20 67 C4 EE F9 8B 57 61 F4 92 76 7D 3F 84 8D 55 B7 E8 E5 AC D5 F1 F5 19 56 A6 5A FB 90 1C AF 93 EB E5 1C D4 67 97 5D 04 0E BE 0B 83 A6 17 83 B9 30 12 A0 C5 33 15 05 B9 0D FB C7 05 76 E3 D8 4A 8D FC 34 17 A3 C6 21 28 BE 30 45 31 1E C7 78 BE 58 61 38 AC 3B E2 01 65 Что же происходит на каждом из субъектов 1) Начнем с Root CA Генерируется Private Key Генерируется Public Key Добавляется информация о CA, задается срок годности Сертификат подписыватся своим же Приватным Ключем: Выбирается сообщение для шифровки (Message). Что именно шифровать, определяет алгоритм и версия SSL. Для конечного пользователя это неважно, так как все версии шифрования и хэширования также помещаются в сертификат, и при расшифровке эти же версии и используются. Message шифруется, и получается цифровая подпись Message хэшируется, и получается FingerPrint. Все это собирается в кучу и получается, так называемый, Самоподписанный сертификат (Self Signed Certificate). 2) Этот Self Signed Certificate раздается клиентам Пример клиента — браузер. В любом браузере можно посмотреть список сертификатов. Например в Chrome: Settings -> Manage Certificates -> Authorities. Теперь клиент знает про существование CA. 3) Подтверждение своей аутентичности Если не вдаваться в детали, то этот пункт одинаков для Сервера и Промежуточных Центров Аутентификации Генерируется Private Key Генерируется Public Key Добавляется информация о CA, определяется срок годности Формируется, так называемый, Запрос на Сертификацию (Certificate Signing Request, CSR) CSR подписывается Приватным Ключем близжайшего по цепи Центра Сертификации. Собственно, так это и называется Certificate Chain, когда Центры Сертификации друг за другом подписывают следующий сертификат, вплоть до конечного — Сертификата Сервера. В итоге, имеем Self Signed Certificate на клиенте и Signed Server Certificate на сервере, т.е. клиент знает и доверяет СА и СА прогарантировал аутентичность сервера. 4) Непосредственно диалог Теперь глянем что же происходит при обращении клиента к серверу. Для этого используем Network dump от Wireshark. TCP 3 way handshake — механизм начала соединения по TCP протоколу. Из dump-а видно, что клиент, с порта 33311 инициировал соединение с сервером, запущенном на порте 8443. Secure Data Transmission — это уже передача, непосредственно, данных по шифрованному каналу TLS handshake — это то что нас и интересует. Подробно об этом можно почитать здесь, но мы рассмотрим только работу с сертификатами. Мы видим сообщения: Client Hello, Server Hello, Change Cipher Spec, Encrypted Handshake Message Ниже показано, что эти сообщения с собой несут: Как видим, вместе с Server Hello Клиенту приходит Цепочка Сертификатов Сервера (Server Certificate). Как клиент проверяет подлинность Сертификата. Как это происходит: 1) Клиент смотрит, есть ли у него Root CA для верхнего сертификата в цепочке, если нет — спускается по цепочке ниже, при чем каждый раз перепроверяет, действительно ли подписан сертификат предыдущим в цепочке. (Это просто — цифровая подпись нижнего должна расшифровываться публичным ключем верхнего). Если не нашел, значить у Клиента и Сервера нет общего знакомого CA, доверять серверу нельзя. 2) если есть — Клиент берет Публичный Ключ своего сертификата и пробует расшифровать подпись сертификата, пришедшего с Сервера. если не получилось, значить Сервер подменил сертификат CA и ему нельзя доверять ну и, наконец, если все ок, все расшифровалось, сроки годности всех сертификатов валидны, и выполнены еще какие-то условия, которые определяет версия SSL, тогда серверу можно доверять. Примечание Протокол TLS также поддерживает механизм доверия Сервера к клиенту. Как видно из рис 5, в ответ на Server Hello, может прийти сертификат клиента, и сервер тоже может удостовериться, что CA гарантировал его аутентичность. Заключение Итак, когда обе стороны убедились, что их собеседники — те за кого себя выдают, можно начинать диалог. При чем, сразу же есть все для дальнейшего шифрования сообщений — приватный ключ на стороне сервера, и его публичный ключ на клиенте, который был прислан с сертификатом сервера. Но в дальнейшем асимметричное шифрование используется только один раз — когда клиент шифрует пароль публичным ключем сервера, и отправляет серверу — KlientKeyExchange. Далее уже этот пароль используется для симметричного шифрования сообщений, так как оно значительно быстрее и проще асимметричного. Механизмы выбора протокола шифрования и обеспечения целостности сообщений — это огромная область математики и криптографии, но, к счастью для пользователя, она уже реализована под капотом SSL. Все что надо — чтобы на клиенте и сервере были совместимые версии SLL, шифров, криптопровайдеров. В конце хотелось бы сказать, что протоколы безопасной коммуникации: очень сложны и запутаны — есть море версий, протоколов, шифров, при чем никогда не знаешь, когда тебе вылезет сообщение — "NoSuchAlgorithmException — Какие-то версии чего-то не совместимы" или "IllegalBlockSizeException — Размер чего-то слишком большой или маленький" непостоянны — сегодня браузер нормально заходит на ваш сервер, а завтра уже скажет — что 2048 — это слишком маленькая длина ключа, мол несекьюрно, и не зайдет вычисления, особенно при асимметрично шифровании, очень ресурсоемки, и на системах всего 5-7 летней давности процесс TLS Handshake может занять 10-20 секунд Но главный, и пожалуй, достаточный, аргумент за — HTTPS и TLS действительно безопасны, насколько это возможно. Полезные ссылки по теме http://www.youdzone.com/signature.html https://habrahabr.ru/post/258285/ https://datacenteroverlords.com/2012/03/01/creatin...own-ssl-certificate-authority/ http://superuser.com/questions/126121/how-to-create-my-own-certificate-chain

Метки:  
Нравится

Профили пользователей в аналитике, или как стать Шерлоком Холмсом
Вторник, 05 Июля 2016 г. 21:16 + в цитатник
Если вы зачитывались историями про Шерлока Холмса или смотрели многочисленные экранизации, то наверняка помните название метода, который использует герой для раскрытия запутанных дел. На всякий случай напомним: он пользуется индукцией — переходом от частного к общему в противовес дедукции, когда из общих данных делают вывод о частных. Как же использовать метод индукции для изучения поведения пользователей в нашем приложении?.. «Элементарно!»- сказал бы герой сэра Арутра Конан Дойля. «Именно так», – вторит ему ведущий аналитик devtodev Василий Сабиров. источник картинки www.smartdatacollective.com/sites/smartdatacollect...a-Analytics-and-BI-Attivio.png До недавнего времени большинство аналитических систем предлагали работу по дедуктивному методу: проводился анализ всех пользователей сразу, а вывод делался о поведении каждого конкретного пользователя. Нельзя считать это ошибкой, но для более точных выводов всё же стоит применить и индуктивный метод. И теперь сервис devtodev рад представить новый функционал аналитических систем, в основу которого положен на индуктивный метод: анализ профилей пользователей. Если вы задались целью точнее понять свой проект, то сначала вы встраиваете в него аналитику и начинаете видеть определенные метрики (DAU, ARPU, LTV, и так далее) и отчёты. Означает ли это, что вы до конца понимаете проект, над которым работаете? Не совсем. Да, вы можете делать выводы о поведении большинства, однако взглянуть на проект глазами конкретного пользователя у вас пока не получится. Чтобы увидеть продукт с этой точки зрения, нужно проследить поведение конкретного пользователя: какие действия он совершает, с какими проблемами сталкивается, понимает ли он суть вашего продукта. Последив за каждым пользователем и узнав, какие действия он совершает внутри продукта, вы, без сомнения, сможете лучше понять его. Профили пользователей в системе Amplitude источник картинки amplitude.zendesk.com/hc/en-us/article_attachments/202671468/User_Search_2.png Проанализировав таким образом N пользователей, вы сможете собрать данные, необходимые для формулировки ряда гипотез об улучшении продукта. И их количество уж точно не будет меньше, чем по итогам анализа метрик по всем пользователям сразу. Практика показывает, что N при этом необязательно должно быть большим: при детальном изучении уже на третьем пользователе вы сформулируете какие-то гипотезы, на пятом — определяете проблемы, на десятом в вашей голове созревают планы на изменение и улучшение продукта. источник картинки www.ew.com/sites/default/files/1452454622/christian-bale_0_1.jpg Еще один пример из художественного произведения, на сей раз это фильм “Игра на понижение”. Внимательный зритель помнит, как герой Кристиана Бейла изучает огромную таблицу с ипотечными кредитами, взятыми каждым конкретным заемщиком, а потом опрашивает этих самых людей, находя таким образом предпосылки грядущего финансового кризиса. Банки же, привыкшие оценивать общую ситуацию, а не каждый случай в отдельности, не верят в приближение конца, так как в целом ситуация складывается отличная, и ничего не предвещает краха. Чем не яркий пример ошибочного анализа? В итоге формируется следующий тренд: многие аналитические системы на рынке запускают свои модули, предоставляющие возможность анализа профилей пользователей. У Localytics это Profiles, у Mixpanel — People, у Amplitude — User Activity. В devtodev мы создали продвинутый вариант такого модуля и назвали его Users. Из чего же складывается профиль пользователя? Во-первых, это информация, которая собирается аналитической системой по умолчанию: дата установки; язык; страна; часовой пояс; Устройство (девайс); версия ОС; канал трафика; версия приложения; и т.д. С помощью этой информации можно фильтровать пользователей по тем или иным параметрам, создавать сегменты и отслеживать в дальнейшем их поведение. Допустим, можно выбрать всех пользователей с iPad, всех из Франции, всех пришедших с Facebook, всех, кто используюет предыдущую версию приложения, и так далее. Фильтры можно комбинировать, чтобы ориентироваться на точечно выбранную аудиторию: англоговорящие пользователи из Западной Европы, пользующиеся новой версией приложения и зарегистрировавшиеся в сервисе не более двух месяцев назад. Во-вторых, в профилях хранится информация о платежах пользователя: когда он заплатил, сколько и за что. Вы будто примеряете его профиль на себя и начинаете лучше понимать мотив его действий: почему он купил именно этот IAP, почему между платежами прошло именно столько времени и так далее. Без профилей пользователей вы можете видеть монетизационные метрики, статистику покупок, и это, безусловно, очень полезная информация. Однако более глубинное понимание достигается именно за счёт перемещения на уровень игрока. В-третьих, профиль пользователя включает в себя статистику событий (custom events), которые происходили с пользователем в проекте. Вы начинаете видеть их последовательность, вы как бы смотрите видео о том, как конкретный человек пользуется вашим продуктом. Вот примеры некоторых вопросов, на которые можно ответить, используя такой метод: какое событие обычно следует после события A? какое событие предшествует событию B? все ли пользователи выполняют событие C после события D? или же уходят на событие E? какие события предшествуют уходу пользователя из проекта? Можно выбрать всех пользователей, входивших в магазин приложения (совершавших событие “Вход в магазин”) и оценить, какие события этому входу предшествовали и каким было поведение пользователя после входа в магазин. Так станет яснее, как происходит конверсия пользователя и в интерес к покупке, и непосредственно в переход к покупке, и как итог в успешный совершенный платёж. Профили пользователей в системе MixPanel источник картинки cdn.mxpnl.com/cache/81e4c82a27f699ba6153b46064105a1e/images/static/landing/marketing/people2/feature-illus.png И наконец, профиль пользователя включает в себя User Properties, которые определяете вы сами. Это может быть что угодно: уровень в игре, код группы при проведении A/B-теста, классификация по величине платёжной активности (minnow / dolphin / whale) и так далее. На все проекты стандартных методов на напасёшься, и наиболее правильной тактикой аналитической системы будет сформировать универсальный набор полезных параметров для отслеживания действий пользователя, оставив при этом возможность клиенту самостоятельно выбрать для анализа любой другой параметр. Практическая польза наличия профилей пользователей в системе аналитики очевидна, для сомневающихся приведу аргументы: С помощью этого модуля можно провести анализ “наоборот”, или индуктивный анализ, если хотите. Вы смотрите поведение конкретных пользователей и начинаете лучше понимать, что они чувствуют, используя ваш продукт На основе проведенного анализа можно отправить выбранным пользователям push-уведомления — некоторые системы (и devtodev в том числе) позволяют это сделать. Случай из практики: разработчики приложения заметили, что пользователь застрял на каком-то уровне, и отправили ему уведомление с подсказкой, как этот уровень пройти. Затем оказалось, что он не один такой, и значительное количество пользователей застревают на одном и том же уровне, а потом уходят из приложения в среднем на семь дней. Пока все дружно писали постановку на упрощение уровня (хотелось же, чтобы пользователи не уходили), всем застрявшим на уровне вы отправили push-уведомление с явной подсказкой. Что же сделали с теми, кто не входил в игру семь дней и больше? Правильно, разослали небольшой, но приятный бонус в виртуальной валюте с помощью тех же push-уведомлений, воспользовавшись передаваемыми параметрами. С помощью профилей пользователей легко тестировать интеграцию аналитической системы. Вообще, интеграция аналитики процесс нетрудный, но достаточно кропотливый: сначала надо сформировать набор событий, чётко понимая, что этих событий будет достаточно для последующих выводов (подробнее про это я писал тут). И когда интеграция закончена, не помешало бы её хорошенько протестировать. И здесь профили пользователей и работа аналитики в реальном времени будут хорошим подспорьем: вы самостоятельно открываете приложение, совершаете цепочку событий, затем находите в аналитике свой профиль и просто смотрите, правильно ли передались события с параметрами. Если же аналитику правильно не тестировать, то итерация на исправление может занять более месяца, который можно было б посвятить более нужным вещам. И наконец, увеличивается доверие к аналитической системе. Допустим, эта самая система что-то вам посчитала (напрмер, ARPU = $0,2), и вы не знаете, как это значение было получено и можно ли ему вообще доверять. Как представитель аналитического сервиса заявлю, что доверять можно, однако я прекрасно понимаю людей, испытывающих легкое недоверие к системе, считая её чёрным ящиком. Часто людям, работающим с данными, хочется самим выгрузить данные и перепроверить всё руками. Наличие профилей пользователей увеличивает доверие к системе аналитики: вы видите не голые цифры, а данные по каждому пользователю отдельно, а возможность выгрузки данных как раз даёт возможность особенно недоверчивым персонам выгрузить данные и посчитать всё самим. Таким образом, наличие профилей пользователей взаимовыгодно и для клиента, и для самой аналитической системы. Таким образом, анализ профилей пользователей существенно упрощает жизнь и клиенту аналитической системы, и самой системе, оставляя современного Шерлока Холмса не у дел. У клиента появляется гораздо больше возможностей для оценки действий пользователей, и главная из них — это возможность проведения индуктивного анализа (анализа “наоборот”). Важно, что и сама система остается в выигрыше, заручаясь еще большим доверием со стороны клиента.

Метки:  
Нравится

Dell Storage SC9000: интеллектуальная система хранения для эффективного дата-центра
Воскресенье, 26 Июня 2016 г. 11:05 + в цитатник
Рост требований к производительности СХД заставляет вендоров искать новые подходы к созданию оптимальной архитектуры систем хранения данных и наряду с традиционными дисками использовать флэш-память. Разработка серверов и систем хранения данных является одним из приоритетов Dell, куда компания инвестирует значительные средства. В настоящее время она предлагает новые системы резервного копирования и хранения данных для разных видов бизнеса. Рассмотрим подробнее систему хранения Dell SC9000. Аппаратная платформа Новый дисковый массив Dell SC9000 выпущен в октябре 2015 года и определенно заслуживает того, чтобы взглянуть на него внимательнее. Это флагманское решение уже можно увидеть в крупных дата-центрах мира. Но к системе стоит присмотреться и средним компаниям. Хранилище SC9000 с многопетабайтной емкостью и операционной системой Storage Center 7.0 предлагает новые возможности для ИТ-подразделений. Аппаратная платформа SC9000, старшая в линейке массивов серии SC, отличается самой высокой производительностью и масштабируемостью — до 960 накопителей SAS SSD и / или HDD на массив, причем массивы можно объединять в группы (федерация). Уже доказавшая свою надежность платформа оснащена новыми 8-ядерными процессорами Intel, вчетверо увеличена емкость системной памяти, а в качестве бэкенда используется интерфейс SAS 12 Гбит/с. Система поддерживает протоколы SAN (FC, iSCSI, FCoE), а также NAS через опциональное устройство FS8600. Производительность системы по сравнению с предыдущими продуктами SC выросла на 40 %. Внутренние тесты показали, что быстродействие массива SC9000 превышает 360 тыс. IOPS при задержке менее миллисекунды. Кроме того, вдвое выросла пропускная способность, а это означает отсутствие узких мест при росте нагрузки. В основе Dell SC9000 – новая серверная платформа Dell PowerEdge 13-го поколения с четырьмя 8-ядерными процессорами Intel Xeon с тактовой частотой 3,2 ГГц и оперативной памятью емкостью до 512 Гбайт. Систему можно конфигурировать как флэш-массив или гибридную СХД. Благодаря применению компонентов с возможностью резервирования и горячего подключения SC9000 является отказоустойчивым и простым в развертывании решением с высокой доступностью. Полки расширения SC400/420, SC200/220 или SC280 позволяют наращивать емкость. Система поддерживает унифицированное управление с массивами SC8000, SC4020, SCv2000. Емкость флэш-массива составляет до 46 Тбайт на 1U (без сжатия данных). Такой плотности удалось добиться благодаря применению в СХД трехуровневой памяти Samsung TLC 3D NAND. Система SC9000 предоставляет более 3 Пбайт чистой емкости, причем массивы можно объединять в группы, если рабочим нагрузкам требуются большие объемы хранения. Полки расширения SC280 (а это 96 HDD 3,5”) дают емкость более 100 Тбайт на 1U. Это можно использовать для медиаархивов или в приложениях, работающих с крупными файлами. Программные средства Несмотря на впечатляющие характеристики аппаратной платформы, многими своими качествами SC9000 обязана софту. Виртуализированная программная среда Storage Center с функциями автоматизации делает систему более экономичной и адекватной широкому спектру задач. Сравнение программных средств массивов серии SC. Программное обеспечение Dell Storage Center 7.0, оснащенное новыми функциями, обеспечивает улучшенную поддержку устройств Dell Storage серии SC в частных облачных средах и других критически важных приложениях. Посмотрим, что тут нового. Улучшенная оптимизация для работы с флэш-памятью Принимая во внимание, что высокая стоимость флэш-памяти является основным барьером для принятия этой технологии, Dell сфокусировалась на повышении эффективности использования накопителей, чтобы снизить их стоимость. Об оптимизации заявляют многие вендоры, но часто используется упрощенный подход с одним уровнем хранения, при котором все виды флэш-памяти ведут себя одинаково. Современные технологии виртуализации Dell позволяют использовать различные типы флэш-памяти в одном и том же массиве для запуска различных рабочих нагрузок и различных сценариев применения. Благодаря этому компания смогла выпустить серию высокоскоростных и экономичных массивов как полностью на базе флэш-памяти, так и в гибридном исполнении. В автоматическом тиринге Dell учитываются разные параметры цены/производительности SSD разного типа. То есть для достижения высокой производительности в IOPS не потребуется выложить запредельную сумму. Вот почему у флэш-массивов Dell стоимость хранения составляет всего 0,65 центов за гигабайт. Ну а в гибридных СХД этот показатель еще ниже. Глубокий тиринг, не ограниченный флэш-памятью Чтобы увеличить срок службы памяти 3D NAND, задействован механизм тиринга – перемещения данных между уровнями хранения. Первый уровень (Tier 1) представлен флэш-памятью SLC или eMLC, выдерживающей большое количество циклов перезаписи, второй (Tier 2) – памятью 3D NAND, в которую записываются относительно редко используемые данные, причем в сжатом виде. В некоторых моделях есть и третий уровень (Tier 3) – HDD. Конфигурацию системы (соотношение емкости разных видов флэш-памяти и жестких дисков) можно подбирать с учетом характера нагрузки: для этого есть соответствующая утилита. WI – для интенсивной записи, RI –- для интенсивного чтения Применяемые Dell методы тиринга – одни из самых полных в отрасли. Массивы SC позволяют создавать унифицированные пулы хранения данных SAN и/или NAS из разнородных систем, формировать тома из носителей разного типа (в том числе включать в них Tier 0 – кэш на стороне сервера), задавать гибкие конфигурации RAID. За счет автоматического размещения данных на соответствующем уровне хранения в реальном времени ускоряется «прогрев» данных и их «остывание». Но главное – упрощается управление, и удается выжать все возможное из накопителей с точки зрения производительности. Интеллектуальное размещение данных и оптимизация хранения на всех уровнях. Запатентованная технология автоматического многоуровневого размещения данных использует основные преимущества различных типов накопителей для оптимизации данных на протяжении всего жизненного цикла. Быстрое внедрение новых технологий Та же виртуализация, которая помогает массивам серии SC демонстрировать свои преимущества в соотношении цена/производительность, позволяет внедрять новые решения. Хороший пример – TLC 3D NAND. Выпустив прошлым летом накопители Mainstream Read-Intensive, Dell вдвое снизила стоимость флэш-памяти Tier 2 без уменьшения долговечности или быстродействия. Память TLC успешно применяется в ее массивах старшего класса, в то время как конкуренты все еще пытаются изменить архитектуру одноуровневых систем младшего класса. Быстрое вертикальное и горизонтальное масштабирование для удовлетворения потребностей в хранении данных и производительности. Одновременная вертикальная и горизонтальная масштабируемость делает массивы SC хорошо расширяемыми. Гибкая самооптимизирующаяся система SC9000 позволяет получить более 3 Пбайт чистой емкости и объединять массивы в группы, обеспечивая необходимой емкостью крупные рабочие нагрузки. Массив SC9000 обеспечивает быстрое модульное расширение благодаря поддержке сетей хранения данных (SAN) и сетевых систем хранения данных (NAS). Его также можно подключать к другим массивам серии SC в более крупных федеративных системах с единым управлением. Программное обеспечение SCOS включает в себя опциональный «гипервизор хранения», позволяющий легко перемещать данные по «федерации» массивов. И даже в случае наращивания одного дискового массива можно получить емкость и производительность крупной распределенной системы с унифицированным управлением. Dell Volume Advisor даст рекомендации по проактивному балансированию нагрузки на основе заданных правил. Он осуществляет мониторинг федерации массивов и советует, где лучше разместить данные. Эффективное использование емкости Массивы серии SC с программным обеспечением SCOS 7.0 поддерживают интеллектуальное сжатие данных на флэш-накопителях и HDD. Тем самым достигается значительная экономия емкости. Функция сжатия интегрирована с тирингом, поэтому сжатие не снижает производительности. При этом активны такие функции, как динамическое распределение емкости. Сжатие данных обеспечивает серьезную экономию емкости хранения, что особенно важно для флэш-памяти. За счет сжатия данных, достигающего 93 % в случае с базами данных Microsoft SQL, решение становится еще более экономичным: флэш-массив оказывается сопоставим по цене с дисковым массивом на базе HDD SAS 15k. Сжатие происходит, когда блоки данных перемещаются на нижние уровни, тем самым уменьшается влияние сжатия данных на производительность системы. При перемещении активных блоков на верхние уровни они остаются сжатыми. Постоянная доступность Новая функция SCOS 7.0 под названием Live Volume Auto-Failover предотвращает незапланированные простои. При отказе ПО Storage Center перенаправляет нагрузку на синхронизированные с основным резервные тома на другом массиве и запускает процедуру восстановления. Вмешательства администратора не требуется. Благодаря переназначению хостов можно вносить изменения в СХД, не влияя на работу пользователей и приложений. Прозрачное для сервера перемещение томов между массивами в федеративном кластере повышает эффективность использования кэша и емкости при растущих нагрузках. Еще одна примечательная технология SC9000 – функция автоматической замены сбойного массива Live Volume, позволяющая работать без простоев. Она дает возможность «растягивать» тома между площадками при помощи средств самого дискового массива. В результате создается недорогое катастрофоустойчивое решение, не требующее перестройки архитектуры хранения данных. Функция Live Volume с автоматическим переключением при отказе обеспечивает непрерывную работу системы при перебоях электропитания и автоматически восстанавливает среду высокой доступности при включении массива. Установка дополнительного оборудования или программного обеспечения не требуется. Функция Live Volume на массивах серии SC хорошо подходит для облачных сред. Она обеспечивает восстановление после сбоев и прозрачное автоматическое переключение на полностью синхронизируемые тома на другом массиве серии SC. Интеграция корпоративных приложений На уровне приложений поддерживаются снепшоты в среде Oracle, облачных средах на платформе Microsoft Azure, VMware Metro Stretch Clusters. Функция Azure Site Recovery обеспечивает резервное копирование данных в облачную инфраструктуру Microsoft. Предусмотрена также интегрированная защита сред Oracle, Microsoft и VMware. Набор программ Application Protection Manager обеспечивает целостность данных на сервере в средах баз данных Oracle, VMware и MS. Опциональные твердотельные накопители и жесткие диски с самошифрованием, сертифицированные по стандарту FIPS, защищают данные от кражи, утери или несанкционированного доступа. А встроенные расширенные возможности включают всесторонние «тонкие» методы управления ресурсами системы. В заключение сравним массив с конкурентами: Массив SC9000 — это подходящее решение для крупных систем хранения данных, серьезных нагрузок и распределенных корпоративных сред. Массив SC9000 не просто увеличивает производительность: его интеллектуальная виртуализированная архитектура автоматически оптимизирует финансовые расходы и использование емкости хранения, обеспечивая максимальную экономию. Массивы хранения Dell SC9000 призваны помочь компаниям с крупными центрами хранения и обработки данных увереннее и быстрее достигать важных целей, расходуя меньше средств и времени. Dell предоставляет заказчикам гибкие комплексные решения, способные быстро адаптироваться под меняющиеся потребности, предлагает решение с рекордно низкой стоимостью хранения гигабайта данных на базе твердотельных накопителей благодаря новому типу памяти TLC 3D.

Метки:  
Нравится

[Из песочницы] Скелетная анимация в играх. Обзор техник и ресурсов
Воскресенье, 26 Июня 2016 г. 09:15 + в цитатник
Anima — это душа, отличающая живое от мертвого. Аристотелевская душа — это принцип движения, проявляющегося в четырёх видах: перемещение, превращение, убывание и возрастание. Спустя почти две с половиной тысячи лет мы используем те же категории в компьютерной графике. Скелетная анимация определяет перемещение, морфинг служит для превращений, а убывание и возрастание это обычное масштабирование. Анимированная графика оживляет образ, вдыхает в картинку душу, и это, на мой взгляд, даже важнее, чем достоверная игра света и тени. Создание качественных скелетных 3D анимаций сегодня, пожалуй, самая труднодоступная для инди разработчиков задача. Вероятно поэтому так мало инди игр в 3D, и так много проектов в стилях пиксель арта или примитивизма, а также бродилок без персонажей в кадре. Но теперь это соотношение может измениться… Попробуйте сосчитать количество разнообразных анимаций в Uncharted 4. По моим оценкам там около часа уникальных движений, не считая лицевой анимации (850 выражений по словам авторов). Подобные игры задают фантастическую планку качества. Примеры анимации Uncharted 4 (>40мб GIF) Если физический рендеринг и создание качественно освещенных статичных сцен становятся доступны энтузиастам благодаря мощным бесплатным игровым движкам и инструментам 3D моделирования, то создание хорошей анимации требует оборудования для захвата движений и длительной кропотливой работы по их внедрению. Одна из самых доступных систем это костюм neuronmocap стоимостью порядка $1.5к без учета доставки. Мне не удалось отыскать примеров создания хотя-бы близкой по уровню анимации при помощи ручного кадрового подхода или какой-либо процедурной анимации. Максимум что возможно сделать вручную, на мой взгляд, — это простые удары, быстрые движения и стилизованная мультяшная анимация. Но как сделать реалистичную ходьбу по лестнице, где очень много деталей, связанных с переносном центра тяжести и балансом тела? Невозможно их все воспроизвести вручную. Может быть я ошибаюсь, и кто-нибудь покажет работы специалистов такого уровня?.. Все это я вспоминаю для того, чтобы оценить по достоинству щедрый подарок от Mixamo. Он буквально открывает дверь на новый уровень для независимых разработчиков: компания Adobe купила Mixamo, и теперь 2.5 тысячи скелетных анимаций для персонажей они отдают совершенно бесплатно "for unlimited commercial or non commercial use": www.mixamo.com Еще пол года назад можно было их получить только выложив порядка $36 000 (ну или спиратив в сети). Помимо анимаций компания также предлагает бесплатную версию инструмента для ригинга и скининга персонажей, инструмент для создания множественных уровней детализации с минимальными потерями качества (LOD), генератор персонажей и плагин для захвата лицевой анимации. Существуют и не менее проработанные наборы анимаций, доступные для приобретения энтузиастами. Но такой гигантский и качественный набор впервые оказался доступен совершенно бесплатно. Еще одним неплохим источником клипов остается база анимаций Университета Карнеги — Меллон и ее адаптированная под Unity версия, однако качество и содержание этой базы не так хороши. Кроме ручной кадровой анимации и захвата движения актера, существуют и интересные процедурные методы симуляции движений: эволюционное моделирование, нейронные сети, task based locomotion. Что интересно, на конференции SIGGRAPH 2016 этим непростым техникам уделяют много внимания. Но широким кругам независимых разработчиков эти вещи пока не доступны, и мне самому хотелось бы больше узнать о возможности их реального применения. Однако сегодня есть и доступные инструменты, симулирующие мускульную динамику (Euphoria Engine и Puppet Master для Unity3d), которые позволяют привнести разнообразные реакции персонажей на обстоятельства. Получить качественные и разнообразные анимационные клипы это только первая часть задачи. Вторая часть заключается в том, чтобы корректно использовать полученные анимации при управлении персонажем. Для этого сначала нужно решить, как вообще сдвигать персонажа в сцене: на основании данных самой анимации (1), либо на основании каких-то иных соображений (например физики твердого тела) (2). То есть, либо анимация будет вычисляться исходя из произвольного (физического) движения объекта в пространстве (2), либо само смещение в пространстве будет исходить из записанной анимации, игнорируя иные вмешательства (1). У обоих подходов есть достоинства и недостатки. В прежние времена, до массового использования захвата движений, вопрос об этом почти не стоял — персонажи двигались процедурно, на основании каких-то простых принципов, а анимационные клипы просто проигрывались для некоторого соответствия этому движению. Но чем лучше становилась анимация и графика в целом, тем заметнее становилось несоответствие движения ног и смещения персонажа, а также неестветсвенность динамики движения. Одним из ярких примеров может быть игра Guild Wars 2 где анимация движений и графика уже достаточно хороши, но вот большой диапазон возможных скоростей и направлений движения персонажа не обеспечен столь же большим набором анимаций, и персонажи либо буксуют на месте, либо проскальзывают вперед как по льду. Та же проблема долгое время преследует и игры на движке Gamebryo (серия TES: Morrowind, Skyrim), да и многие другие. Настоящее движение человека нелинейно — сначала мы наклоняемся вперед, затем выбрасываем ногу, и только потом начинаем движение, быстро ускоряясь после соприкосновения стопы с землей, и двигаемся по инерции до следующего шага. Подобрать функцию, точно описывающую подобное движение, сложно, и редко кто вообще об этом задумывается. Что уж говорить о более сложных движениях — стрейфе, переходах между направлениями, торможением и поворотами. Поэтому для достижения реализма нам в любом случае потребуется гигантский набор разнообразных клипов с движениями в различных направлениях, с различной скоростью, и т.п… Кроме того, анимационные клипы редко можно использовать изолированно, воспроизводя один за другим. Чаще всего в игре присутствует множество анимаций, между которыми не заготовлено специальных анимированных переходов. Поэтому для их симуляции применяется плавное смешивание через линейную интерполяцию поворотов костей. Для удобной настройки таких переходов используется т.н. конечный автомат или машина состояний (State machine). В UE и Unity для этого есть специальные инструменты: Persona и Mecanim. Каждый узел там это некоторое состояние скелетной модели (заготовленный анимационный клип или результат их смешения — Blend Tree). Когда выполнены некоторые заданные условия, осуществляется плавный переход из одного состояния в другое, во время которого оба оказывают пропорциональное времени влияние на повороты костей и смещение объекта. Таким образом достигается иллюзия непрерывности движения. Состояние может быть не одиночным клипом, а смешанным по тому же принципу набором клипов (Blend Tree / Blend Space). Например из клипов движений персонажа в стороны можно выбрать несколько, смешав их пропорционально вектору желаемого движения, и получить движение под любым произвольным углом. Однако существуют такие анимации, для которых смешивание оборачивается некорректными позами. Например когда одна анимация двигает ноги персонажа вперед, а другая вбок, линейное смешивание может привести к пересечению ног друг с другом. Чтобы этого избежать нужно тщательно подбирать анимационные клипы, синхронизировать их фазу, длину и скорость, либо добавлять отдельный клип специально для данного вида движений. Все это сложная и кропотливая работа. И чем больше возможных состояний и переходов между ними, тем сложнее привести их в согласие друг с другом, и проследить за тем, чтобы все нужные переходы срабатывали когда это требуется. 1) Самым очевидным решением является захват движений реального актера при помощи Motion Capture и привязка смещения персонажа в игре к смещению «корневой кости» в самой анимации — принцип Root Motion. Тогда персонаж будет двигаться ровно так, как двигался актер во время записи. Выглядит очень реалистично. Более того, это единственный способ достоверно воспроизвести сложные маневры вроде выпадов, уворотов и паррирования атак холодным оружием. Но этот подход несет в себе и очевидные проблемы. Допустим, персонаж хочет подвинуться к краю обрыва: актер на записи наклоняется, поднимает ногу и делает смелый широкий шаг по сцене. А персонаж шагает прямо в пропасть… Чтобы этого избежать, нужно прервать шаг где-то посередине, но это не только выглядит неестественно, но и затрудняет игроку выбор нужного момента из-за нелинейности движения, в котором может быть долгая подготовка (наклон), а затем резкое уверенное движение (шаг). Можно записать несколько вариантов движений. Допустим: осторожные маленькие шаги, нормальные, и бег. А затем смешать их по параметру требуемой скорости, который можно увеличивать линейно и предсказуемо. Но что если нам нужны движения в стороны? Значит для каждого варианта ширины шага нам нужны еще три-четыре варианта (за вычетом зеркальных). А еще персонаж должен уметь поворачивать во время движения. Значит для каждого варианта нам нужны движения с поворотом. А если поворот может быть быстрым и медленным? Значит еще раз умножаем число необходимых клипов на два. А теперь нам нужно движение по наклонной поверхности! А потом нам захочется, чтобы персонаж умел делать тоже самое вприсяди. Итого — просто сотни и тысячи вариантов анимации которые нужно смешивать и следить за тем, чтобы это происходило корректно и приводило к движениям с нужной скоростью. И все равно, во многих случаях управление будет ощущаться как «ватное», поскольку инерция актера и наша невозможность предусмотреть все возможные человеческие маневры будет лишать игрока контроля над персонажем. Эту проблему, к слову, прочувствовали на себе игроки в The Witcher 3, поэтому в одном из крупных обновлений разработчики внедрили альтернативный вариант управления, где анимация быстрее отзывается на управление в ущерб реализму. В шутерах же проблема нелинейности движения обретает особенно выраженный характер: игроку часто приходится выглядывать из-за угла и быстро уходить обратно, и момент резкой смены направления может очень отличаться — игроку требуется как можно скорее вернуться обратно за укрытие, а у нас нет возможности предсказать заранее, какой ширины шаг он планировал и проиграть соответствующую анимацию. Игроку, в свою очередь, будет трудно привыкнуть к ширине шага, которую делает его персонаж, и к скорости этого шага, чтобы прервать его вовремя. Во-вторых, Root Motion плохо годится для сетевых игр. Нелинейность движения не только затрудняет игроку предсказание скорости, но и лишает нас возможности интерполировать и экстраполировать движение чтобы компенсировать сетевую задержку, что является очень важным и сложным аспектом в быстрых сетевых играх. Если смещение персонажа задается только анимацией, то трудно аналитически подобрать нужные параметры машины состояний (смешивающей разные анимации), которые приведут к движению персонажа в точно нужном нам направлении и с точно нужной нам скоростью (выбранных для компенсации расхождения). Если же сделать наоборот, так, что анимация будет ориентироваться на фактическое движение, то при коррекции расхождения между сервером и клиентом легко можно будет подобрать наиболее подходящую анимацию, и даже если она будет чуточку несоответствовать фактическому смещению, этого почти никто не заметит. Поэтому техника Root Motion используется часто в одиночных играх от третьего лица, где управление осуществляется контекстуально — в зависимости от наличия укрытия, препятствия, режима движения или других обстоятельств, и редко применяется в сетевом режиме и MMOG. Из последних заметных проектов, использующих Root Motion, можно выделить The Witcher 3. Трудно переоценить усилия, вложенные в производство всех его движений. Пример анимации The Witcher 3 и ее съемки 2) Другое решение обратно принципу Root Motion — нужно приводить анимацию в наиболее точное соответствие с произошедшим или планируемым движением. Тогда многие описанные выше проблемы решаются — движение персонажа можно сделать равноускоренным и предсказуемым с возможностью сколь угодно быстрой смены направления. Но как привести нелинейную и инерционную анимацию в соответствие с таким движением? Интересный комплексный подход описали разработчики игры Paragon. Суть его заключается в том, чтобы находить и проигрывать только нужную серию кадров анимации для достижения требуемого смещения/поворота, пропуская лишние. И использовать инверсную кинематику для модификации ширины шага. Первая очевидная трудность при приведении анимации в соответствие с движением, в том, что движение уже произошло, а анимация еще не проиграна. Поэтому очень пригодится система предсказания движения, вычисляющая положение персонажа для следующего кадра. Затем, зная смещение, которое должен осуществить персонаж за следующий кадр, нужно пропустить столько кадров анимационного клипа движения, сколько будет нужно чтобы достичь требуемого смещения, и проиграть тот кадр, на котором требуемое смещение достигнуто. В таком случае анимация станет воспроизводиться с измененной скоростью, так, чтобы точно соответствовать фактическому смещению, и эта скорость может быть быстрее или медленнее оригинальной, поскольку невозможно заставить реального актера поддерживать постоянное ускорение или скорость. Данный подход позволит сгладить анимацию и привести в соответствие с любой сложной процедурной моделью движения, меняющейся во время игры (персонаж может выпить какое-нибудь ускоряющее зелье или оказаться замедлен противником). Недостатком, разумеется, является то, что анимация может стать менее реалистичной из-за сильных изменений в скорости. Однако на практике это дает очень хорошее окно доступных вариаций в котором нарушения скорости незаметны. А вкупе с поправками ширины шага при помощи инверсной кинематики, покрывает еще больший диапазон. Но, к сожалению, этот метод довольно сильно нарушает привычный подход к анимированию, и поэтому я не смог найти простого способа реализовать его, например, с использованием стандартного анимационного компонента Unity. В Unreal Engine также пока нет необходимого функционала, однако разработчики обещают когда-нибудь перенести низкоуровневые наработки, сделанные для Paragon, в общедоступную версию движка. Основной сложностью является поиск и воспроизведение нужного кадра на основании данных о фактическом смещении и повороте. Для этого авторы предлагают делать пре-процессинг анимационных клипов и генерировать для каждого из них дополнительный блок данных: Distance Curve, в котором будут покадрово сохранены значения смещения и поворота корневой кости относительно начала или конца анимации. Затем, в ходе выборки, можно производить быстрый бинарный поиск нужного кадра, где достигнуты соответствующие параметры смещения и поворота, и воспроизводить его. Пока же можно ограничиться прежним подходом, и делать менее точную подгонку скорости анимации к скорости планируемого движения, ориентируясь только на скорость персонажа за последний кадр. Самое главное — неплохой набор душ для экспериментов теперь имеется!

Метки:  
Нравится

«Разрубить Гордиев узел» или преодоление проблем шифрования информации в ОС Windows
Суббота, 25 Июня 2016 г. 17:54 + в цитатник
Современная операционная система это сложный иерархичный процесс обработки и управления информацией. Актуальные версии ОС Windows в этом вопросе не являются исключением. Для того, чтобы интегрировать средство защиты в среду ОС Windows, зачастую хватает встраивания на прикладном уровне. Однако, если речь заходит о шифровании информации в среде ОС Windows, все становится намного сложнее. Основной «головной болью» разработчика средств шифрования в этом процессе является обеспечение «прозрачности шифрования», т.е. необходимо гармонично встроиться в структуру процессов операционной системы и при этом обеспечить невовлечение пользователей в процесс шифрования и уж тем более его обслуживание. Требования к современным средствам защиты все больше и больше исключают пользователя из процесса защиты информации. Таким образом, для этого самого пользователя создаются комфортные условия, не требующие принятия «непонятных» решений по защите информации. В данной статье будут раскрыты идеи эффективной интеграции средства шифрования информации на диске с процессами файловой системы ОС Windows. Перед разработчиками ставилась цель создать механизм шифрования информации на диске, отвечающий требованиям максимальной прозрачности для пользователей. Требования должны будут выполняться за счет эффективного взаимодействия этого механизма шифрования с процессами операционной системы Windows, которые отвечают за управление файловой системой. Эффективность механизма шифрования должна также подтверждаться высокой производительностью процессов шифрования и рациональным использованием ресурсов операционной системы. Изначально была поставлена задача предоставлять одновременный доступ к зашифрованному и расшифрованному содержимому, а также шифровать имена файлов. Это и порождает основные сложности, т.к. такое требование идет в разрез со сложившейся архитектурой Windows. Чтобы понять суть проблемы, для начала нам следует разобрать некоторые основные моменты данной операционной системы. В Windows все файловые системы полагаются на такие подсистемы, как менеджер памяти и кэш менеджер, а менеджер памяти, в свою очередь, полагается на файловые системы. Казалось бы, замкнутый круг, но все станет ясно дальше. Ниже, на рисунке 1, изображены перечисленные компоненты, а также менеджер ввода/вывода, который принимает запросы от подсистем (например Win32) и от других драйверов системы. Также на рисунке используются термины «фильтр» и «стек файловой системы», о чем подробнее будет рассказано ниже. Рисунок 1 Разберем такой механизм, как отображение файла на память. Суть его заключается в том, что при доступе к виртуальной памяти в реальности читается часть файла. Реализуется это при помощи аппаратных механизмов процессоров и непосредственно самого менеджера памяти. Любые диапазоны виртуальной памяти процесса описываются дескрипторами. Если для какого-то диапазона нет дескриптора, значит, на этом участке виртуальной памяти ничего нет, и доступ к такому диапазону неизбежно ведет к краху процесса. В случае, если для какого-либо диапазона закреплена физическая память, доступ к этим виртуальным адресам ведет к обычному доступу к физической памяти, такую память еще называют анонимной. В случае, если файл отображен на виртуальную память, то при доступе по этим адресам считывается часть файла с диска в физическую память, после чего доступ к ней будет выполняться обычным образом. Т.е. эти два случая очень похожи, разница лишь в том, что для последнего в соответствующую физическую память предварительно будет считана часть файла. Обо всех таких типах доступов дескриптор и содержит информацию. Эти дескрипторы являются структурами менеджера памяти, которыми он управляет для того, чтобы выполнять требуемые задачи. Как не трудно догадаться, для того, чтобы считать часть файла в страницу физической памяти, менеджер памяти должен послать запрос файловой системе. На рисунке 2 изображен пример виртуальной памяти процесса с двумя диапазонами, А и В, доступ к которым еще ни разу не выполнялся. Рисунок 2 На диапазон А отображен исполняемый файл самого процесса, а на диапазон В отображена физическая память. Теперь, когда процесс выполнит первый доступ к диапазону А, управление получит менеджер памяти и первое, что он сделает — оценит тип диапазона. Поскольку на диапазон А отображен файл, менеджер памяти сначала считает из файла соответствующую его часть в физическую память, после чего отобразит ее на диапазон А процесса, таким образом дальнейший доступ к считанному содержимому будет выполняться уже без менеджера памяти. Для диапазона В менеджер памяти выполнит такую же последовательность, единственная разница в том, что вместо считываний данных из файла он просто отобразит свободные физические страницы памяти на диапазон В, после чего доступ к этому диапазону будет выполняться уже без участия менеджера памяти. На рисунке 3 изображен пример виртуальной памяти процесса после первого доступа к диапазонам А и В. Рисунок 3 Как видно из рисунка, при доступе к обоим диапазонам доступ к физической памяти выполняется без участия менеджера памяти, т.к. ранее при первом доступе он отобразил на диапазоны А и В физическую память, а в физическую память диапазона А предварительно считал часть соответствующего файла. Кэш менеджер является центральным механизмом для всех открытых файлов в системе на всех дисках. Использование этого механизма позволяет не только ускорять доступ к файлам, но и экономить физическую память. Кэш менеджер не работает сам по себе, в отличие от менеджера памяти. Он полностью управляется файловыми системами, и вся необходимая информация о файлах (например, размер) предоставляется ими. Всякий раз, когда к файловой системе приходит запрос на чтение/запись, файловая система не читает файл с диска, вместо этого она вызывает сервисы кэш менеджера. Кэш менеджер, в свою очередь, пользуясь сервисами менеджера памяти, отображает файл на виртуальную память и копирует его из памяти в буфер запросчика. Соответственно, при доступе к этой памяти менеджер памяти пошлет запрос файловой системе. И это будет особый запрос, который будет говорить, что файл надо считать непосредственно с диска. Если выполняется доступ к файлу, который ранее уже был отображен кэш менеджером, то повторно отображен на виртуальную память он не будет. Вместо этого кэш менеджер будет использовать виртуальную память, куда файл был отображен ранее. Отображение файла отслеживается посредством структур, которые файловые системы передают кэш менеджеру при вызове его сервисов. Об этих структурах немного подробнее будет рассказано ниже. На рисунке 4 приведен пример чтения файла процессом. Рисунок 4 Как показано на рисунке выше, процесс выполняет чтение файла в буфер В. Чтобы выполнить чтение, процесс обращается к менеджеру ввода/вывода, который формирует и посылает запрос файловой системе. Файловая система, получив запрос, не считывает файл с диска, а вызывает кэш менеджер. Далее кэш менеджер оценивает, отображен ли файл на его виртуальную память, и если нет, то он вызывает менеджер памяти для того чтобы отобразить файл/часть файла. В данном примере файл уже отображен, а доступ к нему ни разу не выполнялся. Далее кэш менеджер копирует в буфер В процесса файл, отображенный на диапазон виртуальной памяти А. Поскольку доступ к диапазону А выполняется первый раз, управление получит менеджер памяти, затем он оценит диапазон, и, поскольку это отображенный на память файл, считает его часть в физическую память, после чего отобразит ее на диапазон виртуальной памяти А. После этого, как уже было описано ранее, доступ к диапазону А будет выполняться, минуя менеджер памяти. Ничто не мешает одновременно кэшировать файл и отображать его на память сколько угодно раз. Даже если файл будет закэширован и отображен на память десятков процессов, физическая память, которая используется для этого файла, будет одна и та же. В этом и заключается суть экономии физической памяти. На рисунке 5 приведен пример, где один процесс читает файл обычным образом, а другой процесс отображает этот же файл на свою виртуальную память. Рисунок 5 Как видно из рисунка выше, физическая память отображается на виртуальную память процесса В и виртуальную память кэш менеджера. Когда процесс А будет выполнять чтение файла в буфер D, он обратится к менеджеру ввода/вывода, который сформирует и пошлет запрос файловой системе. Файловая система, в свою очередь, обратится к кэш менеджеру, который просто скопирует файл, отображенный на диапазон виртуальной памяти С кэш менеджера, в буфер D процесса А. Поскольку в момент обращения к кэш менеджеру файл уже был не только отображен, но и ранее выполнялся доступ к диапазону С, на которую отображен файл, то операция будет выполнена без участия менеджера памяти. Процесс В при чтении/записи диапазона Е по сути получит доступ к тем же самым физическим страницам памяти, к котором при копировании файла получал доступ кэш менеджер. Файловые системы принимают запросы от пользовательского ПО или других драйверов. Перед доступом файл должен быть открыт. В случае успешного выполнения запросов открытия/создания файлов файловая система сформирует структуры памяти, которые используются кэш менеджером и менеджером памяти. Также следует отметить, что эти структуры уникальны для файла. Т.е. если конкретный файл диска был открыт на тот момент, когда пришел такой же запрос на этот же файл, файловая система будет использовать ранее сформированные структуры памяти. По сути, они являются программным представлением файла диска в памяти. На рисунке 6 приведен пример соответствия открытых экземпляров файлов и их структур. Рисунок 6 На рисунке процесс А открыл файл С и файл D, а процесс B открыл файл С два раза. Таким образом, имеется три открытых экземпляра файла С, когда структура, сформированная файловой системой, всего одна. Файл D был открыт один раз, следовательно, имеется один открытый экземпляр, которому соответствует структура, сформированная файловой системой. Любые запросы, направленные к файловой системе, не сразу обрабатываются ею. Запросы сначала проходят по цепочке драйверов, которые желают отслеживать такие запросы. Такие драйвера называют фильтрами. Они имеют возможность просматривать запросы до того, как они достигнут файловой системы, а также после того, как файловая система обработает их. Например, фильтр шифрования файлов может отслеживать запросы чтения/записи для того, чтобы расшифровать/зашифровать данные. Таким образом, не дорабатывая сами файловые системы, мы можем зашифровать данные файла. Фильтры могут привязывать свои уникальные данные к структурам файлов, которые формирует файловая система. Вместе драйвера фильтров и драйвер файловой системы формируют стек файловой системы. Количество фильтров может быть разным, также могут быть разными и сами фильтры. Теоретически их может и не быть совсем, но практически так не бывает. На рисунке 7 изображен стек файловой системы, в состав которого входят три фильтра. Рисунок 7 До того, как запрос достигнет файловой системы, он проходит последовательно через фильтры 1, 2 и 3. Когда запрос будет обработан файловой системой, то фильтрами он виден в обратном порядке, т.е. запрос проходит последовательно через фильтры 3, 2 и 1. Также, на примере выше фильтр 1 и фильтр 3 привязали свои структуры к структуре файла, которую сформировала файловая система после выполнения запроса открывания/создания файла. Подавляющее большинство задач решается посредством фильтрации, но наш случай уникален. Как было ранее отмечено, уникален он тем, что нужно предоставлять одновременный доступ к зашифрованному и расшифрованному содержимому, а также шифровать имена файлов. Тем не менее, мы попытаемся разработать фильтр, который позволит решить такую задачу. На рисунке 8 изображена ситуация, когда файл ранее был открыт расшифрованным. Рисунок 8 Это значит, что фильтры видели расшифрованное имя, и они, как это изображено на рисунке, могут привязать это имя к структуре, которую сформирует файловая система (как было ранее сказано, эта структура уникальна для конкретного файла диска) для дальнейших манипуляций с файлом. И в этот момент файл открывается зашифрованным, что означает, что фильтры видели зашифрованное имя. Как они поведут себя в такой ситуации, когда к структуре файла уже привязано расшифрованное имя? Очевидно, что поведение не предсказуемо, хотя и не обязательно, что последствия будут фатальными. В продолжение описанного выше можно добавить, что при доступе к содержимому файла также возникают проблемы, и гораздо более серьезные. Вернемся к ситуации, когда файл был открыт одновременно расшифрованным и зашифрованным. Эта ситуация изображена на рисунке 9, чтение/запись файла еще ни разу не выполнялись. Рисунок 9 Теперь представим себе, что пришел запрос на чтение расшифрованного содержимого. Файловая система воспользуется услугами кэш менеджера и передаст ему структуру файла, к которой и кэш менеджер, и менеджер памяти привяжут свои уникальные данные для дальнейшего управления отображением и кэшированием файла. Эта ситуация изображена на рисунке 10. Рисунок 10 Далее приходит запрос на чтение зашифрованного содержимого, и файловая система снова передает структуру файла кэш менеджеру, а поскольку кэш менеджер и менеджер памяти ранее к этой структуре привязали уникальные данные для этого файла, они просто воспользуются ими для выполнения запроса. Т.е. теперь в этих структурах будет указано, куда был отображен файл, и кэш менеджер просто скопирует данные файла из виртуальной памяти в буфер запросчика. Мы помним, что файл при первом доступе к нему был закэширован расшифрованным, таким образом при зашифрованном доступе в буфере запросчика окажутся расшифрованные данные. Мы только что разобрали две фундаментальные проблемы. На практике их было больше. Например, в рамках поставленной задачи к каждому зашифрованному файлу необходимо добавлять заголовочную информацию, что тоже не решается посредством фильтрации. Чтобы обойти все эти проблемы разом, было найдено решение — виртуальная файловая система. Виртуальная файловая система, по своей сути, мало чем отличается от обычной. Радикальное отличие состоит в том, что обычная файловая система работает с диском, а виртуальная работает с файлами других файловых систем, т.е. является обычным потребителем сервисов файловых систем. На рисунке 11 изображена концепция виртуальной файловой системы. Рисунок 11 В отличие от обычных файловых систем, виртуальная файловая система не регистрирует себя в системе (об этом не было сказано выше, но для того чтобы операционная система могла пользоваться сервисами конкретной файловой системы, она должна зарегистрироваться), а раз так, то запросы к ней направляться не будут. Чтобы решить эту проблему, мы используем фильтр для обычной файловой системы, но на этот раз его функции будут очень простыми и ограниченными, одна из них (и главная) — это отслеживание доступа к зашифрованным файлам. Как только фильтр увидит такой запрос, он просто перенаправит его к виртуальной файловой системе. Если же будет выполняться доступ к обычному файлу, запрос будет передан оригинальной файловой системе. Теперь давайте еще раз разберем расшифрованный и зашифрованный доступы, но уже в контексте виртуальной файловой системы. На рисунке 12 приведен пример, когда выполнялся доступ к расшифрованному и зашифрованному содержимому конкретного файла. Рисунок 12 Еще раз представим ситуацию, когда файл был открыт расшифрованным. Это значит, что в процессе выполнения запроса открывания файла, наш фильтр увидел его и перенаправил на виртуальную файловую систему. Виртуальная файловая система, получив запрос, оценивает тип доступа (расшифрованный или зашифрованный), и поскольку выполняется расшифрованный доступ, виртуальная файловая система сначала преобразует расшифрованное имя в зашифрованное, а после попытается открыть файл через родную файловую систему по этому имени (т.е. имя файла на родной файловой системе будет зашифрованным). В случае успеха виртуальная файловая система сформирует структуры памяти, которые позже будут использовать кэш менеджер и менеджер памяти. Теперь представим себе, что файл открывается зашифрованным, фильтр снова перенаправляет запрос виртуальной файловой системе, не делая никаких оценок. Виртуальная файловая система оценивает тип доступа, а поскольку доступ зашифрованный, она просто попытается открыть файл через родную файловую систему по этому имени. И опять, в случае успеха, виртуальная файловая система сформирует структуры памяти для кэш менеджера и менеджера памяти. Но в отличие от расшифрованного доступа, это будут уже другие структуры. Теперь, если файл снова будет открыт расшифрованным, виртуальная файловая система использует те же структуры, которые сформировала при первом расшифрованном доступе. В случае если файл снова будет открываться зашифрованным, файловая система использует структуры, которые сформировала при первом зашифрованном доступе. Таким образом, мы разделили доступ к расшифрованному и зашифрованному содержимому. На рисунке 13 изображена ситуация, когда доступ на чтение/запись к расшифрованному и зашифрованному содержимому файла ни разу не выполнялся. Рисунок 13 Теперь если будет выполняться расшифрованное чтение, виртуальная файловая система, пользуясь сервисами кэш менеджера, как показано на рисунке 14, передаст ему структуры памяти, которые она вернула при открывании файла расшифрованным. Рисунок 14 Кэш менеджер отобразит файл на виртуальную память и скопирует данные в буфер запросчика. Соответственно, в процессе копирования менеджер памяти пошлет запрос на чтение виртуальной файловой системе, которая в свою очередь пошлет запрос на чтение родной файловой системе, а поскольку кэш менеджеру были переданы структуры памяти для расшифрованного файла, виртуальная файловая система расшифрует данные и сообщит о завершении менеджеру памяти, так закэшируется расшифрованное содержимое. В случае если будет выполняться зашифрованное чтение, виртуальная файловая система передаст, как изображено на рисунке 15, кэш менеджеру структуры памяти, которые она сформировала при открывании файла зашифрованным. Рисунок 15 Кэш менеджер снова отобразит файл на виртуальную память (поскольку в этих структурах файл еще не отображался) и скопирует данные в буфер запросчика. И опять в процессе копирования менеджер памяти пошлет запрос на чтение виртуальной файловой системе, которая снова пошлет запрос на чтение родной файловой системе, а поскольку кэш менеджеру были переданы структуры памяти для зашифрованного файла, то, не расшифровывая данных, виртуальная файловая система сообщит менеджеру памяти о завершении. Так файл закэшируется зашифрованным. Как мы видим, виртуальная файловая система решает фундаментальные проблемы, не позволяющие иметь одновременный доступ к расшифрованному и зашифрованному содержимому файла, из-за чего приходится отказываться от классических механизмов операционной системы. В процессе фильтрации мы можем только добавлять данные к структурам памяти файлов, которые возвращает файловая система, и, поскольку мы не формируем эти структуры, мы не можем вмешиваться в них и управлять ими. А посредством виртуальной файловой системы мы их полностью формируем, и, следовательно, имеем полный контроль над ними, что необходимо в рамках решения данной задачи. Например, нам нужно обеспечивать согласованность расшифрованного и зашифрованного содержимых файлов. Представьте себе ситуацию, когда были записаны данные в расшифрованный файл и данные находятся еще в кэше, а не на диске. И в этот момент приходит запрос на чтение зашифрованного содержимого файла. В ответ на это виртуальная файловая система выгрузит расшифрованное содержимое на диск и сбросит зашифрованный кэш, что заставит кэш менеджер заново послать запрос на чтение виртуальной файловой системе для зашифрованного чтения. В рамках фильтрации подобная задача не решается в принципе. При разработке виртуальной файловой системы приходилось сталкиваться с необычными проблемами. Отчасти это вызвано тем, что мы работаем с файлами файловых систем, когда обычные файловые системы работают с диском. Так, например, была найдена ошибка в файловой системе NTFS. Проявлялась она в том, что доступ к файлу X:\$mft\<любое имя> приводил к повисанию всего доступа к диску X. В результате исследования было установлено, что NTFS не освобождала механизмы синхронизации для файла $mft, который является перечислителем всех файлов диска. И соответственно, чтобы найти какой-либо файл на диске, сначала нужно прочитать $mft файл, доступ к которому повис. Другой пример, который нельзя назвать необычным, это найденная ошибка в ядре Windows 8, в результате которой менеджер памяти полагает, что структуры памяти файла всегда последней версии. Из-за этого он пытается использовать некоторые части этой структуры, которых в действительности может не быть. И это приводило к BSOD. Реализация виртуальной файловой системы значительно сложнее реализации фильтра, но наличие такого механизма дает большую гибкость при манипуляциях с файлами. В том числе такую, о которой мы только что говорили. Хотя, на первый взгляд, может показаться, что задача тривиальна. В результате применения данного подхода к шифрованию были успешно реализованы функции предоставления одновременного доступа программных процессов к зашифрованному и расшифрованному содержимому, а также реализовано шифрование имен файлов, что позволяет обеспечить высокую степень прозрачности при реализации криптографической защиты информации. Надо отметить, что данный подход по обеспечению «прозрачности» шифрования файлов в ОС Windows успешно реализован в корпоративном продукте Secret Disk Enterprise («Аладдин Р.Д.»), который применяется многими организациями в России. Это в свою очередь доказывает жизнеспособность и перспективность применения данной идеи в процессе создания программ шифрования файлов на диске. В качестве заключения стоит отметить, что технологическая сложность файловой системы ОС Windows и отсутствие стандартных механизмов решения задач, подобных описываемой в данной статье, будут всегда являться препятствием создания удобных и простых программ, обеспечивающих защиту информации. В таком случае единственным верным решением является самостоятельная реализация оригинального механизма, позволяющего обойти данные ограничения без потери функциональности ПО.

Метки:  
Нравится

[Из песочницы] Загрузчик для dsPIC33
Суббота, 25 Июня 2016 г. 14:46 + в цитатник
Загрузчик (bootloader) — очень удобный инструмент работы с микроконтроллерами (далее — МК). Это маленькая программа, которая позволяет МК «самопрограммироваться» (self-programming). Обычно, при подаче питания на МК, управление сначала получает загрузчик, которые проверят заранее заданные условия (определенное состояние на ножке МК, флаг в EEPROM, подходящий файл прошивки на SD-карте и т.д.). Если условия не выполняются, то управление передается основной программе. Если же условия выполняются, то загрузчик переключается в режим программирования, получая данные новой прошивки по предопределенному интерфейсу. Это позволяет обновить прошивку МК не прибегая к паяльнику, программатору или внутрисхемному программированию. Обычный алгоритм использования загрузчика для МК, только что вынутого из упаковки: с помощью программатора/отладчика прошивается загрузчик МК монтируется в плату используя загрузчик по заранее определенному интерфейсу загружается основная прошивка Это вполне приемлемо для опытных образцов изделий или для мелкосерийного производства. А что делать, если производство крупносерийное? Или сборка проводится автоматами (а может людьми с функционалом автоматов) — прошил, впаял? Тогда разумно убрать из алгоритма 3го пункт — объединить в одной прошивке и основную программу и загрузчик. В своей практике я столкнулся с довольно жутким методом получения такой прошивки — в HEX-файл основной прошивки просто дописывался HEX-файл с кодом загрузчика. Конечно. такой подход имеет право быть — как ни крути, но итоговые «прошивки имени др. Франкенштейна» работали как надо. Но чувство, что для решения этой задачи должны быть более корректные методы, меня не оставляло. Когда Я поискал решения в Интернете, то был неприятно удивлен, что простого и понятного описания решения нет. Собственно, именно это побудило меня написать публикацию, описывающую мое решение этой ситуации. Возможно мое видение решения этой проблемы отличается от максимально правильного, но оно гораздо более логичней, чем сшивание HEX-файлов. Прежде чем перейти к самой теме публикации, хочу привести список упрощений и инструментов, которые были использованы: MPLAB IDE v8.85 (да, весьма устаревшая IDE) Microchip C30 Toolsuite v3.12 объектные файлы в формате COFF (т.е. по умолчанию для этого toolchain-a) расположение загрузчика и основной программы статичны загрузчик располагается с адреса 0х0400 основная программа располагается с адреса 0х2000 память по адресам с 0х0200 по 0х0400 — неиспользуемая И самое главное — конкретных исходников загрузчика в это публикации не будет. Компоновка загрузчика в основной проект Просто скомпилировать… Начнем с самого простого случая. Добрый Дедушка Мороз прислал Вам на Новый Год готовый загрузчик. Причем он уже потрудился на славу и скомпилировал и скомпоновал его для Вас. Итак, у Вас в руках (на флешке/в сети/на жестком диске) есть файлик – UltraBoot3000.blob. Дальше алгоритм очень простой – просто добавь его к себе в проект. Касаемо MPLAB IDE его надо добавить в категорию «Object Files». К сожалению, по умолчанию в эту категорию можно добавить только файлы с расширением «o». Отмечу так же, что файлы с расширением «o» получаются так же в процессе компиляции Вашей программы. Чтобы нечаянно не перепутать и не забыть о файле загрузчика, рекомендую держать его с другим расширением, например blob – binary linked object. Чтобы IDE положило файл blob в категорию «Object Files», этой категории нужно скорректировать настройки фильтров. Жмем правой кнопкой мыши на этой категории и выбираем пункт «Filter…». В появившемся окне в поле через точку-с-запятой дописываем необходимый нам шаблон фильтра. В нашем случае в поле должно быть в итоге следующее описание фильтров: *.o;*.blob После настройки фильтров можно добавить файл загрузчика в проект. Запускаем процесс компи… НЕТ! СТОП! Чтобы корректно собрать прошивку с нашим загрузчиком, нужен правильный скрипт компоновщика. Конечно, если Дедушка Мороз был настолько добр, что и этот скрипт Вам прислал, то просто добавляем его себе в проект (MPLAB IDE поддерживает файлы с расширением «gld»), запускаем процесс сборки проекта и на выходе получаем корректный файл прошивки с уже встроенным кодом загрузчика. Но что делать, если Дедушка забыл про это скрипт или может быть именно Вы и являетесь тем, кто сделал этот загрузчик и Вам надо встроить его в свой/чужой проект? Читаем дальше… Подготовка скрипта компоновщика Собственно не стоит писать скрипт с нуля. Достаточно чуть-чуть переделать скрипт, который устанавливается в комплекте с компилятором. Лежит этот скрипт в папке «${ToolChainPath}\support\dsPIC33F\gld\». Примечание: здесь и далее ${ToolChainPath} – это путь, куда был установлен компилятор С30, по умолчанию это – «c:\Program Files\Microchip\MPLAB C30\». Скопируем оттуда скрипт по умолчанию для нашего устройства, например для МК dsPIC33FJ128GP802 это будет файл «p33FJ128GP802.gld». Первым делом надо вписать два символа, описывающих начало области загрузчика и основной программы. Например, так: _Booter = 0x000400; _mainFW = 0x002000; Далее в структуре MEMORY {…} в поле program указать начальную позицию (origin) и длину (length), соответствующие началу загрузчика и размеру flash-памяти минус начало загрузчика. Примерно так: program (xr) : ORIGIN = 0x400,LENGTH = (0x15800 - 0x400) Следующим шагом будет корректировка вектора сброса. В структуре SECTIONS {…} найдем описание «Reset Instruction». Необходимо чтобы она выглядела следующим образом: .reset : { SHORT(ABSOLUTE(_Booter)); SHORT(0x04); SHORT((ABSOLUTE(_Booter) >> 16) & 0x7F); SHORT(0); } >reset Осталось только добавить описание зоны загрузчика. Зона описывается в структуре SECTIONS {…}. Это описание необходимо вставить перед описанием зоны «.text». Описание следующее: .boot _Booter : { *(.booter); . = _mainFW - _Booter; } >program = 0xFFFF Итак, скрипт готов. Создание загрузчика Сделать загрузчик из программы Первое, что хотелось бы отметить: загрузчик не должен быть самостоятельной программой. Конечно, в процессе отладки загрузчика его можно реализовать как самостоятельную программу. Но как только Вы планируете его встроить в другую программу его необходимо специально подготовить. Итак, чего лишается программа, превращаясь в загрузчик: Описание конфигурационных бит Векторов прерываний Вектора сброса Кроме этого, невозможно корректно встроить константы загрузчика, хранимые во flash-памяти, в код основной программы. Поэтому от них тоже придется отказаться. Примечание: на самом деле способ есть, но он настолько нетривиален, что для массового использования проще отказать от констант в загрузчике. Доработка исходных текстов Доработка несложная. Убираем все макросы, описывающие конфигурационные биты. Исключаем использование глобальных констант. Настройка проекта Так же необходимо проверить и, при необходимости, скорректировать настройки проекта. Все изменения – во вкладке «MPLAB LINK30», категория «General». Установить чек-боксы: don’t pack data template; don’t create hanldes; don’t create default ISR; remove unused sections. Доработка скрипта компоновщика Так же как и для основной программы с загрузчиком скрипт будет отличным от скрипта по умолчанию. Итак, берем скрипт по умолчанию и вносим следующие изменения. Структуру MEMORY {…} уменьшаем до двух позиций: data и program. Причем начало и длина program соответствуют началу и длине области загрузчика: { data (a!xr) : ORIGIN = 0x800, LENGTH = 0x4000 program (xr) : ORIGIN = 0x400, LENGTH = 0x1C00 } Удаляем полностью описание «Reset Instruction» в структуре SECTIONS {…}. В этой же структуре удаляем описание «Configuration Words». Полностью удаляем структуру SECTIONS {…}, которая описывает вектора прерываний (метка «Section Map for Interrupt Vector Tables»). В структуре SECTIONS {…} дорабатываем описание зоны «.text», заменив название зоны на «.booter» и приведя ее к следующему виду: .booter 0x400 : { *(.init); *(.user_init); *(.handle); *(.libc) *(.libm) *(.libdsp); /* keep together in this order */ *(.lib*); *(.dinit); *(.text); } >program Естественно, полученный скрипт надо добавить в проект. Постобработка выходного файла После осуществления предыдущих действий можно запустить процесс компиляции. В выводе процесса сборки (для MPLAB IDE это будет в окне Output, вкладка Build) можно увидеть результат компоновки. Например, так: Program Memory [Origin = 0x400, Length = 0x1c00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .booter 0x400 0x7d0 0xbb8 (3000) Total program memory used (bytes): 0xbb8 (3000) 27% Data Memory [Origin = 0x800, Length = 0x4000] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0xa2c (2604) bootdata 0x47c0 0 0x40 (64) Total data memory used (bytes): 0xa6c (2668) 16% Если в program memory больше одной секции – то скорей всего вы не до конца выполнили действия описанные выше. Если там именно одна секция с названием «.booter» — то все сделано правильно. Также надо обратить внимание на количество секций в data memory. Теперь надо выполнить постобработку выходного файла. Постобработка проводиться с файлом с расширением «cof». Открываем командную строку в папке с этим файлом. Допустим файл имеет имя ultraboot.cof, тогда выполним команду: "${ToolChainPath}\bin\pic30-strip.exe" -s > Не забываем ${ToolChainPath} заменять на реальный путь. Количество опций > Далее надо провести финальную проверку полученного бинарного файла с загрузчиком. Команда: "${ToolChainPath}\bin\pic30-objdump.exe" -ht ultraboot.blob Вывод будет примерно следующим: ultraboot.blob: file format coff-pic30 Sections: Idx Name Size VMA LMA File off Algn 0 .booter 000007d0 00000400 00000400 00000058 2**1 CONTENTS, ALLOC, LOAD, CODE SYMBOL TABLE: no symbols Если вы увидите, что секций ровно одна — с названием «.booter» и в символьной таблице нет символов, то можно считать, что все сделано корректно. И в конце ссылки на примеры файлов для линкера: для основного проекта с загрузчиком — drive.google.com/file/d/0B063O4zepkwsNDlCMkJ1S1ZxaE0/view?usp=sharing для загрузчика — drive.google.com/file/d/0B063O4zepkwsZU9Nck42cVoyWDA/view?usp=sharing

Нравится

Vidom — blazingly fast alternative to React
Пятница, 24 Июня 2016 г. 19:59 + в цитатник
Давненько я ничего тут не писал, а сегодня как раз пятница, так что можно набросить на React рассказать о своей поделке Vidom. Краткая история Когда только React входил в стадию хайпа (начало 2014 года), идея virtual dom, а также всего с ним связанного (диффы, патчи), показалась мне крайне интересной и я решил осознать ее и прочувствовать через свою собственную реализацию. Я посмотрел существовавшие на тот момент имплементации, сделал несколько подходов, переписывая все несколько раз с нуля, чтобы добиться максимально производительности. Потом, постепенно, появились компоненты, хуки, контексты, серверный рендеринг, es2015 и т.д. Затем я посмотрел что людям в React доставляет боль при использовании, и одними из самых популярных проблем было: производительность серверного рендеринга и отсутствие поддержки фрагментов (этому таску в трекере реакта уже почти два года!). Засучив рукава, я добавил поддержку фрагментов. А производительность ssr в Vidom изначально была в него заложена, результат бенчмарка можно увидеть ниже. В результате получилось: Чем Vidom похож на React виртуальный DOM под капотом jsx возможность создавать свои высокоуровневые компоненты, как на основе классов, так и на основе функций lifecycle-хуки в компонентах на основе классов легкая подписка на DOM-события context api изоморфизм, ssr, возможность реиспользовать разметку, пришедшую с сервера плагин для chrome developer tools Чем Vidom отличается от React скорость, скорость и еще раз скорость целевая платформа только браузеры поддержка фрагментов, что, позволяет, например, из одного компонента возвращать несколько других (без ненужных, и, порой, мешающих DOM-оберток) или манипулировать несколькими нодами, в том числе и DOM, как одной. нет необходимости расставлять key в простых случаях при использовании массивов размер библиотеки (примерно 10Кб после gzip) отсутствуют propTypes отсутствуют, и это главный минус, тысячи сопутствующих библиотек, таких как, react-router, react-redux и т.п. :) Бенчмарки Repaint rate challenge Server-side рендеринг (node v4.4.3, > Проект на github: vidom Готов ответить на ваши вопросы, а также увидеть issue и pull request на github ;)

Нравится

Как мы разрабатываем новый фронтенд Tinkoff.ru
Четверг, 23 Июня 2016 г. 19:37 + в цитатник
В апреле этого года мы перезапустили tinkoff.ru. Банк превратился в финансовый супермакет. Теперь не только клиент банка, но и любой посетитель оплатит мобильный, проверит налоги и оформит ипотеку — всё на одной платформе. В этой статье я поделюсь опытом и технологическими решениями, к которым мы пришли за год разработки. Наш стэк для фронтенда хорошо себя показал. Теперь мы решаем проблемы и адаптируемся к новым требованиям в рамках концепции архитектуры. За год мы разработали 350 независимых интерфейсных блоков из 3000 React-компонентов. Оптимизировали загрузку страниц, потому что tinkoff.ru посещают 7 млн пользователей в месяц и число посетителей постоянно растет. Фронтенд разрабатывает 30 человек и мы постоянно ищем талантливых разработчиков. Мы объединили функции предыдущих интернет-банков, портала и кошелька. Поэтому я сначала опишу исходные стэки, а потом расскажу, как мы пришли к текущему стэку. Обзор предыдущих стэков Портал и интернет-банк 2011 Первую версию мы разрабатывали внутренними ресурсами на основе коммерческого решения от голландской компании. Бекенд крутился на базе тяжелого Java/Spring приложения. На фронте из-за недостатка гибкости и подробной документации сформировался стэк из jQuery, Backbone, Handlebars. Maven собирал фронт с бэком. Было катастрофически мало плагинов для фронта, так как Maven не подходил для сборки клиентских пакетов. Это привело нас в тупик. Благо нашли как отделить клиентскую сборку от серверной с помощью Grunt. Использовать шаблоны на сервере и несвязанные шаблоны на клиенте со своей логикой и архитектурой считалось нормой. Приходилось поддерживать два UI-слоя: серверный UI и клиентский UI. Когда мы имеем крупное RIA – дублируется много логики, которая написана на разных языках программирования. Например: маршрутизация по страницам, логика получения данных или шаблоны с одинаковой разметкой. В конце 2013 года стал развиваться изоморфный подход к созданию веб-приложений. И решение с дублированием шаблонов на сервере и на клиенте стало считаться концептуально неверным. Кошелек 2014 Этот проект интересен по двум причинам: «Тинькофф Мобильный Кошелек» — первое приложение, которое использовали все, не только клиенты банка. Мы попробовали изоморфный подход на базе архитектуры MVC. Отправная точка — статья от Airbnb. Стэк был схож с интернет-банком: Backbone и Handlebars, сервер на Node.js. Часть вью рендерилось на сервере. Приложение решало свои задачи и даже получился один UI-слой. Но стало ясно, что на большом приложении подобная архитектура принесет сложности. Появились проблемы с обогащением моделей данных в браузере. Приходилось писать отдельные контроллеры для серверной и клиентской стороны. Следующий проект разработали по другой парадигме. Интернет-банк 2015 Интернет-банк был отделен от внешнего сайта и представлял из себя Single Page Application. Для интернет-банка использовали фреймворк Angular.js. В итоге мы получили современный интерфейс интернет-банка. В 2015 году бизнес изменил стратегию развития и предъявил новые требования к веб-приложению. Нам предстояло: обновить Tinkoff.ru, интегрировать на все страницы функциональность интернет-банка и кошелька, поддержать SEO и SMM для всех страниц, включая страницы с платежными провайдерами. Новый интернет-банк имел UI-слой только на клиенте. Поисковые роботы пока не научились хорошо индексировать подобные приложения. И непонятно, когда это произойдет. Не получилось отказаться от серверного слоя. Мы видели несколько путей развития существовавших стэков: Объединить старый портал и новый интернет-банк. Портал выступал бы в качестве серверного UI-слоя, а Angular.js в качестве клиентского. Этот вариант не решил бы наши фундаментальные проблемы. Заменить Java приложение Node.js приложением. Это могло бы упростить поддержку, но оставалось два UI-слоя. Убрать Java, оставить только Angular.js. И рендерить SPA с помощью развернутых серверов с headless браузером Phantom.js. Такую схему сложно отлаживать, поэтому этот вариант не подходит для большого количества страниц. Мы проанализировали пути развития существовавших стэков и поняли, что они не решают наших задач. В итоге выбрали кардинально другой подход. Платформа 2016 То, что сейчас доступно на Tinkoff.ru, мы называем платформой. За основу этой системы мы выбрали архитектуру Flux, которую предложили инженеры Facebook в 2014 году. Flux отличается от MV* тем, что в нем отсутствуют разнонаправленные потоки данных, что легче ложится на изоморфную парадигму и всё это помогает быстрее отлаживать приложение. Архитектура Flux взяла за основу модель работы с базой данных CQRS. Мы реализовали идею изоморфного приложения с одним UI-слоем. В качестве шаблонизатора выбрали библиотеку React.js с поддержкой виртуального DOM. Благодаря которому шаблоны легко рендерятся на сервере. Сложившийся стэк решает задачи SEO и SMM. Переиспользует код между браузером и сервером, за исключением специфичного для окружения кода, например работа с cookies. Позволяет решать весь спектр задач одной группой разработчиков, что приводит к ускорению работы. Не зависит от одного фреймворка/вендора. Приложение объединяется набором правил, выстраивается из небольших и независимых модулей. Модуль можно заменить, если будет более подходящая реализация. Универсальное приложение Fluxible В качестве реализации Flux выбрали фреймворк Fluxible от инженеров Yahoo. Эта реализация ориентирована на изоморфный рендер. Выбранное решение полностью удовлетворяет нашим требованиям. Мы стараемся не связывать приложение крупными зависимостями, поэтому используем только две библиотеки из набора: Routr – маршрутизация по страницам. Библиотека поддерживает express-подобные пути. Она изоморфная и быстрая: сейчас роутимся по 2000 страницам. Dispatchr – Flux диспетчер. Распределение по слоям Архитектура приложения Сервисы. Доступ к браузерным или HTTP API, взаимодействие с внешними системами. Здесь содержится часть бизнес логики. Сервисы имеют несколько реализаций: изоморфные shared, server для node.js и client для браузера. Могут кэшировать результат. Действия. Flux action creators, содержат часть UI и бизнес логики. Имеют доступ к сервисам. Сторы. Модели данных, которые содержат UI логику. Компоненты. Рендер данных из сторов в HTML. Прогрессивная загрузка Благодаря серверному рендеру мы получаем эффект прогрессивной загрузки и сокращение time to glass. Средний пользователь видит работающую страницу через 600 мс после запроса сайта. Через пару секунд инициализируется динамика и загружаются персональные данные. Мы можем рендерить все данные на сервере, можем ренедрить часть. А можем полностью отключить серверную часть и использовать приложение как SPA. Чтобы сократить нагрузку на сервера, рендерим только общие данные для всех пользователей, а работу с персональными данными выполняем в браузере. Пример кода Что выполнять на сервере или что позволить запустить пользователю с определенными ролями, мы определяем на уровне функции создания действия: import { ACCOUNT_LIST } from '../actions'; import { CLIENT } from '../roles'; accountList.isServer = true; // Флаг указывает на право запуска действия на сервере accountList.requiredRoles = [CLIENT]; // Список указывает необходимые роли пользователя function accountList(context) { return context.service('account/list') // Каждая часть приложения имеет свой ограниченный контекст с набором методов из общего контекста. Таким образом вызываем сервисы. .then(payload => context.dispatch(ACCOUNT_LIST, payload)); // Далее диспатчим действие с полезной нагрузкой } export default accountList; В остальном коде приложения нет условий для определения окружения. Все решается на уровне контекста, который наследуется от базового класса контекста. Переиспользование Компоненты приходилось использовать с разными моделями данных. Их стало сложно поддерживать, тестировать и переиспользовать. Поэтому мы разделили компоненты на коннекторы и чистые компоненты: Такой подход упростил переиспользование компонентов и тестирование. Пример коннектора import { LogoPure } from './LogoPure.jsx'; const UILogo = connect( ['config', 'brands'], ({ brands, config: { brandsBasePath } }) => ({ brands, brandsBasePath }) )(LogoPure); export default UILogo; Используем утилиту connect (схожа с коннектором из redux), которую можно использовать в виде декоратора. Первый аргумент – список сторов, в которых мы заинтересованы. Второй аргумент – функция маппинга, которая принимает состояние всех сторов и возвращает только нужные чистому компоненту данные. Higher-order Components Следующий подход, который мы изначально не использовали для наследования кода — компоненты высокого порядка. Переиспользовать код между компонентами помогали миксины, которые поддерживает React.createClass. Миксины не гарантируют свое окружение. Если на компоненте использовать более трех миксинов и если они становятся зависимы, то поддержка такого компонента становится проблемой. Подробнее об этом в статье Mixins Are Dead. Long Live Composition. Оптимизация Оптимизация универсального приложения находится на двух сторонах: клиентской и серверной. Расскажу о наших подходах к разработке быстрого приложения. Оптимизация на клиенте Первое правило быстрых компонентов – как можно реже вызывать метод render. Для этого мы используем подход pure-render. Он вызывет render через переопределение метода shouldComponentUpdate, если только исходные данные изменились (props или state). Иногда в компонент передается больше данных, чем ему нужно. Иногда меняются поля модели, данные не меняются, а ссылка на модель данных изменилась. В этом случае проверка pure-render не срабатывает. Чтобы определить количество вызовов render того или иного компонента, мы используем модуль react-perf. С его помощью получаем статистику в удобном виде: Если находим компонент с неоправданно большим количеством ререндеров, то диагностируем его подробней с помощью нашей утилиты render-logger. Она позволяет увидеть измененные данные, которые повлекли вызов render: Рендер произошел из-за изменения функции, переданной в свойство onClick. Это происходит при использовании bind или определении функции внутри render родительского компонента, когда при каждом вызове render создается новая функция. И из-за этого не срабатывает защита pure-render дочернего компонента. Чтобы запретить bind в render, используем линтинг Eslint с плагином eslint-plugin-react и опцией jsx-no-bind. Batched updates React поддерживает изменение стратегии рендера в runtime. Мы используем стратегию пакетного обновления при первоначальной инициализации. Или при переходах между страницами, когда происходит повышенная активность приложения. Это уменьшает итоговое время рендера. Визуальное ускорение Следующий способ, который мы используем для ускорения клиентского экземпляра приложения, это визуальное ускорение. Считаю этот способ лучшим по соотношению затрат к результату. Сейчас на главной Tinkoff.ru есть шапка с логотипами платежных провайдеров, которые появляются с анимацией. В первых версиях логотипы появлялись только после загрузки клиентского пакета JS. На медленном мобильном интернете это приводило к неприятному эффекту долгой загрузки страницы. Пользователь ждал, когда серый блок будет наполнен. Мы решили изменить стили и код компонента, чтобы отрисовывать логотипы на сервере. Благодаря отказу от ожидания инициализации клиентской части, уменьшилось время до появления логотипов. Оптимизация на сервере Серверный рендер компонентов React медленней простых строковых шаблонизаторов. Я расскажу о том, как мы ускоряем рендер на сервере. Используем ES6 Class, а не React.createClass (он медленней из-за autobinding) и не забываем > Минифицированная версия React. Код для профайлинга удален полностью. +2% (здесь и далее прирост относительно первого пункта) Трансформация кода на уровне Babel. Используем два плагина: transform-react-constant-elements поднимает инициализацию компонентов в верхний скоуп модуля и transform-react-inline-elements преобразует вызов createElement к оптимизированному виду. +10% Максимально используем stateless функции. На тестовом стенде замена всех компонентов привела к прибавке в 45%. React-dom-stream приводит результат функции renderToString к потоку, что дает уменьшение времени до отдачи первого байта (TTFB) на нашем стенде до 3-5мс. И к сокращению времени до передачи последнего байта (TTLB) на 55%. На данный момент библиотека не поддерживает React 15. Возможно, функциональность библиотеки включат в ядро React: https://github.com/aickin/react-dom-stream/issues/18 Помимо этого, библиотека реализует интересную возможность кэширования компонентов по отдельности, что может ускорить серверный рендер. На данный момент мы кэшируем всю страницу. Благодаря отсутствию персональных данных в HTML, нам это далось легко. Кэш Кэширование в приложении реализовано на нескольких уровнях: Nginx кэширует на короткий промежуток времени результат генерации всей страницы. Express-cache-on-deamand страховка от потока однотипных запросов. Lru-cache библиотеку используем для кэширования результатов сервисов. С lru-cache мы используем нестандартную схему удаления данных из кэша. Любые данные при достижении TTL не удаляются из памяти, а запрашиваются у источника. Если источник ответил новым результатом – кладем значение в кэш. Такой подход повышает отказоустойчивость, когда внешние системы недоступны. Если мы единожды получили данные из внешнего сервиса, то уже не потеряем. Есть библиотека, которая реализует похожую схему: Сборка и деплой Для сборки и деплоя используем CI Teamcity. Делаем два отдельных артефакта для клиента и сервера. На сборке клиентского пакета обычная конфигурация Webpack. Со сборкой серверного пакета интересней. Сначала мы просто собирали пакет tar из исходников и распаковывали его на сервере. Когда модулей для компиляции Babel стало много, первые запросы на сервер стали проходить долго – Babel компилировал все при первых запросах. Первое реализованное решение – процесс прогрева перед стартом, компиляция. Затем настроили прекомпиляцию Babel при сборке артефакта, что сократило время прогрева до пары секунд. Сейчас в момент прогрева происходит только наполнение кэшей данными из внешних сервисов. Такой подход экономит время на сборке с помощью переиспользования времени, затраченного на компиляцию Babel в клиентской сборке. Второе решение, которое можно использовать – компиляция серверного пакета с помощью Webpack. Этот подход более функциональный, но влечет увелечение общего времени сборки. В артефакты мы не записываем переменные окружения, а передаем их только при старте серверного экземпляра приложения. Значения переменных окружения записываются в стор и передаются на клиент через стандартный процесс передачи состояния приложения с сервера на клиент. Для запуска и мониторинга приложения на сервере используем application runner PM2. PM2 имеет богатую функциональность. Для запуска приложения используем команду pm2 startOrGracefulReload processes.json, что позволяет перезапускать приложение с минимальным временем недоступности. processes.json: { "name": "portal", "script": "server/index.js", "instances": -1 } Если ваше приложение запускается более чем на одном сервере, то между ними есть балансировка. И в этом случае балансировка между форками с помощью Node.js кластера становится ненужной. Мы убрали балансировку балансировки и переложили эту ответственность на единую точку – Nginx. Каждый экземпляр приложения на всех серверах запускается на отдельном порту и Nginx знает о всех экземплярах. Благодаря PM2 сделать это просто. При выборе порта нужно учитывать переменную окружения NODE_APP_INSTANCE: PORT: process.env.PORT + process.env.NODE_APP_INSTANCE Завершение Универсальное веб-приложение решает выставляемые задачи, объединяет одну ответственность в одну кодовую базу. React.js заставил переосмыслить сложившиеся практики в разработке веб-интерфейсов. Виртуальный DOM становится стандартом де-факто для шаблонизаторов. Flux упрощает разработку и отладку сложных приложений. Node.js продолжает завоевывать свое законное место на корпоративных серверах. Если вы не разрабатывали приложения на схожем стэке, то, надеюсь, прочтение статьи сподвигнет вас на смелые эксперименты в этом направлении. Думаю, в ближайшие несколько лет не появится кардинально новых подходов и инструментов для разработки приложений, которые бы на порядок упрощали разработку. Есть смысл вложить немного своего времени в изучение React.js, Flux и присоединиться к нашей Dream Team. Пишите о себе на best-talents@tinkoff.ru. Делюсь фотографиями с одного планирования и обычной пятничной тусовки: Спасибо и до новых встреч! PS: Если вы хотите получить навык промышленной разработки веб-приложений, а также навыки создания конечных продуктов, то добро пожаловать в нашу летнюю школу FinTech. Курсы ведут наши специалисты и по итогу вы научитесь создавать финансовые продукты.

Нравится

Сотню старичков могут выбросить на улицу
Вторник, 21 Июня 2016 г. 20:09 + в цитатник
Попрактиковавшись в мастерстве составления заголовков новостей по методике современной журналистики, перейдем к делу: У нас к списанию подошло большое количество серверов одной модели: Dell PowerEdge 860 в модификации: Xeon 3050 (2 cores / 2.13 GHz) 2GB RAM 2 x 250GB HDDs Списание по причине безнадежного морального устаревания. Пристраиваем в хорошие руки бесплатно! Без СМС и регистрации, как говорится. Условия получения: 1) Забираете оптом (от 30 шт). Абсолютно бесплатно. От Вас только попросим рассказать нам для чего они Вам нужны и последующий фотоотчет как они будут пристроены. Предпочтение будет отдано социальным назначениям. 2) Забираете в розницу (от 3 шт). Забираете серверы бесплатно, но за вывоз из ДЦ попросим 50$ единоразово. 3) Передаем в собственность с последующим размещением у нас в стойке (любое кол-во). Для хабра будет спец-тариф как обычно: 35 $ за серверо-место (1U) с блэк-джеком и шл... с электричеством и интернетом. Можно будет доставить память/поменять диски. Самое интересное на десерт: физическая локация — Нидерланды (г. Утрехт) ;-) Все серверы — протестированы и рабочие. Да и вообще — крайне надежная модель. Чтобы всё честному и по белому: в комментарии пишите почту/кол-во/способ получения. В первую очередь будем отдавать тем, кому на колокейшн (Nothing personal, just business). Спасибо-пожалуйста!

Метки:  
Нравится

Разрабатываем погодного бота в среде IBM Bluemix на основе Facebook
Понедельник, 20 Июня 2016 г. 20:40 + в цитатник
На что обратить внимание в первую очередь при разработке собственного бота? Чат-ботами сейчас никого не удивишь. Они стали массово появляться в различных сервисах и мессенджерах. Основные социальные платформы постепенно вводят возможность разработки собственных ботов, что стимулирует сторонних разработчиков. Они предлагают все больше ботов, полезных и разных. Некоторые боты позволяют проверять баланс своего счета в банке, другие — помогают совершить покупку или заказать столик в ресторане. Почему боты стали такими популярными? Это довольно сложный вопрос. Вероятно, основная причина — огромное количество приложений в различных маркетах. Разработчик (частное лицо или компания) должны потратить множество времени и сил на раскрутку приложения. Их уже миллионы, приложений, и с каждым днем число программ увеличивается. Но выход есть — это как раз боты. Сейчас их гораздо меньше, чем мобильных приложений, и если создать интересного бота, он может стать популярным в считанные дни, если не часы. Пользователи любят ботов — ведь они очень удобны, в большинстве случаев. На что обратить внимание при создании собственного бота? Как выглядит процесс его создания? Обо всем этом давайте поговорим прямо сейчас. Что нужно учитывать при создании своего бота? • Качество взаимодействия– то, как происходит взаимодействие пользователя с ботом, определяет его успешность. Вариации диалога должны быть насыщенны и достаточно полезны. Бот, который не понимает немного перефразированный запрос, будет выглядеть нелепо. IBM Watson, например, доказал, что обучаемые чат-боты можно применить для победы над обычными участниками таких игровых шоу, как «Своя игра», основанных на знаниях. Так как естественный язык Watson и его вариации диалогов можно найти на платформе IBM Bluemix, вы можете использовать их для вашего бота. Вашему боту не обязательно проходить тест Тьюринга. Банковские приложения, например, имеют определённый набор вещей, которые они могут сделать. Так что не стоит создавать излишне перегруженный бот, который будет пытаться отвечать на открытые вопросы вроде «Как мне разбогатеть?» • Независимость от платформ по обмену сообщениями – Эта область переменчива; сложно сказать, какими будут через год предпочтения вашей целевой аудитории в плане мессенджеров. По возможности, создавайте боты, не завязанные на конкретный мессенджер. • Архитектура – чтобы ваш бот был динамичен и позволял пользователю успешно выполнить поставленную задачу, он должен чётко работать с другими службами облака и предыдущими наработками. Убедитесь, что вы пользуетесь технологией, которая легко позволяет хранить и получать доступ к информации и не подведёт при растущем потоке пользователей. Боты – это больше чем чат, убедитесь, что вы можете сформулировать и реализовать логику вашего бизнеса максимально гибко и при этом измеримо. • Думайте стратегически – боты — это не просто ещё одна функция. У них есть потенциал для переосмысления существующей концепции мобильных технологий и начала новой эры – Эры после приложений the post-app era. С чего начать? Для того, чтобы показать, насколько прост процесс создания собственного бота на основе IBM Bluemix, мы предлагаем прямо сейчас заняться разработкой погодного бота для мессенджера Facebook. Учиться будем прямо в процессе создания бота. Итак, наше приложение-бот будет модульным, и состоять из четырех блоков-модулей. Основной модуль — Broker, он обеспечивает взаимосвязь нашего бота с Messaging Platform. В нашем примере связь идет только с Facebook Messenger, но спектр взаимодействия бота с различными платформами можно и расширить. Weather App — модуль, который отвечает за интерпретацию текстового запроса и формулирование ответа. Погода в нашем случае — просто пример. Информация может быть и финансовой, касаться шопинга, продуктов, и т.п. Работу модуля Weather App обеспечивает облачная платформа Bluemix. Эта платформа — продукт нашей компании, это ясно. Но мы выбрали ее не только потому, что это разработка IBM, но и потому, что Bluemix — действительно позволяет много чего сделать. Вот основные достоинства системы: Качество взаимодействия. Благодаря IBM Watson, Bluemix позволяет разработчику использовать инструмент анализа речи и формирования диалогов. Сейчас эти сервисы доступны в IBM Bluemix, так что они доступны всем без исключения пользователям платформы. Независимость от платформы мессенджера. Если выбрать одну какую-то платформу (тот же Facebook) и создать бота на ее основе, то бот будет жестко привязан к этой платформе. А Bluemix позволяет создать независимый сервис, который не будет зависеть от капризов владельцев платформы мессенджера. Связность с другими облачными платформами и сервисами. Bluemix предлагает возможность связать бота с другими облачными сервисами — было бы желание. А теперь — приступаем к разработке Что требуется? • Аккаунт Bluemix для разработчика; • Аккаунт Facebook для бота; Конфигурируем страницу Facebook и приложение • Со страницы выбранного аккаунта выбираем в меню «Create a New Page»; • Выбираем «Cause or Community», вводим имя и кликаем «Get Started»; • Со своей страницы Facebook for Developers выбираем My Apps / Create a New App и нажимаем ‘basic setup’; • Вводим нужные данные и нажимаем «Create App ID»; С Facebook пока все — приступаем к настройке аккаунта в Bluemix. • Из панели Bluemix выбираем ‘Cloud Foundry App’ -> ‘Create App’; • Выбираем «Web»->‘SDK for Node.JS’; • Нажимаем «Continue» и вводим название приложения; • Выбираем «Download Starter Code» и указываем место для загрузки; • Открываем файл app.js и заменяем дефолтный код вот этим кодом с GitHub; • Открываем файл package.json и под dependencies вносим следующие изменения: “body-parser”: “^1.15,0”, “express”: “^4.13.4”, “request”: “2.72.0” • Для запуска Broker App to Bluemix используем следующую команду: ‘cf push using manifest file path/manifest.yml, заменив «path» путем к нашему файлу. Подключаем приложение Facebook к своему приложению Broker App: • На странице Facebook Developer под «Webhooks» выбираем New Subscription / Page; • Под "‘Callback URL" заполняем Broker App URL. Найти это можно сразу под названием приложения • Затем в ‘Verify Token’ заполняем токен, заданный в Broker App (в нашем примере это ‘mySecretAccessToken’); • В ‘Subscription Fields’, выбираем messages, message_deliveries, messaging_options и messaging_postbacks; • Для получения токена доступа Facebook нажимаем ‘Messenger’ и ‘Get Started’. Выбираем созданную ранее страницу, «okay», копируем сгенерированный Page Access Token; • Теперь используем Terminal и выполняем следующую команду: curl -ik -X POST “Facebook_access_token_goes_here”; • Снова открываем app.js и применяем токе Facebook в token var; • Запускаем Broker App в Bluemix, как было указано выше. Создаем Weather App в Bluemix • В среде Bluemix выбираем AlchemyAPI, Insights for Weather, и Natural Language Classifier, которые необходимо привязать к нашему приложению; • Мы уже научили Watson Natural Language Classifier понимать вопросы о погоде. Он может отличить вопрос о самой погоде от простого вопроса о температуре. Вот здесь рассказывается, как можно обучить собственный классификатор; • После того, как вы обработали собственный классификатор, должен появиться id; • Теперь качаем начальный код для своего приложения Node.js; • Открываем файл app.js и заменяем пример кода вот этим примером с GitHub; • Вставляем свой id, полученный пару пунктов выше; • Открываем package.json и в dependencies вносим следующие изменения: «JSON»: "^1.0.0", «body-parser»: "^1.15.0", «cfenv»: "^1.0.3", «express»: "^4.13.4", «node-geocoder»: "^3.9.1", «request»: "^2.71.0", «watson-developer-cloud»: "^1.4.1" Запускаем Weather App в Bluemix Подключаем Broker App к Weather App • Открываем app.js приложения Broker; • Ищем вот такой код: request(«whatistheweather.mybluemix.net/getWeather?text=» + text, function (error, response, body) • Заменяем URL на URl своего Weather app; • Запускаем Weather App в Bluemix. Заработало? Отлично. Если хотите больше информации по этой тематике, то обратите внимание: 23 июня пройдет бесплатный онлайн-семинар по Bluemix, на котором наш специалист Тимур Маркунин покажет, как создать ботов-переводчиков и ответит на самые насущные вопросы. Зарегистрироваться можно здесь.
В популярном архиваторе 7-Zip исправили серьезные уязвимости

Метки:  
Нравится

Security Week 24: черный рынок угнанных RDP, зиродей в Flash, GMail отказывается от SSLv3 и RC4
Воскресенье, 19 Июня 2016 г. 23:04 + в цитатник
Одна из самых резонансных новостей этой недели посвящена черному рынку удаленного доступа к серверам. Эксперты «Лаборатории» исследовали сервис, на котором любой желающий может недорого приобрести информацию для доступа к одному из 70 с лишним тысяч серверов по всему миру по протоколу RDP. Взломанные серверы достаточно равномерно распределены по земному шару, примерно треть приходится на страны, где выбор — максимальный: Бразилию, Китай, Россию, Индию и Испанию. Ничего не подозревающим владельцам этих серверов наверное будет интересно узнать, что с ними могут сделать злоумышленники, но тут я даже затрудняюсь в выборе, с чего начать. Если коротко — сделать можно все. Дальнейший взлом инфраструктуры жертвы — без проблем. Рассылка спама, DDoS-атаки, криминальный хостинг, кража информации, таргетированные атаки с эффективным заметанием следов — тоже можно. Кража данных кредиток, денег со счетов, бухгалтерской отчетности — да, если взломанный сервер имеет доступ к такой информации. Все это — по смешным ценам: 7-8 долларов за учетку. XDedic и подобные сервисы (можно предположить, что он такой не один) — это криминальный екоммерс и финтех, он объединяет преступников разного профиля, крутых и не очень, использует современные технологии, предоставляет качественный сервис. Сами украденные данные предоставляют больше 400 продавцов — тут вам и конкуренция, и борьба за увеличение количества взломов. Самый подходящий момент напомнить — вас могут взломать, даже если вам кажется, что ваши данные никому не нужны. Во-первых, нужны, и вам в любом случае не понравится, как их используют. Во-вторых, ресурсы тоже стоят денег, а когда цена вопроса — три копейки, под удар попадают все вплоть до малого бизнеса. Украдут деньги со счета, или дампы кредиток, или хотя бы контакты клиентов для рассылки спама, атакуют через вас другую компанию, а если вообще ничего не выйдет — ну поставят генератор биткоинов и сожрут электричество. С такими эволюциями киберкриминала трудно бороться, но данное исследование позволяет примерно понять, как это делать. Все выпуски сериала — тут. Не исключено, что у многих жертв xDedic и взлома никакого не происходило, а пароль к RDP был добыт простым перебором. Потенциальным солдатам этой подпольной армии даже не обязательно осваивать такие примитивные скиллы: приложение для брутфорс-атаки на RDP предоставляется там же. Еще одна утилита — по сути своей троян — помогает поддерживать актуальность базы серверов и собирать информацию о доступных ресурсах. Она же сканирует систему на наличие интересного для криминала софта. Ищут инструменты для массовой рассылки сообщений (для спама), приложения для доступа к сервисам азартных игр (чтобы красть оттуда деньги), финансовое ПО (аналогично). Отдельно идет длинный список софта для платежных терминалов и кассовых аппаратов: в общем тоже понятно для чего. Как бороться с этим — не очень понятно, если смотреть с точки зрения потенциальных жертв. Традиционный подход, уже устаревший, но повсеместно применяемый — пытаться закрыть угрозу технологией, то есть софтом. Но в данном случае это просто не работает — нельзя закрыть софтом склонность киберпреступников объединяться для совместного заработка. ОК, подозреваю, что многие жертвы xDedic не выполняли простые рекомендации по защите доступа по RDP. Но дело не в RDP, если закрыть эту дырку, останется еще сотня других. А вот получение информации о подобной криминальной активности, и не просто в формате увлекательного чтива, а с готовыми индикаторами взлома (наличие утилиты-анализатора, подключение к характерным C&C итд), чем раньше, тем лучше — вполне позволит стереть пару ноликов из чека на восстановление после взлома. Добро пожаловать в будущее информационной безопасности, где работают и ценятся прежде всего знания и способы их применения на практике. Zero-day уязвимость во Flash, ждем патч Новость. Advisory Adobe. Исследование «Лаборатории». За последнее время уязвимостей Flash было немало, в том числе критических, в том числе уязвимостей нулевого дня — которые активно эксплуатируются в отстутствие патча. Отличием уязвимости CVE-2016-4171 стало то, что эксперты «Лаборатории» одним махом и баг нашли, и расследовали операции сравнительно молодой APT-группировки, известной как Starcruft. Исследование дает несколько больше технических деталей об уязвимости, чем обычно. Эксплойт использует один из модулей обработки метаданных, где производится чтение данных без контроля границ, что естественно может привести к переполнению буфера. Несколько последовательных операций записи данных, и атакующие получают возможность выполнения произвольного кода. Виновник торжества обведен рамочкой Помимо этого в арсенале Starcruft была обнаружена интересная схема обхода защитных решений. Для этого используется баг (возможно правильно будет назвать это недокументированной фичей) библиотеки Windows DDE, в результате чего последняя используется как прослойка между операциями выполнения эксплойта и запуском вредоносного кода. Так как Adobe Flash — известный источник проблем, защитное решение может отслеживать подозрительные операции выполнения кода от имени процесса, но в данном случае может такой хитрый ход и пропустить. Самое время сказать, что антивирус — не торт, но нет. Новая уязвимость была обнаружена в апреле с помощью автоматизированной системы детектирования эксплойтов, использующейся в наших продуктах. Как бы то ни было, патча уязвимости от Adobe пока нет, хотя возможно он появится прямо в ближайшее время (обещали 16 июня). Gmail прекращает поддержку протоколов SSLv3 и RC4 для подключения по IMAP/POP Новость. Анонс Google. Google последовательно ликвидирует поддержку небезопасных протоколов шифрования данных для собственных сервисов, в первую очередь — для GMail. Оба протокола давно признаны небезопасными и легко взламываемыми, и хотя в Google говорят, что абсолютное большинство клиентов забирают почту с помощью протокола TLS 1.2, некоторое ограниченное количество почтового софта может перестать работать — начиная с 16 июня, но поддержка будет постепенно отключаться еще месяц. В общем у пользователей древних смартфонов и антикварного компьютерного ПО могут возникнуть проблемы. Действия Google, как и предыдущие инициативы по отказу от SSLv3 в браузерах, можно назвать превентивными: информации об атаках для плохо защищенные соединения пока не было (возможно те, кто слушают — особо это не афишируют). Несмотря на то, что RC4 был объявлен небезопасным еще в 2001 году (первые работы вообще были в 1995-м), его продолжают исследовать, так как, увы, его по-прежнему используют. Одно из свежих исследований (PDF) показывает возможность частичной расшифровки трафика за 52 часа. Что еще произошло: Очередные hardcoded ключи нашлись в роутерах Netgear. Новый криптолокер написан на чистом Javascript. Древности: «Warrior-1024» Нерезидентный очень опасный вирус. Стандартно записывается в EXE-файлы. На время работы файла-носителя вирус остается в памяти, перехватывает int 21h и при записи в файл (ah = 40h) вместо записываемой информации подставляет текст: "… and justice for all! (US constitution) Dream Over… And the alone warrior is warrior. The powerfull WARRIOR!". Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 94. Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Метки:  

Поиск сообщений в kopusouthb
Страницы: [2] 1 Календарь

О проекте