Скрипт для экспресс-восстановления Excel-файлов после повреждения

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

В моем случае с такой ошибкой открывался xlsx-файл (далее 1.xlsx), восстановленный с помощью R-Saver после вирусной атаки, подобной «Petya».

После распаковки содержимого файла 1.xlsx в папку "\1" через контекстное меню были выданы следующие ошибки

Оказалось, что эти служебные файлы имеют нулевой размер. Я проделал аналогичную процедуру с исправным файлом 2.xlsx и скопировал из его папки "\2" ненулевые файлы [Content_Types].xml и .rels поверх пустых из "\1". Далее добавил содержимое папки "\1" в архив .zip и переименовал его в 3.xlsx. В результате, файл 3.xlsx уже открылся с корректными данными хотя и с предупреждением

Для автоматизации проделанных выше процедур был разработан скрипт vbscript, распространяемый «As Is».

Исходный код скрипта ST1_XLSX_FIXER_v1

option explicit

Const THIS_SCRIPT_NAME = "ST1_XLSX_FIXER_v1.vbs"
Const SUBDIR_XLS_SRC = "ST1_XLSX_FIXER_DATA_v1"
Const SUBDIR_OUT = "ST1_XLSX_FIXED"
Const RES_SUFFIX = "_fixed_ST1_v1"

Dim fso: Set fso = CreateObject("Scripting.FileSystemObject")

'если запускаем скрипт автономно
if WScript.ScriptName = THIS_SCRIPT_NAME then
    if WScript.Arguments.Count > 0  then             
        Dim fname
        for each fname in WScript.Arguments
                        if fso.GetExtensionName(fname) = "xls" then 
                                WScript.Echo "Файлы формата Excel 2003 и ранее (.xls) не поддерживаются"                        
                        else
                                FixCorruptedExcel fname                 
                        end if
                next
    else
        WScript.Echo "Для работы перенесите выбранные xlsx-файлы на скрипт"
    end if         
end if

Set fso = Nothing

Sub FixCorruptedExcel(fpath)
        
        Dim out_dir: out_dir = fso.GetParentFolderName(fpath) & "\" & SUBDIR_OUT
        if Trim(out_dir) <> "" then
                'создание папки результатов
                If not fso.FolderExists(out_dir) Then
                        fso.CreateFolder(out_dir)
                end if
        End If

        'cоздать копию xlsx-файла с расширением .zip
        Dim extract_dir: extract_dir = out_dir & "\" & fso.GetBaseName(fpath)
        Dim fpath_zip: fpath_zip = extract_dir & ".zip"

        fso.CopyFile fpath, fpath_zip

        'выходной файл
        Dim fpath_fixed: fpath_fixed = extract_dir & RES_SUFFIX & ".xlsx"
        if fso.FileExists(fpath_fixed) then fso.DeleteFile fpath_fixed 
        
        'распаковка zip
        UnzipFile fpath_zip, extract_dir
        
        'удаление zip-файла
        fso.DeleteFile fpath_zip

        'восстановление битых файлов из папки
        Dim script_path: script_path = fso.GetParentFolderName(Wscript.ScriptFullName)
        fso.CopyFolder script_path & "\" & SUBDIR_XLS_SRC, extract_dir
        
        'создание zip   
        CreateEmptyZipFile fpath_zip
        
        'архивирование extract_dir
        Dim shell: set shell = CreateObject("Shell.Application")
        Dim extract_dir_obj: set extract_dir_obj = fso.GetFolder(extract_dir)
        shell.NameSpace(fpath_zip).CopyHere shell.NameSpace(extract_dir).Items      
        
        do until shell.namespace(fpath_zip).items.count = shell.namespace(extract_dir).items.count
                wscript.sleep 1000 
        loop

        'zip -> xlsx
        fso.MoveFile fpath_zip, fpath_fixed

        'удаление unzip-папки
        fso.DeleteFolder extract_dir, true

        WScript.Echo "Исправленный файл: " & vbCrLf & fpath_fixed
        Set shell = Nothing
        
end sub

sub UnzipFile(fpath_zip, extract_dir)

        'создание папки для распаковки
        If not fso.FolderExists(extract_dir) Then
                fso.CreateFolder(extract_dir)
        End If

        'извлечение xlsx - аналог операции контекстного меню "Распаковать в ..."
        Dim shell: set shell = CreateObject("Shell.Application")
        Dim sub_files: set sub_files = shell.NameSpace(fpath_zip).items
        
        Const FOF_SILENT = &H4&
        Const FOF_RENAMEONCOLLISION = &H8&
        Const FOF_NOCONFIRMATION = &H10&
        Const FOF_ALLOWUNDO = &H40&
        Const FOF_FILESONLY = &H80&
        Const FOF_SIMPLEPROGRESS = &H100&
        Const FOF_NOCONFIRMMKDIR = &H200&
        Const FOF_NOERRORUI = &H400&
        Const FOF_NOCOPYSECURITYATTRIBS = &H800&
        Const FOF_NORECURSION = &H1000&
        Const FOF_NO_CONNECTED_ELEMENTS = &H2000&

        Dim args: args = FOF_SILENT + FOF_NOCONFIRMATION + FOF_NOERRORUI
        shell.NameSpace(extract_dir).CopyHere sub_files, args
        
        Set shell = Nothing
        
end sub

sub CreateEmptyZipFile(fname)
        if fso.FileExists(fname) then
        WScript.Echo  "Файл " & fname & " уже существует", vbCritical, WScript.ScriptFullName
    end if
    
    Const ForWriting = 2

    Dim fp: set fp = fso.OpenTextFile(fname, ForWriting, True)
    fp.Write "PK" & Chr(5) & Chr(6) & String(18, Chr(0))
    fp.Close
end sub

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

Для работы скрипта необходимо:

1. Скачать и распаковать архив ST1_XSLX_FIXER_v1.zip в любую папку
2. Левой кнопкой мыши перенести один или несколько xlsx-файлов на скрипт ST1_XLSX_FIXER_v1.vbs
3. Начнется процесс обработки каждого файла
   
4. После успешной обработки каждого файла выдается сообщение вида
   
   
   

Принцип работы скрипта:

1. Сохраняет входной файл неизменным
2. Создает подпапку ST1_XLSX_FIXED
3. Создает в ST1_XLSX_FIXED переименованную в zip копию xlsx
4. Распаковывает zip в папку и копирует поверх нее ST1_XLSX_FIXER_DATA_v1
5. Архивирует полученную папку в zip и переименовывает полученный файл в xlsx

Заключение
Данные эксперимент не претендует на общность использования, используйте предлагаемое решение на свой страх и риск. Со своей стороны планирую провести более широкий эксперимент и по результатам доработать скрипт. Текущее явное ограничение — скрипт не анализирует размер замещаемых файлов при копировании из ST1_XLSX_FIXER_DATA_v1, поэтому не умеет определять, какие именно служебные файлы оказались пустыми и требуют своей замены. Скорее всего, подобный способ применим, если утеряны именно служебные файлы, а не рабочие листы из "\1\xl\worksheets".

Также скрипт не подходит для файлов с расширением xls, созданных в версиях Excel 2003 и ранее, поскольку там используется другой формат хранения данных.

Let's block ads! (Why?)

Интервью в SD podCast с Павлом Одинцовым, автором FastNetMon, инструмента для обнаружения и отражения DDoS атак

Всем привет!

Некоторое время назад ksdaemon пригласил меня в гости к подкасту SD podCast. Это получилось очень интересное путешествие по дебрям нашего проекта и были открыты уголки, про которые раньше даже никто не спрашивал :) Отличная демонстарция фразы — хочешь понять (свой же продукт!) сам — объясни другим.

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

Для тех, кто не знакомы с продуктом для начала рекомендую изучить наш сайт и GitHub проект.

Текст беседы в подкасте Software Development podCast 58.

Пара слов о себе

Меня зовут Павел Одинцов, я автор проекта FastNetMon для обнаружения DDoS атак. Сейчас живу в Лондоне и занимаюсь преимущественно вопросами связанными с проектированием и программирование систем связанных с сетями.

Стандартный вопрос — как ты попал в айти? Как давно и чем занимаешься?

Попадание в ИТ вряд ли случайно, любовь к технике унаследовал от отца, внимание к деталям и умение сконцентрироваться на конкретном вопросе – от матери.

Детство мое прошло по большей части среди кип журналов Техника – Молодежи, Радио, где довольно часто описывалось, как своими силами собрать персональный компьютер. Это в те временами, разумеется, было за рамками моих возможностей, но интерес зародился уже и тогда и с появлением доступных по цене компьютеров (это был Celeron 266 c 32Mb RAM) наконец-то появилась возможность выйти за рамки чтения журналов и попробовать все на практике!

А дальше последовали годы чтения различных книжек, журналов (в основном – Мир ПК, иногда – Хакер), сидения в IRC чатах (привет Руснет и ДалНет!) и изучения технической документации в интернете, который по тем временам у меня был лишь на даче и на скорости 33к.

Через какое-то время в моем городе, Самаре, появился доступный GPRS и Спутниковые провайдеры интернета и, пожалуй, с этого момента было положено начало моей профессиональной практике. Все началось с того, что знакомый по ICQ попросил написать простенький скрипт на Perl, который я тогда как раз учил. Заодно с этим проектом пришло понимание, что разрабатывать на Windows довольно тяжко и принято решение перейти на Linux.

Со временем, хобби превратилось в довольно уверенное знание как Perl, так и Linux и я устроился на работу в Доменный Регистратор REG.RU как Perl программист. Но на практике, занимался я множеством задач связанных с Linux, а не только программировал.

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

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

В первую очередь, мы сконцентрированы на атаках volumetric, осуществляемыми по протоколам L3/L4.

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

Нередко, это атака на какой-либо определенный сайт, также бывают случаи, когда идет атака на инфраструктуру определенного оператора либо компании в целом – это намного опаснее.

Если говорить о текущих типах атак, то основные их типа используемые для атак на емкости канала – это NTP, SSDP, SNMP, DNS-амплификации. Суть их довольно простая, они используют промежуточный узел находящийся под управлением хакера, который в свою очередь шлет подложные запросы используя адрес жертвы вместо своего собственного на тысячи (иногда сотни тысяч) узлов интернета, которые имеют на себе сервис уязвимый к данному типу атаки. После приема этих запросов эти (часто вполне легитимные) сервисы генерируют ответ и отвечают огромным шквалом запросов на указанный узел жертвы, выводя его из строя.

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

Какие есть способы борьбы с такими атаками? Возможные варианты решений

Типичный сценарий борьбы с данными атаками на исчерпание канала довольно печальный. Обычно, с ними сталкивается не сам владелец сайта, VPS или сервера, а системные и сетевые администраторы Дата Центра либо Хостинг компании.

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

Обычно, после этого следует попытка захвата шаблонов трафика с роутеров, серверов, свитчей посредством обычно tcpdump либо встроенных решений от конкретного вендора.

Почти всегда по дампу очевидно, что идет атака на определённый IP адрес в сети и зачастую можно выявить определенную закономерность (например, что атака идет UDP пакетами с 53-го порта – яркий маркер DNS амплификации).

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

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

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

Как появилась идея написать?

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

Какие были до этого реализации/альтернативы?

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

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

Как до этого решались вопросы защиты от DDoS?

Вручную, по звонку телефона дежурному администратору ночью :)

Принцип работы системы

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

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

Внутреннее устройство

Внутри FastNetMon представляет собой конвейер, на вход которого принимается трафик в почти любом формате.

Сейчас мы поддерживаем:

• sFlow v4
• sFlow v5
• Netflow v5
• Netflow v9
• IPFIX
• SPAN
• Mirror
• PF_RING
• Netmap
• SnabbSwitch

После этого из вендор-специфичных форматов трафик конвертируется во внутреннее универсальное представление.

После этого, на каждый узел в сети создается множество счетчиков с детализацией по протоколу (TCP, UDP, ICMP), с детализацией по флагам (например, TCP SYN) или по опциям IP (наличие фрагментации) и отдельный следящий подпроцесс фиксирует, как только скорость определенного счетчика трафика в единицу времени превысила заданный пользователем порог.

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

И, наконец, осуществляется либо вызов скрипта либо генерация BGP анонса с целью заблокировать либо весь трафик целиком либо только паразитный – силами BGP Flow Spec.

Внешний API

По большей части, он отсутствует в привычном понимании API.

FastNetMon умеет экспортировать информацию в Graphite, InfluxDB, чтобы визуализировать трафик.

Для приема информации мы используем довольно четко стандартизованные протоколы, такие как sFlow, IPFIX и NetFlow и если вендор реализует их корректно – мы автоматически гарантируем поддержку со своей стороны.

Система плагинов

Она родилась сама собой, когда пришло понимание, что мир – он очень сложный и одним протоколом (в то время это был захват трафика с миррор/зеркального интерфейса) не обойтись, после этого мы стали добавлять новые протоколы – sFlow, Netflow и когда дошло до добавления четвертого мы провели серьезный рефакторинг и торжественно изолировали каждый модуль захвата трафика в отдельную библиотеку с фиксированным внешним API. Теперь любой может довольно легко разработать плагин реализующий его собственный, особенный способ съема телеметрии трафика.

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

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

Тестирование

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

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

Кроме того, для критичных и сложных по своей сути протоколов (BGP Flow Spec, например) у нас имеются unit тесты.

Адаптация для работы на разных платформах

Сейчас мы поддерживаем почти любой дистрибутив Linux, имеем официальный порт в FreeBSD, в состоянии добавления в официальную пакетную базу Debian. Какое-то время назад добавили поддержку для MacOS просто потому что захотелось поиграться на своем ноутбке :)

Мы пишем код в максимально переносимом формате используя доступные API для платформ и, например, для портирования на FreeBSD потребовалось поменять буквально 4 функции (использовались иные имена констант).

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

На каких технологиях построена (языки, фреймворки, модули) и почему были выбраны именно они?

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

Но мы активно используем внешние проекты – такие как ExaBGP, InfluxDB, Graphite, Grafana, GoBGP для обеспечения визуализации трафика либо взаимодействия со внешним миром.

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

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

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

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

Чтобы обеспечить отказоустойчивость FastNetMon, обычно можно просто продублировать трафик сети на второй инстанс (обычно, роутеры и свитчи поддерживают такое, кроме этого – всегда можно использоваться samplicator) и тем самым обеспечить отказоустойчивость – если один инстанс будет потерян, второй выполнит задачу и заблокирует трафик.

По поводу масштабирования по нагрузке, у нас есть подтвержденный опыт внедрения на сети с почти 1.4Tb трафика, такие цифры были достигнуты на базе NetFlow v9 коллектора и при этом оставалось еще множество возможностей для увеличения пропускной способности.

Если же этого не хватит – всегда можно разделить трафик по какому-либо признаку и установить дополнительные инстансы FastNetMon.

Почему open source?

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

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

Поэтому путь был один – открытый код! Иначе бы вышло узко- специализированное решение решающее одну очень-маленькую задачу в конкретной сфере.

Какие ты видишь преимущества в публикации проекта в open-source?
Безусловно – это огромный impact. Когда видишь, что твое решение используют в 103 странах включая Кубу – это воодушевляет :)

В чем отличие open-source проектов и закрытых коммерческих разработок?

Бывают «закрытые» open-source проекты и бывают очень «открытые» коммерческие проекты с закрытым кодом.

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

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

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

Сообщество вокруг проекта, как проект живет и развивается. Насколько много контрибьюта со стороны? Запросы на новые фичи и баги.

Основной контрибьют в проект идет по нескольким направлениям:

• Интеграция с различными вендорами (A-10 Network, Radware,
• Mikrotik).
• Запросы нового функционала от имеющихся пользователей с
• детальными описаниям их кейсов использования – это очень важная
• информация для развития проекта
• Тестирование на всем возможном многообразии сетевых устройств
• и программного обеспечения к ним
• Интеграция в различные дистрибутивы (AltLinux, FreeBSD, Debian)
• Непосредственного контрибута в ядро проекта (непосредственно модули обнаружения атак и аналитики), к сожалению, довольно мало и основная часть разработки в этом направлении идет собственными силами.

Планы по дальнейшему развитию проекта

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

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

Как часть реализации этого плана – несколько месяцев назад мы выпустили коммерческую версию FastNetMon Advanced, в которой реализован ряд преимуществ критичных для крупных компаний и крупных сетей класса TIER-2 и выше. В основном они касаются упрощенного развертывания, эксплуатации и более гибкого управлению в больших сетях. Основное ядро проекта при этом используется в обоих продуктах одно и тоже.

Как разработать правильную архитектуру, которая позволила бы расширять проект в дальнейшем, не меняя кардинально и не переписывая бОльшую часть кода? :)

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

Но потом – стоит время от времени останавливаться и задать себе вопрос «а как это сделать универсально?», «а кому это еще потребуется?». Часто помогает небольшая заморозка запроса на несколько недель, чтобы обдумать требуемые изменения в архитектуре и убедиться, что идея верная – и лишь после этого приступать к ее разработке.

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

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

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

У нас не было архитектуры изначально – лишь смутные цели, чего мы хотим добиться. На первых шагах не было ясно даже что проект будет работать и сможет справляться с нагрузкой в десятки миллионов пакетов- секунду! Это было очень много и по началу мы не могли отработать и 120 000 пакетов в секунду!

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

Насколько важна документация и тестирование

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

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

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

Всякие социальные аспекты open-source разработки: неправильные PR, глупые вопросы и ошибки

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

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

В итоге мы получаем десятки багов «FastNetMon не работает с устройством XXX вендора YYY», сначала мы извинялись, что проблема у вендора и поделать ничего не можем.

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

Let's block ads! (Why?)

Libdispatch. Как сделать приложение отзывчивым

Moneyball на бирже: как новые технологии меняют не только трейдинг, но и работу хедж-фондов

В 2003 году был опубликован бестселлер Майкла Льюиса под названием «Человек, который изменил все» (“Moneyball”) — это биографическая спортивная драма, рассказывающая историю генерального менеджера бейсбольной команды «Окленд Атлетикс» Билли Бина. Ему удалось добиться впечатляющих успехов с помощью анализа данных при формировании состава.

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

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

Новая эра в работе хедж-фондов

Такой «количественный» подход уходит корнями в тридцатые годы прошлого века, однако объём средств, под управлением финансистов, придерживающихся его, до недавних пор происходил достаточно медленно. Однако в последние восемь лет количественные (или квантовые — от англ. Quantitative, “quant”) хедж-фонды получили в управление почти $1 трлн, это почти треть от всего объёма активов всех мировых хедж-фондов.

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

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

В докладе Deloitte Investment Management Outlook 2017 большие данные, машинное обучение и ИИ названы главными трендами текущего года.

Даже традиционные управляющие начинают внедрять подходы количественного инвестирования. Например, фонд Tudor Investment Corporation был вынужден сократить 15% персонала из-за низких результатов и последующего отзыва средств со стороны инвесторов — это заставило знаменитого управляющего Пола Тудора-Джонса (Paul Tudor-Jones) провести организационные изменения для того, чтобы софкусироваться на более технологических подходах, основанных на работе с данными. «Ни один человек не может победить машину, и ни одна машина не победит человека с машиной», — так он, по слухам, обосновал изменения в работе фонда оставшимся сотрудникам.

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

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

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

Также постоянно осуществляется поиск новых статистически значимых факторов, а те из них, которые перестают таковыми быть, удаляются из использующихся моделей расчетов. Это позволяет подстраиваться под изменение рыночной коньюнктуры. К примеру, фонд Old Mutual Customised Solutions добавил в свою модель принятия решений факторы, описывающие ситуацию с окружающей средой, настроениями в обществе и активность регулирующих органов.

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

Другие материалы по теме финансов и фондового рынка от ITinvest:

• Образовательные ресурсы ITinvest
• Аналитика и обзоры рынка
• Как определить наилучшее время для сделки на фондовом рынке: Алгоритмы следования тренду
• Как Big Data используют для анализа фондового рынка
• Поиск неэффективностей: Что нужно знать о создании стратегий для торговли на бирже
• Эксперимент: Использование Google Trends для прогнозирования обвалов фондового рынка

Let's block ads! (Why?)

Личный опыт: как ИТ-специалисту переехать на работу в США, надеясь только на себя

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

Мой опыт не вписывается в эту схему и потому, как мне кажется, может оказаться полезным для других ИТ-специалистов — я переехал в США по визе O1, которая лишена некоторых недостатков традиционной американской рабочей визы.

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

Недостатки традиционного способа миграции по рабочей визе

Для начала поговорим о том, как устроен «стандартный» процесс переезда на работу в США. Обычно ИТ-специалисты — в основном, программисты — либо сами находят вакансии в понравившихся им компаниях, и отправляют резюме, либо их резюме передают в HR-службы их знакомые, которые уже там работают (это более выигрышный способ), либо рекрутеры компаний сами находят профессионала по нужному направлению и предлагают ему попробовать пройти собеседование.

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

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

На визы H1B существуют квоты — например, квота на следующий год составила 85 000 виз, при том что в прошлом году было подано 236 000 заявок на них, а на 2018 год получено около 200 000 заявок.

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

Если не попал в квоту: виза типа L

Некоторые крупные американские компании с офисами в других странах обходят ограничения виз типа H1B с помощью L-виз. Они предназначены для перевода в головной офис в США сотрудников из зарубежных представительств той же компании. Существуют подтипы L-виз для менеджмента и талантливых сотрудников (special knowledge worker). В общем случае, для того, чтобы получить возможность переехать в США уже без всяких квот и лотерей, сотрудник должен отработать в зарубежном офисе не менее года.

По такой схеме талантливых специалистов перевозят такие компании как Google, Facebook и Dropbox. У меня есть друг, который работает в офисе Dropbox в Дублине именно по этой причине.

Как видно, шанс переехать в США по рабочей визе есть, даже в случае неудачи в ходе лотереи H1B, но здесь надо задать себе вопрос — достаточно ли я ценный кадр, чтобы компания не только тратила на подготовку моей рабочей визы в США от 5 до десяти тысяч долларов, но затем еще перевозила в зарубежный офис и ждала год, пока я смогу присоединиться к команде в головном офисе? Думаю, большинство желающих переехать в Штаты смогут честно ответить на него отрицательно, как было и в моем случае.

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

Виза O1: плюсы, минусы, подводные камни

Виза O1 дается «выдающимся специалистам» в своих областях. Она достаточно активно используется в сфере ИТ-стартапов — многие сотрудники и основатели молодых проектов пытаются переехать в США с ее помощью.

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

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

Далее рассказ о моем опыте получения данной визы (чтобы не флудить в комментариях не по теме материала, ответы на многие вопросы о жизни в США можно найти вот в этой моей статье и обсуждении к ней).

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

Оказалось, что ситуация решается так — можно зарегистрировать в США компанию, которая и пригласит на работу талантливого специалиста, то есть вас. Желательно, чтобы ваша доля в фирме не превышала 50%, тогда получается, что у вас нет полного контроля над компанией и вас в принципе могут уволить. Возможен также вариант, когда компанией управляет совет директоров, который теоретически может и уволить работника.

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

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

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

• Рекомендательные письма от профессионалов в области маркетинга, также котируются мнения журналистов. Здесь важно найти именно коллег по цеху, и с самого начала я планировал набрать писем от генеральных директоров и председателей правления компаний, с которыми когда-то работал, но мой адвокат забраковал эту идею. Пришлось потратить время на поиски и переговоры. Вообще письма — это самое сложное: нужно уговорить людей, потом согласовать с ними текст письма — его пишут адвокаты и используют при этом весьма специфический язык, — и некоторых смущают такие хвалебные оды.
• Публикации в СМИ. У меня много публикаций по работе на русском и английском языках, так что это был самый простой пункт. Единственная сложность — все русскоязычные документы нужно переводить, а это — время и деньги.
• Членство в профессиональных ассоциациях. Здесь важно, чтобы сообщество было довольно старым и уважаемым, и чтобы в него принимали не просто за деньги, а по рекомендации членов. Мне удалось вступить в Российскую гильдию маркетологов, так что этот вопрос тоже был закрыт.
• Публичные выступления. С этим у меня было не густо, пришлось постараться и организовать несколько семинаров, в том числе на журфаке и PR-факультете МГУ.
• Наличие наград. В качестве примера здесь все приводят Нобелевскую премию, но как выяснилось, в качестве награды хороший адвокат может представить, например, попадание моей статьи в подборку лучших на каком-либо сайте.​
• Членство в жюри профессиональных конкурсов. Уже в ходе работы по сбору документов меня действительно пригласили стать членом жюри в одном небольшом онлайн-конкурсе среди редакторов контента.

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

Самой визы у меня в паспорте нет — я оформлял документы уже находясь на территории США. Чтобы её получить, нужно выезжать за пределы страны и идти в консульство, в котором, теоретически, могут начать запрашивать дополнительные документы и вообще отказать в выдаче визы (история об этом есть в публикации по ссылке). И визу дают сроком на два года, а не на три, которые указаны в approval notice от миграционной службы.

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

Весь процесс подготовки документов и рассмотрения визы занял около семи месяцев, это при том, что мы платили $1225 за ускоренное рассмотрение петиции (premium processing) в течение 15 дней. Но у меня возникали заминки с подготовкой документов и другие форс-мажорные обстоятельства, которые все затягивали. Обычно подготовка всего кейса занимает несколько месяцев, а затем идет рассмотрение в миграционной службе.

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

Общие затраты на оформление визы, переводы, оплата ускоренного рассмотрения вместе с открытием компании в США в моем случае составили немногим более $10 000.

Заключение

Резюмируя: потратив больше $10 тысяч, массу сил и полгода времени на начальном этапе вы получите возможность работать в США в своей компании. Далее можно либо развивать этот бизнес, либо искать варианты трудоустройства по контракту или на полноценной основе. Делать это уже находясь в стране гораздо проще, чем из России.

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

Let's block ads! (Why?)

Чем занимались пиарщики РПЦ в день встречи Путина и Трампа на G20?

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

Выборка

За сегмент репрезентативной выборки информационного пространства мы приняли топ 1,000,000 доменов мира по Алексе и заставили краулер обходить главные страницы этих сайтов ежедневно.

Данные

Полученные данные обсчитываем на предмет упоминания в текстах интересующих нас сущностей (в данном случае: РПЦ, Путин, Трамп, G20) и отрисовываем на графике.

Предыстория

30 июня мы добавили поиск упоминания саммита G20, было интересно, как информационное пространство реагирует на достаточно крупное событие в мире политики. Ожидалась первая встреча президентов, всё обещало быть интересным. Путина и Трампа отслеживали и раньше, их удобно использовать в качестве сравнительных величин при анализе неизвестных сущностей, ну а РПЦ как-то добавили из спортивного интереса, хотелось понять, что происходит там вообще.

Визуализация

Вот так выглядит график роста упоминаний G20:

Интерактивный график

К моменту наступления события количество упоминаний выросло с 10 до 40 тысяч, это действительно большая информационная волна, для масштаба, можно сравнить с Российскими политиками:

Интерактивный график

ТОП 1 Медведев — 2,2к упоминаний, правда, это на русском, но все же. Заметно как Поклонская рванула вверх 6-го числа (в тот день она выложила нарезку порно)

Давайте посмотрим на всплеск упоминаний Путина и Трампа в день встречи:

Интерактивный график

Как мы можем заметить, для Путина — это самый сильный всплеск за последнее время (на латинице, сравните с волной по прямой линии за 15-е число), для Трампа, в принципе, тоже.

Если рассмотреть упоминания Путина отдельно (на кириллице и латинице), то картинка становится интереснее:

Интерактивный график

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

Причём тут пиарщики РПЦ?

Если присмотреться к графику упоминаний аббревиатуры РПЦ:

Интерактивный график

Можно заметить, как Русская Православная Церковь стабильно наращивает свое присутствие в интернете, хайпят. Естественным ли образом или пиаром — вопрос отдельного исследования, но нам стало интересно, почему индекс упоминаний РПЦ обвалился в день встречи президентов и мы посмотрели на список доменов, с которых пропала аббревиатура. Выяснилось, что это на 87% те же, кто помогал усиленно освещать G20 в русском сегменте. Может в одном офисе сидят?)

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

Данные на графиках обновляются ежедневно.

Let's block ads! (Why?)

Security Week 27: ExPetr = BlackEnergy, более 90% сайтов небезопасны, в Linux закрыли RCE-уязвимость

[Перевод] Что делает язык программирования «модным»?

Rewarded Video: лучшие сценарии показа или как сделать так, чтобы вашу рекламу посмотрели

Формат Rewarded Video (RV) стремительно растет: пользователей такая реклама практически не раздражает, так как выбор — смотреть или не смотреть — остается за ними. Однако, видео за вознаграждение работает все по тому же по закону Парето: нужно потратить время на разработку стратегии размещения RV, чтобы выжать из этого типа рекламы максимум.

По идее, реклама в приложении должна инициализироваться как можно раньше, чтобы правильно отобразить максимальное количество видео из загруженных. Казалось бы, в таком случае проще показать Rewarded Video cразу после входа в приложение — но этого как раз делать не рекомендуется. Такое решение ударит по метрикам удержания (Retention Rate) и репутации. Пользователь вряд ли захочет вернуться в приложение, где ему навязывают видеорекламу сразу после экрана загрузки.

Кроме того, Rewarded Video не стоит пускать в начало приложения и с коммерческой точки зрения: для поиска более дорогой рекламы, с более высоким eCPM, нужно время.

Еще одна особенность — креатив (само видео) в формате Rewarded Video весит больше, чем остальные виды рекламы, соответственно, и загружается дольше. “Водопад” из рекламных сетей (см. cхему) опрашивается 15-20 секунд, а на загрузку креатива нужно около 30 секунд.

Магазин приложения

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

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

Сanyon Crash — Fall Down

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

Family Guy — The Quest For Stuff

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

PixelMon Hunter

В процессе игры

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

Blusty Bubs — Brick Breaker

Еще один хороший вариант — показать видеорекламу в обмен на подсказки в игре. К примеру, пользователь долго мучается с одним и тем же уровнем или не может разгадать паззл — тогда после нескольких неудачных попыток можно предложить ему видеорекламу в обмен на ключ к разгадке. Так сделали разработчики из студии Rusty Lake, которые создают мистический паззл, вдохновленный Твин Пиксом. В какой-то момент они поняли, что загадки в игре слишком сложны, и добавили видеорекламу для получения подсказок. Этот шаг поднял и лояльность игроков, и выручку.
Кроме подсказок есть много способов мотивировать пользователя посмотреть Rewarded video — например, предложите ему суперсилу, удваивание наград или другую фишку, облегчающую игру.

Hidden Worlds Adventure

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

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

Сanyon Crash — Fall Down

Помните и о балансе внутриигровой экономики. Те, кто не хочет расставаться с внутриигровыми покупками, могут чередовать видео с вознаграждением: скажем, игрок может посмотреть Rewarded video и получить награду только раз в 2-4 часа, а может не ждать и купить ее за реальные деньги. Для примера, вот несколько подключенных к Appodeal приложений с удачным использованием Rewarded video: Color Six, Lolo App, Block Strike, Hidden Worlds Adventure.

Источник заглавного изображения

Let's block ads! (Why?)

Обработка многократно возникающих SIGSEGV-подобных ошибок

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

DPM: Почему он такой?

Выбор алгоритма вычисления квантилей для распределённой системы

Всем привет!

Меня зовут Александр, я руковожу отделом Data Team в Badoo. Сегодня я расскажу вам о том, как мы выбирали оптимальный алгоритм для вычисления квантилей в нашей распределённой системе обработки событий.

Ранее мы рассказывали о том, как устроена наша система обработки событий UDS (Unified Data Stream). Вкратце – у нас есть поток гетерогенных событий, на котором нужно в скользящем окне проводить агрегацию данных в различных разрезах. Каждый тип события характеризуется своим набором агрегатных функций и измерений.

В ходе развития системы нам потребовалось внедрить поддержку агрегатной функции для квантилей. Более подробно о том, что такое перцентили и почему они лучше представляют поведение метрики, чем min/avg/max, вы можете узнать из нашего поста про использование Pinba в Badoo. Вероятно, мы могли бы взять ту же имплементацию, что используется в Pinba, но стоит принять во внимание следующие особенности UDS:

1. Вычисления «размазаны» по Hadoop-кластеру.
2. Дизайн системы подразумевает группировку по произвольному набору атрибутов. Это означает, что количество метрик вида «перцентиль» исчисляется миллионами.
3. Поскольку вычисления производятся с использованием Map/Reduce, то все промежуточные вычисления агрегатных функций должны обладать свойством аддитивности (мы должны иметь возможность «сливать» их с разных нод, производящих вычисления независимо).
4. Pinba и UDS имеют различные языки имплементации – C и Java соответственно.

Критерии оценки

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

Точность вычисления

Мы решили, что нас устроит точность вычислений вплоть до 1,5%.

Время выполнения

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

• время «математики» (стадия Map) – накладные расходы на инициализацию структур данных и добавление данных в них;
• время сериализации – для того чтобы произвести слияние двух структур данных, они должны быть сериализованы и переданы по сети.
• время слияния (стадия Reduce) – накладные расходы на слияние двух структур данных, вычисленных независимо.

Объём памяти

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

• RAM – объём, занимаемый структурами данных для квантилей.
• Shuffle – так как расчёт производится с использованием Map/Reduce, то неизбежен обмен промежуточными результатами между нодами. Для того, чтобы это было возможно, структура данных должна быть сериализована и записана на диск/в сеть.

Также мы выдвигаем следующие условия:

Типы данных

Алгоритм должен поддерживать вычисления для неотрицательных величин, представленных типом double.

Язык программирования

Должна присутствовать имплементация на Java без использования JNI.

Участники исследования

Naive

Чтобы иметь некий референс для сравнения, мы написали реализацию «в лоб», которая хранит все входящие значения в double[]. При необходимости вычисления квантиля массив сортируется, вычисляется ячейка, соответствующая квантилю, и берётся её значение. Слияние двух промежуточных результатов происходит путём конкатенации двух массивов.

Twitter Algebird

Это решение было найдено нами в ходе рассмотрения алгоритмов, заточенных под Spark (используется в основе UDS). Библиотека Twitter Algebird предназначена для расширения алгебраических операций, доступных в языке Scala. Она содержит ряд широко используемых функций ApproximateDistinct, CountMinSketch и, помимо всего прочего, реализацию перцентилей на основании алгоритма Q-Digest. Математическое обоснование алгоритма вы можете найти здесь. Вкратце структура представляет собой бинарное дерево, в котором каждый узел хранит некоторые дополнительные атрибуты.

Ted Dunning T-Digest

Библиотека представляет собой улучшение вышеупомянутого алгоритма Q-Digest с заявленным меньшим потреблением памяти, улучшенной производительностью и более высокой точностью.

Airlift Quantile Digest

На этот продукт мы наткнулись при реверс-инжиниринге распределённого SQL-движка Facebook Presto. Было несколько удивительно увидеть реализацию квантилей в REST-фреймворке, но высокая скорость работы и архитектура Presto (схожая с Map/Reduce) подтолкнули нас к тому, чтобы протестировать это решение. В качестве математического аппарата используется опять же Q-Digest.

High Dynamic Range (HDR) Histogram

Это решение являлось идейным вдохновителем реализации перцентилей в Pinba. Его отличительной особенностью является то, что при инициализации структуры необходимо знать верхний диапазон данных. Весь диапазон значений разбивается на N-ное количество ячеек, и при добавлении мы инкрементируем значение в какой-то из них.

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

Качественная оценка

Каждое из рассматриваемых программных решений было обёрнуто некоторой прослойкой (моделью) (чтобы адаптировать его под фреймворк для тестирования). Перед проведением performance-тестов для каждой модели были написаны unit-тесты для проверки её достоверности. Эти тесты проверяют, что модель (её нижележащее программное решение) может выдавать квантили с заданной точностью (проверялись точности 1% и 0,5%).

Performance-тесты

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

Raw-тест

В этом тесте мы измеряем производительность структур данных на вставку, то есть производятся замеры времени, требуемого на инициализацию структуры и на заполнение её данными. Также мы рассмотрим, как изменяется это время в зависимости от точности и количества элементов. Измерения производились для последовательностей монотонно возрастающих чисел в диапазонах 10, 100, 1000, 10000, 100000, 1000000 при погрешности вычисления 0,5% и 1%. Вставка производилась пачкой (если структура поддерживает) или поэлементно.

В результате мы получили следующую картину (шкала ординат логарифмическая, меньшие значения – лучше):

Результаты приведены для точности 1%, но для точности 0,5% картина принципиально не меняется. Невооружённым глазом видно, что с точки зрения вставки HDR является оптимальным вариантом при условии наличия более чем 1000 элементов в модели.

Volume test

В этом тесте мы производим замеры объёма, занимаемого моделями в памяти и в сериализованном виде. Модель заполняется последовательностями данных, затем производится оценка её размера. Ожидается, что лучшей окажется модель с меньшим объёмом занимаемой памяти. Замер производится с использованием SizeEstimator из Spark.

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

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

Абсолютным чемпионом вновь является HDR.

Map/Reduce-тест

Этот тест наиболее полно отражает поведение системы в боевой ситуации. Методика теста следующая:

1. Предсоздаётся десять моделей, содержащих n-ное количество значений.
2. Производится их слияние (эмуляция map-side combine).
3. Полученное значение сериализуется и десериализуется десять раз (эмуляция передачи по сети с разных воркеров).
4. Десериализованные модели сливаются (эмуляция финальной reduce-стадии).

Результаты теста (меньшие значения – лучше):

И в данном тесте мы снова отчётливо видим уверенное доминирование HDR в долгосрочной перспективе.

Анализ результатов

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

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

Эта статистика позволила нам принять решение о необходимости посмотреть на поведение метрик с большим количеством измерений. В результате мы выяснили, что 90 перцентиль числа событий на одну метрику (то есть нашу тестовую модель) находится в пределах 2000. Как мы видели ранее, при подобном количестве элементов есть модели, которые ведут себя лучше, чем HDR. Так у нас появилась новая модель – Combined, которая объединяет в себе лучшее от двух миров:

1. Если модель содержит менее n элементов, используются алгоритмы Naive модели
2. При превышении порога n инициализируется модель HDR.

Смотрим результаты этого нового участника!

Как видно из приведённых графиков, Combined-модель действительно ведёт себя лучше HDR на малой выборке и сравнивается с ней при увеличении числа элементов.

Если вас интересуют код исследования и примеры API рассмотренных алгоритмов, вы можете найти всё это на GitHub. И если вы знаете реализацию, которую мы могли бы добавить к сравнению, напишите о ней в комментариях!

Let's block ads! (Why?)

Метод восстановления данных с диска, зашифрованного NotPetya с помощью алгоритма Salsa20

[Из песочницы] Спасёт ли Python от казни?

[Перевод] Платформа Node.js обойдёт Java в течение года

Забронируйте ваше место на БИТ-пикнике HPE

Согласны, погода не для пикников. Но наша встреча для ИТ-специалистов «БИТ-пикник» в Москве 11 июля точно пройдет при любом прогнозе. В программе – практические сессии с специалистами по продуктам, разбор реализованных решений и живые демо. Регистрация – до 10 июля, количество мест ограничено, подробности под катом.

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

• Системы хранения HPE 3PAR и технология HPE Nimble InfoSight
• Онлайн-демонстрация быстрой настройки гостевой WiFi сети с СМС авторизацией с помощью облачной системы управления Aruba Central; подключение к облачной системе управления Aruba Central, регистрация точек доступа, настройка гостевого портала и параметров доступа, подключение клиентов к гостевой WiFi сети, сбор и анализ статистики.
• Процессоры Intel и вычислительные технологии HPE
• Гиперконвергентная система HPE SimpliVity 380: вычисления, хранение, бэкап, отказоустойчивость и много другое в одной системе.
• Теория и практика использования компонуемой инфраструктуры HPE Synergy
• HPE OneView — платформа управления серверной инфраструктурой.

В демо-зоне можно будет пообщаться с нашими специалистами и посмотреть на интересное железо – компонуемую инфраструктуру HPE Synergy, серверы HPE Moonshot, гиперконвергентные системы HPE SimpliVity.

Ознакомьтесь с полной программой и зарегистрируйтесь до 10 июля. Ждем вас!

Let's block ads! (Why?)

Лог файлы Linux по порядку

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

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

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

• приложения;
• события;
• службы;
• системный.

Большинство же лог файлов содержится в директории /var/log.

• /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
• /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
• /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.

Поддерживаемые уровни журналирования (приоритеты):
   emerg - система неиспользуемая
   alert - действие должно быть произведено немедленно
    crit - условия критичности
     err - условия ошибок
    warn - условия предупреждений
  notice - обычные, но значимые условия
    info - информационный
   debug - отладочные сообщения

(5:520)$ dmesg -l err
[1131424.604352] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[1131424.666013] usb 1-1.1: 1:1: cannot get freq at ep 0x81
[1131424.749378] usb 1-1.1: 1:1: cannot get freq at ep 0x81

• /var/log/alternatives.log — Вывод программы update-alternatives, в котором находятся символические ссылки на команды или библиотеки по умолчанию.
• /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
• /var/log/audit — Записи, созданные службой аудита auditd.
• /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
• /var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
• /var/log/cups — Все, что связано с печатью и принтерами.
• /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog.
• var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
• /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
• /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
• /var/log/samba/ — Логи файлового сервера Samba, который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
• /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
• /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

Для каждого дистрибутива будет отдельный журнал менеджера пакетов.

• /var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
• /var/log/emerge.log — Для ebuild-ов установленных из Portage с помощью emerge в Gentoo Linux.
• /var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

• /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last.
• /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2.
• /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
• /var/log/utmp — Список входов пользователей в систему на данный момент.
• /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump.

(5:535)$ sudo utmpdump /var/log/wtmp
[5] [02187] [l0  ] [        ] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:07 2015]
[1] [00000] [~~  ] [shutdown] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:08 2015]
[2] [00000] [~~  ] [reboot  ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[8] [00368] [rc  ] [        ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[1] [20019] [~~  ] [runlevel] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]

И другие журналы

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

• /var/log/mysql/ — Лог базы данных MySQL.
• /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log, а ошибки — в error_log.
• /var/log/lighthttpd/ — Лог веб сервера lighttpd.

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

• ~/.xsession-errors — Вывод stderr графических приложений X11.

Initializing  "kcm_input" :  "kcminit_mouse"
Initializing  "kcm_access" :  "kcminit_access"
Initializing  "kcm_kgamma" :  "kcminit_kgamma"
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing.
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
Qt: Session management error: networkIdsList argument is NULL

• ~/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f. Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file>.

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

$ aptitude install lnav #Debian/Ubuntu/LinuxMint
$ yum install lnav #RedHat/CentOS
$ dnf install lnav #Fedora
$ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords
$ yaourt -S lnav #Arch

Навигатор журналов lnav понимает ряд форматов файлов.

• Access_log веб сервера.
• CUPS page_log
• Syslog
• glog
• dpkg.log
• strace
• Произвольные записи с временными отметками
• gzip, bzip
• Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log

Программа умеет напрямую открывать архивный файл.

(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz

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

Mon May 02 20:25:00        123 normal         3 errors         0 warnings         0 marks
Mon May 02 22:40:00          2 normal         0 errors         0 warnings         0 marks
Mon May 02 23:25:00         10 normal         0 errors         0 warnings         0 marks
Tue May 03 07:25:00         96 normal         3 errors         0 warnings         0 marks
Tue May 03 23:50:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 07:40:00         96 normal         3 errors         0 warnings         0 marks
Wed May 04 08:30:00          2 normal         0 errors         0 warnings         0 marks
Wed May 04 10:40:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 11:50:00        126 normal         2 errors         1 warnings         0 marks

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

Использованные материалы

1. lnav — An Advanced Log File viewer for Linux
2. What Are Linux Logs? How to View Them, Most Important Directories, and More
3. Как посмотреть логи в Linux

Let's block ads! (Why?)

Семинар «Облака и реальность: кейсы, грабли, хорошие новости», 13 июля, Санкт-Петербург

Привет, Хабр! Мы готовим к запуску новый курс Университетов DataLine. На этот раз про наши знания в делах облачных. Первый семинар пройдет в Санкт-Петербурге 13 июля – для нас это двойная премьера :-)

На вводном семинаре курса расскажем про практику IaaS в России и в мире, поделимся лайфхаками в области миграции и поговорим об облаке будущего.

У нас осталось всего несколько мест, и мы будем рады видеть ИТ-директоров, инженеров и всех тех, кто занимается обслуживанием ИТ-инфраструктуры.

О чем поговорим:

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

После семинара для всех участников вкусный фуршет.

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

Let's block ads! (Why?)

[Перевод] Как создать билборд-текстуру растительности в Unreal Engine 4

В этой статье мы поговорим о том, как создать билборд-текстуру растительности в Unreal Engine 4. Такая растительность – это простой многократно размноженный четырехугольник, все копии которого всегда повернуты к камере. Я постараюсь привести доводы в пользу такого подхода, расскажу о потенциальных недостатках и отдельно затрону вопрос производительности.

Растительность в Unreal Engine 4

В Unreal Engine 4 по умолчанию есть встроенный инструмент для работы с растительностью под названием Foliage tool. Он добавляет клонированные статические меши (в более общем смысле слова – бесскелетные модели). Каждый ассет с растительностью можно добавить на карту тысячи раз с разными настройками поворота, расположения и т. д. для всех экземпляров.

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

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

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

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

Именно в этом случае на помощь приходят билборды.

Билборд это что-то из области рекламы?

Unreal Engine 4 в базовой комплектации поддерживает компонент Billboard Material Component. Он хорошо подходит для работы с единичными или немногочисленными мешами в уровне, как показано на примере выше. К сожалению, его нельзя использовать для инструмента Foliage tool, который поддерживает только размещение статических мешей. Чтобы использовать компонент Billboard Component, он должен находиться внутри класса Actor, который не поддерживается данным инструментом.

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

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

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

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

Подготовка материала

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

Перейдите в панель Content Browser, кликните правой кнопкой мышки и создайте новый Material.

Выберите следующие настройки:

• Blend Mode: Masked;
• Shading Model: Unlit;
• галочка напротив параметра Two Sided.

Затем можете поместить узлы на графическую панель материала.
Сделаем несколько важных уточнений. Материал настраивает положение вершин так, чтобы они были повернуты к камере. За счет привязанных к World Position Offset узлов материал настраивает положение своих вершин так, чтобы они были повернуты к камере.

Узел 'Custom' содержит внутри секции, отвечающей за эффекты билборда, специальный HLSL-код. Он нужен для вычисления правильного поворота четырехугольника. Параметры этого узла выглядят так: напротив 'Inputs' нужно выбрать одно значение и назвать его 'In', а напротив ‘Output Type’ – CMOT Float 2. В документации это описано иначе, но там неправильные названия параметров:

float2 output;
output = atan2 (In.y,In.x);
return (output);

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

Но этот материал не предназначен для прямого использования. Текстура была преобразована в Material Parameter, который будут использовать экземпляры материала.

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

Определив материал, загрузим в Unreal Engine 4 простой прямоугольник, который будет использоваться как статический меш для Foliage tool.

Создание и загрузка меша

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

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

Я использовал для четырехугольника следующие настройки:

• Roll: 270 градусов.
• Pitch: 180 градусов.
• Yaw: 0 градусов.
• Import Uniform Scale: Настройте в соответствии с размером вашей карты, сам по себе четырехугольник достаточно большой.
• Import translation, Z axis: Настройте в соответствии с ландшафтом. Я выставил на 190 единиц.

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

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

Добавляя меш в Foliage tool, убедитесь, что опции Align to Normal и Random Yaw отключены: они поворачивают меш и нарушают эффект материала.

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

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

Внешний вид

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

Ниже приведены для сравнения деревья с тенью и освещением и простые неосвещенные билборды:

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

Производительность

Поскольку мы рисуем только 2 треугольника для каждого дерева, производительность при таком подходе более чем приемлемая для современных компьютеров. Мне удалось заполнить деревьями всю карту без заметного снижения производительности средней видеокарты (AMD R9 270X). Метод также отлично подходит для работы с тростником, травой или другими мелкими растениями. Игрок не заметит, что они плоские, даже если подойдет ближе.

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

Правда, производительность в данном случае неидеальна. Узел 'Custom', который мы используем для материала, не позволяет движку оптимизировать шейдер. Сейчас это не играет роли, но у вас может быть по-другому. Если сомневаетесь, воспользуйтесь профайлером.

Альтернативы

Есть и другой подход – применять низкополигональные LOD-цепочки, которые генерируются с помощью таких инструментов, как Simplygon или Meshlab. В качестве растительности можно также использовать импостеры. А еще лучше совместить 3 подхода, используя высокополигональную модель дерева (например, с speedtree.com) и наименее детализированную модель в вашей LOD-цепочке. Так вы экономите ресурсы. Когда дерево находится далеко, оно не отличается от плоского спрайта по части детализации и теней. Поэтому необязательно прорисовывать его полностью.

Вывод

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

Let's block ads! (Why?)

Тюнинг типовых ролей Windows. Часть первая: Файлы и печать

Рынок систем детекции и распознавания: Эмоции и «эмоциональные вычисления»

[Из песочницы] Почему мобильные приложения занимают все больше места

Снимаем и вносим наличные в банкомате с помощью смартфона. Впервые в мире

Привет, Хабр! Мы с ребятами подумали и решили, что раз уж все начинают активно пользоваться разного рода Pay-ми (Apple Pay, Samsung Pay, Android Pay, да и не за горами еще парочка от вендоров), то почему бы не дать пользователям возможность не только платить с помощью смартфона на кассе магазина, но и снимать деньги в банкомате.

Сказано – сделано.

С чего все началось

Мысли о том, что неплохо бы постепенно переводить процессы оплаты на бесконтакт, пришли к нам еще во время первого фестиваля Alfa Future People. Тогда эта затея хорошо укладывалась в концепцию о том, что на территории фестиваля не должно быть наличных денег. Расплачиваться предлагалось с помощью браслета.

Гость фестиваля на входе получал браслет и привязанную к нему карту (MasterCard). В браслет была встроена смарт-карта, которая и позволяла расплачиваться касанием на торговых точках фестиваля. Таким образом получался и пропуск на фестиваль, и кошелек.

Это был 2014-й, и затем возможность вносить или снимать наличные в банкомате была распространена с браслетов на наши карты MasterCard PayPass, после чего доработали и VISA.

Новый виток развития платежей касанием был задан, когда к делу активно подключились вендоры. Apple 9 сентября 2014-го представила Apple Pay, который не только доказал свою состоятельность, но и задал очередной тренд. Samsung решил не отставать, в результате чего мир увидел Samsung Pay, а сейчас в РФ работает и Android Pay.

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

Переговоры

Мы пообщались с ребятами из Apple и объяснили им, что и как хотим сделать. Идея была воспринята с энтузиазмом.

На Apple Pay обкатывались все доработки процессинга, поэтому после выхода Samsung Pay и Android Pay каких-то технических сложностей не возникало, и по сути все подключение новой системы к банкоматам зависело только от успешности переговоров с вендором.

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

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

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

В итоге на все про все в случае с подключением Apple Pay у нас ушел месяц. В апреле 2017-го мы едем в Apple, а уже в начале мая проводим первые живые тесты на банкоматах.

На каких смартфонах это работает и насколько это безопасно

Ответ на оба эти вопроса, по сути, прост – все зависит от самой платежной системы вендора.
То есть если ваш смартфон поддерживает Apple Pay, Samsung Pay или Android Pay, то вы можете снять или внести наличные в одном из наших новых банкоматов с помощью смартфона. Если оплата на пинпаде в магазине работает с помощью часов – то получится использовать их и с банкоматом.

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

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

Где можно попробовать в действии

На начало июля в Москве у нас пока установлено 20 таких терминалов, по России суммарно – 300. Приоритет в установке отдается отделениям Альфа-Банка, но банкоматы ставятся и в бизнес-центрах.

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

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

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

К концу 2017-го мы планируем довести число таких банкоматов до 700. Сама перестройка банкоматной сети проводится двумя способами – это и установка новейших моделей банкоматов, и апгрейд текущих (соответствующий софт + ридер). При этом в случае апгрейда стоимость такой доработки составляет примерно 5% от цены нового банкомата.

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

Что дальше

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

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

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

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

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

Barclays Bank, 1967-й год, фото – AP.

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

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

Так вот, использование этого клона в РФ будет бесполезным – у банков есть данные о том, что карта защищена еще и чипом, поэтому снять деньги с клона через банкомат не выйдет. Зато можно увезти клон в США и обналичить его там, без проверки на чип.

Сейчас банкоматная сеть в США настолько огромна, что на ее модернизацию уйдет колоссальное количество средств и времени. Вкупе с определенным консерватизмом имеем то, что имеем – заметное отставание от остального мира по работе с картами.

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

Чем мы и стараемся заниматься.

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

Let's block ads! (Why?)