company_banner

PHP: неправильный путь

http://www.phpthewrongway.com/
  • Перевод
image

В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.

Похоже, все эти люди без устали стараются заставить каждого программировать так, как они считают нужным. Эта статья написана, чтобы поделиться прагматичным взглядом на PHP-программирование. Взглядом, продиктованным опытом и практическими последствиями, а не популярными тенденциями, теориями или академическими догмами. Материалы, представленные на сайте PHP — The Wrong Way, будут обновляться по мере появления новой информации. Приглашаем всех поучаствовать в этом.

Опасность экстремизма


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

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

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

Принцип KISS, который некоторые расшифровывают как «Keep It Simple, Stupid», — чрезвычайно мудрый и правильный, опытные люди призывают следовать ему. Но даже KISS может стать угрозой для проекта, если довести его до абсурда. Есть такое понятие, как излишняя простота, что в нашем случае приводит к недостатку функциональности.

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

Постоянное использование фреймворков


Все PHP-фреймворки общего назначения — отстой!
Расмус Лердорф

В PHP-сообществе по-настоящему плохая тенденция превратилась в де-факто стандарт при разработке веб-приложений. Речь идёт об использовании популярных фреймворков общего назначения.

Это явление широко распространилось. Причина тому — не улучшение результатов разработки и не правильность выполнения каких-то операций с точки зрения технологий и архитектуры. Просто некоторые авторы фреймворков увлекли за собой сообщество разработчиков с помощью полемики, направленной против создания приложений с нуля. Характерными лозунгами стали «Не изобретайте колесо!» и «Не надо всё делать самостоятельно, об этом уже позаботились более опытные».

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

Этим людям настолько нравится увлекать других за собой, становиться своеобразными лидерами мнений в PHP-сообществе, убеждать всех использовать свежие и «модные» open source инструменты, что они забывают удостовериться в осмысленности и толковости своих советов. Фреймворк общего назначения можно сравнить с собранным на фабрике домом. Строительство приложения с помощью такого фреймворка сделает вас кодером или программистом в той же степени, как возведение заранее собранных домов превратит вас в плотника.

В этой статье мы различаем фреймворки и библиотеки по следующим признакам:

  • Библиотека — это набор многократно используемого кода. Например, стандартные библиотеки С или Go. Код библиотеки можно легко и без ограничений внедрить в проект. Она состоит из маленьких фрагментов, у каждого из них есть конкретная функциональность.
  • Фреймворк — это не просто набор многократно используемого кода: вы не сможете вырезать кусок из фреймворка и вставить его в проект. Эта система помогает создавать ПО, но в то же время накладывает на вас ограничения, присущие самому фреймворку. Кроме того, во фреймворке немало взаимозависимой функциональности: одна часть не сможет работать без других.

В мире Python и Ruby создание веб-сайтов с нуля — занятие довольно утомительное, поскольку эти языки для создания веб-сайтов не предназначались. В результате фреймворки общего назначения, такие как Django и Ruby on Rails, быстро стали популярны именно для сайтостроительства на Python и Ruby.

А PHP Расмус Лердорф изначально создавал как набор инструментов, написанных на С, позволяющих легко и быстро разрабатывать динамический HTML. PHP таким задумывался и таким остался, он сам и есть фреймворк.

Всё время своего существования PHP активно развивался, и сегодня он может использоваться для гораздо более разнообразных задач, нежели строительство HTML и веб-сайтов. Но неправильно относиться к PHP как к фреймворку. По своей природе он является уровнем абстракции для разработки веб-приложений, который целиком написан на процедурном С.

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

А вот использование фреймворка поверх PHP — совсем другое дело.

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

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

Чётко уясните: строк кода в любом проекте должно быть как можно меньше, чтобы код стал как можно чище и читабельнее!

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

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

Всегда используйте прагматичный подход, при котором:

Действие или политика продиктованы рассмотрением прямых практических последствий, а не теорией или догмой.
Словарь английского языка Collins, полная версия, 12-е издание, 2014

Неправильный путь: всегда использовать фреймворк поверх PHP.

Постоянное использование шаблонов проектирования


У меня сильная аллергия на оторванные от жизни проекты и шаблоны проектирования. Питер Норвиг написал хорошую статью о том, что шаблоны проектирования — это лишь недостатки вашего языка программирования. Перейдите на язык получше. И он абсолютно прав. Все поклоняются шаблонам и только и думают: «Ага, я воспользуюсь шаблоном Х».
Брендан Айх. Coders at work — Reflections on the Craft of Programming

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

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

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

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

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

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

Я думаю, изначально шаблоны были некими узнаваемыми лучшими решениями частых проблем. Но спустя некоторое время мы обнаружили, что приложения стали в десять раз сложнее, чем нужно, потому что люди пытаются запихнуть туда все шаблоны, о которых они читали («Моё приложение хорошо продумано, потому что по горло нагружено шаблонами»). Так что моё представление о ценности шаблонов изменилось.
Пол Уитон. Evil Design Patterns

Всегда используйте прагматичный подход, при котором:

Действие или политика продиктованы рассмотрением прямых практических последствий, а не теорией или догмой.
Словарь английского языка Collins, полная версия, 12-е издание, 2014

Неправильный путь: искать шаблон для решения проблемы.

Постоянное использование объектно ориентированного программирования


Проблема ОО-языков в том, что они тащат за собой всё своё неявное окружение. Вы хотели банан, но при этом получили гориллу, которая держит банан, и все джунгли в придачу.
Джо Армстронг. Coders at work. Reflections on the Craft of Programming

Абстракция — это сила. А что меня действительно отвращает и о чём я говорил ещё в 1990-е, так это CORBA, COM, DCOM, объектно ориентированная чушь. В то время каждый стартап предлагал какую-нибудь безумную вещь, которая при запуске вызывала 200 тысяч методов и выводила «Hello world». Это же пародия! Вам, как программистам, не нужно ассоциировать себя с такими вещами.
Брендан Айх. Coders at work. Reflections on the Craft of Programming

Многие разработчики и компании сегодня считают, что ООП — единственный оправданный способ разработки. А те, кто с этим спорят, немедленно осознают, что идут против «общепринятого мнения» индустрии.

Блоги и форумы, посвящённые программированию, полны защитников ООП, уверенных в том, что они понимают, о чём говорят, хотя какого-либо стандартного определения не существует.

Но дело в том, что так называемое объектно ориентированное программирование очень часто бывает излишне сложным!

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

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

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

Маленький исторический урок


Один из лучших способов понять парадигму программирования — посмотреть, как она возникла. В чём причина? Из-за каких проблем в других парадигмах понадобился новый подход? Была ли проблема практическая или академическая? И сколько времени прошло с момента создания парадигмы?

Неважно, что говорит человек Х или какое определение даёт человек Y. Важны исторические предпосылки возникновения парадигм.

Есть два пути разработки архитектуры приложения. Первый — сделать её настолько простой, чтобы, очевидно, недостатков не было. Второй — сделать её настолько сложной, чтобы очевидных недостатков не было.
Чарльз Энтони Ричард Хоар

Раньше, ещё до пришествия ООП, примерно в конце 1950-х, для создания многих программ использовали языки с упором на неструктурированное программирование. Их иногда называют языками первого и второго поколений. Неструктурированное программирование исторически стало первой парадигмой. Её активно критиковали за спагетти-код.

Есть и высоко-, и низкоуровневые языки, использующие неструктурированное программирование. Например, BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, машинный код, ранние системы ассемблера (без процедурных метаоператоров), ряд скриптовых языков. Программа на неструктурированном языке обычно состоит из последовательно расположенных команд или выражений, обычно по одной на строку. Строки либо нумеруются, либо могут содержать метки, позволяющие потоку выполнения переходить к любой из строк (вроде непопулярного выражения GOTO). В 1960-х появилось структурное программирование, во многом благодаря известному письму Эдсгера Дейкстра Go To statements considered harmful.

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

Затем из структурированного программирования возникло процедурное. В его основе лежит концепция «вызова процедуры». Это ещё одно название для «вызова функции». Процедуры также известны вам как подпрограммы или методы. По сути, это серия вычислений, которые необходимо выполнить. Любая процедура может быть вызвана другими процедурами или самостоятельно в любое время в ходе исполнения программы.

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

Возникла новая методика, позволяющая разделять данные на разные области видимости: «объекты». К одним и тем же данным могли обратиться только конкретные процедуры, принадлежащие к той же области видимости. Это называется скрытием данных, или инкапсуляцией. В результате удалось гораздо лучше организовать коды.

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

Затем, в основном из-за появления Java, появились новые модные термины, а «процедуру», или «функцию», переименовали в «метод», когда он принадлежит отдельной области видимости. Переменные переименовали в «атрибуты», когда они принадлежат отдельной области видимости.

Так что объект, по сути, — это просто набор функций и переменных, которые теперь называют методами и атрибутами.

Методы и атрибуты изолируются внутри отдельной области видимости с помощью «класса». А когда создаётся экземпляр класса, он называется объектом.

Объекты могут ссылаться друг на друга, и благодаря этому методы (функции) внутри них тоже «взаимодействуют» друг с другом. Также объекты могут «наследовать» методы от других объектов, тем самым расширяя их, это называется «наследование». Это способ многократного использования кода, позволяющий создавать независимые расширения приложений через публичные классы и интерфейсы. Взаимосвязи между объектами породили иерархию. Наследование было создано в 1967 году для языка Simula 67.

Объекты также могут наследовать методы от других объектов и «переопределять» их с помощью дополнительной или изменённой функциональности, это называется «полиморфизм».

В разных языках эти идеи реализованы очень по-разному.

Объектно ориентированное программирование — это иной способ организации кода. Это расширение процедурного программирования, связанное с сокрытием данных (инкапсуляцией) и избеганием глобальных областей видимости. Это расширение функций посредством «заимствования» их чертежей без влияния на оригинальный код (наследование). И это переопределение функций без влияния на оригинальный код (полиморфизм).

Модель ООП позволяет легко создавать программы путём аккреции (наращивания). На практике это зачастую означает, что это структурированный способ написания спагетти-кода.
Пол Грэм. Ansi Common Lisp

Неправильный путь: всегда использовать объектно ориентированное программирование.

Бояться чужого кода


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

Это довольно странное мышление, в основном характерное для веб-разработчиков, говорит о недостатке профессионализма и опыта.

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

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

Профессионалы так не думают. Ни один.

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

Программирование во многом подразумевает взаимодействие с людьми, использующими чужой код. Это часть работы: пытаться улучшить существующую кодовую базу, и иногда приходится её полностью переписывать. Почитайте, что говорят мастера программирования в книге Coders at work. Reflections on the Craft of Programming.

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

Ядро Linux содержит более 20 миллионов строк кода, написанных исключительно с помощью процедурного программирования. В его создании участвовали 14 тысяч человек — и никаких фреймворков. Разные возможности BSD и большая часть Linux GNU userland также написаны только с помощью процедурного программирования без применения фреймворков.

То же самое можно сказать о сотнях open source проектов по всему миру, заброшенных авторами только для того, чтобы их подхватили другие опытные программисты. По многим из этих проектов очень мало документации (или её вообще нет), нет комментариев в коде, нет руководств или иных видов помощи.

Да чего уж там — вся кодовая база PHP написана на С, процедурном языке, без фреймворков.

Когда вы определяете класс в PHP или когда вы запускаете свой любимый PHP-фреймворк, вы выполняете чью-то процедурную работу!

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

Безусловно, существует кошмарный спагетти-код, но никто не пишет его намеренно. Иногда это результат нехватки опыта, зачастую — вина клиентов, много раз меняющих спецификации посреди разработки. Но в обоих случаях вы бы всё равно получили спагетти-код, даже при использовании фреймворка. И неважно, насколько интенсивно вы станете применять объектно ориентированную парадигму: результат окажется тем же.

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

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

Следование стандартам PHP-FIG


FIG расшифровывается как Framework Interoperability Group (Группа по совместимости фреймворков).

PHP-FIG была создана разработчиками фреймворков на конференции php|tek в 2009 году. С тех пор её состав увеличился с 5 до 20 участников.

С PHP-FIG связано много споров. Одни считают это лучшим начинанием PHP-сообщества со времён возникновения самого PHP. Другие уверены, что стоит вообще поскорее забыть о существовании этой группы.

Одна из проблем заключается в том, как PHP-FIG позиционирует себя в своём FAQ:

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

Однако если мы посмотрим на работу нескольких участников группы, становится очевидно, что реальная цель полностью противоречит заявленному. Группа всячески старается превратить PHP-FIG в «группу PHP-стандартов», что было их первоначальным названием. В книгах участников группы, на их сайтах, в блогах, на форумах и т. д. работу PHP-FIG именуют современным PHP, а все остальные подходы объявляют устаревшими.

Проблема PHP-FIG в том, что, хотя многие фреймворки и open source-проекты внедрили у себя ряд стандартов группы, сами эти стандарты в основном призваны решать проблемы «с точки зрения фреймворка», что делает их бесполезными во многих практических ситуациях.

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

Если и нужна какая-то группа, то её стандарты должны отражать интересы всего PHP-сообщества, а не одних лишь разработчиков фреймворков и open source CMS проектов. Такая группа должна представлять разработчиков самого языка PHP, с гораздо большим количеством участников, причём с правом голоса.

Если вы решили следовать стандартам PHP-FIG, то вы должны понимать, что некоторые из них — например, стандарты автозагрузчика PSR-0 и PSR-4 и ряд других — напрямую влияют на то, как вы пишете код ПО.

Во многих сферах требуется высокомасштабируемое, критичное ко времени выполнения, экономически выгодное ПО, которое просто невозможно создать, если следовать стандартам PHP-FIG.

Неправильный путь: следовать стандартам PHP-FIG, за исключением PSR-1 и PSR-2.

Пренебрежение безопасностью


С программистами есть одна проблема: вы никогда не знаете, что делает программист, пока не становится слишком поздно.
Сеймур Крей. defprogramming.com

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

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

Нельзя просто добавить безопасность в приложение!

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

Безопасность критических программных ресурсов сегодня важна как никогда, поскольку основной вектор атак неуклонно перемещается на уровень приложения. По итогам исследования SANS 2009 года, атаки против веб-приложений составили более 60 % всех атак, зарегистрированных в интернете.

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

Безопасность по умолчанию


Сложность убивает. Она высасывает жизнь из разработчиков, затрудняет планирование продуктов, их создание и тестирование, ставит перед нами вызовы в сфере безопасности и утомляет конечных пользователей и администраторов.
Рей Оззи

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

Неправильный путь: не разрабатывать приложение безопасным по умолчанию.

FAQ


Всё вышеописанное легко понять неправильно — давайте кое-что проясним.

В чём цель вашего сайта и почему вы плывёте против течения?
Цель — начать дискуссию о современных методиках и крайних точках зрения.

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

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

Если фреймворк помогает мне быстро начать и продолжить работать, что в этом плохого?
Если вы проанализируете ситуацию и долгосрочные последствия и поймёте, что «быстро начать и продолжить работать» — единственная проблема, которую вы когда-либо решали, то в этом нет ничего плохого. Но тогда мы говорим не о программировании или разработке ПО, а об использовании point-and-click решений.

Быстро начать и продолжить работать — это не создание приложения; это означает, что вы не анализировали проблему и не осознали долгосрочных последствий своего выбора.

Вы хотите сказать, что сторонние пакеты — это плохо?
Нет. Мы рекомендуем использовать сторонние библиотеки. Код, который вы можете легко и без ограничений внедрять в свои проекты. Это отличная возможность!

Кто вы?
Наш сайт посвящён идее борьбы с экстремизмом в PHP-сообществе, а не личному продвижению или обретению известности. Если мы раскроем имена — это лишь отвлечёт внимание от поднятых на сайте проблем. Давайте не будем отвлекаться.

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

Рекомендуемая литература


  1. PHP: Неправильный путь — на Hacker News. Когда мы запустили наш сайт, на Hacker News появилось много комментариев, в которых отражено немало ценных аргументов.

  2. Как программировать без ООП. Свежая и альтернативная точка зрения: Брайан Уилл в трёх видео рассуждает о том, что не стоит начинать с ООП. В завершение он приводит несколько замечаний, как писать не ООП код.

  3. Кодеры за работой. Размышления о ремесле программирования. Интервью основаны почти на 80 часах бесед с 15 величайшими программистами и специалистами по информатике. Здесь вы найдёте многогранный рассказ о том, как они учились программировать, как они оттачивали своё мастерство и что они думают о будущем программирования.

  4. Черты квалифицированного программиста. Компетентность означает достаточное количество опыта и знаний для выполнения задачи. Квалифицированность — знание, почему вы делает что-то именно таким способом и как это укладывается в общую картину. Иными словами, квалифицированный практик всегда компетентный практик, но обратное необязательно верно.

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

  6. Принципы безопасного проектирования. Безопасность веб-приложений — неотъемлемый компонент любого успешного проекта, будь то open source приложение, веб-сервис сквозной обработки или проприетарные бизнес-сайты. Хостеры совершенно справедливо остерегаются небезопасного кода, пользователи остерегаются небезопасных серверов. Задача этого руководства — помочь бизнесу, разработчикам, дизайнерам и архитекторам решений создавать безопасные веб-приложения. Если пользоваться им с самых ранних стадий, то стоимость создания безопасных приложений будет сравнима со стоимостью небезопасных, при этом в долгосрочной перспективе финансовая эффективность окажется несравнимо выше.

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

  8. Улучшение существующей структуры кода с помощью рефакторинга . Рефакторинг позволяет улучшить имеющуюся структуру кода. Это изменение системы таким образом, чтобы внешнее поведение кода не менялось, но при этом внутренняя структура становилось более гармоничной. С помощью рефакторинга вы даже можете превратить плохую структуру в хорошую. В книге обсуждаются принципы рефакторинга, рассказывается, где его стоит применять в первую очередь и как настраивать нужные тесты. Также приведён каталог более чем из 40 проверенных рефакторингов с описанием, когда и зачем их применять, и пошаговые инструкции по внедрению. Заодно иллюстрируются схемы работы рефакторингов. Книга написана на примере Java, но её идеи применимы в любом другом ОО-языке.

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

  10. Прагматичный программист. Здесь исследуются ключевые процессы программирования, от подмастерья до мастера: выработка требований, выполнение работ, правильное сопровождение кода. Рассматриваются самые разные вопросы, начиная с личной ответственности и развития карьеры и заканчивая методикой разработки архитектуры ради сохранения гибкости, простоты адаптации и многократного использования кода.

  11. Понимание языков программирования. Выбор языка программирования — один из важнейших факторов, влияющих на общее качество программной системы. К сожалению, слишком многим программистам не хватает лингвистических навыков: они влюбляются в свой «нативный» язык и не способны критически анализировать его ограничения. Книга «Понимание языков программирования» написана, чтобы объяснить:

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

Метки:
Mail.Ru Group 942,86
Строим Интернет
Поделиться публикацией
Похожие публикации
Комментарии 368
  • +17
    Людям не нужны фреймворки общего назначения. Ни у кого нет общих проблем, каждый пытается решать очень специфические проблемы.
    Расмус Лердорф

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

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

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

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

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

              когда вы ловите segfault ;)

              • 0
                Я не говорил что багов нет, я говорил что тормоза во фреймворках, чаще всего, надуманная и не актуальная проблема ;)
                • 0
                  То есть, Вы таки признаете, что на фреймворках есть баги? :)

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

                              Спор ниочем.


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


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


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


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

                              • НЛО прилетело и опубликовало эту надпись здесь
                                • +1

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


                                  image


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

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

                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • 0
                                      А «медленный старт»? Окно?

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


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

                                      • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Это ложь!
                    • 0

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


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


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

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

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

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

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

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

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

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

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


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


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


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


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


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


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

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

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

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

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

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

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

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

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

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

                      • +4

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

                  • –12
                    В яблочко! Особенно про фреймворки которые используют где ни попадя и часто без нужды.
                    Кстати, это не только в PHP. Типичнейший пример использования той же тактики — jQuery в мире JavaScript.
                    • +2
                      jQuery особенно нужен был в эпоху разного api в браузерах. Сейчас все немного устаканилось, но есть не реализованный функционал в одних и присутствие оного в других. Тут то и пригождаются такие библиотеки.
                      • 0
                        Я не спорю с его плюсами и, даже, полезностью. По к месту и времени, а не бездумно и почти везде.
                        В результате попадаются индивиды, которые оригинальный JS толком понимать перестают. Не говоря уже за скрытые за кодом принципы и суть реализуемых процессов.
                        • +5

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

                                                  • 0
                                                    Я просто думал, что они (мейнстримовые фреймворки) решают какие-то абстрактные надуманные задачи вместо реальных:
                                                    http://blog.kpitv.net/article/frameworks-1/
                                                    :^)
                                                    • 0
                                                      Рассуждаете, будто знаете 2+ фреймворков, хотя по вашим комментам видно обратное — вечная ссылка на yii 1))
                                                      • 0

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

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

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

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

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

                                                            >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? Нету? Фиии… Нафига мне хлебные крошки, если нет элементарного?!

                                                            Ну, думаю, пока что хватит…
                                                            • 0
                                                              У вас? Или у создателей фреймворков? А какое «правильное понимание 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 функциями.

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

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

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

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

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

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

                                                                В 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 функциями.

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

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

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

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

                                                                  Через какое-то время появляется контроллер 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: неправильный путь :)
                                                                  • 0
                                                                    >На предыдущих работах так и было.

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

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

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

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

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

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

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

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

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

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

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

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

                                                                    Пруф?)))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                    >Меню? О, да.

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

                                                                        Пруф?)))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                          ))))) Жесть…

                                                                          >Зачем пруф? Это разве не ясно, что виджеты пятое колесо? А все из-за того что в неверном понимании 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кб ;)
                                                                          • 0
                                                                            Ого ответили :)

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

                                                                            Ответьте на 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 сложилось мнение, что это язык говнокодеров. Хотя на нем пишут и нормальные программисты.
                                                                            • +1
                                                                              >Ого ответили :)

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

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

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

                                                                              >Ответьте на 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.: на этом дискуссию закрываем. Выходные закончились)
                                                                              • 0
                                                                                >Ну так вы и велосипедите ;).

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

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

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

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

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

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

                                                                                Можете, но построитель запросов расчитан на 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.: на этом дискуссию закрываем. Выходные закончились)

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

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

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

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

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

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

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

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

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

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

                                                                                  Кому нужно — берут 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 свой фреймворк, хотя-бы раз в жизни написать свой блог, форум. Для саморазвития — да, возможно. Для реальной работы — нет, противопоказано.

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

                                                                                    Тогда осилив 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
                                                                                      > Тогда осилив 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.»

                                                                                      Вроде как четко написано, что таблицы все-равно блокируются на короткие интервалы. А значит имеем проблемы с производительностью. Потестирую на досуге, но мало верится, что здесь что-то полезное сделали.

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

                                                                                      А что с ними?)) Думаете, они пишут абсолютно все с нуля?))))
                                                                                      • –1
                                                                                        >А в чем у вас отличие от «фреймворков»?)

                                                                                        «фреймворк вызывает функции пользовательского кода» (https://ru.wikipedia.org/wiki/Фреймворк )
                                                                                        У меня более гибридная схема. Чаще я прошу сам, чтобы ядро выполнило какой-то мой код.

                                                                                        Контроллером/моделью/шаблоном может быть любой сторонний код, хотя пока я использую сам.

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

                                                                                        Задача процессор не тратит, это блокирующая операция с сетью.
                                                                                        Вечный цикл можно и в 3 строки написать. :)

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

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

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

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

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

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

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

                                                                                        Их нужно тоже структурировать.
                                                                                        Если любого кода много, то с ним трудно работать. Поэтому я стараюсь писать меньше кода :)

                                                                                        >Т.е. для апи стандарта не надо

                                                                                        Так все апи разные.
                                                                                        Поэтому проще пользоваться универсальной оберткой.

                                                                                        >А зачем эта лишняя сущность?) Вы же против лишних сущностей, но я уже с десяток их насчитал ;)

                                                                                        Так Вы на каждый АПИ сервис предлагаете вводить сущность и реализацию один в один. :)

                                                                                        >А зачем эта лишняя сущность?

                                                                                        Модуль ядра — это не лишняя сущность. Это модуль (модель, компонент), который поставляет поставщик ядра.

                                                                                        >Весь код — нет конечно. Но частично — легко. Например, перевели кеш с файлов на редис — получили доп.функционал в качестве тегов. Почему не использовать? Да, переделываем кеширование.

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

                                                                                        >Да что вы говорите))). Давно есть реплика в мемкеше?)))

                                                                                        Репликаций вроде нету.
                                                                                        Можете сами реплицировать :)

                                                                                        >А что с ними?)) Думаете, они пишут абсолютно все с нуля?))))

                                                                                        Я тоже все не пишу.
                                                                                        Но каркас-то они хоть пишут сами?
                                                                                        Да и ВК как бы без ООП.
                                                                                        Или там все на фреймворках у них? :)
                                                                                        • 0
                                                                                          >«фреймворк вызывает функции пользовательского кода» (https://ru.wikipedia.org/wiki/Фреймворк )

                                                                                          Вообще-то, это сказано про IoC (https://ru.wikipedia.org/wiki/Инверсия_управления) ;). «Фре́ймворк (иногда фреймво́рк; англицизм, неологизм от framework — каркас, структура) — программная платформа, определяющая структуру программной системы». Снова пытаетесь под себя перевернуть?)))))) У вас фреймворк (точнее — нано-фреймворк))).

                                                                                          >Задача процессор не тратит, это блокирующая операция с сетью.

                                                                                          Да вы что… ))))) Я этой задачей занимался на прошлой неделе ;). Попробуйте на досуге. Лучше сразу параллельно пользователей на 40 ;)

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

                                                                                          Не любите свой фреймворк?))))) Прямо описали ассоциации многих людей ;)

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

                                                                                          Не, простая математика. Но много)

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

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

                                                                                          >Такая же боль и при использовании фреймворка. :)

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

                                                                                          >Их нужно тоже структурировать.

                                                                                          Их надо использовать только там, где они полезны. Пихать везде — раскидывать грабли себе же.

                                                                                          >Поэтому я стараюсь писать меньше кода :)

                                                                                          Это видно). Писали-бы побольше — поняли-бы плюсы фреймворков. А писать бложики на 10 страниц много кода не надо)

                                                                                          >Так Вы на каждый АПИ сервис предлагаете вводить сущность и реализацию один в один. :)

                                                                                          Где это я такое предлагал?))) Чёт наговариваете вы на меня)))

                                                                                          >Модуль ядра — это не лишняя сущность. Это модуль (модель, компонент), который поставляет поставщик ядра.

                                                                                          Ух-ты… Есть «ядро», «поставщик ядра», «модуль», «компонент»… И этот человек против виджетов!!! Ахахахаха…

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

                                                                                          Это всего-лишь пример был).

                                                                                          >Мемкеш — распределенный.
                                                                                          >Репликаций вроде нету.

                                                                                          А в чем тогда выражается распределенность?! ))))))))))))))

                                                                                          >Можете сами реплицировать :)

                                                                                          Да ладно?! ВНИМАТЕЛЬНО СЛУШАЮ!!!

                                                                                          >Но каркас-то они хоть пишут сами?

                                                                                          С чего вы это решили?)))) Даже не так. Да, скорее всего что-то пишут сами. Потом используют в виде фреймворков, например так: https://github.com/facebook/FBMock ;)

                                                                                          >Да и ВК как бы без ООП.

                                                                                          И? Как это связано?)

                                                                                          >Или там все на фреймворках у них? :)

                                                                                          Скорее всего нет, я не знаю. Но точно уверен, что не на фреймворке на 50кб ;)
                                                                                          • 0
                                                                                            >Вообще-то, это сказано про IoC

                                                                                            Видимо текст страницы поменялся, цитату скопировал давно.
                                                                                            Да и это не суть важно.

                                                                                            >Наследование — это удобно в большинстве случаев.

                                                                                            Вы же сами говорили о возможных проблемах наследования… :)

                                                                                            >Где это я такое предлагал?))) Чёт наговариваете вы на меня)))

                                                                                            Читайте свои комменты, а то скажете, что имели другое в виду, типа имели в виду, что мой «фреймворк» унылый.

                                                                                            Остальное лень комментить :)
                                                                                            • 0
                                                                                              >Да и это не суть важно.

                                                                                              Ну да, не важно, когда по ссылке сказано вопреки вашим словам)))

                                                                                              >Вы же сами говорили о возможных проблемах наследования… :)

                                                                                              Снова наговариваете))) Никогда подобного не говорил.

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

                                                                                              Не поленился, перечитал — нет ничего подобного. Максимум что есть — вопрос к вам, в стиле «если пихаете в ядро всякий мусор наподобии меню и хлебных крошек, почему не пихаете всякие апи?». Я-же наоборот, раз 10 заявил, что ядро фреймворка должно быть минимальным, без всякого мусора. А для апи есть достаточно удобные обертки, например https://github.com/mpratt/Embera

                                                                                              В идеале, ядро = бутстрап-файл + composer.json.

                                                                                              >Остальное лень комментить :)

                                                                                              Не удивлен, но жаль — только разогрелся).
                                                                                              • 0
                                                                                                >Снова наговариваете))) Никогда подобного не говорил.

                                                                                                me:
                                                                                                >Можно подписаться на событие… :)
                                                                                                you:
                                                                                                >Можно. А можно наследоваться и переделать реализацию.
                                                                                                me:
                                                                                                >Можно. Но некоторые тру-фреймоворкоюзатели говорят, что наследование — зло.
                                                                                                you:
                                                                                                >Т.е. править ядро. Спасибо, не надо)
                                                                                                me:
                                                                                                >Это Вы предлагали наследоваться, а не я править ядро…
                                                                                                you:
                                                                                                >Верно. Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.
                                                                                                me:
                                                                                                >Наследование боль. Такая же боль и при использовании фреймворка. :)
                                                                                                you:
                                                                                                >Странная у вас логика). Наследование — это удобно в большинстве случаев.

                                                                                                Вы по ходу переписки выдумываете выдумки.

                                                                                                >А для апи есть достаточно удобные обертки, например https://github.com/mpratt/Embera

                                                                                                По описанию это встраивалка видео :)
                                                                                                • 0
                                                                                                  >Вы по ходу переписки выдумываете выдумки.

                                                                                                  Перечитайте свою выжимку ;). Где я говорю что наследование — зло?) Скорее наоборот: «Если я наследуюсь и правлю в наследнике — это отлично». Говорю-же — наговариваете на ровном месте))))
                                                                                                  Вы хоть перечитывайте что публикуете)))

                                                                                                  >По описанию это встраивалка видео :)

                                                                                                  Именно. Обертка над кучей апи в отдельной библиотеке.
                                                                                                  • 0
                                                                                                    >Перечитайте свою выжимку

                                                                                                    Вы выдумали, что с моим кодом у Вас будут проблемы с наследованием, а с фреймворком не будет.

                                                                                                    Fesor Вы вроде против наследования? :)
                                                                                                    • 0
                                                                                                      >Вы выдумали, что с моим кодом у Вас будут проблемы с наследованием, а с фреймворком не будет.

                                                                                                      Еще раз перечитайте ;). Я против правки ядра, а не против наследования. Даже написано чуть-ли не 1-в-1: «Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.».

                                                                                                      Может хватит уже придумывать?)
                                                                                                      • 0
                                                                                                        Вы вроде против наследования? :)

                                                                                                        Наследование — инструмент. Я против использования наследования там, где оно не нужно.


                                                                                                        В то же время вы полностью отвергаете разные "ненужные" SOLID и GRASP принципы, здравый смысл и т.д. оправдывая это личным вкусом.

                                                                                                        • 0

                                                                                                          @Fesor Вы пытаетесь спорить с программистом в 4-ой стадии))
                                                                                                          G-M-A-X Вам тоже не помешает прочитать


                                                                                                          https://habrahabr.ru/post/39300/

                                                                                                          • 0

                                                                                                            Я не пытался спорить, с ним бесполезно) Мне просто скучно)

                                                                                                            • 0
                                                                                                              4 Я крутой программер, я написал уже несколько больших программ, я знаю все о программировании!!!

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

                                                                                                              Я благодарен критике (наставлениям :) ).
                                                                                                              Если бы все пользовались готовыми решениями и не изобретали велосипед, то до сих пор жили бы в каменном веке.

                                                                                                              Вы считаете себя на какой стадии? :)
                                                                                                              • 0
                                                                                                                Я стараюсь работать с меньшим количеством кода, так как в голове все это трудно удержать :)

                                                                                                                Именно по этому и нужны эти все кучи абстракций.


                                                                                                                Вы считаете себя на какой стадии? :)

                                                                                                                на 5-ой

                                                                                                              • 0
                                                                                                                Читать вообще полезно. Читать и думать. :)
                                                                                                                И не только в своей профессиональной области, а и в других — для общего развития и расширения кругозора.

                                                                                                                Вот и Ваш совет, и текст по ссылке, напомнили мне другие темы, которые, на мой взгляд, не мешало бы знать и автору этого текста, и ссылающимся на него:

                                                                                                                Проекция (психология)
                                                                                                                Перенос (психология)


                                                                                                                Очень интересное и полезное чтение, рекомендую. :)
                                                                                                              • 0
                                                                                                                Каким же образом я отвергаю SOLID и GRASP?

                                                                                                                О GRASP, кстати, впервые слышу :)

                                                                                                                Я за здравый смысл.

                                                                                                                Ну нету мне смысла тянуть фреймворк и все на него переписывать.
                                                                                                                • 0
                                                                                                                  Каким же образом я отвергаю SOLID и GRASP?

                                                                                                                  лучше скажите в каком месте вы соблюдаете SOLID)


                                                                                                                  О GRASP, кстати, впервые слышу :)

                                                                                                                  Это проблема разработчиков. GRASP штука полезная, почитайте погуглите.


                                                                                                                  Я за здравый смысл.

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


                                                                                                                  Ну нету мне смысла тянуть фреймворк и все на него переписывать.

                                                                                                                  Мне кажется у вас какая-то травма психологическая вокруг фреймворков.

                                                                                                                  • 0
                                                                                                                    здравый смысл мне подсказывает что я лучше поищу готовый вариант нежели буду писать все сам и потом поддерживать это дело.


                                                                                                                    Если У Вас остается 90%, то ок.
                                                                                                                    А у меня останется 10%. :)
                                                                                                                    Проще все выбросить и написать самому 50 кБ.

                                                                                                                    И фреймворки это как раз тот готовый вариант для типичных задач.


                                                                                                                    Фреймворки не совсем решают типичные задачи. Это скорее CMS.

                                                                                                                    • 0
                                                                                                                      >А у меня останется 10%. :)

                                                                                                                      Так проблема именно в этом ;). Вместо того, чтобы использовать — переписываете)))
                                                                                                                      • –1
                                                                                                                        Так проблема именно в этом ;). Вместо того, чтобы использовать — переписываете)))

                                                                                                                        У Вас есть еда, которая для Вас не вкусная / Вы не любите / плохо желудку?
                                                                                                                        Вы ее едите? :)

                                                                                                                        Да и я не переписываю, это если бы переписывал, пришлось бы выбросить 90%.
                                                                                                                        А так я написал всего 50 кБ. :)
                                                                                                                        • +1
                                                                                                                          Когда я впервые попробовал роллы — очень не понравилось, сейчас заказываю часто. Пиво не пил до 18 лет. И сейчас не сильно его люблю, но в компании устраивает.

                                                                                                                          Да, я ем «не вкусную» еду, если считаю, что могу ошибаться или просто не повезло с поваром ;).
                                                                                                                          А вот вы упорно едите асфальт, вместо того, чтобы попробовать что-то более правильное, в плане еды)

                                                                                                                          Про 50кб задал вопрос в другой ветке — жду ответа ;)
                                                                                                                          • 0
                                                                                                                            Когда я впервые попробовал роллы — очень не понравилось

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

                                                                                                                            Да, я ем «не вкусную» еду, если считаю, что могу ошибаться или просто не повезло с поваром ;).

                                                                                                                            У вас просто выбора нет :)
                                                                                                                            Ну или Вы врете :)
                                                                                                                            image

                                                                                                                            А вот вы упорно едите асфальт, вместо того, чтобы попробовать что-то более правильное, в плане еды)

                                                                                                                            В реальности ем немного.
                                                                                                                            Также и в ИТ. Чтобы не растолстеть. :)

                                                                                                                            П.С.
                                                                                                                            Пользуюсь Windows XP, если не знаете :)
                                                                                                                            http://blog.kpitv.net/article/windows-xp/
                                                                                                                            Как Вам? :)
                                                                                                                      • 0
                                                                                                                        Если У Вас остается 90%, то ок.
                                                                                                                        А у меня останется 10%. :)

                                                                                                                        Чего от чего простите? Ну вот флоу. Мне нужно написать маленькую трейдинговую платформу. Функционал специфичный и потому готовых решенйи под это нет. Что я делаю:


                                                                                                                        беру симфони, беру доктрину. Накидывают бизнес сущности на plain php (без фреймворков), описываю как оно там между собой работает, с тестами например проверяю что все ок и начинаю лепить сверху уже инфраструктуру (мэппинги базы, схему потом мне доктрина сгенерит), разные сервисы по взаимодействию с внешними системами. Настрою swiftmailer что бы он мне почту через какой sendgrid/mailgun слал, роутинг, контроллеры, прикручу трансформеры на fractal что бы обезапасить себя от изменений в API в будущем и т.д.


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


                                                                                                                        Ну и да, у меня еще есть отдельные надстройки которые помогают экономить время. Например валидация данных запросов — https://github.com/fesor/request-objects — я его могу генерить из доки по API.


                                                                                                                        При этом всем все гибко просто и моя бизнес логика про фреймворк ничего не знает. А главное — мэйнтейнить такую систему будет проще.


                                                                                                                        Фреймворки не совсем решают типичные задачи. Это скорее CMS.

                                                                                                                        "не совсем решают" так себе характеристика. Типичные задачи для вас возможно отличаются для 95% других людей. Ну и "это скорее CMS" — это вы наверное все же про Yii.

                                                                                                                        • 0
                                                                                                                          При этом я не потратил ни минуты на решение каких-то стандартных задач вроде «отправка почты»

                                                                                                                          Я тоже такие вещи не переизобретаю, вроде не раз об этом говорил :)

                                                                                                                          Ну и да, у меня еще есть отдельные надстройки которые помогают экономить время. Например валидация данных запросов — https://github.com/fesor/request-objects — я его могу генерить из доки по API.

                                                                                                                          Вот и Вы написали свой велосипед. :)
                                                                                                                          Так и у меня есть такие надстройки, что мне даже фреймворк не нужен, и все влезает в 50 кБ… :)
                                                                                                                          На фреймворках есть плюсы, они гибкие. Но за гибкость нужно платить.
                                                                                                                          А также Вы использовали события в своем решении, aktuba был против событий :)
                                                                                                                          А также использовали стандартные интерфейсы, а не велосипедные. Вот я и говорю, что не помешало бы иметь такие интерфейсы для меню и хк. Вот увидите, скоро фреймворки это реализуют (а может и уже реализовали, но ни вы, ни я не в курсе :) )
                                                                                                                          Хотя не совсем понял, где прописаны у Вас сами правила валидации. Они как-то потом подключаются в зависимости от задач, заметил только проверку чтобы у некоторых запросов не было тела. :)

                                                                                                                          Ну и «это скорее CMS» — это вы наверное все же про Yii.

                                                                                                                          Хм, Yii никак не CMS.
                                                                                                                          Он решает ровно на том же уровне, что и остальные фреймворки.
                                                                                                                          Он более монолитный, что имеет свои плюсы и минусы, хотя туда можно тянуть любые компоненты.
                                                                                                                          • 0
                                                                                                                            Он решает ровно на том же уровне, что и остальные фреймворки.

                                                                                                                            Напомните с какими фреймворками вы работали плотно?


                                                                                                                            Вот и Вы написали свой велосипед. :)

                                                                                                                            я портировал идею из laravel и spring под symfony. Если у меня дойдут руки переделать это дело под PSR-7 и отвязаться от symfony/validation — то как бы оно не будет привязано к фреймворку.


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

                                                                                                                            Гибкость = избыточность и так было всегда. Меня избыточность фреймворков полностью устраивает потому как это сокращает время разработки моих задач.


                                                                                                                            А также Вы использовали события в своем решении

                                                                                                                            Симфони по другому не позволяет вклиниться в пайплайн обработки запросов. По сути это часть интграции с фрейморком, сама же либка не завязана на них. Для laravel это можно сделать мидлвэром (адаптером по сути), для другого фреймворка еще как… это не столь важно.


                                                                                                                            А также использовали стандартные интерфейсы, а не велосипедные.

                                                                                                                            А как мне интегрироваться с велосипедными?)


                                                                                                                            не помешало бы иметь такие интерфейсы для меню и хк

                                                                                                                            уже года 3 не приходилось сталкиваться с задачей организации менюшек на бэкэнде. Но вообще в те времена пользовался этим: https://github.com/KnpLabs/KnpMenu


                                                                                                                            Оно не привязано ни к какому фреймворку и есть кучи интеграций.


                                                                                                                            Хотя не совсем понял, где прописаны у Вас сами правила валидации.

                                                                                                                            там папочка examples есть. И тесты.


                                                                                                                            Они как-то потом подключаются в зависимости от задач, заметил только проверку чтобы у некоторых запросов не было тела. :)

                                                                                                                            нет там такого. У каждого объекта запроса есть метод rules который предоставляет правила валидации и все.

                                                                                                                            • +1
                                                                                                                              >был против событий :)

                                                                                                                              Это вы фразу «много событий — плохо» пытаетесь перевернуть в «против событий»?)))))) В своем репертуаре, ложь и глупость)

                                                                                                                              >Вот увидите, скоро фреймворки это реализуют

                                                                                                                              Вот увидите — вы единственный такой дурной)

                                                                                                                              > все влезает в 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?!