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

групп:

каналов:

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

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

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

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

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

go.backupland.com

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

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

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

Size: a a a

DocOps-сообщество

572 membersпожаловаться на группу
2020 January 16

СФ

Семён Факторович in DocOps-сообщество
из своего схожего опыта могу посоветовать следующее:
- нарисовать максимально высокоуровневую, но полную карту модулей/компонентов и написать к ней текстовый пересказ. Из каких модулей состоит система, каковы ключевые точки и принципы внутрисистемного взаимодействия, и пр
- очень полезно задаться вопросом «почему система задизайнена так» (вместо «как именно задизайнена система»). Во-первых, ответ на вопрос «почему» никогда невозможно извлечь из кода, во-вторых, этот вопрос часто важен для дальнейшей поддержки, а в-третьих, вопрос, поставленный так, очень хорошо снимает writer's block
источник
12:37пожаловаться#1

СФ

Семён Факторович in DocOps-сообщество
потому что вопрос (даже самому себе) вида «как устроена система» очень глубокий, и на него очень сложно ответить структурировано и полно
источник
12:38пожаловаться#2

SL

Sergey Lystsev in DocOps-сообщество
Семён Факторович
@slystsev , а вы случайно не оформляли ваши соображения по этой теме в виде отдельной статьи? Я бы с удовольствием почитал!
Лучше на ты 🙂 Я раньше никогда не думал, что это кому-то интересно может быть, кроме меня самого
источник
12:46пожаловаться#3

СФ

Семён Факторович in DocOps-сообщество
«как полностью задокументировать код продукта, чтобы сделать его поддержку/передачу автономной» — второй по частоте вопрос на митапах про документацию
источник
12:51пожаловаться#4

СФ

Семён Факторович in DocOps-сообщество
первый — «как правильно поддерживать документацию в актуальном состоянии»
источник
12:51пожаловаться#5

NV

Nick Volynkin in DocOps-сообщество
Sergey Lystsev
Лучше на ты 🙂 Я раньше никогда не думал, что это кому-то интересно может быть, кроме меня самого
+1 к Семёну, это очень востребованная тема.
источник
14:10пожаловаться#6

DB

Dima Boger in DocOps-сообщество
Спасибо, ребята и девчата, в голове стало немного яснее. Попробую обойти известные грабли)
источник
14:16пожаловаться#7

v

vladimir in DocOps-сообщество
Может кому-то будет полезно

Динамическая сборка и деплой Docker-образов с werf на примере сайта версионированной документации
Хабр
Динамическая сборка и деплой Docker-образов с werf на примере сайта версионированной документации
Мы уже не раз рассказывали про свой GitOps-инструмент werf, а в этот раз хотели бы поделиться опытом сборки сайта с документацией самого проекта — werf.io (его р...
источник
16:31пожаловаться#8

NV

Nick Volynkin in DocOps-сообщество
vladimir
Может кому-то будет полезно

Динамическая сборка и деплой Docker-образов с werf на примере сайта версионированной документации
Хабр
Динамическая сборка и деплой Docker-образов с werf на примере сайта версионированной документации
Мы уже не раз рассказывали про свой GitOps-инструмент werf, а в этот раз хотели бы поделиться опытом сборки сайта с документацией самого проекта — werf.io (его р...
Флант — красавчики! @i_tsupko
источник
16:50пожаловаться#9

ИЦ

Игорь Цупко in DocOps-сообщество
спасибо за добрые слова
источник
16:51пожаловаться#10

NK

ID:0 in DocOps-сообщество
Ребята из Фланта рассказали, как собирают документацию с помощью werf. Это их инструмент для автоматизации сборки докер-образов. Отличный пример принципа "drink your own champagne".

https://habr.com/ru/company/flant/blog/478690/
Хабр
Динамическая сборка и деплой Docker-образов с werf на примере сайта версионированной документации
Мы уже не раз рассказывали про свой GitOps-инструмент werf, а в этот раз хотели бы поделиться опытом сборки сайта с документацией самого проекта — werf.io (его р...
источник
16:56пожаловаться#11

NV

Nick Volynkin in DocOps-сообщество
👋
источник
17:41пожаловаться#12

ИЦ

Игорь Цупко in DocOps-сообщество
а вот и автор
источник
17:41пожаловаться#13
2020 January 17

K

Konstantin in DocOps-сообщество
Dima Boger
Я пока вижу это как-то так:
- Модуль за модулем прибраться в структуре проекта, выкинуть устаревшие вещи, пометить вещи, на которые нужно внимательнее посмотреть позже (неактуальная документация, устаревший код, штуки, которые могут стать скоро легаси)
- Обновить README, проверить его инструкции на чистой системе, убедиться, что покрыты основные кейсы и описан сценарий "как разрабатывать"
- Пройтись по всем внешним эндпоинтам и проверить актуальность документации для них. Описать странные юзкейсы, особенности работы, etc.
- Экспортировать трекер задач прямо в репозиторий 😈
- Пройти по всем модулям, задокументировать каждый, рассказать что часто меняется
https://arc42.org/overview/
arc42
arc42 Template Overview
arc42 is a template for architecture communication and documentation.
источник
13:51пожаловаться#14
2020 January 18

NK

ID:0 in DocOps-сообщество
Мы тут на хакатоне Профунктора делаем инструмент для описания мокапов интерфейса текстом. Не точных прототипов, которые дизайнеры рисуют, а чистов в функциональном стиле. «Здесь поля ввода логина и пароля, потом кнопка "войти"». Короче, mockups as code.

Нам интересны мнения людей, которые рисуют такие мокапы для техзаданий и прочего. Наверняка тут есть такие.
Сможете ответить на несколько вопросов?

Форма тут, пока только на английском, завтра переведу. https://forms.gle/ce1z4i4wYCk5oJs96
Google Docs
Do you make interface mockups? Please tell us about your experience.
Hello! We are a small group of enthusiasts building ImagineUI, a tool for describing interfaces in natural language. We need your help to make it as good as possible.
источник
20:44пожаловаться#15

NK

ID:0 in DocOps-сообщество
Кто хочет научиться локализации в docs as code? У нас в проекте есть библиотека на JavaScript, сайт и документация на Sphinx. Потрогаете пару форматов данных для перевода и онлайн-сервис для совместной работы. Это опенсорс, можно добавить в портфолио.

Перевод не тупой, фактически мы переводим DSL (доменно-специфический язык программирования). Надо много думать и исследовать отзывы пользователей.

Ищу переводчиков с английского на другие европейские языки. Переводить нужно сейчас, хакатон кончится в воскресенье вечером (но проект будет жить и дальше).

Пишите @nick_volynkin, если у вас хороший уровень языка и вы готовы переводить прямо сейчас.
источник
23:56пожаловаться#16
2020 January 20

NV

Nick Volynkin in DocOps-сообщество
Hi
источник
06:40пожаловаться#17

ИУ

Илья Улеско in DocOps-сообщество
@Nick_Volynkin а из чего родилась идея описывать мокапы текстом? В чём выгода?
источник
08:06пожаловаться#18

ИУ

Илья Улеско in DocOps-сообщество
Давайте сменим тему :)

Мы сделали альфа-версию тулзы для описания мокапов текстом. На сайте есть примеры и песочница, чтобы потестировать. https://imagineui.github.io

Очень интересно ваше мнение и фидбек :)
источник
08:06пожаловаться#19

NV

Nick Volynkin in DocOps-сообщество
Илья Улеско
@Nick_Volynkin а из чего родилась идея описывать мокапы текстом? В чём выгода?
хороший вопрос, мы на него ответим ещё на странице проекта
источник
08:07пожаловаться#20