FAANG Master

Навье-Стоксгейт

8 сентября OpenAI заявила, что её невыпущенная модель решила одну из семи "задач тысячелетия" - проблему существования и гладкости решений уравнений Навье–Стокса. Напомню, что до этого была решена лишь одна задача тысячелетия - Гипотеза Пуанкаре, которую доказал Григорий Перельман.

Вначале ~100 агентов 50 часов решали упрощенную задачу о регулярности уравнений Эйлера. Далее результат скормили для решения задачи про уравнение Навье-Стокса. В пике работали около 10000 агентов в течении 88 часов. Потом еще 17 часов на проверку доказательства в Lean. Было потрачено токенов на более чем $22 млн.

Доказательство уже выложено. Но пока независимой проверки не прошло.

Все бы хорошо, но Open AI подозревают в плагиате и краже ключевой идеи доказательства.

За 12 часов до анонса от Open AI математик Тристан Бакмастер опубликовал заявление, где анонсировал несколько прорывов в решении задачи Навье-Стокса. В частности для упрощенной задачи - уравнения Эйлера. И что по самой задаче Навье-Стокса они уже нашли доказательство, но оно пока еще не прошло Lean и статья еще не готова для публикации. Там же он рассказал, что они работали год над этим решением совместно с математиком, который работает в Антропик - Левентом Альпёге. И результатов по Эйлеру достигли 15 августа.

Кроме того, в том же заявлении он написал, что 3 сентября рассказал, про свой проект одному из сотрудников Open AI, после того, как поползли слухи, что в Антропик решили задачу тысячелетия. Тристан, сказал, что это с Левентом их личный проект и к Антропику отношения не имеет. Что Левент делает это не как сотрудник Антропика.

После этого, через 3 дня Open AI делает свое доказательство используя абсолютно тот же подход, предложенный Бакмастером и Альпеге.

6 сентября Себастьен Бюбек из Open AI связывается с Бакмастером. По его словам, он хотел, чтобы все лавры доказательства достались Бакмастеру и Альпеге. Но в ходе разговора узнает, что Бакместер и Альпеге решили только Эйлера, но не Навье-Стокса. Поэтому предлагает Бакмастеру два варианта:
1) Бакмастер и Альпеге публикуют независимо работу по Эйлеру, а Open AI по Навье-Стоксу, но с указанием заслуг Бакмастера и Альпеге.
2) Open AI дает доступ к их доказательству по Навье Стоксу и автором делает Бакмастера, а Альпеге вычеркивает (т.к. он работает в Антропике).

У Бакмастера возникло подозрение, что Open AI украло у них идею доказательства и что, возможно, они получили доступ к его сессиям в Codex. Т.к. они сами активно пользовались Codex для проверки выкладок.
Также Бакмастер сказал, что Бюбек ему угрожал (Зачем тебе разрушать свою карьеру?), после того, как он сказал, что пойдет в публичное поле. А также говорил, что все было бы проще, если бы Альпеге не работал бы в Антропике.

По итогу, Бакмастер и Open AI опубликовали свои заявления и работы независимо. А также Бакмастер предал огласке всю поднаготную этой истории.

Uber совместно с британским стартапом Wayve запускает роботакси в Лондоне

Пришла нотификация в приложении убера. Пока в режиме тестирования. Водитель все равно будет присутствовать на всякий случай. Все это будет на Ford Mustang Mach-E.

Новый HTTP метод QUERY

Этим летом в спецификацию HTTP добавили новый метод - QUERY.
Добавление новых методов происходит довольно редко. Последний раз такое добавление случалось в 2010 году, т.е. 16 лет назад. Тогда добавили метод PATCH.

Какие причины добавления?
Поиск с фильтрами/параметрами. По идее, можно для поиска использовать GET, т.к. он кэшируется и safe (read-only). Но передавать параметры через URI не удобно: есть лимиты, передавать сложные структуры через URI неудобно, URI также часто логируется, используется в качестве закладок в браузере.
Поэтому на практике используют POST, который изначально под это не приспособлен. Параметры/фильтры передают через тело запроса. CDN, reverse proxy обычно не кэшируют такие запросы и перенаправляют на бэкенд, т.к. кэшировать по URI смысла нет без фильтров, которые в теле запроса. Более того, POST изначально предназначался для получения данных для возможного последующего сохранения, а не для read-only чтений, по типу поиска. Т.е. он не safe, а также не идемпотентен.

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

QUERY - safe и idempotent как и GET. Т.е. не меняет состояние сервера, read-only. Ответ кэшируется, но в ключ кэша обязано входить тело запроса и его метаданные. Он также возвращает Location, по которому можно при помощи GET получать те же данные, без пересылки тела запроса с параметрами.

RFC: https://www.rfc-editor.org/info/rfc10008/

IOI 2026

В Ташкенте прошел межнар школьников по информатике.

Результаты: https://stats.ioinformatics.org/results/2026

Официальный медальный зачет по странам не составляется. Также участники из некоторых стран не выступали под флагами своих стран (Россия, Белоруссия, Израиль и т.д.).
Разбивка по странам:
https://stats.ioinformatics.org/contestants/2026
В конце там есть участники из этих стран.

Владислав Жиганов из России занял абсолютное второе место: https://stats.ioinformatics.org/people/8665

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

Получившаяся первая 20ка:

1) Китай, 3-1-0, 1736.83
2) Израиль*, 3-0-1, 1499.01
3) Малайзия, 2-2-0, 1513.21
4) Россия*, 2-2-0, 1513.20
5) США, 2-2-0, 1487.67
6) Япония, 2-1-1, 1517.09
7) Корея, 2-1-1, 1353.45
8) Гонконг, 2-1-0, 1317.18
9) Польша, 2-1-0, 1312.10
10) Казахстан, 1-3-0, 1456.58
11) Турция, 1-2-1, 1350.16
12) Австралия, 1-2-0, 1314.80
13) Тайвань, 1-2-0, 1299.82
14) Украина, 1-2-0, 1286.81
15) Вьетнам, 1-2-0, 1244.42
16) Бразилия, 1-1-2, 1273.75
17) Румыния, 1-1-2, 1269.04
18) Беларусь*, 1-1-2, 1248.34
19) Болгария, 1-1-2, 1215.40
20) Филиппины, 1-0-2, 944.13

* — выступали без национального флага

Составы сборных США: https://stats.ioinformatics.org/delegations/USA/2026

И Великобритании: https://stats.ioinformatics.org/delegations/GBR/2026

В свое время я закончил МФТИ. Относительно непростой вуз для обучения. Закончил неплохо. За время обучения выработал подход к подготовке к экзаменам, который часто применял после окончания вуза. Например, когда решил стать программистом или когда решил заботать алгосы, чтобы поработать в фангах.

Подход следующий. Обычно, на подготовку к экзамену выделялось 4 дня. Для теоретических экзаменов давали список вопросов (билеты). Обычно, это 30-80 тем. Я старался разделить этот список на 3 части и ботать в день эту одну треть. Например, если 30 вопросов, то в день ботал 10 вопросов. Ботал примерно 12-14 часов в день. Каждый день был устроен примерно так. Читаю/изучаю какой-то вопрос по лекциям, книгам и т.д. Стараюсь разобраться пока не понимаю все детали. Далее воспроизвожу этот вопрос на бумаге с формулами и проговариваю про себя ответ на вопрос. И так по всем вопросам, которые я запланировал на день. В конце дня повторял все изученные вопросы за день. Иногда мы проговаривали эти темы вместе с соседями по общаге. Также спрашивали друг друга непонятные вещи, с которыми не смогли разобраться сами. На 4 день, я снова повторял все изученные билеты и доучивал все, что не успел за предыдущие три дня. Часто недоучивал несколько последних билетов, т.к. не хватало времени и/или капасити памяти/мозга. На них я писал бомбы и брал с собой. За все время они мне пригодились 1 раз. Выпал билет, который я не учил и я воспользовался бомбой.
К письменным экзаменам подход похожий. Только вместо билетов, там типы задач. Подготовка была чуть проще, т.к. в течении семестра мы сдавали задания, где прорешивали десятки типовых задач. К письменному экзамену я находил варианты прошлых лет, которые были во внутренней сетке, и прорешивал с десяток другой задач на каждую тему (по матану, дифурам, общефизу и т.д.).

Аналогичный подход я применял, когда решил изучить алгосы 11 лет назад. Я никогда не участвовал в олимпиадах по программированию и изучал все буквально с нуля. Основа подготовки: выяснение основных типов задач, изучение теории и подхода к решению данного типа задач, прорешивание большого числа задач на каждую тему. При этом важно попробовать сначала решить самостоятельно, потом разобраться с решением и его воспроизвести. И далее повторять уже решенные задачи с увеличивающимся интервалом. Сначала сразу после решения. Потом через несколько дней/неделю, потом через месяц, потом через год, потом через несколько лет/перед следующей подготовкой к собесу в другую компанию. Вначале процесс забывания максимален, далее он постепенно замедляется и задача/подход к решению остается надолго в долгосрочной памяти. Самостоятельное прорешивание вначале позволяет глубже погрузиться в детали задачи, ее сложность именно для вас. Это сделает разбор решения более персонализированным, будет вызывать эмоциональный отклик на моменты, с которыми у вас были сложности. И поэтому вы лучше запомните задачу.

Документалка про Java

В продолжение темы документалок, вышла документалка про Java.

Трейлер: Official Trailer

Анонс: Java: The Documentary is Coming Soon

Документалка: The Java Story

Ford наняла обратно уволенных инженеров по качеству

Ранее Ford внедрила систему, основанную на AI, для контроля качества производства. Благодаря, чему уволила сотни инженеров.

Внедрение AI системы привело к росту количества брака и отозванных автомобилей.

Сейчас Ford наняла обратно 300+ опытных инженеров по качеству работать совместно с этой AI системой.

Еще несколько рекомендаций по литературе

Hope Driven Development становится все актуальней и актуальней с появлением AI.

Рейтинг городов Европы для Digital Nomad

Это для тех, что зарабатывает, работая на полной удаленке и имеет возможность работать откуда угодно. Из 19 городов, я исключил те, где нет никакой возможности получить визу, если вы не работаете в этой стране.
При расчете рейтинга я учитывал: стоимость жизни, стоимость недвиги, легкость получения Digital Nomad Visa, климат, медицину, преступность, язык.

Итоговый рейтинг:

1) Валенсия. 32 балла.
Дешево, дешевая недвига, легко получить Digital Nomad Visa, море, солнце, хорошая медицина, низкая преступность.
2) Порту. 30 баллов.
Аналогично Валенсии. Но нет моря (есть океан), чуть дороже недвига.
3) Кипр (Лимассол). 28 баллов.
Подороже, чем Валенсия.
4) Лиссабон. 28 баллов.
Дороже чем Валенсия, особенно недвига.
5) Барселона. 28 баллов.
Дороже Валенсии, выше преступность.
6) Мадрид. 27 баллов.
Как Барселона, но лучше с преступностью и нет моря.
7) Прага. 26 баллов.
Сложнее получить такую визу. Нужно ИП открывать в Чехии. Дорогая недвига.
8) Франкфурт. 26 баллов.
Сложнее получить такую визу. Дорогой город. Нет моря.
9) Мюнхен. 26 баллов.
Аналогично Франкфурту.
10) Берлин. 25 баллов.
Аналогично Франкфурту, но чуть дешевле. Также выше преступность, хуже медицина.
11) Варшава. 25 баллов.
Нет моря, сложнее получить такую визу, дорогая недвига.
12) Дубай. 25 баллов.
Жарко, дорого.
13) Париж. 24 балла.
Сложно получить такую визу. Очень дорого. Нет моря.

В продолжении рейтинга городов Европы. Рейтинг по покупке недвижимости.

Для тех, кому важна только возможность купить недвижимость. Для каждого города я вычислил медианную зп синьера в месяц после уплаты налогов. И месячный платеж по ипотеке за сферическую недвигу в вакууме (75 кв. метров) при 20% первоначальном взносе и 25 годах выплат.

1) Дубай. 15%.
2) Валенсия. 22%.
3) Кипр (Лимассол). 25%
4) Мадрид. 33%
5) Барселона. 36%
6) Брюссель. 36%
7) Цюрих. 38%
8) Порту. 42%
9) Варшава. 42%
10) Амстердам. 47%
11) Берлин. 47%.
12) Лондон. 47%
13) Стокгольм. 54%
14) Лиссабон. 56%
15) Прага. 58%
16) Франкфурт. 59%
17) Мюнхен. 69%.
18) Париж. 72%
19) Люксембург. 76%.

Это при условии, что вы и работать будете в том же городе (а не удаленка на компанию из другой страны). Также часто есть обходные пути. Например, кажется, что в Люксембурге невозможно купить недвигу. Но многие покупают не в самом городе, а в соседних городах. Там всю страну за 2 часа можно объехать. Также есть возможность купить недвигу в несколько раз дешевше по специальным программам. Если это ваша первая недвига, вы ее не можете никому сдавать, а только в ней жить и продать вы ее можете только по цене покупки изначальному продавцу (лэндлорду). Знаю людей кто купил на условные 300-400 тысяч евро дом на 200 квадратов в 40 минутах от Люксембурга.

Топ городов Европы для миграции программиста в 2026. Долгосрочная миграция с возможностью работы в BigTech/FAANG

Включил 18 городов Европы и Дубай. США, Южную и Центральные Америки, Азию, Австралию не рассматривал.

Сделаю несколько топов из этих городов, т.к. разные города хороши под разные типы и цели миграции. Сегодняшний топ фокусируется на долгосрочной миграции, с целью получения гражданства, покупки недвиги, долгосрочной жизни и работы в разных компаниях, которые нанимают в этом городе. Не для тех кому нужно срочно уехать куда-то. Не для тех, кто хочет жить у моря, не важно где, работая на удаленке. А также рассматривает возможность поработать в FAANG/BigTech-компаниях в этом городе. Не для тех, кто хочет выйти на пенсию, живя на инвестиции (FIRE).

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

1) Лондон. Был сам удивлен. 38 баллов.
Хорош в: получении гражданства, не нужно отказываться от первого гражданства. Много вакансий, много FAANG/BigTech. Английский. Топ университеты.
Средний/ниже среднего в: стоимости жизни, преступности, стоимость покупки недвижимости.
2) Цюрих. 34 балла.
Хорош в: безопасность, образование, FAANG/BigTech компании, распространенность английского, высокие зп по отношению к стоимости жизни и стоимости недвиги.
Плох в: получении гражданства, мало вакансий, кроме FAANG.
3) Берлин. 32.5 балла.
Хорош в: получении гражданства.
В остальном нет откровенно плохих метрик, по всем средний/выше среднего.
4) Дубай. 32.3 балла.
Хорош в: стоимость жизни по отношению к зп, налоги, стоимость недвиги по отношению к зп.
Плох в: нельзя получить гражданство, климат, нет фангов.
5) Амстердам. 31.7 балла.
Во всем чуть выше среднего.
Ниже среднего: не много вакансий, стоимость жизни и недвиги по отношению к зп.
6) Варшава. Был удивлен. 31.5 балла.
Хороша в: стоимости жизни по отношению к зп, относительно много вакансий, есть фанги.
Плоха в: язык, получение гражданства.
7) Кипр (Лимассол). 29.7 балла.
Хорош в: получении гражданства.
По большинству других параметров выше среднего.
Плох в: нет фангов, не очень много вакансий.
8) Мюнхен. 29.5 баллов.
Хорош в: получении гражданства, безопасность, медицина, топ универы, фанги.
Плох: высокая стоимость недвиги по отношению к зп.
9) Барселона. 28.5 баллов.
Хороша в: климат, медицина, цена недвиги.
Плохо: гражданство, язык, преступность.
По большинству остальных средне.
10-11) Мадрид. 28.3 балла.
Как Барселона, но похуже климат, получше преступность.
10-11) Брюссель. 28.3 балла.
Хорошо: гражданство, медицина, образование, покупка недвиги.
Плохо: мало вакансий, нет фангов, преступность.
12) Франкфурт. 28 баллов.
Хорошо: гражданство, преступность, медицина, образование.
Плохо: мало фангов, мало вакансий, стоимость недвиги и стоимость жизни.
13) Париж. 25.3 балла.
Хорошо: гражданство, медицина, топ универы.
Плохо: язык, стоимость жизни и недвиги по отношению к зп.
14) Стокгольм. 24.8 балла.
Хорошо: распространенность английского, образование, медицина, безопасность.
Плохо: стоимость жизни и недвиги, получение гражданства.
15) Люксембург. 23.8 балла. Я там жил, лучшее место, но не очень хорошо для долгосрочной миграции программиста.
Хорошо: гражданство, безопасность, медицина, образование, английский.
Плохо: мало вакансий, кроме амазона, высокая стоимость жизни и недвиги.
16) Валенсия. 22.8 балла.
Хорошо: безопасность, медицина, образование, климат, покупка недвиги.
Плохо: гражданство, нет фангов, язык, мало вакансий, маленькие зп.
17) Прага. 22.1 балл.
Хорошо: безопасность, медицина, образование.
По большинству остального - сильно ниже среднего.
18) Порту. 20.5 баллов.
Хорошо: безопасность, медицина, климат.
По остальному - сильно ниже среднего. Хорошо, если вы не зарабатываете в Португалии, а там живете на инвестиции или полной удаленке/фрилансе. Но об этом у меня будет отдельный топ.
19) Лиссабон. 19 баллов. Почти как Порту, но чуть хуже.

Основные причины багов в проде

Это мой личный рейтинг причин на основе работы в 5 компаниях в 4 странах в течении почти двух десятков лет:

1) Качество разработчиков. В начале карьеры я думал, что основная причина - отсутствие процессов. Но потом на практике убедился, что это не так. Какие бы не были процессы (код ревью, тестирование, мониторинг и т.д.) вы не сможете всего предугадать и сделать защиту от дурака от всех возможных случаев. Процессы помогают, но при низком качестве разработчиков это не спасет от всех возможных случаев. В Мета процессов почти нет, тестирование минимально, при этом количество багов не такое большое. Если вы будете нанимать верхние персентили разработчиков по качеству (что бы это не значило), то они будут сразу писать правильно и без багов.
2) Конфигурации. Это вообще топ причина для фангов. Что в Амазоне, что в Facebook/Meta sev0, Large Scale Event аутеджи чаще всего случаются из-за деплоя конфигураций в прод. Конфигурации практически никак не тестируются, быстро деплоятся в прод (минуты). И никто не знает как они повлияют на систему. В них нет/мало проверок, как автоматических так и ручных. Нет особых процессов. Нет интуиции и опыта, как с кодом. Поэтому качество программистов не всегда спасает.
3) Проблемы версионирования/API. Это актуально, если у вас не монолит. Если вы дергаете какую-то зависимость, но ее поведение изменилось и стало не таким каким вы его ожидаете или изменился протокол взаимодействия, то это приводит очень часто к багам. Это типичная проблема микросервисных архитектур, особенно, когда зависимостей очень много.
4) Miscommunication, неправильное понимание задачи/бизнес логики. Тут часто не спасают ни тесты, ни качество программистов. Тесты не спасают, т.к. если вы не правильно поняли как это должно работать, то и в тесте вы будете проверять, что оно работает как ожидаете вы, а не как правильно. Качество программиста тут только гарантирует, что оно будет работать как вы ожидаете, но не как правильно.
5) Проблемы зависимостей. Это то, что сложно контролировать. Если ваша зависимость перестала работать, то тут только нужно убедиться, что ваша компонента fault tolerant и реализованы все нужные механизмы для сокращения blast radius. Например, retry, rate limiting/throttling, circuit breaker, bulk head и т.д.
6) Отсутствие достаточного тестирования. Это только на 6 месте у меня, т.к. при хорошем качестве программистов, это не обязательное условие. При низком качестве, если вы хотите минимизировать число багов - это must have. Если человек не глубоко понимает как работает, написанный им, код. Не видит все edge-cases. Не имеет опыта, не предвидит потенциальные проблемы. Если человек не внимателен к деталям, если он не умеет делать прогрессивный ролаут, мониторить, находить проблемы и их исправлять, пока они не станут влиять на систему, то все возможные тесты обязательны.
7) Отсутствие прогрессивного ролаута и мониторинга в проде. Тестировать и воспроизводить условия прода в тестах часто очень сложно. Поэтому иногда проще задеплоить это в прод, но добавить feature flag и ограничить, кто может пользоваться этим функционалом. Например, можно начать с одного пользователя или маленького процента пользователей. Посмотреть как это будет работать в условиях прода, собрать и проанализировать все метрики и потом уже разворачивать на больший процент пользователей.
8) Сложное сочетание редких событий/медленная деградация системы. Обычно, это сложно покрыть тестами заранее. Часть проблем можно отловить нагрузочным/перфоманс тестированием, но не всегда. Т.к. длительность теста ограниченна по времени и баг может воспроизводится в каких-то особенных условиях. Например, у вас какая-то проблема в коде с многопоточностью, или у вас есть подтекание памяти, которое не происходит на масштабах времени работы нагрузочного теста. Тогда проблема может возникнуть в проде через большой промежуток времени при определенных условиях, которые сложно предусмотреть во время тестирования. Также частично это покрывается качеством программистов, у кого есть опыт и интуиция возможных проблем, но далеко не всегда. Обычно, такие проблемы находят в проде, долго инвестигируются и потом уже под них добавляют какой-то особенный тест.
9) Отсутствие или плохой code review. Одна из задач code-review это найти баги. Это хоть и не основная, но важная часть. Когда пару других разрабов посмотрят на ваш код, они могут заметить баги, которые не заметили вы. Из всех компаний, где я работал, это реально работало только в Amazon. Во многих других компаниях code review или отсутствовал, или был формальным. Но чаще это просто был тул для создания холиваров и конфликтов между программистами и ничему не помогал.

Каков ваш опыт? Почему у вас в компании чаще всего возникают баги?

Heatwave в Лондоне

На этой неделе в Лондоне ожидается сильная жара. До +38°C. Обычно, такую погоду в UK называют heatwave (хитвейв).

При этом жара в UK переносится сильно хуже, чем в других странах. Тут даже температура выше +25°C уже не сильно комфортная.

Это связано с несколькими факторами:

1) Отсутствие кондиционеров в домах. Тут практически не бывает кондиционеров в жилых домах. Кондиционеры есть, в основном, только в офисах и магазинах. Сверлить фасад здания и повесить кондиционер вам никто не даст.
2) Дома - термосы. Дома строились с расчетом на накопление и удержание тепла внутри. У них хорошая теплоизоляция. А также стены сделаны из материала, который хорошо нагревается и долго держит тепло. Это хорошо в прохладную погоду, но не летом. Тут, в отличие от Германии и других стран Европы, не холодно зимой в домах. В Дюссельдорфе и Люксембурге, где я жил до Лондона, было сложно получить температуру выше 19-20 градусов зимой без больших счетов на коммуналку. В Лондоне такой проблемы нет (ну или не так заметна). Но летом это превращается в ад. Дом нагревается в жару и даже после того как жара спадает, стены продолжают еще долго отдавать тепло внутрь и удерживать от потерь наружу. На улице уже может быть 20, а в доме все еще больше 25.
3) Нет внешних ставень. Во многих странах Европы на окнах есть внешние ставни. Закрывать их можно изнутри дома. При этом они полностью блокируют свет, благодаря чему не нагревается само окно и помещение внутри. В Лондоне такого нет. Более того, во многих квартирах окна от потолка до пола, т.е. у вас такой аквариум, который сильно прогревается солнцем со всех сторон. В Люксембурге у меня в квартире были ставни, хотя страна не южная, типа Испании. Это было особенно хорошо ночью, можно было создать полную темноту в помещении на ночь. И все это хорошо сочеталось с +19°C внутри. Спать было заметачельно.
4) В жару очень часто полностью чистое небо. Не смотря на репутацию туманного Альбиона и дождливой страны, тут бывает очень солнечно. При этом на небе нет ни одного облачка. При таком палящем солнце, даже +25°C уже кажется жарой. А в сочетании с квартирами аквариумами, это делает жару внутри помещений невыносимой.