Привет! Меня зовут Влад, я технический писатель в Selectel. Не так давно я выпустил статью, где рассказал, как мы с коллегами разработали верстальщик статей из Google-документов на Хабр.
Но мы работаем не только с Хабром, но и на vc.ru. Редактор статей там сильно отличается: нельзя верстать в html, есть другие типы элементов. Поэтому создать аналогичный верстальщик для этой площадки сложнее. Но вместе с командой PIX Robotics, которая специализируется на программных роботах, у нас это получилось. Подробности под катом!
Используйте навигацию, если не хотите читать текст полностью:
→ Ретроспектива
→ Специфика редактора публикаций на vc.ru
→ Конвертация Google-документа в верстку
→ Архитектура сервиса
→ Результаты и планы на будущее
Ретроспектива
Когда-то давно
Когда я пришел в Selectel в 2022 году, мой тогда еще бадди и нынешний руководитель Ульяна попросила собрать статистику по нашей активности на Хабре и нескольким интересующим нас блогам. В корпоративных Google Analytics и Qlik эти данные не собрать, поэтому я решил завести отдельный дашборд. И вместо того, чтобы автоматизировать этот процесс, решил все сделать вручную, отслеживая изменения на площадке с заданной периодичностью.
Естественно, таким образом много данных не собрать: это скучно, а еще максимально неточно. Поэтому пришлось все-таки автоматизировать этот процесс. И спустя пару недель мы уже собирали данные с помощью самописной программы SeleStat. По сути, это обычный парсер для формирования статистики по выбранным хабраблогам.
Не так давно
Спустя время появилась потребность унифицировать верстку статей по стилю, а также хотелось сократить время на рутинные задачи при подготовке материалов к публикации. Подробнее об этом рассказали в отдельной статье.
В общем, чтобы больше сфокусироваться на серьезных задачах и точнее планировать публикации, мы разработали простую программу для конвертации статей из Google-документов на Хабр. По сути, это простой обработчик текста, сильно упрощающий жизнь авторам нашего блога.
Кроме того, мы автоматизировали постановку задач на смежные отделы в Jira, чтобы не забывать, например, заказывать у дизайнеров обложки и схемы для текстов. Но это тема для отдельной статьи, скорее о налаживании процессов в редакции, о которой может рассказать @lodz.
Сегодня: зачем конвертер статей на vc.ru
Каждую неделю мы выпускаем по два-три поста на vc.ru — это около одной трети публикаций на внешних площадках. Ручная верстка занимает, в среднем, до 1,5 часов: текст нужно правильно отформировать, добавить специальные элементы и utm-метки. И если посмотреть в разрезе квартала, верстка может отнимать более 50 часов рабочего времени.
По этой причине мы решили создать версию верстальщика статей для vc.ru. Но была проблема: редактор этой площадки сильно отличался от редактора статей на Хабре. То есть мы не могли просто взять существующую программу и использовать ее. Нужно было погрузиться в специфику vc.ru и разработать что-то новое.
Специфика редактора публикаций на vc.ru
Как бы это странно ни звучало, для нас лучше, когда редактор статей менее интерактивен и адаптивен. Потому что подобные интерфейсы, наполненные меню, разными блоками и другими элементами, — это всегда сложный JavaScript. Значит, нельзя написать программу, которая будет «бездумно» копипастить текст в заданные текстовые поля.
Нужно имитировать действия человека — от создания публикации и простейшего ввода текста до работы со сложными элементами. Последнего на vc.ru достаточно: есть врезки, персонализированные цитаты, списки, вставки с кодом, различные блоки для элементов медиа и другое.
Если вы можете написать программу для верстки статей на vc.ru, используя библиотеки вроде Selenium, — смело отправляйте нам свое резюме. У нас же не было ресурсов на создание подобного решения с нуля. Поэтому мы обратились в PIX Robotics — и вместе мы написали робота на базе платформы PIX RPA.
PIX RPA — это интерактивный инструмент разработки программных роботов для решения разных рутинных задач. Создание роботов происходит в студии разработки PIX Studio, которая ориентирована как на разработчиков, так и для бизнес-пользователей: программировать роботов можно в построчном формате или с помощью удобных блок-схем.
Список готовых активностей включает задачи по работе с офисными программами, сайтами, бизнес-приложения и мессенджерами. Также можно использовать сервисы распознавания и чат-боты.
Конвертация Google-документа в верстку
Интерпретатор и язык разметки
У нас уже был достаточно хороший конвертер статей из Google-документов в html, который позволял получить код верстки для Хабра — набор из строк с гипертекстовым описанием разных элементов. Мы хотели его переиспользовать с минимальными изменениями для vc.ru, чтобы робот верстал статьи на основании этого кода. В противном случае пришлось бы писать новый интерпретатор.
По сути, наш интерпретатор просто декодирует теги span внутри выгруженного Google-документа, переводит их в простые теги форматирования — i, b, s — и добавляет специальные элементы.
Для сложных элементов вроде врезок и кодовых вставок предусмотрен специальный язык разметки — STML, Selectel Text Markup Language. Его мы используем при написании статей в Google-документах.
Документация в Confluence, правила оформления текста.
В результате интерпретатор возвращает правильно размеченный html-код. Например, для всех ссылок на продуктовые страницы в коде описаны utm-метки.
Код верстки текста в html-формате.
Ретрансляторы тегов
Результат работы интерпретатора почти всегда предсказуем. Мы знаем, что если в Google-документе элемент помечен как Заголовок 1, на выходе получится строка такого вида:
<font cоlor="#EB4247"><h2>Заголовок</h2></font>
Робот тоже понимает разметку в html и решает обратную задачу: транскрибирует код, который сгенерировал интерпретатор, в элементы верстки на vc.ru.
Правила декодирования html-кода для робота-верстальщика.
Все правила описаны в отдельных файлах проекта в Студии PIX — от нажатия комбинаций клавиш до сложных действий вроде вызова элементов. Ориентироваться в интерактивном интерфейсе vc.ru ему позволяет не только xPath, но и встроенный модуль машинного зрения. Он помогает роботу искать нужные элементы на веб-странице и взаимодействовать с ними при необходимости.
Архитектура сервиса
Ранее все сервисы, которые мы разрабатывали с коллегами для автоматизации рабочих задач, были в формате десктопных приложений. Это неудобно: после каждого патча нужно рассылать обновления, следить за совместимостью версий и другими нюансами. Поэтому мы переносим все сервисы — в том числе и робота для верстки статей на vc.ru — в облако.
Рассмотрим, как это работает с точки зрения архитектуры:
1. Интерфейс Marketing Cloud. Сотрудник получает сервисный аккаунт, авторизуется в облаке, которое мы строим на базе виртуальных серверов Selectel, и открывает верстальщик статей. Далее настраивает параметры верстки, загружает zip-архив с изображениями и самой статьей.
2. Конвертер и объектное хранилище. Программа на стороне сервера распаковывает zip-архив и генерирует html-код статьи. Но что она делает с медиафайлами?
Ранее мы загружали все изображения для публикаций в облако habrastorage, однако сейчас стараемся от этого уйти. Поэтому все медиа подгружаются через API в наше объектное хранилище.
3. Робот на базе PIX RPA. После того, как код статьи сгенерирован, он отправляется на другой виртуальный сервер по SMTP/IMAP. На нем запущен робот, который принимает файл, запускает Chrome, переходит на vc.ru, создает публикацию и начинает верстать.
Последнее занимает около 20-30 минут времени: робот имитирует все действия человека. До завершения верстки можно отойти попить чай или заняться другими задачами, а после — опубликовать статью.
При этом робот запущен в фоновом режиме на удаленной машине с Windows Server. То есть обычный пользователь не видит самого процесса, а по завершении верстки получает простое уведомление. Но у нас есть возможность приоткрыть занавесу — вот, как это работает:
Результаты и планы на будущее
Сегодня мы уже используем робота для верстки текстов на vc.ru и тестируем его возможности. Он позволяет нам тратить минимум времени на этот процесс и не забывать о нюансах — например, проставлять utm-метки. Также мы активно дорабатываем интерфейс Marketing Cloud для более удобной работы с роботом.
Мы планируем и дальше развивать собственное облако и сервисы. Среди них — инструменты для аналитики рассылок, работы с SEO, генерации внутренних электронных документов и другое. Будем держать в курсе — следите за обновлениями в нашем блоге!
Возможно, эти тексты тоже вас заинтересуют:
→ Shawarma as a service: как создать бота для заказа шавермы и оставить голодными лишь 1,1% коллег
→ 10 шаблонов запросов для ChatGPT, которые выдадут качественные ответы в помощь продакт-менеджеру
→ Как эффективно управлять парком серверов? Оптимизируем работу с помощью API
laatoo
сюр какой-то, от постановки задачи до реализации
человекочасы разработчиков на разработку и поддержку этого костыля, который сломается при первом изменении html/css редактора vc (пока ваш робот Федор на кнопочки по xpath-селектору нажимает) в совокупности выйдут дороже, чем нанять еще 5 сммщиков который друг за другом проверят и переверстают ту же статью.
все это нужно чтобы раз-два в неделю сммщик не потратил +-полчаса на переверстку новой статьи из за кривого редактора одной из платформ, который почему-то не умеет в md (?)
не проще выйдет писать статью сразу в md, вместо google docs, написать конвертеры
md -> формат особо одаренной платформы, и настроить доставку на платформы через API, чем трахаться с google docs и роботами?насколько громко рухнут /встанут ваши важные маркетинговоо-сммно-пиарные процессы, когда на vc вдруг появится капча?
то же самое, но теперь если google docs завтра перестанет работать в россии
Doctor_IT Автор
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-документов, но и для других редакторов.
laatoo
при том что для md уже куча готовых редакторов с кнопочками, конвертеров хоть в html хоть в pdf, и прочих тулз и сервисов. он сам по себе предоставляет джентельменский набор тегов, который в том или ином виде будет на всех площадках (заголовок, ссылка, цитата, картинка итп). для авторов - редактор с кнопочками на ваш вкус, для разрабов - формат, с которым работать приятнее, чем с кучей span.classname из google docs.
в том что это говно придется поддерживать: трекать изменения на каждом отдельном на сервисе, ловить капчи, редиректы, и молиться, что завтра тот же vc чего нить не сломает. воткнут ребята css uglify в свой ci/cd - все, адьос.
на все это будете тратить человекочасы разрабов в обмен на чч сммщиков, что экономически нецелесообразно (за исключением ситуаций, где все это делает дома и бесплатно джун с горящими глазами чтобы выслужиться)
это цитата из статьи
Вопроса 4:
сколько у ваших ребят занимает верстка лонгрида для одной площадки вручную
сколько статей вы публикуете в месяц
насколько в % отличается зп разраба от сммщика
сколько человекочасов сммщика в месяц вы сэкономили, и через сколько лет отобьется хотя бы месячная (с ваших же слов) разработка, без учета поддержки?