Использование ContextManager - это не костыль, а едиснтвенно верный способ в понятиях языка pyhton сделать принудительное освобождение ресурсов.
"Явное лучше неявного" (c)
Как видно из сообщений саппорта, ответа от них добиться невозможно, а информация в ФАК не соответствует истине.
Остаётся только одно: сделать масштабируемые чекеры по IP/приложения, получать оповещения о том что стала показываться капча и иметь возможность на это оперативно реагировать. План максимум — пытаться автоматизировать этот процесс.
Тем более что эти «неизвестные» ограничения могут ужесточиться в будущем, по-этому как ни крути — надёжи нет.
Отлично, пытался поискать единую категорию для профилей людей в википедии — но так и не нашёл
А в категориях, типа «русские политика» там фотографий мало, и есть далеко не у всех
Спасибо!
Хорошо, когда соберу информацию по актёрам с imdb — обязательно поделюсь.
Цели я описал в вопросе, точная привязка данных из ФСИН к фотографии совершенно не нужна, нужны некоторые характеристики для классификации
Да, про фотохостинги не подумал
Посмотрел, по поиску там тоже очень много фотографий, которые не подходят по критериям
Поиск по нему через google даёт лучшие результаты — goo.gl/jUxN8
Согласен.
Сложно, но варианты «покрывать код тестами» для заказчика, который не в курсе, что такое система контроля версий — совет ещё тот.
Поддержка, а особенно передача проекта — всегда дорогая операция, это без вариантов.
Если «прошлый программист» говорит, что закончил на 80%, это 1) не значит что он закончил на 80% 2) даже в идеальной ситуации с идельным кодом и проф.разработчиками затраты вновь пришедшего разработчика будут гарантированно выше 20%.
И что это за пурга:
>«как бы написать идеальный по моему мнению код», а не «как получить максимум прибыли с минимумом затрат».
1. это избитое клише, которое нельзя применять ко всем
2. разработчик, который пришёл дорабатывать проект по правилам рынка скорее заботится о своей «максимальной прибыли при минимуме затрат.»
Так что, если проекту потребуется поддержка, будут новые версии, нужно заручаться «правильных разработчиков», что б если даже что то с долгосрочным сотрудничеством случится, сложность передачи кода проекта свести к минимуму.
Тем более, что если качаем и парсим с одинаковой скоростью(а этого можно добиться добавив скачку в несколько потов) — то на кой передавать данные и терять производительность.
Я вижу в решении передавать страницы через rabbitmq одни усложнения: минусы отладки, усложнения архитектуры, увеличение времени разработки, несколько типов обслуживающих серверов которые надо по разному настраивать и развёртывать,… а плюсов, кроме «сокрытия реализации парсилки от качалки» нет. Но так как «скачать страницу» — это достаточно простое действие — плюс кажется не очень то и большим.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
"Явное лучше неявного" (c)