Ну кол-во страниц всё же, по моему мнению, почти не влияет на сложность парсинга. А вот свойства и сложная структура и самое интересное — защита — это да согласен. Но таких задач я не видел в свободном доступе. Только по знакомству перепала задачка Яндекс.Маркет парсить, вот это интересно было.
* я не пишу код на заказ, работаю только по проектам, где на выходе статические данные типа CSV, XML, дамп базы т.е. люди, которые хотят запустить код на своём сервере — это не мои клиенты
Тут я вас понимаю, да и хороший код отдавать за 500 рублей временами обидно.
* я не предоставляю услуги по импрту данных куда бы то ни было, если человеку надо спарсенные данные запихать в магазин, вордпресс, DLE или ещё куда — это не мой клиент
Да я не жалуюсь — уже есть круг людей у которых периодически беру заказы, просто для меня фриланс — это не полноценный вид заработка. Да и новые заказчики — это новые идеи, мысли, задачи.
Таких зачастую видно сразу и можно вежливо посылать их. Если вам выносят мозги на весь день, тем более за 500 рублей, значит вы что-то неправильно делаете. Повысьте планку минимальной цены за заказ, количество неадекватов убавится.
К сожалению, не всегда, получается, определить с кем будут проблемы, а с кем нет, просто бывали разные случаи. Как то работал с девушкой, которая вначале казалась неблагонадёжной. В конечном итоге всё оказалось супер, и уже как-то временами, не часто, но от неё бывают маленькие заказы. Так что раз на раз не приходится.
Это неблагодарная работа, я считаю. Подчищать баги за другими.
Мне это нравится, я работаю 3 года один, а работая с чужими самописами, можно чего-нибудь интересное узнать.
Например, вот такую форму записи, в принципе банально и понятно, до сам бы я не додумался наверное до такого, что бы в 1 строчку и красиво:
Сложный парсинг это какой? Яндекс.Маркет, avito, auto.ru или что?
Я обычно всегда откликаюсь на мелкие правки в php самописах, парсеры и т.п. Вот тут, по опыту, если ответил не в течении пару часов после размещения заказа, шанс что тебе хотя бы Заказчик ответил — мал. Конкуренция огромная — видимо ни я один тащусь от написания парсеров :)
Вот пример, что описал выше, eventclick который. Там задача была спарсить товары с сайта кондиционеров с картинками — наименований не много, в районе одной тысячи(или пару сотен, уже не помню, но не суть).
Задача, в среднем, как понимаете, плёвая — час работы с общением, если клиент нормальный.
Вылилось это в квест игру на 4 часа.
Общение велось сначала на Фрилансиме, через комментарии к заказу( хотя свои контакты я всегда всем оставляю в первом же отклике). Я быстренько сделал работу, захожу ответить, а заказ выдаёт 403 ошибку(или что то похожее) — заказчик снял заказ с сайта. Я пишу в саппорт Фрилансима, объясняю суть проблемы. Они вошли в моё положение и выслали мне email с которого был зарегистрирован аккаунт заказчика(огромное им спасибо, кстати, и оперативно и помогли решить проблему).
Дальнейшее общение уже было по этому email. В конечном итоге, я выслал результат после пары мелких замечаний, после чего заказчик хотел что бы я ещё кое-что подправил, я отказал, мотивировав это словами. «заплатите за это, а там за отдельные деньги проговорим доп. работы». Заказчик спросил кошелёк и исчез :)
Ну, я сам из Питера. У меня сейчас цена, которую я считаю для себя комфортной — 500 рублей в час. Но не всегда получается такие заказы находить. Уж слишком большая конкуренция из СНГ и регионов. Либо просто такая у меня ниша на фрилансе.
Подрабатываю на фрилансе, наверное, года 3. В основном заработать на интернет и телефон ну и что бы как-то разрядить рабочие будни. Т.е. пару тысяч в месяц. Т.е. мелкие задачи типа парсеров, правок и т.п. Но бывало и что то крупное.
Так вот всегда работаю с оплатой по факту, иначе лично у меня теряется интерес к работе, напрочь.
Кинули всего 2 раза, оба раза по 500 рублей.
Первый раз, 16-17 летний парень из Эстонии, которому надо было поставить на хостинг одну браузерную он-лайн игру.
Второй раз, человек из eventclick.ru, если верить их портфолио не шарашкина контора.
Если в первом случае было даже не обидно, то во втором случае я желаю им что бы их тоже кто кинул :)
Единственное что мне очень не нравится в заказчиках, так то, что есть отдельные индивиды, которые за задачку в 500 рублей могут вынести мозг на весь день. Вот реально, если вы идёте на фриланс и ищите себе исполнителя, может быть вы сначала определитесь чего вы конкретно хотите?
Нет. По моему мнению, «пила» у мечети ярко выражена, потому что голосов с сайта почти не поступало. А у кремля на сайте побольше голосовало, что и сглаживало зубцы.
Собственно поэтому, мне кажется, линии и идут почти параллельно, потому что смс шлюз захлёбывался и если и выдавал, то выдавал одинаковое кол-во смс голосов.
Так что обвинение ОпСоСов в том что они специально что-то там портили для меня является популизмом и не более.
file_get_contents может бросить варнинг и по другой причине, но Вы об этом не узнаете.
preg_match может бросить варнинг, но Вы об этом не узнаете.
mysql_query может бросить варнинг, но Вы об этом не узнаете.
ну и конечно же любой нотис будет преобразован в исключение и Вы снова об этом не узнаете.
Поймите, мне и не надо об этом знать, в данной конкретной ситуации, если поменяется вёрстка или mysql сервер упадёт или url будет вообще стал валидный я и так об этом узнаю по графику. Я не утверждаю, что, так как я написал — единственно правильное решение. Но в моей ситуации, для меня, я считаю, что написал верно, и пока не увидел у вас весомых аргументов, которые бы пошатнули эту мою уверенность.
ВГТРК не знает что Вы используете. Разница только в заголовках (юзер-агент в частности). Я бы использовал curl, т.к. не надо городить с обработкой ошибок.
Именно, разница в заголовках. Не посылается не user agent, не referer, не cookie. Первое что делают когда делают защиту от парсинга, отсекают всех у кого пустой user agent. По крайней мере об этом говорит моя практика.
Согласен. Но зачем создавать json, который в память не влазит? Я, типа, сгенерил и память сэкономил, а клиент пусть загружает его как хочет?
Вот это единственный момент, который я действительно пропустил, спасибо!
Вам не кажется, что вы сильно всё усложняете, я сам парсер написал минут за 15, в конечном итоге он без проблем проработал всё это время, снабжая интересующими меня данными. Разве не скорость написания, надёжность и быстрота работы являются одними из важных критерий, по которым можно и, даже не побоюсь этого слова, нужно оценивать работу программы? А вообще, это, наверное, хороший пример принципа KISS.
Давайте, если у Вас есть возможность и свободное время, Вы напишите пример, как бы Вы сделали парсер, который делает то же самое и сравним их по количеству строк кода, скорости работы и времени за которое вы его написали.
Собственно, инвайт на Хабрахабре я и захотел получить, ради хорошего спора с коллегами, потому что уже три года работаю единственным программистом в веб-студии и остро нуждаюсь в общении по профессии, ведь как известно, в споре рождается истина.
Вы ошибаетесь, я на PHP программирую уже шестой год.
Про список того что вы написали, скажу следующее, в принципе часть советов(1, 3, 4) правильна, но не в моём случае.
1. Данная конструкция с
set_error_handler('handleError');
и пустым блоком catch
Была нужна что бы не было Warning ошибок когда удалённый сервер отдаёт 404. (file_get_contents вместо тогоже cUrl был выбран исключительно для того что бы морально оправдать парсинг. Раз ВГТРК не банит такие запросы, то они не простив парсинга).
Знаете способ элегантнее и проще? Поделитесь. Не было бы её, то в перспективе у меня бы мог лог ошибок разрастись и занять всё свободное место на HDD( не забываем что цель была в ограниченных ресурсах всё это запускать, и кстати, в конечном итоге всё отработало супер и полторы недели парсинга и «хабраэффект» почти не отобразилось на работе сервера).
2. В данном случае preg_match для меня намного проще. Для более сложного, в плане логики, парсинга, я предпочитаю использовать PHP Simple HTML DOM Parser. Но ради интереса надо будет попробовать сравнить в конкретно этом случае производительность DOMXPath и preg_match по потреблению памяти и скорости работы.
3. В моём случае мне нечего экранировать. Вообще конечно совет новичкам обязательный, все грешат по началу SQL инъекциями.
4 и 5. Ну очень сомнительный совет. Простите, это для меня даже прямо таки вредный совет.
Делать надо так что бы запустил и забыл а оно само работает. Мой код мог бы спокойно работать очень долго и объём требуемой для работы ОЗУ был бы всегда одинаковым.
А в случае который вы мне предлагаете, мне надо было бы сначала создать массив с данными в ОЗУ, затем из него сделать json строку, удалить массив и всю эту строку записать через file_put_contents. И чем больше было бы в БД записей то тем больше он будет кушать ОЗУ и следовательно кончиться тем что отвалиться с PHP Fatal error: Allowed memory size of… :)
Если честно, не вижу никакого криминала. Вполне нормальный пик. Нормальная форма.
Вполне может объяснятся вбросом призыва голосовать на каком нибудь посещаемом ресурсе.
Если вы это мне, то я просто показал интересные моменты на графике, что бы статья покрасивее была. Просто на момент написания статьи, это был наверное один из интересных моментов.
Хотя, конечно, это блекнет по сравнению с 2 миллионами за пол часа в последний день голосования.
Ага. Если в цифрах, то примерно в ситуации с ТОП 2, получается:
32 421 805 голосов через смс, это 10 807 268,33 смс или примерно 38 041 584,53 рубля
37 141 324 голосов через смс, это 12 380 441,33 смс или примерно 43 579 153,49 рубля
Колоссальный прирост голосов за последние сутки у меня вызывает недоумение: как будто акция какая-то была…
У меня на графиках, к сожалению, только общее кол-во без дробления на смс и сайт(голосовать можно было и через смс и через сайт, хотя данные я сохранил и те и другие). Тогда было бы видно, что в основном, последний день голосования — это смс. А так даже в новостях есть, что большие проблемы были с добавлением смс из-за наплыва желающих.
Меня больше интересует за что там 700к голосов сняли 29 августа в 22:40…
И удивляет отсутствие Красной Площади среди кандидатов.
Я с вами согласен, но, вроде бы это специально сделано:
Тут я вас понимаю, да и хороший код отдавать за 500 рублей временами обидно.
В этом я с вами солидарен!
К сожалению, не всегда, получается, определить с кем будут проблемы, а с кем нет, просто бывали разные случаи. Как то работал с девушкой, которая вначале казалась неблагонадёжной. В конечном итоге всё оказалось супер, и уже как-то временами, не часто, но от неё бывают маленькие заказы. Так что раз на раз не приходится.
Мне это нравится, я работаю 3 года один, а работая с чужими самописами, можно чего-нибудь интересное узнать.
Например, вот такую форму записи, в принципе банально и понятно, до сам бы я не додумался наверное до такого, что бы в 1 строчку и красиво:
$id = max(0, isset($_POST['id']) ? (int)$_POST['id'] : 0);А от написания парсеров я тащусь, это можно сказать, моё хобби небольшое.
Я обычно всегда откликаюсь на мелкие правки в php самописах, парсеры и т.п. Вот тут, по опыту, если ответил не в течении пару часов после размещения заказа, шанс что тебе хотя бы Заказчик ответил — мал. Конкуренция огромная — видимо ни я один тащусь от написания парсеров :)
Задача, в среднем, как понимаете, плёвая — час работы с общением, если клиент нормальный.
Вылилось это в квест игру на 4 часа.
Общение велось сначала на Фрилансиме, через комментарии к заказу( хотя свои контакты я всегда всем оставляю в первом же отклике). Я быстренько сделал работу, захожу ответить, а заказ выдаёт 403 ошибку(или что то похожее) — заказчик снял заказ с сайта. Я пишу в саппорт Фрилансима, объясняю суть проблемы. Они вошли в моё положение и выслали мне email с которого был зарегистрирован аккаунт заказчика(огромное им спасибо, кстати, и оперативно и помогли решить проблему).
Дальнейшее общение уже было по этому email. В конечном итоге, я выслал результат после пары мелких замечаний, после чего заказчик хотел что бы я ещё кое-что подправил, я отказал, мотивировав это словами. «заплатите за это, а там за отдельные деньги проговорим доп. работы». Заказчик спросил кошелёк и исчез :)
Так вот всегда работаю с оплатой по факту, иначе лично у меня теряется интерес к работе, напрочь.
Кинули всего 2 раза, оба раза по 500 рублей.
Первый раз, 16-17 летний парень из Эстонии, которому надо было поставить на хостинг одну браузерную он-лайн игру.
Второй раз, человек из eventclick.ru, если верить их портфолио не шарашкина контора.
Если в первом случае было даже не обидно, то во втором случае я желаю им что бы их тоже кто кинул :)
Единственное что мне очень не нравится в заказчиках, так то, что есть отдельные индивиды, которые за задачку в 500 рублей могут вынести мозг на весь день. Вот реально, если вы идёте на фриланс и ищите себе исполнителя, может быть вы сначала определитесь чего вы конкретно хотите?
Собственно поэтому, мне кажется, линии и идут почти параллельно, потому что смс шлюз захлёбывался и если и выдавал, то выдавал одинаковое кол-во смс голосов.
Так что обвинение ОпСоСов в том что они специально что-то там портили для меня является популизмом и не более.
Поймите, мне и не надо об этом знать, в данной конкретной ситуации, если поменяется вёрстка или mysql сервер упадёт или url будет вообще стал валидный я и так об этом узнаю по графику. Я не утверждаю, что, так как я написал — единственно правильное решение. Но в моей ситуации, для меня, я считаю, что написал верно, и пока не увидел у вас весомых аргументов, которые бы пошатнули эту мою уверенность.
Именно, разница в заголовках. Не посылается не user agent, не referer, не cookie. Первое что делают когда делают защиту от парсинга, отсекают всех у кого пустой user agent. По крайней мере об этом говорит моя практика.
Вот это единственный момент, который я действительно пропустил, спасибо!
Вам не кажется, что вы сильно всё усложняете, я сам парсер написал минут за 15, в конечном итоге он без проблем проработал всё это время, снабжая интересующими меня данными. Разве не скорость написания, надёжность и быстрота работы являются одними из важных критерий, по которым можно и, даже не побоюсь этого слова, нужно оценивать работу программы? А вообще, это, наверное, хороший пример принципа KISS.
Давайте, если у Вас есть возможность и свободное время, Вы напишите пример, как бы Вы сделали парсер, который делает то же самое и сравним их по количеству строк кода, скорости работы и времени за которое вы его написали.
Собственно, инвайт на Хабрахабре я и захотел получить, ради хорошего спора с коллегами, потому что уже три года работаю единственным программистом в веб-студии и остро нуждаюсь в общении по профессии, ведь как известно, в споре рождается истина.
Про список того что вы написали, скажу следующее, в принципе часть советов(1, 3, 4) правильна, но не в моём случае.
1. Данная конструкция с
Была нужна что бы не было Warning ошибок когда удалённый сервер отдаёт 404. (file_get_contents вместо тогоже cUrl был выбран исключительно для того что бы морально оправдать парсинг. Раз ВГТРК не банит такие запросы, то они не простив парсинга).
Знаете способ элегантнее и проще? Поделитесь. Не было бы её, то в перспективе у меня бы мог лог ошибок разрастись и занять всё свободное место на HDD( не забываем что цель была в ограниченных ресурсах всё это запускать, и кстати, в конечном итоге всё отработало супер и полторы недели парсинга и «хабраэффект» почти не отобразилось на работе сервера).
2. В данном случае preg_match для меня намного проще. Для более сложного, в плане логики, парсинга, я предпочитаю использовать PHP Simple HTML DOM Parser. Но ради интереса надо будет попробовать сравнить в конкретно этом случае производительность DOMXPath и preg_match по потреблению памяти и скорости работы.
3. В моём случае мне нечего экранировать. Вообще конечно совет новичкам обязательный, все грешат по началу SQL инъекциями.
4 и 5. Ну очень сомнительный совет. Простите, это для меня даже прямо таки вредный совет.
Делать надо так что бы запустил и забыл а оно само работает. Мой код мог бы спокойно работать очень долго и объём требуемой для работы ОЗУ был бы всегда одинаковым.
А в случае который вы мне предлагаете, мне надо было бы сначала создать массив с данными в ОЗУ, затем из него сделать json строку, удалить массив и всю эту строку записать через file_put_contents. И чем больше было бы в БД записей то тем больше он будет кушать ОЗУ и следовательно кончиться тем что отвалиться с PHP Fatal error: Allowed memory size of… :)
Если вы это мне, то я просто показал интересные моменты на графике, что бы статья покрасивее была. Просто на момент написания статьи, это был наверное один из интересных моментов.
Хотя, конечно, это блекнет по сравнению с 2 миллионами за пол часа в последний день голосования.
32 421 805 голосов через смс, это 10 807 268,33 смс или примерно 38 041 584,53 рубля
37 141 324 голосов через смс, это 12 380 441,33 смс или примерно 43 579 153,49 рубля
10russia.sql.gz
У меня на графиках, к сожалению, только общее кол-во без дробления на смс и сайт(голосовать можно было и через смс и через сайт, хотя данные я сохранил и те и другие). Тогда было бы видно, что в основном, последний день голосования — это смс. А так даже в новостях есть, что большие проблемы были с добавлением смс из-за наплыва желающих.
Меня больше интересует за что там 700к голосов сняли 29 августа в 22:40…
Я с вами согласен, но, вроде бы это специально сделано: