Это единственная придирка к букве текста, которую можно найти, да.
Общий же смысл написанного, заголовок и приведённые примеры говорят о передаче приватной информации в URI вообще, а не только через формы.
Так что подразумевается здесь совсем другое.
RFC 2616
15.1.3 Encoding Sensitive Information in URI's
Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
Исходные данные не имеют ничего общего с выводами.
1. Нельзя приравнивать аудиторию Stackoverflow к программистам вообще.
Количество программистов не сокращается с возрастом. С возрастом сокращается желание отвечать на одни и те же ламерские вопросы.
Как и везде, основную массу на SO составляет школота, а специалистов очень мало — им тупо некогда просиживать штаны на сайте. Вот и ответ на загадку, куда деваются программисты.
2. Рейтинг ответа никак не говорит о его качестве. Скорее наоборот. Всё та же школота радостно плюсует ответы на примитивные вопросы, но, не понимая более сложные, просто обходит их стороной.
Нет-нет! ни в коем случае!
Здесь это не работает.
Вот и автор даже сам уже сто раз повторил, что на других системах все будет по-другому (какой тогда вообще смысл было писать — это другой вопрос). То есть, он сам же и пишет, что НЕ НАДО обращаться к его статье.
Оптимизация — это процесс. Её нельзя просто «добавить». В каждом конкретном случае надо действовать по-разному.
Хороший пример — база данных.
Плохая статья напишет «добавь индекс на поле, по которому идет поиск». Хорошая — «изучай эксплейны для твоего КОНКРЕТНОГО случая». Это не всегда занимает 5 минут. Но это то, что реально помогает, и то, что приходится делать.
Но вообще, конечно, это все пустое. Подавляющее большинство комментаторов никогда в жизни не столкнутся с необходимостью опртимизации, а столкнувшись — будут решать ее совсем другими средствами. Не зря на форумах так много вопросов «какая самая ыбыстрая CMS»
Потому что «сделать что-нибудь такое, чтобы сервера не пришлось апгрейдить» — это и есть оптимизация. То есть вы тоже восприняли эту статью именно так. Другого-то смысла у нее и вовсе нету.
Ну вот в этом реально работающем проекте поменять один сравниваемый метод на другой, померять, поменять обратно и снова померять.
Увидим разницу — начнем думать, как оптимизировать (hint: — совем не обязательно на тему смены одной функции на другуюю К примеру, в первом классе детей учат, что если возникают проблемы с чтением большого файла, надо не file() на file_get_contents() менять, а подход в целом, не запихивая весь файл в память целиком)
Не увидим — просто пожалеем о потраченном времени и пойдем займемся чем-нибудь полезным. Профайлингом, например. Который нам заранее скажет — стоит ли возиться с данной конкретной разницей между конкатенациями, или нет.
В этом интересно покопаться с теоретической точки зрения. Но для практической оптимизации — только профайлинг. Качественный, а не искусственный. профайлинг приложения, а не кода, который ничего не делает
В то-то и дело, что нет тут никаких дополнительных возможностей.
Даже автор уже изъюлился весь — «летают, но нызенько-нызенько! На разных осях/сборках/машинах все будет по-разному!!» Ну и толку-то тогда в этих советах, если у соседа они приведут не к экономии, а к расходам?
На самом деле — бред, конечно. Ни к экономии, ни к расходам этот набор заклинаний не имеет никакого отношения.
Дело не в том, какая функция быстрее или медленнее. А в том, что эта разница не влияет на конечный результат. Ключевое слово — конечный результат. На конечном результате мы получим неразличимую разницу — в пределах погрешности.
Это очень сложно понять тому, кто ни разу не пользовался профайлингом и не научился отличать значимое от незначительного. Но рекомендую хотя бы попытаться.
Закон оптимизации только один — профайлинг. Других нету. Действует везде.
Профайлинг приложения в целом, а не искусственного кода на однопользовательской машине.
Человек именно что маялся дурью.
Тe самые запросы выполняются в миллионы раз дольше, чем высиженная здесь мифическая разница между count и sizeof. Весь этот «рефакторинг» высосан из пальца. И оптимизировать надо их, а не это фуфло.
Рефакторинг, my ass. Вот ты аффтару подсуропил. Он-то пытается сейчас закосить под девочку, выставить свои поучения как ни к чему не обязывающие советы, типа «Ну если все равно какую функцию использовать, то лучше „более быструю“. На этапе разработки, разумеется. Но даже он и в кошмарном сне себе не представит, что по его статье надо срочно садиться и перепахивать весь код на использование „более быстрых функций“.
Продолжай его защищать. С такими друзьями врагов не надо :)
На самом деле foreach удобнее. Универсальнее.
А если на критическом к времени выполнения участке обрабатываемый массив имеет такой размер, что заходит речь о сравнении различных методов его перебора, то надо, префразируя известный анекдот, программистов менять, а не функции местами переставлять.
Копаться в потрохах всегда интересно. Но делать это в таких топиках — это играть с горе-оптимизаторами на их поле, в игру быстрее-медленнее.
На самом деле, чтобы облегчить жизнь серверу, надо переписать приложение так, чтобы ему не требовалось часто открывать большой файл.
Вот это действительно будет «облегчение».
А поиск функции, которая выполнит эту тяжелую операцию на 2% быстрее — это игра в куличики, а не оптимизация.
Фееричное, в соскдних предложениях:
1) «Даже на Debian и Ubuntu, PHP иногда ведёт себя по разному».
2) «Тут просто список особенностей поведения.»
Фигли писать список особенностей (зачем он вообще нужен — другой вопрос), если сам же тут же говоришь, на разных системах особенности даже не воспроизводятся.
Тут не сюсюкать надо. Тут за шкирку и в кучу носом натыкать.
Общий же смысл написанного, заголовок и приведённые примеры говорят о передаче приватной информации в URI вообще, а не только через формы.
Так что подразумевается здесь совсем другое.
15.1.3 Encoding Sensitive Information in URI's
Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
вопрос не в том, каким экстеншеном ты пользуешься, а в том, используются ли в коде голые функции API.
1. Нельзя приравнивать аудиторию Stackoverflow к программистам вообще.
Количество программистов не сокращается с возрастом. С возрастом сокращается желание отвечать на одни и те же ламерские вопросы.
Как и везде, основную массу на SO составляет школота, а специалистов очень мало — им тупо некогда просиживать штаны на сайте. Вот и ответ на загадку, куда деваются программисты.
2. Рейтинг ответа никак не говорит о его качестве. Скорее наоборот. Всё та же школота радостно плюсует ответы на примитивные вопросы, но, не понимая более сложные, просто обходит их стороной.
Обсуждать эти «выводы» бессмысленно
А насчет странности термина — это не к нам. Это к старику Кнуту, о котором флейм выше.
как я и говорил — аффтар тобой недоволен. Найди, говорит, слово «рефакторинг» в моей статье и извинись!
лизать-то тоже надо с умом, хе-хе
Здесь это не работает.
Вот и автор даже сам уже сто раз повторил, что на других системах все будет по-другому (какой тогда вообще смысл было писать — это другой вопрос). То есть, он сам же и пишет, что НЕ НАДО обращаться к его статье.
Оптимизация — это процесс. Её нельзя просто «добавить». В каждом конкретном случае надо действовать по-разному.
Хороший пример — база данных.
Плохая статья напишет «добавь индекс на поле, по которому идет поиск». Хорошая — «изучай эксплейны для твоего КОНКРЕТНОГО случая». Это не всегда занимает 5 минут. Но это то, что реально помогает, и то, что приходится делать.
Но вообще, конечно, это все пустое. Подавляющее большинство комментаторов никогда в жизни не столкнутся с необходимостью опртимизации, а столкнувшись — будут решать ее совсем другими средствами. Не зря на форумах так много вопросов «какая самая ыбыстрая CMS»
Увидим разницу — начнем думать, как оптимизировать (hint: — совем не обязательно на тему смены одной функции на другуюю К примеру, в первом классе детей учат, что если возникают проблемы с чтением большого файла, надо не file() на file_get_contents() менять, а подход в целом, не запихивая весь файл в память целиком)
Не увидим — просто пожалеем о потраченном времени и пойдем займемся чем-нибудь полезным. Профайлингом, например. Который нам заранее скажет — стоит ли возиться с данной конкретной разницей между конкатенациями, или нет.
В этом интересно покопаться с теоретической точки зрения. Но для практической оптимизации — только профайлинг. Качественный, а не искусственный. профайлинг приложения, а не кода, который ничего не делает
Даже автор уже изъюлился весь — «летают, но нызенько-нызенько! На разных осях/сборках/машинах все будет по-разному!!» Ну и толку-то тогда в этих советах, если у соседа они приведут не к экономии, а к расходам?
На самом деле — бред, конечно. Ни к экономии, ни к расходам этот набор заклинаний не имеет никакого отношения.
Дело не в том, какая функция быстрее или медленнее. А в том, что эта разница не влияет на конечный результат. Ключевое слово — конечный результат. На конечном результате мы получим неразличимую разницу — в пределах погрешности.
Это очень сложно понять тому, кто ни разу не пользовался профайлингом и не научился отличать значимое от незначительного. Но рекомендую хотя бы попытаться.
Желательно — под нагрузкой.
Профайлинг приложения в целом, а не искусственного кода на однопользовательской машине.
Человек именно что маялся дурью.
Тe самые запросы выполняются в миллионы раз дольше, чем высиженная здесь мифическая разница между count и sizeof. Весь этот «рефакторинг» высосан из пальца. И оптимизировать надо их, а не это фуфло.
Рефакторинг, my ass. Вот ты аффтару подсуропил. Он-то пытается сейчас закосить под девочку, выставить свои поучения как ни к чему не обязывающие советы, типа «Ну если все равно какую функцию использовать, то лучше „более быструю“. На этапе разработки, разумеется. Но даже он и в кошмарном сне себе не представит, что по его статье надо срочно садиться и перепахивать весь код на использование „более быстрых функций“.
Продолжай его защищать. С такими друзьями врагов не надо :)
А если на критическом к времени выполнения участке обрабатываемый массив имеет такой размер, что заходит речь о сравнении различных методов его перебора, то надо, префразируя известный анекдот, программистов менять, а не функции местами переставлять.
Копаться в потрохах всегда интересно. Но делать это в таких топиках — это играть с горе-оптимизаторами на их поле, в игру быстрее-медленнее.
Вот это действительно будет «облегчение».
А поиск функции, которая выполнит эту тяжелую операцию на 2% быстрее — это игра в куличики, а не оптимизация.
habrahabr.ru/blogs/php/102598/#comment_3188263
«летают, но нызенько-нызенько»
Фееричное, в соскдних предложениях:
1) «Даже на Debian и Ubuntu, PHP иногда ведёт себя по разному».
2) «Тут просто список особенностей поведения.»
Фигли писать список особенностей (зачем он вообще нужен — другой вопрос), если сам же тут же говоришь, на разных системах особенности даже не воспроизводятся.
Тут не сюсюкать надо. Тут за шкирку и в кучу носом натыкать.