Репозиторий и дистрибутив
ailev в Openmeta (оригинал в ЖЖ)
| Теория моделирования | |||||
| Теория моделирования | ailev | ||||
| ОпенТренинг | |||||
| ОпенТренинг | greenogr | ||||
| Навыки vs метанойя | |||||
| Навыки vs метанойя | ailev | ||||
| из Питера Сенжа | |||||
| Из Питера Сенжа | kapterev | ||||
| Опен-мета-мета | |||||
| Опен-мета-мета | ailev | ||||
| Репозиторий, дистрибутив. v | |||||
| 2.0. Репозиторий, дистрибутив. v | ailev | ||||
В оригинальном значении этого слова, дистрибутив (distributive kit) -- это "распространяемый набор" каких-то предметов (в случае Linux -- пакетов). Как пишет Максим Отставнов, "Дистрибутив -- связующее звено между авторами свободных программ и их пользователями". Связующее звено между авторами и пользователями. Запомним.
Репозиторий -- это куча разнородных программ, из которой отбирается для какого-то целевого применения их взаимосвязанный набор. Репозиторий -- это инструмент работы самих авторов, использующийся для подготовки различных дистрибутивов. Пользователи с репозиторием не работают, с репозиторием работают авторы. Пользователи работают с дистрибутивами (куда, понятно, могут входить программы самых разных авторов).
Я предлагаю считать, что НЛП, эриксонианский гипноз и другие техники -- это огромный репозиторий самых разных идей, методов и основанных на них техник. Для разных конкретных применений (терапия, личностное развитие, исследования сознания, духовный рост и т.д.) из этих необъятных закромов может быть отобран компактный совместимый (и небольшой -- относительно всего репозитория) набор техник -- дистрибутив. Этот дистрибутив может существовать в виде книги или книжной серии, курсов, набора для какой-то практики.
Понятно, что ядро (базовые техники) у самых разных дистрибутивов будет одно и то же. А вот "специальные техники" (ибо каждый дистрибутив "заточен" под какое-то определенное типовое применение) будут сильно разниться. Для чего создаются дистрибутивы? Для удобства распространения: если распространять весь репозиторий, то одному человеку а) просто не под силу все освоить, б) техники могут быть плохо совместимы друг с другом, в) будет освоено много лишнего, что требуется относительно редко, в) нет формы, в какой осуществляется передача. А вот компактный дистрибутив, специально приспособленный для распространения будет распространяться.
Как я понимаю, курс НЛП-практик/мастер/тренер -- это дистрибутив моделей, широко распространенный и существенно стандартизованный авторами НЛП, которые набрали этот дистрибутив из своего обширнейшего репозитория (куда входит много больше моделей, нежели в курс НЛП-практика/мастера/тренера). В new_code делают свой, другой дистрибутив из этого репозитория, чуть-чуть дополняя своими моделями и техниками. В metapractice -- еще один вариант такой работы с акцентом на создание новых моделей для этого же репозитория. Бахтияров со своей психонетикой имеет совсем другой репозиторий. ОпенМета (как истинная мета) была озабочена не столько созданием дистрибутива, сколько попыткой обозреть разные репозитории и натаскать из них и из собственных идей свой, опенметовский репозиторий моделей. Ну, пятьсот человек пользователей так и не дождались сборки дистрибутива, а несколько затесавшихся авторов до сих пор юзают натасканное в этот огромный опенметовский репозиторий.
Жаль, если написанное мной понятно только для программистов. Надеюсь, кто-нибудь сможет развить идею и перевести этот текст на простой русский язык.
37 комментариев
сначала старые сначала новые
Задача истинной меты - обозрение не только разных репозиториев, но и способов сборки дистрибутивов на их основе, так получается.
Ну, мой пост как раз на эту тему: задает понятия, в которых возможны обсуждения этих способов.
И у нас было множество заходов на эту тему (например, про ДлинныеТехники и метанойи -- были попытки обсуждать их потребный список, сравнительные эффективности для того или сего. Говорилось про Курсы и Загрузчики, делалась попытка создать прообраз заведомо избыточного репозитория моделей -- http://community.livejournal.com/openmeta/164632.html). И были проблематизации как раз по поводу сборки дистрибутивов (например, http://community.livejournal.com/openmeta/164632.html).
С заданным мной разведением репозитория и дистрибутива можно возвращаться к этим темам много более конструктивно и обсуждать проблемы а) сборки разнозаточенных дистрибутивов, обсуждая вопросы их разнообразия и находя незанятые и нестандартные ниши -- типа как пикапщики юзают репозиторий НЛП, сделав свой вторичный репозиторий и создав несколько разных весьма специфических дистрибутивов; б) разницу между авторами моделей, сборщиками и пользователями (а не только авторами и пользователями. Впрочем, мы уже сделали заход на эту тему, когда ввели троицу Алисы, Боба и Чарли, но опять-таки это "получилось по факту", но не было достаточно отрефлектировано. Скажем, в ОпенМете взаимодействие между этими ролями не было отыграно -- Алисы и Бобы чем-то таким занимались вокруг репозиториев, а "дистрибутив как путь к пользователю" не складывался, что оставило огромное количество Чарли-зевак без ожидаемого удовлетворения); в) рассматривать технологии сборки более-менее полных дистрибутивов, а не обрывочно-дырявых (как минимум для этого задав понятие ядра). Это очень большой пласт тем.
И у нас было множество заходов на эту тему (например, про ДлинныеТехники и метанойи -- были попытки обсуждать их потребный список, сравнительные эффективности для того или сего. Говорилось про Курсы и Загрузчики, делалась попытка создать прообраз заведомо избыточного репозитория моделей -- http://community.livejournal.com/openmeta/164632.html). И были проблематизации как раз по поводу сборки дистрибутивов (например, http://community.livejournal.com/openmeta/164632.html).
С заданным мной разведением репозитория и дистрибутива можно возвращаться к этим темам много более конструктивно и обсуждать проблемы а) сборки разнозаточенных дистрибутивов, обсуждая вопросы их разнообразия и находя незанятые и нестандартные ниши -- типа как пикапщики юзают репозиторий НЛП, сделав свой вторичный репозиторий и создав несколько разных весьма специфических дистрибутивов; б) разницу между авторами моделей, сборщиками и пользователями (а не только авторами и пользователями. Впрочем, мы уже сделали заход на эту тему, когда ввели троицу Алисы, Боба и Чарли, но опять-таки это "получилось по факту", но не было достаточно отрефлектировано. Скажем, в ОпенМете взаимодействие между этими ролями не было отыграно -- Алисы и Бобы чем-то таким занимались вокруг репозиториев, а "дистрибутив как путь к пользователю" не складывался, что оставило огромное количество Чарли-зевак без ожидаемого удовлетворения); в) рассматривать технологии сборки более-менее полных дистрибутивов, а не обрывочно-дырявых (как минимум для этого задав понятие ядра). Это очень большой пласт тем.
стоит ли раздавать рыбу, людям у которых есть удочки?
или я что-то важное упустил из повествования.
или я что-то важное упустил из повествования.
А что у вас рыба? А что у вас удочки? А какие одни люди раздают каким другим людям эту самую рыбу? Совсем непонятно :(
![[userpic]](http://localhost:4000/images/none.gif)
В продолжении метафоры, хочу добавить ещё одно понятие репозитория. Как в системе управления версиями, subversion нампример. У нас есть репозиторий кода, из него можно сделать checkout т.н. рабочей копии. Части актуального кода. Одной ветки. Сделать копию основной ветки, поработать над ней, и, возможно, слить с основной векткой в более или менее далёком будущем (branches). Отфиксировать текущее состояние (tags). Вытащить только небольшой кусочек кода (плагин) и работать только с ним, ни сколько не заботясь о целостности остального кода.
В этом смысле, мы имеем конструкцию «репозиотрий – рабочая копия», специально ориентированное на разработчика, дизайнера, писателя, евангелиста и т.д., предполагающую и стимулирующую вклад от участника. При том, что существует большое число энтузиастов-пользователей, стремящихся жить on the edge, читающие лог изменений, поддерживая свою рабочую копию постоянно в свежем виде. Отсюда прямая и быстрая дорога к включению такого энтузиаста в общий процесс разработки, рекрутинга интересующегося продвинутого пользователя в активного контрибьютора.
В то время, как «Репозиторий (пакетов) – Дистрибутив» – это как раз механизм выпуска конечного продукта, для конечного пользователя. Кроме собственно сборки пакетов, построенных из отфискированного на некоторый момент кода (доступного из того же subversion оригинального разработчика), предполагается поддержание механизмов отслеживания зависимостей, автоматическая сборка билдов, создание специфических установочных скриптов и локальных настроек, тестирование стабильности работы, и т.п. Т.е. это не совсем уровень разработчика. Это уровень мэйнтейнера. Ничуть при этом не менее значимый для конечного результата, чем уровень разработчика. Плюс к тому, существует ещё и традиция LinuxFromScratch в той или иной форме.
«Репозиторий (кода) – Рабочая копия» – это инструмент разработчика, для совместной работы над кодом в традициях ОпенСорс. Там где, собственно говоря, и рождается что-то новое.
Теперь, возвращаясь на грешную землю, что мы имеем? Несколько дистрибутивов, собранных из «классических» пакетов по образу и подобию (курсы НЛП практик/мастер/тренер)? Несколько проектов создания нового и интересного кода, на сегодняшний день очень слабо дифференцированного на отдельные «пактеты», «фреймворки», «плагины», и создаваемого в стиле FromScratch (это на мой несколько поверхностный вкус, бегло наблюдающего «по диагонали» за openmeta, metapractice и newcode, вполне вероятно что там внутри всё «по-взрослому», только это снаружи не очень видно)?
Разве openmeta имела своей целью только обозревать репозитории, дистрибутивы и интересные проекты, продуцировать видение всей широкой картинки и роудмапов и собирать свои дистрибутивы для пользователей? Мне казалось, что важным направлением было стимулирование ислледованией и разработок, расширение числа контрибьюторов, в духе ОпенСорс движения из этой самой компьютерной метафоры. Есть ли возможность вот как-то так разложить по полочкам: сюда – разработку, туда – тестирование и сборка дистрибутивов? Сюда – поддержку, туда – пропаганду? Роль openmeta именно в том самом связующем звене Максима Отставнова между авторами и пользователями? Или между авторами и авторами, пользователями, мэйнтейнерами дистрибутивов, проповедниками, тусовщиками, философами и предпринимателями?
Незнаю, насколько имеет смысл продолжать эту метафору дальше. Возможно, тот факт, что сейчас есть условно говоря 5 затесавшихся контрибьюторов и 500 ожидающих релиза early adopters, означает, что это не конечные пользователи, а активные интересующиеся фанаты стиля living on the edge. И тут не нужен полноценный релиз, а нужны хорошее видение, роудмап, ясное понимание перспектив и возможности соучастия.
2be continued...
В этом смысле, мы имеем конструкцию «репозиотрий – рабочая копия», специально ориентированное на разработчика, дизайнера, писателя, евангелиста и т.д., предполагающую и стимулирующую вклад от участника. При том, что существует большое число энтузиастов-пользователей, стремящихся жить on the edge, читающие лог изменений, поддерживая свою рабочую копию постоянно в свежем виде. Отсюда прямая и быстрая дорога к включению такого энтузиаста в общий процесс разработки, рекрутинга интересующегося продвинутого пользователя в активного контрибьютора.
В то время, как «Репозиторий (пакетов) – Дистрибутив» – это как раз механизм выпуска конечного продукта, для конечного пользователя. Кроме собственно сборки пакетов, построенных из отфискированного на некоторый момент кода (доступного из того же subversion оригинального разработчика), предполагается поддержание механизмов отслеживания зависимостей, автоматическая сборка билдов, создание специфических установочных скриптов и локальных настроек, тестирование стабильности работы, и т.п. Т.е. это не совсем уровень разработчика. Это уровень мэйнтейнера. Ничуть при этом не менее значимый для конечного результата, чем уровень разработчика. Плюс к тому, существует ещё и традиция LinuxFromScratch в той или иной форме.
«Репозиторий (кода) – Рабочая копия» – это инструмент разработчика, для совместной работы над кодом в традициях ОпенСорс. Там где, собственно говоря, и рождается что-то новое.
Теперь, возвращаясь на грешную землю, что мы имеем? Несколько дистрибутивов, собранных из «классических» пакетов по образу и подобию (курсы НЛП практик/мастер/тренер)? Несколько проектов создания нового и интересного кода, на сегодняшний день очень слабо дифференцированного на отдельные «пактеты», «фреймворки», «плагины», и создаваемого в стиле FromScratch (это на мой несколько поверхностный вкус, бегло наблюдающего «по диагонали» за openmeta, metapractice и newcode, вполне вероятно что там внутри всё «по-взрослому», только это снаружи не очень видно)?
Разве openmeta имела своей целью только обозревать репозитории, дистрибутивы и интересные проекты, продуцировать видение всей широкой картинки и роудмапов и собирать свои дистрибутивы для пользователей? Мне казалось, что важным направлением было стимулирование ислледованией и разработок, расширение числа контрибьюторов, в духе ОпенСорс движения из этой самой компьютерной метафоры. Есть ли возможность вот как-то так разложить по полочкам: сюда – разработку, туда – тестирование и сборка дистрибутивов? Сюда – поддержку, туда – пропаганду? Роль openmeta именно в том самом связующем звене Максима Отставнова между авторами и пользователями? Или между авторами и авторами, пользователями, мэйнтейнерами дистрибутивов, проповедниками, тусовщиками, философами и предпринимателями?
Незнаю, насколько имеет смысл продолжать эту метафору дальше. Возможно, тот факт, что сейчас есть условно говоря 5 затесавшихся контрибьюторов и 500 ожидающих релиза early adopters, означает, что это не конечные пользователи, а активные интересующиеся фанаты стиля living on the edge. И тут не нужен полноценный релиз, а нужны хорошее видение, роудмап, ясное понимание перспектив и возможности соучастия.
2be continued...
(... continued)
Впрочем, как мне кажется, всё это уже неоднократно случалось на разных фазах истории openmeta. Были и неоднократные проходы по целям, и супер-интересные и полезные модели, и много чего ещё. Может быть, теперь нужен удобный инструмент, который бы позволил постоянно иметь актуальную рабочую копию (только?) тех проектов и пакетов, которые интересны участнику? Это была мысль в сторону практик создания кода и разработок.
Или вот ещё такая сумасшедшая мысль: может быть, нужно грамотное и толковое руководство, туториал из серии «Как собственными силами собрать свой рабочий дистрибутив на базе openmeta (за полчаса ;)». Что, если 50 человек из этих 500 сделают 10 маленьких узкоспециализированных дистрибутивов из того, что уже сейчас доступно и поделятся впечатлениями от процесса? Это была мысль в сторону практик сборки и поддержки дистрибутивов.
Впрочем, как мне кажется, всё это уже неоднократно случалось на разных фазах истории openmeta. Были и неоднократные проходы по целям, и супер-интересные и полезные модели, и много чего ещё. Может быть, теперь нужен удобный инструмент, который бы позволил постоянно иметь актуальную рабочую копию (только?) тех проектов и пакетов, которые интересны участнику? Это была мысль в сторону практик создания кода и разработок.
Или вот ещё такая сумасшедшая мысль: может быть, нужно грамотное и толковое руководство, туториал из серии «Как собственными силами собрать свой рабочий дистрибутив на базе openmeta (за полчаса ;)». Что, если 50 человек из этих 500 сделают 10 маленьких узкоспециализированных дистрибутивов из того, что уже сейчас доступно и поделятся впечатлениями от процесса? Это была мысль в сторону практик сборки и поддержки дистрибутивов.
Да, это я писал все именно про систему выпуска всегда актуальных версий, адаптированных под разные применения и заведомо включающих не всё наработанное, а только небольшую часть.
И явное выделение позиции maintainer (как бы это лучше по-русски для наших применений?).
И явное выделение позиции maintainer (как бы это лучше по-русски для наших применений?).
1. Первое упоминание было в постинге thecroaker -- http://community.livejournal.com/openmeta/18208.html
2. Затем я обратил внимание на это слово и ввел его в оборот специальным образом -- http://community.livejournal.com/openmeta/33585.html
2. Затем я обратил внимание на это слово и ввел его в оборот специальным образом -- http://community.livejournal.com/openmeta/33585.html
Да, забавные искажения.
В своем постинге (вторая приведенная ссылка) я специально добавил христианские поговорки.
Эх, было бы время, переписать бы сейчас всю эту ОпенМету. Или хотя бы перчитать с самого начала...
В своем постинге (вторая приведенная ссылка) я специально добавил христианские поговорки.
Эх, было бы время, переписать бы сейчас всю эту ОпенМету. Или хотя бы перчитать с самого начала...
Ну, сделайте расследование :)
Насчет языка Пра -- я принимал участие в его разработке в самом конце 80-х (группа "Аттик" мехмата МГУ, для этого мы даже выезжали как-то на несколько дней в Пущино. Хороший был проект, до сих пор его жалко). А с пучком Гисса вам лучше сначала к кардиологу, а уж только затем в ОпенМету.
Насчет языка Пра -- я принимал участие в его разработке в самом конце 80-х (группа "Аттик" мехмата МГУ, для этого мы даже выезжали как-то на несколько дней в Пущино. Хороший был проект, до сих пор его жалко). А с пучком Гисса вам лучше сначала к кардиологу, а уж только затем в ОпенМету.
Тогда я знаю, откуда это: http://www.zooservice.ru/product_info.php?products_id=476&osCsid=7acf46fcb459f7559a79c60a0a86042c
Перепросмотр, как советую классики, надо делать обязательно в деревянном гробу, а лучше в земле сырой :)
Кстати, насчет репозитория и прочего... Почему бы не написать специальный софт для метамоделеров? MetaCAD. Я над этим уже пару недель пассивно думаю. Или такой уже есть?
Если нет... Может, как-нибудь после Нового Года списаться, да и сделать?
Мне кажется, очень важная часть здесь - "варианты использования". А то всяких полезных знаний наплодили дофига, а вот куда их применять? Как-то не по-сисарховски это ;)
Кстати, насчет репозитория и прочего... Почему бы не написать специальный софт для метамоделеров? MetaCAD. Я над этим уже пару недель пассивно думаю. Или такой уже есть?
Если нет... Может, как-нибудь после Нового Года списаться, да и сделать?
Мне кажется, очень важная часть здесь - "варианты использования". А то всяких полезных знаний наплодили дофига, а вот куда их применять? Как-то не по-сисарховски это ;)
Софта всякого уже очень много -- вы на какую тему-то софт затеяли? Учить-тренировать, знания представлять в лучшем виде, или еще что?
Сделайте на эту тему отдельный пост с результатами ваших размышлений -- и обсудим всем миром.
Сделайте на эту тему отдельный пост с результатами ваших размышлений -- и обсудим всем миром.
Я бы чуть расширил метафору.
То, что мы имеем в НЛП, ЭГ и прочем - это скорее некий исходный код, разбросанный на просторах неведомо чего - со своими (хитрыми) правилами и инструментами сборки, специфическими (и явно не прописанными) зависимостями, требованиями к платформе и так далее.
Здесь первым шагом было бы как раз построение репозитория - систематизированного хранилища, в котором содержимое заведомо может быть использовано при соблюдении ряда явно описанных критериев.
Вот тогда можно будет сказать, что входит в ядро (на основе зависимостей), и планка требований к дистрибутиво строителям опустится до терпимого уровня...
Сейчас этого репозитрия и близко нет - даже для арсенала НЛП, являющегося самым структурированным из всех подобных проектов, не прописаны зависимости навыков друг от друга, не прописаны критерии существования навыков, нет внятных методик обучения. Кое-что из дыр с критериями и методиками закрыто в Опенмете, кое-что - вероятно, в Метапрактике. А толку - найдут их там опять несколько авторов, которым они, собственно, и не слишком нужны. Какие уж тут дистрибутивы...
То, что мы имеем в НЛП, ЭГ и прочем - это скорее некий исходный код, разбросанный на просторах неведомо чего - со своими (хитрыми) правилами и инструментами сборки, специфическими (и явно не прописанными) зависимостями, требованиями к платформе и так далее.
Здесь первым шагом было бы как раз построение репозитория - систематизированного хранилища, в котором содержимое заведомо может быть использовано при соблюдении ряда явно описанных критериев.
Вот тогда можно будет сказать, что входит в ядро (на основе зависимостей), и планка требований к дистрибутиво строителям опустится до терпимого уровня...
Сейчас этого репозитрия и близко нет - даже для арсенала НЛП, являющегося самым структурированным из всех подобных проектов, не прописаны зависимости навыков друг от друга, не прописаны критерии существования навыков, нет внятных методик обучения. Кое-что из дыр с критериями и методиками закрыто в Опенмете, кое-что - вероятно, в Метапрактике. А толку - найдут их там опять несколько авторов, которым они, собственно, и не слишком нужны. Какие уж тут дистрибутивы...
ага.
правда софт конкретно для организации нажитого - это такая довольно жесткая штука.
то есть как например рисовать майндмэпы или там вписывать в таблички модели - это мы умеем. но "организация нажитого" - это уровнем повыше задача будет.
"в плане организации нажитого"
что есть такое "организация"?
нечто объектно-реляционное: набор объектов, и связей между ними? Опциалнально по связям еще их "веса".
Или как-нибудь по-другому?
"нажитого".
что такое "нажитое"? Как оно будет извлекаться?
То есть допустим если процедура извлечения - перепросмотр по ККДХ, то формат данных один (допустим, отрывки видеофильмов).
Если сразу паттерны (или претендующие на них системные образы) - то другой. Если образы-ассоциации - то третий.
Можно конечно заимплементить сразу всё, но тогда есть подозрение что сил и времени не хватит на такой детализованный разбор опыта (и разработку сложного ПО, кстати!).
"нет сил"
это кстати, как? ;) я недавно для себя моделировал/рушил это самое "нет сил"...
"смотреть на это бардак"
то есть нужно или переструктурировать визуальный образ, или уйти в другую репрезентативную систему.
Компьютеры сейчас хорошо работают только с визуальной, гораздо хуже с аудиалкой, а кинестетика только в плане передачи ее через визуалку и аудио (например, расстояние между иконками на рабочем столе - это кинестетика).
правда софт конкретно для организации нажитого - это такая довольно жесткая штука.
то есть как например рисовать майндмэпы или там вписывать в таблички модели - это мы умеем. но "организация нажитого" - это уровнем повыше задача будет.
"в плане организации нажитого"
что есть такое "организация"?
нечто объектно-реляционное: набор объектов, и связей между ними? Опциалнально по связям еще их "веса".
Или как-нибудь по-другому?
"нажитого".
что такое "нажитое"? Как оно будет извлекаться?
То есть допустим если процедура извлечения - перепросмотр по ККДХ, то формат данных один (допустим, отрывки видеофильмов).
Если сразу паттерны (или претендующие на них системные образы) - то другой. Если образы-ассоциации - то третий.
Можно конечно заимплементить сразу всё, но тогда есть подозрение что сил и времени не хватит на такой детализованный разбор опыта (и разработку сложного ПО, кстати!).
"нет сил"
это кстати, как? ;) я недавно для себя моделировал/рушил это самое "нет сил"...
"смотреть на это бардак"
то есть нужно или переструктурировать визуальный образ, или уйти в другую репрезентативную систему.
Компьютеры сейчас хорошо работают только с визуальной, гораздо хуже с аудиалкой, а кинестетика только в плане передачи ее через визуалку и аудио (например, расстояние между иконками на рабочем столе - это кинестетика).
лично я забил на структуризацию реального опыта с помощью софта, и на досуге пишу игру Паттерн, посвященную вариациям произвольных структур. Если(когда) напишу версию для "нормальных людей" - напишу в ЖЖ и кину полное описание.
Соглашусь.
Только вот с "зависимостями" тут трудно -- я бы их называл "совместимостями". Это ведь все-таки не "фреймворки" или "библиотеки" (в смысле "того, откуда пользовательский код вызывается" и "того, что вызывается пользовательским кодом").
Правильно тут было бы (о чем я все время писал) провести работу по мэппингу разных понятий разных кусков кода, которые были наработаны во всех психотехнических направлениях. Я тут все время писал про онтологическую работу, но никак не мог понять, как это можно было бы сделать технологически. Вот только сейчас примерно понял (см., например, http://ailev.livejournal.com/627019.html пункт 2 -- об использовании Gellish и его метода моделирования предметной области для стыковки понятий разных дисциплин). Это и будет аналогом "прописывания взаимозависимостей", только взятой не из наработок по "исполняемому коду", а из наработок по интегрированию промышленных данных (ISO 15926 и Gellish).
Только вот с "зависимостями" тут трудно -- я бы их называл "совместимостями". Это ведь все-таки не "фреймворки" или "библиотеки" (в смысле "того, откуда пользовательский код вызывается" и "того, что вызывается пользовательским кодом").
Правильно тут было бы (о чем я все время писал) провести работу по мэппингу разных понятий разных кусков кода, которые были наработаны во всех психотехнических направлениях. Я тут все время писал про онтологическую работу, но никак не мог понять, как это можно было бы сделать технологически. Вот только сейчас примерно понял (см., например, http://ailev.livejournal.com/627019.html пункт 2 -- об использовании Gellish и его метода моделирования предметной области для стыковки понятий разных дисциплин). Это и будет аналогом "прописывания взаимозависимостей", только взятой не из наработок по "исполняемому коду", а из наработок по интегрированию промышленных данных (ISO 15926 и Gellish).
Как я понимаю, автор удаленного коммента понимал "организацию" как "архитектуру "(я недавно писал про определение "архитектуры" через "организацию" -- http://ailev.livejournal.com/612830.html, а также см. замечание http://community.livejournal.com/methodology_ru/130741.html?thread=1881269): вынос на уровень собственного осознания основных концептов "нажитого" и их связей. То есть для "организации" ему (ибо он визуален) нужно было бы увидеть картинку "нажитого" крупными блоками, причем с интеракциями между этими блоками (основная идея как "архитектуры", так и "организации" -- это интеракция).
"Нажитое" тут -- это, конечно, "отчужденная модель себя", чтобы над ней можно было бы поразмышлять, как это говорится в GTD ("Главное -- это выкинуть все из головы на какое-то медиа. Нет никакой нужды думать одну мысль дважды, если только вы не любите думать именно её. Сознание -- это экран, не память. Сознание показывает то, что находится в кратковременной, оперативной памяти. А в этой памяти находится все то, о чем вы беспокоитесь: мысли отвлекаются, а никакого прогресса не делается. Поэтому нужно выгрузить все из оперативной памяти вовне, и там это и организовывать -- в внешней памяти не будет никаких "мелькающих мыслей", чистый текст", http://ailev.livejournal.com/384198.html).
Конечно, тут не имеется ввиду собственно переорганизация субъективного опыта -- а изучение его для того, чтобы понять, как и во что переорганизовывать. Тут, конечно, можно пойти по "помоги мне, бессознательное" пути, но бессознательное не слишком хорошо в вопросах целеполагания и упорядочивания. Оно в другом сильно: лошадь хорошо везет, но плохо знает, куда везти. Доверяться лошади в том, что тебя отвезут неслучайным образом, было бы неверно. Поэтому и предлагается путь через выгрузку модели "себя любимого"="нажитого" вовне, в какой-нибудь софт (ибо современный софт -- это аналог ручки и бумажки прошлого века. Доска и мел, скрижаль и долото).
Кстати, сама мысль о "личностной архитектуре", загруженной в софт наподобие Enterprise Architecture (с поддержкой разных view и их взаимосвязи) -- интересная мысль. Далее отсюда прямой проход к бэндлеровским "дизайнам" (альтернативное понятие "архитектуры" -- это ограничение в дизайн-принципах, при этом различение используемых моделей на конструктивные и функциональные и требование иметь в архитектуре обе -- про это в первой книжке из http://community.livejournal.com/openmeta/199621.html).
Понятно, что софтовые интерфейсы к этим моделям пока могут быть традиционными: графические и текстовые окошки с разными символьными репрезентациями моделей.
А насчет "нет сил": глаза боятся, руки делают ;)
"Нажитое" тут -- это, конечно, "отчужденная модель себя", чтобы над ней можно было бы поразмышлять, как это говорится в GTD ("Главное -- это выкинуть все из головы на какое-то медиа. Нет никакой нужды думать одну мысль дважды, если только вы не любите думать именно её. Сознание -- это экран, не память. Сознание показывает то, что находится в кратковременной, оперативной памяти. А в этой памяти находится все то, о чем вы беспокоитесь: мысли отвлекаются, а никакого прогресса не делается. Поэтому нужно выгрузить все из оперативной памяти вовне, и там это и организовывать -- в внешней памяти не будет никаких "мелькающих мыслей", чистый текст", http://ailev.livejournal.com/384198.html).
Конечно, тут не имеется ввиду собственно переорганизация субъективного опыта -- а изучение его для того, чтобы понять, как и во что переорганизовывать. Тут, конечно, можно пойти по "помоги мне, бессознательное" пути, но бессознательное не слишком хорошо в вопросах целеполагания и упорядочивания. Оно в другом сильно: лошадь хорошо везет, но плохо знает, куда везти. Доверяться лошади в том, что тебя отвезут неслучайным образом, было бы неверно. Поэтому и предлагается путь через выгрузку модели "себя любимого"="нажитого" вовне, в какой-нибудь софт (ибо современный софт -- это аналог ручки и бумажки прошлого века. Доска и мел, скрижаль и долото).
Кстати, сама мысль о "личностной архитектуре", загруженной в софт наподобие Enterprise Architecture (с поддержкой разных view и их взаимосвязи) -- интересная мысль. Далее отсюда прямой проход к бэндлеровским "дизайнам" (альтернативное понятие "архитектуры" -- это ограничение в дизайн-принципах, при этом различение используемых моделей на конструктивные и функциональные и требование иметь в архитектуре обе -- про это в первой книжке из http://community.livejournal.com/openmeta/199621.html).
Понятно, что софтовые интерфейсы к этим моделям пока могут быть традиционными: графические и текстовые окошки с разными символьными репрезентациями моделей.
А насчет "нет сил": глаза боятся, руки делают ;)
Именно зависимости. Возьмем, к примеру, навык "установка якоря". Если грубо, он зависит от:
- навыка "создание фокуса внимания" - вероятно, бессознательного
- навыка "калибровка изменений в физиологии"
- навыка "выбор нужного состояния"
- навыка "калибровка пика состояния" (зависящего от "калибровки изменений".
- навыка "выбор сигнала, который станет якорем"
Из этого в НЛП, к примеру, осознается как отдельный навык только "калибровка изменений".
И с этой точки зрения - это именно библиотеки вызываемого кода - для обучения установке якоря все навыки, от которых он зависит, должны уже быть установлены как автоматические стратегии, именно "вызываемые" в нужный момент.
- навыка "создание фокуса внимания" - вероятно, бессознательного
- навыка "калибровка изменений в физиологии"
- навыка "выбор нужного состояния"
- навыка "калибровка пика состояния" (зависящего от "калибровки изменений".
- навыка "выбор сигнала, который станет якорем"
Из этого в НЛП, к примеру, осознается как отдельный навык только "калибровка изменений".
И с этой точки зрения - это именно библиотеки вызываемого кода - для обучения установке якоря все навыки, от которых он зависит, должны уже быть установлены как автоматические стратегии, именно "вызываемые" в нужный момент.
Глянув на дату исходного поста, я побил комментарии - и, наверное, зря.
Я, вообще-то, имел в виду софт, в котором в удобном и обозримом виде можно было бы прописать навыки, их зависимости друг от друга (см. мой коммент выше), и выбрать для любого набора навыков все, что он за собой тащит из зависимостей. НО. "Прописать навыки" не просто названиями, а как модели, пригодные для:
- инсталляции
- проверки - есть ли у человека такая модель.
с точки зрения поддержки софтом здесь много не сделаешь - но нужные поля ввести надо: внутренние критерии наличия, внешние критерии, алгоритм/стратегия, может, еще что-то...
С другой стороны - навыки должны организовываться в смысловые группы (к примеру, "изменение состояния", или "создание фокуса внимания"). Понятно, что такие группы могут пересекаться.
Это тот минимум, который пришел в голову сразу.
Кстати, в таком случае начиают происходить интересные вещи - если стратегия выписана не процессуально, как в НЛП, а по достигаемым целям - имеем сразу пучок различных вариантов - в которых стратегия одна, а методы достижения подцелей различны. Вот вам и "создание техник" нлп-мастерское...
То есть цель - создать софт поддержки репозитория - и как естественно вытекающее следствие - создания дистрибутива.
Дальше его, вероятно, можно будет расширить играми/упражнениями (в смысле - компьютерными) для установки навыков.
Я, вообще-то, имел в виду софт, в котором в удобном и обозримом виде можно было бы прописать навыки, их зависимости друг от друга (см. мой коммент выше), и выбрать для любого набора навыков все, что он за собой тащит из зависимостей. НО. "Прописать навыки" не просто названиями, а как модели, пригодные для:
- инсталляции
- проверки - есть ли у человека такая модель.
с точки зрения поддержки софтом здесь много не сделаешь - но нужные поля ввести надо: внутренние критерии наличия, внешние критерии, алгоритм/стратегия, может, еще что-то...
С другой стороны - навыки должны организовываться в смысловые группы (к примеру, "изменение состояния", или "создание фокуса внимания"). Понятно, что такие группы могут пересекаться.
Это тот минимум, который пришел в голову сразу.
Кстати, в таком случае начиают происходить интересные вещи - если стратегия выписана не процессуально, как в НЛП, а по достигаемым целям - имеем сразу пучок различных вариантов - в которых стратегия одна, а методы достижения подцелей различны. Вот вам и "создание техник" нлп-мастерское...
То есть цель - создать софт поддержки репозитория - и как естественно вытекающее следствие - создания дистрибутива.
Дальше его, вероятно, можно будет расширить играми/упражнениями (в смысле - компьютерными) для установки навыков.
А может, есть что-то такое? Задачка-то довольно распространенная, по идее - описать набор базовых блоков и то, как из них собирается что-то большее...
Т.е. "для себя" здесь вторично. первична - возможность коллективного наполнения этого репозитория.
Ну, я вас правильно понял. Только я использовал в своем комменте другие слова. Так, выписывание стратегии по достигаемым целям -- это как раз функциональное описание по Jan Dietz, а "процессуальное" -- конструктивное описание. И так далее: пройдитесь по рекомендованным мной ссылкам.
Софт при таком подходе сводится к обычному софту представления знаний. Я склоняюсь сейчас к использованию языка представления знаний Gellish, хотя специализированный софт для него (увы!) пока доступен только коммерческий. Впрочем, хранить знания на Gellish можно в электронных таблицах, или в базах данных -- там табличный формат представления данных. Опять же, пройдитесь по ссылкам ;)
Софт при таком подходе сводится к обычному софту представления знаний. Я склоняюсь сейчас к использованию языка представления знаний Gellish, хотя специализированный софт для него (увы!) пока доступен только коммерческий. Впрочем, хранить знания на Gellish можно в электронных таблицах, или в базах данных -- там табличный формат представления данных. Опять же, пройдитесь по ссылкам ;)
Конечно, есть. Задача неоднократно встречалась при создании САПР, в которых нужно собрать что-то огромное (скажем, собрать виртуальную модель самолета из мельчайших винтиков, или нефтяной платформы из отдельных трубопроводов, или электростанции -- и совместить при этом знания электриков, материаловедов, бизнесменов, логистиков, проектировщиков, пользователей и т.д.).
Ага. Со всеми вытекающими задачами отслеживания рассогласований. Т.е. операциями commit и отслеживанием версий.
Другая формулировка для той же проблемы -- это "технологическая платформа" против "конкретного продукта". Технологическая платформа -- это все, что бывает. А в конкретный продукт (вариант) входит только то, что нужно и взаимосогласовано. И тут уже не только нужно управление версиями продукта, но и управление вариантами (продуктами) в рамках технологической платформы.
В репозитории (сосуде, СУБД), вестимо, бултыхаются и технологическая платформа, и конкретные продукты (содержание, знание).
Я тут писал для этого случая привязку к концепции жизненных циклов: http://ailev.livejournal.com/626229.html. Только слова подставьте про НЛП, ЭГ и т.д.
Другая формулировка для той же проблемы -- это "технологическая платформа" против "конкретного продукта". Технологическая платформа -- это все, что бывает. А в конкретный продукт (вариант) входит только то, что нужно и взаимосогласовано. И тут уже не только нужно управление версиями продукта, но и управление вариантами (продуктами) в рамках технологической платформы.
В репозитории (сосуде, СУБД), вестимо, бултыхаются и технологическая платформа, и конкретные продукты (содержание, знание).
Я тут писал для этого случая привязку к концепции жизненных циклов: http://ailev.livejournal.com/626229.html. Только слова подставьте про НЛП, ЭГ и т.д.
А что такое "зависит"? Если нет навыка по цепочке зависимостей, то навыка не может быть?
Тут еще нужно понять, вы даете функциональные формулировки, или конструктивные. Пока похоже на функциональные (задается цель, что нужно получить -- но не механизм получения). С другой стороны, сама цепочка "зависимостей" -- это обычно конструктивная цепочка (конструкция, которую понятно как собрать, и которая позволяет получить заданный результат). Тут нужно еще покопаться, что является в этих навыках теми объектами, из которых дальше все эти навыки конструируются. Субмодальности?
Тут еще нужно понять, вы даете функциональные формулировки, или конструктивные. Пока похоже на функциональные (задается цель, что нужно получить -- но не механизм получения). С другой стороны, сама цепочка "зависимостей" -- это обычно конструктивная цепочка (конструкция, которую понятно как собрать, и которая позволяет получить заданный результат). Тут нужно еще покопаться, что является в этих навыках теми объектами, из которых дальше все эти навыки конструируются. Субмодальности?
Навыки-"кирпичики" (зависимости) дл текущего навыка описываются функционально.
Если нужен навык "быстрой разбивки состояния", мне безразлично, как именно эта самая разбивка будет осуществляться. Аналог - абстрактный класс из программирования, конкретная реализация неприципиальна.
разумеется, если обучаемый не владеет ни одной реализацией данной зависимости, навык он получить не сможет. конечно, может оказаться, что в процессе обучения новому навыку он смог "придумать" и навык-кирпичик, но полагаться на эт мы не можем. В этом, кстати, было бы одно из важных отличий от НЛП - там обучаемому часто именно этим и приходится заниматься - одновременно обучаться нескольким вещам. Не самый эффективный путь... Кстати, вышеописанное якорение - хороший пример.
Сам же конструируемый навык, насколько я понимаю, должен быть описан именно конструктивно, это некий алгоритм.
Примерно так, если я не запутался в терминологии. Если есть принципиальные замечания - буду очень благодарен, так как в ближайшее время займусь всем этим делом вплотную, и хотелось бы получше все спланировать, избежав явных проблем...
А до ссылочек не доберусь никак - может, сначала их осилить, как думаете?
Если нужен навык "быстрой разбивки состояния", мне безразлично, как именно эта самая разбивка будет осуществляться. Аналог - абстрактный класс из программирования, конкретная реализация неприципиальна.
разумеется, если обучаемый не владеет ни одной реализацией данной зависимости, навык он получить не сможет. конечно, может оказаться, что в процессе обучения новому навыку он смог "придумать" и навык-кирпичик, но полагаться на эт мы не можем. В этом, кстати, было бы одно из важных отличий от НЛП - там обучаемому часто именно этим и приходится заниматься - одновременно обучаться нескольким вещам. Не самый эффективный путь... Кстати, вышеописанное якорение - хороший пример.
Сам же конструируемый навык, насколько я понимаю, должен быть описан именно конструктивно, это некий алгоритм.
Примерно так, если я не запутался в терминологии. Если есть принципиальные замечания - буду очень благодарен, так как в ближайшее время займусь всем этим делом вплотную, и хотелось бы получше все спланировать, избежав явных проблем...
А до ссылочек не доберусь никак - может, сначала их осилить, как думаете?
Если конструируемый навык описан как алгоритм, то он вызывает навыки-функции? Вам придется тогда сказать, что любой "навык состоит из навыков" ("цепь состоит из цепи"), а это не слишком конструктивно. Нужны какие-то базовые кирпичики, конструктивы, из которых состоят навыки. Так, описание алгоритма состоит из операторов, выражений и т.д. С другой стороны, описанный подробненько алгоритм имеет цель -- это его функция. Цепочка "взаимозависимостей" тем самым оказывается не функциональной, а конструктивной. Когда вы вызываете какую-то процедуру, то пишете ее вызов с параметрами (конструктив) и объясняете (в комментах, ибо это не конструктивно, а функционально) зачем вызывали.
Тут еще важно заметить, что с простым объектным программированием это все может быть несравнимо. Какое-нибудь аспектное программирование лучше подойдет: описываются навыки-аспекты, а при исполнении происходит weaving (где сам черт не разберет, как соединяются два навыка -- там же параллельное исполнение нескольких навыков в конечном итоге, а не последовательный "вызов" одного из другого!).
Ссылки, конечно, осилить. Разговор станет много точнее. Ибо от вас требуется онтология (например, определить понятие "зависимость" через связи с другими понятиями. Определить, какого типа связь между навыками и зависимостями навыков -- ведь навыки не только из зависимостей состоят (у вас же "зависимости" не макросы?), но и из чего другого? Какого типа связь между навыками, как она исполняется?).
Тут еще важно заметить, что с простым объектным программированием это все может быть несравнимо. Какое-нибудь аспектное программирование лучше подойдет: описываются навыки-аспекты, а при исполнении происходит weaving (где сам черт не разберет, как соединяются два навыка -- там же параллельное исполнение нескольких навыков в конечном итоге, а не последовательный "вызов" одного из другого!).
Ссылки, конечно, осилить. Разговор станет много точнее. Ибо от вас требуется онтология (например, определить понятие "зависимость" через связи с другими понятиями. Определить, какого типа связь между навыками и зависимостями навыков -- ведь навыки не только из зависимостей состоят (у вас же "зависимости" не макросы?), но и из чего другого? Какого типа связь между навыками, как она исполняется?).
не знаю в тему ли - а если в тему то в какую но я вот разрабатываю такую прикладную табличку :
Примитивы связанные с состоянием или проблемой
Состояние
описание в свободной форме
Пассивность-вовлеченность
Зона комфорта
Проблема-препятствие
Цель – рационале
Диагностич алгоритм
Пререквизиты по технике
Техника
Действия по технике
физизиология
мои кейсы
отдача\противопоказания
Дидактический материал
Методика тренинга
Алгоритмы нормализации
Тулзы
Визуализация
Документы
Специалисты
Примитивы связанные с состоянием или проблемой
Состояние
описание в свободной форме
Пассивность-вовлеченность
Зона комфорта
Проблема-препятствие
Цель – рационале
Диагностич алгоритм
Пререквизиты по технике
Техника
Действия по технике
физизиология
мои кейсы
отдача\противопоказания
Дидактический материал
Методика тренинга
Алгоритмы нормализации
Тулзы
Визуализация
Документы
Специалисты
Это очень похоже на подходы к формулированию метамодели для описания какой-то психопрактики, и в этой метамодели в кучу собраны шкалы и объекты работы, граничные условия на этих шкалах и описания действий и т.д. и т.п.
Сделайте следующее: для каждой строчки из списка укажите, какого она типа объект. Типа "пассивность -- вовлеченность" : шкала. Далее будут естественные вопросы типа "а чего это шкала?". Ну, или "диагностический алгоритм" : последовательность действий. Техника: последовательность действий. Далее вопросы типа "диагностический алгоритм -- это такая техники?".
Попробуйте, это увлекательно и познавательно. Не стесняйтесь с типами, смело их выдумывайте (хотя педанты будут говорить, что онтологические типы выдумывать нехорошо, но это будет уже следующий шаг, для него пока рано).
Можно ожидать, что у вас появятся вопросы к вашему списку, и итогом работы будет уже список немного других объектов, причём эти объекты будут типизированы и читателям этого списка станет про эти объекты понятней.
Сделайте следующее: для каждой строчки из списка укажите, какого она типа объект. Типа "пассивность -- вовлеченность" : шкала. Далее будут естественные вопросы типа "а чего это шкала?". Ну, или "диагностический алгоритм" : последовательность действий. Техника: последовательность действий. Далее вопросы типа "диагностический алгоритм -- это такая техники?".
Попробуйте, это увлекательно и познавательно. Не стесняйтесь с типами, смело их выдумывайте (хотя педанты будут говорить, что онтологические типы выдумывать нехорошо, но это будет уже следующий шаг, для него пока рано).
Можно ожидать, что у вас появятся вопросы к вашему списку, и итогом работы будет уже список немного других объектов, причём эти объекты будут типизированы и читателям этого списка станет про эти объекты понятней.
Упс пропустил я этот камент, а за это время табличка выросла до 40 полей и 130 записей... Из мета-описания Я почему-то ломанулся составлять таблицу типов связей полей, а сами типы полей не пришло в голову сравнивать. Теперь буду соображать.
Упс пропустил я этот камент, а за это время табличка выросла до 40 полей и 130 записей... Из мета-описания Я почему-то ломанулся составлять таблицу типов связей полей, а сами типы полей не пришло в голову сравнивать. Теперь буду соображать.
Я полагаю мне нужны вот такой велосипед,
"Что" определяемое через "как", или как связаны цели и предметная область.
Разработка
Гипотезы
Критерии проверки
Методики проверки
Инструменты
Ресурсы разработки
Внедрение
Методики обучения
Методические материалы
Эксплуатация
0) Ценности, принципы и миссия ч/з Этапы
1) Этапы ч/з цели
2) Цели, достижимые в определенных состояниях, через параметры свойств состояний.
3) Проблемы и задачи через функции и роли
4) Функции и роли которые нужно исполнять в контекстах, через
инструменты(дистрибутивы техник), ресурсы, права доступа,
5) Дистрибутивы техник, через набор техник.
соответствующих TCO, Пассивность/вовлеченность
6) Техники, работающие с диапазонами подмножеств объектов, свойств и методов начального состояния и приводящих к диапазону конечных состояний объектов, их
свойств и методов
7) Состояния объектов предметной области -через диапазоны параметров их свойств и
методов, выраженные в шкалах
8) Объекты предметной области - через их свойства и методы
Другой вариант
1) Компетенции
2) Исполняющие функции и роли
3) И используя дистрибуты
4) Техник
5) Работающих по изменяющим алгоритмам (загрузчик, тело алгоритма)
6) Инструментами
7) с внешними ресурсами (информация, время, деньги, человеки с компетенциями),
7) В контекстах (проектов и внешней среды)
8) Достигают целей (SMART параметры)
9) Решая задачи и преодолевая проблемы (зоны комфорта, диагностические алгоритмы)
10) Изменяя состояния (Гран условия, зоны комфорта)
11) Объектов психики
12) их методов, свойств, вовлекаемых и освобождаемых инкапсулированных ресурсов психики)
Для каждого этапа
Документация содержащая
текстовые описания, рисунки и диаграммы, шкалы, списки граничных условий, чеклисты проверки, списки наблюдаемого, аналитика работы)
"Что" определяемое через "как", или как связаны цели и предметная область.
Разработка
Гипотезы
Критерии проверки
Методики проверки
Инструменты
Ресурсы разработки
Внедрение
Методики обучения
Методические материалы
Эксплуатация
0) Ценности, принципы и миссия ч/з Этапы
1) Этапы ч/з цели
2) Цели, достижимые в определенных состояниях, через параметры свойств состояний.
3) Проблемы и задачи через функции и роли
4) Функции и роли которые нужно исполнять в контекстах, через
инструменты(дистрибутивы техник), ресурсы, права доступа,
5) Дистрибутивы техник, через набор техник.
соответствующих TCO, Пассивность/вовлеченность
6) Техники, работающие с диапазонами подмножеств объектов, свойств и методов начального состояния и приводящих к диапазону конечных состояний объектов, их
свойств и методов
7) Состояния объектов предметной области -через диапазоны параметров их свойств и
методов, выраженные в шкалах
8) Объекты предметной области - через их свойства и методы
Другой вариант
1) Компетенции
2) Исполняющие функции и роли
3) И используя дистрибуты
4) Техник
5) Работающих по изменяющим алгоритмам (загрузчик, тело алгоритма)
6) Инструментами
7) с внешними ресурсами (информация, время, деньги, человеки с компетенциями),
7) В контекстах (проектов и внешней среды)
8) Достигают целей (SMART параметры)
9) Решая задачи и преодолевая проблемы (зоны комфорта, диагностические алгоритмы)
10) Изменяя состояния (Гран условия, зоны комфорта)
11) Объектов психики
12) их методов, свойств, вовлекаемых и освобождаемых инкапсулированных ресурсов психики)
Для каждого этапа
Документация содержащая
текстовые описания, рисунки и диаграммы, шкалы, списки граничных условий, чеклисты проверки, списки наблюдаемого, аналитика работы)
А поглядите на http://semat.org/wp-content/uploads/2012/02/2012-11-01.pdf как пример стандарта для подобных описаний и попробуйте разработать kernel для этой спечифической ситуации (когда нет команды, а объекты и практики весьма специфичны) в инструменте http://www.ivarjacobson.com/Practice_Workbench_Download/ (с getting started для SEMAT users).
Это в разы облегчит разбирательство с "мета" (описание практик как таковых) и позволит сосредоточиться на содержании этих практик, т.е. на моделировании.
Это в разы облегчит разбирательство с "мета" (описание практик как таковых) и позволит сосредоточиться на содержании этих практик, т.е. на моделировании.
проще говоря почему и зачем, кто, делает что, когда, как, каким, чем, за сколько
Где почему, зачем, что, как, каким, чем относится к системе объектов и состояний предметной области
Где почему, зачем, что, как, каким, чем относится к системе объектов и состояний предметной области
Спасибо, на первый взгляд выглядит весьма релевантно. По первому впечатлению мне начинать 2012-11-01.pdf (KUALI-BEH kernal extension) со страницы 182, правильно я понял ? Это чтобы начинать не с ядра а с его применения.
Нет, вам бы всё это прочесть, чтобы понять -- а потом сделать сущности (kernel) для ОпенМеты. Ибо они будут другие, нежели чем для программной инженерии. На базе этих сущностей можно потом описать практики (репозиторий в терминах комментируемого поста), и далее описывать метод (дистрибутив в терминах комментируемого поста).
Попробуйте поглядеть презентацию http://semat.org/wp-content/uploads/2012/12/Universals_Track_Intro_Stockholm.pdf (там показан как раз путь, которым разработчики essence дошли до своего ядра, плюс применения этого ядра -- вот нам нужно для ОпенМета такое сделать).
Я сейчас как раз с этим подробно разбираюсь, через некоторое время начну предлагать терминологию на русском, но пока это будет для программной инженерии и попытки думать, каким может быть ядро для других domains (системная инженерия прежде всего, операционный менеджмент следующий). Методы ОпенМеты это как раз новый дисциплинарный домен для essence, т.е. требует разработки для него новых сущностей (kernel) на базе предложенного языка (language).
Попробуйте поглядеть презентацию http://semat.org/wp-content/uploads/2012/12/Universals_Track_Intro_Stockholm.pdf (там показан как раз путь, которым разработчики essence дошли до своего ядра, плюс применения этого ядра -- вот нам нужно для ОпенМета такое сделать).
Я сейчас как раз с этим подробно разбираюсь, через некоторое время начну предлагать терминологию на русском, но пока это будет для программной инженерии и попытки думать, каким может быть ядро для других domains (системная инженерия прежде всего, операционный менеджмент следующий). Методы ОпенМеты это как раз новый дисциплинарный домен для essence, т.е. требует разработки для него новых сущностей (kernel) на базе предложенного языка (language).