Size: a a a

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

2019 March 11

NV

Nick Volynkin in DocOps-сообщество
CodeFest: Три истории провалов с Git.

Привет! Впереди конференция CodeFest. Там на стенде компании Plesk будут небольшие доклады от наших ребят.  А я хочу провести там воркшоп о проблемах с Git.

На воркшопе обсудим несколько неочевидных ошибок, почему они происходят, как их решать и предотвращать.  Расскажу немного про то, как внутри устроены коммиты. Решим несколько практических задачек,  получим немного боевого опыта факапов и их починки. В конце вместе пособираем коммиты голыми руками: без использования git, только через Python/Ruby REPL.

Расскажите, стоит ли вообще это делать, придёте ли вы лично?
источник

NV

Nick Volynkin in DocOps-сообщество
Семён Факторович
и чтобы два раза не вставать: а какой нынче state-of-the-art редактор для rST, чтобы была подсветка и live preview?
Я пишу в PyCharm платном, там есть поддержка шаблонов Jinja 2 ещё
источник

NV

Nick Volynkin in DocOps-сообщество
Семён Факторович
а вот хочется посмотреть, как это сделано в каких-нибудь кастомных документационных решениях, без сваггера
А зачем кастомное решение?
источник

DB

Dima Boger in DocOps-сообщество
Свагер точно умеет, причем в разные аутентификационные схемы. Ещё некоторые распространяют документацию к API в виде импорт-файла для postman и прочих
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
Nick Volynkin
Я пишу в PyCharm платном, там есть поддержка шаблонов Jinja 2 ещё
Поддерживаю, удобнее IntelliJ IDEA и производных для себя пока не нашел

Плагинами можно прикрутить ещё и OpenAPI (Swagger), GraphQL, Markdown есть

Не IDE, а комбайн
источник

NV

Nick Volynkin in DocOps-сообщество
Для , Markdown там даже два плагина
источник

НН

Нац Нац in DocOps-сообщество
Один платный даже вроде как
источник

DB

Dima Boger in DocOps-сообщество
Кстати, я тут открыл для себя redoc
источник

DB

Dima Boger in DocOps-сообщество
https://rebilly.github.io/ReDoc/ и мне нравится
источник

DB

Dima Boger in DocOps-сообщество
дискриминаторы ❤️
источник

СФ

Семён Факторович in DocOps-сообщество
Nick Volynkin
А зачем кастомное решение?
В одном из наших проектов есть огромный массив документации в GitBook. В скором будущем нам надо будет добавлять туда описание небольшого RESTful HTTP API, и мы хотим сделать это бесшовно, оставаясь в гитбуке
источник

NV

Nick Volynkin in DocOps-сообщество
Вы же можете врезать страницы со сваггером просто
источник

NV

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

НН

Нац Нац in DocOps-сообщество
Nick Volynkin
отдельно собрать сваггер, а потом упаковать его в гитбук
:O
источник

СФ

Семён Факторович in DocOps-сообщество
у меня с ходу было ощущение, что это довольно костыльный путь, поэтому и хочется посмотреть, как это делают другие
источник

NV

Nick Volynkin in DocOps-сообщество
ну заинклюдить как-нибудь raw html
источник

СФ

Семён Факторович in DocOps-сообщество
текущая гипотеза в том, что чем сопрягать ежа с ужом, лучше все-таки сделать кастомное решение
источник

СФ

Семён Факторович in DocOps-сообщество
но, возможно, мы героически придумываем себе трудности
источник

СФ

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

СФ

Семён Факторович in DocOps-сообщество
Семён Факторович
Коллеги, а есть ли примеры документации на API с живыми примерами вида «нажал на кнопку, браузер отправил HTTP-запрос, на страничке отобразился реальный результат запроса», но чтобы была возможность загружать свою аутентификационную куку?
в общем, возвращаясь к изначальному вопросу, есть ли примеры такой документации, но _не_ в сваггере?
источник