Comments 59
Пардон, но не удержался: «7 вызовов вместо 13, думаю можно говорить о 90% ускорении» Вот это математика)
+5
Вам какбе намекают, что в два раза — это на 50% быстрее.
На 90% быстрее — это значит, что было 10 секунд, а стало 1 секунду.
Ваш, КО.
На 90% быстрее — это значит, что было 10 секунд, а стало 1 секунду.
Ваш, КО.
-1
Задачка для третьего класса гик-школы:
Ваш код обрабатывал 1000 запросов в секунду. Затем вы его рефакторнули, и он стал на 50% быстрее. Сколько запросов в секунду стал обрабатываль ваш скрипт.
Ответ: 50% от 1000 = 500, следовательно, ваш код стал обрабатывать на 500 запросов в секунду больше. 1000 + 500 = 1500 запросов в секунду.
Задачка со звёздочкой: Сколько запросов станет обрабатывать ваш код при ускорении его ещё на 90%?
Ваш код обрабатывал 1000 запросов в секунду. Затем вы его рефакторнули, и он стал на 50% быстрее. Сколько запросов в секунду стал обрабатываль ваш скрипт.
Ответ: 50% от 1000 = 500, следовательно, ваш код стал обрабатывать на 500 запросов в секунду больше. 1000 + 500 = 1500 запросов в секунду.
Задачка со звёздочкой: Сколько запросов станет обрабатывать ваш код при ускорении его ещё на 90%?
0
Большинство гиков отчалило из класса, сразу после решения 1й задачки.
Гик != Отличник
Гик != Отличник
+1
Вы говорите о производительности, а не о быстроте выполнения. Подмена понятий.
Время выполнения одной операции — сек. (время)
Количество операций в секунду — оп/сек. (производительность, она же мощность в физике) (дробь тут очень важна)
Секунд на одну операцию: 1
Операция в секунду: 1
В два раза быстрее:
Секунд на операцию: 0.5
Операций в секунду: 2
Автор не пишет про ускорение, а не о приросте производительности.
PS: мощность — количество выполненой работы в единицу времени. Если бы вы вспомнили не о 3-ем классе, а хотябы о седьмом-восьмом, то точно бы осилили.
Время выполнения одной операции — сек. (время)
Количество операций в секунду — оп/сек. (производительность, она же мощность в физике) (дробь тут очень важна)
Секунд на одну операцию: 1
Операция в секунду: 1
В два раза быстрее:
Секунд на операцию: 0.5
Операций в секунду: 2
Автор не пишет про ускорение, а не о приросте производительности.
PS: мощность — количество выполненой работы в единицу времени. Если бы вы вспомнили не о 3-ем классе, а хотябы о седьмом-восьмом, то точно бы осилили.
-1
* Автор пишет про ускорение, а не о приросте производительности.
0
точно бы осилилилол, баттхёрт. ясно.
Вы говорите о производительности, а не о быстроте выполнения.оО
Вы здоровы? Производительность и «быстрота», она же скорость, в текущем контексте есть одно и то же, и все они выражаются в «чем-то за время» (например, км/ч, лол/мин, оп/сек). А то, что вы выражаете в секундах, это время выполнения, и о нём ни в оригинальном сообщении, ни в вашем нет ни слова.
Автор пишет про ускорение, а не о приросте производительности.Так, ускорение. Значит, меняется скорость, так? Скорость в чём измеряется? А, точно, это же то же самое, что и производительность в нашем контексте — оп/сек.
Перевожу на человеческий: ускорение на 90% значит, что скорость возросла на 90%, то есть, например, со 100 до 190 км/ч. Вот если бы речь шла об уменьшении какого-то показателя, то вы были бы правы — но увы и ах, об уменьшении речи нет, а уменьшение времени есть лишь следствие увеличения скорости (производительности), которое вы додумали и выпячиваете в попытке показать, быдто бы вы что-то там осилили.
+1
Нет разницы увеличиваем или уменьшаем показатель. Ехали 100 км\ч замедлились на 90% — едем 100 — 90 = 10 км\ч.
0
Долгожданным усовершенствованием будет превращение фронт контроллера в стейт машину, как было и заявлено еще года 4 назад.
Просто if/else конструкции монстрообразные уже. Не говоря о том, что в принципе все идет к этому. Сейчас в зенде уже фактически есть стейты — диспатч, роутинг. ПабСабы нам обещали когда? Я помню еще ЗендКонфу 2009 года в Питере, когда нам и анонсировали их.
Просто if/else конструкции монстрообразные уже. Не говоря о том, что в принципе все идет к этому. Сейчас в зенде уже фактически есть стейты — диспатч, роутинг. ПабСабы нам обещали когда? Я помню еще ЗендКонфу 2009 года в Питере, когда нам и анонсировали их.
+1
Спасибо за ссылки и за новость, интересно.
0
UFO just landed and posted this here
Имхо, плохо, что стринги эскейпятся, а массивы стрингов — нет.
В запарке можно об этом позабыть, и если вдруг понадобится передать из контроллера два текста вместо одного, могут возникнуть проблемы:
Было:
return(array('text'=>'blabla'));
…
echo $text; // проблем нет
Задание, добавить несколько текстов:
return(array('text'=>array('blabla', 'foo')));
…
foreach($text as $txt) echo $txt; // нужно эскейпить
Как раз недавно столкнулся с похожей проблемой в typo3: при посте формы из скалярных параметров удалялись пехапешные эскейпы, а из массивов — нет.
В запарке можно об этом позабыть, и если вдруг понадобится передать из контроллера два текста вместо одного, могут возникнуть проблемы:
Было:
return(array('text'=>'blabla'));
…
echo $text; // проблем нет
Задание, добавить несколько текстов:
return(array('text'=>array('blabla', 'foo')));
…
foreach($text as $txt) echo $txt; // нужно эскейпить
Как раз недавно столкнулся с похожей проблемой в typo3: при посте формы из скалярных параметров удалялись пехапешные эскейпы, а из массивов — нет.
+1
По мне так самым вкусным в ZF2 стали DI и Events
+2
Они уже и так есть в Symfony2. Интересно, чего Зендовцы переписывают велосипеды?
Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.
Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.
-1
Ну, есть они не только в Symfony2, и не в ней первой появились. Так что, видимо, и у симфонистов тоже были причины «изобретать велосипед»
> Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
Хм… архитектуру ZF практически полностью переписали, Вам этого мало?! :)
> Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
Хм… архитектуру ZF практически полностью переписали, Вам этого мало?! :)
0
Они уже и так есть в Symfony2. Интересно, чего Зендовцы переписывают велосипеды?
Они интегрируются друг с другом, как раз для того, чтобы не писать велосипеды. Например компонент Yml из Symfony есть и в нём, и в ZF, и в Doctrine. Это плохо? По-моему просто отлично, когда каждый занимается своим делом, а не пишет «свою CMS». Разве нет?
А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.
Нет, всё с точностью наоборот. Бренд — тот же, фреймворк совершенно другой. Начав с внедрения неймспейсов и фишек php 5.3 зендовцы вошли в раш и используют его преимущества на всю катушку. Основная цель — увеличение производительности. Вы сравните два Skeleton Application. Взять хотя бы диспетчеризацию, построенную на событиях и старый цикл диспетчеризации. Всё по другому, я бы сказал на новом уровне.
0
Вы не так поняли комент Davert-а. Он говорит о том, что есть уже симфони2 с Di, а зендовцы свой изобрели. И говоря о двух одинаковых фреймворках под разными брендами, он имеет в виду Symfony2 и ZF2, а не ZF1/ZF2
+1
Понял, пардоньте. Ну у ZF и Symfony свои пути развития. Symfony — монолит, ZF — конструктор.
0
Вот именно. Вы полностью подтверждаете мои слова про бренды!
Вы не заметили, что Симфони2 уже далеко не монолит, а тоже набор компонентов, и наверное, даже более независимых. Посмотрите немного на Symfony2, и на Symfony Components.
Проблема в том, что в Симфони под единым названием существут 2 разных фреймворка и не все ещё это знают.
Вы не заметили, что Симфони2 уже далеко не монолит, а тоже набор компонентов, и наверное, даже более независимых. Посмотрите немного на Symfony2, и на Symfony Components.
Проблема в том, что в Симфони под единым названием существут 2 разных фреймворка и не все ещё это знают.
0
Да, я в курсе про Symfony components. Умный шаг. Идут в сторону конструктора, но всё же Symfony по своей природе именно монолит. ZF гораздо гибче и абстрактнее.
Про бренды полностью согласен. Такая фигня и с ZF, и с Symfony, и с Doctrine.
Про бренды полностью согласен. Такая фигня и с ZF, и с Symfony, и с Doctrine.
0
Ну насчет гибче абстрактнее… Symfony сейчас как раз и продвигается как компоненты.
Вон уже 8ой друпал будет их использовать. В чем там монолитность пока непонятно. ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Вообщем, у меня есть некоторое разочарование. Я надеялся, что в Зенде будут какие-то новые оригинальные архитектурные решения. А их нет (
Вон уже 8ой друпал будет их использовать. В чем там монолитность пока непонятно. ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Вообщем, у меня есть некоторое разочарование. Я надеялся, что в Зенде будут какие-то новые оригинальные архитектурные решения. А их нет (
-1
ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Модули ZF2 смотрели? Теже бандлы. Можно реализовать специфическую для проекта функциональность, а можно решать общую задачу (уже появилась куча модулей этим занимающихся, например, реализация регистрации/авторизации пользователей)
Модули ZF2 смотрели? Теже бандлы. Можно реализовать специфическую для проекта функциональность, а можно решать общую задачу (уже появилась куча модулей этим занимающихся, например, реализация регистрации/авторизации пользователей)
0
Symfony никогда не планировалась как монолитный фреймворк. Только на первом релизе это скорее выражалось в использовании сторонних компонентов, таких как Propel \ Doctrine, потом, после релиза версии 1.2 большой шаг к разделению был приход sfForm и теперь Symfony2 уже практически полностью состоит из разделенных компонентов.
0
Не понимаю, зачем делать переменные в шаблоне локальными? Как их тогда отличать от реально локальных переменных в шаблоне? Я собственно так и привык ориентироваться? $this->x — параметр из контроллера, $x — локальная переменная, созданная в шаблоне. А теперь будет каша и мешанина.
А в чем плюсы, я так и не понял (надеюсь, что мы не считаем плюсом то, что нужно вводить на 7 символов меньше)?
А в чем плюсы, я так и не понял (надеюсь, что мы не считаем плюсом то, что нужно вводить на 7 символов меньше)?
+1
А их действительно нужно для чего-то отличать?
7 символов по 50 раз в шаблоне — явный плюс. Меньше визуального шума.
7 символов по 50 раз в шаблоне — явный плюс. Меньше визуального шума.
+1
Подсчет символов в коде — это последнее, что надо делать. Что касается 50 раз, то слабо себе представляю, где столько раз нужно обращаться к параметрам из одного шаблона. Чаще это наоборот 5—10 раз.
А по поводу необходимости отличия тут примерно то же самое, как и в случае отличия полей класса от локальных переменных метода. По сути — одно и то же.
А по поводу необходимости отличия тут примерно то же самое, как и в случае отличия полей класса от локальных переменных метода. По сути — одно и то же.
-1
Зачем? В виде должна быть логика представления, там вообще php кода должно быть по минимуму. Мне кажется, так гораздо лучше. Верстальщик опять же откроет вид или шаблон, и быстрее в него «въедет». И вообще есть такая штука, как ViewModel, в которой должны лежать подготовленные для вида данные.
0
В виде должна быть логика представления (если это не Hello World). PHP-код — это как раз и есть логика представления. И ее должно быть ровно столько, сколько нужно. А верстальщики вроде должны шаблоны без логики делать, логика — задача программиста. Правда последнее утверждение может быть весьма спорным и наверняка найдутся куча примеров, когда программисты верстают или верстальщики пишут PHP-код в шаблонах.
Зачем разделять локальные и глобальные переменные в шаблоне я написал выше.
Зачем разделять локальные и глобальные переменные в шаблоне я написал выше.
-2
По идее, в шаблоне не должно быть локальных переменных.
Откуда они там возьмутся? Только из циклов. Вообщем, локальных переменных стоит избегать.
Откуда они там возьмутся? Только из циклов. Вообщем, локальных переменных стоит избегать.
+1
По какой идеи?
Да, в первую очередь локальные переменные появятся в циклах. А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления), и их результатам самое место в локальных переменных.
Что касается избегания, то это как минимум ничем не обосновано. Локальные переменные нужны как хотя бы потому, что они делают блоки кода чище.
Да, в первую очередь локальные переменные появятся в циклах. А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления), и их результатам самое место в локальных переменных.
Что касается избегания, то это как минимум ничем не обосновано. Локальные переменные нужны как хотя бы потому, что они делают блоки кода чище.
-1
«А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления)»
Та нет же, любые вычисления — это уже не представление. Их нужно выносить в хэлперы.
Та нет же, любые вычисления — это уже не представление. Их нужно выносить в хэлперы.
+3
А это утверждение на чем основано? Хэлперы вообще-то служат не для хранения кода, а для его повторного использования.
-3
Все утверждения основаны на опыте и здравом смысле.
Если есть догма «хэлперы для повторного использования» то не верьте ей. Используйте их там где это необходимо. Переносить логику в шаблоны необходимости нет. Точно так же, как сейчас не принято писать яваскрипт в шаблонах, или пардон, SQL-запросы, точно так же, следует выводить любую логику за рамки html-кода. Если так не делать, до говнокода останется всего полшага.
Если есть догма «хэлперы для повторного использования» то не верьте ей. Используйте их там где это необходимо. Переносить логику в шаблоны необходимости нет. Точно так же, как сейчас не принято писать яваскрипт в шаблонах, или пардон, SQL-запросы, точно так же, следует выводить любую логику за рамки html-кода. Если так не делать, до говнокода останется всего полшага.
0
Классная статья, спасибо ;-)
Чувствуете, что ZF стал более удобнее, «человечнее» что-ли?
Такой вопрос, в первом ZF был большой оверхед на Zend_Application. Во втором вы случаем не тестировали Zend\Mvc\Application?
Чувствуете, что ZF стал более удобнее, «человечнее» что-ли?
Такой вопрос, в первом ZF был большой оверхед на Zend_Application. Во втором вы случаем не тестировали Zend\Mvc\Application?
0
Интересует вопрос — чем локальные переменные идеологически и практически лучше в виде? Поддержка шаблонизаторов и короткий вывод в голом PHP коде шаблона?
То, что контроллер возвращает, а не сообщает, конечно, хорошо — тестировать гоораздо проще — сам понимаю. А сам способ использования такой чем лучше?
То, что контроллер возвращает, а не сообщает, конечно, хорошо — тестировать гоораздо проще — сам понимаю. А сам способ использования такой чем лучше?
0
Отвечу только с практической стороны, и это сугубо личная точка зрения.
Во вью-шаблонах про поддержку и короткий вывод я с вами согласен.
Добавлю:
— чище код, его проще поддерживать
— теперь хелперы сразу выделяются благодаря $this (в ZF1 мне эта каша хелперов и переменных просто кажется некрасивой)
— опять таки меньше магических вызовов (мысли вслух: хотя хм-м-м, а как они массив из контроллера в локальные переменные перевели? опять таки какая-то магия. надо будет посмотреть как они это реализовали.)
Вобщем во вью шаблонах это чисто эстетическое улучшение.
Про контроллеры:
— с тестированием абсолютно согласен
— избыточная связанность действий контроллера со вью-классом исчезла (надо писать в какой-то $this->view-> и опять какая-то ненужная тормознутость в использовании магических методов, вобщем некрасиво)
— они подготовили контроллеры к возможности навешивания событий к действиям контроллера через новый компонент EventManager (думаю это основная причина)
— ну и чисто для удобства, теперь можно прозрачно вызвать внутри одного метода/действия получить для обработки массив данных от другого метода/действия этого же класса (иногда такое требовалось и приходилось создавать приватный метод, который потом использовался по отдельности в двух методах).
Во вью-шаблонах про поддержку и короткий вывод я с вами согласен.
Добавлю:
— чище код, его проще поддерживать
— теперь хелперы сразу выделяются благодаря $this (в ZF1 мне эта каша хелперов и переменных просто кажется некрасивой)
— опять таки меньше магических вызовов (мысли вслух: хотя хм-м-м, а как они массив из контроллера в локальные переменные перевели? опять таки какая-то магия. надо будет посмотреть как они это реализовали.)
Вобщем во вью шаблонах это чисто эстетическое улучшение.
Про контроллеры:
— с тестированием абсолютно согласен
— избыточная связанность действий контроллера со вью-классом исчезла (надо писать в какой-то $this->view-> и опять какая-то ненужная тормознутость в использовании магических методов, вобщем некрасиво)
— они подготовили контроллеры к возможности навешивания событий к действиям контроллера через новый компонент EventManager (думаю это основная причина)
— ну и чисто для удобства, теперь можно прозрачно вызвать внутри одного метода/действия получить для обработки массив данных от другого метода/действия этого же класса (иногда такое требовалось и приходилось создавать приватный метод, который потом использовался по отдельности в двух методах).
+1
Перевести массив в набор переменных можно функцией extract. Интересно другое, если возвращать из контроллера данніе через return, все равно довольно часто придется создавать массив, и возвращать уже его, так как количесто вередаваеміх во view переменніх может біть разное (например в режиме администратора передать доп данные во view)
+1
Спасибо, про extract я совсем забыл )
Скорее всего в вашем случае «в режиме администратора передать доп данные во view» можно будет повешать событие на контроллер через EventManager.
Либо всегда передавать полный набор данных и во вью уже ограничивать вывод согласно правам доступа (в этом случае будьте аккуратны если пользуетесь AjaxContext'ом, а то все данные в json'е станут всем доступны).
Скорее всего в вашем случае «в режиме администратора передать доп данные во view» можно будет повешать событие на контроллер через EventManager.
Либо всегда передавать полный набор данных и во вью уже ограничивать вывод согласно правам доступа (в этом случае будьте аккуратны если пользуетесь AjaxContext'ом, а то все данные в json'е станут всем доступны).
0
Вроде как ещё обещали переработать механизм bootstrap'инга, потому что сейчас (ZF 1) bootstrap запускается для всех модулей.
0
Sign up to leave a comment.
Zend Framework 2 — долгожданные усовершенствования в Controller и View