суббота, 30 апреля 2016 г.
Русский перевод выступления Алекса Ионеску «Сумасшедшая попытка переписать Windows с нуля»
Переводчики: gste, leha_bot, Goudron, elnardu, x4fab, music_maniak, rumorukato, AHgpyxA, steven_quartz, jeditobe, Ctulhu31, RooGLM, peterder72, mariocca
Скачать через торрент magnet:?xt=urn:btih:15E110B8DA04E6907FC4AE07C90C180FCE3E590C&dn=ReactOS%20Alex%20Ionescu&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.opentrackr.org%3a1337%2fannounce
В этой беседе Алекс Ионеску, ведущий разработчик ядра для проекта ReactOS с 2004 года (и недавно вернувшийся после долгого перерыва) расскажет про текущее состояние проекта, который уже прошёл 60000 ревизий в репозитории SVN. Алекс также охватит некоторые цели проекта и методологию разработки и тестирования, являющейся в таком проекте широкомасштабным мероприятием (open-source проект по имплементации всей ОС Windows с нуля!), в содействии с другими open-source проектами (MinGW, Wine, Haku и т.д.).Алекс расскажет про инфраструктуру, которая позволяет запустить такой масштабный проект операционный системы (при этом без корпоративных ресурсов ресурсов), а также про ежедневные трудности в условиях работы очень распределённой команды и сильного недостатка знаний об устройстве Win32, которые сильно затрудняют набор новых участников. Наконец, Алекс продемонстрирует работу ОС, попробует работу новых игр и приложений, работу в интернете и пр., и, конечно же, покажет пару синих экранов смерти (BSOD).
Алекс также покажет, как новые сборки ReactOS могут быть собраны прямо из Visual Studio, и как можно заниматься отладкой ядра стандартным отладчиком Microsoft WinDBG, проходя по коду практически-ядра-Windows для отладки проблем с реальными драйверами или приложениями. Если позволит время, Алекс коснётся вопросу реверс-инжиниринга функций Windows или драйверов для целей понимания их логики работы, что может помочь с отладкой проблем вне поля использования ReactOS.
пятница, 29 апреля 2016 г.
Путь лапласиана. Часть 2
А не замахнуться ли нам на Эдсгера нашего Дейкстру?
В первой части мы описали способ ранжирования симметрично связанных объектов (узлов неориентированного графа) относительно заданного направления. Для каждого объекта (узла) вычисляется потенциал (лапласиана), который определяет его положение относительно заданных источника и цели. В данной статье мы покажем, как потенциалы узлов упрощают задачу поиска кратчайших путей (оптимальных маршрутов). А также как меняются сами потенциалы при изменении внешних условий.
В общем случае минимизируемая величина — это необязательно расстояние, — весами ребер графа могут быть стоимости, штрафы, убытки, времена, — любые величины, которые можно складывать. Задача является классической, наиболее простой алгоритм поиска кратчайшего пути дал Э. Дейкстра аж в 1959 году.
Карта потоков
На основании вычисленных в предыдущей части потенциалов и заданных связностей/проводимостей (обратных расстояниям) можно нарисовать карту потоков. Вот ее вид:
Источник (Салтан) и приемник (Гвидон) выделены квадратами. Рядом с названием узла (острова) округленное значение потенциала. Цифры рядом со стрелками отражают величину потока (разность потенциалов деленная на расстояние).
Если бы Салтан пошел на Гвидона армией, то ему бы пришлось распределять направления перемещения масс с учетом величин потоков, указанных на данной карте. Или если б Салтан был комаром фотоном или электроном — тогда бы он тоже полетел/поплыл по всем путям одновременно. Но в реальном мире рулят путешественники-одиночки с ненулевой массой, поэтому нам нужны не все пути, а как раз наоборот — один, но оптимальный.
Наличие потенциалов упрощает (ускоряет) построение оптимального пути. Есть два основных алгоритма — быстрый (но без гарантий оптимальности) и точный. Последний тоже быстрый (относительно классических), но медленнее первого.
Алгоритм Нео
Вспомним рекомендацию Нео — "если хочешь добраться ко сроку — плыви по максимальному потоку". Мы можем ей воспользоваться на основании приведенной карты.
Идея такая. Для каждого узла приведенного на рисунке графа (кроме исходного) надо оставить только входящую ветку и удалить все остальные. Это гарантирует однозначность маршрута от источника. Условием выбора входящей ветки будет максимальность потока.
Для того, чтобы обеспечить скорость работы алгоритма и не перебирать все узлы графа, надо начать с конечного (целевого) узла и двигаться от него по веткам с максимальным потоком в начало.
Согласно карте максимальный поток (4.35) на Гвидона идет с Врангеля — значит, оставляем ветку «Врангель-Гвидон» (включаем ее в путь).
Переходим по ветке на Врангеля. Максимальный поток на Врангеля (2.10) идет с Буяна — идем на Буян. С Буяна соответственно на Альбион, с Альбиона — на Салтана, путь построен. В нашем случае он действительно оптимальный (относительно сумм весов веток исходной карты расстояний) — повезло.
Достоинство данного способа — простота и быстрота построения пути. Мы перебираем только те узлы графа, которые входят в маршрут, то есть скорость работы алгоритма фактически пропорциональна длине оптимального пути (часто это намного меньше размера графа).
Минус — использованный принцип (максимальный поток) не гарантирует оптимальности маршрута. Можно построить карту, для которой «маршрут Нео» будет не самым оптимальным, хотя и близким к нему.
Алгоритм Дейкстры с ранжированием
Если нужен оптимальный алгоритм с гарантией, то придется считать расстояния для каждого узла. Данный способ похож на упомянутый в начале алгоритм Дейкстры, но использование потенциалов (упорядоченности узлов) позволяет выполнить данный расчет за линейное (относительно количества узлов графа) время.
Принцип остается тем же — нам надо определить (оставить) только одну входящую ветку для каждого узла (кроме исходного). Но теперь мы будем использовать точно рассчитанные для узлов длины путей (расстояния от источника) и оставлять ветки с минимальной длиной пути.
Начинаем с начала (остров Салтана) и далее по степени убывания потенциала перебираем каждый узел/остров. Использование порядка перебора узлов гарантирует, что при определении длины пути до текущего узла входящие в него ветки будут идти от уже посчитанных узлов.
Итак, поехали. Остров Салтана является источником, поэтому ему присваиваем нулевую длину пути — d(Салтана) = 0. У источника нет входящих веток (нечего обрезать), поэтому переходим к следующему — Борнео.
У Борнео только одна входящая ветка, поэтому для него сразу можно определить расстояние от источника d:
d(Борнео) = d(Салтана) + Вес пути (Борнео — Салтан) = 0 + 1 = 1
Идем далее на Альбион. В Альбион входит две ветки — от Салтана и от Борнео. Длина пути d для них уже известна, поэтому можно определить длину пути Альбиона для обеих веток: от Салтана — 2, через Борнео — 1+3 = 4. Оставляем минимальную (от Салтана) и присваиваем Альбиону расстояние от источника — d = 2.
Ненужные ветки либо помечаем как неактуальные, либо (если нам нужно построить минимальное дерево — остов графа) удаляем.
Следующий по порядку — остров Буян. У Буяна три входящих ветки. Определяем минимальную — эту будет ветка через Альбион и длина пути от источника до Буяна будет d(Альбион) + 1 = 2 + 1 = 3.
И так далее для всех островов. Последним будет остров Гвидона — на нем расчет пути заканчивается. Для определения оптимального пути двигаемся в обратном направлении от Гвидона до Салтана по актуальным входящим веткам.
В отличие от алгоритма Нео здесь нам приходится пройтись по всем узлам графа и для каждого рассчитать оптимальное расстояние от источника. Но зато мы можем сразу построить дерево (остов) достижимости всех узлов графа из источника (у такого дерева интересные свойства, но это отдельная тема).
Достоинство данного алгоритма по сравнению с классическим Дейкстрой — он однопроходный (сложность ~n). Путь до узла считается только один раз и больше не пересчитывается — следствие упорядоченности узлов графа. Соответственно скорость данного алгоритма выше. Но за все приходится платить. Здесь платой являются начальные затраты на расчет потенциалов (матрицы потенциалов) узлов.
Можно было бы назвать данный алгоритм «улучшенным алгоритмом Дейкстры», если бы у Дейкстры уже не было n-го количества улучшений. Назовем его поэтому «алгоритмом Дейкстры с предварительным ранжированием».
Салтан может отправляться в путь — Альбион (2) > Буян (3) > Врангеля (5) > Гвидон (6). Привет князю.
Устойчивость к переменам
Как известно, устойчивость системы определяется ее реакцией на внешнее воздействие. Если при небольшом изменении входных параметров системы получаем большие изменения выходных — то это слабо устойчивая система. Применительно к алгоритмам на графе это означает, что устойчивый алгоритм не должен требовать полного пересчета в случае изменения, например, величины связности одного из ребер графа.
Достоинство использования матрицы потенциалов в том, что изменение входных требований можно учесть явными формулами — повторного обращения лапласиана не требуется.
Что может измениться? Ну, например, на обратном пути надо заехать из Гвидона в Борнео. Какой маршрут оптимальный? Если есть матрица потенциалов, то пересчет прост — надо посчитать потенциалы нового направления и выполнить описанный выше алгоритм расчета оптимального пути.
В нашем случае важна только разность потенциалов между узлами, поэтому значения потенциалов узлов при заданном источнике S и приемнике G можно считать по формуле:
Это аналог формулы (2.5) из предыдущей части. По данному выражению очень просто пересчитать потенциалы для нового маршрута (например, из Гвидона в Борнео).
Более сложная ситуация — изменилась проводимость (связность) одного из путей (у нас в городе каждой весной такая ситуация) — как это скажется на значениях потенциалов?
Изменение потенциала i-го узла при изменении связности ребра jk запишем как:
Отметим во избежание путаницы, что здесь под производной понимается симметричное возмущение, то есть
(В предыдущей части для возмущения мы использовали направленную производную, там варьирование было несимметричным: ).
Из выражения (2) видно, что для определения изменений потенциалов узлов нам надо научиться считать производные матрицы потенциалов . Эти же производные будут востребованы, если понадобится пересчитать значения матрицы потенциалов при изменении связности
.
Смежные производные и потенциалы 3-го порядка
Возможны три ситуации в зависимости от пересечения множеств индексов i, j и k, l. Если индексы варьируемой переменной kl совпадают с индексами потенциала i j, то тут все просто — производная равна 0.
Если совпадает только один из индексов, то будем назовем такую производную смежной. Смежная производная потенциала 2-го порядка выражается через потенциал 3-го порядка:
Поскольку значение симметричного потенциала не зависит от порядка индексов, то видим, что что все смежные производные с одним и тем же составом индексов равны между собой:
Для нас важно, что потенциалы 3-х порядков могут быть выражены через матрицу потенциалов (то есть через потенциалы 2-го порядка) согласно тождеству:
Выражение (5) можно немного укоротить:
Здесь — скалярный (общий) потенциал, который можно рассматривать просто как множитель.
Избавимся в (5) от обозначений потенциала и оставим только индексы:
Дамы и господа, перед нами знаменитая Джоконда формула Герона, которая как известно, используется для нахождения площади треугольника. Да, потенциалы 3-го порядка тесно связаны с площадями фигур. Следствие того, что как уже отмечалось, потенциалы 2-го порядка не менее тесно связаны с квадратами расстояний.
Но вот как так получается, что производные каких-то потенциалов каких-то абстрактных графов вдруг оказываются связанными с формулами геометрии — загадка и маленькое чудо.
Итак, смежные (и симметричные) производные потенциалов (по связности) можно выразить через сами эти потенциалы.
Теперь мы можем посчитать, например, как изменится потенциал ветки «Борнео-Альбион» при изменении связности ветки «Салтан-Борнео». Согласно формуле нам нужны для этого потенциалы между всеми 3-мя узлами. Согласно матрице потенциалов имеем:
- «Салтан — Борнео» — 6.25,
- «Альбион — Борнео» — 8.36,
- «Салтан — Альбион» — 8.19.
Скалярный потенциал лапласиана равен 8.61.
Подставляя значения потенциалов в формулу (6) и (4), получаем значение изменения потенциала для единичного варьирования:
Так и есть, можете проверить.
Свободные производные потенциалов 2-го порядка
Под свободной производной мы понимаем такую, в которой индексы варьируемой связности не пересекаются с индексами потенциала. На самом деле это и есть наиболее общий случай, из которого должны следовать все остальные. Но именно поэтому выразить значение данной производной через значения потенциалов 2-го порядка оказалось не так-то просто (во всяком случае — мне).
Опуская подробности (укажем лишь, пожалуй, что выражения потенциалов одного порядка через другие удобно использовать тождество Доджсона, который по совместительству Льюис Кэрролл), приведем конечный ответ. Он совпал (и, конечно, стал сразу очевидным после того, как был найден) с выражением для площади четырехугольника (откуда тут площади — уже обсуждали, а почему четырехугольник — тоже понятно — у нас 4 независимых вершины графа). В индексных обозначениях:
(Мы тут довольно свободно используем обозначения, чтобы не загромождать общую структуру, — надеюсь, все понятно. Одинокая (и свободная) i — это скалярный потенциал).
Четырехугольник, площадь которого соответствует данной формуле, образуется вершинами i, j k, l. При этом вершины i, j (и соответственно j, k) должны быть противоположными.
Потенциалы — это квадраты длин диагоналей данного четырехугольника (ну и длинное же слово). Остальные потенциалы — квадраты длин сторон.
Круто. Я не понимаю, как и почему производные потенциалов связаны с площадями, но все равно спасибо за то, что формулы такие простые. (И, пользуясь случаем, — спасибо, Wolphram — нет-нет, да выручаешь).
Тождество (7) является пуантой наших усилий (тут бы надо сесть и не спеша над ним помедитировать. Но некогда).
Из него легко получить формулу Герона (6) и тождество (3), которое геометрически объясняется тем, что площадь отрезка равна 0 (в терминах геометрии это очевидно, а в потенциалах лапласиана — не сразу).
Теперь у нас есть формулы для всех видов производных. Можно, например, рассчитать изменение потенциала ветки «Альбион — Гвидон» при том же изменении связности «Салтан-Борнео» (для тех, кто захочет, ответ — 9.36).
Таким образом матрица потенциалов лапласиана (плюс скалярный потенциал) определяет и значения всех своих производных (а также потенциалов более высоких порядков). Данное свойство позволяет динамически поддерживать актуальность значений матрицы при изменениях связности ребер графа. Нам не надо обращать лапласиан, достаточно воспользоваться формулой площади четырехугольника (7) и вычислить новые значения потенциалов.
Резюме
Заканчиваем. В статье мы рассмотрели использование потенциалов для одной из классических задач — поиск кратчайшего пути. Матрица потенциалов позволяет упростить и ускорить алгоритм такого поиска. Это неплохой и полезный прикладной результат.
Но главное даже не в этом. Мы использовали данную задачу лишь как повод рассказать о лапласианах и о некоторых их замечательных свойствах. Показали, что представляет собой матрица потенциалов и как ее можно использовать. Увидели, как неожиданно проявляется связь между казалось бы различными областями математики. Пользуйтесь!
Комментарии (0)
The Art of Rx
Я покажу на примерах, как делать не надо и как нужно делать обязательно.
Я расскажу, что такое контракт потока и как его соблюдать.
А также покажу, какие части внутри RxJava меня особенно радуют.
Пишу на Scala под Android, люблю функциональщину и реактивщину. Довольно консервативен в плане выбора технологий и фреймворков. Ну а раньше я работал тимлидом в 2GIS.
Так Матвей Мальков обращается на сайте конференции Mobius к будущим слушателям своего доклада. Читайте наше интервью…
— Добрый день. Расскажи в двух словах о себе. Где работаешь, чем занимаешься, когда начал продвигать реактивный подход?
— Привет. Меня зовут Матвей Мальков. Я Android-разработчик уже, наверное, лет 5-6. Конкретно сейчас я занимаюсь Scala-разработкой в одном стартапе. Стартап находится в Москве и о нём я говорить особо много не могу. Но суть в том, что это будет такая комьюнити-платформа, наподобие Телеграма. И её я, собственно, пишу под Android на Scala.
Первый проект, который я полностью перевел на RxJava, у меня был в компании 2GIS. Архитектура, база, работа с сетью — всё. После этого начал активно продвигать фреймворк RxJava и реактивный подход в целом на конференциях. Сейчас пишу на Scala, где использую вовсю функциональный подход, а в свободное время интересуюсь новостями реактивного мира
— Пользователи Хабрахабр наверняка в курсе концепции реактивного программирования. Расскажи про особенности этой парадигмы на Android и про реактивные потоки данных.
— В программировании под Андроид довольно много особенностей, связанных с реактивным программированием. Я как раз хотел бы сказать о том, что не все принципы реактивного программирования, о которых мы попозже подискутируем, хорошо ложатся на Андроид. Чтобы не быть голословным: есть такое понятие как масштабируемость, под которой обычно понимается масштабируемость на большое количество нод, то есть это какая-то серверная масштабируемость. В Андроиде же это всего лишь масштабируемость на треды, что не есть «настоящая» маштабируемость". И она не даёт такого большого мощного импакта на систему в целом. Хотя, конечно, всё равно даёт, но по-другому.
Ещё одна особенность заключается в том, что очень много в Андроиде завязано на императивщину. То есть на мутабельность, на изменяемость данных, и конкретно из-за неё очень сложно всё это завернуть в реактивные потоки. Это приводит к тому, что приходится делать много хаков, что всё очень усложняет. Императивность Android заставляет большое количество разработчиков использовать такие вещи, как сабжекты, которые вообще-то были задуманы и сделаны для того, чтобы сращивать мир реактивный и мир императивный. Но по факту, на самом деле, все пользуются им для того, чтобы что-то легко завернуть в Observable, Это обычно происходит в ущерб архитектуре, особенно на длинной дистанции, на больших проектах. Получается мешанина из императивщины и абы как сделанной на ней реактивщины. А всё потому, что многим людям просто лень сделать правильно или они не знают, как именно правильно.
На самом деле, это в общем-то всё, потому что в правильной архитектуре под Андроид взаимодействие с сетью, кэширование и вообще вся общая бизнес-логика не должна быть завязана на какие-то андроидные части. Поэтому собственно это просто бизнес-логика, которая работает, как и в любых других проектах. Не только в андроидных.
— Главные принципы реактивного программирования (отказоустойчивость, отзывчивость, событийная ориентированность, больше возможностей для масштабирования) были сформулированы давным-давно. Насколько ты согласен с этими принципами сейчас?
— Если говорить о принципах из реактивного манифеста, который, собственно говоря, и является фундаментом и основой идеологии реактивного программирования, то в своей статье на Хабрахабре я подробно раскрывал все эти пять принципов и проецировал их на Андроид-разработку. И безусловно да, я с ними до сих пор согласен. Это костяк, это основные принципы, основные импакты, на которые стоит рассчитывать, когда ты разрабатываешь, используя реактивный подход, и это основные вещи, за которые ты должен бороться, когда ты используешь реактивщину.
Если мы берём отказоустойчивость, то ты всегда должен думать об этом. Это довольно легко, но ты всегда должен держать это в голове. Правильно обрабатывать ошибки и спрашивать себя, все ли кейсы ты обработал и рассмотрел. Реактивщина даёт тебе удобные устройства для этого, но ты всё равно должен об этом думать. И соблюдение всех этих принципов позволяет тебе строить очень хорошие архитектуры и очень хорошие приложения. И, как я уже говорил про масштабируемость, в Андроиде она особо не даёт какой-то импакт, разве что на треды проецируется.
— Что важнее: ресурсоёмкость или надёжность? Ведь есть лимит на выдачу потоков в Android, можно выбросить бюджетные устройства за «борт», просто потому, что приложение (стало) более требовательно к ресурсам :)
— Конечно и безусловно, намного важнее надёжность, потому что сейчас в андроид-мире наметился тренд на то, что очень много устройств находится в дешёвом сегменте. В Индии запустили Android One, в Америке продают телефоны за несколько долларов. То есть появились очень дешёвые и супердешёвые андроид-смартфоны, которые безусловно не могут работать также, как Nexus 6P. Владельцев таких смартфонов становится всё больше и списывать их всех со счетов нельзя.
Но, конечно, про ресурсоёмкость забывать тоже нельзя. Она не вторична, эти два принципа должны идти параллельно друг другу. В той же реактивщине мы можем в зависимости от устройства, от количества ядер задавать разное количество потоков для операций. То есть пусть в бюджетных устройствах что-то работает медленнее, но работает точно и отрабатывает чётко. Пусть это занимает больше времени, но тем не менее. Между этими вещами стоит находить баланс, но внимание держать нужно на обоих!
— Ты сказал, что довольно консервативен в плане технологий и фреймворков. Расскажи про фреймфорк RxJava и его плюсах и минусах.
— Есть такая вещь как Framework-driven-development. Это болезнь, наверное, фронтенда в первую очередь. Да и всего андроид-мира. Представь, что ты не можешь решить какую-то задачу быстро, и тебе конечно же лень думать и ты пытаешься найти какой-то фреймворк, который написал никому не известный индус. У этого фреймворка версия 1.0.0 или 1.0.1, то есть пропатчил он его всего один раз, а написал года три назад. И он как-то удовлетворяет твои нужды. Библиотека не расширяемая, может падать, но свою работу как-то выполняет. Это очень сильно распространено и люди постоянно тянут подобные фреймворки к себе в проект. Я считаю, что так делать нельзя и поэтому везде пишу, что я довольно консервативен в этом плане.
Что можно сказать про фреймворк RxJava? Очень круто, что около него уже есть мощное комьюнити, он часто правится, баги всё время фиксятся. Прикольно, что идёт в разные стороны импрувмент RxJava, т.е. они и нацеливаются на быструю обработку каких-то событий, что очень важно для андроида, и в такой же степени они работают над тем, чтобы RxJava хорошо работала в серверной части. Например, уже была добавлена обработка backpressure, а это уже бекэндовая штука. Раньше там был только on-backpressure-buffer и on-backpressure-drop, а теперь они позволяют кастомно обрабатывать все эти backpressure. В современном Андроиде тоже приходится с этим сталкиваться — не только в высоконагруженных системах. Особенно если система построена на реактивщине, много потоков, один очень быстро пишет данные, а другой поток медленно их читает (неторопливый норвежский читатель) и тогда обработчик начинает задыхаться. И это тоже надо обрабатывать, а обычно Андроид-разработчики не очень в курсе того, что такое backpressure, и очень удивляются, когда слышат эти слова. А это важно и нужно знать в процессе Андроид-разработке.
Минусы у RxJava, безусловно, тоже есть. Дело в том, что это совершенно другой подход, если мы говорим об Андроиде. До сих пор в этой ОС больше применяется императивный подход, а RxJava – это больше функциональщина. И очень немного людей умеют правильно «готовить» RxJava. Даже я сам не супер-правильно понимаю все концепции RxJava, потому что это очень глубокая штука. Но в свою защиту могу сказать, что даже на практическом уровне не все понимают этот фреймворк. :)
Также в очевидных минусах нужно отметить то, что происходит очень много копирований объектов. К чему это приводит – понятно. Это дополнительная нагрузка на GC.
— RxJava vs Bolts: принципиальная разница между ними? Какие у тебя личные предпочтения, ну и потенциал каждого из конкретных подходов?
— Я с Bolts практически не работал, так чисто пробовал потыкать. RxJava мне кажется более родной и лаконичной в плане синтаксиса. Она хорошо выглядит и довольно удобная. Но в то же время Bolts более глубок в плане реактивного подхода. Одни только async и await доставляют, которых, кстати, в “нормальной” RxJava нет. Bolts, как мне кажется, более низкоуровневый и близок к фундаментальным вещам.
Потенциал ясен и он огромен. И одна, и другая библиотека нанесли огромный импакт на разработку. RxJava, насколько я вижу, повлиял больше, так как Bolts всё-таки меньше используется. Какой библиотекой пользоваться – выбор каждого, но мне кажется, что RxJava попроще в плане синтаксиса и понимания.
— Как ты оцениваешь современные приложения от топовых разработчиков: 2GIS, Soundcloud, Facebook и какая у них разница в подходе к парадигме?
— Это абсолютно разные приложения, начиная с того, что они про разные вещи. 2GIS про геолокацию и карты, Soundcloud про музыку, а Facebook про социальные вещи. Они интересно подобраны, потому что написаны на абсолютно разных технологиях. 2GIS написан на Qt 5 + QML, Soundcloud — джавовое приложение с использованием реактивщины RxJava, а Facebook сейчас написан на Reactive Native. Как минимум в этом уже есть принципиальная разница. Плюс есть разница в том, как они относятся к своим пользователям.
То есть, например, Facebook не соблюдает все гайдлайны и у фейсбук-мессенджера есть такая вещь, как Pop-Up или Overlay. Когда ты чатишься, у тебя прямо на рабочем столе стоит лицо того, с кем ты переписываешься. И по клику на него открывается приложение, которое перекрывает всё, что сейчас есть на экране. Так делать не очень правильно и меня лично очень раздражает.
Soundcloud старается привнести много стандартного материал-юзер-интерфейса, но тем не менее очень красиво. Все их треки, которые бегут, когда играет музыка, это всё очень круто и сложно в разработке именно фронтэнда.
Ну а 2GIS – это 2GIS. (кстати, знаете, что правильно произносить не “дубльГИС”, а “двагис”? Теперь знаете! :) У них свои запары, у них QML и они вроде как не могут особо использовать стандартные андроидовские виджеты. Суть в том, что они тоже стараются следовать стандартному материал-дизайну, но у них не всегда это получается.
Мне очень нравятся приложения типа Soundcloud или Телеграма, которые очень быстро работают. Я не знаю, как их оценивать. Приложения работают стабильно и хорошо, дизайн может кому-то нравиться, а кому-то — нет. А парадигмы у них всех разные.
— Как ты оцениваешь динамичность развития реактивного программирования и применение в сферах, отличных от мобильной разработки (Elm)?
— Про Elm ничего сказать не могу, потому что никогда не пользовался. Само же реактивное программирование сейчас, как я вижу, набирает обороты. Оно нашло очень хорошую нишу в server-side, много компаний используют его в своих серверах, что позволяет создавать хорошо маштабируемые сервисы, работающие под большими нагрузками. В BigData тоже можно легко увидеть такие вещи как Akka Streams и RxJava. Вот такой «крутой» (нагруженный, распределенный и бла-бла) сервис как Netflix написан на RxJava почти полностью.
Что касается фронтенда, то я за тенденциями веба не очень слежу. Но знаю, что пишут на ClojureScript много и что есть RxJS, который вроде как тоже нашёл свою нишу. Главное, чтобы дальше всё это продвигалось и развивалось, потому что реактивщина много где уже пригождается и будет обидно, если весь подход свалится во что-то нишевое.
— О чём будет твой доклад The Art of Rx на конференции Mobius 2016?
— О чём будет мой доклад The Art of Rx? Доклад планируется такой более философский, о том, куда идёт реактивщина и о том, как на самом деле правильно её готовить. Я рассмотрю некоторые аспекты, связанные с построением архитектуры приложений с использованием этого подхода. Язык не поворачивается совместить слова «архитектура» и «программирование». Как ни странно, эти ошибки очень многие допускают! Как я об этом узнал? Да очень просто! Я их частенько вижу на всяких форумах. А почему? Да потому что люди много чего делают неправильно в самой реактивщине и пошло-поехало: становится очень сложно всё это поддерживать и вся идея реактивного подхода как будто бы рушится. Ну а я в докладе попытаюсь рассмотреть некоторые архитектурные вещи внутри самой RxJava. А именно: как на самом деле работает тот же flatmap, покажу интересные вещи, связанные с Zip, ну и коснусь нескольких внутренних вещей, например, как создаётся Observable из Observable. В общем, интересных штук я заготовил прилично :).
Многие об этом, наверное, просто никогда даже не задумывались и я постараюсь все так преподнести, чтобы было интересно и познавательно. Самое главное – познавательно.
Видео с прошлого Mobius:
Комментарии (0)
Дайджест интересных материалов из мира Drupal #20
Привет!
Если вы ненавидите свою CMS, то на этих майских самое время посмотреть на альтернативы. Мы в свою очередь с любовью отобрали для вас пару десятков полезных ссылок для изучения Drupal. Внутри опрос!
По-русски
- Хватит это терпеть! Большой честный обзор подходов для создания лендингов от соавтора дайджеста k0teg.
- Не менее полезный материал от Никиты Малышева. Отец-основатель dru.io делится своим подходом к верске Drupal-сайтов на основе Display Suite.
- Хабр заинтересовался вопросами лицензирования: FAQ по лицензированию Drupal, FAQ по лицензированию Backdrop.
- Немного старой доброй семёрки: Работа с чистым Token API. Важно понимать, как оно устроено, но на практике бывает удобно сразу интегрироваться с Entity API и его встроенной поддержкой токенов.
- К другим новостям. @xandeadx разжился лиценцией на PhpStorm и сразу же начал писать заметки на эту тему. Мы никогда ничего такого не писали, но поведение автора блога xandeadx.ru нас очень удиаляет и возмущает. Когда уже будут заметки по Drupal 8?! :)
Drupal 6
Drupal 6 больше не поддерживается. Тем не менее, Почему НЕ надо всё бросать и срочно обновляться с шестёрки? Например потому, что кто-то может заработать на поддержке старой версии друпала. Три компании, официально предоставляющие такую услугу, обязались выкладывать все патчи на Drupal.org в специально заведённом для этой цели проекте Drupal 6 Long Term Support. Если у вас есть проекты на шестёрке, стоит подписаться на Issue Queue этого проекта.
Drupal 7
- Ещё одна ода Параграфам, на этот раз с точки зрения эффективности ограничений в интерфейсе.
- Проверь себя: какой библиотеки нет в ядре семёрки? Варианты ответа:jQuery Cookie, jQuery BBQ, jQuery Joyride, Farbtastic. Подсказка.
- Сервис профилирования blackfire.io набирает популярность. Простой пример использования можно найти в блоге EvolvingWeb.
- Показываем диалог подтверждения при нажатии AJAX-кнопки.
- Начинается ещё одна серия статей по Scald. В прошлый раз мы говорили об этом модуле в выпуске #2.
Drupal 8
- Вышел 8.1.0: Composer, Migrate, BigPipe. Немного о релизе простыми словами.
- Опрос: Как дела у Восьмёрки? Вчера Дрис раскрыл результаты своего опроса "If you have *not* used or migrated to Drupal 8, why not?" Мы подготовили такой же опрос для наших широт.
- К тестам добавлена поддержка JS. Первый пример такого теста можно найти в модуле Toolbar.
- Сообщество активно делится рабочими примерами использования Migrate: Drupal to Drupal 8 via Migrate API, Bringing files along for the ride to D8.
- Видео о том, что можно использовать внутри Twig-шаблонов, если у вас включен Devel. А чтобы не сбрасывать весь кеш при минимальных изменениях шаблона, рекомендуется перевести сайт в режим разработки и посмотреть это видео.
- Программное создание термина таксономии. Простой пример от автора @font-your-face.
- Сниппет с примером использовния традиционного Cache API в восьмёрке.
- Состояние Content Staging в Drupal 8: Improving Drupal's content workflow. Тема жирная и важная, так что пишет сам Дрис. Параллельно ведётся разработка схожего решения для семёрки.
- Первая серьёзная сборка — Thunder. Опять же, анонсирует Дрис.
- Специально для околодрупальной конференции Frontend United был разработан модуль c говорящим названием Offline Application. Подробности в статье Taking a (Drupal 8) website offline using AppCache.
Бизнес и сообщество
- Why Paid Drupal Modules Fail: Drupal as Art. Мощно. Длинно. Читать. Комменты. Подкаст.
- Работа кипит на фронте улучшений Drupal.org: Restructuring Drupal.org, A new design system for Drupal.org.
- Новости для HR: Ларри Гарфилд (человек в жилетке) закончил свою карьеру в Palantir.net, а kalabro (соавтор дайджеста) закончила свою карьеру в SystemSeed. Налетай! :)
- Пример продвижения друпалшопа через Drupal.org: The Faichi Story: From Unknown Drupal Shop to Top 10 in 6 Months. Несмотря на явную пропагандистскую направленность статьи, нельзя не согласиться, что фокус на контрибьюции через Drupal.org действительно может помочь в формировании культуры и сплоченности команды, повысить её профессиональный уровень и сформировать позитивный имидж компании на Drupal.org.
Tools & DevOps
- Каждый веб-разработчик должен в своей жизни посадить дерево, написать CMS и сделать свой образ для локальной разработки. В этот раз вариант "All Inclusive" (Nginx + PHP 7 + Xdebug + Drush/Drupal Console + MySQL) от Chi.
- Wunderkraut поделились своей разработкой для деплоймента восьмёрки: Dropcat.
- Много Drupal Console, которая появилась с приходом Symfony и постепенно становится лучшим другом друпалера. Во-первых, красивый cheatsheet: http://ift.tt/1r1Ye2N
- Во-вторых, видео-туториал, как писать модули под восьмёрку с помощью друпал-консоли. Автор видео встал пораньше, чтобы сделать полезное дело для сообщества.
- Интеграция с Drush пока продвигается тяжело.
Модули
- Service Container
После восьмёрки писать на семёрке бывает тяжело. На помощь приходят модули вроде Service Container. Entity Print
Печать в PDF для 7/8. Статья.- Node view count
Замена Statistics, когда надо посчитать просмотры в друпале.
Административный модуль для любителей Spotlight в маке.
Интергация с голосовым интерфейсом от Amazon.
Новый модуль для указания местоположения на основе Google Map API и Client-side hierarchical select.
Модуль позволяет аккуратно раскладывать Twig-шаблоны по папочкам-компонентам вашей темы.
Простенький JS-форматтер текста «Показать ещё».
Поиск по выводу Devel Kint.
На этом на сегодня всё. Над выпуском работали Олег Кот и Катя Маршалкина. Не забудьте проголосовать в опросе и подписаться на нашу рассылку!
P.S. Ого, это уже двадцатый выпуск!
Комментарии (0)
[Перевод] Примеры кода для интернета вещей: умная поливалка
- Как подключиться к Intel Edison – платформе, созданной для прототипирования и разработки носимых вычислительных решений и IoT-устройств.
- Как взаимодействовать с интерфейсом ввода вывода Edison и с датчиками при помощи MRAA и UPM из Intel IoT Developer Kit, самодостаточного аппаратно-программного решения, которое предназначено для того, чтобы помочь разработчикам исследовать возможности интернета вещей и создавать инновационные продукты.
- Как запустить код примера в Intel XDK IoT Edition, IDE для создания приложений, которые взаимодействуют с датчиками и актуаторами. Эта среда разработки позволяет быстро приступить к разработке приложений для Intel Edison и Intel Galileo.
- Как настроить сервер веб-приложения, который будет хранить данные системы полива с использованием Azure Redis Cache в Microsoft Azure. Это набор облачных служб для IoT-решений, которые поддерживают анализ данных, машинное обучение и множество полезных инструментов, упрощающих подключение устройств к облаку и позволяющих быстро вывести IoT-проект в рабочий режим.
- Как вызывать службы Twilio API для отправки текстовых сообщений на мобильные телефоны.
Возможности системы
Вот какими возможностями обладает автоматическая система полива, которую мы создадим на базе Intel Edison:
- Включение и выключение водяного насоса в соответствии с настраиваемым расписанием.
- Проверка того, действительно ли насос перекачивает воду при подаче ему соответствующей команды. Для этого используется датчик расхода воды.
- Организация доступа к системе с использованием встроенного веб-интерфейса, что позволяет задать расписание полива.
- Хранение сведений о работе системы в облачном хранилище.
- Отправка текстовых сообщений для уведомления потребителей о том, что в работе системы произошёл сбой.
Особенности работы
Система полива позволяет задавать расписание полива, открывая с помощью смартфона, или другого подходящего устройства, веб-страницу, которая хранится на Intel Edison. Она автоматически опрашивает датчик влажности и выводит полученные данные на веб-страницу.
Если предполагается, что водяной насос включён, но датчик расхода воды показывает, что вода по трубам не двигается, будет отправлено текстовое сообщение на заданный номер через Twilio. Таким образом, систему полива, которая вышла из строя, можно будет оперативно отремонтировать.
Дополнительно система может вести журнал событий с использованием кода из Intel IoT Examples Datastore, который исполняется в среде Microsoft Azure.
Аппаратное обеспечение
Аппаратная часть проекта – это Grove Environment & Agriculture Kit, включающий в себя:
- Intel Edison с коммутационной платой Arduino.
- Датчик влажности Grove.
- Водяной насос.
- Датчик расхода воды.
- Реле с сухим герконом Grove.
Программное обеспечение
- Intel XDK IoT Edition
- Учётная запись Microsoft Azure
- Учётная запись Twilio
Предварительные приготовления
Для того, чтобы начать работу, скопируйте на компьютер Git репозиторий How-To Intel IoT Code Samples с помощью такой команды:
$ git clone http://ift.tt/1PftnKi
Если вам удобнее загрузить ZIP-архив с необходимыми материалами, откройте эту страницу и щёлкните по расположенной справа кнопке Download ZIP. Загрузив архив, распакуйте его и найдите папку с кодом к этому проекту (watering-system).
Добавление приложения в Intel XDK IoT Edition
В Intel XDK IoT Edition выберите команду Import Your Node.js Project (Импортировать проект Node.js):
Импорт Node.js-проекта
Затем перейдите к папке, в которой расположены файлы учебного проекта и выделите её.
Выбор папки с кодом проекта
Теперь нужно подключить плату Intel Edison к компьютеру и загрузить на плату программу. Для этого можно воспользоваться меню IoT Device (IoT-устройство), которое расположено в левой нижней части окна. Если система автоматически распознала подключённую плату, выберите в меню соответствующую строку.
Подключение Intel Edison
Если же плата не была распознана автоматически, выберите пункт Add Manual Connection (Добавить подключение вручную), в появившемся окне, в поле Address (Адрес), введите 192.168.2.15, в поле Port (Порт) введите 58888. Кнопкой Connect (Подключить) сохраните подключение.
Ручная установка программы на Intel Edison
Кроме того, программу можно установить на Intel Edison вручную. Для этого подключитесь к плате по SSH и выполните следующую команду:
$ git clone http://ift.tt/1PftnKi
Затем перейдите в папку с примером. Если на Edison ещё не установлен Git, сделать это можно, подключившись к плате по SSL и выполнив следующую команду:
$ opkg install git
Подключение датчиков Grove
Прототип системы полива в сборе
Нужно, чтобы к коммутационной Arduino-совместимой плате была подключена плата расширения Groove (Grove Shield), к которой будут подключаться датчики и актуаторы. Проверьте, чтобы на плате расширения Grove маленький переключатель VCC находился в положении 5V.
Необходимо подвести питание к Intel Edison от внешнего адаптера, который поставляется вместе со Starter Kit, или заменить его на подходящий внешний источник питания (12 В, 1.5 А). Можно использовать и USB-батарею на 5 В.
Кроме того, понадобится макетная плата и дополнительный источник питания на 5 В для водяного насоса. Обратите внимание на то, что для насоса нужен отдельный источник питания. Нельзя использовать один и тот же источник и для Intel Edison и для насоса, то есть, понадобится либо две батареи, либо два адаптера.
Для подключения водяного насоса понадобится реле с сухим герконом Groove. Подключение выполняется так:
- Один из концов кабеля Grove подключите к реле, второй – к порту D4 на плате расширения Grove.
- Один из проводов водяного насоса подключите к предназначенному для насоса источнику питания на 5 В.
- Другой провод насоса подключите к одному из разъёмов питания реле.
- Другой разъём питания реле подключите к «земле» источника питания насоса.
- Подключите датчик расхода воды, присоединив красный провод к выводу «5V», чёрный – к выводу «GND», а жёлтый – к цифровому выходу 2 на плате расширения Grove.
- Подключите один конец кабеля Grove к датчику влажности, другой – к порту A0 на плате расширения Grove.
Ручная установка на Intel Edison
Если вы выбрали путь самостоятельного запуска кода примера на Intel Edison, понадобится разрешить некоторые зависимости.
Для получения модулей Node.js, необходимых для того, чтобы пример запустился на Edison, выполните такую команду:
npm install
Настройки: отправка сообщений и облачное хранилище
Для того, чтобы система могла отправлять текстовые сообщения, необходима учётная запись Twilio и API-ключ. Без ключа сообщения отправлять нельзя. Пример будет работать и без отправки сообщений, но в реальных проектах подобная возможность весьма полезна.
Для того чтобы настроить пример на работу с вашей учётной записью Twilio, нужно, в файле config.json, задать значения параметров «TWILIO_ACCT_SID» и «TWILIO_AUTH_TOKEN». В них, соответственно, нужно указать API-ключ и маркер аутентификации.
{
"TWILIO_ACCT_SID": "YOURAPIKEY",
"TWILIO_AUTH_TOKEN": "YOURTOKEN"
}
При желании можете хранить данные, которые генерируются рассматриваемым примером, в базе данных, развёрнутой с использованием Microsoft Azure, Node.js и хранилища данных Redis. Подробности о том, как настроить облачный сервер, смотрите здесь.
Если у вас есть учётная запись Microsoft Azure и имеется сервер, готовый принимать данные, нужно внести изменения в config.json, а именно, записать в параметры «SERVER» и «AUTH_TOKEN» данные для подключения к серверу.
{
"SERVER": "http://ift.tt/1Q99OTP",
"AUTH_TOKEN": "s3cr3t"
}
В том случае, если в вашем варианте примера будет использоваться и отправка текстовых сообщений средствами Twilio, и хранение данных в Microsoft Azure, настройки будут выглядеть так:
{
"TWILIO_ACCT_SID": "YOURAPIKEY",
"TWILIO_AUTH_TOKEN": "YOURTOKEN",
"SERVER": "http://ift.tt/1Q99OTP",
"AUTH_TOKEN": "s3cr3t"
}
Запуск программы из Intel XDK IoT Edition
Прежде чем запускать программу, сохраните изменения, внесённые в файлы. После этого щёлкните по значку Upload (Выгрузка) для того, чтобы выгрузить код на Intel Edison.
Выгрузка проекта на Intel Edison
После выгрузки запустите программу на устройстве с помощью значка Run (Запуск).
Запуск проекта
Если вы, при работе над проектом, внесли в код изменения, можете воспользоваться командой Upload and Run (Выгрузить и запустить). Свежая версия программы будет выгружена и запущена на Intel Edison. В ходе выполнения программы на Edison можно будет видеть сообщения, подобные показанным на рисунке ниже.
Сообщения от программы, которая работает на Intel Edison
Ручной запуск программы
Для того, чтобы запустить программу вручную, подключитесь к Intel Edison по SSH и выполните следующую команду:
node index.js
Настройка расписания полива
Для настройки расписания полива используется веб-интерфейс, состоящий из одной страницы. Эту страницу можно открыть, запросив её у веб-сервера, который выполняется на той же плате Intel Edison, на которой выполняется основная программа.
Страница для настройки расписания полива
Серверу назначен порт 3000. Таким образом, если Intel Edison подключён к Wi-Fi-сети и ему назначен IP-адрес 192.168.1.13, то адрес сервера (при условии, что подключаются к нему из той же самой локальной сети) будет http://ift.tt/1Pftoh3.
Как определить IP-адрес Intel Edison
Для того, чтобы узнать IP-адрес Intel Edison, можно воспользоваться следующей командой:
ip addr show | grep wlan
После её выполнения можно будет увидеть примерно следующее:
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.1.13/24 brd 192.168.1.255 scope global wlan0
Адрес Intel Edison можно обнаружить после «inet». В нашем случае это 192.168.1.13.
Выводы
Мы рассказали о том, как, на базе Intel Edison, собрать систему полива, которая включает в себя набор датчиков и водяной насос. Системой, подключённой к Интернету, можно управлять с любого устройства, которое умеет открывать веб-страницы. Если задействовать в рассмотренном примере облачные службы для хранения данных и отправки сообщений, можно собирать статистику работы устройства, а, в случае возникновения аварийной ситуации, получить текстовое сообщение на заданный номер мобильного телефона и быстро исправить поломку.
С другими примерами кода из серии How-To Intel IoT Code Samples можно ознакомиться на Intel Developer Zone. Полный код рассмотренного здесь примера можно найти на GitHub.
Комментарии (0)
Анализ производительности Windows с использованием возможностей ОС и утилиты PAL
Автор статьи — Михаил Комаров, MVP — Cloud and Datacenter Management
В данной статье будут рассмотрены:
- механизм работы со счетчиками производительности;
- настройка сборщиков данных как с помощью графического интерфейса, так и с помощью командной строки;
- создание черного ящика для записи данных.
Также рассмотрим и обсудим работу с утилитой PAL и ее применение для сбора и анализа данных, включая типовые проблемы локализованных систем.
В общем виде задачу о производительности можно представить в виде трех частей: сбор данных, анализ полученных данных и создание черного ящика для упреждающего мониторинга проблемной системы.
Сбор данных
Начнем со всем давно известного Performance Monitor. Это стандартная утилита, которая входит во все современные редакции Windows. Вызывается либо из меню, либо из командной строки или строки поиска в Windows 8/10 вводом команды perfmon. После запуска утилиты мы видим стандартную панель, в которой можем добавить и удалить счетчики, изменить представление и масштабировать графики с данными.
Также есть сборщики данных, с помощью которых производится сбор данных о производительности системы. При определённых навыках и сноровке операции по добавлению счетчиков и настройке параметров сбора данных можно производить из графического интерфейса. Но когда возникает задача настройки сбора данных с нескольких серверов, разумнее использовать утилиты командой строки. Вот этими утилитами мы и займемся.
Первая утилита — это Typeperf, которая может выводить данные со счетчиков производительности на экран или в файл, а также позволяет получить список счетчиков, установленных в системе. Примеры использования.
Выводит на экран загрузку процессора с интервалом 1 сек.:
typeperf "\Processor(_Total)\% Processor Time"
Выводит в файл названия счётчиков производительности, связанные с объектом PhysicalDisk:
typeperf -qx PhysicalDisk -o counters.txt
В нашем случае мы можем использовать утилиту Typeperf, чтобы создать файл с нужными нам счетчиками, который в дальнейшем будем использовать как шаблон для импорта счетчиков в сборщик данных.
Следующая утилита – Logman. Данная утилита позволяет создавать, изменять и управлять различными сборщиками данных. Мы будем создавать сборщик данных для счетчиков производительности. Вот, например, краткая справка по команде Logman, которая относится к счетчикам производительности и управлению сборщиком данных.
Разберем несколько примеров, которые нам понадобятся в дальнейшем.
Создадим сборщик данных с именем DataCollector_test, импортировав счетчики производительности из файла test.xml:
logman import DataCollector_test -xml C:\PerfTest\test.xml
Создание файла для сбора данных производительности с включённым циркулярным режимом и заданным размером:
logman update DataCollector_test -f bincirc -max 600
Изменение пути файла с данными производительности по умолчанию:
logman update DataCollector_test -o C:\PerfTest\Test_log.blg
Запуск коллектора данных DataCollector_test:
logman start DataCollector_test
Остановка коллектора данных DataCollector_test:
logman stop DataCollector_test
Отметим, что все эти действия можно производить с удаленным компьютером.
Рассмотрим еще одну утилиту — Relog, которая позволяет производить манипуляции с файлом данных после работы сборщика данных. Вот ее описание:
Ниже несколько сценариев применения этой утилиты.
Извлечение данных счетчиков производительности из файла logfile.blg с применением фильтра со списком счетчиков counters.txt и записью результата в бинарный формат:
relog logfile.blg -cf counters.txt -f bin
Извлечение списка счетчиков производительности из logfile.blg в текстовый файл counters.txt:
relog logfile.blg -q -o counters.txt
Напрямую работать с этой утилитой мы не будем, но информация о ней в дальнейшем поможет в случае возникновения проблем в файле PowerShell, который генерирует утилита PAL.
Отметим еще один момент, некоторые системы анализа требуют данные с наименованиями счетчиков производительности на английском языке. Если интерфейс нашей системы на русском языке, то нам необходимо проделать следующие манипуляции: завести локального пользователя, дать ему права на сбор данных (обычно дают права локального администратора), войти в систему под ним и в свойствах системы изменить язык интерфейса.
Обязательно выйти из системы и зайти во второй раз под этим пользователем для инициализации английского интерфейса и выйти из системы. Далее указать в сборщике данных, что сбор данных будет производиться от имени этого пользователя.
После этого имена счетчиков и файлов будут на английском языке.
Также отметим возможность сбора данных для SQL Server с помощью утилиты из состава продукта. Это SQLDIAG, которая обрабатывает журналы производительности Windows, журналы событий Windows, трассировки SQL Server Profiler, сведения о блокировках SQL Server и сведения о конфигурации SQL Server. Указать, какие типы сведений нужно собирать с помощью программы SQLdiag, можно в файле конфигурации SQLDiag.xml.
Для конфигурирования файла SQLDiag.xml можно использовать инструмент PSSDIAG с codeplex.com.
Вот так выглядит окно этого инструмента.
В итоге, процесс сбора данных для SQL может выглядеть так. С помощью PSSDIAG мы формируем xml-файл. Далее посылаем этот файл клиенту, который запускает SQLDIAG c нашим xml-файлом на удаленном сервере и присылает нам для анализа результат работы в виде blg-файла, который мы будем анализировать в следующей части.
Анализ данных с помощью утилиты PAL
Данная утилита написана Clint Huffman, который является PFE-инженером Microsoft и занимается анализом производительности систем. Также он является одним из авторов авторизованного курса Vital Sign, который читается в Microsoft и доступен для корпоративных заказчиков, в том числе в России на русском языке. Утилита распространяется свободно, ссылку на нее я приведу ниже.
Вот так выглядит стартовое окно утилиты.
На вкладке Counter Log задаётся путь к файлу данных со счетчиками производительности, собранными ранее. Также мы можем задать интервал, за который будет производиться анализ.
На вкладке Threshold File находится список шаблонов, которые можно экспортировать в формат xml и использовать как список счетчиков для сборщика данных. Обратите внимание на большой выбор шаблонов для анализа производительности для различных систем. Пример загрузки из командной строки был показан выше. Самое ценное, что в этих заранее подготовленных шаблонах установлены граничные значения для этих параметров, которые будут использованы в дальнейшем для анализа собранных данных!!!
Вот так, например, выглядят граничные значения для счётчиков дисковой производительности:
Мы можем создавать свои шаблоны с использованием нужных счетчиков, которые будут подстроены под нужды нашей организации.
Действуем по следующему алгоритму: на рабочей станции запускаем утилиту PAL, переходим на вкладку Threshold File и экспортируем шаблон в виде xml-файла. На основании этого файла на сервере создаем сборщик данных и запускаем сборку информации.
После сбора данных копируем полученный файл на рабочую станцию, чтобы анализом не нагружать сервер, возвращаемся на вкладку Counter Log, указываем путь к файлу. Снова переходим на Threshold File и выбираем тот самый шаблон, который экспортировали для сборщика данных.
Переключаемся на вкладку Question и указываем объем оперативной памяти на сервере, на котором был осуществлён сбор данных. В случае 32-битной системы заполним UserVa.
Переходим к вкладке Output Options, на которой задаем интервал разбиения для анализа. Значение по умолчанию AUTO делит интервал на 30 равных частей.
Вкладка File Output выглядит довольно обычно, указываем на ней путь к файлам итоговых отчетов в формате HTML или XML.
Вкладка Queue показывает итоговый скрипт на PowerShell. В общем можно сказать, что утилита собирает параметры, которые она подставляет в скрипт PAL.PS1.
Итоговая вкладка задает параметры исполнения. Можно одновременно запустить несколько скриптов и указать число потоков на процессоре. Хотелось бы акцентировать внимание, что обработку blg делает не утилита, а скрипт PowerShell, и это открывает возможности для полной автоматизации анализа логов. Например, каждые сутки перезапускается сборщик данных, в результате освобождается текущий blg-файл и создаётся новый. Старый файл копируется на специальный сервер, где будет запускаться скрипт, обрабатывающий данный файл. После этого готовый HTML- или XML-файл с результатами перемещается в определённую директорию или высылается на почтовый ящик.
Обратите внимание, что утилита должна работать только в английской локализации. Иначе получим сообщение об ошибке.
Также файл с данными должен быть с названиями счетчиков на английском. Выше я указывал, как это сделать. После нажатия Finish запустится скрипт PowerShell, время работы которого зависит от объёма данных и быстродействия рабочей станции.
Итогом работы утилиты будет отчет в выбранном формате, в котором есть графики и числовые данные, позволяющие понять, что происходило в системе за заданный период с учетом граничных значений алертов в шаблоне на вкладке Threshold File. В общем, анализ HTML-файла позволит на начальном этапе определить проблемные места в системе и понять, куда двигаться дальше, как в плане более тонкого мониторинга, так и в плане модернизации или переконфигурирования системы. В блоге Clint Huffman есть скрипт, которым можно конвертировать файл шаблона с граничными условиями в более понятный формат.
Черный ящик
Иногда возникает необходимость в превентивном мониторинге проблемной системы. Для этого мы создадим «черный ящик», в который будем записывать данные производительности. Вернемся к скриптам, описанным ранее.
Создадим сборщик данных c именем BlackBox, импортировав счетчики производительности из файла SystemOverview.xml, который выгрузили из утилиты PAL или создали самостоятельно:
logman import BlackBox -xml C:\ BlackBox\SystemOverview.xml
Создание файла для сбора данных производительности с включённым циркулярным режимом и заданным размером 600 МБ (около 2 суток при стандартном наборе счетчиков):
logman update BlackBox -f bincirc -max 600
Изменение пути файла с данными производительности по умолчанию:
logman update BlackBox -o C:\ BlackBox \ BlackBox _log.blg
Запуск коллектора данных BlackBox:
logman start BlackBox
Данный скрипт создает задачу перезапуска сборщика данных в случае перезапуска системы:
schtasks /create /tn pal /sc onstart /tr "logman start BlackBox " /ru system
На всякий случай поправим свойства диспетчера данных, чтобы не заполнить место на диске, так как после перезапуска сборщика данных создается новый файл с лимитом 600 МБ.
Отметим, что скопировать файл с данными можно только при остановленном сборщике данных. Остановить же последний можно скриптом или с помощью графического интерфейса.
Остановка коллектора данных BlackBox:
logman stop BlackBox
На этом закончим часть, посвященную сбору и первичному анализу производительности.
Ресурсы
Performance Monitor
http://ift.tt/1VXs2uu
Утилита PAL
http://ift.tt/1ujW6PU
Блог Clint Huffman
http://ift.tt/1p0jGA5
Книга Clint Huffman
Windows Performance Analysis Field Guide
http://ift.tt/1T9AxfC
Комментарии (0)