management

Дефолтный доклад Андрея про расклеивание лейблов и нахождение баланса в скилах

Stream-aligned teams от Тинькофф: про то как утроить разработку вертикально

Открытый справочник по ценностям, бизнес-процессам, стандартам, процедурам и правилам, которые мы используем в команде разработки в Авито.

How I influence tech company politics as a staff software engineer Influencing anything if you’re not in managing is hard because you lack formal authority. The same reason it is so hard to go beyond senior engineer: you need a completely different set of skills. This not that gives a hint to engineers how to expand your influence the right way. TL;DR: build projects which align with company goals. See the details inside. #management #career

–

Пятничное чтиво

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

————————————— Optimistic Concurrency Control: Alice and Bob Couldn’t Sit Together

Проблема распределенных вычислений — гонки связанные с изменением данных. Для чего используют локи. Если говорим о гонках на уровне базы, то кажется, что можно не запариваться, так как в 80% случаев код скорее всего будет работать. Но в цельности, знать о локах и уметь использовать подход придется. А с пониманием работы поможет статья, где автор рассказывает об оптимистичной блокировке в контексте постгреса.

Статья крутиться вокруг одного примера: Алиса и Боб хотят купить билеты в кино. При этом, сделать это так, что бы сидеть рядом. Дальше Боб делает транзакцию, в которой проверяет наличие двух мест рядом и ждет, пока Алиса забронирует место, чтобы самому забронировать место рядом (транзакция все еще висит). Но в этот момент появляется Mallory, которая также хочет забронировать место (но не может из-за транзакции Боба). Дальше Боб с Алисой делают UPDATE для бронирования места и коммитят транзакцию. И по итогу, Mallory окажется без билета, а Боб с Алисой пойдут в кино. А во второй части показано как будет работать optimistic lock для aws Aurora DSQL.

#sql #optimistic_lock

—————————————

Simple tips for managing any project.

Статья от Simon Wardley (это тот, кто придумал карты вордли), в которой рассказывает о базовых принципах в управлении проектами, который использует 15 лет. Для этого он рассказывает о проекте, в котором изначально выбрали не корректно элементы системы из-за чего начались проблемы. Дальше описываются шесть вопросов, которые помогут решить проблемы с проектами. Шаги похожи на то, что предлагает стратегический DDD и если шаги сгруппировать получите следующие направления:

• понимание пользователей и их нужд;
• определение capabilities, которые закрывают нужды пользователей;
• понимание развития компонентов, которые связаны с capabilities;
• менеджмент компонентов.

Дальше автор описывает проблемы, из-за которых происходят провалы. Тут найдете: проблемы с коммуникациями, mismatched expectations стейкхолдеров, проблемы с ясностью целей, проблемы с remote teams, культурными особенностями и проблемы с границами элементов.

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

#management #product

—————————————

How Stripe Processed $1 Trillion in Payments with Zero Downtime

Очередная статья из серии «как в компании X решили проблему Y». На этот раз это страйп, который обработал триллион долларов платежей за год без простоев. Изначально страйп использовал mongoDB, сначала казалось что база проще реляционной в работе. Но из-за нагрузки и количества данных оказалось, что вариант так себе. При этом шардирование монги не помогло (в тексте найдете кусок о том, как шардирование работает). В результате появилась DocDB, основанная на монге, где за хранение и извлечение отвечает монга, а за шардирование и миграции отвечает DocDB.

Дальше описывается, как работает Data Movement Platform — штука, которая помогает перемещать данные между шардами, особенно когда размер шарда выходит за допустимые пределы и нужно добавлять новый. Проблема тут не только в том, чтобы переместить информацию, но и сделать так, что бы связанные данные также переместились в нужный шард. Дальше описан полный алгоритм работы шардирования. А в конце найдете ссылку на оригинальную статью

#how_it_works #sharding

Stripe’s hand-crafted system that guarantees their data never gets lost

Insights on companies, salaries, jobs and more!

Пятничное чтиво

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

————————————— Optimistic Concurrency Control: Alice and Bob Couldn’t Sit Together

Проблема распределенных вычислений — гонки связанные с изменением данных. Для чего используют локи. Если говорим о гонках на уровне базы, то кажется, что можно не запариваться, так как в 80% случаев код скорее всего будет работать. Но в цельности, знать о локах и уметь использовать подход придется. А с пониманием работы поможет статья, где автор рассказывает об оптимистичной блокировке в контексте постгреса.

Статья крутиться вокруг одного примера: Алиса и Боб хотят купить билеты в кино. При этом, сделать это так, что бы сидеть рядом. Дальше Боб делает транзакцию, в которой проверяет наличие двух мест рядом и ждет, пока Алиса забронирует место, чтобы самому забронировать место рядом (транзакция все еще висит). Но в этот момент появляется Mallory, которая также хочет забронировать место (но не может из-за транзакции Боба). Дальше Боб с Алисой делают UPDATE для бронирования места и коммитят транзакцию. И по итогу, Mallory окажется без билета, а Боб с Алисой пойдут в кино. А во второй части показано как будет работать optimistic lock для aws Aurora DSQL.

#sql #optimistic_lock

—————————————

Simple tips for managing any project.

Статья от Simon Wardley (это тот, кто придумал карты вордли), в которой рассказывает о базовых принципах в управлении проектами, который использует 15 лет. Для этого он рассказывает о проекте, в котором изначально выбрали не корректно элементы системы из-за чего начались проблемы. Дальше описываются шесть вопросов, которые помогут решить проблемы с проектами. Шаги похожи на то, что предлагает стратегический DDD и если шаги сгруппировать получите следующие направления:

• понимание пользователей и их нужд;
• определение capabilities, которые закрывают нужды пользователей;
• понимание развития компонентов, которые связаны с capabilities;
• менеджмент компонентов.

Дальше автор описывает проблемы, из-за которых происходят провалы. Тут найдете: проблемы с коммуникациями, mismatched expectations стейкхолдеров, проблемы с ясностью целей, проблемы с remote teams, культурными особенностями и проблемы с границами элементов.

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

#management #product

—————————————

How Stripe Processed $1 Trillion in Payments with Zero Downtime

Очередная статья из серии «как в компании X решили проблему Y». На этот раз это страйп, который обработал триллион долларов платежей за год без простоев. Изначально страйп использовал mongoDB, сначала казалось что база проще реляционной в работе. Но из-за нагрузки и количества данных оказалось, что вариант так себе. При этом шардирование монги не помогло (в тексте найдете кусок о том, как шардирование работает). В результате появилась DocDB, основанная на монге, где за хранение и извлечение отвечает монга, а за шардирование и миграции отвечает DocDB.

Дальше описывается, как работает Data Movement Platform — штука, которая помогает перемещать данные между шардами, особенно когда размер шарда выходит за допустимые пределы и нужно добавлять новый. Проблема тут не только в том, чтобы переместить информацию, но и сделать так, что бы связанные данные также переместились в нужный шард. Дальше описан полный алгоритм работы шардирования. А в конце найдете ссылку на оригинальную статью

#how_it_works #sharding

Alice and Bob want to go to the cinema together and sit next to each other. However, each will book…

Premature optimization “Premature optimization is a root of all evil”, right? Optmizations are actually about doing 3 “T” properly: a right thing at a right time and about the right trade-offs. Alex Ewerlöf wrote a new great piece of advise that I found incredibly relevant, at least my former experience proofs so.

A big collection of useful questions to ask potential employers.

Пятничное чтиво

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

————————————— Optimistic Concurrency Control: Alice and Bob Couldn’t Sit Together

Проблема распределенных вычислений — гонки связанные с изменением данных. Для чего используют локи. Если говорим о гонках на уровне базы, то кажется, что можно не запариваться, так как в 80% случаев код скорее всего будет работать. Но в цельности, знать о локах и уметь использовать подход придется. А с пониманием работы поможет статья, где автор рассказывает об оптимистичной блокировке в контексте постгреса.

Статья крутиться вокруг одного примера: Алиса и Боб хотят купить билеты в кино. При этом, сделать это так, что бы сидеть рядом. Дальше Боб делает транзакцию, в которой проверяет наличие двух мест рядом и ждет, пока Алиса забронирует место, чтобы самому забронировать место рядом (транзакция все еще висит). Но в этот момент появляется Mallory, которая также хочет забронировать место (но не может из-за транзакции Боба). Дальше Боб с Алисой делают UPDATE для бронирования места и коммитят транзакцию. И по итогу, Mallory окажется без билета, а Боб с Алисой пойдут в кино. А во второй части показано как будет работать optimistic lock для aws Aurora DSQL.

#sql #optimistic_lock

—————————————

Simple tips for managing any project.

Статья от Simon Wardley (это тот, кто придумал карты вордли), в которой рассказывает о базовых принципах в управлении проектами, который использует 15 лет. Для этого он рассказывает о проекте, в котором изначально выбрали не корректно элементы системы из-за чего начались проблемы. Дальше описываются шесть вопросов, которые помогут решить проблемы с проектами. Шаги похожи на то, что предлагает стратегический DDD и если шаги сгруппировать получите следующие направления:

• понимание пользователей и их нужд;
• определение capabilities, которые закрывают нужды пользователей;
• понимание развития компонентов, которые связаны с capabilities;
• менеджмент компонентов.

Дальше автор описывает проблемы, из-за которых происходят провалы. Тут найдете: проблемы с коммуникациями, mismatched expectations стейкхолдеров, проблемы с ясностью целей, проблемы с remote teams, культурными особенностями и проблемы с границами элементов.

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

#management #product

—————————————

How Stripe Processed $1 Trillion in Payments with Zero Downtime

Очередная статья из серии «как в компании X решили проблему Y». На этот раз это страйп, который обработал триллион долларов платежей за год без простоев. Изначально страйп использовал mongoDB, сначала казалось что база проще реляционной в работе. Но из-за нагрузки и количества данных оказалось, что вариант так себе. При этом шардирование монги не помогло (в тексте найдете кусок о том, как шардирование работает). В результате появилась DocDB, основанная на монге, где за хранение и извлечение отвечает монга, а за шардирование и миграции отвечает DocDB.

Дальше описывается, как работает Data Movement Platform — штука, которая помогает перемещать данные между шардами, особенно когда размер шарда выходит за допустимые пределы и нужно добавлять новый. Проблема тут не только в том, чтобы переместить информацию, но и сделать так, что бы связанные данные также переместились в нужный шард. Дальше описан полный алгоритм работы шардирования. А в конце найдете ссылку на оригинальную статью

#how_it_works #sharding

The questions you need to ask.

A source-control branching model, where developers collaborate on code in a single branch

Процесс организации процесса разработки, альтернатива gitflow.

Про гугл:

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

Про нетфликс:

• Никакого контроля со стороны менеджеров, полная свобода действий у инженеров
• Инженеры сами решают, что нужно делать. Менеджеры только пытаются им продать свои идеи и объяснить, почему они важные.