Size: a a a

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

2018 August 05

ML

Maksim Lapshin in DocOps-сообщество
Ага. Еще есть поганое слово «тип»
источник

ML

Maksim Lapshin in DocOps-сообщество
У нас у видеокадра есть около 4 разных «типов»
источник

ML

Maksim Lapshin in DocOps-сообщество
Поэтому термин type табуирован даже в коде
источник

NV

Nick Volynkin in DocOps-сообщество
меня ещё со школы бесили термины «тип» и «вид».
источник

NV

Nick Volynkin in DocOps-сообщество
Учитель: «это типы %someshit%, а то — виды %someshit%, неужели разница не очевидна???»
источник

ML

Maksim Lapshin in DocOps-сообщество
Nick Volynkin
А у нас есть дамп — слепок, снятый с работающей VM. А потом мы из него запускаем новую VM и она тоже дамп )
В виртуалках вообще мозговзрывающие термины. Я полчаса первый раз не мог набрать virsh destroy, ведь я хочу просто тормознуть виртуалку, не удалять ее
источник

NV

Nick Volynkin in DocOps-сообщество
где-нибудь на праве: типы договоров и виды договоров. Чоооо?
источник

ML

Maksim Lapshin in DocOps-сообщество
Nick Volynkin
где-нибудь на праве: типы договоров и виды договоров. Чоооо?
А в праве своя терминология и гк рф имеет четкий и законченный перечень _вариантов_ договоров :)
источник

NV

Nick Volynkin in DocOps-сообщество
Maksim Lapshin
В виртуалках вообще мозговзрывающие термины. Я полчаса первый раз не мог набрать virsh destroy, ведь я хочу просто тормознуть виртуалку, не удалять ее
destroy — тормознуть, annihilate — выключить, desintegrate — удалить
источник

ИЦ

Игорь Цупко in DocOps-сообщество
Коллеги, разрешите ворваться к вам.
Проблема: есть пара-тройка человек, которые пополняют внутреннюю базу знаний. И каждый тянет одеяло на себя, не могут договориться о том как структурировать доки, как делать меню, навигацию и прочее.
Как договориться?
В программировании для этого есть фреймворки и паттерны. А с русским языком как быть? ) Он ж не компилируется и автотесты не напишешь.
источник

NV

Nick Volynkin in DocOps-сообщество
Написать стайлгайд.
источник

NV

Nick Volynkin in DocOps-сообщество
Это сборка правил о том, как писать доки: от пунктуации до структуры и целей.
источник

NV

Nick Volynkin in DocOps-сообщество
Каждый пункт можно обсуждать и спорить, но когда он принят, он становится строгим правилом.
источник

NV

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

ML

Maksim Lapshin in DocOps-сообщество
Игорь Цупко
Коллеги, разрешите ворваться к вам.
Проблема: есть пара-тройка человек, которые пополняют внутреннюю базу знаний. И каждый тянет одеяло на себя, не могут договориться о том как структурировать доки, как делать меню, навигацию и прочее.
Как договориться?
В программировании для этого есть фреймворки и паттерны. А с русским языком как быть? ) Он ж не компилируется и автотесты не напишешь.
Как вариант - провести выборы, сделать опрос среди коллег, которые этим пользуются. Но как и любые правильные выборы - под твоим чутким контролем
источник

NV

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

NV

Nick Volynkin in DocOps-сообщество
И ответственность за результат. )
источник

ML

Maksim Lapshin in DocOps-сообщество
Можешь заодно узнать фидбек от коллег и много полезного
источник

ML

Maksim Lapshin in DocOps-сообщество
Nick Volynkin
Ну и кажется, что должен быть один великодушный тиран, за которым будет решающее слово.
Для этого стоит уметь проводить _правильные_ выборы :)
источник

ML

Maksim Lapshin in DocOps-сообщество
Nick Volynkin
Каждый пункт можно обсуждать и спорить, но когда он принят, он становится строгим правилом.
А это вообще всегда так: есть этап обсуждения, есть исполнение. Обсуждать и критиковать вслух на исполнении - за такое под килем протаскивают
источник