Pull to refresh

Comments 77

Немного не в тему, просто интересно, почему «коробочная»? Для меня «коробочная» подразумевает, что продукт можно получить почтой, с диском, лицензией, доками, etc… — в общем для этого и нужна картонная коробка.
UFO just landed and posted this here
На счет comproser — соглашусь с вами, возможно это достаточно серьезное упущение. Насчет best practices не совсем соглашусь — пытался следовать тем, о которых читал для данного языка. Существует достаточно много публикаций о best practices с достаточно расходящимися мнениями. Благодарю за рекомендации.
UFO just landed and posted this here
через пару месяцев там сам автор «ногу сломит»)
// Когда я начинал это писать, только Бог и я понимали, что я делаю
// Сейчас остался только Бог


habrahabr.ru/post/191772/
Меня смутило название классов с маленькой буквы.
Ну насколько мне известно есть несколько устоявшихся «практик» именования переменных и классов, среди которых CamelCase и unser_score
Но конкретно тут все перемешано. Используются пространства имен engine\template вместо хотя бы ffcms\engine\template или еще лучше ffcms\templating… Короче толку от пространства имен без имени вендора… Да и где-то они юзаются, где-то нет…
Я бы сказал так — практически у каждого языка программирования сейчас устоявшейся является одна из этих практик. Для PHP — это был и есть CamelCase.
Ниже уже ребята подсказали, обязательно стандартизирую в будущих обновлениях.
Почитал. Первые строки вселили надежду, что дальше будет опрятный ООП-код с небольшой примесью мусора. Но уже начиная с метода viewUsereditNews код стал напоминать ту «процедурную» лапшу, которой я занимаюсь на работе.
это метафора, например есть framework symfony и в комплекте(в коробки) с ним идет шаблонизатор twig, orm doctrine, ну и куча другого.
а вот например SonataAdminBundle нужно вручную доставлять если нужно.

в данном случае автор говорит что все модули для этой cms идут в комплекте с ней.
Под «коробочная CMS» понималось то, что в стандартном представлении вместе с голой реализацией идет поставка ряда «расширений» (компонентов, модулей и хуков), хотя действительно, данный термин возможно устарел.
вы добавили модуль миграций, могу по опыту сказать, что без него сложно переносить базу, особенно когда роутинг в БД храниться или настройки раздела..., на тестовой машине настраиваешь и потом чтобы задеплоить начинаются проблемы, особенно если кейс бальшой был.
UFO just landed and posted this here
Ну насчет 80% я бы поспорил, но действительно достаточно много, но такой вызов гарантирует единую точку вызова объекта.
UFO just landed and posted this here
Единую точку вызова может гарантировать dependency injection, а не singleton. Ваш стиль — это жесть какая-то (
UFO just landed and posted this here
Вы правы, конструктивная критика всегда к месту, вне зависимости от сравнения, да и в стране у нас ведь демократия и свобода слова.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Само ядро Joomla в принципе неплохо… А вот расширения — это ад. Там много чего тупо для обратной совместимости, но в целом там есть все что бы разработчики расширений писали качественные продукты… но почему-то никто не парится.
UFO just landed and posted this here
UFO just landed and posted this here
Хабраэффект? Интересно что именно проседает.
Нет, к сожалению привет ребятам из infobox. VPS спокойно выдерживает до 2к одновременных посещений (на 1 из ведомых мной ресурсов).
Я думаю, что за год работы вы и так приобрели бесценный опыт. Но я бы посоветовал вам поучаствовать в известных open-source проектах. Так вы увидите как люди пишут код, какие приняты конвенции в том или ином языке. Думаю на Гитхабе полно таких проектов, написанных на PHP. Кроме того вы научитесь писать тесты, т.к. в вашем проекте я тестов не увидел.
Компоненты, модули, блоки, хуки, расширения, виджеты, плагины, аддоны — каждый писатель CMS должен обязательно назвать все имеющиеся у него сущности любым из слов из этого набора. Иначе какая же это CMS. При том, у каждого все эти термины имеют свой смысл.
Очень много неудобств у вас в CMS. Почему, например, ни один checkbox не обернут в label? Приходится целиться мышкой в квадратик. Почему главное меню всегда сворачивается обратно, всегда приходится два раза тыкать. Почему система пишет жирным шрифтом, что менять url очень плохо? Как я понял, нет механизма работы с неизменными id, типа того что в modx есть. Ну да, компонента меню ведь тоже нет. Оно у вас в дефолтном шаблоне захардкожено.
Короче, успехов в дальнейшем допиливании. Сейчас ее нельзя назвать дружественной конечному пользователю.
Спасибо за конструктив, все по факту, постараюсь исправить.
Так же добавлю что использовать радиобаттон для вкл/выкл куда удобрее чем селект, все таки один клик. И подключение к базе данных может лучше перенести в файл? Не даром же так делают популярные CMS
Да, насчет «переключателя» конфигураций «да/нет» я уже задумывался, возможно будет внедрено. Подключение к базе данных итак находиться в файле, как и все стандартные настройки, просто конфигурация выведена в панельку.
Добавьте в свою IDE и описание проекта какой-то формат кодирования кода (PSR-0) и привидите весь код в 1 формат. Там будет проще и вам и участникам проекта.
UFO just landed and posted this here
Позвольте с вами не согласиться — он был сделан уж далеко не первым.
Пара замечаний автору на будущее:

1. Лучше всего ориентироваться на версию PHP 5.2.x. Не все хостинги перешли ещё на 5.3 и тем паче на то, что выше (и, боюсь, не скоро перейдут; типичный тому пример — один из лучших российских хостингов под название SpaceWeb). Ваш код, слава богам, если будет работать хотя бы с версией 5.3.

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

3. Не пытайтесь впихнуть всё в один класс. В своё время разработчики MODx Evolution сделали по сути один базовый класс в движке (documentParser, ЕМНИП) и засунули почти весь функционал туда. В результате код этого класса при всей читабельности сложен даже для простого рефакторинга. Очень хорошо распределять задачи по компонентам. Скажем, есть корневой компонент, в котором дочерними являются DB API, шаблонизатор и мейлер. Это позволяет в дальнейшем комбинировать разные компоненты друг с другом, а — самое главное — модифицировать тот или иной функционал, не затрагивая прочий код.

4. Старайтесь использовать нотацию phpDoc. Это позволит работать с Вашим проектом другим разработчикам и существенно повысит читабельность кода.

Ну и, если что, пишите в ЛС, попробую помочь советом, если потребуется =)
Действительно, сделать проект совместимым с 5.2 будет непросто, хоть и возможности пространства имен я использую достаточно косвенно да и поздним статическим связыванием не увлекался, но бывали моменты использования сокращенного тернарного оператора (вроде бы убрал все в итоге) и некоторых новых возможностей фу-ий (к примеру strstr с параметром before_needle). Все сейчас вроде бы так или иначе стремятся к новым версиям php, тем более в более новых появилась базовая поддержка ряда практичных возможностей(сокращенные представления массивов, трейты, обработчики try-catch-finaly, поддержка opcache из коробки и т.д.).
С остальным — согласен с вами, благодарю за фидбэк.
> Все сейчас вроде бы так или иначе стремятся к новым версиям php

Версия 5.2.x — ИМХО, «золотая» версия PHP. Всё, что выше — это уже немного излишне. Вот сейчас, например, реализуют в PHP тот же принцип, что и в JavaScript — почти всё является объектом — и будет разработчикам «шасье». Сдаётся мне, что производительность резко упадёт. По той же причине я, например, не использую (о, ужас! щаз запинают на раз) PDO, ибо код не только сильно теряет в лаконичности, но и заметно в производительности. Да, PDO — это, конечно, универсально. Только мне всё ж милее старый проверенный годами зоопарк мартышек — mysql, pg, mssql, msql, etc. В своё время я даже исхитрился написать под них универсальный провайдер, в котором тип БД определялся лишь одним строковым параметром инициализации, а методы класса всегда были одними и теми же, даже маппинг типов был для совместимости.

Я сам в своё время писал CMS от мала до велика. В итоге на долгое время пришёл к использованию MODx Evo. Какое-то время даже занимался рефакторингом этой системы (планирую вернуться таки к этой затее). Только когда столкнулся с высоконагруженными проектами, вернулся к старым практикам. Ныне я стараюсь сочетать самые лаконичные методики с процедурным программированием в SQL, чего и Вам советую. Сие сочетание даёт потрясающие результаты.
сделать проект совместимым с 5.2

Зачем? Сейчас минимально-поддерживаемая версия PHP — 5,4. Какой смысл отказываться от тех плюшек, которые дают разработчику новые версии PHP? Забудьте о 5,2 и начинайте забывать о 5,3.

Я не вижу вообще никакой проблемы в том что бы проект был хоть на 5,6. Хостинг под 5,6 найти не проблема, да и VPS стоят копейки нынче. Так же разработчик этой самое CMS сможет в будущем сделать платную поддержку возможно (мечты конечно но все же) и сделать свою CMS облачной и за счет этого жить и развивать продукт.
> Хостинг под 5,6 найти не проблема

В России? Ню-ню. Милейший, а где взаимосвязь между возможностью сделать CMS облачной и версией PHP?
Извините, а что собственно понимается под «облачной CMS» — разделение модели взаимодействия на front и back энд-ы?
Грубо говоря, основная масса файлов движка берётся из некоего репозитория (облака), а под каждый проект выделяется некий набор таблиц в БД, который, собственно, и отделяет проекты друг от друга. Ну, вот так как-то.
Я имел в виду Software as a service, по сути лизинг програмного обеспечения. Разворачивается все на серверах разработчика продукта, клиенту ничего для этого делать не нужно. Аля «специализированный хостинг». Пример — wordpress — вы можете установить себе, а можете просто зарегистрировать аккаунт.
Версия PHP — чем выше, тем удобнее разработчику. Облачность — всем управляет разработчик. Клиенты просто регают акаунты, им создается инстанс, они привязывают домен и радуются. Не нужно ни за обновления волноваться, ни за настройки сервера и т.д.

по поводу 5,6 я всего лишь сказал что хостинги есть.

nic.ru — php5.3
hostland.ru — php5.3
hts.ru — php5.4
timeweb.com — php5.5
jino.ru — php5.5
sprinthost.ru — php5.5

Так что про php5.2 можно уже забыть.
Разработчику-то удобнее, вот только производительность PHP и, соответственно, систем на его основе падает… Хотя что я тут распинаюсь? Ведь вычислительные мощности растут, аки на дрожжах. Чего мелочиться-то, правда? Есть, правда, ещё один момент, чем удобнее разработчику, тем больше становится процент дилетантов среди разработчиков. Освоили очередной фреймворк для создания веб-приложения в десять строчек и погнали штамповать десятками шаблонные поделки. А где созидательность? *махнул рукой* А, ладно, анекдот в тему оставлю:

— Контрабас, сыграйте «до»
* бряк! *
— Контрабас, сыграйте «ре»
* бряк! *
— А, ладно, играйте, что хотите!
вот только производительность PHP и, соответственно, систем на его основе падает…

Вы возможно удивитесь, но PHP5,5+opcache порядочно так быстрее php5.2+apc. То есть если вы просто обновите версию PHP не меняя кодобазу производительность улучшится.

Если вы про все этим модные пространства имен, composer, dependency injection-ы и другие модные штуки, кеширование спасет мир. Большинство готовых решений и так достаточно эффективны и поддерживают кеширование. Тот же composer позволяет нам выполнить команду
composer dump-audoload --optimized

и при наличии opcache-ов вы получите такую производительность, которую вам не даст ни один вася пупкин на php5.2. И при этом система все еще будет поддерживаемой и внесение изменений будет не такой болью. Так же можно децентролизовать проект.

А что я говорю… Мне кажется мы просто в разных мирах сидим… Мне кажется что если инструмент и замедляет производительность на каких 10%-20% но повышает продуктивность разработчика на 40%-50% то оно того стоит (если мы не говорим о проектах где эти 10%-20% это +200 серверов в датацентрах) Но посколько подобные проекты аля коробочных CMS никогда не выйдут на такие масштабы, то лучше уж так. И опять же проблемы производительности частенько решаются архитекрурно и в таких вот CMS-ках узкое место зачастую неэффективное использование баз данных.
Вообще, вопрос о «уровне оптимизации» и «удобстве разработки» извечен. Соглашусь, что при условии неизменности самого кода(и при отсутствии depricated методов в коде в том числе) при моем «беглом» тестировании php 5.5 с opcache показал лучший результат чем php 5.3 с установленным apc или eaccelerator. Притом внедрение opcache в 5.5 версии предоставляется по существу из «коробки» без необходимости сборки их исходных кодов или скачивания готовых библиотек с удаленных репозиториев/хранилищ.
(тут начинаем пинать) я около 12 лет назад поставил одну бесплатную CMS (платные тоже пробовал, но не понравилось, исходники закрыты поправить нет возможности), так вот когда я на их форуме попросил исправить очень серьезные баг которые очень сильно всем мешал, мне толпа активистов «заминусовало», и сказали если не нравиться пиши свою CMS. Я как инициативный бородатый программер взял и написал за пару месяцев. Модульная, MVC модель, хуки, кучу примочек, визуальны генератор дизайна. И вот уже 12 лет она работает на нескольких сотнях моих сайтов, я ее изредко поправляю, она без Аякса. Работает корректно на всех браузерах. И когда я вижу все текущие CMS я понимаю что лучше они не стали. Моя CMS в базовой установке занимает 1 мегабайт, работает со скоростью света, визуальный редактор и все такое стоит.
И еще раз я прихожу к выводу — ХОТИТЕ чтобы ВСЕ работало хорошо — делайте САМИ.

PS: недавно проводил тест сайтов в инете(около 1 000 000 тестил), так вот каждый 1000 сайт на стандартной(коробочной) CMS взламывается без особого труда.
Это хорошо, что ваша система работает столько лет без проблем и изъянов в безопасности приложения. Я буду благодарен вам, если вы найдете и предоставите мне изъяны в безопасности выше опубликованной системы.
Я не вижу в Вашей скрытой рекламе чем Ваша система лучше все тех что существуют, ни объективных графиков нагрузки, ни каких то особоых фишечек преимуществ, такой же «смартфон» как и у всех что тут рекламируют. Показали бы 10-20 принскринов реально работающих сайтов.

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

ЗЫ: Могу отвечать только раз в час, а то меня рекламщики минусуют за честные комментарии, Господи во что хабр превратился.
(и тут начинаем минусовать)
Если по делу — никакой здесь скрытой рекламы нет, ведь пост написан в блог компании, что не нарушает правил хабра. Да, это не разговор о каких-либо высоких достижениях или принципиально новой технологии.
Интересует стабильность работы под нагрузками в сравнении с другими системами? Замечательно, я постараюсь сделать следующий пост в блоге именно об этом — проведу сравнительное ab-тестирование с популярными, по моему мнению CMS.
З.ы. — именно вы выше, по моему мнению занимались скрытой рекламой, расхваливая свою систему — но это ваше право.
Я свою систему не распространяю, поэтому это не реклама.
Не нарушаете, Харб специально сделал раздел Блог компаний, извените, не скрытая реклама, а просто реклама.

Вы показали рекламу(это даже не статья), пользователи написали комменты кто то плохие, кто то ничего не написал.
Да, это не разговор о каких-либо высоких достижениях или принципиально новой технологии. — вот я и пишу, что это очередной велосипед.
Интересует стабильность работы под нагрузками в сравнении с другими системами? — да, хочу понять чем то что вы целой компанией сделали, лучше чем у остальных.
хочу понять чем то что вы целой компанией сделали, лучше чем у остальных.

Это работа всего лишь 1го человека, я выше об этом не раз писал, притом человека, связанного с программированием по средствам самообучения. Постараюсь удовлетворить ваше требование и напишу статью о преимуществах (или недостатках) в зависимости от нагрузок.
(тут начинаем пинать) я около 12 лет назад поставил одну бесплатную CMS (платные тоже пробовал, но не понравилось, исходники закрыты поправить нет возможности), так вот когда я на их форуме попросил исправить очень серьезные баг которые очень сильно всем мешал, мне толпа активистов «заминусовало», и сказали если не нравиться пиши свою CMS.

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

Модульная, MVC модель, хуки

Ой да каждый писал свою CMS, модульную, с MVC, возможно даже с SOA и т.д. А толку то? Если вы ее не распространяете нигде, смысл кричат об этом? 99% что там внутри такой трешачек что wordpress будет еще норм.

так вот каждый 1000 сайт на стандартной(коробочной) CMS взламывается без особого труда.

Ого, всего-то 0,01%? Неплохо для коробочных CMS. На самом деле статистика будет куда плачевнее и тут ничего не сделать.

Очередная CMS это и не плохо и не хорошо. Это никак. Вообще никак. Если ваше решение работает для вас, то это не значит что оно будет работать для кого-то еще. Еще и специфика проектов может отличаться. Меня вот больше печалит что за последние лет 10 не особо чего поменялось в концепции CMS. Да, сейчас начали появляться проекты с inline-редактированием, блочными моделями сборки страниц и т.д. Но можно же и более интересные/концептуальные подходы понапридумывать, с компиляцией и сборкой. оптимизациями запросов в базу, генерация CMS на основе шаблона… что-то меня понесло…
«Ой да каждый писал свою CMS, модульную, с MVC, возможно даже с SOA и т.д. А толку то? Если вы ее не распространяете нигде, смысл кричат об этом? 99% что там внутри такой трешачек что wordpress будет еще норм.»
Согласен, но я писал для себя, для своих проектов и эти проекты успешно работают 12 лет, и это не задумка а трешь коде а нормальный релизный проект — вот в чем разница от 98% тех кто писал свою CMS

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

Вот об это я и говорю. Я зашел на эту страницу, думая что кто то, что то сделал оригинальное, стоящего внимания, НОВОЕ.

Ps: BB коды не работаю для комментов — что за…
Последнее врем Харб превращается в рекламу(как ни назовите, но именно рекламу) «смартфонов» из статей Блогов компаний.
Реализация отвратна. И да, ничего интересного. Просто куски админки вызываются с фронтэнда в попапчике. Лучше уж redkite какой. В прочем у меня свои требования для CMS. И да, у меня не так много проектов такого плана.
Firefox: wysibb не работает кнопка «Выберите файл для загрузки»
Потестировал на локалке — все хорошо (возможно вы пытались это проделать на демо-сайте, там отключена загрузка файлов из-за понятных соображений).
Логично. Кстати на хабре была статья насчет того, что давать заливать файлы пользователям на сервер не безопасно, причем не по «вине» cms, а по вине хостера и его настроек сервера
Я почти прошел мимо, но увидел в качестве преимуществ этой цмс её скорость работы, среди прочих тестируемых были и ВП и инстант и ливстрит и др. Так вот, конечно с учетом возможностей вашей цмс её не очень-то можно сравнивать с теми цмс, что в вашем списке — у них более серьезные возможности, другая архитектура.

Также как я понял ни о какой динамичности для не зарегистрированного пользователя в течении 2-х минут (по-умолчанию) говорить не приходится — им отдается что-то вроде готового хтмл.

Это напоминает какой-то плохой маркетинг — выделить какие-то преимущества на полном утаивании недостатков или отсутствия чего-либо ещё.

Хотя я понимаю что «как-то же выделять свое творение надо».

Код не смотрел (только первые два экрана какого-то файла), мало комментариев.

P.S. либо писать не «Основные преимущества системы», а «основные возможности».
Кеширование из коробки это несомненно плюс. Мне вот пришлось перед wordpress Varnish поставить когда в последний раз с ним сталкивался, что бы все работало быстро. Сейчас же я предпочел бы сделать тот проект на каком piecrust или sculpin (если говорить про нынешние дни).

И что плохого в маркетинге и рекламе своего продукта? Если его не рекламировать, он умрет в безвестности. А так, чем больше людей услышит о продукте, тем больше потенциальных пользователей а так же идей по улучшению продукта.
А я не где и не говорил в материале о преимуществах системы, в данном посте я больше говорил об ее устройстве и потенциальных возможностях, нежели сравнивал ее с популярными системами.
Если речь идет об описании на сайте — то там я старался изложить все по делу и я бы не сказал что функционал системы(из «коробки») существенно ниже, чем у wordpress или dle (у livestreet иная направленность — мульти-блоги).
А о динамичности вы зря заговорили, не посмотрев саму систему и не потестировав ее. Вся соль в том, что «статичным» становиться скомпилированный код шаблона (спасибо за это twig) а все остальное — нет (динамические включения модулей или компонентов в тело страницы).
Как совет: сейчас бурно развивается oн-лайн торговля, разного рода cms очень много, поэтому лучше (имхо) сделать платформу для интернет-магазинов, на базе вашей cms
Дело в том, что реализовать функционал магазина в системе можно без единой строки изменения в ее коде — сам магазин реализовать компонентом, вывод на главную(к примеру) или в блоки шаблона — модулем(callback-ами в готовые методы компонента), корзину — модулем(если нужно взаимодействие с api доставщиков — хук и вызов его методов модулем).
В ближайшее время после правки ряда выше заявленных недоработок(возможно, до внедрения стандарта PSR-1) я постараюсь реализовать данный механизм и опубликовать его в каталоге системы.
Это очень хорошо, что вы позаботились об архитектуре ПО на начальном этапе, а не погнались за «рюшечками»
Наверное, хорошая система, но мой совет автору делать кроме презентаций видео Full HD, с рассказом (обычный захват с экрана). Раз уж версия коробочная. Видео-лекцию все же больше народу посмотрит, а так Вы намельчили там что-то в презентации.

Если соберетесь донести до систему до простых пользователей, сделайте версию без терминологии.
Sign up to leave a comment.