Я тут хвалил новые веб приложения в телеге, тут вообще удивился. Открыл себе карту, для оплат, дополнительную. За 2 минуты. Банкинг в телеге - это конечно мощно и удивительно.

P.S. Не реклама сервиса, только начал пользоваться , если понравился и проблем не будет - порекомендую.

https://habr.com/ru/news/947188/

Тяжело будет сделать ревью после 7 часов такого кодинга.

Мой подписчик написал комментарий, который тянет на пост:

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

+ точность ордера ограничена 1 миллисекундой. если прилетело 5 запросов в одну миллисекунду — нет способа зарезолвить порядок. это кстати касается и бэкенда если что... но (!) при смене мастера — если часы рассинхронизированы больше чем на 1 миллисекунду возможны уже скачки во времени.
если у тебя реплики в разных датацентрах - скорее всего рассинхрон порядка 10-100мс, и значит точно будет прыгать.
что собственно не защищает и бэк, находящийся на разных инстансах за балансиром...

это не то что бы минусы uuid7, просто ограничение модели, но о них важно помнить, если не хочется гулять по граблям)

Вместо #пятничныйюмор . Так выглядит 42 года прогресса.

Мне правда еще не разу не удавалось держать стол таким девственно чистым.

Понедельник начинается с хороших новостей - мой доклад про GitOps для аналитиков взяли на Analyst Days.

В этом осенне-зимнем сезоне будет всего одно выступление, ну может два.

#anystdays #доклады #выступление

Всех с предстоящими выходными, а меня с предстоящими рабочими. Еду в Красноярск на неделю, в командировку.

#пятничныйюмор

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

Очень много про процессы разработки, но теперь надо как-то найти время послушать - даже на x2 это 2часа :(

https://youtu.be/qjPH9njnaVU?si=vOBG2tXbIbBKF6f8

В целом классическая история, когда все яйца в соседней комнате.

💬 Собеседование — это не экзамен, а разговор двух взрослых людей

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

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

Вот мои основные 👇

⚙️ Про техническую свободу
• Как принимаются архитектурные решения: через pull request или через комитет?
• Может ли команда выбирать стек и инструменты?
• Кто деплоит в прод: команда или выделенные админы?

🧭 Про процессы и ответственность
• Как формируется roadmap — команда участвует или всё спускается сверху?
• Что происходит, если команда не успевает к сроку?
• Есть ли ретро, и меняется ли после них что-то на самом деле?

🤝 Про культуру и атмосферу
• Можно ли спорить с архитектором или руководителем?
• Что у вас происходит, когда кто-то ошибается?
• Как вы относитесь к инициативам “вне задач”?

🧍‍♂️ Про своё место в экосистеме
• Где проходит граница ответственности роли?
• Как строится взаимодействие между твоим отделом и остальными?
• Можно ли влиять на процессы — CI/CD, код-ревью, документацию?

Каждый из этих вопросов — не формальность.
По ответу (и по интонации!) сразу видно: перед тобой открытая команда или бюрократическая матрица.

А вы что спрашиваете на собеседованиях?
Какие вопросы помогают вам понять, стоит ли туда идти? 👇

Всех с выходными. #пятничныйюмор

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

Эта утилита закрывает историю с квотами в Яндекс облаке и finOps.

https://habr.com/ru/articles/955382/

Для поста слишком много текста, поэтому опубликовал новость на Хабре.

Для меня это наверное самая любимая CMS. Как с точки зрения разработчика, так и с точки зрения пользователя. Благодаря ей, до сих пор работает (но уже не развивается) семейный блог - https://nemirovblog.ru. Из известного, например Y Combinator и еще как минимум двадцадка крупных медиа изданий и тысячи более мелких.

https://habr.com/ru/news/956572/

Писали что в Apple Pay сейчас нельзя добавить карту, с регионом Россия,но у меня вроде все норм, добавилось.

У кого-то были проблемы?

Сегодня пятница, а значит #пятничный юмор.

Я тут не много подгорел и фрустрировал. Но удалось выдохнуть.

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

Знаете, я тут недавно поймал себя на странной мысли: мне реально нравится работать с легаси-проектами. И нет, меня не подменили.

Помню, раньше загорался от каждого нового проекта. Проект с нуля! Чистый лист! Можно взять свеженькую библиотеку, настроить идеальную архитектуру, выбрать все самые современные инструменты. Все новое, модное, никакого старого багажа. Красота же!

А потом начинается реальность. Ты сидишь и думаешь: как правильно спроектировать эту фичу, которую еще никто не использовал? Какая структура БД будет оптимальной для кейсов, которые мы еще даже не знаем? А вдруг через полгода всё придется переписывать, потому что не учли какой-то важный сценарий?

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

А вот легаси... Вот где магия.

Да, открываешь такой проект – и там хаос. Функция на 500 строк с тремя уровнями вложенных циклов. Бизнес-логика размазана между контроллером, сервисом и каким-то вспомогательным модулем. Запрос к базе, который считает что-то через жопу и работает по 3 секунды. Переменная с названием temp2_new_final_REALLY_USE_THIS.

Но знаете что? Это всё работает. Прямо сейчас. В проде. Приносит деньги. Обслуживает реальных пользователей с их реальными сценариями.

И вот тут начинается кайф. Ты видишь узкое место – переписываешь кусок кода. Сразу можешь прогнать тесты (которые уже есть!), посмотреть на мониторинг, получить обратную связь. Нашел странную логику – разбираешься, почему так сделали, и часто оказывается, что это решает какой-то граничный случай, о котором ты бы в новом проекте даже не подумал.

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

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

Так что да, я теперь тот странный разраб, который радуется легаси-проектам 🙂

В проекте появляется файл CODEOWNERS, и все думают: «Ура, наконец-то порядок! Теперь никто не сломает критичную логику!»

Прописываем владельцев для каждой папки. Настраиваем обязательные проверки. Теперь любое изменение в платежах должен одобрить Вася, а в авторизации – Петя. Безопасность! Контроль! Качество!

А потом начинается реальность.

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

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

Вот тут я понял: CODEOWNERS – это не про код. Это про людей.

Файл не защищает от багов. Он не сделает код лучше магическим образом. Он не заменит нормальное ревью. Он просто создает точку синхронизации между людьми.

И есть два способа его использовать.

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

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

Я видел проекты, где CODEOWNERS превратился в проблему. Каждый владелец стал узким местом. Люди начали обходить систему – делать коммиты в обход, просить "просто апрувни, я сам проверил".

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

А еще видел проекты, где CODEOWNERS вообще нет. И знаете что? Они прекрасно работают. Команда просто сама договаривается, кого позвать на ревью критичных изменений. Без формальных правил, без обязательных блокировок. Просто на доверии и здравом смысле.

Так что если собираетесь добавлять CODEOWNERS в проект – сначала подумайте не про файл, а про команду. Есть ли у вас люди, которые реально готовы быть владельцами? Хватит ли у них времени? Доверяете ли вы остальным разработчикам настолько, чтобы не требовать аппрувы на каждый чих?

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