?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Суббота [22 Mar 2008|12:28pm]
Хотел бы попасть на семинар по самоподдерживающимся системам (http://www.swa.hpi.uni-potsdam.de/s3/) -- это которые сами на себе написаны (Squeak/Smalltalk, COLA, Klein/Self, PyPy/Python, Rubinius/Ruby, and Lisp). Ничего личного, просто познакомиться с этими ребятами из VPRI. Но увы -- пока не судьба, весь май я буду в Москве.
* * *
Написал текст на 31Кзнак -- давненько я таких больших не писал, все больше презентациями пробавлялся. Уже и забыл, как еще несколько лет назад регулярно выдавал тексты на более чем 100Кзнаков.

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

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

Когда идете в организацию, не начинайте с бизнес-процессов. Ищите учеты, и задавайте один вопрос: откуда вы берете учетные данные, и зачем они вам нужны. Вы очень быстро найдете при этом настоящие бизнес-процессы, а не формальные отговорки на процессную тему.
* * *
Можно оценить размеры бойкота убиения журналов: из 730 меня френдующих убилось 15, т.е. масштаб акции в "непараллельном ЖЖ" порядка аж 2%. Прогнозы, которые я читал позавчера, указывали бойкотную цифру в 3%. Ну, не такая уж и большая ошибка, погоды стоят предсказанные.

Я считаю, что люди в СУПе -- хозяева-баре и вправе делать все что угодно, если не нарушают своих же публичных обещаний и самоограничений. Но они обещали публично обсуждать грядущие изменения в их политике и сервисе (уже неоднократно обещали) -- и опять ввели изменения без предупреждений и обсуждений. Это не есть хорошо. СУПу двойка за поведение.

Вчера я в ЖЖ не писал (в надежде донести до СУПа мысль о плохом поведении тамошних менеджеров и экспертов), но убивать перманент эккаунт не стал -- кто его знает, как там эта механика работает, и какой эккаунт мне после этого восстановят.
* * *
Выкачал из Сети десяток книжек с http://www.pdfchm.com. Все крайне интересны. Но когда же их читать?!
* * *
Korg M3-73 рулез! Он немеренно крут, невероятно забавен. Крайне рекомендую.
* * *
Подцепил самый свой слабенький сабвуфер к телевизору в спальне. Вау! Все-таки без сабвуфера (даже плохого) жить нельзя.
* * *
Слушать сидишки на хорошей (в моем случае -- профессиональной) аппаратуре и хорошо и плохо. Хорошо, потому что хорошо! Плохо, потому как время от времени музыка сильно отвлекает от работы. Музыка прекращает быть фоном и становится музыкой. Впрочем, это тоже хорошо.

Кстати, Prodigy -- великая группа.
13 comments|post comment

Суперкомпиляторы и суперинтерпретаторы [22 Mar 2008|12:31pm]
Я вот думаю, что современный подход к нейронным сетям (в которых сеть заставляют моделировать объект, а не просто "распознавать") и суперкомпиляторы (в которых делается модель программы, замещающая исходную программу в тот момент, когда результаты их исполнения оказываются эквивалентными) -- это один и тот же подход примата моделирования над преобразованием.

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

Или я неправ -- и теоретически суперкомпайлеры ждет великое будущее?
(ход на то, что после шага развития интерпретаторов обязательно появляются версии компиляторов -- он известен, но для современных сред с суперпоздним связыванием он не дает ответа на мои вопросы)
32 comments|post comment

Паттерн паттерна: дерево стратегии и тактики как патерн-дерево [22 Mar 2008|01:00pm]
Читаю сейчас очередную книжку про паттерны (и их формы -- паттерны описаний паттернов). И вдруг заметил существенное сходство с формой представления дерева стратегии и тактики. Судите сами:

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

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

Забавно, забавно. Нужно будет еще над этим подумать.
* * *
Никак не соберусь сделать апдейт PraxOS.ru, в частности:
-- подправить понятие организационной системы (свести его к фреймворку)
-- подправить набор "мощных идей"
-- и (как я сейчас понял) вернуться к дереву стратегии и тактики и паттерной форме как способу систематического изложения материала

Останавливает меня одно: чем больше я знакомлюсь с разными фреймворками, тем больше меня воротит от той формы, в которой они излагаются. Редкая птица перелетит пару тысяч страниц со скучным изложением какой-то онтологии. Интересно, поможет ли явный переход к форме паттернов/дерева стратегии и тактики хоть как-то решить эту проблему.

Ключ к PraxOS, конечно -- онтологический подход к разным организационным системам (PraxOS как "система систем", выраженная в более абстрактных терминах, небольшое количество "мощных идей", которые адепт PraxOS сможет узнавать в самых различных фреймворках, и поэтому сможет поддерживать разговор с представителями самых разных учений). Главная проблема тут -- это полная (внешняя!) банальность утверждений, произносимых на высоком уровне абстракции. И нечинаемость абстракного текста (включая цитирование не менее абстрактных фреймворков -- типа того же ITIL или PMI PMBoK).

Поэтому нужны какие-то прорывы по форме. А содержание становится все более и более очерчено и понятно.
2 comments|post comment

navigation
[ viewing | March 22nd, 2008 ]
[ go | previous day|next day ]