Купил такой, за свои деньги аппарат отличный, за 2700 грех жаловаться, но всё же пожалуюсь =).
Недостатки:
1. Если сравнивать со встроенным плеером телевизора(LG47 LX6500), то картинка субъективно хуже(при детальном рассмотрении кажется что картинка в мелких точках).
2. Подтупливает во время путешествия по меню(задержки доходят до 5 секунд).
3. Если ставить паузу, перематывать видео, то может конкретно затупить, спасёт только перезагрузка.
4. Очень яркие диоды на передней панели, исправляется изолентой или пластелином =)
Вот, кстати, ORM в кохане мне очень нравилась, такого простого и интуитивно понятного конструктора запросов я больше нигде не видел. В Yii я почти каждый раз лезу в мануал, чтобы вспомнить, какие ключи в ассоциативном массиве задать, чтобы получился нужный запрос, в кохане через tail call всё очень легко и быстро.
В крупном проекте будет необходимо написать море велосипедов, причем фреймворк очень гибкий и с нечёткой идеологией, поэтому скорее всего эти велосипеды будут раскиданы по всему проекту, скорее всего, это превратится в свалку велосипедов. У Yii более чёткая философия разработки, в нем даже немного приходишь к DRY =)
Обойти никак, но решить проблему вполне возможно.
1. Всегда знайте состояние баланса и не делайте аякс запрос.
2. Выдавайте пользователю предложение «пополнить баланс», на котором он должен кликнуть да.
Второй вариант, на мой взгляд, на много предпочтительней. Для вывода сообщений могу порекомендовать Fallr(http://amatyr4n.com/codecanyon/fallr/), очень красивые сообщения/окошки получаются.
innodb_buffer_pool_size принято ставить в 80% допустимой памяти под MySQL.
По поводу кеша, вам надо понять как именно работает кеш. Вообще чем проще запросы и чем меньше в них участвует таблиц, тем больше шансов на то, что они попадут в кеш.
Всё разобрался в чём запара. Если не отказаться от (sticky > 0), то индекс не будет использоваться, потому что в данном случае он проверяем условие и ставит временный флаг 0 или 1 и сортирует именно по нему, а не по индексу, поэтому тут и не помогает составной индекс.
Нужно дополнительное поле, чтобы избавиться от данного условия и как сказал , порядок полей в индесе важен и необходимо чтобы он охватывал всё условие ORDER BY. В конкретном случае это будет `sticky`+`fliped`+`posted`, именно в данном порядке.
Совсем забыл count(*).
SELECT `id`, `Action`, `user_id`, count(*) FROM `table` GROUP BY `Action`, `user_id` LIMIT 20;
Вот так, а то GROUP BY будет недоволен.
Мне плазма не нравится по юзабили и я ей не пользуюсь. Много ест, не раз видел у коллег на двухядерниках плазма периодически вылетает в топе с 20-25% загрузки. Может на плазму и хватит атома, но далеко не факт, а если и хватит, то тратить большую часть ресурсов на DE, как то не логично.
