Новое

На прошлой неделе умер Билл Аткинсон, один из ключевых программистов ранней Apple, создатель HyperCard.

Тот самый чувак, который запрограммировал возможность окон у макинтошей перекрывать друг друга, потому что ему показалось, что он видел такую возможность во время встречи в Xerox PARC. Инженеры Xerox признались потом, что им и в голову не пришло такое программировать: слишком сложно!

Ещё он разработал алгоритм дизеринга Аткинсона, чтобы рисовать картинки на черно-белых экранах маков того времени.

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

Это был один из первых в мире инструментов визуальной, low code разработки. Создатель веба Тим Бернс Ли говорил, что вдохновлялся ссылками в нем.

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

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

Ситуация, в которой ты можешь внести изменения в программу, которой пользуешься, — прямая противоположность.

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

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

Есть целые экосистемы, построенные на идее расширяемых и редактируемых программ, обычно на основе Lisp-подобных, «интерактивных» языков.

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

Это, кстати, одно из обещаний энтузиастов ИИ: что, мол, с развитием средств автоматизированного программирования мы перестанем платить за программное обеспечение. Каждый будет создавать его под себя с использованием искусственного интеллекта. Я в этом мало верю. Хотя, было бы очень интересно.

Ну а пока, если хотите сделать классный софт под себя, — нанимайте нас! ;)

Дополнительные материалы:

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

Гугл опубликовал пост-мортем по позавчерашнему падению. Обычные ошибки, только на инфраструктуре планетарного масштаба.

У них есть внутренний сервис, который проверяет доступы (бабки, квоты и т. д.) перед тем, как API запрос доходит до любого продукта.

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

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

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

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

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

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

Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.

Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).

Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.

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

Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!

Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.

В контексте падения облаков, чем они лучше/хуже собственного железа?

Можно подумать, что я буду сейчас писать про отказоустойчивость. На самом деле, если ваш проект будет лежать, когда лежит весь GCP или AWS, — то для 99% проектов это абсолютно нормально, такие события происходят раз в несколько лет и длятся не больше пары часов. Мы ведь не кислородными масками управляем, верно?

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

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

Главное преимущество облаков в сравнении с «реальными серверами» — возможность быстро масштабироваться, то есть сегодня у тебя один сервер обрабатывает 1000 пользователей, завтра проект завирусился на миллионы, и ты за пару минут запускаешь десятки, сотни серверов.

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

Но есть нюанс: хорошо написанное веб-приложение на одном современном сервере может выдержать нагрузку в сотни тысяч пользователей. Реальных проектов, которым нужно прямо «облачное» масштабирование, — не так много.

К тому же, если в сервисе нет совсем уж жесткой неоптимальности, обычно, стоимость аренды любой инфраструктуры не является главным расходом. Обычно, зарплаты разработчиков в разы (десятки раз) выше стоимости хостинга. То есть экономить время разработчиков за счет увеличения стоимости инфраструктуры — это обычно выгодно.

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

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

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

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

Пример: классно наблюдать, как последние 3 года создатель важного фреймворка Ruby on Rails и культовой системы управления проектами Basecamp Дэвид Хейнемейер Ханссон (DHH) планомерно перевозит свои продукты с миллионами пользователей из облаков на собственные серверы.

Они объявили о планах выхода из Амазоновского облака AWS ещё в октябре 2022. На тот момент, они платили за Амазону 1,5 млн долларов в год! Для начала, они купили себе физических серверов на полмиллиона долларов (всего треть годового чека за облака!)

В июне 2023 объявили об успешном перевозе всех вычислений, а недавно купили специализированное железо для хранения данных и мае наконец перевезли хранилище файлов из AWS S3.

Другой яркий пример, с которым я сталкивался лично, — это стоимость трафика для медиа-проектов. Трафик в облаках для популярного медиа может стоить десятки тысяч долларов, и такой же объем можно обработать десятком арендованных серверов по 40 баксов каждый. Экономия в 100 раз. Но это всё имеет смысл только на масштабе. Так выпьем же за то, чтобы было на чем экономить!

В 21:46 мск отказала большая часть гугловского облака GCP. Ходят слухи, что всё из-за одного ключевого технического внутреннего сервиса, но в результате в разной степени поломались гугловские продукты, вроде Cloud, Drive, Meet, Gmail.

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

Дальше по цепочке легла половина интернета — Spotify, Discord, Snapchat и тысячи других. Особенно тревожно, что для многих людей сломался RCS — это протокол, продвигаемый Гуглом, который должен заменить смски.

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

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

P. S. Про одновременное падение Amazon Web Services — кажется дезинформация.

Удивительно, на какие ухищрения идут Яндекс и Фейсбук, чтобы отследить, на какие веб-сайты мы ходим.

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

Для этого они, ни много ни мало, запускают локальный веб-сервер прямо на мобильном устройстве.

После публикации статьи Фейсбук перестал это делать, Яндекс — продолжает. Производители браузеров спешно исправляют уязвимость.

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

Интересно, наложит ли кто-то из европейских регуляторов оборотные штрафы?

Мне тут наконец-то объяснили, такое AI-агент.

Это когда мы в первом запросе предоставляем ИИ список тулов, которыми ей можно пользоваться. Пользоваться — это просить нас (клиента) запустить тул с нужными параметрами и вернуть нейросети ответ. И всё это в вечном цикле, не забывая каждый раз прикреплять к запросу всю предыдущую историю переписки. Всё.

Вот отличная статья с примером полной программы, которая делает именно это. Подзаголовок замечательный «Король-то голый!»

Отсутствие сложности не делает этот прием менее полезным. Если включить этот режим в редакторе Cursor — то он сам запросит нужные файлы, прогонит линтер и запустит любые другие нужны утилиты. «Вы и есть за меня будете?!»

Закончили 12-й сезон подкаста «Запуск завтра».

Честно говоря, до сих пор не верится, что мы выпустили уже больше 250 эпизодов!

Этот сезон — особенный. Он состоит из двух частей.

В первой части я наконец-то со вкусом, толком и расстановкой поговорил с умными людьми про власть в цифровом пространстве. Это тема, которая интересует меня уже многие годы. Компьютеры и интернет когда-то были «последним фронтиром», куда уходили те, кто не желал жить по правилам «большого мира». Сейчас ситуация изменилась: в айти есть деньги, айти влияет на политические процессы, и политики, и бизнесмены уже многие годы потихоньку прибирают власть себе в руки. Этот процесс имеет множество форм, и мы говорим о самых разных из них с экспертами, учеными, исследователями и писателем-фантастом! 10 эпизодов!

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

Спасибо команде подкаста — за каждым эпизодом стоит большая работа: Маша Агличева, Маргарита Берденникова, Данил Астапов, Евгения Хрищанович, Юра Шустицкий, Ильдар Фаттахов, Женя Щербина, Аня Карпова.

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

P. S. Коллеги просят упомянуть партнера нарративной части — Селектел. Не жалко — это мой любимый провайдер в России, пользуюсь сам и всем рекомендую!

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

Бизнес-задачи перед нами ставят стандартные: редизайн, улучшение пользовательского опыта и удобства редакции, без потери трафика.

Технически сейчас это программа на C#, которая в одну сторону торчит админкой для редакции, а в сторону читателей генерирует HTML-страницы сайта. Это популярный сетап из 2000-х. Техническую задачу я формулирую как облегчение процесса разработки без потери производительности сайта.

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

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

Но будет ли современное веб-приложение (SPA) так же производительно, как HTML-страницы из 90-х? Речь и о скорости первого открытия — можно ли загрузить JS после полной отрисовки страницы? — и о скорости перехода между страницами — быстрее ли JavaScript-логика, чем отдать готовый HTML с сервера?

Можно ли получить лучшее из обоих миров? На какие компромиссы придётся пойти?

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

—

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

P. S. Один из разработчиков McMaster пишет, что под капотом там VB.NET, хранимки и XSL-трансформации поверх XML для генерации веб-страниц. Хочется вот всё то же самое, только без VB, хранимок и XSLT. 🙈

У меня в голове засели два видео.

Первое — анонс того, что Джони Айв будет делать железо в OpenAI.

Айв — ключевой партнёр Стива Джобса в создании айфонов, макбуков и других культовых продуктов Apple. Он ушел из Apple шесть лет назад и основал свою компанию, у которой супер милый сайт и ни единого публичного продукта. Сумма сделки — 6.5 млрд долларов.

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

Этот анонс — 9 минутный художественный фильм, в котором Сэм (Альтман) и Джони (Айв) играют, будто они идут по шумным улицам Сан-Франциско, встречаются в кофейне (привет Сэм! привет Джони!), бариста делает им по чашке кофе (крупный план, ASMR видео) и ... вдруг они начинают говорить друг о друге в третьем лице, то есть как со сцены, но при этом якобы сидят за барной стойкой, называют друг-друга самыми большими гениями, которых видел свет, утверждают, что мы стоим на пороге самого крупного технологического изменения (видимо, речь об ИИ) и что Сан-Франциско — центр технологий и культуры (?!) и т. д.

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

Кроме видео, есть ещё официальная новость на сайте OpenAI, оформленная как приглашение на свадьбу. Счастья молодым.

Привет!

С гордостью представляю наш новый проект — мы перезапустили «Синхронизацию»!

«Синхронизация» делает лучшие на русском языке лекции про культуру, историю и науку. Несмотря на высокое качество контента, подписку продлевали только 20% клиентов. Причина — технические ограничения платформы.

Вместе с «Синхронизацией» мы перезапустили платформу: разработали новую архитектуру, спроектировали удобный личный кабинет и пересобрали контентную админку. Уложились в рекордные 3 месяца, хотя обычно на такой проект требуется полгода-год.

Делимся, как у нас это получилось.

Кстати, мы готовы взять нового клиента. Пишите мне в личку @samatg или оставляйте заявку на сайте.