Наверно, большинство людей, стремящихся избавиться от сервисов и приложений 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 — сборник афоризмов об истинах в программной отрасли.

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

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

Уже много лет моё хобби — это моделирование из бумаги (или 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.