[Most Recent Entries] [Calendar View] [Friends]
Below are the 20 most recent journal entries recorded in
Anatoly Levenchuk's LiveJournal:
| Thursday, November 26th, 2009 | |||
| 12:32 pm | О выборе линейки САПР На вчерашнем заседании Русского отделения INCOSE в кулуарах произошло обсуждение того, какие критерии должны быть у хорошего САПР. Выяснилось, что любая линейка САПР должна рассматриваться по двум главным аспектам: -- поддержка всех дисциплин системной инженерии (инженерия требований, инженерия системной архитектуры и т.д.). -- поддержка всех инженерных специальностей (и хорошим примером тут являются сооружение из тяжелого бетона, нашпигованного металлом. САПР-поддержка для этого случая тем и интересна, что традиционно работа с тяжелым бетоном была весьма далека от дисциплин системной инженерии, и демонстрация одновременной поддержки дисциплин системной инженерии и работы с тяжелым бетоном служит тяжелым нагрузочным тестом для всех поставщиков САПР). В кулуарах к кулуарам мы с ![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} vvagr сформулировали следующий набор вопросов, которые нужно задавать поставщикам САПР. Ответы на эти вопросы крайне разные для разных поставщиков, а у поставщиков крайне разные для разных версий их систем:1. Поддержка специальной инженерии: все САПР хорошо поддерживают 3D-картинки или принципиальные схемы (например, P&ID). Но каждый элемент для той или иной специальной инженерии (труба, швеллер, да и сам бетон) имеют какую-то модель данных, которой для вашей специальной инженерии просто может не быть. Вопрос: -- модели данных каких элементов наличествуют в САПР "из коробки"? -- модели данных каких элементов можно купить? -- модели данных какого вида можно "настроить"? -- есть ли какие-то доступные каталоги? Есть ли готовые "настройки" для рабочих мест специальной инженерии? (трубы, HVAC, бетон, электрика...). 2. Поддержка дисциплин системной инженерии: -- поддерживается ли в рамках одного рабочего места (без дополнительной настройки) трассировка "по клику мышкой" между требованиями (заинтересованных сторон, требований к системе), логической архитектурой, физической архитектурой, имитационными моделями, рабочим проектом, закупками (практика соглашений), проектом-project? -- есть ли поддержка "оценочного дела" (для требований, архитектуры, "обоснование безопасности" и т.д. -- claims, arguments, evidence). 3. Поддержка процесса системной инженерии: -- поддерживается ли ситуационная инженерия методов? Насколько удобно описываются процессы-workflow (процесс известен и доступен "из коробки"; процесс неизвестен, ибо повторяет процесс какого-то давнего заказчика; процесс гибко настраиваем -- но без настройки ничего не работает) -- есть ли поддержка проектной/менеджерской группы описаний (контрольные точки, пересмотры и т.д.). 4. Интеграция данных жизненного цикла: -- в каждом отдельном САПР своя модель данных ("схема") и база данных для этой модели, а "общий САПР" делается длительной "настройкой" каждого отдельного САПР по схеме "каждый с каждым" для отдельных случаев. -- то же, что выше, но есть общая модель данных (общая "схема") и общая база данных (репозиторий), куда помещается оговоренная часть информации из отдельных САПР при ее "публикации" -- модель данных ("схема") для всех рабочих мест одна и та же, база данных общая. Особых проблем по интеграции между разными рабочими местами поэтому нет. -- подключение дополнительного софта по ISO 15926 5. Какие чертежи выдаются в производство и на стройку? -- выдаются не чертежи, а что-то иное (тогда как это иное может быть использовано в наших краях?) -- выдается полный комплект чертежей по ГОСТ, никаких проблем с отечественными надзорами и подрядчиками -- выдается полный комплект чертежей по каким-то иностранным стандартам, и требуются уговоры контрагентов для их использования. | ||
| Wednesday, November 25th, 2009 | |||
| 1:13 am | Роли и позиции В любом деле у вас есть роль -- какие дела вы делаете, по названию этих дел будет и ваша роль. Делаете покупки -- в этом деле вы покупатель. Учите -- тут вы учитель. Слесарите -- тогда слесарь. Когда человек застревает в какой-то одной "любимой" роли, и начинает в других ролях действовать так, как он действует в этой роли (т.е. на первом плане оказываются ценности этой роли), то это называется -- позиция. Когда он в позиции "инженер", то у него инженерные ценности и когда разрабатывает что-то, и когда воспитывает детей, и когда сидит в парламенте. Когда он в позиции "родитель", то воспитательные ценности и дома среди детей, и в рабочем коллективе, и на шумной вечеринке. Позиции можно занимать неосознанно (и тогда вами легко манипулировать: любые ваши действия легко вычислимы, ибо действуете уже не вы сами, а какая-то "схема" -- позиция и ее ценности). Реакция на указание чьей-то неосознанно занятой позиции разные: "что-то застряла роль в сознании, спасибо, что обратил внимание", или наоборот "какая такая у меня позиция? как так у меня не меняются в разных делах роли? я ведь такой спонтанный!". А можно занимать позицию осознанно: "сейчас займу вот с такой-то целью такую-то позицию" (выберу себе такую роль, и буду придерживаться ее ценностей в самых разных делах, пока не передумаю). Такой выбор позиции обычно называется "самоопределением". Когда человек скачет по разным ролям в одном деле, как зайчик, то с ним очень трудно наладить коммуникацию: внешний эффект при этом такой, что он непрерывно меняет свой набор ценностей -- что было для него ценным пять минут назад вдруг перестает быть значимым, но зато появляются какие-то новые претензии. Это можно назвать "какой гибкий человек, никто его подловить не может", а можно и "какой скользкий". Многие люди не скользкие, потому как застревание в их позиции происходит вне их сознания, просто из-за их застревания в системе ценностей того дела, которым они подолгу занимаются -- поэтому они выглядят как принципиальные люди, отстаивающие какие-то свои принципы. Если у них своего дела нет, то они могут так же бессознательно "не держать позицию", и выглядеть поэтому скользкими и беспринципными. Люди, которые осознают свои застревания в (профессиональных, социальных, семейных) ролях могут выбирать -- занимать ли им какие-либо позиции, или менять их в зависимости от ситуации. Моя позиция обычно занимается осознанно и держится подолгу: консультант, с набором ценностей и методов работы консультанта. Именно это и есть мое самоопределение. В самых разных ситуациях, когда можно занять любую роль, и самоопределиться в любой позиции, я самоопределяюсь как консультант. Хотя это не означает, что я не могу вдруг осознанно перейти в позицию организатора, или позицию исследователя. Обычно это изумляет, потому что окружающим кажется, что меня вдруг подменили: при занятии той или иной позиции ведь меняется практически все, от привычного распорядка дня до поддержки разных сторон в конфликтах. А это просто осознанная смена позиции, на время. Главное в ролях и позициях -- осознавать их. Осознавать и у себя, и у других. | ||
| Tuesday, November 24th, 2009 | |||
| 11:20 pm | Консультирование и преподавание. Образование. Я уже много раз тут писал, что считаю себя консультантом -- и тем самым имеющим прямое отношение к образованию (но не преподаванию). Попробую пояснить тут это с использованием аппарата ситуативной инженерии методов. Все образование крутится вокруг дисциплин -- самых разных методов (практик и шаблонов их применения), которые цветут и пахнут вокруг какой-то онтологии. Эти дисциплины можно условно разбить на общеметодический уровень и ситуационный уровень (http://ailev.livejournal.com/755969.ht -- общеметодический уровень описывает онтологию и методы, еще не касаясь особенностей системы, стадии ее жизненного цикла и используемого инструментария. -- ситуационный уровень требует конкретизации онтологии и методов для конкретной системы (или типа систем), ее стадии жизненного цикла (или набора стадий) и используемого инструментария. Я утверждаю, что задача преподавателя -- это научить студента общеметодическому уровню той или иной дисциплины в степени, достаточной для того, чтобы студент не растерялся и на ситуационном уровне смог выполнить адаптацию метода. Научить этому можно, например, используя имитационные системы. Преподаватель дает студенту задачи на придуманных им системах, их стадиях жизненного цикла и выбранном им инструментарии, студент их решает, применяя метод, которому его учат. Задача консультанта -- разобраться сначала с ситуацией клиента (определение: ситуация -- это когда непонятно, что делать, т.е. непонятен метод). То есть нужно понять, какова система, какова ее стадия жизненного цикла, каковы обеспечивающие системы -- в том числе инструментальное окружение. Понять, какой метод может клиенту помочь в его ситуации и найти этот метод в эээ... интернете, если метод консультанту неизвестен. Если метод не находится, то создать его самостоятельно: заняться методологией как деятельностью, для чего провести всякие исследования и затем заняться инженерией метода. Клиент дает консультанту задачу в виде своей системы, ее стадии жизненного цикла и инструментов -- и консультант готовится к ее решению путем нахождения правильного метода. И вот тут самое интересное: в этой ситуации консультант должен выполнить образовательную практику -- передать знание о методе клиенту, чтобы он сам решил свою задачу, применил метод, но не к учебной системе, а к своей системе. Идеальный случай был бы такой: консультант становится на некоторое время преподавателем, дает клиенту задания на "системах из задачника", а затем обученный клиент идет к своим системам и быстро-быстро применяет полученные знания на практике. Такого идеального случая не бывает, ибо консультанту никто не даст стать преподавателем: метод нужно создавать вместе с клиентом (потому как клиент обычно хорошо знает свою систему, стадию жизненного цикла и инструменты), попутно меняя границы системы и даже саму систему, стадии жизненного цикла и инструментальное окружение, каким-то чудесным образом (ибо домашние задания клиенту давать невозможно -- это ведь он дает консультанту задания!) передавая ему онтологию нужной дисциплины и мотивируя на применение метода на практике. То же самое образование, что и у преподавателя, но Теперь на примере системной инженерии. Если я преподаватель системной инженерии, то я читаю курсы системной инженерии примерно на том уровне общности, на каком дан стандарт ISO 15288 (т.е. "для систем любой природы, любого уровня в структуре подсистем, любого масштаба и любых стадий жизненного цикла"), или руководство по конкретной дисциплине системной инженерии (например MFESA -- описание инженерии системной архитектуре опять же "для любой системы... и т.д."). Задачки из задачника, разборы ситуаций, кейсы и так далее. Если я консультант, и понимаю, что клиенту можно помочь методами системной инженерии (некоторым -- именно что применением всей системной инженерии, некоторым -- особым вниманием к какой-то практике), то у меня не будет возможность читать им курс лекций и проводить семинарские занятия. Я должен буду уговорить обратиться к стандартам -- и сотрудники клиентов со скрипом прочтут стандарт (учебник не прочтут!). Трудные места я буду разъяснить не за флипчартом и не на учебной системе, а за третьей чашкой чая в каком-нибудь кабинете -- и вместо флипчарта будет размахивание руками, а вместо учебной системы первая попавшаяся под руку система, на которой сосредоточено внимание клиента (ничего, после третьего или четвертого объяснения на третьей или четвертой системе его бессознательное генерализует и интериоризует это трудное место, далее он и сам справится). Итого: если преподаватель, то обсуждаются системы преподавателя, а ситуационный метод остается неизвестен (передаются только общеметодические знания). Если консультант -- обсуждаются системы клиента, и по ходу дела создается ситуативный (адаптированный к ситуации) метод. Но в качестве исходного сырья и у преподавателей и у консультантов должен быть запас хороших методов, чтобы не приходилось разыскивать эээ... в интернете (а то и создавать, уж какие получатся) абсолютно все методы ввиду полной методологической безграмотности. У нас такой запас методов называется PraxOS (другой такой запас методов у других консультантов -- www.opfro.ogr). Совершенно понятно, если PraxOS будет использован преподавателями для образования. Но мы будем использовать его для консалтинга: проделывая ситуационную инженерию метода для каждого клиента. Преподавание же у нас довольно редкая и эпизодическая деятельность, скорее уж побочный продукт. Так что все эти "программы курсов" у меня в блоге нужно рассматривать не столько как планы нашей возможной преподавательской работы, сколько альтернативным способом представления методического знания ("библиотека методов"). Признаюсь честно, не так давно я узнал про ситуационную инженерию методов и начал описывать свою деятельность в этих терминах -- поэтому все время и напирал на образовательную составляющую. В любом случае, эти программы курсов/библиотеки методов служат великолепным сырьем для преподавательской работы (только к ним нужно добавить а) учебные задачки с указанием системы и стадии ее жизненного цикла и б) учебные инструменты -- используемый софт, бланки и т.д.). А теперь резко поднимем планку для преподавания, и будем обсуждать не "тренинг", а образование (слово тут тоже поменяется с "преподаватель" на "учитель"). Тут же выяснится, что у каждого ребенка есть ситуация которую преподаватель обычно игнорирует, а принимает во внимание и временами переходит в роль консультанта -- дает нужные для текущей ситуации методы (иногда даже прихватывая их не только из своего личного опыта, но и из эээ... интернета), и тогда по факту ребенок ставит задачки учителю-как-консультанту. Но дальше учитель отличается: его главная задача (в отличие от главной задачи консультанта) -- это заменить задачки ученика на те задачки, которые учитель считает правильными (вопрос о содержании образования). И вместо "давай я научу тебя хвастаться картинкой не только друзьям, а всему миру -- покажу как выложить картинку на Flickr до того, как тебя этому научит первый встречный" скорректирует изучаемую дисциплину на нужную ученику в его будущих ситуациях, а не в его текущей ситуации и одновременно заменяя реальную систему, ее стадию жизненного цикла и инструментарий из текущей ситуации ученика на учебную систему, стадию жизненного цикла и инструментарий (ибо реальных у ученика сейчас нет -- учим-то будущим ситуациям!) -- "ну что, ты еще не ловишь кайф от решения дифференциальных уравнений? Мы ведь их решаем с тобой уже пару месяцев!". Теперь можно пообсуждать, может ли переходить консультант в позицию учителя (и менять задачки, которые хочет с ним решать клиент, и тем самым менять набор методов, которым он научит в итоге клиента) -- пусть сценирование такой ситуации будет предлагаемым читателю этого постинга мыслительным упражнением. Это все, конечно, очень зыбкие материи. Мне очень радостно, что язык ситуативной инженерии методов вводит нужные различения и помогает разобраться в ситуации с преподаванием, консультированием и образованием. Мы на верном пути. | ||
| 10:04 am | 37-й год -- это тоже была модернизация.
| ||
| Monday, November 23rd, 2009 | |||
| 12:04 am | Мы не любим UML: SPEM на Description Logic, OWL и BPEL SPEM дан как UML профиль, но есть модельные реализации на -- Description Logic (http://dns2.icar.cnr.it/ruffolo/proget -- OWL/SWRL (http://sunsite.informatik.rwth-aachen.d -- исполнимый (eXecutable) xSPEM 2, используем ATL + PetriNet --> BPEL (http://hal.archives-ouvertes.fr/docs/0 | ||
| Sunday, November 22nd, 2009 | |||
| 9:37 pm | САПРы и ситуативная инженерия методов Мне кажется, что я уже неоднократно описывал эту архитектуру (см. хотя бы http://ailev.livejournal.com/757999.htm Сегодняшние САПР (системы автоматизации ПPроектирования, ПРрограммирования, ПPроизводства, а также я сюда включаю EAM, ERP и так все корпоративные IT-системы) представляют собой распределенный набор редакторов DSL (workbenches, IDE, модули, обработчики), надстроенных над (возможно, распределенной) базой данных, хранящей модель разрабатываемой и/или изготавливаемой системы. В некоторых САПР (например, Dassault Systemes V6, основанной на хранилище данных MatrixOne) эти модули/обработчики/редакторы_спецязыков (описания геометрии CATIA, описания коллаборации DELMIA и т.д.) основаны на SOA-архитектуре. Подключение новых обработчиков/редакторов_верстаков по договоренности разработчиков всех этих систем происходит по ISO 15926, причем интерфейс тут вебсервисов (RDF и triple store, запросы SPARQL) -- это единственный на сегодня вариант полноценного обмена сложными данными, который позволяет передать все необходимые данные (геометрию, расчетные модели, описание workflow и т.д.) между САПР, а не только их часть. Возьмем эту архитектуру за прототип. То, что я все время предлагаю -- так это: 1. в явном виде иметь описание этой SOA-архитектуры. Ибо сегодня обеспечение совместной работы огромного (порядка 200) модулей современных САПР, в которых отнюдь не все модули относятся к одному поставщику, представляет собой искусство, а не инженерию. Нужно иметь отдельный артефакт: описание сервис-ориентированной архитектуры компонентов САПР, связанных друг с другом. Это описание, понятное дело, должно храниться в общей модели и использоваться для целей конфигурирования. Для этой цели нужно иметь набор DSL для описания SOA и редактор (IDE) для редактирования этого описания. Как происходит потом использование этого описания для целей конфигурирования всей САПР-инфраструктуры -- отдельная история (но обычно САПР умеют использовать описания, данные в терминах их собственной модели). Этот редактор (IDE) для группы описаний (view) SOA можно включить в состав модулей САПР точно так же, как включается редактор P&ID для группы описаний гидравлики в трубопроводах, редактор 3D (геометрии) для группы описаний формы деталей и их пространственной сборки, редактор описания проекта ("модуль управления проектом") для группы описаний разбиения работ и их ресурсного обеспечения, редактор требований ("модуль управления требованиями") для группы описания требований и т.д. Согласно практики интегрирования данных жизненного цикла, это "включение в состав модулей" достигается путем а) учета SOA-архитектуры общей IT-системы (модулей САПР различных поставщиков, хранилищ данных, модулей EAM и т.д.) b) интегрирования данных жизненного цикла с данными, использующимися другими модулями (понимаемыми в этой группе описаний либо как сервисы, либо как обращающимися к нашему IDE как сервису) согласно стандарту ISO 15926 2. в явном виде нужно иметь описание процесса коллективной работы (как коллектива программ-модулей, так и коллектива людей-в-ролях) с этим комплексом САПР. Для этого нужно применить ситуативную инженерию методов. Это означает, что существует некоторый набор методов (коллаборативной) работы людей с модулями САПР, являющийся конкретизацией какого-то варианта описания жизненного цикла и его практик (т.е. варианта "методологии") для данной а) системы, б) стадии жизненного цикла, в) набора используемых САПР. Это традиционная постановка задачи ситуативной инженерии методов, и тут существуют развитые метамодели для этого описания (например, SPEM, ISO 24744, ADOM и т.д.). Нужно иметь качественный редактор (IDE)для набора DSL, реализующего метамодель описания методов и поддерживающего ситуационную инженерию метода -- все эти адаптированные к ситуации "руководства", описания ролей и назначения их обязанностей, выделение отдельных методов работы и прописывание их места в развертке во времени, и т.д. и т.п., что традиционно входит в группу описаний (view) ситуационной инженерии методов. Этот редактор (IDE) для ситуативной инженерии методов включается в общий набор сервисов различных модулей IT-системы точно так же, как и редактор (IDE) для SOA -- с использованием интеграции данных по ISO 15926. Тем самым у нас возникает ситуация, когда мы можем использовать ситуативную инженерию методов для того, чтобы наладить процесс работы с развернутым комплексом САПР. Сегодня эта задача описывается как "разработка workflow для данной проектной организации". Существуют отдельно редакторы workflow, которые крайне специфичны для разных САПР и никак не связаны с набором руководств, которым должны следовать люди. Существуют различные средства для инженерии методов (та же Business Studio из популярных в силу своей простоты). Существуют средства управления проектами, поддерживающими представление жизненного цикла (а не процессное, как для workflow). И никакого шанса на интеграцию всех этих средств. Шанс появляется, если мы используем а) понимание, что для работы со всеми этими средствами нам нужно множество групп описаний жизненного цикла (методов, самого жизненного цикла, используемой инфраструктуры-сервисов и т.д.) б) эти группы описаний должны быть подготовлены редакторами (IDE) в общей среде моделирования в) общность среды моделирования может быть обеспечена за счет использования SOA-архитектуры и интеграции данных с внешней библиотекой справочных данных, т.е. подхода ISO 15926. Я понимаю, что все эти вопросы обсуждаются в рамках Enterprise Architecture, но для меня эта линия рассуждения пока не важна -- не будем сейчас умножать число сущностей без надобностей, а про EA напишем когда-нибудь отдельный пост. | ||
| 4:17 pm | Онтократия в установлении методов разработки Дискурсивное устройство разработки софта (The Discursive Constitution of Software Development -- http://www.lse.ac.uk/collections/inform Ключевой термин: символическая сила (symbolic power), а иногда и символическое принуждение (symbolic violence) -- сила (или насилие) в изменении видения мира, без экономической или физической силы, просто через принятие и сотрудничество с отдельными людьми. В таком залоге ("онтократия") это часто обсуждается СМД-методологами. В диссертации показываются, как эти "онтократические" идеи реализуются на примере установления стандартов методов разработки софта. | ||
| 12:07 am | ISO 15926-2 в открытом доступе На всякий случай напомню: upper ontology (модель данных, схема данных, life cycle integration schema, мета-метамодель) стандарта ISO 15926-2 лежит в открытом доступе: http://www.tc184-sc4.org/wg3ndocs/wg3n1 В самой этой части стандарта больше ничего и нету: схема задана в языке EXPRESS (стандартизован в стандарте STEP, а именно ISO 10303-11, и этому языку готовят второе рождение: http://www.nist.gov/mel/msid/dpg/eesm.c Эта онтология (модель данных, схема) представима: -- в языке логики первого порядка (доказывается эквивалентность с представлением в языке EXPRESS), это декларируется в части ISO 15926-7. Тем самым ISO 15926 становится факт-ориентированным языком. -- в языке OWL (с некоторой потерей семантики), это представление задается в части ISO 15926-8 -- в табличном виде Gellish Table, это представление будет задаваться в части ISO 15926-11 Модель данных ISO 15926-2 -- это мета-метамодель, уровень 3 модели, если определять ее в терминах OMG MDA. Тут можно поспорить, представляет ли она аналог OMG MDA UML 2 или MOF (язык на котором написан UML 2), но я делаю наглое предположение (в постинге про универсальный моделер http://ailev.livejournal.com/757999.htm Если интересно про ISO 15926 дальше, то введение в проблему -- https://www.posccaesar.org/wiki/ISO1592 Интересные ссылки есть и на https://www.posccaesar.org/wiki/ISO1592 Ссылки к онлайновому доступу ко всей онтологической надстройке (библиотека справочных данных на примерно 50 тыс. понятий): https://www.posccaesar.org/wiki/Rds | ||
| Saturday, November 21st, 2009 | |||
| 8:32 pm | Курс по инженерии системной архитектуры Месяц назад я писал наброски программы короткого курса системной инженерии (http://ailev.livejournal.com/746511.ht Необходимость отдельного курса по инженерии системной архитектуры: ISO 15288 посвящает меньше двух страниц "архитектурному проектированию", а руководство по системной инженерии INCOSE посвящает 31 страницу обзору "функционального анализа/разнесения" и "синтезу системной архитектуры". Это очень мало. Так, руководство "Подход к методам инженерии системной архитектуры" (MFESA) даже без уточнений для систем разной природы, разных жизненных циклов и разных используемых архитектурных инструментов -- это 482 страницы, руководство «Метод для оценки качества программоемких системных архитектур» (QUASAR)-- 267 страниц. 1. Инженерия системной архитектуры в контексте других практик системной инженерии. -- практика архитектурного проектирования и дисциплина инженерии системной архитектуры -- «горбатая диаграмма» системной инженерии и место инженерии системной архитектуры в дисциплинах системной инженерии -- разделение инженерии системной архитектуры и инженерии требований, рабочего проектирования -- системные архитекторы, архитектурные коллективы -- невозвможность единого подхода к инженерии системной архитектуры. Адаптация стандартов. -- стандарты инженерии системной архитектуры (ISO 15288, ISO 42010, MFESA, QUASAR) -- методические принципы инженерии системной архитектуры (поддержка ситуационной инженерии методов; масштабируемость; эволюция архитектуры; качество обеспечивающих систем; все типы архитектурных компонент; компонент-ориентированная разработка; хорошо определенные понятия и терминология; архитектуры и их описания как ценные ресурсы; как архитектурные группы описаний, так и области внимания; полнота архитектурных групп описаний; полнота конкретных архитектурных методов; командная работа; независимость оценки архитектуры; анализ влияния перед изменениями архитектуры) 2. Архитектурная онтология -- системная архитектура -- архитектурные структуры -- архитектурные стили, шаблоны и механизмы -- архитектурные основания и интересы -- архитектурные представления (representations) -- архитектурные модели, группы описаний и области внимания (focus area) -- архитектурные продукты работы -- архитектурные эскизы (visions) и эскизные компоненты 2. Архитектурные мероприятия -- планирование и обеспечение ресурсами работ по архитектурной инженерии -- выявление архитектурных направляющих (drivers) -- создание первых версий наиболее важных архитектурных моделей -- выявления возможности переиспользования архитектурных элементов -- создание вариантов архитектурных концепций (visions) -- анализ переиспользуемых компонентов и их источников -- завершение архитектуры и ее представлений -- оценка и приемка архитектуры -- сопровождение архитектуры и ее представлений 4. Архитектурный инструментарий -- архитектурные моделеры -- архитектурное проектирование с использованием современных САПР -- инструменты для DSM В принципе, это все основано на MFESA (полная книжка http://www.freebookspot.in/Books-Me | ||
| 8:11 pm | Универсальный моделер (IDE). Универсальный компилятор (IDE). Во первых строках моего поста прошу пардону за непонятность у всех проходящих мимо: каждый термин тут требует для них многочисленных разъяснений (и даже ссылки на первоисточники и другие мои постинги я повторять по десятому разу не буду, в том числе и потому, что сейчас у Яндекса блоговый поиск опять сурово сбоит и найти сегодня ничего нельзя, но я исхитрился и нашел через интерфейс livejournal.ru -- вот начало разговора про универсальный моделер в приложении к оргмоделированию http://ailev.livejournal.com/701018.htm В свободные (да и в рабочие тоже -- работа у меня такая) минуты я часто размышляю об "универсальном моделере". Вот его основные черты: -- у него есть хранилище данных, больше всего похожее на MatrixOne от Dassault Systemes (базовая онтология на 20тыс. класссов, поддержка многопользовательской работы и SOA на макушке -- чтобы обепечивать "программирование-в-большом") -- но в качестве схемы используется ISO 15926 inside (что странно, ибо RDL-то outside), чтобы исключить постоянный мэппинг для внешних соединений. Сам ISO 15926 при этом контролируется на масштабируемость (выразительность) своих протошаблонов, шаблонов и OIM; и тут нужно еще понять, как делать "диалекты" ISO 15926 -- ведь наверняка программирование такой системы будет включать в себя крутые отползания от стандарта, хотя бы для исправления ошибок или крутого рефакторинга при нахождении нужной масштабируемости. -- само программирование идет в два приёма, и выполняется в подходе language workbenches: 1. инструментальное -- представляет собой создание динамических редакторов-исполнителей для целевых моделей, выражаемых в их DSL. Вспоминаем language workbenches, но компилируем не только из какого-нибудь UML/MOF в исполняемый на компьютере код, но и из 3D-геометрического представления в код для станка с ЧПУ ("субтрактивное производство") или 3D-принтера ("аддитивное производство"), а лет через пять еще нужно будет выводить описание 3D-компоновки для сборочного робота. 2. целевое -- собственно создание моделей. Думать при этом можно про "модули" (workbenches) от Dassault Systemes V6 (но при этом не стоит путать тамошние workbenches с language workbench: то, что в DS V6 называется workbench является лишь одним из DSL+IDE в language workbenches). -- само программирование language workbench при этом устроено на COLA (vpri.org), а главными из тамошних идей считаем мультипарадигмальность и "масштабируемость идей". Код получается крошечным и обозримым. -- все это не менее красиво виртуально-трехмерно чем "тарелочки" у Dassault Systemes V6. Но при этом поддерживается реальное коллаборативное время -- например, как в Croquet с его алгоритмом TeaTime и САПР, засунутым в виртуальный мир. -- все это, конечно, свободный софт. Конечно, при этом нужно все время размышлять на давно задаваемые мной вопросы про парадигмы -- языковую или модельную. И понимать, занимаемся мы программированием или моделированием -- сейчас эти две метафоры/парадигмы сливаются (я помню, что совсем недавно писал об этом, но Яндекс надежно скрывает ссылку). На закуску этого невнятного постинга я помещу рекламу Markus Voelter (http://www.voelter.de/), который все активнее и активнее пишет на те же темы, что и я -- про фактическое слияние моделирования и программирования (правда, все время сваливаясь в частный случай компиляции DSL в исполняемый код языков программирования. Меня же волновала бы компиляция более общего вида, например shape language в модель на языке ISO 15926 в рамках машиностроительного модуля САПР, а затем в программу для станка с ЧПУ, чтобы заниматься далее порождающим производством). Тем не менее, вот его взгляд Markus Voelter на то, как языковая и модельная парадигма сливаются (в тех же language workbenches): И еще нужно глядеть на его презентацию о том, что язык и архитектура -- это про одно и то же: http://www.slideshare.net/schogglad/arc А вот свежайшая презентация Alfonso Pierantonio про model-driven engineering (model-driven development из которого только маленькая часть) в части эволюции-в-малом (эволюции прикладной модели) и эволюции-в-большом (эволюции метамодели): Эта презентация намекает, что возможно менять метамодель так, чтобы при этом отслеживать сохранение целостности уже созданных моделей. Пока это rocket science, но через пять лет это будет сидеть где-нибудь глубоко внутри модельного-программного инструментария. Ecore, KM3, MOF в моей голове полностью соответствуют ISO 15926-2, а UML и прочие "надстройки" -- это уже протошаблоны ISO 15926-2. "Стереотипы" -- это OIM. Разница с текущими моделерами в детальности моделирования (развитости онтологии ISO 15926-2) и наличии организационного механизма накопления экспертного знания в виде RDL. Все, что я говорю -- это "мужики, MDE и MBSE -- это одно и то же. Только в первом случае у вас команды исполняет процессор, а во втором случае -- люди и станки с ЧПУ". И нужно просто повторно использовать идеи, чтобы не распыляться. В любом случае, компьютерная революция начнется уже совсем скоро. Почему я этим всем занимаюсь? Я бы с удовольствием воспользовался готовым универсальным моделером, чтобы делать в нем DSL PraxOS в таких domain как системная инженерия, организационное управление и ситуационная инженерия методов. А дальше бы я применял эти DSL на практике, получал опыт, и выпускал бы новые версии этих языков. Но универсального моделера нетути, и приходится думать, сколько ждать до того момента, когда он появится "сам собой", или примериваться к тому, чтобы затеять его разработку. | ||
| Friday, November 20th, 2009 | |||
| 11:28 pm | Запуск LHC -- прямо сейчас Вот тут приводятся ссылки на прямую трансляцию запуска Большого Адронного Коллайдера, этот запуск происходит прямо сейчас: http://igorivanov.blogspot.com/2009/1 Наконец-то у нас в режиме реального времени показывают не войну, а науку: данные прямо с приборов, обновление каждые 10 секунд. Разве что кнопки анонимусам не дают нажимать, только смотреть можно. | ||
| 11:17 pm | О курсе "Введение в системную инженерию" Прочитал сегодня "в прямом эфире" два с половиной часа чернового материала по введению в системную инженерию -- и выложил это видео (http://ailev.livejournal.com/757223.ht Из многочисленных тем, которые должны были бы войти в это введение, поместились в очень кратком варианте только темы: -- зачем нужна системная инженерия, -- разные определения системной инженерии, -- связь системной инженерии и системного мышления, -- понятие системы (по факту, только в структурном подходе, без процессного), -- понятие о практиках и дисциплинах системной инженерии Те немногие слайды, которые я хотел показать -- так и не показал, обошелся рисованием фломастером на флип-чарте. Так что три четверти площади видеокадра оказались по факту не задействованными 95% времени рассказа. Слайды для этой тематики я подготовлю попозже, и в штатном режиме этот курс пойдет со слайдами. Сегодня же была черновая лекционная сессия -- зато доступная для всех (я просто счел, что уже давно не было материалов начального уровня для тех, кто совсем с системной инженерией не знаком, но хотел бы о ней что-то узнать. Форма жизненного цикла для этих вводных материалов по системной инженерии была выбрана эволюционная (когда выпускаются версии системы, функциональность которых наращивается, причем в момент выхода начальной версии функциональность конечной версии неизвестна -- сначала видео, потом слайды, потом еще могут появиться тексты). Версия 0.1 в виде сегодняшних видео как раз и вышла. Рассказ сегодня ведется уже не в терминах годичной давности "Понятийного минимума подхода системной инженерии к управлению жизненным циклом", когда мы только-только учились говорить о системной инженерии по-русски. За последние полгода мы и лексику более-менее обкатали, и существенно доработали предъявление системной инженерии как дисциплины (набора практик/методов, объединенных общей онтологией). В начальном курсе нужно нужно будет еще затронуть темы, которые в сегодняшний кусочек рассказа не вошли: -- описания и модели, множественности описаний и моделирования -- группы практик системной инженерии -- жизненный цикл и его примеры -- горбатая диаграмма (развертка практик во времени жизненного цикла) -- краткая характеристика основных дисциплин (на примере рассказа о типичном жизненном цикле, с кратким раскрытием онтологии соответствующих дисциплин: онтология инженерии требований, онтология инженерии системной архитектуры, онтология управления конфигурацией и т.д.) -- менеджеры и инженеры: пересмотры выделения ресурсов и оценочное дело -- стандартизация и ситуативная инженерия методов. ISO 15288, ISO 29148, MFESA. -- моделеориентированная системная инженерия и современные САПР как основа для нового поколения практик системной инженерии. -- системы систем ... Этот курс должен как-то затронуть основные мыслительные практики системной инженерии ("повороты мозга", метанойи), дать основную терминологию системной инженерии и какой-общий контекст для углубленного рассказа. Если всё введение в системную инженерию читать примерно в том же темпе, что и сегодня, то это могло бы занять 8-10 лекционных часов при наличии правильных слайдов -- плюс пока непонятное число часов практических занятий. Понятно, что такой курс не должен быть чисто лекционным: ожидаются коллективные обсуждения, создание и предъявление каких-то учебных артефактов (ага, конструктивизм и конструкционизм), решение задач на время и прочие отклонения от классно-урочной системы. После этого вводного курса можно было бы давать более глубокие курсы по традиционным дисциплинам системной инженерии, в первую очередь: -- инженерия требований -- инженерия системной архитектуры [я как раз сейчас готовлю краткое введение в этот курс -- первый раз планирую читать в середине декабря] -- квалификация (валидация и верификация) -- ситуационная инженерия методов -- управление жизненным циклом -- управление сведениями и интеграция данных -- управление конфигурацией -- управление проектами ... | ||
| 11:26 am | Введение в системную инженерию Тут была прямая трансляция моей лекции "Введение в системную инженерию" через ustream.tv Успели затронуть начальные темы введения в системную инженерию: разные определения системной инженерии, зачем нужна системная инженерия, связь системной инженерии и системного мышления, понятие системы, понятие о практиках и дисциплинах системной инженерии. Трансляция шла 2 часа 34 минуты 40 секунд, интернетзрителей было 50, насмотрели они 5 дней 7 часов 25 минут (что дает среднее время одного просмотра больше, чем время трансляции -- вопросы не ко мне, а к статистике Ustream.tv). Для тех, кто хочет выкачать оригинальное видео одним файлом (222Mb) -- это можно сделать тут: http://narod.ru/disk/15241416000/SE_int | ||
| Thursday, November 19th, 2009 | |||
| 10:15 pm | Ринет сегодня поменял smtp сервер Если у кого сегодня траблы с отправкой писем в сетке Ринета, то это у них поменялся SMPT сервер на smtp.rinet.ru -- и даже не все операторы техподдержки еще об этом знают. Так что меняйте настройки своих почтовых клиентов, и у вас все с почтой наладится. | ||
| 12:47 am | Свежие чудеса света У моего дитенки появилась карандучка, или ручкандаш -- не знаю, как назвать. Шариковая ручка, у которой в колпачок вделана резинка. И работает эта ручка как карандаш: абсолютно черный след от шарика можно легко стереть резинкой. В моем рейтинге сегодняшних чудес света это первое место, ибо оно уже у меня дома. Второе место -- это моделирование мозга кошки -- http://www.modha.org/C2S2/2009/1118 Третье место -- вчера Гиперион обнародовал свой дизайн 25МВт реактора, он свинцово-висмутовый и в зависимости от режима работает от 5 до 10 лет без перезарядки. Их цель: снизить цену вплоть до $2000 за киловатт установленной мощности (10 центов за киловатт-час независимо от места установки в мире), и это реально, поскольку размеры там маленькие (полтора метра ширины на два с половиной метра высоты). Выход на формальный процесс лицензирования в NRC в 2010 году, самое позднее – в начале 2011 года. Презентация проекта: http://djysrv.googlepages.com/HyperionP Четвертое место -- это начало работ по выводу на рынок термоэлектронных устройств (то есть в которых внутре нет никакой турбинки и прочих поршней и движущихся частей) с эффективностью в 40% от цикла Карно -- http://web.mit.edu/newsoffice/2009/ther | ||
| Wednesday, November 18th, 2009 | |||
| 12:05 am | Ктулху опасносте! А я и не знал, что в нашем гимне помянут Ктулху: в новом варианте текста там стоит "хранимая Богом родная земля" (http://www.gov.ru/main/symbols/gsrf | ||
| Tuesday, November 17th, 2009 | |||
| 10:19 pm | Стек методов системной инженерии Стек методов системной инженерии необъятен, и требуется разделение труда и сбор довольно разношерстной команды, чтобы получить в одном проекте необходимый набор компетенций. Если за исходную точку брать ISO 15288 "Системная и программная инженерия -- практики жизненного цикла системы", то сразу обнаруживается его абсолютная неконкретность и абстрактность, и в то же время редкое свойство масштабируемости в силу рекурсивного (к разным уровням подсистем) и итеративного (в разные моменты времени) применения. Абстрактность является и самым сильным местом этого стандарта, и самым слабым -- например, стандарт предписывает вам заниматься архитектурным проектированием (а не каким-то другим: от вас требуют использовать логическую и физическую архитектуру), но совершенно не объясняет, как именно вы должны эту архитектуру получить. Можно использовать ISO 15288 непосредственно: любое дело делать "как придется", но сверяться с ISO 15288 -- чтобы чего-нибудь не забыть сверхважное. ISO 15288 в этом плане представляет собой метод (практику) системной инженерии, но очень нечетко определяет содержание входящих подметодов/практик/дисциплин -- не говоря уже о том, что крайне мало содержит указаний на то, как связаны эти составляющие его практики между собой и как они должны применяться в развертке во времени жизненного цикла. Это означает, что непосредственное использование ISO 15288 практически бесполезно -- у вас указано, что для борща обязательно использовать овощи и жидкость, но вот какие именно овощи, и вода эта жидкость или бульон -- это предполагается, что вы уже знаете. Пользуясь этим стандартом, вы не получите сухой борщ, или бульон с яйцом -- требование воды и овощей вас от этого избавит. Но вот упаренную гороховую кашу вы вполне получите, в полном соответствии со стандартом. Нужно конкретизировать. Можно использовать двух, трех или даже трехуровнево (описано в приложении A из ISO 19760), причем варьируя набор уточняющих стандартов для каждой стадии жизненного цикла: -- на первом уровне сам ISO 15288 -- на втором уровне детали уровня мероприятий ISO 15288 из какого-то другого, более подробного стандарта -- на третьем уровне детали уровня дел из какого-то еще более подробного стандарта. Я предлагаю использовать ISO 15288 в рамках ситуационной инженерии методов: I. Общеметодический уровень: для всех систем и всех стадий жизненного цикла 1. ISO 15288, как набор практик (чтобы не забыть о том, каков более-менее полный набор практик системной инженерии, и чтобы получить основу для совмещения между собой всех остальных практик, а также задать общий язык). 2. общеметодические стандарты, раскрывающие выполнение отдельных практик. Например, MFESA для архитектурного проектирования. ICM для описания жизненного цикла. P2M для проектного управления. Моделеориентированная инженерия требований (model-driven requirements engineering), которая второго поколения, а не первого. Основная мысль этих стандартов в том, что не бывает "универсального архитектурного метода", или "универсального жизненного цикла" -- в каждом конкретном случае нам нужно подгонять набор выполняемых инженерных деятельностей под условия конкретной ситуации: типа системы, жизненного цикла, инструментальной инфраструктуры. С другой стороны -- как именно подгонять под конкретные условия, и какой из многочисленных понятийных аппаратов конкретной предметной области задействовать, на этом уровне раскрывается в форме, специально подготовленной к уточнению по ситуации. Тут еще вполне применим термин "практика", или "дисциплина" как тематический набор практик (дисциплина инженерии требований, практика архитектурного проектирования и т.д.). MFESA явно говорит о best practices в своем составе. Это как раз уровень, на котором хотелось бы удержать PraxOS. II. Ситуационный уровень: для отдельных типов систем и отдельных стадий жизненного цикла -- учет природы целевой системы (так, для разработки архитектуры организации, железки и софта нужны разные архитектурные методы, хотя в любом случае это архитектурные методы, а не методы инженерии требований или методы проектной работы -- предметная специфичность удерживается) -- учет стадии жизненного цикла (так, архитектурная работа на стадии разработки и архитектурная работа на стадии техобслуживания и ремонтов требует использования разных методов, постановки совершенно разных целей) -- привязка к конкретным приемам работы и связанной с ними инструментальной инфраструктуре (методы и инструменты неразделимы). Например, уточнить требования MFESA для DSM -- design structure matrix, чтобы поднять модульность. И обязательно привязаться к инструменту (как выполнять DSM с использованием имеющегося софта). Тут уже более приложимо слово "метод", чем практика. Хотя это все игра словами: текущее словоупотребление еще совершенно не устоялось в ситуативной (или ситуационной? LingvoScience выдает оба слова через запятую как переводы situational) инженерии методов. Общеметодическая часть -- это требование быть хоть как-то образованным системным инженером/менеджером (например, отличать архитектурную деятельность и деятельность по инженерии требований, а также владеть специфической терминологией и понимать место этих деятельностей в общем контексте всех необходимых работ. Или понимать основные принципы управления информацией. И все это в объеме, достаточном для поддержания профессионального разговора со специалистами в этих узких областях). Это огромная учебная проблема: минимальные прикидки показывают, что по каждой из 25 основных практик человек должен освоить (то есть хотя бы поддержать разговор) сто страниц плотно набитого идеями текста -- итого 2500 страниц. Я делю сейчас людей на три категории: -- не в состоянии поддержать разговор о методе (постоянно переспрашивает термины, не понимает смысла сказанного) -- поддерживает разговор о методе ("читал" -- т.е. понимает смысл сказанного и знает слова, но путается в предмете при разборе конкретных ситуаций) -- разбирается в методе (в достаточной мере, чтобы использовать метод в текущей работе) Я считаю, что уровень "поддержки разговора" -- это как раз и есть общеметодическая часть. 2500 страниц вдумчивого чтения хорошо структурированной литературы (учебников, стандартов, "наборов методов"), и вы будете поддерживать разговор о системной инженерии. А потом заранее неизвестное число страниц заранее непонятной литературы, участия в непонятном числе проектов и неструктурированного общения, чтобы перейти на уровень "разбирается". Как я понимаю, ситуативная инженерия методов пытается отвечать как раз на этот вопрос: как минимизировать затраты ума, нервов и денег на перетаскивание структурированного знанияе общеметодического уровня на более низкий ситуационный уровень, не потеряв его полноты и структуры. Другими словами, как из "поддерживающих разговор о методе" сделать "разбирающихся в методе". Про всего два уровня абстракции я, конечно, сверхобобщил. Все много, много хуже. Пока же ситуация такова, что даже при двухуровневой структуре я забежал далеко-далеко вперед: если вокруг только те, кто не в состоянии поддержать разговор о методе, то ситуативную инженерию методов применять еще слишком рано: "Какое такое архитектурное проектирование, которое мы тут должны адаптировать к ситуации нашей целевой системы, этапа жизненного цикла проекта и наличествующих инструментов?! Вы о чем? Садитесь, и проектируйте -- если не понимаете, как, поглядите в ГОСТЫ 1953 года издания, или посмотрите, как работают наши пенсионеры"... Как это все отмоделировать хотя бы в том же EPF Composer, это отдельная задача: для ситуативного моделирования методов это хороший инструмент, но для общеметодической работы не слишком. Впрочем, тут и специальные LMS тоже могут оказаться бесполезными -- но мне они с инструментарием ситуативной инженерии методов представляются родственниками. В частности, в LMS популярна метафора музыкального сервиса -- альбомы, жанры, треки, плей-листы. Это очень напоминает то, что делает EPF Composer: у вас есть 1100 исходных треков (это не с потолка, это число фрагментов методов в репозитории методов http://ofpro.org), вам нужно сделать плейлист этих методов для вашего проекта, причем как диджею (синхронизируя треки друг с другом, сочиняя и тут же записывая собственные треки прямо в плейлист, подпевая солистам и непрерывно меняя плейлист для учета настроения тех, кто потом будет его играть-слушать). | ||
| 8:09 pm | Стек технологий ISO 15926 Важно понимать, что одного человека/фирмы, обеспечивающего все необходимые компетенции, нет -- и тем не менее весь этот стек целостен. 1. Системные инженеры-исследователи (academic level systems engineers, как их ласково называют на Западе), обеспечивающие протошаблоны ISO 15926-7 -- строятся поверх начального набора из 201 концепта и их ожидается около 300 штук. Именно эти люди обсуждают выражение модели данных ISO 15926 в языках EXPRESS, UML, OWL, RDF, таблицах (как в Gellish) и эквивалентность этих выражений. Именно эти люди обеспечивают строгие формализмы (типа логики первого порядка). 2. Поставщики системного софта, которые "упаковывают" работу инженеров-исследователей в форму, готовую для организации отображения данных. Думайте о софте типа iRing с разными модификациями, облегчающими интеграцию в разный прикладной софт. Этот софт сразу работает в терминах 300 протошаблонов, и для работы с ним не нужно "вышивать" в терминах исходных 201 концепта. Этот софт с самого начала все понимает про RDL, про фасады -- только он ничего не знает про предметную область, с которой нужно работать. Это системный софт. 3. Синеворотничковые инженеры-философы (mappers), которые понимают их предметные области, хорошо представляют, как устроена глобальная библиотека справочных данных (RDL) и умеют пользоваться 300 шаблонами и системным софтом из предыдущего пункта. Эти люди умеют совмещать разные модели мира, опираясь на онтологию ISO 15926. Скорее всего, эти люди работают в каких-то "брокерах данных", обслуживая мелких поставщиков оборудования на предмет выставления их данных во внешний мир в форматах ISO 15926, либо занимаются "промышленной метафизикой" во внутрифирменных подразделениях, интегрирующих данные крупных организаций. Они будут делать более сложные шаблоны. 4. Поставщики готового софта, использующие уже готовые справочные данные для их предметных областей, и разрабатывающие интерактивные (хорошая была опечатка по Фрейду: интеграктивные) среды для разных предметных областей -- думайте о поставщиках современных САПР, EPR и EAM suits и т.д.. Внешний интерфейс этих систем как раз и будет фасадом ISO 15926, семантическими веб-сервисами. Эти программисты оживят модели данных, которые сделаны промышленными метафизиками. 5. Инженеры, которые проектируют, конструируют, сооружают, ремонтируют свои целевые системы, используя готовый прикладной софт. Инженеры эти даже знать не будут, что там где-то внутри работает ISO 15926 и его библиотеки справочных данных, будут использовать шаблоны. Все, что нужно сделать, это -- понять, что это неизбежно и мейнстрим -- самоопределиться, в каком месте стека тебе работать -- начинать работать в соответствии с этим самоопределением А пока потихоньку сколачиваем организационную структуру, которая будет пытаться удерживать целостность этого технологического стека в применении к русскоязычному миру. Членами там будут юридические лица. И если вы знаете тех, кому было бы интересно создание национальной библиотеки справочных данных в формате ISO 15926, пусть напишут мне письмо. | ||
| 7:24 pm | Трехосевой гироскоп на MEMS Дешевые MEMS (microelectromechanical systems) есть в каждом сматрфоне -- это датчики движения, акселерометры. Теперь к трехосевым микроакселерометрам прибавились трехосевые микрогироскопы: движение какой-нибудь железки с ними может быть отслежено не только с точки зрения направления движения, но и с точки зрения вращений. Высококачественный гироскоп за $3.6 за штучку в партии от тысячи штук -- http://www.st.com/stonline/stappl/cms/p В сочетании трехосевым акселерометром этот трехосевой гироскоп позволяет полностью измерять движение. Нет слов, как это круто. Нет, я не имею ввиду установку этих гироскопов в любительские ракеты и самолеты. И без них применений хватит, в любом телефоне (который уже давно не только телефон). Подобных акселерометров, кстати, STMicroelectronics выпустило уже 600млн. штук. Гироскопы наверняка ждет не менее счастливая количественная судьба. Новые органы чувств выпускают на заводах. | ||
| 6:22 pm | Волновая игрушка Google Wave -- мощнейшая игрушка, с которой никто не знает, что делать. Кто туда хотел попасть, уже все попали (сразу оговорюсь, возможности давать инвайты у меня нет, когда появится такая возможность -- не знаю). Теперь эти все приличные люди добавляют меня (там я получаюсь даже более торжественный: не ailev, как тут, а полностью -- ailevenchuk) в разные волны с общим содержанием "и что с этими волнами делать кроме совместной работы по редактированию текста"?! И все внимательно смотрят: кто что придумает, кто вложится в программирование, кто вложится в контент, и что вообще там можно. А можно ой-ой-ой сколько, если не жалко времени. Интернет начала времен, огромные перспективы. Платформа, каких поискать. Интернет нового поколения, как когда-то стал WWW внутри интернета. Мегааськовый мультитредовый форум с посылкой писем. Карму скоро прикрутят. Пока там главная проблема -- отсутствие стен. В этом доме все стеклянное, очень легко строить, очень легко ломать, все просматривается насквозь. Поэтому я там буду пока наблюдать (относиться к этому нужно так: "поставил себе почту, поставил себе аську, завел логин на форум и буду их время от времени проверять на наличие новых мне лично сообщений", а писать пока буду продолжать тут, в ЖЖ). Наблюдать за волнами можно вот таким плагином: https://addons.mozilla.org/en-US/firefo Для себя я решил, что Wave у меня в голове пока имеет такой же статус "платформы" и "места", как ЖЖ, а дальше поглядим, что будет. Вот Second Life таким "местом" не стала, хотя надежды и были велики. FrendFeed сразу было понятно, что коротковат форматом. Я вспоминаю те времена, когда главным предметом обсуждения в ЖЖ был сам ЖЖ, и полно было постингов типа "список всех русских журналов" или "что делать в ЖЖ" -- вот в волнах сейчас ровно этот период. С другой стороны, в ЖЖ было абсолютно понятно, что делать и как жить, он прост как две копейки. А в волнах непонятно: сложная смесь асинхронных и синхронных взаимодействий завораживает, но не ведет к какому-то осмысленному применению. Killer application будет каким-нибудь ботом, которого нужно будет добавлять к себе в друзья (возможно, дорого за это заплатив настоящими деньгами), но этот бот еще не написан. Или написан, но о нем пока никто не знает. Или уже давно пишется, но об этом никто не знает. Или все о нем уже знают, но никто не придает значения. | ||
