KE
а что вы пытаетесь сделать? задокать API plain текстом? и вам надо какую-то схему один раз объявить и везде ее вставлять? в reST есть только директива include.
Второе, не хочется лишний раз дублировать одно и тоже
Size: a a a
2019 September 04
RG
Второе, не хочется лишний раз дублировать одно и тоже
SY
Второе, не хочется лишний раз дублировать одно и тоже
RG
плюс еще можно вставить только часть другого документа по тегу или конкретные линии. https://asciidoctor.org/docs/user-manual/#include-partial
NV
Коллеги, а не подскажете, в asciidoc или в reST есть что-то типа $ref или allOf как в openAPI? Или я совсем не так их способ применения понял?
ещё можно сваггер переиспользовать: https://github.com/Arello-Mobile/swagger2rst
RG
ещё можно сваггер переиспользовать: https://github.com/Arello-Mobile/swagger2rst
я бы даже добавил https://github.com/Swagger2Markup
2019 September 05
V
А никто случаем не знает - в plantuml skinparam это единственный способ настроить более-менее кастомно отображение? Если я хочу один и тот же элемент (например, component) в разных ситуациях раскрашивать по-разному, то это только через стереотипы делать?
DE
Нет, некоторым элементам можно при вызове давать параметры
DE
Попробуйте использовать препроцессор
SY
кто-нибудь занимается вычиткой текстов в UI? вопрос: какие коллаборативные тулзы вы используете для аппрува текста и вообще элементов UI?
есть, конечно, комментарии в таких design tools как figma, например. но они плохо поддерживают процесс, в котором два пруфридера и 1 аппрувер. комментарии превращаются в длинные дискусии и нет нативного стейта для экранов типа “просмотрено пруфридером номер 1”, “…номер 2”, “…аппрувером”. тормозит процесс((
и нет автогенерируемых заданий типа “тебе надо просмотреть еще такие-то экраны”
есть, конечно, комментарии в таких design tools как figma, например. но они плохо поддерживают процесс, в котором два пруфридера и 1 аппрувер. комментарии превращаются в длинные дискусии и нет нативного стейта для экранов типа “просмотрено пруфридером номер 1”, “…номер 2”, “…аппрувером”. тормозит процесс((
и нет автогенерируемых заданий типа “тебе надо просмотреть еще такие-то экраны”
NV
кто-нибудь занимается вычиткой текстов в UI? вопрос: какие коллаборативные тулзы вы используете для аппрува текста и вообще элементов UI?
есть, конечно, комментарии в таких design tools как figma, например. но они плохо поддерживают процесс, в котором два пруфридера и 1 аппрувер. комментарии превращаются в длинные дискусии и нет нативного стейта для экранов типа “просмотрено пруфридером номер 1”, “…номер 2”, “…аппрувером”. тормозит процесс((
и нет автогенерируемых заданий типа “тебе надо просмотреть еще такие-то экраны”
есть, конечно, комментарии в таких design tools как figma, например. но они плохо поддерживают процесс, в котором два пруфридера и 1 аппрувер. комментарии превращаются в длинные дискусии и нет нативного стейта для экранов типа “просмотрено пруфридером номер 1”, “…номер 2”, “…аппрувером”. тормозит процесс((
и нет автогенерируемых заданий типа “тебе надо просмотреть еще такие-то экраны”
Git :)
EN
кто-нибудь занимается вычиткой текстов в UI? вопрос: какие коллаборативные тулзы вы используете для аппрува текста и вообще элементов UI?
есть, конечно, комментарии в таких design tools как figma, например. но они плохо поддерживают процесс, в котором два пруфридера и 1 аппрувер. комментарии превращаются в длинные дискусии и нет нативного стейта для экранов типа “просмотрено пруфридером номер 1”, “…номер 2”, “…аппрувером”. тормозит процесс((
и нет автогенерируемых заданий типа “тебе надо просмотреть еще такие-то экраны”
есть, конечно, комментарии в таких design tools как figma, например. но они плохо поддерживают процесс, в котором два пруфридера и 1 аппрувер. комментарии превращаются в длинные дискусии и нет нативного стейта для экранов типа “просмотрено пруфридером номер 1”, “…номер 2”, “…аппрувером”. тормозит процесс((
и нет автогенерируемых заданий типа “тебе надо просмотреть еще такие-то экраны”
у нас последний комментарий в дискуссии считается последней инстанцией. автогенерируемые задания - доска в Jira с колонкой в статусе proofread
RG
кто-нибудь занимается вычиткой текстов в UI? вопрос: какие коллаборативные тулзы вы используете для аппрува текста и вообще элементов UI?
есть, конечно, комментарии в таких design tools как figma, например. но они плохо поддерживают процесс, в котором два пруфридера и 1 аппрувер. комментарии превращаются в длинные дискусии и нет нативного стейта для экранов типа “просмотрено пруфридером номер 1”, “…номер 2”, “…аппрувером”. тормозит процесс((
и нет автогенерируемых заданий типа “тебе надо просмотреть еще такие-то экраны”
есть, конечно, комментарии в таких design tools как figma, например. но они плохо поддерживают процесс, в котором два пруфридера и 1 аппрувер. комментарии превращаются в длинные дискусии и нет нативного стейта для экранов типа “просмотрено пруфридером номер 1”, “…номер 2”, “…аппрувером”. тормозит процесс((
и нет автогенерируемых заданий типа “тебе надо просмотреть еще такие-то экраны”
вероятнее всего, надо построить процесс вокруг этой задачи. Многие делают в конфе, там же хранится материал на отсмотр, там же маршруты на согласование. Я бы сделал задачи в каком-то тасктрекере. Исходники хранил бы в гите
SY
проблема в том, что не хочется отрывать тексты от экранов UI. присутствие контекста критично. есть ли что-то из design tools в этой сфере?
RG
проблема в том, что не хочется отрывать тексты от экранов UI. присутствие контекста критично. есть ли что-то из design tools в этой сфере?
а в чем готовятся экраны и как их просматривают?
SY
figma. все смотрят туда
SY
у нас последний комментарий в дискуссии считается последней инстанцией. автогенерируемые задания - доска в Jira с колонкой в статусе proofread
примерно так сейчас и происходит, но процесс разваливается все равно
RG
примерно так сейчас и происходит, но процесс разваливается все равно
Саботаж? Или тупо невозможно отследить исполнение ?
SY
второе