FelixS-Предприятие
24.12.2009
Итак, чего же хочется или что это будет за система. ч.1 Для разработчика(ов)
С [нашей] точки зрения разработчика(ов) система должна быть:
Вот, исходя из этих соображений и были выбраны иструменты и архитектура.
Инструменты ..
Прежде всего это PERL. Говорить о его достоинствах и спорить о преимуществах бесполезно и не нужно. Выбор PERL'а был обусловлен тремя факторами:
Далее, HTML/JavaScript.
WEB-среда была выбрана не случайно.
Во-первых, открытые спецификации и стандарты.
Во-вторых, нет необходимости ставить дополнительный софт, так как используется обычные браузер.
В третьих, очень простая возможность разделения кода и представления в связке PERL+HTML. По моему твердому убеждению, веб-дизайнер должен заниматься дизайном сайта/страницы, а не вникать в код. Именно поэтому, в системе создание представления максимально упрощено и сведено к созданию именно HTML-шаблона. Такой подход давно не нов, однако глядя на многие системы [CRM] построенные на PHP, можно подумать что про него забыли.
При этом в WEB-среда на стороне клиента на 98% [пока] используется лишь для отображения данных. То есть браузер работает как тонкий клиент. 2% -- это обработка данных, связанных с локализацией и некоторым форматированием выводимой страницы. В планах нет намерения нагружать браузер еще какими-либо задачами и вычислениями. Все просто -- получил данные и вывел их в свое окошко. Вся обработка на серверах.
Далее ..
СУБД Postgresql. По-моему, комментарии излишни. Хотя можно отметить наличие очень мощного и гибкого механизама хранимых процедур. Опять таки -- возможность использования PERL. А также хорошую устойчивость и быстродействие с при работе с большими объемами данных. Мы никак не патчим Postgresql, используем то, что есть в исходниках.
Веб-сервер Apache. И тут - mod_perl. :-) Еще один плюс в пользу выбора PERL и, как следствие --- удешевление и упрощение поддержки.
Архитектура -- стандартная, трехзвенная. СУБД <--> Вебсервер <--> Клиент (браузер).
Вот, собственно, пока все ...
Продолжение следует ...
P.S. Этот текст тоже может измениться. Со временем ;-) ¶ 12/24/2009 10:57:00 AM Комментарии: 3
- Максимально простой в сопровождении;
- Использовать максимально безопасные и, вместе с тем, гибкие инструменты разработки и поддержки;
- Быть максимально гибкой и масштабируемой.
- Быть защищенной, с точки зрения авторского права.
Вот, исходя из этих соображений и были выбраны иструменты и архитектура.
Инструменты ..
Прежде всего это PERL. Говорить о его достоинствах и спорить о преимуществах бесполезно и не нужно. Выбор PERL'а был обусловлен тремя факторами:
- Мощность, универсальность и применимость практически в любой операционной среде.
- Безопасность. Согласитесь, что уязвимости в нем [интерпретаторе] находятся гораздо реже, чем в том же PHP. То есть одной головной болью меньше.
- Просто очень нравится.
Далее, HTML/JavaScript.
WEB-среда была выбрана не случайно.
Во-первых, открытые спецификации и стандарты.
Во-вторых, нет необходимости ставить дополнительный софт, так как используется обычные браузер.
В третьих, очень простая возможность разделения кода и представления в связке PERL+HTML. По моему твердому убеждению, веб-дизайнер должен заниматься дизайном сайта/страницы, а не вникать в код. Именно поэтому, в системе создание представления максимально упрощено и сведено к созданию именно HTML-шаблона. Такой подход давно не нов, однако глядя на многие системы [CRM] построенные на PHP, можно подумать что про него забыли.
При этом в WEB-среда на стороне клиента на 98% [пока] используется лишь для отображения данных. То есть браузер работает как тонкий клиент. 2% -- это обработка данных, связанных с локализацией и некоторым форматированием выводимой страницы. В планах нет намерения нагружать браузер еще какими-либо задачами и вычислениями. Все просто -- получил данные и вывел их в свое окошко. Вся обработка на серверах.
Далее ..
СУБД Postgresql. По-моему, комментарии излишни. Хотя можно отметить наличие очень мощного и гибкого механизама хранимых процедур. Опять таки -- возможность использования PERL. А также хорошую устойчивость и быстродействие с при работе с большими объемами данных. Мы никак не патчим Postgresql, используем то, что есть в исходниках.
Веб-сервер Apache. И тут - mod_perl. :-) Еще один плюс в пользу выбора PERL и, как следствие --- удешевление и упрощение поддержки.
Архитектура -- стандартная, трехзвенная. СУБД <--> Вебсервер <--> Клиент (браузер).
Вот, собственно, пока все ...
Продолжение следует ...
P.S. Этот текст тоже может измениться. Со временем ;-) ¶ 12/24/2009 10:57:00 AM Комментарии: 3
01.12.2009
Лицензия
Принципиальное отличие RGPL от GPLv2 -- прямой запрет коммерческого использования без разрешения правообладателя. Под коммерческим использованием подразумевается продажа и техническая поддержка программы с целью получения прибыли. Во всем остальном -- условия демократичны. Можно бесплатно скачивать, бесплатно распространять, использовать и модифицировать.
Текст лицензии лежит тут
¶ 12/01/2009 01:42:00 PM Комментарии: 0
05.10.2009
О проекте ..
Проект существует немногим меньше двух лет. За это время многое изменилось и в проекте, и в окружающем мире.
После долгих проб и многочисленных ошибок, консультаций и советов, а также несмотря на то, что тестовые версии проекта были внедрялись на нескольких коммерческих предприятиях, пришло понимание того, что делать просто очередную учетную систему, сводящую дебет с кредитом -- просто неразумно и нерационально. Составлять конкуренцию той же 1С или "Галактике" просто бессмысленно, потому что единственным преимуществом будет открытость и свободная лицензия. Эти качества проекта, безусловно, являются очень важными и необходимыми, но ...
Преимущества уже существующих учетных систем в том, что они имеют огромные базы пользователей, которым нет смысла переучиваться на какую-то новую, доселе неизвестную систему, если она выполняет те же самые функции. Наличие исходников в свободном доступе -- всего лишь приятный факт. Вроде как не надо покупать, на первый взгляд получается экономия. Однако же дальше начинаются вопросы и проблемы ..
Анализ и осознание возникающих проблем у конечного пользователя, привели к парадоксальному выводу. Очередная система оперативного и бухгалтерского учета в том виде, к которому уже все привыкли (в разных формах) попросту не нужна.
Во-первых, потому что уже существует изрядное количество учетных систем, с самым разным функционалом и лицензиями, в том числе и открытые.
Во-вторых, ни одна из них не удовлетворяет полностью запросов пользователя. Не в смысле объема, а в смысле качества. У каждой свои "фишки", свои возможности. И, чтобы удовлетворить потребности отдельно взятой бизнес-единицы, администраторам и программистам приходится комбинировать самые разные решения, в силу своих возможностей и знаний. Эффективность таких решений, подчастую, является далеко не оптимальной, а поставленные задачи -- выполненными не полностью.
Проблемы с учетными системами (посмотрите любой форум по ним) -- это проблемы не только разрабочиков и системных администраторов. В первую голову -- это проблемы бизнеса. Вернее "неграмотности", "необразованности" и косности очень многих менеджеров и владельцев бизнесов, а также -- сложившейся системы продажи программного обеспечения.
После понимания сложившейся ситуации, пришло понимание того, в каком направлении и как должен развиваться проект FelixS-Предприятие. Хотя учетные функции в системе будут присутствовать безусловно, но это будет не учетная система в узком, привычном понимании.
Продолжение следует ...
¶ 10/05/2009 03:02:00 PM Комментарии: 0
Продолжение следует ...
