Я считаю, что сперва идет теоретическая оценка кандидата, а лишь в процессе испытательного времени практическая.
Сперва человек рассказывает о своих знаниях и возможностях, потом отвечает на вопросы:
- Почему так стоит делать, а вот так нет, что это такое, а это зачем нужно?
Лишь потом его втягивают в процесс работы, дают самостоятельно, в течении недели-двух, разработать свою версию какого-то основного модуля или части движка. Смотрят и оценивают не по пробелам и табуляциям, а по потоку мыслей программиста.
Если он показывает хороший результат - принимают в штат, если нет - до свидания.
Стилю всегда можно научить, подстроить под свои потребности, а вот поток мыслей никогда толком изменить не получится.
Пару раз проходил подобную схему и не был разочарован. Если есть потенциал, но нет знаний, то за неделю-две успеваешь подтянуться до нужного уровня.
Это мое личное мнение и если с ним кто-то не согласен, мне безразлично. (Добавление)
Хочу еще добавить:
Если меня с порога начнут заставлять писать какое-то тестовое задание, основанное на сложных механизмах, не обьяснив суть будущей работы, идеологии и прочего, я попросту уйду сразу.
Вы с шаблонизаторами хоть немного знакомы?
Там все просто, относительно. Магическим способом ничего само по себе не заменится, замену и производит шаблонизатор.
2 - Кто как защищает права на сайт если вобще защищаете Улыбка
Да как его можно защитить? Люди свою собственность от пиратства в интернете уберечь не могут - ту собственность, которая защищена авторским правом (музыка, фильмы и тд.).
Наверное, все, кто сталкивался с разработкой более или менее серьезных приложений, знают, что выбор формата хранения настроек скрипта или приложения — достаточно ответственное дело. Конфиги должны быть легко читаемыми, легко модифицируемыми, легко переносимыми, и так далее — список можно продолжать и продолжать.
Так как серверные PHP-скрипты выполняются, бывает, много раз в секунду, скорость загрузки конфигов — достаточно важный параметр. Хотя ему, порой, уделяется не очень много внимания. Давайте сравним различные варианты хранения настроек для PHP-скриптов с точки зрения скорости их работы. Ну и коснемся вкратце их удобства.
Итак, подопытные:
* INI-файлы
* PHP-скрипты
* XML-файлы
* Текстовые файлы
* Файлы с сериализованными данными
* Вне конкурса — PHP-скрипты с define'ами
* JSON-файлы NEW!
Чтобы никого не обидеть, перечисление в алфавитном порядке. Вариант хранения настроек в базе данных, кстати, не рассматривался. Уж слишком невыгодным он выглядит с точки зрения скорости доступа к настройкам.
Условия:
* Как можно быстрее загрузить настройки из файла
* Вернуть массив настроек в виде «ключ» => «значение»
* Конфигурационный файл содержит 10, 100 или 1000 конфигурационных параметров, представляющих собой короткие строки
* Конфигурация читается 1000 раз подряд, замеряется время работы в секундах
Понятно, что со вторым из условий тестирования можно поспорить. Мне этот вариант показался оптимальным для хранения настроек в памяти во время работы скрипта, но в некоторых случаях он таковым не является. И, кстати, этому условию не удовлетворяют PHP-скрипты с define'ами, из-за чего они и были помечены «вне конкурса».
Конфигурацию оборудования не привожу. Понятно, что скорость скриптов зависит от сервера, но в данном случае сравниваются скрипты, а не серверы.
Правда, необходимо сделать небольшое уточнение по поводу программного обеспечения сервера. Использовался реальный веб-сервер, в момент низкой загрузки. Соответственно, конфигурация сервера «боевая»: Linux Debian Lenny, много памяти и RAID1-массив жестких дисков. PHP серии 5.2.x (не самый последний, врочем) с eAccelerator'ом. На время тестов отключался Zend Optimizer, чтобы тесты были более «чистыми», что минимально повлияло на результаты. Тесты без eAccelerator тоже проводились, но, как ни странно, сильно на распределение сил это не повлияло. Причина, на мой взгляд, кроется в том, что eAccelerator настроен на дисковое кэширование опкодов PHP и на сравнение времени модификации файлов, что «съедает» определенное количество времени — хотя и приносит определенные бонусы.
Сначала маленькая оговорка. Во многих проектах конфигурационный файл не делает return, а просто определяет элементы глобального массива настроек. Это, с одной стороны, не совсем подходило под условия теста, а с другой стороны не совсем идеологически корректно в рамках борьбы против глобальных переменных. Поэтому для сравнения был использован предложенный вариант.
Обратите внимание на то, что этот вариант стабильно проигрывает INI-файлам, хоть и не очень значительно. Что ж, это компенсируется тем, что в настройках можно использовать PHP-выражения, что позволяет сделать конфиги максимально гибкими.
Недостаток очевидный: очень маленькая скорость работы, в несколько раз медленнее, чем другие варианты. Чтобы проверить, не слишком ли медленная PHP-часть этого кода, я попробовал сделать return сразу после загрузки XML-документа (то есть, фактически, конфигурационные параметры не возвращались). Это ускорило процесс всего приблизительно в два раза. Что подтвердило общий вывод.
Не знаю, право, зачем этот способ существует. Возможно, его придумали до того, как изобрели parse_ini_file, или до того, как узнали об этой функции. Не сильно быстрый, не сильно удобный способ.
Пример скрипта не привожу, потому что, как уже говорилось выше, результат в нужном виде вернуть достаточно сложно. Кроме этого, полученные результаты носят условный характер, поскольку второй раз define не переопределяет значение константы.
JSON ворвался в нашу жизнь. Его реализация в PHP позволила даже обогнать одного из лидеров, INI-файлы, но немного уступает встроенной сериализации PHP. Одно замечание: приведенный код возвращает не массив, а stdClass object.
Выводыp
Итак, самый быстрый способ чтения конфигов — это чтение сериализованных данных. Работает быстрее остальных, не тормозит на больших объемах данных. Правда, при этом конфигурационные файлы править вручную достаточно сложно.
Если Вы серьезный человек — то избегайте прямого чтения текстовых файлов, особенно с большими объемами. Вместо этого Вам вполне подойдут JSON-файлы или INI-файлы, тем более, что скрипты станут работать быстрее.
Если нужны гибкие настройки, с возможностью применения условий и переменных — то пишите конфигурационный файл на PHP. Работать будет медленнее предыдущих способов, но гибкость настроек в других способах недостижима.
Настройки в формате XML — самые медленные. Прежде, чем их использовать, подумайте хорошенько.
Искренне надеюсь, что define'ы никто не использует, поэтому оставляем их обсуждение вне выводов.
Итог
Итак, что же применить в реальном приложении? Само собой напрашивается применение комбинированного способа хранения настроек. Например, настройки хранятся в виде PHP-скрипта, результаты выполнения которого кэшируются в виде сериализованного массива. Использование такого подхода вместо чтения конфигурационного файла на PHP позволило получить следующие результаты:
Результаты: 0.018, 0.046, 0.317
Оптимально с точки зрения гибкости и скорости, на мой взгляд.
Еще раз повторю, что подобные ухищрения могут быть полезны только в приложениях, которые запускаются часто и, соответственно, часто читают конфигурационные файлы.
P.S. PHP-код в статье не самый хороший. Я писал его, преследуя две цели: краткость и скорость работы. Поэтому отсутствуют комментарии, длинные имена переменных и различные проверки. Кроме того, большая часть кода работает под PHP 4 и 5 без проблем (кроме, конечно, XML). Надеюсь, это не вызовет излишнего накала страстей. P.P.S. В сравнение добавлен код JSON. P.P.P.S. Добавлены небольшие ремарки по поводу железа и программного обеспечения. Без них, согласен с авторами комментариев, было как-то не так. (Добавление)
.
.
.
.
От меня: Думаю самое место для этой статьи тут. Если разместил не в том разделе, прошу переместить в нужный.
Вы сами такое придумали? Не ищем простых путей?
Я уверен, что можно найти более простой и удобный способ построения вашего дерева. (Добавление)
В вашем случае можно все-таки считывать отдельные ветки, те, которые необходимы:
1 - Создать маску всех возможных индексов и по ним уже выбирать из этой модели, но придется в цикле тыкать и проверять, есть ли данные по такому индексу.
2 - Снова будем тыкать в индексы, но теперь маску создаем прямо на лету, в цикле. Причем циклы будут довольно сложные и многоуровневые.
Лично я бы отказался об подобной модели, слишком сложно с ней работать.
Я не совсем понимаю, зачем такая секретность с id заказа, но можно сделать таким образом:
В момент генерации страницы со списком всех заказов:
- Создать md5 хеши всех id заказов
- В форму заказа поместить не id заказа, а его хеш
- При запросе изменения заказа заново создать хеши заказов и сравнить, какому заказу принадлежит хеш.
Все вроде просто, малость ресурсов будем тратить на двукратное создание хешей и повторную выбору всех id заказов.
Можно немного пофантазировать и хранить массив хешей в сессии, тогда повторно делать выборку и получать хеши не придется.