Экспансия

Экспансия или на пути к тотальной визуализации.

"Чем дальше в лес, тем толще партизаны."

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

   Так как, фирмочка небольшая, приходится быть на все руки мастером, в частности, заниматься и системным администрированием, и администрировать базы данных. Вот тут то мне весьма полезным подспорьем оказалось совокупление DrakonGen с системой мониторинга, написанной в своё время для "ВполнеСебеБанка". Её я тоже делал с использованием DG и описывал раньше в этом блоге(ссыль).  

   Попробовал использовать новый редактор  mxGraph. Вывод - Очень хорошо! Есть, конечно недостатки по сравнению с yEd, но достоинства с лихвой перевешивают недостатки, если, конечно, говорить про применение двух данных редакторов для моих "дракон-геновских" нужд. Новый редактор позволил достаточно просто расширить сферу применения DrakonGen на область системного администрирования и мониторинг, а кодогенерация частично осталась на старом редакторе, а частично перешла в новый. 

Как это выглядит в редакторе

Кодогенерация частично перенесена

Применение DrakonGen для нужд сисадмина

Наличие слоев - огромный плюс нового редактора, парой галочек настраиваем тот или иной вид. Очень удобно..

в одном слое конфигурируем систему мониторинга

в другом выполняем и контролируем 

Добавление новых свойств узла выполняется одной кнопкой, правда, немного "подшаманил" редактор, чтобы свойства "code","text","styles" открывались сразу в свой размер, мне так удобнее  

Я страшный как дракон

                   "С кем поведешься, от того и наберешься". 

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

Новый проект.

Вошел в новый проект. Осваиваю PostgreSQL. 

Использую DrakonAct для запуска скриптов

и использую DrakonGen в алгоритмах 

и тестах

постепенное усложнение, фиг знает как бы я это без Дракона развивал

логику наращивать довольно комфортно, а она всё усложняется и усложняется 

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

и тесты всё усложняются и усложняются, однако, работать с ними в визуальном режиме вполне комфортно

дальше - больше 

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

А это уже мои змейки(к Дракону ни какого отношения не имеют) но и в таком виде визуализация очень помогает.

Код из текста иконы.

Сделал более удобный способ ввода кода из текста иконы.

А когда свернут, то не "отсвечивает" и не мешает.

Попробовал Драконген для подготовки скрипов к семинару.

Доволен более чем.

Эксперимент must go on...

"Если долго сидеть на берегу, то мимо обязательно проплывет тело очередного проекта."

(китайские разработчики) 

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

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

Ну, что же, пацан сказал, пацан сделал. И вот, спустя  несколько дней мучений, у меня всё опять оказалось в кодограмме. Знаете ли, привык. Знаете ли, душа не лежит жить по-старому.


При этом пришлось доделать и донастроить лифтвверх, и сделать автогенерацию меток кода(code_mark). Теперь это реально работает. Все иконы проецируются в код, а код на иконы. То есть, можно работать и на нижнем уровне и на верхнем.

Да, всё это стрёмно, но меня спасает большое количество автотестов, благодаря которым, можно чувствовать себя достаточно уверенно после многократной перегенерации проекта.

В общем, попробуем ещё немного поиграться в визуализацию. Шоу маст гоу он.


З.Ы.   Кстати, пока был простой в проектной деятельности провел несколько семинаров  внутри нашей конторы. Один по проекту, второй по своей любимой визуализации. Как пишут в газетах -  "встретил живейший интерес публики", точнее, со стороны сослуживцев. Интерес в том смысле, что братия весьма позитивненько отзывалась о проделанной работе, что у нас не очень то принято. Так как вся моя проектная деятельность сплошь состояла из "весёлых картинок", то семинары подготовить не составило большого труда. В свою очередь, представленные материалы выглядели весьма привлекательно. Кажется, все всё поняли особо даже и не напрягаясь. И подарили несколько хороших идей по улучшению и развитию. Так же дорогие коллеги коллективным разумом родили новый мем, который мне кажется концептуально важным понятием. Этот мем - "Визуальный комментарий".  Услышав это, до меня наконец-то дошло, почему я так долго упорствую в отстаивании рисования кодограмм ДраконГена в универсальном редакторе. Именно из-за возможности вставки Визуальных комментариев.  Именно они дают большое преимущество для быстрого понимания сути алгоритма по сравнению с чистым ДРАКОНОМ и уж тем более по сравнению с обычным текстовым кодом.

Пробую применить ДраконГен для визуализации проекта на C# (ITU GazeTracker). 

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

Отличный проект

The Free ArchiMate Modelling Tool

A free and open source modelling tool to create ArchiMate models and sketches. Used by hundreds of Enterprise Architects throughout the world.

Опенсорс, Eclipse RCP - супер!  Есть маленькое сомнение в производительности. Вот бы написать конвертер своих проектов из yEd в Archi, тогда бы сразу всё стало понятно.

UPD1:
Archi установился и запустился из исходников(из гита) в пол пинка(30 минут).

UPD2:

Конвертанул DrakonGen из yEd в Archi. Пока в черне так:

Финита ля ...

Постскриптум к предыдущему посту.

Проект сдан, по крайней мере, формально. На мой взгляд, реализован вполне успешно и сейчас самое время сделать предварительные выводы.  Итак...

Лебединая песТня.

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

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

Несколько картинок:

Страсти по редактору

"Мышки плакали, кололись, но продолжали есть кактусы".

(вообще-то, это анекдот, да только не в моём случае)

Специализированный дракон-редактор конечно же нужен, что уж там говорить. Пользоваться внешним, всё равно, что жить на съемной квартире, вроде всё удобно и хорошо, а чужое, это нельзя, сюда не ходи, лишний гвоздь не вбить. Однако, качественный редактор написать с нуля нереально. Пока смотрю в сторону проекта Eclipse-GEF, кажется, на его основе можно собрать более-менее стоящую вещь за приемлемый срок. Там много чего уже есть.

Принципы

"Не могу поступаться принципами"

(Нина Андреева)

Мои Принципы визуального программирования.

Решил собрать на одну страничку всё, чем не могу поступаться:

Принцип Красоты  - Красота и эстетический вид кодограммы имеют приоритет над качеством и функциональной полнотой получаемого из неё кода. Это наиглавнейший принцип.

Принцип Визуальной инкапсуляции - Отображаться должны только важные моменты.

Принцип Полёта - Легкое масштабирование картинки, возможность удобно перемещаться от общего к частному дает полноту и связанность восприятия.

Принцип Импровизации - Спецификации не догма, всё должно подчиняться и подстраиваться для удовлетворения принципа Красоты, но нельзя нарушать строгие правила.

Принцип Алгоритмической инвариантности - Алгоритм не может зависеть от конкретной реализации получаемого кода.

Бочка дёгтя в ложке мёда

(15.11.2014)

"Вот казалось бы, всё есть, а счастья нет"
(народная идиома)

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

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

Совершенно очевидно, что это вовсе не проблема, - нужно использовать старую, добрую декомпозицию. Вопрос только какую? Разбивать на более мелкие силуэты, или выделять блоки визуально?

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

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

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

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

 Пока всё, буду добавлять...лять...лять...  

Исчисление икон

Чувствую, как-то мне неудобно работать в кодограмме и что-то мешает перестраивать логику легко и непринужденно, как оно задумывалось в идеале) 

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

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

Однако, эта "краснуха" существенна только для схемы самого драконгена, а для рабочих схем не так существенна... 

Хотя и ясно как инструменталку сделать но не буду. Хочется уже к корабликам вернуться.  

Найти лицо.

(обновлено 18.11.2014)

"Можно потерять лицо, морду - никогда"

    Для некоторых нет ничего страшнее, чем потерять лицо. Действительно, ну как можно жить без хоть сколь нибудь приличной физиономии, да хоть какая плохая харя, но она должна быть, иначе, что ж это за дела! Задумался и я о том, какой пользовательский интерфейс(ака "морду") слепить для драконов моих. С разгона кинулся было по-бырому сбацать приложение на eсlipce-rcp, да потом тормознул, когда вспомнил какой это недетский гемор и тоска зелёная. Начал чесать репу как же быть и вдруг вспомнил о старой позабытой-позаброшенной разработке - Confex, основная идея которого, собственно, в том и заключается, что все трудности по созданию rcp приложения должны быть скрыты глубоко в ... внутри, а на поверхности одни простые и легкие скрипты.  И вот сижу я, изучаю понаделанное много-много лет назад и тихо офигеваю, сколько же идей похоронено в этом конфексе, и сколько же всего там было понапридумано, понапихано. Сейчас даже вспомнить трудно, не то что воспроизвести. На новом эклипсе не всё заработало, но зачем мне все эти 3D, работа с базой, всякие графики, графы, xmind-ы и составные документы. Мне кроме простых формочек ничего и не нужно. Так что буду реанимировать покойничка.

На реанимацию ушел целый день. Откатился на эклипс indigo, т.к. в новых слишком изменен механизм rcp, а вот версию java поднял до 1.7 из-за кое-каких улучшений в ней. Вроде бы почти всё даже работает, но если и нет, можно будет починить, докрутить. Приятно, что старый труд не пропал совсем и опять востребован.

18.11.2014

Отредактировал конфексный файл. Сделал чтобы все драконы и ДраконГена и SRS запускались из одного интерфейса. Так удобно. Нашел несколько ошибочек в конфексе, ну да фиг с ними, "на скорость не влияют".

Управление реверсом

05.11.2014

В основном реверс закончен, нужно хорошенько оттестировать. Можно ещё поработать над иконой "Полка"(её налогом в Дракон-Джас) но, наверное, пока не буду. Подумалось, что интересно сделать две вещи:

- управление реверсом
- аспекты

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

Основной класс реверса.

Зачем нам эта кишка, когда интересуют только определённые, конкретные участки. 

Для того чтобы избежать подобного положения дел, думаю ввести управление реверсом на уровне анализируемого исходного файла: "Свернуть все","Развернуть все", "Сворачивать однотипные". На уровне группы процедур: "Сворачивать содержимое","Развернуть содержимое", "Сворачивать однотипные", "Не сворачивать однотипные". На уровне процедуры: "Свернуть содержимое","Развернуть содержимое", "Сворачивать однотипные", "Не сворачивать однотипные".

(пока не реализовано)


Аспекты.

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

Другое дело, когда различные аспекты выделяются

Управляющие коментарии для аспектов:  

//<DG2J aspect_begin="ИМЯ АСПЕКТА"/> - начало зоны аспекта с именем

//<DG2J aspect_end="ИМЯ АСПЕКТА"/> - конец зоны аспекта с именем . Пока жестко прописано два аспекта "ASPECTS"  и "DRAKON". 

Работа начата, но до конца пока не доведена...  Ужасно утомило программирование на нижнем уровне. Хочется скорее закончить реверс и навсегда перебраться на верхний уровень... На этом и сосредоточусь. Чёрт с ним, с управлением реверсом и аспектами.  

ДраконАкт

17.11.2014

Ещё немного в сторону ушел от магистрального направления. Сделал микро дракон-язык ДраконАкт (DrakonAct) который пока состоит всего из трех икон "Лифт вниз", "Лифт вверх", "Документ" и  позволит управлять запуском "лифта" вверх и вниз. Иконки выглядят не достаточно красиво, но пока не закончу реверс(который висит над душой как камень) менять ничего не буду. 

Так выглядит главная командная кодограмма, обработка которой инициирует процессы кодогенерации(лифт вниз) или реверсинжениринга(лифт вверх)

Принцип Лифта

(обновлено 14.11.2014)

"Лифт, он тебе не нипель и не диод, он ездит туды-сюды,

 и доставляет всем. И вверх доставляет и вниз..." 

(из разговора дракон-джаз программистов)

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

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

Текучее положение тел

24.10.2014

Продолжаю заниматься реверсом. Медленно но дело движется.
Почти всё хорошо с иконами "Вопрос"

Спецификация(история изменений)

(обновляется. последнее изменение 20.02.2016, добавлена икона БЛОК КОДА )

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

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