nSite

Перед запуском

А. Содержимое (контент) и Дизайн

1. Типографика и верстка
2. Проверьте правильность знаков препинания, особенно апострофы, кавычки и дефисы / тире
3. Проверьте заголовки, для которых вы могли использовать лигатуры (нет необходимости для кириллицы)
4. Проверьте отсутствие висячих строк для важных абзацев
5. Проверьте орфографию и грамматику
6. Непротиворечивость (целостность) информации
7. Заглавные буквы (особенно в заголовках)
8. Проверьте стиль (манеру) написания текстов
9. Повторяющиеся общие фразы (например, ссылки типа «Подробнее»)
10. Возможные вариации слов(с учетом конкретной аудитории сайта)
11. Маркированные списки (например, точки или запятые в конце каждого пункта)
12. Проверьте на абсолютные ссылки (убедитесь, что после переноса на «рабочий» сервер ссылки изменяться на реальные)
13. Убедитесь в отсутствии «рыбы» вместо реального текстового наполнения
14. Проверьте как выводятся на печать наиболее важные страницы
15. При редизайне существующего сайта, убедитесь, что важные существующие (старые) ссылки, перенаправляются на соответствующие новые URL-адреса, если ссылки изменялись
16. Проверьте все скрытые тексты (например, альтернативный текст для изображений, текст в функциях Javascript)

B. Соответствие стандартам

1. Доступность для людей с ограниченными возможностями
2. Проверьте валидность (Х)HTML разметки
3. Проверьте Javascript
4. Валидируйте CSS

C. Видимость в поисковых системах, SEO и метрики

1. Заголовки страниц очень важны: используйте только осмысленные заголовки с соответствующими ключевыми словами
2. Добавьте описания ( в теги meta) для важных страниц (как минимум)
3. Проверьте домен для канонических запросов (например, запрос по адресу site.com, www.site.com и www.site.com/index.html должны приводить к записи одного вида в адресной строке)
4. Убедитесь, что у вас семантически верная разметка (выделены заголовки, и проч.)
5. Проверьте наличие ключевых слов в тексте страниц
6. Проверьте форматирование URL-адресов (для пользователей и поисковых роботов)
7. Настройте Google Analytics, FeedBurner, и любые другие пакеты для измерения успеха проекта
8. Создайте XML Sitemap
9. Настройте Google Webmaster Console и инструменты Яндекс.Вебмастер

D. Функциональное тестирование

1. Проверьте работу всех обязательных функций сайта
2. Проверьте работу поиска (включая релевантность результатов)
3. Проверьте сайт в большинстве современных браузерах (IE, Firefox, Opera, Chrome т.д.), их различных версиях и операционных системах (Windows, OSX, Linux)
4. Проверьте отображение страниц при наиболее распространенных разрешениях экрана
5. Протестируйте все формы (например, обратная связь, добавление комментария в блог), в том числе анти-спам фильтры, шаблоны отправляемых писем и т.д.
6. Протестируйте сайт при выключенном Javascript, Flash и других плагинах
7. Проверьте, что все внешние ссылки являются действительными

E. Обеспечение безопасности (снижение рисков)

1. Настройте расписание резервного копирования, и проверьте результат восстановления из резервной копии.
2. Защитите все критически важные страницы (например, раздел администрирования сайта)
3. Используйте файл robots.txt в случае необходимости
4. Протестируйте безопасность и возможность взлома
5. Выключите вывод текстовых сообщений об ошибках
6. Проверьте размер доступного дискового пространства
7. Настройте уведомления по электронной почте и (или) SMS (например, для ошибок или сбоев сервера) для системы внутреннего и внешнего мониторинга
8. Проверьте производительность системы
9. Проведите нагрузочное тестирование
10. Проверьте оптимизацию изображений
11. Проверьте и осуществляйте кэширование где это необходимо
12. Проверьте общий размер страницы и время ее загрузки
13. Сожмите статические (Javascript / HTML / CSS) файлы
14. Оптимизируйте CSS: использование короткие пути для изображений; используйте наследование в CSS и т.д.
15. Проверьте правильность созданных индексов в таблицах БД
16. Проверьте настройки конфигурации на каждом уровне (Web-сервер, база данных, какие-либо другие программы, в том числе CMS)
17. Настройте ведение лог файлов на веб-сервере и сервере БД

F. Заключительные штрихи

1. Создайте пользовательские страницы для 404 и прочих видов ошибок
2. Создайте иконку для сайта (favicon)

После запуска

G. Маркетинг

1. Используйте социальный маркетинг: Twitter, LinkedIn, Digg, Facebook, StumbleUpon и т.д.
2. Добавьте сайт в поисковые системы
3. Запустите (контекстную) платную рекламу при необходимости
4. Проверьте информацию о сайте в результатах поисковой выдачи

H. Текущие проверки

1. Отслеживайте и реагируйте на обращения обратной связи (полученных напрямую, на сайтах социальных сетей и проч.)
2. Проверяйте аналитические данные на наличие возможных проблем и осуществляйте корректировки по мере необходимости
3. Обновляйте контент

Источник: http://habrahabr.ru/blogs/webdev/57702/

Проанализировав руководство пользователя по реализации моделей, контроллеров и видов, я пришёл к мнению, что реализация MVC в Zend Framework ближе к исходной архитектуре MVC, предложенной Trygve.

Вид никаким образом не контактирует с моделью, а все данные для отображения ему задаёт Контроллер.

Контроллер общается как с Видом, так и с Моделью. Он изменяет состояние Модели в соответствии с действиями пользователя и передаёт необходимые данные Виду.

Модель не зависит ни от Вида, ни от Контроллера и не имеет понятия об их реализации.

Отступление от архитектуры, предложенной Trygve, заключается в том, что Модель не информирует контроллер об изменениях своего состояния, т.к. логика веб-приложений подразумевает, что взаимодействие с моделью может инициироваться только контроллером.

В результате получаем следующу стратегию использования триады MVC.

Вид.
Содержит в себе только информацию для представления пользователю и простейшие правила её представления (если пользователь авторизован – вывести его имя, если не авторизован – вывести форму авторизации).

Контроллер.
Воспринимает данные от пользователя. Проводит валидацию данных от пользователя на предмет хакерских атак (валидация логичности данных находится в модели). Инициирует изменение свойств Модели в соответствии с действиями пользователя. Инициирует необходимый Вид. Передаёт сформированные Моделью данные в Вид. Запускает Вид на отображение.

Модель.
Выполняет всю бизнес-логику приложения. Занимается считыванием и изменением данных.

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

Изначально я предполагал, что это связано с тем архитектура MVC разрабатывалась для обычных приложений, а не для веб-сайтов. Однако оказалось, что мина замедленного действия была заложена непосредственно в момент теоретической разработки архитектуры.

Впервые архитектура MVC была описана Trygve Reenskaug, когда он работал над Smalltalk в Xerox PARC в 1979 году. Но непосредственное внедрение MVC в Smalltalk происходило уже без Trygve, и архитектура была реализована не совсем так, как предлагал Trygve.

В результате под термином MVC понимают два варианта реализации архитектуры Модель-Вид-Контроллер:

Версия Trygve

Модель является «сутью» системы и отвечает за непосредственные алгоритмы, расчёты и тому подобное внутреннее устройство системы.
Контроллер является связующим звеном между Видом и Моделью системы, посредством которого и существует возможность произвести разделение между ними. Контроллер получает данные от пользователя и передаёт их в Модель. Кроме того, он получает сообщения от модели, и передаёт их в Вид.
Вид отвечает за отображение информации, поступающей из системы или в систему.

Smalltalk-версия.

Модель обеспечивает доступ к данным и бизнес-логику приложения. Модель знает о всех существующих видах, но знает только то, что они есть и что у них есть метод Update, который вызывается при изменении состояния Модели.
Контроллер реагирует на действия пользователя, изменяя состояние Модели. Контроллер знает, какие методы нужно вызывать в Модели в случае определённых действий пользователя и какие Виды нужно инициировать в ответ на действия пользователя.
Вид по сигналу от Модели обновлят своё состояние. Вид знает только о Модели, он знает откуда и какие данные нужно взять, чтобы обеспечить их отображение пользователю.

Источники и дополнительные материалы по теме:

1. MVC XEROX PARC 1978-1979
2. Программирование приложений в Smalltalk-80: Как использовать Model-View-Controller (MVC) eng
3. Wikipedia
4. MVC для начинающих и для интернета в частности
5. Обобщённый Model-View-Controller
6. The Definitive Guide to symfony
7. Триада MVC в действии
8. Особенности реализации насыщенных пользовательских интерфейсов Веб-приложений (MVC в DHTML)
9. Ещё много полезных ссылок из Яндекса по правильному запросу

Выбор фреймворка начался в сентябре 2007 года. Периодически я возвращался к этой проблеме и только недавно принял-таки окончательное решение. Из всех возможных вариантов был выбран Zend Framework.

Вот список основных причин выбора именно Zend Framework:

1. Фреймворк написан на чистом PHP5, никакой совместимости с устаревшим PHP4 не предусмотрено.
2. Разработчиками фрэймворка является таже компания, которая занимается разработкой PHP.
3. MVC и ориентированность на паттерны программирования.
4. Наличие русской документации на большую часть функционала.
5. Описание стандарта кодирования как для самого фреймворка, так и для приложений на нём.
6. Поддержка этого фреймворка встроена в Zend Studio for Eclipse.
7. Благодаря громкому имени Zend – вскоре появится много людей, которые будут начинать изучение фреймворков именно с Zend Framework, что автоматически решит кадровую проблему.

Так что выбор фреймворка считаю законченным, теперь начинаю его плотное изучение.

Судя по всему (google & yandex) единственной современной разработкой на ниве поиска с учётом морфологии является phpMorphy. Раньше я использовал RiSearch, но сейчас он похоже почил в бозе. Поэтому буду пробовать новое решение.

Далее привожу полезную запись из блога «Ежовый угол».

Читать дальше »