Книжный куб

Логические ошибки. Как они мешают правильно мыслить (Рубрика #Thinking) Прочитал на выходных репринт учебника 1958 года Авенира Ивановича Уёмова, в котором базово рассказывается про логику и логические ошибки. Автор очень просто и понятно раскрывает тему, одновременно он не льет воду и почти укладывается в 100 страниц. В современной литературе редко когда встретишь такой подход - сейчас принято одну и ту же мысль повторять по кругу, чтобы даже самый невнимательный читатель на пятом повторе понял, о чем речь. Правда, в этом учебнике есть своя особенность - он был написан во времена компартии, а значит В.И. Ленин и его размышления встречаются нам по поводу и без повода, подвязанные белыми нитками к общей логике повествования. В общем, книга состоит из следующих частей 1) В чем сущность логических ошибок? - автор показывает на пример чем отличаются фактические и логические ошибки, а дальше останавливается на логических 2) В чем вред логических ошибок? - логические ошибки могут привести к неверным выводам, а те в свою очередь к реальным последствиям 3) Каковы причины возникновения логических ошибок - здесь автор разделяет правильность мышления, которая помогает доказывать свою позицию, а также убедительность речи, которая позволяет убедить оппонента, даже если логически размышления некорректны. Часто причинами логических ошибок является незнаение людьми того, а что такое правильность мышления (логическая корректность размышлений) и неправильность 4) Значение практики и различных наук для устранения логических ошибок - автор отмечает, что для простых размышлений часто хватает повседневной жизненной практики (здравого смысла), но вот для ситуаций посложнее полезно быть знакомым с разными науками, например, математикой, где очень часто встречаются аксиомы, теоремы и их доказательства, которые содержат в себе логически корректные размышления. 5) Как логика помогает бороться с логическими ошибками - основная часть книги, в которой для борьбы с логическими ошибками нам на помощь приходит логика! 5.1) Логические формы мыслей - автор рассказывает о том, что такое логическая форма, понятия, суждения, умозаключения, доказательства 5.2) Как избежать логических ошибок в мыслях различной формы - эта часть занимает больше половины книги и содержит теоретические объяснения и практические примеры с разбором ошибок и их причин. В общем, эта книга определенно интересна и полезна для изучения. #Thinking #PopularScience #Math #Reasoning

T-Observability Day Tech 2024 (Рубрика #SRE) Астрологи объявили месяц надежности - через 3 недели, а точнее в среду 23 октября, мои коллеги решили организовать конференцию, посвященную надежности и наблюдаемости. В программе будет 5 доклад, один квадратный стол и один воркшоп 1) Доклад о наблюдаемости, надежности и качестве - Алексей Мерсон, Developer Advocate в Sage, Т-Банк 2) Доклад о том, как строится надежность Яндекс Такси - Александр Фишер, руководитель службы надежности Такси, Яндекс Go 3) Доклад о том, как не наступить на грабли Observability - Владимир Дроздецкий, DevOps Teamlead, Magnit Tech 4) Доклад про фронтовые метрики - что нужно для сбора качественных SLI - Максим Вишневский, Frontend Community Lead, Циан 5) Доклад про масштабирование комплаенс-контроля надежности на сотни сервисов - Салих Фахрутдинов, Главный инженер Origination Business Platform, Т-Банк 6) Круглый стол о том, как нанять или вырастить инженера по надежности? - в дискуссии будут участвовать много уважаемых людей:) 7) Воркшоп о том, как готовиться к сбоям и сокращать время на их устранение Отдельным пунктом можно отметить много нетворкинга с экспертами по надежности и инженерами, что создают нашу Observability платформу Sage и остальные инструменты для повышения надежности T-Bank. Полная программа и регистрация тут. P.S. Кстати, прошлом году я рассказывал доклад тему "Проектируем надежные системы" и готовил такой список рекомендованных материалов. Этот доклад и рекомендации неплохо укладываются в тему надежности:) #Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE

Podlodka Techlead Crew - Розыгрыш билета (Рубрика #Architecture) Вчера я уже писал про свое участие в дикускии на конференции от Подлодки, где утром 14 октября я буду обсуждать тему проектирования надежных систем. И по счастливому стечению обстоятельств у меня есть один билетик для читателей канала. Я решил разыграть его среди тех, кто предложит мне интересную свежую книгу или whitepaper на тему надежности программных систем. Одно правило - она должна выйти после 2022 года и я про нее еще не рассказывал на своем канале. Для того, чтобы участвовать недостаточно просто написать название - надо еще написать один абзац на тему того, а что крутого было в рекомендованной книге/whitepaper, которая вам так понравилась. Результаты розыгрыша я подведу в понедельник, выбрав самый интересный предлооженный вариант. #Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE

Обзор whitepaper "A Human-Centered Approach to Developer Productivity" (Рубрика #Management) Больше года назад я прочитал интересную статью, про человеко-центричный подход к продуктивности:) В этой статье Ciera Jaspan и Collin Green (два лида из Google) рассказывали о том, что они в Google отвечают за RnD команду, что изучает вопросы того, а что делает инженеров продуктивными и счастливыми. И круче всего, ребята обещали стартануть целую серию статей. Тогда я прочитал whitepaper создал черновик статьи и … забыл его опубликовать. И только недавно я наткнулся на то, что в этой колонке уже вышло восемь интересных статей, одну из которых про "Software Quality" я разобрал в деталях. Именно в этот момент я понял, что мне надо подрихтовать свой старый черновик обзора и все-таки опубликовать его — так появилась эта статья:) P.S. Это обзор первой статьи из колонки "Developer Productivity for Humans" в журнале IEEE, про которую я писал раньше. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Podlodka Techlead Crew (Рубрика #Architecture) Всего полторы недели осталось до моего участия в круглом столе «Архитектура на старте: подготовка к успеху» в рамках Podlodka Techlead Crew. Там мы обсудим принципы построения надежной архитектуры ваших систем. Мы поговорим про базовые подходы в виде retries, circuit breakers, rate limiters, а также про более продвинутые подходы навроде разных моделей деплоя приложений, которые позволяют достигать разных уровней availability (подробнее на эту тему рекомендую почитать whitepaper "Deployment Archetypes for Cloud Applications"). Помимо этого круглого стола будут и другие интересные спикеры - Александр Агейченко разберет принципы мобильной надежности на примере мобильного Т-Банка. - Даниил Подольский обсудит Disaster Recovery и управление рисками. - Вадим Мартынов расскажет о контроле перегрузок и защите сервисов от отказов. Если вы решите посетить конференцию Techlead Crew, то воспользуйтесь промокодом на скидку в 500 рублей - techlead_crew_7_Sw2ePA. Плюс отдельно мы разыграем бесплатный билет на конференцию, но про это я подробнее напишу вечером. P.S. В прошлом году я рассказывал доклад тему "Проектируем надежные системы" и готовил такой список рекомендованных материалов. #Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE

Podlodka Techlead Crew (Рубрика #Architecture) Всего полторы недели осталось до моего участия в круглом столе «Архитектура на старте: подготовка к успеху» в рамках Podlodka Techlead Crew. Там мы обсудим принципы построения надежной архитектуры ваших систем. Мы поговорим про базовые подходы в виде retries, circuit breakers, rate limiters и так далее.Ъ+ P.S. В прошлом году я рассказывал доклад тему "Проектируем надежные системы" и готовил такой список рекомендованных материалов. Обсудим ключевые принципы надежной архитектуры. Уделим внимание механизмам повторных попыток и самоисцеления, которые обеспечивают устойчивость приложений к сбоям. Присоединяйтесь к нам, чтобы узнать, как заложить прочный фундамент для надежных систем.

A16z The Fintech Newsletter. October 2024 Fintech Newsletter: Fintech isn’t dead. AI is driving a new beginning (Рубрика #Strategy) Я давно подписан на рассылку от фонда Anderssen Horowitz, но обычно ее пролистываю быстро. А вот октябрьское письмо мне понравилось - в нем были интересные статьи 1) Fintech isn’t dead. AI is driving a new beginning Аторы начали с технологических продуктовых циклов: PC Era, Internet Era, Cloud Era, Mobile Era, AI Era, а потом показали как AI здорово может помочь финансовым организациям в автоматизации, например, compliance сотрудников, которые в США за последние 20 лет стали пятыми по скорости роста количества мест в компаниях 2) Why You Shouldn't Fear "Trading Like A Bank" Базовая статья на тему того, как работает оценка банков, исходя из их капитала, а также почему часто финтех компании получают больший мультипликатор. Просто и доступно про важность ROE (return on equity). Собственно, инвесторы, как правило, оценивают банки по P/B (price-to-book) коэффициенту, что рассчитывается как капитализация, разделённая на размер собственного капитала компании. Этот мультипликатор является сокращением для моделей остаточного дохода, которые прогнозируют «избыточную» доходность, которую зарабатывает банк, то есть разницу между его доходностью на собственный капитал («ROE») и его стоимостью собственного капитала. Коэффициент, кратный 1x, означает, что бизнес заработает ROE, равную стоимости его капитала. А вот для финтех компаний обычно характерно более высокое ROE, обусловленное двумя причинами - Более высокая чистая прибыль - обычно финтех-компании умеет дешевле обсулижвать клиентов, а также предлагать продукты более маржинальным клиентам - Оборот активов. Многие финтех-компании способны генерировать больше долларов дохода на единицу активов, чем традиционные банки, поскольку их бизнес-модели обычно основаны на комиссиях в дополнение к процентным доходам. Потоки комиссионных доходов не ограничены размером базы активов (в отличие от процентных доходов) и, следовательно, могут способствовать более высокому обороту активов. Дальше авторы приводят примеры западных компаний, которые умеют в финтех, даже если у них есть банковская лицензия: (American Express, Nubank) #Fintech #Management #Strategy

Колонка "Developer Productivity for Humans" в журнале IEEE (Рубрика #Management) В прошлом году я узнал, что пара исследователей из Google, Ciera Jaspan и Collin Green стартанули как редакторы отдельную колонку "Developer Productivity for Humans" в журнале IEEE Software. Первая статья вышла еще в далеком 2023 году и она задавала весь тон дискуссиии, описывая человеко-центричный подход к этому вопросу. А месяц назад я нашел уже седьмую статью - оказалось, что эти статьи не отображаются на исследовательском сайте Google и их надо искать отдельно на сайте IEEE. Вся серия статей показалась мне интересной, поэтому поделюсь ссылками на них, чтобы вам не пришлось искать:) Плюс дальше я сделаю обзор этих статей в отдельных постах. 1) A Human-Centered Approach to Developer Productivity - эту статью я отдельно разбирал у себя в блоге 2) Hybrid Productivity - эту статью я отдельно разбирал у себя в блоге 3) Defining, Measuring, and Managing Technical Debt 4) Build Latency, Predictability, and Developer Productivity 5) Onboarding and Ramp-Up 6) Measuring Flow, Focus, and Friction for Developers 7) Software Quality - эту статью я отдельно разбирал у себя в блоге 8) Creativity in Software Engineering В общем, рекомендую эти статьи к прочтению - они коротенькие по 6-8 страниц и очень простые, все сложные моменты в статьях, на которые ссылаются авторы, а в этих статьях приведены только основные тезисы и результаты. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Platform Engineering Night @ T-Bank (Рубрика #Conference) 16 октября вечером мои коллеги собирают всех интересующихся платформенной разработкой в нашем московском офисе на Белорусской на мероприятие Platform Engineering Night. В этот вечер ваш ждет плотная программа, гда наши и внешние эксперты обсудят разные интересные темы (про некоторые вещи наши ребята будут рассказывать впервые): - Начнется мероприятие с выступления Станислава Сычева, CTO нашей внутренней платформы разработки Spirit, который расскажет с чего все начиналось и где мы сейчас в плане создания платформы - Дальше Владислав Калугин, technical product manager расскажет про важность developer experience (devex) при созданиии IDP (внутренней платформы разработки), а также подскажет как его замерить - Потом Александр Титов из Флант расскажет про результаты последнего российскиого State of Devops Report и что поменялось с прошлого раза - А закончится программа высутплений дискуссией экспертов, которую будет модерировать главный идеолог нашей PaaS, Дмитрий Гаевский. В обсуждении будут участвовать уважаемые люди: Александр Лукьянченко, Head of PaaS, Авито; Александр Серпичев, Эксперт по архитектуре платформ; Карапет Манасян, Глава платформы разработки цифровых продуктов, MOEX Group; Владимир Калугин, Technical product manager (Code & Build & Artifacts & DevEX), Т-Банк. В общем, регистрируйтесь и приходите послушать эти интересные темы, особенно если вы сами создаете платформы или активно пользуетесь уже созданными:) #PlatformEngineering #Architecture #Processes #Conference

API Governance at Scale (Рубрика #Management) Недавно прочитал интересную статью исследователей про API Governance процессы в Google. На самом деле эта статья напрямую предшествует статье "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency", про которую я рассказывал раньше. В статье "API Governance at Scale" авторы в деталях как и зачем авторы меняли подход к построению API. Собственно, они пришли к процессу, что состоит их трех частей 1) API Improvement Proposals - это задокументированный источник правды относительно того, какие правили есть по отношению к дизайну API 2) API Linter - это автоматизированная проверка соответствия API правилам из AIP (круто, что авторы смогли кодифицировать AIPs и дальше проверять их в этом линтере) 3) API Readability - программа обучения и сертификации API Design экспертов. Процесс API Readabity в Google похож на другой их процесс, а точнее на code readability, про который я уже рассказывал раньше Это исследование рассматривает этот процесс со стороны создателей API и показывает позитивное влияние на качество API как со стороны результата, так и процесса. Интересно, что в уже упомянутой статье-продолжении "AI-Enhanced API Design" этот же процесс рассматривается как со стороны создателей, так и потребителей API и тоже показывает положительное влияние. В общем, whitepaper интересный и я точно сделаю его более подробный разбор, но рекомендую почитать статью в оригинале - она короткая, но очень интересная:) P.S. Именно странички из этой статьи послужили иллюстрацией к посту про whitepaper. #Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

This is Leonardo da Vinci (Рубрика #Art) Эта книга Joost Keizer рассказывает про жизнь Леонардо из Винчи, который родился незаконнорожденным, что не позволило ему пойти по пути отца и стать нотариусом. Вместо этого он пошел заниматься искусством и преуспел в этом:) Правда, эта дорога оказалась путем странствий, который он начал в творческом водовороте Флоренции, дальше поколесил по городам-государствам, а закончил на пенсии в роли гения при дворе короля Франции. Мы знаем Леонардо в основном за его картины, но он проводил много времени вдали от мальберта и был воистину универсальным человеком, который интересовался ествественными науками, инженерией, скульптурой, поэзией, музыкой и даже анатомией (что потом сыграло не в его пользу). Все это он совмещал со своими вынужденными путешествиями - фактически, он был аля цифровым кочевником прошлых дней:) Личный мир Леонардо был одновременно ярким и активным. Иногда он взаимодействовал, а иногда нет, с более широким миром. Но то, что из этого вышло, утвердило Леонардо как определение человека эпохи Возрождения. В общем, книга достаточно интересная и красивая, чтобы ее было приятно почитать, даже если вы как я уже прочитали пару других книг о нем - Мозг Леонардо. Постигая гений да Винчи (Leonardo's Brain: Understanding Da Vinci's Creative Genius) - Леонардо да Винчи. Возрождение мира (Leonard de Vinci, la rennaissance du monde) #Art #History #Biography

How Amazon and Google view CI/CD in an entirely different way (Рубрика #Architecture) Очень интересная статья про разные подходы двух крупных компаний к построению своих процессов CI/CD. Автор проработал суммарно 15 лет в инженерных командах, что занимались CI/CD инфраструктурой: сначала 11 лет в Amazon, потом 4 года в Google, а потом вернулся обратно в Amazon. И в этой статье он рассказывает, как отличчается школа мысли этих двух компаний к построению своих процессов CI/CD, фокусируясь на следующем трио - Pre-submit - эта фаза относится к developer experience до сабмита кода. Собственно, автор разбирает то, какие проверки можно вкрутить на этом этапе в своем рабочем пространстве или как часть процесса code review - Post-submit - это фаза относится к developer experience после сабмита кода. Как происходит merge изменений, как код развертывается в prod-like тестовых средах и прогоняются проверки там, и как код дальше выкатывается на прод - Testing - автор в статье говорит про интеграционное и сквозное тестирования, а не модульное. Модульное тестирование тривиально для запуска в любом месте, но интеграционное тестирование требует, чтобы код-кандидат был развернут в тестируемой системе и связан с зависимостями, что добавляет экспоненциальный уровень сложности к инфраструктуре. Дальше он говорит, что Google и Amazon по разному хостят свой код - Google использует monorepo и весь код хранится в одном месте - Amazon использует концепцию microrepos, где код отдельных сервисов хранится в отдельных репозиториях И это отличие обуславливает разный подход к инструментам и фокусировке на разных этапах developer experience. Если кратко, то Google крут в pre-submit проверках, так как сотни тысяч инженеров живут в общем репозитории, где нет отдельных бранчей. Blast radius при сабмите проблемного кода очень велик, поэтому они очень много инвестируют в разные крутые штуки на pre-submit (вот другая статья автора, где он рассказывает про это run end-to-end integration tests from a local dev environment, or a code review, against ephemeral, hermetic test environments). Но вот post-submit опыт совсем другой - код катится на прод совсем не часто. Суть здесь в том, что изменения разных инженеров накапливаются в батчи, по которым прогоняется большее количество тестов. Это сделано потому, что одна строчка кода может повлиять на большое количество deployments, поэтому запускать все проверки на каждый коммит точно не получится. Но расплата за это - долгое ожидание доставки кода на продакшен. В Amazon код живет микрорепах, где blast-radius изменений ограничен твоим репо (по крайней мере, на pre-submit части). То есть, закоммитив что-то странное, ты легко навредишь только своим коллегам по 2-pizza-team. А дальше включаться post-submit проверки, которые не позволят раскатиться этому изменению. Поэтому в Amazon слабая автоматизация pre-submit части, но вот post-submit сделан сильно лучше, чем в Google. Отличие в том, что изменения в коде оказываются на проде в течение часов, а не суток. Финализируя, автор говорит, что Google и Amazon выбрали разные подходы для борьбы со сложностью - Monorepo ребят из Google работает за счет большой команды, что автоматизирует pre-submit и делает умную селективность тестов, позволяет им запускаться герметично и так далее, но код доставляется на прод долго. Но если требуются крупные изменения по кодовой базе, то их легче сделать в одной монорепе - Microrepos ребят из Amazon проще менять и выкатывать новый фичевый код на прод, не опасаясь больших проблем. Но вот проблемы с обновлением зависимостей в разных репозиториях - это боль. В итоге, автор статьи отмечает, что поддерживать подход Amazon можно гораздо меньшей командой И тот и другой подход имеет право на жизнь и фактически задает некоторую школу мысли для своих адептов:) Автору больше нравится подход Amazon Ну и на самом деле круто скомбинировать крутой опыт на pre-submit и на post-submit, но часто это слишком дорого, поэтому имея ограниченные ресурсы инфра команды фокусируются на самом важном в их условиях. #CI #SRE #Architecture #Software #Infra #QA

EMBA. Сколково. Фундамент (Рубрика #Management) Прочитал красочную книгу Юрия Уляшева про его обучение на программе Executive MBA от университета Сколково. От чтения книги остались смешанные впечатления: +) Книга сделана очень красиво - ее действительно приятно держать в руках или поставить на полку +) Она состоит из красочных конспектов Юрия, в которых кратко рассказывается о пройденных модулях, которых было 18 штук +) Из книги можно почерпнуть общую структуру обучения, где присутствует общий и стратегический менеджмент, лидерство, стратегический маркетинг, финансовый и управленческий анализ, корпоративные финансы, макроэкономика, управление проектами, управление персоналом, ведение переговоров, предпринимательство, принятие решений, операционный менеджмент, венчурный капитал и описание выездных модулей -) Книга напоминает дембельский альбом и тем, кто не проходил MBA в Сколково она даст не слишком много (я, кстати, учился в Сколково в нашей корпоративной MBA и в части модулей у меня случались флешбеки) -) Проработка тем автором и фактическая точность иногда вызывает вопросы - например, фраза в стиле "Agile - это метод управления проектами" звучит оооочень странно -) Книга наполнена рекламой NFT коллеции автора blots.life, сайт которой уже не доступен, также есть и другие странные рекламные интеграции В общем, книга хорошо подходит для тех, кто 1) Хочет понять а что такое EMBA именно в Сколково 2) Закончил EMBA в Сколково и хочет закрепить воспоминания об этом в бумаге P.S. Я уже рассказывал про похожу книгу про MBA - MBA в картинках (The Visual MBA), где меньше пафоса и более сфокусирована теория. А вот тут мои вспоминания о прохождении нашего MBA, что было совместно c INSEAD и Сколково. #Management #Leadership #Processes

Leveraging Computational Thinking in the Era of Generative AI (Рубрика #AI) Интересная статья на тему computational thinking в эру LLMs. После того, как я стал членом ACM (Association of Computing Machinery) мне стали приходить подборки новостей, часть их которых я даже успеваю читать. Конкретно в этой статье шла речь про computational thinking, термин, который был популярен в 2000х и насколько он актуален сейчас. Если возвращаться к определению, то вычислительное мышление формируется в терминах вопросов «Что люди могут делать лучше компьютеров? И что компьютеры могут делать лучше людей?» (Wing, 2006). Собственно в 2000х был целый поток статей, в которых авторы пытались определить какие когнитивные и социальные навыки человека необходимы для процессов решения проблем в целом и для решения вычислительных задач в частности. На сегодняшний день ключевыми компонентами computational thinking считаются (Wing, 2010) - Формулирование проблемы - Декомпозиция проблемы - Организация и логический анализ данных - Представление данных с использованием моделей и симуляций - Абстракции - Предложение и оценка нескольких решений данной проблемы - Реализация выбранного решения - Обобщение Эти навыки вычислительного мышления сегодня признаются важными не только в контексте компьютерных наук, но и как важные навыки для каждого в 21 веке и могут применяться в различных контекстах (Günbatar, 2019; Wing, 2017). Дальше авторы статьи отмечают, что в эру LLMs активно развивается prompt engineering, который определяется так (Dang et al., 2022)

Systematic practice of constructing prompts to improve the generated output of a generative model

Это новая область исследований, которая задается вопросом о том, какие наилучшие практики существуют для формирования промптов для задач GenAI в целом и для задач программирования в частности. Забавно, что эта новая область исследований достаточно быстро может быть старой после появления новых LLMs, которые делают промпт инжиниринг внутри себя:) Но авторы отмечают, что computational thinking нужен для эффективного prompt engineering, который в свою очередь позволяет прокачивать computational thinking, что приводит к позитивной петле обратной связи. Интересно, что Yael Erez, соавтор этой статьи, преподает курс «Введение в компьютерные науки» (CS1) студентам бакалавриата по специальности «Компьютерные науки». В осеннем семестре 2023 года студентам было поручено несколько заданий, включающих решение задач по разработке с помощью приложений GenAI, таких как ChatGPT. И данные по этому обучению подтверждают вышеуказанную связь между computational thinking и prompt engineering. А значит computational thinking нам пригодится и в эпоху GenAI. И хотя сам GenAI может облегчать решение задачи программирования даже для сложных систем, тем самым устраняя необходимость осваивать определенный языковой синтаксис, им все еще не хватает вычислительного мышления. Поэтому вычислительное мышление людей необходимо в эпоху GenAI. P.S. Интересно смотреть на последние достижения foundational моделей, потому что ситуация развивается очень стремительно. И если пока computational thinking людей еще помогает LLMs, то дальше может все и поменяться:) #AI #ML #Software #Architecture #Future

Code of Leadership #20 - Interview with Alexey Grishin about Software Architecture (Рубрика #Architecture) В двадцатом выпуске подкаста "Code of Leadership" я общаюсь с Алексеем Гришиным, архитектором расчетных продуктов T-Bussines в Т-Банке. Алексей проектирует системы, налаживает архитектурные процессы, менторит коллег по архитектуре. На позиции архитектора работает уже около 10 лет, постепенно увеличивая масштаб и зону ответственности. Алексей - один из первых , кто затащил и поддерживает практику Event Storming в Т-Банке. За час мы обсудили следующие темы - Как Алексей пришел в компанию - Как Алексей перешел к роли архитектора - Переход Алексея в Т-Бизнес - Выстраивание процесса управления архитектурой - Согласование изменений - Принятие решений - Подходы с RFC и ADR - Масштабирование архитектурного процесса - Discovery и event storming - Различия в восприятии контекста - Сложности в применении event storming - Продуктовый подход к developer experience - Продажа изменений менеджменту - Документирование решений - Стоит ли расти в архитектора - Практический подход к обучению - Рефлексия и изучения опыта других компаний #Architecture #Software #Management #Leadership #Processes #Architecture

Изучение whitepapers (Рубрика #Architecure) В последнее время я изучаю много whitepapers для того, чтобы ответить для себя на экзистенциальные вопросы относительно того, как правильно выстраивать процессы разработки софта. Меня интересуют темы developer productivity, system design, software architecture и так далее. Причем большая часть прочитанных whitepapers напрямую относится к моей работе в Т-Банке. И я решил стартануть отдельный подкаст с обсуждением разобранных whitepapers, куда я тоже буду звать гостей, с которыми мы будем обсуждать эти крутые статьи. Пока я не придумал название для подкаста, так что в комментах можете накидывать предложения. На фото изучение очередного whitepaper на этот раз про "API Governance at Scale" by Google P.S. Вот примерный список обзоров whitepapers, что я уже разбирал и хотел бы обсудить с гостями - Обзор whitepaper "Secure by Design at Google" (Рубрика #Architecture) - Обзор whitepaper "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" - Обзор whitepaper "CNCF Platforms White Paper" - Обзор whitepaper "Deployment Archetypes for Cloud Applications" - Обзор whitepaper "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - Обзор whitepaper "AWS Fault Isolation Boundaries" - Обзор whitepaper "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles" - Обзор whitepaper "Lifting the veil on Meta's microservice architecture: Analyses of topology and request workflows" - Обзор whitepaper "A Human-Centered Approach to Developer Productivity" - Обзор whitepaper "Measuring Developer Goals" (Рубрика #Management) - Обзор whitepaper "Developer productivity for Humans, Part 7: Software Quality" - Обзор whitepaper "Improving Design Reviews at Google" - Обзор whitepaper "The SPACE of Developer Productivity" - Обзор whitepaper "DevEx in Action" - Обзор whitepaper "DevEx: What Actually Drives Productivity" Если у вас есть опыт в одной из тем и желание обсудить ее со мной на подкасте, то пишите в личку #Whitepaper #Architecture #Management #Science

The way we play. Theory of game design (Гейм-дизайн. Как создаются игры) - Part II (Рубрика #Design) Продолжая рассказ про книгу о геймдизайне Майкла Киллика (Michael Killick), начатый ранее, я хотел рассказать кратко об оставшихся главах 3. С бумаги на экран - как строить сюжетную линию, какие типы персонажей бывают (смешной, героический, ...). Как выстроить геймплей, передвигаться по миру, залезать на возвышенности, прыгать, плавать. Какие варианты взгляда на мир есть: 2D, 2.5D (изометрический), 3D, от первого лица, от третьего лица 4. Контроллер персонажа от первого лица на Unity - практический пример как при помощи Unity сделать демку с видом от первого лица и очень простым миром. Тут автор объясняет как пользоваться Unity и приводит куски кода для базовой настройки демки 5. Управление миром - дизайн уровней - как строить карты, как управлять персонажем, как выстраивать обучение для новых игроков 6. Друг или враг? Дизайн противников - как сделать противников интересными и разнообразными. О том, что у них могут быть разный размер, поведение, скорость, подход к перемещению, атаки, здоровье и так далее. Отдельно автор отмечает важность создания боссов:) 7. Механика, система боев и мультиплеер - здесь автор рассказывает про важное трио, где нужно проработать механики игры, а также боевую систему. После этого уже можно думать про многопользовательскую игру 8. Руководство по созданию 2D-платформеров - еще один пример с Unity, но теперь про создание простенького платформера 9. HUD и UI. Что это такое? - как правильно задизайнить экран (heads-up display), который видит игрок. И тут речь не про основное зрелище, а про вспомогательные элементы: индикатор здоровья, боеприпасов, выносливсти, мини-карта и так далее. Отдельно автор отмечает, что можно делать статический HUD или динамический, который появляется только в некоторых случаях 10. Совет напоследок - автор говорит о важности создания реалистичных целей при создании игры, создании game design документа и следования ему, а также работе в команде, что часто позволяет довести до ума даже сложный проект. 11. Совет или начало - здесь автор подбивает саммари по книге и завершает мотивирующим

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

P.S. Я стал больше интересоваться гейм-дизайном после того, как мой сын поступил в этом году в бакалавриат по этому направлению. Но и до этого я много писал на тему игр и геймдизайна - The Making of Prince of Persia - Геймдзайн (Designing games. A guide to engineering experiences) - Minecraft: Мобиология (Minecraft: Mobestiary) - Кровь, пот и пиксели (Blood, sweat and pixels) - Настольная игра "Нефариус" - Настольная игра "Корпорация Гоблинов" (Goblins Inc) - Прогейминг, Overwatch, киберспорт (Young guns: obsession, owerwatch, and the future of gaming) - Мастера Геймдизайна (Game Designer Confessions: Insights from Finland's Top Game Designers) - Мальчик, сделанный из кубиков (A Boy Made of Blocks) - Настольня игра "Бумунту" - Документальный фильм про AlphaGo - Настольная игра "Ужасы Аркхэма" #Games

Обзор whitepaper "Secure by Design at Google" (Рубрика #Architecture) Недавно я прочитал интересный whitepaper от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. Начинается статья с того, что для security экспертов самоочевидно, что вопросы безопасности должны рассматриваться как интегральная часть дизайна софтовых продуктов и добавление безопасности уже после создания продукта обычно заканчиваются неудачей. А что с этим можно сделать автор рассказывает уже дальше. И если немного спойлерить, то автор отмечает, что security posture софтверных продуктов и сервисов является эмерджентным свойством developer ecosystem, в рамках которой проектируются, имплементируются и деплоятся приложения. А значит эта экосистема должна быть создана определенным образом так, чтобы позволять на этапе проектирования и написания кода сделать его безопасным by design. В самом whitepaper приводится достаточно много примеров о том, как это сделано в Google. Подробнее с обзором можно ознакомиться в моем блоге. P.S. Я уже участвовал в паре подкастов про безопасность, где мы обсуждали shift left security и secure by design - [SafeCode Live] Secure by design - Code of leadership #15 - Interview with Roman Lebed about Information security и упоминал про пару книг - Building secure and reliable systems - я про нее уже как-то рассказывал - Agile Application Security #Software #Security #Infosec #SystemDesign

Публичные выступления на конференциях (Рубрика #PublicSpeaking) Я начал выступать на конференциях около шести лет назад на Teamlead Conf, где я рассказывал про тимлидов во фронтовых командах нашего публичного веба тогда еще Тинькофф. Для меня это был во многом пугающий опыт, так как до этого на конференциях я не выступал. Но, оглядываясь назад, я могу сказать, что тот опыт мне сильно помог вырасти с какой стороны не посмотри и я смог - Стрктурировать свои знания по управлению разработкой, образованию команд и прокачке своих инженеров, многие из которых стали тимлидами. Подготовка к докладу очень хорошо помогает проверить насколько ты действительно разобрался в теме и закрыть определенные пробелы - Познакомиться с крутыми ребятами, которые решали похожие проблемы и почерпнуть их опыт - Вырасти как лидер - мне стало гораздо проще доносить свои мысли просто и понятно и вести ребят за собой - Начать нарабатывать авторитет как эксперт в управлении разработкой, а потом и в проектировании софта Это все дальше мне помогло и в карьере - этот опыт и навыки сработали в плюс, когда я решал свои рабочие вопросы в Т-Банке, где я уже работаю почти 8 лет. Интересно, что на ранних этапах карьеры мне казалось, что спикеры на сцене технобоги, а потом я понял, что не боги горшки обжигают:) С тех пор я активно помогаю стать спикерами другим людям, как внутри компании, так и вовне, будучи в программном комитете ArchDays. Собственно, многие конференции помогают начинающим и опытным спикерам сделать свои доклады лучше, а также часть опытных спикеров ведет очень интересные телеграмм каналы, которые полезно бывает почитать. Собственно мы с этими ребятами собрались в тематическую папку спикеров, которая может быть полезна для тех, кто хочет начать выступать но не знает как. В общем, я рекомендую попробовать начать выступать сначала с внутренним митапов, потом внешних, а потом переходить на тяжелые на... крупные конференции. Поверьте это вам поможет стать лучше как профессионал и получить заслуженное признание (ведь если больше людей знает, что вы сделали что-то хорошеее, то вам будет дальше проще наносить окружающим пользу). P.S. Кстати, я уже достаточно часто рассказывал про публичные выступления раньше - Talk Like TED (Презентации в стиле TED) - The Hero with a Thousand Faces (Тысячеликий герой) - К выступлению готов. Презентационный конструктор - Memo - Убеждай и побеждай - Пиши, сокращай - Вредные советы для спикеров - Риторика. Поэтика - Драматика или поэтика рациональности - Магия общения - Откровения оратора (Confessions of a Public Speaker) - Выступление в стиле TED. Говорю. Слушаю. Слышу (How to be heard. Secrets for powerful speaking and listening) - Как сторителлинг сделал нас людьми (The Storytelling Animal: How Stories Make Us Human) - Черная риторика. Власть и магия слова (Schwarze Rhetorik - Macht und Magie der Sprache) - В голос! Нескучное руководство по созданию подкаста - Randy Pausch Last Lecture: Achieving Your Childhood Dreams - Успешная короткая презентация - Искусство словесной атаки. Практическое руководство (SchlagFertigkeit. Das Arbeitsbuch) - Корпоративная презентация. Как продать идею за 10 слайдов - Курс подготовки спикера от Кирилла Анастасина - 100 главных принципов презентаций (100 Things Every Presenter Needs to Know About People) - Говори на языке диаграмм (Say it with Charts) - Сделано, чтобы прилипать. Почему одни идеи выживают, а другие умирают (Made to Stick. Why Some Ideas Survive and Others Die) - Последняя лекция. Мудрая книга о силе мечты (The Last Lecture) #PublicSpeaking #SelfDevelopment

Центральный университ (Рубрика #Education) Сегодня я был на экскурсии в Центральном Университете, который расположен рядом со станцией метро "Маяковская". Мне в университете очень понравилось - очень интересно устроено пространство, где есть большие аудитории для лекций, средние аудитории для семинаров, маленькие переговорки для работы в командах. Есть зоны притяжения в виде библиотеки, спортивного зала, два кофепоинта Drinkit (в одном я перехватил кофе, так как не успел его выпить до начала экскурсии). В общем, когда больше 20 лет назад я начинал учиться на Физтехе, у меня таких условий не было:) Если же говорить про сам формат университета, то это университет со STEM подходом, куда входит science, technology, engineering и math. В нем студенты получают практические навыки для работы в ИТ и свои первые офферы от лидеров индустрии. Ребята уже приняли на обучение больше 600 студентов, где основная часть учиться на первом курсе бакалавриата и магистратуры, но есть и второкурсники магистры, что начали учиться в универе еще в прошлом году. А вообще, здание расчитано на то, чтобы вместить больше двух тысяч студентов, так что ждем следующих наборов. P.S. Может быть после написания пары книг я подумаю и в сторону академического курса и начну потом его преподавать студентам:) #Career #Education