1. Составление технического задания (далее ТЗ)
   • либо готовое задание от заказчика
   • либо интервью с ним + пометки и самостоятельное  составление ТЗ [лист бумаги, карандаш]
2. Анализ сайтов конкурентов и с похожей тематикой
   1. просмотреть 5-6 сайтов, зафиксировать полностью их функционал [Xmind]
   2. определить, что важно и интересно, зафиксировать [бумага+карандаш или просто память]
3. Сделать прототип сайта (мокап, вайрфрейм и т. д.), для заказчика я употребляю термин «чертеж» [Balsamiq Mockup, Mockingbird - в ней прототип можно связать ссылками и отправить заказчику почти как рабочий сайт]
   1. можно начать с ключевой страницы сайта (главная, страница товара и т. д.)
   2. создать, не ленясь, прототипы всех страниц, всплывающих блоков без исключения
4. Перевести прототип в html+css и аккуратно показать заказчику* (иногда это куда эффектнее и эффективнее, чем первым показывать макет из фотошопа) [текстовый редактор+Firebug]

Продолжение следует…

Столкнувшись впервые с MVC-моделью в разработке веб-приложений (Ruby On Rails), я не сразу понял идею. Вроде «что-то где-то отделено от другого и это лучше чем все в кучу». Поняв тогда, что не смогу осилить этот фреймворк – снова вернулся к MODx и PHP . Спустя пару лет услышал о symfony и твердо решил изучить ее, раз уж среда с моделью MVC существует и для родного бюджетного PHP.

Определение из Википедии:

Model-view-controller (MVC, «Модель-представление-поведение», «Модель-представление-контроллер») — архитектура программного обеспечения, в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента, так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты.

Итак, я стал понимать что модель – вроде как «модель данных» для БД, вид – просто HTML-шаблон с указанием мест вывода данных, а контроллер – связующее между ними звено. То есть:

1. Пользователь запрашивает некий url
2. Вид, соответствующий этому url, обращается к контроллеру
3. Контроллер обрабатывает запрос и получает данные из модели (?) и, возможно, обрабатывает уже полученные данные
4. Контроллер отсылает данные в вид
5. Пользователь видит шаблон с данными

Вроде как, все понятно – можно изобразить работу этой модели следующей схемой:

Схема, иллюстрирующая модель в Википедии выглядит же вот как:

Если прочитать оттуда же следующее утверждение:

Важно отметить, что как представление, так и поведение зависят от модели. Однако модель не зависит ни от представления, ни от поведения. Это одно из ключевых достоинств подобного разделения.

то, например, у меня происходит легкий диссонанс. Вроде как, «модель не зависит ни от вида, ни от контроллера «. На схеме от Википедии видны «прямая связь» и направление от вида к модели, то есть вид напрямую влияет (а может передает данные) модели? То ли я неправильно читаю схему, то ли в определении от Википедии закралась ошибка, то ли неизвестный третий фактор.

Не смотря на все это, я все-таки начал работу и построил небольшое приложение на symfony. Я усиленно пользовался видео-уроками и читал блоги на эту тему. Сейчас я не помню на 100%, но, вроде бы, вся бизнес-логика (обработка данных, перекрестный сбор их и прочее) там содержалась в контроллерах. «Модель» была просто структурой данных в БД (по сути конфиг-файл). С этими знаниями я перешел к разработке в CodeIgniter.

В этом фреймворке, славящимся своей быстротой и гибкостью, бизнес-логика может содержаться как в модели так и в контроллере. Это слегка сбило меня с толку. В процессе работы вышло само-собой, что модель (по аналогии с опытом symfony) у меня лишь содержала сбор данных из БД, а основным рабочим блоком были контроллеры. А иной раз выходило, что часть бызнес-логики попадала в модель… Вобщем, намечался небольшой бардак.

И вот, совсем недавно, подписавшись на новостную рассылку от thinkvitamin.com,  я получил в качестве подарка 44 страницы резюме докладов Райана Сингера, ведущего дизайнера интерфейсов из 37signals. Скажу сразу, для меня интерфейсы приложений от этой студии (basecamp и др.) являются эталоном и объектом поклонения. И как же хорошо, что он и слушатели подняли тему MVC! Все сразу стало на свои места.

Think of the model like this:
What are the things our app needs to
keep track of, and how do they relate to
each other?

и еще – модель в словах:

There are projects and each project has
messages, to-do lists, and milestones.”
“Messages can have comments.”
“To-do lists are made up of to-do items.

Довольно грязный дословный перевод:  модель – это все те вещи, которые ваше приложение должно отслеживать/обрабатывать и как эти вещи соотносятся друг с другом. Теперь, собрав мысли в новое определение, получаем:

• модель содержит всю бизнес-логику приложения – никаких лишних шестеренок в контроллере или виде.
• контроллер – просто как драйвер между устройством и компьютером – выполняет в основном «спинно-мозговые» и транспортные операции (upd: если представить, что ваше приложение будет работать не для веб-браузера, а для десктопа – по идее, вы просто должны заменить контроллер)
• вид – (x)html-шаблон, с которым в большей степени работает уже дизайнер-верстальщик, чем меньше там программного кода вообще, тем лучше

Я лично следующий свой проект буду начинать с бóльшим воодушевлением, чем раньше. Одним бардаком меньше.

Перечислю четко критерии моего выбора:

1. прежде всего, популярность среди разработчиков (необязательно всеобщая)
2. легкий вес
3. вставка из Ворда или скопированного текста с сайта должна исключать мусорный код (однако сохранять параграфы) на выходе
4. необходимый минимум функций и возможность дополнения
5. редактор должен быть именно wysiwyg (для блондинок), но не язык разметки markup или textile
6. желательно базирование на jQuery

Не стану описывать в деталях все пересмотренные варианты, и почему они не подошли. Я потратил почти день и так и не смог найти нужного редактора.  Большинство отметались из-за сохранения на выходе мусора «предыдущей разметки», несмотря на  специальные функции «Вставка из Ворда» и прочее. Отмечу, что встретились достойные разработки нашего российского и даже китайского производства.

Лишь на следующий день, на утро после чашки кофе, как снег на голову упал «мой» редактор – WYMeditor. Достаточно невзрачный по нынешним меркам сайт сначала отпугнул. Однако, я уже был в отчаянии, поэтому решил установить и попробовать. Итак, докладываю:

• WYMeditor – единственный из протестированных (за исключением markItUp!), который «очищает» вставляемый код и красиво разбивает текстовые блоки – параграфы, цитаты, списки
• он весьма легкий и, как мне показалось, на 100% настраиваемый. Я могу легко добавить свою панель кнопок, переместить их, легко могу контролировать «статусную строку» под зоной редактирования.
• в нем есть «темы», применив одну из них (самую аскетичную), у меня получилось неожиданно органично визуально интегрировать редактор в дизайн системы
• стабильный! за все время работы не возникало неожиданностей – кредит доверия возрос

И вот, я, будучи дотошным занудным снобом могу сдать систему с этим редактором в эксплуатацию самой легкомысленной блондинке! И надеяться на чистый, «валидный» код текстов, производимый ею на сайте…

Но что если у вас есть тяга все автоматизировать? Что если вы хотите исключить из цепочки действий (выше) поиск, скачку и загрузку на сайт фотографий? Скажем, зададим страну или курорт на карте Google и пусть фотографии волшебным образом появятся на сайте сами. Хорошие новости – это вполне себе возможно, даже очень просто с помощью сервиса Panoramio.

Этот сервис позволяет выдать набор фотографий по заданному географическому «квадрату» (или даже прямоугольнику – не разбирался в этом глубоко). Если у вас на сайте географические локации хранятся в формате Google Maps (как и у меня), то достаточно «нарастить» квадрат от точки-центра, задав нужный размер квадрата. У меня он разный для стран и курортов.

Пример. Куба задана в базе следующими координатами 21.637005211106306, -77.76123046875 (просто произвольная точка на ее территории). Нарастим квадрат в один градус широты и долготы (примерно 100 км от центра, так как земля не шар а эллипс – точные вычисления достаточно сложны) и получим:

• maxX: -76.76123046875
• maxY: 22.637005211106306
• minX: -78.76123046875
• minY: 20.637005211106306

Теперь достаточно создать REST-запрос к сервису Panoramio: http://www.panoramio.com/map/get_panoramas.php?order=popularity&set=public&from=0&to=27&minx=-78.76123046875&miny=20.637005211106306&maxx=-76.76123046875&maxy=22.637005211106306&size=square&callback=?

В ответ мы получим JSON-данные о фотографиях, типа:

 {
      "count": 773840,"photos": [
        {
          "photo_id": 532693,
          "photo_title": "Wheatfield in afternoon light",
          "photo_url": "http://www.panoramio.com/photo/532693",
          "photo_file_url": "http://static2.bareka.com/photos/medium/532693.jpg",
          "longitude": 11.280727,
          "latitude": 59.643198,
          "width": 500,
          "height": 333,
          "upload_date": "22 January 2007",
          "owner_id": 39160,
          "owner_name": "Snemann",
          "owner_url": "http://www.panoramio.com/user/39160",
        },
        {
          "photo_id": 505229,
          "photo_title": "Etangs près de Dijon",
          "photo_url": "http://www.panoramio.com/photo/505229",
          "photo_file_url": "http://static2.bareka.com/photos/medium/505229.jpg",
          "longitude": 5.168552,
          "latitude": 47.312642,
          "width": 350,
          "height": 500,
          "upload_date": "20 January 2007",
          "owner_id": 78506,
          "owner_name": "Philippe Stoop",
          "owner_url": "http://www.panoramio.com/user/78506"
        }, ...
      ]
    }

С помощью несложной функции (jQuery) можно налету сформировать галерею:

$.getJSON(url,function(data) {
  if (data.photos.length>0) {
  $(data.photos).each(function() {
     $(target).append('<a id="'+this.photo_id+'" title="'+this.photo_title+'" rel="pano" href="http://mw2.google.com/mw-panoramio/photos/medium/'+this.photo_id+'.jpg"><img src="'+this.photo_file_url +'" alt="'+this.photo_title+'" width="60" height="60" /></a>');
  });}
});

url – как раз наш REST-запрос

Самое главное – не забыть указать, что фото отображены с помощью сервиса Panoramio и их полные версии должны иметь ссылку на оригинальное фото.

Подробнее на официальном сайте

Inspired by a stackoverflow.com question. any comments or additions are more than welcome. / Любые комментарии и дополнения по этой теме приветствуются.

UPD: INT(11) in id is changed into INTEGER because ZEROFILL is not used. / Я изменил INT(11) в поле id на INTEGER, так как не использую ZEROFILL

UPD2: * по мнению одного моего товарища (@RuSHA), вместо записи в строку лучше пользоваться отдельной таблицей – выборка через LIKE может оказаться куда прожорливей чем грамотно построенный JOIN.

UPD3:  поля varchar(n) можно заменить на аналогичные char(n) – это займет больше места, однако, из-за фиксированной длины char скорость выдачи данных увеличится.