Примечание переводчика: в предыдущей статье о подготовке к девопс-конференциям, Gryphon88 задал резонный вопрос: как отличить cutting-edge и хайп? Нижеследующая статья наполнена сочной незамутненной истерикой, которую так приятно читать с утра, попивая чашечку кофе. Минус в том, что она написана в ноябре 2016, но нетленка не стареет. Если после прочтения захочется добавки, есть комментарии на Hacker News. А у тебя, юзернейм, такой же ад? Пиши в комментариях. Итак, начнем.

В первый раз я встретился с Докером в начале 2015. Мы экспериментировали с ним, чтобы понять, для чего бы его можно употребить. В то время нельзя было запустить контейнер в фоне, не было команд чтобы посмотреть что запущено, зайти под дебагом или SSH внутрь контейнера. Эксперимент оказался быстрым, Докер был признан бесполезным и более похожим на альфу или прототип, чем на релиз.

Промотаем нашу историю до 2016. Новая работа, новая компания, и хайп вокруг докера поднялся безумный. Разработчики уже выкатили докер в продакшен, так что сбежать с него не удастся. Хорошая новость в том, что команда run наконец-то заработала, мы можем запускать и останавливать контейнеры. Оно шевелится!

У нас 12 докеризованных приложений, бегающих на проде прямо в момент написания этой заметки, размазанные на 31 хост на AWS (по одному приложению на хост, дальше объясню — почему).

Эта заметка рассказывает, как мы путешествовали вместе с Докером — путешествие полное опасностей и неожиданных поворотов.

Докер: Проблемы в продакшене

Докер: Поломки и регрессии в обновлениях

Мы использовали следующие версии (или по крайней мере, попытались это сделать):
1.6 => 1.7 => 1.8 => 1.9 => 1.10 => 1.11 => 1.12

Каждая новая версия что-нибудь да ломала. В начале гда на докере 1.6 мы запустили одно приложение.

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

Версии 1.7 и 1.8 не запускались. Мы перешли на 1.9 только чтобы спустя две недели найти критический баг в этой версии, поэтому пришлось (снова!) обновляться до 1.10.

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

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

Бонус: Докер убрали из официальных репозиториев Debian, поэтому покет переименовался из docker.io в docker-engine. Документация созданная до этого изменения — устарела.

Докер: Старые образы нельзя удалять

Наиболее желаемая, и болезненно отсутствующая фича — команда для удаления старых образов (старше чем X дней, или не используемых Х дней, неважно). Дисковое пространство — это критическая проблема, учитывая что образы часто обновляются и могут занимать более 1 Gb.

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

 docker images -q -a | xargs --no-run-if-empty docker rmi  

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

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

В интернете можно найти множество попыток сделать это, ни одна из них не работает хорошо. Нет никакого API чтобы показывать образы с датами, иногда есть но они устаревают за 6 месяцев. Например, часто используемая стратегия — читать аттрибут "дата" из файла образа и запускать docker rmi. Но она не работает, когда меняется имя. Другая стратегия — вычитывать дату и удалять файлы напрямую, но она приводит к повреждением если прошла неидеально, и это просто нельзя сделать идеально никому кроме самого Докера.

Докер: Поддержка в ядре (точнее, ее отсутствие)

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

Мы используем Debian Stable c backports в проде. Мы начали с Debian Jessie 3.16.7-ckt20-1 (ее релизнули в ноябре 2015). У нее был большой критичный баг, из-за которого хаотично крашились хосты (в среднем, каждые несколько часов).

Докер: Нестабильные драйвера файловой системы

У докера есть куча драйверов для подсистемы хранения. Единственный (якобы) ревностно поддерживаемый — AUFS.

Драйвер AUFS нестабилен. Включая критические баги, приводящие к панике ядра и повреждениям данных.

Он сломан (как минимум) на всех ядрах linux-3.16.x. Лечения не существует.

Мы часто обновляемся вслед за Дебианом и ядром. Дебиан выложил специальные патчи вне обычного цикла. Был один большой багфикс AUFS где-то в марте 2016. Мы думали, что это ТОТ САМЫЙ ФИКС, но нет. После него паники начали случаться реже (каждую неделю вместо каждого дня), но баг никуда не исчез.

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

В 2016 случилось множество фиксов AUFS. Некоторые критичные проблемы починилсь, но куча других всё еще существует. AUFS нестабилен как минимум на всех ядрах linux-3.16.x.

• Debian Stable сосет на 3.16. Нестабильно. Нельзя ничего сделать кроме как переключиться на Debian Testing (который использует четвертое ядро).
• Ubuntu LTS работает на 3.19. Нет никаких гарантий, что последнее обновление починило на нем проблему. Менять нашу основную операционную систему было бы огромной проблемой, но мы так отчаялись, что даже рассматривали этот вариант какое-то время.
• RHEL/CentOS-6 работает на ядре 2.x, RHEL/CentoS-7 — на ядре 3.10 (с кучей бэкпортов от рэдхата RedHat).

Linux 4.x: ядро официально прекратило поддержку докера

Широко известен факт, что у AUFS бесконечно проблем, что разработчики считают ее мертвым грузом. Ради будущих поколений, AFUS выбросили из четвертого ядра.

Не существует никакого неофициального патча для ее поддержки, нет никакого опционального модуля, бэкпорта или чего-то такого, ничего. AUFS полностью исчезла.

(драматическая пауза)

.

.

.

Как тогда докер работает без AUFS? Ну, он не работает.

(драматическая пауза)

.

.

.

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

"OverlayFS — это современная union файловая система, похожая на AUFS. В сравнении с AUFS, OverlayFS спроектирована проще, присутствует в мейнлайне ядра Linux с версии 3.18, и потенциально работает быстрее". — Docker OverlayFS driver

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

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

Overlay: история неуспеха

Драйвер файловой системы — это сложное программное обеспечение, и оно требует огромного уровня надежности. Старички помнят, как Linux мигрировал с ext3 на ext4. Его не сразу написали, еще больше времени дебажили, и в конце концов ext4 стал основной файловой системой во всех популярных дистрибутивах.

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

Короче. В этой истории всё пошло не так. Жуткие истории до сих пор населяют кэш Гугла.

Разработку Overlay бросили в течение года после первого релиза.

драматическая пауза

.

.

.

Время для Overlay2!

"Драйвер overlay2 призван решить ограничения overlay, но он совместим только с ядрами Linux 4.0 и старше, и docker 1.12" — статья "Overlay vs Overlay2 storage drivers"

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

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

Выводы: как мы видим на примере Overlay и Overlay2. Нет бэкпортов. Нет патчей. Нет совместимости со старыми версиями. Докер просто идет вперед и ломает вещи :) Если вы хотите использовать Докер, придется тоже двигаться вперед, успевая за релизами докера, ядра, дистрибутива, файловых систем, и некоторых зависимостей.

Бонус: всемирное падение Докера

2 июня 2016, примерно в 9 утра (по Лондонскому времени). Новые ключи пушатся в публичный репозиторий докера.

Прямым следствием этого является то, что любой apt-get update (или аналог) на системе, в которую подключен сломанный репозиторий, падает с ошибкой "Error https://apt.dockerproject.org/ Hash Sum mismatch".

Это проблема случилась по всему миру. Она повлияла на ВСЕ системы на планете, к которым подключен репозиторий Докера. На всех версиях Debian и Ubuntu, вне запвисимости от версии операционной системы и докера.

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

Через некоторое время. Новость от сотрудника докера: "Есть новости. Я поднял этот вопрос внутри компании, но люди, которые могут это починить, находятся в часовом поясе Сан Франциско (8 часов разницы с Лондоном — прим. автора), поэтому их еще нет на работе."

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

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

Новость от чувака из Докера во Флориде, примерно 3 часа дня по Лондонскому времени. Он проснулся, обнаружил ошибку, и работает над фиксом.

Позже были переопубликованы ключи и пакеты.

Мы попробовали и подтвердили работоспособность фикса примерно в 5 дня (по Лондону).

По сути случилось 7 часовое общемировое падение систем, исключительно по причине поломки Докера. Всё что осталось от этого события — несколько сообщений на страничке бага на GitHub. Никакого постмортема. Немного (или вообще никаких?) технических новостей или освещения в прессе, несмотря на катастрофичность проблемы.

Docker Registry

Реестр хранит и обслуживает образы докера.

Автоматическая сборка CI ===> (при удаче) заливка образа в ===> docker registry
Команда на разворачивание <=== залить образ из <=== docker registry

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

Существует 3 версии реестра:

• Registry v1 — устаревший и заброшенный
• Registry v2 — полностью переписанный на Go, впервые релизнутый в апреле 2015
• Trusted Registry — (платный?) сервис, на который много раз ссылается документация, не уверен что понимаю — что это, просто пропускаем его.

Реестр: Забросить и Сломать

Реестр v2 — это полностью переписанный софт. Реестр v1 был отправлен на пенсию сразу же после выпуска v2.

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

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

Выводы: не доверяй никакому инструменту или API из докера. Они постоянно забрасываются и ломаются.

Одна из целей реестра v2 была в создании более качественного API. Это задокументировано здесь, 9 месяцев назад существовала документация, о которой мы уже и не помним.

Реестр: Нельзя очищать образы

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

Реестр просто растёт вечно. Наш реестр может расти на 50 GB в неделю.

У нас нет сервера с бесконечным размером диска. Наш реестр несколько раз переполнял свободное место, превращая пайплайн сборки в ад, а потом мы перешли на S3.

Выводы: Необходимо использовать S3 для хранения образов (это поддерживается из коробки).

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

Выводы: ручное удаление любого файла или директории с диска реестра ПОВРЕДИТ его.

И на сегодняшний день всё так же невозможно удалить образ из реестра. Никакого API тоже нет. (Одна из главных целей создания v2 была в дизайне хорошего API. Миссия провалилась).

Докер: релизный цикл

Релизный цикл докера является единственной константой в экосистеме Докера:

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

Релизный цикл применим, но не ограничивается следующим: докер, фичи, файловые системы, реестр, всё API…

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

"Мы делаем софт не для того, чтобы его кто-то использовал, а потому что нам нравится делать новые вещи" — будущая эпитафия Докера

Текущий статус-кво Докера в нашей компании

Рост в вебе и микросервисах

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

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

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

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

Заметка: никакие из этих проблем не коснулись наших клиентов и их денег. Мы довольно успешно сдерживаем буйство Докера.

Запрещено использовать в ядре

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

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

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

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

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

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

Запрещено использовать в DBA

Докер задуман быть stateless. Контейнеры не имеют хранилища на диске, всё что происходит — эфемерно и уходит, когда контейнер останавливатеся. Не подразумевается, что контейнеры будут хранить данные. На самом деле, они спроектированы чтобы НЕ ХРАНИТЬ данные. Любоая попытка действовать против этой философии приводит к несчастьям.

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

Короче. Докер НЕ ДОЛЖЕН ЗАПУСКАТЬ базы данных в продакшене, by design.

Всё хуже. Помните постоянные паники ядра при использовании докера?

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

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

Заключение: Вы ОБЯЗАНЫ НЕ ЗАПУСКАТЬ на Докере базы данных в продакшене, НИКОГДА.

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

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

Личное мнение

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

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

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

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

Мой долг — перед клиентами. Защищать их, и их деньги.

Выживаем с Докером на продакшене

Как Докер хочет выглядеть:

Что такое Докер на самом деле:

Следите за релизами и ченжлогами

Внимательно следите за версиями и ченжлогами для ядра, операционной системы, дистрибутива, докера, и всего в промежутке между ними. Изучайте баги, описания как люди ждут патчи, читайте всё что можете максимально внимательно.
ansible '*' -m shell -a "uname -a"

Позвольте докеру умирать

Позвольте докеру умирать. Не требует пояснений.

Время от времени мы мониторим сервера, находим мертвые и перезапускаем с форсом.

Имейте по 3 инстанса всего на свете

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

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

Большую часть времени, крашатся CI и тестовые инстансы. (На них работает куча интенсивных тестов, и проблемы там возникают особо адовые). У нас их много. Бывают вечера, когда они крашатся по 3 штуки одновременно.

Не кладите данные в Докер

Сервисы, которые держат в себе данные, не докеризуются.

Докер спроетирован так, чтобы НЕ ХРАНИТЬ данные. Не пытайтесь идти против этого, это рецепт боли и унижений.

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

Не запускайте ничего важного в Докере

Докер ОБЯЗАТЕЛЬНО сломается. Докер УНИЧТОЖИТ всё, к чему притронулся.

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

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

Докеризованные приложения должны работать на автомасштабирующихся группах. (Заметка: у нас это сделано всё еще не до конца.)

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

План на будущее

Docker

Невероятное испытание при использовании Докера — прийти к работающей комбинации ядро + дистрибутив + версия докера + файловая система.

Прямо сейчас. Мы не знаем, НИКАКОЙ комбинации, которая является действительно стабильной (может быть, такой не существует?). Мы активно ищем её, постоянно тестируя новые системы и патчи.

Цель: найти стабильную экосистему для запуска докера.

Требуется 5 лет чтобы сделать хороший, стабильный софт, а Docker v1.0 имеет возраст всего лишь 28 месяцев, и у него не было времени повзрослеть.

Время обновления железа — 3 года, цикл релизов дистрибутив — 18-36 месяцев. Докер не существовал на предыдущем цикле, поэтому мы не можем оценить совместимость с ним. Хуже того, он зависит от множества продвинутых внутренних систем, которые довольно новы и тоже не успели ни повзрослеть, ни добраться до дистрибутивов.

Он может стать хорошим продуктом лет через 5. Подождем и посмотрим.

Цель: подождать, пока ситуцация станет лучше. В это время заняться делами, и постараться не обанкротиться.

Используйте автоматически масштабирующиеся группы

Докер ограничен stateless приложениями. Если приложения может быть пакетизировано в Docker Image, оно может быть пакетизировано в AMI (Amazon Machine Image — прим. пер.). Если приложение может запускаться в докере, оно также может запускаться в автоматически масштабирующейся группе.

Большинство людей игнорируют это, но Docker бесполезен на AWS, и на самом деле это шаг назад.

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

Контейнеры бесполезны на облачных провайдерах. Всегда существует инстанс правильного размера. Просто создайте его с тем количеством памяти/процессора, которое реально нужно приложению. (Минимально на AWS можно сделать t2.nano, который стоит 5 баксов в месяц за 512MB и 5% CPU).

Во-вторых, наибольшее преимущество контейнеров проявляется в системах с системой полной оркестрации всего, позволяющей автоматически управлять всеми командами (create/stop/start/rolling-update/canary-release/blue-green-deployment). Таких систем оркестрации в данный момент не существует. (В этот момент на сцену выходят всякие Nomad/Mesos/Kubernetes, но они пока недостаточно хороши).

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

Создавайте автоматически масштабирующиеся группы для каждого сервиса, и собирайте AMI на каждую версию (совет: используйте Packer чтобы собирасть AMI). Люди уже знакомы с управлением AMI и инстансами на AWS, здесь нечего особо изучать, и тут нет никакого подвоха. В результате развертывание получается преотличное и полностью автоматизированное. Автомасштабируемые группы года на три опередили экосистему Докера.

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

CoreOS

Важно: Docker and CoreOS созданы различными компаниями, это нужно учитывать.

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

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

Цель: проверить стабильность экосистемы CoreOS.

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

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

Цель: исследовать разворачивание CoreOS в целом.

Kubernetes

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

Проблема с Докером в том, что он ничего из этого не делает. Это просто тупая контейнерная система. Она имеет все недостатки контейнеров без каких-либо преимуществ.

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

• Mesos не предназначен для Docker
• Docker Swarm не заслуживает доверия
• Nomad умеет только самые простые фичи
• Kubernetes новый и экспериментальный

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

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

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

Вопрос не в том, стоит ли внедрять Kubernetes. Вопрос в том, когда это делать?

Задача: продолжать наблюдать за Kubernetes.

Заметка: Kubernetes требует для своего запуска докер. Он будет подвержен всем проблемам докера. (Например, не пытайтесь запустить Kubernetes ни на чем, кроме CoreOS).

Google Cloud: Google Container Engine

Как мы говорили раньше, не существует никакой известной стабильной комбинации: операционная система + дистрибутив + версия докера, поэтому не существует стабильной экосистемы для запуска на ней Kubernetes. Это — проблема.

Но существует потенциальный вокрэраунд: Google Container Engine. Он хостится на Kubernetes (и Docker) как сервис, часть Google Cloud.

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

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

Цель: перейти на Google Cloud, начиная с филиалов, не привязанных к AWS. Игнорирвать оставшуюся часть перечисленных здесь задач, т.к. они становятся нерелевантными.

Google Container Engine: еще одна причина, почему Google Cloud — это будущее, и AWS — это прошлое (в т.ч. на 33% более дешевые инстансы со в 3 раза большей скоростью и IOPS в среднем).

Disclaimer (прочитайте, прежде чем комментировать!)

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

Честно сказать, у нас были ожидания выше среднего, и мы воспринимаем проблемы с продакшеном довольно (слишком?) серьезно.

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

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

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

https://habrahabr.ru/post/332450/

Аналитики компании «Доктор Веб» исследовали модуль обновления M.E.Doc и обнаружили его причастность к распространению как минимум еще одной вредоносной программы. Напоминаем, что, по сообщениям независимых исследователей, источником недавней эпидемии червя-шифровальщика Trojan.Encoder.12544, также известного под именами NePetya, Petya.A, ExPetya и WannaCry-2, стал именно модуль обновления популярной на территории Украины программы для ведения налоговой отчетности M.E.Doc.

В сообщениях утверждается, что первоначальное распространение червя Trojan.Encoder.12544 осуществлялось посредством популярного приложения M.E.Doc, разработанного украинской компанией Intellect Service. В одном из модулей системы обновления M.E.Doc с именем ZvitPublishedObjects.Server.MeCom вирусные аналитики «Доктор Веб» обнаружили запись, соответствующую характерному ключу системного реестра Windows: HKCU\SOFTWARE\WC.



Специалисты «Доктор Веб» обратили внимание на этот ключ реестра в связи с тем, что этот же путь использует в своей работе троянец-шифровальщик Trojan.Encoder.12703. Анализ журнала антивируса Dr.Web, полученного с компьютера одного из наших клиентов, показал, что энкодер Trojan.Encoder.12703 был запущен на инфицированной машине приложением ProgramData\Medoc\Medoc\ezvit.exe, которое является компонентом программы M.E.Doc:



id: 425036, timestamp: 15:41:42.606, type: PsCreate (16), flags: 1 (wait: 1), cid: 1184/5796:\Device\HarddiskVolume3\ProgramData\Medoc\Medoc\ezvit.exe

source context: start addr: 0x7fef06cbeb4, image: 0x7fef05e0000:\Device\HarddiskVolume3\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll

created process: \Device\HarddiskVolume3\ProgramData\Medoc\Medoc\ezvit.exe:1184 --> \Device\HarddiskVolume3\Windows\System32\cmd.exe:6328

bitness: 64, ilevel: high, sesion id: 1, type: 0, reason: 1, new: 1, dbg: 0, wsl: 0

curdir: C:\Users\user\Desktop\, cmd: "cmd.exe" /c %temp%\wc.exe -ed BgIAAACkAABSU0ExAAgAAAEAAQCr+LiQCtQgJttD2PcKVqWiavOlEAwD/cOOzvRhZi8mvPJFSgIcsEwH8Tm4UlpOeS18o EJeJ18jAcSujh5hH1YJwAcIBnGg7tVkw9P2CfiiEj68mS1XKpy0v0lgIkPDw7eah2xX2LMLk87P75rE6 UGTrbd7TFQRKcNkC2ltgpnOmKIRMmQjdB0whF2g9o+Tfg/3Y2IICNYDnJl7U4IdVwTMpDFVE+q1l+Ad9 2ldDiHvBoiz1an9FQJMRSVfaVOXJvImGddTMZUkMo535xFGEgkjSDKZGH44phsDClwbOuA/gVJVktXvD X0ZmyXvpdH2fliUn23hQ44tKSOgFAnqNAra

status: signed_microsoft, script_vm, spc / signed_microsoft / clean

id: 425036 ==> allowed [2], time: 0.285438 ms

2017-Jun-27 15:41:42.626500 [7608] [INF] [4480] [arkdll]

id: 425037, timestamp: 15:41:42.626, type: PsCreate (16), flags: 1 (wait: 1), cid: 692/2996:\Device\HarddiskVolume3\Windows\System32\csrss.exe

source context: start addr: 0x7fefcfc4c7c, image: 0x7fefcfc0000:\Device\HarddiskVolume3\Windows\System32\csrsrv.dll

created process: \Device\HarddiskVolume3\Windows\System32\csrss.exe:692 --> \Device\HarddiskVolume3\Windows\System32\conhost.exe:7144

bitness: 64, ilevel: high, sesion id: 1, type: 0, reason: 0, new: 0, dbg: 0, wsl: 0

curdir: C:\windows\system32\, cmd: \??\C:\windows\system32\conhost.exe "1955116396976855329-15661177171169773728-1552245407-149017856018122784351593218185"

status: signed_microsoft, spc / signed_microsoft / clean

id: 425037 ==> allowed [2], time: 0.270931 ms

2017-Jun-27 15:41:43.854500 [7608] [INF] [4480] [arkdll]

id: 425045, timestamp: 15:41:43.782, type: PsCreate (16), flags: 1 (wait: 1), cid: 1340/1612:\Device\HarddiskVolume3\Windows\System32\cmd.exe

source context: start addr: 0x4a1f90b4, image: 0x4a1f0000:\Device\HarddiskVolume3\Windows\System32\cmd.exe

created process: \Device\HarddiskVolume3\Windows\System32\cmd.exe:1340 --> \Device\HarddiskVolume3\Users\user\AppData\Local\Temp\wc.exe:3648

bitness: 64, ilevel: high, sesion id: 1, type: 0, reason: 1, new: 1, dbg: 0, wsl: 0

curdir: C:\Users\user\Desktop\, cmd: C:\Users\user\AppData\Local\Temp\wc.exe -ed BgIAAACkAABSU0ExAAgAAAEAAQCr+LiQCtQgJttD2PcKVqWiavOlEAwD/cOOzvRhZi8mvPJFSgIcsEwH8Tm4UlpOeS18oE JeJ18jAcSujh5hH1YJwAcIBnGg7tVkw9P2CfiiEj68mS1XKpy0v0lgIkPDw7eah2xX2LMLk87P75rE6U GTrbd7TFQRKcNkC2ltgpnOmKIRMmQjdB0whF2g9o+Tfg/3Y2IICNYDnJl7U4IdVwTMpDFVE+q1l+Ad92 ldDiHvBoiz1an9FQJMRSVfaVOXJvImGddTMZUkMo535xFGEgkjSDKZGH44phsDClwbOuA/gVJVktXvDX 0ZmyXvpdH2fliUn23hQ44tKSOgFAnqNAra

fileinfo: size: 3880448, easize: 0, attr: 0x2020, buildtime: 01.01.2016 02:25:26.000, ctime: 27.06.2017 15:41:42.196, atime: 27.06.2017 15:41:42.196, mtime: 27.06.2017 15:41:42.196, descr: wc, ver: 1.0.0.0, company: , oname: wc.exe

hash: 7716a209006baa90227046e998b004468af2b1d6 status: unsigned, pe32, new_pe / unsigned / unknown

id: 425045 ==> undefined [1], time: 54.639770 ms

Запрошенный с зараженной машины файл ZvitPublishedObjects.dll имел тот же хэш, что и исследованный в вирусной лаборатории «Доктор Веб» образец. Таким образом, наши аналитики пришли к выводу, что модуль обновления программы M.E.Doc, реализованный в виде динамической библиотеки ZvitPublishedObjects.dll, содержит бэкдор. Дальнейшее исследование показало, что этот бэкдор может выполнять в инфицированной системе следующие функции:

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

Весьма интересным выглядит следующий фрагмент кода модуля обновления M.E.Doc — он позволяет запускать полезную нагрузку при помощи утилиты rundll32.exe с параметром #1:



Именно таким образом на компьютерах жертв был запущен троянец-шифровальщик, известный как NePetya, Petya.A, ExPetya и WannaCry-2 (Trojan.Encoder.12544).

В одном из своих интервью, которое было опубликовано на сайте агентства Reuters, разработчики программы M.E.Doc высказали утверждение, что созданное ими приложение не содержит вредоносных функций. Исходя из этого, а также учитывая данные статического анализа кода, вирусные аналитики «Доктор Веб» пришли к выводу, что некие неустановленные злоумышленники инфицировали один из компонентов M.E.Doc вредоносной программой. Этот компонент был добавлен в вирусные базы Dr.Web под именем BackDoor.Medoc.

Подробнее о троянце

P.S. На Украине изъяли серверы у распространившей вирус Petya компании: www.rbc.ru/technology_and_media/04/07/2017/595bb1bc9a7947bc8356a6a3

https://habrahabr.ru/post/332444/

Компания Bitfury занимается поддержкой и разработкой реализации сети Lightning уже больше года. Сегодня мы расскажем о проведении первой multi-hop-транзакции.

/ изображение Vadim Kurland CC

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

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

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

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


Хеши фундирующих транзакций, сформированных командой Bitfury, выглядят следующим образом:

af3bc396cc6ea9fe10ae6c0b2691e40635f0286b356dcb962488ea6d9e15b0c8
87d25c3a6d895f5fff6892495e57814db58280e32eb4697428ac1e8c61a8a5c7

В тесте маршрутизация проводилась вручную, поскольку в транзакции участвовали всего три узла, «расположение» которых было заранее известно. В будущем, когда сеть «разрастется» до тысяч участников, для этого потребуется алгоритм Flare, разработанный компанией Bitfury совместно с командой Lightning Network и представленный в июле 2016 года (о котором мы писали здесь). Алгоритм уже был протестирован компанией ACINQ.

Сама концепция Lightning Network в ближайшем будущем позволит проводить огромное количество маршрутизируемых микротранзакций практически без издержек, что серьезно разгрузит блокчейны. Кроме того, LN позволит ускорить проведение платежей: временной порог «упадет» с 30 минут до нескольких секунд. Однако на пути к этому необходимо преодолеть ряд трудностей.

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

«Однако задержка выхода Segregated Witness блокирует реальный выпуск софта. Также неизвестно, сколько времени потребуется на то, чтобы сеть смогла обрабатывать значительный поток транзакций, — отмечает Вячеслав Жигулин из Bitfury. — На мой взгляд, пройдет как минимум полгода после принятия SegWit, прежде чем пользователи биткойна увидят реальные «дешевые и быстрые» транзакции».

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

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

Пользователи Reddit уже назвали факт реализации multi-hop-транзакции в сети Lightning «чрезвычайно важным» и отметили, что нужно как можно скорее внедрить эту технологию в главные криптовалютные кошельки и блокчейны. И работу над первыми пользовательскими приложениями уже ведет большое количество разработчиков, в том числе Blockstream, ACINQ, Lightning Labs, MIT DCI и Bitfury.

Дополнительное чтение:

• Как запустить надстройку над биткойн-блокчейном
• Как масштабировать биткойн-блокчейн
• Что такое эксклюзивные блокчейны

https://habrahabr.ru/post/332436/

Привет всем. В данной статье я бы хотел показать пример использования связки TI SensorTag, Raspberry PI, Apache Camel с выводом в веб часть. В результате будет веб приложение, отображающее в реальном времени данные с сенсоров и бд хранящая показания, с промежуточным связующим узлом в виде Apache Camel приложения.

Подготовка

Для работы использовались:

1. Raspberry PI 3
2. TI SensorTag 2650 (Можно использовать и TI SensorTag 2541, только будет меньше сенсоров)

Настраиваем TI SensorTag

• Если вы еще не перезаписывали стандартную прошивку, то она подойдет для работы.
• Или нужно скачать BLE Stack и прошить с помощью SmartRF Flash Programmer образ CC2650SensorTag_BLE_All_v1_20.hex, лежащий в %programfiles(x86)%\Texas Instruments\SmartRF Tools\BLE Device monitor\firmware\cc26xx\sensortag

Настраиваем Raspberry PI

Устанавливаем Raspbian на Raspberry PI отсюда.

Eclipse Kura

Eclipse Kura — это фреймворк для создания приложений, работающих с IoT на таких платформах как Raspberry PI. Позволяет настраивать приложения через веб интерфейс или через API. Приложения разворачиваются через OSGi. Так же берет на себя заботу об работе с mqtt брокером. [1]

Установка Eclipse Kura

Для простоты станем рутом и обновим список пакетов sudo -i && apt-get update. Установим Java (лучше использовать Oracle java, apt-get install oracle-java8-jdk). Скачаем Kura версии Raspbian (Model 2) — Stable отсюда (скачать последную версию на момент статьи: wget http://mirror.onet.pl/pub/mirrors/eclipse//kura/releases/3.0.0/kura_3.0.0_raspberry-pi-2-3_installer.deb) и установим: dpkg -i kura_*_installer.deb && apt-get install -f. Перезапускаем Raspberry PI: shutdown -r now.

Теперь можно открыть Kura WEB UI по адресу http://\ c логином и паролем admin/admin. Здесь можно настроить сеть, wi-fi точку доступа, имя устройства и другие параметры.

Установка BlueZ для связи по BLE с SensorTag

Версия из менеджера пакетов должна вполне подойди. Поэтому выполняем:

apt-get install -y libusb-dev libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev

apt-get install bluez

Запустим и добавим в автозагрузку bluetooth сервис: systemctl enable bluetooth && systemctl start bluetooth. Включим беспроводной интерфейс: hciconfig hci0 up. Проверим, что интерфейс включился и все работает: hciconfig -a. При возникновении ошибок в bluez, можно попробовать скачать и скомпилировать последнюю версию, например по статье [3][4].

Установка Mosquitto

Mosquitto — опенсорный брокер сообщений по протоколу MQTT. Он нам нужен для отправки данных с SensorTag на Camel backend приложение.

Его можно установить, как на Rasperry PI, так и на другую машину, или использовать облачные решения (IBM, Azure). Но для работы web части, необходимо, чтобы mosquitto был настроен на работу через mqtt over websockets (Это можно сделать на другом экземпляре брокера, а не на локальном брокере).

Установка на Raspberry PI:

Версия из стандартного репозитория

apt-get install mosquitto 
systemctl enable mosquitto

Чтобы включить websocket в mosquitto добавим следующие строки в /etc/mosquitto/mosquitto.conf

# Websocket  
listener 1883  
listener 9001
protocol websockets

и запустим systemctl start mosquitto. Чтобы установить самую новую версию mosquttio с поддержкой websockets. [2]

wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
apt-get update
apt-get install mosquitto

Сборка и развертывание BLE TI SensorTag example приложения

Kura содержит пример приложения для работы с TI SensorTag. Оно раз в n секунд подключается по BLE к устройству, считывает данные с помощью Generic Attribute Profile (GATT) и отправляет их в брокер. Получается довольно медленно, но для начала пойдет.

Для начала склонируем репозиторий с kura. Можете воспользоваться или оригинальным https://github.com/eclipse/kura или форкнутым проектом https://github.com/leadex/kura, в котором добавлено считывание метрики температуры с барометра.

Выкачиваем:

git clone https://github.com/leadex/kura
cd kura

У меня скомпилировать код удалось только на linux. Для сборки выполняем ./build-all.sh. Для последующей сборки только ble example:

cd kura/kura/examples/org.eclipse.kura.example.ble.tisensortag
mvn clean install -Dmaven.test.skip=true

Далее скопируем полученный jar на Raspberry PI.

cd kura/examples/org.eclipse.kura.example.ble.tisensortag
scp target/org.eclipse.kura.example.ble.tisensortag-*-SNAPSHOT.jar pi@:/tmp

Развертывание

Подключаемся к OSGi console из Raspberry PI telnet localhost 5002 или удаленно telnet 5002. Вводим команду на установка нашего скомпилированного приложения install file:///tmp/org.eclipse.kura.example.ble.tisensortag-1.0.3-SNAPSHOT.jar и потом вводим для проверки ss. Видим установленный, но не запущенный bundle в конце: 75 INSTALLED org.eclipse.kura.example.ble.tisensortag.

Запустим командой start 75, где 75 — id приложения с предыдущего шага. Теперь он запущен: 75 ACTIVE org.eclipse.kura.example.ble.tisensortag и можно просмотреть логи на Raspberry PI: tail -f /var/log/kura.log [5].

В Kura web UI появился новый сервис BluetoohLe. Откроем и настроим его.

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

Настроим Kura:

• В CloudService установим encode.gzip в false
• В MqttDataTransport укажите broker-url, topic.context.account-name

Интеграция с помощью Camel и Web часть

Для быстрого запуска MongoDB + Mosquitto + Webview можно выполнить docker-compose up -d в корне проекта. Это создаст 3 контейнера и забиндит mqtt, websocket, http (8081) порты на localhost. Сразу после этого будет доступна веб часть по адресу http://localhost:8081. И mqtt broker на localhost:1883, поэтому можно будет указать в Kura MqttDataTransport ваш IP.

Пример веб части:

Camel интеграция

iot-backend-camel содержит Apache Camel проект, который подписывается к брокеру сообщений и получает KuraPayload.

EclipseKura сообщения передаются в закодированном формате Google Protobuf. Поэтому нам понадобится библиотека от Google для декодирования com.google.protobuf:protobuf-java.

Далее из сообщения достаются метрики, сериализуются в json и отправляются подписчикам веб части в брокер, а так же сохраняются в базу MongoDB.

Для запуска Camel приложения выполним: gradlew clean build и java -jar ./build/libs/iot-backend-camel-1.0.0-SNAPSHOT.jar.

Веб часть

webview содержит докер образ на основе nginx с html & js. Веб часть использует mqtt over websocket Paho библиотеку и highcharts для динамического отображения значения сенсоров (Температура с ИК сенсора и уровень освещения).

Сайт подписывается у брокера на обновления данных. Вероятно для работы, вам придется сменить mqtt хост в webview. Это можно сделать в webview/dist/view.js. В строке:

// Create a client instance
client = new Paho.MQTT.Client("localhost", Number(9001), "webview_" + parseInt(Math.random() * 1000000, 10));

Перезапустить webview можно с помощью docker-compose up -d --build. Это пересобирет docker образ и перезапустит, если он изменился.

Ссылки

1. http://eclipse.github.io/kura/doc/intro.html
2. https://mosquitto.org/2013/01/mosquitto-debian-repository/
3. http://blog.mrgibbs.io/bluez-5-39-ble-setup-on-the-raspberry-pi/
4. http://wiki.beyondlogic.org/index.php?title=Cross_Compiling_BlueZ_Bluetooth_tools_for_ARM
5. http://eclipse.github.io/kura/doc/deploying-bundles.html

https://habrahabr.ru/post/332428/

На данный момент существует не так много языков программирования, которые годятся для написания UWP приложений (UWP — Universal Windows Platform, или «Универсальная платформа Windows»), одинаково подходящих для запуска на десктопах, планшетах, смартфонах и других устройствах, работающих под управлением Windows 10.
Теперь язык программирования SPL, который я разрабатываю, также может использоваться для создания UWP приложений благодаря наличию SPL SDK. Расскажу об этом подробнее.

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

Можно было бы, конечно, ограничиться примером программы всего в одну строчку:

#.output("Hello, world!")

но это было бы слишком просто :)

Приведенная ниже программа является простым браузером фрактала Мандельброта, навигация по которому осуществляется с помощью стандартных мультитачевых жестов перемещения и масштабирования. Также в этом примере показана возможность выполнения задач в параллельных потоках, работа закадрового буфера для графических функций и использование мультитачевых жестов для работы интерфейса программы. Этот пример специально не перегружен дополнительным функционалом, чтобы сосредоточиться на главном — продемонстрировать, как программа на SPL может стать самостоятельным UWP приложением, которое потом может быть загружено в магазин Microsoft Store.

Текст программы браузера фрактала:

w,h = #.scrsize()
sfx = -2.5; sfy = -2*h/w; sfs = 4
#.aaoff()
:again
end,redo,update = 0
-> draw() 'посчитаем фрактал в отдельном потоке

>
  moved = 0
  > #.pan() 'мультитач навигация
    moved = 1
    x,y,s = #.pan(3)
    x -= (s-1)/2*w
    y -= (s-1)/2*h
    #.drawoff(x,y,s)
  <
  ? moved 'пересчитаем фрактал заново
    sfs /= s
    sfx -= x*sfs/w
    sfy -= y*sfs/w
    again -> end
    redo = 1
  .
  ? update & !redo 'отобразим фрактал
    update = 0
    #.drawoff(0,0)
  .
  wn,hn = #.scrsize()
  ? wn!=w | hn!=h 'изменился размер экрана
    w = wn; h = hn
    again -> end
    redo = 1
  .
<

draw()=
  :loop
  #.offon() 'рисуем в закадровом буфере
  #.scrclear(0,0,0)
  .redo = 0
  sfx = .sfx; sfy = .sfy; fs = .sfs/.w
  > y, 1...h
    > x, 1...w
      fx = sfx + x*fs
      fy = sfy + y*fs
      #.drawpoint(x,y,color(fx,fy):3)
    <
    loop -> .redo
    .update = 1
  <
  .end = 1
.

color(x,y)=
  zr = x; zi = y; n = 0
  maxn = #.int(200*(1-#.log10(.sfs/4)))
  > zr*zr+zi*zi<4 & ncode>

Теперь разберем подробнее этот пример.

w,h = #.scrsize()
sfx = -2.5; sfy = -2*h/w; sfs = 4
#.aaoff()
:again
end,redo,update = 0
-> draw() 'посчитаем фрактал в отдельном потоке

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

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

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

moved = 0
> #.pan() 'мультитач навигация
  moved = 1
  x,y,s = #.pan(3)
  x -= (s-1)/2*w
  y -= (s-1)/2*h
  #.drawoff(x,y,s)
<

Этот цикл включается и работает, если пользователь совершает мультитачевый жест. Во второй строке условием работы цикла является индикатор работы мультитача. В четвертой строке мы получаем параметры мультитачевого жеста — координаты смещения и масштаб. Затем функцией #.drawoff отображаем закадровый буфер с нарисованным в нем фракталом таким образом, чтобы картинка соответствовала текущему смещению и масштабу мультитача. Таким образом получаем интерактивную навигацию по фракталу.

? moved 'пересчитаем фрактал заново
  sfs /= s
  sfx -= x*sfs/w
  sfy -= y*sfs/w
  again -> end
  redo = 1
.

Здесь срабатывает условие, если пользователь только что закончил жест навигации. Пересчитываются новые параметры фрактала: масштаб sfs и координаты sfx,sfy. В пятой строке программа идет на метку again, чтобы заново запустить расчет фрактала, если он уже успел завершиться, то есть переменная end не равна нулю. Если же фрактал еще считается, то он просто отправляется на пересчет благодаря установке переменной redo в 1.

? update & !redo 'отобразим фрактал
  update = 0
  #.drawoff(0,0)
.

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

wn,hn = #.scrsize()
? wn!=w | hn!=h 'изменился размер экрана
  w = wn; h = hn
  again -> end
  redo = 1
.

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

draw()=
  :loop
  #.offon() 'рисуем в закадровом буфере
  #.scrclear(0,0,0)
  .redo = 0
  sfx = .sfx; sfy = .sfy; fs = .sfs/.w
  > y, 1...h
    > x, 1...w
      fx = sfx + x*fs
      fy = sfy + y*fs
      #.drawpoint(x,y,color(fx,fy):3)
    <
    loop -> .redo
    .update = 1
  <
  .end = 1
.

Это основной цикл рисования фрактала. В третьей строке поток графических команд перенаправлется в закадровый буфер, чтобы потом именно оттуда отображать фрактал с учетом его текущего смещения и масштаба при интерактивной навигации. Как видно из этого примера, работа с графикой безопасна для многопоточных расчетов в SPL.
Основной функцией рисования здесь является функция #.drawpoint, которая в качестве аргумента цвета принимает три переданных значения из функции color.
Далее мы видим, что расчет начинается заново путем перехода на метку loop, если глобальная переменная .redo не ноль.
Далее, устанавливая значение глобальной переменной .update в единицу, мы указываем основному потоку, что уже есть, что нового можно отобразить во фрактале.
Если расчет фрактала закончился, то значение глобальной переменной .end устанавливается равной единице. Зная это, при необходимости пересчета фрактала мы заново запустим поток расчета фрактала.

color(x,y)=
  zr = x; zi = y; n = 0
  maxn = #.int(200*(1-#.log10(.sfs/4)))
  > zr*zr+zi*zi<4 & ncode>

Это последняя функция в нашем примере, она выполняет самое важное — возвращает цвет фрактала в каждой точке экрана. В качестве входных параметров x,y функция color принимает координаты точки во фрактале.
Далее в цикле идет расчет фрактала Мандельброта, а в последних двух строках функции возвращается цвет точки в зависимости от полученного расчета фрактала — либо 0,0,0, если фрактал так и не вышел за установленный лимит maxn, либо цвет из цветового пространства HSV в соответствии с полученным значением фрактала.

Здесь лирическая часть статьи заканчивается и переходим к технической части.
Сделаем из программы на SPL самостоятельное UWP приложение.
Дело в том, что интерпретатор языка SPL сначала генерирует промежуточный бинарный код, а потом уже выполняет его. Это все происходит «за кадром» и пользователь может даже не иметь понятия о существовании этого промежуточного кода — файла COD. Но, включив соответствующую опцию в программе, этот COD файл можно увидеть и скопировать из SPL. После чего берем SPL SDK, выполненный в виде уже готового проекта Visual Studio 2017, и копируем в него этот COD файл в виде ресурса.



Затем указываем имя программы в первой строке. В нашем случае это «fractal.txt». Расширение COD-файла .cod указывать не нужно.



Сам же SPL SDK представляет собой просто «выполнитель» COD-файлов, который автоматически при старте запустит вашу программу на SPL.
В общем-то, это все. Самостоятельное UWP приложение готово! Теперь его можно компилировать и запускать на любом устройстве на Windows 10. При желании можно отправить это приложение в Microsoft Store.

Сейчас язык программирования SPL находится в стадии активной разработки. Назначение языка SPL (Simple Programming Language) — любительское программирование в качестве хобби. SPL — это язык программирования, который придумал и разрабатываю лично я. Также «SPL» — это мое приложение для Windows 10, которое сейчас находится в стадии закрытой беты. Те пользователи, которых интересует язык программирования SPL и кто хотел бы принять участие в его развитии с помощью тестирования, а также своими предложениями — добро пожаловать на сайт языка SPL. Там вы найдете документацию по SPL и другую полезную информацию.

Всем упехов в программировании!

https://habrahabr.ru/post/332418/

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

Интересно будет тем, кто ищет новые способы проведения ретроспектив, кто интересуется командной работой, подходами к принятию решений и генерации идей.

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

Вместо вступления

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

Что такое метод шести шляп

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

Метод шести шляп — это метод организации мышления, один и популярных способов проведения мозгового штурма.

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

Круто, а как это поможет при проведении ретроспективы?

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

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

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



Всё это — основные цели проведения ретроспективы (взято отсюда).

Ну а метод шести шляп — это то, что поможет этой цели достигнуть, и тут самое время объяснить команде, что это такое — этот метод, и зачем оно нам нужно. Здесь, я думаю, достаточно ограничиться сжатым объяснением на минуты 4 с краткими простыми примерами (понятнее, чем при непосредственном погружении в ретроспективу по методу шести шляп, всё равно на этом этапе сделать не получится). Чтобы информация не потерялась в головах и дальше не тратилось время на вопросы, можно повесить перед глазами простую шпаргалку, например:



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

Синяя шляпа = управление

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

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

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

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

Белая шляпа = информция и факты

Здесь каждый озвучивает факты о текущем спринте, например:

• Мы не успели сделать такую-то и такую-то задачи,
• Показ прошёл хорошо, заказчик остался доволен,
• Коля (Петя, Каюм) был перекинут на фронтэнд, т.к. ребята не успевали.

Факты должны быть объективные, могут быть как положительные, так и негативные — важно отделять их друг от друга.

Красная шляпа = эмоции и чувства

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

Критическое суждение

Тут можно бросить взор на уже зафиксированные факты и критиковать их (объективно критиковать). Например,

• Если бы при планировании задач были учтены навыки исполнителей, то мы бы не потратили время на попытки обучить Петю работе с системой сборки,
• Если бы качество юзкейсов было выше, то не было бы потрачено столько времени на попытки разобраться (при этом должно быть обозначено, что такое «качество юзкейсов выше»!),

и т.д.

Жёлтая шляпа = оптимистичность

В этой шляпе мы выделяем позитивные моменты: что было хорошего в спринте («По итогу спринта команда отлично сработалась», «Петя, оказывается, крутой фронтенщик! Очень помог нам с такой-то задачей», «Показ прошёл здорово, мы молодцы»), что будет хорошего («С таким фронтенщиком как Петя...» — ну вы поняли).

Зелёная шляпа = креативность

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

Подведение итогов

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

Вместо заключения

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

P.S. То, как это выглядело у нас:

https://habrahabr.ru/post/332264/

Вот что строил испанский архитектор Антонио Гауди:



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



Это два крепления. Первое производится серийно — оно просто в проектировании, просто в изготовлении, дёшево и невероятно уродливо. Второе красивое, и требует на 25% меньше материала для того, чтобы выдержать тот же вес (то есть — куда прочнее). Только его трудно рассчитать, оно будет дороже в серии — и придётся подумать.

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

Начнём с нагрузок на несущие конструкции здания

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



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







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


Фасад дома Мила, я знаю, архитекторы убьют меня за такую съёмку

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

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

Материал диктует вам форму зданий. Всё ваше образование говорит вам, что есть определённые практики расчётов, и нужно пользоваться ими. Есть проработанные веками оптимальные формы. А потом наступает самое интересное. Появляется ограничение в задаче. У вас есть заданный бюджет, и в рамках этого бюджета вам нужно спроектировать здание, внутри которого будет свободная планировка. Потому что богатая буржуазная чета Мила заказала себе дом на главной улице Барселоны. Они хотят несколько собственных помещений — и что-то вроде отеля во всём остальном доме. Это нормальная практика в те годы — каждый дом строился как самообеспечивающийся проект. Все затраты на поддержание дома окупались тем, что часть «квартир» (или этажей) сдавалась жильцам на долгие годы. Техническая сложность была в том, что каждый жилец делал под себя довольно серьёзный ремонт.

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

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

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

Вот, смотрите: арки чердачных помещений дома Батло:



Они сделаны из кирпича — невероятно дёшевы, невероятно (по тем временам) прочны, идеально рассчитаны. А вот прототип из мира живой природы, конструкция, которая отточена тысячелетиями непрерывной оптимизации:





И вот невероятно красивое решение по свету — арки чердака дома Мила:



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

Эргономика

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

• Или в неомодерн (Гауди, эстетика, биоформы и эргономика)
• Или в конструктивизим (Баухаус и ВХУТЕМАС, линейные формы для серийного производства, минимализм).

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

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



Или вот посмотрите на двери:


Позже он улучшил и смотровое отверстие, сделав его похожим на глаз мухи

Здесь нас интересует форма ручки (за неё чертовски удобно браться), глазок, метка с «номером» квартиры. Сейчас эти смотровые отверстия стали уже частью современной культуры Каталонии (я нашёл эту дверь районе Монжуик):


В центр этих «глазков» иногда монтируют маленькую камеру.

Вот ещё его двери и мебель:



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

А вот фурнитура поближе: всё рассчитано под руку:





Ни одной прямой линии при потрясающем удобстве:



Очень интересное у него было управление светом:





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

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

Проект-менеджмент

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



Позже Антонио использовал похожую методику для украшения объектов на крышах зданий:


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

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

Там же в парке Гуэль у него случился первый опыт краудсорсинга. Нужно было выложить мозаикой бортик над рыночной площадью. Не было ни бюджета, ни людей, ни понимания, как сделать всё красиво — то есть схемы. Гауди предложил следующее: каждый рабочий берёт битую керамику (облицовку зданий) и выкладывает свой собственный узор, который кажется ему наиболее интересным на своём участке. Рабочие с огромным энтузиазмом взялись за это дело — архитектор впервые позволил сделать что-то своё, без надзора, и это был бы очень крутой след каждого в нашумевшем проекте. В результате почти бесплатно (за 1/10 от возможного бюджета) и очень быстро был получен крутейший результат. Счастливы были все стороны.

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

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

1. Понял условности текущих методов архитектуры.
2. Разработал свой собственный подход начиная от матаппарата
3. Реализовал всё это в виде зданий, вошедших в культурное достояние человечества.
4. Попутно совершил революцию в архитектуре, эргономике и городском строительстве.
5. Не поругался с городом — его даже звали строить храмовые объекты (самый известный — недостроенная Саграда Фамилиа, Семейный собор Барселоны).

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

https://habrahabr.ru/post/331802/

Привет всем! Сегодня мы публикуем видеозаписи с митапа для профессионалов Data Science, который прошел в нашем московском офисе 24 июня. Под катом — доклады о построении рекомендательных систем от специалистов из Яндекс.Дзена, OZON.ru и Avito, а также подробные описания решений финалистов нашего конкурса, который прошел на площадке Dataring.ru. И, конечно, награждение его победителей!

Машинное обучение в Дзене

Евгений Соколов и Дмитрий Ушанов рассказали нам об основных типах сигналов, которые они используют в рекомендательных алгоритмах, сложностях масштабирования Яндекс.Дзена и о нюансах работы с контентом (классификация, оценка, метрики). Как совместить явный и неявный фидбэк от пользователей, получить хорошие масштабируемые факторы, сопоставить контентную и кликовую информацию — смотрите в видео.

Рекомендации в OZON.ru

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

Какие задачи решает команда рекомендаций в Avito

В своем докладе Василий Лексин, лидер юнита рекомендаций Avito, рассказывает о задачах, с которыми сталкивается его команда, о видах рекомендаций, необходимых для нашего сервиса и подходах, которые используются для их построения.
Также в этом видео — рассказ о том, как команда Avito принимала участие в конкурсе RecSys Challenge 2017. Мы решали задачу холодного старта рекомендательного сервиса по поиску работы и пробовали параллельно два подхода: контентный и более общий, основанный на матричной факторизации.

Об опыте участия в RecSys Challenge 2017 также очень подробно рассказал на тренировке по машинному обучению в Яндексе другой наш коллега, Андрей Остапец. Его доклад начинается с 17:50.

Итоги конкурса Avito по построению рекомендательной системы

24 июня мы наградили победителей конкурса, который прошел на площадке Dataring.ru. Михаил Каменщиков подробно рассказал о задаче соревнования, данных, которые были предоставлены участникам и выборе метрики качества. А также подвел статистику и итоги конкурса. А финалисты соревнования подготовили доклады о своих решениях. Смотрите видео!

Спасибо всем, кто пришел на митап! Плейлист целиком доступен по ссылке. Для тех, кто не любит смотреть видео, мы выложили слайды. Фотоотчет опубликован на нашей странице в Facebook, отмечайте себя и знакомых!
Приглашаем на следующие встречи для профессионалов. Ищите анонсы мероприятий в Facebook AvitoTech, Twitter и Telegram.

https://habrahabr.ru/post/332408/

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

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

Функция вычисления факториала и кэширование

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

Например, вот функция factorial, которая вычисляет и возвращает факториал числа. Если не вдаваться в детали её реализации, выглядеть она будет так:

function factorial(n) {
    // Вычисления: n * (n-1) * (n-2) * ... (2) * (1)
    return factorial
}

Вызовем её следующим образом: factorial(50). Она, как и ожидается, найдёт и возвратит факториал числа 50. Всё это хорошо, но давайте теперь найдём с её помощью факториал числа 51. Компьютер снова выполнит вычисления, и то, что нам надо, будет найдено. Однако, можно заметить, что, при повторном вызове, функция выполняет массу вычислений, которые уже были выполнены ранее. Попытаемся функцию оптимизировать. Подумаем, как, имея значение factorial(50) перейти к factorial(51) без повторного вызова функции. Если следовать формуле вычисления факториала, окажется, что factorial(51) это то же самое, что и factorial(50) * 51.

При подобном подходе, однако, выигрыша в производительности получить не удастся. А именно, сначала, внутри функции factorial() производится полная цепочка вычислений для нахождения факториала 50, а потом то, что получилось, умножается на 51. То есть, при использовании подобной функции, вычисление факториала для числа 51 в любом случае выглядит как перемножение всех чисел от 1 до 51.

Хорошо было бы, если бы функция factorial() умела запоминать результаты вычислений, выполненных при её предыдущих вызовах и использовать их при следующих вызовах для ускорения производительности.

Основы мемоизации

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

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

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

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

// простая функция, прибавляющая 10 к переданному ей числу
const add = (n) => (n + 10);
add(9);
// аналогичная функция с мемоизацией
const memoizedAdd = () => {
  let cache = {};
  return (n) => {
    if (n in cache) {
      console.log('Fetching from cache');
      return cache[n];
    }
    else {
      console.log('Calculating result');
      let result = n + 10;
      cache[n] = result;
      return result;
    }
  }
}
// эту функцию возвратит memoizedAdd
const newAdd = memoizedAdd();
console.log(newAdd(9)); // вычислено
console.log(newAdd(9)); // взято из кэша

Анализ кода функции с мемоизацией

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

• Функция memoizeAdd возвращает другую функцию, которую мы можем вызвать тогда, когда нужно. Такое возможно потому что функции в JavaScript — это объекты первого класса, что позволяет использовать их как функции высшего порядка и возвращать из них другие функции.
  
  
• Переменная cache может хранить данные между вызовами функции, так как она определена в замыкании.
  
  
• Важно то, что функция с мемоизацией — это чистая функция. Эта функция, в частности, возвращает одно и то же для одних и тех же переданных ей аргументов независимо от того, сколько раз до этого её вызывали. Поэтому переменная cache ведёт себя именно так, как ожидается.
  

Написание функции с мемоизацией

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

// простая чистая функция, которая возвращает сумму аргумента и 10
const add = (n) => (n + 10);
console.log('Simple call', add(3));
// простая функция, принимающая другую функцию и
// возвращающая её же, но с мемоизацией
const memoize = (fn) => {
  let cache = {};
  return (...args) => {
    let n = args[0];  // тут работаем с единственным аргументом
    if (n in cache) {
      console.log('Fetching from cache');
      return cache[n];
    }
    else {
      console.log('Calculating result');
      let result = fn(n);
      cache[n] = result;
      return result;
    }
  }
}
// создание функции с мемоизацией из чистой функции 'add'
const memoizedAdd = memoize(add);
console.log(memoizedAdd(3));  // вычислено
console.log(memoizedAdd(3));  // взято из кэша
console.log(memoizedAdd(4));  // вычислено
console.log(memoizedAdd(4));  // взято из кэша

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

Подобное можно написать самостоятельно, но существуют и библиотечные решения:

• В Lodash имеется функция _.memoize(func, [resolver])
  
  
• В ES7 можно воспользоваться декораторами @memoize из decko.
  

Мемоизация рекурсивных функций

Если попытаться передать рекурсивную функцию рассмотренной выше функции memoize, или функции _.memoize из Lodash, то, что получится, будет работать неправильно, так как рекурсивные функции вызывают сами себя, а не то, что получается после добавления возможностей по мемоизации. Как результат, переменная cache в такой ситуации не выполняет своего назначения. Для того, чтобы решить эту проблему, рекурсивная функция должна вызывать свой вариант с мемоизацией. Вот как можно добавить мемоизацию в рекурсивную функцию вычисления факториала. Код, как обычно, можно найти на CodePen.

// уже знакомая нам функция memoize
const memoize = (fn) => {
  let cache = {};
  return (...args) => {
    let n = args[0];
    if (n in cache) {
      console.log('Fetching from cache', n);
      return cache[n];
    }
    else {
      console.log('Calculating result', n);
      let result = fn(n);
      cache[n] = result;
      return result;
    }
  }
}
const factorial = memoize(
  (x) => {
    if (x === 0) {
      return 1;
    }
    else {
      return x * factorial(x - 1);
    }
  }
);
console.log(factorial(5)); // вычислено
console.log(factorial(6)); // вычислено для 6, но для предыдущих значений взято из кэша

Проанализировав этот код, можно сделать следующие выводы:

• Функция factorial рекурсивно вызывает свою версию с мемоизацией.
  
• Функция с мемоизацией кэширует результаты вычисления факториала, что, при её последующих вызовах, значительно улучшает производительность. То есть, в вышеприведённом примере оказывается, что вместо перемножения чисел от 1 до 6 для нахождения факториала числа 6, на 6 придётся умножить лишь то, что было возвращено предыдущим вызовом factorial(5).
  

О мемоизации и кэшировании

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

Итоги: когда стоит прибегать к мемоизации

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

• Для того, чтобы функцию можно было подвергнуть мемоизации, она должна быть чистой, всегда возвращать одни и те же значения в ответ на одни и те же аргументы.
  
  
• Мемоизация — это компромисс между производительностью и потреблением памяти. Мемоизация хороша для функций, имеющих сравнительно небольшой диапазон входных значений, что позволяет достаточно часто, при повторных вызовах функций, задействовать значения, найденные ранее, не тратя на хранение данных слишком много памяти.
  
  
• Может показаться, что собственные реализации мемоизации стоит применять, например, при обращениях к неким API из браузерного кода. Однако, делать этого не нужно, так как браузер автоматически кэширует их, используя, в частности, HTTP-кэш.
  
  
• Если вы работаете с React/Redux, можете взглянуть на reselect. Тут используется селектор с мемоизацией. Это позволяет выполнять вычисления только в том случае, если в соответствующей части дерева состояний произошли изменения.
  
  
• Пожалуй, лучше всего функции с мемоизацией показывают себя там, где выполняются сложные, ресурсоёмкие вычисления. Здесь данная техника может значительно повысить производительность решения. Надо отметить, что нечто вроде вычисления факториала или чисел Фибоначчи — это хорошие учебные примеры, но в реальном мире всё гораздо интереснее и сложнее.
  

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

https://habrahabr.ru/post/332384/

Месяц назад на Hacker News в топ вышел пост про сервис AnyRoom: простенький бэкенд на Go, который позволяет создавать телефонные конференции. Рейтинг больше ста, обсуждения в комментах, Исходный код на github, подписки по 50 долларов в месяц — в общем, всё как у взрослых. После первого удивления «неужели это кому-то нужно?!?» я немного погуглил «голосовая конференция без регистраций и sms недорого», подивился дороговизне приложений и понял что таки да, нужно. А на Voximplant такую штуку можно собрать за полчаса и десяток строк JavaScript-кода. Кто хочет создать стартап и попиариться на Hacker News? Под катом рассказываю, как.

Как работает AnyRoom?

На Go и Twilio. С точки зрения пользователя это выглядит следующим образом: организатор конференции рассылает участникам номер телефона (он один на весь сервис) и несколько цифр номера конференции. Все участники звонят, вводят номер конференции — и могут общаться друг с другом. Как скайп, только работает. Под капотом бэкенд на Go общается с Twilio HTTP-запросами и передает XML'ки, объясняющие, что делать со звонками.

Как это повторить на Voximplant?

У нашего облака есть «изюминка». Логика работы со звонками задается JavaScript-кодом, который выполняется параллельно со звонком. Нет задержек общения с бэкендом, да и сам бэкенд для большинства сценариев не нужен: JavaScript можно написать в нашем Web IDE и отладить в Web Debugger (да-да, вы звоните на номер или облако само звонит, куда скажете, после чего можно прямо в браузере пошагово ходить по JavaScript и смотреть, что происходит со звонками). А можно загрузить по HTTP API, например из GitLab в рамках Continuous Integration.

Чтобы повторить AnyRoom в минимальной версии, достаточно привязать к номеру телефона JavaScript-сценарий, который сделает следующее:

• Примет звонок (специфика телефонии, пока не сделано answer, звонок не тарифицируется и можно, например, играть в него мелодию ожидания. А вот получить из него голосовой поток никто не даст).
• Синтезирует приветствие и предлагает ввести код конференции.
• Считывает цифры, которые пользователь нажимает на клавиатуре (она называются DTMF или «донабор»).
• По нажатию на что-нибудь специальное, например, решетку, отправляет пользователя в конференцию с именем, состоящим из введенных цифр.

Такая реализация будет тем самым MVP: пользоваться уже можно, но есть большой простор для улучшений. Что будет, если два пользователя хотят разные конференции, но придумают один и тот же номер, например «111»? Веб-интерфейс с генератором номеров конференций не помешает. А реализуется MVP вот таким сценарием, который можно привязать как к арендованному на Voximplant номеру (пишите в личку, я пополню баланс, чтобы вы могли поэкспериментировать) либо к отладочному номеру в Готем-Сити, аренда которого стоит один цент в месяц и позволяет тестировать входящие звонки без трат на номер:


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

Правило входящего звонка должно содержать регулярное выражение 'conf_.*' для срабатывания только на звонки в конференцию. Это правило нужно расположить перед правилом для входящих звонков, которое срабатывает вообще не все звонки:


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

Что можно сделать лучше?

Как я уже писал, это очень простой клон популярного сервиса. Нелишним будет веб-интерфейс для генерации ID конференции, возможность позвонить с веб сайта (у нас есть Web SDK), мобильное приложение (у нас есть Android и iOS SDK), проигрывание музыки в конференции (через объект Player), синтез приветствия, информирование о подключившихся и отключившихся пользователях, интеграция оплаты (через HTTP API) и многое другое.

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

https://habrahabr.ru/post/332206/

Что такое DDoS-атаки – сегодня знают, кажется, даже весьма далёкие от IT-сферы люди. На случай, если на Хабр вдруг попал человек, ничего об этом не слышавший, всё же скажем пару слов о базовом. Итак, DDoS – это Distributed Denial of Service, «распределенный отказ в обслуживании»: большое количество машин, заражённых вредоносным ПО, одновременно начинает отправлять на сервер запросы.

В итоге сервер, разумеется, «падает». Техника атаки достаточно проста, и весьма эффективна – так что пользуются ею все, от простых «киберхулиганов», которым по каким-то причинам не нравится атакуемый сайт, до правительств государств с серьёзными политическими целями. А уж в России, где борьба с киберпреступностью ведётся весьма вяло, практика и вовсе широко распространена.
Заказать подобную атаку на конкурента – проще простого, вы легко можете убедиться в этом сами. По запросу «заказать DDoS» любой поисковик выдаст сотни ссылок – и среди них будет полно самых настоящих киберпреступников, которые действительно оказывают подобную услугу.
К чему же мы обо всём этом говорим?

Дата-центры также под угрозой

---

К тому, что хорошая защита от DDoS-атак в наше время – значимый критерий при выборе ЦОД. Этому есть две причины.
Во-первых, при достаточно мощной, хорошо организованной DDoS-атаке, сервер может получить нагрузку в несколько сотен Гбит/с (зафиксированы атаки в 300 Гбит/с и выше) – далеко не всякий дата-центр выдержит подобное. Во-вторых, всё чаще атакуют не отдельные сайты, а именно целые ЦОДы. Примерно 2/3 дата-центров подвергаются атакам с целью «забивания» их каналов связи.
А для крупных крупных ЦОД отражение попыток их «заddosить» уже превратилось в рутину – и, при этом, далеко не все центры научились с ними бороться. Примерно пятая часть случаев отключения ЦОД – это именно последствия DDoS, причём «поднять» центр после этого – сложнее, чем при каком-то ином сбое.
Скорее всего, количество подобных происшествий будет только увеличиваться. Далеко не все компании скрывают информацию о том, в каких дата-центрах распложены их серверы, а атаковать целый ЦОД технически не сложнее, чем конкретный ресурс.
Словом, даже если вы не ожидаете никакой атаки именно на ваш сервер (что, как мы уже выяснили, довольно самонадеянно), то всё равно можете стать жертвой DDoS. Но уже вместе с тысячами людей и организаций, которые пользуются услугами вашего дата-центра. Просто потому, что кто-то из «соседей» кому-то насолил.
Так что очень важно, насколько дата-центр защищён от DDoS-атак. Мы, в ЦОД «Контел», это отлично понимаем – и стараемся принимать все меры к предотвращению проблем (устранять которые после возникновения уже много тяжелее).
Как же сегодня защищают дата-центры?

Как мы защищаемся от DDoS?

---

Как водится, средства защиты от DDoS в тех ЦОДах, что хорошо о ней позаботились (вроде нашего), используются и программные, и аппаратные. Мы, конечно, говорим не только о банальных вещах, вроде той защиты, что реализована Microsoft в IIS.
Прекрасные комплексные решения для защиты как отдельных серверов, так и целых ЦОД от DDoS создаёт компания Cisco. Тут речь идёт о именно о программно-аппаратном комплексе. В первую очередь, работает Cisco Traffic Anomaly Detector – идёт пассивный мониторинг трафика, не вредящий производительности. Но зато позволяющий вовремя распознать начинающуюся атаку, и передать на Cisco Guard «сигнал тревоги».
Cisco Guard работает не «внешнем периметре» — устройство ставится на вышестоящем отрезке того пути, что проходит трафик. Кстати, сигнал от атаке необязательно должен поступать именно от Anomaly Detector – какой-то детектор вторжений, или даже обычный межсетевой экран тоже могут передать эту информацию. Поскольку Cisco Guard использует отдельный сетевой интерфейс, то его работа по «фильтрации» трафика во время DDoS не мешает остальным системам.
Cisco Guard на MVP-архитектуре, кстати, успешно масштабируются – так что это именно тот случай, когда можно создать оборону, явно превосходящую возможности атакующих. При этом, как выражается сама компания, защита осуществляется «с хирургической точностью» — то есть, Cisco подвергает тщательному анализу и фильтрации именно подозрительный трафик, а «нормальный» при этом продолжает совершенно свободное движение.
Но, конечно же, Cisco не является монополистом в сфере программно-аппаратной защиты ЦОД от DDoS-атак. Такие системы разрабатываются и в России (где, как мы уже отмечали выше, проблема DDoS стоит достаточно остро). Хороший пример тут – система «Периметр», но углубляться в её сравнение с продуктами Cisco мы не станем.

А что посоветовать пользователю?

---

Ну, помимо очевидного «положитесь на надёжность наших услуг»?.. К примеру, может посоветовать отказаться от Windows Server и Apache. Сетевой экран «винды», мягко говоря, не очень хорошо справляется с подобными нагрузками. А что до Apache, то на уровне самой архитектуры кода он имеет ряд уязвимостей, которые успешно эксплуатируются годами – несмотря на любые патчи.
Ну, а главное – не бояться. Рано или поздно, с DDoS столкнётся практически каждый. Важно подготовиться к данной неприятности – практически неизбежной, чтобы свести возможные потери к минимуму. Мы поступаем именно так, и всем советуем.

Ну и как всегда немного вкусных дедиков с уже включенной защитой от DDOS
Заказать сервер с защитой от 3200 руб

https://habrahabr.ru/post/332406/

По данным PassMark, AMD смогли «отвоевать» 10,4% рынка CPU во втором квартале 2017 года. Это самый крупный прирост доли рынка x86 CPU, который испытывала компания за все время.

/ фото halfrain CC

В первом квартале 2017 года компания смогла нарастить долю лишь на 2,2%. В основном это связано с тем, что на рынке была доступна только половина наименований AMD Ryzen. Запуск также «смазал» недостаток материнских плат AM4. Во втором квартале компания показала себя совершенно иначе: материнские платы стали доступнее, а также появились процессоры семейства Ryzen 7.

Доля AMD по итогам первого квартала составляла 20,6%, а к концу второго выросла до 31%. При этом в первом квартале прошлого года она была равна 18,1%. Доля Intel на текущий момент составляет 69%. В третьем квартале AMD планирует запустить ultra high-end линейку Threadripper и компоненты Ryzen для мобильных платформ, что, можно ожидать, приведет к дальнейшему росту показателей компании — сейчас количество пользователей AMD-процессоров достигло максимума за последние десять лет.

Доля рынка AMD и Intel (по данным PassMark)

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

Многие пользователи положительно оценивают работу, проведенную AMD, и считают, что прирост доли рынка полностью оправдан. Резиденты Reddit ожидают дальнейшего роста графика вверх, связывая его с грядущим выходом ноутбуков с гибридными процессорами на базе Zen/Vega.

Руководство компании AMD также настроено оптимистично и ожидает дальнейших положительных сдвигов. Марк Пейпермастер (Mark Papermaster) на конференции Bank of America Merrill Lynch 2017 заявил, что не видит причин, которые бы помешали AMD вернуть себе исторический максимум доли рынка CPU. По его словам, дальнейшему росту будут способствовать универсальность применения и покрытие процессорами Ryzen разных ценовых сегментов.

В сегменте серверных процессоров компания хочет увеличить свою долю до двузначного числа за пару лет. И сделать это с помощью процессоров EPYC, официально представленных двумя неделями ранее. Согласно внутренним тестам AMD, модели EPYC значительно быстрее моделей Intel Xeon поколения Broadwell EP. Так, 32-ядерная модель EPYC 7601 при работе с целочисленными значениями (тест SPEC) показала себя на 47% быстрее 22-ядерного Intel Broadwell на частоте 2,4/3,6 ГГц и на 75% быстрее при работе с числами с плавающей запятой. В AMD уверены, что новинки смогут отчасти противостоять процессорам Intel Xeon поколения Skylake, а не только Broadwell.

Отметим, что также AMD надеется вернуть себе исторический максимум и на «графическом поприще». Решение Polaris уже позволило AMD отвоевать у конкурентов 5% рынка, а после релиза карты Vega у компании будет шанс закрепиться в верхнем ценовом диапазоне.

P.S. Еще несколько материалов из Первого блога о корпоративном IaaS:

• Оптимизация производительности в vSphere: решение основных проблем с CPU
• Оптимизация производительности в vSphere: решение основных проблем с CPU (часть 2)
• Почему результат тестирования скорости диска в ноутбуке может быть лучше, чем у промышленного сервера в облаке?
• Плюсы и минусы облачных сервисов в модели IaaS, PaaS, SaaS: мнение экспертов
• Как справиться с пиковыми нагрузками при помощи IaaS

https://habrahabr.ru/post/332394/

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




Маркетинговая стратегия стартапа

Когда: 6 июля
Где: онлайн-трансляция
Условия участия: бесплатно

Сэкономить хотят все, и стартаперы в первую очередь – на мастер-классе от агентства Qmarketing вы узнаете, как это провернуть без ущерба делу. Совладелец успешного стартапа Qlean предложит начинающим предпринимателям советы по построению маркетинговой стратегии и оптимизации расходов на базе собственного опыта. Разбирая все основные понятия – рынок и его ниши, конкуренты, целевая аудитория и ее проблема, стратегии позиционирования и каналы продвижения – спикер раскроет главный секрет: как сэкономить до 70% маркетингового бюджета на старте.

Интенсив по продвижению в Вконтакте

Когда: 8 – 9 июля
Где: Москва, Краснопролетарская ул., 16, подъезд №5, 4-й этаж
Условия участия: 15 800 руб.

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

Базовый курс по Интернет-маркетингу

Когда: 17 – 27 июля
Где: Санкт-Петербург, Караванная, 22, Санкт-Петербургский технический колледж управления и коммерции
Условия участия: 28 500 руб. (4500 за модуль)

Всеобъемлющий десятидневный курс разбит на восемь модулей продолжительностью в 1 – 2 дня, которые учащиеся могут отбирать и оплачивать по собственному усмотрению. Модуль «Продающий копирайтинг» посвящен текстовому наполнению и всему с ним связанному: читабельности и ее составляющим, грамотному структурированию текста, сильным заголовкам, умению зацепить читателя, истреблению слов-паразитов, адаптации текста под целевую аудиторию. На модуле SEO будут разобраны все этапы оптимизации площадки, от анализа и выявления ошибок до контентного аудита, от подбора ключевых слов до наращивания ссылочной массы. Модуль «Социальные медиа и нестандартные методы продвижения» предложит полный обзор возможностей продвижения в социальных сетях, включая рекомендации по конкретным площадкам. Отдельный модуль выделен для юзабилити, или человеко-ориентированного дизайна – его принципов, методов, существующих решений и кейсов, иллюстрирующих тезисы. Освоить техники продвижения можно на модулях практической направленности «Контекстная реклама» и «E-mail-маркетинг». Крупный модуль «Веб-аналитика» сочетает в себе теоретический материал (понятия конверсии, ROI, CLV, LTV, CAC и др) с обучением применению конкретных аналитических инструментов (Google Analytics, Яндекс.Метрика, Power BI, BigQuery) и составлению отчетов. Наконец, последний модуль рассматривает все частности работы с клиентской базой при помощи CRM-систем. Участники, благополучно прошедшие курс, получают сертификат и удостоверение о повышении квалификации, а также возможность пройти индивидуальную практику.

Семинар по GoogleAnalytics для руководителей

Когда: 19 июля
Где: Москва, Ленинградский проспект, 39с79, Mail.ru Group
Условия участия: 1000 руб.

Google Analytics давно уже стал частью того набора универсальных инструментов, который должен освоить каждый маркетолог и, как настаивают специалисты из «Мастерской интернет-маркетинга», любой человек, который оценивает результаты и выносит решения. Владеете им исключительно в теории? У вас есть шанс исправить положение. Тематический семинар в Mail.ru Group посвящен только и исключительно работе с Google Analytics, причем программа адаптирована под потребностей руководителя. Вы узнаете, куда в первую очередь смотреть в отчетах, какие данные считать надежными, что такое «воронка конверсий» и «узкие места» и, конечно, ответ на самый животрепещущий вопрос – окупает ли себя сайт. Теория на семинаре плавно переткает в практику: организаторы помогут слушателям сразу опробовать полученные знания на собственном проекте, чтобы закрепить навык и, не треяя времени, приступить к работе над продвижением.

Золотые правила создания успешных веб-сайтов

Когда: 19 июля
Где: Москва, Дружинниковская, 11/2
Условия участия: 1750 руб.

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

Технологии продвижения интернет-магазина: SEO, CPA, таргетинг, медийка, лидогенерация, автоматизация

Когда: 21 июля
Где: Екатеринбург, Малышева, 74
Условия участия: 7900 руб.

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

Делаем маркетинг лучше

Когда: 27 июля
Где: Санкт-Петербург, Казанская, 7, вход в бизнес-центр «Дворец кварнеги»
Условия участия: 1500 руб.

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

Бизнес-завтрак «Сайт как основной продавец»

Когда: 28 июля
Где: Санкт-Петербург, ул. Марата, 33, ресторан «Флагман»
Условия участия: бесплатно (требуется регистрация)

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

Курс по SMM: продвижение в социальных сетях

Когда: 31 июля
Где: Новосибирск, Николаева, 12, здание Технопарка
Условия участия: 18 000 руб.

По словам организаторов, данный курс охватывает сферу SMM настолько полно, что годится не только для тех, кто хочет подтянуть теорию, чтобы эффективно продвигать собственные проекты, но и для желающих с нуля освоить востребованную профессию. За 30 часов занятий слушатели продвинутся от азов (понятие SMM, виды соцсетей, выявление целевой аудитории и каналов, лидогенерация) к более частным аспектам продвижения (контент-маркетинг, управление репутацией, оптимизация бюджета), научатся пользоваться специальными инструментами продвижения, отслеживать KPI, запускать рекламные кампании и таргетинговую рекламу, узнают специфику самых популярных площадок (ВКонтакте, Facebook, Twitter, LinkedIn, Одноклассники, Instagram, Youtube, Геолокационные сети). К участию приглашаются все заинтересованные, вне зависимости от опыта и уровня подготовки; при успешном прохождении курса учащимся будут предложены бонусы для трудоустройства – сертификат и рекомендации от преподавателя.

https://habrahabr.ru/post/332398/

Представьте, что у вас есть хранилище данных с REST-интерфейсом. Пусть в нем хранится информация о книгах и вы хотите вывести список всех книг. Можно сделать метод «books», который будет возвращать нам список книг. Но при отображении списка обычно есть паджинация или ленивая подгрузка данных, а еще пользовать хочет фильтровать и сортировать данные. Когда мы добавляем поддержку мобильных устройств у нас появляется еще потребность как-то ограничить объем получаемых данных не передавая часть полей. Всю эту информацию должен уметь понимать почти любой метод получения списка объектов, т.к. списки отображаются с помощью специального виджета. И тут нам на помощь приходит Resource Query Language.

Resource Query Language (RQL) — это язык запросов, разработанный для использования в URI при работе с объекто-подобными структурами данных. С помощью RQL клиент может запрашивать у сервера список объектов соответствующих определенным правилам, т.е., по сути, это синтаксис, который описывает как запрашивать данные. Например, запрос выбирающий все книги авторства Перумова может быть записан как eq(author,Перумов) или в обычном формате URL: author=Перумов.

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

Как использовать RQL

RQL выражение содержит функции запроса или операторы сравнения, соединенные логическими операторами.

Типовые сценарии

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

Пусть у нас есть список книг:

[
{ title: "Эльфийский клинок", year: 1993, series: "Кольцо тьмы" },
{ title: "Чёрное копьё", year: 1993, series: "Кольцо тьмы" },
{ title: "Адамант Хенны", year: 1995, series: "Кольцо тьмы" },
{ title: "Воин Великой Тьмы", year: 1995, series: "Летописи Хьёрварда" }
]

Выведем все книги из серии «Кольцо тьмы». В MongoDB мы бы сделали это так:

db.users.find({series: "Кольцо тьмы"})

в RQL это будет выглядеть так:

eq(series, "Кольцо тьмы")

или

series="Кольцо тьмы"

Такой запрос вернет нам три книги.

Теперь более сложный запрос: нам надо вывести все книги серии «Кольцо тьмы» изданные в 1995 году.

В MongoDB:

db.users.find({series: "Кольцо тьмы", year: 1995})

В RQL:

eq(series, "Кольцо тьмы"),eq(year, 1995)

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

{ title: "Воин Великой Тьмы", year: 1995, series: "Летописи Хьёрварда", translations: { language: "English", title: "Godsdoom" } }

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

В MongoDB:

db.users.find({"translations.language": "English"})

В RQL:

eq(translations.language, "English")

Со временем наша библиотека выросла. Список книг не помещается на экран и мы решили показывать его постранично.

В MongoDB мы можем получить второй десяток записей следующим образом:

db.users.find().skip(10).limit(10)

В RQL:

limit(10,10)

Но показывать постранично мало. Еще хочется сортировать данные.

В MongoDB это будет:

db.users.find().sort({title: 1})

В RQL:

sort(+title) 

Функции

Базовые функции стандарта:

Функция	Описание	Примеры
in (,)	Выбирает объекты, у которых значение указанного свойства входит в заданный массив свойств.	in(name,(Silver,Gold))
out (,)	Выбирает объекты, у которых значение указанного свойства не входит в заданный массив свойств.	out(name,(Platinum,Gold))
limit (,)	Возвращает заданное количество (number) объектов начиная с определённой (start) позиции.	limit(0,2)
sort ()	Сортирует список объектов по заданным свойствам (количество свойств неограниченно). Сначала список сортируется по первому из заданных свойств, затем по второму, и так далее. Порядок сортировки определяется префиксом: + — по возрастанию, — — по убыванию.	sort(+hardware.memory,-hardware.diskspace)
select ()	Обрезает каждый объект до набора свойств, определенных в аргументах.	elect(name,hardware.memory,user) select(name,hardware.memory,user.fullName)
values()	Возвращает набор значений из указанного поля всех объектов	values(ve.name)
count()	Возвращает количество записей	in(name,(Silver,Gold))&count()
max()	Возвращает максимальное значение из указанного поля всех объектов	max(ve.memory)
min()	Возвращает минимальное значение из указанного поля всех объектов	min(ve.memory)

Больше существующих операторов можно найти в официальной документации (http://www.persvr.org/rql/).

В технологии APS в RQL добавлена новая функция:

Функция	Описание	Примеры
like (, )	Ищет заданный паттерн (pattern) в заданном свойстве (property). Эта функция аналогична оператору SQL LIKE, хоть и использует символ * вместо %. Чтобы определить в паттерне сам символ *, он должен быть процентно-кодированным, то есть надо писать %2A вместо *, см. примеры. Кроме того, в паттерне можно использовать символ ?, обозначающий, что любой символ в этой позиции является валидным.	like(firstName,Jo*) like(firstName,*ohn) like(firstName,*oh*) like(firstName,Joh?)

И еще три специфичные для APS функции:

Функция	Описание	Примеры
implementing ()	Возвращает список объектов (ресурсы и типы), реализующих базовый тип и включающих в себя сам базовый тип.	aps-standard.org/samples/user-mgmt/offer/1.0
composing ()	Возвращает список типов, которые реализованы производным типом (derived type), включая сам производный тип.	aps-standard.org/samples/user-mgmt/offer/1.0
linkedWith ()	Возвращает список ресурсов, которые связаны тем ресурсом, чей ID указан в качестве аргумента. APS-контроллер ищет все ссылки на ресурсы, включая внутренние системные ссылки. Например, актор admin/owner/referrer, имеющий доступ к ресурсу, тоже будет считаться «связанным» ресурсом.	linkedWith(220aa29a-4ff4-460b-963d-f4a3ba093a0a) implementing(http://aps-standard.org/types/core/user/service/1.0), linkedWith(220aa29a-4ff4-460b-963d-f4a3ba093a0a)

Логические операторы

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

Оператор	Алиас	Примеры	Значение
and (,,...)	& ,	and (http://aps-standard.org/samples/user-mgmt/offer),like(name,*L*)) implementing(http://aps-standard.org/samples/user-mgmt/offer)&like(name,*L*)) implementing(http://aps-standard.org/samples/user-mgmt/offer),like(name,*L*))	Выбирает все предложения (offers), имена которых соответствуют нечувствительному к регистру паттерну *L*
or (,,...)	| ;	implementing(http://aps-standard.org/samples/user-mgmt/offer1.0)&or(like(description,*free*),in(name,(Silver,Gold)))	Выбирает все предложения (offers), описания (description) которых соответствуют паттерну *free*, а также те, чьё имя Silver или Gold.

В технологии APS в RQL также добавлен новый логический оператор отрицания:

Оператор	Алиас	Примеры	Значение
not ()		implementing(http://aps-standard.org/samples/user-mgmt/offer),not(like(name,*free*))	Выбирает все предложения (offers), за исключением тех, чьё имя соответствует Хабр и Гиктаймс — RQL паттерну *free*.

Примечание

1. Оператор and является неявным RQL-оператором верхнего уровня. Например, выражение http://hosting.com?and(arg1,arg2,arg3) эквивалентно http://hosting.com?arg1,arg2,arg3.
2. У оператора and приоритет выше, чем у or. Поэтому при использовании алиасов нужно заключать объединённые запросы в круглые скобки, тем самым определяя необходимый порядок обработки. Например, implementing(),(prop1=eq=1|prop2=ge=2).

Операторы сравнения

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

Оператор	Алиас	Примеры	Значение
eq (,)	=eq=	eq(aps.status,aps:ready) aps.status=eq=aps:ready	Выбирает все объекты, чей aps.status имеет значение aps:ready.
ne (,)	=ne=	ne(aps.status,aps:ready) aps.status=ne=aps:ready	Выбирает все объекты, чей aps.status имеет значение aps:ready.
gt (,)	=gt=	implementing(http://aps-standard.org/samples/user-mgmt/offer),hardware.memory=gt=1024)	Выбирает все предложения (offers), предоставляющие hardware.memory больше 1024.
ge (,)	=ge=	implementing(http://aps-standard.org/samples/user-mgmt/offer),hardware.memory=ge=1024)	Выбирает все предложения (offers), предоставляющие hardware.memory больше или равно 1024.
lt (,)	=lt=	implementing(http://aps-standard.org/samples/user-mgmt/offer),hardware.CPU.number=lt=16)	Выбирает все предложения (offers), предоставляющие hardware.CPU.number меньше 16.
le (,)	=le=	implementing(http://aps-standard.org/samples/user-mgmt/offer),hardware.CPU.number=le=16)	Выбирает все предложения (offers), предоставляющие hardware.CPU.number меньше или равно 16.

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

Значения

Функции запросов и операторы сравнения могут содержать следующие значения:

• Строковые (с использованием URL-кодирования)
• Числа
• Даты (в формате ISO UTC без двоеточия)
• Булевы
• Функции-значения (Value functions)

Функции-значения — это функции, возвращающие особые значения вроде null, true, false или пустое строковое значение. Все они применимы к определённым типам данных.

Функция-значение	Применимые типы	Описания	Примеры
null()	Любой тип	Задаётся, если значение null	name=eq=null()
true() false()	Булевы	Задаётся, если значение true или false	disabled=eq=false()
empty()	Строковые	Задаётся, если строковое значение является пустым (не null, но не содержит никаких символов)	addressPostal.extendedAddress=eq=empty()

Использование

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

Реализация на JavaScript кроме парсера содержит еще и движок, который умеет применять RQL-запрос к массиву объектов.

Оригинальная реализация RQL на JavaScript есть в npmjs: https://www.npmjs.com/package/rql

Реализация с добавленной нами функциональностью также доступна через npm: https://www.npmjs.com/package/aps-rql

https://habrahabr.ru/post/331774/

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

Приключения с IPv6

Прежде всего скажу – ребята, я не понимаю, для чего нужен IPv6 на платформе, которая сама по себе никуда не привязана по этому самому протоколу и адреса она себе назначает какие хочет. Мы с коллегой решили – «нафига козе баян?» – и запретили IPv6. Основательно так запретили. В трёх местах, на уровне ядра и модулей. Заодно обновили софт до последней стабильной версии.

И тут упала у нас раздача адресов по DHCP. При этом, естественно, и пароли в новые машины перестали заводиться.

Что поменялось? Похоже, не запускается dnsmasq. Тогда я нашёл в бэкапах старые версии софта и подложил их. Но боже ж ты мой – всё равно не работает!

Что за чудеса? В логах много всего, но никаких конкретных указаний, что происходит. Начал шерстить все логи подряд, в том числе и системные. Случайно увидел, что на самом деле есть логи, говорящие что произошло – но они лежат вовсе не в /var/log, как можно было бы ожидать. Нет, их почему-то прячут в /var/lib/neutron/ha_confs и далее – в названии каталога участвует имя подсети. Там лежат сгенерированный нейтроном конфиг и логи запуска для keepalived. У нас же «устойчивая» конфигурация. Автоматом сгенерированный конфиг содержит IPv6 адреса. Демон keepalived не стартует – от системы он получает отбой. Мы же запретили IPv6? После этого уже не стартует на нужном адресе dnsmasq – потому что адреса нет, его должен был поднять keepalived. Пришлось вернуть обратно.

Вывод: Если мы запрещаем IPv6 на уровне ядра, то dnsmasq перестаёт запускаться.
Не запрещайте IPv6 в Openstack версии Mitaka!

Старая проблема

Но старая история продолжается.

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

Мы нашли относительно простой способ эту проблему обходить. Сейчас это делается отрыванием внутреннего IP адреса и назначением его из другой подсети – нам при этом приходится часто добавлять новые подсети. Проблема на какое-то время уходит. Часть машин при этом работают замечательно. Самые настоящие «танцы с бубном».

Новые горизонты

Недавно я доказал себе, что эта проблема – в глубине OpenStack. Мы сооружали новую платформу по образу и подобию старой, при этом на тестовых диапазонах. Всё работало шикарно при заведении до 300 машин в ферме, и при этом никаких сбоев!

Обрадовались и стали готовить её в «продакшн». Это подразумевало введение «рваных» диапазонов ip адресов – так получилось. Мы очистили ферму, убрав эти самые триста машин. И вдруг на трёх тестовых виртуалках случилось то же, что и на старой ферме – стали пропадать пакеты, в большом количестве. Похоже, дело в самой сетевой настройке OpenStack.

Да, да! Всё дело в настройке виртуального роутера. К великому сожалению, примеров нормального построения сети более чем для 20 виртуальных машин, в сети не отыскать. Так что, похоже, продолжение следует…

https://habrahabr.ru/post/332400/

Предупреждение: все прилетевшие тапочки будут проданы, помидоры – съедены, яйца – пожарены, испорченные – выброшены. Те, кто думают, что мы маемся фигней – вы угадали, возьмите с полки пирожок. Автор не призывает бросать мешки грудью на амбразуры. Он вообще ни к чему не призывает – он же не политик и не гражданин с активной гражданской позицией. А вот желающих подискутировать – милости просим. Сегодня я буду рассказывать вам занимательную историю о замене Teamviewer на UltraVNC.

Как это работает

Исходная архитектура VNC протокола слабо предназначена для работы через глобальные сети. Для этого есть несколько причин.

• Отсутствие шифрования передаваемых данных.
• Короткие пароли (8 символов в современном мире? Вы серьезно?)
• Отсутствие сквозной нумерации серверов, подключение по IP.
• Невозможность работы из-за NAT.

Я, конечно, перечислил не все. Но это основные недостатки, которые мешали нам рассматривать данное решение всерьез. В итоге, все они были тем или иным образом преодолены. Текущая схема работы выглядит примерно так:



Клиентский UltraVNC сервер подключается к нашему репитеру, который одним своим портом (нестандартным) смотрит в интернет и принимает подключения. А мы подключаемся к этому же серверу по внутреннему адресу изнутри и уже оттуда — к клиенту. Соединения шифруются RSA2048/AES256. Так как серверы и клиенты цепляются на разные порты, можно гибко ограничить, у кого и откуда есть право подключения, не трогая возможность UltraVNC-серверов подключаться к репитеру.

Установка UltraVNC репитера

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

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

sudo apt-get install build-essential

Создаем пользователя для запуска репитера.

sudo useradd -c 'UltraVNC Repeater User' -M -s /sbin/nologin uvncrep

Скачиваем исходники репитера.

wget http://www.wisdomsoftware.gr/download/uvncrep017-ws.tar.gz

Распаковываем репитер и заходим внутрь папки.

tar -xzvf uvncrep017-ws.tar.gz && cd uvncrep017-ws

Собираем репитер.

make

Устанавливаем репитер в систему.

sudo ./install.sh

У нас все готово к успешному запуску, но надо немного изменить файл настроек. Поэтому открываем в любимом редакторе /etc/uvnc/uvncrepeater.ini и приводим настройки к следующему виду:

viewerport = 5900

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

logginglevel = 2

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

allowedmodes = 2

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

useeventinterface = false

Отключаем отправку сообщений. Пока мы никому ничего отправлять не будем. Может быть потом…

Сохраняем файл и тестируем корректность его настроек.

sudo uvncrepeatersvc /etc/uvnc/uvncrepeater.ini

UltraVnc Linux Repeater version 0.17
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): viewerPort : 5900
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): serverPort : 5500
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): maxSessions: 100
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): loggingLevel: 2
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): ownIpAddress (0.0.0.0 = listen all interfaces) : 0.0.0.0
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): runAsUser (if started as root) : uvncrep
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): Mode 1 connections allowed : No
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): Mode 2 connections allowed : Yes
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): Mode 1 allowed server port (0=All) : 0
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): Mode 1 requires listed addresses : No
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): Mode 2 requires listed ID numbers : No
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): useEventInterface: false
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): eventListenerHost : localhost
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): eventListenerPort : 2002
UltraVnc Sat Feb 11 16:48:29 2017 > listInitializationValues(): useHttpForEventListener : true
UltraVnc Sat Feb 11 16:48:29 2017 > dropRootPrivileges(): privileges successfully dropped, now running as user uvncrep
UltraVnc Sat Feb 11 16:48:29 2017 > routeConnections(): starting select() loop, terminate with ctrl+c

Все в порядке, можно запускать как стандартную службу. Останавливаем репитер с помощью Ctrl+C и запускаем уже как сервис.

sudo systemctl start uvncrepeater

Проверяем, что служба запустилась.

$ ps ax | grep uvnc
11168 ?        S      0:00 /usr/sbin/uvncrepeatersvc /etc/uvnc/uvncrepeater.ini
11170 pts/0    S+     0:00 grep --color=auto uvnc

Файл лога можно посмотреть по адресу /var/log/uvncrepeater.log.

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

Итак, первое препятствие между нами и нирваной рухнуло с треском. Теперь мы можем подключаться к клиентам за NAT. На очереди два следующих – отсутствие сквозной нумерации и шифрования. Настраиваем тестовый UltraVNC-сервер. Так как у нас основной парк управляемых машин – это Windows, установка сервера и клиента будет расписана для них.

Скачиваем необходимые компоненты по ссылкам. Компоненты должны иметь архитектуру (x86 и x64), соответствующую архитектуре компьютера, на который происходит установка сервера.
СДЕЛАТЬ СПИСОК ИЕРАРХИЕЙ

• UltraVNC Server
• SecureVNC Plugin:
  
  • x86
  • x64
• Mirror Driver

Запускаем установщик UltraVNC сервер. Принимаем условия соглашения и нажимаем Next >.



Вчитываемся с интересом и Next >.



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



Выбираем установку только UltraVNC Server и нажимаем Next >.



Жмем Next > и никаких гвоздей.



Ставим указанные галочки, чтобы установить UltraVNC сервер как системную службу и запустить его сразу после установки. Жмем Next >.



Смотрим на этот экран с умным видом, потом нажимаем Install.



Здесь есть только одна кнопка для нажима. Жмем на нее.



Снимаем галочку, чтобы не смотреть какие-то последние версии, и жмем Finish.



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



Распаковываем папку с драйвером.



Заходим в папку с соответствующим драйвером и устанавливаем его путем запуска install.bat.

Внимание! Установку драйвера надо производить с административными правами. Причем запустить от имени администратора только install.bat не получится, потому что он запускает еще одну программу и она будет работать уже не от администратора. Поэтому запускаете консоль от администратора, идете в папку установки драйвера и запускаете install.bat оттуда.

Я выполнял тестовую сборку по XP с правами администратора, потому мне это не потребовалось.



Запускаем настройки VNC сервера – uvnc_settings.exe.



Переходим на вкладку Security.

• В разделе Authentication выставляем два пароля. Пароли должны быть одинаковыми, состоять из цифр и больших и малых латинских букв, не более 8 символов длиной.
• В разделе Encryption ставим галочку Use, выбираем из выпадающего списка наш плагин, и жмем на кнопку Configuration.

Галочки должны стоять так, как показано на скриншоте. Если все правильно, закрываем окно нажатием кнопки Close.



Переходим на вкладку Connection.

• В разделе Multiple connections выбираем Keep existing connections.
• В разделе Disconnect выбираем Do Nothing.

Переходим на вкладку Screen Capture.

• В разделе Advanced выбираем Use system hookdll, Use mirror driver, Remove Aero while connected и Remove wallpaper while connected.

Переходим на вкладку Misc/logging.

• В поле Service command line вбиваем самую главную строку. Эта строка содержит ID и адрес и данные репитера для подключения. Выглядит она так:

-autoreconnect ID:XXXXXXXX -connect :
ID получается с помощью скрипта по методике приведенной ниже.





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

Генерация уникального ID

Скрипт получения 8-значного номера ID. Написан на php, потому что это было проще всего. В качестве источника вдохновения использовались комментарии вот к этому вопросу. Как работает, думаю, пояснять не надо. Почему именно скрипт генерации и почему именно по MAC? Потому что репитер не даст подключиться двум серверам с одинаковым ID, а вести журналы со списками ID было предельно лень. А так как MAC-адреса и так уникальны, то почти гарантированно получаем уникальный номер с достаточно низкой вероятностью коллизии.

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

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

Скачиваем необходимые компоненты по ссылкам. Компоненты должны иметь архитектуру (x86 и x64), соответствующую архитектуре компьютера, на который происходит установка Viewer.

• UltraVNC Viewer
• SecureVNC Plugin: x86, x64.

Начинаем установку.



Внимательно читаем странное и нажимаем Next >.



Выбираем папку установки и нажимаем Next >.



Выбираем только компонент UltraVNC Viewer и нажимаем Next >.



Оставляем здесь все как есть и просто нажимаем Next >.



Выставляем галочки так, как вам будет удобно и нажимаем Next >.



Отключаем просмотр последних версий снятием галочки и нажимаем кнопку Finish.

Теперь скачиваем файл плагина по ссылке выше и перемещаем его в папку программы. После этого запускаем Viewer.



Устанавливаем все настройки так же, как и на скрине. ID сервера для подключения вводится именно в таком формате, то есть ID:XXXXXXXX. IP и порт репитера вводятся такими, какими были назначены при установке репитера.

Все, можно подключаться и радоваться жизни.

Замечания по использованию

• Не забывайте при подключении устанавливать security плагин. Если его не будет, соединение все равно произойдет, только без шифрования. Заставить UltraVNC Server требовать шифрования мне пока не удалось.
• Донастройте сервис при установке UltraVNC сервера. В процессе использования было отмечено, что сервис сервера иногда падает. Для того, чтобы в нужный момент не потерять связь с машиной рекомендуется в настройках сервиса установить его автоматический перезапуск при падениях.

Увидимся в следующих сериях

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

P.S. Надеюсь, кому-нибудь пригодится. Буду рад вашим комментариям.

https://habrahabr.ru/post/330450/

Как мы уже писали, сервис Virtual Private Cloud компании Selectel построен на базе платформы OpenStack, об этом подробнее можно прочитать в нашей предыдущей статье.

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

Работа с виртуальным приватным облаком начинается с создания проекта и резервирования для него ресурсов. Эти операции можно выполнить через панель управления или с помощью нашего API.

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

Чтобы привести начальную конфигурацию проекта и работу с OpenStack API к общему знаменателю, мы разработали пакет ansible-selvpc-modules, который включает в себя несколько ansible-модулей, предназначенных специально для нашего сервиса. Он будет полезен в работе для любого рода специалистов, которые взаимодействуют с нашим API.

Модули покрывают весь набор функций, который предоставляет наш сервис. Теперь нет необходимости вручную, либо через сторонние утилиты устанавливать ресурсы для проекта: все это можно сделать сразу в одном плейбуке с помощью ansible-selvpc-modules.

Пакет ansible-selvpc-modules включает в себя:

• selvpc_projects — для управления VPC проектами;
• selvpc_quotas — для управления ресурсами проекта;
• selvpc_limits — для получения информации о доступных ресурсах;
• selvpc_users — для работы с пользователями;
• selvpc_floatingips — для работы с плавающими ip адресами;
• selvpc_subnets — для работы с подсетями;
• selvpc_roles — для работы с ролями в проекте;
• selvpc_tokens — для создания ключей;
• selvpc_licenses — для работы с лицензиями.

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

Установка

Создадим изолированное виртуальное окружение, активируем и установим ansible-selvpc-modules:

$ virtualenv --no-site-packages env
$ source env/bin/activate
$ pip install ansible-selvpc-modules

Также нам понадобятся дополнительные пакеты для работы: shade как зависимость для os_* ansible-модулей и jmespath для удобного парсинга json-а (подробнее). Ставим из PyPi:

$ pip install shade jmespath

Для работы с Resell API нужны ключи. Зарегистрированные пользователи Selectel могут получить их здесь.

Теперь добавим переменные окружения SEL_URL и SEL_TOKEN:

$ export SEL_URL=https://api.selectel.ru/vpc/resell/
// На момент написания статьи актуальной версией API является 2
$ export SEL_TOKEN=<ваш API-ключ полученный выше в панели>

Так как в примере я буду использовать OpenStack модули для Ansible, дополнительно мне понадобятся следующие переменные:

$ export OS_PROJECT_DOMAIN_NAME=<ваш логин на my.selectel.ru>
$ export OS_USER_DOMAIN_NAME=<аналогично предыдущему>

Для облегчения жизни и хождений на хосты через Ansible выставим переменную окружения ANSIBLE_HOST_KEY_CHECKING в значение False:

$ export ANSIBLE_HOST_KEY_CHECKING=False

Все необходимые пакеты установлены, переменные добавлены, приступим к написанию плейбука.

Пример

1. Создадим файл example_vars.yaml, где определим переменные image, username, password и project_name, а также два списка с именами наших дисков и виртуальных машин. (image — образ OS, под управлением которой будет работать наши виртуальные машины, flavor — конфигурация машины, в нашем случае это 512 RAM и 1 VCPU, подробнее):
   

   ---
   username: TestUser
   password: 123456
   project_name: TestProject
   image: Ubuntu 16.04 LTS 32-bit
   volumes:
     - display_name: volume1
     - display_name: volume2
     - display_name: volume3
   servers:
     - name: vm1
     - name: vm2
     - name: vm3
   

   
   
2. Создадим файл example.yaml, в котором мы будем описывать наши таски. Добавим необходимые параметры hosts и vars_files.
   Переменная hosts определяет машину/машины, с которым мы будем осуществлять выполнение тасков, а vars_files указывает, откуда подгружать необходимые переменные (тут это файл example_vars.yaml):
   

   ---
   - hosts: localhost
     vars_files:
       - example_vars.yaml
   

   
   
3. Приступим к написанию тасков. Первым делом добавим создание проекта с помощью selvpc_projects и выделение квот для проекта, используя selvpc_quotas-модуль. Для 3 машин нам будет достаточно 3 процессорных ядер, 1536 RAM и 15 GB SSD-диска:
   

   ...
   tasks:
      - name: Create project
        selvpc_projects:
            project_name: "{{ project_name }}"
        register: project_out
    
      - name: Set quotas on created project
        selvpc_quotas:
            project_id: "{{ project_out.project.id }}"
            quotas:
                compute_cores:
                - region: ru-1
                  zone: ru-1a
                  value: 3
                compute_ram:
                - region: ru-1
                  zone: ru-1a
                  value: 1536
                volume_gigabytes_fast:
                - region: ru-1
                  zone: ru-1a
                  value: 15
        register: quotas_out
   

   
   
4. Создадим и добавим пользователя в проект:
   

   tasks:
      ...
        - name: Create user
          selvpc_users:
              username: "{{ username }}"
              password: "{{ password }}"
          register: user_out
     
        - name: Add created user to project
          selvpc_roles:
              project_id: "{{ project_out.project.id }}"
              user_id: "{{ user_out.user.id }}"
   

   
   
5. Создадим сеть:
   

   tasks:
       ...
        - name: Create public net
          selvpc_subnets:
               project_id: "{{ project_out.project.id }}"
               subnets:
                 - region: ru-1
                   type: ipv4
                   quantity: 1
                   prefix_length: 29
          register: public_net
     
        - name: Get info about network
          selvpc_subnets:
               subnet_id: "{{ public_net|json_query(subnets[0].id') }}"
          register: network_out
   

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

   tasks:
      ...
        - name: Create volumes
          os_volume:
             state: present
             auth:
    auth_url: https://api.selvpc.ru/identity/v3
               username: "{{ username }}"
               password: "{{ password }}"
               project_name: "{{ project_name }}"
             display_name: "{{ item.display_name }}"
             image: "{{ image }}"
             size: 5
            region_name: ru-1
          with_items: "{{ volumes }}"
          register: volume
   

   
   
7. Для доступа к нашим машинам нам будут нужны SSH-ключи. Мы создадим один ключ для всех машин. В этом нам поможет os_keypair:
   

   tasks:
      ...
        - name: Create key
          os_keypair:
             state: present
             auth:
            auth_url: https://api.selvpc.ru/identity/v3
               username: "{{ username }}"
               password: "{{ password }}"
               project_name: "{{ project_name }}"
             name: ansible_key
            region_name: ru-1
             public_key_file: "{{ '~' | expanduser }}/.ssh/id_rsa.pub"
          register: key
   

   
   
8. С помощью os_nova_flavor создадим конфигурацию(flavor) для наших машин, в нашем случае это 512 RAM и 1 VCPU и назовем ее “selectel_test_flavor”(можно дать любое другое):
   

   tasks:
      ...
        - name: Create flavor
          os_nova_flavor:
             state: present
             auth:
               auth_url: https://api.selvpc.ru/identity/v3
               username: "{{ username }}"
               password: "{{ password }}"
               project_name: "{{ project_name }}"
             name: selectel_test_flavor
             ram: 512
             vcpus: 1
             disk: 0
             region_name: ru-1
             is_public: False
          register: flavor
   

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

   tasks:
      ...
        - name: Create servers
          os_server:
             state: present
             auth:
            auth_url: https://api.selvpc.ru/identity/v3
               username: "{{ username }}"
               password: "{{ password }}"
               project_name: "{{ project_name }}"
             name: "{{ item.1.name }}"
             flavor: "{{ flavor }}"
             boot_volume: "{{ item.0 }}"
             nics: "net-id={{ network_out.subnet.network_id }}"
             key_name: ansible_key
            region_name: ru-1
          with_together:
             - "{{ volume|json_query('results[].id') }}"
             - "{{ servers }}"
          register: created_servers
     
     
        - name: Add hosts to inventory
          add_host:
             name: "{{ item }}"
             ansible_host: "{{ item }}"
             ansible_ssh_user: root
             groups: just_created
          with_items: "{{ created_servers|json_query('results[].openstack.accessIPv4') }}"
     
   - pause:
        seconds: 60
   

   
   
10. В конце добавим таск для проверки наших хостов на доступность:
    

    tasks:
       ...
    - hosts: just_created
      tasks:
        - name: Ping all instances
          ping:
          register: results
     debug: msg={{ results }}
    

    
    
    Я также добавил debug и ignore_errors в данном таске для наглядности, это не является обязательным (debug позволит нам выводить более подробный результат выполнения тасков, а ignore_errors не прекратит выполнение плейбука, в случае возникновения каких-либо ошибок).
    
    Дополнительно в конце плейбука я добавил удаление конфигурации (flavor), пользователя и проекта, чтобы почистить все, что было создано ранее:
    

    - hosts: localhost
      gather_facts: False
      vars_files:
        - example_vars.yaml
      tasks:
        - name: Delete flavor
          os_nova_flavor:
              state: absent
              auth:
                auth_url: https://api.selvpc.ru/identity/v3
                username: "{{ username }}"
                password: "{{ password }}"
                project_name: "{{ project_name }}"
              name: "{{ flavor.flavor.name }}"
              region_name: ru-1
          register: out
      
         - name: Delete user
           selvpc_users:
               user_id: "{{ user_out.user.id }}"
               state: absent
           register: out
      
         - name: Delete project
           selvpc_projects:
               project_id: "{{ project_out.project.id }}"
               state: absent
           register: out
    

    
    Полный файл плейбука можно найти здесь.
    
    
11. Запускаем наш плейбук:
    

    $ ansible-playbook example.yaml
    

    
    Во время паузы, которую мы добавили ранее в конце пункта 9, можно сходить в панель управления проекта и посмотреть на созданные серверы:
    
    
    
    Результаты выполнения плейбука в консоли:
    

    TASK [Ping all instances] 
    *************************************************************************
    ok: [95.213.234.211]
    ok: [95.213.234.212]
    ok: [95.213.234.210]
      
    TASK [debug] 
    *************************************************************************
    ok: [95.213.234.210] => {
        "msg": {
            "changed": false, 
            "ping": "pong"
        }
    }
    ok: [95.213.234.211] => {
        "msg": {
            "changed": false, 
            "ping": "pong"
        }
    }
    ok: [95.213.234.212] => {
        "msg": {
            "changed": false, 
            "ping": "pong"
        }
    }
      
    PLAY [localhost] 
    *************************************************************************
    TASK [Delete flavor]
    *************************************************************************
    changed: [localhost]
      
    TASK [Delete user] 
    *************************************************************************
    changed: [localhost]
      
    TASK [Delete project] 
    *************************************************************************
    changed: [localhost]
      
    PLAY RECAP 
    *************************************************************************
    95.213.234.210          : ok=3    changed=0    unreachable=0    failed=0   
    95.213.234.211          : ok=3    changed=0    unreachable=0    failed=0   
    95.213.234.212          : ok=3    changed=0    unreachable=0    failed=0   
    localhost               : ok=25   changed=13   unreachable=0    failed=0 
    

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

Ansible-модули покрывают весь набор функций, которые предоставляет наш сервис, и полезны в работе специалистов, взаимодействующих с нашим API.

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

Документация и исходники

https://habrahabr.ru/post/332260/

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


Серия будет состоять из следующих частей:

• Часть 1. Введение в процедурную анимацию
• Часть 2. Математика прямой кинематики
• Часть 3. Реализация прямой кинематики
• Часть 4. Введение в градиентный спуск
• Часть 5. Инверсная кинематика для робота-манипулятора
• Часть 6. Инверсная кинематика щупалец
• Часть 7. Инверсная кинематика лап паука

Часть 1. Введение в процедурную анимацию

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

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

Ниже мы обсудим очень специфический подвид физических анимаций, в котором применяется симуляция твёрдых тел (rigid body simulation). Такой же тип симуляции обычно используется в игровых движках, например в Unity и Unreal. Давайте посмотрим, как этот простой принцип используется в играх для создания физических анимаций.

Ragdoll-физика

В самой основе физических анимаций лежит принцип возможности симуляции движения персонажей. Воссоздавая процессы и ограничения, управляющие человеческим телом, можно приблизиться к созданию реалистичных поведений. Один из простейших, но эффективных способов создания процедурных анимаций — применение физики тряпичной куклы (рэгдолла, ragdoll)(Wikipedia). Идея заключается в создании гуманоидного тела и соединения всех его звеньев сочленениями (joints) для воссоздания степеней свободы, демонстрируемых реальным прототипом. Просто используя физику твёрдых тел и ограничения сочленений, можно симулировать падение тела человека. Это не только позволяет сэкономить деньги на «анимацию смерти». Также это позволяет создавать персонажей, реалистично падающих и взаимодействующих с окружениями. Подобную задачу почти невозможно решить с помощью только готового набора анимаций, вне зависимости от его точности.

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



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

Симуляции твёрдого тела

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

В статье How Grow Home Uses Maths To Generate Personality игровой журналист Алекс Уилтшир (Alex Wiltshire) разговаривает с представителями Ubisoft об игре Grow Home. Одна из основных особенностей игры — способ движения главного героя, Бада (BUD). В игре нет готовых анимаций, по крайней мере, в традиционном смысле. Когда игрок двигается, положение ног и рук управляется кодом. Части тела подвержены тем же ограничениями, что и у рэгдолла, что заставляет их создавать убедительные анимации.


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



И в Grow Home, и в Rain World процедурные анимации используются для повышения реалистичности персонажей. Однако контроллеры не полагаются на эти анимации. В игре Gang Beasts эта концепция развита ещё дальше. Игра полностью одобряет разболтанные движения, возникающие в результате использования ragdoll-физики. В результате получились забавные персонажи с непредсказуемыми движениями.

Инверсная кинематика

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

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

Одной из первых инди-игр, в которых активно использовалась эта концепция, стала The Majesty Of Color студии Future Proof Games. В ней игрок управляет щупальцем морского существа. В отличие от крыла птицы из Rain World, это щупальце не просто управляется шарнирами. Каждый сегмент поворачивается таким образом, чтобы конечная точка щупальца достигла нужной точки. Если бы в этой анимации использовалась только симуляция твёрдого тела, то щупальце казалось бы «приколотым» к этой точке, как кусок верёвки.


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

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



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

Часть 2. Математика прямой кинематики

Теперь мы начнём путешествие в мир инверсной кинематики. Есть множество способов решения этой проблемы, но все они начинаются с прямой кинематики.

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

Робот-манипулятор

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

Во-первых, давайте начнём с демонстрации того, что мы понимаем под термином «робот-манипулятор»:



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

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



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

Прямая кинематика

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

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

Геометрическая интерпретация

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

Поскольку визуализировать повороты в 3D не так просто, давайте начнём с простого манипулятора в двухмерном пространстве. Робот-манипулятор имеет «исходное положение» — это конфигурация, в которой все сочленения повёрнуты на их «нулевой угол».



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



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



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

Математика

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

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

Начнём с простого случая, когда первое сочленение находится в своём начальном положении. Это значит, что , как на схеме ниже:



Это значит, что:



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



Математически это можно записать как:



Ниже мы узнаем, как можно использовать функцию AngleAxis (документация Unity) без возни с тригонометрией.

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



И, наконец, общее уравнение:



В следующей части статьи мы увидим, как это уравнение удобно реализовать в коде на C#.

Часть 3. Реализация прямой кинематики

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

Введение

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



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

При повороте сочленений мы наблюдаем следующую картину:



Поведение этой системы можно суммировать следующими утверждениями:

• Поворот. Глобальный поворот сочленения — это сумма поворотов всех предыдущих сочленений:
  
  
  
• Положение. Глобальное положение сочленения задаётся как:
  
  
  

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

Иерархия GameObject

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



Если вам знаком риггинг, то вас это не удивит. Кости, представляющие собой сочленения гуманоидного персонажа, тоже имеют систему родителей, при которой повороты и движения наследуются. На изображении из Unity Animation 3: Character Setup Майкла Эрбетнота показан очевидный пример этого.



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

Реализация

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

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

using UnityEngine;
 
public class RobotJoint : MonoBehaviour
{
    public Vector3 Axis;
    public Vector3 StartOffset;
 
    void Awake ()
    {
        StartOffset = transform.localPosition;
    }
}

Для упрощения вычислений примем, что каждое сочленение может поворачиваться только по одной своей локальной оси: X, Y ил Z. Мы обозначим это переменной Axis, которая принимает значение 1 для координаты относительно оси вращения. Если сочленение поворачивается по оси Y, то Axis будет иметь вид (0,1,0). Мы увидим, как это позволит нам избавиться от конструкций с IF.

Давайте создадим функцию ForwardKinematics. Она получает массив angles чисел типа float. Имя говорит само за себя: angles[i] содержит значение локального поворота i-того сочленения. Функция возвращает положение конечного звена в глобальных координатах.

public Vector3 ForwardKinematics (float [] angles)
{
    ...
}

Код является простой реализацией на C# показанного выше уравнения положения. Функции rotate реализуются через удобную функцию Quaternion.AngleAxis.

Vector3 prevPoint = Joints[0].transform.position;
Quaternion rotation = Quaternion.identity;
for (int i = 1; i < Joints.Length; i++)
{
    // Выполняет поворот вокруг новой оси
    rotation *= Quaternion.AngleAxis(angles[i - 1], Joints[i - 1].Axis);
    Vector3 nextPoint = prevPoint + rotation * Joints[i].StartOffset;
    
    prevPoint = nextPoint;
}
return prevPoint;

[Окончание следует. Во второй статье мы рассмотрим инверсную кинематику.]

https://habrahabr.ru/post/332164/

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

Интересный функционал отдельных систем: Elama

Сервис «Рекомендатор»
Запускается при первом входе в систему, его можно запустить и позже.

Рекомендации подразделяются на критичные и важные, баллов нет, в отчете есть кнопки (Настроить, Редактировать) для немедленного выполнения рекомендаций.
При клике по ссылке обучение запускается «слайд-шоу», Каждый слайд — всплывающее окно. Слайды показываются рядом с рекомендациями, выданными для клиентской РК. Каждый слайд поясняет одну из рекомендаций.

Работа с Wordstat.yandex.ru в интерфейсе Elama

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

Управление ставками в зависимости от позиций сайта в поисковой выдаче

Другие особенности Elama

• Выгрузка расходов из ЯД в Google Analytics
• Автопополнение баланса РК

Интересный функционал отдельных систем: Aori

Подбор ключевиков с Яндекс WordStat и Google Keyword Tool

Бесплатная библиотека текстов объявлений

Бесплатная фототека

Магазин услуг

Другие особенности Aori

• можно задать дату старта и окончания РК
• можно создать РК сразу для ЯД и Adwords
• при входе на страницу создания РК предлагают посмотреть обучающее видео
• Два режима показов: равномерный и ускоренный
• Режим «Избегание первого места»: объявления будут показываться в блоке (СР или гарантии — зависит от того, какой порог ставки назначен) – без переплаты за первую строчку.
• автопополнение баланса РК
• распределение средств между площадками (ЯД и Adwords) — автоматическое или ручное

Интересный функционал отдельных систем: К50

Несколько разных периодов в одной формуле

Другие особенности К50

• можно подключить к правилу фид. С помощью фида можно управлять ставками в зависимости от стоимости товаров и других показателей
• Предпросмотр событий: правило создается, но не применяется к РК. В разделе "Отчеты" появится отчет по ключевым словам, к которым будут применяться правила в случае выполнения события.
• Эффектор (действие) «Пометить Тегом» (тег виден только в К50)

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

• Сеть Клики
• Поиск Клики
• Клики в гарантии и ротации
• Показы в гарантии и ротации
• Расход в гарантии и ротации
• Клики в спецразмещении
• Показы в спецразмещении
• Расход в спецразмещении
• Кампания: Название
• Объявление: utm_campain
• Объявление: ссылка без utm
• Объявление: ссылка без utm и доп.параметров
• Объявление: Статус расширений
• Объявление: Ссылка
• Объявление: Регион показов
• Объявление: id
• Фраза: Статус
• Фраза: k50id
• Фраза: Ключевое слово с минус-словами
• Фраза: Ключевое слово без минус-слов
• Фраза: Минус-слова
• Фраза: id
• Фраза: Действующая Макс. цена на поиске
• Фраза: Действующая Макс. цена клика в РСЯ
• Фраза: Новая Макс. цена на поиске
• Фраза: Минимальная цена на поиске
• Фраза: Цена входа в гарантию
• Фраза: Цена 1-го места в гарантии
• Фраза: Цена 1го места в гарантии (новый аукцион)
• Фраза: Ставка 1го места в гарантии
• Фраза: url
• Фраза: Расчетная ставка (если задана стратегия)
• Фраза: прогнозная конверсия (если задана стратегия)
• CallTouch/CRM Звонки/заказы
• CallTouch/CRM Оборот по звонкам/заказам
• CallTouch/CRM Прибыль по звонкам/заказам
• Код ответа сервера без редиректа
• Код ответа сервера

Интересный функционал отдельных систем: Alytics

Особенности генерации из YML у Alytics

• Каскады шаблонов. Для каждого объявления можно создать любое количество шаблонов, которые будут последовательно применяться. Если 1-й шаблон не пройдет ограничения по количеству символов, то система сгенерирует объявление по следующему шаблону.
• Возможность передавать синонимы и любую значимую информацию через тег
  Можно создать объявления только для товаров из заданного ценового диапазона
  Можно округлять цены товаров
  Можно назначить время для проверки обновлений XML
  Можно копировать шаблоны из других проектов или РК
  Импорт/экспорт шаблонов из/в CSV
  Списки синонимов
  Можно сразу создать РК для ЯД и Adwords
  Особенности управления ставками по СРО/CPA у Alytics
  Сегментирование ключевых слов по «смысловой близости»;
  Назначение ставок исходя из вероятностной конверсии по сегментам;
  Назначение ставок исходя из статистической конверсии по ключевым словам;
  Учет статистической конверсии по времени суток и дням недели;
  Вероятностная оценка конверсии для “long-tail” запросов;
  Особенности Alytics
  Задается основная стратегия (по нашей терминологии тактика) и дополнительная (необязательно)
  Можно указать расписание срабатывания правила, а также назначить однократное или многократное срабатывание: еженедельно, ежедневно, ежемесячно, каждые Х дней
  К одному проекту можно подключить сразу несколько профилей Google Analytics, Яндекс Директ, Google AdWords и Яндекс Маркет;
  Сегментация по Гео
  Сегментация Поиск/РСЯ и Поиск/КМС
  Сегментация Спецразмещение/Гарантия
  Суммирование целей с весами
  Учет в статистике НДС, агентских комиссий, скидок от площадок, плавающих курсов валют и т.д.
  Настройка рассылки отчетов по расписанию: нужный excel-отчет придет на почту в назначенный день
  Большое число показателей, используемых в триггерах. Кроме стандартных показателей, присутствующих в других сервисах, используются:
  отдельный учет показателей для поиска и кмс (сетей)
  отдельный учет показателей (показы, клики, СTR) для СР
  доля показов в СР
  доля кликов в СР
  доля затрат в СР
  звонки по user_id
  звонки с коллтрекинговых систем
  продажи из CRM (группа показателей)
  продажи из ГА (группа показателей)
  

  Интересный функционал отдельных систем: Origami

  
  

  Особенности генерации из YML у Origami

  
  Каскады шаблонов. Для каждого объявления можно создать любое количество шаблонов, которые будут последовательно применяться. Если 1-й шаблон не пройдет ограничения по количеству символов, то система сгенерирует объявление по следующему шаблону.
  читает файлы в формате YRL (Yandex Realty Language)
  есть ценовой фильтр
  можно настроить частоту обновлений фида (от 1 до 24 ч)
  
  

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

  
  
  • В параметрах стратегии доступны следующие настройки: «% ставки для перехода на позицию выше» и «% ставки для перехода на позицию ниже»
  • Можно независимо группировать РК в следующие группы: логические, финансовые, оптимизационные, группы для генерации.
  
  

  Интересный функционал отдельных систем: Marilyn

  
  

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

  
  
  • При генерации из YML можно задавать синонимы и варианты написания для товаров и услуг.
  • Автопополнение баланса. Возможно пополнение как с кредитной линии, так и с другой кампании/аккаунта. Можно задать частоту проверки баланса.
    Гибкая настройка прав пользователей
    
    В статистике показывается % выполнения плана:
  • по датам (для проекта указывается дата завершения, поэтому пользователь видит, какая часть выделенного времени использована)
  • по тратам (пользователь видит долю израсходованного бюджета)
  • по кликам (пользователь видит, какая часть от запланированного числа кликов фактически получена).
    Виды ограничения бюджета:
  • по периодам
  • по заказам
  • по проектам
    

    Интересный функционал отдельных систем: R-брокер

    
    

    Оценка качества
    У R-брокера мне понравился функционал, который называется «Оценка качества». Можно заказать такую оценку для рекламной кампании. Система выдает Excel файл с оценками по каждой фразе и с общими оценками по всей РК. В результате можно увидеть, какие недостатки есть у рекламной кампании. Например, в заголовке, тексте объявления или в быстрых ссылках мало слов из ключевой фразы, ссылка нерелевантна, нет минус-слов, посадочная страница долго загружается, у посадочной страницы высокий показатель отказов. Для каждой фразы выдается оценка (от «плохо» до «отлично»). Система даже предлагает свой вариант релевантной посадочной страницы с того же сайта. Для кампании выдаются 2 оценки: с учетом и без учета значимости отдельных фраз. Учет значимости означает следующее: чем больше доля фразы в кликах и расходах кампании, тем больше она влияет на суммарную оценку для кампании. Это правильно: если львиная доля расходов приходится на 2-3 некачественные фразы, то несколько сотен качественных объявлений, по которым никто не кликает, не спасут ситуацию.
    
    

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

    
    
    

    Расчет R-max по CPC или CPO/CPA
    Еще один любопытный функционал R-брокера – «Расчет R-max по CPC». Часто приходится решать такую задачу. Нужно чтобы стоимость клика (CPC) была близка к заданному значению. Какую ставку установить, чтобы добиться именно такой стоимости клика? Если выставить высокую ставку, клики будут слишком дорогими. Если назначить низкую ставку, купим дешевые клики, но кликов окажется слишком мало, план по трафику не будет выполнен. Директ не дает ответа на вопрос об оптимальной ставке, но «Расчет R-max по CPC» отвечает на этот вопрос. Можно выбрать ставку, которая обеспечит желаемую CPC. Система также дает прогноз, сколько будет получено кликов по этой цене. Если выяснится, что кликов слишком мало, можно скорректировать CPC и получить новую рекомендацию по ставке.

    
    
    

    Аналогичным образом можно подобрать ставку (R-max), которая обеспечивает желаемую стоимость заказа (CPO) или стоимость достижения выбранной цели (CPA). R-брокер указывает в прогнозе количество заказов (или достигнутых целей), которое будет получено при данной ставке.

    
    

    Автоуправление по CPC или CPA/CPO
    Можно выставить ставки в кампании по рекомендациям R-брокера. Но реальная ситуация в Директе меняется ежедневно. Поэтому прогноз R-брокера нужно все время корректировать, после чего менять ставки. Чтобы не тратить время на эту однообразную работу, можно поставить кампанию на автоуправление. Тогда R-брокер будет сам корректировать ставки в Директе, чтобы обеспечить назначенное значение CPC или CPA/CPO.

    
    

    Проекты
    Удобный инструмент для работы с кампаниями в R-брокере – проекты. Можно объединить несколько кампаний в один проект и управлять этими кампаниями так, как будто все они объединены в одну кампанию. Например, можно создать набор сегментов, назначить ставки для проекта. Если нужно управлять сразу сотнями кампаний, это очень удобно. Не нужно сотни раз повторять одни и те же рутинные операции.

    
    

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

    
    
    

    Сегменты
    В одной кампании имеется много фраз с разными показателями. Есть эффективные фразы с низкой стоимостью заказа и большим числом конверсий. Есть явно неэффективные фразы, по которым много кликали, но ничего не заказали. Есть "сомнительные" фразы, которые не принесли заказов, но по ним накоплено мало статистики, поэтому неизвестно, чего от них ждать. Некоторые из них могут оказаться эффективными, а другие — нет. Очевидно, что не следует назначать всем этим фразам одинаковые ставки. Поэтому разным категориям фраз следует назначить разные тактики. Состав этих категорий ежедневно меняется, так как фразы перемещаются из одной категории в другую по мере накопления статистики. Но в R-брокере не нужно вручную распределять фразы по категориям. Для этого имеется функционал "Сегменты". Пользователь может создать несколько сегментов, настроить условия для каждого сегмента (например, больше 3-х транзакций по фразе за последние 90 дней при стоимости заказа меньше 1000 руб.) Для каждого сегмента можно назначить ставку или тактику. После каждого обновления статистики R-брокер проверяет условия сегментов и при необходимости переводит фразу в другой сегмент.

https://habrahabr.ru/post/329812/

Как мы и обещали ранее, подготовлена подробная видео-инструкция по самостоятельному проведению аудита безопасности сети с помощью Check Point Security CheckUP R80.10. Ранее были опубликованы три части:

• Часть 1
• Часть 2
• Часть 3

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

1) Обзор


2) Установка и инициализация


3) Настройка


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

P.S. Отдельно хотелось бы поблагодарить за помощь при создании инструкции компанию RRC и лично Алексея Матвеева, а также Алексея Белоглазова из компании Check Point.

https://habrahabr.ru/post/332390/