Для меня, если кто-то будет видеть его или не не имеет значения - маловероятно, что я буду знать то, что некоторая неясная часть кода, который я записал, делает после нескольких месяцев. Существует несколько инструкций:
API, классы платформы и внутренние допускающие повторное использование статические методы должны быть прокомментированы полностью.
Логика в каждой сложной части кода должна быть объяснена на двух местах - общая логика в javadoc и логика для каждой значимой части кода в своем собственном комментарии.
свойства Model должны быть прокомментированы, если они не очевидны. Например, никакой смысл в комментарии имени пользователя и пароля, но типа не должен, по крайней мере, иметь комментарий, в котором говорится, что является возможными значениями для типа.
я не документирую методов get, методы set или что-либо сделанное "книгой". Если у команды есть стандартный способ создать формы, адаптеры, контроллеры, фасады... Я не документирую их, так как нет никакого смысла, если все адаптеры являются тем же и имеют ряд стандартных методов. Любой знакомый с платформой будет знать то, что они для - предполагающий, что философия платформы и способ работать с нею документируются где-нибудь. В этом случается, комментарии означают дополнительную помеху и не имеют никакой цели. Существуют исключения к этому, когда класс делает что-то нестандартное - тогда, короткий комментарий полезен. Кроме того, даже если я создаю форму стандартным способом, мне нравится делить части формы с короткими комментариями, которые делят код на несколько частей, например, "адрес выставления счета запускается здесь".
Короче говоря, прокомментируйте логику, не синтаксис, и сделайте это только однажды на надлежащем месте.
При чтении новостей за пределами моего RSS-ридера я часто использую Readability , чтобы отфильтровать все, кроме сути статьи. Он основан на Javascript, поэтому этот метод не может напрямую применяться к вашей проблеме, но, по моему опыту, алгоритм имеет высокий уровень успеха и заслуживает внимания. Надеюсь, это поможет.
Если вы согласились с тем фактом, что все, что вы попробуете, будет очень схематичным, исходя из ваших требований, я рекомендую вам изучить байесовскую фильтрацию . Этот метод оказался очень эффективным при фильтрации спама из электронной почты.
Взгляните на конструктор шаблонов ( домашняя страница кода Google ). Основная идея состоит в том, что вы запрашиваете несколько разных страниц с одного и того же сайта, а затем отмечаете, какие элементы являются общими для набора страниц. Отсюда вы можете определить, где находится динамический контент.
Попробуйте запустить diff
на двух страницах одного и того же сайта, чтобы понять, как это работает. Различные части страницы - это места с динамическим (интересным) контентом.
Вот что я сделал бы после того, как проверил файл robots.txt
, чтобы убедиться, что можно выбросить статью и проанализировать документ как дерево XML:
Убедитесь, что статья не разбита на много страниц. Если это так, ссылки "просмотр для печати", "отдельная страница" или "просмотр для мобильных устройств" могут помочь перенести его на одностраничный . Конечно, не беспокойтесь, если вам нужно только начало статьи.
Найдите фрейм основного содержания. Для этого я бы посчитал количество информации в каждом теге. Теперь мы ищем узел, который является большим , но состоит из множества маленьких подузлов.
Теперь я бы попытался отфильтровать любой шум внутри кадра содержимого. Ну, сайты, которые я читаю, не кладут туда никакой ерунды, только полезные изображения, но вам нужно уничтожить все, что имеет встроенный javascript и любые внешние ссылки.
При желании выровняйте это в обычный текст (то есть войдите в дерево и откройте все элементы; блочные элементы создают новый абзац).
Угадайте заголовок . Обычно это что-то с h1
, h2
или, по крайней мере, с большим размером шрифта, но вы можете упростить жизнь, предположив, что он чем-то похож на заголовок страницы.
Наконец, найдите авторов ( что-то с именами и адресом электронной почты), уведомление об авторских правах (попробуйте метаданные или слово copyright ) и название сайта. Соберите их где-нибудь вместе со ссылкой на исходный и четко укажите, что это, вероятно, добросовестное использование (или любая другая юридическая доктрина, которая, по вашему мнению, применима к вам. )
Очевидно, это не полное решение, но вместо того, чтобы пытаться найти релевантный контент, может быть проще дисквалифицировать нерелевантный контент. Вы можете классифицировать определенные типы шумов и работать над более мелкими решениями, которые их устраняют. У вас могут быть рекламные фильтры, фильтры навигации и т. Д.
Я думаю, что более серьезный вопрос заключается в том, нужно ли вам иметь одно решение, работающее с широким спектром контента, или вы хотите создать структуру, которую можно расширить и реализовать по каждому сайту? Вдобавок ко всему, как часто вы ожидаете изменений в основных источниках данных (например, волатильности)?
Вот мой (вероятно, наивный) план того, как подойти к этому:
Предполагая, что RSS-канал содержит вводные слова статьи, вы можете использовать их для определения местоположения начала статьи в DOM. Пройдите немного назад по DOM (первый родительский DIV? Первый не встроенный элемент контейнера?) И отрежьте. Это должна быть статья.
Предполагая, что вы можете получить документ как XML (здесь может помочь HtmlAgilityPack ), вы можете (например) получить весь текст-потомок из элементов
с помощью следующего Linq2Xml :
Возможно, вам стоит взглянуть на Скрытое распределение Дирихле , которое представляет собой методику IR для создания тем из имеющихся у вас текстовых данных. Это должно помочь вам уменьшить шум и получить точную информацию о том, о чем страница.