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

Впереди подробный разбор перлов дизайнерских решений в macOS Tahoe с оглядкой на старое-доброе руководство Macintosh Human Interface Design из далёкого 1992 года. — прим. пер.

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

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

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

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

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

Но мы сегодня, естественно, поступим наоборот и заглянем в глубины элемента <plaintext>, чтобы узнать, какие занятные вещи с его помощью можно делать.

Бьюсь об заклад, что ПК в вашем офисе вряд ли потянут большие языковые модели (LLM).

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

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

Недавно моё утро началось с такого вот прекрасного e-mail от Hetzner:

Уважаемый, м-р Джей Сандерс,

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

Также просим вас прислать краткое пояснение с описанием того, как такое могло произойти, и что вы собираетесь в этом отношении предпринять. Если последующие шаги не будут успешно выполнены, ваш сервер может быть заблокирован в любой момент после 2025-12-17 12:46:15 +0100.

К письму прилагалось подтверждение того, что с моего сервера было выполнено сканирование некоего IP-диапазона в Таиланде. Отлично. Никакого вам «Здравствуйте», а лишь заявление о злоупотреблении и угроза отключить всю инфраструктуру через 4 часа.

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

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

Некоторым людям нравятся собеседования с написанием кода. Я к их числу не отношусь.

Недавно мне на LinkedIn попался пост такого содержания:

"Мы задаём каждому соискателю тривиальную задачу на программирование. Что-нибудь вроде: «Дан список чисел, нужно вернуть сумму чётных из них». И такая задача не предполагается как сложная или заумная, и её цель не в том, чтобы кого-то отсеять, теоретически.

Это лишь базовая проверка. Разработчик или SRE с опытом от 6 до 10 лет должен решать такие во сне, согласитесь?

Оказывается, нет.

Где-то 75% кандидатов не справляются. И не только джуниоры. Я говорю о людях с приставкой «Senior» в их квалификации. О людях, которые заявляют, что учат новичков. О тех, кто говорит, что имеет за плечами годы опыта в продакшене.

Для меня это загадка".

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

Долгие годы я воспринимал систему HDMI-CEC как домового: иногда полезная, часто непредсказуемая и всегда загадочная. У меня в гостиной собран несложный мультимедиа-центр — ТВ Samsung с поддержкой ARC (не eARC, которая заслуживает отдельного поста), Denon AVR-X1700H, спрятанный в кладовке, Apple TV, несколько подключённых к Denon игровых приставок и Raspberry Pi 4, управляющий системой Homebridge. Что касается CEC, то в Apple TV эта фича работает прекрасно, но вот приставки ведут себя так, будто едва с ней знакомы. Они будят ТВ, переключают источник, но оставляют Denon в режим ожидания, вынуждая меня переключать вывод аудио вручную.

Когда я закончил работать над проектом ecosyste-ms/package-manager-resolvers, мне стало интересно, какой алгоритм разрешения зависимостей использует сервис GitHub Actions. Когда вы записываете в файл рабочего потока uses: actions/checkout@v4, то объявляете зависимость. GitHub её разрешает, скачивает и исполняет. Так работает управление пакетами. Я же решил отправится в кодовую базу runner, чтобы увидеть весь этот процесс изнутри. И открытия, скажу я вам, оказались весьма тревожными.

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

Один особенно мудрый взрослый (где-то в 1996 году) однажды отвёл меня в сторону и сказал: «Знаешь, хорошо, что программирование приносит тебе удовольствие, потому что в будущем оно тебя не прокормит. Делать это из любви, а не ради денег — отличный подход.

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

Через пять лет соберётся целая библиотека объектов, где они будут лежать подобно книжкам на полках, и бизнес сможет решать любую программную задачу по щелчку пальцев, просто комбинируя нужные библиотеки как детали LEGO. Вы ему не потребуетесь». 

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

И вот я здесь почти 30 лет спустя, и разработка, несмотря ни на что, продолжает меня кормить. Существует опенсорс, и всегда находятся библиотеки, с помощью которых я могу скроить что-то нужное. Постоянно возникают новые серии задач, для которых ещё нет готовых решений. Комбинирование деталей LEGO по-прежнему требует усердного труда. Как только я решаю эту задачу на одном уровне абстракции, мы переходим на другой… и так продолжается по кругу.

Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.

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

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

А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад.

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

Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!

Невероятно!

Но я забегаю вперёд…

Несмотря на то, что книга «Чистый код» привнесла в наш лексикон прекрасный термин, она также снискала и дурную славу. Это руководство от 2008 года представляет собой сборник принципов и исследований, которые «дядя Боб» (Uncle Bob, то есть Роберт Мартин) выработал за годы программирования.

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

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

Можно подумать...

Недавно я закончил реализацию своего хобби-проекта по воссозданию ПК IBM XT из 80-х на основе оригинальных деталей с использованием современных технологий. У меня была чёткая цель: возможность играть на этом ПК в EGA-версию Monkey Island 1 со всеми примочками. То есть мне нужна была поддержка мыши, жёсткий диск с возможностью записи для сохранения игры и версия озвучки через карту Adlib, которая мне нравилась больше всего.

Эта задумка у меня возникла, когда я узнал о существовании маломощного варианта Intel 8088, который использовался в XT. Низкое энергопотребление значительно упрощает подключение процессора к ПЛИС, ввод-вывод которой обычно работает на 3,3 В. Всё это вкупе с маломощной микросхемой SRAM на 1 МБ (CY62158EV30), призванной обеспечить XT его 640 КБ памяти, уже составляло основу для всей будущей системы.

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

Интернет — невероятное изобретение. Людей от него за уши не оттащишь. Вот только есть у этого изобретения проблемы с надёжностью — пакеты теряются, каналы перегружаются, биты путаются, а данные повреждаются. Ох, какой же опасный мир! (Буду писать в духе Крамера).

Хорошо, почему же тогда наши приложения вот так просто работают? Если вы выводили своё приложение в сеть, то процесс вам знаком: socket()/bind() здесь, accept() там, возможно, connect() вон там и, вуаля — данные надёжно текут в обе стороны упорядоченным и целостным потоком.

Сайты (HTTP), сервисы e-mail (SMTP) или удалённый доступ (SSH) — всё это построено на основе TCP и просто работает.

Есть три вида писем, которые могут испортить блаженную субботу: уведомление безопасности, предупреждение об отключении электричества и, очевидно, повторное напоминание о том, что вы задолжали облачному провайдеру один цент — да, именно $0,01. Услугами DigitalOcean я пользуюсь с 2013 года, хотя для личных задач я этот сервис использую редко, просто авторизуюсь несколько раз в неделю для обеспечения поддержки моих клиентов на этой платформе.

Последние две пятницы без какого-либо уведомления в Google Cloud блокировали аккаунт моей компании SSLMate. Впервые подобное произошло в 2024 году, тоже без какого-либо предупреждения. Но сегодня я хочу не столько предупредить вас о рисках использования платформы Google Cloud, сколько поведать о вынужденных компромиссах между снижением безопасности и удобством работы, вызванных своенравной политикой Google.

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

Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.

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

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

Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

Если вы уже давно знакомы с Backblaze (особенно, если следите за обзорами Drive Stats), то наверняка читали наши обсуждения кривой отказов. В статье «Drive Failure Over Time: The Bathtub Curve Is Leaking» мы писали о том, как проверяли истинность старого инженерного принципа, гласящего, что сбои в работе привода, представленные в виде временного графика, демонстрируют предсказуемую U-образную кривую, иначе называемую кривая «ванны».

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

И «ванна» в этом случае не просто «потекла» (отсылка к leak в названии вышеупомянутой статьи, — прим. пер.), её форма больше напоминает бордюр при входе в душевую кабину. Складная история о том, что вначале идут сбои, а потом спокойный средний период с плавным повышением отказов, больше не вписываются в реалии жизни наших приводов. Они становятся лучше. Говоря точнее, датасет Drive Stats указывает на повышение их качественных показателей конкретно в дата-центрах.

Давайте же посмотрим, как выглядит полученная нами кривая отказов, и как она соотносится с прежними поколениями анализа.

Если коротко, то жёсткие диски становятся лучше.

(Перевод моего выступления на  P.I.W.O в июне, слегка подчищенный и приближенный к формату блога).

…звучит как-то не очень. Я сделала все эти слайды в Inkscape с ПК под управлением KDE Linux, плюс я регулярно пользуюсь Firefox. Но это всего лишь я. А что насчёт вас? Вы используете свободное ПО? Поднимите руки! [в аудитории поднимаются руки] Конечно же! Что за чепуха, «Свободное ПО не победило». Кто-то подменил мои слайды… Эй, ведущий конференции!

Ведущий: В другом каталоге.

[Перехожу в каталог с названием другой каталог и открываю файл твои слайды тупица.pdf]

Вот они мои слайды.

Всех приветствую, меня зовут Дорота, и сегодня я буду говорить о том, как …