https://habrahabr.ru/post/333858/

1. Реализация отказоустойчивости на уровне гипервизора;
   
2. Преимущественно отказоустойчивое хранение данных;
   
3. Низкая стоимость резервного копирования и простая реализация для нас;
   
4. Расширение ресурсов в соответствии с нашими потребностями (Pay as you grow);
   
5. Наличие SLA.
   

Программа и методика испытаний

1. Вычислительная подсистема;
   
2. Дисковая подсистема;
   
3. Подключение к сети Интернет.
   

• Вычислительная подсистема: Linpack
  
• Дисковая подсистема: CrystalDiskMark, HD Tune Pro
  
• Пропускная способность: beta.speedtest.net
  

Критерии оценивания

Список провайдеров

• размещение в России;
  
• лицензия Windows Server включена в стоимость;
  
• бесплатное тестирование сервиса перед покупкой;
  
• возможность увеличения ресурсов виртуального сервера;
  
• гипервизор Hyper-V или VMware.
  

• ultravds.com / ruvds.com / bigd.host
• incloud.ru
• cloudlite.ru
• parking.ru
• 1cloud.ru
• neoserver.ru
• adman.com
• infobox.ru
• eserver.ru
• mclouds.ru
• ihc.ru
• cloud-pro.ru
• rackstore.ru
• docker.ru

• ultravds.com / ruvds.com / bigd.host
• adman.com
• parking.ru
• docker.ru
• cloud-pro.ru — ответа не получили

• eserver.ru — активация после предоставления скана документа, подтверждающего личность
• neoserver.ru — активация через менеджера и по будням
• rackstore.ru — активация через менеджера

Тестирование провайдеров

incloud.ru

Результаты тестирования incloud.ru

График производительности в GFlops

Тестирование производительности с помощью HD Tune Pro

Скорость чтения подскакивает после сохранения данных в кеше, это косвенно подтверждает то, что используется СХД.

Кеш виден издалека.

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

• Резервное копирование
  
• Лицензии ПО (Microsoft)
  
• Защита от DDoS-атак
  

• 1 vCPU — 200 рублей
• 1 GB RAM — 200 рублей
• 10 GB SATA — 50 рублей
• 10 GB SAS — 100 рублей
• 10 GB SSD — 150 рублей

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

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

ihc.ru

Результаты тестирования ihc.ru

График производительности в GFlops

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

Стабильное, но не «быстрое» вычисление без заметных провалов.

Тестирование производительности с помощью HD Tune Pro

• Резервное копирование
  
• Возможность приобретения дополнительных IP-адресов
  
• Лицензии на ПО (ISPmanager, Microsoft, 1С-Битрикс)
  

• высокоскоростной доступ в сеть Интернет;
  
• стабильная производительность вычислительной системы без скачков и провалов.
  

• реальная частота CPU оказалась ниже заявленной;
  
• низкая скорость R/W 4K секторов;
  
• высокие задержки на маршрутах по России;
  
• отсутствие информации об используемых серверах и системе хранения данных.
  

infobox.ru

Результаты тестирования infobox.ru

График производительности в GFlops

Хорошее среднее значения производительности в GFlops, но имеются провалы в производительности до 19%.

Тестирование производительности с помощью HD Tune Pro

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

• Резервное копирование
  
• Администрирование серверов
  
• Лицензии ПО (Microsoft, Parallels)
  

• высокоскоростная дисковая подсистема;
  
• производительная вычислительная подсистема.
  

• высокие задержки по России;
  
• нет возможности изменить конфигурацию виртуальной машины.
  

1cloud.ru

Результаты тестирования 1cloud.ru

График производительности в GFlops

Тестирование производительности с помощью HD Tune Pro

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

• Резервное копирование
  
• Лицензии ПО (Microsoft)
  

• 1 vCPU — 110 рублей
• 1 GB RAM — 315 рублей
• 1 GB SATA — 3 рублей
• 1 GB SAS — 5 рублей
• 1 GB SSD — 20 рублей

• удобная панель управления
  
• используется надежное оборудование известных производителей
  

• низкая пропускная способность канала и высокие задержки
  
• есть недокументированные лимиты на использование ресурсов CPU
  

cloudlite.ru

Результаты тестирования cloudlite.ru

График производительности в GFlops

Тестирование производительности с помощью HD Tune Pro

За высокую доступность и отказоустойчивость отвечает VMware VSAN.

• Резервное копирование
  
• Лицензии ПО
  

• высокая производительность CPU;
  
• низкие задержки по России.
  

• с лицензией Windows стоимость сильно увеличивается по сравнению с тарифами на Linux;
  
• невысокая скорость доступа в сеть Интернет.
  

mclouds.ru

Результаты тестирования mclouds.ru

График производительности в GFlops

На графике видна высокая производительность двух вычислительных ядер на уровне 40 GFlops.

Тестирование производительности с помощью HD Tune Pro

• Резервное копирование
  
• Лицензии ПО
  

• 1 vCPU — 99 рублей
• 1 GB RAM — 190 рублей
• 1 GB SSD — 20 рублей

• стабильная и производительная вычислительная и дисковая подсистема;
  
• низкие задержки по России.
  

• ограниченные ресурсы вычислительной, дисковой подсистемы и доступа в сеть Интернет;
  
• нет информации об используемой СХД.
  

Подводим итоги

https://habrahabr.ru/post/333854/

— There is likely to be a change to the terms and conditions relating to the datasciencechallenge.org. The original conditions were set by the company who are running the challenge for us (based on legal grounds) but following feedback they have/will be changed. Please don't let it put you off participating.

Постановка задачи

• A — любые мотоциклы и скутеры
• B — короткие светлые машины
• C — длинные светлые машины
• D — короткие темные машины
• E — длинные темные машины
• F — короткие красные машины
• G — длинные красные машины
• H — белые фургоны
• I — красно-белые автобусы

Метрика

Please send the following information to general@datasciencechallenge.org:
Full name
Nationality
Telephone contact details
Whether you would be happy to provide an interview for the winner announcements
Passport details (scan/photo of details page with photo)
Proof of address (eg. scan/photo of a utility bill)
Bank account details (IBAN, Account Number and Sort Code)

…
I'm sorry to say that due to your Russian citizenship you do not meet Clause 2.3b because Russia has a score below 37. As a result the company running the challenges is unable to award you any prize money as you do not meet the criteria that they need to follow due to their legal obligations in the UK.
…

https://habrahabr.ru/post/330118/

https://habrahabr.ru/post/333832/

https://habrahabr.ru/post/333850/

Это перевод статьи "What’s So Great About Redux?" (автор Justin Falcone), которая мне показалась весьма приятной и интересной для прочтения, enjoy!

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

В этом плане хранилище в Redux — это объект, редюсеры — это обработчики методов, а действия — это сообщения. Вызов store.dispatch({ type:"foo", payload:"bar" }) равносилен store.send(:foo, "bar") в Ruby. Middleware используется почти таким же образом, как в аспектно-ориентированном программировании (например, before_action в Rails), а с помощью connect в react-redux осуществляется внедрение зависимости.

Какие преимущества даёт такой подход?

• Благодаря инверсии контроля, упомянутой выше, исчезает необходимость обновлять пользовательский интерфейс, как только меняется имплементация смены состояний. Добавлять такие сложные функции, как логирование, отмена действия или даже time-travel debugging, становится проще простого. Интеграционные тесты сводятся лишь к тому, чтобы проверить, отправляется ли правильное действие, а для всего остального достаточно юнит-тестов.
• Состояние компонентов в React слишком неповоротливо для работы со сквозной функциональностью, которая затрагивает многие модули приложения, как, например, информация о пользователе или оповещения. Как раз для этого в Redux есть дерево состояний, независимое от пользовательского интерфейса. К тому же, при обработкe состояния вне интерфейса легче поддерживать постоянство, ведь сериализация в localStorage или URL проводится в единственном месте.
• Редюсеры дают огромную свободу в работе с действиями, которые можно сочетать, отправлять одновременно и даже обрабатывать в стиле method_missing.

Но все эти случаи особые. Что же насчёт более простых сценариев?

Как раз здесь у нас проблемы.

• Actions можно рассматривать как сложные переходы между состояниями, но в основном они лишь задают одно значение. В приложениях, сделанных на Redux, зачастую накапливается множество таких простых actions, и это явно напоминает Java с написанием функций сеттеров вручную.
• Один и тот же фрагмент состояния можно было бы использовать по всему приложению, но в большинстве случаев он относится к одной определенной части интерфейса. Перенос состояния из компонентов в хранилище Redux — это просто дополнительное перенаправление без должного уровня абстракции.
• Функции-редюсеры могли бы справиться с самыми замысловатыми задачами метапрограммирования, но обычно сводятся к примитивной диспетчеризации action согласно его типу. Это не проблема для таких языков, как Elm или Erlang, которые отличаются лаконичным и выразительным синтаксисом pattern matching, но в Javascript приходится иметь дело с громоздкими конструкциями switch.

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

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

Получается, лучше сторониться Redux в обычных случаях и приберечь его для особенных?

Как раз такой совет вам даст команда Redux — и я говорю то же самое своим коллегам: не беритесь за него до тех пор, пока setState не начнёт совсем выходить из-под контроля. Но даже я сам не следую собственным правилам, потому что всегда можно найти повод использовать Redux. Может быть, у вас есть много actions вроде set_$foo, при этом с каждым присвоением значения обновляется URL или сбрасывается ещё какое-нибудь промежуточное значение. Может, у вас установлено чёткое однозначное соответствие между состоянием и пользовательским интерфейсом, но вам требуется логирование или отмена действий.

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

Что же делать в таком случае?

К счастью, Redux достаточно гибкий, чтобы подключить к нему сторонние библиотеки для работы с простыми вещами — тaкие, как Jumpstart (https://github.com/jumpsuit/jumpstate). Поясню: я не считаю, что Redux нельзя использовать для низкоуровневых задач. Просто если работа над ними отдаётся сторонним библиотекам, это усложняет понимание, и по закону тривиальности время тратится на мелочи, потому что каждому пользователю в итоге приходится строить собственный фреймворк по частям.

Некоторым такое по душе.

И я в их числе! Но это относится далеко не ко всем. Я большой поклонник Redux и использую его почти во всех проектах, но мне также нравится пробовать новые конфигурации webpack. Я не типичный пример пользователя. Создание собственных абстракций на основе Redux даёт мне новые возможности, но что могут дать абстракции, написанные каким-нибудь Senior-инженером, который не оставил никакой документации и уволился полгода назад?

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

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

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

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

Ты серьёзно собираешься объяснять монады посреди поста?

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

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

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

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

Так к чему же всё это?

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

Этим пониманием нелегко поделиться, потому что основные принципы сводятся к банальным аксиомам («избегайте побочных эффектов») или настолько абстрактны, что почти теряют смысл ((prevState, action) => nextState). Конкретные примеры не помогают: они только демонстрируют многословность Redux, но не показывают его выразительность.

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

И что ты предлагаешь?

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

По-моему, интересно сравнивать React и Redux: хоть React и гораздо сложнее Redux и его API намного шире, как ни странно, его легче изучать и использовать. Всё, что действительно необходимо в API React, — это функции React.createElement и ReactDOM.render , а с состоянием, жизненным циклом компонентов и даже с событиями DOM можно справиться по-другому. Включение всех этих функций в React сделало его сложнее, но при этом и лучше.

"Атомарное состояние" — это абстрактная идея, и оно приносит практическую пользу только после того, как вы в нем разберётесь. С другой стороны, в React метод компонента setState управляет атомарностью состояния за вас, даже если вы не понимаете, как оно работает. Такое решение не идеально — было бы эффективнее отказаться от состояния вообще, или в обязательном порядке обновлять его при каждом изменении. Ещё этот метод может преподнести неприятные сюрпризы, если вызвать его асинхронно, но всё же setState намного полезнее для React в качестве рабочего метода, а не просто теоретического понятия.

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

Вся ирония в том, что смысл существования Redux — это «Developer Experience»: Дэн разработал Redux, чтобы изучить и воспроизвести time-travel debugger как в Elm. Однако, по мере того, как идея приобретала собственную форму и превращалась, по факту, в объектно-ориентированную среду экосистемы React, удобство «DX» отошло на второй план и уступило гибкости конфигурации. Это вызвало расцвет экосистемы Redux, но там, где должен быть удобный фреймворк с активной поддержкой, пока зияет пустота. Готовы ли мы, сообщество Redux, заполнить её?

https://habrahabr.ru/post/333848/

Показатели эффективности работы веб-студии

Как работать с показателями?

• Выполнение плана по доходам: > 100%
• Использование ФРВ: > 70%
• Использование ФРВ на коммерческие проекты: > 70%
• Рентабельность производственных активов: > 90%
• Выполнение нормативов: > 90%
• Выполнение сроков: > 90%

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

https://habrahabr.ru/post/333842/

        private void Edit(T sourceEntry, bool useCopy, bool showChanges, ReplicationProfile replicationProfile)
        {
            var cache = new ReconstructionCache();
            var sourceSnapshot = sourceEntry.CreateSnapshot(cache, replicationProfile);

            var editableEntry = useCopy ? sourceSnapshot.ReplicateGraph() : sourceEntry;
            if (GetView(editableEntry).ShowDialog() == true)
            {
                var resultSnapshot = editableEntry.CreateSnapshot(null, replicationProfile);
                var changes = sourceSnapshot.Juxtapose(resultSnapshot)
                    .Where(j => j.State != Etalon.State.Identical);

                if (changes.Any())
                {
                    MessageBox.Show(showChanges
                        ? changes.Aggregate("", (x, y) => x + y + Environment.NewLine)
                        : "Any changes has been detected!");
                    UpdateSourceData(editableEntry);
                    UpdateUserInterface();
                }
                else MessageBox.Show("There are no any changes.");
            }
            else if (!useCopy) sourceSnapshot.ReconstructGraph(cache);
        }

    public class Person : INotifyPropertyChanged
    {
        private int _id;
        private string _name;
        private string _birthday;
        private string _phone;
        private string _mail;

        public event PropertyChangedEventHandler PropertyChanged = (o, e) => { };

        private void Set(ref T target, T value, [CallerMemberName]string caller = "")
        {
            if (Equals(target, value)) return;
            target = value;
            PropertyChanged(this, new PropertyChangedEventArgs(caller));
        }

        public int Id
        {
            get => _id;
            set => Set(ref _id, value);
        }

        public string Name
        {
            get => _name;
            set => Set(ref _name, value);
        }

        public string Birthday
        {
            get => _birthday;
            set => Set(ref _birthday, value);
        }

        public string Phone
        {
            get => _phone;
            set => Set(ref _phone, value);
        }

        public string Mail
        {
            get => _mail;
            set => Set(ref _mail, value);
        }
    }

        private static readonly ReplicationProfile PersonRepicationProfile = new ReplicationProfile
        {
            MemberProviders = new List
            {
                new CoreMemberProviderForKeyValuePair(),
                new CoreMemberProvider(BindingFlags.Public | BindingFlags.Instance, Member.CanReadWrite),
            }
        };

            var cache = new ReconstructionCache();
            var sourceSnapshot = sourceEntry.CreateSnapshot(cache, replicationProfile);
            ...
                var resultSnapshot = editableEntry.CreateSnapshot(null, replicationProfile);

                var changes = sourceSnapshot.Juxtapose(resultSnapshot)
                    .Where(j => j.State != Etalon.State.Identical);

            var editableEntry = useCopy ? sourceSnapshot.ReplicateGraph() : sourceEntry;

            var cache = new ReconstructionCache();
            var sourceSnapshot = sourceEntry.CreateSnapshot(cache, replicationProfile);
            ...
            else if (!useCopy) sourceSnapshot.ReconstructGraph(cache);

https://habrahabr.ru/post/333846/

В Яндекс.Деньгах хранится масса важной для комфортной работы пользователя информации. Настройки профилей и подписки на штрафы тоже нужно бэкапить, чем и занимается у нас связка из Barman Backup & Recovery for PostgreSQL и pg_receivexlog.

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

Как было, и почему это не круто

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

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

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

Делаем правильно

Итого, будем решать следующие задачи:

1. Обеспечение доступности резервных копий при отказе ДЦ или бэкап-сервера.

   
   
2. Недопущение потери транзакций при выходе мастер-сервера из строя.

Масштаб нашей задачи составляли 20 серверов PostgreSQL 9.5 (10 мастеров и 10 слейвов), обслуживающих 36 баз данных суммарным объемом около 3 ТБ. Но описываемый сценарий подойдет и для пары серверов с критичными БД.

С версии 2.1 в Barman Backup & Recovery появилась возможность записывать поток транзакций не только с мастера, но и со слейв-серверов (реплик).

Общая схема нового решения представлена ниже, она довольно незамысловата:

По одному серверу резервного копирования в каждом ДЦ, конфигурация у них общая (один из плюсов Barman).

Процесс конфигурации выглядит следующим образом:

1. Подключаемся к серверу БД и с помощью пакетного менеджера устанавливаем postgresql-9.5-pgespresso – расширение для интеграции Barman Backup & Recovery c PostgreSQL.
Все команды приводятся для Ubuntu, для других дистрибутивов могут быть отличия:

apt-get install postgresql-9.5-pgespresso

2. Устанавливаем расширение pg_espresso в PostgreSQL:

postgres@db1:5432 (postgres) # CREATE EXTENSION pgespresso

3. Теперь на сервере с Barman нужно создать файл, описывающий настройки резервного копирования для сервера db1 – db1.conf в каталоге /etc/barman.d/ со следующим содержимым:

[db1]
ssh_command = ssh postgres@db1
conninfo = host=pgdb1 user=postgres port=5432
backup_options = concurrent_backup ; позволяет выполнять бэкап с реплики при наличии расширения pg_espresso

archiver = off ; выключаем доставку логов через archive_command
streaming_archiver = on ; включаем доставку логов через механизм репликации
slot_name = barman ; имя слота репликации

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

$ barman receive-wal --create-slot db1

5. И проверить, что Barman видит сервер и забирает с него журналы транзакций:

$ barman check db1

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

Server db1:
        PostgreSQL: OK
        superuser: OK
        PostgreSQL streaming: OK
        wal_level: OK
        replication slot: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: OK (have 7 backups, expected at least 7)
        ssh: OK (PostgreSQL server)
        pgespresso extension: OK
        pg_receivexlog: OK
        pg_receivexlog compatible: OK
        receive-wal running: OK
        archiver errors: OK

Теперь Barman будет забирать журналы и делать бэкапы с реплик. В бэкап попадают все базы PostgreSQL c профилями пользователей, историей платежей, подписками на штрафы, настройками аутентификации и т.п.

Отряд не заметил потери бойца

Напомню, что нулевое RPO при восстановлении нам очень важно, поэтому решили подстраховать Barman дополнительным механизмом – pg_receivexlog. Этот процесс находится на отдельном сервере – не на сервере с базой данных – и непрерывно переносит копии журналов транзакций из мастер-ноды в отдельное хранилище журналов транзакций, доступное для реплики. И так для каждого ДЦ отдельно.

Особенность механизма в том, что СУБД не подтвердит приложению запись данных в базу, пока не получит подтверждение от pg_receivexlog об успешном копировании транзакции.

Без этого сохранялась бы вероятность следующего сценария:

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

   
   

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

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

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

Теперь как настроить чудо механизм синхронного переноса логов:

1. Создаем слот для сборщика логов:

pg_receivexlog --create-slot -S pgreceiver --if-not-exists -h db1

2. Запускаем службы сбора логов с сервера PostgreSQL:

pg_receivexlog -S pgreceiver -d "host=db1 user=postgres application_name=logreceiver" -D /var/lib/postgresql/log/db1/ --verbose --synchronous

*-S: используемый слот репликации. Должен быть создан на первом шаге;*
*-d: строка подключения к базе;*
*-D: каталог, куда будут сохраняться журналы;*
*—synchronous: записывать данные в синхронном режиме;*

3. После запуска pg_receivexlog будет пытаться в синхронном режиме сохранять журналы транзакций в каталог. Таких сборщиков может быть несколько, по одному на сервер PostreSQL. Но чтобы синхронный режим заработал, нужно в настройках СУБД на мастер-ноде указать параметр в конфигурации PostgreSQL:

synchronous_standby_names = 'logreceiver, standby'

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

restore_command = 'scp postgres@logreceiver:/var/lib/postgresql/log/db1/%f* %p'

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

В качестве резюме приведу немного конкретики о времени и объеме бэкапов по описанной в статье схеме. Полный бэкап упомянутых серверов снимается в Яндекс.Деньгах ежедневно и весит около 2 ТБ, на обработку которых бэкап-серверу нужно 5-10 часов. Кроме того, выполняется постоянный бэкап журналов транзакций с помощью перемещения их файлов в хранилище.

https://habrahabr.ru/post/333844/

https://habrahabr.ru/post/333840/

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

Готовые варианты

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

Tcpdump. Консольный и довольно известный сниффер для UNIX-систем.

Пингуем 8.8.8.8 и любуемся выводом tcpdump.

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

Продолжаем пинговать 8.8.8.8, но смотрим уже с помощью Wireshark.

Microsoft Message Analyzer (в прошлом Microsoft Network Monitor). Помимо функций сниффера, может анализировать сообщения программ и устройств, системные события.

Возможностей много, поэтому и интерфейс громоздкий.

Наконец, WinDump. Аналог tcpdump, но для Windows.

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

1. В маршрутизаторах Mikrotik сниффер стоит искать в Tools - Packet Sniffer.
   
   Сниффер на Микротике.
   Любопытной возможностью является настройка потока (Streaming), позволяющая отправлять трафик с роутера прямо на компьютер с запущенным Wireshark.

   
   
2. В маршрутизаторах D-link DFL также присутствует сниффер. Искать в Tools - Packet Capture.
   
   Сниффер в D-Link DFL.

К сожалению, через GUI пакеты не посмотреть, но можно скачать дамп трафика в формате .cap и открывать привычным анализатором Wireshark или Microsoft Message Analyzer.

А теперь представим, что сниффер почему-то вот прямо сейчас не скачать, а инструмент нужен - приступим к упражнениям с PowerShell.

«Мощная оболочка» спешит на помощь

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

Ловить пакеты будем из командной строки с использованием набора командлетов NetEventPacketCapture в Windows 8.1/2012R2. Для примера представим, что на компьютере с именем REIKO пользователь работает в терминальной сессии - подглядим за его работой при помощи PowerShell.

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

$Cim = New-CimSession -ComputerName 'REIKO'

После этого создадим сессию обработчика событий:

New-NetEventSession -Name "Session01" -CimSession $Cim -LocalFilePath "C:\Windows\Temp\Trace.etl" -CaptureMode SaveToFile

И добавим поставщика событий:

Add-NetEventProvider -CimSession $Cim -Name 'Microsoft-Windows-TCPIP' -SessionName "Session01"

Посмотреть всех возможных поставщиков можно командой logman query providers.

После чего осталось запустить трассировку:

Start-NetEventSession -Name "Session01" -CimSession $Cim

Для остановки достаточно в той же команде заменить Start на Stop.

Результаты можно посмотреть следующей командой:

Get-WinEvent -Path "\\REIKO\C$\Windows\Temp\Trace.etl" -Oldest

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

Для автоматизации процессов такой трассировки (привет коллегам из ИБ) системный администратор Dan Franciscus написал скрипт Invoke-PSTrace.

#requires -Modules NetEventPacketCapture

function Invoke-PSTrace {
[OutputType([System.Diagnostics.Eventing.Reader.EventLogRecord])]
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true)]
        [string]$ComputerName,
        [switch]$OpenWithMessageAnalyzer,
        [pscredential]$Credential
    )  
        DynamicParam 
        {
            $ParameterName = 'ETWProvider' 
            $RuntimeParameterDictionary = New-Object System.Management.Automation.RuntimeDefinedParameterDictionary
            $AttributeCollection = New-Object System.Collections.ObjectModel.Collection[System.Attribute]
            $ParameterAttribute = New-Object System.Management.Automation.ParameterAttribute
            $ParameterAttribute.Mandatory = $true
            $AttributeCollection.Add($ParameterAttribute)
            $arrSet = logman query providers | Foreach-Object {$_.split('{')[0].trimend()} | Select-Object -Skip 3 | Select-Object -SkipLast 2
            $ValidateSetAttribute = New-Object System.Management.Automation.ValidateSetAttribute($arrSet)
            $AttributeCollection.Add($ValidateSetAttribute)
            $RuntimeParameter = New-Object System.Management.Automation.RuntimeDefinedParameter($ParameterName, [string], $AttributeCollection)
            $RuntimeParameterDictionary.Add($ParameterName, $RuntimeParameter)
            return $RuntimeParameterDictionary
        }

    begin 
    {
        $ETWProvider = $PsBoundParameters[$ParameterName]
    }

    process 
    {
        #Remove any existing sessions
        Get-CimSession -ComputerName $ComputerName -ErrorAction SilentlyContinue | Remove-CimSession -Confirm:$False
        Get-NetEventSession -Name "Session1" -ErrorAction SilentlyContinue | Remove-NetEventSession -Confirm:$False
        Remove-Item -Path "C:\Windows\Temp\$ComputerName-Trace.etl" -Force -Confirm:$False -ErrorAction SilentlyContinue
        #Create new session

        try 
        {
            $Cim = New-CimSession -ComputerName $ComputerName -Credential $Credential -ErrorAction Stop
            New-NetEventSession -Name "Session1" -CimSession $Cim -LocalFilePath "C:\Windows\Temp\$ComputerName-Trace.etl" -ErrorAction Stop -CaptureMode SaveToFile | Out-Null
        }

        catch 
        {
            Write-Error $_
            Break
        }    

        Add-NetEventProvider -CimSession $Cim -Name $ETWProvider -SessionName "Session1" | Out-Null
        Start-NetEventSession -Name "Session1" -CimSession $Cim | Out-Null

        if (Get-NetEventSession -CimSession $Cim)
        {
            Read-Host 'Press enter to stop trace' | Out-Null
        }

        Stop-NetEventSession -Name 'Session1' -CimSession $Cim   
        Remove-NetEventProvider -Name $ETWProvider -CimSession $Cim  
        Remove-NetEventSession -Name 'Session1' -CimSession $Cim  
        Remove-CimSession -CimSession $Cim -Confirm:$False 

        if ($ComputerName -ne 'LocalHost')
        {
            Copy-Item -Path "\\$ComputerName\C$\Windows\Temp\$ComputerName-trace.etl" -Destination 'C:\Windows\Temp' -Force
        }

        Get-CimSession -ComputerName $ComputerName -ErrorAction SilentlyContinue | Remove-CimSession -Confirm:$False

        if ($OpenWithMessageAnalyzer)
        {
             Start-Process -FilePath 'C:\Program Files\Microsoft Message Analyzer\MessageAnalyzer.exe' -ArgumentList "C:\Windows\Temp\$ComputerName-trace.etl"
        }

        else 
        {
             Get-WinEvent -Path "C:\Windows\Temp\$ComputerName-trace.etl" -Oldest 
        }
    }
}

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

Пример работы скрипта.

Поскольку в PowerShell можно использовать инструментарий .NET, еще до появления набора командлетов NetEventPacketCapture в сообществе появился скрипт сниффера Get-Packet. Ознакомиться с одним из вариантов доработанного скрипта можно в блоге у автора, я же приведу пример его работы.

Пингуем и смотрим трафик скриптом PowerShell.

Из-за использования методов .NET работает значительно быстрее командлетов, но создать его «на коленке» и без доступа к интернету будет непросто. Тем не менее это неплохая альтернатива проприетарным программам.

Старичок CMD тоже не промах

Если вы также любите батники, как их люблю я, то можете заинтересоваться трассировкой без всяких PowerShell, средствами привычного netsh.exe. Помимо создания можно ещё и сконвертировать файл трассировки из формата .etl в удобные форматы вроде .txt и .html.

@echo off

rem запускаем трассировку
netsh trace start InternetClient provider=Microsoft-Windows-TCPIP level=5 tracefile=trace.etl > nul
rem ждем 5 секунд
timeout 5 > nul

rem останавливаем трассировку
netsh trace stop > nul

rem конвертируем файл .etl в удобный .txt, чтоб не открывать Microsoft Message Analyzer
netsh trace convert input=trace.etl output=trace.txt dump=txt > nul

rem посмотрим, кто у нас занимается RDP
type trace.txt | findstr "3389"

rem убираем временные файлы
del trace*

Подробнее с синтаксисом netsh для сбора трассировки можно ознакомится в документации Microsoft.

С CMD самое большое неудобство в том, что без дополнительных утилит не так просто выполнить запуск скрипта, поэтому PsExec.exe или команду WMIC стоит держать под рукой:

wmic /user:"username" /password:"password" /node:"computer" process call create "sniffer.bat > log.txt"

В качестве «домашнего задания» предлагаю читателям запустить сбор трассировки на файловом сервере или сервере печати с помощью поставщика событий Microsoft-Windows-SMBServer. Особенно интересные результаты выходят, если с сервером работают как клиенты SMB v1, так и SMB v2 и старше.

https://habrahabr.ru/post/333838/

Результаты мониторинга

ТОП источников

ТОП подверженных инцидентам сегментов

Наиболее часто используемые техники воздействия на системы, повлёкшие инцидент ИБ

https://habrahabr.ru/post/333810/

Доверяйте данным, а не своим «чувствам»

Технология касания

Световое перо

Инфракрасные сенсорные экраны

Резистивные сенсорные экраны

Емкостные сенсорные экраны

Размер, давление и пятна контакта

Устаревшие стандарты

Определение новых стандартов

Наука касания

Базовые наблюдения за касаниями

• 75% пользователей касаются экрана только одним большим пальцем.
• Меньше 50% держат телефон одной рукой.
• 36% обхватывают телефоны, используя вторую руку, чтобы было стабильнее удерживать и удобнее дотягиваться до разных областей экрана.
• 10% держат телефон в одной руке и нажимают пальцем другой.

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

https://habrahabr.ru/post/333818/

Surfancy

Texel

МЕГА Accelerator 2

1. Выберите трек с тематикой, наиболее подходящей для вашей идеи. Их всего три: пространство для встреч, взаимодействие с посетителями и автоматизированный бэк-офис.
   
2. Подготовьте понятную и яркую презентацию в формате PDF или PPTX.
   
3. Подробно заполните анкету. Обратите внимание на вопросы про продажи, опыт работы с крупными компаниями и размер привлеченных инвестиций.
   
4. Не тяните с подачей заявки, прием заканчивается уже 27 июля 2017 года!
   

1. Ваша заявка пройдет экспертный отбор. Если она войдет в топ-50 проектов — поздравляем, вы становитесь участником предакселерационной программы.
   
2. С 2 по 27 августа прокачайте свой проект в предакселераторе, получите обратную связь от ведущих экспертов в сфере ритейла и попадите в итоге в топ-15 проектов.
   
3. С 18 сентября по 8 декабря активно работайте над проектом на креативной площадке коворкинга PO2RT, запустите пилот на площадках торговых центров МЕГА и докажите, что ваш проект лучший.
   

https://habrahabr.ru/post/333830/

• Ставьте только реальные дедлайны;
• Позволяйте команде ставить сроки;
• Объясняйте;
• Делайте акцент на негативных последствиях;
• Используйте систему напоминаний;
• Используйте эффективное ПО.

https://habrahabr.ru/post/333796/

• HP не является производителем модулей RAM.
• Когда вы видите бренд HP Qualified Memory, это означает, что DRAM прошла серьёзную проверку качества и тестирование с используем проприетарных диагностических инструментов и специализированных диагностических тестов, чтобы обеспечить высокий уровень производительности и доступности серверов HP ProLiant.
  
  
  
  
• До того, как модуль DRAM получит бренд HP Qualified Memory (наклейку), он проходит интенсивный четырехфазный процесс проверки качества. HP задолго до разработки продукта сообщает производителям модулей памяти (Tier 1 memory suppliers) требования к DRAM. Группа HP Memory Core получает модули DIMM непосредственно от поставщика-производителя. На диаграмме процесса HPMQ (HP Memory Qualification) даны краткие описания четырех фаз процесса проверки качества. На наш взгляд, важно обратить внимание на то, что не описано какая доля полученных на проверку модулей отсеивается.
  
  
  В результате HPMQ не меняется расположение микросхем, кажется, дизайнер ошибся
  
  
• Память проверяется так, чтобы она не становилась слишком горячей и по этой причине не забыла ваши данные.
  

  HP-validated memory is tested so that it does not get too hot and forget your data. HP-validated memory is tested so that it does not cause the system to shut-down due to power overload.

• HP Qualified Memory обладает такой же полной гарантией, что и серверы ProLiant.
• Если будет установлено, что отказ сервера вызван RAM под другим брендом (не-hp) или в любое время будет обнаружено, что сторонняя часть наносит ущерб компонентам или системам HP, стоимость ремонта, включая поврежденные детали HP, оплату труда и проезда, не будет покрываться по стандартной гарантии HP. Но установка сторонней памяти не снимает сервера ProLiant с гарантии HP. Подобное заблуждение часто приводится пользователями IT-форумов как аргумент «за OEM» в ходе обсуждения подбора памяти для сервера.
  

• Каждый серверный модуль Kingston для конкретной системы должен пройти испытания на принудительный отказ. Эта уникальная процедура позволяет отбраковывать потенциально дефектные модули, не допуская их попадания в отгружаемые партии продукции. В том числе, присутствует проверка надёжности при разогреве. Полный список проверок качества здесь.
• Являясь долговременным членом Совета директоров JEDEC, Kingston Technology способствует созданию отраслевых стандартов для технологий изготовления памяти. Все модули памяти, выпускаемые компанией Kingston, отвечают требованиям JEDEC и основным техническим условиям, применяемым ведущими изготовителями полупроводниковых устройств.
• Техническая поддержка и тест-драйв. Есть официальное представительство в РФ (в отличии от Crucial, например), по запросу всегда есть необходимое количество плашек для отгрузки. Серверную память можно взять на тест-драйв и посмотреть, как она будет работать в реальных условиях на конкретном сервере.
• «Пожизненная» гарантия. Если модуль памяти откажет, его заменят по гарантии.

• VMware VMotion;
• VMware DRS;
• VMware HA;
• и прочие.

https://habrahabr.ru/post/333786/

3. Анатомия таксономии

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

Начнем вот с чего: то, что мы называем таксономией, на самом деле представляет собой, как правило, целый набор связанных документов, называемых Связанным комплексом таксономий (Discoverable Taxonomy Set), для краткости - DTS.

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

Чтение DTS подразумевает переход по всем ссылкам до тех пор, пока не будут прочитаны все из связанных документов.

Таксономия может ссылаться на два типа документов:

• Таксономия - это тот случай, когда одна таксономия (Extended Taxonomy) расширяет другую таксономию (Base Taxonomy)
• База ссылок (Linkbase) - она используется для предоставления дополнительных сведений об определенных в таксономии концептах. Базы ссылок описывают связи между разными концептами, а также между концептом и дополнительной информацией к нему. Всего существует пять основных видов баз ссылок (каждый из которых будет подробно рассматриваться далее):
  
  • Определения (Definition)
  • Вычисления (Calculation)
  • Презентация (Presentation)
  • Ярлыки (Label)
  • Ресурсы (Reference)

Схематически это можно изобразить следующим образом:

Обратите внимание, что некоторые базы ссылок (Reference и Label) являются однонаправленными, т.е. ссылка ведет от таксономии к ресурсам базы ссылок. Другие базы ссылок (Definition, Calculation и Presentation) являются двунаправленными. Ссылки указывают от одной части таксономии к другой части.

Если необходимо, таксономия также ссылается на схему отчета XBRL «xbrl-instance-2003-12-31.xsd» (или, правильней сказать, импортирует ее) - она содержит базовые элементы, необходимые для определения всех концептов.

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

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

3.1. Схема таксономии

Ядро таксономии – это ее схема, которая является обязательным документом. Эта схема, о которой мы все это время говорим, на самом деле представляет собой документ XML Schema (стандарт W3C, позволяющий определять структуру XML-документов). Спецификация XBRL использует XML Schema в качестве базового языка для описания таксономий. Поверх этого базового языка она определяет набор специфичных для XBRL дополнений и ограничений.

В рамках схемы таксономии можно:

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

3.1.1. Определение концептов

Спецификация XBRL содержит ряд требований и рекомендаций по определению концептов:

• Каждый концепт должен иметь уникальное имя в пределах схемы таксономии;
• Каждый концепт должен иметь атрибут Тип, который определяет, какого типа данные могут предоставляться (см. далее);
• Концепты определяются в схеме таксономии как пункт (item) или кортеж (tuple);
  

  Это означает, что каждый концепт должен иметь атрибут substitution group со значением xbrli:item или xbrli:tuple
  

• Рекомендуется указывать в каждом концепте атрибут с уникальным идентификатором, это упрощает обращение к концепту.

XML Schema предоставляет несколько способов улучшить определение концептов:

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

Кроме того, XBRL определяет для концептов атрибуты periodType и balance:

• Атрибут periodType необходим для item-концептов (xbrli:item). Он позволяет отделить концепты, измеряемые по состоянию на определенную дату, от концептов, измеряемых за период времени;
  

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

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

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

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

3.1.1.1. Типы данных концептов

Для всех item-концептов должен быть указан тип передаваемых данных. Доступные типы данных определяются стандартом XML Schema и спецификацией XBRL.

XML Schema включает в себя следующие типы: логический (boolean), текстовый (text), десятичный (decimal), дата (date), части дат и т.д. (полный список можно найти в разделе 5.1.1.3 спецификации XBRL).

Примечание: для каждого типа из XML Schema имеется соответствующее определение типа XBRL.

Спецификация XBRL добавляет следующие типы данных:

• Денежный (monetary) – используется для концептов, отражающих денежные значения;
• Доли (shares) – для долевых концептов, напр. акций;
• Простой (pure) – для концептов, в которых числитель и знаменатель выражены неявно в общем значении, напр. темпы роста, проценты;
• Дробный (fractions) – когда факты не могут быть точно представлены никаким из других типов, напр. значение 1/3 не имеет точного десятичного представления, но его можно указать с помощью дробного типа. Дроби задаются как отдельные значения числителя и знаменателя.

3.1.2. Ссылки на базы ссылок

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

Ссылка может указывать на определенный вид Базы ссылок путем определения роли. Спецификация XBRL допускает следующие роли:

• Определение (Definition)
• Вычисление (Calculation)
• Презентация (Presentation)
• Ярлык (Label)
• Ресурс (Reference)
• Сноска (Footnote)

Примечание: Для сносок не создается отдельных баз ссылок. Эта роль используется только в пределах отчета XBRL.

Также, возможно определить пользовательские роли, что является еще одним примером расширяемости XBRL.

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

3.1.3. Роли (roles) и роли дуг (arcroles)

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

Связи, которые определяются дугами, типизируются ролями дуг (arcroles). Основные дуги, такие как «concept-label» или «summation-item» предопределены спецификацией XBRL. Также, возможно определить собственные дуги. Но используется это обычно для технических целей, напр. для определения новых связей в расширении спецификации XBRL. Примером этого могут служить дуги, определенные в спецификации XBRL Dimensions, о которой мы поговорим в Главе 5.

3.1.4. Пример

Вернемся к примеру «таксономии»:

Здесь мы можем приблизительно определить следующие концепты:

Имя	Тип
nr_employees_total	non-negative integer item
nr_employees_male	non-negative integer item
nr_employees_female	non-negative integer item
nr_employees_age_up_to_20	non-negative integer item
nr_employees_age_21_to_40	non-negative integer item
nr_employees_age_41_and_up	non-negative integer item

Мы рассмотрим эти концепты в следующем разделе про базы ссылок.

3.2. Базы ссылок

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

Базы ссылок расширяют это определение следующим образом:

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

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

Примечание: Приведенные здесь «базы ссылок» не являются полными или корректными. Они приведены просто для иллюстрации.

База ссылок ярлыков (label linkbase)
База ссылок ярлыков может присвоить русский ярлык каждому используемому в форме концепту:

Концепт	Ярлык
nr_employees_total	Всего
nr_employees_male	Мужчины
nr_employees_female	Женщины

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

Концепт	Ярлык
nr_employees_total	Total
nr_employees_male	Men
nr_employees_female	Women

Примечание: Этот пример базы ссылок ярлыков не совсем корректен. Мы вернемся к нему позже.

База ссылок определений (definition linkbase)
Определения концептов предоставляют различного рода информацию. Например, о том, что определенный концепт требует обязательного наличия другого концепта:

Концепт	Требует
nr_employees_male	nr_employees_female
nr_employees_female	nr_employees_male

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

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

Концепт	Псевдоним
nr_employees	nr_employees_total
nr_employees	nr_employees_male
nr_employees	nr_employees_female

База ссылок вычислений (calculation linkbase)
C помощью вычисления можно задавать такие правила:

• nr_employees_male + nr_employees_female = nr_employees_total

Такое правило автоматически отловило бы арифметическую ошибку в заполненной форме.

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

Концепт	Ресурс
nr_employees_total	Законодательный акт; Часть IV; Раздел 156-32.г
nr_employees_male	Законодательный акт; Часть IV; Раздел 156-32.г
nr_employees_female	Законодательный акт; Часть IV; Раздел 156-32.г

Примечание: Это можно выразить и связью «многие-к-одному», рассмотрим это далее.

База ссылок на презентаций (presentation linkbase)
Презентации описывают, как концепты могут быть иерархически представлены в отчетной форме. Наш пример мог бы иметь следующую иерархию:

Концепт	Нижний уровень иерархии
nr_employees_total	nr_employees_male
nr_employees_total	nr_employees_female

3.2.1. Общие характеристики баз ссылок

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

3.2.1.1. Дуги (arcs)

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

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



Атрибуты дуги from и to могут быть ресурсами, включенными в расширенную ссылку (extended link), или локаторами (locators) в расширенной ссылке, которые указывают на концепты или ресурсы в других документах.

Локатор указывает на концепт или ресурс с помощью атрибута href, который может содержать id концепта или выражение стандарта XPointer.

3.2.1.2. Запрет и переопределение

Когда таксономия расширяется, может потребоваться изменить существующие взаимосвязи между концептами. Для этого существует два механизма – запрет (prohibiting) и переопределение (overriding).

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

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

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

Спецификация XBRL указывает, что правила применяются к эквивалентным отношениям, и точно определяет, когда отношения эквивалентны на основе атрибутов дуг и сторон «от» и «к».

3.2.1.3. Циклы

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

• Любые (any) – все циклы разрешены, нет ограничений на взаимосвязи;
• Неориентированные (undirected) – этот странно названный вариант допускает циклы, если нет обратного пути к начальному узлу. Например, узлы А и Б могут иметь много путей от А к Б, но не должно быть пути от Б к А;
• Никакие (none) – не разрешены никакие циклы, сеть не может иметь более одного пути между двумя узлами. Это накладывает большие ограничения на взаимосвязи.

Примечание: Путь состоит из набора дуг между узлами. Путь может быть коротким (одна дуга между двумя узлами) или длинным (сотни дуг между сотнями узлов).

3.2.1.4. Роли

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

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

Роли могут быть использованы в ресурсах и в дугах между ними.

3.2.2. Специфичные характеристики баз ссылок

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

3.2.2.1. База ссылок ярлыков

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

Ярлыки могут иметь следующие роли:

• label (роль по умолчанию) – используется для стандартных ярлыков;
• terseLabel – используется для сокращенных ярлыков, где часть описания опущена;
• verboseLabel – используется для расширенных меток, подробно описывающих концепт;
• positiveLabel, positiveTerseLabel и positiveVerboseLabel – стандартный, сокращенный и расширенный ярлыки, используемые для положительного значения факта;
• negativeLabel, negativeTerseLabel и negativeVerboseLabel – стандартный, сокращенный и расширенный ярлыки, используемые для отрицательного значения факта;
• zeroLabel, zeroTerseLabel и zeroVerboseLabel – стандартный, сокращенный и расширенный ярлыки, используемые для нулевого значения факта;
• totalLabel – используется для ярлыков концептов, определяющих итоговые значения;
• periodStartLabel и periodEndLabel – используются для ярлыков концептов, определяющих факты, ассоциированные с началом или окончанием периода;
• documentation – для ярлыков, предоставляющих документацию по концепту;
• definitionGuidance, disclosureGuidance, presentationGuidance, measurementGuidance, commentaryGuidance и exampleGuidance – для ярлыков, которые дают пояснения по таким аспектам концепта как определение, способ измерения или пример заполнения.

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

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

Концепт	Язык	Роль	Ярлык
nr_employees_total	ru	totalLabel	Всего
nr_employees_male	ru	terseLabel	Мужчины
nr_employees_female	ru	terseLabel	Женщины
nr_employees_total	en	totalLabel	Total
nr_employees_male	en	terseLabel	Men
nr_employees_female	en	terseLabel	Women

3.2.2.2. База ссылок ресурсов

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

Ссылки могут состоять из частей (part), напр. «Законодательный акт; Часть IV; Раздел 156-32.г». В спецификации XBRL элемент part является абстрактным, поскольку способ разделения публикации на части варьируется для каждой публикации / юрисдикции.

Ссылки могут иметь следующие роли:

• reference (значение по умолчанию) – используется для стандартного ресурса концепта;
• definitionRef – используется для ссылки на точное определение концепта;
• disclosureRef, mandatoryDisclosureRef и recommendedDisclosureRef – используются для ссылки на объяснения требований к раскрытию;
• unspecifiedDisclosureRef – используется для ссылки на объяснения не указанных требований к раскрытию, таких как общая практика, полнота и структура;
• presentationRef – используется для ссылки на объяснение презентации концепта;
• measurementRef – используется для ссылки на метод измерения значения концепта;
• commentaryRef – используется для ссылки на любой комментарий общего плана к концепту;
• exampleRef – используется для ссылки на документацию, иллюстрирующую использование концепта с помощью примера.

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

3.2.2.3. База ссылок презентаций

Дуги презентаций имеют роль «parent-child», что позволяет определять иерархическую структуру концептов. И parent-, и child-сторона связи должна указывать на концепт.

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

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

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

3.2.2.4. База ссылок вычислений

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

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

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

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

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

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

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

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

В настоящее время разрабатывается еще одна база ссылок – формулы (formula linkbase). Она станет доступна для использования в ближайшее время и обеспечит более широкие функциональные возможности для определения формул расчета.

3.2.2.5. База ссылок определений

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

• general-special
  Взаимосвязь item-концептов с их обобщением / детализацией. Такие взаимосвязи можно рассматривать как «является одним из», напр. концепт «менеджер подразделения» является детализацией концепта «менеджер». Обратите внимание, что любое допустимое значение для элемента детализации также является допустимым как значение для элемента обобщения. В обратную сторону это, как правило, не работает.
  Сеть таких взаимосвязей может содержать только неориентированные циклы, поскольку детализация никогда не может быть собственным обобщением.
• essence-alias
  Эта взаимосвязь может быть применена только к item-концептам. Она используется, когда определены несколько похожих концептов и указывает, какой из них является наиболее подходящим (essence). Все остальные концепты считаются псевдонимами (alias) этого essence-концепта.
  Alias-концепты и essence-концепты должны иметь одинаковый тип значения, одинаковый тип периода (periodType) и одинаковый атрибут balance, если он используется.
  Сеть таких взаимосвязей может содержать только неориентированные циклы, поскольку концепт не может быть собственным псевдонимом.
• similar-tuples
  Эта взаимосвязь используется между кортежами концептов и аналогична essence-alias для item-концептов – она идентифицирует кортежи с эквивалентными определениями. Примером может служить почтовый адрес, который может отражаться в разных форматах, но содержать эквивалентные данные.
• requires-element
  Эта взаимосвязь используется между кортежами или item-концептами и определяет требования в пределах отчета XBRL. Если в отчете используется факт для концепта на стороне «от», то в отчете также обязательно должен быть факт для концепта на стороне «к».

https://habrahabr.ru/post/333738/

• Node JS
• Bot Framework Emulator
• Visual Studio Code (не обязательный параметр)

Установка Node.JS

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs
sudo apt-get install -y build-essential

Установка Bot Framework Emulator под Linux

arch

botframework-emulator-3.5.29-x86_64.AppImage

Установка Visual Studio Code

Создание нашего первого чат бота

npm init

npm install --save botbuilder
npm install --save restify

var restify = require('restify');
var builder = require('botbuilder');

// Setup Restify Server
var server = restify.createServer();
server.listen(process.env.port || process.env.PORT || 3978, function () {
   console.log('%s listening to %s', server.name, server.url); 
});

// Create chat connector for communicating with the Bot Framework Service
var connector = new builder.ChatConnector({
    appId: process.env.MICROSOFT_APP_ID,
    appPassword: process.env.MICROSOFT_APP_PASSWORD
});

// Listen for messages from users 
server.post('/api/messages', connector.listen());

// Receive messages from the user and respond by echoing each message back (prefixed with 'You said:')
var bot = new builder.UniversalBot(connector, function (session) {
    session.send("You said: %s", session.message.text);
});

Запуск и отладка чат бота

node app.js

P.S. Опрос: нужна ли подобная статья применительно к C# и .Net Core

	Да
	Нет
	Мне всё равно

Никто ещё не голосовал. Воздержавшихся нет.

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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333824/

1. Отключите самозащиту антивируса (главное окно -> Настройка -> Дополнительно -> Самозащита -> Снять галку у пункта «Включить самозащиту» -› нажать ОК).
2. Зайдите в папку C:\Program Files (x86)\Kaspersky Lab\Название продукта (например, Kaspersky Internet Security) \skin\resources\neutral\sounds.
3. Переименуйте хранящийся в этой папке файл infected.wav во что-нибудь другое.
4. Скачайте файл infected.wav и скопируйте его в ту же папку.
5. Обязательно включите «Самозащиту» обратно!
6. Можете скачать тестовый файл с нашей страницы support.kaspersky.ru/viruses/general/459, чтобы проверить звук.
7. ????
8. Profit!

https://habrahabr.ru/post/333822/

Чему уже научились сверточные искусственные нейронные сети (ИНС) и как они устроены?

1. Предисловие.

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

2. Прорыв.

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

Приведу простой и очень наглядный пример:

2002:

Earth Simulator – один из самых быстрых в мире вычислительных комплексов. Он был построен в 2002 году. До 2004 года эта машина оставалась самым мощным вычислительным устройством в мире.

Стоимость: $350.000.000.
Площадь: четыре теннисных корта,
Производительность: 35600 гигафлопс.

2015:

NVIDIA Tesla M40/M4: GPU для нейронных сетей

Стоимость: $5000
Площадь: помещается в карман,
Производительность: До 2,2 Терафлопс производительности в операциях с одинарной точностью с NVIDIA GPU Boost

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

3. Операция свертки.

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

Что же это такое?
Попробуем разложить всё по полочкам:

Котики

Экспериментируя на животных, David Hubel и Torsten Wiesel выяснили, что одинаковые фрагменты изображения, простейшие формы, активируют одинаковые участки мозга. Другими словами, когда котик видит кружочек, то у него активируется зона “А”, когда квадратик, то “Б”. И это сподвигло ученых написать работу, в которой они изложили свои идеи по принципам работы зрения, а затем они это подтвердили опытами:

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

Математика

Графические редакторы давно используют математику для изменения стиля изображения, но как оказалось, те же самые принципы можно применить и в области распознавания образов.
Если мы рассмотрим картинку как двумерный массив точек, каждую точку — как набор значений RGB, а каждое значение — это просто 8-ми битовое число, то получим вполне себе классическую матрицу. Теперь возьмем и придумаем свою, назовем её Kernel, матрицу, и будет она такой:

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

Вот что мы получим:

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

Вот пример наборов Kernel матриц:

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

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

Подводные камни

Поняв, как работают мозги котов и как применить математический аппарат, мы решили создать свой фича-экстрактор! Но… подумав сколько фич нужно извлекать, сколько уровней извлечения нам надо и, прикинув, что для нахождения сложных образов мы должны анализировать сочетания фич “каждая с каждой” мы поняли, что памяти для хранения этого всего нам точно не хватит.
На помощь вновь пришли математики и придумали операцию объединения (pooling).
Суть ее проста — если в определенной области присутствует фича высокого уровня, то можно откинуть другие.

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

На практике чередуют слои свертки и объединения несколько раз.

Финальная архитектура.

Применив всё, что описано выше, можно получить вполне рабочую архитектуру фиче-экстрактора, не хуже, чем у кошки в голове, более того, в настоящее время точность распознавания компьютерного зрения достигает в отдельных случаях >98%, а, как подсчитали ученые, точность распознавания образа человеком составляет в среднем 97%. Будущее пришло, Скайнет наступает!

Вот примеры нескольких схем реальных фича-экстракторов:

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

Это видео просто шикарно демонстрирует как работают фича-экстракторы:

4. Кто всем заправляет?

1. Tensorflow

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

Пример того, что дает Inception-v3 (классификатор изображений от Google, построенный на Tensorflow) и натренированный на ImageNet наборе изображений:

2. MS Cognitive Services (The Microsoft Cognitive Toolkit)

Компания Microsoft пошла другой дорогой, она предоставляет готовые API, как за деньги, так и бесплатно, с целью ознакомления, но лимитируя количество запросов. API — очень обширные, решают десятки задач. Это всё можно попробовать прямо на их сайте.
Можно, конечно, использовать MSCT так же как и TF, там даже синтаксис и идея очень похожи, оба описывают графы с заглушками, но ведь зачем тратить время, когда можно использовать уже обученные модели?

3. Caffe (Caffe2)

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

Яркий пример применения Caffe:
Rober Bond, используя натренированную на распознавание котов сеть, соорудил автоматизированную прогонялку котов с его газона, которая при обнаружении кота на видео, поливает его водой.

Существует еще много разных, популярных в свое время библиотек, оберток, надстроек: BidMach, Brainstorm, Kaldi, MatConvNet, MaxDNN, Deeplearning4j, Keras, Lasagne(Theano), Leaf, но лидером считается Tensorflow, в силу своего бурного роста за последние два года.

5. Области применения (вместо заключения)

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

https://habrahabr.ru/post/333772/