Size: a a a

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

2020 July 10

NV

Nick Volynkin in DocOps-сообщество
Fox Mulder
А вот у  меня такой вопрос исходя из рекламы канала -
где подготовка программистов сильнее: ВМК, МехМат или ИТМО?
🤷‍♂️
источник

НН

Нац Нац in DocOps-сообщество
Канал отличный
источник

ML

Maksim Lapshin in DocOps-сообщество
Fox Mulder
А вот у  меня такой вопрос исходя из рекламы канала -
где подготовка программистов сильнее: ВМК, МехМат или ИТМО?
Примерно одинаково: личные флуктуации сильно выше, чем разница в качестве
источник

FM

Fox Mulder in DocOps-сообщество
Maksim Lapshin
Примерно одинаково: личные флуктуации сильно выше, чем разница в качестве
спасибо
источник
2020 July 13

NK

ID:0 in DocOps-сообщество
Видео опубликовали. Напоминаю: на TechLeadConf рассказывали про инструменты для документации, с фокусом на доки от инженеров и для инженеров. Документирование кода, диаграммы и схемы, публикация в Confluence, вот это всё. Костя Валеев рассказал про Foliant, Семён Факторович — про Pandoc, а я про Sphinx.

https://youtu.be/4qv0YNtuRlE
источник
2020 July 14

NK

ID:0 in DocOps-сообщество
Раздают книжку Developer, Advocate!

Developer, Advocate! — книга о сообществах разработчиков, технопиаре, developer relations и всём таком. Компания Azul наняла автора книги Geertjan Wielenga и по такому случаю бесплатно раздаёт электронную версию книги. Конечно, в обмен на подписку. :)
источник

ME

Maria Ermakovich in DocOps-сообщество
великолепный язык
источник

NV

Nick Volynkin in DocOps-сообщество
Maria Ermakovich
великолепный язык
Это Олег Чирухин, он вообще прекрасный человек и пишет хорошо
источник

СФ

Семён Факторович... in DocOps-сообщество
Nick Volynkin
Это Олег Чирухин, он вообще прекрасный человек и пишет хорошо
И ведь он в какой-то момент рассматривал карьеру техписателя!
источник

NV

Nick Volynkin in DocOps-сообщество
Ну в широком смысле он и есть. Только он ещё занимается деврелом, маркетингом и я бы даже сказал что журналистикой.
источник
2020 July 15

J

JTProgru in DocOps-сообщество
Товарищи, приветствую!
Хочу внедрить у себя в компании https://foliant-docs.github.io для ведения документации в Confluence.
Если тут есть те кто им пользовался, поделитесь опытом (ткните в доку) как правильно указывать внутренние ссылки:
Главная страница пространства а на ней ссылка на соседнюю страницу в этом пространстве. Ну и так далее.
источник

НН

Нац Нац in DocOps-сообщество
Привет, тебе сюда https://t.me/foliantdocs
источник

J

JTProgru in DocOps-сообщество
Спасибо тебе добрый человек!
источник
2020 July 16

NK

ID:0 in DocOps-сообщество
​​Будет легче, если сначала прочитаете...

В начале статьи бывает полезно написать о предусловиях для чтения. Что читатель должен заранее сделать или прочитать, чтобы понять эту статью? Например, в статье про настройку X можно дать ссылку на установку этого X. Так читатель не потеряется и сначала вернётся к установке, если ещё не сделал её.

Встретил отличный пример такой ссылки в доке Google Search Console:
«This report is much easier to understand if you have read how Google Search works first.»

Это так душевно звучит, с заботой о читателе.
источник
2020 July 17

MS

Mikhail Sapozhnikov in DocOps-сообщество
YouTube
Непрерывное применение архитектурных практик как способ снижения рисков / Александр Лучков
Проблема документирования технических решений обсуждается часто, долго и с большими разногласиями. Широко распространены в зависимости от отрасли два лагеря "формалисты-бюрократы" и "гибкие-либералы".
Из моего опыта аргументы вторых сводятся к утверждениям  похожим на:
- "Документация устаревает быстрее, чем обновляется, поэтому в ИТ системе единственная актуальная документация - это код"
- "Документация нужна только там, где нужно её сдавать. Поэтому необходимо писать только ту документацию, которая указана в контракте"
- "Документация - это дорого и поэтому лучше делать продукт интуитивным"
- "Формализмы - это затраты на их изучение, а рынок настолько широк, что невозможно научить всех. Поэтому лучше писать каждый как умеет."

Первые же говорят о том, что:
- "Хорошая документация должна быть"
- "Документация делает процесс разработки управляемым"
- "При хорошей документации RTFM является эффективным способ обучения сотрудников"
- "Документация обеспечивает возможность поддерживать качество продукта…
источник

NV

Nick Volynkin in DocOps-сообщество
Mikhail Sapozhnikov
YouTube
Непрерывное применение архитектурных практик как способ снижения рисков / Александр Лучков
Проблема документирования технических решений обсуждается часто, долго и с большими разногласиями. Широко распространены в зависимости от отрасли два лагеря "формалисты-бюрократы" и "гибкие-либералы".
Из моего опыта аргументы вторых сводятся к утверждениям  похожим на:
- "Документация устаревает быстрее, чем обновляется, поэтому в ИТ системе единственная актуальная документация - это код"
- "Документация нужна только там, где нужно её сдавать. Поэтому необходимо писать только ту документацию, которая указана в контракте"
- "Документация - это дорого и поэтому лучше делать продукт интуитивным"
- "Формализмы - это затраты на их изучение, а рынок настолько широк, что невозможно научить всех. Поэтому лучше писать каждый как умеет."

Первые же говорят о том, что:
- "Хорошая документация должна быть"
- "Документация делает процесс разработки управляемым"
- "При хорошей документации RTFM является эффективным способ обучения сотрудников"
- "Документация обеспечивает возможность поддерживать качество продукта…
О, это интересно, спасибо
источник

ИЦ

Игорь Цупко... in DocOps-сообщество
Коллеги, я хочу быстро, нет, БЫСТРО рисовать формы (инпуты, текстареи, галки, опшны и обязательно файлы всех цветов и размеров) в виде html+css+js.
- Чтобы они не были страшными, как в Google Forms
- Чтобы процесс создания формы был сопоставим по времени с "накликать в Гугл формах" (вариант с написанием кода не исключаю, но это должно быть стремительно)
- Чтобы результирующую форму как виджет можно было корректно вставить в любой сайт и оно не разъёбывало всё нахрен и не тянуло 100500 зависимостей паравозиком

Есть идеи, как это можно сделать?
источник

НН

Нац Нац in DocOps-сообщество
Тильда или вебфлоу с экспортом?
источник

ИЦ

Игорь Цупко... in DocOps-сообщество
^_^ как же я мог забыть про экспорт в Тильде

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

ИЦ

Игорь Цупко... in DocOps-сообщество
у Тильды по крайней мере
источник