LINUX.ORG.RU
ФорумTalks

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


0

0

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

★★★★
Ответ на: комментарий от r_asian

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

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

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

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

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

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

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

;)

roller ★★★
()
Ответ на: комментарий от 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 ★★★
()
Ответ на: комментарий от dreamer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вот.

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

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

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

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

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

HappyCoder
()
Ответ на: комментарий от 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
()
Ответ на: комментарий от Cris

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HappyCoder
()
Ответ на: комментарий от 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
()
Ответ на: комментарий от anonymous

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

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

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

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