livedev.org

При написании приложения по принципам MVC с использованием Ajax, часто для одного и того же запроса нужно получить данные в двух отличных друг от друга вариантах—в чистом HTML и в XML/json для Ajax запроса. А т.к. один и тот же контроллер в MVC обрабатывает оба типа запроса и скорее всего было бы удобно для его обработки использовать один и тот же URL, надо как-то отличать их, чтоб знать в каком формате отдать данные. Если это POST-запрос то можно просто создать дополнительное поле/переменную в запросе, а если GET, то нужно или отдельный URL для каждого типа данных или дополнительный заголовок в запросе (см. ниже почему).

Проблема мне кажется больше именно в GET запросе. Если следовать правилам ReST, то контент полученный по URL должен быть кеширован, а в нашем случае будет кеширован первый формат, в котором контроллер отдаст контент. Было бы удобно чтоб контроллер делал проверку на наличие каких-то заголовков и отдавал в зависимости от них ответ в нужном виде, но вот кеширование этому помешает. Т.к. кеш скеширует контент на первый попавшийся запрос (Ajax/HTML) и для следующего отличного запроса может быть отдан контент в неверном формате. Конечно можно с помощью заголовков вообще отключить кеширование, но это неоправдано, т.к. в протоколе HTTP не зря предусмтрена такая функциональность.

В общем решением была бы возможность реагирования кеша на определенные заголовки от сервера. И да, это указано в стандарте HTTP и реализовано как клиентами так и серверами. Есть такой заголовок в стандарте HTTP—Vary:, обычно его называют Vary Header. Он необходим как раз для осуществления правильного кеширование в зависимости от его значения. По большому счету он нужен чтоб указать кешу для какого заголовка запроса скеширован данный URL. Т.е. контент в кеше теперь будет идентифицироваться не только по URL, но по URL + заголовок указанный директивой Vary. Например, если пользователь залогинен на сайт с использованием Cookie, тогда заголовок Vary должен выглядеть так Vary: Cookie. URL в это случае, например, будет /profile/ (профиль пользователя) и два разных пользователя, попав на страницу из одного кеша будут проверены с помощью директивы Vary на предмет Cookie и получат разный контент. Или например кеширование должно производиться с учетом языка пользователя, тогда директива будет выглядить так Vary: Content-Language.

Зачем это нужно в нашем случае? Все просто—практически все Javascript Toolkits используют заголовок HTTP_X_REQUESTED_WITH со значением ‘XMLHttpRequest’. Так что если мы поставим Vary: HTTP_X_REQUESTED_WITH, то оба запроса к одному URL но от разных инициаторов (сам браузер или javascript/ajax код) будут скешированы отдельно.

Вот такой интересный нюанс. Может кому-то пригодится в деле.

Последнее время стал увлекаться подкастами. К сожалению русскоязычных качественных очень мало. А на тему веб-разработок вообще нет (поправьте если ошибаюсь).

Хочу привести свою подборку англоязычных подкастов, которые слушаю.

1. Начну с наиболее интересного для меня—Hivelogic Radio. В этом подкасте автор концентрируется на веб-разработке, как на дизайне так и на программировании. Очень интересные интервью с интересными людьми. В разработке есть акцент на Ruby on Rails. Со стороны аудио, подкаст сделан очень качественно. Приятно слушать.
2. Следующий подкаст я слушаю не так давно, но у него довольно большой авторитет—FOO Casts: Podcasts from O’Reilly & Friends В нем освящается много технических вопросов, необязательно связанных с вебом, но все равно полезных для любого гика и разработчика. Качества звука тоже на высоте.
3. Inside Silicon Valley—Подкаст, состоящий в основном из интервью с монстрами и просто успешными людьми из Силиконовой Долины. Качество хорошее, слушать интересно.
4. Python411 Podcast—для фанов Python. Качество звука не впечатляет, но темы и интервью довольно интересные. Так что подкаст пожалуй действительно для фанатов Python. Освящаются вопросы не только веб-разработки, но и других специализаций в программировании.
5. WebDevRadio—Действительно настоящий подкаст именно для веб-разработчика. Обсуждение новых технологий в вебе, интервью, относительно часты обновления. Советую.
6. The Mac Attack—Подкаст про Mac, MacOSX и все что с ним связано. Как известно многие современные веб-разработчики и дизайнеры выбирают платформу Apple в качестве рабочей станции. Так что думаю будет просто интересно, а некоторым и полезно.

Обновление моего блога.

На днях обновил свой блог на движке typo, до весрии 4.1

Впечатления пока что только приятные. Сразу бросается в глаза подчищенная админка. Большой плюс еще, что блог движок работает на rails 1.2 и заметный прогресс в том, что есть встроенная возможность локализации.

Процесс переезда прошел прозрачно, почти без бубна и плясок :-) Итак пошагово, для тех, кто будет повторять:

1. Бекапим базу в двух вариантах—SQL-дамп и сериализованный YAML вариант. Первое делается через mysqldump или phpmyadmin, а второй вариант командой rails-backup в директории с rails-проектом блога.
2. Обновляем rails и typo. Т.к. у меня все работает через rubygem, я просто запустил sudo gem update. После чего получил последние стабильные gems.
3. Останавливаем текущий процесс typo. Переименовываем директорию проекта и создаем заново проект с typo—typo install my_typo_dir
4. Переносим конфиги из старой в новую директорию (обычно это database.yml и mongrel_cluster.yml). И обновляем базу rake db:migrate.
5. После чего запускаем проект (у меня он работает через mongrel cluster), логинимся в админку и первым делом нам предлагается поменять контент в базе на новый лад. Нужно просто согласиться и блог готов к работе.

Если появились трудности при апдейте—пишите, чем смогу помогу.

PS: В рассылке видел, что у одного человека возникли проблемы при переезде с базой. У него полечилось через rails-backup и rails-restore