• Будущее браузеров и искусственный интеллект. Дзен в Яндекс.Браузере
    0
    Эх, я-то надеялся что будущее уже почти наступило, а оно ещё и только зарождается.
    Листы рекомендаций на основе вкусов других — не решают проблемы. Наверное мои вкусы слишком специфичны.

    P.S. вы не ответили на главный вопрос ;)
  • Будущее браузеров и искусственный интеллект. Дзен в Яндекс.Браузере
    0
    В ленте будут и другие ресурсы. И даже больше. Будут ресурсы и другой тематики в рамках борьбы с самоизоляцией пользователя.

    А можно услышать пару слов о том, как будет осуществляться подбор ресурсов по другой тематике? Просто рандомно, или на основе каких-то данных?

    P.S. Вы не в курсе, ведутся ли какие-то работы, чтобы научить машину слушать музыку, чтобы предлагать хороших исполнителей, которых ты ещё не нашел сам?
  • Что нам стоит сайт распарсить. Основы webdriver API
    0
    Я тут вижу дважды вызов метода wait(X), с 20 и 10 в качестве параметра. Я правильно понимаю что это время отведенное на ожидание драйверу, прежде чем вернуть ответ? Т.е. грубо говоря ждем 20 секунд чтобы всё загрузилось потом тащим таблицу? Тогда получается что полминуты это только ожидания…
  • Web без мышки
    0
    Тогда хотя бы какие-то данные об этом предоставьте, мол «еще два месяца старательной доработки и будем всем желающим счастье» :)
    Пришлось внимательно комменты перечитать, чтобы убедиться что а) Это не я слепой а и правда никаких ссылок нет, б) Об этом уже спросили и я не сделаю дубль.
    По теме же — развивайте библиотеку! Выглядит вкусно и полезно. Что касается холиваров насчет «мышка/клава» бред какой-то. Каждому удобно то, что удобно. Такое ощущение, что часть людей которые участвуют в этих спорах совершенно забывают о том, что им никто ничего не навязывает.
    У вас есть потребность в такой библиотеке и вы её создаете и развиваете — это прекрасно! Я уверен что найдутся люди которым это интересно, и кто с удовольствием будет использовать данную либу. Для интерфейсов — самое то.
  • Что нам стоит сайт распарсить. Основы webdriver API
    0
    Но именно он, как я понимаю, и был использован.

    Не совсем, я не отказался от всей той логики что была до появления фантома, всё что делал фантом в данном случае — кликал на элемент который якобы ссылка, отрабатывал все внутренние редиректы (от 2 до примерно 7) и возвращал итоговый url в output.

    Колонок что-то около десятка. При количестве строк под сотню разбор данных из этой таблицы занимал где-то минуту из PHP по webdriver с использованием достаточно простого XPath

    Звучит жутко, как я понимаю каждый xpath запрос отдавался в браузер и основная проблема была именно в этом? В случае с пайтоном и адекватным способом общения его и браузера, я бы стащил готовый html в пайтон и там уже разбирал. Может быть так и следовало поступить? Маленький html жрется очень быстро. Если надо распарсить какие-то огромные данные, то есть event-based парсинг. Доводилось мне парсить xml в 60гигов, примерно за 4 часа он был пережеван, при этом в базу ушло около 5,5 миллионов записей. В самом файле их было намного больше. Хотя таких данных в веб-парсинге пожалуй что нет.
  • Что нам стоит сайт распарсить. Основы webdriver API
    0
    Оценка прироста от такого решения не проводилась? И я не очень уловил, как тогда оправляются в него команды?

    Нет, не производилось. Да и это решение было выбрано не совсем осознанно, надо было использовать какой-то headless браузер. Быстрый гуглинг для поиска решения подходящего под пайтон не принесли адекватных плодов, а с PhantomJs опыт уже был. Потому быстренько его и использовал. В тот момент когда возникла необходимость в парсинге с учетом js, было слишком мало времени на анализ, планирование, прототипирование… надо было сделать еще вчера. Потому получилось так, как я описал.
    Как фантом получает команды? Через консоль. /usr/bin/phantomjs /my/path/to/script.js params а в самом script.js есть всё, что надо для работы. Результат отдаем обратно в output и слушаем пайтоном. Т.е. там нет полноценного общения, запуск и получение результата, всё. Вся логика внутри скрипта который скармливается фантому.

    Фантомы можно запускать с использованием проксей

    И даже если бы было нельзя, то можно было бы решить средствами не фантома, но по не техническим причинам было решено не использовать прокси.

    В попытке ускорить парсинг не возникала идея перенести бизнес логику парсинга в подлючаемые к фантому JS? У меня возникали большие подозрения, что это может ускорить процесс, но руки до подобной переделки уже не дошли.

    Очень сомневаюсь в действительной пользе такого решения. Зачем внутри фантома решать задачи парсинга большие, чем получение нужных данных? Думается мне что оверхед на передачу данных в сторонний скрипт (Python, php, C#, nodejs, anything_you_like) будет гораздо ниже, чем анализ данных внутри виртуального браузера. Особенно если данных какой-то относительно большой объем. Я думал избавиться от воркера который собирает картинки и делать это в фантоме, всё равно ведь страница отрисовывается. Но способа лучше чем отрисовать картинку в канвасе и сохранить данные из канваса — не нашел. А данный способ всё равно порождает дополнительный запрос за контентом, потому смысла не имеет.
    Хотя в случае с использованием API для общения с браузером, возможно, всё иначе.
  • Что нам стоит сайт распарсить. Основы webdriver API
    0
    Часть нужных ссылок была переделана из обычного тега «a» в js реализацию по onClick, и, к сожалению, место откуда берутся данные весьма не очевидно, а дебагать обфусцированный js код очень сомнительное удовольствие.

    неплохо работает связка awesomium+C#+CSQuery

    К счастью/сожалению (по желанию) я не знаю C# и .net платформу. Знаю Python и js, на них и писал :)

    Что касается скорости парсинга, как я писал выше наибольшая проблема была в качестве связи с сайтом-донором. Сбросы соединений, 502-ые и т.д. не починить ничем, кроме разнесения процесса парсинга на разные сервера чтобы стучать с разных IP. Это при условии что я прав и такое поведение — это защита от слишком большого количества запросов от одного хоста, а не просто дохлый хостинг.
  • Что нам стоит сайт распарсить. Основы webdriver API
    0
    Хочу поделиться опытом использования old-school -ного парсера вместе с PhantomJS, думаю опыт может быть полезен, плюс тут есть цифры на которых можно «пощупать» скорость работы.
    Не так давно был у меня проект под который надо было парсить сайт с недвижимостью, python + requests + beatyful soup и вопрос решен довольно быстро. Навигация по html-дереву через xpath, регулярки только для анализа данных, но никак не структуры. Задача имела временные ограничения — работать парсер должен был не более 6ти часов в день. Среднее количество записей которые собирались с сервера — 67.000. Парсер был разбит на задачи, т.е. есть головной скрипт который производит общий аудит и создает отдельные задачи на парсинг, 8 воркеров отведено было для решения этих задач, каждый воркер мог еще создать отдельные задачи, на каждую из задач опять же отводилось 8 воркеров. Чтобы было понятно — сбор данных одна очередь, сбор изображений другая очередь, анализ урлов уводящих со страницы — третья. Такой вот парсер в работе был совершенно не заметен по нагрузке, и в свои 6 часов укладывался с лихвой. Потом на сайте-доноре произошли изменения которые без исполнения js никак не обработать. И тут я подключил к этому делу фантом. 12воркеров запускавших фантомы отжирали несколько гигов памяти, периодически они (экземпляры фантомов) не могли нормально «умереть» и не освобождали ресурсы, что в конечном итоге приводило к отказу сервера, т.к. в особо плохих случаях, когда проблема возникала очень часто — память на сервере просто заканчивалась физически. А это было 16 гигов оперативы и 16 гигов свапа. Данный вопрос решился относительно быстро, пайтон воркеры запускали phantomjs как обычную консольную команду и слушали output, это не было использование какого-то драйвера. В итоге, при плохом коннекте к сайту (думаю на стороне сайта-донора была защита по кол-ву обращений с одного IP) Phantomjs порой не мог загрузить страницу целиком, происходил обрыв связи, или получал ответ слишком поздно. Опять же, все мои скрипты для phantomjs-а исполнялись после того как DOM полностью построен, и задержка/обрыв связи при загрузке какого-нить скрипта блокировали исполнение задач моего phantom-а, соответственно как только я поставил таймеры на самоубийство фантома — проблема ушла. Однако пару раз сервер ночью у нас таки лёг. Но баги-то починить можно, а вот со скоростью работы сделать ничего нельзя :( Скорость сбора данных упала до 6-10 тысяч записей за отведенные 6 часов. Что любопытно, увеличение кол-ва воркеров выше 12 в моем случае приводило только к замедлению работы. Кол-во отказов в доступе/обрывов связи с сайтом-донором возрастало жутко, но это всё-таки не проблема решения, а проблема иной плоскости.
  • Жизнь PHP-разработчика
    0
    Как показывает практика, люди, нашедшие в себе силы, изучив любой другой язык, на PHP назад почти не возвращаются. Отсюда риторический вопрос — «Почему!?».

    Возможно потому, что как здесь уже говорили — php хорош как язык для начинающих, ибо «начать делать» можно быстро. С Си, Джавой и прочими «Мощными и проверенными временем» решениями не сравниться. Мой опыт веб-программирования начался с php. Можно сказать от скуки решил сделать маленький полезный проект, взял книжку, читал её три дня, а потом начал кодить и недельки за две уже было годное под мои задачи приложение. При полном отсутствии опыта разработки под веб до того времени. Думаю мало какой ещё язык позволяет так легко начать делать что-то реальное (для себя). Потом я увлёкся вебом, пару лет писал на пхп, но познакомился с пайтон-джанго. После Joomla это было невероятно круто. А дальше началась полноценная разработка под веб, пришлось заняться фронт-эндом, а потом и нодой. В итоге сейчас мне порой любопытно чтож там твориться-то в пхп. Однако есть гораздо более интересные вещи на которые и трачу время, а к пхп вернутся нет стимула. И дело не в языке. Мы в компании используем иной стек технологий, так что мне это просто не к чему. Думаю у многих ситуация схожая. Когда пхп первый язык, то возвращается к нему поздно — т.к. ты уже не одиночка и надо оглядываться на команду.

    P.S. По теме топика — мне кажется, зачастую нападки на язык больше из-за людей, которые на нём пишут. Всё-таки я очень много встречал упоротых Пыхеров (я иначе их не назову, без обид) которые ничего кроме раздражения не вызывают. И язык на котором они пишут виноват только в том, что он в начале прост настолько, что даже упоротые быдлокодеры смогли им овладеть.
  • Разработка браузерной онлайн игры на meteor
    0
    Кстати, вот еще вопрос о котором сразу не подумал.
    А как сделан механизм постройки зданий? Т.е. вот я пользователь нажал «построить», дальше постройка должна быть готова через Х минут. setTimeout тут может принести множество неожиданностей, например обновили/перезагрузили сервак и таймауты потерялись. Просто timestamp-подобный флаг времени, когда можно начать использовать здание?
  • Разработка браузерной онлайн игры на meteor
    0
    Zav, а почему был выбран iron-router а не flow-router? Iron уже не поддерживается длительное время, в итоге если возникнут какие-то проблемы с очередным релизом Метеора, то придётся форкать пакет и править самому.

    Ты написал среди плюсов метеора — средство для дебага, можешь как-то расширить описание?

    Ну и вопрос исключительно «о себе». Ты написал что это был первый проект на метеоре, нет ли после запуска ощущения, что многое можно было сделать иначе и лучше? Просто у меня после запуска первого проекта на метеоре было ощущение, что я многое сделал не правильно. И сейчас подправляю многие вещи. Вот и интересно, есть ли такое же впечатление? Просто метеор немного не обычен и думать в разработке на нём надо порой иначе.
  • Быстро и «грязно»: excel to html
    0
    Как правило, если на сайт надо вставить табличку, то там есть WYSIWYG редактор, большинство из них не только умеют вставлять таблицы с сохранением форматирования, но так же имеют кнопки «очистить лишнее форматирование». В каком-то даже видел кнопку «убрать лишние тэги», которая подчищает ненужные дивы, всяческие   и т.д.
    Но вообще когда у меня встает подобная задача, обычно копирую таблицу в WYSIWYG редактор, оттуда забираю её в html виде (многие редакторы так же дают возможность поглядеть на исходники в html), а уже готовый html подчищаю в чем-нибудь аля notepad++, автозамена и регулярки (в особо запущенных случаях) решают :)
    Возможно звучит не совсем оптимально, однако это способ который я нашел для себя на заре работы в вебе и с тех пор даже не пытался оптимизировать (надобности не было). Но даже такой способ не оставляет тонны мусора, как у автора (не в обиду). Ибо, лично мне кажется, что контент на странице должен быть адекватным и по форматированию/стилизации совпадать со всем сайтом. Иначе со временем сайт превратится в вот это
  • Веб-приложения на Clojure
    0
    Осмелюсь ответить вместо автора :)
    vk.com/myclojure.
  • Веб-приложения на Clojure
    0
    Мне было бы интересно прочитать про использование ClojureScript, сравнение с CoffeeScript/JavaScript и, конечно же, впечатление программиста от использования. Так что, автор, если напишите — лично я буду признателен.
  • 5 причин для Angular-разработчиков в пользу использования Meteor
    0
    Абсолютно согласен, Blaze в 99% случаев работает очень хорошо и прозрачно. Есть некоторые нюансы при специфичных задачах, например когда надо к перестроенным данным выполнить некий код, как пример — инициализировать select2, тут начинаются пляски с бубном. В остальном же blaze очень хорош и весьма прост. Вообще метеор, на мой взгляд, самая простая с точки зрения изучения, система на js, при условии что человек неплохо знает сам язык и его особенности. Ангулар на порядок сложнее.
  • 5 причин для Angular-разработчиков в пользу использования Meteor
    0
    удалено
  • 5 причин для Angular-разработчиков в пользу использования Meteor
    +4
    Я гляжу в основном общаются знатоки ангулара, а есть ли здесь знатоки Метеора? Я использую Метеор уже некоторое время, не так давно закончил на нём первый большой (относительно) проект, с ангуларом я знаком очень поверхностно, и потому не могу понять — зачем он может быть нужен в метеоре?
    То, что я знаю об Ангуларе:
    1. Ангулар делает данные связанными
    2. Автоматически перерисовывает шаблоны при изменении данных.
    3. Своя событийная модель (свои хендлеры)
    4. Умеет обращаться за получением/обновлением данных на сервер.

    Что я не понимаю:
    1. В Метеоре сделать реактивную переменную просто, это одна из фишек Метеора. Не говоря уже о работе с БД, где подписки на коллекции обновляются так же автоматически. Потому я не понимаю зачем нам нужен Ангуларовский биндинг данных.
    2. Перерисовку страницы Метеор так же делает весьма просто и удобно (как правило), зачем перерисовка шаблонов от Ангулара?
    3. В Метеоре, на мой взгляд, очень удобный биндинг обработчиков к событиям. И нет большой проблемы сделать кастомные события (при помощи Jquery). Зачем события Ангулара и их обработчики в ангулар-стиле?
    4. Большая часть данных которая нужна при работе в Метеоре, это объект пользователя и коллекции из БД, и то и другое легко доступно в любом месте, ангуларовские запросы к серверу не нужны.
    В итоге я не понимаю зачем использовать ангулар в метеоре? В самом начале статьи было сказано: «Метеор это хороший бэкэнд для Ангулар-разработчика» — это единственный смысл? Т.е. получается, что это не к Метеору прикрутили Ангулар а наоборот?
    Прошу понять меня правильно, я не пытаюсь устроить холивар или просто обгадить идею этой связки — но я действительно не понимаю её плюсов, за исключением одного: «Так проще из ангулар-девелопера сделать еще и сервер-сайд девелопера».
  • Несколько тонкостей использования jade в Meteor-проектах
    0
    Спасибо, позже добавлю в статью.
  • Flask. Наполняем «флягу» функционалом
    +1
    1 <...> Вроде и не мешают, а вроде никто и не приглашал.

    Я под термином «монстроузность» понимаю избыточный функционал который либо мешает, либо жрёт дополнительные ресурсы в недопустимых количествах. Приведённый вами пример, лично для меня не есть признак монстроузности. Лежат, кушать не просят. Вдруг понадобятся — ничего не нужно делать, только настроить. Не понадобятся? Ну и Бог с ними.
    2. Django многие вещи позволяет сделать несколькими путями. Кому-то это по душе, но точно не мне. Пример? — render_to_respose, render, HttpResponse.

    Приведённые вами функции не равнозначны, и служат как раз для гибкости и удобства. Нужно вернуть статус 200? return HttpResponse(200). Нужен просто обычный ответ? render_to_response(). Нужно что-то накрутить хитрое? render с кучей параметров. Я с одной стороны согласен, что это избыточно. Но с другой — не избыточный путь это оставить только HttpResponse, что вынудит любого из нас написать свою обёртку для удобства. Чтобы не передавать каждый раз кучу вещей вроде content_type, статус и т.д. Как по мне — гораздо удобнее использовать raise Http404 чем возвращать HttpResponse(status=404). Но соглашусь, что это дело вкуса. Хуже того, в наших проектах на Django используется собственный декоратор render_to, построенный на основе render, насколько я помню. И в 95% случаев мы работаем именно через него. Нам так удобнее.
    3. Ограничения? На структуру проекта

    Хм, ни разу не испытывал неудобства из-за структуры джанго-проектов. Но, возможно, мне просто не попадалась такая задача. Про юзеров — согласен, было не очень удобно и приходилось отчасти костылить. Однако решается всё довольно просто и очевидно. К сожалению что там после 1.5 сделали я знаю только из прочтения changelog-а. Старые проекты пока держим на 1.4, а в новых юзеры просты до тупости, так что на практике не щупал :(
    А с ограничениями ORM согласен. Если надо что-то сложнее чем примитив — бывает геморрой.
    Я ни в коем случае не противник Django, просто это не мой выбор. Может быть, я просто его не понял.

    Я спрашивал не для спора о том, что лучше. Исключительно с целью разобраться. Может быть я привык к каким-то вещам и просто их не замечаю? Критичный взгляд порой полезен.
  • Flask. Наполняем «флягу» функционалом
    +1
    Присоединяюсь к запросу, мне то же очень интересно узнать какие в Django есть ограничения, с которыми сложно смириться. И что же там монстроузного? Возможно, это будет поводом рассмотреть их внимательнее.
  • Несколько тонкостей использования jade в Meteor-проектах
    0
    if not заменяется на unless.

    Не знал, большое спасибо. Добавил в статью.
  • Несколько тонкостей использования jade в Meteor-проектах
    0
    Совсем без логики — никуда. Надо же порой проверить наличие элементов в списке, или, например, основываясь на кол-ве элементов принять решение, как дальше выстраивать элементы. Вот пихать бизнес-логику, или какие-то сложные проверки — однозначно не просто плохо, а недопустимо.
  • Несколько тонкостей использования jade в Meteor-проектах
    0
    Да, именно для этого я и сделал себе два хелпера, equal и notequal. Но до этого потратил время, чтобы таки добиться нужного поведения от jade, но, увы, в данном случае это не возможно :(
  • Несколько тонкостей использования jade в Meteor-проектах
    0
    Можно добавить параметр для проверки, но проверяет он его исключительно на true. А вот такая проверка
    if some == another
        .one-el
    else
        .another-el
    

    Не заработает.
    По меньшей мере я так и не нашел способа заставить её работать.