Дык openapi же) шо там жсон, шо там, просто считал покрытие

Каждый элемент спецификации при перегонке api в формальную документацию (любым способом) имеет якоря. Предположим, нам надо посчитать покрытие "свободной документацией" путей (paths). Если есть путь, на якорь которого или на якоря подчиненных элементов нет ссылки в документации, значит путь мы пропустили.

Это хорошо ещё с той точки зрения, что при изменениях api мы можем контролировать, что ссылки ведут на существующие якоря (т.е. на реальные элементы).

давненько я не слышал термина "якорь"

пусть будет id

можно использовать невидимую ссылку. т.е. мы как бы говорим в свободной документации, что это место касается вот такого id в сгенерированной документации на api, но в конечном документе никакой гиперссылки показывать не нужно. такая необходимость тоже бывает

👋 хочу поделиться ссылкой на свой микроблог, который собирается из Markdown файлов небольшой самописной программой: https://chuhlomin.com/blog/2021/microblog.html?lang=ru

оффтопный вопрос: какие профиты даёт именно Go для подобного юзкейса?

у меня просто go (когда пришлось соприкоснуться) оставил впечатление очень вербозного языка с перегруженным синтаксисом

1. Код компилируется в небольшой бинарный файл → меньше размер докер-образа → быстрее pull на стороне CI
2. Меньше зависимостей → меньше риск обнаружения уязвимостей в зависимости; нет необходимости тянуть весь мир (намеренное преувеличение) как в nodejs
3. Мне субъективно нравится как работают шаблоны в Go

1. при нынешних скоростях интернета разве есть большая разница?
2. я ни слова не сказал про nodejs :)
3. а как они работают? У меня просто был опыт  переписывания slack-бота с Go на Clojure и (в том числе) именно процессинг mustache темплейтов на последнем был гораздо лаконичнее

1. Скорее всего нет, просто стремление к минимализму и скорости, в духе: если можно сделать образ маленьким, зачем делать его больше
2. Ну обычно я видел что используют 11ty для такого
3. Вот пример шаблона поста: https://github.com/chuhlomin/micro/blob/main/templates/post.html

1. premature optimisation? :)
2. к сожалению(или к счастью), не в курсе
3. похоже на типичный https://en.wikipedia.org/wiki/Mustache_(template_system), свёртка шаблона со структурой с данными обычно делается вызовом одной функции

1. Возможно, но взять тот же closure, ему нужна java, а это контейнер на сотни мегабайт который ещё и поднимается медленнее vs 10-15мб контейнера с одним go бинарником.
3. Если бы в го не было встроено шаблонов, то наверное делал бы с mustache
Тут скорее главная причина выбора go что он мне как-то ближе

1. ну, во-первых, необязательно, во-вторых, babashka же есть(21-22MB архив со всеми батарейками), в т.ч. с готовым экшном для гитхаба

> Тут скорее главная причина выбора go что он мне как-то ближе

а, ну вот это вполне себе тянет на реальную причину

я повторюсь, это исключительно на базе личных впечатлений, Go для меня остался языком, который тратит твоё время, вместо того, чтобы экономить

1. Не могу ничего сказать, для меня closure как свой отдельный мир, которым я не проникся

Тут смотря на чём экономить: писать нужно больше, зато читать (лично мне) проще и быстрее

с тем, что код читают больше, чем пишут - категорически согласен, с тем, что читать большее количество кода проще, чем меньшее - хотел бы поспорить

понятно, что речь не идёт про всякие J и прочие APL, я про языки для живых людей

возвращаясь к пункту 3, например, переписанный код для выкатывания чейнджлога к релизу уменьшился раза в 3-4, по сравнению с оригиналом, в читабельности даже выиграл, вместо императивного расписывания инструкций компьютеру пришлось просто описывать бизнес-задачу.