Наш браузер Ladybird неплохо справляется с качественно отформатированным веб-контентом, но я решил, что будет полезно проверить его инструментами для исследования безопасности. Поэтому сегодня мы воспользуемся Domato 🍅 — DOM-фаззером из Google Project Zero, чтобы провести стресс-тест Ladybird и устранить найденные в процессе ошибки.

Работает это следующим образом: Domato генерирует рандомизированные веб-страницы со множеством по большей части валидного, но странного HTML, CSS и JavaScript. Я загружу эти страницы в отладочную сборку Ladybird и посмотрю, что получится.

Часть 1

Обобщённые системы не приводят к интересному геймплею

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

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

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

Пост не будет ни научной оценкой, ни A/B-исследованием. Это моё личное мнение после разработки игр на Rust маленькой инди-командой (два человека) в попытках заработать достаточно денег, чтобы финансировать процесс. Мы не одни из тех разработчиков с бесконечными финансами от инвестора и многолетним запасом времени. Если вы находитесь в этой категории и получаете удовольствие от многолетней разработки систем, то всё написанное ниже к вам не относится. Я рассматриваю всё с такой точки зрения: «Мне хочется создать игру максимум за 3-12 месяцев, чтобы люди могли сыграть в неё, а я — немного заработать». Статья не написана с точки зрения «Я хочу изучить Rust, а разработка игр — это весело», хотя это и вполне нормальная цель; просто она никак не согласуется с тем, чего хотим мы — заниматься разработкой игр коммерчески успешным и самодостаточным образом.

Мы выпустили несколько игр на Rust, Godot, Unity и Unreal Engine, и многие люди сыграли в них в Steam. Мы создали с нуля собственный игровой 2D-движок с простым рендерером, а также в течение нескольких лет использовали Bevy и Macroquad во многих проектах, некоторые из которых были очень нетривиальными. Кроме того, я бэкенд-разработчик на полную ставку и пишу код на Rust. Этот пост — не какое-то поверхностное мнение после изучения нескольких туториалов или разработки небольшой игры для геймджема. За три с лишним года мы написали сильно больше ста тысяч строк кода на Rust.

Задача этого поста — развеять популярные и часто повторяемые аргументы. Но это всё-таки субъективное мнение; по большей части я написал пост, чтобы не объяснять снова и снова одно и то же. Пусть это будет справочный материал о том, почему мы, скорее всего, откажемся от Rust как от инструмента для разработки игр. Мы ни в коем случае не планируем прекращать создавать игры, просто не будем делать это на Rust.

О нашем девятимесячном пути к горизонтальному шардингу Postgres-стека Figma и о возможности обеспечения (почти) бесконечной масштабируемости.

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

С 2020 года стек баз данных Figma вырос почти в сотню раз. Это хорошая проблема, ведь она означает, что наш бизнес расширяется. Но в то же время она стала причиной технических сложностей. В течение последних четырёх лет мы усиленно старались не отставать от прогресса и избегать потенциальных проблем, связанных с ростом. В 2020 году у нас работала единственная база данных Postgres, которая хостилась на самом большом физическом инстансе AWS, но к концу 2022 года мы уже создали распределённую архитектуру с кэшированием, репликами для чтения и десятком вертикально разделённых баз данных. Мы разбили группы связанных таблиц (например, «Figma files» или «Organizations») на отдельные вертикальные разделы, что позволило нам обеспечить удобство инкрементального масштабирования и оставить достаточно пространства для дальнейшего роста.

Я форкнул и модифицировал компилятор Rust rustc. Одна фича — кэширование раскрытия процедурных макросов — привела к снижению времени инкрементальных сборок на 11-40% в различных реальных крейтах. Благодаря этому ускорились dev-сборки и меньше стал тормозить rust-analyzer (IDE IntelliSense).

Если вы специалист в повышении производительности компилятора Rust, то можете сразу перейти к разделу «Кэширование раскрытия макросов: ускорение инкрементальных сборок Rust на 40%».

Я большой поклонник автоматизированных тестов и достаточно дисциплинированный их автор. Проектирование ПО крайне сложно реализовать функционально корректно и ещё сложнее избежать регрессии в дальнейшем. Как сказал Майкл Фезерс, «легаси-код — это весь код, у которого нет тестов».

Некоторые вещи, например, конечные точки серверов, схемы баз данных и компоненты библиотек UI тестировать очень просто.

Другие вещи тестировать сложнее, например, конечные точки, вызывающие сторонние API, веб-страницы на React со сложными состояниями и асинхронные задачи, требующие детализированных записей баз данных. Airbnb мне было сложно тестировать письма со сбросом паролей, потому что отправка электронной почты выполнялась через аутсорсный сервис.

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

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

Недавно я провела в Mastodon опрос о том, насколько мои читатели уверены в том, что они хорошо понимают работу HEAD в Git. Результаты (на основании примерно 1700 голосов) меня немного удивили:

10% — 100%

36% — достаточно сильно уверен

39% — уверен в некоторой степени

15% — представления не имею

Меня удивило, что люди не уверены в своём понимании: я-то считала, что HEAD — это довольно простая тема.

Обычно, когда остальные, в отличие от меня, считают какую-то тему запутанной, причина заключается в какой-то скрытой сложности, которую я не учитываю. И в дальнейших обсуждениях выяснилось, что HEAD действительно чуть сложнее, чем я считала!

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

Хотя я уже перечислил некоторые возможные последствия для ПО в своей статье «Мы снова в кризисе ПО, но в ближайшее время ИИ никого не заменит», мне бы хотелось рассмотреть, что произойдёт, если большие языковые модели (Large Language Model, LLM) полностью заменят человеческий труд. Содержание дилеммы будет практически одинаковым для всех областей, но я сосредоточусь на разработке ПО, потому что самые громкие заявления об LLM звучат как раз в её сторону.

Мы, разработчики ПО, пользуемся git каждый день, однако большинство из нас применяет только самые основные команды, например, add, commit, push и pull, как будто на дворе по-прежнему 2005 год.

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

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

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

Я работаю над созданием Graphite, источником вдохновения для которого стал внутренний инструментарий Facebook. Когда я решил создать стартап с друзьями, то никогда раньше не слышал о Mercurial, хотя всегда страстно любил инструменты разработчика. Мой предыдущий опыт разработки включал в себя личные проекты, домашнюю работу в колледже, разработку для iOS в Google и развитие инфраструктуры в Airbnb. На протяжении всей моей карьеры использование git было таким же естественным, как воздух. Он настолько популярен, что лично я считал его единственным подходящим инструментом для создания изменений в коде и управления ими.

Забавно, что специалист по Mercurial Грегори Gregory Szorc работал рядом со мной в Airbnb, хотя я знал его только как приятного коллегу, но не представлял, что он контрибьютор.

В 2021 году мои коллеги по команде Томас и Ник раскрыли мне глаза. Они пришли из Facebook и, к моему удивлению, едва знали Git. Зато они имели глубокое понимание паттернов Mercurial и рабочего процесса Facebook на основе «многослойных diff» (stacked diff). Со временем они убедили меня в полезности этого паттерна и мы развернули направление развития компании, чтобы реализовать многослойные diff для разработчиков GitHub.

Но пост посвящён не нашему стартапу. Он о важном вопросе, не дававшем мне покоя последние три года. Почему фейсбукеры не пользуются Git? Зачем они выбрали Mercurial и создали на его основе собственные рабочие процессы? Я знаю что Google не пользуется Git, но это логично, культура разработки Google возникла на пять лет раньше Git. Facebook же был основан примерно в то же время, что и создан Git, около 2004 года, и ко времени, когда Facebook начал серьёзно выбирать инструментарий для управления исходниками, Git был старше и популярнее Mercurial. Так почему же Facebook не использует Git?

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

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

Некоторые паттерны стало возможно использовать на практике только благодаря безопасности Rust по памяти, а на C++ они слишком опасны. В статье приведён один такой пример.

Работая над внутренней библиотекой, написанной на Rust, я создал тип ошибок для парсера, у которых должна быть возможность сделать Clone без дублирования внутренних данных. В Rust для этого требуется указатель с подсчётом ссылок (reference-counted pointer) наподобие Rc.

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

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

Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go.

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

В основном я учился программированию самостоятельно. Когда у меня появлялась захватывающая идея, я разбирался, что необходимо для решения этой задачи. Например, когда я заинтересовался работой поисковых движков, то начал читать о вычислительной эффективности множеств. Так я обнаружил задачу «как понять, что я уже выполнил краулинг этого URL?», если их уже были тысячи. Чтобы ускорить ответ на этот вопрос, я использовал множество, поиск по которому занимает O(1), а не O(n).

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

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

Я решил составить собственный список проектов, поддерживающих мой интерес к программированию. Это список в стиле серии Challenging projects every programmer should try Остина Хенли.

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

Инструмент предназначен для виртуального смешения красок, он содержит солвер, генерирующий рецепты для создания цвета из имеющихся красок. Инструмент поставляется с замеренными мной данными для красок Kimera. Он написан на Python 3; в репозитории есть все исходники, и если у вас есть дистрибутив Python, то его можно просто запустить. Также в репозитории есть исполняемый файл Windows, созданный при помощи PyInstaller (см. раздел Releases справа). Ещё я добавил версию для Mac; это файл .dmg и в нём что-то есть, а если нажать на него, инструмент запустится, так что, кажется, всё работает. Но, честно говоря, я редко пользуюсь Mac, поэтому мне сложно сказать, есть ли там всё нужное, или требуется что-то ещё...

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

Ниже представлено более-менее полное описание его работы (и условия, при которых он не работает).

TL;DR Статья посвящена находкам, описанным в моих постах Mapping the Semantic Void, часть I и II. Создав специальный эмбеддинг в центроиде токенов (векторе средних значений всех 50257 эмбеддингов токенов GPT-J ), при помощи промта приказав модели определить его и учтя логиты, можно создать «дерево определений» состоящее в подавляющем большинстве из туманных сформулированных неопределённостей. Это вряд ли может удивлять, ведь модели GPT-J, по сути, дают задачу определить «что-то среднее». Однако наиболее вероятная ветвь в дереве, дающая определение, содержащее что-то конкретное, определяет «призрачный токен» (ghost token) в центроиде как «мужской пенис» (a man's penis). Снизив уровень отсечки кумулятивной вероятности, чтобы создать длинные списки возможных определений, мы выясним, что почти все ветви, предоставляющие определения, касающиеся чего-то конкретного, связаны с сексом/деторождением, и среди них лишь время от времени встречаются связанные со статусом. Как обычно, я понятия не имею, что всё это значит, но буду рад вашим предположениям!

Недавно я наткнулся на пост Алехандры Гонсалес (@blyxyas), в котором рассказывается о попытке сжать игру крестики-нолики в минимальное количество битов. Она пришла к решению из 18 битов. Это заставило меня задуматься: а можно ли улучшить этот результат?

Как говорит Алехандра, существует 765 возможных состояний игры¹. Мы можем просто назначить число каждому состоянию, что займёт 10 битов². Но, по словам Алехандры, это «скучно». С таким описанием игры мы практически ничего не сможем сделать. Когда будет нужно считать значение из конкретной ячейки или перейти из одного состояния в другое, на практике нам придётся использовать таблицу поиска, сопоставляющую каждое число с более крупным и структурированным описанием, что делает бессмысленным саму идею сжатого описания.

Много лет назад, учась computer science на старших курсах, я долго изучал различные вакансии онлайн, надеясь найти подходящую должность стажёра-программиста.

Кроме вакансий для стажёров я иногда случайно нажимал на объявления о вакансиях «сеньор-разработчика». Помню, больше всего меня поражало то, что первой строкой шло требование определённого количества лет работы: «Эта должность требует 5+ лет опыта».

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

Время летело, не успел моргнуть глазом, как прошло больше десятка лет. Сегодня я с гордостью могу сказать, что работаю программистом уже 14 лет. Спустя годы боёв на фронтах разработки ПО я осознал, что многие её аспекты сильно отличаются от того, что я представлял на старших курсах, а именно:

• С опытом программирование не становится намного проще, о «проще пареной репы» можно только мечтать.

• Написание кода для множества «больших проектов» — это не только неинтересное, но и опасное занятие, гораздо менее увлекательное, чем решение алгоритмических задач в LeetCode.

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

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