кстати говоря споры о языках в стиле "у моего яйца круче вечером, а у твоего - утром" лишены смысла (хуже - они не лишены смысла для тех новичков, кто этого не понимает).
А вот грамотное сравнение "давайте попробуем сделать вот такую-то фунциональность на этом, на этом и на этом языке..." совсем не лишено смысла - как минимум оно развёртывает некоторые возможности языка (при этом автор сравнения должен уметь их использовать на всех сравниваемых языках, конечно же), позволяя в голове откладывать "хм.. если будет задача сделать такое - надо будет подумать что вот тут это проще делается..." даже без собственного опыта.
Даже появилась идея создания проекта, вроде списка всех возможных задач в программировании (начиная от работы с массивами, заканчивая реализацией MVC паттерна и так далее... =)), тем самым отпозиционируя все языки на четкие области применения... :) Может быть, такой проект уже существует?
Когда меня спрашивают - на чём я пишу - я обычно отвожу глаза и говорю что это дурацкий вопрос.. ведь пишу я вроде как на всем. Но тут есть один момент. Рельсы, питон (django) и PHP - область их применения захлёстывает веб-разработку целиком. На рельсах и django писать проще чем на PHP. Но есть ещё дурацкая маркетинговая сила. Если разрабатывать большой проект - работодатель зачастую обеспокоен "а смогу ли я потом легко и дешево найти разработчиков?". В России популярность PHP не вызывает сомнений. Вот и приходится писать на PHP и маньячно оптимизировать то, что можно было бы просто написать с использованием другого языка.
Интересно иметь в голове такой факт - что на Си можно написать ВСЁ. Один раз нужно было написать простейший http-сервер, отдающий циферки (знакомым с торрентом - привет!). До красноты в глазах выдавливал из получившегося приложения скорость. Дрался с GIL в Питоне (молодой был, глупый ;)). В итоге приложение получилось ненормально быстрым (по сравнению с традиционными серверами) но очень сложным (и, как следствие, хрупким). Как раз после прочтения книги и пришла в голову мысль что я не пишу суперпрогу, а банально веду войну с Питоном. Переписали всё на DigitalMars D, прирост в скорости +400% и отчетливо простая внутренняя архитектура.. :)
В любом случае книги книгами - а голова важнее. А вот все вместе - это лучший набор ;)
в том то и дело - что я ошибся не в указании банковского счета (что действительно испортило бы мне настроение) - а всего на всего в названиях программ - и к таким замечаниям вроде "ох! это вопиющая безграмотность!" отношусь с должным сарказмом =). Zend Platform, так Zend Platform, каюсь, перепутал, подправлю статью.
ZendOptimizer обладает этой функциональностью. Так? Лишь бы ляпнуть, честное слово.
unix-сокеты... а вы потестите, потестите... скорость установки соединения, нагрузка на ядро при большом кол-ве соединений, использование буфера (не перемешивающегося с буфером tcp)... вот и будет вам "чуть чуть" ;)
ну у них в доках сказано "ни за что не включайте оптимизацию - глючит!" =)) Сам пару часов затылок чесал при виде разваливающегося проекта ;). Но без оптимизации - как часы.
eAccelerator мне совсем не нра из-за непрозрачной архитектуры (лениво в исходниках копаться и рассматривать что же они там творят и API глядеть для PHP).. а вот xcache - растёт. Последний раз когда глядел на него - он в альфе был. Сейчас вроде как 1.2 уже. Надо ставить и пробовать. Да =).
я конечно не знаю - может вам заняться нечем вот вы и мусолите одно и тоже по десять раз... я лично был свидетелем проектов 12 девелоперов * 6 месяцев, 80% которых были описаны изначально. И что вы мне доказываете в чем сила TDD - когда я и сам это прекрасно знаю и ни в коем случае не ругаюсь на экстремальное программирование - даже наоборот =).
Была один раз задача - написать торрент-трекер, так если бы мы более 60% времени изначально не потратили на описание внутренней архитектуры и поиск проблем в зародыше - потратили бы уйму человеко-часов (слава богу, не своих) на их нахождение в процессе работы.
TDD и отсутствие проектирования архитектуры не имеют между собой ничего общего. Всегда нужно сначала думать а потом делать, иначе ничего хорошего не выйдет. Практики TDD же позволяют сначала разрабатывать тесты, а уж потом писать для них код.
например. обход дерева файлов при помощи виртуального курсора будет кушать памяти гораздо меньше чем с рекурсией. Сравню и покажу пример на досуге. Увидите :).
кто-то находит полезным, кто-то вредным. Мнение субъективно по своей сути =).
Многое я писал для того чтобы наоборот не пытались оптимизировать там, где ничего не получится (передача по ссылкам). Заменять обычные объекты статичными (или по крайней мере сильно стараться это делать) - глупо. Я писал о том, что просто забывать о статических классах не стоит. По поводу комментариев - опять же слышал несколько мнений в виде "файлы должны быть маааленькими и комментарии тормозят парсинг" (абсурд, но не все это понимают). Рекурсии полезны, но если можно обойтись без них - лучше без них. Тем более учитывая что рекурсия без проверки вложенности может когда-нибудь вызвать segfault при перегрузке стека php. Sprintf в строках я дал опять-таки для примера, чтобы просто не забывали о его существовании ;).
Поймите - это не howto, это просто мысли в слух. Для каждого конкретного случая можно вспомнить что то из этой статьи а потом подумать "стоит это тут использовать или нет". Делать бездумно - глупо впринципе.
1. shmop явно неудобен. На shm_* посмотрю, интересное замечание, спасибо
2. чтобы всё было подконтролем, в независимости от того что решат сделать дефолтным в следующей поставке php ;)
3. PDO_* работает конечно медленнее чем mysql, т.к. он является для него оберткой. С транзакциями в MySQL при постоянных подключениях есть одни огромные грабли - нужно в конце скрипта не забывать транзакции откатывать или коммитить. Потому что сам он этого делать уже не будет (т.к. коннект не рвётся)
5. Я в общем-то и написал "не пытайтесь ничего скоприовать по ссылке пока это действительно не будет необходимым" ;).
6. Просто на моих глазах было много программистов - которым уж очень нужно было всегда создавать экземпляры классов... Даже для factory делали.
А вот грамотное сравнение "давайте попробуем сделать вот такую-то фунциональность на этом, на этом и на этом языке..." совсем не лишено смысла - как минимум оно развёртывает некоторые возможности языка (при этом автор сравнения должен уметь их использовать на всех сравниваемых языках, конечно же), позволяя в голове откладывать "хм.. если будет задача сделать такое - надо будет подумать что вот тут это проще делается..." даже без собственного опыта.
Даже появилась идея создания проекта, вроде списка всех возможных задач в программировании (начиная от работы с массивами, заканчивая реализацией MVC паттерна и так далее... =)), тем самым отпозиционируя все языки на четкие области применения... :) Может быть, такой проект уже существует?
да что нагородили то
лучше переписать все это на
Интересно иметь в голове такой факт - что на Си можно написать ВСЁ. Один раз нужно было написать простейший http-сервер, отдающий циферки (знакомым с торрентом - привет!). До красноты в глазах выдавливал из получившегося приложения скорость. Дрался с GIL в Питоне (молодой был, глупый ;)). В итоге приложение получилось ненормально быстрым (по сравнению с традиционными серверами) но очень сложным (и, как следствие, хрупким). Как раз после прочтения книги и пришла в голову мысль что я не пишу суперпрогу, а банально веду войну с Питоном. Переписали всё на DigitalMars D, прирост в скорости +400% и отчетливо простая внутренняя архитектура.. :)
В любом случае книги книгами - а голова важнее. А вот все вместе - это лучший набор ;)
unix-сокеты... а вы потестите, потестите... скорость установки соединения, нагрузка на ядро при большом кол-ве соединений, использование буфера (не перемешивающегося с буфером tcp)... вот и будет вам "чуть чуть" ;)
eAccelerator мне совсем не нра из-за непрозрачной архитектуры (лениво в исходниках копаться и рассматривать что же они там творят и API глядеть для PHP).. а вот xcache - растёт. Последний раз когда глядел на него - он в альфе был. Сейчас вроде как 1.2 уже. Надо ставить и пробовать. Да =).
за xcache http://www.dailymotion.com/blog/video/37… - далеко не всегда он аутсайдер. Да и вообще разброс по скорости там не настолько критичен =).
Разве что xcache надо пробовать. Это да.
Была один раз задача - написать торрент-трекер, так если бы мы более 60% времени изначально не потратили на описание внутренней архитектуры и поиск проблем в зародыше - потратили бы уйму человеко-часов (слава богу, не своих) на их нахождение в процессе работы.
Не путайте молодёжь =)
Многое я писал для того чтобы наоборот не пытались оптимизировать там, где ничего не получится (передача по ссылкам). Заменять обычные объекты статичными (или по крайней мере сильно стараться это делать) - глупо. Я писал о том, что просто забывать о статических классах не стоит. По поводу комментариев - опять же слышал несколько мнений в виде "файлы должны быть маааленькими и комментарии тормозят парсинг" (абсурд, но не все это понимают). Рекурсии полезны, но если можно обойтись без них - лучше без них. Тем более учитывая что рекурсия без проверки вложенности может когда-нибудь вызвать segfault при перегрузке стека php. Sprintf в строках я дал опять-таки для примера, чтобы просто не забывали о его существовании ;).
Поймите - это не howto, это просто мысли в слух. Для каждого конкретного случая можно вспомнить что то из этой статьи а потом подумать "стоит это тут использовать или нет". Делать бездумно - глупо впринципе.
2. чтобы всё было подконтролем, в независимости от того что решат сделать дефолтным в следующей поставке php ;)
3. PDO_* работает конечно медленнее чем mysql, т.к. он является для него оберткой. С транзакциями в MySQL при постоянных подключениях есть одни огромные грабли - нужно в конце скрипта не забывать транзакции откатывать или коммитить. Потому что сам он этого делать уже не будет (т.к. коннект не рвётся)
5. Я в общем-то и написал "не пытайтесь ничего скоприовать по ссылке пока это действительно не будет необходимым" ;).
6. Просто на моих глазах было много программистов - которым уж очень нужно было всегда создавать экземпляры классов... Даже для factory делали.