Комментарии 4
По сути, наш интерпретатор просто декодирует теги span внутри выгруженного Google-документа, переводит их в простые теги форматирования — i, b, s — и добавляет специальные элементы
занимает около 20-30 минут времени: робот имитирует все действия человека
сюр какой-то, от постановки задачи до реализации
человекочасы разработчиков на разработку и поддержку этого костыля, который сломается при первом изменении html/css редактора vc (пока ваш робот Федор на кнопочки по xpath-селектору нажимает) в совокупности выйдут дороже, чем нанять еще 5 сммщиков который друг за другом проверят и переверстают ту же статью.
все это нужно чтобы раз-два в неделю сммщик не потратил +-полчаса на переверстку новой статьи из за кривого редактора одной из платформ, который почему-то не умеет в md (?)
не проще выйдет писать статью сразу в md, вместо google docs, написать конвертеры
md -> формат особо одаренной платформы, и настроить доставку на платформы через API, чем трахаться с google docs и роботами?насколько громко рухнут /встанут ваши важные маркетинговоо-сммно-пиарные процессы, когда на vc вдруг появится капча?
то же самое, но теперь если google docs завтра перестанет работать в россии
1 Нет. Например, конвертер статей на Хабр был написан за неделю-две, занимался им в свободное время. То же самое и с остальными сервисами – например, для сбора аналитики. Робота для vc собрали также быстро, меньше месяца ушло на все этапы – от постановки тз до первых тестов.
1.2 Интерфейсы всех сервисов пишем таким образом, чтобы можно было изменить, например, xpath / название класса и робот / парсер без проблем продолжил работу. Было несколько раз такое, когда мы собирали данные с Хабра, все ок. Достаточно было подать другие данные на вход интерфейса.
1.3 Про сммщиков – это просто не так) Просто констатирую, что мы здесь уходим в плюс и сохраняем много человекочасов.
2 При чем здесь вообще md? И почему на любой площадке он должен поддерживаться?) У vc своя специфика редактора – он такой, потому что у его аудитории нет веской потребности в html или md.
2.2 Откуда данные про полчаса? В статье же написано, сколько мы тратили времени до автоматизации процесса верстки. Если бы лонгриды верстались за полчаса, вероятно, потребности бы такой сильной не было.
3 Нет, не проще. Мы используем Google-документы из-за удобства в совместной работе. Документ можно расшарить и отправить коллеге, который, в свою очередь, может быть не знаком с md. Да он, собственно, и не обязан быть с ним знаком. Тут тогда проще задать спросить, зачем вообще люди пользуются Google-документами, если есть md... и почему не LaTeX?
3.2 Нет, API использовать не проще, потому что его нет. Очевидно, наличие API было первым, что я проверил, когда начал заниматься автоматизацией. У Хабра и vc.ru он отсутствует. Да и в чем проблема воспользоваться RPA? Это кажется эффективней, чем просить у разработчиков той или иной площадке выкатить API, который неизвестно, каким получится на выходе.
4 Не рухнут. Человек тоже принимает участие в процессе верстки, он загружает архив из Google-документов, настраивает параметры верстки – например, ключевое слово для utm и тд. Если появится капча, добавим на своей платформе фрейм и уведомление от робота, что нужно помочь с капчей. Добавится всего одно действие, человеку нужно будет дополнительно потратить 5-10 секунд своего времени. Не думаю, что это веская причина, чтобы бояться автоматизации)
5. Если перестанет, есть VPN и другие способы. Возвращаясь к разговору о интерфейсах: все разделено на логические функциональные блоки. Есть блок первичной конвертации из Google-документов, а есть роутер, который дополнительно это все декодирует и фильтрует. И для нас не будет сложным поменять параметры первичной конвертации таким образом, чтобы она работала не только для Google-документов, но и для других редакторов.
При чем здесь вообще md? И почему на любой площадке он должен поддерживаться
при том что для md уже куча готовых редакторов с кнопочками, конвертеров хоть в html хоть в pdf, и прочих тулз и сервисов. он сам по себе предоставляет джентельменский набор тегов, который в том или ином виде будет на всех площадках (заголовок, ссылка, цитата, картинка итп). для авторов - редактор с кнопочками на ваш вкус, для разрабов - формат, с которым работать приятнее, чем с кучей span.classname из google docs.
в чем проблема воспользоваться RPA
в том что это говно придется поддерживать: трекать изменения на каждом отдельном на сервисе, ловить капчи, редиректы, и молиться, что завтра тот же vc чего нить не сломает. воткнут ребята css uglify в свой ci/cd - все, адьос.
на все это будете тратить человекочасы разрабов в обмен на чч сммщиков, что экономически нецелесообразно (за исключением ситуаций, где все это делает дома и бесплатно джун с горящими глазами чтобы выслужиться)
Откуда данные про полчаса?
это цитата из статьи
Вопроса 4:
сколько у ваших ребят занимает верстка лонгрида для одной площадки вручную
сколько статей вы публикуете в месяц
насколько в % отличается зп разраба от сммщика
сколько человекочасов сммщика в месяц вы сэкономили, и через сколько лет отобьется хотя бы месячная (с ваших же слов) разработка, без учета поддержки?
Как мы автоматизировали верстку статей на vc.ru, или почему в маркетинге нужны роботы