Parawriter

Привет! Как проходит лето? Если вы хотели встряхнуться и срочно решить какую-нибудь интересную задачку, у меня есть для вас кое-что. 10 августа заканчивается приём заявок на TechWriter Days 4! Да-да, IV Международная конференция для технических писателей пройдёт в Москве 19–20 марта 2027 года, но задуматься о докладе можно и нужно уже сейчас! Если вы хотите поделиться своими знаниями или опытом с профессиональным сообществом, то поспешите. Приносите идеи докладов любой интересной и близкой вам тематики, но особенно организаторы ждут заявки на темы: * Docs-as-Code, API-документация и автоматизация * Внедрение нейросетей и AI-инструментов в работе техписа * Управление знаниями, локализация и UX-редактура * Инженерные и процессные кейсы в документировании Торопитесь и подавайте заявку до 10 августа! #карьера

Осторожно! Этот пост душный на пять закрытых форточек из пяти Недавно я придумывал определения для глоссария. Запнулся на термине «команда»: Команда — это функциональная единица [название подразделения], которая занимается разработкой, сопровождением и поддержкой сервисов. С содержанием всё ок, а вот выбранная форма мне никак не давала покоя. Смотрел я на неё и так, и эдак, и не мог понять: что же именно не так? Отнёс свой вариант в техписательский чат на беспристрастный аудит, и коллеги мне в первые же секунды раскрыли глаза: использование отглагольных существительных вместо простых глаголов действия. Да, действительно, простая и примитивная ошибка, азы инфостиля. Исправленный вариант звучал так: Команда — это функциональная единица [название подразделения], которая разрабатывает, сопровождает и поддерживает сервисы. Казалось бы всё — дело закрыто. Но кое-что меня продолжало волновать — почему я пропустил такую простую ошибку и почему до сих пор мне больше нравится мой первый вариант с отглагольными существительными? Я думал-думал и понял: всё дело в тонкостях стилистики текста (сейчас будет псевдофилологический разбор в духе Задорнова) В английском языке много времён. Есть, например, Present Simple, с помощью которого мы можем сообщить какой-то общеизвестный факт или описать регулярные действия: The team develops services — команда разрабатывает сервисы и занимается этим регулярно. Это в какой-то мере свойство и назначение команды — разрабатывать сервисы. А есть, например, Present Continuous, с помощью которого мы описываем действия, происходящие прямо сейчас или в определённый момент времени: The team is developing services — команда именно сейчас разрабатывает какие-то сервисы. Это не её свойство, это фиксация её деятельности в данный момент. В русском языке у нас всего одно настоящее время, поэтому явно обозначить разницу между свойством и состоянием в данный момент сложно. Но мне показалось, что конструкция «занимается разработкой сервисов» больше соответствует значению «обычно команда занимается тем, что разрабатывает сервисы», а конструкция «разрабатывает сервисы» — значению «команда сейчас разрабатывает сервисы, а что она будет делать потом, неизвестно». Согласен, этому нет рационального филологического подтверждения, но моё чувство стиля склоняется именно к такой интерпретации, поэтому я с чистой совестью в своём глоссарии оставил первоначальный вариант: Команда — это функциональная единица [название подразделения], которая занимается разработкой, сопровождением и поддержкой сервисов. Какой можно сделать из всего этого вывод? Составление практического стайлгайда, работающего в рамках конкретной документации — бесконечное занятие, потому как уровень погружения в кроличью нору стандартизации формулировок и используемых стилистических оборотов ограничен только душностью техписателя)) TLDR: Вместо исправления канцеляризма я оправдываю его использование на протяжении почти трёх тысяч знаков))) #карьера

Месяцы подготовки, планирования, согласований, прогонов и вычиток. Два часа прямого эфира из прекрасной студии в центре Москвы. Профессиональная команда за спиной, которая обеспечивает красивую картинку, хороший звук и надёжную трансляцию. Четыре человека в кадре, готовые поделиться своим опытом. И всё это — первый TechDocs митап от RWB! Я очень рад, что мы сделали это! 🦾 Спасибо всем причастным, а особенно моим коллегам Лиде, Кате, Паше, Жене, ещё одной Лиде, Люсьене, Тарасу и Илье. Спасибо всем вам, кто смог подключиться к трансляции и принять участие в нашем митапе. Спасибо всем, кто уже посмотрел или посмотрит запись на VK и YouTube 👀 Это было круто! 🍆 P.S. Мы очень хотим проводить больше тематических мероприятий по тех.документации и управлению знаниями, и вы можете нам в этом помочь! Пожалуйста, если вы посмотрели наш митап, заполните форму обратной связи 🕊 #карьера

⭐️⭐️ Уже сегодня — RWB TechDocs Meetup! Включайте трансляцию в 16:00: ⏹️VK ⏹️YouTube

Свершилось! Уже совсем скоро, в четверг 16 июля мы проведём онлайн-митап по технической документации! Наверняка кто-то сейчас спросил в недоумении: а кто это «мы»? Отвечаю: мы — это RWB, и мы проводим TechDocs митап! Впервые на арене! Вас ждут непревзойдённые мастера пера и акулы инструкций! Аксакалы документации поделятся своими практическими кейсами — спешите, спешите, спешите! Билет всего 4 сольдо Совершенно бесплатно! Регистрируйтесь и подключайтесь к нашей онлайн-трансляции! Мы ждём вас в четверг 16 июля в 16:00! --- Фух, вроде привлёк внимание. Будет действительно интересно — познакомим вас с техническими писателями RWB и расскажем, как мы работаем с документацией и процессами вокруг неё. Приходите, будем рады вас видеть!

Ежедневно я ревьюю много технической документации. Иногда мне попадаются тексты, которые подозрительно похожи на сгенерированные искусственным интеллектом. Доказать свои подозрения я не могу, но могу поделиться признаками, по которым я определяю AI-контент. 1. Длииинные тире Сами по себе длинные тире ничего не значат — я активно их использую даже в повседневной смартфонной жизни, не говоря уже о доке. Тут дело не в длине тире, а в способе организации предложений и фраз, при котором тире превращается в самый используемый символ после запятой и точки. Просто посмотрите: Если пайплайн завершился с ошибкой — rts-utility запустится автоматически. Для повторного запуска утилиты необходимо активировать её вручную — учтите это при выполнении отката деплоя. Ещё ИИ любит использовать тире как авторский знак — там где человек поставит запятую или двоеточие, ИИ влепит длинное тире. 2. Вопросы-пояснения Если в тексте встречаются подзаголовки в стиле «Что это значит?», «Как это работает?», «Почему так?», самое время насторожиться. Я заметил, что ИИ постоянно пытается всё объяснить, дополнить, разжевать и проглотить за читателя, да ещё и оформляет эти пояснения отдельными блоками-уведомлениями. В нашей документации так не принято — даже если мы что-то объясняем (почему какая-то штука работает именно так), то нативно встраиваем эти объяснения в текст, а не выделяем их цветными рамочками как в школьном параграфе. 3. Эмодзи Я стараюсь не иметь принципиальных позиций, но честно вам скажу — не люблю использовать смайлики в доке. Для меня это визуальный шум, который только отвлекает от текста. А вот ИИ их очень любит 😍 Надо отдать должное, он подбирает интересные и соответствующие контексту эмодзи и использует их умеренно (в основном в заголовках и шапках таблицы). Когда я вижу в тексте что-то такое, то сразу понимаю, кто приложил к тексту свою нейросетевую руку: ## Решение проблем 🔧 |Проблема⛔️ |Решение💡 | |-----------|----------| 4. Пробелы в конце строк Справедливости ради, это нельзя расценивать как полноценный маркер ИИ. Наличие нескольких пробелов в конце строк говорит лишь о том, что текст был скопирован из какого-то другого источника. Но этим другим источником вполне может оказаться чат с нейросетью 😏 Вполне пойдёт как опосредованный дополнительный признак, работающий в связке с более серьёзными приметами. Так, и что теперь? Да, собственно, ничего) Я не против использования ИИ для разработки технической документации, если это не нарушает политику безопасности компании. Тут скорее чисто спортивный интерес — обнаружить нейроконтент и доказать, что это всё-таки верблюд, а не настоящий человек 🐫 Если вы замечали ещё какие-нибудь характерные признаки нейроконтента, пишите в комментарии, будем делиться опытом ↓↓↓ #практика

О чём мечтает каждый писатель? Выспаться? Создать шедевр? Получить пулитцеровскую или хотя бы квартальную премию? И то, и то, и это. Но главная мечта любого порядочного писателя — опубликовать свою книжку. Пост чисто похвастаться если что, так что будьте готовы) Этот пункт теперь я считаю выполненным. Вы наверное помните, что я не только технический писатель, но ещё и немного хоровой композитор. Мы с моими друзьями-композиторами собрались вместе и выпустили сборник наших сочинений. Так уж вышло, что ведение этого проекта я взял на себя: нужно было скоординировать всех авторов (их двадцать четыре человека) и распределить между ними произведения, согласовать разные технические моменты (тональный план, состав хора и прочие музыкальные приколы), проследить за дедлайнами и не нарушить их самому, договориться с издательством, составить и скомпоновать сборник. В общем, получился интересный полноценный проджект-менеджерский кейс, который растянулся почти на год. Было много разнообразного общения, переговоров, поисков компромиссов и, конечно же, творческой созидательной работы. Кстати, проявить свои писательские качества тоже удалось: на правах составителя этого издания я написал к нему небольшую вступительную статью) Пожалуй, добавлю в своё резюме строчку про руководство проектами, но пока карандашом) #флуд и немножечко #практика

Привет! На работе я занимаюсь сопровождением внутренней документации инфраструктурных команд: кубернетисы, ансиблы, виртуальные машины, кластеры, поды, ноды, прокси, неймспейсы… Очень много разных сложных слов, которые по-разному взаимодействуют друг с другом и с читателями. По ходу пьесы я начал разбираться с тем, что это вообще такое и для чего оно нужно, стал постепенно погружаться в этот лор и со временем уже мог переводить с языка девопсов на литературный русский все эти непонятные фразочки типа «прокиньте порт», «прокатите ранбук» и «заскейлите параметры». Но я всё ещё оставался на уровне «поддерживаю беседу, повторяя фразы за другими и с умным видом кивая головой», а хотелось действительно понимать, как это работает. Стало ясно, что без учёбы не обойтись. Я начал искать подходящие курсы по системному администрированию на разных популярных платформах. В итоге решил остановиться на Яндекс Практикуме — мой приятель как раз учился там на системного администратора и хорошо о них отзывался. И вообще я давно хотел попробовать эту площадку. В общем, записался, прошёл вводный урок и понеслась) Что сказать? Много практики (название говорит само за себя)), много информации, клёвый препод, который ведёт воркшопы. А, ну и сами воркшопы конечно) Отдельно хочу отметить наличие облачных виртуальных машин с линуксом, на которых можно тренироваться почти без ограничений. Это оказалось самым важным для меня, так как свободного места на ноуте катастрофически не хватает на разворачивание даже скромной виртуалки. В общем, клёво, полезно, удобно. Есть ли минусы? Конечно. Для меня главным минусом оказалось наличие жёстких дедлайнов с возможностью слететь с курса. К такому мой график оказался не готов 🤪 А вы будьте готовы планировать своё время на обучение, чтобы не оказаться потом в неудобной ситуации) Справедливости ради, на весь курс всего два жёстких дедлайна, и времени, отведённого на выполнение контрольных работ, вполне достаточно, чтобы успевать в срок. В общем, продолжаю грызть гранит науки, учусь различать виртуализацию и контейнеризацию друг от друга, разворачивать сервисы и прокидывать доступы. Очень надеюсь победить не только линукс, но и свою прокрастинацию) #практика #карьера

Material for MkDocs — это популярный фреймворк для разработки документационных систем, который я активно использую в рабочих, домашних и парарайтерских проектах. Сейчас при сборке проектов на MkDocs Material выскакивает страшное предупреждение: ⚠️ Warning from the Material for MkDocs team MkDocs 2.0, the underlying framework of Material for MkDocs, will introduce backward-incompatible changes, including: × All plugins will stop working – the plugin system has been removed × All theme overrides will break – the theming system has been rewritten × No migration path exists – existing projects cannot be upgraded × Closed contribution model – community members can't report bugs × Currently unlicensed – unsuitable for production use А дело в том, что движок MkDocs, на котором работает MkDocs Material, уже пару лет не обновлялся, а его создатели анонсировали новую версию MkDocs 2.0, которая работает на другом топливе и принципиально несовместима с MkDocs Material. В связи с этим разработчики MkDocs Material решили замутить новый генератор статических сайтов с блэк-джеком и поддержкой функций MkDocs Material. Так в этой истории появился Zensical — независимый от сторонних движков инструмент для создания документационных проектов. Он должен вобрать в себя всё лучшее, что было в MkDocs Material, и стать полноценной ему заменой. Сам MkDocs Material никуда не пропадёт, но его поддержку прекратят в ноябре 2026 года. Авторы Zensical понимают, как дорог MkDocs Material пользователям, поэтому очень стараются сделать полностью совместимый продукт. Я, как активный пользователь MkDocs Material, решил протестировать Zensical, чтобы запланировать миграцию своих проектов. Ну что ж... Zensical, как любой молодой продукт, далёк от совершенства. Многое пилится и ещё будет пилиться, но это ожидаемо и не страшно. Но есть одна большая проблема, которая делает работу старых проектов в Zensical почти невозможной. MkDocs Material был любим пользователями по многим причинам. Одна из них — огромная библиотека родных и кастомных плагинов, значительно расширяющих функциональность создаваемых док.систем. Плагины подключались как сторонние расширения. Авторы решили не поддерживать в Zensical старые плагины от MkDocs. Вместо этого они часть плагинов хотят положить в коробку и превратить в базовые функции продукта, а остальное собираются реализовать с помощью новой модульной системы, позволяющей подключать к проекту сторонние модули с дополнительными фичами. На сайте Zensical даже есть план, функциональность каких старых плагинов будут адаптировать в первую и вторую очередь. Но увы, ничего из этого ещё не сделано, сроки реализации не указаны, а большое количество сторонних кастомных плагинов не попали ни в первую, ни во вторую очередь адаптации. В таких условиях я не могу перевезти ни один из своих рабочих или домашних проектов на новую платформу. Выводы Что же делать? Ведь впереди нас ждёт апокалипсис с появлением нового движка MkDocs 2.0, который сломает все наши док.системы! Я честно пытался найти подробную информацию о релизе MkDocs 2.0, но не нашёл. Если коротко, там всё очень сложно. Вполне вероятно, что релиз всё-таки состоится и MkDocs 2.0 реально сломает наши проекты, но! 1. Никто не мешает нам пользоваться старой рабочей версией MkDocs (можно прописать в пайплайне сборки установку стабильной версии MkDocs<2.0; в пакете MkDocs Material это ограничение вроде уже прописано) 2. Существует несколько альтернативных форков MkDocs (например, проект со звучным названием ProperDocs) которые будут продолжать развивать классическое mkdocs-сообщество. Есть тот же самый Zensical, который в своё время дорастёт до полноценного рабочего состояния. Что же решил я? Я решил продолжить пользоваться MkDocs Material, не обновлять MkDocs до версии 2.0 и ждать, когда в Zensical реализуют модульную систему и добавят все необходимые мне функции. В общем, конец света откладывается, живём и радуемся нашим прекрасным док.проектам на Material for MkDocs! #практика #docsascode

Ура! Спустя почти год наконец-то выходит второй пост рубрики #вопрос_ответ Какой формат работы с git выбрать для ведения документации в парадигме docs as code? На мой взгляд, самый подходящий формат работы в гите для документационных проектов небольших команд — github flow Этот процесс подразумевает наличие одной основной ветки master и нескольких фиче-веток для каждой отдельной задачи. Когда вам нужно что-то изменить в проекте, вы откалываете новую ветку от мастера, выполняете в ней работу и создаёте запрос на слияние (пул реквест в гитхабе или мерж реквест в гитлабе), в рамках которого ревьюер проверяет и согласовывает ваш текст, а потом выполняет этот запрос и вливает изменения в мастер-ветку, обновляя основную версию проекта. Github flow хорошо подходит для небольших документационных проектов, которые поддерживаются несколькими людьми. Несомненно ваш проект будет развиваться — процесс работы с гитом не отлит в граните, и вы можете адаптировать его под изменяющиеся реалии в вашей команде. Например, добавить еще одну основную ветку при появлении тестового стенда или настроить релизные ветки для интеграции обновления документации с продуктовыми релизами. Кстати, на следующей неделе мы начинаем последний поток большого мастер-класса «Docs as code для ребят постарше», в рамках которого мы попробуем себя в роли тех.писателя небольшой документационной команды, поработаем с подходом github flow и создадим собственные док.проекты, которые можно использовать как портфолио или личную базу знаний. Если хотите принять участие, пишите в личку @novillero, успевайте до выходных! #карьера #практика

Привет! Отличная новость для всех, кто хочет начать карьеру технического писателя (и не только) : YADRO приглашает на стажировку по более чем 30 направлениям, в числе которых есть и разработка технической документации! YADRO Импульс — это программа оплачиваемой…

Привет! Отличная новость для всех, кто хочет начать карьеру технического писателя (и не только) : YADRO приглашает на стажировку по более чем 30 направлениям, в числе которых есть и разработка технической документации! YADRO Импульс — это программа оплачиваемой стажировки в офисе или удалённо (что особенно круто). Вас ждут два с половиной месяца активной работы: погружение в реальные продукты компании и решение настоящих задач под руководством опытных наставников, а ещё насыщенная образовательная программа, направленная на развитие и укрепление профессиональных навыков. И самое классное — вы можете получить оффер и стать сотрудником компании YADRO! Что делать? Перейдите на сайт, выберите направление и подайте заявку на участие в стажировке. Рекомендую поторопиться — дедлайн уже 3 мая! И желаю удачи! #карьера #реклама

Привет! Что это? Это загадка-анонс в yaml-формате) Отгадали? Проверяйте себя: Третий и пока последний поток большого мастер-класса «Docs as code для ребят постарше» состоится с 11 по 29 мая! Вас ждут: Знакомство с гит и ssg, ci/cd, plantUML, openAPI и CSS, много практики и разработка собственного документационного проекта! А ещё шесть живых встреч: 1. Что такое Docs as code. Общие понятия 2. GIT для технического писателя 3. Создание домашнего док.проекта 4. Публикация и развитие док.проекта 5. Подключение разных типов документации к проекту 6. Кастомизация стилей док.проекта. Использование единого источника Хотите принять участие? Пишите в личку @novillero — я буду вас ждать) Стоимость сравнима с 45 чашками кофе в ресторанчике у дома ☕️☕️☕️ Будьте внимательны и осторожны! Бронь бесплатная, и я никому не пишу первым (только если вы не записывались в лист ожидания) P.S. Кто уже принимал участие, пишите в комментарии, как вам? Может, ваш отзыв поможет кому-нибудь сделать правильный выбор) #карьера

Продолжение ↓↓↓ 5. Проведите работу над ошибками Ещё раз проанализируйте ошибки и подумайте, почему она могла возникнуть. Возможно, дело в некорректном шаблоне, по которому вы пишете этот тип документации, или в несогласованном глоссарии, или в непрозрачном процессе сбора информации от коллег. Будет здорово, если благодаря негативной обратной связи вам получится разрешить какую-то системную проблему в документировании. 6. Не вините себя Повторю снова и снова — не вините себя, не дайте чувству самозванца овладеть вами. Ошибаться — это нормально, главное, умение признавать и исправлять свои ошибки — это признак высокого ума и хорошего специалиста. P.S. А вы получали негативную обратную связь по вашим текстам? Как её обрабатывали? Поделитесь с нами в комментариях — будет интересно почитать о вашем опыте. А если пост наберёт 59 птичек🕊, я так и быть, расскажу о парочке своих факапов)) #практика

Только представьте: вы написали хороший технический документ, опубликовали его в базе знаний и даже закрыли задачу, а на следующий день приходит ваш коллега из целевой аудитории этого документа и говорит, что ничего непонятно, написано плохо и вообще не то, что нужно. Или ещё хуже: вы работаете в компании несколько месяцев, выполняете задачи под руководством аналитика и казалось бы, всё отлично. Но на одном из ретро тимлид разработки спрашивает: а что там с документацией, когда уже у нас будет нормальная дока? Пора бы тех.писателю уже проявить себя. Это обобщённые примеры достаточно распространённых в реальной жизни ситуаций, после которых опускаются руки, падает самооценка и появляется желание переквалифицироваться в управдомы. Да, такое бывает: коллегам могут не нравиться ваши тексты. Нормально ли это? Вполне. Повод ли это ставить на себе крест и начать присматривать вакансии? Нет, не повод. Но что же делать? Как донести до коллег своё видение прекрасной документации и хорошего технического языка и при этом не впасть в уныние или не прослыть конфликтным токсиком, с которым дешевле не связываться? Уф, попробуем разобраться, как правильно реагировать на претензии, обрабатывать обратную связь и воспринимать критику. 1. Определите свою зону ответственности В первую очередь постарайтесь понять, по адресу ли критика. Может, вы и не можете повлиять на решение возникшей проблемы с докой. Кто-то жалуется, что в вашей базе знаний не хватает важных артефактов, а вместо них пишется второстепенная никому не нужная дока. А вы при этом работаете строго по задачам от руководителя и не формируете стратегию развития документации. Ваша ли это проблема? Нет, не ваша. Что делать? Выдохнуть, перекреститься и пойти к руководителю, чтобы передать ему. Но что делать, если претензия относится к результату непосредственно вашей работы? Выдохнуть, расслабиться и перейти к следующим пунктам) 2. Проанализируйте обратную связь Даже если на первый взгляд кажется, что вам выкатили пустые претензии, постарайтесь беспристрастно их разобрать и понять, что-же именно в вашем тексте не понравилось коллеге. Обязательно оставьте эмоции в стороне (и ваши, и вашего визави) и вычлените из «написано плохо», «ничего непонятно», «я совсем другое имел в виду» какие-то недостатки вашего документа. Попробуйте разложить претензии на две кучки: – Вкусовые предпочтения комментатора, которые расходятся с вашим вкусом – Реальные ошибки и недочёты с вашей стороны 3. Проработайте замечания К замечаниям из первой кучки подготовьте аргументированные возражения, чтобы донести коллеге ваше представление о хорошей документации. Замечания же из второй кучки нужно признать, принять и исправить, при этом не посыпая голову пеплом и не ругая себя за ошибки — ошибаться нормально, в этом нет ничего страшного. 4. Обсудите и согласуйте ваши исправления с «заказчиком» (автором замечаний) Свяжитесь с коллегой и сообщите ему о проведённой работе: предложите исправленную версию документа, обратите внимание на замечания из первой кучки и объясните, почему вы не стали их исправлять. Ситуации бывают разные, но всегда и при любых обстоятельствах старайтесь придерживаться простых правил рабочей коммуникации: а. Стремитесь найти компромиссное решение. б. При необходимости предлагайте альтернативные варианты. в. Аккуратно, но твёрдо отстаивайте критически для вас важные решения. г. Находите по возможности сильные аргументы: никогда не подтверждайте свою правоту слабыми компетенциями вашего оппонента. д. Не вовлекайтесь в дискуссию эмоционально: не переходите на личности, не хамите, не кричите. е. Если обсуждение зашло в тупик, эскалируйте его на вашего руководителя (или ваших руководителей). Ваша конечная цель не оправдаться, а решить возникшие претензии к документации и сделать документацию лучше. читай продолжение ↓↓↓

Друзья! Пришёл апрель (необычайно тёплый и солнечный), а с ним и наш двойной день рождения: 5 апреля родился я, а 6 апреля появился на свет канал Parawriter. В день рождения принято подводить итоги. Ну что ж, мне уже 32, я по-прежнему технический писатель, который идентифицирует себя как менеджер знаний) Работаю в ягодной компании, погружаюсь в разные хардовые штуки и размышляю над дальнейшим карьерным развитием. В этом году планирую продолжить выступать на конференциях и митапах — в запасе есть несколько интересных тем. Parawriter тоже именинник: каналу уже два года, и я очень рад, что вокруг него собралось столько активных, душевных, отзывчивых и увлечённых людей! Я надеюсь, что вы, как и я, хорошо проводите тут время 🙃 Самым значительным событием парарайтера за последний год стали два больших трёхнедельных мастер-класса по docs as code, которые мы провели в феврале и марте. Я долго собирался с мыслями и силами, чтобы подготовить и организовать это мероприятие, и вот, всё получилось) Было здорово! Новый год готовит нам новые вызовы — наверняка вы заметили, что телеграм работает уже не так, как прежде 🥲 Я подумал и решил не торопиться: канал останется в телеграме и будет жить своей прежней беззаботной жизнью. Но я планирую наконец-то довести до ума и опубликовать док.портал парарайтера, где я буду размещать много полезной информации, например, обновлённый бесплатный курс «Docs as code для самых маленьких» (ой, спойлер)). В эти праздничные для меня дни я хочу пожелать вам профессионального развития, новых интересных знаний, высоких зарплат, душевных сил, терпения и надежных прокси-серверов. Спасибо за то, что вы здесь! В качестве подарка и поздравления вы можете оставить комментарий под этим постом и рассказать, почему именно вы читаете парарайтера. А если у вас до сих пор премиум-подписка в телеграме, проголосуйте, пожалуйста, за нас — и на канале снова появится красивое оформление 🤗 Спасибо! #флуд

Привет! Ну что, ни месяца без мероприятий для технических писателей? 22 апреля в 16:00 Техкомпод проводит эксклюзивный онлайн-митап Техписатель: старт и прокачка. В программе 4 очень крутых эксперта (с тремя из них я знаком лично, и это правда очень классные…