Может кто-нибудь нашёл способ передавать поток с веб-камеры на сервер не в raw? Единственный был вариант пока покадрово сжимать в jpeg, и получить mjpeg — но это далеко не идеальный вариант.
Без грамотной работы с потоком видео, это чудо как веб-камера в сильверлайт пока всего-лишь игрушка…
Это несомненно помогает, но DQL поможет добиться большей производительности.
Опять же, как управлять временем жизни кеша при loadRelated()? Наверное, это возможно, указав общее время жизни кэша для таблицы (я правда не знаю как), но управление на уровне запросов мне кажется более надежным.
Ну а в целом — Вы правы в том, с точки зрения реализации бизнес-логики приложения, без DQL можно обойтись пожалуй всегда, ну или почти всегда.
Например, есть таблица постов (Posts), у каждого поста есть автор (Users), ну и у пользователя профиль (Profiles).
Если я буду перебирать $posts хранящий посты в цикле и забирать по relation информацию о профиле, это породит множество запросов — равное count($posts)*2, насколько я понимаю.
При использовании DQL, я могу сразу приджойнить нужные таблицы, и все данные заберу в один запрос.
Более того, этот один запрос я смогу закэшировать, и гибко управлять временем жизни кэша конкректно по этим данным, очищать кэш в случае необходимости так же удобно. И т.д. Поправьте меня, если я где-то вру.
Единственный способ делать это иначе, как я понимаю, RawSql API — но это далеко не самый удобный способ.
Я тут в связи с этим подумал… Разработчики хабра счастливые люди хотя бы по одной причине — они единственные, кто могут читать хабр на рабочем месте и при этом работать.
Можно обойтись звёздочками, но назначать им веса от -2 до +2. Т.е. третяя звёздочка — 0. И получим более грамотное вычисление по сумме всех оценок.
Плюс к этому, можно выдумать «относительный вес» суммы = число проголосовавших / максимальное число проголосовавших за одного пользователя.
Тогда, если у лидера 100 голосов и в сумме 150 баллов, то у новичка с пятёркой вес будет 2/20 = 0.2 что мотивирует активно учавствовать — получая большее число оценок.
На мой взгляд и то и другое не хорошо и не плохо. Разумно предупреждать пользователя что ссылка откроется в новом окне. Для этого рядом со ссылкой достаточно поставить простенькую иконку.
Да и не пытался. Именно поэтому я и писал ещё в первом комментарии — ответ о важности высшего образования сугубо индивидуален. Для «среднестатистичекого человека» — высшее образование, пожалуй, лучший путь. Отказываясь от высшего образования человек подразумевает свою «не-среднестатистичность». И это, несомненно, риск.
Без грамотной работы с потоком видео, это чудо как веб-камера в сильверлайт пока всего-лишь игрушка…
«You should always consider using a result cache if the data returned by the query does not need to be up-to-date at any time.»
Я сам дня 3 писал умный контроллер кеша, чтобы реализовать такой вот сброс. Неужели оно было напрасно? :)
Это несомненно помогает, но DQL поможет добиться большей производительности.
Опять же, как управлять временем жизни кеша при loadRelated()? Наверное, это возможно, указав общее время жизни кэша для таблицы (я правда не знаю как), но управление на уровне запросов мне кажется более надежным.
Ну а в целом — Вы правы в том, с точки зрения реализации бизнес-логики приложения, без DQL можно обойтись пожалуй всегда, ну или почти всегда.
Например, есть таблица постов (Posts), у каждого поста есть автор (Users), ну и у пользователя профиль (Profiles).
Если я буду перебирать $posts хранящий посты в цикле и забирать по relation информацию о профиле, это породит множество запросов — равное count($posts)*2, насколько я понимаю.
При использовании DQL, я могу сразу приджойнить нужные таблицы, и все данные заберу в один запрос.
Более того, этот один запрос я смогу закэшировать, и гибко управлять временем жизни кэша конкректно по этим данным, очищать кэш в случае необходимости так же удобно. И т.д. Поправьте меня, если я где-то вру.
Единственный способ делать это иначе, как я понимаю, RawSql API — но это далеко не самый удобный способ.
Плюс к этому, можно выдумать «относительный вес» суммы = число проголосовавших / максимальное число проголосовавших за одного пользователя.
Тогда, если у лидера 100 голосов и в сумме 150 баллов, то у новичка с пятёркой вес будет 2/20 = 0.2 что мотивирует активно учавствовать — получая большее число оценок.
Непонятно, зачем реализовывать какие-либо объекты бизнес-логики во фреймворке…
И у меня есть свой «карма чекер» с блэкджеком и шлюхами:
star.nn.ru/habrakarma.crx
Отличается только тем, что если пользователь авторизован, то он автоматически узнаёт %username% и ещё раз в минуту обновляет рейтинг.
Да, кстати, сначала забыл про API хабры и выпарсивал значения из html-кода страницы профиля…