Задачка про разделение торта поровну между двумя детьми

На день рождения мне подарили книгу "Ученые шутят" (составители Б. С. Горобец, Ю. А. Золотов, С. Н. Федин), которую я уже почти прочел. В ней много интересных историй, но одна мне понравилась особо - это история про Берию, что назначал министров угольной промышленности. Ниже я напишу ее полностью, но сейчас хотел поговорить про упрощенную постановку проблемы честного разделения ресурсов, как я узнал ее почти 10 лет назад из курса "Making Better Group Decisions: Voting, Judgement Aggregation and Fair Division" от Eric Pacuit из University of Maryland:
Предположим, что есть торт и два голодных ребенка. Они хотят поделить торт поровну без участия третьей стороны. Если торт однородный (например, шоколадный торт с равномерно распределенной ванильной глазурью), то найти справедливое разделение несложно - торт можно относительно ровно порезать. Но как нам найти «справедливое» разделение торта, если он неоднороден (например, глазурь, состоящая на 1/3 из шоколада, на 1/3 из ванили и на 1/3 из клубники), и каждый ребенок хочет разные части

торта?

Примерно такую задачу помог решить Берия двум министрам, между которыми делили угольную промышленность СССР (цитата из вышеупомянутой книги "Ученые шутят")

Назначение министров угольной промышленности

(рокировка по Берии)

Он <Берия> был мастером неожиданных и нестандартных решений. <...> Политбюро приняло решение разделить наркомат угольной промышленности, которым руководил В. В. Вахрушев, на два - для западных районов страны и восточных. Предполагалось, что возглавят их соответственно В. В. Вахрушев и Д. Г. Оника. Поручили разделение провести Берии. Можно представить, сколько мороки вызвала бы подобная процедура при обычном бюрократическом подходе. Берия вызвал Вахрушева и Онику и предложил им разделиться полюбовно. А по истечению срока вызвал обоих и сначала спросил у Вахрушева - претендента на руководство западными районами отрасли, - нет ли претензий. Тот ответил, что претензий нет, и всё поделили правильно. Тогда Берия обратился к Онике: "Как вы?" Оника заупрямился: "У меня есть претензии. Все лучшие кадры Вахрушев себе забрал. И все лучшие санатории и дома отдыха тоже". Видя такое дело, Берия рассудил: "Раз Вахрушев считает, что все разделено правильно, а Оника возражает, то сделаем так: Вахрушев будет наркомом восточных районов, а Оника - западных". И совещание на том закончил

В общем, если обратиться к "Задаче справедливого разрезания пирога", то видно, что Берия применил алгоритм, который называется дележ без зависти (envy-free). В этом алгоритме каждый партнер думает, что его кусок как миниму так же ценен как и все остальные. Такой дележ может быть произведен при помощи процедуры дели-и-выбирай: один партнёр режет пирог на два сектора, которые он считает равными, а другой партнёр выбирает сектор, который он считает лучшим. Для пирога может существовать процедура и лучше, а вот для угольной промышленности ее придумать сложнее. Думается, что именно поэтому Берия остановился на этом простом алгоритме, но забавно, что он заранее не предупредил кандидатов о том, как будет принимать решение об их поллюбовном разделении.

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

P.P.S.
ИЗ курса мне особенно запомнилась теорема Эрроу, которая еще называется теоремой "о невозможности демократии" как "коллективного выбора" или "теоремой о неизбежности диктатора". Смысл этой теоремы состоит в том, что

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

#PopularScience #Math #Management #Leadership

Growing Your Personal Design Heuristics • Rebecca Wirfs-Brock • YOW! 2019 - Part 1

Посмотрел на днях выступление за авторством Rebecca Wirfs-Brock, заслуженной бабушки, что написала две книги: "Designing Object-Oriented Software" в 1990 и "Object Design: Roles, Responsibilities, and Collaborations" в 2003. Она является изобретателем Responsibility-Driven Design, одного из первых поведенческих подходов к объектному дизайну. В итоге, если вы слышали про X-driven design (XDD), где X - это произвольное слово, то можете поблагодарить Ребекку за то, что она проложила эту дорожку.

В этом выступлении Ребекка рассказывает про эвристики, как они помогают принимать дизайн решения и как собрать осмысленно свой набор эвристик. Речь идет про
- Кулинарные рецепты, в которых инструкции недостаточно точны, чтобы следуя им напрямую получить желаемое блюдо
- Потом следует вывод, что не существует замены для обучения на своем собственном опыте и рефлексии относительно него
- Дальше автор разбирает то, что такое эвристика и разбирает четыре варианта: rule of thumb, practical method, useful shortcut, approximation. И бракует пару последних вариантов. В итоге, ее определение близко с определениями из wikipedia

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

- Следом за этим Ребекка начинает погружаться в примеры эвристик из разных областей и вспоминает про Мартина Фаулера с его эвристикой для структурирования domain layer, где он предлагал много лет назад три варианта: transaction script pattern, table module pattern, domain model pattern. И Ребекка откапывает тут стюардессу для того, чтобы показать, что эвристики устаревают со временем, так как state-of-the-art постоянно прогрессирует и мы сталкиваемся с новыми проблемами и придумываем новые эвристики для решений. Тут она показывает и другой набор эвристик для дизайна и вспоминает про хранимую процедуру со 100 входными параметрами, которую ей когда-то пришлось ревьювить:) В итоге, следует вывод, что между эвристиками и их пользователями всегда будут нестыковки и надо уметь договариваться.
- Поговорив про эвристики для дизайна, Ребекка переходит к обсуждению мета-эвристик, а точнее эвристик для использования других эвристик. Тут приводится пример с разделением команд, паттерн для первого контакта с системой.
- Следующим шагом идет эвристика, которая определяет наше поведение и отношение к происходящему. Для себя Ребекка вывела эвристику, что она ценит больше консистентность, а не ум. Интересно, что еще в школе я видел похожую эвристику у своего учителя по физике (ниже история скрыта за спойлером)
В лицее у меня был учитель по физике, который выучил кучу призеров международных олимиад по физике. Его эвристика по оцениванию учеников была примерно такой: "Я ценю больше старание и усилия, чем ум". Так у меня в школе итоговой оценкой по физике от него стала четверка и это с учетом учебы в 10 и 11 классе в ЗФТШ и поступление в МФТИ. Просто я был недостаточно сфокусированным на саморазвитии в области физики:)
- Для того, чтобы эвристики не протухали, их требуется переодически испытывать на прочность. Дальше Ребекка обсуждает эвристики насчет размера микросервисов - в 2019 году это было горячей темой:)

А алгоритм для развития эвристик будет в отдельном посте, так как в этот он не поместился:)

#Management #Software #SoftwareDevelopment #Patterns #Engineering #SelfDevelopment

Growing Your Personal Design Heuristics • Rebecca Wirfs-Brock • YOW! 2019 - Part 2

Продолжая первый пост, расскажу про сам алгоритм, что предлагает использовать Ребекка

1) Она рекомендует составить карту своих интересов, а дальше пошарить и обсудить свои любимые эвристики с экспертами в этих темах - это позволяет проверить свои эвристики на прочность, понять их границы применимости и получить новых эвристик. Для записи эвристик Ребекка предлагает использовать технику, что похожа на описание паттернов, но попроще. Для этого можно использовать карточку: рассматриваемый вопрос, эвристика, пример использования эвристики для решения этого вопроса. Дальше Ребекка приводит примеры своих записей эвристик.
2) Также можно пойти от противного - найти эвристику, которая противоречит вашей и дальше попробовать подобрать аргументы "за" и "против" для этой эвристики. Интересно, что это напоминает способ развития переговорщиков, когда требуется уметь выступать как за свою позицию, так и за позицию оппонента:)
3) Дальше Ребекка предлагает общаться один на один, обсуждая конкретную тему. Это пересекается с описанным в первом пункте.
4) Фильтровать то, что звучит на конференциях (иронично, что это выступление тоже было на конференции)
5) Записывать то, как вы действительно работаете
В итоге, она предлагает

Record your design values & practices

И в этом контексте вспоминает Майкла Найгарда с его ADR (Architecture Decision Records), которые он предложил использовать для фиксации архитектурных решений в 2011. Кстати, про его книгу "Release it" я писал раньше.
А напоследок Ребекка предлагает следить за тем, что происходит при применении эвристик и использовать это для их тюнинга.

#Management #Software #SoftwareDevelopment #Patterns #Engineering #SelfDevelopment

Ученые шутят

Сегодня я дочитал книгу про шутки ученых разных специальностей, в которой собраны интересные истории с искрометными шутками известных ученых, забавных случаев со студентами и лекторами, просто байки и научные анекдоты. Авторами-составителями были реальные ученые: Б. С. Горобец, Ю. А. Золотов, С. Н. Федин, с нереальным чувством юмора:) В итоге, книга является компиляцией избранных частей из четырех книг
- "Математики тоже шутят" (4-е изд. М.: URSS, 2012)
- "Советские физики шутят... Хотя бывало не до шуток" (2-е изд. М.: URSS, 2010)
- "Химики еще шутят" (6-е изд. М.: URSS, 2010)
- "Геологи шутят... И не шутят" (3-е изд. М.: URSS, 2011)

Мне книга очень понравилась, хотя некоторые истории я уже знал. Отдельно стоит отметить, что подача в книге достаточно простая, поэтому книгу можно смело рекомендовать всем, кто любит хороший юмор:) Ради примера приведу еще один пример шутки из книги, что мне понравилась, как вчерашняя история с Берией и его подходом к разделению пирога на двоих.

Математик заполняет анкету:
- "Где вы работаете?" - в математическом институте.
- "В чем заключается ваша работа?" - изучаю уравнения Фредгольма первого рода
- "Каково ваше хобби?" - уравнения Фредгольма второго рода

Эта шутка нравится мне тем, что у меня похожая связь между работой и хобби:)

P.S.
Думаю, что я буду переодически к месту вспоминать шутки из этой книги:)

#PopularScience #Physics #Math #Humor

Cultivating Production Excellence • Liz Fong-Jones • YOW! 2019

Еще один доклад про SRE практики от инженера, который получил их работая в Google. Liz Fong-Jones только в начале 2019 года ушла в Honeycomb, а до этого 10 лет работала в Google. Интересно, что новая компания Liz занимается observability инструментами, которые полезны инженерам, заботящимся о надежности своих систем.

Основные тезисы доклада такие
- Production системы становятся все сложнее (особенно при использовании микросервисов и big data) и укратить эту сложность бывает сложно
- Что такое надежность и как ее померить (и что такое uptime)?
- Не стоит покупать DevOps - это не коробки вида Honeycomb, IaaS, K8s, и другие крутые слова. Devops - это пру культуру
- Дальше обсуждение алертов, дашбордов, предсказуемости деплоев, etc
- Возврат от технических систем к социотехническим системам и важность мыслей о людях, кто развивают и поддерживают наши системы
- Лиз предлагает инвестировать в культуру, людей и процессы для того, чтобы повысить надежность систем - и именно это она называет production excellence
- Для повышения production excellence она предлагает целый комплекс мер
- Составить план, опредлиться с метриками и смотреть как они улучшаются
- Вовлекать всех (не только инженеров, но и продактов, финансистов и саппорт)
- Начать Лиз предлагает с того, чтобы научить определять, что что-то с продом идет не так и иметь возможность задебажить эту проблему
- И более сложный совет - это устранить ненужную сложность (но проще сказать, чем сделать):)
- Если системы постоянно ломаются по определенным причинам, то стоит устранить эти причины
- Для измерений Лиз предлагает использовать уже стандартные SLI/SLO/SLA - индикаторы, цели и соглашения по уровню оказания сервисов (это стоит использовать как общий язык с неинженерными специальностями: продактами, финансистами, etc)
- Дальше Лиз объясняет, что для измерения этих показателей надо понимать какие критичные user journeys и дальше думать в разрезе конкретных событий (events)
- И надо уметь определять хорошее событие или плохое (а также фиксировать как успешные, так и неуспешные события - отсюда можно посчитать availabilty) и выставлять thresholds для уровня доступности
- Тут же упоминается проведение chaos экспериментов для определения чувствительности пользователей к уровню сервиса
- Дальше идет речь про то, как понять какое окно использовать для расчета показателей (день, неделя, месяц, etc)
- Важность не упарываться в надежность чрезмерно - важно искать баланс между затратами на надежность и возможностью выделять время на развитие сервиса через добавление новых фич
- Как использовать SLO для генерации alerts и определение error budgets
- Как использовать данные для того, чтобы понимать сколько сейчас требуется тратить времени команды на надежность (совет ориентироваться на бюджет ошибок)
- Помимо SLI & SLO надо еще уметь дебажить проблемы на проде:)
- Для этого надо использовать observability инструменты (кстати, у нас в Tinkoff есть своя observability платформа Sage, которую даже можно потрогать снаружи)
- Дальше Лиз говорит о том, что надо уметь различать почему у нас есть отклонения в показателей работы разных сервисов
- Ну и заканчивается все возвратом к культурным вопросам:
-- что героизм - это не устойчивая стратегия для решения проблем,
-- дебаггинг - это совместная работа, надо тренировать команды работать вместе
-- требуется документировать архитектурные решения и как работают наши системы
-- надо использовать общие инструменты и платформы
-- стоит вести blameless postmortems для инцидентов
- Плюс в конце идет речь про управление рисками - про вероятность и влияние, которые определяют уровень риск. Обычно можно уменьшить вероятность проблем, выбрав те, что влияют на SLO и приоритизировав эти задачи в беклоге. Ну и начать надо с улучшения observability.

P.S.
На тему надежности можно почитать материалы из моего поста "Проектируем надежные системы"

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE #Reliability #Conference

Как читать книги

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

P.S.
Через пару дней сделаю выжимку из этой тонкой книги - она определенно заслуживает краткого обзора.

#Reading #SelfDevelopment #Writing

Публичное интервью по System Design на ArchDays

Сегодня появилась запись публичного интервью, что я проводил на ArchDays 2023. В качестве собеседуемого выступал Никита Староверов, мой коллега из Тинькофф Инвестиций. В этом интервью мы проектировали простую систему для проведения a/b экспериментов в стиле Firebase a/b testing. Мне показалось, что интервью прошло хорошо и интересно, особенно учитывая то, что Никита был не знаком с предметной областью, но при помощи дополнительных вопросов он смог собрать всю нужную информацию. В итоге, мы спроектировали неплохой прототип + обсудили вопросы от зрителей.

P.S.
Через несколько дней я напишу статейку с своим решением этой задачи.

P.P.S.
Если вам интересна тема system design, то можно почитать и другие мои материалы
- в общем про system design в Tinkoff
- больше про то, как мы оцениваем прохождение собеседования
- как подготовиться к собеседованию

#SystemDesign #Interview #Architecture #SoftwareArchitecture #Software #SoftwareDevelopment #DistributedSystems

What You Need To Be A CTO • Simon Raik-Allen • YOW! 2018

Интересный доклад на тему зоны ответственности CIO от спикера, что поработал как в больших, так и маленьких командах. Классно, что рассказ
- сопровождается отличным юмором
- содержит разбор ролей CIO, CTO, VP Engineering
- рассматривает ситуацию как в больших, так и в маленьких компаниях, а также в консалтинге
- пестрит визуализациями с диаграммами Эйлера-Венна для иллюстрации разных зон ответственности, например business - executive - engineering - product - clients - board -...
- показывает что именно делает CTO во всех этих случаях и на что влияет
- расладывает на составные части финмодель условного стартапа и показывает почему CTO и другим инженерам надо понимать откуда появляются деньги и куда они уходят
- показывает как выглядят локальные оптимизации и почему helicopter взгляд CTO позволяет с большей вероятностью прийти к глобальной оптимизации
В итоге, автор выводит такое обобщение роли CTO
Steer technology and people towards the medium-term through knowledge sharing and influence
Ну и бонусным треком в самом конце выступления автор рассказывает как общаться с executive
- не надо говорить на техническом языке - надо говорить на языке бизнеса (на это рекомендую посмотреть книгу Technology Strategy Patterns, что мы обсуждали в Code of Architecture)
- не говорить тупых вещей
- иметь логичный план достижения бизнес-целей в той области, за которую отвечает конкретный executive

P.S.
Я тоже рассказывал доклад с похожей темой на Highload++
- вот запись выступления
- вот расшифровка

#Management #Leadership #Engineering #Career #Software #SoftwareDevelopment #SelfDevelopment