Доброго времени суток, всем! Сегодня пятница, и лучших традициях Хабра, надеюсь мой сегодняшний пост будет хорошей темой в завершении рабочей недели! С моей последней публикации прошло уже больше года, и за это время произошло достаточно много новых интересных событий, о которых сейчас мне бы и хотелось поведать всем заинтересованным, кто продолжает следить за темой.
Все предыдущие мои статьи по данной тематике можно найти через поиск.
Начать хочу с того, что в конце прошлого года назрела некоторая критическая масса, которая заставила меня все же сесть и запустить процесс выпуска новой версии моей скада-системы. Опыт и наработки, накопленные за это время, стали основой для совершенно новой концепции продукта, но при условии сохранения его архитектурной целостности и идеологии. Итак, сейчас готовится к выпуску новая версия моей скады под номером 2.0!
Она была достаточно серьезно переработана, хотя, я бы даже предпочел простое понятие — написана заново. Да, были идеи, были прототипы, была готовая работающая и доказавшая себя в боевых испытаниях и реальных применениях архитектура и продукт. На основе всего этого, а также моих новых шальных идей — сейчас пишется совершенно новая система, но с учетом всего вышеперечисленного.
Очень чесались руки переделать единый редактор проекта — нужно было привести его к концепции MDI. Этого требовало юзабилити, да и вообще здравый смысл. Также давно уже витала в воздухе идея совершенно нового движка графического интерфейса. В прошлых своих статьях я немного делал об этом заметки и показывал свои примерные прототипы. Теперь же эти идеи и прототипы легли в основу новой архитектуры графического движка и самого редактора графики. Используя наработки по графике — конечно же, были модифицированы редакторы алгоритмов, как графический (FBD), так и скриптовый (C#). Пока что здесь все ограничилось юзабилити и рюшечками, но в основу алгоритмического движка новой системы я стал закладывать идеи для дальнейшего расширения его возможностей, но это будет тема будущих статей (я надеюсь).
Самое главное, что серьезно меня тормозило от выхода на путь разработки новой версии — это та ошибка, которую допускают многие разработчики подобных систем, когда доходит до стадии развития и разработки новых версий — преемственность этих версий. Это очень серьезный камень преткновения, который на любой гладкой дороге дает серьезную помеху, о которую запинается чуть ли не каждый по ней идущий. Очень сложно сделать новое, которое не будет отрицать или не поддерживать старое, зачастую потому что это реально новое и старое уже не может быть втиснуто в рамки этой новой концепции. А ведь большинство пользователей — это не старое и новое, а это непрерывная линия, которая тянется от старого к новому и не может просто так взять и прерваться, потому что разработчик продукта решил, что новое будет так и все старое надо переделать, или отказаться от него. Эта проблема меня тормозила достаточно серьезно. Но, я немного помозговал ее и решил попробовать один интересный путь, который, как мне кажется, сможет минимизировать проблемы при переходе на новую систему. И даже более того — новая система сможет интегрироваться в существующие старые версии проектов и постепенно, шаг за шагом, даст разработчику возможность выполнить плавный переход на новую версию уже существующих и действующих систем. Но, подробности этой идеи чуть дальше по тексту.
Перевод среды разработки на мультидокументную архитекутру потребовал некоторой возни, и судя по текущему состоянию этих дел, возня с мелочевкой еще предстоит порядочная. Но, по крайней мере, организация окон системы и их докирование — теперь выглядит и работает по-человечески. К сожалению, у меня теперь нет столько свободного времени, поэтому данная статья не будет изобиловать картинками и видеороликами, я постараюсь показать немного, но по конкретным вещам:
Самая основная деталь системы, которая была переписана с нуля. И даже не просто переписана — я создал, по сути, совершенно новый графический движок системы на базе новых для меня технологий. При этом я попытался заложить в него идеи, которые станут основой для того, чтобы реально разделить инженерный и дизайнерский труд на два отдельных направления, но, нацеленных на единый результат при разработке интерфейсов пользователя.
Я, как инженер практик, считаю уже давно, что творческая составляющая не подлежит обучению и тренировке, талант он не рождается в ходе упорных кропотливых разработок. Так может рождаться и совершенствоваться мастерство, не более. Хоть ковыряйте меня вилкой, но никто никогда не убедит меня, что талант можно привить и улучшить. Не верю я в грамотного инженера, который нарисует красивый, и главное удобный интерфейс! На практике мне такое не встречалось. Придумать идею его удобности — да! Нарисовать — НЕТ! Категорично! Это талант! А он — штука редкая в сочетании с инженерной мыслью. Поэтому, всегда стремился к тому, чтобы труд по разработке графических интерфейсов был всегда разделен на два направления: дизайн, реализация. Как говорится: Кесарю – кесарево, а слесарю -… И только так можно сделать это удобным, красивым и функциональным. И обе эти составляющие должны делать два разных по профессии человека: дизайнер (дизайн) и инженер (реализация). В новой системе графики я решил максимально упростить поддержку переходов от макета дизайна к его реализации и обратно, сделать его сквозным. То есть, то, что делает эскизами инженер — может быть передано как есть (в векторе, а не рисунками) дизайнеру, а затем от дизайнера вернуть как есть (в векторе, а не рисунками) обратно в скаду, и продолжить редактировать графику средствами скады дальше, не ломая того, что сделал дизайнер. На сегодняшний день, везде, где доходит дело до подобных методов разработки интерфейса — обмен с дизайнером и обратно ведется только на уровне графических картинок, которые используются максимум как подложка, или как фон, не более. Хочу чтобы инженеры перестали быть художниками, и делали свои задачи, а художники могли наиболее адекватно принимать и возвращать макеты инженерам. Это одна из целей будущей системы.
И вторая главная задача графики в новой системе — снизить процессорную нагрузку. В текущей 1-й версии моей скады вся графика процессоро-зависимая, поэтому в крупных решениях это начинало проявляться. Также это влияло на интерактивные возможности графического интерфейса, ограничивая некоторые возможности по взаимодействию с пользователем.
В этой части все улучшения в основном коснулись только внешнего вида отображения и удобства работы с алгоритмами: для визуального языка — новая графическая оболочка и отрисовка, а для текстового — новый редактор со своими плюшками в стиле студии. Также, в рамках новой версии я начал проработку некоторых новых вещей, которые просили пользователи, правда пока их делаю только на уровне ядра вычислителя и пока не выносил их наружу. Планирую, что скоро можно будет разрабатывать свои собственные блоки FBD на базе скриптового языка, а также подключить скриптовый язык в графические экраны, где можно будет напрямую работать с их содержимым, или наоборот дополнять интерфейс пользовательскими компонентами.
Как уже сказал выше — одна из частых проблем большинства разработчиков скада — это поддержка наследования наработок при переходе на новые версии. Все заявляют, что наследование есть и можно перенести все старое в новое, но, как показывает практика — перечень «нюансов» и «ограничений» зачастую сводит на нет такие заявления, и даже то, что вроде есть, может быть использовано не более чем для «поиграться». Не утверждаю, что это поголовный трабл, но — он зачастую имеет место быть и очень часто.
Для себя решил, что заставить сделать это дело более-менее грамотно позволит только одно — запретить на время разработки загружать и сохранять системе проекты в ее родном новом формате, а делать загрузку проектов только в формате предыдущей версии. Даже чтобы отладить какую-то функцию — надо сначала создать проект с ней в версии 1.0 и только потом открывать его в версии 2.0 и выполнять проверку. А если функция совсем новая — то для проверки создавать простой проект с нуля.
По крайней мере, это ограничение заставляет прорабатывать именно поддержку старых наработок с преобразованием их в новые форматы и пока вроде получается.
К концу этого месяца планирую раздать предварительную версию для опробования среди пользователей системы и получить обратную связь. Но будет это сделано только среди тех, кто сейчас реально работает с текущей 1-й версией системы.
В дополнение к совместимости — было принято решение, что на уровне сетевого протокола новая версия будет полностью соответствовать спецификации 1-й версии. Это даст возможность, имея готовую наработку в 1-й версии, открыть ее в новой версии 2.0 и конвертировать, например узлы АРМов, или добавить новые с новой графикой и запустить их уже в рамках реально работающей системы. Благодаря поддержке одной и той же спецификации — эта процедура должна предоставить плавный переход на новую версию системы без ломания всего, что есть, и глобального перелопачивания и переделывания всего подряд. Посмотрим, оправдает ли себя моя задумка. Практика покажет, а также обратная связь от разработчиков и пользователей тоже.
Все предыдущие мои статьи по данной тематике можно найти через поиск.
Начать хочу с того, что в конце прошлого года назрела некоторая критическая масса, которая заставила меня все же сесть и запустить процесс выпуска новой версии моей скада-системы. Опыт и наработки, накопленные за это время, стали основой для совершенно новой концепции продукта, но при условии сохранения его архитектурной целостности и идеологии. Итак, сейчас готовится к выпуску новая версия моей скады под номером 2.0!
Она была достаточно серьезно переработана, хотя, я бы даже предпочел простое понятие — написана заново. Да, были идеи, были прототипы, была готовая работающая и доказавшая себя в боевых испытаниях и реальных применениях архитектура и продукт. На основе всего этого, а также моих новых шальных идей — сейчас пишется совершенно новая система, но с учетом всего вышеперечисленного.
Очень чесались руки переделать единый редактор проекта — нужно было привести его к концепции MDI. Этого требовало юзабилити, да и вообще здравый смысл. Также давно уже витала в воздухе идея совершенно нового движка графического интерфейса. В прошлых своих статьях я немного делал об этом заметки и показывал свои примерные прототипы. Теперь же эти идеи и прототипы легли в основу новой архитектуры графического движка и самого редактора графики. Используя наработки по графике — конечно же, были модифицированы редакторы алгоритмов, как графический (FBD), так и скриптовый (C#). Пока что здесь все ограничилось юзабилити и рюшечками, но в основу алгоритмического движка новой системы я стал закладывать идеи для дальнейшего расширения его возможностей, но это будет тема будущих статей (я надеюсь).
Самое главное, что серьезно меня тормозило от выхода на путь разработки новой версии — это та ошибка, которую допускают многие разработчики подобных систем, когда доходит до стадии развития и разработки новых версий — преемственность этих версий. Это очень серьезный камень преткновения, который на любой гладкой дороге дает серьезную помеху, о которую запинается чуть ли не каждый по ней идущий. Очень сложно сделать новое, которое не будет отрицать или не поддерживать старое, зачастую потому что это реально новое и старое уже не может быть втиснуто в рамки этой новой концепции. А ведь большинство пользователей — это не старое и новое, а это непрерывная линия, которая тянется от старого к новому и не может просто так взять и прерваться, потому что разработчик продукта решил, что новое будет так и все старое надо переделать, или отказаться от него. Эта проблема меня тормозила достаточно серьезно. Но, я немного помозговал ее и решил попробовать один интересный путь, который, как мне кажется, сможет минимизировать проблемы при переходе на новую систему. И даже более того — новая система сможет интегрироваться в существующие старые версии проектов и постепенно, шаг за шагом, даст разработчику возможность выполнить плавный переход на новую версию уже существующих и действующих систем. Но, подробности этой идеи чуть дальше по тексту.
Единая среда разработки с поддержкой MDI.
Перевод среды разработки на мультидокументную архитекутру потребовал некоторой возни, и судя по текущему состоянию этих дел, возня с мелочевкой еще предстоит порядочная. Но, по крайней мере, организация окон системы и их докирование — теперь выглядит и работает по-человечески. К сожалению, у меня теперь нет столько свободного времени, поэтому данная статья не будет изобиловать картинками и видеороликами, я постараюсь показать немного, но по конкретным вещам:
Новый графический движок
Самая основная деталь системы, которая была переписана с нуля. И даже не просто переписана — я создал, по сути, совершенно новый графический движок системы на базе новых для меня технологий. При этом я попытался заложить в него идеи, которые станут основой для того, чтобы реально разделить инженерный и дизайнерский труд на два отдельных направления, но, нацеленных на единый результат при разработке интерфейсов пользователя.
Я, как инженер практик, считаю уже давно, что творческая составляющая не подлежит обучению и тренировке, талант он не рождается в ходе упорных кропотливых разработок. Так может рождаться и совершенствоваться мастерство, не более. Хоть ковыряйте меня вилкой, но никто никогда не убедит меня, что талант можно привить и улучшить. Не верю я в грамотного инженера, который нарисует красивый, и главное удобный интерфейс! На практике мне такое не встречалось. Придумать идею его удобности — да! Нарисовать — НЕТ! Категорично! Это талант! А он — штука редкая в сочетании с инженерной мыслью. Поэтому, всегда стремился к тому, чтобы труд по разработке графических интерфейсов был всегда разделен на два направления: дизайн, реализация. Как говорится: Кесарю – кесарево, а слесарю -… И только так можно сделать это удобным, красивым и функциональным. И обе эти составляющие должны делать два разных по профессии человека: дизайнер (дизайн) и инженер (реализация). В новой системе графики я решил максимально упростить поддержку переходов от макета дизайна к его реализации и обратно, сделать его сквозным. То есть, то, что делает эскизами инженер — может быть передано как есть (в векторе, а не рисунками) дизайнеру, а затем от дизайнера вернуть как есть (в векторе, а не рисунками) обратно в скаду, и продолжить редактировать графику средствами скады дальше, не ломая того, что сделал дизайнер. На сегодняшний день, везде, где доходит дело до подобных методов разработки интерфейса — обмен с дизайнером и обратно ведется только на уровне графических картинок, которые используются максимум как подложка, или как фон, не более. Хочу чтобы инженеры перестали быть художниками, и делали свои задачи, а художники могли наиболее адекватно принимать и возвращать макеты инженерам. Это одна из целей будущей системы.
И вторая главная задача графики в новой системе — снизить процессорную нагрузку. В текущей 1-й версии моей скады вся графика процессоро-зависимая, поэтому в крупных решениях это начинало проявляться. Также это влияло на интерактивные возможности графического интерфейса, ограничивая некоторые возможности по взаимодействию с пользователем.
Новые редакторы алгоритмов
В этой части все улучшения в основном коснулись только внешнего вида отображения и удобства работы с алгоритмами: для визуального языка — новая графическая оболочка и отрисовка, а для текстового — новый редактор со своими плюшками в стиле студии. Также, в рамках новой версии я начал проработку некоторых новых вещей, которые просили пользователи, правда пока их делаю только на уровне ядра вычислителя и пока не выносил их наружу. Планирую, что скоро можно будет разрабатывать свои собственные блоки FBD на базе скриптового языка, а также подключить скриптовый язык в графические экраны, где можно будет напрямую работать с их содержимым, или наоборот дополнять интерфейс пользовательскими компонентами.
Совместимость с предыдущей версией.
Как уже сказал выше — одна из частых проблем большинства разработчиков скада — это поддержка наследования наработок при переходе на новые версии. Все заявляют, что наследование есть и можно перенести все старое в новое, но, как показывает практика — перечень «нюансов» и «ограничений» зачастую сводит на нет такие заявления, и даже то, что вроде есть, может быть использовано не более чем для «поиграться». Не утверждаю, что это поголовный трабл, но — он зачастую имеет место быть и очень часто.
Для себя решил, что заставить сделать это дело более-менее грамотно позволит только одно — запретить на время разработки загружать и сохранять системе проекты в ее родном новом формате, а делать загрузку проектов только в формате предыдущей версии. Даже чтобы отладить какую-то функцию — надо сначала создать проект с ней в версии 1.0 и только потом открывать его в версии 2.0 и выполнять проверку. А если функция совсем новая — то для проверки создавать простой проект с нуля.
По крайней мере, это ограничение заставляет прорабатывать именно поддержку старых наработок с преобразованием их в новые форматы и пока вроде получается.
К концу этого месяца планирую раздать предварительную версию для опробования среди пользователей системы и получить обратную связь. Но будет это сделано только среди тех, кто сейчас реально работает с текущей 1-й версией системы.
В дополнение к совместимости — было принято решение, что на уровне сетевого протокола новая версия будет полностью соответствовать спецификации 1-й версии. Это даст возможность, имея готовую наработку в 1-й версии, открыть ее в новой версии 2.0 и конвертировать, например узлы АРМов, или добавить новые с новой графикой и запустить их уже в рамках реально работающей системы. Благодаря поддержке одной и той же спецификации — эта процедура должна предоставить плавный переход на новую версию системы без ломания всего, что есть, и глобального перелопачивания и переделывания всего подряд. Посмотрим, оправдает ли себя моя задумка. Практика покажет, а также обратная связь от разработчиков и пользователей тоже.
