если перед коммитом тест сломался — да, нужно поправить
Как мне кажется, в большинстве случаев тест будет написан так, что не сможет выявить закравшийся баг, то есть критические точки изначально не будут учтены ни в коде, ни в тесте.
Вы просто еще не научились их писать))
Так как тесты нужны прежде всего как индикатор работоспособности при изменениях, то следует учитывать то, что скорее всего это сломался сам тест, так как он не ложится на измененный код.
Верно, если вы поменяли код — то сломанные тесты сами себя не поправят.
Я стараюсь писать качественный код. Выше качество кода — нужно меньше тестировать. Это фишка японских автомобилей.
Качество автомобилей можно определить только за счет их тестирования до введения в производство И после N-летней поддержки.
На основе самомнения же аргумент — так себе.
Ни на одной работе их не писали, поэтому я не привит к красивому.
Круть, наконец-то хоть один пункт в точку. Рекомендую сделать это первым пунктом и "привит к красивому" заменить на "умею их писать", в этом случае будет идеально.
Возможно я что-то пропустил, но ссылок на apache.org не вижу
Та плевать. Там что, конфигов нету? :)
Динамических, в стиле htaccess, htpasswd да, нету, только статические.
То что фреймворк защищает от SQL-инъекций (ибо работает через PDO) не означает, что он защичит, если пихнуть plain SQL.
Вы используете что-то в стиле green sql? Если нет — ваше ядро не решает проблему
Кто-то проводит аудит фреймворков самостоятельно?
Экосистема больших фреймворков тем и подкупает, что аудитором (пусть и косвенно) является каждый, кто его использует.
У нас может быть 100500 скриптов, которые динамично меняются.
Собственно и что теперь?
Мапить 100500 скриптов это псевдопрограммирование
Вы так говорите, будто бы маппинг обязательно нужно делать руками.
А как лучше? :)
Зависит от продуктовых требований к проекту. Из основных вариантов решения этой проблемы:
Использовать шаблонизатор, типа twig
Вынести фронтенд в SPA
Реализовать маппер, умеющий в зависимости статики И поиск по файлам. При первом запуске он просканирует, что у вас есть и положит в кэш, Далее при подключении статики — срезолвит зависимости и вернет требуемое (это тоже не плохо бы кэшировать).
Если не использовать __call, то нужно мапить все методы и следить за добавлением новых методов.
Мы просто проверяем, существуют ли нужные скрипты в папке $method.
Так вот, мне было интересно, как он будет его менять, если в родителе этот метод использовал другие private/final методы.
Еще раз: менять нельзя.
Я не спорю, что руки кривые, просто это конфиг по умолчанию. :)
Ну нет такой штуки, как конфиг по умолчанию, не ужели это не ясно? Если вы в проекте дописываете .htaccess — это нихрена не конфиг по умолчанию, это станет вашей личной анальной болью.
В том же nginx+php-fpm в принципе отсутствует поддержка динамической настройки сервера.
Многие фреймворщики думают, что используя фреймворк они за бетонной стеной.
Верно, но смею заметить, что вы со своим 50к ядром точно в такой же ситуации))
В большинстве случаев без __call можно обойтись, дублируя код.
неа)) Есть интерфейсы, наследование, DI,...
call_user_func* тоже сотона мохнатая придумала? :)
Если посмотреть, что callable — это function/string/array[string,string]/array[object,string], да это очень опасная конструкция. Лучше уже тайпхинтинг на \Closure
Наличие скрипта проверяется сначала в папке шаблона (если нужна специфичная версия), потом в шаблоне по умолчанию, потом в папке по умолчанию.
Вы изначально хотите каку сделать)) Под статику достаточно реализовать маппинг и уже на его основании делать сборку. __call тут ну вот ни капли ни при чем.
Мы просто проверяем, существуют ли нужные скрипты в папке $method.
этот подход — днище.
Нам не нужно при добавлении нового скрипта доопределять методы, не нужно их переименовывать при переименовании папок.
Все верно, но и магия тут тоже вот ни капли не нужна)).
асинхронные микросервисы — это по сути те же события
Меняй барыгу, пока не поздно.
Кстати, как будете поступать в случае, если наследуемый метод использовал приватный метод или был final? :)
private — это модификатор, явно указывающий: «тебе это трогать во вне текущего класса не надо».
final — это модификатор, явно указывающий: «тебе нельзя тут ничего менять».
Я за ним особо не слежу, может в плагинах.
слив засчитан
А потом получаем примерно такое https://habrahabr.ru/post/309436/ с единой точкой входа в конфиге по умолчанию :)
Ага, только там проблема кривых рук, а не кода ;)
Это конфиг по умолчанию!
Если сервер настроен криво — это значит, что руки кривые.
Если не использовать __call, то нужно мапить все методы и следить за добавлением новых методов.
Если без __call вот вообще никак — у вас архитектура днище. __callStatic — это еще хуже. Про существование этих методов стоит в принципе забыть.
Интересно, какой оверхед у кеша (допустим мемкеш) doctrine по сравнению с чистым PHP.
Ничтожный)). Что с доктриной, что без, сетевые издержки будут на порядки дольше, чем обвязки.
Вообще, сущность не должна себя куда-то сохранять/извлекать.
Я рад за вас, вы только что придумали Entity-Repository. Во многих случаях он более надежный, чем AR. Правда бывают случаи, когда он слишком избыточный.
silex основан на Симфони.
На компонентах — да, на стеке выполнения — нет.
Звездочка — это типа понравилось / избранное?
Тип того + все ваши фоловеры видят, что какие проекты вы отмечаете.
В статье вы критикуете "фреймворки", при этом доводы базируете только на yii.
Далеко не все фреймворки используют MVC подход, вы же говорите так будто бы все.
Model вы рассматриваете только как ActiveRecord (пусть и не явно). AR — это одна из возможных реализаций Model.
Да ладно, в вашей статье отсутствует объектиная критика (только субъективная), куча подмененных понятий и необоснованных выводов. Это отличный троллинг))
Удивительно, как много текста требуется, что бы сказать "Здравый смысл — превыше всего".
Неправильный путь: всегда использовать фреймворк поверх PHP.
Если пишешь маленькую либу для преобразования строк, или что-то типа того — ясное дело, что фреймворк тебе не нужен, он просто не будет использоваться. Если же фреймворк, как набор инструментов реально помогает жить — не пользоваться этим глупо.
Фреймворк — это не просто набор многократно используемого кода: вы не сможете вырезать кусок из фреймворка и вставить его в проект.
После этой фразы где-то в мире грустит один Фабьен.
Компании сталкиваются с тем, что фреймворки общего назначения плохо помогают решать конкретные задачи, к тому же очень медленно работают.
Если фреймворк не помогает решить задачу — он не подходит для этой задачи. На счет медленности фреймворков: PHP — язык быстрых решений, а не быстрых систем.
Но в любом случае вы добавляете в код новый уровень сложности, который совершенно не нужен!
Лолшто? Нужен, или нет — это зависит от проекта и его бизнес требований.
Когда мы пытаемся решать разные проблемы в рамках приложения с помощью одной конкретной парадигмы программирования, мы перестаём творчески мыслить и эффективно работать.
Когда мы начинаем творчески мыслить и внедряем множество парадигм в действительно крупном проекте мы становимся золотарями.
Неправильный путь: искать шаблон для решения проблемы.
Если твою проблему решили 100500 раз — так как раз таки надо поискать как.
Неправильный путь: всегда использовать объектно ориентированное программирование.
Когда PHP станет чисто ФП языком — тогда согласен. (Это не касается проектов на 5-50 строк, там в принципе все равно)
Однако если мы посмотрим на работу нескольких участников группы, становится очевидно, что реальная цель полностью противоречит заявленному.
Заговор, заговор! Где моя шапочка из фольги. Если стандарты есть — это на порядки круче, чем если их нет.
Если и нужна какая-то группа, то её стандарты должны отражать интересы всего PHP-сообщества, а не одних лишь разработчиков фреймворков и open source CMS проектов.
Зачем так ограничиваться?)) Нужна группа, которая поможет всему человечеству))
Во многих сферах требуется высокомасштабируемое, критичное ко времени выполнения, экономически выгодное ПО, которое просто невозможно создать, если следовать стандартам PHP-FIG.
Еще бы, на других языках PSR-* поддерживать скорее всего будет проблематично. Повторюсь PHP — язык быстрых решений.
Неправильный путь: следовать стандартам PHP-FIG, за исключением PSR-1 и PSR-2.
А как же PSR-5, PSR-12?)) Если стандарт не противоречит бизнес требованиям проекта И дает плюшки — глупо им не пользоваться.
Неправильный путь: не разрабатывать приложение безопасным по умолчанию.
Печаль, такое хорошее было начало, и такой вывод… Неправильный путь: вспоминать про безопасность по умолчанию после того как вас хакнули на тролололиард денег.
@franzose Посмотрел вашу библиотеку, есть несколько моментов:
вы не проверяете вводимые настройки для валидации так же не проверяете, а доступен ли валидатор для конкретно этого типа. Пример для Length.php
ваш валидатор подходит только для проверки пользовательского ввода. Это не то, что бы недостаток, а скорее ограничение применения. В случае, если проверять придется много — ваш валидатор станет довольно прожорливой штукой так как на каждую проверку создается тьма объектов.
По своему опыту скажу: задание правил проверки в стиле "not_empty|length:5,15" для крупных проектов — скорее минус, чем плюс. Так как корректность этих правил вы можете узнать на момент запуска, а не на момент написания.
> Предприниматели получают деньги без всяких обязательств в обмен на 7% акций
может я не правильно понял, но 7% акций не является обязательством?
Складываться впечатление, что 1 работающих должен будет обеспечить как минимум 9 БД не работающих. Свой 10-ый БД он тоже по идее должен заработать, вся разница в том, что он его получит из других рук.
По сути наш работающий должен будет как-то выплачивать эти 10 БД в виде налогов (если в стоимости услуг/товаров — это те же налоги, просто платить на прямую их будут те, кто предоставляет услуги/товары).
Если БД будет минимально низким, даже нищенским (можно сравнить с прожиточным минимумом, в Украине на данный момент ~58$) — возможно в этом и будет смысл, но при условии отмены других налогов.
Если же БД будет достаточно высокого уровня — сначала работающему будет со всей силы не выгодно «в белую», будут «серые» и «черные» схемы работы, это сейчас довольно распространено по СНГ. В дальней перспективе рынок все равно снизит БД до нищенского, а привычка работать по серой и черной схемах будет уйдет не скоро.
ИМХО: БД в виде, что указан в статье — обречена на провал. Идея же выхода государства их экономики — должна развиваться.
лол))
аргумент....))
если перед коммитом тест сломался — да, нужно поправить
Вы просто еще не научились их писать))
Верно, если вы поменяли код — то сломанные тесты сами себя не поправят.
Качество автомобилей можно определить только за счет их тестирования до введения в производство И после N-летней поддержки.
На основе самомнения же аргумент — так себе.
Круть, наконец-то хоть один пункт в точку. Рекомендую сделать это первым пунктом и "привит к красивому" заменить на "умею их писать", в этом случае будет идеально.
И где там указание, что это конфиг по умолчанию?
То, что это примеры, я вижу, то что по умолчанию — не вижу.
Понятное дело, что не ядро (мы же в контексте фреймворка говорим).
За тем, что
Еще раз: если вбрасываете про что-то подумайте сначала. Ваша поделка не решает проблем, которые вы предъявляете другим фреймворкам.
Именно по этому я привел в пример софт, который действительно решает подобного рода проблемы.
Конфигруация.
Привести пример, когда это решение не правильное?))
верно, для dev окружения обычно отключается кэширование.
Вы никогда не замечали, что в сгенерированный код обычно пишется комментарий в стиле "код сгенерирован, не надо его менять"?
Подумайте еще разок.
Перефразирую ваш вопрос: а если я не правильные данные в программу введу, она даст правильный результат?
На бэкенде — нет.
И будет у вас файлик на тыщу строк, жуть какая.
glob уже запрещен?
Возвращайтесь в 2016, тут есть всякие memcached, redis, apcu,...
Не благодари
Зато дергать файловую систему ради по глупости — это отлично))
Вы зря так считаете, выводы я уже давно сделал, могу даже поделиться:
Но у вас есть незыблемая уверенность в своих знаниях, по этому я делаю вывод:
Вы демонстрируете эффект Даннинга — Крюгера
Возможно я что-то пропустил, но ссылок на apache.org не вижу
Динамических, в стиле htaccess, htpasswd да, нету, только статические.
Вы используете что-то в стиле green sql? Если нет — ваше ядро не решает проблему
Экосистема больших фреймворков тем и подкупает, что аудитором (пусть и косвенно) является каждый, кто его использует.
Собственно и что теперь?
Вы так говорите, будто бы маппинг обязательно нужно делать руками.
Зависит от продуктовых требований к проекту. Из основных вариантов решения этой проблемы:
Выберите что-то одно
Еще раз: менять нельзя.
Ну нет такой штуки, как конфиг по умолчанию, не ужели это не ясно? Если вы в проекте дописываете .htaccess — это нихрена не конфиг по умолчанию, это станет вашей личной анальной болью.
В том же nginx+php-fpm в принципе отсутствует поддержка динамической настройки сервера.
Верно, но смею заметить, что вы со своим 50к ядром точно в такой же ситуации))
неа)) Есть интерфейсы, наследование, DI,...
Если посмотреть, что callable — это function/string/array[string,string]/array[object,string], да это очень опасная конструкция. Лучше уже тайпхинтинг на \Closure
Вы изначально хотите каку сделать)) Под статику достаточно реализовать маппинг и уже на его основании делать сборку. __call тут ну вот ни капли ни при чем.
этот подход — днище.
Все верно, но и магия тут тоже вот ни капли не нужна)).
Меняй барыгу, пока не поздно.
private — это модификатор, явно указывающий: «тебе это трогать во вне текущего класса не надо».
final — это модификатор, явно указывающий: «тебе нельзя тут ничего менять».
слив засчитан
Если сервер настроен криво — это значит, что руки кривые.
Если без __call вот вообще никак — у вас архитектура днище. __callStatic — это еще хуже. Про существование этих методов стоит в принципе забыть.
Именно по этому и нужны эти все кучи абстракций.
на 5-ой
@Fesor Вы пытаетесь спорить с программистом в 4-ой стадии))
G-M-A-X Вам тоже не помешает прочитать
https://habrahabr.ru/post/39300/
Ничтожный)). Что с доктриной, что без, сетевые издержки будут на порядки дольше, чем обвязки.
Я рад за вас, вы только что придумали Entity-Repository. Во многих случаях он более надежный, чем AR. Правда бывают случаи, когда он слишком избыточный.
На компонентах — да, на стеке выполнения — нет.
Тип того + все ваши фоловеры видят, что какие проекты вы отмечаете.
Вообще говоря — нет. Хранилищем данных может выступать и кэш, xml файл, внешний сервис, что угодно.
Пример: http://docs.doctrine-project.org/projects/doctrine-common/en/latest/reference/caching.html
Если вы утверждаете, что все реализации — плохо, то должны смочь аргументировать такую позицию.
У yii — 4679 звезды на github, у silex — 3292. Я бы не сказал, что тут прямо пропасть в уровнях известности.
Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.
В Symfony нет своей имплементации M из MVC, да есть Doctrine, но это проект другого вендора. Посему называть его MVC фреймворком не корректно.
Смысл есть. Вы же набрасываете на фреймворки в целом. Что на счет Zend, Silex?
Смысла нет. 99% вашей статьи — бред сивой кобылы.
В статье вы критикуете "фреймворки", при этом доводы базируете только на yii.
Далеко не все фреймворки используют MVC подход, вы же говорите так будто бы все.
Model вы рассматриваете только как ActiveRecord (пусть и не явно). AR — это одна из возможных реализаций Model.
Да ладно, в вашей статье отсутствует объектиная критика (только субъективная), куча подмененных понятий и необоснованных выводов. Это отличный троллинг))
Посыпаю голову пеплом, тут 2 "не", я же прочитал с одним))
Спасибо за перевод
Удивительно, как много текста требуется, что бы сказать "Здравый смысл — превыше всего".
Если пишешь маленькую либу для преобразования строк, или что-то типа того — ясное дело, что фреймворк тебе не нужен, он просто не будет использоваться. Если же фреймворк, как набор инструментов реально помогает жить — не пользоваться этим глупо.
После этой фразы где-то в мире грустит один Фабьен.
Если фреймворк не помогает решить задачу — он не подходит для этой задачи. На счет медленности фреймворков: PHP — язык быстрых решений, а не быстрых систем.
Лолшто? Нужен, или нет — это зависит от проекта и его бизнес требований.
Когда мы начинаем творчески мыслить и внедряем множество парадигм в действительно крупном проекте мы становимся золотарями.
Если твою проблему решили 100500 раз — так как раз таки надо поискать как.
Когда PHP станет чисто ФП языком — тогда согласен. (Это не касается проектов на 5-50 строк, там в принципе все равно)
Но обезопасить свой код от дурака — таки надо))
Заговор, заговор! Где моя шапочка из фольги. Если стандарты есть — это на порядки круче, чем если их нет.
Зачем так ограничиваться?)) Нужна группа, которая поможет всему человечеству))
Еще бы, на других языках PSR-* поддерживать скорее всего будет проблематично. Повторюсь PHP — язык быстрых решений.
А как же PSR-5, PSR-12?)) Если стандарт не противоречит бизнес требованиям проекта И дает плюшки — глупо им не пользоваться.
Печаль, такое хорошее было начало, и такой вывод… Неправильный путь: вспоминать про безопасность по умолчанию после того как вас хакнули на тролололиард денег.
@franzose Посмотрел вашу библиотеку, есть несколько моментов:
Посмотрите на досуге: ko-ko-ko/assert
может я не правильно понял, но 7% акций не является обязательством?
Складываться впечатление, что 1 работающих должен будет обеспечить как минимум 9 БД не работающих. Свой 10-ый БД он тоже по идее должен заработать, вся разница в том, что он его получит из других рук.
По сути наш работающий должен будет как-то выплачивать эти 10 БД в виде налогов (если в стоимости услуг/товаров — это те же налоги, просто платить на прямую их будут те, кто предоставляет услуги/товары).
Если БД будет минимально низким, даже нищенским (можно сравнить с прожиточным минимумом, в Украине на данный момент ~58$) — возможно в этом и будет смысл, но при условии отмены других налогов.
Если же БД будет достаточно высокого уровня — сначала работающему будет со всей силы не выгодно «в белую», будут «серые» и «черные» схемы работы, это сейчас довольно распространено по СНГ. В дальней перспективе рынок все равно снизит БД до нищенского, а привычка работать по серой и черной схемах будет уйдет не скоро.
ИМХО: БД в виде, что указан в статье — обречена на провал. Идея же выхода государства их экономики — должна развиваться.