Мне кажется у нас просто немного разные подходы. В смотрите на код сам по себе. Это вполне здравый подход.
Я смотрю, на код, на то как его поддерживать ближайшие 2-3 года и как это делать если человек написавший его уйдет из фирмы. Да, я немного прагматик и параноик в этом плане.
Относительно "++" я отвечу так. Если усредненный уровень разработчика, на которого у моей текущей компании есть бюджет, вдруг поглупеет, и перестанет понимать этот синтаксис, я попрошу людей в команде не использовать "++". Хотя конечно, лучше сменить место работы… :)
Знаю звучит странно, но мое мнение код это просто способ достичь цели. :)
Peter Zaitsev (кстати наш соотечественник, что хорошо слышно по акценту :) рассказывает о том что xtrabackup умеет и как его лучше использовать. С учетом того, что продукт молодой и малоизвестный, а альтернативы решений для бэкапов, либо дороги, либо не очень удобны, доклад достаточно ценный.
О прекрасно вас понимаю… У самого душа кровью обливается, кода ради дедлайна приходится просить команду делать неидеальное решение.
Все что я хотел сказать — данный трюк, характерен скорее для процедурного подхода. Как показывает пример дрюпала — и на нем можно делать очень качественный код. Но мастерства для этого надо, имхо, больше.
Как я уже сказал, трюк интересный, спасибо :) Знать о нем стоит. Но вот пользоваться — лично я остерегусь.
Нюк, не самый лучший представитель того что есть на ПХП. И вы предлагаете, фактически, процедурный подход (ну, точнее модульный). Я видел очень мало хороших продуктов с таким подходом. Дрюпал — приятное исключение.
У меня был опыт (хороший друг попросил — сам бы не полез) с «чудесным» продуктом oscommerce (кстати достаточно известным и распространенным), где «плагины» устанавливались примерно как «в файле таком то, после строки Х вставить такие то строки». Я не шучу.
Конечно я не буду говорить что ООП, сам по себе поможет сделать хорошую архитектуру. Но сейчас по нему много материалов и просто прочтение GoF уже даст много идей для хорошей и правильной архитектуры.
Так что с точки зрения проектирования — ООП подходит лучше.
Если же говорить о производительности, то я уже не раз выражал свою точку зрения. Если ваше приложение упирается в производительность ПХП, это значит ПХП вам не подходит и инструмент реализации был выбран не верно.
Что же, пожалуй соглашусь, что _технически_ для конфигов этот прием имеет смысл.
Я говорю скорее об общепринятости подхода.
Какие плюшки это дает? Из минусов — у людей которые буду поддерживать ваш код после вас, этот прием может вызвать недоумение. Но может быть есть плюсы которые я не вижу и сам начну так делать после вашего ответа… :)
Честно говоря нужность этой возможности крайне сомнительна. Любой язык имеет не очевидные особенности которые редко кто юзает. Знать их полезно, блеснуть ими на собеседование, тоже круто. Но за реальное использование их в продакшен коде — нужно отрывать руки :)
Мне сложно представить где реально можно такое заюзать. Оба примера что вы привели, лучше решать ООП, либо соглашением о пространстве имен для конфигов.
Тем ни мене — спасибо, я не знал о такой возможности. :)
Спасибо за начинание! И спасибо за предыдущие статьи — я их читал с удовольствием. Интересуюсь темой очередей в PHP.
Вы совершенно правы — с очередями в пхп плохо. Тоже исследовал этот вопрос и положительного нашел мало :)
И почитать об этом будет несомненно интересно.
Но… Вероятно я не достаточно внимательно прочитал статью, но в начале вы хотели сделать что-то простое, а в итоге изобрели энтерпрайз сервер сообщений :) Чисто с практической точки зрения, я бы на вашем месте поставил бы RabitMQ и допилил бы code.google.com/p/php-amqplib/. Потому что все описанное выше там уже есть. А так вам придется чертовски много реализовывать руками.
Я кохану3 в продакшен еще не рискую ставить, так что сильно ее не смотрел.
Да, в кохане3 они судя по всему сделали это уже сами.Хотя, честно говоря, каким то очень странным образом. :)
Что касается Коханы, то лично я с NetBeans использую www.mapledesign.co.uk/code/kohana-zend-autocomplete/
Этот скрипт обходит дерево исходников проекта и генерит /application/cache/autocomplete.php
который содержит заглушки вроде
Class ORM extends ORM_Core { /**/ function __construct($id = NULL);/**/ }
так что и проекту не мешает, и автокомплит начинает работать.
Не могу сказать что парсер работает идеально, но вполне приемлемо.
Ну как уже сказали, делать выборку по первичному ключу это не совсем разумно. Если ваше приложение нуждается только в подобных запросах, то RDBMS это явно оверкил. keyvalue база будет более уместной.
Думаю мы говорим просто о разных типах приложениях. Я бы сказал, что проблемы с базой ощущаются, на базах которые на ноуте уже просто не протестируешь. :) К тому же, ваш тест мало что говорит о конкурентных запросах, и уже совсем ни чего не показывает для OLTP приложений…
Так что, там где есть от миллиона хитов в сутки и сколько нибудь развитая бизнес логика, БД может вполне стать ботелнеком.
Совершенно согласен — теоретически статья очень полезна! Жаль только что практических выводов из нее сделать сложно. Ну тут каждый должен, сам посидеть с профайлером и решить для себя, какой процент времени работы отъедает инклуд и думать надо ли оптимизировать или нет.
Вы свою часть работы сделали — спасибо большое! :)
Было бы чудно, если бы вы еще написали как именно в реальных условиях вы бы создавали монолитный файл. Писать парсер с анализатором зависимостей, ой как не хочется если ктото уже сделал часть работы и это можно заюзать. К тому же парсер не спасет от аутолоуда и инклюдов с использованием переменных.
Если напишите статью с реальными аспектами создания монолитного кода, лично я буду вам только благодарен! :)
Простите, а не является ли это охотой не ведем? На синтетических тестах, ваши выводы конечно верны. Но вот положа руку на сердце, как много пхп проектов вы видели, где тормозил бы именно пхп код? Мне кажется в 80% случаев мы упираемя в БД (а скорее даже в IO для БД). Так ли важно, будет занимать пхп, 7% или 9% времени выполнения запроса, если львиную часть все равно будет отжирать БД?
А в остальных 20%, где приложение и правда имеет сложную ПХП логику и тормозит само по себе… Ну может быть просто был не верно выбран инструмент и в этом месте надо было использовать чтото другое, вроде расширение на Си, джавы или (подставить свое любимое)?
Пишу без сарказма, мне правда интересно ваше мнение.
Поймите правильно, я очень благодарен вам за проделанные исследования и если бы у меня был под рукой _готовый_ инструмент который собрал бы мне монолит, для моего приложения, с радостью им бы воспользовался. Но бежать переписывать чтото, что бы избавиться от инклюдов, мне кажется смысла нет.
Можно чуть поподробней о
> Явно императивный скрипт для сборки.
Под императивным подходом в rake я подразумевал, что каждое задание, это фактически ф-цияя на языке Ruby со всем вытекающими. То есть парой строчек, я могу организовать цикл в задаче, условие, использовать богатый набор стандартных библотек.
Я так понимаю что в ант, с эти несколько сложней — если чтото не предусмотренно синтаксисом Ант, то решить это можно только написанием плугина?
Творчества автора не читал но осуждаю… (с) В смывсле maven не пользовался, так что сравнивать сложно
Если уже статья опубликована в разделе вебразработки, то хотелось бы спросить — может ли ктото сравнить maven vs rake для НЕ Java разработки?
Объясню что я имею ввиду. Для мавена и ant, как я понимаю очень просто прописываются типичные действия. Но если чтото надо делать не типичное, я так понимаю надо писать плагин?
Фактически я говорю о императивный vs декларативный подход в сборке. Для для джавы и стандартных действий, ant / maven круты. Но после capistrano / rake заганять себя в рамки XML как то уже не тянет.
А все же как вы решаете проблему равномерного распределния нагрузки по винтам? В таких сервисах файлы быстро становятся популярными и быстро забываются… Пока соберешь статистику по популярности файла, и начнешь его по винатам двигать — его уже ни кто и не качает :)
Кеш ОС, тоже не выход если файлы большие.
Не знаю как на счет модуля, но для вашей проблем уже есть готовое средство. Правда для Nginx Nginx upload module. Записывает файл в tmp каталог и передает, путь до этого файла в POST переменной. Работает у нас в продакшене — очень довольны.
Даже если у вас не стоит nginx, то поставить его, прицепить модуль и использовать nginx только для аплоуда, все равно будет дешевле чем писать и отлаживать модуль самому…
Кроме того, php-fpm имело спецальную возможность для решение той же проблемы. Но прошу прощения, не могу найти описание на новом их новом сайта, так что гуглите…
О мисье так же является автором code.google.com/p/php-rabbit/? Мое уважение!
Долго не отвечал, потому что php-amqp хотел погонять. Что могу сказать — при каких то условиях (которые я даже могу четко воспроизвести), на публичном тестовом сервере и правда выдает эксепшен. Но, с RabbitMQ я знаком второй день, так что может это штатное поведение… Не готов пока обсуждать ее стабильность…
Теперь почему я смотрю в сторону php-amqp, а не в сторону вашей… Ответ очень прост — я не достаточно крут :) Как вы правильно сказали, это опенсорс. С его проблемами… Обе библиотеки достаточно молоды и не имеют большого комьюнити. Обе, потенциально могут принести проблемы на продакшене. А если проблемы будут, то я исхожу из того что фиксить их придется силой команды (автор любой либы тоже человек — ушел в отпуск или просто влюбился… :) А копаться в PHP коде, лично мне будет проще, чем отлаживать сишный код, в котором, к моему глубочайшему удручению, я не могу назвать себя спецом.
Кроме того вопрос инсталляции — у нас достаточно много серверов, компилить клиентов на каждом конечно можно… но не хочется. :)
Так что, если обе библиотеки дадут мне примерно одинаковый уровень стабильности, то я предпочитаю использовать ту что мне будет проще поддерживать.
Однако тесты я еще не закончил и выбор еще не сделал. В любом случае — большое спасибо что сделали альтернативу!
Если же вас интересует мое мнение в общем, то я считаю что ваша библиотека более перспективна. Делать обертку над оттестированным кодом, гораздо более разумно что реализовывать протокол руками (как это сделано в php-amqp). Конечно же и вопрос скорости говорит в пользу вашего решения. Так что единственное что меня беспокоит в текущей реализации, это потенциальные проблемы с поддержкой. Если ваше расширение попадет в стандартную поставку (читай в порты BSD и репозитории) я буду только счастлив его использовать чаще. Если чем то смогу сделать в этом плане — буду рад помочь. Пожалуйста продолжайте развивать этот проект! :)
По поводу проекта чуть позже напишу в личку — хочу протестировать обе библиотеки.
Я смотрю, на код, на то как его поддерживать ближайшие 2-3 года и как это делать если человек написавший его уйдет из фирмы. Да, я немного прагматик и параноик в этом плане.
Относительно "++" я отвечу так. Если усредненный уровень разработчика, на которого у моей текущей компании есть бюджет, вдруг поглупеет, и перестанет понимать этот синтаксис, я попрошу людей в команде не использовать "++". Хотя конечно, лучше сменить место работы… :)
Знаю звучит странно, но мое мнение код это просто способ достичь цели. :)
Все что я хотел сказать — данный трюк, характерен скорее для процедурного подхода. Как показывает пример дрюпала — и на нем можно делать очень качественный код. Но мастерства для этого надо, имхо, больше.
Как я уже сказал, трюк интересный, спасибо :) Знать о нем стоит. Но вот пользоваться — лично я остерегусь.
У меня был опыт (хороший друг попросил — сам бы не полез) с «чудесным» продуктом oscommerce (кстати достаточно известным и распространенным), где «плагины» устанавливались примерно как «в файле таком то, после строки Х вставить такие то строки». Я не шучу.
Конечно я не буду говорить что ООП, сам по себе поможет сделать хорошую архитектуру. Но сейчас по нему много материалов и просто прочтение GoF уже даст много идей для хорошей и правильной архитектуры.
Так что с точки зрения проектирования — ООП подходит лучше.
Если же говорить о производительности, то я уже не раз выражал свою точку зрения. Если ваше приложение упирается в производительность ПХП, это значит ПХП вам не подходит и инструмент реализации был выбран не верно.
Я говорю скорее об общепринятости подхода.
Какие плюшки это дает? Из минусов — у людей которые буду поддерживать ваш код после вас, этот прием может вызвать недоумение. Но может быть есть плюсы которые я не вижу и сам начну так делать после вашего ответа… :)
Мне сложно представить где реально можно такое заюзать. Оба примера что вы привели, лучше решать ООП, либо соглашением о пространстве имен для конфигов.
Тем ни мене — спасибо, я не знал о такой возможности. :)
Вы совершенно правы — с очередями в пхп плохо. Тоже исследовал этот вопрос и положительного нашел мало :)
И почитать об этом будет несомненно интересно.
Но… Вероятно я не достаточно внимательно прочитал статью, но в начале вы хотели сделать что-то простое, а в итоге изобрели энтерпрайз сервер сообщений :) Чисто с практической точки зрения, я бы на вашем месте поставил бы RabitMQ и допилил бы code.google.com/p/php-amqplib/. Потому что все описанное выше там уже есть. А так вам придется чертовски много реализовывать руками.
Да, в кохане3 они судя по всему сделали это уже сами.Хотя, честно говоря, каким то очень странным образом. :)
Этот скрипт обходит дерево исходников проекта и генерит /application/cache/autocomplete.php
который содержит заглушки вроде
Class ORM extends ORM_Core { /**/ function __construct($id = NULL);/**/ }
так что и проекту не мешает, и автокомплит начинает работать.
Не могу сказать что парсер работает идеально, но вполне приемлемо.
Думаю мы говорим просто о разных типах приложениях. Я бы сказал, что проблемы с базой ощущаются, на базах которые на ноуте уже просто не протестируешь. :) К тому же, ваш тест мало что говорит о конкурентных запросах, и уже совсем ни чего не показывает для OLTP приложений…
Так что, там где есть от миллиона хитов в сутки и сколько нибудь развитая бизнес логика, БД может вполне стать ботелнеком.
Вы свою часть работы сделали — спасибо большое! :)
Было бы чудно, если бы вы еще написали как именно в реальных условиях вы бы создавали монолитный файл. Писать парсер с анализатором зависимостей, ой как не хочется если ктото уже сделал часть работы и это можно заюзать. К тому же парсер не спасет от аутолоуда и инклюдов с использованием переменных.
Если напишите статью с реальными аспектами создания монолитного кода, лично я буду вам только благодарен! :)
А в остальных 20%, где приложение и правда имеет сложную ПХП логику и тормозит само по себе… Ну может быть просто был не верно выбран инструмент и в этом месте надо было использовать чтото другое, вроде расширение на Си, джавы или (подставить свое любимое)?
Пишу без сарказма, мне правда интересно ваше мнение.
Поймите правильно, я очень благодарен вам за проделанные исследования и если бы у меня был под рукой _готовый_ инструмент который собрал бы мне монолит, для моего приложения, с радостью им бы воспользовался. Но бежать переписывать чтото, что бы избавиться от инклюдов, мне кажется смысла нет.
> Явно императивный скрипт для сборки.
Под императивным подходом в rake я подразумевал, что каждое задание, это фактически ф-цияя на языке Ruby со всем вытекающими. То есть парой строчек, я могу организовать цикл в задаче, условие, использовать богатый набор стандартных библотек.
Я так понимаю что в ант, с эти несколько сложней — если чтото не предусмотренно синтаксисом Ант, то решить это можно только написанием плугина?
Поправьте если я где то ошибся плиз.
Если уже статья опубликована в разделе вебразработки, то хотелось бы спросить — может ли ктото сравнить maven vs rake для НЕ Java разработки?
Объясню что я имею ввиду. Для мавена и ant, как я понимаю очень просто прописываются типичные действия. Но если чтото надо делать не типичное, я так понимаю надо писать плагин?
Фактически я говорю о императивный vs декларативный подход в сборке. Для для джавы и стандартных действий, ant / maven круты. Но после capistrano / rake заганять себя в рамки XML как то уже не тянет.
Кеш ОС, тоже не выход если файлы большие.
Nginx upload module. Записывает файл в tmp каталог и передает, путь до этого файла в POST переменной. Работает у нас в продакшене — очень довольны.
Даже если у вас не стоит nginx, то поставить его, прицепить модуль и использовать nginx только для аплоуда, все равно будет дешевле чем писать и отлаживать модуль самому…
Кроме того, php-fpm имело спецальную возможность для решение той же проблемы. Но прошу прощения, не могу найти описание на новом их новом сайта, так что гуглите…
Но ваши лучше тем что есть исходники :)
Долго не отвечал, потому что php-amqp хотел погонять. Что могу сказать — при каких то условиях (которые я даже могу четко воспроизвести), на публичном тестовом сервере и правда выдает эксепшен. Но, с RabbitMQ я знаком второй день, так что может это штатное поведение… Не готов пока обсуждать ее стабильность…
Теперь почему я смотрю в сторону php-amqp, а не в сторону вашей… Ответ очень прост — я не достаточно крут :) Как вы правильно сказали, это опенсорс. С его проблемами… Обе библиотеки достаточно молоды и не имеют большого комьюнити. Обе, потенциально могут принести проблемы на продакшене. А если проблемы будут, то я исхожу из того что фиксить их придется силой команды (автор любой либы тоже человек — ушел в отпуск или просто влюбился… :) А копаться в PHP коде, лично мне будет проще, чем отлаживать сишный код, в котором, к моему глубочайшему удручению, я не могу назвать себя спецом.
Кроме того вопрос инсталляции — у нас достаточно много серверов, компилить клиентов на каждом конечно можно… но не хочется. :)
Так что, если обе библиотеки дадут мне примерно одинаковый уровень стабильности, то я предпочитаю использовать ту что мне будет проще поддерживать.
Однако тесты я еще не закончил и выбор еще не сделал. В любом случае — большое спасибо что сделали альтернативу!
Если же вас интересует мое мнение в общем, то я считаю что ваша библиотека более перспективна. Делать обертку над оттестированным кодом, гораздо более разумно что реализовывать протокол руками (как это сделано в php-amqp). Конечно же и вопрос скорости говорит в пользу вашего решения. Так что единственное что меня беспокоит в текущей реализации, это потенциальные проблемы с поддержкой. Если ваше расширение попадет в стандартную поставку (читай в порты BSD и репозитории) я буду только счастлив его использовать чаще. Если чем то смогу сделать в этом плане — буду рад помочь. Пожалуйста продолжайте развивать этот проект! :)
По поводу проекта чуть позже напишу в личку — хочу протестировать обе библиотеки.