Создание и сопровождение сайтов
Прибавил к названию "Глава первая" так как, надеюсь, не последняя.
В ходе разработки продукта встречается много непонятных моментов, для решения которых используется Google или умные слова коллег, либо вчитывание в мануалы.
Хотелось бы помочь и сэкономить ваше время, если вдруг столкнётесь с такими же проблемами в будущем.
Решил сделать небольшой цикл из 2-3 статей на тему создания своего сайта. Здесь не будет кода, здесь будет много слов, мыслей, основанных на моём личном опыте. Рекомендую к прочтению всем.
Итак... Часть первая. Идея.
Наверное, мало из тех, кто использует Denwer, знают, что в его комплект входит Apache HTTP server benchmarking tool. Утилита для тестирования производительности сервера. Находится она по адресу WebServers\usr\local\apache\bin\ab.exe.
Данная утилита позволяет оценить как быстро формируется страница, которую вы запрашиваете. Если вы решили оптимизировать скрипт - вы можете быстро проверить результат оптимизации.
xdebug – это расширение для PHP, написанное одним из разработчиков языка PHP - Derick Rethans.
Первым делом нам необходимо установить xdebug. В качестве сервера будет выступать популярный Denwer.
В данный момент репозиторий для Open Real Estate пришлось разделить на три ветви:
Так же настроены роботы, которые обновляют демо-сайт, проставляют номера версий в релизе и др. Именно из-за роботов пришлось разделить всё на ветви. До этого делались попытки обновлять всё вручную (создавать архив релиза, ложить на демо-сайт через ftp). Но это большие расходы времени разработчика - код приходилось править в трех местах, поэтому решил потратить время один раз и перевести всё на полуавтоматические рельсы.
Собственно, эта заметка объясняет основные моменты использования репозитория с именованным ветвями - как, например, собрать правильное демо, применяя к ветке demo изменения из ветки default.
Это статья для начинающих, постараюсь объяснить непонятные моменты (подразумеваю, что базовые вещи всетаки уже известны) работы в HG.
Когда человек работает с репозиторием один - проблем, как правило, не возникает. Непонятки начинаются, когда с репозиторием работают 2 или более человек. Добавляет бардака "визуальный" софт - TortoiseHg, например. Люди привыкли тыкать одну кнопочку и чтобы "всё было хорошо". А тут куча кнопочек, еще и с невнятным переводом (если используется руссифицированная версия).
Поэтому для обучения категорически рекомендую начинать с работы в консоли.
Задача: сделать "реверсивный" пагинатор для Yii
Что имеется в виду под "реверсивным"? На примере новостей - это когда необходимо, чтобы самая первая новость всегда оставалась на первой странице, а остальные добавляемые новости уже размещались на 2, 3 и так далее страницах.
Картинка для понимания:
Зачем это нужно? Структура сайта не подвергается глобальным изменениям. Мы может открыть 10-ую страницу (поставить закладку, человек придет с поисковика) и там будет то, что ему нужно. При "обычном" подходе при каждом добавлении новости все смещается. И если человек придет на эту же 10-ую страницу - то совершенно не факт, что он найдет нужную информацию на этой странице (сам очень часто натыкаюсь на такое на различных форумах).
Рассмотрим реализацию операций CRUD (Create, Read, Update и Delete) для записей и пользователей на примере входящей в дистрибутив yii демонстрации блога.
Забегая вперёд, скажу, что пост будет изобиловать иллюстрациями. Они помогут вам избежать моих мучений при изучении функционала yii.
Суть проблемы: создаем форму с каптчей. Вводим символы с картинки правильно, но валидация не проходит (либо каптча не показывается вообще).
Небольшое замечание: в данной статье не рассматриваю банальные вещи - AJAX-валидацию, отсутствие GD - об этом много написано.
Рассмотрим несколько более сложные причины такого поведения.
В ходе своей профессиональной деятельности многократно приходилось сталкиваться с различными проектами на самых различных фреймворках, в том числе и на "велосипедных cms" (это когда каждый разработчик пишет свою собственную структуру проекта и имеет свой подход к написанию кода и используемым библиотекам).
Каждый программист видит код по-своему и, как результат, брожение в голове вызывает брожение в коде. Это было бы хорошо, если бы программист всю жизнь вел бы свой проект. Но получается так, что проект доделывается "хоть как-то уже наконец" и клиент с этим проектом уходит в "свободное плавание". Часто бывает, что проект переходит к другому программисту, у которого совершенно другое видение того, как должен выглядеть код. Он начинает вносить свои правки. После 3-4 таких программистов код превращается в сплошную непонятную кашу.