Зачем вы вырываете цитаты из контекста? Про уважение к своему труду в статье тоже написано. Не вижу ничего плохого, чтобы аболютно бесплатно поработать ради получения опыта. Я же не советую всю жизнь задарма работать, сделать пару проектов бесплатно или за минимальную цену, а потом уже, имея минимальный опыт общения с заказчиками начинать эксперементировать с ценой на свой труд.
Я больше хотел сделать акцент на том, что браться то можно, только надо предупредить заказчика и сказать ему, я не способен оценить сроки т.к. раньше не делал этого. Чудеса ведь могут произойти, а могут и не произойти. Хотя, конечно, молодому фрилансеру проще поверить в чудо :)
Таки я писал про дикие джунгли фриланса, где новорожденные фрилансеры сталкиваются с такими же новорожденными заказчиками :) Если у вас 10 лет опыта, то у вас свои правила игры, своя репутация, которую вам нет смысла портить.
> Мы на фрилансе уже больше 10 лет работаем и есть железнейшее правило — пока весь проект по ТЗ не доделан — конечный заказчик по проекту ничего не видит.
Если честно, слабо представляю, как такое возможно. Как заказчик соглашается не получать никаких данных по прогрессу проекта. Почему он согласен просто ждать, а не тестировать промежуточные версии. А что вы делаете такое?
Я бы вообще не советовал начинающим фрилансерам брать задание, которое потребует больше недели на выполнение. Если работать в одиночку, то большие шансы неправильно оценить сроки или наломать серьёзных дров.
Ага, не надо зацикливаться на деньгах, но и прибедняться не стоит. Творить, играть, эксперементировать, не бояться что-то потерять. Мысль, что деньги не главное, — это стратегия. А мысль, что не просить совсем мало, — это тактика скорее. Можно и за «мало денег» поработать, если это даст опыт и связи. Главная мысль статьи показать начинающему фрилансеру, что у него есть права и ответственность и он сам волен выбирать путь развития.
Спасибо. Есть и приятные примеры. Вон парни, которые пилят scrapy, какой-то стартап замутили связанный с запуском scrapy-пауков — инвестирования собирают.
> Имхо, универсальные решения слишком много ресурсов требуют на разработку. И если их пилить, то на постоянке. Напилить группу парсеров каждый из которых решает свою задачу, как показывает мой опыт, проще, в том числе и на будущем сапорте кода.
У меня несколько более глобальная задача. Содать универсальное решение, создать community-вокруг него. Сделать экосистему для библиотеки и компании grablab, которая занимается парсингом сайтов.
> Центральная нода оправляет на любую из подчиненных задание скачать начальную страницу, выдергивает из её контента ссылки на подкатегории первого уровня и оправляет задание на рекурсивное скачивание подчиненным.
Так это и есть синхронизация, особый слой архитектуры. Т.е. центральная нод должна определить какая из но свободна, дать ей задание, потом когда нода пройдёт вниз по дереву, то она опять станет свободна и центральная нода должна узнать об этом. Плюс надо данные с нод забирать, объединять.
> Причем подраздел только на одну ноду, т.е. один подраздел не может скачиваеться двумя нодами.
Я разрабатываю универсальное решение — у сайта вообще не может быть структуры, самого сайта не может быть, может быть просто список ссылок например или на сайте может не быть разделов. Что угодно может быть.
Не знаю, я вообще не люблю декораторы использовать, как-то уродливо выглядят. В данном случае декоратор будет бесполезен т.к. функция-обработчик может yieldить результаты разных типов для которых нужны разные обработчики.
Я в граб в начале одну сущность сделал, впрочем она и сейчас есть, но оказалось что она ненужная. Можно из функци-обработчика сделать не yield Task(name), а yield Data(name) (ещё один спецкласс) и тогда Spider вызовет функцию `def data_` в которой можно сохранить куда-надо данные. Возможно при разработке многоядерной-многомшинной архитектуры это подходет будет более важен, а пока можно прямо из любого обработчика ответа сохранять данные, что как-то проще, чем ещё дополнительные функции городить.
Очередь есть, но пока она как просто хранилище заданий в памяти работает. Если вынести очередь в какой-нить мемкэшед или редис, то уже по идее с некоторыми предосторожностями можно запустить несколько спайдеров. Ну, это один из будущих шагов рефакторинга. Выделения очереди как отдельного слоя архитектуры и различные бэкенды для очереди.
Один процесс — одно ядро. Чтобы работал на нескольких ядрах, одного желания мало. Надо ещё писать код, который будет синхронизироать работу нескольких процессов.
Неа, пока каких-то инструментов для сравнения нету. Библиотека пишется спонтанно. Естественно, если вы будете писать своё решение, то будучи заточенное под задачу он будет быстрее Grab работать.
Пожелания по железу. Используя асинхронность вы скорее всего упрётесь раньше в CPU или жёсткий диск или в канал. Также учтите что для парсинга Grab использует только одно ядро.
> Мы на фрилансе уже больше 10 лет работаем и есть железнейшее правило — пока весь проект по ТЗ не доделан — конечный заказчик по проекту ничего не видит.
Если честно, слабо представляю, как такое возможно. Как заказчик соглашается не получать никаких данных по прогрессу проекта. Почему он согласен просто ждать, а не тестировать промежуточные версии. А что вы делаете такое?
У меня несколько более глобальная задача. Содать универсальное решение, создать community-вокруг него. Сделать экосистему для библиотеки и компании grablab, которая занимается парсингом сайтов.
Так это и есть синхронизация, особый слой архитектуры. Т.е. центральная нод должна определить какая из но свободна, дать ей задание, потом когда нода пройдёт вниз по дереву, то она опять станет свободна и центральная нода должна узнать об этом. Плюс надо данные с нод забирать, объединять.
> Причем подраздел только на одну ноду, т.е. один подраздел не может скачиваеться двумя нодами.
Я разрабатываю универсальное решение — у сайта вообще не может быть структуры, самого сайта не может быть, может быть просто список ссылок например или на сайте может не быть разделов. Что угодно может быть.
Пожелания по железу. Используя асинхронность вы скорее всего упрётесь раньше в CPU или жёсткий диск или в канал. Также учтите что для парсинга Grab использует только одно ядро.