Вы внимательно читали что я писал в комментарии своём?
Я писал что это не защита, это вынужденная мера, так как технология активации флеша без клика на него нарушала патент и от MicroSoft через суд добились выпуска патча, который эту технологию убирал из Internet Explorer
В подкасте говорится что рамка вокруг flash в IE это баг. На самом деле это не так.
Причина появления этой рамки - патенты. Microsoft пришлось сделать такую рамку так как они использовали чью-то технологию активации Flash и им запретили ею пользоваться через суд, поэтому мы и живём теперь с этой рамкой и на MSDN есть скрипт от Microsoft как обойти эту проблему :)
Его стоит использовать осторожно. На практике для запросов, где выборки быстрые из-за индексов (даже если с 5-6 JOIN) CALC_FOUND_ROWS тормозит выполнение запроса по одной простейшей причине - ему нужно выбрать ВСЕ записи (а не LIMIT 20, 20) что-бы знать сколько их всего - это значит что у вас делается запрос без WHERE, записывается кол-во строк и потом фильтруется через WHERE. Так что используйте SELECT COUNT(id) FROM
SQL_CALC_FOUND_ROWS нужно использовать для совсем тяжелых запросов, где происходит сканирование таблицы в любом случае - вот там он идиально работает и не даёт никаког overhead.
Все выше сказанное проверено опытным путём на довольно большом проекте, в котором мы в итоге вырезали с порядка 150 запросов SQL_CALC_FOUND_ROWS оставив его только в небольшой части самых сложных и тяжеловестных запросах. Серверу полегчало раз так в 5-6. Кто не верит - проверьте сами.
Вообще на PHP нападают все кому не лень. И С/С++, С шарписты (C#), и Java и питонисты, и дельфисты и.т.д., причём замечу что в основном это одностороннее - все орут на PHP, а PHP разработчики отбиваются и никого как правило не хаят.
Многие видят проблемы PHP там, где их реально нет - проблема в слепости и однобокости подхода или не желании подумать, или даже в нехватки знаний и воображения. Так же часто упёртость по типу "Я пишу на функциях, значит здесь объекту делать нечего" или наоборот. В 99% случаев это в корне не верно. Надо уметь мешать функции и ООП, надо делать так, что бы работало быстро и было удобно для програмиста. Не нужно прикручивать что-то монструозное для среднего проекта, так же как и не стоит брать что-то среднее по размеру для монструозного проекта. Тоесть надо уметь соотносить размер проекта и размер используемой системы, архитектуры и подхода. Для небольших проектов (небольшой сайт компании с некоторым специфичным функционалом) - функции или возможно постейший базовый класс который делает минимум функционала - грузит модули и возможно обеспечивает права доступа - с использованием функций.
Средний проект - уже с упором на объектную модель, с более-менее сложной логикой но и про функции забывать не стоит. Перегружать всякими мега-ооп штуками тоже не стоит - повышение сложности понимания да и на время разработки особо не повлияет.
Большой проект - вот тут уже в основном чистый ООП подход. Модули таких систем как правило не маленькие и OOP overhead в данном случае будет просто стремится к нулю. Конечно нужно делать с умом, не стоит делать небольшой объект только ради контейнера для десятка функций, специфичных для пары модулей - вынесите в фаил и делайте include.
Моё мнение таково, что большинство не умеют или не хотят видеть ту границу разумности. Они просто делают, потом оказывается что всё плохо, да уже поздно. Кто-то перепишет, а кто-то будет костылять дальше из-за невозможности всё переделать.
Ну многие работодатели смотрят на то, что знает и с чем работал человек помимо стандартной связки, поэтому стоит указывать и прочее тоже.
Да и наличие высшего образования по компъюторным наукам я считаю огромным плюсом - лично я без их знания много что не понимал и не знал. Или не так легко было-бы разобраться. Реально свои знания можно показать только на собеседовании, и то только если собеседование будет проводить подкованный в этой области человек (при последнем собеседовании у меня между делом спросили сколько будет 2 в 7-й степени - ответил чисто машинально 128 ну и ещё пара специфичных вопросов было. В итоге взяли и дали даже больше чем я просил)
Я вот не понимаю одного - что все так привязались к PHP.
Это не язык плохой, это программисты пишушие на нём хреновые. К тому же на одном PHP + MySQL далеко не уедешь, нужно смотреть более широко. Есть довольно много разных технологий, которые можно использовать вместе с PHP и добиватся довольно хороших результатов.
А хороших PHP программистов (99% массы - кодеры) действительно мало. ИТ образование серьёзное за плечами имеет мало кто. И как правило такие программисты чуствуют себя прекрасно на связке PHP + MySQL|PostgreSQL + JavaScript (более-менее серьёзные разработки на нём). Со временем они приходят ещё и к C++|Java|Python и через 5-6 лет могут творить чудеса :)Хотя можно прекрасно обходится и одним PHP - была бы голова на месте и руки.
Я писал что это не защита, это вынужденная мера, так как технология активации флеша без клика на него нарушала патент и от MicroSoft через суд добились выпуска патча, который эту технологию убирал из Internet Explorer
Читать это http://www.securitylab.ru/news/302122.ph…
Причина появления этой рамки - патенты. Microsoft пришлось сделать такую рамку так как они использовали чью-то технологию активации Flash и им запретили ею пользоваться через суд, поэтому мы и живём теперь с этой рамкой и на MSDN есть скрипт от Microsoft как обойти эту проблему :)
Его стоит использовать осторожно. На практике для запросов, где выборки быстрые из-за индексов (даже если с 5-6 JOIN) CALC_FOUND_ROWS тормозит выполнение запроса по одной простейшей причине - ему нужно выбрать ВСЕ записи (а не LIMIT 20, 20) что-бы знать сколько их всего - это значит что у вас делается запрос без WHERE, записывается кол-во строк и потом фильтруется через WHERE. Так что используйте SELECT COUNT(id) FROM
SQL_CALC_FOUND_ROWS нужно использовать для совсем тяжелых запросов, где происходит сканирование таблицы в любом случае - вот там он идиально работает и не даёт никаког overhead.
Все выше сказанное проверено опытным путём на довольно большом проекте, в котором мы в итоге вырезали с порядка 150 запросов SQL_CALC_FOUND_ROWS оставив его только в небольшой части самых сложных и тяжеловестных запросах. Серверу полегчало раз так в 5-6. Кто не верит - проверьте сами.
Многие видят проблемы PHP там, где их реально нет - проблема в слепости и однобокости подхода или не желании подумать, или даже в нехватки знаний и воображения. Так же часто упёртость по типу "Я пишу на функциях, значит здесь объекту делать нечего" или наоборот. В 99% случаев это в корне не верно. Надо уметь мешать функции и ООП, надо делать так, что бы работало быстро и было удобно для програмиста. Не нужно прикручивать что-то монструозное для среднего проекта, так же как и не стоит брать что-то среднее по размеру для монструозного проекта. Тоесть надо уметь соотносить размер проекта и размер используемой системы, архитектуры и подхода. Для небольших проектов (небольшой сайт компании с некоторым специфичным функционалом) - функции или возможно постейший базовый класс который делает минимум функционала - грузит модули и возможно обеспечивает права доступа - с использованием функций.
Средний проект - уже с упором на объектную модель, с более-менее сложной логикой но и про функции забывать не стоит. Перегружать всякими мега-ооп штуками тоже не стоит - повышение сложности понимания да и на время разработки особо не повлияет.
Большой проект - вот тут уже в основном чистый ООП подход. Модули таких систем как правило не маленькие и OOP overhead в данном случае будет просто стремится к нулю. Конечно нужно делать с умом, не стоит делать небольшой объект только ради контейнера для десятка функций, специфичных для пары модулей - вынесите в фаил и делайте include.
Моё мнение таково, что большинство не умеют или не хотят видеть ту границу разумности. Они просто делают, потом оказывается что всё плохо, да уже поздно. Кто-то перепишет, а кто-то будет костылять дальше из-за невозможности всё переделать.
Да и наличие высшего образования по компъюторным наукам я считаю огромным плюсом - лично я без их знания много что не понимал и не знал. Или не так легко было-бы разобраться. Реально свои знания можно показать только на собеседовании, и то только если собеседование будет проводить подкованный в этой области человек (при последнем собеседовании у меня между делом спросили сколько будет 2 в 7-й степени - ответил чисто машинально 128 ну и ещё пара специфичных вопросов было. В итоге взяли и дали даже больше чем я просил)
Это не язык плохой, это программисты пишушие на нём хреновые. К тому же на одном PHP + MySQL далеко не уедешь, нужно смотреть более широко. Есть довольно много разных технологий, которые можно использовать вместе с PHP и добиватся довольно хороших результатов.
А хороших PHP программистов (99% массы - кодеры) действительно мало. ИТ образование серьёзное за плечами имеет мало кто. И как правило такие программисты чуствуют себя прекрасно на связке PHP + MySQL|PostgreSQL + JavaScript (более-менее серьёзные разработки на нём). Со временем они приходят ещё и к C++|Java|Python и через 5-6 лет могут творить чудеса :)Хотя можно прекрасно обходится и одним PHP - была бы голова на месте и руки.