Дмитрий Ковальский

Когда заливаете через CMS, файл по сути заливается во временный файл, а затем происходит move, который, в случае, если временный файл и целевой находятся на одном разделе файловой системы является атомарным (т.е. либо в один момент времени это старый файл, либо новый), либо, если происходит move между разделами - все равно происходит очень быстро.
В случае, когда вы заливаете по ftp - сначала удаляется старый файл, т.е. он становится недоступным, а затем уже начинает подливаться новый. В этот момент и происходит "лажа".
Выходов несколько:
- про первый (не сказал бы, что он очень простой, но все равно довольно эффективный), вам уже написал D' Normalization во втором пункте.
- второй - разливать файлы не по фтп, а, допустим, с помощью rsync из некоей директории, куда вы уже заливаете по ftp. То бишь - залили, проверили, что ничего больше заливать не надо - запустили на сервере rsync из этой директории в продакшн. rsync также копирует различающиеся файлы сначала во временный файл, а затем "мувит" на постоянное место.
- третий - может быть с косяками, использовать, например, opcache в PHP и выставить в параметрах opcache не трогать файл, пока он не состарится, например, на несколько секунд. Секунды определяются эмпирически, в зависимости от скорости вашей заливки.
- четвертый... а фиг знает, придумать можно много всего. Например, хранить файлы в SVN или GIT-репозитории, и по commit/push запускать post-hook, который, например, будет синхронизировать файлы тем же rsync или использовать какой-нибудь Jenkins... масса вариантов, главное не трогать самому файлы продакшна.

1. Location.href
2. Проверка строки регуляркой, например с помощью test

Вы не можете начать тестировать только потому, что Вы решили сначала написать код, а только потом его тестировать. Это неверно! Когда принимается решение писать код, нужно хотя бы где-то описать его задачу. TDD почти один в один взяли подход от математиков. У математиков тоже есть "Дано" - это аналог SetUp и "Нужно сделать" - это аналог вашего тестируемого кода, т.е. то что Вы реализуете и "Чтобы удовлетворяло условиям...." - Это очень похоже на Assert.

Откиньте Ваш код, как будто Вы его еще не написали. Прочитайте формулировки нескольких мат.задач. Посмотрите их стилистику. Как они оформляют мысли при изложении сути задачи. И попробуйте следовать точно также! То есть опишите вашу программерскую задачу до начала решения, как это делают математики.

/Offtop:
Рекомендую Вам выписать возможные случаи при добавлении элемента в список. К примеру:

Позитивные случаи:
* Добавить нормальный элемент;
и т.д. и т.п.

Негативные:
* Добавить Null;
* Добавить когда список уже переполнен - а такое возможно?;
* Добавить когда список, когда не доконца создан - а такое возможно?
и т.д. и т.п.

Не инициализированная переменная не обязана быть равна нулю.
Да по логике как-бы должна но не обязана.

Не инстанс контекста, а не самой БД - разные вещи!
Используй dependencyInjection и переиспользуй инстанс контекста БД в каждом последующем контроллере, подойдет NInject.
Где хостится сервер? IIS? Katana? Если IIS, то стоит помнить про то, что пул может убиваться, соответственно объекты не вечные, в отличие от self-hosted.

Чтобы минимизировать нагрузку и не завязываться на БД стоит продумать кэш в оперативной памяти, продумать сценарии рефреша страницы и подгрузки недавней истории. И, конечно же, корректно использовать entity для чтения (Не трэкать всё подряд) и записи (вставка пачками - bulkinsert по таймеру, если требуется ну очень много вставок).

function runTest(str) {
  var args = str.split('=');
  return (new Function('', 'return ' + args[0] + '===' + args[1] +';'))();
}

runTest('4 * 4 = 16');  //true

По-моему причина очевидно - одинарные скобки будут конфликтовать например с JS-ом.
а двойные открывающие врядли где используются. бывает такое что шаблонизаторы конфликтуют (например symfony2 и в angularJS). В этом случае к примеру энгуляр поддерживает настройку произвольных символов для шаблонизаторов.

А я вот не люблю документированный код. Если код написан хорошо и человек который читает его не тупой - всё понятно.

Да и как-то не красиво смотрится документированный код, ужс как не нравится)
Хотя это лично моё мнение.

stackoverflow.com/questions/9621792/convert-a-big-...

(chf / kzt) = (chf / rub) / (kzt / rub)