вторник, 20 января 2015 г.

[prog] Презентация DDS vs DDS4CCM

С удовольствием посмотрел презентацию "DDS vs DDS4CCM" от Remedy IT (эта компания стоит за такими вещами, как ACE и TAO). И хоть многое было не понятно и для того, чтобы досконально разобраться, что к чему (если это потребуется) придется приложить немало усилий, но все равно воспринимается как бальзам на душу. По многим причинам.

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

Работая в гомельском КБ системного программирования имел отношение к разработке софта для управления оборудованием. И, надо сказать, ощущения, когда следишь за запущенным на реальном объекте программно-аппаратным комплексом и осознаешь, что когда вот эта картинка стала двигаться на экране, была выдана команда на встроенную PCI-ную плату контроллера, откуда пошла команда в релейную. И тут же слышишь щелчки сработавших реле за стенкой. А где-то высоко-высоко над головой, на уровне 10-го этажа открывается люк здоровенного бака с зерном, из которого, поднимая тучи пыли, зерно сыпется на огромные весы, показания которых снимаются специальным датчиком, передаются в контроллер, опрашиваемый программой, и отображаются на экране.

Конечно же, я не объективен, но по мне все это гораздо круче, чем клепание очередного CRUD-приложения на RoR-е. А может это как раз и объективно, и менталитет у разработчиков, занимающихся настолько разными задачами, должен быть разным.

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

Еще любопытный момент -- упомянутые в презентации инструменты для конфигурирования приложений. Вспоминаются первые версии SCADA Objectizer-а, созданного нами в КБСП в 90-х. Мы тоже попали под магию простых, интуитивно понятных GUI-интерфейсов. Но сколько же труда нужно вложить, чтобы все это разработать! А потом сделать реально удобным для пользователя. А потом поддерживать и развивать все это дело... Ужаснах :) Памятуя тот опыт теперь придерживаюсь принципа, что простые текстовые конфиги -- это наше все! :)

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

А теперь, после столь многословной вводной, сами слайды:

PS. Есть еще очень сильное ощущение, что все эти курируемые OMG стандарты (вроде DDS, CCM и т.д.) -- это все оверкилл какой-то. Т.е. для оборонки с раздутыми бюджетами и формализмом на каждом шагу, может это и приемлемо. Однако, для применения многих здравых идей оттуда в коммерческих разработках меньшего масштаба, наверное, было бы лучше иметь что-нибудь более легковесное и простое. Да тот же SObjectizer ;)

Комментариев нет:

Отправить комментарий