Tom Adler’s blog

ссылка: разработчики библиотек о html5

InfoQ провёл виртуальный «открытый стол» с разработчиками популярных javascript-библиотек на тему перспективности для них новых возможностей html5. Участвуют:

особенно интересно, что говорится не столько о тонких технических подробностях, сколько о глобальных подходах, об общем ви́дении

via Andrew Dupont

, , ,

как не качать deb-пакеты дважды

быстрый рецепт

когда вышел Ubunty 9.04 Jaunty Jackalope, я немедленно скачал torrent официального DVD и положил в папочку. А памятуя прошлые обновления, когда новые версии пакетов тянулись с официальных серверов в час по чайной ложке, решил в этот раз использовать пакеты с диска. Но мне вовсе не хотелось вначале записывать образ на болванку, а потом слушать урчание привода, который всяко медленнее винчестера. Казалось бы, что может быть проще — примонтировать iso в файловую систему и указать инсталлятору на неё. Но не тут-то было!

во время предыдущего обновления я безуспешно пытался проделать эту операцию. Однако в этот раз я решил пойти до конца. Вначале создал каталог /media/ubuntu. Работать с iso-образами я предпочитаю через гуй простенькой программки gmount-iso, но того же можно добиться и через /etc/fstab:

/media/l-large/ubuntu-9.04-dvd-i386.iso /media/ubuntu udf,iso9660 noauto,loop

вручную вставить диск в инсталлятор невозможно, о чём предупреждает man apt-cdrom, поэтому положимся на него:

sudo apt-cdrom -d /media/ubuntu add

он зачем-то отмонтирует диск и попросит «вставить» его снова, но это не создаёт особых трудностей : )

после этих операций в /etc/apt/sources.list появилась запись:

deb cdrom:[Ubuntu 9.04 _Jaunty Jackalope_ - Release i386 (20090421.3)]/ jaunty main restricted

тут я обрадовался и запустил инсталлятор. Тот пошуршал байтами и попросил меня вставить диск в привод /cdrom/. «Ага!», — сказали мужики и задумались. Именно в этом месте я забил в прошлый раз. Но сейчас на глаза мне попалась строчка из мана apt-cdrom: «Configuration Item: Acquire::cdrom::mount.» Что-то похоже я уже видел в настройках apt. Например, в /etc/apt/apt.conf.d/10periodic:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "1";

Дальше было просто. Я создал файл /etc/apt/apt.conf.d/35cdrom с одной строчкой:

Acquire::cdrom::mount "/media/ubuntu/";

после этого пакеты ставились и продолжают ставиться большей частью с диска: «Need to get 929kB/5920kB of archives.» Впрочем, локально того же эффекта можно было добиться, указав эту опцию в командной строке к dist-upgrade:

sudo apt-get dist-upgrade -o Acquire::cdrom::mount="/media/ubuntu/"

итак, кратко то же самое (от рута):

# mkdir /media/ubuntu
# echo "/media/l-large/ubuntu-9.04-dvd-i386.iso /media/ubuntu udf,iso9660 noauto,loop" >> /etc/fstab
# sudo apt-cdrom -d /media/ubuntu add 
# echo 'Acquire::cdrom::mount "/media/ubuntu/";\n' >> /etc/apt/apt.conf.d/35cdrom

ps: собравшись опубликовать это на хабре, обнаружил там быстрый рецепт для обновления с сиди:

/cdmountpoint/cdromupgrade

browsers market share

за последнюю неделю мне пришли две новости, из которых можно сделать интересный вывод. Первая — про 270 миллионов пользователей Firefox (via). Вторая — про 35-40 миллионов пользователей Opera. Методики подсчёта у них приблизительно одинаковые, и, конечно, мы обеим компаниям верим ; )

впрочем, почему бы не проверить? Что говорят глобальные сервисы статистики на эту тему? W3Schools считает только своих посетителей, которые в большинстве своём веб-разработчики, поэтому даже не буду смотреть его сторону. Ещё есть, например, Net Applications и StatCounter. Первый из них — в своём роде Alexa — известный, древний и однобокий (подсчитывает преимущественно американские сайты). А вот второй показывает лучшее соответствие заявкам компаний. Получается 30%/270млн у фф, 3%/27млн у оперы и 2%.20млн у хрома, который ещё в конце года рапортовал как раз 10 миллионов

в общем, можно не верить StatCounter'у и Опере, а можно не верить только Net Applications. Жаль только, что блоггеры обычно хватают только первые попавшиеся цифры, и чаще всего ими оказываются данные именно NA

синергия чпу и поиска

пост в продолжение темы об улучшении человекопонятных адресов aka ЧПУ

во вчерашней отповеди Ильи Бирмана недостаточно хорошим адресам я заметил важный момент в мотивации, зачем нужны правильные ЧПУ:

…чтобы я мог написать адрес и попасть на нужную страницу, как я это с лёгкостью делаю на Википедии

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

вспомните: для википедии можно набрать в адресе «ru.wikipedia.org/django» и оказаться на нужной странице «http://ru.wikipedia.org/wiki/Django». Теперь представьте, что для других сайтов можно набрать, например «ilyabirman.ru/уникод», и оказаться на странице «http://ilyabirman.ru/meanwhile/2009/04/15/2/» с заметкой «Биты, Болк и Уникод», или быть перенаправленным с «blog.arty.name/цифровое видео» на «https://blog.arty.name/2009/ssyilka-o-tsifrovom-video/». Здорово, не правда ли?

что для этого нужно? Всего ничего! Если не удалось отрезолвить адрес, не спешить показывать 404 ошибку. Перед этим нужно взять из такого адреса путь и засунуть его в полнотекстовый поиск по основному контенту сайта: новостям, статьям, людям, фильмам — чему угодно. Если есть результаты, взять первый из них и перейти к нему. Вуаля!

конечно, желательно при этом подсмотреть у википедии и ещё одну правильную мысль: при таком редиректе желательно показать пользователю сообщение типа «вы направлены сюда с поискового запроса такого-то, кликните сюда, чтобы посмотреть другие результаты»

есть и быстрый+грязный вариант решения: редирект на гугловский «мне повезёт» по своему сайту и с этой же строкой поиска ; )

такую мысль можно развить в более сложный, но более универсальный и «правильный» вариант. У нас уже есть стандарт OpenSearch, относительно распространённый в вебе. Когда человек начинает писать в адресной строке, браузер берёт домен этого адреса, вытаскивает по XRDS для него путь opensearch, подставляет в этот путь всё после домена, берёт с полученного адреса варианты подсказок и предлагает их пользователю. С человеческой точки зрения это выглядит так: указал домен, после него написал поисковый запрос, выбрал нужный результат и перешёл к нему — почти ничем не отличается от опыта с уже существующими браузерами типа хрома или фф, только результативнее!

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

ваши мысли?

,

новый метод-глагол для http

все веб-разработчики знают про GET/POST, многие — ещё и про PUT/DELETE. Я также наслышан о том, что WebDav добавляет несколько специфичных для себя методов. Но тут внезапно! обнаруживаю в статье «REST worst practices» отсылку к новому глаголу PATCH, черновик спеки которого уже почти готов. Предполагается, что этот метод будет использоваться очень широко, потому что решает очень общую задачу: обновление только части объекта. Проблема в том, что PUT заменяет объект полностью, а иногда удобнее исправить только одну небольшую часть. Очень разумное предложение, буду ждать выхода стандарта

, ,