Pull to refresh

Comments 368

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

Вот тут нужно по полочкам. Разве не спрос рождает предложение, а не наоборот?
Нет ни у кого общих проблем?)) А что же тогда решают фреймворки, хочется спросить, не общие ли проблемы и велосипеды?)
Очень специфические проблемы есть только в научных центрах. Все остальные живут на общем рынке, с одинаковыми задачами — производство либо барыжничество.

Если родиться уникумом, коих можно пересчитывать по пальцам в современном мире, те действительно не решают общие проблемы в силу магии своей личности. А для всех остальных доширак в обед и фреймворки.
продолжу.
Чётко уясните: строк кода в любом проекте должно быть как можно меньше, чтобы код стал как можно чище и читабельнее!

Согласен. Но с какого момента начинаются сроки кода?) С момента запуска машины под операционной системой? Или с момента установки и конфигурации вебсервера, ведь ничего просто так у вас не заработает. Всегда есть готовые продукты, слои, на которых мы сидим и думаем только о своих маленьких строчках кода. Фреймворк тут такое же звено как и все остальное.

Единственный минус всех свистоперделок — производительность. Никто бы и критиковать не подумал бы, как не думают критиковать клавиатуру что она медленно «выдает» буквы.
Единственный минус всех свистоперделок — производительность. Никто бы и критиковать не подумал бы, как не думают критиковать клавиатуру что она медленно «выдает» буквы.

Насчет скорости тут как. Чтобы она стала играть роль, надо чтобы именно фреймворк стал узким горлышком.
Зачастую узкое горлышко в других аспектах.
Какая разница мне, если фреймворк тормозит при миллионе пользователей, если у меня на сайте в день 100 человек?
Фреймворк не начинает тормозить на миллионе, он сразу тормозит :)
Враньё, как обычно) Покажете, когда фреймворк становится тормозом? На примере phalcon, plz )))
Я не говорил что багов нет, я говорил что тормоза во фреймворках, чаще всего, надуманная и не актуальная проблема ;)
То есть, Вы таки признаете, что на фреймворках есть баги? :)

А проблема, конечно, надуманная.
Разработчики платят за сервера не из своего кармана.
Разработчики не могут оптимизировать код и поют бизнесу сказки о высоких нагрузках и покупке новых серверов.
И скажите, что неправда.
Как и в любом другом коде. В вашем, я уверен, сильно больше багов. Даже без исходников уже нашли у вас баги ;)
Разработчики платят за сервера не из своего кармана.

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


Меня более чем устраивают респонсы по 50ms-100ms с Symfony.

Если их устраивает, пускай платят :)
Всякое бывает. :)

Я себе не могу позволить арендовать мощный сервер из-за пиков в 30-50 раз от средней посещаемости.
Если посещаемость плавная, то этот момент не так заметен, необходимость увеличения с ростом посещаемости кажется очевидной.
Я себе не могу позволить арендовать мощный сервер из-за пиков в 30-50 раз от средней

помимо вертикального масштабирования есть еще горизонтальное. Один сервер за 320 баксов вполне может держать примерно столько же rps сколько 7 серверов по 20$, а это $180 баксов выгоды. А если нагрузка плавает мы можем добавлять инстансы по потребностям.

Какие-то сомнительные сервера по 20 баксов. :) Это ж не физические сервера?
Ну ок.
Допустим, я сейчас влезаю в один сервер за 20 баксов. А так нужно будет 50 серверов по 20 баксов. :)

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

Конечно, можно самому запрашивать по API или как ресурсы не только в рамках одного физического.
Но это нужно все запрограммировать, чего вы так избегаете. А потом ресурсы нужно освобождать.
БД тоже таким образом будем разворачивать? :)

Да и нагрузка растет очень резко, что доп. сервера могут не успеть развернуться, разве постоянно оплачивать место на дисках.

Также, я не могу прогнозировать, какой именно трафик придет, чтобы вручную добавлять сервера.
Да и просто лень за этим следить.

Кто-то использует ресурсы по запросу? Как используете?
если проанализировать, то я продолжаю читать этот тред, чтобы узнать насколько человек может быть не подкован в разработке и смежных областях, чтобы пытаться наравне дискутировать с человеком, знающим экосистему от и до.
Ну серьезно: облако, aws, инстансы — не, не слышал…
Все остальные облака, с которыми приходилось сталкиваться на деле оказывались не фазанами, а обычными виртуалками (общипанными курицами).

Как все это в aws — не знаю.
Там очень много сущностей, мне лень с ними разбираться.

Если же мы используем API, то все это нужно запрограммировать.
Или вы верите в чудо?
Что вы держали в амазоне?
Что такое ECU?
До сих пор 1.0-1.2 GHz 2007 Opteron or Xeon?

Капец. Придет какой-то очередной напыщенный и начинает учить.
Что я написал не так?
Что Вы пристали со своим фальконом, который никто не использует (даже Вы)?
Берите Симфони.
Посмотрите, как тупит блаблакар. :)
Как тормозит Blablacar


Как грузится ваш бложик


Разница — всего-то 2 раза. И в блабакар жирнющий симфони, нагрузки побольше, да и на загружаемой страничке как-то побольше интересного.

А теперь финт ушами:
1. Это замеры вместе с сетевыми задержками + сервер :)
2. Главная страница там не доходит до php :)
  1. Это то что важно. Сколько там работает php и работает ли — это уже второстепенно. Важно за сколько миллисекунд клиент получит ответ от сервера, то есть именно с сетевыми задержками.
  2. И что?) важен же результат итоговый)
UFO just landed and posted this here
Ну тогда и gmax-у надо поднять такой-же функционал как у блаблакар и только потом сравнивать ;)
А сравнивать огромный объем внутри блаблакар и простейший crud в говноблоге — не правильно.
ведь у вас спор не об этом

Спор ниочем.


Важно достичь той производительности, при которой не будет страдать UX. То есть если пых отрабатывает 10ms и при этом клиент получает ответ за 100ms, то какая собственно разница?


А еще есть такие вещи как TCP буферы на сервере. То есть если пых например отрабатывает 50ms, пинг до сервера так же 50ms, то при размере ответа до 50 килобайт вполне возможно что пользователь получит ответ за 100ms, в то время как при большем размере тела ответа будет уже 150ms и то если не-было потерь пакетов.


я например пишу мобильные приложеньки и в мобиьных сетях нормальное дело пинги в 200ms, и на фоне этого то что у меня json-ки отдаются 50ms или 100ms уже не столь существенно. С точки зрения же сервера большая часть времени уходит всеравно на блокирование потока выполнения при работе с I/O.


Да, есть конечно и свои нюансы. Например если мы пишем на symfony и у нас dependency hell — то да, будет медленно. Но опять же есть "решения" вроде php-pm.

UFO just landed and posted this here

Давайте тогда разбираться вместе где же я не прав. Вот для наглядности картинка:


image


  • На сервер к нам приходит TCP пакет (будем вести отсчет уже после хэндшейков, мол keep alive и все такое). Время на подтверждение доставки нас особо не интересует (хотя вот тут я могу быть не прав)
  • пакет этот разбирается nginx-ом за смешное время, парсятся заголовки, запрос уходит в php-fpm. Сетевым взаимодействием в пределах loopback интерфейсов мы можем пренебреч поскольку там все чуть проще.
  • через 50ms php-fpm отдает ответ nginx-у который отправляет это в сокет клиенту.
  • tcp пакеты помещаются в буфер. В linux-ах по умолчанию в ядре установлено ограничение на 10 пакетов, которые можно отправить не дожидаясь подтверждения. То есть если не-было потерей пакетов клиент получит пакеты за следующие 25ms, время на подтверждение нас так же не особо интересует (так?).
  • в буфере у нас осталось еще 5 пакетов, они будут доставлены только после того, как нам придут подтверждения по первым 10-ти. Опять же все у нас хорошо, подтверждения пришли в нужном нам порядке, это значит что через 25ms после отправки первых 10-ти пакетов у нас пойдут оставшиеся 5.
  • за следующие 25ms будут доставлены оставшиеся 5 пакетов.

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

UFO just landed and posted this here
А «медленный старт»? Окно?

Повторюсь. Я беру наилучший вариант. При нем у нас уже есть TCP соединение (то есть нет накладных расходов на это), размер окна — 10 пакетов по дефолту (причем я беру наилучший случай когда размер одного пакета = MTU). Ну то есть быстрее чем за 150 миллисекунд в моем примере 15 пакетов клиенту не доставляются.


15 пакетов просто для примера. То же самое для 11-ти пакетов — 150ms. плюс минус конечно, поскольку я сильно упрощаю, но быстрее не выйдет.

UFO just landed and posted this here

Не соблаговалите пройти небольшой опросик:


1.Вы когда нибудь работали в команде? Ну то есть не бложики/каталоги на своем ядре, а проекты которые в одиночку сделать за адекватные сроки не выйдет (например в одиночку вы писали бы проект год, а его релизить нужно через пару месяцев, бизнес не хочет ждать). Если да — то что использовали, были ли в команде люди опытнее вас, каков размер команды.


  1. Вы занимаетесь поддержкой всех проектов, которые были реализованы на вашем решении? Если да, вы когда-нибудь замеряли время на поддержку "своего ядра"? Можете написать примерное количество часов в месяц?
  2. У вас есть проекты, которые не умещаются на одном сервере? Я имею ввиду когда вам приходится раскидывать PHP на несколько серверов.
  3. Предположим что я заказчик. Я хочу что-бы вы разработали мне API для мобильного приложения для бронирования митинг румов (допустим у меня их штук 40 и они делятся по наличию/отсутствию какого-то оборудования, вмещают разное количество людей и нужно автоматически по потребностям их асайнить + нотификации). Можете предоставить грубую оценку в часах сколько у вас займет времени это сделать? Что будете использовать?
>Не соблаговалите пройти небольшой опросик:

Всех оппонентов прошу сделать то же самое.
У Вас почему-то 2 раза 1 :^)

1. Иссесина. Всегда работал в команде, самопись — это личное.
Конечно, были опытнее.
Использовали то, что и все: mysql / php / memcached
Размер микрокоманды — 6 человек. Размер всей команды — хз, больше 20 человек, я всех не видел. :)
Бложик, по большому счету, я не писал специально. :) Все было готово, прикрутил только вывод на главную.

2. Кроме меня этими проектами никто не занимается.
Вот с начала лета точно в ядро ни разу не лез :)

3. Нет, у меня 60к хостов влезало в шаред хостинг и не выходило за лимиты процессора.
Зачем меряться количеством серверов? :)
Это показатель крутости?
Хм, но лучше меньшее кол-во серверов: и по цене и по поддержке.
На работе порядка 15 серверов.

4. Я никому свой код не продаю. :)
Вам нужно API для МП или система бронирования полностью?
Что такое «асайнить»? Назначать/бронировать?
Нужно знать, какие методы нужно предоставить.
Вы платите по часам / по строкам кода / по результату? :)
Какие критерии выбора подрядчика?
А вообще, больше времени уходит не на написание кода, а на чтения замудрого кода, где шибко умные программисты ерунду писали, или просто кода, по которому плачет рефакторинг. :)
Ничего особенного использовать не буду. Зачем технологии ради технологий? :)
  1. конкретнее, фреймворки, библиотеки? самопись? Тесты я так понял не пишите.
  2. То есть в коммерческих проектах вы это "свое решение" не используете и не можете оценить стоимость поддержки оного в часах?
  3. 15 серверов — это для одного проекта?, или просто 15 серверов под разные нужды? Ну мол это вы горизонтально что-то масштабируете или, к примеру, просто 15 машинок для различных нужд?
  4. Вопросом на вопрос, ну ок
    4.1 вы продаете не код а решение проблем. Иначе не понятно о чем вы вообще толкуете со своей религией
    4.2 Клиент пишите не вы, да. API системы бронирования.
    4.3 Иж чего, откуда ж я знаю, я просто заказчик. Мне плевать что там под копотом будет.
    4.4 Конечно же по времени.
    4.5 адекватность, инициативность, умение решать проблемы
    4.6 Согласен. Но фреймворки тут непричем. Не нужно знать принципы или какие-то правила что-бы читать адекватно написанный код. А вот что-бы писать…
    4.7 затем что-бы снизить издержки на разработку.
1. Уже все знают, что Yii 1.1 :)
2. Я всегда говорил, что самопись использую только для себя. :) А поддерживать ядро нужно в любом случае, ибо на фреймворках всего этого нету. :)
3. 1 проект.
4.1. Но вы же хотите платить по часам :) На самом деле все эти часы — ерунда: их легко можно нарисовать (и мои менеджеры их рисовали :) )
4.2. Я не о клиенте. Сама система бронирования уже есть? Оно уже где-то работает? Или бронируют в бумажном журнале? :)
Прикрутить в этом случае API к работающей системе как бы не сложно.
Но нужно понимать, почему не устроили существующие решения.
Ведь они имеют интеграцию с другими процессами компании.

4.3. Ну и я не знаю, что вы хотите видеть в своем приложении. :) Поставьте требование разработчикам приложения, они поставят нам.
4.5. >адекватность, инициативность
Вы хороший клиент.
Большинство заказчиков настаивают, чтобы делать бред, который они хотят. :)
А потом часто просят сделать так, как им говорили.

Только как вы это будете определять?
На цену вопроса внимания не обращаете?
4.7. Если нету необходимости в этих технологиях, то это только удорожит разработку. А еще неизвестны перспективы этих технологий.
Нужно иметь конкретную задачу и решать ее самым простым способом.
Вот тут где-то для отдачи статики предлагали нагородить огород, который якобы будет держать большие нагрузки.
Но при этом не учитывалось, что спрос ограниченный и этот огород не может реализовать требования ТЗ. :)

4.1 ну нарисовать можно что угодно. Я работаю по time&material. То есть "работаем пока клиент платит". Хорошо если мы укладываемся в бюджет проекта, иногда приходится жертвовать частью хотелок и потому мне важно что бы все пилилось максимально быстро, что бы клиент мог реализовать максимальное количество хотелок в минимальный бюджет. Что бы он потом с этим смог найти инвестора и получить дополнительное финансирование… ну вы поняли)


4.2 Разработка с нуля.


4.3 Да ладно вам, никогда таких оценок не делали?


4.5 Я разработчик)) Такое поведение клиента очень часто можно встретить, именно по этому тактика "как можно быстрее сделать так как хочет клиент, показать ему что он не прав и максимально быстро переделать как предлагалось аналитиками/дизайнерами" работает лучше чем попытки уговоров (зависит от клиента конечно, у меня вот текущий клиент как раз из таких. Потратишь час на споры, сделаешь за денек, покажешь и он тако "ну это отстой" и говорит так как ему предлагалось сутки назад как буд-то бы это его идея. Но что тут поделать, клиент должен быть хэппи.


4.7 Ну вы же разработчик, вы и решаете) главное что бы я потом не испытывал с этим трудностей при найме команды и т.д.


p.s. интереса ради глянул сколько моя апишка выплевывает json… сначала ужаснулся цифрам (240ms для списка категорий) а потом прогнал без учета накладных расходов на сеть (ну то есть дернул curl-ом на серваке). aws микроинстанс, симфони, доктрина, парочка кэшей которые включаются двумя строчками в конфиге — 28ms. Список продуктов каталога — ~45ms. И это я еще не подключал прокси генераторы для гидраций в доктрине.


Как по мне вполне себе норм. Да и авторы доктрины уверяют что в 3-ей версии все будет еще круто и будет летать.

4.3
Коммент к статье (к первой цитате) https://habrahabr.ru/post/308494/#comment_9773010

Обычно мне оценки спускают, обычно я в разы быстрее справляюсь.
Но иногда вижу, что оценка занижена, и говорю об этом.

4.7
Ну так трудностей и проблем возникнуть не должно, так как все будет решено самым простым способом… :)

П.С.
А раньше вы меряли с сетевыми задержками. :)
А тут уже вас такой замер не устроил. :)
С точки зрения пользователя ему все равно, будет 90мс или 100мс (он и больше стерпит, вернее, даже не заметит :) ). Только вот на сервере это будет 10мс или 20мс. Грубо говоря, сервер сможет держать нагрузку в 2 раза большую.

Тут один защитник фреймворков увидел у меня соринку в глазу, будто я потратил лишнюю 1 микросекунду на обращение к файловому кешу ОС, а вы говорите 100 или 200 мс — пофиг. :)

А еще некоторые защитники фреймворков не в восторге от Доктрин и пишут запросы руками. :)

>Да и авторы доктрины уверяют что в 3-ей версии все будет еще круто и будет летать.

Маркетинг. :)
Я же не надеюсь на кого-то и не перекладываю на него ответственность.
А обещанного 3 года ждут. :)
> Разве не спрос рождает предложение, а не наоборот?
Изначально, когда-то давно, спрос рождал предложение. Но потом родился первый в мире маркетолог, и он понял, что спрос можно (и нужно) формировать под своё предложение. И стал набирать популярность обратный вариант.
да. но в зоне потребления, потребительских товаров. А профессиональная область хоть этому и подвержена, но куда менее. Поскольку тут товар, потроха и оболочка, непосредственно представляет область проф. интереса.

Видите ли, разработка на PHP — сама по себе массовая область, и здесь имеется всё: маркетологи, реклама, и так далее. И товаром тут являются в том числе фреймворки, а также мартышки, которые их бездумно используют. Мартышек здесь особенно много, потому, что порог вхождения низкий.

Подвержена ещё как. Посмотрите, что сейчас происходит на рынке PHP-фреймворков. Это сотворено прежде всего руками хороших маркетологов.

В яблочко! Особенно про фреймворки которые используют где ни попадя и часто без нужды.
Кстати, это не только в PHP. Типичнейший пример использования той же тактики — jQuery в мире JavaScript.
UFO just landed and posted this here
Я не спорю с его плюсами и, даже, полезностью. По к месту и времени, а не бездумно и почти везде.
В результате попадаются индивиды, которые оригинальный JS толком понимать перестают. Не говоря уже за скрытые за кодом принципы и суть реализуемых процессов.

jQuery удобен. Просто, писать что-то вроде $("#id") короче, чем document.getElementByID('id'), а $("#id .x") вообще коротко уже и не скажешь.


Хотя, конечно, мелкие вставки (для которых Javascript вообще-то и предназначается) легко пишутся без обвесок.

jQuery — это библиотека.
Говорят, что в эпоху массовой эмиграции евреев из СССР в зоне прилёта переселенцев в аэропорту Бен-Гурион висел плакат: «Не думай, что ты самый умный — здесь все евреи».
Самое простое доказательство важности использования jQuery — уменьшение количества кода в три (!) раза и даже более при аналогичном функционале, и как следствие — экономия времени при его написании. Просто сложно это понять не попробовав это самому, ни так ли?
Ну с фреймворками код сокращается на порядок «при аналогичном функционале, и как следствие — экономия времени при его написании». Только смысл поста не в этом. «Просто сложно это понять не» подумав как следует.
Я говорил конкретно о Вашем комментарии про jQuery, которую как и фреймворки «используют где ни попадя и часто без нужды». Нет, конечно, в ней может и не быть необходимости, согласен, однако если написать на JS требуется хоть даже одну строку, на JQuery даже эта строка будет короче и оптимальнее. Я не говорю и о том, что она имеет более оптимизированные и безопасные аналоги операторов, например $.typeof (), и т. п., которые крайне рекомендуется использовать взамен нативных.
Когда ради пары строк кода на JS тянут целую библиотеку, а это теперь почти повсеместно, это просто какой-то позор.
А, ну тут я соглашусь. Только не стоит делать такие поспешные выводы, у нас во многих проектах до 60% функционала jQuery используется запросто! Сомневаюсь, что Вы каждый проект разбирали по косточкам и смотрели что и как в нем реализовано.
Недосуг мне. Но когда приходится подтирать сопли за кодерами, это везде и рядом, на самом деле.
Умножение сущностей без нужды это главный грех программиста.
Ну тут я солидарен) Highslide в этом смысле пошли по правильному пути: у них можно скачать с десяток разных версий с различным функционалом, и, как следствием, количеством кода. Правда для нее все-равно пришлось делать свой обвес для расширения функционала, зато благодаря этому на новых проектах не приходится кастомизировать ее с нуля, ибо из коробки она довольно бедна, как бы странно это бы ни звучало.
«Подтирать сопли» — это удаление всяких «эких новомодных наркоманских джэйкварей» и перепись проекта под голый js?

По мне так грех делать кривущие браузеры, которые уже четверть века никак не могут держаться единого стандарта и не желающих упростить жизнь программерам и взять функциональность jquery под свое крыло.
Подтирание соплей, это оптимизация кода и устранение косяков, часто неочевидных, в реализации.
Так без той же jquery косяков, не очевидных, станет еще больше.
UFO just landed and posted this here
При нормально оптимизированном и правильно минифицированном коде, в частности при правильном подключении скриптов на странице, разница будет практически незаметна, уверяю Вас. Честно признаться, говорю о разрабах в общем, я и сам потрошу весь код, выкидывая из него ненужное и оставляя нужное мне. То же я сделал и с jQuery. Однако очевидно, что я использую его во многих проектах, и просто бессмысленно тратить время на написание кода на JS каждый раз заново, если однажды Вы уже писали его под свои нужды. В данном случае Вас можно поздравить: Вы написали свой фреймворк.
Браво. Вы почти меня поняли.
Теперь абстрагируйтесь от JS и поднимитесь на уровень выше. Мысль будет предельно понятной.
Да, я Вас понимаю полностью. Только я и говорю о том же jQuery как о просто удобной библиотеке для JS, которая избавляет от написания уже написанного ранее кода (извините за тавталогию), ибо просто нет смысла писать все для каждого проекта заново. То, что она разрослась в огромного монстра — я понимаю, поэтому все ненужное мне из нее выкинул, однако я по прежнему называю это свою поделку jQuery, так как базируется она на ней. Почему этого не могут сделать другие разрабы — вопрос не ко мне, я описал свой собственный опыт работы с ней, и то, что, собссно, изначально было ее основной миссией.
А чем Вам Zepto не угодил? Отлично подходит для случаев, когда от jQuery нужен только основной функционал и не нужна поддержка старых браузеров.
В том, что когда нужна максимальный охват аудитории, Зепт откидывает всех кто не на современном браузере.
Когда нужен максимальный охват, проще взять какой-нибудь jQuery 1.9.1 с CDN, и он с большой вероятностью в кеше браузера окажется даже при первом запросе.
Я сказал почему почему Зепта не подходит.
Как по мне, jQuery с головой хватает в 90% случаев. А проблемы якобы большого размера jQuery, это проблемы негров.
Хм, благодарю, да, игрался с ним ради спортивного интереса, но для себя тогда не обнаружил необходимости в переходе на него, и плюс да, он действительно отметает старые браузеры, и как показывает исследование рынка пользователей браузеров — такой шаг был бы чистой воды эгоизмом. Однако с другой стороны в потрошении jQuery есть одно «но»: путь к обновлениям полностью отрезан, однако и кроссбраузерные версии до 2.1.1 уже не обновляются, а начиная с 3.0.0 новые браузеры она так же заворачивает.

А у него в чем суть, можно подключать только то что надо, или подгружает только используемые методы?
+100500. Вы очень точно уловили суть.
Но это, увы, дано не всем.
А Вы с точки зрения экономики посмотрите: Вы как Мудрый Разработчик 1 ставите во главу угла уменьшение количества загружаемого клиентом кода и скорость работы бэкенда. Мудрый Разработчик 2 решает что лучше использовать больше бибилотек, но сократить время разработки (а значит, и стоимость).
Что получает Клиент 1, которому делал сайт Мудрый Разработчик 1: быструю загрузку страницы
Что получает Клиент 2, которому делал сайт Мудрый Разработчик 2: удешевление проекта и более быстрый старт

Чтобы упростить пример, решим что сайты зарабатывают рекламой.

Клиент 1 потртил больше средств, их нужно отбивать. И ставит больше рекламы на сайт. Которая дольше грузится.
Клиент 2 потратил меньше, и может себе позволить поставить рекламы поменьше. Кроме того, он запустился раньше — ему же сайт быстрее сделали.

В результате, посетитель сайта Клиента 1 доволен меньше: сайт долго грузится из-за рекламы, и на странице её визуально больше чем у Клиента 2.

Ясно, что пример простой. Смысл его в том, чтобы показать как вещи взаимосвязаны. Не нужно рассматривать «сферический код в ваакуме». Программисты делают продукт, который нужен бизнесу. И смысла экономить на спичках зачастую просто нет, по факту они выливаются в «медвежью услугу» и для заказчика и, даже, для пользователей.
Интересный пример про то, как уменьшение объёма загружаемой JS-библиотеки приводит к увеличению объёма загружаемой страницы…
Содержание проекта по цене обычно не сопоставимо с его разработкой, и рисовать в лоб зависимость количества рекламы от бюджета разработки сайта я бы вот так лихо не стал. Рекламу навесят и на быстрый проект. и на медленный одинаково.
Я бы не согласился. IMHO для бОльшей части проектов цена разработки сопоставима с ценой поддержки, если смотреть хотя бы на год работы.
Просто выбора обычно нет — нельзя же не поддерживать уже работающий продукт. А вот поддерживать И разрабатывать уже считай вдвое дороже.
А вот поддерживать И разрабатывать уже считай вдвое дороже.

если не менять численность команды — выходит одинаково. У вас человекочасов не убывает и не увеличивается. Проект мэйнтейнится и развивается одновременно. Другое дело что если там все плохо под копотом то может так статья что у разработчиков внесение изменений будет выходить очень долгим. И в итоге на одну и ту же работу потребуется больше времени. Так же отсутствие тестов — постоянное регрессионное тестирование — увеличение стоимость QA и т.д.


Ну то есть не стоит говорить столь категорично. Я знаю команды где ребята фигачили ДО релиза и после примерно в одинаковом ритме. А так же знаю команды где после релиза пришлось увеличивать команду потому что ребята банально не успевали фичи пилить, слишком долго выходило.

Если смотреть на сайт только как на сайт, и под поддержкой иметь в виду только хостинг, правки и прочую мелочь — то да. Но если сайт это основа бизнеса (не сео, контекст и прочее порево), то его разработка и поддержка лишь часть постоянных и переменных расходов. И уж точно бОльшее количество рекламы не появится там из-за его дороговизны. Количество рекламы вообще регулируется только количеством предложений и моральными/финансовыми ограничениями владельца)
Для большинства сложных, но типичных задач, использование фреймворка означает, что в случае чего, можно найти другого программиста, который знает этот фреймворк, и он сможет сразу продолжать.

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

Так не сможет же: всё равно потребуется время на то, чтобы «разобраться».

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

Дорого для кого?
Для нового разработчика? Так ему за это платят.
Для владельца? Так это будет плата за его же ошибки, допущенные им в самом начале…

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

Дорого для всех. Всегда все хотят платить меньше. С какой стати это ошибка владельца? Владелец обязан знать что такое фреймворки? Что такое движки? Вы совершенно не правы, если не хотите все это считать, хотя бы в теории.
А разве на фреймворках есть из коробки «добавить новое вложенное меню»?

Где-то есть, где-то — нет.
В общем случае, всегда знаешь что искать как реализовано нужно в базовом шаблоне, туда и идёшь.
Основная идея в том, что зная инструментарий популярного фреймворка и владея практиками его использования, влиться в разработку на нём значительно проще, чем в разработку основанною на кастомном решении.

Рассуждаете, будто знаете 2+ фреймворков, хотя по вашим комментам видно обратное — вечная ссылка на yii 1))

Не правда! По ссылке в коде есть ещё yii2!

Так как часто аппелируют тем, что в статье только Yii 1, добавил абзац в статью:
Тем, кто скажет, что я работал/знаю только Yii, только Yii говно, а все остальные норм
Вообще-то упоминаются и другие…
На работе используется Yii 1.1. Так как он под рукой, то он «попал под раздачу». Указаны примеры, которые меня раздражают, к пунктам недостатков.
Целенаправленно проверять другие фреймворки лень. Как сказано выше, это не значит, что пункт не подходит к другим фреймворкам. Скоро (не знаю когда) добавится Laravel.
Желающие могут указать свои трудности, с которыми пришлось столкнутся. Они будут добавлены в статью.

Трудности добавляйте, дабы сделать сравнение фреймворков. Тут недавно была статья https://habrahabr.ru/post/305626/
Но это курам на смех.

Также в начале статьи есть подготавливающий первый абзац:
Статья написана прежде всего с позиции разработчика, который пишет код для себя. Никого не заставляю писать на самописи, не всем это подойдет.
Блин, не хорошо кормить тролля, ну да ладно, сделаю исключение в этот раз…

Начнем с простого:

>Cвоеобразное извращенное понимание МВЦ.

У вас? Или у создателей фреймворков? А какое «правильное понимание mvc»?

>Как правило, модель содержит в одном файле код сущности БД и бизнес-логику.

Ой… А в каком это фреймворке есть готовые модели под мою задачу? В yii вроде нет. Вообще не могу вспомнить ни одного фреймворка, у которого уже есть реализация моделей. Чет вы путаете…

>Но цитата из бестпрактис Yii (пруф): «К примеру, модель News может содержать метод getLatestNews, который используется только пользовательской частью и метод getDeletedNews, который используется только административной частью.»

Слово «может» принципиально не замечаете))). Фреймворк не заставляет класть в модель эти методы. Тут, как во всем остальном тексте, проблема явно в вашем понимании, а не во фреймворках.

>3. Необходимость в коде контроллера вызывать рендеринг вида.

И это правильно! Вот в phalcon этого нет и мне очень не удобно.

>4. Не понятно, что такое виджеты в парадигме МВЦ. Какая-то сборная солянка в одном файле.

Ой… Как шаблон проектирования связан с реализацией сущности? Ок, вопрос тогда такой — что такое index.php в парадигме mvc? А как к этой парадигме относится папочка vendor? А в mvc предусмотрены конфиги? Вы хоть на смех себя не выставляйте подобными моментами))))

>Нету возможности выполнить другой контроллер.

Хм… Повеселило… И не должно быть. Контроллер принимает запрос — отдает ответ. Все. И при любом раскладе у вас будет единая точка прием-ответа — это и есть контроллер. А ваш пример настолько убог, что даже даже девочка-первоклашка поймет, что для подобных задач надо юзать модули/плагины/виджеты/etc. Собственно, у вас контроллер = виджет, а роутер = контроллер (скорее всего).

Ну а если уж дико хочется — вам нужен HMVC.

>Настройки для контроллеров

Мдя… Не работал с yii, но во всех остальных фреймворках можно создавать любые отдельные файлы/таблицы/коллекции настроек под любые потребности. Нужен конфиг для контроллера Main? Ок, примерно так: \Config::get('controller/main', $param); Но тут ладно, поверю, т.к. не знаю толком yii.

>Пути к файлам

Тут стало понятно, что psr для вас пустой звук. Ну ок.

>Код, написанный на чистом PHP, будет понятен всем разработчикам.

Логика блондинки))) Код на чистом php понятен всем, но код на чистом php в фреймворке — не понятен))))

>В обычной ЦМС статическая страница это обычный php файл. В фреймворках начинаются танцы с бубном и контроллерами.

Бред.

>У меня уже есть отшлифованное легкое ядро всего на 50КБ. :)

Перевожу на русский: «у меня есть свой фреймворк, но я не пользуюсь фреймворками, поэтому мой фреймворк лежит на полочке».

>Я программист, я не кодер.

Громкое и, судя по посту, беспочвенное заявление.

>Самопись же — под каждый дом — свой проект, как и есть в реальном мире, если Вы не собираетесь жить в курятнике.

Ну да, ну да… Помниться, хрущевки строились на «фреймворке». Более того, под этот «фреймворк» отдельные заводы строили ;). Да и сейчас большинство домов строится по типовым проектам, с использованием стандартизированных и типовых материалов/блоков и пр. В общем — даже в строительстве используют фреймворки. Умные и бережливые.

Ну а те, кому не жалко своего времени, сил и денег — пишут свое, да. И я был таким (а временами и остаюсь таким)).

>Еда

О да. Зря вы это затронули))). Вот когда вы голодны — идете сажать картошку? Начинаете изготавливать стол/стул? Нет? Т.е. вы используете готовую посуду, мебель, продукты, а не создаете все сами? А ведь это и есть «использование фреймворков» — берете готовые, проверенные блоки и используете их для своих нужд.

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

>Если гибкости и скорости CMS не хватает, использовать самопись.

Вот как раз при подобных условиях я лучше возьму фреймворк (phalcon). А для простых случаев — wp/самопись.

>У добавленных цсс/жс файлов нету признака, что файл изменился.

А это зачем? Подобные вещи лежат на деплоере, на клиенте (браузере), на сервере (nginx), но никак не на фреймворке. Он вообще не должна знать что есть какие-то там js/css.

>Отстутствие нужных фич, которые можно легко реализовать в самописи, но сложно на фреймворке из-за его ограничений.

Насколько помню — 3-й раз прошу дать пример. Что тяжело сделать на фреймворке (любом), но легко без фреймворка.

>Быстродейтсвие и потребление памяти.

Поспорим, что мой код на фреймворке будет быстрее вашего на вашей самописи?))))

>Нету нормальных готовых компонентов, например, для добавления пунктов меню, хлебных крошек.

В вашем ядре есть работа с imap, imagick, webdav, aws? Нету? Фиии… Нафига мне хлебные крошки, если нет элементарного?!

Ну, думаю, пока что хватит…
У вас? Или у создателей фреймворков? А какое «правильное понимание mvc»?

У создателей. MVC — это просто разделение кода. А они преподносят MVC как непойми какое достижение. Ну и были указаны конкретные возражения против понимания MVC фреймворками.

А в каком это фреймворке есть готовые модели под мою задачу?

Фреймворк не дает реализации. Но предполагается что реализация и код сущности БД будет в одном файле/классе.

Слово «может» принципиально не замечаете))). Фреймворк не заставляет класть в модель эти методы.

Перейдите по ссылке на документацию…

И это правильно! Вот в phalcon этого нет и мне очень не удобно.

Почему неудобно? У меня при вызове контроллера есть возможность указать, что его рендерить не нужно.
В большинстве случаев веб предполагает рендеринг.

Ой… Как шаблон проектирования связан с реализацией сущности?

Это лишняя сущность.

Ок, вопрос тогда такой — что такое index.php в парадигме mvc?

Контроллер

А как к этой парадигме относится папочка vendor?

Модель

Хм… Повеселило… И не должно быть.

Вообще-то есть, но не афишируется :)

что для подобных задач надо юзать модули/плагины/виджеты/etc

Зачем плодить сущности? :)

Собственно, у вас контроллер = виджет

Да.

а роутер = контроллер (скорее всего)

Основной роутинг на веб-сервере. А контроллер уже сам разбирает параметры.

В лучшем случае это 1 строка для разбора параметров, хотя ее можно вынести в код уровнем повыше, чтобы в контроллер приходили уже разобранные параметры.

А это зачем? Подобные вещи лежат на деплоере, на клиенте (браузере), на сервере (nginx), но никак не на фреймворке.


Клиент закеширует статику и сервер хоть и знает, что она изменилась, ничем не поможет.
А чем может помочь деплоер, если у клиента статика закеширована?
Это можно решить gulp-ом или чем-то подобным, но gulp для маленьких проектов вряд ли используют.

.
Насколько помню — 3-й раз прошу дать пример.

Вроде давал. Например тут:
http://govnokod.ru/19878#comment323742
Например, отдача 304 ответа, языки-фоллбеки для переводов определенного языка, та же дописка даты модификации файла у ресурсов.


Поспорим, что мой код на фреймворке будет быстрее вашего на вашей самописи?))))

Что будем мерять? :)

В вашем ядре есть работа с imap, imagick, webdav, aws? Нету?

Нет. Это большинству не нужно. Есть обертка для ресайзинг файлов над php функциями.

Нафига мне хлебные крошки, если нет элементарного?!

Хлебные крошки нужны большему количеству :)
>Но предполагается что реализация и код сущности БД будет в одном файле/классе.

Уточнение — предполагается вами, а не фреймворком.

>Перейдите по ссылке на документацию…

Перешел. Почитал. И? Не вижу ни в документации, ни в коде запрета реализовывать иначе. А в документации вижу многократное употребление слова «может».

>Почему неудобно? У меня при вызове контроллера есть возможность указать, что его рендерить не нужно.
В большинстве случаев веб предполагает рендеринг.

В phalcon это тоже есть (даже больше — можно не рендерить только определенный уровень. как пример — не рендерить layout, но рендерить виьюху). Вопрос не в том, что надо что-то запретить рендерить, а как отрендерить что-то, что не совпадает с названием класса/метода. Например, есть контроллер comments, метод index, который рендерит вьюху views/comment/index. Через какое-то время появляется контроллер top_comments или fb_comments, например, который обладает своей логикой, но вывод должен быть идентичен. Варианты? Копи-паст?

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

>Это лишняя сущность.

С чего-бы?))) Вот меню или хлебные крошки в фреймворке — это да, лишние сущности. А виджет — это расширение функционала.

>Контроллер

Мдя…

>А как к этой парадигме относится папочка vendor?
>Модель

Чего?! Vendor = model?! Т.е. js/css/cli у вас в моделях? И документация тоже?

>Вообще-то есть, но не афишируется :)

Я вам больше скажу — в php всегда можно вызвать любой код откуда угодно ;)

>Зачем плодить сущности? :)

Потому, что они выполняют разные роли? Вы спите на столе? А на работу ездите на стуле? Зачем вам разные сущности?))))

>Основной роутинг на веб-сервере. А контроллер уже сам разбирает параметры.

Т.е. скрипт зависит от используемого веб-сервера. Прелестно)))

>А чем может помочь деплоер, если у клиента статика закеширована?

Приехали… Одна из задач любого деплоера — пересобрать/изменить параметры вызова статики…
Кроме того, почему фреймворк вообще должен этим заниматься? Кешировать/не кешировать/на сколько кешировать/etc — задача программиста в рамках конкретного проекта, а не задача фреймворка. Мне вот в одном из проектов противопоказано обновлять скрипт на старых клиентах.

>Вроде давал.

Нет, не давали.

>отдача 304 ответа

header(...) / $this-response->setHeader('...') — не вижу где сложность в фреймворке, но простота в нативе.

>языки-фоллбеки для переводов определенного языка

вообще не понял.

>дописка даты модификации файла у ресурсов

filemtime. при чем тут вообще фреймворки?))))

Не катят ваши «примеры»)))

>Что будем мерять? :)

Память/скорость работы.

>Нет. Это большинству не нужно. Есть обертка для ресайзинг файлов над php функциями.

Большинству не нужны меню и хлебные крошки. Особенно второе ;). Покажете хлебные крошки на этой странице?)))
Уточнение — предполагается вами, а не фреймворком.

Перечитайте еще раз ссылку на документацию.
На предыдущих работах так и было.

Не вижу ни в документации, ни в коде запрета реализовывать иначе.

А я говорил о запрете реализовать иначе? Я говорил о бестпрактис…

Через какое-то время появляется контроллер top_comments или fb_comments, например, который обладает своей логикой, но вывод должен быть идентичен. Варианты? Копи-паст?

А при чем тут авторендеринг?
Указывайте в вызове контроллера шаблон, который нужно подхватить.

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

Я тоже за явность.
Но во фреймворках неявности и магии побольше :)
А если что-то и явно, то оно спрятано в тумане в куче абстракций.

С чего-бы?))) Вот меню или хлебные крошки в фреймворке — это да, лишние сущности. А виджет — это расширение функционала.

Меню и хлебные крошки сущности не архитектурные, а прикладные.
А виджеты и контроллеры дублируют друг друга.
Также это дублирование кода самого фреймворка.

Мдя…

Туда поступает запрос и там решаем что делать.
Этот контроллер может вызвать другой контроллер для обработки запроса.
Я ж говорю, у фреймворков своеобразное понимание МВЦ.

Чего?! Vendor = model?! Т.е. js/css/cli у вас в моделях? И документация тоже?

Для меня модель — весь код, на который я опираюсь и вызываю.
А js тоже делится на MVC, но с точки зрения бекэнда — это V
css — V
документация — это документация.

Я вам больше скажу — в php всегда можно вызвать любой код откуда угодно ;)


Ну да, глобалы рулят :)
Хотя не любой, goto не везде можно вызвать.

Зачем плодить сущности? :)

У меня большинство задач решается контроллерами и я не парюсь, взять стул, машину или кровать :)
Я говорю, возьми и сделай.

Какое-то подобие плагинов есть, но сильно не используется.

Т.е. скрипт зависит от используемого веб-сервера. Прелестно)))

Не зависит.
Раньше работало на nginx+apache, сейчас на nginx.
Скрипты при переезде не правил.
Фреймворки тоже зависят от веб-сервера, чтобы тот указал точку входа на /index.php.

Приехали… Одна из задач любого деплоера — пересобрать/изменить параметры вызова статики…

У нас это делает gulp.
И статику кто вызывает? Фреймворк. Значит деплоер должен подсунуть ему эту информацию.
Но деплоеры используются на более сложных проектах (как и упомянутый выше gulp).

header(...) / $this-response->setHeader('...') — не вижу где сложность в фреймворке, но простота в нативе.

У меня поддержка на уровне ядра.
А любые сторонние «компоненты» будут выпадать из этого функционала.

вообще не понял.

Допустим перевода на русский нету, тогда используем переводы в порядке наличия из языков фоллбеков: украинский, английский.

filemtime. при чем тут вообще фреймворки?))))

То есть Вы все таки будете дописывать ко всем файлам filemtime вместо деплоера? :)

Память/скорость работы.

Это понятно.
Я имею в виду какую задачу реализовывать.

Большинству не нужны меню и хлебные крошки.

Меню? О, да.

Покажете хлебные крошки на этой странице?)))

Разработка → PHP: неправильный путь :)
>На предыдущих работах так и было.

Сочувствую). Но тут зависит от программиста, фреймворк не принуждает ;)

>А при чем тут авторендеринг?
>Указывайте в вызове контроллера шаблон, который нужно подхватить.

И чем это отличается от вызова функции рендера?))))

>Я тоже за явность.

Тогда нафига авторендер?))

>Но во фреймворках неявности и магии побольше :)

Пруф? С теми фреймворками, с которыми я работал, магии практически не было ;)

>Меню и хлебные крошки сущности не архитектурные, а прикладные.

И нафига они тогда в фреймворке?)))

>А виджеты и контроллеры дублируют друг друга.

Серьезно?))) Если в вашей голове они друг-друга дублируют, это не означает, что вы правы ;). Я вам больше скажу — в некоторых фреймворках виджет может содержать контроллеры, модели, вьюхи. И даже работать с отдельной базой данных, например).

>Также это дублирование кода самого фреймворка.

Пруф?)))

>Туда поступает запрос и там решаем что делать.
>Этот контроллер может вызвать другой контроллер для обработки запроса.

Т.е., в вашем понимании, это часть приложения. Ок. Но тогда это у вас своеобразное понимание «своеобразное понимание МВЦ.»)). Для большинства разработчиков, index.php — это некий лоадер приложений (да-да, он может грузить разные ПРИЛОЖЕНИЯ, а не контроллеры — это бестпрактик ;)).

>Для меня модель — весь код, на который я опираюсь и вызываю.

И этот человек говорит о том, что у кого-то неправильное представление mvc… ха-ха-ха-ха… Получается, любая php-функция — это часть модели, верно? Вы же вызываете их и опираетесь на них? А значит у вас все приложение — одна большая модель?))))))))))

>Ну да, глобалы рулят :)

Ух как все запущено))). Я про глобалы не говорил и даже не вспомнил про них. Я больше про рефлексию, например).

>У меня большинство задач решается контроллерами и я не парюсь, взять стул, машину или кровать :)
>Я говорю, возьми и сделай.

Ну, в принципе, это видно. Как по комментариям, так и по коду ;). Но например я не готов ехать в другой город на стуле, спать на машине и т.д. И да, у вас не контроллерами решаются задачи, а как-раз виджетами. Контроллер у вас всегда один — index.php ;)

>И статику кто вызывает? Фреймворк. Значит деплоер должен подсунуть ему эту информацию.

Чего?!?! Фреймворк вызывает статику?! Или все-таки приложение? Таким темпом можно дойти до того, что статику вызывает операционка и все операционки = зло)))))))

>Но деплоеры используются на более сложных проектах (как и упомянутый выше gulp).

А на простых кешировать статику не имеет смысла. Хватит кеша в браузере + get-параметр.

>У меня поддержка на уровне ядра.

И это минус. Чтобы поправить хедер — мне править ядро? Бред…

>А любые сторонние «компоненты» будут выпадать из этого функционала.

Серьезно?)))))))))))))))))

>Допустим перевода на русский нету, тогда используем переводы в порядке наличия из языков фоллбеков: украинский, английский.

Ух какая сложная задача))) Lang::get($string); Остальное на уровне конфига)))))

>То есть Вы все таки будете дописывать ко всем файлам filemtime вместо деплоера? :)

Я? Нет конечно). Я отвечал на вашу задачу ;). Но, вы не показали, как это проще сделать на вашем фреймворке))))

>Я имею в виду какую задачу реализовывать.

Пофиг. Вывод данных из файла на страницу — подойдет? Обработку json/xml? Работу с бд? Без разницы, в общем.

>Меню? О, да.

Именно так. Меню — это дизайн+верстка, а не код. И меню нафиг не нужно в фреймворке. Не согласны? Покажите код, который сделает меню как на хабре, например. Или как на zolotorevich.com. Чего будет больше — кода или стилей?)

>Разработка → PHP: неправильный путь :)

Это заголовок поста. Не вижу в нем ссылки на индекс например). Или для вас любая ссылка со стрелкой — это хлебные крошки?)) aktuba.com — такой-же стиль заголовка, но в помине нет никаких хлебных крошек ;)

Вклинюсь в обсуждение. На тему index.php, это не что ино как шаблон проектирования Front Controller.


@aktuba советую не увликатся холиваром. Макс не адекватен и осознавать этого не хочет. Не ты первый пытаешся направить его на путь истинный

Не-не-не, я в курсе: https://habrahabr.ru/company/mailru/blog/308788/?reply_to=9786794#comment_9785022 ;)
Но пятница-же была, хотелось поразвлекаться и посмотреть на реакцию)
Сочувствую). Но тут зависит от программиста, фреймворк не принуждает ;)

Вот в первую очередь из-за дебилов у меня такое отношение к фреймворкам.
Говорят, фреймворк дисциплинирует, все пишите на фреймворках.
А нифига. Это только привело говнокодеров.

И чем это отличается от вызова функции рендера?))))

Но это не функция рендера.

Тогда нафига авторендер?))

Чтобы не заморачиваться рендерингом. :)

И нафига они тогда в фреймворке?)))

Чтобы все сторонние решения имели один интерфейс для добавления пунктов меню и хлебных крошек. А не как вздумается разработчику…
Потом налеплять говна и разбирайся с ним.

в некоторых фреймворках виджет может содержать контроллеры, модели, вьюхи.

На самом деле это лишняя сущность.
Выходит каша. Фиг поймешь, где что искать.

Пруф?)))

Зачем пруф? Это разве не ясно, что виджеты пятое колесо? А все из-за того что в неверном понимании MVC возможен вызов только одного контроллера.

Для большинства разработчиков, index.php — это некий лоадер приложений

Но по сути это контроллер.
Ведь туда поступает запрос.

Получается, любая php-функция — это часть модели, верно?

Это Вы слишком далеко копнули.

Именно так. Меню — это дизайн+верстка, а не код.

Я не о html+css, а интерфейсе для построения массива пунктов меню…

Ясен-красен, что каждый будет использовать свой шаблон :)

Это заголовок поста.

По сути это хлебные крошки, так как показывает иерархию.
>Чтобы все сторонние решения имели один интерфейс для добавления пунктов меню и хлебных крошек. А не как вздумается разработчику…

Которые нахрен никому не нужны)))

>На самом деле это лишняя сущность.

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

>Выходит каша. Фиг поймешь, где что искать.

))))) Жесть…

>Зачем пруф? Это разве не ясно, что виджеты пятое колесо? А все из-за того что в неверном понимании MVC возможен вызов только одного контроллера.

Затем, что несете полную ахинею). Все время говорите о неверном понимании mvc, но вам уже человек 100 сказали, что:
а) неверное понимание именно у вас
б) mvc — не единственный паттерн, да к тому-же не самый удобный (hmvc, mvvm иногда намного удобнее)
в) у вас тоже вызывается только 1 «контроллер» — index.php, в котором вы вызываете виджеты (которые называете почему-то контроллерами).

Итог — путаете сами себя и выставляете себя на смех публике.

>Но по сути это контроллер.
>Ведь туда поступает запрос.

Тогда и nginx является контроллером приложения, верно? Или все-таки нет? Если нет — почему? «Ведь туда поступает запрос.»?)))))
Снова у вас каша в голове, но вы никак не хотите это признавать. Ок, предположим что index.php у вас контроллер. Тогда с чего ваши «виджеты-контроллеры» стали «контроллерами»? В них ведь запрос не поступает — они получают данные от index.php. Значит они не контроллеры, а именно виджеты. Вернулись к исходной точке — у вас 1 контроллер и куча виджетов…

>Это Вы слишком далеко копнули.

Возможно, но разве я не прав? Вы же сами привели это утверждение ;)

>а интерфейсе для построения массива пунктов меню…

А нафиг он нужен?))) Ну а уж если очень-очень нужен — берем composer и подключаем любой удобный (например: https://github.com/tedslittlerobot/menu-builder). И снова вопрос — нафига во фреймворк запихивать то, что там не должно быть? То-же самое касается работы со статикой, с внешними сервисами, с почтой и пр.

>По сути это хлебные крошки, так как показывает иерархию.

))) Нет. Иерархия может быть такая: индекс-раздел1-подраздел2-подподраздел3, а выводиться будет
а) раздел1 — заголовок
б) подраздел2 — заголовок
в) подподраздел3 — заголовок

во всех 3х случаях иерархия нарушена и заголовок является просто заголовком.
Вообще, хлебные крошки — пережиток прошлого, нужный был для seo, от которого уже почти все отказались. И хвалиться что это говно запихали в ядро, как минимум, странно.

>Хотите — плодите сущности. Я в этом смыла не вижу.

))) говорит человек, который запихивает в ядро(!!!) атрибуты cms…

>То есть у Вас по коду раскиданы голые подключения скриптов

Иногда да, иногда нет. requirejs, assets вам в помощь. Фреймворк вообще не должен знать о наличии/отсутствие какой-то там статики.

>Так я как раз о гет-параметре и говорю. Чтобы его не вручную менять, а он сам менялся и не парится.

Так я и не парюсь, но ни одному здравому человеку не придет в голову перекладывать эту задачу на фреймворк).

>304 ответ. Зачем его править?

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

>Вы как узнаете, что страничка не изменилась?

Расшифруйте вопрос.

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

Да, возможно ваш собственный фреймворк подходит под какие-то простейшие задачи (типа блога с меню и хлебными крошками))), но он точно не подойдет под что-то более-менее приличное. Я уверен, что на нем будет сложно сделать даже реалтайм-чатик, не говоря уже о каких-либо соц.сервисах. Например, сейчас я занимаюсь задачей рекомендаций пользователям определенного контента. Используемый инструментарий: nginx, php, mongodb, rabbitmq, redis. Может-ли ваш фреймворк мне чем-то помочь? Очевидно — нет. А любой(!!!) адекватный фреймворк сможет — есть готовые библиотеки для монги/mq/redis.

Но даже для простейших задач вида бложика использовать ваш фреймворк бессмыслено — проще взять готовую cms (практически любую) и вообще не задумываться о всяких меню и хлебных крошках)))

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

P.S.: чуть не забыл — 50кб как-то много для такого «фреймворка», как у вас. Практически уверен, что его можно описать десятком строк в composer.json и тогда получится примерно 1кб ;)
Ого ответили :)

>Которые нахрен никому не нужны)))
Ну ок. Будем велосипедить. Зачем тогда фреймворки? :)

Ответьте на https://habrahabr.ru/company/mailru/blog/308788/#comment_9787704
:)

> Не согласен. Лишняя сущность — это хлебные крошки, например.

Она кушать не просит. Не хочешь — не пользуйся. :) Это просто методы для добавления / получения пунктов.

> А виджеты — полезный инструмент.

Но и дополнительная сущность. Из-за того, что контроллеры предполагается использовать только 1 раз.

>))))) Жесть…

А разве нет?
MVC во фреймворке, отдельно MVC в виджетах, хотя это можно совместить.

>Затем, что несете полную ахинею).

Пруф, что виджеты — лишние и это пятое колесо?
А у Вас своего мнения нету и мозгов?
Да и вряд ли такое будет написано где-то, все придерживаются генеральной линии партии.
Да и смысл, что будет написано против? Вон создатель PHP говорит, что мейнстримовые фреймворки не совсем гуд, это ж не останавливает фреймворкопоклонников :)

>неверное понимание именно у вас

https://ru.wikipedia.org/wiki/Model-View-Controller

«Model-view-controller (MVC, «модель-представление-контроллер», «модель-вид-контроллер») — схема использования нескольких шаблонов проектирования, с помощью которых модель приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента таким образом»

«Начинающие программисты (особенно в веб-программировании, где аббревиатура «MVC» стала популярна) очень часто трактуют архитектурную модель MVC как пассивную модель MVC: модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику.»

На самом деле это не что-то особенное, а здравый смысл разделить код на уровни.

>mvc — не единственный паттерн, да к тому-же не самый удобный (hmvc, mvvm иногда намного удобнее

Я даже не о паттерне говорю, а о самом подходе к разделению кода. Все остальные подходы, это развитие.

>у вас тоже вызывается только 1 «контроллер» — index.php, в котором вы вызываете виджеты (которые называете почему-то контроллерами).

Что Вы пристали ко мне с 1 «контроллер» — index.php?
Вам сторонний человек с лагеря фреймворков указал, что Вы ошибаетесь.

>Итог — путаете сами себя

Я как раз не путаюсь в своем коде.
А фреймворки путают своими сущностями.

> выставляете себя на смех публике

О боже, напугали. :)

>Тогда и nginx является контроллером приложения, верно? Или все-таки нет? Если нет — почему? «Ведь туда поступает запрос.»?)))))

Если все делить на 3 из MVC и смотреть широко, то да.
Кстати, в nginx можно писать логику, чтобы не поднимать каждый раз приложение: memcached | lua
Есть приложения сами себе сервера.
Даже php может быть сервером.

>Тогда с чего ваши «виджеты-контроллеры» стали «контроллерами»? В них ведь запрос не поступает — они получают данные от index.php. Значит они не контроллеры, а именно виджеты. Вернулись к исходной точке — у вас 1 контроллер и куча виджетов…

Это Вы хотите меня говном обмазать. :)
Контроллер может вызывать другой контроллер.
Это есть и в фреймворках, но не афишируется.

>Возможно, но разве я не прав? Вы же сами привели это утверждение ;)

Я имел в виду исходники приложения в *.php
Если доводить до абсурда, то нужно говорить, что php без ОС работать не может :)

>Ну а уж если очень-очень нужен — берем composer и подключаем любой удобный

Тогда будет зоопарк.

>То-же самое касается работы со статикой, с внешними сервисами, с почтой и пр.

Пихать поддержку АПИ внешних сервисов глупо и никто этого не требует.

>пережиток прошлого, нужный был для seo, от которого уже почти все отказались

И сейчас нужен, даже микроформаты для облегчения понимания ПС для этого вышли.
И прежде всего нужно думать обо удобстве пользователей, а не ПС.

>))) говорит человек, который запихивает в ядро(!!!) атрибуты cms…

Линукс тоже имеет монолитное ядро.
Это можно вынести в модуль ядра, не важно. Важен факт, что это из коробки.

>Иногда да

А, ну тогда ок. Аргументов больше не имею, если Вас все устраивает :)

>Так я и не парюсь, но ни одному здравому человеку не придет в голову перекладывать эту задачу на фреймворк).

Пользователи получают устаревшую / сломанную закешированную версию. Ну ок :)
Это не настолько трудно реализовать.

По факту выходит, что фреймворки имеют кучу 3-этажных абстракций, которые непойми как работают, но, по сути, никаких задач не решает, не предлагает стандартизации, чтобы не было велосипедостроения.
Фреймворки возникли якобы, чтобы не писать велосипедов, но они продолжают писаться на них.

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

Можно подписаться на событие… :)

>Расшифруйте вопрос.

Страничка собирается на основе ответов из кода разных поставщиков.
Как узнать, что это та самая страничка, что пользователь получил в прошлый раз? :)

>В целом понятно, что вы просто уперлись и не хотите даже думать.

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

Но за дискуссию спасибо.

Я ни кому не рекомендую использовать мою самопись:
http://blog.kpitv.net/article/когда-будет-публичный-релиз-ядра-15373/
Просто говорю, что многие вещи реализовать легче на самописи, нежели на фреймворке.
Код, по сути, писать нужно и там, и там.
Кто совсем не хочет велосипедов — тому использовать типичные решения.

>Но выставлять себя на смех как-то глупо.
Та смейтесь, смех продлевает жизнь :)

>считаете, что сторонние библиотеки априори зло
Я такого никогда не говорил. Я выступаю с другой точкой зрения…

>но он точно не подойдет под что-то более-менее приличное
Я не говорю, что мое ядро так сходу и подходит и никого не заставляю им пользоваться. Но по крайней мере с меню и хлебными крошками париться не нужно.
Но и фреймворки сходу не подходят.
Разница в том, что свой код можно легко оптимизировать под задачу, а фреймворк придется подпирать костылями, чтобы он не упал на велосипед, на котором мы объезжаем в том числе и подводные камни:
https://yandex.ua/images/search?text=%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0%20php%20%D0%B2%D0%B5%D0%BB%D0%BE%D1%81%D0%B8%D0%BF%D0%B5%D0%B4%20%D0%BA%D0%BE%D1%81%D1%82%D1%8B%D0%BB%D0%B8

>Я уверен, что на нем будет сложно сделать даже реалтайм-чатик

Вряд ли его нужно делать и на php-фреймворке.
Но вообще, а в чем трудность отвечать на запросы пользователей?

>не говоря уже о каких-либо соц.сервисах

Соцсети предоставляют сильно обрезанные возможности

>Например, сейчас я занимаюсь задачей рекомендаций пользователям определенного контента.

Пользователь запрашивает такую рекомендацию? Каким образом? Просто например в ФБ эти рекомендации накрученные самим ВБ :)

>Используемый инструментарий: nginx, php, mongodb, rabbitmq, redis. Может-ли ваш фреймворк мне чем-то помочь? Очевидно — нет.
Такие технологии не представлены в ядре (модулях ядра) (об этом написано по ссылке почему я никому не предлагаю свое ядро). И у меня не фреймворк. А просто ядро.

Но это можно реализовать сторонним кодом в случае необходимости.

У ядра будете просить только конфиги и чтобы оно строило ключи для кеша редиса (если это необходимо).
mongodb будет использовать sql-интерфейс? Если да, то, к сожалению, модуль ядра для БД писался под mysql, хотя, вроде, никакие сугубо mysql фичи не использует. Ну или сторонним модулем.

mongodb вроде раньше плохо себя чувствовала при на большиой базе. Почему не РСУБД?

>Но даже для простейших задач вида бложика использовать ваш фреймворк бессмыслено — проще взять готовую cms (практически любую) и вообще не задумываться о всяких меню и хлебных крошках)))

Для ерунды, которую не нужно кастомизировать, согласен, я об этом и пишу.

>Мой вывод — вам еще развиваться и развиваться.

Я больше скажу, всем есть куда развиваться. :)

>Надеюсь, мой небольшой троллинг даст понять

А-ха-ха. Тролль троллит тролля. :) (Но я себя троллем не считаю)

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

Ну да, и используется теми, кто сам не может реализовать архитектуру, об этом тоже сказано в статье :)

>Практически уверен, что его можно описать десятком строк в composer.json и тогда получится примерно 1кб ;)

С таким подходом код вообще писать не нужно.
Подключаешь composer и получашь кнопку «Сделать все хорошо».
Только этот код должен кто-то в composer положить. :)
Да и разбираться с этим зоопарком дольше, чем самому написать.

По неоткомментированному утверждению из предыдущего комментария:
А на фреймворке пишут говнокод или только радугу?
Зависит ли говнокодистость больше от самого разработчика, нежели от того, на чем он пишет?
Просто о PHP сложилось мнение, что это язык говнокодеров. Хотя на нем пишут и нормальные программисты.
>Ого ответили :)

Ну в выходные у меня есть занятия поинтереснее)

>Ну ок. Будем велосипедить. Зачем тогда фреймворки? :)

Ну так вы и велосипедите ;). А фреймворки нужны чтобы уменьшать время на разработку, делать разработку удобнее и комфортнее.

>Ответьте на https://habrahabr.ru/company/mailru/blog/308788/#comment_9787704

А смысл? Вы в упор не хотите понимать, что говорите глупость. В том комментарии тоже. Наличие/отсутствие каких-либо фич не делает фреймворк лучше или хуже. А вот отсутствие возможности удобно подключать расширения — делает фреймворк ущербным. Если в вашем фреймворке я не могу использовать одновременно несколько баз данных, не могу подключить любую библиотеку с помощью composer — ваш фреймворк ущербен. И никакие cms-фишки не помогут.

>Она кушать не просит. Не хочешь — не пользуйся. :) Это просто методы для добавления / получения пунктов.

А, т.е. если лишняя сущность «кушать не просит» — она хорошая?))) Чем тогда виджеты не угодили — они «кушать непрост» ;)))))

>Но и дополнительная сущность. Из-за того, что контроллеры предполагается использовать только 1 раз.

Мдя, запущено больше чем я думал))) Как связаны виджеты и контроллеры? Это абсолютно разные вещи, не зависящие друг от друга. К вашему фреймворку так-же можно привязать виджеты ;) И да, «кушать не просят» ;)

>MVC во фреймворке, отдельно MVC в виджетах, хотя это можно совместить.

Вы реально не собираетесь думать? Еще раз — виджет никак не связан ни с архитектурой приложения, ни с контроллерами. Зачем их совмещать?! Они для разных целей, абсолютно разный инструмент…
Зачем вам, при таком подходе, модели и вьюхи? Можно-же в контроллере все делать ;)

>Пруф, что виджеты — лишние и это пятое колесо?
>А у Вас своего мнения нету и мозгов?

Да у меня есть, потому и говорю — думать полезно ;). И если подумать — можно понять, что виджеты/плагины/компоненты/библиотеки — это инструменты. Местами полезные, местами необходимые. Вы вон тоже ими пользуетесь, хотя называете их контроллерами)))))))

>На самом деле это не что-то особенное, а здравый смысл разделить код на уровни.

И где, по вашему, не правильно воспринимают mvc разработчики фреймворков?))) В вашей выдержке что-то не увидел ничего похожего. Более того, вы как-то удобно исключили из цитирования фрагмент чуть ниже:

>>Контроллеры же, — как элементы информационной системы, — ответственны лишь за:
>>Приём запроса от пользователя;
>>Анализ запроса;
>>Выбор следующего действия системы, соответственно результатам анализа (например, передача запроса другим элементам системы);

Заметьте, все фреймворки удовлетворяют этим требованиям. Так что не так тогда с фреймворками?)))) И где «неверное понимание mvc»?)))

>Вам сторонний человек с лагеря фреймворков указал, что Вы ошибаетесь.

Нет, он указал на паттерн проектирования (http://design-pattern.ru/patterns/front-controller.html). А мы говорим о конкретно вашей реализации, в которой только 1 контроллер и куча виджетов ;)

>Я как раз не путаюсь в своем коде.
>А фреймворки путают своими сущностями.

Т.е. вы просто не смогли освоить фреймворки?)))) Меня вот они не путают никак.

>Если все делить на 3 из MVC и смотреть широко, то да.
>Кстати, в nginx можно писать логику, чтобы не поднимать каждый раз приложение: memcached | lua

Ну вот, наконец-то… Получается, у вас вообще нет контроллеров?!))) Про nginx знаю и намного больше ;)

>Это Вы хотите меня говном обмазать. :)
>Контроллер может вызывать другой контроллер.

Да ни в коем случае! Но вы прямо напрашиваетесь))).

>Это есть и в фреймворках, но не афишируется.

Мы вроде это уже обсуждали) Вот простой пример, как это сделать в любом фреймворке: $newController = new \Frontend\Controller($this-getDI()); Но это глупость и бред. Контроллер должен быть только 1 и он ответственный за прием запроса и отдачу ответа. А в данном примере созданный контроллер используется в виде виджета ;)

>Я имел в виду исходники приложения в *.php

Предположим, есть кеш-файл (шаблона, данный — не важно) cache.php. По вашей логике — это модель. Правильно я понял?))))

>Тогда будет зоопарк.

Ахахаха… Тогда будет комфорт и удобство. Но по вашей логике — это очень-очень плохо)))))

>Пихать поддержку АПИ внешних сервисов глупо и никто этого не требует.

А чем это отличается от хлебных крошек?))) Это-же все-лишь методы. «Кушать не просят» ;). Но в случае с хлебными крошками, по вашему мнению, необходимо пихать в ядро фреймворка, а апи сервисов нет. Почему такая двойственность?))))

>Линукс тоже имеет монолитное ядро.
>Это можно вынести в модуль ядра, не важно.

И при чем тут линукс?)) Вообще, при чем тут монолит/микроархитектура? Вроде как говорили про конкретную реализацию — ваш фреймворк.

>Важен факт, что это из коробки.

Так и в других фреймворках «из коробки». И коробка называется composer.json ;) При этом, кому не надо — у того нет этого г… на)

>А, ну тогда ок. Аргументов больше не имею, если Вас все устраивает :)

Абсолютно! Реализация зависит от задачи, а не наоборот. Соответственно, если мне надо подключить 1 файл, который не будет меняться — налива мне управление статикой?))

>Пользователи получают устаревшую / сломанную закешированную версию. Ну ок :)
>Это не настолько трудно реализовать.

Как обычно — какой-то глупый вывод)))). composer.json -> assets — и пользователи не мучаются. И фреймворк не содержит лишнего говна. И мне не надо ничего реализовывать. Советую начать думать и только потом делать выводы ;)

>По факту выходит, что фреймворки имеют кучу 3-этажных абстракций, которые непойми как работают, но, по сути, никаких задач не решает, не предлагает стандартизации, чтобы не было велосипедостроения.

))))))). «Не пойми как работают»?! «Никаких задач не решают»?! Вы просто не смогли освоить даже один? Для меня phalconphp решает кучу задач — от производительности, до разделения приложения на микросервисы. И это не говоря об удобной работе с любыми базами данных, серверами очередей, серверами сообщений, фоновых обработчиков и пр. А что решает ваш фреймворк? Добавляет возможность вставить хлебные крошки и меню?!)))))))))))))))))))

>Можно подписаться на событие… :)

Можно. А можно наследоваться и переделать реализацию. Например, чтобы в апи отдавался 1 заголовок, в веб другой, в cli третий. И каждый вариант содержит свой логгер. И этот вариант будет проще поддерживать и отлаживать, чем вариант с событиями. Не говоря уже о том, что события иногда вообще вредны.

>Страничка собирается на основе ответов из кода разных поставщиков.
>Как узнать, что это та самая страничка, что пользователь получил в прошлый раз? :)

Именно для этого и нужен контроллер — единая точка, которая собирает всю информацию и на основе ее формирует ответ ;) Что будете делать, если у вас 3-4 виджета отправят этот заголовок с разными параметрами? Это-же отдельные контроллеры, которые могут получать запрос непосредственно от пользователя или от другого контроллера? Значит есть вероятность, что каждый из таких контроллеров-виджетов может отправлять заголовки сам, верно?))))))

>Плюсы фреймворков не перевешивают их минусов для меня. :)
>И прежде всего с позиции разработчика, который пишет код для себя (о чем и сказано в статье)

Вам уже сотня людей сказала, что вы не назвали минусов фреймворков ;). Все, что вы говорите — «я не разобрался — значит это плохо»)))).

>Просто говорю, что многие вещи реализовать легче на самописи, нежели на фреймворке.

Блин, 4-й раз прошу пример, когда реализовать что-то на самописе будет проще, занимать меньше кода, работать быстрее, чем на фреймворке. Дайте уже хоть какой-то адекватный пример!

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

Не поверите — с ними никто и не парится)))

>Разница в том, что свой код можно легко оптимизировать под задачу, а фреймворк придется подпирать костылями, чтобы он не упал на велосипед

Хахахахахаха… Т.е., по вашему, фреймворк — это что-то магическое?! Почему можно в одном месте подправить, а в другом нет?))))) И как обычно — пруф какой-нибудь дайте. А то звучит как полный бред.

>Вряд ли его нужно делать и на php-фреймворке.

Вряд-ли, но сделать легко.

>Но вообще, а в чем трудность отвечать на запросы пользователей?

Принять запрос от пользователя, отдать всем «подписавшимся» на канал, блокировать отправку устаревших и пр. Как-минимум, что-то наподобие redis сильно облегчит разработку, но ваш фреймворк его просто не поддерживает. И использовать стороннюю реализацию в вашем случае накладно. Вот в этом и трудность вашего фреймворка.

>Пользователь запрашивает такую рекомендацию? Каким образом? Просто например в ФБ эти рекомендации накрученные самим ВБ :)

Да, запрашивают. Каким образом запрашивают?)) Разным — ajax-запрос, запрос к апи, etc.

>Но это можно реализовать сторонним кодом в случае необходимости.

Так получится-же зоопарк)))). Так вот для фреймворков, чаще всего, уже есть удобные, проверенные временем и пользователями, модули, которые надо просто подключить и использовать. В вашем варианте — надо велосипедничать)

>mongodb вроде раньше плохо себя чувствовала при на большиой базе. Почему не РСУБД?

Потому что рсубд чувствует себя еще хуже при частом удалении данных ;). А откуда информация, что монга не справляется с большим количеством данных?)) По работе используем монгу, вес базы под террабайт, есть коллекции с сотнями миллионов записей. Чувствует себя отлично)

>Для ерунды, которую не нужно кастомизировать, согласен, я об этом и пишу.

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

>Ну да, и используется теми, кто сам не может реализовать архитектуру, об этом тоже сказано в статье :)

Блин, как-раз в точности наоборот! Кто может реализовать архитектуру (а не структуру) — использует фреймворки, они очень сильно экономят силы и время ;)

>Да и разбираться с этим зоопарком дольше, чем самому написать.

)))) Серьезно?! Попробуйте написать адекватную библиотеку для работы с монгой ;). Мне даже интересно, сколько это времени займет. Желательно, чтобы можно было делать подобные вещи:

$user = new User;
$user->username = 'username';
$user->save();

$users = Users::get()->findBy(['username' => 'username'], ['sort' => ['lastLogin' => 'desc']]);

Сделайте и покажите, очень интересно ;)

>Зависит ли говнокодистость больше от самого разработчика, нежели от того, на чем он пишет?

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

>Просто о PHP сложилось мнение, что это язык говнокодеров. Хотя на нем пишут и нормальные программисты.

И они пишут на фреймворках, кстати ;)

P.S.: на этом дискуссию закрываем. Выходные закончились)
>Ну так вы и велосипедите ;).

А Вы нет? С тем же меню :)

>А фреймворки нужны чтобы уменьшать время на разработку, делать разработку удобнее и комфортнее.

Ну да. Только хотя бы не усложняли. :)
Это примерно как государство. Оно якобы призвано заботиться о людях, а по факту от него, наверное, больше проблем :)

>Наличие/отсутствие каких-либо фич не делает фреймворк лучше или хуже.

То есть все фреймворки одинаковы? Ведь все они дают возможность удобно подключать расширения.

>Если в вашем фреймворке я не могу использовать одновременно несколько баз данных

Можете, но построитель запросов расчитан на mysql. Кто хочет, переопределяйте методы :)
Да и кто использует сразу 100500 баз? А еще говорят о легкости миграции на другую БД.

Хрен там легко мигрировать, если использованы фишки определенной базы.

>не могу подключить любую библиотеку с помощью composer — ваш фреймворк ущербен.

Подключаете композер и все :) Или что может случится? :)

>И никакие cms-фишки не помогут.

Ну кому что нужно :)

>А, т.е. если лишняя сущность «кушать не просит» — она хорошая?)))

Это даже не обязательно сущность (то есть такого класса может и не быть). Просто пару методов, грубо говоря, наполняющих массив. :)

>Чем тогда виджеты не угодили — они «кушать непрост» ;)))))

Они пятое колесо. Но приходится их использовать.

>Это абсолютно разные вещи, не зависящие друг от друга.

Ну да, разные, но дублирующие друг друга.

>К вашему фреймворку так-же можно привязать виджеты

Их не нужно привязывать, уже есть многоразовые контролеры.

>виджет никак не связан ни с архитектурой приложения

Они типа государство в государстве? :)

>Они для разных целей, абсолютно разный инструмент…

У меня вышло совместить. :)
Опишите, для каких таких разных целей они.

>Зачем вам, при таком подходе, модели и вьюхи? Можно-же в контроллере все делать ;)

Не-не-не. То что не нужно плодить сущности, не значит, что нужно оставить только одну сущность. :)

>виджеты/плагины/компоненты/библиотеки — это инструменты.

Виджет — это инструмент-дубль уровня фреймворка. Он не привносит ничего нового по сравнению с контроллер+вид, это тот же контроллер+вид, названный по другому.

Для меня важна суть:
«MVC — модель приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента»

Фреймворки пропагандируют вместо жирных контроллеров жирные модели в одном классе с сущностью и хождением в базу. Модель (бизнес-логика) не должна быть привязана к какой-то одной сущности.

И ничего плохого в жирном контроллере нет, если этот код нигде не дублируется.
В контроллере можно вызывать разные сущности.

>Более того, вы как-то удобно исключили из цитирования фрагмент чуть ниже:

Я и так много нацитировал. :)

>А мы говорим о конкретно вашей реализации, в которой только 1 контроллер и куча виджетов ;)

Так как в понимании фреймворков не стоит выполнять больше одного контроллера, то с точки зрения фреймворка это выглядит так:
точка входа / фронт-контроллер (index.php) вызывает т. н. главный контроллер-виджет
главный контроллер-виджет и его шаблон может вызывать вспомагательные контроллеры-виджеты.

>Получается, у вас вообще нет контроллеров?!)))

Почему Вы так хотите лишить меня контроллеров и обмазать виджетами? :)

>Но это глупость и бред.

Но часто без этого никак.
А еще их не хотят использовать из-за того, что их запуск слишком ресурсоемкий. У меня с этим все норм. 50 кБ, как никак :)

>А в данном примере созданный контроллер используется в виде виджета ;)

Ну да. То есть виджеты можно легко удалить.

>Предположим, есть кеш-файл (шаблона, данный — не важно) cache.php. По вашей логике — это модель. Правильно я понял?))))

Разумнее это рассматривать тем, кешом чего это является. Если некоторый шаблон используется повторно — это не делает его моделью. Если некоторый контроллер-виджет вызывается на нескольких страницах — он не станет от этого моделью. Это уровень выше.

>Ахахаха… Тогда будет комфорт и удобство. Но по вашей логике — это очень-очень плохо)))))

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

>А чем это отличается от хлебных крошек?))) Это-же все-лишь методы. «Кушать не просят» ;). Но в случае с хлебными крошками, по вашему мнению, необходимо пихать в ядро фреймворка, а апи сервисов нет. Почему такая двойственность?))))

Хлебные крошки одни, а сервисов много.
Хлебные крошки нужны большему количеству поьзователей.
Не обязательно в ядро. Можно в подключаемый по необходимости модуль ядра (поставщика фреймворка), чтобы не было 100500 конкурирующих стандартов, каждый из которых пытался выступить единым стандартом :)
Кстати, я не сторонник мапить апи сервиса один в один. Считаю это псевдопрограммированием. Достаточно удобной обертки над curl.

>И при чем тут линукс?)) Вообще, при чем тут монолит/микроархитектура? Вроде как говорили про конкретную реализацию — ваш фреймворк.

Вы говорите, будто иметь что-то в ядре это плохо. Вот Линукс имеет. Интересно было что Вы сможете возразить или промолчите.

>composer.json -> assets

Ну ясно, что свято место пусто не бывает :)
У конкурирующих реализаций интерфейсы совместимы?

>И фреймворк не содержит лишнего говна.

Это можно держать в модуле ядра (поставщика фреймворка). Главное, чтобы не было 100500 конкурирующих несовместимых решений и ни одно из них не принято стандартом по умолчанию.

>И мне не надо ничего реализовывать.

Вы выше говорили, что подключаете статику через плейн-html.
А то разработчики понаподключают так ресурсы, что возможны повторные поключения тех же библиотек js, что чревато неработоспособностью.

>Для меня phalconphp решает кучу задач — от производительности, до разделения приложения на микросервисы. И это не говоря об удобной работе с любыми базами данных, серверами очередей, серверами сообщений, фоновых обработчиков и пр.

Не знаю на сколько он удобный, не щупал.
А в чем трудность разделить приложение на микросервисы?
И в чем такая необходимость?

>А что решает ваш фреймворк? Добавляет возможность вставить хлебные крошки и меню?!)))))))))))))))))))

Вы ж говорили, не в фишках дело :)

>А можно наследоваться и переделать реализацию. Например, чтобы в апи отдавался 1 заголовок, в веб другой, в cli третий. И каждый вариант содержит свой логгер. И этот вариант будет проще поддерживать и отлаживать, чем вариант с событиями. Не говоря уже о том, что события иногда вообще вредны.

Можно.
Но некоторые тру-фреймоворкоюзатели говорят, что наследование — зло. Но оно тоже имеет право на жизнь. Нужно смотреть, как удобнее решить задачу.
События как бы дают большую гарантию, что вы не разъедетесь с тем, на события кого подписаны. Но да, для них нужно заложить возможность.
Наследование может привести к тому, что вы разъедетесь с тем, кого наследовали.
То есть: вам нужно выполнить ровно то же, что и родитель + еще что-то. Кмк для этого нужно вызывать parent::bla_bla_bla(). Но parent::bla_bla_bla() может так измениться, что что-то сломается из-за последующего вызова кода наследника.

>Вам уже сотня людей сказала, что вы не назвали минусов фреймворков ;). Все, что вы говорите — «я не разобрался — значит это плохо»)))).

Там дебильное MVC и работа с базой.
Мне, возможно, более подойдут микрофреймворки. Но переделывать все, ради того, что это было на фреймворке «как у всех» смысла не вижу.
Ну и другие причины, о которых сказано в статье.

>Блин, 4-й раз прошу пример, когда реализовать что-то на самописе будет проще, занимать меньше кода, работать быстрее, чем на фреймворке.

Уже отвечал, но еще раз.
Как раз 4 примера на каждый запрос :):
«Отсутствие единого интерфейса для построения массива пунктов меню, хлебных крошек.
Отсутствие единого интерфейса для возможности отдачи 304 ответа (header($_SERVER['SERVER_PROTOCOL'].' 304 Not Modified'); мы-то послать может. Но нужно знать, что страница действительно не изменилась).
Отсутствуют языки-фоллбеки для переводов определенного языка.
Пример: перевода на русский нету, тогда используем переводы в порядке наличия из языков-фоллбеков: украинский, английский.
У добавленных цсс/жс файлов нету признака, что файл изменился.»

Остального нету под рукой. Но статья постоянно обновляется, следите за новостями :)

>Не поверите — с ними никто и не парится)))

Значит у вас нету сторонних решений.

>Почему можно в одном месте подправить, а в другом нет?

Вы правите код фреймворка? Да, его можно в git положить, но у многих git-а нету. Да и вряд ли с композером это прокатит. Сидеть и потом выискивать изменения и накатывать? :)

>Как-минимум, что-то наподобие redis сильно облегчит разработку, но ваш фреймворк его просто не поддерживает. И использовать стороннюю реализацию в вашем случае накладно.

Совсем не накладно.
Сторонние реализации как раз приветствуются.

>Да, запрашивают.

А что Вы рекомендуете, может и мне будет интересно и остальным пользователям. Статья будет? :)

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

Если есть 1, который принят как стандарт де-факто, то я не против.

>В вашем варианте — надо велосипедничать)

Подключайте так само и используйте.

>По работе используем монгу, вес базы под террабайт. Чувствует себя отлично)

Значит информация устаревшая и пофиксили.

>Даже если есть что кастомизировать — я буду юзать cms. Будь это wp или modx — кастомизировать их проще, т.к. огромное количество готовых модулей.

Часто эти модули дают о себе знать значительным падением производителности и они дырявые, но то такое.
А если нету модуля, который кастомизирует так, как нужно?

Хотя доводилось работать больше 3-ех лет с Битриксом. Можно использовать. Печально то, что разработчики не прислушиваются к пользователям, а также некоторые кострубатости АПИ.

Когда по Вашему стоит завязывать с кастомизацией CMS и переходить на фреймворк? Или все же лучше не переходить на фреймворк вообще? Ведь на фреймворке велосипедить нужно больше, чем на CMS.

>Попробуйте написать адекватную библиотеку для работы с монгой ;).

Я с ней не работал.
Там есть SQL-интерфейс?

>$users = Users::get()->findBy(['username' => 'username'], ['sort' => ['lastLogin' => 'desc']]);

Сортировка/группировка/джойны на клиенте?

Но если Вы с ней только из-за того, что у РСУБД проблемы с удалением, то возможно уже таких проблем у mysql 5.6.что-то+ (и форках) нет:
http://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html#innodb-online-ddl-summary-grid

Помечаем элементы удаленными, ночью удаляем, и запускаем ALTER TABLE… ENGINE=INNODB, который якобы стал неблокирующим.
Ну и можно использовать партиционирование. По непроверенной информации дает ощутимый прирост.

>Если он говнокодит на фреймворке — он будет развиваться и меняться в лучшую сторону, т.к. постоянно видит правильные и удобные реализации.

Просто на всех работах на фреймворках был говнокод :)
Даже хотя бы не то, что не говнокодили, а отступы не прыгали туда-сюда. Исправишь все, а завтра опять придет в репозиторий то самое. :)
Ну или говоришь такой старшему разработчику, зачем здесь такие костыли, зачем ты лезешь в хату через окно, если можно через двери? А он типа: я спешил, пусть будут.
А чтобы использовать эти костыли приходится брать еще одни костыли (тем окном пользуется тимлидов код, другим окном мой код залазит в тимлидов, так как на балконе установили окна :) ).
Ну или говоришь такой на ИС: какой баран (я человек прямой, людей баранами называю не просто так, а за дела, не с целью обидеть, и себя тоже иногда) тут виджет влепил, который делает примерно такое: echo '<table>дальше пошла таблица'.
А он такой: я, на нашем фреймворке по другому сделать нельзя, это сделано потому что что-то там нельзя разместить выше по коду, и вообще, мне обидно. :) Ну а потом ты досрочно не проходишь ИС.
Ну или говорит такой тимлид: так, нашим пользователям нужна сортировка объявлений по ctr и в эту статистику должна входить реалтайм статистика, еще не записанная в базу (если выбран текущий день, а он выбран по умолчанию, и это статистика за день, так как пишем только ночью).
А это влечет за собой выборку всей базы, всего мемкеша и сортировку этого чуда на клиенте.
Оптимизации, чтобы сортировка была проще, откинули, ибо для этого был необходим аж один дополнительный ключ в мемкеш для объявления. Откинули также более частые сохранение в БД с менее точным ctr. google в то время статистику за текущий день еще не показывал в аналитике. adwords сильно не пользуюсь, разводят на деньги, не знаю, есть ли она там сейчас.
Ну я и не доделал это, так как в один прекрасный вечер сообщили: Ты не прошел ИС, деньги заплатим позже, ну так их никто и не заплатил. :) Ну и контора потом накрылась :)

Думаю, это больше от команды зависит. Если самописцы не замкнуты в себе, то все норм.
Хотя и на самописной доводилось работать. У разных клиентов были несовместимые версии CMS :)
И если команда-говнокодеров на фреймворке, то хоть им на лбу кол теши.

>И они пишут на фреймворках, кстати ;)

Как раз выше написал примеры подтверждающие, что не факт. Может их процент там выше.

>P.S.: на этом дискуссию закрываем. Выходные закончились)

Ок, ответите как сможете :)

Вопрос, который меня больше всего беспокоит:
В каких-то случаях оправдано использовать самопись? Есть ли людям, использующим самопись, оправдание? :)
>А Вы нет? С тем же меню :)

Нет. Оно мне настолько редко нужно, что если вдруг понадобится — возьму что-то на гитхабе ;)

>Это примерно как государство. Оно якобы призвано заботиться о людях, а по факту от него, наверное, больше проблем :)

Ну то, что вы не осилили — не означает что они мудренные ;)

>То есть все фреймворки одинаковы?

Нет. Есть различия. Но суть у них настолько близка, что осилив один — проще понять другие ;)

>Ведь все они дают возможность удобно подключать расширения.

Нет. Ваш вот не дает. Так-же и многие другие. Но есть действительно удобные)

>Ну кому что нужно :)

Кому нужно — берут cms, а не фреймворк))))

>Это даже не обязательно сущность (то есть такого класса может и не быть). Просто пару методов, грубо говоря, наполняющих массив. :)

Даже так)))

>Они пятое колесо. Но приходится их использовать.

Так не используйте))). Пятое колесо — это хлебные крошки или меню, но никак не виджеты)

>Ну да, разные, но дублирующие друг друга.

Блин. Ну хоть покажите, где они дублируют друг-друга)))))

>Их не нужно привязывать, уже есть многоразовые контролеры.

Ну говорю-же — у вас именно виджеты. Наконец-то вы согласились)))

>Они типа государство в государстве? :)

Т.е.? Не понял аналогии.

>Виджет — это инструмент-дубль уровня фреймворка. Он не привносит ничего нового по сравнению с контроллер+вид, это тот же контроллер+вид, названный по другому.

Ой, ну и каша))) Виджет — это не контроллер. Зависит от конкретной реализации, но чаще всего виджет — это обработчик для вьюхи. Некий единый блок вьюхи. В некоторых реализация виджет может содержать контроллер, как и роутер и модель. Но это попытка реализовать hmvc.

>Для меня важна суть:

Ну так все фреймворки соответствуют этой сути)))

>И ничего плохого в жирном контроллере нет, если этот код нигде не дублируется.

А я где-то иное говорил?)) У меня тоже всегда тонкие модели ;)

>В контроллере можно вызывать разные сущности.

Ага, уровнем ниже: вьюхи, модели, виджеты, хелперы… Так есть, да.

>Я и так много нацитировал. :)

Но самое важное решили скрыть))) Ссылаетесь на вики, а там явно указано, что вы ошибаетесь))))

>главный контроллер-виджет и его шаблон может вызывать вспомагательные контроллеры-виджеты.

Абсолютно не понятный шаг. Лишний слой без какой-либо пользы. Проще сразу вызывать нужный контроллер ;)

>Почему Вы так хотите лишить меня контроллеров и обмазать виджетами? :)

Ну я не виноват, что у вас такая дурная архитектура…

>Но часто без этого никак.

Вот за всю мою практику — таких случаев не было. Покажете пример?)

>А еще их не хотят использовать из-за того, что их запуск слишком ресурсоемкий. У меня с этим все норм. 50 кБ, как никак :)

Как связаны ресурсоемкость запуска и вес кода?)))) Не хотят подобное использовать по другим, более логичным причинам ;) Например, это усложняет разработку, появляется лишний и бестолковый слой. Плюсов нет, одни минусы.

>Ну да. То есть виджеты можно легко удалить.

Не, вы не поняли. Вот за такой код, как в моем примере, надо морду… ладно, не морду — по рукам бить.

>Это уровень выше.

Т.е. это все-таки другой уровень абстракции. Но вы же настаивали, что не должно быть больше сущностей, чем Model-View-Controller. Снова какая-то двойственность. Раздвоение личности?)

>Если все сторонние вещи на сайте писались с оглядкой на один и тот же построитель меню — то норм.

Да не дай бог писать что-то с оглядкой на построителя меню…

>Если же вообще сторонних вещей нет, тогда о какой расширяемости и т.п. мы говорим.

Так я-же обратное говорю — не нужен такой мусор, как меню и хлебные крошки во фреймворках. Для этого есть тот-же composer. И пофиг, какой в нем будет подключен menu builder.

>Хлебные крошки одни, а сервисов много.

Так по вашей логике тогда именно апи сервисов должны быть в ядре — чтобы было в одном стиле все ;)

>Хлебные крошки нужны большему количеству поьзователей.

Кроме вас не знаю ни одного такого, если честно)

>Достаточно удобной обертки над curl.

Значит вы очень мало работали с апи)))

>Вы говорите, будто иметь что-то в ядре это плохо. Вот Линукс имеет.

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

>У конкурирующих реализаций интерфейсы совместимы?

Без понятия. Мне это не важно. Найду что-то удобнее, изучу, начну использовать ;) Вопрос-то не в этом был, а в том, зачем пихать все в ядро, если можно использовать вот так ;)

>А то разработчики понаподключают так ресурсы, что возможны повторные поключения тех же библиотек js, что чревато неработоспособностью.

А это точно не забота фреймворка. Это забота разработчика и приложения. И да, это нормально, когда несколько раз подключается один и тот-же js-файл например.

>Не знаю на сколько он удобный, не щупал.

Ну вы кроме yii вообще ничего «не щупали», как я понял)))). Но делаете выводы про всех)

>А в чем трудность разделить приложение на микросервисы?

Оооо, как много вам открытий чудных предстоит))))

>И в чем такая необходимость?

Ну когда на сервере подключены несколько тысяч посетителей круглосуточно и делают по десятку запросов ежесекундно — и не такая необходимость появляется)) Разделение проекта на микросервисы (точнее — выделение из проектовы микро-подпроекты) — это так, мелочь.

>Вы ж говорили, не в фишках дело :)

Ага. Только это про другое было ;). А на вопрос вы что-то не ответили ;)

>Можно.

Т.е. править ядро. Спасибо, не надо)

>События как бы дают большую гарантию

Правда?!)))) Прямо слеза навернулась… Реализовали проект на событиях, через полгода начали выносить подпроекты в микросервисы — сколько сказочного можно поймать из-за использования событий — не представляете))))

>Там дебильное MVC и работа с базой.

Где «там»? Почему дебильное? Потому что вам не понравилось?))) Ну да, это показатель)). В вашей вики сказано, что у фреймворков все правильно сделано (в той цитате, которую вы поскромничали привести).
По поводу базы — не видел вашу реализацию, но уверен что она еще хуже ;)

>Но переделывать все, ради того, что это было на фреймворке «как у всех» смысла не вижу.

А вас никто не просит что-то переделывать. Вам все дают понять, что вы сильно ошибаетесь в выводах. Пора бы уже и задуматься над этим ;)

>Ну и другие причины, о которых сказано в статье.

Причин там нет в принципе. Есть набросы: «мне не нравится — значит не правильно», «мне не удобное — значит не правильно», и т.д.

>Уже отвечал, но еще раз.

Так я на все это ответил — на любом фреймворке это делается намного проще, чем без них ;)

>Но статья постоянно обновляется, следите за новостями :)

Спасибо за приглашение, но нет. Не любитель читать бред)

>Значит у вас нету сторонних решений.

Т.е.? У меня подобное как-раз всегда решается сторонними решениями.

>Вы правите код фреймворка?

Если уж понадобится — почему нет? Еще и реквест разработчикам отпишу.

>Да и вряд ли с композером это прокатит.

Почему это?!))))))))

>Сидеть и потом выискивать изменения и накатывать? :)

Чего?! Вы в 99-м году до сих пор живете?)))

>Сторонние реализации как раз приветствуются.

Ага, поэтому запихнули в ядро!!! хлебные крошки и меню))))

>А что Вы рекомендуете, может и мне будет интересно и остальным пользователям. Статья будет? :)

Возможно, посмотрим. Пока все на уровне опытов и реализации.

>Если есть 1, который принят как стандарт де-факто, то я не против.

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

>А если нету модуля, который кастомизирует так, как нужно?

То есть описанное апи cms-ки ;)

>Хотя доводилось работать больше 3-ех лет с Битриксом. Можно использовать. Печально то, что разработчики не прислушиваются к пользователям, а также некоторые кострубатости АПИ.

Ох… Жаль вас). Такое говнище…

>Когда по Вашему стоит завязывать с кастомизацией CMS и переходить на фреймворк?

Когда задача не для cms.

>Ведь на фреймворке велосипедить нужно больше, чем на CMS.

))) Тонко, но мимо. На фреймворках не надо велосипедничать. Они как-раз для обратного)

>Там есть SQL-интерфейс?

Нет. Точнее есть в виде (упс) отдельного модуля. Но никто не будет это использовать в продакшене.

>Сортировка/группировка/джойны на клиенте?

Нет, на сервере.

>Но если Вы с ней только из-за того, что у РСУБД проблемы с удалением, то возможно уже таких проблем у mysql 5.6.что-то+ (и форках) нет

Есть. Поверьте на слово)

>Помечаем элементы удаленными, ночью удаляем, и запускаем ALTER TABLE… ENGINE=INNODB, который якобы стал неблокирующим.

Ага… Плавали, знаем. Спасибо — не надо. Удалять несколько десятков миллионов записей и потом alter table… После этого получаем проблемы с производительностью, т.к. не запускали optimize table. А если запустили — имеет приложение, которое долго не работает)))

>Ну и можно использовать партиционирование. По непроверенной информации дает ощутимый прирост.

Ну проверьте. Я уже проверял). Использую рсубд только тогда, когда не надо ничего удалять ;)

>Даже хотя бы не то, что не говнокодили, а отступы не прыгали туда-сюда. Исправишь все, а завтра опять придет в репозиторий то самое. :)

Так тут проблема не во фреймворках, а в code style. Если это не отлажено — при чем тут фреймворки-то?))))

>Ну или говоришь такой старшему разработчику, зачем здесь такие костыли, зачем ты лезешь в хату через окно, если можно через двери? А он типа: я спешил, пусть будут.

Тоже не вижу проблемы связанной с фреймворком. Ну дебил человек — ок, фреймворк-то в чем провинился?)

>Ну или говоришь такой на ИС: какой баран (я человек прямой, людей баранами называю не просто так, а за дела, не с целью обидеть, и себя тоже иногда) тут виджет влепил, который делает примерно такое: echo 'дальше пошла таблица'.

Похоже, вы просто работаете с дебилами). Но виноваты фреймворки, ага)

>А это влечет за собой выборку всей базы, всего мемкеша и сортировку этого чуда на клиенте.

Т.е. тупо нет опыта работы с такими объемами))). Обработка raw-данных, обычно, делается иначе. Совсем иначе ;)

>Ну я и не доделал это, так как в один прекрасный вечер сообщили: Ты не прошел ИС, деньги заплатим позже, ну так их никто и не заплатил. :) Ну и контора потом накрылась :)

Ну так фреймворк-то в чем виноват?)))))))

>Если самописцы не замкнуты в себе, то все норм.

Если они «не замкнуты в себе» — рано или поздно дойдут до того, что лучше использовать проверенные решения, а не городить велосипеды. Соответственно, перейдут в разряд пользователей фреймворков. Иначе они все-таки «не замкнуты в себе» ;)

>И если команда-говнокодеров на фреймворке, то хоть им на лбу кол теши.

Ну так сново подтверждение — если люди дебилы, фреймворк не виноват. А если смекалистые — фреймворк сильно поможет ;)

>Как раз выше написал примеры подтверждающие, что не факт. Может их процент там выше.

Ну вы везучий на дебилов, что тут скажешь). У других совсем другая статистика ;)

>В каких-то случаях оправдано использовать самопись? Есть ли людям, использующим самопись, оправдание? :)

Да уже давно нет смысла писать то, что написано. Каждый программер создал хоть 1 свой фреймворк, хотя-бы раз в жизни написать свой блог, форум. Для саморазвития — да, возможно. Для реальной работы — нет, противопоказано.

Я сейчас работаю в проекте, в котором собственный фреймворк. И заменить уже не вариант. Это очень печально, пытаемся постепенно избавляться от легаси в пользу сторонних библиотек, дабы разгрузить основной код. Причина этого — человек не нашел в свое время удобный для себя фреймворк и написал свой. Сча ругаются все, включая автора фреймворка, т.к. проект стал большим, а фреймворк не был расчитан на подобное. ;)
>Нет. Есть различия. Но суть у них настолько близка, что осилив один — проще понять другие ;)

Тогда осилив 1 язык, проще другой :)

>Нет. Ваш вот не дает.

Но у меня не фреймворк. :) Но подключайте себе через композер.

>Но самое важное решили скрыть))) Ссылаетесь на вики, а там явно указано, что вы ошибаетесь))))

Я у себя в статье не оспариваю то, что я якобы скрыл.

>Абсолютно не понятный шаг. Лишний слой без какой-либо пользы. Проще сразу вызывать нужный контроллер ;)

Но нам нужно выполнить 10 контроллеров-виджетов.

>Ну я не виноват, что у вас такая дурная архитектура…

Архитектура наоборот простая.

>Вот за всю мою практику — таких случаев не было. Покажете пример?)

Когда вывод одного контроллера нужно показать в другом, а не использовать костыли в виде виджетов.

>Как связаны ресурсоемкость запуска и вес кода?)

Я вообще-то шутя, но разве не чем больше кода нужно перелопатить, не тем больше времени нужно на это потратить?

>Например, это усложняет разработку, появляется лишний и бестолковый слой.

Нисколько это не усложняет, наоборот упрощает.

>Не, вы не поняли. Вот за такой код, как в моем примере, надо морду… ладно, не морду — по рукам бить.

Я не так выполняю дополнительные контроллеры. Без промежуточных переменных.

>Т.е. это все-таки другой уровень абстракции. Но вы же настаивали, что не должно быть больше сущностей, чем Model-View-Controller. Снова какая-то двойственность. Раздвоение личности?)

Я говорил, что модель — это уровень выше, чем контроллер. :)

>Да не дай бог писать что-то с оглядкой на построителя меню…

Значит Вам не доводилось иметь динамическое меню.

>Так по вашей логике тогда именно апи сервисов должны быть в ядре — чтобы было в одном стиле все ;)

Повторю:
«я не сторонник мапить апи сервиса один в один. Считаю это псевдопрограммированием. Достаточно удобной обертки над curl.»

>Кроме вас не знаю ни одного такого, если честно)

Спросите у сеошников. :)

>Значит вы очень мало работали с апи)))

Может и мало.
Работал с VK и cloudflare.
Мапинг всех методов 1 в 1 в этих случаях был излишним. Хотите — пишите код, я ленивый программист :)

>Без понятия. Мне это не важно. Найду что-то удобнее, изучу, начну использовать ;) Вопрос-то не в этом был, а в том, зачем пихать все в ядро, если можно использовать вот так ;)

Так можно не в ядро. Мне важно наличие стандарта де-факто.

>А это точно не забота фреймворка. Это забота разработчика и приложения. И да, это нормально, когда несколько раз подключается один и тот-же js-файл например.

То есть, стреляйте себе в ноги, я не при чем.
Это не совсем нормально.
Пример:
подключили jQuery
подключили какой-то плагин jQuery
подключили jQuery

Вызывается обработчик, который дергает плагин, а плагина и след простыл. :)

>Ну вы кроме yii вообще ничего «не щупали», как я понял)))). Но делаете выводы про всех)

Так это ко всем относится. :)
Или много мейнстримовых фреймворков сделаны в моем стиле?

>Оооо, как много вам открытий чудных предстоит))))

Если код не вермишель, а предоставляет АПИ друг другу, то ничего сложного.

>Ну когда на сервере подключены несколько тысяч посетителей круглосуточно и делают по десятку запросов ежесекундно — и не такая необходимость появляется))

Если эти микросервисы продолжают жить на одном сервисе, то смысла 0, если это сделано из-за нагрузки. Наоборот, нагрузка увеличится.

У меня максимум нагрузки — 235к хитов за час. Сервер их не почуствовал :)

>Ага. Только это про другое было ;). А на вопрос вы что-то не ответили ;)

Предоставляет единый интерфейс, чтобы не было велосипедов.

>Т.е. править ядро. Спасибо, не надо)

Это Вы предлагали наследоваться, а не я править ядро…

>Правда?!)))) Прямо слеза навернулась… Реализовали проект на событиях, через полгода начали выносить подпроекты в микросервисы — сколько сказочного можно поймать из-за использования событий — не представляете))))

Может у Вас не такие события, как у меня.
Но если события были дебильными, а потом их переделали в микросервисы, не убрав дибильность, то ничего не поменяется.

>Потому что вам не понравилось?

Да. :)

>Причин там нет в принципе.

«У меня уже есть отшлифованное легкое ядро всего на 50КБ. :)
Я хозяин всего кода.
У меня есть сайты, которые я не хочу переводить на что-либо другое просто ради того, чтобы перевести.
Я не хочу завязывать свой код на них.
Я программист, я не кодер.»

>Если уж понадобится — почему нет?

Вы ж говорили, что править ядро плохо? У кого раздвоение? :)

>Еще и реквест разработчикам отпишу.

А они им подотруться :)

>Ага, поэтому запихнули в ядро!!! хлебные крошки и меню))))

Чтобы был единый стандарт.
Не обязательно в ядро, в модуль ядра.

>А я против. Под разные задачи мне нужны разные инструменты, делающие одно и то же.

Наличие стандарта не отменяет права выбора.

>Например — кеширование. Для мелких проектов мне с головой хватит файлового или мемкеш.

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

>Для среднего и выше — уже нужно распределенное, более надежное.

Мемкеш — распределенный.

>Ох… Жаль вас). Такое говнище…

Внутри там много старого мусора, который боятся трогать из-за совместимости.
Но АПИ более-менее норм.

>Когда задача не для cms.

Если CMS толковая, то она нечто вроде CMF, так что пофиг.

>))) Тонко, но мимо. На фреймворках не надо велосипедничать. Они как-раз для обратного)

Там код писать совсем не нужно? :)

>После этого получаем проблемы с производительностью, т.к. не запускали optimize table. А если запустили — имеет приложение, которое долго не работает)))

С 5.7.4 эта операция тоже неблокирующая.

>Тоже не вижу проблемы связанной с фреймворком. Ну дебил человек — ок, фреймворк-то в чем провинился?)

Так не фреймворк виноват. :) Просто фреймворк не исправил его. Для этого нужна команда.

>Т.е. тупо нет опыта работы с такими объемами))). Обработка raw-данных, обычно, делается иначе. Совсем иначе ;)

Это не raw данные. Это уже агрегированные.

>Да уже давно нет смысла писать то, что написано.

А мордокнига и ВК?

>Я сейчас работаю в проекте, в котором собственный фреймворк.

Я сторонник самописи, но работаю с фреймворками
Вы сторонник фреймворков, но работаете с самописью :)

Жизнь — боль. :)
> Тогда осилив 1 язык, проще другой :)

Именно так ;)

>Но у меня не фреймворк. :) Но подключайте себе через композер.

А в чем у вас отличие от «фреймворков»?)

>Но нам нужно выполнить 10 контроллеров-виджетов.

Нет. Нужно выполнить 1 контроллер (который отвественный за запрос от клиента) и 10 различных модулей (для простоты назовем их виджетами).

>Когда вывод одного контроллера нужно показать в другом, а не использовать костыли в виде виджетов.

Т.е. вместо логичного и правильного решения вы придумываете себе костыли и считаете что все остальные костыли юзают?)))))) Был у меня знакомый, который модели называл контроллерами, контроллеры слоями, а вьюхи шаблонами. Очень похоже ;)

>Я вообще-то шутя, но разве не чем больше кода нужно перелопатить, не тем больше времени нужно на это потратить?

Нет конечно). Простой пример — получить все письма из почтового ящика за последний год по imap. Кода — строк 20-30, а вот ресурсоемкость огромная ;)

>Я не так выполняю дополнительные контроллеры. Без промежуточных переменных.

Да какая разница? Вот пример без дополнительных переменных: new \Frontend\Controller($this-getDI()); Можно даже так: (new \Frontend\Controller($this-getDI()))->render(). Все-равно сам подход полное говно.

>Достаточно удобной обертки над curl.

Нет, не достаточно. Для 1-5х методов — может быть, а для полноценного использования крупного апи — нет.

>Спросите у сеошников. :)

Прямо сейчас напротив 2-е сидят. Спросил. Говорят — вообще не существенно)

>Это не совсем нормально.

Я вроде про jquery ничего не говорил. А вот подключать баннеры так довольно удобно:
script src=banner.js?uid=1
script src=banner.js?uid=2


>Или много мейнстримовых фреймворков сделаны в моем стиле?

Да не дай бог в вашем стиле еще что-то появится))). Вам нравится — ок, но не надо молодежь приучать к бреду)

>Если код не вермишель, а предоставляет АПИ друг другу, то ничего сложного.

Серьезно?)))))) ну ок, ок…

>Если эти микросервисы продолжают жить на одном сервисе, то смысла 0, если это сделано из-за нагрузки. Наоборот, нагрузка увеличится.

))) Видно, что далекая для вас тема))) Только за счет асинхронности обработки получается сильно снизить нагрузку, не говоря о других плюсах.

>У меня максимум нагрузки — 235к хитов за час. Сервер их не почуствовал :)

<6к rps? что должна сказать эта цифра?)))))))

>Это Вы предлагали наследоваться, а не я править ядро…

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

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

Вы не поняли. События (я тоже от них фанател когда-то давно) — не панацея. Где-то они очень помогают (для логирования например), а где-то нет. Но всегда, когда их становится много — получается только вред. Как в плане поддержки и развития кода, так и в плане рефакторинга в будущем.

>У меня уже есть отшлифованное легкое ядро всего на 50КБ. :)
>Я хозяин всего кода.
>У меня есть сайты, которые я не хочу переводить на что-либо другое просто ради того, чтобы перевести.
>Я не хочу завязывать свой код на них.
>Я программист, я не кодер.

Ну так отлично. Только не надо других призывать к плохим вещам ;)

>Вы ж говорили, что править ядро плохо? У кого раздвоение? :)

Именно так. И править ядро я буду только если найду какой-то баг или, например, хлебные крошки)))

>А они им подотруться :)

Вам и тут не везет?)))

>Чтобы был единый стандарт.

Какой нафиг стандарт? На хлебные крошки?)))))) Т.е. для апи стандарта не надо, а для хлебных крошек — критически необходимо! Классная логика)

>Не обязательно в ядро, в модуль ядра.

А зачем эта лишняя сущность?) Вы же против лишних сущностей, но я уже с десяток их насчитал ;)

>Ну так не переделывать же весь код, который вызывает методы кеширования из-за того, что поменялось хранилище кеша. Не так ли?

Весь код — нет конечно. Но частично — легко. Например, перевели кеш с файлов на редис — получили доп.функционал в качестве тегов. Почему не использовать? Да, переделываем кеширование.

>Мемкеш — распределенный.

Да что вы говорите))). Давно есть реплика в мемкеше?)))

>Но АПИ более-менее норм.

Да говно апи в битриксе. Честно — минут 10 пытался вспомнить хоть одну систему где хуже — не смог. Даже в modx сильно лучше апи (хотя тоже до нормального не дотягивает).

>Если CMS толковая, то она нечто вроде CMF, так что пофиг.

Хм… Т.е. тут вы не против фреймворков))))

>Там код писать совсем не нужно? :)

Нужно. Велосипедничать не нужно ;).

>С 5.7.4 эта операция тоже неблокирующая.

«As of 5.7.4, OPTIMIZE TABLE uses online DDL (ALGORITHM=INPLACE) for both regular and partitioned InnoDB tables. The table rebuild, triggered by OPTIMIZE TABLE and performed under the cover by ALTER TABLE… FORCE, is now performed using online DDL (ALGORITHM=INPLACE) and only locks the table for a brief interval, which reduces downtime for concurrent DML operations.»

Вроде как четко написано, что таблицы все-равно блокируются на короткие интервалы. А значит имеем проблемы с производительностью. Потестирую на досуге, но мало верится, что здесь что-то полезное сделали.

>А мордокнига и ВК?

А что с ними?)) Думаете, они пишут абсолютно все с нуля?))))
>А в чем у вас отличие от «фреймворков»?)

«фреймворк вызывает функции пользовательского кода» (https://ru.wikipedia.org/wiki/Фреймворк )
У меня более гибридная схема. Чаще я прошу сам, чтобы ядро выполнило какой-то мой код.

Контроллером/моделью/шаблоном может быть любой сторонний код, хотя пока я использую сам.

>Простой пример — получить все письма из почтового ящика за последний год по imap. Кода — строк 20-30, а вот ресурсоемкость огромная ;)

Задача процессор не тратит, это блокирующая операция с сетью.
Вечный цикл можно и в 3 строки написать. :)

>Нет, не достаточно. Для 1-5х методов — может быть, а для полноценного использования крупного апи — нет.

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

>))) Видно, что далекая для вас тема))) Только за счет асинхронности обработки получается сильно снизить нагрузку, не говоря о других плюсах.

А, ну если вы там видео пережимаете, то да, не стоит заставлять пользователя ожидать, пока браузер загрузится :)
Но это было давно. Просто сейчас стало модным.

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

Наследование боль. Нужно использовать события и грамотно их расставлять.
Такая же боль и при использовании фреймворка. :)

>Но всегда, когда их становится много — получается только вред. Как в плане поддержки и развития кода, так и в плане рефакторинга в будущем.

Их нужно тоже структурировать.
Если любого кода много, то с ним трудно работать. Поэтому я стараюсь писать меньше кода :)

>Т.е. для апи стандарта не надо

Так все апи разные.
Поэтому проще пользоваться универсальной оберткой.

>А зачем эта лишняя сущность?) Вы же против лишних сущностей, но я уже с десяток их насчитал ;)

Так Вы на каждый АПИ сервис предлагаете вводить сущность и реализацию один в один. :)

>А зачем эта лишняя сущность?

Модуль ядра — это не лишняя сущность. Это модуль (модель, компонент), который поставляет поставщик ядра.

>Весь код — нет конечно. Но частично — легко. Например, перевели кеш с файлов на редис — получили доп.функционал в качестве тегов. Почему не использовать? Да, переделываем кеширование.

Ну это если в начале разрабатывали без оглядки на теги.
На фреймворках, вроде, интерфейсы кешей предусматривают теги.

>Да что вы говорите))). Давно есть реплика в мемкеше?)))

Репликаций вроде нету.
Можете сами реплицировать :)

>А что с ними?)) Думаете, они пишут абсолютно все с нуля?))))

Я тоже все не пишу.
Но каркас-то они хоть пишут сами?
Да и ВК как бы без ООП.
Или там все на фреймворках у них? :)
>«фреймворк вызывает функции пользовательского кода» (https://ru.wikipedia.org/wiki/Фреймворк )

Вообще-то, это сказано про IoC (https://ru.wikipedia.org/wiki/Инверсия_управления) ;). «Фре́ймворк (иногда фреймво́рк; англицизм, неологизм от framework — каркас, структура) — программная платформа, определяющая структуру программной системы». Снова пытаетесь под себя перевернуть?)))))) У вас фреймворк (точнее — нано-фреймворк))).

>Задача процессор не тратит, это блокирующая операция с сетью.

Да вы что… ))))) Я этой задачей занимался на прошлой неделе ;). Попробуйте на досуге. Лучше сразу параллельно пользователей на 40 ;)

>Я не люблю, когда много кода, который нужно поддерживать, который имеет потенциальные дыры, который нужно писать, который неизвестно как работает, который ничего полезного не делает.

Не любите свой фреймворк?))))) Прямо описали ассоциации многих людей ;)

>А, ну если вы там видео пережимаете, то да, не стоит заставлять пользователя ожидать, пока браузер загрузится :)

Не, простая математика. Но много)

>Наследование боль. Нужно использовать события и грамотно их расставлять.

Странная у вас логика). Наследование — это удобно в большинстве случаев. События тоже удобны, пока их не много.

>Такая же боль и при использовании фреймворка. :)

Вашего? Верю). Мне фреймворки помогают, доставляя удовольствие от использования. Но да, если не можете изучить — будет больно)

>Их нужно тоже структурировать.

Их надо использовать только там, где они полезны. Пихать везде — раскидывать грабли себе же.

>Поэтому я стараюсь писать меньше кода :)

Это видно). Писали-бы побольше — поняли-бы плюсы фреймворков. А писать бложики на 10 страниц много кода не надо)

>Так Вы на каждый АПИ сервис предлагаете вводить сущность и реализацию один в один. :)

Где это я такое предлагал?))) Чёт наговариваете вы на меня)))

>Модуль ядра — это не лишняя сущность. Это модуль (модель, компонент), который поставляет поставщик ядра.

Ух-ты… Есть «ядро», «поставщик ядра», «модуль», «компонент»… И этот человек против виджетов!!! Ахахахаха…

>Ну это если в начале разрабатывали без оглядки на теги.
>На фреймворках, вроде, интерфейсы кешей предусматривают теги.

Это всего-лишь пример был).

>Мемкеш — распределенный.
>Репликаций вроде нету.

А в чем тогда выражается распределенность?! ))))))))))))))

>Можете сами реплицировать :)

Да ладно?! ВНИМАТЕЛЬНО СЛУШАЮ!!!

>Но каркас-то они хоть пишут сами?

С чего вы это решили?)))) Даже не так. Да, скорее всего что-то пишут сами. Потом используют в виде фреймворков, например так: https://github.com/facebook/FBMock ;)

>Да и ВК как бы без ООП.

И? Как это связано?)

>Или там все на фреймворках у них? :)

Скорее всего нет, я не знаю. Но точно уверен, что не на фреймворке на 50кб ;)
>Вообще-то, это сказано про IoC

Видимо текст страницы поменялся, цитату скопировал давно.
Да и это не суть важно.

>Наследование — это удобно в большинстве случаев.

Вы же сами говорили о возможных проблемах наследования… :)

>Где это я такое предлагал?))) Чёт наговариваете вы на меня)))

Читайте свои комменты, а то скажете, что имели другое в виду, типа имели в виду, что мой «фреймворк» унылый.

Остальное лень комментить :)
>Да и это не суть важно.

Ну да, не важно, когда по ссылке сказано вопреки вашим словам)))

>Вы же сами говорили о возможных проблемах наследования… :)

Снова наговариваете))) Никогда подобного не говорил.

>Читайте свои комменты, а то скажете, что имели другое в виду, типа имели в виду, что мой «фреймворк» унылый.

Не поленился, перечитал — нет ничего подобного. Максимум что есть — вопрос к вам, в стиле «если пихаете в ядро всякий мусор наподобии меню и хлебных крошек, почему не пихаете всякие апи?». Я-же наоборот, раз 10 заявил, что ядро фреймворка должно быть минимальным, без всякого мусора. А для апи есть достаточно удобные обертки, например https://github.com/mpratt/Embera

В идеале, ядро = бутстрап-файл + composer.json.

>Остальное лень комментить :)

Не удивлен, но жаль — только разогрелся).
>Снова наговариваете))) Никогда подобного не говорил.

me:
>Можно подписаться на событие… :)
you:
>Можно. А можно наследоваться и переделать реализацию.
me:
>Можно. Но некоторые тру-фреймоворкоюзатели говорят, что наследование — зло.
you:
>Т.е. править ядро. Спасибо, не надо)
me:
>Это Вы предлагали наследоваться, а не я править ядро…
you:
>Верно. Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.
me:
>Наследование боль. Такая же боль и при использовании фреймворка. :)
you:
>Странная у вас логика). Наследование — это удобно в большинстве случаев.

Вы по ходу переписки выдумываете выдумки.

>А для апи есть достаточно удобные обертки, например https://github.com/mpratt/Embera

По описанию это встраивалка видео :)
>Вы по ходу переписки выдумываете выдумки.

Перечитайте свою выжимку ;). Где я говорю что наследование — зло?) Скорее наоборот: «Если я наследуюсь и правлю в наследнике — это отлично». Говорю-же — наговариваете на ровном месте))))
Вы хоть перечитывайте что публикуете)))

>По описанию это встраивалка видео :)

Именно. Обертка над кучей апи в отдельной библиотеке.
>Перечитайте свою выжимку

Вы выдумали, что с моим кодом у Вас будут проблемы с наследованием, а с фреймворком не будет.

Fesor Вы вроде против наследования? :)
>Вы выдумали, что с моим кодом у Вас будут проблемы с наследованием, а с фреймворком не будет.

Еще раз перечитайте ;). Я против правки ядра, а не против наследования. Даже написано чуть-ли не 1-в-1: «Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.».

Может хватит уже придумывать?)
Вы вроде против наследования? :)

Наследование — инструмент. Я против использования наследования там, где оно не нужно.


В то же время вы полностью отвергаете разные "ненужные" SOLID и GRASP принципы, здравый смысл и т.д. оправдывая это личным вкусом.

Я не пытался спорить, с ним бесполезно) Мне просто скучно)

4 Я крутой программер, я написал уже несколько больших программ, я знаю все о программировании!!!

Наоборот :)
Я стараюсь работать с меньшим количеством кода, так как в голове все это трудно удержать :)
5. На этой стадии программист переосмысляет само понятия «программирование». Он начинает прислушиваться к другим программистам, обращать внимание на готовые решения, не изобретая велосипед по-новой, на первый план выходят скорость и качества реализации проекта, просматривая чужие листинги, он ищет не ошибки, а интересные идеи.

Я благодарен критике (наставлениям :) ).
Если бы все пользовались готовыми решениями и не изобретали велосипед, то до сих пор жили бы в каменном веке.

Вы считаете себя на какой стадии? :)
Я стараюсь работать с меньшим количеством кода, так как в голове все это трудно удержать :)

Именно по этому и нужны эти все кучи абстракций.


Вы считаете себя на какой стадии? :)

на 5-ой

Читать вообще полезно. Читать и думать. :)
И не только в своей профессиональной области, а и в других — для общего развития и расширения кругозора.

Вот и Ваш совет, и текст по ссылке, напомнили мне другие темы, которые, на мой взгляд, не мешало бы знать и автору этого текста, и ссылающимся на него:

Проекция (психология)
Перенос (психология)


Очень интересное и полезное чтение, рекомендую. :)
Каким же образом я отвергаю SOLID и GRASP?

О GRASP, кстати, впервые слышу :)

Я за здравый смысл.

Ну нету мне смысла тянуть фреймворк и все на него переписывать.
Каким же образом я отвергаю SOLID и GRASP?

лучше скажите в каком месте вы соблюдаете SOLID)


О GRASP, кстати, впервые слышу :)

Это проблема разработчиков. GRASP штука полезная, почитайте погуглите.


Я за здравый смысл.

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


Ну нету мне смысла тянуть фреймворк и все на него переписывать.

Мне кажется у вас какая-то травма психологическая вокруг фреймворков.

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


Если У Вас остается 90%, то ок.
А у меня останется 10%. :)
Проще все выбросить и написать самому 50 кБ.

И фреймворки это как раз тот готовый вариант для типичных задач.


Фреймворки не совсем решают типичные задачи. Это скорее CMS.

>А у меня останется 10%. :)

Так проблема именно в этом ;). Вместо того, чтобы использовать — переписываете)))
Так проблема именно в этом ;). Вместо того, чтобы использовать — переписываете)))

У Вас есть еда, которая для Вас не вкусная / Вы не любите / плохо желудку?
Вы ее едите? :)

Да и я не переписываю, это если бы переписывал, пришлось бы выбросить 90%.
А так я написал всего 50 кБ. :)
Когда я впервые попробовал роллы — очень не понравилось, сейчас заказываю часто. Пиво не пил до 18 лет. И сейчас не сильно его люблю, но в компании устраивает.

Да, я ем «не вкусную» еду, если считаю, что могу ошибаться или просто не повезло с поваром ;).
А вот вы упорно едите асфальт, вместо того, чтобы попробовать что-то более правильное, в плане еды)

Про 50кб задал вопрос в другой ветке — жду ответа ;)
Когда я впервые попробовал роллы — очень не понравилось

Попробуйте самопись, Вам понравится. :)
Кстати, тоже долго не пробовал суши, не то что я их не любил, просто не пробовал, как и много другой еды.

Да, я ем «не вкусную» еду, если считаю, что могу ошибаться или просто не повезло с поваром ;).

У вас просто выбора нет :)
Ну или Вы врете :)
image

А вот вы упорно едите асфальт, вместо того, чтобы попробовать что-то более правильное, в плане еды)

В реальности ем немного.
Также и в ИТ. Чтобы не растолстеть. :)

П.С.
Пользуюсь Windows XP, если не знаете :)
http://blog.kpitv.net/article/windows-xp/
Как Вам? :)
Если У Вас остается 90%, то ок.
А у меня останется 10%. :)

Чего от чего простите? Ну вот флоу. Мне нужно написать маленькую трейдинговую платформу. Функционал специфичный и потому готовых решенйи под это нет. Что я делаю:


беру симфони, беру доктрину. Накидывают бизнес сущности на plain php (без фреймворков), описываю как оно там между собой работает, с тестами например проверяю что все ок и начинаю лепить сверху уже инфраструктуру (мэппинги базы, схему потом мне доктрина сгенерит), разные сервисы по взаимодействию с внешними системами. Настрою swiftmailer что бы он мне почту через какой sendgrid/mailgun слал, роутинг, контроллеры, прикручу трансформеры на fractal что бы обезапасить себя от изменений в API в будущем и т.д.


При этом я не потратил ни минуты на решение каких-то стандартных задач вроде "отправка почты", только креды в настройках прописал. Или роутинг например. Или работа с базой данных.


Ну и да, у меня еще есть отдельные надстройки которые помогают экономить время. Например валидация данных запросов — https://github.com/fesor/request-objects — я его могу генерить из доки по API.


При этом всем все гибко просто и моя бизнес логика про фреймворк ничего не знает. А главное — мэйнтейнить такую систему будет проще.


Фреймворки не совсем решают типичные задачи. Это скорее CMS.

"не совсем решают" так себе характеристика. Типичные задачи для вас возможно отличаются для 95% других людей. Ну и "это скорее CMS" — это вы наверное все же про Yii.

При этом я не потратил ни минуты на решение каких-то стандартных задач вроде «отправка почты»

Я тоже такие вещи не переизобретаю, вроде не раз об этом говорил :)

Ну и да, у меня еще есть отдельные надстройки которые помогают экономить время. Например валидация данных запросов — https://github.com/fesor/request-objects — я его могу генерить из доки по API.

Вот и Вы написали свой велосипед. :)
Так и у меня есть такие надстройки, что мне даже фреймворк не нужен, и все влезает в 50 кБ… :)
На фреймворках есть плюсы, они гибкие. Но за гибкость нужно платить.
А также Вы использовали события в своем решении, aktuba был против событий :)
А также использовали стандартные интерфейсы, а не велосипедные. Вот я и говорю, что не помешало бы иметь такие интерфейсы для меню и хк. Вот увидите, скоро фреймворки это реализуют (а может и уже реализовали, но ни вы, ни я не в курсе :) )
Хотя не совсем понял, где прописаны у Вас сами правила валидации. Они как-то потом подключаются в зависимости от задач, заметил только проверку чтобы у некоторых запросов не было тела. :)

Ну и «это скорее CMS» — это вы наверное все же про Yii.

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

Напомните с какими фреймворками вы работали плотно?


Вот и Вы написали свой велосипед. :)

я портировал идею из laravel и spring под symfony. Если у меня дойдут руки переделать это дело под PSR-7 и отвязаться от symfony/validation — то как бы оно не будет привязано к фреймворку.


На фреймворках есть плюсы, они гибкие. Но за гибкость нужно платить.

Гибкость = избыточность и так было всегда. Меня избыточность фреймворков полностью устраивает потому как это сокращает время разработки моих задач.


А также Вы использовали события в своем решении

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


А также использовали стандартные интерфейсы, а не велосипедные.

А как мне интегрироваться с велосипедными?)


не помешало бы иметь такие интерфейсы для меню и хк

уже года 3 не приходилось сталкиваться с задачей организации менюшек на бэкэнде. Но вообще в те времена пользовался этим: https://github.com/KnpLabs/KnpMenu


Оно не привязано ни к какому фреймворку и есть кучи интеграций.


Хотя не совсем понял, где прописаны у Вас сами правила валидации.

там папочка examples есть. И тесты.


Они как-то потом подключаются в зависимости от задач, заметил только проверку чтобы у некоторых запросов не было тела. :)

нет там такого. У каждого объекта запроса есть метод rules который предоставляет правила валидации и все.

>был против событий :)

Это вы фразу «много событий — плохо» пытаетесь перевернуть в «против событий»?)))))) В своем репертуаре, ложь и глупость)

>Вот увидите, скоро фреймворки это реализуют

Вот увидите — вы единственный такой дурной)

> все влезает в 50 кБ…

Откуда так много?! У вас-же толком нет ничего. Router (0,3-1кб), request (0,5-1кб), view (скорее всего простейшее, без наследования и пр. — 0,5-1кб), response отсутствует скорее всего (т.к. заголовки отправляет ядро, рендера нет), но даже если есть — 0,5кб. Контроллер и модель — ну по 0,2-0,5кб. Враппер для базы — пусть будет 2 кб (хотя вряд-ли столько у вас наберется). А, ну да — хк и меню))). Ну пусть каждый по 200-300 байт (массив+сеттеры/геттеры — больше нет смысла). Прибавим само ядро, валидаторы — пусть будет 3-5кб. Сколько получилось? 12-13кб. КАК ВЫ УМУДРИЛИСЬ 50кб набрать на микрофреймворке, который ничего не умеет, кроме crud?!
Это вы фразу «много событий — плохо» пытаетесь перевернуть в «против событий»?)))))) В своем репертуаре, ложь и глупость)

Мотаю треды:
И этот вариант будет проще поддерживать и отлаживать, чем вариант с событиями. Не говоря уже о том, что события иногда вообще вредны.

Правда?!)))) Прямо слеза навернулась… Реализовали проект на событиях, через полгода начали выносить подпроекты в микросервисы — сколько сказочного можно поймать из-за использования событий — не представляете))))

Но всегда, когда их становится много — получается только вред. Как в плане поддержки и развития кода

Вы же имели в виду о глупых событиях в моем коде, правильно? :)

Любой код, если его много, сложно поддерживать.
Собственно поэтому у меня и свое ядро на 50 кБ… :)

Откуда так много?!

О, Вы среагировали, что можно и меньше. :)
Если Вы такой мастер, то почему не создали свой Симфони с блекджеком и шлюхами? :)
Вам хватит для этого 64 кБ?

Router (0,3-1кб)

У меня его вообще нету. Шах и мат! :)

без наследования

Явного наследования типа extends нету, но есть минимум 2 способа «наследовать», то есть иметь/изменять т. н. родителя.

хотя вряд-ли столько у вас наберется, 12-13кб

Это Вы считали, сколько бы вышло у Вас?
А то как-то тупо приписывать кому-то свою глупость. :)
Хотя да, есть куда улучшаться, об этом написано в бложике :)

КАК ВЫ УМУДРИЛИСЬ 50кб набрать на микрофреймворке, который ничего не умеет, кроме crud?!

Сколько там занимает crud у Доктрины? :)
>Мотаю треды:

Надо не только «мотать», но еще и читать ;)

>Вы же имели в виду о глупых событиях в моем коде, правильно? :)

Эмм… Откуда такой вывод?)) Вы решили, что я у вас код украл и тайком посмотрел? Вы-же его никому не показываете)))) Я говорил в общем ;)

>О, Вы среагировали, что можно и меньше. :)

Можно и в пару сотен байт уложиться ;)

>Если Вы такой мастер, то почему не создали свой Симфони с блекджеком и шлюхами? :)

Зачем?! Какой смысл распылять силы?)))) Я пользуюсь 3-4я фреймворками, в зависимости от задачи. Но да, когда-то был глупый и писал свои)

>Вам хватит для этого 64 кБ?

Хватит пары килобайт ;). Максимум.

>У меня его вообще нету. Шах и мат! :)

Еще один минус)

>Это Вы считали, сколько бы вышло у Вас?

Не, это я насчитал примерный вес фреймворка без плюшек. Ну и прибавил ваши бредовые меню и крошки.

>А то как-то тупо приписывать кому-то свою глупость. :)

До вас начало доходить? Это прогресс, поздравляю!

>Сколько там занимает crud у Доктрины? :)

2 235 882 Б (3 МБ на диске), объектов: 407. С комментариями. И это вся ORM ;) Я ею не пользуюсь, но на 100% уверен, что она умеет во много раз больше вашего.

Стало тут интересно, сколько весят нормальные фреймворки (до этого никогда не интересовался):
lumen: 135кб
kohana 3.3: 82кб
phppixie: 51 526 Б (думаю, даже он будет помощнее вашего ;)
f3: 16 499 Б

Так-что совсем не понятно, что можно было такого написать на 50кб. Для примера f3: поддержка роутинга, sql/mongodb, довольно приличный шаблонизатор, плагины… и всего 16кб. Так что вы там такого написали на 50кб? Меню на 20кб и хлебные крошки на 30?))))))))))))))))))))))
Эмм… Откуда такой вывод?)) Вы решили, что я у вас код украл и тайком посмотрел? Вы-же его никому не показываете)))) Я говорил в общем ;)


Так Вы все время что-то о моем коде выдумываете, хотя бы тот же размер.

Так-что совсем не понятно, что можно было такого написать на 50кб.


У меня более монолитное ядро.
Оттуда легко можно выбросить кеширование, mysql, memcached, авторизацию, комментарии! (они нужны всем моим сайтам, поэтому они пока в ядре :)), меню, хк, легаси контроллеры, защиту от csrf, 304 ответ, возможность поменять вывод, расположенный выше, кодом, расположенным ниже, добавление ресурсов (+защита от повторной вставки ресурсов, добавление признака изменения ресурса), показ асоциальных кнопок!, встроенная защита, чтобы в админке не было лишнего кода (счетчиков), «поддержка» mysql_* функций в php7, и других удаленных, определения языка/страны по запросу, многоязычность, при желании можно выбросить загрузчик и конфигов, упрощение дебага, авторендеринг шаблонов, некоторый другой мусор и легаси вещи.

Осталось 4кБ: автолоадер, события, MVC. То есть осталось голое ядро.
Зачем мне тянуть мусор, если можно реализовать все самому под себя (так как реализация фреймворков меня не устраивает). Проще нарастить мускулы этому ядру, а не подпирать костылями фреймворк и разбираться с его особенностями.

Кстати, зачем f3 имеет pingback? :)

Да и размеры на гитхабе побольше, даже если не считать «демо» информацию.

экий список велосипедов. Позвольте спросить как вы организуете защиту от XSS? Экранирование везде и всюду или же "фильтровать входные данные"? Если у вас используется mysql_* функции — как защищаетесь от sql инъекций?


Помниться собеседовал чувачка, он тоже с другом "ядро" написал, и там все это решалось "тихим" выпиливаем "лишних" символов. То есть по какой-то причине я не могу использовать пароль с кавычками в его системе.

Позвольте спросить как вы организуете защиту от XSS? Экранирование везде и всюду или же «фильтровать входные данные»?

Описал тут:
http://blog.kpitv.net/article/об-автопреобразовании-спецсимволов-в-html-сущности-15412/

Кратко:
Зависит от ситуации, но нужно иметь в виду, что «экранирование» не панацея, а также оно может быть неуместным.
Если у вас используется mysql_* функции

Это обертки, так как в php7 их удалили.
как защищаетесь от sql инъекций

Даже в нативных mysql_* ф-ях можно защититься от sql инъекций экранированием.
mysqli_* экранирование.
Подготовленные выражения не рассматриваю.
Эмулированные подготовленные выражения == экранирование, а большинство такие и использует (так как это настройка по умолчанию), а также они быстрее.
Помниться собеседовал чувачка, он тоже с другом «ядро» написал, и там все это решалось «тихим» выпиливаем «лишних» символов. То есть по какой-то причине я не могу использовать пароль с кавычками в его системе.

Всякое бывает :)
Меня тоже очень бесит, когда в ИБ (некоторых других важных сайтах) используются надуманные ограничения на пароли. Потом попробуй запомни этот пароль.
А также пароли стоило бы хранить с посоленными хешами.
Многие, даже раскрученные ресурсы, допускают эту багофичу.

А также бесит, когда срабатывает автозащита, и ты не можешь отправить кусок кода. :)
>Осталось 4кБ: автолоадер, события, MVC. То есть осталось голое ядро.

Что-то похожее на реальность. Правла все-равно как-то много. Автолоадер точно можно перекинуть в composer.

>Зачем мне тянуть мусор, если можно реализовать все самому под себя

Так вы и тянете мусор))))))

>Проще нарастить мускулы этому ядру, а не подпирать костылями фреймворк

А правильнее все «мускулы» оформлять отдельными пакетами и использовать только по необходимости ;)

>Кстати, зачем f3 имеет pingback? :)

Без понятия, не пользуюсь ;)

>Да и размеры на гитхабе побольше, даже если не считать «демо» информацию.

Так вы смотрите только код, без документаций и примеров ;)
Автолоадер точно можно перекинуть в composer.

Можно, но я не совсем давно только переехал на ВДС, и то по причине того, что хостер выгнал из-за абуз :)
Так вы и тянете мусор))))))

Не выдумывайте. Или Вы вообще код не пишете?
А правильнее все «мускулы» оформлять отдельными пакетами и использовать только по необходимости ;)

В теперешних 50 кБ действительно много лишнего, я этого не скрываю.
Так вы смотрите только код, без документаций и примеров ;)

Так я так и смотрел.
Любой код, если его много, сложно поддерживать.

Именно. И фишка фреймворка в том что вам не нужно его поддерживать самостоятельно. Для этого у этого фреймворка огромное комьюнити. И именно в этом профит. Чем больше людей юзают тулзу — тем надежнее оно с точки зрения поддержки.


У меня его вообще нету. Шах и мат! :)

да да, как в 2008-ом, .htaccess и реврайты. А как весело это все тестировать, просто сказка.


Если Вы такой мастер, то почему не создали свой Симфони с блекджеком и шлюхами? :)

Если бы мне отвечать на этот вопрос, то просто потому что я ленивый. Мне в симфони что-то не нравится — я это не юзаю и юзаю какой-нибудь другой компонент. Для запросов мне понравилось в laravel но не понравилось то что слишком много обязанностей — написал простенькую либу которая упростила мне жизнь уже не на одном проекте. И да, это делалось не от балды а как общее решение команды и реакция на проблему которая у нас вставала каждый божий день.


Явного наследования типа extends нету, но есть минимум 2 способа «наследовать», то есть иметь/изменять т. н. родителя.

То есть… неявное наследование? Или все же композиция/декорация? При последнем у вас таки явное наследование есть (implements), только так можно с подтипами играться.


Сколько там занимает crud у Доктрины? :)

0 байт. Там нет "круда". Там есть DBAL и ORM + еще библиотеки для кешироваия и вообще весь проект доктрины ориентируется на persistence layer в любой его ипастаси.


Ну и справедливости ради — ORM-ка там шикарная, для ОО-first решений и прототипирования приложений со сложной логикой (что бы накидать быстро модель предметной области а базу — ее можно сгенерить).

Именно. И фишка фреймворка в том что вам не нужно его поддерживать самостоятельно.

Но у меня мало кода. :)
Разговор был больше о коде приложения, а не ядра/фреймворка, типа предыдущему оратору сложно разбираться в событиях, когда и много.

да да, как в 2008-ом, .htaccess и реврайты.

А потом получаем примерно такое https://habrahabr.ru/post/309436/ с единой точкой входа в конфиге по умолчанию :)

Если бы мне отвечать на этот вопрос, то просто потому что я ленивый.

Я тоже ленивый. :)

Мне в симфони что-то не нравится — я это не юзаю и юзаю какой-нибудь другой компонент.

Мне не нравится ядро фреймворка. :)
Если вамнравится, то используйте, я ж никому не запрещаю. И в который раз повторяю, что говорю прежде всего как разработчик, пищущий код для себя.
Написал свое в 4кБ и нарастил функционалом, которого нет на фреймворках.
Кто-то использует скомпилированные либы, кто-то компилит с нужными настройками, кто-то вносит патчи.
Кто-то использует панель управления для сервера, кто-то управляет из консоли.
В каждом подходе есть плюсы и минусы. Больше плюсов — используем, больше минусов — не используем.

При декорации у вас таки явное наследование есть (implements)

Вообще-то декорация кода не требует implements (интерфейса?). Достаточно __cal().
Как Вы видите в «наследовании» шаблонов композицию/декорацию?

Как бы можно сказать, что, шаблон экшена контроллера наследует шаблон основного макета.

Ну и справедливости ради — ORM

Я не люблю эту абстракцию :) Оно может иногда и удобно (по работе), но можно решать задачи и другими способами. Не стоит все пытаться реализовать с максимальной приближенностью к реальности (как тут: https://habrahabr.ru/company/jugru/blog/308914/ )

Но у меня мало кода. :)

это не отменяет того что вам нужно постоянно искать/фиксить баги и дыры в безопасности. А так за вас это комьюнити делает (ну и вы помогаете чуть-чуть)


Разговор был больше о коде приложения, а не ядра/фреймворка, типа предыдущему оратору сложно разбираться в событиях, когда и много.

По поводу событий… На событиях можно легко сделать очень плохо. Есть варианты при которых это все красиво но надо знать что делать и когда. В целом желательно их не использовать но ивенты резко понижают связанность системы, потому иногда это профитно. Главное понимать плюсы и минусы. В большинстве же случаев люди фигачат где не надо хуки аля вордпресс и потом завязывают логику на них и потом это становится неявным адом.


ивенты между компонентами — норм. Ивенты для системных вещей — норм. А вот ивенты в пределах модуля вместо явных вызовов методов — не норм.


Мне не нравится ядро фреймворка. :)

что такое "ядро фреймворка"? У симфони вон есть http-kernel (самое близкое по значению слова к ядру) но как бы… это не совсем "ядро", это точка входа. Оно не умеет ничего кроме как выстраивать пайплайн обработки http запросов. Например оно ничего не знает о маршрутизации и т.д. О контроллерах не очень знает. И вы можете вокруг делать что вздумается.


Кто-то использует панель управления для сервера, кто-то управляет из консоли.

Не передергивайте. Мы обсуждаем вполне конкретные вещи а не абстрактную чушь. Ваш пример тут не подходит. Это звучит как "кто-то использует по суитации а мне просто велосипеды нравятся".


В каждом подходе есть плюсы и минусы.

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


Вообще-то декорация кода не требует implements (интерфейса?). Достаточно __cal().

при таком раскладе вся иерархия типов летит лесом.


Как Вы видите в «наследовании» шаблонов композицию/декорацию?

принцип open/close. Добавить поведение не меняя код. И без наследования.


Как бы можно сказать, что, шаблон экшена контроллера наследует шаблон основного макета.

Это наследование в шаблонах, реализуемое руками. И его можно заменить композицией шаблонов.


Я не люблю эту абстракцию :)

есть DAO, table gateway если вам нравится работать с табличками и рядами. Мне вот нравится строить логику предметной области нормально, но да, на сайтиках и бложиках это не нужно.

это не отменяет того что вам нужно постоянно искать/фиксить баги и дыры в безопасности. А так за вас это комьюнити делает (ну и вы помогаете чуть-чуть)


Это не панацея, дыр всегда можно наделать в своем коде, особенно думая, что фреймворк защищает.
А также куча дыр в том же ВП и Джумла, они ж вроде опенсорс.

А также факт использования общеизвестной системы делает убирает Security through obscurity.

В большинстве же случаев люди фигачат где не надо хуки аля вордпресс и потом завязывают логику на них и потом это становится неявным адом.

А вот ивенты в пределах модуля вместо явных вызовов методов — не норм.

Это крайность, в которую впадать не стоит. :)

что такое «ядро фреймворка»?

Ответ:
То, без чего или с другой реализацией чего, по сути это уже другой фреймворк, как Ларавел и Симфони.

То, что задает тон использования.

Это звучит как «кто-то использует по суитации а мне просто велосипеды нравятся».

У меня нету велосипедов.
С таким успехом любой написанный код можно назвать велосипедом. Типа, берите и пользуйтесь вк/фб как своим сайтом :)
Я не против библиотек.

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

Возможно это парабола? :)

при таком раскладе вся иерархия типов летит лесом.

Так меньше программировать. :)
У нас так на работе сделано :)

принцип open/close. Добавить поведение не меняя код. И без наследования.

Код не меняется. В случае с шаблоном добавляется кусок html.
Я имел в виду, как наследование шаблонов реализуется с пощью композиции/декорации.

есть DAO, table gateway

Мне все абстракции не нравятся :)
Мне нравится быть ближе к уровню БД. Передал параметры, а построитель запросов все построил. Во фреймворках построители запросов немного запутывающие с лишним специфичным функционалом. Хотя я уже нашел, что в них можно делать то, что нужно.
Я говорю о ф-ях типа orWhere/andWhere, find/findAll/findByPK/findAllByPk.

К примеру в jquery для ajax лучше использовать $.ajax вместо $.(get|post)
Вы что используете? :)
>По поводу событий… На событиях можно легко сделать очень плохо. Есть варианты при которых это все красиво но надо знать что делать и когда. В целом желательно их не использовать но ивенты резко понижают связанность системы, потому иногда это профитно. Главное понимать плюсы и минусы. В большинстве же случаев люди фигачат где не надо хуки аля вордпресс и потом завязывают логику на них и потом это становится неявным адом.

Во! Правильное формирование мысли!

>А также куча дыр в том же ВП

А ну поподробнее… Лет 5 уже не слышал о дырах именно в wp, может что пропустил?

>То, что задает тон использования.

Это называется codestyle, а не фреймворк)

>У меня нету велосипедов.

Ага, в этом уже все убедились)))))))))))))))

>Так меньше программировать. :)
>У нас так на работе сделано :)

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

Еще одна ложь)))))) Где это мне «сложно разбираться»?))) Лгунишка мелкий)

>А потом получаем примерно такое https://habrahabr.ru/post/309436/ с единой точкой входа в конфиге по умолчанию :)

Ага, только там проблема кривых рук, а не кода ;)

>Мне не нравится ядро фреймворка. :)

Говорите как есть, нечего увиливать — «не осилил» ;)

>Если вамнравится, то используйте, я ж никому не запрещаю.

У вас кто-то разрешение спрашивал? о_О

>которого нет на фреймворках.

И слава всем богам…

>Достаточно __cal().

Ёптвоюмать… Да не дай… это юзать…

>Как бы можно сказать, что, шаблон экшена контроллера наследует шаблон основного макета.

«Наследует»?! Имеет доступы к параметрам и методам?
Во! Правильное формирование мысли!

То есть Вы фигачили хуки где не надо, а потом они оказались плохие? :)

Еще одна ложь)))))) Где это мне «сложно разбираться»?))) Лгунишка мелкий)

Вы постоянно лжете и выдумываете, а потом кого-то обвиняете во лжи.
Даже цитаты бессмысленно приводить, все равно будете отверчиваться.

У вас кто-то разрешение спрашивал? о_О

Ну так пользуйтесь себе на здоровье.

И слава всем богам…

И еще будете говорить, что мне нужно пользоваться фреймворками, хотя там нету нужного функционала?

Ёптвоюмать… Да не дай… это юзать…

Имелось в виду __call().
Не пользуйтесь, дублируйте код.

«Наследует»?! Имеет доступы к параметрам и методам?

У шаблонов бывают методы?
>То есть Вы фигачили хуки где не надо, а потом они оказались плохие? :)

Снова какой-то глупый вывод)). Перечитайте предложение Fesor-а ;)

>
И еще будете говорить, что мне нужно пользоваться фреймворками, хотя там нету нужного функционала?

Вообще, вам другое говорят: не нужен этот функционал в фреймворках, он должен быть отдельно, в виде подключаемых модулей. ;)

>Имелось в виду __call().

Я понял. Повторю: «Ёптвоюмать… Да не дай… это юзать…».

>Не пользуйтесь, дублируйте код.

о_О Как связано отсутствие дублирования кода и __call?! о_О

>У шаблонов бывают методы?

Вы не поверите…
Снова какой-то глупый вывод)). Перечитайте предложение Fesor-а ;)

У Вас же их было много, видимо использовали к месту и не к месту. :)

Кстати, асинхронные микросервисы — это по сути те же события (которые до этого у Вас были синхронными). :)

И Fesor использовал событие (предлагаемый способ зайти через дверь) вместо наследования (залезть через окно). :)

Кстати, как будете поступать в случае, если наследуемый метод использовал приватный метод или был final? :)

А ну поподробнее… Лет 5 уже не слышал о дырах именно в wp, может что пропустил?

Я за ним особо не слежу, может в плагинах.

Это называется codestyle, а не фреймворк)

Стиль кода как бы в каждой команде может быть свой. :)

Ага, только там проблема кривых рук, а не кода ;)

Это конфиг по умолчанию!

Говорите как есть, нечего увиливать — «не осилил» ;)

Ну почему же. Я его использую по работе.
Но для меня лично оно не подходит.
Как-то глупо брать неподходящий инструмент.

о_О Как связано отсутствие дублирования кода и __call?! о_О

Если не использовать __call, то нужно мапить все методы и следить за добавлением новых методов.
Я называю это псевдопрограммированием. :)

Вы не поверите…

Кто такое использует?

В twig наследуется так:
{% extends "base.html" %}

Или там
{% block title %}Index{% endblock %}

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

не совсем так. И не притягивайте микросервисы в эту тему.


Если не использовать __call, то нужно мапить все методы и следить за добавлением новых методов.
Я называю это псевдопрограммированием. :)

у меня на интерфейс один-два публичных метода. Что там дублировать то? Зачем следить? Если у вас 10 методов на интерфейс это нормально — то перечитываем чего про Single Responsibility и т.д. А использование __call подразумевает тот факт, что вы не используете интерфейсы и не строите иерархию типов. А это в свою очередь резко снижает уровень надежности системы и удобство работы с ней.


Так что давайте не будем впадать в крайности. Все должно быть сбалансировано.


Кстати, как будете поступать в случае, если наследуемый метод использовал приватный метод или был final? :)

Эм… а какое мне дело? это деталь реализации метода, мне об этом смотря на интерфейс знать не интересно и не нужно. В этом весь смысл инкапсуляции.


И Fesor использовал событие (предлагаемый способ зайти через дверь) вместо наследования (залезть через окно). :)

я использовал события потому что это единственный способ вклиниться в пайплайн. В laravel я бы использовал мидлвэры (функции по сути). Ну то есть причем тут это? События нужны там где нужны а вы несете абстрактную чушь.


Короч это уже не интересно… весь этот разговор напоминает дискусии между атеистами и католиками. Там когда кто-то сливается и нужно просто что-то сказать начинается абстрактный бред.

не совсем так.

Так я и не говорю, что совсем так :)

у меня на интерфейс один-два публичных метода.

__destruct и __construct? :)
Зачем классы с 2-мя методами? :)
Остальные методы приватные?

Если у вас 10 методов на интерфейс это нормально

Вполне нормально. Лучше, чем 100500 классов.

А использование __call подразумевает тот факт, что вы не используете интерфейсы

И что тут страшного? :)
Можно проверить существование метода у декорируемого перед вызовом.
Кому что удобно :)

Эм… а какое мне дело?

Я задавал вопрос не Вам… :)

я использовал события потому что это единственный способ вклиниться в пайплайн.

Но могли же отнаследоваться :) Но я не с Вами спорю по этому поводу.

весь этот разговор напоминает дискусии между атеистами и католиками

Я тоже давно это заметил :)
Так я и не говорю, что совсем так :)

Вы как бы вообще ничего конкретного не говорите. Вы просто выворачиваете фразы и т.п.


Зачем классы с 2-мя методами? :)
Остальные методы приватные?

У меня у большинства интерфейсов вообще только один метод. У меня к вам другой вопрос — а вам нужно больше почему-то?


Что до приватных методов — они потому приватные что знать о них как пользователь объекта вы не должны.


Вполне нормально. Лучше, чем 100500 классов.

Чем это лучше?) Вы возможно удивитесь, но снижая связанность системы и повышая специализацию объектов мы сильно упрощаем потом внесение изменений в систему. Да и проверять проще, и рефакторить.


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


Можно проверить существование метода у декорируемого перед вызовом.

а смысл проверять? Метода нет — мы в любом случае падаем. Просто использование нормальной иерархии типов позволяет выявить проблемы ДО запуска приложения, а это может быть важно. Ну и повторюсь — когда у вас только один метод и задекорировать нужно только его — ну как бы все легко и просто.


Я задавал вопрос не Вам… :)

Вы в дескуссии приплетаете мое имя. Тогда попрошу на меня не ссылаться и уж тем более не вырывать из контекста фразы или реализацию.

У меня у большинства интерфейсов вообще только один метод.

Это ж не значит, что у всех должен быть только один метод.

https://habrahabr.ru/post/140581/

Просто использование нормальной иерархии типов позволяет выявить проблемы ДО запуска приложения

У нас автрозагрузка, что мы проверим?
Мы же пишем тесты (проверяем вручную), и так будет видно, что упало.

Вы в дескуссии приплетаете мое имя. Тогда попрошу на меня не ссылаться и уж тем более не вырывать из контекста фразы или реализацию.

Что я вырвал из контекста, то что Вы использовали события, а не наследование? :)

П.С,
Возможно, вы все сами на 4 стадии :)
>Кстати, асинхронные микросервисы — это по сути те же события (которые до этого у Вас были синхронными).

Мдя… Fesor ответил на это довольно развернуто.

>И Fesor использовал событие (предлагаемый способ зайти через дверь) вместо наследования (залезть через окно). :)

Я вам больше скажу — я их тоже использую (посмотрите phalcon или kohana например) ;). Я-бы не считал, что события лучше или хуже наследования — это разные вещи, используемые в разных случаях.

>Кстати, как будете поступать в случае, если наследуемый метод использовал приватный метод или был final? :)

Никак. final/private ставятся не просто так)

>А также куча дыр в том же ВП
>Я за ним особо не слежу, может в плагинах.

Т.е. лишь-бы ляпнуть?))))))) Не меняетесь ни капли)

>Это конфиг по умолчанию!

Серьезно?!

>Как-то глупо брать неподходящий инструмент.

Согласен, но это не означает, что все фреймворки плохие, если вам не подошел один. Согласны?

>Если не использовать __call, то нужно мапить все методы и следить за добавлением новых методов.

о_О Вот это каша в голове…

>Кто такое использует?

Много кто. Например так: $this-getContent() или $this->widget->render(). Вариантов много, но вы никак не хотите воспринимать, что есть что-то намного удобнее вашего)

Мдя… Fesor ответил на это довольно развернуто.

Он по сути ничего не ответил… :)

Никак. final/private ставятся не просто так)

Я не говорю, что наследовали приватный метод. А публичный, который использует приватный в родителе.
То есть решетка на окнах Вас все таки бы остановила? :)

Т.е. лишь-бы ляпнуть?))))))) Не меняетесь ни капли)

https://habrahabr.ru/post/256863/
Ну и google

Серьезно?!

https://symfony.com/doc/current/setup/web_server_configuration.html
<IfModule mod_rewrite.c>
Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]



Согласен, но это не означает, что все фреймворки плохие, если вам не подошел один. Согласны?

Так Вы ж говорите, что и правильно, что на фреймворках нету того, что мне нужно…
Вообще-то я Yii для себя и не примерял, а использовал по работе. Поэтому о нем могу судить более конкретно. Об остальных хватило документации.
Я не говорю, что они плохие, я говорю, что мне, как разработчику, который пишет код для себя, они не подходят.

Много кто. Например так: $this-getContent() или $this->widget->render().

Кроме Вас под наследованием шаблонов вряд ли кто-то понимает переопределение этих функций :)

П.С.
Веселый у хабра парсер, даже в теге код нельзя писать код :)
>Он по сути ничего не ответил… :)

Перечитайте ;)

>То есть решетка на окнах Вас все таки бы остановила? :)

Нет, но я не бросаюсь под поезд. ;)

>https://habrahabr.ru/post/256863/
>Ну и google

Спасибо.

>https://symfony.com/doc/current/setup/web_server_configuration.html

При чем тут настройки веб-сервера?))))) Там кривые руки разработчика. Запрос к favicon идет с помощью get, без доп.параметров. Как он умудрился с помощью этого запроса обновить данные в базе?!)))))))

>Я не говорю, что они плохие, я говорю, что мне, как разработчику, который пишет код для себя, они не подходят.

Вы только об этом и говорите + спамите. Если-бы вы подобное не говорили — не было-бы этого диалога ;)

>Кроме Вас под наследованием шаблонов вряд ли кто-то понимает переопределение этих функций :)

Это не наследование, это доступ к методам в шаблоне — вы же об этом спрашивали. Теперь технично пытаетесь срулить))))
При чем тут настройки веб-сервера?)))))

Они корень проблемы. Если favicon нету, то не должен подниматься фреймворк…

Как он умудрился с помощью этого запроса обновить данные в базе?!)))))))

Я тоже в той статье об этом интересовался :)

Вы только об этом и говорите + спамите. Если-бы вы подобное не говорили — не было-бы этого диалога ;)

Так что, мне все таки не стоит смотреть на другие фреймворки, так как там все равно нету того, что мне нужно? :)
Как-то подло говорить, а посмотри-ка еще фреймворк A, зная, что там нету искомого. Сусанины :)
Я не понимаю, почему Вы пытаетесь меня переубедить, что мне нужно использовать фреймворки? :) Это напоминает уже упомянутый спор атеиста и католика :)

Это не наследование, это доступ к методам в шаблоне — вы же об этом спрашивали. Теперь технично пытаетесь срулить))))


Я понял, что под этим
«Наследует»?! Имеет доступы к параметрам и методам?

Вы понимаете наследование методов.

Но и зачем эти методы вызывать в шаблонах? :)
асинхронные микросервисы — это по сути те же события

Меняй барыгу, пока не поздно.
Кстати, как будете поступать в случае, если наследуемый метод использовал приватный метод или был final? :)

private — это модификатор, явно указывающий: «тебе это трогать во вне текущего класса не надо».
final — это модификатор, явно указывающий: «тебе нельзя тут ничего менять».
Я за ним особо не слежу, может в плагинах.

слив засчитан
А потом получаем примерно такое https://habrahabr.ru/post/309436/ с единой точкой входа в конфиге по умолчанию :)

Ага, только там проблема кривых рук, а не кода ;)

Это конфиг по умолчанию!

Если сервер настроен криво — это значит, что руки кривые.
Если не использовать __call, то нужно мапить все методы и следить за добавлением новых методов.

Если без __call вот вообще никак — у вас архитектура днище. __callStatic — это еще хуже. Про существование этих методов стоит в принципе забыть.
private, final

Я не предлагал их менять.
Предыдущий оратор хотел менять метод, допустим, что публичный.
Так вот, мне было интересно, как он будет его менять, если в родителе этот метод использовал другие private/final методы.

слив засчитан

Перечитайте ответ предыдущему оратору.

Если сервер настроен криво — это значит, что руки кривые.

Я не спорю, что руки кривые, просто это конфиг по умолчанию. :)
Многие фреймворщики (до этого не написавшие ни строчки кода на PHP, поддавшиеся пропаганду) думают, что используя фреймворк они за бетонной стеной.

Если без __call вот вообще никак — у вас архитектура днище.

В большинстве случаев без __call можно обойтись, дублируя код.
call_user_func* тоже сотона мохнатая придумала? :)

Но вот например мы хотим подключать js-скрипты. Наличие скрипта проверяется сначала в папке шаблона (если нужна специфичная версия), потом в шаблоне по умолчанию, потом в папке по умолчанию.
Скрипт подключается допустим по
$JS->>jquery();
или
$JS->>jquery_cookie();

Мы просто проверяем, существуют ли нужные скрипты в папке $method.
Нам не нужно при добавлении нового скрипта доопределять методы, не нужно их переименовывать при переименовании папок.
Так вот, мне было интересно, как он будет его менять, если в родителе этот метод использовал другие private/final методы.

1) я говорил о декорации а не о наследовании так что final нам не помеха
2) private — деталь реализации о которой я ничего знать не должен. Он потому и private. Представьте что вы подключаете либу и у вас есть автокомплит. Так вот, приватные методы (или protected методы) этот автокомплит вам показывать не будет. Так же как этих методов не будет в документации. Просто потому что это деталь реализации и вам как пользователю объектов этого класса это знать не нужно.


Давайте я вам про историю появления этих кастылей в виде модификаторов доступа вообще расскажу.


Короче был такой язык — Си, и в нем все было клево с точки зрения инкапсуляции. Есть header файлы (.h файлики которые) и были файлы с реализацией (.c). Все публичное, интерфейс, описывалось в заголовочных файлах. В итоге если мы пишем кусок приложения, мы можем собрать его в библиотечку (.so, .dll) и поставить вместе с заголовочным файлом (для линковки приложения). И суть инкапсуляции будет заключаться в том, что когда вы пересобираете библиотечку, если у вас не меняется интерфейс а только то как оно что там делает, то вы можете просто заменить файлик библиотечки (.so, .dll) и при этом нам не нужно пересобирать весь проект.


Так вот, был один чувак который решил что "надо ООП" в Си замутить. И он замутил! Вот только теперь для того что бы все было ок надо было в заголовочных файлах прописывать классы вместе с приватными полями и т.д. И что бы это как-то хэндлить придумали модификаторы доступа, которые на уровне компилятора гарантируют нам какую-то инкапсуляцию. Но проблема в том, что теперь детали реализации вытеклли в интерфейсы, в заголовочные файлы, и по итогу вся инкапсуляция нагнулась.


В языках типа Java/C#/PHP и т.д. этот пример уже не столь показателен — там нет таких проблем и такого явного разделения. Точнее там есть явные интерфейсы и все хорошо. Но суть остается той же. У нас все еще есть какие-то пакеты, компоненты и т.д. У них есть интерфейсы. И мы должны иметь возможность тупо заменить версию компонента так, что не придется переписывать ни строчки кода, который использует эти компоненты.


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


Надеюсь вы теперь хоть немного начали понимать что такое инкапсуляция и зачем она нужна. Мысль то простая, но почему-то все ее ломают. Есть даже мнение что "классы" сломали идею ООП потому как всякие там люди слишком много знают о нутрах их объектов и им сложно представить что они знают только о публичных методах когда работают со своим же кодом.


Перечитайте ответ предыдущему оратору.

Что именно, укажите, ибо я там ничего по делу не нашел.


В большинстве случаев без __call можно обойтись, дублируя код.

в каком месте код дублируется?


Ну и да, дубирование кода (если вы с намеком на DRY) это не проблема, проблема — дублирование логики. Полностью пытаться избавиться от дублирования кода смысла нет. Пример — контроллеры. Там куча однотипного кода как правило, но мы не стремимся избавляться там от дублирования ибо логики там как бы нет, а у нас всегда есть возможность быстро что-то поменять.


А когда у нас у интерфейса ОДИН публичный метод и нам нужно только его задекорировать (я говорю об интерфейсах а не о классах, у меня есть класс который реализует 5 интерфейсов потому что я ленивая жопа, но вся система думает что все хорошо), то никакого дублирования и быть не может.


call_user_func* тоже сотона мохнатая придумала? :)

call_user_func — это для динамической диспетчеризации. Это дело нужно там где собственно нужна динамическая диспетчеризация. А для декорации это не нужно. Метод __call можно использовать для динамических проксей но это очень специфичные задачи обычно требущиеся для тестирования или организации lazy инициализации.


Но вот например мы хотим подключать js-скрипты.

Вы сейчас про сахарок? Почему бы вместо неявного jquery() не заюзать какой явный package('jquery')? И автокомплит будет работать и читается удобно.


А вообще всю эту фронтэнд чушь лучше хэндлить правильными тулзами. Вся инфраструктура уже готова и реализована на ноде, а "вставлять скрипты" удобнее тулзами вроде gulp-inject и подобными. Оно вам и critical-path css заинлайнит в страничку, и скрипты вставит куда надо… удобно ж!

1) я говорил о декорации а не о наследовании так что final нам не помеха

Предыдущий оратор, это не Вы, а aktuba:
А можно наследоваться и переделать реализацию. И этот вариант будет проще поддерживать и отлаживать, чем вариант с событиями. Не говоря уже о том, что события иногда вообще вредны.


Что именно, укажите, ибо я там ничего по делу не нашел.

Это я писал index0h, ему стоило перечитать о багах в ВП:
https://habrahabr.ru/post/256863/
Ну и google


Полностью пытаться избавиться от дублирования кода смысла нет. Пример — контроллеры. Там куча однотипного кода как правило, но мы не стремимся избавляться там от дублирования ибо логики там как бы нет, а у нас всегда есть возможность быстро что-то поменять.

В контроллерах дублирование логики. :)
Но это сложно назвать дублированием логики.
При изменении в одном контроллере это вряд ли должно менятся в другом.
Я говорю об: установка заголовка страницы, лейаута, хк.
А что Вы имеете в виду? :)
Кстати, в моих контроллерах нету дублирования по части рендеринга. :)
А также можно описать повторяемую логику в базовом контроллере и отнаследоваться от него, если это целесообразно.

Вы сейчас про сахарок? Почему бы вместо неявного jquery() не заюзать какой явный package('jquery')? И автокомплит будет работать и читается удобно.

Автокомплита на параметр не будет, а нам только он важен.
Вообще-то эту вещь писал не я. Но использовал.
А также в случае с методами, мы можем просто определить метод, если понадобится более сложная логика, а не плодить if/case.

В догонку:
Вы не откоментили https://habrahabr.ru/post/140581/
на счет классов с одним методом (и не только).
Так вот, мне было интересно, как он будет его менять, если в родителе этот метод использовал другие private/final методы.

Еще раз: менять нельзя.


Я не спорю, что руки кривые, просто это конфиг по умолчанию. :)

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


В том же nginx+php-fpm в принципе отсутствует поддержка динамической настройки сервера.


Многие фреймворщики думают, что используя фреймворк они за бетонной стеной.

Верно, но смею заметить, что вы со своим 50к ядром точно в такой же ситуации))


В большинстве случаев без __call можно обойтись, дублируя код.

неа)) Есть интерфейсы, наследование, DI,...


call_user_func* тоже сотона мохнатая придумала? :)

Если посмотреть, что callable — это function/string/array[string,string]/array[object,string], да это очень опасная конструкция. Лучше уже тайпхинтинг на \Closure


Наличие скрипта проверяется сначала в папке шаблона (если нужна специфичная версия), потом в шаблоне по умолчанию, потом в папке по умолчанию.

Вы изначально хотите каку сделать)) Под статику достаточно реализовать маппинг и уже на его основании делать сборку. __call тут ну вот ни капли ни при чем.


Мы просто проверяем, существуют ли нужные скрипты в папке $method.

этот подход — днище.


Нам не нужно при добавлении нового скрипта доопределять методы, не нужно их переименовывать при переименовании папок.

Все верно, но и магия тут тоже вот ни капли не нужна)).

Если вы в проекте дописываете .htaccess — это нихрена не конфиг по умолчанию

Я для чего давал ссылку на документацию?

В том же nginx+php-fpm в принципе отсутствует поддержка динамической настройки сервера.

Та плевать. Там что, конфигов нету? :)

Верно, но смею заметить, что вы со своим 50к ядром точно в такой же ситуации))

Я не говорю, что мое ядро защищает.
Я говорю, что нужно думать.
htmlspecialchars() — не 100% гарантия от XSS.
То что фреймворк защищает от SQL-инъекций (ибо работает через PDO) не означает, что он защичит, если пихнуть plain SQL.
А также гораздо проще самому обеспечить безопасность 50 кБ, нежели надеятся, что это сделают за тебя другие в 20 МБ. Кто-то проводит аудит фреймворков самостоятельно?

Вы изначально хотите каку сделать)) Под статику достаточно реализовать маппинг и уже на его основании делать сборку. __call тут ну вот ни капли ни при чем.

Вы не дочитали.
У нас может быть 100500 скриптов, которые динамично меняются.
Мапить 100500 скриптов это псевдопрограммирование, да и Fesor говорил, что в классе должен быть только 1 публичный метод :)

этот подход — днище.

А как лучше? :) (Сейчас я этот подход не использую, уволился с той работы. На текущей работе нету никаких версий скриптов, все собирается gulp-ом, в личных проектах тоже все работает на одной версии)

Все верно, но и магия тут тоже вот ни капли не нужна)).

Так без магии нужно все это делать… :)
Я для чего давал ссылку на документацию?

Возможно я что-то пропустил, но ссылок на apache.org не вижу


Та плевать. Там что, конфигов нету? :)

Динамических, в стиле htaccess, htpasswd да, нету, только статические.


То что фреймворк защищает от SQL-инъекций (ибо работает через PDO) не означает, что он защичит, если пихнуть plain SQL.

Вы используете что-то в стиле green sql? Если нет — ваше ядро не решает проблему


Кто-то проводит аудит фреймворков самостоятельно?

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


У нас может быть 100500 скриптов, которые динамично меняются.

Собственно и что теперь?


Мапить 100500 скриптов это псевдопрограммирование

Вы так говорите, будто бы маппинг обязательно нужно делать руками.


А как лучше? :)

Зависит от продуктовых требований к проекту. Из основных вариантов решения этой проблемы:


  1. Использовать шаблонизатор, типа twig
  2. Вынести фронтенд в SPA
  3. Реализовать маппер, умеющий в зависимости статики И поиск по файлам. При первом запуске он просканирует, что у вас есть и положит в кэш, Далее при подключении статики — срезолвит зависимости и вернет требуемое (это тоже не плохо бы кэшировать).

  • Если не использовать __call, то нужно мапить все методы и следить за добавлением новых методов.
  • Мы просто проверяем, существуют ли нужные скрипты в папке $method.
  • Так без магии нужно все это делать… :)

Выберите что-то одно

Возможно я что-то пропустил, но ссылок на apache.org не вижу

Апачу, как бы пофиг, какой мусор под ним бегает :)

Продублирую:
https://symfony.com/doc/current/setup/web_server_configuration.html

Вы используете что-то в стиле green sql? Если нет — ваше ядро не решает проблему

Имеется в виду это?
https://habrahabr.ru/post/117375/
Я Вам так скажу — это ерунда.
Да и эта приблуда — это сторонний софт, ни какое не ядро.
Да и зачем оно в случае с подготовленными выражениями на сервере?
Да и откуда оно решает, какие запросы правильные, а какие нет? Запретите пользователю, под которым бегаете в базу, допустим менять таблицы. Это более правильное решение.
Использование этой ерунды — еще один повод не думать и ни за что не отвечать. Грохнули базу — кивнул на эту штуку и все. :)

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

Каждый читает код?
Ага, щас.
Сколько лет жила уязвимость в openssl, HTTP_PROXY (это не фреймвморки, но смысл тот же)?
Большинство код не читает и не нужно строить иллюзии. Раньше может читали больше.

Вы так говорите, будто бы маппинг обязательно нужно делать руками.

Ок, прошлись по всему чему только можно и сгенерировали файл.
Но этот файл нужно перегенерировать, если что-то изменилось.
А так сказали френтэндерам, что вызывать и ничего не нужно перегенерировать.
Если файл будет автогенерироваться, то трудно будет вносить изменение в определенные методы по необходимости.
Нужно будет помнить, что этот файл под генератором и нужно поправить генератор. :)

Все это — дополнительное программирование, не дающее плюсов.

Использовать шаблонизатор, типа twig

Он сумеет понять, что запросе jquery нужно подключить файлы из папки jquery, но не факт, что все, а только те, что описаны в метафайле из этой папки? При этом не обязательно с папки с текущим шаблоном. Есть 2-фоллбек папки.

Вынести фронтенд в SPA

Разве скрипты не нужно подключать при этом? :)

При первом запуске он просканирует, что у вас есть и положит в кэш

Большинство скриптов не используется, это будет один большущий элемент кеша.
Нужно запрограммировать обход и правильную укладу/выборку в кеш.
А еще кешировать результат.
А также кеши у сайтов изолированы. То есть общую папку, в который лежит большинство скриптов, нужно дублировать всем.
А также писать генератор и поддерживать его в актуальном состоянии.

Это программирование ради программирования.
Ссылки давал.
Но вы выводов не делаете, а упорно твердите одно и то же.
Разве скрипты не нужно подключать при этом? :)

SPA — это отдельное приложение, оно вообще в отдельном репозитории у меня например живет. Ну то есть оно про похапэ вообще ничего не знает.

1. Действительно, логику подключения скриптов можно держать на клиенте. То есть отдавать ему пути ко всем скриптам на сайте. А оно пусть само решает. Но тогда этой логикой нужно будет снабдить приложение :) Приходим туда, откуда пришли :)

1.1.
Но можно немного оптимизировать:
Отдавать только те скрипты, которые оно может использовать (и которые нефиг светить кому не нужно, а также грузить лишний json из 100500 не самых коротких путей).
Но для этого следует использовать $JS->jquery() или $JS->package('jquery'), который, ну признайте, ну вот ни чем не лучше __call() :) или использовать маппер из п.3, который тоже тянет кода.
Приходим туда, откуда пришли.

2. А можно отдавать какие скрипты нужно подключить по конкретному запросу, но тоже нужно это расчитать.
Приходим туда, откуда пришли.

То есть вы придумываете разную ерунду и сложности, которые как бы даже не совсем для решения задачи в случае с SPA (никто для обработки того, какой скрипт нужно подключить не будет делать SPA, это делают из других побуждений), лишь бы нормально не решить задачу :)

Доверь таким программистам-фреймворщикам сайт писать. :)
Действительно, логику подключения скриптов можно держать на клиенте.
Отдавать только те скрипты, которые оно может использовать
а также грузить лишний json из 100500 не самых коротких путей

2016-ый год, HTTP2, бандлеры… какой json о чем вы? Кэш браузера справится, есть масса техник оптимизирующих это добро. И забудьте о PHP, всем этим занимаются всякие webpack-и и прочие system.js.


Но для этого следует использовать $JS->jquery() или $JS->package('jquery')

Вы понятия не имеете о чем говорите, так?

То есть отдавать ему пути ко всем скриптам на сайте.

nope, клиент собирается и зависимостями рулит самостоятельно, без помощи php. Со стороны бэка грузятся только данные.


Но тогда этой логикой нужно будет снабдить приложение :) Приходим туда, откуда пришли :)

фронт должен знать из чего состоит фронт… и не поспоришь))


Отдавать только те скрипты, которые оно может использовать

Возвращайтесь в 2016-ый)) Фронт в случае SPA сам решает, что у него есть, что нужно догрузить и что нужно обновить.


Но для этого следует использовать $JS->jquery() или $JS->package('jquery'), который, ну признайте, ну вот ни чем не лучше __call() :)

Я понимаю, что ваше черезжопное решение самое прекрасное и восхитительное для вас, но в реальности эта же задача решается принципиально по другому. Почему же оно черезжопное? Да все просто:
вы на каждый запрос дергаете рекурсивно файловую систему, для HL — это самоубийственная практика. ramfs может спасти, но даст дикий оверхэд.


А можно отдавать какие скрипты нужно подключить по конкретному запросу, но тоже нужно это расчитать.

Вы понятие не имеете о чем говорите. В случае SPA бэк вообще не участвует в управлении его скриптами. С точки зрения бэка — это не более, чем просто статические файлы, которые отдаются nginx-ом. PHP в этом процессе вообще не участвует.


То есть вы придумываете разную ерунду и сложности, которые как бы даже не совсем для решения задачи в случае с SPA

Нет слов)) Ну вот серьезно, вы бы хоть чуть-чуть разобрались в том, о чем говорите))


Доверь таким программистам-фреймворщикам сайт писать. :)

Кхм, я себя сайтоделецем и не считаю)) Бэкенд инженер — уже ближе. Сайтики — это действительно не моя парафия уже года 4 как. Распределенные web системы — это то, чем я занимаюсь.

nope, клиент собирается и зависимостями рулит самостоятельно, без помощи php. Со стороны бэка грузятся только данные.

Откуда он может знать, что нужно подключить на конкретной странице, если мы решаем, нужно ли вообще подключать статику, динамически.

Ну да, энтерпрайс подход: суем всю статику подряд, а там браузер сам разберется. И плевать на трафик у клиентов. :)
Откуда он может знать, что нужно подключить на конкретной странице, если мы решаем, нужно ли вообще подключать статику, динамически.

Месседж был в контексте SPA. Прочитайте пункт Goals.


И плевать на трафик у клиентов. :)

что в воду преднул)). Трафик на оборот уменьшается.

Месседж был в контексте SPA. Прочитайте пункт Goals.

В любом случае приложение должно подсказать.
А также обработка зависимостей шаблона/сайта/языка.
Это 25*3*2 вариантов. :)

что в воду преднул)). Трафик на оборот уменьшается.

Растет за счет отдачи всей статики сразу.
А так да, я тоже такое делал.
Не весь сайт работал на SPA (вообще SPA сильно узкое обозначение), а основные разделы.
>То есть отдавать ему пути ко всем скриптам на сайте.

Lol)))

>Но тогда этой логикой нужно будет снабдить приложение :)

А еще приложение должно знать, какую рубашку вы оденете утром)

>Но для этого следует использовать $JS->jquery() или $JS->package('jquery')

Realy?!

>ну признайте, ну вот ни чем не лучше __call()

Т.е., для вас нет разницы, статика или _call… Нуууу, ок.

>А можно отдавать какие скрипты нужно подключить по конкретному запросу, но тоже нужно это расчитать.

А можно вообще этого не делать… Ой, сорри, поломал систему (((

>никто для обработки того, какой скрипт нужно подключить не будет делать SPA, это делают из других побуждений

Ага. Делают как-раз для того, чтобы не дергать приложение из-за js-скриптов. Упс, уточню сразу — дело не только в скриптах.

>Доверь таким программистам-фреймворщикам сайт писать. :)

Не говори, напишут еще, летать будет, бажить не будет… Без работы кто-то останется)
https://symfony.com/doc/current/setup/web_server_configuration.html

И где там указание, что это конфиг по умолчанию?


In the examples below, the web/ directory will be the document root..

То, что это примеры, я вижу, то что по умолчанию — не вижу.


Да и эта приблуда — это сторонний софт, ни какое не ядро.

Понятное дело, что не ядро (мы же в контексте фреймворка говорим).


Да и зачем оно в случае с подготовленными выражениями на сервере?

За тем, что


То что фреймворк защищает от SQL-инъекций (ибо работает через PDO) не означает, что он защичит, если пихнуть plain SQL.

Еще раз: если вбрасываете про что-то подумайте сначала. Ваша поделка не решает проблем, которые вы предъявляете другим фреймворкам.


Именно по этому я привел в пример софт, который действительно решает подобного рода проблемы.


Да и откуда оно решает, какие запросы правильные, а какие нет?

Конфигруация.


Запретите пользователю, под которым бегаете в базу, допустим менять таблицы. Это более правильное решение.

Привести пример, когда это решение не правильное?))


Но этот файл нужно перегенерировать, если что-то изменилось.

верно, для dev окружения обычно отключается кэширование.


Если файл будет автогенерироваться, то трудно будет вносить изменение в определенные методы по необходимости.

Вы никогда не замечали, что в сгенерированный код обычно пишется комментарий в стиле "код сгенерирован, не надо его менять"?


Все это — дополнительное программирование, не дающее плюсов.

Подумайте еще разок.


Он сумеет понять, что запросе jquery нужно подключить файлы из папки jquery, но не факт, что все, а только те, что описаны в метафайле из этой папки?

Перефразирую ваш вопрос: а если я не правильные данные в программу введу, она даст правильный результат?


Разве скрипты не нужно подключать при этом? :)

На бэкенде — нет.


Большинство скриптов не используется, это будет один большущий элемент кеша.

И будет у вас файлик на тыщу строк, жуть какая.


Нужно запрограммировать обход и правильную укладу/выборку в кеш.

glob уже запрещен?


А также кеши у сайтов изолированы. То есть общую папку, в который лежит большинство скриптов, нужно дублировать всем.

Возвращайтесь в 2016, тут есть всякие memcached, redis, apcu,...


А также писать генератор и поддерживать его в актуальном состоянии.

Не благодари


$assets = __DIR__ . '/assets/';
$files = [];
$intertator = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($assets));

foreach ($intertator as $file) {
    if (!$file->isDir()) {
        $files[] = $file->getPathname();
    }
}

$result = sprintf('<?php $cache=%s;', var_export($files, true));

Это программирование ради программирования.

Зато дергать файловую систему ради по глупости — это отлично))


Но вы выводов не делаете, а упорно твердите одно и то же.

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


  1. Опыта работы в крупных нагруженных проектах (100rps хотя бы) у вас нет.
  2. Опыта работы с командой хотя бы из 10+ программистов у вас нет.
  3. Понимания общих принципов (SOLID например) у вас нет.
  4. Понимания общих шаблонов проектирования у вас нет.

Но у вас есть незыблемая уверенность в своих знаниях, по этому я делаю вывод:
Вы демонстрируете эффект Даннинга — Крюгера

>Опыта работы в крупных нагруженных проектах (100rps хотя бы) у вас нет.
>Опыта работы с командой хотя бы из 10+ программистов у вас нет.
>Понимания общих принципов (SOLID например) у вас нет.
>Понимания общих шаблонов проектирования у вас нет.

Так, 4-й (вроде-бы), кто ему сказал это, но толку?)))) Для него важнее меню и хлебные крошки во фреймворке, чем правильная архитектура и готовность к нагрузкам…

P.S.: «в крупных нагруженных проектах (100rps хотя бы)» — с каких пор 100rps = нагруженное приложение? Я что-то пропустил?
«в крупных нагруженных проектах (100rps хотя бы)» — с каких пор 100rps = нагруженное приложение? Я что-то пропустил?

В случае подходов, что он предлагает 100rps можно расценивать как довольно серьезную нагрузку (загрузку статики я не учитываю). Ну сами посудите:


  • на каждый запрос для подключения js/css рекурсивно бегать по файловой системе и подключать найденное, учитывая, что этой статики у него очень много.
  • кэширует ли он хоть каике-то результаты обработки — честно говоря сомневаюсь.
  • лелею надежду, что хотя бы opcache не выключает.
на каждый запрос для подключения js/css рекурсивно бегать по файловой системе и подключать найденное, учитывая, что этой статики у него очень много.

Зачем эту ерунду писать?
Зачем рекурсивно бегать по ФС? :)
Статики много, никто ее всю не подключает.

кэширует ли он хоть каике-то результаты обработки — честно говоря сомневаюсь.

Зачем? ОС сама закеширует файлик на 2 строки и факт его наличия/отсутствия. Обычно подключался 1 скрипт на страницу: jquery. Время подключения на уровне погрешности измерения.
А вот создать объект из класса 50 кБ — это на 1-2 порядка больше, хотя уже ни к какой ФС обращатся не нужно, и это учитывая php7 + opcache.
Но почему-то месье не говорят сколько ненужного мусора подключает фреймворк.

на каждый запрос для подключения js/css рекурсивно бегать по файловой системе и подключать найденное, учитывая, что этой статики у него очень много.

Зачем эту ерунду писать?
Зачем рекурсивно бегать по ФС? :)
Статики много, никто ее всю не подключает.

кэширует ли он хоть каике-то результаты обработки — честно говоря сомневаюсь.

Зачем? ОС сама закеширует файлик на 2 строки и факт его наличия/отсутствия. Обычно подключался 1 скрипт на страницу: jquery. Время подключения на уровне погрешности измерения.
А вот создать объект из класса 50 кБ — это на 1-2 порядка больше, хотя уже ни к какой ФС обращатся не нужно, и это учитывая php7 + opcache.
Но почему-то месье не говорят сколько ненужного мусора подключает фреймворк.

Для любителей преждевременной оптимизации:
Никакой нагрузки не было: спрос ограниченный, максимум 300 хостов * 3 хита в день.

Так, 4-й (вроде-бы), кто ему сказал это, но толку?)

Ребятки, это у вас 4-ый.
Это вы доказываете свою правоту, не разобравшись в вопросе.

Для него важнее меню и хлебные крошки во фреймворке, чем правильная архитектура и готовность к нагрузкам…

Подключение 1 (среднее число) 50 байтового файлика на 1 хит убъет, производительность?

Какие нагрузки на фреймворке, если они позиционируются «быстро собрать из кубиков говно, а потом перепишем, если будет нагрузка»?

с каких пор 100rps = нагруженное приложение?

А с каких следует считать нагруженным?

У меня максимум было около 66, ВПС за 6 баксов этого не почувствовал. :)

Но у вас есть незыблемая уверенность в своих знаниях, по этому я делаю вывод

Может это вы не знаете куда деть свои знания?
Пропагандируете свой оверинжиниринг. Я не собираюсь эту ерунду поддерживать.

В каких проектах вы работаете? Они нагруженные? У вас есть личные проекты? Сколько?

Опыта работы с командой хотя бы из 10+ программистов у вас нет.

Команда на 1 проект? Зачем так много? Вы в какой команде работали на проекте?

Понимания общих шаблонов проектирования у вас нет.

Зачем ими городить огород? Все должно быть оправдано.
Это вы на собеседованиях корчите из себя гуру, а потом на проекте УГ?

Зато дергать файловую систему ради по глупости — это отлично))

Загуглите «кеш ОС» и посмотрите в дебаггере сколько памяти жрет Ваш фреймворк и сколько он файлов подключил.
А мне же вы запрещаете подключить в среднем 1 файл на страницу.
В чужом глазу видите соринку, а в чужом бревно не видите.

Не благодари

Под поддерживать я имел в виду иметь возможность для определенного языка/шаблона/сайта/скрипта задействовать отдельную логику.

RecursiveIteratorIterator и RecursiveDirectoryIterator — это уже 2 универсальных файла? :)

$assets = __DIR__. '/assets/';

Вообще-то, сначала нужно проверить текущий шаблон сайта, потом шаблон сайта по умолчанию, потом общее хранилище скриптов.

То есть с разных шаблонов могут подключатся разные версии скрипта.
Иметь такой автогенерируемый файлик для каждого шаблона каждого сайта? Шаблонов у сайтов от 2 до 4 обычно. Сайтов 20-25.

if (!$file->isDir()) {
$files[] = $file->getPathname();
}

Этого не достаточно. Так вы свалите все в кучу и не будем знать, что нужно подключить.
Например, по $JS->jquery() нужно подключить сам jquery такой-то версии и jquery.migrate. Какие именно файлы из папки подключить сказано в метафайле .include. А также подключение файла может зависить от текущего языка.
Умножаем 25 сайтов * 3 шаблона * 2 языка.
Нам теперь нужно решать проблему не подключения скриптов, а подключения скрипта, который подключит скрипты :)
Ну как в том приколе, фабрика по производству фабрик фабрик. :)

Возвращайтесь в 2016, тут есть всякие memcached, redis, apcu,...

У вас скрипты лежат в мемкеше?
Месье знает толк в извращениях :)

glob уже запрещен?

glob не решает сам задачи бизнес-логики как бы.
Тут что glob, что readdir.

И будет у вас файлик на тыщу строк, жуть какая.

А ниче, что его каждый раз нужно подключать?
До этого обходились подключением 50 байтного файлика с 2 строками. Вы ж именно против этого выступали. :)

На бэкенде — нет.

Откуда фронт узнает, какой скрипт-ы соответствует jquery определенного языка/шаблона/сайта? :)

Перефразирую ваш вопрос: а если я не правильные данные в программу введу, она даст правильный результат?

Вы ерунду написали.
Какие файлы из папки jquery по запросу $JS->jquery указано в файлике .include из этой папки.

Вы никогда не замечали, что в сгенерированный код обычно пишется комментарий в стиле «код сгенерирован, не надо его менять»?

А нам нужно иметь возможность кастомизации. Все, нельзя? Не сам сгенерированный файл, а генератор, чтобы он генерировал, что нужно кастомно.

верно, для dev окружения обычно отключается кэширование.

То есть нужно тратить время и сбрасывать кеш на проде.
С __call() не нужно было :)

Привести пример, когда это решение не правильное?))

В 99% пользователю, который бегает в базу с сайта (или как вы себя называете приложения) не нужны эти запросы. :)
Под админом бегайте как хотите.

Конфигруация.

О, еще пиши тут конфигурацию. :)

Еще раз: если вбрасываете про что-то подумайте сначала. Ваша поделка не решает проблем, которые вы предъявляете другим фреймворкам.


Так и фреймворки ж не решают…

Именно по этому я привел в пример софт, который действительно решает подобного рода проблемы.

Вы его используете? :)

За тем, что

То есть не такие фреймворки и защищенные? :)
А фреймворк так и предлагает: пихни в меня plain SQL.

Понятное дело, что не ядро (мы же в контексте фреймворка говорим).

Зачем вообще его было приплетать?
Чтобы блеснуть умом? :)

И где там указание, что это конфиг по умолчанию?

То, что это примеры, я вижу, то что по умолчанию — не вижу.


Ну в самой поставке конфигов нету, потому что много серверов и способов подключения.
Но это указано в документации по настройке сервера под фреймворк, Карл!
Это стыдоба. Сидели бы как мыши под веником, а еще возмущаются.
Кстати, вот и под nginx оттуда же для реализации всеми вами любимой одной точки входа.
    location / {
        # try to serve file directly, fallback to app.php
        try_files $uri /app.php$is_args$args;
    }


Не говори, напишут еще, летать будет, бажить не будет… Без работы кто-то останется)


Сколько у вас личных сайтов?
Но это на фреймворках сайты тупят, а сделанные строго под задачу сайты летают.

Ага. Делают как-раз для того, чтобы не дергать приложение из-за js-скриптов. Упс, уточню сразу — дело не только в скриптах.

Вы серьезно?
Кеширование в браузере придумала сотона мохнатая? :)

А можно вообще этого не делать… Ой, сорри, поломал систему (((

А как фронт узнает, что jquery означает jquery.1.8.1.min.js + jquery.migrate.1.8.1.min.js?

Т.е., для вас нет разницы, статика или _call… Нуууу, ок.

Если Вы забили, то напомню.
Вам не понравилось, что я подключал статику с помощью магического $JS->jquery() через __call().

Realy?!

Тролль, почему Вы обрезали цитату:
или использовать маппер из п.3, который тоже тянет кода

То есть в любом случае городить огород. :)

А еще приложение должно знать, какую рубашку вы оденете утром)

То есть Вы слились и не можете реализовать требования.

Lol)))

Вы вообще ничего не предложили. :)

Сайтики — это действительно не моя парафия уже года 4 как. Распределенные web системы — это то, чем я занимаюсь.

Пример хоть одной системы.
web система? Значит сайт. Зачем выеживаться.

Нет слов)) Ну вот серьезно, вы бы хоть чуть-чуть разобрались в том, о чем говорите))

Для чего же делают SPA? :)

В случае SPA бэк вообще не участвует в управлении его скриптами. С точки зрения бэка — это не более, чем просто статические файлы, которые отдаются nginx-ом. PHP в этом процессе вообще не участвует.

А как фронт узнает, что jquery означает jquery.1.8.1.min.js + jquery.migrate.1.8.1.min.js?

фронт должен знать из чего состоит фронт… и не поспоришь))

Ну так проблема осталась.
Вы хотели от нее спрятаться, но добавили новых проблем.
Не было у бабы хлопот, купила порося

nope, клиент собирается и зависимостями рулит самостоятельно, без помощи php. Со стороны бэка грузятся только данные.

Каким образом он знает, какой шаблон принадлежит какому сайту? :) А также поддержание языковых зависимостей.

Вы понятия не имеете о чем говорите, так?

Я ж упомянул предлагаемый вами вариант:
или использовать маппер из п.3, который тоже тянет кода


2016-ый год, HTTP2

2016 год в 2012 году, когда это было написано. Да, сильно :)

Кэш браузера справится

Выплевавай в браузер 5 МБ скриптов, пофиг, переварит. :) Круто. Энтерпрайс-подход, епта.
Зачем эту ерунду писать?
Зачем рекурсивно бегать по ФС? :)

Но вот например мы хотим подключать js-скрипты. Наличие скрипта проверяется сначала в папке шаблона (если нужна специфичная версия), потом в шаблоне по умолчанию, потом в папке по умолчанию.

Действительно))


Зачем? ОС сама закеширует файлик на 2 строки и факт его наличия/отсутствия.

да-да, вы только подтверждаете мои слова, а не опровергаете.


С вами было весело общаться, но на этой веселой ноте давайте заканчивать. Вы как google-translate, что-то пишете, но без малейшего осознания.

>Но почему-то месье не говорят сколько ненужного мусора подключает фреймворк.

Например?))

>спрос ограниченный, максимум 300 хостов * 3 хита в день.

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

>Это вы доказываете свою правоту, не разобравшись в вопросе.

Да я тут уже 2-ю неделю разбираюсь ;). И чем дальше — тем очевиднее, что ваше поле деятельности == мелкие сайтики. Напишите, что-ли, на досуге SPA-тудушку какую-нибудь. Потом расскажете, сколько ресурсов уходит на фронтенд, а сколько на бекенд. Не-SPA не интересно ;)

>Какие нагрузки на фреймворке, если они позиционируются «быстро собрать из кубиков говно, а потом перепишем, если будет нагрузка»?

Да по разному. Сравните как-нибудь свой фреймворк с phalcon ;)

>В каких проектах вы работаете? Они нагруженные?

Сейчас zoon.ru — 300к уников в сутки, 1М хитов.
До этого — rbtaxi.ru, 2000+ онлайн пользователей круглосуточно, 12к rps в мускулю, 18-20к rps к редису, spa.
До этого — nnm.ru. При мне было 300-350к уников в сутки, 1,5-2М хитов.
Были еще, но помельче… Нагруженные эти проекты или нет?)

>У вас есть личные проекты? Сколько?

В лучшие времена было сотни полторы единовременно. Сейчас почти не осталось.

>Команда на 1 проект? Зачем так много?

Для сайтиков — 10 человек да, это много. Для более-менее среднего приложения — мало.

>Зачем ими городить огород? Все должно быть оправдано.

Поддержка приложения/модуля намного приоритетнее ежесекундной простоты кода.

>Загуглите «кеш ОС» и посмотрите в дебаггере сколько памяти жрет Ваш фреймворк и сколько он файлов подключил.
>А ниче, что его каждый раз нужно подключать?

Включите opcache уже )

>Под поддерживать я имел в виду иметь возможность для определенного языка/шаблона/сайта/скрипта задействовать отдельную логику.

о_О. «Отдельная логика подключения статики»… Я думал от подобного все отказались этак году в 2000-м…

>Вообще-то, сначала нужно проверить текущий шаблон сайта, потом шаблон сайта по умолчанию, потом общее хранилище скриптов.

Чувствуется наследние битрикса и джумлы))))))

>Так вы свалите все в кучу и не будем знать, что нужно подключить.

Открою страшный секрет — и не надо знать ;). require.js вам в помощь.

>Умножаем 25 сайтов * 3 шаблона * 2 языка.

Ух-ты… А зачем умножать на количество сайтов? Все сайтики в одной куче? Правка в коде ради одного убивает остальные?)))

>А нам нужно иметь возможность кастомизации. Все, нельзя? Не сам сгенерированный файл, а генератор, чтобы он генерировал, что нужно кастомно.

Бред…

>То есть нужно тратить время и сбрасывать кеш на проде.
С __call() не нужно было :)

Lol…

>Так и фреймворки ж не решают…

Т.е. вы согласны, что ваше поделие не лучше фреймворков, в данном вопросе? Про меню и хк помню — они идут в минус ;)

>Но это на фреймворках сайты тупят, а сделанные строго под задачу сайты летают.

Серьезно?)))) Мельком пробежался по форуму yii, надыбал самые «тормозящие»!
https://karofilm.ru/
https://www.mascotte.ru/
http://kuponator.ru/
http://www.trud.com/
http://66.ru/
https://tvrain.ru/

Думаю, каждый из них на несколько порядков нагруженнее любого вашего проекта ;). Ну и нет наверное смысла сравнивать количество функционала.
Другие фреймворки лень смотреть, как-нибудь сами гляньте ;)

>А как фронт узнает, что jquery означает jquery.1.8.1.min.js + jquery.migrate.1.8.1.min.js?

Может подумаете, прежде чем подобное писать?)))) Фронт-то как-раз знает, что ему надо, а вот бекенду этого знать не надо ;)

>Вам не понравилось, что я подключал статику с помощью магического $JS->jquery() через __call().

Не правда). Мне не понравилось вообще использование __call ;)

>То есть Вы слились и не можете реализовать требования.

Вы серьезно?))))) А зачем мне реализовывать бред? Например, вот такой: «Действительно, логику подключения скриптов можно держать на клиенте.». «Логику подключения»?! Зачем?! Давайте попробуем предположить, на ум приходят 2 варианта:

1. Слишком много статики. Скорее всего — это не ваш вариант, но все-равно рассмотрим. Предположим, есть 500 js-файлов и вы их подключаете в зависимости от страницы/языка и пр. Правильный подход — объединить скрипты в пакеты, в зависимости от условий (язык — отдельный пакет, раздел — второй пакет и т.д.) и подключать их пакетами, а не отдельно. Результат — ускорение загрузки. Пример — facebook.com.
2. Среднее количество статики. Ну пусть будет 50-100 файлов. Так-же, выгоднее оформить в несколько пакетов и отдавать все эти пакеты на всех страницах, т.к. с большой вероятностью пользователь попадет на несколько страниц и эти файлы так или иначе придется загружать.
3. Малое количество файлов. Ваш случай). Собираем в один пакет, упаковываем, отдаем с помощью gzip.

Теперь вопрос — нафига все-таки бекенд-приложению знать о статике?) Ну а вы да, реализуйте свои «требования»)))))))

>Вы вообще ничего не предложили. :)

Да пожалуйста… Хотите грузить статику по условиям? require.js вам в помощь. Хотите отказаться от условий — варианты чуть выше.

>web система? Значит сайт. Зачем выеживаться.

Ой-ой-ой… Открою страшный секрет: веб-система — не означает сайт. Да, сайт может быть частью (иногда самой маленькой, как на ats24.ru, иногда большой, как на zoon.ru), но точно эти вещи не одно и то-же. Сайт — это мелочь.

>Каким образом он знает, какой шаблон принадлежит какому сайту? :) А также поддержание языковых зависимостей.

Сами-себе придумали проблемы, героически их решаете?))) Ну удачи)
Например?))

Включите дебаггер, увидите. А также сколько это все памяти съедает увидите.

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

1. Вы даже с задачей не разобрались, а начали городить огород.
Это типа купить ребенку одежды, чтобы хватило до конца школы.
А потом или ребенок оказался карликом, или одежда пропала / не понравилась :)
2. Вы серъезно экономите на спичках порядка 1 * 10-5 с? Отправляю ознакомиться с соринкой и бревном…
Ваши костыли с кешами и прочим мусором съедят на порядки больше…

Сравните как-нибудь свой фреймворк с phalcon ;)

Сравните Симфони и phalcon.

zoon.ru

Ниче так сайт.
Но это в среднем 35rps :)
На чем?

Проекты норм, но не 100 rps :)

Для более-менее среднего приложения — мало.

Команды должны работать более менее изолировано.
У нас тоже больше 10 разработчиков, я даже не знаю сколько.
Но наша маленькая команда (5 чел) работает над одним куском.

Поддержка приложения/модуля намного приоритетнее ежесекундной простоты кода.

У вас в вакансии написано:
Знание ООП и паттернов, и умение это знание применять. Или не применять, если не нужно.


Мой ответ про паттерны.

Включите opcache уже )

Он включен по умолчанию… :)
И он живет отдельно от кеша ОС.

о_О. «Отдельная логика подключения статики»… Я думал от подобного все отказались этак году в 2000-м…

Есть задание, делаем.
Мне пофиг, что от чего отказался :)

Чувствуется наследние битрикса и джумлы))))))

А вот фреймворки в этом плане тупые.
Плохая у них поддержка многошаблонности.

require.js вам в помощь.

О, еще что-то нужно учить.
https://habrahabr.ru/post/310026/

Ух-ты… А зачем умножать на количество сайтов? Все сайтики в одной куче? Правка в коде ради одного убивает остальные?)))

Ядро общее.
Сайтики холдинга немного связаны между собой.

Т.е. вы согласны, что ваше поделие не лучше фреймворков, в данном вопросе?

Уже лучше. Мое ядро на одном уровне с фреймворками. :)
Но как бы у мое ядро не побуждает пихать plain sql, для этого есть отдельный интерфейс.

Думаю, каждый из них на несколько порядков нагруженнее любого вашего проекта ;)

На одном сайте максимум 580к хостов в месяц.
>Включите дебаггер, увидите.

Часто включаю, мусора не вижу… Так подскажете?

>А также сколько это все памяти съедает увидите.

Голый запуск? Самый минимум. Вот набросал простейшее приложение: https://gist.github.com/aktuba/752806c38452bb3d52ec692a86651a76

Вот результат:
time: 0.00045609474182129
mem: 0

Что не так делаю?)))

>На чем?

На фреймворке. Сделали его до меня.

>Сравните Симфони и phalcon.

Эмм… А что именно сравнивать?)

>Но это в среднем 35rps :)
>Проекты норм, но не 100 rps :)

Хм… Как-то вы странно rps считаете))) Ну для примера, rbt: 2к онлайн х 1-5 запросов в секунду = 2-10к rps. не?))))
Даже на zoon цифры сильно отличаются от вашего расчета, но тут знаю почему — вы до сих пор считаете, что web-система === сайт)))))))

>Команды должны работать более менее изолировано.

Зависит от проекта, привычек и пр.

>Мой ответ про паттерны.

А это вообще к чему?))) Мы вроде про паттерны не разговаривали)

>Он включен по умолчанию… :)

Тогда откуда речь о постоянном подключении php-файлов?)

>Есть задание, делаем.

Глупое задание)

>Плохая у них поддержка многошаблонности.

Ну вот в phalcon хорошая. А вообще — это лишнее. Нет в этом надобности.

>О, еще что-то нужно учить.

Ну да, вам проще костыли написать, чем выучить 2 команды: define и require)))

>Уже лучше. Мое ядро на одном уровне с фреймворками. :)

В чем-же? Можно разделить приложение на несколько уровней (front/back/api)? Без отдельных приложений, т.е. чтобы были общие модели, библиотеки, хелперы? Насколько удобно делать разный рендер из экшена (json/xml/html/text/base64)? Что с поддержкой баз данных?

>Но как бы у мое ядро не побуждает пихать plain sql, для этого есть отдельный интерфейс.

QB не интересен в принципе. Лично я юзаю plain-sql в большинстве случаев. Для простых вещей — orm/odm.

>На одном сайте максимум 580к хостов в месяц.

В месяц?! Хм… На nnm за последний месяц 1,2М уников, если верить метрике яндекса. Получается, у вас на одном сайте в районе 35к уников в сутки? И это максимум?)
Голый запуск? Самый минимум. Вот набросал простейшее приложение: https://gist.github.com/aktuba/752806c38452bb3d52ec692a86651a76

Вот результат:
time: 0.00045609474182129
mem: 0

Это Вы померяли не фреймворк, а приложение на фреймворке, которое ничего не делает :)
Нужно было взять Симфони.

На фреймворке. Сделали его до меня.

Ну так самопись, елки. :)

zoon

Я делил трафик равномерно на 30 дней * 8 часов

Зависит от проекта, привычек и пр.

Так просто проще.

А это вообще к чему?))) Мы вроде про паттерны не разговаривали)

Действительно.
Но паттерны головного мозга недалеко от ооп головного мозга и фреймворков головного мозга.
:)

Тогда откуда речь о постоянном подключении php-файлов?)

Замеряйте на досуге, сколько времени тратится на создание объекта из 50 кБ класса.

Можно разделить приложение на несколько уровней (front/back/api)

Все можно разделить.
Часть функционала на одном сайте работает через АПИ, у которого может быть 3 вида клиентов.

Насколько удобно делать разный рендер из экшена (json/xml/html/text/base64)?

А в чем проблема?
Сказал подключить другой шаблон (вид), а тот шаблон пускай как хочет, так и рендерит. :)

Что с поддержкой баз данных?

Мне достаточно mysql сейчас.
Главное, что расширения под любую БД есть в PHP.
Для простых запросов, скорее всего, не придется менять QB.
А запросы, использующие особенности базы, придется переписать, и не всегда это ограничивается только синтаксисом.
И как-то неправильно требовать от самописи, которая используется в связке с mysql, чтобы она поддерживала другие базы.

QB не интересен в принципе. Лично я юзаю plain-sql в большинстве случаев.

Хм, зря.
plain-sql порождает дублирование и раскидывание кода, усложняет поддержку.
Говорили об энтерпайсе, фреймворках, а тут такое. :)
Не, сложные запросы можно написать вручную, но я при этом все равно использую фунционал QB, чтобы хотя бы не самому писать OR и AND, а также не пролезли инъекции.
Хотя мне тоже QB фреймворков показались унылыми.

В месяц?! Хм… На nnm за последний месяц 1,2М уников, если верить метрике яндекса.

Ну так nnm известен на весь рунет, сколько там людей работает?

Получается, у вас на одном сайте в районе 35к уников в сутки? И это максимум?)

Это в среднем по больнице в сутки.
Пиковую посещаемость я уже озвучивал.
>Это Вы померяли не фреймворк, а приложение на фреймворке, которое ничего не делает :)

Стоп-стоп-стоп… Вы сказали, что фреймворк вставляет лишнее. Я показал что нет. Что не так?)

>Ну так самопись, елки. :)

Серьезно?))) Ну тогда абсолютно любой фреймворк является «самописью». Против чего вы тогда выступаете?))))))

>Но паттерны головного мозга недалеко от ооп головного мозга и фреймворков головного мозга.
:)

Согласен. Как и от «самописи головного мозга» ;).

>Я делил трафик равномерно на 30 дней * 8 часов

Хм… А какой смысл? Ну предположим, есть 1,5М хитов в сутки. Но каждый хит генерит какое-то количество дополнительных запросов с помощью аякса или вебсокетов. Возможно, есть еще мобильное приложение, которое не учитывается в хитах. Возможно, есть еще апи-сервисы, которые тоже не учитываются в хитах. Странная у вас математика ;)

>Замеряйте на досуге, сколько времени тратится на создание объекта из 50 кБ класса.

Хм… Смысл? У меня не бывает классов в 50кб ;). И я даже представить себе такой класс не могу)))))))

>Все можно разделить.

Согласен. Вопрос — насколько это будет удобно. Не будет-ли подключаться лишнее. Можно-ли для одного модуля подменить общий класс/общую библиотеку/общую модель. И т.д.

>Сказал подключить другой шаблон (вид), а тот шаблон пускай как хочет, так и рендерит. :)

А, т.е. для генерации json во вьюхе делаем доп.обработку и вывод? Для xml во вьюхе делаем вообще отдельную логику? А в контроллере switch..case чтобы отдать правильный заголовок? Не, спасибо, но такое убожество не нужно)

>Хм, зря.

Нет)

>Главное, что расширения под любую БД есть в PHP.

Я вам больше скажу — для некоторых баз несколько расширений и важно правильно выбирать нужное. А если выбрать неверно — ваш код не будет работать)

>plain-sql порождает дублирование и раскидывание кода, усложняет поддержку.

Откуда такие выводы?))))

>Говорили об энтерпайсе, фреймворках, а тут такое. :)

Ну, в отличии от вас, я выбираю инструмент по задачам). Простенькие задачи — да, могу использовать orm/ar, сложные — будут plain-запросы.

>Хотя мне тоже QB фреймворков показались унылыми.

Уверяю, у вас такой-же унылый))) QB — это в принципе недоделка. Не поддерживает полный функционал базы, не позволяет писать сложные или удобные запросы и пр.

>Ну так nnm известен на весь рунет, сколько там людей работает?

Насколько я знаю, программер на ннм 1 ;)
Стоп-стоп-стоп… Вы сказали, что фреймворк вставляет лишнее. Я показал что нет. Что не так?)

1. Нужно было считать не разницу…
2. Нужну было брать Симфони.
3. Это расширение, хз, как оно в mu фигурирует.

Раз Вы привели Фалькон то, следует ли остальным писать свои расширения? :)

Ну тогда абсолютно любой фреймворк является «самописью». Против чего вы тогда выступаете?))))))

Они когда-то были самописью. О чем я говорю, а вы не слышите. :)
Наконец-то.
Но код, который используется большим количеством пользователей / компаний, неправильно называть самописью.
И я не против фреймворков как самоцель, просто они унылые и мне не подходят :)

Согласен. Как и от «самописи головного мозга» ;).

Согласен, я и не говорю, что все нужно писать самому. :)

Я делил трафик равномерно на 30 дней * 8 часов
Хм… А какой смысл? Ну предположим, есть 1,5М хитов в сутки. Но каждый хит генерит какое-то количество дополнительных запросов с помощью аякса или вебсокетов. Возможно, есть еще мобильное приложение, которое не учитывается в хитах. Возможно, есть еще апи-сервисы, которые тоже не учитываются в хитах. Странная у вас математика ;)

Это самый вероятный сценарий 8 часов * 30 дней. :)
Вы же тоже как-то среднее кол-во вдень считали :)
Хитом, мне кажется, стоит считать показатели счетчиков аналитики.
Вы же не пишете туда все подряд аякс запросы. :)
Хит — это открытие другой страницы (не важно, с помощью аякс или полная перезагрузка).

Возможно, есть еще апи-сервисы, которые тоже не учитываются в хитах.

Так и у меня не все учитывается в хитах :)
Допустим, аякс-отправка комментариев.
аякс-подсказки-поиск

Хм… Смысл? У меня не бывает классов в 50кб ;). И я даже представить себе такой класс не могу)))))))

У меня по работе на фреймворке и больше. :)
Не всегда большее количество меньших классов лучше.
Замеряйте не 1*50, а 5*10.

Можно-ли для одного модуля подменить общий класс/общую библиотеку/общую модель. И т.д.

Если будет нужно, то можно. :)
Ничем не сложнее, чем на фреймворке.

А, т.е. для генерации json во вьюхе делаем доп.обработку и вывод? Для xml во вьюхе делаем вообще отдельную логику? А в контроллере switch..case чтобы отдать правильный заголовок? Не, спасибо, но такое убожество не нужно)

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

Ну, в отличии от вас, я выбираю инструмент по задачам). Простенькие задачи — да, могу использовать orm/ar, сложные — будут plain-запросы.

Как бы и я по задачам :)
Раз пишете plain-запросы, то Вы не трушный фреймворщик :)
Они их писать разучились. :)

Уверяю, у вас такой-же унылый))) QB — это в принципе недоделка. Не поддерживает полный функционал базы, не позволяет писать сложные или удобные запросы и пр.

А он и не должен поддерживать полный функционал :)
Абстракция может не поддерживать низлежащий уровень.
В большинстве случаев достаточно базового, а когда недостаточно, то на основе кирпичиков QB можно собрать руками plain-запрос. Возможно, таких кирпичиков фреймворки не представляют (в открытую).

Насколько я знаю, программер на ннм 1 ;)

На ставку?
Там, наверное, и кроме программера ест люди.
А я один за всех на несколько проектов в свободное время и последнее время лень писать код. :)
>Нужно было считать не разницу…

Как это не разницу? Вы сказали, что фреймворк вставляет кучу своего. Убираем то, что потребляет приложение — получаем объем ресурсов, потребляемый фреймворком.

>Нужну было брать Симфони.

Почему? Я не пользуюсь симфони.

>Раз Вы привели Фалькон то, следует ли остальным писать свои расширения? :)

Еще раз — зачем писать свое, когда есть готовое, протестированное и удобное?)

>Но код, который используется большим количеством пользователей / компаний, неправильно называть самописью.

Ну тогда на zoon и rbt фреймворки, а не самопись ;)

>Вы же тоже как-то среднее кол-во вдень считали :)

Верно. Но я считал rps, а не хиты ;) А вы зачем-то приравняли хиты к rps о_О

>Так и у меня не все учитывается в хитах :)

Тогда как вы насчитали 35 rps?)))))

>У меня по работе на фреймворке и больше. :)
>Не всегда большее количество меньших классов лучше.

Всегда. Большие классы сложно поддерживать, большая связанность и пр.

>Я имел в виду, что по запросу мы понимаем какой шаблон должен рендерить контроллер.

А я имел в виду, что иногда вообще не надо рендерить никакой шаблон ;)

>Раз пишете plain-запросы, то Вы не трушный фреймворщик :)

Т.е. для вас пользователь фреймворка обязан использовать AR/QB/ORM? о_О

>Они их писать разучились. :)

Ну если вы разучились — это не означает, что разучились остальные)))

>В большинстве случаев достаточно базового, а когда недостаточно, то на основе кирпичиков QB можно собрать руками plain-запрос

Зачем собирать из говна конфетку?))))

@G-M-A-X, попробую вам раскрыть смысл чуть больше. Возможно хоть какая-то польза будет от этой всей дискуссии.


У меня по работе на фреймворке и больше. :)
Не всегда большее количество меньших классов лучше.

и чуть раскрою ответ:


Всегда. Большие классы сложно поддерживать, большая связанность и пр.

  1. Принцип единой ответственности — у каждой штуки должна быть только одна причина измениться. Нарушение этого принципа можно легко и просто анализировать по комментариям к коммитам к отдельным файлам.
  2. Внешняя связанность — чем больше класс — тем больше мы на него завязываем — тем хуже с точки зрения возможных изменений. Проверить насколько все плохо или хорошо со связанностью можно опять же через git — глянуть какие файлы чаще всего менялись рядом с конкретным по одним и тем же причинам.
  3. Внутренняя связанность — это ближе к принципу единой ответственности. Когда у вас все маленькое и логически структурировано правильно — вам проще находить что где менять, проще читать и поддерживать код.
  4. open/close принцип — мы должны иметь возможность "добавлять" поведение не меняя код. Это опять же решается декорацией/композицией. Например у нас есть штука которая лазит по сети и загружает данные. И когда это становится узким местом мы можем завернуть это добро в декоратор и в коммите с комментарием "Add cache to something that retrieves something from network" будет один новый файл и возможно поправленный конфиг.
  5. Сегрегация интерфейсов. Порой нам удобно сделать два интерфейса с одним публичным методом, и сделать один класс который имплементирует оба интерфейса. В этом случае с точки зрения связанности наша система будет использовать только то что нужно — и у нас не будет двух классов в системе у которых может быть одна и та же причина измениться (например FileUploader и FileDownloader интерфейсы, и класс который реализует это используя один и тот же способ, удобнее держать это рядом а не плодить сущности). То есть маленькие классы не всегда хорошо — всегда хорошо очень маленькие и простые интерфейсы
  6. Инверсия зависимостей — опять же когда мы хотим использовать что-то, чему в рамках нашей подсистемы не место. В качестве наглядного примера — вот картинка. Точки тут сгруппированы в 3 подсистемы, и у каждой группы точек только одна знает о другой подсистеме и является точкой доступа. Это нужно что бы подсистемы минимально знали о том что и как. И все эти принципы выше служат этой цели — сделать не хаос из стрелочек а что бы все было относительно просто и выглядело здраво.

А булшит аля "самопись vs фреймворки" давайте оставим. Все фреймвкорки так или иначе самопись, и библиотеки и т.д. Но если есть что-то что удовлетворяет потребности (и не прикрывайтесь производительностью, даже такие монстры как симфони при правильных руках выдерживают неплохие нагрузки), грех этим не пользоваться.

Но паттерны головного мозга недалеко от ооп головного мозга и фреймворков головного мозга.

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

Какие файлы из папки jquery по запросу $JS->jquery указано в файлике .include из этой папки.

Да выложите вы уже ваш говнокод. Мы найдем в нем 100500 дыр и багов и тема "фраймворк vs самопис" будет закрыта.


PS: и не надо повторяться что вы не готовы делиться своим говном

Да выложите вы уже ваш говнокод.

Этот код писал не я.

Мы найдем в нем 100500 дыр и багов

Ой божечки :)

и тема «фраймворк vs самопис» будет закрыта

Только непрофессиональные люди отдают вопросы безопасности налево и думают, что за фреймворком они как за камянной стеной и можно не думать о безопасности при написании кода под фреймворк.

Из другой темы, не могу там отыечать:
Чем-то вы мне напоминаете нашего общего знакомого G-M-A-X. Вместо того чтоб использовать готовое решение делаем свое.

Зачем эту дичь писать?
Фреймворк полностью не пригоден под мои требования. И отожествлять фреймворки и библиотеки это тоже глуповато.

Вы не обращали внимание на то что схема генерируемая доктриной сильно не оптимальна?

Та пофиг. Используем фреймворки и не паримся. Бизнес докупит серверов, если че. Это разве наша проблема :)

О, там много чего

То есть до Вас дошло, что надеяться на абстракции фреймворка не стоит? :)

В таком случае сущность превращается в помойку

Я, собственно, против таких сущностей-моделей-помоек и выступаю :)

Этот код писал не я.

ну вот. пиарились, пиарились и тут выясняется что я не я, корова не моя.


Только непрофессиональные люди отдают вопросы безопасности налево

это называется аудит безопасности и стоит он очень приличных денег


То есть до Вас дошло, что надеяться на абстракции фреймворка не стоит? :)

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


Я, собственно, против таких сущностей-моделей-помоек и выступаю :)

и пишете еще большую помойку, но свою. родная помойка не пахнет

ну вот. пиарились, пиарились и тут выясняется что я не я, корова не моя.

Хм, но я ж писал пару дней назад:
Сейчас я этот подход не использую, уволился с той работы


это называется аудит безопасности и стоит он очень приличных денег

Все пользователи фрейморков платят за аудит? :)
Они ж его получают бесплатно, только качество спорное.

О, там много чего

это я взял из Вашего списка недостатков Доктрины: https://habrahabr.ru/post/302438/#comment_9801354, провтикал прошлый раз дать ссылку.

и пишете еще большую помойку, но свою. родная помойка не пахнет

Наоборот же, мне неудобно так работать было, поэтому я не воспринимаю модели, как помойки.
А также Вы упустили, что мои модели (сущности) тонкие.

Вам не нравится помойка, но Вы в ее экосистеме живете.
Все пользователи фрейморков платят за аудит? :)

нет, но вы видимо не улавливаете в чем смысл.


Возьмем две системы. Вашу в 50 килобайт, какой-нибудь no-name микрофреймворк в 200 килобайт и например Symfony в пару мегабайт кода. И давайте признаем тот факт что дыры есть и у вас, и в этом микрофреймворке и в симфони (иначе небыло бы security апдейтов).


Идем дальше. Предположим что количество потенциальных уязвимостей коррелируется с объемом кода. То есть у вас потенциальных дыр будет поменьше чем в микрофреймворке и значительно меньше чем в той же симфони.


Продолжим мысль. Кто занимается "секьюрити аудитом" ваших проектов? Да собственно никто. Кто занимается секьюрити аудитом no-name микрофреймворка? Возможно пара человек за все время нашло несколько уязвимостей.


Кто занимается секьюрити аудитом Symfony — ну пара сотен человек так или иначе, на симфони пилят проекты подпадающие под различные сертификации по безопасности (IPC например или чего интереснее, HIPAA например). Так же есть целая армия разработчиков которые мониторят новости в комьютерной безопасности и латают дыры которые только можно найти (например возможность выполнения произвольного кода при помощи unserialize и т.д. Врядли вы подумали бы о таких нюансах).


То есть "фреймворк" — это второстепенно в контексте вопроса безопасности. Важно — количество квалифицированных представителей среди комьюнити этого фреймворка.


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


Вот и вся логика. Популярные инструменты лучше протестированы и требуют меньше эффортов в плане поддержки.


это я взял из Вашего списка недостатков Доктрины

это не "недостатки", это особенности. У доктрины в документации вполне честно написано что ORM как и любая абстракция вынуждена течь, иначе работа этой ORM-ки не эффективна. Причем из всех имеющихся для PHP ORM-ок доктрина как абстракция течет намного меньше. Особенно когда вы приверженец oo-first и для вас денормализация и "забить на внешние ключи" это нормально. Тогда в целом всех этих недостатков как бы и нет, работе это не мешает, а потом, когда функционал готов, можно уже заниматься оптимизациями.


А также Вы упустили, что мои модели (сущности) тонкие.

Это тип плюс? у меня они… средние. Они знают то что им нужно знать, они содержат поведение. Это не "типизированный ассоциативный массив", это объект, чье состояние инкапсулировано и поменять его может только сам объект. А когда люди говорят о "тонких сущностях" — это просто структура данных возможно с геттерами и сеттерами.


А теперь вспомним, как называется парадигма программирования, где методы объектов (функции по сути) меняют состояние других объектов напрямую (через публичные свойства или сеттеры). Процедурное программирование. Чем оно хуже ООП (в большинстве случаев) — тем что не пытается скрыть сложность и снизить связанность системы.


Вам не нравится помойка, но Вы в ее экосистеме живете.

Представьте что вы вселяетесь в отель. Все чисто и красиво. Да, если включить лампу черного света вы найдете странные пятна, или еще чего. Но можно же просто пользоваться благами цивилизации и не париться?

нет, но вы видимо не улавливаете в чем смысл.

Вы сначала пели, что аудит делает сообщество.
Потом пели, что аудит только платный бывает.
Теперь вот опять бесплатный.
:)

Вопрос в том, что:
1. Я 50кБ могу сам проверить
2. Я не надеюсь на защиту от ядра/фреймворка, а постоянно о ней думаю.
3. Есть куда менее проверенные куски сторонних разработчиков, которые скачиваются отдельно, вот там основные дыры и сидят, как в уже упомянутых тут дырах ВП.

это не «недостатки», это особенности.

Это не баг, а фича. :)
Кого-то эта течь устраивает, кого-то нет. Кстати, там Вы дискутировали как раз с автором цитаты.
это просто структура данных возможно с геттерами и сеттерами

Без.

Это тип плюс?

Да. Бизнес логика при необходимости лежит отдельно, а не в общем мусорнике.

Парадигма программирования, где методы объектов меняют состояние других объектов напрямую (через публичные свойства или сеттеры). Процедурное программирование. Оно хуже ООП

А в ООП нету вызовов методов? :)

Представьте что вы вселяетесь в отель. Все чисто и красиво.

Правильней так:
Вы вселяетесь в отель, а там говно по стенам, но жить-то можно, все ж живут.
И двери в номер можно не закрывать, можно ж доверять. А тут раз, и вас обчистили.
А номера все 10-местные, мало ли, у вас будет рост посещаемости номера.
А для того, чтобы зайти в номер, вам нужно сплясать с бубном.
А потом к вам в номер начали подселять людей. :)
Вы сначала пели

ну у меня два проекта проходило секьюрити аудит. И мы за это платили деньги. И Таких как я тысячи. Так что комьюнити само фиксит дырки, само проводит секьюрити аудит, и периодически проводит платный в рамках своих проектов.


Вопрос в том, что:
  1. Я 50кБ могу сам проверить
    ...

Вопрос в том что, повторюсь, вы не достаточно квалифицированы. Да, защититься от примитивных видов атак не вопрос, но это не значит что "дыр нет". Пример — сериализация. Если у вас она используется — уже есть нюансы. И таких неочевидных вариантов полным полно и о них нужно знать. И постоянно мониторить.


Кого-то эта течь устраивает, кого-то нет. Кстати, там Вы дискутировали как раз с автором цитаты.

Каждый инструмент имеет свою область применения. Автору нужно было явно не то а эдакий электронный ДБА. Доктрина про другое, вот и все.


Да. Бизнес логика при необходимости лежит отдельно, а не в общем мусорнике.

Если у вас код мусорник — то тогда понятно в чем плюс.


А в ООП нету вызовов методов? :)

ООП — это передача сообщений между объектами. "вызов сеттера" — это по сути изменение внутреннего состояния объекта напрямую. Это можно делать до тех пор, пока клиентскому коду не приходится проверять инварианты объектов, с которыми он работает. Это первый сигнал что что-то пошло не так как клиентскому коду вообще не нужно об этом всем знать.


Вы вселяетесь в отель, а там говно по стенам, но жить-то можно, все ж живут.

я смотрю у вас какая-то травма была.

Вы вселяетесь в отель, а там говно по стенам, но жить-то можно, все ж живут

Скорее так:
Я видел эти отели. Там грязно. Я видел волос на полу и складку на постеле. В ванной небыло одноразовых тапочек. А полотенце не было сложено в виде лебедей. А ещё халат висел не на вешелке. А ночью я видел свет из коридора в щель под дверью.


Отели это зло. Я лучшие по своему. В картонной коробке на улице. Она продувается, в ней холодно, жёстко и она намокает и разваливается от дождя. Но это моя коробка. Я сам её собирал. Я сам заклеивал все дыры скотчем. Я знаю её как облупленную. А в этих ваших отелях даже щель под дверью закрыть нечем.

Пропустил.
А как весело это все тестировать, просто сказка.

http://blog.kpitv.net/article/почему-я-не-использую-тесты-кода-15338/ (основной посыл сказан, как всегда, в юрле :) )

Но рассматриваю тестирование API.
Как всегда сноска: говорю прежде всего о личном коде
  1. тесты нужно писать до кода как процесс формализации того что вы хотите сделать. Это не долго
  2. тесты не должны часто меняться если у вас не меняется функционал. Если вы рефакторите код приложения — тесты не меняются. Поддерживать их легко.
  3. для юнит тестов не нужно. Для функциональных — докер, все легко и изолируемо.
  4. просто нужно уметь тесты писать. А для этого их нужно писать.
  5. задача тестов — гарантировать что вы не сломали из того что знали. Баги будут всегда потому что мы не в состоянии покрыть все возможные тестовые сценарии, слишком дорого.
  6. Тесты нужны не для того что бы "писать качественный код" а что бы "в любой момент времени я могу без страха поправить в любом месте и узнать сломалось чего или нет". Без постоянного рефакторинга (не когда переписываешь все а по чуть чуть, например узнал что "эта штука называется по другому" — поменял), ваш код как бы вы не старались превратится в кашу. Все будет хорошо только на очень простых проектах.
  7. А вот это уже правда. Вы не пишите тестов потому что не писали и не умеете. А все остальное — отговорки которые вы себе придумали.

Да и тестирование не всегда подразумевает "автоматическое". Руками ж тоже надо как-то проверять. И дебажить.

1. Как правило, я функционал реализую не сразу целиком, а в процессе, есть разбитие на уровни. Я не могу заранее знать, как будет работать тот или иной нижележащий (или выше, смотря как смотреть) уровень, которого еще нету. Написал чуток кода, проверил как он работает. А не написал весь тест сразу.
И видение как все должно работать может меняться. Тесты легче написать, когда есть четкие требования, когда тебе пришла четкая изолированная задача, типа тебе нужно реализовать такое-то API. А то в процессе кодинга чего-то без жестких требований API 100 раз может поменяться :) Вряд ли стоит тест писать полностью сразу без написания кода. Лучше писать итерациями. А также, учитывая тот факт, что тесты прежде всего являются индикатором поломок кода при изменениях, то скорее всего лучше их писать после кода или итерациями.

2. Имел в виду поддержку, если меняется функционал. И больше не новый функционал, а изменения и фикс старого. А так, да.

3. Я больше о БД. А также, чтобы тестовая база имела все связанные данные, нужные для фикса багов (это не совсем относится к тестам).

4. Баги допускают все. Если мы допустили «баг» в тесте (постановке задачи), то скорее допутим его в
коде.

5. Поэтому все не нужно покрывать. В большинстве случаев достаточно сделать высокоуровневый тест (API).
Если изменился функционал, то упадет и тест, но это не означает, что есть баг. А править тест приходится.

6. Если править «качественно», то вероятность ошибок меньше. Рефакторинг нужен. Свой код постоянно рефакторю. На работе только во время решения задачи, чтобы она удобней ложилась. На рефакторинг нету времени, а жаль.

7. Я даже настаиваю, чтобы на работе их ввели, а то порой поправишь в одном месте, а потом из-за этого через некоторое время всплывает баг, казалось бы в совсем не связанном месте. :)

Говорить совсем, что тестов нету, тоже не правильно. :)
Ведь нужно проверять, как работает тот или иной метод и дорабатывать его, пока он не заработает как следует.
Да, это скорее ручные тесты, потом поправлю заголовок, если не забуду. :)
Просто не всегда оправдано тест писать отдельно. Тестировать можно и самим кодом (АПИ тесты). Только для некоторого кода нужны юнит-тесты.
Тесты иметь удобно, но еще удобнее, когда их пишет кто-то другой :)
Не успел отредактировать:
3+. Просто некоторые тесты стоило бы выполнять вместе. Есть возможность запустить групповой тест, состоящий из нескольких в том же phpunit? Или это нужно руками?
Хотя тесты API можно и руками написать :)
Кстати, у меня есть парочка запросов, которыми я проверяю важные части, пока вручную.

П.С.
Добавил Ваш ответ в бложик :)

лол))


Тесты нужно писать.

аргумент....))


Тесты нужно поддерживаь в актуальном состоянии.

если перед коммитом тест сломался — да, нужно поправить


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

Вы просто еще не научились их писать))


Так как тесты нужны прежде всего как индикатор работоспособности при изменениях, то следует учитывать то, что скорее всего это сломался сам тест, так как он не ложится на измененный код.

Верно, если вы поменяли код — то сломанные тесты сами себя не поправят.


Я стараюсь писать качественный код. Выше качество кода — нужно меньше тестировать. Это фишка японских автомобилей.

Качество автомобилей можно определить только за счет их тестирования до введения в производство И после N-летней поддержки.
На основе самомнения же аргумент — так себе.


Ни на одной работе их не писали, поэтому я не привит к красивому.

Круть, наконец-то хоть один пункт в точку. Рекомендую сделать это первым пунктом и "привит к красивому" заменить на "умею их писать", в этом случае будет идеально.

Почему вы опустили это:
Я никого не призываю их не использовать.
Все сказано о самописном личном коде.
В других ситуациях могут быть нюансы.

Какое все же тестирование я рассматриваю:
Тестирование API.
Тестирование на работе, когда тесты пишет кто-то другой.
Это больше актуально в больших системах.


Я ж не говорю, что они не нужны.
Но в личных проектах я их не пишу.
А вот на работе прошу, чтобы писали.

Вы согласны, что необходимость в тестах растет с ростом команды и кодовой базы? :)
Так вот, я пишу личные проекты сам и там кода не много и они некоммерческие.
Да и ВК как бы без ООП.

потому что начанался вконтактик на бодреньком процедурном коде. Это не говорит о том что "вконтактики" лучше знают как что писать. Просто им ресурсов это все поддерживать хватает.


Вон фэйсбуки свой PHP запилили, с нормальной объектной моделью, сносной системой типов и т.д. А по поводу "фреймворков" — юзают в основном на фронтэнде. На бэкэнде у них… ну можно сказать свои фреймворки которые они в опенсурс выкладывают.


Да и брать в пример продукты с такими нагрузками в принципе нет никакого смысла. У них там микросервисы, огромные ресурсы и инфраструктура. А у вас бложик.

Коммент пропал. :(

>вконтактик, фэйсбуки

Даже Цукенберг признал, что ВК в США работает быстрее ФБ.

C — тоже без ООП.

>А по поводу «фреймворков» — юзают в основном на фронтэнде.

Фронт — это другое государство. :)

>На бэкэнде у них… ну можно сказать свои фреймворки которые они в опенсурс выкладывают.

Так все фреймворки проходят стадию самописи.
Но их авторам тоже говорят: Вась, брось, возьми фреймворк А или Б. У них сообщество, тесты, все такое. :)

>Да и брать в пример продукты с такими нагрузками в принципе нет никакого смысла.

Это были козыри. Я проверял, нужно ли такие сайты писать на Симфони. :)

>А у вас бложик.

Та бложик это для себя и для лулзов :) Бложик появился совсем недавно.
Даже Цукенберг признал, что ВК в США работает быстрее ФБ.

Если для вас важна скорость — просто берите Go или Rust. PHP не для этого — он для уменьшения стоимости разработки под WEB.


C — тоже без ООП.

Си появился примерно в тот же период, что придумали саму концепцию ООП. Да и потом, то что в Си нет "классов" — там есть структуры, там можно добиться инкапсуляции (причем лучше чем в плюсах), там все хорошо с полиморфизмом (драйвера — хороший пример), там все… ну так себе с наследованием но на структурах это можно сделать и многие даже делают.


ООП — это в первую очередь управление связанностью и зависимостями. А все остальное — оно не только про ООП.


Фронт — это другое государство. :)

У меня выходит двойное гражданство.


Так все фреймворки проходят стадию самописи.

Вот только в отличии от вас у этих "самописей" авторы поопытнее будут.


Но их авторам тоже говорят: Вась, брось, возьми фреймворк А или Б. У них сообщество, тесты, все такое. :)

Вот смотрите. Я использую Symfony уже 5 лет. И мне он честно сказать жмет. Потому свои проекты я пилю на ооочень адаптированном под себя symfony. По сути это мой фреймворк который на 90% состоит из отдельных компонентов которые мне лень писать самому. Я проходил этап написания своих фреймворков лет так 7 назад, уже не интересно.


Это были козыри. Я проверял, нужно ли такие сайты писать на Симфони. :)

Знаю ребяток которые пилят сайтики на 50 миллионов пользователей на симфони и они довольны. blablacar например. А когда у вас миллиард пользователей — чуть другие заботы появляются нежели фреймворки или языки программирования.


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


p.s. фреймворки от фэйсбука мне не нравятся. Решения от вконтактика — бесполезны поскольку они ориентированы исключительно на вконтактик.

Если для вас важна скорость — просто берите Go или Rust.

У меня не такие большие нагрузки, чтобы оправдано было переписывать.
Потом, вряд ли у них сейчас более развита инфраструктура, чем в PHP.
И у них типизация «статическая, строгая».

«По большому счёту, Go является процедурным языком с поддержкой интерфейсов.»
(https://ru.wikipedia.org/wiki/Go )
ООП-шники негодуют :)

PHP не для этого — он для уменьшения стоимости разработки под WEB.

Но PHP не настолько медленный, особенно в свете выхода 7 версии.
Я не совсем понимаю ВК и ФБ, которые с PHP сделали костыли, вместо того, что взять компилируемый язык.

Си ООП

То есть на самом деле не так важна явная парадигма языка. :)

Вот только в отличии от вас у этих «самописей» авторы поопытнее будут.

Хм, настолько опытные, что решили писать самопись :)
Если самому не писать код, то можно и остаться программистом на Битриксе (Кодеигнайтер) и уметь только решать задачи в рамках ЦМС/фреймворка. :)

Потому свои проекты я пилю на ооочень адаптированном под себя symfony. По сути это мой фреймворк который на 90% состоит из отдельных компонентов которые мне лень писать самому.


На написание кода уходить процентов 10 времени, остальные 90 — это чтение.
Чем меньше, тем проще читать.
Фреймворки слишком универсальны.
Компоненты — это ок.
Но если мне не нравятся компоненты, которые реализуют ядро фреймворка.
То, без чего или с другой реализацией чего, по сути это уже другой фреймворк, как Ларавел и Симфони.
Взять и выбросить 90%? :)
Если нету цели иметь всеядный комбайн, то можно ограничится созданием ядра только под свои задачи.
Это ж не так много кода нужно.
Да и моя самопись эволюционировала с php странички, вся динамика которой была в отдаче элемента массива по индексу из запроса. Самым трудным для меня было понять, как получать GET параметры. Об этом в статьях типа «Создаем сайт на коленке» не говорилось :)

А когда у вас миллиард пользователей — чуть другие заботы появляются нежели фреймворки или языки программирования.

Конечно, затыки бывают не только на бекэнде.

blablacar например.

Тоже о них знаю. Это наверно единственный пример.
У них главная отдается с
cache-control:max-age=3600, public, s-maxage=3175
И дурота есть тоже.
Раскрученный проект не значит умно сделанный. :)
Я не совсем понимаю ВК и ФБ, которые с PHP сделали костыли, вместо того, что взять компилируемый язык.

Видимо, к тому времени, когда проблемой стал язык программирования, объём и сложность уже разработанного кода были настолько велики, что переписывание (читай — «разработка») «с нуля» на другом языке были совершенно невыгоды.
Видимо, к тому времени, когда проблемой стал язык программирования, объём и сложность уже разработанного кода были настолько велики, что переписывание (читай — «разработка») «с нуля» на другом языке были совершенно невыгоды.


У меня кода на самописи настолько бла-бла-бла, что переписывать его на фреймворке совершенно невыгодно.

вот будет пара миллиардов строк кода — тогда поговорим о фэйсбуках вконтактах.

вот будет пара миллиардов строк кода — тогда поговорим о фэйсбуках вконтактах.

Миллиарды строк кода? :)
Ну да, ну да.
Судя по этой статье https://habrahabr.ru/post/308974/ Вы погорячились :)

А также берем во внимание, что там много разработчиков на ставке, а я своим кодом занимаюсь в свободное время как хобби (программирование сначала было моим хобби, а потом уже стало работой).
Ну, в принципе, это видно. Как по комментариям, так и по коду ;). Но например я не готов ехать в другой город на стуле, спать на машине и т.д.

Хотите — плодите сущности. Я в этом смыла не вижу.

И да, у вас не контроллерами решаются задачи, а как-раз виджетами. Контроллер у вас всегда один — index.php ;)

О-ло-ло. :)

Чего?!?! Фреймворк вызывает статику?! Или все-таки приложение?

То есть у Вас по коду раскиданы голые подключения скриптов:
<link href="//habracdn.net/habr/styles/1472830295/_build/global_main.css" rel="stylesheet" media="all" />

Ну ок.

А на простых кешировать статику не имеет смысла. Хватит кеша в браузере + get-параметр.

Так я как раз о гет-параметре и говорю. Чтобы его не вручную менять, а он сам менялся и не парится.

И это минус. Чтобы поправить хедер — мне править ядро? Бред…

304 ответ. Зачем его править?
Вы как узнаете, что страничка не изменилась?

Но, вы не показали, как это проще сделать на вашем фреймворке))))

Я этим не парюсь.
Этим занимается ядро.
Хотите — плодите сущности. Я в этом смыла не вижу.

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

В обычной ЦМС статическая страница это обычный php файл. В фреймворках начинаются танцы с бубном и контроллерами.
Бред.

Видимо, для автора просто "обычная ЦМС" === "1С-Битрикс".

Я не понимаю, с чем Вы спорили.
Я говорю, что на фреймворках нет из коробки «добавить новое вложенное меню», об этом и в статье (и многом другом, чего тоже нету).
Вы говорите, что нет и не нужно.

Спорьте тогда с предыдущими ораторами.
Или они используют какие-то неправильные фреймворки? :)
Я говорю, что на фреймворках нет из коробки «добавить новое вложенное меню»

потому что это задача не из категории 95%, а из котегории % людей которым нужны менюхи. Для таких есть отдельные либы к фреймворкам которые все это позволяют делать.


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


Вам например не фейрмворк нужен а CMF какая-нибудь. Вот и все.


Или они используют какие-то неправильные фреймворки? :)

вполне возможно)

Я не о шаблоне меню, а о собирании массива пунктов. :)

я так же не о шаблоне меню, а о собирании "дерева" пунктов.

Написано много "интересных", "аргументированных" и "правильных" замечаний о вреде фреймвороков (особенно yii1 и yii2).
Для примера:


В обычной ЦМС статическая страница это обычный php файл. В фреймворках начинаются танцы с бубном и контроллерами.

Решение (в тот же yii) http://www.yiiframework.com/wiki/22/how-to-display-static-pages-in-yii/
Но боюсь, вы не осилите это решение — слишком сложное, нужен бубен.

Не поддавайся этому толстому троллю).
Статью я писал не с целью троллинга, а для систематизации недостатков фреймворков, дабы давать ее оппонентам, а не каждый раз вспоминать аргументы.

Да ладно, в вашей статье отсутствует объектиная критика (только субъективная), куча подмененных понятий и необоснованных выводов. Это отличный троллинг))

Эсли Вы принимаете правила фреймворков, то да, для Вас это все будет необъективным.

А также Вы можете добавить объективности статье:
Желающие могут указать свои трудности, с которыми пришлось столкнутся. Они будут добавлены в статью.


О каких подменных понятиях Вы говорите? :)
О каких подменных понятиях Вы говорите? :)

В статье вы критикуете "фреймворки", при этом доводы базируете только на yii.
Далеко не все фреймворки используют MVC подход, вы же говорите так будто бы все.
Model вы рассматриваете только как ActiveRecord (пусть и не явно). AR — это одна из возможных реализаций Model.

Не только yii, но в основном. О причинах этого я написал.

>Model вы рассматриваете только как ActiveRecord

Лично я рассматриваю шире.
А фреймворки примерно так (ну или иную конкретную реализацию хождения в БД).

МВЦ в:
https://ru.wikipedia.org/wiki/Symfony
https://ru.wikipedia.org/wiki/Laravel

Об остальных смысла говорить нету.
Лично я рассматриваю шире.

Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.


В Symfony нет своей имплементации M из MVC, да есть Doctrine, но это проект другого вендора. Посему называть его MVC фреймворком не корректно.


Об остальных смысла говорить нету.

Смысл есть. Вы же набрасываете на фреймворки в целом. Что на счет Zend, Silex?

>Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.

Я рассматриваю шире. А все эти DBAL/DAO/ActiveRecord — это хождение в базу. И так рассматривают фреймворки, а не я.

>Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.

Это реализация хождения в базу. Я говорю, что неправильно рассматривать модель — как хождение в базу. Смысл мне перебирать все реализации хождений в базу, если я выступаю против их всех?

>В Symfony нет своей имплементации M из MVC

Ну и что, что нету. Под M все равно понимается хождение в базу. Symfony используется в связке с Doctrine чуть реже, чем всегда?
Пускай уберут в википедии упоминание, что они MVC в первом предложении, или там же укажут, что M у них как бы и нету. :) Хомячки ведутся на модные слова.

>Что на счет Zend

Каюсь, что упустил.
Он тоже MVC:
https://ru.wikipedia.org/wiki/Zend_Framework

Микрофреймворки / малоизвестные не рассматривал.
Так как малоиспользуемых много и смысла нету, я больше противник дурости в мейнстримовых (разрекламированных). Некоторые микро — это обрезки Симфони и Ларавел.
А все эти DBAL/DAO/ActiveRecord — это хождение в базу. И так рассматривают фреймворки, а не я.

Вообще говоря — нет. Хранилищем данных может выступать и кэш, xml файл, внешний сервис, что угодно.
Пример: http://docs.doctrine-project.org/projects/doctrine-common/en/latest/reference/caching.html


Смысл мне перебирать все реализации хождений в базу, если я выступаю против их всех?

Если вы утверждаете, что все реализации — плохо, то должны смочь аргументировать такую позицию.


Микрофреймворки / малоизвестные не рассматривал.

У yii — 4679 звезды на github, у silex — 3292. Я бы не сказал, что тут прямо пропасть в уровнях известности.

>Вообще говоря — нет. Хранилищем данных может выступать и кэш, xml файл, внешний сервис, что угодно.

Ок, не база, а хранилище данных.
Интересно, какой оверхед у кеша (допустим мемкеш) doctrine по сравнению с чистым PHP.

О, вспомнил. На моей первой работе с фреймворками (Yii) отказались от моделей фреймворка (DBAL/DAO/ActiveRecord), а написали свой велосипед, который вызывался моделями фреймворка (сущностями, которые вроде продолжали наследовать фреймвок) :)

>Если вы утверждаете, что все реализации — плохо, то должны смочь аргументировать такую позицию.

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

Хотя да, все эти ходилки в базу мне не нравятся. :) Некоторые я щупал в живую, о принципах некоторых читал в документации.

Меня полностью устаивает моя ходилка :)

silex основан на Симфони. У yii 2 8к звезд, хотя это не важно.
У исходников php 10к звезд.
Но это же не значит, что php менее популярен за свои фреймворки. :)
Да и звездочки можно накрутить.

Звездочка — это типа понравилось / избранное?
Что она еще дает?
Интересно, какой оверхед у кеша (допустим мемкеш) doctrine по сравнению с чистым PHP.

Ничтожный)). Что с доктриной, что без, сетевые издержки будут на порядки дольше, чем обвязки.


Вообще, сущность не должна себя куда-то сохранять/извлекать.

Я рад за вас, вы только что придумали Entity-Repository. Во многих случаях он более надежный, чем AR. Правда бывают случаи, когда он слишком избыточный.


silex основан на Симфони.

На компонентах — да, на стеке выполнения — нет.


Звездочка — это типа понравилось / избранное?

Тип того + все ваши фоловеры видят, что какие проекты вы отмечаете.

А также Вы можете добавить объективности статье

Смысла нет. 99% вашей статьи — бред сивой кобылы.

Статью я писал не с целью троллинга, а для систематизации недостатков фреймворков

1) твоя статья основана на опыте работы с одним фреймворком, весьма примитивном если честно.


2) выборка фреймворков и опыт работы только с одним не дают вам возможности что-то систематизировать.


3) для ваших задач это не нужно — потому это все больше выглядит как старая добрая фраза. Для молотка любая задача выглядит гвоздем. То есть вы не представляете что у кого-то могут быть другие задачи и для них ВАШИ способы работы не подходят.

1) Но все фреймворки имеют указанные недостатки :)
3) Я и не заставляю всех. :) Если не подходит, значит не подходит. Мне вот фреймворки не подходят. :)
Но танцы же начинаются… :)
Да, совершенно с Вами согласен: любому специалисту куда проще и легче включиться в работу, если ему хорошо известны и знакомы «инструменты и приспособления». Но мне кажется, что это не очень свежая идея… ;)

А вот если фрейморк и «кастомное решение» поставить в равные условия незнания либо знания их нашим разработчиком, то разница между ними для разработчика исчезнет совсем, или почти совсем. Не так ли? :)
К популярным фреймворкам есть обширная документация, примеры использования, тонны вопросов на StackOverflow.
Равных условий не будет.
Забавные вы… :)
Фреймворк у вас обязательно и «популярный», и «хорошо знакомый» разработчику, а «кастомное решение» — и без документации, и вообще…

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

Может. Теоретически.
В теории — теория и практика одно и то же. На практике же это совершенно не так.

laravel, yii — более 40000 вопросов на stackoverflow. Практически любой вопрос вида «как сделать то, как работает это, почему не работает так» можно вбивать в гугл и получать ответ сразу же. Ни одно кастомное решение такого не предполагает.
Зачастую спрашивают откровенный бред.
Потому что говнокодеров заманили на фреймворки.

Ну или спрашивают, как обойти подводные камни фреймворка.
А в грамотной самописи их не будет (этих камней).

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

И вынужден напомнить ещё раз: задача, выполненная при помощи и на основе фреймворка — это всё то же «кастомное решение».

Покажите мне, пожалуйста, пусть даже не «более 40000», н охоят бы «более 40» вопросов и ответов по конкретной задаче, разработанной «поверх» любого ­-пусть даже популярного :) — популярного фреймворка.

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

Вангую: нет таких… :)

Нет, фреймворк не обязательно "хорошо знакомый", но при найме разработчика на проект достаточно указать в требованиях знание определенного фреймворка. Как нанять программиста на проект чуть менее чем польностью состоящего из "кастомных решений"? Все указать в вакансии? Таким образом, кого бы ни взяли на "кастомное решение", ему придётся разрабираться не только в этих "решениях", но и в том, как они связаны.


А если брать "на вырост", то тут уже играет роль документация и целостность решения. Если во фреймворке всё выполнонено в едином стиле (по крайней мере бОльшая часть), то каждое "кастомное решение" выполнено в "кастомного стиле".

Ключевое слово: Документация.

Любой фреймворк — это всё те же «кастомные» (не люблю эти уродливые заимствования :) ) решения, но хорошо документированные. И от прочего самописного кода их отличает только большая применяемость, что к качеству самого продукта имеет, зачастую, далеко не прямое отношение.

Так что Вы ищете разработчика, знающего платформу, на которой основано данное «кастомное решение», которого любой нанимаемый Вами разработчик всё равно не знает — то я позволю себе иметь хорошо документированное «кастомное решение», которое мой разработчик всё равно будет изучать так же, как и Ваш. :)

А ругаемый здесь кем-то «говнокод» точно так же может «жить» и поверх фреймворка — в собственно приложении, всё так же «кастомном» (а иначе — никак!)…

И в чём тогда разница?? :)

Времени потребуюется на порядок меньше.

Обоснуете? :)

Надо добавить новое вложенное меню — если ты знаешь фреймворк, то ты знаешь, что меню там делается именно вот так. Можно даже не искать по всему коду, как в нем это реализовано, а просто знать, что идем вон-туда.

Я, видимо, что-то пропустил, и теперь не знаю — а какая связь между PHP фреймворками и «вложенными меню»? Я где-то слышал :), что меню — это HTML+CSS(+JS), нет? ;)

И потом, Вы — в пылу спора, видимо — делаете «хорошее» такое допущение: «если ты знаешь фреймворк». :)

Вы, знаете, я не только не против ­— я очень даже «за» знания! Но давайте тогда предположим, что «ты» знает и самописный код на PHP, а? Ну, просто справедливости ради. И тогда мой ответ Вам в этой части будет выглядеть как-то так:

Надо добавить новое вложенное меню — если ты знаешь самописный код, то ты знаешь, что меню там делается именно вот так. Можно даже не искать по всему коду, как в нем это реализовано, а просто знать, что идем вон-туда.

Хорошо, правда? :))
Да, и возражения из серии «Да фреймворки знают все, а этот код — только его разработчик!» — не принимаются.
Причины:
1. Фреймворков очень много.
2. При допущении о знании новым разработчиком данного конкретного фреймворка — смотрите моё замечание касательно "если ты знаешь". :)
3. Фреймворк — только «платформа», на которой строится приложение, опять-таки представляющее из себя наш злосчастный «самописный код» (Sic!).

Думаю, здесь моя идея понятна, да? :)

Тогда идём дальше.

«Дорого для всех. Всегда все хотят платить меньше. С какой стати это ошибка владельца? Владелец обязан знать что такое фреймворки? Что такое движки? Вы совершенно не правы, если не хотите все это считать, хотя бы в теории.»

А кто у нас придумывает идею задачи? Кто нанимает разработчика, даёт ему ТЗ, контролирует разработку — не забывая, конечно же, и о документации? Ну, и так далее.
Кто должен всё проконтролировать, чтобы было «как надо»? Разве не наш владелец? Разве не он, помимо контроля за соответствием исполнения задачи его замыслу, должен проследить, чтобы конечный продукт не оказался «вещью в себе», справиться с которым не в состоянии никто, кроме первоначально нанятого «мага и волшебника»?

Так вот я и имею в виду, что если владелец что-то там «промухал», то это он ССЗБ, а вовсе не разработчик. Его вина.

Так что это Вы «совершенно не правы, если не хотите все это считать, хотя бы в теории».
«Я так думаю!» © :)
потребуется время на то, чтобы «разобраться».

Вот только разбираться он будет не в том "а что это предыдущий программер тут нагородил с роутингом и т.д.", а непосредственно с бизнес-логикой.


Для владельца? Так это будет плата за его же ошибки, допущенные им в самом начале…

А какие ошибки допустил владелец? О_О Не он же "разрабатывал с нуля", а предыдущий программер. Т.е. владелец будет расплачиваться за ошибк, допущенные (предыдущим) разработчиком. И в каждом магазине будут одни и те же ошибки

Вот только разбираться он будет не в том «а что это предыдущий программер тут нагородил с роутингом и т.д.», а непосредственно с бизнес-логикой.

Ну, во-первых, какая разница, на что именно он потратит то же самое, в общем-то, время?

И во-вторых — а почему Вы так уверены что там, «над» фреймворком, будет бизнес логика, «белая и пушистая»? ;)
Тот же самописный код, по сути… Ну, если только наша задача не сводится к простейшей «демке» применения конкретного фреймворка, в пару строк. :))

А какие ошибки допустил владелец? О_О Не он же «разрабатывал с нуля», а предыдущий программер. Т.е. владелец будет расплачиваться за ошибк, допущенные (предыдущим) разработчиком.


Да нет же. :)
Повторяться не хочу, чуть выше уже пояснил свою точку зрения.

И в каждом магазине будут одни и те же ошибки

Очень даже может быть.
Только они будут «одни и те же» у одного и того же разработчика, вне зависимости от того, на чём он строит свои приложения.

Мне кажется, ошибки всё больше исходят от людей, а не от используемых ими «инструментов и приспособлений». :)

Нет, нет и ещё раз нет:)


Ну, во-первых, какая разница, на что именно он потратит то же самое, в общем-то, время?

известный разработчику фреймворк: время на бизнес-логику (и не важно, пушистая она или нет — точно такая же будет в самописном фреймворке)
самописный код: сначала разобраться во фреймворке; затем в бизнес-логике. И на втором шаге постоянно оглядываться на первый.


А какие ошибки допустил владелец?
Кто должен всё проконтролировать, чтобы было «как надо»?

Простите, а когда я пропустил тот момент, когда все заказчики поголовно стали программистами-архитеторами-дизайнерами, что могут отслеживать каждый шаг и контролировать качество продукта?:)


Только они будут «одни и те же» у одного и того же разработчика

Не угадали. Есть фреймворк/CMS, к которым написаны и применены в десятках других проектах модули (и будем откровенны, очень часто они завязаны на фреймворк/CMS так, что не оторвать). Если в нём и есть ошибка, то она допускается 1 раз и со временем исправляется. Тоже 1 раз. В случае велосипеда кто будет её исправлять на десятках проектов? И кто сказал, что набор ошибок одного и того же функционала в разных пректах будет одинаковым?


ИМХО, проектов, требующих какой-то особой организации, которую не может предоставить фреймворк. А большая часть тех, кто думает, что у него именно такой проект, заблуждаются.

Нет, нет и ещё раз нет:)

Да. Один раз. Не люблю повторяться. :)
известный разработчику фреймворк: время на бизнес-логику (и не важно, пушистая она или нет — точно такая же будет в самописном фреймворке)
самописный код: сначала разобраться во фреймворке; затем в бизнес-логике. И на втором шаге постоянно оглядываться на первый.

А почему в первом случае разработчик знает фреймворк, а во втором Вы его заставляете «разбираться», а потом ­— ещё зачем-то и «оглядываться»?? Тем более, что она «точно такая же»?.. :(

По-моему, Вы мухлюете… :)

Не угадали.

Так а я и не.
Я понимаю, что людям нередко свойственно судить о других по себе, но… Вы ошиблись. :)

Есть фреймворк/CMS, к которым написаны и применены в десятках других проектах модули (и будем откровенны, очень часто они завязаны на фреймворк/CMS так, что не оторвать). Если в нём и есть ошибка, то она допускается 1 раз и со временем исправляется. Тоже 1 раз. В случае велосипеда кто будет её исправлять на десятках проектов? И кто сказал, что набор ошибок одного и того же функционала в разных пректах будет одинаковым?


Ну а здесь Вы даже и не мухлюете, а откровенно жульничаете, сравнивая фреймворк — «базу» для всё такого же самописного приложения — с другим самописным приложением. Это нечестно, я так не играю… :))

ИМХО, проектов, требующих какой-то особой организации, которую не может предоставить фреймворк. А большая часть тех, кто думает, что у него именно такой проект, заблуждаются.

Эээмммм… А Вы не пробовали читать то, что пишете? :)
Эта Ваша мысль слишком глубока для меня… :))
Очень правильная статья. Вообще, практически везде по жизни отлично работает правило «без фанатизма». Любая разумная рекомендация или правило может превратиться в ад адский, если её бездумно применять всегда и везде.
В том числе и рекомендации этой статьи ;)
«6 советов, как с минимальными усилиями изобрести велосипед и начать создавать не поддерживаемые приложения».
Это ж перевод. В переводных статья велика вероятность встретить подобное.
> В этом случае вы добавляете уровень абстракции поверх другого уровня абстракции, который изначально создавался как базовая точка отсчёта.

Это необходимо, особенно если учитывать, насколько неприятен чистый php. Решения таких задач как чтение-запись файла\загрузка данных по http\прослушивание сокета выглядят крайне неопрятно без использования сторонних библиотек, так как php в большинстве случаев не предоставляет удобных абстракций, а просто занимается копированием C функций.
Извините, но что здесь является неудобным :)?

1. Чтение-запись файла:
$contents = file_get_contents("filename");
file_put_contents("other_filename", $contents);


2. Загрузка данных по HTTP
$contents = file_get_contents("http://something/other_thing"); // да, это та же функция!
// Если нужно что-то более продвинутое, используйте curl, он умеет ВСЁ


3. Прослушивание сокета
$socket = stream_socket_server("tcp://0.0.0.0:8000", $errno, $errstr);
while ($conn = stream_socket_accept($socket)) {
   fwrite($conn, 'The local time is ' . date('n/j/Y g:i a') . "\n");
   fclose($conn);
}


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

Вас смущает, что это какие-то вещи офомлены в виде классов с 10 видов исключений? Ну так а зачем нужно использовать ООП для такой простой задачи?
Ну так а зачем нужно использовать ООП для такой простой задачи?

Просветите, как мне тестировать код, использующий вызовы file_get_contents и file_put_contents?
https://github.com/badoo/soft-mocks или
https://github.com/krakjoe/uopz

на ваш выбор
Я надеялся вы предложите перегружать стандартные функции с помощью namespace, но костыль тоже сойдет. Можно примерчик теста с использованием любого из? )
Пример для strlen:

\QA\SoftMocks::redefineFunction(
    'strlen',
    '$a',
    'return \\QA\\SoftMocks::callOriginal("strlen", [trim($a)]));'
);

var_dump(strlen("  a  ")); // int(1)
Надо будет как нибудь попробовать сие чудо, благодарю.

Воу, а как же "PHP специально сделан, чтобы упростить решение типовых задач для веба и в нём есть удобные абстракции для большинства стандартных вещей"?
Зачем использовать какую-то левую библиотеку? Разве в php нет для этого стандартной функции? А это же лишняя зависимость в проект! Бедный ваш заказчик, который регулярно переплачивает за то, что вы не в состоянии написать тест сами!


Никогда не понимал людей, которые используют внешние зависимости! Только свои решения!

Зачем использовать какую-то левую библиотеку?

Вообще PHP позволяет сделать то же через namespace без «левых зависимостей»
Спасибо за разъяснение зачем нужно ООП, когда можно обойтись без него. Оказывается, в первую очередь чтоб всё мокалось и благодаря этому юнит-тестилось.
Вы можете моки через хаки динамического линковщика делать даже на Си, где ООП и не пахнет. Паттерн Dependency Injection, конечно, позволяет писать код, в котором можно подменять реализацию любого класса, но я лично не согласен с тем, что ООП создавался для этого. В принципе, DI можно сделать и в процедурном стиле, хоть это и будет выглядеть не так «красиво».
Совершенно все, начиная отсутствием объектного интерфейса (я вынужден помнить список разрозненных функций вместо использования публичных методов объектов), заканчивая одинаковым порядком аргументов (точнее его отсутствием) в функциях.
Curl же совершенно особая песня, его можно отнести к особым, наиболее неудобным сторонам php.

В качестве контрпримера приведу библиотеки, которые на мой взгляд привносят хорошие, удобные абстракции:
https://github.com/guzzle/guzzle
https://github.com/moment/moment
https://github.com/KnpLabs/Gaufrette
Совершенно все, начиная отсутствием объектного интерфейса

Простите, но это замкнутое докащательство: автор постулирует в том числе отсутствие необходимости в повсеместном ООП, в качестве примера приводит процедурный код и вы говорите «а тут нет объектного интерфейса». Ясное дело нет: это пример другого подхода.

я вынужден помнить список разрозненных функций вместо использования публичных методов объектов

Стоп-стоп-стоп, а если вы используете объектный интерфейс, вам не надо помнить имя класса и имена методов? Или вы пользуетесь подсказками IDE? Тогда и с процедурным подходом то же самое — поиск по имени и автодополнение.
Для поиска по имени нужно либо это имя помнить, либо иметь префикс (который есть далеко не у всех функций), так же в процессе этого придется отбрасывать n-oe количество методов, которые имеют похожие имена, но к задаче не относятся. Так же процедурный код не предоставляет удобного способа хранения\инкапсуляции внутреннего состояния, что дополнительно нагружает разработчика и загрязняет код.
Подсказками IDE пользуюсь, всегда.
Для поиска по имени нужно либо это имя помнить, либо иметь префикс (который есть далеко не у всех функций)

А с ООП не так? Имя класса и метода не надо помнить?

так же в процессе этого придется отбрасывать n-oe количество методов, которые имеют похожие имена, но к задаче не относятся

Это зависит от разбиения на модули, в общем — частность.

Так же процедурный код не предоставляет удобного способа хранения\инкапсуляции внутреннего состояния, что дополнительно нагружает разработчика и загрязняет код.

Мы говорим об интерфейсе, изначально в разрезе примера доступа к файлу и т.п. но все равно во множестве случаев внутреннее состояние в процедурном подходе точно так же инкапсулируется. Например, вы открываете файл, получаете handle, все внутренние данные скрыты за ним.

Подсказками IDE пользуюсь, всегда.

Тогда непонятно, в чем проблема поиска имени — открываем модуль, ответственный за класс функций X и смотрим список процедур. Это ничем особым не отличается от подсказки при вводе имени экземпляра класса.
Все сводится к правильному разбиению на модули и хорошим именам процедур. Если мы предполагаем, что имена могут быть плохими, не отражающими суть действия, то мы можем равно предполагать, что в ООП вместо LinkedList.First() мы будем иметь LL.f(), что ничем не лучше, чем какой-нибудь llgfe(abc)
Кажется эта ветка комментариев постепенно начала вырождаться в объяснения основ ооп, зачем оно нужно и чем лучше процедурного кода. Извините, но нет, не хочу, вольный пересказ Мейера — это не слишком интересное занятие.
Нет, мы с вами спорим по одной простой частности: о том, что «нужно помнить имя».
иметь LL.f(), что ничем не лучше, чем какой-нибудь llgfe(abc)
Чуть лучше: «LL» и «f» не свалены в одну кучу, «abc» инкапсулировано в «LL», а не передаётся в функцию, которую можно перепутать, да ещё и как аргумент безликого стандартного типа вроде «число» или «целое» или чем там заменяется указатель на объект.
Если не сваливать все функции в одну глобальную область видимости, а пользоваться модулями или неймспейсами, то проблема исчезает. Между linked_list_instance.first() и linked_list.first(instance) нет никакой разницы.
Безликими типами пользоваться не нужно, конечно же.

Эта запись с точкой — всего лишь синтаксический сахар. Не это является сутью и признаком объектно-ориентированного программирования и, как другой сахар, не является обязательно необходимым.


Для ООП требуется то, что требуется: в первую очередь инкапсуляция (в логическом смысле, в проекте), на которую вы намекаете. То есть, у меня есть некая структура и набор функций для работы с именно этой структурой или её усложнёнными вариантами, это вот признак объектно-ориентированного программирования, и процесс разработки программы не зависит от того, напишу я f.a(), или classf_a(f). Более того, C++, когда-то был фронт-эндом для C и имеено то самое и делал: заменял конструкции вида f.a() на classf_a(f), после чего отдавал результат обычному компилятору C. Глупо же говорить, что после обработки фронт-эндом программа переставала быть объектно-ориентированной, правда?


А ещё есть такая штука как GLib, в которой по сути тем же способом реализован объектно-ориентированный подход на чистом C. Естественно, никакого специального синтаксиса — C как C. Но разработка явно объектно-ориентированная.


И точно так же можно писать на C++ совершенно не объектно-ориентированный код. Но точки при этом будут.

Суть сравнения LL.f() и llgfe() — не в противопоставлении концепций процедурки о ООП, а пример плохих имен, только и всего.
Чуть лучше: «LL» и «f» не свалены в одну кучу

Ок, пусть в процедурном API будет в качестве примера не llgfe(abc), а ll_gfe(abc).

«abc» инкапсулировано в «LL»

Это разумеется, но там выше спор об именах был и о том-де, что сложно вспомнить, как функция называется в процедурной парадигме. К чему я и привел пример — если мы говорим о заведомо плохих именах, то никакое ООП не спасет.
а если вы используете объектный интерфейс, вам не надо помнить имя класса и имена методов?

Ну, к примеру, на VBA программировать сильно удобнее, чем на ExcelBasic или WordBasic как раз из-за того, что там 900+ функций реорганизованы в ~30 классов с ~30 методами каждый. Правда, работает существенно медленнее, но это уже нюансы.
Или вы пользуетесь подсказками IDE?
Тоже существенный фактор. ОО языки сильно лучше дружат с интеллектуальными IDE.
как раз из-за того, что там 900+ функций реорганизованы в ~30 классов с ~30 методами каждый

Сложите эти функции по 30 модулям с префиксами — то же самое по части имен.
Ок, а если мне нужен ORM, конфигурирование различных окружений, роутинг, логирование и т.д.?
file_get_contents(«http://something/other_thing»);

До первого таймаута. Потом человек узнает, что надо было использовать curl, тут же офигевает, что для этого надо с десяток строк кода и фигачит ещё один guzzle.
На самом деле, можно передать таймаут в контекст file_get_contents :). Но я и правда умолчал об обработке ошибок. Впрочем, адекватная обработка ошибок — это всегда боль, не важно, ООП у вас или нет.
это всегда боль, не важно, ООП у вас или нет.

В этом и прикол библиотек, они всю эту боль на себя обычно берут и делают какие-то упрощения. А ООП позволяет вам "изолировать" все сайд эффекты.

Чтение-запись файла:

поддержка облачных хранилищ? Тестирование? Да, есть стримы и врапперы для стримов (спасает в принципе) но всеже


Загрузка данных по HTTP

В ответе только тело ответа, а мне заголовки иногда нужны. То есть уже надо юзать curl. А потом еще мне надо делать 10 паралельных запросов и что бы было удобно, фасадик сверху и мы уже получаем библиотечку вроде co. А у других свои задачи со своими нюансами.


Прослушивание сокета

web sockets, хэндшейки, работа с готовыми протоколами и т.д.

На самом деле, для вебсокетов и для асинхронного выполнения 10 HTTP-запросов я бы использовал другой язык, go. Конкретно PHP тут уже упирается в отсутствие тредов, но отсутствие тредов — это тоже сознательное решение, позволяющее писать более простой и управляемый код для веба.

Поддержка облачных хранилищ обычно сводится к работе через HTTP. Заголовки действительно получить через file_get_contents нельзя, но заметьте, что cURL предлагает вполне сносный (и вполне себе объектный, хотя может так не показаться поначалу) API.

Библиотеки вроде https://github.com/mpyw/co лишь эмулируют «треды» и не позволяют дальше выполнять свой код асинхронно по отношению к выполняющимся запросам. Настоящие асинхронные запросы к MySQL и memcached есть в HHVM, кстати.
На самом деле, для вебсокетов и для асинхронного выполнения 10 HTTP-запросов я бы использовал другой язык, go.

Даже если у вас есть уже продукт на PHP и эта штука нужна для второстепенного функционала? Микросервисы мало кто умеет готовить нормально, так что представьте что у вас монолит.


Конкретно PHP тут уже упирается в отсутствие тредов

Треды не лучший способ работы с I/O, а вот корутины в PHP есть уже довольно давно. Я спорить не буду в том что go раскидает наши корутины еще и по потокам и вообще эффективнее такие задачи решает, но тут конкретно мысль о том что треды не для этого.


cURL предлагает вполне сносный (и вполне себе объектный, хотя может так не показаться поначалу) API.

С каких пор "изменение состояния объекта процедурами" называется объектный?


Библиотеки вроде https://github.com/mpyw/co лишь эмулируют «треды»

повторюсь. Эта "эмуляция тредов" называется корутины. В Go похожий принци просто чуть сложнее.


и не позволяют дальше выполнять свой код асинхронно по отношению к выполняющимся запросам

Вообще-то позволяет. Мы можем получить промис и блокировка процесса будет произведена только на время работы самого пыха. Мультиплексирование потока команд и все такое.


Настоящие асинхронные запросы к MySQL и memcached есть в HHVM, кстати.

У HHVM все очень плохо с постгресом, к сожалению. Да и memcache я как-то не юзаю ибо мне удобнее работать с redis. Ну и опять же асинхронные запросы к базе это… актуально отлько тогда, когда мы имеем демонов которые обслуживают сразу по несколько десятков запросов хотя бы. А на данный момент инфраструктура пыха в плане библиотек поддерживающих неблокируемые операции весьма скудна.

> Заголовки действительно получить через file_get_contents нельзя

Справедливости ради, заголовки получить можно, но весьма таки неинтуитивным способом.

> file_get_contents(«http://example.com»);
> var_dump($http_response_header);

Если хочется отправить пачку HTTP запросов асинхронно и нативно, то можно попробовать поиграться со stream_select. Сам таким не занимался, но, в теории, должно будет сработать.

P.S.: я буду обновлять комментарии, я буду обновлять комментарии…
> В ответе только тело ответа, а мне заголовки иногда нужны. То есть уже надо юзать curl.

Не надо. Заголовки http-ответа доступны через переменную $http_response_header

file_get_contents('http://ya.ru');
var_dump($http_response_header);

С помощью file_get_contents() можно сделать и POST-запрос, и передать любые http-заголовки запроса, и таймаут выставить. Так что в 90% случаев можно обойтись без CURL.

Но не понятно, в чем спор? CURL — это библиотека, а автор статьи ничего не имеет против библиотек.
UFO just landed and posted this here
Например, PDO — маленькая библиотека, предоставляющая согласованный интерфейс для обращения к базам данных в PHP.


Но даже тут для удобной работы с PDO необходима еще 1 абстракция и все сведется к написанию ещё одного велосипеда.
Постоянное использование фреймворков

Напомню, что фреймворк, это набор инструменты для разработки и не более.

Все PHP-фреймворки общего назначения — отстой!
Расмус Лердорф

А я скажу, что Расмус Лердорф отстой, раз такое заявляет.
Компании сталкиваются с тем, что фреймворки общего назначения плохо помогают решать конкретные задачи, к тому же очень медленно работают. Фреймворки невозможно масштабировать, и многие компании пытаются выдрать из них куски в отчаянной надежде заставить работать то, что изначально не требовалось.

Компании с этим сталкиваются и с использованием других инструментов.
Мне к примеру фреймворки очень хорошо помогают решать конкретные задачи.
А про скорость это просто смешно. Ну да PHP работает медленно сам по себе(относительно других ЯП(что опять отдельная тема для дискуссии)), но если на сайт и так заходят 2 человека, то кто скажет где узкое горлышко? В РНР? Сомневаюсь. Его сил на 2 пользователей хватает с головой.
Масштабирование? А это проблема абсолютно всех проектов. Нам конечно рассказывают сказки про крутые масштабируемые системы, но зачастую это откровенное вранье. Всегда находятся нюансы о которых ты просто не знал в начале проекта, которые в итоге твою масштабируемость убивают. Начинаешь писать костыли(если нет времени) или переписывать очень многое(если время позволяет).
Не бывает простых методов масштабируемости. Увы и ах.

Вообще статья ОЧЕНЬ спорная.
UFO just landed and posted this here
Действительно так.
Надеюсь дожить до коллективного разума.
Конечно надежда помогает вставать по утрам, однако я вижу только то, что чуть ли не каждый год появляется еще больше библиотек, призванных их разрабами стать стандартом де-факто. Поэтому эта идея «коллективного разума» лично для меня остается из разряда колоний на Луне (хотя-бы на Луне): очевидно, что это будет возможно в будущем, однако в нашем обозримом будущем полеты в космос будут осуществляться разве что с помощью костров святой инквизиции. Извините за такую грустную иронию, наболело просто…
Надеюсь не дожить до этого «счастья»
UFO just landed and posted this here
Они же о себе всё сказали в конце — что они — безымянные тролли, и на Гитхаб даже выложили не код, а свою единственную статью из корня доменного имени сайта. В основе которой — цитаты известных людей против парадигм, сказанные по разным случаям. Отсутствие контрпримеров подсказывает, что авторы только что прошли стадию понимания недостатков слепого следования фреймворкам и сами думают, что же делать дальше.
Зря вы на автора перешли, ваш уровень настолько высок, что вы помимо статьи можете оценить его уровень? Который, возможно, имеет дело с проектами, совершенно непохожими на ваши и с совершенно другими требованиями и окружением? Типа, если человек написал статью про паттерны программирования без контрпримеров, это означает, что он «только что» прошел стадию понимания паттернов программирования?

По моему, как раз надо бы больше статей, которые позволяют взглянуть на вопросы разработки под другим углом
По моему, как раз надо бы больше статей, которые позволяют взглянуть на вопросы разработки под другим углом

Залезьте на какой нибудь форум разработчиков-новичков, там подобной «прагматичной» чуши океан.
Потому что сказанное в статье грамотно, всё это можно найти по разным статьям в интернете, но тропинка протаптывается в направлении троллизма в плане «не надо пользоваться фреймворками». А авторы неизвестны. Об их уровне можно сказать, что он не начальный, стадию отрицания ООП они прошли самостоятельно. Но отсутствие конструктивности, что все отмечают, говорит, что до этой стадии ещё не дошли (обычно приходят или к паттернам, или к ФП. Но паттерны они тоже отрицают почему-то (цитаты подходящие попались от Пола Грэма про макросы? так это он про Си, скорее) — говорит как раз о недлинном пути).

В общем, да, по статье всё читается. Посмотрите других критиков ООП — там хорошо видно, что они что-то предлагают вместо него (прототипы, примеси, ФП). Ближайших примеров на Хабре можно найти очень много, вот, например, за 5 августа. Или эти 2 статьи: http://frontender.info/the-two-pillars-of-javascript/
цитаты подходящие попались от Пола Грэма про макросы? так это он про Си, скорее
Это он про Common Lisp.
Подбор цитат к статье вообще жжёт… из всех процитированных, по-моему, только 1 человек использует PHP и это Расмус :-)
Да, емое, велосипед, который будет обладать более высокой производительностью, чем фреймворк, надо еще поискать ))

Тот же Yii, построенный на концепции «ленивости» во всем, даже ухом не поведет, пока вы не обратитесь к какому-либо релейшену конкретной модели (не то, что запрос в БД не сделает, даже класс не проинклудит до непосредственного обращения к классу модели). И что, я должен все это продумывать каждый раз для нового приложения? Ну бред вообще же полнейший.
вы очень поверхностно смотрите.
Объект вашей модели yii, ожидая ленивого запроса уже содержит в себе несколько объектов на каждую ленивую связь, объект схемы таблицы с объектами колонок таблицы, объекты поведений, десяток объектов валидаторов, непосредственно объект абстракции над коннекшном к базе ActiveQuery, внутри которого объект квери билдера и самого коннекшна (черт знает, что я еще не вспомнил).
В абстрактном «велосипеде» есть простой конекшн к базе, простейший репозиторий в кач-ве абстракции над коннекшном, сервис, в котором происходит валидация одним валидатором и непосредственно сохранение простейшей модели через репозиторий, и все в это десятки раз легче по памяти чем модель yii.

Расмус именно это и имел в виду: предоставляя всеконфигурируемость приложений, фреймворки лишают большинство желания разбираться что там под капотом, и нужно ли оно. Покрывая 95% потребностей всех разработчиков, фреймворк добавляет на это 50-70% оверхеда.
К слову: страница с простым листингом одних и тех же сущностей на yii кушает памяти в 5 раз больше, чем страница на одном из микрофреймворков.

Смотря как сделан листинг на микрофреймворке и как сделан листинг на Yii.

Да какая разница. Вы не из сферического вакуума, случайно?

А что будет с вашим фреймоворком когда нужно будет другому человеку его поддерживать? То-то же.
каким фреймворком? речь о приложении на основе framework-agnostic модулей, которые по структуре будут намного проще для понимания любым php-разработчиком без знаний конвенций какого-либо фреймворка.

Т.е. составленные вместе рандомные (в плане комбинаций альтернатив) "framework-agnostic модули" не требуют "знаний конвенций какого-либо фреймворка", а фреймворк состоящий из таких же модулей, но собранных и разработанных в едином дизайне — требует какие-то непосильные "знания"?

все знания посильны. Но создавая модули для фреймворка программист а) ограничивает область применения одним фреймворком б) жестко связывает модуль с конкретными реализациями, зачастую хардкодя их использование в) накладывает требования к необходимым знаниям — апи фреймворка. Зачем связывать принудительно с фреймворком Х, если можно связывать с любым фреймворком/библиотекой через интерфейс адаптера, таким образом перекладывая вопрос выбора инструмента на конечного разработчика.

а) не вижу проблемы. Создаётся обощённый компонент + простой адаптер для отдельного (своего) фреймворка. А если этот функционал специфичный для проекта, то какая разница, в том, ограничена ли область применения одним фреймворком? Часто ли меняется фреймворк в проекте? Даже тип БД меняется крайне редко, а фреймворк вообще маловероятно.
б) аналогично, захардкоживание — не проблема фреймворка. Он как раз позволяет и мотивирует так не делать.
в) если модуль используется в определённом фреймворке, то он, скорее всего, написан по тем же соглашениям и правилам, которые определены во фреймворке. А значит, что всегда можно догадаться, как ведёт себя каждый отдельный модуль.


Зачем связывать принудительно с фреймворком Х

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

>>> не вижу проблемы. Создаётся обощённый компонент + простой адаптер для отдельного (своего) фреймворка

проблемы нет. Это и есть framework-agnostic.

>>> А если этот функционал специфичный для проекта, то какая разница, в том, ограничена ли область применения одним фреймворком? Часто ли меняется фреймворк в проекте? Даже тип БД меняется крайне редко, а фреймворк вообще маловероятно.

функционал получения данных специфичный для проекта? Начинаешь проект на mysql, заканчиваешь на смеси elasticsearch с каким-нибудь http-сервисом, из которых собираются сущности.
В процессе развития карьеры и опыта каждый новый проект становится сложнее, и больше предъявляет требований к изначально верному построению архитектуры. И смена/комбинирование источника данных становится ежепроектной обыденностью, приучащей хардкод заменять на интерфейсы+адаптеры. В больших проектах, над которыми работают на протяжении нескольких лет множество программистов, меняются требования ко всему неединожды.

>>> аналогично, захардкоживание — не проблема фреймворка

я не говорил о проблемах фреймворка. я говорил про плюсы framework-agnostic подхода. Это гибче для использования, проще для понимания, но требовательней к навыкам проектирования
Из статьи я вынес, что Расмус очень самокритичен.
Остальная же часть… Авторы серьезно верят, что в следующий раз при начале проекта люди не возьмут Laravel, Symfony или тот же Yii, а начнут писать на этом чрезвычайно неудачном фреймворке под названием PHP? Если людям нужно масштабироваться, людям можно взять Go или, там, набирающий обороты Elixir. Но людям это как правило не нужно, людям нужно решение своих типовых задач. Они за этим пришли в PHP.

Не использовать ООП и шаблоны проектирования как магию, которая сама все исправит, быть программистом и копипастером — это все замечательно. Но, если подумать, причем тут фреймворки?
«и копипастером» => «а не копипастером»
Ядро Linux содержит более 20 миллионов строк кода, написанных исключительно с помощью процедурного программирования


Неверно делать вывод о стиле программирования на основании используемого языка. На С тоже пишут (в том числе, и в ядре) с использованием некоторых техник ООП. Критика парадигмы, а не кокретных примеров её использования вызывает только раздражение.
UFO just landed and posted this here
Соглашусь. Я тоже не понимаю, какие альтернативы предлагает Расмус? Я пишу на php уже много-много лет и спасает только то, что параллельно читаю стандарты в Java и более-менее стараюсь следовать им в php.

Окей, предположим, что php — это фреймворк для веба… Тогда я смело заявляю, что это точно полный отстой, потому что более скудного и бесполезного фреймворка я не встречал. Где хотя бы соглашения/стандарты/реализации роутинга, секьюирити, валидации, ОРМ? Даже тот же PDO нельзя назвать библиотекой, потому что он дает ну настолько уж базовый функционал, что поверх него еще библиотеку нужно строить.

Ладно, кто-то всё ровно скажет, что php классный фреймворк и его библиотека PDO классно работает с БД, а секьюрити, валидация и роутинг — это мои капризы, кому они нужны в «реальном бизнесе». Но где в этом фреймворке возможность тестирования? Этим даже там и не пахнет, снова нужно искать какие-то левые библиотеки, написанные на этом недофреймворке и… писать кучи абстракций над всем, что есть в недофреймворке.

Всё же php это ЯП для веба и не более того. А такие фреймворки, как Symfony2+ и Laravel хоть как-то сглаживают весь хаос, неоднозначность, непредсказуемость в php.

Я любил php, пока не стали заставлять делать на нем ERP, CRM и документооборот. Ну не предназначен он ни для чего серьезнее обычного сайта, который просто динамически генерирует html.

Не хотел никого задеть и обидеть, но Расмус немного в своих высказываниях зазнается и забывает своё место.
Где хотя бы соглашения/стандарты/реализации роутинга
А что такое роутинг? Процесс выбора, какой модуль будет выполняться в зависимости от того, что за запрос пришёл?

В первоначальной инкарнации PHP предполагалось, что роутинг выполняет веб-сервер. Т.е. есть 10 скриптов, имеющих разные адреса (например, имена файлов разные, или лежат в поддиректориях), и какой из скриптов (читай — какой модуль) вызвать, определит веб-сервер, в зависимости от запроса. Это и есть роутинг.


А роутинг "в современном понимании" потребовался потому, что пошла мода иметь "одну точку входа" и так называемые "SEO-пути". Тут определять, какой модуль должен отработать, т.е. выполнять роутинг, вынуждена уже эта самая одна точка входа, а функционал веб-сервера используется не полностью и только для того, чтобы всё вообще направить на эту одну точку входа.

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

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

В итоге придем всё ровно к тому, что если core-team не хочет решать это и как-то стандартизировать, то будем куча разнородных решений, некоторые из которых будут стремиться стать максимально универсальными, и лучшие именно из универсальных решений будут повсеместно использоваться.

Что значит стандарт сервера? Обычный маппинг URI->fs 1:1. Есть путь /home/user/site/docroot/ — он виден как example.com/. Всё, нужен нам модуль /home/user/site/docroot/sub/module.php — отправляем на example.com/sub/module.php.

Это было с самого появления HTTP. Ну, да, тонкость возникает, что здесь php-файл не отдаётся непосредственно как есть, а выполняется сервером, но я слышал что эту задачу вроде бы уже научились решать.

Причём, никто не заставляет вас держать вообще всё в пределах docroot — там нужно только то, что может быть запрошено легально через веб-сервер. А что касается контроля доступа — так опять же, аутентификацию сваливаем на веб-сервер, он же умеет http basic auth, а можно и вообще по клиентским ssl-сертификатам или через kerberos, а дальнейший контроль так и так будет выполнять сам модуль.

Стандарт значит, что сервера, которые мапят урл с php-скриптом должны соответствовать установленным поведениям, файлы конфигов должны для этого быть как-то унифицированы. Это поведение должно учитывать нужды программ, для которых предназначается данный ЯП.
Обычный маппинг URI -> fs — явно не учитывает огромное кол-во нужд, которые важны людям, использующим php сегодня.
В итоге опять каждый будет пилить свой велосипед. Я понимаю, что многих php-программистов это не напрягает, потому что они даже не подозревают, что программист может не однотипные задачи кодить, а концентрироваться на решении бизнес-задач, не отвлекаясь на то, как бы это реализовать, чтобы другие могли понять и было легко поддерживать в долгосрочной перспективе.

HTTP-Auth, хорошо. Пусть кор-тим скажет, чтобы разработчики его использовали, тогда сразу всем станет ясно, что php только для динамической генерации html, и никакую бизнес логику в него пихать не следует. Секьюрити включает в себя не только аутентификацию, но и авторизацию, под которую опять каждый будет изобретать свой велосипед.

Всего, чего не коснись в php, нуждается в том, чтобы писать свой велосипед… И еще этот Расмус делает настолько глупые заявления, говоря, что фреймворки общего назначения полный отстой.

Так авторизацию в любом случае каждый модуль будет делать себе сам, как ни крути. Подумайте сами, как фреймворку будет известно, кто и к чему имеет права доступа? Только если мы ему об этом расскажем в виде кода. А поскольку в каждом модуле набор защищаемых объектов, возможных действий с ними и соответственно возможных разрешений и тому подобного — свой, имеющий смысл только для этого модуля — то в каждом модуле это будет свой код.

Погодите, мы сейчас говорим не о фреймворке, а об ЯП php. Пожалуйста, не называйте его фреймворком, это выглядит очень странно :)
Например, ЯП может предложить помечать определенные методы некоторыми токенами. Как? Да без разницы, хоть через анотации.
При вызове методов мы можем проверять эти токены и вызывать привязанные к ним обработчики, которые будут реализовывать определенный интерфейс. (Понимаю, что в php мало кто знает, что существуют интерфейсы, которые могут очень сильно помогать в стандартизации).
Или можно реализовать простейшую событийную модель, которая для помеченных методов будет вызывать слушателей, а для остальных — выполнять, как есть. На производительности это особо не скажется.

Я уже придумал 2 достаточно абстрактных и универсальных решения за 5 минут. Этого не могут сделать разработчики ЯП? Я честно, не знаю какие цели ставит перед собой тот, кто заведует развитием php, но подозреваю, что точно не цель сделать всё легким в поддержке.

Я еще раз повторю, что я реально ЛЮБИЛ php, потому что у него есть свои плюсы. Но сейчас его тащат в ту нишу, где он смотрится просто смешно и нелепо. На данный момент он может закрепиться в этой нише ТОЛЬКО благодаря фреймворкам, типа Symfony2, но и тут Расмус вставляет им палки в колеса своими нелепыми высказываниями.
Честно, я не понимаю, куда идет php, и всё больше и больше боюсь делать на нем проекты, которые придется поддерживать и развивать 5+ лет.
PHP — это шаблонизатор. Все остальное появилось сильно позже…
Все остальное появилось сильно позже…

В т.ч. и сам термин — «шаблонизатор»
От шаблонизатора в PHP только теги <?php ?> / <?= ?>, и конструкции include / require. Все, что внутри тегов — язык программирования.
Статья, повторю уже сказанное, более чем спорная. В сумме с отсылкой к авторитету создателя PHP Расмуса Лердорфа, хотя за ним Гутмансу и Сураски не только пришлось переписывать код, который им, цитирую «очень не понравился», но и исправлять многочисленные ошибки в дизайне языка, звучит как призыв «назад к PHP 3» (если не к PHP/FI). Хотя мысль «без фанатизма» сама по себе и здрава, но здесь похоже предлагается подменить фанатичное следование «современным стандартам разработки» чем-то из 90-х (да и сама статья написана достаточно, гм…, фанатично). А это куда хуже, те, кому приходилось работать с legacy PHP кодом «старой школы» меня поймут. Бесспорен тут только призыв писать безопасный код и большая часть рекомендованной литературы.

Да глупы наезды эти. Гутманс и Сураски потребовалось всё переписать потому, что они решили приспособить язык для другого, не для того, для чего он изначально предназначался. Это нормально: решил занять другую нишу — приспосабливайся. Жаль только, что они имя не стали менять — меньше было бы сейчас пересудов.

Ну как для другого. Для веб-программирования. Разве что сместили акценты с «программа-шаблонизатор чтобы добавить какую-никакую динамику» на «язык программирования». При том, что судя по тому, что они писали (причём не на форумах/в рассылках, а в предисловиях к книгам), сам по себе исходник расмусовского php был, скажем так, legacy-style, что к назначению языка уж точно никакого отношения не имеет. Ну и в том, что касается проектирования языка, пусть даже в рамках реализации шаблонизатора у PHP были неудачные захардкоденные решения… В общем если кто помнит историю языка (лучше — на своей шкуре) те в курсе.

>Жаль только, что они имя не стали менять — меньше было бы сейчас пересудов.
Ну они долго поддерживали совместимость со многими из этих самых неудачных решений, хотя и объявили их depricated.
Любой фреймворк — это форма организации мышления для выражения желаний
Можно ботать по фене, можно читать лекции, можно торговаться на базаре — мы владеем этими формами выражения и не думаем, что есть некий незамутненый руссский язык
Поэтому фреймворки полезны, и их полезно знать, хотя бы для того, чтобы иметь широкий кругозор мышления
Как сказано в одной мудрой книге — узкий специалист подобен флюсу — его полнота односторонна
PHP собщество в лице http://www.phptherightway.com/
против
Mail.ru Group в лице http://www.phpthewrongway.com/

Пожалуй выберу первое…
Mail.ru Group то тут чем провинились? Они только статью перевели же.
UFO just landed and posted this here
Успешный в маркетинговом плане, разумеется.
UFO just landed and posted this here
Да, symfony явно ломает представление автора о фреймворках.
UFO just landed and posted this here
Какой отборный бред. Надеюсь, автору полегчало.

P.S.
> В этой статье мы различаем фреймворки и библиотеки по следующим признакам:
> Библиотека — это набор многократно используемого кода.
> Фреймворк — это не просто набор многократно используемого кода

OMG. Хватит придумывать. Библиотеку вызываете вы, фреймворк вызывает вас, результат зависит от разработчика.
Статью полностью не прочитал, но автора понимаю.
Приветствую текст и считаю появление таких статей позитивной тенденцией.

Еще один критик-теоретик (см. его активность: https://github.com/binarygenius?tab=activity ) решил заработать себе баллов на критике PHP.

Видимо каждый начинающий программист должен написать дейтинг на PHP, свою CMS свой фреймворк и покритиковать PHP. ОК. Примем это просто как должное. Все должны через это пройти. Переболеть, как ветрянкой в детстве. И лучше в детстве, поверьте, очень печально смотреть, как взрослый мужик болеет ветрянкой (или критикует PHP).

А мы, практики, пойдем дальше использовать этот язык для решения бизнес-задач. Которые, надо отметить, он решает быстро и очень качественно. Кому не нравится — можете и дальше писать статьи о том, какой PHP плохой и какое у него омерзительное сообщество.
""«Не надо всё делать самостоятельно, об этом уже позаботились более опытные»"
У этого лозунга довольно глубокие корни.
Сегодня одно из главных преимуществ PHP — поддержка императивной, функциональной, объектно ориентированной, процедурной и рефлективной парадигм.
Императивная, функциональная и процедурная парадигмы вполне легко и сравнительно удобно и с небольшим оверхедом эмулируются на объектно-ориентированной. А знаменитая тема шаблонов проектирования на 70-80% состоит из эмуляции функционального программирования с помощью объектно-ориентированного программирования.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Расмусу нужно пофрилансить годик, сразу одумается. 3 коммита за полгода и 1млн $ в кармане, это не 3 магазина за месяц и хотя бы 100к в кармане.
Ну, было бы нужно — наверняка же «пофрилансил» бы, верно? :)

И потом, сколько, в плане ценности для (со)общества, «весят» его коммиты, и сколько — те три магазина? Вопрос риторический. :)
UFO just landed and posted this here
В мире Python и Ruby создание веб-сайтов с нуля — занятие довольно утомительное, поскольку эти языки для создания веб-сайтов не предназначались.

А PHP Расмус Лердорф изначально создавал как набор инструментов, написанных на С, позволяющих легко и быстро разрабатывать динамический HTML. PHP таким задумывался и таким остался, он сам и есть фреймворк.


А можно немного подробнее? В чем именно PHP является фреймворком и что именно в нем реализовано настолько лучше, чем в Python и Ruby? Я только поверхностно знаком с двумя последними, но не помню там ничего такого, в чем PHP их превосходил бы на голову.

Если сравнивать голые языки, то шаблонизатор, конечно же, и работа с формами в PHP в разы лучше того, что в других языках.
Но вот если брать не голые языки, а фреймворки, то эта разница не играет существенной роли.

Мне кажется, что то, что есть в PHP по работе с формами и выводом данных, не дотягивает до звания "фреймворк". Думаю, автор преувеличил.

Когда PHP только появился — это был ого-го какой фреймворк! =) Сейчас этого, конечно, мало.
Уместным был бы тэг «провокация» или дисклеймер «сарказм». Если бы не цитаты Расмуса. Нуместные.
Ощущение, что статья опоздала на полдесятка лет.
Статья скорее вредная.
Только php начал выбираться из ада легаси-говнокода и тут опять — пишите свои велосипеды вместо фреймворков. Блин.
Более грамотный подход — использовать фреймворк, а то, что в нем не нравится — менять на свои части. Или выдергивать компоненты симфони и строить из них что-то своё. Но не писать всю эту фигню с нуля.
Когда пишешь с нуля — получается не так качественно, не так протестированно, не так гибко, не так документированно, как взять готовый компонент фреймворка.
К словам Расмуса я вообще отношусь настороженно. Когда было голосование по отмене magic_quotes, Расмус голосовал против отмены. Человек явно не совсем в теме промышленной разработки
Мне одному кажется, что вся статья это просто жирный троллинг?
«All general purpose PHP frameworks suck» — кто-нибудь вообще гуглил эту фразу?
Читал в оригинале.
Как бальзам на душу :)

AloneCoder добавьте, пожалуйста, перевод на гитхаб, откуда переводили.
Не пойму нахрена писать свой велосипед поддерживать свой фреймворк… Считаю что правильно писать так, что бы было как можно меньше зависимостей с одной стороны но если есть зависимости, то к ним надо коннектиться так, что бы они максимально долго могли обновляться… самое дермовое когда твое приложение не сможет обновить зависимости — вот когда динь динь с признаками, «что-то тут не так»
Пока программисты философствуют, спорят, любуются, ошибаются, я спокоен за программистов.

Цитату Расмуса вырвали из контекста. Он её произнёс на PHP frameworks day 2013 в Киеве отвечая на вопрос. Там главная цель — посоветовать авторам фреймворков, как можно оптимизировать production-режим их работы. Это было вполне уместно, учитывая направленность конференции и присутствие разработчиков многих популярных фреймворков.


Вот полное видео, чтобы контекст понять: https://www.youtube.com/watch?v=anr7DQnMMs0

Надо было перефразировать так: все фреймворки под PHP, кроме Yii — полное дерьмо ;)

В том контексте, скорее, надо было упомянуть ReactPHP, хотя это всё-равно немного не то, о чём Расмус говорил. Его идею можно реализовать генерацией оптимального кода типа как Composer autoload-классы генерит.

Не понимаю, зачем столько копий ломать вокруг этой статьи. Если отбросить всю воду, то смысл статьи очень простой «Выбор инструментов должен зависеть от конкретной задачи, а не от крутости и популярности инструментов». И это абсолютно справедливо, я считаю.
Если использование конкретного фреймворка реально упрощает решение задачи, то замечательно. А если вы за уши притягиваете фреймворк ради «я использовал модный и популярный фреймворк, я крут» то гнать вас в шею.
То же самое про подгон каждого чиха под шаблоны проектирования ради того, чтобы доказать всем, что эти шаблоны знаешь.
То же самое про ООП — «все ооп пишут, скажут что я лох, если не использовал ооп в своем скрипте на 10 строчек».

Если у вас есть мега крутая болгарка, которую все хвалят и вам нужно спилить ветку яблони на даче, то странно будет, если вместо того, чтобы взять старую ножовку, вы повезете на дачу дизель-генератор чтобы подключить к нему модную болгарку, правда ведь?
Любые аналогии ложны. Можно сказать и так: «если у вас на даче есть болгарка с генератором, зачем ехать в город за ножовкой?!».
Бред.

Если ты годами пилишь один проект в маленькой команде, то может и ОК. В реальности люди уходят/приходят, проекты меняются.

Из практики:

  1. Получил недавно проект на plain php — неделька нужна только чтобы вникнуть в идеи, которые автор закладывал при проектировании приложения. При очередном коммите реально боишься сломать что-то, серьезно что-то поменять в архитектуре не поломав половину просто нереально.
  2. Получил в наследство проект на Yii2 — пару дней на погружение, и то, потому что автор много уходил он стандартов, описанных в документации.
  3. Получил в наследство проект на Symfony — пол дня понадобилось чтобы войти в проект и делать реальные задачи.
Бывает абсолютно по разному, приходилось видеть творения написанные Java программистом на PHP + Symphony к тому же еще и первой. Вместо объяснения предметной области человек при передаче проекта углубился в «Тут у меня адаптерс фабрикой и работает это вот так.». Хотелось не просто матерится а бить по голове. Так как то что там фабрика мы и так увидели.

В то же время довелось работать в одной весьма мощной команде, свой фреймворк с нуля (даже два, гы), и всё настолько понятно и внятно что Yii/Symphony/Zend показались гипертрофированными гориллами. (при этом где-то пол дня чтобы въехать в это всё, но я сам автор фреймворка поэтому фреймворк для меня уже не имеет значения особого, главное понять чем руководствовался человек при его построении а дальше как по накатаной)

Так что… все очень по разному.
https://habrahabr.ru/company/mailru/blog/308788/#comment_9781382
вы правы абсолютно. Надо понимать, что в основная масса кодеров на фреймворках подыскивают design pattern для задачи, а Программист ими думает, потому что знает для чего они нужны и как они помогут удобно и гибко архитектурно решить задачу.
Поэтому отказ от фреймворка возможен и нужен только в случае команды очень опытных классных специалистов, которые читают приложение как азбуку.
Программистам же пока далеким от понимания архитектуры следует решать проблемы на фреймворке, который в данном случае уместнее перевести не как «каркас», а как «рамки» — рамки, которые не позволят уйти далеко от более-менее приемлимой архитектуры приложения.

PS ошибся веткой. ответ на коммент dezconnect https://habrahabr.ru/company/mailru/blog/308788/#comment_9781340
> Надо понимать, что в основная масса кодеров на фреймворках подыскивают design pattern для задачи, а Программист ими думает
У вас как-то недостаточно понтов в слове «Программист». Надо ещё вензелей добавить, золотые ленточки и всё такое. А кодеров наоборот, уменьшить, и коричневым цветом.
А если без шуток, то обычно никто ничем не думает. У всех есть какой-то привычный и хорошо изученный инструмент, и именно его и выбирают. Критерий «привычный» используется в подавляющем большинстве случаев. Ну, кроме тех, когда разработчик вообще непрофильный, и у него в принципе нет привычного фреймворка для данной задачи. Вот непрофильные как раз и начинают сравнивать, перебирать, критиковать :)
никаких понтов. Просто попытался программистов чуть-чуть поделить на тех, кто начал мыслить архитектурными понятиями и еще нет. Первые могут думать в ключе «доктрина решает все проблемы работы с сущностями», вторые могут думать так: «доктрина решает все проблемы работы с сущностями, я знаю все эти проблемы, знаю какой оверхед добавляет доктрина, знаю как архитектурно организовать работу, поэтому реализую все сервисом, репозиторием и pdo».
В моем понимании это не архитектурное решение, а просто оптимизация памяти/скорости, при этом с усложнением дальнейшей поддержки кода.

Как раз 2 параллельных проекта сейчас, один с PDO, другой с Doctrine. Вроде PDO и быстрее, но поддержка похожего кода заметно усложнилась. В проекте с Doctrine и Symfony там где нужно что-то реально быстро сделать, это делают демоны на Go. Писать их проще, чем plain php, а производительность в десятки-сотни раз лучше.
Статья натолкнула на воспоминания лекций по программированию с теорией, которая имеет право жить только в параллельной вселенной уникальных условиях и контексте, где люди программируют от скуки чтобы развлечься, где позволено выбирать между оптимизированным, полностью адаптированным решением под конкретную задачу и полуготовым шаблоном на костылях. Возвращаясь в суровые реалии, где ваши задачи порождает бизнес, а ресурсы имеют конкретные ограничения, пока мы будем писать «с нуля», конкурент с помощью пары команд в терминале займет нашу ЦА и заработанные деньги заинвестирует в 10 стажеров-студентов, которые на очередном «адском» фреймворке запилят фичи, которые мы только успели добавить в бэклог. Этот комментарий не о PHP, он о том, что каждое подобное решение (фреймворк? стандарт? безопасно? подход?) принимается под давлением большого количества факторов (за исключением фактора: потому что мейнстрим).
Автор (в ЛС 2 дня нет ответа про искажение смысла перевода): в конце статьи у вас:
Чтобы прийти к идеям, мыслям и решениям, отражённым на нашем сайте, не требуется большого опыта, если вы всегда делаете то, что говорят другие.

В оригинале:
Чтобы прийти к идеям, мыслям и выводам, отражённым на нашем сайте, не требуется большого опыта, если вы просто сосредоточены на этой теме, в которой отдельные вещи всегда делаются традиционно (или: «так, как говорят другие»).

А у Вас по смыслу «говорят другие» перенеслось на человека, автора. Да и ещё почему-то «всегда». Другими словами, грубо: «если у вас никогда своих решений не было, вы придёте к этим идеям и мыслям, что на сайте». Вот эта бессмысленность фразы и заставила меня взглянуть в оригинал: ).
(The ideas, thoughts, and conclusions expressed on this website doesn’t take much experience to reach if you just stay focused on the main theme which is to always do a particular thing because other people says so.)

Спасибо за перевод


Удивительно, как много текста требуется, что бы сказать "Здравый смысл — превыше всего".


Неправильный путь: всегда использовать фреймворк поверх PHP.

Если пишешь маленькую либу для преобразования строк, или что-то типа того — ясное дело, что фреймворк тебе не нужен, он просто не будет использоваться. Если же фреймворк, как набор инструментов реально помогает жить — не пользоваться этим глупо.


Фреймворк — это не просто набор многократно используемого кода: вы не сможете вырезать кусок из фреймворка и вставить его в проект.

После этой фразы где-то в мире грустит один Фабьен.


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

Если фреймворк не помогает решить задачу — он не подходит для этой задачи. На счет медленности фреймворков: PHP — язык быстрых решений, а не быстрых систем.


Но в любом случае вы добавляете в код новый уровень сложности, который совершенно не нужен!

Лолшто? Нужен, или нет — это зависит от проекта и его бизнес требований.


Когда мы пытаемся решать разные проблемы в рамках приложения с помощью одной конкретной парадигмы программирования, мы перестаём творчески мыслить и эффективно работать.

Когда мы начинаем творчески мыслить и внедряем множество парадигм в действительно крупном проекте мы становимся золотарями.


Неправильный путь: искать шаблон для решения проблемы.

Если твою проблему решили 100500 раз — так как раз таки надо поискать как.


Неправильный путь: всегда использовать объектно ориентированное программирование.

Когда PHP станет чисто ФП языком — тогда согласен. (Это не касается проектов на 5-50 строк, там в принципе все равно)


Неправильный путь: бояться кода, написанного другими.

Но обезопасить свой код от дурака — таки надо))


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

Заговор, заговор! Где моя шапочка из фольги. Если стандарты есть — это на порядки круче, чем если их нет.


Если и нужна какая-то группа, то её стандарты должны отражать интересы всего PHP-сообщества, а не одних лишь разработчиков фреймворков и open source CMS проектов.

Зачем так ограничиваться?)) Нужна группа, которая поможет всему человечеству))


Во многих сферах требуется высокомасштабируемое, критичное ко времени выполнения, экономически выгодное ПО, которое просто невозможно создать, если следовать стандартам PHP-FIG.

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


Неправильный путь: следовать стандартам PHP-FIG, за исключением PSR-1 и PSR-2.

А как же PSR-5, PSR-12?)) Если стандарт не противоречит бизнес требованиям проекта И дает плюшки — глупо им не пользоваться.


Неправильный путь: не разрабатывать приложение безопасным по умолчанию.

Печаль, такое хорошее было начало, и такой вывод… Неправильный путь: вспоминать про безопасность по умолчанию после того как вас хакнули на тролололиард денег.

Неправильный путь: не разрабатывать приложение безопасным по умолчанию.

Посыпаю голову пеплом, тут 2 "не", я же прочитал с одним))

«Не могу молчать» (С) Л. Толстой.
Выскажу своё любительское мнение.

Считаю неправильным начинать осваивать язык с ООП, ибо сильно абстрагирует от понимания более низкоуровневых процессов. Это моё субъективное мнение, но есть люди, которые считают также.

Для огромной доли веба (не берусь сказать в процентах) ООП не нужен, его повсеместное использование навязывается бизнес-интересами отдельной группы разработчиков.
Мы все прекрасно знаем схему: чтобы оправдать существование, нужно постоянно предлагать что-то новое.

И тем не менее, ООП в PHP, думаю, оправдан в очень крупных проектах: когда работает несколько программистов, когда есть хорошая координация между ними, когда описание разрабатываемого функционала отдельным программистом появляется почти одновременно с кодом, т.е. когда есть возможность понять, какой класс, например, только что написал программист.

P.S.
Сижу кручу Devel Next, ООП фактически не знаю, но по поводу удобочитаемости (чисто субъективно), мне надо сделать конкатенацию строк из двух форм, простота этого действа в ООП манит и тревожит одновременно:

$this->browserUrl->text=$this->edit->text.$this->browserUrl->text;


Считаю неправильным начинать осваивать язык с ООП

Вы хотели сказать "осваивать программирование"? Если так — то согласен. Для начала следует со структурным программированием разобраться, разобраться с декомпозицией, функциональной абстракцией и т.д.


Исходя из моих наблюдений ООП для большинства это "классы", просто "модули для функций". Вы можете об этом судить банально по количеству статических методов, по наличию геттеров и сеттеров и т.д. Это старое доброе процедурное программиронивае но почему-то для большинства это ООП.


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

Повторюсь — а что вместо? Единственная адекватная альтернатива — функциональне программирование, которое в PHP практически нереально применять в удобном виде.


И тем не менее, ООП в PHP, думаю, оправдан в очень крупных проектах

да нет, в любом проекте ООП норм. Есть отдельные задачи где ООП не очень хорошо подходит. Потому следует знать и об альтернативах и не зацикливаться на одной концепции. Но веселье в том что никто не заставляет использовать только одну парадигму. Скажем смешание идей функционального и объектно-ориентированного очень даже хорошо. Оно как бы даже не конфликтует между собой особо.


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

Можете пояснить что вы имеете ввиду? И опять причем тут классы?


описание разрабатываемого функционала отдельным программистом

Тесты? TDD? BDD?


простота этого действа в ООП манит и тревожит одновременно:

погуглите про "закон деметры". Вы такой записью его нарушаете поскольку работаете с внутренним состоянием объектов BrowserUrl, edit и т.д. То есть проблема не в ООП в вашем случае а проблема в том как реализовано то что вы используете, в нарушении инкапсуляции.

погуглите про «закон деметры».

Спасибо. Попробую вникнуть. Интуитивно чувствовал, что что-то не так, хоть и работает.
Можете пояснить что вы имеете ввиду? И опять причем тут классы?

Я, может, и не очень точно выразился, но когда посматривал разные крупные проекты на том же гитхабе, подметил за собой одну вещь: если я бы даже знал ООП на элементарном уровне, мне бы не всегда было достаточно мнемоники (и комментариев) разного рода «сущностей»: классов, методов и т.д… а если много народа работает над проектом и новое появляется очень быстро… лично для себя вижу выход отдельного полного описания той или иной части проекта… Приведу пример, я не пытался кодить ООП, но редактировать пытался, мне как-то попался один игровой проект (браузерная игра), — крупный брошенный проект — там не работала пара вещей, я начал ковырять, описания не было, чтобы исправить ошибку ушло очень много времени…
Вы хотели сказать «осваивать программирование»?

Ну так многих зазывают на фреймворки, хотя они ни строчки кода не написали на PHP.

Повторюсь — а что вместо? Единственная адекватная альтернатива — функциональне программирование, которое в PHP практически нереально применять в удобном виде.

Не нужно вдаваться в крайности. Не пере-ООП-шить. А то такой код стороннему человеку не особо понятен.
Типа: я крутой перец, замутил тут абстракций, а вы разбирайтесь.

Но веселье в том что никто не заставляет использовать только одну парадигму.

Ну как бы существует «мнение» «авторитетов», что кто не использует ООП, тот лох.
Прошу прощения, что не в тему:
Я правильно понимаю, что чтобы не нарушить инкапсуляцию, достаточно
внутри метода задать переменную для объекта из другого метода, типа
$var=$this->browserUrl->text
и в начале класса сделать var private…
Или я чего-то не понимаю… ?!
Лучше вообще не делать private, а делать protected.
Для огромной доли веба ООП не нужен

+1.
Достаточно использовать базовые возможности ООП без оверинжиниринга.
Приятно осознавать, что не только я считаю, что фреймворки зло.
Разумеется лень двигатель прогресса, но в итоге это привело к куче кодеров даже в топовых IT компаниях с 2х недельными курсами с нуля, которые без фрейворка даже 2 + 2 сложить не могут. В корень обленились, никакого понимания сути происходящего за ширмой написанного кем-то чужого кода.

Да, бесспорно использование готовых модулей сильно сокращает время разработки, но за это расплачиваться приходится дырами в безопасности (только появится новая дыра, сразу же 100500 сайтов подвержены угрозе взлома по единому сценарию), а также сливу 50%+ ресурсов сервера из-за отсутствия оптимизаций под конкретную задачу.

Если ранее понты шли от того кто сколько языков знает (иностранных и программирования), то теперь кто сколько фреймворков знает.
Считаете это нормально? Скорее это мина замедленного действия пока весь этот мыльный пузырь не лопнет от очередной уязвимости случайно обнаруженной у 2/3 рунета.
Приятно осознавать, что не только я считаю, что фреймворки зло.

зло — не фреймворки, а кривые руки. доводилось патчить код одного противника фреймворков, и в нем была куча переменных вида $u, $uid, $tid, $o и т.п… Что не дай человеку — чистый php, symfony, phalcon — все превратится в нечитаемый поток ужаса. И всегда есть вариант собрать по отдельности из библиотек, почитав код перед этим.
Помимо брейшей в программировании есть бреши в общих концепциях построения систем, например, систем хранения данных, которые просто не просчитали.
Вот пример: закон Яровой — та часть, которая о «новых требованиях к операторам связи и интернет-проектам».
Краткая суть — очень долго хранить все данные, но никто, похоже, не просчитал, что будет если технический хакинг войдет в симбиоз с социальным. Я имею в виду не банальный взлом и слив информации, а подмену информации, например, о конкретном человеке или группе лиц, которая может навредить.
С общим падением фундаментальных знаний ситуация может стать непредсказуемой. Но прошу прощения, что отшел от темы.
PHP — это огромный ящик с инструментами, позволяющий решать самые разные задачи самыми разными способами, а не только одним. PHP — это свобода

Скааааааааайп…