Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 287
С чувством юмора и по сути
смешно :) а особенно, как только вспомню людей, что _действительно_ в чем-то так думают
но честно - мне хочется верить, что профессиональные пхп кодеры есть, но в чем я теперь уверен - он должен знать пхп далеко не как первый язык...
но честно - мне хочется верить, что профессиональные пхп кодеры есть, но в чем я теперь уверен - он должен знать пхп далеко не как первый язык...
>> _действительно_ в чем-то так думают
Что, сразу все 13 мыслей именно так и думают? :)
Что, сразу все 13 мыслей именно так и думают? :)
профессионалу глубоко безразлично как написан проект, профессионал может заставить любой код работать с минимальными исправлениями. Все профессионалы - ленивы. ООП язык для ленивых. Профессионалу проще написать одну функцию чем 15 классов и один класс вместо 15 функций. Профессионал знает чего он стоит и получает больше. Лучше быть профессионалом в PHP чем говнокодером на JAVA, хотя лучше стремится познать все :)
Описание не профессионала, а помеси супермена с планокуром :)
И как проект написан ему безразлично, и любой код он может заставить работать, и ленивый, и ООП - именно для него, но в то же время ему "проще написать одну функцию", хотя тут же лучше класс, чем функции. И получает он больше, чем стоит, и (вот ведь чудо!) - лучше ему быть профессионалом, чем говнокодером.
Бред какой-то.
И как проект написан ему безразлично, и любой код он может заставить работать, и ленивый, и ООП - именно для него, но в то же время ему "проще написать одну функцию", хотя тут же лучше класс, чем функции. И получает он больше, чем стоит, и (вот ведь чудо!) - лучше ему быть профессионалом, чем говнокодером.
Бред какой-то.
Мб, и первый подойдет. Но, имхо, очевидно, что при прочих равных, хорошее знание еще нескольких языков полезно. Вообще, чем больше знаешь, тем полезней. Вопрос в том, как найти баланс между кругозором и глубиной знаний.
пошел уговаривать админа поставить акселератор...
1) не понял про что пункт
2) согласен полностью. + надо еще умудриться заставить выбранный акселератор остаться в живых при большой нагрузке. Страшный сон этого пункта - segmentation fault
3) парадигмы применяются не для непосредственного увеличения производительности. Скорее, для более удобной реализации механизмов увеличения производительности (тот же кэш)
4) согласен
5) супер! :))) 5+
6) не работал с этим фреймворком
7) 5+
8) теоретически согласен
9) не согласен. Точнее, не всегда это так. В большинстве случаев это не так.
10) то же самое
11) согласен.
12) не РНР5 - коварная штука, а комьюнити РНР5 - коварная штука.
13) блин, вот это профессионально!
2) согласен полностью. + надо еще умудриться заставить выбранный акселератор остаться в живых при большой нагрузке. Страшный сон этого пункта - segmentation fault
3) парадигмы применяются не для непосредственного увеличения производительности. Скорее, для более удобной реализации механизмов увеличения производительности (тот же кэш)
4) согласен
5) супер! :))) 5+
6) не работал с этим фреймворком
7) 5+
8) теоретически согласен
9) не согласен. Точнее, не всегда это так. В большинстве случаев это не так.
10) то же самое
11) согласен.
12) не РНР5 - коварная штука, а комьюнити РНР5 - коварная штука.
13) блин, вот это профессионально!
1) Пункт про то, что PHP как правило не является узким местом и возможно не стоит так гнаться за производительностью PHP, а вместо этого заняться более адекватными вещами...
3) Да. Просто топик изначально писался в контексте высокой производительности, да еще эти вечные советы по ускорению PHP с помощью правильных блох... :)
10) Без акселератора на машине разработчика вообще не стоит говорить об оптимизации - профайлер будет бессовестно толкать вас на такие жуткие вещи, как например вырезание комментов :) вместо оптимизации _действительно_ узких мест.
9) После п.10 уже не актуально :)
3) Да. Просто топик изначально писался в контексте высокой производительности, да еще эти вечные советы по ускорению PHP с помощью правильных блох... :)
10) Без акселератора на машине разработчика вообще не стоит говорить об оптимизации - профайлер будет бессовестно толкать вас на такие жуткие вещи, как например вырезание комментов :) вместо оптимизации _действительно_ узких мест.
9) После п.10 уже не актуально :)
1) см. ниже
9), 10) убедили :) согласен.
А вообще, по поводу "вечных советов по ускорению PHP с помощью правильных блох" полностью поддерживаю. Писал об этом буквально вчера
9), 10) убедили :) согласен.
А вообще, по поводу "вечных советов по ускорению PHP с помощью правильных блох" полностью поддерживаю. Писал об этом буквально вчера
а что насчет второго пункта? segmentation fault... он же есть...
по мне дак не очень статья :) мне кажется через чур уж юморно, но, стоит отдать должное, полезная инфа ;)
Есть полезная информация, но многочисленные "вы неудачник", "цветы в противогазе" и т.д. вызывают отторжение. Было бы гораздо лучше, если бы вы написали эту заметку как статью.
О статье, которых миллионы, забудете через неделю. А цветы в противогазе и акселератор в расслабленном анусе запомнятся надолго.
Чтобы статья запомнилась, попала в закладки, на рабочий стол, на принтер - она должна быть полезной, а не запоминающейся.
Я бы добавил этот пост в закладки, если бы здесь было в два раза больше полезной информации и почти не было шелухи про противогазы и анусы - это мерзко и неприятно.
Я бы добавил этот пост в закладки, если бы здесь было в два раза больше полезной информации и почти не было шелухи про противогазы и анусы - это мерзко и неприятно.
Прочел. Через 5 минут решил вспомнить. Но помню только противогаз, анус и цветочки. Не понял почему там был PHP?
Решил перечитать и наткнулся на такие вещи
> Если на вашей рабочей машине PHP работает под Windows ... не мучайте PHP - не гоняйте его под Windows
Что есть в винде и чего нет в юниксах, от чего PHP становится мучительно работать?
Чем плоха винда в данном случае?
Что вы не можете сделать такого на винде, чего можете на юниксах?
Решил перечитать и наткнулся на такие вещи
> Если на вашей рабочей машине PHP работает под Windows ... не мучайте PHP - не гоняйте его под Windows
Что есть в винде и чего нет в юниксах, от чего PHP становится мучительно работать?
Чем плоха винда в данном случае?
Что вы не можете сделать такого на винде, чего можете на юниксах?
Я тоже "мучаю" дома и на работе php под windows, ещё "издеваюсь" над php на выделенном, виртуальном выделенном и просто виртуальном хостингах под *nix и что-то до сих пор не заметил разницы в работе под этими платформами.
Позабавил такой момент.
Автор очень часто использует "яркие" выражения со словами "анус", "противогаз" и проч..
Но он тщательно выводит с большой буквы "Windows" вместо ставших привычными в статьях подобного сорта "вынь", "сукьс", "масдай" и проч.
В результате очень сомнительной впечатление от прочтения статьи :)
Автор очень часто использует "яркие" выражения со словами "анус", "противогаз" и проч..
Но он тщательно выводит с большой буквы "Windows" вместо ставших привычными в статьях подобного сорта "вынь", "сукьс", "масдай" и проч.
В результате очень сомнительной впечатление от прочтения статьи :)
Что вы не можете сделать такого на винде, чего можете на юниксах?
Сразу вспоминается то, на что наступали.
1. Стереть открытый файл.
2. Использовать flock как рекомендательный лок, а не жёсткий.
А вообще мелких отличий - десятки, а то и сотни. Именно что получается "запах цветов в противогазе": основные вещи-то те же, но никогда не знаешь - будет оно в боевом режиме работать так же или нет. Можно, конечно, и на сервер Windows взгромоздить - но тогда уж лучше использовать Windows-технологии (ASP.NET, etc).
Сразу вспоминается то, на что наступали.
1. Стереть открытый файл.
2. Использовать flock как рекомендательный лок, а не жёсткий.
А вообще мелких отличий - десятки, а то и сотни. Именно что получается "запах цветов в противогазе": основные вещи-то те же, но никогда не знаешь - будет оно в боевом режиме работать так же или нет. Можно, конечно, и на сервер Windows взгромоздить - но тогда уж лучше использовать Windows-технологии (ASP.NET, etc).
Я а не думаю что автор так уж презирает Windows. Упор скорее на то, что использовать разные столь среды для разработки и для продакшна - самому себе создавать проблемы. Одно дело FredBSD vs Linux: с высоты PHP-шных абстракций отличия можно заметить раз в сто лет, другое - Windows vs *nix: отличий - вагон и маленькая тележка.
Это все очередные частности превосходства одного перед другим.
каждый юникс имеет множество отличий друг перед другом.
Я же говорю в общем.
Неужели [b]с точки зрения автора[/b] в винде нельзя написать приложение, которое будет работать одинаково хорошо как в винде так и в юниксах.
каждый юникс имеет множество отличий друг перед другом.
Я же говорю в общем.
Неужели [b]с точки зрения автора[/b] в винде нельзя написать приложение, которое будет работать одинаково хорошо как в винде так и в юниксах.
Наверное я не совсем ясно выразился. Скорее всего в винде все будет работать примерно так же, как в никсах, но не ждите, что профайлер покажет вам те места, которые будут реально узкими на боевом серваке. Хотя примерно - да.
Но главное - вы отделяетесь от никсов, вы не видите всю систему в целом. Речь здесь идет о хотя бы мало-мальски нагруженных системах, так что руку нужно держать на пульсе постоянно.
Но главное - вы отделяетесь от никсов, вы не видите всю систему в целом. Речь здесь идет о хотя бы мало-мальски нагруженных системах, так что руку нужно держать на пульсе постоянно.
+ однажды пытался распараллелить выполнение пхп скрипта на несколько потоков (знаю что это перебор и гораздо лучше был бы тот же перл/питон, но так было удобнее для комплекса)
под _W_indows сие чудо работать не могло. под *nix же, что называется, с пол-пинка
под _W_indows сие чудо работать не могло. под *nix же, что называется, с пол-пинка
знаете, насчет противогаза и прочего, сразу видно, что человек рассматривает php только как веб язык. Его же еще можно использовать как аналог перловки или питона. Я согласен, что многие фичи из никсов не работают, но например когда мне нужно было написать маленький импортер из mysql в excel, я тупо заюзал com и не е@ся с пировскими и прочими библиотеками(кстати никто не знает нормально создающую библиотеку без косяков с русской кодировкой?пировскую библиотеку при setVersion(8) сколбашивает).Так что вы неправы ;) и там и там пхп к месту, главное не пытаться заставлять его делать то, для чего он не предназначен :)
> "Его же еще можно использовать как аналог перловки или питона."
Не ради холивара, но, уважаемый, вы скорей всего очень мало сталкивались с указанными языками и перлом в частности. Не стоит делать таких громикх замечаний :) PHP - PHP Hypertext Processor и этим ве сказано, в других местах он слаб, да и не нужен он в других местах.
> "когда мне нужно было написать маленький импортер из mysql в excel"
попиарю еще немного перл :) А вот то, что отвечает вашей задаче в точности.
Не ради холивара, но, уважаемый, вы скорей всего очень мало сталкивались с указанными языками и перлом в частности. Не стоит делать таких громикх замечаний :) PHP - PHP Hypertext Processor и этим ве сказано, в других местах он слаб, да и не нужен он в других местах.
> "когда мне нужно было написать маленький импортер из mysql в excel"
попиарю еще немного перл :) А вот то, что отвечает вашей задаче в точности.
Чем плоха винда в данном случае?
в силу обстоятельств сейчас вынужден возиться с ПХП и Zend Framework.
дык вот, на моём ноуте стоял денвер, под ним и начал возиться. при чем так, в спешке, не заморачиваясь над производительностью. потом чисто случайно замерил время отработки скриптов и ужаснулся. потыркал профайлером и чуть дар речи не потерял. bootstraper отрабатывал 0.3с (три_десятых_секунды!!!). при таком раскладе кроме как отказаться от Zend Framework'овского MVC ничего в голову не приходило, но данный пунктик был на время отложен.
а потом у меня появился свободный вечер и я поднял себе на WMVare линушок, аналогичный тому на котором всё в последствии должно будет крутиться. ну и заодно перенес всё с денвера на виртуальную машину.
и тут, о чудо, всё резко заработало нормально! bootstraper отрабатывает за 0.05, для виртуальной машины (которой я выделил аж 128M памяти и вроде как больше одного ядра она у меня принципиально не отъедает) мне такого показателя вполне достаточно.
возникает вопрос: и почему под виндой оно работало в 6 раз медленнее !?...
потому что вы профан. во-первых "денвер" - это ужасно, а во-вторых, ВЫБИРАТЬ систему или фреймвор тестировать не под той системой где оно реально будет работать - глупо. Здесь говорили о разработке, а не о тестировании. Общее состояние при разработке под линуксом и виндой одинаково почти. при профилированни надо сравнивать порядки цифр, а не их точные значения.
потому что вы профан.
спасибо :")
во-первых "денвер" - это ужасно
а что не ужасно? собирать из сырцов под виндой?! :D
до тех пор пока мне хватает его возможностей он меня устраивает. к тому-же мне не так уж и часто приходится с ним иметь дело :)
во-вторых, ВЫБИРАТЬ систему или фреймвор тестировать не под той системой где оно реально будет работать - глупо.
речь шла не о выборе и тестировании, а о случайно замеченном факте. трактовать который можно по разному.
при профилированни надо сравнивать порядки цифр, а не их точные значения.
речь не шла о профилировании, до него еще далеко. профайлером я тыкал только для того чтобы выяснить ЧТО тормозит, и когда увидел что тормозит кусок фреймворка то был сильно расстроен. но, как оказалось в дальнейшем, зря.
поймите, я отвечал на конкретный вопрос: «Чем плоха винда в данном случае?»
и в ситуации которую я описывал винда была плоха тем, что чуть не стала причиной незаслуженных кирпичей в cторону ZF.
вы считаете что в «денвере» php или апач сильно отличается от любой другой «подвиндузной» сборки?
Денвер - это такая поделка, зло которой в том, что Котеров зачем-то половину ДЕФОЛТНЫХ значение php.ini перекрутил на другие. в результате если проект сложный, вы сталкнетесь с большими проблемами на продакшене. Денвер зло, которое приучает писать неправильно и с костылями. А потом приходят такие вот на работу и ставят себе денвер и удивляются когда я присылаю бумажку с просьбой поставить тот или ино модуль новый. Они просто не знаю что это такое!
Что до остального - подчеркну - мы говорили О РАЗРАБОТКЕ и отдельные тормоза какой-то там фигни совершенно на разработку не влияют. Ваше удивление говорит лишь о том, что ВЫ НЕ ТЕСТИРОВАЛИ свой выбор фреймворка, а тупо начали им пользоваться. Это не вина винды или еще чего. Если бы вы осмысленно выбрали фреймворк, оттестировали его как положено, то данные конкретные тормоза вам были бы безразличны - потому что вы ЗАЛИ БЫ как он на самом деле работает. И тогда сосредоточились бы не на отладке чужого кода, а всетки на разработке и тестировании своего. Надеюсь я достаточно развернуто ответил?
Что до остального - подчеркну - мы говорили О РАЗРАБОТКЕ и отдельные тормоза какой-то там фигни совершенно на разработку не влияют. Ваше удивление говорит лишь о том, что ВЫ НЕ ТЕСТИРОВАЛИ свой выбор фреймворка, а тупо начали им пользоваться. Это не вина винды или еще чего. Если бы вы осмысленно выбрали фреймворк, оттестировали его как положено, то данные конкретные тормоза вам были бы безразличны - потому что вы ЗАЛИ БЫ как он на самом деле работает. И тогда сосредоточились бы не на отладке чужого кода, а всетки на разработке и тестировании своего. Надеюсь я достаточно развернуто ответил?
и удивляются когда я присылаю бумажку с просьбой поставить тот или ино модуль новый. Они просто не знаю что это такое!
а... ну в таком контексте да... тут сложно спорить :D
Ваше удивление говорит лишь о том, что ВЫ НЕ ТЕСТИРОВАЛИ свой выбор фреймворка
в точку. я собирался с ним познакомиться.
Если бы вы осмысленно выбрали фреймворк, оттестировали его как положено, то данные конкретные тормоза вам были бы безразличны
если бы бабке писюн, она дедкой была бы :D
вот так соберешся поиграться с чем-то, а потом выводы неправильные сделаешь. и не потому что я не ЗНАЛ, я ведь как раз собирался УЗНАТЬ, а потому что неправильно выбрал платформу для игр.
в таком контексте понятно почему винда не есть лучший выбор с моей точки зрания?
Это все условности и частности. Никакого особого отношения к винде, в частности, не имеющие. Не вижу никаких проблем разработки в винде. Я вот сижу под линуксом - просто привык и обкатываю новые технологии, но у меня работа такая. Программеры в массе своей сидят в винде - и никаких проблем не было никогда.
Денвер не зло. Зло использовать денвер для чего либо кроме начального обучения. Ни кто не мечтает научиться конфигурировать АПАЧ, а сайт желают сделать каждый продвинутый ШКОЛЬНИК. Денвер поделка на уровне Школьника. Если ее использовать для чего либо другого тогда да. А в Школе он помогает.
Сколько меня не лечи - я считаю что денвер зло. И вот почему: первый же запрос в яндексе дает ссылку на такое детальное и простое описание "как поставить LAMP" что это становится ничем не сложнее денвера, а необходимый навык получается. К тому же, главная претензия к денверу в том, что там умолчательные настройки поменяны на черте какие и навешено столько левой фигни, что часто программист нафиг не способен понять почему дома у него работает, а на работе нет - потому что всяких длл там понапихано левых немеряно.
Извините. Я никого не соберался лечить и агитировать за денвер. Это образовательный проект. И он РЕАЛЬНО мне помог учить детей.
Как только мы прошли азы, начались проблемы. В ДИЗАЙНЕ его использовать нельзя. А LAMP это линукс апач мускул ПХП?
Это не очень подходит для начального обучения. Нельзя сразу объяснять и материал и еще 4 программы.
А вот куроводство по моему мнению зло. Всмысле - личное мнение с притензией на абсолютную истину - это всегда зло.
Как только мы прошли азы, начались проблемы. В ДИЗАЙНЕ его использовать нельзя. А LAMP это линукс апач мускул ПХП?
Это не очень подходит для начального обучения. Нельзя сразу объяснять и материал и еще 4 программы.
А вот куроводство по моему мнению зло. Всмысле - личное мнение с притензией на абсолютную истину - это всегда зло.
уж лучше XAMPP
А по-моему удачно написано. ухую псевдо-научную статью возможно не каждый бы дочитал до конца.
Это как лекция в университете, в течении которой преподаватель только монотонно бубнит, склоняя тудентов ко сну :)
Это как лекция в университете, в течении которой преподаватель только монотонно бубнит, склоняя тудентов ко сну :)
полезные мысли, стоит над ними периодически медитировать (читай задуматься).
но автору-- за способ изложения.
но автору-- за способ изложения.
Читаю комментарии, и ужасаюсь. Для написания данной статьи мне понадобилось: 2 противогаза, 2 ануса, 1 танк и 3 (!) неудачника! Впредь обязуюсь соблюдать следующие нормативы: на один хабратопик не более: 1 противогаза, 1 ануса, 1 танка и 1 неудачника! :)
Однако плюс от применения танков, противогазов и анусов налицо:
1) Никто не заметил в п.5 - "три оператора вывода" - print() - не оператор, а функция. Никто не добавил, что на один HTTP запрос отвечает один оператор echo (или функция print():)
2) В п.4 - "Закешировать можно все. Вопрос лишь в том, как посылать уведомления" - никто не стал спорить о вероятности попадания в кеш.
3) Никто не сказал, что пример в п.7 плох на фоне п.5 :)
Ну и еще там есть... В общем противогазы и анусы намного популярней PHP даже в блоге про PHP ;)
Однако плюс от применения танков, противогазов и анусов налицо:
1) Никто не заметил в п.5 - "три оператора вывода" - print() - не оператор, а функция. Никто не добавил, что на один HTTP запрос отвечает один оператор echo (или функция print():)
2) В п.4 - "Закешировать можно все. Вопрос лишь в том, как посылать уведомления" - никто не стал спорить о вероятности попадания в кеш.
3) Никто не сказал, что пример в п.7 плох на фоне п.5 :)
Ну и еще там есть... В общем противогазы и анусы намного популярней PHP даже в блоге про PHP ;)
AirWorker, до этого еще не добрались :) там еще полно чего. Просто противогазы интереснее в первую очередь обсуждать, пока мозг обдумывает более важные вопросы
А еще поправки иногда выливаются в бубнеж под нос, а не в комментарии с обличением :).
это как раз говорит об уровне знаний php-программистов :-)
PS: прошу всех не воспринимать лично — шутка...
PS: прошу всех не воспринимать лично — шутка...
Потомучто в этой откровенно замской статье, все остальное было не важно. автору очень понравились пошлые метафоры и он ими упивался. А содержание оказалось не важно. Я лично поставил - статье, потому что содержание должно соответствовать оформлению, а тут на лицо расхождение.
у Zend_Controller_Front есть такая замечательная вещь как маршрутизаторы ;)
Да. Но слишком сильная заточка под /key/value/ (концепт /vdir1/vdir2/vdir3/ реализуется некрасиво)
почему же, можно настроить и на "концепт /vdir1/vdir2/vdir3/" и на какой угодно = ), Zend_Controller_Router_Route_Regex на самом деле творит чудеса = ) тем более что доступ ко все переменным запроса идет через объект Request.
Некрасиво, факт. Потому что всё остальное так или иначе заточено под формат "модуль-контроллер-действие", тогда как троичность этой конструкции весьма условна. Но делать нечего, корячимся...
Всё же меня всегда удивлял такой подход к делу: возьмём не самые быстрые технологии для хранения данных, не самый эффективный по производительности язык программирования, а потом начнём все оптимизировать... То есть, я тут не наезжаю ни на кого, меня эта ситуация просто удивляет. Наверняка я чего-то не понимаю.
Вы знаете более быстрые языки для веб программирования?
Смотря что считать web-программированием. Я, конечно, совсем не специалист в этом, но для меня web-программирование - это обмен данными с пользователем через http. И только.
Остальная часть - это просто программирование во всём его многообразии. А для разнообразного программирования есть множество инструментов с производительностью готовых программ намного превосходящей готовые программы, созданные при помощи связки php + база данных.
Остальная часть - это просто программирование во всём его многообразии. А для разнообразного программирования есть множество инструментов с производительностью готовых программ намного превосходящей готовые программы, созданные при помощи связки php + база данных.
А что такое "язык для веб-программирования"? Я за последние лет 5 участвовал в создании не одного веб-проекта. Использовалась C++ и Java в основном. PHP - один раз для вспомогтельного сайта. Считать ли Java языком веб-программирования?
Ява.
Возможно, мод_перл.
Возможно, мод_перл.
Вы учитывали скорость разработки в оценке? Даже если PHP в этом случае несколько медленнее, то на сэкономленные на зарплате программистов деньги (т.к. выше скорость разработки и ниже ее сложность) можно установить немного более мощный сервер, на котором все будет работать не медленнее.
Еще я слышал, правда из не очень авторитетных источников, что PHP с оптимизатором не уступает Яве по производительности.
Еще я слышал, правда из не очень авторитетных источников, что PHP с оптимизатором не уступает Яве по производительности.
Ну, вопрос же был именно про скорость исполнения.
Но раз уж вы про скорость разработки...
Чем скорость разработки на яве меньше скорости разработки на пхп??? Я занимался и тем и другим. Мой опыт показывает, что на пхп существенно медленнее из-за тошнотворного синтаксиса, [список прочих общеизвестных уродств пхп] и существенно худшей поддержки со стороны IDE.
Перл я сильно трогать не буду, давно это было... Но тоже не понимаю где там могут быть тормоза со скоростью разработки. Писать на перле приятнее, чем на пхп :). Если не лезть в дебри, то писать на перле можно в очень похожем на пхп стиле, учитывая то, что пхп и был рождён как очень сильно усечённое подмножество перла с косметическими отличиями :). Если не касаться ОО, конечно. Как сейчас в перле с ОО я не в курсе, а во времена оны было, конечно, за уши притянуто и не сильно просто в использовании. Если так и осталось, то да, тут перл по скорости и удобству разработки проиграет, наверное.
Но раз уж вы про скорость разработки...
Чем скорость разработки на яве меньше скорости разработки на пхп??? Я занимался и тем и другим. Мой опыт показывает, что на пхп существенно медленнее из-за тошнотворного синтаксиса, [список прочих общеизвестных уродств пхп] и существенно худшей поддержки со стороны IDE.
Перл я сильно трогать не буду, давно это было... Но тоже не понимаю где там могут быть тормоза со скоростью разработки. Писать на перле приятнее, чем на пхп :). Если не лезть в дебри, то писать на перле можно в очень похожем на пхп стиле, учитывая то, что пхп и был рождён как очень сильно усечённое подмножество перла с косметическими отличиями :). Если не касаться ОО, конечно. Как сейчас в перле с ОО я не в курсе, а во времена оны было, конечно, за уши притянуто и не сильно просто в использовании. Если так и осталось, то да, тут перл по скорости и удобству разработки проиграет, наверное.
любую технологию надо оптимизировать и "подтачивать" под под определенные нужды, если ничего этого не делать, даже самую хорошую технологию и самый лучший язык можно превратить в нечто ужасное, я думаю.
Да. Но у php + bd есть явное ограничение сверху на степень заточенности.
"ограничение сверху на степень заточенности" — уж слишком абстрактное понятие; идеализировать любой инструментарий людской деятельности можно (в теории, и в попытках — на практике) бесконечно (на протяжении жизни человечества), но, жить и работать нам с вами нужно сейчас и сегодня... сейчас и сегодня...
Многие очень крупные компании нисколько не пугаются использовать связки php+mysql, python+postgre и другие варианты, пока эти связки работают и решают насущные задачи...
Многие очень крупные компании нисколько не пугаются использовать связки php+mysql, python+postgre и другие варианты, пока эти связки работают и решают насущные задачи...
Проблема не в производительности языка, а в том кто и как пишет приложения, слишком низкий проходной уровень языка - это и проблема и успех самого языка, т.е. если перенести это какой-нить абстрактный язык это выглядело бы это так:
- программист выучил Java/C#/C++ за 24 часа по книге для чайников
- ему ставят задачу написать программку для работы с БД (какой-нить телефонный справочник)
- все работает, но с увиличением кол-ва записей начинает программа загибаться, т.к. юнец для того чтобы посчитать кол-во записей в таблицах - выгребает все записи, а потом считает кол-во итемов в массиве путем перебора цикла(1)
- но "мега гуру" говорят - да ты вот этак сделай перебор цикла будет на ХХ% быстрее (это про блошиную оптимизацию - 5 и 7)
- после приходит реальный гуру, находит сие неподобство, объясняет что да как, а заодно и говорит, что при компиляции лучше выставить такие-то галочки - т.к. их нужно всегда выставлять для финальной компиляции - и будет быстрее работать (это по пункту 10)
- программист выучил Java/C#/C++ за 24 часа по книге для чайников
- ему ставят задачу написать программку для работы с БД (какой-нить телефонный справочник)
- все работает, но с увиличением кол-ва записей начинает программа загибаться, т.к. юнец для того чтобы посчитать кол-во записей в таблицах - выгребает все записи, а потом считает кол-во итемов в массиве путем перебора цикла(1)
- но "мега гуру" говорят - да ты вот этак сделай перебор цикла будет на ХХ% быстрее (это про блошиную оптимизацию - 5 и 7)
- после приходит реальный гуру, находит сие неподобство, объясняет что да как, а заодно и говорит, что при компиляции лучше выставить такие-то галочки - т.к. их нужно всегда выставлять для финальной компиляции - и будет быстрее работать (это по пункту 10)
рабочая это имеется ввиду production сервер как я понял :)
ну насчет персистентных коннектов к базе можно поспорить.
Во-первых, они работают только когда PHP установлен как модуль Apache, что не всегда хорошо.
Во-вторых, чтобы нативно работать с MySQL 4.1 и новее без использования старых методов авторизации и устаревших функций, нужно использовать MySQLi расширение/функции. Они не поддерживают постоянные соединения, увы. Как и интерфейсы ко многим другим СУБД. Поэтому вся оптимизация работы с БД идет через правильные и оптимизированные запросы и уменьшение их количества.
Насчет акселераторов - согласен.
Во-первых, они работают только когда PHP установлен как модуль Apache, что не всегда хорошо.
Во-вторых, чтобы нативно работать с MySQL 4.1 и новее без использования старых методов авторизации и устаревших функций, нужно использовать MySQLi расширение/функции. Они не поддерживают постоянные соединения, увы. Как и интерфейсы ко многим другим СУБД. Поэтому вся оптимизация работы с БД идет через правильные и оптимизированные запросы и уменьшение их количества.
Насчет акселераторов - согласен.
0. ... и комментарии.
1. Запустите профайлинг любого вашего проекта, который работает с БД. Я готов поспорить, что время работы с БД будет занимать не меньше половины времени работы скрипта
2. про оптимизатор и опкод это в догонку к предыдущей статье, где всякими извращениями над исходных кодом пытались его "оптимизировать".
Автору: Молодец, согласен со всем, кроме обустройства девелоперской машины. Год проработал с LAMP в vmWare, вспоминаю как страшный сон. Денвер намного практичнее и удобнее. И не понятно зачем _разработчику_ акселератор. Быстрее он от этого писть не будет, точно
1. Запустите профайлинг любого вашего проекта, который работает с БД. Я готов поспорить, что время работы с БД будет занимать не меньше половины времени работы скрипта
2. про оптимизатор и опкод это в догонку к предыдущей статье, где всякими извращениями над исходных кодом пытались его "оптимизировать".
Автору: Молодец, согласен со всем, кроме обустройства девелоперской машины. Год проработал с LAMP в vmWare, вспоминаю как страшный сон. Денвер намного практичнее и удобнее. И не понятно зачем _разработчику_ акселератор. Быстрее он от этого писть не будет, точно
>> И не понятно зачем _разработчику_ акселератор. Быстрее он от этого писть не будет, точно
Окружение, приближенное к боевому на девелоперской машине нужно по одной простой причине: для постоянного контроля реальной (близкой к реальной) скорости и вычисления узких мест "на лету". Вы должны всегда быть в курсе, что происходит в общей системе сервера и как работают его части вместе.
Топик написан все же с прицелом на высокую производительность.
Окружение, приближенное к боевому на девелоперской машине нужно по одной простой причине: для постоянного контроля реальной (близкой к реальной) скорости и вычисления узких мест "на лету". Вы должны всегда быть в курсе, что происходит в общей системе сервера и как работают его части вместе.
Топик написан все же с прицелом на высокую производительность.
> Я готов поспорить, что время работы с БД будет занимать не меньше половины времени работы скрипта
Вы проиграете... При использовании фреймворков до 60% (в особо экстремальных случаях) занимают require_once
Вы проиграете... При использовании фреймворков до 60% (в особо экстремальных случаях) занимают require_once
>> персистент коннекшен к базе снижает накладные расходы почти до нуля - дальше все зависит от ваших познаний БД.
Похоже вы нашли серебряную пулю :)
>> козе боян? на моей рабочей машине я хочу отлаживать код, а не акселерировать
Отлаживайте, тестируйте, вылавливайте баги, но об оптимизации забудьте
Похоже вы нашли серебряную пулю :)
>> козе боян? на моей рабочей машине я хочу отлаживать код, а не акселерировать
Отлаживайте, тестируйте, вылавливайте баги, но об оптимизации забудьте
Может быть, отсутствие трудосустройства у автора даст ему повод задуматься, почему ему не нужно выставлять свою эгцентричность напоказ.
Это пять ;)
Не буду ничего писать, Давыдов уже прожег на тему прямых путей ;)
Не буду ничего писать, Давыдов уже прожег на тему прямых путей ;)
хех, со здоровым юмором и по больному месту :)
такое впечатление что автор помахал красной тряпочкой перед php-программистами и хочет поиграть в торреодора
автору респект и уважуха :)
Со многими пунктами не согласен.
В частности, пока есть что оптимизировать и что даст после оптимизации значительный прирост производительности - нужно оптимизировать. И только потом прибегать к кешированию. Ибо кеширование - не всегда хорошо (например, данные могут обновляться так часто, что кеш будет перестраиваться не реже или ненамного реже, чем загрузка страницы с этими данными - смысл тогда в кеше?), а реализовать его иногда бывает сложнее, чем оптимизировать несколько участков кода. Поэтому правильный путь нужно выбирать по ситуации, а не сразу кидаться кешировать все и вся.
В частности, пока есть что оптимизировать и что даст после оптимизации значительный прирост производительности - нужно оптимизировать. И только потом прибегать к кешированию. Ибо кеширование - не всегда хорошо (например, данные могут обновляться так часто, что кеш будет перестраиваться не реже или ненамного реже, чем загрузка страницы с этими данными - смысл тогда в кеше?), а реализовать его иногда бывает сложнее, чем оптимизировать несколько участков кода. Поэтому правильный путь нужно выбирать по ситуации, а не сразу кидаться кешировать все и вся.
Статья-источник про советы по оптимизации скорее носила ознакомительных характер, аля Оптимизация программ на PHP без изменений алгоритмов от Бородина. Причем ключевое слово тут «изменений» и «алгоритмов».
кеш, акселерация и прочее это, несомненно, очень хорошо =) просто мега хорошо и порой действительно спасает. Но не стоит забывать о оптимизации алгоритмов, на каком бы языке они небыли бы изложены. В последнее время много выскочек пропагандируют кеши и акселерации, а в итоге народ с сертификатом повышения квалификации из Бауманки пишет полнейший говнокод, который спасает только кеш и если кеш слетает (а слетает он часто на хороших нагрузках. Скажем, на одном из моих проектов 20 серверов с мемкешем, частенько то один то другой виснут) говнокод валит сервак.
Люди, изучайте кеширование и акселерацию только тогда, когда у вас уже возникли проблемы с нагрузкой и вы уже потратили минимум пару недель на оптимизацию алгоритмов. Иначе станете говнокодерами, а не программистами.
кеш, акселерация и прочее это, несомненно, очень хорошо =) просто мега хорошо и порой действительно спасает. Но не стоит забывать о оптимизации алгоритмов, на каком бы языке они небыли бы изложены. В последнее время много выскочек пропагандируют кеши и акселерации, а в итоге народ с сертификатом повышения квалификации из Бауманки пишет полнейший говнокод, который спасает только кеш и если кеш слетает (а слетает он часто на хороших нагрузках. Скажем, на одном из моих проектов 20 серверов с мемкешем, частенько то один то другой виснут) говнокод валит сервак.
Люди, изучайте кеширование и акселерацию только тогда, когда у вас уже возникли проблемы с нагрузкой и вы уже потратили минимум пару недель на оптимизацию алгоритмов. Иначе станете говнокодерами, а не программистами.
т.е. вроде ООП переболели, если год назад я бы заявил что ООП отстой и можно обойтись статическими классами и процедурами на худой конце — меня все банили, то теперь просто минимуют по тихой. Выросла новая болячка — кеш =) теперь все считают что панацея это кеш.
Обойтись чем-то "более простым" можно всегда, не вопрос:)
Но разобраться в этом более простом через 2 месяца будет уже невозможно.
Но разобраться в этом более простом через 2 месяца будет уже невозможно.
Как в той рекламе: «ты просто не умеешь их готовить». Если за 2 месяца ты не можешь разобраться в своем коде, то о чем можно говорить.
... а в чужом? :) Глобализация уже в полный рост имеет место: фреймворки там всякие и пр.
Как известно, ОО* - это больше средство повторного использования кода. Имеется ввиду, повторного использования другим человеком. Т.е. - это больше некие репрезентативные функции. И это ОО-подходу вполне удается. Я не очень представляю себе Zend Framework в не-ОО исполнении. Хотя нет - представляю. Получится как раз такая лапша, за которую многие так не любят php. Конечно, можно сделать так, что это все будет работать, но...
В связи с этим вспоминается нашумевший тут диспут :) по поводу правильной настройки винды, что б не падало и не глючило. Лично я предпочитаю не бороться с тем, чего можно избежать.
Как известно, ОО* - это больше средство повторного использования кода. Имеется ввиду, повторного использования другим человеком. Т.е. - это больше некие репрезентативные функции. И это ОО-подходу вполне удается. Я не очень представляю себе Zend Framework в не-ОО исполнении. Хотя нет - представляю. Получится как раз такая лапша, за которую многие так не любят php. Конечно, можно сделать так, что это все будет работать, но...
В связи с этим вспоминается нашумевший тут диспут :) по поводу правильной настройки винды, что б не падало и не глючило. Лично я предпочитаю не бороться с тем, чего можно избежать.
Повторное использование кода? Для этого существует документация и структуры, которые, кстати, очень активно юзает ОО подход. Те же классы не имеют отношения к ОО, пока на основе их не строятся объекты. Организовав статичные классы мы имеем те же плюсы для вас — неймспейсы по сути, плюс отказываемся от объектов.
И всего этого гемороя можно счастливо избежать.
По крайней мере мне - удается :)
По крайней мере мне - удается :)
геморой вы зарабатываете, а не избегаете.
Я дела:
1. Разработавыю класс
2. Работаю с ним.
Вы делаете:
1. Разрабатываете класс.
2. Не забываете объявлять объекты на основе класса.
3. Работаете с объектом.
Я дела:
1. Разработавыю класс
2. Работаю с ним.
Вы делаете:
1. Разрабатываете класс.
2. Не забываете объявлять объекты на основе класса.
3. Работаете с объектом.
:) Моя схема работы совсем не совпадает: я предпочитаю начинать сначала - с проектирования...
Если делать именно так, как указано у Вас - да, это сложно. Потому как потом начинается бардак и анархия: обязательно что-нибудь забываем :)
Есть основное отличие в подходах, на котором мы никогда не сойдемся: организация мозгов. ОО требует большей строгости, но я хорошо знаю, что лучше сначала два часа подождать, за то потом - за 5 минут долететь. И потом уже летать неоднократно :)
Если делать именно так, как указано у Вас - да, это сложно. Потому как потом начинается бардак и анархия: обязательно что-нибудь забываем :)
Есть основное отличие в подходах, на котором мы никогда не сойдемся: организация мозгов. ОО требует большей строгости, но я хорошо знаю, что лучше сначала два часа подождать, за то потом - за 5 минут долететь. И потом уже летать неоднократно :)
Эту статью можно прочитать один раз и забыть, она еще для PHP3 кажись писалась, и уже давно не актуальна!!!
Ну зачем да так сразу - неудачник. В команде должен быть 1 человек, который хорошо знает тонкости php, чтобы соптимизировать framework. А потом да, потом нафиг такую оптимизацию.
В фавор. И - на ночь читать.
1. "узкое место _всегда_ - БД." - Если руки из ЖОПЫ , то ДА оно.
2. "Какой бы ерундой вы не занимались - 30-60% производительности (возможно и больше) PHP-кода решит правильно выбранный и настроенный акселератор." - см. пункт 1, я не применяю акселераторов, код получаеться все ровно быстрый.
3. ООП - едиственный правельный метод написания, кроме
4. 5 пункт , я вообще не понял, о чем Афтар говорит(RSS-контроллере Это что за зверь).
5. Пункт 8 справедлив лиш в том случае если совокупный доход раза в 4 больше платы за сервак.
6. 10 пункт, я уже говорил, у меня на 100 проц. движок динамичный. кеш не нужен, так как у меня нет статичных объектов в принципе(не надо меня шпынять за это, я сам выбрал гибкость в упор статике ).
интернет бизнес
2. "Какой бы ерундой вы не занимались - 30-60% производительности (возможно и больше) PHP-кода решит правильно выбранный и настроенный акселератор." - см. пункт 1, я не применяю акселераторов, код получаеться все ровно быстрый.
3. ООП - едиственный правельный метод написания, кроме
- Вы школьник
- Вы пишите только для себя
- Вы не будите никогда приметь этот код
- вы никогда не смотрите, на то , что написали(если нужна новая ф.(дада, ни клас и ни метод, а иммено ф. так как вы не пишите на ООП) вам проще написать заного ее, опять отловить все ошибки во время ее написания )
4. 5 пункт , я вообще не понял, о чем Афтар говорит(RSS-контроллере Это что за зверь).
5. Пункт 8 справедлив лиш в том случае если совокупный доход раза в 4 больше платы за сервак.
6. 10 пункт, я уже говорил, у меня на 100 проц. движок динамичный. кеш не нужен, так как у меня нет статичных объектов в принципе(не надо меня шпынять за это, я сам выбрал гибкость в упор статике ).
интернет бизнес
1. Оно узкое место, как раз если руки не из ЖОПЫ.
3. Этим надо переболеть
4. А вы rss отдаете контроллером, который отдает обычную версию сайта?
5. Зарплаты растут, серваки дешевеют. Смотрим в будущее.
3. Этим надо переболеть
4. А вы rss отдаете контроллером, который отдает обычную версию сайта?
5. Зарплаты растут, серваки дешевеют. Смотрим в будущее.
1. я знаю решения, на окторых 10 пользователей умирало в виду, что каждое обращение к базе убивало сервак на 100 проц.
3. не понял
4. рсс - это лента новостей ?, если да, то у меня есть XSLT шаблон и XML(данные с сайта), я трансформирую получается лента, какой контроллер то ?
5. люблю знаете ли работать на себя.
3. не понял
4. рсс - это лента новостей ?, если да, то у меня есть XSLT шаблон и XML(данные с сайта), я трансформирую получается лента, какой контроллер то ?
5. люблю знаете ли работать на себя.
1. Если руки из ЖОПЫ, то любое место - узкое.
3. Просто ООП не панацея, есть случаи, когда его не удобно применять.
4. Рсс это не обязательно лента новостей(Точнее даже это совсем не лента новостей). Довольно часто приходится немного разные данные использовать в рсс и самом сайте.
5. VPS-ка простая стоит 150 рублей, это как надо программировать, чтобы доход был меньше 600 рублей?)
3. Просто ООП не панацея, есть случаи, когда его не удобно применять.
4. Рсс это не обязательно лента новостей(Точнее даже это совсем не лента новостей). Довольно часто приходится немного разные данные использовать в рсс и самом сайте.
5. VPS-ка простая стоит 150 рублей, это как надо программировать, чтобы доход был меньше 600 рублей?)
хороший запрос отрабытывает 0,01 секунды.
узкие же места, о которых говорит автор - разница между кавычками, единицы тактов процессора. по сравнению с ними БД - действительно узкое место.
понятно?
узкие же места, о которых говорит автор - разница между кавычками, единицы тактов процессора. по сравнению с ними БД - действительно узкое место.
понятно?
с каких пор ООП - _единственный_ правильный метод?
с таких, что с ооп намного удобночитаемый код.
у меня работа связана с разбором говнокода, и получается , что очень много когда написаного разными людьми мне приходится просматривать и обрабатывать, отсюда то и говорю.
у меня работа связана с разбором говнокода, и получается , что очень много когда написаного разными людьми мне приходится просматривать и обрабатывать, отсюда то и говорю.
В пределах одной компании (группы разработчиков) отлично решается путем введения жёстких требований к оформлению кода - как именовать переменные и функции, как форматировать код и т.д., у меня например такое требования занимают три экрана 1280х1024 10-ым шрифтом :) Не хочет программист-исполнитель соответствовать этим требованиям, мотивируя тем что "мне удобнее писать так" - придется с ним расстаться. Это _хороший_ подход и он _работает_. И код получается не менее хорошо читаемым чем при ООП. Он просто - _другой_. А другой - не всегда значит плохой.
1. хорошо оформленный функциональный код может быть не менее удобочитаемым, чем ООП. А плохо оформленный ООП код может быть точно таким же нечитаемым, как плохой функциональный. Пример:
можно написать некоторую систему на ООП. Допустим у нас есть класс для обработки и вывода информации о людях.
ООП: $man->getHTML();
функциональный код: manGetHTML или getHTMLForMan() или как угодно иначе обзовите функцию. Разница - в отсутствии символа ->, но его и заменить можно чем-то если вам удобнее с разделителями.
На уровне машины:
функциональное программирование: найдем адрес функции, запомним место, на котором выполняется вызов функции, перейдем по адресу функции, выполним ее код, вернем результат куда нужно и продолжим выполнение программы.
ООП: обработаем класс и запишем его в память, создадим объект класса и запишем в память, при вызове метода объекта найдем адрес объекта, запомним откуда мы уходим в класс, найдем в классе адрес функции.....
можно написать некоторую систему на ООП. Допустим у нас есть класс для обработки и вывода информации о людях.
ООП: $man->getHTML();
функциональный код: manGetHTML или getHTMLForMan() или как угодно иначе обзовите функцию. Разница - в отсутствии символа ->, но его и заменить можно чем-то если вам удобнее с разделителями.
На уровне машины:
функциональное программирование: найдем адрес функции, запомним место, на котором выполняется вызов функции, перейдем по адресу функции, выполним ее код, вернем результат куда нужно и продолжим выполнение программы.
ООП: обработаем класс и запишем его в память, создадим объект класса и запишем в память, при вызове метода объекта найдем адрес объекта, запомним откуда мы уходим в класс, найдем в классе адрес функции.....
Пример не катит. ООП это не занос набора функций в класс.
в вебе так часто получается, особенно если работа идет над какой-то CMS средней сложности... хотя возможно пример действительно не очень вышел. Но, я надеюсь, идея понятна
кстати говоря, в данном примере вообще пофигу использовали ли мы классы только как контейнеры для функций или использовали больше возможностей. одна строка, которая вполне может находится внутри метода класса, который выполняет действия над самим объектом этого класса.
Это попытка показать, что нет каких-то особенных различий в удобочитаемости ООП кода и неООП кода. Плюс, что делает машина при том или ином подходе.
Это попытка показать, что нет каких-то особенных различий в удобочитаемости ООП кода и неООП кода. Плюс, что делает машина при том или ином подходе.
Если рассматривать с этой стороны то полностью солидарен. Только плз не надо говорить о скорости работы если бы в контексте пхп4 бы принял этот аргумент то в пхп5 это будет экономия на спичках.
Проблема в том что очень мало видел грамотно спроектированных приложений написанных в функциональном стиле. Читабельный, да это часто. Но если говорить о модификации и росте то тут по сравнению с ООП стилем гораздо реже. Кроме друпала ничего даже на ума не приходит.
Подчеркну что я говорю о только своем опыте (4 года).
Проблема в том что очень мало видел грамотно спроектированных приложений написанных в функциональном стиле. Читабельный, да это часто. Но если говорить о модификации и росте то тут по сравнению с ООП стилем гораздо реже. Кроме друпала ничего даже на ума не приходит.
Подчеркну что я говорю о только своем опыте (4 года).
Экономия на спичках - вопрос спорный. В ряде случаев, в небольших проектах - да. В крупных и сложных - совсем нет.
Если у вас простой корпоративный сайт с небольшим кол-вом функций и небольшой посещаемостью, конечно, такая оптимизация чего-либо значительного не даст.
Но если взять крупный портал или сложную систему (например, очень развитую CRM), то такой подход может в итоге помочь. Пусть не так сильно, как оптимизация запросов к БД, но (я считаю, что оптимизируем не только работу с БД) все же даст прирост производительности.
Как я выше писал, для вызова одного метода грубо говоря совершается в два раза больше операций. Каждая требует времени и памяти. В случае простой системы из двух-трех независимых объектов или с крайне неглубокой иерархией классов и объектов нет смысла заморачиваться на этот счет.
Но крупный портал/CRM может содержать десятки классов, сотни объектов, каждый из которых в свою очередь содержит еще десятки объектов. Представьте, сколько в этом случае переходов с одного адреса памяти на другой потребуется в ряде случаев даже для вызова одного метода. А учитывая, сколько раз происходят подобные вызовы и сколько конструкторов мы запускаем, сколько объектов храним в памяти? Прилично выходит в итоге-то.
Мне как-то повезло сравнить в производительности две CMS средней величины. Одна написана на ООП. Вторая - чисто функциональный подход. Набор функций один в один. Обе системы достаточно качественно написаны. Но разница в производительности в реальных условиях оказалась вполне достаточной, чтобы отказаться от системы с ООП.
Если у вас простой корпоративный сайт с небольшим кол-вом функций и небольшой посещаемостью, конечно, такая оптимизация чего-либо значительного не даст.
Но если взять крупный портал или сложную систему (например, очень развитую CRM), то такой подход может в итоге помочь. Пусть не так сильно, как оптимизация запросов к БД, но (я считаю, что оптимизируем не только работу с БД) все же даст прирост производительности.
Как я выше писал, для вызова одного метода грубо говоря совершается в два раза больше операций. Каждая требует времени и памяти. В случае простой системы из двух-трех независимых объектов или с крайне неглубокой иерархией классов и объектов нет смысла заморачиваться на этот счет.
Но крупный портал/CRM может содержать десятки классов, сотни объектов, каждый из которых в свою очередь содержит еще десятки объектов. Представьте, сколько в этом случае переходов с одного адреса памяти на другой потребуется в ряде случаев даже для вызова одного метода. А учитывая, сколько раз происходят подобные вызовы и сколько конструкторов мы запускаем, сколько объектов храним в памяти? Прилично выходит в итоге-то.
Мне как-то повезло сравнить в производительности две CMS средней величины. Одна написана на ООП. Вторая - чисто функциональный подход. Набор функций один в один. Обе системы достаточно качественно написаны. Но разница в производительности в реальных условиях оказалась вполне достаточной, чтобы отказаться от системы с ООП.
Насчет роста системы и расширяемости, на мой взгляд это недостаток архитектуры большинства неООП систем - ООП тут не причем. неООП системы разрабатывались по большей части когда-то давно. Затем все ринулись использовать везде где нужно и не нужно ООП. Начали прорабатывать более расширяемые системы, но уже проектировали их с ипользованием ООП. А про функциональный подход все забыли, потому что в нюансах не разбирались, или просто на моду повелись или по каким-либо еще причинам.
поддержку полиформизма и инкапсуляцию тоже функциями сможете набросать ? :)
для подавляющего большинства операций, производимых CMS и аналогичными web-based системами, она не нужна. а вот когда нужно, тогда да - ООП.
Я ж не сказал, что вообще никогда не нужно его использовать. В большинстве случаев можно и нужно обойтись без него.
Я ж не сказал, что вообще никогда не нужно его использовать. В большинстве случаев можно и нужно обойтись без него.
А почему я такого мнения, я писал выше и описывал процесс с точки машинных операций плюс еще пара слов о синтаксисе и удобству.
А с каких это пор ооп код намного читаем ? да еще написаного разными людьми.
Вообще-то что ооп, что функции написанные разными людьми,
без соблюдения общих правил все равно приведет к нечитаемости кода.
И это факт.
А если один человек будет писать, или группа людей, которые соблюдают единые (внутри конкретно взятого проекта) правила, то все будет читаемо. И не важно, ооп это или функции. Я видел проекты, написаные без ооп и очень легко читаемые. Даже лучше чем некоторые написанные на ооп.
Почему-то ооп код считают более читаеым.
Не в ооп дело, а в программисте, который пишет код.
Если руки из одного места ростут, то ооп подходт не поможет.
написания кода
Вообще-то что ооп, что функции написанные разными людьми,
без соблюдения общих правил все равно приведет к нечитаемости кода.
И это факт.
А если один человек будет писать, или группа людей, которые соблюдают единые (внутри конкретно взятого проекта) правила, то все будет читаемо. И не важно, ооп это или функции. Я видел проекты, написаные без ооп и очень легко читаемые. Даже лучше чем некоторые написанные на ооп.
Почему-то ооп код считают более читаеым.
Не в ооп дело, а в программисте, который пишет код.
Если руки из одного места ростут, то ооп подходт не поможет.
написания кода
Есть такое мнение: "На ООП проще написать плохой код, но потенциальные возможности также выше."
А еще такое: "Зависит от стиля мышления".
Спор, получившийся ниже, довольно бессмысленен. Хоть бы одну ссылку на исследование дали.
А еще такое: "Зависит от стиля мышления".
Спор, получившийся ниже, довольно бессмысленен. Хоть бы одну ссылку на исследование дали.
1. "узкое место _всегда_ - БД." - Если руки из ЖОПЫ , то ДА оно.
А если нет, то какое? Расскажите, пожалуйста, какое место самое узкое, если руки не из жопы. И не надо мне говорить, что если руки не из жопы, то и узких мест нет.
3. ООП - едиственный правельный метод написания
Поверьте, как человек, руководивший проектом на 40K строк, сделанного по принципу "OOP for the sake of OOP", это очень глупая позиция. ООП в PHP действительно намного медленнее, особенно когда доходит до конструкций типа $this->controller->template->get('foobar', array('a' => $a)); вместо include 'templates/foobar.php'.
4. 5 пункт , я вообще не понял, о чем Афтар говорит(RSS-контроллере Это что за зверь).
Ну если вы не можете, зная что такое RSS и что такое контроллер, догадаться, чем может быть RSS-контроллер (хотя я тоже в первый раз такое слышу), чести это вам не добавляет. Или не знаете?
5. Пункт 8 справедлив лиш в том случае если совокупный доход раза в 4 больше платы за сервак.
Если вы не можете позволить себе виртуальный сервер, возможно, есть смысл подумать о смене профессии.
6. 10 пункт, я уже говорил, у меня на 100 проц. движок динамичный. кеш не нужен, так как у меня нет статичных объектов в принципе(не надо меня шпынять за это, я сам выбрал гибкость в упор статике ).
Ну и дурак. (аче, можно же под конец резюмировать?)
А если нет, то какое? Расскажите, пожалуйста, какое место самое узкое, если руки не из жопы. И не надо мне говорить, что если руки не из жопы, то и узких мест нет.
3. ООП - едиственный правельный метод написания
Поверьте, как человек, руководивший проектом на 40K строк, сделанного по принципу "OOP for the sake of OOP", это очень глупая позиция. ООП в PHP действительно намного медленнее, особенно когда доходит до конструкций типа $this->controller->template->get('foobar', array('a' => $a)); вместо include 'templates/foobar.php'.
4. 5 пункт , я вообще не понял, о чем Афтар говорит(RSS-контроллере Это что за зверь).
Ну если вы не можете, зная что такое RSS и что такое контроллер, догадаться, чем может быть RSS-контроллер (хотя я тоже в первый раз такое слышу), чести это вам не добавляет. Или не знаете?
5. Пункт 8 справедлив лиш в том случае если совокупный доход раза в 4 больше платы за сервак.
Если вы не можете позволить себе виртуальный сервер, возможно, есть смысл подумать о смене профессии.
6. 10 пункт, я уже говорил, у меня на 100 проц. движок динамичный. кеш не нужен, так как у меня нет статичных объектов в принципе(не надо меня шпынять за это, я сам выбрал гибкость в упор статике ).
Ну и дурак. (аче, можно же под конец резюмировать?)
Нащёт ООП поспорил бы. Особенно применительно к web-у. Почти 8-летний опыт разработки под web, сначала на чистом С, потом perl, php а так же управление коллективом разработчиков дает мне уверенность говорить что при числе разработчиков < 10 вполне удается работать используя ТОЛЬКО функциональный подход, используя ООП только для вызова внешних (не самописных) классов.
Функциональный подход на нефункциональных языках? Да, это посильнее "Фауста" Гёте. И очень сильно посильнее предложенной кем-то выше эмуляции ООП-а, без использования встроенных в язык ООП средств (вотще какая-то дурная идея).
Однако, вернёмся к функциональному подходу - почему си, перл, пхп, а не... Хм.. А что там у нас есть.. А, вспомнил - видел как-то веб-фреймворк на схеме. Он даже где-то на соурсфорже лежит. Это же жутко неудобно - писать функциональные программы на имеритивном языке.
Однако, вернёмся к функциональному подходу - почему си, перл, пхп, а не... Хм.. А что там у нас есть.. А, вспомнил - видел как-то веб-фреймворк на схеме. Он даже где-то на соурсфорже лежит. Это же жутко неудобно - писать функциональные программы на имеритивном языке.
Сорри поторопился - естественно имелся в виду не функциональная а процедурно-ориентированная парадигма в процедурных языках.
p.s. Имеритивных языков не знаю, знаю императивные. Хотя могу и ошибаться, ибо курс лингвистического обеспечения у меня был 11 лет назад.
p.s. Имеритивных языков не знаю, знаю императивные. Хотя могу и ошибаться, ибо курс лингвистического обеспечения у меня был 11 лет назад.
Императивные, конечно. Описка.
Но вы тоже удивили в комментариях выше - вводите жёсткие правила оформления-именования, увольняете за несоблюдение и всё ради чего? Чтобы ваши процедурные программы читались не хуже оо-шных? А смысл? Не проще ли писать оо? Ведь это удобнее. Какие-то религиозные принципы запрещают пользоваться оо? Ну, то есть с сями я понимаю, ситуация может того требовать, но в более других языках... Смысл?
Но вы тоже удивили в комментариях выше - вводите жёсткие правила оформления-именования, увольняете за несоблюдение и всё ради чего? Чтобы ваши процедурные программы читались не хуже оо-шных? А смысл? Не проще ли писать оо? Ведь это удобнее. Какие-то религиозные принципы запрещают пользоваться оо? Ну, то есть с сями я понимаю, ситуация может того требовать, но в более других языках... Смысл?
Смысл - иметь наглядный, хорошо управляемый и поддерживаемый код проекта. В то время, когда проект начинал писаться было принято такое решение - не использовать ООП вообще (кроме вышеоговоренных случаев использования заимствованных библиотек, интерфейс которых предполагает не процедурный а объектный доступ). Этот подход показал свою жизнеспособность. Кроме того я лично не считаю что ООП удобнее во всех ситуациях.
Выглядит либо как религия, либо как будто принимающий это решение просто не понимал оо парадигму, поэтому решил запретить. :)
Я понимаю смысл этого в си, как уже говорил. Но в таком уродстве, как пхп писать без оо - ужос, по-моему. То, что так можно делать и это жизнеспособно, это ясно-понятно. Что во всех ситуациях оо не панацея, тоже, но в веб разработке, да на пхп... Выглядит странно. Я даже в крошечных проектах как минимум оо-обёртку вокруг дб приделываю. Экономит ну очень много времени, сил и нервов.
Я понимаю смысл этого в си, как уже говорил. Но в таком уродстве, как пхп писать без оо - ужос, по-моему. То, что так можно делать и это жизнеспособно, это ясно-понятно. Что во всех ситуациях оо не панацея, тоже, но в веб разработке, да на пхп... Выглядит странно. Я даже в крошечных проектах как минимум оо-обёртку вокруг дб приделываю. Экономит ну очень много времени, сил и нервов.
Хм... А просветите, пожалуста, начинающего, чем именно ООП реально, и дейтсивтельно, лучше процедурного стиля?
Я, например, выделил пока для себя только один возможный плюс: расширяемость, в случае с Perl — через @ISA;
Но это частично обходится объявлением функции прямо в namespace целевого package (SomeApp, к примеру) через typeglob'ы и no strict 'refs';. Остается только вопрос, как её Export'ировать в другие модули при use SomeApp.
Другой вариант - глобально эскпортированный во время
В общем, плюс ООП: расширяемость. Ещё плюсы у ООП есть?
Я, например, выделил пока для себя только один возможный плюс: расширяемость, в случае с Perl — через @ISA;
Но это частично обходится объявлением функции прямо в namespace целевого package (SomeApp, к примеру) через typeglob'ы и no strict 'refs';. Остается только вопрос, как её Export'ировать в другие модули при use SomeApp.
Другой вариант - глобально эскпортированный во время
use хэш анонимных функций в роли объекта.В общем, плюс ООП: расширяемость. Ещё плюсы у ООП есть?
Конечно есть. Как ни странно, они следуют прямо из определения :)
+инкапсуляция данных
+наследование (возможно, именно это вы назвали расширяемостью)
Конечно, всё "обходится", но ведь это некрасиво, сложно в поддержке и вообще сложно.
+инкапсуляция данных
+наследование (возможно, именно это вы назвали расширяемостью)
Конечно, всё "обходится", но ведь это некрасиво, сложно в поддержке и вообще сложно.
Да, я имел ввиду именно наследование. Тоесть, кроме наследования (которое есть суть расширение методов и/или свойств объекта новыми методами, если не ошибаюсь) и возможности "прятать" переменные (свойства) — больше никаких плюсов?
Основной плюс - работа с абстракциями систем реального мира. Читайте Буча, у него всё доходчиво расписано.
О как даже! А можно, пожалуста, ссылку на подобное чтиво, или хотя бы, что конкретно искать?
А самому погуглить - никак?..
Гради Буч. Объектно-ориентированный анализ и проектирование (с примерами приложений на С++)
Гради Буч. Объектно-ориентированный анализ и проектирование (с примерами приложений на С++)
Докатились, теперь на хабре вешают ссылки как подписи к камментам.
Поскольку это не было написано выше, упомяну, что для кэширования в больших проектов удобно использовать memcached.
И не только для кэширования, но и как хранилище данных, которые не жалко потерять при перезагрузке.
И не только для кэширования, но и как хранилище данных, которые не жалко потерять при перезагрузке.
Честно говоря меня, достали уже высказывания "используйте memcached". Вы понимаете, что говорите? memcached это только один из способов хранить кэш, а не какой-то магический подход, который сделает все сам. Вы fullpage-кэш там храните?
Согласен. Плюсов у него много:
- потоковая безопасность инкремента/декремента
- соединение через сокеты (это же и самый большой минус)
- встроенный хендлер для сессий
- и еще несколько :)
Просто большинство даже не пытаются искать другие решения. А насчет fullpage я не случайно, я такой проект видел.
Другой случай - на каждом сервере стоит memcached и на нем храняться данные, специфичные для этого сервера. На вопрос почему не APC, ответили, что такого не знают.
- потоковая безопасность инкремента/декремента
- соединение через сокеты (это же и самый большой минус)
- встроенный хендлер для сессий
- и еще несколько :)
Просто большинство даже не пытаются искать другие решения. А насчет fullpage я не случайно, я такой проект видел.
Другой случай - на каждом сервере стоит memcached и на нем храняться данные, специфичные для этого сервера. На вопрос почему не APC, ответили, что такого не знают.
Извините, наболело :)
Разумеется это не серебряная пуля и тем более сам он ничего не делает, но тем кто ещё не знает о таком варианте (но работает над нагруженным проектом работающим на N серверах) нужно как минимум знать о нем.
1. Мы храним в memcached не готовые страницы (они разные и кэшировать их бессмысленно), а различные данные, которые в маленьких проектах можно на каждый запрос собирать из базы и других источников. Но в больших это становится накладно.
Разумеется нужно помнить об инвалиданции (или обновлении) кэша при изменении данных, поэтому для ненагруженных проектов это только лишнее усложнение кода.
2. В memcached хранятся данные которые вообще никогда не пишутся на диск (в базу), например число неудачных попыток ввести пароль для замедления подбора паролей. С учётом того, что некоторые пытаются подбирать пароли со скорость 100 (и больше) запросов в секунду, на sql это создаёт заметную нагрузку. А после перезагрузки мемкешеда подибральщик все равно снова упрётся в лимит и в потере этих счётчиков при перезагрузке memcached ничего страшного нет. Если поискать то в больших проектах таких данных (которые не иногда жалко терять) набирается достаточно, чтобы намmemcached сэкономить несколько SQL-серверов.
1. Мы храним в memcached не готовые страницы (они разные и кэшировать их бессмысленно), а различные данные, которые в маленьких проектах можно на каждый запрос собирать из базы и других источников. Но в больших это становится накладно.
Разумеется нужно помнить об инвалиданции (или обновлении) кэша при изменении данных, поэтому для ненагруженных проектов это только лишнее усложнение кода.
2. В memcached хранятся данные которые вообще никогда не пишутся на диск (в базу), например число неудачных попыток ввести пароль для замедления подбора паролей. С учётом того, что некоторые пытаются подбирать пароли со скорость 100 (и больше) запросов в секунду, на sql это создаёт заметную нагрузку. А после перезагрузки мемкешеда подибральщик все равно снова упрётся в лимит и в потере этих счётчиков при перезагрузке memcached ничего страшного нет. Если поискать то в больших проектах таких данных (которые не иногда жалко терять) набирается достаточно, чтобы намmemcached сэкономить несколько SQL-серверов.
"адекватного спеца по PHP в Москве - 30-45 тыс. рублей в месяц"
Я бы сказал 45-75
Я бы сказал 45-75
наконец-то кто-то высказался по существу! респект чувак.
плюсанул бы, да кармы нету.
насчет пхп с акселератором на дев-машине могу поспорить конечно... а могу и не спорить :)
насчет того что пхп5 нормальный язык.... тоже спорить не буду. :) большую часть недочетов все равно обещаются пофиксить в 6м,а синтаксис... ну, скажем так - дело привычки.
вообще нету хороших и плохих языков, есть комьюнити. в пхп оно, надо сказать, _в_среднем_ поадекватней чем в ROR'е.
А вообще надо быть полиглотом. Гетерогенные системы ftw
плюсанул бы, да кармы нету.
насчет пхп с акселератором на дев-машине могу поспорить конечно... а могу и не спорить :)
насчет того что пхп5 нормальный язык.... тоже спорить не буду. :) большую часть недочетов все равно обещаются пофиксить в 6м,а синтаксис... ну, скажем так - дело привычки.
вообще нету хороших и плохих языков, есть комьюнити. в пхп оно, надо сказать, _в_среднем_ поадекватней чем в ROR'е.
А вообще надо быть полиглотом. Гетерогенные системы ftw
6-1 обещает быть более глючным, чем 5-й. Я скептически отношусь к факту его появления.
насчет глюков - согласен, до 6.2.0 на шестерку даже смотреть смысла не будет.
но скажем так. в перспективе - пхп скорее всего станет довольно мощным all-in-one языком.
на самом он весьма неплох, что на данный момент, что в перспективе. проблема в том, что из него из-за элементарной безграмотности пытаются сделать панацею.
но скажем так. в перспективе - пхп скорее всего станет довольно мощным all-in-one языком.
на самом он весьма неплох, что на данный момент, что в перспективе. проблема в том, что из него из-за элементарной безграмотности пытаются сделать панацею.
Про зарплату "адекватного спеца по PHP" откровенно удивили. Я и за 60 найти не могу уже который месяц.
P.S.: Пользуясь случаем, если кто ищет работу программистом (PHP) - пишите. (-:
P.S.: Пользуясь случаем, если кто ищет работу программистом (PHP) - пишите. (-:
Везучий. У меня 96k никто освоить не годен.
http://phpclub.ru/talk/showthread.php?s=&threadid=107308&rand=0
http://phpclub.ru/talk/showthread.php?s=&threadid=107308&rand=0
Вот только какие мы с Вами выводы должны сделать? Предлагать по 100-150 т.р.? Но при все желании, таких товарищей единицы. А достаточно приличное количество программистов и 40 не стоит.
Приличное? А Вы, батенька, оптимист :) Если учесть, что PHP предрасположен к недотепам и "фейс-контроля" у него никакого, то и недотеп, соответственно, очень много, их в десятки раз больше, чем специалистов.
Специалист, профессионал, стоит дорого, но другие мне просто не нужны. А раз не нужны, я делаю что могу, чтоб он работал не где-либо, а именно у меня.
Специалист, профессионал, стоит дорого, но другие мне просто не нужны. А раз не нужны, я делаю что могу, чтоб он работал не где-либо, а именно у меня.
Оптимист. Увы.
Так я к тому и говорю. Я ведь тоже делаю все что я могу, что бы такие люди работали у меня. Конечно, 96 предложить не могу (у меня требования значительно скромнее), но и 60 платить за, извиняюсь, раздолбайство, опоздания, сорванные сроки и трепание нервов как-то не очень хочется. А пока, увы, это суровая действительность.
Так я к тому и говорю. Я ведь тоже делаю все что я могу, что бы такие люди работали у меня. Конечно, 96 предложить не могу (у меня требования значительно скромнее), но и 60 платить за, извиняюсь, раздолбайство, опоздания, сорванные сроки и трепание нервов как-то не очень хочется. А пока, увы, это суровая действительность.
можно тест глянуть? интересно ? :)
даю 30, нужен простой код без фреймворков
и ваш тест?)
PHP — это глобально и надёжно.
Респект. Хоть одно дельное и по сути! Единственное с чем не согласен, это с расценками:) А так, 5 балов!
Во, перечитал... Пунктик 6. Маршрутиризацией занимается на FrontController, а Router и их можно наштамповать ровно столько, сколько нужно.
Ой ща по шапке (карме) настучат
Проблема большинства PHP разработчиков в том, что большенство не разработчики а кодеры, которым только и надо писать, писать и ещё раз писать. Если человек (будущий "developer")начинает учить язык с книги "PHP для чайнегов", а перед этим в техникуме или ПТУ какя то бабушка читала им паскаль и делфи, но у человека ничего толкового из этого не вышло, ИМХО удел такого девелопера получать максимум 1000 уе (предел мечтаний), и писать свой страшный код.
Программировать надо начинать с основ теории алгоритмов. Язык программирования это всего лишь инструмент, как было выше подмечено, если человек не может найти правильное (рациональное) решение проблемы, то на каком бы языке он не писал, производительность будет страдать, будь то С++ или bash-скрипт.
PS моё ИМХО, не высосано из пальца. Я когдато учился в техникуме радиоэлектроники (сам я на радиотехнику учился), у нас было отделение программирования, так им преподавали языки или студенты вузов, или бабушки которые мне преподавали технологию производства или РЭА. Понятное дело каких программистов выпустил техникум.Те кто хотел научится, учились сами.
Проблема большинства PHP разработчиков в том, что большенство не разработчики а кодеры, которым только и надо писать, писать и ещё раз писать. Если человек (будущий "developer")начинает учить язык с книги "PHP для чайнегов", а перед этим в техникуме или ПТУ какя то бабушка читала им паскаль и делфи, но у человека ничего толкового из этого не вышло, ИМХО удел такого девелопера получать максимум 1000 уе (предел мечтаний), и писать свой страшный код.
Программировать надо начинать с основ теории алгоритмов. Язык программирования это всего лишь инструмент, как было выше подмечено, если человек не может найти правильное (рациональное) решение проблемы, то на каком бы языке он не писал, производительность будет страдать, будь то С++ или bash-скрипт.
PS моё ИМХО, не высосано из пальца. Я когдато учился в техникуме радиоэлектроники (сам я на радиотехнику учился), у нас было отделение программирования, так им преподавали языки или студенты вузов, или бабушки которые мне преподавали технологию производства или РЭА. Понятное дело каких программистов выпустил техникум.Те кто хотел научится, учились сами.
Вообщем то нормально написано, люблю импрессивные стили.
Но есть откровенный бред насчет оптимизации и держания на дэвэлопмент-тачке акселератора.
Но есть откровенный бред насчет оптимизации и держания на дэвэлопмент-тачке акселератора.
Чета стилистика текста здорово смахивает на promp-перевод с инглиша. Обычно тамошние юмористы так тонко шутят "ты отстой, ты неудачник и т.п." "На вас надет... ТАНК" - с этой фразы вообще упал.
Не важно, какой концепт вы применяете - строгое ООП (в стиле Zend Framework), функции в стиле PHP4 (или ограниченное ООП) или вообще лапшу в стиле "PHP для чайников" - ни одна из этих парадигм не даст ощутимый прирост производительности, если конечно ваши программисты не выше как минимум на голову.
Мне кажется, парадигмы применяют не столько для роста производительности, сколько для упрощения поддержки продукта в дальнейшем. От статьи остаётся ощущение, что на концепты можно забить, так как роста производительности они не дают. Но неправильно выбранный концепт (или вообще отсутствие концепта) доставят вам в итоге не меньше проблем, чем низкая производительность. С хорошим концептом производительность можно поднять кэшированием и т.д., а вот с недостатками концепта бороться сложнее.
Мне кажется, парадигмы применяют не столько для роста производительности, сколько для упрощения поддержки продукта в дальнейшем. От статьи остаётся ощущение, что на концепты можно забить, так как роста производительности они не дают. Но неправильно выбранный концепт (или вообще отсутствие концепта) доставят вам в итоге не меньше проблем, чем низкая производительность. С хорошим концептом производительность можно поднять кэшированием и т.д., а вот с недостатками концепта бороться сложнее.
Статья не ахти , в основном стеб и мелкие замечание про то что нужно использовать а что нет , такие выпады без цифр и графиков оценки производительности того или иного метода оптимизации не заслуживают внимания , "да и вообще вы все такие неумехи" - это наверное главная мысль этой статьи , автор явно не потрудился написать - "а почему так нужно писать ту или иную конструкцию ?" , наверно лень .
К чему лично я придрался :
1) узкие места в php пропорциональны опытности программиста и только ,
45тыс по москве - бред , эта з.п. не спеца , а извините студента на поддержке и разработке модулей корп. сайта или движка.
2) акселератор - где они и как их зовут?!.
3) Парадигмы применяются исключительно для : быстрой разработки , беспроблемного расширения и
наращивания функциональности.
4) у меня фреймворк написан - обслуживает 300к запросов в день - кеширования нет , весь вопрос в правильной модели самого движка, естественно, для каждой задачи он сугубо индивидуален.
5) экономить на копейках в производительности на print или echo - просто смешно.
7) Это вообще блеск ! Сначала пишут удобный код а уже потом производительный.
13) Не хватает пространства имен :)
К чему лично я придрался :
1) узкие места в php пропорциональны опытности программиста и только ,
45тыс по москве - бред , эта з.п. не спеца , а извините студента на поддержке и разработке модулей корп. сайта или движка.
2) акселератор - где они и как их зовут?!.
3) Парадигмы применяются исключительно для : быстрой разработки , беспроблемного расширения и
наращивания функциональности.
4) у меня фреймворк написан - обслуживает 300к запросов в день - кеширования нет , весь вопрос в правильной модели самого движка, естественно, для каждой задачи он сугубо индивидуален.
5) экономить на копейках в производительности на print или echo - просто смешно.
7) Это вообще блеск ! Сначала пишут удобный код а уже потом производительный.
13) Не хватает пространства имен :)
1) про пропорциональность узких мест непонятно. Поясните, пожалуйста. 45К - нормальная зарплата, и не в Москве. Бывает выше, но чаще - ниже.
2) eAccelerator, xCache, APC,... вопрос "где они?" непонятен
3) да
4) "300К запросов в день" - надеюсь, вы понимаете, что эта цифра вообще ни о чем не говорит (пиковая нагрузка? запросы к чему вообще - к БД, к апачу, к страницам?....)
5) об том и статья ;)
7) производительность - это нефункциональное требование, которого может и не быть. Возможно, о нем вообще не надо думать. В любом случае, об этом надо думать не после написания кода.
13) угу, согласен :)
2) eAccelerator, xCache, APC,... вопрос "где они?" непонятен
3) да
4) "300К запросов в день" - надеюсь, вы понимаете, что эта цифра вообще ни о чем не говорит (пиковая нагрузка? запросы к чему вообще - к БД, к апачу, к страницам?....)
5) об том и статья ;)
7) производительность - это нефункциональное требование, которого может и не быть. Возможно, о нем вообще не надо думать. В любом случае, об этом надо думать не после написания кода.
13) угу, согласен :)
"и не в Москве" → "и даже в Москве"
1) спец уже на стадии проектирования знает узкие места , именно там он приложит усилия на оптимизацию.
2) это вопрос автору , статья без ссылок на хоть какое-то решение , для просвещения незнающих - просто болтовня.
4) 300к - это уников в день , остальное можно подсчитать.
5) Про это статья о производительности и как бы :) , узких местах в php.
P.S. могу добавить что для много миллионных загрузок сам php будет узким местом :)
2) это вопрос автору , статья без ссылок на хоть какое-то решение , для просвещения незнающих - просто болтовня.
4) 300к - это уников в день , остальное можно подсчитать.
5) Про это статья о производительности и как бы :) , узких местах в php.
P.S. могу добавить что для много миллионных загрузок сам php будет узким местом :)
3) Вот речь и идет о том, что производительность от парадигмы не зависит.
4) 300к запросов в день это всего лишь 3.5 запроса в секунду ) не такая большая цифра, чтобы по ней судить о производительности.
7) Не понял, вы согласны или несогласны с "Сначала пишут удобный код а уже потом производительный."? :)
13) В 5.3, кстати, будут.
4) 300к запросов в день это всего лишь 3.5 запроса в секунду ) не такая большая цифра, чтобы по ней судить о производительности.
7) Не понял, вы согласны или несогласны с "Сначала пишут удобный код а уже потом производительный."? :)
13) В 5.3, кстати, будут.
300к запросов в день это не всего лишь 3.5 запроса в секунду. Это где-то 35 в пике (если только у вас сайт не слишком глобальный, то пик - где-то 10x от среднего). Уже ничего так. Но сможет ли ваш движок обратотать 3M запросов в день (300 запросов в секунду)? Разумный запас прочности движка - 10х от сегодняшних потребностей (если ваша популярность вырастет не в 10, а в 100 раз у вас будут деньги на то, чтобы всё переписать на совсем другой парадигме, а 10-кратный рост может случиться достаточно быстро для того, чтобы у вас не было на это времени).
3)а вот и зависит : всегда гибкость за счет производительности
4)да согласен не большая , просто если вы попытаетесь скормить этим 300к bitrix - даун обеспечен.
7) не согласен , нужно конечно заботится о производительности ка си-программист :) , но не до паранои.Пишут код , тестируют на нагрузках , а потом оптимизируют .
4)да согласен не большая , просто если вы попытаетесь скормить этим 300к bitrix - даун обеспечен.
7) не согласен , нужно конечно заботится о производительности ка си-программист :) , но не до паранои.Пишут код , тестируют на нагрузках , а потом оптимизируют .
>4)да согласен не большая , просто если вы попытаетесь скормить этим 300к bitrix - даун обеспечен.
-
не надо утверждать то, о чем не знаете.
-
не надо утверждать то, о чем не знаете.
Послушайте уважаемый ,
Во-первых : из каких соображений вы сделали вывод что я этого не знаю ?
Во-вторых : в моей практике есть реальный пример новостного портала на bitrix 4 , поверьте он и на 50к загибался :).
И в-третьих : я говорил про чистую работу bitrix, без сторонних серверных или софтверных решений , типа memcachd , gnix.
Во-первых : из каких соображений вы сделали вывод что я этого не знаю ?
Во-вторых : в моей практике есть реальный пример новостного портала на bitrix 4 , поверьте он и на 50к загибался :).
И в-третьих : я говорил про чистую работу bitrix, без сторонних серверных или софтверных решений , типа memcachd , gnix.
1. из вашего утверждения, на которое я собственно и ответил
2. вы в этот момент мониторили серверы (апач, mysql, нгинкс), к которым обращался сайт? Лично я мониторил, когда проводил нагрузочное тестирование в 1М на битриксе. Правда, это была не древняя четверка (вы бы еще битрикс3 вспомнили) Еще раз: 50К чего? запросов в секунду? что значит "загибался"? время отклика превышало 2 сек, или 500-я ошибка вылезала?
3. так может для чистоты эксперимента еще и кэширование в самом битриксе отключить, и все это на Р-MMX поставить под виндой?
2. вы в этот момент мониторили серверы (апач, mysql, нгинкс), к которым обращался сайт? Лично я мониторил, когда проводил нагрузочное тестирование в 1М на битриксе. Правда, это была не древняя четверка (вы бы еще битрикс3 вспомнили) Еще раз: 50К чего? запросов в секунду? что значит "загибался"? время отклика превышало 2 сек, или 500-я ошибка вылезала?
3. так может для чистоты эксперимента еще и кэширование в самом битриксе отключить, и все это на Р-MMX поставить под виндой?
но вообще я согласен, битрикс - тормоз тот еще :) без костылей хрен заставишь двигаться
По поводу 4 - вопрос скорее, состоит в том, сколько вы времени потратили на поддержку 300к на уровне PHP и сколько бы вы потратили, применив кэширование.
Наконец-то хоть кто-то написал по сути, а то куча народу уже написало статьи на тему вызова echo, но нигде не было приведено, сколько в секундах это экономит времени.
Вы всё еще пытаетесь кому-то доказать что он не удачник? Вы неудачник!
Молодца ))))
Я бы просто запульнул в афтора помидором , на большее он не тянет.
очень трезво написано! спасибо за бальзам на душу. (:
13) И не верьте никому, кто заявляет, что PHP5 - "плохая" технология, пока не врубитесь в нее хотя бы на 90% и не убедитесь в этом сами :)
перейдя на php с "нормальных" языков, я считал php бейсиком с синтаксисом си
перейдя теперь на abap я понимаю, какой же хороший и удобный язык php :)
Где это VDS по 150 рублей?
Ура!!! Первый стоящий топик по адекватному подходу к программингу на PHP. А то уже в конец достали разглагольствования ньюбов на тему оптимизации "echo"))))
Автор похоронил все будущие статьи по оптимизации кода на PHP. =)
На хабрахабре не появится больше таких.
А если появятся - авторы получат в комментах кучу ссылок на этот пост и уйдут в минуса =)
На хабрахабре не появится больше таких.
А если появятся - авторы получат в комментах кучу ссылок на этот пост и уйдут в минуса =)
тест
Над пунктом 9 прослезился. Когда-то давно ставил себе VMWare, задолбался, поставил Linux. Задолбался еще больше ("Лучше день потерять, но за час долететь"), но доволен результатом.
Пункт 10 - весьма сомнительный. С одной стороны акселератор во время разработки не нужен. Ну зачем, объясните? То, что он нужен в продакшене -сомнению не подлежит, но в разработке-то зачем? Выкатывается версия на production-сервер на тестовый поддомен и там сразу видно проседания производительности на целевой машинке.
С другой стороны - возможно, тестирование в обстановке максимально приближенной к конечному месту проживания проекта...
Пункт 10 - весьма сомнительный. С одной стороны акселератор во время разработки не нужен. Ну зачем, объясните? То, что он нужен в продакшене -сомнению не подлежит, но в разработке-то зачем? Выкатывается версия на production-сервер на тестовый поддомен и там сразу видно проседания производительности на целевой машинке.
С другой стороны - возможно, тестирование в обстановке максимально приближенной к конечному месту проживания проекта...
"кстати, я до сих пор не видел ни одной нормальной книги по PHP5"
от дерика ретханса есть отличная
от дерика ретханса есть отличная
Может написано и в жестковатой форме, но сутьпередана хорошо.
Некоторые думают, что PHP можно изучать за 24 часа, некоторые — за неделю. А потом эти люди толпами ходят и гнобят PHP за то, что на нем плохо пишут.
Но одно "но" все же есть. В PHP действительно не хватает некоторых вещей, кое-что реализовано плохо, и слишком много свободы для программиста. Последнее, являясь преимуществом PHP, сыграло против него злую шутку.
Некоторые думают, что PHP можно изучать за 24 часа, некоторые — за неделю. А потом эти люди толпами ходят и гнобят PHP за то, что на нем плохо пишут.
Но одно "но" все же есть. В PHP действительно не хватает некоторых вещей, кое-что реализовано плохо, и слишком много свободы для программиста. Последнее, являясь преимуществом PHP, сыграло против него злую шутку.
Кстати. В нормальном проекте echo должно быть в одном месте. И желательно выводить xml, шаблон делать в xslt. Рендеринг пошустрее будет. Вобще считаю html зло. xhtml рулит. Мой пример на http://new.nigma.ru - можно за ценить что xml рисуется быстрее. А насчет кеширования и оптимизации. Есть apc - собрал статически php - и не надо всяких там zend - оптимазеров. Для бд есть memcache. Ну на крайняк. Хранить всё в плоских файлах и на tmpFS. Как говорится было бы желание. А производительность никуда не денется.
Раз пошла такая пьянка — подскажите, пожалуста, "профайлер" для Perl?
Забавнно получилось с 11 пунктом. У автора в профиле-резюме написано: PHP5 (именно 5, ООП) - в совершенстве. Да вы батенька неудачник!? А такие опусы пишите.
Жесткая форма написания.
Жесткая форма написания.
12) Нормальные книги есть, тот же Шлосснейгл к примеру.
В целом понравилось, несмотря на нарочито жёсткий стиль изложения. Хорошо подмечены ключевые болевые точки web-разработчика :)
Большой процент флеймов вокруг похапэ крутится именно вокруг микрооптимизаций: все эти кавычки, эхи и прочая лабуда. В реальных проектах bottleneck'ов, где всё это реально влияет на производительность, обычно не бывает.
По 5-му пункту: не всё так просто, обычно echo-подобные конструкции во множестве вызываются во view-скриптах (что в "PHP-шаблонах" ZF, что в Smarty). Другое дело, что гораздо раньше, чем различия в методиках вывода начнут сказываться на скорости вывода, начнутся проблемы с пропихиванием выведенного через канал.
Но вот со всякими там юниксами-акселераторами на рабочей машине - не согласен категорически. Это уже фанатизм. Большинство проектов пишутся как кроссплатформенные, так что работать надо в той операционке, в которой привычно. А акселератор на рабочем месте скорее вредит, потому как без него лучше видно, что какой-то код подтормаживает.
Большой процент флеймов вокруг похапэ крутится именно вокруг микрооптимизаций: все эти кавычки, эхи и прочая лабуда. В реальных проектах bottleneck'ов, где всё это реально влияет на производительность, обычно не бывает.
По 5-му пункту: не всё так просто, обычно echo-подобные конструкции во множестве вызываются во view-скриптах (что в "PHP-шаблонах" ZF, что в Smarty). Другое дело, что гораздо раньше, чем различия в методиках вывода начнут сказываться на скорости вывода, начнутся проблемы с пропихиванием выведенного через канал.
Но вот со всякими там юниксами-акселераторами на рабочей машине - не согласен категорически. Это уже фанатизм. Большинство проектов пишутся как кроссплатформенные, так что работать надо в той операционке, в которой привычно. А акселератор на рабочем месте скорее вредит, потому как без него лучше видно, что какой-то код подтормаживает.
по-моему автор большой сказочник
Да нет, скорее его просто достал непрекращающиеся повсеместно извержения религиозного характера на темы "похапэ - отстойный язык, юзайте руби/питон/перл" и про ловлю блох промеж кавычек с эхами. Местами, конечно, перегнул, но какая ж провокация без этого :)
мне не понравились две вещи:
1) форма изложения в посте: создаётся впечатление, что автор умный, а остальные дураки и неудачники
2) я, как не первый год программист на пхп, не согласен с некоторыми пунктами.
1) форма изложения в посте: создаётся впечатление, что автор умный, а остальные дураки и неудачники
2) я, как не первый год программист на пхп, не согласен с некоторыми пунктами.
А с какими именно?
2-3) в PHP очень часто производительность храмает из-за криворукости программиста. А кеширование необходимо либо на сильно нагруженых серверах либо когда профайлер показывает места, которые не могут быть оптимизированы небольшими затратами.
4) тут всё правильно
7) sprintf работает везде во всех языках очень медленно. это аксиома. а первые три эха значения не имет
8) хостинг необходимо выбирать не из амбициозности разработчика, а из потребностей сайта, что будет на нём размещаться. и чтобы тратить каждый раз на 500 баксов больше на выделеный сервер необходимы веские аргументы
9) автор явно предвзято относится к Windows
10) если человек отлаживаетс xDebug то в большинсте случаев у разбработчиков будет отключён акселератор
12) автор себя дискредетирует как профессионал? что наталкивает на мысль, что он сказочник
4) тут всё правильно
7) sprintf работает везде во всех языках очень медленно. это аксиома. а первые три эха значения не имет
8) хостинг необходимо выбирать не из амбициозности разработчика, а из потребностей сайта, что будет на нём размещаться. и чтобы тратить каждый раз на 500 баксов больше на выделеный сервер необходимы веские аргументы
9) автор явно предвзято относится к Windows
10) если человек отлаживаетс xDebug то в большинсте случаев у разбработчиков будет отключён акселератор
12) автор себя дискредетирует как профессионал? что наталкивает на мысль, что он сказочник
2-3) "Криворукость" программиста обычно не связана с PHP как с инструментом. То есть этот же самый проект, будучи написанным на Руби или Питоне, тормозил бы точно так же и в тех же местах. Причём в основном - при выборке данных из СУБД. Ну, бывают ещё разные идиотские самопальные шаблонные системы, но это уже редкость.
7) Дело в том, что в большинстве случаев "тормознутость" sprintf реально никак не сказывается на общей производительности. Массивный контент сосредоточен в шаблонах, а вклад мелочёвки незначителен. Не, ну сдуру можно, конечно, и sprintf-ами сайт положить :)
8) "Потребности сайта" - штука комплексная и в общем случае включает в себя потребности программиста. Иногда дешевле взять хостинг подороже, чем оплачивать труды программиста, который научит сайт сносно пахать на плохом хостинге. Хотя это, конечно, не повод писать откровенную лажу в расчёте на суперкомпьютер, который всё перемелет...
9-10) О, это да :)
12) Написать провокационный пост и не измазаться при этом самому практически невозможно: вместе с изобличаемыми пороками обязательно всплывут и собственные, ггг :)
7) Дело в том, что в большинстве случаев "тормознутость" sprintf реально никак не сказывается на общей производительности. Массивный контент сосредоточен в шаблонах, а вклад мелочёвки незначителен. Не, ну сдуру можно, конечно, и sprintf-ами сайт положить :)
8) "Потребности сайта" - штука комплексная и в общем случае включает в себя потребности программиста. Иногда дешевле взять хостинг подороже, чем оплачивать труды программиста, который научит сайт сносно пахать на плохом хостинге. Хотя это, конечно, не повод писать откровенную лажу в расчёте на суперкомпьютер, который всё перемелет...
9-10) О, это да :)
12) Написать провокационный пост и не измазаться при этом самому практически невозможно: вместе с изобличаемыми пороками обязательно всплывут и собственные, ггг :)
Оказывается школьники пишут не толко книги по РНР, но и статьи на хабре. Статья может и имеет несколько правильных фактов, но такие вещи как "кульхацкеры не юзают венду" и "покупайте дедикатед сервер за 150 р вместо виртуального хостинга" сразу выдают возраст и опыт песателя данной статьи.
А причем здесь Винда? Зачем ее юзать на нагруженных проектах??? автор говорит, что надо юзать конечный продукт... и я полностью согласен с тем, что девелоперская среда должна в идеале полностью соответствовать продуктиву.
слишком вызывающий пост. это не профессионально.
очень даже профессионально на фоне предыдущих псевдо-ликбезов
А по существу? Или Вы тоже сторонник "сносить венду, красноглазый линакс - форева?". У меня на всех серверах стоит Линукс, только почему-то от этого я не бью себя пяткой в грудь, мол, посмотрите, какой я крутой. Каждое средство - под задачу. И ОС на программирования на PHP никак не влияет.
у кого что болит, тот о том и говорит
Спасибо, ничего нового, но приятно когда видишь единомышленников :-)
И еще. Если вы не юзаете svn, юнит-тесты, и не пишете пхпдок - вы мудак! Позаботьтесь о других разработчиках, не будьте мудилой.
И еще. Если вы не юзаете svn, юнит-тесты, и не пишете пхпдок - вы мудак! Позаботьтесь о других разработчиках, не будьте мудилой.
вы тоже не отличаетесь от автора - такой же правильный, а все остальные мудаки, кто не делает так же.
SVN, phpdoc и unit-test - это признаки профессионализма и хорошего кода, но не обязательно к применению, так как есть другие методы.
SVN, phpdoc и unit-test - это признаки профессионализма и хорошего кода, но не обязательно к применению, так как есть другие методы.
Да хрен с ним. Пусть будут максимы =)
Средний пэхаммист не понимает, когда у задачи больше двух решений.
Поэтому пусть лушче считают единственным более продвинутое.
Читая эти топики, я все больше склоняюсь к тому, что учить надо именно так.
Как вычислять дважды два они все равно не понимают. И не поймут. Пусть уж хоть тупо зазубривают ответ.
Средний пэхаммист не понимает, когда у задачи больше двух решений.
Поэтому пусть лушче считают единственным более продвинутое.
Читая эти топики, я все больше склоняюсь к тому, что учить надо именно так.
Как вычислять дважды два они все равно не понимают. И не поймут. Пусть уж хоть тупо зазубривают ответ.
Да, я такой же, как хомяк, которого бьют током. Один раз ударили - больше не хочу.
Работал в разных конторах и везде обязательно был огромный проект, тянущийся с NN-х времен. И если на остальных проектах отсутствие системы контроля версий не было критично (либо они малы, либо еще чего), то к этим ее просто надо было вводить, потому что всегда начинают нервы не выдерживать от мелких багов, переливаний нужных файлов и так далее.
romv4, я бы с радостью описал свою мысль абсолютно правильно, точно и исчерпывающе (описав все существующие методы) чтоб не цеплялись к словам, но не могу. Может вы мне поможете?
Работал в разных конторах и везде обязательно был огромный проект, тянущийся с NN-х времен. И если на остальных проектах отсутствие системы контроля версий не было критично (либо они малы, либо еще чего), то к этим ее просто надо было вводить, потому что всегда начинают нервы не выдерживать от мелких багов, переливаний нужных файлов и так далее.
romv4, я бы с радостью описал свою мысль абсолютно правильно, точно и исчерпывающе (описав все существующие методы) чтоб не цеплялись к словам, но не могу. Может вы мне поможете?
с удовольствием. напишите в приват, а результат потом выложите здесь, либо в отдельном посте
Я свой вариант уже написал, в этой строчке вы указали на недочеты:
> SVN, phpdoc и unit-test - это признаки профессионализма и хорошего кода, но не обязательно к применению, так как есть другие методы.
Собственно, я эти другие методы подразумевал. Видимо плохо, рас вы не поняли (понятное дело что на этих 3х вещах мир клином не встал).
> SVN, phpdoc и unit-test - это признаки профессионализма и хорошего кода, но не обязательно к применению, так как есть другие методы.
Собственно, я эти другие методы подразумевал. Видимо плохо, рас вы не поняли (понятное дело что на этих 3х вещах мир клином не встал).
Честно говоря не понял для кого статья.
Для php-разработчиков? Как минимум 6 из 13 "советов" предполагают контроль над сервером (где-то ошибся в подсчете? - поправьте). Нет, можно, конечно, поднять сервер, а то и кластер в локалке, настроить его как хочется и показывать заказчику как все летает под 1к запросов в секунду. Потом передать ему скрипты, получить деньги, только потом он будет жаловаться на тормоза на виртхостинге за 3000 руб/месяц (ну не нашел он линка на VDS за 150р) при одном запросе в час.
Но как часто разработчик имеет контроль над реальной средой выполнения? В лучшем случае он может порекомендовать менеджеру проекта и, возможно, заказчик прислушается к рекомендациям менеджера (если менеджер, конечно, воспримет их всерьез, а не как очередное оправдание разработчика за свой кривой код, и решится их донести до заказчика, который пришел с пачкой в баксов в руках и сказал "я купил самый дорогой виртуальный хостинг на 100 лет вперед, чтобы и внукам досталось, мне сказали хостинг - это главное, чтобы тормозов не было, а тормозов я не люблю, а виртуальный - это же сейчас круто!!! Виртуальная реальность, Матрица, все дела... Сделаете мне сайт? Не сделаете - найду других, а у вас проблемы будут, с налоговой ")
Для php-разработчиков? Как минимум 6 из 13 "советов" предполагают контроль над сервером (где-то ошибся в подсчете? - поправьте). Нет, можно, конечно, поднять сервер, а то и кластер в локалке, настроить его как хочется и показывать заказчику как все летает под 1к запросов в секунду. Потом передать ему скрипты, получить деньги, только потом он будет жаловаться на тормоза на виртхостинге за 3000 руб/месяц (ну не нашел он линка на VDS за 150р) при одном запросе в час.
Но как часто разработчик имеет контроль над реальной средой выполнения? В лучшем случае он может порекомендовать менеджеру проекта и, возможно, заказчик прислушается к рекомендациям менеджера (если менеджер, конечно, воспримет их всерьез, а не как очередное оправдание разработчика за свой кривой код, и решится их донести до заказчика, который пришел с пачкой в баксов в руках и сказал "я купил самый дорогой виртуальный хостинг на 100 лет вперед, чтобы и внукам досталось, мне сказали хостинг - это главное, чтобы тормозов не было, а тормозов я не люблю, а виртуальный - это же сейчас круто!!! Виртуальная реальность, Матрица, все дела... Сделаете мне сайт? Не сделаете - найду других, а у вас проблемы будут, с налоговой ")
> Если на вашей рабочей машине PHP работает без акселератора - вы нюхаете цветы в противогазе, надетом на респератор, а поверх этих гламурных шмоточек на вас еще надет... ТАНК! Установите уже акселератор, черт возьми!
Quercus: PHP in Java
http://quercus.caucho.com/
- повышает производительность PHP-скриптов на сервере Resin в ~4..6 раз, переводя их в JavaServlets, JIT-компилирует и выполняет уже нативный код.
Это имелось в виду?
Quercus: PHP in Java
http://quercus.caucho.com/
- повышает производительность PHP-скриптов на сервере Resin в ~4..6 раз, переводя их в JavaServlets, JIT-компилирует и выполняет уже нативный код.
Это имелось в виду?
> И не верьте никому, кто заявляет, что PHP5 - "плохая" технология, пока не врубитесь в нее хотя бы на 90% и точно не будете знать, чего вам в ней не хватает ;)
Хочу threads!
Хочу threads!
Автор похоже злой Админ байке, собрал все типы ) для хорошого проэкта можно и 2..3 сервера в кластер собрать, ну или на T2000, а сайт вроде васяПупки ВЕБ2 сервис конечно PHP5 может и не нужно....
Улыбнуло: Самый быстрый код - это код, которого нет.
Самая лучшая рыба - это колбаса.
Самая лучшая рыба - это колбаса.
best
Зажигательный пост, просто читал и плакал :)
считаю что ничего плохого в использовании PHP под windows нет - в домашних целях. На сервере, само собой должны быть никсы... Хотя я знаю пару примеров, один из них сайт гос.учреждения, где крутятся ASP и PHP одновременно.
Есть доля правды =))
Автору респект и уважуха. Хабр курю давно, но регистрироваться смысла не видел. Заморачиваться с кармой и т.п. Но, эта статья таки заставила зарегаться (после того как проржались всем офисом), и первым делом ушла в избранное. Без "неудачнег", "анус" эта статья стала бы еще одной унылой и скучной выкладкой фактов.
ЗЫ. А тем, кто не понимает литературного стиля Автора поскорее выпить йаду, и убить сибя ап стенку. Вы как всегда вместо того чтобы увидеть и оценить Суть, ниасилив Текст, придираетесь к стилю.
ЗЫ. А тем, кто не понимает литературного стиля Автора поскорее выпить йаду, и убить сибя ап стенку. Вы как всегда вместо того чтобы увидеть и оценить Суть, ниасилив Текст, придираетесь к стилю.
> Если вы считаете, что постигли PHP5 в совершенстве — вы неудачник. Всегда есть, чему научиться. Если вы точно знаете, у кого вам есть чему поучиться — можете дальше не читать.
знаю, у кого можно научиться, но эти люди к сожалению со мной не работают…
>Причем некоторые из них умудряются писать умные книги (кстати, я до сих пор не видел ни одной нормальной книги по PHP5), и учить людей «тонкостям программирования на PHP» множеством других способов.
да, согласен, много авантюьюристов в мире РНР. А книг, действительно нормальных нет, и это естественно — технология на столько двигается вперед, что всякая информация, и даже маны, быстро устаревают. Пока пишешь книгу по прикладным отраслям и она выйдет в свет — она уже станет не актуальной. Можно написать книгу в стиле переведенный ман в собственном соку разбавленный примерами… Но — это не книга, а… про то что было изложено выше.
про все осатльное отчасти согласен…
знаю, у кого можно научиться, но эти люди к сожалению со мной не работают…
>Причем некоторые из них умудряются писать умные книги (кстати, я до сих пор не видел ни одной нормальной книги по PHP5), и учить людей «тонкостям программирования на PHP» множеством других способов.
да, согласен, много авантюьюристов в мире РНР. А книг, действительно нормальных нет, и это естественно — технология на столько двигается вперед, что всякая информация, и даже маны, быстро устаревают. Пока пишешь книгу по прикладным отраслям и она выйдет в свет — она уже станет не актуальной. Можно написать книгу в стиле переведенный ман в собственном соку разбавленный примерами… Но — это не книга, а… про то что было изложено выше.
про все осатльное отчасти согласен…
> Какой бы ерундой вы не занимались с PHP, узкое место _всегда_ — БД.
ну, это не всегда и зависит от того, как построить архитектуру. Например в моем проекте скрипт исполняется 5 мс, а запрос — 0.3 мс. а ab выдает 500 qpc
И где здесь узкое место???
ну, это не всегда и зависит от того, как построить архитектуру. Например в моем проекте скрипт исполняется 5 мс, а запрос — 0.3 мс. а ab выдает 500 qpc
И где здесь узкое место???
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Страшные сказки про PHP5, рассказанные на ночь…