В фестивале IMYDJ New Year 4th edition список танцев выглядит так: KIZOMBA - URBANKIZ - SEMBA - AFRO - DANCEHALL (https://www.facebook.com/events/146364315990640). Dancehall регулярно ставит уже на вечеринках DJ Marsel (мы обсуждали этот вопрос с ним в четверг в PapaJoy's , куда я забежал на пару часов -- и он как раз пару треков dancehall ставил), да и другие диджеи тоже подключаются. И dancehall можно часто услышать на занятиях Сирото и Левина. Но танцуют все не dancehall классический, а "месят урбанкиз" -- именно месят, потому как танец получается более драйвовый, чем "просто урбан", хотя и мене драйвовый, чем он же под мумбатон (который тоже ставят уже регулярно). И вот это уже в программе фестиваля "официально". Хотя и после афрохауса, который идёт пока везде разве как анимация. А ещё начали ставить компу (в варианте douceur мелодий), но "официально" в программе фестивалей кизомбы её пока нет. Как быстро всё развивается!

Отличается это всё очень специфической телесной работой (и dancehall и afrohouse, и compa). Я вчера забежал буквально на час в Тики-Бар, где танцевал со знакомой партнёршей, которая занималась и зуком, и лет 12 разной телеской (йога, растяжки и т.д.), а сейчас вот и кизомбой. Как я понял, у неё был копчик сильно отклячен в кизомбе, из-за чего болела спина -- как и у многих других партнёрш. Артём Левин ей это поправил на занятиях, спина болеть перестала. Артём рассказывает это очень убедительно: "строение африканских тел такое, что только кажется, что они оттопыривают зад! На самом деле позвоночник там в нейтральном положении, копчик не отклячивается. Европейцам не нужно пытаться повторить африканскую форму тела, и нужно держать свой позвоночник прямым, зад должен быть в "нейтрали", а не отведён назад. Тогда и спина не будет болеть, и замахи бунды на любые волны будут из "нейтрали", а не из почти крайних положений". И теперь эта партнёрша стоит ровно.

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

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

Вот тут можно почитать про танцевальные тела джазовое, балетное, модерна и т.д. (https://arzamas.academy/courses/50/6 -- жмите там на "расшифровку" сразу, чтобы не тратить время на аудио). Универсальных тел не бывает, хотя эта мечта у человечества есть. Я называю это всё по традиции восточных единоборств "стилевыми движками", ибо сказать "африканское/джазовое тело" -- не слишком понятно без контекста, о чём речь. Но вот "африканский/джазовый стилевой телесный движок" много понятней. В "зонтике кизомбы", конечно, этот самый африканский/джазовый движок. Антон Климат сегодня сказал, что оценивает число этих движков где-то в 10-15 штук. Это обозримая величина, с этим можно как-то разобраться. Танцевальная инженерия берёт системный фитнес (универсальный язык работы с движением) и дальше затачивает тело под конкретный стиль, "запускает движок". И на базе этого работающего движка уже дальше можно строить отдельные танцы. Чтобы мне танцевать кизомбу и все сопутствующие танцы, мне нужно запустить африканский стилевой движок, в котором важна изоляция бёдер, свободное изолированное движение тазовой пластины по самым хитрым траекториям, с самой хитрой развесовкой, в нестандартных позах с самыми неожиданными напряжениями в этих позах. Ничего, это обозримая задача, IMHO она решается проще, чем задача системного фитнеса, в котором идут более-менее универсальные растяжки-расслабления плюс силовые тренировки глубоких мышц. Ибо когда есть подготовленное системным фитнесом тело, которым можно двигаться, дальше можно танцевать. Если тела, которое может двигаться, нет, то и танцевать не получается.

Цепочка текстов "Системный фитнес", где я рассказываю подробней про стилевые движки -- https://ailev.livejournal.com/1429126.html

https://ailev.livejournal.com/1451264.html

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

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

Обнаружил, что на мой эккаунт в инстаграмме подписано огромное число людей -- больше трёхсот человек. Хотел их уважить и сделать трансляцию туда моего ЖЖ, как ВКонтакте, ФриФиде, фейсбуке. Но в инстаграмме как-то странно, устроить туда трансляцию своих текстов из ЖЖ я не понял как: инстаграм ожидает фотографии в качестве содержания записи и главное устройство для постов там не десктоп, а телефон.

Хотел написать пост про стейкхолдерскую пляску, в отличие от стейкхолдерского танца: пляска обычно характеризуется некоторой неосознанностью телесных паттернов, отсутствием культуры и порядка в движениях, неотрепетированностью и спонтанностью, а танец -- строгой зарегулированностью и наличием некоторого канона в движениях. Подробности можно поглядеть в https://arzamas.academy/courses/50/3, и там сразу жмите "расшифровка", чтобы не слушать, а читать). Но потом подумал-подумал, поглядел ещё раз на текст "Так говорил Заратустра" (там ведь тоже про танцы много), другие лекции из курса, на материал по отличию пляски и танца в котором я дал ссылку в этом абзаце -- и не стал писать, ибо не так уж и продуктивна эта метафора, она забалтывается художественной необязательностью последующих построений. Стейкхолдер, которого не учили компетенции, но жизнь заставила "плясать" -- он и пляшет, уж как может, без какой-то культуры в движениях, но свежо и от души. А стейкхолдер, который знает свою роль, он танцует свою деятельность глубоко паттернировано, у него накачаны соответствующие мозговые мышцы, он "в культуре". А дальше, как в танцах: вечная проблема соотношения свободной пляски (которой, оказывается, не бывает -- просто паттерны движений более просты и повседневны, а не разнообразны и изысканны) и предписанного танцевального канона. Сравнение с танцем тут на две фразы, никакого целого поста не нужно, а если дальше проходить по танцевальной линии, то современный танец прямо таки борется с танцевальной культурой, ему подавай ту самую спонтанность и некультурность (при полном признании, что речь идёт об утопии -- тело-то "для свободы выражения" тренируется!). С другой стороны, все эти проблемы можно было бы решить, если говорить о холархии движения: тренируется системный фитнес, сама способность к движению, но не стилевой движок, а потом стилевой движок, но не предписанные паттерны движений -- и танца как такового может не быть, только пляска, но это будет очень хорошо паттернированная пляска, только паттерны будут нижележащего системного уровня: готового к движению "универсального тела" (при всей абстрактности и утопичности этого -- но язык движения универсален!) и настроенного на предпочтение определённых двигательных паттернов тела. Так что это всё нужно ещё додумывать, а вместо полноценного поста пока пусть будет этот абзац.

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

https://ailev.livejournal.com/1451169.html

Я регулярно писал посты "куда думать в первом квартале", а разок написал и "куда думать во втором квартале" (https://ailev.livejournal.com/1250672.html -- а ведь сильно продвинулись за прошедших почти три года!) -- ибо "стратегия ничто, а стратегирование всё!". Вот темы моих текущих размышлений, только с учётом того, что уже явно не начало четвёртого квартала, и мы везде уже опоздали, всё не расписано подробно, не структурировано по крупным подтемам, как раньше, и практически без ссылок на многочисленные предыдущие посты:
-- сопровождение системного мышления: вычленение собственного системного содержания (с учётом отделения онтологики и вычислительного мышления), отслеживание развития системной мысли и апдейты, разъяснения по частым ошибкам, полноценный тренажёр (больше задач!), опускание входного ценза до уровня средней школы, поддержка сообщества (в том числе выпуск текущей группы из примерно 80 студентов пары кафедр МФТИ).
-- полноценный набор курсов [классической] системной инженерии, работа в INCOSE. Апдейт "Системноинженерного мышления", закончить работу с SysArchi.
-- развитие мышления: разбирательство со спектром формальности мышления, стеком абстракций, рендерингом/сенсорно-вербальным декодером, творчеством/противоречиями, и тут же онтологии и коннективистские модели (онтологии и перспективы SysMoLan) -- https://ailev.livejournal.com/1449992.html, https://ailev.livejournal.com/1449229.html.
-- программа развития личности (Просвещение-2020, EduOps, чеклисты дисциплин и прочая) из фундаментальных методологических и когнитивных дисциплин: уточнённый список курсов, входное-выходное тестирование уровня развития, курсы-учебники-задачники, сообщество. В предыдущих "куда думать" когнитивная часть шла в разделе "инженерия психики" и отчасти "коллаборационный нейровеб", а методологическая тоже была немаленькой (научное мышление и причинность, онтологика, вычислительное мышление тут), так что это по факту огромный пункт.
-- кругозор по сферам человеческой деятельности. Что это такое и как ему учить. Отдельные пункты общего списка: культура и её роль, кругозор по системному менеджменту: развитие и отчуждение материала (на базе CMC2), проект системного маркетинга и прочие по разделам. Короткий курс системной инженерии тоже попадает в кругозор, и только полноценное образование системного инженера будет прикладным.
-- обучаемая робототехника как фронтир системной инженерии. Железо/"железо" и алгоритмика (RL etc.) в рамках embodied интеллект-стека. Методология разработки (собственно, это и есть "современная системная инженерия"). Заделы: вводная лекция по курсу системной инженерии, обзоры интеллект-стека и работы по стратегии NVIDIA в части автомобильного рынка.
-- Julia: SysMoLan Studio. Julia, Julia Jetson AGX Software Stack (как вариант embodied интеллект-стек). Учебно-промышленный Julia AI-стек (как часть интеллект-стека, только с акцентом и на учебность тоже) -- https://ailev.livejournal.com/1448888.html.
-- хроники сингулярности: текущие exponential/disruption technologies и AI в их основе. Мониторинг, чтобы быть в курсе и не пролететь мимо чего-то реально важного. Дело бесполезное, но интересное.
-- телесные практики: системный фитнес и танцевальная инженерия (по факту тут пока кизомба).

Дальше, конечно, нужно удавливать мультитаскинг и стратегировать (то есть выкидывать, выкидывать, выкидывать из списка. Что невозможно, конечно. Но надо).

https://ailev.livejournal.com/1450840.html

Побывал на мастер-классе Рони Салеха (https://vk.com/event112773246). Я писал о его семинаре прошлого года в https://ailev.livejournal.com/1376152.html и https://ailev.livejournal.com/1376374.html. В этом году он выдал всё то же самое, хотя и в меньшем объеме -- но с новыми дидактическими приёмами. Типа "музыка как Санта Клаус, каждая восьмёрка приносит нам что-то новенькое" или "регулярно делайте в танце выходной день -- объявляйте воскресенье". Мне стало чуть понятней, что он вносит в понятие foxkiz: он его моделировал по социальному шведскому фокстроту (а не по спортивным бальным фокстротам). Этот фокстрот в Швеции самый популярный социальный танец, но он танцуется "вверху", а не "в пол", как кизомба. Поэтому Рони в кизомбу включил его элементы: затяжные слайды (но их сейчас делают чуть более чем все, так что это уже не так оригинально) и lift-tension-direction -- резкие остановки со сменой направлений в плавном движении. Рони большой артист, он велик и замечателен. Для меня особо нового он ничего не сказал, но было очень приятно услышать поддержку его в том, что нужно кизомбу танцевать так, как хочешь, чтобы не было сожалений (regrets) о том, что ты танцуешь что-то не своё, а чужое. Каждый танцор имеет уникальный стиль, и нужно его культивировать, а не стремиться к унификации и стандарту. И нужно приспосабливаться к стилю партнёров по танцу, внимательно их слушать -- не только всё время вести самому. Танец это диалог, а не монолог одного артиста одному безмолвному зрителю. Ещё он (как и в прошлый раз) подчёркивал важность работы корпусом в ведении (у него это прямо chest, грудь) -- а я печалился, что это легко рассказать, но трудно сделать. Но я уже больше понимаю, о чём это он. Перед ведением на всякие закресты-ронды я уже и сам приловчился брать плотный контакт в солнечном сплетении, иначе ведь плохо всё получается. Нужно эту привычку распространять на разные другие элементы: удобней будет всем.

А ещё сходил на пятничную препати в спайси сальсе и воскресную афтепати в madman. Восторг и удовольствие! Стоило учиться танцевать пару лет, чтобы потом так развлекаться.

Спрашивали, какой фестиваль кизомбы мне больше всего нравится. Мой ответ (https://vk.com/wall-24773547_18233?reply=18316): Самый крутой фестиваль для партнёров — это Москва. В день сложно качественно протанцевать больше четырёх часов, все эти слова про 72 часа в сутки это для монстров, простым смертным это недоступно. А в Москве вечеринки практически ежедневно, по цене 200 рублей за этих четыре часа. И лучшие партнёрши. Вот и фестиваль, круглогодично, в любой день.

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

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

Обсуждали, почему это пошла мода на танец девушек за партнёров. Отвечал (https://vk.com/wall-167384137_28225?reply=28264): Есть много разных причин, по которой вдруг девушка хочет танцевать как leader. Из моих наблюдений главная — это самостоятельно выразить акценты в музыке, причём но не только для себя, но и для партнёра/партнёрши. Когда прёт от музыки и танца, то этим хочется поделиться. Ну, а дальше — а) или умеешь, или нет, ибо leader неожиданно много должен знать-уметь, и б) есть с кем потанцевать за leader, или нет. Парня follower найти потанцевать посложней будет, чем девушку. Отсюда и результат.

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

Спрашивали, важны ли в танце внешние фишки или танец таки "вовнутрь пары". Отвечал (https://vk.com/wall-167384137_28139?reply=28160): у меня все фишки идут внуть пары — партнёрше весело, а концерт никто не подряжался делать. У меня с одной партнёршей почему-то всё время получался вместо танца концерт, а последний месяц — танец стал наконец-то внутрь пары (думаю, это просто доросли оба). Но сказать что мы делаем меньше фишек? Нет, делаем фишек только больше. Внутрь пары не означает топтания на месте с залипанием ни разу. Но и залипушки можно сделать легко концертными по ощущению.

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

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

Мои заметки по компе (не "народной", а как её танцуют на парижских дискотеках и как я сам видел на DJ Elite в исполнении афрофранцузов, и как я понял по объяснениям Алёны Фортуновой -- у неё в старшей группе как раз идёт серия занятий по компе):

1. Стоять ровно по вертикали (контакт по факту от груди до колен), не "сидеть на стульчике", не отклячивать зад (проекция копчика между ступней), не откидываться назад от партнёрши/партнёра.

2. Таз африканский (изолированный от корпуса!), подвыворотность тазовых связок (не знаю, как это делают, но у некоторых девочек это очевидно получается -- видна характерная "африканская" посадка).

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

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

5. Ведение основное от движений таза (вариант похуже: колени, таз неподвижен -- но это может быть просто фишка, не основной вариант). Возможна помощь руками, но руками не переусердствовать -- руки больше сопровождают, нежели ведут.

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

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

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

https://ailev.livejournal.com/1450716.html

Наступил радостный день: доходы от продажи моих книжек (26029руб) превысили расходы на вёрстку и публикацию (24409руб.). Роялти в моих книжках была установлена в Ridero как 10руб., цена в магазинах оказалась 40 рублей за книжку. Я заполнил заявку на вывод средств, и мне обещали вернуть мои деньги в течение 30 дней (не спрашивайте, почему так долго. Наверняка там откроются административно-налоговые бездны). Ещё и на пару тысяч рублей наварился! Вся эта история началась в январе, break even наступил в октябре. Года не прошло! Системного мышления (https://ridero.ru/books/sistemnoe_myshlenie/) продано 1369 экземпляров на сегодня (с февраля 2018), визуального мышления (https://ridero.ru/books/vizualnoe_myshlenie/) продано 251 экземпляр (с июля 2018). В топе Ridero за сентябрь (https://ridero.ru/blog/?p=2854) я тоже есть -- в литресе "Системное мышление" занимает второе место, в Ridero электронных книгах "Визуальное мышление" занимает первое место (93 продажи в сентябре), а "Системное мышление" третье место, в печатных книгах "Системное мышление" аж двенадцатое.

Оба этих книжных проекта в чём-то оказались успешными:
-- "Системное мышление" позволило как-то отчудить от меня, любимого, тот объём знаний, который я считаю универсальным системным мышлением (хотя в него по необходимости попали большие куски онтологики и кусочки системного менеджмента, инженерии и предпринимательства). Книжка (и добавленные к ней примерно 200 задач, объём их тоже примерно 200 страниц книжного формата) позволила также сделать удачный курс в Coursera http://www.systemsthinkingcourse.ru/, ибо видео IMHO совершенно недостаточно для качественного образования. "Системное мышление" на Курсере стартовало тоже в феврале (набор открыт 29 января 2018), на сегодня там 135 получивших платный сертификат об окончании, а хоть что-то бесплатно посмотрели-пролистали 3855 человек. И ещё во всех этих цифрах не участвуют цифры киевского цветного издания в бумаге тут: https://balovstvo.me/sys-thinking (там по почте разошлось ещё порядка полусотни экземпляров) и тиража цветного издания Школы системного менеджмента (там разошлась на разных мероприятиях ещё сотня штук).
-- "Визуальное мышление" я думал, что вообще никто читать не будет. Но нет, планка "научного тиража" в 200 экземпляров была преодолена! В этой книжке собрано много оригинальных идей, которые без особого растолковывания мелькали у меня в блоге. Именно в этой книжке можно прочесть про движение по спектру формальности движения (включая описание не только хода на формализацию, но и хода на деформализацию как рендеринг -- привнесение деталей из "латентного представления"), почитать (а не только послушать) про мою модель личности, познакомиться с тем, как исследования по искусственному интеллекту влияют на распространённые идеи о человеческом мышлении. Изложение в разы и разы менее рваное и более последовательное, чем в моих постах в блоге. Так что теперь по многим вопросам я даю ссылку не на свои посты, а на книжку.

Книжных планов у меня сейчас нет, но какие-то соображения есть:
-- непонятно, что делать с "Системноинженерным мышлением". Формально я эту книгу ещё не издавал, хотя вышло аж две редакции. Но содержание этой книги существенно отличается от "Системного мышления", многие подробности про инженерию (целые разделы!) в универсальный учебник не вошли. И это 2015 год -- три года прошло, моё представление от state-of-the-art поменялось. Опции: 1. издать книжку "как есть", предупредив, что это вторая редакция в вариенте апреля 2015 года, и "всё устарело". 2. Напрячься и переписать, дополнив главами с обзором системной инженерии (по факту я подготовил трёхчасовое видео с этим обзором для закрытого курса онлайн-магистратуры МФТИ, по опыту там материала будет как раз чуть ли не на книжку, если расшифровывать текст. Про визуальное мышление -- это ж тоже был поначалу доклад). А ещё там до чёртиков картинок с не очень понятными копирайтами, и эту головную боль нужно будет как-то долго и муторно снимать. Этот второй вариант "сделать третью редакцию и опубликовать" -- очередное серьёзное книжное приключение, и непонятно, зачем мне его делать.
-- сделать вторую редакцию "Визуального мышления", сняв акцент на визуальности -- пусть визуальность там останется, но не главным. Ведь по сути, я рассказываю в этой книжке про мышление как таковое. За время после написания книжки у меня в блоге появилось уже достаточно нового материала. Вот его и включить. И надеяться, что у книжки будет ещё две с половиной сотни читателей. И я бы даже задумался над этим проектом более серьёзно, если бы была надежда получить две с половиной тысячи читателей, а не две с половиной сотни. Но сейчас это всё wishful thinking, так что этим заниматься не буду.
-- у меня по факту появилось много разных цепочек (по системному фитнесу, по фундаментальному образованию, по SysMoLan), вот их и издать. Проблема в том, что издание в книжной форме требует структурированности и последовательности изложения. Мой опыт говорит, что эти огромные цепочки нужно переписать, чтобы добиться этой структурированности и последовательности. Но будут ли читать результаты этой переписки больше, чем читают сейчас тексты самой цепочки? Не факт! Так что это всё тоже не планы, а "соображения".
-- курс про списки дисциплин личного развития (краткая версия слайдов доступна в https://ailev.livejournal.com/1448663.html, а курс http://system-school.ru/uptodate) -- это ведь тоже книжка, если это изложить письменно. Но мне почему-то кажется, что в личном изложении это ещё будут слушать, а вот книжку читать -- вряд ли. Массовая книжная культура уходит, увы. Так что трудозатраты очевидны, а польза от этих трудозатрат -- нет.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214034622433670

И я всегда это писал, но повторю ещё раз: в litres книжки в 13 электронных форматах, и многим это удобно (за 40 рублей). Но есть и бесплатно -- выложены "Системное мышление" поглавно как материал к каждой неделе бесплатного курса в Курсере -- http://systemsthinkingcourse.ru/, а "Визуальное мышление" полностью одним файлом как материал к первой главе.

https://ailev.livejournal.com/1450411.html

Очередной заход к онтологии системной инженерии, ST4SE (semantic technologies for systems engineering): https://sercuarc.org/wp-content/uploads/2018/06/SE-Ontology_Smith_slides.pdf -- осторожно, там 318 слайдов, презентация декабря 2017 года (видно в "свойствах" файла). Это всё на базе BFO 2.0 в OWL (basic formal ontology, это upper ontology от Barry Smith) -- http://basic-formal-ontology.org/. Все примеры госфинансированы: биология, экология, военные. Подчёркивается авторитарный характер этих онтологий. На BFO порядка 250 таких проектов. В презентации традиционные попытки определить понятия system, lifecycle, capability, function, service и т.д.. -- на базе различалок BFO.

Ещё один подобный заход -- это IOF (industry ontology foundry, предметная область промышленного производства, проект начали в 2016 и готов кусочек на 600 сущностей) на SKOS с участием того же Barry Smith: https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=925807, формальный сайт https://sites.google.com/view/industrialontologies/home.

В мире ISO 15926 тоже всё вяло, но проистекает: в этом году вышла часть 12, ISO/TS 15926-12:2018, Life-cycle integration ontology represented in Web Ontology Language -- https://www.iso.org/standard/70695.html.

Небольшой обзорчик по информационному моделированию и онтологиям (семантическим информационным моделям, как они там пишут) в системах автоматизации зданий знает про ISO 81346, но даже не поминает BFO, IOF, ISO 15926 -- https://www.researchgate.net/publication/321983944_A_survey_on_information_modeling_and_ontologies_in_building_automation

А ещё помним про knowledge graph и связанные с ними всякие 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 -- имя этим проектам легион, там просто нет "официальной и большой" upper ontology, по большому счёту речь идёт об инженерных онтиках, и инженерных моделях данных (тех же онтиках). Их тьма.

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

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

Но если ты собираешься делать SysMoLan Studio, то все эти работы хорошо бы знать: они являются коллекцией тех граблей, на которые можно наступить. При этом системный язык в инженерии можно понимать как хочешь:
-- управление конфигурацией системы, то есть регистрация функциональных, конструктивных, пространственных частей системы и их описаний. IEC 81346 и связанное с ним версионирование/registry. Первые PDM были ровно для этого: не потерять ничего, что творят проектировщики/конструкторы. Описать систему -- выдать сводную заказную спецификацию для системы и передать её куда-то в ERP, систему планирования производства и т.д.. Чтобы в спецификации было что-то кроме кодов, вводится аннотирование. В отчётах -- таблички. Вся информация о компонентах, модулях, местах -- в файлах. SysMoLan для такого использования -- это язык аннотации обозначаемых кодами IEC 81346 объектов, а Studio должна генерировать Excel-таблички. Ура, "системный язык готов".
-- выражение архитектурных решений, то есть демонстрация совмещения функциональной, модульной и пространственной структур. Это означает, что упор делается на какую-то трассировку соответствующих объектов друг ко другу по заранее предписанным отношениям и формализации способов аннотации. Получаем варианты SysMoLan типа SysML или ArchiMate, кому что больше нравится. Дальше можно извлечь объекты и получить спецификацию из предыдущего пункта.
-- Но можно пройти на шаг дальше и научиться трассировать схемы принципиальные/технологические к каким-то 3D моделям прежде всего. Это PLM-системы датацентрические, и в такую PLM уже непосредственно втыкаются CAD, чтобы сама трассировка была "автомагической" -- схема данных такой PLM по сути дела представляет системный язык. ISO 15926 представляет собой попытку сделать ровно вот такой системный язык "интеграции данных жизненного цикла", независимый от конкретной PLM (а во многих реальных PLM просто по факту использовались предварительные наработки по ISO 15926 в их версии 1997 года). А язык типа SysML или ArchiMate там есть? А как же! На нём рисуется "логическая архитектура" перед тем, как поручить те или иные части системы спроектировать в CAD и после готовности материалов из CAD они трассируются к созданным объектам. Беда только в том, что это идеальная конструкция не выживала в силу монструозности: PLM системы существовали и существуют, с болью интегрируя результаты работы различных CAD и систем моделирования прочности и мультифизики (а это не системная инженерия, а инженерия по специальности), а рядом появляются "системноинженерные системы" на базе каких-то вариантов архитектурных языков. И эти системы в особо крупных военных проектах выживают, но не слишком интегрируясь с PLM, а в не особо крупных проектах так вместо них используются просто тематические CAD (типа редакторов принципиальных схем и технологических диаграмм, крепко адаптированных для конкретной предметной области). Можно поглядеть ещё на аналогичную жизнь в архитектуре предприятия: архитектурные диаграммы (почему-то сразу предполагается графическая/диаграммная форма!) предприятия (например, на ArchiMate) просят не путать с архитектурными описаниями (чаще всего тоже диаграммами, причём на UML) софта, оговаривают их неподробность (типа "идите в BPMN и другие стандарты/моделеры за подробностями"), но почему-то делают сверку архитектуры IT-решения с СMDB (база данных менеджмента конфигурации для IT-службы). По факту архитектура предприятия трассируется и к следующему уровню инженерных решений "с подробностью, достаточной для изготовления", и оказывается частью управления конфигурацией (ибо новые объекты прежде всего появляются в ней). Ну, и современные варианты архитектуры предприятия включают в себя бизнес-архитектуру и целеполагание -- в "обычной" системной инженерии это требования. Прикасаешься к архитектурному языку, тут же огребаешь и потребности-требования, и управление конфигурацией, и (с учётом всех трассировок) PLM с её вечной задачей мэппинга различных видов CAD и необходимостью иметь "генератор конверторов" прямо из коробки.
-- ... тут ещё много идей, что считать "системным языком". Например, это онтологический язык, в которой понятие "система" является центральным для управления вниманием, а онтология понимается как раз как чеклист для управления вниманием: мир в этой онтологии состоит не из объектов, а из систем, и эти системы сразу по-разному описываются разными стейкхолдерами, исходя из их интересов. Это ничего не добавляет, но обозвал же Ян Диец свои архитектурные соображения по устройству организации "онтология предприятия", и Захман тоже назвал свой архитектурный подход "онтологией предприятия" -- вот и SysMoLan можно обозвать systems ontology со всей сопутствующей дискуссией про то, как переводить -- "онтология систем" или "системная онтология" (победит "системная онтология"). И да, не забыть всунуть в эту онтологию соображения Диеца и Захмана -- ибо нужно описывать не только целевые системы, но и обеспечивающие! SysMoLan должен и архитектуру предприятия описывать! Так что учитывать нужно не только инженерные онтологии, но и менеджерские/организационные.

В любом случае от обсуждения онтологического статуса объектов SysMoLan не уйти. По факту SysMoLan должен быть какой-то системной (системноинженерной и системноменеджерской) онтологией и моделью данных. Это означает, что:
а) нельзя выдумывать эту онтологию из головы. И нужно как-то вписываться в текущие онтологические наработки. Понятия брать из инженерных стандартов, а вот что там в части upper ontology и какой там уровень формальности -- это нужно тщательно выбирать. Успех ArchiMate IMHO в том, что там существенно смягчённые онтологические нормы. Впрочем, SysML в этом плане не хуже. SysMoLan должен быть суперкомпактен, ибо даже ArchiMate считают излишне богатым. SysMoLan не должен быть полноценным онтологическим языком, в котором из коробки достаётся BFO и/или ISO 15926 и/или IOF, и/или даже ST4SE -- это угробит проект на старте. Он должен быть суперкомпактным для очень узкого круга задач, минимального числа сценариев. Но этот суперкомпактный язык онтологически должен быть получше ArchiMate и SysML -- иначе зачем мы его делаем?! Нас же в текущих языках не устраивает именно отсутствие онтологии системного подхода! И это Сцилла.

б) Харибда в том, что к архитектуре тут же захочется трассировать все остальные описания (например, архитектурные расчёты), и страстно захочется PLM с развитым мэппингом, и SysMoLan Studio окажется эпицентром в каком-то Smart Data Lake со всеми вытекающими. Если делать SysMoLan как DSL на Julia, то это не выглядит чем-то страшным, но это хорошо бы предусмотреть на старте. Если уж сказал слово "онтология", то мэппинг у тебя будет -- для других целей обычно без этого слова обходятся. Тут системная онтология отходит на десятый план и на первый план выходит обычное моделирование данных -- вся дискусссия из https://www.infoq.com/news/2018/10/das-modern-data-architecture (это William McKnight on Data Platforms and Creating a Modern Data Architecture) к нам в гости. И фраза из презентации Barry Smith по первой ссылке текущего поста о том, что "онтологические вопросы сводились к вопросу о моделировании данных, это и губило проекты" (ну, или наоборот, позволяло проектам выживать -- никто ж не знает!).

в) А есть больше чем Сцилла и Харибда: в тот момент, когда захочется что-то делать с самой архитектурой -- все эти search-oriented architecture, differential architecture. Закладываться сразу на это? Так в этом никто ничего не понимает. Но современный архитектурный язык должен ползти как раз в этом направлении. И онтология SysMoLan тогда должна быть современной, на вероятностной логике -- тоже, желательно, "из коробки". Иначе риск унаследовать всю головную боль с болотом онтологических стандартов. Я рассматриваю текст про language models, knowledge graphs, relational models https://ailev.livejournal.com/1449229.html ровно по этой линии, заодно решая проблему мэппинга инженерных описаний как проблему перевода с языка на язык. Но это абсолютно исследовательское направление в абсолютно неизведанных водах, когда это всё дойдёт до практики -- непонятно, каких это потребует ресурсов -- преогромных. Но зато полный фронтир и есть чем хвастаться. Из минусов -- за это никто не заплатит, если не найдётся какой-то меценат. Не в России, конечно. И такой меценат не найдётся. То есть в ближайшей перспективе года-двух это утопия, но уже в трёхлетней перспективе differentiable architecture будет очень, очень горячей темой -- и если заняться сейчас, то через три года будем в эпицентре (но кушать эти три года будет совсем нечего, в этом-то и утопичность: "невозможность" и "крайняя привлекательность" одновременно).

У меня такое ощущение, что весь наш сегодняшний опыт показывает ровно те места, где лежат хорошо заметные рельсы антикварных неудачных технологий или суперфронтирных несуществующих технологий, в совокупности надёжно заводящие разработку системного языка и его моделера/студии в тупик.

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

Описание проекта SysMoLan Studio -- https://ailev.livejournal.com/1446524.html, и там есть все нужные ссылки, чтобы понять проект.

https://ailev.livejournal.com/1449992.html

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

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

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

Вот тут поминают меня как автора образа "электроэнергия -- это сыр" -- https://medium.com/internet-of-energy/1937c8206547. Сколько лет уж прошло!

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

https://ailev.livejournal.com/1449791.html

Не могу не перепостить танцующего фанк робота 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. И заставить его сплясать -- не раз плюнуть, но за несколько раз плюнуть уже можно справиться. Если это кому-то нужно, конечно. А дальше это будет обязательно кобот, так что и с человеком в паре он (она?!) тоже будет плясать.

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

https://ailev.livejournal.com/1449481.html

Моя любимая статья этой недели -- 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 про одно и то же, и это и есть онтологический/эпистемологический фронтир.

https://ailev.livejournal.com/1449229.html

Есть прикладные дисциплины, за них платят. Есть фундаментальные дисциплины, которые и образуют "умение мыслить". А есть ни то, ни сё: кругозор, который про наличие самих групп прикладных дисциплин, про сферы человеческой деятельности и как они связаны. Я описывал этот кругозор в постах про глубокие уровни абстракции 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

https://ailev.livejournal.com/1449158.html

Вот мои мечталки, связанные с 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 -- Так более выразительный язык помогает не только хорошую мысль выразить лаконично, но и плохую мысль выразить крайне точно и эффективно для её реализации на практике!

Вот и хотелось бы на распрекрасном языке выразить какие-то хорошие мысли.

https://ailev.livejournal.com/1448888.html

Сегодня побыл хедлайнером на 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

https://ailev.livejournal.com/1448663.html

Я уже писал, как я оцениваю партнёрш (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 лет. Но это всё очень вялые мысли, ибо для их реализации нужно забросить все остальные дела -- а кизомба и так занимает довольно много времени, я ведь не только на вечеринки хожу, но и продолжаю заниматься. Удовольствие от кизомбы растёт прямо пропорционально моему уровню танца, так что я не собираюсь прерывать занятия, я собираюсь и дальше увеличивать удовольствие -- повышать свой уровень. На другие танцы поэтому времени просто нет, так что разговор о них у меня только в сослагательном наклонении.

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

https://ailev.livejournal.com/1448326.html

Сегодня почти закончилась конференция по умным роботам и системам 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 года, в этой области нетленку не создашь. Всё быстро.

https://ailev.livejournal.com/1448129.html

Онтологическая инженерия -- это подход и средства, позволяющие описать успешную онтологию. Успешная онтология -- это которая будет затем использована для реализации успешных систем. Такое "словарное определение" я смастерил по образу и подобию определения системной инженерии (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 году нужно и тем, и другим.

https://ailev.livejournal.com/1447922.html

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

В эти выходные я урывками посещал кизомба-фестиваль 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

https://ailev.livejournal.com/1447611.html

В эти выходные у меня большие танцульки, я иду на "французский фестиваль в Москве" DJ Elite (https://vk.com/thedjselite):


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

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

Вот видео, где можно увидеть образцы меня танцующего в тепличных условиях студии: 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), исключительно импровизационно (это только на занятиях "танцуют строем"), да и сложнее танцевать, ибо места для танцев не так много, как в студии. То, что партнёршу ты эту можешь видеть первый раз,я даже не упоминаю -- это основная особенность социальных танцев.

https://ailev.livejournal.com/1447362.html

По Нильсу Бору профи -- это тот, кто не делает в какой-то предметной области типичных ошибок новичков. По Талебу успех рационального фланёра в том, чтобы не быть лохом -- не делать грубых ошибок "по глупости". В книжке Гаванде "Манифест чеклистов" (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

https://ailev.livejournal.com/1446993.html

До 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

https://ailev.livejournal.com/1446903.html

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

Текущие языки системного моделирования (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

https://ailev.livejournal.com/1446524.html