А чем лучше YAML'a? На TOML правил только раз конфиг у гитлаба, после YAML было неудобно

Если честно, не знаю, я ненавижу toml и обожаю yaml

Просто знаю что за него почему-то принято топить как раз в контексте "я каждый раз испытываю страдание когда использую yaml"

Может модно, не знаю. Мне, в принципе, всё норм. ini только не люблю.

Почему я ушёл от Atom обратно к VS Code

Дано: технический писатель, разрабатываю документацию в Asciidoc, всё люблю "из коробки", два года работал с VS Code, затем по рекомендации коллег перешёл на Atom.
Несколько месяцев проработал с Atom и вернулся обратно к VS Code, ниже делюсь впечатлениями.

В Atom отсутствуют рабочие пространства. Ну или я их не нашёл.

Git Blame в Atom есть только в виде таблицы, не нашёл GitLens, чтобы прямо над каждой строкой было.

Установленный терминал, а встроенного терминала в Atom нет, игнорирует символ _ в названиях веток и тексте.

Установленный терминал открывается с помощью Ctrl+Shift+T, но как его закрыть обратно? Такого хоткея я не нашёл, ну или плохо искал. В VS Code всё решается одним хоткеем.

Иногда Atom "вылетает" без объяснения причин. Мелочь, но отвлекает.

Чтобы установить новый Package в Atom, нужно зайти в Welcome Guide и только там выбрать Install a Package. Какой-то сложный UX.

Время от времени Atom плохо индексирует проект, и зачастую невозможно найти файл сразу после запуска Atom. Иногда дело доходило до использования grep.

Не нашёл удобный package для работы с TODO в Atom.

Непонятно, какой комбинацией клавиш в Atom можно перенести окно вправо вместо того, чтобы нажимать на окно правой кнопкой и выбирать Split Right.

Внешний вид в VS Code просто приятнее. Но это вкусовщина.

Поиск команды и файла разделены разными комбинациями в Atom. В VS Code это сделано в одном окне.

Asciidoc preview - невозможно обновить окно, чтобы посмотреть изменения. Сам предпросмотр обновляется не сразу, я не понял логики обновлений.

Asciidoc preview - не пролистывает исходный файл при прокручивании Preview.

Asciidoc Preview - не показывает JSON при include.

После переключения на другую ветку, Atom метит файлы с прежней ветки как несохраненные и спрашивает, сохранить ли. Иногда это сбивает с толку. VS Code же помечает файл как удалёнынй и ничего не предлагает с ним делать. Это удобнее.

Преимущество Atom: более насыщенный цветами синтаксис Asciidoc, лучше обозначены элементы контента. В VS Code цветовая гамма скромнее.

Общие впечатления: Atom хороший редактор, но VS Code мне нравится больше и он субъективно удобнее.

Кстати, Optima приятный

Том Джонсон разочаровался в подходе docs like code и теперь склоняется к docs like prose:
https://idratherbewriting.com/blog/treat-code-like-code-and-prose-like-prose/

и накатал целый роман

Ещё чуть-чуть, и сообщество познает дао, что "docs like only docs" :)

docs like code не нужно, расходимся )

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

и как вы таки это себе представляете, если механизм деплоя один?)

Я думаю, Том погорячился насчёт всего подхода. Его основная боль — процесс ревью документов.

Некоторые стейкхолдеры предпочитают менее технические инструменты: например, Quip или Google Docs.

В заказной разработке ровно эта боль – я не всегда могу погрузить внешних заказчиков в свой, страшный для них процесс

Как правило нужно подстраиваться, собирать документацию для ревью внешними людьми в тот же Google Docs

И вот потом, когда получаем фидбек в виде комментариев в Word'овском формате, связывать их обратно с исходником довольно унылое занятие

Люди часто ленятся потом возвращаться к .md (потому что это объективно неудобно), и финальные правки остаются в Google Docs :(

И к вопросу о пайплайне, соответственно

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

У меня была ситуация, когда команду опытных западных техрайтеров нужно было погружать в гит. Они с ним раньше не имели дела. Хорошо хоть тим лид дал добро, хотя он сам тоже не имел опыта работы с гитом.

Так нет никакой проблемы запускать только нужные джобы при изменении конкретных файлов

Инкрементальная сборка?

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