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

Ближайшие мероприятия Тинькофф Образования за пределами Москвы

Наша команда образования работает по всей територии России и практикует разные форматы: митапы, воркшопы, курсы. Ниже список
- 16.01 - 17:00 - Ижевск - мастер класс по проектированию и реализации распределенных приложений на Java
- до 29.01 - Рязань - отбор на проектную мастерскую Тинькофф в Рязани
- до 30.01 - Воронеж - junior митап для студентов, где будет обсуждение старта карьеры в аналитике, Scala и QA
- до 5.02 - Ижевск, Пермь, Уфа - бесплатный образовательный спецкурс для студентов
- 10.02 - 12:00 - Уфа - мастер класс по проектированию и реализации распределенных приложений на Java

Если бы я был студентом, то с удовольствием вписался в такую активность, но в мое время таких мероприятий особо не было:)

#SelfDevelopment #Education #Software #SoftwareDevelopment

Конструирование языков. От эсперанто до дотракийского

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

Лингвистическая наука обычно не считает искусственные языки достойным объектом исследования

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

Сама книга состоит из 6 глав, каждая из которых погружается в конкретный класс конлангов (от constructed languages)
1. Недостижимый идеал - эта глава посвящена обсуждению логических и философских языков. В таких языках основная цель создать логичный язык без изъянов и дальше посмотреть как это повлияет на мышление нативных спикеров на этом языке:) Здесь упоминаются языки логлан, ро, токипона, ифкуиль. Круто, что автор показывает разные языки и объясняет концепт - это позволяет сравнить концепции языков и их реализацию, а иногда увидеть и противопоставление - например, языка токипона с минимальными правилами и передачей базовой сути и языка ификуиль, где можно передать тончайшие смыслы, но сделать это достаточно сложно:)

2. Изобретение знаков - здесь идет речь про языки, что претендуют на логичность и выражение глубинных свойств мироустройства, но не при помощи букв, а при помощи картинок. Эта глава начинается с разбора типологии знаков, где выделены три типа в зависимости от того, как соотносится означающее и означаемое: иконы, индексы и символы.
- иконы - знаки, у которых означающее как-то похоже на означаемое (картинка собаки на заборе)
- знаки-индексы - означающее и означаемое связаны по смежности в пространстве, во времени или в цепи причин и следствий (лай собаки из-за забора)
- знаки-символы - означающее и означаемое связаны условной связью, которая определяется договоренностью (слово dog или собака)
Дальше автор разбирает язык дорожных знаков, трансцедентную алгебру, блиссимволику и паленео.

3. В поисках взаимопонимания - тут речь про международные, вспомогательные языки, навроде, достаточно известного эсперанто. Прикольно, что в этой главе идет речь про сложность языков и автор вспоминает сложность по Колмогорову и ближе к концу главы идет речь про избыточность информации в искусственных языках и естественных и как они отличаются. Если кратко, то в естветственных языках сущ...ет изб..ность ... инф..ции, кт...ая позв..ет вос..вать про..ски, а вот в искусственных языках авторы эту избыточность выкидывают. Это позволяет проще формировать сообщение, но получающий сообщение сложнее его интерпретирует особенно, если возникли помехи, например, из-за шума часть звуков собеседник не расслышал. А вообще в этой главе автор говорит про солресоль, волапюк, эксперанто (тут он рассказывает про агглютинативные языки и про флективные, а также про их отличие), latino sine flexione, междусловjански. Эта глава мне очень понравилась.

4. Языки естественные, да не совсем - здесь автор рассказывает как некоторые языки, что считаются естественными, были когда-то сконструированы. Например, он показывает как общий немецкий язык был сконструирован из разных немецких наречий и как этому поспособствовал Мартин Лютер с его переводом Библии, также упоминает похожая история с итальянским языком и Данте Алигьери и его "Божественной комедией". Другие истории посвящены нюнорску в Норвегии, а также ивриту у евреев.

5. Вымышленные миры - эта интересная часть посвящена искуственным языкам эльфов Толкиена (синдарин), клингонцев из Стартрека, дотракийцев из Игры престолов, На'ви из Аватара Джеймса Кэмерона, новояза из романа Джорджа Оруэлла 1984 и других

Продолжение в следующем посте.

#SelfDevelopment #Writing #PopularScience

Конструирование языков. От эсперанто до дотракийского - Part II

Продолжение первого поста про эту книгу

6. Лингвоконструирование в научной лингвистике - здесь разбирается сценарии применения лингвоконструирования в науке. Например, здесь идет реконструирование языков на основе уже существующих или мертвых языков, например, праязыка индоевропейцев, из которого получились большинство языков евпропейцев и славян. А другой пример использования сконструированных языков - это проведениее лингвистических экспериментов и определение закономерностей в развитии языков. Обычно это долгий процесс, который ученые хотят ускорить. В итоге, сконструированные языки могут выступать в роли мушек-дрозофилов для биологов - это могут быть достаточно простые языки, развитие которых легко проследить и вывести определенные закономерности. В конце, автор уделяет немного времени семантике и показывает как в естественных языках толковые словари содержат циклы в определении слов, например, в словаре Ожегова и Шведовой циклятся определения трех слов: "место" - "пространство" - "промежуток". Для этого автор вспоминает про семантические примитивы Анны Вежбицкой, которых порядка 55. Эти примитивы можно использовать для определения слов без циклов, но они получаются похожими на то, что было в языке токипона, который обсуждался в первой главе.

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

P.S.
Вот еще крутое интервью Александром Пиперски, автором книги, про Задорнова, лингвистику и конструирование языков.

#SelfDevelopment #Writing #PopularScience

Внутренняя платформа для разработки и разработчиков: за что платит бизнес?

Интересный доклад от Александра Чубинского на тему создания и развития IDP (internal developer platform) на примере компании Yandex. Александр рассказывает историю развития платформы в Yandex и очерчивает этапы, через которые проходило IDP: феодализм, империя, децентрализация, капитализм. Первые три этапа интересны с точки зрения истории, а вот этап капитализма актуален для всех. И на этом этапе Александр говори про следующее
- CTO актуален вопрос стоимости платформы (TCO - total cost of ownership), а до этого на предыдущих этапах уже обсуждалась надежность и качество предоставляемых сервисов
- CFO волнует P&L (profit and loss) продукта - и стоимость сервисов платформы может быть значимой частью этого отчета для конкретного проддукта
- Отсюда появляется система тарификации (что именно и почем) - ответ в том, что деньги надо брать за потребляемые пользователям сервисы
- Дальше надо посчитать юнит-экономику для платформы - платформа не для заработка на внутренних пользователях, а скорее должна быть самоокупаема
- Потом появляется желание уметь делать zoom-in/zoom-out для анализа потребления ресурсов платформы - в разрезе сервисов/команд/продуктов/...
- Но появляется вопрос, а какие драйверы роста у платформ - их два: потребление ресурсов, рост команды. Потребление ресурсов завязано на юнит-экономику и бухгалтерию потребления, а вот команда платформы растет в некоторой пропорции от потребителей (условно некоторый % от продуктовых команд - это связано с тем, что заказчиков новых фичей становится больше и для того, чтобы удовлетворять этот спрос требуется больше людей)
- Дальше Александр рассказывает про то, что платформа становится внутренним бизнес-юнитом и дальше может идти вовне и часть своих сервисов продавать наружу

#PlatformEngineering #Software #SoftwareDevelopment #Architecture #Economics #SRE #Devops #Engineering

Про относительность определения лучшего

Как-то раньше я уже писал про книгу "Ученые шутят" (посты 1 и 2), которая мне очень понравилась. И я решил купить еще юмористических книг из этой серии и приобрел книгу "Шахматисты шутят... и выигрывают". В ней много шуток чемпионов мира, претендентов, гроссмейстеров, а также знаменитостей из других областей, которые любили шахматы. Но в этой книге нет забавной истории, которая в свое время мне понравилась. Она посвящена второму чемпиону мира, Эмануилу Ласкеру, что владел короной 27 лет на рубеже 19 и 20 века. И вот эта история

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

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

P.S.
А вообще книга "Шахматисты шутят... и выигрывают" мне понравилась, правда около половины этих забавных историй я читал еще 25-30 лет назад:)

#PopularScience #Humor #Chess