Бодрый кодер

Сижу готовлюсь к выступлению, остался час.

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

#analystdays #ad21

Вышла GPT5.1. Как всегда быстрее, лучше, умнее.

Я пока сильно разницы не заметил, кроме скорости.

Так же появилась кастомизация «стиля» ответа.

#openai #chatgpt #gpt5.1

Тут балуюсь с оптимизацией сборки Next.js приложения, при сборке docker образа, отжирается 50 гигов. Самое приложение, меньше гига.

Люблю фронтенд.

После оптимизации удалось добавиться увелечение только на 6 гигабайт, после окочания джобы + 1 гиг на кэш.

#cicd #nexjs #reacr

Мне, как спикеру прошлого Highload, был доступен один билет на любую конференцию «Онтико» в течение года. Очно не смог, поэтому взял онлайн на прошедший Highload в Москве.

Начал смотреть и сразу первый доклад попал прямо в сердечко: «Деньги или скорость? Экономика выбора: Python vs Java vs Go при разных RPS».

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

#доклады #выбораязыка #go #python #java

Всех с пятницей и рабочей субботой :)

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

Яндекс оказывается обновил систему найма и сделал это не плохо.

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

https://habr.com/ru/companies/yandex/articles/959986/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🚀 Ищем волонтеров на крупнейшие IT-конференции в Москве!

HighLoad++ — это конференция в России и СНГ, посвящённая разработке высоконагруженных систем, архитектуре, инфраструктуре и масштабированию.
TeamLead Conf — единственная профессиональная конференция для тимлидов и руководителей не только из IT.

Если тебе интересно увидеть закулисье одного из самых масштабных IT-событий страны, получить опыт организации конференции и стать частью сильной команды — присоединяйся к волонтёрам 💪

🗓 Даты участия: 4–11 ноября (можно выбрать 4 дня или один из дней)
📍 Место проведения: Технопарк «Сколково»

Что тебя ждёт:
– уникальный опыт работы на ведущих конференциях в России
– общение с экспертами и профессионалами из крупнейших IT-компаний
– понятные задачи и поддержка координаторов
– доступ к записям выступлений и атмосфера закулисья
– полноценное питание в дни работы
– и, конечно, участие в легендарном afterparty HighLoad++ 🎉

Задачи волонтёров: работа в залах, помощь в логистике на площадке, регистрация участников, помощь в зоне выставки.

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

📩 Чтобы присоединиться, заполни анкету волонтёра — мы свяжемся с тобой после рассмотрения заявки.

Расскажи о наборе друзьям, приходите вместе — давайте создавать легендарную атмосферу🔥

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Южной Корее НАМЕРТВО остановилась работа всего государства — из-за одного пожара в датацентре уже неделю не работает практически ничего.

Огонь накрыл сервера Национальной службы Информационных Ресурсов (NIRS): там хостились все государственные сервисы, базы данных и облачные системы.

Всего в очищающем пламени пали 647 государственных сервисов, из них 96 уничтожены полностью. Сгорели:

— Местные госуслуги;
— Система удостоверения личности;
— Государственное облако хранения документов — миллионы записей утеряны безвозвратно;
— Государственная почта;
— Образовательные базы университетов;
— Финансовые и административные сервисы.

858 терабайт данных сгорели вместе с бэкапами — они хранились на сервере в соседней комнате.

Предварительно: причина пожара — возгорание литий-ионной батареи во время её замены.

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

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