Сейчас модно писать, что ML пришел туда и все стало отлично, DL пришел сюда и все стало замечательно. А к кому-то пришел сам AI, и там все стало просто сказочно! Возможна ли ситуация, когда к нам пришел волшебный ML/DL и все стало сложнее, тяжелее и на порядок запутаннее? Безусловно! Разберем такой пример.

Десятки лет при сравнении кодеков и алгоритмов обработки видео исследователи использовали старые добрые метрики PSNR и SSIM с довольно простыми формулами и были счастливы. Но прогресс невозможно остановить! На их место пришли новые метрики и… тут выяснилось, что они взламываются.

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

В этот момент собеседники обычно дружно спрашивают, кому это надо? О, поверьте, есть люди, которым не просто надо, а сильно надо! Представьте себе, что вы руководитель подразделения и у вас жесткие KPI (маркетинг требует обогнать конкурентов, от этого зависят нехилые годовые бонусы у всех сотрудников и особенно у вас). Чтобы улучшить видеокодек на условные 4%, требуются десятки человеко-месяцев труда весьма высокооплачиваемых инженеров, причем, бывает, получается, а бывает, не очень. И тут выясняется, что можно за пару недель работы одного зеленого стажера подшаманить метрику на 7%. Ваши действия? Вспоминается жизненный анекдот «тут-то мне карта и поперла»…

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

Впрочем обо всем по порядку…

Кому интересен цирк с конями взлом метрик — го под кат.

Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:

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

Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.

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

Введение

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

Напоминаем, что Centrifugo – это сервер сообщений в реальном времени (real-time). Сервер держит постоянные соединения от пользователей приложения и предоставляет API для моментальной рассылки какого-либо уведомления активным пользователям, подписанным на канал уведомления. Можно использовать для создания чатов, "живых" комментариев, multiplayer игр, стримить данные и метрики (например, быстро меняющиеся курсы валют).

Новая Центрифуга v3 нацелена упростить использование сервера в простых real-time приложениях. Улучшена производительность сервера, существующие фичи обросли новой функциональностью. Centrifugo v3 поддерживает однонаправленные (unidirectional) real-time транспорты, клиентский JSON протокол значительно ускорен. Появилась экспериментальная поддержка высокопроизводительного движка на основе Tarantool. Помимо HTTP теперь есть возможность проксировать клиентские события используя GRPC протокол. Добавлены новые методы и поля серверного API, а также анонсирована PRO версия сервера, нацеленная на бизнес-пользователей.

Когда я начал работу с Kubernetes, и Infrastructure as Code (IaC), я быстро понял, что мне нужно решение для работы с секретами. Когда я поискал в интернете, то не увидел единого мнения по поводу практического подхода к проблеме, подходящего ко всем ситуациям. Поэтому, в этом году, я поставил себе задачу изучить, какие решения для управления секретами приложения и инфраструктуры существуют, решить, которое из них я считаю лучшим и освоить его. В конце исследования, я пришел к выводу, что HashiCorp Vault перехвален, а Mozilla SOPS с KMS и Git неоправданно недооценены.

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

[Если вы спешите, проскрольте ниже к урокам и гляньте на открытый код graphql-schema-registry]

На сегодняшний день существуют готовые (проприетарные) решения для мониторинга IP(TS)-потоков, например VB и iQ, они обладают достаточно богатым набором функций и обычно подобные решения имеются у крупных операторов, имеющих дело с ТВ-сервисами. В этой статье описывается решение на базе open source проекта TSDuck, предназначенное для минимального контроля IP(TS)-потоков по счётчику CC(continuity counter) и битрейту. Возможный вариант применения — контроль потери пакетов или потока целиком через арендованный L2-канал (который нет возможности нормально мониторить, например путём считывания счётчиков потерь в очередях).

Очень кратко о TSDuck

TSDuck это open source (лицензия 2-Clause BSD) ПО (набор консольных утилит и библиотека для разработки своих утилит или плагинов) для манипуляций с TS-потоками. В качестве входа умеет работать с IP (multicast/unicast), http, hls, dvb-тюнерами, dektec dvb-asi демодулятором, имеется внутренний генератор TS-потока и чтение из файлов. В качестве выхода может быть запись в файл, IP (multicast/unicast), hls, dektec dvb-asi и HiDes модуляторы, плееры (mplayer, vlc, xine) и drop. Между входом и выходом можно включить различные процессоры трафика, например перемаппинг PID-ов, делать скремблирование/дескремблирование, анализ CC-счётчиков, подсчёт битрейта и прочие типовые для TS-потоков операции.

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

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Spoiler. Alert!

• Не для тех, кто «уже» работает с Machine Learning. Что-то интересное будет, но маловероятно, что под катом вас ждут открытия.
• Не о Transfer Learning. Не будем говорить о том, как написать нейронную сеть на Python, а потом работать с ней из JavaScript. Никаких читов — будем писать глубокие нейронные сети именно на JS.
• Не о всех деталях. Вообще все концепции в одну статью не поместятся, но необходимое, конечно, разберем.