войти зарегистрироваться

Я пиарюсь whois

индекс
146,06

CMS на Perl: опыт разработки

Дисклэймер: данная статья написана XTreme. Человек не зарегистрирован на Хабре, поэтому попросил статью опубликовать. Что я и делаю. Если кому-то статья понравится, контакты Михаила могу дать через ЛС.

В далеких 90-х остались времена, когда Perl был наиболее популярным языком для написания всевозможных «примочек» для популярных тогда домашних страниц. Собственно говоря, вызвано это было целым рядом факторов, но факт состоял в том, что на каждом втором сайте, где была возможность устанавливать CGI скрипты, можно было найти гостевую книгу или доску объявлений, написанную на Perl.



На смену Perl’у по популярности пришел PHP, и это было достаточно закономерно с той точки зрения, что PHP имеет намного более понятную и наглядную модель разработки. У обоих языков можно отметить свои плюсы – большую скорость выполнения и безопасность у Perl и простоту разработки и распространенность у PHP. Но данный вопрос скорее является поводом для очередного «холивара», поэтому не будем углубляться в него более подробно.

Большинство существующих сейчас систем управления содержанием сайтов написаны именно на языке PHP. Этот факт является неоспоримым, но вызван он скорее степенью распространенности языка, чем адекватностью языка задаче создания CMS.

Я несколько лет разрабатываю систему управления сайтами на языке Perl – изначально под внутренние проекты своей студии, но на данном этапе система выросла до того момента, когда можно говорить о «публичной версии».

CMS называется Taracot, и сайт проекта доступен по адресу www.taracot.org (там же имеется демка системы). Лицензия – GPL.

image

Из основных особенностей системы я бы выделил:

– CMS написана на языке Perl и использует MySQL в качестве базы данных;
– система разработана для систем *NIX (Linux, FreeBSD и т.д.), но может также использоваться и на других системах, включая Windows;
– модульная структура позволяет подключить к Вашему сайту любой необходимый функционал, в основном комплекте уже представлено большое количество модулей;

– работает весьма и весьма шустро:
– достаточно комфортный и удобный пользовательский интерфейс с возможностью модификации;
– «дружественные» адреса URL;
– некоторые возможности технологии AJAX;
– безопасность (надеемся;)).

Система достаточно сложна в установке на серверы. Вызвано это прежде всего недостаточной поддержкой хостерами Perl’а – не стоят многие необходимые модули, и необходимо переписываться с администраторами на предмет их установки. В общем и целом, это – большая беда всех современных проектов.

Еще один недостаток – это плохая документация. Да, поскольку проектом на данном этапе занимаюсь я один, у меня просто физически не хватает времени написать документацию грамотную. То же самое относится и к хорошему инсталлятору.

Тем не менее, система получилась достаточно удачной как минимум в двух планах. Первый аспект – процесс обучения работе пользователей с системой достаточно прост (мне удалось научить работать с ней как минимум трех людей, не имеющих практически никакого отношения к компьютерам и Интернету); второй аспект – не слишком большая нагрузка на сервер, что позволяет использовать CMS в крупных проектах.

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

С уважением, XTreme.

UPD: Автора статьи пригласили на Хабр, прошу любить и жаловать — xtremespb .
+66
22 января 2009, 21:49
17
slepojpyu

комментарии (154)

  • Хотелось бы конечно увидеть тесты производительности… Или хотя бы время генерации страниц?
    • Да, забыл указать е-мэйл автора. По ссылке он есть. ;-) Я думаю, Михаил с радостью ответит на ваш вопрос.
    • Тесты на Benchmark я как-то делал, получалось намного меньше секунды. Сейчас уже точно не могу сказать…
      • Еще бы оно было больше секунды )
        Но «намного» — это очень растяжимое понятие. И зависит от железки/ОС/etc.
      • У меня ноут Celeron 1.7ghz 1.5 gb ram, мой движок на php генерит страницу ( один запрос к бд ) за 0.05-0.8 ( очень слабая машина )
        Проект на Ruby On Rails генерится в среднем 0.01 и ниже…
        Вот такие цифры должны показывать ) а не «меньше секунды» )
        • Ну тогда вам до кучи вопросов:
          1. Что значит один запрос к БД: тянем одну сущность, коллекцию, или делаем десяток джойнов?
          2. Какой проект на RoR? Структура данных?

          Очень эти цифры контекстнозависимы, имхо…
          • Меня ща минусанули только за то, что я показа с какой скоростью генерится у меня на машине проект? о_О?
            1. обычный запрос — что-то типа select * from news order by id desc limit 0,10 … просто для примера.
            2. Не большое приложение, в котором используются 2 таблицы для организации рубрикатора… ничего сложного.

            Я лишь хотел показать, что показатель «меньше секунды» это крайне расплывчато… даже на моём медленном железе… подобные штуки работают меньше десятой секунды.
            • Вас минуснули за поддержку абстрактных размышлений о скоростях генерации страниц без указания условий тестирования :)
              • На самом деле это был пример того, что нужно конкретизировать цифры…
                • Значит вас не поняли.
                  Тут это бывает сплошь и рядом :)))
                  • хорошо хоть не расстреляли… )
  • Perl, sweet Perl…
    • Эххх. жалко что почти ушло это время. А в прочем я до сих пор парсеры и временные инструменты пишу на нем. PERL FOREVER!
      • Я весь серверный код пишу на нём :)
        И я такой не один ;)
        • Я тоже пишу скрипты на Perl для задач, работающих в бэкграунде :)
          Как-то пхп для таких задач мне дико использовать :)
      • Никуда оно не ушло. В качестве примера можно посмотреть на movabletype.org
  • Zabavno 4to posle udaleniya user admin, sistema perestaet rabotat'…
    • Логика *nix — root может делать все, даже rm -rf / ;)
      • помню в win95 можно было «Мой Компьютер» в корзину кидать :)
  • хочу цмс на асме! :)
    • Может сразу на байт-коде, чтобы наверняка? =))

      P.S. Мне кажется, что CMS на PHP это более разумно. Как минимум потому, что проще разработка и сопровождение (насколько я знаю, возможности ООП в PHP5 шире, чем у Perl актуальной версии).
      • ключевое слово «кажется»
      • Поддерживаю товарища JIP.
      • Возможности ООП в Перл не ограничиваются языком программирования :)
      • на Perl очень даже интересное ООП. да и возможностей больше.
        но:
        1. не все с етими возможносстями справляються
        2. не все о них знают в достаточной мере

        ну и может еще такое:
        -. нет таких и уже популярных IDE для perl, как для php (имеется в виду Zend или PDT) с такой возможностю, как графический отладчик. естественно есть perl5db.pl, но не всем удобно работать с ним. ( ето мое имхо… )

        п.с: есть Komodo IDE, но…
        • Есть еще Eclipse + EPIC.
          Я много чего перепробовал. И кучу редакторов специально заточенных под Перл, и всякие там Notepad++, и Vim + PerlSupport…
          Сейчас я использую, в основном, 2 редактора – это Far Manager + Colorer, когда нужно что-то подправить или написать. Либо Eclipse + EPIC когда действительно нужно, чтобы разработка была удобной.
          • Кстати, конкретно дебажить и юнит тесты запускать в Еклипсе удобно
        • что значит не справляються? что значит не знают?
          В таких случаях берут кэмелбук и штудируют :)

          Чем не угодил родной перловский отладчик?
          • >> Чем не угодил родной перловский отладчик?
            Сложный и неудобный
            • ptkdb пробовали?
              • Побывал, но когда он сам себя начал дебажить… :))
        • Но что? Мне и бесплатного Komodo Edit хватает, и что самое главное — он умеет открывать удаленные файлы по ssh + кроссплатформенный.
          • кстати да, в большинстве случаев бесплатного Komodo Edit целиком хватает
      • А динамическое изменение дерева наследования в рантайме в PHP слабо реализовать? :)

        PS Правда, в Perl'e оно меняется для всех экземпляров класса что есть некоторое неудобство :(
      • :)
        а о каких возможностях ООП Perl текущей версии вы знаете?
    • на асме полноценной цмс не видел, но зато видел на с++ называется DJEM

      ru.wikipedia.org/wiki/DJEM
    • Кстати, почему бы и нет. Есть ведь Menuet OS)
      ИМХО, часто полезно делать вещи нетривиальным путем. Иногда оно получается лучше.
    • dbf
    • dbf
    • 22 января 2009, 22:44
    • #
      • 0
    С ума сойти, неужели это тот самый XTreme у которого был сайт в зеленоватых тонах на где-то на webservice.ru :) я там в начале 2000-х качал статьи и скрипты.
    • JIP
    • JIP
    • 22 января 2009, 22:57
    • #
      • 0
    интересно что препятствует развертыванию системы на хостинге
    есть несколько полезных модулей которые на «сях» написаны (работа с СУБД и датами). надесь скоро появятся нормалные pure perl реализации этих модулей

    core модулей достаточно
    • Препятствует то, что эти модули не установлены. Самая основная проблема — GD, остальные можно прописать вручную в CMSку.
      • Практически на всех хостерах GD стоит. Если нет GD то есть ImageMagick. А в своем скрипте можно выделить собственный модуль отрисовки изображений, который будет делать мэппинг запросов к GD или ImageMagick в зависимости от того что есть в наличии.
        • Это вы с php спутали. А модули для perl хостеры вообще не ставят. Забыли уже что это такое.
          • Ой не надо ля-ля!
            Все везде есть… я работаю с perl'ом и проблем с наличием модулей или установкой своих не испытываю уже давно.
  • такое…
  • Наверное кому-то покажется что я придираюсь. Ясно — что эта CMS не рассчитана на серъезное применение.
    1. Смешивать код и html — лично для меня зло
    2. Может я проглядел — но где use strict?
    3. Правильно ли я понял что данные ориентированы на windows-1251 (а как же UTF8)?

    А плохо было бы сделать тоже самое используя скажем Catalyst? А может стоило попытаться привнести сюда немного ООП? Я не из ярых фанатов perl — но на нем можно писать совсем под другому — достаточно почитать про тот же Moose. Для начала.
    • Кстати половина комментариев в NestedSets.pm — это пиз*ец — яркий пример как не надо писать комментарии. 
      # объявляем переменную, которую будем передавать процедуре перемещения
    my $data;

      • Это не мой модуль, поэтому я не удалял оттуда комментарии автора.
    • Если исплользовать ООП, подозреваю преимущество в скорости может начать таять.
      • Срочно вызовите санитаров!
        • ООП и быстродействие вещи не свместимые.
          Ни один транслятор или компилятор не сделает из ООП кода — машинный код сопоставимый по объему с тем же функционалом но написаным в обычной «функциональной» нотации.
          И даже скорость разработки не причем, ООП это удобство и скорость разработки сложных систем, но для 80% задач это не рационально.

          Извиняюсь за «холиварность» коммента.
          • 1) вы считаете, что программа размеров в 50 мегабайт будет в два раза быстрее программы в 100 мегабайт?
            2) вы считаете, что маленький code reuse способен дать в итоге меньший размер?
            3) вы не слышали, например, про inline?
            • Вообще я хотел сказать о скорости работы конечного приложения.
              • и, собственно, о том же…
                или вы намекаете на то, что perl/php+js+sql+css+html в одном файле будет работать быстрее, чем полноценная MVC?
          • Ого, а у многих совместимы. Что мы делаем не так?
          • Вы, видимо, слабо представляете себе особенности реализации ООП в перле, если пишите «акадимические» цитаты. То что будет тормозить — это без вопросов… но то что в малых системах лучше без ООП — это заблуждение.
      • Зато скорость разработки может вырасти
        • Вот так люди и приходят к написанию десктопных приложений на Java/.NET — чтоб им пусто было!
    • Первая часть коммента – в точку.
      На вторую про Муус и Каталист отвечу.

      1.Catalyst не для CGI. FCGI, mod_perl, POE или что-то еще – пожалуйста, но то только на CGI, слишком уж тормозить он будет.
      2.Moose. Я считаю что Moose – это круто, это реальный прорыыв в ООП. Я никогда не использовал Moose в реальных проектах. Я не планирую использовать Moose в реальных проектах, потому что меня вполне устраивает ООП в Перл 5.
      А вы используете Moose?
      • В дополнение.
        Catalyst – не для CGI, но сейчас активно развивается Mojo. Это детище одного из авторов Каталиста. Он, кроме mod_perl'ов, FCGI и прочего прекрасно работает под CGI, за счет своей легковесности.
        Я думаю, что это очень хороший каркас для любой ЦМСки.
        Вот немного подробней на русском: Mojo. Велосипед или эволюция?
        Сайт проекта: Mojo Web Framework
        • По поводу cgi — признаюсь чесно Catalyst с ним не пробовал — все через fcgi и сервер для разработки в комплекте. Mojo — немного слышал, но еще не видел. Moose я пока широкомасштабно не использую, но стараюсь применять там где мне удобно иметь какие-то простенькие объекты и коллекции — потом смотришь на свой код и радуешься =)
    • Мне показалось, или никто не заметил, что автор использует HTML::Template?
      • НЛО прилетело и опубликовало эту надпись здесь.
        • Просто писали, что автор не пользуется шаблонами.
  • НЛО прилетело и опубликовало эту надпись здесь.
    • Не стоит очеловечивать Перл, говорят, что ему это очень не нравится
  • С тем, что Перл может быть быстрее, спорить не буду, а вот на чем основано вот это: «безопасность у Perl»? Не вижу у Перла никаких преимуществ в этом плане.
    • Taint mode?
      (код автора не читал)
      • Плюс неймспейсы которые в php относительно недавно. Тейнт мод кстати приводит программы к максимальной детерменированости (постоянству исполнения). Кстати, при разработке всегда использую warnings fatal all (останавливается исполнение по первому варнингу), а в продакшн фатал алл снимаю. Вобще в перл 5 есть достаточный инструментарий, чтобы писать максимально стабильные и безопасные приложения. При условии правильного радиуса кривизны рук (!), продуманости алгоритмов… и т.д. Склоняюсь к мнению, что это не техническая проблема (написание небезопасных программ, про perl могу сказать точно), а проблема кадров. И еще, если уж и говорить про проблему безопасности, то надо учитывать что проблемы на уровне исполнения (машины исполнения perl и php), нужно понимать, что эти машины, тоже написаны людьми, и в них тоже есть проблемы (про perl кстати крайне редко что-то проскользывает в репортах).

        • Вроде в php есть safe_mode, там тоже какие-то ограничения, более того, можно запрещать отдельные функции. Я тоже люблю перехватывать любые варнинги/нотисы в php и прерывать работу скрипта в этом случае, так как правильно написанный код их не генерирует.

          > Вобще в перл 5 есть достаточный инструментарий, чтобы писать максимально стабильные и безопасные приложения. При условии правильного радиуса кривизны рук (!), продуманости алгоритмов… и т.д. Склоняюсь к мнению, что это не техническая проблема (написание небезопасных программ, про perl могу сказать точно), а проблема кадров

          С тем, что проблема кадров, согласен, возможно простота php не очень квалифицированных разработчиков, просто я думаю неопытный perl-разработчик может допустить те же самые ошибкти, связанные например со слабой проверкой входящих данных.
    • возможно _сейчас_ у php плохая репутация. про дырки в функциях довольно часто пишут. не интересуюсь этой платформой, но иногда вижу багрепорты в своих фидах

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

      в реализации багов хватает (умудрился найти рекурсию в регкспе)

      «безопасность у Perl» здесь: perldoc.perl.org/perlsec.html

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

        Кстати перловые регулярки, стали стандартом де-факто, библиотеку по регуляркам можно юзать в практически любом нужном вам приложение (си, плюсы и т.д.) не написанном на perl ;)
      • На перле имеется возможность писать как угодно и что угодно. Факт в том что одно и то же можно делать множеством различных способов, это идеология языка №1, если кто-то хочет строгости в стили программирования, однородных конструкциях, синтаксисе, то перл не для него.
    • Технология CGI, имхо, имеет много плюсов в плане безопасности, особенно если suexec. Но это ИМХО, разумеется.
      • а можете назвать хотя бы пару плюсов по сравнению с jvm, если уж на то пошло?
        • Я могу ошибаться, но все-таки нельзя сравнивать виртуальную машину с интерфейсом?
          • А с чем тогда предлагаете сравнивать CGI? С mod_perl что ли?
            • Да с чем угодно, но только не с VM. Например, с mod_php?
              • А почему нет? Или вы будете отрицать, что у java-«приложений» дела с безопасностью обстоят лучше, чем у perl-«приложений»(через cgi)?
                • Отнюдь. Просто принцип различный, а безопасность лучше сравнивать у технологий, работающих по одному принципу, ИМХО.
                  • а разве у mod_php и *cgi один принцип работы?
      • php вроде как поддерживает и CGI, и FastCGI
  • Если честно, то система достаточно слабенькая. Без обид.

    7 лет назад я тоже писал в одиночку CMS на Perl. Очень любил этот язык, да и сейчас уважаю. Скачал CMS, посмотрел — прямо дежа вю! В том плане, что на дворе-то 2009 год, а там всё какое-то древнее и простенькое :)

    По существу, то помимо разнообразных архитектурных ограничений системы, прилично и проблем с юзабилити. Да, всё понятно, это сделано программистом-юниксоидом, в аскетичном стиле. Но дизайнер/юзабилист бы совсем не помешал, тем более мы реально не в 2000 году, когда такое ещё могло прокатить.

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

    Из того, что сразу бросилось в глаза (вперемешку про разное):

    1) Для обычного пользователя поле Groups (взятое из Unix) ни о чём не говорит ( taracot.rh1.ru/cgi-bin/taracot/admin/module.cgi?module=users&page=1&filter=&filter_oncat=&sort=0&action=add ), там должен быть список со множественным выделением. И ведь редактора групп нет вообще, т.е. даже взять их неоткуда.

    2) Везде кнопки редактирования и удаления расположены впритык друг к другу — промазать очень легко

    3) Delete confirmation message слишком абстрактный («Are you sure?»), никакой конкретики о том, ради чего этот вопрос

    4) У иконок операций над элементами списков нет тултипов

    5) Язык админки переключается только через правку config0.pm

    6) Все операции проходят через промежуточную страницу, на которой написано «Operation successful.» и линк Go back. Совсем плохо.

    7) изменения порядка следования элементов выполнены через гиперссылки в виде стрелок — никакого drag-drop и ajax

    8) Система шаблонов — редактируются файлы в textarea. Удобства меньше, чем даже в notepad — какой смысл в таком редакторе? Там же, шаблоны общие, т.е. нет привязки к конкретному языку сайта

    9) Работа с Category tree — вообще фантастика, надо видеть этот фарш из голубых стрелочек во все стороны :)

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

    Дальше не могу, реально слишком много ужасов :)
    • Безусловно, Вы правы. Система разрабатывается давно, под конкретные проекты и одним программистом. Поэтому многие вещи в том же юзабилити достаточно ужасны, но я стараюсь по мере появления свободного времени их улучшать.
  • ох… ) я програмил как на перле так и на пхп… могу привести один пример. как по мне — это очень ярко илюстриреут мое видение этих двух языков.

    если ваш скрипт постом получает данные:
    — на перле, вы берете готовый, кем-то написаный или сами садитесь пишите, скрипт на перле, который парсит пришедшие данные в более удобный для работы с ними вид
    — на пхп, можно и самому работать с входящим потоком STDIN, но есть готвый, стандартизированный, проверенный, вшитый способ обработки вхоядщего потока, просто $_POST

    перл это мега рульный язык, но это не значит что на нем удобно писать веб-интерфейсы
    чесно говорю — я бы эту цмс ни под каким соусом не взял бы, это для фанатов и у кого много времени…
    • на Perl люди для этого используют либо CGI* модули или производные для mod_perl.

      • да причем тут что для этого используют… этот пример о том что многое в пхп автоматизировано и стандартизировано
        • А что Вы таки считаете что подключение модуля это не автоматизация?

          Кстати говоря пиэйчпи как аз из за «многое в пхп автоматизировано» считается говно язком.
        • То, о чем вы говорите, называется не «автоматизация», а «засорение языка» или «смешивание языка с веб-движком». Если я захочу писать на перле в ПХП-стиле, я поставлю mason, и там у меня будут и распарсеный запрос, и все остальное.
    • Что-то, похоже, вы очень давно «програмили» на перле и явно злоупотребляли Matt's Script Archive.
      Не парсит никто на перле STDIN.

      CMS может быть гораздо более интересна, если автор ее оттестирует и доведет ее до правильной работы в mod_perl-окружении.

      • Вы правы, я начинал еще во время Matt's Script Archive, и собственно Perl'у учился по книге этого самого Мэтта лет этак несколько назад.
    • а минусовать то чего )… вы когда-нибудь видели перл код после 3-х лет эксплуотации и развитии проекта… ) даже с объектами? )

      если перл Можно использовать для веб интерфейсов — это не значит что его Нужно использовать для этого? у каждого языка есть своя сфера применения и свои задачи, для чего и почему тот или иной язык создавался…
      • В сферу применения Перла входит создание веб интерфейсов.
        Вы думаете, что Perl и Template Toolkit плохо подходит для генерации веб интерфейсов?
        Из своего опыта, могу сказать, что очень даже хорошо.

        Если у меня база данных заполняется данными, добытыми перл-скриптами, то почему бы мне не использовать Перл для вывода этих данных в виде веб интерфейса? Я так и делаю.
      • Да, видел. За эти три года он стал лучше и аккуратнее.
  • Свою первую CMS я тоже написал на Perl. И очень хорошо работала :) После изучения PHP с лёгкостью перенес все принципы работы на новый язык, на нём и остался.

    А работало всё так:
    был файл в корню, например www.site, который был пописан в .htaccess как исполняемый perl. А все ссылки были вида: /www.site/main.html, /www.site/about/index.html…
    И этого было достаточно! Модули, динамические карты, шаблоны — и всё в прошлом веке! :)

    Эх, было время. Как вспомню собак @_, и $0 — так сразу хочется туда вернуться ))
  • А вот по поводу производительности. Слэшдот до сих пор же вроде на перловом скрипте пашет…
    • ага, на 18 дуал-квадах… ;)
  • кто-нибудь, расскажите автору про MVC!
    • Спасибо, уже рассказали, буду разбираться
      • ничем не примечательное плане кода «поделие» набрало уже под сорок плюсов? Да, либо «хабр уже не тот», либо тут замешана какая-то магия перла…
        • Это особая, уличная магия :)
          Я же не писал, что это супер-мега-система с отличным кодом. Это мой личный проект, и я бы хотел, чтобы к разработке данного «поделия» присоединились такие вот специалисты, как Вы. А просто поругать свою поделку я могу и сам, ибо о бОльшем количестве недостатков знаю не понаслышке:)
        • В спорах рождается истина. Если статья спорная, но интересная — почему бы и нет?
          Хабр уже не торт?!
          • ну я пока что вижу скорее отрицательные отзывы, положительно о тут отзываются только те, кто писал/пишет на перле…
            • Человек, написавший статью, принимает критические комменты к сведению. Вероятно — исправит недочеты, о чем в статье и сказано. А новички учатся на чужих ошибках — разве это плохо?! И не в этом ли смысл Хабра?
              • «вероятно — автор совсем плохо знает программирование», уж извините за прямолинейность.
                • 1. Вероятно, Вы слишком критически настроены, а прямолинейность — это не есть плохо. ;-)
                  2. Если автор плохо(?) знает програмирование, объясните почему плохо, что он обратился на Хабр за советом/критикой?!
                  3. boorooom =/= автор статьи, на всякий случай. boorooom вообще не разбирается в программировании :) пока что.
                  • 1. Вероятно по той причине, что из-за вот таких статей «хабр уже не тот».
                    2. Я уже написал почему — автор, очевидно, совсем не знает MVC, и даже более того, не отрицает этого. Писать веб-сайты как минимум без MV — имхо очень плохо.
                    3. «boorooom вообще не разбирается в программировании :)» заметно по "=/=". Программист скорее всего написал бы "!=" ;)
                    • 1. Теперь я вижу — Вы именно придираетесь. Это видно по «хабр уже не тот».
                      2. Вы не ответили на вопрос, а только ещё раз повторили свой тезис, который ответом на мой вопрос не является.
                      3. Я не скрываю, что я не программист. И никогда не говорил обратного. И ведь именно "!=" хотел сперва написать, да подумал соригинальничать. А так хотелось под «матерого программера» хотя бы в комментариях закосить ;-)

                      P.S. Не принимайте мои ответы слишком всерьёз, я просто помог человеку опубликоваться. К добру ли, к худу — сообщество решит.
                      • 2. Простите, неправильно прочитал ваш вопрос сначала. Скажите, а плохо ли постить код типа ша (boolValue.toString().length==4) {...}? (хотя тут я, конечно, преувеличиваю, но суть идеи, надеюсь, понятна)
                        3. Ну, я вообще тоже пошутил ;)
                    • >> Я уже написал почему — автор, очевидно, совсем не знает MVC, и даже более того, не
                      >> отрицает этого.

                      Было бы лучше, если бы автор не знал MVC и отрицал это :))
                    • Да, кстати, последнее соображение на сегодня, если позволите.
                      Я заметил, что часто весьма спорные/неоднозначные/даже неудачные статьи на Хабре приводят к появлению новых статей сходной тематики, на них ссылающихся.
                      Т.е. по сути — становятся катализатором, порождающим качественный и интересный контент. А это уже позволяет Хабру быть «тем». И это правильно, на мой сугубо не программистский взгляд. За сим — пошел спать, всех благ.
  • Я думаю, это такой обычай. Каждый веб-разработчик должен когда-то написать свою CMS. Не надо этого стесняться, ничего плохого в этом нет :-)
    • Первая стадия любого программиста — бросаться писать решения под все свои задачи.
      Вторая стадия — искать существующие решения и затачивать их под себя.
      Третья — когда уже не пытается даже затачивать, и можно уже идти в менеджеры…
    • STZ
    • STZ
    • 23 января 2009, 02:06
    • #
      • 0
    Эх, помню времена.
    CMS — Sanitarium WebLoG
    Форум — YaBB или Ikonboard.
  • Фишка-то CMS чтобы написать ядро и выложить API для модулей. Насколько я понимаю, для CMS-ок очень критично выбрать именно тот язык у которого большое community для расширяемости сторонними разработчиками. Поэтому я сейчас пишу CMS на PHP5 + Zend Framework
    • Вы действительно думаете что вашу CMS будет расширять какой-нибудь сторонний разработчик?
      • А почему бы и нет? (я думаю разработчики wordpress, drupal, joomla не были так скептически настроены).

        Мое имхо, что CMS должна предполагать ее модификацию. И самое простое — это написание отдельных модулей (плагинов) у которых слабое взаимодействие с ядром. Я вообще считаю что самое главное написать костяк и сделать хороший порт для плагинов — и дело в шляпе (люди все остальное сделают сами). Ну посудите сами, что такое jQuery, например, без ее плагинов?
        • Когда разработчики wordpress, drupal, joomla разрабатывали свои проекты, то им не нужно было отвечать на вопрос «А чем это ваша CMS лучше Вордпресса, Друпала или Джумлы?».
          В любом случае, у вас потенциально может получится нечто лучшее, но у вас Очень большая конкуренция ;)
          • Да, они (wp, drupal, ...) хороши, но ждем CMS нового поколения (полностью на php5, с новой идеологией ядра).
            Может оффтоп, но написание своей CMS возникло потому что есть в этом потребность и потому что есть неплохая книжка
    • Вы явно выбрали не тот раздел, чтобы сравнивать перл и пхп в сторону последнего. Перловое комьюнити не имеет себе равных.
      • Я просто плохо знаю Perl (работаю на PHP). Не спорю, есть в мире действительно хорошие вещи!.. наверное поэтому я до сих пор играю в starcraft BW =)
      • >Перловое комьюнити не имеет себе равных.
        Вы это серьёзно? По мне так перл уже давно «мёртв»…
        • Не мертв. Хотя щас модно говорить об этом. Тем не менее, это никак не влияет на его комьюнити.
          • Дело-то не в моде, а в том, что perl6 будет не скоро, новых разработчиков практически не появляется, «конкуренты» очень сильны итд… Да, на перле написано «пол-линукса», но в данной теме мы же говорим о нём как о языке для веб-девелопмента.
            • Да причем же здесь все это? Или может у нас с вами разное понятие о «комьюнити»?
              CPAN пополняется ежедневно, крупные конференции и локальные сборы перл монгеров проходят стабильно (в т.ч. и в России). Все это продолжит свое существование независимо от состояния «конкурентов».
              • >Все это продолжит свое существование независимо от состояния «конкурентов».
                1) существование, но не развитие.
                2) перл «жив» в-основном из-за легаси-кода и «линукса».

                поймите, мне от смерти перла ни горячо, ни холодно, я просто констатирую факты.
                если у вас факты, доказывающие неправоту п.1 и п.2 — высказывайте, мне интересно.
                • Ну мы ведь говорим о комьюнити, а не самом языке? Тогда скажите мне, что вы имеете ввиду под развитием именно комьюнити (ну кроме притока новых людей, которых хоть и очень много, но они есть)? Это уже большая, устойчивая инфраструктура с «головой» в The Perl Foundation и «отростками» в виде локальных PM групп (пример — Moscow.pm).

                  По поводу п.2: это имеет место быть. Но в меньшей степени, чем в «основом». Честно говоря, мне лень отстаивать свою точку зрения. Именно потому, что мне не горячо и не холодно от этого. Вы даже можете подумать, что я увиливаю от этого, потому что мне сказать нечего)
                  • 1) Вы можете представить себе комьюнити вокруг языка, который не развивается? Лично я — с превеликим трудом. А чтобы понять развитие комьюнити можно посмотреть, например, на Ruby/RoR
                    • Ну вы говорите так, как будто его (развития) вообще не происходит. А между тем, разработка perl6 все-таки продолжается. И особо желающие его уже опробовали. Относительно недавно был релиз perl 5.10.
                      Выход perl6, не важно когда он случится (в разумных пределах конечно), обеспечит комьюнити «жизненной силой» еще долгое время.
                      • >Относительно недавно был релиз perl 5.10. Выход perl6, не важно когда он случится (в разумных пределах конечно)
                        рубисты, кстати, точно так же говорят о «развитии» руби — мол 1.8.x недавно был, и 1.9 _пишется_, предпочитая не вспоминать, что 1.8.0 вышел уже лет 5 назад, а 2.0 в обозримом будущем пока не видно.
                        • Ну то рубисты. Релиз 5.10 был не два года назад, а всего лишь год) Да и perl6 по при умеренно оптимистичном подходе видно в обозримом будущем (09-10 год)
                          • А я вот не жду perl6… по мне так лучше бы оптимизировали производительность существующих версий. Perl6 — это другой язык. Имхо, мертворожденный. Если переходить на него, то лучше уж на питон… или руби на крайняк — там хоть уже инфраструктура есть.
                            • Я описал свое видение ситуации в целом. Лично я perl6 тоже не жду в плане смены основного языка (хотя кто знает, как все сложится...). Однако, несомненно — «поиграться» с ним мне конечно хочется.
                              Относительно оптимизации текущих версий: имхо, 5ая ветка достигает (достигла?) своей точки максимума в сложности реализации. Видимо настал момент переписать все с нуля.
        • Вы видели его тело?
  • Не беспокойте дух Perl он в свое время сослужил хорошую службу :) пусть покоится с миром.
    • На нём написано половина линукса.
    • Ну это вы хватили лишнего. Perl еще нас всех переживет. Perl, как гоночная машина — научится управлять сложно, но если научился, то уже никогда не захочешь на чем-то медленнее ездить.
    • На нем написано половина интернета.
      • Чего минусуете? Наврное потомучто больше половины а не половина…
    • Вас зомбировали этой мыслью…
    • Я имел ввиду вебразработку на перле
  • А русская версия будет?
    • Я когда код смотрел, то обнаружил, что там для всего есть русские языковые пакеты, просто язык админки зашит в конфиге, и он не русский ;) Если переключить — всё заработает :)
    • На самом деле, есть русский язык. И даже есть переключение русский-английский.
      Гляньте живые проекты:
      www.re-hash.ru/
      ahu.li/
      fotokost.rh1.ru — он еще делается, но зато там есть модуль фотоальбома
  • Ндя, довольно стрёмный код без комментариев… Не легко вам будет сформировать сообщество вокруг своей CMS. ООП + MVC + внятный API + коментарии или документация — в эту сторону надо топать.

    PS Вот за такой код и не любят Perl-разработчиков…
  • Я вас разочарую наверно не каждый согласится ставить CMS на Perl, так как специалистов для ее поддержки нати будет сложнее, а денег они возьмут больше. А по поводу скорости не знаю, если основная нагрузка идет на БД, то использование Перла вряд ли радикльно ускорит систему.
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.