Книжный куб

На корпоративе колегги пошутили со сцены, представляя меня, что в 2024 году

Александ Поломодов научиться читать книги быстрее, чем авторы их писать

С учетом плана написания своей книги, это очеь вероятно:) #Humour

Радость познания (The pleasure of finding things out) - 2 Продолджая пост про первую половину этой крутой книги, рассмотрим оставщиеся главы 8. Что такое наука? - лекция для молодых преподавателей, где Фейнман хотел поделиться с ним своих подходом к познанию сути вещей, то есть как смотреть на мир с любопытством и непредвзятостью, но прежде всего как научиться во всем сомневаться 9. Самый большой умник на свете - здесь Фейнман признается в своей любви к физике и говорит, что меньше всего любит философию, а также обсуждает КЭД, про которую есть отдельная книга "КЭД - странная теория света и вещества", про которую я уже рассказывал 10. Наука ослепляющей дикости: некоторые замечания по поводу науки, псевдонауки и рекомендации, как не дать себя одурачить - здесь Фейнман круто рассказывает про карго-культ и приводит историю туземцев на островах, которые строили соломенные самолеты и аэродром, чтобы к ним опять начали поступать грузы с большой земли:) 11. Это просто - как раз, два, три - смешная история про Фейнмана в студенческие времена, которая демонстрирует его экспериментальный подход к выяснению загадки счета и времени 12. Ричард Фейнман строит Вселенную - здесь Фейнман круто рассказывает про свое первое выступление перед учеными, которое случилось сразу перед нобелевскими лауреатами:) А также о звонке о получении Нобелевской премии, на который Ричард ответил "Не могли бы вы сообщить мне об этом утром?" 13. Взаимосвязь науки и религии - философская лекция, в конце которой Фейнман объединяет "два великих наследия западной цивилизации": дух научного приключения и христианскую этику. Наука позволяет нам участвовать в захватывающем путешествии в непознанное, где тайны Вселенной все равно остаются незыблемыми и все подлежит сомнию, а религия дает базис любви и братсва людей, говорит о ценности отдельной личности и смиренности духа. P.S. Забавно, что у меня появилась эта книга после поездки на Физтех ради выступления, про которую я рассказывал раньше. #PopularScience #Physics #Biography

Радость познания (The pleasure of finding things out) - 1 Эта книга составлена из выступлений Фейнмана на разных мероприятиях, зачастую перед студентами или другими учеными. Часть из этих выступлений не публиковалась раньше, поэтому книгу я читал с большим интересом. В отличие от книги "Вы, конечно, шутите, мистер Фейнман", про которую я рассказывал раньше, эта книга предполагает вдумчивое чтение, интерес читателя к науке и научному подходу к познанию окружающего мира, а также готовность подвергать все сомнению:) А теперь немного про содержание книги 1. Радость познания сути вещей - статья, что дала название всей книге. В ней мы видим как подход к познанию Ричарда сформировался под влиянием отца, который не учил терминам или теориям, а учил наблюдать за окружающим и видеть суть и взаимосвязи. Мне особенно понравилось познание через аналогии ака "тиранозавр в окне" (смотри на эту тему рекомендую "Большую книгу аналогий") и разбор алгебры для практичного человека, где Ричард рассказывает про инструкции из школы про решение задач как "целый набор шагов, с помощью которых вы могли бы получить ответ, если не понимаете, что вы пытаетесь сделать". Остальная часть статьи тоже очень интересна, не даром она идет первой в книге. 2. Компьютеры будущего - в этой статье Ричард выступает провидцом и говорит о паралелльных компьютерах и их миниатюризации. Достаточно интересно обсуждался вопрос обратимых и необратимых вычислений и связи скорости вычислений с потреблением энергии. Все это рассматривается не с позиции технических возможностей почти сороколетней давности (лекция 1985 года), а скорее с точки зрения концептуальных возможностей и того, что это видение не противоречит существующим физическим законам 3. Лос-Аламос - взгляд снизу - это рассказ про времена Фейнмана в Лос-Аламосе и участие в Манхеттенском проекте. В принципе, это все обсуждалось и в уже упоминавшейся книге "Вы, конечно, шутите ..." 4. В чем состоит и в чем должна состоять роль научной культуры в жизни общества - здесь Ричард рассказывает про научный подход, выдвижение гипотез и теорий, их полезность и фальсифицируемость. Он верит в то, что и жизнь общества должна идти по пути, похожему на научный - "всегда нужно оставлять место сомнениям, дискуссиям" и что "придет время, когда люди полностью осознают, что сила власти ограниченна, что правительства не уполномочены решать вопрос, ценна ли научная теория или нет ... Они не должны присваивать себе право делать выбор между различными версиями описания истории, экономической теории или философии" 5. Как много места в глубине - в 1959 году Фейнман в Калтехе рассказывал про нанотехнологии - это было провидческое выступление, где он упоминал про: хранение информации, аналог фотолитографии, выстраивание атомов для создания новых материалов. В конце он устрол конкурс по миниатюризации, который в итоге превратился в премию Фейнмана по нанотехнологиям 6. Ценность науки - лекция в формате урока для молодых ученых о том, что они несут ответственность за будущее цивилизации 7. Особое мнение Ричарда Фейнмана, касающееся следствия по делу космического корабля-челнока "Челленджер" - если говорить на it'шном, то Ричард участвовал в написании постмортема по инциденту с "Челленджер", но его мнение не хотели учитывать в официальном отчете, поэтому он написал свое "особое мнение" и добился включения его в официальный отчет (в приложении) P.S. Продолжение разбора в следующем посте. #PopularScience #Physics #Biography

Tinkoff TeamLead Meetup 1 Интересный митап на тему тимлидов от Тинькофф, которое прошло под знаменем наджености и в котором было 4 выступления по 20 минут + 10 минут на вопросы/ответы. Вот эти доклады 1) Как выиграть гонку с бизнесом на высоконагруженном сервисе, обеспечивая высокий уровень надежности Выступление Владислава Хачатурова из Сбера на тему того, как выстроены внутренние процессы на самом высоконагруженном сервисе "Главный экран" для приложения Сбербанк Онлайн в условиях вечной гонки, с обеспечением высокой надежности. Тут много было про inner-source и как сделать платформенную команду, которая работает над архитектурой, надежностью, принимает сервисы в эксплуатацию от продуктовых команд, которые контрибьютят в сервисы платформенной команды. 2) Как мы падали и поднимались. И чему научились в процессе. Выступление Ильи Барбашова из Авито, где он рассказывает про как в Авито захворали важные инфраструктурные сервисы (Kafka as a Servioce). А дальше как ребята изменили подход к оценке их надежности, и как это помогло планировать им работу и общаться с пользователями, которыми являются продуктовые разработчики. 3) Настройка окружения Выступление Алексея Калакина из билайн, в котором он рассказал о проблемах взаимодействия с инфрой, и с интеграционно связанными приложениями. Разобрал как настроить свзяь бизнеса и технических лидов, а также показал как решать это различными методами. 4) Стратегия управления техническим долгом Выступление Никиты Ульшина из Тинькофф, в котором он рассказывает про то, откуда берётся техдолг, как он влияет на продуктивность и мотивацию команды, как правильно планировать работу над техдолгом и как избавиться от него. Дальше идет обсуждение приоритизации и того, как продавать результаты работы над техдолгом. Интересно, что Никита работает в команде, которая делает бекенд систему для нашего server driven UI для веб приложений, а про эти системы я уже раньше упоминал в других докладах:) #Management #Engineering #Software #SoftwareDevelopment #Architecture #Processes #SRE #Leadership

Как формировать структуру команд под запросы бизнеса - часть 3 Продолжу пост про структуру команд и проектный подход и в этом посте мы поговорим про продуктовую разработку. В прошлом посте я много говорил про полезность проектного подхода и возникает вопрос, а зачем нам нужна продуктовая разработка, если есть такие замечательные проекты. Но проекты хороши для старта новых инициатив или ведения кросс-командных активностей. А вот если мы хотим более планово и непрерывно поставлять ценность, то мы приходим к концепции продукта, где - Есть конкретная целевая аудитория продукта - Есть примерное понимание какие фичи, стори, JTBD (jobs to be done) мы хотим реализовать - Есть желание выкатывать эти изменения небольшими порциями и тестировать как они работают - Есть понимание, что план может гибко меняться в процессе движения С таким набором ожиданий становится ясно, что проектный подход нам не подходит. В итоге, мы приходим к продуктовым процессам разработки, про которые я рассказывал в докладе "Совершенствование потока разработки программного обеспечения", где я рекомендовал почитать книгу "Making Work Visible" от Доминики Деграндис, про которую я писал раньше. Но вообще есть несколько подходов к тому как организовывать работу и планировать время ее выполнения. Однако важно помнить про ироничный закон Паркинсона

Работа заполняет время, отпущенное на неё

Этот закон дает понять почему планирование работы с буферными запасами проблема, а именно так часто планируют в проектном управлении. Но если планировать работу задач на команду в режиме push, то можно столкнуть с тем, что требования к командам и их производительность не сбалансированы, что не позволяет выполнить все задачи вовремя. В итоге, нам нужна система с pull режимом, когда люди вытягивают новую задачу по мере завершения предыдущей. Такой системой, например, является Kanban. Но важно понимать какие задачи попадают в такой процесс - важно не соглашаться на все подряд, а обдуманно давать добро только на самые важные в конкретный момент и делать это визуально. Для этого надо организовать систему рабочего потока, выполняющую следующие задачи - Делает работу видимой - Ограничивает количество незавершенной работы - Оценивает рабочий поток и управляет им - Эффективно определяет приоритеты - Вносит коррективы на основе метрик и обратной связи И проблема со временем и его утеканием обязана следующим пяти факторам - Too WIP - история про незавершенную работу, бутылочное горлышко и закон Литтла. - Unknown dependencies - здесь про архитектурные проблемы и зависимости между системами и разными командами. - Unplanned work - незапланированная работа крадет время у запланированной. Этим она делает систему непредсказуемой, а главное для нас — это прогнозируемость и ожидания. - Conflicting priorities - если все задачи приоритетные, то ни одну из них нельзя назвать реально важной. Без внятных приоритетов людям приходится пытаться сделать слишком много сразу, что автоматически приводит к росту WIP, который замедляет всю систему. - Neglected work - часто такая работа проявляется в форме техдолга, который накапливался в системе, когда люди только клепали фичи без работы по повышению технического совершенства системы. Вообще, часто проседает важная но не срочная работа, которую так любят откладывать … пока она не перерастет в экстренную ситуацию, когда станет незапланированной работой, от которой нельзя отказаться. В итоге, я всегда стремился выстроить продуктовые кросс-функциональные команды, используя Kanban подходы. В целевом виде эти команды являлись stream-aligned командами из Team topologies (подробнее в обзоре 1, 2, 3). Про то, как я строил продуктовую разработку я рассказывал в контексте нашего веба Tinkoff.ru в двух давних докладах - Доклад на Teamlead Conf 2018 про масштабирование фронтовых команд Tinkoff.ru с управленческой точки зрения - Доклад на ArchDays 2019 про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях #Management #Leadership #Project #ProjectManagement #Software

Мартин

I guess my recommendation would be to learn just enough about the internals of the systems that you're using so that you have a reasonably accurate mental model of what's going on there.

Jesse There are a lot of paths out there. Pit's to look out the various paths, look at what you want to do and what your skills are and see if one of those applies to

you.

Jesse отмечает следующие карьерные варианты: разработка, менеджмент, наука, консалтинг, devrel. И в зависимости от сильлных сторон и предпочтений, стоит выбирать свой путь. #Management #Data #Databases #SystemEngineering #DistributedSystems #Software #Architecture #Conference

Designing A Data-Intensive Future: Expert Talk • Martin Kleppmann & Jesse Anderson • GOTO 2023 Крутое интервью Мартина Клеппмана и Jesse Aderson в рамках goto конференции в Амстердаме. Сначала пара слов об участниках интервью - Мартина Клеппмана многие знают как автора классической книги с кабанчиком ("Designing Data-Intensive Applications"), сейчас он больше исследователь и занимается так называемым "Local-First Collaboration Software" (automerge) - подробнее можно посмотреть в выступлении Мартина, которое я разбирал месяц назад - Jesse Anderson я узнал в качестве автора книги "Data Teams", а также автора интересного выступления "Why Most Data Projects Fail and How to Avoid It", про который я рассказывал 2 месяца назад В итоге, оба участника превосходно шарят в теме разговора и поэтому она развивается очень интересно. Вот тут доступна ее расшифровка. Ниже тезисно расскажу основные мысли - Мартин рассказывает про свою книгу "DDIA", в которой он рассказал про основы работы с данными и рассмотрел широкий ландшафт технологических решений, которые были актуальны чуть меньше 10 лет назад, когда Мартин начинал писать книгу - Сейчас Мартин планирует написать второе издание книги, в котором он учтет изменения -- Рост популярности cloud-native приложений и разработку распределенных приложений слоями, когда одна распределенная система опирается на нижележащую распределенную систему и так далее - рекомендую про это подробнее прочитать в whitepaper от ребят из Google "Deployment Archetypes for Cloud Applications", про которую я рассказывал раньше -- Закат Map-Reduce, чью поляну забрали cloud data warehouse с точки зрения аналитики и стриминговые системы с точки зрения приложений с кастомной логикой Мне нравится, что Мартин продолжить и во второй книге использовать подход

So I'm not telling people what to do, I'm telling people what questions to ask.

Мартин отдельно отмечает, что написание новой книги идет не быстро, поэтому ждать ее скоро не стоит. Дальше Martin и Jesse обсуждают концепцию единого инструмента для всех задач, связанных с данными, и приходят к выводу, что если бы такой инструмент был, то он бы делал все эти задачи плохо. Поэтому Martin говорит о том, что надо использовать правильные инструменты для конкретных задач, например, удобно начинать с реляционной базы данных, которая достаточно гибкая и производительная. Круто использовать streaming systems для того, чтобы иметь потом возможность переключиться на более удобное решение

For example, you could run both consumers side by side for an amount of time, check the consistency across the two systems, and then eventually decide to switch over from the old one to the new one. Streaming systems allow that so much better than, for example, systems based on, like, doing calls to individual services. So I feel like, as you said, the streaming can help with making change easier there.

Дальше Мартин вспоминает свое бытие в стартапах и говорит, что для них часто важно пытаться сделать вещи максимально просто, потому что они всегда в сложных условиях нехватки времени, людей, ресурсов. А также все очень быстро меняется и надо быть готовым к этим изменениям. Правда, Мартин отмечает, что условная Kafka как streaming может быть overkill для стартапа с точки зрения нагрузки и сложности, но за счет уменьшения сложности изменений - это может быть хорошим решением и для стартапа в качестве базового механизма для работы с данными. Следующая часть интервью посвящена "Local-First Collaboration Software" (automerge), про которое я говорил выше и разбирал месяц назад. А дальше Мартин размышляет на счет бытия ученым и почему он переключился после 10 лет пребывания в стартапах на стезю ученого и как это позволяет ему лучше продумывать сложные идеи в области distributed systems. А также почему так мало PhD диссертаций превращаются в рабочие системы (значимое исключение Apache Flink). Ну и напоследок Мартин и Jesse говорят дают советы для дата инженеров

ICPC Northern Eurasia Contests - победители Не зря съездил на полуфинал ICPC - посмотрел как команда "Ёлки-палки" из МФТИ победила в соревнованиях второй год подряд. Ребята решили все задачи и выиграли очень уверенно. Ждем от них победы в финале ICPC. #Software #Engineering

Как RnD появляется в крупных IТ-компаниях Вот и вышла запись моего выступления на конференции Teamlead++ в треке техлидов про появление research and development в крупных компаниях. В этом докладе я рассмотрел это на примерах компаний Google, Amazon, Yandex и Tinkoff. Причем сначала я показывал как выглядел рост компании, показывал как работает бизнес-модель (часто это была модель платформы с двухсторонним сетевым эффектом), а потом делал вывод, что такой экспоненциальный рост требовал ррешения большого количества технических вызовов. И разные компании к этим техническим вызовам подходили по разному - Google многие из решенных проблем заворачивал в whitepaper, которые дали старт многим open-source проектам - Amazon скорее делал техпродукты для себя, а потом начал их продавать в AWS, причем статьи были не про внутреннее устройство, а про то, как пользоваться этими продуктами - Yandex часто рассказывал про свои решения, но деталей почти не было, но в 2016 году появился в open source ClickHouse, в 2017 - CatBoost, а в 2022 и 2023 публикаций стало много, среди которых самое интересное - YDB и Ytsauru, и это если говорить только про официальный open source от Yandex:) У нас в Тинькофф все начиналось с использования коробочных продуктов, потом мы стали писать много своего кода, года 4 назад стартовала разработка своей IDP (internal developer platform) и кучи технологических продуктов: - Managed K8s - целевой runtime для low-latency приложений - LBaaS - балансировщик как сервис, который доводит трафик до приложений внутри Managed K8s - DBaaS (Postgres, Cassandra, Redis) - целевые базы данных - Kafka as a Service - платформа для messaging - Sage - наша obsesrvabilty платформа (логи, метрики, алерты) со своим языком Mage и планом перехода с Elastic на новосозданную базу данных - Statist и a/b платформа - общее решение для продуктовой аналитики и a/b тестов - Куча инструментов внутри нашей data платформы - тут инструментов очень много - и так далее И сейчас у нас собирается RnD лаба для инженерных исследований, которой руководит Станислав Моисеев, а находится она в нашей платформе базовых технологий, которой руководит Игорь Маслов, директор этой платформы и VP. В общем и целом, для нас развитие RnD направления является стратегическим направлением и если вы хотите заниматься инженерными исследованиями, то можете писать мне в личку, а я познакомлю вас со Стасом и Игорем:) P.S. В ближайший понедельник в 18.00 на стриме Code of Arcitecture мы поговорим про подходы к RnD в Google и расскажем как мы планируем это делать в Тинькофф. На стриме мы будем обсуждать это с Вовой Чистяковым, Игорем Масловым и Станиславом Моисеевым. P.P.S. Материалы к докладу - Статья с расшифровкой - текстовая версия выступления, но без части про Yandex (ее я добавлял именно к Teamlead Conf) - White paper "Google's Hybrid Approach to Research" - хорошая научная статья 2012 года про гибридный подход Google к RnD - Ключевые публикации с Google Research - подборка от меня ключевых whitepaper по техническим продуктам Google - Invent and Wander. Избранные статьи создателя Amazon Джеффа Безоса - книга с историей Amazon через публичные письма Джеффа акционерам + другие ключевые выступления - Письмо Джеффа Безоса акционерам 2010 года - интересно написано про важность общих подходов и инструментов для компании - Статья от Yandex "Почему инфраструктура big tech обычно состоит из самописных решений" - крутая статья, в которой на пальцах объясняются причины и приводится примеры ввнутреннего облака и монорепозитория - Yandex Platform Engineering - крутой ресурс с описанием технологий и команд отдела Yandex Platform Engineering, который делает инфраструктуру для разработки и эксплуатации продуктов Яндекса - Whitepaper "Investigation of The Relationship Between Brand Value And R&D Activities: Fortune 500 Companies Analysis" - исследование про связь стоимости бренда и затрат на RnD #Management #RnD #Leadership #Processes #Architecture #PlatformEngineering

ICPC Northern Eurasia Contests Эти дни с понедельника по среду я провожу в Питере на командных соревнованиях школьников и студентов по программированию: для студентов это ICPC в Северной Евразии, а для школьников это всероссийская олимпиада (кстати, на приложенных снимках как раз она). Вчера я поучаствовал в открытии и рассказал - Как радостно видеть полный концертный зал людей, что увлечены программированием - это достаточно редкое зрелище вобщем, но которое можно увидеть на таких соревнованиях или IT конференциях - Как нам в Тинькофф приятно поддерживать образование в общем и конкретно такое мероприятие (подробнее про активности Тинькофф Образования можно почитать в отдельном канале) - Как круто, что участники добрались до этого этапа соревнований и что их ждет пара увлекательных дней, на протяжении которых надо получать удовольствие от участия - Что кому-то из улыбнется удача и они смогут победить, но даже тех, кому не повезет, ждет светлое будущее в индустрии, например, в компаниях-спонсорах мероприятия (желательно конечно в конкретной желтой компании) - Что желаю всем удачи На этом мой минутный спич завершился, как и мое участие во вчерашней официальной части:) P.S. На фотографиях видно, что столы красочно украшены шариками - это не просто деталь интерьера, это показатель того, как команды справляются с задачами - Цвет шарика отображает сложность задачи - Количество шариков показывает сколько задач решено - А шарики в виде звездочек выдают командам, которые первыми решили конкретную задачу В общем и целом, атмосфера мероприятия замечательная и напоминает то, как в детстве ты сам ходил по олимпиадам - в воздухе чувствуется некоторое напряжение и работа мысли, а на лицах участников мелькают эмоции, видна командная работа, которая иногда сменяется глубокой задумчивостью. #Software #SoftwareDevelopment #Conference #Engineering

Архитектурные диаграммы с помощью LLMs (ChatGPT) Ревьювил на выходных внутренние архитектурные документы и наткнулся на инструкцию о том как правильно писать RFC/ADR а также как можно визуализировать архитектурные диаграммы при помощи чатботов. Сама инструкция была дельной вида

Нарисуй на plantuml диаграмму Есть postgres база. В ней есть таблица под названием XXX. Данные в эту табличку XXX пишет фронтенд YYY посредством обращения к бэкенду ZZZ, работающему с этой базой. Есть ETL процесс который перекладывает эту таблицу в clickhouse WWW, в таблицу VVV. При помощи Jupyter мы подключаемся к DWH и анализируем эту таблицу

VVV В принципе, таким макаром можно попросить LLM сгенерировать - диаграммму классов, компонентную диаграмму, sequence или activity, если нам нужны UML диаграммы - все виды диаграмм из C4 Model: Context, Containers, Components, and Code - любые другие диаграммы: ER, DFD, IDEF, BPMN, ... Правда, в этой инструкции авторы забыли, что на выходе из LLM иногда получается треш, а значит надо знать эти нотации самостоятельно и уметь их читать, а также желательно моделировать. В итоге, визуализировать с помощью ChatGPT конечно весело, но визуализация должна помогать + быть достаточно точной. А для того, чтобы проверить насколько она хороша, я бы рекомендовал не просто командовать чатботу, но еще изучить документацию моделированию, например, такую - Стандарт по UML - Документацию по platuml - Документацию по C4 Model - И любая другая документация по нужной вам нотации моделирования Без таких базовых знаний сложно отвалидировать то, что выдала LLMка #Software #SoftwareArchitecture #Architecture #Engineering #SoftwareDevelopment

День рождения Насти У моей любимой жены сегодня день рождения. За последний год она успела уйти с прошлой работы, решив сфокусироваться на учебе в Вышке. Правда, после старта магистратуры планы поменялись и Настя решила совмещать учебу с работой в качестве директора благотворительного фонда "Академия жизни", миссия которого звучит так

Мы помогаем каждому ребенку из детского дома найти свое место во взрослой жизни В 18 лет дети-сироты остаются один на один с миром, о котором они ничего не знают. Мы готовим ребят к самостоятельной жизни, помогаем научиться правильно переживать эмоции, рассчитывать на свои силы и верить в себя.

Настя подошла к вопросу управления фондом системно и составила стратегию развития на 2024 год. А для того, чтобы помочь реализовать стратегию вы можете подписаться на соцсети фонда или сделать добровольное пожертвование на сервисе "Пользуясь случаем". Раз в квартал представители фонда будут делиться в социальных сетях инфомацией о том, как собранные средства помогают развитию фонда. Информация о фонде - годовой отчет фонда за 2022/2023 - telegram канал фонда - группа вконтакте #Charity

Ruby on Rails: The Documentary Интересная история создания фреймворка для веб-приложений на языке Ruby, которую преимущественно рассказывает сам создатель фреймворка, David Heinemeier Hansson. Сам фреймворк для своего времени был действительно прорывным - он повышал удобство и скорость разработки, позволял разработчику в одиночку накидать прототип или даже довести его до продукта. Правда, у продукта поверх Ruby on Rails было несколько проблем: - производительность решения - когда приложение становилось популярным и получало прирост нагрузки, то чеки за используемые мощности железа становились негуманными - подход conventions over configurations - этот подход про имплицитно принятые решения, которые скрыты от разработчиков, но торчат наружу в виде некоторых guidelines. И все классно работает пока все коллеги разделяют и следуют конвенциям. Но по мере роста решения и команды появляется кто-то, кто, например, используя метапрограммирование (спасибо Ruby) неявно меняет базовое поведение и вся наша стройная схема ломается и надо тратить время на нетривиальный дебаг. В итоге, я персонально больше скланяюсь к мантре "Explicit is better than implicit" из The Zen of Python. Интересно, что я впервые встретился с Ruby on Rails лет 10 назад в курсе "CS169 - Engineering Software as a Service" от Berkley. В этом курсе авторы - с большим энтузиазмом использовали Ruby on Rails в качестве базового фреймворка - промотировали TDD (test driven development) и высокий code coverage - учиили использовать BDD (behavioral driven development) и именно там я познакомился с огурцом (Cucumber) и с тех пор разуверился в этом подходе (но это отдельная история) - показывали как использовать Capistrano для деплоя кода в продакшен, потом я некоторое время использовал этот инструмент в своих продакшен проектах - объясняли почему код, выглядящий как текст на том языке, что ты говоришь - это круто. Ну эту часть я ни тогда, ни сейчас не выкупил (хотя адепты 1С наверное прониклись бы этим объяснением) В итоге, именно продакшен код на Ruby on Rails я особо не писал, но видел как концепции этого веб-фреймворка проникали в фреймворки на других языках (тот же паттерн ActiveRecord) и мне было интересно а куда он пропал с радаров. В этой документалке вы не найдете ответа на этот вопрос, но зато узнаете как этот фреймворк стал популярен. И вам про это расскажет не только David Heinemeier Hansson, но и куча других людей, приложивших руку к развитию этого фреймворка - Jason Fried, Founder & CEO at 37signals - Tobias Lütke, Co-founder and CEO Shopify (участник rails core team с 2004 по 2008 год) - Jeremy Daer, разработчик в 37signals и участник rails core team с 2005 года - Jamis Buck, сейчас в MongoDB (участник rails core team с 2005 по 2007 год) #Software #Engineering #History #SoftwareDevelopment #Architecture #SystemEngineering

Если с ребенком трудно Эта книга Людмилы Петрановской написана простым и понятным языком про детей и для родителей. Для родителей, у которых не получается найти общий язык со своим ребенком. Сама книга состоит из 2 частей и кучу миниглавок с простой мыслью, примером и интерпретацией происходящего - это позволяет легко двигаться по книге и воспринимать ее как смесь теории и решебника:) В первой части книги, которая называется "Прощай, оружие, или make love, not war" автор высутпает в качестве сапера и показывает как можно уйти от конфронтации с собственным ребенком, втянуть шипы, избавиться от дежурных фраз и негодования. Когда эта цель достигнута, то автор переходит ко второй части книги "Трудное поведение: перезагрузка" и показывает - как можно повлиять на трудное поведение ребенка - чем трудное поведение отличается от плохого - в чем причина этого поведения - это зачастую самый простой способ достижения хороших целей (а сложным и конструктивным способам дети часто не успевают научиться) Дальше автор предлагает алгоритм из 7 шагов для перезагрузки поведения 1. Определяем цель - надо выбрать то поведение ребенка, которое мешает жить больше всего. У нас должна быть одна или две цели, на которых мы решили сфокусироваться 2. Что именно происходит? - надо собрать симптомы и попробовать собрать информацию о трудном поведении (что, где, когда, ...) 3. Ищем пружину - надо понять что именно является ключевой причиной трудного поведения. 4. Объясняем, что не так - тут надо объяснить в чем проблема, используя "Я-высказывания", где мы говорим про свои чувства, потребности и проблемы. Не используем "Ты-высказывания" навроде "ты не прав" или "ты плохой" 5. Даем наступить последствиям - важно, чтобы при наступлении последствий родители не злорадствовали, а продолжали поддерживать детей, оставались на их стороне и помогали разгребать последствия. Главное, чтобы последствия не были подстроены, а наступали естественным путем 6. Помогаем добиваться своего по-другому - суть в том, что трудное поведение - это обычно примитивные технологии достижения желаемого. Поэтому нам надо показать на примере правильное поведение. Причем главное - это что вы делаете, а не что говорите. Важно быть изобретательным и помогать ребенку находить разные варианты решения проблем. 7. Закрепляем достижения - для закрепления нового поведения требуется поддерживать детей, проявлять симпатию, говорить уверенно и позитивно о будущих изменениях, хвалить и обнимать детей. В общем, мне книга зашла тем, что она легко написана, содержит базовую теорию и разбор большого количества ситуаций из практики, причем в некоторых из которых можно узнать свой опыт взаимодействия с детьми. После прочтения я понял как можно было в этих ситуациях вести себя по-другому. P.S. Если немного модифицировать советы из книги, то их можно использовать для работы с трудными сотрудниками:) #ForParents #ForKids #Management #Leadership #Psychology

Code of Architecture - Новогодный выпуск 18 декабря в 18.00 у нас будет новогодний выпуск с обсуждением white paper от Google на тему их гибридного подхода к RnD. Эта статья так и называется "Google's Hybrid Approach to Research" и вышла она в 2012 году (статья доступна в pdf версии здесь). На этот выпуск к нам придут два крутых гостя: - Игорь Маслов, мой коллега, директор базовых технологий, вице-президент Тинькофф - Станислав Моисеев, мой колллега, директор инженерных исследований в Тинькофф Я думаю, что выпуск получится огненным и мы поговорим про подходы Google, а также расскажем как это соотносится с тем, как выглядит RnD в Тинькофф. Чуть ближе к делу я напишу анонс с ссылкой на трансляцию и обложкой, а пока можно почитать мой обзор этого whitepaper, а также вспомнить прошлый новогодний стрим, где мы говорили про Манифест про распределенные системы от команды Аmazon, который тоже был вокруг whitepaper и позволил нам обсудить много интересного:) #RnD #SoftwareDevelopment #SystemDesign #Engineering #Management

Как мы в Тинькофф делали игру «три в ряд» для 3 млн клиентов Интересное выступление от Вадима Гончарова, руководителя отдела проектных и игровых решений внутри моего юнита. В этом выступлении Вадим рассказал про то, как он и его команда создали игру "Ряд наград": - как сделали свой детерминированный движок match3 - разработали бэкенд с системой валидации ходов, системой выполнения заданий, выдачи призов и уведомлений - как на фронтенде не стали использовать Unity или iOS/Android - как пошли путём применения HTML5-технологий: взяли связку Pixi.js для игры и React.js для обвеса - как использовали технику dependency injection с помощью DI-контейнера, чтобы подружить огромное количество модулей между собой P.S. Помню как уговаривал Вадима выступить на Python Conf и рассказать про эволюции Тинькофф Журнала, за который он отвечал до проектов и игр. С тех пор Вадим сильно прокачался, но драйв остался все на том же высоком уровне. Кстати, Вадим ведет интересный канал, на который можно подписаться. #Management #Software #Engineering #ProjectManagement #Architecture

ICPC Northern Eurasia Contests В воскресенье еду в Питер, чтобы в понедельник поучаствовать в мероприятиях студенческого командного чемпионата по программированию ICPC в Северной Евразии, который пройдет с 11 по 13 декабря. Судя по расписанию мероприятия, оно будет плотным и насыщенным не только с точки зрения самого программирования, но и с точки зрения side активности, но мне точно надо будет присутствовать на разных церемониальных частях: Opening Ceremony, Awards Ceremony for RTO HSPC, Awards Ceremony for NEF (что удобно подсвечивается желтым в расписании если нажать Ctrl + F и поискать "Ceremony"). Правда, я думаю, что мероприятие будет интересным и я почти все 3 дня проведу на площадке, общаясь с людьми, что увлечены разработкой софта и которые могут стать отличной свежей кровью для наших технологической компании. #Software #SoftwareDevelopment #Conference #Engineering

10 Learnings From Running Production Infrastructure at Google • Christof Leng • GOTO 2023 Хороший доклад от Christof Leng, Lead for Google's SRE Engagement Model and SRE Review Programs. Доклад отлично структурирован и может служить некоторой выжимкой из SRE книг Google, которые доступны на их сайте и про которые я уже рассказывал: SRE Book и Building Secure and Reliable Systems. Если возвращаться к самому докладу, то он состоит из следующих частей 0. Culture - начинается все с знаменитой фразы "Культура ест стратегию на завтрак". Но это еще и инженерная проблема, на которую можно смотреть с точки зрения доступного тулинга, методологии, которую могут использовать инженеры для повышения надежности. 1. Reliability can't be taken for granted - про это же я рассказывал в самом начале своем докладе "Проектируем надежные системы - стоит ли игра свеч", но суть в том, чтобы помнить про надежность и риски того, если система будет недостаточно надежна - на это можно смотреть с точки зрения рисков. Плюс надо помнить, что добавить надежность после создания системы бывает невозможно или слишком дорого, поэтому требования по надежности надо обсуждать в нужный момент 2. Cattle vs. Pets - популярная метафора про то, что нам надо относиться к своим системам не как домашним животным, а как к животным из стада. Это позволяет автоматизировать действия по поддержке стада и масштабировать подходы, что не возможно с домашними животными:) 3. Blamelessness - история про правильный подход к обвинениям. Про это подробнее можно почитать у Веструма, который писал про типологию культур - "A typology of organisational cultures", а также про поток информации в них и отношение к ошибкам - "The study of information flow: A personal journey" 4. Measure what matters - рассказ про SLO (service level objectives) и что они действительно должны быть тем, что важно для пользователей сервиса 5. Failure modes - история про то, что участие в инцидентах в рамках oncall позволяет понять как системы разваливаются, почуствовать пороху и понять, что на кону многое стоит. Это не передается при чтении постмортемов ... даже в слух и по ролям:) 6. No heroes - про то, что культура героев, спасающих всех - это плохо для всех. Нас интересует не преодоление проблем, а их предотвращение. 7. Automation - тут идет речь про посто автоматизацию своей работы, которая позволит делать более сложные задачи и меньше заниматься рутинным ручным трудом - лень двигатель процесса. 8. Change is No. 1 reason for outages - все вокруг постоянно меняется и зачастую это является причиной перебоев в работе. И надо быть готовым к этому. Надо минимизировать риск каждого отдельного изменения и автоматизации их проверки и применения (например, используйте GitOps) 9. Outages are inevitable - проблемы неизбежны и надо быть к ним готовым, ограничивая импакт, частоту и вообще управляя риском. 10. No haunted graveyards - не заводите кладбищ с привидениями, под которыми Chistof понимает важные приложения, которые никто уже не трогает и на знает как они работают, а значит не может починить их в случае проблем с ними. Напоследок автор говорит, что не надо делать сложные системы. Вместо этого надо стараться делать простые системы, хотя это гораздо сложнее, чем сделать сложную систему:) Автор превозносит simplicity и говорит, что boring is beautiful:) #Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE #Reliability #Conference

В этот понедельник мы провели четвертый стрим клуба Code of Architecture по книге "Continuous Architecture in Practice". Он был посвящен в большой степени resilience, но кроме этого мы упомянули про emerging technologies и сделали выводы целиком по книге. Собственно вся дискуссия была вокруг надежности, отказоустойчивости, resilience как архитектурной характеристики. Я уже раньше писал про эту глааву отдельный пост. У нас в гостях были два гостя: - Евгений Пешков, техлид, независимый эксперт и консультант, увлеченный созданием продуктов, построением эффективных команд и внедрение практик технического совершенства в мире разработки и архитектуры ПО, основатель сообщества DDDevotion. - Сергей Баранов, архитектор, основатель конференции ArchDays. Сергей ведет каналы В рамках обсуждения мы упоминали дополнительные материалы - Моя статья "Проектируем надежные системы — стоит ли игра свеч", которая целиком посвящена теме надежности - "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем - "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг) - "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability) - "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность - "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный) - "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем - "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем - "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу. - "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента - "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента - Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы #Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #SRE #Reliability #DistributedSystems