Разработка любого проекта начинается с процесса «разработка требований» этот процесс может выполняться как на стороне заказчика, так и на стороне исполнителя. После того как обеим сторонам становятся ясны границы и требования к проекту, исполнитель приступает к процессу «Принятие решение».
На входе этого процесса: функциональные и не функциональные требования к проекту, варианты архитектурных решений; а на выходе выбранное архитектурное решение. В зависимости от сложности проекта эти процессы могут быть более или менее формализованы, но они присутствуют на всех проектах.
Если требования заказчика четко определенны и изменению не подлежат, то жизненный цикл этого проекта может быть «водопад», а если требования заказчика изменяются по мере увеличения его представления о Системе, то тогда лучше выбирать более гибкие жизненные циклы: спиральная, инкрементная или одна из технологий XP. По своему опыту могу сказать, что жизненный цикл «водопад» применим только для выполнения государственных заказов и только там где бизнес процессы, реализуемые в Системе стабильны.
При выборе архитектурного решения нужно учесть жизненный цикл проекта и если он будет из ряда гибких, то и само архитектурное решение должно позволять реализовать эту гибкость.
Зачем и из чего можно выбирать?
Многие разработчики, сталкиваясь с этим этапом проекта, и прямо и бесповоротно заявляют, что нужно писать с нуля. Причин для того чтобы принять такое решение множество и они все на поверхности, но для уверенности лучше определите список альтернатив. Действительно 15% проектов являются уникальными, но 85% состоят из тех самых, логических частей. Как связан выбор архитектурного решения с тем, что писать Систему с нуля или использовать наработки других разработчиков? Очень просто. Каждый из существующих движков состоит из определенной и устоявшейся архитектуры, а системы Open Source чаще всего состоят из объективных архитектурных решений. Остается только определить какой движок, писался для какой цели. И если эта цель совпадает с Вашей целью, то вы ее можете использовать при исследовании как альтернативу написанию с нуля. Если методом экспертных оценок определенно, что ни одна из альтернатив не подходит для реализации этого проекта, то тогда приступайте к написанию проекта с нуля. В этом случае не забудьте выделить 30% трудозатрат проекта на проектирование, потому что переработка одной ошибки допущенной на этапе проектирования во много раз превышает стоимость ошибки допущенной на более поздних этапах проекта. А игнорирование этапа проектирования приводит к недопустимости расширения возможностей Системы.
Какая разница в движках?
Как я уже сказал, что каждый движок, пишется под разные группы целей. 50% тех сайтов, которые реализуются на основании существующих движков, достаточно обычной CMS, которая позволяет добавлять, редактировать и удалять страницы; управлять гостевой книгой; добавлять, редактировать новости и, конечно же, прайс-лист. Остальные 50% нуждаются в доработках и вот тут ситуация уже интересней. В этом случае привлекательность движка зависит от его возможностей по расширению и изменению. Те CMS, которые содержат расширенный функционал для расширения Системы, можно отнести к разряду CMF (Content Management Framework). CMF не могут быть предназначены для просто сайтов или для более сложных систем. Они должны позволять реализовывать как одни, так и другие типы. Разница между CMF в том, сколько нужно времени и усилий для разработки одного дополнительного модуля. Немалое значение это документация Системы, потому что чем менее документирована Система, тем беднее разработчики будут использовать заложенный функционал. А это приводит к написанию того функционала, который уже давно был реализован.
Xokos Technonology как CMS
Скачав последнюю версию на SourceForge.com пользователь может залить на свой хост и после обычной инсталляции, он уже может использовать следующие модули:
- Контент – позволяет с помощью визуального редактора добавлять и редактировать страницы, группировать страницы оп темам, создавать многостраничные статьи. Каждая из статей может, имеет свои ключевые слова, которые затем вносятся определенные теги при отображении страницы. По желанию можно указать источник статьи. Права на добавление и редактирование страниц изначально у администратора, но эти права можно передать как определенной группе пользователей так и не зарегистрированным пользователям. Права раздаются как на одну статью, так и на группу статей.
- Гостевая книга – предназначена для сбора сообщений от пользователей сайта. Администратор может отредактировать, скрыть сообщение от пользователя, а так же ответить на сообщение. При добавлении объявления стоит предохранитель от спама.
- Новости – этот модуль позволяет публиковать новости компании. Модуль похож на контент, но и имеет свои особенности это поля дата опубликования и интро (краткое содержание). Есть и дополнительные публичные методы: Отобразить последние 3, 5, 10 новостей.
- Построитель сложных страниц – этот модуль предназначен для отображения нескольких страниц или содержимое нескольких сущностей на одной странице. Форма добавления такой страницы похожа на форму в модуле Контент, но имеет свою особенность, для того что бы на этой странице отобразились другие страницы, нужно указать ссылку в специальном формате. К примеру: %Module%?module=Content&method=show&id=3%/Module% - при отображении этой страницы вместо этой конструкции будет отображено содержимое модуля Контент сущности под номеров 3. Чаще всего этот модуль используется для отображения главной страницы, на которой, к примеру, должны быть графики и последние 5 сообщений из Гостевой книги и 3 Новости.
- Банеры – этот модуль может подразумевать более широкое применение, чем просто банерная система. К примеру, вам нужно, что бы при просмотре определенных страниц у вас отображались определенные картинку в определенном месте, в Xokos Technonology это будут внутренние баннеры, которые управляются через модуль Баннеры. Счетчики в Xokos Technonology тоже управляются через модуль Баннер. При добавлении баннера пользователь указывает тип баннера (Картинка, Флеш ролик или скрипт). Если это картинка или флеш, то указывается ресурс, а если скрипт, то заполняется поле скрипт. при добавлении вы можете указать размеры баннера, ключевые слова (метки), ограничения по показам или кликам, ограничения по датам и ссылку, куда перебросить пользователя при клике по баннеру. По всем кликам ведется статистика, кто и на какой странице кликнул по баннеру.
- Блоки – могу отображать содержимое любого модуля и отображаться в тех местах, где вы укажите. К примеру, баннер пока не вставить в один из блоков, он не будет отображен на странице. При добавлении блока указывается метка, где его отображать.
Т. е. джентльменский набор у владельца нового сайта уже есть. Единственное что ему остается сделать, это изменить дизайн ново испеченного сайта. Для этого ему нужно скачать тему под Xokos Technonology или же следуя инструкции создать свою. Для того что бы создать свою тему, пользователю не нужно лесть в php скрипты ему достаточно внести изменения в xslt шаблонах, которые очень похожи на html.
Считаю, что на этом Xokos Technonology как CMS можно поставить галочку.
Xokos Technonology как CMF
CMF – это набор полезных функций позволяющие программисту уменьшить время разработки не типичного или частично не типичного сайта.
Xokos Technonology – заложены методы по работе с: файлами, разными базами данных, запросами, изображениями, xml файлами, ошибками и списками. Все вызываемые действия проверяются Системой контроля прав. Xokos Technonology предусмотрены инструменты по отладке: отображение списка выполняемых sql запросов и время на их выполнение, логирование всех ошибок в Системе. Модуль Статистика позволяет отследить цепочку прохождения пользователей страниц, увидеть с какого поисковика, по каким словам и даже с какой по номеру страницы пользователь перешел на сайт.
Время на разработку прототипа нового модуля занимает не более 20 минут.
Ограниченния по дизайну полностью отсутствуют, за счет полного отделения php кода от xslt описания дизайна. Это также позволяет использовать динамические флеш ролики и разнообразные структуры разных страниц.
Документация по архитектуре и по модулям есть в форматах phpDocumentator и Enterprise Architect.
Думаю, что эти аргументы позволяют Xokos Technonology поставить галочку и как CMF.
P.S. Делайте жизнь проще, принимая правильные решения, а с сэкономленное время можете потратить на свое хобби.
Пользуйтесь с удовольствием: http://sourceforge.net/projects/xokos/
Loading ...
октября 13, 2007 в 12:23 am
Еще одна из тысячи разработок, когда девелоперу стало лень рассматривать готовые разработки.
Кроме того, что ничего нового и уникального тут нет, так еще и накладываются требования к хостингу.
У меня как-то был проект в котором использовался xslt с пхп. Проблемы возникают из-за того, что существует несколько разных xslt процессоров, даже на том же линухе. Из-за чего приходится отлаживать xslt шаблоны в соответсвиями с глюками/фичами конкретной реализации.
Ну и это еще в добавок к тому, что не так уж и много хостеров устанавливают поддержку xslt.
октября 13, 2007 в 12:50 am
А мне понравилось. Единственное что рядом с xslt процессораом можно было б вфигарить поддержку смарти или поискать нехостингбейзд xslt.
октября 14, 2007 в 3:36 pm
В ответ "dimat"
Xokos использует php"шный xslt процессор, по этому проблем не возникает не на Windows, не на Linux и не на FreeBSD.
Достаточно только подключить модуль xsl.
Три года назад я к сожалению не столкнулся с хорошим фреймворком и по этому писал свой. а сейчас просмотрел существующие и взял от них некоторые преимущества.
Но если у кого то есть предложение по улучшению или же имеющиеся наработки, то я с удовольствием все выслушаю.
октября 14, 2007 в 9:43 pm
php"шный xslt процессор -- это написан на чистом пхп или все таки использует нативные extensions?
Если чистый пхп, то дайте, пожалуйста, линк где его можно скачать. А то я даже не нашел достойного ХМЛ парсера, который не использовал бы модули пхп.
А если все таки модуль, то попробуйте скомпилить пхп сами -- там нужно что бы был установлен xsl библиотека, которые могут быть разными. Например, под виндой это MSXML, под linux один из них -- Sablotron. Говорю по своему опыту.
октября 15, 2007 в 1:06 am
>License : GNU General Public License (GPL)
Как-то не согласуется с
>Пользуйтесь с удовольствием
Для удовольствия требуются лицензии LGPL или BSD, или им подобные.
Я уже давно не обращаю внимания на код открытый под GRL - всегда можно найти аналог под более либеральными лицензиями, которые не ограничивают свободу использования
Но спасибо за выложенные разработки - думаю они пригодятся людям.
октября 15, 2007 в 1:10 am
Я выбрал такую же лицензию как и Xoops. Если она кого то ограничивает, то это не проблема поменять ее.
октября 15, 2007 в 1:14 am
Главным моим желанием, сделав это продукт открытым, есть то что бы другие разработчики могли подключатся к разработке этого продукта и вносили туда что то новое и полезное. И этот продукт становился более полезным для начинающих разработчиков.
октября 15, 2007 в 1:16 am
Даже если Вы хотите туда что то добавить за деньги, то я готов и этот момент обсудить.
октября 15, 2007 в 3:00 am
Вопрос не в том, что добавлять что-то за деньги. Добавлять и дорабатывать можно и бесплатно (хотя с платой - это лучше
), но вопрос в другом.
Именно в использовании мне близка идеология свободного и open source ПО в границах того, что автор разрешает использовать свой код на своё усмотрение. Та же LGPL (насколько я её понимаю) не требует открывать доработанный код - можно указать откуда был взят первоначальный код и при желании открыть исходники (в случае именно c open source ПО - дать доступ к уже изменённому коду).
Просто не всегда удобна GPL когда например делаешь разработки на заказ. Там могут специфичные моменты, которые не хотелось выносить на публику. Особено же это касается фреймворков. Если CMS под GPL - в принципе терпимое решение, то фреймворк может потребовать большей заточки под свои нужды - часто для этого он и выбирается в отличие от CMS. я не против указать в коде передаваемом заказчику, что такие-то такие-то классы были изменены, а за основу был вязт такой-то такой-то фреймворк, но писать на каждом заборе, что используется такой-то фреймфорк не хочется.
В документации тоже можно указать. НЕо для коммерческой разработки не более.
Я некоторое время назад начал использовать codeigniter - и уже даже отсылал репорт по уязвимости (как потом я понял - это был false positive), но факт остаётся фактом, если у этого фреймворка была GPL лицензия я даже на него не глянул бы.
Но как автора я понимаю Вас - по идее не хотелось бы, чтобы труд Вашего имени использовался завтра Васей Пупкиным под названием VasPup CMS.
Как вариант, разделить продукт на две части - собственно фреймворк под лицензией, которая позволяет не открывать код (я думаю можно будет это разумно отделить), а то что явлется уже CMS - сделать под GPL.
октября 15, 2007 в 3:04 am
Хотя всё рвно не до конца я высказал свою точку зрения на GPL. Я использую скрипты написанные под ней, но только для домашнего использования.
Как пример я сейчас нашёл класс под GPL - я буду его использовать, но для написания небольшого сервиса для себя.
октября 15, 2007 в 3:42 am
а вобще есть ли разница какая лицензия у софта?
всеравно на это все публика ложит х...
октября 15, 2007 в 3:50 am
>ложит х...
я стараюсь не ложить по возможности. Линуксоиды - те ваще к этому истерически относятся..
октября 15, 2007 в 3:57 am
а
тогда предположу что ребята с паленой виндой и прочим нуленым софтом (как я, например) ложат
октября 15, 2007 в 4:06 am
ну дык я написал по возможности
я не линуксоид, хотя пояследне время есть желание попробовать убунту уж много слов о ней говорится вокруг
октября 15, 2007 в 4:51 am
я перепробовал кучу всяких будучи студентом второго курса...
ничего не подошло
для моих задач - все говно
октября 15, 2007 в 4:52 am
хотя может за 5 лет чтото изменилось глобально
октября 15, 2007 в 10:24 am
Лицензия не пофиг
Если Вова допустим узнает, что какой-то сайт использует его продукт не по лицензии, он имеет полное право написать абуз на хостинг, и процентов 90 что сайт прикроют.
Ведь так же поступают с теми, кто устанавливает зануленные vbulletin, ipb и прочее
октября 15, 2007 в 1:00 pm
Если менять лицензию, то на какую лучше:
LGPL или BSD??
BSD - понимаю более распространенная.
октября 15, 2007 в 3:33 pm
код какой-нить GPL-ный внутри есть? Ибо тогда "по понятиям" крути не крути вся система должна остаться под GPL за некоторыми мне не до конца понятными исключениями.
октября 15, 2007 в 3:54 pm
Я не спец по лицензиям, но мне кажется, что если используется продукт с лицензией GPL, внутри своего, то не обязательно твой должен быть тоже под GPL.
Например, MySQL распространяется под GPL (http://www.mysql.com/company/legal/licensing/), хотя есть много разработок под комерческой лицензией, которые его используют.
Если не ошибаюсь, то только в том случае, если ты модифицируешь проект под лицензией GPL, тогда твой код должен быть под той же лицензией.
Если кто-то хочет правильно соблюдать все условия лицензий, то лучше вначале ознакомится с самой лицензией. Внизу описания на википедии (http://ru.wikipedia.org/wiki/GNU_General_Public_License) есть ссылочки на русский перевод (для тех кто не умеет читать на английском).
октября 15, 2007 в 6:20 pm
>MySQL распространяется под GPL
MySQL распространяется под двумя лицензиями: GPL и коммерческой.
>то не обязательно твой должен быть тоже под GPL.
Там тонкая грань которую я до сих пор толком не понял. Что-то о зависимости продукта от кода под GPL.
октября 15, 2007 в 7:03 pm
Повторюсь, что я не спец в этом деле, поэтому могу ошибаться.
Я думаю, что если ты используешь GPL продукт, то твой может быть под любой лицензией. Например, ты можешь сказать что бы этот GPL продукт был установлен в системе (например, скомпилированная библиотека, или даже ОС
)
Можешь даже включить в инсталяху этот продукт.
НО! Если ты хочешь внести изменения в GPL продукт, то твои изменения должны быть тоже под GPL.
Если кто хорошо в этом деле разбирается, подправьте. Самому, наконец, интересно разобраться за столько лет
октября 15, 2007 в 8:45 pm
Внутри я использую JPGraph лицензия QPL и SPAW2 лицензия GPL.
Какую теперь мне лицензию использовать? Наверное лучше GPL.
октября 17, 2007 в 9:29 am
>Yes, For commercial (non-open-source) you will need to >get the "JpGraph Professional License". This allows you >you deploy JpGraph in a commercial context. Further >details upon contact.
То есть, с JPGraph - получается сложновато использовать для коммерческих нужд
октября 17, 2007 в 10:54 am
получается что GPL решение при его использовании порождает ничего кроме GPL решений?
октября 17, 2007 в 3:24 pm
ну дык говорят же что GPL заразная
а вообще dimat описал примерно правила взаимодетествия с GPL продуктами...
Но там есть тонкая грань, когда твоё приложение считается зависимым от GPL-ного продукта, а когда нет, и в первом случае оно должно быть тоже под этой лиценией.
Дао я не постиг
как отличить одно от другого 
октября 17, 2007 в 8:12 pm
А кто знает как поменять лицензию с GPL на LGPL?
октября 25, 2007 в 10:42 pm
Насколько я помню нюансы лицензий - самая демократичная - Apache Software License.