Хочется думать, что те, кто «поставил капкан», сделали это более грамотно, чем кажется на первый взгляд, и максимально исключили ложные срабатывания. И что защищать будут не только контент, но и данные, и репутацию доверившихся клиентов.
Допустим, это единственная защита и нет никаких скрытых кодов, внедренных в видео. Допустим также, что планируется подавать иски против пользователей, штрафовать или лишать доступа к контенту. Поскольку имея SID сфабриковать защиту не составляет труда, возникает два вопроса:
1. Насколько защищена база данных SID?
2. Как скоро после компрометации захлебнется карательная машина?
Подозреваю, что доказать свою невиновность в случае подделки подписи в подавляющем большинстве случаев будет ой как непросто.
Жаль, у меня пока нет задач, для которых действительно потребовалась бы вся мощь Scrapy (а было бы круто для приготовления холостяцкого ужина запустить промышленную установку по формированию пельменей — джастфофан).
Впрочем, думаю рано или поздно такие задачи появятся, и тогда советы придутся очень кстати.
Курсовая работа — это все таки образцово-показательное выступление. Я же только брался показать, что всего за один день, со скромными познаниями в пайтоне, еще меньшим опытом и без углубления в документации и мучительный выбор, что ставить — пробелы или табуляцию (я, кстати, сразу выбрал табуляцию, просто потому что быстрее им ошибок меньше в отступах) — вполне реально решить конкретную задачу, буде такая появится.
Спасибо за развернутые и полезные комментарии. Для того, чтобы узнать многое из описанного, потребовалось бы кипу всего перечитать. Например, сам никогда бы не задался вопросом, есть ли специальный модуль для записи CSV-файлов!
С кодировками вышла самая большая маета, осмыслить проблему логически не получилось и пришлось подбирать методом тыка. Наверное как раз из-за того, что в Python юникод != utf8.
С выносом XPath в конфиг все просто (кстати, да SQL я бы тоже вынес). Говорят, что человек, начинающий изучать два иностранных языка, путает слова и конструкции и только с опытом происходит надежное отделение двух языковых полей. Так и здесь: ХPath запросы, помещенные прямо в текст, отвлекали от кода. Кроме того, оказалось удобнее отделить написание python-кода, и отладку XPath. Охотно признаю, что опыт в том и другом сделает такое разделение избыточным.
По хранению в памяти согласен. Но в данной задаче памяти требовалось немного, а отлаживать отдельно парсинг и запись в файл показалось удобнее. На других объемах, разумеется, пришлось бы память экономить.
Пытаюсь осилить. Однако, тут вот какая штука. Scrapy — мощный фреймворк. Он облегчает решение стандартных задач, но и устанавливает рамки. И он не подходит для первого знакомства с парсингом для таких новичков как я. Причины просты:
1. Требуется время на изучение, чтобы понять, чем именно он упрощает решение задач и как.
2. Заранее неизвестны неочевидные ограничения, которые начнут всплывать на практике и уже после того, как затрачены усилия на освоение базы.
3. Количество различных примеров и разноплановой документации для простого инструмента в несопоставимое количество раз больше, чем для фреймворка.
4. Дополнительные библиотеки, необходимые для установки. Во-первых это масса возможностей сделать ошибку. Так, например, я пытался twisted поставить на Win с помощь easy-install и все вроде бы хорошо ставилось, вот только библиотека не нашлась. Может надо было просто пути прописать к каталогу scripts, а может действительно нужно ставить через msi, но процесс на время затормозился.
4. Дополнительные библиотеки. Неминуемы отсылки документации к возможностям библиотек и время на изучение особенностей их использования во фреймворке.
В частности, сейчас я знаю (благодаря доброму совету и чтению документации по Srapy), что смог бы переписать решение задачи с использованием фреймворка. Но в очереди следующие, для решения которых нужно выбирать инструменты с оглядкой на фреймворк. Как подвесить краулер сервисом windows? Возникнут ли какие-нибудь особенности, если нужно записать данные не в файл, а в документ через API Google Docs? Можно ли вызывать Srapy из кода, а не из командной строки?
Есть и другие смутные вопросы, ответы на которые есть смысл искать, погрузившись в Srapy по самые гланды.
В любом случае, Srapy попробую. Спасибо за наводку!
Прежде всего, решением задачи. lxml дал самый быстрый отклик в плане работающего примера. Тут наверное нужно пояснить. До этого я писал полноценный скрипт на python только один раз (не считая всяких «hello world»), сам язык знаю плохо и потратил на решение задачи минимум времени (написание и отладку кода, копание в документации, сравнение различных инструментов). То есть то, что не заработало сразу или требовало длительного изучения, я отбрасывал сразу.
Смысл статьи именно в том и состоит — не похвалиться кодом, не выбрать наилучшие инструменты, а показать столь же неискушенным в теме читателям, как я, что написать работающий парсер от начала и до конца на пайтоне и с применением перечисленных средств без предварительной подготовки (изучения питоник-стиля, чтения букварей и массы документации) действительно просто. И это — лучшая реклама пайтону и использованным инструментам. Но это слова о статье.
Что касается выбора средств, то они диктовались рамками задачи. Ту же самую работу можно было без всякого программирования проделать вручную за два, много два с половиной дня. Потратить то же время на изучение различных мнений и чтение мануалов заманчиво, но при этом далеко не факт, что в результате пепелац взлетит. Словом, не обладая обширными базовыми знаниями и чутьем практика, вкладывать силы в глубокое предварительное изучение каждой претендующей на использование технологии — расточительно, когда речь идет об автоматизации решения конкретной задачи.
Что касается lxml, то он оказался простым, эффективным в плане гибкости применения, хорошо и с разных сторон документированным инструментом.
1. Насколько защищена база данных SID?
2. Как скоро после компрометации захлебнется карательная машина?
Подозреваю, что доказать свою невиновность в случае подделки подписи в подавляющем большинстве случаев будет ой как непросто.
Жаль, у меня пока нет задач, для которых действительно потребовалась бы вся мощь Scrapy (а было бы круто для приготовления холостяцкого ужина запустить промышленную установку по формированию пельменей — джастфофан).
Впрочем, думаю рано или поздно такие задачи появятся, и тогда советы придутся очень кстати.
Узнал много нового и полезного, как из комментариев, так и благодаря им. Жаль, что не могу проголосовать, не ожидал, что время голосования истекает.
С кодировками вышла самая большая маета, осмыслить проблему логически не получилось и пришлось подбирать методом тыка. Наверное как раз из-за того, что в Python юникод != utf8.
С выносом XPath в конфиг все просто (кстати, да SQL я бы тоже вынес). Говорят, что человек, начинающий изучать два иностранных языка, путает слова и конструкции и только с опытом происходит надежное отделение двух языковых полей. Так и здесь: ХPath запросы, помещенные прямо в текст, отвлекали от кода. Кроме того, оказалось удобнее отделить написание python-кода, и отладку XPath. Охотно признаю, что опыт в том и другом сделает такое разделение избыточным.
По хранению в памяти согласен. Но в данной задаче памяти требовалось немного, а отлаживать отдельно парсинг и запись в файл показалось удобнее. На других объемах, разумеется, пришлось бы память экономить.
1. Требуется время на изучение, чтобы понять, чем именно он упрощает решение задач и как.
2. Заранее неизвестны неочевидные ограничения, которые начнут всплывать на практике и уже после того, как затрачены усилия на освоение базы.
3. Количество различных примеров и разноплановой документации для простого инструмента в несопоставимое количество раз больше, чем для фреймворка.
4. Дополнительные библиотеки, необходимые для установки. Во-первых это масса возможностей сделать ошибку. Так, например, я пытался twisted поставить на Win с помощь easy-install и все вроде бы хорошо ставилось, вот только библиотека не нашлась. Может надо было просто пути прописать к каталогу scripts, а может действительно нужно ставить через msi, но процесс на время затормозился.
4. Дополнительные библиотеки. Неминуемы отсылки документации к возможностям библиотек и время на изучение особенностей их использования во фреймворке.
В частности, сейчас я знаю (благодаря доброму совету и чтению документации по Srapy), что смог бы переписать решение задачи с использованием фреймворка. Но в очереди следующие, для решения которых нужно выбирать инструменты с оглядкой на фреймворк. Как подвесить краулер сервисом windows? Возникнут ли какие-нибудь особенности, если нужно записать данные не в файл, а в документ через API Google Docs? Можно ли вызывать Srapy из кода, а не из командной строки?
Есть и другие смутные вопросы, ответы на которые есть смысл искать, погрузившись в Srapy по самые гланды.
В любом случае, Srapy попробую. Спасибо за наводку!
Смысл статьи именно в том и состоит — не похвалиться кодом, не выбрать наилучшие инструменты, а показать столь же неискушенным в теме читателям, как я, что написать работающий парсер от начала и до конца на пайтоне и с применением перечисленных средств без предварительной подготовки (изучения питоник-стиля, чтения букварей и массы документации) действительно просто. И это — лучшая реклама пайтону и использованным инструментам. Но это слова о статье.
Что касается выбора средств, то они диктовались рамками задачи. Ту же самую работу можно было без всякого программирования проделать вручную за два, много два с половиной дня. Потратить то же время на изучение различных мнений и чтение мануалов заманчиво, но при этом далеко не факт, что в результате пепелац взлетит. Словом, не обладая обширными базовыми знаниями и чутьем практика, вкладывать силы в глубокое предварительное изучение каждой претендующей на использование технологии — расточительно, когда речь идет об автоматизации решения конкретной задачи.
Что касается lxml, то он оказался простым, эффективным в плане гибкости применения, хорошо и с разных сторон документированным инструментом.