Pull to refresh
40
0
Михаил Горянский @Umkus

User

Send message
Может, хоть, со скриншота покажете? :)
Если речь о создании нескольких виртуальных хостов (server{}) и они не подхватываются, нужно смотреть error_log. Конфиги должны иметь расширение ".conf". Может проблема в настройках DNS/hosts. Уточните вопрос.
Ну да, " = " (точное совпадение) и " ^~ "(не пробовать другие регекспы после совпадения) более строгие локейшены, чем простые " * " (регистро зависимый регексп) и " ~* "(регистро независимый регексп).
Если у вас нет 50-ти location-ов в server-е, то всё должно быть относительно просто и логично.
А какие у вас были проблемы с конфигом из html5 boilerplate, если не секрет?
Tengine, кстати, интересный проект, панирую его потрогать, как время появится.
Я боялся, что это будет очередная вариация поста с заголовком «Настраиваем nginx» :) Но, карма вашего моментария говорит об обратном. Сегодня добавлю больше листингов и текста, спасибо.
У меня в ближайших планах универсальный редирект без .www в начале (кстати, уже появился реквест на гитхабе). Сам использую его для своих проектов (статичную версию).
Конечно. Некоторые моменты взяты из этого проекта.
Точно. Спасибо, забыл про них.
Ага, спасибо. Иначе Fatal error.
Объясните, почему в первом листинге все методы объявлены без method body? Это же не абстрактные методы и классы.
Подтверждаю. Та же история и в приложении для Android. Можно войти через Facebook, но потом всё равно попадаешь на стандартную форму регистрации.
Там были данные других людей.

Интересный вы человек. С одной стороны толкуете за сохранность чужих данных чуть ниже, в то же время самостоятельно выставляете на них ссылки для людей и роботов.

Если вам для баг-репорта нужен мой айдишник вконтакте, то он равен моему нику. Всё остальное вы уже сами нашли.
Мне не приятно видеть в результате выдачи на четвёртом месте чёткого пацанчика, которого я не знаю и которым я не являюсь.
Мне приятно, что вы ко мне не равнодушны и потрудились выяснить нашу с ним общую фамилию. Но мою фамилию легче узнать, просто поискав мой ник.
Уважаемый Яндекс. Мне не приятно видеть на запрос моего имени и фамилии вот такую картину.



Не делай из меня шута. Я не знаю этого человека.
Если представить себе простую функцию, требующую кеширования, то да, это кажется странным. Но если функция подтягивает значения извне, их обязательно нужно указывать дополнительно, для этого придуманы PAR_*. Т.е. использование PAR_* по крайней мере опционально.

Все имена кэшевых переменные хранятся в специальном многомерном массиве, что делает несколько затруднительным однозначное структурирование их по тегу, имени, сгенерированному по функции и параметрам этой функции, а так же неким дополнительным параметрам. Причём параметры функции и дополнительные параметры кэша нужно однозначно разделять, так как они могут пересечся по именам. По-этому я решил сделать использование кэшевых параметров обязательным и полностью отказаться от генерации по функции. Да, приходится писать болше. Но для одного проекта обычно достаточно объявить всего пару параметров, как в дефолтном конфиге — PAR_USER, PAR_ID, (...). В сочетании друг с другом и с тегами они формируют свою смысловую переменную, к примеру: айди продукта(TAG_PRODUCT + PAR_ID), айди коментария (TAG_COMMENT + PAR_ID), страница новостей (TAG_PAGE + PAR_TYPE). Параметры весьма абстрактны, как можно заметить. Из них удобно лепить.

Так же не стоит забывать, что для удаления конкретного элемента из кэша нам придётся всё же его каким-то образом полноценно идентифицировать. А если переменной изначально имя было дано как-то автоматически и не явно, внутри библиотеки, то объяснить кешу что конкретно мы хотим удалить будет весьма непросто.

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

Изначально я выдавал переменным кеша имена по имени вызываемой функции + переданным в неё параметрам, но вскоре перешёл на кешевые параметры PAR_*, так как они как-раз это и покрывают и дают больше контроля и ясности.
Меня, всё же терзает один момент. Было бы неплохо услышать сторонее мнение.
Если у переменной есть тег, и два параметра. А чуть далее по коду производится удаление по этому тегу и одному из этих параметров. Стоит ли удалять все значения, в которых участвует этот параметр, т.е. вышеописанную переменную? Или оставить это на программиста, мол, если ему нужно групповое удаление, пускай удаляет тегами, либо явно указывает остальные параметры?
Пример из example.php:
//Adding another var (note the new param)
CacheTag::SetFunction('f2');
CacheTag::SetTags(CacheTag::TAG_PRODUCT);
CacheTag::SetParam(CacheTag::PARAM_ID, 2);
CacheTag::SetParam(CacheTag::PARAM_USER, 7);
CacheTag::SetTimeout(0.1);
CacheTag::Fetch();

//Deleting vars tagged with Product and with param id = 2
CacheTag::SetTags(CacheTag::TAG_PRODUCT);
CacheTag::SetParam(CacheTag::PARAM_ID, 2);
CacheTag::Flush();

В текущей реализации кеш не будет обновлён.
По баг-репорту с CacheTag::Flush():
Дело в том, что все указанные в начале настройки (установки тегов, параметров, времени жизни) сбрасываются при вызове Fetch/Flush. Т.е. у вас Flush() сбрасывает пустоту. По идее у вас будет место в коде, где потребуется конкретно этот элемент кеша сбросить. Вот там-то вы и будете указывать конкретный тег и, возможно, параметры — те же самые, что вы указывали при добавлении. Т.е. тег с параметрами нужно указывать при вызове метода Flush(), так же как и Fetch().

Тайм-лимит подразумевался становиться дефолтовым, если только не передаётся число больше нуля. Но всё же добавил эту возможность.

По поводу лишнего replace:
Вот где собака зарыта. Я упустил вывод дебаговой информации для метода Replace(). Если бы я не допустил этой ошибки, было бы видно, что помимо прочих кешевых транзакций в началае работы скрипта берётся из кеша переменная _resetTags, а в конце она же заменяется/записывается. Не при каждом запросе чего-то из кеша, а в начале и в конце работы всего скрипта. Т.е. +2 к общему количеству запросов. Т.е. должно быть вот так:
__construct
Getting _resetTags
__get

Getting product
__get

Replacing _resetTags
__replace

My bad. Дело было к четырём утра, не уследил.

Как бы то нибыло, я только что исправил этот недочёт и повысли версию. Changelog на привычном месте.
Повысил версию. Ищите changelist в конце топика.

Information

Rating
Does not participate
Location
Одесса, Одесская обл., Украина
Date of birth
Registered
Activity