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

На прошлой неделе моё внимание привлёк этот коммит:

858d2e434dd 8372584: [Linux]: Замена чтения proc для получения CPUtime потока на clock_gettime

diffstat выглядел интересно: +96 вставок, -54 удалений. В changeset был добавлен бенчмарк JMH из 55 строк, что означало реальное уменьшение кода продакшена.

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

Мне нравится, когда можно увидеть обратную сторону; какой бы формальной и железобетонной ни казалась спецификация ES-262, мы всё равно замечаем (если знать, куда смотреть) в ней все хорошие и плохие решения, принятые сотнями людей, разрабатывавших язык. У JavaScript есть характер. Да, он не всегда делает всё в точности так, как можно ожидать, но на мой взгляд, JavaScript обладает настоящим очарованием, которое можно оценить, если глубоко его изучить.

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

Прямо сейчас в вашем ядре есть баги, которые не найдут ещё многие годы. Я знаю это, потому что проанализировал 125183 бага с отслеживаемой меткой Fixes: за 20-летнюю историю Git ядра Linux.

Прежде чем баг обнаружат, он в среднем живёт в ядре 2,1 года. Но в некоторых подсистемах ситуация гораздо хуже: для драйверов шины CAN этот срок в среднем составляет 4,2 года, для сетевого протокола SCTP — 4,0 года. Самый долгоживущий баг в моём датасете (переполнение буфера в ethtool) прятался в ядре 20,7 года. Баг, который я проанализирую в статье подробно (утечка refcount в netfilter), прожил 19 лет.

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

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

Но вот что я вам скажу: в основе этих инструментов не лежит магия. Для них достаточно примерно двухсот строк простого Python.

Давайте с нуля напишем собственный функциональный кодинг-агент.

Часть I: Основы

«В теории теория и практика одинаковы. На практике это не так». — авторство приписывается разными специалистам по computer science

Загадка

Два часа утра. Я смотрю на совершенно нелогичные данные профилирования.

В процессе работы над загрузчиком для SoC RISC-V у нас возникла проблема с производительностью. Загрузчик должен был искать конфигурации устройств в таблице: примерно пятьсот элементов, каждый с 32-битным ID устройства и указателем на данные конфигурации. Всё просто.

Мой коллега реализовал эту систему с помощью хэш-таблицы. «Поиск за O(1), — сказал он уверенно, — лучше уже некуда».

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

Я попробовал использовать очевидную оптимизацию: заменить хэш-таблицу двоичным поиском по отсортированному массиву. Двоичный поиск занимает O(log n), что теоретически хуже, чем O(1). Так написано в учебниках. Мой преподаватель алгоритмов был бы разочарован.

Но в результате загрузчик оказался на 40% быстрее.

Как O(log n) смогло победить O(1)? Что происходит?

Base64 — это схема кодирования двоичных значений в текст, преобразующая произвольные двоичные данные (например, изображения, файлы или любые байтовые последовательности) в безопасную печатную ASCII-строку, состоящую из 64-символьного алфавита (A–Z, a–z, 0–9, +, /). Браузеры применяют эту схему в JavaScript для встраивания двоичных данных непосредственно в код/HTML или для передачи двоичных данных в виде текста.

Недавно в браузерах появились удобные и безопасные функции для обработки Base64: Uint8Array.toBase64() и Uint8Array.fromBase64(). Хоть у них и есть множество параметров, смысл их сводится к кодированию и декодированию.

При кодировании они берут 24 бита из входных данных и разделяют их на четыре сегмента по 6 бит, и каждое 6-битное значение (в интервале от 0 до 63) соотносится с конкретным символом из алфавита Base64: первые 26 символов — это буквы A-Z в верхнем регистре, следующие 26 — a-z в нижнем, затем идут цифры 0-9 и, наконец, символы «+» и «/» в качестве 62-го и 63-го символов. Если длина входных данных не кратна трём байтам, то в качестве заполнителя используется знак «=».

Насколько же быстро могут работать эти функции?

Недавно я активно занимался отправкой и проверкой пул-реквестов проекта PyTorch, созданных с существенной помощью LLM. Этот процесс сильно отличается ситуации в начале года, когда было понятно, что LLM вполне подходит для проектов, создаваемых с нуля, но для кодовой базы в продакшене их код оставался безнадёжно низкокачественным. Можете посмотреть мои смердженные PR, в описании которых упоминается Claude Code; у Джейсона Энсела тоже был подобный опыт (ссылка на Meta*; также есть список issue, на которые он ссылался в совей статье). Сейчас всё активнее обсуждается (Саймон Уиллисон, LLVM) то, как процесс код-ревью должен адаптироваться к этой новой эпохе LLM. Мой вклад в эти обсуждения таков: внутри команд код-ревью должен поменяться, превратившись в первую очередь в механизм согласования с человеком.

Вот фотография новогодней ёлки в том виде, в котором видит матрица камеры.

Она даже не чёрно-белая, а серо-серая.

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

Уже многие годы JavaScript остаётся «рабочей лошадкой» веба. Если вам нужно сделать то, что невозможно реализовать средствами HTML и CSS, то обычно найти решение помогает JS. И это замечательно! JS помог расширить возможности пользователей, а также стимулировал прогресс HTML и CSS!

Но время идёт, функции HTML и CSS расширяются, поэтому мы должны начать заменять старые и привычные решения на JS новыми, требующими меньше JS.

Я ничего не имею против JS, но у него есть иные задачи, кроме как управление аккордеонами и внеэкранными меню навигации... Кроме того, JS нужно скачивать, распаковывать, обрабатывать, после чего он ещё часто тратит память на мониторинг и поддержку фич. Если мы сможем перенести какую-то функциональность JS в нативный HTML или CSS, тогда пользователям придётся скачивать меньше данных, а оставшийся JS сможет уделить внимание более важным задачам, с которыми (пока) не справляются HTML и CSS.

В этой статье я приведу несколько примеров; сможете придумать свои?

«История игрушек» выглядела иначе, но объяснить это будет немного сложно.

В 1995 году компьютерная графика была самой важной темой в индустрии, и в центре этого ажиотажа находилась Pixar. Эта студия уже заставила Disney перейти на компьютеры и выиграла первый Оскар за компьютерную короткометражку (Tin Toy). ПО Pixar использовалось в крупных голливудских фильмах наподобие «Парка юрского периода».

Следующим шагом стала «История игрушек» (Toy Story), которую рекламировали как первую анимационную картину, полностью созданную в компьютерной графике¹. Даже после предыдущих успехов Pixar этот шаг оставался рискованным. Будут ли продаваться билеты на полностью цифровой фильм?

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

У историков, изучающих болезни, возникла проблема. При исследовании образцов ДНК древнего человека генетики обнаружили гены, принадлежащие бактерии чумы Yersinia pestis, и это означало, что её эпидемия бушевала в Евразии пять тысяч лет назад. То есть почти за 3500 лет до «первой чумы», названной Юстиниановой по имени властвовавшего тогда римского императора. Как назвать этот обнаруженный «приквел» эпидемии? Сейчас самое популярное название — это чума позднего неолита и бронзового века (Late Neolithic-Bronze Age, LNBA), но это слишком уж многословно. Однако у учёных есть и другие причины для беспокойства. Есть вероятность, что это открытие станет ещё одним гвоздём в крышку гроба давно сложившегося убеждения о том, когда и почему человечество обрело множество влияющих на нас сегодня инфекционных заболеваний. В образцах, взятых у древних людей, обнаружилась галерея доисторических ужасов. Эти так называемые зоонозные заболевания донимали животных ещё до того, как перенеслись на человека, поэтому считается, что они совершили этот межвидовой переход после изобретения человечеством сельского хозяйства примерно двенадцать тысяч лет назад. Но в процессе изучения генетиками всё более глубоких слоёв прошлого обнаруживается, что переход произошёл гораздо позже — крупномасштабные вспышки происходили в Европе, как вы уже могли догадаться, примерно пять тысяч лет назад. Эти открытия не только покончили со старыми представлениями об эволюции заболеваний, но и заставили нас переосмыслить поворотный доисторический период. Как в то время распространялись болезни? Действовали ли тогда патогены так же, как и сегодня? Могла ли сама чума стать причиной бронзового века, заложив фундамент европейской цивилизации?

Компиляторы то и дело удивляют меня очень хитрыми трюками. Когда я впервые увидел эту оптимизацию, то едва смог поверить в её реальность. Я изучал оптимизацию циклов и написал простую функцию, суммирующую все числа до заданного значения...

В этой статье я изложу то, что почерпнул из чтения RFC 9111 (2022 год) — последнего стандарта по HTTP-кэшингу.

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

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

В конце 2021 года, уже сильно после начала локдауна, моя одержимость кроссвордом газеты The New York Times превратилась в хобби-проект. Я хотел написать приложение с кроссвордами, понял, что мне нужны сами кроссворды, попробовал сочинять их вручную, осознал унылость этого процесса и задался вопросом: можно ли генерировать их алгоритмически? В этом году я наконец-то выпустил Crosswarped для iOS и Android — игру в кроссворды, созданную на основе генератора, описываемого в этой статье.

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

Такое поведение грубо, оно заставляет других людей впустую тратить время и идёт вразрез с долгом разработчика ПО.

Ваша задача — выпускать код, который доказанно работает.

Мы, разработчики ПО, не просто производим код; сегодня даже можно сказать, что для этого предназначены LLM. Мы должны выпускать код, который работает, и приложить к нему доказательство его работы. Если вы этого не делаете, то просто сбрасываете бремя настоящей работы на того, кто должен будет проверять ваш код.

Приветствую, Новенький! Рад, что вы завершили онбординг в нашей корпорации ACME. У меня для вас есть первый тикет. Это простая задача, всего два сторипоинта, но она позволит вам немного научиться тому, как взаимодействуют наши сервисы. Просто реализуйте SLO доступности нашего сервиса Foo. Вы ведь знаете, как реализуются SLO?

Думаю, нам стоит стремиться к четырём девяткам. Я уверен, что вы в курсе всех best practices нашей отрасли, поэтому не буду надоедать вам советами. Если нужно, внизу есть бумажная Google SRE Book. Мне кажется, это быстрая задача; сможете представить свой SLO к пятничному демо?

Будущее плиточных веб-макетов уже настало! После того, как Mozilla заложила фундамент, потребовались годы работы команды Apple WebKit и множество этапов обсуждений в CSS Working Group с разработчиками всех браузеров, чтобы стало понятно, как всё это должно работать.

Представляем вашему вниманию CSS Grid Lanes.

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

Но я не такой.

В Интернете я всегда стремлюсь получить понятный и запоминающийся цифровой идентификатор. Многие годы мне удавалось подбирать идентификаторы в виде моего имени + фамилии в Instagram* (@jlaf) и осмысленных слов на других платформах (@explain, @discontinue). Поэтому когда ДТС в третий раз прислал мне письмо с напоминанием о необходимости обновления номера, у меня сработал тот же инстинкт: почему я даже не задумался о том, чтобы получить номер с красивым сочетанием символов?

Хотите увидеть нечто любопытное? Вот, как устранили проблему «антеннагейта» на iPhone в 2010 году. 20 байт.

iOS 4.0: 8d ff ff ff 91 ff ff ff 95 ff ff ff 99 ff ff ff 9d ff ff ff iOS 4.0.1: 86 ff ff ff 98 ff ff ff 9e ff ff ff a7 ff ff ff b0 ff ff ff

Контекст: в 2010 году, когда выпустили iPhone 4, пользователи заметили, что если взять телефон определённым образом, то количество полосок сигнала сети падает с 5 до примерно 2. Спустя насколько недель компания опубликовала письмо, в котором свалила вину за это на неправильную формулу.

В этой статье я представлю мой завершённый очень быстрый алгоритм преобразования дат.. Он обеспечивает существенный прирост скорости, по величине сравнимый с приростом, достигнутым предыдущим самым быстрым алгоритмом (Neri-Schneider 2021) относительно его предшественника (C++ Boost). Полная реализация алгоритма на C++ выпущена как свободное и бесплатное ПО (лицензия BSL-1.0).

Алгоритм генерирует точные результаты за период ±1,89 триллиона лет, поэтому подходит для обработки полного 64-битного времени UNIX (в секундах).