Pull to refresh

Comments 29

Есть Libpurple (Pidgin, Finch, Adium) к которому есть модуль для ВК.
Можно логировать в plain text или в html. Можно заставить его логгировать всю историю или держать на сервере в фоне запущеным и логировать «эфир» в инвизибл моде.
Для увеличения количества запросов к API используйте https://vk.com/dev/execute (до 25 запросов за раз или до 75 в секунду учитывая частотные ограничения).
я думаю лучше бы сразу вы их записали в базу, можно было бы всякие выборки сделать тогда.
UFO just landed and posted this here
UFO just landed and posted this here
Хмм, статья очень кстати: тоже недавно задался вопросом как вытащить из ВК свои диалоги.
Кстати, если не секрет, поделитесь целью и результатами исследования.
UFO just landed and posted this here
А разве это хорошо, если программисты будут гуглить именно это?
Как по мне, так надо гуглить «vk get messages», «vk api python», а так, если всем разжевывать подобные задачи, то программисты, которые на этом вырастают, уже не могут ни ходить, ни решать реальные бизнес проблемы самостоятельно, им всегда будет не хватать целых книг следующего плана: «Как нажать на кнопку», «Как сделать свой интернет магазин», «Как сделать корзину на сайте», «Как сделать комментарии на сайте», «Как сделать голосование на сайте». Хотя истина лежит в поиске ответов на вопросы: «SQL для начинающих, база данных», «Основы framework».
К тому же решение кривое, перебор и обновление offset вполне себе делается через создание своей процедуры для API.
Ладно бы еще это была какая-то особенная библиотека для работы с ВК API на пайтоне, где можно было бы допустим обходить капчу через AntiCaptcha API и прочих сервисов такого плана и обзор всех этих дел. (vk_api)
Кстати по-поводу «Обходить капчу», такая библиотека для работы с VK api есть, если кому то интересно. Правда надо будет не забыть поменять AppID, для удобства там авторский стоит.
Captcha Handler можно как раз установить свой + вроде бы был готовый вариант с anti-captcha.com. И как раз для лентяев — всё на русском языке, сам автор тоже оперативно выходит на связь. И так даже посмотреть если, то проект вроде бы еще живет.

Выхожу на связь. У меня еще есть удобные обертки над execute и например можно делать так:


messages_iter = vk_tools.get_all_iter('messages.getHistory', max_count=200, values=values)
for message in messages_iter:
    ...

Есть своя выкачивалка сообщений, правда код плохой, но зато есть экспорт в html

UFO just landed and posted this here
А давайте не будет кафе и ресторанов, и еду готовить нужно будет каждому самому для себя. И зачем вообще кому-то нужны кафе и рестораны? Если им будут готовить еду другие люди, то люди, которые вырастают с кафе и ресторанами, уже не станут сами поварами!
:)
В общем, имхо, всё хорошо в меру.
Гуглить можно и так, и эдак — и документацию, и конкретный рецепт для конкретного случая. И в обоих случаях что-то найдётся полезное. Разве это не замечательно?
Получить список сообщений с вк — тут много ума не надо. Поиск информации о решении данной проблемы — неверный путь, но возможно простительный для начинающих, если есть куда стремиться.
Писать вот такие статьи на каждый случай — это обрекать все больше и больше народу на невозможность правильно работать с документацией и задачей априори. Под «такими» статьями я понимаю абсолютную бесполезность. Здесь не описывается как работать с конкретной либой например, какие у нее есть фишки, которые мы можем применить и получить определенный профит, как нам лучше оптимизировать ту или иную штуку. Здесь просто получение всех сообщений, ненужное описание как записать все в файлик ну и + «олгоритхм» как пройтись по всем сообщениям, просто прибавляя offset, который может реализовываться через execute процедуры вк, вот и всё.
А сама проблема в том, что таким образом формируются абсолютно некомпетентные «специалисты» на IT рынке. Я вот из мира PHP и смею утверждать, что мы там лучше всех знаем таких умельцев, порожденных DVD-курсами Русакова и Попова, которые формируют коробочное мнение о задачах и отдаляют людей от математики и программирования как такового. Точно так же и здесь: поиск информации в таком ключе порождает то же коробочное мышление. А это именно некомпетентность специалиста, формируемая прогрессирующей невозможностью решать реальные проблемы.
Я с вами крайне несогласен. И аналогию вы мою про кафе и поваров проигнорировали зря. И вряд ли приведёте мне ссылки на какие-либо исследования, обосновывающие вашу позицию — ведь это ваши умозрительные умозаключения о связи наличия рецептов решения задач и уровне программистов. Я считаю, что наборы рецептов (cookbook-и) — полезны, что изучение чужого кода улучшает инженерные навыки, и, кстати, рецепты часто размещаются в той же документации.
И вообще, инженерия — это навык решать практические задачи наиболее подходящими методами, в том числе, используя имеющиеся куски кода и компоненты, если так лучше для конкретной задачи, а не навык делать всегда всё с нуля, к которому вы пытаетесь всё свести. Следующим шагом вы скажете, «а чего пользоваться API вконтакте», или что «почему-то нет API для моего ЯП, буду сам гонять HTTP запросы», потом и до ассемблера дойдёте, а потом вообще пойдёте проектировать свой компьютер. Где граница между «коробочным» мышлением и «правильным»?
У нас в стране и так слишком много инженеров-формалистов, презирающих всех, кто делает что-либо не по правилам, придуманными этими формалистами, и слишком мало инженеров-предпринимателей.
А среди предпринимателей приоритеты стоят наоборот: время и стоимость решения проблемы имеет значение, а опыт, получаемый подрядчиком от изучения документации и его экспериментов с API, или гармония цветов проводов соединений за передней панелью — не имеет какого-либо существенного значения.
Аналогию я проигнорировал, потому как она вообще никак не связана с тем, что я пытаюсь донести.
Я про подход к решению задач, вы — про велосипедостроение. Где я говорю о том, что надо сидеть и писать свои решения с 0? Я говорю о том, что к вопросу надо подходить фундаментально — это позволит потом быстрее и дешевле (раз уж речь зашла о предпринимательском духе) реализовывать что угодно, без необходимости прочтения книг, прохождения видеокурсов для решения той или иной задачи.
Нельзя же полностью понять устройство двигателя самолёта без знаний физики, термодинамики, электрики, механики и аэродинамики, но можно найти кукбук, где это все можно собрать скотчем и продать, да?
>Я говорю о том, что к вопросу надо подходить фундаментально — это позволит потом быстрее и дешевле
Это в вас говорит профессиональная деформация.
«Фундаментально» — это как? Знать всё про ассемблер и коды машинных команд, смотреть вывод компилятора в бинарном коде, знать формат IP-пакетов и ISO иерархию TCP-стека? Много лет изучать теорию, не решая практические задачи? Решать задачу каждый раз самому вместо использования чужих решений? Придумывать вместо однократного решения задачи общий алгоритм решения произвольной похожей задачи? Или как-то ещё?
И всё это для чего? Чтобы научиться идеально решать эту задачу и похожие?
Проблема лишь в том, что фундаментальность — антоним практичности. Вы предлагаете годы страдать, чтобы потом за 5 минут прилететь. А в чём выгода такой стратегии на практике для предпринимателя? У него задачи каждый раз разные. Для наёмного работника — да, есть выгода в том, что вы будете уметь много раз для каждого клиента решать одну и ту же задачу (или похожие). А в бизнесе нужно решение сейчас, когда ещё нет конкурентов, а не через годы, когда это будут уметь делать все за 5 минут.
Не поймите неправильно, специалисты тоже нужны, я лишь говорю, что в некоторых ситуациях подход генералиста лучше — и это именно принципиально другой подход, вынужденно вызванный разнообразием и шириной решаемых проблем, и именно генералист предпочтёт использовать готовый рецепт при возможности.
Просто не считайте, что при этом генералисты чем-то хуже специалистов — да, у них может и нет фундаментального подхода и глубины знаний VK API, но если они при меньшем опыте работы справятся с конкретной задачей быстрее вас — то может такая стратегия тоже имеет смысл?
И в этом есть только один плюс: чем больше неквалифицированных кадров, тем больше заработная плата у реальных специалистов.
P.S:
Главное чтобы дорабатывать ничего после таких умельцев не приходилось никогда.
Что-то у меня глаза немного закровоточили от листингов.
Конкретнее, конкретнее.

Я вот могу подсказать автору, что если он хочет вывести номер итерации, то вместо i = 0; ...; i += 1 в Питоне ему стоило бы делать просто
for i, friend in enumerate(friends):
    ....


Ещё можно добавить, что if'ы в Питоне принято делать так, чтобы минимизировать вложенность. То есть не
if whatever:
    # огромный блок кода с отступом
, а
if not whatever:
    continue # ну или return
# огромный блок кода без отступа


Ну и, конечно же, не
if type(dialog) == dict:
, а
if isinstance(dialog, dict):
Ещё вместо
m_text = re.sub("<br>", " ", dialog['body'])
достаточно
m_text = dialog['body'].replace("<br>", " ")
Соответственно, import re можно вообще убрать.
Там много всего, на самом деле. К теме поста, конечно, это не относится, но каждому хотя бы однажды просто необходимо пройтись по своему коду каким-нибудь линтером, чтобы понять, какие вещи ты делаешь вразрез с PEP.
За реализацию идеи, безусловно, плюс, но листинги лично для меня все портят. По восемь пробелов отступы, docstring нет, комментариев нет, пятиуровневая вложенность. И это далеко не все.
Это не восемь пробелов, это табуляции, PEP 8 их не совсем запрещает, а батл «табуляции vs. пробелы» — это вообще отдельная тема.
Просто мне лень было все это писать, вот и решил тезисно замечание сделать, чтобы менее ленивые люди дали развернуты ответ.
С готовностью принимаю критику.) Я не программист по профессии; стараюсь учиться правильному и делать поменьше глупостей, но не всегда получается красиво. Благодарю за советы)
Sign up to leave a comment.

Articles