TDR — процесс технического дизайн-ревью / Павел Лакосников (Авито) (Рубрика #Architecture)

Интересный доклад Паши Лакосникова из Авито про принятие качественных технических решений в большой компании. Основные тезисы примерно следующие
1) Сам Паша давно работает в Авито и сейчас занимается выстраиванием architecture governance
2) По мере роста компании все сложнее принимать качественные решение из-за роста чимсла команд и усложнения иерархии
3) Компании часто вводят роли техлидов и архитекторов для решения этих проблем
4) Это приводит к тому, что инженеров отстраняют от принятия решения и они теряют мотивацию и ответственность за принятые без них решения
5) Дальше появляется архитектурные комитеты и архревью, где рассматриваются архитектурные артефакты и принимаются решения
6) Если все решения прогонять через архкомитет, то он становится бутылочным горлышком и замедляет работу, а также стоит много-много денег
7) Следующий шаг - это дизайн ревью решений в асинхронном формате
😍 Для этого нужны шаблоны документов для описания технических решений + автоматическая валидация их заполнения. В документе должны быть: автор, команда, юнит, дата создания, уровень влияния (низкий, средний, высокий), сроки ревью.
9) Дальше появляется реестр таких документов и возможность поиска и анализа решений
10) Инициативы делятся на разные уровни, которые требуют ревью разной строгости и формата
11) Уровни влияния помогают разным стейкхолдерам отслеживать только нужные им инициативы, например, техдиры могут отслеживать самые крупные изменения
12) У технических инициатив есть связь с продуктовыми, что позволяет лучше понять для чего мы делаем изменения и насколько они оправданы
13) У инициатив есть жизненный цикл: прототип, эксперимент, масштабирование. Каждый этап имеет свою детальность проработки. А также можно фиксировать зависимости между командами и компонентами для предотвращения ошибок.
14) Так как в инициативах указываются затронутые компоненты, то их владельцы получают уведомления и могут прийти поревьювить инициативу, в которой они упоминаются
15) Наличие реестра обеспечивает историчность принятия решений + позволяет настроить валидацию принятия решений, чем отдельные роли: авторы, контрибьюторы, FIY и owners
16) Реестр можно связать с техническим радаром, который должен быть входной точкой в жизненный цикл технологий.
17) Все это обеспечивает прозрачность появления и развития технологий, а также их depracation и миграции с EOL (end of life)
18) По всей этой машиенрии можно собирать метрики: количество decision records, время их прохожджения, доля успешно доведенных до конца и так далее
19) Внедренный процесс помогает решить проблему с архитектурными комитетами, а также повысить вовлеченность инженеров

P.S.
Про то, как это устроено у нас было в постах
- Серия подкаста "Code of Leadership" - Interview with Anton Kosterin about Architecture Governance
- Мое выступление на ArchDays 2024 - "Архитектура в Т-Банке: вчера, сегодня, завтра"
- Серия подкаста Research Insights Made Simple про "API Governance at Scale", где мы с Даниилом Кулешовым разбирали whitepaper о том, как это устроено в Google, а также говорили про governance у нас в компании

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Enabling efficient analysis of biobank-scale data with genotype representation graphs (Рубрика #Data)

Наткнулся тут в рассылке от ACM (Association of Computing Machinery) на новость, что отлично демонстрирует то, что большие данные уже не такие большие:) Собственно, в генетике данных было всегда много после того, как ученые научились расшифровывать геном. Но эти данные надо было уметь где-то хранить и быстро лопатить для того, чтобы извлекать инсайты. И теперь ученые-исследователи из Корнелла разработали новый метод сжатия данных, который позволяет хранить большие геномные наборы данных на локальных компьютерах. Раньше эти данные весили сотни террабайт, а теперь они жмутся в гигабайты. Этот метод, названный Genotype Representation Graph (GRG), описан в статье, опубликованной 5 декабря 2024 года в Nature Computational Science. GRG использует графы для представления генотипов, что позволяет компактно и интуитивно кодировать информацию о геномах, а также выполнять вычисления без необходимости разжатия данных. Это делает анализ биобанковских данных более эффективным и менее затратным. В отличие от традиционных матричных представлений, GRG фиксирует связи между индивидами через общие мутации в их геномах. Метод был разработан для решения проблемы роста объема данных, который теперь может достигать петабайтов из-за увеличения доступности полногеномных последовательностей. GRG обеспечивает масштабируемость и точное представление данных, позволяя проводить сложные анализы, которые ранее были недоступны из-за высокой вычислительной стоимости.

Исследование уже привлекло внимание научного сообщества, и другие ученые начали тестировать метод на различных наборах данных. Работа поддержана грантом Национального института здравоохранения США.

#Data #Math #Software #Whitepaper

Evolution of software architecture with the co-creator of UML (Grady Booch) (Рубрика #Architecture)

Интересная серия подкаста с Гради Бучем, на книгах которого я учился в самом начале карьеры:) Гради придумал объектно-ориентированное проектирование и "метод Буча", который был предтечей UML. Дальше он вместе с Rumbaugh и Jacobson стал создателем языка UML (Unified Modeling Language), а также основал компанию Rational Rose, которую 20 лет назад купил IBM. Сразу после покупки Rational Гради стал Fellow внутри IBM и, судя по разговору в подкасте, именно это ни один раз его спасало от увольнения (как я понял Fellow нельзя так просто взять и уволить). В следующем году Гради исполнится уже 70 лет, но он бодр и полон сил.
Сам подкаст затрагивает следующие основные темы
1) Эволюция разработки ПО: разработка программного обеспечения - это история повышения уровня абстракции, где современные фреймворки и облачные сервисы стали ключевыми архитектурными решениями.
2) Роль архитектора изменилась: теперь архитектор решает системные проблемы и управляет более абстрактными уровнями системы.
3) Гради Буч примерно 20 лет назад получил предложение от Билла Гейтса стать Chief Architect всего Microsoft, но он отказался и сосредоточился на работе в IBM, в частности, в области искусственного интеллекта (помогал делать IBM Watson).
4) UML был создан для описания систем на разных уровнях абстракции и впоследствии стал стандартом. Несмотря на это, со временем его использование уменьшилось из-за сложности, которая появилась в версии 2+. Кстати, я действительно помню, как сложность скачком увеличилась и UML начали двигать от визуализации архитектуры в сторону языка прогаммирования, из которого можно генерить код на обычных языках
5) Среди современных вызовов есть следующие
- В bigtech компаниях иногда используют формальные методы для описания алгоритмов распределенных систем - это нужно для сложных случаев
- AI и LLM сейчас на коне, но Гради отмечает их потенциальные ограничения и опасности.
6) Эволюция архитектуры произошла из-за распределенных систем, которые потребовали новых методов обмена сообщениями между частями системы. А современные архитектурные решения часто зависят от предварительно созданных компонентов и API, что снижает риски и затраты на создание систем.
7) Напоследок Гради дает совет, что начинающим инженерам-программистам не стоит бояться экспериментировать и учиться новому.

#DistributedSystems #Architecture #Software #SystemDesign

CMMI (Capability Maturity Model Integration) (Рубрика #Management)

Когда я только начинал свою карьеру как инженер на слуху были модели зрелости для процессов разработки софта, а конкретнее CMMI. Сегодня я решил вспомнить историю этой модели и границы применимости, так как в последнее время я вижу большое увлечение разными моделями зрелости, например, KMM или ACMM. Я расскажу про них подробнее в следующий раз, а сегодня давайте поговорим про CMMI.

Изначальную версию CMM (Capability Maturity Model) разработал SEI (Software Engineering Institute) внутри Carnegie Mellon University в конце 1980х годов для Department of Defense. Цель была в том, чтобы улучшить практики разработки софта в этом ведомстве. К 2000 году CMM объединило в себе разные модели зрелости и расширилось на еще одно слово Integration, чтобы выйти в свет в виде модели CMMI и увеличить границы применимости.

Фреймворк строился вокруг концепций возможностей и зрелости
- Возможности относились к способностям организации достигнуть бизнес-цели через хорошо выстроенные процессы
- Зрелость отображала концепцию эволюции процессов во времени от ad-hoc до файнтюна и вылизывания выстроенных процессов:)

Фокус был на определении, имплементации и непрерывном улучшении процессов для обеспечения консистентности и эффективности. Фреймворк включал цели и лучшие практики для помощи в движении к лучшим процессам. В нем были следующие уровни зрелости
1) Initial: непредсказуемые и реактивные процессы (условно реакция по факту произошедшего события)
2) Managed: процессы планируются и выполняются с учетом политик
3) Defined: процессы хорошо описаны и стандартизированы
4) Quantitatively Managed: процессы измеримы и контролируются с учетом статистических методов
5) Optimizing: фокус на улучшении процессов через инновации

Адепты этого подхода упирали на плюсы фреймворка
1) Increased efficiency and productivity - это достигалось за счет стандартизации и оптимизации, что приводило к выравниванию workflow и лучшему распределению ресурсов
2) Quality improvement - предполагалось выравнивание процессов на требования заказчиков для повышения качества продуктов и удовлетворенности клиентов
3) Competitive advantage - достижение высоких уровней зрелости выделяло компании на рынке, что показывало их приверженность лучшим практикам (особенно актульно для сервисных компаний, что делают проекты на заказ)
4) Scalability - фреймворк позволял организациям масштабироваться по мере роста и наработки какой-то специфики

А среди недостатков выделяли
1) Complexity and cost - имплементаци CMMI была комплексной, требовала кучу времени и была дорогой из-за выделения значительных ресурсов, тренировок и документации
2) Rigidity - модель была негибкой, а также предотвращала внедрение новых практик и технология, что появлялись после ее внедрения
3) Bureaucracy - модель требовала значительного количества документов, что повышало уровень бюрократии и снижало гибкость и креативность (ака без бумажки ты букашка)
4) Lack of customizability - эта общая модель не всегда хорошо натягивалась на любую организацию (например, на bigtech компании, что взлетали в начале 2000-х), что ограничивало такие организации, если они пытались внедрить CMMI

В итоге, я видел внедрения CMMI в начале 2000х в сервисных компаниях (галерах), которые работали на рынке заказной разработки, но не слышал ни про одну bigtech компанию, принявшую эту модель. Я думаю, что причина в том, что на вопрос "А какую проблему мы решаем" эта модель CMMI не дает никакого ответа внутри продуктовой компании.

Я думаю, что надо фокусироваться на конкретных практиках, что решают конкретные проблемы, например,
- Процесс написания RFC и фиксация арх решений в ADR
- Ведение техрадара в организации
- Как работать с надежностью систем: observability, SLI/SLO/SLA, бюджет ошибок
- и так далее

Но вот в упор не могу понять на...я выбивать уровень 5 CMMI кроме как порадовать своего внутреннего бюрократа.

#Processes #Management #Metrics #Leadership #Software

ЦЕХ 4 - Урок #25 "Как стать брендом?. Эксперт — Игорь Манн" (Рубрика #Writing)

В очередном уроке Игорь Манн рассказывает про построение личного бренда. А уж он знает в этом толк:) Из этого урока я вынес следующие основные идеи

1) Личный маркетинг (что равно личному бренду) начинается с постановки цели и аудита самого себя. А еще он должен быть системным
2) Для этого можно задать себе четыре главных вопроса: кто вы, что вы делаете, как вы это делаете и как об этом узнают.
3) Личный бренд помогает целевой аудитории запомнить вас и выбрать ваши выступления, статьи и книги.
4) К этому вопросу надо подходить системно и работать параллельно над качеством и узнаваемостью
5) Вообще, это про инвестиции в себя, в образование, книги, внешний вид, благоприятные условия для жизни, работы и новых впечатлений
6) Игорь советует начать заниматься личным брендом сразу, а не тогда, когда вы набьете 10к часов в своей области и станете экспертом
7) В личном бренде важно постоянство - нельзя делать это иногда или по настроению
😍 Игорь говорит, что важно быть хорошим профессионалом, а уже затем хорошим человеком (это из серии, что хороший человек - это не профессия)
9) Автор отмечает необходимые навыки, которые нужны человеку доверие, коммуникабельность, умение общаться с ИИ, инициативность, тайм-менеджмент, личную эффективность, умение продавать и стрессоустойчивость, умение доводить дела до конца и проявлять упорство.
10) А дальше можно оценить свои навыки и понять, что требуется просто поддерживать, а над чем надо поработать
11) Игорь говорит о важности самопрезентации и предлагает упражнение "100 слов о себе", а потом экстремальные "3 слова о себе"
12) Для личностного роста нужны вызовы, которые делают тебя сильнее (прямо как по Ницше)
13) Секрет профессионального долголетия Игоря в том, что он постоянно занимался самообразованием и стремился стать номером один в своей области.
14) Важно иметь хорошие отношения в семье и уделять ей достаточно времени, а также окружать себя интересными людьми и работать над своим нетворкингомЁ
15) Можно сделать SWOT анализ самого себя и понять сильные и слабые стороны, а также расписать возможности и угрозы
16) Важно правильно работать с самооценкой и уметь преодолевать синдром самозванца
17) В этом могут помочь сравнения с более ранней версией самого себя или крутыми конкурентами
18) Также полезны профессиональные достижения и признание людей
19) Но для всего этого надо работать много, системно и по приоритетам
20) Для того, чтобы это сделать нужно уметь отвечать на вопрос "А зачем мне это нужно":)

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме
22. Взаимодействие с обозревателями, критиками и СМИ
23. Продвижение автора. Личный кейс
24. Продающие тексты

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up (Рубрика #Management)

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

Основные моменты этой статьи следующие

1. Вопрос онбординга очень важен - это процесс перехода нового инженера от новичка до продуктивного члена команды. Он важен как для индивидуального успеха, так и общекомандной производительности. Эффективный онбординг может сократить время "разгона" и улучшить долговременную продуктивность
2. Но адаптации инженеров часто мешают стандартные проблемы: недостаточная документация, отсутствие наставничества, неясные ожидания от инженера, а также сложные исходный код проектов. Эти факторы могут задерживать способность разработчика эффективно вносить вклад в работу команды
3. Для оценки качества онбординга надо уметь его измерять. По-факту, это измерение относиться к измерению продуктивности инженеров, но так как нас интересуют только результаты изменений в подходах к онбордингу, то авторы решили мерить не саму продуктивность, а изменения в ней.
4. Предыдущие подходы к ramp-up-time metrics включали сравнение параметров новчиков с опытными инженерами, но авторы этого исследования пошли своим путем, в котором им нужно было избежать сравнения между самими инженерами-новичками (иначе у них появилась бы мотивации геймить метрики и показывать как они здорово онбордятся). В итоге, они решили валидировать метрики-кандидаты относительно восприятия самих инженеров относительно того, насколько они заоонбордились в стандартные инженерные задачи.
5. Авторы исследовали 9 метрик-кандидатов и выбрали для дальнейшего анализа 3, в которых есть прогресс со временем работы и выход на некоторый стабильный уровень. Это метрики
- Active coding time per line of code (LOC)
- Reviewed LOC
- Submitted LOC
Дальше авторы аггрегировали новых инженеров по недельным когортам, а потом начали отслеживать сколько недель потребуется этим метрикам, чтобы выйти на стабильный уровень и оставаться там по-крайней мере 4 недели.
6. Потом авторы запустили опросы для инженеров (что работали меньше 40 недель). Этот опрос прошло порядка 3к инженеров. Вопросы были вокруг 17 стандартных задач, навроде, writing code, reviewing other people's code, running build and tests, finding examples of API use by others at Googe и так далее. Вопросы были про опыт вокруг этих задач в последнюю неделю и было 5 вариантов ответов от "Я не выполнял таких задач", до "Я уже выполняю такие задачи на максимально эффективном уровне по моим ожиданиям".
7. Авторы нашли стат значимую негативню корреляцию между "Active coding time per LOC" и самооценкой эффективности выполнения 15 из 17 задач. А 6 из 17 задач стат значимо были связаны с submitted LOC. Авторы взяли и эту метрику в качестве ramp-ut-time.
8. Авторы рассказали про результаты COVID-19 для ramp-up-time, так как у них данные начали собираться еще до всей петрушки.
- Для инженеров до COVID-19 средняя круизная скорость была в 2.5 раза выше, чем начальная. А для выходящих в COVID она стала всего 1.5x
- До COVID 19 инженеры выходили на стабильный submitted LOC за 12 недель, а после - за 18 недель
9. Авторы думают, что смогут использовать результаты исследования для помощи коллегам, которые запускают образовательные инициативы и треннинги для инженеров внутри компании

Авторы предлагают следующие рекомендации для улучшения онбординга
- Предоставляйте исчерпывающую документацию и четкие guidelines.
- Назначайте наставников или «buddies» для помощи новым разработчикам.
- Реализуйте структурированные программы адаптации с определенными этапами.
- Поощряйте обратную связь от новых сотрудников для совершенствования процессов адаптации.
- Инвестируйте в инструменты и системы, которые упрощают навигацию по исходникам и рабочим процессам.

P.S.
Разводящий пост с обзорами всех статей из серии доступен здесь.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

ЦЕХ 4 - Урок #26 "Работа автора с литературным агентом. Эксперт — Галина Бочарова" (Рубрика #Writing)

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

1. Зарубежом важность литературных агентов достаточно велика, особенно в США и Европе, где они играют ключевую роль. В России их влияние пока ограничено.
2. Но даже на российском рынке виден рост числа агентов - это связано с интересом к переводным книгам, ростом уровня русскоязычных авторов и развитием цифровых платформ, таких как Bookmate.
3. Авторы могут сотрудничать с агентами для продвижения книг, но это не всегда необходимо. Важно выбирать подходящие издательства и правильно готовить рукописи, но это могут делать сами авторы самостоятельно
4. Договоры с издательствами требуют внимательного изучения. Особое внимание следует уделять правам на экранизации, переводы и театральные постановки, которые могут приносить значительный доход.
5. Продажа прав на кино, переводы и зарубежные рынки может быть сложной, но прибыльной. Агенты активно работают с продюсерами и зарубежными партнёрами.
6. Агенты получают комиссию (обычно 20%) от авансов, роялти и других доходов. Дополнительный доход возможен через цифровые сервисы и продюсирование проектов.
7. Издательства могут требовать активного участия автора в продвижении. Агент помогает в этом процессе, но автор также должен быть вовлечён.
8. Агенты готовы работать с новичками, если видят потенциал. Однако это требует больших усилий и рисков.
9. На рынке есть отдельно агенты, а также скауты. Агент представляет интересы автора за комиссию, а скаут работает на издательство за фиксированную оплату.

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме
22. Взаимодействие с обозревателями, критиками и СМИ
23. Продвижение автора. Личный кейс
24. Продающие тексты
25. Как стать брендом?

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

How to Learn: Unlocking the Brain's Secrets • Barbara Oakley & Charles Humble • GOTO 2024 (Рубрика #SelfDevelopment)

Интересный подкаст клуба goto, в котором Чарльз Хаммел берет интервью у Барбары Оукли. Барбара автор очень популярного курса "Learning How to Learn" на Coursera. К этому курсу Барбара написала книгу "Думай как математик" ("A Mind For Numbers"), про которую я раньше уже рассказывал. А в этом подкасте было поднято много интересных тем

1. Для разных предметов эффективны разные методы, напрмер, для изучения языков и математики
2. Интересно, что Барбара сама прошла путь от ученого-лингвиста до профессора по инженерии. Книга "Мышление в цифрах", что я уже упоминал выше посвящена методам обучения, подходящим для STEM-дисциплин.
3. Сейчас есть кризис повторяемости результатов исследований в общем, а также исследований в образовании. Барбара приводит конкретные примеры, когда популярные, но неэффективные методы обучения сопровождались научными статьями, результаты которых не удалось повторить
4. Барбара рассказывает о двух работах мозга: сосредоточенный и рассеянный. Для эффективного обучения нужно уметь переключаться между режимами
5. Физические упражнения помогают в обучении, повышая когнитивные способности и успеваемость
6. Тренировки помогают вырабатывать нейротрофический фактор мозга BDNF, который помогает нейронам соединяться друг с другом, а также способствует лучшему усвоению знаний
7. Сон помогает мозгу обрабатывать и закреплять новые знания, а правильное питание, включая растения, орехи и темный шоколад, способствует здоровью мозга.
8. Осознанная практика помогает в обучении - важно практиковать выполнение сложных задач, так как рост на стандартных задачах без вызовов гораздо медленнее
9. Для обучения, как и для работы важна психологическая безопасности, которая означает уважение и способность бросать вызов. В эффективных командах важно бросать вызов и обсуждать неудобные темы. Подробнее можно почитать про проект Аристотель - тут ребята из Google исследовали факторы, что делают команды эффективными и самым важным фактором стала psychological safety
10. Для обучения важно как понимать как работает working и long-term memory. Рабочая память позволяет временно удерживать информацию. Долговременная память хранит информацию надолго. Гиппокамп усиливает память и взаимодействует с рабочей памятью. Гиппокамп усиливает память и взаимодействует с рабочей памятью. Подробнее про типы памяти можно почитать в книге "The Programmer's Brain", о которой я уже раньше рассказывал
11. Гиппокамп быстро формирует и разрушает связи в мозге. Зубрежка перед тестом неэффективна, так как связи быстро исчезают. Повторение с интервалами помогает лучше запоминать информацию.
12. Память хранится в соединениях между нейронами. Эти связи формируют память, как биты в компьютере.
13. Метафоры помогают связывать концепции и понимать новые идеи. А также они помогают лучше их запоминать
14. Барбара рассказывает как она использует AI в обучении через суммаризацию сложных документов перед началом их изучения.
15. Учителя должны обучать студентов эффективному обучению. А AI может помочь им в преподавании, но для этого сами учителя должны быть готовы к новым технологиям
16. Наши знания ржавеют и воспоминания исчезают, если их не использовать. Дендритные отростки могут отмирать, если не использовать навыки. Использование знаний помогает восстановить забытые навыки.
17. Есть еще много областей в исследовании мозга, которые покрыты туманом неизвестного и поэтому тут можно и нужно проводить дальнейшие исследдования, что принесут нам понимание и удивительные результаты

P.S.
Если этот подкаст вам понравился, то могут понравиться материалы из моего предыдущего поста с подборкой материалов на тему работы мозга.

#SelfDevelopment #Brain #PopularScience #Thinking

Вычислительная машина и мозг (The Computer and the Brain) (Рубрика #PopularScience)

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

Сама книга до сих пор актуальна, а в свое время была пророческой. Она состоит из трех частей
1) Первая часть посвящена устройству вычислительных машин: памяти, хранимому коду программы, аналоговым и цифровым элементам.
2) Вторая часть исследует мозг с точки зрения нейронных сетей, памяти и логической глубины.
3) Неоформленная третья часть касается выводов о роли кода и языка в системах36.

Основные идеи:
1) Сравнение мозга и компьютера
Фон Нейман рассматривает мозг как вычислительный механизм, сравнивая его с современными ему компьютерами. Он анализирует аналоговые и цифровые аспекты работы мозга и машин, начиная с базовых элементов — нейронов и транзисторов. Автор исследует различия и сходства в архитектуре, памяти, обработке информации и точности работы мозга и ЭВМ. По-факту, он комбинирует теорию информации, начало которой положил Клод Шеннон, а также идею про абстрактный вычислитель от Алана Тьюринга (так называемая машина Тьюринга).
2) Ключевыми вопросы
- Является ли мозг аналоговым или цифровым автоматом? (как мы помним в 50-е годы 20 века знаний о мозге были сильно, чем сейчас)
- Может ли искусственный интеллект достичь уровня человеческого разума?
Фон Нейман, беря за основу идею машины Тьюринга, приходит к выводу, что различия между ними минимальны, несмотря на разницу в строительных блоках.
3) Роль языка и информации
В конце книги поднимается вопрос о том, какой язык использует мозг для обработки информации. Фон Нейман предполагает, что этот язык может быть менее логически строгим, чем привычные математические системы. Мне кажется, что эта часть обрывается затравкой - Джон не смог дописать свои лекции из-за болезни, которую уже победить не смог.

Эта книга интересна как попытка объдинить биологию и информатику в рамках кибернетики еще 70 лет назад, а также показала путь к междисциплинарному подходу к изучению интеллекта — как естественного, так и искусственного. Интересно, что Джон фон Нейман сделал еще много хорошего в разных дисциплинах, среди которых

1) Архитектура компьютеров: Разработал концепцию фон Неймановской архитектуры, которая легла в основу современных компьютеров. Принципы этой архитектуры следующие
- Единое хранилище памяти для программ и данных
- Процессор. Процессор предназначен для обработки данных и выполнения команд из памяти
- Последовательное выполнение команд. Команды выполняются одна за другой, в строгой последовательности
- Ввод-вывод. Устройства ввода-вывода обеспечивают интерфейс между компьютером и внешним миром.
- Адресуемая память. Все данные и инструкции имеют уникальные адреса в памяти, что позволяет процессору быстро получать доступ к нужной информации.
2) Теория игр: Совместно с Оскаром Моргенштерном заложил основы теории игр. Его теорема о минимаксе стала фундаментом для изучения стратегического поведения в экономике, политике и других областях. Интересно, что этой работой заинтересовался Джон Нэш, который продолжил копать тему теории игр, а потом получил за нее Нобелевскую премию
3) Квантовая механика: Внёс вклад в математическое обоснование квантовой механики, разработав алгебру фон Неймана и концепцию гильбертова пространства для описания квантовых систем.
4) Манхэттенский проект: Участвовал в разработке атомной бомбы, предложив концепцию взрывных линз для симметричного сжатия плутониевого ядра.
5) Клеточные автоматы: Разработал теорию клеточных автоматов и концепцию самовоспроизводящихся систем, что стало основой для моделирования сложных систем и развития искусственного интеллекта.

Подробнее про Джона можно прочитать в книге "Человек из будущего" (она у меня на очереди) или в интересной статье с кратким обзором

#SelfDevelopment #Brain #PopularScience #Thinking #Architecture