После 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 — сборник афоризмов об истинах в программной отрасли.

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

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

Уже много лет моё хобби — это моделирование из бумаги (или papercraft): искусство создания 3D-моделей из вырезанных и склеенных бумажных деталей. Это хобби — надмножество оригами в том смысле, что в нём допускается вырезание и склеивание, а также использование для одной модели нескольких листов бумаги. Благодаря снижению ограничений papercraft позволяет создавать более сложные модели, которые проще собирать.

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

Я всегда был активным сторонником самохостинга, но ни разу не пробовал ничего, связанного с VoIP. Недавно я приобрёл несколько IP-телефонов и создал личную домашнюю телефонную сеть на основе Asterisk. Это руководство поможет вам настроить собственную телефонную систему при помощи опенсорсных инструментов.

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

Основная часть работы современных разработчиков ПО¹ связана с API: публичными интерфейсами для общения с программой, например, API Twilio. Я потратил кучу времени на работу с API как их разработчик и пользователь. Я писал публичные API для сторонних разработчиков, приватные API для внутреннего использования (или для потребления одной страницей фронтенда), API REST и GraphQL и даже несетевые интерфейсы, например, для инструментов командной строки.

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

Когда пристёгиваешь пациента к электронной пушке, способной выстреливать пучком частиц с энергией 25 МэВ, следование процедурам — вопрос жизни и смерти. Оператор, эксплуатировавшая аппарат лучевой терапии в Онкологическом центре Восточного Техаса (East Texas Cancer Center, ETCC), работала с ним достаточно долго для того, чтобы запомнить все процесс.

21 марта 1986 года оператор пригласила пациента в процедурную. Она проверила его назначение и уложила его на стол Therac-25. Над пациентом находилась диафрагма излучателя — поворотный диск, позволявший выбрать тип излучаемого устройством пучка. Сначала оператор переключила поворотный диск в простой режим оптического лазера, чтобы луч ударил в небольшой участок грудины пациента.

Несколько лет назад благодаря таким ютуберам, как Nebula Photos, у меня появился интерес к астрофотографии. Вооружённый OM System OM-5 и объективом Olympus на 15-140 мм, я смог сделать со штатива достаточно приличные снимки туманности Ориона, сняв 300 кадров с двухсекундной экспозицией и затем объединив их в Siril.

Понимая, что могу получить более качественные результаты при помощи трекинга, я примерно за €200 купил трекер Move Shoot Move. Он позволил использовать более долгую экспозицию, но находить объекты для съёмки и обеспечивать правильную привязку к полюсам всё равно было довольно сложно. В итоге я потратил кучу времени на изучение подходящих монтировок телескопов с функциями GOTO (автоматического наведения) и трекинга, почти решившись на приобретение моделей в ценовом диапазоне от €1200 до €4000. Для хобби, в котором я пока был новичком, подобные вложения показались мне перебором.

Я устроился в Apple в октябре 1995 года. В это время Apple кружилась в сливном отверстии раковины, готовясь отправиться в канализацию. Возможно, вы помните все эти разговоры о том, что Apple скоро закроется. Немного странно, что она продолжала нанимать сотрудников, но, очевидно, в Apple считали, что им всё равно нужен ещё один «графический инженер» для работы над технологией QuickdrawGX. Тогда мне был 31 год, я жил в Канзасе и программировал игры для Macintosh. Разумеется, в компании решили, что я хорошо подойду на эту должность.

Процесс собеседования оказался для меня совершенно неожиданным и новым (подробно о нём написано здесь), но в конечном итоге мне предложили работать графическим инженером QuickdrawGX в Apple Computer, Inc.

Переезжать с моей девушкой, всеми вещами (и двумя кошками) из Канзаса в Калифорнию было безумно сложно, но мы справились. Как окажется позже, мне предстояло ещё многое узнать о программировании, да и о профессионализме в целом. И тут я сразу понял, что, возможно, взялся за задачу, которая мне не по зубам (как программисту). Другие инженеры Apple были дружелюбными, но и очень умными. (Наверно, мне стоит подробнее написать о панике, которую я ощущал первое время; казалось, будто я случайно забрёл в глубокую часть бассейна.)

Впрочем, постепенно (примерно через полгода) я, так сказать, вошёл в колею, и начал справляться с работой немного увереннее. Но вскоре я всё равно понял, что по-прежнему остаюсь недисциплинированной деревенщиной, не совсем отвечающим стандартам Профессиональной Корпорации™.

Вскоре после моего прихода в компанию проект QuickdrawGX расценили провалившимся, меня перевели в новую команду (ColorSync) и чуть позже выдали новый проект. У Apple было стандартное окно, в котором пользователь мог выбирать цвет, оно называлось Color Picker («Палитра»). Кроме того, в то время Apple начинала переход с чипов Motorola 68K на новые, более быстрые чипы PowerPC (PPC). Моя задача заключалась в том, чтобы проект Color Picker, написанный для чипов 68K, компилировался для новой архитектуры PPC.

Intel выпустила процессор 386 в 1985 году, он стал первым 32-битным чипом линейки x86. Этот чип упаковывался в керамический квадрат с торчащими снизу 132 позолоченными ножками, которые вставляются в разъём на материнской плате. Хоть эта конструкция может показаться скучной, внутри неё происходит гораздо больше, чем можно было бы ожидать. По моей просьбе компания Lumafield выполнила компьютерную 3D-томографию чипа, обнажившую шесть слоёв сложных соединений, сокрытых внутри керамического корпуса. Более того, оказалось, что в чипе есть почти невидимые металлические проводники, соединённые с боковыми сторонами корпуса (см. показанные выше полосы). Снимок также показал, что у 386 есть две отдельных сети питания и заземления: один для ввода-вывода, второй — для логики процессора.

Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy. Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy, который, возможно, станет способом реализации сверхбыстрого Python.

Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.

Предыстория

Моя команда занимается разработкой медицинского ПО: приложения для передачи направлений пациентов в системе здравоохранения Австралии.

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

Система электронных направлений удобна для всех. Когда врач создаёт новое направление, мы автоматически извлекаем информацию из PMS (patient management software, системы управления пациентами, которой владеет наша компания) с данными пациента, этнической принадлежностью, индексом массы тела, принимаемыми лекарствами, медицинской историей и всем остальным, что необходимо для направления. В бланке направления есть валидируемая «форма специализации» с полями, относящимися к конкретной услуге, для которой выписывается направление.

Благодаря этому в направлении содержится вся необходимая информация. И, разумеется, в форме также есть большое текстовое поле для свободного текста (referral letter), в котором терапевт может объяснить, почему он решил выписать пациенту направление.

При отправке направления данные передаются в цифровом виде. Они преобразуются в один из нескольких форматов в зависимости от получателя. Некоторые получатели используют для приёма направлений наш продукт Referral Manager; в этом случае нам не нужно ничего преобразовывать, они просто получают доступ в веб-интерфейсе к тем данным, которые хранятся в базе данных. Однако обычно данные преобразуются в HL7 (старый текстовый формат файлов медицинской информации), CDA (XML-документ с отдельной таблицей стилей) или просто в PDF с человекочитаемой информацией. Благодаря этому данные совместимы со множеством различных электронных систем других компаний.

Также выполняется сохранение PDF-копии направления в PMS врача для ведения его собственной картотеки. Это позволяет ему просматривать всю историю пациента в PMS без необходимости поиска документов в куче приложений разных разработчиков.

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

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

Посмотрев два видео PewDiePie, в которых он узнал об установке Arch (задача эта считается довольно сложной даже для любителей Linux) и о создании трёх проектов (камеры для собаки, устройства для получения информации о погоде/напоминания о питьевом режиме/медитаций и кто знает, что будет ещё) из опенсорсных напечатанных на 3D-принтере деталей, я стал размышлять о самостоятельном проектировании, своём хостинге и технологической независимости. Эти темы уже давно очень близки мне.

Когда меня спрашивают, как начать писать блог или как получить работу, я всегда говорю, что сначала нужно купить домен. Во-вторых, нужно хостить собственный веб-сайт блога, если вы обладаете техническими навыками (впрочем, сегодня это уже несложно). Я говорю так потому, что всё накапливается со временем. Разумеется, вы можете начать с готового блога и не принадлежащего вам URL, но если вы хотите заниматься этим на долгосрочной основе, то что будет дальше? Я видел, как многие люди скачут с WordPress на Medium, потом на Substack, потом на Ghost. Иногда они не выполняют миграцию своих постов, на написание которых было потрачено много времени, а просто создают новые.

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

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

Слишком многие люди преступно пренебрегают резервным копированием. Из-за заблуждений в этой области теряется слишком много данных; это связано и с ошибочными техниками наподобие «бэкапов Шрёдингера» (то есть никогда не тестируемых, а значит, валидных и невалидных одновременно), и с концептуальными заблуждениями о том, что такое бэкапы и как они работают (RAID — это не бэкап!).

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

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

Когда я был зимой в Японии, одним из самых удивительных для меня явлений этой страны оказалась невероятная система общественного транспорта. Она не только была эффективной и надёжной, но и турникеты на станциях работали подозрительно быстро. Турникеты лондонской подземки не сравнятся с ними по скорости работы с Google Pay и другими моими бесконтактными картами. В чём же причина? Я решил изучить, почему японская система транспортных карт (IC-карт) так уникальна по сравнению с западными, и в процессе этого исследования узнал пару любопытных фактов.

Пару месяцев назад я купил Nanoleaf Pegboard Desk Dock — последнее слово в технологиях USB-хабов с RGB-светодиодами и крючками для устройств. К сожалению, это чудо инженерной мысли поддерживает только гейминговые операционные системы — Windows и macOS, поэтому возникла необходимость в драйвере для Linux.

В своих постах я уже настраивал Windows VM с пробросом USB и пытался выполнить реверс-инжиниринг официальных драйверов. При этом я задумался, а нельзя ли написать производителю и попросить у него спецификации или документацию его протокола. К моему удивлению, техподдержка Nanoleaf ответила мне всего через четыре часа, предоставив полное описание протокола, используемого Desk Dock, а также полосами RGB-светодиодов. Документация по большей мере подтвердила то, что я обнаружил самостоятельно, но также я нашёл в ней пару других мелких подробностей (например, управление питанием и яркостью), которые были мне неизвестны.

Сегодня мы попробуем написать драйвер на основании протокола (который я изучил реверс-инжинирингом), параллельно сверяясь с официальной документацией. Однако здесь есть одна небольшая проблема: раньше я ни разу не писал драйверов для устройств под Linux, а с USB-устройствами взаимодействовал только как пользователь.

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

Свой первый веб-сайт я создал где-то в начале 2000-х, и как и большинство веб-сайтов того времени, он был очень простым. Это неудивительно, учитывая то, что большинство (включая и меня) писали такие веб-сайты в Блокноте, что накладывало ограничения на сложность. Можно было выбрать или Блокнот, или какой-то из WYSIWYG-редакторов, которые привязывали к себе тем, что сгенерированный ими HTML было бы совершенно невозможно поддерживать без них, а если вносить изменения вручную, то это вполне могло поломать всё в редакторе.

Тогда не было iPhone, почти не было SEO, а JavaScript, как и CSS, использовать было совсем необязательно.

Цветопередача первых ЖК-экранов была плохой, поэтому лучше было выбирать цветовую схему с высокой контрастностью.

Оптимальным разрешением было 1024×768 (или 1280×1024, если вы могли себе это позволить), однако стоило и обеспечить работоспособность размеров окна и панелей в 800×600. Вам же не нужно, чтобы контент выходил за левый или правый край экрана?

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

В этом посте я расскажу, как на помощь мне пришли Linux, WireGuard и Hetzner, благодаря которым я смог получить доступ ко всему Интернету через одно лишь соединение IPv6.