Комментарии 35
Обратите внимание на:
Проекту явно не хватает автозагрузки с единым стандартом для Namespace\\Class, развертывания из композера и слежение за версиями им же и много чего прочего, что можно изучить по ссылкам выше.
Проекту явно не хватает автозагрузки с единым стандартом для Namespace\\Class, развертывания из композера и слежение за версиями им же и много чего прочего, что можно изучить по ссылкам выше.
Composer полноценно поддерживается, у самого движка немного другой (более простой и специфический) механизм автозагрузки.
Если кратко — все \ меняете на /, префикс \cs\modules соответствует директории components/modules, с плагинами аналогично.
Просто Composer не обязателен для установки и работы системы, но опционально можете использовать, автозагрузчик классов из vendor будет подхвачен автоматически.
Если кратко — все \ меняете на /, префикс \cs\modules соответствует директории components/modules, с плагинами аналогично.
Просто Composer не обязателен для установки и работы системы, но опционально можете использовать, автозагрузчик классов из vendor будет подхвачен автоматически.
На счёт двух других ссылок — знаем, в курсе, сознательно некоторые из советов не применяю. Как результат — движок, рендерящий страницу с запросом в БД работает существенно быстрее фреймворка, который никаких запросов не делает и рендерит примитивнейшую фиксированную страницу. В реальных условиях разброс будет ещё больше.
Отдельно стоит упомянуть размер стека вызовов при ошибке — в CleverStyle CMS он будет существенно меньше чем у Symfony, более осмысленный и простой для понимания, всё это результат осознанного выбора при принятии архитектурных решений.
Отдельно стоит упомянуть размер стека вызовов при ошибке — в CleverStyle CMS он будет существенно меньше чем у Symfony, более осмысленный и простой для понимания, всё это результат осознанного выбора при принятии архитектурных решений.
То есть, вы сознательно игнорируете стандарты стиля и качества написания кода и это по вашему дает вашему проекту больший performance?
Я скажу вам больше, процедурный код, реализующий те-же функциональные особенности забитый в 1 файл будет делать это еще быстрей, однако вы же не пошли по этому пути. Вы стараетесь, хотя-бы отчасти, сделать ваш проект доступным для работы и доработки другими людьми, расширяемым, однако это едва-ли возможно если вы не следуете общепринятым принципам (т.к. вследствие этого другому человеку нужно будет потратить время на изучение именно вашего стиля расширения).
А будет ли он таким же гибким и понятным как в symfony?
П.с. — все проблемы, связанные с расходом ресурсов и временем генерации страниц уже давно решаются при помощи nginx/php-fpm+opcache и прочих шалостей, даже для таких монстров как bitrix(господь упаси).
Как результат — движок, рендерящий страницу с запросом в БД работает существенно быстрее фреймворка, который никаких запросов не делает и рендерит примитивнейшую фиксированную страницу. В реальных условиях разброс будет ещё больше.
Я скажу вам больше, процедурный код, реализующий те-же функциональные особенности забитый в 1 файл будет делать это еще быстрей, однако вы же не пошли по этому пути. Вы стараетесь, хотя-бы отчасти, сделать ваш проект доступным для работы и доработки другими людьми, расширяемым, однако это едва-ли возможно если вы не следуете общепринятым принципам (т.к. вследствие этого другому человеку нужно будет потратить время на изучение именно вашего стиля расширения).
Отдельно стоит упомянуть размер стека вызовов при ошибке — в CleverStyle CMS он будет существенно меньше чем у Symfony, более осмысленный и простой для понимания, всё это результат осознанного выбора при принятии архитектурных решений.
А будет ли он таким же гибким и понятным как в symfony?
П.с. — все проблемы, связанные с расходом ресурсов и временем генерации страниц уже давно решаются при помощи nginx/php-fpm+opcache и прочих шалостей, даже для таких монстров как bitrix(господь упаси).
То есть, вы сознательно игнорируете стандарты стиля и качества написания кода и это по вашему дает вашему проекту больший performance?
Я скажу вам больше, процедурный код, реализующий те-же функциональные особенности забитый в 1 файл будет делать это еще быстрей, однако вы же не пошли по этому пути.
Будет быстрее, это факт. Поэтому приходится искать золотую средину. Symfony исповедует более академический стиль программирования, напрочь забывая что в PHP нет zero cost abstractions, то есть каждая прослойка это потеря производительности, порой существенная. Так почему бы не выстроить архитектуру, которая и расширяемая, и абстракций имеет только необходимый минимум?
Вы стараетесь, хотя-бы отчасти, сделать ваш проект доступным для работы и доработки другими людьми, расширяемым, однако это едва-ли возможно если вы не следуете общепринятым принципам (т.к. вследствие этого другому человеку нужно будет потратить время на изучение именно вашего стиля расширения).
Конечно стараюсь. Но теперь давайте по сути, а не абстрактно и в вакуме. Возьмем достаточно большой файл, что в стиле кодирования такого, что делает код едва ли доступным и расширяемым? Буду очень благодарен комментариям по существу, а не «не такой как все — вон из профессии».
А будет ли он таким же гибким и понятным как в symfony?
Вы пробовали, к примеру отлаживать Composer, который использует немало компонентов Symfony? Я пробовал, блуждание по пустым прокси-вызовам убивает желание вникать в проект напрочь. Как раз из-за меньшего количества «пустых» вызовов стек меньше и гораздо понятнее.
П.с. — все проблемы, связанные с расходом ресурсов и временем генерации страниц уже давно решаются при помощи nginx/php-fpm+opcache и прочих шалостей, даже для таких монстров как bitrix(господь упаси).
К вашему сведению opcache включен начиная с PHP 5.5 по-умолчанию, тесты с PHP-FPM показывают аналогичный результат. Ещё объективные возражения по поводу условий тестирования?
Будет быстрее, это факт
Я так понимаю за счёт меньшего стека вызова, я прав?
Но как влияет хоть один из PSR на величину стека вызова?
Не только и не столько из-за количества вызовов, как из-за количества объектов, которые создаются в процессе. Возьмите любой пример и сравните — в большинстве случаев будет меньше вызовов и меньше сущностей.
PSR никак не влияют на величину стека вызовов напрямую)
PSR никак не влияют на величину стека вызовов напрямую)
так всё же почему Вы выбрали такой стиль кодирования?
когда речь идёт о закрытых проектах — да, там может быть всё, что угодно, как принято в команде.
Но всё же Ваш проект в опен сорсе, его видят большое количество, которые привыкли к определённым стандартам в опен сорс проектах, привыкли контрибьютить по этим стандартам.
Это ведь сильно снижает читаемость кода, или нет?
когда речь идёт о закрытых проектах — да, там может быть всё, что угодно, как принято в команде.
Но всё же Ваш проект в опен сорсе, его видят большое количество, которые привыкли к определённым стандартам в опен сорс проектах, привыкли контрибьютить по этим стандартам.
Это ведь сильно снижает читаемость кода, или нет?
Стандарты кодирования, нужны что бы легко писать код, и не задумываться о стиле.
Поясню, у вас все названия переменных через _, методов тоже, и вероятно ещё куча мелочей. И есть стандарт, которому все популярные библиотеки следуют, и большинство проектов в целом так же приходят к нему, все го знают. Я как рядовой разработчик тоже его знаю, и привык писать именно так, т.е. без задней мысли буду называть метод так: «someMethod», в IDE так же есть правила автоформата для стандарта, и эти часто пользуются люди, что бы не пропускать мелочи в стиле кодирования.
И теперь когда я, захочу помочь в развитии вашего проекта, мне нужно будет переучиваться, перенастраивать окружение, переучиваться писать всё по стандарту. Это пустая трата времени, это ведь не несёт в себе ценности для меня, не даёт новых знаний, новых навыков. И многие тупо не будут помогать проекту если им нужно будет таким заниматься. И пойдут люди помогать другим проектам.
Вот в кратце суть стандартов кодирования, зачем они и чем полезны.
Поясню, у вас все названия переменных через _, методов тоже, и вероятно ещё куча мелочей. И есть стандарт, которому все популярные библиотеки следуют, и большинство проектов в целом так же приходят к нему, все го знают. Я как рядовой разработчик тоже его знаю, и привык писать именно так, т.е. без задней мысли буду называть метод так: «someMethod», в IDE так же есть правила автоформата для стандарта, и эти часто пользуются люди, что бы не пропускать мелочи в стиле кодирования.
И теперь когда я, захочу помочь в развитии вашего проекта, мне нужно будет переучиваться, перенастраивать окружение, переучиваться писать всё по стандарту. Это пустая трата времени, это ведь не несёт в себе ценности для меня, не даёт новых знаний, новых навыков. И многие тупо не будут помогать проекту если им нужно будет таким заниматься. И пойдут люди помогать другим проектам.
Вот в кратце суть стандартов кодирования, зачем они и чем полезны.
Если вас остановит написание some_method вместо someMethod — то это, конечно, очень печально. У меня правило на этот счёт простое — в любом стороннем проекте где я принимаю участие (а, как видно по моему GitHub профилю, таких много), я всегда без дополнительных вопросов принимаю локальный стиль кодирования и подходы, какими бы они не были.
К вашему сведению opcache включен начиная с PHP 5.5 по-умолчанию, тесты с PHP-FPM показывают аналогичный результат. Ещё объективные возражения по поводу условий тестирования?
Насколько я помню, начиная с версии php 5.5 входит в состав сборки бинарника php, однако он НЕ включен по умолчанию:
;opcache.enable=0
Конечно стараюсь. Но теперь давайте по сути, а не абстрактно и в вакуме. Возьмем достаточно большой файл, что в стиле кодирования такого, что делает код едва ли доступным и расширяемым? Буду очень благодарен комментариям по существу, а не «не такой как все — вон из профессии».
Во 1х вы наступили на те же грабли, на которые я наступил полтора года назад — у вас очень много (а возможно и все) классов наследуют паттерн singleton, который сам по себе является «мертвым» как для расширения так и для тестирования. Очень многие модели реализации в вашей CMS куда лучше будут выглядеть и работать в виде тех же factory, DI — ведь именно в умении выбрать правильный паттерн для конкретной реализации и заключается одна из составляющих работы программиста.
Вы пробовали, к примеру отлаживать Composer, который использует немало компонентов Symfony? Я пробовал, блуждание по пустым прокси-вызовам убивает желание вникать в проект напрочь. Как раз из-за меньшего количества «пустых» вызовов стек меньше и гораздо понятнее.
Верно, но это лишь их огрех из-за больших прослоек прокси или абстракций, уже не помню где, но есть рекомендации по количеству «прослоек» от крайней к основной модели реализации.
Насколько я помню, начиная с версии php 5.5 входит в состав сборки бинарника php, однако он НЕ включен по умолчанию
Вот уж не знаю что сказать, по-моему используется всё-таки (в php.ini такой же комментарий как у вас).
Во 1х вы наступили на те же грабли, на которые я наступил полтора года назад — у вас очень много (а возможно и все) классов наследуют паттерн singleton, который сам по себе является «мертвым» как для расширения так и для тестирования.
Это не до конца верно. Во-первый название отражает способ использования, но не то, как он устроен внутри (внутри оно ближе к Factory). На самом деле компоненты могут расширять и модифицировать базовые системные классы, при чём даже делать множественное наследование, подробнее в соответствующем разделе документации. Но в целом да, это немного менее гибко чем DI, зато проще в использовании.
Недавно система перестала заводить сессию на каждого посетителя без надобности, добавил обновленный тестовый результат, получился двухкратный рост по сравнению с более старой версией системы: с 1279.86 rps до 2678.93 rps, тут Symfony уже никак конкурировать не может со своими 1206.22 rps.
На HHVM получилось 2878.00 rps:
Увеличение конкурентности приводит к росту скорости но по окончанию теста что-то упирается и сильно конкурентность поднять не получается — сразу падает, то ли конфигурация сетевого стека то ли Nginx. В любом случае производительность очень ОК я считаю.
При этом я не вдаюсь в крайности вроде процедурного кода в одном файле — запускается полноценный фреймворк.
На HHVM получилось 2878.00 rps:
HHVM
nazar-pc@nazar-pc ~> ab -c256 -n10000 test.com:8000/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net
Licensed to The Apache Software Foundation, www.apache.org
Benchmarking test.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx/1.9.10
Server Hostname: test.com
Server Port: 8000
Document Path: /
Document Length: 2195 bytes
Concurrency Level: 256
Time taken for tests: 3.475 seconds
Complete requests: 10000
Failed requests: 808
(Connect: 0, Receive: 0, Length: 808, Exceptions: 0)
Total transferred: 24578997 bytes
HTML transferred: 21948997 bytes
Requests per second: 2878.00 [#/sec] (mean)
Time per request: 88.951 [ms] (mean)
Time per request: 0.347 [ms] (mean, across all concurrent requests)
Transfer rate: 6908.05 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.7 0 5
Processing: 17 88 13.5 86 187
Waiting: 17 87 13.5 86 187
Total: 21 88 13.3 86 187
Percentage of the requests served within a certain time (ms)
50% 86
66% 91
75% 95
80% 97
90% 105
95% 110
98% 118
99% 121
100% 187 (longest request)
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net
Licensed to The Apache Software Foundation, www.apache.org
Benchmarking test.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx/1.9.10
Server Hostname: test.com
Server Port: 8000
Document Path: /
Document Length: 2195 bytes
Concurrency Level: 256
Time taken for tests: 3.475 seconds
Complete requests: 10000
Failed requests: 808
(Connect: 0, Receive: 0, Length: 808, Exceptions: 0)
Total transferred: 24578997 bytes
HTML transferred: 21948997 bytes
Requests per second: 2878.00 [#/sec] (mean)
Time per request: 88.951 [ms] (mean)
Time per request: 0.347 [ms] (mean, across all concurrent requests)
Transfer rate: 6908.05 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.7 0 5
Processing: 17 88 13.5 86 187
Waiting: 17 87 13.5 86 187
Total: 21 88 13.3 86 187
Percentage of the requests served within a certain time (ms)
50% 86
66% 91
75% 95
80% 97
90% 105
95% 110
98% 118
99% 121
100% 187 (longest request)
Увеличение конкурентности приводит к росту скорости но по окончанию теста что-то упирается и сильно конкурентность поднять не получается — сразу падает, то ли конфигурация сетевого стека то ли Nginx. В любом случае производительность очень ОК я считаю.
При этом я не вдаюсь в крайности вроде процедурного кода в одном файле — запускается полноценный фреймворк.
Вот из-за такого хода дискуссий приходится уходить в англоязычный сектор опенсорса. Без обид.
nazarpc инфраструктурно развивает сообщество (CMS, polymer, для Php Inspections (EA Extended) были баг-репорты) и критиковать решения не стоит.
Не нравится решения автолоадинга, докера, архитектуры — делайте пулл реквесты, или создавайте тикеты.
nazarpc инфраструктурно развивает сообщество (CMS, polymer, для Php Inspections (EA Extended) были баг-репорты) и критиковать решения не стоит.
Не нравится решения автолоадинга, докера, архитектуры — делайте пулл реквесты, или создавайте тикеты.
А что означает Failed requests: 8468 в тесте CleverStyle CMS?
Failed requests: 8468
(Connect: 0, Receive: 0, Length: 8468, Exceptions: 0)
Это значит что у ответов отличается тело запроса по длинне. Поскольку в теле страницы указывается потребляемая оперативная память и время рендеринга страницы то тело ответа на несколько байт может отличаться, сами же запросы прошли без ошибок.
Не знал про Scrutinizer, спасибо за наводку. Проверил несколько своих решений, 10/10 ) Где мой пирожок?
Хорошая штука, там даже автопатчи есть на code-style и мелкие баги :)
П.с. — покажите проект с 10/10 ( я до 8ки вылизывал достаточно долго).
П.с. — покажите проект с 10/10 ( я до 8ки вылизывал достаточно долго).
чет он мне дает 9.69 бала, но не показывает проблемный код. Странно.
scrutinizer-ci.com/g/Bashka/bricks_frameworks_base
дал 8.6 балла за то, что не смог найти в проекте объявленный выше класс ))) крутая штука, вне всяких сомнений
дал 8.6 балла за то, что не смог найти в проекте объявленный выше класс ))) крутая штука, вне всяких сомнений
Ну… для 3 классов с парой методов это просто. А вот вам пример yii2, код которой далеко не самый плохой: scrutinizer-ci.com/g/yiisoft/yii2
del
Dockerfile странный, во-первых, описывает установку MariaDB и nginx, во-вторых, нет привязки к версии, билдится только мастер, в-третьих, все это лежит в коде проекта. По этим причинам не рекомендуется использовать в продакшене или сам проект для этого не пригоден?
Только поэтому, Dockerfile ориентирован только на одну цель — запустить работоспособную git версию системы чтобы пощупать что оно такое. Там кроме указанных вами вещей есть ещё некоторые недочёты из-за которых в продакшн этот контейнер совать нельзя.
Тем не менее у меня есть другая разработка: github.com/nazar-pc/docker-webserver
Вот с её помощью успешно работает несколько сайтов как на базе CleverStyle CMS, так и, например, ownCloud и один проект на Yii 1.
По идее нужно сделать специальный production-ready образ, и даже есть issue по этому поводу, просто руки не доходят чтобы сделать толково.
Тем не менее у меня есть другая разработка: github.com/nazar-pc/docker-webserver
Вот с её помощью успешно работает несколько сайтов как на базе CleverStyle CMS, так и, например, ownCloud и один проект на Yii 1.
По идее нужно сделать специальный production-ready образ, и даже есть issue по этому поводу, просто руки не доходят чтобы сделать толково.
Complete requests: 10000
Failed requests: 8468
мне кажется или тут что-то не так?
Кажется, уже спрашивали выше: habrahabr.ru/post/275139/#comment_8740645
извините, еще не проснулся )
хотел спросить, много ли изменилось с моего комментария ко второй части публикации
хотел спросить, много ли изменилось с моего комментария ко второй части публикации
Да:
— все найденные вами недочеты и многие другие были исправлены
— UI в целом стал более дружелюбным, но есть ещё идеи над улучшением сообщений о недостающих зависимостях компонентов или конфликтах в админке и некоторые другие
— тему оформления создавать стало гораздо проще (по сути скачиваете любой шаблон, убеждаетесь что CSS/JS/HTML от веб-компонентов в папках css/js/html, удаляете явное подключение этих файлов из шаблона и вставляете подстановочные фразы вроде
— поскольку практически всё ядро подверглось рефакторингу — читать и понимать код теперь проще и стиль гораздо более однородный, с но с компонентами ещё много работы
— поработал над документацией, особенно по фронтенду — больше информации и примеров
Если соизволите посмотреть на прогресс и оставить комментарий — буду премного благодарен, вы тогда очень помогли.
— все найденные вами недочеты и многие другие были исправлены
— UI в целом стал более дружелюбным, но есть ещё идеи над улучшением сообщений о недостающих зависимостях компонентов или конфликтах в админке и некоторые другие
— тему оформления создавать стало гораздо проще (по сути скачиваете любой шаблон, убеждаетесь что CSS/JS/HTML от веб-компонентов в папках css/js/html, удаляете явное подключение этих файлов из шаблона и вставляете подстановочные фразы вроде
<!--head--> и <!--content--> чтобы движок знал куда контент вставлять; больше ничего не нужно менять, благодаря выпиленному UIkit конфликтов стилей не будет, раньше всё было немного сложнее)— поскольку практически всё ядро подверглось рефакторингу — читать и понимать код теперь проще и стиль гораздо более однородный, с но с компонентами ещё много работы
— поработал над документацией, особенно по фронтенду — больше информации и примеров
Если соизволите посмотреть на прогресс и оставить комментарий — буду премного благодарен, вы тогда очень помогли.
Может быть уже говорили, но меня как-то смущают такие вещи в коде.
namespace cs;
use
h;
Выравнивание такое потому что в случае нескольких классов они все подключаются одним
По сравнению с рекомендуемым PSR одним классом на
use:namespace cs\modules\HybridAuth;
use
Exception,
h,
Hybrid_Endpoint,
cs\Config,
cs\Event,
cs\ExitException,
cs\Key,
cs\Language,
cs\Mail,
cs\Page,
cs\Route,
cs\Session,
cs\User;
По сравнению с рекомендуемым PSR одним классом на
use гораздо меньше визуального шума.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cобрать лучшее из двух миров — фреймворков и CMS (часть 3)