Вступил в клуб кому за 30, а в душе мне 22.

Как же бесит, что в confluence при редактировании статьи нельзя переключиться в режим исходника, а не вот этот вот WYSIWYG.

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

Как это всегда бывает, нашлись уникумы, которые хотели снега и всего того дерьма, который появляется вместе с ним в Москве.

Ну что же? Встречайте!

Microsoft релизнула новый движок для python в vscode на основе их статического анализатора pyright - pylance, но из коробки он не запускается. Ну как так?

31

Интересно, сколько должен стоить НГ ужин чтобы на нем НЕ включали Лепса?

НГ праздники - время когда можно найти парковку на Патриках, да еще и бесплатно

С момента как мы сели на карантин прошло ровно 2 года, но по ощущениям прошла вечность.

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

11го октября, ночью, произошло интересное событие, которое навело меня на некоторые размышления. Гильдия Frontier первая убила Лича на официальном сервере World of Warcraft в режиме hardcore.

Предыстория
Коротко о World of Warcraft в режиме hardcore. Я думаю, что все так или иначе играли в разные компьютерные игры - на ПК, на PlayStation, на телефоне, это не важно. Во всех играх есть возможность умереть и воскреснуть или загрузить прошлое сохранение, чтобы попробовать пройти сложный уровень еще раз. Обычно в играх всегда есть право на ошибку, а зачастую оно еще и имеет бесконечное количество повторений. Суть World of Warcraft в режиме hardcore в том, что права на ошибку нет, вообще нет, совсем нет. Если ты играл 1/2/3 месяца, прокачивая своего персонажа и получая какие-то вещи для его экипировки, то в случае его смерти ты теряешь все. Ты теряешь все эти месяцы игры, и тебе придется начинать заново, с чистого листа.

История
Интерес данной новости в том, что гильдия в 40 человек смогла за 1.5 месяца (сервера открылись в сентябре) убить всех боссов в игре и закрыть весь контент, практически не совершая ошибок, то есть не теряя своих участников. Повторяюсь - любая ошибка в режиме hardcore при походе на боссов в WOW ведет к смерти персонажа и полной потере всего, что ты, как игрок, нафармил за 1.5 месяца. Также стоит учесть, что в походе на боссов смерть одного члена рейда может привести к гибели всего рейда. Потеря одного члена может вызвать дисбаланс, который в свою очередь может привести к гибели всего рейда.

Размышления
Так как гильдия Frontier смогла этого достичь? На мой взгляд это:
-- постановка амбициозной цели
-- ультра высокий уровень работы в команде, в том числе доверия
-- невероятные навыки коммуникации их рейд-лидера

В Magnit Online, где я сейчас работаю, мы написали свод принципов, которые объединили в инженерную культуру. С одной стороны, они кажутся простыми и понятными для любого здравомыслящего инженера. С другой стороны, некоторым сотрудникам приходится время от времени напоминать о простых истинах, и наши принципы очень помогают в этом, так как они фиксированы на "бумаге".

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

Кстати, одним из источников вдохновения при написании наших принципов была книга автора Рэя Далио - "Принципы". Советую прочитать ее.

Из внутреннего корпоративного мессенджера.

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

📖📖📖 Предыстория 📖📖📖
У кого был или есть швейцарский нож? У меня был в детстве. Помню, как мой отец подарил его мне, сказав: "Вот теперь у тебя есть всё, что нужно для похода в лес". Нож, конечно, был крутым, но в 90% случаев я пользовался только его основным лезвием, а остальными инструментами - лишь изредка. Например, открывашка для пива была крайне полезной в те моменты, когда возникало желание что-то попить 🍻🍻🍻.

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

Принцип «Швейцарского ножа»

Кто понимает разницу между кодером и разработчиком? Я для себя ее четко осознал, когда начал работать в Магнит и провел 100+ собеседований.

Кодер
По моему мнению, кодер - это просто исполнитель (пишущая машинка), который пишет код на основе технического задания, и других спецификаций/документации, с минимальным погружением в задачу и проект. Такие инженер (кодеры) обычно работают или работали в аутсорсинге, где оплата идет по часам, и заказчику мало интересно, что происходит внутри: главное - соблюдение сроков и запуск проекта. Мне искренне жалко инженеров, которые в начале своей карьеры попадают в среду, где формируют неправильное представление о работе инженера-программиста (software engineer).

Разработчик
На другой стороне находится разработчик, который создает архитектуру, самостоятельно уточняет требования, пишет код с тестами, умеет в DevOps и следит за работой своего продукта (сервиса) в prod окружении. Мое почтение таким инженерам. Именно разработчики создает что-то новое, что-то выдающееся, именно разработчиков ждут в стартапах, где нет четких правил и понятного плана работ, именно разработчики могут заложить правильную инженерную культуру в компании. Однако, иногда они могут быть занозой в том самом месте, так как, как правило, обладают своей сильной точкой зрения, и если она не совпадает с вашей, могут возникать конфликты.

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

Интересные размышления по этогу вопросу есть в этой статье.

Наверное, вы знаете, что совсем недавно Магнит приобрел KazanExpress. Прямо сейчас мы находимся в стадии анализа, каким образом будем объединять технологии обеих компаний, чтобы достичь лучших решений для обоих бизнесов.

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

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

1. Теперь в Москве две улицы Мира. Что делать?
2. Теперь в городе две мэрии. Куда отправлять работать депутатов?
3. Что делать с мэром города, которого влили в Москву? По ходу оказалось, что он указами от правительства нафигачил объектов, которых нет ни в одном кадастровом реестре. Что делать с этими объектами?
4. Плитка в Красногорске была вертикальная, а стандарт в Москве - горизонтальная. Когда и главное, кем, всё нужно переложить?
И так далее.

Самое сложное в объединении инфраструктуры - это правильно объединить сети и общую адресацию. Обычно приходится вносить изменения в текущую инфраструктуру, чтобы не сломалось приложение. Сложность растет линейно с количеством инфраструктурных компонентов. У нас есть 160 микросервисов, а у КЕ уже насчитали 110. Так что это довольно большой кусок работы.

На прошлой неделе я побывал в гостях у ребят из завтракаст. Поговорили о PaaS, выборе языка разработки для backend, джунах и еще о многом другом. Например, cможете узнать как я чуть не бросил ВУЗ.

Видеозапись доступна по этой ссылке, а yandex подкаст по этой.

Какой у вас в компании freeze? code freeze? release freeze? feature release freeze?

Каждый год вокруг этого вопроса разгораются споры. Как внутри IT, так и между IT и бизнесом.

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

Хотя, у той же Apple бывают задержки при ревью в сторе в период рождественских праздников.

Несколько красивых графиков и чисел наших DORA-метрик.

Lead Time for Changes (LTFC) - весь Q3/Q4 активно работали над этим вопросом. Обнаружили множество проблем в наших процессах разработки и фиксили их. Одной из стандартных проблем являются большие Merge Request'ы, которые проходят через долгие этапы ревью, тестирования и интеграции. Это следствие плохой декомпозиции задач.

Deployment Frequency (DF) - у нас все в порядке, мы еще не достигли уровня elite, но все равно показатели не плохие.

Change Failure Rate (CFR) - исходя из стандарта, мы уже находимся в elite зоне, но нашей внутренней целью является снижение CFR до уровня не более 3%.

Кто не понимает, о чём вообще речь, бегите читать книгу "Accelerate".

Хочу поделиться одним интересным примером, где "копирование не воровство" вышло на какой-то невероятный для меня уровень.

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

На мой субъективный взгляд данный концерт HYBRID THEORY Live @ Altice Arena 2023 (Full Show), в чем-то лучше чем оригинальные концерты, думаю что всем поклонникам linkinpark и nu-metal будет крайне интересно.

В общей сложности я писал на Python более 12 лет. Начинал я еще с Python 2.5, когда учился в вузе, а закончил уже на Python 3.10 в Magnit. Как Python-программист, я прошел через ряд классических задач, актуальных в 2010-х годов. Я полностью ощутил все сложности миграции большого Django-проекта с Python 2.7 на Python 3.5, внедрял MyPy на большом легаси-проекте, переписывал проект с синхронного кода на асинхронный. Не могу сказать, что у меня были высокие теоретические знания Python на тот момент, но как практик я мог реализовать любой коммерческий проект.

Мне довелось использовать множество популярных и не очень библиотек и фреймворков: Eventlet/Greenlet, Flask, Django, Starlette, FastAPI. Однако со временем, когда я уже работал в ostrovok.ru, мне пришлось начать писать немного на Golang. Не могу сказать, что Golang сразу же мне понравился, но мне очень понравился подход к обработке ошибок. Я настолько им проникся, что стал применять такой же подход к обработке ошибок на Python, то есть без использования исключений.

Как руководитель разработки в Magnit, я использовал свой административный ресурс, чтобы инвестировать свое время и время своих разработчиков в python-тулинг для backend разработки. Я понимал, что Python никогда не будет на одном уровне с Golang по производительности, но я верил, что огромное сообщество Python сможет предложить что-то, чтобы Python оставался хорошим выбором для backend разработки. Отличным примером работы сообщества стало появления pydantic и его последующее развитие в pydantic2. Я рассказывал о нашем опыте миграции на pydantic2 на Moscow Python Podcast.

Зачем я это все рассказываю? Мы, Magnit Online, начиная с первого квартала 2024 года, больше не пишем новые сервисы на Python для обработки пользовательских запросов с мобилки и веба, используем только Golang.

P.S.: Хочется верить, что производительность Python позитивно изменится после реализации subinterpreters, которые обещали представить в Python 3.13/Python 3.14.