Предыстория
Однажды на меня по рассылке вышла одна ИТ-компания и поручила подготовить статью для Хабра. Статью следовало подготовить из доклада двух немецких исследователей на одной, как сейчас модно говорить, «хакерской» конференции (https://media.ccc.de/v/39c3-hacking-washing-machines).
Рекогносцировка
Прежде чем взяться за эту задачу я, как водится, прояснил для себя ожидания заказчика: какой тип контента для него характерен и, соответственно, каковы ожидания его целевой аудитории и что это за аудитория.
Выяснилось, что компания регулярно исследует разные технические устройства и публикует об этом отчеты, вот парочка из тех, которые мне привели в качестве примера:
Итак, картинка сложилась — речь идет о сообществе реверс-инженеров, которые любят разбирать все до винтика и байтика (и даже битика), чтобы понять, как все устроено. На меня даже нахлынула ностальгия, я в постскриптуме позже расскажу почему. Следующий шаг — план работы над статьей и согласование его с заказчиком.
План
О том, что с заказчиком нужно делиться планом составления статьи, я научился, изучая копирайтинг у Дмитрия Кота, в книге «Продающие тексты. Модель для сборки». Я тогда учился делать продающие тексты, но не особо преуспел — информационные и научно-популярные мне были интереснее. В общем, отвлекся.
Итак, я зайдя на по ссылке ролика, я мысленно приготовился уже к мытарствам выкачивания видео и извлечения из него текста. Но увидел там под видео следующее:
Таким образом, и видео можно было легко скачать, и даже субтитры уже готовые лежат. Это сильно упростило мне подготовительный этап, и предоставил клиенту свой план (цитирую по переписке):
1. Поскольку готовые субтитры с таймингом есть, я вычищаю субтитры от тайминга, исправляю ошибки в субтитрах, делаю черновик перевода.
2. Черновик перевода структурирую по тематическим блокам/заголовкам. Возможно, я предложу сделать из этого выступления статью в двух частях (т.к. там два докладчика). Нерелевантные части отбрасываю (там были, например, довольно бесполезные вопросы от публики, часть из них я бы отбросил).
3. Перекраиваю текст согласно подготовленной структуре, делаю литературную правку.
4. Согласно скорректированному тексту, извлекаю из выступления скриншоты, для наглядности изложения (рисунки). К скриншотам делаю подрисуночные подписи, к рисункам/иллюстрациям в тексте проставляю ссылки.
5. Показываю черновик в гуглодоках. Если черновик ОК, могу занести в хабр и подготовить к публикации (это стандартная процедура для моих клиентов, которым я готовлю статьи в хабр), но нужен будет логин-пароль.
Согласование и излишества плана
5-й пункт моего плана не понадобился, конкретно этому клиенту такая услуга не нужна, ему удобнее оказалось заносить контент на Хабр самостоятельно. Что касается 2-го пункта, то тут тоже мне в некотором плане повезло, так как здесь полезных вопросов после доклада почти не было, публика задавала неинформативные вопросы.
Часто же с докладами или вебинарами бывает так, что публика задает вопросы по существу, и поскольку ты готовишь статью, а не интервью и не расшифровку, тебе нужно как-то эту информацию аккуратно и бесшовно по тексту растворить. Иногда вопросы бывают насколько не в тему, но информативные, что можешь подолгу сидеть и греть голову на тему «как впихнуть невпихуемое».
Как бы то ни было, клиент план одобрил, и работа началась.
Шаг 1: обработка субтитров и подготовка черновика перевода
Субтитры, которые я скачал со страницы доклада, были в таком формате:
Я прикинул, что здесь можно, конечно, вычистить таймкоды каким-нибудь скриптом с регулярными выражениями на Python, но это лишь одна операция. А мне для получения чернового перевода нужно было их сделать конвейером несколько:
1. Убрать таймкоды.
2. Исправить правописание исходного текста.
3. Исправленное правописание перевести начерно.
4. Черновой перевод почитать без опоры на оригинал (начисто).
Мне представилось, что все четыре операции я смогу завернуть в небольшой пайплайн для ИИ-ассистента. Так и получилось, после нескольких итераций корректировки промпта я стал в выдаче получать такой результат:
Дальше немного механического копипаста, и результат переезжает в Google Docs:
Прогон всей транскрипции и получение чернового перевода (правда без учета итераций корректировки промпта) по моему таймтрекеру занял 150 минут. Учитывая, что продолжительность видео составляет 56:57 минут, я считаю это неплохой результат.
Двигаемся дальше.
Шаг 2: структурирование черновика
Я много раз напарывался на одну и ту же ошибку, которая почти с неизбежностью встречи Титаника с айсбергом приводила к тому, что я снова возвращался на исходные позиции и начинал все заново (да, я плохо учусь на своих ошибках ;-).
Речь о том, что у текста должен быть скелет. Если ты ввязываешься в текст, не дав себе труда, чтобы сконструировать ему скелет — текст у тебя в итоге будет бесформенным и расползется как «мысь по древу».
Таким образом я приступил к разработке структуры и тоже обратился за помощью к ИИ, цитирую промпт:
Проанализируй предложенную ниже расшифровку доклада.
Сделай ее структурированное оглавление (заголовки только 1-го и 2-го уровней). Укажи с какого предложения начинается и каким заканчивается каждый тематический модуль, соответствующий заголовку 2-го уровня.
Адаптируй подготовленное оглавление под рассказ о техническом эксперименте, адаптированный для портала habr.com.
Выводи оглавление следующим образом:
--- Начало ---
1. Заголовок 1-го уровня
- Заголовок 2-го уровня
[Первое предложение модуля]
[Последнее предложение модуля]
- Заголовок 2-го уровня
[Первое предложение модуля]
[Последнее предложение модуля]
--- Конец ---
========= РАСШИФРОВКА =========
Спасибо за прекрасное…
========= КОНЕЦ РАСШИФРОВКИ =========
Далее работа строилась таким образом:
- Беру предложенный заголовок.
- Анализирую текст в ячейке. Если текст подходит под тематику заголовка, добавляю в этот модуль.
- Если не подходит, смотрю следующий заголовок и решаю - начинать новый модуль, или все же с некоторой корректировкой заносить его в прежний.
Так постепенно по заголовкам и подзаголовкам распределилась вся статья. Опять же, ИИ давал лишь ориентиры по заголовкам, но подходят они по формулировке и по уместности — решать должен райтер, т.е. я.
И вот, например, ИИ мне предложил первые три пункта с описанием рисков вскрытия техники назвать как “опасности”, но фраза “Опасность №3: техника активно используется семьей” мне показалась какой-то чересчур неправильной, и я на этом моменте немного завис — нужно было все это объединить под одним типом заголовка.
В итоге сделал “Предостережения…”:
В любом случае эта часть работы в целом проскочила быстро, гораздо более затратным по времени оказался следующий этап: добавление иллюстраций.
Шаг 3: добавление иллюстраций.
Обычно я прошу докладчиков выслать мне их презентации, и я оттуда выдираю все их картинки, схемки и скриншоты. В данном случае доступа к докладчикам у меня не было, их материалы на странице доклада не выкладывали, в своих GitHub они ничего про свои доклады тоже не говорили.
Остается одно: по несколько секунд перешагивать доклад и скриншотить все подряд на максимальном разрешении и с минимальным числом артефактов скриншотов.
Этим и занялся. Именно тогда и стало понятно что статью надо делить на две части — длина статьи приблизилась к 50 страницам, люди давно отвыкли читать такие трактаты.
Что касается артефактов, то больше всего меня напрягали иностранные надписи на картинках и черный фон. Получалось примерно так.
Поскольку целевой площадкой клиент обозначил Хабр, а там основной фон — белый, то и фон картинок тоже желательно бы сделать белым. С надписями тоже понятно, но иногда эти надписи попадают прямо на картинку и красиво их заменять не получается.
На помощь пришел снова ИИ, которого я попросил заменить фон и заменить надписи, чтобы в итоге получалось примерно так:
На это все равно уходило много времени (которое, я не уверен, что заказчик захотел бы оплачивать), я сообщил об этой рутине заказчику, и заказчик дал мне отбой на доработку картинок. Дальше я просто вешал скриншоты, а их обработку заказчик взял на свою сторону. На выходе получался черновик перевода, заголовки и картинки, без финальной вычитки и оформления — как на скриншоте ниже:
На шаг 2 и 3 согласно тайм-трекеру суммарно ушло 219 минут.
Основная работа мне еще предстояла.
Шаг 4 и 5: Подготовка черновика статей
Первым делом для начала работы над статьей я должен был написать «лид», как говорят современные райтеры, или «зачин», как его называет М. Веллер в своей «Технологии рассказа». Я вооружился его рекомендациями, почитал «зачины» из предложенных заказчиком статей, получилось такое:
Красным я отметил часть, которую на тот момент еще не согласовал с клиентом (я предложил ему поделить статью на две части, но на тот момент “добро” не получил).
После зачина налил себе ведерко кофе, вооружился виртуальным карандашом, и начал внимательно и вдумчиво читать каждую фразу, прикидывая для себя — смог бы я по этой русской формулировке сделать то же, о чем говорил докладчик? Могу ли я изложить ту же идею как-то более доступно? Правил по ситуации.
Также надо было под каждую картинку поставить подрисуночную подпись, чтобы было понятно, на что обращать внимание. Часто бывает так, что авторы-техписы грешат тем, что картинку вешают, а куда именно в ней смотреть, не разъясняют (хотя это не всегда очевидно).
Опять же, что писать под картинкой? Мне тема хоть и интересна, но я же не сам исследовал, вдруг не угадаю с подписью? Выбрал самую безопасную для себя стратегию — подвешивал в качестве подрисуночной подписи скорректированную цитату из текста (иногда не угадывал, приходилось искать другую цитату). Три раза выявлялись логические дыры, и тогда приходилось идти снова в видео, чтобы с удивлением там обнаружить, что я какую-то картинку - недостающий паззл из объяснения докладчика - пропустил.
С кодом тоже были затыки. Я плохо понимаю Assembler, но его обильно упоминают в докладе исследователи. Если я привожу листинг этого кода, как мне понять, какую подрисуночную подпись поставить? Приходилось советоваться с ИИ, и, поскольку на Хабре много таких читателей, как я, для их удобства я добавлял комментарии к листингам (хотя у докладчиков их не было). Получалось так:
В одном месте я подумал даже, что исследователь ошибся. В частности он сказал: «написал небольшой скрипт на Python, который перебирает все возможные значения первого параметра». Ниже приведен листинг:
fn cmd_unlock(param1: u8, param2: u8) {
if param1 != SECRET_KEY1 {
return;
}
if param2 != SECRET_KEY2 {
return;
}
unlock_interface();
}
Только этот код точно не на Python написан, ИИ подсказывает что на Rust. Выкрутился из этой ситуации тем, что поставил соответствующую формулировку на листинге: “Листинг 1. Проверка двух переданных параметров”. Получается, что на Python он писал один скрипт, а на скриншоте показал другой. Ок, логика сходится.
Справедливости ради отмечу, что в одном месте докладчик все-таки оговорился (по-другому я не смог объяснить эту фразу), о чем я и оставил комментарий клиенту:
Также возник вопрос почти с самого начала — как вести повествование? Если это авторская статья, то вроде как уместно писать от первого лица. С другой стороны, это же не заказчик проводил исследование, и надо писать от третьего лица, но статья в третьем лице и постоянные переформулировки на третье лицо мне показались длинноватыми. Сравните длину сами: “Мы решили посмотреть…” или “Исследователь Северин принял решение посмотреть”.
В общем я всю статью написал от первого лица, за что позже получил возврат на доработку от клиента с требованием все переписать все же от третьего лица.
Ну ок, надо было сразу спросить. Оплошал.
Закончил я статью тем, чем обычно заканчиваются статьи заказчика: пригласил подписаться, поблагодарил за уделенное внимание, предложил оставаться на связи.
Суммарно обе статьи составили 55 страниц, времени ушло по тайм-трекеру 659 минут.
Постскриптум
Работа над этим материалом у меня вызывала теплое чувство ностальгии по событиям почти 30-летней давности, когда я только-только знакомился с компьютерами, уже был FIDOшником (раньше была распространена сеть FIDOnet, а не Интернет), и я знакомился с миром игр через King’s Bounty.
Ресурсы в игре экономить не хотелось, и мой тогдашний друг, Евгений Азанов, научил меня, как быстро пополнять ресурсы и как из peasant-ов делать драконов. Нужно просто сохраниться, запомнить число крестьян, потом купить еще одного-двух, и снова сохраниться.
Дальше дело техники: открываешь сохраненный файл в hex-редакторе, находишь, в каком месте произошло изменение на ту величину, на которую увеличилось число крестьян (они тоже в шестнадцатеричном счислении выражены), и меняешь и код крестьян как типа войска, и код их количества (например, на FFFF, т.е. по максимуму), и всю игру сам черт тебе не страшен.
Самое интересное было вычислять в редакторе, где же эти крестьяне, феи, рыцари и т.п. находятся. Именно тогда я перестал бояться ковыряться в таком коде :).
Вот эти воспоминания меня и накрывали, когда я видел, как шаг за шагом исследователи добирались до самых глубин логики бытовой техники.
На этом все.
Спасибо за ваше внимание :).