AlexNickolaenkov писал(а):три вопроса:
1) на чем пишешь? (полагаю С+-
2) какие БД собираешься поддерживать?
3) какой интерфейс предоставляет SCADA?
AlexNickolaenkov писал(а):Ещё подумаю, но по-моему это изобретение велосипеда.
Смотрел в сторону докручивания для этой цели Nagios (http://www.nagios.org/) или Zabbix(http://www.zabbix.com/)?
Чем мотивирован выбор С+- в качестве основного языка разработки?
С моей точки зрения уровень абстракции, предоставляемый этим языком при разработке подобного продукта слишком низок
что приведет к значительной сложности разработки, сложности подколючения новых людей,сложности поддержки и тестирования.
С моей точки зрения уровень абстракции, предоставляемый этим языком при разработке подобного продукта слишком низок
На мой взгляд "уровень абстракции" используемого языка программирования мало влияет на сложность разработки. Основным фактором, определяющим сложность, является архитектура разрабатываемой системы, сформированная на этапе проектирования. А на архитектуру системы влияют в основном парадигма программирования (ООП,ПП,ФП,ЛП..), опыт проектировщика, знание шаблонов проектирования.
Такие "фишки" как динамическая типизация,автоматическая сборка мусора, отсутствие адресной арифметики могут значительно облегчить изучение языка программирования и повысить "удобство" его использования, но повлиять на сложность они не могут. А иногда они могут породить дополнительные проблемы, страшно представить, как бы я парсил бинарный протокол на языке вроде Питона или Руби..
AlexNickolaenkov писал(а):Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое. Надо четко понимать главную цель программиста при написании программ: избегать сложность (KISS from unix).
Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое.
AlexNickolaenkov писал(а):Касаемо Nagios: исходный код Nagios занимает несколько килобайт. Он достаточно маленький и достаточно хорошо написан (для С) %) Если цель потренироваться, то рассматривать такие системы с одной стороны не надо, но с другой можно учесть их опыт. Нагиос это тоже сервер, который занимается мониторингом. Его можно настроить на сбор информации с удаленных объектов через TCP/IP. Т.е. по сути если использовать нагиос как базу, надо было бы написать только реализацию протокола pm3p и доделать соединение нагиоса с базой (насколько помню сейчас он использует syslog), но наработки в этой системе по направлению к базе уже есть. Итого: взять сервер нагиос, работающий тоже через преподобный xinetd, остается написать для него сервис check_pm3p и наслаждаться работающей системой )
kluchev писал(а):AlexNickolaenkov писал(а):Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое. Надо четко понимать главную цель программиста при написании программ: избегать сложность (KISS from unix).
Про KISS я даже плакат на стене своим программистам повесил![]()
По поводу C и Java: посмотри на эти языки с позиции моделей вычислений, один черт по моему, и там и там - Фон-Нейман. Ни С, ни Java - не предназначены для решения задач с несколькими процессами. На эту тему есть статья Эдварда Ли - "Проблема с потоками" http://www.softcraft.ru/parallel/pwt/index.shtml
Java - хороший пример инфляционного процесса в информационных технологиях, достаточно посмотреть критику Вирта. Вообще-то в ИТ - нехилый кризис...
Кстати, мы затеяли нашу бурную деятельность именно для того, чтобы разобраться, как нам сделать более удобное средство проектирования.
if(a || b){
lock (d);
// dosomething
}
if(a & b){
unlock(d);
}
lock(something){
// do something
}
AlexNickolaenkov писал(а):Поясню про lock-unlock...
Переход от lock-unlock к synchronized вызыван совсем не удобством, и for(int i=0; i = somthing.length; i++) -> foreach тоже. Старые конструкции пораждают баги...
#define synchronized(something) for(lock( something ); islocked( something ); unlock( something ))
#define foreach( i, c ) \
typedef __typeof__( c ) c##_CONTAINER;\
for( c##_CONTAINER :: iterator i = c.begin(); i != c.end(); ++i )
Раб Лампы писал(а):Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.
kluchev писал(а):Раб Лампы писал(а):Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.
Хм... Упаси господь применять это на практике. Применение макросов убивает проверки компилятора
и приводит к трудноуловимым ошибкам.
#define TRUE FALSE
AlexNickolaenkov писал(а):Эх не ссылался я бы на труды Microsoft, говоря о хорошем стиле программирования... Интересно мнение Аркадия Олеговича на темуЯ на C++ почти не программировал, но с моей точки зрения макросы -- хак на c++, вносящие лишнюю сложность и неоднозначность.
Раб Лампы писал(а):kluchev писал(а):Раб Лампы писал(а):Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.
Хм... Упаси господь применять это на практике. Применение макросов убивает проверки компилятора
We all know that C and C++ macros are evil, sharing a level of hell with the devil himself
Макросы работают на уровне препроцессора, поэтому никакие проверки компилятора не должны убиваться.и приводит к трудноуловимым ошибкам.
Наоборот. Как было замечено выше, применение подобных конструкций помогает избежать глупых ошибок.
Подобные приемы с макросами применяются во многих C++ библиотеках. К примеру, у того же Майкрософта.
В библиотеке Qt, которую я сейчас использую, даже написан дополнительный препроцессор, который добавляет в C++ дополнительные конструкции для обмена сообщениями между объекатми. (макосы SIGNAL и SLOT, по сути синтаксичесое воплощение механизма делегирования событий.)
NickBorisov писал(а):ИМХО, такое мнение о макросах может сложиться только у человека, не имеющего опыта разработки и поддержки сколько-нибудь крупного, совместного проекта на С++. Не в обиду будет сказано.
Так сложилось, что в моем случае наиболее коммерчески востребованным оказался именно С++Он не идеален, как и все остальные языкм. Но с этим можно справляться
Могу посоветовать 2 очень неплохие книги:
"Веревка достаточной длины, чтобы ... выстрелить себе в ногу" - это исключительно про С++. Читается не очень увлекательно, но когда столкнешь с описанным там, все осознаешь.
"Совершенный код" Стива Макконнела - тут уже речь идет о том, чтобы код можно было не только писать, но и потом читать, а главное - поддерживать
AlexNickolaenkov писал(а):Я думаю NickBorisov имел в виду опыт Раб Лампы.
Вернуться в Бакалаврские работы
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0