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

Оказывается, некоторые программы невозможно удалить. Например, на отдельных моделях Samsung невозможно удалить Facebook (есть только опция 'disable'). Говорят, на Samsung S9 вдобавок предустановлены «неудаляемые» приложения Microsoft.

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

Всё это надо зачистить.

В 2019 году была написана потрясающая статья Parse, don’t validate. Я крайне рекомендую изучить её всем программистам (а также недавнее дополнение к ней Names are not type safety). Её основная идея заключается в том, что существует два способа проверки валидности входящих данных функции:

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

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

Инструмент контроля типов является хрестоматийным примером валидатора!

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

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

Иногда 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)? Какие ошибки встречаются наиболее часто, и что их вызывает?

Бытует мнение, что IT-специалисты — народ своеобразный, и все у них заточено под компьютеры и технологии. Что даже Новый год они встречают вместе с нейросетями среди роботов в костюме из полупроводников за написанием очередной программы для оборудования по вакцинации 5G-станций. И что питаются эти ребята инфракрасным излучением и двоичным кодом. Опросы показали, что для ИТ-специалистов Новый год — это традиционный семейный и домашний праздник, на котором принято ставить ёлку, готовить «Оливье», пить шампанское и запускать фейерверки. А в большинстве компаний принято отмечать праздник новогодним корпоративом, который чаще всего проходит в ресторане, с кокаином и шлюхами с алкоголем и высшим руководством. Но статистика и стереотипы не отображают истинное положение дел отдельно взятого человека. Поэтому про празднование НГ, про подарки, и вообще как хотели бы провести праздники, и как провели новогодние выходные, спросим у самих айтишников! Ниже приведена подборка комментариев хабровчан к постам с поздравлениями Нового года за предыдущие годы.

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

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

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

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

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

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

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