Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Использование статических языков для веб-майнинга — ошибка

10 комментариев

Web mining/scraping с использованием компилируемых языков – это ошибка. Тем самым, то про что я написал в нескольких своих постах про WatiN – в корне неправильно.

Почему? Все просто – манипулировать WatiN нужно очень много, как при отладке так и при изменениях структуры сайтов. Адекватно ли каждый раз лезть в VS и перекомпилировать? Нет. Эти задачи должны отдаваться на откуп либо DLR либо – если вам совсем тошно – для in-process компиляции прямо в вашей программе (я имею ввиду CSharpCompiler или как он сейчас там называется).

Сейчас буду менять свой код дабы реализовать именно такой подход. Придется делать IntelliSense и подсветку синтаксиса. Весело.

Реклама

Written by Dmitri

14 сентября 2010 в 19:58

Опубликовано в .NET, C#

комментариев 10

Subscribe to comments with RSS.

  1. Дима, у меня эта мысль уже так пару лет сидит в голове, но нет или не было никакой поддержки инлайн-компиляции кода, да и высокий порог вхождения в WPF вынудил меня снова вернуться к JavaScript и Web-разработкам

    Вадим

    15 сентября 2010 at 15:39

    • Ну как это—есть ведь. Мы же можем из нашей программы компилировать in-memory сборку которая прямо в наш текущий аппдомен подгрузится. И если извратиться, ее можно даже в другой аппдомен загрузить чтобы все оттуда можно было выгружать. Я собственно про это.

      Что касается поддержки редактирования, сейчас как раз работаю с тем же UI-компонентом который LinqPad использует – там очень много чего поддерживается, в том числе и C#.

      Dmitri

      15 сентября 2010 at 16:16

  2. Если ты используешь типизированный мэппинг у WatiN, для того чтобы сопоставить контролы на странице со свойствами в Page-классе, то поддержка такого решения будет достаточно трудоемкой.

    На первый взгляд мне этот типизированный мэппинг с помощью атрибутов очень сильно понравился, но потом я от него отказался в пользу менее типизированного подхода — использованием CSS селекторов в духе:

    //input[contains(@class, ‘inputDate’)]
    //*[text()=’Sign On’]/ancestor::a
    //*[text()=’Name’]/following::input[1]
    //*[contains(text(), ‘SomeDynamicText’)]//a[contains(@class, ‘actionDownload’)]

    Причем я переехал на этот синтаксис когда начал переписывать свой код с WatiN на HtmUnit + IKVM. Я понял что каждый раз искать эти котролы, и потом описывать мэппинг это очень большой effort.

    Поскольку я уже знал XPath, то я с наскоку изучил синтаксис этих самых CSS селекторов. В качестве иструмента для отладки CSS селектора я использовал связку Firefox + Firebug + Firefind. На удивление все это заняло у меня довольно мало времени.

    Так что посмотри, вдруг тебе идея с CSS-селекторами понравится, хотя я не знаю насколько хорошо с ними обстоят дела у WatiN.

    А насчет строгой типизации и необходимости перекомпиляции проблема стоит действительно так остро?

    Может быть стоит какие-то менее радикальные решение пробовать типа разнесения разных сценариев по разным C# проектам и потом это все на динамике связывать через тот же MEF или IoC?

    Просто использование динамической компиляции IMHO существенно связывает руки, а использование динамических языков типа IronPyhton все таки менее продуктивно. Хотя в VS 2010 с IronPython намного лучше стало чем раньше :)

    ЗЫ не хочу показаться назойливым, но ты поковыряй таки HtmlUnit + IKVM. Рально хорошая вещь, как раз для скрейпинга подходит намного лучше чем WatiN, который делался чисто для QA Automation. Он умеет обрабатывать очень много браузерных сценариев при этом без браузера. Ты же не собираешь данные с Flash и Silverlight приложений? Или таки собираешь?

    Alexey Diyan

    15 сентября 2010 at 16:24

    • Как-то я все это совсем по-другому вижу. В смысле API от WatiN меня устраивает для некритичных по производительности задач (WatiN – тормоз, но если майнить раз в день—какая разница?). Что меня неустраивает так это то, что каждый раз когда я понимаю что сделал ошибку где-то, мне надо все перекомпилировать и перезапускать. Workflow при вынесении этой компиляции прямо в мою программу увеличивает мою производительность в разы. Я могу например прямо в своём автопубликаторе редактировать роботов для существующих площадок и добавлять новые.

      Кстати, вот скриншот самой тулзы — дабы было понятно для чего все это.

      Dmitri

      15 сентября 2010 at 17:19

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

    ulu

    15 сентября 2010 at 19:53

    • Почему? Это ж прибыльно, спрос есть — имея свои фреймворки и процессы, можно делать мало и зарабатывать много.

      Dmitri

      15 сентября 2010 at 23:12

      • Просто переписывать парсинг каждый раз, когда владелец сайта меняет дизайн — слишком накладно.

        ulu

        18 сентября 2010 at 21:45

      • Дмитрий, подскажите в каких областях это пользуется спросом?

        Алексей

        29 сентября 2010 at 23:30

  4. Не пробывал использовать скриптинг из F#? я например использую, и компилируется и если надо что-то поменять студия не нужна.

    cadet354

    3 ноября 2010 at 10:22


Оставить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: