Как я шагал по пути создания CMS

[mpak666]

Думаю, почти каждый веб-программист задумывался на тему свой «CMS», мега крутой, мега универсальной, удобной и завоевывающей мир. Задумывались, писали, разочаровывались и писали снова. Я, разумеется, так же прошел этот тернистый путь, что-то изобретал, на глазах росли продукты вокруг, рос я и так же росли мои продукты. Хочу немного рассказать как раз о новом своём детище, как я к нему пришел это будет первой статьёй, второй станет, что представляет внутри новая система DC.CMS и как я научился говорить нет себе, мириться с рядом вещей, что не всегда удается сделать в «идеальном» мире.

В целом веб-программированием я занимаюсь уже лет 10, а программированием и его изучением лет наверное 16. Среди этих сроков, есть годы и месяцы тяжких «методов тыка», когда буквально приходилось по крупицам выбирать информацию из сети, тяжко было раньше. Не было столько блогов и всяческих коммунити, теперь проще, а раньше допытывать Crazy на Deforum’е казалось ежедневным занятием. Что-то пошло на пользу, осело в мозгу, что-то не пригодилось и с годами стало иначе. Но базис и фундамент это отлично, отличнее всего запомнил я фразу «ты не должен этого хотеть», за эту фразу отдельное спасибо. Да, именно эта фраза может стать ключевой в понимании программирования. Но об этом в итогах, а пока вернемся к CMS.

Я уже говорил, что почти каждый веб-программист писал CMS. Возможно ради практики, возможно, ему казалось, что его идеи еще не реализованы или просто из-за «лени» возиться с изучением чужих систем. Есть и еще варианты, разочарование - это когда, пересмотрев кучу уже ставших почти «де-факто» систем приходит понимание, что весь этот багаж программисту начинает казаться бессмысленным. Себя я мотивирую именно двумя последними пунктами: лень и разочарование.

Когда я начинал входить в веб-программирование, PHP4 был не так распространен, даже еще PHP3 встречался. Бесплатный хостинг был не всегда с MySQL, чаще даже без него. И всё еще силён был Perl и крутая аура окружала этот язык. Потому я не долго думая слезая с MFC (C++) и «виндового» программирования выбрал Perl. Первоначально CMS не было, как и особого такого понятия. Тогда миром владела Nuke! Всяческие портало-образные дот комы, html с фреймами или большие проекты в Dreamweaver 3 с site-map и подключением репликации по ftp. Потому когда в какой-то момент захотелось сделать новостной портал, то это было ужасное скопление .shtml файлов к которым при помощи SSI крепились отдельные куски как чистого html, так и CGI скриптов. Последние в свою очередь дергали ужасно медленную базу MySQL 3 тихо испускали дух на больших соединениях. Потом были переработки в mod_perl, чтобы повысить производительность и даже тупо принудительное кэширование всего в html.

Но в какой-то момент в моих руках родилась первая CMS, назвал её незатейливого DataCenter 1. Это было 2 простых скрипта, бэкэнд позволял создавать файлы баз (своя текстовая база оказалась универсальнее не всегда стабильной и имеющейся MySQL), авторизовался и раскидывал текстовые данные по текстовым файлам. Фронт уже был сложнее, он позволял доставать поля из текстовых баз, показывать как одиночный документ, так и фильтрованный список. Если бы я сейчас глянул на это, наверное бы долго смеялся, это ужасно. Система не прожила и 10ти сайтов. Надоело, что на каждый раздел надо создавать свой shtml файл с SSI директивами. Причем к тому времени появились свои серверные мощности.

И вот на одном из «больших» сайтов родилась версия 2. Версия 2 уже была интереснее в плане открытия для себя mod_rewrite который во многом определил мой дальнейший взгляд на CMS. Так как ЧПУ стал не только «понтом» системы, но и основой логики ядра. Версия была сразу заточена в двух драйверах данных: из текстовых баз для простых сайтов в 500-1000 страниц. Тут тягать MySQL мне казалось и даже сейчас я считаю бессмысленно, всю нагрузку решал файл кэш или преобразование в статику. И вторая версия, которая несколько раз использовалась на крупных сайтах, и в одном СМИ, была уже посерьезнее mod_perl, mysql и кэш в статику. Но версия продолжения не получила, после ряда проектов стало сложно поддерживать. А статичную версию можно было поставить на сайт в течении минут. Я даже уже начинал делать «соревнования» с самим собой а-ля «а за сколько я сверстаю сайт и повешу на движок в этот раз»?! Да, рекорды без верстки с креплением изначально новых layout’ов и шаблонов модулей шли на 20ые минуты. Именно вторая версия системы со статичными базами получила дальнейшее развитие. Тогда я даже не зная о названии впервые реализовал для себя «активные шаблоны». Теперь ни база, ни ядро, а лишь «дизайн» определял какой ему модуль поставить в эту колонку, а что отобразить, например в анимированной шапке. Это было забавно, если бы не так тяжко для серверов. Честно говоря, запускать Perl скрипты с 5кой модулей и частыми require (do) в CGI это не самый оптимальный по памяти и скорости вариант. Зато, конечно же чистый, никакого мусора и утечек, всё стабильно, но очень мало жизнеспособно при больших посещениях. Но сайтах компаний такой подход вполне, нагрузки в виде огромных посещений у них не всегда частые, даже напротив очень малые. Хотя всё еще вижу в сети проекты и с несколько тысячными посещениями, но я знаю, что там внутри целый dedicated сервер под капотом на один единственный сайт. В следующем этапе победил PHP.

Да, уже был вынужденный шаг ухода в PHP. Помимо основной работы у меня всегда был постоянный фриланс. А тут уже клиенты сами начинают диктовать условия, да и рынок, конкуренция начали требовать проекты на PHP.
Мотивация простая, PHP простой язык, потому вы сделали сайт, а поддерживать, развивать и возможно переделать на новый сайт сможет уже сторонний разработчик. Сам я этого не понимаю, потому, как нечасто с приходом редизайна сайта всем лень копаться в чужом коде, очень лень, потому чаще новый сайт сразу подразумевает и новую программную часть. Так, что в целом я до сих пор убежден, что если вам разрабатывают сайт, то без разницы на чем, не диктуйте разработчику свои условия платформы, ибо с приходом нового разработчика всё будет заново. Потому разработчику лучше разрабатывать в той среде где он как рыба в воде.
Но мы отошли, это была ремарка. PHP действительно простой язык, а особенно после Perl’а всё очень просто и кажется, что функции есть под любую задачу. Конечно же немного пугает такое обилие, но есть в этом и простота, что нет необходимости реализовывать это еще раз или нет нужды, что-то собирать из CPAN и доставлять под нужду. Прелесть PHP в обилии «всё включено», как в этом же его и слабость из-за отсутствия библиотеки пакетов, PEAR не в счет, ибо это дикий отстой. К чему до сих пор не могу привыкнуть в PHP так к регулярным выражениям, все эти preg_match, _all, _replace и т.п. когда так удобно было «// =~ s и =~ m» в простоте. Ну да ладно. PHP приблизил MySQL ко мне. Это был не DBI (хотя PDO позднее сделал еще ближе), не было встроенных placeholders, удобных классов и прочих вкусностей, потому и появлялись такие замечательные библиотеки как DBSimple и т.п. Это был период когда DataCenter пытался удобно слезть на PHP, была даже версия почти в один-в-один переписанная на PHP, только интерфейс был новый, но даже конфиги и старые базы проходили. Но не прижилась, 2-3 сайта и тотальное забытие. PHP4 казался не удобный, да и зачем, когда почти каждый хостер держал CGI-BIN папку. Была одна забавная интеграция старой CMS системы на языке Perl с личным кабинетом на PHP, где база была в SQLite, шаблонизатор QuickTemplate, интеграция с webmoney и т.п. Но это было давно и неправда, да и в целом ужасно. Мне кажется, почти каждый программист с выходом нового продукта считает старые свои продукты если не ужасными, то в любом случае отсталыми. В общем, версия 3и так и не увидела свет.

Здесь начался период поисков, терзаний, экспериментов. Поиск чего-то, что могло мотивировать на написание новой системы на новом языке и отказ от уже устоявшейся, стабильной и не давшей ни одного сбоя в плане безопасности системы и переваливших уже за 200 плагинов, которые надо было бы всё же переписывать. Это очень интересный период, я ставил почти все бесплатные CMS системы имевшиеся на рынке. Были и варезные установки, но это лишь для знакомства. Это был неоценимый опыт, я научился переваривать чужие исходники, брать чужие идеи, развивать, использовать примеры и т.п. Мне даже в какой-то момент стало нравиться, что мой фриланс состоял почти на 90% из доработки чужих проектов, развитие чужих систем и сайтов. В целом это не плохая ниша, востребованная, не сильно конкурентная и всегда востребованная. Проекты создаются, проекты сложные, индивидуальные и кому-то надо их развивать дальше, переделывать и поддерживать.

В темны период поисков идеи, работа шла чередом. В один из моментов я понял, что мне проще какую-то фигулину сделать на PHP, а уже не на Perl’е. В этот момент я познакомился с Фреймворком CodeIgniter, да и в целом с идеологией MVC. Это был маленький взрыв для меня в будущее, так как именно CI мне дал интерес к отцу так сказать - Ruby on Rails. В этот момент мне хватало всех инструментов CI, в паре с коллегой у нас вышли несколько больших проектов. И кучка множественная личною мною собранных проектов со всеми пределами MVC. После ряда проектов сразу было решено, что ядром новой CMS системы уже точно станет framework. Сказано сделано. Разумеется система проектировалась, решались основные вопросы, коих было 3.
1. Дерево страниц - каким ему быть? Какую структуру удобнее выбрать? Делать просто списком смежности или же материализованные пути или может связные списки?
2. Модули, как совместить идеологию MVC когда одна страница - один контроллер это априори с CMS системой в которой надо отвязать URL от указания и намеки на контроллер, да и еще сделать возможность модульности страниц, блочности.
3. Интерфейс - каким он должен быть, что будет удобнее пользователю и самому разработчику? Как сделать так, чтобы разработчик мог быстро и удобно развертывать приложения на базе CMS и обязательно под себя мог настроить или переписать?

Вам знакомы эти вопросы? Значит, вы тоже писали свою CMS. Заглядывая, вперёд скажу, что первые 2 вопроса были очень тяжелыми, хотя и 3тий тоже не подарок. Но если 1 и 2 мне кажется в данный момент мною решены, то с 3им я еще вожусь и разбираюсь. Но уверяю вас, экспериментов было по вопросам много, приходилось даже выпускать сайты в «сыром» и не совсем оптимальном виде, время поджимало, тут было главным решение глобальной задачи, а не красивой реализации. Каюсь, есть такое фабричное чувство, но ничего с этим не поделать, кушать хочется всегда ;-) Но в целом не скажу, что оптимальны мои шаги и решения, но они позволяют сайтам выходить из под моей руки и местами даже гордиться своим кодом. Мне конечно пришлось отказаться от ряда решений и желаний. Самое главное я решил отказаться от универсальности! Это возможно в идеальном мире, но только не на Земле. Потому, что совместить два разных сайта от новостного СМИ до крупного Интернет-магазина или же простого сайта фирмы торгующей нефтепродуктами - невозможно. Нужно научиться себя заставить писать, корректировать или правильно применять уже имеющиеся модули для каждого нового проекта. Посвящать ему больше времени и относиться к нему со всем теплом как к своему детищу. Понимаю, что это не всегда возможно, может заесть рутина или казалось бы малооплачиваемость или малоинтересность проекта, но стремиться к этому надо, так будет легче в дальнейшем.

Это может стать еще одним выводом. И всего у нас их три:
1. Хорошая мотивация к созданию своей CMS, это лень - когда вам лень делать столько лишних вещей, а кажется можно сделать проще и главное быстрее. Хорошо, если еще эта «лень» подкрепляется реальным опытом построенном на «разоровании» в чужих продуктах. Когда вы реально понимаете, что готовы и можете создать свою CMS и она будет удобнее, быстрее и проще аналогов.
2. Нужно научиться «не хотеть, чего не надо», то бишь говорить себе нет. Я вот еще с этим борюсь, но уже понимаю, что зря например я запихнул в систему 4 типа визуальных редакторов, на самом деле хватило бы одного, а не пихать туда TinyMCE, FCKeditor, Markdown и CodePress. В любом случае выбор пользователю не нужен, ему нужен один хороший редактор. Я вот сейчас, например, очень жду выхода новой версии Redactor’a от Imperavi (и Lessio) На нём и остановлюсь, заменив уже ставший стандартным TinyMCE.
И 3ий вывод это, что не стоит стремиться за универсальностью. Нельзя угодить всем, создав сместь трактора с Феррари вы рискуете взорваться на тестовых испытаниях. Нужно уметь искать компромисс между тем делается ли CMS для пользователя, чтобы ему было просто и удобно обновлять содержание или же для разработчика, чтобы ему было удобно быстро устанавливать, настраивать и расширять систему под свои индивидуальные нужды. Для себя я уже решил сделать удобный CMF на базе framework’а под капотом, где будет вполне удобная для пользователя сторона администирования содержания, но в любом случае как и управление техническим средством требующим прочтения мануала или хотя бы кратких основ работы с системой. В любом случае тут важнее будет последующая поддержка разработчиком, вопросы будут всегда, даже как бы не была тупа и проста система, найдётся еще тупее и проще человек, что не сможет с ней разобраться. По мне так уж лучше развивать саппорт, чем отуплять совсем до безобразия саму систему, что ведёт к вынужденном урезанию функционала.

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

Итог прост. Писать CMS - это здорово! Итог.

Опубликовано здесь