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

Некоторые вещи, например, конечные точки серверов, схемы баз данных и компоненты библиотек 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.

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

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

Придумывать имена сложно. Давайте посмотрим, как далеко мы можем зайти без них.

Что это?

Это язык программирования, основанный на трёх парадигмах:

Бесточечном программировании

Стековом программировании

Массиво-ориентированном программировании

Основная «фишка» языка — избегание любых наименований. Оставаясь верным этой максиме, сам язык тоже не имеет названия. «Язык программирования без имён» (namingless programming language) — это его определение.

Так как в мире есть только один такой язык, название ему не нужно.

Для чего это нужно?

В основном ради развлечения. Это язык для хобби-программирования.

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

Как выглядит код на таком языке?

Вот так:

i_^_b_H_i_cpp^_)_V_b_v_J_^_E_H_leafL_==^_)_V_H_Z_Z_^_)_V_H_I_^_E_1^_2^_#_G_Z_Z_^_E_1^_2^_#_H_$_L_-^_G_m_G_&_&_

Чёрт возьми!

Ага.

Простите.

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

Тот пост оказался довольно популярным и вызвал обсуждения, повлиявшие на то, как я делаю это сегодня. И спустя годы ведения подкаста Go Time, обсуждения Go в X/Twitter и поддержки подобного кода я решил, что настало время обновить информацию.

(Если вы педант и скажете, что Go не совсем 13 лет, то я отвечу, что начал писать HTTP-сервисы на Go версии .r59.)

В этом посте рассматривается широкий спектр тем, связанных с созданием сервисов на Go

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

Вспоминаю время, когда я ещё плохо владел терминалом. У меня возникли какие-то проблемы с дистрибутивом Linux. Что-то не монтировалось правильно или появлялись ошибки разрешений для файлов, в которых я не мог разобраться самостоятельно, поэтому попросил помощи у одного из сеньор-разработчиков. Величественность и грация, с которой он обращался с Vim и его командами, вдохновляла, это запомнилось мне навсегда. А ещё я захотел стать таким же, как он: быстрым, эффективным, всезнающим гуру. Реальность оказалась гораздо более приземлённой, но и в каком-то смысле приносящей бóльшую отдачу.

Изначально я представлял LED Industrial Piercing [перевод на Хабре] как проект, специально рассчитанный на использование светодиодов 0201. В конечном итоге они оказались совершенно не нужны. Светодиоды 0201 слишком малы! Очевидно, я должен был двинуться глубже, поэтому целью нового проекта стало размещение как можно большего их количества на поверхности серёжки-гвоздика.

283 ГБ/с на AMD Ryzen 9 7700X.

Сборка (протестирована с GCC 13):

g++ fizzbuzz.cc -march=native -o fizzbuzz -O3 -Wall -std=c++20 -fno-tree-vectorize -fno-exceptions

На сборку уходит несколько минут. В зависимости от CPU можно добиться повышенной производительности с -fno-tree-vectorize или без этого ключа.