Сергей Протько

что делает запрос? Там как я понимаю сейчас логика такая, что берутся 100К строк, это все дело идет домножается на 20К (ибо LEFT JOIN), затем вы группируете по id картинок (подозреваю что так вы проверяете случаи когда у игрушки нету картинки, ибо в любом случае результат счетчика будет либо 0 либо 1, если только id не уникален)... Логика довольно странная. Вам не кажется что можно намного проще?

Что касается условия `b`.`published` = 1, его можно писать в ON у JOIN, тогда проверка будет работать на меньших выборках и вообще вы будете иметь с меньшим количеством рядов. Но мне что-то подсказывает что у вас логика некорректная.

Зачем? Вот действительно, зачем? Есть вопросы по тому с чего начать - symfony.com и в документацию. Нужен перевод документации - так есть (правда слегка устаревшая). Просто оценить размеры сообщества - ну так есть групки на всяких linkedin. Есть куча конференций посвященных symfony.

Для всего остального есть stackoverflow.

где взять практику? пишите лабы, придумывайте себе интересные темы для курсовых... Делайте собственные проектики...

А для выводов вида "ничему не научат" - это от вас зависит. Обычно можно сдружиться с магистрантами/аспирантами, да и за все время учебы в универе парочка шарящих преподавателей вам должны попасться. Слишком смелые выводы для студента первого курса. Вот если у вас и на 3-ем курсе будут те же мысли, чтож... жаль. Значит такой университет.

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

возможно если вы сможете объяснить кому-то ( в том числе гуглу) что вы хотите, вы не только найдете ответ, но может еще и додумаетесь до него сами.

Вот я не понимаю, откуда столько подобных вопросов? Неужели вы не в состоянии сами сделать какие-то выводы, поискать подобные вопросы (появляются чуть ли не каждый день)... Неужели не понятно что чтобы что-то узнать нужно что-то сделать...

Придумайте себе проектик небольшой и сделайте. Он начала до конца. И опыт будет, и показать чего будет, и поймете для себя каких знаний вам особенно не хватает. Причем делайте по больше самостоятельно. Даже если у вас что-то выйдет не красиво, просто потом покажите кому-нибудь свое творение (на том же собеседовании) что бы вам хотя бы указали на ошибки.

Смелее надо быть, а то так и будете топтаться на месте.

Ну так откуда менеджеру асетов знать зависимости? Вы либо должны регистрировать ваш плагин так же как ассет через менеджер, либо jquery руками подключать. Асет менеджер просто добавляет в конец head секции (в случае POS_HEAD) скрипты.

Вообще асет менеджер в yii штука гнилая и я считаю что она только добавляет гемороя а не помогает в чем-то. Потом ищи сыщи все эти registerCoreScript по туче модулей/виджетов/компонентов/экстеншенов.... При деплое неудобно, все на лету происходит, если у вас php из апача работает и из какого-нибудь пользователя аля www-data, то могут быть проблемы с правами...

Ваш вариант мне нравится меньше нежели реализация QueryBuilder в Doctrine2. А еще там есть DQL, тоже иногда удобно. Да и меня в нем лично все устраивает.

1) каким таким движком?
2) Что? имеется в виду изменения оформления в зависимости от контекста? Это ж вроде как противоречит философии bem, не?
3) нет не ужас. Стили должны быть независимыми. Если у вас во всех блоках текст должен быть красным - так и сделайте его красным при помощи какого-то общего класса, например txt-red или еще как более очевидно назвать (text-hightlight, text-warning) в зависимости от целей преследуемых.

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

вот почитайте доку в MSDN

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

Функция должна вернуть какой-то результат, причем определенного типа. Что вы будете делать в случае ошибки? А как уведомить разработчика что именно пошло не так?

Для этого ввели механизм исключений. Если в функции что-то идет не так, можно сформировать исключение со всей имеющейся по ошибке информации и выбросить его.

Если вы используете конструкцию try/catch в использующем эту функцию коде, то вместо крэша у вас вызовется один из обработчиков catch (вы можете спускаться по иерархии классов, задавая различное поведение для разного рода ошибок), возможно произведете какие-то уточнения в данных, переспросите пользователя и программа продолжит работу совершенно нормально.

нативная технология всегда лучше. Хотя попробовать (именно попробовать) стоит.

мне кажется что java далеко не лучший выбор для имплементации штук с такими объемами вычислений.

так вы ж метод не вызвали...

print a.school_address()

у yii нету разделения на окружения по сути. Там есть только внутренняя переменная YII_DEBUG которая влияет по умолчанию только на компоненты фреймворка. Настройки логирования и разделение конфигов по окружениям - это ваша забота, вы можете сделать это дело как на основе проверки константы YII_DEBUG, так и своими силами (разные конфиги для разных окружений, кастыли из array_merge и т.д).

Я для своих проектов использую тот же подход что и в symfony. Конфиги хранятся в yml, общие части вынесены в config.yml, входная точка загружает config_prod или config_dev в зависимости от окружения требуемого. Дальше уже бутстрапер сам компилит конфиг, или же забирает его из кэша, ну и все.

По поводу консольных команд - логичнее их запускать в dev окружении (скажем что бы нивелировалось влияние кеширования каких-то данных или что там у вас может отличаться в настройках). Вы можете так же добавить в точку входа в консольное приложение какой-нибудь дополнительный аргумент аля --debug или --no-debug что бы переключать окружение.

с localStorage это реализовано на более низком уровне.

А так только через getter/setter-ы только для существующих свойств. Да и не вижу смысла в этом. Возможно вам будет удобнее описать конечную задачу которую вы хотите решить при помощи "магии".

эм... что?

конкатенация стилей/скриптов и их последующая минификация - это нормальная практика. Для этого ненужно никаких стандартов. Делайте хоть на лету, хоть собирайте один раз при деплое (что было бы логично) а еще лучше сразу же ложите рядом уже сжатый в gzip вариант ваших скомпиленых файлов. Опять же смысла сделать из двух файлов один я не вижу как минимум по следующей причине: стили должны загрузиться раньше скриптов. Во всяком случае в большинстве случаев. Загрузка скриптов не должна блокировать загрузку страницы.

Что касается SPDY - то тут вы вообще ни капельки не попали. Там профит в том что используется одно tcp-соединение с сервером и мультиплексирование данных. Это позволяет снизить нагрузку на сервер, не тратить время на подключение к серверу по новой для загрузки следующих файлов и т.д. По сути при использовании этого протокола конкатенация файлов стилей и скриптов не должна приносить существенного профита, ибо соединение все равно будет одно и то же.

p.s. приведенная вами статья не даром находится в хабе "ненормальное программирование".