Очень рад объявить о завершении моего первого компилятора для языка программирования! Malcc — это инкрементальный AOT-компилятор Lisp, написанный на C.

Вкратце расскажу о его многолетней разработке и что я узнал в процессе. Альтернативное название статьи: «Как написать компилятор за десять лет или меньше».

(В конце есть TL;DR, если вас не волнует предыстория).

Замена Disqus на Commento снизила размер страниц в 10 раз

Когда я завёл блог, то установил Disqus для комментариев. Это был естественный выбор: сайты по всему интернету ставили Disqus, его легко настроить, и есть бесплатный вариант использования. Я спокойно интегрировал движок комментариев и двинулся дальше.

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

Я ошибался.

27 марта мы в Mozilla объявили о начале стандартизации WASI, системного интерфейса WebAssembly (WebAssembly system interface).

Зачем: разработчики начали применять WebAssembly за пределам браузера, потому что WASM обеспечивает быстрый, масштабируемый, безопасный способ запуска одинакового кода на всех машинах. Но у нас пока нет прочного фундамента для такой разработки. Вне браузера нужен некий способ общения с системой, то есть системный интерфейс. А у платформы WebAssembly его пока нет.

Что: WebAssembly — это ассемблер для концептуальной, а не физической машины. Он работает на различных архитектурах, поэтому и системный интерфейс нужен для концептуальной ОС, чтобы работать на разных операционных системах.

Вот что такое WASI: это системный интерфейс для платформы WebAssembly.

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

Впервые нейронный вокодер работает в реальном времени на одном процессорном ядре телефона, а не на высокоскоростном GPU. Итоговый битрейт 1600 бит/с примерно в десять раз меньше, чем выдают обычные широкополосные кодеки. Качество намного лучше, чем у существующих вокодеров с очень низким битрейтом и сопоставимо с более традиционными кодеками, использующими более высокий битрейт.

Изучение глифов на терминалах DEC VT100 и VT220

Недавно я немного увлёкся эмуляцией аналоговых медиа: хотелось воссоздать растровую графику ЭЛТ, как на «стеклянных терминалах» прошлого, таких как культовая серия VT от Digital Equipment Corporation (DEC). В процессе возник ряд вопросов об особенностях отображения шрифтов в пиксельной графике ЭЛТ. Интересно, как на самом деле выглядели шрифты и можно ли реконструировать их по спецификациям?


Современные шрифты TrueType воссоздают глифы VT220. Имейте в виду, что VT-терминалы поддерживали два режима разрешения: один на 132 символа в строке и один на 80 символов (char-matrix 9×10 и 10×10, соответственно), в последнем интервал расширен на один пиксель

Благодаря обилию технической информации на сайтах вроде vt100.net и bitsavers.org можно легко определить внешний вид тех шрифтов. Например, мы можем восстановить глифы из прошивки терминалов. Есть даже шрифты TrueType, которые повторяют типографику VT220: Glass TTY VT220 с растровыми строками и DEC Terminal Modern с современными, гладкими очертаниями (на иллюстрации вверху).

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

Мы пытаемся скопировать этот узор в нашей жизни и нашем обществе и потому любим ритм, песню, танец, различные радующие и утешающие нас формы. Однако можно разглядеть и опасность, таящуюся в поиске абсолютного совершенства, ибо очевидно, что совершенный узор — неизменен. И, приближаясь к совершенству, всё сущее идёт к смерти» — Дюна (1965)

Я считаю, что концепция вложений (embeddings) — одна из самых замечательных идей в машинном обучении. Если вы когда-нибудь использовали Siri, Google Assistant, Alexa, Google Translate или даже клавиатуру смартфона с предсказанием следующего слова, то уже работали с моделью обработки естественного языка на основе вложений. За последние десятилетия произошло значительное развитие этой концепции для нейронных моделей (последние разработки включают контекстуализированные вложения слов в передовых моделях, таких как BERT и GPT2).

Как известно, некоторые авторы на YouTube крайне недовольны условиями, которые предлагает эта платформа. Аналогичное сражение сейчас ведут разработчики Android-приложений на платформе Google Play. Попытаюсь за 20 минут объяснить, что не так с Android.

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

Раньше основные релизы Android приносили новые функции, которые радовали и разработчиков, и пользователей. Но с какого-то момента я уже начал бояться анонсов новых версий, и до сих пор ищу в себе силы (хех), чтобы посмотреть на список изменений и рекомендации для разработчиков к последнему релизу. И новые версии — это не единственная причина для нервотрёпки: изменения в политике Google Play Store тоже всегда забавно читать.

Недавно я узнал, что Red Hat удаляет поддержку MongoDB из Satellite (говорят, из-за изменений лицензии). Это заставило меня задуматься, что в последние несколько лет я видел кучу статей, как ужасна MongoDB и что никто никогда не должен её использовать. Но за это время MongoDB стала гораздо более зрелым продуктом. Что же случилось? Действительно ли вся ненависть объясняется ошибками в начале маркетинга новой СУБД? Или люди просто применяют MongoDB не там, где нужно?

Если вам вдруг кажется, что я защищаю MongoDB, пожалуйста, прочитайте дисклеймер в конце статьи.

Tensorflow стал стандартной платформой для машинного обучения (ML), популярной как в индустрии, так и в научных исследованиях. Создано множество свободных библиотек, инструментов и фреймворков для обучения и обслуживания моделей ML. Проект Tensorflow Serving помогает обслуживать модели ML в распределённой среде продакшна.

Наш сервис Mux использует Tensorflow Serving в нескольких частях инфраструктуры, мы уже обсуждали использование Tensorflow Serving в кодировании видео по заголовкам. Сегодня сосредоточимся на методах, которые улучшают задержку за счёт оптимизации как на сервере прогнозирования, так и на клиенте. Прогнозы модели обычно являются «онлайновыми» операциями (на критическом пути запроса приложения), поэтому основные цели оптимизации — обрабатывать большие объёмы запросов с максимально низкой задержкой.

Это продолжение статьи «Зачем Racket? Зачем Lisp?», которую я написал примерно через год после того, как открыл для себя Racket. Будучи новичком, я не мог понять дифирамбов, которые со всех сторон сыпались в адрес Lisp. Я не знал, что и думать. Как понимать, что Lisp в конце концов вызовет «глубокое просветление». Окей, как скажешь, бро.

У меня был простой вопрос: какая польза? В прошлой статье я попытался ответить на него и обобщил причины, почему кто-то захочет изучить Lisp или, в частности, Racket.

Я составил список из девяти особенностей языка, наиболее ценных для меня как новичка в Racket. Например, особенность № 5 — «создание новых языков программирования». Этот метод также называется языково-ориентированным программированием, или ЯОП.

В прошлых статьях цикла мы обсудили безопасность памяти и безопасность потоков в Rust. В этой последней статье посмотрим на последствия реального применения Rust на примере проекта Quantum CSS.

Движок CSS применяет правила CSS на странице. Это нисходящий процесс, который спускается по дереву DOM, после расчёта родительского CSS дочерние стили можно вычислять независимо: идеальный вариант для параллельных вычислений. К 2017 году Mozilla предприняла две попытки распараллелить систему стилей с помощью C++. Обе провалились.

Разработка Quantum CSS началась, чтобы повысить производительность. Улучшение безопасности — просто удачный побочный эффект.

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

Этот цикл статей опубликован выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий тикет. Все исходники для статьи лежат в этой ветке.

Ещё одна статья о страничной организации памяти?
Если вы следите за этим циклом, то видели статью «Страничная память: продвинутый уровень» в конце января. Но меня раскритиковали за рекурсивные таблицы страниц. Поэтому решил переписать статью, применив иной подход для доступа к фреймам.

TL;DR: Четыре года назад я покинул Google с идеей нового инструмента для мониторинга серверов. Идея состояла в том, чтобы объединить в одну службу обычно изолированные функции сбора и анализа логов, сбора метрик, оповещений и панели мониторинга. Один из принципов — сервис должен быть действительно быстрым, обеспечивая девопсам лёгкую, интерактивную, приятную работу. Это требует обработки наборов данных по несколько гигабайт за доли секунды, не выходя за рамки бюджета. Существующие инструменты для работы с логами часто медленные и неуклюжие, поэтому мы столкнулись с хорошей задачей: грамотно разработать инструмент, чтобы дать пользователям новые ощущения от работы.

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

Нейросеть нейросетей


Изображение brentsview под лицензией CC BY-NC 2.0

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

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

Фото Джантин Дурнбос на Unsplash

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

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

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

Есть много способов повышения веб-производительности. Один из них — предзагрузка контента, который понадобится позже. Префетчинг CSS, предварительный рендеринг полной страницы или резолвинг доменного имени. Делаем всё заранее, а потом мгновенно отображаем результат! Звучит круто.

Ещё круче, что это очень просто реализовано. Пять тегов <link rel> дают браузеру команду на предварительные действия:

<link rel="prefetch" href="/style.css" as="style" />
<link rel="preload" href="/style.css" as="style" />

<link rel="preconnect" href="https://example.com" />
<link rel="dns-prefetch" href="https://example.com" />

<link rel="prerender" href="https://example.com/about.html" />

Недавно меня пригласили выступить с вечерней лекцией в Типографском обществе Австрии. Для меня стало большой честью последовать по стопам таких светил, как Мэтью Картер, Вим Краувел, Маргарет Калверт, Эрик Шпикерман и покойная Фреда Сэк.

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

Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

Девушка на скутере. Иллюстрация freepik, логотип Nomad от HashiCorp

Kubernetes — это 300-килограммовая горилла для оркестровки контейнеров. Она работает в некоторых самых крупных контейнерных системах в мире, но дорого обходится.

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

Новая структура данных Redis 5 под названием «потоки» (streams) вызвала живой интерес в сообществе. Как-нибудь я поговорю с теми, кто использует потоки в продакшне, и напишу об этом. Но сейчас хочу рассмотреть немного другую тему. Мне начинает казаться, что многие представляют потоки неким сюрреалистичным инструментом для решения ужасно трудных задач. Действительно, эта структура данных *также* осуществляет обмен сообщениями, но будет невероятным упрощением считать, что функциональность Redis Streams ограничена только этим.

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