Недавно на eBay мне попалась партия интересных USB-девайсов (Epiphan VGA2USB LR), которые принимают на вход VGA и отдают видео на USB как веб-камера. Меня настолько обрадовала идея, что больше никогда не придётся возиться с VGA-мониторами, и учитывая заявленную поддержку Linux, я рискнул и купил всю партию примерно за 20 фунтов (25 долларов США).

Получив посылку, я подключил устройство, но оно даже не подумало появиться в системе как UVC. Что не так?

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

TL;DR. В большинстве категорий теперь выделяются явные лидеры — несколько лет назад такого не было. Это помогает накоплению знаний. Поэтому Навыки владения инструментами в среднем становятся глубже у разработчиков всех уровней.

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

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

Результаты

Итак, к делу! Возьмите чай/кофе/напиток на свой выбор и посмотрим на результаты…

В книге ”Masters of Doom” о компании id Software и её влиянии на массовую культуру Дэвид Кушнер размышлял о необычном стиле работы ведущего программиста Джона Кармака.

Чтобы повысить производительность и не отвлекаться от работы над движком Quake, тот принял агрессивный подход — начал постепенно смещать начало рабочего дня. В конце концов Джон садился программировать вечером, а заканчивал перед рассветом. Эти непрерывные отрезки тишины, изоляции и глубокой работы позволили ему создать первый в мире сверхбыстрый 3D-движок. Игра Quake произвела настоящий фурор.

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

Недавно Facebook выпустил то, что именует «новой платформой финансовых сервисов» под названием Libra. Она позиционируется как цифровая расчётная система, основанная на корзине международных валют, которые управляются на «блокчейне» и хранятся в денежном пуле, управляемом из Швейцарии. Цели проекта амбициозны и влекут масштабные геополитические последствия.

В Financial Times и New York Times много разумных статей о необоснованных денежных и экономических предположениях в основе предлагаемой финансовой системы. Но не хватает специалистов, способных на анализ с технической точки зрения. Не так много людей работают над финансовой инфраструктурой и публично говорят о своей работе, поэтому данный проект не слишком освещён в технических СМИ, хотя его внутренности открыты для всего мира. Я имею в виду открытые исходники в репозиториях Libra и Calibra Organisation.

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

Низкая задержка DNS — ключевой фактор для быстрой работы в интернете. Чтобы её минимизировать, важно тщательно подобрать DNS-серверы и анонимные рилеи. Но первым делом следует избавиться от бесполезных запросов.

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

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

Опубликованная месяц назад статья Алексис Бингесснер «Рендеринг текста вас ненавидит» очень мне близка.

В далёком 2017 году я разрабатывал интерактивный текстовый редактор в браузере. Неудовлетворённый существующими библиотеками на ContentEditable, я подумал: «Эй, да просто заново реализую выделение текста! Разве это сложно?» Я был молод. Наивен. Прикинул, что справлюсь за две недели. На самом деле попытка решить эту проблему отняла несколько лет моей жизни, в том числе год оплачиваемой работы с утра до вечера по разработке текстового редактора для новой ОС.

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

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

Ровный и быстрый конвейер выдаёт в точности нужное количество продукции, все его этапы сбалансированы с точки зрения эффективности и скорости. Он избегает пустой траты времени или ресурсов, по образцу методологии 3M от Toyota Production System.

Теперь асинхронную связь внедряют не только на удалёнке

Иллюстрация: Yin Weihung

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

Только не совсем понятно, почему.

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

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

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

Эта история особенно впечатляет. В самом деле, как часто у вас один поток несколько секунд крутится в цикле из семи команд, удерживая блокировку, которая останавливает работу 63 других процессоров? Это просто восхитительно, в каком-то ужасном смысле.

Вопреки распространённому мнению, у меня на самом деле нет машины с 64 логическими процессорами, и я никогда не видел этой конкретной проблемы. Но с ней столкнулся мой друг, этот ботан зацепил меня он попросил о помощи, и я решил, что проблема достаточно интересная. Он выслал трассировку ETW с достаточным количеством информации, чтобы коллективный разум в твиттере быстро решил проблему.

Мы в поте лица готовим очередную мажорную версию Tokio, асинхронной среды выполнения для Rust. 13 октября для слияния в ветку оформлен пул-реквест с полностью переписанным планировщиком задач. Результатом станет огромное улучшение производительности и уменьшение задержки. В некоторых тестах зафиксировано десятикратное ускорение! Как обычно, синтетические тесты не отражают фактическую выгоду в реальности. Поэтому мы также проверили, как изменения в планировщике повлияли на настоящие задачи, такие как Hyper и Tonic (спойлер: результат замечательный).

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

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

Я много писал о проектах компьютерного зрения и машинного обучения, таких как системы распознавания объектов и проекты распознавания лиц. У меня также есть опенсорсная библиотека распознавания лиц на Python, которая как-то вошла в топ-10 самых популярных библиотек машинного обучения на Github. Всё это привело к тому, что новички в Python и машинном зрении задают мне много вопросов.



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

Где-то в 2014 году в дампах исходного дерева BSD 3 я нашла файл /etc/passwd с паролями всех ветеранов, таких как Деннис Ричи, Кен Томпсон, Брайан В. Керниган, Стив Борн и Билл Джой.

Для этих хэшей использовался алгоритм crypt(3) на основе DES — известный своей слабостью (и с длиной пароля максимум 8 символов). Поэтому я подумала, что будет легко взломать эти пароли ради удовольствия.

Берём стандартные брутеры john и hashcat.

Написанной мной инструмент командной строки Sloc Cloc and Code (scc), который теперь доработан и поддерживается многими отличными людьми, подсчитывает строки кода, комментарии и оценивает сложность файлов внутри каталога. Здесь нужна хорошая выборка. Инструмент подсчитывает в коде операторы ветвления. Но что такое сложность? Например, заявление «У этого файла сложность 10» не очень полезно без контекста. Чтобы решить эту проблему, я запустил scc на всех исходниках в интернете. Это также позволит найти какие-то крайние случаи, которые я не рассматривал в самом инструменте. Мощное испытание методом грубой силы.

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

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

Голые цифры:

• 9 985 051 репозиториев всего
  
• 9 100 083 репозитория хотя бы с одним файлом
  
• 884 968 пустых репозиториев (без файлов)
  
• 3 500 000 000 файлов во всех репозиториях
  
• Обработано 40 736 530 379 778 байт (40 ТБ)
  
• Идентифицировано 1 086 723 618 560 строк
  
• Распознано 816 822 273 469 строк с кодом
  
• 124 382 152 510 пустых строк
  
• 145 519 192 581 строк комментариев
  
• Общая сложность по правилам scc: 71 884 867 919
  
• 2 новые ошибки, найденные в scc

Рендеринг текста: насколько сложным он может быть? Оказывается, невероятно сложным! Насколько мне известно, буквально ни одна система не выводит текст «идеально». Где-то лучше, где-то хуже.

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

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

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

Типичный вопрос разработчиков под Windows: «Почему здесь до сих пор нет <ВСТАВЬТЕ ТУТ ЛЮБИМУЮ КОМАНДУ LINUX>?». Будь то мощное пролистывание less или привычные инструменты grep или sed, разработчики под Windows хотят получить лёгкий доступ к этим командам в повседневной работе.

Подсистема Windows для Linux (WSL) сделала огромный шаг вперёд в этом отношении. Она позволяет вызывать команды Linux из Windows, проксируя их через wsl.exe (например, wsl ls). Хотя это значительное улучшение, но такой вариант страдает от ряда недостатков.

MS-DOS 2.0 хранит буфер чтения с диска, но не буфер записи. Буфер чтения важен: он позволяет избежать повторного чтения. И его можно аннулировать, когда том отмонтирован.

Но погодите, мы же не отмонтируем дискеты. Мы их просто вынимаем.

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

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

Текущая конфигурация

CardGames.io работает на AWS. Все html-страницы, CSS, JavaScript и изображения хранятся на S3. У нас есть API на C#, размещённый на Elastic Beanstalk, он работает на серверах Linux под управлением .NET Core с Docker. Наконец, мы используем CloudFront CDN перед статикой на S3 и API. Ниже приведён счёт EC2 за август 2019 года. У нас есть несколько других инстансов, но API работают на m1.small (да, вероятно, t2.small лучше подходит) с классической балансировкой нагрузки. Если суммировать выделенное красным, то выходит $164,21 в месяц, неплохо. Я даже включил туда EBS, поскольку не уверен, как разбить эти расходы, у нас ведь несколько проектов на EC2.

Поисковая выдача на ListenNotes.com

Listen Notes — это поисковая система и база данных подкастов. Технология на самом деле очень скучная. Никакого ИИ, глубокого обучения или блокчейна. «Если вы должны объявлять о внедрении ИИ, то вы не используете Настоящий ИИ» :)

После прочтения этой статьи вы сможете повторить мой проект или легко сделать нечто подобное. Не придётся нанимать много разработчиков. Помните, когда Instagram привлёк $57,5 млн и отошёл к Facebook за $1 млрд, у них было всего 13 сотрудников — и это не только разработчики. Покупка Instagram произошла в начале 2012-го. Сейчас 2019 год, и сегодня как никогда просто создать что-то значимое с крошечной инженерной командой — даже из одного человека.

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

Это псевдорасшифровка моей презентации на !!Con 2019.

В большинстве используемых сегодня процессорных архитектур есть инструкция под названием popcount, сокращённо от 'population count'. Она делает следующее: подсчитывает количество установленных битов в машинном слове. Например (возьмём 8-битные слова для простоты), popcount(00100110) равно 3, а popcount(01100000) равно 2.

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