The MicroPHP Manifesto

[@skywatcher]

Автор слишком сконцентрировался на PHP, в то время, как это применимо к программированию в общем.

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

[@80x86]

Автор слишком многословно говорит о том, что нефиг из сверхскоростного шаблонизатора делать очередной бриллиант на канатной дороге.

Разные цели, разные ниши, разные идеологии.

ЗЫ. Не переношу Zend FW.

[@aeryaguzov]

Зря(

[@aeryaguzov]

В смысле зря не переносишь Zend, просто ты не смог его понять(

[@80x86]

Думаю, 12 лет теребления PHP для этого достаточно :)

Поверь, я его понял.
Но принять этот страшный кусок сплава перла, плюсов и лени не смог.

[@aeryaguzov]

И тут кроме кидания говна в сторону ZF я хотел бы услышать хоть один аргумент против…

[@80x86]

*пожимая плечами*

Понимаешь, в любой профессии есть некоторый порог, после которого восприятие мира меняется с аргументально-инструментального на сенсорно-интуиционное.

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

Я это к чему?

Если хочется, то придумай типичную задачу и реализуй её с помощью нескольких инструментов типа ZF, симфонии, уии, кисса, whatever-you-want. Ну и до кучи ­— с помощью современных конкурентов PHP (естественно, «конкурентов» в широком смысле слова — инструментов, ковариантных PHP на множестве околовебных ниш) типа Эрланга с Нитрогеном, Руби с Рельсами или Пайтона с приснопомянутым Джанго.

Мне заниматься этой формализацией ощущений обратно в стотысячный раз уже не хочется.

[@VolCh]

Я тоже не смог его понять. Symfony (1 и 2) смог, Cake тоже. CI и ZF — нет.

[@taliban]

Раз на раз не приходится, я вот работал и с зендом и с кодеигнитером, и считаю второе плохим поделием, в отличии от первого. Так что я бы сказал что это на любителя.

[@mjr27]

Я, наверное, и сам зенд не понял. А именно, я не понял, зачем было выпускать фреймфорк, сочетающий в себе худшее из java-style oop и old-style php (<?php echo htmlspecialchars($this->_app->getTitle), ENT_NOQUOTES); ?> WTF?), когда на дворе уже наступили 2000е
/holywar

[@aeryaguzov]

Я поведусь на твой холивар:-)

Примеры «худшего из java-style oop»?

<?php echo htmlspecialchars($this->_app->getTitle(), ENT_NOQUOTES); ?> — в чем здесь проблема?

[@dfuse]

Помесь ООП и глобальной функции, вызываемой к тому же с флагом. $this->_app->getTitle()->getEscaped() было бы уже гораздо лучше.

[@aeryaguzov]

Вообще в Zend_View есть escape и правильно записывать вот так:

<?php echo $this->escape($this->headTitle()); ?>

Мне стало интересно откуда был взят код: <?php echo htmlspecialchars($this->_app->getTitle(), ENT_NOQUOTES); ?> поэтому специально сначала спросил:-)

[@dfuse]

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

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

[@taliban]

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

[@dfuse]

Да я и не про фреймворк, я ж только о том куске.

[@mjr27]

Да как-то ковырял один проектик, в нем было написано примерно таким образом.
Но <?php echo $this->escape($this->headTitle()); ?> дела особо не меняет, длина и понятность ужасает.

Я вообще от фреймворка ожидаю самоэскейпящегося <?=$title;?>, но в php это прозрачным образом нереализуемо (оборачивая строку в объект мы лишаем себя простых и понятных вещей типа if($title))

На худой конец, рельсостайл <?=h($title);?>, но это не зенд вей )

[@dmitry_dvp]

Вы тоже из тех, кто не разобрался

Эта конструкция

<?=$this->headTitle();?>
даёт
<title>...</title>

Эскейпленный, естественно

[@VolCh]

Есть __toString. Для самоэскейпинга прозрачно.

А if ($title) как раз не прозрачно, имхо — нужно знать правила приведения строки к булю и понимать что условие сработает если title равно '0' (да ещй написать в user guide «заголовок поста должен быть непустым, не более 100 символов, и не символ 0»). Предпочитаю явное сравнение (empty(), увы, тоже не очевидна).

[@mjr27]

мы, наверное, друг друга не поняли. проблема с __toString в том, что если оборачивать выводимые переменные в объект, то… объект всегда приводится к true, нету в php контроля приведения к bool.
писать вокруг этого свои конструкции if($title->toBool()) — тоже приятного мало.
может я где-то чего-то недопонял, но сделать вменяемый самоэскейпинг, не ломающий никаких распространенных конструкций я в свое время не осилил.

P.S: также немало попоболи мне доставила реализация массивных интерфейсов. Казалось бы, объект себя ведет как массив, реализует все как массив, крякает как массив, ан нет, is_array($obj) == false :)

[@VolCh]

toBool() это ещё ладно.Вот конкатенацию…

[@GearHead]

в том, что в нормальном фреймворке это выглядит так:

<%=h title %>

[@aeryaguzov]

В ZF это выглядит так: <?php echo $this->headTitle() ?>,

а с директивой short_open_tags=On так:<?= $this->headTitle() ?>

[@GearHead]

ага. давайте эскейпить символы прямо в контроллерах.

[@aeryaguzov]

Какие контроллеры, О-О) Все делается во вью

[@GearHead]

где объявляется $this->headTitle()?

[@Disturbed]

это view helper

[@dfuse]

В Yii $this в шаблоне смотрит именно на контроллер

[@taliban]

А в зенде это вид, что логично.
Где я? В виде, $this — вид. В контроллере, $this — контроллер. В модели, $this — модель.

[@ainu]

Ребят, кому хочется открывать в ide класс View и ручками писать htmlspecialchars (whatever)?
Хочется {title|h} и работать дальше.

[@VolCh]

А не <?php echo $this->headTitle($title) ?>?

[@AndrewStephanoff]

Поддерживаю, после того, как посмотрел на ZF 2, мне проще на Java веб-приложение создать.

[@80x86]

Да на чём угодно, не обязательно на Java.

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

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

[@AndrewStephanoff]

На Java — потому, что уж сильно на Spring похож.

[@AndrewStephanoff]

точнее — на попытку

[@aeryaguzov]

Очень жду пример страшной и неудобной реализации какой-нибудь идеи из ZF2!

[@80x86]

*во второй раз пожимая плечами и улыбаясь*

Лучший пример страшной и неудобной реализации какой-нибудь идеи из ZF2 — сам ZF2.

[@aeryaguzov]

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

Приведите пример, если не сложно!

[@truezemez]

«Я думаю, что PHP достаточно сложен» — в оригинале «I think PHP is complicated enough». Возможно здесь я неправильно перевел. Без контекста тяжело уловить суть. Я думаю, что автор имел ввиду нечто другое.

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

Я думаю, что истина, как всегда где-то посредине.

[@Svyatov]

Тогда скорее имеется в виду «Я думаю, что PHP и так уже достаточно сложен».

[@easterism]

имеется ввиду, что сложности PHP уже достаточно для возлагаемых на него задач

[@Zharskiy]

по крайней мере он честно говорит «ниасилил»

статью надо было перевести «Манифест школоты»

[@truezemez]

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

[@Anton_Gorodezkiy]

Буквально недавно хотел попробовать один из микрофреймворков и остановился на KissMVC.
Да, приятно. Да, заманчиво. И фрейм хорош, как по мне.
Но после того, как я стал замечать, что вручную пытаюсь написать реализации некоторых вещей, которые уже встроены в CI (не реклама, но предпочтение), я бросил идею о микрофреймворках. На мой взгляд минимализм тоже должен быть оправдан.
Хотя бесконечным return array( внутри Yii я тоже не рад и очевидности коду, мне кажется, это не придает.

[@noRerih]

Мой мозг орет:
FUCK.
THAT.
SHIT.
(не смог подобрать лучших слов – прим. переводчика)

НАХУЙ.
ЭТО.
ДЕРЬМО.
(хотя точки после каждого слова смотрятся странно)

[@truezemez]

Спасибо. Я думал о этом варианте, но не рискнул.

[@maxvodo]

Раньше (может годик назад) был прикольный проект именно такого плана phpKISS (Keep It Simple Stupid), однако сейчас гугл предлагает создать новый проект с этим именем, видимо проект умер. Не знаю, как проверить, вот этот проект — это он же?

[@ksenobayt]

Мой мозг орет:
FUCK.
THAT.
SHIT.

ЕБИСЬ
ОНО
КОНЁМ

— на мой взгляд, самый близкий по смыслу аналог.

[@Elfet]

А мне наоборот нравится углубляться в изучение сложных библиотек и фремворком таких как Doctrine и Symfony.

[@akalend]

Полностью ЗА!

[@cawabanga]

Я, например, тоже из тех, кто недолюбливает слишком жирное абстрагирование от предметной области. У меня кровоточат глаза, когда мне приходится иметь дело с какой-нибудь джавой или там PHP+Symfony — куда ни глянь, везде мельтешат какие-то итераторы, фабрики, интерфейсы, ивенты, а что фактически делает этот код — остаётся загадкой. Тот случай, когда за деревьями не разглядеть леса.

Но с другой стороны, безо всего этого наваристого дизайна становится довольно уныло, если не сказать абсолютно невозможно, в условиях, приравненных к энтерпрайзу, когда одна система написана полусотней людей на пяти языках и вагоне 3d party компонентов.

[@aeryaguzov]

Мне печально слышать, что у php-разработчика являются загадкой «библейские» паттерны в стиле итераторов и фабрик(

[@samally]

Они просто нужны далеко не на каждом шагу

[@aeryaguzov]

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

[@VolCh]

Знать необязательно, главное использовать :) Знать нужно для коммуникации, если она не нужна, то можно и не знать.

[@atlete]

Не все же php разработчики такие.
К сожалению не все знакомы с паттернами.
Это не зависит от языка программирования.

[@aeryaguzov]

PHP я специально упомянул, потому что сам php-разработчик!

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

[@cawabanga]

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

[@mr_avi]

Я вот на Silex и Symfony 2 для маленьких — средних и средних — больших соответственно, подсел. Удобно тем, что микрофреймворк основан на компонентах макрофреймворка, таким образом что-то можно перенести, похожие подходи, схожий интерфейс.

[@Davert]

По отзывам разботчиков на рельсах, их любимая подработка — переводить разросшиеся Sinatra-проекты на Rails… Как вы знаете, Silex похож на Sinatra, потому смею предположить, что вскоре что-то подобное будет в среде симфони2 разработчиков )

[@nightstalker]

Разработчики youporn показали что на symfony2 можно делать большие высоконагруженные проекты. Так что за симфу не переживайте ;-)

[@aeryaguzov]

Баян! Об этом манифесте я читал в январе, но это не главное…

Вот мое мнение по этому поводу:

Любой, кто воспринимает этот манифест, как руководство к действию, НИКОГДА не написал ни одного серьезного большого проекта! Микрофреймворк хорош для микропроекта, выполняющего одну, две функции, но когда проект разрастается любой адекватный разработчик понимает, что он выходит за рамки микрофремворка, и идет дальше. Есть люди, которые не хотят идти дальше и пишут костыли, другие переделывают архитектуру.

[@aeryaguzov]

Кстати я смотрел Silex и первая мысль, которая у меня возникла: этот микрофремворк слишком избыточен для разработки простого проекта: DQL и Twig лишние — они скорее замедлят разработку, потому что разработчику придется учить язык для доступа к данным и язык шаблонов, вместо того чтобы делать работу.

[@AndrewStephanoff]

Никто не заставляет их использовать — в своё время я обошёлся простыми DAO классами и json в качестве view.

[@student_ivan]

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

[@ecl]

говорящий ник

[@AmdY]

Это всё лапша для бедных, нужно меряться не количеством НАПИСАННОГО кода фреймворка, а количеством кода который НУЖНО НАПИСАТЬ.

вместо всего описанного куска кода на ZF в реальности нужно написать
zf create project ProjectName

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

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

[@ferrari]

Да ну бросьте. Уж только не ZF хвалить в за кол-во кода требуемого от разработчика. Все его конкуренты, исключая симфонию, имеют в 2, ато и в 3 раза более компкатный синтаксис.
Это никак не уменьшает его крутости как готового ко всему фреймворка, но простота вызовов и краткость кода — не его конёк точно.

[@AmdY]

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

[@VolCh]

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

[@konsoletyper]

Ну вот почему-то некоторые думают, что чем больше кода, тем быстрее он работает. А это, на самом деле, не так. И микрофреймворки не должны отличаться высокой производительностью в задачах, крупнее hello world. Пример: роутинг. Есть набор шаблонов URL (регулярных выражений), которые привязаны к методам. Фреймворк проверяет, какому из шаблонов соответствует введённый URL, последовательно перебирая каждый из шаблонов и проверяя, соответствует ли ему URL или нет. При разрастании проекта таких шаблонов будет становиться всё больше и больше и время, нужное на роутинг, будет увеличиваться. Потому в идеале нужно сделать подход, принятый в утилите lex: составить конечный автомат, соответствующий всем шаблонам сразу, и каждому конечному состоянию приписать метод, который нужно дёргать при совпадении. Потом этот недетерминированный конечный автомат преобразуется в детерминированный и в итоге весь роутинг делается за один тривиальный проход по URL'у. Конечно, в PHP всё быстрее будет проверить несколько регулярок. А вот, например, в Java очень даже есть смысл сделать подобную оптимизацию. В случае с Java код фреймворка можно сделать ещё жирнее: сгенерировать байт-код. Так код фреймворка «жирнеет», время на запуск увеличивается. Зато всё летает. При этом, клиентский код никак не меняется — как был контроллер с аннотированными методами, так он и остался.

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

[@Aux]

Какой-то корявый у вас роутинг. Меньше кода — ВСЕГДА лучше производительность. Только в асме бывают исключения.

[@konsoletyper]

Неужто? O_o А я и не знал. Ну конечно же, все эти яйцеголовые парни пишут распределённую сортировку слиянием чисто ради выпендрёжа — нет бы написать простой пузырёк, который мало того, что простой и понятный, так ещё и быстрый, потому что всего три строчки. Ну или там все эти многочисленные СУБД — нет, чтобы как все нормальные люди просто искать по списку — они нагородили какие-то B-деревья, R-деревья, планы запросов. Конечно же, там всё внутри настолько жирное, что адски тормозит. Ну все мы знаем, что производительность сайтов сильно в БД упирается. Вон, какие-то жалкие 20 запросов на отрисовку страницы сделают, страница уже целую секунду рендерится. А оно вот, оказывается, почему так.

[@Aux]

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

[@konsoletyper]

При достаточно большом размере задачи асимптотическая сложность начнёт себя проявлять и алгоритм с меньшей асимптотической сложностью даст большую производительность на практике. Тем более, не всегда небольшая асимптотическая сложность даётся ценой накладных расходов на реализацию. Бывают ещё оффлайн-алгоритмы, которые предполагают постоянные или редко изменяющиеся данные на входе. Тогда, ценой некоторых расходов на препроцессинг, получаем быстро работающий (в том числе и практически) алгоритм. То, что я описал для роутинга — классический пример. Имеем задержку при старте (а преобразование НКА в ДКА — это задача со сложностью в худшем случае O(exp(n)), где n — число состояние, но на самом деле, это надо очень постараться сделать такую плохую регулярную грамматику), но при этом полученный автомат будет работатать со скоростью O(n), где n — размер URL. И практическая скорость будет очень высокой, т.к. если сгенерировать байт-код, выйдет простой цикл и несколько switch'ей.

[@Aux]

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

Одна строчка против тысячи классов всегда лучше. И оправдания тысяче классов нет.

[@konsoletyper]

Ну хотя бы потому, что регулярка — это нифига не регулярка, а разбухший монстр. Регулярки в Perl, PHP и много ещё где способны работать с надмножеством регулярных грамматик. Естественно, при этом асимптотическая сложность работы с такими регулярками будет уже не O(n). Разумеется, в чём-то вроде PHP или Perl смысла нет писать свой код для реализации конечных автоматов. А вот в случае с Java и C# очень даже есть, потому что они хоть и высокоуровневые, посимвольного разбора строк не боятся. Кстати, движки регулярных выражений в этих языках написаны на них же самих.

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

[@konsoletyper]

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

[@skiedr]

Давайте экономить время — и позволим фреймворкам работать за нас.
CakePHP save the world!

[@Prapor]

Степень сложности отладки растет пропорционально степени сложности Framework-a.
Большинство задач в веб не сложнее калькулятора.
Как сказал выше один человек
«За деревьями леса не видно.»
Мы превратили PHP из языка написания веб страничек в язык написания прикладного ПО.
Я солидарен с автором.

[@VolCh]

Может превратили потому что задача шаблонизации веб-страничек уже не востребована? Вернее, востребована только как часть веб-приложения, да и то зачастую решаемая на другом языке (пускай и его транслятор написан на php)?

[@Prapor]

ЗЫ.
Я хочу быть Грегом Джинном.