LINUX.ORG.RU
ФорумTalks

Снова вопрос о CMS: На чем?


0

0

Решил сделать web-ресурс для локалки, типа новостной ленты с гостевухой. Возник вопрос на чем писать. Вводные: динамический html, данные в базе, не php, свой сервер, максимальная производительность не критична, есть время поизвращаться :-) Есть опыт работы с php+mysql. Сейчас думаю над связкой perl+postgresql. Кто что может посоветовать? Может есть какие-нибудь готовые решения в CPAN, которые можно присовокупить к проекту? Кто что может сказать по сабжу? Желательно услышать конкретные доводы за/против и хуже/лучше, если имеете что предложить отличное от моего выбора.

★★★★

Базу PostgreSQL естественно, хотя в случае MVC особой разницы нет.

true
()
Ответ на: комментарий от r_asian

> А довод привести? ;-)

Посмотри на его ник =) true - это уже довод и не обсуждается ))

far_tuna
()
Ответ на: комментарий от mutronix

true > Лучше Ruby/Rails или Python/Django.

mutronix > Дык, чем лучше-то?

Смотри свои же требования:

mutronix >есть время поизвращаться :-)

;)

roller ★★★
()

тут имхо основной момент - есть время поизвращаться, так что можно выбрать то, чем хотел попользоваться, но за деньги заказчика боялся, рекомендую написать на чем-нибудь экзотичном, чтоб опыт получить

cvb
()
Ответ на: комментарий от mutronix

> Дык, чем лучше-то?

Лучше Перла :)

А если серьезно, то Руби > Перла. А РОР дает возможность делать качественное веб-приложение без траха с низкоуровневыми вещами.

А если хочешь вообще быстро, поставь пунбб :)

Cris
()
Ответ на: комментарий от Cris

>А РОР дает возможность делать качественное веб-приложение без траха с низкоуровневыми вещами.

Я сначала это прочитал как "ПОП" :) RoR - Ruby on Rails

Автору темы: Если хочешь чего-то нового и интересного, то пиши на ruby on rails. Думаю, что этой причины будет достаточно.

P.S. Только пришёл с почты. Получил Agile Web Development with Rails (second edition). Yummy! :D

HappyCoder
()
Ответ на: комментарий от mutronix

1. Качественный ORM который на порядок увеличит программситкую производительность при создании объектной модели и на 90% автоматизирует работу с базой. У перла/пхп конечно есть аналоги, но дотягивающих хотябы на до ActiveRecord я не нашёл. Это считай сократит время реализации проекта на 50-70%

2. Отличный расширяемый шаблонник

3. Полная интеграция всех компоненнтов

4. Куча расширений и готовых решений. Например включения кэширования данных с помощью memcahce на уровне делается одной строкой на класс (причём это сторонний модуль).

5. Ruby намного лучше чем PHP и лучше чем Perl

CrazyPit ★★★
()
Ответ на: комментарий от HappyCoder

я здесь с 2002 года с перерывом на виндузячество.

zort
()

прошу заметить - геноцид анонимусов (через нечитаемую КАПТЧУ) подходит к завершению. в этом треде ни одного.

zort
()
Ответ на: комментарий от zort

> прошу заметить - геноцид анонимусов (через нечитаемую КАПТЧУ) подходит к завершению. в этом треде ни одного.

Не надо троллить.

mutronix ★★★★
() автор топика
Ответ на: комментарий от mutronix

троллинг это когда по теме. а это информация к размышлению.

zort
()
Ответ на: комментарий от dreamer

Прикручивается нормально, я у себя именно так и поднимал.

Cris
()
Ответ на: комментарий от zort

> ruby сакс потому что тормоз

Рейлс работает быстро. У него все подгружается один раз в прадакшине, так что мимо.

> джава сакс потому что открытой не bloated СMS под нее нету.

Мне кажется, что ты в каждом топике показываешь свои комплексы по-поводу того, что кроме Явы ты ничего не знаешь. И пытаясь их скрыть трубишь о ее масштабируемость надежности и скорости.

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

Cris
()
Ответ на: комментарий от Cris

все вы какие то психотерапевты. Я вас видимо раздражаю потому что не голословно показываю экспериментально проверяемые факты.

>Но есть одна проблема, человек который один раз одел легкие кроссовки

я не сомневаюсь что рельсы хороший инструмент для определённых задачь, всё работает моментально из коробки , и многим нравится красивый и удобный синтаксис. Но мой поинт в том, что всегда должно присутствовать несколько мнений. Рельсы пиарят на лево и неа прово, в то время как в джаву незаслуженно плюются.(из за стереотипа о тормознутости из 1999-2001, когда компы были слабые на память, а джава действительно тормозная). вот я (где могу) и уравновешиваю ситуацию.

>Рейлс работает быстро. У него все подгружается один раз в прадакшине, так что мимо.

это не адекватный ответ. в CMSах присутствуют вычислительно сложные алгоритмы cвязанные с версионностью документов, индексация для поиска с морфологическо-синтаксическим разбором языка как базы так и документов в файлах, сам поиск, итп (можно много найти) зти задачи динамические и не заменяются кэшем. CMSы без таких фичей это поделки.

то что я показал в ссылке, действительно не может показать процент реальной нагрузки на языковую часть в работающей CMS, но она может показать насколько медленнее в ruby будут работать тяжелые алгоритмы. на глаз это в 10-300 раз медленнее.

и насколько я себе представляю, ruby не имеет тотально убийственных фич по сравнению с джавой.

вот.

zort
()

Месье, мой тебе совет - найди какого-нибудь одного гуру и общайся с ним по icq. а весь этот сыр-бор на LOR - это только вариант запутаться. )

я бы посоветовал perl+xslt+БД-какую-нить. можно Oracle, раз уж извращаться =)

vahvarh ★★★
()
Ответ на: комментарий от zort

>это не адекватный ответ. в CMSах присутствуют вычислительно сложные алгоритмы cвязанные с версионностью документов, индексация для поиска с морфологическо-синтаксическим разбором языка как базы так и документов в файлах, сам поиск, итп (можно много найти) зти задачи динамические и не заменяются кэшем. CMSы без таких фичей это поделки.

Создать либу на C, обвернуть в gem и использовать в CMS?

>и насколько я себе представляю, ruby не имеет тотально убийственных фич по сравнению с джавой.

Назови три. Мне просто интересно узнать.

HappyCoder
()
Ответ на: комментарий от vahvarh

>я бы посоветовал perl+xslt+БД-какую-нить. можно Oracle, раз уж извращаться =)

Имхо, xslt стоит использовать только тогда, когда нужен вывод не только в html. И зачем танцевать вокруг xml, если всё равно будет использоваться БД? Зачем танцевать с бубнами, строя SQL-запросы, если в RoR есть прозрачная реализация ORM для связки Model и БД?

HappyCoder
()
Ответ на: комментарий от HappyCoder

ну например половина баз данных умеют выплёвывать сразу готовый XML.

кроме того, опять же, много ли есть проектов на RoR? особенно в рунете? А то это всё равно что кобол выучить.

vahvarh ★★★
()
Ответ на: комментарий от HappyCoder

я как раз имел ввиду что железнодорожники должны назвать фичи, за которые они платят такими потерями в производительности.

>Создать либу на C, обвернуть в gem и использовать в CMS?

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

zort
()
Ответ на: комментарий от zort

> это не адекватный ответ. в CMSах присутствуют вычислительно сложные алгоритмы cвязанные с версионностью документов, индексация для поиска с морфологическо-синтаксическим разбором языка как базы так и документов в файлах, сам поиск, итп (можно много найти) зти задачи динамические и не заменяются кэшем.

Ты такие сложные задачи решаешь в CMS :). Морфологический разбор языка o_O. Обычно все что нужно - поиск. В mysql есть полнотекстовый поиск - работает и кушать не просит.

> CMSы без таких фичей это поделки.

А CMS и есть поделки.

> и насколько я себе представляю, ruby не имеет тотально убийственных фич по сравнению с джавой.

Имеет. Скорость разработки, возможность расширения на уровне метапрограммирования и гибкость языка. Для меня это еще проявляется в отсутствии необходимости менять Vim на iDea.

Собственно против Явы ничего не имею. ИМХО, тенденции таковы, что скоро она станет вторым Си. А JRuby, Jython, Groovy, Scala будут над-языками, использующими ее библиотеки, как это сейчас происходит с Си.

Cris
()
Ответ на: комментарий от zort

> я как раз имел ввиду что железнодорожники должны назвать фичи, за которые они платят такими потерями в производительности.

Какими потерями? Перестань пустословить. Берем посылку - Ява быстрее Руби в 10 раз. Начинается морфологический анализ текста, который Руби может потянуть на 10 человек, а Ява получается 10*10 = 100 человек. К нам по Диггу заходит 300 человек и Ява закинув лапки умирает(как и Руби если не...).

Если не делать кеширование. В рельсах оно идет с коробки и тут уже работает nginx на выдачу, а не тормозной JBoss, с которым я имел "радость" поработать и убедиться в "быстроте и надежности".

Или ты можешь мне привести пример сервера с высокими нагрузками на Яве и без кеширования? Нет? Ну тогда зачем этот чес про "безопасности, интегрированности и сопровождаемости".

Cris
()
Ответ на: комментарий от Cris

>Ты такие сложные задачи решаешь в CMS :)

их больше негде решать.

>Обычно все что нужно - поиск.

такой как на лоре, да? ,без нормального алгоритма вычисления релевантности ?

>В mysql есть полнотекстовый поиск - работает и кушать не просит.

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

>А CMS и есть поделки.

не согласен.

>Имеет. Скорость разработки, возможность расширения на уровне метапрограммирования и гибкость языка.

на вкус и цвет товарищей ... по мне такая "гибкость", выходит гемороем при больших проектах.

>что скоро она станет вторым Си.

никогда не станет. она окончательно займет свою относительно новую нишу.

---------

вобщем, кому нужна скорость при безпасности, и кто не готов на потери ради "гибкости", юзайте джаву.

zort
()
Ответ на: комментарий от vahvarh

> Месье, мой тебе совет - найди какого-нибудь одного гуру и общайся с ним по icq. а весь этот сыр-бор на LOR - это только вариант запутаться. )

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

> я бы посоветовал perl+xslt+БД-какую-нить. можно Oracle, раз уж извращаться =)

Оракл - это конечно круто (особенно для повыщения скиллов), тут спору нет, но он не free, а экспресс версия на моей машине не запустится из-за ограничений на максимальный объём оперативки. Если я не ошибаюсь, то он даже на 2 процессорных системах работать не будет, так что хз, запустится ли он хотя бы на ноуте :-)

mutronix ★★★★
() автор топика
Ответ на: комментарий от mutronix

нууу ты зря. ему можно и 256Mb выделить и будет нормально елозить. у меня нуууу скажем так production сидит на гиге оперативы вместе с mysql, perl и даже ява-машина там жрала 256Mb. И при этом там не один десяток сайтов крутится на оракле писанных.

ICQ - возможно зря. Хорошее оно или плохое, но деловые контакты по другому поддерживать не удаётся.

vahvarh ★★★
()
Ответ на: комментарий от Cris

>10*10 = 100 человек. Если не делать кеширование.

считать вас в школе научили. ыыы

какое кеширование ? я же сказал что это не откешировать.

морфологический анализ текста я предлагаю делать при добавлении нового документа/поста, чтобы внести в индекс поиска (для того чтобы индекс обновлялся моментально, а не раз в день после ночного переиндексирования), так и при rebuildинге индекса.

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

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

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

если говорить про к примеру ORM подобный кеш(хотя я против ORM) , то джава тут точно быстрее.

> К нам по Диггу заходит 300 человек

от дигг/слешдот эффектов никто не защищён.

>а не тормозной JBoss, с которым я имел "радость" поработать и убедиться в "быстроте и надежности".

я в самом начале сказал что не bloated нету. попробуй jive.

zort
()
Ответ на: комментарий от vahvarh

> нууу ты зря. ему можно и 256Mb выделить и будет нормально елозить. у меня нуууу скажем так production сидит на гиге оперативы вместе с mysql, perl и даже ява-машина там жрала 256Mb. И при этом там не один десяток сайтов крутится на оракле писанных.

Я писал про Oracle express. Там вроде hardcoded ограничения на железо и если машина имеет больше 1 CPU и/или больше 1 или 2 Gb мозгов, то экспресс на такой машине работать не будет. Плюс, не представляю, где достать версию для pure x86_64 :)

В общем, оракл отпадает.

mutronix ★★★★
() автор топика
Ответ на: комментарий от mutronix

>Я писал про Oracle express. Там вроде hardcoded ограничения на железо и если машина имеет больше 1 CPU и/или больше 1 или 2 Gb мозгов, то экспресс на такой машине работать не будет. Плюс, не представляю, где достать версию для pure x86_64 :)

http://www.oracle.com/technology/products/database/xe/index.html

Oracle Database XE can be installed on any size host machine with any number of CPUs (one database per machine), but XE will store up to 4GB of user data, use up to 1GB of memory, and use one CPU on the host machine.

true
()

Забей на всю свою религиозность (не php) и ставь друпал, на php как выяснилось тоже можно писать отличные cms.

Вон даже Марк плюнул на фанатичную любовь к питону и ubuntu.com на друпале сейчас вертится.

kasian ★★
()
Ответ на: комментарий от zort

Мораль сказки такова. Java для Web хорошо и быстро, но под задачу автора темы будет слишком.

1. Тут быстрее будет разработать на чём-нибудь любом другом нежели на java.

2. А если надо будет ещё обновлять код сайта, то лучше брать MVC-фреймворк. А тут рулит RoR по масштабируемости.

Если лень заморачиваться насчёт идеологий, пиши на чём угодно спагетти-код с кучей костылей и велосипедов.

HappyCoder
()
Ответ на: комментарий от vahvarh

> кроме того, опять же, много ли есть проектов на RoR? особенно в рунете? А то это всё равно что кобол выучить.

Для того, чтобы выучить РОР, достаточно иметь две книжки и желание:
http://www.flickr.com/photos/anildigital/178961991/

А спросить, если что непонятня можно здесь http://groups.google.com/group/ror2ru/topics или на оффициальном мейл-листе.

ЗЫ: zort, этот скриншот и для тебя тоже :)

Cris
()
Ответ на: комментарий от zort

В догонку к предыдущей картинке пощу скрин показывающей всю мощь Явы: http://www.tabernadelturco.com/2006/03/20/ruby-on-rails-y-java/ .

Согласен, Ява уделывает Руби без шансовы в соотношении количество-строк-кода/единицу-функционала.

Cris
()
Ответ на: комментарий от Cris

http://www.rubyonrails.com/media/images/blahblah_vs_tada.png

картинка не открывается, блог на тарабарском, понять что на чем написано не реально.

вабще подобные сравнения не катят, т.е. если искать самый bloated java код и самый не bloated ruby, а потом их сравнивать со всеми библиотечными частями оставленными за кадром, то джава точно проиграет ;)

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

другие аргументы будут ?

zort
()
Ответ на: комментарий от Cris

смешной скриншот. показывает что под java книжек и технологий которые дублируют друг друга больше. из дублированных книжек: (struts in action,struts cookbook, jakarta struts) (jboss, web services, j2ee patterns,jfc classes, patterns of EEARC к вебу мало отношения имеют.) итд. можно долго перечислять

для того чтобы заменить эти книжки, достаточно изучить базовую джаву по одной книжке, прочитать спецификации сервлетов и jsp + прочитать туториал к спрингу. и всё.

zort
()
Ответ на: комментарий от anonymous

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

zort
()
Ответ на: комментарий от zort

добавлю. среднее качество java приложений действительно отвратительное, ибо вокруг джавы сейчас сконцентрировалось гораздо больше true-безграмотныx идиотов чем вокруг всего остального. уж точно на несколько порядков больше чем вокруг лиспа.

zort
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.