Он должен был вывести ошибку, а не тихо промолчать.
Это типичный говнокод:

catch(Exception $e)
{
   return false; // !
}

Так вроде как 560Ti лучше должна быть, чем просто 560

Безусловно

А Anisotropic говорил, что «мой Giraffe 560 ti уже не может тянуть комфортно все игры на максимальных».

Да, только вы написали в ветку где Useless_guy говорил «У меня 560 (без Ti) все игры тянет на максимуме.»

Насчет FPS ничего сказать не могу, но (визуально) игра работает гарантированно не хуже, как и у меня на конфиге GTX660 + i7 3770 (у меня выдает over 50FPS на сложных сценах, чего более чем достаточно)

Ну я даже не знаю что сказать по этому поводу. Может быть вы не отличаете 30 фпс от 60? Ну вот, например, бенчмарк:


Откуда у вас берутся «over 50FPS на сложных сценах» я не понимаю. И, да, 50 фпс для шутера это не «более чем достаточно», а минимум, с которым можно комфортно играть.

Во-первых, 560Ti != 560. Во-вторых, с каким разрешением она играет? В-третьих, отсутствие явных лагов еще не говорит о комфортной игре, может быть ваша знакомая играет с 30 фпс, чего явно не достаточно для комфортной игры в шутер.

И да, в предыдущем комменте вы говорили, что у вас 560 (без Ti), а это довольно существенное отличие в плане производительности

Metro 2033, Crisis Warhead

BF3 пробовали?

Попробуйте на своей видеокарте запустить BF3 на максимуме и сами поймете что значит «не может тянуть комфортно»

Я пожалуй дополню вопрос, чтобы было понятно к чему я веду. Допустим, деплоится новая фича содержащая в себе sql-миграцию (скажем, CREATE TABLE foo...) и код который без этой миграции не будет работать (SELECT… FROM foo). Понятно что если код задеплоится раньше чем sql-миграция или наоборот, то мы получим неработающее приложение на некоторое время. Собственно, меня интересует как происходит синхронизация миграций и кода при деплое (особенно при наличии множества бэкендов, время выполнения git pull на них может быть разным).

Из-за картинок слона прочитал название темы как SmartPostgres

А sql-миграциями как?

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

А зачем весь этот геморрой, если можно просто хранить статику на шаре? Да и вообще, мне казалось что уже давно устоялась практика не хранить какое-либо состояние на сервере приложений (статика, кэш и т.д идет на отдельные сервера). Автор упомянул, что они пробовали использовать подобный подход, но столкнулись с проблемами NFS, вот я и хотел узнать какого рода были проблемы.

Довольно странный подход с хранением статики на web1. Что будет если он ляжет? Да и бэкенды получаются неравнозначными (как вы, кстати, деплоите код?). Расскажите поподробнее чем не устроил подход с NFS?

Во-первых, в описании поведения MIN() об этом не сказано ни слова. То что MIN применительно к датам неявно использует какое-то преобразование автор сам догадался и оказался прав.
Во-вторых, нормальная СУБД в таком случае должна сообщить об ошибке, а не тихонько промолчать, вернув неверный результат.

P.S. Вообще MySQL в мире СУБД напоминает мне PHP в мире ЯП: куцый функционал, зачастую неявное поведение, но все им почему-то пользуются.

Тут просто тупой перебор каждого пикселя, это ахтунг. Если использовать numpy, то думаю скорость возрастет на порядок, а то и на два

А разве Idea не включает в себя все то, что есть в webstorm'е?

я думаю аппрув приложений от гугла там вне общей очереди и на особом рассмотрении.

Причем даже не в 1-ый или 2-ой, а в 3-ий

Я надеюсь вы и примеры этого сможете привести?

А где вы на скрине увидели 500-ую ошибку?