Во-первых, я ничего не изобретаю. Ну и ок, вы правы, вынос картинок на отдельный домен тоже хороший способ, я не знал про эту особенность работы браузеров.
Остаются ситуация, когда заголовки http и картинка весят существенно больше чем base64 и случай с узким каналом, когда всё выглядит некрасиво из-за недогрузившихся мелких графических элементов (аякс тут тоже тормозит - канал-то занят).
Уменьшение числа запросов здесь скорее не для уменьшения нагрузки на сервер, а для ускорения загрузки страницы. см. выше комментарии про аякс, который стоит пока грузятся картинки.
ну и + принудительный показ CAPTCHA (см. мой комментарий строчкой ниже)
тут есть ещё один мега-приятный побочный эффект. в FF с плагином ImagesLikeOpera интегрированные картинки показываются всегда, независимо от настроек плагина.
ниже попробую разделить "советы" на классы так, как я их вижу:
I. не оптимизация, а правила здравого смысла, хорошего тона и культуры программирования. по большей части не имеют отношения непосредственно к php:
13 (сильно удивился что следующим пунктом не было ничего про switch), 1, 9, 10, 11, 17, 18, 23, 24, 28, 36, 39
II. Оптимизации очень низкого уровня, имеющие смысл разве что внутри очень длинных циклов и занимающие большой процент времени:
29 (то же самое что и 3), 40 (если это имеет смысл. например 90% времени уходит на эти функции и реализация на C будет как минимум разы эффективнее)
III. советы, ведущие к отказу от важных плюшек, предоставляемых языком в угоду несущественной оптимизации. Подобные прблемы должны быть проблемой транслятора, а не программиста (aka "с таким подходом вам бы на чистом C писать..."):
5, 6, 7, 8, 21, 22, 26, 27, 33 (хак!), 34, 35,
IV: резонно, но если выполнимо, то скорее относится к первому пункту.
2, 14, 19
V: действительно разумный подход к оптимизации - взваливание проблем на внешние решения, не требующие модификации кода:
15, 31
VI: пункты, вызвавшие у меня недоумение, непонимание, или смех. Если кто-то с ними согласен, пожалуйста, объясните что к чему.
16. зачем это вдруг???
30. это примерно то же, что и 29, только в профиль и на другом уровне. в принципе, резонно, но уж слишком очевидно чтобы упоминать в списке.
32 - первая половина - пункт V, вторая - то же что 31.
37. помимо повторного использования есть и другие мотивы разбиения методов!
38. есть побочные эффекты - метод разрастется до той степени, пока разбивать его не становится слишком сложно, потом рабиение откладывается на потом, и так он и останется толстым и сложным. Надо думать о таких вещах на этапе проектирования.
41. это техника, совершенно в стороне от остального.
42. никакого отношения к пхп не имеет. имел бы - был бы в разделе V.
для интерфейсов - есть (-:
правда это сомнительное преимущество, которое стоит использовать с крайней аккуратностью и точно зная почему это стало необходимо, ибо за довольно редкими и очевидными исключениями, если класс имплементирует сразу пачку интерфейсов, то это обычно сигнализирует о нарушении single responsibility principle ( http://en.wikipedia.org/wiki/Single_responsibility_principle )
регулярка и js - это дело наживное (кроме того js - вообще другой язык, напрямую к делу почти не относящийся)
про OSI - имхо правильный вопрос.
про "что происходит" - действительно, респект и уважуха. я прям представил как человек уточняет какая операционка, какой браузер, какой адрес (как минимум - какого уровня домен) и какой с той стороны сервер... и понеслась. через 20 минут доходим до ресолва днса, через несколько часов - до разбора заголовков http (если там http!)... к пятому дню собеседования можно распарсить собственно тело ответа... (-: жуть, просто триллер какой-то.
а как поменять значения двух переменных местами, не задействуя третью, нас в восьмом классе учиили. странный вопрос.
так он не предлагает ставить пятилетний. он предлагает не ставить топовое оборудование типа сверхбыстрой памяти, матерей со сверхбыстрой шиной и сверхрзогнанных процов. т.е. всё что появилось за последние полгода-год (-:
спорный, в общем, момент. я например не согласен. ибо если оборудование начнет глючить, то в первый год, пока оно на гарантии.
по несколько более высокому курсу есть вполне легальный способ ввода и вывода реальных денег - за иски можно покупать геймкоды, которые потом никто не запрещает продавать за реальные баксы.
повторяю свою изначальную мысль... "поддосят 3-4 дня и отстанут" - только если это попытка забить 100Мб канал потоком всего в 25Мб. Если это достаточно умный ддос, формурующий запросы сильно нагружающие приложение (например, опять-же, базу данных), то, несмотря на относительно свободный интернет канал, атака будет успешной. Подскочат averages под сотню-другую и всё встанет раком. Именно поэтому стоит даже такие на первый взгляд безобидные ддосы отслеживать и пресекать.
Прояессор в россии - это не учёная степень, это учебное звание, если человек работает в институте. Профессором теоретически может быть как доктор, так и кандидат.
либо пишите так чтобы unset надобился максимально редко. Я вот сейчас чисто из интереса пересмотрел немалую часть кода - не нашел ни одного случая, где я не уверен в содержимом переменной и одновременно оно имеет значение.
насколько я помню, f/4.5 означает что оптический диаметр диафрагмы в 4.5 раза меньше фокусного расстояния. Диаметр линзы вообще всегда ни при чем и всего-лишь ограничивает диафрагму.
разобрал непонятку с Windows/Linux: переводчик сиильно ошибся.
в оригинале было
Because the L in LAMP stands for Linux, not Looney. Customers prioritize MySQL's platform choices, not Sun. As with Glassfish, their number one download platform is still Windows - and we're very committed to those developers, as well.
стало так:
Потому что в аббревиатуре LAMP "L" означает "Linux", а не "Looney". Выбор приоритетной платформы для MySQL определяет потребитель, а не Sun. Как и в случае с Glassfish, главной платформой для загрузки MySQL останется Windows. Со своей стороны мы также весьма заинтересованы в сотрудничестве с их разработчиками.
должно было быть так:
...пользвоатели определяют приоритетную платформу, а не Sun. Так Glassfish самая популярная платформа всё ещё Windows и мы так же преданны этим разработчикам...
Остаются ситуация, когда заголовки http и картинка весят существенно больше чем base64 и случай с узким каналом, когда всё выглядит некрасиво из-за недогрузившихся мелких графических элементов (аякс тут тоже тормозит - канал-то занят).
ну и + принудительный показ CAPTCHA (см. мой комментарий строчкой ниже)
ниже попробую разделить "советы" на классы так, как я их вижу:
I. не оптимизация, а правила здравого смысла, хорошего тона и культуры программирования. по большей части не имеют отношения непосредственно к php:
13 (сильно удивился что следующим пунктом не было ничего про switch), 1, 9, 10, 11, 17, 18, 23, 24, 28, 36, 39
II. Оптимизации очень низкого уровня, имеющие смысл разве что внутри очень длинных циклов и занимающие большой процент времени:
29 (то же самое что и 3), 40 (если это имеет смысл. например 90% времени уходит на эти функции и реализация на C будет как минимум разы эффективнее)
III. советы, ведущие к отказу от важных плюшек, предоставляемых языком в угоду несущественной оптимизации. Подобные прблемы должны быть проблемой транслятора, а не программиста (aka "с таким подходом вам бы на чистом C писать..."):
5, 6, 7, 8, 21, 22, 26, 27, 33 (хак!), 34, 35,
IV: резонно, но если выполнимо, то скорее относится к первому пункту.
2, 14, 19
V: действительно разумный подход к оптимизации - взваливание проблем на внешние решения, не требующие модификации кода:
15, 31
VI: пункты, вызвавшие у меня недоумение, непонимание, или смех. Если кто-то с ними согласен, пожалуйста, объясните что к чему.
16. зачем это вдруг???
30. это примерно то же, что и 29, только в профиль и на другом уровне. в принципе, резонно, но уж слишком очевидно чтобы упоминать в списке.
32 - первая половина - пункт V, вторая - то же что 31.
37. помимо повторного использования есть и другие мотивы разбиения методов!
38. есть побочные эффекты - метод разрастется до той степени, пока разбивать его не становится слишком сложно, потом рабиение откладывается на потом, и так он и останется толстым и сложным. Надо думать о таких вещах на этапе проектирования.
41. это техника, совершенно в стороне от остального.
42. никакого отношения к пхп не имеет. имел бы - был бы в разделе V.
правда это сомнительное преимущество, которое стоит использовать с крайней аккуратностью и точно зная почему это стало необходимо, ибо за довольно редкими и очевидными исключениями, если класс имплементирует сразу пачку интерфейсов, то это обычно сигнализирует о нарушении single responsibility principle ( http://en.wikipedia.org/wiki/Single_responsibility_principle )
про OSI - имхо правильный вопрос.
про "что происходит" - действительно, респект и уважуха. я прям представил как человек уточняет какая операционка, какой браузер, какой адрес (как минимум - какого уровня домен) и какой с той стороны сервер... и понеслась. через 20 минут доходим до ресолва днса, через несколько часов - до разбора заголовков http (если там http!)... к пятому дню собеседования можно распарсить собственно тело ответа... (-: жуть, просто триллер какой-то.
а как поменять значения двух переменных местами, не задействуя третью, нас в восьмом классе учиили. странный вопрос.
спорный, в общем, момент. я например не согласен. ибо если оборудование начнет глючить, то в первый год, пока оно на гарантии.
если имеют, то в чем проблема установки впритык к задней стенке? только экономия пары вентиляторов (-:
по русски они называются "разработчики _на_ PHP"
либо пишите так чтобы unset надобился максимально редко. Я вот сейчас чисто из интереса пересмотрел немалую часть кода - не нашел ни одного случая, где я не уверен в содержимом переменной и одновременно оно имеет значение.
в оригинале было
Because the L in LAMP stands for Linux, not Looney. Customers prioritize MySQL's platform choices, not Sun. As with Glassfish, their number one download platform is still Windows - and we're very committed to those developers, as well.
стало так:
Потому что в аббревиатуре LAMP "L" означает "Linux", а не "Looney". Выбор приоритетной платформы для MySQL определяет потребитель, а не Sun. Как и в случае с Glassfish, главной платформой для загрузки MySQL останется Windows. Со своей стороны мы также весьма заинтересованы в сотрудничестве с их разработчиками.
должно было быть так:
...пользвоатели определяют приоритетную платформу, а не Sun. Так Glassfish самая популярная платформа всё ещё Windows и мы так же преданны этим разработчикам...
будьте бдительны при чтении переводов (-: