Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 170
>> В общем, как настоящие русские парни, мы решили все сломать к хренам собачьим и построить заново, сделав красиво.
Я бы поаккуратней пользовался такими фразами, для многих это первый сигнал, чтобы поставить вопрос о профпригодности разработчика ;)
Я бы поаккуратней пользовался такими фразами, для многих это первый сигнал, чтобы поставить вопрос о профпригодности разработчика ;)
Тем не менее, иногда это правильный выход :( У меня коллеге досталось на растерзание творение вечносменяющихся студентов… это полбеды еще. Они работали под руководством бывшего военного, который прославился своим высказыванием «perl быстрее sql». Когда система подросла, там вышло боком абсолютно все.
И стоило так мучаться…
Я считаю решение со встроенным в сервер скриптовым модулем откровенно фиговым.
Отдача контента по HTTP-это одно, а выполнение скриптов — совсем другое. Выигрыш от применения легковесных серверов во многом благодаря разделению фронтенд — бекенд. А то все люди удивляются почему у них echo выполняется минуту.
Тем более у перла такая шикарная работа с fast cgi…
Отдача контента по HTTP-это одно, а выполнение скриптов — совсем другое. Выигрыш от применения легковесных серверов во многом благодаря разделению фронтенд — бекенд. А то все люди удивляются почему у них echo выполняется минуту.
Тем более у перла такая шикарная работа с fast cgi…
хочешь собираешь с перлом — не хочешь без перла.
А вот то что он встроен иногда очень помогает.
А вот то что он встроен иногда очень помогает.
На медленных клиентах мы висим веб сервером вместе с модулем, жрем память.
В концепции фронтенд-бекенд мы вебсервером быстренько запросили бекенд, бекенд быстренько отстрелялся, дальше веб-сервер берет медленного клиента за руку и ведет его в кино, потом в ресторан, и может быть в номера. Жирный бекенд в это время отдыхает, ресурсы свободны.
На бекенде может быть все что угодно, главное чтобы лишнего ничего при подготовке ответа не происходило.
В концепции фронтенд-бекенд мы вебсервером быстренько запросили бекенд, бекенд быстренько отстрелялся, дальше веб-сервер берет медленного клиента за руку и ведет его в кино, потом в ресторан, и может быть в номера. Жирный бекенд в это время отдыхает, ресурсы свободны.
На бекенде может быть все что угодно, главное чтобы лишнего ничего при подготовке ответа не происходило.
Тож собирался исследовать сей вопрос, но Вы были раньше, спасибо :) Правда у меня немного другого плана эксперимент — нагрузки никакой, зато ресурсов небогато… но это уже лирика. Ниже пара комментов по существу.
1) Apache::Session — наверное, единственный модуль который вы могли взять не переделывая :) Там от апача одно название, используйте хоть в консоли… По-моему, я даже в документации это видел, но не уверен. Код в свое время довольно детально пришлось изучить, там ничего «лишнего» нет.
2) попробуйте сделать бенчмарк с разными настройками масона — как у вас и с out_method => $buffer (т.е. чтобы буферизовать вывод, и потом его уже руками из хендлера отдавать клиенту сразу весь). Под модперлом разница в скорости отдачи мягко говоря заметная.
1) Apache::Session — наверное, единственный модуль который вы могли взять не переделывая :) Там от апача одно название, используйте хоть в консоли… По-моему, я даже в документации это видел, но не уверен. Код в свое время довольно детально пришлось изучить, там ничего «лишнего» нет.
2) попробуйте сделать бенчмарк с разными настройками масона — как у вас и с out_method => $buffer (т.е. чтобы буферизовать вывод, и потом его уже руками из хендлера отдавать клиенту сразу весь). Под модперлом разница в скорости отдачи мягко говоря заметная.
Интересно, обязательно каждому НЕ PHP-программисту, в топике\комментарии писать, что-то типо: «Я смотрю а там пэхопэ, гавно какое!»
Дело не в языке, а в том кто на нем пишет.
Дело не в языке, а в том кто на нем пишет.
Но на РНР говна много больше, ибо знаний почти не нужно.
Это, согласитесь, это совсем не проблема PHP. Поэтому с первым тезисом:
«обнаружилось несколько серьёзных проблем:
Это было написано на PHP;» — я не соглашусь, извините. Второе вполне допускаю: сам постоянно вижу подобный код. Но это далеко не проблема языка. А проблемы в головах искоренить — это утопия. Одним Перлом весь мир не обеспечишь.
«обнаружилось несколько серьёзных проблем:
Это было написано на PHP;» — я не соглашусь, извините. Второе вполне допускаю: сам постоянно вижу подобный код. Но это далеко не проблема языка. А проблемы в головах искоренить — это утопия. Одним Перлом весь мир не обеспечишь.
Не принимайте близко к сердцу. Не знаю, как относится к PHP автор, но мне кажется что в любом случае для них проблема — это саппортить PHPшный проект. Иначе бы решение не было сделано на перле :)
Но это далеко не проблема языка.Увы и ах, но это — проблема языка. PHP — это специальный язык для создания быдлокода и ошибка у него в ДНК.
Основная проблема — в подходе: если программист делает идиотское действие (ну не знаю — умножает строку на строку, например), то любой нормальный язык выбросит ошибку. Статические языки сделают это во время компиляции, динамические — в рантайме. PHP же попытается угадать чего на самом деле хотели сделать. Что это значит? А это значит две вещи:
1. Такой язык будет безумно популярен так как люди с кривыми руками (но умеренно кривыми руками) смогут на нём порождать нечто работающее.
2. 99% кода, созданного на этом языке будут иметь ошибки и уязвимости.
Простой рассчёт: если в программе 10'000 операторов и PHP «угадывает» намеренье программиста в 99.9% случаев правильно (неплохой процент, да?), то вероятность получения программы без ошибок — меньше одной сотой процента (а это уже никуда не годится).
Не могу назвать perl идеалом, но до PHP ему далеко. С ним из распространённых языков может сравниться только один: JavaScript. Но от него никуда, в общем, не денешься, приходится терпеть. А от PHP нужно избавляться по возможности. Ибо писать на нём хорошие программы так же просто как ездить на одноколёсном велосипеде: ничего невозможного нет, нужно просто больше внимания уделить управлению, но… если вы не в цирке — купите нормальный велосипед и не морочьте людям голову!
Простите но это ↑ бред, PHP ничего никогда не угадывает, все задокументировано и работает именно так как задумано разработчиками. PHP не требует много знаний или даже прямых рук — но это далеко не проблема языка, это скорей его преимущество так как он позволит «wannabe» программистам сделать что-то из ничего.
Все могут PHP но не все могут С++(к примеру) и мы это замечаем, мы видим проблемы в более популярных и более доступных вещах, в любом языке есть плохие программисты, но вот интересная штука, разница между хорошим и плохим С++(к примеру) программистом в том что у обоих программа скомпилируется.
Да, кстати достаточно изменить настройку оповещения об ошибках чтоб увидеть что она есть, но не показывается дабы «быдлокодер» не описался, попробуйте.
Все могут PHP но не все могут С++(к примеру) и мы это замечаем, мы видим проблемы в более популярных и более доступных вещах, в любом языке есть плохие программисты, но вот интересная штука, разница между хорошим и плохим С++(к примеру) программистом в том что у обоих программа скомпилируется.
Да, кстати достаточно изменить настройку оповещения об ошибках чтоб увидеть что она есть, но не показывается дабы «быдлокодер» не описался, попробуйте.
php -r '$x = «f o o»;$x = explode(" ",$x);print_r($x);'
ничего не угадывает, ака
ничего не угадывает, ака
Простите но это ↑ бред, PHP ничего никогда не угадывает, все задокументировано и работает именно так как задумано разработчиками.Вашими бы устами… К сожалению всё ровно наоборот: вначале был сделан язык, который пытался сделать «как лучше», а потом это задокументерировали. Тот факт что функция sort может вам выдать неотсортированный массив если звёзды плохо встанут это не отменило.
«Будьте осторожны при сортировке массивов, содержащих элементы разных типов, так как в этом случае результат работы функции sort() может быть непредсказуемым.»
Как по вашему должна в данном случае работать функция sort???
Хочешь сортировать сложные структуры данных используй usort().
Как по вашему должна в данном случае работать функция sort???
Хочешь сортировать сложные структуры данных используй usort().
Как по вашему должна в данном случае работать функция sort???Хорошие варианты:
1. Бросить исключение или вернуть код ошибки.
2. Завершить выполнение программы.
Плохие варианты:
1. Вернуть массив, который непонятно — отсортирован вообще или нет.
2. «Тихо» привести данные к одному типу и отсортировать массив.
Чем раньше и жёще реакция на ошибки — тем выше шансы на то, что созданная в результате программа будет правильной. Идеал — это Ada, чуть похуже — Java, Lisp и Haskell — тоже ничего так варианты. PHP же в этом ряду находится просто за гранью разумного.
Повторюсь еще раз :)
Хорошие программисты используют язык как ИНСТРУМЕНТ. Плохие — как ПОНТЫ ;)
На любом языке можно хорошо и достойно писать. Почему больше всего плохого кода на PHP вам ответит гугль — просто язык гораздо популярнее многих — соответсвенно народ на нем больше делает — отсюда следствие.
А то что лично Вы назвали в сврем посте плохим как язык PHP так и JavaScript ( который например не только мне очень нравится своим подходом к ООП ) — это говорит о вас как раз о том, к какой стороне программистов принадлежите Вы ;) Без обид ;)
Хорошие программисты используют язык как ИНСТРУМЕНТ. Плохие — как ПОНТЫ ;)
На любом языке можно хорошо и достойно писать. Почему больше всего плохого кода на PHP вам ответит гугль — просто язык гораздо популярнее многих — соответсвенно народ на нем больше делает — отсюда следствие.
А то что лично Вы назвали в сврем посте плохим как язык PHP так и JavaScript ( который например не только мне очень нравится своим подходом к ООП ) — это говорит о вас как раз о том, к какой стороне программистов принадлежите Вы ;) Без обид ;)
ну последнее время перл все больше отмирает. а вот пайтон наоборот, угрожает зохавать похапе :)
Особенно при наличии джанги.
Особенно при наличии джанги.
Ну здесь справедливости ради хочется отметить, что есть еще такие «гуру» перла, которые в одной строчке пишут мегаконструкцию, а-ля «смотрите ламеры и учитесь, слабо такое завернуть», что сразу хочется отведать пионерской PHP-шной лапши.
Судя по моему опыту самолет — говно — нет ручки переключения скоростей, болтается ввер-вниз руль и куча каких-то тумблеров!!!
А кто вы? Вы великий программист и у вас есть с чем сравнивать? Вы пробовали делать проекты на разных языках и сравнивали их по какому-то праметру? Тогда напишите, а так увы — вы очередной «плохой» программист :)
P.S. Очень хорошо отношусь к Python-у, очень быстрый и качественный язык с отличной ООП архитектурой и весьма необычным подходом к блокам кода. Но, к сожелению, пока не такой попуялрный на хостингах (
А кто вы? Вы великий программист и у вас есть с чем сравнивать? Вы пробовали делать проекты на разных языках и сравнивали их по какому-то праметру? Тогда напишите, а так увы — вы очередной «плохой» программист :)
P.S. Очень хорошо отношусь к Python-у, очень быстрый и качественный язык с отличной ООП архитектурой и весьма необычным подходом к блокам кода. Но, к сожелению, пока не такой попуялрный на хостингах (
Баги есть везди, к сожелению. А вот неподкрепленное фактами утверждение весьма плохо говорит о вас, как о профи. Я знаю массу людей, которые отлично пишут на PHP, Ruby и Python-е. И каждый абсолютно нормально относится ко всем языкам на которых пишет. Ибо есть у каждого языка свой сахар и своя соль.
А то, что по Вашему — PHP — говно — означет лишь одно — вы мало писали на этом языке. А про баги — зайдите на багрепорты для пайтона и Руби например. И это нормально. Любой язык развивается, при этом могу и допускаются ошибки. Это и есть эволюция собственно ;)
А то, что по Вашему — PHP — говно — означет лишь одно — вы мало писали на этом языке. А про баги — зайдите на багрепорты для пайтона и Руби например. И это нормально. Любой язык развивается, при этом могу и допускаются ошибки. Это и есть эволюция собственно ;)
Однако очень странные у вас аналогии, тогда приведу свою:
заходите вы в магазин, подходите к ветрины с соусами, берет там чили и пробуете… Вы не знаете для чего он и понятно чем Вы его будете считать, а вот то, что получается когда его применяют правильно — я думаю очень бы Вам понраилось, так что — увы и ах ;)
заходите вы в магазин, подходите к ветрины с соусами, берет там чили и пробуете… Вы не знаете для чего он и понятно чем Вы его будете считать, а вот то, что получается когда его применяют правильно — я думаю очень бы Вам понраилось, так что — увы и ах ;)
И кстати, Вы так и не указали свой опыт :)
Почитал внимательно
Хоть и пишу на Perl, — но не считаю php плохим. Вопрос в том, как ты пишешь — если пишешь бред — зачем вообще писать? И тем более жаловаться что «язык не говорит мне что я пишу бред».
Хоть и пишу на Perl, — но не считаю php плохим. Вопрос в том, как ты пишешь — если пишешь бред — зачем вообще писать? И тем более жаловаться что «язык не говорит мне что я пишу бред».
А какой у вас опыт, если не секрет? За несколько лет работы пхпшником у меня ни разу не возникало такой мысли
ну поповоду не причечооночти именований функций — это как раз "-" PHP, а вот куски кода работающие по-разному в разгых версиях языка — это увы — проблемы не только PHP ;)
Хм… лень мануал смотреть но скорее всего логика такая:
$foo — строка, она-же является массивом знаков, ну типа $foo=«asdf» и $foo[1] будет 's'
Мы обратились по ключу «foobar» => ключа такого нет ибо ключи у нас цифровые :) Раз нет, бум считать что ключ = 0. По скольку мы работаем с characters, то он взял только первый символ строки. Теперь по русски :)
$foo = «asdf»;
$foo[«foobar»] = «baz» => $foo[0] = 'b'
Как то так, поправьте меня если я ошибаюсь :)
$foo — строка, она-же является массивом знаков, ну типа $foo=«asdf» и $foo[1] будет 's'
Мы обратились по ключу «foobar» => ключа такого нет ибо ключи у нас цифровые :) Раз нет, бум считать что ключ = 0. По скольку мы работаем с characters, то он взял только первый символ строки. Теперь по русски :)
$foo = «asdf»;
$foo[«foobar»] = «baz» => $foo[0] = 'b'
Как то так, поправьте меня если я ошибаюсь :)
Это логика кстати, пусть и не тривиальная ;)
Не все, что не уписывается в Вашу логику — не есть логика.
За нетривиальность часто, очень часто ругают PHP, но далеко не так категорично, как Вы.
И кстати Ваш друг более сдержан в критике.
Не все, что не уписывается в Вашу логику — не есть логика.
За нетривиальность часто, очень часто ругают PHP, но далеко не так категорично, как Вы.
И кстати Ваш друг более сдержан в критике.
Конечно не означает что PHP можно за такие действия поставить "+". Но вот так категорично судить — это смешно.
Естественно минус за точто не кидает варнинг — это сложно отлаживать. Однако я, например, придерживаюсь всегда оперделенного стиля программирования, и обычно если делую переменные, которые меняют тип в процессе выполнеия — четко представляю за чем.
Смысл «нетепизируемости» не в том, что можно по всякому вот так выковряживаться, а совсем в другом.
Бога ради — пишите на другом, но не рубите с плеча )
Естественно минус за точто не кидает варнинг — это сложно отлаживать. Однако я, например, придерживаюсь всегда оперделенного стиля программирования, и обычно если делую переменные, которые меняют тип в процессе выполнеия — четко представляю за чем.
Смысл «нетепизируемости» не в том, что можно по всякому вот так выковряживаться, а совсем в другом.
Бога ради — пишите на другом, но не рубите с плеча )
ммм? и я с хрипотой кинулся защищать PHP? :-D
Вы хорошо о себе думаете )
Поглядите мой самый верхней комментарий, адресованный не вам — и Вы поймете ;)
Вы хорошо о себе думаете )
Поглядите мой самый верхней комментарий, адресованный не вам — и Вы поймете ;)
Кстати ниже всего этого darkk очень неплохо написал о своем мнении.
Можете прочесть это, а потом перечитать свои топики.
Еще раз повторюсь — профессионал может считать, что какой-то инструмент не подходит лично ему по таким-то и таким-то пречинам. Он может это говорить ИМХО свое, но никогда не скажет что инструмент — гавно ;) darkk сказал что «мог бы сказать» но не сказал ;)
Во-первых вы таким утверждением дискредитируете себя в глазах других программистов, которые используют данный инструмент в своей практике, это раз, а во-вторых это просто элементарное неуважение в принципе.
Кстати благодаря PHP движению возникло множество терок из которых потом и повылезали различные решения, принятые в дальнешем на вооружение. Вам не кажется, что только за одно это можно уважать данное сообщество, даже не используя его язык?
Isn'it?
Собственно спор дальше ниочем считаю бесмыссленым, я не призывал Вас полюбить чтото или начать писать на PHP, и не говорил что PHP — лучший язык ;)
Можете прочесть это, а потом перечитать свои топики.
Еще раз повторюсь — профессионал может считать, что какой-то инструмент не подходит лично ему по таким-то и таким-то пречинам. Он может это говорить ИМХО свое, но никогда не скажет что инструмент — гавно ;) darkk сказал что «мог бы сказать» но не сказал ;)
Во-первых вы таким утверждением дискредитируете себя в глазах других программистов, которые используют данный инструмент в своей практике, это раз, а во-вторых это просто элементарное неуважение в принципе.
Кстати благодаря PHP движению возникло множество терок из которых потом и повылезали различные решения, принятые в дальнешем на вооружение. Вам не кажется, что только за одно это можно уважать данное сообщество, даже не используя его язык?
Isn'it?
Собственно спор дальше ниочем считаю бесмыссленым, я не призывал Вас полюбить чтото или начать писать на PHP, и не говорил что PHP — лучший язык ;)
главное тузлы для миграции с phpbb/punbb/… на pybb. я первый свалю.
Еще бы миграцию с друпала напейсать :)
Еще бы миграцию с друпала напейсать :)
Я стал значительно терпимее после того, как баги с безопасностью были найдены в микрокоде процессоров Intel (на wasm.ru чудесный топик был на эту тему).
И к глюкам разного рода я уже привык — редкий день без отосланного багрепорта обходится. :)
Я тоже могу сказать «PHP — говно», мне противен язык с кучей лапши, но это всего лишь инструмент — некоторые задачи (Personal Home Page) он решает отлично и это сложно не признать. Насколько на нём удобно и хорошо писать сложные и большие системы — не знаю, у меня нет опыта написания чего-то огромного на PHP, так, пару чуть менее чем тривиальных сайтиков несколько лет назад.
Но это не отменяет моей скромной ненависти к PHP, сдержанного отношения к Perl и тихого обожания Python.
:)
И к глюкам разного рода я уже привык — редкий день без отосланного багрепорта обходится. :)
Я тоже могу сказать «PHP — говно», мне противен язык с кучей лапши, но это всего лишь инструмент — некоторые задачи (Personal Home Page) он решает отлично и это сложно не признать. Насколько на нём удобно и хорошо писать сложные и большие системы — не знаю, у меня нет опыта написания чего-то огромного на PHP, так, пару чуть менее чем тривиальных сайтиков несколько лет назад.
Но это не отменяет моей скромной ненависти к PHP, сдержанного отношения к Perl и тихого обожания Python.
:)
:) А какже Ruby?
Гугл сказал Python — значит Python.
Достаточно часто слышал про проблемы с производительностью при сравнении ruby vs. python, нет, я знаю, что современные вычислительные мощности бла-бла-бла, и время программиста бля-бла-бла.
Но, как мне кажется без вдумчивого изучения ruby, он с python примерно эквивалентен по фишками.
А для экзотики хотелось бы поковырять haskell и erlang, да времени не хватает :-)
Достаточно часто слышал про проблемы с производительностью при сравнении ruby vs. python, нет, я знаю, что современные вычислительные мощности бла-бла-бла, и время программиста бля-бла-бла.
Но, как мне кажется без вдумчивого изучения ruby, он с python примерно эквивалентен по фишками.
А для экзотики хотелось бы поковырять haskell и erlang, да времени не хватает :-)
Есть такое про Ruby vs Python. Haskell глядел… ну так чтото очень крутое, иногда напоминающее по синтаксису regexp-ы :) Как развитие мозга — само то )
А пайтон учили по каким материалам? Или консоль + google? ( мой вариант последний — нормальных печатных книг я, к сожелению, не нашел )
А пайтон учили по каким материалам? Или консоль + google? ( мой вариант последний — нормальных печатных книг я, к сожелению, не нашел )
Про хаскель я всерьез задумался тогда, когда мне в JS-коде захотелось использовать нечто, что, как я впоследствие узнал, называлось «Y-комбинатор» :-)
Питон — под python-docs.tar.bz2 (официальные доки), ничего лучшего тоже не видал… Да и не привыкать документацию читать, начиная изучать программирование с ассемблера :)
Питон — под python-docs.tar.bz2 (официальные доки), ничего лучшего тоже не видал… Да и не привыкать документацию читать, начиная изучать программирование с ассемблера :)
тормозилло.
Вообще очень много вкусного внутри, но недоделанный GC и пожирание памяти отбивают всю охоту на нем писать.
Потом рубя настолько сильно меняется от версии к версии, что становится страшно.
Рубинов в руби много (yaml, literal programming,...) но все это разведено в огромной куче г… на на которую натыкаешся написав первый проект.
Вообще очень много вкусного внутри, но недоделанный GC и пожирание памяти отбивают всю охоту на нем писать.
Потом рубя настолько сильно меняется от версии к версии, что становится страшно.
Рубинов в руби много (yaml, literal programming,...) но все это разведено в огромной куче г… на на которую натыкаешся написав первый проект.
использование этих багов, которое грозился показать графоман КК, так никто и не увидел.
Ну да, но наличие багов в микрокоде это не отменяет, а если есть «просто баги», наверняка есть и баги с безопасностью в той или иной форме.
ну баги есть в любой программе длиннее 30 строк.
Другое дело, что обновление микрокода даже любой линупс изкаропки делает.
Другое дело, что обновление микрокода даже любой линупс изкаропки делает.
Ну вы как бы лжете, как минимум про «любой из коробки».
про дистры без коробки (генту и подобные) речь не идет.
Ну, например, в убунте 8.10 из коробки не обнаружено.
Или, хотите сказать, у убунты коробки нет? :)
Или, хотите сказать, у убунты коробки нет? :)
packages.ubuntu.com/intrepid/intel-microcode
но если его искаропки не пускают — кокноникл окончательно падает в моих глазах.
но если его искаропки не пускают — кокноникл окончательно падает в моих глазах.
а помоему тут вопрос только один фозникает — вы зачем так пишите? Высасывать из пальца примеры надуманные не стоит.
А присвоение ключу строки либо превратило строку в ассоциативный массив (вполне ожидаемое поведение для текстового ключа), либо (о боги!) этот текстовый ключ был неявно преобразован в число, после чего в зависимости от представления строки в разных версиях был взят либо первый её символ, либо '\0'…
ыыы ) Логика есть на самом деле ) Кста у меня ругается в варнинг PHP 5: foo is not array
Ну да, отличная логика, такая, слегка недетерминированная :)
Что warning это хорошо — значит, всё-таки баг был отрепорчен не зря.
А у вас какая версия? У меня 5.2.6-pl7-gentoo с E_ALL не ругается…
При том я нашел четвертый вариант результата выполнения кода — строка не меняется вообще:
$ php -r '$foo = «asdf»; $foo[«foobar»] = $foo; var_dump($foo);'
string(4) «asdf»
Что warning это хорошо — значит, всё-таки баг был отрепорчен не зря.
А у вас какая версия? У меня 5.2.6-pl7-gentoo с E_ALL не ругается…
При том я нашел четвертый вариант результата выполнения кода — строка не меняется вообще:
$ php -r '$foo = «asdf»; $foo[«foobar»] = $foo; var_dump($foo);'
string(4) «asdf»
ммм… странно действительно. у меня PHP 5.2.6.6
кажется в баг репорте вам внятно ответили:
In your code:
$name = «foobar»;
$name['anything'] = $name;
$name['anything'] is addressing a string offset, 'anything' is casted to
0 so you're overwriting the first character of $name with $name.
The first result, string(6) «oobar», is looking like it's overwriting
the first byte with a null byte, which isn't what one expects but
related to the way PHP optimizes access to variables, which isn't made
for «wrong» code.
для «просветленных»:
фактически ваш код
$foo = «foobar»;
$foo[«foobar»] = $foo;
равен этому
$foo = «foobar»;
$foo[0] = «f»;
In your code:
$name = «foobar»;
$name['anything'] = $name;
$name['anything'] is addressing a string offset, 'anything' is casted to
0 so you're overwriting the first character of $name with $name.
The first result, string(6) «oobar», is looking like it's overwriting
the first byte with a null byte, which isn't what one expects but
related to the way PHP optimizes access to variables, which isn't made
for «wrong» code.
для «просветленных»:
фактически ваш код
$foo = «foobar»;
$foo[«foobar»] = $foo;
равен этому
$foo = «foobar»;
$foo[0] = «f»;
с чего это он даёт разные результаты?
проверте это
function foobar($name) {
$name['anything'] = $name;
var_dump($name);
}
$name = «foobar»;
foobar($name);
$name = «foobar»;
$name['anything'] = $name;
var_dump($name);
результат:
X-Powered-By: PHP/5.2.5
Content-type: text/html
string(6) «foobar»
string(6) «foobar»
проверте это
function foobar($name) {
$name['anything'] = $name;
var_dump($name);
}
$name = «foobar»;
foobar($name);
$name = «foobar»;
$name['anything'] = $name;
var_dump($name);
результат:
X-Powered-By: PHP/5.2.5
Content-type: text/html
string(6) «foobar»
string(6) «foobar»
приведенный мною пример несколько отличается от того, что в баг репорте.
подумайте, в чём разница (домашнее заданее).
более того, я уверен что мой пример будет работать ОДИНАКОВО для ЛЮБОЙ версии пхп5.
хинт: в пхп5 и пхп4 данные передовались в функцию по-разному…
таких косяков навалом и в вашем (и моём :) любимом пайтоне
подумайте, в чём разница (домашнее заданее).
более того, я уверен что мой пример будет работать ОДИНАКОВО для ЛЮБОЙ версии пхп5.
хинт: в пхп5 и пхп4 данные передовались в функцию по-разному…
таких косяков навалом и в вашем (и моём :) любимом пайтоне
понятно что она не меняется. если взять например логигу коментом выше то получается вы запихали в первый(ака нулевой) байт строки $foo первый же байт строки $foo )))
на самом деле тут всё логично и то что одно версия пхп выдает варнинг а другая нет не означает что результат будет разный. тут всё очень логично: строка это массив байтов. естественно индексы у этого массива цифровые и мы можем спокойно писать ['0'] или ['1'] или даже ['10px'](px будет успешно отброшено) т.к. php преобразует строку в интеджер, то что «foobar» преобразовывается в 0 тоже логично.(Оф. документация по intval: Strings will most likely return 0 although this depends on the leftmost characters of the string. The common rules of integer casting apply. )
Зато php не заставляет нас загромождать код преобразованиями строки в integer.
А то что глупые программисты могут превратить эту фичу в баг это их проблемы.
Зато php не заставляет нас загромождать код преобразованиями строки в integer.
А то что глупые программисты могут превратить эту фичу в баг это их проблемы.
Разный результат на разных версиях был получен экспериментально и стоил нескольких часов отладки.
Я не спорю, что пример — ацкий ацтой, но это тот случай, когда warning выдавать лучше, чем тупо кастовать строчку к числу.
Если хотите подробностей, вот этот баг: bugs.php.net/bug.php?id=45400
Я не спорю, что пример — ацкий ацтой, но это тот случай, когда warning выдавать лучше, чем тупо кастовать строчку к числу.
Если хотите подробностей, вот этот баг: bugs.php.net/bug.php?id=45400
скажите, может ли в реально ситуации встретиться код $name['anything'] = $name;? да согласен в таком случае логичнее вывести варнинг. но если писать
$name['anything'] = $name2; то никакого варнинга ненадо. такой код логичен.
$name['anything'] = $name2; то никакого варнинга ненадо. такой код логичен.
и я не отрицаю что результат выполнения $name['anything'] = $name; в контексте функции это баг. вобщемто если поправить то можно и без варнинга обойтись
в том то и дело, что не может.
если встретился — надо упасть с ошибкой 500 а не продолжать выполнение с непредсказуемым результатом.
если встретился — надо упасть с ошибкой 500 а не продолжать выполнение с непредсказуемым результатом.
Более того, такой код встретился и именно изменение поведения между версиями и обратило на себя внимание. Я не спорю с тем, что код — дрянь, но я считаю, что такое поведение для кода $string[$another_string] не логично и далеко не очевидно, что строка-индекс будет прикастована к целому.
PHP/5.2.5
string(4) «asdf»
string(4) «asdf»
Нет, я все понимаю, что compatibility надо иногда ломать, но всё же…
Например, в том же питоне была выпущена версия 2.6 где при исполнении кода, который поломается в 3.0, выдавались предупреждения.
А все варианты результата этого кода, коих три: "\0oobar", «foobar», и array('foobar' => 'foobar') — вот все эти три варианта проявляются в различных версиях 5.2.x (может быть я все-таки ошибаюсь про все три, но абсолютно точно — два из них в 5.2.х и все три в 5.х).
Отсюда вывод: либо они слишком часто любят ломать совместимость, либо данный интерпретируемый язык не выдает warning-ов при таком очевидном и довольно тривиальном «undefined behaviour» — это его никак не красит.
Стоит также заметить, что в данном случае речь не про стандартную библиотеку, не про криворуких кодеров — речь про дизайн языка.
Например, в том же питоне была выпущена версия 2.6 где при исполнении кода, который поломается в 3.0, выдавались предупреждения.
А все варианты результата этого кода, коих три: "\0oobar", «foobar», и array('foobar' => 'foobar') — вот все эти три варианта проявляются в различных версиях 5.2.x (может быть я все-таки ошибаюсь про все три, но абсолютно точно — два из них в 5.2.х и все три в 5.х).
Отсюда вывод: либо они слишком часто любят ломать совместимость, либо данный интерпретируемый язык не выдает warning-ов при таком очевидном и довольно тривиальном «undefined behaviour» — это его никак не красит.
Стоит также заметить, что в данном случае речь не про стандартную библиотеку, не про криворуких кодеров — речь про дизайн языка.
cдаётся мне, первый, кто напишет для «кривых, плохих, тупых, нелогичных и вообще корявых» функций враппер в виде “красиво и правильно именованных” функций и выложит его в виде pecl-модуля станет просто мега-героем…
зачем оно в ядре? лично меня устраивают и такие названия.
а вот пекл — самое оно… хочешь — ставишь, не хочешь не ставишь…
а вот пекл — самое оно… хочешь — ставишь, не хочешь не ставишь…
ну лично у меня не пухнет, наверное у меня неправильный мозг.
можете предложить ваши варианты названий для этих функций (просто интересно).
preg_match_all прекрасно работает с UTF-8, надо только уметь читать мануал, в котором чётко написано про модификатор u. а те кто не умеют читать — видимо сейчас заполняют баг-репорт…
можете предложить ваши варианты названий для этих функций (просто интересно).
preg_match_all прекрасно работает с UTF-8, надо только уметь читать мануал, в котором чётко написано про модификатор u. а те кто не умеют читать — видимо сейчас заполняют баг-репорт…
ну вот видите :)
мне даже кажется, что если залезть с сорцу пхп, то там все эти функции сделаны именно так, как вы описали, а именно флагами от одной функции добиваются нужного эффекта…
поверьте и у случае с флагами было бы огромного количество недовольных «этой тупорылой функцией сортировки массивов с тучей мрачных флагов»
мне даже кажется, что если залезть с сорцу пхп, то там все эти функции сделаны именно так, как вы описали, а именно флагами от одной функции добиваются нужного эффекта…
поверьте и у случае с флагами было бы огромного количество недовольных «этой тупорылой функцией сортировки массивов с тучей мрачных флагов»
Да ладно имена. Чёрт с ними. Вы мне объясните — кем надо быть чтобы создать такой ублюдочный API для регулярных выражений? Вы посмотрите на эту функцию:
Почему так? Потому что работа с регулярными выражениями состоит из двух частей:
1. Создание конечного автомата из регулярного выражения (задача весьма медленная и, как правильно, не оптимизированная).
2. Поиск в строке с использованием ранее построенного автомата.
Разница в скорости работы этих фонкций — порядки! Для сложных регулряных выражений — сотни и тысячи раз! Что мы имеем в PHP? Правильно: эти две операции объединены! Притом что в используемой библиотеке они, как и положено, разнесены по разным функциям (что должно было бы, в общем, заставить задуматься).
Я не против функций, объединяющих эти действия — иногда этот гибрид вполне может оказаться полезным (скажем вы обрабатываете регулярным выражением ровно одну строку). Но когда это — основной и единственный API… И после этого вы продолжаете утверждать что PHP писали вменяемые люди?
int preg_match_all ( string $pattern, string $subject, array $&matches [, int $flags [, int $offset ]] )Какой диагноз? Правильно: расстрел на месте через повешенье.
Почему так? Потому что работа с регулярными выражениями состоит из двух частей:
1. Создание конечного автомата из регулярного выражения (задача весьма медленная и, как правильно, не оптимизированная).
2. Поиск в строке с использованием ранее построенного автомата.
Разница в скорости работы этих фонкций — порядки! Для сложных регулряных выражений — сотни и тысячи раз! Что мы имеем в PHP? Правильно: эти две операции объединены! Притом что в используемой библиотеке они, как и положено, разнесены по разным функциям (что должно было бы, в общем, заставить задуматься).
Я не против функций, объединяющих эти действия — иногда этот гибрид вполне может оказаться полезным (скажем вы обрабатываете регулярным выражением ровно одну строку). Но когда это — основной и единственный API… И после этого вы продолжаете утверждать что PHP писали вменяемые люди?
у вас есть реальные замеры производительности в языке с типа_прекомпайлингом патерна и пхп?
просто интересно
просто интересно
Чушь собачья. Вообще-то можно элементарно кешировать откомпилированные последние использованиные регекспы.
А то, что поиск работает быстрее компиляции — вообще чушь собачья. возьмите-ка текст на 50 Кб и простенький регекксп и посмотрите.
А то что вы предлагаете, отдельно сделать компиляцию регекспа, а отдельно — выполнение, так идите-ка вы подальше с такими идеями, делать мне больше нечего писать всюду теперь по 2 функции вместо одной!
А то, что поиск работает быстрее компиляции — вообще чушь собачья. возьмите-ка текст на 50 Кб и простенький регекксп и посмотрите.
А то что вы предлагаете, отдельно сделать компиляцию регекспа, а отдельно — выполнение, так идите-ка вы подальше с такими идеями, делать мне больше нечего писать всюду теперь по 2 функции вместо одной!
Facebook.
Вы просто не умеете его готовить.
Вы просто не умеете его готовить.
А не страшно использовать конечный автомат для такого?
Как мониторите среднее время выполнения запроса и сколько запросов в секунду обрабатываете на ядро?
Как мониторите среднее время выполнения запроса и сколько запросов в секунду обрабатываете на ядро?
И стоило так мучатся при наличии таких превосходных инструментов как Catalyst и Muse?
как хак — пойдёт, молодцы ребята. в продакшн — боже сохрани.
nginx — сервер не мультитредовый, исполнение перла блокирует обработку запросов.
в итоге все его преимущества разом идут лесом. в итоге вы получили масштабируемость от числа воркеров.
поздравляю, вы изобрели апач 1.3 :)
nginx — сервер не мультитредовый, исполнение перла блокирует обработку запросов.
в итоге все его преимущества разом идут лесом. в итоге вы получили масштабируемость от числа воркеров.
поздравляю, вы изобрели апач 1.3 :)
Круто замешан колобок :)
Я уже думал, что окончательно просветлился, но сейчас понимаю, что я реально в танке.
Выходит, то что я написал выше про фронтенд-бекенд — это несущественная фигня по сравнению с этим?
Что значит «масштабируемость от числа воркеров», можно чуть подробнее?
И чем отличается выполнение «в самом себе» перла от отдачи картинки или запроса на бекенд?
Я уже думал, что окончательно просветлился, но сейчас понимаю, что я реально в танке.
Выходит, то что я написал выше про фронтенд-бекенд — это несущественная фигня по сравнению с этим?
Что значит «масштабируемость от числа воркеров», можно чуть подробнее?
И чем отличается выполнение «в самом себе» перла от отдачи картинки или запроса на бекенд?
я думаю мы говорим об одном и том же.
если цель состояла в избавлении от «бэкенда», т.е. отдельного сервера для обработки скриптов и совмещения его с «лёгким», использующимся для раздачи статики, то она не выполнена. а всё потому, что обработка перла тормозит всю работу воркера nginx. так что в этом смысле полученный резльтат даже хуже чем апач 1.3: если воркер nginx обрабатывает 1000 запросов на отдачу картинок и ему приходит 1001-й запрос, который уходит во встроенный перл и заставляет его задуматься, то обработка остальных запросов останавливается.
nginx очень хорошо справляется с задачей по «перекладыванию» данных между файл-дескрипторами (отдача статики, проксирование), но производить какие-либо нетривиальные вычисления в этом цикле категорически нельзя.
если цель состояла в избавлении от «бэкенда», т.е. отдельного сервера для обработки скриптов и совмещения его с «лёгким», использующимся для раздачи статики, то она не выполнена. а всё потому, что обработка перла тормозит всю работу воркера nginx. так что в этом смысле полученный резльтат даже хуже чем апач 1.3: если воркер nginx обрабатывает 1000 запросов на отдачу картинок и ему приходит 1001-й запрос, который уходит во встроенный перл и заставляет его задуматься, то обработка остальных запросов останавливается.
nginx очень хорошо справляется с задачей по «перекладыванию» данных между файл-дескрипторами (отдача статики, проксирование), но производить какие-либо нетривиальные вычисления в этом цикле категорически нельзя.
Спасибо, суть я кажется уловил. Проблема в том что воркер «поперхнется» запросом на обработку встроенного перла и вся очередь встает, то есть нужно вешать больше воркеров, чтобы очереди были короче.
Отличие от запроса на бекенд здесь в том, что воркер умеет «распараллеливать» такие вещи, а обработку встроенного перла — нет.
Я правильно понимаю?
Отличие от запроса на бекенд здесь в том, что воркер умеет «распараллеливать» такие вещи, а обработку встроенного перла — нет.
Я правильно понимаю?
именно.
Отлично. Спасибо за взрыв мозга, пошел грызть теорию до полного просветления…
я так понял, что вы фактически перечеркнули результаты работы «настоящих русских парней»?
Не совсем =)
Если воркер начинает захлебываться от потока запросов, то не будет никакой разницы на бэкэнде он или на встроенном перле. Клиент будет тупить пока до него очередь не дойдет.
Все равно в таком случае надо что-то делать
Если воркер начинает захлебываться от потока запросов, то не будет никакой разницы на бэкэнде он или на встроенном перле. Клиент будет тупить пока до него очередь не дойдет.
Все равно в таком случае надо что-то делать
со встроенным перлом он начнёт захлёбываться куда раньше.
таким образом, сервить «тяжёлые» страницы вместе с «лёгкими» (статикой) становится невозможно, потому что тяжёлые страницы (на встроенном перле) блокируют всё подряд (эффект, которым апач не страдает).
начинаем добавлять воркеров, сгружать статику (чтоб не тупила), оставляем только тяжёлые страницы… что получается? получается тот же апач 1.3, только с извращениями. польза? знакомство со внутренностями nginx, изощрённый трах с embedded перлом, но никак не рабочее решение.
таким образом, сервить «тяжёлые» страницы вместе с «лёгкими» (статикой) становится невозможно, потому что тяжёлые страницы (на встроенном перле) блокируют всё подряд (эффект, которым апач не страдает).
начинаем добавлять воркеров, сгружать статику (чтоб не тупила), оставляем только тяжёлые страницы… что получается? получается тот же апач 1.3, только с извращениями. польза? знакомство со внутренностями nginx, изощрённый трах с embedded перлом, но никак не рабочее решение.
Весьма интересно, спасибо вам!
Скорее всего, даже если бы вы решили все перекодить, но при этом оставили бы первый пункт в покое и исправили бы следующие два, то гемора было бы намного меньше.
Прочитал статью, отложил в ящичек, решил попробовать при случае, порадовался даже слегка, а потом почитал коменты и понял, что все же mod_perl наше всё. Отличную работу провели в статье, вот только инструменты не те, да-с, совсем не те, как оказалось.
Главное, что это прецендент — перл в nginx юзабелен, и это на самом деле немаленькое достижение :)
Читается как фэнтэзи. Герои попали в необычную ситуацию и вынуждены делать ответственную работу в сжатые сроки и в непривычных условиях.
За быдлокод надо руки отрывать, сразу все быстро научатся писать нормально.
очень интересно, что скажут люди, которые сей проект будут (рано или поздно) обновлять (расширять, менять)? думаю, много (не)лестных слов в адрес «джедаев» :))
Спасибо за интересную статью. Сам я благополучно (и с удовольствием) забыл перл лет этак пять уже как.
Ну зря вы mod_perl обижаете. Всё там очень хорошо и интересно ;)
А встроеный энжайновский перл исключительно для маленьких быстреньких скриптов.
А встроеный энжайновский перл исключительно для маленьких быстреньких скриптов.
Сильные духом бы, написали сайт как модуль к nginx, или встроели бы в него bf, и реализовали на нем :)
Вот это сила духа, вот это да! А у вас…
Вот это сила духа, вот это да! А у вас…
не надо искушать =)
Вообще-то путать асинхронный сервер, и синхронно выполняемый язык это — дибилизм.
Появилась необходимость обработать POST запрос на стороне nginx, доку вроде нашел, но все же не смог разобраться толком.
Пакет у меня: nginx-0.7.67-1.fc13.i686
Вот такое я накодил:
use nginx;
package mymodule;
our $r;
sub check_input {
$r = shift;
if ( $r->request_method eq 'POST' ) {
$r->has_request_body( \&mymodule::check_input_process_post );
}
return 0;
}
sub check_input_process_post {
return 1;
}
1;
__END__
в результате, получил ошибку сегментации
2010/09/14 15:30:12 [notice] 2488#0: signal 17 (SIGCHLD) received
2010/09/14 15:30:12 [alert] 2488#0: worker process 2526 exited on signal 11 (core dumped)
2010/09/14 15:30:12 [notice] 2488#0: start worker process 2539
2010/09/14 15:30:12 [notice] 2488#0: signal 29 (SIGIO) received
2010/09/14 15:30:12 [notice] 2488#0: signal 17 (SIGCHLD) received
2010/09/14 15:30:12 [alert] 2488#0: worker process 2524 exited on signal 11 (core dumped)
2010/09/14 15:30:12 [notice] 2488#0: start worker process 2541
2010/09/14 15:30:12 [notice] 2488#0: signal 29 (SIGIO) received
с помощью научного тыка, выяснил, что проблема у меня в:
$r->has_request_body( \&mymodule::check_input_process_post );
судя по логам измеенений, ранее была проблема с $r->has_request_body, но начиная с версии 0.6.22 должны были устранить…
… кто-то может мне помочь? )
Пакет у меня: nginx-0.7.67-1.fc13.i686
Вот такое я накодил:
use nginx;
package mymodule;
our $r;
sub check_input {
$r = shift;
if ( $r->request_method eq 'POST' ) {
$r->has_request_body( \&mymodule::check_input_process_post );
}
return 0;
}
sub check_input_process_post {
return 1;
}
1;
__END__
в результате, получил ошибку сегментации
2010/09/14 15:30:12 [notice] 2488#0: signal 17 (SIGCHLD) received
2010/09/14 15:30:12 [alert] 2488#0: worker process 2526 exited on signal 11 (core dumped)
2010/09/14 15:30:12 [notice] 2488#0: start worker process 2539
2010/09/14 15:30:12 [notice] 2488#0: signal 29 (SIGIO) received
2010/09/14 15:30:12 [notice] 2488#0: signal 17 (SIGCHLD) received
2010/09/14 15:30:12 [alert] 2488#0: worker process 2524 exited on signal 11 (core dumped)
2010/09/14 15:30:12 [notice] 2488#0: start worker process 2541
2010/09/14 15:30:12 [notice] 2488#0: signal 29 (SIGIO) received
с помощью научного тыка, выяснил, что проблема у меня в:
$r->has_request_body( \&mymodule::check_input_process_post );
судя по логам измеенений, ранее была проблема с $r->has_request_body, но начиная с версии 0.6.22 должны были устранить…
… кто-то может мне помочь? )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встроенному perl'у быть!