Андрей Марченко Dev заметки

Выше требования по коммуникации

Это то, что меня особенно удивило.

Уровень коммуникации у некоторых Principal инженеров здесь лучше, чем у большинства VP, которых я встречал в Тинькофф. И именно это долго меня тормозило.

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

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

Тут есть сильная культура написания и шаринга документов о своей работе, анонсов, апдейтов и результатов. То, что казалось мне «много» в Тинькофф, по факту оказалось довольно мало в Meta.

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

Хотя мне всё ещё далеко до некоторых Principal инженеров, которые умеют очень хорошо преподносить свою работу.

Они не просто говорят: «Я улучшил A».

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

Требования значительно растут без значительного роста ЗП

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

При этом увеличивается в основном только оклад, без мгновенного роста акций. И только в течение примерно 3 лет общая ЗП постепенно придёт к уровню, который был бы у меня, если бы я сразу пришёл на IC6.

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

Есть и другая проблема: новым IC6 довольно сложно закрепиться в компании.

Нужно быстро понять множество внутренних особенностей и требований, при этом конкуренция уже значительно выше. И если не успеваешь адаптироваться, performance review вполне может выбить тебя из компании.

При этом сейчас у меня появляются развилки, куда расти дальше.

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

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

Скорость роста зависит от компании

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

Middle → Senior → Lead → Architect → Head of Coretech Frontend.

При этом я год работал в Booking.com, и там повышение даже особо серьёзно не обсуждалось. Каждый раз скорее намекалось, что впереди ещё много лет, прежде чем оно станет возможным.

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

В Meta культура построена по-другому. Здесь вполне возможно быстрое повышение, если ты показываешь нужный impact.

Есть люди, которые приходят стажёрами и доходят до Staff примерно за 4 года. Я много раз видел шутки про 25-летних Staff в Meta с четырьмя годами опыта работы.

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

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

Что дальше?

Следующий уровень это IC7, и тут уже появляется намного больше сложностей.

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

Поэтому сейчас мой фокус: закрепиться в текущей роли, улучшить коммуникационные навыки и найти новую сильную команду, которая позволит продолжить рост дальше.

Promotion сильно зависит от команды и проекта

Promotion сильно зависит от того, в какой команде и на каком проекте ты оказался.

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

При этом недостаточно просто сделать работу. Нужно ещё правильно преподнести результат и нормально зафиксировать его в документах и артефактах, чтобы потом на это можно было ссылаться в performance review и promotion case.

Поэтому, если в команде просто нет подходящих проектов, сделать promotion становится намного сложнее, независимо от того, насколько хорошо ты работаешь.

В моём случае у меня уже была экспертиза в Performance и SRE, поэтому я начал работать над этим практически с первого дня.

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

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

Так постепенно и появился scope, который уже выходил за рамки одной команды.

То есть здесь важно, чтобы одновременно сошлось несколько вещей: правильная команда, подходящий проект, менеджер, который тебя поддерживает, и возможность показать достаточно большой impact.

Нужны крутые проекты и много активностей

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

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

Также нужно постепенно занимать какую-то нишу внутри команды. Например, в итоге я полностью отвечал за Reliability/Performance в проекте.

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

Мне в этом сильно помог AI.

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

Я всё время следил за новыми подходами, пробовал их использовать и в целом хорошо понимал сильные и слабые стороны AI.

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

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

Требования стандартизированы

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

С одной стороны, это сильно упрощает рост. С другой, создаёт ту самую конкуренцию за scope и возможность закрывать нужные требования. Все хотят кого-то вести, помогать, задавать direction и брать ownership.

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

Тут и появляется проблема: повышение сильно зависит от стабильной команды, проекта и менеджера. У меня с этим были проблемы, но повезло, что сохранялся один и тот же менеджер менеджера, с которым были хорошие отношения и который периодически подкидывал мне критичные проекты.

Сколько реально заняло повышение

Я с самого начала говорил менеджеру, что одна из моих целей это promotion. Но за 2 года у меня сменилось 5 менеджеров, и каждый раз я заново проговаривал эту цель и получал немного разный список требований и ожиданий.

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

После нескольких критичных проектов я уже начал понимать, что, скорее всего, закрываю большую часть требований для IC6. Но основная часть материала, на котором потом строился promotion case, появилась именно в этом году.

Как выглядел сам promo case

Для повышения составляется promotion case, который описывает твои действия за предыдущий период: какие проекты ты делал, как себя вёл и каких результатов добился.

При этом нужно закрыть определённые требования по нескольким направлениям: Product, Engineering Excellence, Direction и People.

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

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

То есть promotion дают не за потенциальную возможность когда-нибудь работать как IC6, а за то, что ты уже какое-то время фактически работаешь как IC6 и можешь это доказать результатами.

Получил повышение с Senior (IC5) до Staff (IC6) уровня после 2 лет работы в FAANG. До этого я также получил множество повышений в Тинькофф, с Middle до примерно Principal уровня, так что есть с чем сравнить. Поэтому решил написать небольшую заметку.

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

Поэтому я и перешёл с понижением, но с целью получить повышение хотя бы до Staff уровня. В итоге получилось.

Выше конкуренция

Первое, с чем я столкнулся в Meta, это значительно более высокий средний уровень инженеров. Я бы сказал, как минимум +1 или +2 уровня относительно российских стандартов.

То есть метовский Senior вполне мог бы пойти на Lead или руководящую позицию в Тинькофф. От Senior здесь ожидается практически полная организация работы вокруг проекта и координация других инженеров внутри него.

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

При этом внутри компании много людей, которые хотят продолжать здесь работать, потому что performance review значат очень много и можно довольно легко вылететь с работы. Тебя оценивают относительно других людей, поэтому желательно быть как минимум не хуже среднего уровня в своей команде.

Также много тех, кто хочет расти. И тут появляется война за scope, соревнование внутри команды за важные проекты, которые потом помогут с performance review и promotion.

Что конкретно меняется между IC5 и IC6

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

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

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

Так и появились интересные особенности:

* Работа с React/React Native/Relay-разработчиками - все легко поменять, так как это локальный код. Как итог, у меня есть N патчей и улучшений в React/React Native. Так же ты можешь просто пойти и поговорить с ними, попросить помощи решить свою проблему и даже повлиять на дизайн фич.
* Работа с реальными девайсами - так как мое приложение работает на девайсах, это сильно меняет разработку. Можно было посмотреть, как разрабатывают девайсы, как работает Android изнутри и как идет его разработка. Так же было интересно видеть развитие прототипов, когда девайс постепенно меняется и приходит к финальной стадии.
* Очень сильная внутренняя культура компании - интересно было видеть, как культура меняет разработку и влияет на людей. Особенно заметна разница между людьми, которые только пришли, и теми, кто работает в компании 8+ лет. При этом замечаешь и много минусов, например полную оптимизацию работы и проектов под performance review и покрытие требуемых axes, что иногда приводит до абсурдных ситуаций.
* Следить за ценой акции — моя оплата больше чем наполовину основывается на цене акций компании. А значит сильный рост или падение влияет даже на настроение. Хоть ты по сути никак не можешь повлиять на эту цену, но как минимум хочешь и желаешь компании роста. Так же каждый год накидывают новые акции — акции дают на 4 года и выплачивают каждый квартал. Это привязывает тебя к компании, так как твоя оплата растет, и особенно сильно растет, если цена акций увеличивается.
* Безлимит LLM-токенов - как итог, я почти перестал писать код руками и обычно использую 4+ LLM-сессии параллельно. В итоге давно трачу миллиард токенов в месяц. Сам по себе безлимит LLM-ресурсов влияет на подходы и на появление дополнительных инструментов, которые запускают множество ревью-процессов и анализов. Даже жалко становится, когда делаю собственные проекты и есть только личная подписка на Claude и Codex с зарезанными лимитами, которая не позволяет использовать те же подходы.

Но 13 мая был также последний мой день работы над Quest-девайсами. Меня просто взяли и перенесли в AI-организацию, сказав, что теперь я буду работать над AI-проектами. По всей видимости, буду AI-инженером. Не знаю каких-либо подробностей, но как минимум будет интересно узнать, как делают AI/LLM-продукты изнутри, и поработать с ML-инженерами.

Давно не писал в канал. 13 мая исполнилось 2 года, как я работаю в Meta и работаю над Quest-девайсами. Я разрабатывал магазин приложений - то место, где пользователи могут купить игры для девайсов. Все это время отвечал за производительность и работоспособность этого приложения + пилил фичи.

За это время я очень много узнал и перестроил то, как работаю каждый день. Недавно ко мне пришла аналогия: я начинал в маленькой компании, которая даже не была IT, где разрабатывал на PHP и заливал код на удаленный сервер через FTP. Потом я перешел в Тинькофф, где процессы уже были на ступень выше. Так и Meta стала еще одним значительным прыжком по сравнению с прошлым опытом.

Что я поменял в работе:

* Метрики - это то, чего мне не хватало в Тинькофф, и я даже создал первую версию Statist, чтобы решить эту проблему. При этом сейчас все инструменты работают отлично: куча данных, все быстро работает, есть трейсинги, алерты и многое другое. Я полностью пересмотрел свой подход к тому, как должны работать метрики в компании.
* A/B-тесты - это тоже отчасти был новый инструмент для меня. Но я увидел, как можно работать и строить процессы и инструменты так, чтобы делать A/B-тесты на ВСЕ фичи. И как A/B-тесты помогают понимать, как люди пользуются приложением, и изучать, насколько изменения важны.
* Отличная среда разработки. Правда, я опять вернулся к заливанию PHP на серверы, но теперь это работает отлично. Поднятие среды — это ровно 0 команд. Все просто работает.
* Идеальные деплои - можно сделать систему, где разработчику ни разу за 2 года не нужно будет проверять, что происходит с инстансом на продакшене, и править какие-либо конфигурации. Привет K8S с их сложностями и проблемами.
* Огромные монорепы - когда над репозиторием работает еще N тысяч инженеров и постоянно пушится код, это меняет сам подход и инструменты. В Тинькофф у меня был проект, где я разбивал монорепу для всего сайта на N репозиториев, и часть проблем была связана с инструментами и подходами. Теперь я вижу больше того, как можно организовать монорепу так, чтобы не было больно и при этом получать множество плюсов от такого подхода. Как итог, теперь я всегда начинаю с монореп для всех личных проектов.

Сейчас лечу в самолёте из отпуска, где есть бесплатный интернет от Starlink, и решил написать пост, потому что это сильно меняет впечатления от полётов, особенно если лететь больше 5 часов. Раньше приходилось заранее готовить контент: скачивать фильмы, ролики с YouTube или статьи, которые хотел почитать в самолёте. Да и вообще долгие поездки выбивали из привычного ритма. А с нормальным интернетом можно заниматься почти тем же, к чему привык за компом, только с дополнительным шумом и неудобным креслом.

При этом соединение стабильное, скорость скачивания больше 50 Мб/с, пинг низкий — около 65 мс. В итоге можно делать большинство привычных вещей: смотреть стриминговые сервисы, включая Twitch, играть в некоторые онлайн-игры или писать код с привычными AI-инструментами.

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

Привет! Давно ничего не писал в этот канал. Прошло уже 8 месяцев с тех пор, как я работаю в Reality Labs (Meta) и занимаюсь разработкой Quest Store — это место, где люди покупают приложения для устройств Quest. За это время я успел пережить один лэйофф и получить высокую оценку EE (Exceeds Expectations, «выше ожиданий») за 2024 год.

В основном я занимался производительностью и надежностью (Reliability) — тем, чем, собственно, и занимался последние 10 лет. И в этих аспектах особенно заметно, чем большие компании отличаются от остального мира. Например, в Т-Банке и Booking использовались общепринятые стандарты производительности и подходы SRE от Google. Google активно вкладывался в развитие/продвижение своих идей.

Meta же пошла во многом своим путем. Она появилась давно и, как и Google, параллельно развивала внутренние подходы, затачивая их под свои нужды. За годы требования к метрикам и инструментам росли, и в итоге базовый уровень здесь значительно выше, чем, например, в Booking.com или Тинькофф и подкреплено отличным инструментарием.

Для меня тоже многое изменилось в подходе к улучшению производительности. В Тинькофф я много работал над оптимизацией фреймворка Tramvai: как загружаются JS/CSS на клиенте, как происходит инициализация приложения и так далее. Это были довольно низкоуровневые оптимизации.

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

Это сильно изменило мои приоритеты. Вот несколько ключевых моментов:

- @defer и @stream. В статье https://engineering.fb.com/2020/05/08/web/facebook-redesign/ хорошо описаны подходы к загрузке данных. Например, при загрузке ленты постов бэкенд может отдавать данные как поток: по мере готовности посты отправляются клиенту. В итоге первые два поста загружаются максимально быстро и сразу показываются пользователю, а остальное подгружается в фоне в том же запросе. @defer работает похоже: приоритет отдается данным для экрана, который пользователь видит первым, а остальное загружается в фоне. Эти продвинутые подходы значительно ускоряют визуальную производительность приложения.

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

- Близость к командам, разрабатывающим React, React Native и Relay. Это похоже на то, как в Тинькофф я мог бы обсуждать задачи с разработчиками Tramvai и просить у них помощи. Здесь то же самое. При этом внести улучшения довольно просто. Например, мои правки для производительности React Native: https://github.com/facebook/react-native/pull/46103/files и https://github.com/facebook/react-native/pull/47965.

В итоге за 8 месяцев в Meta я как минимум посмотрел на тему производительности с другой стороны — с продвинутым инструментарием и подходами, где не пришлось строить этот процесс с нуля, как это было, например, в Тинькофф. И увидел изнутри огромную компанию с десятками тысяч инженеров и гигантским офисом MPK 22, 21, 12, где можно идти пешком с одного конца до другого 30 минут, а между концами офисов ходят шаттлы.

Сегодня я наткнулся на дискуссию вокруг Effector https://habr.com/ru/companies/vk/articles/839632/, когда одна из команд VK опубликовала пост с критикой и объяснением, почему они отказываются от этой библиотеки. Я следил за Effector с 2019 года и всегда считал, что он сложен и делает слишком большой акцент на управлении состоянием.

Мой прошлый подход

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

Этот подход повлиял на разработку фреймворка Tramvai, над которым я работал. Вот что было внутри:

- Простой менеджер состояния https://tramvai.dev/docs/features/child-app/state-management/ , похожий на Redux, но без глобальных обновлений при каждом изменении.
- React Query для загрузки данных https://tramvai.dev/docs/features/data-fetching/react-query , который полностью отвечал за это, причем данные с API не хранились в менеджере состояния.
- Для SSR использовались глобальные экшены https://tramvai.dev/docs/features/data-fetching/action : для каждой страницы регистрировался набор промисов с действиями, которые нужно было выполнить перед рендерингом страницы.

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

Новый взгляд

После перехода в новую компанию я увидел иной подход, основанный на Relay, который активно использует возможности React и при этом значительно упрощает схему, использованную в Tramvai. Relay — это клиент для GraphQL, позволяющий декларативно описывать необходимые данные для компонентов и связывать их между родительскими и дочерними элементами.

Ключевые улучшения:
- Замена глобальных экшенов: Вместо ручного прописывания экшенов используется useFragment https://relay.dev/docs/api-reference/use-fragment/ , который описывает набор данных, необходимых для текущего компонента. При подключении компонента родителем нужно связать необходимость загрузки этих данных https://relay.dev/docs/guided-tour/rendering/fragments/#composing-fragments , что повторяется на всех уровнях, формируя полную цепочку необходимых данных для страницы.
- Использование React Suspense: Этот подход позволяет улучшить визуальную производительность, загружая только необходимые данные. Появляется возможность пометить данные как необязательные для блокирующей загрузки, используя React.Suspense для отображения скелетонов на месте еще не загруженных компонентов.

Как это можно применить к Tramvai

Применяя эти концепции к Tramvai, можно было бы:
- Позволить каждому компоненту описывать необходимые данные для рендеринга. При этом без использования GraphQL, а как необходимые react-query которые необходимы для отрисовки компоненты, дальше это можно дедублицировать
- Связывать эти данные по цепочке к определению роута, просто лист промисов/query
- При переходе на страницу выполнять список промисов/query, которые нужно выполнить для страницы. При этом ожидая только блокирующие данные
- Использовать React Suspense для компонентов, данные которых еще не загружены. Все это автоматически, на основе информации, был ли выполнен query ранее


Преимущества нового подхода:
- Улучшенная производительность: Пользователь видит плавный переход между страницами, где новая страница уже отрендерена с данными для первого экрана, а остальное догружается в фоне.
- Упрощение организации кода: Разработчику не нужно думать о связи с SSR и последующей загрузке. Он просто определяет необходимые компоненту данные, а остальное происходит автоматически.


В итоге, я считаю, что этот способ оптимален для SSR React-приложений, обеспечивая баланс между производительностью и удобством разработки, а так-же открывает дверь к Server components. А так-же убирает большую часть сложности с State manager для большинства сайтов.

Всем привет, возвращаюсь с новой статьей: Edge Computing Demystified - From ISP Architecture to Global Content Delivery.

Недавно читал в новостях, что выходит из строя оборудование Google, и из-за этого YouTube будет хуже работать в России. И тут я вспомнил, что сам работал 10 лет назад в мелком интернет-провайдере, который уже тогда имел оборудование от Google для кэширования статичных данных. По сути, это и есть Edge-технологии, которые стали популярны в реализациях Edge Computing/Functions/Workers. То есть Google, как обычно, придумал крутые технологии задолго до всех. Получается, что Edge — это не что-то хайповое, а уже давно проверенные технологии, которые работают внутри большинства крупных CDN-сервисов.

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

Статью можете почитать тут: https://amarchenko.dev/blog/2024-07-22-edge-netwook/

Всем привет, в статье про FAANG компании я обещал рассказать куда в итоге прошел. И вот результат - в этот понедельник был первый день в Meta в Калифорнии. Буду работать на позиции senior full stack разработчика в Oculus команде.

Всем привет! Написал очередную статью с разбором Technology Radar 30 от ThoughtWorks. ThoughtWorks — это консалтинговая организация, в которой работают крутые инженеры, такие как Martin Fowler и Neal Ford. Каждые полгода компания ThoughtWorks выпускает список технологий, в которые они верят и которые начинают использовать. Последние семь лет я активно слежу за этим списком, так как он помогает мне понимать, куда движется IT-сфера и какие технологии я мог пропустить, находясь в своем информационном пузыре.

В этом выпуске делается акцент на AI/ML/LLM инструментах и новых сервисах, построенных на их основе, а также на решениях, которые помогают создавать подобные приложения. А также Infrastructure as Code для описания инфраструктуры проекта на языках по типу TypeScript.

В моем блоге вы можете найти разбор списка технологий по категориям с небольшим расбором, зачем все это нужно: https://amarchenko.dev/blog/2024-05-08-technology-radar-30/

Собрал для вас в одну папку авторов, ведущих блоги по фронтенду, веб-разработке и вокруг неё.

🔗 https://t.me/addlist/Z6Efi4jXwe9lODcy

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

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

Надеюсь, будет полезно ✌️

@web_platform | Поддержать канал 🤝

Привет всем! Опубликовал новую статью в своем блоге о NewSQL. Последние три месяца я много изучал то, как работают базы данных внутри: прочел несколько книг, прошел несколько курсов (кстати, у MIT прям отличный курс на эту тему), а также изучил ряд papers. В итоге, на основании всего изученного, получилась эта статья.

Меня давно интересовал вопрос, как устроены новые типы баз данных NewSQL. Если с работой PostgreSQL и в общих чертах с Cassandra было понятно, то оставались вопросы относительно таких систем, как Google Spanner или FaunaDB, предлагающих высокую консистентность и масштабируемость. Как они могут решить все сложности и почему они еще не стали универсальным решением и не сместили предыдущие поколения?

В статье вы найдете разбор SQL и NoSQL баз данных, подробный разбор NewSQL на примере FaunaDB, а также обзор Consensus протоколов, таких как Raft и Multi-Paxos, лежащих в основе множества распределенных систем. Также рассмотрены Two-phase commits и Calvin для распределенных транзакций.

Полный текст статьи доступен в моем блоге: https://amarchenko.dev/blog/2024-03-13-new-sql/

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

В итоге я выделил пачку ключевых моментов, на которые стоит обратить внимание при собеседовании, особенно в Big Tech и FAANG компаниях, где достаточно сложные интервью, отличные от того, к чему я привык. Когда требуется специальная подготовка и формат ответов.

В итоге написал статью в которой рассказываю о:
- Различных типах компаний;
- Нужен ли хороший английский на интервью?
- Моём подходе к Coding/System Design/Behavioral интервью
- Количестве задач, которые я решил, и моих рекомендациях по подготовке

Саму статью можете почитать в моем блоге https://amarchenko.dev/blog/2024-01-17-interview-experience/ и удачного вам прохождения интервью

Всем привет, давно я не писал новых статей, так как активно готовился к собеседованиям к FAANG компаниям. Пока жду результатов. Делюсь новой интересной статьей не под моим авторством, но содержащую интересную информацию про базы данных, основные проблемы и подходы:
- CAP-теорему
- LSM Tree – это популярный дизайн баз данных, наподобие Cassandra
- Bloom filters, позволяющие, не расходуя большой объем памяти, понять, обрабатывал ли ты ранее элемент
- Consistent Hashing – алгоритм распределения данных между хостами

Статья https://tontinton.com/posts/database-fundementals/ . В общем, советую почитать. Особенно если вы – full-stack или бэкенд-разработчик, так как все это необходимо знать для успешного прохождения system-design собеседований.

Также одна из интересных для меня тем – это реализация небольшого прототипа системы. Я подумываю написать на Node.js простую базу данных, которая внутри использует LSM Tree и при этом запускается как часть Node.js процесса. То есть сам Node.js будет выступать в роли бэкенда и базы данных. Такой дизайн используют, например, в Одноклассниках, только у них Java и Cassandra. Это помогает убрать задержки между бэкендом и базой данных и улучшить SLA. Но пока это только в планах.

Всем привет. Написал очередную статью. На этот раз про архитектуру и фреймворки. Ранее мне часто попадался новый фреймворк Service Weaver от Google для Golang, так как инженеры Google активно участвует в конференциях и рассказывают про этот фреймворк.

Первая мысль: "Очередной фреймворк, ничего интересного". Но на деле этот фреймворк реализует интересную модель, когда во время деплоя можно выбрать, как именно проект будет задеплоен - как множество микросервисов? Как модульный монолит? Или как множество модульных монолитов?

И это определенно необычный подход, который позволяет решить ряд проблем микросервисов. В статье подробнее разбираю, как работает эта "магия" внутри, на основе каких компонентов построен Service Weaver и как это можно реализовать в Node.js.

Статья доступна на английском: https://amarchenko.dev/blog/2023-10-19-service-weaver/

В своей статье я использовал расширение deoptexplorer-vscode https://marketplace.visualstudio.com/items?itemName=rbuckton.deoptexplorer-vscode для сбора профайл информации V8 и последующего удобного просмотра. На удивление все это легко можно запустить, расширение имеет хороший UI. А значит это:
- Рабочий инструмент для создания оптимизированных библиотек
- Позволяет понять на примерах механизмы работы V8, включая концепции, такие как hidden-classes, turbofan, Monomorphic, Polymorphic, Megamorphic, PACKED_SMI_ELEMENTS и прочее.

Привет всем! Опубликовал новую статью на тему Memory Cache. Тема кэширования меня всегда привлекала своей вариативностью и отсутствием универсального решения. В прошлом, я уже реализовывал простые версии LRU cache, в том числе и на собеседованиях. Недавно наткнулся на исследование нового алгоритма кэширования — S3-FIFO. Он ещё не был реализован для JS, и это меня заинтересовало. S3-FIFO отличается простотой, но при этом по обещаниям обеспечивает отличную производительность и высокий hit rate.

В статье найдете:

- Зачем нужен Кэш и почему важен hit rate?
- Разновидности алгоритмов кэширования: 2Q, LRU cache, S3-FIFO.
- Возможные угрозы: как атака на кэш может нарушить работу приложения.
- Детальное рассмотрение и реализация S3-FIFO.
- Результаты тестирования в плане производительности и cache hit.
- Бонус: профилирование кода в V8 и поиск мест деоптимизации.

Статья доступна на английском: https://amarchenko.dev/blog/2023-10-12-memory-cache/
А так-же ссылка на самому библиотеку: https://github.com/Tom910/effective-cache

Channel name was changed to «Андрей Марченко Dev заметки»