Comments 37
Никогда не пишите- ЕЩЕ ОДНА! кому нужна еще одна если уже есть такие же? За такую фразу дипломные работы валятся, даже если они хорошие, а тут opensource проект.
Пишите- что то вроде- НОВАЯ MCS, ОТЛИЧАЮЩАЯСЯ ОТ ПРОЧЕМ ТЕМ, ЧТО она там супер пупер в чем-то.
Мысли вслух. Дипломы валятся??? Почему я не учился в таком вузе.
Во всех обзорах CMS есть один существенный недостаток, который достаточно важен для конечного потребителя, но очень гемморойный для описания. Это нагрузочное тестирование в боевых условиях в сравнении с другими решениями.
По сути, описание ничем не отличается от других CMS на других платформах, основной критерий «Java EE звучит убедительно» это, кончено, супер, но…

Хотелось бы увидеть одинаковые «Enterprise» приложения, выполненные на основных платформах, например Java/C#/Python/Ruby/PHP/Perl, и сравнение между ними на одном и том же сервере по нагрузке. Вот это был бы реальный пример. Плюс табличка с реальным временем написания приложения и затраты на написание (2 раба писали 20 часов на хлебе и воде или же пять «сеньйоров» ваяли 40 дней в сауне), плюс размер кода, плюс загрузка памяти и прочая шелуха.

Ясное дело, что никто этим заниматься не будет, потому грустно читать все эти обзоры. По типу как «Вот новая модель Хонды, тут мы допили новую ручку под капотом, типа фича. А Хонда звучит убедительно для заказчика, это вам не ВАЗ». Вроде как CMS в вакууме, ну да, есть какие-то фичи, да, есть какие-то возможности. Но как оно в боевых условиях — никто не знает. И есть ли профит от этой джавы в данном случае — а хрен его знает.

P.S. Это не лично к автору обзора, это скорее мысли вслух. Всяко полезно узнать новое название «на всякий случай», всё же авось пригодится.
Это был бы очень полезный обзор, но весьма и весьма трудоёмкий.
Пару слов на тему производительности Apache Lenya. Так как используется XSLT трансформации во многих местах, то производительность будет невысока. Если к тому же учесть экзотические фреймворки типа Apache Avalon, по которым сложно найти толковую документацию, то и затраты на написание, по крайней мере на изучение, будут высоки.
Но вот концепция, когда при редактировании (в режиме Authoring) сразу видно структуру сайта, мне близка. Я считаю, что обычным пользователям она будет проще для освоения и понимания, чем, скажем, Секции-Категории в Joomla. Ведь часто наполнением сайта занимаются далеко не технические специалисты. Удобство использования для обычных пользователей тоже надо учитывать.
> Это был бы очень полезный обзор, но весьма и весьма трудоёмкий.
Ага, я именно об этом :) Ежемесячно кто-либо отписывается на хабре о какой-нибудь «очередной» CMS. Но все эти описания просто бесполезны.

> Но вот концепция, когда при редактировании сразу видно структуру сайта
Здесь стоит уточнить, для каких именно пользователей. Ведь те, кто уже поработал с CMS, те уже «привыкли» к каким-то устоявшимся механизмам.

В любом случае, без основательного сравнения дискутировать бессмысленно :) Ведь кому-то и джумла на пне 4 сойдёт, а кто-то нагородит десяток серверов а-ля «энтерпрайз» ради сотни клиентов.

Кстати, интересно, как апачевские проекты находят применение. Иногда, глядя на них, складывается впечатление, что кто-то пишет тонны кода «в стол» в своё удовольствие, из которого только 10-15% идёт в мир. Хотя это возможно обманчивое мнение.
ето уже не впечатление! Ето уже тенденция смахивающая на Эпидемию! Вот эта Сравнилка «охватила»
1147 (!!!!) ЦеЭмЕcов! И похоже еше не вечер. А впечатление в ето случае — проще написат свой, чем понятb как работает готовый.

У Апачевских проектов очень хорошая лицензия, да и много проектов используется, например в нашей компании из больших wicket, из маленьких не перечесть… всех не помню :)
Честное сравнительное тестирование практически невозможно.
1) сравнительные тесты производительности может не позволять лицензия;
2) специалист, ковырявшийся в системе «последние 5 лет», как правило может быстро допилить ее до качественно иных показателей, нежели дефолтная поставка.
А всё сравнивать и не нужно. Зачастую, когда мы видим «очередную» CMS, то мы не думаем о «спеце с опытом 5 лет» либо о лицензиях, наоборот, нам нужно увидеть реальные преимущества, что бы потом уже нанимать спеца и платить лицензии.

Можно на выборочных CMS построить идентичное приложение, как я и написал выше, да хоть тот же форум/блог/доску/хабр/etc, и заливать всё это на один и тот же сервак, и проверять нагрузку, загрузку проца-памяти и т.д., SQL запросы (профайлер, количество, etc). В целом протестировать основные факторы. Как лицензия может не позволить запустить «ab ...»? Спеца отбрасывает, принимаем за фактю. что у на специалист общего профиля, без знаний в текущей CMS. Вот и будет адекватное сравнение.

А потом мы уже будем посмотреть, что даже если какая-то CMS обладает ну супер фишками, но не выдерживает и 10 запросов в секунду либо заваливает MySQL бесполезными запросами, то грош цена такой CMS.
Сравнение демо-версий — это лишь сравнение демо-версий. Сравнение примеров из коробки — это сравнение лишь примеров из коробки. И это совсем не то же самое, что реальные проекты, которые надо еще пару месяцев разрабатывать, прежде чем мы увидим рабочий сайт.

Например, лицензия на MS SQL запрещает публикацию сравнительных тестов производительности (делать, конечно, никто не запретит).

Например, Битрикс в дефолтной поставке из коробки, при прочих равных, реально жрет ресурсов и может не выдержать 10 запросов в секунду. Но разработчики реально умудряются строить крупные проекты на нем под достаточно высокой нагрузкой. Не фанат этой системы, но вот такой расклад, что его выбирают… по другим критериям.

Прожорливость системы вообще может стоять на последнем месте.

Не против решений, изначально дающих кучу технических плюшек, но как они себя потом поведут — проверить дороговато.

Все таки считаю, что мысль о сложности или часто невозможности адекватно сравнить CMS заслуживает внимания.
Давайте рассмотрим простые примеры. Например, машины. Все они выполняют функции «ездить», плюс имеют некоторые дополнительные плюшки. И все эксперты умудряются их сравнивать, выработаны критерии, всё отлично. Причем эти критерии общие! При сравнениях не учитывают такие вещи, как «а у меня нет денег на лицензии» либо «у меня тут мастер есть, который копейки с детства собирает». Сравниваются всегда четкие характеристики самой системы, а не внешние факторы. Это уже клиент сам выберет. Но он должен видеть чёткость и сравнение, чем этот горшок лучше соседнего. Так же с промышленным оборудованием, кораблями, садовыми горшками и всем остальным.

У CMS есть четкая цель — управление контентом, и вполне реально составить список из двух десятков критериев, по которым и сравнить. Например, те же корабли сравниваются на верфи по внешним параметрам и характеристикам оборудования, после чего их прогоняют в море на стандартных тестах, типа ускорения, несколько выстрелов, торможение, манёвренность. Это далеко не боевые условия, но всё же позволяют дать адекватную оценку работе систем.

Так же точно можно сделать и с CMS. Это средство, инструмент, а любой инструмент имеет предназначение и соответствующие характеристики, по которым можно успешно сравнивать и делать выводы. Кроме того, проект средней сложности реально покажет поведение CMS под нагрузкой, это как базовые испытания. И сразу станет видно. Указанный пример с Битрикс не показатель, например автор в статье указал критерий «java ee выглядит солидно», что для CMS далеко не критерий, это внешний фактор конкретного клиента, а не заслуга системы. Любая CMS конфигурируется, но тут есть нюанс. Это конфигурация самой CMS либо это конфигурация apache/mysql/memcached, которые как раз и не нужно трогать, а оставлять дефолтными, что бы проверить реальную работу самой CMS.

При таких раскладах вполне реально получить адекватную оценку и сравнение.
До хабраката вставь картинку с логотипов с выравниванием влево / вправо, и переноси в блог CMS завтра, где-то в районе «после обеда» чтобы он на главную попал. в конце можно привести список ресурсов по аналогии с вики, оф сайт, сообщества и т. п. Все консольные команды тоже лучше либо провести через что-то подсвечивающее либо завернуть в code + blockquote.
Ревизии есть, если не ошибаюсь, в поздних версиях вордпресса. Во всяком случае, неоднократно попадались советы, как их отключать.
Не ревизии, но близкое к тому — черновики (автоматически сохраняемые) — встречал ещё в нескольких движках, а также в публичных блог-сервисах (жж, дайри).

Журналирование, естественно, много где есть.

Это так, отвлечённо.
«Поздние версии вордпресс», ха! Неимоверное достижение…

В Друпале и ревизии, и несколько состояний документа (если больше двух — плагином), и много чего еще было всегда (по крайней мере в шестой версии)
Я и не выдаю за достижение. Я поясняю, что это в принципе встречается.
Ну, начнем с того, что каким-нибудь «плагином» всегда можно что угодно и к чему угодно прицепить, причем любой степени простоты/громоздкости. Вопрос в том, нужно ли это все в таком объеме и если нужно, то часто ли. Лишний наворот — усложнение системы, в том числе для пользователя.
Спасибо, познавательно. Не забудьте обещанную статью про доработку. :)
Насчет версий интересный у всех подход.

А почему, кстати, именно версия документа, а не куска системы или целиком системы?

Вот был раньше cvs, лепивший версии на файлы отдельно, потом появился svn, сохранявший версию для всего репозитория.

Просто интересно, почему отдельных документов версии? Кто что думает?
Документы обычно более независимы, чем исходники программ, поэтому откатывать всё одновременно смысла нет имхо.
по своему небольшому опыту хочеться добавить, что Апачи Леня нечеловечески сложна. Пока во всех концептах разберешься, пока рабочую версию соберешь, пока все настроишь, и все конечному пользователю объяснишь — все желание с ней работать пропадает. Для своих нужд нашел более удачную CMS, называется Магнолия (http://www.magnolia-cms.com/home.html) имеет коммерческую и открытую лицензию (GPL). Очень проста (по сравнению с Леней), большое сообщество, используется на довольно большом количестве сайтов.
По своему опыты подтвержу, что Леня очень сложна. Может и не «нечеловечески», но копать иногда приходилось долго. Плюс экзотические фреймворки. Но проект мы тогда сдали, кучу изменений сделали, клиент остался вполне доволен.
Можно попридираюсь?

2 «Java EE» звучит для уха бизнесмена серьёзнее и надёжнее, чем, скажем, PHP

Фиговый тот бизнесмен, который вникает в нюансы платформы для создания интернет-представительства своей компании. «Подбираю специалистов и не боюсь делегировать им часть своих полномочий». Вот признак настоящего бизнесмена. Вот правило для умного руководителя. Если бы Java EE звучало для IT-директора — о да, я бы поверил. Но в музыку для ух предпринимателя :(
Мы в компании несколько раз подряд пытались ее интегрировать в работу.

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

Для использования в реальной жизни она, может, и пригодна, но она чудовищно, запредельно дорога во внедрении. Значит, ее имеет смысл ставить на сайты огромных масштабов, И ТО: нужно сначала доказать, что это целесообразно.
CMS на Java это жесть… чтоб писать плагины людям придется нанимать людей за несколько тысяч долларов в месяц, вместо студента который знает пехапэ.
Что касается мелких заказчиков, то да, им лучше нанять студентов, а вот что касается крупных корпоративных пользователей, то они склонны доверять компаниям, лучше тоже крупным. То, что в компании могут работать студенты, это уже другое дело. Корпорациям нужны гарантии, а что может дать бедный студент?
А если компания накроется? Искать потом крутых ява-программистов чтоб разбирались? С PHP это намного проще…
Это как-то связано с популярным apache, или у авторов просто не нашлось достаточно креативности?
Only those users with full accounts are able to leave comments. Log in, please.