Иногда YouTube или Twitch не подходят как стриминговая платформа — скажем, если вы пилите портал с вебинарами или контентом 18+, нарушаете авторские права или хотите максимально отгородить свою трансляцию от остального интернета. У них есть много альтернатив как в виде сервисов (те же минусы, недостаток контроля и непредсказуемая политика), так и в виде self-hosted решений. Проблема опенсорсных стриминговых проектов в том, что все они начинаются с крохотной связки из пары технологий, а затем отчаянно пытаются вырасти в сервис, добавляя сложные веб-интерфейсы, чаты, библиотеки стримов и в конечном счёте отдаляясь от исходной цели: дать миру инструмент, который по понятному мануалу позволит запустить свой сервер трансляций. Что с ним будет дальше, в какие системы будет встроена эта картинка — это только ваше личное дело, а самописный аналог твича с лагающими и отваливающимися сервисами и периодически валящимся билдом не нужен никому, кроме его разработчиков. Поэтому в этой статье мы разберём минимальную цепочку действий для запуска своего RTMP-сервера с плеером.

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

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

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

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

За последний год разработчики Vimeo писали код бэкенда на множестве языков — PHP, Go, Ruby, Python, NodeJS, Java, C, C++ и немного на Rust.

В 2004 году мы начинали всего с одного: PHP. Это был идеальный язык для новых стартапов наподобие Vimeo. Интерпретатор PHP позволял предпринимателям быстро разрабатывать прототипы и имел большую стандартную библиотеку, позволявшую избавиться от мороки с повседневными задачами типа отправки писем и доступа к базам данных.

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

WebAssembly позволяет запускать код на разных языках программирования внутри браузера, и сейчас это не только способ разрабатывать веб-приложения не на JS, но и возможность использовать браузер как кроссплатформенную, легкодоступную песочницу для тестирования. Например, проект Wasmino позволяет эмулировать ядро Arduino в браузере и запускать на нём код прямо из IDE.

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

Доверие — высочайшая форма мотивации. Оно выявляет в людях самое лучшее.

Стивен Р. Кови, «Семь навыков высокоэффективных людей»

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

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

«Наконец-то, у нас появился Винсент, я могу поручить ему заняться A и B; Тед будет делать C, D
и E, Джен займётся F, G и H, а я смогу добраться до I, J, K, L и M».

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

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

Неужели сегодня можно раскрыть преступление вообще не вставая из-за компьютера? Только на основании следов, которые люди оставляют в базах данных, в истории мессенджеров, в логах операторов связи, на камерах наблюдения?

Или это фантастический киберпанк?

If This Then That — сервис для автоматизации задач и создания пайплайнов из действий в разных сервисах. Это самый известный и функциональный продукт на рынке, но популярность ему навредила: полноценное создание апплетов теперь возможно только с платной подпиской, а на реддите периодически появляются жалобы на нестабильную работу сервиса. Как и в случае с любым полезным но платным продуктом, ищущий альтернативы обрящет их в опен-сорсном комьюнити. Мы сравним три self-hosted инструмента: Huginn, Beehive и Node-RED, попробуем их в действии и выберем лучший по функционалу и удобству использования.

В начале фильма «Терминатор 2: Судный день» Джон Коннор использует лэптоп для подбора PIN украденной дебетовой карты.


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


Номеронабиратель (War Dialer) из «Военных игр» (1983 год)


Чёрный ящик из «Тихушников» (1992 год)

Недавно я вспомнил эту сцену из «Терминатора 2», поэтому начал гуглить «лэптоп из Терминатора 2».

Оказалось, что это Atari Portfolio — первый в мире палмтоп-компьютер («наладонный» компьютер). Он был выпущен в июне 1989 года.

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

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

Если ваше приложение становится чуть сложнее, то вы переходите к инструментам наподобие Gatling. Они позволяют симулировать виртуальных пользователей, выполняющих различные сценарии, что намного полезнее, чем простая осада одного или нескольких URL. Но даже этого недостаточно, если вы пишете приложение, использующее одновременно WebSockets и HTTP-вызовы в течение долговременной сессии, а также требующее повторения по таймеру определённых действий. Возможно, я серьёзно недоглядел чего-то в документации, но мне не удалось найти способа, допустим, настроить периодическое событие, запускаемое каждые 30 секунд и выполняющее определённые действия при ответе на сообщение WebSocket, а также производящее действия по HTTP, и всё это в рамках одной HTTP-сессии. Я не нашёл такой возможности ни в одном инструменте нагрузочного тестирования (и именно поэтому написал на работе свой собственный инструмент, который надеюсь выложить в open source, если найду время на подчистку кода и отделения его от проприетарных частей).

Подробнее об этом хаке и особенностях его работы можно узнать из доклада на !!con 2020 «Playing Breakout… inside a PDF!!»

Если вы его не смотрели, то попробуйте открыть файл breakout.pdf в Chrome.

Как и многие из вас, я всегда считал PDF довольно безопасным форматом: автор создаёт текст и графику, после чего он открывается в программе просмотра PDF, больше ничего не делая. Несколько лет назад я мимоходом слышал об уязвимостях Adobe Reader, но особо не задумывался о том, как они могут возникать.

Изначально Adobe сделала PDF именно для этого, но мы уже выяснили, что сегодня это совсем не так. В 1310-страничной спецификации PDF (на самом деле довольно понятном и интересном чтиве) описывается безумное количество возможностей, в том числе:

• Встроенный Flash
• Аннотации в виде звука и видео
• Аннотации в виде 3D-объектов (!)
• Метаданные Web capture
• Произвольные математические функции (в том числе и Тьюринг-неполное подмножество PostScript)
• Формы с поддержкой Rich text, использующие подмножество XHTML и CSS
• Вложения в виде файлов и коллекций файлов

но самое интересное для нас…

• Это скрипты JavaScript на основе стандартной библиотеки, совершенно отличающейся от библиотеки браузера

Если вы несколько лет вообще не следили за Windows 10 и не знаете, что происходит, то пропустили одну вещь — очень горячей темой для разработчиков стала подсистема Windows для Linux, она же WSL. Среди программистов очень часто её обсуждают. Действительно, потрясающе интересная штука.

Наконец-то у нас появилась возможность запустить свой инструментарий Linux на Windows наравне с виндовыми программами. А это значит, что больше не нужно изучать странный PowerShell или пользоваться архаичной консолью CMD.EXE.

К сожалению, не всё так радужно. WSL по-прежнему является неким инородным элементом, который отделён от родной среды Windows. В частности, не может взаимодействовать с «родными» инструментами Windows.

Когда я десяток лет назад переехал в США для работы в Facebook, то понятия не имел, хорошим или плохим был оффер. Я даже не торговался и согласился на ту сумму, которую мне предложили. Отчасти это вызвано тем, что я был в восторге от приглашения, отчасти тем, что я совершенно не знал, чего мне ждать. К своей чести, Facebook предложил мне на 7–8% больше, чем изначально (думаю, так получилось, потому что они ожидали, что я буду обсуждать условия, чего я не делал).

К счастью, в последние несколько лет благодаря сайтам наподобие glassdoor и levels.fyi стало очень легко узнавать средние зарплаты и их диапазон. Не хватает только одного — информации о том, сколько можно зарабатывать, если ты по-настоящему хорош, допустим, входишь в 1% лучших инженеров FB (то есть на уровне примерно 100 инженеров). В этом посте я поделюсь своими зарплатами и карьерным ростом, чтобы дать представление о том, насколько быстро можно развиваться и как при этом будет меняться зарплата.

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

Ниже я расскажу о своём карьерном росте и зарплате, которую я получал, но если вам интересны только цифры, то вот таблица:


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

Проблема

Штрихкод — классная штука для маркировки всего на свете, от товаров до людей. Сейчас в ходу около двух десятков стандартов двумерных штрихкодов, и ещё десятки неудачных, трагически непонятых, самопальных и внутренних корпоративных вариантов, большинство из которых с треском проигрывает обычному QR-коду. Распространённость и простота реализации сделали его самым популярным среди двумерных штрихкодов, но и у него есть недостаток, характерный для всех линейных собратьев: он вмещает очень мало информации. В 2-3 килобайта можно уместить ссылку или небольшой отрывок текста, но даже небольшая картинка или обычный документ уже не влезут даже в самый большой код.

Чрезвычайно оптимальная форма для печенья Мартина Лерша.

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

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

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

• Посещён 1 миллион страниц
• Записано по 65 метрик каждой страницы
• Запрошен 21 миллион URL
• Зафиксировано 383 тысячи ошибок
• Сохранено 88 миллионов глобальных переменных

Можно ли превзойти наш анализ? Мы опубликовали наш набор данных на Kaggle, поэтому вы можете обработать данные самостоятельно.

Зачем рендерить миллион веб-страниц?

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

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

Четверть века назад как своеобразный эксперимент возник один из первых крупных поисковых движков, задумывавшийся как публичный тест основного продукта производителя серверов. В этом тесте мог принять участие любой пользователь с подключением к вебу. На то время эксперимент оказался настолько удачным, что этого никто и представить не мог. Однако проблема заключалась в том, что по сути своей это был эксперимент, который никогда не позиционировался как бизнес. Поэтому со временем эту инновацию неизбежно превзойдут другие, более подходящие компании, а данная передовая идея со временем станет частью прошлого. Но никто не собирался превращать в музейный экспонат инновации Интернета 1995 и 1996 годов: время не стояло на месте, как и веб-сайты, какими бы важными они ни были. Однако было бы здорово, если бы кто-то смог это сделать. В своей статье я пишу об AltaVista, Digital Equipment Corporation, веб-доменах и о том, как важная история может стать основой глупой маркетинговой схемы какой-то случайной компании.

Ускорители частиц вокруг нейтронной звезды в конструкции галактического маяка. Источник: A Neutrino Beacon. A. A. Jackson, arXiv:1905.05184

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

Но при этом возникает парадокс Ферми:

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

Кажется, на этот вопрос есть разумный ответ.

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

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

Недавно я наткнулся на историю столь же удивительную, сколь и ужасную:

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

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

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

…

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

…

Я получил от ИТ-директора неожиданное текстовое сообщение. «Простите за беспокойство, у нас огромная проблема. s1X. Можете прилететь сегодня во второй половине дня?» В их терминологии S1X обозначает «хуже, чем уровень серьёзности 1, потому что проблема распространилась на несвязанные с ней части бизнеса».

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

Дата-центр АНБ в Юте на картах Google Maps

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

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