Журнал Анатолия Левенчука http://blogs.trust.ua/levenchuk/ Анатолий Левенчук :: Журнал Анатолия Левенчука | http://blogs.trust.ua/ Fri, 02 Dec 2011 18:24:53 +0200 Trust.UA Анатолий Левенчук :: Журнал Анатолия Левенчука http://blogs.trust.ua/userpic/1249305522 http://blogs.trust.ua/levenchuk/ 100 100 http://blogs.trust.ua/levenchuk/2011/12/02/1011/Ob-vibori/ Fri, 02 Dec 2011 18:24:53 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/12/02/1011/Ob-vibori/ Об выборы http://kuznetsov.livejournal.com/104425.html, я расхожусь с автором этого текста только в том, что само христианство и прочие мировые религии я считаю тоже язычеством, только версии 2.0).

У меня про выборы только два вопроса, и оба про то, что правды ждать вообще неоткуда:

1. Многие школы в понедельник будут отмываться от выборов -- в буквальном смысле (http://vvagr.livejournal.com/1685393.html). В нашей школе выборов нет, но понедельник таки будет выходым. Вот какую бумажку приклеили дитёнку в дневник: "Уважаемые родители! Во исполнение приказа Департамента образования города Москвы от 22 ноября 2011 года №912 "Об организации образовательного процесса в государственных образовательных учреждениях города Москвы в период ограничительных мероприятий по гриппу и ОРВИ в 2011-2012 учебном году", в соответствии с СП 3.1.2.1319-03, письмом Управления Роспотребнадзора по городу Москве от 21.11.2011 года №17-06-03/615 и приказа начальника управления образования центрального округа В.И.Лопатиной от 24.11.2011 № 1519 информируем Вас о том, что 5 декабря 2011 года (в понедельник) в нашей школе -- "День здоровья", дети не учатся. Учащиеся в этот день пребывают дома, выполняют задания, которые задали учителя на дом, проводят профилактические мероприятия по предупреждению ГРИППА (по усмотрению родителей). Выход в школу -- 06 декабря 2011 года".

Речь, конечно, не о выборах, просто дети должны будут сидеть дома и проводить "профилактические мероприятия по предупреждению ГРИППА (по усмотрению родителей)".

2. В ЖЖ выполнили "принуждение к дню предвыборной тишины". Будут ли продолжать ддосить Живой Журнал и после выборов? Хотя официально выборы тут не при чем, просто чистое хулиганство, никакой политики! ЖЖ, скорее всего, поднимется уже после подсчета голосов -- тоже ведь будет проводить профилактические мероприятия по предупреждению компьютерного ГРИППА (по усмотрению менеджмента). И Коммерсантъ тоже будет сидеть дома лишний день, разве что мы в его случае номера письма и имени чиновника не знаем... ]]> http://blogs.trust.ua/levenchuk/2011/12/02/1011/Ob-vibori/ http://blogs.trust.ua/levenchuk/2011/12/02/1010/Nedelya-obrazovaniya-po-informatike-4-10-dekabrya-2011/ Fri, 02 Dec 2011 16:28:37 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/12/02/1010/Nedelya-obrazovaniya-po-informatike-4-10-dekabrya-2011/ Неделя образования по информатике: 4-10 декабря 2011
К этой неделе делается много полезного и интересного. Вот, например, американский вебсайт этой недели составил список образовательных ресурсов по информатике: http://www.csedweek.org/resources (очень интересный, кстати, список).

Мой личный план в рамках мероприятий этой недели:

1. Приму участие в научно-практическом семинаре "дошкольная алгоритмика". Особо обращу внимание, что в мире дошкольной алгоритмикой вообще мало кто занимается -- это фронтир. Сначала алгоритмике нигде не учили, затем учили только в ВУЗах, затем в старших классах, а теперь уже и в средней школе. Я тут не имею ввиду те задачки "рассортируй птичек и рыбок на две кучки" и "какой предмет лишний на этой картинке", которые сейчас выдают за информатику для младшеклассников. Я тут имею ввиду написание настоящих программ, в которых есть и циклы, и условия, и подпрограммы с параметрами. Так что это будет вполне себе фронтир. Кстати, я в 2009г. уже писал про Михаила Долинского и его школу программирования для младшешкольников со слоганом "программировать раньше, чем читать!" -- они вполне себе работают, и тоже тем самым находятся на фронтире: http://dl.gsu.by/NForum/forum/list/16.dl

2. Буду заниматься с собственным сыном-третьеклассником -- на сегодня осталась последняя задача 14 урока, а на "образовательной неделе" начнем решать задачи 15 урока курса http://server.179.ru/wiki/?page=DenisKirienko/Kumir

3. Сделаю постинг о том, как учить премудростям ISO 15926, это ведь тоже информатика. ]]> http://blogs.trust.ua/levenchuk/2011/12/02/1010/Nedelya-obrazovaniya-po-informatike-4-10-dekabrya-2011/ http://blogs.trust.ua/levenchuk/2011/12/02/1009/Pro-ECM-i-PLM-a-takje-pyatoe-pokolenie-injenernih-informacionnih-sistem/ Fri, 02 Dec 2011 08:45:18 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/12/02/1009/Pro-ECM-i-PLM-a-takje-pyatoe-pokolenie-injenernih-informacionnih-sistem/ Про ECM и PLM, а также пятое поколение инженерных информационных систем [info]ttfna в треде http://ailev.livejournal.com/965124.html?thread=9717252#t9717252 к моему постингу про четыре поколения перехода от документ-центричности к датацентричности. Получилось много, и в коммент не поместилось. Собственно, я всё это уже в разное время у себя в ЖЖ писал -- разве что разноски по поколениям не делал.

1. Многие современные как гибридные, так и датацентричные PLM (системы product lifecycle management) используют всё то же самое, что ECM (enterprise content management), по факту используемые в крутой документоцентрике -- наличие "объектов" в них не является критерием отличия. Я бы сравнивал современные ECM с более ранними PDM (product data management) системами, где самое важное было как-то управляться с многочисленными файлами разной природы -- понимая при этом, что физическое представление "файла" не так важно, как его "объектная" сущность и поэтому собственно работа ведется с "карточками" этих файлов -- а сами эти карточки вполне себе "объекты".

2. Как в ECM и PDM, любые современные PLM имеют какой-нибудь item с атрибутами и associations/relations этих items в основе, поддерживающая наследование и прочие прелести объект-атрибутной модели. Никакой предметной области нет, кроме просто развитой работы с данными. Эта объект-атрибутная модель опирается на какую-нибудь реляционку под ними -- все они "нашлёпки" над каким-нибудь Ораклом.

3. Но далее в PLM уже над items строится некоторая (у кого более богатая, у кого менее богатая) онтология, которая подразумевает мэппинг структур данных на объекты реального мира: фишка не в том, что довольно быстро в этой модели мира мы выходим на "оборудование", важное для PLM, а в том, что сама эта модель мира начинается с thing (почувствуйте разницу с item!) и принципиально расширяема в этой описывающей мир, а не описывающей структуры данных части -- причем "из коробки". В отличие от ECM настройка на предметную область производится не только разработчиками "плагинов" (это тоже есть), но и предварительно в PLM существует уже некоторая связная модель инженерного мира.

4. В этих PLM опять же "из коробки" даны слитые воедино модели данных/онтологии разнопредментых authoring tools, это нормальный стиль. Эти разные модели данных принципиально сливаются в одну модель данных, что гарантируется общей онтологией, а не общей схемой данных из items и relations.

5. Эта архитектура была выработана после того, как выяснилось, что работа с plugins как в ECM (это было в ходе разработки стандарта STEP, закончившейся не "единым языком инжиниринга", как предполагалось, а кучей application protocols для разных предметных областей) не гарантирует, что модели данных всех эти plugins сольются в одно красивое целое -- если при этом не основывать все эти предметные модели данных на беспредметной общемировой (еще раз повторюсь: "беспредметная модель данных" моделирует мир -- вещи, время, пространство, отношения, свойства, атомы, молекулы, живое-неживое и т.д., что нельзя путать с абсолютно другой природы айтемами, записями, атрибутами, объектами и прочими формализмами данных).

6. Конечно, уже начинаются интересные примеры, как из разных ECM пытаются делать PLM: для этого берут огромного размера рашпиль и доводят более-менее удачную ECM до состояния PLM -- например, это произошло с MatrixOne и Enterprise Bridge после их приобретения разработчиками САПР. Но это переход в уже другой класс систем, и фишка в существенной доработке модели данных -- т.е. огромный объем программирования как раз в терминах этих айтемов и записей, но этот объем программирования выполняется еще до всяких там "плагинов", как раз для того, чтобы потом данные самых разных заранее даже неизвестных еще плагинов слились в одну информационную модель. Это совсем другой стиль, нежели обычная работа с плагинами в ECM.

7. Именно необходимость объединять данные разных предметных областей и authoring tools ставит запрет на использование объект-атрибутной модели: что для одного authoring tool объект, для другого authoring tool атрибут. Отсюда и переход к факт-ориентированной модели, в которой все те же фрагменты мира выражаются в формализме классов (теории множеств), а не в субстанциональной аристотелевской парадигме объектов-свойств.

8. Люди из мира PLM, естественно, знают про происходящее в мире ECM, идиотов-то сейчас нет. Другое дело, что они когда-то сами таким занимались -- но ввиду много бОльшей сложности их задач они пошли дальше.

9. Масла в огонь подливает то, что ECM и связанный с ними MDM обычно внутрикорпоративны, а вот для PLM обычно данные и справочные данные должны быть отраслевыми -- проекты выходят далеко за границы любой инжиниринговой компании, и с самого начала архитектура и способы работы должны поддерживать работу комьюнити. Именно поэтому ISO 15926 сразу подразумевает для интеграции данных использование федерации библиотек справочных данных, а не "корпоративное решение MDM".

10. Файл, конечно, не эпицентр современных ECM -- но так уж получается. То есть потенциально современные ECM могут быть использованы не как средства второго поколения (где главное -- это обеспечивать ссылки на файлы из паутины классификаторов), а средства третьего поколения (где главное -- это поддержание модели предметной области, из которой уже и идут ссылки на "первичку"). Но модели предметной области, где задействованы ECM получаются жидковаты. Мы в 1998 году затеяли разработку онтологического движка Communiware, это как раз была попытка сделать ECM с отрывом от файлов -- ибо мы целились на рынок интернетов и интранетов, где важны были не столько файлы, сколько статьи, постинги, комментарии, рубрики и прочие нехитрые предметные сущности. Мы сделали онтологический движок, и на нём нехитрую обобщенную модель того самого веб-контента. На этой совсем нехитрой модели всё и закончилось, ибо при выходе на хитрые модели потребовалось бы принимать абсолютно другие архитектурные и онтологические решения. На этом же заканчивается сейчас "семантик веб": множество нехитрых онтологических моделей отнюдь не слипаются в полноценную хитрую модель куска реальности. Финансовые модели мира -- при всём к ним уважении -- оказываются много менее хитрыми, нежели модели продукции, достаточные инженерам для производства. Инженерам потребовалось двадцать лет для осознания этого факта неслипания их моделей данных в ходе работы разных консорциумов и групп по стандартизации (прежде всего -- консорциума EPISTLE) и необходимости поэтому использования какой-то общей верхнеуровневой онтологии для разных authoring tools.

11. Итого: ECM обычно относятся ко второму поколению крутой датацентрики, ибо несмотря на всю их пригодность к вышиванию на них крестиком сложных моделей данных никто этого не делает. PLM как раз "из коробки" содержат весьма сложные схемы данных инжиниринга, и поэтому относятся к третьему (гибридному) и четвертому (датацентрическому) поколениям.

12. Я ожидаю, что пятое поколение -- это будет про федерацию датацентричных систем. ]]> http://blogs.trust.ua/levenchuk/2011/12/02/1009/Pro-ECM-i-PLM-a-takje-pyatoe-pokolenie-injenernih-informacionnih-sistem/ http://blogs.trust.ua/levenchuk/2011/11/30/1008/Chetire-pokoleniya-informacionnih-sistem-dlya-injenernih-proektov/ Wed, 30 Nov 2011 21:17:32 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/30/1008/Chetire-pokoleniya-informacionnih-sistem-dlya-injenernih-proektov/ Четыре поколения информационных систем для инженерных проектов
1. Электронная бумага. Бумажная бумага в ассортименте форматов, растровые сканы документов (хорошо, если .pdf -- но часто бывают и .tiff), штрих-коды на бумаге как высшее достижение цивилизации, в компьютерах реестры документов, попытки распознавать сканы обламываются на том, что бывают самые разные authoring tools кроме Ворда -- хотя я слышал, что уже некоторые типы чертежей тоже умудряются распознавать. Все ругают такие системы, все от них избавляются. Это наше радостное настоящее.

2. Электронный инженерный документооборот. Документ -- это всегда электронный документ в формате authoring tool. Если это чертеж, то это электронный чертеж со всеми связями и атрибутами. Если это текст, то это вордовый документ. Если это P&ID диаграмма, то это она. В проекте много-много таких документов. Документ = файл. Система хвастается, что ей все форматы нипочём, и в ней есть смотрелки для всех форматов. Ведет "любое количество классификаторов для любого числа типов документов". Документоцентрика в чистом виде, апофеоз и апофигей. Это то, что многие "внедряют" прямо сейчас -- светлое завтра сегодняшних проектов.

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

4. Датацентричные системы. Намаявшись со своими гибридами, некоторые разработчики PLM сделали страшное: они объявили базу данных информационной модели "первичкой", потребовали перевязанности всей информационной модели разных authoring tools с самого начала и на этом основании заставили работать authoring tools прямо с общей для всех базой данных (а не каждый со своей собственной, как в предыдущих поколениях). Это означало резкий отход от привычных форм работы: документы стали выписками, они привязывались к информационной модели (первичке), а не информационная модель привязывалась к ним. Недостатки этой архитектуры являются продолжением достоинств: привыкшие к документам люди страшно теряются -- в базе данных нет листов, томов, к ней неприменимы ГОСТы документоориентированной разработки, в полной растерянности ориентированные на документы технадзоры (хотя им выгружают тонну выписок -- и они тоже становятся довольны), трудно юридически обосновывать "кому сидеть", невозможно цеплять authoring tools старых поколений -- ведь они тоже документоориентированы! Это не вполне еще отлаженное будущее сейчас осваивают только "лидеры рынка", а остальные в благоговейном ужасе к нему готовятся -- от датацентрической судьбы-то не уйдешь, гони ее сегодня хоть в дверь, она завтра всё одно влетит в окно.

У меня ко всему этому только одна претензия: не нужно гибридным системам говорить о том, что они полностью датацентричны, а электронному инженерному документообороту произносить какие-то слова про ISO 15926. Каждый сверчок пусть знает свой шесток. Управление технологиями должно происходить осознанно -- при всём понимании, что лучшая система предыдущего поколения может оказаться лучше и худшей системы следующего поколения по огромному числу характеристик. Но вот лучшие системы этих поколений обычно и сравнить-то уже нельзя, разница очевидна -- если, конечно, знаешь на что смотреть. ]]> http://blogs.trust.ua/levenchuk/2011/11/30/1008/Chetire-pokoleniya-informacionnih-sistem-dlya-injenernih-proektov/ http://blogs.trust.ua/levenchuk/2011/11/30/1007/nikel-plus-vodorod/ Wed, 30 Nov 2011 19:52:15 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/30/1007/nikel-plus-vodorod/ никель плюс водород
Сегодня очередная серия этой эпопеи: Дефкалион раскрыла спецификацию своего продукта, который обещают выпустить на рынок в 2012г. -- http://www.defkalion-energy.com/files/Press_Release_30Nov2011_Praxen_Defkalion_Green_Technologies.pdf

Мне даже неинтересно, что будет с энергетикой, если всё это окажется не шарлатанством. Мне интересно, что будет со всем остальным миром, если разберутся с физикой подобного рода явлений. 2012 года, думаю, будет вполне достаточно, чтобы любые мистификации были развеяны -- а пока эти новости читать явно интересней научной фантастики и приключений, так что я буду доволен любым исходом дела. Но инвесторам в любую энергетику сейчас трудно определяться, я им не завидую ;-) ]]> http://blogs.trust.ua/levenchuk/2011/11/30/1007/nikel-plus-vodorod/ http://blogs.trust.ua/levenchuk/2011/11/30/1006/livIejournal/ Wed, 30 Nov 2011 18:27:25 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/30/1006/livIejournal/ livIejournal http://blogs.yandex.ru/search.xml?text=%22liviejournal%22 -- а сейчас уже много. И хоть бы кто написал, как лечить. Рестартом моей мозиллы это почему-то не лечится...

UPDATE: понятно, что произошло -- спамовый коммент, в нем фрагмент кода.
UPDATE2: как-то самовылечилось -- даже не понимаю, от каких моих действий... ]]> http://blogs.trust.ua/levenchuk/2011/11/30/1006/livIejournal/ http://blogs.trust.ua/levenchuk/2011/11/28/1005/Arhimeit-po-russki-podstrochnik-seminara/ Mon, 28 Nov 2011 21:38:13 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/28/1005/Arhimeit-po-russki-podstrochnik-seminara/ Архимейт по-русски: подстрочник семинара
Архимейт по-русски
]]> http://blogs.trust.ua/levenchuk/2011/11/28/1005/Arhimeit-po-russki-podstrochnik-seminara/ http://blogs.trust.ua/levenchuk/2011/11/27/1004/Na-sleduushei-nedele-opyat-NN-zatem-seminar/ Sun, 27 Nov 2011 10:29:46 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/27/1004/Na-sleduushei-nedele-opyat-NN-zatem-seminar/ На следующей неделе: опять НН, затем семинар
Системная инженерия и ISO 15926
]]> http://blogs.trust.ua/levenchuk/2011/11/27/1004/Na-sleduushei-nedele-opyat-NN-zatem-seminar/ http://blogs.trust.ua/levenchuk/2011/11/25/1003/Partiinost-poiskovih-sistem/ Fri, 25 Nov 2011 22:30:16 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/25/1003/Partiinost-poiskovih-sistem/ Партийность поисковых систем
Это у Яндекса бага или фича? ]]> http://blogs.trust.ua/levenchuk/2011/11/25/1003/Partiinost-poiskovih-sistem/ http://blogs.trust.ua/levenchuk/2011/11/25/1002/Sistemi-podderjki-kollektivnoi-raboti-protiv-sistem-podderjki-oformleniya-rezultatov-rabot/ Fri, 25 Nov 2011 14:24:30 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/25/1002/Sistemi-podderjki-kollektivnoi-raboti-protiv-sistem-podderjki-oformleniya-rezultatov-rabot/ Системы поддержки коллективной работы против систем поддержки оформления результатов работ
Вот только несколько примеров из моей практики:

1. Обычно правление крупных компаний разделяется примерно поровну, когда я задаю ключевой вопрос по выбору системы документооборота: вам нужно, чтобы всегда формально знать, кто виноват -- или вам нужно обеспечить продуктивную работу? В первом случае вам нужна именно система документооборота, и она автоматически попадает в ведение канцелярии, которая драконовски нагибает всех на выполнение ГОСТов делопроизводства. Во втором случае вам нужно ставить issue tracker (самая распространенная форма groupware для промышленной коллаборации -- предыдущее поколение адаптивного управления кейсами). В первом случае у вас всё будет юридически корректно задокументировано, и соблюдены все регламенты. Во втором случае работа будет идти не столько по регламентам (хотя и это возможно), сколько по уму -- ибо отнюдь не вся работа умещается в регламенты.

Обращу особое внимание, что даже не все знают про использование issue trackers как систем управления процессами -- а ведь они не только могут выполнять пересылки и уведомления, определенные в design time, но и делать то же самое в runtime (да еще и хитрыми способами -- не только push, но и подписками/pull). Новые поколения issue trackers интегрируются с wiki, системами управления конфигурацией/ведения версий (в случае САПР такое объединение называется PLM-системой), системами проектного управления и учета времени и т.д.. Но это не канцелярский документооборот, которого не интересует содержательное решение вопроса (и тем самым привлечение к issue/case самых разных людей, итерации, эксперименты, дополнительные совещания и прочее, что не отражено ни в одном регламенте), а интересуют только предписанные в design time визы.

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

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

3. Обсуждение ППР (плана производства работ) сооружения, получаемого по технологии Multi-D на последнем заседании Русского отделения INCOSE (http://incose-ru.livejournal.com/31246.html). Как и в предыдущих случаях, столкнулись два разных рассмотрения: административно-бюрократически речь идет о разработке ППР как документа со многими подписями, а потом внесение в этот ППР четко согласованных изменений (полагающихся готовыми к тому моменту, когда их начнут согласовывать). Но ведь есть и содержательное инженерное рассмотрение, при которой ППР сначала разрабатывается, а потом непрерывно приводится в соответствие с жизнью. Эти два взгляда вполне совместимы, если непрерывно актуализируемая модель производства работ время от времени выплёвывает бюрократам выписки, которые они затем утверждают в полном соответствии с их старинными бюрократическими правилами бумажной работы. Бюрократов ведь не волнует, из какого сора получаются те документы, которые они потом согласуют -- а инженеров как раз интересует поддержка способа, которым они эти документы для согласования производят. Ибо нет способа -- нечего оказывается и согласовывать. Ужас в том, что ход получения начального согласовываемого документа в знаниевой работе чрезвычайно похож на согласование и редактирование в ходе согласования -- но айтишники не поддерживают общение инженеров, они поддерживают только общение инженеров с начальниками.

Недаром одной из причин сохранения "бумаги" называют трудности в определении того, "кто будет сидеть" за допущенные при актуализации модели ошибки. С другой стороны, сама работа по актуализации модели и выработке тех самых "изменений к ППР" вообще не попадает в рассмотрение, для нее не рассматриваются "процессы" (ведь там не столько привычные "согласования", сколько просто содержательная и довольно разнообразная работа, плохо поддающаяся "процессному подходу" в его классическом варианте) и коллаборация в этой работе фактически не будет поддержана ничем, кроме электронной почты. ]]> http://blogs.trust.ua/levenchuk/2011/11/25/1002/Sistemi-podderjki-kollektivnoi-raboti-protiv-sistem-podderjki-oformleniya-rezultatov-rabot/ http://blogs.trust.ua/levenchuk/2011/11/24/1001/Arhimeit-po-russki-relsi-dlya-mishleniya/ Thu, 24 Nov 2011 21:03:39 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/24/1001/Arhimeit-po-russki-relsi-dlya-mishleniya/ Архимейт по-русски: рельсы для мышления
Архитектор не гроссмейстер -- он не умеет играть без доски, он использует диаграммы, чтобы смотреть на них и думать. Тем самым работа его двухтактна: писать диаграммы и затем читать их. Эти диаграммы для него -- "экзокортекс", продолжение его мозга, участвующее в размышлении. Он думает, ставя перед собой (или перед другими -- если организуемое им размышление коллективное) вопросы, появляющиеся от соприкосновения формализма Архимейта с неформально устроенной жизнью предприятия. Тут неважно, это только проектируемая будущая жизнь, или реальная уже идущая жизнь (всё одно мы и об одной, и о другой узнаём только то, что думают об этой жизни люди, а не то, что было или есть "на самом деле"). Мысль -- диаграмма -- вопрос -- мысль.

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

Механизм типов подразумевает задание главным образом одного простого вопроса, ответ на который обычно очень сложно получить. Для каждого встречающегося в жизни объекта спросите "что это?!", "часть чего это?", "с чем это связано?". Подберите тип Архимейта. Получите удовольствие: до вас мало кто задумывался, "что это". Ответ на этот вопрос может оказаться очень нетривиальным, а получение этого ответа заставит задать десятки других вопросов.

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

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

Моделирование идет циклически: поглядел на жизнь и что-то про нее понял, затем записал понятое на диаграмме. Поглядел на диаграмму -- нашел ошибки. Поглядел на жизнь -- исправил ошибки в диаграмме. Поглядел на диаграмму -- понял что-то про жизнь. Записал понятое на диаграмме -- и опять начал искать ошибки. Результат такого процесса довольно неожиданный: архитектор вдруг начинает что-то понимать про жизнь предприятия едва ли не глубже, чем непосредственно участвующие в деятельности люди. Архитектор находит в действующих предприятиях бессмысленные работы (activity, кстати, рекомендую переводить как "работы" -- родовой термин для всех вариантов поведений), странные группировки объектов деятельности, лишних деятелей. Он же находит их в проектах предприятий -- как своих проектах, так и в проектах других людей. Формализм Архимейта заставляет продумывать то, что прошло бы мимо внимания. Ошибки и трудности моделирования являются теми ниточками, с которых можно начинать распутывание запутанного клубка деятельности предприятия -- и Архимейт в изобилии поставляет такие ниточки.

Особенностью моделирования на Архимейте является его кажущаяся аскетичность. Моделирование делается намеренно неподробно (при всех заявлениях, что "при потребности вы сможете выразить все нужные детали). Типов объектов и отношений в Архимейте намеренно мало, авторы заявляют что сознательно пошли на удовлетворение только 20% потребностей архитекторов в выразительных средствах (эти 20% покрывают 80% всех случаев, а остальные 80% "выразительности" ушли бы на оставшиеся 20% случаев -- эти "остальные выразительности" просто убрали из языка). Но вся эта неподробность и аскетичность кажущаяся. Архимейт заставляет писать суть дела -- как бы банально и просто эта суть ни выглядела на диаграмме. И -- чудо, чудо -- эта банальная суть дела всегда вызывает много банальных вопросов как к жизни, так и к диаграмме. Архимейт создан так, чтобы задавать правильные вопросы. Ответы на эти вопросы почему-то оказываются небанальными, и в этом главная сила Архимейта.

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

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

Удобная графическая нотация является при этом только бонусом, секрет успеха вовсе не в ней. Секрет именно в типах объектов и отношений Архимейта, предлагаемых соглашениях об именовании и декларируемом соответствии формальных моделей Архимейта замыслу предприятия или реальному предприятию -- и тех вопросах, которые эти типы, имена и отражение реальности моделью задают архитектору. ]]> http://blogs.trust.ua/levenchuk/2011/11/24/1001/Arhimeit-po-russki-relsi-dlya-mishleniya/ http://blogs.trust.ua/levenchuk/2011/11/23/1000/Arhimeit-po-russki-oshibki-nachinaushih/ Wed, 23 Nov 2011 11:23:14 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/23/1000/Arhimeit-po-russki-oshibki-nachinaushih/ Архимейт по-русски: ошибки начинающих как нужно -- и не предупреждается, как не нужно моделировать. Так что я приведу тут несколько наиболее распространенных ошибок, которые делают новички. Считайте, что это своеобразный чеклист: проверяйте, есть ли эти ошибки на ваших и чужих диаграммах.

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

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

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

Одноуровневости отображения уровня оборудования в Архимейте почти не бывает, но все учебники и блоги практикующих архитекторов предупреждают о пагубности игнорирования этого уровня. Более того, они советуют моделировать оборудование и системный софт довольно детально.

Почему важно отображение всех этих уровней одновременно? Потому что вам придется отвечать на очень и очень неудобные вопросы про несоответствие деятельности, обработки данных и оборудования. Ибо на диаграммах это несоответствие становится хорошо видным и самые разные люди начинают задавать самые разные вопросы. Отвечать на эти вопросы архитектурными решениями (менять диаграммы с "as is" на "to be", а затем планировать работы по переходу к "to be") -- это и есть работа архитектора предприятия.

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

Первая из ошибок, которую делают новички -- это попытка использовать "продукт" (product) вместо "объекта деятельности" (business object). Самое маленькое следствие этой ошибки -- это отказ редактора диаграмм прописывать необходимые отношения. Реакция на это архитектора-новичка: "ваш софт сломался". Ещё бы! Продукт в Архимейте -- это набор сервисов и контракт. То есть продукт в Архимейте -- это по сути поведение (сервисы), а не структура! Это не "чугунная чушка", а "поставка и обслуживание чугунной чушки", это не "кредит", а "предоставление кредита".

Любой кусок архитектуры зачем-то нужен -- деятельность обслуживает (service) каких-то клиентов, обработка данных обслуживает (service) деятельность и другую обработку данных, оборудование обслуживает (service) обработку данных и другое оборудование. Явное указание сервисов заставляет трижды подумать, зачем нужен тот или иной кусок предприятия -- и результаты этого размышления часто бывают нетривиальны и заставляют менять архитектуру (а потом менять предприятие в соответствии с этими изменениями архитектуры).

Большинство новичков-архитекторов вообще не использует сервисов на диаграммах, что строго противоречит подходу Архимейта. Отсутствие явно прописанных сервисов верный знак, что в голове архитектора нет разделения на "внутренний-внешний", то есть его архитектура несистемна (не в терминах систем), немодульна -- со всеми негативными последствиями (модуль-подсистема отличается прежде всего тем, что его можно заменить, не трогая всю целевую систему. Модульная архитектура позволяет заменять "внутреннее", не меняя "внешнего" и поддерживать такой стиль мышления, поощряющий замену реализаций по мере получения новой информации и открытия новых возможностей. Если использовать сервисы, то можно легко заменить архитектуру IT-решения, не меняя деятельности, можно заменить одно интеграционное решение на другое, не меняя всей архитектуры IT-решения, можно заменить оборудование, не меняя обработки данных, можно добавить еще пару-тройку каналов предоставления сервиса и т.д.). Если не использовать сервисы, то такие замены очень трудно сформулировать и выделить из паутины объектов и отношений полной архитектуры.

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

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

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

Удаление элемента происходит либо из полного описания (в Archi это delete from model), либо только из группы описаний (delete from view). Если вы случайно удалили элемент из архитектурной модели, то вам нужно его завести на диаграмме этой группы описаний заново, "с нуля". Если вы случайно удалили элемент из группы описаний, то вам его нужно вытащить из модели на полное описание -- создание с нуля как раз и породит дублирование.

Элементы дерева модели, которые в Archi даны курсивом, означают такие элементы, которые просто не были выведены ни в одной из тематических групп описаний. Но они не удалены из модели! Их просто отфильтровали из всех диаграмм. Новичкам к такому поведению редактора нужно привыкнуть, но пока этой привычки не появилось, управление конфигурацией вашим архитектурным проектом по мере его разрастания будет проблематичным.

4. Новички (которым к этому моменту обычно промыли мозги "процессным подходом") начинают архитектурную работу с выявления (или придумывания) процессов. Как ни странно, это ошибка (см., например,http://ailev.livejournal.com/867599.html). Начинать всегда нужно с элементов пассивной структуры и предоставляемых сервисов. Процессы появляются потом, когда вы понимаете, что вам нужно делать с пассивной структурой, чтобы добиться полезной работы сервиса.

И только в самую последнюю очередь нужно прописывать элементы активной структуры (когда деятельность понятна, можно кого-нибудь назначить на ее выполнение -- а не придумывать деятельность под известного вам исполнителя). ]]> http://blogs.trust.ua/levenchuk/2011/11/23/1000/Arhimeit-po-russki-oshibki-nachinaushih/ http://blogs.trust.ua/levenchuk/2011/11/21/999/Skoro-skoro-Novii-God/ Mon, 21 Nov 2011 22:16:39 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/21/999/Skoro-skoro-Novii-God/ Скоро, скоро Новый Год
Если в этом году всё так рано начинается, то страшно представить, какой разгул веселья будет к середине декабря. Схватка Деда Мороза с Дедом Лайном в этом году будет явно нешуточной. ]]> http://blogs.trust.ua/levenchuk/2011/11/21/999/Skoro-skoro-Novii-God/ http://blogs.trust.ua/levenchuk/2011/11/21/998/Kak-opisivat-informacionnie-modeli-krupnih-injenernih-obektov/ Mon, 21 Nov 2011 22:07:07 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/21/998/Kak-opisivat-informacionnie-modeli-krupnih-injenernih-obektov/ Как описывать информационные модели крупных инженерных объектов
2. Модели данных информационных моделей (пардон за каламбур) описываются на трех уровнях абстракции:
-- архитектурном
-- концептуальном (нейтральном)
-- прикладном (логическо-физической реализации прикладным софтом)

3. Описание архитектурного уровня выполняется в подходе Архимейт, группа описаний информационной структуры (http://ailev.livejournal.com/955954.html). Целью архитектурного описания информационной модели является представить крупные блоки модели, выразить их связь с объектами деятельности и дать понимание о том, какие прикладные системы используются для их хранения. Архитектурное описание в свою очередь разбивается на три уровня абстракции (в соответствии с подходом Архимейт, ):

А) на уровне деятельности архитектурного описания перечисляются объекты моделирования (в том числе и intangible – типа «прибыль» или «сейсмостойкость»). Это «та целевая система, которую моделирует система-модель».

Б) на уровне данных архитектурного описания перечисляются концептуальные (предметные) наборы данных концептуальной (нейтральной) модели, соответствующие микротеориям моделирования предметной области (термин "микротеория" был предложен сначала людьми из CYC, а сейчас по факту принят всеми онтологами). Модель данных для этих наборов данных на архитектурном уровне абстракции не моделируется – она будет детализироваться на концептуальном (нейтральном) уровне абстракции

В) на уровне оборудования архитектурного описания перечисляются варианты реализации наборы данных прикладного уровня полного описания, модель данных которых будет описана на прикладном уровне.

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

5. Прикладной уровень (логически-физической реализации) полного описания представляет собой описание мэппинга из концептуальной (нейтральной, ISO 15926) модели данных в конкретную (логическую) модель данных информационной системы, выбранной для (физического) хранения информационной модели (хранения данных информационной модели). Тем самым описание прикладного уровня зависит технологии реализации мэппинга к нейтральной модели (.15926, XMpLant, Iring и т.д.). Важно, что на прикладном уровне описания каждый элемент модели данных прикладной системы привязывается путем мэппинга к элементу модели данных концептуального уровня.

6. Основные проблемы приведенного подхода, требующие дополнительных исследований:
-- как представлять связи между элементами разных уровней описания (онтология информатики в части представления мета-отношений весьма неразработана)
-- как представлять микротеории (проблема модульности моделей данных, онтологий)
-- как объяснять необходимость двойного детального описания (в терминах концептуального описания и в терминах конкретной системы хранения, да еще и мэппинг). Тут могут быть самые разные отговорки, в том числе большой соблазн в качестве "нейтрального" уровня описания выбрать формализм доминирующей системы хранения. ]]> http://blogs.trust.ua/levenchuk/2011/11/21/998/Kak-opisivat-informacionnie-modeli-krupnih-injenernih-obektov/ http://blogs.trust.ua/levenchuk/2011/11/18/997/Vremya-obnarujeniya-sobitiya-protiv-realnogo-vremeni-sobitiya----mir-glazami-jurnalistov/ Fri, 18 Nov 2011 09:05:30 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/18/997/Vremya-obnarujeniya-sobitiya-protiv-realnogo-vremeni-sobitiya----mir-glazami-jurnalistov/ Время обнаружения события против реального времени события -- мир глазами журналистов
Или вот сегодняшнее "У обвиняемого в его убийстве наметился мотив преступления" в Коммерсанте. У обвиняемого мотив был еще в момент преступления, он вовсе не наметился у него в момент обнаружения его следователями!

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

Мне кажется, что еще лет десять назад такого словоупотребления не было. Но сегодня "упавшие деревья" и "жертвы" -- это уже не про сами деревья и жертвы, а строчки о них в чьих-то отчётах. Изменение этих строчек и есть "реальные события" в головах журналистов, а их речь это честно отражает. ]]> http://blogs.trust.ua/levenchuk/2011/11/18/997/Vremya-obnarujeniya-sobitiya-protiv-realnogo-vremeni-sobitiya----mir-glazami-jurnalistov/ http://blogs.trust.ua/levenchuk/2011/11/17/996/Perspektivi-mobilnih-servisov/ Thu, 17 Nov 2011 22:49:08 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/17/996/Perspektivi-mobilnih-servisov/ Перспективы мобильных сервисов http://vasforum.ru/win/vas-agend.html), но в компенсацию обещал написать тут несколько замеченных мной трендов в этой сфере. На написание этой заметки я наверняка потрачу времени не меньше, чем на доклад в тамошнем формате -- зато сколько сэкономлю времени в поездах! Это, наверное, символично для конференции по мобильным сервисам:

1. Лет пять назад много писали статей о "нательной компьютерной сети" -- и она таки штатно появилась отнюдь не в форме bluetooth (как многие ожидали, наблюдая за всякими bluetooth-гарнитурами), а в форме internet tethering ("раздача интернета") через полноценное WiFi соединение: мобильные телефоны Android начиная с версии 2.3 это умеют делать "из коробки", а пользуются этой раздачей планшеты. Поскольку иметь множество симок и связанных с ними хлопот никому неинтересно, то очень много людей пользуются именно таким "нательным интернетом" из кармана в руки (от телефона к планшету) -- а рынок на это реагирует выпуском планшетов только с WiFi и отсутствием самостоятельных WWAN возможностей.

2. В отчёте за пятый год STEPS утверждается, что код -- это просто еще один тип медиа (http://ailev.livejournal.com/960827.html), имея ввиду, что фрагменты с кодом вверстываются в страницу примерно так же, как видеоролики и "проигрываются" интерпретатором примерно так же, как плеер проигрывает те же видеоролики или аудиофайлы. Но есть и еще один аспект: покупать и продавать код можно так же, как и любые другие медиа -- газеты, книжки, видео и аудио. И пиратится код примерно так же. Поэтому application store является просто расширением всяческих iTunes. А поскольку простых и сложных программных кодов можно написать примерно столько же, сколько простых и сложных книжек, или снять малобюджетных или крупнобюджетных фильмов -- то можно считать, что началась эра Гутенберга-2. Человечество до этого изготавливало коды чуть ли не вручную, и распространяло их неудобным образом, а appstore произвел тут революцию примерно такую же, как печатный пресс: ранее малодоступное стало массово доступным. Про цены и бизнес-модели я молчу, ибо история тут только-только начинается (так, "продажи внутри приложений" уже существенно меняют жизнь).

Спросите: что же тут нового? Отвечу: эти куски кода из независимых должны становиться общающимися между собой -- мечта о "верстке приложений" случится именно на планшетах, ибо на телефонах для верстки места маловато, а на компьютерах пока нет appstore и необходимой для возникновения удобоваримых стандартов верстки массовости и стандартности.

3. Может ожить идея edutainment. Все огромные вливания в чрезвычайно модное лет десять назад "образование-и-развлечение" оказались пшиком, но пшиком была и идея Apple Newton. Технологии подросли, и "наладонные компьютеры" были уже не пшиком, а планшеты стали вообще хитом. С появлением application store и дОлжного уровня технологий идея edutainment вполне может воскреснуть: достаточно поглядеть, как планшет легко вступил в соревнование с игровыми консолями -- технология оказалась более чем развлекательной, а надлежащий нишевый контент можно будет придумать за счет демократичности appstore.

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

5. Применение мобильных устройств может быть неожиданно большим в составе роботов. Роботы присутствия уже вовсю используют планшеты (на них отображается морда лица присутствующего). Но вот своему дитенку я объяснял, что после окончания курса с нарисованным роботом я куплю ему Lego NXT 2.0, а потом добавлю к этому Lego телефон -- сразу прихватив в состав дешевого крохотного робота гироскопы, датчики ускорения, вайфай, видеокамеру, более мощный компьютер и память, громкий динамик и качественный микрофон -- да еще и экран вдобавок. Роботов хороших и разных будет больше и больше, и часть мобильных сервисов очень скоро будет уже не для людей, а для роботов. ]]> http://blogs.trust.ua/levenchuk/2011/11/17/996/Perspektivi-mobilnih-servisov/ http://blogs.trust.ua/levenchuk/2011/11/14/995/Sistemnaya-injeneriya-v-sovremennoi-Rossii/ Mon, 14 Nov 2011 16:41:49 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/14/995/Sistemnaya-injeneriya-v-sovremennoi-Rossii/ Системная инженерия в современной России


Я сам не слишком хорошо отношусь к военной системной инженерии, но картинка верна в России и для любой другой сложной техники. ]]> http://blogs.trust.ua/levenchuk/2011/11/14/995/Sistemnaya-injeneriya-v-sovremennoi-Rossii/ http://blogs.trust.ua/levenchuk/2011/11/14/994/Vo-vtornik-i-sredu-ya-v-Nijnem/ Mon, 14 Nov 2011 16:29:31 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/14/994/Vo-vtornik-i-sredu-ya-v-Nijnem/ Во вторник и среду я в Нижнем http://blogs.trust.ua/levenchuk/2011/11/14/994/Vo-vtornik-i-sredu-ya-v-Nijnem/ http://blogs.trust.ua/levenchuk/2011/11/14/993/Ob-Rossiu-s-julikami-i-vorami/ Mon, 14 Nov 2011 16:14:00 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/14/993/Ob-Rossiu-s-julikami-i-vorami/ Об Россию с жуликами и ворами http://www.mr7.ru/news/politics/story_47063.html).

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

Попкорна мне, попкорна. ]]> http://blogs.trust.ua/levenchuk/2011/11/14/993/Ob-Rossiu-s-julikami-i-vorami/ http://blogs.trust.ua/levenchuk/2011/11/11/992/Eskiz-obrazovatelnogo-proekta-/ Fri, 11 Nov 2011 15:06:41 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/11/992/Eskiz-obrazovatelnogo-proekta-/ Эскиз образовательного проекта Функции целевой системы:

1. Содержание образования (чему учим):
-- контринтуитивные современные дисциплины (дисциплина -- "то, что загружается в голову": более мелкое деление, чем "учебные предметы" -- проще всего думать о "дисциплинах" как отдельных пунктах типовой современной образовательной программы по какому-то учебному предмету, или о главе учебника -- все эти "оператор цикла" и "деление с остатком" вполне подходят по уровню гранулярности).
-- возможность распознавать несколько предыдущих культурных образцов этих дисциплин (например, "использование блок-схем алгоритмов" или "субстанциальная парадигма"), знать их недостатки и конвертировать описание в терминах этих старых дисциплин в описания в терминах новых ("реинжиниринг" старого знания, по мотивам подхода книжки BORO).
-- набор дисциплин начальной серии может быть из учебных предметов математики, философской логики, алгоритмики, и даже музыки (помним, что музыка имеет формальную модель -- ноты). Использование формализмов и формальных моделей -- это основное, чему учат в STEM (http://en.wikipedia.org/wiki/STEM_fields). "Физик" всегда имеет шанс стать "лириком", а вот "лирик" обычно уже не имеет стать шанс "физиком". Образование должно давать рост числа возможных жизненных траекторий, а не их ограничение (в отличие от просто обучения, которое обслуживает одну заранее выбранную жизненную траекторию). У нас идет обучение в рамках каждой дисциплины, но сама совокупность этих обучений (компетенции моделирования на формальных языках и рассуждения о реалиях жизни с использованием этих моделей) задаёт образование.
-- учим сначала science (созданию компактных описаний сложных явлений, и операции с описаниями), а инженерии (коллективное создание рабочих продуктов) учим потом.

2. Кастомизация: возможность индивидуально определять границы ("уклоны", "специализации" -- в терминах необходимых к освоению отдельных "дисциплин" внутри общепринятых учебных предметов) в общем курсе и подстраиваться к начальному уровню и способностям. Т.е. предлагается не набор из нескольких комплексных обедов, но a la cart.

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

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

5. Старт обучения должен быть при любых начальных компетенциях ученика, окончание при любых заданных компетенциях: технология должна предусматривать кастомизацию для входных компетенций ученика, так и адаптацию к его способности обучаться в ходе курса. Конечно, объем осваиваемых дисциплин и время обучения при этом являются переменными параметрами.

Пресуппозиции:

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

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

Приципы решения:

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

Единицей поедания знаниевого слона служит "дисциплина". Эти дисциплины выделяются как связные куски соответствующих учебных предметов, удобные для учебных операций (не слишком крупные, и не слишком мелкие). Каждая дисциплина представлена в целевой системе своим образовательным модулем, в свою очередь состоящем из:
-- микротеории (содержание образования): объекты и возможные с ними операции. Гранулярность тут для учебных целей в разы и разы меньше, чем принято обычно для использования (например, "вычислять выражение" -- это очень много операций. "Использовать оператор цикла" -- это очень много операций).
-- микробиблиотека объяснений данной дисциплины
-- микробиблиотека "подводящих" и "закрепляющих" задач данной дисциплины
-- микробиблиотека потенциальных ментальных ошибок (в том числе сценарии действий по их искоренению)
-- указатели на комплексные (тестирующие, закрепляющие) задачи, задействующие данную дисциплину

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

Образовательная траектория делается не столько из "учебных предметов", сколько из тесно связанных дисциплин, поддерживающих друг друга: природа не поделена на факультеты.

Ключевым моментом тут является переход от сегодняшней определяющей роли "содержания дисциплины" и мутных объяснений с традиционными "определениями основных понятий" к определяющей роли упражнений (по словам А.П.Ершова, это "сержантский метод").

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

10. Языкоориентированность: поскольку учим моделировать предметные области, то есть учим формальным языкам (STEM):
-- использование DSL для дисциплины обеспечивает формализм представления предметной области (DSL-язык=микротеория+нотация)
-- обеспечивает необходимую модульность конструктивизма (гранулированность по языкам, гранулированность по текстам на
-- это обеспечивает учебные рабочие продукты конструкционизма (тексты на языках, которые должны представить ученики)
-- это обеспечивает автоматизм проверки и распознавания ошибок (опыт систем автоматизации проверок решения программистских задач -- систем автоматизации тестирования)
-- понятная метафора связи между учебными модулями ("линковка библиотечных образовательных модулей")

Итого: задачи решаются в комплекте учебных миров, но устроенном как language workbench (с доработками в части управления образовательными модулями с их задачами и разными языками).

11. Иерархия языков разной степени богатства для прорыва возрастного/общеобразовательного ценза:
-- разделение концептов (дисциплины) и оформляющего дисциплину представления (нотации программирования). Фишка в том, что в конечном итоге и набор концептов, и выражающий их предметно-специфический язык должны быть полными (а часто и мультипарадигмальными) -- но в начальный момент должен быть ограничен и набор концептов, и нотация. Думать нужно прежде всего о принципах работы пары ПиктоМир-КуМир.
Это означает, что language workbench поддерживает разнообразные учебные миры (языки иконографические, как в ПиктоМире, затем языки тайловые, затем языки полные-учебные как Ершол и Схема, затем языки рабочие как Питон и Скала).

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

Если считать, что учебные модули, поддерживающие дисциплины, это исполняемые (учеником) модули на "языке описания учебного процесса", то это аналогично задаче разрешения зависимостей (думайте о task linker/builder/make). Далее нужно из "пирамидки зависимостей" построить последовательность -- "образовательный маршрут", причем с адаптивной перемаршрутизацией по мере понимания реальных способностей и начального уровня ученика в ходе продвижения по маршруту.

Конечно, обеспечение такой линковки требует не просто тщательного моделирования отдельных дисциплин, но и какой-то общеонтологической проработки: вряд ли удастся достигнуть унификации всей используемой терминологии и понятий во всем комплекте дисциплин (возьмём хотя бы classes и sets), но должны быть средства выражения связей и при отсутствии такой унификации.

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

Гипотеза: мы можем в существенной мере автоматизировать эту кастомизацию.

14. Дистантность может быть нестандартна: технологическая компонента доставляется сразу ученику, но отсутствующая компонента человеческого участия доставляется родителям/гувернантам/репетиторам альтернативным каналом (то есть делаем "сервис для ученика и его учителя"). Скорее всего, "полный бот" при существующем уровне технологий не может быть разработан, но вот инструментально поддержать и кое-что автоматизировать для пары "ученик-наставник" (снизив тем самым вдесятеро требования к мастерству наставника и способностям ученика) можно уже сегодня.


Минимальные компетенции для такого проекта:

15. Платформа
-- Системный инженер (архитектор) и его команда (разработчики платформы)
-- Менеджер
-- Организатор частного образования (специалист по бизнес-моделям, массовому обслуживанию и т.д.)

17. Разработка учебных модулей
-- Специалисты-предметники по каждой дисциплине (могут вообще ничего не знать о педагогике, но должны хорошо знать дисциплину и связанные с ней практики)
-- Модельеры (онтологи, логики и т.д. -- специалисты по работе с формально выраженными знаниями: представление знаний, алгоритмы работы со знаниями и т.д.)
-- Программисты учебных миров (интерфейсы, среды исполнения -- language workbench)
-- Нейролингвистические модельеры (обнаружение затыков, их моделирование -- пополнение библиотечки, такой хитрый knowledge aquisition вполне в духе нелперов: знание о незнании)
-- Дидакты: придумывание способов объяснения, придумывание упражнений, придумывание учебных миров
-- Спецы по презентации, инфографике и т.д. (ибо дидакты сами рисовать не умеют)

Бизнес-модель:

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

17. Продукт может быть необязательно русскоязычным. Но нужно понимать, что локализация будет весьма и весьма непохожа на локализацию программных продуктов.

18. В принципе, целевая система чем-то похожа на DisciplineStore (по примеру AppStore, которые были открыты по примеру iTunes). Дисциплины при таком подходе -- это один из типов медиа (стрим объяснений и задач). Напомню, что в проекте STEPs отрабатывается идея, что исполняемый код -- это один из типов медиа, и его можно использовать при верстке "активных эссе".

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

Проект получается очень сложный (хотя бы по набору помянутых в нём множества технологий, часть из которых далеко не вышла из исследовательской стадии, поэтому "венчурность" тут просто зашкаливает -- ну, и сложности сбора минимальной работоспособной команды проекта), и чтобы его как-то двигать с заметной скоростью, нужно бы бросить любимую работу консультанта, и заняться этим проектом full time -- на что я пока не готов. С другой стороны, фирма у меня называется TechInvestLab, и была когда-то задумана ровно для стартов подобных проектов (каковых некоторое количество и произошло в разной форме и разного размера). Так что будем это пока считать моими личными заметками "для памяти" в Лабораторном Журнале, а там посмотрим. ]]> http://blogs.trust.ua/levenchuk/2011/11/11/992/Eskiz-obrazovatelnogo-proekta-/ http://blogs.trust.ua/levenchuk/2011/11/08/991/Vishel-otchet-proekta-STEPS-Towards-Expressive-Programming-Systems-za-2011-god/ Tue, 08 Nov 2011 23:00:41 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/08/991/Vishel-otchet-proekta-STEPS-Towards-Expressive-Programming-Systems-za-2011-god/ Вышел отчет проекта STEPS Towards Expressive Programming Systems за 2011 год http://www.vpri.org/pdf/tr2011004_steps11.pdf) -- в нём сообщается, что заявленная в прошлом году система уже работает, хотя в ней еще можно найти следы использования Си. Система воспроизводит основную функциональность персонального компьютинга (браузинг веба, производство текстовых документов, спредшитов, слайдовых презентаций, работу с языками программирования, воспроизведение аудио и видео), но умещается в 20тыс. строк кода на голом железе -- вместе со всеми необходимыми для реальной работы оптимизациями.

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

Вот такой информатике и нужно обучать в школе. Вот такую информатику и нужно делать на работе.

Все основные материалы проекта тут: http://vpri.org/html/writings.php (а кое-какие коды выложены в http://www.vpri.org/vp_wiki/index.php/Main_Page -- но результирующий код проекта пока отсутствует. Наверняка откладывают выкладку в надежде хоть как-то отдокументировать работающий код, на что уйдёт последняя неделя шестого года проекта -- это уж как всегда в таких исследованиях, ничего необычного). ]]> http://blogs.trust.ua/levenchuk/2011/11/08/991/Vishel-otchet-proekta-STEPS-Towards-Expressive-Programming-Systems-za-2011-god/ http://blogs.trust.ua/levenchuk/2011/11/06/990/Rim-den-vosmoi-i-poslednii/ Sun, 06 Nov 2011 19:27:06 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/06/990/Rim-den-vosmoi-i-poslednii/ Рим, день восьмой и последний
Из аттракционов были бооольшой велосипед (на троих, причем с помогающим электромотором) и лодка. Чудом никого не задавили велосипедом, чудом не перевернулись пару раз на лодке -- ведь дитятко вносил существенный фактор неопределенности в управление всем, что движется. Мою шапочку на каких-то виражах потеряли. Потом нашли на лавочке. Оттёрли влажной салфеткой, стала опять как новая. Жена поделилась опытом: любая грязь легко оттирается влажными салфетками. Эти салфетки являются главным инструментом ухода за дитенком на прогулках -- вместо мытья рук перед едой, скоростная чистка одежды и обуви и т.д..

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

Выходили из парка на обед, попали в небольшую пиццерию и удивились качеству тамошней еды и суете вокруг нас пожилых работников кафе. Выяснили, что этому семейному кафе более ста лет, и они пытаются блюсти традиции. Утром они открываются для завтрака в 6:20, у нас будет шанс позавтракать там перед самолётом. Ибо в нашей гостинице еда на завтрак полностью соответствует тому, что написано во всех путеводителях: "завтрак в Риме сводится к булочке с кофе, еще могут быть мюсли и сыр с ветчиной -- и не ожидайте ничего большего". Жена вполне готова пробежаться завтра к завтраку дополнительных четыре квартала, лишь бы не в гостиницу.

Как мы поняли за неделю, класс заведения легко определить на глаз:
-- если на каждом столе цветочек, то вас за обедом безжалостно ограбят (одна маленькая порция макарон с мясом будет стоить 1200рублей)
-- если на всех столах скатерти, то дешевизна меню не должна вас вводить в заблуждение: способ развязать ваш кошелек найдётся
-- если есть пицца на противнях (разрезная на квадратные кусочки), и бутерброды, но сесть можно только за стойкой -- то будет относительно дёшево, но не факт, что вам понравится
-- если где-то в глубине виднеются пластиковые столики, то нужно идти от двери, где обычно продаётся пицца в каком-то ассортименте, вглубь, ко второму прилавку -- там продаются самые разные блюда, на которые вы можете поглядеть на витрине. Вот эти-то блюда и нужно брать, и садиться за столик: получается компромисс между качеством, ценой, скоростью, разнообразием меню и т.д.. Но и в этом случае средний чек в пересчете на рубли у вас будет 800руб за обед -- в Москве в каких-нибудь "Граблях" примерно того же класса готовка и в том же количестве обошлась бы в 400руб. Охотно верю, что можно найти и более дешевый и вкусный римский общепит, но что Москва самый дорогой город Европы, меня пока не убедили.

Последнее сегодняшнее развлечение -- это мультфильмы канала Boing. Конечно, там тоже есть повсеместный Spongebob по-итальянски, но всё остальное транслируется из неведомых нам сериалов. Соглашение с дитяткой простое: одна задачка по алгоритмике меняется на 20 минут мультфильмов по-итальянски. Из курса Дениса Кириенко мы закончили полностью 12 уроков, и сейчас идет повторение -- решаются вновь последние задачи каждого урока.

Ходят слухи, что в Рим вот-вот придут те самые дожди, которые смывают сегодня всю южную Европу. Очень надеюсь, что наш самолёт завтра взлетит до этого момента.

Вторник -- уже рабочий день. ]]> http://blogs.trust.ua/levenchuk/2011/11/06/990/Rim-den-vosmoi-i-poslednii/ http://blogs.trust.ua/levenchuk/2011/11/05/989/Rim-den-sedmoi/ Sat, 05 Nov 2011 23:35:51 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/05/989/Rim-den-sedmoi/ Рим, день седьмой
Сегодня было хождение на военную выставку, где дитенку пустили покрутить штурвалы и подёргать ручки самой разной военной техники Италии -- счастья были полные штаны, но взлететь или пострелять боевыми ему таки не дали. Компьютеров у военных была уйма, техника глючила, военные натянуто улыбались. Были представлены и современные тактические ракеты, и многие разновидности БТР, и старинная техника с приставленными к ней людьми в старой военной форме. Среди людей в новой военной форме я видел одного очень важного (судя по свите) офицера НАТО, которого от вождя индейцев отличала скромность: ему на парадную шляпу хватило всего одного перышка.

А потом мы вынуждены были пойти второй раз в Explora: тот самый детский музей, который я не хвалил вчера. Я его и сегодня не хвалю, но вынести причитания дитенка мы не смогли, ему туда было нужно явно не меньше, чем жене в виллу Боргезе. Cеанс загула был повторён.

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

Сегодня ходил уже не в пиджаке, но в плаще. Ноябрь, он и в Риме ноябрь. К плащу одел новую шапочку. В первую пару дней в Риме пытался купить какую-нибудь легкую шапочку к плащу, и удивлялся ценам (что-то типа полутора сотен евро за шапочку в шапочном магазине на виа Корсо). А потом случайно померял какую-то бейсболку в сувенирном ларьке на совершенно безлюдной улице -- и она села как влитая. Итого: на шапочку потрачено 4 (четыре) евро, а шапочка оказалась того же бренда, что и купленный в Москве ксивник жены. ]]> http://blogs.trust.ua/levenchuk/2011/11/05/989/Rim-den-sedmoi/ http://blogs.trust.ua/levenchuk/2011/11/04/988/Rim-den-shestoi/ Fri, 04 Nov 2011 23:39:56 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/04/988/Rim-den-shestoi/ Рим, день шестой
Местный детский музей Explora оказался худшим из всех виденных -- московский Экспериментаниум и Лунариум много круче. Там предлагается несколько игр в дочки-матери на деньги. Можно поиграть в банк -- напечатать деньги, посидеть за стойкой клерком, поглазеть на биржевой терминал. Можно посидеть на кассе в маленьком супермаркете (крутая касса, даже чеки выбивает!). Ну и дальше разные другие дочки-матери, тоже с деньгами. Все это приспособлено для детишек 3-6 лет. Для детей 7-12 лет предлагается пара-тройка скучных головоломок с объяснениями на итальянском. Поэтому наше девятилетнее дитятко там было самым старшим, а остальная итальянская мелочь (иностранцев практически не было) путалась у него под ногами (точнее, это он путался под ногами у многочисленных маленьких детишек). Ходить туда не нужно, если у вас не пятилетка -- но если уж пришли, то вам и не дадут потратить много времени: там "сеансы" по часу сорока пяти.

Много часов сегодня было потрачено на программирование: всего-то нужно было написать процедуру закраски шахматной доски M*N, но сочетание вложенных циклов со счётчиками, передачи параметров длины и высоты доски, проверки четности текущих ряда и столбца взорвало дитёнке голову (хотя ни одна из этих концепций по отдельности трудностей не представляла). Пару дней теперь придется потоптаться на этом материале. Вообще, обучение третьеклассника программированию нетривиально во многом потому, что курс для семиклассника подразумевает полный автоматизм владения каким-нибудь "делением с остатком". А когда это деление с остатком проходится в курсе математики чуть ли не в те же дни, что используется в курсе алгоритмики -- это становится определенной дидактической проблемой. И таких пересечений довольно много. Так что сейчас мы занимаемся с женой на пару: она ответственна за достаточную математическую/геометрическую подготовку дитятки, а я за собственно алгоритмику. И Рим как раз хорошее место для подобных занятий -- ведь в московской суете мы собираемся на несколько часов втроем только в выходные дни (будни вечером тут в счет не идут, ибо после работы-школы-домашек квадратная голова уже у всех троих. Про раннее утро я вообще молчу, раннее утро ведь добрым не бывает).

Сегодня также начал курс Онтолана: программа седьмого класса состоит из 1. курса моделирования (работы с данными), 2. алгоритмики и 3. работы с Офисом. Сначала я думал, что добью алгоритмику, и только потом буду давать онтолан. Но потом вдруг подумал, что курс Онтолана в значительной мере говорильный, и много задач можно решать, просто ходя по улицам Рима. К сегодняшнему вечеру дитенка и жена уже более-менее различают Индивиды и КлассыИндивидов -- итог двух прогулок по двадцать минут каждая. Обсуждались встречающиеся компьютеры, автомобили, двери, монеты, урны и даже папы и мамы. Контрольные вопросы -- про не встречающиеся самолёты (классика жанра: "полетишь на самолёте?"). Ну, вы поняли идею. Пытаюсь применить тот же подход, что был использован в языковой паре ПиктоМир-КуМир. Сначала обсуждается предметная среда и тренируются типовые мыслительные операции в простейшем их варианте -- без сложного синтаксиса, "прямым указанием" (сегодня в качестве "прямого указания" я тупо тыкал пальцем в предметы, а в случае классов индивидов бодро размахивал руками -- жестикулируя включение и отсутствующих предметов). Потом добавляется синтаксис (собственно Онтолан), и обучение продолжается с использованием более мощного языка. Увы, софта пока для Онтолана нет, задач пока нет -- так что будем набирать опыт вот таким претендотипом. ]]> http://blogs.trust.ua/levenchuk/2011/11/04/988/Rim-den-shestoi/ http://blogs.trust.ua/levenchuk/2011/11/03/987/Rim-den-pyatii/ Thu, 03 Nov 2011 22:17:40 +0200 levenchuk http://blogs.trust.ua/levenchuk/2011/11/03/987/Rim-den-pyatii/ Рим, день пятый
Растений тоже не слишком много, и отнюдь не все они подписаны (бирки-то есть на многих, но не более чем бирки с инвентарными номерами). Тем не менее, вся местная природа представлена довольно хорошо, плюс чуть-чуть экзотики типа бамбуковых рощ и банановых пальм (которые вовсе не пальмы, а такая большая трава!).

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

Вездесущие пиццы и лазаньи уже достали и меня, и жену. Но дитятко продолжает требовать свою пиццу маргарито, и не желает менять ее на что-то менее пиццное и менее маргаритное.

Очень не хватает моря. В Барселоне я отправлял семью купаться, а сам успевал за эту пару часов хоть что-то сделать. Тут моря нет, и меня эксплуатируют почти круглосуточно.

Свой HTC Desire буду менять: он постоянно теряет сеть, а у жены и сына много менее навороченные телефоны ее не теряют! Так жить дальше нельзя, нужно уже озаботиться заменой -- в этом модельном ряду уже пара поколений прошла после этого Desire. Хотя ничего существенного в этой паре поколений не было добавлено (только гонка гигагерц и ядер), вдруг они подняли стабильность работы? ]]> http://blogs.trust.ua/levenchuk/2011/11/03/987/Rim-den-pyatii/