?

Log in

No account? Create an account
Лабораторный журнал
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 20 most recent journal entries recorded in Anatoly Levenchuk's LiveJournal:

[ << Previous 20 ]
Wednesday, October 17th, 2018
3:32 pm
lytdybr
Я хожу в эти дни довольный: текст про новую коннективистскую семантику как языковые модели и модели/эмбеддинги знаниевых графов (https://ailev.livejournal.com/1449229.html) для меня абсолютно программный -- он тесно связал и мою работу над разделением фундаментального образования и кругозоров, и тематику SysMoLan, и тематику развития методов AI. По факту -- это следующий шаг в размышлениях по поводу мышления после завершения "Визуального мышления". Для меня этот текст про языковые модели и знаниевые графы в сочетании с текстом про кругозор подтвердил, что я ползу в более менее правильном направлении: все мои разные проекты и проектики это часть одного целостного проекта, а ещё есть шанс сохранить применимость в этом проекте некоторых моих старых компетенций, наряду с прихватом новых.

Студенты в МФТИ показывают примерно то же поведение, что и всегда: несколько человек уже поняло, о чём курс, и пытаются в рамках него решить вопросы по своим проектам. С одной группой даже сумели разобрать штук пять целевых систем -- хоть как-то их назвать. Минут по сорок на систему, три часа занятия. Впрочем, с курсантами Школы системного менеджмента всё то же самое: ровно такие же рассуждения с совсем неучебными, а очень даже рабочими проектами, такие же поиски целевой системы, при этом учебник и курс с задачами пройдены даже неоднократно. Но это поначалу не даёт защиты от ошибок, беглость в системном мышлении вырабатывается постепенно, плюс нужен ещё и кругозор.

Увы, большинство студентов МФТИ ещё не поняло, о чём курс: у них синдром студента, они ещё не знают цвета учебника и не узнают в лицо препода, так как занятия не посещают, видео не смотрят, книжку не читают, задачи не решают, и наверняка будут очень удивляться, когда у них возникнут проблемы с эссе. А они возникнут, весь мой опыт говорит именно об этом. Я очень весёлый на занятиях -- но только до тех пор, пока в тексте эссе я не увижу очередной попытки в раздел альфы system definition вписать словарное определение системы.

Вьюнош стал победителем лицейской олимпиады по физике (нельзя было не идти, вот и сходил). Опять он пошёл в кружок экспериментальной физики в "Потенциал" МФТИ на Климентовском переулке, но уже троллит тамошних преподавателей: "сколько лет можно измерять руку?!". Ибо программа там из класса в класс начала повторяться, а он же туда не первый год ходит! Но вот лекции из кружка теоретической физики его зацепили: там рассматривали движение стакана с водой. И то верно: роботы будущего будут напоминать собой IMHO не столько железяки с моторчиками (хотя и это наверняка будет), сколько бурдюки с синтетическими мышцами, и физика движения будет там такая же, как у человека -- как у бурдюка с водой, и инерция в этом бурдюке весьма управляема по отдельным частям тела. Даже крутиться один и тот же человек может как яйцо вкрутую или как свежее яичко (помните этот простой опыт?) в зависимости от того, как искусно напряжёт или расслабит свою мускулатуру, наложенную на скелет и внутренние органы во много слоёв. Вот пусть изучает такую "физику мягкого тела" хотя бы на примере движения стакана с водой.

В танцах я не препод (и не хочу им быть), и явно не выдающийся танцор (хотеть в свои 60 лет я могу, но не более чем хотеть). Жена подсказала, что я там по факту в своей привычной позиции методолога, консультанта. Фигура в танцах редкая, поэтому резко выделяюсь на общем фоне для одних (которые в этой сфере деятельности профи), но полностью незаметен для других (которые "просто потанцевать"). Я с удовольствием ввязываюсь с этой позиции в разные околотанцевальные разговоры. Вот пример моих текстов в треде про "почему социальным танцам не учат быстро" (https://vk.com/wall-167384137_27968):
В треде обсуждается только "маркетинговая" и "социальная" сторона вопроса, но не суть самой возможной скоростной методики преподавания. Я сам считаю, что в танцах есть способы ускорения подготовки в разы по сравнению с уже имеющимися методами "показа движений". Из мне известных преподов не-кизомбы в этом направлении (резкого укорочения сроков танцевальной подготовки) сейчас работает Антон Климат, он называет это "танцевальная инженерия" (а более общий вариант подготовки тела к движению мы назвали системный фитнес — он ведь и для восточных единоборств подходит, да и просто для спорта, и для сцендвижения). Если брать конкретно кизомбу, то там тоже есть место для улучшений. Я прошёл длинный и извилистый путь у разных преподов, но сейчас понимаю, что всё это можно было бы сократить в разы при других методиках подготовки. Я сам иногда думаю над такой методикой (в основе та самая танцевальная инженерия и внятный язык разговора о теле — особенно об инерациальной передаче движений в танце, обучение сразу как партии партнёра, так и партнёрши, ранняя работа с музыкальностью, управление расстоянием в паре и т.д.), но я лично не препод и преподом в танцах быть не хочу. В танцах таких как я сейчас вообще нет. Я тут выступаю как методолог, консультант — но даже и тут не хотел бы специализироваться в танцах, мне бы просто потанцевать, а эту методологию считаю хобби. )))

Вот тут Климат начал писать о своих штудиях: https://vk.com/klimat (там последняя запись сейчас начинается с восхитительной цитаты про "подтянуть пупок к косточке, из которой растёт хвостик" — как раз типовой сегодняшний способ разговора о движении, от которого нужно отойти). Но танцевальная инженерия — это то, что нужно делать до собственно танца. А потом ещё и сам танец. Я сам писал про это разделение на работу с телом и работу с танцем в серии текстов https://ailev.livejournal.com/1429126.html.

Вообще, если в этом деле нет теории — будут различные практические блуждания в потёмках. "Никакой теории, чистая практика" — это лозунг средневековья, а ведь именно этот лозунг у нас на знамёнах танцевального образования. Социальные танцы, сольные танцы, ритуальные танцы — это без разницы, везде без теории будет медленно и неправильно, танцевальное кулибинство.

Дальше нужно делать стейкхолдерский анализ. В сегодняшней бизнес-экосистеме социальных танцев есть вечеринки (и тамошние орги, тяготеющие к диджеям как раб.силе) и школы (и тамошние орги, тяготеющие к преподам как раб.силе). Дальше нужно решать вопрос о структурированном времяпрепровождении — где человек получает удовольствия больше: в танцшколе или на вечеринке? Я уже неоднократно ставил в разных текстах вопрос, что во многих танцшколах вечеринки понимаются как "дополнительные занятия сампо к нашим занятиям с преподом", а не как цель. Хотя начиналось всё с того, что школы готовили к вечеринкам. Но жизнь изменилась. Без размышлений на эту тему и понимания структуры социального/танцевального удовольствия от студий и школ как двух формах практикования танцев не сдвинешься. Это заход в "социологию социальных танцев" (обычно говорят "философию", но тут предмет уж совсем дохлый, словом "философия" прикрывают разные метафорические бла-бла-бла, "идеологии" — а я тут про более строгие рассуждения).

Бизнес-интересы танцшкол — чтобы максимизировать время нахождения в этих школах, бизнес-интересы оргов — максимизировать выход из танцшколы на вечеринки, так что вопросы методики преподавания как шкурные больше должны волновать оргов (в том числе ведь при этом и проблема баланса решается! Именно партнёров готовить долго!), а школы это будет волновать в меру появления конкуренции (любители-преподаватели уйдут, а профи придётся подтянуться). Но это всё wishful thinking, так как уровень ведения бизнеса по сравнению даже с окружающей российской корпоративной культурой — ниже плинтуса, это не бизнесы по большей части, а хобби любителей потанцевать ("самоокупается, и ладно", никаких практик современного бизнеса — всё "на коленке"). И за рубежом, похоже, весь этот "бизнес" тоже такой же, в кавычках.

Ещё один вопрос — это мультидансерство, хотя сама по себе кизомба как зонтичный термин уже мультидансинг (сюда ещё и компа для разнообразия на всех парах летит, ждём и в Москве через два-три месяца). Это добавляет сложности в рассмотрение. Понятно, что танцевальную базу нужно давать общую для всех социальных танцев, это в разы и разы сократит время подготовки. В прошлой своей реплике в этом треде я давал ссылку на свои тексты по танцам, там этот вопрос отражён как "высшее танцевальное образование" (ибо один танец — это уровень ПТУ, ремесленное "умение работать на одном станке". Социальные танцы тут не исключение).

Но бизнес-часть (в том числе вопросы маркетинга, позиционирования, эко-системы и т.д.) обсуждать можно, но не с кем и незачем, людям и так хорошо. А дальше теория, технология, методика образования в области танцев — если её нет, то конкуренции по сравнению с общим сегодняшним уровнем не будет даже потенциальной, и не будет шанса изменения ситуации. Поэтому я потихоньку копаю в этом направлении. Если есть содержание нового танцевального образования, то организационным мясом оно быстро обрастёт. Фишка в том, что это содержание образования должно стать отчуждаемым от препода. В телесных практиках это очень тяжело обеспечить и обосновать, ибо тут бытуют легенды про "линии непосредственной передачи", как в восточных боевых искусствах.

В соцсетях пабликов по кизомбе до чёртиков, но вот эти вопросы не обсуждаются ни в одном из пабликов — я видел уже много людей, которые хотят к вопросам танцев подойти хоть как-то серьёзно, но их запал кончается через пару реплик, когда обнаруживается, что нужно заниматься теорией, и не только ролики смотреть, но и буковки читать, и не все буковки по-русски.
Хотя я и просто пишу, с личной позиции танцора. Вот, например, мои критерии походов на вечеринки: выбираю вечернюю, а не ночную вечеринку как первый критерий (ночами нужно спать!). Поближе к дому как второй критерий (время пути туда-обратно это ж существенный процент от времени самой вечеринки). Если опенэйр, то он, скорее всего, выиграет у всех. Ещё отсутствие кальянов: они дико воняют, а их разноска распугивает партнёрш во время танцев, но общепит, похоже, открыл для себя дополнительный источник дохода в этих кальянах — и эту напасть не остановишь. Со всем остальным можно мириться: и партнёрш можно всегда хороших найти, и музыку сейчас все хорошо играют (я и аутентику люблю, так что меня этим не испугаешь, и под дансхол с мумбатоном я могу что-то сообразить, так что и этим не испугаешь — я музыкально-танцевально всеяден, разве афрохаус пропускаю), и пол мне подходит любой скользскости.

Антон Климат наконец-то начал писать про танцевальную инженерию в своей ленте -- и это радует: https://vk.com/klimat (и дубль в фейсбуке -- https://www.facebook.com/djklimat).

Утром меня добила жена, которая попыталась мне сегодня что-то рассказать про автокефалию. Мне! Про автокефалию! Шаланды, полные кефали, в Одессу Костя приводил -- я услышал что-то типа этого. Игра Украины против Турции в очередном туре, а Россия уже проиграла. Удивительно, что на эту церковную борьбу за власть идёт такое обилие комментов, вся лента фейсбука про это, и лента ЖЖ про это, разве что ВКонтакте и френдфидик молчат. Всё-таки 21 век на дворе, к папе на коленках никто ползти и не думает. Почему вдруг всех так озаботила игра в иностранных агентов коммерческих организаций в лице разных церквей? Как будто что-то в мировом раскладе от этих бюрократических войн церковных чиновников хоть немного изменится при любом варианте окончания этих войн. И все меня окружающие радостно обсуждают эти вопросы, как будто больше нечем заняться, кроме интриг византийского двора. Хотя да, две команды церковников играют в очередной футбол на чемпионате мира, как тут не поболеть -- даже если сам мяч не пинаешь и тебе этот спорт фиолетов. А влияние результата этих боданий церквей и их болельщиков на мир -- как результата чемпионата мира по футболу. Нуль.

Интересно, если бы цервки все свои миллиарды баксов и рублей пускали не на внешний шик (они ж там артисты -- поэтому концертные залы, артистическая одежда, реквизит и т.д.), а на реальное дело обеспечения бессмертия, и не духовного, а вполне себе биологического, как это приблизило бы это самое бессмертие? Одно дело молитвой помогать людям в хосписах, другое дело -- сделать так, чтобы до хосписов люди не доходили вообще. Но это так, wishful thinking. Трындеть про бессмертие в недоказуемом случае души в разы и разы легче, чем реально что-то делать в направлении доказуемого случая бессмертия тела. Шансы что-то быстро решить с реальным бессмертием сегодня уже есть, с мышками уже что-то биоинженерное начинает работать. Но реально бороться со смертью церковь как раз не борется, а только машет кадилом каждому усопшему вслед.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214002615633520
Tuesday, October 16th, 2018
4:19 pm
UpTown Spot -- робопёс, танцующий фанк
Не могу не перепостить танцующего фанк робота SpotMini (https://youtu.be/kHBcVlqpvZ8):


Сравните с образчиками 2010 года (всего 8 лет назад!) и первым же комментом там про "танцующих медведей" -- https://ailev.livejournal.com/870330.html. Или compressorheads 2013 года (пять лет назад!): https://ailev.livejournal.com/1053048.html. Про тверк-робота я уже писал в 2015, https://ailev.livejournal.com/1179701.html, но теперь можно делать совсем уж настоящего тверк-робота. Да хоть танцующего танец живота, техническая возможность уже есть, только это не нужно никому.

Робот, который учит танцам, сейчас на колёсах (2017 год): https://ailev.livejournal.com/1349125.html. Но уже очевидно, что антропоморфный Atlas и это сможет. Он же уже бегает паркур, делает сальто назад -- https://youtu.be/LikxFZZO2sk. И заставить его сплясать -- не раз плюнуть, но за несколько раз плюнуть уже можно справиться. Если это кому-то нужно, конечно. А дальше это будет обязательно кобот, так что и с человеком в паре он (она?!) тоже будет плясать.

Дальше цена на это всё будет падать вдвое (а то и втрое) каждый год. И на каком-то уровне цены (очень скоро! ойкнуть не успеете!) спрос появится и на умение робота сплясать. Будут роботы готовить, стирать, а в свободное от этих дел время ублажать хозяина беседами об умном, игрой на музыкальных инструментах и танцами. Где-то я о таком слышал, но потом там то ли аболиционизм был, то ли феминизм, то ли ещё какое-то умное слово, никак не могу вспомнить.
3:23 pm
Language models, knowledge graphs, relational models -- всюду жизнь
Моя любимая статья этой недели -- BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding от Google AI Language (https://arxiv.org/abs/1810.04805). BERT is conceptually simple and empirically powerful. It obtains new state-of-the-art results on eleven natural language processing tasks, including pushing the GLUE benchmark to 80.4% (7.6% absolute improvement), MultiNLI accuracy to 86.7% (5.6% absolute improvement) and the SQuAD v1.1 question answering Test F1 to 93.2 (1.5 absolute improvement), outperforming human performance by 2.0. В задачах, связанных с естественным языком (а не только обработкой изображений) начинают появляться фразы outperforming human performance! Для меня эти "модели языка" и есть state-of-the-art в "новой семантике". Семантика ведь это не факты про смысл, а знание о значениях -- знание переносимо из ситуацию в ситуацию, а факты чаще всего остаются уникальными для ситуации. Семантика в новой терминологии, это про transfer learning и тем самым смежно с mulitask learning.

Тут нужно ещё обязательно упомянуть и прогресс в text style transfer -- это когда в тексте сохраняют содержание (знание), но только меняют стиль изложения, свежий прогресс вот тут: https://vk.com/@deepvk-obzor-svezhih-statei-style-transfer. Типовая фраза оттуда -- We validate the effectiveness of our model in three tasks: sentiment modification of restaurant reviews, dialog response revision with a romantic style, and sentence rewriting with a Shakespearean style. И меняют язык аки твой стиль, выучивая language agnostic universal representation (да ещё и на базе универсальной грамматики, привет Хомскому и Монтегю) -- https://openreview.net/forum?id=r1l9Nj09YQ.

Ещё интересная тут штука -- это работа с кодированием мира на искусственных языках. Оцените пассаж из https://githubengineering.com/towards-natural-language-semantic-code-search/ про перевод с естественного языка на язык программирования: "task of mapping code to the vector space of natural language. We can evaluate this model objectively using the BLEU score. Currently we have been able to achieve a BLEU score of 13.5 on a holdout set of python code, using the fairseq-py library for sequence to sequence models". Плохо переводит, но ведь переводит! Но сам заход-то какой: mapping code to the vector space of natural language -- это ж про смысловое пространство, ровно как я писал в книжке "Визуальное мышление" (https://www.litres.ru/anatoliy-levenchuk/vizualnoe-myshlenie-doklad-o-tom-pochemu-im-nelzya-obol/).

Отличие в том, что языковые модели это коннективистские представления знаний о мире (не о языке! а об отражаемом языком мире! -- это нужно отдельно обсуждать, что именно выучивается в language representation models), а не knowledge graphs. Понятно, что в конечном итоге потребуется объединённая работа knowledge graphs и language representatnions, по уже неоднократно обсуждавшимся линиям выучивания сеткой разных embeddings (по сути, language models это просто "второе поколение embeddings") и knowledge graphs путём выучивания knowledge graph как embedding (типа https://www.hindawi.com/journals/sp/2018/6325635/ и там небольшой обзор разных моделей embeddings для knowledge graphs или подходов из списочка https://gist.github.com/mommi84/07f7c044fa18aaaa7b5133230207d8d4 -- все эти RDF2Vec. Или построения разных семантических/knowledge graph представлений по научной литературе, типа SourceData is at an early stage, Lemberger says, having generated a knowledge graph comprising 20,000 experiments that were manually curated during the editing process for roughly 1,000 articles. The online tool is currently limited to querying this data set, but Lemberger and his colleagues are training machine-learning algorithms on it -- это обзорчик семантического поиска в научной литературе, там всё такое: https://www.nature.com/articles/d41586-018-06617-5).

Это всё не снимает задачи нахождения нормального представления для knowledge graph -- преодолевающего недостатки RDF. Есть множество более современных подходов, более современных форматов, и я бы от них не отмахивался. Вот только один из вариантов: GRAKN.AI (https://grakn.ai -- при этом идите туда сразу через VPN, Роскомпозор пытается его фильтровать). В тексте https://blog.grakn.ai/knowledge-graph-representation-grakn-ai-or-owl-506065bd3f24 объясняется, почему там идут не по линии трипл-сторов и стандартов W3C). Это всё для меня имеет прикладное значение, ибо в ближайшее время потребуется выбрать представление для knowledge graph в SysMoLan Studio (https://ailev.livejournal.com/1446524.html). В SysMoLan Studio мы будем работать с knowledge graph, и нужно быть state-of-the-art. И в инженерии сейчас используют не RDF, а как раз такие knowledge graphs, как GRAKN -- работы типа SMART-DOG (Strathclyde Mechanical and Aerospace Research Toolbox for Domain Ontology Generation), https://blog.grakn.ai/semi-automatic-generation-of-a-reliable-knowledge-graph-for-space-mission-design-with-grakn-c96061eee2a3. Это всё фронтир, это всё неочевидно выживет, но это какое-то движение вперёд, а не топтание на месте на мощах так и не взлетевших древних технологий.

Очень интересное обсуждение СМД-подхода появилось в https://www.facebook.com/groups/771940449578453/permalink/1673757909396698/ (и там дальше по ссылкам), где исследовательская программа ГПЩ анализируется Алексеем Боровских как логическая программа: " мы все (по крайней мере те, кто занимался всерьез наукой), прекрасно знаем, что [логическое] рассуждение — лишь конечная форма, в которую мы выкладываем мысль для того, чтобы она была и доступна окружающим, и для нас не потерялась в суете. А вот движение самой мысли — какова его логика? Можно ли задать форму этого движения так, чтобы оно было не блужданием впотьмах, а осознанным и осмысленным движением вперед?". Для меня ответом является уход от последовательной "алгоритмической" парадигмы пошагового движения в каком-то knowledge graph (логического вывода), ибо при этом нового знания не породишь (новые концепты при этом не появляются -- просто появляются какие-то имена для уже существующих концептов в лучшем случае). А вот в коннективистской парадигме, где мы прыгаем в спектре формальности мышления от формального knowledge graph к его дифференцируемым представлениям в виде разных knowledge graph models, используем language models -- вот там мысль и может "двигаться" (в той мере, в которой коннективистские вычисления в нейросетках можно назвать "движением"). Логики выживают тут только те, кто готовы рассуждать и на тему вероятностного/байесовского вывода (inference). И онтологи, соответственно, выживут только те, кто готовы обсуждать knowledge graph models и language models, а не только knowledge graphs и language. Поэтому из текста по ссылке "Насколько я понимаю, в процессе решения этой проблемы выкристаллизовалась концептуальная позиция: средством понимания всегда является идеальный объект. Который, поскольку он идеален, должен быть как-то представлен в знаковой форме" -- вот эту знаковую форму и можно проблематизировать, ибо она может быть просто вектором, местом в пространстве смыслов. А дальше да, нужно коммуницировать, и для этого иметь какие-то знаки, обозначающие места в пространстве смыслов -- но это не для понимания, а для коммуникации/объяснения (экстернализации понимания). С компьютерами тут проще: можно передать language model в ONNX, "таблетки знаний" для компьютеров можно сказать, придумали в какой-то рудиментарной форме.

С людьми сложнее, но можно обсуждать "фундаментальное образование" и "кругозор", как формирующее ровно то же самое: language model, knowledge graph embedding/model. И дальше не удивляться, что хорошо обученные предварительно люди потом довольно быстро доучиваются до нужных кондиций в каких-то прикладных задачах. Меня такая даже метафора устраивает, при этом в каждой метафоре есть доля метафоры.

Дальше по этой линии -- "размер имеет значение", все эти языковые модели/модели графов знаний могут быть выучены на реально больших корпусах. И вот тут с людьми то же самое. Меня сильно радует, что я вышел на тему кругозора (https://ailev.livejournal.com/1449158.html). То, что у всех в голове дребезг от близости понятий "фундаментальное образование", "базовое образование", "кругозор" -- это пройдёт. Но меня радует, что сразу в ответ на понятие "кругозор" пошли ссылки и на liberal arts. Это верный признак, что через "кругозор" можно будет как-то более-менее прилично выйти и на культуру. Теперь к культуре и даже к личной жизни и семье появилась тропинка, которую можно потихонечку расширять. В предыдущем делении дисциплин на фундаментальные (методологические и когнитивистские -- upper ontology) и прикладные (domain ontology) этой тропинки не было. А вот с появлением middle ontology и кругозора тропинка появилась, и фундаментальные знания нужны для культуры как сферы деятельности (а не культура сама по себе даёт фундаментальные знания!). Но теперь у меня есть подходящая метафора (а то и не метафора), как всё это объяснять и что с этим делать.

Ещё один заход тут -- это на нейронет/киберличность, совместную работу людей и компьютеров с их knowledge graphs и language models. И выход на нептолемеевские модели интеллектуальных систем, где интеллект одного человека и компьютера находится в центре рассмотрения, а все остальные интеллекты вращаются вокруг него. Коммуникация с учётом и knowledge graphs и language/knowledge models (то есть передача не фактов, а знаний о мире -- делёжка/sharing онтологией, семантикой, то есть обучение с использованием "таблеток знаний" в какой-то форме) это ж самое оно. Так что по сравнению с обсуждениями четырёхлетней давности, когда мы обсуждали семантические стандарты обмена знаниями в нейронете, мы не учитывали возможность существования не только новых стандартов для knowledge graphs (типа того же GRAKN), но и новых стандартов для коннективистских их моделей и моделей языка -- типа того же ONNX.

Что дальше? Например, можно порассуждать (онтологически), чем похожи и чем отличаются модели графов знаний и языковые модели. И обязательно помнить, что в reinforcement learning обсуждают похожую на knowledge graphs штуку, только называют её relational models -- типа https://arxiv.org/abs/1809.11044. Всё это IMHO про одно и то же, и это и есть онтологический/эпистемологический фронтир.
Monday, October 15th, 2018
1:38 am
Кругозор: между прикладностью и фундаментальностью
Есть прикладные дисциплины, за них платят. Есть фундаментальные дисциплины, которые и образуют "умение мыслить". А есть ни то, ни сё: кругозор, который про наличие самих групп прикладных дисциплин, про сферы человеческой деятельности и как они связаны. Я описывал этот кругозор в постах про глубокие уровни абстракции https://ailev.livejournal.com/1442975.html, онтологию сфер деятельности как основу для стейкхолдерского мастерства, https://ailev.livejournal.com/1443370.html и эскиз учебной программы для системного развития личности https://ailev.livejournal.com/1443837.html (в этом посте я прямо перечисляю эти сферы деятельности, причём даю развёртку на один уровень для инженерии, менеджмента, предпринимательства, а остальные сферы деятельности -- списком).

Основной вывод в том, что если не знать хотя бы примерно общую структуру человеческой деятельности по её сферам, то трудно будет даже рассуждать о том, чтобы вписывать работы в рамках своих прикладных компетенций в какие-то проекты: если ты не очень понимаешь, чем работа инженера отличается от работы менеджера, от работы предпринимателя и не очень понимаешь, какие ещё сферы деятельности бывают (сводишь, например, правоохрану к тому же менеджменту -- типовой редукционизм), то никакие фундаментальные знания тебе не помогут, ты не договоришься со стейкхолдерами -- не будешь их знать, не сможешь их определить. Каждая практика в сфере деятельности -- это вид стейкхолдера. Скажем, грубо "системный инженер" или более тонко "инженер по требованиям", грубо "медик" и более тонко "эпидемиолог".

У моих студентов в МФТИ, которые пришли сразу из бакалавров, основной пробел, похоже, именно в отсутствии кругозора. Они ещё как-то способны осваивать фундаментальные дисциплины, но когда они на базе этих дисциплин пытаются выполнить какие-то прикладные практики, результатом часто является катастрофа именно из-за отсутствия кругозора. Людей и работы они видят, а вот практики и стейкхолдеров -- нет.

Вопрос в том, как получить этот кругозор, и пораньше.

Фундаментальным дисциплинам учат обычно преподы-исследователи, прикладным -- забежавшие в учебный класс практики с методологической жилкой из соответствующих сфер деятельности. Кругозору IMHO не учит никто. И мало кто о нём говорит. Я и сам набрёл на его необходимость только этим летом, до этого проблема была очевидна, но я её не мог точно сформулировать.

vvagr считает (это было в частной беседе), что кругозор получается только путём глубокого овладения какой-то сферой деятельности, то есть в результате полноценного прикладного обучения, но потом забывания всех мелочей -- и дальше в голове остаётся только правильно устроенная middle ontology, основные понятия этой сферы деятельности, часть кругозора. То есть кругозор -- это результат деградации профессионального знания, и он всегда неполный (ибо глубоко научиться многому нельзя). Дальше будет только хуже, поскольку прикладные области живут всё короче, и времени хватать для глубины освоения (скажем, 6-7 лет для занятия чем-то одним) не будет. Всё будет по верхам, и кругозор будет некачественный в части "чеклиста для мышления" и не слишком свежий, ибо знания будут быстро устаревать.

Я же считаю, что кругозору можно и нужно учить, как и всему другому. И учить нужно, как всему остальному: сначала выделить такой предмет, потом создать учебник и задачник, потом обеспечить как-то узнавание тамошних концептов в жизни (тренировать постановку задач). И уже потом более глубокая работа с прикладными областями, domain ontology -- когда знаешь их место в жизни ровно за счёт кругозора, за счёт владения middle ontology.

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

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10213987291890436
Sunday, October 14th, 2018
4:05 pm
Мои мечталки и Julia.
Вот мои мечталки, связанные с Julia (http://julialang.org/, русскоязычный чат https://t.me/JuliaLanguage):

1. SysMoLan Studio -- моделер и платформа системного языка моделирования, https://ailev.livejournal.com/1446524.html. В тексте по ссылке дана более-менее подробная постановка задачи и объяснено, почему именно на Julia.

2. Сертифицированный Julia Jetson AGX software stack. NVIDIA выпускает AGX компьютеры с GPU для встроенных применений -- https://www.nvidia.com/en-us/deep-learning-ai/products/agx-systems/. Все они устроены похожим образом, хотя есть и отличия (серии Jetson для роботов, DRIVE для беспилотных автомобилей, Clara для медицинских изображений -- но в основе там стандартные CUDA-чипы).

Начинают в NVIDIA обычно с автомобильного "железа" и софта (денег там побольше), а затем сдвигают эти железо и софт в робототехнику -- например, AGX Xavier уже есть и как DRIVE, и как Jetson. А вот AGX Pegasus пока только как DRIVE, а Jetson ждём-с, ведь пример со сначала автомобильным, а потом робототехническим Xavier перед глазами. Программируются эти компьютеры AGX на дикой смеси из C++ на нижних уровнях (та же CUDA) до Python на верхних уровнях. И много кода, требующего высокой эффективности (робототехника! мало компьютертной мощности, но реальное время!) и поэтому хороших алгоритмов. Вот это и нужно получить на Julia, решая проблему двух языков. Из интересных и трудных возникающих там задач -- это сертификация по нормам безопасного компьютинга (ASIL-D) этого софтверного стека. Само по себе это огромная задача, иметь систему надёжного программирования.

Про Julia Jetson AGX software stack -- это совсем-совсем мечталка. "Если софт уже есть, то кто его будет переписывать, и зачем?" -- это ведь основной вопрос. Julia даёт интересный ответ на этот вопрос: AGX системы по сути являются махонькими такими суперкомпьтерами. А единственный пока язык высокого уровня, который используется для программирования суперкомпьютеров -- это Julia. Если мы хотим компактный (высокоуровневый), легко расширяемый (отладка до самого железа, а не до границы библиотек), быстро выполняющийся (проблема двух языков) код, поощряющий исследования в части новой алгоритмики разных уровней софтверного стека, то Julia даёт такую возможность. Новой алгоритмики -- это потому что проблемы уже написанного стека становятся явно видимы, и их нужно как-то решать.

А если добавить вопросы сертификации в безопасности компьютинга, то результаты могут быть полезны и для развития самой Julia (хотя это уже совсем мечталка). Так что вопрос "зачем переписывать" имеет какой-то ответ, остаются неотвечаемые проблемы в "кто".

Конечно, это задача совсем не та, что в http://www.juliarobotics.org/ и , она будет помасштабней.

3. Учебно-промышленный Julia AI-стек. В нулевой постановке вопроса -- это просто повторение проекта http://www.fast.ai/, только не на Питоне, а на Julia. Курс глубокого обучения на базе оригинальной библиотеки, которую потом можно использовать в production. В расширенной постановке вопроса -- это обучение программированию (входной билет в глубокое обучение), матану, линейной алгебре, байесовской статистике и всем остальным пререквизитам для этого глубокого обучения (см., например, последовательность курсов в "образовательных ступеньках к деланию роботов", https://ailev.livejournal.com/1434868.html). В ещё более крутой постановке вопроса -- это шаг от просто поддержки deep learning к differentiable programming и прочим радостям альтернативной алгоритмики в искусственном интеллекте. Почему это нужно делать на Julia? Ну, Torch перешёл от Lua к Python -- почему? Следующая остановка на этом пути -- как раз Julia. Но основная фишка этого проекта не в "промышленном фреймворке/библиотеке", а в учебности, сопряжённой с промышленным инструментарием. Про эту учебность в части минимальной связки курсов на Julia я даже написал чуть подробней в https://ailev.livejournal.com/1433113.html.

Почему мне так хочется, чтобы это все эти три моих мечталки были на Julia? Неужели я не знаю, что любое упоминание Julia вызывает сразу дискуссию со стороны любителей других языков программирования? Неужели я незнаком с критикой языка? Например, "как вы можете работать с языком, в котором первый элемент массива -- первый, а не нулевой!". Ну да, индексация как в математике, как в инженерии, а не как в программировании -- формулы с индексами из математических и инженерных статей перекладываются в код на Julia один в один, без какой-либо перекодировки индексации! Это всё прикладное программирование, а не системное программирование: работаем с инженерными таблицами и тензорами, а не адресами в памяти. Julia определяется как язык для technical computing, инженерных вычислений. Вот ровно на эту тему и все три проекта из списка моих мечталок. Опять же, кастомные массивы с произвольной индексацией-какую-пожелаешь в Julia есть -- https://github.com/JuliaArrays/OffsetArrays.jl и поддержка для этого -- https://docs.julialang.org/en/latest/devdocs/offset-arrays/. И так по каждому пункту возражений: есть ответы и на аргумент "после NumPy и Pandas математика в Питоне стала быстрой, новых языков не нужно", и на аргумент "Cython всем поможет", и на множество других аргументов. Моё мнение по будущему и развитию Julia я написал в "на выпуск Julia 1.0.0", https://ailev.livejournal.com/1440499.html.

Но есть ещё и мой личный аргумент: Julia мне нравится ещё и по чисто эстетическим соображениям. Я его обнаружил в сентябре 2014 года, и так и написал: "Язык Julia (http://julialang.org/) приобрёл в версии 0.3 полноценный REPL. Почему-то изо всех свеженьких языков программирования мне симпатичен именно он, а не язык Вольфрама и стремительно матереющий Go. Кто-нибудь может мне эту симпатичность объяснить?" (https://ailev.livejournal.com/1139366.html). За эти четыре года в этом отношении для меня мало что изменилось.

Почему я решил выписать тут эти свои мечталки?

Самый верный способ избавиться от лишних для человека мечталок -- это выложить их на бумагу. Мозг после этого уверен, что "эти мечты не забудутся!", и спокойно прекращает об этих мечталках думать. Методики типа GTD рекомендуют после этого регулярно просматривать списки этих мечталок, и брать некоторые из них к исполнению, а остальные честно вычёркивать из списка, как "просто мечты", "хотелки, которые заведомо не будут реализованы". Я пишу тут свой список хотелок по Julia, но не факт, что после этого просто их вычеркну и забуду.

Мечта в этих хотелках -- это то, что я сам хотел бы пописать код на Julia. Ибо меня это почему-то привлекает, мой мозг мне говорит, что в этом много удовольствия (врёт, конечно, но этому вранью почему-то хочется верить -- это ведь и есть "мечта"?). Но я понимаю, что не буду сам писать промышленный и тем более исследовательский код на Julia, ибо для этого нужно бросить чуть более чем все остальные деятельности, чтоб потратить пару лет для выхода на нужный уровень профессионализма -- и по факту стать разработчиком или даже разработчиком-исследователем. Хочу ли я этого? Нет, я уже был программистом, но перестал активно писать код где-то в 1987 году. Но я вплоть до последнего времени регулярно руководил разработкой того или иного софта, и от этого не зарекаюсь и сейчас. Так что эти проекты для меня "бесплодные мечталки" лишь наполовину. Если мне подвернётся возможность/ресурсы эти проекты реализовать -- я мимо этих возможностей не пройду, а активно ввяжусь, хотя и не в роли программиста. А по первому проекту я уже делаю активные телодвижения.

В принципе, весь этот пост -- ответ на первые два коммента к моему посту "Об Julia language" ещё из февраля 2015 года (https://ailev.livejournal.com/1164251.html):
kuzh -- вот блин, языков распрекрасных всё больше, а программы всё хуже!
ailev -- Так более выразительный язык помогает не только хорошую мысль выразить лаконично, но и плохую мысль выразить крайне точно и эффективно для её реализации на практике!

Вот и хотелось бы на распрекрасном языке выразить какие-то хорошие мысли.
Saturday, October 13th, 2018
3:29 am
Мои выступления на SECR'18
Сегодня побыл хедлайнером на SECR'18 -- https://2018.secrus.org/, Software Engineering Conference Russia. Я много лет плачу членские взносы в ACM и тамошний SIGSOFT, так что для меня это вполне профильная конференция. Как у хедлайнера у меня там было четыре обязательных мероприятия:

1. Доклад "Стейкхолдерское мастерство", слайды (https://www.slideshare.net/ailev/ss-119256332, для страдающих от Роскомпозора -- https://yadi.sk/i/3sKV-D10PiDGMQ):

Видео снималось, будет опубликовано позже.

2. Q&A сессия. Основные вопросы были про то, как я направляю обучение своего вьюноша -- учитываю ли его предпочтения (да, конечно -- но чётко понимаю, что он их может поменять в любой момент), подтягиваю ли трудные предметы или наоборот, развиваю то, где ему полегче (развиваю то, где ему полегче -- и трудное потом подтягивается проще), почему я гружу его физикой (чтобы не терял адекватность: знаю многих физиков-директоров, а вот математиков-директоров не так много -- физика заставляет всё время думать о применимости теорий к окружающему миру, а вот математика про окружающий мир и его ограничения заставляет вспоминать чуток пореже), делает ли он что-нибудь руками (да, там уже была куча "паяльных кружков" и школ робототехники, и в этом году тоже -- кружок экспериментальной физики в МФТИ и элективный курс работы со станками с ЧПУ от СТАНКИНА в его лицее), и т.д..

3. Мастер-класс "Как и какое мышление нужно развивать (чеклисты для личного развития)", слайды (https://www.slideshare.net/ailev/ss-119256910, для страдающих от Роскомпозора -- https://yadi.sk/i/UpV8v-WFOEbX8Q):

Видео снималось, будет опубликовано позже.

4. Завершающая вечеринка, где состоялось две длинные беседы -- одна по факту про моё отношение ко всяческой эзотерике-мистике (плохое) и вторая про проблемы надёжности нейронных сетей (я считаю, что надёжность выше человеческой -- это уже большой шаг вперёд, а 100% надёжность -- это утопия).

И кроме этого я успел только послушать доклад про коллективное программирование на ПиктоМире (ну очень интересно -- https://2018.secrus.org/program/submitted-presentations/cooperative-programming-tasks/, вебсайт -- https://piktomir.ru/, и уже прошла первая олимпиада по коллективному программированию, а в Сургуте уже прошли обучение по этой программе 2000 детишек в детских садах, а в этом году их будет уже 6000. И план группы "Аттик" -- сделать ПиктоКуМир, и к третьему классу школы успешно заканчивать обучение школьников в области программирования, причём в том объёме, который сейчас требуется стандартом образования от выпускников средней школы.

И ещё доклад про специализацию С++ на Курсере. Мой вопрос там был -- как можно освоить язык по видеоматериалам, особенно если смотреть эти материалы с телефона в машине или автобусе. Ответ был невнятен (типа "а потом люди всё равно начинают читать, мы прикладываем к видео конспект").

Но я ещё немного потроллил защитников текущего вузовского образования на панели по судьбам IT-образования в России. Там, увы, ничего интересного не сказали: сплошной плач Ярославны на крепостной стене и метания в разные стороны. Вузы хотят учить, как учили (и то, что мир программной инженерии меняется прямо на глазах, их мало заботит), работодатели хотят, чтобы учили вот прямо конкретным технологиям для каждого типа рабочих мест (вот прямо программистов .NET готовили!), а что-либо в текущей патовой ситуации изменить нельзя, ибо вузовская бюрократия этого ни за что не допустит. Работают решения только "мимо школы", только "мимо вузов" -- но эта простая идея даже не обсуждается, хотя и было отмечено, что разные успешные инициативы в IT-образовании почему-то оказываются не в вузах. Наоборот, обсуждался вопрос, как такие сбежавшие инициативы вернуть в вузы! Я не удержался, и на вопрос о том, почему нельзя такие же успешные инициативы делать прямо в вузах, выкрикнул из зала -- "в грязной луже чистого производства не построишь".

Пройти на SECR'18 в этом году было сложно: недалеко от venue (Цифровой Октябрь) находится храм Христа Спасателя (sic!), куда завезли очередные мощи, и там везде рядом были рамки металлоискателей, полиция и толпы страждущих вожделением к мощам народу. Меня там тоже обыскали -- вдруг что не так у меня в рюкзаке! Это было символично: программная инженерия, мощи и полиция.

Обсуждение в фейсбуке у Максима Цепкова: https://www.facebook.com/mtsepkov/posts/1951760418214236 (про развитие личности), https://www.facebook.com/mtsepkov/posts/1951456538244624 (про стейкхолдерское мастерство).

Мои выступления на SECR'16 (я на них пару раз сослался в докладах этого года): https://ailev.livejournal.com/1308520.html
1:48 am
Мои предпочтения в кизомбе
Я уже писал, как я оцениваю партнёрш (https://ailev.livejournal.com/1447611.html), но не писал ещё о собственных предпочтениях в кизомбе. А они есть.

Главный принцип был высказан Ronie Saleh: разнообразие принципов. Нужно делать из кизомбы танец контрастов (https://ailev.livejournal.com/1376152.html, https://ailev.livejournal.com/1376374.html). Хотя это легче заявить, чем сделать. Например, я не понимал, как танцевать близко: танцевал далеко и очень далеко -- и даже не пускал партнёршу к близкому танцу, просто не понимал, как это. За последнюю пару месяцев мне удалось более-менее разобраться с этой проблемой (спасибо Саше Сирото и Артёму Левину, которые не просто показали и рассказали, но и буквально заставили прочувствовать и даже как-то освоить базу близкого танца -- теперь и саида нормально проходится без разрыва контакта, и ускорения мягкие, и "кач в пол" как надо). Другой пример -- это медленный и быстрый танцы. Для медленного танца не хватает баланса (и тут нужно банально качать мышцы), для быстрого -- мягкости, что достигается "качем в пол" на скорости (и тут нужно разгонять работу бёдер, которые при повышении скорости просто отключаются сами собой). Так что работаю над собой, направления этой работы вполне понятны. Но фишка в том, что я могу кусочек аутентики, тарраш/дусера (много их), урбана (а сейчас интенсивно осваиваю и компу) упаковать в рамках одного трека. Рисую танец всеми красками, не использую стилевых монохромов: жанр музыки и соответствующий стиль танца определяю не по всему треку, а по настроению отдельных музыкальных фраз внутри одного трека. Это не всем нравится, но всем не угодишь -- многим-то нравится!

Есть и другие конкурентные преимущества перед другими партнёрами, которые я активно эксплуатирую в своём танце:
-- я не запоминаю связок, у меня память короткая. И чтобы танцевать, я импровизирую. Так что в итоге я импровизирую неплохо, всё-таки два года практики танцев "без связок" -- практики импровизации.
-- а поскольку связок нет, то и классических закрытий в танце у меня не так чтобы много. Идёт сплошной поток движений, и я стараюсь сохранять непрерывность движения партнёрши как можно дольше. Когда музыка бодрая (пара треков дансхолла на кизомба-вечеринке ставится всегда, а некоторые идут ещё дальше и включают мумбатон -- это всё более чем бодрая музыка), то и танец получается довольно драйвовый, причём без пауз и остановок -- связок нет, нет связанных с ними закрытий. Обратная сторона в том, что эта драйвовость у меня получается на грани фола. Например, теряется компактность шагов -- всё это перестаёт напоминать "кизомбу, как она должна была бы быть", но и тут есть свои плюсы: у большинства партнёрш в этот момент вдруг загораются глаза, и они выдают все недоплясанные в сальсе эмоции. Не канон, совсем не канон, но это нравится многим и многим партнёршам, и я буду продолжать это делать.
-- я танцую foxkiz (подхваченный мной у того же Ronie Saleh), что в Москве довольно редко. Это длинные инерциальные дорожки по прямой, типа фокстротных дорожек. У партнёрш появляется ощущение, что они то ли плывут, то ли летят, то ли вальсируют, и это всё на довольно большой скорости и в непрерывных поворотах. Обычно я это делаю на самом краю толпы: и прохожу метров десять вперёд-назад по узкой метровой ширины дорожке между стоящими у стеночки и танцующей толпой. Это в некотором роде трюк: каждый разворот при таком проходе должен быть на 180°, скорость высока, свободного места мало -- и при недоворотах на следующем шаге врезаешься либо в танцующих, либо в стоящих. Но в этом и драйв!
-- я брал уроки движения за ведомого (не буду говорить "за партнёршу", переведу английское lead-follow). И поэтому меня можно вести. Я точно знаю, что многих партнёрш от этого буквально прёт. И это никак не связано с гендерными ролями, или "современная женщина хочет подоминировать" или чем-то таким. 99.9% в желании и удовольствии девочек вести -- это возможность выразить ведомому музыкальные акценты, которые слышит ведущий, а не самовыразиться перед собой каким-нибудь "женским стилем". А иногда партнёрши перехватывают для этого ведение, считая, что они просто делают "женский стиль", не более. И вот я в это время просто позволяю им вести. Никто из партнёрш не делает это целый танец, но толерантность к перехвату ведения и умение не испортить в этот момент танец -- вот это сильная моя сторона. Хотя я ещё недостаточно хорош как ведомый, но комплимент "лёгкая партнёрша" я уже слышал много раз. Вообще-то умение танцевать обе партии -- это прерогатива преподавателей, но это просто часть танцевального мастерства, и я считаю, что это тоже нужно развивать. Это и при обучении удобно: мои преподаватели не показывают мне мужскую партию в её трудных местах, но заставляют в этих местах протанцевать за партнёршу -- я понимаю, как вести, и дальше уверенно веду сам. Это сильно сокращает время обучения.
-- я чувствую движение инерции в партнёрше (знаю, какая и где и с какой скоростью идёт у неё волна в теле) и могу подхватить эту волну как руками, так и корпусом. А ещё я и сам могу телом делать всякий разный вейвинг с изоляциями и анимациями/дискретками. Это позволяет мне задавать довольно разнообразный танец в тараш*(много их!) и дусере. Но главный трюк в том, что я ведусь и на движение корпуса, а со многими партнёршами я могу ещё и посоревноваться: у кого изоляция при этом лучше. И да, могу делать и волну животиком -- и вестись на эту волну тоже. И вот это всё уже цепляет и продвинутых партнёрш. При этом, конечно, я всё это тарашение-дюсерение никогда не делаю сразу: сначала партнёрше нужно показать, что умеешь ходить ножками, и только после этого возможны всякие залипушки (хотя тут вопрос тонкий: тут и музыка важна, и давнее ли знакомство с партнёршей, и сиюминутные желания партнёрши -- они иногда ходить ножками вдруг активно сопротивляются, у них с этим "космосом" свои особые отношения, им вдруг позарез нужны эти залипушки, и это приходится учитывать).
-- когда играет семба, я не ухожу с танцпола, а отвязываюсь по полной. И даже когда играет сальса, я не ухожу с танцпола (для одного трека с грехом пополам моих умений хватает, хотя я уже пару месяцев это не проверял). Я ухожу с танцпола, когда играет бачата (к счастью, она практически не играет на кизомба-вечеринках), у меня с бачатой эстетические разногласия.
-- а ещё я считаю кизомбу весёлым танцем и поэтому часто улыбаюсь. Конечно, бывает у меня и знаменитое печальное "танго-лицо", но я надеюсь, что это редкие моменты. И мне говорили, что эта улыбка -- это тоже моё конкурентное преимущество на танцполе, полном партнёрских покер-фейсов.

Из этого понятно, что я скептически отношусь ко всем "незыблемым законам" тех или иных авторитетов или даже целых "фракций" кизомба-движения. Нужно ли водить партнёршу корпусом или рамкой? Нужно и корпусом, и рамкой, и всем -- иногда я даже демонстративно убираю руки, "как на занятиях", иногда веду руками непрерывно, иногда использую "импульсное ведение", нужно не только уметь всё это, но и делать всё это! Конечно, есть любители или нелюбители этих разных вариантов. Некоторые партнёрши не любят, когда "подруливаешь руками" -- но некоторые другие партнёрши наоборот, чувствуют себя спокойнее при этом, так что я таки буду подруливать руками, если на вечеринке и есть впечатление, что только корпуса не хватает. Это ведь не занятие, чтобы "не учить девочек плохому": мне ведь нужно удовольствие доставить девочке на вечеринке, а не "научить её танцевать". Мне не нужно, чтобы она превращалась в одно большое ухо, танцуя со мной, и я делал ей замечание, что "ты не знаешь базы!". Нет, она должна просто танцевать комфортно. Да, для разных партнёрш "комфортно" означает разное -- но я и не надеюсь, что понравлюсь всем. Но некоторым -- нравлюсь.

Ещё один частый вопрос о том, как долго я танцую, если партнёрша не заканчивает танец сама (а она всё реже и реже заканчивает танец сама, что меня радует). Основной мой критерий -- если мне партнёрше уже нечего сказать в танце, то танец я прекращаю. С начинашками у меня часто нечего сказать уже к концу первого трека, но я пытаюсь топтать базу до конца третьего трека (ну, иногда второго, в совсем уж тяжких случаях). А с остальными -- это всегда по разному, ибо когда я начинаю считать треки, то обычно это происходит прямо с первого трека. А если я уж не начал считать треки сразу -- то могу и десять минут танцевать, и час. И с хорошими партнёршами у меня сами начинаются вспоминаться разные фишки, танцеваться разные стили, а иногда движения я сочиняю прямо по ходу танца. С совсем хорошими партёршами я начинаю ещё и делать футворки, причём это тоже импровизация (не то чтобы я не умел делать классический мужской стайлинг, но у меня ж память короткая -- и мне легче придумать какой-то футворк, чем вспомнить и воспроизвести вовремя). Но это только если я уверен, что партнерша не будет сбиваться -- иначе никаких сбивающих с толку движений ногами, никаких отвлекающих внимание махов руками.

В результате всего этого мне уже несколько раз говорили, что мой танец немного страшненький на "смотреть", но весьма интересный и комфортный, если ощущать его внутри пары.

Обычно я приглашаю хорошо знакомых партнёрш, и очень редко малознакомых. Хотя иногда играю в "такси" и приглашаю несколько человек подряд от стеночки. Но это очень иногда. Тут ещё и такой фактор, как моя удивительно плохая память на лица -- у меня лёгкая степень просопагнозии, и мне нужно встретить человека раз пять, чтобы как-то начать его узнавать, и раз десять, чтобы узнавать уверенно. Откуда берутся эти "хорошо знакомые партнёрши"? Вестимо, с занятий! Я ж прозанимался довольно долго в разных студиях -- и есть партнёрши, к которым я уже как-то привык, и они как-то привыкли ко мне. Вот с ними и танцую. А вот преподавателей я обычно не приглашаю: у меня плохо получаются танцы с преподавателями, я с ними теряюсь. Хотя и тут есть исключения, есть преподаватели, с которыми мне нравится танцевать (и могу только надеяться, что им со мной тоже нравится).

Есть ли у меня желание преподавать? Этот вопрос тут не случаен, ибо со мной регулярно пытаются заговорить на предмет преподавания кизомбы (и даже были попытки брать индивы, но я не дался). То, что я чего-то там преподаю, у меня на лбу написано, но на лбу не написано, что я сейчас главным образом преподаю системное мышление, системный менеджмент, системную инженерию -- вот и путают с кизомбой. Нет, желания преподавать кизомбу у меня нет, и нет никаких связанных с этим планов. Но время от времени я задумываюсь о текущей методике преподавания кизомбы, и у меня есть мысли о том, как можно было бы преподавать кизомбу, чтобы учить ей быстрее (в том числе на базе системного фитнеса), а удовольствия от танца у учеников было бы больше -- но эти мысли у меня нет планов воплощать самому. Так что я потихоньку думаю на эту тему, но только думаю -- и жду, пока вокруг меня появятся правильные для этого проекта люди.

Почему кизомба? Она крайне разнообразна и быстро развивается, это зонтичный стиль для многих и многих танцев, она ещё и музыкально всеядна. Куда развиваться? Интересны были бы (по разным причинам) зук, сальса NY, танго -- из социальных. Но ролики я смотрю больше всего сейчас по линии джаз-танцев, уж больно они там все заводные и танцуют под правильную музыку. Идеи танцевать джаз-танцы нет, ибо возраст не позволит. И возраст уже не позволит танцевать в сольных стилях -- мне всё-таки уже 60 лет. Но это всё очень вялые мысли, ибо для их реализации нужно забросить все остальные дела -- а кизомба и так занимает довольно много времени, я ведь не только на вечеринки хожу, но и продолжаю заниматься. Удовольствие от кизомбы растёт прямо пропорционально моему уровню танца, так что я не собираюсь прерывать занятия, я собираюсь и дальше увеличивать удовольствие -- повышать свой уровень. На другие танцы поэтому времени просто нет, так что разговор о них у меня только в сослагательном наклонении.

Какие планы? Дальних планов нет, а из ближайших -- улучшить свою осанку (распрямиться!), наладить классическую кизомба-базу -- как минимум, научиться не срывать кач в пол на высоких скоростях и более стабильно работать корпусом, разобраться с компой. Ещё я бы хотел повспоминать все те связки, которым меня учили два года в самых разных местах -- но я понимаю, что это нереализуемо. Так что смирюсь и сосредоточусь на работе с базой (чеклист для исправлений по этой базе у меня сейчас строчек на тридцать). Ибо базы мало не бывает, основное удовольствие от кизомбы в ней.

mykizombafoto
Thursday, October 4th, 2018
10:22 pm
Робототехника в 2018
Сегодня почти закончилась конференция по умным роботам и системам 2018 года (2018 IEEE/RSJ International Conference on Intelligent Robots and Systems, 1-5 октября 2018 в Мадриде), под лозунгом Towards a Robotic Society (и не пытайтесь перевести, а затем не пытайтесь откомментировать этот лозунг) -- https://www.iros2018.org/.

Что докладывают? То, что вопрос потихоньку смещается из вопроса про возможность-невозможность той или иной работы для робота в вопрос о цене робота -- и вопрос решается "гиперадаптацией", как у людей. Если у робота три пальца, то он всё одно сможет собрать кубик рубика, ибо ну очень эти три пальца ловки, прямо как у человека-инвалида: https://www.youtube.com/watch?v=KVGn8tP9klI. Престидижитаторство развивается у роботов чрезвычайно быстро -- сравни эту трёхпалую руку с обзорчиком в "робот-престидижитатор или экспоненциальные технологии на марше" в https://ailev.livejournal.com/1438640.html.

Если у робота одна нога, он будет прыгать на этой одной ноге так, как прыгает человек-инвалид -- демонстрируя чудеса ловкости -- https://www.youtube.com/watch?v=ZFGxnF9SqDE. У Boston Dynamics появляются конкуренты, было неформальное соревнование этих роботов -- https://www.youtube.com/watch?v=tZnKwOv0FUA. Прыгает там пока только Spot mini, но это ж понятно, что через полгодика будут прыгать-все. Зато после падения поднимается быстрее всего вездеход Anymal, но стабильность держит самый тупой -- Laikago. Собачка через пару лет станет студенческим проектом, как десяток лет назад таким проектом был какой-нибудь сегвей.

И уж если робот антропоморфен, но двигается медленно и поднимает каждой рукой только два с полтиной килограмма, то и такой хиляк всё равно сможет обшить стену гипсоплитами (это, пожалуй, наиболее радующая одних людей и пугающая других людей демонстрация: https://www.youtube.com/watch?v=ARpd5J5gDMk).

Экспоненциальные технологии, каждый раз либо вдвое по результативности при той же цене, либо вдвое дешевле при той же результативности. Кстати, вот версия презентации Тони Себа по подрывным технологиям в транспорте -- июньская 2018 (https://youtu.be/KVm74yE0aUE). Прошла пара лет с 2016 года, когда я писал про его презентацию "чистый подрыв, под всей цивилизацией сразу" https://ailev.livejournal.com/1307264.html, и он не изменил своих цифр, разве что кое-где сделал более резкие заявления. К 2030 году жизнь поменяется драматически, перелом (когда S-образная кривая интеллектуальног электротранспорта резко рванёт вверх и тренд станет заметным -- речь пойдёт о занятии первых 5% рынка) в 2020-2021 годах, а затем за десять лет всё будет кубарем. И это даже безо всяких там роботов. А с роботами, похоже, всё движется к тому же -- замечать-то журналисты будут всё антропоморфное или похожее на животных, но подорвут всю промышленность к чёртовой матери роботы неантропоморфные. Их и роботами-то называть не будут, как те самые "робомобили" или "роботакси" всё чаще и чаще называют "беспилотными", и всё реже реже именуют в каком-то смысле слова "роботами" -- даже если у них появляется голосовой интерфейс (а у чего сейчас нет голосового интерфейса? Алиса и Гугль уже высовывают своё чуткое ухо из любого утюга, и они в этом неодиноки). Граница между электронными фоннеймановскими и коннективисткими мозгами и изменениями в физическом мире стремительно размывается: киберфизические системы сегодня -- экспоненциальная технология.

Моя программа курсов дистантного обучения настоящей робототехнике (не путать с "образовательной робототехникой") вот тут: https://ailev.livejournal.com/1434868.html. Конечно, эта программа не доживёт и до 2020 года, в этой области нетленку не создашь. Всё быстро.

UPDATE: 11 октября вышло обновление достижений -- паркур антропоморфного робота Atlas от Boston Dynamics, https://youtu.be/LikxFZZO2sk
4:08 pm
Онтологическая инженерия в 2018
Онтологическая инженерия -- это подход и средства, позволяющие описать успешную онтологию. Успешная онтология -- это которая будет затем использована для реализации успешных систем. Такое "словарное определение" я смастерил по образу и подобию определения системной инженерии (Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal. -- https://sebokwiki.org/wiki/Systems_Engineering_(glossary)). Но не системная инженерия ближе всего к онтологической инженерии, а инженерия требований и инженерия системной архитектуры. Инженерия требований выявляет, описывает/документирует и далее использует описание системы как чёрного ящика, инженерия системной архитектуры занимается придумыванием и документированием описания системы как белого ящика. Онтологическая инженерия делает это не с системой, а с более сложным случаем: с какой-то предметной областью, domain. В пределе этой предметной областью является весь мир, но чаще всего это и впрямь одна или несколько довольно узких предметных областей. Какая-то с этим связанная терминология была дана в "Онтике онтологизации" https://ailev.livejournal.com/1427265.html.

Для меня важно сейчас, что методология онтологической инженерии (обсуждение методов онтологической работы) по факту имеет дело с онтологическими описаниями "по форме", а вот содержание этих онтологиxеских описаний может быть крайне разнообразным. Как и в методологии инженерии требований, мы обсуждаем разные форматы документирования требований, разные варианты моделей требований. Как в методологии работы с системной архитектурой разбираемся с формами архитектурных описаний (помним тот же ISO42010). Так и в онтологической инженерии всё то же самое, но акценты другие: описываем не систему, а какой-то промежуточный уровень стека абстракций, описание предметной области (про "глубокий стек абстрактности мышлений" и онтологические уровни см. в https://ailev.livejournal.com/1442975.html, а про абстракции как чеклисты см. в https://ailev.livejournal.com/1446993.html).

Работа с абстракциями, работа с описанием предметных областей ни разу не является прерогативой "настоящих онтологов". Как и с инженерией требований и с системной архитектурой главным образом работают отнюдь не дипломированные инженеры по требованиям и инженеры-архитекторы, так и с онтологическими описаниями работают в абсолютно других местах. Говорит прозой всё население земного шара, но не все знают, что они говорят "прозой". Так и тут: смотрим на деятельность, а не на то, как она называется. Где искать сегодня state-of-the-art онтологической инженерии? Прошлый мой пост на эту тему был ровно два года назад, "онтологии и бибинарная модель мышления" -- https://ailev.livejournal.com/1305176.html.

1. То, что происходит с классическими онтологиями и даже с computational ontology, просто пока сбрасываем со счетов. Там пока ничего не происходит, никаких прорывов. Всё очень трудоёмко и ждёт enablers из других областей (про машинное обучение заговаривают всё чаще). Поэтому тут притормаживаем, интересуемся теми местами, где всё бежит бегом.

2. Стандарты и публичные документы. Стандарты -- это где есть проверка соответствия. Публичные документы -- это где нет проверки соответствия, но в последнее время появляются разные формы проверки на их знание (т.е. они кладутся в основу учебных процессов, ибо в них документируется дисциплина). Все BoK как раз сюда и относятся. Я уже давно говорил, что методологическая/онтологическая работа происходит в области стандартизации -- в 2004 по механизмам стандартизации -- http://ailev.livejournal.com/212819.html, выступление по стандартизации как "месте, где живёт методология" в 2009г. -- http://ailev.livejournal.com/664154.html, или в 2012 я сопоставляю институализацию и стандартизацию -- http://ailev.livejournal.com/982274.html, или обзорчик по стандартизации роботов в 2014 году -- http://ailev.livejournal.com/1103887.html. Прорывов тут нет, она идёт, как идёт. Новые предметные области появляются и по мере созревания документируются в стандартах и публичных документах разной степени формальности, а это и есть онтологическая инженерия.

3. Разработка корпоративного софта -- это текущий state-of-the-art "классической" онтологической работы. Вот некоторая линейка рассуждений:
а) вся разработка корпоративного софта это внесение и исправление многочисленных багов, при этом баги могут появляться и из-за изменений во внешней среде, и приходить от собственных разработчиков. Цикл выпуска новых версий, в которых баги исправляются, сейчас недопустимо длинный. Поэтому DevOps -- это наше всё, непрерывная интеграция и выпуск тут цель и средство. Изменения вносятся маленькими порциями (small batch size) и выпускаются в жизнь очень быстро.
б) микросервисы позволяют ещё уменьшить порции выпусков, а также изолировать распространение ошибок по системе (это же модули!). Микросервисы содержат собственные данные, и они нарезаются так, чтобы как-то соответствовать business capability (оргвозможностям, см. про их связь с практиками в "к онтологии организационного моделирования": https://ailev.livejournal.com/1446903.html. А сами микросервисы (включая моделирование данных в них) делаются с использованием DDD (domain-driven-development), где одно из основных понятий -- это bounded context, поиск модульности в организации. На выходе тем самым мы получаем распределённые данные.
в) дальше мы должны обеспечить методы работы с распределёнными данными (включая изменения в моделях данных), в которых время от замысла до реализации изменения должно стремиться к нулю. Можно обсуждать, как это связано с онтологической инженерией (всё-таки онтологии это больше про типы, но ведь работа с типами бессмысленна, если в какой-то момент мы не обращаемся к индивидам -- и недаром в "классике" индивиды и абстрактные объекты рассматриваются как имеющие общую презентацию, хранящиеся и обрабатывающиеся в одной "базе знаний"). Тем не менее, задача именно такая: найти изменение предметной области, документировать его, далее вывести это документированное изменение в "эксплуатацию". Обычный инженерный цикл. Этот цикл хорошо описан в книжке Edson Yanaga "Migrating to Microservices Databases. From Relational Monolith to Distributed Data" -- http://b-ok.xyz/book/3493751/b6ab98. Тем самым DDD+DevOps+microservices = современная "классическая" онтологическая инженерия, да ещё со смещением акцента с чисто "разработки" к "эксплуатации" и в какой-то мере даже "вывода из эксплуатации" -- то есть просматривается работа с полным жизненным циклом онтологического описания, а не просто "академическое упражнение в описании мира".

4. Работы по машинному обучению, абсолютно неклассическая онтологическая инженерия. Часть работ по этой тематике я указывал в "компьютерной поддержке полного спектра формальности мышления" -- https://ailev.livejournal.com/1438749.html. Конечно, этот "спектр формальности мышления" нужно ещё как-то соотносить с "глубоким стеком абстрактности мышления" из https://ailev.livejournal.com/1442975.html (где вообще я рассказываю об онтологических уровнях как уровнях абстрактности -- и помним, что уровни нейросети выучивают разные уровни абстракции в рамках обучения представлениям, representation learning, http://ailev.livejournal.com/1045081.html). Тут работы идут главным образом по связке "классических онтологий" в виде knowledge graph и нейросетей с attention в этом графе -- это основной поток работ, типа Learning beyond datasets: Knowledge Graph Augmented Neural Networks for Natural language Processing.

Важнейшей чертой "классических" онтологий была возможность логического вывода по ним, всякие пруверы/солверы рассматривались чуть ли не как главное достоинство "формализации концептуализации" -- вплоть до заявлений, что "по чему нельзя логически выводить, то не онтология", появления важнейших новаций в модульности онтологий типа "микротеорий" именно на базе критерия непротиворечивости в части логического вывода. Похоже, что сейчас в этой части будут прорывы, и эти прорывы идут из абсолютно практической задачи создания вопросно-ответной системы, способной ответить на вопросы, относящиеся к разным документам (сделав при этом несколько тактов логического вывода). Это будет происходить, похоже, на базе "соревновательной науки" -- опубликован соответствующий датасет и baseline для отслеживания SoTA -- HotpotQA: https://hotpotqa.github.io/.

Но практическая онтологическая инженерия идёт много дальше этой notebook data science (когда кто-то придумывает очередной алгоритм и очередную архитектуру для представления данных в нейросети или в knowledge graph). И идёт по той же самой линии, которая была заявлена в предыдущем пункте с "классикой" из DDD+DevOps+microservices. В machine learning ключевым словом тут является pipeline -- "Getting Better at Machine Learning" https://medium.com/@rchang/getting-better-at-machine-learning-16b4dd913a1f прямо указывает, что всякие "соревнования" и победы в алгоритмах и представлениях это не вся инженерия! Инженерное решение должно закрывать полный жизненный цикл: от постановки задачи до использования результатов, поддерживаться должен полный жизненный цикл данных и их моделей (которыми можно в том числе считать и выученные на базе этих данных нейронные сети -- новая форма представления вероятностных онтологий, а inference в нейронных сетях -- новая форма использования онтологий). Pipelines (вариант того же самого: plumbing) в машинном обучении, которое мы будем считать одним из видов неклассической онтологической инженерии (там ведь тоже идёт работа с данными и их моделями!), активно сейчас нарезается на практики и получает свои инструменты -- "AI Plumbing: mapping the landscape", https://medium.com/digital-catapult/ai-plumbing-mapping-the-landscape-d213e41842d прямо говорит, что в эпицентре там DataTech, и там нужно как-то организовать данные, поместить данные в базу данных. А это прямая отсылка к классическому моделированию данных, классической онтологической инженерии. Всё в этой онтологической инженерии переплетено и смешано на многих уровнях: дискретные и коннекционистские модели данных поддерживают друг друга -- и в обозримой перспективе будут сосуществовать вместе. И тут появляется уже DataOps (см.также "от DataOps к NoOps" -- https://ailev.livejournal.com/1367897.html).

Ещё один аспект -- это проблемы модульности коннекционистских онтологий ("модульность", https://ailev.livejournal.com/1294242.html), то есть отсутствие "таблеток знаний". Тут огромное количество работ, из самых знаменитых работ последнего времени можно указать, например, использование pretrained language models вроде ElMo https://arxiv.org/abs/1802.05365, ULMFit https://arxiv.org/abs/1801.06146, июньской работы по комбинированию transformers и unsupervised pre-training от OpenAI https://blog.openai.com/language-unsupervised/. А ещё бесконечный поток по multitask learning, transfer learning и многим схожим до неразличимости направлениям -- это же тоже ровно оно для коннективистских онтологий, отражение всех этих идей по "микротеориям" в классике онтологии и reference data library в классике моделирования данных. Разделение труда, модульный синтез, все проблемы "моделирования в большом" ("онтологические модели -- это про проектирование/программирование/моделирование-в-большом", https://ailev.livejournal.com/748188.html, я писал это ещё в 2009).

5. Ещё одно направление работы в онтологической инженерии связано с тем, что в причинных моделях всё одно нужно иметь какую-то гипотезу по модели причинности, которую подтверждать или опровергать данными. И эта гипотеза, по идее, строится на онтологии -- её делает subject expert. Это ещё одно место, где можно ожидать интереса к онтологической инженерии ("Ложь, наглая ложь, и причинный вывод" -- https://ailev.livejournal.com/1435703.html). Мне также кажется, что попытка иметь "объяснимые модели" в нейронных сетях (гуглите "interpreting and understanding deep neural networks" -- этих работ огромное количество) это того же поля ягода, это попытка привязать когнитивистскую модель к модели какой-то theory theory "классической" онтологии, а для этого эту самую "классическую онтологию" нужно построить.

Одно очевидно:
-- онтологическая инженерия давно уже не существует под привычными для онтологов именами. Как всегда, прогресс приходит "сбоку". Онтологической работой занимаются не онтологи, достижения "олдовых онтологов" используются по минимуму. Это похоже на то, что происходит с философией в целом: инженеры, менеджеры, программисты по-быстрому переизобретают давно известные философские идеи, потому как получить их в приемлемой форме от философов не представляется возможным (те ж начинают не с сути дела, а с Платона и Аристотеля -- и до сути дела уже не добраться). Потом философы приписывают достижения всех этих творцов себе, типа "они ж давно говорили". То, что от их говорения при этом толку не было, не упоминается. "После того -- значит вследствие того" в философии это умолчание, а зря. Вот в онтологии наступают похожие времена: онтологической инженерией занимаются люди, практикующие DDD и моделирование данных, а их заслуги припишут себе академические философы, задним числом.
-- переход от онтологии (и даже онтологики!) к онтологической инженерии сразу даёт 1. выход на понятие жизненного цикла и обращает внимание на прагму: как, когда, в какой форме, кем используется результат онтологической работы, какие инструменты это поддерживают. 2. упор на модульность и модульный синтез как основную решаемую проблему -- уход от ontology engineering-in-the-small (laptop data science) к ontology engineering-in-the-large, со всеми этими идеями разделения труда и непрерывной интеграции в части объединения результатов труда.
-- классическое и когнитивистское онтологическое моделирование/моделирование данных уже сосуществуют, взаимно питают и дополняют друг друга, они отнюдь не отрицают друг друга. Заниматься в онтологической инженерии в 2018 году нужно и тем, и другим.
Tuesday, October 2nd, 2018
9:15 pm
Мои критерии оценки партнёрш в кизомбе
Почему я занимаюсь именно кизомбой? А просто кизомба не предполагает скорбного танго-фейса (хотя и это можно устраивать, если есть желание, но чаще на лицах расслабленная блаженная улыбка), а ещё кизомба бывает более драйвовая и быстрая, чем сальса, но и медленности, томности и чувственности в кизомбе бывает столько, что хоть с танцпола сбегай во избежание последствий. И каждый год она новая. В этом году, например, в неё стремительно вливается компа. Вот за это мы кизомбу и любим. Весь танцевальный мир в одном флаконе, да ещё и с пожалуй, самыми близкими обнимашками из всех парных танцев.

В эти выходные я урывками посещал кизомба-фестиваль DJ's Elite -- для меня основная фишка этого фестиваля в том, что social room переходит в party без объявлений, незаметно, и ничем IMHO не отличается (кроме вдруг внезапно увеличивающегося макияжа на лицах партнёрш). Приходишь, когда можешь, и уходишь, когда уже не можешь. Очень удобно. Для партнёрш основной фишкой фестиваля были многочисленные парижские танцоры-таксисты, но мне они неинтересны, так что "атмосферы Парижа" я там не заметил, она была только для девушков (и в отзывах девушков все восторги именно по этому поводу).

Я приходил рано вечером, уходил в районе полуночи, танцы там были доступны 72 часа круглосуточно, но больше этих нескольких вечерних часов мне было не выдержать. В воскресенье я поставил личный рекорд: танцевал почти восемь часов практически без перерывов. Идея фестиваля -- сделать праздник (главным образом французских) диджеев, так что это по задумке диджейский фестиваль. Диджеи веселятся, у них свой праздник и тусня, а поскольку их искусство без танцоров особого смысла не имеет, то присутствующим танцорам достаётся музыка не просто вялых знаменитых диджеев, а раскочегаренной диджейской тусовки. То есть на эмоциональную ступеньку выше, чем на "просто вечеринках". Диджеи ведь тоже люди, их тоже качает фестивальность. И формат самого зала (огромная высокая сцена с диджеями перед танцевальным залом) подчёркивала эту диджейную фестивальность. Про саму организацию фестиваля я дал отзыв тут: https://vk.com/wall-167384137_25508?reply=25568, но меня там больше интересовали танцевальные вопросы, нежели бытовые и организационные.

В одном послефестивальном чатике зашёл разговор о критериях оценки партнёрами партнёрш. Понятно, что никакого канона тут нет, все фломастеры на вкус и цвет разные. Но я вполне могу явно сформулировать собственные критерии.

Вот мои критерии оценки в поиске "идеальной партнёрши":

1. Танцует ли она со мной лично, или танцует с собой, музыкой и кем угодно ещё. При этом она может отлично и технично вестись, но эмоций в отношении лично меня ноль. А бывает отнюдь не ноль, вот это и ценю -- но это чисто субъективное ощущение. Сами партнёрши что при этом думают, мне неведомо.

2. Идёт ли легко на ускорения и ждёт ли на даблбитах и прочих замедлениях. Ибо если нет, то гудбай музыкальность.

3. База, которую понимаю тут как постуру (как стоять, где основная точка контакта в корпусе -- в животе или в солнечном сплетении, давит ли рукой сверху или прижимает сзади, удержание собственного баланса в любой точке) и "просто шагать" -- шаги в корпус, шаги вбок без приседаний, повороты на 180 на оси пары, ускорения, саиды без разрыва контакта, ронды и закресты. Это даёт возможность танцевать гладко, не спотыкаясь, обеспечивает connection. Я существенно почистил себе базу за последние месяца два, и это очень сильно добавило к танцу. Connection стал в разы лучше и с начинашками. Обычно это всё это про базу в совокупности называют "лёгкая партнёрша" (хотя к этому добавляют часто и умение вытянуться при поддержках). Так что я и сам стараюсь что-то делать со своей базой, и от партнёрши ожидаю того же.

3. Повороты: как девочки приходят в саиду после поворота, как они крутятся. Опытные партнёрши проворачиваются на оси, крутятся очень близко и всегда приходят "к партнёру" после поворота. Неопытные заранее неизвестно, в какой позе и где остановятся. И при повороте их болтает, никакой "оси".

4. Специфические кизомбические штучки: если тебя посылают в разлёт, то лети и не поворачивайся, во все четыре стороны (почему-то делают хорошо только в одну сторону). Если шаги, то с любого шага в любую сторону, в том числе закрытия на ускорении (делают не в четыре стороны, а только в одну). Как летают руки, если их куда-то подкинули.

5. Как работает корпус-бёдра на всяких таррашах-таррашиньях -- амплитуда, анимация ("покадровое движение", с остановками), что там где и как и с какой скоростью ведётся, где танцует само, где гнётся, где не гнётся, не делает ли голова camel style с корпусом и прочая. Это отдельная вселенная, год назад этим мало кто владел вообще, сейчас прошло массовое научение, и стало получше. Но всё одно, если брать девушков из регионов, то они тут сильно отстают: там разных стилей-подстилей, вариантов очень много, и пока даже непонятно, как это всё обсуждать, одного языка нет. Условно можно поделить на тех, у кого даже бёдра не двигаются, у кого волны умеют только до солнечного сплетения, но само сплетение только неподвижно; для меня ещё те, кто всё делает, но чуть-чуть, но я их оказываюсь уже гибче (бывает!), кто умеет изолировать лево-право , и т.д. и т.п. -- тут отдельный мир, и с ним ещё нужно разбираться. У меня одна партнёрша танцевала несколько вечеринок подряд "хорошо", но потом вдруг расслабилась, по её словам "выключила голову", и стала в моих руках в этом отношении вообще волшебной (но у неё, правда, там был и зук в анамнезе, и много чего ещё) -- то есть это всё, оказывается, тоже "по настроению" и ситуативно.

6. Lady style, когда он не мешает ведению (опыт показал, что у начинашек он таки мешает ведению, и сильно). Но в танце это может быть очень, очень интересно -- просто наблюдать за тем, что вытворяет партнёрша, слушать дополнительную ритмику от её движения. Встречал образцы крутейшего lady style, которые на ведение не влияли никак -- самому даже интересно, как это всё можно делать!

7. Интересно, если партнёрша умеет вести. Тогда можно пробовать делать диалог в танце, и это увлекательно.

Увы, по этим всем довольно жётским критериям совсем идеальных партнёрш для меня не было. Но отличных и просто хороших -- много! И это меня радует. Тут нужно заметить, что и я ведь далеко не идеал как партнёр. Я не знаю, как оценивают партнёрши меня (молчат ведь на этот счёт, как рыбы -- "нормально ты танцуешь, не переживай"), но об их критериях оценки партнёров можно догадываться по самым разным замечаниям, которые я от них получал:

1. Внятность и музыкальность ведения должна быть в любой момент времени, но ведение должно быть не резким. Это главное, но это очень странный пункт, его непонятно как тренировать, и даже как понимать -- это сугубо индивидуально для партнёрш, и зависит от их настроения, обуви, музыки и т.д.. Проблема в том, что внятность для одних партнёрш -- это будет буквально шёпот для других и резкий крик для третьих. И тут предпочтения не угадаешь (разве что начинашки обычно любят ведение погромче, а опытные партнёрши на это обижаются -- но и тут бывают разные ситуации). Тем не менее, часто вижу на танцполе многих партнёров без явной базы, но с внятным и мягким музыкальным с точки зрения партнёрш ведением -- и ими, вроде, партнёрши явно как-то довольны. Хорошее ведение прощает в глазах партнёрши всё остальное.

2. База, без которой не будет connection. А connection это путь к сложным элементам и разным вариантам космоса (у меня был текст https://ailev.livejournal.com/1315064.html -- там, правда, нет ещё сегодня уже общепризнанного разделения connection и "космоса". Надо бы его обновить, знаю-то я предмет уже существенно побольше). Понимание базы у всех партнёрш разное, так что не угадаешь.

3. Чтобы было не скучно. И тут Рони Салех рулит (https://ailev.livejournal.com/1376152.html, https://ailev.livejournal.com/1376374.html): в танце должно быть всего понемножку -- и бегать, и медленно ходить, и залипать, и крутиться, и блокировать, и на рамке, и на корпусе и т.д.. Фишки тут не обязательны, всё это можно делать и на базе, но одна фишка на трек тут тоже пойдёт в зачёт. И опять же, всё индивидуально: некоторые партнёрши очень любят поддержки, и в количестве, а некоторые их терпеть не переваривают. Не угадаешь.
4. Никаких залипушек (к которым отнесём все многочисленные варианты тараш-компы-дусера), если не продемонстрировано хорошее умение бегать ножками. Если ты не мачо из Голливуда, то в первом-втором треке поползновение на залипушки -- презумпция виновности, и точка (хотя если диджей вдруг заиграл свой космос, то такова судьба, и от неё не уйдёшь). Но дальше опять же -- некоторым залипушки надоедают быстро, а некоторые наоборот -- против, если после недолгих залипушек с ними потом хочется побегать-походить (они улетают в свой космос, и им не хочется возвращаться обратно). Не угадаешь.
5. Очень многие партнёрши хотели бы перехватывать ведение, причём не для того, чтобы "показать сильного человека", а просто чтобы выразить собственное понимание ритмики в музыке. Но а) они стесняются б) не знают, как, в) не замечают, когда делают это -- даже не осознают, г) у них шанс это сделать есть только с девушками, но им хочется танцевать с юношами (а хоть и шестидесятилетними, как я) -- и выражать свою музыкальность, хотя бы изредка, почему бы и нет? И вот тут нужно просто быстро подстраиваться. Я, когда это просёк, то сразу получил огромное конкурентное преимущество перед другими партнёрами ))) Одна довольно известная партнёрша даже сказала, что я для неё одно из двух "открытий года" -- при этом IMHO она даже не слишком осознавала, насколько она время от времени перехватывает инициативу в танце ))) Но и тут: некоторые не любят даже себе признаться в таком поведении, поэтому с ними этого ни в коем случае делать нельзя.

Так что по всем пунктам оценки партнёршами партнёров у меня стоит "не угадаешь" -- в конечном итоге либо звёзды сойдутся, и тебя одна партнёрша оценит высоко, а другая не очень, либо звёзды не сойдутся, и будет ситуация ровно наоборот. В любом случае, от партнёра требуется большой диапазон умений -- и чуйка, без которой весь этот диапазон будет использован неправильно. Поэтому каждый пункт тут интересен тем, на что обращать внимание, а не тем, что по каждому пункту делать.

Я сам просто прокачиваю свои умения по этим темам, а там как свезёт: каждая партнёрша это лотерея. Тем более что каждая партнёрша разная сама с собой в разные моменты времени. Как и для каждой партнёрши партнёр оказывается такой же лотереей. И тоже в разные моменты один и тот же партнёр может быть разным. Меня иногда разносит так в танце, что мама не горюй, а иногда я вял, сдержан и компактен -- и кому-то нравится одно, а кому-то другое.

UPDATE (по итогам переписки в ЛС):
1. camel style — это когда волна в теле вдруг проходит в голову, или начинается с головы. Голова при волнах должна всегда оставаться неподвижной, в изоляции, если это кизомба. Вообще-то в разных видах тарраши волна вообще не поднимается выше солнечного сплетения, но в последний год это правило существенно нарушается.
2. Угадать, что партнёру инициативы в ведении будут приятны, нельзя — если только прямо не спросить или не знать заранее от кого-то. Мне интересно, когда меня пробуют вести, но есть партнёры с "домостроем" в голове, и с ними это может кончиться фатально, занесением в чёрный список.
3. Компу ставят музыку на кизомба-вечеринках сейчас часто уже и в Москве, но танцуют под неё главным образом "просто кизомбу". А тут Алёна Фортунова ткнула нас в танцующих на DJ's Elite парижских таксистов, сказала "вот так в Париже танцуют компу, нужно и нам так уметь". И в этот понедельник у неё в старшей группе пару часов мы уже разучивали, как двигаться в компе. Увы, роликов нормальных "культурной кизомбической компы" в интернетах нет, там всё какие-то другие "народные компы".

UPDATE: обсуждение вконтакте -- https://vk.com/wall2449939_1884
Friday, September 28th, 2018
4:24 pm
Французская кизомба в Москве
В эти выходные у меня большие танцульки, я иду на "французский фестиваль в Москве" DJ Elite (https://vk.com/thedjselite):
DJElite_2018

Из интересного на этом фестивале -- разнообразие привезённой в Москву французской элиты диджеев. На Западе на кизомба-вечеринки ходят как раз "на диджеев". Диджеи задают музыкой настроение и даже подстиль танца. Вот и послушаю.

Я записывался на все эти "фестивали выходного дня" ещё весной и ранним летом, и они казались далеко "осенью" -- на поверку же вышло, что все они случились в сентябре. Это третьи большие сентябрьские танцульки. И как и в остальные разы, я буду на этом фестивале только часть времени. Так, завтра у меня вместо тамошних мастер-классов собственные развлечения в МФТИ со своими студентами. Но и работать эти выходные целиком я не собираюсь: полноценно к работе вернусь только в понедельник.

Вот видео, где можно увидеть образцы меня танцующего в тепличных условиях студии: https://vk.com/video247400234_456239113, https://vk.com/video247400234_456239104, https://vk.com/video247400234_456239093. Это примерно уровень старшей группы, я танцую "с нуля" уже пару лет. На вечеринках (и дневнинках -- на фестивалях круглосуточно работает social room, который та же вечеринка, только днём) всё это поразноборазней (примеры -- https://ailev.livejournal.com/1373388.html, https://ailev.livejournal.com/1435210.html), исключительно импровизационно (это только на занятиях "танцуют строем"), да и сложнее танцевать, ибо места для танцев не так много, как в студии. То, что партнёршу ты эту можешь видеть первый раз,я даже не упоминаю -- это основная особенность социальных танцев.
1:27 pm
Список дисциплин личного развития как чеклист чеклистов
По Нильсу Бору профи -- это тот, кто не делает в какой-то предметной области типичных ошибок новичков. По Талебу успех рационального фланёра в том, чтобы не быть лохом -- не делать грубых ошибок "по глупости". В книжке Гаванде "Манифест чеклистов" (https://ailev.livejournal.com/1029295.html, она уже и по-русски есть) утверждается, что ошибки "по глупости" делают и опытные люди. И отличным средством от этих ошибок являются чеклисты. Чеклист в книжке понимается расширенно: план-график, в котором прописано 3264 работы объявляется чеклистом, по которому проверяется, действительно ли выполнены работы. Чеклист даёт список важнейших/контрольных вопросов, в решении которых ты должен убедиться, чтобы снять риски, чтобы не оказаться лохом, чтобы не сделать новичковой ошибки просто по замотанности в условиях вечного повседневного пожара и аврала. И чеклист, который по сути не делает ничего, кроме привлечения внимания к важным вещам, оказывается самым дешёвым и эффективным средством повышения результативности работы.

В трехмесячном тесте в восьми больницах на 4000 пациентах технология чеклистов снизила серьезные послеоперационные осложнения на 36%, смертность на почти 50% -- а в абсолютных цифрах предотвращено было 150 случаев серьезного ущерба и примерно 30 смертей пациентов -- http://metamodern.com/2010/11/03/for-the-next-nobel-prize-in-medicine-i-nominate/ Предоперационный чеклист -- листочек с 19 тщательно разработанными вопросами, в первой версии даже не касающимися специфики (какой орган) предстоящей операции.

OMG Essence в основе своей тоже имеет чеклисты: "Основы предполагают, что достижение состояний со всеми отвеченными утвердительно контрольными вопросами обеспечивается тяжёлой работой, их достижение необходимо, и отрицательные ответы означают, что работы было недостаточно. Незаданный вопрос (или нечестный ответ на вопрос) -- это классические грабли, на которые наступают по самым разным причинам, хотя об их существовании прожужжали все уши, всем они известны, но... хотят как лучше, получается, как всегда. Чеклисты Основ -- именно об этом, о возвращении к основам, о проверке тривиального" -- https://ailev.livejournal.com/1059869.html.

В "глубоком стеке абстрактности мышления" (https://ailev.livejournal.com/1442975.html) я писал: "высокоуровневая онтология используется как чеклист для мышления о ситуации/проекте: можно понять, что в ситуации продуманно, а что ещё требует рассмотрения и может содержать потенциальные риски". Жизнь бесконечно богата на детали, и непонятно, на чём сосредоточиться, нужно бы знать, что важно -- о чём обязательно нужно подумать, не забыть за суетой будней. Онтологии абстрактных дисциплин (например, системного мышления) представляют собой наборы важных высокоуровневых понятий, тесно связанных между собой.

Вот понятия системного мышления: http://ailev.livejournal.com/1278600.html. Этот очень короткий список можно трактовать ровно как универсальный чеклист, предотвращающий от ошибок невнимательности. Если тебе рассказали про модули -- спроси про компоненты и размещения; если продумал проверку, вспомни о приёмке; если дают описание, поинтересуйся методом описания, если смотришь на человека, думай о стейкхолдере и его интересе. Конечно, у этого списка есть сложность: его трудно понять. Трудно отождествлять эти понятия с объектами реальной жизни. Если ты это не освоил, то системное мышление не помогает тебе управлять вниманием, не привлекает твоё внимание к важному -- и оно погрязает в перебирании огромных количеств неважного. Мысль не взлетает, перестаёт быть абстрактной, а стелется низко-низко. И ты делаешь новичковые ошибки, становишься лохом.

В тексте "Почему не работают трёхдневные тренинги ни для инженеров, ни для менеджеров" (https://ailev.livejournal.com/1430047.html) я писал, что попытки применения знаний трёхдневных тренингов в реальных ситуациях приводит часто к катастрофе из-за того, что при применении этих знаний не учитываются множество других важнейших вопросов (грубо говоря, если ты освоил хитрый метод починки сердца во время операции, но делаешь эту операцию столовым ножом, без анестезии, не помыв руки, то успех починки сердца будет равен нулю: тебе не хватает понимания ситуации в целом, а не понимания только особенностей починки сердца).

Фундаментальное образование даёт нам чеклисты, предотвращающие такие ошибки за счёт привлечения внимания к важным аспектам ситуации. Эти предметы-чеклисты сводятся к небольшому списку образовательных предметов:
-- кругозор в виде начальных знаний по онтологиям самых важных объектов примерно полутора десятков сфер человеческой деятельности (https://ailev.livejournal.com/1443370.html).
-- методологические дисциплины (онтологика, системное мышление и т.п.) и когнитивистика (это то, чем стала психология, когда перестала заниматься душой -- психопрактики, прокрастинатология и т.п.) -- пункт 1 в https://ailev.livejournal.com/1443837.html.

И уже поверх этого случившегося системного развития личности становятся полезными трёхдневные тренинги.

Я считаю, что сам список фундаментальных "чеклистовых дисциплин" -- это тоже чеклист, и может использоваться для планирования развития личности по направлению "не быть лохом".

Поэтому я в слайды с аннотированными списками этих дисциплин для третьего потока тренинга "как оставаться востребованным специалистом в эпоху перемен" (я сам называю его "как выжить в эпоху перемен перемен" -- http://system-school.ru/uptodate) вставил места, где участники тренинга могут по десятибалльной системе проставить свои оценки по компетентности в этих предметах. Дальше у меня в планах сделать какой-нибудь более точный диагностический аппарат, чтобы это была не "самооценка" ("умный ли я в _______? А то!"), а результат тестирования.

Пункты списка этого "чеклиста развития личности" привлекают внимание участников тренинга к фундаментальным дисциплинам, и не дают сделать новичковые ошибки в планировании развития своих личностей.

Конечно, однодневный (два вечера) тренинг -- это даже не трёхдневный тренинг. Ничего особо содержательного менеджерского или инженерного освоить на этом тренинге нельзя. Но вот аннотированный чеклист для чеклистов (по факту -- аннотированный список дисциплин современного фундаментального образования) получить можно. А дальше уже дома потихоньку разбираться в нём и планировать шаги развития -- книжки ли читать, или на курсы ходить, или усиливать уже освоенное, или срочно затыкать дырки, или плюнуть и ничего с личным развитием не делать.

Ничего не делать тоже нормально. Конечно, чеклисты снизили смертность от операций на 50%, но и без чеклистов многие (хотя и не все) люди после операций выживали. И строили тоже безо всяких планов-графиков и других видов чек-листов, по паре сотен лет на какой-нибудь собор. С личным развитием можно так же, никто и не заметит.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10213873986617875
Tuesday, September 25th, 2018
4:10 pm
К онтологии организационного моделирования
До 40% времени всех дел уходят не на собственно дела, а на их организовывание: на то, чтобы какие-то малознакомые или даже хорошо знакомые люди поделили между собой труд так, чтобы на выходе был осмысленный для них всех результат. Речь тут не идёт о прокрастинации, когда ничего не происходит, потому как "нет воли" у человека, или "нет политической воли", если речь идёт о какой-то организации. Нет, всё происходит, никто не отлынивает, только 40% времени занимает "договориться" (координация, лидерство и т.д.), и всего 60% занимает "сделать". Поставьте в это отношение любые проценты из своей практики, отклонения тут бывают на порядки величины, суть от этого не меняется.

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

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

Стейкхолдер -- Иван Петрович Сидоров, который играет стейкхолдерскую роль инженера так же, как он бы играл роль Принца Гамлета в театре. Стейкхолдерскую роль (как реагировать на ситуации так, как реагировал бы "настоящий инженер") он выучил ещё в инженерном вузе, она культурно обусловлена, играл Иван Петрович Сидоров эту роль во множестве театров, тьфу, предприятий.

А ещё стейкхолдер -- это тот же Иван Петрович Сидоров, который играет роль менеджера проектов, как он играл бы роль Офелии в театре. Роли этой он не учил, но она тоже культурно обусловлена, поэтому Иван Петрович нахватался каких-то слов ("план-график", "сдвинуть вправо", "поздний старт") у коллег, и даже как-то на ночь читал какую-то книжку (хотя мало что в ней понял, пробормотал "не про наши фирмы" и заснул на середине третьей главы).

В этом плане Иван Петрович внутри себя актёр, обладающий многими компетенциями (то есть выучивший роли и имеющий опыт игры) по стейкхолдерским ролям инженера и менеджера проекта. У него крутые компетенции инженера и сомнительные компетенции менеджера, но уж какие есть. Трудно найти талантливого актёра, который одинаково хорошо играл бы и Принца Гамлета, и Офелию. Когда Иван Петрович задействует свои компетенции (умение действовать в роли "по ситуации"), то он или инженер, или менеджер проекта. Когда он определяет, играть ли ему вообще эту роль (выйти из ситуации), учить ли ему следующую роль, или жаловаться на сотрудников по спектаклю, тьфу, работе, то он -- актёр. В какой-то степени можно сказать, что актёр это принимающая на себя роль и играющая эту роль часть личности, а стейкхолдер это знающая роль часть актёра.

Оргзвено -- это какое-то подразделение или коллегиальный орган предприятия, имеющий полномочия по распоряжению ресурсами (выдавать поручения, то есть просить другие оргзвенья что-то сделать), или даже непосредственно потреблять ресурсы, которые нельзя о чём-то попросить, например, заюзать 3D принтер на полдня, если это принтер принадлежит оргзвену. "Принадлежит" в данном случае трактуется как то, что принтер является по факту физической частью оргзвена -- все молекулы принтера входят в состав молекул оргзвена. Коллективную принадлежность принтера ряду оргзвеньев мы пока не рассматриваем, но оргзвено может состоять из других оргзвеньев и коллективную принадлежность мы будем решать по этому пути: говорить, что молекулы принтера просто являются частью оргзвена, в котором есть и другие оргзвенья.

А ещё оргзвенья сотрудничают, и в этом плане принимают на себя обязательства, то есть обещают другим орзвеньям что-то сделать и делают это. Вот это сотрудничество оргзвеньев (выдача друг другу поручений, выполнение работ и их приёмка) и называется организацией. Если известно, кто кому что может поручать, и кто эти поручения должен бы выполнять без особых споров, то это и есть организация. Подробно об этом рассказано в книжке DEMO (https://ailev.livejournal.com/644440.html), и речь идёт о координационном/коммуникационном аспекте разных предприятий/предпринятий.

Самое маленькое оргзвено -- из одного актёра, который назначен быть этим оргзвеном. Так что Иван Петрович как личность в тот момент, когда он актёр и играет роль инженера, является оргзвеном, а оргзвено является Иваном Петровичем. Иван Иванович принят на работу оргзвеном (т.е. на должность инженера) в секторе перспективных разработок оргзвена ООО "Промсбытмонтажинновация". Но если Иван Петрович ещё не приступил к работе, то оргзвено никакое не звено, это организационное место. Хотя люди говорят о них одинаково, но организационному месту работу не поручишь, а вот организационному звену (частям личностей, которые в нём работают) работу поручишь. Оргзвено -- это заполненное каким-то актёром оргместо.

Если Иван Петрович устал и сонный рассуждает на работе с окружающими его так же прокрастинирующими личностями о столетней давности урожае бахчевых на аризонщине, то он "просто личность". Если он спорит, что не он должен "подтирать за этими идиотами из соседнего отдела, пусть сами проверяют свои 3D-модели!", или "не буду я рисовать план-график, это пусть менеджер рисует, я лучше второй вариант теплообменника обсчитаю", то это в нём актёр капризничает по поводу игры в какой-то стейкхолдерской роли в какой-то ситуации. Но это редко (в DEMO это называют "выход в дискурс"), чаще Иван Петрович как личность в подобных ситуациях вздыхает, а потом честно впахивает как инженер, или (много реже) менеджер проекта. Но эти ситуации спора трудно обсуждать, если не различать оргзвенья (думать в этот момент нужно об органиграмме), актёров (которые спорят и выдают обещания играть по той или иной роли) и стейкхолдеров (которые обладают нужными для работы компетенциями и собственно работают). Лидерство как раз является практикой, которая занимается совмещением личностей и оргзвеньев, учитывая тот факт, что внутри личностей есть актёры и стейкхолдеры, а оргзвенья нужны в той мере, в которой на оргзвенья назначены стейкхолдерские роли.

Когда актёра с оговорёнными компетенциями ("инженером буду, менеджером могу, но посудомойкой не буду, хотя посуду мыть умею, компетенции в посуде есть, но они не про вас") из Ивана Петровича назначают на оргместо, то это означает, что с момента назначения Иван Петрович приобретает полномочия и обязанности этого оргместа, становится частью организации. Появляется оргзвено.

"Назначение" это способ сказать, что с момента назначения два объекта -- это один и тот же объект. С момента назначения актёр, играющий роль инженера в Иван Петровиче и инженерная вакансия инженера в наполовину существующем оргзвене ООО "Промсбытмонтажинновация" (наполовину существующим -- потому как половина там оргзвеньев, а половина только "плановые оргзвенья", то есть вакансии есть, а людей нету) стали одним и тем же -- оргзвеном "инженер" в оргзвене ООО "Промсбытмонтажинновация" или "инженером Иваном Петровичем". Названий много, обсуждаются под этими названиями разные вещи (набор компетенций актёра Ивана Петровича, требуемые компетенции для оргместа инженера, владение этими компетенциями на необходимом уровне зрелости актёром Иваном Петровичем, достаточность времени нахождения актёра в роли, договороспособность актёра Ивана Петровича, злобность характера личности Ивана Петровича и его манеру выражения, и т.п.), и много разных ошибок делается, если путаются должность и стейкхолдерская роль, стейкхолдер в роли и требуемая компетенция игры по этой роли, организационное место и организационное звено. Особенно часты проблемы в том случае, если не прошло операции назначения: факт назначения не состоялся, и о назначении никто не узнал. "Организованность" это как раз оно: понятные всем и очевидные назначения -- после "организации" понятно, кто за что (за игру каких ролей, то есть выполнение каких работ) отвечает и кого о чём можно попросить.

Можно обсуждать, Ивана Петровича назначают стейкхолдером-инженером, или роль инженера назначают на Ивана Петровича. Принято говорить, что актёров назначают на роли в пьесе, а не роли на актёров. Так понятней, ибо актёр (человек) может что-то сделать, а роль без актёра -- ничто, Принц Гамлет не существует, пока на его роль не назначат актёра и этот актёр не начнёт играть именно эту роль. Для этого нужно договориться с актёром, чтобы его назначить. Так что отношение "назначения" с одной стороны ненаправлено (означает, что назначенные друг на друга объекты -- "одно и то же" с момента назначения), а с другой стороны направлено, причём направленность указывает на момент начала этой "одноитожести". Как всегда, аристотелевская физика проникает в язык: палец давит на стол, а стол не давит на палец. Так и человека назначают на место, а не место на человека. В ньютоновской же физике разделяют обсуждение того, каким образом человек и место стали оргзвеном (кто там на кого надавил что там на что было назначено -- событие назначения), и что будет после этого события (каковы ипостаси участвующих в назначении объектов, "одноитожность" объектов). То есть различаем "событие назначения" и "отношение назначения".

Разница оргместа (вакансии) и оргзвена (заполненной вакансии, после назначения актёра на оргместо) не уникальна. Примерно так же связаны практики и оргвозможности, оргвозможности и работы.

Актёр Иван Петрович выучил роль инженера и приобрёл недюжинный опыт игры в этой роли. Это значит, что он загрузил себе в голову дисциплину инженерии (не будем тут уточнять, какой именно инженерии. Небольшого кусочка какой-нибудь инженерии нам хватит для целей этого текста). А ещё Иван Петрович для работы пользуется 3D принтером. Практика -- это как раз то, чем обычно занимаются люди, имеющие в голове дисциплину и пользующиеся при этом какой-то технологией. Можем ли мы говорить, что в ООО "Промсбытмонтажинновация" есть оргвозможность (capability) что-то напечатать на 3D принтере, если там есть и технология 3D принтер, и умелый инженер Иван Петрович как стейкхолдер, практикующий дисциплину инженерии? Нет. Мы можем разговаривать о практике, обсуждать разные аспекты этой практики в деятельности людей вообще. Но ничего напечатано не будет до моментов необходимых назначений: Иван Петрович должен стать оргзвеном сам (чтобы получить возможность принимать обязательства/давать обещания и самому поручать что-то, например поручать закупать расходники для принтера людям в бухгалтерии), и в составе его оргзвена (сектор перспективных разработок ООО "Промсбытмонтажинновация") должен появиться принтер, а ещё как-то должна быть налажена закупка комплектующих -- кто-то тоже должен быть на это назначен. Вот после того, как прошли все назначения, у нас появляется оргвозможность aka "поставленная практика".

И эта оргвозможность (все выполненные организационные назначения с полученными обещаниями эти назначения выполнять) как раз и предоставляет сервис как поведение на каком-то интерфейсе оргзвена, назначенного на выполнение необходимой практики. Тем самым оргвозможность -- это организация, в которой укопмлектованные людьми и оборудованием оргместа стали оргзвеньями, и в них существует сотрудничество в той мере, в которой можно выполнить какие-то практики (распорядиться ресурсами в виде людей, оборудования, расходников). Внешнее поведение всех сложных цепочек взаимных поручений приводят к одному "окошку", где и оказывается сервис -- происходит внешне важное поведение на оргинтерфейсе (интерфейсе оргзвена), во внешней по отношению к оргзвену действительности появляется непоправимая польза. Так что "оргвозможность = практика плюс назначения/организация" ровно так же как "практика = дисциплина плюс технология". Если нет организованности, то практики не выполняются, весь пар уходит в "координацию", бессмысленную и беспощадную, занимающую 100% времени.

Но и иметь оргвозможность (поставить практику, то есть нанять Ивана Петровича, купить для него принтер и вменить в должностные обязанности Ивану Петровичу печатать в 3D по свистку всех проходящих мимо других инженеров) недостаточно, чтобы реально что-то напечатать, чтобы сервис оказался задействованным и работа выполнена. Нужно ввести ещё понятие работы, как использования сервисов. Работа, которая должна вести к результатам работы оргзвеньев, должна как-то быть нарезана на куски, которые оргзвенья способны принять и выполнить -- задачи/задания. Про работу мы будем думать как про оргзвенья, занятые её выполнением (обычный ход на 4D онтологическое рассмотрение деятельности) -- и интересует нас в этот момент выполнение обещаний про сроки и ресурсы, а также логистические проблемы, связанные с выполнением этих обещаний. Это операционный менеджмент. Операционного менеджера интересуют оргзвенья, как выполняющие работы (то есть оргзвенья в конечном итоге!). Так что и наш Иван Петрович, извлекая из памяти компетенции проектного управляющего вдруг начинает думать о сроках, ресурсах и о том, чего не хватает для того, чтобы вот прямо сегодня вечером отдать результаты 3D печати, как об этом было ранее договорено с клиентом.

Впрочем можно точно так же думать про эти оргзвенья и про то, что они в этот момент выполняют практику. Практика и работа в момент выполнения работы -- это одно и то же, работа назначена на практику, а практика назначена на оргзвено. С теми же отождествлениями и различениями "события назначения" и "реального отождествления", что и в случае оргмест и оргзвена. Как "оргместо" живёт в проектах (и как проект/design и как проект/plan) и договорённостях по поводу воплощения задуманной организации, а в жизни мы видим оргзвенья, так и практика живёт в проектах задуманной деятельности по получению результатов какого-то типа, пока она не реализуется/воплощается в работах. Хотите получать прототипы деталей через пару часов после их проектирования -- займитесь организационной инженерией: запланируйте оргместо для инженера, компетентного в 3D печати, купите принтер, наймите актёра, исполняющего роль этого инженера. Задействуйте лидерство, чтобы актёр радостно выполнял свою роль инженера, а не саботировал её. А чтобы получить реальную деталь, так ещё и поручите ему конкретную работу в рамках операционного менеджмента.

Так что в конечном итоге все заинтересованные в работах Ивана Петровича и его принтера обсуждают его и принтер, но используют при этом разные слова в зависимости от того, что именно обсуждается. И слова при этих обсуждениях используются разные, слов много, и предусмотреть и обсудить нужно много чего, чтобы хотелки по поводу работы превратились в настоящие работы. Содержание поста вполне можно использовать как чеклист (что уже обсуждено, а что ещё нужно обсудить) по организации какой-то деятельности таким образом, чтобы в конце концов произошли какие-то реальные работы (подробней о том, как высокоуровневые онтологии использовать в качестве чеклистов см. в "глубоком стеке абстрактности мышления", https://ailev.livejournal.com/1442975.html).

На темы этого поста также полезно ознакомиться с:
-- SysArchi, https://ailev.livejournal.com/1444887.html
-- слова-термины важны, и не важны, https://ailev.livejournal.com/1442764.html (тут пример как раз -- оргвозможности, capabilities).

Идея в том, чтобы моделировать в одном описании (текстовом или диаграммном, тут неважно) все эти разные аспекты организации. Так что этот пост к обсуждению метамодели для SysMoLan (https://ailev.livejournal.com/1446524.html) в той части, в которой она касается моделирования архитектуры предприятия.

И, конечно, что не сказано в этом уже не слишком коротком посте, так то просто не сказано, а не "этого нет". Концепция открытого мира. Обсуждается маленький кусочек enterprise ontology, а не полная и детальная онтология. Например, никак тут не обсуждается целеполагание, а оно важно. Или вот один из неявных тезисов моего поста, который я попытаюсь раскрыть полней в другом тексте: имена часто выбирают в зависимости от степени реализации -- чтобы в речи не путать"как запроектировано" и "как реализовано". Практика (она потенциальна, в проекте) и оргвозможность (поставленная практика). Должностная вакансия (должность это сокращение ведь -- суть в том, что есть вакансия, оргместо) и сотрудник в должности (вакансия заполнена).

При этом предлагаемая онтология обсуждается достаточно неформально, а то при любой попытке навести онтологическую строгость из ниоткуда появляется столько понятий, что никакую жизнь под них уже не подведёшь. Мы будем пытаться рассуждать примерно на таком уровне строгости, на котором определяется ArchiMate, но делать при этом онтологические выборы получше, уж как мы понимаем это "лучше".

UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10213856153132049
Monday, September 24th, 2018
7:19 pm
SysMoLan Studio
Развитие моделеориентированной системной инженерии требует появления инструментов системного моделирования, который позволит иметь в одной модели целевую систему (железо/бетон, электроника, софт) в её системном окружении, так и обеспечивающую систему (расширенное предприятие). Более того, моделирование с использованием этих инструментов должно включать в себя интеграцию данных архитектурных и мультифизических расчётов, а также обеспечивать аналитические (например, проверку целостности модели) и синтетические (алгоритмическое построение части модели) запросы к модели. Желательно также предусмотреть возможность оптимизации моделей, например для поиска математически оптимальной архитектуры (поиск-ориентированная инженерия).

Текущие языки системного моделирования (SysML, AADL, Capella для моделирования целевых систем, UML для моделирования программных систем, ArchiMate для моделирования предприятий, SyM для связи системного и мультифизического моделирования в Modelica) не дают этих возможностей. Проект SysArchi, предпринятый Русским отделением INCOSE в 2018 году показал, что системное моделирование целевых и обеспечивающих систем в рамках ArchiMate 3.0 крайне неудобно, а традиционных языках системного моделирования по факту невозможно моделировать предприятие.

Исследовательский проект .15926 TechInvestLab по созданию моделера и платформы инженерного моделирования на базе инженерной онтологии и форматов языка ISO 15926 показал неудобство работы с низкоуровневыми представлениями для концептуального моделирования и подчеркнул необходимость использования языка программирования как для описания моделей, так и для манипуляций с моделями (создание моделей, запросы к модели). Сам проект .15926 имел акцент на создание системы мэппинга (интеграции данных) инженерных моделей, полученных в составе различных систем и меньше уделял внимание на аспектах создания системных моделей инженерами. В то же время проект .15926 показал, что программное создание объектов моделирования и представление моделей систем в текстовом и псевдографическом виде очень и очень перспективно, графические же представления "визуального моделирования" ограничены в их использовании. Это положение примата текстового представления для манипулирования большими и подробными моделями было подробно обосновано в книге А.Левенчука "Визуальное мышление. Доклад о том, почему им нельзя обольщаться". Проект по моделеориентированному концептуальному проектированию с использованием визуальных представлений на ArchiMate и манипулированием этими представлениями из языка R показал перспективность подхода использования языка программирования для работы с архитектурными системными моделями так же, как .15926 показал это для моделей интеграции инженерных данных (проект описан в книге В.Мизгулина "Системный инженер. Как начать карьеру в новом технологическом укладе").

По итогам этого исследовательского проекта TechInvesLab и русское отделение INCOSE в 2015 году выступили с инициативой создания языка системного моделирования SysMoLan, который преодолеет недостатки существующих архитектурных языков и сможет как синтаксически удобно выражать знания по структурам целевой и обеспечивающей системы, так и решать задачи интеграции данных (мэппинга различных инженерных моделеров).

В 2018 году эта инициатива получила развитие: было предложено реализовать SysMoLan как встроенный предметно-ориентированный язык (DSL) в рамках языка технических вычислений Julia. Этот же выбор сделали авторы языка инженерного моделирования Modelica, создавшие DSL Modia в Julia. Выбор Julia как хост-языка для языка системного моделирования помогает решить множество задач, плохо решаемых при других архитектурных решениях: проблемы расширения системного языка, взаимодействие различных видов инженерных моделей и моделей предприятия, наличие языка запросов к создаваемой модели, возможность оптимизации моделей (дифференцируемое программирование).

Ещё одно направление предварительное направление исследовательских работ касалось сред моделирования, которые развивались в некоторое подобие PLM-системы, в которых использовался датацентрический "прожекторный" подход с хранением всех данных (программ, моделей, параметров моделей, "скриптов" отдельных расчётов) с учётом управления конфигурацией и изменениями. Появилось множество примеров подобных систем управления конфигурацией и изменениями, интегрированных с различными вариантами моделеров (прежде всего речь идёт о связке CAD+разнообразные инженерные моделиры+PLM), аналогичные системы появлялись и в области моделирования архитектуры предприятия. В программировании за подобными системами закрепилось наименование "студии".

Предлагается создать SysMoLan Studio, представлящую из себя моделер и платформу системного моделирования для целевых и обеспечивающих систем. Моделер этой системы "из коробки" должен поддерживать ведение системных холархий (breakdown structures: system, product, work, etc. -- в соответствии со стандартом IEC81346) и описания входящих в них систем, в то же время предоставляя возможность для верхнеуровневого (архитектурного) описания систем и подсистем, входящих в эти холархии в соответствии со стандартом ISO42010. Первоначальный акцент в моделировании будет на создание структурных моделей целевых и обеспечивающих систем, а не на задачи мэппинга. Проще всего думать о SysMoLan Studio как об "Archi для системного языка", но в отличие от Archi там будет:
-- высокоуровневый язык системного моделирования SysMoLan, в котором удобно моделировать архитектуры и потребности/требования как целевых систем, так и обеспечивающих систем
-- параллельное представление на текстовом DSL-в-Julia и псевдографических отображениях (двустороннее "связывание данных", как в модели MVVC).
-- консоль работы с моделью с полноценным языком Julia для аналитических приложений, интеграции данных инженерных моделей, расширений SysMoLan, подключения альтернативных представлений и т.д.

Первоначальное использование SysMoLan Studio предполагается в следующих проектах:
-- курсы Школы системного менеджмента ("Системная инженерия. Менеджмент продукта", "Системный менеджмент и стратегирование" прежде всего). Учебные программы по системной инженерии и инженерии предприятия других учебных заведений.
-- небольшие (более близкие к индивидуальной работе с моделями, нежели командным разработкам в больших коллективах) бизнес-проекты создания концепций продукта, корпоративного развития на стадии концептуального моделирования.
-- исследования по системному подходу и системному моделированию в инженерии, менеджменте и предпринимательстве (дифференцируемые архитектуры и т.п.).

Подробности:
-- цепочка текстов "SysMoLan" -- https://ailev.livejournal.com/1443879.html
-- проект "студии" -- https://ailev.livejournal.com/1280626.html (и там trainer studio, systems engineering studio, conceptual studio)
-- .15926 Editor and Platform -- https://github.com/TechInvestLab/dot15926
-- SysArchi -- системное моделирование в ArchiMate 3.0 -- https://ailev.livejournal.com/1444887.html
-- В.Мизгулин, "Системный инженер. Как начать карьеру в новом технологическом укладе" -- https://www.litres.ru/vyacheslav-mizgulin/sistemnyy-inzhener-kak-nachat-kareru-v-novom-tehnologicheskom-uklade/
-- А.Левенчук, "Визуальное мышление. Доклад о том, почему им нельзя обольщаться" -- https://ailev.livejournal.com/1437344.html
-- поиск-ориентированая инженерия -- https://ailev.livejournal.com/1122876.html
Saturday, September 22nd, 2018
9:57 pm
Бизнес-модель обучения "оплата только в случае успеха".
Вот тут готовят менеджеров продукта: https://productschool.ru/. Далее ждут полгода -- и если за полгода прошло повышение на старом или переход на новое место работы, то просят перечислить половину месячной зарплаты. Зарплаты же ожидаются от 100тыс. и выше, т.е. перечислять от 50тыс. и выше. Узнаёте паттерн "Содействие поступлению в вуз. Оплата только в случае успеха"? Но если не хочется трудоустраиваться, то 89тыс.рублей и вас за такие деньги даже не отчислят: за "бесплатно" намерены гонять и спрашивать выполнение восьми домашек, а за деньги можно прохалявить, всё честно.

Вот тут тоже готовят продактов, но явно идёт обращение к корпоративному сектору, который должен заплатить за своих сотрудников: https://product.vision/ru. Совсем другая бизнес-модель.

У нас в Школе системного менеджмента очень и очень многие выпускники имеют карьерный рост в течение полугода после выпуска. И гоняем и спрашиваем тоже, хотя не отчисляем за невыполнение домашних заданий (но выдаём сертификат "прослушал", а не "освоил"). И даже курс для продактов тоже есть, на основе моделеориентированной системной инженерии: http://system-school.ru/engineering (третий поток начнётся уже 30 сентября, не зевайте). В основе там системное мышление, которое нужно знать на входе в объёме моего учебника/курса на Курсере, поэтому за меньшее время удаётся научить большему. И тоже берут онлайн, если кто не в Москве. И даже не один курс на эту тему, вот ещё на основе ТРИЗ++ -- http://system-school.ru/innovations (хотя тут и слов product management не говорят). Фишка в этих курсах в том, что это совсем необязательно айтишные продукты. Системная инженерия и ТРИЗ -- они всеядны, они не только софта, но и железа не боятся, да и бетона тоже.

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

А дальше вы получаете продвижение по службе (неважно, от продукта, или просто от поумнения, или просто если вы активный такой, что пошли на какие-то курсы и даже делали какие-то домашние задания, то шанс продвинуться у такого активного побольше, чем у неактивного). Случился ли продукт, или не случился, тут неважно. Но половину месячной зарплаты уже нужно отдать, даже если ничего не платили за учёбу и вместо препода вас учил видеоролик. Хорошая бизнес-модель! Надо взять на заметку.

А пока учим по-старинке, не влезая в "процент от прибыли". Выдаем сертификаты "прослушал", "освоил". Может, зря так делаем.
Friday, September 21st, 2018
7:37 pm
lytdybr
Мой эккаунт в "Одноклассниках" взломали, попросили по полному списку френдов денег, показали френдам фото кредитной карточки, только вот имени-фамилии моих на карточке не было. Ещё не доросли технологии у хакеров, чтобы ещё и убедительные фото генерировать. Но эта хакерская mass customization ещё будет, года через два. Спасибо Андрею Степенко, который первым об этом взломе сообщил, и Виктору Агроскину, который посоветовал менять пароль из другого браузера (ибо в штатном браузере куки не давали даже разлогиниться). Теперь всё в порядке, двухфакторная авторизация и прочая, и прочая. Вообще, я этими "одноклассниками" как не пользовался много лет, так и не планирую пользоваться. Но вот хакеры пользуются, надо же!

Проект SysMoLan (https://ailev.livejournal.com/1443879.html) в сочетании с проектом "студии" (https://ailev.livejournal.com/1280626.html -- и там trainer studio, systems engineering studio, conceptual studio) начинает шевелиться. Появляются люди, которые им готовы заняться (например, Вячеслав Мизгулин). В первой версии это могло бы быть что-то типа Archi с SysMoLan, чтобы моделировать продукты, использующие системы и обеспечивающие системы продукта (контексты эксплуатационный и разработки) не в Архимейте на кривоватом SysArchi (https://ailev.livejournal.com/1444887.html), а сразу в системном языке. Теперь нужно понять, кто может поспонсировать такой проект: выполнить такт организационной работы, а не только двигать содержание. Краудфандинг тут плохо поможет, ибо на моделеры не найдёшь крауда (это "толпа", а какие уж тут толпы!). Нужно несколько меценатов (вариант госфондов с исследовательскими грантами не предлагать: время на бюрократию, отчётность, compliance и т.д. будет вполне сравнимо со временем самой разработки. Нет уж).

Сутками отвечаю во всех чатах на вопросы по онтологике (до системного мышления, увы, дело даже не доходит) типа: "вот тут у вас описан белый конь в яблоках. Да-да, картинка белого коня с пятнышками по всему телу. Яблоки должны быть антоновка, или гольден? А сколько их брать на килограмм веса коня, если коня в этих яблоках тушить? А сколько, если его в яблоках прожаривать?". Ужас ещё и в том, что вопросы задаются именно такой длинной серией, на них пытаются ответить ещё человека четыре, и через некоторое время непонятно, что тут вообще можно сделать -- большой чат на десяток реплик обсуждает конскую колбасную пасту с яблоками, которая делается как форшмак, только не из селёдки, а из яблок, и продолжает называть её "конь в яблоках, который из учебника". Ужас в том, что это всё абстрактные вопросы, а не попытка решить какую-то свою прикладную задачу (а если и решить задачу, то обычно проблема оказывается не в коне и не в яблоках -- проблема описана где-нибудь в другом месте учебника). Но ничего, после каких-то разъяснений всё одно люди начинают лучше разбираться в своих прикладных проектах, и их жизнь становится в итоге лучше.

Мне в личке заметили, что я давно не писал попсовых текстов. Ну да. Я ж не журналист, не публицист, не попсовик-затейник. Никаких обязательств по выдаче на-гора попсы, никакого плана по валу. Но значительная часть моих текстов сейчас уходит в ЛС и закрытые чаты. Это плохо: обсуждаются обычно очень общие вопросы, но мои ответы на эти вопросы потом невозможно найти никаким поиском -- хорошо индексируются только открытые посты.

В физматлицее в десятом классе собирают макулатуру, "приносить в маленькую раздевалку в любой день". Это должно символизировать уже даже не знаю что. Ритуалы, смысл которых уже прочно забыт, но они добросовестно исполняются.
Wednesday, September 19th, 2018
11:18 am
ШСМ: progress report
Утрясли с Пион Медведевой изменения в "Основах онтологики". Осталось согласовать даты запуска новых двух курсов вместо прежнего одного:
-- Основы онтологики 2.0. Программа курса: https://thpectrum.livejournal.com/11639.html (и 12 октября 2018 курс уже пойдёт по этой программе http://system-school.ru/ontologics).
-- Онтологика: принятие решений ("как выбирать среди множества разумных альтернатив группе стейкхолдеров с разными предпочтениями?"). Программа курса: https://thpectrum.livejournal.com/11881.html.

Преподаватели перерабатывают свои курсы в соответствии с проектом соглашения о моделировании SysArchi (текст тут: https://yadi.sk/i/DgjcxXh3yPjQIA). В моём курсе СМС2 (http://system-school.ru/sms) эта переработка касается и пятого дня, "инженерия предприятия" (где вводится Архимейт как предпочтительный язык документирования архитектуры предприятия), и шестого дня "стратегирование" (один из паттернов документирования стратегии даётся как раз на Архимейте).

Курс Вячеслава Мизгулина переименован, и подправлено его содержание. Теперь это "Системная инженерия и менеджмент продукта" (старт очередного потока 30 сентября 2018): http://system-school.ru/engineering. Менеджмент продукта -- это как из невнятных идей по поводу продукта сделать востребованный рынком (функции) и доступный в производстве (конструкция) продукт. В тренинге даются методы моделеориентированной системной инженерии, язык моделирования ArchiMate 3.0 и стиль моделирования будет SysArchi. Изюминка курса -- моделирование на Архимейте как целевой и использующей системы ("менеджмент ПРОДУКТА"), так и обеспечивающих систем ("МЕНЕДЖМЕНТ продукта"). У нас отличия от похожих учебных инициатив:
а) требования к фундаментальному образованию — системное мышление прежде всего, это обеспечивает дисциплину мысли и поэтому большую скорость обучения, плюс в поддержку есть смежные совместимые по языку и подходам курсы по системному менеджменту, системным инновациям и в будущем системному маркетингу
б) менеджмент не только IT-продуктов, но и просто инженерных (в том числе хардверных) продуктов, и поэтому применимость опыта моделеориентированной системной инженерии — у нас плотная работа с международным сообществом практикующих системных инженеров INCOSE.

Практикум "Системные инновации" (aka ТРИЗ++) запускаем 10 октября 2018 (http://system-school.ru/innovations), видео обсуждения тут: https://youtu.be/OLuDwqnKpWs. В состав преподавателей вошли три мастера ТРИЗ и управляющий партнёр школы: А.В.Кудрявцев, В.Е.Минакер, М.С.Рубин и Ц.В.Церенов. Заниматься 6 дней тренингов, 11 семинарских занятий.

Курс "Системное лидерство 2.0" Александра Турханова стартует уже 29 сентября, он существенным образом переработан: http://system-school.ru/leadership

У Антона Климата начались регулярные занятия по танцевальной инженерии (младшая сестра системного фитнеса) на базе Spicy Salsa: https://vk.com/wall7236650_5555, и по этой же ссылке -- к кому обратиться за занятиями в Пензе, Казани, Нижнем Новгороде, Кирове. Методика-то вполне отчуждаема. Для выпускников "Системного фитнеса" день апдейта будет идти два раза: выбрать и зарегистрироваться можно тут: https://www.facebook.com/events/243879966318017/ (форма оплаты -- system-school.tilda.ws/moveupdate, в приходящем письме спросят, на какую из двух дат была регистрация), а очередной полный четвёртый поток (32 часа) пойдёт с 3 ноября -- http://system-school.ru/move. Текст от выпускницы "Системный фитнес: что это такое?" тут: https://vk.com/@9383-sistemnyi-fitnes-chto-eto-takoe

На видеоканале Школы появились новые видео: https://www.youtube.com/channel/UCJ0Uq_WB7GLmY-NTz2oFoUQ. А всего там уже 85 самых разных видео.

Все курсы школы получили закрытые телеграм-чаты выпускников, общие для всех потоков. Делимся там новостями по материалам курсов, идеями, литературой, опытом применения полученных на курсах компетенций.

Появился телеграм-бот @SystemSchoolBot, в нём удобно следить за расписанием ближайших курсов.

Онлайн-курс в Курсере (http://www.systemsthinkingcourse.ru/) уже выдал сертификаты для 119 человек, это примерно по 15 человек в месяц с момента запуска курса. Книжку "Системное мышление" https://www.litres.ru/anatoliy-levenchuk/sistemnoe-myshlenie/ купили уже в количестве 1208 экземпляров, это примерно по 150 штук в месяц. По курсу "Системное мышление" в вузах сейчас идёт около сотни студентов-очников. Нельзя сказать, что современное системное мышление быстро овладевает массами, но речь идёт уже о сотнях и тысячах знакомящихся с ним людей.

Активно идут обсуждения "Системного маркетинга" (см. его место в экскизе программы системного развития личности тут: https://ailev.livejournal.com/1443837.html, видео одного из ранних обсуждений тут: https://youtu.be/0fK4_ugqdeE).

Я сейчас работаю над "Стейкхолдерским мастерством", это у меня текущий приоритет в запуске новых курсов. Ближайший тренинг у меня в это воскресенье, 23 сентября -- третий день "Системного менеджмента и стратегирования 2.0", будем обсуждать различия управления жизненным циклом и управления работами. А ближайший открытый курс -- про личное развитие ("Как оставаться востребованным специалистом в эпоху перемен", http://system-school.ru/uptodate), третий поток будет 3 октября 2018, и я опять переделываю содержание курса.
Monday, September 17th, 2018
9:22 pm
Мой KizMiFest в Ростове
Из поездки на фестиваль кизомбы в Ростов-на-Дону получился мини-отпуск. Погулять по броду (от "бродвей" -- Садовая от Будённовского до Ворошиловского и обратно): done. Покушать пироженок в "Золотом колосе": done. Там до сих пор можно заказать торты! Только этих тортов штук тридцать видов, а не пяток, как в советское время. Покушать мороженого в "Зелёной горке": done. Только это теперь пафосное место, там диваны и почти никого нет, и мороженое не вкуснейшее, а ужасное перемёрзшее, и несут его официанты, а не ты сам. На Садовой появился узенький газончик посередь тротуара, это к нынешнему чемпионату по футболу сделали. Несколько эпидемий укладки плитки на сто лет с ежегодной перекладкой в Ростове тоже прошли, так что это даже не обсуждается.

Набережная городского пляжа на левбердоне -- оооо! оооо! оооо! Там гуляло много детей и детских площадок там полоса на сотни метров, так что всё было более чем живое, да ещё мы туда угодили в день города. Затея с этой набережной (как и превращение всего левбердона в сплошную улицу ресторанов) удалась, жизнь в Ростове стала лучше.

Но никакой ностальгии у меня в Ростове не случилось. Просто попал в привычную среду, в мозгу что-то щёлкнуло -- и как не уезжал, "я дома". Только всё какое-то тихое и замедленное, но это обычное ощущение после бешеных темпов Москвы. Много раз вспоминал поговорку, что в Ростове едят, а в Москве питаются: и дело не только в южной готовке, дело ещё и в отводимом на еду времени, сам темпоритм жизни и темпоритм настроя на поглощение пищи существенно различны.

Поскольку мои друзья меня постоянно похищали (какой такой фестиваль, если я приехал первый раз за пятнадцать лет?!), все дневные мероприятия фестиваля KizMi (https://vk.com/kizmifest2018) прошли мимо меня -- разве что только в воскресенье случился один предобеденый час social room. Играл DJ Sway, и играл он около широко раскрытой двери на терраску, то есть для него это был open air. И играл он, как водится на опенэйрах, волшебно. DJ Sway в закрытом помещении и на свежем воздухе -- два абсолютно разных диджея. В этот час был полный зал, и у всех танцующих и просто сидящих были абсолютно блаженные улыбки. Ну, и я в этот час потанцевал -- и тоже блаженно поулыбался, хорошо ведь потанцевал!

Уровень танцпола в пятницу был нереально крут. Присутствовали таксидансеры из Москвы, Питера, Волгограда, Астрахани. В начале вечеринки партнёрш существенно не хватало, потом всё как-то пришло в баланс. А вот в субботу вечером почти все таксидансеры и их "свита" толпой ушли в нумера праздновать дни рождения, и гендерный баланс резко пошатнулся. Но площадке остались KizzPro из Питера, я понаблюдал за их танцами и закомплексовал. Фишка была в том, что они были и мягки, и быстры, и по совокупности круты. Основа их базы -- аутентика, а сам танец -- бешеный урбан со вставками всех родов тарраши. Одна из партнёрш пыталась меня утешить: ещё пара лет, и я тоже так буду танцевать. Ибо она сама танцует четыре года, а когда она пришла, эти ребята уже танцевали. Чудес ведь не бывает, всё не спеша. Ну да, в танцах способности способностями, а тренировки тренировками. Два года я уже танцую, два года ещё попрактиковаться -- и всё будет. Но хочется-то сейчас и сразу, и хочется сильно. Не-танцорам не понять, насколько это "хочется сильно". И никакие рационализации типа "ну, если научишься так, то что?" не помогут. Если научусь так, буду хотеть ещё круче, это ж понятно: ничего не изменится, буду просто комплексовать по другому поводу.

В воскресенье танцпол состоял уже наполовину из ростовчан, ибо понаехавшие поразъехались. Из ростовских школ мне запомнились девочки из МОКО -- они были все с классической базой, не танцевали всё время на цыпочках и ощущались даже на урбане очень гармонично. Ибо пересушенный урбан для меня не есть хорошо. Можно очень сухо и очень быстро станцевать пяток секунд, но в целом кизомба для меня приемлема более мягкая. Когда я сам почти два года танцевал пересушенный урбан, я и не подозревал, сколько я теряю в танце, плохо владея аутентикой.

Когда-то для меня очень нетривиальной оказалась идея Рони Салеха, что разная стилистика в кизомбе может быть не в рамках разных треков, а в рамках одного трека (https://ailev.livejournal.com/1376374.html). Но я недооценивал глубины этой мысли. Все эти его "три энергии", этот эзотерический язык затушевали простой факт: можно и нужно в зависимости от музыки, вдохновения и мимолётного/секундного настроения менять базу: если надо, то глубоко садиться на бедро, если не надо, то и не садиться. Но кач, ginga должны присутствовать практически всегда, в том числе на высоких скоростях -- они уходят почти в ноль, но не уходят совсем. Это даёт нужную мягкость, мягкость нужна для качественного контакта, качественный контакт даёт восхитительный connection.

База -- это наше всё, и урбанская база по факту это просто развитие, ограничение и дополнение классической базы, а не полная её замена. Пару последних месяцев я чистил свою базу (через два года танцевания! Лучше поздно, чем никогда!), восстанавливая работу бёдер в стороны, работу "в землю" через перенос веса, и это полностью окупилось. Танцевал с партнёршами из Москвы, Ессентуков, Пятигорска, Казахстана, Астрахани, Ростова, Ярославля, Донецка -- и всем, вроде, понравилось. И мне понравилось.

Воскресная афтепати совпала с экзаменами Алёны Фортуновой (https://www.facebook.com/alena.fortunova), у которой я занимаюсь уже больше двух лет без перерывов в Spicy Salsa: она сдала экзамены Кертису и Кароле, получила тренерский сертификат первого уровня по урбанкизу. Так что в России появился сертифицированный преподаватель урбанкиза, и у меня теперь не просто занятия три раза в неделю рядом с домом, а мастер-классы от сертифицированного преподавателя! Впрочем, сама бумажка сертификата мало что меняет: она просто подтверждает уровень Алёны.

Многие партнёрши на фестивале меня танцевально удивили. Они ведь очень разные, эти партнёрши. Даже одни и те же партнёрши, только взятые в момент другого настроения, а уж если говорить о партнёршах из разных студий, да ещё и немосковских студий, то и подавно). Надеюсь, что и я удивил там многих. Я, конечно, по своему уровню не таксидансер ни разу, но для начинашек (а их там была едва ли не половина в субботу-воскресенье) я вполне комфортен, часто к полной их неожиданности. И есть подозрения, что со мной нравится танцевать и не начинашкам тоже. Но это пока только подозрения.

Итого: поездка (то ли в гости к друзьям, то ли на фестиваль) удалась сполна. Спасибо оргам фестиваля, спасибо моим друзьям. Прямо-таки мини-отпуск. Времени даже на поклацать по клавишам не было, так что эти строки я писал в самолёте на Москву.

UPDATE: обсуждение ВКонтакте -- https://vk.com/wall2449939_1853
Thursday, September 13th, 2018
5:07 pm
Улётное
Завтра в пятницу утром я вылетаю в Ростов-на-Дону, где не был лет пятнадцать, вернусь вечером в понедельник. Лечу абсолютно по нерабочим делам: на кизомба-фестиваль -- https://vk.com/kizmifest2018. Так что вряд ли буду в этот weekend оперативно реагировать на письма-чаты.
Tuesday, September 11th, 2018
7:20 pm
Доклад "SysArchi -- системное моделирование в ArchiMate 3.0"
Прочёл сегодня из Москвы по скайпу в Нижний Новгород двухчасовой доклад "SysArchi -- системное моделирование в ArchiMate 3.0" в рамках семинара НИУ ВШЭ «Дни Инженерии организаций», проводимого факультетом информатики, математики и компьютерных наук. Студенты там в новом учебном году будут знакомиться и с курсом "Системное мышление", так что им это содержание более чем актуально. Аудиовидеозаписи не велось. Но вот слайды (https://www.slideshare.net/ailev/sysarchi, для спасающихся от Роскомпозора https://yadi.sk/i/9LL1WtvOgcjwZA):

Драфт текущей версии соглашения о моделировании SysArchi (оно сейчас активно обсуждается) -- https://yadi.sk/i/DgjcxXh3yPjQIA.

SysArchi, или "системный Архимейт" это стиль программирования на ArchiMate 3.0 (http://pubs.opengroup.org/architecture/archimate3-doc/), помогающий явным образом опереться на понятия системного подхода при моделировании не только организационных систем, но и их целевых систем по тем же принципам, что декларируются в подходе моделе-ориентированной системной инженерии (Model-Based Systems Engineering, MBSE) с использованием архитектурных языков SysML, AADL и др.. При этом моделирование на Архимейте ещё и обеспечивающей системы (жизненного цикла, вместо традиционно использующихся тут языков ситуационной инженерии методов OMG SPEM, OMG Essence, ISO 24744, но также и структуры ролей и организационных мест предприятия) обеспечивают полноту системного моделирования в инженерном проекте.

Этот стиль подразумевает полное и свободное использование возможностей, предусмотренных спецификацией языка, но при прямом моделировании понятий современного системного подхода подсказывает предпочтительные выборы элементов языка. Сам Архимейт частично системный язык (он в явном виде учитывает рекомендации ISO/IEC/IECC 42010:2011 по структурированию описаний системы), но довольно далёк от поддержки системного моделирования в общем виде, а также плох для создания моделей сложных целевых систем . Кроме того, Архимейт не слишком опирается на достижения современной онтологии, поэтому в SysArchi даются рекомендации, как обойти его ограничения.

Стиль моделирования SysArchi предполагается для использования его при совместном моделировании инженерных (целевых и использующих) систем и архитектуры предприятий (обеспечивающих систем). В системном подходе подчёркивается, что нельзя рассматривать архитектуру предприятия (обеспечивающей системы) вне целевой системы и её жизненного цикла, поэтому SysArchi применим и к «классическим» проектам моделирования архитектуры предприятия.

В сложных больших проектах архитектурного моделирования возможно использование всего полного набора элементов языка ArchiMate, а при необходимости более детального (не архитектурного) моделирования рекомендуется использовать другие языки моделирования (BPMN и т.д. – как это указано в спецификации ArchiMate). Но и в этих случаях следование рекомендациям стиля SysArchi для повышения зрелости системного моделирования остаётся предпочтительным.

После доклада были интересные вопросы, например о том, как бы сделать очередной заход на верхнюю онтологию в духе BORO для архитектуры предприятий. Мой ответ был в том, что нужно двигаться в направлении вероятностных онтологий и дифференцируемых архитектур, и в рамках работ над SysMoLan мы этим обязательно займёмся (https://ailev.livejournal.com/1443879.html). И вопрос про инструментальную поддержку SysArchi был в том же духе: этот стиль моделирования "проходной" (так же, как и ArchiEssence -- он у нас будет недолго), ибо из ArchiMate системный язык так просто не сделаешь. Вместо разворачивания экосистемы онтологически кривоватого SysArchi мы лучше наши усилия направим сразу на SysMoLan.
[ << Previous 20 ]
Лабораторный журнал   About LiveJournal.com