Plesk changelogs.
Переделал страницу с журналом изменений Plesk. Весь вечер сижу и радуюсь результату. (Как мало надо трудоголику).
Под капотом там
— автомиграция контента, написанного за четыре года,
— мощь и тупость Jekyll,
— немного методологии БЭМ,
— совсем немного Jenkins pipelines, и
— changelog API на горизонте.
Хотите почитать статью с подробностями?
Если вам есть что сказать про вёрстку, информативность и полезность этой страницы — приходите с фидбеком. Можно в чат @docsascode, можно в личку @nick_volynkin.
Переделал страницу с журналом изменений Plesk. Весь вечер сижу и радуюсь результату. (Как мало надо трудоголику).
Под капотом там
— автомиграция контента, написанного за четыре года,
— мощь и тупость Jekyll,
— немного методологии БЭМ,
— совсем немного Jenkins pipelines, и
— changelog API на горизонте.
Хотите почитать статью с подробностями?
Если вам есть что сказать про вёрстку, информативность и полезность этой страницы — приходите с фидбеком. Можно в чат @docsascode, можно в личку @nick_volynkin.
Технические писатели и UX-писатели.
Автор «Плавучей редакции» Владимир пишет о профессиях технического и UX-писателя: https://news.1rj.ru/str/editboat/236.
Я считаю, что технические писатели владели инфостилем и занимались UX-writing'ом ещё до того, как появились оба этих слова. У нас есть выверенные процессы и стайлгайды, которые охватывают всё от запятых до business value. А ещё мы бережно относимся и умеем работать с терминами — в технических текстах и интерфейсах они очень важны. Интерфейсы, с которыми мы работаем — это не только кнопки на сайтах, мы умеем писать тексты для CLI и API. Встроенная документация в нативных библиотеках, всякие javadoc и docstring — это тоже интерфейсные тексты. Не все техписатели этим занимаются, но таких много.
Ещё там есть опрос об отношении между двумя профессиями. Для меня UX-писатель — это скорее специализация техписателя. Думаю, что заниматься только текстами или только документацией к сложному продукту — дело неэффективное. Но есть и другие продукты, где пользователь читает только текст в интерфейсе и задача писателя — донести нужные знания только через этот текст. Наверное, в них можно стать UX-писателем из дизайнера, копирайтера или аналитика.
Автор «Плавучей редакции» Владимир пишет о профессиях технического и UX-писателя: https://news.1rj.ru/str/editboat/236.
Я считаю, что технические писатели владели инфостилем и занимались UX-writing'ом ещё до того, как появились оба этих слова. У нас есть выверенные процессы и стайлгайды, которые охватывают всё от запятых до business value. А ещё мы бережно относимся и умеем работать с терминами — в технических текстах и интерфейсах они очень важны. Интерфейсы, с которыми мы работаем — это не только кнопки на сайтах, мы умеем писать тексты для CLI и API. Встроенная документация в нативных библиотеках, всякие javadoc и docstring — это тоже интерфейсные тексты. Не все техписатели этим занимаются, но таких много.
Ещё там есть опрос об отношении между двумя профессиями. Для меня UX-писатель — это скорее специализация техписателя. Думаю, что заниматься только текстами или только документацией к сложному продукту — дело неэффективное. Но есть и другие продукты, где пользователь читает только текст в интерфейсе и задача писателя — донести нужные знания только через этот текст. Наверное, в них можно стать UX-писателем из дизайнера, копирайтера или аналитика.
Telegram
Плавучая редакция
UX-писатели и технические писатели
Нанять писателя в команду разработки — для многих компаний это всё еще звучит страшновато. Но принципиально нового в этом нет. Писатели уже давно участвуют в проектах, только называются по-другому — технические писатели.…
Нанять писателя в команду разработки — для многих компаний это всё еще звучит страшновато. Но принципиально нового в этом нет. Писатели уже давно участвуют в проектах, только называются по-другому — технические писатели.…
Forwarded from Уютный IT адочек
Тут идёт голосование для вручения премии Highload++ 2019.
Предполагается, что премией должны быть награждены люди, которые оказали значительное позитивное влияние на отрасль в целом, продвинули её вперёд к добру, свету и позитиву. Голосование вот тут: http://www.highload.ru/moscow/2019/award (красная кнопка "Проголосовать" справа)
И не то, чтобы я призывал голосовать за какого-то кандидата, но именно это я сейчас и попробую сделать 🙂
Мне кажется, человек, который очень достоин премии, но может быть позабыт - это Филлип Кулин, автор https://usher2.club/ и неугомонный борец с безумием в органах власти. Роскомнадзор и попытки управлять интернетом никуда не денутся, некомпетентность управленцев - останется, и мне кажется, что без работы таких людей как Фил (а он не только делает сервисы, публично вскрывает абсурд и косяки в работе гос. органов, но и пытается общаться с госами на их языке, чтобы ну хоть как-то повлиять на ситуацию), в нашей действительности - никак.
Фил достоин, голосуйте, пожалуйста, за Фила.
Предполагается, что премией должны быть награждены люди, которые оказали значительное позитивное влияние на отрасль в целом, продвинули её вперёд к добру, свету и позитиву. Голосование вот тут: http://www.highload.ru/moscow/2019/award (красная кнопка "Проголосовать" справа)
И не то, чтобы я призывал голосовать за какого-то кандидата, но именно это я сейчас и попробую сделать 🙂
Мне кажется, человек, который очень достоин премии, но может быть позабыт - это Филлип Кулин, автор https://usher2.club/ и неугомонный борец с безумием в органах власти. Роскомнадзор и попытки управлять интернетом никуда не денутся, некомпетентность управленцев - останется, и мне кажется, что без работы таких людей как Фил (а он не только делает сервисы, публично вскрывает абсурд и косяки в работе гос. органов, но и пытается общаться с госами на их языке, чтобы ну хоть как-то повлиять на ситуацию), в нашей действительности - никак.
Фил достоин, голосуйте, пожалуйста, за Фила.
Я протормозил с анонсом, конечно. У вас есть ещё пара часов чтобы проголосовать ^. И я тоже поддерживаю Фила Кулина. Думаю, сейчас лучшее, что можно сделать для интернета — хотя бы не дать его сломать. Фил как раз этим и занимается.
Forwarded from Эшер II A+
#latex После доклада на GolangConf решил поделиться опытом создания презентации с помощью LaTeX:
https://habr.com/ru/post/471352/
Специально для этой статьи я сделал шаблоны для двух предстоящих конференций:
https://github.com/schors/hl2019theme
https://github.com/schors/sc2019theme
Вобщем, рекомендую. Программировать презентацию оказалось занимательно.
https://habr.com/ru/post/471352/
Специально для этой статьи я сделал шаблоны для двух предстоящих конференций:
https://github.com/schors/hl2019theme
https://github.com/schors/sc2019theme
Вобщем, рекомендую. Программировать презентацию оказалось занимательно.
DocOps
Курс по документированию REST API на русском языке. Тут случилось что-то невероятное. Курс Тома Джонсона по документированию REST API переведён на русский язык. Денис Старков сделал это сам, один, за полгода работы. Оригинальный Documenting APIs: A guide…
Перевод курса по документированию API теперь есть в форме сайта: https://starkovden.github.io.
Курс по документированию REST API | learnapidoc-ru
Курс по документированию API. Вольный перевод курса https://idratherbewriting.com/learnapidoc/
«Как замотивировать наших ребят делиться своим опытом через текст?» — недавно опубликованный совет от Людмилы Сарычевой. Хорошая тема на пересечении редактуры, деврела и управления знаниями.
Я там написал коментарий на основе своего опыта в Plesk и коллективной мудрости DevRel-сообщества. Если вам есть что добавить — присоединяйтесь.
Я там написал коментарий на основе своего опыта в Plesk и коллективной мудрости DevRel-сообщества. Если вам есть что добавить — присоединяйтесь.
Бюро Горбунова
Как замотивировать наших ребят делиться своим опытом через текст?
Как организовать редакцию в веб-студии, не привлекая копирайтеров? Хочется, чтобы тексты писали наши разработчики, шарящие в теме, а не сторонние авторы, хватающие информацию по верхам. Как замотивировать наших ребят делиться своим опытом через текст?
Опубликованы записи докладов и слайды недавней конференции API the Docs: https://pronovix.com/event/api-docs-amsterdam-2019.
Там всё про документирование кода и API.
Спасибо @aselivanava за ссылку :)
Там всё про документирование кода и API.
Спасибо @aselivanava за ссылку :)
Forwarded from Maria Ermakovich
Привет! Хочу устроить техрайтерский чятик в Беларуси — Write The Docs Минск. Когда наберем достаточно местных, сможем собраться на митап, кофе, другие напитки.
Добро пожаловать: https://news.1rj.ru/str/wtd_minsk
Добро пожаловать: https://news.1rj.ru/str/wtd_minsk
Как зачем переводить комментарии в примерах кода? Чтобы вот такие вот угарные примеры получались!
https://news.1rj.ru/str/tech_b0lt_Genona/1130
https://news.1rj.ru/str/tech_b0lt_Genona/1130
Telegram
Технологический Болт Генона
Отличные примеры
https://developer.mozilla.org/ru/docs/Web/API/ParentNode/append
https://developer.mozilla.org/ru/docs/Web/API/ParentNode/append
Когда-нибудь здесь будет канал с нормальными вакансиями для техписателей: @docops_jobs. С описанием задач, технологий и пользы от документации, а не задолбавших всех печенек. Но не сегодня. Как-нибудь доберусь. А пока что подписывайтесь. :)
Известный техписатель из Амазона Том Джонсон сделал крутейшие тесты на квалификацию, а потом разочаровался в них.
Follow-up to 4 Technical Writing Tests Post.
It's been a while since I've written a post that has received so many negative comments as 4 Technical Writing Tests to Screen Candidates. Although many people did like the tests and found them interesting or fun, quite a few people had more negative reactions. As a result, I'm scrapping the idea of multiple choice tests as a way to filter candidates...
Приходите в @docsascode, обсудим.
Follow-up to 4 Technical Writing Tests Post.
It's been a while since I've written a post that has received so many negative comments as 4 Technical Writing Tests to Screen Candidates. Although many people did like the tests and found them interesting or fun, quite a few people had more negative reactions. As a result, I'm scrapping the idea of multiple choice tests as a way to filter candidates...
Приходите в @docsascode, обсудим.
У нас теперь есть свой человек в Лондоне :)
https://news.1rj.ru/str/shut_up_and_write/120
https://news.1rj.ru/str/shut_up_and_write/120
Telegram
Shut up and write
Заметки с митапа Write the docs London
Курсы от Google📝
Об авторе: Шариф Салах (Sharif Salah) старший технический писатель в Google.
В компании Google уже несколько лет проходят курсы на которых любой сотрудник может научиться писать техническую документацию.…
Курсы от Google📝
Об авторе: Шариф Салах (Sharif Salah) старший технический писатель в Google.
В компании Google уже несколько лет проходят курсы на которых любой сотрудник может научиться писать техническую документацию.…
Обсуждали на кухне доклад Александра Тоболя про UDP. Когда-то я конспектировал этот доклад с постоянными паузами и повторами видео. Александр рассказывает быстро, а плотность информации довольно большая, так что сходу сложно уловить весь смысл. Интересно, сколько успели понять те, кто слушал доклад вживую на конференции.
Ничего не напоминает? Это же UDP. В докладе про UDP!
Ничего не напоминает? Это же UDP. В докладе про UDP!
Forwarded from Arina Ballerina
Привет! TLDR
Пару месяцев назад я решала проблему — чем генерить документацию в PDF, если у тебя доку собирает MkDocs, который из коробки этого не умеет. Просила тут помощи и обещала здесь же отписаться, что пробовала, к какому решению пришла. Я начинающий автоматизатор, могу написать простенький скрипт на баше или питоне, не больше. В сторону генерации из HTML я сразу не пошла, так как там не одностраничный документ и CSS для меня это слишком сложно. Поэтому я смотрела конвертеры из Markdown в PDF.
Что я пробовала:
1. Конвертер https://hub.docker.com/r/fiware/md2pdf/. Мне с разбега даже hello world не дался, нужно разбираться в настройках. Если бы не помог @glu0n, я бы может и не справилась. Результат очень не очень внешне + не работает с кириллицей из коробки. Зато не нужно собирать всё в один файл, он это делает за вас, ему можно скормить тот же конфиг что уже есть в MkDocs.
2. Typora https://typora.io/. Самое простое и быстрое решение. Делает все через Pandoc, очень хорошо настроен шаблон, PDF получается эстетичный, правильно подсвечивает код. Можно скачать десктопное приложение. Cобственно я так и сделала, когда мне нужно было сделать PDF быстро. Минусы: все равно кое-чего не хватает например, в готовом PDF нет номеров страниц, нужно как-то собирать все md-файлы в один, ну и герерить придется руками (зато GUI).
3. Foliant https://github.com/foliant-docs. Самый серьезный инструмент, делает всё, что нужно. Тоже генерит через Pandoc. Тоже не нужно собирать ему один файл. Разобраться самостоятельно можно, есть документация, хотя мне все-таки потребовалась помощь создателей, но они слава богу отвечают в чате. Из коробки PDF у меня получился достаточно приличного качества. Но стало понятно, что если я хочу что-то поправить, то нужно будет самой настраивать шаблон, плюс Foliant по-моему нет смысла использовать только для сборки PDF, он не использует ваш конфиг MkDocs, использует свой конфиг с содержанием (foliant.yml). По-хорошему нужно делать сборку всех форматов доки Фолиантом.
4. Pandoc. Полный контроль над процессом, но настройка, самое сложное — LaTeX-шаблон. Ну и собирать все md-файлы в один тоже придется. Килограммы документации, и она неплохая.
Как я генерирую PDF в итоге:
Стало понятно что все равно придется настраивать LaTeX-шаблон. И надо склеить md-файлы в один. Так как я контрол-фрик, да и сборка html-документации в MkDocs у меня уже настроена, я не стала склеивать файлы сторонней тулзой. Я написала короткий Python-скрипт, который парсит YAML-конфиг MkDocs и собирает один md-файл. Этот один я скармливаю Pandoc. Использую --pdf-engine=xelatex. Обложку с названием документа дизайнер сделал в PDF и я ее приклеиваю в конце с помощью pdfunite. Осталось разобраться в туче параметров tex-шаблонов.
Пару месяцев назад я решала проблему — чем генерить документацию в PDF, если у тебя доку собирает MkDocs, который из коробки этого не умеет. Просила тут помощи и обещала здесь же отписаться, что пробовала, к какому решению пришла. Я начинающий автоматизатор, могу написать простенький скрипт на баше или питоне, не больше. В сторону генерации из HTML я сразу не пошла, так как там не одностраничный документ и CSS для меня это слишком сложно. Поэтому я смотрела конвертеры из Markdown в PDF.
Что я пробовала:
1. Конвертер https://hub.docker.com/r/fiware/md2pdf/. Мне с разбега даже hello world не дался, нужно разбираться в настройках. Если бы не помог @glu0n, я бы может и не справилась. Результат очень не очень внешне + не работает с кириллицей из коробки. Зато не нужно собирать всё в один файл, он это делает за вас, ему можно скормить тот же конфиг что уже есть в MkDocs.
2. Typora https://typora.io/. Самое простое и быстрое решение. Делает все через Pandoc, очень хорошо настроен шаблон, PDF получается эстетичный, правильно подсвечивает код. Можно скачать десктопное приложение. Cобственно я так и сделала, когда мне нужно было сделать PDF быстро. Минусы: все равно кое-чего не хватает например, в готовом PDF нет номеров страниц, нужно как-то собирать все md-файлы в один, ну и герерить придется руками (зато GUI).
3. Foliant https://github.com/foliant-docs. Самый серьезный инструмент, делает всё, что нужно. Тоже генерит через Pandoc. Тоже не нужно собирать ему один файл. Разобраться самостоятельно можно, есть документация, хотя мне все-таки потребовалась помощь создателей, но они слава богу отвечают в чате. Из коробки PDF у меня получился достаточно приличного качества. Но стало понятно, что если я хочу что-то поправить, то нужно будет самой настраивать шаблон, плюс Foliant по-моему нет смысла использовать только для сборки PDF, он не использует ваш конфиг MkDocs, использует свой конфиг с содержанием (foliant.yml). По-хорошему нужно делать сборку всех форматов доки Фолиантом.
4. Pandoc. Полный контроль над процессом, но настройка, самое сложное — LaTeX-шаблон. Ну и собирать все md-файлы в один тоже придется. Килограммы документации, и она неплохая.
Как я генерирую PDF в итоге:
Стало понятно что все равно придется настраивать LaTeX-шаблон. И надо склеить md-файлы в один. Так как я контрол-фрик, да и сборка html-документации в MkDocs у меня уже настроена, я не стала склеивать файлы сторонней тулзой. Я написала короткий Python-скрипт, который парсит YAML-конфиг MkDocs и собирает один md-файл. Этот один я скармливаю Pandoc. Использую --pdf-engine=xelatex. Обложку с названием документа дизайнер сделал в PDF и я ее приклеиваю в конце с помощью pdfunite. Осталось разобраться в туче параметров tex-шаблонов.
Агрессивный наброс на документацию и вполне адекватный ответ. https://github.com/valor-software/ngx-bootstrap/issues/5566
GitHub
ngx-bootstrap documentation sucks! · Issue #5566 · valor-software/ngx-bootstrap
The documentation for ngx-bootstrap sucks! Do you expect developers to read your mind or to gleen over your source code just to understand how this mediocre mush works? Don't know what I am...
Пара отличных докладов с последнего Гипéрбатона (это такая конфа Яндекса про документацию).
Forwarded from Александр Парень
Видеозаписи блиц-докладов с Мини-Гипербатона в Санкт-Петербурге.
Александр Парень
▪️Особенности генерации PDF-файлов из Confluence Cloud.
Андрей Емельянов
▪️Как приручить Pandoc?
Александр Парень
▪️Особенности генерации PDF-файлов из Confluence Cloud.
Андрей Емельянов
▪️Как приручить Pandoc?
YouTube
Александр Парень. Особенности генерации PDF-файлов из Confluence Cloud. Яндекс. Мини-Гипербатон.
1. Какие проблемы могут возникнуть при генерации PDF-файлов из Confluence Cloud?
2. Как искать решения по продуктам Atlassian в официальном сообществе?
2. Как искать решения по продуктам Atlassian в официальном сообществе?