Size: a a a

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

2020 April 26

IC

Ivan Cheban in DocOps-сообщество
Они десятилетиями писали в старых инструментах
источник

H

Hartmann in DocOps-сообщество
Не удивлюсь, если выяснится, что некоторые ещё помнят COBOL.
источник

FM

Fox Mulder in DocOps-сообщество
Ivan Cheban
Просто там много техрайтеров из прошлой эпохи. Коллегам с прошлого проекта всем было 40-50 лет
Жена ездила в голландию на слёт dita техрайтеров. Там много было как европецев, так и американцев. Все в возрасте. Все исповедуют docs as  code
источник

IC

Ivan Cheban in DocOps-сообщество
Получается, что самые продвинутые техрайтеры ездят на конференции, изучают новые инструменты. Но есть много ленивых, которым не хочется учить новое.
источник

IC

Ivan Cheban in DocOps-сообщество
И не везде они нужны эти новые инструменты, эта документация в коде
источник

H

Hartmann in DocOps-сообщество
На конференции ездят с другими целями. :)
источник

IC

Ivan Cheban in DocOps-сообщество
Многим нужны просто пдфки, сделанные из Ворда
источник

H

Hartmann in DocOps-сообщество
Ivan Cheban
Многим нужны просто пдфки, сделанные из Ворда
На сегодняшний день, так и есть.
источник

FM

Fox Mulder in DocOps-сообщество
есть моё мнение, оно может быть неверным, но я думаю, что на западе давным давно отказались от печатных мануалов
источник

IC

Ivan Cheban in DocOps-сообщество
Мы сами продвигаем эти ссг в массы. Рассказываем руководству, как это просто и красиво
источник

H

Hartmann in DocOps-сообщество
Fox Mulder
есть моё мнение, оно может быть неверным, но я думаю, что на западе давным давно отказались от печатных мануалов
На чём оно основывается?
источник

IC

Ivan Cheban in DocOps-сообщество
Но пдф документация и инструменты типа MadCap Flare ещё долго не отомрут
источник

H

Hartmann in DocOps-сообщество
Ivan Cheban
Мы сами продвигаем эти ссг в массы. Рассказываем руководству, как это просто и красиво
Если просто и красиво, то не одобрят. Им надо говорить насколько это выгоднее и дешевле текущих решений и соответственно сколько они смогут срезать бабла себе. :)
источник

FM

Fox Mulder in DocOps-сообщество
Hartmann
На чём оно основывается?
ну из рационального подхода - проще контент держать в сети
источник

H

Hartmann in DocOps-сообщество
Fox Mulder
ну из рационального подхода - проще контент держать в сети
Никого не защищаю и не оправдываю, тем более наличие печатных мануалов.
Первое, что в голову пришло по поводу контента в сети:
— наличие постоянного доступа в интернет;
— очень желательно иметь контроль над ресурсом, где выложен материал.
Оба момента необходимо учитывать.
источник

FM

Fox Mulder in DocOps-сообщество
Один фиг, всякие бумажные мануалы на технику не в ворде делаются
источник

ML

Maksim Lapshin in DocOps-сообщество
Хотел поделиться: мы в флюссонике начали имплементить такую идею, чтобы склеить тесты и документацию.

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

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

Это первый шаг из нашего списка:

1. сделать тестируемыми примеры конфига (мы здесь)
2. сделать тестируемыми примеры вызовов курла и прочих подобных утилит
3. сделать генерируемыми скриншоты
4. сделать детекцию сильного изменения скриншотов, нет ли багов
5. автогенерировать видеоскринкасты из записи прогона тестов (селениум)
источник

ML

Maksim Lapshin in DocOps-сообщество
Maksim Lapshin
Хотел поделиться: мы в флюссонике начали имплементить такую идею, чтобы склеить тесты и документацию.

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

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

Это первый шаг из нашего списка:

1. сделать тестируемыми примеры конфига (мы здесь)
2. сделать тестируемыми примеры вызовов курла и прочих подобных утилит
3. сделать генерируемыми скриншоты
4. сделать детекцию сильного изменения скриншотов, нет ли багов
5. автогенерировать видеоскринкасты из записи прогона тестов (селениум)
это к вопросу о том, зачем нужны форматы хранения документации, с которыми могут работать другие отделы.

Мы уже из документации выгружаем json, который вставляется в реакт-вебморду в нужных местах для нажатия на вопросик «что это за кнопка»
источник

H

Hartmann in DocOps-сообщество
Maksim Lapshin
это к вопросу о том, зачем нужны форматы хранения документации, с которыми могут работать другие отделы.

Мы уже из документации выгружаем json, который вставляется в реакт-вебморду в нужных местах для нажатия на вопросик «что это за кнопка»
Толково.
источник

H

Hartmann in DocOps-сообщество
Maksim Lapshin
Хотел поделиться: мы в флюссонике начали имплементить такую идею, чтобы склеить тесты и документацию.

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

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

Это первый шаг из нашего списка:

1. сделать тестируемыми примеры конфига (мы здесь)
2. сделать тестируемыми примеры вызовов курла и прочих подобных утилит
3. сделать генерируемыми скриншоты
4. сделать детекцию сильного изменения скриншотов, нет ли багов
5. автогенерировать видеоскринкасты из записи прогона тестов (селениум)
Чтоб скрины автоматом генерировались? То есть, чтоб руками каждый раз не делать? Я правильно понял?
источник