Понадобилось как-то выудить информацию из Интернета. Нашёл подходящий сайт, посмотрел на устройство страниц. Оказалось, что скрыто многое от ока всё скачивающего wget. Не помогла и стандартная сборка HTTrack. Хотел было паука для Scrapy написать, но не пришло ощущение надёжности и масштабируемости. Стал думу думать, да и велосипед изобретать, точнее свой web crawler писать.

Находил в Интернете разные статьи по разработке инструментов для скачивания сайтов, но не приглянулись из-за ограниченности своей, которая допустима лишь для примеров, но не для задач реальных. Приведу лишь два основных. Во-первых, заранее необходимо предусмотреть разбор всех типов страниц. Во-вторых, почти всегда информация выгружается за один раз, а при ошибке просто всё вновь запускается.

Про свои предыдущие поделки на время забыл, в сторону отложил, а всё сосредоточение направил на архитектуру, статью о которой не срамно и на Хабре будет выложить.

Упрощения ради повествования было имя выбрано «ИнКр» (InCr), что является сокращением от Intellectual Crawler, а также является началом слова Incredible (невероятный).

ИнКр должен представлять собой платформу, которая сама реализует базовые функции по управлению заданиями, скачиванию и хранению документов. Со стороны же разработчика требуется написание парсеров для конкретного сайта. В ходе анализа были сформулированы следующие основные требования:
1. Возможность гибкой настройки загрузки: ограничение количества потоков, приостановка обработки для аутентификации, распознаванию captcha и т.п.;
2. Независимость загрузки страниц и их разбора, возможность повторного разбора ранее скаченных страниц;
3. Поддержка процесса разработки парсера: отдельно отмечаются все документы, которые не смогли быть полностью разобраны;
4. Возможность дополнения данных, полученных на основе информации нескольких страниц;
5. Продолжение процесса загрузки страниц после остановки;
6. Корректная обработка изменений;
7. Одновременная работа сразу с несколькими сайтами и наборами правил.

Вы знаете, чем отличается %{REQUEST_URI} в Apache mod_rewrite от $_SERVER["REQUEST_URI"] в PHP?

Сможете в .htaccess на уровне Apache сделать корректную переадресацию 301 с домена с префиксом www или на него?

Для последнего вопроса я и сейчас не смогу предложить решение. Причина в протоколе HTTP/1.1, который пришлось изучить подробнее, когда «изобретал велосипед» (создавал ядро для сайта).

Всё дело в HTTP-заголовке запроса «Host:». При определённых условиях там может быть всё, что угодно, причём сервер должен полностью это проигнорировать согласно HTTP/1.1. Большинство же разработчиков используют значение этого поля, например, для SEO-оптимизаций. Забегая вперёд, скажу, что дополнительный прокси (например, nginx) позволит решить эту проблему.

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

Что же скрывает REQUEST_URI в HTTP/1.1?

Недавно наткнулся на ошибку в Android приложении Яндекс.Метро. Если бы был чемпионкой мира по синхронному плаванию, то обязательно спросил бы: «Кто создавал программу „для галочки“? Кто работал „на отшибись“? Кто слабое звено?». Недоумение вызывала не сама ошибка, а то, что она попала в приложение и всё ещё не исправлена.

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

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

В статье же мы будем рассматривать распространённые приложения, которые протестировать может любой участник команды. Давайте проведём небольшой эксперимент. Если у вас нет Android устройства, то попросите минут на десять у коллег или друзей. Скачайте приложение Яндекс.Метро и попробуйте его протестировать. Интересует актуальная на текущий момент версия 1.63 от 02.11.2012 сборка 159 (на Google Play стоит дата 21.01.2013). Для корректности проверки предлагаю снять галочку «Автообновление» в настройках Google Play.

Проверять будем основную функцию: нахождение маршрута между двумя станциями метрополитена Москвы. Посмотрите на карту метро. Подумайте, что следовало бы протестировать в приложении, что могло бы быть неправильно реализовано. Явной ошибкой будет сообщение «Маршруты не найдены», что некорректно, поскольку нет изолированных станций.

Эта же ошибка может проявить себя не так явно:

Введение

В статье описываю подход к созданию удобного инструмента на Javascript для онлайн-редактирования текстов. В качестве примера создал прототип для редактирования статей на Хабре (описан ниже). С его помощью сейчас и вношу изменения в данную статью.

Передо мной встала задача выбора онлайн-редактора для текстов на сайте. Самым очевидным решением оказался бы один из WYSIWYG редакторов. Но этот вариант мне не понравился по нескольким причинам. Во-первых, многие уязвимости популярных CMS систем связаны именно с WYSIWYG редакторами. Во-вторых, после публикации текст часто будет отличаться от того, что было в редакторе. В-третьих, подобные редакторы сложно расширить для поддержки новых тэгов и элементов. Поэтому остановился на WYSIWYM редакторе.