Конференция "Прикладное системное мышление"-2020, день второй
Во второй день мы практически не потеряли в численности, людей в пике была та же сотня (первый день я обсуждал в https://ailev.livejournal.com/1508452.html). Доклады были по сравнению с прошлыми годами несравненно сильнее в части методологии, это работает наш упор на системное мышление и онтологику: разговор об инженерии и менеджменте на крепком методологическом основании становится сразу серьёзным, без размахивания руками и ссылок на личное чутьё в качестве аргумента. Видео (кроме двух последних докладов) появится в ближайшее время в https://yadi.sk/d/mzj4OrkwOnNrdQ
Вот мои заметки по основным замеченным мной проблемам:
1. Неразличение уровней формализации на спектре мышления и используемой нотационной техники.
Псеводкод, текст с формальными идентификаторами, текст, код, схема, диаграмма -- всё это замешивается в невообразимую кучу. Текст полностью формальный и текст на естественном языке сравниваются с диаграммами, схема тут не поймёшь -- диаграмма или набор концептов (формальный или не очень формальный, "схемоид" на спектре формальности мышления, т.е. выражаемый в языке обычно всякими отходами от theory theory). Явная дыра в нашем курсе онтологики, прямое техническое задание заплатки к курсу. Но и другие курсы должны обратить у нас на это внимание, прежде всего курс "Системная инженерия", где Вячеслав Мизгулин поднял проблему необходимости текстовых описаний в инженерии и отметил в своём докладе недостаточность методологических материалов по стыку схематизации-рендеринга в части концептуализации и в части нотационной инженерии. Отдельно концептуализации разного уровня формальности, отдельно нотационные техники текстовые (с разной степени вменяемости синтаксисами!), отдельно нотационные техники диаграммные. Ну ведь правда же, когда говорят "псевдокод", то аспекты свободы концептуализации или свободы синтаксиса имеются ввиду, или обе свободы сразу -- непонятно.
Мне больше всего понравился кейс Антона Меркулова, где он для выражения архитектуры предприятия последовательно пробовал ArchiMate, собственную диаграммную нотацию (на основе существенно более компактной нотации из функциональных описаний для электроники) и остановился на свободном тексте с типизированными понятиями системного подхода сущностями, именованными на CamelCase (https://ru.wikipedia.org/wiki/CamelCase ), например, Роль_ПерекатчикСолнцаВручную. Тип позволяет делать проверки (например, не путаются ли роли и должности), идентификатор выражает концепт, а отношения и менее формальные понятия выражаются текстом. Дальше можно в этот "текстокод" вводить потихоньку другие конструкции. Ещё пара проектов демонстрировала текстовые архитектуры вместо диаграммных техник, так что процесс пошёл. Кирилл Гайдамака сделал замечание, что текущие языки требований тоже по факту представляют собой "текстокод" -- синтаксис задаётся текстовыми шаблонами, терминология выделяется из текста, но текст таки остаётся свободным, язык не формальный, а естественный. Но в этом "текстокоде" (боюсь, боюсь писать "псевдокод"!) люди с удовольствием делают правки (ибо чётко видны последствия правок, формализма достаточно), в отличие от полностью свободного литературного текста, с которым они отказываются работать. Давний спор (14 февраля 2019 года на заседании Русского отделения INCOSE я спросил, почему в одном и том же проекте одни и те же люди отказывались работать с текстами у Александра Лучкова, и отказывались работать с картинками у Кирилла Гайдамаки -- https://ailev.livejournal.com/1465997.html, и там ссылка на видео) получил разрешение: слово "текст" не отражало степень формальности этого текста, а "картинка" также не отражала степень формальности -- они отсылали только к типу нотации (и даже не к нотации, ибо для "текста" и "картинки" могли быть десятки нотаций для самых разных уровней формализации и разных вариантов концептуализаций/онтик предметной области). Теперь понятно, о чём нужно было спрашивать дальше!
Вопрос про "полнотекстовое на естественном языке представление против формального текста" обсуждался лет десять назад с Donald Firesmith (он приезжал к нам в Москву и резко выступал против того, что архитектура выражается только формальными языками, настаивая на необходимость текстовых документов. Но он как раз из "старых системных инженеров", о которых говорил Вячеслав в своём докладе). И этот же вопрос лишней формализации буквально вчера всплыл в закрытом обсуждении в фейсбуке (чем плохо тегирование по сравнению с текстами), и я там тоже отметился: 11 лет назад я писал про эту вакханалию лишней(т.е. не ведущей к проверкам, вычислениям или чему-то осмысленному) формализации/тегирования в https://ailev.livejournal.com/715272.html, и привёл байку Моя любимая байка про IBM Watson, который выиграл Jeopardy!, причём я лично участвовал в той встрече онтологов, где был этот диалог. Там спросили, почему люди в IBM не кодируют википедию в виде онтологии/knowledge graph (по сути -- не формализуют википедию), а используют полнотекстовую обработку? Ответ был таков, что вопросы они не могут предопределить, а любое сжатие информации/формализация/схематизация/моделирование -- потеря ответа на какой-то неожиданный вопрос, ибо вопрос может быть про важное для спрашивающего, но неважное для формализатора. На удивление онтологов, что работа с полными текстами без их кодирования/сжатия в виде формальных представлений требует диких вычислительных мощностей, они ответили "так ровно поэтому IBM Watson -- это прежде всего суперкомпьютер!". Все эти соображения остаются верными и сегодня, когда говорим о knowledge graphs. Если не очень понятна цель, то чересчур сжатые формализации быстро оказываются бесполезными в тот момент, когда цель становится ясной и оказывается не той, которая была при формализации.
Вот в требованиях и архитектуре вы не знаете, какие вопросы могут быть у людей, и что именно люди будут искать в ваших описаниях, и на каком уровне формальности они будут это искать. Поэтому не нужно стремиться всё архитектурные описания делать в виде формальных моделей, особенно если вы не собираетесь с ними дальше работать формально (скажем, обрабатывать каким-то алгоритмом), а читать их дальше будут люди.
Особенно обидно было то, что неудачные нотации закрывают хорошие концептуализации. Так, всё направление GORE (goal-oriented requirements engineering) появилось как указание на необходимость учитывать человеческие цели (ролевые интересы, предпочтения и намерения по реализации предпочтений) в инженерии требований, особенно разбираться с возникающими конфликтами между стейкхолдерскими ролями: разбираться не столько с требованиями, сколько с проектными ролями, которые тянут эти требования каждый в свою сторону в силу своих предпочтений. Моделями требований начали называть представления, в которых кроме требований указывалась трасса к проектным ролям и их конфликтам. Но у языков для моделей требований с их графическим представлением не нашлось много интересных кейсов по моделям требований (хотя тот же ArchiMate явно указывает, что учитывает фреймворк i* в своей концептуализации, то есть он в какой-то мере язык GORE, т.е. включает подъязык требований -- вот тут у меня есть абзац на эту тему в разговоре про SysArchi и там пара ссылок: https://ailev.livejournal.com/1454948.html).
Отдельно нужно подумать, как развести формализационный и нотационный аспекты в рендеринге (ибо как я сейчас понимаю, в паре "схематизация-рендеринг" крепко перемешаны оба аспекта проблемы, и нужно особо оговаривать, что имеется ввиду -- см., например, последнюю дискуссию об этом тут: https://ailev.livejournal.com/1494762.html). Онтологам и коммуникаторам может быть там всё ясно, но когда дело дойдёт до системных инженеров, лучше бы это "всё ясно" дополнительно разъяснять на пальцах, разводя формализационный и нотационный аспекты явно и давая примеры.
2. Редукционизм в мышлении разработчиков
Несколько докладов говорили о разрыве коммуникации между системным архитектором и рядовыми разработчиками. Этот разрыв каждый раз оказывался тем или иным изводом разрыва между редукционистским (в голове нет понимания идеи системных уровней) и системным (в голове есть идея системных уровней) представлением систем в проекте. Вопрос в том, что делать в этой ситуации: учить разработчиков системному мышлению? Или как-то автогенерировать "рабочку" (в том числе программный код) из архитектурных артефактов и тем самым просто выкинуть разработчиков (умощнить архитектора автоматизацией, а быдлокодеров-редукционистов сократить)?
Моё мнение -- нужно научиться быстро доносить идею системных уровней до разработчиков (я вот сейчас как раз занимаюсь ускорением этого донесения, пошли первые результаты). Ибо химии на алхимическом языке не научишь. Нельзя архитектурное многоуровневое описание донести до разработчиков в редукционистском языке. Но для этого архитекторам нужно чётко понимать, в чём проблема их общения с разработчиками и в чём проблемы их собственного инструментария в этой части (поскольку дискуссия редукционистов с системщиками была лет пятьдесят назад, то мало кто помнит, с чего там начиналось и чем закончилось -- поэтому как лечить эту ментальную чуму никто не помнит). Что у самих "системных" архитекторов тут тоже рыльце в пушку -- это мне тоже понятно, у меня на каждом потоке один или двое системных архитектора, и после курса они мне доверительно обычно говорят, что только после курса поняли, чем они на самом деле занимались. Я и сам такой: в начале перестройки я гордо называл себя "системный архитектор", не понимания ни значения слова "системный", ни системного характера архитектурного моделирования, и уж тем более не смог бы внятно рассказать разницу между системными и редукционистскими описаниями. Вот об этом нужно говорить явно, и учить разработчиков "через нехочу".
Учить не только разработчиков, конечно, но и всех остальных. Архитектура -- это коммуникационный артефакт, и её нужно уметь не только архитекторам писать, но всем остальным читать и понимать. Для этого нужно понимать принципы архитектурной концептуализации, то есть с мереологией нужно разбираться и разработчикам, и архитекторам, и менеджерам, и всем вообще: это мыслительная компетенция "бакалавриат" для всех, а не только "магистратура архитеторов". Можно не знать слова "мереология", но вот отношения "часть-целое" отслеживать в разбиениях по разным принципам нужно уметь всем.
Вторая засада в этой проблеме непоняток между разработчиками и архитекторами именно софта -- это длинная цепочка описаний: архитектура описывает программу, код тоже описывает программу, которая описывает домен. Описывает ли архитектура домен и что мы там делаем с DDD? Ответы тут очень, очень невнятны.
3. Проблема мереологии софта
Мереология -- это подраздел онтологии, занимающийся отношениями частей и целого. Для софта:
-- отношения "вызова" путаются с отношениями "часть-целое" (я немного затронул этот вопрос в "мереологии практик мышления": https://ailev.livejournal.com/1508228.html).
-- мереология описаний (кода), мереология софта в момент исполнения, мереология данных, мереология домена и их трассировки друг ко другу -- это всё разное. Сегодня это не очень различается в части работы с системными уровнями, а надо различать. А то обсуждаются системные уровни непонятно чего. Помним при этом, что функциональные разбиения -- это разбиения в момент работы/operations, и они связаны с назначением/функцией (а она в свою очередь упирается в то, что это даёт для моделирования софтом домена, и если не просматривается целевой домен, то что-то с функциональностью не так, архитектура не архитектура). Мой опыт таков, что софтовые архитекторы испытывают огромные трудности с функциональными описаниями и мереологией функциональных объектов! Впрочем, архитекторы предприятий тоже (это ж разговор про практики, труднопонимаемые "процессные объекты").
-- мереология платформ может быть выстроена разным образом. Например, сам "вызов" может быть превращён в 4D объект "сессия" и сервер/платформа и клиент/надстройка над платформой могут выступить взаимодействующими объектами на одном уровне (как показано было в великолепном архитектурном докладе Ивана Подобеда), или можно идти традиционным путём "стеков", где платформа/сервер уровнем ниже её надстройки/клиентов -- и так на много уровней вверх. И в одном и в другом случае можно развести команды (по платформенным уровням или по модулям в рамках одного уровня в разных мереологических вариантах концептуализации домена), но какие-то примеры таких мереологических развилок в моделировании можно было бы рассмотреть в ходе обучения системному мышлению. Повторюсь, обучать нужно не только архитекторов, но и всех остальных.
Я написал в чат спикеров конференции, что считаю сегодняшний день крайне полезным. Почему? Да вот же -- три пункта, которые я тут записал (1. Путаница между формализационным и нотационным аспектами при обсуждении моделей. 2. Редукционизм разработчиков. 3.Мереология софта), это же довольно точные задания на исследования преподавателям наших курсов -- и это не абстрактные исследования из разряда "интересненько", а исследования в ответ на реальные проблемы, которые пришли из производственной жизни. Когда результаты этих исследований попадут в курсы, наши выпускники будут способны замечать проблемы из этих пунктов в своих проектах и они будут знать, в каком направлении искать решение этих проблем. Мир станет чуточку лучше. Так что очень полезно сегодня посидели, я очень доволен.
Наконец-то собрался попробовать в "Братьях Караваевых" калитку с уткой (калитки -- это такие финские пирожки. Похоже по конструкции на хачапури по-аджарски, только тесто слоёное, вместо сыра картошка, а вместо яйца утка. Понятно ведь описал?!). Очень вкусно, рекомендую! За едой беседовал на два фронта: за соседними столами обедали друзья, которые заканчивали сегодня очередной поток "Системного фитнеса". А после конференции я зашёл в зал, где этот "Системный фитнес" только-только закончился, и таки встал на руки: сделал колесо. Впервые после перерыва в три десятка лет. Показывать это ещё совсем нельзя (к земле я был явно не перпендикулярен, это попало на видео, и там градусов шестьдесят -- для первого раза после трёх десятков лет это ОК, но и хвастаться нельзя). Так что я ещё и на двух мероприятиях Школы сегодня побывал -- на конференции и на "Системном фитнесе"!
UPDATE: обсуждение в чате блога с https://t.me/ailev_blog_discussion/1942
Вот мои заметки по основным замеченным мной проблемам:
1. Неразличение уровней формализации на спектре мышления и используемой нотационной техники.
Псеводкод, текст с формальными идентификаторами, текст, код, схема, диаграмма -- всё это замешивается в невообразимую кучу. Текст полностью формальный и текст на естественном языке сравниваются с диаграммами, схема тут не поймёшь -- диаграмма или набор концептов (формальный или не очень формальный, "схемоид" на спектре формальности мышления, т.е. выражаемый в языке обычно всякими отходами от theory theory). Явная дыра в нашем курсе онтологики, прямое техническое задание заплатки к курсу. Но и другие курсы должны обратить у нас на это внимание, прежде всего курс "Системная инженерия", где Вячеслав Мизгулин поднял проблему необходимости текстовых описаний в инженерии и отметил в своём докладе недостаточность методологических материалов по стыку схематизации-рендеринга в части концептуализации и в части нотационной инженерии. Отдельно концептуализации разного уровня формальности, отдельно нотационные техники текстовые (с разной степени вменяемости синтаксисами!), отдельно нотационные техники диаграммные. Ну ведь правда же, когда говорят "псевдокод", то аспекты свободы концептуализации или свободы синтаксиса имеются ввиду, или обе свободы сразу -- непонятно.
Мне больше всего понравился кейс Антона Меркулова, где он для выражения архитектуры предприятия последовательно пробовал ArchiMate, собственную диаграммную нотацию (на основе существенно более компактной нотации из функциональных описаний для электроники) и остановился на свободном тексте с типизированными понятиями системного подхода сущностями, именованными на CamelCase (https://ru.wikipedia.org/wiki/CamelCase ), например, Роль_ПерекатчикСолнцаВручную. Тип позволяет делать проверки (например, не путаются ли роли и должности), идентификатор выражает концепт, а отношения и менее формальные понятия выражаются текстом. Дальше можно в этот "текстокод" вводить потихоньку другие конструкции. Ещё пара проектов демонстрировала текстовые архитектуры вместо диаграммных техник, так что процесс пошёл. Кирилл Гайдамака сделал замечание, что текущие языки требований тоже по факту представляют собой "текстокод" -- синтаксис задаётся текстовыми шаблонами, терминология выделяется из текста, но текст таки остаётся свободным, язык не формальный, а естественный. Но в этом "текстокоде" (боюсь, боюсь писать "псевдокод"!) люди с удовольствием делают правки (ибо чётко видны последствия правок, формализма достаточно), в отличие от полностью свободного литературного текста, с которым они отказываются работать. Давний спор (14 февраля 2019 года на заседании Русского отделения INCOSE я спросил, почему в одном и том же проекте одни и те же люди отказывались работать с текстами у Александра Лучкова, и отказывались работать с картинками у Кирилла Гайдамаки -- https://ailev.livejournal.com/1465997.html, и там ссылка на видео) получил разрешение: слово "текст" не отражало степень формальности этого текста, а "картинка" также не отражала степень формальности -- они отсылали только к типу нотации (и даже не к нотации, ибо для "текста" и "картинки" могли быть десятки нотаций для самых разных уровней формализации и разных вариантов концептуализаций/онтик предметной области). Теперь понятно, о чём нужно было спрашивать дальше!
Вопрос про "полнотекстовое на естественном языке представление против формального текста" обсуждался лет десять назад с Donald Firesmith (он приезжал к нам в Москву и резко выступал против того, что архитектура выражается только формальными языками, настаивая на необходимость текстовых документов. Но он как раз из "старых системных инженеров", о которых говорил Вячеслав в своём докладе). И этот же вопрос лишней формализации буквально вчера всплыл в закрытом обсуждении в фейсбуке (чем плохо тегирование по сравнению с текстами), и я там тоже отметился: 11 лет назад я писал про эту вакханалию лишней(т.е. не ведущей к проверкам, вычислениям или чему-то осмысленному) формализации/тегирования в https://ailev.livejournal.com/715272.html, и привёл байку Моя любимая байка про IBM Watson, который выиграл Jeopardy!, причём я лично участвовал в той встрече онтологов, где был этот диалог. Там спросили, почему люди в IBM не кодируют википедию в виде онтологии/knowledge graph (по сути -- не формализуют википедию), а используют полнотекстовую обработку? Ответ был таков, что вопросы они не могут предопределить, а любое сжатие информации/формализация/схематизация/моделирование -- потеря ответа на какой-то неожиданный вопрос, ибо вопрос может быть про важное для спрашивающего, но неважное для формализатора. На удивление онтологов, что работа с полными текстами без их кодирования/сжатия в виде формальных представлений требует диких вычислительных мощностей, они ответили "так ровно поэтому IBM Watson -- это прежде всего суперкомпьютер!". Все эти соображения остаются верными и сегодня, когда говорим о knowledge graphs. Если не очень понятна цель, то чересчур сжатые формализации быстро оказываются бесполезными в тот момент, когда цель становится ясной и оказывается не той, которая была при формализации.
Вот в требованиях и архитектуре вы не знаете, какие вопросы могут быть у людей, и что именно люди будут искать в ваших описаниях, и на каком уровне формальности они будут это искать. Поэтому не нужно стремиться всё архитектурные описания делать в виде формальных моделей, особенно если вы не собираетесь с ними дальше работать формально (скажем, обрабатывать каким-то алгоритмом), а читать их дальше будут люди.
Особенно обидно было то, что неудачные нотации закрывают хорошие концептуализации. Так, всё направление GORE (goal-oriented requirements engineering) появилось как указание на необходимость учитывать человеческие цели (ролевые интересы, предпочтения и намерения по реализации предпочтений) в инженерии требований, особенно разбираться с возникающими конфликтами между стейкхолдерскими ролями: разбираться не столько с требованиями, сколько с проектными ролями, которые тянут эти требования каждый в свою сторону в силу своих предпочтений. Моделями требований начали называть представления, в которых кроме требований указывалась трасса к проектным ролям и их конфликтам. Но у языков для моделей требований с их графическим представлением не нашлось много интересных кейсов по моделям требований (хотя тот же ArchiMate явно указывает, что учитывает фреймворк i* в своей концептуализации, то есть он в какой-то мере язык GORE, т.е. включает подъязык требований -- вот тут у меня есть абзац на эту тему в разговоре про SysArchi и там пара ссылок: https://ailev.livejournal.com/1454948.html).
Отдельно нужно подумать, как развести формализационный и нотационный аспекты в рендеринге (ибо как я сейчас понимаю, в паре "схематизация-рендеринг" крепко перемешаны оба аспекта проблемы, и нужно особо оговаривать, что имеется ввиду -- см., например, последнюю дискуссию об этом тут: https://ailev.livejournal.com/1494762.html). Онтологам и коммуникаторам может быть там всё ясно, но когда дело дойдёт до системных инженеров, лучше бы это "всё ясно" дополнительно разъяснять на пальцах, разводя формализационный и нотационный аспекты явно и давая примеры.
2. Редукционизм в мышлении разработчиков
Несколько докладов говорили о разрыве коммуникации между системным архитектором и рядовыми разработчиками. Этот разрыв каждый раз оказывался тем или иным изводом разрыва между редукционистским (в голове нет понимания идеи системных уровней) и системным (в голове есть идея системных уровней) представлением систем в проекте. Вопрос в том, что делать в этой ситуации: учить разработчиков системному мышлению? Или как-то автогенерировать "рабочку" (в том числе программный код) из архитектурных артефактов и тем самым просто выкинуть разработчиков (умощнить архитектора автоматизацией, а быдлокодеров-редукционистов сократить)?
Моё мнение -- нужно научиться быстро доносить идею системных уровней до разработчиков (я вот сейчас как раз занимаюсь ускорением этого донесения, пошли первые результаты). Ибо химии на алхимическом языке не научишь. Нельзя архитектурное многоуровневое описание донести до разработчиков в редукционистском языке. Но для этого архитекторам нужно чётко понимать, в чём проблема их общения с разработчиками и в чём проблемы их собственного инструментария в этой части (поскольку дискуссия редукционистов с системщиками была лет пятьдесят назад, то мало кто помнит, с чего там начиналось и чем закончилось -- поэтому как лечить эту ментальную чуму никто не помнит). Что у самих "системных" архитекторов тут тоже рыльце в пушку -- это мне тоже понятно, у меня на каждом потоке один или двое системных архитектора, и после курса они мне доверительно обычно говорят, что только после курса поняли, чем они на самом деле занимались. Я и сам такой: в начале перестройки я гордо называл себя "системный архитектор", не понимания ни значения слова "системный", ни системного характера архитектурного моделирования, и уж тем более не смог бы внятно рассказать разницу между системными и редукционистскими описаниями. Вот об этом нужно говорить явно, и учить разработчиков "через нехочу".
Учить не только разработчиков, конечно, но и всех остальных. Архитектура -- это коммуникационный артефакт, и её нужно уметь не только архитекторам писать, но всем остальным читать и понимать. Для этого нужно понимать принципы архитектурной концептуализации, то есть с мереологией нужно разбираться и разработчикам, и архитекторам, и менеджерам, и всем вообще: это мыслительная компетенция "бакалавриат" для всех, а не только "магистратура архитеторов". Можно не знать слова "мереология", но вот отношения "часть-целое" отслеживать в разбиениях по разным принципам нужно уметь всем.
Вторая засада в этой проблеме непоняток между разработчиками и архитекторами именно софта -- это длинная цепочка описаний: архитектура описывает программу, код тоже описывает программу, которая описывает домен. Описывает ли архитектура домен и что мы там делаем с DDD? Ответы тут очень, очень невнятны.
3. Проблема мереологии софта
Мереология -- это подраздел онтологии, занимающийся отношениями частей и целого. Для софта:
-- отношения "вызова" путаются с отношениями "часть-целое" (я немного затронул этот вопрос в "мереологии практик мышления": https://ailev.livejournal.com/1508228.html).
-- мереология описаний (кода), мереология софта в момент исполнения, мереология данных, мереология домена и их трассировки друг ко другу -- это всё разное. Сегодня это не очень различается в части работы с системными уровнями, а надо различать. А то обсуждаются системные уровни непонятно чего. Помним при этом, что функциональные разбиения -- это разбиения в момент работы/operations, и они связаны с назначением/функцией (а она в свою очередь упирается в то, что это даёт для моделирования софтом домена, и если не просматривается целевой домен, то что-то с функциональностью не так, архитектура не архитектура). Мой опыт таков, что софтовые архитекторы испытывают огромные трудности с функциональными описаниями и мереологией функциональных объектов! Впрочем, архитекторы предприятий тоже (это ж разговор про практики, труднопонимаемые "процессные объекты").
-- мереология платформ может быть выстроена разным образом. Например, сам "вызов" может быть превращён в 4D объект "сессия" и сервер/платформа и клиент/надстройка над платформой могут выступить взаимодействующими объектами на одном уровне (как показано было в великолепном архитектурном докладе Ивана Подобеда), или можно идти традиционным путём "стеков", где платформа/сервер уровнем ниже её надстройки/клиентов -- и так на много уровней вверх. И в одном и в другом случае можно развести команды (по платформенным уровням или по модулям в рамках одного уровня в разных мереологических вариантах концептуализации домена), но какие-то примеры таких мереологических развилок в моделировании можно было бы рассмотреть в ходе обучения системному мышлению. Повторюсь, обучать нужно не только архитекторов, но и всех остальных.
Я написал в чат спикеров конференции, что считаю сегодняшний день крайне полезным. Почему? Да вот же -- три пункта, которые я тут записал (1. Путаница между формализационным и нотационным аспектами при обсуждении моделей. 2. Редукционизм разработчиков. 3.Мереология софта), это же довольно точные задания на исследования преподавателям наших курсов -- и это не абстрактные исследования из разряда "интересненько", а исследования в ответ на реальные проблемы, которые пришли из производственной жизни. Когда результаты этих исследований попадут в курсы, наши выпускники будут способны замечать проблемы из этих пунктов в своих проектах и они будут знать, в каком направлении искать решение этих проблем. Мир станет чуточку лучше. Так что очень полезно сегодня посидели, я очень доволен.
Наконец-то собрался попробовать в "Братьях Караваевых" калитку с уткой (калитки -- это такие финские пирожки. Похоже по конструкции на хачапури по-аджарски, только тесто слоёное, вместо сыра картошка, а вместо яйца утка. Понятно ведь описал?!). Очень вкусно, рекомендую! За едой беседовал на два фронта: за соседними столами обедали друзья, которые заканчивали сегодня очередной поток "Системного фитнеса". А после конференции я зашёл в зал, где этот "Системный фитнес" только-только закончился, и таки встал на руки: сделал колесо. Впервые после перерыва в три десятка лет. Показывать это ещё совсем нельзя (к земле я был явно не перпендикулярен, это попало на видео, и там градусов шестьдесят -- для первого раза после трёх десятков лет это ОК, но и хвастаться нельзя). Так что я ещё и на двух мероприятиях Школы сегодня побывал -- на конференции и на "Системном фитнесе"!
UPDATE: обсуждение в чате блога с https://t.me/ailev_blog_discussion/1942