Возможность наследования описания методов в дочерних классах (при добавлении пустого docblock'а описания копируются из родительского класса\интерфейса)
Было бы хорошо если бы описания наследовались без необходимости добавлять пустые блоки.
А причем тут PHP? В статье C# встречается чаще чем PHP…
И вообще какой вывод должны сделать читатели прочитавшие статью? Что у вас все получилось?
Как то бесполезно…
С моей точки зрения это очень не правильный подход. При данном подходе все новые изменения сразу попадут на продакшн сервер. А если в этих изменениях будет регрессионные ошибки? Они сразу положат продакшн сервер… Для того что бы изменения не убили продакшн сервер, умные люди придумали вехи и версии, которые в репозитории будут отмечены тэгами. Продакшн сервер нужно обновлять только на определенный тэг, содержащий фиксированное число изменений проверенных тестировщиками. Таким образом вы сможете более менее гарантировать качество кода и сайта в целом. Описанный у вас способ подходит для деплоя на девелопмент сервер и в меньшей мере на стэйджинг сервер.
Google Closure Tools поможет структурировать код и скомпилировать его в один файл. К тому же на Google Closure Library можно написать свое MVC приложение, и для этого не нужен Backbone/Underscore/jQuery. Правда Google Closure сложный фреймворк для начинающих (или только знающих jQuery) программистов.
Я попытался описать абстрактный вариант, если мы говорим о memcached, то там валидация данных реализована с помощью cas token для варианта когда мы сначала читаем данные, изменяем их и потом пытаемся их записать. Для Вашего варианта можно использовать метод memcached::add который не позволит перезаписать уже существующие данные. В общем говоря memcached (не путать с memcache) предоставляет достаточно инструментов что бы разрулить конфликты, надо просто мануал почитывать, перед тем как писать костыли.
Что значит «уже не использую» и «эволюционировал»?
Временное хранилище это то место где Вы можете хранить данные не боясь их потерять. При этом временное хранилище должно предоставлять более быстрый доступ к данным нежели постоянное хранилище (иначе не было бы смысла его использовать). В случае потери данных во временном хранилище они должны быть получены из постоянного хранилища данных и положено во временное.
Положим что временное хранилище это кеш, а постоянное хранилище это база данных, тогда алгоритм работы прост:
как только нам понадобились данные, мы сначала ищем их в кеше, если они там есть, используем их, если нет то ищем их в базе данных, если искомые данные есть в базе данных, читаем их, сохраняем в кеш и продолжаем работу
Таким образом в первый раз мы будем искать данные и в кеше и в базе, но зато в последующие разы мы будем получать данные только из кеша.
Было бы хорошо если бы описания наследовались без необходимости добавлять пустые блоки.
И вообще какой вывод должны сделать читатели прочитавшие статью? Что у вас все получилось?
Как то бесполезно…
слонтоесть дельфин.Временное хранилище это то место где Вы можете хранить данные не боясь их потерять. При этом временное хранилище должно предоставлять более быстрый доступ к данным нежели постоянное хранилище (иначе не было бы смысла его использовать). В случае потери данных во временном хранилище они должны быть получены из постоянного хранилища данных и положено во временное.
Положим что временное хранилище это кеш, а постоянное хранилище это база данных, тогда алгоритм работы прост:
как только нам понадобились данные, мы сначала ищем их в кеше, если они там есть, используем их, если нет то ищем их в базе данных, если искомые данные есть в базе данных, читаем их, сохраняем в кеш и продолжаем работу
Таким образом в первый раз мы будем искать данные и в кеше и в базе, но зато в последующие разы мы будем получать данные только из кеша.