Разработка сервера сбора и обработки данных

Разработка сервера сбора и обработки данных

Сообщение Интегральный вычислитель » 08 апр 2008, 11:18

Попов Роман, гр 4105.
Тема бакалаврской работы:
"Разработка сервера сбора и обработки данных для распределенной ИУС"

В рамках данный работы я разрабатываю сервер для связи между удаленными контроллерами управления и SCADA-системой через TCP/IP сети. Задачей сервера является сбор информации с контроллеров, доставка команд управления и обновлений программного обеспечения контроллеров, связь с базой данных.

Реализуемый протокол прикладного уровня является усовершенствованием протокола PM3P, используемого в учебных стендах семейства SDK. Также вводиться дополнительный протокол канального уровня, который с одной стороны позволит использовать сервер вне TCP/IP стека, а с другой стороны добавит некоторые полезные свойства, такие как шифрование.

На данный момент полностью реализована работа с контроллерами, думаю над тем, как обеспечить соединение с базой данных и SCADA системой.
I Have Seen The Truth And It Doesn't Make Any Sense
Аватара пользователя
Интегральный вычислитель
 
Сообщения: 561
Зарегистрирован: 02 апр 2008, 16:04
Откуда: из Леса

Re: Разработка сервера сбора и обработки данных

Сообщение AlexNickolaenkov » 03 май 2008, 22:53

три вопроса:
1) на чем пишешь? (полагаю С+- :)
2) какие БД собираешься поддерживать?
3) какой интерфейс предоставляет SCADA?
Аватара пользователя
AlexNickolaenkov
 
Сообщения: 435
Зарегистрирован: 02 май 2008, 21:40
Откуда: Санкт-Петербург

Re: Разработка сервера сбора и обработки данных

Сообщение Интегральный вычислитель » 04 май 2008, 00:26

AlexNickolaenkov писал(а):три вопроса:
1) на чем пишешь? (полагаю С+- :)

В основном на Си, частично на СиПлюс ( на нем написана "фабрика" пакетов канального уровня). Головная часть (приемо-передатчик) написана на Си, она работает со стандартным потоком ввода-вывода и вызывает нужные ей подсистемы (разборка пакетов, связь с БД, логер ) в отдельных процессах, передавая им данные через FIFO-файлы. При реализации конкретного канала связи пишется обертка для stdin/stdout и тривиальный механизм расспараллеливания (listen - fork) (я использую xinetd =) )
2) какие БД собираешься поддерживать?

Тренируюсь на мускуле, но ничто не мешает мне в последствии прикрутить что-нибудь типа odbc.
3) какой интерфейс предоставляет SCADA?

Никакой. Интерфейс для SCADA предоставляет сервер, либо SCADA/сервер обмениваются данными через БД. Для этого в сервере существует отдельный процесс, который на выходе генерит очереди команд для каждого процесса, обслуживающего соединение с контроллером. На данный момент эти очереди опрашиваются периодически, через заданный промежуток времени, но я надеюсь, что как только у меня появиться свободное время, я смогу придумать асинхронный механизм IPC :D
I Have Seen The Truth And It Doesn't Make Any Sense
Аватара пользователя
Интегральный вычислитель
 
Сообщения: 561
Зарегистрирован: 02 апр 2008, 16:04
Откуда: из Леса

Re: Разработка сервера сбора и обработки данных

Сообщение AlexNickolaenkov » 04 май 2008, 09:06

Ещё подумаю, но по-моему это изобретение велосипеда. Смотрел в сторону докручивания для этой цели Nagios (http://www.nagios.org/) или Zabbix(http://www.zabbix.com/)?

Чем мотивирован выбор С+- в качестве основного языка разработки? С моей точки зрения уровень абстракции, предоставляемый этим языком при разработке подобного продукта слишком низок, что приведет к значительной сложности разработки, сложности подколючения новых людей, сложности поддержки и тестирования.
Аватара пользователя
AlexNickolaenkov
 
Сообщения: 435
Зарегистрирован: 02 май 2008, 21:40
Откуда: Санкт-Петербург

Re: Разработка сервера сбора и обработки данных

Сообщение Интегральный вычислитель » 04 май 2008, 15:23

AlexNickolaenkov писал(а):Ещё подумаю, но по-моему это изобретение велосипеда.

Научиться делать велосипеды - одна из моих целей. В моем дипломе мне хотелось потренироваться в программировании, а не углубляться глубоко в теорию.
Смотрел в сторону докручивания для этой цели Nagios (http://www.nagios.org/) или Zabbix(http://www.zabbix.com/)?

Нет, насколько я понял, это штуки соврешенно другого класса и для других целей. Мне хотелось сделать небольшой сервак, занимающий в памяти несколько десятков килобайт и расчитанный на воплощение в компактном кондовом девайсе без механических частей (жестких дисков и вентиляторов). Изначально планировалось реализовать его на SDK 2.0 под uCos/eCos, но, к сожалению, у человека занимающегося операционками возникли проблемы с ethernet контроллером.
Чем мотивирован выбор С+- в качестве основного языка разработки?

Компиляторы C++ существуют для множества аппаратных платформ, это и мотивировало выбор языка.
С моей точки зрения уровень абстракции, предоставляемый этим языком при разработке подобного продукта слишком низок

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

На данный момент сервер состоит из компонентов по сложности и размеру близких к программе "Hello world", а его архитектура умещается на одной странице формата A4. Такую систему достаточно легко тестировать, да и подключить в её разработку можно даже первокурсника.
I Have Seen The Truth And It Doesn't Make Any Sense
Аватара пользователя
Интегральный вычислитель
 
Сообщения: 561
Зарегистрирован: 02 апр 2008, 16:04
Откуда: из Леса

Re: Разработка сервера сбора и обработки данных

Сообщение AlexNickolaenkov » 04 май 2008, 16:22

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

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

Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое. Надо четко понимать главную цель программиста при написании программ: избегать сложность (KISS from unix).

Касаемо Nagios: исходный код Nagios занимает несколько килобайт. Он достаточно маленький и достаточно хорошо написан (для С) %) Если цель потренироваться, то рассматривать такие системы с одной стороны не надо, но с другой можно учесть их опыт. Нагиос это тоже сервер, который занимается мониторингом. Его можно настроить на сбор информации с удаленных объектов через TCP/IP. Т.е. по сути если использовать нагиос как базу, надо было бы написать только реализацию протокола pm3p и доделать соединение нагиоса с базой (насколько помню сейчас он использует syslog), но наработки в этой системе по направлению к базе уже есть. Итого: взять сервер нагиос, работающий тоже через преподобный xinetd, остается написать для него сервис check_pm3p и наслаждаться работающей системой )
Аватара пользователя
AlexNickolaenkov
 
Сообщения: 435
Зарегистрирован: 02 май 2008, 21:40
Откуда: Санкт-Петербург

Re: Разработка сервера сбора и обработки данных

Сообщение kluchev » 04 май 2008, 16:44

AlexNickolaenkov писал(а):Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое. Надо четко понимать главную цель программиста при написании программ: избегать сложность (KISS from unix).


Про KISS я даже плакат на стене своим программистам повесил :mrgreen:

По поводу C и Java: посмотри на эти языки с позиции моделей вычислений, один черт по моему, и там и там - Фон-Нейман. Ни С, ни Java - не предназначены для решения задач с несколькими процессами. На эту тему есть статья Эдварда Ли - "Проблема с потоками" http://www.softcraft.ru/parallel/pwt/index.shtml

Java - хороший пример инфляционного процесса в информационных технологиях, достаточно посмотреть критику Вирта. Вообще-то в ИТ - нехилый кризис...

Кстати, мы затеяли нашу бурную деятельность именно для того, чтобы разобраться, как нам сделать более удобное средство проектирования.
В споре рождается коллективное заблуждение, а истиной мы его называем для краткости
Аватара пользователя
kluchev
 
Сообщения: 995
Зарегистрирован: 04 апр 2008, 13:31
Откуда: SPb

Re: Разработка сервера сбора и обработки данных

Сообщение Интегральный вычислитель » 04 май 2008, 16:55

Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое.

Одним словом, мы говорим о разных вещах. То, что ты называешь сложностью, я называю удобством. Мне тоже нравяться Java и Си# (хотя synchronized в C++ легко реализуется с помощью макросов, также как и foreach циклы и прочие синтаксические удобности), но тащить вместе с программой прожорливые виртуальные машины не всегда представляется возможным, особенно если ты программируешь не под PC.
I Have Seen The Truth And It Doesn't Make Any Sense
Аватара пользователя
Интегральный вычислитель
 
Сообщения: 561
Зарегистрирован: 02 апр 2008, 16:04
Откуда: из Леса

Re: Разработка сервера сбора и обработки данных

Сообщение Интегральный вычислитель » 04 май 2008, 17:02

AlexNickolaenkov писал(а):Касаемо Nagios: исходный код Nagios занимает несколько килобайт. Он достаточно маленький и достаточно хорошо написан (для С) %) Если цель потренироваться, то рассматривать такие системы с одной стороны не надо, но с другой можно учесть их опыт. Нагиос это тоже сервер, который занимается мониторингом. Его можно настроить на сбор информации с удаленных объектов через TCP/IP. Т.е. по сути если использовать нагиос как базу, надо было бы написать только реализацию протокола pm3p и доделать соединение нагиоса с базой (насколько помню сейчас он использует syslog), но наработки в этой системе по направлению к базе уже есть. Итого: взять сервер нагиос, работающий тоже через преподобный xinetd, остается написать для него сервис check_pm3p и наслаждаться работающей системой )

Спасибо, я посмотрю на него повнимательней, когда будет время. Наверное для дипломной писанины там найдется полезная информация.
I Have Seen The Truth And It Doesn't Make Any Sense
Аватара пользователя
Интегральный вычислитель
 
Сообщения: 561
Зарегистрирован: 02 апр 2008, 16:04
Откуда: из Леса

Re: Разработка сервера сбора и обработки данных

Сообщение AlexNickolaenkov » 04 май 2008, 17:25

kluchev писал(а):
AlexNickolaenkov писал(а):Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое. Надо четко понимать главную цель программиста при написании программ: избегать сложность (KISS from unix).


Про KISS я даже плакат на стене своим программистам повесил :mrgreen:

По поводу C и Java: посмотри на эти языки с позиции моделей вычислений, один черт по моему, и там и там - Фон-Нейман. Ни С, ни Java - не предназначены для решения задач с несколькими процессами. На эту тему есть статья Эдварда Ли - "Проблема с потоками" http://www.softcraft.ru/parallel/pwt/index.shtml

Java - хороший пример инфляционного процесса в информационных технологиях, достаточно посмотреть критику Вирта. Вообще-то в ИТ - нехилый кризис...

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


Да, знаю эту точку зрения. Но переход от одной системы к другой никогда не будет быстрым. Поэтому если что-нибудь получится, то еще лет 20 мы будем работать с тем, что есть. Так что не сильно бы я рассчитывал на новую модель и яростно ее защищал. Я бы сказал -- ну да, есть такое.

Не бывает плохих технологий и хороших, каждая из них решает свою цель. Целей у Java много, у C# тоже и у других языков типа C, ++, python и Ruby. Естественно все эти технологии большое зарабатывание денег и переливание из пустого в порожнее, но движение там есть, и его необходимо видеть для того чтобы успешно работать над новыми концепциями. К чему я это клоню? Не изменив базу мы не сможем изменить технологии. Как базировались мы на Тьюринге, так и будет наша железка работать выбирая одну команду за другой, не накладывая никаких других ограничений. Так как наша отрасль делает такое железо, то софтверные ребята, базируясь на нем делают свои технологии. В общем тут все очень глубоко, с моей точки зрения. И нельзя сказать что Java 7 там что-нибудь решила кардинально новое. Совсем нет -- просто улучшенный синтаксис на той же основе. Более удобное средство для зарабатывания денег.

Более того, надо помнить, что в ИТ все завязано на деньгах и исследования тоже. Западные профессора живут на грантах, поэтому работают на производство, которое налагает на них такие ограничения. Только учитывая весь опыт мы сможем сделать что-нибудь полезное. С моей точки зрения решение нашей задачи может растянуться на десятилетия, которых судя по всему у нас нет.

Поясню про lock-unlock:
Переход от lock-unlock к synchronized вызыван совсем не удобством, и for(int i=0; i = somthing.length; i++) -> foreach тоже. Старые конструкции пораждают баги. Например, вот классический пример
Код: Выделить всё
if(a || b){
   lock (d);
   // dosomething
}

if(a & b){
   unlock(d);
}

видим, что лок в этом случае не всегда отпускается - результат на лицо: дедлок.

Очевидно что переход от такой структуры к синтаксису
Код: Выделить всё
lock(something){
// do something
}


полностью убирает в этом случае проблему дедлока. Это сделано для уменьшения количества таких "глупых" дефектов в программах. Удобство второстепенно.

Edward Lee, пишет одно, другие пишут совсем другое, третьи вообще не думают об этом и зарабатывают деньги. Поэтому это остается одной из точек зрения, не более. Для себя я еще не определился, что мне ближе, но текущее состояние дел в профессиональном программировании угнетает.

З.ы. с нетерпением жду момента роспуска кафедры "Прикладной математики и информатики", ну или по крайней мере прекращения преподавания их в дисциплинах нашей кафедры. Всем уже давно очевидно, что никаких полезных знаний они не дают.
Аватара пользователя
AlexNickolaenkov
 
Сообщения: 435
Зарегистрирован: 02 май 2008, 21:40
Откуда: Санкт-Петербург

Re: Разработка сервера сбора и обработки данных

Сообщение Интегральный вычислитель » 04 май 2008, 21:41

AlexNickolaenkov писал(а):Поясню про lock-unlock...
Переход от lock-unlock к synchronized вызыван совсем не удобством, и for(int i=0; i = somthing.length; i++) -> foreach тоже. Старые конструкции пораждают баги...

Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.
Код: Выделить всё
#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 )
I Have Seen The Truth And It Doesn't Make Any Sense
Аватара пользователя
Интегральный вычислитель
 
Сообщения: 561
Зарегистрирован: 02 апр 2008, 16:04
Откуда: из Леса

Re: Разработка сервера сбора и обработки данных

Сообщение kluchev » 04 май 2008, 23:38

Раб Лампы писал(а):Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.


Хм... Упаси господь применять это на практике. Применение макросов убивает проверки компилятора и приводит к трудноуловимым ошибкам. А ещё очень сильно страдает идиоматичность кода из-за введения новых языковых конструкций, от которых непонятно чего ожидать. В C++ и так все плохо, а тут ещё и макросы... О вреде конструкции lock/unlock теперь надо смотреть в курилке, в разделе "Размышления о науке, образовании и смысле жизни" :mrgreen:
В споре рождается коллективное заблуждение, а истиной мы его называем для краткости
Аватара пользователя
kluchev
 
Сообщения: 995
Зарегистрирован: 04 апр 2008, 13:31
Откуда: SPb

Re: Разработка сервера сбора и обработки данных

Сообщение Интегральный вычислитель » 05 май 2008, 09:40

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, по сути синтаксичесое воплощение механизма делегирования событий.)
I Have Seen The Truth And It Doesn't Make Any Sense
Аватара пользователя
Интегральный вычислитель
 
Сообщения: 561
Зарегистрирован: 02 апр 2008, 16:04
Откуда: из Леса

Re: Разработка сервера сбора и обработки данных

Сообщение AlexNickolaenkov » 05 май 2008, 10:09

Код: Выделить всё
#define TRUE FALSE

Эх не ссылался я бы на труды Microsoft, говоря о хорошем стиле программирования... Интересно мнение Аркадия Олеговича на тему :-) Я на C++ почти не программировал, но с моей точки зрения макросы -- хак на c++, вносящие лишнюю сложность и неоднозначность.
Аватара пользователя
AlexNickolaenkov
 
Сообщения: 435
Зарегистрирован: 02 май 2008, 21:40
Откуда: Санкт-Петербург

Re: Разработка сервера сбора и обработки данных

Сообщение kluchev » 05 май 2008, 12:28

AlexNickolaenkov писал(а):Эх не ссылался я бы на труды Microsoft, говоря о хорошем стиле программирования... Интересно мнение Аркадия Олеговича на тему :-) Я на C++ почти не программировал, но с моей точки зрения макросы -- хак на c++, вносящие лишнюю сложность и неоднозначность.

Ну, я уже накушался макросов по самое немогу, причем я использовал большей десятка различных компиляторов... А по поводу Microsoft - действительно так. Это не то место, где нужно учиться технологиям. Это скорее Мекка для спекулянтов, IMHO :mrgreen:
В споре рождается коллективное заблуждение, а истиной мы его называем для краткости
Аватара пользователя
kluchev
 
Сообщения: 995
Зарегистрирован: 04 апр 2008, 13:31
Откуда: SPb

Re: Разработка сервера сбора и обработки данных

Сообщение NickBorisov » 06 май 2008, 09:46

Раб Лампы писал(а):
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, по сути синтаксичесое воплощение механизма делегирования событий.)


ИМХО, такое мнение о макросах может сложиться только у человека, не имеющего опыта разработки и поддержки сколько-нибудь крупного, совместного проекта на С++. Не в обиду будет сказано.

Так сложилось, что в моем случае наиболее коммерчески востребованным оказался именно С++ :) Он не идеален, как и все остальные языкм. Но с этим можно справляться :) Могу посоветовать 2 очень неплохие книги:
"Веревка достаточной длины, чтобы ... выстрелить себе в ногу" - это исключительно про С++. Читается не очень увлекательно, но когда столкнешь с описанным там, все осознаешь.
"Совершенный код" Стива Макконнела - тут уже речь идет о том, чтобы код можно было не только писать, но и потом читать, а главное - поддерживать ;)
Mess with the best, die like the rest. (c)
Аватара пользователя
NickBorisov
 
Сообщения: 115
Зарегистрирован: 04 май 2008, 18:21
Откуда: Санкт-Петербург

Re: Разработка сервера сбора и обработки данных

Сообщение kluchev » 06 май 2008, 12:01

NickBorisov писал(а):ИМХО, такое мнение о макросах может сложиться только у человека, не имеющего опыта разработки и поддержки сколько-нибудь крупного, совместного проекта на С++. Не в обиду будет сказано.

Так сложилось, что в моем случае наиболее коммерчески востребованным оказался именно С++ :) Он не идеален, как и все остальные языкм. Но с этим можно справляться :) Могу посоветовать 2 очень неплохие книги:
"Веревка достаточной длины, чтобы ... выстрелить себе в ногу" - это исключительно про С++. Читается не очень увлекательно, но когда столкнешь с описанным там, все осознаешь.
"Совершенный код" Стива Макконнела - тут уже речь идет о том, чтобы код можно было не только писать, но и потом читать, а главное - поддерживать ;)


Мне кажется, что осознание у меня произошло уже достаточно давно :mrgreen:

Такое мнение о макросах появилось после реализации у нас на кафедре нескольких компиляторов с помощью которых было реализован ряд крупных проектов :mrgreen:

По поводу C++ я близок к критике Вирта. У нас на FTP выложены его статьи.
В споре рождается коллективное заблуждение, а истиной мы его называем для краткости
Аватара пользователя
kluchev
 
Сообщения: 995
Зарегистрирован: 04 апр 2008, 13:31
Откуда: SPb

Re: Разработка сервера сбора и обработки данных

Сообщение AlexNickolaenkov » 06 май 2008, 12:39

Я думаю NickBorisov имел в виду опыт Раб Лампы. :-)
Аватара пользователя
AlexNickolaenkov
 
Сообщения: 435
Зарегистрирован: 02 май 2008, 21:40
Откуда: Санкт-Петербург

Re: Разработка сервера сбора и обработки данных

Сообщение NickBorisov » 06 май 2008, 14:26

AlexNickolaenkov писал(а):Я думаю NickBorisov имел в виду опыт Раб Лампы. :-)

разумеется :mrgreen: он же бакалаврскую пишет ;)
абсолютно согласен, что применение макросов в большинстве случаев не оправдано.
Mess with the best, die like the rest. (c)
Аватара пользователя
NickBorisov
 
Сообщения: 115
Зарегистрирован: 04 май 2008, 18:21
Откуда: Санкт-Петербург

Re: Разработка сервера сбора и обработки данных

Сообщение NickBorisov » 06 май 2008, 14:46

хотя, если интересно, могу привести случаи, когда это очень даже удобно и эффективно.
Аватара пользователя
NickBorisov
 
Сообщения: 115
Зарегистрирован: 04 май 2008, 18:21
Откуда: Санкт-Петербург

След.

Вернуться в Бакалаврские работы

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1