Size: a a a

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

2019 March 12

ДС

Денис Старков in DocOps-сообщество
Antonio
Так что, на Гугл инициативу кто-то будет подаваться?
Наверное попробую, если не сильный загруз будет
источник
2019 March 13

NP

Nikolaj Potashnikov in DocOps-сообщество
Antonio
я тоже об этом думал, надо почитать, подходит ли оно в нашем случае. Спасибо
это функциональный посредник, убрать его нельзя.
про стереотип, думаю, лишнее. У нас юзер дока и мало кто умеет правильно читать uml
а почему не стереотипизировать так, как нравится? мне кажется, отходить от UML — это нормальная практика. Вот  доклад: https://vimeo.com/242213372, — в котором есть отличный вывод "Следование принципам вожнее нотации". Можно дружелюбную иконку специальную приделать.  Или даже, возвращаясь к первоначальному варианту, сделать что-то типа такого: https://www.plantuml.com/plantuml/img/SoWkIImgAStDuU9oLD2rorTmib88IYqiJIqkKJ3aSbB8rxLJS4OMuk9oICrB0Me00000. PlantUML очень ограничен по возможностям. Но в этом его сила. Как только разрешается полет фантазии, резко увеличиваются трудозатраты или требования к памяти "художника"
источник

NV

Nick Volynkin in DocOps-сообщество
Друзья, а кто из вас едет на CodeFest?
источник

СФ

Семён Факторович in DocOps-сообщество
я буду
источник

A

Antonio in DocOps-сообщество
Лучшее требование к техническому писателю, которое я когда-либо видел
Produce documentation with unified examples, consistent style, and jaw-dropping quality.
источник

NV

Nick Volynkin in DocOps-сообщество
третий показатель субъективный и неизмеримый )
источник

A

Antonio in DocOps-сообщество
по правде сказать, я такой комплимент недавно получал)
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
Nick Volynkin
третий показатель субъективный и неизмеримый )
вполне измеримый: https://icd.who.int/browse10/2016/en#/S03.4
источник

A

Antonio in DocOps-сообщество
» Classification of Diseases
ахаха))
источник

A

Antonio in DocOps-сообщество
ну, если в таком ключе, то да
источник

A

Antonio in DocOps-сообщество
Nikolaj Potashnikov
а почему не стереотипизировать так, как нравится? мне кажется, отходить от UML — это нормальная практика. Вот  доклад: https://vimeo.com/242213372, — в котором есть отличный вывод "Следование принципам вожнее нотации". Можно дружелюбную иконку специальную приделать.  Или даже, возвращаясь к первоначальному варианту, сделать что-то типа такого: https://www.plantuml.com/plantuml/img/SoWkIImgAStDuU9oLD2rorTmib88IYqiJIqkKJ3aSbB8rxLJS4OMuk9oICrB0Me00000. PlantUML очень ограничен по возможностям. Но в этом его сила. Как только разрешается полет фантазии, резко увеличиваются трудозатраты или требования к памяти "художника"
Я не говорю, что отходить от шаблонов плохо - наоборот, если можно где-то сымпровизировать и сделать проще для понимания, я всегда постараюсь это сделать. Но, поскольку UML для меня пока еще не настолько понятен, чтобы я четко понимал, что "вот здесь можно так сделать, а здесь импровизация вызовет двусмысленность и confusing", потому я пытаюсь сделать по фен-шую
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
PlantUML скорее не для фен-шуя, то ли он так мыслился, то ли так получилось.. возможно фен-шуй вообще сложен в концепции diagram as text
источник

NV

Nick Volynkin in DocOps-сообщество
А что такое фен-шуй в данном случае?
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
Точное следование нотации
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
например, в bpmn за нотацию не выпрыгнешь
источник

NV

Nick Volynkin in DocOps-сообщество
Если ни писатель, ни читатель не знают нотации, почему бы не писать как понятно, а не как правильно?
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
вот как раз ссылка на презентацию, которая эту мысль продвигает
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
на teamlead был какой-то мастер класс на эту тему... но там уже был перегиб палки
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
да.. нашел тезисы))
источник

NP

Nikolaj Potashnikov in DocOps-сообщество
источник