Присоединюсь к мнению Funcraft относительно названия переменных. Также добавлю, что namespace верхнего уровня с ником разработчика выглядит не сильно привлекательно. Но в остальном, код выглядит привлекательным.
В добавок ко всему вышесказанному (тоже из разряда оптимизации) — при статике на отдельном сервере, нет необходимости посылать все куки с основного сервера (значит заголовки запроса меньше, трафик меньше). Кроме того, если отрубить скрипты на статик-сервере, даже в случае дырки в аплоадере, файл злоумышленника ничего не сделает :)
То есть нужно:
1) где-то найти адекватную радужную таблицу
2) залить ее к себе на сервер
3) перед регистрацией проверять вхождение вводимого пароля (наверное все же его хеша?) в эту таблицу
То есть, если это таблица в БД — имеем дополнительный запрос. Если это файл — имеем поиск без индекса.
Конечно возможность «попробовать» разные вкусняшки — это круто, но использование стольких технологий для одной маломасштабируемой странички, выглядит довольно странно.
Поясните, про префикс подчеркивания, что здесь с вашей точки зрения не так? Символ подчеркивания для закрытых полей и методов — это требования zf coding standarts.
Согласен, поэтому и написал «например». Думаю в каждом конкретном случае разработчик сам определяет этот промежуток.
У нас, например, недавно я вводил новый функционал Class::Method, но на следующий день решил исправить на вызов Class::anotherMethod — сделал именно так, как описал выше. Хотя здесь функционал был новый и понятное дело, что никто еще не должен был успеть с ним поработать :)
Можно старый метод не удалять, а проксировать его на новый, до разлива на продакшн. А после разлива (например на сл. день), делать второй коммит с удалением уже старого проксирующего метода. Это обычно спасает в большинстве ситуаций.
Да, достаточно. И плодить файл не придется, один файл на всю папку system.
Другое дело, что по хорошему она должна быть на одном уровне с public_html, чтобы еще и таким способом исключить прямого обращения.
Интересно, много ли на хабре/среди разработчиков тех, кто не изучал её?
1) где-то найти адекватную радужную таблицу
2) залить ее к себе на сервер
3) перед регистрацией проверять вхождение вводимого пароля (наверное все же его хеша?) в эту таблицу
То есть, если это таблица в БД — имеем дополнительный запрос. Если это файл — имеем поиск без индекса.
Как-то так?
Поделитесь, какими методами вы это делаете?
У нас, например, недавно я вводил новый функционал Class::Method, но на следующий день решил исправить на вызов Class::anotherMethod — сделал именно так, как описал выше. Хотя здесь функционал был новый и понятное дело, что никто еще не должен был успеть с ним поработать :)
PS: привет коллегам из Баду)
Другое дело, что по хорошему она должна быть на одном уровне с public_html, чтобы еще и таким способом исключить прямого обращения.
Честно говоря разочарован. Думал здесь я найду реально что-то интересное, а не простой репост того, чего итак в сети уже полно в 100500 копиях.