Современный уровень развития RTS и виртуализации позволяет считать файлом что угодно (независимо от того, где это физически расположено и как хранится), если:

• это упорядоченный набор байтов ограниченной длины
  
• к нему применимы «стандартные» файловые операции open, read, write, pos, close, delete/truncate
  
• прозрачно монтируется к локальной FS
  

Практические применения коллизий в md5. [ >>> ]
В пример приводятся два абсолютно разных postscript документа, с одинаковым md5 хэшем.
[ >>> ]

С введением в строй гугловского sitemap вопрос хинтов для поисковых систем все равно остается актуальным.

Понятно, что контент обновляемого сайта можно поделить на две категории:
а) Динамическая. Это новые и часто обновляемые страницы. Необходимость быстрой индексации: высокая
б) Статическая. Фактически — это архив сайта. Изменяется редко, за исключением индексов. Необходимость быстрой индексации: низкая.
Третью категорию («левый контент»), формально не входящую в стостав сайта, рассматривать не будем.

Что предлгает Гугль? Он предлагает выложить список всех страниц сайта с указанием last modified и частоты изменения (для каждого url). Что с этим списком собирается делать Гугль — не совсем понятно (в документации это не описано).
Предположительно, Гугль начнет сверять sitemap со своим списком страниц. «Новые» страницы, отсутствующие в гугловском списке, пойдут в очередь на индексацию. «Старые» страницы сравниваются по last modified и, при необходимости, пойдут на реиндексацию.

Все это, конечно, хорошо… но! Что-то меня не радует необходимость перестраивать sitemap после каждого обновления на сайте/блоге. А это, между прочим, не одна тысяча url.
Поэтому, на мой взгляд, было бы логичней не смешивать все в один котелок, а отделить мух от котлет и учитывать каждую категорию отдельно. Динамическую часть получать из «облегченного» rss, а статическую — из списка разделов (тот же sitemap, но не по отдельным url, а по разделам). А для каждого раздела еще можно указать, какие страницы индексировать в первую очередь, а какие — вообще нежелательно (например, «версия для печати»). Где-то так…

Интересным примером масштабирования в зависимости от объемов задачи является рыба пирана. На практике стая пиран за ограниченное время способна освоить еду на несколько порядков превышающую возможности одной пираны.
В it-области такие подходы тоже применяются… но несколько странным методом.

update: если один муравей способен утащить «груз», в несколько раз превышающий его собственный вес, то сколько муравьев потребуется, чтобы утащить слона?

«Это не „непонятный символ“, а тензор форматирования второго уровня»

А не поговорить ли нам о метаразметке? Потому как на небольших текстах нет разницы, какой разметкой вы пользуетесь — html или wiki, особенно при quick insert («выделил — вставил») — и по этому поводу копья можно не ломать.

Так вот, в отличие от «обычной» разметки, метаразметка базируется на том, что контент полностью отделен (в идеале) от визуального представления.
Т.е. производится разметка структурными блоками/элементами, причем прямого соответствия с html-представлением нет. Точнее, такого соответствия вообще нет — документ разворачивается в html (или другой формат) согласно правилам преобразования (которые легко заменить). Интересно, что элемент в полученном html может «расползаться» по странице, а не концентрироваться в одном месте.

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

Поскольку речь идет о разметке записей в блогах, то XML как строгий, инертный и неудобный вариант метаразметки рассматривать не будем.
Более привлекателен вариант, когда запись считается «документом, встраиваемым в среду», а развертывание в html производится средствами самой среды. Стратегия разметки записи при этом напоминает тюнинг, подстройку рельефа записи — т.е. выделение структурных единиц из plain text.

Следующий момент — это синтаксис. Он (сюрприз!) не обязан быть парным. Зато разметка обязана быть однозначной — и в этом смысле теговая разметка безопаснее разметки спецсимволами, но менее прозрачна.

Раз уж руки не доходят попробовать АК на натуре, то попробую умно порассуждать.

Так вот, АК — это способ выцеплять ключевые слова (КС) прямо из текста (заметки или статьи). Выцепленные слова морфологически нормализуются и предлагаются пользователю «на утверждение». При необходимости пользователь может отредактировать эти КС.

Есть две основные стратегии работы АК:
а) исключающая. Стратегия предусматривает фильтрацию и отбрасывание «незначащих и/или несущественных» слов. «Сухой остаток» — это и есть искомые КС.
Плюсы: позволяет выцепить даже те КС, которые раньше не встречались
Минусы: непонятно, как в общем случае определять малоценность слова
б) включающая. Стратегия, обратная предыдущей: из текста выцепляются «знакомые» слова, из которых и формируется список КС.
Плюсы: объем базы знаний меньше, чем в варианте «а»; автоматический учет синонимов
Минусы: не способен опознать КС, которое раньше не встречалось; сложнее в настройке и сопровождении

Следующий шаг — урезание списка КС. Ну зачем вам нужны все 10–20 (или больше) КС?
Поэтому КС рейтингуются (по весу/важности) и оставляются наиболее ценные, остальные — отбрасываются.

«Это был необычайно умный и прожорливый зверек»

 — Никс, а что это за «вывернутая шкурка идеального агрегатора», о котором ты вчера трепалась с Джи?
 — Ммм… в двух словах этого не объяснить.
 — Ничего, я удобно устроилась и никуда не тороплюсь.
 — Вот негодяйка! Ладно, слушай. Исходная предпосылка такая: идеальный агрегатор (в классическом понимании) получается мифическим. Потому как на вкус и предпочтение… а попробуй учти всех их в одной программе. Разработчики, конечно, пытаются учесть «все» и нарастить «функциональную мощь», но… попытка идти экстенсивным путем — это примерно как «если требуется повысить удои, то начинаем разводить кур».
А раз гибкость и эффективность — немаловажный для нас фактор, то тут мы подходим к следующей предпосылке: почему бы нам не зайти с другой стороны — со стороны пользователя и его предпочтений? И тогда речь пойдет об идеальном поведении агрегатора. А оно зависит не от того, как и что может показать агрегатор, а от того, в каком виде и под каким соусом пользователь хочет читать свои любимые фиды. И тут у нас есть два варианта. Первый: агрегатор распределяет записи по тематике, и оставляет все остальное на усмотрение пользователя. Второй — базируется на том, как пользователь предпочитает работать с информацией. Мне, к примеру, удобно читать новые записи лентой, разбитой по порциям. И от агрегатора требуется не только упорядочить записи по тематике, но и сформировать ленту, с учетом того, какую тематику я хочу читать первой, а какую — оставить на сладкое.
 — А если сегодня ты захочешь одно, а завтра — другое?
 — А для этого есть система профилей или что-то типа того, которая позволяет учесть, во сколько я вчера легла спать, с какой ноги встала и почему «не нужно читать до завтрака советских газет». Захочу — и не буду читать ленту, а начну сама потрошить фиды или тематическую раскладку.
 — Иначе говоря, ты хочешь навязать агрегатору свои правила игры. А идеальное поведение — это когда он принимает их?
 — В точку! Агрегатор должен предоставлять столько возможностей, сколько мне нужно и в том разрезе, как мне удобно. И не должен навязывать мне правила, как мне читать. Его задача — поддерживать мой темп и стиль работы с информацией. Как сказала Джи, «эвристики программы заканчиваются там, где начинаются эвристики пользователя». А моя задача — объяснить свои эвристики программе: что и как подавать мне в горшочке, а что — в тарелочке с синей каемочкой.
 — Ты так хорошо расписала… знаешь, а мне тоже нужен такой нежный и заботливый зверек.

В каких случаях АК может быть вполне приемлемой штукой?
Навскидку вот как:

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

Решил поискать, что известно «Уважаемому Интернету» о rss 3.0. Выяснилось, что проект такой штуки действительно существует (пример фида), но… «странно-то как, Машенька!»

Впрочем, у меня вот какой вопрос. Если я хочу воткнуть собственные теги в rss 2.0 — каким образом это делается? Поднять собственный namespace или как-то иначе (например, встраивать в комментарии)?
Интерес пока чисто теоретический.

Людям свойственно путать real identiny с virtual identity. Virtual multi-identity их шокирует, а от multi-virtual identity ортогональные векторы мышления реципиентов идут куда-то по градиенту, т.к. никак не укладываются в привычное (а иногда и шаблонное) мышление.

Кроме того, многие изначально делают ошибку: переносят свои привычки и стереотипы из реальной реальности в виртуальную. А потом удивляются диссонансу…

inspired by