(Не)идеальный интернет

Куча работы опять и сложно переключиться на дописывание своего нового сайта. И хостинг не мешало бы поменять на какой-нибудь VPS пошустрее. Работа доставляет задачками на тему внутривидовой коммуникации homo sapiens и способности сохранять выдержку и хладнокровие в моменты, когда многие их теряют. На знание географии, кстати, тоже доставляет задачки - скоро буду приводить Яндекс.Пробки в вид, пригодный для показа по телевизору. Дочь скоро пойдет в школу и об этом тоже не стоит забывать.

Очень хочется, чтобы все было спокойно. Пусть так оно и будет.

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

Получил массу удовольствия от просмотра и вам рекомендую :)

Установил Subversion на сервере под управлением apache+nginx в виртуальный подкаталог /svn

Настроил, работает и крутится. Но не полностью — никак не коммитятся файлы с картинками, имеющими разрешение png, jpg и т.д. При этом svn ругается следующим образом:

Commit failed (details follow):
Server sent unexpected return value (405 Not Allowed) in response to PROPFIND
request for '.......'
 
   

Долко колупался, но все-таки нашел на каком-то заброшенном форуме вопрос про такую же ситуацию и упоминание, что если в конфиге nginx отредактировать строчку

location ~* ^.+\.(jpeg|jpg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js|djvu|mht|chm)$ { ...
 
   

, убрав оттуда расширения файлов, которые не могут закоммититься, то все работает. Проверил - действительно, работает. Но отключать кэширование таких файлов — не решение.

Вместо этого надо исключить виртуальный подкаталог svn из обрабатываемых nginx'ом каталогов. За это отвечает секция nginx.conf примерно следующего вида:

location ~* ^/(awstats|myadmin/|svn/) {
proxy_pass http://xx.xx.xx.xx:8080;
proxy_redirect http://yoursite.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
 
   

Сегодня привычно запустил по пути на работу Opera Mini в своем мобильном телефоне, набрал в адресной строке http://reader.google.com и с удивлением обнаружил, что привычного мобильного интерфейса там нет:

Если я не ошибаюсь, этот интерфейс изначально предназначался для устройств с экранами среднего формата (типа таблеток, некоторых КПК и т.п.), которые способны обрабатывать Javascript. По функциональности он приближается к интерфейсу, доступному из обычных браузеров.

Однако в Opera Mini (которая, как известно, не обрабатывает Javascript локально, а делает это на специально предназначенных для этого серверах) каждое действие, предполагающее скриптовую интерактивность, перезагружает страницу. В случае с мобильной версией Google Reader это означает пустой расход трафика на загрузку не только новых, но и уже прочитанных записей, а также необходимость каждый раз проматывать разросшуюся страницу к новым записям. В общем, жутко неудобно.

Поверхностный анализ ситуации выявил, что Opera Mini стала как-то по другому отдавать Гуглу заголовки User-Agent в своих запросах и Гугл отдает интерфейс, не предназначенный для мобильников.

Теперь о том, что же нужно делать в сложившейся ситуации, не отказываясь от Opera Mini. Нужно всего ничего — воспользоваться прямой ссылкой на легкую мобильную версию Google Reader, которая доступна по адресу http://google.com/reader/m:

Так что поправляйте закладки в телефоне, если еще не поправили.