Comments 59
По факту хорошие парсеры обычно не наглеют и минимизируют по возможности количество RPS так как и за трафик, прокси и клауд тоже нужно платить. Если говорить о home residential прокси то стоимость довольно неплохо подскакивает. Автор большой молодец так как в данной статье верно замечает, что приоритет в этой войне нужно сместить на баланс принятых мер, защиты от средств сбора данных и удобства обычных пользователей.
Посоветовать могу как не странно самые простые js проверки не смотря на возможности headless браузеров но они на порядок медленней обычных http запросов и их масштабирование на порядок сложнее(точнее дороже) чем у обычных скриптов. Так же многие из тех кто пишет парсеры не лезут в js смотреть всю цепочку вызовов. Касательно капчи 3-я версия google ReCapcha неплохо ловит парсеры, но так же часто срабатывает на обычных пользователей, так что советую остановиться на второй в текущей момент.
Так же не самой плохой стратегией следует принять создание API для получения данных. Некоторые сервисы предлагают платный API к данным тем самым снижая на порядок объём ботов которые к ним лезут.
За 6 лет активной работы по всевозможными проектам, связанным с питоновской библиотекой Scrapy и более 5000 лично написанных скрейперов, всего 1 раз столкнулся с тем, что не смог справиться с задачей извлечения контента без каких-либо вебдрайверов. Это был какой-то сайт с котировками, у них стояла защита от сервиса Incapsula (к которой, кстати, время от времени появляются способы обхода, но потом быстро выкатывается новая версия и приходится искать новые). На верхушку хит-парада защиты контента я бы поставил всякие каптчи (как сторонние, так и самодельные). На втором месте попытки шифровки запросов. Но поскольку эти шифровки делаются на клиенте, ничего не мешает прочитать сорс и сделать аналогичную шифровку у себя. Сложнее ли написать скрейпер к такому сайту? Несомненно. Сильно сложнее? Думаю, минут на 30 дольше. На 3-ем месте изощренное кунг-фу вроде того, каким владеет LinkedIn. Не представляю, сколько ресурсов эти ребята тратят на свои шаманские практики, но работают эти практики, признаюсь, очень хорошо, сделать стабильный и быстрый скрейпер их площадки — задача невероятной сложности.
Ну вот прям навскидку, что за пару секунд на ум пришло:
Залогиньтесь Scrapy сюда: secure.tesco.com/account/en-GB/login
Поскрапьте Scrapy это: www.tmdn.org/tmview/welcome
Количество это не всегда показатель опыта. Можно за 6 лет вырыть 5000 типовых индивидуальных окопов, но это не сделает инженером фортификационных систем.
К примеру с кроссовками могу добавить что я тем же способом приобрёл себе видеокарточку на сайте нвидии, когда из-за бума майнинга достать их было почти нереально. А так же лимитированную яндекс-колонку и когда-то отслеживал билеты ржд. До спекуляций правда не додумался, всё для личного использования ))
Если продавец не может сделать нормальный бэкордер или захочет поиграть с покупателями в странные ценовые игры, то к нему придут скрейперы )) И лучшая защита от них — улучшать user experience реальных пользователей.
Тот же акамаи, к примеру, может проверять порядок в котором присылаются header'ы и соответствие user-agent'у. При неправильном порядке запрос блокируется. Это конечно обходится, но тем не менее, как пример fingerprintg'a без js.
Если там REST API, в которое можно сходить чем угодно помимо браузера по задумке, то речь об обычной js инъекции не идет. Однако если там доступ токенизирован с ограничением предметной области — например, конкретное моб.приложение и браузеры — то все веселее. Для браузера уже понятно, как токен сгенерировать, а вот в моб.приложении модифицируется клиентская часть, для этого антиботчики дают свои SDK. У одного из решений можно вообще так капчу себе встроить в клиент (звучит дико, как по мне)
Эксплуатировать WebRTC leak это ходовой вариант, но и защититься от него несложно.
А вот обфускация и динамические перестановки действительно заставят повозиться тех, кто глазами и парсером смотрит JS и крафтит ответы. Однако динамика встречается нечасто по моим наблюдениям.
А ещё есть обычные пользователи, которых бесит попытка за ними следить, и которые этот ваш фингерпринтинг самостоятельно блокируют в самом обычном браузере: Умеренный Hardening для Firefox. Что опять же легко превратит борьбу с ботами в блокирование доступа честному покупателю.
P.S. Кстати говоря, буквально сегодня у меня был похожий случай. Несколько месяцев назад у меня почему-то перестал работать поиск на prom.ua (а-ля украинский амазон) — точнее, из результатов поиска не открывалась страница с товаром (выдавала 404). Из-за этого я раз 5 отказался от покупки, найдя товары через обычный поисковик на других сайтах. Но сегодня было "очень надо" купить именно через prom.ua, и я таки разобрался, в чём проблема. Отключение uBlock Origin, uMatrix и HTTPS Everywhere не помогло, что меня несколько озадачило — обычно дело в ком-то из них. Пришлось запускать Vivaldi (в котором всё работает) и сравнивать открывающиеся из результатов поиска url: оказалось, что файрфокс выкидывал из параметров запроса campaignId — работа плагина Neat URL. Пришлось добавить в Neat URL исключение специально для этого параметра на prom.ua, и всё снова заработало. Но дело в том, что я абсолютно уверен — этот параметр не является необходимым для открывания страницы товара из результатов поиска, так что виноватым в проблеме является вовсе не Neat URL, а жадность владельцев сайта к сбору посторонних данных о пользователях — что лишило их дохода от нескольких продаж в данном случае.
Метрики из Google Analytics могут помочь обнаружить скрейпинг, если он производится топорно, без попыток мимикрировать под человека. Во-первых, надо почистить метрики фильтрами (Exclude all hits from known bots and spiders), а затем можно искать аномалии в репортах: например, юзеры, которые открывают ровно 1 URL (не корень) и уходят, высокая скорость переходов и т.д. — по совокупности факторов неладное заметить можно невооружённым глазом.
Так что предотвратить — нет, обнаружить — чаще да, чем нет.
Что делать, если приехал скрейпер
А где вариант "расслабиться и получить удовольствие"?
Если кому-то сильно надо, он, не смотря на все Ваши супермегафингерпринты тупо посадит на задачу Amazon Mechanical Turk и будет иметь то, что "надо", за копейки так или иначе. Так зачем мучиться самому и мучить других?
Скрейперу понадобилось перебрать достаточно много поисковых запросов, и он из 200 RPS к этой локации сделал почти 700.
А если бы у вас был нормальный роботоориентированный API, то никто не пришёл бы к Вам скрейпить страницы (и зря тратить процессорное время на их рендеринг), ибо нафига? Обращались бы к API.
приходящие боты сгребают в корзину
Поэтому "сгребание в корзину" в нормальных магазинах на состояние остатков на складе никак не влияет — остатки уменьшаются только когда реально прошла оплата. А до тех пор — "кто не успел, тот опоздал" ©
С учетом того, что у сайта была посещаемость около 3 миллионов в день, представьте, что им еще сверху прилетает 24 миллиона запросов в день.
Ну вот смотрите, у них этого сайта есть выбор: либо эти 24 миллиона прилетают через стандартный web — то есть мало того, что выполнятся те же самые запросы, но сверх того ещё и фронтенд работает, оборачивая результаты в HTML, который на другом конце будет выкинут нафиг — либо 24 миллиона запросов прилетает через API (то есть с минимальной обработкой). Что Вы выбираете?
А на самом деле можно пойти ещё дальше. Что является целью "эффективных менеджеров"? Уж никак не нагружение Ваших серверов (они ведь тем самым и свои нагружают — парсингом улова) — им просто нужны самые свежие данные. Так дайте им то, что они хотят: просто добавьте в API поле "дать мне только то, что изменилось после такого-то таймстемпа" — и всё, передаются только диффы, миллионы резко испаряются. Кроме того, эффективным менеджерами можно доступ к этому API за, скажем, сотку баксов в месяц продавать — им это явно выгоднее, чем им платить эту же сумму производителям средств обхода защиты от скрейпинга (плюс ещё можно парочку своих программистов сократить), а Вам — лишняя прибыль.
Подумайте сами ещё раз: вот поняли Вы, что Вас скрейпят, пошли к программистам и поставили задачу — "схватить и не пущать". Программисты пожужжали и сделали. Знаете, что это означает? Что где-то далеко какой-то начальник пришёл к своим программистам и сказал: "У нас только что скрейпинг чего-то накрылся. Почините." Goto начало параграфа. В результате у программистов (то одних, то других, попеременно) мозги плавятся, у серверов процессоры дымятся, приближая глобальное потепление, и кулеры гудят, а пользы — никому и никакой от слова "совсем".
Ну вот смотрите, у них этого сайта есть выбор: либо эти 24 миллиона прилетают через стандартный web — то есть мало того, что выполнятся те же самые запросы, но сверх того ещё и фронтенд работает, оборачивая результаты в HTML, который на другом конце будет выкинут нафиг — либо 24 миллиона запросов прилетает через API (то есть с минимальной обработкой). Что Вы выбираете?
В моем случае уже было API.
А на самом деле можно пойти ещё дальше. Что целью «эффективных менеджеров»? Уж никак не нагружение Ваших серверов (они ведь тем самым и свои нагружают — парсингом улова) — им просто нужны свежие данные. Так дайте им то, что они хотят: просто добавьте в API поле «дать мне только то, что изменилось после такого-то таймстемпа» — и всё, передаются только диффы, миллионы резко испаряются. Кроме того, эффективным менеджерами можно доступ к этому API за, скажем, сотку баксов в месяц продавать — это явно выгоднее, чем им платить эту же сумму производителям средств обхода защиты от скрейпинга.
Ну там может резко возрасти количество желающих эти данные скачать или те, кто не захочет платить за апи 100 баксов, а будет парсить по бесплатному апи. Но в целом, мысль интересная, спасибо.
Работа разработчиков стоит денег, и довольно больших. Обеим сторонам! Поэтому и у владельца сайта и заказчика парсинга есть отличная финансовая мотивация найти такой баланс цены на API, который устроит всех — потому что это сэкономит деньги и тем и другим.
По моим наблюдениям, причиной этого не делать обычно является либо то, что владелец сайта наивно полагает, что любые парсеры возможно и не очень сложно заблокировать (и поэтому успевает вложить ресурсы в попытку это сделать, которые потом жалко выкидывать и он продолжает двигаться по этому пути уже из принципа), либо сайт вообще не имеет API и разрабатывать его чисто "ради чужих парсеров" выглядит для владельца дикой идеей.
и будет иметь то, что «надо», за копейки так или иначе
Такое обобщение не берет в расчет бизнес-модель коммерческих скрейперов. А она работает, когда в асимптотическом приближении (инструмент уже написан/куплен, стоимость модификации околонулевая, а кол-во заказов большое и растет) стоимость данных с одной обработанной странички в продаваемом датасете выше, чем накладные расходы: виртуалки, трафик, стоимость решения капчи, стоимость ручного труда + еще ряд менее очевидных параметров.
ибо нафига? Обращались бы к API.
Идея public API благородна, я бы хотел жить в мире, где у каждого ресурса с полезными данными было бы оно. К сожалению, что с коммерческим, что с бесплатным роботоориентированным интерфейсом бывает так, что ресурс начинают скрейпить и со страничек, и с API — каких-то данных не хватает, медиа и тд. Из того, что вы уважаете потребности своих юзеров, не следует, что они станут уважать ваши.
А до тех пор — «кто не успел, тот опоздал»
Здесь согласен. Однако пока не у всех ритейлеров работает такая модель, эти сценарии как были, так и продолжатся.
Такое обобщение не берет в расчет бизнес-модель коммерческих скрейперов.Что-то я этого параграфа не понял — сдаётся мне, Вы слишком витиевато изъяснились.
стоимость данных с одной обработанной странички в продаваемом датасете выше, чем накладные расходы:Это чисто проблема Вашего (владельца данных) ценообразования: хозяин скрейпера нашёл способ скрейпить их дешевле, чем Вы их ему продаёте. Снижайте цену — это рынок: «я хочу, чтобы эти данные стоили $XXXX» — он так не работает, вы должны предоставлять некое конкурентное преимущество (на выбор — цена, удобство, маски-шоу для нарушителей и т.п.) — иначе не купят.
Идея public API благородна, я бы хотел жить в мире, где у каждого ресурса с полезными данными было бы оно. К сожалению, что с коммерческим, что с бесплатным роботоориентированным интерфейсом бывает так, что ресурс начинают скрейпить и со страничек, и с API — каких-то данных не хватает, медиа и тд. Из того, что вы уважаете потребности своих юзеров, не следует, что они станут уважать ваши.Я что-то говорил про благородство, уважение, потребности и проч.? Здесь совершенно тупое взаимодействие двух акторов: владельца данных и скрейпера, далее чистая
- Владелец данных вынужден предоставлять их любому желающему (иначе пользователи ничего не смогут у него купить);
- Обычный (индивидуальный) пользователь хочет получить веб-страничку (с оформлением, рюшечками, UI и проч.) поодиночке и редко — но их (сравнительно) много;
- Скрейпер хочет получить голые данные (без оформления, рюшечек, UI и проч.) массово и часто — но их (сравнительно) мало;
- Отличить обычного пользователя от скрейпера в момент получаения (самого первого) HTTP-запроса невозможно (особенно с учётом того, что последний изо всех сил старается маскироваться).
Предполагаем, что количество доходящих до хозяину скрейперов при наличии защиты n меньше, чем без наличия защиты N (количество «пытающихся» при этом всё равно N, просто (N-n) не проходят сквозь защиту)
Хозяин имеет расходы:
- на сервера только с обычными пользователями — {$обслуживание обычных пользователей} (не детализируем, ибо оно одинаковое во всех случаях)
- на сервера со «скрейперной» нагрузкой — ({$обслуживание обычных пользователей} + {$обращений к БД для (x) скрейперных пользователей})
- на сервера со «скрейперной» нагрузкой и противоскрейперной защитой — ({$обслуживание обычных пользователей} + {$обращений к БД для n скрейперных пользователей} + {$UI для n скрейперных пользователей} + {$противоскрейперной защиты})
Скрейпер имеет расходы:
- противодействуя защите: {$аренду серверов обработки данных}(N) + {$вырезания UI}(N) + {$з/п разработчиков обхода защиты}
- не противодействуя защите: {$аренду серверов обработки данных}(n)
Таблица стратегий:
- Хозяин — защищаться, скрейпер — противодействовать:
- расходы хозяина: ({$обслуживание обычных пользователей} + {$обращений к БД для n скрейперных пользователей} + {$UI для n скрейперных пользователей} + {$противоскрейперной защиты})
- расходы скрейпера: {$аренду серверов обработки данных}(N) + {$вырезания UI}(N) + {$з/п разработчиков обхода защиты} — {$убыток от неполноты данных}
- Хозяин — защищаться, скрейпер — не противодействовать:
- расходы хозяина: ({$обслуживание обычных пользователей} + {$обращений к БД для n скрейперных пользователей} + {$UI для n скрейперных пользователей} + {$противоскрейперной защиты})
- расходы скрейпера: {$аренду серверов обработки данных}(n) + {$убыток от неполноты данных}
- Хозяин — не защищаться, скрейпер — (всё равно пытаться) противодействовать:
- расходы хозяина: {$обслуживание обычных пользователей} + {$обращений к БД для n скрейперных пользователей} + {$UI для n скрейперных пользователей}
- расходы скрейпера: {$аренду серверов обработки данных}(n) + {$вырезания UI}(n) + {$з/п разработчиков обхода защиты}
- Хозяин — не защищаться, скрейпер — не противодействовать:
- расходы хозяина: {$обслуживание обычных пользователей} + {$обращений к БД для n скрейперных пользователей}
- расходы скрейпера: {$аренду серверов обработки данных}(n)
В этот момент докладчик просто разводит руками и молчит, потому что оптимальная стратегия становится абсолютно очевидной любому, обладающему не то, что навыками чтения, а просто зрением.
то-то я этого параграфа не понял — сдаётся мне, Вы слишком витиевато изъяснились.
Постараюсь проще. Расходы на продвинутый скрейпинг могут быть совсем не копеечными, если данные нужно собирать помногу и регулярно, а не один раз из одного места для исследования или развлечения. Внезапно, миллион капч оборачивается порядка $700, аренда residential proxy — от $100/m и выше сообразно качеству. А это те инструменты, на которые скрейпера заставляет тратиться защита. А вы этого не учитываете.
Здесь совершенно тупое взаимодействие двух акторов: владельца данных и скрейпера, далее чистая теория игр
Не могу согласиться насчет «тупое». Есть масса факторов, которые находятся за пределами вашей платежной матрицы и могут заставить (и в реальной жизни заставляют) скрейпера не ходить в API или ходить не только в него:
- интерфейсы коммерческих ресурсов, что платные, что бесплатные (как Walmart Open API) имеют либо рейтлимит, либо лимит на общее число запросов с одного токена, и собрать датасет нужного размера не выходит. При этом такого рода ограничения на вебсайте (особенно рейтлимит) вводить опасно, его же еще и люди смотрят.
- В API может не оказаться данных нужного типа. Или они преобразовываются как надо на фронте, и под них нужно писать аналогичную трансформацию, что дольше, чем лишний раз бахнуть по сайту.
- Открыли API? А я собираю с десятков подобных сайтов, где API нет, у меня уже потрачено на инфраструктуру и техстек, теперь я могу скрейпить ваш сайт из обоих мест параллельно! :).
- Банальная лень и нежелание трогать то, что уже работает.
Этот список можно продолжить.
А это те инструменты, на которые скрейпера заставляет тратиться защита. А вы этого не учитываете.
Учитываю. Видите ли, эта тема мне крайне близка, и я с ней как бы не понаслышке. Если данные доступны человеку — они будут доступны роботу (пусть даже с применением "механических турков").
миллион капч оборачивается порядка $700,
… вот только Вы забываете, что, ставя капчу, вы сильно снижают конверсию реальных покупателей. Замечательный способ выстрелить себе в ногу.
имеют либо рейтлимит, либо лимит на общее число запросов с одного токена,
Повторюсь: если Вы со скрейпером не пришли ко взаимовыгодному решению — значит, Вы что-то делаете неправильно. Дайте мне конкретную проблему — я Вам дам конкретное решение. Часто скрейпят? Дайте возможность API отдавать только изменения. Всё равно скрейпят веб даже при наличии API? Узнайте, чего им не хватает в API и добавьте. И т.п. У скрейпа веба есть не нужный ни Вам, ни — главное — скрейперу, оверхед — следовательно, если они согласны на него тратиться, значит, они получают с него какое-то преимущество; дайте им это преимущество, но без оверхеда ни для них, ни для Вас — и все будут довольны.
В API может не оказаться данных нужного типа.
"А сейчас мы проезжаем мимо публичного дома." — "А ПОЧЕМУ???". Сделайте, чтобы оказались! Это значительно проще, чем ваять веб-страницу и наклёпывать на неё работающий антискрейпер (а там ещё false positives подтянутся, с соответствующими результатами для конверсии)
заставляют скрейпера не ходить в API или ходить не только в него
Эта проблема решается включением в API "того, чего не хватало". Что, повторюсь, проще, чем ваять веб-страницу для пользователя.
теперь я могу скрейпить ваш сайт из обоих мест параллельно! :).
"БуханкаТроллейбус.жпг" — НО ЗАЧЕМ??? Держать лишние инстансы, деньги на них тратить? Я что, идиот? Лучше очередной мерс куплю.
Банальная лень и нежелание трогать то, что уже работает.
Вы недооцениваете банальное бабло, которое побеждает зло — и даже лень.
- основной бизнес-задачей рассматриваемых в рамках доклада веб-ресурсов является не продажа публичных данных скрейперам, с которыми вы предлагаете «прийти к взаимовыгодному решению»;
- оценка действий скрейпера с позиции логики не всегда соотносится с реальностью. Как и договороспособность.
Приведу 2 примера из практики, которые иллюстрируют это:
- Скрейпер приходит на страницу сайта с авиабилетами и собирает перелеты, делая несколько млн запросов за час. При этом он собирает столько же уникальных данных, сколько бы он получил, делая порядка 20000 запросов за тот же час: частота обновления на ресурсе заведомо ниже частоты запросов к одной и той же позиции, и большинство ответов ему просто не нужны. Зачем он это делает? «Держать лишние инстансы, деньги на них тратить? Я что, идиот?» Нет, ему просто наплевать, пока не возникло защиты в этом месте, создание такой нагрузки была для него столь же дешевым.
- Сайт открыл свой API для поиска и листинга цен, там появился трафик, но нагрузка от скрейперов не снизилась. Причины: 1) скрейперам забыли позвонить и сообщить :) 2) в API пришла часть тех, кто раньше покупал у скрейперов собранные данные, сузив рынок сбыта, но не ликвидировав его 3) снова, скрейпить без защиты просто и дешево, поэтому отказываться от него ради API нелогично, наоборот, можно совместить одно с другим.
Оверхед на скрейпинг с веб-страниц, о котором вы говорите, существует в основном из-за наличия уже внедренных мер защиты. И на него согласны тратиться лишь оттого, что других вариантов собрать данные с такой же скоростью не предоставлено. API скорее помогает не скрейперам, а тем, кто от них больше всего страдает — юзерам, аффилиатам или партнерам, которым нужна интеграция функций одного сервиса в другой.
частота обновления на ресурсе заведомо ниже частоты запросов
Это известно Вам, но не тому, кто писал скрейпер. Он перестраховывается, так как не хочет пропустить изменения. Сообщите владельцу, что это бессмыссленно, сделайте endpoint с "номером версии данных", который будет инкрементироваться при обновлении — и лишние скрейпы уйдут.
скрейперам забыли позвонить и сообщить
и… чей это недостаток? Если лень звонить — измените немножко код страницы (что заставит разработчика скрейпера, выматерившись, пойти разбираться, чего это скрейпер перестал работать), вставив в него большой коментарий вида "Эй, разработчик скрейпера, не морочься, вот тут есть API" — и будет ЩАСТЬЕ
в API пришла часть тех, кто раньше покупал у скрейперов собранные данные, сузив рынок сбыта
… и теперь эти покупатели будут нести деньги не хозяину скрейперов, а напрямую Вам, чем это плохо?
скрейпить без защиты просто и дешево, поэтому отказываться от него ради API нелогично, наоборот, можно совместить одно с другим.
если скрейпят "и так и так" — значит, в API нет чего-то, что есть на странице; добавьте.
P.S. Если Вы ещё не поняли — это я Вам как этот самый разработчик скрейперов говорю. Правда, по счастью для Вас, мы работаем с американской индустрией. ;)
А как на счет сайт через OCR прогонять? Или ресурсоемко?
Хорошая статья. Но мне интересно как должен быть организован корректный, нежный и бережный скрейпинг?)
Пробовал даже через селениум — не спасло ситуацию. Даже вручную в браузере ходил вводить капчу (найти все велосипеды или зонты), сервис мне не верил :)
А путь с платным разгадыванием капчи не пригодился :)
P.S. Еще сталкивался когда нельзя было внутреннюю страницу посмотреть без родительской. Правильный реферер не помогал, видимо пользователя «вели» по сайту и логгировали все его запросы, создавая тем самым недопустимые для него переходы. Наверное
В примитивном варианте это поможет от скрейперов «запустил и забыл», которые, видимо, не собираются продавать свою работу, и на ее качество им плевать.
Угу, замечательный способ выстрелить себе в ногу — теперь вместо 20 миллионов запросов от скрейпера Вам будет приходить 120 (а потом скрейпящий будет сравнивать полученные копии одной и той же страницы, чтобы понять, какие из них истинные).
Не вижу смысла защищаться от парсинга, только от такого, который создает нагрузку(правильной настройкой rate-limit например)
Не до конца понимаю почему никто никогда не вспоминает о таких вещах как browsermob+selenium. Как детектить такие атаки? Обфускация css и js-ловушки уже не помогут.
На мой взгляд, потому что такие вещи требуют очень много ресурсов и создать ощутимую нагрузку на сайт с помощью них не получится. Поэтому смысла от них защищаться нет, толко лишнее время и деньги
Насчет ресурсов, поделюсь опытом, сделать миллион запросов в час, используя только голые http-запросы и одно ядро процессора i5 — не проблема. А сколько ресурсов потребуется headless-браузеру, чтобы организовать такое количество запросов? А учитывая, что там тяжелые сценарии, которые будут кушать вашу память и цпу на 1 запрос, а вам надо миллион?
Задача браузерных парсеров либо обходить сложные системы защиты, либо делать свою работу аккуратно и незаметно, в ущерб скорости. Для копитыринга и ему подобных задач, такие парсеры конечно используются крайне редко, из-за описанных вами минусов, но в условиях корпоративной автоматизации при отсутствии внешнего API — очень и очень часто. Особенно когда надо взаимодействовать со всякими госпорталами, у которых клиентская часть сгенерирована непонятно чем и работает непонятно как, где скорость в 2-4 задачи парсинга в минуту — это уже хороший результат, а когда пытаешься быстрее, то моментально руководство получает звонок с требованием больше так не делать, а то отвесят бан. Но, при этом, публичное API делать отказываются.
Сложно, дорого, в большинстве случаев решается введением платного API на доступ к тем же данным.
представим, что вы студент, завтра утром у вас защита курсовой работы, у вас по материалам «конь не валялся», не хватает ни цифр, ни выдержек, ни цитат — и вы понимаете, что за оставшуюся часть ночи перелопатить всю эту базу знаний вручную у вас нет ни времени, ни сил, ни желания.
Поэтому, по совету старших товарищей, вы расчехляете питоновскую командную строку и пишете простой скрипт, который принимает на вход URL’ы, ходит туда, загружает страницу, парсит контент, находит в нем интересующие ключевые слова, блоки или цифры, складывает их в файлик или в табличку и идет дальше.
Заряжаете в этот скрипт необходимое количество вам адресов научных публикаций, онлайн-изданий, новостных ресурсов — он быстро все перебирает, складывая результаты. Вам же остается только по ним нарисовать графики и диаграммы, таблицы — а на следующее утро с видом победителя получаете свой заслуженный балл.
Слушайте, это что у вас за студент такой, с какой специальности?? То есть, собрать скриптом курсовую за ночь так, чтобы препод не понял, что это тупая копипаста, он может, а написать её сам не в состоянии.
И где это оценку за курсовую ставят в этот же день?
Так, если человек делает исследование эволюции систем предупреждения столкновений воздушных судов и уже успел изучить их устройство, ключевые параметры и сделать нужные выводы, этого будет недостаточно без информации о самих инцидентах столкновений и их последствий, т.е. контекста, в котором работа по этому направлению ведется последние 50-60 лет. Как минимум, стоило бы раздобыть описание всех инцидентов за этот срок, категоризировать их и показать, какие из них были ключевыми для внедрения изучаемых технологий (как катастрофа в Гранд-Каньоне в 1956). Без такого анализа работа на эту тему будет, вероятно, воспринята в лучшем случае как проведенная небрежно, а в худшем — как откровенная халтура.
Это всего лишь пример, притом скромный по масштабу, т.к. крупных столкновений-катастроф с участием гражданской авиации всего меньше 100, и они уже заботливо разложены по табличках в вики-статьях и на профильных ресурсах. Но даже в его контексте вытащить, скажем, газетные заголовки из онлайн-архивов печатных изданий вручную достаточно долго и муторно.
Что касается оценок — по моему опыту, если кафедра принимала решение устраивать именно защиту курсовых работ (а не как обычно, сдача текста -> письмо на кафедру от н/р с рекомендованной оценкой -> проставление оценки), то оценки оглашались в тот же день.
Любая исследовательская работа, включая студенческие, требует поиска и изучения prior art/prior works, событий, упоминаний в медиапространстве и их значимости для выбранной сферы.Ещё раз повторю вопрос про специальность вашего гипотетического студента :) На курсовых технических специальностей нет слов «prior art/prior works, событий, упоминаний в медиапространстве».
вытащить, скажем, газетные заголовки из онлайн-архивов печатных изданий вручную достаточно долго и муторноА накидать скрипт на питоне, который распарсит кучу совершенно разношёрстных представлений это, отладить его, проверить результат это значит, быстро? :)) При том, что специальность не программирование?
по моему опыту, если кафедра принимала решение устраивать именно защиту курсовых работ (а не как обычно, сдача текста -> письмо на кафедру от н/р с рекомендованной оценкой -> проставление оценки), то оценки оглашались в тот же деньНаучный руководитель у простой курсовой? Это где так?
По помему опыту (с обеих сторон, кстати) курсовые сдавались на проверку, а через несколько дней была их «защита» в виде собеседования.
Ещё раз повторю вопрос про специальность вашего гипотетического студента :)
Пусть будет — сугубо гипотетически — 051311, математическое и программное обеспечение вычислительных машин, комплексов, и компьютерных сетей. Но с тем же успехом может быть и 010107, вычислительная математика, и какая-нибудь другая, где студентами ведется научная работа, и решаются задачи с использованием компьютера :)
На курсовых технических специальностей нет слов «prior art/prior works, событий, упоминаний в медиапространстве».
Это очень строгое отрицание, и оно, как мне кажется, неверно. Понятие prior art в контексте алгоритмов и исходного кода общеупотребимо. Поэтому, если вы, например, делаете работу об алгоритме собственной разработки, который решает какую-то задачу, без изучения prior art по своей тематике, упоминания релевантных разработок в обзорной части доклада и анализа их преимуществ/недостатков относительно этой задачи вряд ли ее воспримут всерьез. Я не берусь говорить, что «везде так» или «везде не так», однако вот выписка из одного из вузовских пособий по оформлению учебно-научных текстов:
«Назначение этой главы – дать более детальное и систематическое представление о существующих решениях рассматриваемой проблемы, чем это сделано во введении. <...> В идеале в обзорной главе должен быть дан сравнительный анализ известных подходов и вариантов решения проблемы...»
На моем опыте, учитывая, что первая курсовая у студента чаще не несет больших и важных научных инноваций, научное руководство повышенное внимание обращало на то, насколько тщательно студент изучил свою тему и собрал данные для обзорной части, особенно если он планировал в этой теме работать и дальше.
При том, что специальность не программирование?
А почему бы и да? Студенты фундаментальных научных дисциплин тоже изучают по программе ЯП и используют их в качестве инструмента, да и не только они. К тому же, как я говорил в докладе, гайдов и готовых сниппетов вокруг столько, что яблоку упасть негде.
Научный руководитель у простой курсовой? Это где так?
Как минимум, в МГТУ, МФТИ, МГУ это так, наверняка во многих других ВУЗах тоже, но я не берусь безоговорочно судить.
Угу, как я уже писал — замечательный способ сделать хуже самому себе. Или напроситься под роскомнадзор, если защита ошибётся (а ведь никто не застрахован!) и случайно покажет "плохие слова" обычному пользователю. Как говорится, "у каждой задачи есть простое, лёгкое, неправильное решение".
вывести публичное api по которому у вас смогут легко и безболезненно забирать данные в формате json, с постраничным выводом и описанием.
Web scraping вашего сайта: непрошеные гости и как их встречают