Телеграмм чат группы docops страница 7

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

DocOps

2240 membersпожаловаться на группу

1
«
…
‹
2
3
4
5
6
7
8
›
…
»

2018 October 10

WTD Moscow #2: Никита Самохвалов, «Исчерпывающая документация на RESTful API».

Ещё один доклад на митапе Write the Docs в Москве 14 октября.

Никита Самохвалов из компании Нотамедиа расскажет о том, как документировать RESTful API с помощью Open API Specification.

Когда огрызки недодокументации на API вызывают негодование, а процесс написания оной доставляет немало хлопот, самое время подумать об автоматизации. В каком формате писать? Что писать? Как проверять? Приходите на митап, чтобы узнать, как изо дня в день инженеры «Нотамедии» решают подобные задачи.

Москва, 14 октября, начало в 13:00. Вы знаете, что делать.

#writethedocs #writethedocs_moscow

источник

86613:57пожаловаться #1

WTD Moscow #2: Данила Медведев, НейроКод.

Ещё один доклад на митапе Write the Docs в Москве 14 октября. Наконец мы добрались до управления знаниями.

Данила Медведев расскажет про инструмент для моделирования и хранения знаний под названием «НейроКод». Я видел этот инструмент и немного пользовался — очень крутая штука, принципиально отличается от всех баз знаний, вики и заметок, которые я когда-либо видел. Деталей не расскажу, потому что NDA. Зато их расскажет Данила.

Вот небольшое введение в тему от автора:

Новое комплексное архитектурное решение для решения основной задачи ИТ. DKR, OHS, усиление интеллекта, фрактальность, spatial hypertext, ZUI, моделирование, бизнес- и ИТ-архитектура, управление знаниями, PIM/GIM.

Концепция документации была сформулирована в книге "Traité de documentation: le livre sur le livre, théorie et pratique" Пола Отлета, создателя прото-Интернета и сооснователя Лиги Наций. Затем область документации разошлась на два направления — электронного документооборота ("Toward Paperless Information Systems" Фредерика Ланкастера) и человеко-машинного симбиоза ("Man-Computer Symbiosis" Джозефа Ликлайдера и "Augmenting Human Intellect: A Conceptual Framework" Дугласа Энгельбарта).

Я расскажу про второе направление. Для организации информации Энгельбарт предложил архитектуру Open Hyperdocument System/Dynamic Knowledge Repository. Из существующих концепций именно она лучше всего описывает, что мы делаем, разрабатывая технологию НейроКод. Эта технология также базируется на принципе фрактальной организации сетей информации и концепции масштабируемого интерфейса.

С помощью этой технологии пользователи и организации могут решать задачи моделирования своих процессов и систем, проектирования бизнес- и ИТ-архитектуры, управления знаниями. Цель её применения — сокращение непроизводительных затрат на обеспечивающие процессы и усиление коллективного интеллекта организации.

Если вы мало что поняли и не знаете все эти аббревиатуры — дайте я вас обниму, я тоже не знаю. Приходите на митап, поймём и узнаем вместе.

Зарегистрируйтесь и напишите своё настоящее имя и фамилию — вход строго по записи, охрана строгая.

#writethedocs #writethedocs_moscow

источник

99017:12пожаловаться #2

2018 October 11

Пирамида рецензирования

В разработке документации есть этапы (слои) рецензирования. Это порядок проверки документа, он примерно такой:

— сам перечитал и проверил на грубые ошибки;
— отдал коллеге на проверку грамотности, структуры и стиля;
— отдал эксперту на проверку смысла и содержания.

Если на конкретном этапе есть замечания, документ возвращают доработку, а не передают дальше.

А в тестировании есть понятие «пирамида тестирования». Тесты выполняются в таком порядке:

— модульные тесты проверяют логику отдельных деталей;
— функциональные тесты проверяют то, как работают фичи продукта;
— интеграционные тесты проверяют то, как части большого продукта работают вместе.

Если на конкретном уровне продукт не проходит тесты, то тесты на более высоком уровне не имеют смысла; продукт возвращают на доработку.

Кажется, между рецензированием документа и тестированием продукта есть что-то общее.

источник

116608:56пожаловаться #3

Нашёл хороший канал про UX, а в нём рекомендации, как писать тексты в интерфейсе:

https://t.me/uxnotes/186

Рекомендации авторам микротекста (теперь их называют UX-писателями 🙊):
— Сотрудничайте с дизайнерами, вместе прорабатывая структуры страниц и адаптируя дизайн под контент;
— Сотрудничайте с исследователями, чтобы говорить с пользователем на одном языке;
— Ориентируйте текст на пользователя. Пишите «вы ввели неверный пароль», а не «произошла ошибка входа»;
— Пишите лаконично, сначала говорите о важном;
— Убирайте жаргон и технические термины, чтобы расширить контекст;
— Призывайте пользователей к адекватным ситуации действиям. На кнопке под сообщением «неверный пароль» пишите не «Ок», а «Попробовать ещё» и «Восстановить пароль»;
— Переписывайте текст в стиле вашего бренда. Google вместо «Wrong password» напишет «That password doesn’t look right» (но это не точно);
— Проводите АБ-тесты.

Также в статье объясняется разница между голосом бренда и тоном сообщения, и есть пример трансформации текста, который это учитывает.

https://medium.com/советы-по-проектированию-интерфейсов/71db849397de

источник

112519:34пожаловаться #4

2018 October 12

WTD Moscow #2: Светлана Новикова, «Управление знаниями с помощью матрицы компетенций».

Продолжаем тему управления знаниями на митапе Write the Docs в Москве 14 октября.

Светлана Новикова работает в компании IPONWEB, в офисе которой мы с вами встретимся. Светлана расскажет про матрицу компетенций и как с ее помощью организовать управление знаниями в команде разработки:

Расскажу про саму технику матрицы компетенций, откуда она взялась, почему существует еще с 80х годов, и про то, как мы сделали матрицу 2.0. Мы использовали ее для «ориентации на местности», описав, какие явные и неявные знания есть в проекте, какие навыки нужны разработчику, а затем привязали к ней работу с артефактами знаний, включая, но не ограничиваясь документацией, например, knowledge sharing sessions, тренинги, обучения, тесты на понимание, чек-листы и другое.

Митап уже послезавтра. Регистрация закроется сегодня в 17 по Москве. Успейте зарегистрироваться.

Если не успеваете — посмотрите трансляцию, она будет доступна для всех.

источник

108016:09пожаловаться #5

2018 October 13

Что проверить в документации для заказчика? Что вы не упоминаете других заказчиков!

Опытом делится Николай Поташников на secrus.org.

Слайды: https://quizzical-jang-f3e5a7.netlify.com/

источник

121710:41пожаловаться #6

2018 October 14

WTD Moscow #2: Николай Волынкин, «Технический писатель 2.0.1».

Ещё один доклад на Write the Docs #2 в Москве 14 октября.

Николай — это я, автор канала @docops.

Поделюсь своими наблюдениями и мнением о том, какие задачи может выполнять технический писатель, чтобы принести больше пользы бизнесу; как эти задачи сформулировать и измерить успех. А ещё о том, куда движется профессия, что теряет ценность, а что наоборот, становится ценным.

Трансляция прямо сейчас: https://www.youtube.com/watch?v=p7G9VRkhjkA

Слайды: nick.volynkin.gitlab.io/techwriter20.

Версия 2.0.1 в названии — не случайность. Про «Техписателя 2.0» я рассказывал в субботу на конференции SECR. За день получил порцию обратной связи и немного обновил содержание. Надеюсь, что за следующий год обратной связи хватит на 3.0.

Обещаю, «Техписателя Х» не будет.

#writethedocs #writethedocs_moscow

источник

110613:44пожаловаться #7

2018 October 15

Ретроспектива конференции

Сам хотел написать об этом, но меня опередили. Подробный пост о том, как мы в Plesk проводим ретроспективу конференции и в чём польза от этой практики:

https://t.me/program_man/47

Products | People | Process

Хотел бы поделиться одной довольно хорошо работающей у нас практикой.

Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой-то полезный рецепт - то все хорошо. Но конференции сейчас большие, многопоточные, самих конференций много, всем везде не успеть.

Поэтому применяем простую практику - ретроспектива конференции. После поездки надо заполнить простую таблицу - какой доклад | какая оценка полезности | чем интересен | что хотелось бы применить; Таблицу потом обсуждаем, чтобы дополнить упущенное

Теперь польза:
1) участники выделяют и формулируют главное в услышанном. это очень важный этап в усвоении объемной информации, но мало кто достаточно дисциплинирован чтобы делать это самостоятельно
2) участники обсуждают свои оценки полезности доклада. это вскрывает разность взглядов, создает поле для дискуссии и расширения кругозора
3) не-участники видят какие доклады были наиболее полезны…

источник

109511:18пожаловаться #8

2018 October 17

Одна из причин, почему тексты в интерфейсе должен писать отдельный человек — не дать дизайнеру напихать в интерфейс пиктограммы без подписей.

Вот что здесь изображено? Я не понимаю половину этих картинок!

источник

115212:45пожаловаться #9

Обратная связь по митапу WTD Moscow #2.

Если вы были на митапе WTD Moscow #2 или смотрели трансляцию, пожалуйста, оставьте отзыв. Мы стараемся делать митапы чаще и лучше, так что ваша обратная связь нам сильно поможет.

Заполните форму, это займёт минут пять-десять: https://goo.gl/forms/d5ZInFDnwuNdhmtO2.

Если что, трансляция пока что доступна: https://www.youtube.com/watch?v=p7G9VRkhjkA. Через некоторое время вместо неё мы опубликуем отдельные видеозаписи докладов.

Отзыв о митапе WTD Moscow #2, 14 октября 2018

Спасибо вам, что пришли на митап!

Пожалуйста, ответьте на несколько вопросов. Этим вы поможете нам сделать следующие митапы интереснее и полезнее.

источник

168714:33пожаловаться #10

2018 November 08

Привет, давайте знакомиться!

Я работаю техническим писателем в Plesk, внедряю практику «документация как код», пишу в этом канале про документацию и управление знаниями, организую митапы на те же темы. Посты в канале обсуждают в чате @docsascode.

Сегодня я смотрю Highload++, на ходу пишу и оформляю конспекты, и сразу их публикую на GitHub. Это эксперимент, он уже точно удачный, так что я и дальше буду так делать.

Если ваша документация болит и требует улучшения — давайте обсудим, пишите @nick_volynkin. Я сейчас не беру заказы на разработку документации, но посоветую вам хорошего аутсорсера.

Если вы хотите рассказать о том, как вы пишете и автоматизируете доки, внедряете управление знаниями, решаете другие задачи бизнеса с помощью технического текста — это очень круто, жду вас на митапе в Москве, Питере, Новосибирске или других городах. Пожалуйста, заполните форму заявки, я вам отвечу.

До связи,
Николай Волынкин.

источник

199410:17пожаловаться #11

Вадим Мадисон из Авито, «Что мы знаем о микросервисах».

Вадим рассказывает в том числе про требования к документации для микросервиса. Они прям всерьёз требуют документацию и без неё не принимают микросервис от разработчиков. Вот что в неё входит:

— Описание сервиса. В двух предложениях, что сервис делает.
— Диаграмма архитектуры.
— Runbook. (Про них я скоро опубликую конспект из книги Seeking SRE)
— FAQ
— Описание API endpoints
— Labels — к какому продукту, функциональности и структурному подразделению относится сервис.
— Владельцы кода.

Конспект здесь: https://github.com/NickVolynkin/highload-2018/blob/master/1.1-microservices.md

источник

184711:02пожаловаться #12

Тернии контейнеризированных приложений и микросервисов
Иван Круглов, Booking.com

Очень толковый доклад о проблеме, двух неудачных и одной удачной попытке решения. Полный конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.2-per-aspera-ad-paas.md

Ключевые мысли:

Мысль 1: не стоит недооценивать способность кода выживать. Если вы что-то написали, этим внезапно будут пользоваться. Если там баги, люди с ними столкнутся и будут требовать исправлений.

Мысль 2: лучше скучный инструмент, который вы можете освоить, чем крутецкий, но слишком сложный.

Мысль 3: стоит заранее сформулировать ожидания пользователей от системы и системы от пользователей.

Мысль 4 (продолжение второй): kubernetes хорош, но важнее подумать о том, как вы будете его интегрировать в сществующую экосистему. Только если вы не стартап, все такие cloud-native.

источник

177911:57пожаловаться #13

Data Discovery в микросервисной архитектуре
Николай Голов, Avito

Доклад о том, как создать и поддерживать цифровой двойник всей инфраструктуры данных в большой компании — Persistent Fabric, «помнящая ткань».

Из ответов на вопросы после доклада: Fabric — это ткань, а ни в коем случае не фабрика. Не стройте фабрику данных (джависты, вам!), это тупиковый путь. ))

https://github.com/NickVolynkin/highload-2018/blob/master/1.3-data-discovery.md

источник

171712:53пожаловаться #14

«Судя по тому, что половина зала знакома с kubernetes, понятие „pod“ уже все знают».

Ох, смелое допущение. Не пишите документацию с такими допущениями.

источник

104313:10пожаловаться #15

Базы данных и Kubernetes
Дмитрий Столяров, Флант

Если вы настолько любите kubernetes, что хотите положить в него вообще всё, в том числе базы данных и другой stateful — вот вам подробная инструкция от Дмитрия Столярова из Фланта.

Если вы сомневаетесь, вот что об этом думает докладчик. Технологии развиваются волнами. Сначала технология появляется, потом она становится простой. Пока что стейтфул в k8s — уже можно, но ещё сложно, но со временем станет проще и лучше.

А ещё компания Флант делает инструмент https://github.com/flant/dapp.

Конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.4-bd-k8s.md

источник

167814:02пожаловаться #16

Apache Kafka как основа для велосипедостроения
Николай Сивко, okmeter.io

Очередной доклад с Highload 2018. Николай рассказывает о том, как сделать свою time-series database, используя Apache Kafka в качестве WAL (write ahead log).

Краткие выводы. Если вы хотите написать свою специализированную БД:

— Подумайте 100 раз
— разберитесь, как работают взрослые БД
— используйте kafka в качестве wal
— напишите остаток кода

Конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.5-kafka-bicycle.md

источник

167615:09пожаловаться #17

Разгоняем обработку событий до 1.6М/сек. Опыт Badoo
Александр Крашенинников, Badoo

Хороший ликбез про построение системы сбора статистики. А ещё Александр хвалит ClickHouse: «Инструмент классный, документация ваще огонь, я сам туда писал».
Конспект тут: https://github.com/NickVolynkin/highload-2018/blob/master/1.6-accelerate-events.md

Немного о том, как я пишу эти конспкты:

1. Смотрю, вроде бы всё понятно.
2. Моргнул.
3. Что это вообще на слайде? О чём докладчик говорит? Ничего не понятно!

источник

190516:11пожаловаться #18

Топ ошибок со стороны разработки при работе с PostgreSQL.
Алексей Лесовский, Data Egret

Отличный доклад. Алексей раскладывает все проблемы с PostgreSQL по категориям, перечисляет основные ошибки внутри категорий, предлагает решения.

А ещё как техписателю и иногда докладчику мне нравится вот что:
— Сразу объявил структуру доклада, очень чётко по ней шёл и в конце повторил тезисно. Так слушателям гораздо понятнее, где они находятся. А ещё так запоминается лучше. Будете о чём-то рассказывать — пожалуйста, делайте так.
— Термины вводил сразу на русском и английском. Это помогает сопоставить оригинальный термин с переводом и не плодить зоопарк терминов. Например: «Внешние таблицы (foreigh tables), декларативное партиционирование (declarative partitioning)». Так я тоже рекомендую делать в докладах и документации, особенно в переводах статей.

Ещё у Алексея есть документ с подборкой хороших практик: https://github.com/lesovsky/postgres-commandments/blob/master/README.md.

Конспект доклада: https://github.com/NickVolynkin/highload-2018/blob/master/1.7-postgresql-errors.md.

источник

181717:59пожаловаться #19

«Платформа» в Badoo: как мы построили инфраструктурную разработку.
Антон Поваров, Badoo

Доклад про становление инфраструктурной команды, её роль в компании, задачи и взаимодействие с разработчиками и бизнесом.
Конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.8-badoo-infradev.md

Это последний доклад на сегодня. Хорошего вам отдыха, встретимся завтра.

источник

185019:22пожаловаться #20

1
«
…
‹
2
3
4
5
6
7
8
›
…
»