[Most Recent Entries] [Calendar View] [Friends]
Below are the 20 most recent journal entries recorded in
Anatoly Levenchuk's LiveJournal:
| Friday, July 10th, 2009 | |
| 12:55 am | Бешеный четверг Четверг, как обычно -- самый загруженный день. * * * Где-то летом после шестого класса мне вдруг приспичило учить латинский. Купил какой-то учебник (для ветеринаров, кажется), пытался что-то понимать. Ничего не понял. Года через два купил еще один учебник латыни (для юристов, насколько помню). Опять ничего не понял, и быстро уговорил себя, что латинский язык мне не нужен. Про то, что мне нужен английский, я понял еще только лет через пятнадцать... * * * Как ни странно, но моя ссылка на бразильский музыкальный подкаст стала для нескольких человек откровением. Специально для них: http://book.pdfchm.net/Focus-Music-of-N * * * Группа описаний (view) может быть либо выпиской (копия оригинала на какой-то момент), либо оригинальной, либо суммой выписок и оригиналов. Проблема в том, что люди в массе своей путают выписки и оригиналы, и это происходит в жизни (и намеренно, и по ошибке) и в стандартах (по ошибке), и даже в нормативных актах (по небрежию, ошибке и незнанию). Так что view означает тематическую группу описаний, а уж выписка это или оригинал нужно в каждом случае разбираться отдельно. Этим я ставлю некоторую точку в развязанной мной самим некоторое время назад терминологической дискуссии. * * * Замечу, что "операционная система Гугля", равно как и Андроид -- это просто варианты Линукса. С этого момента мне неинтересно, разных Линуксов ведь много, и от добавки еще одного в мире операционных систем ничего не изменится. Про имя я вообще молчу: как Линукс уже не Гну, так и Хром уже не Линукс... Аналогичная "браузерная ОС" Gazelle от Microsoft тоже ни разу не новая операционная система -- http://www.infoq.com/news/2009/07/Gazel Термин "новая операционная система" вдруг изменил свое значение. Теперь, услышав "операционная система" нужно долго спрашивать, какие именно "операции" имеются ввиду... * * * Интересно, связь между регулированием цен и введением талонов нашим Партии и Правительству кто-нибудь напомнит? Или этот бледнолицый будет наступать на грабли много-много раз? Я еще могу понять, когда закрывают рынок -- это всем понятно, что борьба не с рынком (то бишь базаром), а с чем-то совсем другим, не имеющим никакого отношения к собственно торговле. Но борьба с торговыми сетями! Ну, и демократизация (в смысле решения вопросов голосованием) экономики на встрече G8: "Дмитрий Медведев рассказал, что в рамках Петербургского экономического форума прошло голосование, какую цену на нефть считать справедливой. Эксперты, участвовавшие в этом форуме, сошлись на том, что 70-80 долларов за баррель было бы приемлемо на данный момент. Лидеры стран "восьмерки" согласились с этими цифрами." (http://www.rg.ru/2009/07/09/vosjmerka.h Тут вдумчивый читатель сам подставит надлежащее количество мата на любом привычном для него языке. * * * Рецензия на мою рецензию про Голдратта: http://mmaxxxx.livejournal.com/134255.h |
| Thursday, July 9th, 2009 | |
| 12:12 am | Сказки на ночь А вот такие у ботов будут глазки -- как у человека, только круче: http://www.wired.com/dangerroom/200 * * * У русскоязычных интегральщиков (интересующихся Кеном Уилбером) завелась жизнь на портале: http://www.integralportal.ru Вот его последнее выступление 27 июня 2009г. (в переводе на русский), по факту оно про матрицу Комба-Уилбера но в развороте "чего в восточных религиях не хватает, чего в западном образовании не хватает": http://www.integralportal.ru/message/13 * * * Вот такие вот пошли стартапы: http://www.impredicative.com/ (обе ссылки на этой странице интересны -- но только для интересующихся современным программистским языкотворчеством). |
| Wednesday, July 8th, 2009 | |
| 5:30 pm | Середина недели Просьба писать мне письма на ailev@asmp.msk.su, ежели что хотите мне сообщить лично. Ибо "сообщения ЖЖ" приходят ко мне в такой форме, что я с ними без проблем работать не могу (ох, уж эта юзабилити веб-интерфейсов). Это я к тому, что вчера-сегодня очень много людей захотели со мной связаться именно через "ЖЖ-почту", которая ведь вовсе не почта... * * * Обзор прошлогоднего аналитического отчета Semantic Wave 2008 -- http://integrallife.com/files/Seman Ежели кому нравятся картинки про Web 3.0, то там их есть. The semantic wave embraces four stages of internet growth. The irst stage, Web 1.0, was about connecting information and getting on the net. Web 2.0 is about connecting people — putting the “I” in user interface, and the “we” into Webs of social participation. The next stage, Web 3.0, is starting now. It is about representing meanings, connecting knowledge, and putting these to work in ways that make our experience of internet more relevant, useful, and enjoyable. Web 4.0 will come later. It is about connecting intelligences in a ubiquitous Web where both people and things reason and communicate together.Приглядитесь: там уилберовские 4 квадранта!  * * * Нужно было нарисовать картинку трех жизненных циклов в их взаимосвязи. Попробовал в SmartDraw2008, в MS Visio -- нуль результатов, вышивание крестиком. Решением оказалось использовать SmartArt Tools из MS PowerPoint 2007. Патамушто SmartArt исходят из того, что у тебя есть (текстовая) структура, и тебе нужно графически подать эту текстовую структуру. А эти дурацкие "рисовалки" исходят из того, что у тебя есть картинка, и тебе ее нужно нарисовать из базовых примитивов -- а тексты в каждом элементике сами по себе, никакой структуры не представляют. Жизнь через ПауэрПойнт. |
| Tuesday, July 7th, 2009 | |
| 12:40 am | Веблог Не пропустите: сегодня ![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} andrey_stepenko вновь выложил в Сеть три своих перевода книжек Э.Голдратта: http://zhurnal.lib.ru/s/stepenko_a_Эти книжки я бы отнес к обязательному чтиву (для кого? Долго думал, три раза начинал писать, что художникам и музыкантам можно не читать, и три раза понимал, что и для них тоже бы нужно. Так что -- обязательное чтиво для всех). * * * Кончился перерыв в передачах Caipirinha Appreciation Society -- http://cas.podomatic.com/. Они восхитительны: это та самая бразильская музыка, которую нельзя услышать в ротациях радиостанций, а часто и купить на пластинках и выкачать в торрент-сетях. Двухчасовые эти передачи очень разные по стилям как внутри себя, так и между собой. Уверен, вам понравится. * * * Про новые применения карбида кремния в разных преобразователях напряжения (http://techon.nikkeibp.co.jp/article/H Я вдруг осознал, что бОльшую часть жизни профессионально занимался всяким intangible, и крайне гордился этим. А сейчас все чаще и чаще задумываюсь об определяющей роли tangible. Оно понятно, что без intangible (например, софта) огромное количество tangible -- груда бесполезного железа, годного только на переплавку. Но как-то упускается из виду, что без этого полезного tangible весь этот intangible не менее бесполезен, и его даже на переплавку нельзя отправить... * * * Пригласили меня выступить на нижегородский TEDx -- и я дал предварительное согласие. Сегодня увидел, кто там будет выступать: http://community.livejournal.com/icamp2 Уж не знаю, когда буду готовить презентацию, но хотел бы рассказать о том, как за воплями о нано-технологиях абсолютно незамеченным проходит революция в кило-технологиях -- человечество быстро-быстро осваивает километровые размеры своих конструкций. При этом опять-таки не забываем, что цена оборудования пропорциональна кубу объема -- но куда деться, ежели для многих и многих применений размер имеет значение? Конечно, большие проекты в истории человечества были и раньше. Что изменилось в XXI веке по сравнению, например, с веком XX? 1. Сооружаются объекты, которые принципиально не были возможны раньше. 2. Этих проектов много, и они все разных типов. Очень много, и очень разных. Раньше каждый большой (в прямом смысле слова -- большой по физическим размерам) проект становился чуть ли не номерным "чудом света". Сейчас большинство таких проектов являются чудесами лишь местного масштаба. 3. Техника безопасности. На этих стройках и монтажах перестали умирать люди -- раньше это было обычным делом. Сами сооружения тоже стали безопаснее в разы: сейсмоустойчивость, телекамеры слежения и т.д. 4. Финансирование кило-проектов уже не только государственное, но все чаще и чаще частное. 5. Сроки сооружения кило-объектов существенно короче, чем раньше. Более того, эти сроки соблюдаются (равно как и бюджеты). Итого: массово делается невообразимое -- причем в срок, и в рамках бюджета. Это ли не чудо?! А задумки уже идут по мега-технологиям... |
| Monday, July 6th, 2009 | |
| 1:41 pm | Концепт-архитектура софта PraxOS В очередной раз пофантазируем о том, каким мог бы быть софт PraxOS. Конечно, пока обсуждаем только концепт-архитектуру, которая (как и концепт-кары) бесконечно далека от принимаемой для промышленной разработки версии -- но если сегодня начать с такими концептами, то лет за пять вполне можно и до промышленной версии дойти. Что мне нравится, так это существование работающих прототипов для любой из частей этой концепт-архитектуры. Остается только собрать эти идеи из разных систем в одно работающее целое. Вот из каких элементов могла бы состоять PraxOS-система: 1. Интерфейсер -- генератор отчетов, редактор, дебаггер и прочий интерфейс с человеком. Основные черты: -- на первый взгляд воспринимается как средство подготовки презентаций, но не типа PowerPoint, а зум-презентации типа Prezi (http://prezi.com). -- Презентации состоят из отдельных представлений, которые берутся из набора, похожего на энциклопедию визуальных представлений (помните "периодическую таблицу методов визуализации"? http://www.visual-literacy.org/periodic -- Каждое представление препрограммируется как отображение данных модели согласно метаданных метамодели на некую нотацию. Это и есть DSL: свой для каждого представления, которое является просто отображаемой на презентации картинкой (необязательно прямоугольной), и оно редактируемо (т.е. служит как средством вывода, так и средством ввода данных модели). -- представления могут быть в форме, особо удобной для манипулирования (редактирования), например двухпанельные Commanders или многопанельные Browsers. Они, понятно, набираются из элементарных представлений, но всякие варианты драг-н-дроп (включая управление через жестовые интерфейсы) обязательно поддерживаются. 2. Проектор-контроллер -- обеспечение объединения презентаций разных интерфейсеров (общий драг-н-дроп прежде всего, общие команды ко всем интерфейсерам, жестовый интерфейс для группы людей и т.д.). В двух вариантах: -- в реале управление выводом интерфейсеров на разные имеющиеся вокруг экраны, как в g-speak (http://www.oblong.com/), плюс другие идеи из MS project Natal. -- в виртуале раскидывание вывода интерфейсеров по предметам окружающего мира, как в http://www.qwaq.com/, но управление опять-таки как в project Natal (а внутри -- тот же g-speak). Только не поддавайтесь очарованию тамошних примеров манипулирования фотографиями и фильмами: очень много работы с предметами PraxOS будет нормальной текстовой и табличной (в том числе формовой), а не идеографической-иероглифической. 3. Репозиторий -- его задача поддерживать целостную базу знаний (в классическом понимании: ежели программы, которые трудятся над данными, хранятся в базе данных, равно как и схема базы данных, то такую базу данных назовем базой знаний). В репозитории есть: -- upper ontology. Например, из ISO 15926. Или из ISO 18629 (PSL). Вряд ли из SBVR, ибо тамошняя модель очень небогата. -- RDL (и тут нужно подумать, собственная или внешняя), как минимум состоящая из метамоделей предметов -- предметные модели Как именно это все устроено внутри (семантич.сетка, логика, объекты) -- это предмет отдельного обсуждения. Судя по сегодняшним онтологическим трендам, все неизбежно скатывается к логике. Двоюродные дедушки этого репозитория PraxOS -- репозитории современных САПР (SPF, SmarTeam, Vnet и т.д.). 4. Коммуникатор -- интерфейс Pub/Sub (думайте о каком-то гибриде между реализацией Facade из ISO 15927-7 и real-time data distribution specification, OMG DDS http://portals.omg.org/dds) для связи с внешним программным миром (другими движками PraxOS, адаптерами к legacy-приложениям и т.д.). 5. Движок -- мультипарадигмальная мультиязыковая платформа программирования. На ней, собственно, все остальное и написано. Например, это может быть пиумартовская COLA с добавками логической парадигмы, но обязательно умеющая распараллелиться (сейчас, как я понимаю, у COLA с параллельностью никак). 6. Предметы -- метамодели предметной области для Репозитория+Коммуникатора (включая словари для "локализации" для словарных сообществ) плюс отображения в нотации для Интерфейсера (или добавка к этим нотациям), плюс какие-то аналитические программы (проверка целостности, статистика, вычисления и т.д.). Эдакие стандарты типа оргметамоделей OMG -- BMM, SPEM и т.д. Примерно соответствуют "профайлам", или "mdac", или "плагинам" для UML2-моделеров. И не забыть сюда же разные варианты тьюториалов (каждый предмет поставляется в виде учебного софта, а затем этот учебный софт разворачивается на реальное применение). Чем лучше будет продумана архитектура, тем больше частей других элементов софта PraxOS удастся реализовать в виде предметов. В идеале софт PraxOSа написан сам на себе, и весь состоит из Предметов. Как этого добиться -- отдельный разговор (bootstrapping, конечно!). Дальше нужно обсуждать: -- обеспечивающие предметы (предметы, обеспечивающие функционирование PraxOS, но не связанные с организационным моделированием), т.е. уточнять архитектуру: программистская часть работы. -- целевые предметы (состав поддерживаемых PraxOS предметных областей организационного управления, предметы всевозможных САПР, предметы АСУ ТП и т.д.), т.е. заниматься экспертной (непрограммистской) частью работы. Конечно, лучше всего обсуждать целевые предметы, документируя обсужденное с использованием средств обеспечивающей системы -- обеспечивающих предметов по разработке предметов. -- существующие международные стандарты, на рекомендации которых можно (я бы даже сказал: нужно) опереться. |
| Sunday, July 5th, 2009 | |
| 11:56 pm | Об оргмоделирование Про болото стандартов словарей организаций хорошее представление дает списочек из https://www.opengroup.org/projects/si/u Оставь надежду, всяк сюда входящий. Первая история про Вавилонскую башню стала трагедией, затем -- с языками програмирования -- фарсом, а сейчас та же история со словарями-онтологиями стала клоунадой: упал (всем смеяться), отжался (смеяться два раза). Основная печаль тут еще и в том, что на "SBVR 15926" Гугль выдает сплошь мои постинги. Первая же цитата из результата поиска -- "Люди из ISO 15926 об SBVR, похоже, не знают. Нужно будет им написать письмо (хотя я заранее знаю, что они ответят -- "отлично! вот и займись этим")". Глас вопиющего в пустыне. * * * С моделерами общего назначения (Artisan, Objecteering, Rational, Modelio, ModelPro, Eclipse MDT или EMF, Enterprise Architect и несть им числа) ситуация равно плохая: все они устроены одинаково -- представляют моделирование в картинках UML2 с целью довести результат до кода. Вся поддержка стандартов сводится к тому, что моделеры позволяют организовать "профайлы" (картриджи, плагины), поддерживающие те или иные стандарты. Эти "профайлы" между собой, как правило, не связываются. Изредка находятся герои, которые объединяют штук пять стандартов в один "профайл" (например, KnowEnterprise представляет такой "профайл" к Artisan Studio для SBVR, BMM, OSM, BPMN и еще ряду айтишно-ориентированных), но в моделерах общего назначения результат профайлирования ужасен: простым людям разобраться в этом программистко-ориентированном на UML2 мире нельзя, на диаграммах всего не увидишь, и приходится хитро манипулировать моделером, чтобы понять происходящее -- а моделер поддерживает прежде всего UML2 и все действия делаются не в терминах модели, а в терминах UML2. Все эти моделеры с "профайлами" оказываются по факту редакторами базы знаний, используемыми не столько для стадии Knowledge Aсquisition и последующей отладки знаний, сколько для накатанной дорожки производства кода в заходе MDA и документации к этим кода кодам (прежде всего речь идет о конверсии модели в текст требований ТЗ для подписания договора, и уж только затем речь заходит о "документации к наваянному"). Так, даже в Systems Engineering Edition для Enterpise Architect (http://www.sparxsystems.com/products/e База знаний оказывается при этом на UML2/MOF, куски целевой (в нашем случае организационной) онтологии подгружаются в виде "профайлов", отображение базы знаний на экране делается не в терминах удобных пользовательских DSL ("стереотипы" у меня язык не поворачивается называть DSL), а в терминах "иконок с подписями" -- в итоге в качестве нотации мы имеем диаграммно-иероглифическое письмо (можно поглядеть, например, на бесконечное количество иконок для SoaML, каковой язык моделирования услугоориентированной архитектуры так и определен как "UML профиль и метомодель для услуг" -- SoaML/UPMS: http://www.omg.org/docs/ad/08-08-04.p Я понимаю, зачем системы оргмоделирования программистам. Но хотелось бы получить систему оргмоделирования, которая была бы развернута в сторону организаторов людей, а не писателей кодов. Решения, в которых организационные знания выражаются в UML2, не похожи на правильные. Нельзя людей заставлять набирать организационные нормы в стиле детского tile-программирования, из иконок-слов, которые нужно выбирать мышкой из огромных словарных деревьев (а именно такое решение предлагается в KnowEnterprise/Artizan. Правда, там можно подключить внешний редактор для этих целей, но и внешний редактор не сильно лучше). * * * Второй класс моделеров -- это системы представления знаний, если вы, конечно, сможете эти "системы представления знаний" отличить сходу от предыдущего класса UML-моделеров, см., например http://www.ajrhem.com/AJRhem-KAF%20 Первое же наблюдение: оставь стандарты, всяк сюда входящий. Все стандарты "де факто" от человека или фирмы (типа CYC), или они вообще не стандарты и не опубликованы (типа БигМастер), или таки коллективной разработки и даже стандарты, но плохо структурированной в пространстве, времени и оргформах группы людей (типа Gellish). Инструменты иногда есть. Иногда наборот, есть только стандарты (типа ISO 15926, включая WIP), но нет развитых инструментов -- к которым отношу прежде всего возможность сгенерировать какой-нибудь понятный альбом схем, пригодный для подписания генеральным директором в качестве приложения к приказу по предприятию (если уж вообще говорить о целях организационного моделирования, то это и есть цель: сделать модель организации "to be" и утвердить ее приказом директора. А потом утверждать изменения этой модели). Бродить среди этих "не для программистов" университетских разработок "моделирования знаний" можно долго, и все они крайне перспективны. Но хочется-то а) стандартов и б) инструментов. А стандарты и инструменты появляются там, где обитают программисты. А программисты быстро-быстро все превращают в передачу токенов и машину состояний -- и их стандарты не помогают... Забавно, что в 80-х я довольно много (в самых разных проектах и на разных местах работы) работал с этой предметной областью "представления знаний" как говорили раньше и "моделирования", как говорят сейчас, отмываясь от дурной репутации программистского "искусственного интеллекта" и не связываясь с гуманитарным "управлением знаниями". Что изменилось за прошедшие 20 лет? Вместо "редактора форм" или текстового редактора для редактирования используются графические редакторы -- а двадцать лет назад просто не было мышки. Сказать, что это принципиальное нововведение, я не могу. В некоторых задачах объемы информации стали огромны -- старые машины просто это не смогли бы переварить. Но никакого перехода количества в качество не наблюдается. Чуть больше внимания уделяется формальной полноте языков представления моделей: двадцать лет назад этому вообще не уделялось внимания, а теперь формализмами хотя бы чуть-чуть интересуются. Негусто, совсем негусто. Нужно также понимать, что в указанной группе продуктов есть самые интересные: предназначенные не для генерации кода, а для обеспечения понимания. Именно к такому классу продуктов относится, например, БигМастер -- универсальный моделер, который разрабатывался как средство knowledge acquisition и последующей генерации не столько кодов, сколько отчетов. Вот такое и нужно прежде всего -- удобное, ориентированное на людей, но соответствующее стандартам и с проработанной онтологией (это важно для связи с другими системами: одиноко торчащие приложения сегодня мало кому нужны). Ну, и где такое взять?! * * * Третий класс моделеров -- это IDE для DSL. Представления знаний, как осознанного моделирования тут вообще нет, все кодируется "просто языком" и называется DDE (domain-driven engineering). Мне это направление кажется невероятно перспективным. По сути -- это тот же моделер, что и существующие UML-моделеры, но а) представление моделей в памяти в них не ограничено MOF. Это может быть и фактоориентированное представление, и любое другое. Обратная сторона этой медали -- проблемы с обменом такими моделями с другими приложениями. Но обмениваться можно и в XMI, ежели приспичило. Сгенерировать UML -- это совершенно не то, что в нем работать. б) представление моделей на экране в них не ограничено UML-диаграммами, и может быть сделано удобным для эксперта-непрограммиста. "Редактор языков/моделей общего назначения" или language workbench -- это очень и очень новый класс софта. Увы, в этой области нет еще вообще ничего: ни нормальных DSL (есть какие-то очень узкие "тестовые примеры"), ни нормальных редакторов (три штуки, кочующие из обзора в обзор), ни заточки на генерацию просматриваемых человеком документов-выписок (поскольку делают это все программисты, то заточка существующих polyDSL-IDE делается на генерацию кода -- конечно, на Java). Про управление конфигурацией, многопользовательскость и прочие черты "промышленного программирования" я вообще молчу: это все будет, конечно, но "когда-нибудь". * * * Теперь несколько слов о примерах использования (user stories) организационных моделей -- это крайне важно для оценки того софта, который сейчас может быть использован для целей оргмоделирования. 1. Команда программистов пришла в организацию и декларировала "ориентацию IT на бизнес-цели". Чтобы это доказать, они вытаскивают UML-моделер, и первым делом делают BMM-модель. Клиент в восторге, его спросили про бизнес и заставили сформулировать показатели для balanced scorecards -- а эти balanced scorecards важны будут, чтобы "информационная система" (к которой все в конечном итоге и сведется) имела сразу "правильные отчеты". Существенным является knowledge aсquisition словаря, а также организационных норм и процессов вкупе с оргструктурой: по ним сразу генерируется код (BPEL с непосредственным исполнением плюс business rules engine), и многочисленные клерки тут же получают свои формочки и дашборды. Очень удобно, все счастливы. Модель процессов вывешивается на стенке в качестве документации, чтобы новые сотрудники понимали, что реально происходит и кто к кому с чем обращается. Под этот сценарий уже сегодня можно брать UML-моделеры, и всем будет хорошо. 2. Служба развития компании пытается сформулировать новую стратегию и предложить новые организационные процессы. Для этого они организуют проектные сессии с компетентными в формулировании этой стратегии сотрудниками, используя организационную модель в качестве средства документирования и обсуждения "письменно зафиксированной" стратегии, организационных норм, процессов, а затем и оргструктуры. Любые изменения, сделанные в каких-то удобных для непрограммистов группах описаний (view), отражаются (согласно правилам согласования методов описаний, viewpoint correspondence view) в других удобных для непрограммистов группах описаний -- там отлавливаются организационные ошибки, и оргмодель тем самым становится все точнее и подробнее (с точки зрения людей-организаторов. Мнение программистов в этот момент никого не волнует). В какой-то момент менеджмент утверждает эту модель в качестве "руководства к действию" -- и "из неё" генерируются инструкции персоналу, альбомы оргструктуры и процессов, а после получения виз всех разработчиков эти (ага, уже бумажные) альбомы становятся приложениями к утверждающему их приказу. Под это применение я пока не знаю средств (БигМастер мог бы сгодиться, но его заточенность на eIDEF0 делает его плохим средством моделирования процессов, включая хореографию. А несоответствие многим другим стандартам делает его нестыкуемым с другими видами софта: трудным переход к сценарию 1, в котором по тексту данной модели можно также сгенерировать еще и код. Кроме того, я не видел хороших нотаций DSL для описаний организации, понятных менеджменту. Иероглифику многоиконочных UML-нотаций не предлагать). 3. Создается временная организация для достижения какой-то цели (т.е. проект. Недаром в ISO 15288 слова "проект" и "организация" путаются). Строится организационная модель: определяются цели и задачи (BMM), определяется процесс (в смысле SPEM -- форма жизненного цикла, стадии, методы работы и т.д.), делается экземпляр процесса и для этого экземпляра процесса планируется график (в смысле "сетевого планирования") проекта -- он же "процесс BPMN". Заключаются необходимые (не всегда письменные и не всегда "внешние") контракты/договорки, оргмодель начинает отражать расширенную организацию с учетом этих контрактов (хореографическая компонента BPMN, сейчас это BPDM, а потом просто BPMN 2). Выделяются ресурсы (добавляется "вписывание" в OSM). Запускается issue tracker + система управления конфигурацией для продуцируемых артефактов (включая управление конфигурацией deliverables), их настройки генерируются из оргмодели. Для этих целей можно пробовать использовать те куски оргмоделирования (а они там есть!), которые застряли в системах управления проектами, issue trackers и некоторых workflow-системах -- системах управления процессами типа уже упоминавшейся процессно-проектной системы Savvion. Но как это оргмоделирование бедно и как его результаты невозможно утвердить приказом, ибо это оргмоделирование выполняется опять же программистами! Но нет сомнения, что эти обрывки застрявших в этом софте оргмоделеров будет постепенно вырастать в полноценные и более-менее понятные непрограммистам средства оргмоделирования. Очень постепенно, так что за время этого вырастания что-нибудь может произойти с самими классами этого софта (удивительно, но еще год назад я встречал не только множество непрограммистов, но и множество программистов, не знающих про такой класс софта, как issue tracker. А про то, что системы управления проектами внутри себя имеют маленькую собственную систему управленческого финансового учета, тоже мало кто догадывается). Итого: из оргмодели можно генерировать 1. код софта, 2. тексты распорядительных документов, 3. настройки для систем управления проектами/процессами. Это означает, что фронт-энд "для экспертов" у моделера может быть один и тот же, а вот бэк-энды существенно разные (нельзя ведь говорить, что "софт фронт-энда генерирует просто текст" -- толку-то в такой "просто генерации"!). Динамическую ситуацию, когда организация работы ежедневно меняется, отражая сознательно меняемую оргмодель (а оргмодель меняется, отражая сознательно изменяемую организацию работ) я пока даже не рассматриваю. Переход от статики к динамике, от "организационной компиляции" к "организационной интерпретации" -- это потом, когда-нибудь. |
| Saturday, July 4th, 2009 | |
| 12:30 pm | Суббота утро В четверг состоялось очередное заседание Русского отделения INCOSE, и я прочел там доклад по стандартам организационного моделирования в системной инженерии (а первый час даже удалось записать на видео: http://community.livejournal.com/incose * * * Все чаще и чаще люди замечают, что нынешние Партия и Правительство в России более-менее успешно реализуют Программу НСДАП 1927г., как минимум в отношении торговых бизнесов: http://v-novikov.livejournal.com/30 * * * Поглядел краем глаза концерт Diana Kroll в Рио. Поражен был до глубины души: я не понимал, почему она такая знаменитая джазовая певица (ибо мне не очень нравится, как она поет по сравнению со многими другими), но выяснилось, что она отлично играет на пианино -- по моему мнению, так много лучше, чем поет. И теперь я понимаю, что знаменита она стала именно по совокупности игры и пения. Примерно так же я удивлялся, когда увидел пару выступлений Tory Amos под собственную игру на клавишах -- но Tory Amos как раз поет лучше, чем играет. * * * Читал оргмоделер. Много думал. Писать не удалось: редкая птица перелетает через русские шрифты без плясок с бубном... * * * Наконец-то звуковые прожекторы пошли в жизнь. LF-120 и LF-220 от Fohhn (http://www.fohhn.com/uploads/media/LF-1 Про аналогичную "колонку" (именно что "маленькую колонну") BOSE L1 Compact тоже всякие чудеса пишут: http://www.synthzone.com/ubbs/Forum37/H У такой аппаратуры обычно плохо только с одним параметром: ценой, ибо много-много драйверов в одном корпусе, и все их нужно изготовить и закрепить. Но у новой техники всегда с ценой плохо, пока она новая. |
| Thursday, July 2nd, 2009 | |
| 1:08 am | А теперь итальянские таланты Удивитесь: Вот из тамошних комментов: "I know the kid in the middle, and he only started voice training in February this year, a couple of months before this was recorded, so its all natural". |
| Wednesday, July 1st, 2009 | |
| 11:55 pm | Окружающая среда, перед четвергом Позавчера вечером, наконец, INCOSE Russian Chapter получила статус Emerging Chapter. Не знаю, есть ли в России секс (например, в СССР секса не было), но системная инженерия в России теперь точно есть. Завтра на заседании INCOSE буду читать доклад "Стандарты описания жизненного цикла и другие стандарты организационного моделирования в системной инженерии" (по слайдам "онтологические стандарты организационной модели" -- http://www.slideshare.net/ailev/ss-1640 * * * Сегодяшний эксперимент с ella_p показал, что я легко могу говорить на темы нормирования (законотворчества, стандартизации и т.д.) два часа подряд -- и это далеко не предел.* * * Развернул на ноутбуке для evaluation настоящий моделер: Artisan Studio + KnowEnterprise. Сильно испугался. Это то же программирование, и даже круче (каждая из частных моделей -- это ведь отдельный язык, а еще ведь есть межмодельные=межязыковые связи!). Нужно запомнить этот день, когда я сел за баранку этого пылесоса. Увы, ничего подобного класса из свободного софта и близко нету: только конструкторы типа "сделай сам" (тот же Eclipse или JBoss). Очень все это сложно организовано: после всех этих установок у меня на компьютере вдруг появился еще один пользовательский запароленный администраторский эккаунт, завелись какие-то серверные процессы, администраторские утилиты... * * * Спонтанно случившийся сегодня многочасовой внутренний семинар TechInvestLab привел к следующему неутешительному выводу: в современных средствах организационного моделирования (включая модели процессов) нет средств, которые могли бы адекватно отмоделировать 4D модель основных систем (целевых!) и привязывать эту модель к оргмодели. На сегодня организационные модели крутятся среди одних людей и отмоделированы в одном софте, а технические модели крутятся среди других людей и отмоделированы в другом софте. И эти миры не соприкасаются, отсюда и бардак. Проблема в том, что систем много разных, жизненных циклов у них много, все эти системы находятся друг ко другу в разных отношениях, и эти отношения существенно зависят от того, в какой форме эти системы пребывают на той или иной стадии жизненного цикла. Полное множественное 4D в полный рост -- адекватное описание системы артефактов (часть из которых внутренние и вспомогательные продукты, а часть -- конечные продукты, целевые системы). А потом эти все артефакты (в число которых может войти и бюджет, и партия арматуры) нужно привязать к организационным моделям. Системная инженерия начинается с систем, в которых есть подсистемы, и которые изменяются в ходе их продвижения по жизненному циклу. С этого утречком и начнем -- с тем замечанием, что в традиционный PBS какого-нибудь САПРа это все не поместишь: систем много разных, и все они на разных этапах своих связанных жизненных циклов, моделирование этой ситуации требует специального сосредоточения. * * * ЖЖ предложил мне установить очередную аську. Я в очередной раз отказался. Эти аськопредложения когда-нибудь кончатся?! * * * Наконец, вышел FireFox 3.5 (http://www.mozilla-europe.org), который обещается быть втрое быстрее моего нынешнего FireFox 3 -- вот сейчас поставлю его, и лягу спать. UPDATE: поставил, времени заняло минуты три. Отвалился Tab Mix Plus -- ну, и как теперь с этим браузером вообще работать?! UPDATE2: фигня вопрос: новый TabMixPlus живет вот тут: http://tmp.garyr.net/forum/viewtopic.ph |
| Tuesday, June 30th, 2009 | |
| 11:38 pm | Десять гармонизированных подходов системной инженерии Обучение системной инженерии (или просто инженерии, если признать, что бессистемной инженерии вообще не должно существовать) связано с преодолением текущих парадигм в инженерном и менеджерском сознании. Макс Планк в своей "Научной автобиографии" (1968г) заметил, что парадигмы умирают только вместе с их носителями. Тем не менее, замена проторенных мыслительных рельс все-таки возможна в ходе специальным образом организованного образования -- если его не сводить к лекционным курсам и чтению учебников, а использовать так называемы активные методы. Каждая из "парадигм" системной инженерии обычно является "походом" (переносом категориальных схем и их понятийного раскрытия, разработанных в одних областях человеческой деятельности на другие сферы). При смене парадигмы одни "подходы" заменяют другие -- мышление начинает выделять в мире другие объекты и другие связи между объектами, и начинает проделывать с этими объектами другие операции. Часто ключевым моментом этой замены является осознание того факта, что "обычный ход вещей" является вовсе не обычным, а некоторым "подходом", который откуда-то пришел сам, и должен будет уступить место другому, более современному и лишенному недостатков предыдущего "подхода". Если какой-то человек не знает понятия жизненного цикла, то он все равно как-то работает со временем -- но не факт, что границы этого времени простираются от замысла системы до ее вывода из эксплуатации. С огромной степенью вероятности люди будут удерживать в голове при принятии решений тот кусочек времени, в котором продвижение системы по жизненному циклу находится в их ведении -- например, в силу контракта. Чтобы избавиться от недостатков такого подхода, нужно ввести новое понятие -- жизненный цикл -- и далее описать картину мира с использованием этого нового термина, причем согласовывая эту картину мира с многими и многими другими мыслительными нововведениями. Вот краткое перечисление этих улучшающих жизнь переходов от старых мыслительных парадигм к новым, гармонизацию которых в своем составе предполагает системная инженерия: 1. Переход от редукционистского к системному подходу. Целое невозможно свести к сумме частей этого целого -- вот суть системного подхода. Само выделение целого как "фигуры из фона" не может быть произвольным, то же относится к элементам системы: важна цель системы, важно взаимодействие элементов для достижения этой цели, а не просто наличие произвольно выбранных частей. Любая система имеет надсистему и подсистемы, системы иерархичны. Границы системы с окружающими ее системами важны и требуют явного определения: все участники междисциплинарного обсуждения должны говорить об одной и той же системе в одних и тех же границах, чтобы не подменять системы в ходе их обсуждения. Это очень просто звучит, но по факту "редукционистский" (выделение отдельных черт исследуемого или проектируемого объекта, без обсуждения принципов, по которым эти отдельные черты были выделены) или "натуральный" ("естественный", "здравого смысла") подход применяется повсеместно до сих пор. Системное мышление не становится системным только потому, что в текстах упоминается слово "система" и "выделяются части системы". Само выделение системы из окружащего мира происходит в форме описаний. Важным тут является вопрос, являются ли эти описания частью системы, а также как связаны между собой системы, выполненные по одним и тем же описаниям разного уровня абстракции (без этого трудно обсуждать systems family engineering, технологические платформы). Очень трудным является понимание системы систем (system-of-system), в которой в качестве совместной рассматриваются системы, имеющие разных собственников. Понятие киберфизической системы, а также рассмотрение совместной системы из киберфизической и людей тоже обычно дается с трудом: гуманитарии игнорируют физическую часть, технари -- людскую. 2. Переход от структурного к процессному подходу. Главное, что происходит в системе -- это ее изменения во времени. Рассмотрения системы (организации, двигателя внутреннего сгорания, человека или даже общества) с точки зрения его структуры (схемы, отражающей связи элементов-подсистем) совершенно недостаточно, нужно рассматривать изменения во времени и взаимодействия, разворачиваемые во времени. Например, в организационных системах сейчас повсеместно переходят от органиграммы как основного средства представления организации к процессным диаграммам, управление проектами -- это отражение того же тренда: сетевой график проекта много лучше отражает положение дел, нежели штатное расписание. Сюда же обычно относят концепцию полного жизненного цикла, все варианты проектного подхода и связанные с ним методы управления жизненным циклом. Изредка этот переход относят не к отдельному, а говорят о "втором поколении системного подхода", ибо само задание процессов требует выделения системы, в которой эти процессы идут. Тут нужно обратить особое внимание, что в системной инженерии процессы жизненного цикла -- это процессы, которые происходят в обеспечивающей системе для продвижения целевой системы по ее жизненному циклу, а не в целевой системе. Поэтому иногда уточняют, что речь идет о процессах управления жизненным циклом. Сюда же можно отнести необходимость перехода (как минимум, в информационном моделировании систем) к представлениям 4D-онтологии, в которых у объектов есть темпоральные части, и поэтому легче обсуждать изменения объектов во времени, чем в "бытовой" 3D-онтологии. Но дискуссия о необходимости такого перехода еще не закончилась. И тут же следует указать, что процессы описываются с точки зрения акторов, а не с точки зрения конкретных участвующих в них людей. 3. Переход от одной группы описаний ко множественности групп описаний. Никакой одной профессиональной точки зрения недостаточно, чтобы получить более или менее полное реализационное описание системы. Для системы должны быть получены различные группы взаимосвязанных описаний, часто получаемые междисциплинарно. В культурологии это "постмодерн", в СМД-методологии это "схема многих знаний", в системной инженерии ISO 42010, стандарт архитектурных описаний. 4. Переход от рабочего проектирования (конструирования, дизайна) к обязательному предварительному архитектурному. Вместо того, чтобы сразу работать с "кодом" софта, "чертежами" оборудования, "инструкциями" организации и прочими реализационными описаниями систем, для начала нужно сделать сущностное, не зависящее от деталей реализации описание создаваемой системы: архитектуру. Архитектура описывает основные подсистемы и их взаимодействие в языке, свободном от деталей реализации. Одной архитектуре может соответствовать множество разных реализаций. Архитектура более живуча, чем ее реализации. 5. Переход от непосредственной реализации к моделецентричной реализации. Вместо того, чтобы строить реальную систему, для начала создаются всевозможные модели системы -- как абстрактные архитектурные, так и имитационные, зависящие от реализации. Эти модели представляют более-менее адекватное реальности подробное описание системы, к которому возможно задавать вопросы "а что если" (т.е. речь идет прежде всего об имитационном моделировании, включая имитационные прогоны архитектурных моделей). Сначала система "строится" в идеальном мире моделирования, и только затем в реальном мире: все ошибки убираются на этапе моделирования, а не на этапе реального воплощения в мире. Сюда же относится идея о том, что описания системы (включая архитектурные описания) должны быть представлены не на естественном языке, а на формальном языке, подразумевающем возможность какого-то отчужденного от чтения человеком "машинного исполнения". 6. Переход от документоцентризма к датацентризму. Различные описания системы не должны готовиться в форме отдельных документов. Все эти описания должны храниться в виде взаимосвязанных отдельных информационных единиц-данных, готовых для объединения в той или иной форме -- речь идет о хранении информации в виде базы данных и доступе к этой информации с разнообразными запросами. Более того, работа с изменениями должна вестись в терминах отдельных данных, а не "документов". Думать об информации таким образом очень трудно, ибо базы данных (тем более -- распределенные базы данных) появились в истории человечества совсем недавно, а вся материальная культура и язык поддерживает работу с "документами-на-листах-бумаги". 7. Переход от работы "для одного хозяина" к работе со множеством заинтересованных сторон. Для любой системы всегда есть множество заинтересованных сторон, мнение которых нужно учитывать. Это означает, что требования к системе всегда противоречивы, исходят из самых разных источников, и нужна специальная работа по их согласованию -- значительная часть этой работы сводится не к техническим решениям, а к проведению переговоров между заинтересованными лицами. Наличие множества заинтересованных в системе сторон существенно меняет содержание инженерной деятельности: эта деятельность по "инженерии требований" уже не проходит в мире исключительно технических решений, а должна учитывать противоречивые интересы самых разных людей. 8. Переход от "проверки" к раздельным верификации и валидации. Идея верификации (проверка на соответствие формальным требованиям) всем привычна. Много более трудно воспринимается идея, что такой проверки явно недостаточно: важно не столько соответствие требованиям, сколько то, чтобы системой можно было пользоваться -- ибо при разработке системы ошибка могла закрасться в сами требования! 9. Переход от методов "предсказания будущего" к использованию гибких методов. Идея о том, что любые предсказания будущего (в том числе в таких формах, как тщательно разработанные планы) являются заведомо неполными и неточными, и с планами нужно работать как с "прогнозами", а не "обещаниями", воспринимается очень тяжело. Особенно трудно перейти к риск-ориентированным формам жизненного цикла, подразумевающим пошаговое выделение ресурсов на основе постоянного пересмотра их выделения на основе непрерывно меняющихся оценок проектной ситуации. Гибкие методы ведут к модификациям основных практик системной инженерии, когда планировать приходится в условиях отсутствия прецедентов (так, идея о том, что требования должны меняться в течение всего жизненного цикла, понимается очень трудно -- ведь в методах "предсказания будущего" все полные и детальные требования должны быть "предсказаны" в самом начале разработки!). 10. Переход от "технологического конвейера" к "заказам-поставкам". Процесс управления жизненным циклом нельзя считать "конвейером", просто выполнением серии технологически предписанных работ (в теории управления организационными процессами это называют "оркестровка"). В жизни независимые акторы участвуют в процессе, выполняя контракт на оказание услуги по своей части участия в общем процессе (в теории управления организационными процессами это называют "хореография"). В системной ижненерии этот вопрос обсуждается как отдельная группа контрактных практик, причем самым трудным тут является понимание того факта, что контракты могут быть не только явные между различными юридическими лицами, но и неявные внутри акторов в рамках одной организации. Все это общие подходы (наборы идей о том, как обсуждать мир), которые применимы для самых разных типов систем -- но на разном материале эти принципы работают по-разному. Можно выделить следующие типы целевых рукотворных систем, формы жизненных циклов у которых существенно различаются: -- оборудование -- софт -- организация (люди) Понятно, что "проектирование сотрудника" или "проектирование организации" по методам существенно отличается от проектирования софта, а проектирование софта существенно отличается о проектирования оборудования. Но, например, переход от идеи рабочего проектирования к идее обязательной архитектурной (т.е. без реализационных деталей, сущностной "онтологической") проработки конструкции применим ко всем типам, хотя архитектуры оборудования, софта и организации выразимы в абсолютно разных типах описаний, взаимно непонятных для работающих над созданием оборудования, софта и организации специалистов. Образовательная задача как раз в том, чтобы инсталлировать в головах студентов такой образ мыслей, который бы позволил гармонизированно применять перечисленные десять основных подходов системной инженерии к любым системам, не отвлекаясь на специфику материала системы. Конечно, этот список можно критиковать. Например, можно обсуждать включение в него в явном виде работы с рисками. Или обязательность управления решениями. Можно выписать все практики системной инженерии, и потребовать научить этим практикам -- прямо по списку из какого-нибудь учебника или какого-нибудь стандарта. Легко заметить, что в предлагаемом мной списке довольно много того, что в явном виде не попадает ни в какие практики, а обычно пишется в "предисловиях", "введениях", "общих замечаниях" и дале считается само собой разумеющимся. Я при составлении этого списка ориентировался как раз на то, что все эти переходы от одних "бытовых" мыслительных парадигм к другим ("профессиональным") не являются само собой разумеющимися, такому мышлению нужно учить специально. И попробовал отобрать те подходы, которые являются ядром системной инженерии, отличающие ее от любых других способов продвижения рукотворных систем по их жизненным циклам -- от замысла до вывода из эксплуатации. |
| 12:36 pm | Факт-ориентированное моделирование Международный семинар по факт-ориентированному моделированию состоится 4-6 ноябра 2009г. в Vilamoura, Portugal (ORM2009, http://otm-conferences.com/index.php/or Факто-ориентированное моделирование -- это основанный на естественном языке концептуальный подход к моделированию и запросу сведений о предметных областях в терминах интересующих фактов. В этом подходе все факты и правила высказываются на языке, легко понимаемом специалистами этих предметных областей.Я бы еще отнес к интересным фактоориентированным подходам Gellish, с учетом того, что Gellish представляет не только интересный неграфический (а именно, табличный) формализм для записи фактов, но и промышленную онтологию. Еще интересным вариантом факт-ориентированного формализма является используемый в программе организационного моделирования БигМастер фирмы БИГ (http://big.spb.ru/bigmaster/, есть свободный вариант ГосМастер http://bigc.ru/government/products/gosm Каким путем я сегодня направил бы PraxOS? А вот этим бы путем и направил. |
| Sunday, June 28th, 2009 | |
| 11:06 pm | Воскресенье Ядерные блоггеры, наконец, встретились очно -- http://www.theenergycollective.com/TheE Понятно, что самое интересное в ядерной энергетики можно вычитать у блоггеров. У остальных игроков рынка информация никогда не вылезет на поверхность. Впрочем, и блоггеры тоже пишут не всё, что знают. Ко мне это тоже относится, хотя я и не "блоггер", и не "ядерный". * * * Живу в иланг-иланговом лесу, вся квартира от вчерашних воскурений провонена им насквозь. * * * Книжка по BMM -- http://www.pdfxp.com/pdf/www9-9business * * * Никак не могу понять, в чем подвох Google Voice -- http://www.google.com/googlevoice/a Инициативы Гугля сильно радуют, но не менее сильно напрягают. Огромная инфраструктура под единым управлением: абсолютная власть развращает ведь абсолютно. С другой стороны, кто может сделать дешевле и лучше? А что бесплатный сыр бывает только в мышеловке, это все знают. * * * Софт под новые стандарты OMG пока практически недоступен: есть только коммерческие варианты, и многие доступны только как часть консалтинговых предложений. BPMN 1.1 поддерживается повсеместно, в том числе и в свободном софте (например, недлинный списочек есть в http://bpmsoftware.wordpress.com/free-b Дела в http://wiki.eclipse.org/MDT (Model Development Tools, вебсайт проекта http://www.eclipse.org/modeling/mdt/ Работающий BPMN редактор в eclipse -- http://www.eclipse.org/bpmn/ (сейчас в SOA Tools platform project -- http://www.eclipse.org/stp/). Ребята в http://www.savvion.com обложились формами по сбору информации с каждого, кто к ним заглянет. Но у них процессно-проектный подход: в процессы на BPMN разрешается добавлять майлстоуны, всасывать информацию из MS Project и экспортировать в него, и всячески размывается граница проектного и процессного -- наконец-то кто-то сообразил! Adonis community edition поддерживает интересные расширения в моделировании BPMN 1: http://www.adonis-community.com/faq_fun Lombardi Blueprint представляет решение в духе 37Signals -- простейшие диаграммы, очень удобный интерфейс, экспорт в ворд, эксель, пауэрпойнт и прочие радости менеджера. Правда, можно экспортировать и в BPDM. 30 дней бесплатного триала, а затем отрубание всех возможностей экспорта -- https://blueprint.lombardi.com Все это BPMN-процессное хозяйство в очень растрепанном состоянии, никак они оправиться от засилья разных других "процессных" нотаций не могут. Шаблоны для разных процессов собраны тут: http://www.metastorm.com/products/refer Design Chain по DCOR -- доступен только членам Supply-Chain Council: http://www.supply-chain.org/resources/d В мае вышел public preview DCOR 2.0 * * * Выходных категорически не хватает. Завтра утром опять начнутся входные... |
| 1:54 pm | Заоблачные вычисления. Облачные вычисления стали уже заоблачными: на виртуальных машинах Amazon EC2 и памяти Amazon S3 фирма Microsoft (ладно, не сама она, а только что проглоченный ей Powerset, поиск на естественном языке) разворачивает свободную кластерную инфраструктуру Hadoop (http://hadoop.apache.org/core/), и затем решает свои задачи на этом "виртуальном суперкомпьютере", собранном из виртуальных машин. Облако на облаке, заоблачность налицо. Это не единственный пример. Рекламная сеть Adknowledge поступает ровно таким же образом: Hadoop поверх EC2. И японский поиск изображений CblR, и многие другие (http://wiki.apache.org/hadoop/PoweredB Ежели спуститься на ступеньку ниже, и просто собирать Hadoop-кластеры из обычных, а не виртуальных машин, то становятся возможными заоблачные вычисления в старинном ("недостижимости") смысле этого слова. Так, Yahoo! приняла участие в соревнованиях по сортировке больших массивох данных http://sortbenchmark.org/ и бодро отрапортовала (http://developer.yahoo.net/blogs/hadoo Чем больше электроный фундамент уходит в "нано", тем больше в облачных и даже заоблачных высях приходится запоминать значения слов уже не только "тера" (байты, флопсы), но и пета. Это несмотря на то, что герцы так и замерли в начале "гига". Инфраструктуру распределенных вычислений сделать не так уж дорого: за $10тыс. уже можно получить вполне навороченный собственный кластер, ежели есть чем его занять на полную катушку. А ежели нет уверенности в полной его занятости, то можно для экспериментов купить процессорное время в том же Amazon EC2/S3. Есть множество готовых свободнософтовых приложений для Hadoop -- от самого обычного веб-поиска (http://lucene.apache.org/nutch/) и корпоративного поиска (http://lucene.apache.org/solr/) до библиотек машинного обучения (http://lucene.apache.org/mahout/, the first public release includes implementations for clustering, classification, collaborative filtering and evolutionary programming). И при все этом я (вслед за Аланом Кеем) имею наглость утверждать, что компьютерная революция еще не началась: все помянутое обеспечение многослойно и в силу этого неэффективно дублирует друг друга, основано на допотопных процессорных и сетевых архитектурах, некомпактно из-за использования нынешних языков. Но я думаю, что переход от "пета" (квадриллион) к "экза" (следующие три нолика, квинтиллион), имена которых появились в 1975г., произойдет много быстрее, чем компьютерная революция. А уж компьютерная революция заставит вспомнить о появившихся в 1991г. "зетта" и "йотта" (http://www.wikiznanie.ru/ru-wz/index.php/М Имеет ли это значение? Да, именно это и имеет определяющее значение. Хотя я и не сторонник параллельности (я считаю, что последовательные вычисления далеко не исчерпали потенциала своего развития, и именно они являются определяющими для прогресса), дешевая параллельность крайне важна. Сначала все появляется в виде mainframe с заоблачными ценами, а затем такая же вычислительная мощность обязательно появляется у кого-нибудь в ноутбуке. Так было, и так будет. Поэтому крайне интересно смотреть на датацентры Гугля и думать, что будет в тот относительно недалекий момент, когда такие датацентры будут доступны в ноутбуках. А что будет в этот момент считаться в датацентрах (которые никуда, конечно, не денутся), даже представить сейчас невозможно. А пока проходим в среднем одну приставку за десятилетие. Что там за заоблаками? |
| 1:51 am | Суббота Жена купила свечку за 5руб., 10мл масла иланг-иланг за 30руб., и полдня проводила на мне эксперименты, кипятя весь этот доллар на моем рабочем столе. Первые несколько часов было нормально, а затем сквозняк поменял направление -- и мало мне не показалось. По степени прованивания помещения -- то же самое, что индийские тлеющие ароматы. Спать теперь буду как в иланг-иланговом саду душным тропическим вечером. * * * Новая наука "эконофизика", родившаяся в 90-х годах прошлого века усилиями российских безработных физиков, попавших в нелегкие экономические условия. Вы думаете, я шучу?! Это практически цитата из объявления о Первом Всероссийском конгрессе "Эконофизика, финансовые рынки, экономический рост" (http://www.strf.ru/organization.aspx?C Экспорт этой революции уже идет: "Несмотря на то, что эконофизика — наука молодая, она уже включена в программу обучения во многих ведущих университетах Европы и Северной Америки". Я так думаю, что эконофизики должны будут изучать падение индексов, введя затем понятия экономического тела и экономического ускорения. А когда они дойдут до квантовых денег (которые доходят до людей то частично, то волнами), тут-то и придется всем раскошелиться на Большой Экономический Коллайдер, где эконофизики будут сталкивать разогнанных (pun intended) потребителей и изготовителей и смотреть, что из этого получится. А вот как об этом говорят сами ученые. Георгий Малинецкий, зам.директора по научной работе ИПМ им.Келдыша РАН, доктор ф.-м.н., профессор(http://www.strf.ru/organizati Помните, Леонардо да Винчи изучал падение тел, бросая камешки. Он узнал, что падение зависит от плотности, массы и прочих вещей, получил много экспериментальных данных, но к развитию физики это не привело. На мой взгляд, эконофизика может остаться на уровне Леонардо да Винчи, то есть учёные будут анализировать чудесные данные статистики, математизировать всё и вся и так далее. Но если учёные смогут перешагнуть через это «музицирование», через барьер Галилея, то есть вывести ясные простые общие сущности, то тогда эконофизика станет важной и интересной частью математической экономики, которая в большой степени вдохновлена линейной математикой и которая пробует входить в сложный, богатый и интересный мир нелинейности. В этом случае у эконофизики славное будущее.Я думаю, что наши ученые слишком долго бросали камешки с крутого бережка далекого пролива Лаперуза. Теперь они много через чего готовы перешагнуть, перебежать, перелететь. Галилей со своим барьером будет нервно курить в сторонке. * * * А вот еще новости науки: про российскую смертность от алкоголя, на чистом английском языке -- http://www.physorg.com/news165240883.ht * * * Tuck Andress невероятно техничен в игре на гитаре -- http://www.youtube.com/watch?v=NtljYur4 Еще более удивительно, что есть люди, делающие нотную запись для этой игры -- http://www.tuckandresstabs.com/. А вот как играет этот автор свои транскрипции Tuck -- http://video.google.com/videoplay?d * * * Перевод ISO 15288:2008 сейчас как будто сделан ПРОМТом. Потому как сам текст как будто написан ПРОМТом... Каждый раз, когда мне активно не нравится перевод (то есть все время), мне еще более активно не нравится и оригинал. Хорошо понимаю людей, которые торгуют понятными пересказами этих стандартов. Вот, например, вариант такого пересказа: перечисление более 800 помянутых в стандарте планов, процедур, записей, документов, аудитов, пересмотров -- http://www.techstreet.com/cgi-bin/detai * * * Удивительный разговор получился про парадигмы программирования: http://ailev.livejournal.com/695253.htm Вот пройдет еще десять лет, и Великий Гугль будет искать на всех языках по-английски, а также объединять отдельные реплики в тредах. И тогда кто-нибудь будет искать тексты по онтологиям языков программирования, и найдет эти наши с avlasov заметки, и вытащит их все сразу на английском одной статьей -- и нанесем мы тем самым непоправимую пользу будущему. Впрочем, не удивлюсь, если этими "кто-нибудь" будем мы же. Я и сейчас регулярно делаю поисковые запросы на интересующие меня темы, в которых в том же Гугле вылезают по парочке моих постингов на первой же странице. Но это Гугль мне льстит: он подстраивается под мои поисковые паттерны, подмешивает побольше ссылок из "страны пребывания IP" и т.д.. * * * В магазин чая, который расположен в нескольких шкафчиках предбанника кафе "Джаганнат", что на Кузнецком Мосту, завезли разный китайский зеленый чай весеннего сбора. Рекомендую. * * * Я понял, чем именно меня дико раздражают некоторые виды презентаций. Они стремительно делаются похожими на глянцевые журналы! Беллетристика, беллеграфика... * * * "Мир сошел с ума" -- это неправда. Он на него и не всходил. |
| Friday, June 26th, 2009 | |
| 7:48 pm | Про человеколюбие Выложенный вчера подстрочник семинара по организационной модели (http://www.slideshare.net/ailev/ss-164 Это квинтэссенция сегодняшнего тренда на внимание к людям, внимание к облегчению их общения, внимание к предоставлению средств описаний, удовлетворяющих самым разным интересам. Тут можно выявить три этапа: появление хоть каких-то описаний организации (прежде всего -- органиграмма), затем признание необходимости множества таких описаний и связанный с этим переход от преимущественно структурных -- органиграмма -- к процессным описаниям, описаниям норм ("корпоративная культура") и т.д., и только затем, на третьем этапе более формальные описания, строящиеся на общем онтологическом метаязыке -- только для того, чтобы можно было строить общий разговор про все эти описания, каждое из которых строится так, чтобы учитывать наличие других и тесно с ними связано. В рамках этого связанного множества описаний, адресующих интересы многих и многих участников обсуждения организации, уже дальше можно выбирать более или менее адекватные. Но эта адекватность делится уже на адекватность описания того или иного аспекта организации (надлежащесть теории этого аспекта) и на адекватность вписывания в общую систему описаний (то, что называется "правила согласования методов описаний", viewpoint correspondence rules). Тот же тренд применим для описания "всеобщей организации" -- общества (или, что для меня то же самое, человека. Ибо в Птолемеевские модели человека я давно не верю, общество Маугли, где человек не находится среди других подобных, обществом не является, потому как Маугли только биологически люди). Сейчас все старые и новые нормы общественного описания, концепции человека и т.д. идут кубарем: я бы не мог выставить что-то в человеке, поддающееся определению -- все эти определения существенно ситуативны и одновременны по принципу. Это и есть сегодняшний главный тренд: отсутствие трактовки человека (как и всего остального) как продукта одной идеи -- рынка ли и "выгоды", "гуманитарно-счастьевой" или еще какой. Суть этого перехода не в добавлении (я бы даже сказал, во взрывном добавлении) при обсуждении какого-то одного аспекта "человека" всевозможных других -- при обсуждении человека в добровольных обменах (вроде как экономическое обсуждение, про "деньги" и "выгоду") юридических, политических, социологических и психологических описаний, при обсуждении политических проблем -- экономических и юридических и т.д. Но для каждой из разных "групп описаний" (view), адресующих разные "интересы" (concerns) могут быть более и менее адекватные теории. Например, про рынок и "экономического человека" были уж совсем уродливые марксистские/неоклассические теории, да и сейчас с этими теориями не все хорошо. Есть аналогичные теории про "счастье" и "радость", но это не столько теории, сколько "рассуждения". До сих пор ничего современно-адекватного про счастье, радость и любовь нет, хотя религиозные "теории" с байками про хождение по воде и семь хлебов или даосское вознесение на небо после соития с 12 сотнями женщин стремительно отваливаются за буйной фантазийностью, а новые (чтобы без каких-нибудь чудес) теории появляются медленно и почти неразличимы в тысячах нетеоретических голосов, говорящих на эту тему. Безусловно, хоуторнские сугубо нерелигиозные эксперименты, а также работы Маслоу и тысяч и тысяч других феноменологов (включая таких "неученых", как самородки-манипуляторы типа Дейла Карнеги) заложили основание для многих и многих движений, включая даже дауншифтинг (сознательный уход от высокооплачиваемых позиций в пользу менее оплачиваемых), и уж конечно массовый фрилансинг, назначение офисом кофеен (массовое, кстати, движение) и прочие странные формы околопредпринимательской деятельности, включая теории "вы займитесь делом, а деньги к вам придут потом" (очень, очень популярное сейчас движение на Западе). Все эти теории якобы обсуждают примат счастья и радости над деньгами. Но это только "якобы". На на самом деле обсуждается свобода выбора способа такого заработка, который был бы совместим с ощущениями свободы и счастья, или наоборот -- свободу выбора такого счастья, которое обеспечивало бы пользу другим людям и связанный с этим неизбежный заработок. Первый этап тут -- это просто освоение мозгами невозможности работы с одной идеей "человека", одной моделью. Второй этап -- это попытки рассуждать одновременно в терминах разных моделей, которые знать друг друга не знают изначально. Третий этап -- это попытки строить разные теории так, чтобы признавать другие теории и предлагать "штатные" стыки с этими другими теориями. Но для этого требуется договориться о методах. Скажем, мизесианцы практически любой спор превращают в спор о методе, о философских основаниях -- и это не случайно. Этот взрыв разнообразия и однообразия в их связности (разнообразия теоретической кроны на базе однообразия в философских корнях) и составляет особенность сегодняшнего момента. Уже мало иметь одну хорошую теорию-"дисциплину", или пяток разных несвязанных между собой теорий, данных через их представителей (вечный поиск "консенсуса" и всякая другая "партисипативность", когда нагоняют всякий несовместный друг с другом народ и пытаются добиться "диалога"). Нужно обеспечить подлинную междисциплинарность: заранее предусмотренную во всех этих теориях уже при их создании возможность межтеоретического диалога. В теориях о счастье давайте покажем, где там стыкуется разговор о деньгах или о юридических практиках. В теориях об организации давайте покажем, где инженерное связано с духовным ростом, которым озабочены люди в организации. Но это очень непросто сделать. Ибо для этого нужно договориться об общем философском основании. Поэтому я ожидаю в ближайшее время прорыва философского эээ... дискурса в самые разные круги, которые им раньше не занимались. В программировании онтологии уже занимают существенное место в промышленных разработках. То же самое будет происходить во всех других отраслях знаний -- просто, как водится, у программистов все методологическое происходит быстрее. В конечном счете -- это человеколюбие, разные теории, разные точки зрения -- это всегда разные интересы, разные люди. Такой подход является основой для практической любви не к одному человеку, а ко многим. Любить тут -- это дать возможность взаимодействовать, обмениваться на всех уровнях (надеюсь, что читатели данного текста "про любовь" не путают агапэ, эрос, филию и сторге и под обменом понимают не только обмен биологическими жидкостями, но и обмен товарами, сервисами, знаниями, навыками и т.д.). |
| 1:26 pm | Пятничное утро Оказывается, livejournal глючит при показе медиа в постинге. Презентация про стандарты описания организаций из моего предыдущего постинга у меня в браузере регулярно заменяется роликом проекта Natal, который я опубликовал еще несколько дней назад. * * * Обзорчик программ для DSM (design structure matrix) со скриншотами: http://puln.livejournal.com/1790.ht Как я понимаю, puln и дальше будет писать на эти темы.* * * Интервью с сэром Tony Hoare (автором Quicksort, Hoare logic, Communication Sequential Processes и вдохновителем языка Occam) -- http://www.infoq.com/interviews/tony-ho Интересные подробности про практику доказательства правильности программ в Microsoft. Очень интересное замечание, что документирование дизайна в инженерии и в программировании существенно различаются: когда строишь мост, должен записать все предположения и расчеты безопасности в надежде, что эти записи никогда не будут востребованы судом по поводу обрушившегося моста, а вот запись предположений и расчетов безопасности для софта еще востребованы, даже если софт так же критичен, как мост. Выход видится в том, что все такое документирование должно делаться специальными программами, которые должны пробовать восстановить по тексту программы такое документирование, а затем использовать его для доказательства правильности программы -- и для софта в последние годы в таком инструментарии прошел значительный прогресс. Статическая или динамическая типизация тут не имеет значения, это в бОльшей мере инженерный, а не научный вопрос: просто для динамических языков проверка делается в ходе выполнения программы, а не перед выполнением, в обмен на гибкость мы получаем более медленное исполнение. Полная для меня неожиданность: он имеет базовое образование в греческих и латинских языках, а компьютерную науку и языки учил в МГУ! И целый год участвовал в проекте по машинному переводу "научного русского" на английский. Первая научная статья Tony Hoare была подана и опубликована в русскоязычном журнале "Машинный перевод", он напечатал ее на русскоязычной пишущей машинке друга. Но ему не давали посмотреть на русские компьютеры, они тогда были секретны! |
| 12:14 am | Про организационную модель и прочие радости жизни Парное программирование и системная инженерия имеют одинаково трудную природу для показа их выгодности: эти наборы практик предотвращают ошибки, а доказать неизбежность ошибок при несоблюдении этих практик невозможно. Новая статья про экономику парного программирования: http://dnicolet1.tripod.com/agile/i * * * Сделали очередной подстрочник семинара -- на этот раз по организационной модели в системной инженерии: * * * Надо бы уже обновить остальные подстрочники: много чего произошло в области русскоязычной терминологии системной инженерии с момента их написания, да и с пониманием немного лучше стало... Про сайт PraxOS я вообще молчу: он отстал от текущей жизни на неприлично сказать сколько. * * * Кролик линяет, и становится из рыжеватого серым. Жена где-то вычитала, что зайцы и кролики отличаются именно этим: зайцы при линьке меняют цвет, а кролики цвета не меняют. То есть у нас таки заяц! Ну, или где-то в интернетах с этими зайцеобразными не-грызунами опять напутали... * * * В Wall Street Journal опубликован (http://online.wsj.com/article/SB124580 Фактически это начинается легитимизация не-токамаковских и нелазерных технологий: авторитет Меткалфа достаточен, чтобы снять с них налет «авантюрности» по сравнению с ITER, NIF и прочим термоядерным официозом. Я ожидаю, что где-то за три-четыре года термоядерный пейзаж существенно поменяется. * * * Очень хочется иметь SPEM 2 composer с диаграммками BPMN 2, возможностью анализа DSM (с точки зрения распутывания чрезмерной связности процессов), а также алгоритмами поиска критической цепи и прочими радостями проектного управления. Пока есть связки либо SPEM-ActivityUML, либо DSM-проектное управление, либо BPMN с остальными организационными моделями, но пересечения миров проектного и процессного (включая процессный issue tracker с его воркфлоу, но и возможностью отслеживать общее продвижение в терминах плана-графика проекта) нигде найти не удается. А надо бы уже что-то в этом направлении предпринять. Правда, как этот оргмодельный самолет взлетит со всеми этими бассейнами и кинозалами, непонятно: это ж сколько производственных пилотов, штурманов, бортмехаников и стюардов его должны обслуживать? Но и без такого инструментария тоже уже непонятно, как делать сложные проекты: условия международных тендеров таковы, что с киркой и какой-то матерью уже такие тендеры и не выиграешь, и не выполнишь. |
| Wednesday, June 24th, 2009 | |
| 8:53 pm | Я язычнег -- хочу учебные (детские) капища Программный (pun intended) получился у нас тред с avlasov про парадигмы языков программирования: http://ailev.livejournal.com/695253.htmЭто новое language workbench (оно же model driven) язычество можно назвать "внутренней школой" -- обсуждается не столько конкретный синтаксис, линеаризация, сериализация, поверхностная структура (ох, сколько в разных словарных сообществах для этого концепта имен!), сколько абстрактный синтаксис, синтаксическое дерево, глубинная структура -- и даже не индивидуальные (модели), а в свою очередь -- их структура, метамодель. Двухуровневое порожденчество: глубинная структура-3 для описания конструкции глубинной структуры-2 абстрактного синтаксиса для глубинной структуры-1 высказывания на языке, предъявляемого как линеаризованная (или графическая) или еще какая, полученная "по правилам разворачивания" структура в конкретном синтаксисе. Ну, или парсинг обратно. Число уровней (только случайно совпадающих с ранними представлениями о числе моделей в MDA ;) произвольно. А деток учить по традиции: внешним проявлениям, затем показывать глубинную структуру на шаг вглубь -- для каждого внешнего проявления свою (парадигмы программирования), затем показывать общность и связь этих парадигм, о которых тоже можно говорить на одном языке (онтология программирования) -- только к этому моменту они уже будут не детки. Кроме взрослых капищ нужны еще и детские. Даешь КуМир с комплектом разнопарадигмальных миров! Ну, и авторам Скрэтча тоже есть над чем подумать в этом плане. Хотя эти-то думают, Пиумарта-то в близком идеологическом родстве с авторами Скрэтча. Но тут печаль: про языковые капища понимает avlasov, но не понимают авторы детских сред программирования. Про детские среды программирования понимают люди, абсолютно не склонные обсуждать разные парадигмы программирования: им и с процедурным стилем весело. А я так вообще другими делами занимаюсь полный рабочий день... |
| 2:08 am | Конец нетбукам. Конец студийной аппаратуре. Конец всему Очаровательная статья Michael Gartenberg про конец нетбуков (http://www.engadget.com/2009/06/23/ent И так повсеместно: в музыкальных кругах небольшой переполох: вышел студийный магнитофон Zoom R16 (http://www.zoom.co.jp/english/produ Следующим шагом кто-то догадается поставить в такой магнитофон карточку Eye-Fi Pro, чтобы уж сразу файлы гнать в компьютер по WiFi и не заморачиваться с USB-кабелем -- http://www.dpreview.com/news/0906/09061 |
| Tuesday, June 23rd, 2009 | |
| 7:31 pm | ГОСТы в свободном доступе Появилось много-много (по слухам даже все) ГОСТов в свободном доступе -- http://walter-simons.livejournal.com/15 Прислали мне эту ссылку позавчера вечером, ко вчерашнему утру я уже откачал 5Gb -- и попытался вчера вечером их развернуть у себя на ноутбуке. После чего и пишу этот пост с предупреждением: а) вы должны осознавать, что после разворачивания у вас появится 20Gb файлов. И этих файлов будет много более 320тыс. (ибо это только отдельных .gif 320тыс., а еще есть несколько десятков тыс. .html-файлов, которые эти .gif и показывают в браузере). Столько файлов для файловой системы ноутбука я счел уж слишком большой нагрузкой. Ужас в том, что я успел уже завести тысяч эдак двадцать файлов, и потом полвечера эти файлы удалял, проверял файловую систему и т.д. -- файловые операции на таких объемах происходят медленно и печально. б) искать вы сможете, только при установке специальной поисковой системы (пары скриптов перла в комплекте поставки, там же база MySQL). Эта встроенная система будет искать только по именам ГОСТов, но не по содержанию. А содержание не индексировано никак. Это означает, что вы будете пользоваться всей этой базой только тогда, когда точно знаете, какой по номеру ГОСТ вам нужен -- и не сможете заглядывать в базу по другим поводам (например, чтобы подглядеть принятую "местными профи" терминологию -- самое частое обращение к каким-то ведомственным текстам). Ну, а тех, кого эти трудности не останавливают -- ссылку на счастье я привел. Еще я долго глядел вчера в какой-то наугад вытащенный старинный ГОСТ про качество стирального порошка: на такую компоненту его качества, как "патентная чистота" (измеряемого какими-то неведомыми аж двумя показателями). И воздействие порошка на "орган обоняния". И вспоминал Козьму Пруткова -- "нельзя объять необъятное", "не ходи по косогору -- сапоги стопчешь" и т.д. Про ОСТы (которых много больше, и которые "дейстуют" до сих пор) я вообще молчу. Тут и у Козьмы Пруткова слов не будет... |