Близятся Новый год и Рождество, а значит, ёлки и всё связанное с ними: гирлянды, украшения и, разумеется, игрушки. Праздник слишком уж весёлый, и я решил, что ему не хватает мрачной игры, поэтому напечатал маленькую ёлочную игрушку в виде модели IBM PC, засунул в неё самый маленький ЖК-дисплей, который смог найти, добавил туда процессор и логику, а также аккумулятор. Это устройство может висеть на ёлке и показывать демонстрационный режим Doom со звуком и музыкой. Но и это ещё не всё: если подключить ней любую BLE-клавиатуру или джойстик, то можно будет самому убивать миллиметровых зомби, какодемонов и импов.

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

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

NanoKVM — это аппаратный KVM-переключатель, разработанный китайской компанией Sipeed. Это устройство, выпущенное в прошлом году, позволяет удалённо управлять компьютером или сервером при помощи виртуальной клавиатуры, мыши и монитора. Благодаря своему компактному размеру и низкой стоимости устройство быстро привлекло внимание Интернета, особенно когда компания пообещала выпустить его код в опенсорс. Однако, как мы увидим, это устройство обладает серьёзными проблемами безопасности.

Вчера до вершины популярности Hacker News добрался этот пост Джоны Гловера:

Может ли Claude воссоздать веб-сайт Space Jam из 1996 года? Нет. Или, по крайней мере, не с моими навыками промптинга. Требуется помощь, потому что я хочу сохранить этот веб-сайт навечно, но это никак нельзя сделать, кроме как попросить Claude воссоздать его из скриншота. Поверьте мне, я менеджер по разработке со степенью по computer science. Пожалуйста, помогите 😞

Чтобы уточнить подробности своей просьбы, Джона передал Claude Code (Opus 4.1) скриншот лэндинга, папку с изображениями и следующий промпт:

Я даю тебе:

1. Полный скриншот страницы лэндинга Space Jam.

2. Папку с сырыми графическими ресурсами**, извлечёнными с исходного сайта

Твоя задача — максимально точно воссоздать страницу лэндинга в полном соответствии со скриншотом.

С подобными задачами кодинг-агенты справляются идеально. Как я часто говорю, все задачи — это задачи поиска, но этот принцип не всегда просто применить на практике. Однако в данном случае применить его очень просто! У нас есть скриншот, поэтому diff пикселей сильно упрощает работу!

Вообще, можно сказать, что сам по себе Claude Code не смог бы с этим справиться. Но Claude с конфигурациями nori¹ просто обязан это сделать.

Так что вызов принят.

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

«Зачем беспокоиться о том, чего не произойдёт?»

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

За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни.

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

Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.

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

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

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

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

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

Однако, наверно, разработчики поняли, что у системы есть уязвимость, которую невозможно пропатчить — друзья. Если они учатся на том же курсе, что и ты, то лёжа в кроватке, можно отправлять им сообщения со слёзными просьбами поделиться кодом.

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

Любительские радиостанции — интересный способ знакомства с работой радиоспектра; что ещё более важно, это встроенные устройства, на которых могут быть установлены странные чипы/прошивки! Мне стало любопытно, насколько просто взломать мою Yaesu FT-70D, поэтому я приступил к расследованию. Единственный ресурс по радиостанциям Yaesu — это пост на Reddit о кастомной прошивке для Yaesu FT1DR.

Пользователь Reddit написал, что если выполнить процесс обновления прошивки через USB, то радиостанция раскрывает микроконтроллер Renesas H8SX, флэш-память которого можно изменить при помощи Renesas SDK. Отличное многообещающее начало, но SDK было не так легко настроить, а я не был даже уверен, сможет ли он сдампить прошивку... поэтому долгое время не брался за него.

Не думаю, что за мою 45-летнюю карьеру какой-то другой язык удивлял меня сильнее, чем Zig. Могу с уверенностью сказать, что Zig — это не только новый язык программирования, но и, на мой взгляд, совершенно новый способ написания программ. Задача этого языка — далеко не только замена C или C++.

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

Для меня бренд Apple всегда был синонимом внимания к деталям, но, к сожалению, в последние 8-10 лет решения компании на них совершенно не ориентированы.

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

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

У 82-летнего Кена Томпсона сохранились потрясающие воспоминания о первых днях операционной системы Unix и о буйной команде её разработчиков-гиков.

В этом месяце Музей компьютерной истории Кремниевой долины в партнёрстве с Ассоциацией вычислительной техники выпустил специальный выпуск на четыре с половиной часа, записанный полтора года назад историком технологий Дэвидом Броком. В этом выпуске Томпсон подробно перечислил многие из важных моментов своей карьеры — от работы над языком программирования C и Unix до операционной системы «Plan 9 from Bell Labs» и языка программирования Go.

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

Также по ходу дела Томпсон рассказывает историю о маленьком аллигаторе, которого друг отправил ему в офис в Bell Labs. («Его просто принесли, как почту… Не самый лучший из питомцев»).

Многие люди смутно представляют, что у финансовых институтов есть обязанность соблюдать Know Your Customer (KYC) и иметь программы AML (anti-moneylaundering), но что это означает на самом деле? Рад, что вы спросили.

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

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

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

В качестве противоположного примера возьмём Levels.fyi. Сегодня этот сайт помогает миллионам разработчиков сравнивать зарплаты и карьерные перспективы, но в начале его «бэкендом» были просто Google Формы, сохраняемые в Google Таблицы. Никаких микросервисов, никакого Kubernetes, никакой шины событий. Самые простые инструменты, которые можно придумать. Такая легковесная система обеспечила владельцам сервиса скорость её развития. Они проверили жизнеспособность идеи, расширили аудиторию и начали вкладываться в более сложные системы только тогда, когда стало ясно, что продукт рабочий. Иными словами, простота не стала для них препятствием, а превратилась в залог успеха. Стоит также помнить о том, что некоторые из самых сложных инфраструктур изначально были очень простыми: например, Airbnb, Facebook*, Reddit. Прежде, чем завоевать всемирную популярность, они были фрагментарными монолитами.

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

Когда в 2019 году я начинал размышлять о проблемах обучения кодингу, нашим врагом номер один был «ад туториалов». Признаки попадания в этот ад:

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

• Вы тратили больше времени на просмотр видео о кодинге, чем на само программирование.

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

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

• Глубокий курс обучения. Основы CS нужно преподавать не только в традиционных учебных заведениях.

• Практическое освоение всего. Необходимо писать код; не только в проектах, но и интерактивно, в процессе изучения каждой концепции.

• Меньше видео, больше текста. Видео слишком легко потреблять бездумно.

Повторюсь, что в 2019 году ад туториалов был повсеместным. Многочасовые курсы на YouTube собирали миллионы просмотров. Однако сегодня те же самые каналы с трудом набирают по пятьдесят тысяч просмотров нового контента. Посмотрите на FreeCodeCamp, Traversy Media и Web Dev Simplified. Я не пытаюсь бросить тень на эти каналы, они помогли куче людей, но их показатели сейчас именно таковы.

Каждую секунду в дата-центры Cloudflare в 330 городах отправляется 84 миллиона HTTP-запросов. Из-за этого даже самые редкие из багов возникают достаточно часто. На самом деле, именно наши масштабы позволили нам недавно обнаружить в компиляторе Go на arm64 баг, вызывающий состояние гонки в генерируемом коде.

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

После COVID-19 наша культура труда в основном изменилась к лучшему, но были и негативные изменения, например, увеличение количества совещаний на 13,5%[1].

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

В своей знаменитой статье «Maker's Schedule, Manager’s Schedule» [2] Пол Грэм писал:

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

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

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

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

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

Почти всё время существования лаборатории студенческих проектов Висконсинского университета в ней использовалась камера. Есть свидетельства наличия такой системы ещё в 1990-х: на древней версии сайта университета о ней говорится следующее:

…на стену приклеена изолентой камера ценой $15, подключённая к видеомагнитофону, который соединён с видеоразъёмом Mac IIcx, где запущены Timed Video Grabber (TVG) и FTPd. Рабочая станция HP Dax выполняет скрипт, который каждые 60 секунд пытается сохранить на FTP последнее изображение. Из-за отсутствия синхронизации часов время от времени происходят коллизии доступа к файлам, и вся схема ломается.

Прочитав это, я ненароком с восхищением взглянул на камеру, которая теперь установлена наверху аркадного автомата. Система, для создания которой требовалось оборудование на многие тысячи долларов, сегодня реализуема (в бесконечно лучшем качестве) на основе веб-камеры за $50, подключенной к Raspberry Pi.

В сентябре 1985 года Джон Бентли опубликовал книгу Programming Pearls — сборник афоризмов об истинах в программной отрасли.

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

Ох, какая наивность! Ничто не ново под луной. Почти все приведённые афоризмы болезненно актуальны.