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

Разработчики Chrome, наконец, урезали поддержку лучшего блокировщика рекламы, uBlock Origin, и теперь популярность моего любимчика Firefox снова растёт¹. Так что здесь я постараюсь убедить вас перейти на этот браузер и покажу, как его использовать.

Политика найма в большинстве компаний оставляет желать лучшего. Они просто тратят своё и наше время (я как-то проходил собеседование из 9 этапов!). Они охотятся на передовых программистов и при этом даже не могут отличить реальных людей от LLM. Короче, в манибол они явно не играют.

Для соискателей картина тоже выглядит тоскливо. Некоторые из лучших знакомых мне программистов (среди которых мейнтейнеры компилятора Rust) не могут найти работу, так как теряются под воздействием стрессовых факторов собеседования. Одному такому человеку, который уже более 4 лет работает с Haskell и более 2 лет — с Rust, рекрутёр прямо сказал, что он «не технарь». Плюсом ко всему компании могут неделями, а порой и месяцами мурыжить людей, не давая понять, приняли их на работу или нет.

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

В этой статье я коротко опишу один приём, который помогает мне писать код быстрее и с меньшим числом ошибок. Я говорю «приём», но по факту это просто практика, которой я начал следовать с опытом, сам того не замечая.

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

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

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

Читателям моего блога известно, что я работаю над обновлённой версией «Precision Clock» (но не спешите радоваться, до релиза ещё не один месяц). Одна из доработок этих «точных часов» коснулась дисплея, который теперь отображает время с точностью до миллисекунды. Причём я переработал его в корне, чтобы убрать мерцание, возникающее при записи работы часов на скоростную камеру.

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

С полгода назад я начал чаще использовать для программирования Python. Почему? Конечно, из-за ИИ. Лично для меня очевидно, что сегодня эта сфера связана с очень большими деньгами перспективами во всех направлениях. А какой язык является самым распространённым для ИИ? Да-да, как-раз этот проныра.

Я уже писал на Python, но только небольшие скрипты. К примеру, вот этот скрейпит метаданные всех видео с моего канала на YouTube. Собранные метаданные выводятся в виде файла JSON, который я использую для показа красивой статистики роликов на этой статичной странице. Как можно видеть здесь, этот скромный скрипт через GitHub Actions выполняется в соло-режиме каждый понедельник. Просто реализовать всё это на Python куда проще, чем с помощью того же Batch. И не только из-за более дружественного синтаксиса, но и потому, что его интерпретатор нативно интегрирован во все дистрибутивы Unix. Разве не круто?

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

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

Меня не покидала мысль: «А не будет ли проще написать логику в виде последовательной программы, ожидающей события и возобновляющей выполнение с места остановки?»

Естественно, в проекте не допускалось использование RTOS, посему традиционный подход применения потоков или систем блокирования для управления конкурентностью не рассматривался. Но я знал, что должна быть некая золотая середина.

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

Но как современная страна переживает такое отключение от интернета? Разве это не должно рушить все налаженные процессы?

Не совсем, ведь Исламская Республика последние десять лет занималась разработкой интернета внутри интернета.

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

Недавно работал над хобби-проектом, который описал в другой своей статье. В процессе его реализации у меня возникло желание чиркануть пару абзацев о том, почему React — отстой, но в итоге я не смог удержаться и решил высказаться по полной…

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

В 1985 году учёный Питер Нур будто зрил в будущее, написав свою работу под названием «Programming as Theory Building», которая сегодня стала весьма актуальной. Мы всё чаще видим, как начинающие разработчики бездумно принимают сгенерированный ИИ код, который толком не понимают, а кодовые базы разрастаются лишёнными теоретических основ реализациями. В свете всего этого чётко вырисовывается основная идея Нура: «программа – это не её исходный код».

Недавно залез в ROM оригинального Power Macintosh G3 и случайно обнаружил там пасхалку, о которой до этого ещё нигде не писали.

Началось с того, что одним воскресным утром я решил заглянуть в файл-шаблон ROM для Mac с помощью программы HEX Fiend Эрика Хармана. Меня интересовало, какие ресурсы хранятся в постоянной памяти Power Mac G3. Эта ROM использовалась в моделях Beige, Mini Tower и всех G3, выпускавшихся с 1997 по 1999 годы.

Пишу я эту статью в середине 2025, и мне не верится, что сегодня Power Mac G3 уже больше 27 лет. Невероятно!

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

Взявшись за эту задачу, я около двух часов ваял небольшой скрипт, который будет скрейпить данные из базы крейтов Rust crates.io и анализировать их для выяснения, какие пакеты чаще скачиваются для работы (то есть в будние дни), а какие для развлечения (то есть в выходные).

Мы с Крисом недавно «с нуля» буквально за пару часов создали механизм поиска для моего блога. Основную часть проделал именно Крис, так как до этого с word2vec я был знаком лишь отдалённо.

Разработанный нами поисковик основывается на векторных представлениях (эмбеддингах) слов. Принцип здесь следующий. Функция получает слово и отображает его в N-мерное пространство (в данном случае N=300), где каждое измерение отражает определённый оттенок смысла. Вот хорошая статья (англ.) о том, как обучить собственную модель word2vec, и её внутреннем устройстве.

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

Уравнение ниже может показаться пугающим, но в нём говорится, что косинусное сходство, представляющее косинус угла между двух векторов cos(theta), определяется в виде скалярного произведения, поделённого на произведение величин каждого вектора. Разберём всё это подробнее.

Недавно наткнулся на новость о том, что количество приложений в Google Play Store сократилось на 47%.

Я сам энтузиаст разработки под Android и последние 5 лет работал над альтернативой для Google Play Music и Podcast под названием MusicSync. Так что, будучи близким к теме человеком, мне захотелось поделиться своим опытом обслуживания приложений и заодно пояснить, почему меня эта новость нисколько не удивила.

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

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

Моим первым языком программирования был ActionScript. Написание кода для Macromedia Flash максимально далеко от голого железа, и эта специфика работы глубоко засела в моём сознании. В результате меня интересовали преимущественно высокоуровневые языки для веб-программирования. Низкоуровневые же казались непостижимыми. Со временем я постепенно из разных источников узнавал о них всё больше, но это моё убеждение оставалось прежним. Низкоуровневые языки пугают, и машинный код подтверждал это наглядно. Когда я обращался к Google с запросом «понятный машинный код», то результат выдачи чаще представлял нечто пугающее и отталкивающее, нежели полезное для обучения.

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

Машинный код вовсе не страшен. Если вы можете обеспечить, чтобы документ JSON соответствовал схеме JSON, то без проблем сможете писать машинный код.