На счет обработчика сигналов я осведомлен. У вас есть решение лучше?
За конструктивные замечание спасибо, попробую прокомментировать:
1. Лицензия, GPL3. Для многих будет неприемлимо.
я даже не задумывался о лицензии, но думаю поменять для красоты не помашет, какую лучше поставить?
2. Сигналы — демоны должны обрабатывать SIGTERM (остановка) и SIGHUP (обновление конфигурации).
Это не демон. По сути это просто консольное приложение которое в случае необходимости можно отправить в background. Главное что бы логирование было в файл а не в консоль. Возможность сделать его демоном, интересная, но пока не было нужды.
На счет обновления конфигурации. Это задача сложная, не достаточно просто обновить значения параметров, нужна какая то логика перехода от старых к новым значениям. Это уже частные случай. Я могу лишь добавить другой обработчик для обновление конфигурации. НО! В отличии от выключения, в этом случае я уже не решусь в обработчике делать сложные вычисление, без коих обновление конфигурации навряд ли сработает.
3. Использование ревизии из svn для версионирования — плохое решение. Как минимум тем, что привязывает к svn.
Для, для GIT это подойдет. И я не знаю как сделать автоверсионирование для GIT. Без него не хочу.
4. «Сборку дистрибутива» — ваш package.sh — умеет делать CMake.
Он проде позволяет сделать правила для make install. Не? Это немножко не то.
5. Задание имени pid-файла через опцию командной строки я считаю излишним. у всех всегда пути жестко вкомпилированы, то же самое относится и к логам. При необходимости пути должны настраиваться во время конфигурирования, перед сборкой.
Я с вами не согласен. И я в статье явно написал, что одно из требований это возможность запуска нескольких инстансов на одном сервере.
6. Если это демон, то почему не проиходит демонизации (создание новой сессии, отказ от управляющего терминала и тд.)? Имеет смысл сделать поддержку upstart (Linux), launchd (MacOS) и scm (Windows).
Это не демон :) Но вот добавить скрипты для запуска останова, хотя бы еще для Win это нужно. Но это уже планы на будущее.
Начну с того что я не предоставляю библиотеку. Это даже близко на нее не похоже и цели такой тоже не было. На этом пожалуй и закончу :)
Я согласен со всем что вы написали про библиотеки. Но сравнивать это с тем что делал я это так же, как говорить данный проект идет ортогонально C# идеологии — абсолютно верно, но бессмысленно.
Кстати на счет тестов это вы хорошо вспомнили, вопрос важный, так как если это уже было бы включено в общую структуру тогда начать писать тесты становиться еще проще. Беда только в том что, что кто то любит Gtest, ктото boost test, ктото CppTest. Но наверно я добавлю в проект boost test.
А должно подразумевать указание «пространства имён» (как в Бусте и везде):
#include «MyCompany/MyProject/program_options.h»
#include «MyCompany/MyProject/version.h»
Я ни в коем случае не буду использовать название компании в исходных кодах. Вы наверно пишите на Java или C#, потому что вот именно там я такую штуку видел очень часто. Я даже имя проекта в сорсах не использую.
На счет С++ namespace, я их специально не использую тут, потому что не знаю какие.
2) Такая иерархия файлов плохо масштабируется. Попробуй рассмотреть пример не отдельно взятого проекта в вакууме, а взаимодействие пары пользовательских модулей (например, library и runner), заданных заголовками и исходниками, и пары сторонних библиотек, заданных заголовками и предкомпилированными бинарниками.
Не совсем улавливаю вашу мысль. Если вы хотите подключить к этому проекту стороннюю библиотеку, то у вас есть возможность просто положить ее рядом в inclide/other_lib или же сделать свой файндер для CMake и хранить ее далеко в системе. Не?
svnversion это номер последней ревизии всей ветки. Я использую ревизию последнего изменения проектной папки. В случае когда у вас в svn только один проект разницы нет. Но если более, то это уже не то.
Таки у меня ошибка, конечно же version.sh должен использоваться Last Change Revision.
В ходе написания проекта я пришел к выводу, что это уже не первый раз, когда у меня получается подобная архитектура
Я тоже. Но мне это не очень нравится. Конечно всех коней в вакууме не предусмотришь в начале, как бы ни старался, но проще отталкиваться уже от чего то, чем от пустого main.cpp
Зафиксировать личный опыт. Узнать что в можно улучшить изменить, возможно помочь кому то, кто еще менее опытен чем я. Понятное дело, что ничего нового я не сказал. Я и не пытался.
По поводу цветов, делал я тут недавно свой «инсталлятор» а решил отдельные важный части подкрасить. Потом интегрировал его в Jenkins, и узрел все те ацкие спец символы которые цвет консоли придают в обычном текстовом формате. Плюнул на все это и удалил цвета. Так проще.
Я согласен с обоими коментами. Просто увидев такой объемный пост и прочитав первый абзац, а уже приготовился к отличному чтиву и тому, что пойду переписывать свои приложения, а не сложилось. Ну да ладно. Лишний раз убедился что уже что то знаю.
Хорошие программистыспецы умеют признавать свои ошибки и заблуждения. А так же не следовать, как овцы, всем указаниям менеджмента, а аргументированно отстаивать свою точку зрения.
Я бы назвал это скрытым порно :) Кто то даже не поймет какой ужас тут происходит. Я мирюсь с этим, просто потому, что сделать лучше не могу.
Который должен уметь почти все что выше описанный проект :)
Любая разработка начинается с чего то. Это один из вариантов с чего я начинаю.
За конструктивные замечание спасибо, попробую прокомментировать:
я даже не задумывался о лицензии, но думаю поменять для красоты не помашет, какую лучше поставить?
Это не демон. По сути это просто консольное приложение которое в случае необходимости можно отправить в background. Главное что бы логирование было в файл а не в консоль. Возможность сделать его демоном, интересная, но пока не было нужды.
На счет обновления конфигурации. Это задача сложная, не достаточно просто обновить значения параметров, нужна какая то логика перехода от старых к новым значениям. Это уже частные случай. Я могу лишь добавить другой обработчик для обновление конфигурации. НО! В отличии от выключения, в этом случае я уже не решусь в обработчике делать сложные вычисление, без коих обновление конфигурации навряд ли сработает.
Для, для GIT это подойдет. И я не знаю как сделать автоверсионирование для GIT. Без него не хочу.
Он проде позволяет сделать правила для make install. Не? Это немножко не то.
Я с вами не согласен. И я в статье явно написал, что одно из требований это возможность запуска нескольких инстансов на одном сервере.
Это не демон :) Но вот добавить скрипты для запуска останова, хотя бы еще для Win это нужно. Но это уже планы на будущее.
Начну с того что я не предоставляю библиотеку. Это даже близко на нее не похоже и цели такой тоже не было. На этом пожалуй и закончу :)
Я согласен со всем что вы написали про библиотеки. Но сравнивать это с тем что делал я это так же, как говорить данный проект идет ортогонально C# идеологии — абсолютно верно, но бессмысленно.
Я ни в коем случае не буду использовать название компании в исходных кодах. Вы наверно пишите на Java или C#, потому что вот именно там я такую штуку видел очень часто. Я даже имя проекта в сорсах не использую.
На счет С++ namespace, я их специально не использую тут, потому что не знаю какие.
Не совсем улавливаю вашу мысль. Если вы хотите подключить к этому проекту стороннюю библиотеку, то у вас есть возможность просто положить ее рядом в inclide/other_lib или же сделать свой файндер для CMake и хранить ее далеко в системе. Не?
Таки у меня ошибка, конечно же version.sh должен использоваться Last Change Revision.
Я тоже. Но мне это не очень нравится. Конечно всех коней в вакууме не предусмотришь в начале, как бы ни старался, но проще отталкиваться уже от чего то, чем от пустого main.cpp
программистыспецы умеют признавать свои ошибки и заблуждения. А так же не следовать, как овцы, всем указаниям менеджмента, а аргументированно отстаивать свою точку зрения.