В мире 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-сообществе, а не личному продвижению или обретению известности. Если мы раскроем имена — это лишь отвлечёт внимание от поднятых на сайте проблем. Давайте не будем отвлекаться.
Каков ваш опыт в разработке ПО?
Чтобы прийти к идеям, мыслям и решениям, отражённым на нашем сайте, не требуется большого опыта, если вы всегда делаете то, что говорят другие.
Рекомендуемая литература
- PHP: Неправильный путь — на Hacker News. Когда мы запустили наш сайт, на Hacker News появилось много комментариев, в которых отражено немало ценных аргументов.
- Как программировать без ООП. Свежая и альтернативная точка зрения: Брайан Уилл в трёх видео рассуждает о том, что не стоит начинать с ООП. В завершение он приводит несколько замечаний, как писать не ООП код.
- Кодеры за работой. Размышления о ремесле программирования. Интервью основаны почти на 80 часах бесед с 15 величайшими программистами и специалистами по информатике. Здесь вы найдёте многогранный рассказ о том, как они учились программировать, как они оттачивали своё мастерство и что они думают о будущем программирования.
- Черты квалифицированного программиста. Компетентность означает достаточное количество опыта и знаний для выполнения задачи. Квалифицированность — знание, почему вы делает что-то именно таким способом и как это укладывается в общую картину. Иными словами, квалифицированный практик всегда компетентный практик, но обратное необязательно верно.
- Руководства по безопасному программированию. Не зависящий от технологий документ с набором общих методик безопасного программирования в формате чек-листа, который можно внедрять в жизненный цикл разработки ПО. Используя эти методики, вы избежите большинства распространённых уязвимостей.
- Принципы безопасного проектирования. Безопасность веб-приложений — неотъемлемый компонент любого успешного проекта, будь то open source приложение, веб-сервис сквозной обработки или проприетарные бизнес-сайты. Хостеры совершенно справедливо остерегаются небезопасного кода, пользователи остерегаются небезопасных серверов. Задача этого руководства — помочь бизнесу, разработчикам, дизайнерам и архитекторам решений создавать безопасные веб-приложения. Если пользоваться им с самых ранних стадий, то стоимость создания безопасных приложений будет сравнима со стоимостью небезопасных, при этом в долгосрочной перспективе финансовая эффективность окажется несравнимо выше.
- Выживание на глубине: безопасность в PHP. Все жертвы успешных взломов быстро отмечают в пресс-релизах и на сайтах: безопасность для них крайне важна, и они относятся к ней со всей серьёзностью. Примите это близко к сердцу до того, как прочувствуете на практике.
- Улучшение существующей структуры кода с помощью рефакторинга . Рефакторинг позволяет улучшить имеющуюся структуру кода. Это изменение системы таким образом, чтобы внешнее поведение кода не менялось, но при этом внутренняя структура становилось более гармоничной. С помощью рефакторинга вы даже можете превратить плохую структуру в хорошую. В книге обсуждаются принципы рефакторинга, рассказывается, где его стоит применять в первую очередь и как настраивать нужные тесты. Также приведён каталог более чем из 40 проверенных рефакторингов с описанием, когда и зачем их применять, и пошаговые инструкции по внедрению. Заодно иллюстрируются схемы работы рефакторингов. Книга написана на примере Java, но её идеи применимы в любом другом ОО-языке.
- Практика программирования. Сборник практических вопросов, актуальных для программистов.
- Прагматичный программист. Здесь исследуются ключевые процессы программирования, от подмастерья до мастера: выработка требований, выполнение работ, правильное сопровождение кода. Рассматриваются самые разные вопросы, начиная с личной ответственности и развития карьеры и заканчивая методикой разработки архитектуры ради сохранения гибкости, простоты адаптации и многократного использования кода.
- Понимание языков программирования. Выбор языка программирования — один из важнейших факторов, влияющих на общее качество программной системы. К сожалению, слишком многим программистам не хватает лингвистических навыков: они влюбляются в свой «нативный» язык и не способны критически анализировать его ограничения. Книга «Понимание языков программирования» написана, чтобы объяснить:
- какие альтернативы доступны разработчикам,
- какие языковые конструкции лучше использовать для повышения безопасности и читабельности,
- как эти конструкции реализованы и как их можно эффективно компилировать,
- какова роль языка в выражении и усилении абстракций.
Комментарии (272)
mxms
30.08.2016 17:02-12В яблочко! Особенно про фреймворки которые используют где ни попадя и часто без нужды.
Кстати, это не только в PHP. Типичнейший пример использования той же тактики — jQuery в мире JavaScript.
DeLuxis
30.08.2016 18:20+2jQuery особенно нужен был в эпоху разного api в браузерах. Сейчас все немного устаканилось, но есть не реализованный функционал в одних и присутствие оного в других. Тут то и пригождаются такие библиотеки.
mxms
31.08.2016 00:10Я не спорю с его плюсами и, даже, полезностью. По к месту и времени, а не бездумно и почти везде.
В результате попадаются индивиды, которые оригинальный JS толком понимать перестают. Не говоря уже за скрытые за кодом принципы и суть реализуемых процессов.
merlin-vrn
31.08.2016 09:51+5jQuery удобен. Просто, писать что-то вроде $("#id") короче, чем document.getElementByID('id'), а $("#id .x") вообще коротко уже и не скажешь.
Хотя, конечно, мелкие вставки (для которых Javascript вообще-то и предназначается) легко пишутся без обвесок.
Acuna
30.08.2016 22:31+4Самое простое доказательство важности использования jQuery — уменьшение количества кода в три (!) раза и даже более при аналогичном функционале, и как следствие — экономия времени при его написании. Просто сложно это понять не попробовав это самому, ни так ли?
mxms
30.08.2016 22:35-4Ну с фреймворками код сокращается на порядок «при аналогичном функционале, и как следствие — экономия времени при его написании». Только смысл поста не в этом. «Просто сложно это понять не» подумав как следует.
Acuna
30.08.2016 22:46-1Я говорил конкретно о Вашем комментарии про jQuery, которую как и фреймворки «используют где ни попадя и часто без нужды». Нет, конечно, в ней может и не быть необходимости, согласен, однако если написать на JS требуется хоть даже одну строку, на JQuery даже эта строка будет короче и оптимальнее. Я не говорю и о том, что она имеет более оптимизированные и безопасные аналоги операторов, например $.typeof (), и т. п., которые крайне рекомендуется использовать взамен нативных.
mxms
31.08.2016 00:07+1Когда ради пары строк кода на JS тянут целую библиотеку, а это теперь почти повсеместно, это просто какой-то позор.
Acuna
31.08.2016 00:12А, ну тут я соглашусь. Только не стоит делать такие поспешные выводы, у нас во многих проектах до 60% функционала jQuery используется запросто! Сомневаюсь, что Вы каждый проект разбирали по косточкам и смотрели что и как в нем реализовано.
mxms
31.08.2016 00:17-4Недосуг мне. Но когда приходится подтирать сопли за кодерами, это везде и рядом, на самом деле.
Умножение сущностей без нужды это главный грех программиста.Acuna
31.08.2016 00:31Ну тут я солидарен) Highslide в этом смысле пошли по правильному пути: у них можно скачать с десяток разных версий с различным функционалом, и, как следствием, количеством кода. Правда для нее все-равно пришлось делать свой обвес для расширения функционала, зато благодаря этому на новых проектах не приходится кастомизировать ее с нуля, ибо из коробки она довольно бедна, как бы странно это бы ни звучало.
pudovMaxim
31.08.2016 10:54+1«Подтирать сопли» — это удаление всяких «эких новомодных наркоманских джэйкварей» и перепись проекта под голый js?
По мне так грех делать кривущие браузеры, которые уже четверть века никак не могут держаться единого стандарта и не желающих упростить жизнь программерам и взять функциональность jquery под свое крыло.mxms
31.08.2016 20:31Подтирание соплей, это оптимизация кода и устранение косяков, часто неочевидных, в реализации.
rockin
30.08.2016 23:58-2У тебя код уменьшился? Ок.
Что за эгоизм! Зато у клиента он увеличился ровно на загрузку jquery. Всей. Целиком.Включая те функции, что твое величество и не использовало.
Именно этот момент и является ключевым для нелюбви к сторонним компонентам. Для разработчика — это благо. Натыкал вызовов и всё работает. Но клиент тянет и основной код и этот, и тот, и третий, и четвёртый. Только потому что разработчику, видите ли, так удобно. Написать децл меньше кода, но затянуть кучу кода со стороны.Acuna
31.08.2016 00:06+2При нормально оптимизированном и правильно минифицированном коде, в частности при правильном подключении скриптов на странице, разница будет практически незаметна, уверяю Вас. Честно признаться, говорю о разрабах в общем, я и сам потрошу весь код, выкидывая из него ненужное и оставляя нужное мне. То же я сделал и с jQuery. Однако очевидно, что я использую его во многих проектах, и просто бессмысленно тратить время на написание кода на JS каждый раз заново, если однажды Вы уже писали его под свои нужды. В данном случае Вас можно поздравить: Вы написали свой фреймворк.
mxms
31.08.2016 00:15Браво. Вы почти меня поняли.
Теперь абстрагируйтесь от JS и поднимитесь на уровень выше. Мысль будет предельно понятной.Acuna
31.08.2016 00:24Да, я Вас понимаю полностью. Только я и говорю о том же jQuery как о просто удобной библиотеке для JS, которая избавляет от написания уже написанного ранее кода (извините за тавталогию), ибо просто нет смысла писать все для каждого проекта заново. То, что она разрослась в огромного монстра — я понимаю, поэтому все ненужное мне из нее выкинул, однако я по прежнему называю это свою поделку jQuery, так как базируется она на ней. Почему этого не могут сделать другие разрабы — вопрос не ко мне, я описал свой собственный опыт работы с ней, и то, что, собссно, изначально было ее основной миссией.
Source
31.08.2016 02:12+2А чем Вам Zepto не угодил? Отлично подходит для случаев, когда от jQuery нужен только основной функционал и не нужна поддержка старых браузеров.
holy_finger
01.09.2016 14:10В том, что когда нужна максимальный охват аудитории, Зепт откидывает всех кто не на современном браузере.
Source
01.09.2016 14:36Когда нужен максимальный охват, проще взять какой-нибудь jQuery 1.9.1 с CDN, и он с большой вероятностью в кеше браузера окажется даже при первом запросе.
holy_finger
01.09.2016 16:20Я сказал почему почему Зепта не подходит.
Как по мне, jQuery с головой хватает в 90% случаев. А проблемы якобы большого размера jQuery, это проблемы негров.
Acuna
02.09.2016 18:59Хм, благодарю, да, игрался с ним ради спортивного интереса, но для себя тогда не обнаружил необходимости в переходе на него, и плюс да, он действительно отметает старые браузеры, и как показывает исследование рынка пользователей браузеров — такой шаг был бы чистой воды эгоизмом. Однако с другой стороны в потрошении jQuery есть одно «но»: путь к обновлениям полностью отрезан, однако и кроссбраузерные версии до 2.1.1 уже не обновляются, а начиная с 3.0.0 новые браузеры она так же заворачивает.
А у него в чем суть, можно подключать только то что надо, или подгружает только используемые методы?
urvalla
31.08.2016 11:15+1А Вы с точки зрения экономики посмотрите: Вы как Мудрый Разработчик 1 ставите во главу угла уменьшение количества загружаемого клиентом кода и скорость работы бэкенда. Мудрый Разработчик 2 решает что лучше использовать больше бибилотек, но сократить время разработки (а значит, и стоимость).
Что получает Клиент 1, которому делал сайт Мудрый Разработчик 1: быструю загрузку страницы
Что получает Клиент 2, которому делал сайт Мудрый Разработчик 2: удешевление проекта и более быстрый старт
Чтобы упростить пример, решим что сайты зарабатывают рекламой.
Клиент 1 потртил больше средств, их нужно отбивать. И ставит больше рекламы на сайт. Которая дольше грузится.
Клиент 2 потратил меньше, и может себе позволить поставить рекламы поменьше. Кроме того, он запустился раньше — ему же сайт быстрее сделали.
В результате, посетитель сайта Клиента 1 доволен меньше: сайт долго грузится из-за рекламы, и на странице её визуально больше чем у Клиента 2.
Ясно, что пример простой. Смысл его в том, чтобы показать как вещи взаимосвязаны. Не нужно рассматривать «сферический код в ваакуме». Программисты делают продукт, который нужен бизнесу. И смысла экономить на спичках зачастую просто нет, по факту они выливаются в «медвежью услугу» и для заказчика и, даже, для пользователей.
Flammar
03.09.2016 12:28Интересный пример про то, как уменьшение объёма загружаемой JS-библиотеки приводит к увеличению объёма загружаемой страницы…
ingiboy
06.09.2016 11:32+1Содержание проекта по цене обычно не сопоставимо с его разработкой, и рисовать в лоб зависимость количества рекламы от бюджета разработки сайта я бы вот так лихо не стал. Рекламу навесят и на быстрый проект. и на медленный одинаково.
saboteur_kiev
06.09.2016 17:07Я бы не согласился. IMHO для бОльшей части проектов цена разработки сопоставима с ценой поддержки, если смотреть хотя бы на год работы.
Просто выбора обычно нет — нельзя же не поддерживать уже работающий продукт. А вот поддерживать И разрабатывать уже считай вдвое дороже.
Fesor
06.09.2016 17:38А вот поддерживать И разрабатывать уже считай вдвое дороже.
если не менять численность команды — выходит одинаково. У вас человекочасов не убывает и не увеличивается. Проект мэйнтейнится и развивается одновременно. Другое дело что если там все плохо под копотом то может так статья что у разработчиков внесение изменений будет выходить очень долгим. И в итоге на одну и ту же работу потребуется больше времени. Так же отсутствие тестов — постоянное регрессионное тестирование — увеличение стоимость QA и т.д.
Ну то есть не стоит говорить столь категорично. Я знаю команды где ребята фигачили ДО релиза и после примерно в одинаковом ритме. А так же знаю команды где после релиза пришлось увеличивать команду потому что ребята банально не успевали фичи пилить, слишком долго выходило.
ingiboy
06.09.2016 18:37+1Если смотреть на сайт только как на сайт, и под поддержкой иметь в виду только хостинг, правки и прочую мелочь — то да. Но если сайт это основа бизнеса (не сео, контекст и прочее порево), то его разработка и поддержка лишь часть постоянных и переменных расходов. И уж точно бОльшее количество рекламы не появится там из-за его дороговизны. Количество рекламы вообще регулируется только количеством предложений и моральными/финансовыми ограничениями владельца)
saboteur_kiev
31.08.2016 16:38Для большинства сложных, но типичных задач, использование фреймворка означает, что в случае чего, можно найти другого программиста, который знает этот фреймворк, и он сможет сразу продолжать.
Если же каждый раз интернет-магазин будет пилиться с нуля, разобраться в миллионе интернет-магазинов, написанных уникально, будет слишком дорого.
sav1812
01.09.2016 00:39и он сможет сразу продолжать
Так не сможет же: всё равно потребуется время на то, чтобы «разобраться».
Если же каждый раз интернет-магазин будет пилиться с нуля, разобраться в миллионе интернет-магазинов, написанных уникально, будет слишком дорого.
Дорого для кого?
Для нового разработчика? Так ему за это платят.
Для владельца? Так это будет плата за его же ошибки, допущенные им в самом начале…
И потом, какая разница, «с нуля» ли будет «пилиться», или на какой-то платформе? Стоимость вхождения для нового разработчика всегда будет зависеть, в основном, от правильности постановки задачи и организации разработки на начальном этапе.saboteur_kiev
01.09.2016 01:20Времени потребуюется на порядок меньше.
Надо добавить новое вложенное меню — если ты знаешь фреймворк, то ты знаешь, что меню там делается именно вот так. Можно даже не искать по всему коду, как в нем это реализовано, а просто знать, что идем вон-туда.
Дорого для всех. Всегда все хотят платить меньше. С какой стати это ошибка владельца? Владелец обязан знать что такое фреймворки? Что такое движки? Вы совершенно не правы, если не хотите все это считать, хотя бы в теории.G-M-A-X
01.09.2016 20:58А разве на фреймворках есть из коробки «добавить новое вложенное меню»?
Zhuravljov
01.09.2016 22:54Где-то есть, где-то — нет.
В общем случае, всегда знаешь что искать как реализовано нужно в базовом шаблоне, туда и идёшь.
Основная идея в том, что зная инструментарий популярного фреймворка и владея практиками его использования, влиться в разработку на нём значительно проще, чем в разработку основанною на кастомном решении.G-M-A-X
02.09.2016 00:50Я просто думал, что они (мейнстримовые фреймворки) решают какие-то абстрактные надуманные задачи вместо реальных:
http://blog.kpitv.net/article/frameworks-1/
:^)
aktuba
02.09.2016 01:33Рассуждаете, будто знаете 2+ фреймворков, хотя по вашим комментам видно обратное — вечная ссылка на yii 1))
G-M-A-X
02.09.2016 14:10Так как часто аппелируют тем, что в статье только Yii 1, добавил абзац в статью:
Тем, кто скажет, что я работал/знаю только Yii, только Yii говно, а все остальные норм
Вообще-то упоминаются и другие…
На работе используется Yii 1.1. Так как он под рукой, то он «попал под раздачу». Указаны примеры, которые меня раздражают, к пунктам недостатков.
Целенаправленно проверять другие фреймворки лень. Как сказано выше, это не значит, что пункт не подходит к другим фреймворкам. Скоро (не знаю когда) добавится Laravel.
Желающие могут указать свои трудности, с которыми пришлось столкнутся. Они будут добавлены в статью.
Трудности добавляйте, дабы сделать сравнение фреймворков. Тут недавно была статья https://habrahabr.ru/post/305626/
Но это курам на смех.
Также в начале статьи есть подготавливающий первый абзац:
Статья написана прежде всего с позиции разработчика, который пишет код для себя. Никого не заставляю писать на самописи, не всем это подойдет.
aktuba
02.09.2016 15:39Блин, не хорошо кормить тролля, ну да ладно, сделаю исключение в этот раз…
Начнем с простого:
>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? Нету? Фиии… Нафига мне хлебные крошки, если нет элементарного?!
Ну, думаю, пока что хватит…G-M-A-X
02.09.2016 17:15У вас? Или у создателей фреймворков? А какое «правильное понимание 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 функциями.
Нафига мне хлебные крошки, если нет элементарного?!
Хлебные крошки нужны большему количеству :)aktuba
02.09.2016 18:00>Но предполагается что реализация и код сущности БД будет в одном файле/классе.
Уточнение — предполагается вами, а не фреймворком.
>Перейдите по ссылке на документацию…
Перешел. Почитал. И? Не вижу ни в документации, ни в коде запрета реализовывать иначе. А в документации вижу многократное употребление слова «может».
>Почему неудобно? У меня при вызове контроллера есть возможность указать, что его рендерить не нужно.
В большинстве случаев веб предполагает рендеринг.
В 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 функциями.
Большинству не нужны меню и хлебные крошки. Особенно второе ;). Покажете хлебные крошки на этой странице?)))G-M-A-X
02.09.2016 21:27Уточнение — предполагается вами, а не фреймворком.
Перечитайте еще раз ссылку на документацию.
На предыдущих работах так и было.
Не вижу ни в документации, ни в коде запрета реализовывать иначе.
А я говорил о запрете реализовать иначе? Я говорил о бестпрактис…
Через какое-то время появляется контроллер 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: неправильный путь :)aktuba
02.09.2016 21:52>На предыдущих работах так и было.
Сочувствую). Но тут зависит от программиста, фреймворк не принуждает ;)
>А при чем тут авторендеринг?
>Указывайте в вызове контроллера шаблон, который нужно подхватить.
И чем это отличается от вызова функции рендера?))))
>Я тоже за явность.
Тогда нафига авторендер?))
>Но во фреймворках неявности и магии побольше :)
Пруф? С теми фреймворками, с которыми я работал, магии практически не было ;)
>Меню и хлебные крошки сущности не архитектурные, а прикладные.
И нафига они тогда в фреймворке?)))
>А виджеты и контроллеры дублируют друг друга.
Серьезно?))) Если в вашей голове они друг-друга дублируют, это не означает, что вы правы ;). Я вам больше скажу — в некоторых фреймворках виджет может содержать контроллеры, модели, вьюхи. И даже работать с отдельной базой данных, например).
>Также это дублирование кода самого фреймворка.
Пруф?)))
>Туда поступает запрос и там решаем что делать.
>Этот контроллер может вызвать другой контроллер для обработки запроса.
Т.е., в вашем понимании, это часть приложения. Ок. Но тогда это у вас своеобразное понимание «своеобразное понимание МВЦ.»)). Для большинства разработчиков, index.php — это некий лоадер приложений (да-да, он может грузить разные ПРИЛОЖЕНИЯ, а не контроллеры — это бестпрактик ;)).
>Для меня модель — весь код, на который я опираюсь и вызываю.
И этот человек говорит о том, что у кого-то неправильное представление mvc… ха-ха-ха-ха… Получается, любая php-функция — это часть модели, верно? Вы же вызываете их и опираетесь на них? А значит у вас все приложение — одна большая модель?))))))))))
>Ну да, глобалы рулят :)
Ух как все запущено))). Я про глобалы не говорил и даже не вспомнил про них. Я больше про рефлексию, например).
>У меня большинство задач решается контроллерами и я не парюсь, взять стул, машину или кровать :)
>Я говорю, возьми и сделай.
Ну, в принципе, это видно. Как по комментариям, так и по коду ;). Но например я не готов ехать в другой город на стуле, спать на машине и т.д. И да, у вас не контроллерами решаются задачи, а как-раз виджетами. Контроллер у вас всегда один — index.php ;)
>И статику кто вызывает? Фреймворк. Значит деплоер должен подсунуть ему эту информацию.
Чего?!?! Фреймворк вызывает статику?! Или все-таки приложение? Таким темпом можно дойти до того, что статику вызывает операционка и все операционки = зло)))))))
>Но деплоеры используются на более сложных проектах (как и упомянутый выше gulp).
А на простых кешировать статику не имеет смысла. Хватит кеша в браузере + get-параметр.
>У меня поддержка на уровне ядра.
И это минус. Чтобы поправить хедер — мне править ядро? Бред…
>А любые сторонние «компоненты» будут выпадать из этого функционала.
Серьезно?)))))))))))))))))
>Допустим перевода на русский нету, тогда используем переводы в порядке наличия из языков фоллбеков: украинский, английский.
Ух какая сложная задача))) Lang::get($string); Остальное на уровне конфига)))))
>То есть Вы все таки будете дописывать ко всем файлам filemtime вместо деплоера? :)
Я? Нет конечно). Я отвечал на вашу задачу ;). Но, вы не показали, как это проще сделать на вашем фреймворке))))
>Я имею в виду какую задачу реализовывать.
Пофиг. Вывод данных из файла на страницу — подойдет? Обработку json/xml? Работу с бд? Без разницы, в общем.
>Меню? О, да.
Именно так. Меню — это дизайн+верстка, а не код. И меню нафиг не нужно в фреймворке. Не согласны? Покажите код, который сделает меню как на хабре, например. Или как на zolotorevich.com. Чего будет больше — кода или стилей?)
>Разработка > PHP: неправильный путь :)
Это заголовок поста. Не вижу в нем ссылки на индекс например). Или для вас любая ссылка со стрелкой — это хлебные крошки?)) aktuba.com — такой-же стиль заголовка, но в помине нет никаких хлебных крошек ;)
ghost404
03.09.2016 01:12Вклинюсь в обсуждение. На тему index.php, это не что ино как шаблон проектирования Front Controller.
@aktuba советую не увликатся холиваром. Макс не адекватен и осознавать этого не хочет. Не ты первый пытаешся направить его на путь истинный
aktuba
03.09.2016 11:28Не-не-не, я в курсе: https://habrahabr.ru/company/mailru/blog/308788/?reply_to=9786794#comment_9785022 ;)
Но пятница-же была, хотелось поразвлекаться и посмотреть на реакцию)
G-M-A-X
03.09.2016 15:25Сочувствую). Но тут зависит от программиста, фреймворк не принуждает ;)
Вот в первую очередь из-за дебилов у меня такое отношение к фреймворкам.
Говорят, фреймворк дисциплинирует, все пишите на фреймворках.
А нифига. Это только привело говнокодеров.
И чем это отличается от вызова функции рендера?))))
Но это не функция рендера.
Тогда нафига авторендер?))
Чтобы не заморачиваться рендерингом. :)
И нафига они тогда в фреймворке?)))
Чтобы все сторонние решения имели один интерфейс для добавления пунктов меню и хлебных крошек. А не как вздумается разработчику…
Потом налеплять говна и разбирайся с ним.
в некоторых фреймворках виджет может содержать контроллеры, модели, вьюхи.
На самом деле это лишняя сущность.
Выходит каша. Фиг поймешь, где что искать.
Пруф?)))
Зачем пруф? Это разве не ясно, что виджеты пятое колесо? А все из-за того что в неверном понимании MVC возможен вызов только одного контроллера.
Для большинства разработчиков, index.php — это некий лоадер приложений
Но по сути это контроллер.
Ведь туда поступает запрос.
Получается, любая php-функция — это часть модели, верно?
Это Вы слишком далеко копнули.
Именно так. Меню — это дизайн+верстка, а не код.
Я не о html+css, а интерфейсе для построения массива пунктов меню…
Ясен-красен, что каждый будет использовать свой шаблон :)
Это заголовок поста.
По сути это хлебные крошки, так как показывает иерархию.aktuba
04.09.2016 15:03>Чтобы все сторонние решения имели один интерфейс для добавления пунктов меню и хлебных крошек. А не как вздумается разработчику…
Которые нахрен никому не нужны)))
>На самом деле это лишняя сущность.
Не согласен. Лишняя сущность — это хлебные крошки, например. А виджеты — полезный инструмент.
>Выходит каша. Фиг поймешь, где что искать.
))))) Жесть…
>Зачем пруф? Это разве не ясно, что виджеты пятое колесо? А все из-за того что в неверном понимании 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кб ;)G-M-A-X
04.09.2016 17:07Ого ответили :)
>Которые нахрен никому не нужны)))
Ну ок. Будем велосипедить. Зачем тогда фреймворки? :)
Ответьте на 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 сложилось мнение, что это язык говнокодеров. Хотя на нем пишут и нормальные программисты.aktuba
04.09.2016 19:45+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.: на этом дискуссию закрываем. Выходные закончились)G-M-A-X
04.09.2016 23:10>Ну так вы и велосипедите ;).
А Вы нет? С тем же меню :)
>А фреймворки нужны чтобы уменьшать время на разработку, делать разработку удобнее и комфортнее.
Ну да. Только хотя бы не усложняли. :)
Это примерно как государство. Оно якобы призвано заботиться о людях, а по факту от него, наверное, больше проблем :)
>Наличие/отсутствие каких-либо фич не делает фреймворк лучше или хуже.
То есть все фреймворки одинаковы? Ведь все они дают возможность удобно подключать расширения.
>Если в вашем фреймворке я не могу использовать одновременно несколько баз данных
Можете, но построитель запросов расчитан на 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.: на этом дискуссию закрываем. Выходные закончились)
Ок, ответите как сможете :)
Вопрос, который меня больше всего беспокоит:
В каких-то случаях оправдано использовать самопись? Есть ли людям, использующим самопись, оправдание? :)aktuba
05.09.2016 00:30>А Вы нет? С тем же меню :)
Нет. Оно мне настолько редко нужно, что если вдруг понадобится — возьму что-то на гитхабе ;)
>Это примерно как государство. Оно якобы призвано заботиться о людях, а по факту от него, наверное, больше проблем :)
Ну то, что вы не осилили — не означает что они мудренные ;)
>То есть все фреймворки одинаковы?
Нет. Есть различия. Но суть у них настолько близка, что осилив один — проще понять другие ;)
>Ведь все они дают возможность удобно подключать расширения.
Нет. Ваш вот не дает. Так-же и многие другие. Но есть действительно удобные)
>Ну кому что нужно :)
Кому нужно — берут 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 свой фреймворк, хотя-бы раз в жизни написать свой блог, форум. Для саморазвития — да, возможно. Для реальной работы — нет, противопоказано.
Я сейчас работаю в проекте, в котором собственный фреймворк. И заменить уже не вариант. Это очень печально, пытаемся постепенно избавляться от легаси в пользу сторонних библиотек, дабы разгрузить основной код. Причина этого — человек не нашел в свое время удобный для себя фреймворк и написал свой. Сча ругаются все, включая автора фреймворка, т.к. проект стал большим, а фреймворк не был расчитан на подобное. ;)G-M-A-X
05.09.2016 11:24>Нет. Есть различия. Но суть у них настолько близка, что осилив один — проще понять другие ;)
Тогда осилив 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 данные. Это уже агрегированные.
>Да уже давно нет смысла писать то, что написано.
А мордокнига и ВК?
>Я сейчас работаю в проекте, в котором собственный фреймворк.
Я сторонник самописи, но работаю с фреймворками
Вы сторонник фреймворков, но работаете с самописью :)
Жизнь — боль. :)aktuba
05.09.2016 15:57+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.»
Вроде как четко написано, что таблицы все-равно блокируются на короткие интервалы. А значит имеем проблемы с производительностью. Потестирую на досуге, но мало верится, что здесь что-то полезное сделали.
>А мордокнига и ВК?
А что с ними?)) Думаете, они пишут абсолютно все с нуля?))))G-M-A-X
06.09.2016 00:26-1>А в чем у вас отличие от «фреймворков»?)
«фреймворк вызывает функции пользовательского кода» (https://ru.wikipedia.org/wiki/Фреймворк )
У меня более гибридная схема. Чаще я прошу сам, чтобы ядро выполнило какой-то мой код.
Контроллером/моделью/шаблоном может быть любой сторонний код, хотя пока я использую сам.
>Простой пример — получить все письма из почтового ящика за последний год по imap. Кода — строк 20-30, а вот ресурсоемкость огромная ;)
Задача процессор не тратит, это блокирующая операция с сетью.
Вечный цикл можно и в 3 строки написать. :)
>Нет, не достаточно. Для 1-5х методов — может быть, а для полноценного использования крупного апи — нет.
Я не люблю, когда много кода, который нужно поддерживать, который имеет потенциальные дыры, который нужно писать, который неизвестно как работает, который ничего полезного не делает.
>))) Видно, что далекая для вас тема))) Только за счет асинхронности обработки получается сильно снизить нагрузку, не говоря о других плюсах.
А, ну если вы там видео пережимаете, то да, не стоит заставлять пользователя ожидать, пока браузер загрузится :)
Но это было давно. Просто сейчас стало модным.
>Верно. Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.
Наследование боль. Нужно использовать события и грамотно их расставлять.
Такая же боль и при использовании фреймворка. :)
>Но всегда, когда их становится много — получается только вред. Как в плане поддержки и развития кода, так и в плане рефакторинга в будущем.
Их нужно тоже структурировать.
Если любого кода много, то с ним трудно работать. Поэтому я стараюсь писать меньше кода :)
>Т.е. для апи стандарта не надо
Так все апи разные.
Поэтому проще пользоваться универсальной оберткой.
>А зачем эта лишняя сущность?) Вы же против лишних сущностей, но я уже с десяток их насчитал ;)
Так Вы на каждый АПИ сервис предлагаете вводить сущность и реализацию один в один. :)
>А зачем эта лишняя сущность?
Модуль ядра — это не лишняя сущность. Это модуль (модель, компонент), который поставляет поставщик ядра.
>Весь код — нет конечно. Но частично — легко. Например, перевели кеш с файлов на редис — получили доп.функционал в качестве тегов. Почему не использовать? Да, переделываем кеширование.
Ну это если в начале разрабатывали без оглядки на теги.
На фреймворках, вроде, интерфейсы кешей предусматривают теги.
>Да что вы говорите))). Давно есть реплика в мемкеше?)))
Репликаций вроде нету.
Можете сами реплицировать :)
>А что с ними?)) Думаете, они пишут абсолютно все с нуля?))))
Я тоже все не пишу.
Но каркас-то они хоть пишут сами?
Да и ВК как бы без ООП.
Или там все на фреймворках у них? :)aktuba
06.09.2016 01:30>«фреймворк вызывает функции пользовательского кода» (https://ru.wikipedia.org/wiki/Фреймворк )
Вообще-то, это сказано про IoC (https://ru.wikipedia.org/wiki/Инверсия_управления) ;). «Фре?ймворк (иногда фреймво?рк; англицизм, неологизм от framework — каркас, структура) — программная платформа, определяющая структуру программной системы». Снова пытаетесь под себя перевернуть?)))))) У вас фреймворк (точнее — нано-фреймворк))).
>Задача процессор не тратит, это блокирующая операция с сетью.
Да вы что… ))))) Я этой задачей занимался на прошлой неделе ;). Попробуйте на досуге. Лучше сразу параллельно пользователей на 40 ;)
>Я не люблю, когда много кода, который нужно поддерживать, который имеет потенциальные дыры, который нужно писать, который неизвестно как работает, который ничего полезного не делает.
Не любите свой фреймворк?))))) Прямо описали ассоциации многих людей ;)
>А, ну если вы там видео пережимаете, то да, не стоит заставлять пользователя ожидать, пока браузер загрузится :)
Не, простая математика. Но много)
>Наследование боль. Нужно использовать события и грамотно их расставлять.
Странная у вас логика). Наследование — это удобно в большинстве случаев. События тоже удобны, пока их не много.
>Такая же боль и при использовании фреймворка. :)
Вашего? Верю). Мне фреймворки помогают, доставляя удовольствие от использования. Но да, если не можете изучить — будет больно)
>Их нужно тоже структурировать.
Их надо использовать только там, где они полезны. Пихать везде — раскидывать грабли себе же.
>Поэтому я стараюсь писать меньше кода :)
Это видно). Писали-бы побольше — поняли-бы плюсы фреймворков. А писать бложики на 10 страниц много кода не надо)
>Так Вы на каждый АПИ сервис предлагаете вводить сущность и реализацию один в один. :)
Где это я такое предлагал?))) Чёт наговариваете вы на меня)))
>Модуль ядра — это не лишняя сущность. Это модуль (модель, компонент), который поставляет поставщик ядра.
Ух-ты… Есть «ядро», «поставщик ядра», «модуль», «компонент»… И этот человек против виджетов!!! Ахахахаха…
>Ну это если в начале разрабатывали без оглядки на теги.
>На фреймворках, вроде, интерфейсы кешей предусматривают теги.
Это всего-лишь пример был).
>Мемкеш — распределенный.
>Репликаций вроде нету.
А в чем тогда выражается распределенность?! ))))))))))))))
>Можете сами реплицировать :)
Да ладно?! ВНИМАТЕЛЬНО СЛУШАЮ!!!
>Но каркас-то они хоть пишут сами?
С чего вы это решили?)))) Даже не так. Да, скорее всего что-то пишут сами. Потом используют в виде фреймворков, например так: https://github.com/facebook/FBMock ;)
>Да и ВК как бы без ООП.
И? Как это связано?)
>Или там все на фреймворках у них? :)
Скорее всего нет, я не знаю. Но точно уверен, что не на фреймворке на 50кб ;)G-M-A-X
06.09.2016 11:44>Вообще-то, это сказано про IoC
Видимо текст страницы поменялся, цитату скопировал давно.
Да и это не суть важно.
>Наследование — это удобно в большинстве случаев.
Вы же сами говорили о возможных проблемах наследования… :)
>Где это я такое предлагал?))) Чёт наговариваете вы на меня)))
Читайте свои комменты, а то скажете, что имели другое в виду, типа имели в виду, что мой «фреймворк» унылый.
Остальное лень комментить :)aktuba
06.09.2016 13:04>Да и это не суть важно.
Ну да, не важно, когда по ссылке сказано вопреки вашим словам)))
>Вы же сами говорили о возможных проблемах наследования… :)
Снова наговариваете))) Никогда подобного не говорил.
>Читайте свои комменты, а то скажете, что имели другое в виду, типа имели в виду, что мой «фреймворк» унылый.
Не поленился, перечитал — нет ничего подобного. Максимум что есть — вопрос к вам, в стиле «если пихаете в ядро всякий мусор наподобии меню и хлебных крошек, почему не пихаете всякие апи?». Я-же наоборот, раз 10 заявил, что ядро фреймворка должно быть минимальным, без всякого мусора. А для апи есть достаточно удобные обертки, например https://github.com/mpratt/Embera
В идеале, ядро = бутстрап-файл + composer.json.
>Остальное лень комментить :)
Не удивлен, но жаль — только разогрелся).G-M-A-X
06.09.2016 22:06>Снова наговариваете))) Никогда подобного не говорил.
me:
>Можно подписаться на событие… :)
you:
>Можно. А можно наследоваться и переделать реализацию.
me:
>Можно. Но некоторые тру-фреймоворкоюзатели говорят, что наследование — зло.
you:
>Т.е. править ядро. Спасибо, не надо)
me:
>Это Вы предлагали наследоваться, а не я править ядро…
you:
>Верно. Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.
me:
>Наследование боль. Такая же боль и при использовании фреймворка. :)
you:
>Странная у вас логика). Наследование — это удобно в большинстве случаев.
Вы по ходу переписки выдумываете выдумки.
>А для апи есть достаточно удобные обертки, например https://github.com/mpratt/Embera
По описанию это встраивалка видео :)aktuba
06.09.2016 22:29>Вы по ходу переписки выдумываете выдумки.
Перечитайте свою выжимку ;). Где я говорю что наследование — зло?) Скорее наоборот: «Если я наследуюсь и правлю в наследнике — это отлично». Говорю-же — наговариваете на ровном месте))))
Вы хоть перечитывайте что публикуете)))
>По описанию это встраивалка видео :)
Именно. Обертка над кучей апи в отдельной библиотеке.G-M-A-X
06.09.2016 22:32>Перечитайте свою выжимку
Вы выдумали, что с моим кодом у Вас будут проблемы с наследованием, а с фреймворком не будет.
Fesor Вы вроде против наследования? :)aktuba
06.09.2016 22:34>Вы выдумали, что с моим кодом у Вас будут проблемы с наследованием, а с фреймворком не будет.
Еще раз перечитайте ;). Я против правки ядра, а не против наследования. Даже написано чуть-ли не 1-в-1: «Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.».
Может хватит уже придумывать?)
Fesor
07.09.2016 01:22Вы вроде против наследования? :)
Наследование — инструмент. Я против использования наследования там, где оно не нужно.
В то же время вы полностью отвергаете разные "ненужные" SOLID и GRASP принципы, здравый смысл и т.д. оправдывая это личным вкусом.
index0h
07.09.2016 02:23@Fesor Вы пытаетесь спорить с программистом в 4-ой стадии))
G-M-A-X Вам тоже не помешает прочитать
G-M-A-X
07.09.2016 16:454 Я крутой программер, я написал уже несколько больших программ, я знаю все о программировании!!!
Наоборот :)
Я стараюсь работать с меньшим количеством кода, так как в голове все это трудно удержать :)
5. На этой стадии программист переосмысляет само понятия «программирование». Он начинает прислушиваться к другим программистам, обращать внимание на готовые решения, не изобретая велосипед по-новой, на первый план выходят скорость и качества реализации проекта, просматривая чужие листинги, он ищет не ошибки, а интересные идеи.
Я благодарен критике (наставлениям :) ).
Если бы все пользовались готовыми решениями и не изобретали велосипед, то до сих пор жили бы в каменном веке.
Вы считаете себя на какой стадии? :)index0h
07.09.2016 17:30Я стараюсь работать с меньшим количеством кода, так как в голове все это трудно удержать :)
Именно по этому и нужны эти все кучи абстракций.
Вы считаете себя на какой стадии? :)
на 5-ой
sav1812
08.09.2016 02:07Читать вообще полезно. Читать и думать. :)
И не только в своей профессиональной области, а и в других — для общего развития и расширения кругозора.
Вот и Ваш совет, и текст по ссылке, напомнили мне другие темы, которые, на мой взгляд, не мешало бы знать и автору этого текста, и ссылающимся на него:
— Проекция (психология)
— Перенос (психология)
Очень интересное и полезное чтение, рекомендую. :)
G-M-A-X
07.09.2016 16:29Каким же образом я отвергаю SOLID и GRASP?
О GRASP, кстати, впервые слышу :)
Я за здравый смысл.
Ну нету мне смысла тянуть фреймворк и все на него переписывать.Fesor
08.09.2016 09:55Каким же образом я отвергаю SOLID и GRASP?
лучше скажите в каком месте вы соблюдаете SOLID)
О GRASP, кстати, впервые слышу :)
Это проблема разработчиков. GRASP штука полезная, почитайте погуглите.
Я за здравый смысл.
здравый смысл мне подсказывает что я лучше поищу готовый вариант нежели буду писать все сам и потом поддерживать это дело. И фреймворки это как раз тот готовый вариант для типичных задач.
Ну нету мне смысла тянуть фреймворк и все на него переписывать.
Мне кажется у вас какая-то травма психологическая вокруг фреймворков.
G-M-A-X
08.09.2016 10:20здравый смысл мне подсказывает что я лучше поищу готовый вариант нежели буду писать все сам и потом поддерживать это дело.
Если У Вас остается 90%, то ок.
А у меня останется 10%. :)
Проще все выбросить и написать самому 50 кБ.
И фреймворки это как раз тот готовый вариант для типичных задач.
Фреймворки не совсем решают типичные задачи. Это скорее CMS.
aktuba
08.09.2016 12:59>А у меня останется 10%. :)
Так проблема именно в этом ;). Вместо того, чтобы использовать — переписываете)))G-M-A-X
08.09.2016 20:53-1Так проблема именно в этом ;). Вместо того, чтобы использовать — переписываете)))
У Вас есть еда, которая для Вас не вкусная / Вы не любите / плохо желудку?
Вы ее едите? :)
Да и я не переписываю, это если бы переписывал, пришлось бы выбросить 90%.
А так я написал всего 50 кБ. :)aktuba
08.09.2016 22:50+1Когда я впервые попробовал роллы — очень не понравилось, сейчас заказываю часто. Пиво не пил до 18 лет. И сейчас не сильно его люблю, но в компании устраивает.
Да, я ем «не вкусную» еду, если считаю, что могу ошибаться или просто не повезло с поваром ;).
А вот вы упорно едите асфальт, вместо того, чтобы попробовать что-то более правильное, в плане еды)
Про 50кб задал вопрос в другой ветке — жду ответа ;)G-M-A-X
09.09.2016 00:54Когда я впервые попробовал роллы — очень не понравилось
Попробуйте самопись, Вам понравится. :)
Кстати, тоже долго не пробовал суши, не то что я их не любил, просто не пробовал, как и много другой еды.
Да, я ем «не вкусную» еду, если считаю, что могу ошибаться или просто не повезло с поваром ;).
У вас просто выбора нет :)
Ну или Вы врете :)
А вот вы упорно едите асфальт, вместо того, чтобы попробовать что-то более правильное, в плане еды)
В реальности ем немного.
Также и в ИТ. Чтобы не растолстеть. :)
П.С.
Пользуюсь Windows XP, если не знаете :)
http://blog.kpitv.net/article/windows-xp/
Как Вам? :)
Fesor
08.09.2016 14:43Если У Вас остается 90%, то ок.
А у меня останется 10%. :)Чего от чего простите? Ну вот флоу. Мне нужно написать маленькую трейдинговую платформу. Функционал специфичный и потому готовых решенйи под это нет. Что я делаю:
беру симфони, беру доктрину. Накидывают бизнес сущности на plain php (без фреймворков), описываю как оно там между собой работает, с тестами например проверяю что все ок и начинаю лепить сверху уже инфраструктуру (мэппинги базы, схему потом мне доктрина сгенерит), разные сервисы по взаимодействию с внешними системами. Настрою swiftmailer что бы он мне почту через какой sendgrid/mailgun слал, роутинг, контроллеры, прикручу трансформеры на fractal что бы обезапасить себя от изменений в API в будущем и т.д.
При этом я не потратил ни минуты на решение каких-то стандартных задач вроде "отправка почты", только креды в настройках прописал. Или роутинг например. Или работа с базой данных.
Ну и да, у меня еще есть отдельные надстройки которые помогают экономить время. Например валидация данных запросов — https://github.com/fesor/request-objects — я его могу генерить из доки по API.
При этом всем все гибко просто и моя бизнес логика про фреймворк ничего не знает. А главное — мэйнтейнить такую систему будет проще.
Фреймворки не совсем решают типичные задачи. Это скорее CMS.
"не совсем решают" так себе характеристика. Типичные задачи для вас возможно отличаются для 95% других людей. Ну и "это скорее CMS" — это вы наверное все же про Yii.
G-M-A-X
08.09.2016 21:18При этом я не потратил ни минуты на решение каких-то стандартных задач вроде «отправка почты»
Я тоже такие вещи не переизобретаю, вроде не раз об этом говорил :)
Ну и да, у меня еще есть отдельные надстройки которые помогают экономить время. Например валидация данных запросов — https://github.com/fesor/request-objects — я его могу генерить из доки по API.
Вот и Вы написали свой велосипед. :)
Так и у меня есть такие надстройки, что мне даже фреймворк не нужен, и все влезает в 50 кБ… :)
На фреймворках есть плюсы, они гибкие. Но за гибкость нужно платить.
А также Вы использовали события в своем решении, aktuba был против событий :)
А также использовали стандартные интерфейсы, а не велосипедные. Вот я и говорю, что не помешало бы иметь такие интерфейсы для меню и хк. Вот увидите, скоро фреймворки это реализуют (а может и уже реализовали, но ни вы, ни я не в курсе :) )
Хотя не совсем понял, где прописаны у Вас сами правила валидации. Они как-то потом подключаются в зависимости от задач, заметил только проверку чтобы у некоторых запросов не было тела. :)
Ну и «это скорее CMS» — это вы наверное все же про Yii.
Хм, Yii никак не CMS.
Он решает ровно на том же уровне, что и остальные фреймворки.
Он более монолитный, что имеет свои плюсы и минусы, хотя туда можно тянуть любые компоненты.Fesor
08.09.2016 21:52Он решает ровно на том же уровне, что и остальные фреймворки.
Напомните с какими фреймворками вы работали плотно?
Вот и Вы написали свой велосипед. :)
я портировал идею из laravel и spring под symfony. Если у меня дойдут руки переделать это дело под PSR-7 и отвязаться от symfony/validation — то как бы оно не будет привязано к фреймворку.
На фреймворках есть плюсы, они гибкие. Но за гибкость нужно платить.
Гибкость = избыточность и так было всегда. Меня избыточность фреймворков полностью устраивает потому как это сокращает время разработки моих задач.
А также Вы использовали события в своем решении
Симфони по другому не позволяет вклиниться в пайплайн обработки запросов. По сути это часть интграции с фрейморком, сама же либка не завязана на них. Для laravel это можно сделать мидлвэром (адаптером по сути), для другого фреймворка еще как… это не столь важно.
А также использовали стандартные интерфейсы, а не велосипедные.
А как мне интегрироваться с велосипедными?)
не помешало бы иметь такие интерфейсы для меню и хк
уже года 3 не приходилось сталкиваться с задачей организации менюшек на бэкэнде. Но вообще в те времена пользовался этим: https://github.com/KnpLabs/KnpMenu
Оно не привязано ни к какому фреймворку и есть кучи интеграций.
Хотя не совсем понял, где прописаны у Вас сами правила валидации.
там папочка examples есть. И тесты.
Они как-то потом подключаются в зависимости от задач, заметил только проверку чтобы у некоторых запросов не было тела. :)
нет там такого. У каждого объекта запроса есть метод
rulesкоторый предоставляет правила валидации и все.
aktuba
08.09.2016 22:36+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?!G-M-A-X
09.09.2016 00:43Это вы фразу «много событий — плохо» пытаетесь перевернуть в «против событий»?)))))) В своем репертуаре, ложь и глупость)
Мотаю треды:
И этот вариант будет проще поддерживать и отлаживать, чем вариант с событиями. Не говоря уже о том, что события иногда вообще вредны.
Правда?!)))) Прямо слеза навернулась… Реализовали проект на событиях, через полгода начали выносить подпроекты в микросервисы — сколько сказочного можно поймать из-за использования событий — не представляете))))
Но всегда, когда их становится много — получается только вред. Как в плане поддержки и развития кода
Вы же имели в виду о глупых событиях в моем коде, правильно? :)
Любой код, если его много, сложно поддерживать.
Собственно поэтому у меня и свое ядро на 50 кБ… :)
Откуда так много?!
О, Вы среагировали, что можно и меньше. :)
Если Вы такой мастер, то почему не создали свой Симфони с блекджеком и шлюхами? :)
Вам хватит для этого 64 кБ?
Router (0,3-1кб)
У меня его вообще нету. Шах и мат! :)
без наследования
Явного наследования типа extends нету, но есть минимум 2 способа «наследовать», то есть иметь/изменять т. н. родителя.
хотя вряд-ли столько у вас наберется, 12-13кб
Это Вы считали, сколько бы вышло у Вас?
А то как-то тупо приписывать кому-то свою глупость. :)
Хотя да, есть куда улучшаться, об этом написано в бложике :)
КАК ВЫ УМУДРИЛИСЬ 50кб набрать на микрофреймворке, который ничего не умеет, кроме crud?!
Сколько там занимает crud у Доктрины? :)aktuba
09.09.2016 01:24+1>Мотаю треды:
Надо не только «мотать», но еще и читать ;)
>Вы же имели в виду о глупых событиях в моем коде, правильно? :)
Эмм… Откуда такой вывод?)) Вы решили, что я у вас код украл и тайком посмотрел? Вы-же его никому не показываете)))) Я говорил в общем ;)
>О, Вы среагировали, что можно и меньше. :)
Можно и в пару сотен байт уложиться ;)
>Если Вы такой мастер, то почему не создали свой Симфони с блекджеком и шлюхами? :)
Зачем?! Какой смысл распылять силы?)))) Я пользуюсь 3-4я фреймворками, в зависимости от задачи. Но да, когда-то был глупый и писал свои)
>Вам хватит для этого 64 кБ?
Хватит пары килобайт ;). Максимум.
>У меня его вообще нету. Шах и мат! :)
Еще один минус)
>Это Вы считали, сколько бы вышло у Вас?
Не, это я насчитал примерный вес фреймворка без плюшек. Ну и прибавил ваши бредовые меню и крошки.
>А то как-то тупо приписывать кому-то свою глупость. :)
До вас начало доходить? Это прогресс, поздравляю!
>Сколько там занимает crud у Доктрины? :)
2 235 882 Б (3 МБ на диске), объектов: 407. С комментариями. И это вся ORM ;) Я ею не пользуюсь, но на 100% уверен, что она умеет во много раз больше вашего.
Стало тут интересно, сколько весят нормальные фреймворки (до этого никогда не интересовался):
lumen: 135кб
kohana 3.3: 82кб
phppixie: 51 526 Б (думаю, даже он будет помощнее вашего ;)
f3: 16 499 Б
Так-что совсем не понятно, что можно было такого написать на 50кб. Для примера f3: поддержка роутинга, sql/mongodb, довольно приличный шаблонизатор, плагины… и всего 16кб. Так что вы там такого написали на 50кб? Меню на 20кб и хлебные крошки на 30?))))))))))))))))))))))G-M-A-X
09.09.2016 10:42Эмм… Откуда такой вывод?)) Вы решили, что я у вас код украл и тайком посмотрел? Вы-же его никому не показываете)))) Я говорил в общем ;)
Так Вы все время что-то о моем коде выдумываете, хотя бы тот же размер.
Так-что совсем не понятно, что можно было такого написать на 50кб.
У меня более монолитное ядро.
Оттуда легко можно выбросить кеширование, mysql, memcached, авторизацию, комментарии! (они нужны всем моим сайтам, поэтому они пока в ядре :)), меню, хк, легаси контроллеры, защиту от csrf, 304 ответ, возможность поменять вывод, расположенный выше, кодом, расположенным ниже, добавление ресурсов (+защита от повторной вставки ресурсов, добавление признака изменения ресурса), показ асоциальных кнопок!, встроенная защита, чтобы в админке не было лишнего кода (счетчиков), «поддержка» mysql_* функций в php7, и других удаленных, определения языка/страны по запросу, многоязычность, при желании можно выбросить загрузчик и конфигов, упрощение дебага, авторендеринг шаблонов, некоторый другой мусор и легаси вещи.
Осталось 4кБ: автолоадер, события, MVC. То есть осталось голое ядро.
Зачем мне тянуть мусор, если можно реализовать все самому под себя (так как реализация фреймворков меня не устраивает). Проще нарастить мускулы этому ядру, а не подпирать костылями фреймворк и разбираться с его особенностями.
Кстати, зачем f3 имеет pingback? :)
Да и размеры на гитхабе побольше, даже если не считать «демо» информацию.Fesor
09.09.2016 11:02экий список велосипедов. Позвольте спросить как вы организуете защиту от XSS? Экранирование везде и всюду или же "фильтровать входные данные"? Если у вас используется mysql_* функции — как защищаетесь от sql инъекций?
Помниться собеседовал чувачка, он тоже с другом "ядро" написал, и там все это решалось "тихим" выпиливаем "лишних" символов. То есть по какой-то причине я не могу использовать пароль с кавычками в его системе.
G-M-A-X
09.09.2016 11:27Позвольте спросить как вы организуете защиту от XSS? Экранирование везде и всюду или же «фильтровать входные данные»?
Описал тут:
http://blog.kpitv.net/article/об-автопреобразовании-спецсимволов-в-html-сущности-15412/
Кратко:
Зависит от ситуации, но нужно иметь в виду, что «экранирование» не панацея, а также оно может быть неуместным.
Если у вас используется mysql_* функции
Это обертки, так как в php7 их удалили.
как защищаетесь от sql инъекций
Даже в нативных mysql_* ф-ях можно защититься от sql инъекций экранированием.
mysqli_* экранирование.
Подготовленные выражения не рассматриваю.
Эмулированные подготовленные выражения == экранирование, а большинство такие и использует (так как это настройка по умолчанию), а также они быстрее.
Помниться собеседовал чувачка, он тоже с другом «ядро» написал, и там все это решалось «тихим» выпиливаем «лишних» символов. То есть по какой-то причине я не могу использовать пароль с кавычками в его системе.
Всякое бывает :)
Меня тоже очень бесит, когда в ИБ (некоторых других важных сайтах) используются надуманные ограничения на пароли. Потом попробуй запомни этот пароль.
А также пароли стоило бы хранить с посоленными хешами.
Многие, даже раскрученные ресурсы, допускают эту багофичу.
А также бесит, когда срабатывает автозащита, и ты не можешь отправить кусок кода. :)
aktuba
09.09.2016 13:15>Осталось 4кБ: автолоадер, события, MVC. То есть осталось голое ядро.
Что-то похожее на реальность. Правла все-равно как-то много. Автолоадер точно можно перекинуть в composer.
>Зачем мне тянуть мусор, если можно реализовать все самому под себя
Так вы и тянете мусор))))))
>Проще нарастить мускулы этому ядру, а не подпирать костылями фреймворк
А правильнее все «мускулы» оформлять отдельными пакетами и использовать только по необходимости ;)
>Кстати, зачем f3 имеет pingback? :)
Без понятия, не пользуюсь ;)
>Да и размеры на гитхабе побольше, даже если не считать «демо» информацию.
Так вы смотрите только код, без документаций и примеров ;)G-M-A-X
09.09.2016 14:20Автолоадер точно можно перекинуть в composer.
Можно, но я не совсем давно только переехал на ВДС, и то по причине того, что хостер выгнал из-за абуз :)
Так вы и тянете мусор))))))
Не выдумывайте. Или Вы вообще код не пишете?
А правильнее все «мускулы» оформлять отдельными пакетами и использовать только по необходимости ;)
В теперешних 50 кБ действительно много лишнего, я этого не скрываю.
Так вы смотрите только код, без документаций и примеров ;)
Так я так и смотрел.
Fesor
09.09.2016 01:59Любой код, если его много, сложно поддерживать.
Именно. И фишка фреймворка в том что вам не нужно его поддерживать самостоятельно. Для этого у этого фреймворка огромное комьюнити. И именно в этом профит. Чем больше людей юзают тулзу — тем надежнее оно с точки зрения поддержки.
У меня его вообще нету. Шах и мат! :)
да да, как в 2008-ом, .htaccess и реврайты. А как весело это все тестировать, просто сказка.
Если Вы такой мастер, то почему не создали свой Симфони с блекджеком и шлюхами? :)
Если бы мне отвечать на этот вопрос, то просто потому что я ленивый. Мне в симфони что-то не нравится — я это не юзаю и юзаю какой-нибудь другой компонент. Для запросов мне понравилось в laravel но не понравилось то что слишком много обязанностей — написал простенькую либу которая упростила мне жизнь уже не на одном проекте. И да, это делалось не от балды а как общее решение команды и реакция на проблему которая у нас вставала каждый божий день.
Явного наследования типа extends нету, но есть минимум 2 способа «наследовать», то есть иметь/изменять т. н. родителя.
То есть… неявное наследование? Или все же композиция/декорация? При последнем у вас таки явное наследование есть (implements), только так можно с подтипами играться.
Сколько там занимает crud у Доктрины? :)
0 байт. Там нет "круда". Там есть DBAL и ORM + еще библиотеки для кешироваия и вообще весь проект доктрины ориентируется на persistence layer в любой его ипастаси.
Ну и справедливости ради — ORM-ка там шикарная, для ОО-first решений и прототипирования приложений со сложной логикой (что бы накидать быстро модель предметной области а базу — ее можно сгенерить).
G-M-A-X
09.09.2016 11:08Именно. И фишка фреймворка в том что вам не нужно его поддерживать самостоятельно.
Но у меня мало кода. :)
Разговор был больше о коде приложения, а не ядра/фреймворка, типа предыдущему оратору сложно разбираться в событиях, когда и много.
да да, как в 2008-ом, .htaccess и реврайты.
А потом получаем примерно такое https://habrahabr.ru/post/309436/ с единой точкой входа в конфиге по умолчанию :)
Если бы мне отвечать на этот вопрос, то просто потому что я ленивый.
Я тоже ленивый. :)
Мне в симфони что-то не нравится — я это не юзаю и юзаю какой-нибудь другой компонент.
Мне не нравится ядро фреймворка. :)
Если вамнравится, то используйте, я ж никому не запрещаю. И в который раз повторяю, что говорю прежде всего как разработчик, пищущий код для себя.
Написал свое в 4кБ и нарастил функционалом, которого нет на фреймворках.
Кто-то использует скомпилированные либы, кто-то компилит с нужными настройками, кто-то вносит патчи.
Кто-то использует панель управления для сервера, кто-то управляет из консоли.
В каждом подходе есть плюсы и минусы. Больше плюсов — используем, больше минусов — не используем.
При декорации у вас таки явное наследование есть (implements)
Вообще-то декорация кода не требует implements (интерфейса?). Достаточно __cal().
Как Вы видите в «наследовании» шаблонов композицию/декорацию?
Как бы можно сказать, что, шаблон экшена контроллера наследует шаблон основного макета.
Ну и справедливости ради — ORM
Я не люблю эту абстракцию :) Оно может иногда и удобно (по работе), но можно решать задачи и другими способами. Не стоит все пытаться реализовать с максимальной приближенностью к реальности (как тут: https://habrahabr.ru/company/jugru/blog/308914/ )
Fesor
09.09.2016 11:33Но у меня мало кода. :)
это не отменяет того что вам нужно постоянно искать/фиксить баги и дыры в безопасности. А так за вас это комьюнити делает (ну и вы помогаете чуть-чуть)
Разговор был больше о коде приложения, а не ядра/фреймворка, типа предыдущему оратору сложно разбираться в событиях, когда и много.
По поводу событий… На событиях можно легко сделать очень плохо. Есть варианты при которых это все красиво но надо знать что делать и когда. В целом желательно их не использовать но ивенты резко понижают связанность системы, потому иногда это профитно. Главное понимать плюсы и минусы. В большинстве же случаев люди фигачат где не надо хуки аля вордпресс и потом завязывают логику на них и потом это становится неявным адом.
ивенты между компонентами — норм. Ивенты для системных вещей — норм. А вот ивенты в пределах модуля вместо явных вызовов методов — не норм.
Мне не нравится ядро фреймворка. :)
что такое "ядро фреймворка"? У симфони вон есть http-kernel (самое близкое по значению слова к ядру) но как бы… это не совсем "ядро", это точка входа. Оно не умеет ничего кроме как выстраивать пайплайн обработки http запросов. Например оно ничего не знает о маршрутизации и т.д. О контроллерах не очень знает. И вы можете вокруг делать что вздумается.
Кто-то использует панель управления для сервера, кто-то управляет из консоли.
Не передергивайте. Мы обсуждаем вполне конкретные вещи а не абстрактную чушь. Ваш пример тут не подходит. Это звучит как "кто-то использует по суитации а мне просто велосипеды нравятся".
В каждом подходе есть плюсы и минусы.
ваш подход хорош только на этапе обучения, в коммерческих проектах минусы слихвой перекрывают плюсы.
Вообще-то декорация кода не требует implements (интерфейса?). Достаточно __cal().
при таком раскладе вся иерархия типов летит лесом.
Как Вы видите в «наследовании» шаблонов композицию/декорацию?
принцип open/close. Добавить поведение не меняя код. И без наследования.
Как бы можно сказать, что, шаблон экшена контроллера наследует шаблон основного макета.
Это наследование в шаблонах, реализуемое руками. И его можно заменить композицией шаблонов.
Я не люблю эту абстракцию :)
есть DAO, table gateway если вам нравится работать с табличками и рядами. Мне вот нравится строить логику предметной области нормально, но да, на сайтиках и бложиках это не нужно.
G-M-A-X
09.09.2016 14:15это не отменяет того что вам нужно постоянно искать/фиксить баги и дыры в безопасности. А так за вас это комьюнити делает (ну и вы помогаете чуть-чуть)
Это не панацея, дыр всегда можно наделать в своем коде, особенно думая, что фреймворк защищает.
А также куча дыр в том же ВП и Джумла, они ж вроде опенсорс.
А также факт использования общеизвестной системы делает убирает Security through obscurity.
В большинстве же случаев люди фигачат где не надо хуки аля вордпресс и потом завязывают логику на них и потом это становится неявным адом.
А вот ивенты в пределах модуля вместо явных вызовов методов — не норм.
Это крайность, в которую впадать не стоит. :)
что такое «ядро фреймворка»?
Ответ:
То, без чего или с другой реализацией чего, по сути это уже другой фреймворк, как Ларавел и Симфони.
То, что задает тон использования.
Это звучит как «кто-то использует по суитации а мне просто велосипеды нравятся».
У меня нету велосипедов.
С таким успехом любой написанный код можно назвать велосипедом. Типа, берите и пользуйтесь вк/фб как своим сайтом :)
Я не против библиотек.
ваш подход хорош только на этапе обучения, в коммерческих проектах минусы слихвой перекрывают плюсы.
Возможно это парабола? :)
при таком раскладе вся иерархия типов летит лесом.
Так меньше программировать. :)
У нас так на работе сделано :)
принцип open/close. Добавить поведение не меняя код. И без наследования.
Код не меняется. В случае с шаблоном добавляется кусок html.
Я имел в виду, как наследование шаблонов реализуется с пощью композиции/декорации.
есть DAO, table gateway
Мне все абстракции не нравятся :)
Мне нравится быть ближе к уровню БД. Передал параметры, а построитель запросов все построил. Во фреймворках построители запросов немного запутывающие с лишним специфичным функционалом. Хотя я уже нашел, что в них можно делать то, что нужно.
Я говорю о ф-ях типа orWhere/andWhere, find/findAll/findByPK/findAllByPk.
К примеру в jquery для ajax лучше использовать $.ajax вместо $.(get|post)
Вы что используете? :)
G-M-A-X
09.09.2016 11:12Пропустил.
А как весело это все тестировать, просто сказка.
http://blog.kpitv.net/article/почему-я-не-использую-тесты-кода-15338/ (основной посыл сказан, как всегда, в юрле :) )
Но рассматриваю тестирование API.
Как всегда сноска: говорю прежде всего о личном кодеFesor
09.09.2016 11:38- тесты нужно писать до кода как процесс формализации того что вы хотите сделать. Это не долго
- тесты не должны часто меняться если у вас не меняется функционал. Если вы рефакторите код приложения — тесты не меняются. Поддерживать их легко.
- для юнит тестов не нужно. Для функциональных — докер, все легко и изолируемо.
- просто нужно уметь тесты писать. А для этого их нужно писать.
- задача тестов — гарантировать что вы не сломали из того что знали. Баги будут всегда потому что мы не в состоянии покрыть все возможные тестовые сценарии, слишком дорого.
- Тесты нужны не для того что бы "писать качественный код" а что бы "в любой момент времени я могу без страха поправить в любом месте и узнать сломалось чего или нет". Без постоянного рефакторинга (не когда переписываешь все а по чуть чуть, например узнал что "эта штука называется по другому" — поменял), ваш код как бы вы не старались превратится в кашу. Все будет хорошо только на очень простых проектах.
- А вот это уже правда. Вы не пишите тестов потому что не писали и не умеете. А все остальное — отговорки которые вы себе придумали.
Да и тестирование не всегда подразумевает "автоматическое". Руками ж тоже надо как-то проверять. И дебажить.
G-M-A-X
09.09.2016 12:511. Как правило, я функционал реализую не сразу целиком, а в процессе, есть разбитие на уровни. Я не могу заранее знать, как будет работать тот или иной нижележащий (или выше, смотря как смотреть) уровень, которого еще нету. Написал чуток кода, проверил как он работает. А не написал весь тест сразу.
И видение как все должно работать может меняться. Тесты легче написать, когда есть четкие требования, когда тебе пришла четкая изолированная задача, типа тебе нужно реализовать такое-то API. А то в процессе кодинга чего-то без жестких требований API 100 раз может поменяться :) Вряд ли стоит тест писать полностью сразу без написания кода. Лучше писать итерациями. А также, учитывая тот факт, что тесты прежде всего являются индикатором поломок кода при изменениях, то скорее всего лучше их писать после кода или итерациями.
2. Имел в виду поддержку, если меняется функционал. И больше не новый функционал, а изменения и фикс старого. А так, да.
3. Я больше о БД. А также, чтобы тестовая база имела все связанные данные, нужные для фикса багов (это не совсем относится к тестам).
4. Баги допускают все. Если мы допустили «баг» в тесте (постановке задачи), то скорее допутим его в
коде.
5. Поэтому все не нужно покрывать. В большинстве случаев достаточно сделать высокоуровневый тест (API).
Если изменился функционал, то упадет и тест, но это не означает, что есть баг. А править тест приходится.
6. Если править «качественно», то вероятность ошибок меньше. Рефакторинг нужен. Свой код постоянно рефакторю. На работе только во время решения задачи, чтобы она удобней ложилась. На рефакторинг нету времени, а жаль.
7. Я даже настаиваю, чтобы на работе их ввели, а то порой поправишь в одном месте, а потом из-за этого через некоторое время всплывает баг, казалось бы в совсем не связанном месте. :)
Говорить совсем, что тестов нету, тоже не правильно. :)
Ведь нужно проверять, как работает тот или иной метод и дорабатывать его, пока он не заработает как следует.
Да, это скорее ручные тесты, потом поправлю заголовок, если не забуду. :)
Просто не всегда оправдано тест писать отдельно. Тестировать можно и самим кодом (АПИ тесты). Только для некоторого кода нужны юнит-тесты.
Тесты иметь удобно, но еще удобнее, когда их пишет кто-то другой :)G-M-A-X
09.09.2016 12:57Не успел отредактировать:
3+. Просто некоторые тесты стоило бы выполнять вместе. Есть возможность запустить групповой тест, состоящий из нескольких в том же phpunit? Или это нужно руками?
Хотя тесты API можно и руками написать :)
Кстати, у меня есть парочка запросов, которыми я проверяю важные части, пока вручную.
П.С.
Добавил Ваш ответ в бложик :)
Fesor
06.09.2016 02:11+1Да и ВК как бы без ООП.
потому что начанался вконтактик на бодреньком процедурном коде. Это не говорит о том что "вконтактики" лучше знают как что писать. Просто им ресурсов это все поддерживать хватает.
Вон фэйсбуки свой PHP запилили, с нормальной объектной моделью, сносной системой типов и т.д. А по поводу "фреймворков" — юзают в основном на фронтэнде. На бэкэнде у них… ну можно сказать свои фреймворки которые они в опенсурс выкладывают.
Да и брать в пример продукты с такими нагрузками в принципе нет никакого смысла. У них там микросервисы, огромные ресурсы и инфраструктура. А у вас бложик.
G-M-A-X
06.09.2016 22:29Коммент пропал. :(
>вконтактик, фэйсбуки
Даже Цукенберг признал, что ВК в США работает быстрее ФБ.
C — тоже без ООП.
>А по поводу «фреймворков» — юзают в основном на фронтэнде.
Фронт — это другое государство. :)
>На бэкэнде у них… ну можно сказать свои фреймворки которые они в опенсурс выкладывают.
Так все фреймворки проходят стадию самописи.
Но их авторам тоже говорят: Вась, брось, возьми фреймворк А или Б. У них сообщество, тесты, все такое. :)
>Да и брать в пример продукты с такими нагрузками в принципе нет никакого смысла.
Это были козыри. Я проверял, нужно ли такие сайты писать на Симфони. :)
>А у вас бложик.
Та бложик это для себя и для лулзов :) Бложик появился совсем недавно.Fesor
07.09.2016 01:33+1Даже Цукенберг признал, что ВК в США работает быстрее ФБ.
Если для вас важна скорость — просто берите Go или Rust. PHP не для этого — он для уменьшения стоимости разработки под WEB.
C — тоже без ООП.
Си появился примерно в тот же период, что придумали саму концепцию ООП. Да и потом, то что в Си нет "классов" — там есть структуры, там можно добиться инкапсуляции (причем лучше чем в плюсах), там все хорошо с полиморфизмом (драйвера — хороший пример), там все… ну так себе с наследованием но на структурах это можно сделать и многие даже делают.
ООП — это в первую очередь управление связанностью и зависимостями. А все остальное — оно не только про ООП.
Фронт — это другое государство. :)
У меня выходит двойное гражданство.
Так все фреймворки проходят стадию самописи.
Вот только в отличии от вас у этих "самописей" авторы поопытнее будут.
Но их авторам тоже говорят: Вась, брось, возьми фреймворк А или Б. У них сообщество, тесты, все такое. :)
Вот смотрите. Я использую Symfony уже 5 лет. И мне он честно сказать жмет. Потому свои проекты я пилю на ооочень адаптированном под себя symfony. По сути это мой фреймворк который на 90% состоит из отдельных компонентов которые мне лень писать самому. Я проходил этап написания своих фреймворков лет так 7 назад, уже не интересно.
Это были козыри. Я проверял, нужно ли такие сайты писать на Симфони. :)
Знаю ребяток которые пилят сайтики на 50 миллионов пользователей на симфони и они довольны. blablacar например. А когда у вас миллиард пользователей — чуть другие заботы появляются нежели фреймворки или языки программирования.
К примеру и фэйсбук и вконтактикам пришлось реализовать свои базы данных для того что бы решить проблемы репликаций в реалтайме и т.д. Ну то есть банально когда у вас несколько датацентров — вам можно делать все что угодно.
p.s. фреймворки от фэйсбука мне не нравятся. Решения от вконтактика — бесполезны поскольку они ориентированы исключительно на вконтактик.
G-M-A-X
07.09.2016 17:59Если для вас важна скорость — просто берите Go или Rust.
У меня не такие большие нагрузки, чтобы оправдано было переписывать.
Потом, вряд ли у них сейчас более развита инфраструктура, чем в PHP.
И у них типизация «статическая, строгая».
«По большому счёту, Go является процедурным языком с поддержкой интерфейсов.»
(https://ru.wikipedia.org/wiki/Go )
ООП-шники негодуют :)
PHP не для этого — он для уменьшения стоимости разработки под WEB.
Но PHP не настолько медленный, особенно в свете выхода 7 версии.
Я не совсем понимаю ВК и ФБ, которые с PHP сделали костыли, вместо того, что взять компилируемый язык.
Си ООП
То есть на самом деле не так важна явная парадигма языка. :)
Вот только в отличии от вас у этих «самописей» авторы поопытнее будут.
Хм, настолько опытные, что решили писать самопись :)
Если самому не писать код, то можно и остаться программистом на Битриксе (Кодеигнайтер) и уметь только решать задачи в рамках ЦМС/фреймворка. :)
Потому свои проекты я пилю на ооочень адаптированном под себя symfony. По сути это мой фреймворк который на 90% состоит из отдельных компонентов которые мне лень писать самому.
На написание кода уходить процентов 10 времени, остальные 90 — это чтение.
Чем меньше, тем проще читать.
Фреймворки слишком универсальны.
Компоненты — это ок.
Но если мне не нравятся компоненты, которые реализуют ядро фреймворка.
То, без чего или с другой реализацией чего, по сути это уже другой фреймворк, как Ларавел и Симфони.
Взять и выбросить 90%? :)
Если нету цели иметь всеядный комбайн, то можно ограничится созданием ядра только под свои задачи.
Это ж не так много кода нужно.
Да и моя самопись эволюционировала с php странички, вся динамика которой была в отдаче элемента массива по индексу из запроса. Самым трудным для меня было понять, как получать GET параметры. Об этом в статьях типа «Создаем сайт на коленке» не говорилось :)
А когда у вас миллиард пользователей — чуть другие заботы появляются нежели фреймворки или языки программирования.
Конечно, затыки бывают не только на бекэнде.
blablacar например.
Тоже о них знаю. Это наверно единственный пример.
У них главная отдается с
cache-control:max-age=3600, public, s-maxage=3175
И дурота есть тоже.
Раскрученный проект не значит умно сделанный. :)sav1812
08.09.2016 02:47Я не совсем понимаю ВК и ФБ, которые с PHP сделали костыли, вместо того, что взять компилируемый язык.
Видимо, к тому времени, когда проблемой стал язык программирования, объём и сложность уже разработанного кода были настолько велики, что переписывание (читай — «разработка») «с нуля» на другом языке были совершенно невыгоды.G-M-A-X
08.09.2016 10:29-1Видимо, к тому времени, когда проблемой стал язык программирования, объём и сложность уже разработанного кода были настолько велики, что переписывание (читай — «разработка») «с нуля» на другом языке были совершенно невыгоды.
У меня кода на самописи настолько бла-бла-бла, что переписывать его на фреймворке совершенно невыгодно.Fesor
08.09.2016 14:43вот будет пара миллиардов строк кода — тогда поговорим о фэйсбуках вконтактах.
G-M-A-X
08.09.2016 20:50вот будет пара миллиардов строк кода — тогда поговорим о фэйсбуках вконтактах.
Миллиарды строк кода? :)
Ну да, ну да.
Судя по этой статье https://habrahabr.ru/post/308974/ Вы погорячились :)
А также берем во внимание, что там много разработчиков на ставке, а я своим кодом занимаюсь в свободное время как хобби (программирование сначала было моим хобби, а потом уже стало работой).
G-M-A-X
03.09.2016 15:42Ну, в принципе, это видно. Как по комментариям, так и по коду ;). Но например я не готов ехать в другой город на стуле, спать на машине и т.д.
Хотите — плодите сущности. Я в этом смыла не вижу.
И да, у вас не контроллерами решаются задачи, а как-раз виджетами. Контроллер у вас всегда один — index.php ;)
О-ло-ло. :)
Чего?!?! Фреймворк вызывает статику?! Или все-таки приложение?
То есть у Вас по коду раскиданы голые подключения скриптов:
<link href="//habracdn.net/habr/styles/1472830295/_build/global_main.css" rel="stylesheet" media="all" />
Ну ок.
А на простых кешировать статику не имеет смысла. Хватит кеша в браузере + get-параметр.
Так я как раз о гет-параметре и говорю. Чтобы его не вручную менять, а он сам менялся и не парится.
И это минус. Чтобы поправить хедер — мне править ядро? Бред…
304 ответ. Зачем его править?
Вы как узнаете, что страничка не изменилась?
Но, вы не показали, как это проще сделать на вашем фреймворке))))
Я этим не парюсь.
Этим занимается ядро.Fesor
06.09.2016 02:12Хотите — плодите сущности. Я в этом смыла не вижу.
разберитесь что это значит. Как по мне "писать свои ядра" — это плодить сущности потому что годных компонентов (не фреймворков) сейчас хватает.
Avenger911
05.09.2016 13:50В обычной ЦМС статическая страница это обычный php файл. В фреймворках начинаются танцы с бубном и контроллерами.
Бред.
Видимо, для автора просто "обычная ЦМС" === "1С-Битрикс".
G-M-A-X
04.09.2016 12:32Я не понимаю, с чем Вы спорили.
Я говорю, что на фреймворках нет из коробки «добавить новое вложенное меню», об этом и в статье (и многом другом, чего тоже нету).
Вы говорите, что нет и не нужно.
Спорьте тогда с предыдущими ораторами.
Или они используют какие-то неправильные фреймворки? :)Fesor
05.09.2016 17:14Я говорю, что на фреймворках нет из коробки «добавить новое вложенное меню»
потому что это задача не из категории 95%, а из котегории % людей которым нужны менюхи. Для таких есть отдельные либы к фреймворкам которые все это позволяют делать.
мне вот таким заниматься не нужно потому что за это отвечает фронтэнд (ангуляры, реакты и прочее). А у них опять же это не из коробки потому что навигация у каждого делается по своему и просто под 90% всех вариаций можно найти что-то готовое.
Вам например не фейрмворк нужен а CMF какая-нибудь. Вот и все.
Или они используют какие-то неправильные фреймворки? :)
вполне возможно)
t_kanstantsin
02.09.2016 01:37Написано много "интересных", "аргументированных" и "правильных" замечаний о вреде фреймвороков (особенно yii1 и yii2).
Для примера:
В обычной ЦМС статическая страница это обычный php файл. В фреймворках начинаются танцы с бубном и контроллерами.
Решение (в тот же yii) http://www.yiiframework.com/wiki/22/how-to-display-static-pages-in-yii/
Но боюсь, вы не осилите это решение — слишком сложное, нужен бубен.aktuba
02.09.2016 10:15Не поддавайся этому толстому троллю).
G-M-A-X
02.09.2016 14:13Статью я писал не с целью троллинга, а для систематизации недостатков фреймворков, дабы давать ее оппонентам, а не каждый раз вспоминать аргументы.
index0h
03.09.2016 23:55Да ладно, в вашей статье отсутствует объектиная критика (только субъективная), куча подмененных понятий и необоснованных выводов. Это отличный троллинг))
G-M-A-X
04.09.2016 00:07Эсли Вы принимаете правила фреймворков, то да, для Вас это все будет необъективным.
А также Вы можете добавить объективности статье:
Желающие могут указать свои трудности, с которыми пришлось столкнутся. Они будут добавлены в статью.
О каких подменных понятиях Вы говорите? :)index0h
04.09.2016 01:01О каких подменных понятиях Вы говорите? :)
В статье вы критикуете "фреймворки", при этом доводы базируете только на yii.
Далеко не все фреймворки используют MVC подход, вы же говорите так будто бы все.
Model вы рассматриваете только как ActiveRecord (пусть и не явно). AR — это одна из возможных реализаций Model.G-M-A-X
04.09.2016 12:26Не только yii, но в основном. О причинах этого я написал.
>Model вы рассматриваете только как ActiveRecord
Лично я рассматриваю шире.
А фреймворки примерно так (ну или иную конкретную реализацию хождения в БД).
МВЦ в:
https://ru.wikipedia.org/wiki/Symfony
https://ru.wikipedia.org/wiki/Laravel
Об остальных смысла говорить нету.index0h
04.09.2016 13:14Лично я рассматриваю шире.
Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.
В Symfony нет своей имплементации M из MVC, да есть Doctrine, но это проект другого вендора. Посему называть его MVC фреймворком не корректно.
Об остальных смысла говорить нету.
Смысл есть. Вы же набрасываете на фреймворки в целом. Что на счет Zend, Silex?
G-M-A-X
04.09.2016 14:45>Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.
Я рассматриваю шире. А все эти DBAL/DAO/ActiveRecord — это хождение в базу. И так рассматривают фреймворки, а не я.
>Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.
Это реализация хождения в базу. Я говорю, что неправильно рассматривать модель — как хождение в базу. Смысл мне перебирать все реализации хождений в базу, если я выступаю против их всех?
>В Symfony нет своей имплементации M из MVC
Ну и что, что нету. Под M все равно понимается хождение в базу. Symfony используется в связке с Doctrine чуть реже, чем всегда?
Пускай уберут в википедии упоминание, что они MVC в первом предложении, или там же укажут, что M у них как бы и нету. :) Хомячки ведутся на модные слова.
>Что на счет Zend
Каюсь, что упустил.
Он тоже MVC:
https://ru.wikipedia.org/wiki/Zend_Framework
Микрофреймворки / малоизвестные не рассматривал.
Так как малоиспользуемых много и смысла нету, я больше противник дурости в мейнстримовых (разрекламированных). Некоторые микро — это обрезки Симфони и Ларавел.index0h
04.09.2016 15:22А все эти DBAL/DAO/ActiveRecord — это хождение в базу. И так рассматривают фреймворки, а не я.
Вообще говоря — нет. Хранилищем данных может выступать и кэш, xml файл, внешний сервис, что угодно.
Пример: http://docs.doctrine-project.org/projects/doctrine-common/en/latest/reference/caching.html
Смысл мне перебирать все реализации хождений в базу, если я выступаю против их всех?
Если вы утверждаете, что все реализации — плохо, то должны смочь аргументировать такую позицию.
Микрофреймворки / малоизвестные не рассматривал.
У yii — 4679 звезды на github, у silex — 3292. Я бы не сказал, что тут прямо пропасть в уровнях известности.
G-M-A-X
04.09.2016 18:19>Вообще говоря — нет. Хранилищем данных может выступать и кэш, xml файл, внешний сервис, что угодно.
Ок, не база, а хранилище данных.
Интересно, какой оверхед у кеша (допустим мемкеш) doctrine по сравнению с чистым PHP.
О, вспомнил. На моей первой работе с фреймворками (Yii) отказались от моделей фреймворка (DBAL/DAO/ActiveRecord), а написали свой велосипед, который вызывался моделями фреймворка (сущностями, которые вроде продолжали наследовать фреймвок) :)
>Если вы утверждаете, что все реализации — плохо, то должны смочь аргументировать такую позицию.
Я выступаю не столько против самих реализаций, сколько против представления о моделях, как о сущностям, которые ходят в хранилище. Вообще, сущность не должна себя куда-то сохранять/извлекать. Это лишний функционал.
Хотя да, все эти ходилки в базу мне не нравятся. :) Некоторые я щупал в живую, о принципах некоторых читал в документации.
Меня полностью устаивает моя ходилка :)
silex основан на Симфони. У yii 2 8к звезд, хотя это не важно.
У исходников php 10к звезд.
Но это же не значит, что php менее популярен за свои фреймворки. :)
Да и звездочки можно накрутить.
Звездочка — это типа понравилось / избранное?
Что она еще дает?index0h
04.09.2016 18:48Интересно, какой оверхед у кеша (допустим мемкеш) doctrine по сравнению с чистым PHP.
Ничтожный)). Что с доктриной, что без, сетевые издержки будут на порядки дольше, чем обвязки.
Вообще, сущность не должна себя куда-то сохранять/извлекать.
Я рад за вас, вы только что придумали Entity-Repository. Во многих случаях он более надежный, чем AR. Правда бывают случаи, когда он слишком избыточный.
silex основан на Симфони.
На компонентах — да, на стеке выполнения — нет.
Звездочка — это типа понравилось / избранное?
Тип того + все ваши фоловеры видят, что какие проекты вы отмечаете.
index0h
04.09.2016 11:36А также Вы можете добавить объективности статье
Смысла нет. 99% вашей статьи — бред сивой кобылы.
Fesor
05.09.2016 17:17Статью я писал не с целью троллинга, а для систематизации недостатков фреймворков
1) твоя статья основана на опыте работы с одним фреймворком, весьма примитивном если честно.
2) выборка фреймворков и опыт работы только с одним не дают вам возможности что-то систематизировать.
3) для ваших задач это не нужно — потому это все больше выглядит как старая добрая фраза. Для молотка любая задача выглядит гвоздем. То есть вы не представляете что у кого-то могут быть другие задачи и для них ВАШИ способы работы не подходят.
G-M-A-X
05.09.2016 23:041) Но все фреймворки имеют указанные недостатки :)
3) Я и не заставляю всех. :) Если не подходит, значит не подходит. Мне вот фреймворки не подходят. :)
sav1812
03.09.2016 13:32Да, совершенно с Вами согласен: любому специалисту куда проще и легче включиться в работу, если ему хорошо известны и знакомы «инструменты и приспособления». Но мне кажется, что это не очень свежая идея… ;)
А вот если фрейморк и «кастомное решение» поставить в равные условия незнания либо знания их нашим разработчиком, то разница между ними для разработчика исчезнет совсем, или почти совсем. Не так ли? :)
Ogra
03.09.2016 18:53+2К популярным фреймворкам есть обширная документация, примеры использования, тонны вопросов на StackOverflow.
Равных условий не будет.sav1812
04.09.2016 01:33Забавные вы… :)
Фреймворк у вас обязательно и «популярный», и «хорошо знакомый» разработчику, а «кастомное решение» — и без документации, и вообще…
Да, действительно равных условий не будет никогда. Но и таких, как мечтается вам — тоже, в общем-то…
И «популярный фреймворк» может оказаться совершенно незнакомым новому разработчику, и кастомное решение — грамотно разработанным и хорошо документированным, что нивелирует разницу между ним и «популярным».
Ogra
04.09.2016 06:56+2Может. Теоретически.
В теории — теория и практика одно и то же. На практике же это совершенно не так.
laravel, yii — более 40000 вопросов на stackoverflow. Практически любой вопрос вида «как сделать то, как работает это, почему не работает так» можно вбивать в гугл и получать ответ сразу же. Ни одно кастомное решение такого не предполагает.G-M-A-X
04.09.2016 12:39Зачастую спрашивают откровенный бред.
Потому что говнокодеров заманили на фреймворки.
Ну или спрашивают, как обойти подводные камни фреймворка.
А в грамотной самописи их не будет (этих камней).
Поэтому многие задачи приходится решать порывшись в исходниках.
sav1812
04.09.2016 13:25Вы по-прежнему сравниваете «платформу» (фреймворк ) с конечной задачей, решение которой может быть основано как на фреймворке, так и на «самописном» коде.
И вынужден напомнить ещё раз: задача, выполненная при помощи и на основе фреймворка — это всё то же «кастомное решение».
Покажите мне, пожалуйста, пусть даже не «более 40000», н охоят бы «более 40» вопросов и ответов по конкретной задаче, разработанной «поверх» любого -пусть даже популярного :) — популярного фреймворка.
Только, пожалуйста, задачи не «массового применения», не «серийной», вроде асбтрактного блога или форума, или некой системы учёта, рассчитанной на широкий круг лиц — а конкретной, заказанной каким-либо заказчиком для своих личных нужд.
Вангую: нет таких… :)
t_kanstantsin
04.09.2016 10:59Нет, фреймворк не обязательно "хорошо знакомый", но при найме разработчика на проект достаточно указать в требованиях знание определенного фреймворка. Как нанять программиста на проект чуть менее чем польностью состоящего из "кастомных решений"? Все указать в вакансии? Таким образом, кого бы ни взяли на "кастомное решение", ему придётся разрабираться не только в этих "решениях", но и в том, как они связаны.
А если брать "на вырост", то тут уже играет роль документация и целостность решения. Если во фреймворке всё выполнонено в едином стиле (по крайней мере бОльшая часть), то каждое "кастомное решение" выполнено в "кастомного стиле".
sav1812
04.09.2016 13:33-1Ключевое слово: Документация.
Любой фреймворк — это всё те же «кастомные» (не люблю эти уродливые заимствования :) ) решения, но хорошо документированные. И от прочего самописного кода их отличает только большая применяемость, что к качеству самого продукта имеет, зачастую, далеко не прямое отношение.
Так что Вы ищете разработчика, знающего платформу, на которой основано данное «кастомное решение», которого любой нанимаемый Вами разработчик всё равно не знает — то я позволю себе иметь хорошо документированное «кастомное решение», которое мой разработчик всё равно будет изучать так же, как и Ваш. :)
А ругаемый здесь кем-то «говнокод» точно так же может «жить» и поверх фреймворка — в собственно приложении, всё так же «кастомном» (а иначе — никак!)…
И в чём тогда разница?? :)
sav1812
03.09.2016 13:13Времени потребуюется на порядок меньше.
Обоснуете? :)
Надо добавить новое вложенное меню — если ты знаешь фреймворк, то ты знаешь, что меню там делается именно вот так. Можно даже не искать по всему коду, как в нем это реализовано, а просто знать, что идем вон-туда.
Я, видимо, что-то пропустил, и теперь не знаю — а какая связь между PHP фреймворками и «вложенными меню»? Я где-то слышал :), что меню — это HTML+CSS(+JS), нет? ;)
И потом, Вы — в пылу спора, видимо — делаете «хорошее» такое допущение: «если ты знаешь фреймворк». :)
Вы, знаете, я не только не против — я очень даже «за» знания! Но давайте тогда предположим, что «ты» знает и самописный код на PHP, а? Ну, просто справедливости ради. И тогда мой ответ Вам в этой части будет выглядеть как-то так:
Надо добавить новое вложенное меню — если ты знаешь самописный код, то ты знаешь, что меню там делается именно вот так. Можно даже не искать по всему коду, как в нем это реализовано, а просто знать, что идем вон-туда.
Хорошо, правда? :))
Да, и возражения из серии «Да фреймворки знают все, а этот код — только его разработчик!» — не принимаются.
Причины:
1. Фреймворков очень много.
2. При допущении о знании новым разработчиком данного конкретного фреймворка — смотрите моё замечание касательно "если ты знаешь". :)
3. Фреймворк — только «платформа», на которой строится приложение, опять-таки представляющее из себя наш злосчастный «самописный код» (Sic!).
Думаю, здесь моя идея понятна, да? :)
Тогда идём дальше.
«Дорого для всех. Всегда все хотят платить меньше. С какой стати это ошибка владельца? Владелец обязан знать что такое фреймворки? Что такое движки? Вы совершенно не правы, если не хотите все это считать, хотя бы в теории.»
А кто у нас придумывает идею задачи? Кто нанимает разработчика, даёт ему ТЗ, контролирует разработку — не забывая, конечно же, и о документации? Ну, и так далее.
Кто должен всё проконтролировать, чтобы было «как надо»? Разве не наш владелец? Разве не он, помимо контроля за соответствием исполнения задачи его замыслу, должен проследить, чтобы конечный продукт не оказался «вещью в себе», справиться с которым не в состоянии никто, кроме первоначально нанятого «мага и волшебника»?
Так вот я и имею в виду, что если владелец что-то там «промухал», то это он ССЗБ, а вовсе не разработчик. Его вина.
Так что это Вы «совершенно не правы, если не хотите все это считать, хотя бы в теории».
«Я так думаю!» © :)
t_kanstantsin
01.09.2016 01:24+3потребуется время на то, чтобы «разобраться».
Вот только разбираться он будет не в том "а что это предыдущий программер тут нагородил с роутингом и т.д.", а непосредственно с бизнес-логикой.
Для владельца? Так это будет плата за его же ошибки, допущенные им в самом начале…
А какие ошибки допустил владелец? О_О Не он же "разрабатывал с нуля", а предыдущий программер. Т.е. владелец будет расплачиваться за ошибк, допущенные (предыдущим) разработчиком. И в каждом магазине будут одни и те же ошибки
sav1812
03.09.2016 13:21Вот только разбираться он будет не в том «а что это предыдущий программер тут нагородил с роутингом и т.д.», а непосредственно с бизнес-логикой.
Ну, во-первых, какая разница, на что именно он потратит то же самое, в общем-то, время?
И во-вторых — а почему Вы так уверены что там, «над» фреймворком, будет бизнес логика, «белая и пушистая»? ;)
Тот же самописный код, по сути… Ну, если только наша задача не сводится к простейшей «демке» применения конкретного фреймворка, в пару строк. :))
А какие ошибки допустил владелец? О_О Не он же «разрабатывал с нуля», а предыдущий программер. Т.е. владелец будет расплачиваться за ошибк, допущенные (предыдущим) разработчиком.
Да нет же. :)
Повторяться не хочу, чуть выше уже пояснил свою точку зрения.
И в каждом магазине будут одни и те же ошибки
Очень даже может быть.
Только они будут «одни и те же» у одного и того же разработчика, вне зависимости от того, на чём он строит свои приложения.
Мне кажется, ошибки всё больше исходят от людей, а не от используемых ими «инструментов и приспособлений». :)t_kanstantsin
04.09.2016 11:21Нет, нет и ещё раз нет:)
Ну, во-первых, какая разница, на что именно он потратит то же самое, в общем-то, время?
известный разработчику фреймворк: время на бизнес-логику (и не важно, пушистая она или нет — точно такая же будет в самописном фреймворке)
самописный код: сначала разобраться во фреймворке; затем в бизнес-логике. И на втором шаге постоянно оглядываться на первый.
А какие ошибки допустил владелец?
Кто должен всё проконтролировать, чтобы было «как надо»?
Простите, а когда я пропустил тот момент, когда все заказчики поголовно стали программистами-архитеторами-дизайнерами, что могут отслеживать каждый шаг и контролировать качество продукта?:)
Только они будут «одни и те же» у одного и того же разработчика
Не угадали. Есть фреймворк/CMS, к которым написаны и применены в десятках других проектах модули (и будем откровенны, очень часто они завязаны на фреймворк/CMS так, что не оторвать). Если в нём и есть ошибка, то она допускается 1 раз и со временем исправляется. Тоже 1 раз. В случае велосипеда кто будет её исправлять на десятках проектов? И кто сказал, что набор ошибок одного и того же функционала в разных пректах будет одинаковым?
ИМХО, проектов, требующих какой-то особой организации, которую не может предоставить фреймворк. А большая часть тех, кто думает, что у него именно такой проект, заблуждаются.
sav1812
04.09.2016 14:25-1Нет, нет и ещё раз нет:)
Да. Один раз. Не люблю повторяться. :)
известный разработчику фреймворк: время на бизнес-логику (и не важно, пушистая она или нет — точно такая же будет в самописном фреймворке)
самописный код: сначала разобраться во фреймворке; затем в бизнес-логике. И на втором шаге постоянно оглядываться на первый.
А почему в первом случае разработчик знает фреймворк, а во втором Вы его заставляете «разбираться», а потом — ещё зачем-то и «оглядываться»?? Тем более, что она «точно такая же»?.. :(
По-моему, Вы мухлюете… :)
Не угадали.
Так а я и не.
Я понимаю, что людям нередко свойственно судить о других по себе, но… Вы ошиблись. :)
Есть фреймворк/CMS, к которым написаны и применены в десятках других проектах модули (и будем откровенны, очень часто они завязаны на фреймворк/CMS так, что не оторвать). Если в нём и есть ошибка, то она допускается 1 раз и со временем исправляется. Тоже 1 раз. В случае велосипеда кто будет её исправлять на десятках проектов? И кто сказал, что набор ошибок одного и того же функционала в разных пректах будет одинаковым?
Ну а здесь Вы даже и не мухлюете, а откровенно жульничаете, сравнивая фреймворк — «базу» для всё такого же самописного приложения — с другим самописным приложением. Это нечестно, я так не играю… :))
ИМХО, проектов, требующих какой-то особой организации, которую не может предоставить фреймворк. А большая часть тех, кто думает, что у него именно такой проект, заблуждаются.
Эээмммм… А Вы не пробовали читать то, что пишете? :)
Эта Ваша мысль слишком глубока для меня… :))
BoogerWooger
30.08.2016 17:04+2Очень правильная статья. Вообще, практически везде по жизни отлично работает правило «без фанатизма». Любая разумная рекомендация или правило может превратиться в ад адский, если её бездумно применять всегда и везде.
atc
30.08.2016 17:27-2> В этом случае вы добавляете уровень абстракции поверх другого уровня абстракции, который изначально создавался как базовая точка отсчёта.
Это необходимо, особенно если учитывать, насколько неприятен чистый php. Решения таких задач как чтение-запись файла\загрузка данных по http\прослушивание сокета выглядят крайне неопрятно без использования сторонних библиотек, так как php в большинстве случаев не предоставляет удобных абстракций, а просто занимается копированием C функций.
youROCK
30.08.2016 19:06+12Извините, но что здесь является неудобным :)?
1. Чтение-запись файла:
$contents = file_get_contents("filename"); file_put_contents("other_filename", $contents);
2. Загрузка данных по HTTP
$contents = file_get_contents("http://something/other_thing"); // да, это та же функция! // Если нужно что-то более продвинутое, используйте curl, он умеет ВСЁ
3. Прослушивание сокета
$socket = stream_socket_server("tcp://0.0.0.0:8000", $errno, $errstr); while ($conn = stream_socket_accept($socket)) { fwrite($conn, 'The local time is ' . date('n/j/Y g:i a') . "\n"); fclose($conn); }
PHP специально сделан, чтобы упростить решение типовых задач для веба и в нём есть удобные абстракции для большинства стандартных вещей. Также там есть возможности для того, чтобы сделать практически всё имеюшее практическую ценность в вебе (и не только), причём, как правило, оно тоже достаточно удобно.
Вас смущает, что это какие-то вещи офомлены в виде классов с 10 видов исключений? Ну так а зачем нужно использовать ООП для такой простой задачи?Delphinum
30.08.2016 19:09+4Ну так а зачем нужно использовать ООП для такой простой задачи?
Просветите, как мне тестировать код, использующий вызовы file_get_contents и file_put_contents?youROCK
30.08.2016 19:42+5https://github.com/badoo/soft-mocks или
https://github.com/krakjoe/uopz
на ваш выборDelphinum
30.08.2016 19:53-4Я надеялся вы предложите перегружать стандартные функции с помощью namespace, но костыль тоже сойдет. Можно примерчик теста с использованием любого из? )
youROCK
30.08.2016 20:21+5Пример для strlen:
\QA\SoftMocks::redefineFunction( 'strlen', '$a', 'return \\QA\\SoftMocks::callOriginal("strlen", [trim($a)]));' ); var_dump(strlen(" a ")); // int(1)t_kanstantsin
31.08.2016 10:59Воу, а как же "PHP специально сделан, чтобы упростить решение типовых задач для веба и в нём есть удобные абстракции для большинства стандартных вещей"?
Зачем использовать какую-то левую библиотеку? Разве в php нет для этого стандартной функции? А это же лишняя зависимость в проект! Бедный ваш заказчик, который регулярно переплачивает за то, что вы не в состоянии написать тест сами!
Никогда не понимал людей, которые используют внешние зависимости! Только свои решения!
Delphinum
31.08.2016 12:41+1Зачем использовать какую-то левую библиотеку?
Вообще PHP позволяет сделать то же через namespace без «левых зависимостей»
Flammar
31.08.2016 02:42+2Спасибо за разъяснение зачем нужно ООП, когда можно обойтись без него. Оказывается, в первую очередь чтоб всё мокалось и благодаря этому юнит-тестилось.
youROCK
31.08.2016 14:13Вы можете моки через хаки динамического линковщика делать даже на Си, где ООП и не пахнет. Паттерн Dependency Injection, конечно, позволяет писать код, в котором можно подменять реализацию любого класса, но я лично не согласен с тем, что ООП создавался для этого. В принципе, DI можно сделать и в процедурном стиле, хоть это и будет выглядеть не так «красиво».
atc
30.08.2016 19:18+1Совершенно все, начиная отсутствием объектного интерфейса (я вынужден помнить список разрозненных функций вместо использования публичных методов объектов), заканчивая одинаковым порядком аргументов (точнее его отсутствием) в функциях.
Curl же совершенно особая песня, его можно отнести к особым, наиболее неудобным сторонам php.
В качестве контрпримера приведу библиотеки, которые на мой взгляд привносят хорошие, удобные абстракции:
https://github.com/guzzle/guzzle
https://github.com/moment/moment
https://github.com/KnpLabs/GaufretteMacIn
30.08.2016 21:21+6Совершенно все, начиная отсутствием объектного интерфейса
Простите, но это замкнутое докащательство: автор постулирует в том числе отсутствие необходимости в повсеместном ООП, в качестве примера приводит процедурный код и вы говорите «а тут нет объектного интерфейса». Ясное дело нет: это пример другого подхода.
я вынужден помнить список разрозненных функций вместо использования публичных методов объектов
Стоп-стоп-стоп, а если вы используете объектный интерфейс, вам не надо помнить имя класса и имена методов? Или вы пользуетесь подсказками IDE? Тогда и с процедурным подходом то же самое — поиск по имени и автодополнение.atc
30.08.2016 21:59Для поиска по имени нужно либо это имя помнить, либо иметь префикс (который есть далеко не у всех функций), так же в процессе этого придется отбрасывать n-oe количество методов, которые имеют похожие имена, но к задаче не относятся. Так же процедурный код не предоставляет удобного способа хранения\инкапсуляции внутреннего состояния, что дополнительно нагружает разработчика и загрязняет код.
Подсказками IDE пользуюсь, всегда.MacIn
30.08.2016 22:36+3Для поиска по имени нужно либо это имя помнить, либо иметь префикс (который есть далеко не у всех функций)
А с ООП не так? Имя класса и метода не надо помнить?
так же в процессе этого придется отбрасывать n-oe количество методов, которые имеют похожие имена, но к задаче не относятся
Это зависит от разбиения на модули, в общем — частность.
Так же процедурный код не предоставляет удобного способа хранения\инкапсуляции внутреннего состояния, что дополнительно нагружает разработчика и загрязняет код.
Мы говорим об интерфейсе, изначально в разрезе примера доступа к файлу и т.п. но все равно во множестве случаев внутреннее состояние в процедурном подходе точно так же инкапсулируется. Например, вы открываете файл, получаете handle, все внутренние данные скрыты за ним.
Подсказками IDE пользуюсь, всегда.
Тогда непонятно, в чем проблема поиска имени — открываем модуль, ответственный за класс функций X и смотрим список процедур. Это ничем особым не отличается от подсказки при вводе имени экземпляра класса.
Все сводится к правильному разбиению на модули и хорошим именам процедур. Если мы предполагаем, что имена могут быть плохими, не отражающими суть действия, то мы можем равно предполагать, что в ООП вместо LinkedList.First() мы будем иметь LL.f(), что ничем не лучше, чем какой-нибудь llgfe(abc)atc
30.08.2016 23:11Кажется эта ветка комментариев постепенно начала вырождаться в объяснения основ ооп, зачем оно нужно и чем лучше процедурного кода. Извините, но нет, не хочу, вольный пересказ Мейера — это не слишком интересное занятие.
MacIn
31.08.2016 15:18Нет, мы с вами спорим по одной простой частности: о том, что «нужно помнить имя».
Flammar
31.08.2016 03:02иметь LL.f(), что ничем не лучше, чем какой-нибудь llgfe(abc)
Чуть лучше: «LL» и «f» не свалены в одну кучу, «abc» инкапсулировано в «LL», а не передаётся в функцию, которую можно перепутать, да ещё и как аргумент безликого стандартного типа вроде «число» или «целое» или чем там заменяется указатель на объект.Ogra
31.08.2016 08:04Если не сваливать все функции в одну глобальную область видимости, а пользоваться модулями или неймспейсами, то проблема исчезает. Между linked_list_instance.first() и linked_list.first(instance) нет никакой разницы.
Безликими типами пользоваться не нужно, конечно же.
merlin-vrn
31.08.2016 10:10+1Эта запись с точкой — всего лишь синтаксический сахар. Не это является сутью и признаком объектно-ориентированного программирования и, как другой сахар, не является обязательно необходимым.
Для ООП требуется то, что требуется: в первую очередь инкапсуляция (в логическом смысле, в проекте), на которую вы намекаете. То есть, у меня есть некая структура и набор функций для работы с именно этой структурой или её усложнёнными вариантами, это вот признак объектно-ориентированного программирования, и процесс разработки программы не зависит от того, напишу я f.a(), или classf_a(f). Более того, C++, когда-то был фронт-эндом для C и имеено то самое и делал: заменял конструкции вида f.a() на classf_a(f), после чего отдавал результат обычному компилятору C. Глупо же говорить, что после обработки фронт-эндом программа переставала быть объектно-ориентированной, правда?
А ещё есть такая штука как GLib, в которой по сути тем же способом реализован объектно-ориентированный подход на чистом C. Естественно, никакого специального синтаксиса — C как C. Но разработка явно объектно-ориентированная.
И точно так же можно писать на C++ совершенно не объектно-ориентированный код. Но точки при этом будут.
MacIn
31.08.2016 15:22Суть сравнения LL.f() и llgfe() — не в противопоставлении концепций процедурки о ООП, а пример плохих имен, только и всего.
MacIn
31.08.2016 15:21+1Чуть лучше: «LL» и «f» не свалены в одну кучу
Ок, пусть в процедурном API будет в качестве примера не llgfe(abc), а ll_gfe(abc).
«abc» инкапсулировано в «LL»
Это разумеется, но там выше спор об именах был и о том-де, что сложно вспомнить, как функция называется в процедурной парадигме. К чему я и привел пример — если мы говорим о заведомо плохих именах, то никакое ООП не спасет.
Flammar
31.08.2016 02:57а если вы используете объектный интерфейс, вам не надо помнить имя класса и имена методов?
Ну, к примеру, на VBA программировать сильно удобнее, чем на ExcelBasic или WordBasic как раз из-за того, что там 900+ функций реорганизованы в ~30 классов с ~30 методами каждый. Правда, работает существенно медленнее, но это уже нюансы.Или вы пользуетесь подсказками IDE?
Тоже существенный фактор. ОО языки сильно лучше дружат с интеллектуальными IDE.MacIn
31.08.2016 15:23как раз из-за того, что там 900+ функций реорганизованы в ~30 классов с ~30 методами каждый
Сложите эти функции по 30 модулям с префиксами — то же самое по части имен.
not_ice
30.08.2016 19:59+1Ок, а если мне нужен ORM, конфигурирование различных окружений, роутинг, логирование и т.д.?
CAJAX
31.08.2016 09:23+1file_get_contents(«http://something/other_thing»);
До первого таймаута. Потом человек узнает, что надо было использовать curl, тут же офигевает, что для этого надо с десяток строк кода и фигачит ещё один guzzle.youROCK
31.08.2016 11:07+2На самом деле, можно передать таймаут в контекст file_get_contents :). Но я и правда умолчал об обработке ошибок. Впрочем, адекватная обработка ошибок — это всегда боль, не важно, ООП у вас или нет.
Fesor
31.08.2016 15:04+1это всегда боль, не важно, ООП у вас или нет.
В этом и прикол библиотек, они всю эту боль на себя обычно берут и делают какие-то упрощения. А ООП позволяет вам "изолировать" все сайд эффекты.
Fesor
31.08.2016 15:03-1Чтение-запись файла:
поддержка облачных хранилищ? Тестирование? Да, есть стримы и врапперы для стримов (спасает в принципе) но всеже
Загрузка данных по HTTP
В ответе только тело ответа, а мне заголовки иногда нужны. То есть уже надо юзать curl. А потом еще мне надо делать 10 паралельных запросов и что бы было удобно, фасадик сверху и мы уже получаем библиотечку вроде co. А у других свои задачи со своими нюансами.
Прослушивание сокета
web sockets, хэндшейки, работа с готовыми протоколами и т.д.
youROCK
31.08.2016 16:30На самом деле, для вебсокетов и для асинхронного выполнения 10 HTTP-запросов я бы использовал другой язык, go. Конкретно PHP тут уже упирается в отсутствие тредов, но отсутствие тредов — это тоже сознательное решение, позволяющее писать более простой и управляемый код для веба.
Поддержка облачных хранилищ обычно сводится к работе через HTTP. Заголовки действительно получить через file_get_contents нельзя, но заметьте, что cURL предлагает вполне сносный (и вполне себе объектный, хотя может так не показаться поначалу) API.
Библиотеки вроде https://github.com/mpyw/co лишь эмулируют «треды» и не позволяют дальше выполнять свой код асинхронно по отношению к выполняющимся запросам. Настоящие асинхронные запросы к MySQL и memcached есть в HHVM, кстати.Fesor
31.08.2016 20:42-1На самом деле, для вебсокетов и для асинхронного выполнения 10 HTTP-запросов я бы использовал другой язык, go.
Даже если у вас есть уже продукт на PHP и эта штука нужна для второстепенного функционала? Микросервисы мало кто умеет готовить нормально, так что представьте что у вас монолит.
Конкретно PHP тут уже упирается в отсутствие тредов
Треды не лучший способ работы с I/O, а вот корутины в PHP есть уже довольно давно. Я спорить не буду в том что go раскидает наши корутины еще и по потокам и вообще эффективнее такие задачи решает, но тут конкретно мысль о том что треды не для этого.
cURL предлагает вполне сносный (и вполне себе объектный, хотя может так не показаться поначалу) API.
С каких пор "изменение состояния объекта процедурами" называется объектный?
Библиотеки вроде https://github.com/mpyw/co лишь эмулируют «треды»
повторюсь. Эта "эмуляция тредов" называется корутины. В Go похожий принци просто чуть сложнее.
и не позволяют дальше выполнять свой код асинхронно по отношению к выполняющимся запросам
Вообще-то позволяет. Мы можем получить промис и блокировка процесса будет произведена только на время работы самого пыха. Мультиплексирование потока команд и все такое.
Настоящие асинхронные запросы к MySQL и memcached есть в HHVM, кстати.
У HHVM все очень плохо с постгресом, к сожалению. Да и memcache я как-то не юзаю ибо мне удобнее работать с redis. Ну и опять же асинхронные запросы к базе это… актуально отлько тогда, когда мы имеем демонов которые обслуживают сразу по несколько десятков запросов хотя бы. А на данный момент инфраструктура пыха в плане библиотек поддерживающих неблокируемые операции весьма скудна.
bohdan4ik
01.09.2016 22:20> Заголовки действительно получить через file_get_contents нельзя
Справедливости ради, заголовки получить можно, но весьма таки неинтуитивным способом.
> file_get_contents(«http://example.com»);
> var_dump($http_response_header);
Если хочется отправить пачку HTTP запросов асинхронно и нативно, то можно попробовать поиграться со stream_select. Сам таким не занимался, но, в теории, должно будет сработать.
P.S.: я буду обновлять комментарии, я буду обновлять комментарии…
Flex25
01.09.2016 20:04+1> В ответе только тело ответа, а мне заголовки иногда нужны. То есть уже надо юзать curl.
Не надо. Заголовки http-ответа доступны через переменную $http_response_header
file_get_contents('http://ya.ru');
var_dump($http_response_header);
С помощью file_get_contents() можно сделать и POST-запрос, и передать любые http-заголовки запроса, и таймаут выставить. Так что в 90% случаев можно обойтись без CURL.
Но не понятно, в чем спор? CURL — это библиотека, а автор статьи ничего не имеет против библиотек.
Temirkhan
30.08.2016 17:31+4Почему я чувствую словно каждое следующее утверждение все ярче и ярче кричит САРКАЗМ в конце высказывания?
artemiycpp
30.08.2016 17:31+2Например, PDO — маленькая библиотека, предоставляющая согласованный интерфейс для обращения к базам данных в PHP.
Но даже тут для удобной работы с PDO необходима еще 1 абстракция и все сведется к написанию ещё одного велосипеда.
holy_finger
30.08.2016 17:52+5Постоянное использование фреймворков
Напомню, что фреймворк, это набор инструменты для разработки и не более.
Все PHP-фреймворки общего назначения — отстой!
Расмус Лердорф
А я скажу, что Расмус Лердорф отстой, раз такое заявляет.
Компании сталкиваются с тем, что фреймворки общего назначения плохо помогают решать конкретные задачи, к тому же очень медленно работают. Фреймворки невозможно масштабировать, и многие компании пытаются выдрать из них куски в отчаянной надежде заставить работать то, что изначально не требовалось.
Компании с этим сталкиваются и с использованием других инструментов.
Мне к примеру фреймворки очень хорошо помогают решать конкретные задачи.
А про скорость это просто смешно. Ну да PHP работает медленно сам по себе(относительно других ЯП(что опять отдельная тема для дискуссии)), но если на сайт и так заходят 2 человека, то кто скажет где узкое горлышко? В РНР? Сомневаюсь. Его сил на 2 пользователей хватает с головой.
Масштабирование? А это проблема абсолютно всех проектов. Нам конечно рассказывают сказки про крутые масштабируемые системы, но зачастую это откровенное вранье. Всегда находятся нюансы о которых ты просто не знал в начале проекта, которые в итоге твою масштабируемость убивают. Начинаешь писать костыли(если нет времени) или переписывать очень многое(если время позволяет).
Не бывает простых методов масштабируемости. Увы и ах.
Вообще статья ОЧЕНЬ спорная.Temirkhan
30.08.2016 18:02Да что тут спорного-то, ей богу? До тех пор, пока у программистов не появится «коллективный разум улья», систематизация знаний и методик будет оставаться универсальным решением.
holy_finger
30.08.2016 18:19+1Действительно так.
Надеюсь дожить до коллективного разума.Acuna
30.08.2016 22:38Конечно надежда помогает вставать по утрам, однако я вижу только то, что чуть ли не каждый год появляется еще больше библиотек, призванных их разрабами стать стандартом де-факто. Поэтому эта идея «коллективного разума» лично для меня остается из разряда колоний на Луне (хотя-бы на Луне): очевидно, что это будет возможно в будущем, однако в нашем обозримом будущем полеты в космос будут осуществляться разве что с помощью костров святой инквизиции. Извините за такую грустную иронию, наболело просто…
spmbt
30.08.2016 18:34Они же о себе всё сказали в конце — что они — безымянные тролли, и на Гитхаб даже выложили не код, а свою единственную статью из корня доменного имени сайта. В основе которой — цитаты известных людей против парадигм, сказанные по разным случаям. Отсутствие контрпримеров подсказывает, что авторы только что прошли стадию понимания недостатков слепого следования фреймворкам и сами думают, что же делать дальше.
BoogerWooger
30.08.2016 18:49+2Зря вы на автора перешли, ваш уровень настолько высок, что вы помимо статьи можете оценить его уровень? Который, возможно, имеет дело с проектами, совершенно непохожими на ваши и с совершенно другими требованиями и окружением? Типа, если человек написал статью про паттерны программирования без контрпримеров, это означает, что он «только что» прошел стадию понимания паттернов программирования?
По моему, как раз надо бы больше статей, которые позволяют взглянуть на вопросы разработки под другим угломDelphinum
30.08.2016 18:54По моему, как раз надо бы больше статей, которые позволяют взглянуть на вопросы разработки под другим углом
Залезьте на какой нибудь форум разработчиков-новичков, там подобной «прагматичной» чуши океан.
spmbt
31.08.2016 00:06Потому что сказанное в статье грамотно, всё это можно найти по разным статьям в интернете, но тропинка протаптывается в направлении троллизма в плане «не надо пользоваться фреймворками». А авторы неизвестны. Об их уровне можно сказать, что он не начальный, стадию отрицания ООП они прошли самостоятельно. Но отсутствие конструктивности, что все отмечают, говорит, что до этой стадии ещё не дошли (обычно приходят или к паттернам, или к ФП. Но паттерны они тоже отрицают почему-то (цитаты подходящие попались от Пола Грэма про макросы? так это он про Си, скорее) — говорит как раз о недлинном пути).
В общем, да, по статье всё читается. Посмотрите других критиков ООП — там хорошо видно, что они что-то предлагают вместо него (прототипы, примеси, ФП). Ближайших примеров на Хабре можно найти очень много, вот, например, за 5 августа. Или эти 2 статьи: http://frontender.info/the-two-pillars-of-javascript/Source
31.08.2016 02:38+1цитаты подходящие попались от Пола Грэма про макросы? так это он про Си, скорее
Это он про Common Lisp.
Подбор цитат к статье вообще жжёт… из всех процитированных, по-моему, только 1 человек использует PHP и это Расмус :-)
not_ice
30.08.2016 20:03+3Да, емое, велосипед, который будет обладать более высокой производительностью, чем фреймворк, надо еще поискать ))
Тот же Yii, построенный на концепции «ленивости» во всем, даже ухом не поведет, пока вы не обратитесь к какому-либо релейшену конкретной модели (не то, что запрос в БД не сделает, даже класс не проинклудит до непосредственного обращения к классу модели). И что, я должен все это продумывать каждый раз для нового приложения? Ну бред вообще же полнейший.
zelenin
30.08.2016 23:10+1вы очень поверхностно смотрите.
Объект вашей модели yii, ожидая ленивого запроса уже содержит в себе несколько объектов на каждую ленивую связь, объект схемы таблицы с объектами колонок таблицы, объекты поведений, десяток объектов валидаторов, непосредственно объект абстракции над коннекшном к базе ActiveQuery, внутри которого объект квери билдера и самого коннекшна (черт знает, что я еще не вспомнил).
В абстрактном «велосипеде» есть простой конекшн к базе, простейший репозиторий в кач-ве абстракции над коннекшном, сервис, в котором происходит валидация одним валидатором и непосредственно сохранение простейшей модели через репозиторий, и все в это десятки раз легче по памяти чем модель yii.
Расмус именно это и имел в виду: предоставляя всеконфигурируемость приложений, фреймворки лишают большинство желания разбираться что там под капотом, и нужно ли оно. Покрывая 95% потребностей всех разработчиков, фреймворк добавляет на это 50-70% оверхеда.
К слову: страница с простым листингом одних и тех же сущностей на yii кушает памяти в 5 раз больше, чем страница на одном из микрофреймворков.springimport
31.08.2016 16:13+1Да какая разница. Вы не из сферического вакуума, случайно?
А что будет с вашим фреймоворком когда нужно будет другому человеку его поддерживать? То-то же.zelenin
31.08.2016 16:32каким фреймворком? речь о приложении на основе framework-agnostic модулей, которые по структуре будут намного проще для понимания любым php-разработчиком без знаний конвенций какого-либо фреймворка.
t_kanstantsin
31.08.2016 19:41Т.е. составленные вместе рандомные (в плане комбинаций альтернатив) "framework-agnostic модули" не требуют "знаний конвенций какого-либо фреймворка", а фреймворк состоящий из таких же модулей, но собранных и разработанных в едином дизайне — требует какие-то непосильные "знания"?
zelenin
31.08.2016 19:59все знания посильны. Но создавая модули для фреймворка программист а) ограничивает область применения одним фреймворком б) жестко связывает модуль с конкретными реализациями, зачастую хардкодя их использование в) накладывает требования к необходимым знаниям — апи фреймворка. Зачем связывать принудительно с фреймворком Х, если можно связывать с любым фреймворком/библиотекой через интерфейс адаптера, таким образом перекладывая вопрос выбора инструмента на конечного разработчика.
t_kanstantsin
01.09.2016 01:43а) не вижу проблемы. Создаётся обощённый компонент + простой адаптер для отдельного (своего) фреймворка. А если этот функционал специфичный для проекта, то какая разница, в том, ограничена ли область применения одним фреймворком? Часто ли меняется фреймворк в проекте? Даже тип БД меняется крайне редко, а фреймворк вообще маловероятно.
б) аналогично, захардкоживание — не проблема фреймворка. Он как раз позволяет и мотивирует так не делать.
в) если модуль используется в определённом фреймворке, то он, скорее всего, написан по тем же соглашениям и правилам, которые определены во фреймворке. А значит, что всегда можно догадаться, как ведёт себя каждый отдельный модуль.
Зачем связывать принудительно с фреймворком Х
Это вопрос создания библиотеки. Никто не запрещает изначально создать модуль и адаптер к нему для своего фреймворка. Если кто-то этого не делает — это его заботы. Возможно у него нет времени, возможно желания или знаний. Но разве это проблема отдельного фреймворка?
Но в отличие от франкенштейна из разнородных модулей, полученный модуль будет однородным в рамках фреймворка и может быть с лёгкостью применён в другом проекте написанном на таком же фреймворке.zelenin
01.09.2016 02:12>>> не вижу проблемы. Создаётся обощённый компонент + простой адаптер для отдельного (своего) фреймворка
проблемы нет. Это и есть framework-agnostic.
>>> А если этот функционал специфичный для проекта, то какая разница, в том, ограничена ли область применения одним фреймворком? Часто ли меняется фреймворк в проекте? Даже тип БД меняется крайне редко, а фреймворк вообще маловероятно.
функционал получения данных специфичный для проекта? Начинаешь проект на mysql, заканчиваешь на смеси elasticsearch с каким-нибудь http-сервисом, из которых собираются сущности.
В процессе развития карьеры и опыта каждый новый проект становится сложнее, и больше предъявляет требований к изначально верному построению архитектуры. И смена/комбинирование источника данных становится ежепроектной обыденностью, приучащей хардкод заменять на интерфейсы+адаптеры. В больших проектах, над которыми работают на протяжении нескольких лет множество программистов, меняются требования ко всему неединожды.
>>> аналогично, захардкоживание — не проблема фреймворка
я не говорил о проблемах фреймворка. я говорил про плюсы framework-agnostic подхода. Это гибче для использования, проще для понимания, но требовательней к навыкам проектирования
ajaxtelamonid
30.08.2016 18:00+2Из статьи я вынес, что Расмус очень самокритичен.
Остальная же часть… Авторы серьезно верят, что в следующий раз при начале проекта люди не возьмут Laravel, Symfony или тот же Yii, а начнут писать на этом чрезвычайно неудачном фреймворке под названием PHP? Если людям нужно масштабироваться, людям можно взять Go или, там, набирающий обороты Elixir. Но людям это как правило не нужно, людям нужно решение своих типовых задач. Они за этим пришли в PHP.
Не использовать ООП и шаблоны проектирования как магию, которая сама все исправит, быть программистом и копипастером — это все замечательно. Но, если подумать, причем тут фреймворки?
RomanArzumanyan
30.08.2016 18:00+3Ядро Linux содержит более 20 миллионов строк кода, написанных исключительно с помощью процедурного программирования
Неверно делать вывод о стиле программирования на основании используемого языка. На С тоже пишут (в том числе, и в ядре) с использованием некоторых техник ООП. Критика парадигмы, а не кокретных примеров её использования вызывает только раздражение.
DeLuxis
30.08.2016 18:14Критикуя предлагайте что-то взамен.
IvanCher
31.08.2016 09:55+2Соглашусь. Я тоже не понимаю, какие альтернативы предлагает Расмус? Я пишу на php уже много-много лет и спасает только то, что параллельно читаю стандарты в Java и более-менее стараюсь следовать им в php.
Окей, предположим, что php — это фреймворк для веба… Тогда я смело заявляю, что это точно полный отстой, потому что более скудного и бесполезного фреймворка я не встречал. Где хотя бы соглашения/стандарты/реализации роутинга, секьюирити, валидации, ОРМ? Даже тот же PDO нельзя назвать библиотекой, потому что он дает ну настолько уж базовый функционал, что поверх него еще библиотеку нужно строить.
Ладно, кто-то всё ровно скажет, что php классный фреймворк и его библиотека PDO классно работает с БД, а секьюрити, валидация и роутинг — это мои капризы, кому они нужны в «реальном бизнесе». Но где в этом фреймворке возможность тестирования? Этим даже там и не пахнет, снова нужно искать какие-то левые библиотеки, написанные на этом недофреймворке и… писать кучи абстракций над всем, что есть в недофреймворке.
Всё же php это ЯП для веба и не более того. А такие фреймворки, как Symfony2+ и Laravel хоть как-то сглаживают весь хаос, неоднозначность, непредсказуемость в php.
Я любил php, пока не стали заставлять делать на нем ERP, CRM и документооборот. Ну не предназначен он ни для чего серьезнее обычного сайта, который просто динамически генерирует html.
Не хотел никого задеть и обидеть, но Расмус немного в своих высказываниях зазнается и забывает своё место.merlin-vrn
31.08.2016 10:21Где хотя бы соглашения/стандарты/реализации роутинга
А что такое роутинг? Процесс выбора, какой модуль будет выполняться в зависимости от того, что за запрос пришёл?В первоначальной инкарнации PHP предполагалось, что роутинг выполняет веб-сервер. Т.е. есть 10 скриптов, имеющих разные адреса (например, имена файлов разные, или лежат в поддиректориях), и какой из скриптов (читай — какой модуль) вызвать, определит веб-сервер, в зависимости от запроса. Это и есть роутинг.
А роутинг "в современном понимании" потребовался потому, что пошла мода иметь "одну точку входа" и так называемые "SEO-пути". Тут определять, какой модуль должен отработать, т.е. выполнять роутинг, вынуждена уже эта самая одна точка входа, а функционал веб-сервера используется не полностью и только для того, чтобы всё вообще направить на эту одну точку входа.
IvanCher
31.08.2016 10:35Я согласен с Вами, но ведь время идет вперед и нужно хоть немного смотреть по сторонам. Напишите тогда стандарт для этого сервера, который отправляет на нужные скрипты. Или опишите стандарт для роутинга через фронт-контроллер. Я за любой из этих путей со стандартизацией/соглашением, но не за оба одновременно без.
Я не считаю, что дело именно в моде иметь фронт-контролер. Скорее фронт-контролер просто решает некоторые проблемы, которые в «первоначальном пути» решать было сложно, например контроль доступа.
Да, я знаю, как сделать компонент секьюрити, чтобы оставить при этом роутинг через веб-сервер, но тогда вылезет куча других проблем и вопросов. И опять таки, я буду знать, как это работает, но другой программист с ходу вряд ли в этом разберется. Возникает сразу проблема поддержки проекта и его развития. Документацию на всё не напишешь, а если напишешь, то php уже теряет своё преимущество в скорости разработки.
В итоге придем всё ровно к тому, что если core-team не хочет решать это и как-то стандартизировать, то будем куча разнородных решений, некоторые из которых будут стремиться стать максимально универсальными, и лучшие именно из универсальных решений будут повсеместно использоваться.merlin-vrn
31.08.2016 10:44-1Что значит стандарт сервера? Обычный маппинг URI->fs 1:1. Есть путь /home/user/site/docroot/ — он виден как example.com/. Всё, нужен нам модуль /home/user/site/docroot/sub/module.php — отправляем на example.com/sub/module.php.
Это было с самого появления HTTP. Ну, да, тонкость возникает, что здесь php-файл не отдаётся непосредственно как есть, а выполняется сервером, но я слышал что эту задачу вроде бы уже научились решать.
Причём, никто не заставляет вас держать вообще всё в пределах docroot — там нужно только то, что может быть запрошено легально через веб-сервер. А что касается контроля доступа — так опять же, аутентификацию сваливаем на веб-сервер, он же умеет http basic auth, а можно и вообще по клиентским ssl-сертификатам или через kerberos, а дальнейший контроль так и так будет выполнять сам модуль.IvanCher
31.08.2016 11:06Стандарт значит, что сервера, которые мапят урл с php-скриптом должны соответствовать установленным поведениям, файлы конфигов должны для этого быть как-то унифицированы. Это поведение должно учитывать нужды программ, для которых предназначается данный ЯП.
Обычный маппинг URI -> fs — явно не учитывает огромное кол-во нужд, которые важны людям, использующим php сегодня.
В итоге опять каждый будет пилить свой велосипед. Я понимаю, что многих php-программистов это не напрягает, потому что они даже не подозревают, что программист может не однотипные задачи кодить, а концентрироваться на решении бизнес-задач, не отвлекаясь на то, как бы это реализовать, чтобы другие могли понять и было легко поддерживать в долгосрочной перспективе.
HTTP-Auth, хорошо. Пусть кор-тим скажет, чтобы разработчики его использовали, тогда сразу всем станет ясно, что php только для динамической генерации html, и никакую бизнес логику в него пихать не следует. Секьюрити включает в себя не только аутентификацию, но и авторизацию, под которую опять каждый будет изобретать свой велосипед.
Всего, чего не коснись в php, нуждается в том, чтобы писать свой велосипед… И еще этот Расмус делает настолько глупые заявления, говоря, что фреймворки общего назначения полный отстой.merlin-vrn
31.08.2016 11:12Так авторизацию в любом случае каждый модуль будет делать себе сам, как ни крути. Подумайте сами, как фреймворку будет известно, кто и к чему имеет права доступа? Только если мы ему об этом расскажем в виде кода. А поскольку в каждом модуле набор защищаемых объектов, возможных действий с ними и соответственно возможных разрешений и тому подобного — свой, имеющий смысл только для этого модуля — то в каждом модуле это будет свой код.
IvanCher
31.08.2016 11:25Погодите, мы сейчас говорим не о фреймворке, а об ЯП php. Пожалуйста, не называйте его фреймворком, это выглядит очень странно :)
Например, ЯП может предложить помечать определенные методы некоторыми токенами. Как? Да без разницы, хоть через анотации.
При вызове методов мы можем проверять эти токены и вызывать привязанные к ним обработчики, которые будут реализовывать определенный интерфейс. (Понимаю, что в php мало кто знает, что существуют интерфейсы, которые могут очень сильно помогать в стандартизации).
Или можно реализовать простейшую событийную модель, которая для помеченных методов будет вызывать слушателей, а для остальных — выполнять, как есть. На производительности это особо не скажется.
Я уже придумал 2 достаточно абстрактных и универсальных решения за 5 минут. Этого не могут сделать разработчики ЯП? Я честно, не знаю какие цели ставит перед собой тот, кто заведует развитием php, но подозреваю, что точно не цель сделать всё легким в поддержке.
Я еще раз повторю, что я реально ЛЮБИЛ php, потому что у него есть свои плюсы. Но сейчас его тащат в ту нишу, где он смотрится просто смешно и нелепо. На данный момент он может закрепиться в этой нише ТОЛЬКО благодаря фреймворкам, типа Symfony2, но и тут Расмус вставляет им палки в колеса своими нелепыми высказываниями.
Честно, я не понимаю, куда идет php, и всё больше и больше боюсь делать на нем проекты, которые придется поддерживать и развивать 5+ лет.
Bkmz
30.08.2016 18:28-1PHP — это шаблонизатор. Все остальное появилось сильно позже…
vshemarov
30.08.2016 18:50+6Все остальное появилось сильно позже…
В т.ч. и сам термин — «шаблонизатор»
michael_vostrikov
30.08.2016 19:53+2От шаблонизатора в PHP только теги
<?php ?> / <?= ?>, и конструкцииinclude / require. Все, что внутри тегов — язык программирования.
bentall
30.08.2016 18:32+3Статья, повторю уже сказанное, более чем спорная. В сумме с отсылкой к авторитету создателя PHP Расмуса Лердорфа, хотя за ним Гутмансу и Сураски не только пришлось переписывать код, который им, цитирую «очень не понравился», но и исправлять многочисленные ошибки в дизайне языка, звучит как призыв «назад к PHP 3» (если не к PHP/FI). Хотя мысль «без фанатизма» сама по себе и здрава, но здесь похоже предлагается подменить фанатичное следование «современным стандартам разработки» чем-то из 90-х (да и сама статья написана достаточно, гм…, фанатично). А это куда хуже, те, кому приходилось работать с legacy PHP кодом «старой школы» меня поймут. Бесспорен тут только призыв писать безопасный код и большая часть рекомендованной литературы.
merlin-vrn
31.08.2016 10:25Да глупы наезды эти. Гутманс и Сураски потребовалось всё переписать потому, что они решили приспособить язык для другого, не для того, для чего он изначально предназначался. Это нормально: решил занять другую нишу — приспосабливайся. Жаль только, что они имя не стали менять — меньше было бы сейчас пересудов.
bentall
31.08.2016 11:32Ну как для другого. Для веб-программирования. Разве что сместили акценты с «программа-шаблонизатор чтобы добавить какую-никакую динамику» на «язык программирования». При том, что судя по тому, что они писали (причём не на форумах/в рассылках, а в предисловиях к книгам), сам по себе исходник расмусовского php был, скажем так, legacy-style, что к назначению языка уж точно никакого отношения не имеет. Ну и в том, что касается проектирования языка, пусть даже в рамках реализации шаблонизатора у PHP были неудачные захардкоденные решения… В общем если кто помнит историю языка (лучше — на своей шкуре) те в курсе.
>Жаль только, что они имя не стали менять — меньше было бы сейчас пересудов.
Ну они долго поддерживали совместимость со многими из этих самых неудачных решений, хотя и объявили их depricated.
sbnur
30.08.2016 18:46+1Любой фреймворк — это форма организации мышления для выражения желаний
Можно ботать по фене, можно читать лекции, можно торговаться на базаре — мы владеем этими формами выражения и не думаем, что есть некий незамутненый руссский язык
Поэтому фреймворки полезны, и их полезно знать, хотя бы для того, чтобы иметь широкий кругозор мышления
Как сказано в одной мудрой книге — узкий специалист подобен флюсу — его полнота односторонна
DexterHD
30.08.2016 19:08-9PHP собщество в лице http://www.phptherightway.com/
против
Mail.ru Group в лице http://www.phpthewrongway.com/
Пожалуй выберу первое…
NikitaStrelkov
30.08.2016 20:34+3Mail.ru Group то тут чем провинились? Они только статью перевели же.
planarik
30.08.2016 20:00+5Я даже знаю успешный коммерческий продукт, разработчики которого следуют этим советам :)
Только хорошо ли он внутри?
sumanai
30.08.2016 20:26+2Фреймворк — это не просто набор многократно используемого кода: вы не сможете вырезать кусок из фреймворка и вставить его в проект.
Последние фреймворки придерживаются компонентного подхода, и выдрать оттуда что-либо не составляет труда.
xfg
30.08.2016 22:34+1Да, symfony явно ломает представление автора о фреймворках.
sumanai
30.08.2016 23:05+1Да не только симфония. Тот же Zend с третьей версии компонентный, да и с остальные идут в туже сторону. Можно быстро собрать фреймворк под свои нужды из компонентов других фреймворков и независимых (типа FastRoute).
velvetcat
30.08.2016 21:43-1Какой отборный бред. Надеюсь, автору полегчало.
P.S.
> В этой статье мы различаем фреймворки и библиотеки по следующим признакам:
> Библиотека — это набор многократно используемого кода.
> Фреймворк — это не просто набор многократно используемого кода
OMG. Хватит придумывать. Библиотеку вызываете вы, фреймворк вызывает вас, результат зависит от разработчика.
dcc0
30.08.2016 22:07-7Статью полностью не прочитал, но автора понимаю.
Приветствую текст и считаю появление таких статей позитивной тенденцией.
AlexLeonov
30.08.2016 22:18-5Еще один критик-теоретик (см. его активность: https://github.com/binarygenius?tab=activity ) решил заработать себе баллов на критике PHP.
Видимо каждый начинающий программист должен написатьдейтинг на PHP, свою CMSсвой фреймворк и покритиковать PHP. ОК. Примем это просто как должное. Все должны через это пройти. Переболеть, как ветрянкой в детстве. И лучше в детстве, поверьте, очень печально смотреть, как взрослый мужик болеет ветрянкой (или критикует PHP).
А мы, практики, пойдем дальше использовать этот язык для решения бизнес-задач. Которые, надо отметить, он решает быстро и очень качественно. Кому не нравится — можете и дальше писать статьи о том, какой PHP плохой и какое у него омерзительное сообщество.
dcc0
30.08.2016 23:17""«Не надо всё делать самостоятельно, об этом уже позаботились более опытные»"
У этого лозунга довольно глубокие корни.
Flammar
31.08.2016 03:11Сегодня одно из главных преимуществ PHP — поддержка императивной, функциональной, объектно ориентированной, процедурной и рефлективной парадигм.
Императивная, функциональная и процедурная парадигмы вполне легко и сравнительно удобно и с небольшим оверхедом эмулируются на объектно-ориентированной. А знаменитая тема шаблонов проектирования на 70-80% состоит из эмуляции функционального программирования с помощью объектно-ориентированного программирования.sumanai
31.08.2016 20:32Так и объектно-ориентированную парадигму можно эмулировать на функциональном.
stychos
31.08.2016 04:02+2В очередной раз переписывая один недопоисковик, я вообще на минутку заумался, что стало как-то слишком много абстракций и ненужного ООП, и что можно сделать куда короче, проще, в лоб, да и на обычных функциях, и количество кода сократится раз в десять, и прочесть и удержать в голове его станет реальнее…
stychos
31.08.2016 04:09Но потом, на всякий случай, заглянул на секунду в исходник моего «любимого» Vicidial, чтобы поскорее протрезветь.
lookid
31.08.2016 04:04Расмусу нужно пофрилансить годик, сразу одумается. 3 коммита за полгода и 1млн $ в кармане, это не 3 магазина за месяц и хотя бы 100к в кармане.
sav1812
31.08.2016 04:15+4Ну, было бы нужно — наверняка же «пофрилансил» бы, верно? :)
И потом, сколько, в плане ценности для (со)общества, «весят» его коммиты, и сколько — те три магазина? Вопрос риторический. :)
KlimovDm
31.08.2016 08:59+2Жаль, что никто никогда не напишет о phpthemiddleway, просто потому что это ближе к практике, чем к теории.
FractalizeR
31.08.2016 10:47В мире Python и Ruby создание веб-сайтов с нуля — занятие довольно утомительное, поскольку эти языки для создания веб-сайтов не предназначались.
А PHP Расмус Лердорф изначально создавал как набор инструментов, написанных на С, позволяющих легко и быстро разрабатывать динамический HTML. PHP таким задумывался и таким остался, он сам и есть фреймворк.
А можно немного подробнее? В чем именно PHP является фреймворком и что именно в нем реализовано настолько лучше, чем в Python и Ruby? Я только поверхностно знаком с двумя последними, но не помню там ничего такого, в чем PHP их превосходил бы на голову.
Ogra
31.08.2016 11:00+1Если сравнивать голые языки, то шаблонизатор, конечно же, и работа с формами в PHP в разы лучше того, что в других языках.
Но вот если брать не голые языки, а фреймворки, то эта разница не играет существенной роли.FractalizeR
31.08.2016 12:02Мне кажется, что то, что есть в PHP по работе с формами и выводом данных, не дотягивает до звания "фреймворк". Думаю, автор преувеличил.
Ogra
31.08.2016 12:05+3Когда PHP только появился — это был ого-го какой фреймворк! =) Сейчас этого, конечно, мало.
nitso
31.08.2016 11:24Уместным был бы тэг «провокация» или дисклеймер «сарказм». Если бы не цитаты Расмуса. Нуместные.
Ощущение, что статья опоздала на полдесятка лет.
varanio
31.08.2016 11:32+2Статья скорее вредная.
Только php начал выбираться из ада легаси-говнокода и тут опять — пишите свои велосипеды вместо фреймворков. Блин.
Более грамотный подход — использовать фреймворк, а то, что в нем не нравится — менять на свои части. Или выдергивать компоненты симфони и строить из них что-то своё. Но не писать всю эту фигню с нуля.
Когда пишешь с нуля — получается не так качественно, не так протестированно, не так гибко, не так документированно, как взять готовый компонент фреймворка.
К словам Расмуса я вообще отношусь настороженно. Когда было голосование по отмене magic_quotes, Расмус голосовал против отмены. Человек явно не совсем в теме промышленной разработки
demin
31.08.2016 11:56+3Мне одному кажется, что вся статья это просто жирный троллинг?
«All general purpose PHP frameworks suck» — кто-нибудь вообще гуглил эту фразу?
G-M-A-X
31.08.2016 12:03-5Читал в оригинале.
Как бальзам на душу :)
AloneCoder добавьте, пожалуйста, перевод на гитхаб, откуда переводили.
wartur
31.08.2016 13:14Не пойму нахрена писать свой велосипед поддерживать свой фреймворк… Считаю что правильно писать так, что бы было как можно меньше зависимостей с одной стороны но если есть зависимости, то к ним надо коннектиться так, что бы они максимально долго могли обновляться… самое дермовое когда твое приложение не сможет обновить зависимости — вот когда динь динь с признаками, «что-то тут не так»
dcc0
31.08.2016 14:06+2Пока программисты философствуют, спорят, любуются, ошибаются, я спокоен за программистов.
SamDark
31.08.2016 14:11+2Цитату Расмуса вырвали из контекста. Он её произнёс на PHP frameworks day 2013 в Киеве отвечая на вопрос. Там главная цель — посоветовать авторам фреймворков, как можно оптимизировать production-режим их работы. Это было вполне уместно, учитывая направленность конференции и присутствие разработчиков многих популярных фреймворков.
Вот полное видео, чтобы контекст понять: https://www.youtube.com/watch?v=anr7DQnMMs0
youROCK
31.08.2016 16:31-3Надо было перефразировать так: все фреймворки под PHP, кроме Yii — полное дерьмо ;)
SamDark
31.08.2016 16:52+1В том контексте, скорее, надо было упомянуть ReactPHP, хотя это всё-равно немного не то, о чём Расмус говорил. Его идею можно реализовать генерацией оптимального кода типа как Composer autoload-классы генерит.
WarAlex
31.08.2016 14:56+3Не понимаю, зачем столько копий ломать вокруг этой статьи. Если отбросить всю воду, то смысл статьи очень простой «Выбор инструментов должен зависеть от конкретной задачи, а не от крутости и популярности инструментов». И это абсолютно справедливо, я считаю.
Если использование конкретного фреймворка реально упрощает решение задачи, то замечательно. А если вы за уши притягиваете фреймворк ради «я использовал модный и популярный фреймворк, я крут» то гнать вас в шею.
То же самое про подгон каждого чиха под шаблоны проектирования ради того, чтобы доказать всем, что эти шаблоны знаешь.
То же самое про ООП — «все ооп пишут, скажут что я лох, если не использовал ооп в своем скрипте на 10 строчек».
Если у вас есть мега крутая болгарка, которую все хвалят и вам нужно спилить ветку яблони на даче, то странно будет, если вместо того, чтобы взять старую ножовку, вы повезете на дачу дизель-генератор чтобы подключить к нему модную болгарку, правда ведь?skyeff
02.09.2016 10:49Любые аналогии ложны. Можно сказать и так: «если у вас на даче есть болгарка с генератором, зачем ехать в город за ножовкой?!».
faost
31.08.2016 15:20+3Бред.
Если ты годами пилишь один проект в маленькой команде, то может и ОК. В реальности люди уходят/приходят, проекты меняются.
Из практики:
- Получил недавно проект на plain php — неделька нужна только чтобы вникнуть в идеи, которые автор закладывал при проектировании приложения. При очередном коммите реально боишься сломать что-то, серьезно что-то поменять в архитектуре не поломав половину просто нереально.
- Получил в наследство проект на Yii2 — пару дней на погружение, и то, потому что автор много уходил он стандартов, описанных в документации.
- Получил в наследство проект на Symfony — пол дня понадобилось чтобы войти в проект и делать реальные задачи.
dezconnect
31.08.2016 17:16Бывает абсолютно по разному, приходилось видеть творения написанные Java программистом на PHP + Symphony к тому же еще и первой. Вместо объяснения предметной области человек при передаче проекта углубился в «Тут у меня адаптерс фабрикой и работает это вот так.». Хотелось не просто матерится а бить по голове. Так как то что там фабрика мы и так увидели.
В то же время довелось работать в одной весьма мощной команде, свой фреймворк с нуля (даже два, гы), и всё настолько понятно и внятно что Yii/Symphony/Zend показались гипертрофированными гориллами. (при этом где-то пол дня чтобы въехать в это всё, но я сам автор фреймворка поэтому фреймворк для меня уже не имеет значения особого, главное понять чем руководствовался человек при его построении а дальше как по накатаной)
Так что… все очень по разному.
zelenin
31.08.2016 17:32вы правы абсолютно. Надо понимать, что в основная масса кодеров на фреймворках подыскивают design pattern для задачи, а Программист ими думает, потому что знает для чего они нужны и как они помогут удобно и гибко архитектурно решить задачу.
Поэтому отказ от фреймворка возможен и нужен только в случае команды очень опытных классных специалистов, которые читают приложение как азбуку.
Программистам же пока далеким от понимания архитектуры следует решать проблемы на фреймворке, который в данном случае уместнее перевести не как «каркас», а как «рамки» — рамки, которые не позволят уйти далеко от более-менее приемлимой архитектуры приложения.
PS ошибся веткой. ответ на коммент dezconnect https://habrahabr.ru/company/mailru/blog/308788/#comment_9781340DrPass
31.08.2016 18:10> Надо понимать, что в основная масса кодеров на фреймворках подыскивают design pattern для задачи, а Программист ими думает
У вас как-то недостаточно понтов в слове «Программист». Надо ещё вензелей добавить, золотые ленточки и всё такое. А кодеров наоборот, уменьшить, и коричневым цветом.
А если без шуток, то обычно никто ничем не думает. У всех есть какой-то привычный и хорошо изученный инструмент, и именно его и выбирают. Критерий «привычный» используется в подавляющем большинстве случаев. Ну, кроме тех, когда разработчик вообще непрофильный, и у него в принципе нет привычного фреймворка для данной задачи. Вот непрофильные как раз и начинают сравнивать, перебирать, критиковать :)zelenin
31.08.2016 18:18+1никаких понтов. Просто попытался программистов чуть-чуть поделить на тех, кто начал мыслить архитектурными понятиями и еще нет. Первые могут думать в ключе «доктрина решает все проблемы работы с сущностями», вторые могут думать так: «доктрина решает все проблемы работы с сущностями, я знаю все эти проблемы, знаю какой оверхед добавляет доктрина, знаю как архитектурно организовать работу, поэтому реализую все сервисом, репозиторием и pdo».
faost
01.09.2016 11:52В моем понимании это не архитектурное решение, а просто оптимизация памяти/скорости, при этом с усложнением дальнейшей поддержки кода.
Как раз 2 параллельных проекта сейчас, один с PDO, другой с Doctrine. Вроде PDO и быстрее, но поддержка похожего кода заметно усложнилась. В проекте с Doctrine и Symfony там где нужно что-то реально быстро сделать, это делают демоны на Go. Писать их проще, чем plain php, а производительность в десятки-сотни раз лучше.
ComeClarity
01.09.2016 10:31+1Статья натолкнула на воспоминания лекций по программированию с теорией, которая имеет право жить только в
параллельной вселеннойуникальных условиях и контексте, где люди программируют от скуки чтобы развлечься, где позволено выбирать между оптимизированным, полностью адаптированным решением под конкретную задачу и полуготовым шаблоном на костылях. Возвращаясь в суровые реалии, где ваши задачи порождает бизнес, а ресурсы имеют конкретные ограничения, пока мы будем писать «с нуля», конкурент с помощью пары команд в терминале займет нашу ЦА и заработанные деньги заинвестирует в 10 стажеров-студентов, которые на очередном «адском» фреймворке запилят фичи, которые мы только успели добавить в бэклог. Этот комментарий не о PHP, он о том, что каждое подобное решение (фреймворк? стандарт? безопасно? подход?) принимается под давлением большого количества факторов (за исключением фактора: потому что мейнстрим).
spmbt
01.09.2016 21:56Автор (в ЛС 2 дня нет ответа про искажение смысла перевода): в конце статьи у вас:
Чтобы прийти к идеям, мыслям и решениям, отражённым на нашем сайте, не требуется большого опыта, если вы всегда делаете то, что говорят другие.
В оригинале:
Чтобы прийти к идеям, мыслям и выводам, отражённым на нашем сайте, не требуется большого опыта, если вы просто сосредоточены на этой теме, в которой отдельные вещи всегда делаются традиционно (или: «так, как говорят другие»).
А у Вас по смыслу «говорят другие» перенеслось на человека, автора. Да и ещё почему-то «всегда». Другими словами, грубо: «если у вас никогда своих решений не было, вы придёте к этим идеям и мыслям, что на сайте». Вот эта бессмысленность фразы и заставила меня взглянуть в оригинал: ).
(The ideas, thoughts, and conclusions expressed on this website doesn’t take much experience to reach if you just stay focused on the main theme which is to always do a particular thing because other people says so.)
index0h
02.09.2016 10:37+1Спасибо за перевод
Удивительно, как много текста требуется, что бы сказать "Здравый смысл — превыше всего".
Неправильный путь: всегда использовать фреймворк поверх PHP.
Если пишешь маленькую либу для преобразования строк, или что-то типа того — ясное дело, что фреймворк тебе не нужен, он просто не будет использоваться. Если же фреймворк, как набор инструментов реально помогает жить — не пользоваться этим глупо.
Фреймворк — это не просто набор многократно используемого кода: вы не сможете вырезать кусок из фреймворка и вставить его в проект.
После этой фразы где-то в мире грустит один Фабьен.
Компании сталкиваются с тем, что фреймворки общего назначения плохо помогают решать конкретные задачи, к тому же очень медленно работают.
Если фреймворк не помогает решить задачу — он не подходит для этой задачи. На счет медленности фреймворков: PHP — язык быстрых решений, а не быстрых систем.
Но в любом случае вы добавляете в код новый уровень сложности, который совершенно не нужен!
Лолшто? Нужен, или нет — это зависит от проекта и его бизнес требований.
Когда мы пытаемся решать разные проблемы в рамках приложения с помощью одной конкретной парадигмы программирования, мы перестаём творчески мыслить и эффективно работать.
Когда мы начинаем творчески мыслить и внедряем множество парадигм в действительно крупном проекте мы становимся золотарями.
Неправильный путь: искать шаблон для решения проблемы.
Если твою проблему решили 100500 раз — так как раз таки надо поискать как.
Неправильный путь: всегда использовать объектно ориентированное программирование.
Когда PHP станет чисто ФП языком — тогда согласен. (Это не касается проектов на 5-50 строк, там в принципе все равно)
Неправильный путь: бояться кода, написанного другими.
Но обезопасить свой код от дурака — таки надо))
Однако если мы посмотрим на работу нескольких участников группы, становится очевидно, что реальная цель полностью противоречит заявленному.
Заговор, заговор! Где моя шапочка из фольги. Если стандарты есть — это на порядки круче, чем если их нет.
Если и нужна какая-то группа, то её стандарты должны отражать интересы всего PHP-сообщества, а не одних лишь разработчиков фреймворков и open source CMS проектов.
Зачем так ограничиваться?)) Нужна группа, которая поможет всему человечеству))
Во многих сферах требуется высокомасштабируемое, критичное ко времени выполнения, экономически выгодное ПО, которое просто невозможно создать, если следовать стандартам PHP-FIG.
Еще бы, на других языках PSR-* поддерживать скорее всего будет проблематично. Повторюсь PHP — язык быстрых решений.
Неправильный путь: следовать стандартам PHP-FIG, за исключением PSR-1 и PSR-2.
А как же PSR-5, PSR-12?)) Если стандарт не противоречит бизнес требованиям проекта И дает плюшки — глупо им не пользоваться.
Неправильный путь: не разрабатывать приложение безопасным по умолчанию.
Печаль, такое хорошее было начало, и такой вывод… Неправильный путь: вспоминать про безопасность по умолчанию после того как вас хакнули на тролололиард денег.
index0h
02.09.2016 13:16Неправильный путь: не разрабатывать приложение безопасным по умолчанию.
Посыпаю голову пеплом, тут 2 "не", я же прочитал с одним))
Alexufo
Вот тут нужно по полочкам. Разве не спрос рождает предложение, а не наоборот?
Нет ни у кого общих проблем?)) А что же тогда решают фреймворки, хочется спросить, не общие ли проблемы и велосипеды?)
Очень специфические проблемы есть только в научных центрах. Все остальные живут на общем рынке, с одинаковыми задачами — производство либо барыжничество.
Если родиться уникумом, коих можно пересчитывать по пальцам в современном мире, те действительно не решают общие проблемы в силу магии своей личности. А для всех остальных доширак в обед и фреймворки.
Alexufo
продолжу.
Согласен. Но с какого момента начинаются сроки кода?) С момента запуска машины под операционной системой? Или с момента установки и конфигурации вебсервера, ведь ничего просто так у вас не заработает. Всегда есть готовые продукты, слои, на которых мы сидим и думаем только о своих маленьких строчках кода. Фреймворк тут такое же звено как и все остальное.
Единственный минус всех свистоперделок — производительность. Никто бы и критиковать не подумал бы, как не думают критиковать клавиатуру что она медленно «выдает» буквы.
holy_finger
Насчет скорости тут как. Чтобы она стала играть роль, надо чтобы именно фреймворк стал узким горлышком.
Зачастую узкое горлышко в других аспектах.
Какая разница мне, если фреймворк тормозит при миллионе пользователей, если у меня на сайте в день 100 человек?
DrPass
> Разве не спрос рождает предложение, а не наоборот?
Изначально, когда-то давно, спрос рождал предложение. Но потом родился первый в мире маркетолог, и он понял, что спрос можно (и нужно) формировать под своё предложение. И стал набирать популярность обратный вариант.
Alexufo
да. но в зоне потребления, потребительских товаров. А профессиональная область хоть этому и подвержена, но куда менее. Поскольку тут товар, потроха и оболочка, непосредственно представляет область проф. интереса.
merlin-vrn
Видите ли, разработка на PHP — сама по себе массовая область, и здесь имеется всё: маркетологи, реклама, и так далее. И товаром тут являются в том числе фреймворки
, а также мартышки, которые их бездумно используют. Мартышек здесь особенно много, потому, что порог вхождения низкий.SamDark
Подвержена ещё как. Посмотрите, что сейчас происходит на рынке PHP-фреймворков. Это сотворено прежде всего руками хороших маркетологов.