Мне пришло понимание, почему я не воспринимаю российский big tech как tech. Для меня весь российский tech кроме Яндекса — это "бизнес с айти", а не "technology".

Я как-то слышал фразу от сотрудника раннего Амазона, что до появления AWS, Амазон по большому счёту был интернет-магазином с отделом разработки.

Только когда Амазон начал создавать новые технологии и платформы — свои ЦОД, электронные читалки Kindle, облачные сервисы, Alexa — он стал по-настоящему технологической компанией. Только тогда непосредственно технологические разработки стали либо продуктом, либо платформой для продукта, которые очень сложно скопировать, не имея технологий.

Банк, интернет-магазин или сайт объявлений с ИТ-отделом используют созданный другими технологический фундамент для достижения своих бизнес-целей. То есть это в первую очередь бизнес, а какой уж там стек под капотом — вторично.

Это крутые бизнесы, но их конкурентное преимущество — в процессах, маркетинге и партнёрствах. Приложения и сайты попросту отражают эти процессы.

Команда сильных программистов сможет скопировать стек Авито, Т-Банк и Озон (смогут ли они достигнуть масштаба — это другой вопрос, скорее всего, нет). Однако, команда сильных программистов не сможет скопировать и создать с нуля поиск Яндекса, операционную систему Windows (Microsoft), LLM (OpenAI), Kubernetes (Google), Lambda (AWS) или фреймворк React (запрещённая соц сеть), когда в мире ещё нет аналогов, которые можно скопировать.

Помимо умения писать код и комбинировать современные технологии в продукт, такие платформы требуют глубокой технической экспертизы в узком домене. И дело даже не в том джун программист или синиор. Требуется другой подход — программисты в компаниях с ИТ-отделами решают прикладные задачи, а в настоящем tech есть группы людей (далеко не все!), которые занимаются computer science и создают то, чем потом пользуются все.

Я был в нескольких митингах с Марком Брукером, создателем AWS Lambda, у которого больше патентов, чем у кого-либо в Амазоне. Сейчас он Distinguished Engineer (его коллеги по цеху в Амазоне, это такие люди как Джеймс Гослинг, создатель Java). Это человек с другой планеты. Он по-другому мыслит.

Я не утверждаю, что одни компании лучше других. Они просто разные. И те, и другие в первую очередь зарабатывают деньги. Но разница в подходе позволяет по-настоящему технологическим компаниям становиться мировыми лидерами, потому что их технологии становятся платформами для всех остальных, в то время как бизнес, который "просто" бизнес — привязан к одной компании или даже к одной географии.

Меня спросили в комменте типа «не пойдешь в русский тех?»

Я подумал, подумал и наверное пошел бы куда-то пилить API-first продукт для разработчиков как CPO.

В бизнес-жаргоне много военных терминов. Есть они и в айти.

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

В книге The Pragmatic Programmer, Дейв Томас и Эндрю Хант говорят о применении этого подхода к разработке. Вместо того, чтобы пилить софт пошагово и сразу правильно, сначала нужно создать его каркас, работающий от и до (end-to-end).

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

По мере разработки мы наполняем каркас, постоянно проверяя, что всё работает.

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

Всегда был оверачивером. Знаете какая самая большая проблема у оверачиверов?

Мы считаем себя недоачиверами.

Всегда ощущение, что можно больше. Что что-то упущено. Мало.

Можно сказать «не парься». Но это как сказать человеку с РПП «ну ты просто перестань есть». Как сказать алкашу «ты просто перестань пить».

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

Нужно просто учиться использовать эту энергию умеренно и лишний раз себя не гнобить. Радоваться тому, что уже получилось. Просто знать, что в будущем тоже получится, не загоняя себя в яму тревожностью.

Жить в настоящем.

Есть выражение “the grass is always greener on the other side”, символизирующее побег от текущей реальности в реальность воображаемую, где непременно ждёт разочарование.

На другой работе будет лучше. В другой стране будет лучше. С другим человеком в отношениях будет лучше.

Те из нас, кто уже пожил достаточно на этом свете, знают, что иногда это действительно так, но чаще — совсем не так.

Другая работа — такое же болото. В другой стране всё так же через ж.пу, только по-другому. Другой человек такой же абьюзер.

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

The grass is greener where you water it.

Это так просто и так гениально. Трава зеленее там, где мы её поливаем.

Искать хорошее в том, что есть. Менять то, что не нравится. Постригать и поливать свой газон вместо того, чтобы искать новый, как только на твоём завяли цветы.

Цветы завяли не потому что они плохие. А потому что ты не ухаживал за ними.

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

Искусство жизни — в том, чтобы регулярно отлавливать клопов-вонючек и удалять их со своего газона, поливать траву и полоть её от сорняков.

Ключевое слово — регулярно.

Я очень люблю фразу “do what you love, love what you do”. Её суть в том, чтобы относиться к тому, что есть, с заботой и любовью. Когда любишь то, что делаешь, ты начинаешь делать то, что любишь.

Всем пис и хорошего начала рабочей недели ❤️

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

С этим согласен 100%.

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

Если вы уезжаете из провинции покорять Москву или западное побережье США, то это качественный скачок (step function change), которого невозможно достигнуть в вашей локации/индустрии. Если уходите из QA в разработку, потому что хотите создавать, а не проверять чужой код, это тоже качественный скачок.

Трава на новом месте не обязательно будет зеленее во всех её проявлениях. Но вы попадаете на качественно иной луг. Отказываетесь от одуванчиков ради пышной тропической растительности.

Где пальме хорошо, там берёзе смерть :)
- (из комментов)

Пальмы вам тоже могут остоп.здеть и захочется обратно в берёзки, но если ваша цель — побыть Индианой Джонсом, то такие скачки того стоят. К берёзкам можно всегда вернуться, а сожаления о неувиденных пальмах будут терзать до самой смерти.

Как мы дожили до такого интернета?

С чат жпт не нужны никакие психоделики.

Осирис против бетховена

«Ваши любимые фильмы»

Год назад нам бесплатно сделали сайт. На тот момент у нас не доходили руки и кстати попался молодой парень, который предложил поработать забесплатно, за опыт.

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

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

Но оно кагбэ работало да и ладно.

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

Пока Арнаб колесит по западному побережью в роадтрипе, подготовлю ему PR на 2000 строк, который можно не ревьювить.

Потестим в проде.

В тему предыдущего поста.

ChatGPT умеет генерировать новые и видоизменять существующие SVG!

Если не знакомы с форматом - это формат изображения, в котором прописываются «пути движения» геометрических фигур в формате, для понимания которого нужна твердая шестерка по геометрии.

<svg width="100" height="80" viewBox="0 0 100 80" xmlns="http://www.w3.org/2000/svg">
<path d="M10 20 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
<path d="M10 40 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
<path d="M10 60 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
</svg>

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

Это улёт, ребята. Я в восторге.

Анекдот от чат жпт.

Приходит как-то продакт-менеджер к разработчику и говорит:
— Ну-ка, отгадай загадку: «Без кода, без тестов, на проде фичи работают».
Разработчик думал-думал и говорит:
— Баги!
— Нет, это костыль! Ладно, вот тебе ещё одна загадка: «Два коммита, один пуш, а посередине деплой».
Разработчик долго думал и говорит:
— Баги!
— Нет, это CI/CD!

Продакт-менеджер ушёл, а разработчик решил проверить джуна. Пока шёл, всё в голове перепутал. Приходит к джуну и говорит:
— А ну, отгадай загадку: «Без кода, без пуша, полна жопа багов».
Джун в замешательстве:
— Что-то не то, кажется…
Разработчик:
— Вот и я думаю, что не то, а продакт-менеджер говорит, CI/CD!

И ещё один

Приходит как-то продакт-менеджер к разработчику и говорит:
— Ну-ка, отгадай загадку: «Без ТЗ, без сроков, но задача на вчера».
Разработчик думал-думал и говорит:
— Это твоё устное требование!
— Нет, это agile! Ладно, вот ещё одна загадка: «Два экрана, три кнопки, а багов миллион».
Разработчик долго думал и говорит:
— Это твоё требование!
— Нет, это MVP!

Продакт-менеджер ушёл, а разработчик пошёл к джуну проверить, как тот соображает. Пока шёл, в голове всё перепутал. Приходит к джуну и говорит:
— А ну, отгадай загадку: «Без сроков, без экранов, полна жопа багов».
Джун растерялся:
— Что-то чушь какая-то…
Разработчик:
— Вот и я думаю, что чушь, а продакт-менеджер говорит, agile!

А как прошла ваша неделя?

P.S. Я чёт надеялся, что удалённого кода будет больше, чем нового. Но я добавил пару фич по ходу дела, поэтому не вышел из меня мега-сеньор, который удаляет кода больше, чем пишет.

Кто-нибудь знает какие фреймворки для мобильных приложений используют Т-Банк, Сбер, Озон и Авито?

Приложения выглядят одинаково как под копирку. Стало интересно.

В преддверии уходящего 2024 года, я решил сделать небольшой фейл.

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

До 2 ночи сделал всё, что было нужно. Потом вспомнил про баг, который хотел пофиксить. Проковырялся с ним до 3 утра, ничего не пофиксил, за.бался и выгорел напоследок.

Плюс здесь в том, что работа мне сегодня ненавистна и я точно уже не буду о ней думать в новогоднюю ночь.

Всех с наступающим! 🎄

Пока каникулы, я делюсь сказочно красивым и ностальгическим зимним Иркутском в сторис.

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

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

Stop the bleeding — остановить кровотечение

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

Это основной принцип операционки в Амазоне.

Roll back first. Fix later.

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

Хотя это и называется roll back, как правило мы всё же делаем "roll forward" — создаём новый коммит, который убирает проблемные коммиты из главной ветки (main). Таким образом, у нас не возникает несоответствия между главной веткой и кодом на проде даже в кризис.

Если проблемы с инфраструктурой — жрутся ресурсы, не хватает мощностей, тупо скейлим инфраструктуру (scale up/out), чтобы дать системе больше ресурсов. Восстанавливаем стабильность, потом разберёмся почему возникла проблема.

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

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

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

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

Ну ок. Это хорошо для производительности, всё клёво. Более того, функция пока ещё не была удалена и она продолжает работать. В смысле, пока продолжает работать, но в будущем будет удалена.

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

Пока Арнаб спит, я сам пофиксил баг в коде (хорошо не быть на 100% зависимым от СТО!), всё потестил и подготовил PR. Через пару часов начнём выкат новой версии в прод. Заодно проверим насколько работает механизм ускоренного ревью — вроде у Apple можно попросить ревьювнуть побыстрее, если это багфикс и изменение простое.

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

Заключение: мобильное приложение — это вам не веб, шипать баги в прод очень с.ка больно.

🤡 Оказалось, это был билд в бете. Я с утра с недосыпу проапгрейдился до самого свежего билда для внутреннего использования и забыл об этом в суматохе.

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

Как полагается клиентоориентированному продакту, начал паниковать что есть мочи 🙈

Отменяю все выводы.

Тесты можно пока не писать 👌

Кто-нибудь может посоветовать USB-C хаб/концертратор с DisplayPort, чтобы выдавал хотя бы 144 Hz в 4k?

Нужно такой, чтобы можно было купить в России.

Смотрю на Озоне и не доверяю ничему, что вижу 🙈