Книжный куб

Основы Теории U (The Essentials of Theory U. Core Principles and Applications) Три года назад я прочел книгу "Основы Теории U" за авторством Отто Шармера, которую в 2019 году выпустило издательство МИФ. Тогда книга показалась мне слишком эзотерической - в ней системное мышление густо переплетается с "обновлением наших психологических и организационных операционных систем во всех секторах социума". Изначальная книга по теории U в три раза больше книги про Основы и видимо еще более замороченная, а вот "Основы теории U" читается неплохо и состоит из трех частей: 1. Основа видения поля - про познание внутреннего состояния, из которого проистекают наши действия 2. Метод системных измений, учитывающих сознание - методы и инструменты для инициатора изменений 3. Осмысление эволюционных преобразований в обществе - про глобальные изменения и инициативу U.lab В общем, интересная книга ... для расширения сознания #Management #Leadership

Балет "Зимняя Сказка" в Большом Театре Был вчера с женой на этом балете и нам все понравилось. Мы сидели во втором ряду партера и могли наблюдать не только хореографию артистов балета, но и работу дирижера, а также его оркестра. За работой этих слаженных коллективов было очень интересно следить с учетом того, что я как-то писал статью про подходы оркестровки и хореографии в мире менеджмента разработки ПО:) Сам балет был в трех действиях, наполненных драматическими событиями, которые не очень-то были похожи на сказку, а если и были, то на какую-то мрачную. Правда, финал был максимально похож на happy end:) В общем, если вам нравится балет, то вероятно вам понравится эта постановка на основе одной из поздних пьес Уильяма Шекспира. #Culture

Как нанимать технических руководителей — выступление на Teamlead Conf 2023 Только что закончил выступление на конференции и добрался до публикации статьи с кратким содержимым. В прошлом посте я заспойлерил анонс, то тут я отмечу чем может быть полезна статья. Но перед этим отмечу, что главное не заниматься карго-культом и пытаться повторить описаннные мной процессы. Лучше учитывать ваш контекст и использовать описанные мной подходы для того, чтобы — Улучшить наем технических руководителей в вашу компанию — Улучшить наем технических руководителей в вашу команду:) — Понять что вы можете прокачать в себе для становления лучшим руководителем — И напоследок, самому лучше подготовиться к такому типу интервью, если вы планируете сменить работу #Management #Leadership #Processes #Conference #SystemDesign #Engineering

Список материалов для моего выступления сегодня на Teamlead Conf 2023 "Как нанимать технических руководителей " Наем инженеров обсуждается на конференциях довольно часто. Кто-то рассказывает про то, как нанимает за одну встречу, а другие говорят про свои многоэтапные интервью. А вот про наем технических руководителей (teamlead, engineering manager, director of engineering) рассказывают гораздо реже. В этом докладе я исправляю эту несправедливость и в конце делюсь списком рекомендованных материалов, представленных ниже. Отдельно отмечу, что расшифровку доклада я тоже опубликую сегодня, но уже после выступления:) Management and Leadership - Книга "The Manager's Path" и саммари в трех частях: pre-manager, manager, engineering director  - Книга "An Elegant Puzzle: Systems of Engineering Management" и ее краткий обзор  - Книга "A Seat at the Table: IT Leadership in the Age of Agility" и ее краткий обзор  - Книга "The Art of Leadership: Small Things, Done Well"  - Книга "Technology Strategy Patterns"  - Книга "Staff Engineer" и обзор в двух частях: 1 и 2  - Мой доклад "Эволюция роли технического руководителя от инженера до CTO", в нем есть куча рекомендаций по изучению  - Мой доклад "SOLID'ный тимлид, или основы менеджмента для технарей" Processes and projects - Книга "Team Topologies" и ее обзор в 3 частях: teams as means of delivery, team topologies that work for flow, evolving team interactions for innovation and rapid delivery  - Книга "Remote Team Interactions Workbook"  - Книга "More Effective Agile: A Roadmap for Software Leaders"  - Книга "Making Work Visible"  - Книга "Digital Transformation Game Plan"  - Моя статья "Про управление проектами и продуктами" HR -Книга "Who : Solve Your #1 Problem"  - Книга "The CEO Next Door" -Статья про performance review Technical excellence -Статья про System Design Interview в общем  - Статья про то, как мы оцениваем System Design Interview -Статья о том, как подготовиться и пройти System Design Interview  - Публичное System Design Interview на C++ Russia 2022  - Публичное System Design Interview на конференции ArchDays 2022  - Статья про то как развиваться если ты уже Senior developer  - Стать про Troubleshooting Interview в Tinkoff  - Статья со списком книг о проектировании программного обеспечения #Management #Leadership #Processes #Conference #SystemDesign #Engineering

Сегодня вечером в 18:00 по Мск будет седьмой выпуск клуба "Code of Architecture" по книге "Распределенные системы" ван Стина и Таненбаума, в котором мы обсуждаем главу про именование. Предыдущие выпуски были посвящены общему обзору книги, обсуждению архитектуры, процессов, коммуникаций, координации, именования, а теперь мы дошли до обсуждения следующих важных вопросов - Для чего нужна репликация и какие проблемы она решает (производительность и надежность), а какие приносит с собой (сложность поддержки консистентности)  - Какие модели консистентности бывают: дата-центричные и клиенто-центричные  - Какие бывают дата-центричные модели консистентности (sequential, causal, eventual, continuous) - Какие бывают клиенто-центричные модели консистентности (monotonic reads, monotonic writes, read your writes, writes follow reads), а также рассмотрим пример с ZooKeeper  - Как управлять репликами (replica management)  - Какие протоколы косистентности бывают А также напоследок рассмотрим как работает кеширование и репликация в современном Web Гостями стрима станут наши коллеги — Дмитрий Гаевский и Виталий Кондратов. Дмитрий занимается разработкой dev to dev-решений на больших масштабах, создает сложные RnD-решения и проектирует event-driven-системы. Виталий — архитектор в отделе базовых технологий. Он разрабатывает и улучшает базы данных и инфраструктуру для их эксплуатации. Встречаемся на ютуб-канале IT's Tinkoff. #SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

#Sec #Security #Agile #Processes #Software #SoftwareDevelopment #DevSecOps

Дальше рассматриваются вопросы безопасности Глава 5. Безопасность и требования. Тут речь идет о том, что безопасность - это просто еще одна область нефункциональных требований и ее стоит встривать в процесс работы над системой с самого начала как, например, вопросы производительности конечного решения или его удобства Глава 6. Гибкое управление уязвимостями. Тут речь идет о том, как относится к уязвимостям, как учитывать их и как планировать их устранение, а также как связано тестирование и безопасность Глава 7. Риск для гибких команд. Вся глава посвящена основам риск менеджмента в контексте вопросов безопасности. Если вы уже знакомы с этой областью знаний, то сложно будет найти что-то новое Глава 8. Оценка угроз и осмысление атак. Одна из самых содержательных глав по безопасности:) Глава 9. Построение безопасных и удобных для пользователей систем. Здесь рассматриваются варианты проектирования безопасности так, чтобы она приводила в итоге к продукту, которым нельзя пользоваться, т.к. средства безопасности рушат весь user experience Глава 10. Инспекция кода в интересах безопасности. Здесь рассматриваются варианты code review причем с точки зрения того, как их использовать правильно, чтобы повысить безопасность конечного решения Глава 11. Гибкое тестирование в безопасности. Здесь речь о том, как тестировать код, инфраструктур и CI/CD пайплайн в интересах обеспечния безопасности. Авторы упоминают несколько инструментов, которые могут быть полезны практикующим специалистам Глава 12. Внешние инспекции, тестирование и рекомендации. Лучше всего про содержание этой главы говорит следующая фраза, завершающая главу: "Если вы не собираетесь использовать внешние инспекции, чтобы учиться у экспертов, то только зря тратите их время и свои деньги" Глава 13. Эксплуатация и безопасность. Здесь рассматриваются вопросы мониторинга и обнаружения вторжений, реакций на инциденты, защиты CI/CD пайплайно и работы с секретами:) Глава 14. Сообщение нормативным требованиям. Здесь расматриваются 2 подхода: 1. Подход на основе правил (Пример: PCI DSS) 2. Подход на основе результатов (Пример Reg SCI) Эту главу полезно прочитать, чтобы понять разницу в этих подходах, а заодно ознакомиться с человеческим описанием того, что за правилы описаны в PCI DSS, которые часто поминауются всуе по поводу и без:) Глава 15. Культура безопасности. Превосходная глава. Очень хорошо про культуру. Замечательно про "тяни, а не толкай". Отличные принципы эффективности: 1. Содействуй, а не блокируй; 2. Прозрачная безопасность; 3. Не ищите виноватых; 4. Масштабировать безопасность, усиливать фланги; 5. Кто - не менее важно, чем как Глава 16. Что такое гибкая безопасность. В этой главе каждый из 4-х авторов книги рассказывает свою историю и делится тем, как пришел к вопросам безопасности в разработке и кристализует свои мысли относительно темы книги

Безопасность разработки в Agile-проектах (Agile Application Security: Enabling Security in a Continuous Delivery Pipeline) Три года назад я прочитал эту превосходную книгу. Изначально я думал, что книжка поможет мне ознакомиться с текущим состоянием дел в безопасности. Но на самом деле авторы подошли с большим размахом к этой теме. В книге они поставили перед собой задачу: - рассказать разработчикам о том, как выглядит современные подходы к безопасности - рассказать олдскульным безопасникам как выглядит современная разработка и что запретительный подход из прошлого перестал работать при появлении современных подходов навроде CI/CD В самом начале идет краткий экскурс в современную разработку в главах: Глава 2. Элементы гибких методик Глава 3. Революция в методах разработки - присоединяйтесь! Глава 4. Работа с существующим жизненным цилком разработки Эти начальные главы дают настолько хороший экскурс, что они будет полезны не только безопасникам, но и самим разработчикам, работающим в рамках гибких подходов, т.к. иногда следование процессам преващается в карго-культ или формопоклонничество как это называл Фейнман:) Поэтому иногда стоит вспоминать, что важен не сам процесс ради процесса, а те результаты, которые он помогает достигать

HBR's 10 Must Reads on Strategy (Стратегия от Harvard Business Review) Лет пять назад я прочитал эту книгу 2009 года от HBR по стратегии, в которой было собрано 10 классических статей на эту тему. Сама книга была разделена на две части: создание стратегии и ее воплощение в реальность. Часть про создание стратегии начиналось с Майкла Портера, классика в этом вопросе, а заканчивалась стратегией голубого океана. В части про исполнение стратегии мелькала история про систему сбалансированных показателей, которую я помню еще по своей магистратуре:) А вообще тема стратегии и тактики мне знакома еще лет с 6, когда я начал заниматься шахматами и занимался ими лет до 14:) Так вот у Савелия Тартаковера, знаменитого шахматиста, была такая фраза "Тактика - это знание того, что делать, когда есть, что делать. Стратегия - это знание того, что делать, когда делать нечего" и эта фраза отлично описывает отличие:) Для тех, кто заинтересовался книгой, вот перечень статей, которые вошли в нее Strategy Development 1. What Is Strategy? by Michael E. Porter 2. The Five Competitive Forces That Shape Strategy by Michael E. Porter 3. Building Your Company’s Vision by James C. Collins and Jerry I. Porras 4. Reinventing Your Business Model by Mark W. Johnson, Clayton M. Christensen, and Henning Kagermann 5. Blue Ocean Strategy by W. Chan Kim and Renée Mauborgne Strategy Execution 6. The Secrets to Successful Strategy Execution by Gary L. Neilson, Karla L. Martin, and Elizabeth Powers 7. Using the Balanced Scorecard as a Strategic Management System by Robert S. Kaplan and David P. Norton 8. Transforming Corner-Office Strategy into Frontline Action by Orit Gadiesh and James L. Gilbert 9. Turning Great Strategy into Great Performance by Michael C. Mankins and Richard Steele 10. Who Has the D?: How Clear Decision Roles Enhance Organizational Performance by Paul Rogers and Marcia Blenko P.S. Плюс бонусная статья от HBR про стратегию от 2014 года The Big Lie of Strategic Planning by Roger L. Martin #Strategy #Management #Chess #Leadership

Руководитель разработки медиапроектов Тинькофф Первая вакансия в этом канале будет посвящена поиску человека, который будет работать над развитием наших медиа-проектов. Его руководителями будут ребята из бизнеса в лице главного издателя и главного продакта наших медиа, а также я в качестве руководителя по инженерной части. Интересно, что само направление медиа для меня не чужое, так как еще до Tinkoff я успел принять участие в разработке медиа-проектов, будучи руководителем команд разработки в Woman.ru и Banki.ru. А в первый день выхода на работу в Тинькофф я познакомился с первым программистом Тинькофф Журнала (Т—Ж), так как мы одновременно устраивались на работу. Дальше я никогда напрямую не отвечал за ТЖ, но часто помогал с консультациями и выделением времени инженеров из моих команд. Но теперь настало время платформизировать Т—Ж и сделать его основой всех наших медиа. В итоге, я ищу опытного руководителя, который возьмёт на себя роль технического директора медиапроектов Тинькофф: он возглавит команду отдел из 40 инженеровспециалистов, запустит новые направления и выстроит процессы. Сейчас в разработку медиапроектов входит три больших продукта: - Журнал - Помощь - Бизнес-секреты - Помимо этого есть и другие продукты поменьше: образовательные Учебник и Школа бизнеса, блоги продуктов, платформа для медиа. Продукты представлены в вебе и мобильных приложениях. Всё это поддерживают и развивают семь продуктовых команд и две сервисные. Продуктовые команды кросс-функциональные, в их состав кроме технарей входят продакты, дизайнеры, редакторы и другие специалисты. Сервисные команды — тестирование и инфраструктура. В планы медиапроектов на 5 лет входит — Создать большое сообщество, где пользователям будет легко создавать и загружать контент в разных форматах: видео, изображения, длинные и короткие статьи, а модераторам — проверять его — Прокачать админку, чтобы редакторы сами выпускали статьи и публиковали другой контент без участия специально обученных верстальщиков. Помимо этого надо будет — Разработать собственную CMS на основе текущих наработок Т—Ж, чтобы запустить новые контентные проекты и пересадить на неё существующие. — Запустить и поддержать 10 новых контент-проектов. Сделать всё так, чтобы каждый проект не был ограничен возможностями платформы, а мог по необходимости расширяться собственной функциональностью. Что этому кандидату предстоит делать Я ожидаю, что руководитель разработки - Будет активно участвовать в стратегическом и тактическом планировании, а также воплощении планов в реальность - Возьмет на старте большую часть работы по созданию и внедрению медийной платформы - Сможет разобраться в соответствующих предметных областях: инфраструктуре, тестированию, особенностях работы медиа, современных рассылок, аналитике и многочисленных интеграциях - Будет принимать качественные управленческие и технические решения В моих глазах идеальный кандидат: — Несколько лет руководил отделом или командой разработки больше 30 человек. — Работал в крупной продуктовой компании. В идеале, ещё и успел поработать в медиа. — Умеет оптимизировать процессы: ускорять релизы, повышать пропускную способность команды. — Имеет широкий технический и архитектурный кругозор. Знаком с концепцией микрофронтендов, эволюционного дизайна, монолитов, сервисов, микросервисов, чистых функций и вот этого всего. В идеале, уже однажды спроектировал и воплотил переход технического решения из продуктового в платформенное. — Знаком с большей частью стэка команды: React, React Native, FastAPI, Postgres, Redis, Docker, Kubernetes. — Умеет планировать на разные горизонты: от спринта до нескольких лет. Способен синхронизировать эти планы между бизнесом и технарями. Различает роадмапы и бэклоги, CJM и user story. P.S. Если вы считаете, что подходите на эту позицию, то пишите мне в личку. #Vacancy #Engineering #Management #Leadership

Writing an engineering strategy Интересная статья про инженерную стратегию от Will Larson, автора книг An Elegant Puzzle (про engineering management) и Staff Engineer (про высокоуровневых SDE). В этой статье автор рассказывает про то, как писать engineering strategy, являясь engineering executive, используя структуру которую предложил Richard Rumelt в книге "Good Strategy, Bad Strategy". В этой структуре 3 составляющих: 1. Diagnosis - объяснение в чем вызов и корневая проблема, которую мы решаем 2. Guiding policies - подходы, которым стоит следовать для решения вызовов. Эти руководящие policies могут быть как явными, так и неявными компромиссами (tradeoffs) между вариантами действий. 3. Coherent actions - набор действий, которые направляются принципами для решения challenge. Эта самая важная часть стратегии. Дальше автор рассказывает про - Процесс написания - Когда ее стоит писать - Что делать с отсутствующими бизнесовой и продуктовой стратегией, которые должны учитываться в инженерной стратегии

В этот понедельник мы провели шестой стрим клуба Code of Architecture по книге “Distributed Systems”, в котором мы обсудили вопросы именования. А точнее мы поговорили про - адреса, идентификаторы и имена - плоское именование, влючая распределенные хеш таблицы и consistent hashing - структурное именование, включая unix filesystem и DNS - attribute-based naming, включая триплеты RDF из семантического веба и LDAP как комбинацию структурного и attribute-based подхода - name-data networking, экспериментальный подход, который хочет занять место протокола IP в современном интернете Гостями стрима были - Алексей Квак, руководитель разработки из Тинькофф Артефакты с этого стрима доступны по ссылкам - Статья с кратким обзором - Запись стрима - Miro доска с презентацией #SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

Кинофантастика. Наука выносит вердикт (Ls Science Fait Son Cinema) В этой интересной книге ученые, Ролан Леук и Жан-Себастьян Стейер, разбирают популярные научно-фантастические фильмы и рассказывают насколько они реальны и какие реальные научные дисциплины стоят за сюжетом. Авторы проходятся бегом по астрономии, физике, биологии, лингвистике, бактериологии и вирусологии, причем это неполный список. Сама книга состоит из четырех частей: 1. Посрамить физику - авторы разбирают фильмы "Человек-муравей", "Гравитация", "Интерстеллар") 2. Новые горизонты - авторы разбирают фильмы про космические станции в виде колец для создания искусственной гравитации, далше обсуждают жизнь на Марсе на примере фильма "Марсианин", продолжают рассмотрением жизни на ледяных планетах, а потом вспоминают про фильм "Прометей" про Чужого 3. Эти удивительные инопланетяне - тут обсуждение начинается с происхождения внеземных видов, продолжается эволюцией видов в научной фантастике, а напоследок разбираются проблемы экзо-лингвистике на примере фильма "Прибытие" 4. Осторожно опасно для жизни - в этой части авторы обсуждают невидимые опасности в виде радиации, микробов и бактерий. Дальше разбирают фильмы "Нечто", "Годзилла" и "Тихоокеанский рубеж" #PopularScience #Physics #Cinema

Software Engineering для Финтех Школы Мы в компании уделяем достаточно много сил и времени обучению. Мы учим как сотрудинков внутри, так и будущих сотрудников, начиная со школьной скамьи и продолжая в университете. В этом году мне надо было записать для Финтех Школы лекцию про облачные вычисления и я решил посмотреть как мои коллеги рассказывали о Software Engineering в предыдущих циклах обучения. Так я наткнулся на доклад Игоря Маслова, директора базовых технологий, который он читал для студентов в 21 году. Доклад мне понравился тем, как Игорь разбирает эволюцию подходов в разработке софта и демонстрирует, что это очень динамичная сфера, в которой подходы постоянно развиваются и то, что было нормой еще 10 лет назад может к текущему моменту безвозвратно устареть. Ну и из этого обзора видно, что наша молодая дисциплина идет от ремесленного к инженерному подходу, обрастая практиками, которые позволяют обеспечить повторяемый результат хорошего качества. #SoftwareDevelopment #Software #Engineering #SystemEngineering #Processes

От основ к созданию роботов Лет 5 назад я купил эту книгу для обучения сына премудростям создания роботов. Я ее конечно прочитал, но воплотить план обучения в жизнь не получилось, но это не проблема книги, которая отлично написана и оформлена иллюстрациями. Её приятно даже просто пролистать.Если переходить к сути книги, то авторам удалось весело и с простыми практическими занятиями раскрыть заявленную в названии тему:) В первых главах были описаны разнообразные роботы и дана качественная характеристика, отличающая робота от радиоуправляемой игрушки:) Дальше авторы рассказали о: - программировании алгоритма работы робота - булевой логике - датчиках как органах чувств роботов - беспроводной связи - adruino и управления моторами при помощи ШМИ В общем, книга действительно интересная и подходит для практических занятий робототехникой с сыном:) #Robotics #ForKids #SoftwareDevelopment #Engineering

Agile Patterns В свое время читал перечень этих паттернов в карточке с DZone, плюс есть сайт agilepatterns.org Если кратко, в первой половине статьи с DZone автор выделяет шаблоны, которые помогают организовывать разработку по agile. Про них все всегда рассказывают и поэтому я не буду их здесь перечислять. А вот на последних страницах автор рассказывает об антипаттернах, которые могут пох...рить всю нашу работу по выстраиванию процессов:) Среди таких антипаттернов присутствуют - Cherry Picking - выбор членами команды самых "вкусных" задач из беклога вместо самых приоритетных - Death March - продолжение проекта, который уже не нужен, но на который потратили много сил и его жалко закрыть - Disguised Project - проект, который заказчик пытается пропихнуть как рутинные задачи - Micromanagement - ну тут все ясно:) - Unbounded Timebox - неопределенные границы для завершения проекта - Undefined Done - ху..к-х..к и в продакшен:) и куча техдолга на выходе - Unlimited WIP - неограниченный объем задач в работе - Unresolved Proxy - много заказчиков без одного ответственного за продукт - Waterscrumfall - гибрид из waterfall и scrum, признан нежизнеспособным в открытой природе:) В общем, хорошая статья и читается легко:) #Management #Processes #Scrum #Kanban #Agile

Chaos Engineering. Building Confidence in System Behavior through Experiments Эту книгу я прочитал лет 5 назад и мне она понравилась: отличная обложка и очень здравый и взвешенный подход для работы с комплексными системами Книга начинается с главы "Зачем заниматься инженерией хаоса" и ее достаточно для того, чтобы определиться стоит ли читать книгу дальше. В первом абзаце авторы рассказывают о том, что Chaos Engineering используется для эмпирического исслледования поведения систем при помощи экспериментов. Чем-то этот подход напоминает мне лабораторные работы по физике/химии в университетские времена:) Основная цель эксперииментов узнать о потенциальных слабостях системы заблоговременно, а не в момент, когда они приводят к реальным проблемам. Хаос иненерия кардинально отличается от тестирования системы, т.к. в тестировании есть специфичные условия и ожидается специфичное поведение, тесты обычно имеют бинарную природу. В итоге, тесты не дают нам новой информации о системе. В свою очередь, хаос инженерия в свою очередь при помощи экспериментов поззволяет нам лучше понять систему и узнать об особенностях ее функционирования. В этой же главе рассказывается о пререквизитах для Chaos Engineering: для определения степени готовности вашей организации к использованию Chaos Engineering вам требуется ответить на 1 вопрос:"Достаточно ли устойчива ваша система к событиям реального мира, например, отказам сервисов или пикам сетевых задержек (network latency)". Если ответ "нет", то до вы знаете что вам стоит сделать до того, как изучать данную книгу:) Думаю, что большая часть читающих книгу отсеивается на данных пререквизитах:) Но представим, что мы ответил "Да" - в этом случае вы попадаете в прекрасный мир chaos engineering, который помогает контролировать сложность систем и спать спокойно:) Если тема вас заинтересовала, то предлагаю вам самим ознакомиться с этой книгой:) #Chaos #Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software #SoftwareDevelopment

Вчера Кирилл, мой двухлетний сын, добрался до "книжки с кабанчиком". Кажется, что он уже готовится проектировать что-то масштабное:)

Сегодня вечером в 18:00 по Мск будет шестой выпуск клуба "Code of Architecture" по книге "Распределенные системы" ван Стина и Таненбаума, в котором мы обсуждаем главу про именование. Предыдущие выпуски были посвящены общему обзору книги, обсуждению архитектуры, процессов, коммуникаций, координации, а теперь мы дошли до обсуждения следующих важных вопросов  - Зачем нужны имена, идентификаторы и адреса  - Что такое плоское именование (flat naming). Здесь в качестве примеров рассмотрим Distributed Hash Tables  - Что такое структурированное именование (structured naming). Здесь в качестве примеров рассмотрим работу DNS и Unix FileSystems  - Что такое основанное на атрибутах именование (attribute-based naming). Здесь вспомним про LDAP  - Что такое named-data networking Встречаемся на ютуб-канале IT's Tinkoff. #SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

Computing machinery and intelligence (Вычислительные машины и разум) Это знаменитая статья Алана Тьюринга опубликованная в 1950 году в журнале Mind. В этой статье автор описал свой подход при поиске ответа на вопрос “Может ли машина мыслить”. Сейчас этот подход зачастую называют тестом Тьюринга, а сам автор назвал это игрой в имитацию. Знакомство с этим подходом сейчас как никогда актуально с учетом новой волны хайпа вокруг чатботов, которые умеют достаточно неплохо вести диалоги с пользователями. Суть подхода Алана в том, что вопрос “может ли машина мыслить” слишком общий. Для того, чтобы на него ответить придется дать сначала определение того, что такое машина, потом что такое мыслить. Причем определение того, что мы понимаем под мышлением машины и мышлением человека может не совпасть. Поэтому Тьюринг предлагает сделать шаг в сторону и заменить изначальный вопрос на тот, что может быть относительно легко проверен, а именно сможет ли машина отвечать на вопросы человека так, чтобы он счел ее человеком. Если машина на это способна, то она проходит тест, который в наше время называется тестом Тьюринга. Забавно, что большую часть книги автор борется с возможными контраргументами относительно такого перехода и дальше относительно главного вопроса, причем борется успешно. Чуть больше подробностей про контраргументы можно прочиитать в моей статье на Medium. Плюс можно посмотреть фильм про Алана Тьюринга "Игра́ в имита́цию" ("The Imitation Game"), в котором рассказывается о вкладе Алана во взлом немецкой Энигмы во время второй мировой войны. #ComputerScience #AI #PopularScience