Книжный куб

Разработка Web-приложений с использованием UML (Building Web Applications with UML) Достал с полки эту раритетную книгу, которой уже больше 20 лет:) В ней автор в начале 2000х рассказывал про web разработку и как там применять UML. Я решил понастальгировать и вспомнить как выглядели книги по проектированию и разработке во времена начала моей карьеры:) Эта книга была написана в 2000 году - Сразу после появления Ajax (Asynchronous JavaScript and XML) в 1999, но в книге в основном рассказывалось про апплеты Java, элементы ActiveX - Еще до появления Agile Manifesto в 2001 и поэтому упор был на RUP (Rational Unified Process) как итеративный процесс разработки - Еще до заката UML (сложно определить конкретную дату), поэтому в книге UML прикручивается ко всему, даже DOM-страничке:) - Еще до рассвета Agile, поэтому есть глава про определение архитектуры, в которой говорится про use cases и три паттерна: тонкий клиент, толстый клиент и распределенный вариант с блекджеком и шлюхами CORBA (Common Object Request Broker Architecture) и RMI (Remote method invocation) - Еще до повального увлечения user stories, поэтому есть целая глава про требования, функциональные и нефункциональные и их ранжирование В главе про реализацию забавно смотреть на sequence и activity диаграммы web-системы, которая совсем не выглядит интерактивной:) А в главе про реализацию по старой традиции приведены простыни html кода (десятки страниц), который, видимо, надо было перепечатывать для воспроизведения примеров у себя:) В общем, сейчас эта книга скорее является букинистической диковинкой и окном в прошлое веб-разработки, чем полезным источником знаний:) #Software #SoftwareDevelopment #UML #Engineering

Hello Deep Learning • Bert Hubert • GOTO 2023 Интересное выступление Bert Hubert с рассказом про Deep Learning на пальцах. Сам Bert достаточно известный товарищ, который является немного ученым, разработчиком и предпринимателем. Забавно, как вначале он говорит, что много лет игнорировал хайп вокруг deep learning, отчасти потому что также яро проповедовали и blockchain, который оказался пшиком. Но после появления chatGPT игнорировать глубокое обучение уже было нельзя и он решил погрузиться в этот домен. Для этого он выбрал подход, что похож на "Kubernetes the hard way" от Kelsey Hightower. Для этого Берт взял стандартную задачу по распознаванию цифр и решил ее решить с нуля:) А дальше он кратко рассказал про - Статью Attention is all you need - NIST и его подборку рукописных цифр как базу для обучения - Подход втупую через вычитание значений пикселей для 3 и 7 между собой и ручное разделение множеств - Дальше усложняем с перемножением на рандомную матрицу - Дальше добавляем функцию потерь (loss function) - Переход к трем слоям для классификации цифр по десяти категориям - Добавление нелинейности при перемножениях (ReLU и GELU) - Добавление градиентов для обучения коэффициентов модели и получение хороших результатов - Добавление шума в исходные данные и получение полного треша в качестве результатов от обученной модели и дальше автор говорит следующее

Production use of a neural network tends to go through these four phases (if you are lucky): 1. It works on the training data 2. It also works on the validation data 3. After a lot of disappointment, we get it to work on other people’s real life data too 4. Other people can get it to work on their own data as well

Almost all demos declare victory after phase 2.

И дальше автор делает финальные выводы по выступлению - Deep learning реально - Deep learning позволяет получать магические результаты - Deep learning не является волшебным и обманчиво простым - Все еще можно попасть на борт этого корабля:) В итоге, автор предлагает не опираться на внешние API облачных сервисов, а делать свои продукты поверх решений, доступных on-premise. Автор предлагает посмотреть на следующие материалы - Whisper.cpp: state of the art voice transcription in dozens of languages, entirely self-contained on your own computer/phone: https://github.com/ggerganov/whisper.cpp - LlaMA “GPT-like”, self-contained, own computer etc: https://github.com/ggerganov/llama.cpp - https://berthub.eu/articles/posts/hello-deep-learning/ - the series behind this presentation, https://github.com/berthubert/hello-dl - https://berthub.eu/articles/posts/ai-is-guaranteed-to-disrupt-us/ #ML #DataScience #Data #Math #Software #SoftwareDevelopment #Engineering

Занимательная математика Эта книга Якова Перельмана как-то обошла меня в детстве стороной, хотя я до дыр зачитывал его "Занимательную физику". В этой книге про математику Яков Перельман собрал большое количество приключенческих и фантастических рассказов, в которых скрыты математические загадки. А дальше в примечаниях после каждого произведения Яков расшифровывает математическую суть этой истории. Если вы читали Герберта Уэллса, Жюля Верна, Владимира Бенедиктова, то возможно уже сталкивались с этими произведениями, но скорее всего не могли оценить правдоподобность идей авторов. Ниже представлены все части этого сборника в формате "Название оригинального произведения. Название комментариев от Перельмана. Мои комментарии о чем все это" 1. На мыльном пузыре - рассказ Курда Лассвица. Относительность пространства и времени. Напоминает фильм "Дорогая, я уменьшил детей" 2. Машина времени - извлечение из повести Герберта Уэллса. Время как четвертое измерение. Просто про пространство и время. 3. На комете - из романа Жюля Верна. Примечания. Про силу притяжения и как подручными средствами определить вес и плотность кометы. 4. Предшественник Нансена - рассказ В. Ольдена. Живой планетарий. Про движение планет и как это можно моделировать:) 5. Универсальная библиотека - рассказ К. Лассвица. Литературная машина. Про комбинаторику и вероятности. Примерно то же самое, что толпа обезьян, которая стуча по клавиатуре случайно напишет "Войну и мир". Интересно смотреть сейчас на успехи LLMs, которые успешно генерируют связный текст:) 6. Пирамида Хеопса и ее тайны - рассказ Я. Перельман. Действия над приближенными числами. Развенчивание подходов желтой прессы на примере желтых заголовков о Пирамиде Хеопса:) 7. История одной игры - Вильг и Аренса. Примечания. Про игру "пятнашки" и как она появилась и почему привела изначально к буму 8. Странная задача на премию -Проф. Г. Симона. Диофант Александрийский. Про решение целочисленных уравнений 9. Числовые анекдоты - Барри Пен. Просто забавный набор задач, что можно порешать и проверить себя 10. Хитрое разрешение мудреной задачи - В.Г. Бенедиктов. Увеселительная арифметика Бенедиктова. Интересный сборник Бенедиктова и как пример задачка про продажу куриных яиц 11. Вверх дном - из романа Жюля Верна. Возможно ли переместить полюса Земли. Про вращение Земли вокруг своей оси и ее полюса 12. Самокатная подземная железная дорога - А. Родных. Сказочная дорога. Аля прообраз Hyperloop, что недавно закрылся, только еще более феерический:) Напоследок приведу цитату самого Якова Перельмана насчет этого сборника

В поисках средств для оживления в широких кругах интереса к математике, мне пришла мысль собрать ряд произведений, трактующих математические темы в беллетрической или полубеллетрической форме, и предложить их читателю с соответствующими комментариями. Число таких произведений, конечно, весьма ограничено. Этим объясняются скромные размеры настоящего сборника. Однако, затрагиваемые в нем математические темы все же довольно разнообразны: относительность пространства и времени, четырехмерный мир, расчеты из области небесной механики, вопросы математической географии, комбинаторика и исполинские числа, приложение математического анализа к играм, неопределенный анализ, уравнения. Можно надеяться, что этот небольшой сборник натолкнет иных читателей на более серьезные размышления и побудит к систематическому ознакомлению с тем или иным отделом математики. Настоящий сборник является первым известным мне опытом подобного рода.

#Math #PopularScience #Physics

How Data & Software Eng. Teams Collaborate to Ensure Smooth Data Integrations • Sam Bail • GOTO 2023 Интересное выступление Sam Bail про коллаборацию команд, что отвечают за разработку софта и за аналитические данные:) Слайды этого выступления доступны здесь. Сетап проблемы выглядит так

Product manager: We’re launching this awesome new feature next month! And we need analytics from day 1! Let’s GOOO! Data team: HOLD ON! Lemme talk to the software engineering team first and see what their data architecture looks like…

А дальше доклад посвящен следующим темам и выстроен в виде важных вопросов, которые обычно задает Sam в очередном проекте 1. Logistics - нужны доки, нужны встречи и понятная зона ответственности, понятные коммуникации, ответы на вопросы: что мы планируем измерять и когда (уже в первый день, неделю, месяц, ...). Как сделать так, что команда разработки была в синке с аналитикой. 2. Infrastructure - где хостятся данные, какой там тип хранилища, могут наши ETL инструменты с этим справиться, нужен ли SSH туннель. Есть ли prod и dev инстансы, мы используем реплики для получения данных? Нужен ли нам доступ на запись? Что мы делаем с credentials (личные они или общие, как мы их шарим). Когда удастся получить доступ к данным? На dev или prod? 3. Data model - как выглядит схема данных, есть ли документация, кто поддерживает изменения в схеме и кто и как их коммуницирует? Как будет выглядеть data constraints enforcing (foreign key relationship, NULL values, default values, JSON schemas)? Как обрабатываются таймзоны в датах, валюты? Действительно ли мы сохраняем все, что хотим измерять? 4. Application and data flow - как и когда записи создаются и поля заполняются значениями? Какие действия вызывают модификации значений? Как события модификаций данных логируются (поле updated_at или отдельная таблица с событиями логирования)? Как будут обработаны удаления (hard или soft удаления)? Архивируются ли "старые" данные? Нужна ли миграция данных из старого приложения? Будут ли реалистичные тестовые данные, на которых можно будет разрабатывать? Будут ли тестовые данные в production среде? 5. Data contracts - как будут документированы договоренности из пунктов 1-4? И как мы будем обеспечивать их соблюдение в будущем не требуя слишком большого человеческого участия? Что из этого можно вынести в CI/CD и проверять на стороне производителе данных (а не как обычно на стороне потребителя)? Как нужно будет коммуницировать об изменениях и кого надо будет информировать об этом? Что делать, если что-то сломается? Как надо будет репортить о проблемах, а также какое SLA будет на фиксы? Автор обобщает весь доклад тремя пунктами

- Integrating data from a new source into your data warehouse isn’t just “plug n play” - There are an infinite number of questions to consider. You will probably miss something. - The key is connection and context between teams.

А дальше, если все сделать правильно, то проблема из самого начала превращается в

Product manager: Look at this awesome new feature! And the dashboard to track all these cool metrics! Data team: Well it’s not everything you asked and it was a bit bumpy getting there, but it works! Go team!

#Data #Software #SoftwareDevelopment #Engineering #Management #Leadership #Databases

Геймдзайн (Designing games. A guide to engineering experiences) - Part IV Этот пост продолжает обзор книги, по которой уже было два поста: 1, 2 и 3. И тут мы продолжим говорить про вторую часть книги "Искусство создания игры" Глава 6. Баланс Автор начинает с определения

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

Баланс является инструментом, который используют для разных целей, где выделяются две: честность и глубина - игра считается честно, если вначале ни у одного из игроков нет преимущества - для того, чтобы игра была глубокой, она должна генерировать решения, которые были бы настолько сбалансированы, что даже эксперту сложно было бы принять решения Обычно игроки используют определенные стратегии - конкретные наборы действий для достижения целей. И если нет вырожденной стратегии (очевидно лучшей для данной ситуации), то игра является глубокой. Интересно, что баланс зависит от навыка игрока, так как разный уровень навыков дает доступ к разным стратегиям. Иногда ради баланса геймдизайнер решает поменять одну из механик, из которых состоит игра. Но изменения в механиках меняют все стратегии, в которые она встроена, а не только те, что мы планировали изменить. Поэтому поиск баланса достаточно сложен. Прямо как при принятии архитектурных решений:) Глава 7. Многопользовательская игра Эту главу автор начинает с рассмотрения теории игр, которой посвящены отдельные книги "Теория игр", "Теория игр в комиксах". Тут идет речь про равновесие Нэша, смешанные стратегии, yomi (чтение мыслей противника и попытка его убедить, что вы сделаете что-то одно, а вы на самом деле сделаете что-то другое). Дальше идет речь про то, что в многопользовательских играх часто у игроков могут быть разные цели, что приводит к тому, что одни игроки нарушают опыт других игроков. Глава 8. Мотивация и удовлетворение Эта глава начинается к отсылке к дофаминовому удовольствию и предвкушению награды, которое работает лучше, чем собственно получение награды. Дальше автор рассказывает про режим подкрепления

Режим подкрепления - это система правил, которая определяет, когда выдается награда

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

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

Глава 9. Интерфейс Автор начинает с того, что у нас 2 цели - донести информацию о том, что проихсодит в игре - здесь мы должны разработать системы, которые структурируют и упорядочивают информацию - обеспечить возможность управления - здесь мы должны разработать сложную комбинацию ограничений, соглашений и вспомогательных систем Для этого часто используются метафоры, которые придают новой информации знакомые черты, чтобы ее можно было легче понять. Больше того, игра должна задать словарь метафор, который указывает какие элменты моделируют механику, и соответствовать этому словарю. Для того, чтобы информация воспринималась лучше используется визуальная иерархия, в которой важные элементы становятся более заметными, чем неважные. Глава 10. Рынок Эта глава посвящена тому, как игры чувствуют себя на рынке. Про эффект Матфея, дилемму новатора, сегментацию рынка, кривую ценности. В общем, здесь мы заходим на территорию маркетинга и планирования продаж:) P.S. На этом обзор это книги заканчивается, так часть книги про "Процессы" очень хорошо пересекается с обычными процессами разработки, о которых я и так часто рассказываю. #Design #GameDesign #SystemDesign #SystemThinking #Management #SelfDevelopment

Practical (a.k.a. Actually Useful) Architecture • Stefan Tilkov • GOTO 2023 Это выступление является последним для Стефана Тилькова на goto конференциях, где он начал выступать еще в 2012 году. Я помню как в 2019 году лично посетил его выступление про архитектуру в Берлине на Software Architecture Conference. Тогда мне показалось, что он очень бодрый спикер и консультант, который еще много лет будет выступать, напишет много статей и книжек, но в середине 2023 года его не стало. Goto сделали страницу в память о его наследии, ну а дальше я расскажу про его последнее выступление, в котором он дал 10 советов для прагматичной архитектурной работы 1. Choose your perspective(s) consciously - Стефан предлагает выбирать перспективу осмысленно. Он показывает разные перспективы: доменную архитектуру (с основными сервисами по доменам и стыками с внешними системами), макро-архитектуру (с основными доменами и их взаимодействиями внутри), микроархитектуру (какие технологии используются для этих сервисов). 2. Explicitly architect your team setup - здесь Стефан фактически отсылает нас к обратному маневру Конвея и дальше упоминает книгу Team topologies 3. Match your organizational setup to project size, etc. - про эту тему я рассказывал отдельный доклад на YaTalks, правда, у Стефана фокус на том, как выглядит архитектурная работа в каждом из случаев 4. Don't be afraid to decide things centrally - для эффективной работы автономных команд требуется принять ряд централизованных решений (что довольно иронично). Стефан рассказывает про то, какие это решения 5. Pick your battles wisely - тут речь про change management и про выбор тех изменений, которые требуются прямо сейчас. Важно не запускать слишком много изменений 6. Enforce the least viable amount of rules, rigidly - здесь автор показывает важность того, чтобы правил не было слишком много, иначе мы можем потерять гибкость и слишком бюрократизироваться 7. Balance prescriptive vs. descriptive architecture - здесь автор говорит хорощие вещи, что документирование архитектурных решений - это не то же самое, что их принятие:) Часто это документирование является первым шагом, но не конечной целью. Также круто сказано о том, что хорошее архитектурное решение не может нравиться всем, а если вам удалось принять решение, удовлетворяющее всех, то скорее всего это плохое решение (на эту тему можно посмотреть клип Би2 - Компромисс) 8. Don't aim for perfection - iterate - про итеративный подход к улучшениям 9. Architect for delivery flow as much as for runtime quality - здесь Стефан рассказывает о том, что при принятии архитектурных решений надо смотреть не только на функциональные и нефункциональные требования, но и на то, как это влияет на процессы разработки. Про это я тоже рассказывал в докладе "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса" 10. Be boring & do more with less - здесь Стефан рассказывает про технологическую стабильность, а также про уровень безумия компаний, который зависит от количества денег, что они готовы тратить на консультации:) В итоге, советы от Стефана звучат так

Prefer simple, straightforward solutions to overly clever and complicated, cool approaches

и

Focus innovation on the domain, not technology

Ну и финальный аккорд выступления посвящен тому, что архитектура до сих пор остается самой интересной областью в IT потому, что она имеет значение - если сделать ее плохо, то все развалится, а вот если сделать правильно, то успех еще не гарантирован:) P.S. RIP Стефан. Ты был крутым архитектором, консультантом и спикером. #Architecture #Software #Engineering

Картинка к посту про PACELC

Consistency Tradeoffs in Modern Distributed Database System Design (или whitepapere про PACELC) Продолжая серию постов про консистентность (CAP теорема, ее доказательство), я расскажу про whitepaper 2012 года от Daniel J. Abadi с расширением CAP теоремы до PACELC (читается как [pass-elk]). Суть этой статьи звучит так

The CAP theorem’s impact on modern distributed database system design is more limited than is often perceived. Another tradeoff—between consistency and latency—has had a more direct influence on several well-known DDBSs. A proposed new formulation,

PACELC

, unifies this tradeoff with CAP.

Фокус CAP теоремы на поведении распределенной системы во время разделения сети. Но большую часть времени система работает в состоянии, когда с сетью все в порядке. Поэтому интересно оценить а какоой tradeoff в этом случае. И это оказывается треугольник "consistency, availability, and latency", который автор упрощает до пары consistency и latency, так как

Availability and latency are arguably the same thing: an unavailable system essentially provides extremely high latency

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

1. Data updates sent to all replicas at the same time 2. Data updates sent to an agreed-upon location first 3. Data updates sent to an arbitrary location first

1) Здесь отправка обновлений происходит на все ноды. Есть два варианта - a. Pre-processing слоя нет - тут будет нарушена консистентность (линеаризуемость) из определения Gilbert and Lynch (из уже упоминавшегося доказательства CAP теоремы). - b. Такой слой есть - время уйдет на координацию узлов, если их много, а если узел в препроцессинге один, то мы будем тратить время на пересылку запросов к нему, что в гео-распределенной системе может быть затратно. 2) Здесь мы имеем мастер-ноду (для разных элементов данных у нас могут быть разные мастера). И в эту мастер-ноду летят все запросы на обновление, которые она выполняет и эффективно определяет порядок операций, который един для всех реплик. Здесь есть 3 возможности для репликации 1. Синхронная репликация - при апдейте мы ждем пока все реплики обновятся. Это консистентно, но увеличивает latency 2. Асинхронная репликация - тут мы обычно прихраниваем update в persistent storage, но успешной репликации не ждем и подтверждаем операцию. Дальше интересно посмотреть как мы читаем данные в этом случае - a. Если мы читаем с мастера, то мы не имеем проблем с consistency, но latency может быть большим, так как мастер далеко. Плюс при высокой нагрузке на мастер мы тоже получим проблемы с latency. - b. Если мы читаем с реплик, то потенциально может прочитать устаревшие данные 3. Комбинация синхронное и асинхронной - по-факту, это что-то из серии tunable consistency в Cassandra, где можно указывать кворум на запись и на чтение 3) Тут похоже на второй пункт, но мы отправляем обновления не в определенный мастер для конкретного элемента, а на произвольную ноду. Проблемы с consistency и latency здесь похожи на те, что во втором пункте. Дальше автор разбирает как эти tradeoffs работают в популярных на то время базах данных: Dynamo, Cassandra, PNUTS, Riak, ... и делается вывод, что дизайн решения в базах зачастую больше фокусируются на consistency/latency в условиях нормальной работы, а не на consistency/availability в условиях наступления partition. И дальше автор предлагает переписать CAP в PACELC с примерно такой формулировкой

If there is a partition (P), how does the system trade off availability and consistency (A and C); else (E), when the system is running normally in the absence of partitions, how does the system trade off latency (L) and consistency (C)?

#Software #Architecture #DistributedSystems #SystemDesign

Вакансия Principal Engineer ко мне в команду У меня есть отличная вакансия напрямую ко мне в команду в качестве Principal Engineer, который будет моим замом по инженерным активностям на уровне моего подразделения в 1к человек. Сразу скажу, что подразделение разделено на 4 управления и 1 отдел, в которых эти вопросы тоже отдельно прорабатываются, но мне нужен мой зам, чтобы курировать развитие важных тем и отслеживать движение по ним. Теперь подробнее по направлениям 1) Observability & reliability На самом деле в моей концепции мира сами технические директора управлений отвечают за observability и надежность сервисов своих команд, но нужна централизация, так как - у нас есть стандартные подходы к логам/метрикам/алертам - это наша observability платформа Sage - у нас есть стандартные подходы к классификации сервисов по критичности и измерению их SLA - это наша платформа SLAser, в которой заводятся SLI/SLO/SLA и которая умеет расчитывать их соблюдения на основе данных в Prometheus - у нас есть подход к работе с инцидентами и инструменты для автоматического их заведения и линковки между собой Задача моего зама в том, чтобы знать про все эти инструменты, понимать как они связаны между собой, как ими пользоваться, а также помогать командам в моей зоне ответственности повысить свой уровень зрелости в области observability и reliability путем использования стандартных инструментов. 2) Capacity management У нас есть стандартный процесс для управления мощностями, который требует активного планирования того, сколько потребуется ресурсов для наших сервисов в будущем. Так как у нас гибридное облако, то надо уметь планировать и inhouse мощности и мощности в публичных облаках, круто, что наша IDP (internal developer platform) умеет работать и inhouse и в public cloud, спасибо коллегам из Coretech. Интересно, что capacity planning - это зона технических руководителей управлений в моем подразделении, но мне нужен централизованный guidance от моего зама за тем, что все идет по плану (который мы обсуждаем с руководителями) + если есть проблемы, то их может разрулить мой зам 3) Migrations and EOL У нас есть централизованный процесс миграций в нашем ИТ, который зачастую создает много работы для руководителей. Если миграция инициирована извне подразделения, то требуется понять как она аффектит нас и как уложится в целевые сроки и скоординировать все команды внутри. Для этого требуется зачастую крутой инженер, который понимает суть миграции и то, что она задевает внутри. Собственно, мой зам будет отвечать за эту координацию 4) Scalability Компания активно растет последние годы, у нас в процессе много проектов по улучшению возможностей масштабирования наших систем под новые нагрузки. У меня есть зам по архитектуре, Антон Костерин, который отвечает за этот проект как в моем подразделении, так и на уровне все компании. Но и для моего зама по инженерным активностям найдется в этом проекте работа. На самом деле есть еще большое количество интересных активностей, с которыми такой кандидат сможет мне помочь, но лучше двинуться дальше и ответить на вопрос "А что случилось с предшественником?", который у меня возникает, когда ищут кого-то на интересную позицию. Ответ в том, что мой коллега на этой позиции работал со мной 6 лет и работал хорошо, а потом решил переехать в солнечные края. Игорь - большой молодец и мне будет его нехватать, но теперь я ищу "нового Игоря":) Если вам интересна вакансия, то дальше нам надо будет познакомиться, а дальше будет прохождение технических интервью, о многих из которых я уже рассказывал - Общие инженерные вопросы - вопросы в форме блица про сети, работу компьютера, операционные системы, базы данных - Алгоритмы и структуры данных - решение алгоритмических задач с написанием кода - Troubleshooting - работа над инцидентом в типовой системе (вот пост про это интервью) - System Design - проектирование простенького сервиса (вот пост про это интервью) Если результаты будут классными, то о ЗП мы договоримся. Если вакансия заинтересовала, то пишите мне в личку #Vacancy #SRE #Career

Вакансия Principal Engineer ко мне в команду У меня есть отличная вакансия напрямую ко мне в команду в качестве Principal Engineer, который будет моим замом по инженерным активностям на уровне моего подразделения в 1к человек. Сразу скажу, что подразделение разделено на 4 управления и 1 отдел, в которых эти вопросы тоже отдельно прорабатываются, но мне нужен мой зам, чтобы курировать развитие важных тем и отслеживать движение в целевом направлении. Теперь подробнее про зоны ответственности 1) Observability & reliability На самом деле в моей концепции мира сами технические директора управлений отвечают за observability и надежность сервисов своих команд, но нужна централизация, так как - у нас есть стандартные подходы к логам/метрикам/алертам - это наша observability платформа Sage - у нас есть стандартные подходы к классификации сервисов по критичности и измерению их SLA - это наша платформа SLAser, в которой заводятся SLI/SLO/SLA и которая умеет расчитывать их соблюдения на основе данных в Prometheus - у нас есть подход к работе с инцидентами и инструменты для автоматического их заведения и линковки между собой Задача моего зама в том, чтобы знать про все эти инструменты, понимать как они связаны между собой, как ими пользоваться, а также помогать командам в моей зоне ответственности повысить свой уровень зрелости в области observability и reliability путем использования стандартных инструментов. 2) Capacity management У нас есть стандартный процесс для управления мощностями, который требует активного планирования того, сколько потребуется ресурсов для наших сервисов в будущем. Так как у нас гибридное облако, то надо уметь планировать в разрезе inhouse мощностей, так и то, что мы можем эффективно выполнять в нашей IDP (internal developer platform), развернутой в публичных облаках. Опять же это планирование напрямую приземляется в технических руководителей управлений в моем подразделении, но мне нужен централизованный guidance от моего зама за тем, что все идет по плану (который мы обычно отдельно планируем с руководителями) + если есть проблемы, то их может разрулить мой зам 3) Migrations and EOL (end of life) У нас есть централизованный процесс миграций в нашем ИТ, который зачастую создает много работы для руководителей. Если миграция инициирована не тобой, то требуется понять как она тебя аффектит и как уложится в целевые сроки и скоординировать все команды. Для этого требуется зачастую крутой инженер, который понимает суть миграции и то, как она задевает команды в моем подразделении. Собственно, мой зам сможет это координировать. 4) Scalability Наша компания активно растет последние годы и сейчас у нас в процессе много проектов по тому, чтобы улучшить возможности масштабирования наших систем под новые нагрузки. У меня есть зам по архитектуре, Антон Костерин, который отвечает за этот проект как в моем подразделении, так и на уровне все компании. Но и для моего зама по инженерным активностям найдется в этом проекте работа. На самом деле есть еще большое количество интересных активностей, с которыми такой кандидат сможет мне помочь, но лучше двинуться дальше. Когда я слышу, что ищут кого-то на интересную позицию, то у меня возникает вопрос "А что случилось с предшественником?". Тут бы у меня этот вопрос тоже возник, поэтому превентивно отвечаю - предшественник работал со мной 6 лет и прошел очень многое, но потом далекие страны поманили его и он уехал греться на солнышке. А вообще, Игорь - большой молодец и мне будет его нехватать. Теперь я ищу нового Игоря:) Найм будет состоят

Patterns & Anti-Patterns for Effective Feature Flagging • Edith Harbaugh • YOW! 2019 Интересное выступление от Edith Harbaugh, co-founder и CEO платформы для фича флагов LaunchDarkly. В самом начале Edith вспоминает про темные времена, когда она работала в компании, где релизы были раз в полтора года ... и это было быстро, потому что у конкурента они были каждые три года:) Дальше начинается рассказ про паттерны и анти-паттерны их использования. Но до этого хотелось бы обсудить, что сама идея флагов кажется очень простой: нам надо уметь закрывать часть функциональности в коде флагом, который можно удаленно включить/выключить. Это помогает с несколькими вещами - С feature flags хорошо работает TBD (trunk based development), а без них почти нет - Release management становится проще (особенно в мобилках) - Можно тестировать функциональность на части аудитории, например сотрудниках Но тут мы оказываемся на стыке двух миров - работы с кодом и релизами и экспериментами (a/b тесты, сегментация пользователей, персонализация, ...) Ну а дальше давайте я расскажу про какие вещи говорила Edith Паттеры и хорошие способы применения флагов - Feature kill switches - паттерны для отключения фичей на случай проблем или на случай спайка нагрузки - Мердж бранчей без конфликтов - условно feature flag - это enabler для TBD, про который я уже говорил - Controlled rollout - условно раскатка порции трафика на новую фичу - Early access betas для самых лояльных/лучших пользователей - Для блокировки фичей для некоторых пользователей (например, тех, кому нужны только отстоявшиеся фичи) - Для тестирования в проде и сокращения важности staging контура (Edith предлагает его вообще убить) - Для подписок, где часть фичей доступна только по подписке (я думаю, что это странный кейс конечно) - Для отключения старых фичей Антипаттерны и косяки - Кривое наименование флагов - это просто путает и мешает использовать флаги - Overused flags - одни и те же флаги, которые используются разными командами по разному, условно одни думают, что этот флаг лечит от кашля, а другие, что от запора:) - Конфликтующие флаги - учитывая комбинаторику, конфликтующие очень легко получить, особенно если не подумать заранее о том, что именно мы закрываем флагами - Использование флагов для критической функциональности, которая уже давно не должна отключаться - пример с CMS системой, где можно флагом было отключить загрузку файлов, что эффективно отключало всю систему:) Смысл в том, что такой флаг уже давно стал бесмыссленным:) - Флаги, что остаются в коде и никогда не выпиливаются - это просто ухудшает кодовую базу Напоследок приводятся рекомендации - Flag carefully - Lock down access - Remove flags P.S. У нас в компании были разные системы для управления флагами и экспериментами. Сейчас мы идем в сторону общего решения, где - Базовые сценарии управления флагами будут прямо внутри нашей IDP (internal developer platform) - эта часть про код + release management - Расширенные сценарии управления будут внутри a/b платформы - это часть про использование флагов для экспериментов, персонализаций, бет и так далее Если вам нравятся такие задачи и у вас есть опыт промышленной разработки, то вы можете написать мне:) #Software #Devops #SRE #Reliability #Architecture #Engineering #Processes

Материалы к Code of Architecture по white paper «Google's Hybrid Approach to Research» В этот понедельник мы провели новогодний стрим по архитектуре. В рамках встречи мы поговорили про то, как устроено RnD (Research and Development) в Google. Гостями эфира были наши коллеги - Игорь Маслов, руководитель управления базовых технологий и обработки данных Тинькофф - Станислав Моисеев, директор инженерных исследований в Тинькофф Материалы, которые мы упоминали в рамках выпуска представлены ниже - Мы обсуждали сам white paper, доступный здесь - Для визуализации взаимодействий мы использовали слайд с топологией команд, который был из моей статьи с обзором этого white paper - Мы проводили параллели с Team Topologies, про которую я отдельно рассказывал в трех частях: 1, 2, 3 - Мы обсудили и обновленную философию RnD от Google с сайта research.google. Интересно, что она чуток поменялась со временем написания whitepapaer про гибридный подход - Мы пробедали быстро по крупным технологическим whitepaper от Google, про которые я отдельно рассказывал в статье про RnD в крупных компаниях (Google, Amazon, Yandex, Tinkoff) - Поговорили про наши технологические продукты, которые были созданы для решения продуктовых задач и доступны на нашем сайте, например, про observability платформу Sage или наш Tinkoff VoiceKit для обработки голоса Ну и напоследок мы рассказали о том, что в нашем инженерном RnD подразделении есть куча интересных направлений, а также что туда идет набор исследователей. Так что если вы всегда мечтали делать сложные инженерные задачи на переднем краю технологий, то вы можете написать мне, а я дальше уже познакомлю вас со Стасом или Игорем. #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #RnD #CoA

День влюбленных в математику В следующем году Тинькофф, ИТМО и Тинькофф Образование организует конкурс для студентов, которые любят математику. Победителям достанутся денежные призы и классный мерч. Всего будут три этапа: - Отборочный онлайн-тур - Разнобой, 12-18 февраля - Офлайн-полуфинал в регионах России - Интеллектуальная викторина, 2 марта - Финал в Москве - Математическая регата, 23 марта P.S. Мне с самого детства нравилась математика, поэтому я и поступил в МФТИ на факултет управления и прикладной математики. Ученого из меня не получилось, но я до сих пор люблю читать научно-популярную литературу по математике. Например, я раньше уже писал про следующие интересные книги, связанные с математикой - Модельное мышление (The Model Thinker) - Принцип ставок (Thinking in Bets) - Заходит экономист в публичный дом (An economist walks into a brothel) - Теория игр (A Game Theorist's Guide to Success in Business and Life) - Игра случая (Fluke. The Math and Myth of Coincidence) - Теория игр в комиксах - Величайшие математические задачи (The Great Mathematical Problems) - Понимать, но не предвидеть. Предвидеть, но не понимать (Comprendre sans prevoir, prevoir sans comprendre) - Математический беспредел. От элементарной математике к возвышенным абстракциям (Beyond Infinity: An expedition to the outer limits of the mathematical universe) - Статистика. Краткий курс в комиксах (The cartoon guide to statistics) - Статистика в комиксах (Inroducing Statistics. A Graphic Guide) - What Is ChatGPT Doing ... and Why Does It Work? - Романтика искусственного интелекта - Занимательная статистика. Манга (The Manga Guide to Statistics) #Math #PopularScience #Education #SelfDevelopment

Пара записей с поездки в Питер на ICPC и ВКОШП Я уже писал раньше о том, как ездил в Питер на эти мероприятия, чтобы поучаствовать в них, так как Тинькофф спонсирует эти чемпионаты по программированию. Мне очень понравилась атмосфера контеста и его участники, поэтому я рад, что съездил туда + я поучаствовал не только в церемониальных частях мероприятий, но и побывал на прямых трансляциях, где обсудил с Лидией Перовской разные моменты 1) Трансляция ВКОШП - эта трансляция командных соревнований школьников и здесь мы поговорили на следующие темы - про формат соревнований и почему они настолько интересны - почему командные соревнования по программированию неплохо моделируют командную работу инженеров в реальной разработке - про роль тимлида в команде - про то, что можно успеть за 26 минут - про выступление на YaTalks про структуру команд - про то, как я почти не пишу код в последнее время, но стабильно читаю его - интересно про инциденты и отсылку к публичному интервью по troubleshooting на Devoops - про a/b платформу и продуктовую аналитику - про найм олимпиадников в команды (тут я рассказал забавную историю из опыта) 2) Трансляции ICPC - это трансляция командных соревнований студентов и здесь мы поговорили про следующие темы - про мою зону ответственности в Тинькофф - про мое обучение в МФТИ - про сложность подготовки к соревнованиям - про стажировки в компаниях, где выстроены процессы разработки (лучше в Тинькофф) - хорошие советы о том, как правильно работать в команде по спортивному программированию:) - про канбан-метод и визуализацию работы - про сложные процессы в больших компаниях и синхронизацию знаний - про важность ретроспектив - про современные шахматы, обучение им и как это прокачивает мышления #Software #SoftwareDevelopment #Conference #Engineering

Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services Раньше я уже рассказывал про знаменитую CAP теорему за авторством Eric Brewer. А сегодня я хотел поговорить про whitepaper 2002 года от Seth Gilbert и Nancy Lynch, в котором утверждение из гипотезы стало теоремой. Авторы этого whitepaper так формулируют гипотезу, которую планируют доказать

It is impossible for a web service to provide the following three guarantees: consistency, availability, partition-tolerance

Все эти свойства желательны в реальных системах. Но для того, чтобы доказать это утверждение, требуется для начала формализовать все три свойства 1) Начать стоит с consistency, где авторы идут в сторону atomic data objects или линеаризуемой консистентности (linearizable consistency)

Under this consistency guarantee, there must exist a total order on all operations such that each operation looks as if it were completed at a single instant. This is equivalent to requiring requests of the distributed shared memory to act as if they were executing on a single node, responding to operations one at a time.

Такие гарантии косистентности пользователям проще воспринимать и для такой модели проще проектировать клиентское приложение, которое будет взаимодействовать с такой распределенной системой. 2) Второй характеристикой является availability, где для непрерывной доступности каждый запрос, попавший на несбойную ноду системы должен получить свой ответ. Таким образом любой алгоритм для генерации ответа сервисов должен оканчиваться в конечном счете (eventually terminate). Интересно, что это слабое определение доступности, так как нет верхней границы на время ответа - это позволяет unbounded computation. Но если рассматривать это с позиции устойчивости к разделению, то это может рассматриваться как сильное определение доступности - даже если происходят сбои в сети, каждый запрос должен завершиться. 3) Для моделирования partition-tolerance авторы предлагают считать, что в сети может теряться произвольное количество сообщений, что отправляются от одной ноде к другой. В итоге, мы можем моделировать любой паттерн потерь

When a network is partitioned, all messages sent from nodes in one component of the partition to nodes in another component are lost. (And any pattern of message loss can be modeled as a temporary partition separating the communicating nodes at the exact instant the message is lost.)

Дальше авторы переходят к доказательствам 1) Начнем сначала с асинхронных систем

Theorem 1 It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties: • Availability • Atomic consistency in all fair executions (including those in which messages are lost).

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

Theorem 2 It is impossible in the partially synchronous network model to implement a read/write data object that guarantees the following properties: • Availability • Atomic consistency in all executions (even those in which messages are lost).

Доказательство похоже на предыдущее как две капли воды:) Оставшаяся часть white paper посвящена Delayed-t consistency в частично синхронных системах, про которую мы тут говорить не будем. #Software #Architecture #DistributedSystems #SystemDesign

Новогодний титул в Тинькофф Мои коллеги устроили новогодний утренник прямо в приложении Тинькофф. Все как в детстве: снежинки, зайчики, лисички и другие персонажи. Роль найдется для каждого – в зависимости от того, какие траты были в 2023 году. Этот титул доступен для просмотра в разделе мобильных историй. А мой титул в этом году "Добрый доктор". И вот как это получилось: - В середине года мою аусси по имени Люси порвала стая охотничьих собак прямо на собачей площадке - Я больше недели ездил по утрам в ветеринарную клинику, а иногда и по вечерам - Мы вылечили прокушенную грудь и надкусанную лапу Люси - Люси теперь бегает как ни в чем не бывало:) #Humor

Code of Architecture рзабор white paper «Google's Hybrid Approach to Research» Сегодня в 18:00 мы проведем новогодний стрим по архитектуре. В рамках встречи мы поговорим про то, как устроено RnD (Research and Development) в Google — какую цель исследований поставила для себя компания и почему; — к каким резльтатам она привела; — как устроен гибридный подход к исследованиям там; — как выглядят паттерны организации взаимодействия исследовательских и продуктовых инженерных команд; — почему и зачем компании инвестируют в Google. Гостями эфира станут наши коллеги - Игорь Маслов, руководитель управления базовых технологий и обработки данных Тинькофф - Станислав Моисеев, директор инженерных исследований в Тинькофф На тему стрима можно почитать материалы - PDF версия доступна здесь - Мой обзор этой статьи доступен здесь - Моя статья про RnD в крупных компаниях (Google, Amazon, Yandex, Tinkoff) #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #RnD #CoA

Как формировать структуру команд под запросы бизнеса на YaTalks 2023 Появилась запись моего выступления на YaTalks, где я рассказывал про основы и принципы дизайна команд, которые помогали мне на протяжении 7 лет работы в Тинькофф. Часть выступления уже доступна в виде расшфировок 1) пост про структуру команд 2) пост про проектный подход 3) пост про продуктовый подход 4) пост про масштабирование (пока на очереди) В общем, для тех, кто больше любит видео, теперь оно доступно для просмотра:) #Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

Щелкунчик и Мышиный король О приближении нового года можно следить по традиционным рождественнским представлениям и их частотности. Так получилось, что за последние 24 часа я дважды был на постановках Щелкунчика по повести-сказке Гофмана, но какие разные это были постановки 1) Вчера вечером это было иммерсивное шоу, которое разворачивалось на трех этажах особняка, которые отображали соответственно мир мышей, мир людей и мир игрушек. Механика этой постановки предполагала одновременное разворачивание событий на всех трех этажах и молчаливых зрителей, которые имели свободу воли и могли выбирать на каком им этаже быть, за каким персонажем следить и следить ли вообще за чем-то:) Я на такой постановке в первый раз и она мне показалась достаточно интересной. 2) Сегодня утром это была постановка для детей в домике Фанни Белл, где самые маленькие дети фактически сидят в первом ряду, который не отделен от сцены. В этой постановке участвовали только 3 актера, но они делали это очень хорошо - маленькие зрители вовлекались в представление, общались с актерами, подсказывали, что видели Мышиного Короля, а также участвовали в атаке на него, закидывая снежками. В общем, детям очень понравилось:) Так за одни сутки я дважды увидел постановку по мотивам Щелкунчика и смог сравнить как обыгрывается сюжет для аудитории разных возрастов:) #Theater #ForKids #ForParents