Мой новый любимый развлекательный подкаст — Everything Everywhere Daily.

За 10-12 минут подкастер покрывает интересные темы типа как работают деньги, пакт Молотова-Риббентропа или истории интернета.

По ссылке — эпизод про интернет.

Из него я узнал, что название Internet (inter network) произошло из необходимости соединять разношёрстные сети университетов. Создатели решили, что каждая сеть будет «черным ящиком» (black box), а протоколы интернета будут единым стандартом для связи между границами сетей.

Первый протокол назывался NCP (network control protocol), в котором не было даже таких базовых вещей как контроль доставки. Когда в 1969 году по нему было передано первое сообщение — слово login, чтобы залогиниться с компьютера университета Лос Анджелеса в компьютер Стэнфорда — система упала после получения первых двух символов (lo).

В конце 1970х были созданы протоколы TCP и IP, которые разделяли транспортировку пакетов и их содержимое. 1 января 1983 года все компьютеры американской сети университетов ARPANet перешли на TCP/IP.

В 1980х были разработаны протоколы для почты SMTP и передачи файлов FTP. Чуть позже появится HTTP и родится интернет, который мы используем сейчас.

В воскресенье 29 июня в 11:00 по Нью-Йорку / 18:00 по Москве я буду на лайв трансляции у Ани Наумовой.

Поговорим про:

1) Россию и Америку — тема того, где трава зеленее весьма обширная, особенно, после того, как я провел месяц в Штатах. Затронем в том числе тему адаптации детей в новую для них российскую культуру, про это были вопросы и в чате.

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

3) Стартап и корпорации — как отличается работа в Google/Amazon от стартапа из двух-трех человек.

Трансляция будет на ютубе с вопросами из зала. Предполагаю, что будет легко и душевно. Я люблю формат живого Q&A.

Ссылку на подключение пришлю, когда Аня всё создаст. А пока добавляйте ивент в календарь.

Live будет по этой ссылке. Сразу предупреждаю, что описание немного clickbaitное.

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

https://youtube.com/live/F031E2Rp56M?feature=share

Моя суббота началась в 9 утра с емейла от Google Cloud, в котором говорилось, что мы достигли 100% от запланированных затрат в $50.

Каково же было удивление, когда я увидел цифру расходов в $1,800 за последние 16 часов.

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

1) В первую очередь надо остановить кровотечение (stop the bleeding).

а) Мы открыли дашборды и увидели, на что тратятся деньги. Они тратились на Google Cloud Functions и Cloud Logging. Из этого сразу понятно, что логи — это результат исполнения функций, так как между ними прямая зависимость.

б) Мы выяснили из дашборда какая конкретная функция исполняется по 5 тысяч раз в секунду. Их было 3, но только одна является первопричиной. Остальные — эффекты второго порядка.

в) Параллельно мы забурились в нашу аналитику в BigQuery и выяснили, что удобные вьюшки (views) сломались из-за огромного потока данных, которые мы отправляем из функций в BQ. Так как мы понимаем устройство платформы, мы смогли сделать запросы к таблицам, из которых генерятся вьюшки. Выяснили, что один из документов в таблице Firestore обновляется с нереальной переодичностью (850 тысяч раз за сутки при норме меньше 10).

г) Открыли этот документ в веб UI Firestore и своими глазами увидели, как документ бесконечно обновляется рандомными данными. Поняли, что мы бессильны это остановить "нормальными" методами.

д) Удалили функцию, которая отвечает за обновление этого документа. Увидели в логах и дашборде, что кровотечение остановлено. Но вместе с этим легла и часть нашего функционала.

2) Документировать всё.

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

3) Root cause analysis и систематичная проверка гипотез.

Мы не могли разобраться в чём причина и решили задеплоить функции заново, чтобы посмотреть, что будет. Ничего не произошло, но это показалось подозрительным.

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

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

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

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

4) Багфикс и мониторинг.

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

5) Устранение последствий.

Первым делом связались с Гуглом, чтобы попросить, чтобы нам простили этот счёт. Создали документ в гугл доках со всеми деталями и поделились с ними. Сказали, что ответят в течение нескольких часов.

Так же нам нужно будет посмотреть на целостность данных для подкастов с неуникальными индентификаторами. По нашим данным таких только пара десятков. Это можно оставить до понедельника.

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

6) Запостить в соц сетях.

Такие вещи интересны обеим сторонам — людям, которые в страхе гигантских счетов всё же деплоят в облака и людям, которые говорят "ага, я вам говорил, что облако это опасно!"

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

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

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

Но все закончилось хорошо. Увидимся через 10 часов.

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

В 1980 году геймдизайнер Тору Иватани из Namco задумал персонажа, посмотрев на пиццу с откушенным кусочком — так родилась форма желтого «колобка» с открытым ртом. Изначально игра вышла в Японии под названием Puck-Man, но при локализации в Северной Америке Midway переименовала её в Pac-Man, опасаясь, что хулиганы могут превратить «Puck» в неблагозвучный эпитет.

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

У меня в жизни было не так много долгосрочных менторов, обычно это были люди на несколько встреч, но с одним человеком я в контакте уже 11 лет.

Его зовут Дэвид Хиджирида. Мы познакомились, когда я проходил практику в Amazon. Мой менеджер был бывшим подчиненным Дэвида и он нас познакомил ради «нетворкинга», так как Дэвид тоже получил МВА в Wharton.

Дэвид старше меня на 11 лет, значит, тогда ему было как мне сейчас. Он был директором инжиниринга в биллинге в AWS.

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

В следующие несколько лет я периодически обращался к Дэвиду за советами по коммуникации идей руководству. Его главный вклад — матрица 2х2, которая визуализировала стратегию моего продукта AWS Chatbot. Я получил за неё огромное количество комплиментов. Дэвид нарисовал её на доске за 30 секунд...

Потом он ушёл из Амазона и мы стали общаться очень редко.

В прошлом году он написал мне сообщение «теперь моя очередь учиться у тебя». Он хотел узнать про уход из бигтеха, создание продуктов на коленках и про мои приключения в Перу.

Он был проездом во Флориде, но у нас не получалось пересечься. Моя жена была в отъезде и на мне было двое детей.

Тогда я предложил ему переночевать у меня перед рейсом.

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

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

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

Желаю и вам встретить своего Дэвида.

Клип с моего лайва на ютубе Ани Наумовой.

Тема, на мой взгляд, не противоречивая, но триггерящая.

Для полного погружения, можете почитать комменты.

Реклама воды Smart в приложении Lyft (райдшеринг).

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

Прикольно смотреть, как ребята придумывают новые форматы бренд-рекламы в приложениях, которая и работает, и не раздражает.

Хорошая новость для продакт менеджеров.

Стивен Синофски на подкасте a16z сказал интересную мысль: бОльшая часть работы профессионалов — это обработка исключений (exception handling).

Суть работы продакт менеджера — не в написании требований, а в устранении неопределённости и принятии сложных, неоднозначных решений (judgement calls). В этом AI их заменить не сможет.

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

Поэтому мы с вами в безопасности.

Советую послушать эпизод, там много ещё чего интересного про то, где мы сейчас в развитии ИИ с передовой венчурного капитала.

Если вы зайдёте на айфоне в App Store => нажмете свой аватар => Apps => My Apps, то можете посмотреть первые приложения, которые вы установили.

У меня это были SlovoEd, служба такси в Сингапуре и приложение для подкастов.

По этому списку так же можно понять, когда вы завели себе айфон. У меня он появился 27 апреля 2010. Это был черный iPhone 3G — второе поколение.

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

Три простых правила для списков:

1) Сортируйте по полю, которое есть в списке (a.k.a. не сортировать по невидимым полям).

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

Поэтому в списке всех стран мира ОАЭ (United Arab Emirates) и Великобритания (United Kingdom) оказались между Украиной и Соединенными Штатами.

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

2) Если в списке более 10 пунктов, добавьте поиск или фильтр. Скроллить список из 200 пунктов — такое себе удовольствие для пользователя.

3) Выберите значение по умолчанию, если вы знаете что-то про пользователя. Если пользователь в США, то выберите США по умолчанию (не Китай, как на скрине).

Вдохновлено опытом шоппинга на Miu Miu.

Помните старый анекдот, где сын спрашивает у папы, как пишется слово фигура? Папа отвечает, что, если это касается твоей мамы, то фЕгура.

То же самое можно сказать про дЕзайн Амазон.

За месяц использования американских сервисов, я понял, что

1) Наши банки куда лучше. Особенно Сбер.

2) ПВЗ Озон супер эффективны. В ПВЗ Амазона через раз тупо не срабатывает штрихкод. Прям дичь.

3) Яндекс Такси в больших городах в разы комфортнее и быстрее.

Хороший пост про prompt injection в вайб кодинге.

У этой позиции хватает противников, но я с Таней. Ты не знаешь, кто смотрит на твоё резюме и твоё лицо может как расположить так и оттолкнуть.

Я пробую вайб-кодинг в Claude Code. Заплатил $20 за первый месяц Claude Pro, чтобы получить доступ к их терминальному приложению для вайб кодинга.

На этот шаг меня вдохновило две вещи:

1) Чей-то пост (я его уже не найду), в котором автор, опытный СТО, говорил, что закоммитился написать один пет-проект полностью в Курсоре, чтобы прочувствовать вайб-кодинг на практике.

2) Потраченный выходной день, чтобы оптимизировать пайплайн обработки данных в нашем веб-приложении, который сломался, когда объём данных вырос в 10 раз. Я потратил полдня, чтобы пофиксить вещи, которые можно было бы делегировать ИИ.

Итак, я использую Claude Code для простого проекта. Я давно хотел самостоятельно захостить свои подкасты на Cloudflare.

Я пишу набор скриптов, чтобы а) скачать все файлы с текущего (платного) хостинга, б) сконвертировать метаданные в JSON и Markdown для удобства редактирования, шаблонизации и т.п., в) скомпилировать из всего этого добра XML, который требуется для подкаст-приложений и г) загрузить это всё на Cloudflare R2 через GitHub Actions, проверить, чтобы не было файлов-сирот (orphans), сломанных ссылок и т.п.

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

Простота его в том, что он работает локально и, если сломается, ничего не случится.

Первые впечатления после пары часов вайб-кодинга:

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

2) Он в целом всё правильно понял про мой проект и делает как надо, хотя и есть нюансы.

3) Нюанс: Много дублирующейся логики. Приходится ему говорить, чтобы выносил повторяющийся код в отдельные модули.

4) Нюанс: Он пишет ненужный код, например, валидацию данных, которые и так не могут быть неправильными ввиду того, что у них задан тип в TypeScript.

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

UGC такой UGC.

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