Лабораторный журнал
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 20 most recent journal entries recorded in Anatoly Levenchuk's LiveJournal:

    [ << Previous 20 ]
    Saturday, September 20th, 2014
    11:14 pm
    Курс практик MBSE 2014 в МФТИ -- занятие 1
    По традиции даю ссылки на доп.материалы по некоторым затронутым вопросам:
    -- как зажечь мастерство: http://ailev.livejournal.com/1130190.html (оценка затрат труда на одно занятие прошлого семестра у лучшего студента: 3 часа очное занятие + 3 часа внимательное чтение материала к занятию + 2 часа работы над вопросами к своему проекту = 8 астрономических часов * 8 занятий = 64 астрономических часа. Можно ли освоить системноинженерное мышление за 64 астрономических часа?!).
    -- темы второго курса и типы затрагиваемых систем: http://ailev.livejournal.com/1136987.html
    -- INCOSE Systems Engineering Vision 2025 -- http://www.incose.org/newsevents/announcements/docs/SystemsEngineeringVision_2025_June2014.pdf (а более подробное обсуждение затронутых вопросов -- видео доклада http://incose-ru.livejournal.com/49015.html).
    -- изготовление детекторного приёмника с самодельными детекторами, наушниками и т.д.: http://saveyou.ru/forum/showthread.php?t=1200 (там много-много страниц в этом треде, колоритное обсуждение от "выживальщиков").
    -- event management: http://en.wikipedia.org/wiki/Event_management
    -- основные ограничения системноинженерного мышления: наука, сверхсложные объекты, системы с людьми -- все прописаны в книжке прошлого курса (http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf).

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

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

    Занятия в помещении на Клементовском, горячий шоколад в тамошних автоматах есть -- только нужно не забывать нажимать кнопку "Меньше сахара", чтобы не наливали шоколадный сироп. Но главное не в помещении, а в дороге: велосипедная дорожка из гладкого асфальта на Пятницкой. На самокатике по ней в самый раз.
    Friday, September 19th, 2014
    5:32 pm
    Об BigData
    Выступал сегодня на конференции BigData Russia в DI Telegraph (http://bigdatarussia.ru/), высказал пару-тройку не новых мыслей:

    1. Термин BigData чем дальше в лес, тем более маркетинговый -- зонтик для каких угодно алгоритмов над какими угодно данными, и не в величине этих данных дело. Оговорочки докладчиков типа "большие BigData" много чего стоят. Можно говорить просто Data, не ошибётесь (ivbeg в своём выступлении на этой конференции так и сказал, что сегодня пик популярности термина, а дальше он сдохнет так же быстро, как Internet 2.0, Internet 3.0 и прочие из этой серии. Дальше будут просто Data -- и я с Иваном в этом вопросе совершенно согласен).

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

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

    3. Все эти дискуссии про открытые и закрытые данные -- это политические дискуссии. Что у одних боевики, то у других ополченцы. Что у одних разведчики-герои, у других шпионы-гады. Что одни хотят открыть, другие хотят закрыть. И пока нет чётких моральных ориентиров, участвовать в таких дискуссиях бессмысленно.

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

    4. Основной тезис про семантику и онтологии:
    -- семантика (трипл-сторы, графовые базы данных и т.д.) снимают проклятие табличных и объект-ориентированных представлений. В факт-ориентированных представлениях не нужно каждый раз проводить переструктурирование схемы базы данных при добавлении нового куска схемы данных. Триплы сожрут всё и не подавятся.
    -- онтология появляется там и тогда, где и когда нужно объединять данные для осмысленной их обработки, а не просто хранить разнородную информацию.
    -- это независимые ходы. Вполне можно работать с онтологиями в объектно-ориентированных базах данных (например, современные PLM/CAD/CAE именно так устроены: в них есть upper untology, в которой прописано общее устройство мира -- наличие функциональных объектов, физических объектов, процессов и т.д., но модель данных объект-ориентированная или даже реляционная), можно без онтологий работать с семантическими моделями данных (так работают с OWL-онтиками, т.е. факт-ориентированными описаниями отдельных кусочков мира, которые затем оказываются абсолютно неинтегрируемыми друг с другом). Конечно, онтологическая и семантическая работа одновременно является выигрышной, но learning curve таких решений запредельно велика, ибо этот подход поддерживается пока крайне малым числом инструментов. В IT побеждают не столько хорошие идеи, сколько хорошие инструменты. Так что для массового распространения семантического и онтологического одновременно подхода в работе с данными придётся немного подождать. Disclaimer: TechInvestLab как раз делает такой инструмент -- .15926 Editor (http://techinvestlab.ru/dot15926Editor -- кстати, мы позавчера выложили вторую бету версии 1.5, качайте и пользуйтесь).

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

    UPDATE: неожиданно в FB несколько содержательных комментов к этому посту -- https://www.facebook.com/ailevenchuk/posts/10203228046836034
    Thursday, September 18th, 2014
    2:38 pm
    Как будут делаться вещи
    Чудесная презентация Carl Bass (CEO of 3D design, Autodesk) по современным изменениям в инженерии -- 25 минут плотнейшего рассказа про 3D промышленную печать и её ограничения, преимущества облачных САПР, выращивание вещей биоинженерным методом, порождающее проектирование (http://youtu.be/eAfVF1ne_1M):

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

    Вокруг меня сейчас много разговоров про импортзамещение, собственные САПР и PLM, операционные системы и чипы. Это от мёртвого осла догоняющее развитие. Нормальную конкурентную в мировом масштабе разработку "импортзамещением" не называют. Нужно не выделываться, а вписываться в мировое развитие -- а оно сейчас происходит внезапно и быстро, и сегодня для только начинающихся разработок нужно ставить невозможные цели, чтобы через несколько лет работы иметь шанс оказаться в толпе таких же разработчиков, а не любоваться задницами убежавших вперёд.

    Выбор риска быть в первых рядах или без риска любоваться задницами впереди идущих -- это уж личные предпочтения каждого.
    Wednesday, September 17th, 2014
    10:49 pm
    Системноинженерное мышление -- это прежде всего про физические объекты
    Провёл сегодня вечером мастер-класс для архитекторов предприятия (http://gamechangers.ru/tracks/enterprise-architecture). Обратная связь была очень интересна: больше всего студентов зацепило, что "система -- это физический объект". У меня редко кто этому удивлялся, даже в группах с преобладанием программистов. Но вот думать о предприятии или мероприятии как о физическом объекте людям вдруг оказалось странно и непривычно.

    Это ложное впечатление, что инженер работал раньше с чертежами, а сейчас с моделерами. Нет, инженер работал и работает с физическими объектами, а чертежи и моделеры нужны ему только потому, что без этого трудно изменить реальность, изменить физический мир, получить желаемые физические объекты. Целевая система -- это физическая система.

    Вот он я, методолог системной инженерии, писатель блогов и работник прочего умственного труда. Но когда я нахожусь на инженерном объекте, то послушно надеваю каску (на фото я изображён позавчерашний):
    levenchuk_ingr
    Ибо физическая реальность -- это вам не мышкой кликать. Мышкой кликать нужно лишь для того, чтобы потом был повод надеть каску -- система для своего воплощения должна выйти из битов в атомы, и этот выход не всегда безопасен. А когда всё уже сооружено и безопасно, кликать мышкой и носить каски уже не нужно будет, разве что во время очередной модернизации.
    Tuesday, September 16th, 2014
    10:08 pm
    Три тома по системной инженерии.
    Мой один томик по системноинженерному мышлению нужно превращать в три томика. Вот примерное содержание:

    1. Системноинженерное мышление в управлении жизненным циклом: уже написан (http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf).

    2. Практики моделеориентированной системной инженерии.
    -- Моделеориентированная системная инженерия (понятие модели, языки моделирования и моделеры в отличие от языков программирования и компиляторов, практики моделирования)
    -- Моделеориентированная инженерия требований (GORE+Use Cases)
    -- Моделеориентированная инженерия системной архитектуры (Компоненты: мультифизика и принципиальные схемы -- modelica. Модули: DSM, product lines. ТРИЗ. Практики порождения, поиск-ориентированная инженерия).
    -- Управление жизненным циклом (agile и lean, concurrent engineering, управление конфигурацией и изменениями, управление информацией).
    -- Практики воплощения: внимание к правой части V-диаграммы (advancing manufacturing, cyber-physical production systems, etc.).
    -- Проверка и приёмка (в том числе автоматизация испытаний/тестирования).

    3. Разнообразие инженерных систем
    -- Инженерия предпринятия [раздел восемь в первом томике, уже написан)
    -- Инженерия кибер-физических систем (resilient, адаптивные системы, жизненный цикл и моделирование)
    -- Программная инженерия
    -- Инженерия обучающих сервисов [в отличие от "организации образования" как менеджмента]
    -- Инженерия мероприятий [в отличие от event management]
    -- Инженерия психики
    -- Биоинженерия
    -- Инженерия нейронета [чтобы мозги не заржавели. Пример network intensive system, основанной на стандартах -- типа интернета, SmartGrid и т.д.]

    Проблема в том, что писать самому всё это не только трудно, но и не совсем правильно. А студенты хорошо не напишут. Так что всё будет, но будет меееееееееееедленно. Либо когда у самого руки дойдут (судя по скорости выпуска предыдущего тома, это по одному тому в год), либо когда студенты подрастут, перестанут быть студентами и помогут.
    Saturday, September 13th, 2014
    9:54 pm
    AINL 2014 -- день второй
    Сегодня искусственным интеллектом на конференции AINL (http://ainlconf.ru/agenda) уже немножко пахло (хотя кто-то пошутил, что это пока запах запаха искусственного интеллекта, но всё же). Было хорошо и интересно.

    Что я понял изо всех этих дней:

    1. Тотальный переход от плоских (flat) к иерархическим/глубоким статистическим архитектурам, в самых разных школах (языки у всех различаются, идеи похожи):
    -- deep learning, само собой
    -- hierarchical reinforcement learning (ага, обработка текстов в агентской парадигме -- так разговаривает робот Nao), иерархизация существенно улучшает качество работы
    -- в архитектурах-на-правилах работа с микротеориями-на-правилах и более-статистическим-диспетчированием между ними (пример: чатбот Евгений Густман), работа на вручную кодируемых правилах не получается и очень трудоёмка, вынужденно появляется "диспетчирование" между предметными модулями-микротеориями.

    2. Об онтологиях лингвисты уже знают, многие хотят попробовать -- ибо статистика не даёт понимания текста (хотя и позволяет делать короткие пробежки по "сочетаемости слов" вместо логического вывода -- всё больше и больше таких материалов). Но не получается пока (рутина, текучка и т.д.). Впрочем, я писал об этом по материалам первого дня: http://ailev.livejournal.com/1136444.html.

    3. "Платформу" и "инструментарий" развивать и демонстрировать бесполезно, нужно развивать и демонстрировать killer application. Впрочем, это было понятно и до этой конференции. Из killer application у лингвистов пока наблюдаются только боты хелп-деска (и многие из них живут только до прихода на этот рынок продуктов типа IBM Watson Adviser). Всё остальное это гранты и студенты, студенты и гранты.
    Friday, September 12th, 2014
    10:10 pm
    AINL 2014 -- день первый
    Сходил сегодня на конференцию AINL (http://ainlconf.ru/agenda) -- искусственный интеллект и естественный язык. Лингвистики было в количестве, искусственный интеллект пока не детектед. Совсем не детектед, что очень жаль.

    Тусовка хвастается значениями метрик F1 для узнавания чего-то в текстах (http://en.wikipedia.org/wiki/F1_score, а "на пальцах" и по-русски, например, http://blog.gramant.ru/2012/06/06/f1-measure/). Узнаётся у каждого что-то своё высокоспецифичное, а значения метрики сегодня у людей типовая выше 0.9, у университетских узкоспециализированных программ 0.8, у коммерческих "унивесальных движков" порядка 0.7. Новички легко выходят на 0.6, а дальше нужно учиться.

    Как я понял, опытные лингвисты уже прониклись необходимостью обращения к онтологиям, ибо уже понимают, что без них нельзя нынешние инвалидные лингвистические программы быстро-быстро исключительно глубокими нейронными сетками и прочими "машинными обучениями" доводить до гипервалидных с F1 лучше, чем у усталого и не очень внимательного человека не-лингвиста. В докладе ABBYY отметили, что их технологию сегодня делают человек 30 лингвистов и человек 10 онтологов (хотя тут нужно ещё разобраться, онтология ли там, или по-прежнему "онтолого-лингвистическая сеть"). Но пример ABBYY почти исключительный: онтологи среди лингвистов пока почти не встречаются.

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

    Я проверил сегодня: в нашем онтологическом редакторе .15926 Editor (freeware, http://techinvestlab.ru/dot15926Editor) команда "import nltk" отличненько работает. Хотя большинство стендовых докладов ориентировались не на NLTK, а на Yandex Tomita Parser (http://api.yandex.ru/tomita/). Но ежели хочется быстро-быстро попробовать всю мощь связки современных технологий обработки текстов и онтологических технологий, то у нас оказывается не самый плохой для этого инструментарий.

    Завтра тоже планирую пойти. Завтрашние темы даже поинтересней сегодняшних (обещают много разного рассказать про лингвистическое обеспечение для роботов).
    Wednesday, September 10th, 2014
    11:58 pm
    Доклад по трендам в инженерии требований и управлении требованиями
    Сделал сегодня на семинаре IBM доклад по трендам в инженерии требований и управлении требованиями на основании анализа INCOSE SE Vision 2025 (хинт: не столько того, что в этом Vision было, сколько того, чего там не было -- user needs и architecture там помянуты несчётное число раз, а вот находящиеся промеж них requirements практически не встречаются). Вот слайды (http://www.slideshare.net/ailev/ss-38938621):


    Из новых слайдов там немножко про понятие user needs по сравнению с требованиями.

    Там есть как минимум одна не слишком тривиальная мысль: приход машин, интерпретирующих тексты (а хоть и того же IBM Watson), означает, что в числе user needs и requirements будут продолжать оставаться тексты на естественном языке. Ибо исследования того же IBM Watson показали, что при формализации этих текстовых требований неизбежно будет исчезать информация -- и необходимо хранить для альтернативных формализаций исходные тексты, а не только распарсированную в какой-нибудь семантических граф формальную модель. Собственно, это та же мысль, которую регулярно высказывает Donald Firesmith про архитектуру: не все архитектурные рабочие продукты должны быть именно моделями, текстам на естественном языке там тоже есть место. Требования (как и архитектура) этого не избегают, и это неожиданно может дать вторую молодость продуктам типа DOORS или IRqA.

    Куда же ушли "требования"? А никуда: просто они появляются как маленький элемент в моделях GORE, в которых кроме требований много чего связанного с user needs, связями с user cases (из которых эти требования появляются), кусками архитектуры, зависящими от требований и т.д.. Сферические модели требований в вакууме не выживают, и поэтому "моделирование" включает в себя и архитектуру, и требования тоже -- моделирование ведь не только "архитектурное моделирование"! И не только "исполняемые численные модели", но и модели с элементами-текстами-на-естественном-языке в узлах какого-нибудь графа, созданного по метамодели GORE.
    Tuesday, September 9th, 2014
    10:55 pm
    Философия науки, техники, инженерии. Китайские передовые исследования.
    Бао Оу: "Мне хотелось бы обобщить результаты передовых исследований китайских ученых, изложить основные вопросы философии инженерии, касающиеся философских предпосылок, породивших философию инженерии, отправных пунктов аргументации в сфере философии инженерии, а также специфики инженерного мышления" -- http://vphil.ru/index.php?option=com_content&task=view&id=986&Itemid=52

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

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

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

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

    В Essence практика=дисциплина+технология. Дисциплина в голову (т.е. это знания, "теория"), а техника (инструменты и формы рабочих продуктов с инструкциями по их использованию -- причём они поддерживают дисциплину) разворачиваются "на местности" -- вместе же они рождают практику работы. Инженеры используют практики, соединяя их в метод. Наука даёт методы описания. Философам до этих всех различений ещё тупить и тупить много лет, а инженеры (особенно инженеры-методологи, инженеры методов) уже давно это обсуждают -- и даже создают на этот счёт свои методы описания (то есть занимаются и наукой тоже).
    Monday, September 8th, 2014
    12:26 pm
    Биткойны и Мизес. Что после биткойнов.
    Свеженькое про биткойны и Мизеса: http://www.fee.org/the_freeman/detail/what-gave-bitcoin-its-value (перевод на русский: http://bitnovosti.com/2014/09/07/v-chem-istochnik-stoimosti/).

    Книги австрийской школы экономики (в том числе тексты Мизеса) на русском в количестве тут: http://www.sotsium.ru. Вот самая знаменитая книжка Мизеса на русском в открытом доступе: http://libertarium.ru/l_lib_socialism0

    Про частные деньги я писал и в 1999 году, тогда это казалось почти несбыточным и почему-то связывалось с неурядицами денежного обращения в России (вот, например -- рубрика была "Либертариум на Полит.ру": http://polit.ru/article/1999/04/08/473734/).

    Но частные деньги в отсутствие государственного центрального банка -- это ещё не вся история. Ещё из свеженького на эту тему: как Виталик Бутерин переустраивает интернет по принципам биткойна: http://bitnovosti.com/2014/09/05/20letniy-vunderkind/.

    У рынка и свободы должна быть своя инфраструктура. И всё больше людей понимают, что принципы частных денег можно приложить и к финансовым инструментам произвольного вида как таковым, в том числе и контрактам. Я писал на эти темы ещё в 1998 году в Компьютерре. Более того, не все прогнозы того времени сбылись -- там ведь ещё было про "сначала деньги, а потом уже финструменты -- ибо они сложнее" (процесс уже идёт: "Розничная сеть Overstock.com и ее генеральный директор Патрик Бирн надеются создать новый вид ценных бумаг на основе блокчейна Биткойна, намереваясь преобразить весь фондовый рынок так же, как биткойн преобразил наши взгляды на хранение и перевод денег." --http://bitnovosti.com/2014/08/03/overstock-perevernet-rynok/), но я дальше писал: "кто знает - может, автоматизирована будет не только система обращения финструментов, но и система их конструирования. И программисты будут конкурировать на рынке САПР для финансистов…" -- вот этот мой сугубо теоретический текст про права собственности в электронной форме: http://old.computerra.ru/offline/1998/240/1189/

    Плюс не будем забывать, что экономика работает и для обменивающихся агентов. Рынки агентов грядут, поддержанные постбиткойновской денежной инфраструктурой обмены помогут распределять ресурсы и нежити -- и, надеюсь, государству и центральным банкам до этих рынков будет не дотянуться со своим регулированием и налогами.
    Sunday, September 7th, 2014
    5:40 pm
    Монитор Dell UltraSharp 5K (27", 5120*2880)
    Dell объявил о выходе в четвертом квартале этого года 27" монитора UltraSharp 5К (в этом мониторе аж 14.7млн пикселей): http://www.anandtech.com/show/8496/dell-previews-27inch-5k-ultrasharp-monitor-5120x2880. Цена предполагается божеская, $2499. Конечно, в интернетах полно обсуждений о том, что подключать его по-нормальному к видеокарте не получится. Но это трудности переходного периода. Главное, что это почти вдвое больше пикселей от только появляющихся мониторов 4К и вдвое (а не вшестеро) больше по цене.

    Я серьёзно задумывался ещё неделю назад, не прикупить ли мне ещё один BL2400, ибо одна картинка на несколько экранов мне довольно редко требуется, чаще нужны четыре разных окна, и их удобней держать на портретной ориентации 24" контрастном мониторах:
    -- Два PowerPoint (один с исходной колодой, другой для формируемой колоды слайдов),
    -- текст (Scrivener, Word, PDF-читалка -- неважно)
    -- браузер
    У меня пока только два подходящих монитора, от которых я счастлив. Вместо третьего у меня стоит ноутбук (экран которого 30% от площади основных мониторов), и ещё один большой монитор просто некуда ставить. Более, эти три экрана стоят по крутой дуге, которой не добиться ни от какого curved современного телевизора.

    Выход монстров типа Dell 5K сильно меняет ситуацию: вдвое больше пикселей это всё-таки вдвое больше пикселей (хоть и слишком мелких для меня). И это будет суп из топора: под такие мониторы нужно менять и компьютеры тоже.

    А на подходе 8К (33млн. пикселей, вдвое от 5К), пока это главным образом анонсы 98" телевизоров, но вряд ли это пройдёт мимо мониторов. Вот последний из анонсов, LG (Sharp и Samsung отбомбились раньше), с LCD технологией: http://www.engadget.com/2014/09/04/lg-8k-tv/. Но этих зверей пока хотеть рано.
    11:37 am
    lytdybr -- 12 лет в ЖЖ
    Сегодня 12 лет в ЖЖ, куда меня затащил vvagr (вот первый пост: http://ailev.livejournal.com/2002/09/07/ -- а вообще в тот день я радовался, что купил на Горбушке много сидишек по 70 рублей штучка, важное событие было в моей тогдашней жизни!). Забавно будет почитать ещё через дюжину лет, что у меня сегодня происходит.

    В ЖЖ я сегодня friend of 2082 (сколько из них не заглядывали в ЖЖ уже много лет?), в фейсбуке у меня "друганов" 1001 плюс 164 followed by (в скольких лентах я там не показываюсь?), в практически дохлом уже френдфиде 152 подписчика, ВКонтакте настолько уже на периферии моего внимания, что я им и не интересуюсь (хотя трансляция из ЖЖ идёт и туда). По разным всяким счётчикам устойчиво читающих мой блог порядка 2тыс. человек, что далеко до трёх тысяч "регистрируемого госорганами блогера" (тьфу-тьфу).

    Под это юбилейное дело почистил фейсбучную группу Close friends (проглядываю по факту только её), ибо год я её состава не трогал, а сейчас что-то уж совсем там много инженеров развелось с ура-патриотическими настроениями -- зачем мне большевистская газета вместо ленты?

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

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

    Дьявол, как я жалею, что не знал всего того, что я понял при изучении немецкого при изучении английского! Я английский после пяти лет изучения в школе знал примерно так же, как немецкий сейчас после изучения аж целый месяц и одну неделю.

    Вопрос: что является аналогом аудирования и говорения для языков программирования? И не говорите, что в программировании или моделировании все только молчат!

    Разница между моделированием, запросами, программированием выходит у меня в размышлениях на передний план. Это я всё про SysMoLan (он потихоньку движется). Ещё разбираемся с описаниями (descriptions), там вылезает стандарт IEC

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

    Практики моделеориентированной системной инженерии: до Нового Года это, похоже, будет основная тема (как до сегодняшнего дня основной темой было системноинженерное мышление). Хотя с темой системноинженерного мышления работа далеко не закончена:
    -- исправление ошибок, дополнения к основному черновому тексту. Ибо уже немножко обратной связи накопилось
    -- коммуникация с западным сообществом (Сейчас есть только глава в один сборник, 20 страниц на английском. А нужно бы все 306 страниц перевести)
    -- формализация, линия SysMoLan.
    -- понять упражнения (возможен ли тренинг?). Методические рекомендации тем, кто будет его преподавать (преподаватели тут мне не конкуренты: я-то главным образом рабочие сессии с этим материалом провожу, а не собственно "курсы"). И тут вопрос: можно ли вообще опустить этот курс до бакалавриата? А в старшую школу?
    Wednesday, September 3rd, 2014
    6:42 pm
    В Екатеринбурге
    В Екатеринбурге тепло и солнечно, много студентов, преподавателей, инженеров и случайных "интересантов". Надеюсь, мои занятия тут придутся впрок. Сегодня рассказывал о том, чего нет в книжке, завтра уже буду работать с проектами участников -- традиционный тренинг мышления. Вот оно где происходит:
    IMG_20140903_170933.397
    Monday, September 1st, 2014
    11:15 am
    С новым учебным годом!
    Я думал, что первого сентября мне придётся выдать отроку в школу вилку (чтобы снимать с ушей лапшу, ибо кроме торжественных линеек и уроков патриотического воспитания сегодня ведь ничего не будет). Но жена поступила более радикально: она договорилась с классной руководительницей ("да, сегодня ничего полезного в школе не будет, только промывка мозгов в количестве по указивкам сверху"), что отрок сегодня в школу не пойдёт вообще. В итоге все спокойны и счастливы, а производители идеологического контента пусть утрутся.

    Учебный год у меня самого начинается ударно. В плане меня-учителя завтра вылетаю проводить трёхдневный семинар в УрФУ по системноинженерному мышлению, а 20 сентября начинаю занятия в МФТИ по курсу практик моделеориентированной системной инженерии. Кроме того, меня таки уговорили стать научным руководителем одной студентки (ага, симпатичной) по теме "Cost estimation in a model-based agile systems engineering". Так что учебных дел в этом сентябре у меня оказалось сильно побольше, чем обычно.

    В плане меня-ученика я продолжу заниматься немецким. По сравнению с английским немецкий язык могуч и выразителен. Интересно, сколько времени мне нужно будет его учить, чтобы уметь читать документы типа "Cyber-Physical Systems:
    Chancen und Nutzen aus Sicht der Automation" (http://www.vdi.de/uploads/media/Stellungnahme_Cyber-Physical_Systems.pdf) -- хотел бы понять тамошние диаграммки, но месяца изучения языка явно не хватает для такого подвига.

    Интересно вспомнить мой деньзнаниевый пост год назад ("знаниевые формы и их системная инженерия" -- http://ailev.livejournal.com/1084933.html). Там всё в силе, процесс идёт, хотя и практически только моими силами. Из описанного там потенциального тридцатитомничка один по системноинженерному мышлению я написал: http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf. Интересно, получится ли в этом году написать ещё томик.
    Sunday, August 31st, 2014
    11:26 pm
    Сто имён деиндустриализации. Робовей в робовейнике.
    В разных странах деиндустриализация aka "четвёртая промышленная революция" называется в госорганах по-разному, а в частном секторе так и вообще глаза разбегаются от изобилия имён. Так, в США предпочитают advanced manufacturing (свежий финский обзор тут: http://www.slideshare.net/futurewatch/team-finland-future-watchadvancedmanufacturingusareport), в Германии примерно то же называют Industrie 4.0 (опять же, свежий финский обзор тут: http://www.slideshare.net/futurewatch/doku-1314533v1team-finlandfuturewatchadvancedmanufacturinggermanyreport). Там ещё миллион других имён: cyber-physical production system (особенно любят в Industrie 4.0 -- вот тамошняя white paper: http://www.acatech.de/fileadmin/user_upload/Baumstruktur_nach_Website/Acatech/root/de/Material_fuer_Sonderseiten/Industrie_4.0/Final_report__Industrie_4.0_accessible.pdf), Industrial Internet (как следующая революция после industrial revolution и internet revolution. Вот так, по простому -- http://www.iiconsortium.org/, "industrial internet is projected to impact 62% of the world's GDP"). Internet of Things масштабов предприятия, всё оборудование в сети. В Industrie 4.0 говорят, что и людей сюда тоже обязательно включают, в самых разных ролях -- Challenges for the human factor in future production scenarios, http://www.kth.se/polopoly_fs/1.481977!/industry%204.0%20-%20full.pdf). Словотворчество на подъеме, как в старые добрые времена (помните information superhighway? Вот и сегодняшние новомодные Industrie 4.0 будут там же, наряду с давно сдувшимся web 2.0 и даже уже сдохшим web 3.0).

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

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

    P.S. Пожалуйста, не нужно тут комментов про скайнет. Я понимаю, что эти комменты идут у многих рефлекторно ("фрукт -- яблоко", "робот -- скайнет"), но уж сдерживайтесь, пожалуйста.
    7:38 pm
    Ivar Jacobson об Essence и не только
    Ivar Jacobson, похоже, смирился с нашей идеей о том, что Essence kernel для системной инженерии нужно немножко подхакать, нельзя его просто нарастить над софтовым kernel. Вот фрагмент из его последнего интервью, где он пишет и о нашей работе в INCOSE Russian chapter (CSI Communications, August 2014 -- http://www.csi-india.org/c/document_library/get_file?uuid=faffd90f-cc91-4624-a54a-2272200e5cb2&groupId=10157):
    Debasish: Is there a distinction between what Essence is and what a kernel is?

    Ivar: Yes. Essence is a kernel for software development endeavors. Thus, Essence is a specifi c kernel. There could be other kernels.

    Pinakpani: What might be a difference between one kernel and another?

    Ivar: As I just said, Essence is a kernel to support endeavors that result in a software system. There will be an extended kernel for systems including hardware and peopleware – a kernel for systems engineering. So there could be other kernels. Now what we have seen is the Essence kernel developed for software endeavors can be easily modified to also work for system engineering. So Essence is inherently more generic, but we now want to focus on software to make sure the kernel is efficient for software development.

    Debasish: So could I say in the most abstract sense, a kernel attempts to establish a common ground for a group endeavor, and that group endeavor could be anything. In this case its software, but it could be building a skyscraper or building a bridge or building a company or anything like that. Correct?

    Ivar: Yes, in Russia people have realized that a kernel similar to the Essence kernel could work for almost any human endeavor. As a first example, a team in Russia coming from the Russian Chapter of INCOSE is working on extending the Essence kernel so that it also includes systems engineering – hardware and software and people ware. The changes to get there are rather small.
    Ещё он вновь разъясняет, почему эти чеклисты именно про альфы, а не про рабочие продукты. Это про результат содержательный, а не результат по форме (увы, нам часто не удаётся объяснить менеджерам и инженерам: все привыкли к внешнему контролю по форме, а о внутреннем контроле по содержанию даже не хотят задумываться):
    Pinakpani: You often talk about software project checklist. Checklists have been around forever and ever and not given a value expected. What are these and how do they help a software professional? A developer, a tester, an architect or a project manager? Why do you think your checklists are better?

    Ivar: Historically we have used checklists to identify progress. The problem with these checklists has been that they have usually been related to the fact that you have done a particular activity or that you have written a particular work product, a document or something like that. Such checklists are very easy to cheat and not really very useful. The fact that you have written a document doesn't mean the document is valuable. By having states representing real outcome, you know you really have achieved something when you have reached a particular state. And not in terms of written documents or performed activities. For example, the Team Collaborating state cannot be achieved just by listing the names of your team members. It requires that the team members are communicating in an open and honest way, and that the team members are focused on their agreed mission. That is actually the key to the difference. Our checklists are measuring or identifying that you really have achieved something and not that you have filled in a document template or that you have performed an activity.

    Debasish: So are you saying that the particular kinds of checklists that you've got are trying to measure the quality of the item or activity or artifact?

    Ivar: Not exactly. Essence doesn't care about documents at all, it doesn't care that you have done some activity. Instead, Essence cares that you have achieved something of value like executable code. Executable code is a real result. For instance, that you have written a requirement specification is not something that we would use to measure progress. Instead that you have got consensus among the stakeholders that these are the requirements for what the system is required to do.
    Ещё один горячий пункт, это про размытость и невнятность формулировок вопросов в чеклистах Essence. Это сделано намеренно, но именно это в Essence дико раздражает "железных" инженеров, именно в нетерпении к этому и в непонимании этому самая существенная разница между культурой программных и железных инженеров (по крайней мере, железных инженеров советской производственной системы). Железные инженеры хотят в этой части взять под козырёк, но не хотят ничего обсуждать -- "как начальники прикажут, так мы и будем делать. И вся ответственность на предложившем вопросы. Сами же ни о чём договариваться не будем -- о чём там договариваться? Всё и так ясно". А основная идея Essence -- это как раз договориться внутри команды! И не отделываться "готовностью рабочих продуктов", и не обманываться, что "и так ясно". Вот:
    Pinakpani: The different checks in the checklists are ambiguous. What value does such checklists give?

    Ivar: That is really a very important question. If you go through a checklist for a particular state, it's not necessarily instantly clear what is meant to achieve a state. This is actually intentional. If we tried to make it unambiguous, we would have to express ourselves in a formal way and then almost nobody would understand what is meant. On the other hand if we had no precision at all the checklists wouldn’t give us any hint of the meaning and that wouldn’t make them useful. Let's go back to the Bounded state we discussed earlier and look at the example checklist item in this state that says, “the stakeholders have a shared understanding of the extent of the proposed solution”. Some people might think we need a complete and consistent set of requirements that are frozen to achieve this state but that is not what is meant by Bounded. A “shared understanding of the extent” means the stakeholders agree where the boundaries of the proposed system lie. The team needs to agree that this checklist item is achieved by discussing it within the context of their own endeavor. This is one of the reasons we refer to Essence as a “thinking framework.” Instead we have had to strike a balance and to some extent rely on people’s experience. We know that within a team, people may have different opinions about the meaning of a particular checklist item. That results in a discussion, which is most valuable, and eventually the team will decide on how they interpret the checklist item and take a decision about whether the item has been achieved or not as in the example referred to previously.

    Debasish: In one of your prior answers you used the word "consensus" – for example, is their consensus about the requirements. The ambiguous word there is obviously "consensus". Does consensus mean 80% of the people like it or my boss likes it? What is the meaning of "consensus" is partly environmentally determined. That makes it a useful ambiguity. It makes it a useful ambiguity because it brings up discussion which inevitably must be clarifying to the process. Would you agree?

    Ivar: Yes, exactly that's a very good example. It brings up a discussion and the team will eventually agree and take a decision about whether we have achieved what the checklist item implies and whether we have consensus or not.

    Pinakpani: The ambiguity brings up a discussion of a likely critical aspect of the endeavor as opposed to that being left out of the mind of the developers. Or everybody assuming things are okay without really having had an explicit agreement. Would that be a fair statement?

    Ivar: Yes.
    Тем, кто дочитал до этого места, будет интересно и замечание Ivar про постепенно восстанавливающийся после воцарения agility вкус к архитектурной работе:
    Debasish: Object orientation and component based development stood on strong philosophy of separation of concerns and compartmentalization of responsibilities. But, immature learning as well as lack of fundamentals often leads to poor conceptualization of code reuse. If code is not usable in its first instance re-usability is a far cry. Do you agree?

    Ivar: Software reuse is a complex area and much can be said about it. Together with Martin Griss, I wrote a book (Software Reuse…), which discusses the questions you raise. Briefly, I would like to say that software reuse is something you need to architect to get. It is not something you get for free. It requires architecting competencies that have not been promoted since the world became agile. However, architecture practices are on its way back and software reuse will once again be a concern for all IT executives.
    Thursday, August 28th, 2014
    7:10 pm
    Системная инженерия с прицелом на 2025: вплоть до социофизических систем
    Я вот забыл написать, а пару месяцев назад был опубликован программный документ INCOSE: Systems Engineering Vision 2025 -- http://www.incose.org/newsevents/announcements/docs/SystemsEngineeringVision_2025_June2014.pdf

    Вот типичные примеры оттуда:
    Leveraging Information and Analysis for Effective Decision Making
    -- From: Systems engineers explore a limited number of design alternatives primarily based on determin -istic models of performance, physical con-straints, cost and risk.
    -- To: Systems engineers rapidly explore a broad space of alternatives to maximize overall value, based on a comprehensive set of measures including performance, physical constraints, security, resilience, cost and risk.

    Architecting and Design of Resilient Systems
    -- From: Fault detection, isolation, and recovery is a common practice when designing systems so they
    can recover from failures, and/or off nominal performance and continue to operate. Fault detection is based on a priori designation and characterization of off-nominal behavior.
    -- To: Architecting will incorporate design approaches for systems to perform their intended function in the face of changing circumstances or invalid assumptions. Ref: Engineering Resilient Space Systems, Final Report, Keck Institute for Space Studies, Sept. 2013
    Нужно, конечно, хорошо понимать технологический контекст, но за каждой такой парой From: и To: стоят очень и очень серьёзные изменения в методах инженерии и инструментах для поддержки этих методов.

    Но и системноинженерного шовинизма, конечно, хоть отбавляй. Так, впрямую говорится о том, что системные инженеры полезут не только в социотехнические и крупномасштабные системы предприятий, но и в социофизические системы (во термин! это покруче киберфизических, конечно): Systems engineering will also contribute to assessments and analysis of socio-physical systems such as the global climate system to inform stakeholders and decision makers of the emergent impacts of organizational and public policy actions.

    Да-да, масштабы планеты: The state of the Earth system will be made widely available in near real time. Continuous awareness of the Earth system state will be communicated to decision makers and the public. By blending technologies, policies and institutions, a knowledge-dense cyber-infrastructure will provide an always-on management service that communities and industries everywhere can access on demand.

    Cистемные инженеры тоже люди, и ничто человеческое им не чуждо. Они, наконец, оформились профессионально (в 2015 году INCOSE будет праздновать своё 25-летие), и теперь всё более и более настойчиво будут предлагать себя как инженеры Земли -- действительно, что им размениваться на меньшее? Ну ладно, они будут готовы синженерить и маленький кусочек земли, какую-нибудь страну вместе с её правительством, или на худой конец отрасль промышленности -- со всеми её заводами. Только закажите, вам обязательно сделают: в срок и в строгом соответствии с бюджетом. Так сказать, реализуя Systems Engineering Vision 2025.

    Так что читайте, вдохновляйтесь и восхищайтесь, но не забывайте при этом включать мозг.
    12:04 pm
    Моделирование, запросы, программирование: с какого конца идти?
    Jonathan Edwards в дискуссии к своему "Манифесту программирования будущего" (http://alarmingdevelopment.org/?p=893) пишет: "One thing I have been working on is to have a single unified data model across the PL, DB, & UI. We have lots of complex mappings and embeddings but few true unifications".

    Он затрагивает сразу две темы, которыми мы занимаемся в ходе работы над Сисмоланом (http://ailev.livejournal.com/1127145.html):
    -- модели данных, которыми мало кто занимался в computer science на предмет выражения чего-то там в мире
    -- стык между программированием, запросами к данным и моделированием (выражением куска мира в форме, допускающей разные толкования -- грубо говоря, укладывание мира в базу данных и обеспечение возможности работы разных программ с этими данными).

    Правда, он подходит примерно с той же стороны, что и justy_tylor (см. дискуссию в http://ailev.livejournal.com/1129494.html): от языка программирования для поддержки мэппинга с учётом нужд UI к стыку с базами данных (запросам).

    Мы в этот компот языка программирования и языка запросов добавляем моделирование предметной области, говоря, что это нарезка предметной области всегда системная – и пытаясь поддержать системный подход прямо в модели данных (в том числе что разные программы и разные запросы могут обрабатывать одни и те же данные, представленные в виде модели на языке моделирования). То есть мы начинаем с языка моделирования и пытаемся через язык запросов к модели добраться до программирования. justy_tylor идёт обратным ходом (чётко его позиция выражена в этом комменте: http://ailev.livejournal.com/1128881.html?thread=11875761#t11875761). Где-то посредине, наверное, встретимся.

    Тезис у этого Джонатана Эдвардса мне очень симпатичен: если не надстраиваться над сегодняшним стеком технологий и инструментов, а брать из них только идеи, то получится в разы и разы проще. И простые люди имеют шанс к нам подтянуться.

    И да, я понимаю: в области языков и данных решают не столько супер-пупер идеи, сколько супер-пупер инструментарий. То есть адекватно профинансированные хорошие инструменты для реализации плохой идеи побеждают недоразвитые в силу недостатка инвестиций инструменты для реализации хороших идей. Но такое знание ещё не повод перестать думать о хороших идеях.

    UPDATE: а вот и Bezivin из Atlanmod продолжает думать на эту же тему -- связь моделирования и программирования: http://cbi2014.unige.ch/documents/CBI2014.TowardsCrossDisciplinaryPractices.JeanBezivin.pdf
    Wednesday, August 27th, 2014
    11:44 pm
    Браузерное расстройство
    Что-то у меня FireFox32 стал сильно глючить: вчера чуть не сорвал дистантную лекцию через MS Linc из за краха плагина, неправильно показывает скорость на speedtest.net (сегодня я провёл час на телефоне с провайдером: скорость в 117Мбит/сек оказалась глюком FireFox, а правильную скорость у меня показывает, например IE11), ютьюбные видео часто показывает с рывками. Можно, конечно, грешить на большое количество открытых в нём окон. Можно грешить на подхваченный какой-нибудь злой плагин. Можно грешить на то, что я сижу не на стабильной версии, а релизном бета-канале. Но можно грешить и на то, что с этого браузера уже нужно куда-то деваться, ибо всему хорошему регулярно приходит конец.

    Но отдаваться почему-то не хочется ни изделию Корпорации Зла, ни изделию Корпорации Не Зла (которая явно тоже не Корпорация Добра). Убедите меня в чём-нибудь. Может, я не знаю каких-нибудь волшебных новостей на эту тему, появившихся месяц-два назад. Ибо на FireFox я как-то надолго задержался (а до этого у меня был Maxthon, как сейчас помню).

    UPDATE: тщательное исследование проблемы показало, что от добра добра не ищут -- одно браузерное шило на другое браузерное мыло менять нецелесообразно. Любой переезд обойдётся дороже выгод, что-то немедленно проиграется, хотя что-то и немедленно выиграется. Так что не дёргаюсь, остаюсь на FF -- только строго минимизирую аддоны и плагины.
    12:58 am
    Артигогика и педагогика в одном флаконе
    Поглядите на то, как обучают современные нейронные сетки, прикидывающиеся маленькими девочками:





    Внушаить, да? Этот проект Baby X в уже третьей версии делают в Laboratory for Animate Technologies оклендского института биоинженерии: http://www.abi.auckland.ac.nz/en/about/our-research/animate-technologies.html.

    Я давно писал про артигогику (http://ailev.livejournal.com/1011621.html), но эти биоинженеры делают всё, чтобы стремительно размыть разницу между артигогикой и педагогикой. Артигоги рискуют просуществовать примерно столько же, сколько существовали операторы ЭВМ. Всё происходит более чем стремительно.

    Итак, что нам стоит ребёнка построить? Нарисуем -- будет жить. Комиссии у них по биоэтике, ага. А если это нежить? Комиссия будет по этике нежитей? Не сотвори себе...

    А сотворивши этих тамагочей, их нужно будет учить и воспитывать. Научите зарабатывать -- будет вам зарабатывать. Научите... впрочем, педофилам и педофилорегулирующим органам просьба не беспокоиться ещё лет пять-десять, пока оно только нарисованное. А потом оно выйдет в физический мир, куда ж денется? Папа Карло напечатает своего Буратино, или Мальвину, или даже потенциально разумного пёсика Тотошку третьего пола на 3D принтере (или вырастит в горшке на подоконнике из семечка, подготовленного биоинженерами в соседней лаборатории, это ведь неважно), а затем будет учить уму-разуму, уж как сможет, в меру своего педагогического умения и этического разумения. С тем же переменным успехом, с каким учат обычных деток -- ибо и с обычными детками не всегда всё получается. С одной стороны, изменится в жизни всё, а с другой -- ничего ведь не изменится.
[ << Previous 20 ]
About LiveJournal.com