neyronius

Да мне кажется не в пороге вхождения дело, я знаком с Zend`ом и c Yii, и вот честно не понимаю зачем нужен зенд. Поясню, даже отлично зная как делается то или иное действие в этих фреймворках, как правило на Yii все делается намного быстрее, для многих типовых действии в yii намного больше готовых решений. Но мы все помним, что зенд для сложных проектов, где все не совсем стандартно, и что то вроде Yii не катит. Здесь у меня возникает вопрос, а не проще тогда вообще на чистом PHP писать? В большом, сложном, нестандартном проекте, скорее всего работают достаточно неплохие программисты и встает вопрос, зачем им вообще засорять свой код Zend`ом, ну разве только парой библиотек из него, но согласитесь, использовать библиотеку из фреймворка, это не использовать фреймворк. Я кстати часто натыкаюсь на такое мнение, что Zend не фреймофрк, а очень хорошая сборка библиотек.

Мне показалось эффективным использования 80%-90% практики на 10%-20% теории.

Никогда не тратить время на чтение или изучение информации, для которой не было проведено сжатие или намеренно раздутой, например книги (за исключением серьезных трудов) или длинные видеосюжеты.
Они были эффективны во времена дефицита информации и превратились в настоящих лангольеров — пожирателей времени во времена ее переизбытка.

Смотрите профильные статьи уважаемых профессионалов и сразу применяйте их на практике.

Вообще техника предоставления информации и обучения очень важна. Используйте эффективные механизмы.

Например для изучения теории большниству людей сертификация подойдет больше чем самообучение — так как заставляет держаться во временных рамках и заставляет человека двигаться в обучении.

Относитесь более скептически к разговорам о том, что обучение человеком-преподавателем ничего не заменит. При грамотном подходе автоматические курсы часто эффективнее и быстрее, чем обучение человеком.

Бегите немедленно от любых лекций, курсов, обучающих материалов, если слушая первые 5 минут — вы понимаете, что тратите время впустую.

Мне кажется этого достаточно чтобы эффективно обучаться и поиск каких сверхъестственных методик, которые могут научить супербыстро и суперкачественно совершенно ни к чему.

По своему опыту, скорость обучения прямо пропорциональна личной мотивации. У меня — это 90% успеха.

А почему нет?
Если производительности достаточно и с охлаждением нормально — хороший вариант. Низкое энергопотребление, встроенный UPS.

PDO из коробки малоюзабелен и неудобен: не считает время и статистику запросов, не поддерживает ленивого соедиения, пула соединений, транзакций, нормальных плейсхолдеров. потому обертку писать стоит в 90% случаев.

А вот написать обертку, позволяющую прозрачно для кода менять СУБД, у вас не получится. В MySQL есть LIMIT, INSERT ON DUPLIATE KEY UPDATE и куча вещей, которых нет в других БД. Что вы с ними делать будете, чтобы заставить работать в оракле?

В большинстве случаев, нет. Есть doctrine и куча других готовых библиотек.

У нас все веб разработчики включая меня, сидят на убунте. Веб сервера которые мы используем также на убунте. У убуны довольно большое комьюнити, что очень удобно. Можно еще на дебиан посмотреть, тем более что на хостингах дебиан тоже часто бывает.

Я бы посоветовал вам развивать память и воображение. У самого была подобная проблема: трудно было уместить в голове полную картину, приходилось что-то рисовать и записывать. При этом, всегда терялась какая-то часть информации. Потом решил отказаться от любых инструментов и держать все в голове. Сначало было сложновато, но потом мозг привык и сейчас я могу создавать в голове подробные трехмерные схемы взаимодействий, крутить их как угодно и запоминать на долгое время :) Инструменты — это, конечно, хорошо, но собственный мозг лучше )

Зачем orm если sql намного гибче и удобней?

Стоят ли у вас индексы на таблицах?
Sphinx это поисковой движок, при коротком времени обновления индекса у вас будет свежая инфа в индексе.

Но мне кажется вы что-то делаете не так:
Зачем собственно выводить данные из индекс sphinx, а не напрямую из бд? Если проблема только в скорости значит у вас проблемы с запросами. Необходимо проанализировать запросы через EXPALIN и проверить наличие и использование индексов.

Так как CodeIgniter очень в подвешенном состоянии, то я бы рекомендовал Laravel — laravel.com/ это свежий, очень структурированный, понятный и с хорошей документацией фрэймворк, лучшее пока что я видел.

Сам по себе ORM — банальная ничем не примечательная хрень. Это уже много раз делали в других фреймворках (например, RoR, Java) и описано в книгах про паттерны. Берешь, делаешь как в Руби и пользуешься хоть до посинения.

Пример с User::create() неудачный: у реальных объектов бывает по 20 свойств и фукнция с 20 аргументами будет выглядеть дико. Функции с подчеркиванием в начале — уродливые. Передавать __CLASS__ и подобные магические методы тоже не очень как-то.

Один из сложных моментов в проектировании ORM — оптимальная организация взаимодействия с хранилищем. Например, этот ваш пример:

> foreach(UsersGroup::getPremiumMembers()->orderBy('registration_date')->limit(10) as $user){
> echo $user->getCountry()->getCurrency()->getCode()."
";

Сколько запросов сгенерирует при использовании SQL-хранилища? По идее, должно быть в районе 3-4, причем данные справочников еще бы и стоило кешировать (ибо валюты у стран меняются очень редко) и обойтись 1-2 запросами. Если у вас в цикле для каждого юзера делается запрос — хлам это, а не ORM.

Второй момент — оверхед. Вы когда-нибудь считали, какая разница по времени выполнения запроса через ваш ORM и через mysqli_query() (включая время на загрузку и инициализацию классов ORM)? Посчитайте, наверняка у вас после этого вообще пропадет желание использовать ORMы.

Третий момент — масштабирование. Можно ли, к примеру, сделав огромный сайт на вашем ORM, не переписывая кода, реализовать расшардивание базы на 100 серверов (чтобы справиться с нагрузкой). Можно ли на нем делать проекты уровня хотя бы игр для соцсетей или вконтакта?

Если у вас есть решение хотя бы некоторых из описанных 3 проблем проектирования ORM, ваша статья на тему архитектурных решений и программистских хитростей была бы крайне интересна. Если нет решения — то такой орм любой школьник может сделать, как я уже сказал, прочтя мануал к рубионрейлс.

Могу поделиться своим опытом в этом плане, возможно это окажется вам полезно. Мы делали REST API для мобильных клентов (iOS, Android) и допустили ужасную ошибку, сделав в первой версии приложения с API, изначально предназначенным для AJAX. Как оказалось, особенность внешних клиентов заключается в том, что мы не имеем над ними никакого контроля: однажды запущенное приложение будет посылать такие и только такие запросы, которые в него заложены, а с размножением версий ситуация только осложняется. Поэтому API вынуждено оставаться совместимым, что оказалось очень нежелательно и некрасиво при внесении изменений в логику и структуру сервиса. Дальше — хуже. Поскольку вызовы API были сделаны «гибкими», по принципу «мало команд — больше настроек», во многие заранее на стороне клиента передавались параметры выдачи (фильтры, количество элементов на странице и т.д.). После деплоя приложений этими параметрами стало невозможно управлять. Сейчас, в новой версии, эти ошибки учтены с помощью дополнительной прослойки, реализующей принцип «много команд, минимум настроек»: для каждой версии API (отдельно для сайта и версий внешних клиентов) существуют разные обёртки, с подстановкой заранее подготовленных фильтров, проверок и формата выдачи. Это позволяет контролировать менять логику поведения внешних клиентов на сервере, огранизовать серсионность и совместимость.

monoray.ru/products/51-open-business-card

не плохая на фреймворке Yii, админка достаточно простая

Посмотри мой велосипед, просто и много дополнительных модулей + своя IDE есть. Более 100 дизайнов, поддержка скинов в админке и т.д. Форум поддержки в наличии.

Возможно, TiddlyWiki пойдёт.