/ фото Sistema Bibliotecario Vimercatese CC

Практически каждая крупная организация нанимает в свой штат разработчиков программного обеспечения. При этом только треть из них заняты непосредственно в бизнесе, связанном с ИТ. Но вне зависимости от того, где они работают: в фармацевтической компании, образовательной или рекламной сферах, они остаются программистами.

Работа в команде – ответственное занятие, поскольку в этом случае люди отвечают не только за себя, но и за окружающих, они общаются, помогают друг другу. Как бы это ни было банально, ключом к продуктивному общению между людьми всегда является вежливость и взаимоуважение. Однако все же есть определенный список фраз, которые – даже когда они звучат вежливо и корректно – не стоит употреблять в разговоре с разработчиками и тестировщиками, если вы их коллега, заказчик, «владелец» или руководитель проекта.

Это уже четвёртая статья в цикле про веб-скрейпинг при помощи Node.js:

1. Web scraping при помощи Node.js
2. Web scraping на Node.js и проблемные сайты
3. Web scraping на Node.js и защита от ботов
4. Web scraping обновляющихся данных при помощи Node.js

В прошлых статьях были рассмотрены получение и парсинг страниц, рекурсивный проход по ссылкам, организация и тонкая настройка очереди запросов, анализ Ajax-сайтов, обработка некоторых серверных ошибок, инициализация сессий и методы преодоления защиты от ботов.

В этой статье разбираются такие темы, как веб-скрейпинг регулярно обновляющихся данных, отслеживание изменений и использование облачных платформ для запуска скриптов и сохранения данных. Ещё внимание уделяется разделению задач веб-скрейпинга и обработки готовых данных, а также тому, чего стоит избегать при работе с обновляющимися сайтами.

Цель статьи – показать весь процесс создания, развёртывания и использования скрипта от постановки задачи и до получения конечного результата. Как обычно, для примера используется реальная задача, какие часто встречаются на биржах фриланса.

Современный мир ПО очень черно-бело разделён на два лагеря: либо ты opensource-приложение, либо закрытое проприетарное. Нет, есть, конечно, и разные лицензии в открытых проектах и какие-то подвижки закрытых продуктов выкладывать в опенсорс свои части (привет, Google, Facebook, Microsoft). Но всё это не меняет сути дела в принципе — если ты берёшь открытый продукт, то видишь всё, что у него внутри, можешь это оценить и решить, стоит связываться или нет. Если ты хочешь приобрести закрытое ПО, то всё, что остаётся — верить заливающимся соловьями продажникам фирмы-производителя, как у них там всё внутри классно, надёжно, быстро и современно. Ну, вы наверняка были на какой-нибудь такой конференции или презентации, где выходил человек в костюме и час втирал о том, как же всё стало лучше в версии 18.1.1 их продукта и почему его нужно покупать прямо сейчас. Ещё часто можно недельку погонять ограниченный trial-режим, что даст ответ ровно на 1 вопрос: «как работает ограниченный trial-режим в течение недели?». Покупатель всегда остаётся один-на-один с решением «взять и рискнуть» или «не связываться». Объективных данных для принятия решения мало. При этом их, казалось бы, больше и не станет — производитель закрытого продукта не выложит исходники, поскольку именно они составляют коммерческую ценность.

Казалось бы — тупик? А давайте рассмотрим следующую мысль — что если мы потребуем предложим производителю выложить в открытый доступ тесты на его ПО? Все, что есть — юнит, интеграционные, производительности, другие. При этом производитель и потенциальный покупатель получают ряд преимуществ.