Category: отзывы

2019

Что может современный студент: перебирать в руках детальки конструктора

Вот тут шикарное обсуждение возможностей современных студентов-бакалавров (да и магистров, кстати, уже тоже -- время-то быстро летит): https://www.facebook.com/konstantin.okorokov.3/posts/1606923176044151

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

Новое в этом повороте то, что речь идёт не только про чтение. Речь идёт о любых других длинных учебных формах (обратите внимание в этом треде, что "Магов [магистров] посылаю послушать Анатолия на его курсе в Coursera - уж там у него чистая квинтэссенция. Не доходят."). Вот эта выдержка из треда, она совпадает со впечатлениями от моих студентов в МФТИ-МИСиС-МИФИ (в Школе публика постарше, и там это не так ещё заметно):

Konstantin Okorokov ... У Анатолия недавно вышла очередная редакция учебника по системному мышлению - любому студенту на модуле "Введение в специальность" (если такие остались) ставил бы обязательным к прочтению.

Edward Galiaskarov Konstantin, эту книгу Анатолия использую, заставляю студентов читать - только не могут они пока читать большие книги (магистры, бакалаврам такое пока не по зубам). Нравится Мизгулин.

Konstantin Okorokov Эдуард Галиаскаров если учебник по системному мышлению - большая книга, то для студентов у меня плохие новости

Edward Galiaskarov Konstantin - давненько Вы студентов не видели? Не они мне рецензию на 10 страничную статью три недели писали, а уж книгу мы читаем по частям как в детском саду

Konstantin Okorokov Эдуард Галиаскаров т.е. бородатая студенческая притча о предэкзаменационном "- тебе сколько прочитать осталось? 1,5 метра, а тебе? - а мне 2 " (имея в виду высоту стопки учебников) - устарела безвозвратно?

Edward Galiaskarov Konstantin Okorokov - устарела. Сейчас в век интернета никто не читает, зато развиваются исключительные способности поиска ответа

Edward Galiaskarov процент чтецов примерно как в принципе Парето Перевернутом.

Konstantin Okorokov Эдуард Галиаскаров простого, понятного, неправильного ответа

Konstantin Okorokov Эдуард Галиаскаров ну, в век интернета, можно метры заменять на мегабайты

Edward Galiaskarov Konstantin Okorokov - ага. Потому я стараюсь все вопросы и задания превращать в чистую практическую плоскость. Но с мотивацией читать и разбираться со знанием самостоятельно беда.

Edward Galiaskarov Все ждут рафинированной, концентрированной информации.

Edward Galiaskarov Магов посылаю послушать Анатолия на его курсе в Coursera - уж там у него чистая квинтэссенция. Не доходят. Беда просто.

Konstantin Okorokov Эдуард Галиаскаров при таком подходе видится, что или группы обучаемых уменьшать или число преподавателей увеличить в одной группе.

Edward Galiaskarov Konstantin Okorokov - уменьшать нельзя, это же не студенты, а чистые деньги. Потому держат до последнего.

Edward Galiaskarov Я конечно заставляю учиться, но это сложно, если человек сам не тянется к знаниям или ждет, когда ему в рот положат некую пилюлю знания.

Konstantin Okorokov Переслегин, в "Новых картах будущего" описывал этот феномен утраты интереса к обучению, с очень тревожным сдвигом влево, к раннему возрасту.

Alexander Turkhanov Konstantin Okorokov я сейчас прохожу это со своими детьми. Зачем учиться читать, когда на все есть аудиосказки? И если бы у меня не было педагогических и менеджерских-лидерских навыков, я бы вряд ли справился.

Edward Galiaskarov Konstantin, у нас тут была дискуссия с профпсихологом. Она выдвинула гипотезу, что это все связано с ранним вовлечением детей в обучение + наверное неправильным. В итоге дети детства не видят и рано устают от обучения. Конечно, тут есть спорные места.

UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10212597851355291
2019

lytdybr

31 бета-тестер моего учебника "Системное мышление", которые прислали мне отзыв на первую главу, получили сегодня переделанную первую главу и свеженаписанную вторую главу -- всего 76 страниц. Огромное им спасибо за присланные предложения и замечания! Я никак не ожидал такого массового отклика, это было очень приятно! Я постарался все эти замечания учесть. Ну, почти все. Мне пришлось практически полностью переделать первую главу, плюс добавить туда десяток новых страниц, чтобы это всё учесть. А при написании второй главы обнаружил, что из второй версии учебника в третью не так уж много удалось заимствовать, почти всё в ней пришлось писать заново. Такое впечатление, что это получается не третья версия предыдущего учебника, а вообще новый учебник.

Вчера час разговаривал с Антоном Климатом про системный фитнес -- проверялось, насколько текущий подход к телесно-двигательному мышлению удовлетворяет требованиям к мышлению из http://ailev.livejournal.com/1342372.html (рациональность, абстрактность, адекватность, осознанность). Всё ОК, удовлетворяет. При этом в других подходах -- нет, многие требования не выполняются. Такое впечатление, что не разговаривать нужно, а писать текст. И добавлять к тексту видеоролики с иллюстрациями. Но это всё потом: во-первых, нужно дописать учебник, и мультитаскинг удавливать по возможности. Иначе будет слишком много полунаписанных текстов. Во-вторых, в этой телесной области нужно самому быть демонстрацией успехов. А до этого как до Луны, я ж не очень активно тренируюсь. С другой стороны, кто меня видел год назад и сегодня, сильно удивляются разнице как в диаметре, так и происходящим изменениям в осанке и подвижности. Толстым людям ведь не будут верить в разговорах про диету, а нетанцующим в разговорах про танцы.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210929624130653
2019

Видеообзор "Как определить свою систему среди чужих"

Двадцатиминутный видеообзор темы "Как определить свою систему среди чужих" (https://youtu.be/6hHkx4vYJU4):

Это первая тема из шести в серии однодневных тренингов школы системного менеджмента (кстати, очередной цикл начинается 6 декабря 2015, как раз с этого тренинга по определению своей системы -- http://nisse.ru/training1/).

Последовательность и акценты изложения отличаются от тех, которые были в моём учебнике системноинженерного мышления (этот учебник тут: http://techinvestlab.ru/systems_engineering_thinking):
-- это не системное мышление для инженеров, а системное мышление для менеджеров (хотя те, кто ходит к нам -- это чаще всего инженеры, которые хотят поднабраться менеджерских компетенций). Так что много меньше внимания традиционным системноинженерным дисциплинам (инженерии требований, инженерии системной архитектуры, проверкам и приёмкам), но много больше внимания к дисциплинам работы с обеспечивающей системой -- предприятием. Хотя ровно вот этот первый тренинг может быть интересен как для инженеров, так и для менеджеров, менеджерская специфика будет потом нарастать от дня ко дню, до самого шестого дня "Стратегирование".
-- сначала тренируемся определять свою систему по отношению причастности к ней (возможности влиять, наличию интереса к ней), находим место целевой системы в холархии системных уровней. Профессионально окрашенный интерес будет рассматриваться в последующих тренингах. Ибо если профессионально работаешь не с той системой, счастья тебе не будет.
-- никаких жизненных циклов, время будет рассматриваться только со второго дня. Мне всегда хотелось побольше успеть рассказать в первый день. Но "успеть рассказать" -- это ещё не значит, что тебя услышат, это ещё не значит, что услышанное поймут, а понятое будут использовать в работе. Так что на сегодня в этом дне оставлен минимум плотно связанного изложения, зато этот минимум можно понять за день и потом использовать в работе. Значительная часть группы такую порцию материала вполне осваивает, он получился не обзорным, а рабочим.

Общая программа всего шестидневного курса тренинга системноинженерного мышления была тут: http://ailev.livejournal.com/1220045.html (кстати, послезавтра, в воскресенье 15 ноября 2015, у текущей группы проходит четвёртый день этого марафона, "Развитие и совершенствование").

Если хотите ещё видео на тему инженерного мышления, то у школы системного менеджмента есть целый видеоканал тут: https://www.youtube.com/channel/UCJ0Uq_WB7GLmY-NTz2oFoUQ (там кроме моих видеообзоров есть ещё видеотезаурус системного мышления, который делает vvagr, плюс материалы по ТРИЗ).

Новости школы можно найти на её страничке в фейсбуке: https://www.facebook.com/system.school.ru/

Тем же, кто хочет профи-уровня, можно поглядеть на страницу Русского отделения INCOSE (но там меньше про менеджмент и больше про системную инженерию): http://incose-ru.livejournal.com/
2019

lytdybr

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

С курсами свезло, там группа набралась всего человек восемь, поэтому скучать отроку на уроках особо не дают.

А вот тут предлагают научить компьютер отвечать на тесты для восьмиклассников, за деньги ($50тыс. лучшей программе) -- https://www.kaggle.com/c/the-allen-ai-science-challenge. Через пару-тройку лет абитуриентские тесты компьютеров кончатся, начнутся тесты ВУЗовские. Как раз мой парень подрастёт и выйдет на рынок труда (вернее на то, что от этого рынка труда останется после выхода на него резко поумневших компьютеров).

Вот несколько тем, вокруг которых крутятся мои мысли последних дней (интересно было бы прочитать этот списочек года через три):
-- интересы (concerns) и работа с ними через что-нибудь типа word2vec (https://code.google.com/p/word2vec/). Что такое concerns онтологически (чем это не domains, и почему они могут быть interests, drivers и т.д.. Какие с ними операции возможны? Какие классификации? Откуда они берутся и куда уходят? Как соотносятся со стейкхолдерами? С позициями? С ролями?). Алгебра интересов (как это принято в word embeddings -- http://gavagai.se/blog/2015/09/30/a-brief-history-of-word-embeddings/), выявление интересов по высказываниям стейкхолдеров -- тут вполне может быть много deep learning.
-- компактификация знания, и различия между "онтологическим знанием" и каким-нибудь "зоопарком обученных нейросеток" меня всегда занимала, но в последние дни я вот думаю про consilience (https://en.wikipedia.org/wiki/Consilience) в связи с компактификацией знания -- там плывёт сейчас значение слова от объединения разных доказательств в "сильное свидетельство в пользу теории" в сторону "единой науки", то бишь "однородной науки как теории всего". По-русски это переводят как "непротиворечивость", что полностью устраняет оттенки как "усиления от соединения", так и "слипания всего в одно целое".
-- не проработать ли мне ещё раз на свежую голову основания НЛП (нейролингвистического программирования), там ведь как раз много про эпистемологию и это вроде как ровно та "нейролингвистика", на которую пытаются выходить сейчас люди из deep learning. Аналогии у меня тут смутные, сама область НЛП на редкость эклектична и нужно ещё сообразить, что оттуда копнуть, но даже интересно, что я бы сейчас вычитал из трудов отцеположников (отцов-основателей, основоположников), если бы занялся этим делом сейчас. Когда-то я по факту забросил openmeta потому, что совершенно не хватало методологического инструментария, системный подход у меня тогда был никакой. Сейчас ситуация другая.
-- модульность, платформенность, цена связи в модульности (http://www.sciencedaily.com/releases/2013/01/130130082300.htm), технологические стеки и как их моделировать, стандарты и протоколы, интерфейсы и т.д., библиотеки и пр. -- в связи с инновациями (прорыв получается, когда берёшь новую реализацию модулей на три уровня ниже твоего прикладного уровня) и в связи с programming/modeling-in-the-large. Особенно мне понравился тут кусок из Педро Домингоса, в котором он рассказывает про необходимость модулей в What's Missing in AI: The Interface Layer (http://homes.cs.washington.edu/~pedrod/papers/ai100.pdf).
-- что называть целевой системой (у каждого ведь она своя, стейкхолдеров много -- и если каждый будет называть целевой системой то, что его интересует в каждый момент времени, можно не договориться чисто лингвистически, не добиться командного действия). Тут ещё акцент на целевой системе с точки зрения линии определения SoS по "социальному критерию": ты можешь определять развитие для твоей собственной системы, но уже для using system тебе приходится всех уговаривать. Нужно уточнить набор эвристик и использованием терминологии, дать примеры.
-- интересно было осознать, что model-based conceptual design и эволюция системы после её постройки в порядке обеспечения resilience это про выход за рамки традиционно понимаемого жизненного цикла. Нужно ещё раз вернуться к табличке "уровни вещества * уровни воплощения", при этом ещё и понять, что таких плоских табличек, перевязанных одни и тем же каким-то уровнем вещества много -- все они определяют разные прикладные уровни. И выход идёт как за границы традиционных уровней воплощения (стадий жизненного цикла), так и уровней вещества (в более микро, чем обычно и в более макро, чем обычно -- в захват и трансформацию using system, если мы даём туда прорывный модуль, который может вывести using system на новое качество).
-- вышел проект рабочей группы NIST по кибер-физическим системам, и нужно что-то с этим делать. Там 200 страниц каких-то размышлений (и про сети, и про IoT и M2M, SoS и так далее), нужно сформулировать к ним своё отношение -- http://www.cpspwg.org/Portals/3/docs/CPS%20PWG%20Draft%20Framework%20for%20Cyber-Physical%20Systems%20Release%200.8%20September%202015.pdf

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

И в преддверии пятницы вечера: всю неделю под впечатлением от Hugues Le Bars (1950- 04/11/2014), https://www.youtube.com/channel/UCBFV5elM-08Ps0Lv4M9NUOQ (работать под эту музыку совершенно невозможно. Она ой-ой-ёй-ах-aх-ёй. Типа как Yello, если от него пойти не дальше в жёсткую сторону Prodigy, а в противоположную, где помягче).
2019

Архимейт по-русски 1.1 -- бета готова

Сегодня я закончил новый перевод Archi 3.2.1, обозвал его версией 1.1 (версия 1.0 была выпущена три года назад -- http://ailev.livejournal.com/988360.html).

По сути, это третья редакция перевода:
-- первая была формальная, и все стандартнаци были очень довольны. Уже в первой редакции я максимально согласовал с уже имеющейся терминологией переводов ISO 42010 (Архимейт на нём базируется). Эта редакция так и осталась внутренней, плагина к Archi я для неё не публиковал.
-- после тестирования на клиентах я решил резко сбить пафос и убрать по возможности канцелярит-стандартит. Основной аргумент был: деньги за реализацию архитектуры платят те люди, которые айтишных стандартов не читали, но они должны хотя бы что-то понимать из ведущихся разговоров, хотя бы полпроцента. В этом виде и вышла версия 1.0 плагина к Archi (глоссарий -- http://ailev.livejournal.com/956829.html, дополнения второй версии -- http://ailev.livejournal.com/978200.html).
-- третья версия 1.1 выйдет сейчас, и я продолжил там гнуть ту же линию снижения пафоса и укорочения говорения. Профессионального сленга стало больше, на лёгкие проблемы я сознательно махнул рукой (ибо решение этих проблем, которое я пытался реализовать в версии 1.0 было хуже, чем сами проблемы), плюс учтён опыт прошедших трёх лет -- и несколько источников ошибок я постарался исправить на уровне выбора слов.

Вот главные изменения:

1. Я перестал добавлять ко всем словам название уровня. Не "объект деятельности", и даже не "оргобъект", а просто "объект". Не "процесс деятельности", и даже не "оргпроцесс", а просто "процесс". Хотя там, где одинаковые слова для похожих элементов разных уровней, я уровень оставил -- оргсервис, программный сервис и сервис "железа".

2. Уровень Business-"люди" стал "деятельностью" (не будем беречь этого слова, потратим его свободно. Busniness -- это "дело", "деятельность"). Но в некоторых местах я вместо длинного "деятельность" даю короткую приставку "орг" -- тот же оргсервис. И всё-таки я не стал называть уровень "организационным". Три уровня деятельность-"софт"-"железо" звучат для меня более понятно, нежели организация-"софт"-"железо", ибо про деятельность того же софта я сказать не могу, а вот про организацию софта -- запросто. Но оргсервис я не перепутаю с программным сервисом, поэтому не просто "сервис", и не длинно "сервис деятельности людей" (по мотивам прошлой версии перевода), а "оргсервис", ибо короче и понятней.

3. Уровень оборудования стал уровнем "железа". А заодно Node-оборудование стало "железом" (если говорить о единице оборудования -- будет единица "железа"). "Железо" пишем в кавычках. Я с клиентами в "реальном секторе" неоднократно натыкался на то, что они подолгу не понимали, о каком я говорю оборудовании -- о том, которое в их информационных системах, или в котором их информационные системы! А уточнять каждый раз, что "айтишное оборудование" -- это длиннее и не менее сленгово, чем просто "железо".

Так что было Infrastructure usage-"использование оборудования", стало "использование "железа"", Infrastructure function стал функционалом "железа", а не оборудования, а Infrastructure interface стал интерфейсом "железа".

4. Уровень программ стал уровнем "софта". А Application Component-"программная компонента" стала "программой". Описание программы (инкапсуляция, интерфейсы, реализация файлом и т.д.) чётко указывает на то, что речь идёт именно о программном модуле. Компонента там по смыслу -- "программный функционал", на выполнение которого назначается модуль. Так что слово "компонента" просто опущено.

Ну, и Application Behaviour -- работ "софта" (а не работа программ), Application Cooperation -- взаимодействие "софта", Application Structure -- структура "софта". Там, где говорится о множестве программ, где используется собирательное понятие, там "софт".

Но не "софтовый" сервис, а "программный сервис", не "софтинка", а "программа", не функционал "софтинки", а "программный функционал" -- где имеется ввиду не весь "софт" предприятия, а одна или программа или небольшая группа программ.

5. Крутейшее изменение, которое касается и ISO 42010. View (помним, что в стандарте veiw группирует входящие в него модели) переобозван из группы описаний просто описанием. Да, там нюансы. Так, архитектурное описание (description) само состоит из разных тематических групп описаний, а элементарными описаниями являются "модели" (models). По мне сегодняшнему, так это очередная попытка навести разнотиповую иерархию там, где просто специализация типа. Ведь определение системы противопоставляется описанию системы (description -- все view вместе), которое делится на тематические описания типа архитектурного -- и уже это вполне себе view. А затем view делятся на маленькие подвьюшки -- модели. А в Archi description называется Total veiw, низовых моделек нет вовсе. И слово "модель" там занято, по смыслу это как раз definition (видеть модель можно, только вынеся на какую-то диаграмму-описание или в специальном окошке диаграммы дерева-модели -- и как называется это окошко? Правильно, тоже view).

Итог: группа описаний стала просто описанием. Есть определение, а есть описание. То, что в Archi view-окошко программы и ArchiMate view обозначаются одним словом -- это ничего, это нормально. Так что там иногда путается в переводе "закрыть окошко" и "закрыть описание".

Ах, насколько же стало проще и понятней!

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

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

Архимейт явно проговаривает, что никаких конкретных исполнителей ролей в нём не предусмотрено, Actors главным образом используется для выражения органиграммы. А "ответственный" обычно ещё и несколько ролей играет, ибо назначен явно не на одну практику. И вот поэтому переводим "ответственный" (главный инженер, департамент закупок и т.д.), а не просто "исполнитель".

7. Product (который я в прошлый раз честно оставил "продуктом") надёжно всех сбивает с толку -- это "банковский продукт", "страховой продукт", но в реальном секторе каждый раз удивляются, почему Арчи не позволяет поступать с ним как с продуктом, как будто он какие-то работы (activity), а не продукт! Да, ArchiMate определяет product именно как service+contract! Вот он и ведёт себя как оргсервис при моделировании! Так что я назвал его хитро: оргсервис-продукт, чтобы прямо из названия следовала аналогия с "банковским продуктом".

Парное к нему соглашение об уровне сервиса (contract) я так и назвал полностью, чтобы дополнительно прояснить эту засаду с оргсервис-продуктом как сервисом -- "соглашение об уровне сервиса". Архимейт 2.1 тут странен: в тексте подробно говорится, что чаще всего тут SLA, а иногда другие типы контрактов. А элемент назвали контрактом. Я перевёл по наиболее частому случаю, строго по стандарту! И приписал в подсказке, что могут быть и другие виды контрактов.

8. Stakeholders стали из заинтересованных сторон просто "стейкхолдерами". Язык развивается, и это нужно учитывать. Слово компьютер постепенно заменило слово ЭВМ, и тут ровно такой же случай.

9. Requirements по более тщательному рассмотрению стало не требованиями (ещё можно говорить про требования к "софту" или "железу", но про деятельность редко говорят в терминах требований), а... контрольной точкой. Это удивило и меня самого.

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

Почему "контрольная точка"? В контрольной точке же явно оттенок команд-глаголов из "управления кейсами", а не декларативная чисто инженерная запись о "требуемом свойстве"!

Ну, Goal (а requirement это по сути декомпозиция Goal) там тоже SMART-цель с ярко выраженным глаголом-командой. "Увеличить продажи на 20% к 3 января" -- цели все такие. И requierment, из них следующие тоже все имеют этот оттенок требуемого действия, а не требуемого пассивного свойства. Это требование действия, требование изменения. И даже стандарт говорит, что для достижения целей нужен план, и именно для этого служат requirement (но тут же стандарт сбивается, и продолжает говорить про "свойства системы").

После внимательного рассмотрения примеров (и особо замечания Gerben Wierda, что всякие контроли моделировать нужно requirements -- то, что требования контролируются, было и так понятно, но он уточнил, что сам контроль моделируется элементом requirement!), а также принимая во внимание тренды в части кейсов (контрольная точка становится элементом контроля, соединяющим требования и выполнение работы -- поскольку требования выполняются сейчас асинхронно, то в каждой контрольной точке указывается условие её достижения, фрагмент требований). То есть контрольная точка -- это тот самый синтез элемента плана и требуемых свойств, о которых говорит данный пункт стандарта.

Я писал в http://ailev.livejournal.com/1202776.html -- "Планируются события как чеклисты (к продуктам) и контрольные точки (состояния продуктов в проектах)". Вот события предприятия ("архитектуры") в ArchiMate планируются через Event, а события развития ("с архитектурой") планируются через удовлетворение requirement, контрольные точки. Так что эта логика case management попадает теперь и в дополнение целеполагания.

10. Presentation из "представления" стало "рабочим продуктом" -- объект в ArchiMate это "информация", альфа. Так что информация никак не представлена. Но она может быть представлена в данных и затем артефактом (но это уже чисто айтишные заморочки -- невидимые в деятельности), а в деятельности альфа представляется рабочими продуктами (одним или несколькими). Формулировки и объяснения стандартов ArchiMate и Essence тут весьма близки. Так что я просто учёл тут результаты наших работ с Essence.

11. Driver стал из "фактора влияния" интересом (concern). В ArchiMate, впрочем, об этом прямо говорится -- и про связь со стейкхолдером, чей этот интерес. Миром движут интересы, всё правильно. Замечание, что может быть и просто "какой-то внешний фактор" игнорируем: это означает, что интерес к фактору есть, и по норме дальше мы просто должны понимать, чей этот интерес. Но можем, конечно, не указывать, чей интерес какое-нибудь "падение рынка", язык вполне допускает тут расслабиться. Но я бы не рекомендовал расслабляться, и подумать, кого это может из стейкхолдеров волновать. Так что тут я просто чуть-чуть подправил перевод в сторону чуть более строгого системного подхода.

12. Gap стал "различием" (из "расхождения"). To be и as is не "расходятся", а "различаются".

13. Deliverable из "комплектующего" (что более пристало инженерным, а не орг-работам) стал "результатом пакета работ", практически по тексту стандарта.

14. В большинстве случаев в интерфейсе я начал писать не "ошибка при открытии файла", а "ошибка открытия файла" -- и по этому же шаблону все остальные подобные выражения. Тут, конечно, можно открывать холивар, но это явно не самый большой грех этого перевода. Хочется, хочется быть поближе к народу!

Технически сейчас ситуация такая:
-- переведено уже всё (пользовательский интерфейс+подсказки), кроме хелпа. Хелп я переводить не буду.
-- есть техническая проблема: время от времени вдруг вместо перевода показываются английские слова (иногда это при перезапуске Archi исчезает, иногда остаётся). Эту проблему буду решать в ближайшие дни -- я думаю, что-то там не то с версиями Eclipse, я сделал запрос автору Archi (ну, или придётся тут поискать какого-то местного знатока локализации в Eclipse). В принципе, основное там уже всё по-русски, и все эти вкрапления английского не слишком мешают. Тем не менее, публиковать версию пока рано. UPDATE: всё уже исправлено.
-- готов отдать language bundle для Archi 3.2.1 на бета-тестирование прямо сейчас -- под обязательство потыкать и прислать мне какие-то замечания в ближайшую пару дней. Для этого напишите мне на ailev@asmp.msk.su
2019

Глубокая попса и её эффективность

Лето искуственного интеллекта, лето 2015 года. Компьютеры достигают самых разных высот человеческого духа почти каждый день, недостатка в новостях нет. А всё началось примерно в 2011 году, когда спецы по искусственному интеллекту занялись попсой. Победа IBM Watson в Jeopardy! была как раз в 2011 году (https://en.wikipedia.org/wiki/Watson_%28computer%29) и все поняли, что "лёд тронулся", зима искусственного интеллекта заканчивается. Большие команды смогли получить финансирование. В этом же 2011 году была поставлена задача роботу поступить в университет Токио (http://21robot.org/), а весной 2014 уже results indicated that the robot has an 80 percent or higher probability of passing exams for 404 universities across the country (http://www.japantimes.co.jp/news/2014/03/04/national/robots-challenged-to-pass-todai-examination/).

Но эти "большие проекты" оказались не самым большим событием 2011 года. Самым большим событием оказалось то, что в октябре 2011 года Andrew Ng вытащил свой стендфордский курс по машинному обучению в сеть и первый же набор составил сто тысяч человек (Курсера была организована в 2012 году как раз на основе этого опыта -- https://en.wikipedia.org/wiki/Andrew_Ng). Все эти люди попали на учебно-соревновательную площадку http://kaggle.com (образована как раз в апреле 2010года и в 2011 году получила $11млн. венчурного финансирования -- https://en.wikipedia.org/wiki/Kaggle) -- и понеслось, искусственный интеллект стал народным, и после кратенькой весны наступило лето. Я сам плотно разбираться с этими технологиями стал в 2012 и тогда же отметил, что пузырь искусственного интеллекта уже надувается (пункт 3 в http://ailev.livejournal.com/1051479.html).

Сегодня искусственный интеллект (слабый, меня AGI слабо интересует, pun intended) стал попсовым как в части его разработчиков (сотни тысяч человек) так и в части потенциальной аудитории, которую эти разработки могут заинтересовать. Искусственный интеллект стал дешёвым, и data scientists (как они себя стали называть) шутят. То на полмира шумят про прохождение компьютером теста Тьюринга, который держался 64 года, то начинают генерировать Шекспира побуквенно (про галлюцинации нейронных сеток -- http://ailev.livejournal.com/1191576.html), то заставляют компьютер сочинять рэп с поэтическим качеством не хуже человечьего сочинительства (http://www.technologyreview.com/view/537716/machine-learning-algorithm-mines-rap-lyrics-then-writes-its-own/). Тёплый ламповый рэп, сочиняющийся алгоритмом DeepBeat, который встал на плечи гигантов -- он честно учился на примере более 10тыс. песен более ста рэпперов, он продолжатель традиции! А традиция сложна, DeepBeat outperforms the top human rappers by 21% in terms of length and frequency of the rhymes in the produced lyrics. Суть реп-поэзии (там очень хитрые ритмы и нетрадиционные рифмы) компьютер понял, разве что историй этот алгоритм пока не рассказывает, но это только пока.

Ещё из событий последних дней -- это воспроизведение компьютером функции художественной критики (http://www.technologyreview.com/view/538281/machine-vision-algorithm-chooses-the-most-creative-paintings-in-history/). Компьютеру предъявили базу данных из 62тыс. картин разных лет и попросили указать наиболее творческие (creative). Как метрику творческости попросили использовать те картины, которые задавали какой-то основывающийся на них стиль рисования в будущем. И что? Компьютер, который уже имеет глазки, выявил такие картины -- и они совпали с теми, что указывают художественные критики. Вот, полюбуйтесь (вертикальная шкала как раз творческость -- картины с изобразительными новинками, которые лягут в основу других картин в будущем):

Several famous pictures stand out as being particularly novel and influential, such as Goya’s Christ crucified, Monet’s Haystacks at Chailly at sunrise and Munch’s The Scream. Other works of art stand out because they are not deemed creative, such as Rodin’s 1889 sculpture Danaid and Durer’s charcoal drawing of Barbara Durer dating from 1514. Фишка в том, что всё это было найдено автомагически, без участия человека. Авторы работы Elgammal and Saleh point out that it can also be used to explore creativity in literature, sculpture, and even in science.

Про кулинарную книгу Chef Watson я и не говорю, уникальные рецепты от компьютера не бог весть какое дело, но тоже ведь выход в попсу. Вот свеженькая дегустация http://www.engadget.com/2015/06/12/cooking-with-watson-caymanian-plantain-dessert/

На фоне этих достижений превосхождение компьютером людей в IQ тесте кажется чем-то незначительным (http://www.technologyreview.com/view/538431/deep-learning-machine-beats-humans-in-iq-test/). После победы в Jeopardy! и поступления в японские колледжи это ни разу не достижение, просто этим никто не занимался. Попсой раньше пренебрегали, IQ тест это ярковыраженная попса, сейчас до попсы дошли руки.

Нет, не всё ещё ОК -- так, подписи к картинкам компьютер ещё сочиняет плохо, лучший результат пока у компьютера только 27.3% подписей таких же или лучше человеческих, 31% подписей проходящих тест Тьюринга (http://mscoco.org/dataset/#leaderboard-cap). Но если моего отрока посадить делать подписи к 300тыс. самых разных картинок, вряд ли он сумеет лучше. Так что смело можно считать, что подростковых результатов компьютеры в распознавании изображений уже добились.

В глубоких архитектурах много чего нового: так, совсем недавно придумали как свёрточные сети выразить через рекуррентные (http://arxiv.org/abs/1505.00393). Хитростей в обучении-порождении и вариаций глубоких архитектур уже бездна. В отличие от 2011 года в эту предметную область уже за пару-тройку месяцев не войдёшь, несмотря на изобилие открытых библиотек, реализующих самые разные архитектуры на самых разных языках программирования (например, на моём любимом языке Julia библиотека для deep learning тут: https://github.com/pluskid/Mocha.jl).

Одно из радикальных направлений -- это дискретные вычисления на недискретных архитектурах. В 1995 году было доказано, что на глубоких статистических архитектурах можно решать дискретные проблемы (они эквивалентны машине Тьюринга, http://binds.cs.umass.edu/papers/1995_Siegelmann_Science.pdf). С тех пор решение дискретных проблем недискретыми методами довольно продвинулось. Выдвигаются новые виды архитектур, одни из последних -- нейронные машины Тьюринга, Reinforcement Learning Neural Turing Machines, http://arxiv.org/abs/1505.00521 (выражает вычислительные шаги лучше, чем глубогие нейронные сети), "указательные сети", pointer networks: http://arxiv.org/abs/1506.03134, и много-много других похожих, уже не-нейронных архитектур. Гуд бай, монополия фон-неймановских и гарвардских архитектур!

Вообще, гибридные вычисления, точное моделирование против "научения исключительно на примерах" стоят в эпицентре. Вот тут провозглашается, что "Святой Грааль deep learning -- это научиться эффективно обрабатывать инварианты, типа повороты в изображениях": http://www.inference.vc/the-holy-gr/, ход на "точные вычисления". А вот тут просто изображения для тренировки сетки дополнительно поворачиваются, чтобы учесть эти инварианты -- действие, явно антиэффективное (но результативное): http://benanne.github.io/2015/03/17/plankton.html (тут классифицировали планктон по его изображению). Я верю, что одновременно будут развиваться оба подхода: и "мозг должен что-то уметь с самого начала, эффективно работать с инвариантами", и "мозг ничего не знает о мире, дайте ему достаточно времени, и он всему научится сам".

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

Нейроморфные архитектуры тем самым становятся из перспективных-для-учёных попсово-перспективными. GPU признаются как временное дешёвое неудобное малоэффективное решение, начинаются эксперименты с FPGA (http://cadlab.cs.ucla.edu/~cong/slides/fpga2015_chen.pdf) и появляются первые ориентиры для достигаемой плотности вычислений (гигаопераций в секунду на FPGA slice -- рекорд сейчас вполне сравним с достигаемым на GPU ускорением, примерно в 17 раз). Как только эти ориентиры будут сформированы, произойдёт что-то типа "гонки гигагерц" и "гонки мегапикселей". С этим направлением сильно пересекается понимание, что глубокие архитектуры не требуют большой разрядности (работ на эту тему пока мало, но они уже появляются: http://petewarden.com/2015/05/23/why-are-eight-bits-enough-for-deep-neural-networks/).

Главное, это не допускать никаких дискуссий по AGI тематике, никакого "сильного искусственного интеллекта". Уже грустно шутят, что "недавно люди печалились, что в области AI ничего не происходит, а сейчас печалятся, что происходит слишком много". Выход в попсу как кормит, так и убивает на корню.

В любом случае, я бы глубоко приветствовал попсовые приложения -- занятия искусственным интеллектом должны стать народными. Когда-то Женя Самойлович мне объяснял, что никакие силы не заставят людей учить иностранный язык, чтобы читать на нём научную литературу. А вот чтобы прочесть в подлиннике Достоевского или даже Гомера -- таких людей может найтись неожиданно много. Поэтому если хочется, чтобы твой язык учили, заимей пишущих на нём великих писателей -- обратись к народу с художественным словом. Так и в случае задач искусственного интеллекта нужно обратиться к народу с художественным, а не научным словом. Пусть машина расскажет лучший в мире рэп, даст лучшую в мире литературную критику, и тогда много-много людей заинтересуются языком, на котором это всё написано: им захочется познакомиться с глубокими архитектурами и выучить Python, Lua, Julia.
2019

lytdybr

Буду рассказывать про моделеориентированность в инженерии на 93 заседании Русского отделения INCOSE в эту среду. Ужо намоделируюсь в этом году по самое не балуйся! Вот только несколько ссылочек на материалы:
-- группы AtlanMod: http://www.emn.fr/z-info/atlanmod/index.php/Main_Page
-- инициативы INCOSE MBSE: http://www.omgwiki.org/MBSE/doku.php
-- свежий доклад [бывшего руководителя AtlanMod] Jean Bezivin: http://cbi2014.unige.ch/documents/CBI2014.TowardsCrossDisciplinaryPractices.JeanBezivin.pdf
-- постановки задачи SysMoLan: http://ailev.livejournal.com/1127145.html

Неприлично положительная рецензия на моё первое занятие по курсу MBSE 2014 в МФТИ -- https://www.facebook.com/photo.php?fbid=806740249347805&set=a.257039637651205.63013.100000355115101 (за сутки 45 лайков, ой-ой).

Заработала кнопочка экспорта-импорта по технологии ISO 15926 в одном из распространённых САПРов -- реализация на .15926 Editor, всё необходимое в версии 1.5beta2 уже есть, "генератор адаптеров" вполне себе работает, паттерны данных рулят. Через недельку попробуем продемонстрировать всё это на FIATECH, и тогда уж расскажем поподробней. Кстати, в языке паттернов версии 1.5beta2 уже появилась лямбда: паттерн может вызывать какую-то внешнюю обработку для себя (например, сделать какую-то подстановку в имя перед записью в граф). Работа над SysMoLan тоже потихоньку двигается.

Семь моих фоток с конференции BigData 19 сентября: https://www.facebook.com/ailevenchuk/timeline/story?ut=60&wstart=0&wend=1412146799&hash=-1411944809004787995

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

Мой немецкий идёт ни шатко, ни валко, ни на сторону. По идее, я должен уже знать 780 слов (по счётчику duolingo) и лихо переводить текст в обе стороны, бодро распознавать беглую немецкую речь и отчётливо выговаривать несуществующие в русском и английском звуки в ich liebe dich. Но вот чёрта с два. Хотя через неделю будет уже целых два месяца с момента начала изучения языка, но у меня отнюдь нет уверенного A1 (хотя "уверенный A1", как я понимаю, относится к беспроблемной сдаче соответствующего экзамена, а не к беспроблемному знанию соответствующего уровня языка).
2019

Основы: контрольные вопросы по состоянию проекта

Контрольные вопросы по состоянию проекта разработки программной системы (чеклисты из Essence) определены в стандарте Основ (OMG Essence -- сущности и язык для методов программной инженерии, http://ailev.livejournal.com/1051048.html), но использоваться должны по правилам из книжки Cheklists Manifesto (http://ailev.livejournal.com/1029295.html).

Я постарался перевести эти контрольные вопросы для сущностных альф Основ на русский, заодно собрав их в табличку:
Collapse )
Успешного вопрошания!
2019

Архимейт по-русски. Организация деятельности при поддержке "софта" и "железа"

1. Архитектурное описание предприятия: как сделать видимой организацию работ

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

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

Для описания архитектуры предприятия используется специальный язык Архимейт. Этот язык позволяет записать самое важное, что есть в организации предприятия -- и проигнорировать мелкие детали.

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

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

Для многих людей, назначенных архитекторами (особенно для тех, кто пришёл "из программистов" или "из сисадминов"), оказывается полной неожиданностью неминуемый переход от изображения на Архимейте результатов разных интервью в качестве "архитектурного описания as is" к сочинению "архитектурного описания to be" и немедленно следующему плотному общению с начальством по поводу превращения свежесочиненных диаграмм Архимейта в организационную реальность предприятия. Архимейт поможет вам в вашем деле не больше, чем спеллчекер и умение управляться со стилями Ворда в получении нобелевской премии по литературе.

Вы предупреждены.

2. Деятельность, "софт", "железо"

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

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

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

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

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

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

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

Еще есть комментарий и отношение связи комментария с какими-то другими элементами, а также рамочка для группировки элементов.

Вот и весь Архимейт, 54 понятия. Но не нужно обольщаться его простотой. В Великом и Могучем тоже всего 33 буквы.

4. Нужен не ты, нужен твой сервис.

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

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

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

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

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

Итоги года: чего прихвачено в ушедшем 2011г.

Прошлые итоги года -- http://ailev.livejournal.com/894876.html. Традиционно прочитал -- и удивился, насколько я полно реализовал мысль "я задумываюсь о тематическом downshifting", посещавшую меня в прошлом году. Не то чтобы мне удалось удавить мультитаскинг, но хотя бы чуть-чуть сузить мультитемье! Про остатки междисциплинарности я умолчу, ибо получилось эдакое междисциплинарное эээ... олиготемье.

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

Хихикну, что в 2011 году я опять начал писать код -- на Ершоле, ибо приходилось решать дитяткины задачки. Экспериментально выяснено, что рекурсивный обход произвольного лабиринта я еще способен написать! Также впервые за много лет написал несколько строчек на Си (точнее, его диалекте RobotC), попрограммировал на нём аппаратуру (не в первый раз. Так, в юности я программировал аппаратный фурье-преобразователь, эмулируя для него интерфейс IEC модулями универсальных портов крейта CAMAC -- и это было чуток посложней, чем управлять моторами Lego!) .

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

По факту этот семейный учебный акцент сказался и на структурировании моих работ, которые дополнились еще и образованием младшешкольников -- но общего отхода от структурирования (http://ailev.livejournal.com/843165.html) и проблематизаций (http://ailev.livejournal.com/867290.html) 2010 года не произошло.

1. Системная инженерия

Если первая половина года была в дожёвывании тематики требований (и становилось всё ясней и ясней, что никакой особой тематики требований нет, а есть тематика обсуждения системной архитектуры внешними по отношению к разработчикам людьми), то во второй половине года, наконец, был сдвиг в архитектурные работы. Это было не только "изучение", но и "разработка". Из самых крупных укажу только на СУЖЦ, об архитектуре которой у меня было множество постингов в 2011.

Наметился также сдвиг от тематики чистого управления жизненным циклом как предотвращения и обнаружения инженерных коллизий к проблематике порождения инженерных артефактов -- но в этой области мы пока ничего не делали сами (если не считать работы с ISO 15926 как необходимые для представления данных для такого порождения), только разнюхивали. Наиболее интересным из этого разнюхивания был контакт с людьми из группы системной инженерии исследовательской лаборатории IBM в Хайфе: они как раз участвовали в проектах META/METAII/iFAB, о необходимости более подробного разбирательства с каковыми я говорил в "проблематизации" 2010 года.

Я этот год был директором по исследованиям Русского отделения INCOSE, мы провели 18 заседаний в Москве (incose_ru), апрельскую трехдневную встречу в Бекасово, в июне встречали Бо Оппенгеймера с lean systems engineering в Москве и Асмуса Пандикова со standardisation в Нижнем Новгороде. В декабре прошли перевыборы Совета директоров Русского отделения INCOSE, и в 2012 году я продолжу быть директором по исследованиям.

Из многочисленных моих докладов и лекций хотелось бы особо выделить "Инженерия будущего", я выступал на эту тему в Нижнем Новгороде, Санкт-Петербурге и в Москве. С этой целью (чтобы люди не ловили на слух мудрёные слова и потом имели возможность поискать что-то в Гугле) я порезал на слайды постинг http://ailev.livejournal.com/934632.html, а затем эти слайды попали в качестве примера "как не нужно делать слайды" на одну из презентаций kapterev. Наиболее полная версия моего рассказа на тему "инженерии будущего" (видеозапись) -- http://incose-ru.livejournal.com/29605.html. В конце концов, я сформулировал тезис про четыре поколения системной инженерии -- и что нужно четко отдавать себе отчёт, каким именно поколением занимаешься (http://ailev.livejournal.com/936356.html).

И еще сформулировал, как трёхуровнево описывать информационные модели крупных инженерных объектов (http://ailev.livejournal.com/962773.html) -- этот короткий постинг я почему-то сочинял очень долго, и мне придется еще много раз к нему возвращаться. Ну, и про четыре поколения инженерных систем (бумага, документоцентрика, гибриды, датацентрика) тоже сформулировал (http://ailev.livejournal.com/965124.html) и даже добавил про пятое поколение как федерацию датацентрики (http://ailev.livejournal.com/965564.html).

По линии системной инженерии укрепилась роль TechInvestLab, как "научного руководителя", когда мы приглядываем за иностранными консультантами в больших проектах -- ибо за этими иностранцами нужен глаз да глаз, чтобы они выдавали работу действительно на международном уровне! Интересно, что с иностранцами в 2011г. я встречался главным образом не в Москве, а в Нижнем Новгороде, и оптом (на июньском Multi-D форуме -- http://ailev.livejournal.com/935544.html), и в розницу. Так, с автором DEMO профессором Jan Dietz мы в сентябре пили чай и дискутировали именно в Нижнем (http://ailev.livejournal.com/952625.html), хотя в общих проектах с ним еще и не успели поработать. Ничего, еще не вечер.

2. PraxOS: праксеологическая организационная система.

Как переход от системноинженерных задач к организационным я пытался разобраться с феноменом инженерного менеджмента (http://ailev.livejournal.com/926383.html) и его связью с системной инженерией, и даже стал первым членом ASEM из России. И сформулировал тему управления технологиями: http://ailev.livejournal.com/928711.html. Затем явно разделил метод на дисциплину (то, что кладут в голову) и технологию (то, что разворачивают на предприятии), http://ailev.livejournal.com/930608.html и прописал постановку задачи для моделе-ориентированного инженерного менеджмента -- http://ailev.livejournal.com/928876.html.

Но это всё задел на будущее. А в давно опубликованном роадмэпе PraxOS от разговоров по постановке задачи потихоньку переходим к делу. Было "прихвачено" две большие практики: adaptive case management (ACM, http://ailev.livejournal.com/946134.html и http://ailev.livejournal.com/948974.html) и архитектурная работа в Архимейте (ArchiMate).

Я сделал большую серию постингов "Архимейт по-русски" (http://ailev.livejournal.com/964544.html, http://ailev.livejournal.com/963548.html, http://ailev.livejournal.com/963190.html, http://ailev.livejournal.com/956829.html -- глоссарий, http://ailev.livejournal.com/956191.html, http://ailev.livejournal.com/955954.html), после чего долго и много рисовал диаграммы сам и комментировал чужие диаграммы. Я даже договорился с проектом Archi, что мы портируем этот редактор на русский язык (по тамошним планам это будет в конце января 2011).

ACM же позволило вернуться к пониманию 2007 года, ибо мы уже тогда сказали, что нужно смотреть на "работы" -- а уж "процессы" или "проекты" эти работы, это вторично. Главным софтом мы еще тогда назначили issue tracker, который люди из ACM считают как раз предшественником современных систем адаптивной работы с кейсами. А если начинать разбираться с кейсами и issues, заодно можно вернуться из "процесс-ориентированного подхода" (т.е. разговоров об онтологически трудновыявляемом и плохо понимаемом одинаково) к разборке с вещами (которые довольно просто выявляются, и все их понимают более-менее одинаково) -- как это было декларировано в октябре 2010 в "что лучше: процессы или вещи" (http://ailev.livejournal.com/867599.html).

Под самый Новый Год я даже сделал большой постинг с первой попыткой определить базовые понятия ОргЛана (http://praxos.livejournal.com/13689.html), ибо рассказывать о лучших методах организации нужно с использованием какого-то языка -- если нет правильного языка, то вместо рассказа будет невнятное мычание. Очень надеюсь, что мы в 2012 сумеем доопределить язык, получить редактор ОргЛана и приступить к формулированию "лучших оргметодов" с использованием этого языка. Главная проблема тут -- это очень четко показать связь между ПраксОС (который весь принадлежит methodology domain) и собственно деятельностью предпринятия (которая вся в endeavour).

Все основные результаты по ПраксОСу/ОргЛану я писал не у себя в ЖЖ (кроме редких исключений, типа обсуждения систем поддержки коллективной работы против систем поддержки оформления результатов работ http://ailev.livejournal.com/963821.html), а в praxos (там, кстати, на сегодня 89 читателей). За год там прошло всего 7 записей, но они преогромные как размеру текстов, так и по отраженной в них работе. Я очень доволен итогами года, продвижение несомненно.

3. Методология

В этом году у меня появилась гипотеза, что в основании всей знаниевой пирамиды, которую надлежит освоить современному человеку, лежит современная философская логика. Все попытки контактов с СМД-методологами оказались в этом смысле бесплодными: они не могут поддержать какую-то осмысленную беседу на эту тему, увы. Я даже посетил несколько заседаний логико-философского кружка и начал устанавливать контакты с логиками -- но тамошние люди оказались далеки от практики. В марте я ругался (http://ailev.livejournal.com/916260.html): "что, мне ходить обсуждать деятельность к СМД-методологам, 4D онтологии к аналитическим логикам, когнитивные архитектуры на ontolog-forum, языки в рассылке FONC и не иметь никакой возможности обсудить это всё во взаимосвязи в одной тусовке"?

Так что я попытался как-то восстановить мостик между "всем известными теоретиками прошлого", "малоизвестными теоретиками настоящего" и "широко известными в узких кругах практиками". Результаты этих штудий как-то обобщены в постингах "четырехмерие и охватизм" (http://ailev.livejournal.com/913373.html) и "ну, и какая у нас онтологическая традиция" (http://ailev.livejournal.com/952930.html).

И именно из этой точки начала вырастать моя образовательная программа.

На удивление, в этом году не дошли руки заняться стандартизацией как таковой. Еще у меня несколько месяцев в плане постингов болтается раскрытие темы еще одного места методологической работы: аналитические агентства (например, в IT это Gartner), которые занимаются выявлением трендов, стандартизируют в своих отчётах терминологию разговора об этих трендах, и тем самым кладут основу для последующей стандартизации в консорциумах. Но я не теряю надежды написать об этом в 2012.

4. .15926

В целом на работе мы пытались продолжать курс на то, чтобы работать не столько в городе, или даже стране, сколько сразу на глобусе -- если уж и работать, то нужно это делать по гамбургскому счёту, чтобы о результатах было не стыдно рассказать и на английском. Первый международный релиз нашего .15926 софта -- это самый продвинутый на тот момент Browser, конец марта 2011. В июне 2011 vvagr съездил на конференцию POSCCaesar в Осло, рассказал о наших планах, а в середине декабря мы в существенной мере эти планы реализовали (http://ailev.livejournal.com/968936.html, список фич http://levenchuk.com/2011/12/18/121/): выпустили freeware .15926 Editor с документацией на английском (хотя опубликовна еще и не вся документация -- но ждать уже недолго). Это самый мощный в мире редактор данных ISO 15926, так что есть чем хвастаться. Окончательно ясно: мы пошли по странному пути сочетания современного языка программирования (мультипарадигмального Python) и наикучерявейшей модели данных ISO 15926 -- то есть обработка делается процедурно, функционально, объектно, но никак не декларативно. Это и стало ISO 15926L. Софт планируется как платформа программирования, мы сейчас стабилизируем эту платформу, она насквозь плагинная -- поэтому исходных кодов пока не публикуем, версия 0.83 означает, что предыдущих семь версий кода движка (две в прошлом году, и шесть в этом -- т.е. в среднем раз в пару месяцев) было нами выкинуто на помойку истории. Этот редактор еще и реализует табличный язык TabLan -- и у ISO 15926 появилась инструментальная возможность быть гармонизованным с Gellish, если у кого-то будет такое желание и ресурсы на эту работу.

А еще в феврале мы выпустили на русском методику "ISO 15926 outside", в сентябре перевели ее на английский. Все эти результаты можно найти на http://techinvestlab.ru/ISO15926

Также ключевой итог года -- это формулирование программы самообразования для ISO 15926 (http://dot15926.livejournal.com/27293.html). Тут оказалось много хитростей, главная из которых -- нужно обязательно начинать с книжки BORO (http://ailev.livejournal.com/938647.html), в которой ISO 15926 не упоминается вообще, и используется абсолютно чуждая для ISO 15926 терминология!

Мы также организовали две тусовки русскоязычных любителей ISO 15928 ("фестиваль" в марте -- http://ailev.livejournal.com/919606.html, а в декабре -- прямо у нас в офисе, http://dot15926.livejournal.com/28051.html). Глобальные результаты всей этой деятельности: в комьюнити ISO 15926 в LinkedIn по статистике 7% членов из РФ, Россия легко соперничает по абсолютному числу интересующихся этой семантической технологией с любыми другими странами.

Комьюнити dot15926 выросло за год с 54 читающих до 87 человек -- но более важно то, что некоторые из них в этом году ещё и пишут.

Еще мы подняли наш внутренний RDL TechInvestLab на OpenVirtuoso, и ведем с ним сейчас активные эксперименты.

Меня по-прежнему волнует, что у нас полное отсутствие лингвистической компоненты. Но тут (спасибо IBM Watson) мы уже начали какие-то телодвижения навстречу разработчикам соответствующего софта, и ситуация становится понятней. Я даже написал программный постинг "нужен фордеф" (про формализатор-деформализатор), http://ailev.livejournal.com/969337.html.

Главное в 2012 году -- инструментарий для обеспечения модульности онтологий и администрирования библиотек справочных данных. Понятно, что для создания такого инструментария нам нужно будет серьезно разобраться с методами обеспечения коллективной онтологической работы.

5. Опенмета

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

6. Образование (младшеклассников, и не только)

Неожиданностью занятия образованием не являются: я еще в 2006 году в worldchanging (http://ailev.livejournal.com/368377.html) отмечал, что эти вопросы крутятся у меня в голове. Но тут где-то с апреля (http://ailev.livejournal.com/922715.html) я был втянут Анатолием Георгиевичем Кушниренко в проект "дошкольная алгоритмика" (в августе уже было http://ailev.livejournal.com/948015.html), и в итоге мой дитятко освоил программирование на Ершоле в объеме половины программы седьмого класса физ-матшколы. Ужас оказался в том, что в ходе прохождения этого курса стало непонятно, чему по этой алгоритмической линии его учить дальше -- и я уже месяц как присматриваюсь к робототехнике (http://ailev.livejournal.com/967480.html, http://ailev.livejournal.com/970810.html, http://ailev.livejournal.com/969556.html, http://ailev.livejournal.com/971904.html). Поэтому весь декабрь поверх обычного учебного гумуса все горизонтальные поверхности в квартире еще и равномерно покрылось Lego в ассортименте (а ассортимент у Lego, нужно заметить, разнообразный), плюс около компьютера стоит программируемый на RobotC робот-тележка, умеющий уже бегать по линии.

Это неожиданное для меня в 2010 году учительство собственного малолетки успело в 2011 выйти и за рамки чисто семейных занятий: у нас в офисе прошел семинар "дошкольная алгоритмика" (мои тезисы к нему -- http://ailev.livejournal.com/966480.html, а видео -- http://ailev.livejournal.com/966698.html), буквально на днях должен пройти еще один семинар по "преподаванию умности" -- это явно эхо моих публикаций. Весь 2011 год я много писал на школьно-образовательные темы, причем меня интересовал главным образом методический аспект: если догадаться а) чему учить самому базовому и б) как этому учить, то можно сэкономить много-много нервов и времени: ибо знание принципов существенно освобождает от знания фактов. На всякий случай disclaimer: меня мало волнует устройство школьного образования в России или какой другой стране, меня волнует, как учить малых детишек. Более того, по мере подрастания моего собственного дитя, меня будет волновать, как учить уже не очень малых детишек -- мой образовательный интерес еще и непостоянен! Понятно, что алгоритмика, логика, философская логика (я даже сформулировал что-то про ОнтоЛан и ОнтоМир в ряду других учебных сред -- http://ailev.livejournal.com/955671.html и http://ailev.livejournal.com/953444.html), математика (мои вопрошания, по бОльшей части никем не понятые: http://ailev.livejournal.com/970638.html) тут неразделимы и где-то в эпицентре такого образования. "Картину мира для младшеклассников" (http://ailev.livejournal.com/950308.html) я продолжаю копать дальше.

Основная идея -- это то, что для выхода на упражнения (решения задач) нужно иметь цепочку языков разного уровня сложности: от примитивных до полноценных "взрослых". Тем самым, "формальноязыково-ориентированное" образование получается нацеленным на умение моделировать и далее работать с формальными моделями. Но чистой "языковости" мало: нужно еще иметь правильно подобные "миры", которые обеспечивают наглядность для языковой среды -- тем самым "базовые языки моделирования" должны предусматривать какой-то выход на модульность по отношению к этим мирам (пример -- "исполнители" и их "миры" в КуМире). Задачи и упражнения формулируются в Мирах, а их решения делаются на Языке (обычно общем для нескольких миров). И при создании этой цепочки нужно помнить о van Bethem (http://ailev.livejournal.com/915253.html), переводя это на все формальные языки: "...говорить о логике как о науке,цель которой в значительной мере определяется поиском определенного баланса между выразительной силой формальных языков и многосложностью их использования при решении таких задач как осуществление контроля за согласованностью, адекватностью моделирования и правильностью вывода". Тут можно опять помянуть фордеф и "математический" (без связи с реальным миром -- только формальные преобразования) и "моделирующий" (с соблюдением каких-то соответствий формализма реальному миру) подход к образованию. Саму мысль о том, что инженера литературе можно обучить, а вот литератора инженерии уже вряд ли я даже повторять не буду: это к дискуссии о том, что базово в образовании. Образование тем и отличается от просто (профессионального) обучения, что после него повышается разнообразие возможных жизненных траекторий, а не сужается. Ну, и последовательность в образовании тоже важна: сначала "наука" (умение что-то описать), потом "инженерия" (умение что-то коллективно сделать в реальности по сочиненным описаниям), и всё это еще в школе, не откладывая до ВУЗа -- http://ailev.livejournal.com/955671.html.

Но я отметился не только в образовании для младшеклассников, я еще сделал несколько постингов про образование великовозрастных программистов, из которых можно особо выделить -- http://ailev.livejournal.com/907435.html, http://ailev.livejournal.com/937201.html, и "виртуальный доклад" http://ailev.livejournal.com/937397.html. И даже цеплянул тему музыкального образования: http://ailev.livejournal.com/944960.html и http://ailev.livejournal.com/951435.html. А еще раскочегарился на формулирование эскиза образовательного проекта -- http://ailev.livejournal.com/961237.html.

Вот и все мои "тематические" достижения, остальное попадает в раздел "разное".

Политэкономических штудий у меня почти не было, несмотря на заявленную в прошлом году программу -- не считать же попытки формулирования своих интересов в либерализме (http://ailev.livejournal.com/919184.html, http://ailev.livejournal.com/924734.html) и лёгкие огрызания по поводу текущей политики (например, об митинги http://ailev.livejournal.com/971177.html) какими-то "штудиями"! Кроме Лебедевских чтений (которые прошли штатно 21 мая, http://ailev.livejournal.com/931975.html, и запомнились как раз "гладкостью" -- значит, нужно что-то менять!), мы провели еще в январе прошлого года посиделку "праксеология и логика" (http://ailev.livejournal.com/899308.html) -- но ничего существенного из этой посиделки за год не получилось. Тем не менее, я этой темы формализации (раскрытия философско-логических оснований -- "априорности" праксеологии) бросать не намерен. Сейчас у нас есть инструментарий онтологической работы (тот же .15926 Editor), подходы к ОргЛану, так что всё только начинается.

Путешествовал я по меркам последнего десятка лет очень много: побывал с семьёй в сентябре в Барселоне и в ноябре в Риме, выступал на конференции в Санкт-Петербурге, а про чуть ли не десяток командировок в Нижний я уже написал.

Год был не слишком богат на железные гаджеты: можно, конечно, считать гаджетом Lego Mindstorms NXT 2.0, но это дитенке. Ну, еще мне подарили iPod 2, но он тоже пошёл жене и дитенку. Купленный объектив 14-140 для Lumix GF-1 тоже был для жены. И еще купил 802.11n роутеры ASUS -- незабываемые ощущения от наблюдения за 9.6Мbyte/sec downloading на дитенкином десктопе, ибо мои входные 100Мбит/сек вполне теперь дотягиваются и до дальних комнат. Себе я только обновил в сентябре дисплей на рабочем месте (http://ailev.livejournal.com/953609.html), да поменял телефон на Galaxy Nexus, буквально неделю назад. Да, еще месяц назад купил очередную электробритву Brown Series 7, даже не очень топовую -- и восхитился тамошними "50 минут на одной зарядке" при вполне приличных ножах.

Увы, за год так и не собрался восстановить мою домашнюю сетку: три компьютера и дисковый плеер пали смертью храбрых, так и не дождавшись ремонта. И чёрт бы с ними, но данных жалко -- там ведь везде были RAID-массивы...

На самокате не просто в этом году "катался" -- он был всю весну, лето и осень основным транспортом!

Из интернет-гаджетов продолжил платить за vimeo.com, pandora.com, добавил к своим платным сервисам smtp2go.com и Hotspot Shield Elite. Гаджетом года стал с большим отрывом от всех бесплатный mikogo.com -- но его самые удобные фичи перешли в разряд платных буквально месяц назад, и теперь я планирую заплатить и за этот сервис.

К списку просматриваемых лент добавил очень узенький список на Фейсбуке (много уже, чем число автоматически там зафрендованных -- ибо у меня там политика автоматического френдования всех, кто постучится). Я там по-прежнему ничего и не пишу -- только транслирую постинги отсюда. Хотя очень изредка не удерживаюсь и что-то комментирую. Число френдов в ЖЖ окончательно стабилизиовалось (что показывает: я не попсею) -- год назад было 1458 френдов, сейчас 1612. Оказалось, что это совсем ничего не значащие цифры, и даже не из-за большого количества спамботов и "мёртвых душ". Просто меня читают и через френдфид, и через фейсбук, и даже через Гугль Ридер (http://ailev.livejournal.com/948685.html). У меня такая догадка, что число моих "живых" читателей сейчас порядка двух тысяч человек. Очень забавно было получить почетную грамоту, в которой я был поименован как "блоггер": http://ailev.livejournal.com/957226.html

Не помню, какие художественные книжки я читал в этом году (хотя помню, что что-то читал -- с экрана, не в бумаге). В начале года я был опечален тем, что в художественной литературе главным образом показывают развитие чувствовалки и упорства, но не показывают развитие думалки (http://ailev.livejournal.com/903228.html), и даже попытался написать рецензию на Nodame Cantabile как на производственный роман (http://ailev.livejournal.com/918476.html, а всего у меня за 2011 год чуть ли не десяток постингов, касающихся тех или иных анимешек). А потом просто продолжил смотреть анимешки (http://ailev.livejournal.com/949633.html), чем сильно расширил свой подзаржавевший на традиционных жанрах художественный опыт. Всё-таки в 21 веке живём, и развитие чувствовалки возможно не только на примере заскорузлых от многовекового употребления жанров. Эти анимешки мне в один глаз влетают, в другое ухо вылетают точно так же, как и художества традиционных жанров -- пересказать сюжеты вряд ли смогу внятно, имён персонажей тоже не запоминаю. Но я не расстраиваюсь: жизнь показывает, что это всё это где-то откладывается в правильных закоулках памяти. Какую-то беседу на анимешную тему я уже могу поддержать, имея личный опыт просмотра, а не опыт чтения аннотаций и рецензий. Из тех вебсайтов, которые мне в этом помогали в 2011, я особо отметил бы http://anidb.net, http://www.animeultima.tv/ (английские переводы) и http://myvi.ru (русские переводы, только не раздел "аниме", в котором собираются версии с голосовым переводом -- я как раз полюбил смотреть с субтитрами). Мангу пробовал полюбить, но ни одной целиком так и не смог одолеть -- это искусство уж точно не моё. После этого года я могу точно сказать: я совсем не отаку (в любом смысле этого слова), и отаку мне никогда не стать...

Еще вдруг заметил, что кроме бразильской музыки иногда начинаю переключаться на японскую -- чаще всего после того, как в каких-нибудь анимешках встречаю что-то необычное, например ALI PROJECT (http://ailev.livejournal.com/937873.html). А для тех, кто дочитал до этого места -- эксклюзив, которого в других постингах не было. Вот музыка opening к одной из анимешек нынешней осени. Сама анимешка "никакая", но послушайте ритмику этой музыки -- http://www.youtube.com/watch?v=3L6zP5xkHjU (половина видео -- это показ прохождения видеоигры, где нужно точно простучать партию ударных вместе с музыкой. А вторая половина -- это прохождение только для партии ударных, чтобы вы окончательно удивились). Так что с этого года я начинаю потихоньку любить современную японскую музыку, в ней есть что послушать.

Еда года -- мороженное. Его я в 2011 съел немеренно, и не только летом. А еще нежно вспоминаю лагман из нижегородского заведения "Тако". Едал я и разные другие лагманы -- но с тем лагманом (пробовал дважды в разные приезды) никакого сравнения. Антиеда года, несомненно, была вездесущая испанская "хамбурхуеса".

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

А теперь интересно мнение читателей моего ЖЖ -- что я в 2011 сделал самого крутого?