REG.ru потерял домен, даунтайм более суток, тишина от ТП

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

Не сразу было понятно, в чем дело: все работает, мониторинг не тревожит.
Оказалось, что корневой домен более не зарегистрирован. Whois отдают not registered. Пока все живет только за счет кэша DNS.
Домен в зоне .im, на котором висит основной сервис и приложения, зарегистрирован у REG.ru. Был продлен 9 августа (проверил в списке успешных транзакций) и сам reg.ru показывает до сих пор, что все ок:

Что делать?
Честно говоря такого подвоха никак не ожидали.
Упади сервер, база и даже хостер — на все есть свое решение проблемы, пусть даже с простоем в несколько часов. Но тут домен! На него завязаны приложения в маркетах, у клиентов стоят закладки.
И самое страшное, что регистратору это все поровну: для них тикеты равны по приоритету и могут обрабатываться днями (хоть речь о мелкой проблеме с входом в панель, хоть об аварии подобной нашей).

Создали сразу тикет (#2015082810048659), тишина…
Нашел скрытую возможность позвонить в REG.ru: http://ift.tt/1NFROiX
Дозвонился, девушка пообещала, что передала специалистам, тишина…
После обеда звонил еще 2 раза — пытался донести робо-людям, что это авария, что у нас клиенты, и т.д.
Писал по email, даже в группу ВК. Позже в тикете отписались, что специалисты занимаются, меня уведомят о решении проблемы.
Идут вторые сутки. От REG.ru тишина…

Регистрация напрямую
Сегодня утром я сделал простую вещь: нашел собственника домена .im (остров Мэн) — это www.nic.im и провел регистрацию с нуля. Домен удачно зарегистрировался, вышло конечно дороже в 3 раза ( 40 фунтов по курсу). Установил минимальный TTL и через час(!) домен и поддомены заработали, а whois отдавал записи сразу после оплаты домена. Думаю было не тянуть и сделать все вчера, но я ожидал какого-то решения от reg.ru и боялся возможных коллизий.

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

Самое смешное: пока мы разбирались со всем этим — нам непрерывно помогала техподдержка linode, у которых хостятся NS-сервера всех наших доменов, ну и сами продакшен сервера. Они мало чем могли помочь в данном вопросе, но всегда отвечают на любой вопрос в течении 3-х минут и всегда рады помочь (и так более 5 лет). REG.ru, который должен был решать свою проблему с утерей домена клиента — не ответил до сих пор…

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Ко-кластеризация: cегментирование данных вдоль и поперёк

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

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

Иными словами задача состоит в том, чтобы из мозаики данных собрать картинку блочного вида. Математически этот метод можно формализовать с помощью процедуры три-факторизации неотрицательных матриц. Пусть V матрица входных данных размера n x m. Требуется представить ее в виде

Каждая строка матриц R и C содержит ровно одну единицу, остальные элементы — нули. Единичный элемент (i j) матрицы R указывает, что строка i матрицы V принадлежит j-ому горизонтальному кластеру. Единичный элемент (k l) матрицы С указывает, что столбец k матрицы V принадлежит l-ому вертикальному кластеру.

Матрицы R и C выбираются таким образом, чтобы минимизировать функцию потерь: В этом случае D определяется через норму Фробениуса

Эта формализация восходит к работе [2], в которой была предложена ортогональная три-факторизация неотрицательных матриц. Такая постановка задачи позволяет применять итерационные методы нахождения указанного разложения входной матрицы, похожие на методы факторизации неотрицательных матриц.

Но в этой публикации будут рассмотрены примеры блочной кластеризации полученные с помощью метода максимального правдоподобия. Детали алгоритма можно найти в работе [1]. Такой подход, как правило, требует больших вычислительных затрат для нахождения решения. Но есть и преимущества. Во-первых, с помощью такого метода можно автоматически определять оптимальное, с точки зрения алгоритма, число горизонтальных и вертикальных кластеров для категориальных данных [3]. Во-вторых, алгоритм позволяет учитывать тип входных данных — категориальные (в частности, бинарные) или непрерывные (в этом случае не требуется ограничения на то, что входные данные неотрицательны). Для расчетов будет использован пакет blockcluster [4] среды R.

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

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

Пример 1: Freedom in the World (Freedom House 2015 data)
Данные Freedom in the World (FIW) — сравнительная оценка политических прав и гражданских свобод в 195 странах мира на основе опросов экспертов проводимых организацией Freedom House. Данные за 2015 год, агрегированные до 7 под-категорий, доступны здесь.
По результатам этих 7 переменных каждой из 195 стран присваивается два рейтинга — политических прав и гражданских свобод, и итоговый статус страны — свободна, частично свободна и несвободна (всего 3 группы) по результатам этих рейтингов.

Код на R с (4,1) ко-кластеризацей FIW данных

library(data.table)
library(blockcluster)
 
fiw.2015 <- fread("FIW 2015.csv")
fiw.2015.clusters <- cocluster(as.matrix(fiw.2015[,LETTERS[1:7],with=FALSE]), 
                                 datatype = "categorical",model = "pik_rhol_multi", nbcocluster = c(4,1),
                                 strategy = cocluststrategy(nbinititerations=100, nbxem = 20, nbtry = 20 ))

Для объектов класса blockcluster реализована поддержка функции plot( ), но я использую свой вариант отображения решения кластеризации.

Результат кластеризации всех стран, за исключением нескольких случаев, соответствует статусу предложенному Freedom House, с поправкой на то, что 2 верхних кластера в их отчете имеют одинаковый статус — Free. Тем не менее, легко видно, что второй кластер явно отличается от первого, особенно по переменным “F” и “G”. Также этот результат показывает, что в целом каждый кластер “темнее” предшествующего по всем переменным сразу. Результат блочной кластеризации представленный на географической карте в tableau public (ссылка)

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

Пример 2: Democracy module (European social survey 2012 data)
Исследования проекта ESS упоминается во всех моих предыдущих публикациях. Здесь сообщается где можно взять данные и как загрузить их в R. Мы будем группировать целевую аудиторию и переменные по блоку исследования с вопросами о демократии.
Респондентам предлагалось выставить оценки (от 0 до 10) о степени важности для демократии некоторых 16 базовых ценностей и оценить (от 0 до 10) степень применения в стране респондента 14 утверждений о гражданских институтах и правах в настоящее время. Полярные значения:
0 — “совсем не важно” / “полностью не соответствует действительности”;
10 — “крайне важно” / “полностью отвечает действительности”.
Подробная информация о модуле и сами вопросы доступны по этой ссылке.
Это ссылка на pdf файл с анкетой на русском языке для респондентов из Эстонии.

Задаем целевую аудиторию: мужчины возрастом от 15 лет из Франции или России.

Код на R с (5,3) ко-кластеризацей ESS данных

# block.e.names are names of Democracy module variables that were taken from questionnaire. 
data <- subset(srv.data, cntry %in% c("FR", "RU") & gndr =='Male', select = c('cntry', block.e.names[1:30]))
command <- paste("data.m <- data[,as.numeric(c(",
                 paste(block.e.names[1:30], collapse = ","), ")) - 1]")
eval(parse(text=command))
dim(data.m) <- c(length(data.m)/30, 30)
data.clusters <- cocluster(data.m, datatype = "categorical",model = "pik_rhol_multi", nbcocluster = с(5,3),
                           strategy = cocluststrategy(nbinititerations=100, nbxem = 40, nbtry = 40 ))

При выводе результатов на блочную карту заменяем пропущенные значения (NA) на -5, чтобы они сильнее отличались от 0.

Кластеры нумеруем слева направо и сверху вниз.
Сперва о вертикальных кластерах. В первый (светлый) кластер попали первые 15 вопросов об общих (гипотетических) ценностях для демократии. Единственный из 16 вопросов о базовых ценностях для демократии не попавший в первый кластер — вопрос о консолидации (“Важно ли, чтобы перед принятием решений политики учитывали мнения правительств других европейских стран”), он попал во второй кластер. Третий вертикальный кластер темнее второго в первую очередь для первого и третьего горизонтальных кластеров. Этот третий кластер состоит из следующих суждений

Те респонденты, которые подчеркивают важность для демократии базовых гражданских и политических ценностей — 1 и 3 горизонтальные кластеры, критичнее относятся к действительности — 2 и 3 вертикальные кластеры. Третий горизонтальный кластер более пессимистичен по сравнению с первым.
Горизонтальные кластеры 2 и 4 более однотонные по вертикальным составляющим, но четвертый темнее второго, особенно в первой вертикальной составляющей. Респонденты четвертого кластера не считают важным наличие каких-либо ценностей для демократической жизни страны.
В пятом горизонтальном кластере много респондентов, которые не дали ответы на ряд вопросов, большей частью из второго и первого вертикальных кластеров. Левый нижний угол очень контрастен — либо нет ответа на вопрос, либо заявляется высокая степень важности определенной ценности.

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

Литература:
[1] G. Govaert, M. Nadif, Block clustering with Bernoulli mixture models: Comparison of different approaches, Computational Statistics & Data Analysis, Volume 52, Issue 6, 20 February 2008, Pages 3233-3245.
[2] C. Ding et al. Orthogonal nonnegative matrix t-factorizations for clustering //Proceedings of the 12th ACM SIGKDD international conference on Knowledge discovery and data mining. – ACM, 2006. – С. 126-135.
[3] C. Keribin et al. Estimation and selection for the latent block model on categorical data //Statistics and Computing. – 2014. – С. 1-16.
[4] P. S. Bhatia et al. blockcluster: Coclustering package for binary, contingency, continuous and categorical data-sets. R package version 3.0.2

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Node.js и Express как они есть

Здравствуйте, любители нашего хаброблога и прочие читатели!

Мы планируем вновь отметиться на поле неувядающего Node.js и рассматриваем возможность издания этой книги:

Поскольку вполне понятен читательский интерес «а как он впихнул все это в двести страниц, и зачем мне это нужно»? под катом предлагаем перевод доскональной статьи Томислава Капана о том, зачем на самом деле нужен Node.js.

Введение

Благодаря растущей популярности, язык JavaScript в наше время активно развивается, и современная веб-разработка драматически изменилась по сравнению с недавним прошлым. Те вещи, которые мы сегодня можем делать в Вебе при помощи JavaScript, работающего на сервере, а также в браузере, было сложно себе вообразить еще несколько лет назад – в лучшем случае, такие возможности существовали только в песочницах вроде Flash или Java Applets.
Прежде чем подробно поговорить о Node.js, можете почитать о преимуществах полностекового использования JavaScript. При этом тесно переплетаются сам язык и формат данных (JSON), что позволяет оптимально переиспользовать ресурсы разработки. Поскольку это достоинство присуще не столько Node.js, сколько JavaScript в целом, мы не будем подробно останавливаться на этой теме. Но в этом и заключается ключевое преимущество, которое вы приобретаете, внедряя Node в свой стек.

В Википедии читаем: “Node.js – это пакет, включающий движок JavaScript V8 от Google, уровень абстракции платформы – библиотеку libuv, а также базовую библиотеку, которая сама написана на JavaScript.” Кроме того, необходимо отметить, что Райан Даль, автор Node.js, стремился создавать сайты, работающие в реальном времени и оснащенные push-функцией, под впечатлением от таких приложений как Gmail”. В Node.js он предоставил программистам инструмент для работы с парадигмой неблокирующего, событийно-ориентированного ввода/вывода.

Спустя 20 лет господства парадигмы «веб-приложения без сохранения состояния на базе коммуникации запрос-отклик без сохранения состояния» у нас наконец-то есть приложения с двунаправленной связью в реальном времени.
Короче: Node.js блистает в приложениях реального времени, так как задействует push-технологию через веб-сокеты. Что же в этом такого революционного? Ну, как уже говорилось, спустя 20 лет использования вышеупомянутой парадигмы появились такие двунаправленные приложения, где связь может инициировать как клиент, так и сервер, а затем приступать к свободному обмену данными. Такая технология резко контрастирует с типичной парадигмой веб-откликов, где коммуникацию всегда инициирует клиент. Кроме того, вся технология основана на открытом веб-стеке (HTML, CSS и JS), работа идет через стандартный порт 80.

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

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

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

Пространно.

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

Тонкости работы Node.js «под капотом» довольно интересны. По сравнению с традиционными вариантами веб-сервисов, где каждое соединение (запрос) порождает новый поток, нагружая оперативную память системы и, в конце концов, разбирая эту память без остатка, Node.js гораздо экономичнее: он работает в единственном потоке, при вызовах использует неблокирующий ввод/вывод, позволяет поддерживать десятки тысяч конкурентных соединений (которые существуют в цикле событий).

Простой расчет: допустим, каждый поток потенциально может затребовать 2 Мб памяти и работает в системе с 8 Гб оперативной памяти. В таком случае мы теоретически можем рассчитывать максимум на 4000 конкурентных соединений плюс издержки на переключение контекста между потоками. Именно с таким сценарием приходится иметь дело при использовании традиционных веб-сервисов. Node.js, избегая всего этого, может масштабироваться более чем до миллиона конкурентных соединений (в качестве эксперимента для подтверждения концепции).

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

Чтобы избежать всплывания исключений до самой поверхности применяется следующий прием: ошибки передаются обратно вызывающей стороне как параметры обратного вызова (а не выбрасываются, как в других средах). На случай, если какое-то необработанное исключение проскочит и всплывет, существует множество парадигм и инструментов, позволяющих следить за процессом Node и выполнять необходимое восстановление аварийно завершившегося экземпляра (хотя, пользовательские сеансы при этом восстановить не удастся). Наиболее распространенными из них являются модуль Forever, либо работа с применением внешних системных инструментов upstart и monit.

NPM: Менеджер пакетов Node

Обсуждая Node.js, просто необходимо упомянуть существующую в нем встроенную поддержку управления пакетами, для которой применяется инструмент NPM, по умолчанию присутствующий в любой установке Node.js. Идея модулей NPM во многом схожа с Ruby Gems: это набор общедоступных компонентов для многократного использования, которые легко установить через онлайновый репозиторий; для них поддерживается управление версиями и зависимостями.

Полный список упакованных модулей находится на сайте NPM npmjs.org, а также доступен при помощи инструмента NPM CLI, который автоматически устанавливается вместе с Node.js. Экосистема модулей совершенно открыта, любой может опубликовать в ней собственный модуль, который появится в списке репозитория NPM. Краткое введение в NPM (немного староватое, но по-прежнему актуальное) находится на сайте http://ift.tt/rUg2ZF.
Некоторые из наиболее популярных современных NPM-модулей:

• express: Express.js, фреймворк для веб-разработки для Node.js, написанный в духе Sinatra, де-факто – стандартный для большинства существующих сегодня приложений Node.js.
• connect: Connect – это расширяемый фреймворк, работающий с Node.js в качестве HTTP-сервера, предоставляющий коллекцию высокопроизводительных «плагинов», известных под общим названием «связующее ПО» (middleware); служит основой для Express.
• socket.io и sockjs – серверная часть двух наиболее распространенных сегодня веб-сокетных компонентов.
• Jade – один из популярных шаблонизаторов, написанный в духе HAML, по умолчанию используется в Express.js.
• mongo и mongojs – обертки MongoDB, предоставляющие API для объектных баз данных MongoDB в Node.js.
• redis — клиентская библиотека Redis.
• coffee-script – компилятор CoffeeScript, позволяющий разработчикам писать программы с Node.js при помощи Coffee.
• underscore (lodash, lazy) – Самая популярная вспомогательная библиотека JavaScript, упакованная для использования с Node.js, а также две аналогичные ей библиотеки, обеспечивающие повышенную производительность, поскольку реализованы немного иначе.
• forever – Вероятно, самая распространенная утилита, обеспечивающая бесперебойное выполнение сценария на заданном узле. Поддерживает работоспособность вашего процесса Node.js при любых неожиданных сбоях.

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

В каких случаях следует использовать Node.js

ЧАТ

Чат — это наиболее типичное многопользовательское приложение, работающее в реальном времени. От IRC (были времена), использующих разнообразные открытые и открытые протоколы, функционирующие через нестандартные порты, мы пришли к современности, когда все можно реализовать на Node.js с применением веб-сокетов, действующих через стандартный порт 80.

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

Попробуем изобразить, как оно работает.

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

На стороне сервера у нас простое приложение Express.js, в котором реализуются две вещи: 1) обработчик запросов GET ‘/’, обслуживающий веб-страницу, на которой располагается как форум с сообщениями, так и кнопка ‘Send’, инициализирующая новое введенное сообщение и 2) сервер веб-сокетов, слушающий новые сообщения, выдаваемые клиентами веб-сокетов.

На стороне клиента у нас есть HTML-страница, на которой настроено два обработчика: один из них слушает события щелчка по кнопке ‘Send’, которая подхватывает введенное сообщение и спускает его на веб-сокет, а другой слушает новые входящие сообщения на клиенте для обслуживания веб-сокетов (т.е., сообщения, отправленные другими клиентами, которые сервер собирается отобразить при помощи этого специального клиента).

Вот что происходит, когда один из клиентов отправляет сообщение:

1. 1. Браузер подхватывает щелчок по кнопке ‘Send’ при помощи JavaScript-обработчика, забирает значение из поля ввода (т.e., текст сообщения) и выдает сообщение веб-сокета, воспользовавшись клиентом веб-сокетов, подключенным к нашему серверу (этот клиент инициализируется вместе с веб-страницей).
2. 2. Серверный компонент веб-сокетного соединения получает сообщение и перенаправляет его всем остальным подключенным клиентам широковещательным методом.
3. 3. Все клиенты получают новое сообщение по принципу push при помощи веб-сокетного компонента, выполняющегося на веб-странице. Затем они подхватывают контент сообщения и обновляют веб-страницу, добавляя на форум новую запись.

Это простейший пример. Для более надежного решения можно использовать простой кэш, основанный на хранилище Redis. Еще более продвинутое решение — очередь сообщений, позволяющая обрабатывать маршрутизацию сообщений к клиентам и обеспечивающая более надежный механизм доставки, который позволяет компенсировать временные обрывы соединения или хранить сообщения для зарегистрированных клиентов, пока они находятся в оффлайне. Но независимо от того, какие оптимизации вы выполняете, Node.js все равно будет действовать в соответствии с теми же базовыми принципами: реагировать на события, обрабатывать множество конкурентных соединений, поддерживать плавность пользовательских взаимодействий.

API ПОВЕРХ ОБЪЕКТНОЙ БАЗЫ ДАННЫХ

Хотя Node.js особенно хорош в контексте приложений, работающих в реальном времени, он вполне подходит и для предоставления информации из объектных баз данных (напр. MongoDB). Данные, сохраненные в формате JSON, позволяют Node.js функционировать без потери соответствия и без преобразования данных.

Например, если вы используете Rails, то вам пришлось бы преобразовывать JSON в двоичные модели, а потом снова предоставлять их в виде JSON по HTTP, когда данные будут потребляться Backbone.js, Angular.js или даже обычными вызовами jQuery AJAX. Работая с Node.js, можно просто предоставлять ваши объекты JSON клиенту через REST API, чтобы клиент их потреблял. Кроме того, не приходится беспокоиться о преобразовании между JSON и чем угодно еще при считывании базы данных и записи в нее (если вы используете MongoDB). Итак, вы обходитесь без множества преобразований, используя универсальный формат сериализации данных, применяемый и на клиенте, и на сервере, и в базе данных.

ОЧЕРЕДИ ВВОДА

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

При использовании такого подхода отзывчивость системы сохраняется и под высокой нагрузкой, что особенно полезно, если клиенту не требуется подтверждение о том, что запись данных прошла успешно. Типичные примеры: логирование или запись данных о пользовательской активности (user tracking), обрабатываемых по пакетному принципу и не используемых впоследствии; операции, итог которых должен отражаться мгновенно (например, обновление количества «лайков» в Facebook), где приемлема согласованность в конечном счете, так часто используемая в мире NoSQL.

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

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

ПОТОКОВАЯ ПЕРЕДАЧА ДАННЫХ

На более традиционных веб-платформах HTTP-запросы и отклики трактуются как изолированные события; но фактически они представляют собой потоки. Этим моментом можно воспользоваться в Node.js для создания некоторых классных возможностей. Например, можно обрабатывать файлы, пока они еще закачиваются, поскольку данные поступают потоком, и мы можем работать с ними в онлайновом режиме. Это можно сделать, например, при кодировании видео или аудио в реальном времени, а также при установке прокси между различными источниками данных (подробнее см. в следующем разделе).

ПРОКСИ

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

Хотя и существуют выделенные прокси-серверы, вместо них удобно использовать Node, особенно если прокси-инфраструктуры не существует, либо если вам нужно решение для локальной разработки. Здесь я имею в виду, что можно создать клиентское приложение, где будет применяться сервер разработки Node.js, где мы будем хранить ресурсы и делать прокси/заглушки для запросов к API, а в реальных условиях такие взаимодействия уже будут выполняться при помощи выделенного прокси-сервиса (nginx, HAProxy, т.д.)

ИНФОРМАЦИОННАЯ ПАНЕЛЬ БИРЖЕВОГО ТРЕЙДЕРА

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

ПАНЕЛЬ ДЛЯ МОНИТОРИНГА ПРИЛОЖЕНИЙ

Это еще один практический случай, для которого идеально подходит модель «Node+веб-сокеты». Здесь мы отслеживаем посетителей сайта и визуализируем их взаимодействия в реальном времени (если вас интересует такая идея, то она уже решается при помощи Hummingbird).

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

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

ИНФОРМАЦИОННАЯ ПАНЕЛЬ ДЛЯ ОТСЛЕЖИВАНИЯ СИСТЕМЫ

Теперь давайте поговорим об инфраструктурных аспектах. Допустим, есть SaaS-провайдер, желающий предложить пользователям страницу для отслеживания сервисов (скажем, статусную страницу GitHub). Имея цикл событий Node.js, можно создать мощный веб-интерфейс, где состояния сервисов будут асинхронно проверяться в реальном времени, а данные будут отправляться клиенту через веб-сокеты.

Такая технология позволяет сообщать о статусах как внутренних (внутрикорпоративных), так и общедоступных сервисов в реальном времени. Давайте немного разовьем эту идею и попытаемся представить сетевой операционный центр (NOC), отслеживающий работу приложений оператора связи, провайдера облачных сервисов/хостинг-провайдера или какой-нибудь финансовой организации. Все это работает в открытом веб-стеке на основе Node.js и веб-сокетов, а не Java и/или Java-апплетов.

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

Где можно использовать Node.js

СЕРВЕРНЫЕ ВЕБ-ПРИЛОЖЕНИЯ

Node.js c Express.js также можно применять для создания классических веб-приложений на серверной стороне. Однако, пусть это и возможно, такая парадигма запрос/отклик, где Node.js будет переносить отображенный HTML, нетипична для данной технологии. Существуют аргументы как в пользу такого подхода, так и против него. Необходимо учитывать следующее:

За:

• Если ваше приложение не выполняет интенсивных вычислений, нагружающих процессор, то его можно написать полностью на JavaScript, включая даже базу данных, если вы используете объектную базу данных (например, MongoDB) и JSON. Это значительно упрощает не только разработку, но и подбор специалистов.
• Поисковые роботы получают в ответ полностью отображенный HTML, что гораздо удобнее для поисковой оптимизации, чем, например, работа с одностраничными приложениями или веб-сокетным приложением, работающим на базе Node.js.
• Любые интенсивные вычисления, нагружающие процессор, будут блокировать динамичность Node.js, поэтому в таком случае лучше использовать многопоточную платформу. Также можно попробовать горизонтальное масштабирование вычислений [*].
• Использовать Node.js с реляционной базой данных по-прежнему довольно неудобно (подробнее см. ниже). Сделайте себе одолжение и выберите какую-нибудь другую среду, например, Rails, Django или ASP.Net MVC, если собираетесь заниматься реляционными операциями.

[*] В качестве альтернативы таким CPU-интенсивным вычислениям можно создать хорошо масштабируемую MQ-среду с обработкой на интерфейсе базы данных, чтобы Node оставался «на передовой» и асинхронно обрабатывал клиентские запросы.

В каких случаях не следует использовать Node.js

СЕРВЕРНОЕ ВЕБ-ПРИЛОЖЕНИЕ, ЗА КОТОРЫМ РАСПОЛОЖЕНА РЕЛЯЦИОННАЯ БАЗА ДАННЫХ

Сравнивая Node.js плюс Express.js с Ruby on Rails, мы уверенно выбираем второй вариант, если речь идет о доступе к реляционным данным.

Инструменты реляционных баз данных для Node.js по-прежнему находятся в зачаточном состоянии, работать с ними довольно неприятно. С другой стороны, Rails автомагически настраивает доступ к данным прямо при установке, плюс предоставляет инструменты для поддержки миграций схем баз данных и прочие Gems. Rails и соответствующие фреймворки обладают зрелыми и проверенными реализациями доступа к уровню данных (Active Record или Data Mapper), которых вам будет остро недоставать, если вы попытаетесь воспроизвести такую конструкцию на чистом JavaScript.[*]

Все-таки, если вы твердо намерены все делать на JavaScript, обратите внимание на Sequelize и Node ORM2— оба инструмента пока не лишены шероховатостей, но со временем могут и дозреть.

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

СЛОЖНЫЕ СЕРВЕРНЫЕ ВЫЧИСЛЕНИЯ И ОБРАБОТКА

Когда речь заходит о сложных вычислениях, Node.js оставляет желать лучшего. Разумеется, вы не собираетесь программировать на Node сервер для вычислений Фибоначчи. В принципе, любые вычислительные операции, сильно нагружающие процессор, девальвируют выигрыш в пропускной способности, который в Node достигается благодаря событийно-ориентированному неблокирующему вводу/выводу. Дело в том, что любые входящие запросы будут блокироваться, пока единственный поток занят перевариванием чисел.

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

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

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

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

Заключение

Мы обсудили Node.js с теоретической и практической точки зрения, начав с его целей и назначения и закончив разговором о всяческих вкусностях и подводных камнях. Если у вас возникнут проблемы с Node.js, то помните, что почти всегда они сводятся к следующему факту: блокирующие операции — причина всех бед. В 99% процентах случаев все проблемы начинаются из-за неправильного использования Node.

Помните: Node.js никогда не предназначался для решения проблемы масштабирования вычислений. Он создавался для масштабирования ввода/вывода, с чем действительно справляется очень хорошо.

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

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Из песочницы] AMI. Разносторонний Originate. Применение в CTI приложении

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

Пример настройки AMI и подключения по telnet

Настроим учетную запись в файле /etc/asterisk/manager.conf:

[general]
enabled = yes
port = 5038
bindaddr = 0.0.0.0

[1cami] ;
secret=PASSWORD1cami
deny=0.0.0.0/0.0.0.0
permit=0.0.0.0/0.0.0.0
; Достаточно ограниченного набора прав. 
read=call
write=originate

Далее необходимо в CLI консоли Asterisk выполнить команду:

module reload manager

Для подключения будем использовать средства telnet:

~ # telnet 127.0.0.1 5038
Asterisk Call Manager/1.2

Как только появится приглашение “Asterisk Call Manager”, можно вводить команды. Первой командой должна быть авторизация.

Action: Login
Username: 1cami
Secret: PASSWORD1cami

Завершением ввода команды служит пустая строка. В случае успеха, получаем ответ:

Response: Success
Message: Authentication accepted

Базовый пример Originate

Описание параметров команды AMI

• Channel — Имя канала. Формат type/identifier. Type — тип канала, в зависимости от используемого драйвера SIP / IAX2 / DAHDI
• Context — Имя контекста для совершения вызова. Следует использовать совместно с параметрами Exten и Priority
• Exten — номер телефона, определенный в контексте «Context»
• Priority — Приоритет, позиция в Context, с которой начнеться обработка вызова
• Timeout — Таймаут в милисекундах. Если инициатор исходящего звонка не ответил, вызов будет завершен
• CallerID — значение callerid для исходящего звонка. Формат «ИмяСотрудника <НомерТелефона>»
• Variable — установка переменных для порожденных Originate каналов
• Account — Значение поля accauntcode для исходящих вызовов
• Application — команда dialplan, которая будет выолнена, используется совместно с параметром «Data»
• Async — признак асинхронного выполнения команды. Если установлен в значение «1», результат будет возвращен в пакете типа «Event» с именем «OriginateResponse»Data — Параметры команды dialplan
• ActionID — идентификатор запроса, полезно использовать при несколькоих одновренменных асинхронных запросах. Позволяет сопоставить результат с исходных запросом

Коды ответа «Event» с именем «OriginateResponse»

• 0 = Номер не найден в Context
• 1 = Нет ответа (no answer)
• 4 = Успешное выполнение (answered)
• 8 = Перегрузка или абонент не доступен (congested or not available)

Рассмотрим инициацию вызова с SIP канала 104 на номер 74952293042 в контексте from-internal:

Action: Originate
Channel: SIP/104
Context: from-internal
Exten: 74952293042
Priority: 1
Callerid: 104
Variable: SIPADDHEADER="Call-Info:\;answer-after=0"

В результате этой команды, зазвонит внутренний телефон, связанный с каналом SIP/104. После поднятия трубки, вызов пойдет на номер 74952293042 в контекст from-internal, приоритет 1.

В некоторых случаях удобно совмещать исходящий вызов с intercom, для этого следует задействовать параметр Variable.
Для Cisco, Linksys, Yealink и некоторых программных телефонов, подойдет установка переменной “SIPADDHEADER” в значение: "Call-Info:\;answer-after=0"

Допустим, на рабочем месте используется телефон Linksys. В результате Originate, сработает автоматический ответ на вызов, на телефоне, связанном с каналом SIP/104.

Перехват вызова

Все слышали о функции перехвата вызова, поступившего на соседний телефонный аппарат.
Обычно функция реализуется “старкодом” *8.

Для реализации перехвата, в dialplan можно задействовать приложение PickUp или PickupChan, сети довольно много примеров использования.

Как организовать эту функцию средствами AMI?

Для захвата вызова можно воспользоваться командой Originate. У нее есть два интересных параметра:

• Application — приложение, которое должно быть запущено
• Data — данные приложения

Опишем пример перехвата вызова, поступившего на sip аккаунт 104:

Action: Originate
Channel: SIP/104
Application: PickupChan
Data: SIP/104-0000003c
Priority: 1
Callerid: 104
Variable: SIPADDHEADER="Call-Info:\;answer-after=0"

Особенность этого Originate — нет необходимости описывать параметр «context».

Но появляется потребоность отслеживать каналы, которые мы можем перехватить. В данном примере канал описан как «SIP/104-0000003b».

Отслеживать появление новых каналов возможно в event "Newstate", где "ChannelState" установлено в значение «5» (Ringing). Ниже пример event:

Event: Newstate
Privilege: call,all
Channel: SIP/104-0000003c
ChannelState: 5
ChannelStateDesc: Ringing
CallerIDNum: 104
CallerIDName: Default Extension
ConnectedLineNum: 104
ConnectedLineName: 
Uniqueid: askozia-1438348824.146

Как только поступит event "Newstate", где "ChannelState" установлено в значение «6» (Up) — на вызов уже ответили:

Event: Newstate
Privilege: call,all
Channel: SIP/104-0000003c
ChannelState: 6
ChannelStateDesc: Up
CallerIDNum: 104
CallerIDName: Default Extension
ConnectedLineNum: 104
ConnectedLineName: 
Uniqueid: askozia-1438348824.146

Внимательный читатель заметит в примере некоторую несуразицу:

Action: Originate
Channel: SIP/104
Application: PickupChan
Data: SIP/104-0000003b

Ошибки нет. Вызов выполняем с Channel SIP/104, PickupChan выполняем для канала SIP/104-0000003b. То есть для своего же канала.

Прокомментирую на примере

Эту функцию мы запустили в повседневное использование. На моем рабочем месте установлен IP телефон. К телефону подключена гарнитура.

1. Мне поступает входящий вызов;
2. Жму кнопку «Ответить на вызов» в нашем CTI приложении;
3. Выполняется описанный выше пример originate;
4. Благодаря установленному «SIPADDHEADER» происходит автоответ;
5. Телефон выполняет исходящий звонок и «пикапит» вызов.

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

Прослушать запись разговора

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

Пример AMI:

Action: Originate
Channel: SIP/104
Application: Playback
Data: /storage/usbdisk1/test_file
Priority: 1
Callerid: Playback
Variable: SIPADDHEADER="Call-Info:\;answer-after=0"

Используется приложение "Playback", в качестве данных передаем полное имя файла без расширения "/storage/usbdisk1/test_file".

Подслушать разговор

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

Action: Originate
Channel: SIP/104
Application: ChanSpy
Data: SIP/105,qx
Priority: 1
Callerid: Spy-105 <105>
Variable: SIPADDHEADER="Call-Info:\;answer-after=0"

• q — “тихий режим”, присоединение к разговору не анонсируется в разговор.

Присоединиться к разговору

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

Action: Originate
Channel: SIP/104
Application: ChanSpy
Data: SIP/105,qBx
Priority: 1
Callerid: Spy-105 <105>
Variable: SIPADDHEADER="Call-Info:\;answer-after=0"

• B — оба канала могут слышать присоединившегося абонента

Режим суфлера

Куратор может присоединиться к разговору и подсказывать стажеру:

Action: Originate
Channel: SIP/104
Application: ChanSpy
Data: SIP/105,wx
Priority: 1
Callerid: Spy-105 <105>
Variable: SIPADDHEADER="Call-Info:\;answer-after=0"

• w — режим шепота, присоединившегося абонента будет слышать только канал, за которым «шпионим»

Заключение

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

При разработке я рекомендую обратить внимание на проекты PAMI, NAMI и Shift8.

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Визуализация кристаллических 3d-структур в браузере без плагинов

Привет, Хабр! В этой статье я сравню четыре открытых движка визуализации кристаллических структур в формате CIF (Crystallographic Information File), популярном в кристаллохимии и материаловедении. Речь пойдёт о современном JavaScript (включая транскомпиляцию Java и C в JavaScript), о кристаллохимии и физике твёрдого тела. Мы телепортируемся из мира Шрёдингера и Ландау в мир Бернерса-Ли и Джобса, а затем обратно. Итак, поехали.

Из школьного курса физики известно, что атомы в твёрдом теле упорядочены в периодически повторяющиеся структурные единицы размером порядка нанометра, образующие кристаллическую решётку. Физика твёрдого тела в духе редукционизма изучает связь между свойствами этих структурных единиц (элементарных ячеек) и свойствами объектов макромира. Например, контролируя адсорбцию молекул воды на поверхности оксидов переходных металлов, можно удешевить синтез водорода и кислорода, улучшить производительность топливных ячеек и сенсорных приборов, оптимизировать доставку лекарств в фармакологии. Короче говоря, физика твёрдого тела так или иначе описывает любой лабораторный или технологический процесс, и здесь значение молекулярной визуализации переоценить крайне сложно. Де-факто в материаловедении самым распространённым компьютерным форматом для обмена данными о кристаллических структурах является CIF. Важным отличием CIF от других химических форматов является поддержка 3d-трансляций, иными словами, для задания бесконечного 3d-кристалла мы повторяем в трёх направлениях его элементарную ячейку.

CIF создан в 90-х в международным союзом кристаллографии (IUCR). Основу CIF составляет текстовый контейнер под названием STAR (Self-Defining Text Archive and Retrieval), где физические свойства, полученные в результате дифрактометрии или теоретических расчётов, маркируются стандартными тэгами. Стандартные тэги определяют параметры кристаллической ячейки, её симметрию, входящие в её состав атомы, метаданные соответствующей научной публикации и прочее. Эти тэги задаются во внешних CIF-словарях, подобных XSD-схемам XML-документов, так что возможна валидация CIF-документа по CIF-словарю и даже вывод новых физических свойств на основе доступных. Отличия в том, что CIF разрешает произвольные тэги, которые игнорируются CIF-парсером (разумеется, позже они могут стать частью стандарта и быть включены в новые словари по решению союза IUCR). Кроме того, CIF поддерживает реляционную модель данных, когда, например, можно ссылаться на определённые атомы в кристаллической структуре по их идентификаторам. Недостаток в отсутствии удобной поддержки многоуровневых иерархий, здесь STAR-контейнер проигрывает XML. Кстати говоря, именно поэтому у CIF существует XML конкурент под названием CML (Chemical Markup Language).

Традиционно CIF-файлы открываются в десктопных приложениях (Vesta, Accelrys/BIOVIA, RasMol и многие другие), однако и в этой области около четырёх лет назад браузеры начали свой крестовый поход против десктопных приложений. Известные мне open source плоды этого похода собраны ниже, а их код в виде единого веб-приложения можно найти в репозитории. Код тестировался в нескольких популярных браузерах, включая IE 11 и мобильный Safari. Структура репозитория следующая: папка data содержит примеры CIF-моделей (если вы когда-либо имели дело с кристаллохимией или материаловедением, у вас наверняка найдутся свои), папка engines содержит JavaScript код всех движков, utils содержит вспомогательный код, например, браузерный загрузчик файлов для локальной обработки CIF-моделей. Таким образом, для запуска веб-приложения достаточно открыть его папку для веб-сервера и зайти в браузере на соответствующий адрес (или просто перейти в репозиторий). Все файлы статические, никакой серверной обработки не предусмотрено.

Коротко о четырёх моделях из папки data:

• adsorption.cif — модель вышеупомянутой адсорбции воды на перовските, элементарная ячейка, по умолчанию загружается в каждый из движков,
• fullerene.cif — фуллерен C₆₀,
• lfp.cif — фосфат лития-железа LiFePO₄, материал катода литий-ионной батареи. Обратите внимание на ион лития: он очень лёгкий и подвижный (а всё потому, что литий третий в таблице Менделеева). Третий электрон лития приходит или уходит во внешнюю цепь в результате разрядки или зарядки батареи, в то время как ион лития путешествует сквозь электролит.
• mdma.cif — гидрохлорид 3,4-метилендиокси-N-метамфетамина. Его функциональные группы могут быть заменены с сохранением соответствующего эффекта, при этом образуется новое и поэтому легальное вещество. Именно в этом и состоит проблема синтетических аналогов.

Теперь, собственно, результаты сравнения движков.

Движок	Версия	Общий объём кода (в скобках GZip)	Технология отрисовки	Кастомизация	Лицензия
JSmol	14.2.15	2,1 MB (700 KB)	canvas	богатая, программно и в UI	LGPL
ChemDoodle Web Components	7.0.1	354 KB (121 KB)	WebGL	богатая, программно	GPL v3
RasmolJS	–	1,1 MB (462 KB)	canvas, SDL, asm.js	богатая, программно	GPL
Player.html	0.10	265 KB (83 KB)	canvas, Three.js	ограниченная, в UI	MIT

Решения на основе Java-апплетов, Flash- и прочих плагинов не рассматривал как тупиковую ветвь эволюции, только чистый (как принято выражаться, «ванильный») JavaScript. Впрочем, чистый JavaScript возможно синтезировать из множества других языков, первое и третье решение как раз и есть такие случаи.

JSmol получен из Java-кода Jmol с помощью инструмента Java2Script. Общий объём кода JSmol составляет 12,7 MB, части из которого загружаются по мере необходимости. В таблице выше приведён объём, требуемый для старта. Функционально этот движок полностью повторяет своего более известного Java-собрата, предоставляя самый богатый набор возможностей. Сравнение можно было бы здесь окончить, если бы не гигантский размер (и самый медленный старт) и издержки портирования инородного стека, в частности, уродливый и нечитаемый JavaScript.

ChemDoodle Web Components основан на проприетарном продукте. Это имеет достоинства (прекрасная документация, высокое качество как кода, так и продукта в целом) и недостатки (ограничения на использование, неотключаемая отправка сведений о пользователях). К недостаткам также можно отнести отсутствие поддержки canvas в пользу WebGL, а значит, неработоспособность на чуть устаревшем оборудовании. Если недостатки не представляют проблемы, этот движок можно назвать победителем.

RasmolJS получен из своего старшего C-собрата RasMol с помощью Emscripten. Британский хемоинформатик Ноэл О'Бойль портировал оригинальный графический функционал на библиотеку SDL, поддерживаемую Emscripten, в результате транскомпилированный JavaScript код осуществляет 3d-отрисовку в элементе canvas. Кроме того, код сгенерирован по стандарту asm.js, что в теории должно обеспечивать прирост производительности. На практике получился всё же довольно тяжеловесный и медлительный движок, к тому же лишённый ряда функций предыдущих участников.

Player.html написан мной с использованием Three.js и Math.js. Упор сделан на минимализм и быстроту, а также поддержку как можно более широкого ряда оборудования, так что движок работает даже на древних лэптопах. Разработка начата относительно недавно, поэтому функционал ещё очень беден. Любую критику ценю и жажду.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Советы начинающим разработчикам сетевых приложений

В данной статье будет дана серия рекомендаций начинающим сетевым разработчикам. Возможно она поможет вам не наступать на некоторые грабли а так же предложит менее очевидные но более правильные способы решения ваших задач. Отчасти статья может является холиварной и противоречить вашему опыту. В этом случае — добро пожаловать в комментарии.
Совет 1
По возможности — используйте TCP. В противном случае вам придется самому заботится о целостности ваших данных, а это не так просто, как кажется на первый взляд. Основное узкое место TCP, в которое вы упрётесь начав его использовать в realtime задачах — задержка перед отправкой данных. Но это поправимо — нужно лишь установить сокету флаг TCP_NODELAY:

int flag = 1;
int result = setsockopt(sock, IPPROTO_TCP,  TCP_NODELAY, (char *) &flag, sizeof(int));
if (result < 0)
    ... handle the error ...

Для некоторых задач использовать TCP невозможно. К примеру, при реализации техники обхода NAT. В этом случае можно воспользовать готовой библиотекой, обеспечивающей гарантированную доставку поверх UDP, к примеру UDT library. Для других задач (например, передача мультимедиа) иногда так же есть смысл использовать UDP — многие кодеки поддерживают потерю пакетов. Но тут стоит быть аккуратным — возможно лучшим решением будет всё же не терять данные, а вместо этого обеспечить ускоренное воспроизведение фрагмента, полученного с задержкой.

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

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

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

• нет необходимости использовать примитивы синхронизации
• на каждое соединение тратится минимально необходимые ресурсы (в отличие от потоков, для которых вам как минимум нужно некоторое количество памяти под стек для каждого из них)

Для этих целей в linux существует epoll, во freebsd и macosx — kqueue а в windows — io completion port. Вместо того, чтобы вручную работать со всем этим зоопарком есть смысл посмотреть в сторону boost asio, libevent и прочих подобных библиотек.

Совет 4
Прежде чем писать свой велосипед сериализации — посмотрите на существующие решения. Для сериализации в бинарном виде есть google protobuff, MessagePack / CBOR и прочие. В текстовом — json && xml и их вариации.

Совет 5
Правильно выбирайте модель синхронизации. Основные модели синхронизации следующие:

• Передача полного состояния. С точки зрения реализации тут всё просто. Берём объект, сериализуем и отправляем всем кому он нужен. Пока объект имеет небольшой размер или редко запрашивается — всё хорошо. Как только размер становится относительно большой или же требуется частая синхронизация — начинает рости потребление трафика вплоть до невозможности обеспечить требуемую скорость обновления.
• Передача изменений (дифов). В этом подходе, вместо отправки полного состояния считается разница между старым состоянием и новым и отправляется лишь разница между ними. Разница может получатся разными способами. Например, её может явно запрашивать принимающая сторона (eg. пришли мне все данные с марта по июнь, остальное у меня уже есть). Или же отправляющая сторона сама следит за тем, какие данные уже есть у принимающей, в самом простом случае — считая что принимающая успешно получила все старые данные (eg. вот тебе данные за март; во тебе за апрель; вот тебе за май ...).
• Воспроизведение всеми одинакового набора событий. В этом подходе само состояние вообще не передаётся. Вместо этого передаются события, приводяющие к изменению состоянию.

В случе если у вас сериализованные события имеют размер сильно меньший чем состояния, рекомендую использовать именно третий способ. Однако он требует аккуратной реализаци. Иногда этот способ используют в комбинации с первым (например, в бд redis при master-slave синхронизации баз — подключившийся слейв вначале загружает полную копию базы а затем начинает проигрывать все команды синхронно с мастером). Так же этот способ позволяет делать простое журналирование происходящего. Для этого достаточно просто сохранять все команды. Так сделано, к примеру, в игре StarCraft. Сохранённые команды используютеся в дальнейшем при просмотре реплеев.

Совет 6
По возможности выбирайте централизованную архитектуру. Децентрализация выглядит заманчиво, однако существенно усложняет (и иногда замедляет) реализацию. При нескольких равноправных узлах вам необходимо думать о том, кто же в итоге будет принимать решения. Для решения этой задачи разработаны различные схемы принятия решений. Самые популярные — paxos (поверьте, вы не хотите это программировать) и raft. Но, даже в случае отсутствия необходимости консенсуса вам придется использовать разные хитрые методы решения тривиальных для централизованных систем задач. Например, dht для поиска, proof of work для защиты от атак, etc.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[Перевод] Начало работы с Intel Energy Profiler для Android

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

Обзор

Intel VTune Amplifier для специализированных систем позволяет оптимизировать энергопотребление приложений, предназначенных для встраиваемых платформ Linux, для операционных систем Android и Windows. Делается это благодаря анализу, который проводится с помощью Intel Energy Profiler.

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

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

Целевая платформа и хост-система

В этом материале рассматривается процесс профилирования энергопотребления на целевой платформе Android с использованием инструментов, включенных в состав Intel System Studio, установленной на Windows-компьютере. В материал так же включены комментарии об особенностях работы с системой, которая установлена на ОС Linux. Система, установленная на Mac OS, будет работать схожим образом, однако, мы не проводили эксперименты на Mac. Копии экрана, которые имеются в статье, сделаны на компьютере с установленной ОС Windows.

Проверка наличия необходимых драйверов

За работу с Android-устройствами в Energy Profiler отвечают несколько компонентов.

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

Следующий компонент – низкоуровневое приложение, которое взаимодействует с драйверами. С приложением можно работать через командную строку. В частности – собирать данные с устройства. Это приложение обычно называют сборщиком данных Intel SoC Watch. Обращение к нему ведется с помощью команды socwatch, сборщик можно установить на устройстве с помощью ADB-скрипта.

И, наконец, компонент для визуализации данных, который встроен в пользовательский интерфейс Intel VTune Amplifier. Вполне допустимо собирать данные по анализу энергопотребления, используя Intel SoC Watch через командную строку и обрабатывать полученные сведения вручную без использования графических инструментов Intel VTune Amplifier. Именно поэтому во многих работах, посвященных оптимизации энергопотребления, говорится лишь об «Intel SoC Watch», но не об «Intel Energy Profiler».

Для того чтобы узнать, установлен ли на устройстве, с которым вы собираетесь работать, нужный драйвер, а так же то, какая версия средства для сбора данных понадобится, нужно открыть adb shell и проверить, есть ли в директории /lib/modules/ или /system/lib/modules/ файл драйвера SOCWATCHx_x.ko.

Пример проверки устройства на наличие драйвера SOCWATCH

После проверки оказалось, что на устройстве, которое мы используем в этом примере, драйвер уже включён в образ системы. Располагается он по адресу /lib/modules/SOCWATCH1_3.ko. Имя файла драйвера позволяет нам понять, какую версию Intel SoC Watch надо использовать для сбора данных. Это – версия 1.3.

Если бы оказалось, что имя файла выглядит как SOCWATCH1_5.ko, нам бы пришлось воспользоваться Intel SoC Watch версии 1.5. Обратите внимание на то, что в Android Lollipop драйвер, скорее всего, будет находиться в папке /system/lib/modules. Однако и на этой версии Android стоит проверить обе папки. Например, на планшетном компьютере Asus Fonepad 8 с CPU Intel Atom Z3530, обновлённом до Android 5.0, драйвер был обнаружен именно в папке /lib/modules/.

Если необходимого драйвера не удаётся найти в системе, его нужно включить в ядро при сборке. Это выходит за рамки данной статьи. Полезные сведения на эту тему можно найти в руководстве пользователя, в разделе «Building the Kernel Modules». Ниже мы расскажем о том, где можно найти это руководство. Особое внимание следует обратить на то, чтобы драйвер имел такую же подпись, как и системное ядро, либо – должна быть возможность предоставить драйверу разрешения системного уровня.

Установка приложения для сбора данных

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

Найдите файл system_studio_target.tgz. Он находится в папке установки Intel System Studio. Путь к директории, где он расположен, может выглядеть как <ISS_install_dir>/Targets. Здесь <ISS_install_dir> представляет собой папку, куда выполнена установка System Studio. При использовании ОС Windows это обычно «C:\Program Files (x86)\Intel\System Studio yyyy.x.xxx». На Linux – «opt/intel/system_studio_yyyy.x.xxx».
Здесь yyyy.x.xxx – это номер версии набора установленных приложений. В вышеупомянутом .tgz-архиве содержатся файлы, которые нужны для хост-систем под управлением Windows или Linux. Архив следует распаковать куда-нибудь, где легко будет найти его содержимое. В нашем случае он был распакован в директорию «C:\Users\Public\ISS-2015_SoCWatch».

Если вы уже пользуетесь бета-версией Intel System Studio 2016, нужный файл можно найти по адресу «C:\Program Files (x86)\Intel_sw_development_tools\system_studio_2016.x.xxx\Targets».

С помощью командной строки перейдите к одной из только что распакованных папок, имя которой соответствует версии драйвера Intel SoC Watch, который ранее был идентифицирован на устройстве. В нашем случае это папка «C:\Users\Public\ISS-2015_SoCWatch\system\studio\target\socwatch_android_v1.3d\».

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

Убедитесь, что Android-устройство подключено к компьютеру по USB и запустите установочный скрипт. При работе в Windows нужно запустить пакетный файл socwatch_android_install.bat. В Linux вам понадобится shell-скрипт socwatch_android_install.sh. Если вы уже пользовались этими скриптами, вы увидите сообщение о том, что установка не удалась. Поэтому, если вы случайно установили не ту версию Android-приложения, перед установкой нужной версии вам понадобится удалить с устройства папку /data/socwatch с помощью adb shell. В случае успеха вы увидите список копируемых на устройство файлов.

Установка сборщика данных на устройство

Сбор данных

Сбор данных для анализа, в самой простой форме этого процесса, состоит из трёх шагов. Первый – настройка окружения. Второй – загрузка драйвера. Третий – запуск скрипта, который и собирает данные.

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

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

Подключитесь к устройству с помощью ADB и перейдите в директорию /data/socwatch. Здесь вы обнаружите скрипт setup_socwatch_env.sh. Запустите скрипт. В ходе его работы текущие настройки окружения будут показаны на экране. Кроме того, среди выведенных данных вы увидите напоминание о том, что нужно загрузить драйвер, но этим мы займёмся на следующем шаге. А сейчас нам нужны следующие команды:

source ./setup_socwatch_env.sh

или

. ./setup_socwatch_env.sh

Настройка окружения для сбора данных с помощью shell-скрипта

Загрузка драйвера

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

На данном шаге в оперативную память устройства загружается драйвер, обнаружением которого на устройстве мы занимались выше. Делается это с помощью команды insmod. В нашем примере драйвер расположен по адресу /lib/modules/SOCWATCH1_3.ko, он присутствует на устройстве и его можно загрузить для дальнейшей работы. Для большей уверенности можно проверить еще раз, загружен ли драйвер. Делается это с помощью команды lsmod. Вот пример её использования:

insmod /lib/modules/SOCWATCHx_y.ko

Загрузка и подтверждение загрузки драйвера socwatch

Некоторым версиям socwatch требуется загрузка дополнительного драйвера (socperf_xxx.ko). Так это или нет, будет указано после выполнения скрипта set_socwatch_env.sh.

Запуск скрипта для сбора данных

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

./socwatch --max-detail -f cpu -s 5 -t 30 -o ./results/GSG_examplerun

Запуск сбора данных

Здесь программа собирает сведения о C-состояниях и P-состояниях ядра процессора, выждав 5 секунд перед началом сбора данных. Сбор ведется в течение 30 секунд. Результаты выводятся в папку /data/socwatch/results/, при этом имена файлов начинаются с «GSG_examplerun».

Обратите внимание на то, что подключение Android-устройства к компьютеру через USB-кабель, весьма вероятно, повлияет на режим энергопотребления устройства. Поэтому кабель часто отключают сразу после запуска команды, но до начала сбора данных. Это можно сделать, например, с помощью фоновой задачи и команды nohup. Соответствующая команда может выглядеть так: «nohup ./socwatch &». После того, как она исполнена, кабель можно отключить.

Нередко весьма желательно, чтобы данные были собраны только при выполнении какого-то определенного приложения. Этого можно добиться с помощью параметра socwatch «-p». Подробности об этом приёме можно узнать из руководства пользователя или применив ключ --help.

Визуализация результатов с помощью VTune Amplifier

Для того чтобы проанализировать собранные данные с помощью Intel VTune Amplifier, нам понадобится пройти еще два этапа. А именно – скопировать файлы с собранными данными с устройства и импортировать их в приложение.

Копирование файлов с устройства

Для того чтобы скопировать файлы с устройства, нужно, воспользовавшись командной строкой, перейти в директорию компьютера, в которой вы можете сохранить эти файлы. Рекомендуется, чтобы это была папка, отличная от той, в которой хранятся проекты Intel VTune Amplifier. Дело в том, что при импорте эти файлы будут автоматически скопированы именно туда, поэтому лучше всего перенести их с устройства в какую-нибудь временную директорию.

Если опустить данный шаг и попытаться перейти напрямую к файлам на устройстве (например, начало пути к ним может выглядеть как «devicename/internal storage/data»), работать с ними не удастся из-за различных ограничений, связанных с разрешениями.

Когда вы перешли в командной строке к временной директории, в которую хотите скопировать файлы с устройства, воспользуйтесь командой adb pull. Если вы не помните точные имена файлов, можно получить их список командой вида «adb shell ls /data/socwatch/results». Вот примеры команд, с помощью которых мы скопировали нужные файлы:

adb pull /data/socwatch/results/GSG_examplerun.csv
adb pull /data/socwatch/results/GSG_examplerun.sw1

Копирование файлов с результатами тестирования на компьютер

Импорт данных в VTune для дальнейшего анализа

На этом шаге нам понадобится лишь файл с расширением .sw1, который был скопирован с устройства. Файл .csv (comma separated values) это текстовый файл с результатами, его можно использовать как источник данных для собственных скриптов анализа данных или других инструментов.

Запустите приложение Intel VTune Amplifier и загрузите нужный проект. Если вы не знакомы с этим продуктом, обратитесь к статье Начало работы с Intel VTune Amplifier для специализированных систем или к какому-нибудь похожему руководству. На вкладке «Welcome» щёлкните по ссылке «Import Result…». Можно поступить иначе – перейти к группе «Energy Analysis», которую можно найти в разделе «Analysis Type» на вкладке «New Analysis», и щёлкнуть «Import Data».

Обратите внимание на то, что вышеописанные действия актуальны для Intel System Studio 2015 Update 1 или более поздней. Если вы пользуетесь более ранней версией Intel System Studio, вам может понадобиться воспользоваться инструментами командной строки для импорта данных.

Импорт данных с вкладки Welcome

Импорт данных с экрана выбора типа анализа

И в том и в другом случаях следующим шагом будет вкладка «Import a File and Create a Result». На ней будет поле, в котором можно указать путь к .sw1-файлу, скопированному с устройства, который вы хотите импортировать в приложение.

Вкладка выбора файла для импорта

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

Интерпретация результатов

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

При загрузке результатов режим просмотра «Platform Power Analysis» будет выбран по умолчанию (обычно других вариантов нет), будет показана вкладка «Summary». На этой вкладке можно найти такие полезные сведения, как «Elapsed time», то есть – время тестирования, и время работы ядер процессора (обычно – это количество ядер, умноженное на время тестирования). Здесь же есть сведения о событиях (событий в секунду на ядро), которые приводят к выходу процессора из режима пониженного энергопотребления. На этой же вкладке можно обнаружить сведения о частоте активных ядер и о причинах событий, которые их «пробуждают».

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

./socwatch --max-detail -f cpu -f device -f sys -t 30 -s 5 –o ./results/idleasleep

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

Данные по устройству, которое находилось в спящем режиме

Еще одна полезная закладка – это «Correlate Metrics». Здесь можно увидеть раскладку по времени для различных состояний и событий. Тут можно легко увеличить масштаб просмотра нужного отрезка времени и исследовать точные временные рамки событий и то, как они соотносятся друг с другом. Кроме того, обратите внимание на то, что если удерживать какое-то время указатель мыши над интересующим вас участком, можно увидеть всплывающее сообщение с более подробными сведениями. Именно этот момент показан на следующем рисунке.

Просмотр данных на вкладке System Correlate Metrics

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

Для сравнения результатов двух испытаний сначала нужно раздельно импортировать в приложение оба набора данных, затем закрыть их вкладки анализа данных. На этом шаге рекомендуется переименовать результаты анализа в окне «Project Navigator» для того, чтобы с ними было удобнее работать, однако, это необязательно. Затем нужно воспользоваться значком «Compare Results» и указать, какие именно результаты анализа следует сравнить. Приложение покажет оба набора аналитических данных в одном окне, где их можно сопоставить. Вот пример сравнения двух наборов данных, полученных при выполнении различных тестов.

Сравнение результатов нескольких испытаний: общие сведения

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

Итоги

Мы рассмотрели пример использования средств Intel System Studio для анализа энергопотребления устройств, работающих на платформе Android. Теперь у вас есть всё необходимое для того, чтобы приступить к анализу и оптимизации ваших приложений.

Домашнее задание

» Документация по Intel VTune Amplifier 2015
» Руководства по оптимизации и повышению производительности

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Улучшенное выделение вкладок в сборке Vivaldi 1.0.258.3

сегодня в 15:10

Всем привет!

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

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

Теперь, удерживая клавишу Ctrl или Shift мы можем выбрать несколько из них, при этом результат выбора отображается теперь более наглядно:

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

Выберем из открывшегося списка вариант «Разместить по сетке» и получим вот примерно такой результат:

На этом пока всё на сегодня. Загрузить новую сборку можно по ссылкам ниже:

Полный список изменений:

• VB-1955 Cookie manager needs some love: click whole row to expand cookie; cookie filtering updated
• VB-8685 Tab selection not visible: High-contrast assured for all 4 themes
• VB-8739 Non-English languages are not used
• VB-5796 Refresh of desktop icons after Vivaldi start and SpeedDial reload
• SVG animation fix: Wrong color in light UI/active tab fixed
• Fix for excessive GPU memory usage when many tabs are open

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

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

[recovery mode] Дайджест полезных материалов для iOS-разработчиков

Пока все с нетерпением ждут новый iPhone и стабильную версию iOS 9, которые будут представлены на презентации Apple 9 сентября, мы собрали для вас подборку интересных материалов этой недели.

Кстати, про iOS 9. Начиная с нее, Apple будет дополнительно предупреждать пользователя при попытке установить Enterprise-приложение напрямую, без MDM. Такое вот небольшое стимулирование. Небольшое на первом шаге. Внутренний параноик говорит: «Сейчас у Apple нет полной связки для доставки Enterprise, Apple не контролирует цепочку, но может начать».

What’s New in AppCode 3.2
Как всегда: быстрее, могучее. Лучшая поддержка смешанного кода. Редактор UI стал отдельным плагином. Да, все изменения касаются Xcode 6.4, поддержка всего, сопутствующего Xcode 7, в процессе.
JETBRAINS.COM

Swift 2: Beta 6
На днях вышла 6-я бета Xcode. В ней было не только исправлено более половины крэшей, связанных со Swift, но и внесены некоторые изменения в сам язык. Из статьи вы узнаете, что именно изменилось.
RUSSBISHOP.NET

iOS 9 content blocking will transform the mobile Web: I’ve tried it
Интересная статья о том, как может измениться мир мобильной рекламы с приходом iOS 9.
THENEXTWEB.COM

Droptimizer
Несколько раз упоминались инструменты оптимизации графики для приложений. Вот еще один к ряду.
12ROCKETS.COM

Reducing FOOMs in the Facebook iOS app
Познавательная статья от Facebook о том, как они боролись с out-of-memory крэшами.
CODE.FACEBOOK.COM

TKSubmitTransition
Кнопка с красивой анимацией вам в коллекцию.
GITHUB.COM

LNPopupController
Фреймворк, позволяющий показывать контроллеры также, как это сделано в Apple Music и Podcasts.
GITHUB.COM

Читать продолжение выпуска

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Storage Replica в Windows Server 2016

Автор статьи — Михаил Комаров, MVP по направлению Hyper-V

Цель данной статьи — рассказать о новой компоненте Storage Replica, которая появилась в Windows Server vNext. Появление данной технологии было ожидаемо, так как последние несколько лет Microsoft уделяет пристальное внимание системам хранения. Первой ласточкой была новая реализация протокола SMB 3.0, которая появилась с выходом Windows Server 2012 и доработана новыми возможностями к выходу Windows Server 2012 R2.

Далее в нашу копилку добавим новый тип файлового кластера, так называемый SOFS

Упомянем также такие приятные вещи как встроенный тиминг, поддержку RDMA, InfiniBand-адаптеров, Storage Space для объединения дисков пул, Storage Tiering, который позволяет эффективно использовать комбинацию SDD и HDD пулов. Уже есть решения дисковых JBOD-полок, которые можно подключать напрямую к серверам и делать системы хранения. Есть промышленные решения Dell CPS, в которых использованы данные технологии.

После всего этого можно было ожидать репликацию томов, как в других системах хранения, и с выходом Windows Server vNext TP это было реализовано.

Storage Replica — это технология репликации томов в Windows на уровне блоков с использованием протокола SMB. На данный момент реализованы два сценария репликации томов: эластичный кластер и репликация между простыми серверами.

Управление реализовано следующим образом: из оснастки Failover Cluster Manager для эластичного кластера, а также Windows PowerShell и WMI. Обратите внимание, что поддерживаются только несъемные диски. Хотелось бы подчеркнуть, что Storage Replica — это не DFSR, и что репликация идет на уровне блоков. Ниже на иллюстрации видно, что механизм реализации Storage Replica находится ниже файловой системы, поэтому блочная репликация не зависит от типа файловой системы NTFS/CSVFS/ReFS.

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

Рассмотрим процесс асинхронной репликации более детально. Первый шаг — поступление данных на сервер-источник. Второй шаг — запись в журнал на отдельном томе. На третьем — оповещение приложения, что данные обработаны. Четвертый шаг — передача информации на целевой сервер. Пятый шаг — запись в журнал на целевом сервере. Шестой шаг — информирование сервера-источника об успешной записи в журнал. Далее, в момент времени t1, произойдет запись данных с тома журнала в том данных на обоих серверах.

Закончим теорию и начнем переходить к практике.

Начнем с требований.

Редакция Windows Server – Datacenter Edition. Оба компьютера должны быть членами домена. Диски обязательно GPT, не MBR. Никаких съемных носителей — внешних USB-массивов, флешек, ленточных накопителей, 5,25-дюймовых флоппи-дисков и т. п. Также необходима та же геометрия диска (между журналами, между данными) и разделы для данных. Свободное место для журналов на томе Windows NTFS/ReFS (журнал фиксированного размера, он не увеличивается и не уменьшается). Никакой репликации %SystemRoot%, файлов подкачки, файлов спящего режима, файлов DMP. Также необходимо открыть на брандмауэре порты SMB, WS-MAN.

Задержки обмена пакетами

В среднем ≤ 5 мс в обе стороны. Если взять идеальный вариант — скорость света в вакууме, то 5 мс — это примерно 1 500 км при обмене в обе стороны. В реальности оптоволокно снижает скорость примерно на 35 %, а есть еще и коммутаторы, маршрутизаторы, брандмауэры и т. д. В сухом остатке: большинство клиентов ограничиваются расстоянием 30–50 км.

Пропускная способность сети

Начальное требование — сеть ≥ 1 Гбит/с — при соединении «узел-узел» между серверами (для Windows Server нужны сетевые карты 1 Гбит/с). Все зависит от операций ввода-вывода и интенсивности совместного использования канала (возможно, SR – не единственная функция, которая будет генерировать трафик на площадку аварийного восстановления). Определите количество операций ввода- вывода (125 Мб/с объема операций ввода-вывода = ~1 Гбит/с нагрузки на сеть).

Производительность и размер тома журнала

Флеш-накопители (SSD, NVME и т. д.). Журналы большего размера позволяют быстрее восстановить систему после крупного сбоя и быстрее переключиться. Но цена этому — место на диске.

Существует командлет Test-SRTopology, который проверяет требования и рекомендации по пропускной способности сети, размеру журналов, количеству операций ввода-вывода в секунду и т. д. Работает в течение указанного времени и создает аккуратный отчет с рекомендациями в формате HTML.

Необходимо обратить внимание, что целевой том всегда отключен. Сценарий для целевого тома с возможностью записи-чтения или только чтения не используется. Подключение только «один к одному». Всегда можно использовать другие функции репликации (например, Hyper-V Replica для A-B, а SR для A-C). При изменении размера тома репликация прерывается.

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

Enable-NetFirewallRule -CimSession SR1,SR2 -DisplayGroup "Remote Desktop","File and Printer Sharing"

Результат ее работы приведен ниже. Можно сделать это из консоли.

Проверим доступность сервера:

ping SR2.contoso.com -4 -f -l 1472 -n 300

На следующем шаге подключим по 2 диска на каждый сервер и при инициализации выберем GPT раздел. Далее отформатируем в NTFS и присвоим литеры дискам. Для демонстрации я использовал динамические диски. И диск под журнал ограничил 15GB.

Включим фичу с помощью PowerShell команды и перезагрузим хосты.

$Servers = {список серверов}
$Servers | ForEach { Install-WindowsFeature –ComputerName $_ –Name WVR –IncludeManagementTools -restart }

Или используя графический интерфейс

Теперь включим репликацию, используя PowerShell, мастер доступен только в версии для failover cluster.

 
New-SRPartnership -SourceComputerName SR1 -SourceRGName rg01 -SourceVolumeName Q: -SourceLogVolumeName T: -DestinationComputerName SR2 -DestinationRGName rg02 -DestinationVolumeName Q: -DestinationLogVolumeName T: -LogSizeInBytes 8gb

Данная команда включает репликацию на серверах SR1,SR2. Определяет тома репликации Q, на которых буду лежать данные, а также задает тома для журналов T и задает размер журнала 8 GB.
Результат работы команды мы видим ниже.

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

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

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

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

Как мы говорили ранее, на втором сервере диск с данными недоступен. Он в формате RAW и будет доступен после отключения или переключения репликации.

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

Запускаем DISKPART, выбираем наш диск (х, например)

DISKPART
LIST DISK
SELECT DISK X
attribute disk clear readonly

Находим раздел (Y “unknown” размером 512KB)

LIST PARTITION
SELECT PARTITION Y

Проверяем раздел ( GUID 558d43c5-a1ac-43c0-aac8-d1472b2923d1)

DETAIL PARTITION

Удаляем раздел

DELETE PART OVERRIDE

На этом мы закончим краткий обзор данной технологии, которая появилась в Windows Server vNext.

Ресурсы
Storage Replica in Windows Server Technical Preview

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.